﻿3GPP TS 29.002 V16.3.0 (2021-06)
Technical Specification
3rd Generation Partnership Project;
Technical Specification Group Core Network and Terminals;
Mobile Application Part (MAP) specification
(Release 16)

	



The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification.
Specifications and Reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.




3GPP
Postal address

3GPP support office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Internet
http://www.3gpp.org

Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© 2021, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).
All rights reserved.

UMTS™ is a Trade Mark of ETSI registered for the benefit of its members
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
LTE™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
GSM® and the GSM logo are registered and owned by the GSM Association

Contents
Foreword	28
1	Scope	29
2	References	29
3	Abbreviations	35
4	Void	36
5	Overload and compatibility overview	36
5.1	Overload control	36
5.1.1	Overload control for MSC (outside MAP)	36
5.1.2	Overload control for MAP entities	36
5.1.3	Congestion control for Signalling System No. 7	40
5.2	Compatibility	40
5.2.1	General	40
5.2.2	Strategy for selecting the Application Context (AC) version	40
5.2.2.1	Proposed method	40
5.2.2.2	Managing the version look-up table	41
5.2.2.3	Optimising the method	42
6	Requirements concerning the use of SCCP and TC	42
6.1	Use of SCCP	42
6.1.1	SCCP Class	42
6.1.2	Sub-System Number (SSN)	42
6.1.3	SCCP addressing	43
6.1.3.1	Introduction	43
6.1.3.2	The Mobile-services Switching Centre (MSC)	45
6.1.3.2.1	MSC interaction during handover or relocation	45
6.1.3.2.2	MSC for short message routing	45
6.1.3.2.3	MSC for location request routing	45
6.1.3.2.4	MSC for LMU Control	45
6.1.3.3	The Home Location Register (HLR)	46
6.1.3.3.1	During call set-up	46
6.1.3.3.2	Before location updating completion	46
6.1.3.3.3	After location updating completion	46
6.1.3.3.4	VLR restoration	47
6.1.3.3.5	During Network-Requested PDP Context Activation	47
6.1.3.3.6	Before GPRS location updating completion	47
6.1.3.3.7	After GPRS location updating completion	48
6.1.3.3.8	Query for a Location Request	48
6.1.3.4	The Visitor Location Register (VLR)	48
6.1.3.4.0	General	48
6.1.3.4.1	Inter-VLR information retrieval	48
6.1.3.4.2	HLR request	48
6.1.3.4.3	CSS request	48
6.1.3.5	The Interworking MSC (IWMSC) for Short Message Service	49
6.1.3.6	The Equipment Identity Register (EIR)	49
6.1.3.7	Void	49
6.1.3.8	The Serving GPRS Support Node (SGSN)	49
6.1.3.8.0	General	49
6.1.3.8.1	HLR request	49
6.1.3.8.2	GMSC request	49
6.1.3.8.3	CSS request	49
6.1.3.9	The Gateway GPRS Support Node (GGSN)	49
6.1.3.10	The Gateway MSC (GMSC) for Short Message Service	50
6.1.3.10A	Void	50
6.1.3.10A.1	Void	50
6.1.3.10A.2	Void	50
6.1.3.10B	The Gateway Mobile Location Centre (GMLC)	50
6.1.3.10C	The CSG Subscriber Server (CSS)	50
6.1.3.11	Summary table	50
6.2	Use of TC	53
7	General on MAP services	53
7.1	Terminology and definitions	53
7.2	Modelling principles	53
7.3	Common MAP services	54
7.3.1	MAP-OPEN service	55
7.3.2	MAP-CLOSE service	58
7.3.3	MAP-DELIMITER service	58
7.3.4	MAP-U-ABORT service	58
7.3.5	MAP-P-ABORT service	59
7.3.6	MAP-NOTICE service	60
7.3.7	Void	61
7.3.8	Void	61
7.3.9	Void	61
7.3.10	Void	61
7.4	Sequencing of services	61
7.5	General rules for mapping of services onto TC	62
7.5.1	Mapping of common services	62
7.5.2	Mapping of user specific services	63
7.6	Definition of parameters	64
7.6.1	Common parameters	64
7.6.1.1	Invoke Id	64
7.6.1.2	Linked Id	64
7.6.1.3	Provider error	64
7.6.1.4	User error	64
7.6.2	Numbering and identification parameters	68
7.6.2.1	IMSI	68
7.6.2.2	TMSI	68
7.6.2.3	IMEI	68
7.6.2.3a	IMEISV	68
7.6.2.4	Previous location area Id	68
7.6.2.5	Stored location area Id	68
7.6.2.6	Current location area Id	68
7.6.2.7	Target location area Id	68
7.6.2.8	Target cell Id	68
7.6.2.8A	Target RNC Id	68
7.6.2.9	Void	68
7.6.2.10	Originating entity number	69
7.6.2.11	MSC number	69
7.6.2.12	Target MSC number	69
7.6.2.13	HLR number	69
7.6.2.14	VLR number	69
7.6.2.15	HLR Id	69
7.6.2.16	LMSI	69
7.6.2.17	MS ISDN	69
7.6.2.17A	Additional MSISDN	69
7.6.2.18	OMC Id	69
7.6.2.19	Roaming number	69
7.6.2.19A	Relocation Number List	69
7.6.2.20	Void	69
7.6.2.21	Handover number	69
7.6.2.22	Forwarded-to number	70
7.6.2.22A	Long forwarded-to number	70
7.6.2.22B	Long FTN Supported	70
7.6.2.23	Forwarded-to subaddress	70
7.6.2.24	Called number	70
7.6.2.25	Calling number	70
7.6.2.26	Originally dialled number	70
7.6.2.27	Service centre address	70
7.6.2.28	Zone Code	70
7.6.2.29	MSIsdn-Alert	70
7.6.2.30	Location Information	70
7.6.2.30a	Location Information for GPRS	70
7.6.2.30b	Location Information for EPS	70
7.6.2.31	GMSC Address	70
7.6.2.32	VMSC Address	71
7.6.2.33	Group Id	71
7.6.2.34	North American Equal Access preferred Carrier Id	71
7.6.2.35	Void	71
7.6.2.36	Void	71
7.6.2.37	Serving cell Id	71
7.6.2.38	SGSN number	71
7.6.2.39	SGSN address	71
7.6.2.40	GGSN address	71
7.6.2.41	GGSN number	71
7.6.2.42	APN	71
7.6.2.43	Network Node number	72
7.6.2.43A	Network Node Diameter Address	72
7.6.2.44	PDP-Type	72
7.6.2.44A	Extension PDP-Type	72
7.6.2.45	PDP-Address	72
7.6.2.45A	Extension PDP-Address	72
7.6.2.46	Additional number	72
7.6.2.46A	Additional Network Node Diameter Address	72
7.6.2.46B	Third Number	72
7.6.2.46C	Third Network Node Diameter Address	72
7.6.2.47	P-TMSI	72
7.6.2.48	B-subscriber number	73
7.6.2.49	B-subscriber subaddress	73
7.6.2.50	LMU Number	73
7.6.2.51	MLC Number	73
7.6.2.52	Multicall Bearer Information	73
7.6.2.53	Multiple Bearer Requested	73
7.6.2.54	Multiple Bearer Not Supported	73
7.6.2.55	PDP-Charging Characteristics	73
7.6.2.56	Selected RAB ID	73
7.6.2.57	RAB ID	73
7.6.2.58	gsmSCF Address	73
7.6.2.59	V-GMLC Address	73
7.6.2.60	Void	73
7.6.2.61	H-GMLC Address	73
7.6.2.62	PPR Address	74
7.6.2.63	Routeing Number	74
7.6.2.64	Additional V-GMLC Address	74
7.6.2.65	MME Name	74
7.6.2.66	3GPP AAA Server Name	74
7.6.2.67	CSS number	74
7.6.2.68	SGSN Name	74
7.6.2.69	SGSN Realm	74
7.6.3	Subscriber management parameters	74
7.6.3.1	Category	74
7.6.3.2	Equipment status	74
7.6.3.2a	BMUEF	74
7.6.3.3	Extensible Bearer service	74
7.6.3.4	Extensible Teleservice	74
7.6.3.5	Extensible Basic Service Group	75
7.6.3.6	GSM bearer capability	75
7.6.3.7	Subscriber Status	75
7.6.3.8	CUG Outgoing Access indicator	75
7.6.3.9	Operator Determined Barring General Data	75
7.6.3.10	ODB HPLMN Specific Data	77
7.6.3.11	Regional Subscription Data	77
7.6.3.12	Regional Subscription Response	77
7.6.3.13	Roaming Restriction Due To Unsupported Feature	78
7.6.3.14	Extensible SS-Info	78
7.6.3.15	Extensible forwarding information	78
7.6.3.16	Extensible forwarding feature	78
7.6.3.17	Extensible SS-Status	78
7.6.3.18	Extensible Forwarding Options	78
7.6.3.19	Extensible No reply condition timer	79
7.6.3.20	Extensible Call barring information	79
7.6.3.21	Extensible Call barring feature	79
7.6.3.22	CUG info	79
7.6.3.23	CUG subscription	79
7.6.3.24	CUG interlock	79
7.6.3.25	CUG index	80
7.6.3.26	CUG feature	80
7.6.3.27	Inter CUG options	80
7.6.3.28	Intra CUG restrictions	80
7.6.3.29	Extensible SS-Data	80
7.6.3.30	Subscriber State	80
7.6.3.31	Requested Info	81
7.6.3.31A	Requested Domain	81
7.6.3.32	Suppression of Announcement	81
7.6.3.33	Suppress T-CSI	81
7.6.3.34	GMSC CAMEL Subscription Info	81
7.6.3.35	VLR CAMEL Subscription Info	81
7.6.3.36	Supported CAMEL Phases in the VLR	81
7.6.3.36A	Supported CAMEL Phases in the SGSN	81
7.6.3.36B	Offered CAMEL4 CSIs in the VLR	81
7.6.3.36C	Offered CAMEL4 CSIs in the SGSN	81
7.6.3.36D	Offered CAMEL4 CSIs	81
7.6.3.36E	Offered CAMEL4 CSIs in interrogating node	81
7.6.3.36F	Offered CAMEL4 CSIs in VMSC	81
7.6.3.36G	Offered CAMEL4  Functionalities	82
7.6.3.36H	Supported CAMEL Phases	82
7.6.3.36I	Supported CAMEL Phases in interrogating node	82
7.6.3.37	CUG Subscription Flag	82
7.6.3.38	CAMEL Subscription Info Withdraw	82
7.6.3.39	Voice Group Call Service (VGCS) Data	82
7.6.3.40	Voice Broadcast Service (VBS) Data	82
7.6.3.41	ISDN bearer capability	82
7.6.3.42	Lower layer Compatibility	82
7.6.3.43	High Layer Compatibility	82
7.6.3.44	Alerting Pattern	82
7.6.3.45	GPRS Subscription Data Withdraw	82
7.6.3.45A	EPS Subscription Data Withdraw	82
7.6.3.46	GPRS Subscription Data	83
7.6.3.46A	EPS Subscription Data	83
7.6.3.47	QoS-Subscribed	83
7.6.3.48	VPLMN address allowed	83
7.6.3.49	Roaming Restricted In SGSN/MME Due To Unsupported Feature	83
7.6.3.50	Network Access Mode	83
7.6.3.51	Mobile Not Reachable Reason	83
7.6.3.52	Cancellation Type	83
7.6.3.53	All GPRS Data	83
7.6.3.54	Complete Data List Included	83
7.6.3.55	PDP Context Identifier	83
7.6.3.56	LSA Information	83
7.6.3.57	SoLSA support indicator	84
7.6.3.58	LSA Information Withdraw	84
7.6.3.59	LMU Indicator	84
7.6.3.60	LCS Information	84
7.6.3.61	GMLC List	84
7.6.3.62	LCS Privacy Exception List	84
7.6.3.62A	Additional LCS Privacy Exception List	84
7.6.3.63	LCS Privacy Exception Parameters	84
7.6.3.64	External Client List	85
7.6.3.65	Internal Client List	85
7.6.3.65A	MO-LR List	85
7.6.3.65B	Privacy Notification to MS User	85
7.6.3.65C	GMLC List Withdraw	85
7.6.3.65D	Service Type List	85
7.6.3.66	IST Alert Timer	85
7.6.3.67	Call Termination Indicator	85
7.6.3.68	IST Information Withdraw	85
7.6.3.69	IST Support Indicator	85
7.6.3.70	Super-Charger Supported In HLR	86
7.6.3.71	Super-Charger Supported In Serving Network Entity	86
7.6.3.72	Age Indicator	86
7.6.3.73	GPRS enhancements support indicator	86
7.6.3.74	Extension QoS-Subscribed	86
7.6.3.75	SGSN CAMEL Subscription Info	86
7.6.3.75A	Extension-2 QoS-Subscribed	86
7.6.3.75B	Extension-3 QoS-Subscribed	86
7.6.3.75C	Extension-4 QoS-Subscribed	86
7.6.3.76	MO-SMS-CSI	86
7.6.3.76a	MT-SMS-CSI	87
7.6.3.77	GPRS-CSI	87
7.6.3.78	CAMEL subscription info	87
7.6.3.83	Call Barring Data	87
7.6.3.84	Call Forwarding Data	87
7.6.3.85	ODB Data	88
7.6.3.86	Requested Subscription Info	88
7.6.3.87	CS Allocation/Retention priority	88
7.6.3.88	ODB Info	88
7.6.3.89	Suppress VT-CSI	88
7.6.3.90	Suppress Incoming Call Barring	88
7.6.3.91	gsmSCF Initiated Call	88
7.6.3.91a	SuppressMTSS	88
7.6.3.92	Call barring support indicator	88
7.6.3.93	MNP Info Result	88
7.6.3.94	Allowed Services	88
7.6.3.95	Unavailability Cause	89
7.6.3.96	MNP Requested Info	89
7.6.3.97	Access Restriction Data	89
7.6.3.98	Supported RAT types indicator	89
7.6.3.99	UE SRVCC Capability	89
7.6.3.100	Temporary Empty CSG Subscription data Indicator	89
7.6.3.101	WLAN-offloadability	89
7.6.3.102	IMSI-Group-Id	89
7.6.4	Supplementary services parameters	89
7.6.4.1	SS-Code	89
7.6.4.1A	SS-Code 2	90
7.6.4.2	SS-Status	90
7.6.4.3	SS-Data	90
7.6.4.4	Override Category	90
7.6.4.5	CLI Restriction Option	90
7.6.4.6	Forwarding Options	91
7.6.4.7	No reply condition timer	91
7.6.4.8 - 7.6.4.14	Void	91
7.6.4.15	Forwarding information	91
7.6.4.16	Forwarding feature	91
7.6.4.17	Void	91
7.6.4.18	Call barring information	91
7.6.4.19	Call barring feature	92
7.6.4.20	New password	92
7.6.4.21	Current password	92
7.6.4.22	Guidance information	92
7.6.4.23	Void	92
7.6.4.24	SS-Info	92
7.6.4.25 - 7.6.4.35	Void	92
7.6.4.36	USSD Data Coding Scheme	93
7.6.4.37	USSD String	93
7.6.4.38	Bearer service	93
7,6,4.38A	Bearer Service 2	93
7.6.4.39	Teleservice	93
7.6.4.39A	Teleservice 2	93
7.6.4.40	Basic Service Group	93
7.6.4.41	eMLPP information	93
7.6.4.42	SS-event	93
7.6.4.43	SS-event data	94
7.6.4.44	LCS Privacy Exceptions	94
7.6.4.45	Mobile Originating Location Request (MO-LR)	94
7.6.4.46	NbrUser	94
7.6.4.47	MC Subscription Data	94
7.6.4.48	MC Information	94
7.6.4.49	CCBS Request State	95
7.6.4.50	Basic Service Group 2	95
7.6.5	Call parameters	95
7.6.5.1	Call reference number	95
7.6.5.2	Interrogation type	95
7.6.5.3	OR interrogation	95
7.6.5.4	OR capability	95
7.6.5.5	Forwarding reason	95
7.6.5.6	Forwarding interrogation required	96
7.6.5.7	O-CSI	96
7.6.5.7A	D-CSI	96
7.6.5.7B	T-CSI	96
7.6.5.7C	VT-CSI	96
7.6.5.7D	O-IM-CSI	96
7.6.5.7E	D-IM-CSI	96
7.6.5.7F	VT-IM-CSI	96
7.6.5.8	Void	96
7.6.5.9	Void	96
7.6.5.10	Void	96
7.6.5.11	CCBS Feature	96
7.6.5.12	UU Data	97
7.6.5.14	Number Portability Status	97
7.6.5.15	Pre-paging supported	97
7.6.5.16	MT Roaming Retry Supported	97
7.6.5.17	MT Roaming Retry	97
7.6.5.18	Paging Area	97
7.6.5.19	Call Priority	97
7.6.5.20	MTRF Supported	97
7.6.5.21	LCLS Global Call Reference (LCLS GCR)	97
7.6.5.22	LCLS-Negotiation	97
7.6.5.23	LCLS-Configuration-Preference	97
7.6.6	Radio parameters	97
7.6.6.1 - 7.6.6.3	Void	98
7.6.6.4	GERAN Classmark	98
7.6.6.5	BSSMAP Service Handover	98
7.6.6.5A	BSSMAP Service Handover List	98
7.6.6.6	RANAP Service Handover	98
7.6.6.7	HO-Number Not Required	98
7.6.6.8	Integrity Protection Information	98
7.6.6.9	Encryption Information	98
7.6.6.10	Radio Resource Information	98
7.6.6.10A	Radio Resource List	98
7.6.6.10B	Chosen Radio Resource Information	98
7.6.6.11	Key Status	98
7.6.6.12	Selected UMTS Algorithms	98
7.6.6.13	Allowed GSM Algorithms	98
7.6.6.14	Allowed UMTS Algorithms	99
7.6.6.15	Selected GSM Algorithm	99
7.6.6.16	Iu-Currently Used Codec	99
7.6.6.17	Iu-Supported Codecs List	99
7.6.6.17A	Iu-Available Codecs List	99
7.6.6.18	Iu-Selected Codec	99
7.6.6.19	RAB Configuration Indicator	99
7.6.6.20	UESBI-Iu	99
7.6.6.21	Alternative Channel Type	99
7.6.6.22	AoIP-Supported Codecs List Anchor	99
7.6.6.23	AoIP-Available Codecs List Map	99
7.6.6.24	AoIP-Selected Codec Target	99
7.6.7	Authentication parameters	100
7.6.7.1	Authentication set list	100
7.6.7.2	Rand	100
7.6.7.3	Sres	100
7.6.7.4	Kc	100
7.6.7.5	Xres	100
7.6.7.5A	Ck	100
7.6.7.5B	Ik	100
7.6.7.5C	Autn	100
7.6.7.5D	KASME	100
7.6.7.6	Cksn	100
7.6.7.6A	Ksi	100
7.6.7.6B	Auts	100
7.6.7.7	Ciphering mode	101
7.6.7.8	Current Security Context	101
7.6.7.9	Failure cause	101
7.6.7.10	Re-attempt	101
7.6.7.11	Access Type	101
7.6.8	Short message parameters	101
7.6.8.1	SM-RP-DA	101
7.6.8.2	SM-RP-OA	101
7.6.8.3	MWD status	101
7.6.8.4	SM-RP-UI	102
7.6.8.5	SM-RP-PRI	102
7.6.8.6	SM Delivery Outcome	102
7.6.8.7	More Messages To Send	102
7.6.8.8	Alert Reason	102
7.6.8.9	Absent Subscriber Diagnostic SM	102
7.6.8.10	Alert Reason Indicator	102
7.6.8.10A	Additional Alert Reason Indicator	102
7.6.8.11	Additional SM Delivery Outcome	102
7.6.8.12	Additional Absent Subscriber Diagnostic SM	102
7.6.8.13	Delivery Outcome Indicator	103
7.6.8.14	GPRS Node Indicator	103
7.6.8.14A	IMS Node Indicator	103
7.6.8.15	GPRS Support Indicator	103
7.6.8.16	SM-RP-MTI	103
7.6.8.17	SM-RP-SMEA	103
7.6.8.18	IP-SM-GW SM Delivery Outcome	103
7.6.8.19	IP-SM-GW Absent Subscriber Diagnostic SM	103
7.6.8.20	IP-SM-GW Indicator	103
7.6.8.21	SM Delivery Timer	103
7.6.8.22	SM Delivery Start Time	103
7.6.8.23	Maximum Retransmission Time	103
7.6.8.24	Requested Retransmission Time	103
7.6.8.25	Maximum UE Availability Time	104
7.6.8.26	SMS-GMSC Alert Event	104
7.6.8.27	SMS-GMSC Address	104
7.6.8.28	SMS-GMSC Diameter Address	104
7.6.8.29	New SGSN Number	104
7.6.8.30	New MME Number	104
7.6.8.31	New SGSN Diameter Address	104
7.6.8.32	New MME Diameter Address	104
7.6.8.33	New MSC Number	104
7.6.8.34	SMSF 3GPP Absent Subscriber Diagnostic SM	104
7.6.8.35	SMSF Non 3GPP Absent Subscriber Diagnostic SM	104
7.6.8.36	SMSF 3GPP Delivery Outcome Indicator	104
7.6.8.37	SMSF Non-3GPP Delivery Outcome Indicator	105
7.6.8.38	SMSF 3GPP SM Delivery Outcome	105
7.6.8.39	SMSF Non-3GPP SM Delivery Outcome	105
7.6.8.40	SMSF 3GPP Absent Subscriber Diagnostic SM	105
7.6.8.41	SMSF Non 3GPP Absent Subscriber Diagnostic SM	105
7.6.9	Access and signalling system related parameters	105
7.6.9.1	AN-apdu	105
7.6.9.2	CM service type	105
7.6.9.3	Access connection status	105
7.6.9.4	External Signal Information	106
7.6.9.5	Access signalling information	106
7.6.9.6	Location update type	106
7.6.9.7	Protocol ID	106
7.6.9.8	Network signal information	106
7.6.9.8A	Network signal information 2	107
7.6.9.9	Call Info	107
7.6.9.10	Additional signal info	107
7.6.10	System operations parameters	107
7.6.10.1	Network resources	108
7.6.10.2	Trace reference	108
7.6.10.2A	Trace reference 2	108
7.6.10.3	Trace type	108
7.6.10.4	Additional network resources	108
7.6.10.5	Trace depth list	108
7.6.10.6	Trace NE type list	108
7.6.10.7	Trace interface list	108
7.6.10.8	Trace event list	108
7.6.10.9	Trace support indicator	109
7.6.10.10	Trace Propagation List	109
7.6.10.11	MDT-Configuration	109
7.6.10.12	MDT User Consent	109
7.6.11	Location Service Parameters	109
7.6.11.1	Age of Location Estimate	109
7.6.11.2	Deferred MT-LR Response Indicator	109
7.6.11.3	Deferred MT-LR Data	109
7.6.11.4	LCS Client ID	109
7.6.11.5	LCS Event	109
7.6.11.7	LCS Priority	109
7.6.11.8	LCS QoS	109
7.6.11.9	CS LCS Not Supported by UE	110
7.6.11.10	PS LCS Not Supported by UE	110
7.6.11.11	Location Estimate	110
7.6.11.11A	GERAN Positioning Data	110
7.6.11.11B	UTRAN Positioning Data	110
7.6.11.11C	GERAN GANSS Positioning Data	111
7.6.11.11D	UTRAN GANSS Positioning Data	111
7.6.11.11E	UTRAN Additional Positioning Data	111
7.6.11.11F	UTRAN Barometric Pressure Measurement	111
7.6.11.11G	UTRAN Civic Address	111
7.6.11.12	Location Type	111
7.6.11.13	NA-ESRD	111
7.6.11.14	NA-ESRK	111
7.6.11.15	LCS Service Type Id	111
7.6.11.16	Privacy Override	111
7.6.11.17	Supported LCS Capability Sets	112
7.6.11.18	LCS Codeword	112
7.6.11.19	NA-ESRK Request	112
7.6.11.20	Supported GAD Shapes	112
7.6.11.21	Additional Location Estimate	112
7.6.11.22	Cell Id Or SAI	112
7.6.11.23	LCS-Reference Number	112
7.6.11.24	LCS Privacy Check	112
7.6.11.25	Additional LCS Capability Sets	113
7.6.11.26	Area Event Info	113
7.6.11.27	Velocity Estimate	113
7.6.11.28	Accuracy Fulfilment Indicator	113
7.6.11.29	MO-LR Short Circuit Indicator	113
7.6.11.30	Reporting PLMN List	113
7.6.11.31	Periodic LDR information	113
7.6.11.32	Sequence Number	113
7.6.12	Void	113
7.7	Representation of a list of a basic parameter in service-primitives	114
8	Mobility services	114
8.1	Location management services	114
8.1.1	Void	114
8.1.1.1	Void	114
8.1.1.2	Void	114
8.1.1.3	Void	114
8.1.2	MAP_UPDATE_LOCATION service	114
8.1.2.1	Definition	114
8.1.2.2	Service primitives	114
8.1.2.3	Parameter definitions and use	115
8.1.3	MAP_CANCEL_LOCATION service	118
8.1.3.1	Definition	118
8.1.3.2	Service primitives	118
8.1.3.3	Parameter definitions and use	118
8.1.4	MAP_SEND_IDENTIFICATION service	119
8.1.4.1	Definition	119
8.1.4.2	Service primitives	119
8.1.4.3	Parameter definitions and use	120
8.1.5	Void	121
8.1.5.1	Void	121
8.1.5.2	Void	121
8.1.5.3	Void	121
8.1.6	MAP_PURGE_MS service	121
8.1.6.1	Definition	121
8.1.6.2	Service primitives	122
8.1.6.3	Parameter definitions and use	122
8.1.7	MAP_UPDATE_GPRS_LOCATION service	123
8.1.7.1	Definition	123
8.1.7.2	Service primitives	123
8.1.7.3	Parameter definitions and use	124
8.1.8	MAP-NOTE-MM-EVENT	128
8.1.8.1	Definition	128
8.1.8.2	Service primitives	128
8.1.8.3	Parameter use	129
8.1.9	MAP_UPDATE_VCSG_LOCATION service	130
8.1.9.1	Definition	130
8.1.9.2	Service primitives	130
8.1.9.3	Parameter definitions and use	131
8.1.10	MAP_ CANCEL_VCSG_LOCATION service	131
8.1.10.1	Definition	131
8.1.10.2	Service primitives	131
8.1.10.3	Parameter definitions and use	132
8.2	Paging and search	132
8.2.1	MAP_PAGE service	132
8.2.1.1	Definition	132
8.2.1.2	Service primitives	132
8.2.1.3	Parameter definitions and use	132
8.2.2	MAP_SEARCH_FOR_MS service	133
8.2.2.1	Definition	133
8.2.2.2	Service primitives	133
8.2.2.3	Parameter definitions and use	133
8.3	Access management services	134
8.3.1	MAP_PROCESS_ACCESS_REQUEST service	134
8.3.1.1	Definition	134
8.3.1.2	Service primitives	134
8.3.1.3	Parameter definitions and use	134
8.4	Handover services	136
8.4.1	MAP_PREPARE_HANDOVER service	136
8.4.1.1	Definition	136
8.4.1.2	Service primitives	136
8.4.1.3	Parameter use	137
8.4.2	MAP_SEND_END_SIGNAL service	141
8.4.2.1	Definition	141
8.4.2.2	Service primitives	141
8.4.2.3	Parameter use	141
8.4.3	MAP_PROCESS_ACCESS_SIGNALLING service	141
8.4.3.1	Definition	141
8.4.3.2	Service primitives	141
8.4.3.3	Parameter use	142
8.4.4	MAP_FORWARD_ACCESS_SIGNALLING service	143
8.4.4.1	Definition	143
8.4.4.2	Service primitives	143
8.4.4.3	Parameter use	144
8.4.5	MAP_PREPARE_SUBSEQUENT_HANDOVER service	146
8.4.5.1	Definition	146
8.4.5.2	Service primitives	146
8.4.5.3	Parameter use	146
8.4.6	MAP_ALLOCATE_HANDOVER_NUMBER service	147
8.4.6.1	Definition	147
8.4.6.2	Service primitives	147
8.4.6.3	Parameter use	147
8.4.7	MAP_SEND_HANDOVER_REPORT service	148
8.4.7.1	Definition	148
8.4.7.2	Service primitives	148
8.4.7.3	Parameter use	148
8.5	Authentication management services	148
8.5.1	MAP_AUTHENTICATE service	148
8.5.1.1	Definition	148
8.5.1.2	Service primitives	149
8.5.1.3	Parameter use	149
8.5.2	MAP_SEND_AUTHENTICATION_INFO service	149
8.5.2.1	Definition	149
8.5.2.2	Service primitives	150
8.5.2.3	Parameter use	150
8.5.3	MAP_AUTHENTICATION_FAILURE_REPORT service	152
8.5.3.1	Definition	152
8.5.3.2	Service primitives	152
8.5.3.3	Parameter use	152
8.6	Security management services	153
8.6.1	MAP_SET_CIPHERING_MODE service	153
8.6.1.1	Definitions	153
8.6.1.2	Service primitives	153
8.6.1.3	Parameter use	153
8.7	International mobile equipment identities management services	154
8.7.1	MAP_CHECK_IMEI service	154
8.7.1.1	Definition	154
8.7.1.2	Service primitives	154
8.7.1.3	Parameter use	154
8.7.2	MAP_OBTAIN_IMEI service	155
8.7.2.1	Definition	155
8.7.2.2	Service primitives	155
8.7.2.3	Parameter use	155
8.8	Subscriber management services	156
8.8.1	MAP-INSERT-SUBSCRIBER-DATA service	156
8.8.1.1	Definition	156
8.8.1.2	Service primitives	157
8.8.1.3	Parameter use	158
8.8.1.4	Basic service information related to supplementary services	172
8.8.2	MAP-DELETE-SUBSCRIBER-DATA service	172
8.8.2.1	Definition	172
8.8.2.2	Service primitives	172
8.8.2.3	Parameter use	173
8.9	Identity management services	178
8.9.1	MAP-PROVIDE-IMSI service	178
8.9.1.1	Definition	178
8.9.1.2	Service primitives	178
8.9.1.3	Parameter use	178
8.9.2	MAP-FORWARD-NEW-TMSI service	178
8.9.2.1	Definition	178
8.9.2.2	Service primitives	179
8.9.2.3	Parameter use	179
8.10	Fault recovery services	179
8.10.1	MAP_RESET service	179
8.10.1.1	Definition	179
8.10.1.2	Service primitives	179
8.10.1.3	Parameter definition and use	179
8.10.2	MAP_FORWARD_CHECK_SS_INDICATION service	180
8.10.2.1	Definition	180
8.10.2.2	Service primitives	180
8.10.2.3	Parameter definition and use	180
8.10.3	MAP_RESTORE_DATA service	181
8.10.3.1	Definition	181
8.10.3.2	Service primitives	181
8.10.3.3	Parameter definitions and use	181
8.11	Subscriber Information services	183
8.11.1	MAP-ANY-TIME-INTERROGATION service	183
8.11.1.1	Definition	183
8.11.1.2	Service primitives	183
8.11.1.3	Parameter definition and use	184
8.11.2	MAP-PROVIDE-SUBSCRIBER-INFO service	185
8.11.2.1	Definition	185
8.11.2.2	Service primitives	185
8.11.2.3	Parameter definition and use	185
8.11.3	MAP-ANY-TIME-SUBSCRIPTION-INTERROGATION service	186
8.11.3.1	Definition	186
8.11.3.2	Service primitives	186
8.11.3.3	Parameter definition and use	187
8.11.4	MAP-ANY-TIME-MODIFICATION service	188
8.11.4.1	Definition	188
8.11.4.2	Service primitives	188
8.11.4.3	Parameter definition and use	188
8.11.5	MAP-NOTE-SUBSCRIBER-DATA-MODIFIED service	189
8.11.5.1	Definition	189
8.11.5.2	Service primitives	189
8.11.5.3	Parameter definition and use	190
9	Operation and maintenance services	191
9.1	Subscriber tracing services	191
9.1.1	MAP-ACTIVATE-TRACE-MODE service	191
9.1.1.1	Definition	191
9.1.1.2	Service primitives	192
9.1.1.3	Parameter use	192
9.1.2	MAP-DEACTIVATE-TRACE-MODE service	193
9.1.2.1	Definition	193
9.1.2.2	Service primitives	193
9.1.2.3	Parameter use	193
9.1.3	MAP-TRACE-SUBSCRIBER-ACTIVITY service	194
9.1.3.1	Definition	194
9.1.3.2	Service primitives	194
9.1.3.3	Parameter use	194
9.2	Other operation and maintenance services	195
9.2.1	MAP-SEND-IMSI service	195
9.2.1.1	Definition	195
9.2.1.2	Service primitives	195
9.2.1.3	Parameter use	195
10	Call handling services	195
10.1	MAP_SEND_ROUTING_INFORMATION service	195
10.1.1	Definition	195
10.1.2	Service primitives	195
10.1.3	Parameter use	196
10.2	MAP_PROVIDE_ROAMING_NUMBER service	202
10.2.1	Definition	202
10.2.2	Service primitives	202
10.2.3	Parameter use	203
10.3	MAP_RESUME_CALL_HANDLING service	205
10.3.1	Definition	205
10.3.2	Service primitives	205
10.3.3	Parameter use	206
10.4	MAP_PREPARE_GROUP_CALL service	207
10.4.1	Definition	207
10.4.2	Service primitives	207
10.4.3	Parameter definitions and use	208
10.5	MAP_PROCESS_GROUP CALL_SIGNALLING service	209
10.5.1	Definitions	209
10.5.2	Service primitives	209
10.5.3	Parameter definitions and use	209
10.6	MAP_FORWARD_GROUP_CALL_SIGNALLING service	210
10.6.1	Definitions	210
10.6.2	Service primitives	210
10.6.3	Parameter definitions and use	210
10.7	MAP_SEND_GROUP_CALL_END_SIGNAL service	211
10.7.1	Definitions	211
10.7.2	Service primitives	212
10.7.3	Parameter definitions and use	212
10.7A	MAP_SEND_GROUP_CALL_INFO service	212
10.7A.1	Definitions	212
10.7A.2	Service primitives	212
10.7A.3	Parameter definitions and use	213
10.8	Void	214
10.9	Void	214
10.10	MAP_SET_REPORTING_STATE service	214
10.10.1	Definition	214
10.10.2	Service primitives	214
10.10.3	Parameter use	214
10.11	MAP_STATUS_REPORT service	215
10.11.1	Definition	215
10.11.2	Service primitives	215
10.11.3	Parameter use	215
10.12	MAP_REMOTE_USER_FREE service	216
10.12.1	Definition	216
10.12.2	Service primitives	216
10.12.3	Parameter use	216
10.13	MAP_IST_ALERT service	217
10.13.1	Definition	217
10.13.2	Service primitives	217
10.13.3	Parameter use	217
10.14	MAP_IST_COMMAND service	218
10.14.1	Definition	218
10.14.2	Service primitives	218
10.14.3	Parameter use	218
10.15	MAP_RELEASE_RESOURCES service	219
10.15.1	Definition	219
10.15.2	Service primitives	219
10.15.3	Parameter use	219
11	Supplementary services related services	219
11.1	MAP_REGISTER_SS service	219
11.1.1	Definition	219
11.1.2	Service primitives	219
11.1.3	Parameter use	220
11.2	MAP_ERASE_SS service	221
11.2.1	Definition	221
11.2.2	Service primitives	221
11.2.3	Parameter use	221
11.3	MAP_ACTIVATE_SS service	222
11.3.1	Definition	222
11.3.2	Service primitives	222
11.3.3	Parameter use	222
11.4	MAP_DEACTIVATE_SS service	223
11.4.1	Definitions	223
11.4.2	Service primitives	224
11.4.3	Parameter use	224
11.5	MAP_INTERROGATE_SS service	225
11.5.1	Definitions	225
11.5.2	Service primitives	225
11.5.3	Parameter use	225
11.6	Void	227
11.7	MAP_REGISTER_PASSWORD service	227
11.7.1	Definitions	227
11.7.2	Service primitives	227
11.7.3	Parameter use	227
11.8	MAP_GET_PASSWORD service	228
11.8.1	Definitions	228
11.8.2	Service primitives	228
11.8.3	Parameter use	228
11.9	MAP_PROCESS_UNSTRUCTURED_SS_REQUEST service	228
11.9.1	Definitions	229
11.9.2	Service primitives	229
11.9.3	Parameter use	229
11.10	MAP_UNSTRUCTURED_SS_REQUEST service	230
11.10.1	Definitions	230
11.10.2	Service primitives	230
11.10.3	Parameter use	230
11.11	MAP_UNSTRUCTURED_SS_NOTIFY service	231
11.11.1	Definitions	231
11.11.2	Service primitives	231
11.11.3	Parameter use	231
11.12	MAP_SS_INVOCATION_NOTIFY	232
11.12.1	Definition	232
11.12.2	Service primitives	232
11.12.3	Parameter use	232
11.13	MAP_REGISTER_CC_ENTRY service	233
11.13.1	Definition	233
11.13.2	Service primitives	233
11.13.3	Parameter use	233
11.14	MAP_ERASE_CC_ENTRY service	234
11.14.1	Definition	234
11.14.2	Service primitives	234
11.14.3	Parameter use	234
12	Short message service management services	235
12.1	MAP-SEND-ROUTING-INFO-FOR-SM service	235
12.1.1	Definition	235
12.1.2	Service primitives	235
12.1.3	Parameter use	236
12.1.4	Identities of MT-SMS Target Nodes	239
12.2	MAP-MO-FORWARD-SHORT-MESSAGE service	240
12.2.1	Definition	240
12.2.2	Service primitives	240
12.2.3	Parameter use	240
12.3	MAP-REPORT-SM-DELIVERY-STATUS service	241
12.3.1	Definition	241
12.3.2	Service primitives	241
12.3.3	Parameter use	242
12.4	MAP-READY-FOR-SM service	244
12.4.1	Definition	244
12.4.2	Service primitives	244
12.4.3	Parameter use	245
12.5	MAP-ALERT-SERVICE-CENTRE service	245
12.5.1	Definition	245
12.5.2	Service primitives	246
12.5.3	Parameter use	246
12.6	MAP-INFORM-SERVICE-CENTRE service	248
12.6.1	Definition	248
12.6.2	Service primitives	249
12.6.3	Parameter use	249
12.7	MAP-SEND-INFO-FOR-MT-SMS service	249
12.7.1	Definition	249
12.7.2	Service primitives	250
12.7.3	Parameter use	250
12.8	MAP-SEND-INFO-FOR-MO-SMS service	250
12.8.1	Definition	251
12.8.2	Service primitives	251
12.8.3	Parameter use	251
12.9	MAP-MT-FORWARD-SHORT-MESSAGE service	251
12.9.1	Definition	251
12.9.2	Service primitives	251
12.9.3	Parameter use	252
12.10	MAP-MT-FORWARD-SM-FOR-VGCS service	254
12.10.1	Definition	254
12.10.2	Service primitives	254
12.10.3	Parameter use	254
13	Network-Requested PDP Context Activation services	255
13.1	MAP_SEND_ROUTING_INFO_FOR_GPRS service	255
13.1.1	Definition	255
13.1.2	Service primitives	255
13.1.3	Parameter definition and use	255
13.2	MAP_FAILURE_REPORT service	256
13.2.1	Definition	256
13.2.2	Service primitives	256
13.2.3	Parameter definition and use	256
13.3	MAP_NOTE_MS_PRESENT_FOR_GPRS service	257
13.3.1	Definition	257
13.3.2	Service primitives	257
13.3.3	Parameter definition and use	257
13A	Location Service Management Services	258
13A.1	MAP-SEND-ROUTING-INFO-FOR-LCS Service	258
13A.1.1	Definition	258
13A.1.2	Service Primitives	258
13A.1.3	Parameter Use	259
13A.2	MAP-PROVIDE-SUBSCRIBER-LOCATION Service	260
13A.2.1	Definition	260
13A.2.2	Service Primitives	260
13A.2.3	Parameter Definition and Use	261
13A.3	MAP-SUBSCRIBER-LOCATION-REPORT Service	264
13A.3.1	Definition	264
13A.3.2	Service Primitives	264
13A.3.3	Parameter Definition and Use	265
13A.4	Void	268
13A.4.1	Void	268
13A.4.2	Void	268
13A.4.3	Void	268
13A.5	Void	268
13A.5.1	Void	268
13A.5.2	Void	268
13A.5.3	Void	268
13A.6	Void	268
13A.6.1	Void	269
13A.6.2	Void	269
13A.6.3	Void	269
13A.7	Void	269
13A.7.1	Void	269
13A.7.2	Void	269
13A.7.3	Void	269
13A.8	Void	269
13A.8.1	Void	269
13A.8.2	Void	269
13A.8.3	Void	269
13A.9	Void	269
13A.9.1	Void	269
13A.9.2	Void	269
13A.9.3	Void	269
14	General	269
14.1	Overview	269
14.2	Underlying services	269
14.3	Model	270
14.4	Conventions	270
15	Elements of procedure	270
15.1	Handling of unknown operations	270
15.2	Dialogue establishment	271
15.2.1	Behaviour at the initiating side	271
15.2.2	Behaviour at the responding side	272
15.3	Dialogue continuation	273
15.4	Load control	273
15.5	Procedures for MAP specific services	273
15.5.1	Service invocation	273
15.5.2	Void	274
15.5.3	Service invocation receipt	274
15.5.4	Void	274
15.5.5	Handling of components received from TC	274
15.6	SDL descriptions	274
16	Mapping on to TC services	307
16.1	Dialogue control	307
16.1.1	Directly mapped parameters	307
16.1.2	Use of other parameters of dialogue handling primitives	307
16.1.2.1	Dialogue Id	307
16.1.2.2	Application-context-name	307
16.1.2.3	User information	307
16.1.2.4	Component present	307
16.1.2.5	Termination	307
16.1.2.6	P-Abort-Cause	307
16.1.2.7	Quality of service	307
16.2	Service specific procedures	308
16.2.1	Directly mapped parameters	308
16.2.2	Use of other parameters of component handling primitives	308
16.2.2.1	Dialogue Id	308
16.2.2.2	Class	308
16.2.2.3	Linked Id	308
16.2.2.4	Operation	309
16.2.2.5	Error	310
16.2.2.6	Parameters	310
16.2.2.7	Time out	310
16.2.2.8	Last component	310
16.2.2.9	Problem code	310
16.2.2.9.1	Mapping to MAP User Error	310
16.2.2.9.2	Mapping to MAP Provider Error parameter	311
16.2.2.9.3	Mapping to diagnostic parameter	311
17	Abstract syntax of the MAP protocol	312
17.1	General	312
17.1.1	Encoding rules	312
17.1.2	Use of TC	312
17.1.2.1	Use of Global Operation and Error codes defined outside MAP	313
17.1.3	Use of information elements defined outside MAP	313
17.1.4	Compatibility considerations	313
17.1.5	Structure of the Abstract Syntax of MAP	314
17.1.6	Application Contexts	316
17.2	Operation packages	317
17.2.1	General aspects	317
17.2.2	Packages specifications	318
17.2.2.1	Location updating	318
17.2.2.2	Location cancellation	318
17.2.2.3	Roaming number enquiry	319
17.2.2.4	Information retrieval	319
17.2.2.5	Inter-VLR information retrieval	319
17.2.2.6	IMSI retrieval	319
17.2.2.7	Call control transfer	320
17.2.2.8	Void	320
17.2.2.9	Void	320
17.2.2.10	Interrogation	320
17.2.2.11	Void	320
17.2.2.12	Handover Control	320
17.2.2.13	Subscriber Data management stand alone	321
17.2.2.14	Equipment management	321
17.2.2.15	Subscriber data management	321
17.2.2.16	Location register restart	321
17.2.2.17	Tracing stand-alone	322
17.2.2.18	Functional SS handling	322
17.2.2.19	Tracing	322
17.2.2.20	Binding	322
17.2.2.21	Unstructured SS handling	323
17.2.2.22	MO Short message relay services	323
17.2.2.23	Short message gateway services	323
17.2.2.24	MT Short message relay services	324
17.2.2.25	Void	324
17.2.2.26	Message waiting data management	324
17.2.2.27	Alerting	324
17.2.2.28	Data restoration	324
17.2.2.29	Purging	325
17.2.2.30	Subscriber information enquiry	325
17.2.2.31	Any time information enquiry	325
17.2.2.32	Group Call Control	325
17.2.2.32A	Group Call Info Retrieval	325
17.2.2.33	Void	326
17.2.2.34	Void	326
17.2.2.35	Gprs location updating	326
17.2.2.36	Gprs Interrogation	326
17.2.2.37	Failure reporting	326
17.2.2.38	GPRS notifying	326
17.2.2.39	Supplementary Service invocation notification	327
17.2.2.40	Set Reporting State	327
17.2.2.41	Status Report	327
17.2.2.42	Remote User Free	327
17.2.2.43	Call Completion	327
17.2.2.44	Location service gateway services	327
17.2.2.45	Location service enquiry	328
17.2.2.45A	Location service reporting	328
17.2.2.46	Void	328
17.2.2.47	Void	328
17.2.2.48	Void	328
17.2.2.49	IST Alerting	328
17.2.2.50	Service Termination	328
17.2.2.51	Mobility Management event notification	329
17.2.2.53	Subscriber Data modification notification	329
17.2.2.54	Authentication Failure Report	329
17.2.2.55	Resource Management	329
17.2.2.56	MT Short message relay VGCS services	330
17.2.2.57	Vcsg location updating	330
17.2.2.58	Vcsg location cancellation	330
17.3	Application contexts	330
17.3.1	General aspects	330
17.3.2	Application context definitions	331
17.3.2.1	Void	331
17.3.2.2	Location Updating	331
17.3.2.3	Location Cancellation	331
17.3.2.4	Roaming number enquiry	332
17.3.2.5	Void	332
17.3.2.6	Location Information Retrieval	332
17.3.2.7	Call control transfer	332
17.3.2.8	Void	333
17.3.2.9	Void	333
17.3.2.10	Void	333
17.3.2.11	Location registers restart	333
17.3.2.12	Handover control	333
17.3.2.13	IMSI Retrieval	333
17.3.2.14	Equipment Management	334
17.3.2.15	Information retrieval	334
17.3.2.16	Inter-VLR information retrieval	334
17.3.2.17	Stand Alone Subscriber Data Management	335
17.3.2.18	Tracing	335
17.3.2.19	Network functional SS handling	335
17.3.2.20	Network unstructured SS handling	336
17.3.2.21	Short Message Gateway	336
17.3.2.22	Mobile originating Short Message Relay	336
17.3.2.23	Void	337
17.3.2.24	Short message alert	337
17.3.2.25	Short message waiting data management	337
17.3.2.26	Mobile terminating Short Message Relay	337
17.3.2.27	MS purging	338
17.3.2.28	Subscriber information enquiry	338
17.3.2.29	Any time information enquiry	338
17.3.2.30	Group Call Control	338
17.3.2.30A	Group Call Info Retrieval	338
17.3.2.31	Void	339
17.3.2.32	Gprs Location Updating	339
17.3.2.33	Gprs Location Information Retreival	339
17.3.2.34	Failure Reporting	339
17.3.2.35	GPRS Notifying	339
17.3.2.36	Supplementary Service invocation notification	340
17.3.2.37	Reporting	340
17.3.2.38	Call Completion	340
17.3.2.39	Location Service Gateway	341
17.3.2.40	Location Service Enquiry	341
17.3.2.41	Void	341
17.3.2.42	Void	341
17.3.2.43	Void	341
17.3.2.44	IST Alerting	341
17.3.2.45	Service Termination	341
17.3.2.46	Mobility Management event notification	342
17.3.2.48	Subscriber Data modification notification	342
17.3.2.49	Authentication Failure Report	342
17.3.2.50	Resource Management	342
17.3.2.51	Mobile terminating Short Message Relay VGCS	343
17.3.2.52	Vcsg Location Updating	343
17.3.2.53	Vcsg Location Cancellation	343
17.3.3	ASN.1 Module for application-context-names	343
17.4	MAP Dialogue Information	346
17.5	MAP operation and error codes	348
17.6	MAP operations and errors	350
17.6.1	Mobile Service Operations	350
17.6.2	Operation and Maintenance Operations	357
17.6.3	Call Handling Operations	358
17.6.4	Supplementary service operations	361
17.6.5	Short message service operations	365
17.6.6	Errors	368
17.6.7	Group Call operations	374
17.6.8	Location service operations	376
17.6.9	Void	377
17.7	MAP constants and data types	377
17.7.1	Mobile Service data types	377
17.7.2	Operation and maintenance data types	426
17.7.3	Call handling data types	433
17.7.4	Supplementary service data types	439
17.7.5	Supplementary service codes	443
17.7.6	Short message data types	446
17.7.7	Error data types	452
17.7.8	Common data types	458
17.7.9	Teleservice Codes	467
17.7.10	Bearer Service Codes	468
17.7.11	Extension data types	470
17.7.12	Group Call data types	471
17.7.13	Location service data types	474
17.7.14	Void	484
18	General on MAP user procedures	485
18.1	Introduction	485
18.2	Common aspects of user procedure descriptions	485
18.2.1	General conventions	485
18.2.2	Naming conventions	485
18.2.3	Convention on primitives parameters	486
18.2.3.1	Open service	486
18.2.3.2	Close service	487
18.2.4	Version handling at dialogue establishment	487
18.2.4.1	Behaviour at the initiating side	487
18.2.4.2	Behaviour at the responding side	487
18.2.5	Abort Handling	487
18.2.6	SDL conventions	487
18.3	Interaction between MAP Provider and MAP Users	488
19	Mobility procedures	489
19.1	Location management Procedures	489
19.1.1	Location updating	490
19.1.1.1	General	490
19.1.1.2	Procedures in the VLR	495
19.1.1.3	Procedure in the PVLR	495
19.1.1.4	Procedure in the SGSN	495
19.1.1.5	Procedures in the HLR	496
19.1.1A	Location updating for VCSG	516
19.1.1A.1	General	516
19.1.1A.2	Procedures in the VLR	516
19.1.1A.3	Procedures in the SGSN	516
19.1.1A.4	Procedures in the CSS	516
19.1.2	Location Cancellation	524
19.1.2.1	General	524
19.1.2.2	Procedure in the HLR	524
19.1.2.3	Procedure in the VLR	525
19.1.2.4	Procedure in the SGSN	525
19.1.2A	Location Cancellation for VCSG	532
19.1.2A.1	General	532
19.1.2A.2	Procedure in the CSS	532
19.1.2A.3	Procedure in the VLR	532
19.1.2A.4	Procedure in the SGSN	532
19.1.3	Void	536
19.1.4	MS Purging	536
19.1.4.1	General	537
19.1.4.2	Procedure in the VLR	537
19.1.4.3	Procedure in the SGSN	537
19.1.4.4	Procedure in the HLR	538
19.2	Handover procedures	543
19.2.1	General	543
19.2.2	Procedure in MSC‑A	546
19.2.2.1	Basic handover	546
19.2.2.2	Handling of access signalling	547
19.2.2.3	Subsequent handover	547
19.2.3	Procedure in MSC‑B	547
19.2.3.1	Basic handover	548
19.2.3.2	Handling of access signalling	548
19.2.3.3	Subsequent handover	548
19.2.4	Macro Receive_Error_From_HO_CA	548
19.2.5	Procedure in VLR‑B	548
19.3	Fault recovery procedures	567
19.3.1	VLR fault recovery procedures	567
19.3.1.1 General	567
19.3.1.2	Procedure in the VLR	568
19.3.1.3	Procedure in the HLR	568
19.3.2	HLR fault recovery procedures	570
19.3.2.1	General	570
19.3.2.2	Procedure in the HLR	571
19.3.2.3	Procedure in the VLR	572
19.3.2.4	Procedure in the SGSN	572
19.3.3	CSS fault recovery procedures	578
19.3.3.1	General	578
19.3.3.2	Procedure in the CSS	579
19.3.3.3	Procedure in the VLR	579
19.3.3.4	Procedure in the SGSN	579
19.4	Mobility Management event notification procedure	584
19.4.1	General	584
19.4.2	Procedure in the VLR or SGSN	585
19.4.3	Procedure in the gsmSCF	585
19.5	HLR Insert Subscriber Data macros	588
19.5.1	Macro Insert_Subs_Data_Framed_HLR	588
19.5.2	Macro Insert_GPRS_Subs_Data_Framed_HLR	588
19.5A	CSS Insert Subscriber Data macros	591
19.5A.1	Macro Insert_VCSG_Subs_Data_Framed_CSS	591
20	Operation and maintenance procedures	593
20.1	General	593
20.1.1	Tracing Co-ordinator for the VLR	593
20.1.2	Tracing Co-ordinator for the SGSN	593
20.1.3	Subscriber Data Management Co-ordinator for the VLR	593
20.1.4	Subscriber Data Management Co-ordinator for the SGSN	593
20.2	Tracing procedures	600
20.2.1	Subscriber tracing activation procedure	603
20.2.1.1	Procedures in the HLR	603
20.2.1.2	Procedure in the VLR	603
20.2.1.3	Procedure in the SGSN	603
20.2.2	Subscriber tracing deactivation procedure	603
20.2.2.1	Procedures in the HLR	603
20.2.2.2	Procedure in the VLR	604
20.2.2.3	Procedure in the SGSN	604
20.3	Subscriber data management procedures for HLR	617
20.3.1	Subscriber deletion procedure	618
20.3.1.1	Procedure in the HLR	618
20.3.1.2	Procedure in the VLR	618
20.3.1.3	Procedure in the SGSN	619
20.3.2	Subscriber data modification procedure	619
20.3.2.1	Procedure in the HLR	619
20.3.2.2	Procedures in the VLR	620
20.3.2.3	Procedures in the SGSN	620
20.3A	Subscriber Data Management procedures for CSS	632
20.3A.1	Subscriber deletion procedure	633
20.3A.1.1	Procedure in the CSS	633
20.3A.1.2	Procedure in the VLR	633
20.3A.1.3	Procedure in the SGSN	633
20.3A.2	Subscriber data modification procedure	634
20.3A.2.1	Procedure in the CSS	634
20.3A.2.2	Procedures in the VLR	634
20.3A.2.3	Procedures in the SGSN	634
20.4	Subscriber Identity procedure	646
20.4.1	Procedure in the VLR	646
20.4.2	Procedure in the HLR	646
21	Call handling procedures	649
21.1	General	649
21.2	Retrieval of routing information	649
21.2.1	General	649
21.2.2	Procedure in the GMSC	653
21.2.9	Process in the gsmSCF	653
21.2.4	Procedure in the HLR	653
21.2.5	Procedure in the VLR to provide a roaming number	654
21.2.6	Procedure in the VLR to restore subscriber data	654
21.2.7	Procedure in the VLR to provide subscriber information	654
21.2.8	Procedure in the old VLR to request a Roaming Number (MTRF)	654
21.3	Transfer of call handling	664
21.3.1	General	664
21.3.2	Process in the VMSC	664
21.3.3	Process in the GMSC	665
21.4	Inter MSC Group Call Procedures	668
21.4.1	General	668
21.4.2	Process in the Anchor MSC	668
21.4.3	Process in the Relay MSC	669
21.4A	Inter MSC Group Call Info Retrieval	674
21.4A.1	General	674
21.4A.2	Process in the MSC	674
21.5	Void	677
21.6	CCBS: monitoring and reporting the status of the subscriber	677
21.6.1	Reporting co-ordinator process in the VLR	677
21.6.2	Setting the reporting state – stand-alone	677
21.6.2.1	Process in the HLR	677
21.6.2.2	Process in the VLR	677
21.6.3	Status Reporting	677
21.6.3.1	Process in the VLR	678
21.6.3.2	Process in the HLR	679
21.6.4	CCBS: Remote User Free	679
21.6.4.1	Process in the HLR	680
21.6.3.2	Process in the VLR	680
21.7	Void	693
21.8	Void	693
21.9	Immediate Service Termination (IST)	693
21.9.1	IST Alert	693
21.9.1.1	Procedure in the MSC	693
21.9.1.2	Procedure in the HLR	693
21.9.2	IST Command	693
21.9.2.1	Procedure in the HLR	694
21.9.2.2	Procedure in the MSC	694
21.10	Resource Management	699
21.10.1	General	699
21.3.2	Process in the GMSC	699
21.3.3	Process in the VMSC	699
22	Supplementary services procedures	702
22.1	Supplementary service co-ordinator processes	702
22.1.1	Supplementary service co-ordinator process for the MSC	702
22.1.2	Void	702
22.1.3	Functional supplementary service co-ordinator process for the HLR	702
22.1.4	Call completion supplementary service co-ordinator process for the HLR	702
22.2	Registration procedure	707
22.2.1	General	707
22.2.2	Procedure in the MSC	708
22.2.3	Procedure in the VLR	708
22.2.4	Procedure in the HLR	708
22.3	Erasure procedure	714
22.3.1	General	714
22.3.2	Procedure in the MSC	715
22.3.3	Procedure in the VLR	715
22.3.4	Procedure in the HLR	715
22.4	Activation procedure	715
22.4.1	General	715
22.4.2	Procedure in the MSC	716
22.4.3	Procedure in the VLR	717
22.4.4	Procedure in the HLR	717
22.5	Deactivation procedure	723
22.5.1	General	723
22.5.2	Procedure in the MSC	724
22.5.3	Procedures in the VLR	724
22.5.4	Procedures in the HLR	724
22.6	Interrogation procedure	724
22.6.1	General	724
22.6.2	Procedure in the MSC	725
22.6.3	Procedures in the VLR	725
22.6.4	Procedure in the HLR	726
22.7	Void	730
22.8	Password registration procedure	731
22.8.1	General	731
22.8.2	Procedure in the MSC	733
22.8.3	Procedure in the VLR	733
22.8.4	Procedure in the HLR	733
22.9	Mobile Initiated USSD procedure	736
22.9.1	General	736
22.9.2	Procedure in the MSC	736
22.9.3	Procedure in the VLR	736
22.9.4	Procedure in the HLR	737
22.9.5	Procedures in the gsmSCF/secondary HLR	737
22.10	Network initiated USSD procedure	751
22.10.1	General	751
22.10.2	Procedure in the MSC	751
22.10.3	Procedure in the VLR	751
22.10.4	Procedure in the HLR	752
22.10.5	Procedure in the gsmSCF or secondary HLR	752
22.11	Common macros for clause 22	772
22.11.1	SS Password handling macros	772
22.11.2	Void	772
22.12	Supplementary Service Invocation Notification procedure	776
22.12.1	General	776
22.12.2	Procedure in the MSC	776
22.12.3	Procedure in the gsmSCF	776
22.13	Activation of a CCBS request	779
22.13.1	General	779
22.13.2	Procedure in the VLR	779
22.13.3	Procedure in the HLR	779
22.14	Deactivation of a CCBS request	782
22.14.1	General	782
22.14.2	Procedure in the VLR	782
22.14.3	Procedure in the HLR	782
23	Short message service procedures	785
23.1	General	785
23.1.1	Mobile originated short message service Co-ordinator for the MSC	785
23.1.2	Short message Gateway Co-ordinator for the HLR	785
23.2	The mobile originated short message transfer procedure	790
23.2.1	Procedure in the serving MSC	791
23.2.2	Procedure in the VLR	791
23.2.3	Procedure in the SGSN	791
23.2.4	Procedure in the SMS Interworking MSC (SMS-IWMSC)	792
23.3	The mobile terminated short message transfer procedure	804
23.3.1	Procedure in the SMS-GMSC	811
23.3.2	Procedure in the HLR	813
23.3.3	Procedure in the Serving MSC	813
23.3.4	Procedure in the VLR	814
23.3.5	Procedure in the SGSN	814
23.3.6	Procedure in the SMS Router	815
23.3.7	Procedure in the IP-SM-GW	816
23.4	The Short Message Alert procedure	862
23.4.1	Procedure in the Serving MSC – the MS has memory available	864
23.4.2	Procedures in the VLR	864
23.4.2.1	The Mobile Subscriber is present	864
23.4.2.2	The MS has memory available	864
23.4.3	Procedures in the SGSN	865
23.4.3.1	The Mobile Subscriber is present	865
23.4.3.2	The Mobile Equipment has memory available	865
23.4.4	Procedure in the HLR	865
23.4.5	Procedure in the SMS Interworking MSC	865
23.5	The SM delivery status report procedure	874
23.5.1	Procedure in the SMS-GMSC	874
23.5.2	Procedure in the HLR	874
23.5.3	Procedure in the IP-SM-GW	875
23.6	The macro Report_SM_Delivery_Stat_HLR	880
23.7	The mobile terminated short message transfer procedure for VGCS	883
23.7.1	Procedure in the SMS-GMSC	884
23.7.2	Procedure in the Anchor MSC	884
24	GPRS process description	888
24.1	Procedure for retrieval of routeing information for GPRS	889
24.1.1	Process in the GGSN	889
24.1.2	Process in the HLR	889
24.2	Procedure for reporting failure to establish a network requested PDP context	892
24.2.1	Process in the GGSN	892
24.2.2	Process in the HLR	892
24.3	Procedure for reporting that an MS has become reachable for GPRS	895
24.3.1	Process in the HLR	895
24.3.2	Process in the GGSN for Note Ms Present For Gprs	895
24A	CSE interrogation and control of subscriber data	898
24A.1	General	898
24A.2	Any Time Subscription Interrogation procedure	900
24A.2.1	General	900
24A.2.2	Process in the gsmSCF	900
24A.2.3	Process in the HLR	900
24A.3	Any Time Modification procedure	903
24A.3.1	General	903
24A.3.2	Process in the gsmSCF	903
24A.3.3	Process in the HLR	903
24A.4	Subscriber Data Modification Notification procedure	906
24A.4.1	General	906
24A.4.2	Process in the HLR	906
24A.4.3	Process in the gsmSCF	906
24A.5	Any Time Interrogation procedure	911
24A.5.1 General	911
24A.5.2	Procedures in the gsmSCF	912
24A.5.3	Procedure in the HLR	912
24A.5.4	Procedure in the GMLC	912
24B	Location Services process description	918
24B.1	Routeing information retrieval procedure for LCS	918
24B.1.1	General	918
24B.1.2	Process in the GMLC	918
24B.1.3	Process in the HLR	918
24B.2	Provide Subscriber Location procedure	921
24B.2.1	General	921
24B.2.2	Process in the GMLC	921
24B.2.3	Process in the MSC	921
24B.2.4	Process in the SGSN	921
24B.3	Subscriber Location Report procedure	925
24B.3.1	General	925
24B.3.2	Process in the MSC	925
24B.3.3	Process in the SGSN	925
24B.3.4	Process in the GMLC	925
25	General macro description	929
25.1	MAP_OPEN handling macros	929
25.1.1	Macro Receive_Open_Ind	929
25.1.2	Macro Receive_Open_Cnf	929
25.2	Macros to check the content of indication and confirmation primitives	934
25.2.1	Macro Check_Indication	934
25.2.2	Macro Check_Confirmation	934
25.3	The page and search macros	937
25.3.1	Macro PAGE_MSC	937
25.3.2	Macro Search_For_MS_MSC	937
25.4	Macros for handling an Access Request	940
25.4.1	Macro Process_Access_Request_MSC	940
25.4.2	Macro Process_Access_Request_VLR	940
25.4.3	Macro Obtain_Identity_VLR	940
25.4.4	Process Update_Location_Child_VLR	940
25.5	Authentication macros and processes	950
25.5.1	Macro Authenticate_MSC	950
25.5.2	Macro Authenticate_VLR	950
25.5.3	Macro Obtain_Authent_Params_VLR	950
25.5.4	Process Obtain_Authentication_Sets_VLR	950
25.5.5	Process Obtain_Authent_Sets_SGSN	950
25.5.6	Process Obtain_Authent_Sets_HLR	950
25.5.7	Authentication Failure Reporting	951
25.5.7.1	General	951
25.5.7.2	Process in the VLR	951
25.5.7.3	Process in the SGSN	951
25.5.7.4	Process in the HLR	951
25.6	IMEI Handling Macros	967
25.6.1	Macro Check_IMEI_MSC	967
25.6.2	Macro Check_IMEI_VLR	967
25.6.3	Process Check_IMEI_SGSN	967
25.6.4	Process Check_IMEI_EIR	967
25.6.5	Macro Obtain_IMEI_MSC	967
25.6.6	Macro Obtain_IMEI_VLR	967
25.7	Insert Subscriber Data macros and processes	976
25.7.1	Macro Insert_Subs_Data_VLR	976
25.7.2	Macro Insert_Subs_Data_SGSN	976
25.7.3	Process Insert_Subs_Data_Stand_Alone_HLR	976
25.7.4	Process Insert_GPRS_Subs_Data_Stand_Alone_HLR	976
25.7.5	Macro Wait_for_Insert_Subs_Data_Cnf	977
25.7.6	Macro Wait_for_Insert_GPRS_Subs_Data_Cnf	977
25.7.7	Process Send_Insert_Subs_Data_HLR	977
25.7.8	Process Insert_VCSG_Subs_Data_Stand_Alone_CSS	977
25.7.9	Macro Wait_for_Insert_VCSG_Subs_Data_Cnf	977
25.7.10	Process Send_Insert_VCSG_Subs_Data_CSS	977
25.8	Request IMSI Macros	991
25.8.1	Macro Obtain_IMSI_MSC	991
25.8.2	Macro Obtain_IMSI_VLR	991
25.9	Tracing macros	994
25.9.1	Macro Trace_Subscriber_Activity_MSC	994
25.9.2	Macro Trace_Subscriber_Activity_VLR	994
25.9.3	Macro Trace_Subscriber_Activity_SGSN	994
25.9.4	Macro Activate_Tracing_VLR	994
25.9.5	Macro Activate_Tracing_SGSN	994
25.9.6	Macro Control_Tracing_With_VLR_HLR	994
25.9.7	Macro Control_Tracing_With_SGSN_HLR	994
25.10	Short Message Alert procedures	1002
25.10.1	Process Subscriber_Present_VLR	1002
25.10.2	Process SubscriberPresent_SGSN	1002
25.10.3	Macro Alert_Service_Centre_HLR	1002
25.10.4	Process Alert_SC_HLR	1002
Annex A (informative):	ASN.1 Cross-reference listing and fully expanded sources	1006
Annex B (informative):	Void	1007
Annex C (informative):	 Message Segmentation Mechanisms	1008
C.1	SCCP segmentation	1008
C.2	TCAP segmentation	1008
C.2.1	Empty Begin	1008
C.2.2	Empty Continue	1008
C.2.3	TC-Result-NL	1008
C.3	MAP Segmentation	1009
C.3.1	Invoke without explicit indication	1009
C.3.2	Invoke with explicit indication	1009
C.3.3	Result	1009
Annex D (informative):	Void	1014
Annex E (informative):	Change History	1015

Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x	the first digit:
1	presented to TSG for information;
2	presented to TSG for approval;
3	or greater indicates TSG approved document under change control.
y	the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc.
z	the third digit is incremented when editorial only changes have been incorporated in the document.
In the present document, modal verbs have the following meanings:
shall	indicates a mandatory requirement to do something
shall not	indicates an interdiction (prohibition) to do something
The constructions "shall" and "shall not" are confined to the context of normative provisions, and do not appear in Technical Reports.
The constructions "must" and "must not" are not used as substitutes for "shall" and "shall not". Their use is avoided insofar as possible, and they are not used in a normative context except in a direct citation from an external, referenced, non-3GPP document, or so as to maintain continuity of style when extending or modifying the provisions of such a referenced document.
should	indicates a recommendation to do something
should not	indicates a recommendation not to do something
may	indicates permission to do something
need not	indicates permission not to do something
The construction "may not" is ambiguous and is not used in normative elements. The unambiguous constructions "might not" or "shall not" are used instead, depending upon the meaning intended.
can	indicates that something is possible
cannot	indicates that something is impossible
The constructions "can" and "cannot" are not substitutes for "may" and "need not".
will	indicates that something is certain or expected to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document
will not	indicates that something is certain or expected not to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document
might	indicates a likelihood that something will happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document
might not	indicates a likelihood that something will not happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document
In addition:
is	(or any other verb in the indicative mood) indicates a statement of fact
is not	(or any other negative verb in the indicative mood) indicates a statement of fact
The constructions "is" and "is not" do not indicate requirements.
1	Scope
It is necessary to transfer between entities of a Public Land Mobile Network (PLMN) information specific to the PLMN in order to deal with the specific behaviour of roaming Mobile Stations (MS)s. The Signalling System No. 7 specified by CCITT is used to transfer this information.
The present document describes the requirements for the signalling system and the procedures needed at the application level in order to fulfil these signalling needs.
Clauses 1 to 6 are related to general aspects such as terminology, mobile network configuration and other protocols required by MAP.
MAP consists of a set of MAP services that are provided to MAP service-users by a MAP service-provider.

Figure 1.1/1: Modelling principles
Clauses 7 to 13A of the present document describe the MAP services.
Clauses 14 to 17 define the MAP protocol specification and the behaviour of service provider (protocol elements to be used to provide MAP services, mapping on to TC service primitives, abstract syntaxes, etc.).
Clauses 18 to 25 describe the MAP user procedures that make use of MAP services.
The present document specifies functions, procedures and information which apply to GERAN Iu mode. However, functionality related to GERAN Iu mode is neither maintained nor enhanced.
2	References
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
-	References are either specific (identified by date of publication, edition number, version number, etc.) or non‑specific.
-	For a specific reference, subsequent revisions do not apply.
-	For a non-specific reference, the latest version applies.  In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]	3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2]	3GPP TS 22.001: "Digital cellular telecommunications system (Phase 2+); Principles of telecommunication services supported by a Public Land Mobile Network (PLMN)".
[3]	3GPP TS 22.002: "Bearer Services Supported by a Public Land Mobile Network (PLMN)".
[4]	3GPP TS 22.003: "Circuit Teleservices Supported by a Public Land Mobile Network (PLMN)".
[5]	3GPP TS 22.004: "General on Supplementary Services".
[6]	3GPP TS 42.009: "Digital cellular telecommunications system (Phase 2+); Security aspects".
[7]	3GPP TS 22.016: "International Mobile station Equipment Identities (IMEI)".
[8]	3GPP TS 22.041: "Operator Determined Barring".
[9]	3GPP TS 22.081: "Line identification supplementary services - Stage 1".
[10]	3GPP TS 22.082: "Call Forwarding (CF) supplementary services - Stage 1".
[11]	3GPP TS 22.083: "Call Waiting (CW) and Call Hold (HOLD) Supplementary Services - Stage 1".
[12]	3GPP TS 22.084: "Multi Party (MPTY) Supplementary Services - Stage 1".
[13]	3GPP TS 22.085: "Closed User Group (CUG) supplementary services - Stage 1".
[14]	3GPP TS 22.086: "Advice of charge (AoC) Supplementary Services - Stage 1".
[15]	3GPP TS 22.088: "Call Barring (CB) supplementary services - Stage 1".
[16]	3GPP TS 22.090: "Unstructured Supplementary Service Data (USSD); - Stage 1".
[17]	3GPP TS 23.003: "Numbering, addressing and identification".
[18]	Void
[19]	3GPP TS 23.007: "Restoration procedures".
[20]	3GPP TS 23.008: "Organisation of subscriber data".
[21]	3GPP TS 23.009: "Handover procedures".
[22]	3GPP TS 23.011: "Technical realization of Supplementary Services - General Aspects".
[23]	3GPP TS 23.012: "Location management procedures".
[24]	3GPP TS 43.020: "Security related network functions".
[25]	3GPP TS 23.038: "Alphabets and language".
[25a]	3GPP TS 23.039: "Interface protocols for the connection of Short Message Service Centres (SMSCs) to Short Message Entities (SMEs)".
[26]	3GPP TS 23.040: "Technical realization of the Short Message Service (SMS) Point to Point (PP)".
[26a]	3GPP TS 23.271: "Functional stage2 description of LCS".
[27]	3GPP TS 23.081: "Line Identification Supplementary Services - Stage 2".
[28]	3GPP TS 23.082: "Call Forwarding (CF) Supplementary Services - Stage 2".
[29]	3GPP TS 23.083: "Call Waiting (CW) and Call Hold (HOLD) Supplementary Services - Stage 2".
[30]	3GPP TS 23.084: "Multi Party (MPTY) Supplementary Services - Stage 2".
[31]	3GPP TS 23.085: "Closed User Group (CUG) Supplementary Services - Stage 2".
[32]	3GPP TS 23.086: "Advice of Charge (AoC) Supplementary Services - Stage 2".
[33]	3GPP TS 23.088: "Call Barring (CB) Supplementary Services - Stage 2".
[34]	3GPP TS 23.090: "Unstructured Supplementary Services Data (USSD) - Stage 2".
[34a]	3GPP TS 33.204: "3G Security; Network domain security; TCAP user  security".
 [35]	3GPP TS 24.008: "Mobile Radio Interface Layer 3 specification; Core Network Protocols - Stage 3".
[36]	3GPP TS 24.010: "Mobile radio interface layer 3 Supplementary Services specification - General aspects".
[37]	3GPP TS 24.011: "Point-to-Point (PP) Short Message Service (SMS) support on mobile radio interface".
[37a]	3GPP TS 44.071: "Location Services (LCS) – stage 3".
[38]	3GPP TS 24.080: "Mobile radio interface layer 3 supplementary services specification - Formats and coding".
[39]	3GPP TS 24.081: "Line identification supplementary services - Stage 3".
[40]	3GPP TS 24.082: "Call Forwarding (CF) Supplementary Services - Stage 3".
[41]	3GPP TS 24.083: "Call Waiting (CW) and Call Hold (HOLD) supplementary services - Stage 3".
[42]	3GPP TS 24.084: "Multi Party (MPTY) Supplementary Services - Stage 3".
[43]	3GPP TS 24.085: "Closed User Group (CUG) Supplementary Services - Stage 3".
[44]	3GPP TS 24.086: "Advice of Charge (AoC) Supplementary Services - Stage 3".
[45]	3GPP TS 24.088: "Call Barring (CB) Supplementary Services - Stage 3".
[46]	3GPP TS 24.090: "Unstructured Supplementary Services Data - Stage 3".
[47]	3GPP TS 48.002: " Base Station System - Mobile-services Switching Centre (BSS - MSC) interface principles".
[48]	3GPP TS 48.006: "Signalling transport mechanism specification for the Base Station System - Mobile-services Switching Centre (BSS - MSC) interface".
[49]	3GPP TS 48.008: "Mobile Switching Centre - Base Station System (MSC - BSS) interface; Layer 3 specification".
 [49a1]	3GPP TS 48.031: "Location Services (LCS); Serving Mobile Location Centre (SMLC) – Serving Mobile Location Centre (SMLC); SMLC Peer Protocol (SMLCPP)".
[49b]	3GPP TS 48.071: "Location Services (LCS); Serving Mobile Location Centre - Base Station System (SMLC - BSS) interface Layer 3 specification".
[50]	3GPP TS 49.001: "General network interworking scenarios".
[51]	3GPP TS 29.002: "Mobile Application Part (MAP) specification".
[52]	Void
[53]	Void
[54]	Void
[55]	3GPP TS 29.006: "Interworking between a Public Land Mobile Network (PLMN) and a Packet Switched Public Data Network/Integrated Services Digital Network (PSPDN/ISDN) for the support of Packet Switched data transmission services".
[56]	3GPP TS 29.007: "General requirements on interworking between the Public Land Mobile Network (PLMN) and the Integrated Services Digital Network (ISDN) or Public Switched Telephone Network (PSTN)".
[57]	3GPP TS 29.008: "Application of the Base Station System Application Part (BSSAP) on the E-interface".
[58]	3GPP TS 29.010: "Information element mapping between Mobile Station - Base Station System and BSS ‑ Mobile-services Switching Centre (MS - BSS - MSC) Signalling procedures and the Mobile Application Part (MAP)".
[59]	3GPP TS 29.011: "Signalling interworking for Supplementary Services".
[59a]	3GPP TS 49.031: "Digital cellular telecommunications system (Phase 2+); Location Services (LCS); Base Station System Application Part LCS Extension (BSSAP-LE)".
[60]	Void
[61]	3GPP TS 52.008: "GSM Subscriber and Equipment Trace".
[62]	ETS 300 102-1 (1990): "Integrated Services Digital Network (ISDN); User-network interface layer 3 specifications for basic call control".
[63]	ETS 300 136 (1992): "Integrated Services Digital Network (ISDN); Closed User Group (CUG) supplementary service description".
[64]	ETS 300 138 (1992): "Integrated Services Digital Network (ISDN); Closed User Group (CUG) supplementary service Digital Subscriber Signalling System No.one (DSS1) protocol".
[65]	ETS 300 287: "Integrated Services Digital Network (ISDN); Signalling System No.7; Transaction Capabilities (TC) version 2".
[66]	ETR 060: "Signalling Protocols and Switching (SPS); Guide-lines for using Abstract Syntax Notation One (ASN.1) in telecommunication application protocols".
[66b]	ETR 091: "ETSI object identifier tree; Common domain Mobile domain"
[67]	ITU-T Recommendation E.164: "The international public telecommunication numbering plan".
[68]	ITU-T Recommendation E.212: "The international identification plan for mobile terminals and mobile users".
[69]	ITU-T Recommendation E.213: "Telephone and ISDN numbering plan for land mobile stations in public land mobile networks (PLMN) ".
[70]	ITU-T Recommendation E.214: "Structure of the land mobile global title for the signalling connection control part (SCCP) ".
[71]	ITU-T Recommendation Q.699: "Interworking between ISDN access and non-ISDN access over ISDN User Part of Signalling System No. 7 ".
[72]	ITU-T Recommendation Q.711: "Specifications of Signalling System No.7; Functional description of the Signalling Connection Control Part".
[73]	ITU-T Recommendation Q.712: "Definition and function of SCCP messages".
[74]	ITU-T Recommendation Q.713: "Specifications of Signalling System No.7; SCCP formats and codes".
[75]	ITU-T Recommendation Q.714: "Specifications of Signalling System No.7; Signalling Connection Control Part procedures".
[76]	ITU-T Recommendation Q.716: "Specifications of Signalling System No.7; Signalling connection control part (SCCP) performances".
[77]	ITU-T Recommendation Q.721 (1988): "Specifications of Signalling System No.7; Functional description of the Signalling System No.7 Telephone user part".
[78]	ITU-T Recommendation Q.722 (1988): "Specifications of Signalling System No.7; General function of Telephone messages and signals".
[79]	ITU-T Recommendation Q.723 (1988): "Specifications of Signalling System No.7; Formats and codes".
[80]	ITU-T Recommendation Q.724 (1988): "Specifications of Signalling System No.7; Signalling procedures".
[81]	ITU-T Recommendation Q.725 (1988): "Specifications of Signalling System No.7; Signalling performance in the telephone application".
[82]	ITU-T Recommendation Q.761 (1988): "Specifications of Signalling System No.7; Functional description of the ISDN user part of Signalling System No.7".
[83]	ITU-T Recommendation Q.762 (1988): "Specifications of Signalling System No.7; General function of messages and signals".
[84]	ITU-T Recommendation Q.763 (1988): "Specifications of Signalling System No.7; Formats and codes".
[85]	ITU-T Recommendation Q.764 (1988): "Specifications of Signalling System No.7; Signalling procedures".
[86]	ITU-T Recommendation Q.767: "Specifications of Signalling System No.7; Application of the ISDN user part of CCITT signalling System No.7 for international ISDN interconnections".
[87]	ITU-T Recommendation Q.771: "Specifications of Signalling System No.7; Functional description of transaction capabilities".
[88]	ITU-T Recommendation Q.772: "Specifications of Signalling System No.7; Transaction capabilities information element definitions".
[89]	ITU-T Recommendation Q.773: "Specifications of Signalling System No.7; Transaction capabilities formats and encoding".
[90]	ITU-T Recommendation Q.774: "Specifications of Signalling System No.7; Transaction capabilities procedures".
[91]	ITU-T Recommendation Q.775: "Specifications of Signalling System No.7; Guide-lines for using transaction capabilities".
[92]	ITU-T Recommendation X.200: "Reference Model of Open systems interconnection for CCITT Applications".
[93]	ITU-T Recommendation  X.680: "Information technology  –  Abstract Syntax Notation One (ASN.1): Specification of basic notation".
[93b]	ITU-T Recommendation X.681: "Information technology  –  Abstract Syntax Notation One (ASN.1): Information object specification".
[94]	ITU-T Recommendation X.690: "Information technology  –  ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)".
[95]	ITU-T Recommendation X.210: "Open systems interconnection layer service definition conventions".
[97]	3GPP TS 23.018: "Basic Call Handling".
[98]	3GPP TS 23.078: "Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase 4 - Stage 2".
[99]	3GPP TS 23.079: "Support of Optimal Routeing (SOR) - Stage 2".
[100]	3GPP TS 43.068: "Voice Group Call Service (VGCS) - Stage 2".
[101]	3GPP TS 43.069: "Voice Broadcast service (VBS) - Stage 2".
[102]	ANSI T1.113: "Signaling System No. 7 (SS7) - ISDN User Part".
[103]	Void
[104]	3GPP TS 23.060: "General Packet Radio Service (GPRS) Service description; Stage 2".
[105]	3GPP TS 29.060: "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface".
[106]	3GPP TS 29.018: "General Packet Radio Service (GPRS); Serving GPRS Support Node (SGSN) - Visitors Location Register (VLR); Gs interface layer 3 specification".
[107]	3GPP TS 23.093: "Technical Realization of Completion of Calls to Busy Subscriber (CCBS); Stage 2".
[108]	3GPP TS 23.066: "Support of Mobile Number Portability (MNP); Technical Realisation Stage 2".
[109]	ANSI T1.112 (1996): "Telecommunication – Signalling No. 7 - Signaling Connection Control Part (SCCP)".
[110]	3GPP TS 23.116: "Super-Charger Technical Realisation; Stage 2.".
[111]	Void.
[112]	Void 
[113]	Void
[114]	Void
[115]	Void
[116]	ITU-T Recommendation Q.850 (May 1998): "Usage of cause and location in the Digital Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN User Part".
[117]	3GPP TS 22.135: "Multicall; Service description; Stage 1".
[118]	3GPP TS 23.135: "Multicall supplementary service; Stage 2".
[119]	3GPP TS 24.135: "Multicall supplementary service; Stage 3".
[120]	3GPP TS 25.413: "UTRAN Iu interface Radio Access Network Application Part (RANAP) signalling".
[121]	3GPP TS 29.202: "SS7 signalling transport in core network".
[122]	3GPP TS 23.032: "Universal Geographical Area Description (GAD)".
[123]	3GPP TS 22.071: "Location Services (LCS); Service description, Stage 1".
[124]	ITU-T Recommendation X.880: "Data networks and open system communication - Open System Interconnection - Service definitions - Remote operations: Concepts, model and notation".
[125]	3GPP TS 23.278: "Customised Applications for Mobile Network Enhanced Logic (CAMEL)  Phase 4 – Stage 2 IM CN Interworking (Rel-5)".
[126]	3GPP TS 23.172: "Technical realization of Circuit Switched (CS) multimedia service; UDI/RDI fallback and service modification".
[127]	3GPP TS 26.103: "Speech codec list for GSM and UMTS".
[128]	3GPP TS 23.141: "Presence Service; Architecture and Functional Description".
[129]	3GPP TS 23.094: "Follow Me (FM) – Stage 2".
[130]	Void
[131]	3GPP TS 32.421: "Subscriber and equipment trace: Trace concepts and requirements".
[132]	3GPP TS 32.422: "Subscriber and equipment trace; Trace control and Configuration Management".
[133]	3GPP TS 23.236: "Intra-domain connection of Radio Access Network (RAN) nodes to multiple Core Network (CN) nodes".
[134]	3GPP TS 23.204: "Support of Short Message Service (SMS) 
over generic 3GPP Internet Protocol (IP) access".
[135]	3GPP TS 23.292: "IP Multimedia Subsystem (IMS) Centralized Services".
[136]	3GPP TS 23.067: "enhanced Multi-Level Precedence and Pre-emption service (eMLPP) - Stage 2".
[137]	3GPP TS 24.067: "Enhanced Multi-Level Precedence and Pre-emption service (eMLPP); Stage 3".
[138]	3GPP TS 22.011: "Service accessibility".
[139]	IETF RFC 3588: "Diameter Base Protocol".
[140]	Void
[141]	3GPP TS 29.173: "Locations Services; Diameter-based SLh interface for Control Plane LCS".
[142]	Void
[143]	3GPP TS 23.272: "Circuit Switched (CS) fallback in Evolved Packet System (EPS); Stage 2".
[144]	3GPP TS 29.272: "Evolved Packet System (EPS); Mobility Management Entity (MME) and Service GPRS Support Node (SGSN) related interfaces based on Diameter protocol".
[145]	3GPP TS 23.401: "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access".
[146]	3GPP TS 29.205: "Application of Q.1900 series to bearer independent Circuit Switched (CS) core network architecture; Stage 3".
[147]	3GPP TS 36.413: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)".
[148]	3GPP TS 23.682: "Architecture enhancements to facilitate communications with packet data networks and applications".
[149]	3GPP TS 29.274: "3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C)". 
[150]	3GPP TS 23.380: "IMS Restoration Procedures".
[151]	3GPP TS 29.273: "Evolved Packet System (EPS); 3GPP EPS AAA interfaces".
[152]	3GPP TS 29.118: "Mobility Management Entity (MME) - Visitor Location Register (VLR) SGs interface specification".
[153]	3GPP TS 38.413: "NG-RAN; NG Application Protocol (NGAP)".

3	Abbreviations
ADD	Automatic Device Detection 
GANSS	Galileo and Additional Navigation Satellite Systems
All other abbreviations used in the present document are listed in 3GPP TS 21.905.
4	Void
5	Overload and compatibility overview
5.1	Overload control
There is a requirement for an overload/congestion control for all entities of the Public Land Mobile Network and the underlying Signalling System No. 7.
5.1.1	Overload control for MSC (outside MAP)
For the entity MSC the following two procedures (outside MAP) may be applied to control the processor load:
-	ISDN
CCITT Recommendation Q.764 (Automatic Congestion Control), applicable to reduce the mobile terminating traffic;
-	BSSAP
3GPP TS 48.008 [49] (A-interface Flow Control), applicable to reduce the mobile originating traffic.
5.1.2	Overload control for MAP entities
For all MAP entities, especially the HLR, the following overload control method is applied.
If overload of a MAP entity is detected requests for certain MAP operations (see tables 5.1/1, 5.1/2, 5.1/3 and 5.1/4) may be ignored by the responder. The decision as to which MAP Operations may be ignored is made by the MAP service provider and is based upon the priority of the application context.
Since most of the affected MAP operations are supervised in the originating entity by TC timers (medium) an additional delay effect is achieved for the incoming traffic.
If overload levels are applicable in the Location Registers the MAP operations should be discarded taking into account the priority of their application context (see table 5.1/1 for HLR, table 5.1/2 for MSC/VLR, table 5.1/3 for the SGSN and table 5.1/4 for the SMLC; the lowest priority is discarded first).
The ranking of priorities given in the tables 5.1/1, 5.1/2, 5.1/3 and 5.1/4 is not normative. The tables can only be seen as a proposal that might be changed due to network operator/implementation matters.
Table 5.1/1: Priorities of Application Contexts for HLR as Responder
	Responder = HLR	Initiating Entity
Priority high
	Mobility Management
	networkLocUp	VLR
	(updateLocation),
	(restoreData/v2),
	(sendParameters/v1)
	gprsLocationUpdate	SGSN
	(updateGPRSLocation/v3),
	infoRetrieval	VLR/SGSN 
	(sendAuthenticationInfo/v2/v3),
	(sendParameters/v1)
	istAlerting	MSC
	(istAlert/v3)	msPurging	VLR 
	(purgeMS/v2/v3)
	msPurging	SGSN 
	(purgeMS/v3)
	Short Message Service
	shortMsgGateway	GMSC
	(sendRoutingInfoforSM),
	(reportSM-DeliveryStatus)
	mwdMngt	VLR/SGSN 
	(readyForSM/v2/v3),
	(noteSubscriberPresent/v1)
	Mobile Terminating Traffic
	locInfoRetrieval	GMSC
	(sendRoutingInfo)
	anyTimeEnquiry	gsmSCF
	(anyTimeInterrogation/v3)
	reporting	VLR
	(statusReport)
	Location Services
	locationSvcGateway	GMLC
	(sendRoutingInfoforLCS/v3)
	Subscriber Controlled Inputs (Supplementary Services)
	networkFunctionalSs	VLR
	(registerSS),
	(eraseSS),
	(activateSS),
	(deactivateSS),
	(interrogateSS),
	(registerPassword),
	(processUnstructuredSS-Data/v1),
	(beginSubscriberActivity/v1)
	callCompletion	VLR
	(registerCCEntry),
	(eraseCCEntry)
	networkUnstructuredSs	VLR
	(processUnstructuredSS-Request/v2)
	imsiRetrieval	VLR
	(sendIMSI/v2)
	gprsLocationInfoRetrieval	GGSN/SGSN
	(sendRoutingInfoForGprs/v3/v4)
	failureReport	GGSN/SGSN
	(failureReport/v3)
	authenticationFailureReport	VLR/SGSN
	(authenticationFailureReport/v3)
Priority low
NOTE:	The application context name is the last component but one of the object identifier.
Operation names are given in brackets for information with "/vn" appended to vn only operations.
Table 5.1/3: Priorities of Application Contexts for SGSN as Responder
	Responder = SGSN	Initiating Entity
Priority high
	Mobility and Location Register Management
	locationCancel	HLR
	(cancelLocation v3)
	reset	HLR
	(reset)
	subscriberDataMngt	HLR
	(insertSubscriberData v3),
	(deleteSubscriberData v3)
	tracing	HLR
	(activateTraceMode),
	(deactivateTraceMode)

	Short Message Service
	shortMsgMT-Relay	MSC
	(MT-ForwardSM v3),
	(forwardSM v1/v2)

	Location Services

	locationSvcEnquiry	GMLC
	(provideSubscriberLocation v3)

	Network-Requested PDP context activation
	gprsNotify	HLR
	(noteMsPresentForGprs v3),

	(Subscriber Location & State retrieval)
	subscriberInfoEnquiry	HLR
	(provideSubscriberInformation/v3)

Priority low
NOTE:	The application context name is the last component but one of the object identifier.
Operation names are given in brackets for information with "/vn" appended to vn.
Table 5.1/2: Priorities of Application Contexts for MSC/VLR as Responder

NOTE:	The application context name is the last component but one of the object identifier.
Operation names are given in brackets for information with "/vn" appended to vn only operations.
5.1.3	Congestion control for Signalling System No. 7
The requirements of SS7 Congestion control have to be taken into account as far as possible.
Means that could be applied to achieve the required traffic reductions are described in clauses 5.1.1 and 5.1.2.
5.2	Compatibility
5.2.1	General
The present document of the Mobile Application Part is designed in such a way that an implementation which conforms to it can also conform to the Mobile Application Part operational version 1 specifications, except on the MSC-VLR interface.
A version negotiation mechanism based on the use of an application-context-name is used to negotiate the protocol version used between two entities for supporting a MAP-user signalling procedure.
When starting a signalling procedure, the MAP-user supplies an application-context-name to the MAP-provider. This name refers to the set of application layer communication capabilities required for this dialogue. This refers to the required TC facilities (e.g. version 1 or 2) and the list of operation packages (i.e. set of operations) from which operations can be invoked during the dialogue.
A version one application-context-name may only be transferred to the peer user in a MAP-U-ABORT to an entity of version two or higher (i.e. to trigger a dialogue which involves only communication capabilities defined for MAP operational version 1).
If the proposed application-context-name can be supported by the responding entity the dialogue continues on this basis otherwise the dialogue is refused and the initiating user needs to start a new dialogue, which involves another application-context-name which requires less communication capabilities but provides similar functionality (if possible).
When a signalling procedure can be supported by several application contexts that differ by their version number, the MAP-User needs to select a name. It can either select the name that corresponds to the highest version it supports or follow a more specific strategy so that the number of protocol fallbacks due to version compatibility problems is minimised.
5.2.2	Strategy for selecting the Application Context (AC) version
A method should be used to minimise the number of protocol fall-backs which would occur sometimes if the highest supported AC-Name were always the one selected by GSM entities when initiating a dialogue. The following method is an example that can be used mainly at transitory phase stage when the network is one of mixed phase entities.
5.2.2.1	Proposed method
A table (table 1) may be set up by administrative action to define the highest application context (AC) version supported by each destination; a destination may be another node within the same or a different PLMN, or another PLMN considered as a single entity. The destination may be defined by an E.164 number or an E.214 number derived from an IMSI or in North America (World Zone 1) by an E.164 number or an IMSI (E.212 number). The table also includes the date when each destination is expected to be able to handle at least one AC of the latest version of the MAP protocol. When this date is reached, the application context supported by the node is marked as "unknown", which will trigger the use of table 2.
A second table (table 2) contains an entry for each destination that has an entry in table 1. For a given entity, the entry in table 2 may be a single application context version or a vector of different versions applying to different application contexts for that entity. Table 2 is managed as described in clause 5.2.2.2.
The data for each destination will go through the following states:
a)	the version shown in table 1 is "version n-1", where 'n' is the highest version existing in this specification; table 2 is not used;
b)	the version shown in table 1 is "unknown"; table 2 is used, and maintained as described in clause 5.2.2.2;
c)	when the PLMN operator declares that an entity (single node or entire PLMN) has been upgraded to support all the MAP version n ACs defined for the relevant interface, the version shown in table 1 is set to "version n" by administrative action; table 2 is no longer used, and the storage space may be recovered.
5.2.2.2	Managing the version look-up table
WHEN it receives a MAP-OPEN ind the MAP-User determines the originating entity number either using the originating address parameter or the originating reference parameter or retrieving it from the subscriber data using the IMSI or the MSISDN.
IF the entity number is known:
THEN
	It updates (if required) the associated list of highest supported ACs.
ELSE
	It creates an entry for this entity and includes the received AC-name in the list of highest supported ACs.
WHEN starting a procedure, the originating MAP-user looks up its version control table.
IF the destination address is known and not timed-out.
THEN
It retrieves the appropriate AC-name and uses it
IF the dialogue is accepted by the peer
THEN
It does not modify the version control table
ELSE (this should never occur)
	It starts a new dialogue with the common highest version supported (based on information implicitly or explicitly provided by the peer).
	It replaces the old AC-name by the new one in the list of associated highest AC supported.
ELSE
	It uses the AC-name that corresponds to the highest version it supports.
IF the dialogue is accepted by the peer.
THEN
	It adds the destination node in its version control table and includes the AC-Name in the list of associated highest AC supported.
ELSE
	It starts a new dialogue with the common highest version supported (based on information implicitly or explicitly provided by the peer).
IF the destination node was not known
THEN
	It adds the destination node in its version control table and includes the new AC-Name in the list of associated highest AC supported.
ELSE
	It replaces the old AC-name by the new one in the list of highest supported AC and reset the timer.
5.2.2.3	Optimising the method
A table look-up may be avoided in some cases if both the HLR and the VLR or both the HLR and the SGSN store for each subscriber the version of the AC-name used at location updating. Then:
-	for procedures which make use of the same application-context, the same AC-name (thus the same version) can be selected (without any table look-up) when the procedure is triggered;
-	for procedures which make use of a different application-context but which includes one of the packages used by the location updating AC, the same version can be selected (without any table look-up) when the procedure is triggered;
for HLR:
-	Subscriber data modification (stand alone);
for VLR:
-	Data Restoration.
6	Requirements concerning the use of SCCP and TC
6.1	Use of SCCP
The Mobile Application Part (MAP) makes use of the services offered by the Signalling Connection Control Part (SCCP).
MAP supports the following SCCP versions:
-	Signalling Connection Control Part, Signalling System no. 7 CCITT ('Blue Book SCCP');
-	Signalling Connection Control Part, Signalling System no. 7 ITU-T Recommendation (07/96) Q.711 to Q.716 ('White Book SCCP'). Support of White Book SCCP at the receiving side shall be mandated from 00:01hrs, 1st July 2002(UTC). However, for signalling over the MAP E-interface to support inter-MSC handover/relocation, the support of White Book SCCP shall be mandated with immediate effect.
A White Book SCCP message will fail if any signalling point used in the transfer of the message does not support White Book SCCP. Therefore it is recommended that the originator of the White Book SCCP message supports a drop back mechanism or route capability determination mechanism to interwork with signalling points that are beyond the control of GSM/UMTS network operators.
In North America (World Zone 1) the national version of SCCP is used as specified in ANSI T1.112. Interworking between a PLMN in North America and a PLMN outside North America will involve an STP to translate between ANSI SCCP and ITU-T/CCITT SCCP.
The SCCP is identified as an MTP3-user and the transport of SCCP messages between two entities shall be accomplished according to the 3GPP TS 29.202 [121].
6.1.1	SCCP Class
MAP will only make use of the connectionless classes (0 or 1) of the SCCP.
6.1.2	Sub-System Number (SSN)
The Application Entities (AEs) defined for MAP consist of several Application Service Elements (ASEs) and are addressed by sub-system numbers (SSNs). The SSNs for MAP are specified in 3GPP TS 23.003 [17].
When the SGSN emulates MSC behaviour for processing messages (MAP-MO-FORWARD-SHORT-MESSAGE, MAP_CHECK_IMEI, MAP_SUBSCRIBER_LOCATION_REPORT) towards entities which do not support interworking to SGSNs, it shall use the MSC SSN in the calling party address instead of the SGSN SSN. 
When present in the network, the Presence Network Agent emulates the behaviour of the GSM Service Control Function (gsm SCF) for processing of messages (MAP-NOTE-MM-EVENT, MAP-ANY-TIME-INTERROGATION and MAP-ANY-TIME-MODIFICATION).
When a FFN (Follow Me Functional Node, see TS 23.094 [129]) is implemented in a network entity different from HLR, this network entity shall emulate HLR behaviour, i.e. it shall accept MAP-PROCESS-UNSTRUCTURED-SS-REQUEST messages addressed with SSN for HLR.
In an EPS, an Interworking Function (IWF) may be used to convert Diameter S6a messages to MAP Gr messages and vice versa; also an IWF may be used to convert Diameter S13 messages to MAP Gf messages and vice versa. An SSN value for the IWF does not exist. Instead the IWF shall use the SGSN SSN value when serving an MME and use the HLR SSN when serving an HSS. An IWF is said to serve an MME (or HSS) when Diameter messages are exchanged between the IWF and the MME (or HSS).

6.1.3	SCCP addressing
6.1.3.1	Introduction
Within the GSM System there will be a need to communicate between entities within the same PLMN and in different PLMNs. Using the Mobile Application Part (MAP) for this function implies the use of Transaction Capabilities (TC) and the Signalling Connection Control Part (SCCP) of CCITT Signalling System No. 7.
Only the entities that should be addressed are described below. If the CCITT or ITU-T SCCP is used, the format and coding of address parameters carried by the SCCP for that purpose shall comply with CCITT Recommendation Q.713 with the following restrictions:
1)	Intra-PLMN addressing
	For communication between entities within the same PLMN, a MAP SSN shall always be included in the called and calling party addresses. All other aspects of SCCP addressing are network specific.
2)	Inter-PLMN addressing
a)	Called Party Address
-	SSN indicator = 1 (MAP SSN always included);
-	Global title indicator = 0100 (Global title includes translation type, numbering plan, encoding scheme and nature of address indicator);
-	the translation type field will be coded "00000000" (Not used). For call related messages for non-optimal routed calls (as described in 3GPP TS 23.066 [108]) directed to another PLMN the translation type field may be coded "10000000" (CRMNP);
-	Routing indicator = 0 (Routing on global title);
b)	Calling Party Address
-	SSN indicator = 1 (MAP SSNs always included);
-	Point code indicator = 0;
-	Global title indicator = 0100 (Global title includes translation type, numbering plan, encoding scheme and nature of address indicator);
-	Numbering Plan = 0001 (ISDN Numbering Plan, E.164; In Case of Inter-PLMN Signalling, the dialogue initiating entity and dialogue responding entity shall always include its own E.164 Global Title as Calling Party Address);
-	the translation type field will be coded "00000000" (Not used);
-	Routing indicator = 0 (Routing on Global Title).
If ANSI T1.112 SCCP is used, the format and coding of address parameters carried by the SCCP for that purpose shall comply with ANSI specification T1.112 with the following restrictions:
1)	Intra-PLMN addressing
	For communication between entities within the same PLMN, a MAP SSN shall always be included in the called and calling party addresses. All other aspects of SCCP addressing are network specific.
2)	Inter-PLMN addressing
a)	Called Party Address
-	SSN indicator = 1 (MAP SSN always included);
-	Global title indicator = 0010 (Global title includes translation type);
-	the Translation Type (TT) field will be coded as follows:
	TT = 9, if IMSI is included;
	TT = 14, if MSISDN is included;
	Or TT = 10, if Network Element is included. (If TT=10, then Number Portability GTT is not invoked, if TT=14, then Number Portability GTT may be invoked).
-	Routing indicator = 0 (Routing on global title);
b)	Calling Party Address
-	SSN indicator = 1 (MAP SSNs always included);
-	Point code indicator = 0;
-	Global Title indicator = 0010 (Global title includes translation type);
	TT = 9, if IMSI is included;
	TT = 14, if MSISDN is included;
	Or TT = 10, if Network Element is included. (If TT=10, then Number Portability GTT is not invoked, if TT=14, then Number Portability GTT may be invoked).
Routing indicator = 0 (Routing on Global Title).
If a Global Title translation is required for obtaining routeing information, one of the numbering plans E.164, E.212 and E.214 is applicable.
-	E.212 numbering plan.
	When CCITT or ITU-T SCCP is used, an E.212 number must not be included as Global Title in an SCCP UNITDATA message. The translation of an E.212 number into a Mobile Global Title is applicable in a dialogue initiating VLR, SGSN or GGSN if the routeing information towards the HLR is derived from the subscriber's IMSI. In World Zone 1 when ANSI SCCP is used, the IMSI (E.212 number) is used as a Global Title to address the HLR. When an MS moves from one VLR service area to another, the new VLR may derive the address of the previous VLR from the Location Area Identification provided by the MS in the location registration request. The PLMN where the previous VLR is located is identified by the E.212 numbering plan elements of the Location Area Identification, i.e. the Mobile Country Code (MCC) and the Mobile Network Code (MNC).
-	E.214 and E.164 numbering plans.
	When CCITT or ITU-T SCCP is used, only address information belonging to either E.214 or E.164 numbering plan is allowed to be included as Global Title in the Called and Calling Party Address. In World Zone 1 when ANSI SCCP is used, the IMSI (E.212 number) is used as a Global Title to address the HLR.
	If the Calling Party Address associated with the dialogue initiating message contains a Global Title, the sending network entity shall include its E.164 entity number.
	When receiving an SCCP UNITDATA message, SCCP shall accept either of the valid numbering plans in the Called Party Address and in the Calling Party Address.
	When CCITT or ITU-T SCCP is used and an N-UNITDATA-REQUEST primitive from TC is received, SCCP shall accept an E.164 number or an E.214 number in the Called Address and in the Calling Address. In World Zone 1 when ANSI SCCP is used, the IMSI (E.212 number) is used instead of E.214 number.
The following clauses describe the method of SCCP addressing appropriate for each entity both for the simple intra‑PLMN case and where an inter-PLMN communication is required. The following entities are considered:
-	the Mobile-services Switching Centre (MSC);
-	the Home location Register (HLR);
-	the Visitor Location Register (VLR);
-	the Gateway Mobile-services Switching Centre (GMSC);
-	the GSM Service Control Function (gsmSCF);
-	the Interworking Mobile-services Switching Centre (IWMSC);
-	the Serving GPRS Support Node (SGSN);
-	the Gateway GPRS Support Node (GGSN);
-	the Gateway Mobile Location Centre (GMLC);
-	the CSG Subscriber Server (CSS).
6.1.3.2	The Mobile-services Switching Centre (MSC)
There are several cases where it is necessary to address the MSC.
6.1.3.2.1	MSC interaction during handover or relocation
The address is derived from the target Cell id or from the target RNC id.
6.1.3.2.2	MSC for short message routing
When a short message has to be routed to an MS, the GMSC addresses the VMSC by an MSC identity received from the HLR that complies with E.164 rules.
For MS originating short message, the IWMSC address is derived from the Service Centre address.
6.1.3.2.3	MSC for location request routing
When a location request for a particular MS needs to be sent to the MS's VMSC, the GMLC addresses the VMSC using an E.164 address received from the MS's HLR.
6.1.3.2.4	MSC for LMU Control
When a control message has to be routed to an LMU from an SMLC, the SMLC addresses the serving MSC for the LMU using an E.164 address.
6.1.3.3	The Home Location Register (HLR)
There are several cases where the HLR has to be addressed.
6.1.3.3.1	During call set-up
When a call is initiated the HLR of the called mobile subscriber will be interrogated to discover the whereabouts of the MS. The addressing required by the SCCP will be derived from the MSISDN dialled by the calling subscriber. The dialled number will be translated into either an SPC, in the case of communications within a PLMN, or a Global Title if other networks are involved (i.e. if the communication is across a PLMN boundary).
If the calling subscriber is a fixed network subscriber, the interrogation can be initiated from the Gateway MSC of the home PLMN in the general case. If the topology of the network allows it, the interrogation could be initiated from any Signalling Point that has MAP capabilities, e.g. local exchange, outgoing International Switching Centre (ISC), etc.
6.1.3.3.2	Before location updating completion
When an MS registers for the first time in a VLR, the VLR has to initiate the update location dialogue with the MS's HLR and a preceding dialogue for authentication information retrieval if the authentication information must be retrieved from the HLR. When initiating either of these dialogues, the only data for addressing the HLR that the VLR has available is contained in the IMSI, and addressing information for SCCP must be derived from it. When continuing the established update location dialogue (as with any other dialogue), the VLR must derive the routeing information towards the HLR from the Calling Party Address received with the first responding CONTINUE message until the dialogue terminating message is received. This means that the VLR must be able to address the HLR based on:
-	an E.214 Mobile Global Title originally derived by the VLR from the IMSI (when CCITT or ITU-T SCCP is used), or an E.212 number originally derived from IMSI (when ANSI SCCP is used, an IMSI); or
-	an E.164 HLR address; or
-	in the case of intra-PLMN signalling, an SPC.
When answering with Global Title to the VLR, the HLR shall insert its E.164 address in the Calling Party Address of the SCCP message containing the first responding CONTINUE message.
If the HLR is in the same PLMN as the VLR, local translation tables may exist to derive an SPC. For authentication information retrieval and location updating via the international PSTN/ISDN signalling network that requires the use of CCITT or ITU-T SCCP, the Global Title must be derived from the IMSI, using the principles contained in CCITT Recommendation E.214 and the Numbering Plan Indicator (NPI) value referenced by the SCCP Specifications. In World Zone 1 where the ANSI SCCP is used, IMSI (E.212 number) is used as Global Title. A summary of the translation from the IMSI (CCITT Recommendation E.212) to Mobile Global Title (described in CCITT Recommendation E.214) is shown below:
-	E.212 Mobile Country Code translates to E.164 Country Code;
-	E.212 Mobile Network Code translates to E.164 National Destination Code;
-	E.212 Mobile Subscriber Identification Number (MSIN) is carried unchanged if within the E.164 number maximum length (15 digits). If the Mobile Global Title is more than 15 digits the number is truncated to 15 by deleting the least significant digits.
This translation will be done either at the application or at SCCP level in the VLR. The Mobile Global Title thus derived will be used to address the HLR.
If location updating is triggered by an MS that roams from one MSC Area into a different MSC Area served by the same VLR, the VLR shall address the HLR in the same way as if the MS registers for the first time in the VLR.
6.1.3.3.3	After location updating completion
In this case, the subscriber's basic MSISDN has been received from the HLR during the subscriber data retrieval procedure as well as the HLR number constituting a parameter of the MAP message indicating successful completion of the update location dialogue. From either of these E.164 numbers the address information for initiating dialogues with the roaming subscriber's HLR can be derived. Also the subscriber's IMSI may be used for establishing the routeing information towards the HLR. This may apply in particular if the dialogue with the HLR is triggered by subscriber controlled input.
Thus the SCCP address of the roaming subscriber's HLR may be an SPC, or it may be a Global title consisting of the E.164 MSISDN or the E.164 number allocated to the HLR or either the E.214 Mobile Global Title derived from the IMSI if CCITT or ITU-T SCCP is used, or the IMSI if ANSI SCCP is used (ANSI SCCP is used in World Zone 1).
6.1.3.3.4	VLR restoration
If a roaming number is requested by the HLR for an IMSI that has no data record in the interrogated VLR, the VLR provides the roaming number in the dialogue terminating message. Subsequently the VLR must retrieve the authentication data from the MS's HLR, if required, and must then trigger the restore data procedure. For this purpose, the VLR has to initiate in succession two independent dialogues with the MS's HLR. The MTP and SCCP address information needed for routeing towards the HLR can be derived from the IMSI received as a parameter of the MAP message requesting the roaming number. In this case, the IMSI received from the HLR in the roaming number request shall be processed in the same way as the IMSI that is received from an MS that registers for the first time within a VLR. Alternatively to the IMSI, the Calling Party Address associated with the roaming number request may be used to obtain the routeing information towards the HLR.
6.1.3.3.5	During Network-Requested PDP Context Activation
When receiving a PDP PDU the GGSN may interrogate the HLR of the MS for information retrieval. When initiating such a dialogue, the only data for addressing the HLR that the GGSN has available is contained in the IMSI, and addressing information must be derived from it. The IMSI is obtained from the IP address or the X.25 address in the incoming IP message by means of a translation table. This means that the GGSN shall be able to address the HLR based on an E.214, (if CCITT or ITU-T SCCP is used), or E.212 (if ANSI SCCP is used), Mobile Global Title originally derived by the GGSN from the IMSI in the case of inter-PLMN signalling. In the case of intra-PLMN signalling, an SPC may also be used.
If the HLR is in the same PLMN as the GGSN, local translation tables may exist to derive an SPC. For information retrieval via the international PSTN/ISDN signalling network, the Global title must be derived from the IMSI, using the principles contained in CCITT Recommendation E.214 and the Numbering Plan Indicator (NPI) value referenced by the SCCP Specifications. A summary of the translation from the IMSI (CCITT Recommendation E.212) to Mobile Global Title (described in CCITT Recommendation E.214) is shown below:
-	E.212 Mobile Country Code translates to E.164 Country Code;
-	E.212 Mobile Network Code translates to E.164 National Destination Code;
-	E.212 Mobile Subscriber Identification Number (MSIN) is carried unchanged if within the E.164 number maximum length (15 digits). If the Mobile Global Title is more than 15 digits the number is truncated to 15 by deleting the least significant digits.
This translation will be done either at the application or at SCCP level in the GGSN. The Mobile Global Title thus derived will be used to address the HLR.
6.1.3.3.6	Before GPRS location updating completion
When an MS registers for the first time in an SGSN, the SGSN has to initiate the update location dialogue with the MS's HLR and a preceding dialogue for authentication information retrieval if the authentication information must be retrieved from the HLR. When initiating either of these dialogues, the only data for addressing the HLR that the SGSN has available is contained in the IMSI, and addressing information for SCCP must be derived from it. When continuing the established update location dialogue (as with any other dialogue), the SGSN must derive the routeing information towards the HLR from the Calling Party Address received with the first responding CONTINUE message until the dialogue terminating message is received. This means that the SGSN must be able to address the HLR based on:
-	an E.214 (if CCITT or ITU-T SCCP is used) or E.212 (if ANSI SCCP is used) Mobile Global Title originally derived by the SGSN from the IMSI; or
-	an E.164 HLR address; or
-	in the case of intra-PLMN signalling, an SPC.
If the HLR is in the same PLMN as the SGSN, local translation tables may exist to derive an SPC. For authentication information retrieval and location updating via the international PSTN/ISDN signalling network, the Global title must be derived from the IMSI, using the principles contained in CCITT Recommendation E.214 and the Numbering Plan Indicator (NPI) value referenced by the SCCP Specifications. A summary of the translation from the IMSI (CCITT Recommendation E.212) to Mobile Global Title (described in CCITT Recommendation E.214) is shown below:
-	E.212 Mobile Country Code translates to E.164 Country Code;
-	E.212 Mobile Network Code translates to E.164 National Destination Code;
-	E.212 Mobile Subscriber Identification Number (MSIN) is carried unchanged if within the E.164 number maximum length (15 digits). If the Mobile Global Title is more than 15 digits the number is truncated to 15 by deleting the least significant digits.
This translation will be done either at the application or at SCCP level in the SGSN. The Mobile Global Title thus derived will be used to address the HLR.
6.1.3.3.7	After GPRS location updating completion
In this case, the subscriber's Basic MSISDN has been received from the HLR during the subscriber data retrieval procedure as well as the HLR number constituting a parameter of the MAP message indicating successful completion of the update location dialogue. From either of these E.164 numbers the address information for initiating dialogues with the roaming subscriber's HLR can be derived. Also the subscriber's IMSI may be used for establishing the routeing information towards the HLR.
Thus the SCCP address of the roaming subscriber's HLR may be an SPC, or it may be a Global title consisting of the E.164 MSISDN or the E.164 number allocated to the HLR or the E.214 Mobile Global Title derived from the IMSI.
6.1.3.3.8	Query for a Location Request
For a location request from an external client, the GMLC needs to address the home HLR of the target MS to obtain the address of the target MS's serving MSC. The GMLC uses either the international E.164 MSISDN, the international E.214 number (if CCITT or ITU-T SCCP is used) or the international E.212 number (if ANSI SCCP is used) of the MS as means to route a query to the HLR.
6.1.3.4	The Visitor Location Register (VLR)
6.1.3.4.0	General
There are several cases when the VLR needs to be addressed.
6.1.3.4.1	Inter-VLR information retrieval
When an MS moves from one VLR service area to another, the new VLR may request the IMSI and authentication sets from the previous VLR. The new VLR derives the address of the previous VLR from the Location Area Identification provided by the MS in the location registration request.
6.1.3.4.2	HLR request
The HLR will only request information from a VLR if it is aware that one of its subscribers is in the VLR service area. This means that a location updating dialogue initiated by the VLR has been successfully completed, i.e. the HLR has indicated successful completion of the update location procedure to the VLR.
When initiating dialogues towards the VLR after successful completion of location updating, the routeing information used by the HLR is derived from the E.164 VLR number received as a parameter of the MAP message initiating the update location dialogue. If the VLR is in the same PLMN as the HLR, the VLR may be addressed directly by an SPC derived from the E.164 VLR number. For dialogues via the international PSTN/ISDN signalling network, presence of the E.164 VLR number in the Called Party Address is required.
6.1.3.4.3	CSS request
The CSS will only request information from a VLR if it is aware that one of its subscribers is in the VLR service area. This means that a VCSG location updating dialogue initiated by the VLR has been successfully completed, i.e. the CSS has indicated successful completion of the update VCSG location procedure to the VLR.
When initiating dialogues towards the VLR after successful completion of VCSG location updating, the routeing information used by the CSS is derived from the E.164 VLR number received as a parameter of the MAP message initiating the update VCSG location dialogue. The VLR may be addressed either by the E.164 VLR number or directly by an SPC derived from the E.164 VLR number due to the VLR is in the same PLMN as the CSS.
6.1.3.5	The Interworking MSC (IWMSC) for Short Message Service
The IWMSC is the interface between the mobile network and the network to access to the Short Message Service Centre. This exchange has an E.164 address known in the SGSN or in the MSC.
6.1.3.6	The Equipment Identity Register (EIR)
The EIR address is either unique or could be derived from the IMEI. The type of address is not defined.
6.1.3.7	Void
6.1.3.8	The Serving GPRS Support Node (SGSN)
6.1.3.8.0	General
There are several cases when the SGSN needs to be addressed.
6.1.3.8.1	HLR request
The HLR will initiate dialogues towards the SGSN if it is aware that one of its subscribers is in the SGSN serving area. This means that a GPRS location updating has been successfully completed, i.e., the HLR has indicated successful completion of the GPRS location update to the SGSN. The routeing information used by the HLR is derived form the E.164 SGSN number received as parameter of the MAP message initiating the GPRS update location procedure. If the SGSN is in the same PLMN as the HLR, the SGSN may be addressed directly by an SPC derived from the E.164 SGSN number. For dialogues via the international PSTN/ISDN signalling network, the presence of the E.164 SGSN number in the Called Party Address is required.
6.1.3.8.2	GMSC request
When the GMSC initiates dialogues towards the SGSN the SGSN (MAP) SSN (See 3GPP TS 23.003 [17]) shall be included in the called party address. The routeing information used by the GMSC is derived from the E.164 SGSN number received as a parameter of the MAP message initiating the forward short message procedure. If the GMSC does not support the GPRS functionality the MSC (MAP) SSN value shall be included in the called party address.
NOTE:	Every VMSC and SGSN shall have uniquely identifiable application using E.164 numbers, for the purpose of SMS over GPRS when the GMSC does not support the GPRS functionality.
6.1.3.8.3	CSS request
The CSS will initiate dialogues towards the SGSN if it is aware that one of its subscribers is in the SGSN serving area. This means that a VCSG location updating has been successfully completed, i.e., the CSS has indicated successful completion of the VCSG location update to the SGSN. The routeing information used by the CSS is derived from the E.164 SGSN number received as parameter of the MAP message initiating the update VCSG location procedure. The SGSN may be addressed either by the E.164 SGSN number or directly by an SPC derived from the E.164 SGSN number due to the SGSN is in the same PLMN as the CSS.
6.1.3.9	The Gateway GPRS Support Node (GGSN)
The GGSN provides interworking with external packet-switched networks, network screens and routing of the Network-Requested PDP Context activation. If a Network-Requested PDP Context activation fails, the HLR will alert the GGSN when the subscriber becomes reachable. The HLR will use the E.164 GGSN number received as parameter of the MAP message reporting the failure.
6.1.3.10	The Gateway MSC (GMSC) for Short Message Service
The GMSC provides interworking with the network to access the Short Message Service Centre, the mobile network and routing of Send Routing Info For SM. The GMSC has on E.164 address known in the HLR, SGSN or MSC.
6.1.3.10A	Void
6.1.3.10A.1	Void
6.1.3.10A.2	Void
6.1.3.10B	The Gateway Mobile Location Centre (GMLC)
The GMLC initiates location requests on behalf of external clients. The E.164 address of the GMLC is provided to an HLR when the GMLC requests a serving MSC address or SGSN address from the HLR for a target MS. The E.164 address of the GMLC is also provided to a serving MSC or SGSN when the GMLC requests the location of a target MS served by this MSC or SGSN.
6.1.3.10C	The CSG Subscriber Server (CSS)
The CSS address is either unique or could be derived from the IMSI. The type of address is not defined.
6.1.3.11	Summary table
The following tables summarise the SCCP address used for invoke operations. As a principle, within a PLMN either an SPC or a GT may be used (network operation option), whereas when addressing an entity outside the PLMN the GT must be used. The address type mentioned in the table (e.g. MSISDN) is used as GT or to derive the SPC.
For a response, the originating address passed in the invoke is used as SCCP Called Party Address. For extra-PLMN addressing the own E.164 entity address is used as SCCP Calling Party Address; for intra-PLMN addressing an SPC derived from the entity number may be used instead. When using an SPC, the SPC may be taken directly from MTP.
Table 6.1/1
to
from
fixed net work
HLR
VLR
MSC
EIR
gsmSCF
SGSN
GGSN
CSS
fixed network
---
E:GT
T:MSISDN
---
---
---
---
---
---
---
Home Location Register
---
---
I:SPC/GT
E:GT
T:VLR NUMBER
---
---
I:SPC/GT
E:GT
T:gsmSCF NUMBER
I:SPC/GT
E:GT
T:SGSN
NUMBER
I:SPC/GT
E:GT
T:GGSN
NUMBER
---
Visitor Location Register
---
I:SPC/GT
E:GT
T:MGT
(outside World Zone 1)/MSISDN
(World Zone 1/)HLR NUMBER
(note)
I:SPC/GT
E:GT
T:VLR NUMBER
---
---
 I:SPC/GT E:GT T:gsmSCF NUMBER
---
---
I: SPC/GT
E:GT
T:CSS NUMBER
mobile-services switching centre
---
I:SPC/GT
E:GT
T:MSISDN
I:SPC/GT
E:GT
T:VLR NUMBER
I:SPC/GT
E:GT
T:MSC NUMBER
I:SPC/GT
E:GT
T:EIR NUMBER
I:SPC/GT
E:GT
T:gsmSCF NUMBER
I:SPC/GT
E:GT
T:SGSN
NUMBER
---
---
gsm Service Control Function
---
I:SPC/GT
E:GT
T:MSISDN
---
---
---
---
---
---
---
Serving
GPRS
Support
Node
---
I:SPC/GT
E:GT
T:MGT/
MSISDN/HLR NUMBER
---
I:SPC/GT
E:GT
T:MSC
NUMBER


I:SPC/GT
E:GT
T:EIR
NUMBER
I:SPC/GT
E:GT
T:gsmSCF NUMBER 
---
---
I:SPC/GT
E:GT
T:CSS NUMBER
Gateway
GPRS
Support
Node
---
I:SPC/GT
E:GT
T:MGT
---
---
---
---
---
---
---
Gateway Mobile Location Centre
---
I:SPC/GT
E:GT
T:MSISDN, MGT
(outside World Zone 1) or IMSI
(World Zone 1)
(note)
---
I:SPC/GT
E:GT
T:MSC NUMBER
---
---
I:SPC/GT
E:GT
T:SGSN NUMBER 
---
---
CSG Subscriber Server
---
---
I:SPC/GT
E:GT
T:VLR NUMBER
---
---
---
I:SPC/GT
E:GT
T:SGSN
NUMBER
---
---
I:	Intra-PLMN.
E:	Extra (Inter)-PLMN.
T:	Address Type.
GT:	Global Title.
MGT:	E.214 Mobile Global Title.
SPC:	Signalling Point Code.
NOTE:	For initiating the location updating procedure and an authentication information retrieval from the HLR preceding it, the VLR has to derive the HLR address from the IMSI of the MS. The result can be an SPC or an E.214 Mobile Global Title if CCITT or ITU-T SCCP is used, or IMSI itself if ANSI SCCP is used (ANSI SCCP is used in World Zone 1). When continuing the established update location dialogue (as with any other dialogue) the VLR must derive the routeing information towards the HLR from the Calling Party Address received with the first responding CONTINUE message until the dialogue terminating message is received.
	For transactions invoked by the VLR after update location completion, the VLR may derive the information for addressing the HLR from addresses received in the course of the update location procedure (MSISDN or HLR number) or from the IMSI.
	When invoking the Restore Data procedure and an authentication information retrieval from the HLR preceding it, the VLR must derive the information for addressing the HLR from the address information received in association with the roaming number request. This may be either the IMSI received as a parameter of the MAP message requesting the Roaming Number or the Calling Party Address associated with the MAP message requesting the Roaming Number.
	The gsmSCF shall be addressed using more than one Global Title number. The first Global Title number is used to address a gsmSCF for MAP. The second Global Title number is used to address a gsmSCF for CAP.
	For querying the HLR to obtain the VMSC address to support location services, the GMLC has to derive the HLR address from either the MSISDN or IMSI of the target MS. When using the IMSI, the result can be an SPC or an E.214 Mobile Global Title if CCITT or ITU-T SCCP is used, or IMSI itself if ANSI SCCP is used (ANSI SCCP is used in World Zone 1).


Table 6.1/2
to
from

GMLC
fixed network

---
Home Location Register

---
Visitor Location Register

---
Mobile-services Switching Centre

I:SPC/GT
E:GT
T:MLC Number 
gsm Service Control Function

I:SPC/GT
E:GT
T:MSISDN
Serving
GPRS
Support
Node

I:SPC/GT
E:GT
T:MLC Number 
Gateway
GPRS
Support
Node

---
Gateway Mobile Location Centre


I:	Intra-PLMN.
E:	Extra (Inter)-PLMN.
T:	Address Type.
GT:	Global Title.
MGT:	E.214 Mobile Global Title.
SPC:	Signalling Point Code.

6.2	Use of TC
The Mobile Application part makes use of the services offered by the Transaction Capabilities (TC) of Signalling System No. 7. ETS 300 287, which is based on CCITT White Book Recommendations Q.771 to Q.775, should be consulted for the full specification of TC.
The MAP uses all the services provided by TC except the ones related to the unstructured dialogue facility.
From a modelling perspective, the MAP is viewed as a single Application Service Element. Further structuring of it is for further study.
Transaction Capabilities refers to a protocol structure above the network layer interface (i.e., the SCCP service interface) up to the application layer including common application service elements but not the specific application service elements using them.
TC is structured as a Component sub-layer above a Transaction sub-layer.
The Component sub-layer provides two types of application services: services for the control of end-to-end dialogues and services for Remote Operation handling. These services are accessed using the TC-Dialogue handling primitives and TC-Component handling primitives respectively.
Services for dialogue control include the ability to exchange information related to application-context negotiation as well as initialisation data.
Services for Remote Operation handling provide for the exchange of protocol data units invoking tasks (operations), and reporting their outcomes (results or errors) plus any non-application-specific protocol errors detected by the component sub-layer. The reporting of application-specific protocol errors by the TC user, as distinct from application process errors, is also provided. The Transaction sub-layer provides a simple end-to-end connection association service over which several related protocol data units (i.e. built by the Component Sub-Layer) can be exchanged. A Transaction termination can be prearranged (no indication provided to the TC user) or basic (indication provided).

7	General on MAP services
7.1	Terminology and definitions
The term service is used in clauses 7 to 12 as defined in CCITT Recommendation X.200. The service definition conventions of CCITT Recommendation X.210 are also used. 
MAP services that are defined for use between HLR and SGSN are also used in an Evolved Packet System (EPS) between two IWFs and between HSS and IWF, where the IWF is an Interworking Function that converts MAP messages to Diameter messages and vice versa. 
MAP services that are defined for use between SGSN and EIR are also used in an Evolved Packet System (EPS) between IWF and EIR.
IWFs may be connected via Diameter to MMEs and HSSs and they may be connected via MAP to HSSs, IWFs, and EIRs.

7.2	Modelling principles
MAP provides its users with a specified set of services and can be viewed by its users as a "black box" or abstract machine representing the MAP service-provider. The service interface can then be depicted as shown in figure 7.2/1.

Figure 7.2/1: Modelling principles
The MAP service-users interact with the MAP service-provider by issuing or receiving MAP service-primitives at the service interface.
A MAP service-user may receive services from several instances of the MAP service-provider at the same time. In such cases the overall procedure is synchronised by the service-user.
The MAP service-primitives are named using the following notation:
MAP-ServicePrimitiveName type
where type can be any of: request (req), indication (ind), response (rsp) or confirm (cnf). (In the user arrow diagrams type is not indicated in the case of req/ind and indicated as "ack" in the case of rsp/cnf).
The services are further classified as unconfirmed-service, confirmed-service and provider-initiated-service where the first two categories refer to whether or not the service is confirmed by the service-provider. The confirmation may or may not correspond to a response provided by the other service-user.
MAP services are also classified as common MAP services that are available to all MAP service-users, and MAP service-user specific services, which are services available to one or several, but not all, MAP service-users.
A MAP dialogue is defined as an exchange of information between two MAP users in order to perform a common task. A MAP dialogue will consist of one or several MAP services.
7.3	Common MAP services
All MAP service-users require access to services for performing basic application layer functions:
-	for establishing and clearing MAP dialogues between peer MAP service-users;
-	for accessing functions supported by layers below the applications layer;
-	for reporting abnormal situations;
-	for handling of different MAP versions;
-	for testing whether or not a persistent MAP dialogue is still active at each side.
For these purposes the following common services are defined:
-	MAP-OPEN service;
-	MAP-CLOSE service;
-	MAP-DELIMITER service;
-	MAP-U-ABORT service;
-	MAP-P-ABORT service;
-	MAP-NOTICE service.
In defining the service-primitives the following convention is used for categorising parameters:
M	the inclusion of the parameter is mandatory. The M category can be used for any primitive type and specifies that the corresponding parameter must be present in the indicated primitive type;
O	the inclusion of the parameter is a service-provider option. The O category can be used in indication and confirm type primitives and is used for parameters that may optionally be included by the service-provider;
U	the inclusion of the parameter is a service-user option. The U category can be used in request and response type primitives. The inclusion of the corresponding parameter is the choice of the service-user;
C	the inclusion of the parameter is conditional. The C category can be used for the following purposes:
-	to indicate that if the parameter is received from another entity it must be included for the service being considered;
-	to indicate that the service user must decide whether to include the parameter, based on the context on which the service is used;
-	to indicate that one of a number of mutually exclusive parameters must be included (e.g. parameters indicating a positive result versus parameters indicating a negative result);
-	to indicate that a service user optional parameter (marked "U") or a conditional parameter (marked "C") presented by the service user in a request or response type primitive is to be presented to the service user in the corresponding indication or confirm type primitive;
(=)	when appended to one of the above, this symbol means that the parameter takes the same value as the parameter appearing immediately to its left;
blank	the parameter is not present.
A primitive type may also be without parameters, i.e. no parameter is required with the primitive type; in this case the corresponding column of the table is empty.
7.3.1	MAP-OPEN service
This service is used for establishing a MAP dialogue between two MAP service-users. The service is a confirmed service with service primitives as shown in table 7.3/1.
Table 7.3/1: Service-primitives for the MAP-OPEN service
Parameters
Request
Indication
Response
Confirm
Application context name
M
M(=)
U
C(=)
Destination address
M
M(=)


Destination reference
U
C(=)


Originating address
U
O


Originating reference
U
C(=)


Specific information
U
C(=)
U
C(=)
Responding address


U
C(=)
Result


M
M(=)
Refuse-reason


C
C(=)
Provider error



O

Application context name:
This parameter identifies the type of application context being established. If the dialogue is accepted the received application context name shall be echoed. In case of refusal of dialogue this parameter shall indicate the highest version supported.
Destination address:
A valid SCCP address identifying the destination peer entity (see also clause 6). As an implementation option, this parameter may also, in the indication, be implicitly associated with the service access point at which the primitive is issued.
Destination-reference:
This parameter is a reference that refines the identification of the called process. It may be identical to Destination address but its value is to be carried at MAP level. Table 7.3/2 describes the MAP services using this parameter. Only these services are allowed to use it.
Table 7.3/2: Use of the destination reference
MAP service
Reference type
Use of the parameter



MAP-REGISTER-SS
IMSI
Subscriber identity



MAP-ERASE-SS
IMSI
Subscriber identity



MAP-ACTIVATE-SS
IMSI
Subscriber identity



MAP-DEACTIVATE-SS
IMSI
Subscriber identity



MAP-INTERROGATE-SS
IMSI
Subscriber identity



MAP-REGISTER-PASSWORD
IMSI
Subscriber identity



MAP-PROCESS-UNSTRUCTURED-
SS-REQUEST
IMSI (note 1)
Subscriber identity



MAP-UNSTRUCTURED-
SS-REQUEST
IMSI (note 2)
Subscriber identity



MAP-UNSTRUCTURED-SS-NOTIFY
IMSI (note 2)
Subscriber identity



MAP-FORWARD-SHORT-MESSAGE
IMSI (note 3)
Subscriber identity



MAP-REGISTER-CC-ENTRY
IMSI
Subscriber identity



MAP-ERASE-CC-ENTRY
IMSI
Subscriber identity

NOTE 1:	On the HLR - HLR interface and on the HLR - gsmSCF interface the Destination reference shall be either IMSI or MSISDN.
NOTE 2:	On the gsmSCF - HLR interface and on the HLR - HLR interface the Destination reference shall be either IMSI or MSISDN.

NOTE 3:	Only when the IMSI and the LMSI are received together from the HLR in the mobile terminated short message transfer.
Originating address:
A valid SCCP address identifying the requestor of a MAP dialogue (see also clause 6). As an implementation option, this parameter may also, in the request, be implicitly associated with the service access point at which the primitive is issued.
Originating-reference:
This parameter is a reference that refines the identification of the calling process. It may be identical to the Originating address but its value is to be carried at MAP level. Table 7.3/3 describes the MAP services using the parameter. Only these services are allowed to use it. Processing of the Originating-reference shall be performed according to the supplementary service descriptions and other service descriptions, e.g. operator determined barring. Furthermore the receiving entity may be able to use the value of the Originating-reference to screen the service indication.
Table 7.3/3: Use of the originating reference
MAP service
Reference type
Use of the parameter



MAP-REGISTER-SS
ISDN-Address-String
Originated entity address



MAP-ERASE-SS
ISDN-Address-String
Originated entity address



MAP-ACTIVATE-SS
ISDN-Address-String
Originated entity address



MAP-DEACTIVATE-SS
ISDN-Address-String
Originated entity address



MAP-INTERROGATE-SS
ISDN-Address-String
Originated entity address



MAP-REGISTER-PASSWORD
ISDN-Address-String
Originated entity address



MAP-PROCESS-UNSTRUCTURED-
SS-REQUEST
ISDN-Address-String
Originated entity address



MAP-UNSTRUCTURED-
SS-REQUEST
ISDN-Address-String (note)
Originated entity address



MAP-UNSTRUCTURED-
SS-NOTIFY
ISDN-Address-String (note)
Originated entity address



MAP-REGISTER-CC-ENTRY
ISDN-Address-String
Originated entity address



MAP-ERASE-CC-ENTRY
ISDN-Address-String
Originated entity address

NOTE:	The Originating reference may be omitted. 
Specific information:
This parameter may be used for passing any user specific information. Establishment and processing of the Specific information is not specified by GSM and shall be performed according to operator specific requirements.
Responding address:
An address identifying the responding entity. The responding address is included if required by the context (e.g. if it is different from the destination address).
Result:
This parameter indicates whether the peer accepts the dialogue.
Refuse reason:
This parameter is present only if the Result parameter indicates that the dialogue is refused. It takes one of the following values:
-	Application-context-not-supported;
-	Invalid-destination-reference;
-	Invalid-originating-reference;
-	No-reason-given;
-	Remote node not reachable;
-	Potential version incompatibility.
7.3.2	MAP-CLOSE service
This service is used for releasing a previously established MAP dialogue. The service may be invoked by either MAP service-user depending on rules defined within the service-user. The service is an unconfirmed service with parameters as shown in table 7.3/4.
Table 7.3/4: Service-primitives for the MAP-CLOSE service
Parameters
Request
Indication
Release method
M

Specific Information
U
C(=)

Release method:
This parameter can take the following two values:
-	normal release; in this case the primitive is mapped onto the protocol and sent to the peer;
-	prearranged end; in this case the primitive is not mapped onto the protocol. Prearranged end is managed independently by the two users, i.e. only the request type primitive is required in this case.
Specific information:
This parameter may be used for passing any user specific information. Establishment and processing of the Specific information is not specified by GSM GSM and shall be performed according to operator specific requirements.
7.3.3	MAP-DELIMITER service
This service is used to explicitly request the transfer of the MAP protocol data units to the peer entities.
See also clause 7.4 and 7.5 for the detailed use of the MAP-DELIMITER service.
The service is an unconfirmed service with service-primitives as shown in table 7.3/5.
Table 7.3/5: Service-primitives for the MAP-DELIMITER service
Parameters
Request
Indication







7.3.4	MAP-U-ABORT service
This service enables the service-user to request the MAP dialogue to be aborted. The service is an unconfirmed service with service-primitives as shown in table 7.3/6.
Table 7.3/6: Service-primitives for the MAP-U-ABORT service
Parameters
Request
Indication
User reason
M
M(=)
Diagnostic information
U
C(=)
Specific information
U
C(=)

User reason:
This parameter can take the following values:
-	resource limitation (congestion);
the requested user resource is unavailable due to congestion;
-	resource unavailable;
the requested user resource is unavailable for reasons other than congestion;
-	application procedure cancellation;
the procedure is cancelled for reasons detailed in the diagnostic information parameter;
-	procedure error;
processing of the procedure is terminated for procedural reasons.
Diagnostic information:
This parameter may be used to give additional information for some of the values of the user-reason parameter:
Table 7.3/7: User reason and diagnostic information
User reason
Diagnostic information
Resource limitation (congestion)
-
Resource unavailable
Short term/long term problem
Application procedure cancellation
Handover cancellation/
Radio Channel release/
Network path release/
Call release/
Associated procedure failure/
Tandem dialogue released/
Remote operations failure
Procedure error
-

Specific information:
This parameter may be used for passing any user specific information. Establishment and processing of the Specific information is not specified by GSM and shall be performed according to operator specific requirements.
7.3.5	MAP-P-ABORT service
This service enables the MAP service-provider to abort a MAP dialogue. The service is a provider-initiated service with service-primitives as shown in table 7.3/8.
Table 7.3/8: Service-primitives for the MAP-P-ABORT service
Parameters

Indication
Provider reason

M
Source

M

Provider reason:
This parameter indicates the reason for aborting the MAP dialogue:
-	provider malfunction;
-	supporting dialogue/transaction released;
-	resource limitation;
-	maintenance activity;
-	version incompatibility;
-	abnormal MAP dialogue.
Source:
This parameter indicates the source of the abort. For Transaction Capabilities (TC) applications the parameter may take the following values:
-	MAP problem;
-	TC problem;
-	network service problem.
Table 7.3/9: Values of provider reason and source parameters
and examples of corresponding events
Provider reason
Source
Corresponding event
Provider
MAP
Malfunction at MAP level at peer entity
malfunction
TC
"Unrecognised message type" or
"Badly formatted transaction portion" or
"Incorrect transaction portion" received in TC-P-ABORT
"Abnormal dialogue"

Network service
Malfunction at network service level at peer entity

Supporting dialogue/ transaction released



TC



"Unrecognised transaction ID" received in TC-ABORT
Resource
MAP
Congestion towards MAP peer service-user
limitation
TC
"Resource limitation" received in TC-P-ABORT
Maintenance
MAP
Maintenance at MAP peer service-user
activity
Network service
Maintenance at network peer service level
Abnormal MAP dialogue
MAP
MAP dialogue is not in accordance with specified application context
Version incompatibility
TC
A Provider Abort indicating "No common dialogue portion" is received in the dialogue initiated state

7.3.6	MAP-NOTICE service
This service is used to notify the MAP service-user about protocol problems related to a MAP dialogue not affecting the state of the protocol machines.
The service is a provider-initiated service with service-primitive as shown in table 7.3/10.
Table 7.3/10: Service-primitive for the MAP-NOTICE service
Parameters
Indication
Problem diagnostic
M

Problem diagnostic:
This parameter can take one of the following values:
-	abnormal event detected by the peer;
-	response rejected by the peer;
-	abnormal event received from the peer;
-	message cannot be delivered to the peer.
7.3.7	Void
7.3.8	Void
7.3.9	Void
7.3.10	Void
7.4	Sequencing of services
The sequencing of services is shown in figure 7.4/1 and is as follows:
Opening:
	The MAP-OPEN service is invoked before any user specific service-primitive is accepted. The sequence may contain none, one or several user specific service-primitives. If no user specific service-primitive is contained between the MAP-OPEN and the MAP-DELIMITER primitives, then this will correspond to sending an empty Begin message in TC. If more than one user specific service-primitive is included, all are to be sent in the same Begin message. The sequence ends with a MAP-DELIMITER primitive.
Continuing:
	This sequence may not be present in some MAP dialogues. If it is present, it ends with a MAP-DELIMITER primitive. If more than one user specific service-primitive is included, all are to be included in the same Continue message.
Closing:
	The sequence can only appear after an opening sequence or a continuing sequence. The sequence may contain none, one or several user specific service-primitives if the MAP-CLOSE primitive specifies normal release. If no user specific service-primitive is included, then this will correspond to sending an empty End message in TC. If more than one user specific service-primitive is included, all are to be sent in the same End message. If prearranged end is specified, the sequence cannot contain any user specific service-primitive. The MAP-CLOSE primitive must be sent after all user specific service-primitives have been delivered to the MAP service-provider.
Aborting:
	A MAP service-user can issue a MAP-U-ABORT primitive at any time after the MAP dialogue has been opened or as a response to an attempt to open a MAP dialogue.
The MAP service-provider may issue at any time a MAP-P-ABORT primitive towards a MAP service-user for which a MAP dialogue exists.
MAP-U-ABORT primitives and MAP-P-ABORT primitives terminate the MAP dialogue.

a) Opening

b) Continuing

c) Closing

d) Aborting
Figure 7.4/1: Sequencing of services
If the reason "resource unavailable (short term problem)" is indicated in the MAP-U-ABORT indication primitive, the MAP service-user may decide to attempt a new MAP dialogue establishment immediately.
Sequencing of user specific service-primitives is done by the MAP service-user and based on rules applicable for each MAP service-user instance.
A MAP-NOTICE indication primitive may be received at any time during the active period of a MAP dialogue.
7.5	General rules for mapping of services onto TC
7.5.1	Mapping of common services
Table 7.5/1 gives an overview of the mapping rules for mapping of common services onto TC-services. Table 7.5/2 gives the mapping rules for mapping of TC-services onto common services.
Protocol machine description is given in clauses 14 to 17.
Table 7.5/1: Mapping of common services onto TC services
MAP service-primitive
TC service-primitive
MAP-OPEN request
(+ any user specific service primitives)
+ MAP-DELIMITER request

TC-BEGIN request
(+ component handling primitives)
MAP-OPEN response
(+ any user specific service primitives)
+ MAP-DELIMITER request

TC-CONTINUE request (note)
(+ component handling primitives)
(any user specific service primitives)
+ MAP-DELIMITER request
TC-CONTINUE request
(+ component handling primitives)
(any user specific service primitives)
+ MAP-CLOSE request
TC-END request
(+ component handling primitives)
MAP-U-ABORT request
TC-U-ABORT request
NOTE:	Or TC-END if the MAP-CLOSE request has been received before the MAP-DELIMITER request.

Table 7.5/2: Mapping of TC services onto common service
TC service-primitive
MAP service-primitive
TC-BEGIN indication
(+ component handling primitives)
MAP-OPEN indication
(+ user specific service primitives)
+ MAP-DELIMITER indication (note 1)
TC-CONTINUE indication
(+ component handling primitives)
First time:
MAP-OPEN confirm
(+ user specific service primitives)
+ MAP-DELIMITER indication (note 1)

Subsequent times:
(user specific service primitives)
+ MAP-DELIMITER indication (note 1)
TC-END indication
(+ component handling primitives)
MAP-OPEN confirm (note 6)
(user specific service primitives)
+ MAP-CLOSE indication
TC-U-ABORT indication
MAP-U-ABORT indication or
MAP-P-ABORT indication (note 2)
MAP-OPEN confirmation (note 3)
TC-P-ABORT indication
MAP-P-ABORT indication (note 4)
MAP-OPEN confirmation (note 5)
NOTE 1:	It may not be necessary to present this primitive to the user for MAP version 2 applications.
NOTE 2:	The mapping depends on whether the TC-U-ABORT indication primitive contains a MAP‑abort‑PDU from the remote MAP service-provider or a MAP-user-abort-PDU from the remote MAP service-user.
NOTE 3:	Only if the opening sequence is pending and if the "Abort Reason" in the TC-U-ABORT indication is set to "Application Context Not Supported".
NOTE 4:	If the "Abort Reason" in the TC-P-ABORT indication is set to a value different from "Incorrect Transaction Portion".
NOTE 5:	Only if the opening sequence is pending and if the "Abort Reason" in the TC-P-ABORT indication is set to "Incorrect Transaction Portion".
NOTE 6:	Only if opening sequence is pending.

7.5.2	Mapping of user specific services
Table 7.5/3 gives the general mapping rules which apply to mapping of MAP user specific services onto TC services and table 7.5/4 gives the similar rules for mapping of TC services onto MAP user specific services. Detailed mapping is given in clauses 14 to 17.
Table 7.5/3: Mapping of MAP user specific services onto TC services
MAP service-primitive
TC-service-primitive
MAP-xx request
TC-INVOKE request
MAP-xx response
TC-RESULT-L request
(note 1)
TC-U-ERROR request

TC-U-REJECT request

TC-INVOKE request (note 2)

Table 7.5/4: Mapping of TC services onto MAP user specific services
TC-service-primitive
MAP service-primitive
TC-INVOKE indication
MAP-xx indication
TC-RESULT-L indication (note 4)
MAP-xx confirm
TC-U-ERROR indication

TC-INVOKE indication (note 2) 

TC-L-CANCEL indication

TC-U-REJECT indication
MAP-xx confirm or
TC-L-REJECT indication
MAP-NOTICE indication (note 3)
TC-R-REJECT indication


Notes to tables 7.5/3 and 7.5/4:
NOTE 1:	The mapping is determined by parameters contained in the MAP-xx response primitive.
NOTE 2:	This applies only to TC class 4 operations where the operation is used to pass a result of another class 2 or class 4 operation.
NOTE 3:	The detailed mapping rules are given in clause 16.
NOTE 4:	If RESULT-NL components are present they are mapped onto the same MAP-xx confirm.
7.6	Definition of parameters
7.6.1	Common parameters
The following set of parameters is used in several MAP service-primitives.
7.6.1.1	Invoke Id
This parameter identifies corresponding service primitives. The parameter is supplied by the MAP service-user and must be unique over each service-user/service-provider interface.
7.6.1.2	Linked Id
This parameter is used for linked services and it takes the value of the invoke Id of the service linked to.
7.6.1.3	Provider error
This parameter is used to indicate a protocol related type of error:
-	duplicated invoke Id;
-	not supported service;
-	mistyped parameter;
-	resource limitation;
-	initiating release, i.e. the peer has already initiated release of the dialogue and the service has to be released;
-	unexpected response from the peer;
-	service completion failure;
-	no response from the peer;
-	invalid response received.
7.6.1.4	User error
This parameter can take values as follows:
NOTE:	The values are grouped in order to improve readability; the grouping has no other significance.
a)	Generic error:
-	system failure, i.e. a task cannot be performed because of a problem in the entity reporting the error or in another entity. The type of entity or network resource may be indicated by use of the network resource parameter or additional network resource parameter. If and only if the problem is in the entity reporting the error, a cause of failure (FailureCauseParam) shall be included;
-	data missing, i.e. an optional parameter required by the context is missing;
-	unexpected data value, i.e. the data type is formally correct but its value or presence is unexpected in the current context;
-	resource limitation;
-	initiating release, i.e. the receiving entity has started the release procedure;
-	facility not supported, i.e. the requested facility is not supported by the PLMN with detailed reasons as follows:
	-	Shape of location estimate not supported;
	-	Needed LCS capability not supported in serving node;
-	incompatible terminal, i.e. the requested facility is not supported by the terminal.
b)	Identification or numbering problem:
-	unknown subscriber, i.e. no such subscription exists;
-	number changed, i.e. the subscription does not exist for that number any more;
-	unknown MSC;
-	unidentified subscriber, i.e. if the subscriber is not contained in the database and it has not or cannot be established whether or not a subscription exists;
-	unallocated roaming number;
-	unknown equipment;
-	unknown location area.
c)	Subscription problem:
-	roaming not allowed, i.e. a location updating attempt is made in an area not covered by the subscription;
-	illegal subscriber, i.e. illegality of the access has been established by use of authentication procedure;
-	bearer service not provisioned;
-	teleservice not provisioned;
-	illegal equipment, i.e. the IMEI check procedure has shown that the IMEI is blacklisted or not whitelisted.
d)	Handover problem:
-	no handover number available, i.e. the VLR cannot allocate a number for handover or cannot allocate the required amount of numbers for relocation;
-	subsequent handover failure, i.e. handover to a third MSC failed for some reason;
-	target cell outside group call area.
e)	Operation and maintenance problem:
-	tracing buffer full, i.e. tracing cannot be performed because the tracing capacity is exceeded.
f)	Call set-up problem:
-	no roaming number available, i.e. a roaming number cannot be allocated because all available numbers are in use;
-	absent subscriber, i.e. the subscriber has activated the detach service or the system detects the absence condition. This error may be qualified to indicate whether the subscriber was IMSI detached, in a restricted area or did not respond to paging;
-	busy subscriber. This error may be qualified to indicate that the subscriber was busy due to CCBS and that CCBS is possible;
-	no subscriber reply;
-	forwarding violation, i.e. the call has already been forwarded the maximum number of times that is allowed;
-	CUG reject, i.e. the call does not pass a CUG check; additional information may also be given in order to indicate rejection due to e.g. incoming call barred or non-CUG membership;
-	call barred. Optionally, additional information may be included for indicating either that the call meets a barring condition set by the subscriber or that the call is barred for operator reasons. In the case of barring of Mobile Terminating Short Message, the additional information may indicate a barring condition due to "Unauthorised Message Originator"; if the call is rejected due to the application of the ACR supplementary service, the additional information shall indicate a barring condition due to "Anonymous Call Rejection";
-	optimal routeing not allowed, i.e. the entity which sends the error does not support optimal routeing, or the HLR will not accept an optimal routeing interrogation from the GMSC, or the call cannot be optimally routed because it would contravene optimal routeing constraints;
-	forwarding failed, i.e. the GMSC interrogated the HLR for forwarding information but the HLR returned an error.
g)	Supplementary services problem:
-	call barred;
-	illegal SS operation;
-	SS error status;
-	SS not available;
-	SS subscription violation;
-	SS incompatibility;
-	negative password check;
-	password registration failure;
-	Number of Password Attempts;
-	USSD Busy;
-	Unknown Alphabet;
-	short term denial;
-	long term denial.
For definition of these errors see 3GPP TS 24.080 [38].
h)	Short message problem:
-	SM delivery failure with detailed reason as follows:
-	memory capacity exceeded;
-	MS protocol error;
-	MS not equipped;
-	unknown service centre (SC);
-	SC congestion;
-	invalid SME address;
-	subscriber is not an SC subscriber;
-	and possibly detailed diagnostic information, coded as specified in 3GPP TS 23.040, under SMS-SUBMIT-REPORT and SMS-DELIVERY-REPORT. If the SM entity that returns the SM Delivery Failure error includes detailed diagnostic information, it shall be forwarded in the MAP_MO_FORWARD_SHORT_MESSAGE and in the MAP_MT_FORWARD_SHORT_MESSAGE response.
-	message waiting list full, i.e. no further SC address can be added to the message waiting list.
-	Subscriber busy for MT SMS, i.e. the mobile terminated short message transfer cannot be completed because:
-	another mobile terminated short message transfer is going on and the delivery node does not support message buffering; or 
-	another mobile terminated short message transfer is going on and it is not possible to buffer the message for later delivery; or
-	the message was buffered but it is not possible to deliver the message before the expiry of the buffering time defined in 3GPP TS 23.040;
-	Absent Subscriber SM, i.e. the mobile terminated short message transfer cannot be completed because the network cannot contact the subscriber. Diagnostic information regarding the reason for the subscriber's absence may be included with this error.
i)	Location services problem:
-	Unauthorised Requesting Network
-	Unauthorised LCS Client with detailed reasons as follows:
-	NoAdditional Information
-	Client not in MS Privacy Exception List
-	Call to Client not setup
-	Disallowed by Local Regulatory Requirements
-	Unauthorised Privacy Class
-	Unauthorised Call/Session Unrelated External Client
-	Unauthorised Call/Session Related External Client
-	Privacy override not applicable
-	Position method failure with detailed reasons as follows:
-	Congestion
-	Insufficient resources
-	Insufficient Measurement Data
-	Inconsistent Measurement Data
-	Location procedure not completed
-	QoS not attainable
-	Position Method Not Available in Network
-	Position Method Not Available in Location Area
-	Unknown or unreachable LCS Client.
7.6.1.5	All Information Sent
This parameter indicates to the receiving entity when the sending entity has sent all necessary information.
7.6.2	Numbering and identification parameters
7.6.2.1	IMSI
This parameter is the International Mobile Subscriber Identity defined in 3GPP TS 23.003 [17].
7.6.2.2	TMSI
This parameter is the Temporary Mobile Subscriber Identity defined in 3GPP TS 23.003 [17].
7.6.2.3	IMEI
This parameter is the International Mobile Equipment Identity defined in 3GPP TS 23.003 [17].
7.6.2.3a	IMEISV
This parameter is the International Mobile Equipment Identity and Software Version Number defined in 3GPP TS 23.003 [17].
7.6.2.4	Previous location area Id
This parameter refers to the identity of the location area from which the subscriber has roamed.
7.6.2.5	Stored location area Id
This parameter refers to the location area where the subscriber is assumed to be located.
7.6.2.6	Current location area Id
This parameter is used to indicate the location area in which the subscriber is currently located.
7.6.2.7	Target location area Id
This parameter refers to the location area into which the subscriber intends to roam.
7.6.2.8	Target cell Id
This parameter refers to the identity of the cell to which a call has to be handed over.
7.6.2.8A	Target RNC Id
This parameter refers to the identity of the RNC to which a call has to be relocated.
7.6.2.9	Void
7.6.2.10	Originating entity number
This parameter refers to an application layer identification of a system component in terms of its associated ISDN number.
7.6.2.11	MSC number
This parameter refers to the ISDN number of an MSC.
7.6.2.12	Target MSC number
This parameter refers to the ISDN number of an MSC to which a call has to be handed over.
7.6.2.13	HLR number
This parameter refers to the ISDN number of an HLR.
7.6.2.14	VLR number
This parameter refers to the ISDN number of a VLR.
7.6.2.15	HLR Id
This parameter refers to the identity of an HLR derived from the IMSI defined in CCITT Recommendation E.212.
7.6.2.16	LMSI
This parameter refers to a local identity allocated by the VLR to a given subscriber for internal management of data in the VLR. LMSI shall not be sent to the SGSN.
7.6.2.17	MS ISDN
This parameter refers to one of the ISDN numbers assigned to a mobile subscriber in accordance with CCITT Recommendation E.213.
7.6.2.17A	Additional MSISDN
This parameter refers to an ISDN number assigned on top of the existing MSISDN, to a user with a connection to the PS domain (see 3GPP TS 23.003 [17]). If the Additional MSISDN is available its value shall be used as C‑MSISDN on the Sv interface.
7.6.2.18	OMC Id
This parameter refers to the identity of an Operation and Maintenance Centre.
7.6.2.19	Roaming number
This parameter refers to the roaming number as defined in CCITT Recommendation E.213.
7.6.2.19A	Relocation Number List
This parameter refers to the number(s) used for routing one call or several calls between MSCs during relocation.
7.6.2.20	Void
7.6.2.21	Handover number
This parameter refers to the number used for routing a call between MSCs during handover.
7.6.2.22	Forwarded-to number
This parameter refers to the address to which a call is to be forwarded. A subaddress may be appended. For subscribers having an originating CAMEL Phase 2 or higher subscription, this address need not be in E.164 international format.
7.6.2.22A	Long forwarded-to number
This parameter refers to the address to which a call is to be forwarded. A subaddress may be appended. For subscribers having an originating CAMEL Phase 2 or higher subscription this address need not be in international format.
7.6.2.22B	Long FTN Supported
This parameter indicates that the sending entity supports Long Forwarded-to Numbers.
7.6.2.23	Forwarded-to subaddress
This parameter refers to the sub-address attached to the address to which a call is to be forwarded.
7.6.2.24	Called number
This parameter refers to a called party number as defined in CCITT Recommendation Q.767.
7.6.2.25	Calling number
This parameter refers to a calling party number as defined in CCITT Recommendation Q.767.
7.6.2.26	Originally dialled number
This parameter refers to the number dialled by the calling party in order to reach a mobile subscriber.
7.6.2.27	Service centre address
This parameter represents the address of a Short Message Service Centre.
7.6.2.28	Zone Code
This parameter is used to define location areas into which the subscriber is allowed or not allowed to roam (regional subscription). With a complete list of Zone Codes the VLR or the SGSN or MME is able to determine for all its location areas, routing areas or tracking areas whether roaming is allowed or not.
7.6.2.29	MSIsdn-Alert
This parameter refers to the MSISDN stored in a Message Waiting Data File in the HLR. It is used to alert the Service Centre when the MS is again attainable.
7.6.2.30	Location Information
The VLR indicates in this parameter the location of the served subscriber as defined in 3GPP TS 23.018 [97].
7.6.2.30a	Location Information for GPRS
The SGSN indicates in this parameter the location of the served subscriber as defined in 3GPP TS 23.078 [98].
7.6.2.30b	Location Information for EPS
The MME (via an IWF) indicates in this parameter the location of the served subscriber. 
7.6.2.31	GMSC Address
This parameter refers to the E.164 address of a GMSC.
7.6.2.32	VMSC Address
This parameter refers to the E.164 address of a VMSC.
7.6.2.33	Group Id
This parameter is used to describe groups a subscriber can be a member of. A subscriber can partake in all group calls (VBS/VGCS) where he subscribed to the respective groups.
7.6.2.34	North American Equal Access preferred Carrier Id
This parameter refers to the carrier identity preferred by the subscriber for calls requiring routing via an inter-exchange carrier. This identity is used at:
-	outgoing calls: when the subscriber does not specify at call set-up a carrier identity;
-	forwarded calls: when a call is forwarded by the subscriber;
-	incoming calls: applicable to the roaming leg of the call.
7.6.2.35	Void
7.6.2.36	Void
7.6.2.37	Serving cell Id
This parameter indicates the cell currently being used by the served subscriber.
7.6.2.38	SGSN number
This parameter refers to the ISDN number of a SGSN.
7.6.2.39	SGSN address
This parameter refers to the IP-address of a SGSN. This parameter is defined in 3GPP TS 23.003 [17].
7.6.2.40	GGSN address
This parameter refers to the IP-address of a GGSN. This parameter is defined in 3GPP TS 23.003 [17].
7.6.2.41	GGSN number
This parameter refers to the ISDN number of a GGSN or the ISDN number of the protocol-converter if a protocol‑converting GSN is used between the GGSN and the HLR.
7.6.2.42	APN
This parameter refers to the DNS name of a GGSN. This parameter is defined in 3GPP TS 23.060 [104].
7.6.2.43	Network Node number
This parameter refers to the ISDN number of an MT-SMS target node (MSC or MME, SGSN, or IP-SM-GW) or of an SMS Router.
7.6.2.43A	Network Node Diameter Address 
This parameter refers to the Diameter Name and Realm of the same MT-SMS target node or SMS Router of which the ISDN number is within the Network Node number parameter. 
7.6.2.44	PDP-Type
This parameter indicates which type of protocol is used by the MS as defined in 3GPP TS 23.060 [104]. The allowed values are one of IPv4 encoded as HEX (21) or IPv6 encoded as HEX (57), or Non-IP encoded as HEX (02).
NOTE:	To indicate both IPv4 and IPv6 PDP types are allowed, but not IPv4v6, two PDP contexts need to be present in the subscription for the same APN, one indicating IPv4 PDP type and one indicating IPv6 PDP type.

7.6.2.44A	Extension PDP-Type
This parameter indicates the support of the dual-stack PDP-type (IPv4v6) encoded as HEX (8D) by a certain PDP, as defined in 3GPP TS 23.060 [104], and it is an extension to PDP-Type.
7.6.2.45	PDP-Address
This parameter indicates the address of the data protocol as defined in 3GPP TS 23.060 [104].
7.6.2.45A	Extension PDP-Address
This parameter indicates an additional address of the data protocol, and it is included when the PDP supports dual-stack (IPv4v6).
It is an extension to PDP-Address and it is encoded in the same way. IPv4 or IPv6 address types can be used in this parameter but, when both parameters are present, each of them shall contain different address types.
7.6.2.46	Additional number
This parameter refers to the ISDN number of an additional MT-SMS target node (MSC or MME or SGSN) or of an SMS Router.
7.6.2.46A	Additional Network Node Diameter Address 
This parameter refers to an additional Diameter Name and Realm of the same MT-SMS target node or SMS Router of which the ISDN number is within the Additional number parameter. 
7.6.2.46B	Third Number
This parameter refers to the ISDN number of a third MT-SMS target node (MSC or MME or SGSN).
7.6.2.46C	Third Network Node Diameter Address 
This parameter refers to the third Diameter Name and Realm of the same MT-SMS target node of which the ISDN number is within the Third number parameter. 
7.6.2.47	P-TMSI
This parameter is the Packet Temporary Mobile Subscriber Identity defined in 3GPP TS 23.003 [17].
7.6.2.48	B-subscriber number
This parameter refers to the number of the destination B dialled by the A user. This may include a subaddress.
7.6.2.49	B-subscriber subaddress
This parameter refers to the sub-address attached to the destination B dialled by the A user.
7.6.2.50	LMU Number 
This parameter refers to a local number assigned to an LMU by an SMLC.
7.6.2.51	MLC Number 
This parameter refers to the ISDN (E.164) number of an MLC.
7.6.2.52	Multicall Bearer Information
This parameter refers to the number of simultaneous bearers supported per user by the serving network.
7.6.2.53	Multiple Bearer Requested
This parameter indicates whether multiple bearers are requested for a relocation.
7.6.2.54	Multiple Bearer Not Supported
This parameter indicates whether multiple bearers are supported.
7.6.2.55	PDP-Charging Characteristics
This parameter indicates the charging characteristics associated with a specific PDP context as defined in 3GPP TS 32.215.
7.6.2.56	Selected RAB ID
The selected radio access bearer to be kept at subsequent inter-MSC handover from UMTS to GSM.
7.6.2.57	RAB ID
This parameter indicates the radio access bearer identifier as defined in 3GPP TS 25.413. This parameter is used to relate the radio resources with the radio access bearers.
7.6.2.58	gsmSCF Address
This parameter refers to the ISDN number assigned to the gsmSCF address.  In an IP Multimedia Core Network, the gsmSCF-address shall contain the IM-SSF address when the IM-SSF takes the role of the gsmSCF.
7.6.2.59	V-GMLC Address
This parameter refers to the IP address of a V-GMLC.
7.6.2.60	Void
7.6.2.61	H-GMLC Address
This parameter refers to the IP address of a H-GMLC.
7.6.2.62	PPR Address
This parameter refers to the IP address of a Privacy Profile Register.
7.6.2.63	Routeing Number
This parameter refers to a number used for routeing purpose and identifying a network operator. See 3GPP TS 23.066 [108].
7.6.2.64	Additional V-GMLC Address
This parameter refers to the IP address of a V-GMLC.
7.6.2.65	MME Name
This parameter refers to the Diameter Identity of an MME as defined in 3GPP TS 23.003 [17].
7.6.2.66	3GPP AAA Server Name
This parameter refers to the Diameter Identity of a 3GPP AAA server as defined in 3GPP TS 29.273 [151].
7.6.2.67	CSS number
This parameter refers to the ISDN number of a CSS as defined in 3GPP TS 23.003[17].
7.6.2.68	SGSN Name
This parameter refers to the Diameter Identity of an SGSN as defined in 3GPP TS 23.003 [17].
7.6.2.69	SGSN Realm
This parameter refers to the Diameter Identity of an SGSN as defined in 3GPP TS 23.003 [17].
7.6.3	Subscriber management parameters
7.6.3.1	Category
This parameter refers to the calling party category as defined in CCITT Recommendation Q.767.
7.6.3.2	Equipment status
This parameter refers to the status of the mobile equipment as defined in 3GPP TS 22.016 [7].
7.6.3.2a	BMUEF
This parameter refers to the Bit Map of UE Faults and corresponds to the UESBI-Iu parameter defined in 3GPP TS 25.413 [120].
7.6.3.3	Extensible Bearer service
This parameter may refer to a single bearer service, a set of bearer services or to all bearer services as defined in 3GPP TS 22.002 [3]. This parameter is used only for subscriber profile management. Extensible Bearer service values include all values defined for a Bearer service parameter (7.6.4.38).
7.6.3.4	Extensible Teleservice
This parameter may refer to a single teleservice, a set of teleservices or to all teleservices as defined in 3GPP TS 22.003 [4]. This parameter is used only for subscriber profile management. Extensible Teleservice values include all values defined for a Teleservice parameter (7.6.4.39).
7.6.3.5	Extensible Basic Service Group
This parameter refers to the Basic Service Group either as an extensible bearer service (see clause 7.6.3.3) or an extensible teleservice (see clause 7.6.3.4). This parameter is used only for subscriber profile management. The null value (i.e. neither extensible bearer service nor extensible teleservice) is used to denote the group containing all extensible bearer services and all extensible teleservices.
7.6.3.6	GSM bearer capability
This parameter refers to the GSM bearer capability information element defined in 3GPP TS 24.008 [35].
7.6.3.7	Subscriber Status
This parameter refers to the barring status of the subscriber:
-	service granted;
-	Operator Determined Barring.
7.6.3.8	CUG Outgoing Access indicator
This parameter represents the Outgoing Access as defined in ETS 300 136.
7.6.3.9	Operator Determined Barring General Data
This parameter refers to the set of subscriber features that the network operator or the service provider can regulate. This set only includes those limitations that can be 
a) controlled in the VLR,
b) controlled in the SGSN or MME,
c) controlled in the SGSN applied for short message transfer only,
d) interrogated or modified by the gsmSCF:

ODB category
Controlled in the VLR 
Controlled in the SGSN or MME
Controlled in the SGSN applied for short message transfer only
Interrogatable and modifyable by the gsmSCF
All outgoing calls barred
X

X
X
International outgoing calls barred
X

X
X
International outgoing calls except those to the home PLMN country barred
X

X
X
Interzonal outgoing calls barred
X

X
X
Interzonal outgoing calls except those to the home PLMN country barred
X

X
X
Interzonal outgoing calls AND international outgoing calls except those directed to the home PLMN country barred
X

X
X
Premium rate (information) outgoing calls barred
X


X
Premium rate (entertainment) outgoing calls barred
X


X
Supplementary service access barred
X


X
Invocation of call transfer barred
X


X
Invocation of chargeable call transfer barred
X


X
Invocation of internationally chargeable call transfer barred
X


X
Invocation of interzonally chargeable call transfer barred
X


X
Invocation of call transfer where both legs are chargeable barred
X


X
Invocation of call transfer if there is already an ongoing transferred call for the served subscriber in the serving MSC/VLR barred
X


X
All packet Oriented Services barred

X

X
Roamer Access to HPLMN-AP barred

X

X
Roamer Access to VPLMN-AP barred

X

X
Outgoing calls when roaming outside the home PLMN country



X
All incoming calls



X
Incoming calls when roaming outside the home PLMN country



X
Incoming calls when roaming outside the zone of the home PLMN country



X
Roaming outside the home PLMN



X
Roaming outside the home PLMN country



X
Registration of any call forwarded-to number



X
Registration of any international call forwarded-to number



X
Registration of any international call forwarded-to number except to a number within the HPLMN country



X
Registration of any inter-zone call forwarded-to number



X
Registration of any inter-zone call forwarded-to number except to a number within the HPLMN country



X


7.6.3.10	ODB HPLMN Specific Data
This parameter refers to the set of subscriber features that the network operator or the service provider can regulate only when the subscriber is registered in the HPLMN. This set only includes those limitations that can be controlled in the VLR or in the SGSN or MME:
-	Operator Determined Barring Type 1;
-	Operator Determined Barring Type 2;
-	Operator Determined Barring Type 3;
-	Operator Determined Barring Type 4.
7.6.3.11	Regional Subscription Data
This parameter defines the regional subscription area in which the subscriber is allowed to roam. It consists of a list of Zone Codes (see clause 7.6.2.28).
7.6.3.12	Regional Subscription Response
This parameter indicates either that the regional subscription data cannot be handled or that the current MSC or SGSN or MME area is entirely restricted because of regional subscription.
7.6.3.13	Roaming Restriction Due To Unsupported Feature
This parameter defines that a subscriber is not allowed to roam in the current MSC area. It may be used by the HLR if a feature or service is indicated as unsupported by the VLR.
7.6.3.14	Extensible SS-Info
This parameter refers to all the information related to a supplementary service and is a choice between:
-	extensible forwarding information	(see clause 7.6.3.15);
-	extensible call barring information	(see clause 7.6.3.20);
-	CUG info	(see clause 7.6.3.22);
-	extensible SS-Data	(see clause 7.6.3.29).
7.6.3.15	Extensible forwarding information
This parameter represents the information related to each call forwarding service:
-	the SS-Code of the relevant call forwarding service	(see clause 7.6.4.1);
-	if required, a list of extensible forwarding feature parameters	(see clause 7.6.3.16).
	The list may contain one item per Basic Service Group.
7.6.3.16	Extensible forwarding feature
This parameter applies to each combination of call forwarding service and Basic Service Group and contains the following information, as required:
-	extensible Basic Service Group	(see clause 7.6.3.5);
-	extensible SS-Status	(see clause 7.6.3.17);
-	forwarded-to number	(see clause 7.6.2.22);
-	forwarded-to subaddress	(see clause 7.6.2.23);
-	extensible forwarding options	(see clause 7.6.3.18);
-	extensible no reply condition timer	(see clause 7.6.4.19);
-	long forwarded-to number	(see clause 7.6.2.22A).
If a number is required to define the forwarded-to destination then:
-	If the VLR supports Long Forwarded-to Numbers then the long forwarded-to number shall be present and the forwarded-to number shall be absent;
-	If the VLR does not support Long Forwarded-to Numbers then the forwarded-to number shall be present and the long forwarded-to number shall be absent.
7.6.3.17	Extensible SS-Status
This parameter refers to the state information of individual supplementary services as defined in 3GPP TS 23.011 [22].
7.6.3.18	Extensible Forwarding Options
This parameter refers to a set of forwarding options attached to a supplementary service. It contains the following information:
-	notification to forwarding party	(see 3GPP TS 22.082 [10] for the meaning of this parameter);
-	redirection notification to the forwarded-to party	(see 3GPP TS 22.082 [10] for the meaning of this parameter);
-	notification to calling party	(see 3GPP TS 22.082 [10] for the meaning of this parameter);
-	redirecting presentation	(see 3GPP TS 22.082 [10] for the meaning of this parameter);
-	forwarding reason	(see 3GPP TS 22.082 [10] for the meaning of this parameter).
7.6.3.19	Extensible No reply condition timer
This parameter refers to the extensible no reply condition timer for call forwarding on no reply.
7.6.3.20	Extensible Call barring information
This parameter contains for each call barring service:
-	SS-Code	(see clause 7.6.4.1);
-	a list of extensible call barring feature parameters	(see clause 7.6.3.21).
	The list may contain one item per Basic Service Group.
7.6.3.21	Extensible Call barring feature
This parameter gives the status of call barring services as applicable to each Basic Service Group. The parameter contains the following information:
-	Extensible Basic Service Group	(see clause 7.6.3.5);
-	provisioned SS-Status	(see clause 7.6.3.17).
7.6.3.22	CUG info
This parameter refers to the overall information required for operation for each CUG:
-	CUG subscriptionList;
-	CUG featureList.
7.6.3.23	CUG subscription
This parameter refers to the set of basic information for each CUG defined in that subscription. The following information is stored:
-	CUG index;
-	CUG interlock;
-	Intra CUG restrictions;
-	Basic Service Group List.
7.6.3.24	CUG interlock
This parameter represents the CUG interlock code defined in ETS 300 138.
7.6.3.25	CUG index
This parameter represents the CUG index defined in ETS 300 138.
7.6.3.26	CUG feature
This parameter contains two parameters that are associated with the Basic Service Group. If the Basic Service Group Code is not present the feature applies to all Basic Services. The following parameters are included:
-	Preferential CUG indicator:
-	indicates which CUG index is to be used at outgoing call set-up using the associated Basic Service Group;
-	Inter CUG Option:
-	describes whether it for the associated Basic Service Group is allowed to make calls outside the CUG and whether incoming calls are allowed;
-	Basic Service Group.
See 3GPP TS 22.085 [13] for meaning of this parameter.
7.6.3.27	Inter CUG options
This parameter indicates the subscribers' ability to make and receive calls outside a specific closed user group. It takes any of the following values:
-	CUG only facility (only calls within CUG are allowed);
-	CUG with outgoing access (calls outside CUG allowed);
-	CUG with incoming access (calls from outside CUG into CUG allowed);
-	CUG with both incoming and outgoing access (all calls allowed).
7.6.3.28	Intra CUG restrictions
This parameter describes whether or not the subscriber is allowed to originate calls to or to receive calls from within the CUG. It can take any of the following values:
-	no CUG restrictions;
-	CUG incoming calls barred;
-	CUG outgoing calls barred.
7.6.3.29	Extensible SS-Data
This parameter refers to the necessary set of information required in order to characterise one supplementary service:
-	SS-Code	(see clause 7.6.4.1);
-	Extensible SS-Status (if applicable)	(see clause 7.6.3.17);
-	Extensible Override subscription option (if applicable)	(see clause 7.6.3.30);
-	Extensible CLI Restriction (if applicable)	(see clause 7.6.3.31);
-	Extensible Basic Service Group Code	(see clause 7.6.3.5).
7.6.3.30	Subscriber State
This parameter indicates the state of the MS as defined in 3GPP TS 23.018 [97].
7.6.3.31	Requested Info
This parameter indicates the subscriber information being requested as defined in 3GPP TS 23.018 [97] and 3GPP TS 23.078 [98].
7.6.3.31A	Requested Domain
This parameter indicates the domain (circuit switched, i.e. from the MSC/VLR, or packet switched, i.e. from the SGSN) from which the requested information should be retrieved.
7.6.3.32	Suppression of Announcement
This parameter indicates if the announcement or tones shall be suppressed as defined in 3GPP TS 23.078 [98].
7.6.3.33	Suppress T-CSI
This parameter is used to suppress the invocation of terminating CAMEL services.
7.6.3.34	GMSC CAMEL Subscription Info
This parameter contains CAMEL subscription information, i.e. O-CSI and/or D-CSI and/or T-CSI, which indicates to the GMSC that originating and/or terminating CAMEL services shall be invoked for the incoming call.
7.6.3.35	VLR CAMEL Subscription Info
This parameter identifies the subscriber as having CAMEL services that are invoked in the MSC or VLR.
7.6.3.36	Supported CAMEL Phases in the VLR
This parameter indicates which phases of CAMEL are supported in the VLR.
7.6.3.36A	Supported CAMEL Phases in the SGSN
This parameter indicates which phases of CAMEL are supported in the SGSN.
7.6.3.36B	Offered CAMEL4 CSIs in the VLR
This parameter indicates which CSIs of CAMEL phase 4 are offered in the VLR as defined in 3GPP TS 23.078.
7.6.3.36C	Offered CAMEL4 CSIs in the SGSN
This parameter indicates which CSIs of CAMEL phase 4 are offered in the SGSN as defined in 3GPP TS 23.078.
7.6.3.36D	Offered CAMEL4 CSIs
This parameter indicates which CSIs of CAMEL phase 4 are offered as defined in 3GPP TS 23.078.
7.6.3.36E	Offered CAMEL4 CSIs in interrogating node
This parameter indicates which CSIs of CAMEL phase 4 are offered in the GMSC or in the gsmSCF as defined in 3GPP TS 23.078.
7.6.3.36F	Offered CAMEL4 CSIs in VMSC
This parameter indicates which CSIs of CAMEL phase 4 are offered in the VMSC as defined in 3GPP TS 23.078.
7.6.3.36G	Offered CAMEL4  Functionalities
7.6.3.36H	Supported CAMEL Phases
This parameter indicates which phases of CAMEL are supported as defined in 3GPP TS 23.078.
7.6.3.36I	Supported CAMEL Phases in interrogating node
This parameter indicates which phases of CAMEL are supported as defined in 3GPP TS 23.078. The interrogating node may be a GMSC or a gsmSCF.
This parameter indicates which functionalities of CAMEL phase 4 are offered as defined in 3GPP TS 23.078.
7.6.3.37	CUG Subscription Flag
This parameter indicates that a subscriber with a T-CSI also has a CUG subscription. It is defined in 3GPP TS 23.078. 
7.6.3.38	CAMEL Subscription Info Withdraw
This parameter indicates that CAMEL Subscription Info shall be deleted from the VLR or SGSN.
7.6.3.39	Voice Group Call Service (VGCS) Data
This parameter refers to one or more groups a subscriber may be a member of for voice group calls.
7.6.3.40	Voice Broadcast Service (VBS) Data
This parameter refers to one or more groups a subscriber may be a member of for the voice broadcast service. Per group it is further indicated whether the subscriber is only allowed to listen to respective group calls or whether he is in addition entitled to initiate respective voice broadcast calls.
7.6.3.41	ISDN bearer capability
This parameter refers to the ISDN bearer capability information element defined in 3GPP TS 29.007 [56].
7.6.3.42	Lower layer Compatibility
This parameter refers to the lower layer compatibility information element defined in 3GPP TS 24.008 [35].
7.6.3.43	High Layer Compatibility
This parameter refers to the high layer compatibility information element defined in 3GPP TS 24.008 [35].
7.6.3.44	Alerting Pattern
This parameter is an indication that can be used by the MS to alert the user in a specific manner in case of mobile terminating traffic (switched call or USSD). That indication can be an alerting level or an alerting category.
7.6.3.45	GPRS Subscription Data Withdraw
This parameter indicates that GPRS Subscription Data shall be deleted from the SGSN.
7.6.3.45A	EPS Subscription Data Withdraw
This parameter indicates that EPS Subscription Data shall be deleted from the MME.
7.6.3.46	GPRS Subscription Data
This parameter refers to the list of PDP-Contexts the subscriber has subscribed to.
7.6.3.46A	EPS Subscription Data
This parameter refers to the list of APN-Configurations the subscriber has subscribed to.
7.6.3.47	QoS-Subscribed
This parameter indicates the quality of service subscribed for a certain service. It is defined in 3GPP TS 23.060 [104].
7.6.3.48	VPLMN address allowed
This parameter specifies whether the MS is allowed to use a dynamic address allocated in the VPLMN. It is defined in 3GPP TS 23.060 [104].
7.6.3.49	Roaming Restricted In SGSN/MME Due To Unsupported Feature
This parameter defines that a subscriber is not allowed to roam in the current SGSN or MME area. It may be used by the HLR if a feature or service is indicated as unsupported by the SGSN or MME.
7.6.3.50	Network Access Mode
This parameter is defined in 3GPP TS 23.008 [20]. 
7.6.3.51	Mobile Not Reachable Reason
This parameter stores the reason for the MS being absent when an attempt to deliver a short message to an MS fails at the MSC, SGSN or both. It is defined in 3GPP TS 23.040.
7.6.3.52	Cancellation Type
This parameter indicates the reason of location cancellation. It is defined in 3GPP TS 23.060 [104]. The HLR shall not send Cancel Location with a Cancellation Type of "initialAttachProcedure" to the SGSN unless the SGSN has indicated support of this cancellation type within UpdateGprsLocation or the HLR has enough knowledge that the SGSN supports "initialAttachProcedure". If the HLR needs to send a cancellation type of "initialAttachProcedure" but cannot do so due to non-support by the SGSN, the HLR shall send Cancel Location with a Cancellation Type of "updateProcedure" and delete the stored SGSN-Number.
7.6.3.53	All GPRS Data
This parameter indicates to the SGSN that all GPRS Subscription Data shall be deleted for the subscriber.
7.6.3.54	Complete Data List Included
This parameter indicates to the SGSN or MME that the complete GPRS Subscription Data/EPS Subscription Data stored for the Subscriber shall be replaced with the GPRS Subscription Data/EPS Subscription Data received.
7.6.3.55	PDP Context Identifier
This parameter is used to identify a PDP context for the subscriber.
7.6.3.56	LSA Information
This parameter refers to one or more localised service areas a subscriber may be a member of, together with the priority, the preferential access indicator, the active mode support indicator and active mode indication of each localised service area. The access right outside these localised service areas is also indicated.
7.6.3.57	SoLSA support indicator
This parameter indicates that the VLR or the SGSN supports SoLSA subscription.
7.6.3.58	LSA Information Withdraw
This parameter indicates that LSA information shall be deleted from the VLR or the SGSN.
7.6.3.59	LMU Indicator
This parameter indicates the presence of an LMU.
7.6.3.60	LCS Information
This parameter defines the LCS related information for an MS subscriber and contains the following components:
-	GMLC List	(see clause 7.6.3.61).
-	LCS Privacy Exception List	(see clause 7.6.3.62).
-	MO-LR List	(see clause 7.6.3.65A).
-	Additional LCS Privacy Exception List	(see clause 7.6.3.62A).

7.6.3.61	GMLC List
This parameter contains the addresses of all GMLCs that are permitted to issue a call/session unrelated or call/session related MT-LR location request for this MS. Usage of this parameter is defined in 3GPP TS 23.271.
7.6.3.62	LCS Privacy Exception List
This parameter defines the classes of LCS Client that are allowed to locate any target MS. For each class, the following information is provided:
-	SS-Code	(see clause 7.6.4.1);
-	a list of LCS privacy exception parameters	(see clause 7.6.3.63).
7.6.3.62A	Additional LCS Privacy Exception List
This parameter defines the classes of LCS Client that are allowed to locate any target MS. For each class, the following information is provided:
-	SS-Code	(see clause 7.6.4.1);
-	a list of LCS privacy exception parameters	(see clause 7.6.3.63).
The Additional LCS Privacy Exception List shall be present only if the LCS Privacy Exception List is present and contains LCS privacy exception parameters for 4 privacy exception classes.
7.6.3.63	LCS Privacy Exception Parameters
This parameter gives the status of each LCS privacy exception class and any additional parameters relevant to this class. The parameter contains the following information:
-	provisioned SS-Status	(see clause 7.6.3.17);
-	privacy notification to MS user	(see clause 7.6.3.65B);
-	external client List	(see clause 7.6.3.64);
-	internal client List	(see clause 7.6.3.65).
-	service type List	(see clause 7.6.3.65D);

7.6.3.64	External Client List 
This parameter is only applicable to the call/session unrelated privacy class and call/session related privacy class, and gives the identities of the external clients that are allowed to locate a target MS for a MT-LR. Each identity is an international (e.g.E.164) address. For each identified external client, GMLC restrictions may be defined. It may also be indicated if the MS shall be notified of a non-restricted MT-LR from each identified LCS client and, if so, whether notification only or notification with privacy verification shall apply. Usage of this parameter is defined in 3GPP TS 23.271.
7.6.3.65	Internal Client List 
This parameter is only applicable to the PLMN operator privacy class and gives the identities of the internal PLMN operator clients that are allowed to locate a target MS for an NI-LR or MT-LR. Usage of this parameter is defined in 3GPP TS 23.271.
7.6.3.65A	MO-LR List
This parameter defines the classes of MO-LR for which a subscription exists for a particular MS. For each class, the following information is provided:
-	SS-Code	(see clause 7.6.4.1).
7.6.3.65B	Privacy Notification to MS User
This parameter is applicable to the call/session unrelated privacy class and call/session related privacy class. For non-call/call related privacy class it indicates whether the MS user shall be notified for that class MT-LR from any value added LCS client when the MT-LR is restricted and be enabled to accept or override the restriction.  Usage of this parameter is defined in 3GPP TS 23.271.
7.6.3.65C	GMLC List Withdraw
This parameter indicates whether the subscriber's LCS GMLC list shall be deleted from the VLR or SGSN.
7.6.3.65D	Service Type List 
This parameter is only applicable to the Service type privacy class and gives the identities of the service type of the clients that are allowed to locate a target MS for an MT-LR. Usage of this parameter is defined in 3GPP TS 23.271.
7.6.3.66	IST Alert Timer
This parameter indicates the IST Alert Timer value that must be used in the MSC to inform the HLR about the call activities that the subscriber performs. Units are minutes.
7.6.3.67	Call Termination Indicator
This parameter indicates whether the MSC shall terminate a specific ongoing call, or all the call activities related to a specified subscriber.
7.6.3.68	IST Information Withdraw
This parameter indicates that IST information shall be deleted from the VMSC.
7.6.3.69	IST Support Indicator
This parameter indicates the degree of IST functionality supported by the MSC (Visited MSC or Gateway MSC). It can take one of the following values:
-	Basic IST functionality;
-	IST command service (in addition to the basic IST functionality and including the ability to terminate all calls being carried for the identified subscriber).
7.6.3.70	Super-Charger Supported In HLR
This parameter is used by the HLR to indicate support of the Super-Charger functionality and an indication of the age of the subscription data stored in the HLR.
7.6.3.71	Super-Charger Supported In Serving Network Entity
This parameter is used to indicate support of the Super-Charger functionality by the originating entity and to indicate either that subscription data is required or the date and time of the last know subscriber data modification.
7.6.3.72	Age Indicator
This parameter is used by the HLR to determine the validity of the subscription data retained by the serving network entity in a Super-Charged network.
7.6.3.73	GPRS enhancements support indicator
This parameter indicates to the HLR that the SGSN supports GPRS enhancements.
7.6.3.74	Extension QoS-Subscribed
This parameter indicates the enhanced QoS subscribed for a certain service. It is defined in 3GPP TS 23.060. This parameter is an extension to QoS-Subscribed.
7.6.3.75	SGSN CAMEL Subscription Info
This parameter identifies the subscriber as having CAMEL services that are invoked in the SGSN.
7.6.3.75A	Extension-2 QoS-Subscribed
This parameter indicates the additional QoS information to the Extension QoS-subscribed parameter. It is a further extension to Extension QoS-Subscribed. This parameter shall be used when the maximum bit rate exceeds 8640 kbps. For more details, refer to 3GPP TS 24.008 [35].
7.6.3.75B	Extension-3 QoS-Subscribed
This parameter indicates the additional QoS information to the Extension QoS-subscribed parameter. It is a further extension to Extension QoS-Subscribed. This parameter shall be used when the maximum/guaranteed bit rate for uplink exceeds 8640 kbps. For more details, refer to 3GPP TS 24.008 [35].
7.6.3.75C	Extension-4 QoS-Subscribed
This parameter indicates the additional QoS information to the Extension QoS-subscribed parameter. It is a further extension to Extension QoS-Subscribed. This parameter shall be used to define the Evolved Allocation/Retention Priority parameter, which includes the Priority Level, the Preemption Capability value and the Preemption vulnerability value, as described in 3GPP TS 29.060 [105].
7.6.3.76	MO-SMS-CSI
This parameter identifies the subscriber as having mobile originating SMS CAMEL services as defined in 3GPP TS 23.078. For the CAMEL phase 3 the MO-SMS-CSI is the same as the SMS-CSI.
7.6.3.76a	MT-SMS-CSI
This parameter identifies the subscriber as having mobile terminating SMS CAMEL services as defined in 3GPP TS 23.078.
7.6.3.77	GPRS-CSI
This parameter identifies the subscriber as having GPRS CAMEL services as defined in 3GPP TS 23.078.
7.6.3.78	CAMEL subscription info
This parameter indicates the CSI that can be controlled by CSE.
7.6.3.79	Extensible Call barring information for CSE
This parameter contains for each call barring service for CSE:
-	SS-Code;
-	a list of extensible call barring feature parameters.
	The list may contain one item per Basic Service Group.
-	password;
-	wrong password attempt counter;
-	notification-to-CSE flag.
7.6.3.80	Extensible Forwarding information for CSE
This parameter represents the information for CSE related to each call forwarding service:
-	the SS-Code of the relevant call forwarding service;
-	if required, a list of extensible forwarding feature parameters;
-	the list may contain one item per Basic Service Group;
-	notification-to-CSE flag.
7.6.3.81	Modification Request for CSI
This parameter indicates the CAMEL subscription information to be modified by CSE.
7.6.3.81a	Modification Request for ODB data
This parameter indicates the operator determined barring data to be modified by CSE.
7.6.3.82	Modification Request for SS Information
This parameter indicates the call forwarding, call barring, call hold, call waiting, explicit call transfer, calling line identification presentation and calling line identification restriction supplementary service data to be modified by CSE.
7.6.3.83	Call Barring Data
This parameter contains the extensible call barring feature list (see clause 7.6.3.21) and Notification to CSE flag.
7.6.3.84	Call Forwarding Data
This parameter contains the extensible call forwarding feature list (see clause 7.6.3.16) and Notification to CSE flag.
7.6.3.85	ODB Data
This parameter contains the ODB general data, ODB HPLMN specific data.
7.6.3.86	Requested Subscription Info
This parameter indicates the subscription information being requested.
7.6.3.87	CS Allocation/Retention priority
This parameter indicates the allocation/retention priority for Circuit Switched (CS). It corresponds to the allocation/retention priority that is defined in 3GPP TS 23.107.
7.6.3.88	ODB Info
This parameter contains the ODB data and Notification to CSE flag.
7.6.3.89	Suppress VT-CSI
This parameter is used to suppress the invocation of terminating CAMEL services at the VMSC.
7.6.3.90	Suppress Incoming Call Barring
This parameter is used to suppress the invocation of Incoming Call Barrings.
7.6.3.91	gsmSCF Initiated Call
This parameter is used to indicate that the call was initiated by the gsmSCF.
7.6.3.91a	SuppressMTSS
This parameter is used to suppress the invocation of terminating supplementary services
7.6.3.92	Call barring support indicator
This parameter is used to indicate that the SGSN supports the call barring services for SMS.
7.6.3.93	MNP Info Result
This parameter refers to the Mobile Number Portability (MNP) information result (see 3GPP TS 23.078 [98] and 3GPP TS 23.066 [108]). This parameter may contain the following information:
-	Routeing Number	(see clause 7.6.2.63).
-	IMSI	(see 3GPP TS 23.078[98], see also clause 7.6.2.1).
-	MSISDN	(see clause 7.6.2.17).
-	Number Portability Status	(see clause 7.6.5.14).
7.6.3.94	Allowed Services
This parameter is used by the HLR to indicate which service is available for a call when two services have been requested, for the SCUDIF feature described in 3GPP TS 23.172 [126].
7.6.3.95	Unavailability Cause
This parameter is used to indicate the reason for the unavailability of one of the services as indicated by the Allowed Services IE (see 7.6.3.94) when two services have been requested, for the SCUDIF feature described in 3GPP TS 23.172 [126].
7.6.3.96	MNP Requested Info
This parameter indicates by its presence that  Mobile Number Portability (MNP) information is requested for the subscriber, as defined in 3GPP TS 23.078 [98].
7.6.3.97	Access Restriction Data
This parameter refers to the radio access technologies that are possibly restricted to a subscriber via subscription data. For the use of the parameter, see 3GPP TS 23.012 [23] for the CS domain and 3GPP TS 23.060[104], 3GPP TS 29.060 [105] clause 7.5.3 and 3GPP TS 29.274 [149] clause 7.3.6 for the PS domain.
7.6.3.98	Supported RAT types indicator
This parameter indicates which RAT types are supported/served by the MSC/VLR or SGSN or MME
7.6.3.99	UE SRVCC Capability
This parameter indicates, if present, the support of SRVCC capability by the UE.
7.6.3.100	Temporary Empty CSG Subscription data Indicator
This parameter indicates that the CSS has currently no CSG subscription data for this roaming user but registers the VLR or SGSN, so to inform them if later changes in CSG subscription data occur. 
7.6.3.101	WLAN-offloadability
This parameter refers to the WLAN offloadability for E-UTRAN or UTRAN. This parameter is defined in 3GPP TS 29.272 [144].
7.6.3.102	IMSI-Group-Id
This parameter refers to the IMSI-Group identifier. This parameter is defined in 3GPP TS 29.272 [144].

7.6.4	Supplementary services parameters
7.6.4.1	SS-Code
This parameter may refer to one supplementary service or a set of supplementary services as defined in 3GPP TS 22.004. For MAP this includes:
-	Calling Line Identification Presentation service (CLIP);
-	Calling Line Identification Restriction service (CLIR);
-	Connected Line Identification Presentation service (COLP);
-	Connected Line Identification Restriction service (COLR);
-	Calling Name Presentation (CNAP);
-	All Call Forwarding services, including Call Deflection;
-	Call Waiting (CW);
-	Call Hold (HOLD);
-	Multi-Party service (MPTY);
-	Closed User Group (CUG);
-	All Charging services;
-	All Call Restriction services;
-	Explicit Call Transfer service (ECT);
-	enhanced Multi-Level Precedence and Pre-emption service (eMLPP);
-	Completion of Calls to Busy Subscriber, originating side (CCBS-A);
-	Completion of Calls to Busy Subscriber, destination side (CCBS-B);
-	All LCS privacy exceptions	(see clause 7.6.4.44);
-	Mobile Originating Location Request (MO-LR)	(see clause 7.6.4.45);
-	Multicall (MC).
7.6.4.1A	SS-Code 2
This parameter is used to refer to one or a set of supplementary services  (as 7.6.4.1 "SS-Code") related to Network Signal Info 2 for SCUDIF calls (see 3GPP TS 23.172 [126]).
7.6.4.2	SS-Status
This parameter refers to the state information of individual supplementary services as defined in 3GPP TS 23.011.
7.6.4.3	SS-Data
This parameter refers to the necessary set of information required in order to characterise one supplementary service:
-	SS-Code	(see clause 7.6.4.1);
-	SS-Status (if applicable)	(see clause 7.6.4.2);
-	Override subscription option	(see clause 7.6.4.4);
-	CLI Restriction	(see clause 7.6.4.5);
-	Basic Service Group Code	(see clause 7.6.4.40).
7.6.4.4	Override Category
This parameter refers to the subscription option Override Category attached to a supplementary service. It can take the following two values:
-	Enabled;
-	Disabled.
7.6.4.5	CLI Restriction Option
This parameter refers to the subscription option Restriction mode attached to the CLIR supplementary service. It can take the following three values:
-	Permanent;
-	Temporary (Default Restricted);
-	Temporary (Default Allowed).
7.6.4.6	Forwarding Options
This parameter refers to a forwarding option attached to a supplementary service. It can take one of the following values:
-	notification to forwarding party	(see 3GPP TS 22.082 [10] for the meaning of this parameter);
-	notification to calling party	(see 3GPP TS 22.082 [10] for the meaning of this parameter);
-	redirecting presentation	(see 3GPP TS 22.082 [10] for the meaning of this parameter);
-	Forwarding reason	(see 3GPP TS 22.082 [10] for the meaning of this parameter).
7.6.4.7	No reply condition timer
This parameter refers to the no reply condition timer for call forwarding on no reply.
7.6.4.8 - 7.6.4.14	Void
7.6.4.15	Forwarding information
This parameter represents the information related to each call forwarding service:
-	the SS-Code of the relevant call forwarding service	(see clause 7.6.4.1);
-	if required, a list of forwarding feature parameters	(see clause 7.6.4.16).
	the list may contain one item per Basic Service Group.
7.6.4.16	Forwarding feature
This parameter applies to each combination of call forwarding service and Basic Service Group and contains the following information, as required:
-	Basic Service Group	(see clause 7.6.4.40);
-	SS-Status	(see clause 7.6.4.2);
-	forwarded-to number	(see clause 7.6.2.22);
-	forwarded-to subaddress	(see clause 7.6.2.23);
-	forwarding options	(see clause 7.6.4.6);
-	no reply condition timer	(see clause 7.6.4.7);
-	long forwarded-to number	(see clause 7.6.2.22A).
If a number is required to define the forwarded-to destination then:
-	If the VLR supports Long Forwarded-to Numbers then the long forwarded-to number shall be present and the forwarded-to number shall be absent.
-	If the VLR does not support Long Forwarded-to Numbers then the forwarded-to number shall be present and the long forwarded-to number shall be absent.
7.6.4.17	Void
7.6.4.18	Call barring information
This parameter contains for each call barring service:
-	SS-Code	(see clause 7.6.4.1);
-	a list of call barring feature parameters	(see clause 7.6.4.19).
	The list may contain one item per Basic Service Group.
7.6.4.19	Call barring feature
This parameter gives the status of call barring services as applicable to each Basic Service Group. The parameter contains the following information:
-	Basic Service Group	(see clause 7.6.4.40);
-	SS-Status	(see clause 7.6.4.2).
7.6.4.20	New password
This parameter refers to the password which the subscriber just registered in the network.
This parameter refers to a password used by the subscriber for supplementary service control.
7.6.4.21	Current password
This parameter refers to a password used by the subscriber for supplementary service control.
7.6.4.22	Guidance information
This parameter refers to guidance information given to a subscriber who is requested to provide a password. One of the following information may be given:
-	"enter password";
	this information is used for checking of the old password;
-	"enter new password";
	this information is used during password registration for the request of the first new password;
-	"enter new password again";
	this information is used during password registration for the request of the new password again for verification.
7.6.4.23	Void
7.6.4.24	SS-Info
This parameter refers to all the information related to a supplementary service and is a choice between:
-	forwarding information	(see clause 7.6.4.15);
-	call barring information	(see clause 7.6.4.18);
-	CUG info	(see clause 7.6.4.8);
-	SS-Data	(see clause 7.6.4.3).
-	eMLPP information	(see clause 7.6.4.41).
7.6.4.25 - 7.6.4.35	Void
7.6.4.36	USSD Data Coding Scheme
This parameter contains the information of the alphabet and the language used for the unstructured information in an Unstructured Supplementary Service Data operation. The coding of this parameter is according to the Cell Broadcast Data Coding Scheme as specified in 3GPP TS 23.038 [25].
7.6.4.37	USSD String
This parameter contains a string of unstructured information in an Unstructured Supplementary Service Data operation. The string is sent either by the mobile user or the network. The contents of a string sent by the MS are interpreted by the network as specified in 3GPP TS 22.090 [16].
7.6.4.38	Bearer service
This parameter may refer to a single bearer service, a set of bearer services or to all bearer services as defined in 3GPP TS 22.002 [3]. This parameter is used only for supplementary service management.
7,6,4.38A	Bearer Service 2
This parameter is used to indicate the bearer service or set of bearer services (as 7.6.4.38 "Bearer service") related to Network Signal Info 2 for SCUDIF calls (see 3GPP TS 23.172 [126]).
7.6.4.39	Teleservice
This parameter may refer to a single teleservice, a set of teleservices or to all teleservices as defined in 3GPP TS 22.003 [4]. This parameter is used only for supplementary service management.
7.6.4.39A	Teleservice 2
This parameter is used to indicate the teleservice or set of teleservices (as 7.6.4.39 "Teleservice") related to Network Signal Info 2 for SCUDIF calls (see 3GPP TS 23.172 [126]).
7.6.4.40	Basic Service Group
This parameter refers to the Basic Service Group either as a bearer service (see clause 7.6.4.38) or a teleservice (see clause 7.6.4.39). This parameter is used only for supplementary service management. The null value (i.e. neither bearer service nor teleservice) is used to denote the group containing all bearer services and all teleservices.
7.6.4.41	eMLPP information
This parameter contains two parameters which are associated with the eMLPP service. The following two parameters are included:
-	maximum entitled priority:
-	indicates the highest priority level the subscriber is allowed to apply for an outgoing call set-up;
-	default priority:
-	defines the priority level which shall be assigned to a call if no explicit priority is indicated during call set-up.
7.6.4.42	SS-event
This parameter indicates the Supplementary Service for which an invocation notification is sent towards the gsmSCF. It can indicate one of the following services:
-	Explicit Call Transfer (ECT)
-	Call Deflection (CD)
-	Multi-Party call (MPTY)
-	Completion of Calls to Busy Subscriber (CCBS)
7.6.4.43	SS-event data
This parameter contains additional information related to Supplementary Service invocation. Depending on the service invoked it can contain the following information:
ECT	A list with all Called Party Numbers involved.
CD	The called Party number involved.
7.6.4.44	LCS Privacy Exceptions 
Distinct SS codes are assigned to the following classes of LCS client in a target MS subscriber's privacy exception list.
-	Universal Class;
-	Call/session related value added class;
-	Call/session unrelated value added class;
-	PLMN operator class.
-	Service type class.

7.6.4.45	Mobile Originating Location Request (MO-LR)
Distinct SS codes are assigned to the following classes of MO-LR:
-	Basic Self Location;
-	Autonomous Self Location;
-	Transfer to Third Party.
7.6.4.46	NbrUser
This parameter indicates the maximum number of parallel bearers that may be used as defined by the user at registration of the MC SS.
7.6.4.47	MC Subscription Data
This parameter contains two parameters which are associated with the MC service. The following two parameters are included:
-	NbrUser:
	indicates the maximum number of parallel bearers that may be used as defined by the user at registration of the MC SS
-	NbrSB:
	indicates the maximum number of parallel bearers that may be used as defined by the user's subscription.
7.6.4.48	MC Information
This parameter contains three parameters which are associated with the MC service. The following parameters are included:
-	NbrSB;
-	NbrUser;
-	NbrSN.
Definitions of these parameters are provided in 3GPP TS 23.135.
7.6.4.49	CCBS Request State
This parameter indicates the current state of the CCBS request. It can take one of seven values:
-	request;
-	recall;
-	active;
-	completed;
-	suspended;
-	frozen;
-	deleted.
7.6.4.50	Basic Service Group 2
This parameter refers to the Basic Service Group either as a bearer service (see clause 7.6.4.38) or a teleservice (see clause 7.6.4.39). This parameter is used only for supplementary service management. 
7.6.5	Call parameters
7.6.5.1	Call reference number
This parameter refers to a call reference number allocated by a call control MSC.
7.6.5.2	Interrogation type
This parameter refers to the type of interrogation for routing information which is sent from a GMSC to an HLR. It can take either of two values:
-	basic call (for information to route a call before the call has been extended to the VMSC of the called party);
-	forwarding (for information to route the call to the forwarded-to destination after the VMSC of the forwarding party has requested the GMSC to resume handling of the call.
7.6.5.3	OR interrogation
This parameter indicates that the GMSC which interrogated the HLR for routeing information is not in the same PLMN as the HLR, and therefore that the call will potentially be optimally routed.
7.6.5.4	OR capability
This parameter indicates the phase of OR which the GMSC supports.
7.6.5.5	Forwarding reason
This parameter indicates the reason for which the call is to be forwarded. It can take one of three values:
-	busy subscriber;
-	mobile subscriber not reachable;
-	no subscriber reply.
7.6.5.6	Forwarding interrogation required
This parameter indicates that if the VMSC of the forwarding subscriber requests the GMSC to resume handling of the call the GMSC shall interrogate the HLR for forwarding information.
7.6.5.7	O-CSI
This parameter identifies the subscriber as having originating CAMEL services as defined in 3GPP TS 23.078.
7.6.5.7A	D-CSI
This parameter identifies the subscriber as having originating CAMEL dialled services as defined in 3GPP TS 23.078.
7.6.5.7B	T-CSI
This parameter identifies the subscriber as having terminating CAMEL services in the GMSC, as defined in 3GPP TS 23.078.
7.6.5.7C	VT-CSI
This parameter identifies the subscriber as having terminating CAMEL services in the VMSC, as defined in 3GPP TS 23.078.
7.6.5.7D	O-IM-CSI
This parameter identifies the subscriber as having originating IP Multimedia Core Network CAMEL services as defined in 3GPP TS 23.278. 
7.6.5.7E	D-IM-CSI
This parameter identifies the subscriber as having originating IP Multimedia Core Network CAMEL dialled services as defined in 3GPP TS 23.278. 
7.6.5.7F	VT-IM-CSI
This parameter identifies the subscriber as having terminating IP Multimedia Core Network CAMEL services as defined in 3GPP TS 23.278.
7.6.5.8	Void
7.6.5.9	Void
7.6.5.10	Void
7.6.5.11	CCBS Feature
This parameter corresponds to the 'CCBS Description' parameter in 3GPP TS 23.093. It refers to the necessary set of information required in order to characterise a certain CCBS request. The parameter may contain the following information:
-	CCBS Index	(see 3GPP TS 23.093 for the use of this parameter);
-	B-subscriber number	(see clause 7.6.2.48);
-	B-subscriber subaddress	(see clause 7.6.2.49);
-	Basic Service Group Code	(see clause 7.6.4.40).
7.6.5.12	UU Data
This parameter includes User-To-User Data. It is defined in 3GPP TS 23.087.
7.6.5.13	UUS CF Interaction
This parameter indicates if the call forwarding or call deflection has been activated after UUS1 request has been accepted . It is defined in 3GPP TS 23.087.
7.6.5.14	Number Portability Status
This parameter indicates the number portability status of subscriber. See 3GPP TS 23.066 [108].
7.6.5.15	Pre-paging supported
This parameter indicates that the entity which sent it supports pre-paging.
7.6.5.16	MT Roaming Retry Supported
The parameter indicates that the entity which sent it supports MT Roaming Retry. When sent by the HLR, it further indicates that the GMSC also supports MT Roaming Retry.
7.6.5.17	MT Roaming Retry
The parameter indicates that the GMSC receiving the IE shall start MT roaming retry (see 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23]).
7.6.5.18	Paging Area
The parameter indicates the paging area where the MS is currently located (see 3GPP TS 23.012 [23] and 3GPP TS 23.018 [97]).
7.6.5.19	Call Priority
The parameter indicates the eMLPP priority of the call (see 3GPP TS 23.067 [136]).
7.6.5.20	MTRF Supported
The parameter indicates that the entity which sends it supports MT Roaming Forwarding. 
7.6.5.21	LCLS Global Call Reference (LCLS GCR)
This parameter refers to a globally unique call identifier for the duration of the call (see 3GPP TS 29.205 [146]). This parameter is used to identify a call and to correlate the call legs of a call to determine if the call is a local call within the BSS.
7.6.5.22	LCLS-Negotiation
This parameter is used to request MSC-B to indicate LCLS, see 3GPP TS 29.205 [146] clause B.2.1.4 LCLS Negotiation Request.
7.6.5.23	LCLS-Configuration-Preference
This parameter contains information to indicate the negotiated LCLS configuration preference, see 3GPP TS 29.205 [146] clause B.2.1.10 LCLS Configuration Preference.
7.6.6	Radio parameters
7.6.6.1 - 7.6.6.3	Void
7.6.6.4	GERAN Classmark 
This information element is sent from one MSC  to the other MSC in the signalling  for inter MSC handover. It is used to convey information related to cell capabilities, as defined in 3GPP TS 48.008.
7.6.6.5	BSSMAP Service Handover
This parameter refers to the Service Handover information element defined in 3GPP TS 48.008
7.6.6.5A	BSSMAP Service Handover List
This parameter refers to the list of Service Handover information elements defined in 3GPP TS 48.008. This parameter shall be used when there are multiple bearers and at least one of the bearers has an associated BSSMAP Service Handover parameter.
7.6.6.6	RANAP Service Handover
This parameter refers to the Service Handover information element defined in 3GPP TS 25.413.
7.6.6.7	HO-Number Not Required
This parameter indicates that no handover or relocation number allocation is necessary.
7.6.6.8	Integrity Protection Information
This parameter refers to the Integrity Protection Information element defined in 3GPP TS 25.413.
7.6.6.9	Encryption Information
This parameter refers to the Encryption Information element defined in 3GPP TS 25.413.
7.6.6.10	Radio Resource Information
This parameter refers to the Channel Type information element defined in 3GPP TS 48.008 [49].
7.6.6.10A	Radio Resource List
This parameter refers to list of RAB-id's and their associated Channel Type information elements defined in 3GPP TS 48.008. This parameter shall be used when there are multiple bearers and at least one of the bearers has an associated Radio Resource Information parameter.
7.6.6.10B	Chosen Radio Resource Information
This parameter refers to the Chosen Channel and Speech Version information elements defined in 3GPP TS 48.008. 
7.6.6.11	Key Status
This parameter refers to the Key Status element defined in 3GPP TS 25.413.
7.6.6.12	Selected UMTS Algorithms
This parameters identifies the UMTS integrity and optionally encryption algorithms selected by MSC-B. Coding of this parameter is defined in 3GPP TS 25.413.
7.6.6.13	Allowed GSM Algorithms
This parameters identifies the allowed GSM algorithms in MSC-B. Coding of this parameter is defined in 3GPP TS 48.008.
7.6.6.14	Allowed UMTS Algorithms
This parameters identifies the allowed UMTS algorithms in MSC-B. Coding of this parameter is defined in 3GPP TS 25.413.
7.6.6.15	Selected GSM Algorithm
This parameter identifies the GSM algorithm selected by GSM BSC controlled by MSC-B. Coding of this parameter is defined in 3GPP TS 48.008.
7.6.6.16	Iu-Currently Used Codec
This parameter indicates the codec used at the Iu interface before handover.
7.6.6.17	Iu-Supported Codecs List
This parameter indicates the codecs supported by the UE and by MSC-A and the associated modes in priority order (the first entry being the highest priority codec). MSC-B uses this information to select the associated transcoder resources.
7.6.6.17A	Iu-Available Codecs List
This parameter indicates the codecs available at the Iu interface in MSC-B and the associated modes. MSC-A uses this information to decide whether a change to a different codec at the Iu interface is possible.
7.6.6.18	Iu-Selected Codec
When sent by MSC-B, this parameter indicates the codec selected by MSC-B for the Iu interface. When sent by MSC-A, this parameter indicates the codec to be used by MSC-B at the Iu interface.
7.6.6.19	RAB Configuration Indicator
This parameter indicates by its presence that MSC-A (or MSC-B in case of subsequent handover) has generated the RAB parameters according to the preferred codec (first entry in the Iu-Supported Codecs List).
7.6.6.20	UESBI-Iu
This parameter refers to the UESBI-Iu (UE Specific Behaviour Information over the Iu interface) information element defined in 3GPP TS 25.413.
7.6.6.21	Alternative Channel Type
This parameter refers to the Channel Type information element defined in 3GPP TS 48.008 [49] for the alternative radio access bearer. This parameter is used for SCUDIF calls (see 3GPP TS 23.172 [126]).
7.6.6.22	AoIP-Supported Codecs List Anchor
This parameter is used for inter-MSC handover with AoIP access and the procedures and contents of the parameter are as defined in AoIP-Supported Codecs List (Anchor) in 3GPP TS 23.009 [21]. 
7.6.6.23	AoIP-Available Codecs List Map
This parameter is used for inter-MSC handover with AoIP access and the procedures and contents of the parameter are as defined in AoIP-Available Codecs List (Map) in 3GPP TS 23.009 [21].
7.6.6.24	AoIP-Selected Codec Target
This parameter is used for inter-MSC handover with AoIP access and the procedures and contents of the parameter are as defined in AoIP-Selected Codec (Target) in 3GPP TS 23.009 [21].
7.6.7	Authentication parameters
7.6.7.1	Authentication set list
This parameter represents a list of sets of authentication parameters for a given subscriber.
The list either contains Authentication Triplets (Rand, Sres, Kc) or Authentication Quintuplets (Rand, Xres, Ck, Ik, Autn). If the list contains Authentication Quintuplets, the order of sequence in this list is chronological, the first quintuplet in the list is the oldest one.
7.6.7.2	Rand
This parameter represents a random number used for authentication.
7.6.7.3	Sres
This parameter represents the response to an authentication request.
7.6.7.4	Kc
This parameter refers to a key used for ciphering purposes.
7.6.7.5	Xres
This parameter represents the response to an UMTS authentication request.
7.6.7.5A	Ck
This parameter refers to a key used for UMTS ciphering purposes.
7.6.7.5B	Ik
This parameter refers to the Integrity Key.
7.6.7.5C	Autn
This parameter refers to the Authentication Token.
7.6.7.5D	KASME
This parameter refers to the Key for the Access Security Management Entity.
7.6.7.6	Cksn
This parameter refers to a ciphering key sequence number.
7.6.7.6A	Ksi
This parameter refers to a key set identifier.
7.6.7.6B	Auts
This parameter refers to the resynchronisation token.
7.6.7.7	Ciphering mode
This parameter refers to the ciphering mode which is associated with a radio channel. It may take values as follows:
-	no encryption;
-	identification of specific ciphering algorithm.
7.6.7.8	Current Security Context
This parameter represents a list of security context parameters for a given subscriber.
The list either contains GSM Security Context data (Kc, Cksn) or UMTS Security Context Data (Ck, Ik, Ksi).
7.6.7.9	Failure cause
This parameter refers to an authentication failure which has occurred. It may take values as follows:
-	wrong user response;
-	wrong network signature.
7.6.7.10	Re-attempt
It indicates whether the failure ocurred in a normal authentication attempt or in an authentication reattempt (there was a previous unsuccessful authentication).
7.6.7.11	Access Type
It indicates whether the authentication procedure was initiated due to a call, an emergency call, a location updating, a supplementary service procedure, a short message transfer, a GPRS attach procedure, a routing area updating, a service request, a MS initiated Detach in GPRS, a PDP context activation or a PDP context deactivation procedure.
7.6.8	Short message parameters
7.6.8.1	SM-RP-DA
This parameter represents the destination address used by the short message service relay sub-layer protocol. It can be either of the following:
-	IMSI	(see clause 7.6.2.1);
-	LMSI	(see clause 7.6.2.16);
-	MS-ISDN	(see clause 7.6.2.17);
-	roaming number	(see clause 7.6.2.19);
-	service centre address	(see clause 7.6.2.27).
7.6.8.2	SM-RP-OA
This parameter refers to the originating address used by the short message service relay sub-layer protocol. It can be either of the following:
-	MS-ISDN	(see clause 7.6.2.17);
-	service centre address	(see clause 7.6.2.27).
7.6.8.3	MWD status
This parameter indicates whether or not the address of the originator service centre is already contained in the Message Waiting Data file. In addition, it contains the status of the Memory Capacity Exceeded Flag (MCEF), the status of the Mobile subscriber Not Reachable Flag (MNRF), the status of the Mobile station Not Reachable for GPRS flag (MNRG), the status of the Mobile station Not Reachable for 5G-3GPP access flag (MNR5G) and the status of the Mobile station Not Reachable for 5G-Non-3GPP access flag (MNR5GN3G).
7.6.8.4	SM-RP-UI
This parameter represents the user data field carried by the short message service relay sub-layer protocol.
7.6.8.5	SM-RP-PRI
This parameter is used to indicate whether or not delivery of the short message shall be attempted when a service centre address is already contained in the Message Waiting Data file.
7.6.8.6	SM Delivery Outcome
This parameter indicates the cause for setting the message waiting data. It can take one of the following values:
-	Absent subscriber;
-	MS memory capacity exceeded;
-	Successful transfer.
7.6.8.7	More Messages To Send
This parameter is used to indicate whether or not the service centre has more short messages to send.
7.6.8.8	Alert Reason
This parameter is used to indicate the reason why the service centre is alerted. It can take one of the following values:
-	MS present;
-	Memory Available.
7.6.8.9	Absent Subscriber Diagnostic SM
This parameter is used to indicate the reason why the subscriber is absent. For the values for this parameter see 3GPP TS 23.040.
7.6.8.10	Alert Reason Indicator
This parameter indicates that the alert reason is sent to the HLR due to GPRS activity.
7.6.8.10A	Additional Alert Reason Indicator
This parameter indicates that the alert reason is sent to the HLR due to IMS activity.
7.6.8.11	Additional SM Delivery Outcome
This parameter is used to indicate the GPRS delivery outcome in case a combination between delivery outcome for GPRS and non-GPRS are sent to the HLR.
7.6.8.12	Additional Absent Subscriber Diagnostic SM
This parameter indicates the reason of the additional SM Delivery Outcome.
7.6.8.13	Delivery Outcome Indicator
This parameter indicates that the delivery outcome sent to the HLR is for GPRS.
7.6.8.14	GPRS Node Indicator
This parameter indicates by its presence that the Network Node Number sent by the HLR, SMS-Router or IP-SM-GW is to be considered as the SGSN number (although it may actually be an SMS-Router Number or IP-SM-GW Number).
7.6.8.14A	IMS Node Indicator
This parameter indicates by its presence that the Network Node Number sent by the HLR is an IP-SM-GW number. 
7.6.8.15	GPRS Support Indicator
This parameter indicates that the SMS-GMSC supports GPRS specific procedure of combine delivery of Short Message via MSC and/or via the SGSN.
7.6.8.16	SM-RP-MTI
This parameter represents the RP-Message Type Indicator of the Short Message. It is used to distinguish a SM sent to the mobile station in order to acknowledge an MO-SM initiated by the mobile from a normal MT-SM. This parameter is formatted according to the formatting rules of address fields as described in 3GPP TS 23.040.
7.6.8.17	SM-RP-SMEA
This parameter represents the RP-Originating SME-address of the Short Message Entity that has originated the SM. This parameter is used by the short message service relay sub-layer protocol and is formatted according to the formatting rules of address fields as described in 3GPP TS 23.040.
7.6.8.18	IP-SM-GW SM Delivery Outcome
This parameter is used to indicate the delivery outcome for the IMS domain.
7.6.8.19	IP-SM-GW Absent Subscriber Diagnostic SM
This parameter indicates the reason of the IP-SM-GW SM Delivery Outcome.
7.6.8.20	IP-SM-GW Indicator
This parameter indicates by its presence that sm-deliveryOutcome is for delivery via IMS.
7.6.8.21	SM Delivery Timer
This parameter indicates the SM Delivery Timer value set in the SMS-GMSC to the IP-SM-GW, SGSN or MSC/VLR. It may be taken into account by the domain selection procedure in the IP-SM-GW. Units are in seconds.
7.6.8.22	SM Delivery Start Time
This parameter indicates the timestamp (in UTC) at which the SM Delivery Supervision Timer was started in the SMS-GMSC.
7.6.8.23	Maximum Retransmission Time
This parameter indicates the maximum retransmission time (in UTC) until which the SMS-GMSC is capable to retransmit the MT Short Message. 
7.6.8.24	Requested Retransmission Time
This parameter indicates the retransmission time (in UTC) at which the SMS-GMSC is requested to retransmit the MT Short Message. 
7.6.8.25	Maximum UE Availability Time
This parameter indicates the timestamp (in UTC) until which a UE using a power saving mechanism (such as extended idle mode DRX) is expected to be reachable for SM Delivery. 
This information may be used by the SMS Center to prioritize the retransmission of Short Message to UEs using a power saving mechanism.
7.6.8.26	SMS-GMSC Alert Event
This parameter indicates the event that causes the MME (via an IWF) or the SGSN to alert the SMS-GMSC for retransmitting an MT Short Message.
7.6.8.27	SMS-GMSC Address
This parameter contains the E.164 number of the SMS-GMSC or SMS Router, in international number format as described in ITU-T Recommendation E.164 [67].
7.6.8.28	SMS-GMSC Diameter Address
This parameter contains the Diameter Identity of the SMS-GMSC or SMS Router.
7.6.8.29	New SGSN Number
This parameter contains the E.164 number of the new SGSN serving the MS.
7.6.8.30	New MME Number
This parameter contains the E.164 number of the new MME serving the MS.
7.6.8.31	New SGSN Diameter Address
This parameter contains the Diameter Identity of the new SGSN serving the MS.
7.6.8.32	New MME Diameter Address
This parameter contains the Diameter Identity of the new MME serving the MS.
7.6.8.33	New MSC Number
This parameter contains the E.164 number of the new MSC serving the MS.
7.6.8.34	SMSF 3GPP Absent Subscriber Diagnostic SM
This parameter is used to indicate the reason why the subscriber is absent for 5G 3GPP access. For the values for this parameter see 3GPP TS 23.040.
7.6.8.35	SMSF Non 3GPP Absent Subscriber Diagnostic SM
This parameter is used to indicate the reason why the subscriber is absent for 5G Non 3GPP access. For the values for this parameter see 3GPP TS 23.040.
7.6.8.36	SMSF 3GPP Delivery Outcome Indicator
This parameter indicates that the delivery outcome IE is associated to the SM delivery via the SMSF for 3GPP access.
7.6.8.37	SMSF Non-3GPP Delivery Outcome Indicator
This parameter indicates that the delivery outcome IE is associated to the SM delivery via the SMSF for Non-3GPP access.
7.6.8.38	SMSF 3GPP SM Delivery Outcome
This parameter is used to indicate the delivery outcome at the SMSF for 3GPP access.
7.6.8.39	SMSF Non-3GPP SM Delivery Outcome
This parameter is used to indicate the delivery outcome at the SMSF for non-3GPP access.
7.6.8.40	SMSF 3GPP Absent Subscriber Diagnostic SM
This parameter is used to indicate the reason why the subscriber is absent for 5G 3GPP access. For the values for this parameter see 3GPP TS 23.040.
7.6.8.41	SMSF Non 3GPP Absent Subscriber Diagnostic SM
This parameter is used to indicate the reason why the subscriber is absent for 5G Non 3GPP access. For the values for this parameter see 3GPP TS 23.040.
7.6.9	Access and signalling system related parameters
7.6.9.1	AN-apdu
This parameter includes one or two concatenated complete 3GPP TS 25.413 or 3GPP TS 48.006 [48] messages, as described in 3GPP TS 23.009 and 3GPP TS 29.010. The access network protocol ID indicates that the message or messages are according to either 3GPP TS 48.006 [48] or 3GPP TS 25.413. For the coding of the messages see 3GPP TS 25.413, 3GPP TS 48.006 [48] and 3GPP TS 48.008 [49].
7.6.9.2	CM service type
This parameter identifies the service category being requested by the subscriber:
-	mobile originating call;
-	emergency call establishment;
-	short message service;
-	mobile originating call re-establishment;
-	mobile terminating call;
-	SS request;
-	Voice group call set-up;
-	Voice broadcast set-up.
7.6.9.3	Access connection status
This parameter represents the following access connection status information:
-	RR-connection status (established/not established);
-	ciphering mode (on/off);
-	authentication status (authenticated/not authenticated).
7.6.9.4	External Signal Information
This parameter contains concatenated information elements (including tag and length) which are defined by a common protocol version, preceded by the associated protocol ID. It is used to transport information of the indicated protocol via MAP interfaces.
7.6.9.5	Access signalling information
This parameter refers to any set of information elements imported from 3GPP TS 24.008 [35].
7.6.9.6	Location update type
This parameter refers to the location update type (normal, periodic or IMSI attach) contained in the 3GPP TS 24.008 [35] LOCATION REGISTRATION REQUEST message.
7.6.9.7	Protocol ID
This parameter refers to the protocol to which the coding of the content of the associated External Signal Information conforms.
The following values are defined:
-	04.08;
-	08.06;
-	ETS 300 102-1.
This value indicates the protocol defined by ETS 300 102-1 (EDSS1).
7.6.9.8	Network signal information
This parameter is transported as external signal information. The protocol ID shall be set to "ETS 300 102-1".
The network signal information may include the following information elements as defined in 3GPP TS 29.007 [56]:
-	ISDN BC; the tag and length are defined by ETS 300 102-1.
For the content, see 3GPP TS 29.007 [56].
-	HLC; the tag and length are defined by ETS 300 102-1.
For the content, see 3GPP TS 29.007 [56].
-	LLC; the tag and length are defined by ETS 300 102-1.
For the content, see 3GPP TS 29.007 [56].
They are contained in the Signal Information parameter according to figure 7.6/1 (irrespective of the order):

Figure 7.6/1: Network signal information parameter
7.6.9.8A	Network signal information 2
This parameter is transported as additional external signal information for SCUDIF calls, described in 3GPP TS 23.172 [126]. The protocol ID and possibly included information elements are identical to Network Signal Information, defined in 7.6.9.8, "Network signal information".
7.6.9.9	Call Info
This parameter is transported as external signal information. The protocol ID shall be set to "3GPP TS 24.008 [35]".
The Call Info includes the set of information elements from the original SETUP message and is imported from 3GPP TS 24.008 [35].
7.6.9.10	Additional signal info
This parameter is transported as external signal information. The protocol ID shall be set to "ETS 300 356".
The additional signal information may include the following information elements:
-	Calling Party Number as defined by ETS 300 356.
-	Generic Number as defined by ETS 300 356.
They are contained in the Signal Information parameter according to figure 7.6/2 (irrespective of the order):

Figure 7.6/2: Additional signal information parameter
7.6.10	System operations parameters
7.6.10.1	Network resources
This parameter refers to a class or type of network resource:
-	PLMN;
-	HLR;
-	VLR (current or previous);
-	MSC (controlling or current);
-	EIR;
-	radio sub-system.
7.6.10.2	Trace reference
This parameter represents a reference associated with a GSM only tracing request as defined in 3GPP TS 52.008 [61]. The parameter is managed by OMC/EM.
7.6.10.2A	Trace reference 2
This parameter represents a reference associated with a tracing request as defined in 3GPP TS 32.421 [131] and 3GPP TS 32.422 [132]. The parameter is managed by EM.
7.6.10.3	Trace type
This parameter identifies the type of trace for GSM only tracing request. Trace types are fully defined in 3GPP TS 52.008 [61]. If the activation of the tracing is requested only for UMTS, then this parameter shall contain value "No MSC Trace" for MSC Record Type and value "No BSS Trace" for BSS Record Type.
7.6.10.4	Additional network resources
This parameter refers to a class or type of network resource:
-	SGSN;
-	GGSN;
-	GMLC;
-	gsmSCF;
-	NPLR;
-	AuC.
7.6.10.5	Trace depth list
This parameter identifies the list of depths of trace per network element. See 3GPP TS 32.422 [132].
7.6.10.6	Trace NE type list
This parameter identifies the list of network elements to be traced. See 3GPP TS 32.422 [132].
7.6.10.7	Trace interface list
This parameter identifies the list of interfaces or protocols per network element to be traced. See 3GPP TS 32.422 [132].
7.6.10.8	Trace event list
This parameter identifies the list of events per network element, which trigger a Trace Recording Session. See 3GPP TS 32.422 [132].
7.6.10.9	Trace support indicator
This parameter indicates that UMTS trace parameters are supported in the VLR or in the SGSN.
7.6.10.10	Trace Propagation List
This parameter indicates UMTS trace propagation parameters sent from one MSC to the other MSC in the signalling  for inter MSC handover/relocation. See 3GPP TS 32.422 [132].
7.6.10.11	MDT-Configuration
This parameter contains Minimization of Drive Test Configuration Data as defined in 3GPP TS 32.422 [132].
7.6.10.12	MDT User Consent
This parameter contains an indicator whether user consent for MDT activation is available or not as defined in 3GPP TS 32.422 [132].
7.6.11	Location Service Parameters 
7.6.11.1	Age of Location Estimate
This parameter indicates how long ago the location estimate was obtained.
7.6.11.2	Deferred MT-LR Response Indicator 
This parameter shows that this is a response to a deferred mt-lr request.
7.6.11.3	Deferred MT-LR Data
This parameter is used to report the deferred location event type, the location information and reason why the serving node aborted monitoring the event to the GMLC. The termination cause mt-lrRestart shall be used to trigger the GMLC to restart the location procedure in all the cases where the sending node detects that the location procedure cannot be successfully performed anymore by the sending node and that it could be successfully performed by another node (as for example when. Cancel Location or Send Identification has been received). The location information shall be included only if the termination cause is mt-lrRestart. The network node number contained in the location information refers to the node where the MS/UE has moved to and shall be included if available, like in case Send Identification has been received.
7.6.11.4	LCS Client ID
This parameter provides information related to the identity of an LCS client.
7.6.11.5	LCS Event
This parameter identifies an event associated with the triggering of a location estimate.
7.6.11.6	Void
7.6.11.7	LCS Priority
This parameter gives the priority of the location request.
7.6.11.8	LCS QoS
This parameter defines the Quality of Service (QoS) for any location request. It is composed of the following elements.
1)	Response Time
	Indicates the category of response time – "low delay" or "delay tolerant".
2)	Horizontal Accuracy
	Indicates the required horizontal accuracy of the location estimate.
3)	Vertical Coordinate
	Indicates if a vertical coordinate is required (in addition to horizontal coordinates).
4)	Vertical Accuracy
	Indicates the required vertical accuracy of the location estimate (inclusion is optional). 
5)	Velocity Request
Indicates that velocity should be returned if available (inclusion is optional).
7.6.11.9	CS LCS Not Supported by UE
This parameter is used by the VLR to indicate to the HLR that the UE does not support neither UE Based nor UE Assisted positioning metheds for Circuit Switched Location Services. VLR defines the presence of this parameter on the basis of the Classmark 3 information.
7.6.11.10	PS LCS Not Supported by UE
This parameter is used by the SGSN to indicate to the HLR that the UE does not support neither UE Based nor UE Assisted positioning metheds for Packet Switched Location Services. SGSN defines the presence of this parameter on the basis of the UE capability  information and the access technology supported by the SGSN.
7.6.11.11	Location Estimate
This parameter gives an estimate of the location of an MS in universal coordinates and the accuracy of the estimate. The estimate is expressed in terms of the geographical shapes defined  by 3GPP TS 23.032. and is composed of the type of shape plus the encoding of the shape itself. Any type of shape defined in 3GPP TS 23.032 can be filled in in the Location Estimate parameter, but only the encoding of the following shapes shall be carried by Location Estimate:
- Ellipsoid point with uncertainty circle
- Ellipsoid point with uncertainty ellipse
- Ellipsoid point with altitude and uncertainty ellipsoid
- Ellipsoid arc
- Ellipsoid point
The encoding for the remaining types of shape, defined in the 3GPP TS 23.032, shall be filled in in the Additional Location Estimate parameter.
7.6.11.11A	GERAN Positioning Data
This parameter provides positioning data associated with a successful or unsuccessful location attempt for a target MS described in 3GPP TS 49.031 [59a]. 
7.6.11.11B	UTRAN Positioning Data
This parameter provides positioning data associated with a successful location attempt for a target MS as described in 3GPP TS 25.413 [120].  It contains the positioningDataDiscriminator and positioningDataSet parts of the RANAP PositionData element only.
7.6.11.11C	GERAN GANSS Positioning Data
This parameter provides GANSS positioning data associated with a successful or unsuccessful location attempt for a target MS as described in 3GPP TS 49.031 [59a] if GANSS has been used. 
7.6.11.11D	UTRAN GANSS Positioning Data
This parameter provides GANSS positioning data associated with a successful location attempt for a target MS as described in 3GPP TS 25.413 [120] if GANSS has been used. It contains the GANSS-PositioningDataSet part of the RANAP PositionData element only.
7.6.11.11E	UTRAN Additional Positioning Data
This parameter provides additional positioning data associated with a successful location attempt for a target MS as described in 3GPP TS 25.413 [120] if Additional Positioning has been used. It contains the Additional-PositioningDataSet part of the RANAP PositionData element only.
7.6.11.11F	UTRAN Barometric Pressure Measurement
This parameter provides barometric pressure measurement associated with a successful location attempt for a target MS as described in 3GPP TS 25.413 [120]. 
7.6.11.11G	UTRAN Civic Address
This parameter provides civic address associated with a successful location attempt for a target MS as described in 3GPP TS 25.413 [120]. 
7.6.11.12	Location Type
This parameter indicates the type of location estimate required by the LCS client. Possible location estimate types include:
-	current location;
-	current or last known location;
-	initial location for an emergency services call;
-	deferred location event type;
-	notification verification only.
7.6.11.13	NA-ESRD
This parameter only applies to location for an emergency services call in North America and gives the North American Emergency Services Routing Digits.
7.6.11.14	NA-ESRK
This parameter only applies to location for an emergency services call in North America and gives the North American Emergency Services Routing Key.
7.6.11.15	LCS Service Type Id
This parameter defines the LCS Service Type of the current positioning request. The possible values are defined in 3GPP TS 22.071 [123]
7.6.11.16	Privacy Override
This parameter indicates if MS privacy is overridden by the LCS client when the GMLC and VMSC/SGSN for an MT-LR are in the same country.
7.6.11.17	Supported LCS Capability Sets
This parameter indicates which capability sets of LCS are supported in the VLR or SGSN.
7.6.11.18	LCS Codeword
This parameter contains the codeword associated to current positioning request as described in 3GPP TS 23.271 [26a].
7.6.11.19	NA-ESRK Request
This parameter allows the MSC to indicate that it requires the GMLC to allocate a  NA-ESRK based on the target MS location estimate.  This parameter only applies to emergency services calls in North America.
7.6.11.20	Supported GAD Shapes
This parameter indicates which of the shapes defined in 3GPP TS 23.032 are supported. If the parameter is not provided then the receiving node shall assume that the sending entity supports the following shapes:
- Ellipsoid point with uncertainty circle
- Ellipsoid point with uncertainty ellipse
- Ellipsoid point with altitude and uncertainty ellipsoid
- Ellipsoid arc
- Ellipsoid point
7.6.11.21	Additional Location Estimate
This parameter gives an estimate of the location of an MS/UE in universal coordinates and the accuracy of the estimate. This parameter allows the location estimate to be expressed in any of the geographical shapes defined in 3GPP TS 23.032 
7.6.11.22	Cell Id Or SAI
For GERAN access, this parameter contains the Global Cell Identifier for the cell that the subscriber is currently attached to.  For UTRAN access, this parameter contains the Service Area Identifier for the cell that the subscriber is currently attached to.
7.6.11.23	LCS-Reference Number
This parameter represents a reference between a request and a responce of a deferred mt-lr procedure as deccribed in 3GPP TS 23.271 [26a].
7.6.11.24	LCS Privacy Check
This parameter refers to the requested privacy check related actions (call/session unrelated and/or call/session related) from MSC or SGSN provided by H-GMLC. Possible requested actions are:
-	positioning allowed without notifying the UE user;
-	positioning allowed with notification to the UE user;
-	positioning requires notification and verification by the UE user; positioning is allowed only if granted by the UE user or if there is no response to the notification;
-	positioning requires notification and verification by the UE user; positioning is allowed only if granted by the UE user;
-	positioning not allowed.
7.6.11.25	Additional LCS Capability Sets
This parameter indicates which capability sets of LCS are supported in the VLR or SGSN.
7.6.11.26	Area Event Info
This parameter defines the requested deferred MT-LR area event information. The parameter consists of area definition, type of area event, occurrence info and minimum interval time.
7.6.11.27	Velocity Estimate
This parameter gives an estimate of the velocity of an MS and the accuracy of the estimate. The estimate is expressed in terms of speed and bearing as defined by 3GPP TS 23.032 [122], and is composed of the velocity terms plus the encoding of the velocity itself.  Only the encoding of the following velocity definitions shall be carried by the Velocity Estimate:
- Horizontal Velocity
- Horizontal with Vertical Velocity
- Horizontal Velocity with Uncertainty
- Horizontal with Vertical Velocity and Uncertainty
7.6.11.28	Accuracy Fulfilment Indicator
This parameter indicates the fulfilled accuracy of the positioning procedure. For details see 3GPP TS 23.271 [26a]. 
7.6.11.29	MO-LR Short Circuit Indicator
This parameter indicates whether MO-LR short circuit feature is permitted. For details see 3GPP TS 23.271 [26a].
7.6.11.30	Reporting PLMN List
This parameter provides a list of PLMNs in which subsequent periodic MO-LR TTTP requests will be made. For details see 3GPP TS 23.271 [26a].
7.6.11.31	Periodic LDR information
This parameter refers to the periodic reporting interval and reporting amount of the deferred periodic location. For details see 3GPP TS 23.271 [26a].
7.6.11.32	Sequence Number
This parameter refers to the number of the periodic location reports completed. The sequence number would be set to 1 in the first location report and increment by 1 for each new report. When the number reaches the reporting amount value, the H-GMLC (for a periodic MT-LR or a periodic MO-LR transfer to third party) will know the procedure is complete. For details see 3GPP TS 23.271 [26a].
7.6.12	Void

7.7	Representation of a list of a basic parameter in service-primitives
In some service-primitives several instances of a basic parameter of clause 7.6 are required. In the service descriptions such cases will be represented as
ParameterNameLIST
in the tables where ParameterName refers to one of the parameters defined in clause 7.6. This corresponds to the following construction rule:

Figure 7.7/1: Construction of Lists
8	Mobility services
8.1	Location management services
8.1.1	Void
8.1.1.1	Void
8.1.1.2	Void
8.1.1.3	Void
8.1.2	MAP_UPDATE_LOCATION service
8.1.2.1	Definition
This service is used by the VLR to update the location information stored in the HLR. 
This service is also used by an IWF that registers an MME as MSC for MT-SMS.
The MAP_UPDATE_LOCATION service is a confirmed service using the service primitives given in table 8.1/2.
8.1.2.2	Service primitives
Table 8.1/2: MAP_UPDATE_LOCATION
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
IMSI
M
M(=)


MSC Address
M
M(=)


VLR number
M
M(=)


LMSI
U
C(=)


Supported CAMEL Phases
C
C(=)


SoLSA Support Indicator
C
C(=)


IST Support Indicator
C
C(=)


Super-Charger Supported in Serving Network Entity
C
C(=)


Long FTN Supported
C
C(=)


Supported LCS Capability Sets
C
C(=)


Offered CAMEL 4 CSIs
C
C(=)


Inform Previous Network Entity
C
C(=)


CS LCS Not Supported by UE
C
C(=)


V-GMLC Address
U
C(=)


IMEISV
C
C(=)


Skip Subscriber Data Update
U
C(=)


Supported RAT Types Indicator
U
C(=)


Paging Area
U
C(=)


Restoration Indicator
U
C(=)


MTRF Supported
U
C(=)


Equivalent PLMN List
C
C(=)


MSISDN-less Operation Supported
C
C(=)


MME-Diameter-Address-For MT-SMS
C
C(=)


Reset-IDs Supported
C
C(=)


ADD Capability


U
C(=)
Paging Area Capability


U
C(=)
HLR number


C
C(=)
User error


C
C(=)
Provider error



O

8.1.2.3	Parameter definitions and use
Invoke Id
See definition in clause 7.6.1.
IMSI
See definition in clause 7.6.2.
MSC Address
See definition for MSC number in clause 7.6.2. The MSC address is used for short message delivery only and for each incoming call set-up attempt the MSRN will be requested from the VLR.
VLR number
See definition in clause 7.6.2.
LMSI
See definition in clause 7.6.2. It is an operator option to provide the LMSI from the VLR; it is mandatory for the HLR to support the LMSI handling procedures.
Supported CAMEL Phases
This parameter indicates which phases of CAMEL are supported. Must be present if a CAMEL phase different from phase 1 is supported. Otherwise may be absent.
HLR number
See definition in clause 7.6.2. The presence of this parameter is mandatory in case of successful HLR updating.
SoLSA Support Indicator
This parameter is used by the VLR to indicate to the HLR in the Update Location indication that SoLSA is supported. If this parameter is not included in the Update Location indication and the Subscriber is marked as only allowed to roam in Subscribed LSAs, then the HLR shall reject the roaming and indicate to the VLR that roaming is not allowed to that Subscriber in the VLR. 
This SoLSA Support Indicator shall be stored by the HLR per VLR where there are Subscribers roaming. If a Subscriber is marked as only allowed to roam in Subscribed LSAs while roaming in a VLR and no SoLSA Support indicator is stored for that VLR, the location status of that Subscriber shall be set to Restricted.
IST Support Indicator
This parameter is used to indicate to the HLR that the VMSC supports basic IST functionality, that is, the VMSC is able to terminate the Subscriber Call Activity that originated the IST Alert when it receives the IST alert response indicating that the call(s) shall be terminated. If this parameter is not included in the Update Location indication and the Subscriber is marked as an IST Subscriber, then the HLR may limit the service for the subscriber (by inducing an Operator Determined barring of Roaming, Incoming or Outgoing calls), or allow service assuming the associated risk of not having the basic IST mechanism available. 
This parameter can also indicate that the VMSC supports the IST Command service, including the ability to terminate all calls being carried for the identified subscriber by using the IMSI as a key. If this additional capability is not included in the Update Location indication and the HLR supports the IST Command capability, then the HLR may limit the service for the subscriber (by inducing an Operator Determined barring of Roaming, Incoming or Outgoing calls), or allow service assuming the associated risk of not having the IST Command mechanism available.
Long FTN Supported
This parameter indicates that the VLR supports Long Forwarded-to Numbers.
Super-Charger Supported in Serving Network Entity
This parameter is used by the VLR to indicate to the HLR that the VLR supports the Super-Charger functionality and whether subscription data has been retained by the VLR. If subscription data has been retained by the VLR the age indicator shall be included. Otherwise the VLR shall indicate that subscriber data is required.
If this parameter is absent then the VLR does not support the Super-Charger functionality.
Supported LCS Capability Sets
This parameter indicates, if present, the capability sets of LCS which are supported. If the parameter is sent but no capability set is marked as supported then the VLR does not support LCS at all.
If this parameter is absent then the VLR may support at most LCS capability set 1, that is LCS Release98 or Release99 version.
Offered CAMEL 4 CSIs 
This parameter indicates the CAMEL phase 4 CSIs offered in the VMSC/VLR (see clause 7.6.3.36D).
Inform Previous Network Entity
This parameter is used by the VLR to ask the HLR to inform the previous network entity about the update by sending the previous network entity a Cancel Location message. It is used if Super-Charger is supported in the network and either the serving network entity has not been able to inform the previous network entity that MS has moved (i.e. if it has not sent Send Identification to the previous serving entity) or the MTRF Supported flag is set in the MAP_UPDATE LOCATION request.
CS LCS Not Supported by UE
See definition in clause 7.6.11.
V-GMLC address
See definition in clause 7.6.2.
IMEISV
For definition of the parameter see clause 7.6.2. For the use of this parameter see 3GPP TS 23.012. IMEISV shall be present if ADD function is supported and a new IMEISV is to be notified to the HLR (The functional requirements for the presence of IMEISV due to ADD are described in 3GPP TS 22.101 clause 7.4).
Skip Subscriber Data Update
The presence of the parameter is optional and if present it indicates that the service is solely used to inform the HLR about change of IMEISV or Paging Area. The parameter is used to optimise signalling load during Location Update procedure. 
Supported RAT Types Indicator
This parameter indicates, if present, which access technologies (e.g. GERAN and / or UTRAN) are served by the MSC/VLR (see clause 7.6.3)
Paging Area
This parameter indicates, if present, the paging area where the MS is currently located (see clause 7.6.5.18)
Restoration Indicator
This parameter indicates, if present, that the HLR shall send in the MAP-INSERT-SUBSCRIBER-DATA the MME Name if the subscriber is registered to EPS, or the SGSN Number if available and if the subscriber is registered to GPRS. The VLR may set this indicator during a CSFB mobile originated call if the VLR performs an implicit location update (see 3GPP TS 23.272 [143]).
MTRF Supported
See 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence.
Equivalent PLMN List
This parameter indicates the equivalent PLMN list of which the VLR requests the corresponding CSG Subscription data.
MSISDN-less Operation Supported
See clause 3.6.1.5 of 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence.
MME-Diameter-Address-For-MT-SMS
This parameter may be sent by an IWF that registers an MME for MT-SMS. The MME-Diameter-Address-For-MT-SMS may be stored in the HLR and may be sent in SMS interrogation responses to SMS-GMSCs.
Reset-IDs Supported
This parameter indicates, if present, the support of Reset-IDs by the MSC.
ADD Capability
This parameter indicates, if present, the support of ADD function by the HLR.
Paging Area Capability
This parameter indicates, if present, the support of Paging Area function by the HLR. The HLR shall report the same capability for all subscribers.
User error
In case of unsuccessful updating, an error cause shall be returned by the HLR. The following error causes defined in clause 7.6.1 may be used, depending on the nature of the fault:
-	unknown subscriber;
-	roaming not allowed;
	This cause will be sent if the MS is not allowed to roam into the PLMN indicated by the VLR number. The cause is qualified by the roaming restriction reason "PLMN Not Allowed", "Supported RAT Types Not Allowed" or "Operator Determined Barring". If no qualification is received (HLR with MAP Version 1), "PLMN Not Allowed" is taken as default.
	This cause shall be used when the HLR rejects a MAP Update Location request received for an MSISDN-less subscription from a VLR not supporting MSISDN-less operation (see clause 3.6.1.5 of 3GPP TS 23.012 [23]).
-	system failure;
-	unexpected data value.
Provider error
For definition of provider errors see clause 7.6.1.
8.1.3	MAP_CANCEL_LOCATION service
8.1.3.1	Definition
This service is used between HLR and VLR to delete a subscriber record from the VLR. It may be invoked automatically when an MS moves from one VLR area to another, to remove the subscriber record from the old VLR, or by the HLR operator to enforce a location updating from the VLR to the HLR, e.g. on withdrawal of a subscription.
Also this service is used between HLR and SGSN to delete a subscriber record from the SGSN. It may be invoked automatically when an MS moves from one SGSN area to another, to remove the subscriber record from the old SGSN, or by the HLR operator to enforce a location updating from the SGSN to the HLR. This service is also used to request the SGSN to indicate to the MS to initiate an immediate re-attach procedure.
In an EPS this service is used between HSS and IWF and between IWF and IWF to delete the subscriber record from the MME or SGSN or to release bearer resources without deleting the subscriber record. This service is also used to request the MME or SGSN to indicate to the UE to initiate an immediate re-attach procedure.
The MAP_CANCEL_LOCATION service is a confirmed service using the primitives defined in table 8.1/3.
8.1.3.2	Service primitives
Table 8.1/3: MAP_CANCEL_LOCATION
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
IMSI
M
M(=)


LMSI
C
C(=)


Cancellation Type
C
C(=)


MTRF Supported And Authorized
U
C(=)


MTRF Supported And Not Authorized
U
C(=)


New MSC Number
U
C(=)


New VLR Number
U
C(=)


New LMSI
U
C(=)


Reattach Required
U
C(=)


User error


C
C(=)
Provider error



O

8.1.3.3	Parameter definitions and use
Invoke Id
See definition in clause 7.6.1.
IMSI
See definition in clause 7.6.2.
LMSI
See definition in clause 7.6.2. The LMSI shall be included if it has been received from VLR. LMSI is not applicable between SGSN and HLR.
Value 0000 0000 can be used to indicate that the LMSI is not in use.
Cancellation Type
See definition in clause 7.6.3. The presence of this parameter is mandatory when the Cancel Location is sent to the SGSN or IWF. The parameter may also be sent during an inter-VLR location update If the VLR receives this parameter and does not understand it the VLR shall ignore it and should by default assume an Update procedure. If the SGSN receives this parameter indicating initial attach procedure, the SGSN shall do as specified in 3GPP TS 23.060 [104], and shall not delete the subscription data.
MTRF Supported And Authorized
See 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence.
MTRF Supported And Not Authorized
See 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence.
New MSC Number
This parameter refers to the E.164 address of the new VMSC. The use and conditions of presence of this parameter are specified in 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23]. This parameter shall be present if the MTRF Supported And Authorized flag is present.
New VLR Number
This parameter contains the new VLR Number. See definition in clause 7.6.2. The use and conditions of presence of this parameter are specified in 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23]. This parameter shall be present if the MTRF Supported And Authorized flag is present.
New LMSI
See definition in clause 7.6.2 for LMSI. This parameter shall be present if the MTRF Supported And Authorized flag is present and the HLR has received the LMSI in Update Location from the new VLR.
Reattach Required
When present and when the Cancellation Type indicates a subscription withdraw, this parameter indicates that the MME (informed via the IWF) or the SGSN shall delete the subscription data and request the UE or MS to initiate an immediate re-attach procedure as described in 3GPP TS 23.401 [145] and in 3GPP TS 23.060 [12].
User error
If the cancellation fails, an error cause is to be returned by the VLR or by the SGSN or IWF. One of the following error causes defined in clause 7.6.1 shall be used:
-	unexpected data value;
-	data missing.
Provider error
For definition of provider errors see clause 7.6.1.
8.1.4	MAP_SEND_IDENTIFICATION service
8.1.4.1	Definition
The MAP_SEND_IDENTIFICATION service is used between a VLR and a previous VLR to retrieve IMSI and authentication data for a subscriber registering afresh in that VLR. 
It may also be used to send the MSC number from a VLR to a previous VLR.
The MAP_SEND_IDENTIFICATION service is a confirmed service using the service primitives defined in table 8.1/4.
8.1.4.2	Service primitives
Table 8.1/4: MAP_SEND_IDENTIFICATION
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
TMSI
M
M(=)


Number of requested vectors
M
M(=)


Segmentation prohibited indicator
C
C(=)


MSC Number
U
C(=)


Previous Location Area Id
U
C(=)


Hop Counter
U
C (=)


MTRF Supported
U
C(=)


VLR Number
U
C(=)


New LMSI
U
C(=)


IMSI


C
C(=)
Authentication set


U
C(=)
Current Security Context


U
C(=)
MT call pending flag


U
C(=)
Last used LTE PLMN ID	


U
C(=)
User error


C
C(=)
Provider error



O

8.1.4.3	Parameter definitions and use
Invoke Id
See definition in clause 7.6.1.
TMSI
See definition in clause 7.6.2. 
If multiple service requests are present in a dialogue then this parameter shall be present in every service request.
Number of requested vectors
A number indicating how many authentication vectors the new VLR is prepared to receive. The previous VLR shall not return more vectors than indicated by this parameter. 
This parameter shall be present in the first (or only) request of the dialogue. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one
Segmentation prohibited indicator
This parameter indicates if the new VLR or SGSN allows segmentation of the response at MAP user level. 
This parameter may be present only in the first request of the dialogue.
IMSI
See definition in clause 7.6.2. The IMSI is to be returned if the service succeeds. 
If multiple service requests are present in a dialogue and the service succeeds then this parameter shall not be present in any service response other than the first one
MSC Number
This is the ISDN number assigned to the MSC currently serving the MS. This parameter shall be present if the MTRF Supported flag is present.
Previous Location Area Id
See definition in clause 7.6.2. Together with the TMSI the Previous Location Area Id can be used to derive the IMSI.
Authentication set
See definition in clause 7.6.7. If the service succeeds a list of up to five authentication sets is returned, if there are any available.
Current Security Context 
See definition in clause 7.6.7. If the service succeeds, a list of either GSM or UMTS Security Context parameters can be returned. 
This parameter shall not be included if the Key Status associated to the current security context indicates this is a new keyset that has not been used yet. If this parameter is present in the message, the new VLR shall consider that the keyset has already been used (i.e. the key status is "old").
MT call pending flag 
This flag indicates by its presence that there is a Mobile Terminating call pending in the old MSC/VLR. See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence.
Hop Counter 
For the use of this parameter see 3GPP TS 23.012 [23]. 
MTRF Supported
See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence.
VLR Number
This is the ISDN number assigned to the VLR currently serving the MS. See definition in clause 7.6.2. The use and conditions of presence of this parameter are specified in 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23]. This parameter shall be present if the MTRF Supported flag is present.
New LMSI
See definition in clause 7.6.2 for LMSI. This parameter may be present if the MTRF Supported flag is present.
Last used LTE PLMN ID
See 3GPP TS 23.272 [143] for the use of this parameter and the conditions for its presence.
User error
This parameter is mandatory if the service fails. The following error cause defined in clause 7.6.1 may be used, depending on the nature of the fault:
-	unidentified subscriber.
Provider error
For definition of provider errors see clause 7.6.1.
8.1.5	Void
8.1.5.1	Void
8.1.5.2	Void
8.1.5.3	Void
8.1.6	MAP_PURGE_MS service
8.1.6.1	Definition
This service is used between the VLR and the HLR to cause the HLR to mark its data for an MS so that any request for routing information for a mobile terminated call or a mobile terminated short message will be treated as if the MS is not reachable. It is invoked when the subscriber record for the MS is to be deleted in the VLR, either by MMI interaction or automatically, e.g. because the MS has been inactive for several days. This service shall not be used if both the VLR and HLR support the Super-Charger functionality.
Also this service is used between the SGSN and the HLR to cause the HLR to mark its data for an MS so that any request for routing information for a mobile terminated short message or a network requested PDP-context activation will be treated as if the MS is not reachable. It is invoked when the subscriber record for the MS is to be deleted in the SGSN, either by MMI interaction or automatically, e.g. because the MS has been inactive for several days. This service shall not be used if both the SGSN and HLR support the Super-Charger functionality. 
In an EPS this service is used between IWF and IWF and between IWF and HSS.
The MAP_PURGE_MS service is a confirmed service using the primitives defined in table 8.1/6.
8.1.6.2	Service primitives
Table 8.1/6: MAP_PURGE_MS
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
IMSI
M
M(=)


VLR number
C
C(=)


Freeze TMSI


C
C(=)
Freeze P-TMSI


C
C(=)
Freeze M-TMSI


C
C(=)
SGSN number
C
C(=)


Last known location
C
C(=)


User error


C
C(=)
Provider error



O

8.1.6.3	Parameter definitions and use
Invoke ID
See definition in clause 7.6.1.
IMSI
See definition in clause 7.6.2.
VLR number
Shall be present if the sender is VLR. See definition in clause 7.6.2.
SGSN number
Shall be present if the sender is SGSN. See definition in clause 7.6.2. 
In an EPS, this parameter may contain the IWF number.
Freeze TMSI
This parameter is sent to the VLR to indicate that the TMSI has to be frozen. It shall be present if the received VLR number matches the stored VLR number.
Freeze P-TMSI
This parameter is sent to the SGSN to indicate that the P-TMSI has to be frozen. It shall be present if the received SGSN number matches the stored SGSN number.
Freeze M-TMSI
This parameter is sent to the IWF to indicate that the M-TMSI has to be frozen. It shall be present if the received node number matches the stored IWF number.
Last known location
This parameter contains the last known location of the purged UE.
User error
This parameter is sent by the responder when an error is detected and if present, takes one of the following values:
-	Data Missing;
-	Unexpected Data Value;
-	Unknown Subscriber.
Provider error
See definition of provider errors in clause 7.6.1.
8.1.7	MAP_UPDATE_GPRS_LOCATION service
8.1.7.1	Definition
This service is used by the SGSN to update the location information stored in the HLR. 
In an EPS, this service is used between IWF and IWF and between IWF and HSS.
The MAP_UPDATE_GPRS_LOCATION service is a confirmed service using the service primitives given in table 8.1/7.
8.1.7.2	Service primitives
Table 8.1/7: MAP_UPDATE_GPRS_LOCATION
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
IMSI
M
M(=)


SGSN number
M
M(=)


SGSN address
M
M(=)


Supported CAMEL Phases
C
C(=)


SoLSA Support Indicator
C
C(=)


Super-Charger Supported in Serving Network Entity
C
C(=)


GPRS enhancements support indicator
C
C(=)


Supported LCS Capability Sets
C
C(=)


Offered CAMEL 4 CSIs
C
C(=)


Inform Previous Network Entity
C
C(=)


PS LCS Not Supported by UE
C
C(=)


V-GMLC Address
U
C(=)


Call barring support indicator
C
C(=)


IMEISV
C
C(=)


Skip Subscriber Data Update
U
C(=)


Supported RAT Types Indicator
U
C(=)


EPS Info
C
C(=)


Serving Node Type Indicator
C
C(=)


Supported Features
U
C(=)


Used RAT Type
U
C(=)


GPRS Subscription Data not needed Indicator
C
C(=)


EPS Subscription Data Not Needed Indicator
C
C(=)


Node-Type-Indicator
U
C(=)


Area Restricted Indicator
C
C(=)


UE Reachable Indicator
C
C(=)


T-ADS Data Retrieval Support Indicator
C
C(=)


Homogeneous Support Of IMS Voice Over PS Sessions
C
C(=)


Update of Homogeneous Support Of IMS Voice Over PS Sessions
C
C(=)


UE SRVCC Capability
C
C(=)


Equivalent PLMN List
C
C(=)


MME Number for MT SMS
C
C(=)


SMS-Only
C
C(=)


SMS Register Request
C
C(=)


Removal of MME Registration for SMS
C
C(=)


MSISDN-less Operation Supported
C
C(=)


SGSN Name
C
C(=)


SGSN Realm
C
C(=)


Lgd Support Indicator
C
C(=)


Adjacent-PLMNs
C
C(=)


Reset-IDs Supported
C
C(=)


ADD Capability


U
C(=)
SGSN-MME Separation Support Indicator


C
C(=)
HLR number


C
C(=)
MME Registered for SMS


C
C(=)
User error


C
C(=)
Provider error



O

8.1.7.3	Parameter definitions and use
Invoke Id
See definition in clause 7.6.1.
IMSI
See definition in clause 7.6.2.
SGSN number
See definition in clause 7.6.2. 
In an EPS, this parameter is populated with an IWF number if received from an IWF.
SGSN address
See definition in clause 7.6.2. 
In an EPS, this parameter is populated with an IWF address if received from an IWF.
Supported CAMEL Phases
This parameter indicates which phases of CAMEL are supported. The SGSN can only support CAMEL phase 3 or greater.
SoLSA Support Indicator
This parameter is used by the SGSN to indicate to the HLR in the Update GPRS Location indication that SoLSA is supported. If this parameter is not included in the Update GPRS Location indication and the Subscriber is marked as only allowed to roam in Subscribed LSAs, then the HLR shall reject the roaming and indicate to the SGSN that roaming is not allowed to that Subscriber in the SGSN.
This SoLSA Support Indicator shall be stored by the HLR per SGSN where there are Subscribers roaming. If a Subscriber is marked as only allowed to roam in Subscribed LSAs while roaming in a SGSN and no SoLSA Support indicator is stored for that SGSN, the location status of that Subscriber has to be set to Restricted.
Super-Charger Supported in Serving Network Entity
This parameter is used by the SGSN to indicate to the HLR that the SGSN supports the Super-Charger functionality and whether subscription data has been retained by the SGSN. If subscription data has been retained by the SGSN the age indicator shall be included. Otherwise the SGSN shall indicate that subscriber data is required.
If this parameter is absent then the SGSN does not support the Super-Charger functionality.
GPRS enhancements support indicator
This parameter is used by the SGSN to indicate to the HLR in the Update GPRS Location indication that GPRS enhancements are supported. If this parameter is included in the Update GPRS Location indication the HLR may send the extension QoS parameter in the PDP contexts to the SGSN. The HLR may send the extension-2 QoS, the extension-3 QoS and the extension-4 QoS parameters with the extension QoS parameter.
HLR number
See definition in clause 7.6.2. The presence of this parameter is mandatory in case of successful HLR updating.
Supported LCS Capability Sets
This parameter indicates, if present,  the capability sets of LCS which are supported. If the parameter is sent but no capability set is marked as supported then the SGSN does not support LCS at all.
The SGSN is not allowed to indicate support for LCS capability set 1.  
If this parameter is absent then the SGSN does not support LCS at all.
Offered CAMEL 4 CSIs 
This parameter indicates the CAMEL phase 4 CSIs offered in the SGSN (see clause 7.6.3.36D).
Inform Previous Network Entity
This parameter is used by the SGSN to ask the HLR to inform the previous network entity about the update by sending the previous network entity a Cancel Location message. It is used in case Super-Charger is supported in the network and the serving network entity has not been able to inform the previous network entity that MS has moved, that is if it has not sent SGSN Context Request to the previous serving entity.
PS LCS Not Supported by UE
See definition in clause 7.6.11.
V-GMLC address
See definition in clause 7.6.2.
Call Barring support indicator
See definition in clause 7.6.3.92.
IMEISV
For definition of the parameter see clause 7.6.2. For the use of this parameter see 3GPP TS 23.060. IMEISV shall be present if ADD function is supported and the IMEISV is new in SGSN (The functional requirements for the presence of IMEISV due to ADD are described in 3GPP TS 22.101 clause 7.4).
Skip Subscriber Data Update
The presence of the parameter is optional and if present it indicates that subscriber data download during the updateGprsLocation procedure may be skipped by the HLR e.g. because the service is solely used to inform the HLR about change of IMEISV. The parameter is used to optimise signalling load during Location Update procedure. 
Supported RAT Types Indicator
This parameter indicates, if present, which access technologies (e.g. GERAN and/or UTRAN and/or E-UTRAN) are served by the SGSN or MME (see clause 7.6.3)
EPS Info
This parameter may indicate that the MME or SGSN has selected a new PDN GW for an APN. If so, the HSS shall skip subscriber data update (insert subscriber data) and only note the new PDN GW.
Otherwise this parameter may indicate the appropriate instruction to be performed by the HSS which is one or more of
a)	Update Location; i.e. send CancelLocation to the old MME and replace the stored MME id (if Serving Node Type Indicator is present and the stored MME id is different from the received MME id), or send CancelLocation to the old SGSN and replace the stored SGSN id (if Serving Node Type Indicator is absent and the stored SGSN id is different from the received SGSN id);
b)	Cancel SGSN; i.e. send CancelLocation to the SGSN and delete the stored SGSN id.
c)	Initial Attach; i.e. send CancelLocation to the MME (if Serving Node Type Indicator is absent) or to the SGSN (if Serving Node Type Indicator is present) with cancellation type set to "initial attach procedure"
Serving Node Type Indicator
This parameter indicates by its presence that the subscriber's serving node is an MME (which is either stand alone or combined with an SGSN) and it indicates by its absence that the subscriber's serving node is an SGSN (which is either stand alone or combined with an MME).
Supported Features
This parameter shall be used by an IWF to forward feature support indications as received from the MME or SGSN via S6a/S6d. It shall also be used by the SGSN to indicate support of the Dedicated Core Network functionality to the HLR.
Used RAT Type
This parameter may indicate the RAT type currently used by the serving node.
GPRS Subscription Data not needed Indicator
This parameter indicates by its presence that the SGSN (or MME/IWF) does not request GPRS Subscription Data in addition to EPS Subscription Data.
EPS Subscription Data Not Needed Indicator
This parameter indicates by its presence that the SGSN does not request EPS Subscription Data in addition to GPRS Subscription Data.
NOTE:	The indicator is only applicable to an SGSN which only supports Gn and Gp interfaces and does not support S4 interface.
Node-Type Indicator
This parameter indicates by its presence that the requesting node is a combined MME/SGSN. Absence of this Indicator indicates that the requesting node is a single MME or SGSN.
When Node-Type Indicator is absent and Serving Node Type Indicator is present, the HSS may skip checking SMS/LCS supported features and skip the download of SMS/LCS-related subscription data to a standalone MME.
Area Restricted Indicator
This parameter indicates by its presence that the network node area is restricted due to regional subscription. This parameter is used by the IWF only.
UE-Reachable Indicator
This parameter indicates by its presence that the UE is reachable. 
NOTE:	In general any UpdateGPRS-Location request message (with or without UE-Reachable Indicator) implicitly conveys the information that the UE is now reachable. 
This explicit indicator shall be set only when UpdateGPRS-Location is used for the only and no other purpose than indicating UE reachability. The HLR shall skip subscriber data downloading and any mobility management functionality other than reporting the UE's reachability to relevant core network entities.
T-ADS Data Retrieval Support Indicator
This parameter indicates by its presence that the SGSN supports retrieval of T-ADS data with the Provide-Subscriber-Info service.
Homogeneous Support Of IMS Voice Over PS Sessions 
This parameter when present indicates that IMS voice over PS sessions is homogeneously supported in the complete SGSN area or that IMS voice over PS sessions is homogeneously not supported in the complete SGSN area. 
Update of Homogeneous Support Of IMS Voice Over PS Sessions
This parameter when present indicates that Homogeneous Support of IMS Voice Over PS Sessions is updated. If the Homogeneous Support of IMS Voice Over PS Session is not present, the value of the Homogeneous Support of IMS Voice Over PS Sessions shall be updated as unknown to the serving node.
UE SRVCC Capability
See definition in clause 7.6.3.99. 
Equivalent PLMN List
This parameter indicates the equivalent PLMN list of which the MME/SGSN requests the corresponding CSG Subscription data.
MME Number for MT SMS
This parameter contains the ISDN number of the MME allocated for MT SMS (see 3GPP TS 23.003 [17]). It is present when the MME requests to be registered for SMS.
SMS-Only
This parameter indicates to the HSS that the UE needs only PS domain services and SMS services.
SMS Register Request
This parameter indicates to the HSS that if the MME (via IWF) needs to be registered for SMS, prefers not to be registered for SMS or has no preference to be registered for SMS, see 3GPP TS 23.272 [143]. 
This parameter indicates to the HSS that if the SGSN needs to be registered for SMS, prefers not to be registered for SMS or has no preference to be registered for SMS, see 3GPP TS 23.060 [104]. 
Removal of MME Registration for SMS
This parameter indicates by its presence that the MME requests to remove its registration for SMS.
MSISDN-less Operation Supported
This parameter indicates by its presence that the SGSN supports MSISDN-less operation (see clause 5.3.17 of 3GPP TS 23.060 [23]). An SGSN which supports MSISDN-less operation shall set this parameter. 
SGSN Name
See definition in clause 7.6.2. This parameter is provided in a request when the serving node is an SGSN and the SGSN supports Lgd interface for LCS and/or Gdd interface for SMS.
SGSN Realm
See definition in clause 7.6.2. This parameter is provided in a request when the serving node is an SGSN and the SGSN supports Lgd interface for LCS and/or Gdd interface for SMS.
Lgd Support Indicator
This parameter, by its presence, indicates to the HSS that the SGSN supports Lgd interface for LCS. When absent the SGSN supports only Lg interface for LCS, if LCS is supported.
Adjacent PLMNs
This parameter indicates the list of PLMNs where an UE served by the SGSN is likely to make a handover from the PLMN where the SGSN is located. This list is statically configured by the operator in the SGSN, according to the geographical disposition of the different PLMNs in that area, the roaming agreements, etc...
Reset-IDs Supported
This parameter indicates, if present, the support of Reset-IDs by the SGSN.
ADD Capability
This parameter indicates, if present, the support of ADD function by the HLR.
SGSN-MME Separation Support Indicator
This parameter indicates by its presence that the HSS separately stores SGSN Id and MME Id. A combined MME/SGSN shall not send Update-GPRS-Location at intra node inter RAT routing area update if a Separation Indicator was not received previously. 
MME Registered for SMS
This parameter indicates by its presence that the HSS has registered the MME for SMS.
User error
In case of unsuccessful updating, an error cause shall be returned by the HLR. The following error causes defined in clause 7.6.1 may be used, depending on the nature of the fault:
-	unknown subscriber;
-	roaming not allowed.
	This cause will be sent if the MS is not allowed to roam into the PLMN indicated by the SGSN number. The cause is qualified by the roaming restriction reason "PLMN Not Allowed", "Supported RAT Types Not Allowed" or "Operator Determined Barring".
	This cause shall be used when the HLR rejects a MAP Update Gprs Location request received for an MSISDN-less subscription from a SGSN not supporting MSISDN-less operation.
-	system failure;
-	unexpected data value.
The diagnostic in the Unknown Subscriber may indicate "Imsi Unknown" or "Gprs or EPS Subscription Unknown".
Provider error
For definition of provider errors see clause 7.6.1.
8.1.8	MAP-NOTE-MM-EVENT
8.1.8.1	Definition
This service is used between the VLR and the gsmSCF or between the SGSN and the gsmSCF when a mobility management event for a subscriber has been processed successfully, that subscriber is provisioned with M-CSI or MG-CSI and the relevant mobility management event is marked for reporting.
This service is also used between the VLR and the Presence Network Agent or between the SGSN and the Presence Network Agent to notify the Presence Network Agent when a mobility management event for a subscriber has been processed successfully, that subscriber is provisioned with M-CSI or MG-CSI and the relevant mobility management event is marked for reporting (see 3GPP TS 23.141 [128]). 
8.1.8.2	Service primitives
The service primitives are shown in table 8.1/8.
Table 8.1/8: MAP_NOTE_MM_EVENT parameters
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
Event Met
M
M(=)


Service Key
M
M(=)


IMSI
M
M(=)


Basic MSISDN
M
M(=)


Location Information for GPRS
C
C(=)


Location Information
C
C(=)


LSA Identity
C
C(=)


Supported CAMEL Phases
M
M(=)


 Offered CAMEL 4 Functionalities
C
C(=)


User error


C
C(=)
Provider error



O

8.1.8.3	Parameter use
Event Met
This parameter indicates the mobility management event that has lead to the notification. It shall have one of the following values for a mobility management event reported by the VLR:
-	Location update in the same VLR service area;
-	Location update to another VLR service area;
-	IMSI attach;
-	MS initiated IMSI detach (explicit detach);
-	Network initiated IMSI detach (implicit detach).
It shall have one of the following values for a mobility management event reported by the SGSN:
-	Routeing area update in the same SGSN service area;
-	Routeing area update to another SGSN service area;
-	GPRS attach;
-	MS initiated GPRS detach;
-	Network initiated GPRS detach;
-	Network initiated transfer to the "not reachable for paging" state.
Service Key
See clause 7.6.x.
IMSI
See clause 7.6.x.
Basic MSISDN
See clause 7.6.x.
Location Information
See clause 7.6.2.30. This information shall be sent when the event is reported by a VLR, if available. If the event is reported as part of an SGs location update procedure, this information shall include the LAI and the Location Information for EPS if available.
Location Information for GPRS
See clause 7.6.2.30a. This information shall be sent when the event is reported by an SGSN, if available.
LSA Identity
See clause 7.6.x. This information shall be sent, if available.
Supported CAMEL Phases
See clause 7.6.x. This information shall always be sent.
Offered CAMEL 4 Functionalities 
This parameter indicates the CAMEL phase 4 functionalities offered by the sending entity, VMSC/VLR or SGSN (see clause 7.6.3.36G).
User error
This parameter is sent by the receiving entity when an error is detected. It shall have one of the following values:
-	Data Missing;
-	Unexpected Data Value;
-	Unknown Subscriber;
-	MM-EventNotSupported.
Provider error
This is defined in clause 7.6.1.
8.1.9	MAP_UPDATE_VCSG_LOCATION service
8.1.9.1	Definition
This procedure is used by the VLR or SGSN to register the MS in the CSS when
-	the VPLMN supports Autonomous CSG Roaming
-	and the HPLMN has enabled Autonomous CSG Roaming in the VPLMN 
-	and the MS has requested an initial attach or a location area procedure or a routing area procedure to a CSG cell 
-	and the VLR or SGSN has not yet registered the MS in the CSS.
The MAP_UPDATE_VCSG_LOCATION service is a confirmed service using the service primitives given in table 8.1/9.
8.1.9.2	Service primitives
Table 8.1/9: MAP_UPDATE_VCSG_LOCATION
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
IMSI
M
M(=)


VLR number
C
C(=)


SGSN number
C
C(=)


MSISDN
C
C(=)


Temporary Empty CSG Subscription data Indicator


C
C(=)
User error


C
C(=)
Provider error



O

8.1.9.3	Parameter definitions and use
Invoke Id
See definition in clause 7.6.1.
IMSI
See definition in clause 7.6.2.
VLR number
See definition in clause 7.6.2. The presence of this parameter is mandatory when the service is used by the VLR.
SGSN number
See definition in clause 7.6.2. The presence of this parameter is mandatory when the service is used by the SGSN.
MSISDN
See definition in clause 7.6.2. Shall be present if this parameter is available. 
Temporary Empty CSG Subscription data Indicator
See definition in clause 7.6.3.100. This parameter shall be present if the CSS accepts the request and there is no CSG Subscription data (empty CSG-ID list) for the roaming MS in the CSS.
User error
The following error causes defined in clause 7.6.1 may be used:
-	unknown subscriber; 
-	system failure;
-	unexpected data value.
Provider error
For definition of provider errors see clause 7.6.1
8.1.10	MAP_ CANCEL_VCSG_LOCATION service
8.1.10.1	Definition
This service is used between CSS and VLR to delete a roaming user record including the CSG subscription data and the CSS number from the VLR. The service is also used between CSS and SGSN to delete a roaming user record including the CSG subscription data and the CSS number from the SGSN. It may be invoked when there is removal of the CSG subscription data in CSS and of the MS registration including the case where a MS was registered in CSS but without CSG data.
The MAP_CANCEL_VCSG_LOCATION service is a confirmed service using the primitives defined in table 8.1/10.
8.1.10.2	Service primitives
Table 8.1/10: MAP_CANCEL_VCSG_LOCATION
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
IMSI
M
M(=)


User error


C
C(=)
Provider error



O

8.1.10.3	Parameter definitions and use
Invoke Id
See definition in clause 7.6.1.
IMSI
See definition in clause 7.6.2. 
User error
If the cancellation fails, an error cause is to be returned by the VLR or by the SGSN. One of the following error causes defined in clause 7.6.1 shall be used:
-	unexpected data value;
-	data missing.
Provider error
For definition of provider errors see clause 7.6.1.
8.2	Paging and search
8.2.1	MAP_PAGE service
8.2.1.1	Definition
This service is used between VLR and MSC to initiate paging of an MS for mobile terminated short message or unstructured SS notification.
The MAP_PAGE service is a confirmed service using the primitives from table 8.2/1.
8.2.1.2	Service primitives
Table 8.2/1: MAP_PAGE
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
IMSI
M
M(=)


Stored location area Id
M
M(=)


TMSI
U
C(=)


User error


C
C(=)
Provider error



O

8.2.1.3	Parameter definitions and use
Invoke Id
See definition in clause 7.6.1.
IMSI
See definition in clause 7.6.2. The IMSI is used to define the paging subgroup. If the TMSI is not supplied, paging on the radio path uses the IMSI as an identifier.
Stored location area Id
See definition in clause 7.6.2.
TMSI
See definition in clause 7.6.2. The TMSI is included if paging on the radio channel is to use the TMSI as an identifier.
User error
The following error causes defined in clause 7.6.1 may be sent by the user in case of a paging error, depending on the failure reason:
-	absent subscriber;
-	unknown location area;
-	busy subscriber;
-	system failure;
-	this corresponds to the case where there is no call associated with the MAP_PAGE service, i.e. if the call has been released but the dialogue to the VLR has not been aborted;
-	unexpected data value.
Provider error
See definition in clause 7.6.1.
8.2.2	MAP_SEARCH_FOR_MS service
8.2.2.1	Definition
This service is used between VLR and MSC to initiate paging of an MS in all location areas of that VLR. It is used if the VLR does not hold location area information confirmed by radio contact.
The MAP_SEARCH_FOR_MS service is a confirmed service using the primitives from table 8.2/2.
8.2.2.2	Service primitives
Table 8.2/2: MAP_SEARCH_FOR_MS
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
IMSI
M
M(=)


Current location area Id


C
C(=)
User error


C
C(=)
Provider error



O

8.2.2.3	Parameter definitions and use
Invoke Id
See definition in clause 7.6.1.
IMSI
See definition in clause 7.6.2. The IMSI is used to identify the subscriber when paging on the radio path.
Current location area Id
See definition in clause 7.6.2. In case of successful outcome of the service, i.e. if the MS responds to paging, the Location Area Id of the area in which the MS responded is given in the response.
User error
The following error causes defined in clause 7.6.1 shall be sent by the user if the search procedure fails, depending on the failure reason:
-	absent subscriber;
	this error cause is returned by the MSC if the MS does not respond to the paging request;
-	system failure;
-	this corresponds to the case where there is no call associated with the MAP_SEARCH_FOR_MS service, i.e. if the call has been released but the dialogue to the VLR has not been aborted;
-	busy subscriber;
-	unexpected data value.
Provider error
See definition in clause 7.6.1.
8.3	Access management services
8.3.1	MAP_PROCESS_ACCESS_REQUEST service
8.3.1.1	Definition
This service is used between MSC and VLR to initiate processing of an MS access to the network, e.g. for mobile originated short message submission or after being paged by the network.
The MAP_PROCESS_ACCESS_REQUEST service is a confirmed service using the primitives from table 8.3/1.
8.3.1.2	Service primitives
Table 8.3/1: MAP_PROCESS_ACCESS_REQUEST
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
CM service type
M
M(=)


Access connection status
M
M(=)


Current Location Area Id
M
M(=)


Serving cell Id
M
M(=)


TMSI
C
C(=)


Cksn
C
C(=)


IMSI
C
C(=)
C
C(=)
IMEI
C
C(=)
C
C(=)
MSISDN


U
C(=)
User error


C
C(=)
Provider error



O

8.3.1.3	Parameter definitions and use
Invoke Id
See definition in clause 7.6.1.
CM service type
See definition in clause 7.6.9.
Access connection status
See definition in clause 7.6.9.
Current Location Area Id
See definition in clause 7.6.2. This parameter is used to update the VLR in case of previous VLR failure.
Serving cell Id
See definition in clause 7.6.2.
TMSI
See definition in clause 7.6.2. Either TMSI or IMSI as received from the MS are included in the Request/Indication, but one shall be present. In case of CM Service Type "Emergency Call Establishment", the IMEI may replace IMSI/TMSI.
Cksn
See definition in clause 7.6.7. In case of access with TMSI, the Cksn shall be present.
IMSI
See definition in clause 7.6.2. Either TMSI or IMSI as received from the MS are included in the Request/Indication, but one shall be present. In case of CM Service Type "Emergency Call Establishment", the IMEI may replace IMSI/TMSI.
In the Response/Confirmation, the IMSI is to be sent in case of successful outcome of the service. In case of CM Service Type "Emergency Call Establishment", IMEI may replace IMSI.
IMEI
See definition in clause 7.6.2. The IMEI may replace IMSI/TMSI in the Request/Indication and IMSI in the Response/Confirmation only in case the CM Service Type indicates "Emergency Call Establishment".
MSISDN
See definition in clause 7.6.2. The MSISDN is included in case of successful outcome of the service as an operator option, e.g. if it is needed at the MSC for charging purposes in case of call forwarding.
User error
One of the following error causes defined in clause 7.6.1 shall be sent by the user if the access request fails, depending on the failure reason:
-	unidentified subscriber;
-	illegal subscriber;
	this error is sent if a correlated authentication procedure has not authenticated the subscriber;
-	illegal equipment;
	this error is sent if an IMEI check failed, i.e. the IMEI is blacklisted or not white-listed;
-	roaming not allowed;
-	this cause is used after VLR restart if the subscriber has no subscription for the current location area, e.g. due to regional subscription. The cause will be qualified by "location area not allowed" or "national roaming not allowed", respectively;
-	unknown location area;
-	system failure;
-	unexpected data value.
Provider error
For definition of provider errors see clause 7.6.1.
8.4	Handover services
It should be noted that the handover services used on the B-interface have not been updated for Release 99. The B-interface is not fully operational specified. It is strongly recommended not to implement the B-interface as an external interface.
8.4.1	MAP_PREPARE_HANDOVER service
8.4.1.1	Definition
This service is used between MSC-A and MSC-B (E-interface) when a call is to be handed over or relocated from MSC‑A to MSC‑B.
The MAP_PREPARE_HANDOVER service is a confirmed service using the primitives from table 8.4/1.
8.4.1.2	Service primitives
Table 8.4/1: MAP_PREPARE_HANDOVER
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
Target Cell Id
C
C(=)


Target RNC Id
C
C(=)


HO-NumberNotRequired
C
C(=)


IMSI
C
C(=)


Integrity Protection Information
C
C(=)


Encryption Information
C
C(=)


Radio Resource Information
C
C(=)


AN-APDU
C
C(=)
C
C(=)
Allowed GSM Algorithms
C
C(=)


Allowed UMTS Algorithms
C
C(=)


Radio Resource List
C
C(=)


RAB ID
C
C(=)


GERAN Classmark
C
C(=)


BSSMAP Service Handover
C
C(=)


BSSMAP Service Handover List
C
C(=)


RANAP Service Handover
C
C(=)


Iu-Currently Used Codec
C
C(=)


Iu-Supported Codecs List
C
C(=)


RAB Configuration Indicator
C
C(=)


ASCI Call Reference
C
C(=)


UESBI-Iu
C
C(=)


IMEISV
C
C(=)


Alternative Channel Type
C
C(=)


Trace_Propagation_List
C
C(=)


AoIP-Supported Codecs List Anchor 
C
C(=)


Regional Subscription Data
U
(C=)


CSG Subscription Data
U
(C=)


LCLS Global Call Reference
C
C(=)


LCLS-Negotiation
C
C(=)


LCLS-Configuration-Preference
C
C(=)


Multiple Bearer Requested
C
C(=)


Handover Number


C
C(=)
Relocation Number List


C
C(=)
Multicall Bearer Information


C
C(=)
Multiple Bearer Not Supported


C
C(=)
Selected UMTS Algorithms


C
C(=)
Chosen Radio Resource Information


C
C(=)
Iu-Selected Codec


C
C(=)
Iu-Available Codecs List


C
C(=)
AoIP-Selected Codec Target


C
C(=)
AoIP-Available Codecs List Map


C
C(=)
User error


C
C(=)
Provider error



O

8.4.1.3	Parameter use
Invoke Id
For definition of this parameter see clause 7.6.1.
Target Cell Id
For definition of this parameter see clause 7.6.2. This parameter is only included if the service is not in an ongoing transaction. This parameter shall also be excluded if the service is a part of the Inter-MSC SRNS Relocation procedure or the inter-system handover GSM to UMTS procedure described in 3GPP TS 23.009.
Target RNC Id
For definition of this parameter see clause 7.6.2. This parameter shall be included if the service is a part of the Inter-MSC SRNS Relocation procedure or the inter-system handover GSM to UMTS procedure described in 3GPP TS 23.009.
HO-Number Not Required
For definition of this parameter see clause 7.6.6.
IMSI
For definition of this parameter see clause 7.6.2. This UMTS parameter shall be included if:
-	available and 
-	if the access network protocol is BSSAP and 
-	there is an indication that the MS also supports UMTS.
Integrity Protection Information
For definition of this parameter see clause 7.6.6. This UMTS parameter shall be included if available and if the access network protocol is BSSAP.
Encryption Information
For definition of this parameter see clause 7.6.6. This UMTS parameter shall be included if available and if the access network protocol is BSSAP.
Radio Resource Information
For definition of this parameter see clause 7.6.6. This GSM parameter shall be included if the access network protocol is RANAP and there is an indication that the UE also supports GSM. If the parameter Radio Resource List is sent , the parameter Radio Resource Information shall not be sent.
AN-APDU
For definition of this parameter see clause 7.6.9.
Allowed GSM Algorithms
For definition of this parameter see clause 7.6.6. This parameters includes allowed GSM algorithms. This GSM parameter shall be included if: 
-	the service is a part of the Inter-MSC SRNS Relocation procedure and
-	Ciphering or Security Mode Setting procedure has been performed.and
-	there is an indication that the UE also supports GSM.
Allowed UMTS Algorithms
For definition of this parameter see clause 7.6.6. This UMTS parameter shall be included if all of the following conditions apply:
-	access network protocol is BSSAP and
-	Integrity Protection Information and Encryption Information are not available and
-	Ciphering or Security Mode Setting procedure has been performed.
Radio Resource List
For definition of this parameter see clause 7.6.6. This parameter shall be included if the access network protocol is RANAP and there is an indication that the UE also supports GSM. This parameter shall be sent when MSC-A requests multiple bearers to MSC-B. If the parameter Radio Resource Information is sent , the parameter Radio Resource List shall not be sent.
RAB ID
For definition of this parameter see clause 7.6.2. This parameter shall be included when MSC-A supports multiple bearers and access network protocol is BSSAP and the RAB ID has a value other than 1.
GERAN Classmark
For definition of this parameter see clause 7.6.6 This parameter shall be included if available.
BSSMAP Service Handover
For definition of this parameter see clause 7.6.6. It shall be present if it is available and the access network protocol is RANAP. If the parameter BSSMAP Service Handover List is sent, the parameter BSSMAP Service Handover shall not be sent.
BSSMAP Service Handover List
For definition of this parameter see clause 7.6.6. It shall be present if it is available and the access network protocol is RANAP. This parameter shall be sent when MSC-A requests multiple bearers to MSC-B. If the parameter BSSMAP Service Handover is sent, the parameter BSSMAP Service Handover List shall not be sent.
RANAP Service Handover
For definition of this parameter see clause 7.6.6. It shall be present if it is available and the access network protocol is BSSAP.
Iu-Currently Used Codec
For definition of this parameter see clause 7.6.6. This parameter shall be included if the handover is requested for a speech bearer and the MS is in UMTS or GERAN Iu-mode access. This parameter shall not be included if the Iu-Supported Codecs List is not included.
Iu-Supported Codecs List
For definition of this parameter see clause 7.6.6. This parameter shall be included by MSC-A, if the handover is requested for a speech bearer. 
RAB Configuration Indicator
For definition of this parameter see clause 7.6.6. This parameter may be included if the handover is requested for a speech bearer and MSC-A knows by means of configuration information that MSC-B supports the use of the Iu-Supported Codecs List parameter. This parameter shall not be included if the Iu-Supported Codecs List is not included.
ASCI Call Reference
This parameter contains either the broadcast call reference or group call reference.  It shall be included if a subscriber is undergoing handover during a VGCS or VBS call, where MSC-B already has a Bearer established, so that MSC-B can determine the Group or Broadcast Call to which it shall attach the subscriber, see 3GPP TS 48.008 [49]. 

UESBI-Iu
For definition of this parameter see clause 7.6.6. It shall be present if it is available and the access network protocol is BSSAP.
IMEISV
For definition of the parameter see clause 7.6.2. This parameter shall be present, if available. This is used e.g. for Management based Trace Activation (see 3GPP TS 32.422).
Alternative Channel Type
For definition of this parameter see clause 7.6.6 It shall be present for a SCUDIF call if the access network protocol is BSSAP.
Trace Propagation List
See definition in clause 7.6.10. This parameter shall be included when MSC-A requests trace invocation.
AoIP-Supported Codecs List Anchor
For definition of this parameter see clause 7.6.6. This parameter may be included by MSC-A, if the handover is requested for a speech bearer and mobile terminal supports GSM codec types. 
Regional Subscription Data
The list of subscribed Zone Codes as received from the HLR may be included by MSC-A at intra PLMN inter MSC handover and may be stored at MSC-B for use at subsequent intra MSC handover. 
CSG Subscription Data
The subscribed CSG Subscription Information as received from the HLR may be included by MSC-A at intra PLMN inter MSC handover and at inter PLMN inter MSC handover when the target PLMN is an ePLMN, and may be stored at MSC-B for use at subsequent intra MSC handover. 
LCLS Global Call Reference
For definition of this parameter see clause 7.6.5.21. This parameter shall be included when MSC-A supports LCLS.
LCLS-Negotiation
For definition of this parameter see clause 7.6.5.22. This parameter shall be included when MSC-A supports LCLS.
LCLS-Configurations-Preference
For definition of this parameter see clause 7.6.5.23. This parameter shall be included when MSC-A supports LCLS.
Multiple Bearer Requested
For a definition of this parameter see clause 7.6.2. This parameter shall be sent when MSC-A requests multiple bearers to MSC-B.
Handover Number
For definition of this parameter see clause 7.6.2. This parameter shall be returned at handover, unless the parameter HO-NumberNotRequired is sent. If the parameter Handover Number is returned, the parameter Relocation Number List shall not be returned.
Relocation Number List
For definition of this parameter see clause 7.6.2. This parameter shall be returned at relocation, unless the parameter HO-NumberNotRequired is sent. If the parameter Relocation Number List is returned, the parameter Handover Number shall not be returned.
Multicall Bearer Information
For a definition of this parameter see clause 7.6.2. This parameter shall be returned at relocation in the case that MSC-B supports multiple bearers.
Multiple Bearer Not Supported
For a definition of this parameter see clause 7.6.2. This parameter shall be returned at relocation when MSC-B receives Multiple Bearer Requested parameter and MSC-B does not support multiple bearers.
Selected UMTS Algorithms
For definition of this parameter see clause 7.6.6. This parameters includes the UMTS integrity and optionally encryption algorithms selected by RNC under the control of MSC-B. This UMTS parameter shall be included if the service is a part of the inter MSC inter system handover from GSM to UMTS.
Chosen Radio Resource Information
For definition of this parameter see clause 7.6.6. This parameter shall be returned at relocation if the encapsulated PDU is RANAP RAB Assignment Response and MS is in GSM access.
Iu-Selected Codec
For definition of this parameter see clause 7.6.6. This parameter shall be included if an Iu-Supported Codecs List was received in the service request and MSC-B supports the selection of codec based on the Iu-Supported Codecs List and the target radio access network is connected to MSC-B via the Iu interface, even if the Iu-Selected Codec is equal to the Iu-Currently Used Codec received in the service request. This parameter shall not be included if the Iu-Supported Codecs List was not received in the service request.
Iu-Available Codecs List
For definition of this parameter see clause 7.6.6. This parameter shall be included by an MSC-B supporting TrFO, if the Iu-Supported Codecs List was included by MSC-A and the target radio access is UMTS or GERAN Iu-mode. 
AoIP-Selected Codec Target
For definition of this parameter see clause 7.6.6. This parameter may be included by an MSC-B supporting TrFO, if the AoIP-Supported Codecs List Anchor was included by MSC-A and if AoIP is used on the target A interface with transcoder inserted in the MGW.
AoIP-Available Codecs List Map
For definition of this parameter see clause 7.6.6. This parameter may be included by an MSC-B supporting TrFO, if the AoIP-Supported Codecs List Anchor was included by MSC-A and if AoIP is used on the target A interface with transcoder inserted in the MGW. 
User error
For definition of this parameter see clause 7.6.1. The following errors defined in clause 7.6.1 may be used, depending on the nature of the fault:
-	No handover number available.
-	Target cell outside group call area;
-	System failure.
-	Unexpected data value.
-	Data Missing.
Provider error
See definition of provider errors in clause 7.6.1.
8.4.2	MAP_SEND_END_SIGNAL service
8.4.2.1	Definition
This service is used between MSC-B and MSC-A (E-interface) indicating that the radio path has been established by MSC-B to the MS. MSC-A retains then the main control of the call until it clears.
The response is used by MSC-A to inform MSC-B that all resources for the call can be released in MSC-B, either because the call has been released in MSC-A or because the call has been successfully handed over or relocated from MSC-B to another MSC.
The MAP_SEND_END_SIGNAL service is a confirmed service using the primitives from table 8.4/2.
8.4.2.2	Service primitives
Table 8.4/2: MAP_SEND_END_SIGNAL
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
AN-APDU
M
M(=)


Provider error



O

8.4.2.3	Parameter use
Invoke Id
For definition of this parameter see clause 7.6.1.
AN-APDU
For definition of this parameter see clause 7.6.9.
Provider error
For definition of this parameter see clause 7.6.1.
8.4.3	MAP_PROCESS_ACCESS_SIGNALLING service
8.4.3.1	Definition
This service is used between MSC-B and MSC-A (E-interface) to pass information received on the A‑interface or Iu-interface in MSC‑B to MSC‑A.
The MAP_PROCESS_ACCESS_SIGNALLING service is a non-confirmed service using the primitives from table 8.4/3.
8.4.3.2	Service primitives
Table 8.4/3: MAP_PROCESS_ACCESS_SIGNALLING
Parameter name
Request
Indication
Invoke Id
M
M(=)
AN-APDU
M
M(=)
Selected GSM Algorithm
C
C(=)
Selected UMTS Algorithms
C
C(=)
Chosen Radio Resource Information
C
C(=)
Selected RAB id
C
C(=)
Iu-Selected Codec
C
C(=)
Iu-Available Codecs List
C
C(=)
AoIP-Selected Codec Target
C
C(=)
AoIP-Available Codecs List Map
C
C(=)

8.4.3.3	Parameter use
Invoke Id
For definition of this parameter see clause 7.6.1.
AN-APDU
For definition of this parameter see clause 7.6.9.
Selected GSM algorithm
For definition of this parameter see clause 7.6.6. This parameter shall be present if the encapsulated PDU is Security Mode Complete and MS is in GSM access.
Selected UMTS Algorithms
For definition of this parameter see clause 7.6.6. This parameters includes the UMTS integrity and optionally encryption algorithms selected by RNC under the control of MSC-B. This UMTS parameter shall be included if the encapsulated PDU is BSSMAP Cipher Mode Complete and the MS is in UMTS, or an interystem handover to UMTS is performed in MSC-B, or in the case of intra MSC-B intra UMTS relocation. 
Chosen Radio Resource Information
For definition of this parameter see clause 7.6.6. This parameter shall be sent if the encapsulated PDU is RANAP RAB Assignment Response and MS is in GSM access.
Selected RAB ID
The selected radio access bearer that was kept at subsequent intra-MSC handover from UMTS to GSM after multiple bearers were used.
Iu-Selected Codec
For definition of this parameter see clause 7.6.6. This parameter shall be included 
-	if MSC-B changes the selected codec and the MS is in UMTS or GERAN Iu-mode access;
-	if intersystem handover to UMTS or GERAN Iu-mode is performed in MSC-B; or
-	if MSC-B received a Forward Access Signalling service request including an Iu-Supported Codecs List and the MS is in UMTS or GERAN Iu-mode access.
This parameter shall not be included if the Iu-Supported Codecs List was not received either in the Prepare Handover service request or in the Forward Access Signalling service request.
Iu-Available Codecs List
For definition of this parameter see clause 7.6.6. This parameter shall be included by an MSC-B supporting TrFO
-	if the Iu-Available Codecs List has changed in MSC-B;
-	if intersystem handover to UMTS or GERAN Iu-mode is performed in MSC-B; or
-	if MSC-B received a Forward Access Signalling service request including an Iu-Supported Codecs List and the MS is in UMTS or GERAN Iu-mode access. 
AoIP-Selected Codec Target
 For definition of this parameter see clause 7.6.6. This parameter may be included 
-	if A interface codec is changed in MSC-B; or
-	if intersystem handover to AoIP capable BSC is performed in MSC-B and if AoIP is used on the target A interface with transcoder inserted in the MGW; or
-	if MSC-B received a Forward Access Signalling service request including an AoIP-Supported Codecs List and the MS is in AoIP capable GSM access where AoIP is used on the target A interface with transcoder inserted in the MGW.
This parameter shall not be included if the AoIP-Supported Codecs List Anchor was not received either in the Prepare Handover service request or in the Forward Access Signalling service request.
AoIP-Available Codecs List Map
For definition of this parameter see clause 7.6.6. This parameter may be included by an MSC-B supporting TrFO 
-	if the AoIP-Available Codecs List has changed in MSC-B; or
-	if intersystem handover to AoIP capable BSC is performed in MSC-B where AoIP is used on the target A interface with transcoder inserted in the MGW; or
-	if MSC-B received a Forward Access Signalling service request including an AoIP-Supported Codecs List Anchor and the MS is in AoIP capable GSM access where AoIP is used on the target A interface with transcoder inserted in the MGW. 
8.4.4	MAP_FORWARD_ACCESS_SIGNALLING service
8.4.4.1	Definition
This service is used between MSC-A and MSC-B (E-interface) to pass information to be forwarded to the A-interface or Iu-interface of MSC-B.
The MAP_FORWARD_ACCESS_SIGNALLING service is a non-confirmed service using the primitives from table 8.4/4.
8.4.4.2	Service primitives
Table 8.4/4: MAP_FORWARD_ACCESS_SIGNALLING
Parameter name
Request
Indication
Invoke Id
M
M(=)
Integrity Protection Information
C
C(=)
Encryption Information
C
C(=)
Key Status
C
C(=)
AN-APDU
M
M(=)
Allowed GSM Algorithms
C
C(=)
Allowed UMTS Algorithms
C
C(=)
Radio Resource Information
C
C(=)
Radio Resource List
C
C(=)
BSSMAP Service Handover
C
C(=)
BSSMAP Service Handover List
C
C(=)
RANAP Service Handover
C
C(=)
Iu-Currently Used Codec
C
C(=)
Iu-Supported Codecs List
C
C(=)
RAB Configuration Indicator
C
C(=)
Iu-Selected Codec
C
C(=)
Alternative Channel Type
C
C(=)
Trace Propagation List
C
C(=)
AoIP-Supported Codecs List Anchor
C
C(=)
AoIP-Selected Codec Target
C
C(=)
UESBI-Iu
C
C(=)
IMEISV
C
C(=)

8.4.4.3	Parameter use
For the definition and use of all parameters and errors, see clause 7.6.1.
Invoke Id
For definition of this parameter see clause 7.6.1.
Integrity Protection Information
For definition of this parameter see clause 7.6.6. This UMTS parameter shall be included if available and if the encapsulated PDU is BSSMAP Cipher Mode Command.
Encryption Information
For definition of this parameter see clause 7.6.6. This UMTS parameter shall be included if available and if the encapsulated PDU is BSSMAP Cipher Mode Command.
Key Status
For definition of this parameter see clause 7.6.6. This UMTS parameter shall be included if available and if the encapsulated PDU is BSSMAP Cipher Mode Command.
AN-APDU
For definition of this parameter see clause 7.6.9.
Allowed GSM Algorithms
This parameters includes allowed GSM algorithms. This GSM parameter shall be included if the encapsulated PDU is RANAP Security Mode Command and there is an indication that the UE also supports GSM.
Allowed UMTS Algorithms
For definition of this parameter see clause 7.6.6. This UMTS parameter shall be included if Integrity Protection Information and Encryption Information are not available and the encapsulated PDU is BSSMAP Cipher Mode Command.
Radio Resource Information
For definition of this parameter see clause 7.6.6. This parameter shall be sent if the encapsulated PDU is RANAP RAB Assignment Request. If the parameter Radio Resource List is sent, the parameter Radio Resource Information shall not be sent.
Radio Resource List
For definition of this parameter see clause 7.6.6. This parameter shall be sent if the encapsulated PDU is RANAP RAB Assignment Request and MSC-A requests modification of multiple bearers. If the parameter Radio Resource Information is sent, the parameter Radio Resource List shall not be sent.
BSSMAP Service Handover
For definition of this parameter see clause 7.6.6. It shall be present if it is available and the encapsulated PDU is RANAP RAB Assignment Request. If the parameter BSSMAP Service Handover List is sent, the parameter BSSMAP Service Handover shall not be sent.
BSSMAP Service Handover List
For definition of this parameter see clause 7.6.6. It shall be present if it is available and the encapsulated PDU is RANAP RAB Assignment Request and MSC-A requests modification of multiple bearers. If the parameter BSSMAP Service Handover is sent, the parameter BSSMAP Service Handover List shall not be sent.
RANAP Service Handover
For definition of this parameter see clause 7.6.6.. It shall be present if it is available and the encapsulated PDU is BSSMAP Assignment Request.
Iu-Currently Used Codec
For definition of this parameter see clause 7.6.6. This parameter shall be included if the encapsulated PDU is a RANAP RAB Assignment Request or BSSMAP Assignment Request for a speech bearer and the MS is in UMTS or GERAN Iu-mode access. This parameter shall not be included if the Iu-Supported Codecs List is not included.
Iu-Supported Codecs List
For definition of this parameter see clause 7.6.6. This parameter shall be included if the encapsulated PDU is a RANAP RAB Assignment Request or BSSMAP Assignment Request and 
-	a new bearer is allocated for speech;
-	an existing bearer is modified from data to speech; or
-	for an existing speech bearer the order of priority in the Iu-Supported Codecs List needs to be modified. 
This parameter shall not be included if the Iu-Selected Codec is included.
RAB Configuration Indicator
For definition of this parameter see clause 7.6.6. This parameter may be included if the encapsulated PDU is a RANAP RAB Assignment Request for a speech bearer, and MSC-A knows by means of configuration information that MSC-B supports the use of the Iu-Supported Codecs List parameter. This parameter shall not be included if the Iu-Supported Codecs List is not included.
Iu-Selected Codec
For definition of this parameter see clause 7.6.6. This parameter shall be included if
-	the encapsulated PDU is a RANAP RAB Assignment Request or BSSMAP Assignment Request for an existing speech bearer; and
-	the MS is in UMTS or GERAN Iu-mode access; and 
-	an Iu-Available Codecs List was received by MSC-A for this speech bearer before, either in the Prepare Handover service response or in the Process Access Signalling service request.
This parameter shall not be included if the Iu-Supported Codecs List is included.
Alternative Channel Type
For definition of this parameter see clause 7.6.6. This parameter shall be present for a SCUDIF call if the encapsulated PDU is BSSMAP Assignment Request.
Trace Propagation List
See definition in clause 7.6.10. This parameter shall be included when MSC-A requests trace invocation.
AoIP-Supported Codecs List Anchor
For definition of this parameter see clause 7.6.6. This parameter may be included if the encapsulated PDU is a BSSMAP Assignment Request and 
-	a new bearer is allocated for speech;
-	an existing bearer is modified from data to speech; or
-	for an existing speech bearer the order of priority in the AoIP-Supported Codecs List needs to be modified. 
This parameter shall not be included if the AoIP-Selected Codec Target is included.
AoIP-Selected Codec Target
For definition of this parameter see clause 7.6.6. This parameter may be included if
-	the encapsulated PDU is a BSSMAP Assignment Request for an existing speech bearer; and
-	the MS is in AoIP capable GSM access where AoIP is used on the target A interface with transcoder inserted in the MGW; and 
-	an AoIP-Available Codecs List was received by MSC-A for this speech bearer before, either in the Prepare Handover service response or in the Process Access Signalling service request.
This parameter shall not be included if the AoIP-Supported Codecs List Anchor is included.
UESBI-Iu
For definition of this parameter see clause 7.6.6. It shall be present if it is available and the access network protocol is BSSAP and the parameter has not already been sent to the target MSC.
IMEISV
For definition of the parameter see clause 7.6.2. This parameter shall be present if available and if not already sent to the target MSC. This is used e.g. for Management based Trace Activation (see 3GPP TS 32.422).
8.4.5	MAP_PREPARE_SUBSEQUENT_HANDOVER service
8.4.5.1	Definition
This service is used between MSC-B and MSC-A (E-interface) to inform MSC-A that it has been decided that a handover or relocation to either MSC-A or a third MSC (MSC-B') is required.
The MAP_PREPARE_SUBSEQUENT_HANDOVER service is a confirmed service using the primitives from table 8.4/5.
8.4.5.2	Service primitives
Table 8.4/5: MAP_PREPARE_SUBSEQUENT_HANDOVER
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
Target Cell Id
C
C(=)


Target RNC Id
C
C(=)


Target MSC Number
M
M(=)


Selected RAB ID
C
C(=)


GERAN Classmark
C
C(=)


RAB Configuration Indicator
C
C(=)


AN-APDU
M
M(=)
C
C(=)
User error


C
C(=)
Provider error



O

8.4.5.3	Parameter use
Invoke Id
For definition of this parameter see clause 7.6.1.
Target Cell Id
For definition of this parameter see clause 7.6.2. This parameter shall be excluded if the service is a part of the Inter-MSC SRNS Relocation procedure or the inter-system handover GSM to UMTS procedure described in 3GPP TS 23.009.
Target RNC Id
For definition of this parameter see clause 7.6.2. This parameter shall be included if the service is a part of the Inter-MSC SRNS Relocation procedure or the inter-system handover GSM to UMTS procedure described in 3GPP TS 23.009.
Target MSC Number
For definition of this parameter see clause 7.6.2.
Selected RAB ID
For definition of this parameter see clause 7.6.2.
GERAN Classmark
For definition of this parameter see clause 7.6.6 This parameter shall be included if available.
RAB Configuration Indicator
For definition of this parameter see clause 7.6.6. This parameter may be included if the call is a speech call and MSC-B knows by means of configuration information that MSC-B' (and MSC-A) supports the use of the Iu-Supported Codecs List parameter.
AN-APDU
For definition of this parameter see clause 7.6.9.
User error
For definition of this parameter see clause 7.6.1. The following error causes defined in clause 7.6.1 may be used, depending on the nature of the fault:
-	Unknown MSC;
-	Subsequent handover failure;
-	Unexpected data value;
-	Data Missing.
Provider error
For definition of this parameter see clause 7.6.1.
8.4.6	MAP_ALLOCATE_HANDOVER_NUMBER service
8.4.6.1	Definition
This service is used between MSC and VLR (B-interface) to request a handover number.
The MAP_ALLOCATE_HANDOVER_NUMBER service is a confirmed service using the primitives from table 8.4/6.
8.4.6.2	Service primitives
Table 8.4/6: MAP_ALLOCATE_HANDOVER_NUMBER
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
User error


C
C(=)
Provider error



O

8.4.6.3	Parameter use
Invoke Id
For definition of this parameter see clause 7.6.1.
User error
For definition of this parameter see clause 7.6.1. The following errors defined in clause 7.6.1 may be used, depending on the nature of the fault:
-	No handover number available.
Provider error
For definition of this parameter see clause 7.6.1.
8.4.7	MAP_SEND_HANDOVER_REPORT service
8.4.7.1	Definition
This service is used between VLR and MSC-B (B-interface) to transfer the handover number to be forwarded to and used by MSC-A.
The MAP_SEND_HANDOVER_REPORT service is a confirmed service using the primitives from table 8.4/7.
8.4.7.2	Service primitives
Table 8.4/7: MAP_SEND_HANDOVER_REPORT
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
Handover Number
M
M(=)


Linked Id
M
M(=)


Provider error



O

8.4.7.3	Parameter use
Invoke Id
For definition of this parameter see clause 7.6.1.
Handover Number
For definition of this parameter see clause 7.6.2.
Linked Id
For definition of this parameter see clause 7.6.1. This service is linked with MAP_ALLOCATE_HANDOVER_NUMBER.
Provider error
For definition of this parameter see clause 7.6.1.
8.5	Authentication management services
8.5.1	MAP_AUTHENTICATE service
The MAP_AUTHENTICATE service is used on the MAP B interface. This interface is not fully operational specified. It is strongly recommended not to implement the B-interface as an external interface.
8.5.1.1	Definition
This service is used between the VLR and the MSC when the VLR receives a MAP service indication from the MSC concerning a location registration, call set-up, operation on a supplementary service or a request from the MSC to initiate authentication.
The service is a confirmed service and consists of four service primitives.
8.5.1.2	Service primitives
The service primitives are shown in table 8.5/1.
Table 8.5/1: MAP_AUTHENTICATE parameters
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
RAND
M
M(=)


CKSN
M
M(=)


SRES


M
M(=)
Provider error



O

8.5.1.3	Parameter use
Invoke id
See clause 7.6.1 for the use of this parameter.
RAND
See clause 7.6.7 for the use of this parameter.
CKSN
See clause 7.6.7 for the use of this parameter.
SRES
See clause 7.6.7 for the use of this parameter.
Provider error
See clause 7.6.1 for the use of this parameter.
8.5.2	MAP_SEND_AUTHENTICATION_INFO service
8.5.2.1	Definition
This service is used between the VLR and the HLR for the VLR to retrieve authentication information from the HLR. The VLR requests up to five authentication vectors.
Also this service is used between the SGSN and the HLR for the SGSN to retrieve authentication information and/or UE Usage Type from the HLR. The SGSN requests up to five authentication vectors. 
Also this service is used between the BSF and the HLR for the BSF to retrieve authentication information from the HLR. The BSF shall only request one authentication vector at a time.
In an EPS, this service is used between IWF and IWF and between IWF and HSS.
If the requesting node type is different from "MME" and the user is a UMTS subscriber, the HLR shall return authentication quintuplets. If the requesting node type is different from MME and the user is a GSM subscriber, the HLR shall return authentication triplets. 
If the requesting node type is "MME", the HSS shall return EPS authentication vectors.
If the requesting node type is a combined MME/SGSN, the HSS shall return requested authentication vectors for the actual RAT and may return additional authentication vectors for the other RAT.
If the HLR cannot provide the VLR, the SGSN or the BSF with triplets, an empty response is returned. The VLR, the SGSN, or the BSF may then re-use old authentication triplets, except where this is forbidden under the conditions specified in 3GPP TS 43.020 [24].
If the HLR cannot provide the VLR, the SGSN or the BSF with quintuplets, an empty response is returned. The VLR, the SGSN or the BSF shall not re-use old authentication quintuplets. 
If the HSS cannot provide the IWF with EPS authentication vectors, an empty response is returned.
If the VLR or SGSN or IWF or BSF receives a MAP_SEND_AUTHENTICATION_INFO response containing a User Error parameter as part of the handling of an authentication procedure, the authentication procedure in the VLR or SGSN or MME or BSF shall fail.
Security related network functions are further described in 3GPP TS 43.020 [24] and 3GPP TS 33.200.
The service is a confirmed service and consists of four service primitives.
8.5.2.2	Service primitives
The service primitives are shown in table 8.5/2.
Table 8.5/2: MAP_SEND_AUTHENTICATION_INFO parameters
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
IMSI
C
C(=)


Number of requested vectors
C
C(=)


Requesting node type
C
C(=)


Re-synchronisation Info
C
C(=)


Segmentation prohibited indicator
C
C (=)


Immediate response preferred indicator
U
C (=)


Requesting PLMN ID
C
C(=)


Number of additional requested vectors
C
C(=)


Additional requested Vectors are for EPS
C
C(=)


UE Usage Type Request Indication
C
C(=)


AuthenticationSetList


C
C(=)
UE Usage Type


C
C(=)
User error


C
C(=)
Provider error



O

8.5.2.3	Parameter use
Invoke id
See clause 7.6.1 for the use of this parameter.
IMSI
See clause 7.6.2 for the use of this parameter.
This parameter shall be present in the first (or only) request of the dialogue. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one.
Number of requested vectors
A number indicating how many authentication vectors the VLR, the SGSN, the MME or the BSF is prepared to receive. The HLR shall not return more vectors than indicated by this parameter.
This parameter shall be present in the first (or only) request of the dialogue. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one.
Requesting node type
The type of the requesting node (SGSN, MME, combined MME/SGSN, VLR, or BSF).
This parameter shall be present in the first (or only) request of the dialogue. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one.
Re-synchronisation Info
For definition and use of this parameter see 3GPP TS 33.200.
If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one..
Segmentation prohibited indicator
This parameter indicates if the VLR, the SGSN or the IWF allows segmentation of the response at  MAP user level.
This parameter may be present only in the first request of the dialogue.
Immediate response preferred indicator
This parameter indicates that one of the requested authentication vectors is requested for immediate use in the VLR, the SGSN, the MME or the BSF. It may be used by the HLR together with the number of requested vectors and the number of vectors stored in the HLR to determine the number of vectors to be obtained from the AuC. It shall be ignored if the number of available vectors is greater than the number of requested vectors.
If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one.
Requesting PLMN ID
The PLMN-ID of the requesting node. See3GPP TS 23.003.
This parameter shall be present in the first (or only) request of the dialogue. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one.
Number of additional requested vectors
A number indicating how many additional authentication vectors the combined MME/SGSN or IWF is prepared to receive. The HLR shall not return more vectors than indicated by this parameter. This parameter shall be present only if the requesting node type is a combined MME/SGSN. A combined MME/SGSN that wants to request only EPS-Vectors (only non-EPS-Vectors) shall set the requesting node type to "MME" ("SGSN").
This parameter shall be present in the first (or only) request of the dialogue. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one.
Additional vectors are for EPS
This parameter shall be absent if Number of additional vectors is absent. The parameter indicates by its presence that additional vectors (i.e. not for immediate use) are for EPS.
This parameter shall be present in the first (or only) request of the dialogue. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one.
UE Usage Type Request Indication
This parameter indicates by its presence that the HLR (if it supports the Dedicated Core Network functionality) shall include the UE Usage Type in the response to the SGSN. This parameter is not applicable for VLRs.
AuthenticationSetList
A set of one to five authentication vectors are transferred from the HLR to the VLR, from the HLR to the SGSN or IWF or from the HLR to the BSF, if the outcome of the service was successful.
UE Usage Type
This parameter shall be present if UE Usage Type Request Indication was present in the request and the HLR supports the Dedicated Core Networks functionality (see 3GPP TS 23.060 [104]) and a UE Usage Type is available in the subscription data of the user. In this case, if the Immediate Response Preferred parameter is not set, the HLR may return no authentication vectors in the response.
User error
One of the following error causes defined in clause 7.6.1 shall be sent by the user in case of unsuccessful outcome of the service, depending on the respective failure reason:
-	unknown subscriber;
-	unexpected data value;
-	system failure;
-	data missing.
Provider error
See clause 7.6.1 for the use of this parameter.
8.5.3	MAP_AUTHENTICATION_FAILURE_REPORT service
8.5.3.1	Definition
This service is used between the VLR and the HLR or between the SGSN or HLR for reporting of authentication failures.
8.5.3.2	Service primitives
The service primitives are shown in table 8.5/3.
Table 8.5/3: MAP_AUTHENTICATION_FAILURE_REPORT parameters
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
IMSI
M
M(=)


Failure cause
M
M(=)


Re-attempt
M
M(=)


Access Type
M
M(=)


Rand
M
M(=)


VLR number
C
C(=)


SGSN number
C
C(=)


User error


C
C(=)
Provider error



O

8.5.3.3	Parameter use
Invoke id
See clause 7.6.1 for the use of this parameter.
IMSI
See clause 7.6.2 for the use of this parameter.
Failure Cause
See clause 7.6.7 for use of this parameter.

Re-attempt
See clause 7.6.7 for use of this parameter.
Access Type
See clause 7.6.7 for use of this parameter.
Rand
This parameter identifies the specific AV that failed authentication.
See clause 7.6.7 for use of this parameter.
VLR number
Shall be present if the sender is VLR. See definition in clause 7.6.2.
SGSN number
Shall be present if the sender is SGSN. See definition in clause 7.6.2.
User error
This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clause 7.6.1:
-	Unknown Subscriber;
-	System Failure;
-	Unexpected Data Value.
Provider error
These are defined in clause 7.6.
8.6	Security management services
8.6.1	MAP_SET_CIPHERING_MODE service
8.6.1.1	Definitions
This service is used between the VLR and the MSC to set the ciphering mode and to start ciphering if applicable. It is called when another service requires that information is to be sent on the radio path in encrypted form.
The service is a non-confirmed service and consists of two service primitives.
8.6.1.2	Service primitives
The service primitives are shown in table 8.6/1.
Table 8.6/1: MAP_SET_CIPHERING_MODE parameters
Parameter name
Request
Indication
Invoke id
M
M(=)
Ciphering mode
M
M(=)
Kc
C
C(=)

8.6.1.3	Parameter use
Invoke id
See clause 7.6.1 for the use of this parameter.
Ciphering mode
See clause 7.6.7 for the use of this parameter.
Kc
The Kc parameter should be included when the ciphering mode parameter indicates that ciphering must be performed.
8.7	International mobile equipment identities management services
8.7.1	MAP_CHECK_IMEI service
8.7.1.1	Definition
This service is used between the VLR and the MSC, between the MSC and the EIR, between the SGSN and EIR, and between IWF and EIR to request check of IMEI. If the IMEI is not available in the MSC or in the SGSN, it is requested from the MS and transferred to the EIR in the service request.
This service may also be used to request the BMUEF from the EIR.
The service is a confirmed service and consists of four service primitives.
8.7.1.2	Service primitives
The service primitives are shown in table 8.7/1.
Table 8.7/1: MAP_CHECK_IMEI parameters
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
IMEI
C
C(=)
C
C(=)
IMEISV
C
C(=)
C(=)
C(=)
Requested Equipment Info
M
M(=)


Equipment status


C
C(=)
BMUEF


C
C(=)
User error


C
C(=)
Provider error



O

8.7.1.3	Parameter use
Invoke id
See clause 7.6.1 for the use of this parameter.
Requested Equipment Info
This parameter indicates whether Equipment Status or BMUEF or both is requested.
IMEI
See clause 7.6.2 for the use of this parameter. The parameter shall not be included in the service request between the VLR and the MSC, but one of IMEI and IMEISV is mandatory in the service request from the MSC to the EIR, from the SGSN to the EIR and from the IWF to the EIR. It is not included in the service response from the EIR to the MSC,  the SGSN or the IWF, but one of IMEI and IMEISV is mandatory in the service response from the MSC to the VLR on successful outcome.
IMEISV
See clause 7.6.2 for the use of this parameter. IMEISV shall be present if BMUEF is requested.
Equipment status
See clause 7.6.3 for the use of this parameter. This parameter is sent by the responder in case of successful outcome of the service if Equipment status was requested.
BMUEF
See clause 7.6.4 for the use of this parameter. This parameter is sent by the responder in case of successful outcome of the service if BMUEF was requested.
User error
One of the following error causes defined in clause 7.6.1 shall be sent by the user in case of unsuccessful outcome of the service, depending on the respective failure reason:
-	unknown equipment;
	this error is returned by the responder when the IMEI is not known in the EIR;
-	system failure;
-	data missing.
Provider error
See clause 7.6.1 for the use of this parameter.
8.7.2	MAP_OBTAIN_IMEI service
8.7.2.1	Definition
This service is used between the VLR and the MSC to request the IMEI. If the IMEI is not available in the MSC, it is requested from the MS.
The service is a confirmed service and consists of four service primitives.
8.7.2.2	Service primitives
The service primitives are shown in table 8.7/2.
Table 8.7/2: MAP_OBTAIN_IMEI parameters
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
IMEI


C
C(=)
User error


C
C(=)
Provider error



O

8.7.2.3	Parameter use
Invoke id
See clause 7.6.1 for the use of this parameter.
IMEI
See clause 7.6.2 for the use of this parameter. The parameter is included in the service response from the MSC to the VLR on successful outcome of the service.
User error
If the service fails, the VLR sends the user error System Failure (see clause 7.6.1) to the MSC.
Provider error
See clause 7.6.1 for the use of this parameter.
8.8	Subscriber management services
8.8.1	MAP-INSERT-SUBSCRIBER-DATA service
8.8.1.1	Definition
This service is used by an HLR to update a VLR with certain subscriber data in the following occasions:
-	the operator has changed the subscription of one or more supplementary services, basic services or data of a subscriber. Note that in case of withdrawal of a Basic or Supplementary service this primitive shall not be used;
-	the operator has applied, changed or removed Operator Determined Barring;
-	the subscriber has changed data concerning one or more supplementary services by using a subscriber procedure;
-	the HLR provides the VLR with subscriber parameters at location updating of a subscriber or at restoration. In this case, this service is used to indicate explicitly that a supplementary service is not provisioned, if the supplementary service specification requires it. The only supplementary services which have this requirement are the CLIR and COLR services. Network access mode is provided only in restoration. If the Super-Charger functionality is supported the HLR may not need to provide the VLR with subscriber parameters at location updating of a subscriber. See TS 23.116.
Also this service is used by an HLR to update an SGSN with certain subscriber data in the following occasions:
-	if the GPRS subscription has changed;
-	if the network access mode is changed;
-	the operator has applied, changed or removed Operator Determined Barring;
-	the subscriber has changed data concerning one or more supplementary services by using a subscriber procedure;
-	the HLR provides the SGSN with subscriber parameters at GPRS location updating of a subscriber. If the Super‑Charger functionality is supported the HLR may not need to provide the SGSN with subscriber parameters. See 3GPP TS 23.116. 
Also this service is used by a CSS to update an SGSN or a VLR with VPLMN-CSG-Subscription data in the following occasions:
-	if the VPLMN-CSG subscription data has changed;
-	the CSS provides the VLR or SGSN with VPLMN-CSG subscription data at VCSG location updating of a subscriber.

In an EPS, this service is used by an HSS to update an MME via IWF with certain subscriber data in the following occasions:
-	the EPS subscription has changed;
-	the operator has applied, changed or removed Operator Determined Barring;
-	the HSS provides the MME via IWF(MME) with subscriber parameters at EPS location updating of a subscriber unless an explicit indication to skip subscriber data update has been received.
In an EPS, this service is used by an IWF to indicate to the MME via IWF that the HSS has requested to be notified when the UE has become reachable.
It is a confirmed service and consists of the primitives shown in table 8.8/1.
8.8.1.2	Service primitives
Table 8.8/1: MAP-INSERT-SUBSCRIBER-DATA
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
IMSI
C
C(=)


MSISDN
C
C(=)


Additional MSISDN
C
C(=)


Category
C
C(=)


Subscriber Status
C
C(=)


Bearer service List
C
C(=)
C
C(=)
Teleservice List
C
C(=)
C
C(=)
Forwarding information List
C
C(=)


Call barring information List
C
C(=)


CUG information List
C
C(=)


SS-Data List
C
C(=)


eMLPP Subscription Data
C
C(=)


MC-Subscription Data
C
C(=)


Operator Determined Barring General data
C
C(=)
C
C(=)
Operator Determined Barring HPLMN data
C
C(=)


Roaming Restriction Due To Unsupported Feature
C
C(=)


Regional Subscription Data
C
C(=)


VLR CAMEL Subscription Info
C
C(=)


Voice Broadcast Data
C
C(=)


Voice Group Call Data
C
C(=)


Network access mode
C
C(=)


GPRS Subscription Data
C
C(=)


EPS Subscription Data
C
C(=)


VPLMN LIPA Allowed
C
C(=)


Roaming Restricted In SGSN/MME Due To Unsupported Feature
C
C(=)


North American Equal Access preferred Carrier Id List
U
C(=)


SGSN CAMEL Subscription Info
C
C(=)


LSA Information
C
C(=)


IST Alert Timer
C
C(=)


SS-Code List


C
C(=)
LMU Identifier
C
C(=)


LCS Information
C
C(=)


CS Allocation/Retention priority
C
C(=)


Super-Charger Supported In HLR
C
C(=)


Subscribed Charging Characteristics
C
C(=)


Access Restriction Data
C
C(=)


ICS Indicator
U
C(=)


CSG Subscription Data
C
C(=)


VPLMN CSG Subscription Data
C
C(=)


UE Reachability Request Indicator
C
C(=)


SGSN Number
C
C(=)


MME-Name
C
C(=)


Subscribed Periodic RAU-TAU Timer
C
C(=)


Subscribed Periodic LAU Timer
C
C(=)


MDT User Consent
C
C(=)


PS and SMS-Only Service Provision
C
C(=)


SMS in SGSN Allowed
C
C(=)


CS-to-PS-SRVCC-Allowed-Indicator
C
C(=)


P-CSCF Restoration Request
C
C(=)


Adjacent Access Restriction Data
C
C(=)


IMSI-Group-Id List
C
C(=)


UE Usage Type
C
C(=)


User Plane Integrity Protection Indicator
C
C(=)


DL-Buffering Suggested Packet Count
C
C(=)


Reset-IDs
C
C(=)


eDRX-Cycle-Length List
C
C(=)


IAB-Operation-Allowed-Indicator
C
C(==)


Regional Subscription Response


C
C(=)
Supported CAMEL Phases


C
C (=)
Offered CAMEL 4 CSIs


C
C (=)
Supported Features


U
C (=)
User error


U
C(=)
Provider error



O

8.8.1.3	Parameter use
All parameters are described in clause 7.6. The following clarifications are applicable:
Network access mode
This parameter defines if the subscriber has access to MSC/VLR and/or to SGSN/MME. This parameter is used by SGSN/MME and MSC/VLR. In VLR, the parameter is used only as part of Restore Data Procedure and the parameter is not stored in the VLR. This parameter shall always be sent to the SGSN and viaIWF to the MME as part of the GPRS subscriber data at GPRS/MME location updating. It shall be sent to the SGSN and via IWF to the MME if it is changed as a result of administrative action. 
This parameter shall not be used by the CSS.

IMSI
It is only included if the service is not used in an ongoing transaction (e.g. location updating). This parameter is used by the VLR and the SGSN and IWF.
MSISDN
For subscriptions with MSISDN:
It is included at location updating and when it is changed. The MSISDN sent shall be the basic MSISDN. This parameter is used by the VLR and the SGSN and IWF.
For a subscription without MSISDN:
The HLR shall not populate this parameter  if the VLR or SGSN explicitly indicated support of MSISDN-less operation. 
NOTE 1:	See clauses 8.1.2.3 and 8.1.7.3 for the case where the VLR or SGSN does not support MSISDN-less operation.
Additional MSISDN
If subscribed, the Additional MSISDN is included at location updating and when it is changed. This parameter is used by the SGSN and IWF. This parameter shall be ignored by the VLR if received.
If the SGSN does not indicate support of the feature the HSS shall not send the parameter.
Category
It is included either at location updating or when it is changed. This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it.
Subscriber Status
It is included either at location updating or when it is changed.
To apply, remove or update Operator Determined Barring Categories the Subscriber Status is set to Operator Determined Barring. In this case ODB General Data shall also be present. If the Operator Determined Barring applies and the subscriber is registered in the HPLMN and HPLMN specific Operator Determined Barring applies then ODB HPLMN Specific Data shall also be present.
To remove all Operator Determined Barring Categories the Subscriber Status shall be set to "Service Granted". This parameter is used by the VLR and the SGSN and IWF. 
This parameter shall not be used by the CSS.

Bearer service List
A list of Extensible Bearer service parameters (Extensible Bearer service is defined in clause 7.6). An Extensible Bearer service parameter must be the code for an individual Bearer service, except in the cases described below.
The codes for the Bearer service groups "allAlternateSpeech-DataCDA" and "allAlternateSpeech-DataCDS" shall, if applicable, be sent from the HLR to the VLR as a pair. The codes for the Bearer service groups "allSpeechFollowedByDataCDA" and "allSpeechFollowedByDataCDS" shall, if applicable, be sent from the HLR to the VLR as a pair.
If it is included in the Request/Indication, it includes either all Extensible Bearer services subscribed (at location updating or at restoration) or only the ones added (at subscriber data modification).
If the VLR receives an Indication containing any Extensible Bearer service parameters which it does not support/allocate it returns them in the response to the HLR and discards the unsupported Extensible Bearer services (no error is sent back), except in the cases described below.
If the VLR receives the codes for the Bearer service groups "allSpeechFollowedByDataCDA" and "allSpeechFollowedByDataCDS" and supports one or more of the circuit-switched synchronous or asynchronous data rates specified for simple data bearer services, it shall accept the bearer service codes, and not return them in the response to the HLR. If the VLR does not support any of the circuit-switched synchronous or asynchronous data rates specified for simple data bearer services, and receives the pair of codes for "allAlternateSpeech-DataCDA" and "allAlternateSpeech-DataCDS" or the pair of codes for "allSpeechFollowedByDataCDA" and "allSpeechFollowedByDataCDS", it shall reject the pair of codes by returning them in the response to the HLR. This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. 
This parameter shall not be used by the CSS.

Teleservice List
A list of Extensible Teleservice parameters (Extensible Teleservice is defined in clause 7.6). An Extensible Teleservice parameter must be the code for an individual Teleservice.
If it is included in the Request/Indication, it contains either all Extensible Teleservices subscribed (at location updating or at restoration) or the ones added (at subscriber data modification). Only the Extensible Teleservices that are relevant to the node at which the message is received should be included in the Teleservice List.
If the VLR or the SGSN or the IWF receives an Indication containing any Extensible Teleservice parameters which it does not support/allocate it returns them in the response to the HLR and discards the unsupported Extensible Teleservices (no error is sent back). This parameter is used by the VLR and the SGSN and the IWF.
This parameter shall not be used by the CSS.

Forwarding information List
A list of Extensible Forwarding information parameters (Extensible Forwarding information is defined in clause 7.6). It includes Call Forwarding services either at location updating or at restoration or when they are changed. Each Extensible Forwarding information parameter shall be treated independently of all other parameters in the primitive.
The Extensible Forwarding information shall include the SS-Code for an individual call forwarding supplementary service. The Extensible Forwarding information shall contain one or more Extensible Forwarding Features (Extensible Forwarding Feature is defined in clause 7.6).
The Extensible Forwarding Feature may include an Extensible Basic Service Group. This shall be interpreted according to the rules in clause 8.8.1.4.
The Extensible Forwarding Feature shall contain an Extensible SS-Status parameter.
If the Extensible SS-Status indicates that call forwarding is registered then (except for call forwarding unconditional) the Extensible Forwarding Feature shall contain a number to define the forwarded-to destination and, if available, the forwarded-to subaddress. In other states the forwarded-to number and, if applicable, the forwarded-to subaddress shall not be included. For call forwarding unconditional the forwarded-to number and, if applicable, the forwarded-to subaddress shall not be included. If the VLR does not receive a forwarded-to subaddress then it shall assume that a forwarded-to subaddress has not been registered.
The Extensible Forwarding Feature shall contain the extensible forwarding options (except for call forwarding unconditional where the extensible forwarding options shall not be included). Bits 3 and 4 of the extensible forwarding options shall be ignored by the VLR, and may be set to any value by the HLR.
For call forwarding on no reply: If the extensible SS-Status indicates that call forwarding is registered then the Extensible Forwarding Feature shall contain an extensible no reply condition timer. In other states the no reply condition timer shall not be included.
For call forwarding services other than call forwarding on no reply: The Extensible Forwarding Feature shall not contain a no reply condition timer.
If the VLR receives an Indication containing any Call Forwarding service codes which it does not support/allocate it returns them to the HLR in the parameter SS-Code List and discards the unsupported Call Forwarding service codes (no error is sent back). This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. 
This parameter shall not be used by the CSS.

Call barring information List
A list of Extensible Call barring information parameters (Extensible Call barring information is defined in clause 7.6). It includes Call Barring services either at location updating or at restoration or when they are changed. Each Extensible Call barring information parameter shall be treated independently of all other parameters in the primitive.
The Extensible Call barring information shall include the SS-Code for an individual call barring supplementary service. The Extensible Call barring information shall contain one or more Extensible Call Barring Features (Extensible Call Barring Feature is defined in clause 7.6).
The Extensible Call Barring Feature may include an Extensible Basic Service Group. This shall be interpreted according to the rules in clause 8.8.1.4.
The Extensible Call Barring Feature shall contain an extensible SS-Status parameter.
If the VLR or the SGSN or the IWF receives an Indication containing any Extensible Call Barring service codes which it does not support/allocate it returns them to the HLR in the parameter SS-Code List and discards the unsupported Extensible Call Barring service codes (no error is sent back). 
This parameter shall not be used by the CSS.
CUG information List
A list of CUG information list parameters (CUG information is defined in clause 7.6). It includes CUG information either at location updating or at restoration or when it is changed.
At location updating, restoration or when there is a change in CUG data, the HLR shall include the complete CUG‑SubscriptionList and, if there are options per basic group, it shall also include the complete CUG-FeatureList. If there are not options per extensible basic service group the CUG-FeatureList shall not be included.
In any dialogue, the first insertSubscriberData message which contains CUG information shall include a non-empty CUG-SubscriptionList.
When the VLR receives CUG data it shall replace the stored CUG data with the received data set.
If CUG-FeatureList is omitted in the Insert Subscriber Data operation VLR shall interpret that no options per extensible basic service group exist, and then it shall apply the default values i.e. no outgoing access, no incoming access, no preferential CUG exists.
If CUG-Feature is received without preferential CUG, the VLR shall interpret that no preferential CUG applies.
If the VLR detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value.
Note that data consistency between CUG subscription data and CUG feature data is the responsibility of the HLR.
If the VLR does not support the CUG service it returns its code to the HLR in the parameter SS-Code List and discards the received information (no error is sent back). This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. 
This parameter shall not be used by the CSS.
SS-Data List
A list of Extensible SS-Data parameters (Extensible SS-Data is defined in clause 7.6). It is sent for any other supplementary service than Call Forwarding, Call Barring, CUG and eMLPP either at location updating or at restoration or when they are changed. Each SS-Data parameter shall be treated independently of all other parameters in the primitive.
The Extensible SS-Data shall include the SS-Code for an individual supplementary service.
The Extensible SS-Data shall contain an Extensible SS-Status parameter and any subscription options that are applicable to the service defined by the SS-Code.
The SS-Data may include a Basic Service Group List. This shall be interpreted according to the rules in clause 8.8.1.4.
If the VLR receives an Indication containing any supplementary service codes which it does not support/allocate it returns them to the HLR in the parameter SS-Code List and therefore discards the unsupported service codes received (no error is sent back).
This parameter is used by the SGSN only for LCS. If the SGSN receives an Indication containing any LCS related supplementary service codes which it does not support/allocate it returns them to the HLR in the parameter SS-Code List and therefore discards the unsupported service codes received (no error is sent back). SS-codes not related to the supported LCS capability set shall be discarded. 
If the IWF receives an Indication containing any LCS related supplementary service codes, it returns them to the HSS in the parameter SS-Code List and therefore discards the service codes received (no error is sent back). SS-codes not related to the supported LCS capability set shall be discarded. 
This parameter shall not be used by the CSS.
Operator Determined Barring General data
If it is included in a Request/Indication, it includes all the Operator Determined Barring categories that may be applied to a subscriber registered in any PLMN. This parameter is only included in a Request/Indication when the parameter Subscriber Status is set to the value Operator Determined Barring. Note that all General Operator Determined Barring Categories shall be set to their actual status.
If the VLR or the SGSN or IWF receives an Indication containing Operator Determined Barring General Data which shows that the subscriber is subject to barring not supported / not allocated by the VLR or by the SGSN, it returns Operator Determined Barring General Data in the response to the HLR to show the barring categories which are not supported / not allocated by the VLR or by the SGSN. This parameter is used by the VLR and the SGSN and IWF. 
This parameter shall not be used by the CSS.
Operator Determined Barring HPLMN data
It includes all the Operator Determined Barring categories that may be applied only to a subscriber registered in the HPLMN. Therefore, it shall only be transferred to the VLR or to the SGSN or IWF when the subscriber is roaming into the HPLMN and when the parameter Subscriber Status is set to the value Operator Determined Barring. Note that all HPLMN Operator Determined Barring Categories shall be set to their actual status.
If Subscriber Status is set to the value Operator Determined Barring and no Operator Determined Barring HPLMN data is present then the VLR or the SGSN or IWF shall not apply any HPLMN specific ODB services to the subscriber. This parameter is used by the VLR and the SGSN and IWF. 
This parameter shall not be used by the CSS.
eMLPP Subscription Data
If included in the Insert Subscriber Data request this parameter defines the priorities the subscriber might apply for a call (as defined in clause 7.6). It contains both subparameters of eMLPP.
If the VLR does not support the eMLPP service it returns its code to the HLR in the parameter SS-Code List and therefore discards the received information (no error is sent back).
eMLPP subscription data that have been stored previously in a subscriber data record in the VLR are completely replaced by the new eMLPP subscription data received in a MAP_INSERT_SUBSCRIBER_DATA during either an Update Location or Restore Data procedure or a stand alone Insert Subscriber data procedure. This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. 
This parameter shall not be used by the CSS.
MC Subscription Data
If included in the Insert Subscriber Data request, this parameter provides the MC Subscription Data as defined in clause 7.6.
If the VLR does not support the MC service, it returns its code to the HLR in the parameter SS-Code List and therefore discards the received information (no error is sent back).
MC subscription data that have been stored previously in a subscriber data record in the VLR are completely replaced by the new MC subscription data received in a MAP_INSERT_SUBSCRIBER_DATA during either an Update Location or Restore Data procedure or a stand alone Insert Subscriber data procedure. This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. 
This parameter shall not be used by the CSS.
Roaming Restriction Due To Unsupported Feature
The HLR may decide to include this parameter in the request if certain services or features are indicated as not supported by the MSC/VLR (e.g. Advice of Charge Charging Level).
If this parameter is sent to the VLR the MSC area is restricted by the HLR and the VLR. This parameter is used only by the VLR and if the SGSN or the IWF receives this parameter it shall ignore it. 
This parameter shall not be used by the CSS.
Regional Subscription Data
If included in the Insert Subscriber Data request this parameter defines the subscriber's subscription area for the addressed VLR, for the addressed SGSN or for the addressed MME (as defined in clause 7.6). It contains the complete list of up to 10 Zone Codes that apply to a subscriber in the currently visited PLMN. The HLR shall send only those Zone Codes which are stored against the CC and NDC of the VLR, the SGSN or the MME to be updated.
NOTE 2:	Support of this parameter is a network operator option and it will not be sent to networks which do not support Regional Subscription.
Regional subscription data that have been stored previously in a subscriber data record in the VLR, in the SGSN or in the MME are completely replaced by the regional subscription data received in an Insert Subscriber Data indication during either an Update Location or Restore Data procedure or a stand alone Insert Subscriber data procedure.
After the regional subscription data are inserted the VLR or the SGSN shall derive whether its location areas are allowed or not. If the whole MSC or SGSN area is restricted it will be reported to HLR by returning the Regional Subscription Response.
The VLR or the SGSN returns a Regional Subscription Response indicating that a problem with the Zone Code has been detected in one of the following cases:
-	Too Many Zone Codes: more than 10 Zone Codes are to be stored in the VLR or in the SGSN.
-	Regional Subscription Not Supported by the VLR or the SGSN.
-	Zone Codes Conflict: the VLR or the SGSN detects that the zone codes indicate conflicting service permission for a location area.
Zone codes which have no mapping to location areas shall be ignored.
If a sequence of MAP_INSERT_SUBSCRIBER_DATA services is used during a dialogue, Regional Subscription Data shall be accepted only in one service. Regional Subscription Data received in a subsequent service shall be rejected with the error Unexpected Data Value.
If Regional Subscription Data are not included in any MAP_INSERT_SUBSCRIBER_DATA service, there is no restriction of roaming due to Regional Subscription. This parameter is used by the VLR, the SGSN and the IWF. 
This parameter shall not be used by the CSS.
Voice Broadcast Data
This parameter contains a list of group id's a user might have subscribed to; (VBS-Data is defined in clause 7.6). It includes VBS information either at location updating or at restoration or when it is changed.
At location updating, restoration or when there is a change in VBS data, the HLR shall include the complete VBS-Data.
When the VLR receives VBS-Data within a dialogue it shall replace the stored VBS-data with the received data set. All subsequent VBS-data received within this dialogue shall be interpreted as add-on data.
If VBS-data is omitted in the Insert Subscriber Data operation the VLR shall keep the previously stored VBS data.
If the VLR detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value. This parameter is used only by the VLR and if the SGSN or the IWF receives this parameter it shall ignore it. 
This parameter shall not be used by the CSS.
Voice Group Call Data
This parameter contains a list of group id's a user might have subscribed to; see clause 7.6.
At location updating, restoration or when there is a change in VGCS data, the HLR shall include the complete VGCS‑Data.
When the VLR receives VGCS-Data within a dialogue it shall replace the stored VGCS-Data with the received data set. All VGCS-Data received within this dialogue shall be interpreted as add-on data.
If VBCS-Data is omitted in the Insert Subscriber Data operation the VLR shall keep the previously stored VGCS-Data.
If the VLR detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value. This parameter is used only by the VLR and if the SGSN or the IWF receives this parameter it shall ignore it. 
This parameter shall not be used by the CSS.
North American Equal Access preferred Carrier Id List
A list of the preferred carrier identity codes that are subscribed to.
When the VLR receives this parameter from the HLR, it shall replace the previously stored preferred carrier identity codes with the received ones. It is not possible to delete all the preferred carrier identity codes from the VLR using this service. To delete all the preferred carrier identity codes from the VLR, the HLR shall use the MAP_CANCEL_LOCATION service. 
This parameter shall not be used by the CSS.
LSA Information
If included in the ISD request, this parameter contains a list of localised service area identities a user might have subscribed to together with the priority, the preferential access indicator, the active mode support indicator and active mode indication of each localised service area; see clause 7.6. The access right outside these localised service areas is also indicated. In all cases mentioned below, the LSA information shall only include LSA Data applicable to the VPLMN where the Subscriber is located. The VLR number, received in the MAP-UPDATE_LOCATION primitive, or the SGSN number, received in the MAP_UPDATE_GPRS_LOCATION primitive, can be used, alongside data stored in the HLR, to determine the LSA Data applicable to the VPLMN.
At restoration, location updating or GPRS location updating the HLR shall include the complete set of applicable LSA Information.
When there is a change in LSA data the HLR shall include at least the new and/or modified LSA data.
When there is a change in the access right outside the localised service areas the HLR shall include the LSA only access indicator.
When the SGSN or the VLR receives LSA information within a dialogue it shall check if the received data has to be considered as the entire LSA information. If so, it shall replace the stored LSA information with the received data set, otherwise it shall replace the data only for the modified LSA data (if any) and/or access right, and add the new LSA data (if any) to the stored LSA Information.
If the entire LSA information is received, it shall always include the LSA only access indicator value together with the LSA data applicable for the PLMN (if any).
If LSA Information is omitted in the Insert Subscriber Data operation the SGSN or the VLR shall keep the previously stored LSA Information.
If the SGSN or the VLR detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value. This parameter is used by the VLR and the SGSN, and if the IWF receives this parameter it shall ignore it. 
This parameter shall not be used by the CSS.
IST Alert Timer
This parameter contains the IST Alert timer value that must be used to inform the HLR about the call activities that the subscriber performs.
At Location Updating, restoration, or when there is a change in the IST data defined for the Subscriber, the HLR shall include the IST Alert timer. 
This parameter shall not be used by the CSS.
LMU Identifier
This parameter indicates the presence of an LMU. This parameter is used only by the VLR and shall be ignored if received by an SGSN or an IWF. 
This parameter shall not be used by the CSS.
LCS Information
This parameter provides the following LCS related information for an MS subscriber:
-	list of GMLCs in the HPLMN;
-	privacy exception list;
-	MO-LR list.
At restoration and location updating, the HLR shall include the complete LCS data of the subscriber.
When there is a change in LCS subscriber data the HLR shall include at least the new and/or modified LCS data. LCS data that is not modified need not be included.
The VLR/SGSN shall keep any previously stored LCS Information that is not included in an Insert Subscriber Data operation.
If the VLR/SGSN detects that there is overlapping in the LCS information received within a dialogue, it shall send the error Unexpected Data Value. However, if the VLR receives the LCS code in both the LCS Information and the SS‑Data List, then the VLR shall not interpret this as overlapping data. This parameter is used by the VLR and the SGSN and the IWF. 
This parameter shall not be used by the CSS.
Super-Charger Supported In HLR
This parameter is used by the HLR to indicate support for the Super-Charger functionality. If this parameter is present it shall include an indication of the age of the subscription data stored in the HLR.
If this parameter is absent then the HLR does not support the Super-Charger functionality. 
This parameter shall not be used by the CSS.
SS-Code List
The list of SS-Code parameters for the services that are provided to a subscriber but are not supported/allocated by the VLR/SGSN/IWF (SS-Code is defined in clause 7.6). The list can only include individual SS-Codes that were sent in the service request. For the VLR, this list can also include SS-Codes for the eMLPP and/or CUG services if the above mentioned conditions, as described in eMLPP Subscription Data and/or CUG information List, are met (that is, eMLPP Subscription Data and/or CUG information List are received). 
This parameter shall not be used by the CSS.
ICS-Indicator
This optional flag indicates to the MSC Server enhanced for ICS (see 3GPP TS 23.292 [135]) whether the MSC Server shall attempt the IMS registration.
This parameter is used by the VLR and the SGSN. 
This parameter shall not be used by the CSS.
CSG-Subscription Data
This parameter contains a list of CSG-Ids, the associated expiration dates (see 3GPP TS 22.011 [138]) and a list of corresponding APNs (see 3GPP TS 29.272 [144]. When the VLR or SGSN or MME receives CSG-Subscription Data from the HLR/HSS it shall replace the stored CSG-Subscription Data from the HLR/HSS (if any) with the received data. This parameter is used by the VLR and the SGSN and IWF, except the list of corresponding APNs is not applicable to the VLR, and the VLR shall ignore this list if it is received. 
This parameter shall not be used by the CSS.
VPLMN CSG Subscription Data
This parameter contains a list of CSG-Ids, the associated expiration dates (see 3GPP TS 22.011 [138]). When the VLR or SGSN or MME receives VPLMN CSG Subscription Data from the CSS, it shall replace the stored VPLMN-CSG Subscription Data from the CSS (if any) with the received VPLMN CSG Subscription data. This parameter is used by the VLR, the SGSN and MME.
This parameter is not applicable for the HLR/HSS, and the VLR or SGSN or IWF shall ignore this parameter if it is received from the HLR/HSS.
CSG Subscription Data from the HLR/HSS and VPLMN CSG Subscription Data from the CSS are managed independently in the VLR or SGSN or MME. If the same CSG Id exists in both CSG subscription data from the CSS and CSG subscription data from the HLR/HSS, the CSG subscription data from the HLR/HSS shall take precedence over the CSG subscription data from the CSS in further use.
UE Reachability Request Indicator
This parameter indicates by its presence that the HSS is awaiting a Notification of UE Reachability. This parameter is used by the IWF only. 
This parameter shall not be used by the CSS.
MME Name
This parameter contains the MME identity used over the SGs interface (see 3GPP TS 23.003 [17] clause 19.4.2.4) when stored in the HSS. Otherwise this parameter contains the Diameter Identity of the MME (see 3GPP TS 23.003 [17]). If the subscriber is registered to EPS and the length of the MME Name does not exceed 55 octets, the HLR shall send the MME Name to the VLR during the data restoration procedure if the 'Restoration Indicator' is set in the MAP_RESTORE_DATA request, and during an Update Location procedure if the 'Restoration Indicator' is set in the MAP_UPDATE_LOCATION request. This parameter may be used by the MSC/VLR, e.g. to page the UE via SGs. 
This parameter shall not be used by the CSS.
Subscribed Periodic RAU-TAU Timer
This parameter contains the subscribed periodic RAU/TAU timer (see 3GPP TS 23.401 [145] and 3GPP TS 23.060 [104]) and is used by the SGSN and MME (via IWF). The SGSN and MME shall handle the Subscribed Periodic RAU-TAU Timer as specified in clause 5.2.1.1.2 of  3GPP TS 29.272 [144].
If the VLR receives this parameter it shall ignore it. 
This parameter shall not be used by the CSS.
Subscribed Periodic LAU Timer
This parameter contains the subscribed periodic LAU timer value (see 3GPP TS 23.012 [23]) and is used by the MSC/VLR. The MSC/VLR shall handle the Subscribed Periodic LAU Timer as specified in clause 3.7.3 of  3GPP TS 23.012 [23].
If the SGSN receives this parameter it shall ignore it. 
This parameter shall not be used by the CSS.
SGSN Number
This parameter contains the Identity of the SGSN (see 3GPP TS 23.003 [17]). If the subscriber is registered to GPRS, the HLR shall send the SGSN Number if available to the VLR during the data restoration procedure if the 'Restoration Indicator' is set in the MAP_RESTORE_DATA request, and during an Update Location procedure if the 'Restoration Indicator' is set in the MAP_UPDATE_LOCATION request. This parameter may be used by the MSC/VLR, e.g. to page the UE via Gs. 
This parameter shall not be used by the CSS.
MDT User Consent
This parameter indicates the user consent availability for MDT activation, see 3GPP TS 32.422 [132]. This parameter is used by the VLR, the SGSN and the IWF. 
This parameter shall not be used by the CSS. 
PS and SMS-only Service Provision
This parameter indicates whether the subscription is for PS Only and permits CS service access only for SMS. 
SMS in SGSN Allowed
This parameter indicates whether the HSS allows SMS to be provided by SGSN over NAS.
User Plane Integrity Protection Indicator
This parameter indicates by its presence that the SGSN may decide to activate integrity protection of the user plane when GERAN is used (see 3GPP TS 43.020 [24]).
If the VLR receives this parameter it shall ignore it. 
DL-Buffering Suggested Packet Count
This parameter indicates a suggested DL-Buffering Packet Count. The MME (via IWF) and SGSN may take it into account in addition to local policies, to determine whether to invoke extended buffering of downlink packets at the SGW for High Latency Communication. Otherwise, the MME or SGSN shall make this determination based on local policies only (see 3GPP TS 29.272 [144]).
If the VLR receives this parameter it shall ignore it.
Reset-IDs
This parameter contains a list of subscribed Reset-IDs.
eDRX-Cycle-Length List
This list shall contain the subscribed eDRX cycle length, along with the RAT type to which it is applicable.
IAB-Operation-Allowed-Indicator
This parameter indicates by its presence that IAB operation is authorized for the UE. See 3GPP TS 401 [145].
Regional Subscription Response
If included in the response this parameter indicates one of:
-	Network Node Area Restricted entirely because of regional subscription;
-	Too Many Zone Codes to be inserted;
-	Zone Codes Conflict;
-	Regional Subscription not Supported by the VLR or by the SGSN or MME.
If the VLR determines after insertion of Regional Subscription Data that the entire MSC area is restricted, the VLR shall respond with a Regional Subscription Response indicating MSC Area Restricted. Otherwise MSC Area Restricted is not sent. The HLR shall check whether the current MSC area is no longer restricted.
If the SGSN determines after insertion of Regional Subscription Data that the entire SGSN area is restricted, the SGSN shall respond with a Regional Subscription Response indicating SGSN Area Restricted. Otherwise SGSN Area Restricted is not sent. The HLR shall check whether the current SGSN area is no longer restricted. This parameter is used by the VLR, the SGSN and the IWF. 
This parameter shall not be used by the CSS.
VLR CAMEL Subscription Info
This parameter is sent for subscribers who have CAMEL services which are invoked in the MSC.
-	In CAMEL phase 1, this parameter contains only the O-CSI.
-	In CAMEL Phase 2, this parameter may contain O-CSI, SS-CSI and TIF-CSI. In CAMEL Phase 2 and onwards, TDP-Criteria for O-CSI may be associated with O-CSI.
-	In CAMEL Phase 3, this parameter may contain O-CSI, D-CSI, SS-CSI, VT-CSI, MO-SMS-CSI, M-CSI and TIF-CSI. In CAMEL Phase 3 and onwards,  TDP-Criteria for VT-CSI may be associated with VT-CSI.
-	In CAMEL Phase 4, this parameter may contain O-CSI, D-CSI, SS-CSI, VT-CSI, MO-SMS-CSI, MT-SMS-CSI, M-CSI and TIF-CSI. In CAMEL Phase 4, TDP-Criteria for MT-SMS-CSI may be associated with MT-SMS-CSI.
The VLR CAMEL Subscription Info is sent at location updating or when any information in the applicable CAMEL Subscription Info in the HLR has been changed.
At location updating, the complete set of VLR CAMEL Subscription Info is sent in one dialogue.
When CAMEL Subscription Information is changed in the HLR and changed data have to be sent to the VLR, then:
-	for CAMEL Phase 1 and CAMEL Phase 2, the complete set of VLR CAMEL Subscription Info is sent in one dialogue;
-	for CAMEL Phase 3 or higher, one or more specific elements of VLR CAMEL Subscription Info are sent in one dialogue.
When the VLR receives a specific element of VLR CAMEL Subscription Info, it shall overwrite the corresponding specific element of VLR CAMEL Subscription Info (if any) which it has stored for that subscriber.
For CAMEL Phase 1 and CAMEL Phase 2 , the VLR CAMEL Subscription Info consists of any one or more of:
-	O-CSI (irrespective of the value of the "CAMEL Capability Handling" inside O-CSI),TDP-Criteria for O-CSI,SS-CSI and TIF-CSI.
	(The complete set of above shall be sent even if only one CSI has changed in case of stand alone ISD. The omitted elements of above list will be withdrawn in the VLR.)
From CAMEL phase 3 onwards, the specific elements of VLR CAMEL Subscription Info which may be sent are:
O-CSI (irrespective of the value of the "CAMEL Capability Handling" inside O-CSI), TDP criteria for O-CSI, SS-CSI and TIF-CSI;
	(The complete set of above shall be sent even if only one CSI has changed in case of stand alone ISD. The omitted elements of above list will be withdrawn in the VLR.)
-	D-CSI;
-	VT-CSI;
-	TDP-Criteria for VT-CSI;
-	MO-SMS-CSI;
-	MT-SMS-CSI;
-	TDP-Criteria for MT-SMS-CSI;
-	M-CSI.
If the VLR CAMEL Subscription Info is omitted in the Insert Subscriber Data operation the VLR shall keep the previously stored VLR CAMEL Subscription Info. Within one dialogue subsequent received data are interpreted as add-on data. If the VLR detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value. This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it.
The VLR CAMEL Subscription Info may contain the TIF-CSI (Translation Information Flag) for CAMEL Phase 2 and higher. See 3GPP TS 23.072 for the use of this parameter and the conditions for its presence. 
This parameter shall not be used by the CSS.
Supported CAMEL Phases
The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. This parameter is used by the VLR and SGSN.
A VLR or SGSN not supporting any CAMEL Phase may omit this parameter. An IWF shall omit this parameter. 
This parameter shall not be used by the CSS.
GPRS Subscription Data
This parameter contains a list of PDP-contexts a user has subscribed to; see clause 7.6.
At GPRS location updating the HLR shall include the complete GPRS Subscription Data.
When there is a change in GPRS subscriber data the HLR shall include only the new and/or modified PDP contexts.
When the SGSN receives GPRS Subscription Data within a dialogue it shall check if the received data has to be considered as the entire GPRS subscription data. If so, it shall replace the stored GPRS Subscription Data with the received data set, otherwise it shall replace the data only for the modified PDP contexts (if any) and add the new PDP contexts (if any) to the stored GPRS Subscription Data.
If GPRS Subscription Data is omitted in the Insert Subscriber Data operation the SGSN shall keep the previously stored GPRS Subscription Data.
If the SGSN detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value. This parameter is used only by the SGSN and if the VLR receives this parameter it shall ignore it.
The SGSN shall handle the SIPTO-Permission information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2.
The SGSN shall handle the SIPTO-Local-Network-Permission information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2.
The SGSN shall handle the LIPA Permission information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2. 
The SGSN shall handle the Restoration-Priority information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2.
This parameter shall not be used by the CSS.
EPS Subscription Data
This parameter contains:
-	the UE level APN-OI Replacement (see 3GPP TS 23.401 [145]), and
-	the Subscriber Profile ID for RAT/Frequency Priority (RFSP-ID)  (see 3GPP TS 23.401 [145], 3GPP TS 36.413 [147] and 3GPP TS 23.060 [104]), and
-	the AMBR (see 3GPP TS 23.401 [145] and 3GPP TS 23.060 [104]), and
-	a list of APN Configurations,
-	a session transfer number for SRVCC (STN-SR) (see 3GPP TS 23.003 [17]).
-	MPS CS Priority, which by its presence indicates the UE is subscribed to the eMLPP in the CS domain. 
-	MPS EPS Priority, which by its presence indicates the UE is subscribed to the MPS in the EPS domain. 
-	Subscribed vSRVCC (see 3GPP 29.272 [144]).
This parameter is used only by the MME via IWF and SGSN. If the VLR receives this parameter it shall ignore it. 
The MPS CS Priority and MPS EPS Priority inside the parameter are used only by the MME via IWF. If the SGSN receives them it shall ignore them.
The SGSN shall handle the SIPTO-Permission information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2. 
The SGSN shall handle the SIPTO-Local-Network-Permission information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2.
The SGSN shall handle the LIPA Permission information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2. 
The SGSN shall handle the Restoration-Priority information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2.
The SGSN shall handle the WLAN-offloadability information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2.
This parameter shall not be used by the CSS.
VPLMN LIPA Allowed
This parameter by its presence indicates that the UE is allowed to use LIPA in the PLMN where the UE is attached (see 3GPP TS 23.401 [145] and 3GPP TS 23.060 [104]). 
This parameter is used only by the IWF and SGSN. If the VLR receives this parameter it shall ignore it. 
This parameter shall not be used by the CSS.
SGSN CAMEL Subscription Info
The SGSN CAMEL Subscription Info is sent at GPRS location updating or when any information in the applicable SGSN CAMEL Subscription Info in the HLR has been changed.
-	In CAMEL Phase 3, this parameter may contain one or both of GPRS-CSI and MO-SMS-CSI.
-	In CAMEL Phase 4, this parameter may contain GPRS-CSI, MO-SMS-CSI and MT-SMS-CSI and TDP-Criteria for MT-SMS-CSI.
At GPRS location updating the complete set of SGSN CAMEL Subscription Info is sent.
When CAMEL Subscription Information is changed in the HLR and changed data have to be sent to the SGSN, then one or more specific elements of SGSN CAMEL Subscription Info are sent in one dialogue.
When the SGSN receives a specific element of SGSN CAMEL Subscription Info, it shall overwrite the corresponding specific element of SGSN CAMEL Subscription Info (if any) which it has stored for that subscriber.
The specific elements of SGSN CAMEL Subscription Info which may be sent are:
-	MO-SMS-CSI;
-	MT-SMS-CSI;
-	TDP-Criteria for MT-SMS-CSI;
-	GPRS-CSI;
-	MC-CSI.
This parameter is used only by the SGSN and if the VLR or IWF receives this parameter it shall ignore it. 
This parameter shall not be used by the CSS.
Roaming Restricted In SGSN/MME Due To Unsupported Feature
The HSS/HLR may decide to include this parameter in the request if certain services or features are indicated as not supported by the SGSN/IWF. This parameter is used only by the SGSN and IWFand if the VLR receives this parameter it shall ignore it. 
This parameter shall not be used by the CSS.
CS Allocation/Retention priority 
The CS Allocation/Retention priority is used only for Circuit Switched (CS). This parameter specifies relative importance to compare with other bearers about allocation and retention of bearer. This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. 
This parameter shall not be used by the CSS.
Offered CAMEL 4 CSIs 
This parameter indicates the CAMEL phase 4 CSIs offered in the VMSC/VLR or SGSN (see clause 7.6.3.36D). An IWF shall omit this parameter. 
This parameter shall not be used by the CSS.
Subscribed Charging Characteristics
This parameter refers to the Subscribed Charging Characteristics as defined in 3GPP TS 32.251.
For a detailed description of the use of the parameter, see 3GPP TS 32.251.
This parameter is used only by the SGSN and IWF and if the VLR receives this parameter it shall ignore it. 
This parameter shall not be used by the CSS.
Access Restriction Data
This parameter indicates the allowed RAT for the PLMN where the UE is attached according to subscription data. (see clause 7.6.3.97)
If the VLR/SGSN/MME supports the Access Restriction feature but does not receive the Access Restriction Data parameter from the HSS/HLR at location updating or restoration, the VLR/SGSN/MME shall assume that the subscriber's profile does not have any restrictions enabled.
For a detailed description of the use of the parameter, see 3GPP TS 23.012 [23] for the CS domain and 3GPP TS 23.060[104], 3GPP TS 29.060 [105] clause 7.5.3 and 3GPP TS 29.274 [149] clause 7.3.6 for the PS domain. 
This parameter shall not be used by the CSS.
Supported Features
This parameter shall be used by an IWF to forward feature support indications as received from the MME or SGSN via S6a/S6d. 
This parameter shall not be used by the CSS.
CS-to-PS-SRVCC-Allowed-Indicator
This parameter indicates by its presence to the MSC Server enhanced for ICS (see 3GPP TS 23.292 [135]) that CS to PS SRVCC is subscribed.
This parameter is used by the VLR. 
P-CSCF Restoration Request
This parameter indicates by its presence that the HSS requests to the SGSN or the MME (via the IWF) the execution of the HSS-based P-CSCF restoration procedures, as described in 3GPP TS 23.380 [150], clause 5.4.
This parameter shall not be used by the CSS.
Adjacent Access Restriction Data
This parameter indicates the allowed RAT in each one of the indicated PLMN IDs, according to subscription data.
This parameter shall not be used by the CSS.
IMSI-Group-Id List
A list of IMSI-Group-Id parameters each of which identifies an IMSI-Group the subscriber belongs to.
UE Usage Type
This parameter indicates the usage characteristics of the UE that enables the selection of a specific Dedicated Core Network . It shall not be sent to VLRs and shall not be sent to SGSNs that did not indicate support of the Dedicated Core Network functionality within GPRS-Location Update. When the Insert-Subscriber-Data operation is used within an Update-GPRS-Location Dialogue, the HLR shall include this parameter if the SGSN indicated support of the Dedicated Core Network functionality and a UE Usage Type is available in the subscription data of the user. Outside the Update-Gprs-Location Dialogue the HLR shall include this parameter towards the SGSN that supports the Dedicated Core Network functionality if the value changed. 
User error
Only one of the following values is applicable:
-	Unidentified subscriber;
-	Data missing;
-	Unexpected data value.
8.8.1.4	Basic service information related to supplementary services
A number of parameters that relate to supplementary services can be qualified by a Basic Service Group (or a Basic Service Group List). This clause explains how this information is to be interpreted. Supplementary service parameters to which this clause is applicable only apply to the basic service groups described in this clause, and only those basic service groups shall be overwritten at the VLR or the SGSN.
The Basic Service Group (or Basic Service Group List) is optional.
If present the Basic Service Group (or each element of the Basic Service Group List) shall be one of:
-	an Elementary Basic Service Group for which the supplementary service is applicable to at least one basic service in the group and for which the subscriber has a subscription to at least one basic service in the group;
-	the group "All Teleservices" provided that the service is applicable to at least one teleservice and that the subscriber has a subscription to at least one teleservice which is in the same Elementary Basic Service Group as a teleservice to which the service is applicable;
-	the group "All Bearer Services" provided that the service is applicable to at least one bearer service and that the subscriber has a subscription to at least one bearer service which is in the same Elementary Basic Service Group as a basic service to which the service is applicable.
If the Basic Service Group (or Basic Service Group List) is not present then the parameter shall apply to all Basic Service Groups.
If the basic service information is not a single Elementary Basic Service Group then the parameter shall be taken as applying individually to all the Elementary Basic Service Groups for which:
-	the supplementary service is applicable to at least one basic service in the Basic Service Group; and
-	the subscriber has a subscription to at least one basic service in the Basic Service Group.
The VLR and the SGSN are not required to store supplementary services data for Basic Service Groups which are not supported at the VLR or the SGSN respectively.
8.8.2	MAP-DELETE-SUBSCRIBER-DATA service
8.8.2.1	Definition
This service is used by an HLR to remove certain subscriber data from a VLR or SGSN if the subscription of one or more supplementary services or basic services is withdrawn. Note that this service is not used in case of erasure or deactivation of supplementary services.
This service is also used by an HLR to remove GPRS subscription data from an SGSN. 
This service is also used by an HSS via IWF to remove EPS subscription data from an MME. 
This service is also used by a CSS to remove the CSG subscription data from an MME via IWF or a VLR/SGSN.

It is a confirmed service and consists of the primitives shown in table 8.8/2.
8.8.2.2	Service primitives
Table 8.8/2: MAP-DELETE-SUBSCRIBER-DATA
Parameter name
Request
Indication
Response
Confirm

Invoke Id
M
M(=)
M(=)
M(=)

IMSI
M
M(=)



Basic service List
C
C(=)



SS-Code List
C
C(=)



Roaming Restriction Due To





Unsupported Feature
C
C(=)



Camel Subscription Info Withdraw
C
C(=)



Specific CSI Withdraw
C
C(=)



Regional Subscription Data
C
C(=)



VBS Group Indication 
C
C(=)



VGCS Group Indication
C
C(=)



GPRS Subscription Data Withdraw
C
C(=)



EPS Subscription Data Withdraw
C
C(=)



Roaming Restricted In SGSN/MME Due To Unsupported Feature
C
C(=)



LSA Information Withdraw
C
C(=)



IST Information Withdraw
C
C(=)



Regional Subscription Response


C
C(=)

GMLC List Withdraw
C
C(=)



Subscribed Charging Characteristics Withdraw
C
C(=)



CSG Information Deleted
C
C(=)



VPLMN CSG Information Deleted
C
C(=)



APN-OI-Replacement Withdraw
C
C(=)



STN-SR Withdraw
C
C(=)



Subscribed vSRVCC Withdraw
C
C(=)



Subscribed Periodic RAU-TAU Timer Withdraw
C
C(=)



Subscribed Periodic LAU Timer Withdraw
C
C(=)



Additional MSISDN Withdraw
C
C(=)



CS-to-PS-SRVCC Withdraw
C
C(=)



User Plane Integrity Protection Withdraw
C
C(=)



DL-Buffering Suggested Packet Count Withdraw
C
C(=)



UE-Usage-Type Withdraw
C
C(=)



Reset-IDs Withdraw
C
C(=)




IAB-Operation-Withdraw
C
C(=)


User error


C
C(=)

Provider error



O


8.8.2.3	Parameter use
All parameters are described in clause 7.6. The following clarifications are applicable:
Basic service List
A list of Extensible Basic service parameters (Extensible Basic service is defined in clause 7.6). It is used when one, several or all basic services are to be withdrawn from the subscriber. If the VLR or the SGSN receives a value for an Extensible Basic Service which it does not support, it shall ignore that value. This parameter is used by the VLR and by the SGSN; if the IWF receives this parameter it shall ignore it. 
This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS.
SS-Code List
A list of SS-Code parameters (SS-Code is defined in clause 7.6). It is used when several or all supplementary services are to be withdrawn from the subscriber.
There are three possible options:
-	deletion of basic service(s);
The parameter Basic service List is only included.
-	deletion of supplementary service(s);
The parameter SS-Code List is only included.
-	deletion of basic and supplementary services;
Both Basic service List and SS-Code List are included.
This parameter is used by the VLR and SGSN and IWF for Call Barring and LCS. Otherwise, this parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. 
This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS.
Roaming Restriction Due To Unsupported Feature
This parameter is used if Roaming Restriction Due To Unsupported Feature is deleted from the subscriber data. This may occur if unsupported features or services are removed from the subscriber data in the HLR.
If this parameter is sent the VLR shall check if the current Location Area is possibly allowed now. This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. 
This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS.
CAMEL Subscription Info Withdraw
This parameter is used to indicate that CAMEL Subscription Info shall be deleted from the VLR or from the SGSN. All CAMEL Subscription Info for the subscriber shall be deleted. This parameter is used by the VLR and by the SGSN. This parameter should not be sent in the same message as the Specific CSI Withdraw parameter; if the IWF receives this parameter it shall ignore it. 
This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS.
Specific CSI Withdraw
This parameter is used to indicate that one or more specific elements of CAMEL Subscription Info shall be deleted from the VLR or from the SGSN. 
The specific elements of CAMEL Subscription Info which may be withdrawn are:
-	O-CSI with TDP criteria for O-CSI;
-	SS-CSI;
-	TIF-CSI;
-	D-CSI;
-	VT-CSI with TDP criteria for VT-CSI;
-	MO-SMS-CSI;
-	MT-SMS-CSI with TDP-Criteria for MT-SMS-CSI;
-	M-CSI;
-	MG-CSI;
-	GPRS-CSI.
This parameter is used by the VLR and by the SGSN; if the IWF receices this parameter it shall ignore it. It shall not be sent to VLRs that do not support CAMEL phase 3 or higher. This parameter should not be sent in the same message as the CAMEL Subscription Info Withdraw parameter. 
This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS.
Regional Subscription Identifier
Contains one single Zone Code (as defined in clause 7.6) and is used if all Zone Codes shall be deleted from the subscriber data. When all the Zone Codes are deleted, the VLR, the SGSN or the MME shall check for its location areas whether they are allowed or not. If the whole Network Node area is restricted, the VLR, the SGSN or the MME (via the IWF) will report it to HLR by returning the Regional Subscription Response "Network Node Area Restricted". 
The binary coding of the Zone Code value received in a Delete Subscriber Data request shall not be checked by the VLR, the SGSN or the MME.
Note that support of this parameter is a network operator option and it shall not be sent to networks which do not support Regional Subscription.
If Regional Subscription is not supported by the VLR, the SGSN or the MME, the request for deletion of Zone Codes is refused by sending the Regional Subscription Response "Regional Subscription Not Supported" to the HLR.
If no Zone Codes are stored in the respective subscriber data record, the request for deleting all Zone Code information shall be ignored and no Regional Subscription Response shall be returned. This parameter is used by the VLR, the SGSN and the MME. 
This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS.
VBS Group Indication
Contains an indication (flag) which is used if all Group Ids shall be deleted from the subscriber data for the Voice Broadcast teleservice.
If VBS is not supported in the VLR or no Group Ids are stored for VBS in the respective subscriber record, the request for deletion of all Group Ids shall be ignored. This parameter is used only by the VLR and if the SGSN or the IWF receives this parameter it shall ignore it. 
This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS.
VGCS Group Indication
Contains an indication (flag) which is used if all Group Id's shall be deleted from the subscriber data for the Voice Group Call teleservice. This parameter is used only by the VLR and if the SGSN receives this parameter it shall ignore it.
If VGCS is not supported in the VLR or no Group Ids are stored for VGCS in the respective subscriber record, the request for deletion of all Group Ids shall be ignored. 
This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS.
GPRS Subscription Data Withdraw
This parameter is used to indicate whether all GPRS Subscription Data for the subscriber shall be deleted or if only a subset of the stored GPRS Subscription Data for the subscriber shall be deleted. In the latter case only those PDP contexts whose identifiers are included in the subsequent identifier list will be deleted. This parameter is used only by the SGSN and if the VLR receives this parameter it shall ignore it. 
This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS.
EPS Subscription Data Withdraw
This parameter is used to indicate whether all EPS Subscription Data for the subscriber shall be deleted or if only a subset of the stored EPS Subscription Data for the subscriber shall be deleted. In the latter case, only those APN Configurations whose identifiers are included in the subsequent identifier list will be deleted. This parameter is used only by the SGSN and the MME and if the VLR receives this parameter it shall ignore it. 
This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS.
Roaming Restricted In SGSN/MME Due To Unsupported Feature
This parameter is used if Roaming Restricted In SGSN/MME Due To Unsupported Feature is deleted from the GPRS/EPS subscriber data. This may occur if unsupported features or services are removed from the GPRS/EPS subscriber data in the HLR.
If this parameter is sent the SGSN shall check if the current Location Area is possibly allowed now. This parameter is used only by the SGSN and the IWF and if the VLR receives this parameter it shall ignore it. 
This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS.
LSA Information Withdraw
This parameter is used to indicate whether all LSA Information for the subscriber shall be deleted or if only a subset of the stored LSA Information for the subscriber shall be deleted. In the latter case only the LSA data whose LSA identities are included in the subsequent LSA data list will be deleted. This parameter is used by the VLR and the SGSN. 
This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS.
IST Information Withdraw
This parameter is used to indicate that the IST condition has been removed for the subscriber. See 3GPP TS 43.035 for the use of this parameter. 
This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS.
Regional Subscription Response
If included in the Delete Subscriber Data response this parameter indicates one of:
-	Network Node Area Restricted;
-	Regional Subscription Not Supported.
This parameter is used by the VLR, the SGSN and the IWF. 
This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS.
GMLC List Withdraw
This parameter indicates that the subscriber's LCS GMLC List shall be deleted from the VLR or SGSN. This parameter is used by the VLR and the SGSN and IWF. 
This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS.
Subscribed Charging Characteristics Withdraw
This parameter indicates that the Subscribed Charging Characteristics shall be replaced with a local default value in the SGSN or in the MME (see 3GPP TS 32.251).
This parameter is used only by the SGSN and the IWF and if the VLR receives this parameter it shall ignore it. 
This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS.
CSG Information Deleted
This parameter indicates that CSG Subscription Information received from the HLR/HSS shall be deleted from VLR, SGSN, or MME.
This parameter is used  by the VLR, SGSN and the IWF. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS.
VPLMN CSG Information Deleted
This parameter indicates that CSG Subscription Information received from the CSS shall be deleted from VLR, SGSN.
This parameter is used by the VLR and SGSN. This parameter is not applicable for the HLR/HSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the HLR/HSS.
APN-OI-Replacement Withdraw
This parameter indicates that APN-OI-Replacement shall be deleted from the SGSN or the MME.
This parameter is used  by the SGSN and the IWF and if the VLR receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS.
STN-SR Withdraw
This parameter indicates that STN-SR shall be deleted from the SGSN or the MME.
This parameter is used  by the SGSN and the IWF and if the VLR receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS.
Subscribed vSRVCC Withdraw
This parameter indicates that Subscribed vSRVCC shall be deleted from the MME.
This parameter is used  by the MME and the IWF and if the SGSN or VLR receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS.
Subscribed Periodic RAU-TAU Timer Withdraw
This parameter indicates that Subscribed Periodic RAU-TAU Timer value shall be deleted from the SGSN or the MME.
This parameter is used  by the SGSN and the IWF and if the VLR receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS.
Subscribed Periodic LAU Timer Withdraw
This parameter indicates that Subscribed Periodic LAU Timer value shall be deleted from the VLR.
This parameter is used  by the VLR and if the MME or SGSN receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS.
Additional MSISDN Withdraw
This parameter indicates that Additional MSISDN shall be deleted from the SGSN or MME.
This parameter is used by the SGSN and the IWF.
CS-to-PS-SRVCC Withdraw
This parameter indicates by its presence that CS to PS SRVCC is no longer subscribed.
User Plane Integrity Protection Withdraw
This parameter indicates by its presence that User Plane Integrity Protection may no longer be required. 
DL-Buffering Suggested Packet Count Withdraw
This parameter indicates by its presence that a suggested DL-Buffering Packet Count is no longer subscribed.
UE-Usage-Type Withdraw
This parameter indicates by its presence that a UE-Usage-Type is no longer subscribed.
This parameter is not applicable for VLRs.
The HLR shall include this parameter towards the SGSN or MME (via IWF) that supports the Dedicated Core Network functionality if the subscription to a UE-Usage-Type is removed. 
Reset-IDs Withdraw
This parameter indicates by its presence that Reset-IDs are no longer subscribed.
IAB-Operation-Withdraw
This parameter indicates by its presence that IAB operation is no longer authorized for the UE.
User error
Only one of the following values is applicable:
-	Unidentified subscriber;
-	Data missing;
-	Unexpected data value.
8.9	Identity management services
8.9.1	MAP-PROVIDE-IMSI service
8.9.1.1	Definition
This service is used by a VLR in order to get, via the MSC, the IMSI of a subscriber (e.g. when a subscriber has identified itself with a TMSI not allocated to any subscriber in the VLR).
It is a confirmed service and consists of the primitives shown in table 8.9/1.
8.9.1.2	Service primitives
Table 8.9/1: MAP-PROVIDE-IMSI
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
IMSI


C
C(=)
User error


C
C(=)
Provider error



O

8.9.1.3	Parameter use
All parameters are described in clause 7.6. The following clarifications are applicable:
IMSI
This parameter is received when the request is successfully carried out. It contains the requested IMSI.
User error
Only one of the following values is applicable:
-	Absent subscriber.
8.9.2	MAP-FORWARD-NEW-TMSI service
8.9.2.1	Definition
This service is used by a VLR to allocate, via MSC, a new TMSI to a subscriber during an ongoing transaction (e.g. call set-up, location updating or supplementary services operation).
It is a confirmed service and consists of the primitives shown in table 8.9/2.
8.9.2.2	Service primitives
Table 8.9/2: MAP-FORWARD-NEW-TMSI
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
TMSI
M
M(=)


Provider error



O

8.9.2.3	Parameter use
The parameter TMSI is described in clause 7.6.
8.10	Fault recovery services
8.10.1	MAP_RESET service
8.10.1.1	Definition
This service is used by the HSS/HLR or CSS, after a restart, to indicate to a list of VLRs, SGSNs or MMEs (via IWF) that a failure occurred.
This service may also be used by the HSS/HLR as part of operation and maintenance actions e.g. to allow planned HLR/HSS outage without service interruption, or to update subscription data shared by multiple subscribers.
The MAP_RESET service is a non-confirmed service using the service primitives defined in table 8.10/1.
8.10.1.2	Service primitives
Table 8.10/1: MAP_RESET
Parameter name
Request
Indication
Invoke Id
M
M(=)
Sending Node Number
M
M(=)
HLR Id LIST
U
C(=)
Reset-ID LIST
C
C(=)
Subscription Data
C
C(=)
Subscription Data Deletion
C
C(=)

8.10.1.3	Parameter definition and use
Invoke Id
See definition in clause 7.6.1.
SendingNode Number
For a restart of the HLR/HSS, this parameter shall contain the HLR number. See definition in clause 7.6.2.
For a restart of the CSS, this parameter shall contain the CSS number. See definition in clause 7.6.2.
HLR Id LIST
The HLR Id List is a list of HLR Ids. If the parameter is present in the indication, the VLR, the SGSN or the MME may base the retrieval of subscribers to be restored on their IMSI: the subscribers affected by the reset are those whose IMSI leading digits are equal to one of these numbers. If the parameter and the Reset-ID List is absent, subscribers to be restored are those for which the OriginatingEntityNumber received at location updating time matches the equivalent parameter of the Reset Indication.
This parameter shall only be applicable for a restart of the HLR/HSS. It shall not be present if Reset-ID LIST is present.
Reset-ID LIST
The Reset-ID LIST is a list of Reset-IDs. It shall not be present if Reset-IDs are not supported by the HLR/HSS and by theVLR or SGSN or MME (via IWF). If the parameter is present in the indication, the VLR, the SGSN or the MME may base the retrieval of affected subscribers (i.e. those impacted by the restoration or by the shared data update) on their subscribed Reset-IDs: The subscribers affected by the reset are those whose subscription contains at least one of these Reset-IDs. 
Subscription Data
If the Reset Procedure is used to add/ modify subscription data shared by multiple subscribers, this Information Element shall contain the part of the subscription profile that either is to be added to the subscription profile stored in the VLR, MME or SGSN or combined MME/SGSN or is replacing a part of the subscription profiles of the impacted subscribers stored in the VLR, MME or SGSN.
Shall be absent if Subsciption Data Deletion is present.
Shall be absent if Reset-ID LIST is absent 
Subscription Data Deletion
If the Reset Procedure is used to delete subscription data shared by multiple subscribers, this Information Element shall contain the identifications of the part of the subscription profile that is to be deleted from the subscription profiles of the impacted subscribers stored in the VLR, MME or SGSN.
Shall be absent if Subsciption Data is present.
Shall be absent if Reset-ID LIST is absent 

8.10.2	MAP_FORWARD_CHECK_SS_INDICATION service
8.10.2.1	Definition
This service may be used by an HLR as an implementation option, to indicate to a mobile subscriber that supplementary services parameters may have been altered, e.g. due to a restart. If received from the HLR, the VLR shall forward this indication to the MSC, which in turn forwards it to the MS. The HLR only sends this indication after successful completion of the subscriber data retrieval from HLR to VLR that ran embedded in a MAP_UPDATE_LOCATION procedure.
The MAP_FORWARD_CHECK_SS_INDICATION service is a non-confirmed service using the service primitives defined in table 8.10/2.
8.10.2.2	Service primitives
Table 8.10/2: MAP_FORWARD_CHECK_SS_INDICATION
Parameter name
Request
Indication
Invoke Id
M
M(=)

8.10.2.3	Parameter definition and use
Invoke Id
See definition in clause 7.6.1.
8.10.3	MAP_RESTORE_DATA service
8.10.3.1	Definition
This service is invoked by the VLR on receipt of a MAP_PROVIDE_ROAMING_NUMBER indication for an unknown IMSI, or for a known IMSI with the indicator " Subscriber Data Confirmed by HLR" set to "Not confirmed". The service is used to update the LMSI in the HLR, if provided, and to request the HLR to send all data to the VLR that are to be stored in the subscriber's IMSI record.
This service may be invoked by the VLR on receipt of a "MAP-MT-FORWARD-SHORT-MESSAGE" message for an unknown IMSI, or for a known IMSI with the indicator "Subscriber Data Confirmed by HLR" set to "Not confirmed". The service is used to update the LMSI in the HLR, if provided, and to request the HLR to send all data to the VLR that are to be stored in the subscriber's IMSI record.
The HLR shall return the error "system failure" to the VLR if the subscriber is not registered on the VLR.
The MAP_RESTORE_DATA service is a confirmed service using the service primitives defined in table 8.10/3.
8.10.3.2	Service primitives
Table 8.10/3: MAP_RESTORE_DATA
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
IMSI
M
M(=)


LMSI
U
C(=)


Supported CAMEL phases
C
C(=)


SoLSA Support Indicator
C
C(=)


IST Support Indicator
C
C(=)


Super-Charger Supported in Serving Network Entity
C
C(=)


Long FTN Supported
C
C(=)


Supported LCS Capability Sets
C
C(=)


Offered CAMEL 4 CSIs
C
C(=)


Restoration Indicator
U
C(=)


Supported RAT Types Indicator
U
C(=)


MTRF Supported
U
C(=)


MSISDN-less Operation Supported
C
C(=)


HLR number


C
C(=)
MS Not Reachable Flag


C
C(=)
User error


C
C(=)
Provider error



O

8.10.3.3	Parameter definitions and use
Invoke Id
See definition in clause 7.6.1.
IMSI
See definition in clause 7.6.2.
LMSI
See definition in clause 7.6.2. It is an operator option to provide the LMSI from the VLR; it is mandatory for the HLR to support the LMSI handling procedures.
Supported CAMEL Phases
This parameter indicates which phases of CAMEL are supported. Must be present if a CAMEL phase different from phase 1 is supported. Otherwise may be absent.
SoLSA Support Indicator
This parameter is used by the VLR to indicate to the HLR in the Restore Data indication that SoLSA is supported. If this parameter is not included in the Restore Data indication then the HLR shall not perform any specific error handling. 
This SoLSA Support Indicator shall be stored by the HLR per VLR where there are Subscribers roaming. If a Subscriber is marked as only allowed to roam in Subscribed LSAs while roaming in a VLR and no SoLSA Support indicator is stored for that VLR, the location status of that Subscriber shall be set to Restricted.
IST Support Indicator
This parameter is used to indicate to the HLR that the VMSC supports basic IST functionality, that is, the VMSC is able to terminate the Subscriber Call Activity that originated the IST Alert when it receives the IST alert response indicating that the call(s) shall be terminated. If this parameter is not included in the Restore Data indication and the Subscriber is marked as an IST Subscriber, then the HLR may limit the service for the subscriber (by inducing an Operator Determined barring of  Outgoing calls), or allow service assuming the associated risk of not having the basic IST mechanism available. 
This parameter can also indicate that the VMSC supports the IST Command service, including the ability to terminate all calls being carried for the identified subscriber by using the IMSI as a key. If this additional capability is not included in the Restore Data indication and the HLR supports the IST Command capability, then the HLR may limit the service for the subscriber (by inducing an Operator Determined barring of Outgoing calls), or allow service assuming the associated risk of not having the IST Command mechanism available.
Long FTN Supported
This parameter indicates that the VLR supports Long Forwarded-to Numbers.
Super-Charger Supported in Serving Network Entity
This parameter is used by the VLR to indicate to the HLR that the VLR supports the Super-Charger functionality and that subscriber data is required.
If this parameter is absent then the VLR does not support the Super-Charger functionality.
Supported LCS Capability Sets
This parameter indicates, if present, the capability sets of LCS which are supported. If the parameter is sent but no capability set is marked as supported then the VLR does not support LCS at all.
If this parameter is absent then the VLR may support at most LCS capability set 1, that is LCS Release98 or Release99 version.
Offered CAMEL 4 CSIs 
This parameter indicates the CAMEL phase 4 CSIs offered in the VMSC/VLR (see clause 7.6.3.36D).
Restoration Indicator
This parameter indicates, if present, that the HLR shall send in the MAP-INSERT-SUBSCRIBER-DATA the MME Name if the subscriber is registered to EPS, or the SGSN Number if available and if the subscriber is registered to GPRS. The VLR may set this indicator if it supports Gs or SGs interfaces.
Supported RAT Types Indicator
This parameter indicates, if present, which access technologies (e.g. GERAN and / or UTRAN) are served by the MSC/VLR (see clause 7.6.3)
MTRF Supported
See 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence.
MSISDN-less Operation Supported
See clause 3.6.1.5 of 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence.
HLR number
See definition in clause 7.6.2. The presence of this parameter is mandatory in case of successful outcome of the service.
MS Not Reachable Flag
See definition in clause 7.6.8. This parameter shall be present in case of successful outcome of the service, if the "MS Not Reachable flag" was set in the HLR.
User error
In case of unsuccessful outcome of the service, an error cause shall be returned by the HLR. The following error causes defined in clause 7.6.1 may be used, depending on the nature of the fault:
-	unknown subscriber;
-	system failure;
-	unexpected data value;
-	data missing.
Provider error
For definition of provider errors see clause 7.6.1.
8.11	Subscriber Information services
8.11.1	MAP-ANY-TIME-INTERROGATION service
8.11.1.1	Definition
This service is used by the gsmSCF, to request information (e.g. subscriber state and location) from the HLR or the GMLC at any time. This service may also be used by the gsmSCF to request the Mobile Number Portability (MNP) information from the NPLR.
This service is also used by the Presence Network Agent to request information, (e.g. subscriber state and location) about the subscriber (associated with a presentity) from the HLR at any time (see 3GPP TS 23.141 [128]).
When this service is used to the HLR, the subscriber state, location, Time Zone, or T-ADS data may be requested.
When this service is used to the GMLC, only the location may be requested. 
When this service is used to the NPLR, only the MNP information may be requested.
The MAP-ANY-TIME-INTERROGATION service is a confirmed service using the service primitives defined in table 8.11/1.
8.11.1.2	Service primitives
Table 8.11/1: Any_Time_Interrogation
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
Requested Info
M
M(=)


Requested domain
C
C(=)


MNP Requested Info
C
C(=)


gsmSCF-Address
M
M(=)


IMSI
C
C(=)


MSISDN
C
C(=)


Location Information


C
C(=)
Location Information for GPRS


C
C(=)
Location Information for EPS


C
C(=)
Subscriber State


C
C(=)
PS Subscriber State


C
C(=)
EPS Subscriber State


C
C(=)
IMEI


C
C(=)
MS Classmark 2


C
C(=)
GPRS MS Class


C
C(=)
MNP info Result


C
C(=)
IMS Voice Over PS Sessions Support Indicator


C
C(=)
Last UE Activity Time


C
C(=)
Last RAT Type


C
C(=)
Time Zone


C
C(=)
Daylight Saving Time


C
C(=)
User error


C
C(=)
Provider error



O

8.11.1.3	Parameter definition and use
All parameters are described in clause 7.6. The use of these parameters and the requirements for their presence are specified in 3GPP TS 23.018 [97] and 3GPP TS 23.078 [98].
The HLR or GMLC may be able to use the value of the parameter gsmSCF-address to screen a MAP_Any_Time_Interrogation indication.
The use of the parameters and the requirements for their presence are specified in 3GPP TS 23.078 [98]. 
IMS Voice Over PS Sessions Support Indicator
This parameter indicates the most recent IMS-Voice-Over-PS-Sessions support (based on the Last UE Activity Time), as received from the serving nodes. This parameter shall be present if Requested Info indicates that T-ADS Data are requested.
Last UE Activity Time
This parameter indicates the most recent available point in time of the UE's last radio contact, as received from the serving nodes. This value may not represent the absolute last instant of radio activity of the UE, when any of the serving nodes has not answered to the T-ADS query. This parameter may be present if requested Info indicates that T-ADS Data are requested. This value may not be available when all the serving nodes have indicated an homogeneous support or an homogeneous non support of IMS Voice Over PS Sessions, since in that case, the serving nodes do not need to be explicitly asked for T-ADS Data. 
Last RAT Type
This parameter indicates the most recent available RAT Type of the access (based on the Last UE Activity Time), as received from the serving nodes. This parameter shall be present if requested Info indicates that T-ADS Data are requested and the IMS Voice Over PS Sessions Support Indicator does not take the value "unknown". This value may not represent the absolute last RAT Type of the UE, when any of the serving nodes has not answered to the T-ADS query. This parameter may be present if requested Info indicates that T-ADS Data are requested. This value may not be available when all the serving nodes have indicated an homogeneous support or an homogeneous non support of IMS Voice Over PS Sessions, since in that case, the serving nodes do not need to be explicitly asked for T-ADS Data.
Time Zone
This parameter indicates the Time Zone of the location in the visited network where the UE is attached, including any adjustment for summertime (daylight saving time).
Daylight Saving Time
This parameter indicates the Daylight Saving Time (in steps of 1 hour) used to adjust for summertime the time zone of the location where the UE is attached in the visited network. 
User error
This parameter is sent by the responder when an error is detected and if present, takes one of the following values:
-	System Failure;
-	Any Time Interrogation Not Allowed;
-	Data Missing;
-	Unexpected Data Value;
-	Unknown Subscriber.
Provider error
These are defined in clause 7.6.1.
8.11.2	MAP-PROVIDE-SUBSCRIBER-INFO service
8.11.2.1	Definition
This service is used to request information (e.g. subscriber state and location) from the VLR, SGSN or MME (via an IWF) at any time.
The MAP-PROVIDE-SUBSCRIBER-INFO service is a confirmed service using the primitives defined in table 8.11/2.
8.11.2.2	Service primitives
Table 8.11/2: Provide_Subscriber_Information
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
Requested Info
M
M(=)


IMSI
M
M(=)


LMSI
U
O


Call Priority
U
O


Location Information


C
C(=)
Location Information for GPRS


C
C(=)
Subscriber State


C
C(=)
PS Subscriber State


C
C(=)
IMEI


C
C(=)
MS Classmark 2


C
C(=)
GPRS MS Class


C
C(=)
IMS Voice Over PS Sessions Support Indicator


C
C(=)
Last UE Activity Time


C
C(=)
Last RAT Type


C
C(=)
Location Information for EPS


C
C(=)
Time Zone


C
C(=)
Daylight Saving Time


C
C(=)
User error


C
C(=)
Provider error



O

8.11.2.3	Parameter definition and use
All parameters are defined in clause 7.6. The use of these parameters and the requirements for their presence are specified in 3GPP TS 23.018 [97] and 3GPP TS 23.078 [98].
Call Priority
This parameter indicates the eMLPP priority of the call (see 3GPP TS 24.067 [137]). This parameter should be present if the HLR supports this parameter and if the Call Priority was received in the MAP_SEND_ROUTING_INFORMATION request. 
IMS Voice Over PS Sessions Support Indicator
This parameter indicates whether IMS Voice Over PS Sessions is supported at the UE's current Routing Area. This parameter shall be present if the UE's current Routing Area is known to the SGSN and the Requested Info indicates that T-ADS Data are requested; otherwise it shall be absent.
Last UE Activity Time
This parameter indicates the point in time of the UE's last radio contact. This parameter shall be present if requested Info indicates that T-ADS Data are request.
Last RAT Type
This parameter indicates the RAT Type of the access where the UE was present at the time of the last radio contact. This parameter shall be present if requested Info indicates that T-ADS Data are request.
Time Zone
This parameter indicates the Time Zone of the location in the visited network where the UE is attached, including any adjustment for summertime (daylight saving time).
Daylight Saving Time
This parameter indicates the Daylight Saving Time (in steps of 1 hour) used to adjust for summertime the time zone of the location where the UE is attached in the visited network. 
User error
This parameter is sent by the responder when an error is detected and if present, takes one of the following values:
-	Data Missing;
-	Unexpected Data Value.
If the subscriber is not found on the VLR, SGSN or MME, this may be indicated to the requester with the "Unexpected Subscriber" value inside the Unexpected Data Value error
Provider error
These are defined in clause 7.6.1.
8.11.3	MAP-ANY-TIME-SUBSCRIPTION-INTERROGATION service
8.11.3.1	Definition
This service is used by the gsmSCF, to request subscription information (e.g. call forwarding supplementary service data or CSI) from the HLR at any time.  In an IP Multimedia Core Network, an IM-SSF can take on the role of a gsmSCF for this service. 

8.11.3.2	Service primitives
Table 8.11/3: Any_Time_Subscription_Interrogation
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
Requested Subscription Info
M
M(=)


GsmSCF-Address
M
M(=)


IMSI
C
C(=)


MSISDN
C
C(=)


Long FTN Supported
C
C(=)


Call Forwarding Data


C
C(=)
Call Barring Data


C
C(=)
ODB Info


C
C(=)
CAMEL Subscription Info


C
C(=)
Supported CAMEL phases in VLR


C
C(=)
Supported CAMEL phases in SGSN


C
C(=)
Offered CAMEL 4 CSIs in VLR


C
C(=)
Offered CAMEL 4 CSIs in SGSN


C
C(=)
MSISDN-BS-List


C
C(=)
CSG Subscription Data


C
C(=)
Call Hold Data


C
C(=)
Call Waiting Data


C
C(=)
Explicit Call Transfer Data


C
C(=)
Calling Line Identification Presentation Data


C
C(=)
Calling Line Identification Restriction Data


C
C(=)
User error


C
C(=)
Provider error



O

8.11.3.3	Parameter definition and use
All parameters are described in clause 7.6.
The HLR may be able to use the value of the parameter gsmSCF-address to screen a MAP_Any_Time_Subscription_Interrogation indication.  The gsmSCF-address shall contain the IM-SSF address when the IM-SSF takes the role of the gsmSCF.

The use of the parameters and the requirements for their presence are specified in 3GPP TS 23.078 [98] and 3GPP TS 23.278 [125].
User error
This parameter is sent by the responder when an error is detected and if present, takes one of the following values:
-	Unexpected Data Value;
-	Unknown Subscriber;
-	BearerServiceNotProvisioned;
-	TeleserviceNotProvisioned;
-	CallBarred;
-	IllegalSS-Operation;
-	SS-NotAvailable;
-	InformationNotAvailable;
-	Any Time Subscription Interrogation Not Allowed;
-	Data Missing.
Provider error
These are defined in clause 7.6.1.
8.11.4	MAP-ANY-TIME-MODIFICATION service
8.11.4.1	Definition
This service is used by the gsmSCF, to modify information of the HLR at any time.
This service is also used by the Presence Network Agent to activate or deactivate reporting of mobility management events (associated with a presentity) from the VLR or SGSN  (see 3GPP TS 23.141 [128]).
This service is also used by a Service Related Entity (e.g. the IP-SM-GW) to activate a one-time subscription of UE-reachability in the MME (see 3GPP TS 23.204 [134]) and SGSN (see 3GPP TS 23.060 [104]). 
This service is also used by external Short Message Gateway (IP-SM-GW) for updating the IP-SM-GW Number stored in the HLR, and for retrieving SC Address from the HLR.
8.11.4.2	Service primitives
Table 8.11/4: Any_Time_Modification
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
gsmSCF-Address
M
M(=)


Subscriber Identity
M
M(=)


Modification request for ODB data
C
C(=)


Modification request for SS information
C
C(=)


Modification request for CSI
C
C(=)


Modification request for CSG
C
C(=)


Long FTN Supported
C
C(=)


Modification request for IP-SM-GW data
C
C(=)


Activation request for UE-Reachability
C
C(=)


Ext Forwarding information-for-CSE


C
C(=)
Ext Call barring information-for-CSE


C
C(=)
ODB Info


C
C(=)
CAMEL subscription info


C
C(=)
Service Centre Address


C
C(=)
User error


C
C(=)
Provider error



O

8.11.4.3	Parameter definition and use
All parameters are described in clause 7.6.
The HLR may be able to use the value of the parameter gsmSCF-address to screen a MAP_Any_Time_Modification indication.
The use of parameters other than described below and the requirements for their presence are specified in 3GPP TS 23.078  [98] and 3GPP TS 23.278 [125].
gsmSCF-Address
This parameter indicates the address of the interrogating gsmSCF. The gsmSCF Address shall be in international E.164 format. If the service is used by IP-SM-GW, the parameter contains the address of the IP-SM-GW. See also 3GPP TS 23.078 [98] and 3GPP TS 23.278 [125].
Modification request for CSG
This parameter is used by the gsmSCF to request notification of modification of CSG subscription data.
Modification request for IP-SM-GW data
This parameter is used by the external IP-SM-GW for updating the IP-SM-GW Number and IP-SM-GW Diameter Address stored in the HLR. If this parameter is present then other modification requests shall not be present.
Activation request for UE Reachability
This parameter is used by the Service Related Entity (e.g. IP-SM-GW) to activate the one-time subscription for UE-Reachability. If this parameter is present then other modification requests shall not be present.
Service Centre Address
See definition in clause 7.6.2.
User error
This parameter is sent by the responder when an error is detected and if present, takes one of the following values:
-	Any Time Modification Not Allowed;
-	Data Missing;
-	Unexpected Data Value;
-	Unknown Subscriber;
-	Bearer service not provisioned;
	This error is returned only if not even a subset of the requested bearer service group has been subscribed to;
-	Teleservice not provisioned;
	This error is returned only if not even a subset of the requested teleservice group has been subscribed to;
-	Call Barred;
-	Illegal SS operation;
-	SS error status;
-	SS incompatibility;
-	SS subscription violation;
-	Information Not Available.
Provider error
These are defined in clause 7.6.1.
8.11.5	MAP-NOTE-SUBSCRIBER-DATA-MODIFIED service
8.11.5.1	Definition
This service is used by the HLR to inform the gsmSCF that subscriber data have been modified.  In an IP Multimedia Core Network, an IM-SSF can take on the role of a gsmSCF for this service.
This service is also used by the HLR to inform the Service Related Entity (e.g. IP-SM-GW) that the UE has become reachable (see 3GPP TS 23.204 [134]).
8.11.5.2	Service primitives
Table 8.11/5: Note_Subscriber_Data_Modified
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
IMSI
M
M(=)


MSISDN
M
M(=)







Ext Forwarding information-for-CSE
C
C(=)


Ext Call barring information-for-CSE
C
C(=)


ODB Info
C
C(=)


CAMEL subscription info
C
C(=)


CSG Subscription Data
C
C


CW info
C
C(=)


CH info
C
C(=)


CLIP Info
C
C(=)


CLIR Info
C
C(=)


ECT Info
C
C(=)


All Information Sent
C
C(=)


UE reachable
C
C(=)


User error


C
C(=)
Provider error



O

8.11.5.3	Parameter definition and use
Invoke id
See clause 7.6.1 for the use of this parameter.
IMSI
See clause 7.6.2 for the use of this parameter.
MSISDN
See clause 7.6.2 for the use of this parameter.  In an IP Multimedia Core Network, if no MSISDN is available, the HLR shall populate this parameter with the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [17]).
Ext Forwarding information-for-CSE
See clause 7.6.3 for the use of this parameter. The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98].
Ext Call barring information-for-CSE
See clause 7.6.3 for the use of this parameter. The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98].
ODB Info
See clause 7.6.3 for the use of this parameter. The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98].
CAMEL subscription info
See clause 7.6.3 for the use of this parameter. The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98] and 3GPP TS 23.278 [125].
CSG Subscription Data
This parameter contains a list of CSG-Ids and the associated expiration dates (see 3GPP TS 22.011 [138]). The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98].

CW Info
This parameter contains the status of the call waiting supplementary service. The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98]
CH Info
This parameter contains the status of the call hold supplementary service.The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98]
ECT Info
This parameter contains the status of the explicit call transfer supplementary service.The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98]
CLIP Info
This parameter contains the status of the calling line identification presentation supplementary service.The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98]
CLIR Info
This parameter contains the status of the calling line identification restriction supplementary service.The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98]
All Information Sent
This parameter is set when the HLR has sent all information to gsmSCF.
UE Reachable
This parameter is used when the HLR indicates to the Service related entity (e.g. IP-SM-GW) that the UE is reachable again.
User error
This parameter is sent by the responder when an error is detected and if present, takes one of the following values:
-	Data Missing;
-	Unexpected Data Value;
-	Unknown Subscriber.
Provider error
These are defined in clause 7.6.1.
The use of the parameters and the requirements for their presence are specified in 3GPP TS 23.078 [98] and 3GPP TS 23.278 [125].
9	Operation and maintenance services
9.1	Subscriber tracing services
9.1.1	MAP-ACTIVATE-TRACE-MODE service
9.1.1.1	Definition
This service is used between the HLR and the VLR to activate subscriber tracing in the VLR.
Also this service is used between the HLR and the SGSN to activate subscriber tracing in the SGSN.
The MAP-ACTIVATE-TRACE-MODE service is a confirmed service using the primitives from table 9.1/1.
9.1.1.2	Service primitives
Table 9.1/1: MAP-ACTIVATE-TRACE-MODE
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
IMSI
C
C(=)


Trace reference
M
M(=)


Trace type
M
M(=)


Trace reference 2
C
C(=)


Trace depth list
C
C(=)


Trace NE type list
C
C(=)


Trace interface list
C
C(=)


Trace event list
C
C(=)


Trace support indicator


C
C(=)
OMC Id
U
C(=)


MDT-Configuration
C
C(=)


User error


C
C(=)
Provider error



O

9.1.1.3	Parameter use
Invoke id
See definition in clause 7.6.1.
IMSI
See definition in clause 7.6.2. The IMSI is a mandatory parameter in a stand-alone operation.
Trace reference
See definition in clause 7.6.10. This parameter contains trace reference for GSM only tracing request.
Trace type
See definition in clause 7.6.10. This parameter contains trace type for GSM only tracing request.
OMC Id
See definition in clause 7.6.2. The use of this parameter is an operator option.
Trace reference 2
See definition in clause 7.6.10. This parameter shall be used for UMTS trace activation.
Trace depth list
See definition in clause 7.6.10. This parameter shall be used for UMTS trace activation.
Trace NE type list
See definition in clause 7.6.10. This parameter shall be used for UMTS trace activation.
Trace interface list
See definition in clause 7.6.10. This parameter shall be used for UMTS trace activation.
Trace event list
See definition in clause 7.6.10. This parameter shall be used for UMTS trace activation.
Trace support indicator
See definition in clause 7.6.10. This parameter shall be used for UMTS trace activation.
MDT-Configuration
See definition in clause 7.6.10. 
User error
The following errors defined in clause 7.6.1 may be used, depending on the nature of the fault:
-	Unidentified Subscriber;
-	Facility Not Supported;
-	Tracing Buffer Full;
-	System Failure;
-	Unexpected Data Value;
-	Data missing.
Provider error
For definition of provider errors see clause 7.6.1.
9.1.2	MAP-DEACTIVATE-TRACE-MODE service
9.1.2.1	Definition
This service is used between the VLR and the HLR for deactivating subscriber tracing in the VLR.
Also this service is used between the SGSN and the HLR for deactivating subscriber tracing in the SGSN.
The MAP-DEACTIVATE-TRACE-MODE service is a confirmed service using the primitives from table 9.1/2.
9.1.2.2	Service primitives
Table 9.1/2: MAP-DEACTIVATE-TRACE-MODE
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
IMSI
C
C(=)


Trace reference
M
M(=)


Trace reference 2
C
C(=)


User error


C
C(=)
Provider error



O

9.1.2.3	Parameter use
Invoke id
See definition in clause 7.6.1.
IMSI
See definition in clause 7.6.2. The IMSI is a mandatory parameter in a stand-alone operation.
Trace reference
See definition in clause 7.6.10.
Trace reference 2
See definition in clause 7.6.10. This parameter shall be used for UMTS trace activation.
User error
The following errors defined in clause 7.6.1 may be used, depending on the nature of the fault:
-	Unidentified Subscriber;
-	Facility Not Supported;
-	System Failure;
-	Unexpected Data Value;
-	Data missing.
Provider error
For definition of provider errors see clause 7.6.1.
9.1.3	MAP-TRACE-SUBSCRIBER-ACTIVITY service
9.1.3.1	Definition
This service is used between the VLR and the MSC to activate the subscriber tracing in the MSC.
The MAP-TRACE-SUBSCRIBER-ACTIVITY service is a non-confirmed service using the primitives from table 9.1/3.
9.1.3.2	Service primitives
Table 9.1/3: MAP-TRACE-SUBSCRIBER-ACTIVITY
Parameter name
Request
Indication
Invoke id
M
M(=)
IMSI
C
C(=)
Trace reference
M
M(=)
Trace type
M
M(=)
OMC Id
U
C(=)

9.1.3.3	Parameter use
Invoke id
See definition in clause 7.6.1.
IMSI
See definition in clause 7.6.2. The controlling MSC shall provide either the IMSI or the IMEI to the servicing MSC.
Trace reference
See definition in clause 7.6.10.
Trace type
See definition in clause 7.6.10.
OMC Id
See definition in clause 7.6.2. The use of this parameter is an operator option.
9.2	Other operation and maintenance services
9.2.1	MAP-SEND-IMSI service
9.2.1.1	Definition
This service is used by a VLR in order to fetch the IMSI of a subscriber in case of some Operation & Maintenance procedure where subscriber data are needed in the Visited PLMN and MSISDN is the only subscriber's identity known.
It is a confirmed service and consists of the primitives shown in table 9.2/1.
9.2.1.2	Service primitives
Table 9.2/1: MAP-SEND-IMSI
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
MSISDN
M
M(=)


IMSI


C
C(=)
User error


C
C(=)
Provider error



O

9.2.1.3	Parameter use
All parameters are described in clause 7.6. The following clarifications are applicable.
User error
Only one of the following values is applicable:
-	Unknown subscriber;
-	Unexpected data value;
-	Data missing.
10	Call handling services
10.1	MAP_SEND_ROUTING_INFORMATION service
10.1.1	Definition
This service is used between the Gateway MSC and the HLR. The service is invoked by the Gateway MSC to perform the interrogation of the HLR in order to route a call towards the called MS.
This is a confirmed service using the primitives listed in table 10.1/1.
This service is also used between the GMSC and the NPLR and between the gsmSCF and the HLR.
10.1.2	Service primitives
Table 10.1/1: MAP_SEND_ROUTING_INFORMATION parameters
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
Interrogation Type
M
M(=)


GMSC or gsmSCF Address
M
M(=)


MSISDN
M
M(=)
C
C(=)
OR Interrogation
C
C(=)


OR Capability
C
C(=)


CUG Interlock
C
C(=)
C
C(=)
CUG Outgoing Access
C
C(=)
C
C(=)
Number of Forwarding
C
C(=)


Network Signal Info
C
C(=)


Supported CAMEL Phases
C
C(=)
C
C(=)
Suppress T-CSI
C
C(=)


Offered CAMEL 4 CSIs
C
C(=)


Suppression of Announcement
C
C(=)


Call Reference Number
C
C(=)


Forwarding Reason
C
C(=)


Basic Service Group
C
C(=)


Basic Service Group 2
C
C(=)


Alerting Pattern
C
C(=)


CCBS Call
C
C(=)


Supported CCBS Phase
C
C(=)


Additional Signal Info
C
C(=)


IST Support Indicator
C
C(=)


Pre-paging supported
C
C(=)


Call Diversion Treatment Indicator
C
C(=)


Long FTN Supported
C
C(=)


Suppress VT-CSI
C
C(=)


Suppress Incoming Call Barring
C
C(=)


SuppressMTSS
C
C(=)


gsmSCF Initiated Call
C
C(=)


Network Signal Info 2
C
C(=)


MT Roaming Retry Supported
U
C(=)


Call Priority
U
C(=)


IMSI


C
C(=)
MSRN


C
C(=)
Forwarding Data


C
C(=)
Forwarding Interrogation Required


C
C(=)
VMSC address


C
C(=)
ReleaseResourcesSupported


C
C(=)
GMSC Camel Subscription Info


C
C(=)
Location Information


C
C(=)
Subscriber State


C
C(=)
Basic Service Code


C
C(=)
CUG Subscription Flag


C
C(=)
North American Equal Access preferred Carrier Id


U
C(=)
User error


C
C(=)
SS-List


U
C(=)
CCBS Target


C
C(=)
Keep CCBS Call Indicator


C
C(=)
IST Alert Timer


C
C(=)
Number Portability Status


U
C(=)
Supported CAMEL Phases in VMSC


C

Offered CAMEL 4 CSIs in VMSC


C
C(=)
MSRN 2


C
C(=)
Forwarding Data 2


C
C(=)
SS-List 2


C
C(=)
Basic Service Code 2


C
C(=)
Allowed Services


C
C(=)
Unavailability Cause


C
C(=)
Provider error



O
GSM Bearer Capability


U
C(=)

10.1.3	Parameter use
See clause 7.6 for a definition of the parameters used in addition to the following. Note that:
-	a conditional parameter whose use is defined only in 3GPP TS 23.078 shall be absent if the sending entity does not support CAMEL;
-	a conditional parameter whose use is defined only in 3GPP TS 23.079 [99] shall be absent if the sending entity does not support optimal routeing;
-	a conditional parameter whose use is defined only in 3GPP TS 23.078 & 3GPP TS 23.079 [99] shall be absent if the sending entity supports neither CAMEL nor optimal routeing.
Interrogation Type
See 3GPP TS 23.079 [99] for the use of this parameter.
GMSC or gsmSCF address
The E.164 address of the GMSC or the gsmSCF. This parameter contains the gsmSCF address if the gsmSCF iniated call parameter is present, otherwise it is the GMSC address.
MSISDN
This is the Mobile Subscriber ISDN number assigned to the called subscriber. In the Request & Indication it is the number received by the GMSC in the ISUP IAM. If the call is to be forwarded and the HLR supports determination of the redirecting number, the HLR inserts the basic MSISDN in the Response.
See 3GPP TS 23.066 [108] for the use of this parameter and the conditions for its presence in the response.
OR Interrogation
See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence.
OR Capability
See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence.
CUG Interlock
See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence.
CUG Outgoing Access
See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence.
Number of Forwarding
See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence.
Network Signal Info
See 3GPP TS 23.018 [97] for the conditions for the presence of the components of this parameter.
Supported CAMEL Phases
The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078.
T-CSI Suppression
The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078.
Offered CAMEL 4 CSIs 
This parameter indicates the CAMEL phase 4 CSIs offered in the GMSC/VLR (see clause 7.6.3.36D).

Suppression Of Announcement
The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078.
Call Reference Number
The use of this parameter and the conditions for its presence are specified in 3GPP TS 23.078 [98], 3GPP TS 23.079 [99] and 3GPP TS 23.018 [97].
Forwarding Reason
See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence.
Basic Service Group
See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. 
Basic Service Group 2
See 3GPP TS 23.079[99] for the use of this parameter and the conditions for its presence.
Alerting Pattern
See 3GPP TS 23.018 [97] and 3GPP TS 23.078 [98] for the use of this parameter and the conditions for its presence.
CCBS Call
See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence.
Supported CCBS Phase
This parameter indicates by its presence that CCBS is supported and the phase of CCBS which is supported.
Additional Signal Info
See 3GPP TS 23.081 [27] and 3GPP TS 23.088 [33] for the conditions for the presence of the components of this parameter.
IST Support Indicator
This parameter is used to indicate to the HLR that the GMSC supports basic IST functionality, that is, the GMSC is able to terminate the subscriber call activity that originated the IST Alert when it receives the IST Alert response indicating that the call(s) shall be terminated. If this parameter is not included in the Send Routing Information indication and the subscriber is marked as an IST subscriber, then the HLR may limit the service for the call (by barring the incoming call if it is not subject to forwarding, or suppressing Call Forwarding from the GMSC), or allow the call assuming the associated risk of not having the basic IST mechanism available.
This parameter can also indicate that the GMSC supports the IST Command, including the ability to terminate all calls being carried for the identified subscriber by using the IMSI as a key. If this additional capability is not included in the Send Routing Information indication and the subscriber is marked as an IST subscriber, then the HLR may limit the service for the subscriber (by barring the incoming calls if they are not subject to forwarding, or suppressing Call Forwarding from the GMSC), or allow the incoming calls assuming the associated risk of not having the IST Command mechanism available.
Pre-paging supported
See 3GPP TS 23.018 for the use of this parameter and the conditions for its presence.
Call Diversion Treatment Indicator
This parameter indicates whether or not call diversion is allowed. 
Network Signal Info 2
See 3GPP TS 23.172 [126] for the conditions for the presence of the components of this parameter.
MT Roaming Retry Supported
See 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence.
Call Priority
This parameter indicates the eMLPP priority of the call (see 3GPP TS 24.067 [137]). This parameter should be present if the GMSC supports the eMLPP feature and if the call is an eMLPP call. The eMLPP priority levels A and B shall be mapped to the Call Priority level 0.
IMSI
See 3GPP TS 23.018 [97] and 3GPP TS 23.066 [108] for the use of this parameter and the conditions for its presence.
MSRN
See 3GPP TS 23.018 [97], 3GPP TS 23.066 [108] and 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. If the NPLR returns only the MSISDN-number without Routeing Number to the GMSC, the MSISDN-number shall be returned as MSRN.
Forwarding Data
This parameter includes a number to define the forwarded-to destination, the forwarding reason and the forwarding options Notification to calling party and Redirecting presentation, and can include the forwarded-to subaddress. See 3GPP TS 23.018 [97] and 3GPP TS 23.079 [99] for the conditions for the presence of its components.
Forwarding Interrogation Required
See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence.
Long FTN Supported
This parameter indicates that the GMSC supports Long Forwarded-to Numbers.
Suppress VT-CSI
The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078.
Suppress Incoming Call Barring
The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078.
gsmSCF Initiated Call
The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078.
SuppressMTSS
The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078.
VMSC address
See 3GPP TS 23.079 [99] and 3GPP TS 23.078 [98] for the use of this parameter and the conditions for its presence. 
In addition this parameter shall be present if the ReleaseResourcesSupported parameter is present.
Release Resources Supported
This parameter indicates by its presence that the MAP_RELEASE_RESOURCES service is supported at the VMSC. It shall be present if so indicated by the VMSC with MAP_PROVIDE_ROAMING_NUMBER confirm.
GMSC CAMEL Subscription Info
The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078.
Location Information
The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078.
Subscriber State
The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078.
CUG Subscription Flag
The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078.
North American Equal Access preferred Carrier Id
This parameter is returned to indicate the preferred carrier identity to be used to set-up the call (i.e. forwarding the call or establishing the roaming leg).
SS-List
This parameter includes SS-codes and will be returned as an operator option. The HLR shall not send PLMN-specific SS-codes across PLMN boundaries. However if the GMSC receives PLMN-specific SS-codes from a foreign PLMN's HLR the GMSC may ignore it. If the GMSC attempts to process the PLMN- specific SS- codes, this may lead to unpredictable behaviour but the GMSC shall continue call processing.
Basic Service Code
The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078.
If the CAMEL service is not involved, this parameter includes the basic service code and will be returned as an operator option. The HLR shall not send a PLMN-specific Basic Service Code across PLMN boundaries. However if the GMSC receives a PLMN-specific Basic Service Code from a foreign PLMN's HLR the GMSC may ignore it. If the GMSC attempts to process the PLMN specific Basic Service codes, this may lead to unpredictable behaviour but the GMSC shall continue call processing.
CCBS Target
See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence.
Keep CCBS Call Indicator
See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence.
IST Alert Timer
It includes the IST Alert timer value that must be used to inform the HLR about the call activities that the subscriber performs. This parameter is only sent to the GMSC in response to a Send Routing Information request which indicates the the GMSC supports IST.
Number Portability Status
This parameter indicates the number portability status of the subscriber. This parameter may be present if the sender of SRIack is NPLR.
Supported CAMEL Phases in VMSC
The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078.
Offered CAMEL 4 CSIs in VMSC
This parameter is defined in clause 7.6.3.36F.
MSRN 2
The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.172 [126].
Forwarding Data 2
The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.172 [126].
SS-List 2
The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.172 [126].
Basic Service Code 2
The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.172 [126].
Allowed Services
The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.172 [126].
Unavailability Cause
The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.172 [126].
User error
This parameter is sent by the responder when an error is detected and if present, takes one of the following values:
-	Unknown Subscriber;
The diagnostic for the Unknown Subscriber error may indicate "NPDB Mismatch".
-	Number changed;
-	Call Barred;
	This error will indicate that either incoming calls are barred for this MS or that calls are barred due to Operator Determined Barring (see 3GPP TS 22.041 [8] for a definition of this network feature);
-	CUG Reject;
	The value of this error cause will indicate the reason for CUG Reject;
-	Bearer Service Not Provisioned;
-	Teleservice Not Provisioned;
	A subscription check has been performed and the call has not passed the check due to incompatibility with regard to the requested service. Depending on the nature of the incompatibility, either of these messages will be returned;
-	Facility Not Supported;
-	Absent Subscriber;
	This indicates that the location of the MS is not known (either the station is not registered and there is no location information available or the Provide Roaming Number procedure fails due to IMSI detached flag being set), or the GMSC requested forwarding information with a forwarding reason of not reachable, and the call forwarding on MS not reachable service is not active; this may also indicate that the MS has moved to a new MSC/VLR and that MT Roaming Retry is requested (see 3GPP TS 23.018 [97]);
-	Busy Subscriber;
	This indicates that Call Forwarding on Busy was not active for the specified basic service group when the GMSC requested forwarding information with a forwarding reason of busy;
	The error may also indicate that the subscriber is busy due to an outstanding CCBS recall. In the error data it may then be specified that CCBS is possible for the busy encountered call;
-	No Subscriber Reply;
	This indicates that Call Forwarding on No Reply was not active for the specified basic service group when the GMSC requested forwarding information with a forwarding reason of no reply;
-	OR Not Allowed;
	This indicates that the HLR is not prepared to accept an OR interrogation from the GMSC, or that calls to the specified subscriber are not allowed to be optimally routed;
-	Forwarding Violation;
-	System Failure;
-	Data Missing;
-	Unexpected Data Value.
See clause 7.6.1.4 for a definition of these errors.
Provider error
These are defined in clause 7.6. 
GSM Bearer Capability
This information is passed according to the rules specified in 3GPP TS 29.007 [56]. There may be two GSM Bearer Capabilities supplied.

10.2	MAP_PROVIDE_ROAMING_NUMBER service
10.2.1	Definition
This service is used between the HLR and VLR. The service is invoked by the HLR to request a VLR to send back a roaming number to enable the HLR to instruct the GMSC to route an incoming call to the called MS.
This service is also used between old VLR and new VLR during the MT Roaming Forwarding procedure. The service is invoked by the old VLR to request a roaming number from the new VLR to be able to route an incoming call to the called UE.
This is a confirmed service which uses the primitives described in table 10.2/1.
10.2.2	Service primitives
Table 10.2/1: MAP_PROVIDE_ROAMING_NUMBER parameters
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
IMSI
M
M(=)


MSC Number
M
M(=)


MSISDN
U
C(=)


LMSI
C
C(=)


GSM Bearer Capability
C
C(=)


Network Signal Info
C
C(=)


Suppression Of Announcement
C
C(=)


Call Reference Number
C
C(=)


GMSC Address
C
C(=)


OR Interrogation
C
C(=)


OR Not Supported in GMSC
C
C(=)


Alerting Pattern
C
C(=)


CCBS Call
C
C(=)


Supported CAMEL Phases in interrogating node
C
C(=)


Additional Signal Info
C
C(=)


Pre-paging supported
C
C(=)


Long FTN Supported
C
C(=)


Suppress VT-CSI
C
C(=)


Offered CAMEL 4 CSIs in interrogating node
C
C(=)


MT Roaming Retry Supported
U
C(=)


Paging Area
U
C(=)


Call Priority
U
C(=)


MTRF Indicator
U
C(=)


Old MSC Number
U
C (=)


Last used LTE PLMN ID
U
C(=)


Roaming Number


C
C(=)
VMSC address


U
C(=)
ReleaseResourcesSupported


U
C(=)
User error


C
C(=)
Provider error



O

10.2.3	Parameter use
See clause 7.6 for a definition of the parameters used, in addition to the following. Note that:
-	a conditional parameter whose use is defined only in 3GPP TS 23.078 [98] shall be absent if the sending entity does not support CAMEL;
-	a conditional parameter whose use is defined only in 3GPP TS 23.079 [99] shall be absent if the sending entity does not support optimal routeing;
-	a conditional parameter whose use is defined only in 3GPP TS 23.078 [98] & 3GPP TS 23.079 [99] shall be absent if the sending entity supports neither CAMEL nor optimal routeing.
IMSI
This is the IMSI of the called Subscriber.
MSC Number
This is the ISDN number assigned to the MSC currently serving the MS. When the service is used between HLR and VLR, the MSC number will have been stored in the HLR as provided at location updating. When used between old VLR and new VLR during an MT Roaming Forwarding procedure, the MSC number will have been provided at location cancelling or within Send Identification.
MSISDN
See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence.
LMSI
See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence. In addition, for the mobile terminating roaming forwarding procedure between the old VLR and the new VLR, this parameter shall be present if the MTRF Indicator is present and the old VLR has received the new LMSI in Cancel Location from the HLR or in Send Identification from the new VLR.
GSM Bearer Capability
See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence.
This information is passed according to the rules specified in TS 3GPP TS 29.007 [56].
There may be two GSM Bearer Capabilities supplied.
Network Signal Info
See 3GPP TS 23.018 [97] for the conditions for the presence of the components of this parameter.
Suppression Of Announcement
The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078 [98].
Call Reference Number
The use of this parameter and the conditions for its presence are specified in 3GPP TS 23.078 [98], 3GPP TS 23.079 [99] and 3GPP TS 23.018 [97].
GMSC Address
The use of this parameter and the conditions for its presence are specified in 3GPP TS 23.078 [98], 3GPP TS 23.079 [99] and 3GPP TS 23.018 [97].
OR Interrogation
See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence.
OR Not Supported in GMSC
See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence.
Supported CAMEL Phases in interrogating node 
This parameter is defined in clause 7.6.3.36I.Alerting Pattern 
See 3GPP TS 23.078 [98] for the use of this parameter and the conditions for its presence.
CCBS Call
See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence.
Additional Signal Info
See 3GPP TS 23.081 [27] for the conditions for the presence of the components of this parameter.
Pre-paging supported
See 3GPP TS 23.018 for the use of this parameter and the conditions for its presence. This information element is not applicable for MTRF, and shall be ignored if received while the MTRF Indicator is present.
Long FTN supported
See 3GPP TS 23.082 for the use of this parameter and the conditions for its presence.
Suppress VT-CSI
See 3GPP TS 23.078 for the use of this parameter and the conditions for its presence.
Offered CAMEL 4 CSIs in interrogating node
This parameter is defined in clause 7.6.3.36E.
MT Roaming Retry Supported
See 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence. This information element is not applicable for MTRF, and shall be ignored if received while the MTRF Indicator is present.
Paging Area
See 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence. This information element is not applicable for MTRF, and shall be ignored if received while the MTRF Indicator is present.
Call Priority
This parameter indicates the eMLPP priority of the call (see 3GPP TS 24.067 [137]). This parameter should be present if the HLR supports this parameter and if the Call Priority was received in the MAP_SEND_ROUTING_INFORMATION request.
MTRF Indicator
This indicator indicates by its presence that the service is used between old VLR and new VLR during an MT Roaming Forwarding procedure. See 3GPP TS 23.018 [97].
Old MSC Number
This parameter refers to the E.164 address of the old MSC. The use of this parameter is specified in 3GPP TS 23.018 [97]. This information element is applicable only if the MTRF Indicator is set.
Last used LTE PLMN ID
See 3GPP TS 23.272 [143] for the use of this parameter and the conditions for its presence. This information element is applicable only if the MTRF Indicator is set.
Roaming Number
See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence.
VMSC address
See 3GPP TS 23.079 [99], 3GPP TS 23.078 [98] and 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence. This parameter shall be present during the Mobile Terminating Roaming Forwarding Call during Retrieval of Routeing Information procedure if an MSRN is allocated by the new MSC/VLR.
ReleaseResourcesSupported
This parameter indicates by its presence that the MAP_RELEASE_RESOURCES service is supported at the VMSC.
User error
This parameter is sent by the responder when an error is detected and if present, takes one of the following values:
-	Absent Subscriber;
	This error will be returned if the IMSI detach flag is set.
-	No Roaming Number Available;
-	OR Not Allowed;
	This indicates that the MAP_PROVIDE_ROAMING_NUMBER indication included the OR interrogation indicator, but the VLR does not support optimal routeing.
-	Facility Not Supported;
-	System Failure;
-	Data Missing;
-	Unexpected Data Value.
See clause 7.6 for a definition of these reasons.
Provider error
These are defined in clause 7.6.
10.3	MAP_RESUME_CALL_HANDLING service
10.3.1	Definition
This service is used between the terminating VMSC and the GMSC. The service is invoked by the terminating VMSC to request the GMSC to resume handling the call and forward it to the specified destination.
This is a confirmed service which uses the Primitives listed in table 10.3/1.
10.3.2	Service primitives
Table 10.3/1: MAP_RESUME_CALL_HANDLING parameters
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
Call Reference Number
C
C(=)


Basic Service Group
C
C(=)


Basic Service Group 2
C
C(=)


IMSI
C
C(=)


Forwarding Data
C
C(=)


CUG Interlock
C
C(=)


CUG Outgoing Access
C
C(=)


O-CSI
C
C(=)


D-CSI
C
C(=)


CCBS Target
C
C(=)


UU Data
C
C(=)


UUS CF Interaction
C
C(=)


All Information Sent
C
C(=)


MSISDN
C
C(=)


MT Roaming Retry
U
C(=)


User error


C
C(=)
Provider error



O

10.3.3	Parameter use
Information received in subsequent segment of a segmented dialogue shall not overwrite information received in an earlier segment.
See clause 7.6 for a definition of the parameters used, in addition to the following.
Call Reference Number
See 3GPP TS 23.079 [99] for the use of this parameter. This parameter shall be present in the first segment of the dialogue.
Basic Service Group
See 3GPP TS 23.079 [99] for the use of this parameter. This parameter shall be present in the first segment of the dialogue. 
Basic Service Group 2
See 3GPP TS 23.079[99] for the use of this parameter. If this parameter is present, it shall be in the first segment of the dialogue.
IMSI
This is the IMSI of the forwarding Subscriber. This parameter shall be present in the first segment of the dialogue.
Forwarding Data
This parameter includes a number to define the forwarded-to destination, the forwarding reason and the forwarding options Notification to calling party and Redirecting presentation, and can include the forwarded-to subaddress. See 3GPP TS 23.079 [99] for the conditions for the presence of its components. This parameter shall be present in a first segment of the dialogue.
CUG Interlock
See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence.
CUG Outgoing Access
See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence.
O-CSI
See 3GPP TS 23.078 for the use of this parameter and the conditions for its presence.
For CAMEL phases 1 & 2, the O-CSI shall contain only one set of O-BCSM TDP data.
D-CSI
The Dialled Services-CSI.
See 3GPP TS 23.078 for the use of this parameter and the conditions for its presence.
CCBS Target
See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. 
UU Data
See 3GPP TS 23.087 for the use of this parameter and the conditions for its presence.
UUS CF Interaction
See 3GPP TS 23.087 for the use of this parameter and the conditions for its presence.
All Information Sent
This parameter is set when the VMSC has sent all information to GMSC.
MT Roaming Retry
See 3GPP TS 23.018 [97], 3GPP TS 23.012 [23] and 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. When this parameter is present, only the Call Reference Number and All Information Sent IEs shall be present; the other IEs shall be ignored by the GMSC if received. 
MSISDN
This parameter is the basic MSISDN of the forwarding subscriber. It shall be present if the VMSC supports determination of the redirecting number. 
User error
This parameter is sent by the responder when an error is detected and if present, takes one of the following values:
-	Optimal Routeing not allowed;
-	Forwarding failed;
-	Unexpected Data Value;
-	Data Missing.
Provider error
These are defined in clause 7.6.
10.4	MAP_PREPARE_GROUP_CALL service
10.4.1	Definition
This service is used by the Anchor_MSC to inform the Relay_MSC about a group call set-up.
The MAP_PREPARE_GROUP_CALL service is a confirmed service using the service primitives given in table 10.4/1.
10.4.2	Service primitives
Table 10.4/1: MAP_PREPARE_GROUP_CALL service
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
Teleservice
M
M(=)


ASCI Call Reference
M
M(=)


Ciphering Algorithm
M
M(=)


Group Key Number VK-Id
C
C(=)


VSTK Key
C
C(=)


VSTK-RAND
C
C(=)


Priority
C
C(=)


CODEC-Information
M
M(=)


Uplink Free Indicator
M
M(=)


Talker Channel Parameter
C
C(=)


Uplink Reply Indicator
C
C(=)


Group Call Number


M
M(=)
User Error


C
C(=)
Provider Error



O

10.4.3	Parameter definitions and use
Invoke Id
See definition in clause 7.6.1.
Teleservice
Voice Broadcast Service or Voice Group Call Service.
ASCI Call Reference
Broadcast call reference or group call reference. This item is used to access the VBS-GCR or VGCS-GCR within the Relay_MSC.
Ciphering Algorithm
The ciphering algorithm to be used for the group call.
Group Key Number VK-Id
This Group Key Number has to be broadcast and is used by the mobile station to derive the key for ciphering on the radio interface (see 3GPP TS 43.020 [24]). Values 2 to 15 are reserved for future use.
Shall be present if the ciphering applies.
VSTK
The VGCS/VBS Short Term Key is used to derive the key for ciphering on the radio interface (see 3GPP TS 43.020 [24]).
Shall be present if the ciphering applies.
VSTK-RAND
This random number has to be broadcast and is used by the mobile station to derive the group key for ciphering on the radio interface (see 3GPP TS 43.020 [24]).
Shall be present if the ciphering applies.
Priority
Default priority level related to the call if eMLPP applies.
CODEC-Information
Information on the codecs allowed for this call.
Uplink Free Indicator
A flag indicating whether the call is initiated from a dispatcher.
Talker Channel Parameter
A flag indicating by its presence that a dedicated channel shall be established and maintained for the talking service subscriber. 
Uplink Reply Indicator
A flag indicating by its presence that the uplink reply procedure is applicable for the voice group call or voice broadcast call.
Group Call Number
This temporary allocated E.164 number is used for routing the call from the Anchor MSC to the Relay MSC.
User Error
For definition of this parameter see clause 7.6.1 The following errors defined in clause 7.6.1 may be used, depending on the nature of the fault:
-	No Group Call Number available;
-	System Failure;
-	Unexpected Data Value.
Provider Error
See definition of provider error in clause 7.6.1.
10.5	MAP_PROCESS_GROUP CALL_SIGNALLING service
10.5.1	Definitions
This service is used between Relay MSC and Anchor MSC for transmission of Group Call notifications.
The MAP_PROCESS_GROUP_CALL_SIGNALLING service is a non-confirmed service using the service primitives given in table 10.5/1.
10.5.2	Service primitives
Table 10.5/1: MAP_PROCESS_GROUP_CALL_SIGNALLING service
Parameter name
Request
Indication
Invoke Id
M
M(=)
Uplink Request 
C
C(=)
Uplink Release Indication
C
C(=)
AN-APDU
C
C(=)
Release Group Call
C
C(=)
Talker Priority
C
C(=)
Additional Info
C
C(=)
Emergency Mode Reset Command Flag
C
C(=)

10.5.3	Parameter definitions and use
Invoke Id
See definition in clause 7.6.1
Uplink Request 
This information element indicates to the anchor MSC that a service subscriber roaming in the relay MSC area requests access to the uplink.
Uplink Release Indication
This information element if included by the Relay MSC indicates to the Anchor MSC that the uplink has become free.
AN-APDU
This parameter contains the Notification Data message as defined in3GPP TS 48.008 [49].
Release Group Call
This information element if included by the Relay MSC indicates to the Anchor MSC that the service subscriber who has initiated the call and who currently has access to the uplink terminates the call.
Talker Priority
For the definition and use of this parameter see 3GPP TS 43.068 [100]
Additional Info 
For the definition and use of this parameter see 3GPP TS 43.068 [100]
Emergency Mode Reset Command Flag
For the definition and use of this parameter see 3GPP TS 43.068 [100]
10.6	MAP_FORWARD_GROUP_CALL_SIGNALLING service
10.6.1	Definitions
This service is used between Anchor MSC and Relay MSC for transmission of Group Call notifications.
The MAP_FORWARD_GROUP_CALL_SIGNALLING service is a non-confirmed service using the service primitives given in table 10.6/1.
10.6.2	Service primitives
Table 10.6/1: MAP_FORWARD_GROUP_CALL_SIGNALLING service
Parameter name
Request
Indication
Invoke Id
M
M(=)
IMSI
C
C(=)
Uplink Request Acknowledgement
C
C(=)
Uplink Release Indication
C
C(=)
Uplink Reject Command
C
C(=)
Uplink Seized Command
C
C(=)
Uplink Release Command
C
C(=)
AN-APDU
C
C(=)
State Attributes
C
C(=)
Talker Priority
C
C(=)
Additional Info
C
C(=)
Emergency Mode Reset Command Flag
C
C(=)
SM RP UI
C
C(=)

10.6.3	Parameter definitions and use
IMSI
Identity of the service subscriber who has established the call and who is allowed to terminate the call.
Invoke Id
See definition in clause 7.6.1.
Uplink Request Acknowledgement
This information element is used for positive acknowledgement of an uplink request.
Uplink Release Indication
This information element if included by the Anchor MSC indicates to the Relay MSC that the uplink has become free.
Uplink Reject Command
This information element is used for negative acknowledgement of an uplink request.
Uplink Seized Command
This information element if included by the Anchor MSC indicates to the Relay MSC that the uplink is no longer free.
Uplink Release Command
This information element if included by the Anchor MSC indicates to the Relay MSC that the uplink which is granted to a MS in the relay MSC area shall be released.
AN-APDU
This parameter contains the Notification Data message as defined in 3GPP TS 48.008 [49] 
State Attributes
This information element is used to allow service logic running in an Anchor MSC to mute a VGCS talker even when the talker is served on a Relay MSC. The IE is used to build a GCC message that provides a mechanism to induce the VGCS talker terminal to mute/unmute the downlink at the Anchor MSC, as defined in 3GPP TS 44.068.
Talker Priority
For the definition and use of this parameter see 3GPP TS 43.068 [100]
Additional Info 
For the definition and use of this parameter see 3GPP TS 43.068 [100]
Emergency Mode Reset Command Flag
For the definition and use of this parameter see 3GPP TS 43.068 [100] 
SM RP UI
See definition in clause 7.6.8. The short message transfer protocol data unit received from the Service Centre is inserted in this parameter. 

10.7	MAP_SEND_GROUP_CALL_END_SIGNAL service
10.7.1	Definitions
This service is used between the Relay MSC and the Anchor MSC. When the VGCS/ VBS calling service subscriber is in the Relay MSC area the MAP_SEND_GROUP_CALL_END_SIGNAL indicates that at least the downlink channel in the originating cell is established. For all other VGCS/ VBS call set-up scenarios (i.e. calling service subscriber in Anchor MSC area, calling service subscriber in other Relay MSC area, dispatcher originated call) the MAP_SEND_GROUP_CALL_END_SIGNAL indicates that at least the downlink channel in any one cell within the VGCS/ VBS call area in the Relay MSC is established. The response is used by the Anchor MSC to inform the Relay MSC that all resources for the call can be released in the Relay MSC because the call has been released in the Anchor MSC.
The MAP_SEND_GROUP_CALL_END_SIGNAL service is a confirmed service using the service primitives given in table 10.7/1.
10.7.2	Service primitives
Table 10.7/1: MAP_SEND_GROUP_CALL_END_SIGNAL service
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
IMSI
C
C(=)


Talker Priority
C
C(=)


Additional Info
C
C(=)


Provider Error



O

10.7.3	Parameter definitions and use
Invoke Id
See definition in clause 7.6.1
IMSI
Identity of the service subscriber who has established the call and who is allowed to terminate the call.
Shall be present if the call was established by a service subscriber roaming in the relay MSC area.
Talker Priority
For the definition and use of this parameter see 3GPP TS 43.068 [100]
Additional Info 
For the definition and use of this parameter see 3GPP TS 43.068 [100]
Provider Error
See definition of provider error in clause 7.6.1.
10.7A	MAP_SEND_GROUP_CALL_INFO service
10.7A.1	Definitions
This service is used in a RANflex configuration (see 3GPP TS 23.236 [133]) between the subscriber's visited MSC and group call serving MSC of the subscriber's location area. 
The MAP_SEND_GROUP_CALL_INFO service is a confirmed service using the service primitives given in table 10.7A/1.
10.7A.2	Service primitives
Table 10.7A/1: MAP_SEND_GROUP_CALL_INFO service
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
Requested Info
M
M(=)


Teleservice
M
M(=)


Cell Id
C
C(=)


Group Id
M
M(=)


IMSI
C
C(=)
C
C(=)
Talker Priority
C
C(=)


Additional Info
C
C(=)
C
C(=)
TMSI
C
C(=)


CKSN
C
C(=)


Anchor MSC Address


C
C(=)
ASCI Call Reference


C
C(=)
Additional Subscriptions


C
C(=)
Kc


C
C(=)
User Error


C
C(=)
Provider Error



O

10.7A.3	Parameter definitions and use
Invoke Id
See definition in clause 7.6.1
Requested Info
For the definition and use of this parameter see 3GPP TS 43.068 [100]
Teleservice
Voice Broadcast Service or Voice Group Call Service.
Cell Id
Identity of the initiating service subscriber's current cell.
Group Id
For the definition and use of this parameter see 3GPP TS 43.068 [100] and 3GPP TS 43.069 [101].
If prefixes are used together with group IDs, the most significant digit of the Group Id contains the prefix.
IMSI
If sent in the request: Identity of the service subscriber who has established the call and who is allowed to terminate the call.
If sent in the response: Identity of the uplink requesting service subscriber.
Talker Priority
For the definition and use of this parameter see 3GPP TS 43.068 [100]
Additional Info 
For the definition and use of this parameter see 3GPP TS 43.068 [100]
TMSI
See definition in clause 7.6.2. 
CKSN
See clause 7.6.7 for the use of this parameter.
Anchor MSC Address
For the definition and use of this parameter see 3GPP TS 43.068 [100] and 3GPP TS 43.069 [101]
ASCI Call Reference
For the definition and use of this parameter see 3GPP TS 43.068 [100] and 3GPP TS 43.069 [101]
Additional Subscriptions
For the definition and use of this parameter see 3GPP TS 43.068 [100]
Kc
See clause 7.6.7 for the use of this parameter.
User Error
For definition of this parameter see clause 7.6.1 The following errors defined in clause 7.6.1 may be used, depending on the nature of the fault:
-	System Failure;
-	Unexpected Data Value;
-	Data Missing
-	TeleserviceNotProvisioned;
-	Unknown Subscriber;
-	Ongoing Call.
Provider Error
See definition of provider error in clause 7.6.1.
10.8	Void
10.9	Void
10.10	MAP_SET_REPORTING_STATE service
10.10.1	Definition
This service is used between the HLR and the VLR to set the reporting state for a requested service. It is a confirmed service using the service primitives shown in table 10.10/1.
10.10.2	Service primitives
Table 10.10/1: MAP_SET_REPORTING_STATE parameters
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
IMSI 
C
C(=)


LMSI 
C
C(=)


CCBS Monitoring
C
C(=)


CCBS Subscriber Status


C
C(=)
User error


C
C(=)
Provider error



O

10.10.3	Parameter use
See clause 7.6 for a definition of the parameters used, in addition to the following.
IMSI
The IMSI is a mandatory parameter if the service is used as the only one in a dialogue.
CCBS Monitoring
This parameter indicates whether monitoring for CCBS shall be started or stopped. If it indicates that monitoring shall be started this service corresponds to the message 'Start Reporting' in 3GPP TS 23.093 [107]; if it indicates that monitoring shall be stopped this service corresponds to the message 'Stop Reporting' in 3GPP TS 23.093 [107].
CCBS Subscriber Status
See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence.
User error
This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clause 7.6.1:
-	System Failure;
-	Unidentified Subscriber;
-	Unexpected Data Value;
-	Data Missing;
-	Resource Limitation;
-	Facility Not Supported.
NOTE:	This error is reserved for future use.
Provider error
These are defined in clause 7.6.
10.11	MAP_STATUS_REPORT service
10.11.1	Definition
This service is used by the VLR to report an event or call outcome to the HLR. It is a confirmed service using the service primitives shown in table 10.11/1.
10.11.2	Service primitives
Table 10.11/1: MAP_STATUS_REPORT parameters
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
IMSI 
M
M(=)


CCBS Subscriber Status
C
C(=)


Monitoring Mode
C
C(=)


Call Outcome
C
C(=)


User error


C
C(=)
Provider error



O

10.11.3	Parameter use
See clause 7.6 for a definition of the parameters used, in addition to the following.
CCBS Subscriber Status
If this parameter is present without Monitoring Mode and Call Outcome this service corresponds to the message 'Event Report' in 3GPP TS 23.093 [107]. See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence.
Monitoring Mode
If this parameter is present with CCBS Call Outcome this service corresponds to the message 'CCBS Call Report' in 3GPP TS 23.093 [107]. See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence.
Call Outcome
See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence.
User error
This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clause 7.6.1:
-	Unknown Subscriber;
-	System Failure;
-	Unexpected Data Value;
-	Data Missing.
Provider error
These are defined in clause 7.6.
10.12	MAP_REMOTE_USER_FREE service
10.12.1	Definition
This service is used between the HLR and the VLR to report that the B subscriber is now idle and that the A subscriber can be notified. It is a confirmed service using the service primitives shown in table 10.12/1.
10.12.2	Service primitives
Table 10.12/1: MAP_REMOTE_USER_FREE parameters
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
IMSI
M
M(=)


Call Info
M
M(=)


CCBS Feature
M
M(=)


Translated B Number
M
M(=)


Replace B Number
C
C(=)


Alerting Pattern
C
C(=)


RUF Outcome


C
C(=)
User error


C
C(=)
Provider error



O

10.12.3	Parameter use
See clause 7.6 for a definition of the parameters used, in addition to the following.
Call Info
See 3GPP TS 23.093 [107] for the use of this parameter.
CCBS Feature
See 3GPP TS 23.093 [107] for the conditions for the presence of the parameters included in the CCBS feature.
Translated B Number
See 3GPP TS 23.093 [107] for the use of this parameter.
Replace B Number
See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence.
Alerting Pattern
See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence.
RUF Outcome
See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence.
User error
This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clause 7.6.1:
-	Unexpected Data Value;
-	Data Missing;
-	Incompatible Terminal;
-	This error is returned by the responder when the terminal used for CCBS activation is not compatible with the terminal used for the CCBS recall. For details refer to 3GPP TS 24.008 [35];
-	Absent Subscriber (IMSI Detach; Restricted Area; No Page Response);
-	System Failure;
-	Busy Subscriber (CCBS Busy).
Provider error
These are defined in clause 7.6.
10.13	MAP_IST_ALERT service
10.13.1	Definition
This service is used between the MSC (Visited MSC or Gateway MSC) and the HLR, to report that the IST timer running for a call for the Subscriber has expired. It is a confirmed service using the service primitives shown in table 10.13/1.
10.13.2	Service primitives
Table 10.13/1: MAP_IST_ALERT parameters
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
IMSI
M
M(=)


IST Alert Timer


C
C(=)
IST Information Withdraw


C
C(=)
Call termination Indicator


C
C(=)
User error


C
C(=)
Provider error



O

10.13.3	Parameter use
All parameters are described in clause 7.6. The following clarifications are applicable:
IST Alert Timer
If included in the IST Alert response, it includes the new IST Alert timer value that must be used to inform the HLR about the call activities that the subscriber performs.
IST Information Withdraw
 If included in the IST Alert response, this parameter is used to indicate that the IST condition has been removed for the subscriber. When the MSC receives this parameter, IST control for that call shall be terminated.
Call termination Indicator
If included in the IST Alert response, this parameter is used to indicate whether the MSC shall terminate the call activity that had previously triggered the IST Alert procedure, or it shall also release all other call activities for the specified subscriber (outgoing call activities if the IST Alert is initiated by the VMSC, or incoming call activities if the IST Alert is initiated by the GMSC). Release of all other call activities is possible only if the MSC has the capability to link the call activities for the Subscriber by using the IMSI as key.
User error
This parameter is sent by the responder when an error is detected and if present, takes one of the following values:
-	System Failure;
-	Unexpected Data Value;
-	Resource Limitation;
-	Facility Not Supported;
-	Unknown Subscriber.
10.14	MAP_IST_COMMAND service
10.14.1	Definition
This service is used by the HLR to instruct the MSC (Visited MSC or Gateway MSC) to terminate ongoing call activities for a specific subscriber. It is a confirmed service using the service primitives shown in table 10.14/1.
10.14.2	Service primitives
Table 10.14/1: MAP_IST_COMMAND parameters
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
IMSI
M
M(=)


User error


C
C(=)
Provider error



O

10.14.3	Parameter use
All parameters are described in clause 7.6. The following clarifications are applicable:
User error
This parameter is sent by the responder when an error is detected and if present, takes one of the following values:
-	System Failure;
-	Unexpected Data Value;
-	Resource Limitation;
-	Facility Not Supported;
-	Unknown Subscriber.
10.15	MAP_RELEASE_RESOURCES service
10.15.1	Definition
This service is used between the GMSC and the terminating VMSC. The service is invoked by the GMSC to request the VMSC to release the resources associated with the specified MSRN.
This is a confirmed service which uses the Primitives listed in table 10.15/1.
10.15.2	Service primitives
Table 10.15/1: MAP_RELEASE_RESOURCES parameters
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
MSRN
M
M(=)


User error


C
C(=)
Provider error



O

10.15.3	Parameter use
MSRN
See 3GPP TS 23.018 [97] for the use of this parameter. 
User error
This parameter is sent by the responder when an error is detected and if present, takes one of the following values:
-	System Failure;
-	Unexpected Data Value;
Provider error
These are defined in clause 7.6.
11	Supplementary services related services
11.1	MAP_REGISTER_SS service
11.1.1	Definition
This service is used between the MSC and the VLR and between the VLR and the HLR to register data related to a supplementary service. The VLR will relay the message to the HLR.
The service is a confirmed service and uses the service primitives shown in table 11.1./1.
11.1.2	Service primitives
Table 11.1/1: MAP_REGISTER_SS parameters
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
SS-Code
M
M(=)


Basic service
C
C(=)


Forwarded-to number with subaddress
C
C(=)


No reply condition time
C
C(=)


EMLPP default priority
C
C(=)
C
C(=)
Long FTN Supported
C
C(=)


NbrUser
C
C(=)
C
C(=)
Forwarding information


C
C(=)
User error


C
C(=)
Provider error



O

11.1.3	Parameter use
Invoke id
See clause 7.6.1 for the use of this parameter.
SS-Code
This parameter indicates the supplementary service which the mobile subscriber wants to register.
Basic service
This parameter indicates for which basic service group the supplementary service is to be registered. If it is not included, the registration request applies to all basic services.
Forwarded-to number with subaddress
This parameter is obligatory if the registration applies to one or more call forwarding supplementary services. It can optionally include a sub-address.
No reply condition time
This parameter is included if the registration applies to the Call Forwarding on No Reply supplementary service (or a superset of this service) and the mobile subscriber supplies a value for this time.
EMLPP default priority
This parameter is sent by the initiator to register the eMLPP default priority level and is returned by the responder at successful outcome of the service.
Long FTN Supported
This parameter indicates that the mobile station supports Long Forwarded-to Numbers.
NbrUser
This parameter is sent by the initiator to register the MC maximum number of user defined circuit switched bearers to be used.
Forwarding information
This parameter is returned by the responder at successful outcome of the service, if the registration request concerned one or a group of Call Forwarding supplementary services.
User error
This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clause 7.6.1:
-	System failure;
-	Data missing;
-	Unexpected data value;
-	Call Barred;
-	Bearer service not provisioned;
-	This error is returned only if not even a subset of the requested bearer service group has been subscribed to;
-	Teleservice not provisioned;
	This error is returned only if not even a subset of the requested teleservice group has been subscribed to;
-	Illegal SS operation;
-	SS error status;
-	SS incompatibility.
Provider error
See clause 7.6.1 for the use of this parameter.
11.2	MAP_ERASE_SS service
11.2.1	Definition
This service is used between the MSC and the VLR and between the VLR and the HLR to erase data related to a supplementary service. The VLR will relay the message to the HLR.
The service is a confirmed service and uses the service primitives shown in table 11.2/1.
11.2.2	Service primitives
Table 11.2/1: MAP_ERASE_SS parameters
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
SS-Code
M
M(=)


Basic service
C
C(=)


Forwarding information


C
C(=)
User error


C
C(=)
Provider error



O

11.2.3	Parameter use
Invoke id
See clause 7.6.1 for the use of this parameter.
SS-Code
This parameter indicates the supplementary service which the mobile subscriber wants to erase.
Basic service
This parameter indicates for which basic service group the supplementary service should be erased. If it is not included, the erasure request applies to all basic services.
Forwarding information
This parameter is returned by the responder at successful outcome of the service, if the erasure request concerned one or a group of Call Forwarding supplementary services.
User error
This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values, defined in clause 7.6.1:
-	System failure;
-	Data Missing;
-	Unexpected data value;
-	Bearer service not provisioned;
	This error is returned only if not even a subset of the requested bearer service group has been subscribed to;
-	Teleservice not provisioned;
	This error is returned only if not even a subset of the requested teleservice group has been subscribed to;
-	Call Barred;
-	Illegal SS operation;
-	SS error status.
Provider error
See clause 7.6.1 for the use of this parameter.
11.3	MAP_ACTIVATE_SS service
11.3.1	Definition
This service is used between the MSC and the VLR and between the VLR and the HLR to activate a supplementary service. The VLR will relay the message to the HLR.
The service is a confirmed service and uses the service primitives shown in table 11.3/1.
11.3.2	Service primitives
Table 11.3/1: MAP_ACTIVATE_SS parameters
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
SS-Code
M
M(=)


Long FTN Supported
C
C(=)


Basic service
C
C(=)


Forwarding information


C
C(=)
Call barring information


C
C(=)
SS-Data


C
C(=)
User error


C
C(=)
Provider error



O

11.3.3	Parameter use
Invoke id
See clause 7.6.1 for the use of this parameter.
SS-Code
This parameter indicates the supplementary service which the mobile subscriber wants to activate.
Basic service
This parameter indicates for which basic service groups the requested supplementary service(s) should be activated. If it is not included, the activation request applies to all basic services.
Forwarding information
This parameter is returned by the responder at successful outcome of the service, if the activation request concerned Call Forwarding.
Long FTN Supported
This parameter indicates that the mobile station supports Long Forwarded-to Numbers.
Call barring information
This parameter is returned by the responder at successful outcome of the service, if the activation request concerned Call Barring.
SS-Data
This parameter is returned by the responder at successful outcome of the service, if the activation request concerned for example Call Waiting.
User error
This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values, defined in clause 7.6.1:
-	System failure;
-	Data Missing;
-	Unexpected data value;
-	Bearer service not provisioned;
-	This error is returned only if not even a subset of the requested bearer service group has been subscribed to.
-	Teleservice not provisioned;
-	This error is returned only if not even a subset of the requested teleservice group has been subscribed to.
-	Call Barred;
-	Illegal SS operation;
-	SS error status;
-	SS subscription violation;
-	SS incompatibility;
-	Negative PW check;
-	Number Of PW Attempts Violation.
Provider error
See clause 7.6.1 for the use of this parameter.
11.4	MAP_DEACTIVATE_SS service
11.4.1	Definitions
This service is used between the MSC and the VLR and between the VLR and the HLR to deactivate a supplementary service. The VLR will relay the message to the HLR.
The service is a confirmed service and uses the service primitives shown in table 11.4/1.
11.4.2	Service primitives
Table 11.4/1: MAP_DEACTIVATE_SS parameters
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
SS-Code
M
M(=)


Basic service
C
C(=)


Forwarding information


C
C(=)
Call barring information


C
C(=)
SS-Data


C
C(=)
User error


C
C(=)
Provider error



O

11.4.3	Parameter use
Invoke id
See clause 7.6.1 for the use of this parameter.
SS-Code
This parameter indicates the supplementary service which the mobile subscriber wants to deactivate.
Basic service
This parameter indicates for which basic service group the requested supplementary service(s) should be deactivated. If it is not included the deactivation request applies to all basic services.
Forwarding information
This parameter is returned by the responder at successful outcome of the service, if the deactivation request concerned one or a group of Call Forwarding supplementary services.
Call barring information
This parameter is returned by the responder at successful outcome of the service, if the activation request concerned one or a group of Call Barring supplementary services.
SS-Data
This parameter is returned by the responder at successful outcome of the service, for example if the deactivation request concerned the Call Waiting supplementary service.
User error
This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values, defined in clause 7.6.1:
-	System failure;
-	Data Missing;
-	Unexpected data value;
-	Bearer service not provisioned;
	This error is returned only if not even a subset of the requested bearer service group has been subscribed to;
-	Teleservice not provisioned;
	This error is returned only if not even a subset of the requested teleservice group has been subscribed to;
-	Call Barred;
-	Illegal SS operation;
-	SS error status;
-	SS subscription violation;
-	Negative PW check;
-	Number Of PW Attempts Violation.
Provider error
See clause 7.6.1 for the use of this parameter.
11.5	MAP_INTERROGATE_SS service
11.5.1	Definitions
This service is used between the MSC and the VLR and between the VLR and the HLR to retrieve information related to a supplementary service. The VLR will relay the message to the HLR if necessary.
The service is a confirmed service and consists of four service primitives.
11.5.2	Service primitives
The service primitives are shown in table 11.5/1.
Table 11.5/1: MAP_INTERROGATE_SS parameters
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
SS-Code
M
M(=)


Basic service
C
C(=)


Long FTN Supported
C
C(=)


SS-Status


C
C(=)
Basic service Group LIST


C
C(=)
Forwarding feature LIST


C
C(=)
CLI restriction Info


C
C(=)
EMLPP Info


C
C(=)
MC Information


C
C(=)
CCBS Feature LIST


C
C(=)
User error


C
C(=)
Provider error



O

11.5.3	Parameter use
For additional information on parameter use refer to the GSM 04.8x and 04.9x-series of technical specifications.
Invoke id
See clause 7.6.1 for the use of this parameter.
SS-Code
The mobile subscriber can only interrogate a single supplementary service per service request.
Basic service
This parameter indicates for which basic service group the given supplementary service is interrogated. If it is not included, the interrogation request applies to all basic services.
SS-Status
This parameter is included by the responder if:
-	the interrogated supplementary service can only be subscribed for all applicable basic services simultaneously; or
-	the interrogated supplementary service is not active for any of the interrogated basic services, or
-	the interrogation was for the CCBS supplementary service and no CCBS request is active or the service is not provisioned.
Basic service group LIST
This parameter LIST is used to include one or a series of basic service groups for which the interrogated supplementary service is active. If the interrogated supplementary service is not active for any of the interrogated (and provisioned) basic service groups, the SS-Status parameter is returned.
Long FTN Supported
This parameter indicates that the mobile station supports Long Forwarded-to Numbers.
Forwarding feature LIST
The forwarding feature parameter is described in clause 7.6.4. A list of one or more forwarding features is returned by the responder when the interrogation request applied to Call Forwarding supplementary service.
If no basic service code parameter is provided within this sequence, the forwarding feature parameter applies to all provisioned basic services.
CLI restriction Info
The CLI-RestrictionInfo parameter is returned by the responder when the interrogation request applies to the CLIR supplementary service.
EMLPP Info
The eMLPP info (maximum entitled priority and default priority) is returned by the responder if the interrogation request applies to the eMLPP supplementary service.
MC Information
The MC information (NbrSB, NbrUser and NbrSN) is returned by the responder if the interrogation request applies to the MC supplementary service. For a definition of these 3 components, refer to 3GPP TS 23.135 and 3GPP TS 24.135.
CCBS Feature LIST
The CCBS feature parameter is described in clause 7.6. A list of one or more CCBS features is returned by the responder when the interrogation request applied to the CCBS supplementary service. See 3GPP TS 23.093 [107] for the conditions for the presence of the parameters included in the CCBS feature.
User error
This error is sent by the responder upon unsuccessful outcome of the interrogation service, and then takes one of the following values, defined in clause 7.6.1:
-	System failure;
-	Data Missing;
-	Unexpected data value;
-	Bearer Service not provisioned;
	This error is returned only if not even a subset of the interrogated bearer services are provided;
-	Teleservice not provisioned;
	This error is returned only if not even a subset of the interrogated teleservices are provided;
-	Call Barred;
-	Illegal SS operation;
-	SS not available.
Provider error
See clause 7.6.1 for the use of this parameter.
11.6	Void
11.7	MAP_REGISTER_PASSWORD service
11.7.1	Definitions
This service is used between the MSC and the VLR and between the VLR and the HLR if the mobile subscriber requests to register a new password. The VLR will relay the message to the HLR.
The service is a confirmed service and consists of four service primitives.
11.7.2	Service primitives
The service primitives are shown in table 11.7/1.
Table 11.7/1: MAP_REGISTER_PASSWORD parameters
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
SS-Code
M
M(=)


New password


C
C(=)
User error


C
C(=)
Provider error



O

11.7.3	Parameter use
Invoke id
See clause 7.6.1 for the use of this parameter.
SS-Code
This parameter indicates for which supplementary service(s) the password should be registered.
New Password
See clause 7.6.4 for the use of this parameter.
User error
This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values, defined in clause 7.6.1:
-	System failure;
-	Data Missing;
-	Unexpected data value;
-	Call Barred;
-	SS subscription violation;
-	Password registration failure;
-	Negative PW check;
-	Number Of PW Attempts Violation.
Provider error
See clause 7.6.1 for the use of this parameter.
11.8	MAP_GET_PASSWORD service
11.8.1	Definitions
This service is used between the HLR and the VLR and between the VLR and the MSC when the HLR receives a request from the mobile subscriber for an operation on a supplementary service which requires a password from the subscriber. The VLR will relay the message to the MSC.
The service is a confirmed service and uses the service primitives shown in table 11.8/1.
11.8.2	Service primitives
Table 11.8/1: MAP_GET_PASSWORD parameters
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
Linked id
C
C(=)


Guidance info
M
M(=)


Current password


M
M(=)
Provider error



O

11.8.3	Parameter use
Invoke id
See clause 7.6.1 for the use of this parameter.
Linked Id
See clause 7.6.1 for the use of this parameter. If the MAP_GET_PASSWORD service is used in conjunction with the MAP_REGISTER_PASSWORD service, this parameter must be present; otherwise it must be absent.
Guidance info
See clause 7.6.4 for the use of this parameter.
Current password
See clause 7.6.4 for the use of this parameter.
Provider error
See clause 7.6.1 for the use of this parameter.
11.9	MAP_PROCESS_UNSTRUCTURED_SS_REQUEST service
11.9.1	Definitions
This service is used between the MSC and the VLR, between the VLR and the HLR, between the HLR and gsmSCF and between the HLR and HLR to relay information in order to allow unstructured supplementary service operation.
The MAP_PROCESS_UNSTRUCTURED_SS_REQUEST service is a confirmed service using the primitives from table 11.9/1.
11.9.2	Service primitives
Table 11.9/1: MAP_PROCESS_UNSTRUCTURED_SS_REQUEST parameters
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
USSD Data Coding Scheme
M
M(=)
C
C(=)
USSD String
M
M(=)
C
C(=)
MSISDN
C
C(=)


User error


C
C(=)
Provider error



O

11.9.3	Parameter use
Invoke id
See clause 7.6.1 for the use of this parameter.
USSD Data Coding Scheme
See clause 7.6.4 for the use of this parameter. The presence of the parameter in the response is dependent on the unstructured supplementary service application. If this parameter is present, then the USSD String parameter has to be present.
USSD String
See clause 7.6.1 for the use of this parameter. The presence of the parameter in the response is dependent on the unstructured supplementary service application. If this parameter is present, then the USSD Data Coding Scheme parameter has to be present.
MSISDN
The subscriber's basic MSISDN.
See definition in clause 7.6.2. For Follow Me when the service request is sent from the HLR of the A subscriber, the parameter shall contain the MSISDN of the A subscriber, see 3GPP TS 23.094 [129]. For other purposes the MSISDN may be included as an operator option, e.g. to allow addressing the subscriber's data in the gsmSCF with the MSISDN.
User error
This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clause 7.6.1:
-	System failure;
-	Data missing;
-	Unexpected data value;
	This error is returned by the responder if it is not able to deal with the contents of the USSD string.
-	Call Barred;
-	Unknown Alphabet.
Provider error
See clause 7.6.1 for the use of this parameter.
11.10	MAP_UNSTRUCTURED_SS_REQUEST service
11.10.1	Definitions
This service is used between the gsmSCF and the HLR, the HLR and the VLR and between the VLR and the MSC when the invoking entity requires information from the mobile user, in connection with unstructured supplementary service handling.
The MAP_UNSTRUCTURED_SS_REQUEST service is a confirmed service using the primitives from table 11.10/1.
11.10.2	Service primitives
Table 11.10/1: MAP_UNSTRUCTURED_SS_REQUEST parameters
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
USSD Data Coding Scheme
M
M(=)
C
C(=)
USSD String
M
M(=)
C
C(=)
Alerting Pattern
C
C(=)


User error


C
C(=)
Provider error



O

11.10.3	Parameter use
Invoke id
See clause 7.6.1 for the use of this parameter.
USSD Data Coding Scheme
See clause 7.6.4 for the use of this parameter. The presence of the parameter in the response is dependent on the mobile user's MMI input. If this parameter is present, then the USSD String parameter has to be present.
USSD String
See clause 7.6.1 for the use of this parameter. The presence of the parameter in the response is dependent on the mobile user's MMI input. If this parameter is present, then the USSD Data Coding Scheme parameter has to be present.
Alerting Pattern
See clause 7.6.3 for the use of this parameter.
User error
This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clause 7.6.1:
-	System failure;
-	Data missing;
-	Unexpected data value;
	This error is returned by the responder if it is not able to deal with the contents of the USSD string;
-	Absent Subscriber;
-	Illegal Subscriber;
	This error indicates that delivery of the unstructured supplementary service data failed because the MS failed authentication;
-	Illegal Equipment;
-	USSD Busy;
-	Unknown Alphabet.
Provider error
See clause 7.6.1 for the use of this parameter.
11.11	MAP_UNSTRUCTURED_SS_NOTIFY service
11.11.1	Definitions
This service is used between the gsmSCF and the HLR, the HLR and the VLR and between the VLR and the MSC when the invoking entity requires a notification to be sent to the mobile user, in connection with unstructured supplementary services handling.
The MAP_UNSTRUCTURED_SS_NOTIFY service is a confirmed service using the primitives from table 11.11/1.
11.11.2	Service primitives
Table 11.11/1: MAP_UNSTRUCTURED_SS_NOTIFY parameters
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
USSD Data Coding Scheme
M
M(=)


USSD String
M
M(=)


Alerting Pattern
C
C(=)


User error


C
C(=)
Provider error



O

11.11.3	Parameter use
Invoke id
See clause 7.6.1 for the use of this parameter.
USSD Data Coding Scheme:
See clause 7.6.4 for the use of this parameter.
USSD String:
See clause 7.6.1 for the use of this parameter.
Alerting Pattern 
See clause 7.6.3 for the use of this parameter.
User error
This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clause 7.6.1:
-	System failure;
-	Data missing;
-	Unexpected data value;
	This error is returned by the responder if it is not able to deal with the contents of the USSD string.
-	Absent Subscriber;
-	Illegal Subscriber;
	This error indicates that delivery of the unstructured supplementary service data failed because the MS failed authentication.
-	Illegal Equipment;
-	USSD Busy;
-	Unknown Alphabet.
Provider error
See clause 7.6.1 for the use of this parameter.
11.12	MAP_SS_INVOCATION_NOTIFY
11.12.1	Definition
This service is used between the MSC and the gsmSCF when the subscriber invokes one of the following supplementary services; Call Deflection (CD), Explicit Call Transfer (ECT) or Multi Party (MPTY). 
This service is used between the HLR and the gsmSCF when the subscriber invokes the CCBS supplementary service.
11.12.2	Service primitives
The service primitives are shown in table 11.12/1.
Table 11.12/1: SS_INVOCATION_NOTIFY parameters
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
MSISDN
M
M(=)


IMSI
M
M(=)


SS- event
M
M(=)


SS- event data
C
C(=)


B-subscriber Number
C
C(=)


CCBS Request State
C
C(=)


User error


C
C(=)
Provider error



O

11.12.3	Parameter use
All parameters are described in clause 7.6. The use of these parameters and the requirements for their presence are specified in 3GPP TS 23.078.
User error
This parameter is sent by the responder when an error is detected and if present, takes one of the following values:
-	Data Missing;
-	Unexpected Data Value;
-	Unknown Subscriber.
Provider error
This is defined in clause 7.6.1.
11.13	MAP_REGISTER_CC_ENTRY service
11.13.1	Definition
This service is used between the MSC and the VLR and between the VLR and the HLR to register data for a requested call completion supplementary service. The VLR will relay the message to the HLR.
The service is a confirmed service and uses the service primitives shown in table 11.13/1.
11.13.2	Service primitives
Table 11.13/1: MAP_REGISTER_CC_ENTRY parameters
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
SS Code
M
M(=)


CCBS Feature
C
C(=)
C
C(=)
Translated B number
C
C(=)


Service Indicator
C
C(=)


Call Info
C
C(=)


Network Signal Info
C
C(=)


User error


C
C(=)
Provider error



O

11.13.3	Parameter use
See clause 7.6 for a definition of the parameters used, in addition to the following.
SS-Code
This parameter indicates the call completion supplementary service for which the mobile subscriber wants to register an entry.
CCBS Feature
See 3GPP TS 23.093 [107] for the conditions for the presence of the parameters included in the CCBS feature.
Translated B Number
See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence.
Service Indicator
This parameter corresponds to the parameters 'Presentation Indicator' and 'CAMEL Invoked' in 3GPP TS 23.093 [107]. It indicates which services have been invoked for the original call (e.g. CLIR, CAMEL). See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence.
Call Info
See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence.
Network Signal Info
See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence.
User error
This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values, defined in clause 7.6.1:
-	System failure;
-	Data missing;
-	Unexpected data value;
-	Call Barred;
-	Illegal SS operation;
-	SS error status;
-	SS incompatibility.
-	Short Term Denial;
-	Long Term Denial;
-	Facility Not Supported;
NOTE:	This error is reserved for future use.
Private Extensions shall not be sent with these user errors for this operation.
Provider error
See clause 7.6.1 for the use of this parameter.
11.14	MAP_ERASE_CC_ENTRY service
11.14.1	Definition
This service is used between the MSC and the VLR and between the VLR and the HLR to erase data related to a call completion supplementary service. The VLR will relay the message to the HLR.
The service is a confirmed service and uses the service primitives shown in table 11.14/1.
11.14.2	Service primitives
Table 11.14/1: MAP_ERASE_CC_ENTRY parameters
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
SS-Code
M
M(=)
C(=)
C(=)
CCBS Index
C
C(=)


SS-Status


C
C(=)
User error


C
C(=)
Provider error



O

11.14.3	Parameter use
See clause 7.6 for a definition of the parameters used, in addition to the following.
SS-Code
This parameter indicates the call completion supplementary service for which the mobile subscriber wants to erase an entry/entries.
CCBS Index
See 3GPP TS 23.093 [107] for the use of this parameter and the condition for its presence.
SS-Status
Depending on the outcome of the service request this parameter may indicate either provisioned and active or not provisioned.
User error
This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values, defined in clause 7.6.1:
-	System failure;
-	Data Missing;
-	Unexpected data value;
-	Call Barred;
-	Illegal SS operation;
-	SS error status.
Private Extensions shall not be sent with these user errors for this operation.
Provider error
See clause 7.6.1 for the use of this parameter.
12	Short message service management services
12.1	MAP-SEND-ROUTING-INFO-FOR-SM service
12.1.1	Definition
This service is used between the gateway MSC and the HLR to retrieve the routing information needed for routing the short message to the servicing MSC or MME but not both, or SGSN, or (for T4-device triggering via the IMS) IP-SM-GW, or SMSF. This service is also used between the gateway MSC and SMS Router, and SMS Router and HLR in order to enforce routing of the SM delivery via the HPLMN of the receiving MS. This service is also used between HLR and IP-SM-GW, and between IP-SM-GW and HLR  in order to allow MT-SM delivery (other than T4-device triggering) via the IMS.
This service is also used with an IWF interfacing the S6c interface.
The MAP-SEND-ROUTING-INFO-FOR-SM is a confirmed service using the primitives from table 12.1/1.
12.1.2	Service primitives
Table 12.1/1: MAP-SEND-ROUTING-INFO-FOR-SM
Parameter name
Request
Indication
Response
Confirm

Invoke Id
M
M(=)
M(=)
M(=)

MSISDN
M
M(=)



SM-RP-PRI
M
M(=)



Service Centre Address
M
M(=)



SM-RP-MTI
C
C(=)



SM-RP-SMEA
C
C(=)



GPRS Support Indicator
C
C(=)



SM-Delivery Not Intended
U
C(=)



IP-SM-GW Guidance Support Indicator
U
C(=)



Single Attempt Delivery
C
C(=)



IMSI
C
C(=)
C
C(=)

Correlation ID
C
C(=)



T4 Trigger Indicator
C
C(=)




SMSF Support Indicator
C
C(=)


Network Node Number


C
C(=)

Network Node Diameter Address


C
C(=)

LMSI


C
C(=)

GPRS Node Indicator


C
C(=)

Additional Number


C
C(=)

Additional Network Node Diameter Address


C
C(=)

IP-SM-GW Guidance


U
C(=)

Third Number


C
C(=)

Third Network Node Diameter Address


C
C(=)

IMS Node Indicator


C
C(=)


SMSF 3GPP Number


C
C(=)

SMSF 3GPP Diameter Address


C
C(=)

SMSF Non-3GPP Number


C
C(=)

SMSF Non-3GPP Diameter Address


C
C(=)

SMSF 3GPP Address Indicator


C
C(=)

SMSF Non 3GPP Address Indicator


C
C(=)
User error


C
C(=)

Provider error



O


12.1.3	Parameter use
Invoke id
See definition in clause 7.6.1.
MSISDN
See definition in clause 7.6.2. 
When SEND-ROUTING-INFO-FOR-SM is sent by the SMS-GMSC to the HLR following an T4 Submit Trigger (see 3GPP TS 23.682 [148]), MSISDN may not be available. In this case the UE shall be identified by the IMSI and the MSISDN shall take the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [17]). 
When SEND-ROUTING-INFO-FOR-SM is sent by the SMS-GMSC to the HLR in a retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [134]), MSISDN may not be available. In this case the UE shall be identified by a Correlation ID (SIP-URI-B) and the MSISDN shall take the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [17]).
SM-RP-PRI
See definition in clause 7.6.8.
Service Centre Address
See definition in clause 7.6.2.
SM-RP-MTI
See definition in clause 7.6.8. This parameter shall be present when the feature « SM filtering by the HPLMN » is supported by the SMS-GMSC and when the equivalent parameter is received from the short message service relay sub-layer protocol.
SM-RP-SMEA
See definition in clause 7.6.8. This parameter shall be present when the feature « SM filtering by the HPLMN » is supported by the SMS-GMSC and when the equivalent parameter is received from the short message service relay sub-layer protocol.
GPRS Support Indicator
See definition in clause 7.6.8. The presence of this parameter is mandatory if the SMS-GMSC supports receiving of the two numbers from the HLR.
SM-Delivery Not Intended
This parameter indicates by its presence that delivery of a short message is not intended. It further indicates whether only IMSI or only MCC+MNC are requested.
This parameter may be set by entities that request the service without intending to deliver a short message (e.g. MMS Relay/Server), and shall be evaluated by the SMS Router and may be evaluated by the HLR.
IP-SM-GW Guidance Support Indicator
This parameter indicates whether or not the SMS-GMSC is prepared to receive IP-SM-GW Guidance in the response.
Single Attempt Delivery
This parameter indicates the short message is only valid for delivering once, and the HLR/HSS does not need to add the received SC address into MWD list in the case there is no serving node available to provide SMS to the user.
IMSI
See definition in clause 7.6.2. 
In Request and Indication:
IMSI shall be present if MSISDN is not available. When SEND-ROUTING-INFO-FOR-SM is sent by the SMS-GMSC to the HLR in a retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [134]), IMSI may not be available. In this case the IMSI parameter shall be populated with the HLR-ID value.
In Response and Confirm: If enforcement of routing an SM via the HPLMN of the receiving MS is deployed, this parameter contains an MT Correlation ID instead of an IMSI when the service is used between SMS-GMSC and SMS Router (see 3GPP TS 23.040 [26] for more information). If the "SM-Delivery Not Intended" parameter was present in the Indication with a value of "only MCC+MNC requested", then this parameter may contain MCC+MNC+dummy MSIN.
The presence of this parameter is mandatory in a successful case.
T4 Trigger Indicator
This indicator indicates by its presence that the request is sent in the context of T4 device triggering (see 3GPP TS 23.682 [148]). When received, the HLR may return up to three serving node numbers and shall not forward the request to an IP-SM-GW or SMS Router.
SMSF Support Indicator
It indicates that the requesting node is capable of receiving ISDN numbers and/or Diameter addresses of the SMSF as target of MT-SMS.
Correlation ID
The Correlation ID parameter contains the SIP-URI-B identifying the (MSISDN-less) destination user. SIP-URI-A and HLR-ID shall be absent from this parameter.
The Correlation ID indicates by its presence that the request is sent in the context of MSISDN-less SMS delivery in IMS (see 3GPP TS 23.204 [134]). When received, the HLR shall return the IP-SM-GW number and shall not forward the request to an IP-SM-GW.
Network Node Number
See definition in clause 7.6.2. This parameter is provided in a successful response. If the "SM-Delivery Not Intended" parameter was present in the Indication a dummy address may be provided. See clause 12.1.4.
Network Node Diameter Address 
See definition in clause 7.6.2. See clause 12.1.4. 
LMSI
See definition in clause 7.6.2. It is an operator option to provide this parameter from the VLR; it is mandatory for the HLR to include the LMSI in a successful response, if the VLR has used the LMSI.
GPRS Node Indicator
See definition in clause 7.6.8. 
Outside the context of T4 device triggering:  The presence of this parameter is mandatory if only the SGSN number is sent in the Network Node Number (i.e. if the value within Network Node Number is to be considered as SGSN-Number and Additional Number is absent). 
Within the context of T4 device triggering: The presence of this parameter is mandatory if the value within Network Node Number is to be considered as SGSN-Number and Third Number is absent.
Additional Number
See definition in clause 7.6.2.  See clause 12.1.4.
Additional Network Node Diameter Address 
See definition in clause 7.6.2. See clause 12.1.4. 
IP-SM-GW Guidance
This parameter contains the recommended and the minimum timer values for supervision of MT-Forward-Short-Message response. Shall be absent if the IP-SM-GW-Guidance Support Indicator in the request is absent. This parameter is only used by IP-SM-GW and SMS-GMSC.
Third Number
See definition in clause 7.6.2.  See clause 12.1.4.
Third Network Node Diameter Address 
See definition in clause 7.6.2. See clause 12.1.4 
IMS Node Indicator
See definition in clause 7.6.8. 
Outside the context of T4 device triggering: The parameter is not applicable and shall be absent.
Within the context of T4 device triggering: The presence of this parameter is mandatory if the value within Network Node Number is to be considered as IP-SM-GW-Number and Third Number is absent.
SMSF 3GPP Number
This parameter contains the ISDN number of the SMSF target node for MT-SMS over 3GPP access.
SMSF 3GPP Diameter Address
This parameter contains the Diameter Name and Realm of the SMSF target node for MT-SMS over 3GPP access.
SMSF Non-3GPP Number
This parameter contains the ISDN number of the SMSF target node for MT-SMS over non-3GPP access.
SMSF Non-3GPP Diameter Address
This parameter contains the Diameter Name and Realm of the SMSF target node for MT-SMS over non-3GPP access.
SMSF 3GPP Address Indicator
It indicates that the parameter Network Node Number (and Network Node Diameter Address, if present) contains the address of an SMSF for 3GPP access.
SMSF Non-3GPP Address Indicator
It indicates that the parameter Network Node Number (and Network Node Diameter Address, if present) contains the address of an SMSF for non-3GPP access.
User error
The following errors defined in clause 7.6.1 may be used, depending on the nature of the fault:
-	Unknown subscriber;
-	Call Barred;
-	Teleservice Not Provisioned;
-	Absent Subscriber_SM;
-	Facility Not Supported;
-	System failure;
-	Unexpected Data Value;
-	Data missing.
Provider error
For definition of provider errors see clause 7.6.1.
12.1.4	Identities of MT-SMS Target Nodes
In a successful MAP-Send-Routing-Info-For-SM response at least one MT-SMS Target Node identity or an SMS Router identity shall be present and this shall be an E.164 number within the Network Node Number parameter. 
In addition, optionally a second Target Node identity or an SMS Router identity may be present as E.164 number within the Additional Number Parameter. 
In T4 device trigger scenarios in addition to a second Target Node identity, a third Target Node Identity may be present as E.164 number within the Third Number parameter.
In addition to the E.164 identity of an MT-SMS Target Node or an SMSRouter, the presence of the Diameter Name/Realm of the corresponding target node or SMS Router follows the hereafter rules:
-	If Network Node Number contains an MME number for SMS, Network Node Diameter Address shall be present and contain the Diameter address of the MME.
-	If Network Node Number contains an MSC number, Network Node Diameter Address may be present and shall contain the Diameter address of the MME.
-	If Network Node Number contains an SGSN number, Network Node Diameter Address shall be present only if the HSS has received the information that SGSN supports the Gdd interface.
-	If Network Node Number contains an SMS Router number, Network Node Diameter Address may be present and shall contain the SMS Router Diameter address.
-	If Network Node Number contains an IP-SM-GW number, Network Node Diameter Address may be present and shall contain the IP-SM-GW Diameter address.
Similar for Additional Number - Additional Network Node Diameter Address;
Similar for Third Number - Third Network Node Diameter Address. 
In scenarios supporting interworking with 5G System, an E.164 Number and a Diameter Address of the SMSF may be present, for both 3GPP and non-3GPP accesses. In addition:
-	If Network Node Number contains an SMSF 3GPP number, Network Node Diameter Address may be present and shall contain the SMSF 3GPP Diameter address.
-	If Network Node Number contains an SMSF Non-3GPP number, Network Node Diameter Address may be present and shall contain the SMSF Non-3GPP Diameter address.

12.2	MAP-MO-FORWARD-SHORT-MESSAGE service
12.2.1	Definition
This service is used between the serving MSC or the SGSN or IP-SM-GW and the SMS Interworking MSC to forward mobile originated short messages.
The MAP-MO-FORWARD-SHORT-MESSAGE service is a confirmed service using the service primitives given in table 12.2/1.
12.2.2	Service primitives
Table 12.2/1: MAP-MO-FORWARD-SHORT-MESSAGE
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
SM RP DA
M
M(=)


SM RP OA
M
M(=)


SM RP UI
M
M(=)
C
C(=)
IMSI
C
C(=)


Correlation ID
C
C(=)


SM Delivery Outcome
C
C(=)


User error


C
C(=)
Provider error



O

12.2.3	Parameter use
Invoke id
See definition in clause 7.6.1.
SM RP DA
See definition in clause 7.6.8.
In the mobile originated SM transfer this parameter contains the Service Centre address received from the mobile station.
SM RP OA
See definition in clause 7.6.8.
The MSISDN received from the VLR or from the SGSN is inserted in this parameter in the mobile originated SM transfer.
A Dummy MSISDN value is used for MSISDN-less SMS in IMS. In this case the originating user is identified by SIP-URI-A (see Correlation ID).
SM RP UI
See definition in clause 7.6.8. The short message transfer protocol data unit received from the Service Centre is inserted in this parameter.
IMSI
See definition in clause 7.6.2.1. The IMSI of the originating subscriber shall be inserted in this parameter in the mobile originated SM transfer.
Correlation ID
The Correlation ID is composed of an HLR-Id identifying the destination user's HLR, a SIP-URI-B identifying the MSISDN-less destination user, and a SIP-URI-A identifying the originating user. 
The Correlation ID indicates by its presence that the request is sent in the context of MSISDN-less SMS delivery in IMS (see 3GPP TS 23.204 [134]), and that a Report-SM-Delivery status needs to be sent to the HLR to add the SC address to the MWD.
SM Delivery Outcome
See definition in clause 7.6.8. This parameter indicates the status of the mobile terminated SM delivery.
Shall be present if Correlation ID is present and shall take one of the unsuccessful outcome values.
User error
The following errors defined in clause 7.6.1 may be used, depending on the nature of the fault:
-	Facility Not Supported;
-	System Failure;
-	SM Delivery Failure;
-	The reason of the SM Delivery Failure can be one of the following in the mobile originated SM:
-	unknown Service Centre address;
-	Service Centre congestion;
-	invalid Short Message Entity address;
-	subscriber not Service Centre subscriber;
-	protocol error.
-	Unexpected Data Value
Provider error
For definition of provider errors see clause 7.6.1.
12.3	MAP-REPORT-SM-DELIVERY-STATUS service
12.3.1	Definition
This service is used between the gateway MSC and the HLR or the external Short Message Gateway (IP-SM-GW) and the HLR. The MAP-REPORT-SM-DELIVERY-STATUS service is used to set the Message Waiting Data into the HLR or to inform the HLR of successful SM transfer after polling. This service is invoked by the gateway MSC or the external Short Message Gateway (IP-SM-GW).
The MAP-REPORT-SM-DELIVERY-STATUS service is a confirmed service using the service primitives given in table 12.3/1.
12.3.2	Service primitives
Table 12.3/1: MAP-REPORT-SM-DELIVERY-STATUS

Parameter name
Request
Indication
Response
Confirm

Invoke Id
M
M(=)
M(=)
M(=)

MSISDN
M
M(=)



IMSI
C
C(=)



Service Centre Address
M
M(=)



SM Delivery Outcome
M
M(=)



Absent Subscriber Diagnostic SM
C
C(=)



GPRS Support Indicator
C
C(=)



Delivery Outcome Indicator
C
C(=)



Additional SM Delivery Outcome
C
C(=)



Additional Absent Subscriber Diagnostic SM
C
C(=)



IP-SM-GW-Indicator
C
C(=)



IP-SM-GW SM Delivery Outcome
C
C(=)



IP-SM-GW Absent Subscriber Diagnostic SM
C
C(=)



Single Attempt Delivery
C
C(=)


Correlation ID
C
C(=)



SMSF 3GPP Delivery Outcome Indicator
C
C(=)



SMSF 3GPP SM Delivery Outcome
C
C(=)



SMSF 3GPP Absent Subscriber Diagnostic SM
C
C(=)



SMSF non-3GPP Delivery Outcome Indicator
C
C(=)



SMSF non-3GPP SM Delivery Outcome
C
C(=)



SMSF non-3GPP Absent Subscriber Diagnostic SM
C
C(=)




MSIsdn-Alert


C
C(=)

User error


C
C(=)

Provider error



O

12.3.3	Parameter use
Invoke id
See definition in clause 7.6.1.
MSISDN
See definition in clause 7.6.2. 
When REPORT-SM-DELIVERY-STATUS is sent by the SMS-GMSC to the HLR following an T4 Submit Trigger (see 3GPP TS 23.682 [148]), MSISDN may not be available. In this case the UE shall be identified by the IMSI and the MSISDN shall take the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [17]). 
When REPORT-SM-DELIVERY-STATUS is sent by the SMS-GMSC to the HLR in a retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [134]), MSISDN may not be available. In this case the UE shall be identified by a Correlation ID (SIP-URI-B) and the MSISDN shall take the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [17]).
IMSI
See definition in clause 7.6.2. When REPORT-SM-DELIVERY-STATUS is sent by the SMS-GMSC to the HLR in a retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [134]), IMSI may not be available. In this case the IMSI parameter shall be populated with an HLR-ID).
Service Centre Address
See definition in clause 7.6.2.
SM Delivery Outcome
See definition in clause 7.6.8. This parameter indicates the status of the mobile terminated SM delivery.
Absent Subscriber Diagnostic SM
See definition in clause 7.6.8.
GPRS Support Indicator
See definition in clause 7.6.8. The presence of this parameter is mandatory if the SMS-GMSC supports handling of two delivery outcomes.
Delivery Outcome Indicator
See definition in clause 7.6.8.
Additional SM Delivery Outcome
See definition in clause 7.6.8.
Additional Absent Subscriber Diagnostic SM
See definition in clause 7.6.8.
IP-SM-GW Indicator
See definition in clause 7.6.8.
IP-SM-GW SM Delivery Outcome
See definition in clause 7.6.8.
IP-SM-GW Absent Subscriber Diagnostic SM
See definition in clause 7.6.8.
Single Attempt Delivery
This parameter indicates the short message is only valid for delivering once, and the HLR/HSS does not need to add the received SC address into MWD list. It may only be present in the case the delivery of the short message failed due to absent subscriber or MS memory capacity exceeded.
Editor's Note:	Description of the use of this parameter might be needed in 3GPP TS 23.040.
Correlation ID
The Correlation ID parameter contains the SIP-URI-B identifying the (MSISDN-less) destination user. SIP-URI-A and HLR-ID shall be absent from this parameter.
SMSF 3GPP Delivery Outcome Indicator
See definition in clause 7.6.8.
SMSF 3GPP SM Delivery Outcome
See definition in clause 7.6.8.
SMSF 3GPP Absent Subscriber Diagnostic SM
See definition in clause 7.6.8.
SMSF Non-3GPP Delivery Outcome Indicator
See definition in clause 7.6.8.
SMSF Non-3GPP SM Delivery Outcome
See definition in clause 7.6.8.
SMSF Non-3GPP Absent Subscriber Diagnostic SM
See definition in clause 7.6.8.
MSIsdn-Alert
See definition in clause 7.6.2. This parameter shall be present in case of unsuccessful delivery, when the MSISDN received in the operation is different from the stored MSIsdn-Alert; the stored MSIsdn-Alert is the value that is returned to the gateway MSC.
User error
The following errors defined in clause 7.6.1 may be used, depending on the nature of the fault:
-	Unknown Subscriber;
-	Message Waiting List Full;
-	Unexpected Data Value;
-	Data missing.
Provider error
For definition of provider errors see clause 7.6.1.
12.4	MAP-READY-FOR-SM service
12.4.1	Definition
This service is used between the MSC and VLR as well as between the VLR and the HLR. The MSC initiates this service if a subscriber indicates memory available situation. The VLR uses the service to indicate this to the HLR.
The VLR initiates this service if a subscriber, whose message waiting flag is active in the VLR, has radio contact in the MSC.
Also this service is used between the SGSN and the HLR. The SGSN initiates this service if a subscriber indicates memory available situation. The SGSN uses the service to indicate this to the HLR.
Also this service is used between the HSS and the MME via an IWF. The MME initiates this service if a subscriber indicates memory available situation. The MME uses the service to indicate this to the HLR.
The SGSN initiates this service if a subscriber, whose message waiting flag is active in the SGSN, has radio contact in the GPRS. 
The MME initiates this service if a subscriber, whose message waiting flag is active in the MME, has radio contact via LTE.
Also this service is used between the external Short Message Gateway (IP-SM-GW) and the HLR. The IP-SM-GW initiates this service if a subscriber indicates memory available situation. The IP-SM-GW uses the service to indicate this to the HLR.
The IP-SM-GW initiates this service if a subscriber, whose message waiting flag is active in the IP-SM-GW, is reachable in IMS.
The MAP-READY-FOR-SM service is a confirmed service using the primitives from table 12.4/1.
12.4.2	Service primitives
Table 12.4/1: MAP-READY-FOR-SM
Parameter name
Request 
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
IMSI
C
C(=)


TMSI
C
C(=)


Alert Reason
M
M(=)


Alert Reason Indicator
C
C(=)


Additional Alert Reason Indicator
C
C(=)


Maximum UE Availability Time
C
C(=)


User error


C
C(=)
Provider error



O

12.4.3	Parameter use
Invoke id
See definition in clause 7.6.1.
IMSI
See definition in clause 7.6.2. The IMSI is used always between the VLR and the HLR and between the SGSN and the HLR and between the HSS and the IWF. Between the MSC and the VLR the identification can be either IMSI or TMSI.
TMSI
See definition in clause 7.6.2. The identification can be either IMSI or TMSI between MSC and VLR.
Alert Reason
See definition in clause 7.6.8. This parameter indicates if the mobile subscriber is present or the MS has memory available.
Alert Reason Indicator
See definition in clause 7.6.8. This parameter by its presence indicates the message is sent from SGSN, and by its absence indicates the message is sent from VLR or MME via IWF.
Additional Alert Reason Indicator
See definition in clause 7.6.8.
Maximum UE Availability Time
See definition in clause 7.6.8. This information element may be included by the SGSN or MSC when notifying the HLR that the MS is reachable.
User error
The following errors defined in clause 7.6.1 may be used, depending on the nature of the fault:
-	Unknown Subscriber;
-	Facility Not Supported;
-	System Failure;
-	Unexpected Data Value;
-	Data missing.
Provider error
For definition of provider errors see clause 7.6.1.
12.5	MAP-ALERT-SERVICE-CENTRE service
12.5.1	Definition
This service is used between the HLR and the interworking MSC. The HLR initiates this service, if the HLR detects that a subscriber, whose MSISDN is in the Message Waiting Data file, is active or the MS has memory available.
This service is also used between an MME (via an IWF), SGSN or an MSC using Deployment Option 2 (see clause 8.2.4a.1 of 3GPP TS 23.272 [143] and 3GPP TS 23.040 [6]) and the SMS-GMSC (possibly via an SMS Router), to indicate that a MS, for which one or more MT SMS have been requested to be retransmitted at a later time, is now available for MT SMS delivery or has moved under the coverage of another MME, SGSN or MSC. This procedure is used according to the call flows described in clause 10.1 of 3GPP TS 23.040 [26].
The MAP-ALERT-SERVICE-CENTRE service is a confirmed service using the primitives from table 12.5/1.
12.5.2	Service primitives
Table 12.5/1: MAP-ALERT-SERVICE-CENTRE
Parameter name
Request 
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
MSIsdn-Alert
M
M(=)


IMSI
C
C(=)


Correlation ID
C
C(=)


Service Centre Address
M
M(=)


Maximum UE Availability Time
C
C(=)


SMS-GMSC Alert Event
C
C(=)


SMS-GMSC Diameter Address
C
C(=)


New SGSN Number
C
C(=)


New SGSN Diameter Address
C
C(=)


New MME Number
C
C(=)


New MME Diameter Address
C
C(=)


New MSC Number
C
C(=)


User error


C
C(=)
Provider error



O

12.5.3	Parameter use
Invoke id
See definition in clause 7.6.1.
MSIsdn-Alert
See definition in clause 7.6.2. 
When the service is used between the HLR and the SMS-IWMSC, the provided MSISDN shall be the one which is stored in the Message Waiting Data file. If no MSISDN is available, the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [17]) shall be sent and an IMSI or Correlation ID (SIP-URI-B) shall be present. 
When the service is used between an MME (via an IWF), SGSN or MSC and the SMS-GMSC, the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [17]) shall be sent and an IMSI shall be present.
IMSI
When the service is used between the HLR and the SMS-IWMSC, the provided IMSI shall be the identifier which is stored in the Message Waiting Data file if no MSISDN is available in the context of T4 device triggering (see 3GPP TS 23.682 [148]). 
When the service is used between an MME (via an IWF), SGSN or MSC and the SMS-GMSC, this information element shall contain the IMSI in the request sent from the MME (via an IWF), SGSN or MSC, or the User Identifier Alert previously sent in the MT Forward Short Message response, when the request is sent from the SMS Router to the SMS-GMSC.
Correlation ID
When the service is used between the HLR and the SMS-IWMSC, the provided SIP-URI-B within the Correlation ID parameter shall be the identifier which is stored in the Message Waiting Data file if no MSISDN is available in a retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [134]). HLR-ID and SIP-URI-A shall be absent. 
When the service is used between an MME (via an IWF), SGSN or MSC and the SMS-GMSC, this information element shall not be included.
Service Centre Address
See definition in clause 7.6.2. 
When the service is used between the HLR and the SMS-IWMSC, this information element shall contain the E.164 number of the Service Center. 
When the service is used between an MME (via an IWF), SGSN or MSC and the SMS-GMSC, this information element shall contain the E.164 number of the SMS-GMSC (or SMS Router) previously received in the SMS-GMSC Address IE in the MT Forward Short Message Request.
Maximum UE Availability Time
See definition in clause 7.6.8. 
When the service is used between the HLR and the SMS-IWMSC, this information element shall be included, if available. 
When the service is used between an MME (via an IWF), SGSN or MSC and the SMS-GMSC, this information element shall not be included.
SMS-GMSC Alert Event
See definition in clause 7.6.8. 
When the service is used between the HLR and the SMS-IWMSC, this information element shall not be included.
When the service is used between an MME (via an IWF), SGSN or MSC and the SMS-GMSC, this information element shall either indicate that the MS is now available for MT SMS or that the MS has moved under the coverage of another MME, SGSN or MSC.
New SGSN Number
See definition in clause 7.6.8. 
When the service is used between the HLR and the SMS-IWMSC, this information element shall not be included.
When the service is used between an MME (via an IWF) or SGSN and the SMS-GMSC, this information element may be included if the SMS-GMSC Alert Event indicates that the MS has moved under the coverage of another SGSN. When present, it shall contain the E.164 number of the new SGSN serving the MS.
New MME Number
See definition in clause 7.6.8. 
When the service is used between the HLR and the SMS-IWMSC, this information element shall not be included.
When the service is used between an MME (via an IWF) or SGSN and the SMS-GMSC, this information element may be included if the SMS-GMSC Alert Event indicates that the MS has moved under the coverage of another MME. When present, it shall contain the E.164 number of the new MME serving the MS.
New SGSN Diameter Address
See definition in clause 7.6.8. 
When the service is used between the HLR and the SMS-IWMSC, this information element shall not be included.
When the service is used between an MME (via an IWF) or SGSN and the SMS-GMSC, this information element shall be included if available and if the SMS-GMSC Alert Event indicates that the MS has moved under the coverage of another SGSN. When present, it shall contain the Diameter Identity of the new SGSN serving the MS.
New MME Diameter Address
See definition in clause 7.6.8. 
When the service is used between the HLR and the SMS-IWMSC, this information element shall not be included.
When the service is used between an MME (via an IWF) or SGSN and the SMS-GMSC, this information element shall be included if available and if the SMS-GMSC Alert Event indicates that the MS has moved under the coverage of another MME. When present, it shall contain the Diameter Identity of the new MME serving the MS.
SMS-GMSC Diameter Address
See definition in clause 7.6.2.
When the service is used between the HLR and the SMS-IWMSC, this information element shall not be included. 
When the service is used between an MME (via an IWF), SGSN or MSC and the SMS-GMSC, this information element shall contain, if available, the Diameter Identity of the SMS-GMSC (or SMS Router) previously received in the SMS-GMSC Diameter Address IE in the MT Forward Short Message Request. 
New MSC Number
See definition in clause 7.6.8.33. 
When the service is used between the HLR and the SMS-IWMSC, this information element shall not be included.
When the service is used between an MSC and the SMS-GMSC, this information element may be included if the SMS-GMSC Alert Event indicates that the MS has moved under the coverage of another MSC. When present, it shall contain the E.164 number of the new MSC serving the MS.

User error
The following errors defined in clause 7.6.1 may be used, depending on the nature of the fault:
-	System Failure;
-	Unexpected Data Value;
-	Data missing.
Provider error
For definition of provider errors see clause 7.6.1.
12.6	MAP-INFORM-SERVICE-CENTRE service
12.6.1	Definition
This service is used between the HLR and the gateway MSC (transiting an SMS Router, if present) to inform the Service Centre which MSISDN number is stored in the Message Waiting Data file. If the stored MSISDN number is not the same as the one received from the gateway MSC in the MAP-SEND-ROUTING-INFO-FOR-SM service primitive the stored MSISDN number is included in the message.
Additionally the status of MCEF, MNRF, MNRG, MNR5G and MNR5GN3G flags and the inclusion of the particular Service Centre address in the Message Waiting Data list is informed to the gateway MSC when appropriate. 
If the HLR has stored a single MNRR, the value is included in the Absent Subscriber Diagnostic SM parameter.
If the HLR has stored a second MNRR, the value of the MNRR for the MSC is included in the Absent Subscriber Diagnostic SM parameter and the value of the MNRR for the SGSN is included in the Additional Absent Subscriber Diagnostic SM parameter.
The MAP-INFORM-SERVICE-CENTRE service is a non-confirmed service using the primitives from table 12.6/1.
12.6.2	Service primitives
Table 12.6/1: MAP-INFORM-SERVICE-CENTRE
Parameter name
Request
Indication
Invoke Id
M
M(=)
MSIsdn-Alert
C
C(=)
MWD Status
C
C(=)
Absent Subscriber Diagnostic SM
C
C(=)
Additional Absent Subscriber Diagnostic SM
C
C(=)
SMSF 3GPP Absent Subscriber Diagnostic SM
C
C(=)
SMSF Non 3GPP Absent Subscriber Diagnostic SM
C
C(=)

12.6.3	Parameter use
Invoke id
See definition in clause 7.6.1.
MSIsdn-Alert
See definition in clause 7.6.2. This parameter refers to the MSISDN stored in a Message Waiting Data file in the HLR.
MWD Status
See definition in clause 7.6.8. This parameter indicates the status of the MCEF, MNRF, MNRG, MNR5G and MNR5GN3G flags and the status of the particular SC address presence in the Message Waiting Data list.
Absent Subscriber Diagnostic SM
See definition in clause 7.6.8. 
Additional Absent Subscriber Diagnostic SM
See definition in clause 7.6.8.
SMSF 3GPP Absent Subscriber Diagnostic SM
See definition in clause 7.6.8.
SMSF Non 3GPP Absent Subscriber Diagnostic SM
See definition in clause 7.6.8.
12.7	MAP-SEND-INFO-FOR-MT-SMS service
12.7.1	Definition
This service is used between the MSC and the VLR. The service is invoked by the MSC receiving a mobile terminated short message to request subscriber related information from the VLR.
The MAP-SEND-INFO-FOR-MT-SMS service is a confirmed service using the primitives from table 12.7/1.
12.7.2	Service primitives
Table 12.7/1: MAP-SEND-INFO-FOR-MT-SMS
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
SM RP DA
M
M(=)


IMSI
C
C(=)


MSISDN


C
C(=)
User error


C
C(=)
Provider error



O

12.7.3	Parameter use
Invoke id
See definition in clause 7.6.1.
SM RP DA
See definition in clause 7.6.8. This parameter shall contain either an IMSI or an LMSI.
IMSI
See definition in clause 7.6.2. This parameter shall be present if the SM RP DA parameter contains an LMSI; otherwise it shall be absent.
MSISDN
See definition in clause 7.6.2.
User error
The following errors defined in clause 7.6.1 may be used, depending on the nature of the fault:
-	Unknown subscriber;
-	Unidentified Subscriber;
-	Absent subscriber;
-	Unexpected Data Value;
-	Data Missing;
-	Illegal subscriber;
-	Illegal equipment;
-	Subscriber busy for MT SMS;
-	System Failure.
Provider error
For definition of provider errors see clause 7.6.1.
12.8	MAP-SEND-INFO-FOR-MO-SMS service
12.8.1	Definition
This service is used between the MSC and the VLR. The service is invoked by the MSC which has to handle a mobile originated short message request to request the subscriber related information from the VLR.
The MAP-SEND-INFO-FOR-MO-SMS service is a confirmed service using the primitives from table 12.8/1.
12.8.2	Service primitives
Table 12.8/1: MAP-SEND-INFO-FOR-MO-SMS
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
Service Centre Address
M
M(=)


MSISDN


C
C(=)
User error


C
C(=)
Provider error



O

12.8.3	Parameter use
Invoke id
See definition in clause 7.6.1.
Service Centre Address
See definition in clause 7.6.2.
MSISDN
See definition in clause 7.6.2.
User error
The following errors defined in clause 7.6.1 may be used, depending on the nature of the fault:
-	Teleservice Not Provisioned;
-	Call Barred;
-	Unexpected Data Value;
-	Data Missing.
Provider error
For definition of provider errors see clause 7.6.1.
12.9	MAP-MT-FORWARD-SHORT-MESSAGE service
12.9.1	Definition
This service is used between the gateway MSC and the serving MSC or the SGSN (transiting an SMS Router, if present) or the IP-SM-GW to forward mobile terminated short messages.
The MAP-MT-FORWARD-SHORT-MESSAGE service is a confirmed service using the service primitives given in table 12.9/1.
12.9.2	Service primitives
Table 12.9/1: MAP-MT-FORWARD-SHORT-MESSAGE
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
SM RP DA
M
M(=)


SM RP OA
M
M(=)


SM RP UI
M
M(=)
C
C(=)
More Messages To Send
C
C(=)


SM Delivery Timer
C
C(=)


SM Delivery Start Time
C
C(=)


SMS Over IP Only Indicator
C
C(=)


Correlation ID
C
C(=)


Maximum Retransmission Time
C
C(=)


SMS-GMSC Address
C
C(=)


SMS-GMSC Diameter Address
C
C(=)


Requested Retransmission Time


C
C(=)
User Identifier Alert


C
C(=)
User error


C
C(=)
Provider error



O

12.9.3	Parameter use
Invoke id
See definition in clause 7.6.1.
SM RP DA
See definition in clause 7.6.8. This parameter can contain either an IMSI or a LMSI. The use of the LMSI is an operator option. The LMSI can be provided if it is received from the HLR. The IMSI is used if the use of the LMSI is not available.
This parameter is omitted (i.e. is present and takes the value "noSM-RP-DA") in the mobile terminated subsequent SM transfers. 
When a Correlation ID is present, the IMSI parameter within SM RP DA shall be populated with the HLR-ID and the destination user is identified by the SIP-URI-B within the Correlation ID.
SM RP OA
See definition in clause 7.6.8. The Service Centre address received from the originating Service Centre is inserted in this parameter.
This parameter is omitted in the mobile terminated subsequent SM transfers.
SM RP UI
See definition in clause 7.6.8. The short message transfer protocol data unit received from the Service Centre is inserted in this parameter. A short message transfer protocol data unit may also be inserted in this parameter in the message delivery acknowledgement from the MSC or from the SGSN to the Service Centre.
More Messages To Send
See definition in clause 7.6.8. The information from the MMS indication received from the Service Centre is inserted in this parameter. 
SM Delivery Timer
See definition in clause 7.6.8. 
SM Delivery Start Time
See definition in clause 7.6.8.
SMS Over IP Only Indicator
This indicator indicates by its presence that the IP-SM-GW shall try to deliver the short message via IMS without retrying to other domains. It shall be present in messages sent to the IP-SM-GW following a T4-Submit Trigger message (see 3GPP TS 23.682 [148]) but not in messages sent to MSC or SGSN (possibly transiting an SMS-Router).
The indicator also indicates to the IP-SM-GW by its presence that the IMSI within the message is a real IMSI and not a MT-Correlation ID allocated by the IP-SM-GW.
Correlation ID
The Correlation ID parameter contains the SIP-URI-B identifying the (MSISDN-less) destination user and the SIP-URI-A identifying the (MSISDN-less) originating user. HLR-ID shall be absent from this parameter.
Maximum Retransmission Time
See definition in clause 7.6.8.
SMS-GMSC Address
See definition in clause 7.6.8.
This information element shall be present if the Maximum Retransmission Time IE is present in the message. When present, it shall contain the E.164 number of the SMS-GMSC in the request sent by the SMS-GMSC or the E.164 number of the SMS Router in the request sent by the SMS Router. 
SMS-GMSC Diameter Address
See definition in clause 7.6.8.
This information element shall be present if available and if the Maximum Retransmission Time IE is present in the message. When present, it shall contain the Diameter Identity of the SMS-GMSC in the request sent by the SMS-GMSC or the Diameter Identity of the SMS Router in the request sent by the SMS Router. 
Requested Retransmission Time
See definition in clause 7.6.8. This information element may only be present if the MT Forward Short Message Response contains the User error set to Absent Subscriber_SM and if the Maximum Retransmission Time information element is present in the MT Forward Short Message Request. It may be included by an MSC using Deployment Option 2 (see clause 8.2.4a.1 of 3GPP TS 23.272 [143] and 3GPP TS 23.040 [6]) or the SGSN if the UE is using a power saving mechanism (such as extended idle mode DRX) and the UE is currently not reachable. 
The Requested Retransmission Time shall not exceed the Maximum Retransmission Time received from the SMS-GMSC.
User-Identifier-Alert
See definition in clause 7.6.8.
This information element shall be present in the message from the SMS Router to the SMS-GMSC, if the Requested Retransmission Time IE is present in the message. When present, this information shall contain an MT Correlation ID.
User error
The following errors defined in clause 7.6.1 may be used, depending on the nature of the fault:
-	Unidentified subscriber;
-	Absent Subscriber_SM;
-	Subscriber busy for MT SMS;
-	Facility Not Supported;
-	Illegal Subscriber indicates that delivery of the mobile terminated short message failed because the mobile station failed authentication;
-	Illegal equipment indicates that delivery of the mobile terminated short message failed because an IMEI check failed, i.e. the IMEI was blacklisted or not white-listed;
-	System Failure;
-	SM Delivery Failure:
-	The reason of the SM Delivery Failure can be one of the following in the mobile terminated SM:
-	memory capacity exceeded in the mobile equipment;
-	protocol error;
-	mobile equipment does not support the mobile terminated short message service.
-	Unexpected Data Value;
-	Data Missing.
Provider error
For definition of provider errors see clause 7.6.1.
12.10	MAP-MT-FORWARD-SM-FOR-VGCS service
12.10.1	Definition
This service is used between the SMS gateway MSC and the Group Call Anchor MSC to forward mobile terminated short messages into an ongoing voice group call.
The MAP-MT-FORWARD-SM-FOR-VGCS service is a confirmed service using the service primitives given in table 12.10/1.
12.10.2	Service primitives
Table 12.10/1: MAP-MT-FORWARD-SM-VGCS
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
ASCI Call Reference 
M
M(=)


SM RP OA
M
M(=)


SM RP UI
M
M(=)
C
C(=)
Dispatcher List


C
C(=)
Ongoing Call Indicator


C
C(=)
User error


C
C(=)
Provider error



O

12.10.3	Parameter use
Invoke id
See definition in clause 7.6.1.
ASCI Call Reference
Group call reference. This item is used to access the VGCS-GCR within the Anchor_MSC.
SM RP OA
See definition in clause 7.6.8. The Service Centre address received from the originating Service Centre is inserted in this parameter.
SM RP UI
See definition in clause 7.6.8. The short message transfer protocol data unit received from the Service Centre is inserted in this parameter. A short message transfer protocol data unit may also be inserted in this parameter in the message delivery acknowledgement from the MSC to the Service Centre.
Dispatcher List
A list of identities (international E.164 phone numbers) identifying the dispatchers of the VGCS call. It shall be present if received from the GCR; otherwise shall be absent.
Ongoing Call Indicator
Indicates by its presence that the VGCS call is ongoing.
User error
The following errors defined in clause 7.6.1 may be used, depending on the nature of the fault:
-	System Failure;
-	Unexpected Data Value.
Provider error
For definition of provider errors see clause 7.6.1.
13	Network-Requested PDP Context Activation services
13.1	MAP_SEND_ROUTING_INFO_FOR_GPRS service
13.1.1	Definition
This service is used by the GGSN to request GPRS routing information from the HLR.
13.1.2	Service primitives
Table 13.1/1: MAP_SEND_ROUTING_INFO_FOR_GPRS
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
IMSI
M
M(=)


GGSN address
C
C(=)
C
C(=)
GGSN number
M
M(=)


SGSN address


C
C(=)
Mobile Not Reachable Reason


C
C(=)
User error


C
C(=)
Provider error



O

13.1.3	Parameter definition and use
Invoke Id
See definition in clause 7.6.1.
IMSI
See definition in clause 7.6.2.
GGSN address
This parameter shall be present if the protocol-converting GSN is used between the GGSN and the HLR.
GGSN number
See definition in clause 7.6.2.
SGSN address
This parameter shall be present if the outcome of the Send Routing Info For GPRS request to the GPRS application process in the HLR is positive.
Mobile Not Reachable Reason
This parameter shall be present if the outcome of the Send Routing Info For GPRS request to the GPRS application process in the HLR is positive and the MNRG flag in the HLR is set. See definition in clause 7.6.3.51.
User error
This parameter is sent by the responder when an error is detected and if present, takes one of the following values:
-	Absent Subscriber;
-	System Failure;
-	Data Missing;
-	Unexpected Data Value;
-	Unknown Subscriber.
The diagnostic in the Unknown Subscriber may indicate "Imsi Unknown" or "Gprs Subscription Unknown".
-	Call Barred;
	This error will indicate that the received PDP PDUs in the GGSN shall be barred for this MS due to Operator Determined Barring. (The CallBarringCause must be the operatorBarring.)
Provider error
These are defined in clause 7.6.1.
13.2	MAP_FAILURE_REPORT service
13.2.1	Definition
This service is used by the GGSN to inform the HLR that network requested PDP-context activation has failed.
13.2.2	Service primitives
Table 13.2/1: MAP_FAILURE_REPORT
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
IMSI
M
M(=)


GGSN address
C
C(=)
C
C(=)
GGSN number
M
M(=)


User error


C
C(=)
Provider error



O

13.2.3	Parameter definition and use
Invoke Id
See definition in clause 7.6.1.
IMSI
See definition in clause 7.6.2.
GGSN address
This parameter shall be present if the protocol-converting GSN is used between the GGSN and the HLR.
GGSN number
See definition in clause 7.6.2.
User error
This parameter is sent by the responder when an error is detected and if present, takes one of the following values:
-	System Failure;
-	Data Missing;
-	Unexpected Data Value;
-	Unknown Subscriber.
Provider error
These are defined in clause 7.6.1.
13.3	MAP_NOTE_MS_PRESENT_FOR_GPRS service
13.3.1	Definition
This service is used by the HLR to inform the GGSN that the MS is present for GPRS again.
13.3.2	Service primitives
Table 13.3/1: MAP_NOTE_MS_PRESENT_FOR_GPRS
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
IMSI
M
M(=)


GGSN address
C
C(=)


SGSN address
M
M(=)


User error


C
C(=)
Provider error



O

13.3.3	Parameter definition and use
Invoke Id
See definition in clause 7.6.1.
IMSI
See definition in clause 7.6.2.
GGSN address
This parameter shall be present if the protocol-converting GSN is used between the GGSN and the HLR.
SGSN address
See definition in clause 7.6.2.
User error
This parameter is sent by the responder when an error is detected and if present, takes one of the following values:
-	System Failure;
-	Data Missing;
-	Unexpected Data Value;
-	Unknown Subscriber.
Provider error
These are defined in clause 7.6.1.
13A	Location Service Management Services
13A.1	MAP-SEND-ROUTING-INFO-FOR-LCS Service
13A.1.1	Definition
This service is used between the GMLC and the HLR to retrieve the routing information needed for routing a location service request to the servicing VMSC, SGSN, MME or 3GPP AAA server. The MAP-SEND-ROUTING-INFO-FOR-LCS is a confirmed service using the primitives from table 13A.1/1.
13A.1.2	Service Primitives
Table 13A.1/1: MAP-SEND-ROUTING-INFO-FOR-LCS
Parameter name
Request
Indication
Response
Confirm
Invoke Id
M
M(=)
M(=)
M(=)
MLC Number
M
M(=)


MSISDN
C
C(=)
C
C(=)
IMSI
C
C(=)
C
C(=)
LMSI


C
C(=)
Network Node Number


C
C(=)
GPRS Node Indicator


C
C(=)
Additional Number


C
C(=)
Supported LCS Capability Sets


C
C(=)
Additional LCS Capability Sets


C
C(=)
MME Name


C
C(=)
SGSN Name


C
C(=)
SGSN Realm


C
C(=)
AAA Server Name


C
C(=)
V-GMLC Address


U
C(=)
Additional V-GMLC Address


U
C(=)
H-GMLC Address


C
C(=)
PPR Address


U
C(=)
User error


C
C(=)
Provider error



O

13A.1.3	Parameter Use
Invoke id
See definition in clause 7.6.1.
MLC Number
See definition in clause 7.6.2.
MSISDN
See definition in clause 7.6.2. The request shall carry either the IMSI or MSISDN. The response shall carry whichever of these was not included in the request (see 3GPP TS 23.271 for details).
IMSI
See definition in clause 7.6.2.
LMSI
See definition in clause 7.6.2. It is an operator option to provide this parameter from the VLR; it is mandatory for the HLR to include the LMSI in a successful response, if the VLR has used the LMSI.
Network Node Number
See definition in clause 7.6.2. This parameter is provided in a successful response. If the Network Node Number and Additional Number are received in the GMLC, the Network Node Number is used in preference to the Additional Number. If the serving node has no ISDN number, the HLR shall populate the Network Node Number parameter with a dummy ISDN number of "0".
GPRS Node Indicator
See definition in clause 7.6.8. The presence of this parameter is mandatory only if the SGSN number is sent in the Network Node Number.
Additional Number
See definition in clause 7.6.2. This parameter is provided in a successful response. If the Network Node Number and Additional Number are received in the GMLC, the Network Node Number is used in preference to the Additional Number.
Supported LCS Capability Sets
See definition in clause 7.6.11. This parameter indicates the LCS capability of the serving node that is indicated by the Network Node Number. This parameter is provided only if LCS capability sets are available in HLR and Network Node Number is present in this message.
Additional LCS Capability Sets
See definition in clause 7.6.11. This parameter indicates the LCS capability of the serving node that is indicated by the Additional Number. This parameter is provided only if LCS capability sets are available in HLR and Additional Number is present in this message.
MME Name
See definition in clause 7.6.2. This parameter is provided in a successful response when the serving node is an MME.
SGSN Name
See definition in clause 7.6.2. This parameter is provided in a successful response when the serving node is an SGSN and the SGSN has indicated its support for Lgd interface.
SGSN Realm
See definition in clause 7.6.2. This parameter is provided in a successful response when the serving node is an SGSN and the SGSN has indicated its support for Lgd interface.
AAA Server Name
See definition in clause 7.6.2. This parameter is provided in a successful response when the serving node is a 3GPP AAA server.
V-GMLC address
See definition in clause 7.6.2. . This parameter indicates the V-GMLC address of the serving node that is indicated by the Network Node Number.
Additional V-GMLC address
See definition in clause 7.6.2. This parameter indicates the V-GMLC address of the serving node that is indicated by the Additional Number. This parameter is provided only if additional LCS capability sets are available in HLR and Additional Number is present in this message.
H-GMLC address
See definition in clause 7.6.2. The requirements for its presence are specified in 3GPP TS 23.271 [26a].
PPR address
See definition in clause 7.6.2.
User error
The following errors defined in clause 7.6.1 may be used, depending on the nature of the fault:
-	Unknown subscriber;
-	Absent Subscriber;
-	Facility Not Supported;
-	System failure;
-	Unexpected Data Value;
-	Data missing;
-	Unauthorised requesting network.
Provider error
For definition of provider errors see clause 7.6.1.
13A.2	MAP-PROVIDE-SUBSCRIBER-LOCATION Service
13A.2.1	Definition
This service is used by a GMLC to request the location of a target MS from the visited MSC or SGSN at any time. This is a confirmed service using the primitives from table 13A.2/1.
13A.2.2	Service Primitives
Table 13A.2/1: Provide_Subscriber_Location
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
Location Type
M
M(=)


MLC Number
M
M(=)


LCS Client ID
M
M(=)


Privacy Override
U
C(=)


IMSI
C
C(=)


MSISDN
C
C(=)


LMSI
C
C(=)


LCS Priority
C
C(=)


LCS QoS
C
C(=)


IMEI
U
C(=)


Supported GAD Shapes
C
C(=)


LCS-Reference Number
C
C(=)


LCS Codeword
C
C(=)


LCS Service Type Id
C
C(=)


LCS Privacy Check
C
C(=)


Area Event Info
C
C(=)


H-GMLC Address
C
C(=)


Reporting PLMN List
C
C(=)


PeriodicLDRInfo
C
C(=)


MO-LR Short Circuit Indicator
C
C(=)
C
C(=)
Location Estimate


M
M(=)
GERAN Positioning Data


C
C(=)
UTRAN Positioning Data


C
C(=)
GERAN GANSS Positioning Data


C
C(=)
UTRAN GANSS Positioning Data


C
C(=)
UTRAN Additional Positioning Data


C
C(=)
UTRAN Barometric Pressure Measurement


C
C(=)
UTRAN Civic Address


C
C(=)
Age of Location Estimate


C
C(=)
Additional Location Estimate


C
C(=)
Deferred MT-LR Response Indicator


C
C(=)
Cell Id Or SAI


C
C(=)
Accuracy Fulfilment
Indicator


C
C(=)
Target Serving Node for Handover


C
C(=)
User error


C
C(=)
Provider error



O

13A.2.3	Parameter Definition and Use
All parameters are defined in clause 7.6. The use of these parameters and the requirements for their presence are specified in 3GPP TS 23.271 [26a].
Location Type
This parameter identifies the type of location information requested.
MLC Number
This is the E.164 number of the requesting GMLC.
LCS Client ID
This parameter provides information related to the identity of an LCS client.
Privacy Override
This parameter indicates if MS privacy is overridden by the LCS client when the GMLC and VMSC or SGSN for an MT-LR are in the same country.
IMSI
The IMSI is provided to identify the target MS. At least one of the IMSI or MSISDN is mandatory.
MSISDN
The MSISDN is provided to identify the target MS. At least one of the IMSI or MSISDN is mandatory.
LMSI
The LMSI shall be provided if previously supplied by the HLR. This parameter is only used in the case of the MT-LR for CS domain.
LCS Priority
This parameter indicates the priority of the location request.
LCS QoS
This parameter indicates the required quality of service in terms of response time and accuracy. 
IMEI
The requirements for its presence are specified in 3GPP TS 23.271 [26a].
Supported GAD Shapes
This parameter indicates which of the shapes defined in 3GPP TS 23.032 [122] are supported. 
LCS-Reference Number
This parameter shall be included if a deferred MT-LR procedure is performed for a UE available event, an area event or a periodic positioning event.
LCS Codeword
See definition in clause 7.6.11.18. The requirements for its presence are specified in 3GPP TS 23.271 [26a]. 
LCS Service Type Id
See definition in clause 7.6.11.15. The requirements for its presence are specified in 3GPP TS 23.271 [26a]. 
LCS Privacy Check
See definition in clause 7.6.11. The requirements for its and its components presence are specified in 3GPP TS 23.271 [26a].
Area Event Info
See definition in clause 7.6.11. The parameter shall be included if a deferred MT-LR procedure is performed for an area event.
H-GMLC address
See definition in clause 7.6.2. The parameter shall be included if a deferred MT-LR procedure is performed for a UE available event, an area event or a periodic positioning event.
Location Estimate
This parameter provides the location estimate if this is encoded in one of the supported geographical shapes. Otherwise this parameter shall consist of one octet, which shall be discarded by the receiving node.
GERAN Positioning Data
This parameter indicates the usage of each positioning method that was attempted to determine the location estimate either successfully or unsuccessfully.  If Positioning Data received from the RAN contains no Positioning Methods, Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is GERAN, see 3GPP TS 23.271 [26a]. 
UTRAN Positioning Data
This parameter indicates the usage of each positioning method that was successfully attempted to determine the location estimate.  If Position Data received from the RAN contains no Positioning Methods, UTRAN Positioning Data is excluded from the MAP message.  It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a]. 
GERAN GANSS Positioning Data
This parameter indicates the usage of each GANSS positioning method that was attempted to determine the location estimate either successfully or unsuccessfully. If GANSS Positioning Data received from the RAN contains no GANSS method, GERAN GANSS Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is GERAN, see 3GPP TS 23.271 [26a]. 
UTRAN GANSS Positioning Data
This parameter indicates the usage of each GANSS positioning method that was successfully attempted to determine the location estimate. If Position Data received from the RAN contains no GANSS Positioning Data Set, UTRAN GANSS Positioning Data is excluded from the MAP message.  It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a].
UTRAN Additional Positioning Data
This parameter indicates the usage of each Additional positioning method that was successfully attempted to determine the location estimate. If Position Data received from the RAN contains no Additional Positioning Data Set, UTRAN Additional Positioning Data is excluded from the MAP message.  It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a].
UTRAN Barometric Pressure Measurement
This parameter indicates the uncompensated barometric pressure measurement at the MS. The absence of this parameter implies that a barometric pressure measurement was not available or could not be successfully obtained.  It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a].
UTRAN Civic Address
This parameter indicates the civic address of the MS. The absence of this parameter implies that a civic address was not available or could not be successfully obtained.  It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a].
Age of Location Estimate
This parameter indicates how long ago the location estimate was obtained.
Additional Location Estimate
This parameter provides the location estimate when not provided by the Location Estimate parameter. It may be sent only if the parameter Supported GAD Shapes has been received in the Provide Subscriber Location indication and the shape to be included is supported by the GMLC.
Deferred MT-LR Response Indicator
See definition in clause 7.6.11.2.
Cell Id Or SAI
For GERAN access, this parameter indicates Global Cell Identifier of the cell that the served subscriber is currently attached to.  For UTRAN access, this parameter contains the Service Area Identifier for the cell that the subscriber is currently attached to.  This parameter is included only for North American Emergency Calls as described in 3GPP TS 23.271 [26a].  
Accuracy Fulfilment Indicator
See definition in clause 7.6.11.28. 
MO-LR Short Circuit Indicator
This parameter indicates whether MO-LR Short Circuit is permitted for periodic location.
Reporting PLMN List
This parameter indicates a list of PLMNs in which subsequent periodic MO-LR TTTP requests will be made.
Periodic LDR information
This parameter indicates the reporting amount and reporting interval of deferred periodic location.
Target Serving Node for Handover
This parameter provides the address of the target side serving node for handover of an IMS Emergency Call. 
User error
This parameter is sent by the responder when the location request has failed or cannot proceed and if present, takes one of the following values defined in clause 7.6.1.
-	System Failure;
-	Data Missing;
-	Unexpected Data Value;
-	Facility Not Supported;
-	Unidentified Subscriber;
-	Illegal Subscriber;
-	Illegal Equipment;
-	Absent Subscriber (diagnostic information may also be provided);
-	Unauthorised requesting network;
-	Unauthorised LCS Client with detailed reason;
-	Position method failure with detailed reason.
Provider error
These are defined in clause 7.6.1.
13A.3	MAP-SUBSCRIBER-LOCATION-REPORT Service
13A.3.1	Definition
This service is used by a VMSC or SGSN to provide the location of a target MS to a GMLC when a request for location is either implicitly administered or made at some earlier time. This is a confirmed service using the primitives from table 13A.3/1.
13A.3.2	Service Primitives
Table 13A.3/1: Subscriber_Location_Report
Parameter name
Request
Indication
Response
Confirm
Invoke id
M
M(=)
M(=)
M(=)
LCS Event
M
M(=)


LCS Client ID 
M
M(=)


Network Node Number
M
M(=)


IMSI
C
C(=)


MSISDN
C
C(=)


NA-ESRD
C
C(=)
C
C(=)
NA-ESRK
C
C(=)
C
C(=)
IMEI
U
C(=)


Location Estimate
C
C(=)


GERAN Positioning Data
C
C(=)


UTRAN Positioning Data
C
C(=)


GERAN GANSS Positioning Data
C
C(=)


UTRAN GANSS Positioning Data
C
C(=)


UTRAN Additional Positioning Data
C
C(=)


UTRAN Barometric Pressure Measurement
C
C(=)


UTRAN Civic Address
C
C(=)


Age of Location Estimate
C
C(=)


LMSI
U
C(=)


GPRS Node Indicator
C
C(=)


Additional Location Estimate
C
C(=)


Deferred MT-LR Data
C
C(=)


LCS-Reference Number
C
C(=)
C
C(=)
NA-ESRK Request
C
C(=)


Cell Id Or SAI
C
C(=)


H-GMLC Address
C
C(=)
C
C(=)
LCS Service Type Id
C
C(=)


Pseudonym Indicator
C
C(=)


Accuracy Fulfilment Indicator
C
C(=)


Sequence Number
C
C(=)


Periodic LDR Info
C
C(=)


MO-LR Short Circuit Indicator
C
C(=)
C
C(=)
Target Serving Node for Handover
C
C(=)


Reporting PLMN List


C
C(=)
User error


C
C(=)
Provider error



O

13A.3.3	Parameter Definition and Use
All parameters are defined in clause 7.6. The use of these parameters and the requirements for their presence are specified in. 3GPP TS 23.271 [26a].
LCS Event
This parameter indicates the event that triggered the Subscriber Location Report.
LCS Client ID
This parameter provides information related to the identity of the recipient LCS client.
Network Node Number
See definition in clause 7.6.2. This parameter provides the address of the sending node.
IMSI
The IMSI shall be provided if available to the VMSC or SGSN.
MSISDN
The MSISDN shall be provided if available to the VMSC or SGSN.
NA-ESRD
If the target MS has originated an emergency service call in North America, the NA-ESRD shall be provided by the VMSC if available.
If the target MS has originated an emergency service call in North America and NA-ESRK Request is included in Subscriber_Location_Report-Arg, an NA-ESRK or NA-ESRD, but not both, may also be included in the response to the MSC, see 3GPP TS 23.271 [26a].
NA-ESRK
If the target MS has originated an emergency service call in North America, the NA-ESRK shall be provided by the VMSC if assigned. 
If the target MS has originated an emergency service call in North America and NA-ESRK Request is included in Subscriber_Location_Report-Arg, an NA-ESRK or NA-ESRD, but not both, may also be included in the response to the MSC, see 3GPP TS 23.271 [26a].  
IMEI
The requirements for its presence are specified in 3GPP TS 23.271 [26a].
Location Estimate
This parameter provides the location estimate. The absence of this parameter implies that a location estimate was not available or could not be successfully obtained. If the obtained location estimate is not encoded in one of the supported geographical shapes then this parameter shall consist of one octet, which shall be discarded by the receiving node.
GERAN Positioning Data
This parameter indicates the usage of each positioning method that was attempted to determine the location estimate either successfully or unsuccessfully.  If Positioning Data received from the RAN contains no Positioning Methods, Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is GERAN, see 3GPP TS 23.271 [26a]. 
UTRAN Positioning Data
This parameter indicates the usage of each positioning method that was successfullyattempted to determine the location estimate.  If Position Data received from the RAN contains no Positioning Methods, UTRAN Positioning Data is excluded from the MAP message.  It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a].
GERAN GANSS Positioning Data
This parameter indicates the usage of each GANSS positioning method that was attempted to determine the location estimate either successfully or unsuccessfully. If GANSS Positioning Data received from the RAN contains no GANSS method, GERAN GANSS Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is GERAN, see 3GPP TS 23.271 [26a]. 
UTRAN GANSS Positioning Data
This parameter indicates the usage of each GANSS positioning method that was successfully attempted to determine the location estimate. If Position Data received from the RAN contains no GANSS Positioning Data Set, UTRAN GANSS Positioning Data is excluded from the MAP message.  It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a].
UTRAN Additional Positioning Data
This parameter indicates the usage of each Additional positioning method that was successfully attempted to determine the location estimate. If Position Data received from the RAN contains no Additional Positioning Data Set, UTRAN Additional Positioning Data is excluded from the MAP message.  It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a].
UTRAN Barometric Pressure Measurement
This parameter indicates the uncompensated barometric pressure measurement at the MS. The absence of this parameter implies that a barometric pressure measurement was not available or could not be successfully obtained.  It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a].
UTRAN Civic Address
This parameter indicates the civic address of the MS. The absence of this parameter implies that a civic address was not available or could not be successfully obtained.  It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a].
Age of Location Estimate
This parameter indicates how long ago the location estimate was obtained.
LMSI
The LMSI may be provided if assigned by the VLR.
GPRS Node Indicator
See definition in clause 7.6.8. This presence of this parameter is mandatory only if the SGSN number is sent in the Network Node Number. 
Additional Location Estimate
This parameter provides the location estimate when not provided by the Location Estimate parameter..
Deferred MT-LR Data
See definition in clause 7.6.11.3.
LCS-Reference Number
This parameter shall be included if the Subscriber Location Report is the response to a deferred MT location request.
NA-ESRK Request
If the target MS has originated an emergency service call in North America, NA-ESRK Request may be included to indicate that the MSC is able to accept NA-ESRK in the Response message, see clause 7.6.11.19.  
Cell Id Or SAI
For GERAN access, this parameter indicates Global Cell Identifier of the cell that the served subscriber is currently attached to.  For UTRAN access, this parameter contains the Service Area Identifier for the cell that the subscriber is currently attached to.  This parameter is included only for Emergency Calls as described in 3GPP TS 23.271 [26a].   
H-GMLC address
See definition in clause 7.6.2. The parameter shall be included if the Subscriber Location Report is the response to a deferred MT location request for a UE available event, an area event or a periodic positioning event. This parameter shall be included in a Subscriber Location Report response if a deferred MO-LR TTTP procedure is initiated for a periodic positioning event.
LCS Service Type Id
See definition in clause 7.6.11.15. The requirements for its presence are specified in 3GPP TS 23.271 [26a].
Pseudonym Indicator
This parameter indicates by its presence that the pseudonym is required. Refer to 3GPP TS 23.271 [26a]. 
Accuracy Fulfilment Indicator
For a mobile terminated periodic LDR, this parameter indicates whether the obtained location estimate satisfies the requested accuracy or not, provided that this indication is obtained from RAN or the UE with the location estimate.
Periodic LDR Information
This parameter refers to the periodic reporting interval and reporting amount of the deferred periodic location.
MO-LR Short Circuit Indicator
This parameter indicates whether MO-LR Short Circuit is permitted for periodic location.
Reporting PLMN List
This parameter indicates a list of PLMNs in which subsequent periodic MO-LR TTTP requests will be made.
Sequence Number
This parameter refers to the number of the periodic location reports completed. The sequence number would be set to 1 in the first location report and increment by 1 for each new report. When the number reaches the reporting amount value, the H-GMLC (for a periodic MT-LR or a periodic MO-LR transfer to third party) will know the procedure is complete. For details see 3GPP TS 23.271 [26a].
Target Serving Node for Handover
This parameter provides the address of the target side serving node for handover of an IMS Emergency Call. 
User error
This parameter is sent by the responder when the received message contains an error, cannot be forwarded or stored for an LCS client or cannot be accepted for some other reason and if present, takes one of the following values defined in clause 7.6.1.
-	System Failure;
-	Data Missing;
-	Unexpected Data Value;
-	Resource Limitation;
-	Unknown Subscriber;
-	Unauthorised requesting network;
-	Unknown or unreachable LCS Client.
Provider error
These are defined in clause 7.6.1.
13A.4	Void
13A.4.1	Void
13A.4.2	Void
13A.4.3	Void
13A.5	Void
13A.5.1	Void
13A.5.2	Void
13A.5.3	Void
13A.6	Void
13A.6.1	Void
13A.6.2	Void
13A.6.3	Void
13A.7	Void
13A.7.1	Void
13A.7.2	Void
13A.7.3	Void
13A.8	Void
13A.8.1	Void
13A.8.2	Void
13A.8.3	Void
13A.9	Void
13A.9.1	Void
13A.9.2	Void
13A.9.3	Void
14	General
14.1	Overview
Clauses 14 to 17 specify the protocol elements to be used to provide the MAP services described in clause 7.
Clause 15 specifies the elements of procedures for the MAP protocol. Clause 16 specifies the mapping onto TC service primitives. Clause 17 specifies the application contexts, operation packages and abstract syntaxes for the MAP protocol as well as the encoding rules to be applied.
14.2	Underlying services
The MAP protocol relies on the services provided by the Transaction Capabilities (TC) of Signalling System Number No. 7, as referenced in clause 6.
14.3	Model
The MAP Protocol Machine (MAP PM) can be modelled as a collection of service state machines (SSMs) - one per MAP specific service invoked - coordinated by a MAP dialogue control function with its one state machine: MAP dialogue state machine (DSM). There are two types of Service State Machines: Requesting Service State Machines (RSM) and Performing Service State Machines (PSM).
A new invocation of a MAP PM is employed on the receipt of a MAP-OPEN request primitive or a TC-BEGIN indication primitive. Each invocation controls exactly one MAP dialogue. For each MAP specific service invoked during a dialogue, a MAP RSM is created at the requestor's side and a MAP PSM is created at the performer's side.
This modelling is used only to facilitate understanding and the MAP behaviour descriptions and is not intended to suggest any implementation. SDL descriptions are organised according to this model.
How the MAP-service-user and the MAP refer to a MAP dialogue (i.e. a MAP PM invocation) is a local implementation matter.
How TC dialogue identifiers are assigned to a MAP PM invocation is also a local implementation matter.
14.4	Conventions
The behaviour of the MAP PM depends on the application-context-name associated with the dialogue. One major difference is that the MAP requests the transfer of the application-context-name by TC only for those contexts which do not belong to the so-called "version one context set".
The "version one context set" is a set of application-contexts which model the behaviour of a MAP V1 implementation according to the latest phase 1 version of GSM 09.02. This set is defined in clause 15.
The procedures described in clause 15 are used when the application-context-name does not refer to a dialogue between an MSC and its VLR. When the application-context-name refers to a dialogue between an MSC and its VLR the MAP PM procedures are a local implementation matter.
15	Elements of procedure
15.1	Handling of unknown operations
Unknown operations (i.e. a standard operation introduced in a later version of the MAP specification, or a private operation) can be introduced into MAP in a backwards compatible way. This means that the receiver of an unknown operation shall, if the dialogue state allows it, send a TC-REJECT component to the sender of the operation indicating 'unrecognised operation' and continue with the processing of further components or messages exchanged within the dialogue as if the unknown operation had not been received.
The standardised structure of a MAP dialogue shall not be affected by the invocation of unknown operations, i.e. if a dialogue uses only a TC-BEGIN message which is acknowledged by a TC-END message, a TC-CONTINUE message shall not be used to invoke an unknown operation. However the standardised structure of a MAP dialogue may be affected by the rejection of unknown operations, i.e. if a dialogue uses only a TC-BEGIN message which is acknowledged by a TC-END message, a TC-CONTINUE message followed by a TC-END message may be used to carry the rejection of an unknown operation and the response to the standardised operation. The entity which initiated a dialogue whose standardised structure is a TC-BEGIN message which is acknowledged by a TC-END message shall not send any messages in that dialogue after the TC-BEGIN. Note that if the dialogue structure is affected as described in this paragraph the TC-CONTINUE shall include the dialogue portion required to confirm the acceptance of the dialogue.
Unknown operations may be invoked in the following types of message (there is no restriction as to how many unknown operations can be invoked in a message):
-	TC-BEGIN: the component to invoke the unknown operation shall follow the component of the standard operation which is included in this message. 
-	TC-CONTINUE: the component to invoke the unknown operation may be transported as the only component in a stand-alone message or may be grouped with existing operations. In the latter case a specific sequencing of components is not required.
-	TC-END: if the component to invoke the unknown operation is grouped with an existing operation a specific sequencing of components is not required
The TC-REJECT component may be sent in the following messages:
-	TC-CONTINUE or TC-END: either as the only component of the message or grouped with an existing component. The choice is up to the MAP-Service User.
	If the received message contains only unknown operations the MAP-Service User shall send the TC-REJECT components in a TC-CONTINUE message to the peer entity, if the dialogue state allows it.
	If the received message contains unknown operations and standard operations and the standardised structure of the dialogue requires the response to the standard operation to be sent within a TC-END message, then the MAP-Service User may send the response to the standard operations and the TC-REJECT components for the unknown operations in a TC-CONTINUE message followed by a TC-END message. Neither a specific distribution of the components to the TC messages nor a specific sequencing of components is required.
Note that the SDL diagrams of clauses 19 - 25 do not show the report to the MAP-Service User about the reception of the unknown operation. This has been done for simplicity of description; the MAP PM may inform the MAP-Service User.
The sender of the unknown operation shall ensure that there is enough room in the used message for the unknown operation.
15.2	Dialogue establishment
The establishment of a MAP dialogue involves two MAP-service-users: the dialogue-initiator and the dialogue-responder.
This procedure is driven by the following signals:
-	a MAP-OPEN request primitive from the dialogue-initiator;
-	a TC-BEGIN indication primitive occurring at the responding side;
-	a MAP-OPEN response primitive from the dialogue-responder;
-	the first TC-CONTINUE indication primitive occurring at the initiating side;
and under specific conditions:
-	a TC-END indication primitive occurring at the initiating side;
-	a TC-U-ABORT indication primitive occurring at the initiating side;
-	a TC-P-ABORT indication primitive occurring at the initiating side.
One instance of the MAP dialogue state machine runs at the initiating side, and one at the responding side.
15.2.1	Behaviour at the initiating side
The behaviour of the MAP dialogue state machine at the initiating side is defined in sheets 1 – 8 of the process MAP_DSM (figure 15.6/3).
Sheet 3: When the MAP dialogue state machine at the initiating side is waiting for a response from the responding side, a TC-END indication which echoes the AC name which was sent in the TC-BEGIN indicates acceptance of the dialogue. 
Sheet 3: If the dialogue opening is accepted, any components included in the TC-END are processed and passed to the MAP-Service User. The dialogue is closed by sending a MAP-CLOSE to the MAP-Service User.
Sheet 3, sheet 4, sheet 5, sheet 6, sheet 7, sheet 8: when a dialogue is terminated, the MAP dialogue state machine terminates all instances of the Requesting_MAP_SSM which are active for this dialogue.
Sheet 4: A TC-P-ABORT with an abort parameter Incorrect_Transaction_Portion indicates that the responding side does not support a MAP version higher than 1. This triggers a MAP-OPEN confirm indicating that the dialogue is refused, with a refuse reason potential version incompatibility. The MAP-Service User may then decide to retry the dialogue at MAP version 1. 
Sheet 8: When the MAP dialogue state machine at the initiating side is waiting for a response from the responding side, a TC-CONTINUE indication which echoes the AC name which was sent in the TC-BEGIN indicates acceptance of the dialogue. 
Sheet 8: If the dialogue opening is accepted, any components included in the TC-CONTINUE are processed and passed to the MAP-Service User. The dialogue has then reached the established state.
15.2.2	Behaviour at the responding side
The behaviour of the MAP dialogue state machine at the responding side is defined in sheets 0 – 14 of the process MAP_DSM (figure 15.6/3).
Sheet 9: If no application context information is included in the TC-BEGIN indication, this implies a MAP version 1 dialogue. An explicit application context indicating version 1 is treated as abnormal behaviour.
Sheet 11: The v1 application context name which corresponds to a v1 operation is derived using the information in table 15.2/1.
Table 15.2/1: Mapping of V1 operation codes on to application-context-names
Operation
Application-context-name (note 1)
updateLocation
networkLocUpContext-v1
cancelLocation
locationCancellationContext-v1
provideRoamingNumber
roamingNumberEnquiryContext-v1
insertSubscriberData
subscriberDataMngtContext-v1
deleteSubscriberData
subscriberDataMngtContext-v1
sendParameters
infoRetrievalContext-v1

networkLocUpContext-v1 (note 2)
beginSubscriberActivity
networkFunctionalSsContext-v1
sendRoutingInfo
locationInfoRetrievalContext-v1
performHandover
handoverControlContext-v1
reset
resetContext-v1
activateTraceMode
tracingContext-v1
deactivateTraceMode
tracingContext-v1
sendRoutingInfoForSM
shortMsgGatewayContext-v1
forwardSM
shortMsgRelayContext-v1
reportSM-deliveryStatus
shortMsgGatewayContext-v1
noteSubscriberPresent
mwdMngtContext-v1
alertServiceCentreWithoutResult
shortMsgAlertContext-v1
checkIMEI
EquipmentMngtContext-v1

NOTE 1:	These symbolic names refer to the object identifier value defined in clause 17 and allocated to each application-context used for the MAP.
NOTE 2:	The choice between the application contexts is based on the parameters received in the operation.

Sheet 12: If the dialogue is accepted, each component present in the TC-BEGIN is forwarded to an instance of a Performing_MAP_SSM, by executing the procedure Process_Components.
Sheet 13: If the MAP dialogue state machine receives a MAP-OPEN response with a result accepted, it waits for any MAP specific service request or response primitives or a MAP-DELIMITER request. 
Sheet 13, sheet 14: When a dialogue is terminated, the MAP dialogue state machine terminates all instances of the Requesting_MAP_SSM or Performing_MAP_SSM which are active for this dialogue.
Sheet 14: A MAP-DELIMITER request triggers a TC-CONTINUE request to accept the dialogue. The dialogue has then reached the established state.
15.3	Dialogue continuation
Once established the dialogue is said to be in a continuation phase. The behaviour of the MAP dialogue state machine in this phase is defined in sheets 15 – 17 of the process MAP_DSM (figure 15.6/3).
Both MAP users can request the transfer of MAP APDUs until one of them requests the termination of the dialogue.
Normal closure of an established dialogue is shown on sheet 16; abnormal termination is shown on sheet 17.
15.4	Load control
If an entity which should respond to a MAP dialogue opening request is overloaded, it uses the AC of the request to determine whether to discard the request. 
The priority level allocated to each application-context is described in clause 5, tables 5.1/1, 5.1/2, and 5.1/3.
15.5	Procedures for MAP specific services
This clause describes the MAP procedures for MAP specific services. These procedures are driven by the following types of event:
-	a MAP specific request or a MAP specific response primitive;
-	a component handling primitive from TC.
A Service State Machine is activated when of one of the following signals is received:
-	a MAP request primitive, which activates a requesting SSM;
-	a TC-INVOKE indication primitive without a linked identifier, which activates a performing SSM.
For component handling primitives there are two types of event:
-	events which activate a Service State Machine or which can be related to an existing one;
-	events which cannot be related to a Service State Machine.
15.5.1	Service invocation 
The behaviour of the requesting SSM which handles a service is defined by the SDL for the process Requesting_MAP_SSM. The requesting SSM receives a MAP service request from the MAP-Service User via the MAP dialogue state machine and sends a TC-INVOKE request to TCAP. When a confirm is received from TCAP via the MAP dialogue state machine, the requesting SSM forwards a MAP service confirm to the MAP-Service User.
The response to a MAP service invocation may come in the form of a linked request. If the linked request corresponds to a class 4 operation, this is handled by the requesting SSM. If the linked request corresponds to a class 1, 2 or 3 operation, the MAP dialogue state machine sends a notification to the requesting SSM and creates an instance of a performing SSM to handle the linked request. The test "Linked_Operation_Allowed" on sheet 3 of the process Requesting_MAP_SSM takes the (TRUE) exit if the definition of the parent operation includes the received linked operation as a permitted linked operation; otherwise the test takes the (FALSE) exit.
The mapping of MAP specific services on to remote operations is given in table 16.2/1.
15.5.2	Void
15.5.3	Service invocation receipt 
The behaviour of the performing SSM which handles a service is defined by the SDL for the process Performing_MAP_SSM. The performing SSM receives a TC-INVOKE component from TCAP via the MAP dialogue state machine and sends a MAP service indication to the MAP-Service User. When a MAP service response is received from the MAP-Service User via the MAP dialogue state machine, the performing SSM forwards a TC-RESULT or TC-U-ERROR component to TCAP.
15.5.4	Void
15.5.5	Handling of components received from TC
The procedure Process_Components shows the handling of components received in a TC-BEGIN, TC-CONTINUE or TC-END message.
Sheet 2: If a linked invoke component corresponds to a class 4 operation, the MAP dialogue state machine sends it to the requesting SSM instance identified by the linked invoke ID. If a linked invoke component corresponds to any other class of operation, the MAP dialogue state machine sends a notification to the requesting SSM instance identified by the linked invoke ID, creates an instance of a performing SSM and sends the invoke component to it.
15.6	SDL descriptions
The following SDL specification describes a system which includes three blocks: MAP-user, MAP-provider and TC.
Such a system resides in each network component supporting MAP and communicates with its peers via the lower layers of the signalling network which are part of the environment.
Only the MAP-provider is fully described in this clause. The various types of processes which form the MAP-User block and the TC block are described respectively in clauses 18 to 25 of the present document and in CCITT Recommendation Q.774.
The MAP-Provider block communicates with the MAP_USER via two channels U1 and U2. Via U1 the MAP-provider receives the MAP request and response primitives. Via U2 it sends the MAP indication and confirm primitives.
The MAP-Provider block communicates with TC via two channels P1 and P2. Via P1 the MAP-Provider sends all the TC request primitives. Via P2 it receives all the TC indication primitives.
The MAP-Provider block is composed of the four following types of process:
a)	MAP_DSM: This type of process handles a dialogue for transport of MAP messages. There exists one process instance per MAP dialogue.
b)	Load_Ctrl: This type of process is in charge of load control. There is only one instance of this process in each system.
c)	Requesting_MAP_SSM: This type of process handles a MAP service requested during a dialogue. An instance of this process is created by the instance of the MAP_DSM process for each requested MAP service. 
d)	Performing_MAP_SSM: This type of process handles a MAP service performed during a dialogue. An instance of this process is created by the instance of the MAP_DSM process for each MAP service to be performed. 
A process MAP_DSM exchanges external signals with other blocks as well as internal signals with the other processes of the MAP-Provider block. The external signals are either MAP service primitives or TC service primitives.
The signal routes used by the various processes are organised as follows:
a)	A process MAP_DSM receives and sends events from/to the MAP_user via signal route User1/User2. These routes use channels U1 and U2 respectively.
b)	A process MAP_DSM receives and sends events from/to the TCAP via signal route TC1/TC2. These routes use channels P1 and P2 respectively.
c)	A process MAP_DSM receives and sends events from/to the LOAD_CTRL process via signal route Load1/Load2. These routes are internal.
d)	A process MAP_DSM sends events to the Performing_MAP_SSM processes via signal route Intern1. This route is internal.
e)	A process MAP_DSM sends events to the Requesting_MAP_SSM processes via signal route Intern2. This route is internal.
f)	A process Performing_MAP_SSM sends events to the MAP_USER via signal route User3. This route uses channel U2.
g)	A process Performing_MAP_SSM sends events to the TCAP via signal route TC3. This route uses channel P1.
h)	A process Requesting_MAP_SSM sends events to the MAP_USER via signal route User4. This route uses channel U2.
i)	A process Requesting_MAP_SSM sends events to the TCAP via signal route TC4. This route uses channel P1.

Figure 15.6/1: System MAP_Stack

Figure 15.6/2: Block MAP_Provider

Figure 15.6/3a: Process MAP_DSM (sheet 1)

Figure 15.6/3b: Process MAP_DSM (sheet 2)

Figure 15.6/3c: Process MAP_DSM (sheet 3)

Figure 15.6/3d: Process MAP_DSM (sheet 4)

Figure 15.6/3e: Process MAP_DSM (sheet 5)

Figure 15.6/3f: Process MAP_DSM (sheet 6)

Figure 15.6/3g: Process MAP_DSM (sheet 7)

Figure 15.6/3h: Process MAP_DSM (sheet 8)

Figure 15.6/3i: Process MAP_DSM (sheet 9)

Figure 15.6/3j: Process MAP_DSM (sheet 10)

Figure 15.6/3k: Process MAP_DSM (sheet 11)

Figure 15.6/3l: Process MAP_DSM (sheet 12)

Figure 15.6/3m: Process MAP_DSM (sheet 13)

Figure 15.6/3n: Process MAP_DSM (sheet 14)

Figure 15.6/30: Process MAP_DSM (sheet 15)

Figure 15.6/3p: Process MAP_DSM (sheet 16)

Figure 15.6/3q: Process MAP_DSM (sheet 17)


Figure 15.6/4a: Procedure Process_Components (sheet 1)

Figure 15.6/4b: Procedure Process_Components (sheet 2)

Figure 15.6/4c: Procedure Process_Components (sheet 3)

Figure 15.6/4d: Procedure Process_Components (sheet 4)

Figure 15.6/4e: Procedure Process_Components (sheet 5)

Figure 15.6/5: Process Load_Ctrl

Figure 15.6/6a: Process Requesting_MAP_SSM (sheet 1)

Figure 15.6/6b: Process Requesting_MAP_SSM (sheet 2)

Figure 15.6/6c: Process Requesting_MAP_SSM (sheet 3)

Figure 15.6/6d: Process Requesting_MAP_SSM (sheet 4)





Figure 15.6/8a: Process Performing_MAP_SSM (sheet 1)

Figure 15.6/8b: Process Performing_MAP_SSM (sheet 2)


16	Mapping on to TC services
16.1	Dialogue control
Dialogue control services are mapped to TC dialogue handling services. The TC-UNI service is not used by the MAP PM.
16.1.1	Directly mapped parameters
The following parameters of the MAP-OPEN request and indication primitives are directly mapped on to the corresponding parameters of the TC-BEGIN primitives:
-	destination address;
-	originating address.
16.1.2	Use of other parameters of dialogue handling primitives
16.1.2.1	Dialogue Id
The value of this parameter is associated with the MAP PM invocation in an implementation dependent manner.
16.1.2.2	Application-context-name
The application-context-name parameter of a MAP primitive is mapped to the application-context-name parameter of TC dialogue handling primitives according to the rules described in clause 15.1.
16.1.2.3	User information
The user information parameter of TC dialogue primitives is used to carry the MAP dialogue APDUs.
16.1.2.4	Component present
This parameter is used by the MAP PM as described in CCITT Recommendation Q.771. It is not visible to the MAP user.
16.1.2.5	Termination
The value of this parameter of the TC-END request primitive is set by the MAP PM on the basis of the release method parameter of the MAP-CLOSE request primitive, except when the dialogue state machine is in the state DIALOGUE INITIATED, in which case the Termination parameter shall always indicate "pre-arranged end".
16.1.2.6	P-Abort-Cause
Values of the P-abort-cause parameter are mapped to the values of the provider-reason parameter of the MAP‑P‑ABORT indication primitive according to table 16.1/1, except in the dialogue initiated phase for the "incorrectTransactionPortion" and "noCommonDialoguePortion" values which are mapped to the "potential incompatibility problem" value of the refuse-reason parameter of the MAP-OPEN cnf primitive. The source parameter in the MAP-P-ABORT ind takes the value "TC problem".
16.1.2.7	Quality of service
The quality of service of TC request primitives is set by the MAP as shown below.
-	Return option: "Return message on error" or "Discard message on error" as required by the network operator;
-	Sequence control: "Sequence guaranteed" or "Sequence result not guaranteed" as required by the network operator;
-	"Sequence guaranteed" shall be used when a segmented result is to be transferred (e.g. subscriber data in response to SendParameters). It may also be appropriate to use Sequence guaranteed when a series of InsertSubscriberData, ProcessAccessSignalling or ForwardAccessSignalling operations is used.
It is essential that the TC message which indicates acceptance of a dialogue opening request is received by the dialogue initiator before any subsequent message in that dialogue; otherwise the dialogue opening will fail. The dialogue responder shall ensure that this requirement is met by:
-	Sending the dialogue acceptance message in a TC‑END, if the dialogue structure requires it; or
-	Using "Sequence guaranteed", if the dialogue acceptance message is sent in a TC‑CONTINUE; or
-	Waiting until the dialogue acceptance message has been acknowledged by the dialogue initiator before sending a subsequent message, if the dialogue acceptance message is sent in a TC‑CONTINUE.
Table 16.1/1: Mapping of P-Abort cause in TC-P-ABORT indication
on to provider-reason in MAP-P-ABORT indication
TC P-Abort cause
MAP provider-reason
unrecognised message type
provider malfunction
unrecognised transaction Id
supporting dialogue released
badlyFormattedTransactionPortion
provider malfunction
incorrectTransactionPortion
provider malfunction (note)
resourceLimitation
resource limitation
abnormalDialogue
provider malfunction
noCommonDialoguePortion
version incompatibility
NOTE:	Or version incompatibility in the dialogue initiated phase.

16.2	Service specific procedures
Specific services are mapped to TC component handling services.
16.2.1	Directly mapped parameters
The Invoke Id parameter of the MAP request and indication primitive is directly mapped on to the Invoke Id parameter of the component handling primitives.
16.2.2	Use of other parameters of component handling primitives
16.2.2.1	Dialogue Id
The value of this parameter is associated with the MAP PM invocation in an implementation dependent manner.
16.2.2.2	Class
The value of this parameter is set by the MAP PM according to the type of the operation to be invoked.
16.2.2.3	Linked Id
When a service response is mapped to a class 4 operation, the value of this parameter is set by the MAP PM and corresponds to the value assigned by the user to the initial service request (i.e. the value of the invoke ID parameter of the request primitive). Otherwise if such a parameter is included in MAP request/indication primitives it is directly mapped to the linked ID parameter of the associated TC‑INVOKE request/indication primitives.
16.2.2.4	Operation
When mapping a request primitive on to a Remote Operations PDU (invoke), the MAP PM shall set the operation code according to the mapping described in table 16.2/1.
When mapping a response primitive on to a Remote Operations service, the MAP PM shall set the operation code of the TC-RESULT-L/NL primitive (if required) to the same value as the one received at invocation time.
Table 16.2/1: Mapping of MAP specific services on to MAP operations
MAP-SERVICE
operation
MAP-ACTIVATE-SS
activateSS
MAP-ACTIVATE-TRACE-MODE
activateTraceMode
MAP-ALERT-SERVICE-CENTRE
alertServiceCentre
MAP-ANY-TIME-INTERROGATION
anyTimeInterrogaton
MAP_AUTHENTICATION_FAILURE_REPORT
authenticationFailureReport
MAP-ANY-TIME-MODIFICATION
anyTimeModification
MAP-ANY-TIME-SUBSCRIPTION-INTERROGATION
anyTimeSubscriptionInterrogation
MAP-CANCEL-LOCATION
cancelLocation
MAP-CHECK-IMEI
checkIMEI
MAP-DEACTIVATE-SS
deactivateSS
MAP-DEACTIVATE-TRACE-MODE 
deactivateTraceMode
MAP-DELETE-SUBSCRIBER-DATA
deleteSubscriberData
MAP-ERASE-CC-ENTRY
eraseCC-Entry
MAP-ERASE-SS
eraseSS
MAP-FAILURE-REPORT
failureReport
MAP-FORWARD-ACCESS-SIGNALLING
forwardAccessSignalling
MAP-FORWARD-CHECK-SS-INDICATION
forwardCheckSsIndication
MAP-FORWARD-GROUP-CALL-SIGNALLING
forwardGroupCallSignalling
MAP-MT-FORWARD-SHORT-MESSAGE
mt-forwardSM
MAP-MO-FORWARD-SHORT-MESSAGE
mo-forwardSM
MAP-GET-PASSWORD
getPassword
MAP-INFORM-SERVICE-CENTRE
informServiceCentre
MAP-INSERT-SUBSCRIBER-DATA
insertSubscriberData
MAP-INTERROGATE-SS
interrogateSs
MAP-IST-ALERT
istAlert
MAP-IST-COMMAND
istCommand
MAP-NOTE-MS-PRESENT-FOR-GPRS
noteMsPresentForGprs
MAP-NOTE-SUBSCRIBER-DATA-MODIFIED
noteSubscriberDataModified
MAP-PREPARE-GROUP-CALL
prepareGroupCall
MAP-PREPARE-HANDOVER
prepareHandover
MAP-PREPARE-SUBSEQUENT-HANDOVER
prepareSubsequentHandover
MAP-PROCESS-ACCESS-SIGNALLING
processAccessSignalling
MAP-PROCESS-GROUP-CALL-SIGNALLING
processGroupCallSignalling
MAP-PROCESS-UNSTRUCTURED-SS-REQUEST
processUnstructuredSS-Request
MAP-PROVIDE-ROAMING-NUMBER
provideRoamingNumber
MAP-PROVIDE-SUBSCRIBER-LOCATION
provideSubscriberLocation
MAP-PROVIDE-SUBSCRIBER-INFO
provideSubscriberInfo
MAP-PURGE-MS
purgeMS
MAP-READY-FOR-SM
readyForSM
MAP-REGISTER-CC-ENTRY
registerCC-Entry
MAP-REGISTER-PASSWORD
registerPassword
MAP-REGISTER-SS
registerSS
MAP-REMOTE-USER-FREE
remoteUserFree
MAP-REPORT-SM-DELIVERY-STATUS
reportSmDeliveryStatus
MAP-RESET
reset
MAP-RESTORE-DATA
restoreData
MAP-SEND_GROUP-CALL_END_SIGNAL
sendGroupCallEndSignal
MAP-SEND-GROUP-CALL-INFO
sendGroupCallInfo
MAP-SEND-END-SIGNAL 
sendEndSignal
MAP-SEND-AUTHENTICATION-INFO
sendAuthenticationInfo
MAP-SEND-IMSI
sendIMSI
MAP-SEND-IDENTIFICATION
sendIdentification
MAP-SEND-ROUTING-INFO-FOR-SM
sendRoutingInfoForSM
MAP-SEND-ROUTING-INFO-FOR-GPRS
sendRoutingInfoForGprs
MAP-SEND-ROUTING-INFO-FOR-LCS
sendRoutingInfoForLCS
MAP-SEND-ROUTING-INFORMATION
sendRoutingInfo
MAP-SET-REPORTING-STATE
setReportingState
MAP-STATUS-REPORT
statusReport
MAP-SUBSCRIBER-LOCATION-REPORT
subscriberLocationReport
MAP-SUPPLEMENTARY-SERVICE-INVOCATION-NOTIFICATION
ss-Invocation-Notification
MAP-UNSTRUCTURED-SS-NOTIFY
unstructuredSS-Notify
MAP-UNSTRUCTURED-SS-REQUEST
unstructuredSS-Request
MAP-UPDATE-GPRS-LOCATION
updateGprsLocation
MAP-UPDATE-LOCATION
updateLocation
MAP-NOTE-MM-EVENT
NoteMM-Event
MAP-UPDATE-VCSG-LOCATION
updateVcsgLocation
MAP-CANCEL-VCSG-LOCATION
cancelVcsgLocation

16.2.2.5	Error
The error parameter in a TC-U-ERROR indication primitive is mapped to the user error parameter in the MAP confirm primitive of the service associated with the operation to which the error is attached.
The user error parameter in MAP response primitives is mapped to the error parameter of the TC‑U‑ERROR request primitive, except for "initiating-release" and "resource-limitation" which are mapped to the problem code parameter of the TC-U-REJECT request primitive.
16.2.2.6	Parameters
The parameters of MAP specific request and indication primitives are mapped to the argument parameter of TC-INVOKE primitives.
The parameters of MAP specific response and confirm primitives are mapped to the result parameter of TC-RESULT-L primitives, the parameter of TC-U-ERROR primitives or the argument of TC-INVOKE primitives when mapping on linked class 4 operations is used.
16.2.2.7	Time out
The value of this parameter is set by the MAP PM according to the type of operation invoked.
16.2.2.8	Last component
This parameter is used by the MAP PM as described in CCITT Recommendation Q.711. It is not visible from the MAP user.
16.2.2.9	Problem code
16.2.2.9.1	Mapping to MAP User Error
The following values of the user error parameter are mapped as follows to values of the TC problem code parameter. These values are generated by the MAP user. This mapping is valid from the TC-U-REJECT indication primitive to the MAP confirm service primitive and from the MAP response service primitive to the TC-U-REJECT request primitive.
Table 16.2/2: Mapping of MAP User Error parameter on to TC problem code
in TC-U-REJECT primitives
MAP User Error
TC problem code
resource limitation
resource limitation
initiating release
initiating release

16.2.2.9.2	Mapping to MAP Provider Error parameter
The following values of the TC problem code parameter of the TC-U-REJECT indication primitive are mapped as follows to values of the MAP Provider Error parameter of the MAP confirm primitive.
Table 16.2/3: Mapping of TC problem code in TC-U-REJECT on to MAP Provider Error parameter
TC problem code
MAP Provider Error
duplicated invoke Id
duplicated invoke id
unrecognised operation
service not supported
mistyped parameter
mistyped parameter

The following values of the problem code parameters of the TC-L-REJECT primitive are mapped to values of the provider error parameter of the MAP confirm primitive as follows.
Table 16.2/4: Mapping of TC problem code in TC-L-REJECT on to MAP Provider Error parameter
TC problem code
MAP Provider Error
return result unexpected
unexpected response from the peer
return error unexpected
unexpected response from the peer

16.2.2.9.3	Mapping to diagnostic parameter
The following values of the problem code parameter of the TC-R-REJECT and TC-U-REJECT primitive are mapped to values of the diagnostic parameter of the MAP-NOTICE indication primitive as follows:
Table 16.2/5: Mapping of TC problem code of TC-R-REJECT and TC-U-REJECT
on to diagnostic parameter
TC problem code
MAP diagnostic
General problem
- abnormal event detected by the peer
Invoke problem

-	unrecognised linked ID
- abnormal event detected by the peer
-	linked response unexpected
- response rejected by the peer
-	unexpected linked operation
- response rejected by the peer
Return result problem

-	unrecognised invoke ID
- response rejected by the peer
-	return result unexpected
- response rejected by the peer
-	mistyped parameter
- response rejected by the peer
Return error problem

-	unrecognised invoke ID
- response rejected by the peer
-	return error unexpected
- response rejected by the peer
-	unrecognised error
- response rejected by the peer
-	unexpected error
- response rejected by the peer
-	mistyped parameter
- response rejected by the peer

The following values of the problem code parameter of the TC-L-REJECT primitive are mapped to values of the diagnostic parameter of the MAP-NOTICE indication primitive as follows.
Table 16.2/6: Mapping of TC problem code of TC-L-REJECT on to diagnostic parameter
TC problem code
MAP diagnostic
General problems
- abnormal event received from the peer
Invoke problem

-	unrecognised linked ID
- abnormal event received from the peer
Return result problem

-	unrecognised invoke ID
- abnormal event received from the peer
Return error problem

-	unrecognised invoke ID
- abnormal event received from the peer

17	Abstract syntax of the MAP protocol
17.1	General
This clause specifies the Abstract Syntaxes for the Mobile Application Part as well as the associated set of Operations and Errors, using the Abstract Syntax Notation One (ASN.1), defined in ITU-T Recommendations X.680  and X.681 with additions as defined in clause 17.1.4 on Compatibility Considerations and the OPERATION and ERROR external information object classes, defined in ITU-T Recommendation X.880.
The Abstract Syntax is defined for all interfaces specified in clause 4.4 except for the A- and B-interfaces.
The Mobile Application Part protocol is defined by two Abstract Syntaxes:
-	one Abstract Syntax which encompass all Operations and Errors identified by the various MAP subsystem numbers.
This Abstract Syntax represents the set of values each of which is a value of the ASN.1 type TCAPMessages. TCMessage as defined in ITU-T Recommendation Q.773 with the component relationconstraint clauses resolved by the operation and error codes included in the ASN.1 modules MAP-*Operations and MAP-Errors. However, only the subset of this abstract syntax which is required by the procedures defined for an entity needs to be supported.
-	one Abstract Syntax identified by the OBJECT IDENTIFIER value MAP-DialogueInformation.map-DialogueAS.
This Abstract Syntax represents the set of values each of which is a value of the ASN.1 type MAP-DialogueInformation.MAP-DialoguePDU. Such a value of the ASN.1 single-ASN.1-type element is contained within the user-information element of the TCAPMessages.DialoguePortion ASN.1 type. This Abstract Syntax name is to be used as a direct reference.
17.1.1	Encoding rules
The encoding rules which are applicable to the defined Abstract Syntaxes are the Basic Encoding Rules for Abstract Syntax Notation One, defined in ITU-T Recommendation X.690 with the same exceptions as in ITU-T Recommendation Q.773, clause 4 Message Representation.
When the definite form is used for length encoding, a data value of length less than 128 octets must have the length encoded in the short form.
When the long form is employed to code a length, the minimum number of octets shall be used to code the length field.
OCTET STRING values and BIT STRING values must be encoded in a primitive form.
There is no restriction to the use of empty constructors (e.g. an empty SEQUENCE type). That is, the encoding of the content of any data value shall consist of zero, one or more octets.
17.1.2	Use of TC
The mapping of OPERATION and ERROR to TC components is defined in ETS 300 287 (version 2) which is based on ITU-T Recommendation Q.773.
NOTE 1:	The class of an operation is not stated explicitly but is specified as well in the ASN.1 operation definition.
	Class 1: RESULT and ERROR appear in ASN.1 operation definition.
	Class 2: only ERROR appears in ASN.1 operation definition.
	Class 3: only RESULT appears in ASN.1 operation definition.
	Class 4: both RESULT and ERROR do not appear in ASN.1 operation definition.
The field "ARGUMENT", "PARAMETER" or "RESULT" (for information objects of class OPERATION and ERROR) is always optional from a syntactic point of view. However, except when specifically mentioned with the ASN.1 comment "-- optional" , the "parameter" part of a component has to be considered as mandatory from a semantic point of view.
When an optional element is missing in an invoke component or in an inner data structure while it is required by the context, an error component is returned if specified in the information object associated with the operation ; the associated type of error is "DataMissing". This holds also when the entire parameter of an invoke component is missing while it is required by the context.
NOTE 2:	When a mandatory element is missing in the parameter or inner data structure of any component, a reject component is returned (if the dialogue still exists). The problem code to be used is "Mistyped parameter".
The Timer Values used in the operation definitions are indicated as ASN.1 comments. The Timer Value Ranges are:
s	= from 3 seconds to 10 seconds;
m	= from 15 seconds to 30 seconds;
ml	= from 1 minute to 10 minutes;
l	= from 28 hours to 38 hours.
17.1.2.1	Use of Global Operation and Error codes defined outside MAP
An entity supporting an application context greater than 2 shall be capable of receiving an operation or error code, within an application context defined in GSM 29.002, encoded as either an Object Identifier (as defined in ITU-T Recommendation X.690 ) or an integer value (as defined in clause 17.5). Related restrictions regarding the use of Object Identifiers are as follows:
-	The length of the Object Identifier shall not exceed 16 octets and the number of components of the Object Identifier shall not exceed 16.
-	Object Identifiers shall be used only for operations or errors defined outside of GSM 29.002.
-	Global error codes may be sent only in response to a global operation. If a standard operation is received then a global error code shall not be sent in response.
Handling of an unknown operation codes by the receiving entity is defined in clause 15.1.1.
17.1.3	Use of information elements defined outside MAP
An information element or a set of information elements (messages) transparently carried in the Mobile Application Part but defined in other recommendations/technical specifications are handled in one of the following ways:
i)	The contents of each information element (without the octets encoding the identifier and the length in the recommendation/technical specification where it is defined unless explicitly stated otherwise) is carried as the value of an ASN.1 type derived from the OCTET STRING data type. Additionally, the internal structure may be explained by means of comments. In case of misalignment the referred to recommendation/technical specification takes precedence.
ii)	The complete information element (including the octets encoding the identifier and the length in the recommendation/technical specification where it is defined) or set of information elements and the identity of the associated protocol are carried as the value of the ExternalSignalInfo data type defined in the present document. Where more than one information element is carried, the information elements are sent contiguously with no filler octets between them.
17.1.4	Compatibility considerations
The following ASN.1 modules conform to ITU-T Recommendation X.680 and X.681 . An extension marker ("...") is used wherever future protocol extensions are foreseen.
The "..." construct applies only to SEQUENCE and ENUMERATED data types. An entity supporting a version greater than 1 shall not reject an unsupported extension following "..." of that SEQUENCE or ENUMERATED data type. The Encoding Rules from clause 17.1.1 apply to every element of the whole Transfer Syntax especially to the ASN.1 type EXTERNAL.
The extension container "privateExtensionList" is defined in this specification in order to carry extensions which are defined outside this specification. Private extensions can be defined by, for example, network operators, manufacturers, and regional standardisation bodies.
Private extensions shall:
1)	if included in operations of an AC of V2, follow the extension marker and be tagged using PRIVATE tags up to and including 29.
NOTE: This type of extension is in most cases used only within a PLMN.
2)	if included in operations of an AC of V3 or higher: be included only in the Private Extension Container that is defined in the specification.
NOTE: This type of extension can be used between PLMNs.
Private extensions shall not be included in v2 supplementary service operations.
Private extensions shall not be included within user error for RegisterCCEntry and EraseCCEntry operations.
PCS extensions shall be included in the PCS Extension Container that is defined in this specification.
In order to improve extensibility, a few error parameters have been defined as a CHOICE between the version 2 description and a SEQUENCE including the version 2 description and an extension container. Operations used in a v2-application-context must consider only the first alternative while operations used in a vn-application-context (n>2) must consider only the second alternative.
17.1.5	Structure of the Abstract Syntax of MAP
For each MAP parameter which has to be transferred by a MAP Protocol Data Unit (MAP message), there is a PDU field (an ASN.1 type) which has the same name as the corresponding parameter, except for the differences required by the ASN.1 notation (blanks between words are removed or replaced by hyphen, the first letter of the first word is capital and the first letter of each of the following words ise capitalised, e.g. "no reply condition time" is mapped to "NoReplyConditionTime"). Additionally some words may be abbreviated as follows:
bs	basic service
ch	call handling
cug	closed user group
ho	handover
ic	incoming call
id	identity
info	information
mm	mobility management
lcs	location services
ms	mobile service
oc	outgoing call
om	operation & maintenance
pw	Password
sm	short message service
ss	supplementary service 
The MAP protocol is composed of several ASN.1 modules dealing with either operations, errors, data types, and, if applicable, split into those dealing with mobile services, call handling services, supplementary services and short message services. For operations and errors the code values are given as parameters,  in order to allow use of the defined information objects also by other protocols (e.g. 3GPP TS 24.080 [38]). The ASN.1 source lines are preceded by line-numbers at the left margin in order to enable the usage of the cross-reference in annex A.
The module containing the definition of the operation packages for MAP is:
1.	MAP-OperationPackages.
The module containing the definition of the application contexts for MAP is:
2.	MAP-ApplicationContexts.
The module containing the data types for the Abstract Syntax to be used for TCAPMessages.DialoguePortion for MAP is:
3.	MAP-DialogueInformation.
The module containing the supported operations  is:
4.	MAP-Protocol.
The modules containing all operation definitions for MAP are:
5.	MAP-MobileServiceOperations;
6.	MAP-OperationAndMaintenanceOperations;
7.	MAP-CallHandlingOperations;
8.	MAP-SupplementaryServiceOperations;
9.	MAP-ShortMessageServiceOperations;
10.	MAP-Group-Call-Operations;
11.	MAP-LocationServiceOperations.
The module containing all error definitions for MAP is:
12.	MAP-Errors.
Modules containing all data type definitions for MAP are:
13.	MAP-MS-DataTypes;
14.	MAP-OM-DataTypes;
15.	MAP-CH-DataTypes;
16.	MAP-SS-DataTypes;
17.	MAP-SS-Code;
18.	MAP-SM-DataTypes;
19.	MAP-ER-DataTypes;
20.	MAP-CommonDataTypes;
21.	MAP-TS-Code;
22.	MAP-BS-Code;
23.	MAP-ExtensionDataTypes;
24.	MAP-GR-DataTypes;
25.	MAP-LCS-DataTypes.
References are made also to modules defined outside of the present document. They are defined in the technical specification Mobile Services Domain, technical specification Transaction Capability and ITU-T Recommendation X.880 respectively:
MobileDomainDefinitions;
TCAPMessages, DialoguePDUs ;
Remote-Operations-Information-Objects.
17.1.6	Application Contexts
The following informative table lists the latest versions of the Application Contexts used in this specification, with the operations used by them and, where applicable, whether or not the operation description is exactly the same as for previous versions. Information in 17.6 & 17.7 relates only to the ACs in this table.

AC Name
AC Version
Operations Used
Comments
locationCancellationContext
v3
cancelLocation

equipmentMngtContext
V3
checkIMEI

imsiRetrievalContext
v2
sendIMSI

infoRetrievalContext
v3
sendAuthenticationInfo

interVlrInfoRetrievalContext
v3
sendIdentification

handoverControlContext
v3
prepareHandover
forwardAccessSignalling
sendEndSignal
processAccessSignalling
prepareSubsequentHandover
the syntax of this operation has been extended in comparison with release 98 version
mwdMngtContext
v3
readyForSM

msPurgingContext
v3
purgeMS

shortMsgAlertContext
v2
alertServiceCentre

resetContext
v3
reset

networkUnstructuredSsContext
v2
processUnstructuredSS-Request
unstructuredSS-Request
unstructuredSS-Notify

tracingContext
v3
activateTraceMode
deactivateTraceMode

networkFunctionalSsContext
v2
registerSS
eraseSS
activateSS
deactivateSS
registerPassword
interrogateSS
getPassword

shortMsgMO-RelayContext
v3
mo-forwardSM

shortMsgMT-RelayContext
v3
mt-forwardSM

shortMsgMT-VGCS-RelayContext
v3
mt-forwardSM-VGCS

shortMsgGatewayContext
v3
sendRoutingInfoForSM
reportSM-DeliveryStatus
InformServiceCentre
the syntax of this operation has been extended in comparison with release 96 version
networkLocUpContext
v3
updateLocation
forwardCheckSs-Indication
restoreData
insertSubscriberData
activateTraceMode
the syntax is the same in v1 & v2

gprsLocationUpdateContext
v3
updateGprsLocation
insertSubscriberData
activateTraceMode

subscriberDataMngtContext
v3
insertSubscriberData
deleteSubscriberData

roamingNumberEnquiryContext
v3
provideRoamingNumber

locationInfoRetrievalContext
v3
sendRoutingInfo

gprsNotifyContext
v3
noteMsPresentForGprs

gprsLocationInfoRetrievalContext
v4
sendRoutingInfoForGprs

failureReportContext
v3
failureReport

callControlTransferContext
v4
resumeCallHandling

subscriberInfoEnquiryContext
v3
provideSubscriberInfo

anyTimeEnquiryContext
v3
anyTimeInterrogation

anyTimeInfoHandlingContext
v3
anyTimeSubscriptionInterrogation
anyTimeModification

ss-InvocationNotificationContext
v3
ss-InvocationNotification

groupCallControlContext
v3
prepareGroupCall
processGroupCallSignalling
forwardGroupCallSignalling
sendGroupCallEndSignal

reportingContext
v3
setReportingState
statusReport
remoteUserFree

callCompletionContext
v3
registerCC-Entry
eraseCC-Entry

istAlertingContext
v3
istAlert

ServiceTerminationContext
v3
istCommand

locationSvcEnquiryContext
v3
provideSubscriberLocation
subscriberLocationReport

locationSvcGatewayContext
v3
sendRoutingInfoForLCS

mm-EventReportingContext
v3
noteMM-Event

subscriberDataModificationNotificationContext
v3
noteSubscriberDataModified

authenticationFailureReportContext
v3
authenticationFailureReport

resourceManagementContext
v3
releaseResources

groupCallInfoRetievalContext
v3
sendGroupCallInfo

vcsgLocationUpdateContext
v3
updateVcsgLocation
insertSubscriberData

vcsgLocationCancelContext
v3
cancelVcsgLocation


NOTE (*):	The syntax of the operations is not the same as in previous versions unless explicitly stated
In the word-text of ASN.1 Modules hidden text is used for marking the begin (.$modulename), interrupt (.#), continuation (.$) and end (.#END) of ASN.1 Source. This allows to automatically extract the ASN.1 Sources. These markers should not be deleted! In addition, hidden text is also used to overcome some compiler restrictions
In addition no line break should occur when printing a paragraph in ASN.1 source, otherwise the line-numbering of word is inconsistent with the line-numbering in Annex A.
For Completeness the module MAP-Frame is included as hidden text.
.$MAP-Frame

DEFINITIONS ::=

BEGIN

IMPORTS
	Component,
	TCMessage
FROM TCAPMessages

	dialogue-as-id,
	DialoguePDU
FROM DialoguePDUs

	updateLocation
FROM MAP-Protocol

	map-DialogueAS,
	MAP-DialoguePDU
FROM MAP-DialogueInformation

	map-ac
FROM MAP-ApplicationContexts
;


ZZZZ-Dummy ::= NULL

.#END
17.2	Operation packages
17.2.1	General aspects
This clause describes the operation-packages which are used to build the application-contexts defined in clause 17.3.
Each operation-package is a specification of the roles of a pair of communicating objects (i.e. a pair of MAP-Providers), in terms of operations which they can invoke of each other.
The grouping of operations into one or several packages does not necessarily imply any grouping in terms of Application Service Elements.
The following ASN.1 information object class is used to describe operation-packages in this clause:
OPERATION-PACKAGE ::= CLASS {
	&Both     OPERATION     	OPTIONAL,
	&Consumer OPERATION     	OPTIONAL,
	&Supplier OPERATION     	OPTIONAL,
	&id       OBJECT IDENTIFIER	UNIQUE OPTIONAL } 
WITH SYNTAX {
	[ OPERATIONS       &Both ]
	[ CONSUMER INVOKES &Supplier ]
	[ SUPPLIER INVOKES &Consumer ]
	[ ID               &id ] }

Since the application-context definitions provided in clause 17.3 use only an informal description technique, only the type notation is used in the following clauses to define operation-packages.
The following definitions are used throughout this clause (n>=2):
-	v1-only operation: An operation which shall be used only in v1 application-contexts;
-	vn-only operation: An operation which shall be used only in vn application-contexts;
-	v(n-1)-operation: An operation whose specification has not been modified since the MAP v(n-1) specifications or if the modifications are considered as not affecting v(n-1) implementations;
-	v(n-1)-equivalent operation: The version of an operation which excludes all the information elements and errors which have been added since the MAP v(n-1) specification;
-	vn-only package: An operation package which contains only vn-only operations;
-	v(n-1)-package: An operation package which contains only v(n-1)- operations.
The names of vn-packages are suffixed by "-vn" where n>=2.
For each operation package which is not vn-only (n>=2) and which does not include only v(n-1)-operations, there is a v(n-1)-equivalent package. Except when a definition is explicitly provided in the following clauses, the v(n‑1)‑equivalent package includes the v(n-1)-equivalent operations of the operations which belong to this package.
17.2.2	Packages specifications
17.2.2.1	Location updating
This operation package includes the operations required for location management procedures between HLR and VLR.
locationUpdatingPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is VLR
	CONSUMER INVOKES {
	updateLocation}
	SUPPLIER INVOKES {
	forwardCheckSs-Indication} }

The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clause 17.2.1.
17.2.2.2	Location cancellation
This operation package includes the operations required for location cancellation and MS purging procedures between HLR and VLR and between HLR and SGSN.
locationCancellationPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is VLR or SGSN if Consumer is HLR
	CONSUMER INVOKES {
	cancelLocation} }

The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clause 17.2.1.
17.2.2.3	Roaming number enquiry
This operation package includes the operations required for roaming number enquiry procedures between HLR or old VLR and VLR.
roamingNumberEnquiryPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is VLR if Consumer is HLR or old VLR
	CONSUMER INVOKES {
	provideRoamingNumber} }

The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clause 17.2.1.
17.2.2.4	Information retrieval
This operation package includes the operation required for the authentication information retrieval procedure between HLR and VLR and between HLR and SGSN.
infoRetrievalPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is VLR
	-- Supplier is HLR if Consumer is SGSN
	CONSUMER INVOKES {
	sendAuthenticationInfo} }

The v2-equivalent package is defined as follows:
infoRetrievalPackage-v2  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is VLR
	-- Supplier is HLR if Consumer is SGSN
	CONSUMER INVOKES {
	sendAuthenticationInfo} }

The v1-equivalent package is defined as follows:
infoRetrievalPackage-v1  OPERATION-PACKAGE ::= {
	-- Supplier is HLR or VLR if Consumer is VLR
	-- Supplier is HLR if Consumer is SGSN
	CONSUMER INVOKES {
	sendParameters} }

17.2.2.5	Inter-VLR information retrieval
This operation package includes the operations required for inter VLR information retrieval procedures.
interVlrInfoRetrievalPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is VLR if Consumer is VLR
	CONSUMER INVOKES {
	sendIdentification} }

The v2-equivalent package is defined as follows:
interVlrInfoRetrievalPackage-v2  OPERATION-PACKAGE ::= {
	-- Supplier is VLR if Consumer is VLR
	CONSUMER INVOKES {
	sendIdentification} }

The v1-equivalent package is : infoRetrievalPackage-v1.
17.2.2.6	IMSI retrieval
This operation package includes the operation required for the IMSI retrieval procedure between HLR and VLR.
imsiRetrievalPackage-v2  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is VLR
	CONSUMER INVOKES {
	sendIMSI} }

This package is v2 only.
17.2.2.7	Call control transfer
This operation package includes the operation required for the call control transfer procedure between VMSC and GMSC.
callControlTransferPackage-v4  OPERATION-PACKAGE ::= {
	-- Supplier is GMSC if Consumer is VMSC
	CONSUMER INVOKES {
	resumeCallHandling} }

The v3-equivalent package can be determined according to the rules described in clause 17.2.1.
17.2.2.8	Void
17.2.2.9	Void
17.2.2.10	Interrogation
This operation package includes the operations required for interrogation procedures between MSC and HLR or NPLR or between HLR and gsmSCF.
interrogationPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is HLR or NPLR if Consumer is MSC
	-- Supplier is HLR if Consumer is gsmSCF
	CONSUMER INVOKES {
	sendRoutingInfo} }

The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clause 17.2.1.
17.2.2.11	Void
17.2.2.12	Handover Control
This operation package includes the operations required for handover procedures between MSCs.
handoverControlPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is MSCB if Consumer is MSCA
	CONSUMER INVOKES {
	prepareHandover |
	forwardAccessSignalling}
	SUPPLIER INVOKES {
	sendEndSignal |
	processAccessSignalling |
	prepareSubsequentHandover} }

The v2-equivalent package can be determined according to the rules described in clause 17.2.1.
The v1-equivalent package is defined as follows.
handoverControlPackage-v1  OPERATION-PACKAGE ::= {
	-- Supplier is MSCB if Consumer is MSCA
	CONSUMER INVOKES {
	performHandover |
	forwardAccessSignalling |
	traceSubscriberActivity}
	SUPPLIER INVOKES {
	sendEndSignal |
	noteInternalHandover |
	processAccessSignalling |
	performSubsequentHandover} }

17.2.2.13	Subscriber Data management stand alone
This operation package includes the operations required for stand alone subscriber data management procedures between HLR and VLR or between HLR and SGSN. Also this operation package includes the operations required for stand alone subscriber data management procedures between CSS and VLR or between CSS and SGSN. For the CSS – VLR interface and CSS – SGSN interface only version 3 of this operation package is applicable.
subscriberDataMngtStandAlonePackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is VLR or SGSN if Consumer is HLR or CSS
	CONSUMER INVOKES {
	insertSubscriberData |
	deleteSubscriberData} }

The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clause 17.2.1.
17.2.2.14	Equipment management
This operation package includes the operations required for equipment management procedures between EIR and MSC or between EIR and SGSN.
equipmentMngtPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is EIR if Consumer is MSC
	-- Supplier is EIR if Consumer is SGSN
	CONSUMER INVOKES {
	checkIMEI} }

The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clause 17.2.1.
17.2.2.15	Subscriber data management
This operation package includes the operations required for subscriber data management procedures between HLR and VLR or between HLR and SGSN. Also this operation package includes the operations required for subscriber data management procedures between CSS and VLR or between CSS and SGSN. For the CSS – VLR interface and CSS – SGSN interface only version 3 of this operation package is applicable.
subscriberDataMngtPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is VLR or SGSN if Consumer is HLR or CSS
	CONSUMER INVOKES {
	insertSubscriberData} }

The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clause 17.2.1.
17.2.2.16	Location register restart
This operation package includes the operations required for location register restart procedures between HLR and VLR or between HLR and SGSN and also between CSS and VLR or between CSS and SGSN.
resetPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is VLR or SGSN if Consumer is HLR or CSS
	CONSUMER INVOKES {
	reset} }

The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clause 17.2.1.
For CSS-VLR interface and CSS-SGSN interface, only version 3 of this operation package is applicable.
17.2.2.17	Tracing stand-alone
This operation package includes the operations required for stand alone tracing procedures between HLR and VLR or between HLR and SGSN.
tracingStandAlonePackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is VLR or SGSN if Consumer is HLR
	CONSUMER INVOKES {
	activateTraceMode |
	deactivateTraceMode} }

The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clause 17.2.1.
17.2.2.18	Functional SS handling
This operation package includes the operations required for functional supplementary services procedures between VLR and HLR.
functionalSsPackage-v2  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is VLR
	CONSUMER INVOKES {
	registerSS |
	eraseSS |
	activateSS |
	deactivateSS |
	registerPassword |
	interrogateSS}
	SUPPLIER INVOKES {
	getPassword} }

The v1-equivalent package can be determined according to the rules described in clause 17.2.1.
17.2.2.19	Tracing
This operation package includes the operations required for tracing procedures between HLR and VLR or between HLR and SGSN.
tracingPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is VLR or SGSN if Consumer is HLR
	CONSUMER INVOKES {
	activateTraceMode} }

The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clause 17.2.1.
17.2.2.20	Binding
This operation package includes the operation required to initialise a supplementary service procedure between VLR and HLR or between gsmSCF and HLR.
bindingPackage-v1  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is VLR
	-- Supplier is gsmSCF if Consumer is HLR
	CONSUMER INVOKES {
	beginSubscriberActivity} }
This package is v1 only.
17.2.2.21	Unstructured SS handling
This operation package includes the operations required for unstructured supplementary services procedures between VLR and HLR, between the HLR and the gsmSCF, and between HLR and HLR.
unstructuredSsPackage-v2  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is VLR
	-- Supplier is gsmSCF or HLR if Consumer is HLR
	CONSUMER INVOKES {
	processUnstructuredSS-Request}
	SUPPLIER INVOKES {
	unstructuredSS-Request |
	unstructuredSS-Notify} }

The v1-equivalent package is defined as follows:
unstructuredSsPackage-v1  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is VLR
	-- Supplier is gsmSCF if Consumer is HLR
	CONSUMER INVOKES {
	processUnstructuredSS-Data} }

17.2.2.22	MO Short message relay services
This operation package includes the operations required for short message relay service procedures between IWMSC and VMSC or between GMSC and MSC or between SGSN and IWMSC.
mo-ShortMsgRelayPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is IWMSC if Consumer is MSC
	-- Supplier is IWMSC if Consumer is SGSN
	CONSUMER INVOKES {
	mo-forwardSM} }

The v2-equivalent package is defined as follows:
shortMsgRelayPackage-v2  OPERATION-PACKAGE ::= {
	-- Supplier is IWMSC if Consumer is MSC
	-- Supplier is MSC or SGSN if Consumer is GMSC
	-- Supplier is IWMSC if Consumer is SGSN
	CONSUMER INVOKES {
	forwardSM} }

The v1-equivalent package can be determined according to the rules described in clause 17.2.1.
17.2.2.23	Short message gateway services
This operation package includes the operations required for short message service gateway procedures between MSC and HLR.
shortMsgGatewayPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is GMSC
	CONSUMER INVOKES {
	sendRoutingInfoForSM |
	reportSM-DeliveryStatus}
	SUPPLIER INVOKES {
	informServiceCentre} }

The v2-equivalent package can be determined according to the rules described in clause 17.2.1.
The v1-equivalent package is defined as follows:
shortMsgGatewayPackage-v1  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is GMSC
	CONSUMER INVOKES {
	sendRoutingInfoForSM |
	reportSMDeliveryStatus} }

17.2.2.24	MT Short message relay services
This operation package includes the operations required for short message relay service procedures between GMSC and MSC or between GMSC and SGSN.
mt-ShortMsgRelayPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is MSC or SGSN or SMS-Router or IP-SM-GW if Consumer is GMSC
	CONSUMER INVOKES {
	mt-forwardSM} }

The v2-equivalent package is: shortMsgRelayPackage-v2
17.2.2.25	Void
17.2.2.26	Message waiting data management
This operation package includes the operations required for short message waiting data procedures between HLR and VLR, between HLR and SGSN.
mwdMngtPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is SGSN
	-- Supplier is HLR if Consumer is VLR
	CONSUMER INVOKES {
	readyForSM} }

The v2-equivalent package can be determined according to the rules described in clause 17.2.1.

The v1-equivalent package is defined as follows:
mwdMngtPackage-v1  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is VLR
	CONSUMER INVOKES {
	noteSubscriberPresent} }

17.2.2.27	Alerting
This operation package includes the operations required for alerting between HLR and IWMSC.
alertingPackage-v2  OPERATION-PACKAGE ::= {
	-- Supplier is IWMSC if Consumer is HLR
	CONSUMER INVOKES {
	alertServiceCentre} }

The v1-equivalent package is defined as follows.
alertingPackage-v1  OPERATION-PACKAGE ::= {
	-- Supplier is IWMSC if Consumer is HLR
	CONSUMER INVOKES {
	alertServiceCentreWithoutResult} }

17.2.2.28	Data restoration
This operation package includes the operations required for VLR data restoration between HLR and VLR.
dataRestorationPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is VLR
	CONSUMER INVOKES {
	restoreData} }

The v2-equivalent package can be determined according to the rules described in clause 17.2.1.
The v1-equivalent package is: infoRetrievalPackage-v1
17.2.2.29	Purging
This operation package includes the operations required for purging between HLR and VLR or between HLR and SGSN.
purgingPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is VLR
	-- Supplier is HLR if Consumer is SGSN
	CONSUMER INVOKES {
	purgeMS} }

The v2-equivalent package can be determined according to the rules described in clause 17.2.1.
17.2.2.30	Subscriber information enquiry
This operation package includes the operations required for subscriber information enquiry procedures between HLR and VLR or between HLR and SGSN.
subscriberInformationEnquiryPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is VLR or SGSN if Consumer is HLR
	CONSUMER INVOKES {
	provideSubscriberInfo} }

This package is v3 only.
17.2.2.31	Any time information enquiry
This operation package includes the operations required for any time information enquiry procedures between gsmSCF and HLR or between gsmSCF and GMLC or between gsmSCF and NPLR.
anyTimeInformationEnquiryPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is HLR or GMLC or NPLR if Consumer is gsmSCF
	CONSUMER INVOKES {
	anyTimeInterrogation} }

This package is v3 only.
17.2.2.32	Group Call Control
This operation package includes the operations required for group call and broadcast call procedures between MSCs.
groupCallControlPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is relay MSC if Consumer is anchor MSC
	CONSUMER INVOKES {
	prepareGroupCall |
	forwardGroupCallSignalling}
	SUPPLIER INVOKES {
	sendGroupCallEndSignal |
	processGroupCallSignalling} }

This package is v3 only.
17.2.2.32A	Group Call Info Retrieval
This operation package includes the operations required for group call and broadcast call info retrieval between MSCs.
groupCallInfoRetrievalPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is group call serving MSC if Consumer is visited MSC
	-- Supplier is visited MSC if Consumer is group call serving MSC
	CONSUMER INVOKES {
	sendGroupCallInfo} }

This package is v3 only.
17.2.2.33	Void
17.2.2.34	Void
17.2.2.35	Gprs location updating
This operation package includes the operations required for the gprs location management procedures between HLR and SGSN.
gprsLocationUpdatingPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is SGSN
	CONSUMER INVOKES {
	updateGprsLocation} }

This package is v3 only.
17.2.2.36	Gprs Interrogation
This operation package includes the operations required for interrogation procedures between HLR and GGSN. 
gprsInterrogationPackage-v4  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is GGSN
	CONSUMER INVOKES {
	sendRoutingInfoForGprs} }

The v3-equivalent package is defined as follows.

gprsInterrogationPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is GGSN
	CONSUMER INVOKES {
	sendRoutingInfoForGprs} }

17.2.2.37	Failure reporting
This operation package includes the operations required for failure reporting between HLR and GGSN.
failureReportingPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is GGSN
	CONSUMER INVOKES {
	failureReport} }

This package is v3 only.
17.2.2.38	GPRS notifying
This operation package includes the operations required for notifying that GPRS subscriber is present between HLR and GGSN.
gprsNotifyingPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is GGSN if Consumer is HLR
	CONSUMER INVOKES {
	noteMsPresentForGprs} }

This package is v3 only.
17.2.2.39	Supplementary Service invocation notification
This operation package includes the operations required for Supplementary Service invocation notification procedures between the MSC and the gsmSCF and between the HLR and the gsmSCF.
ss-InvocationNotificationPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is gsmSCF if Consumer is MSC
	-- Supplier is gsmSCF if Consumer is HLR
	CONSUMER INVOKES {
	ss-InvocationNotification} }

This package is v3 only.
17.2.2.40	Set Reporting State
This operation package includes the operation required for procedures between HLR and VLR to set the reporting state.
setReportingStatePackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is VLR if Consumer is HLR
	CONSUMER INVOKES {
	setReportingState} }      

This package is v3 only.
17.2.2.41	Status Report
This operation package includes the operation required for procedures between VLR and HLR to report call results and events.
statusReportPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is VLR
	CONSUMER INVOKES {
	statusReport} }     

This package is v3 only.
17.2.2.42	Remote User Free
This operation package includes the operation required by the HLR to indicate to the VLR that the remote user is free.
remoteUserFreePackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is VLR if Consumer is HLR
	CONSUMER INVOKES {
	remoteUserFree} }     

This package is v3 only.
17.2.2.43	Call Completion
This operation package includes the operations required for procedures between VLR and HLR for subscriber control of call completion services.
callCompletionPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is VLR
	CONSUMER INVOKES {
	registerCC-Entry |
	eraseCC-Entry} }

This package is v3 only.
17.2.2.44	Location service gateway services
This operation package includes the operations required for location service gateway procedures between GMLC and HLR.
locationSvcGatewayPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is GMLC
	CONSUMER INVOKES {
	sendRoutingInfoForLCS} }

This package is v3 only.
17.2.2.45	Location service enquiry
This operation package includes the operations required for the location service enquiry procedures between GMLC and MSC and between GMLC and SGSN.
locationSvcEnquiryPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is MSC or SGSN if Consumer is GMLC
	CONSUMER INVOKES {
	provideSubscriberLocation} }

This package is v3 only.
17.2.2.45A	Location service reporting
This operation package includes the operations required for the location service enquiry procedures between MSC and GMLC and between SGSN and GMLC.
locationSvcReportingPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is GMLC if Consumer is MSC
	-- Supplier is GMLC if Consumer is SGSN
	CONSUMER INVOKES {
	subscriberLocationReport} }

17.2.2.46	Void
17.2.2.47	Void
17.2.2.48	Void
17.2.2.49	IST Alerting
This operation package includes the operation required for alerting procedures between the MSC (Visited MSC or Gateway MSC) and HLR.
ist-AlertingPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is VMSC
	-- Supplier is HLR if Consumer is GMSC
	CONSUMER INVOKES {
	istAlert} }

This package is v3 only.
17.2.2.50	Service Termination
This operation package includes the operation required for immediate service termination procedures between the HLR and the Visited MSC or between the HLR and the Gateway MSC.
serviceTerminationPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is VMSC or GMSC if Consumer is HLR
	CONSUMER INVOKES {
	istCommand} }

This package is v3 only. 
17.2.2.51	Mobility Management event notification
This operation package includes the operations required for Mobility Management event notification procedures between VLR and gsmSCF.
mm-EventReportingPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is gsmSCF if Consumer is VLR
	CONSUMER INVOKES {
	noteMM-Event} }
This package is v3 only.
17.2.2.52	Any time information handling
This operation package includes the operations required for any time information handling procedures between gsmSCF and HLR.
anyTimeInformationHandlingPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is gsmSCF
	CONSUMER INVOKES {
	anyTimeSubscriptionInterrogation |
	anyTimeModification} }

This package is v3 only.
17.2.2.53	Subscriber Data modification notification
This operation package includes the operations required for Subscriber Data modification notification procedures between HLR and gsmSCF.
subscriberDataModificationNotificationPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is gsmSCF if Consumer is HLR
	CONSUMER INVOKES {
	noteSubscriberDataModified} }

This package is v3 only.
17.2.2.54	Authentication Failure Report
This operation package includes the operation required for procedures between VLR and HLR or the SGSN and the HLR for reporting of authentication failures.
authenticationFailureReportPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is HLR if Consumer is VLR
	-- Supplier is HLR if Consumer is SGSN
	CONSUMER INVOKES {
	authenticationFailureReport} }

This package is v3 only.
17.2.2.55	Resource Management
This operation package includes the operation required for procedures between GMSC and VMSC for resource management purpose.
resourceManagementPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is VMSC if Consumer is GMSC
	CONSUMER INVOKES {
	releaseResources} }

This package is v3 only.
17.2.2.56	MT Short message relay VGCS services
This operation package includes the operations required for short message relay service procedures between SMS GMSC and MSC.
mt-ShortMsgRelay-VGCS-Package-v3  OPERATION-PACKAGE ::= {
	-- Supplier is MSC if Consumer is GMSC
	CONSUMER INVOKES {
	mt-forwardSM-VGCS} }

This package is v3 only.
17.2.2.57	Vcsg location updating
This operation package includes the operations required for the vcsg location management procedures between CSS and VLR or between CSS and SGSN.
vcsgLocationUpdatingPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is CSS if Consumer is VLR or SGSN
	CONSUMER INVOKES {
	updateVcsgLocation} }

This operation package is v3 only.
17.2.2.58	Vcsg location cancellation
This operation package includes the operations required for the vcsg location cancellation procedures between CSS and VLR or between CSS and SGSN.
vcsgLocationCancellationPackage-v3  OPERATION-PACKAGE ::= {
	-- Supplier is VLR or SGSN if Consumer is CSS 
	CONSUMER INVOKES {
	cancelVcsgLocation} }

This operation package is v3 only.

17.3	Application contexts
17.3.1	General aspects
An application-context is assigned for each dialogue established by a MAP-user. In the present document each application-context is assigned a name which is supplied in the MAP-OPEN Req primitive by the MAP-User and transmitted to the peer under certain circumstances.
The following ASN.1 information object class is used to describe the main aspects of application-contexts in the following clauses:
APPLICATION-CONTEXT ::= CLASS {
	&Symmetric           OPERATION-PACKAGE OPTIONAL,
	&InitiatorConsumerOf OPERATION-PACKAGE OPTIONAL,
	&ResponderConsumerOf OPERATION-PACKAGE OPTIONAL,
	&code                OBJECT IDENTIFIER } 
WITH SYNTAX {
	[ OPERATIONS OF         &Symmetric ]
	[ INITIATOR CONSUMER OF &InitiatorConsumerOf
	RESPONDER CONSUMER OF &ResponderConsumerOf ]
	ID &code }


The following definitions are used throughout this clause:
-	v1-application-context: An application-context which contains only v1-packages and uses only TC v1 facilities;
-	v1 context set: the set of v1-application-contexts defined in the present document.
-	vn-application-context (n>=2): An application-context which contains only vn-packages;
The names of v1-application-contexts are suffixed by "-v1" while other names are suffixed by "-vn" where n>=2.
Application-contexts which do not belong to the v1 context set use v2 TC facilities.
The last component of each application-context-name (i.e. the last component of the object identifier value) assigned to an application-context which belongs to the v1 context set indicates explicitly "version1".
For each application-context which does not belong to the "v1 context set" there is a v1-equivalent application context. This is a v1-application-context which includes the v1-equivalents of the packages included in the original context.
Each application-context uses the abstract-syntax associated with the operation-packages it includes and uses the transfer-syntax derived from it by applying the encoding rules defined in clause 17.1.1.
ACs which do not belong to the v1 context set require the support of the abstract-syntax identified by the object identifier value: MAP-DialogueInformation.map-Dialogue-AS defined in clause 17.4.
17.3.2	Application context definitions
17.3.2.1	Void
17.3.2.2	Location Updating
This application context is used between HLR and VLR for location updating procedures.
networkLocUpContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is HLR if Initiator is VLR
	INITIATOR CONSUMER OF {
	locationUpdatingPackage-v3 |
	dataRestorationPackage-v3}
	RESPONDER CONSUMER OF {
	subscriberDataMngtPackage-v3 |
	tracingPackage-v3}
	ID	{map-ac networkLocUp(1) version3(3)} }

The following application-context-name is assigned to the v2-equivalent application-context:
	ID	{map-ac networkLocUp(1) version2(2)}

The following application-context-name is assigned to the v1-equivalent application-context:
	ID	{map-ac networkLocUp(1) version1(1)}

17.3.2.3	Location Cancellation
This application context is used between HLR and VLR or between HLR and SGSN for location cancellation procedures. For the HLR - SGSN interface only version 3 of this application context is applicable.
locationCancellationContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is VLR or SGSN if Initiator is HLR
	INITIATOR CONSUMER OF {
	locationCancellationPackage-v3}
	ID	{map-ac locationCancel(2) version3(3)} }

The following application-context-name is assigned to the v2-equivalent application-context:
	ID	map-ac locationCancel(2) version2(2)

The following application-context-name is assigned to the v1-equivalent application-context:
	ID	map-ac locationCancel(2) version1(1)

17.3.2.4	Roaming number enquiry
This application context is used between HLR and VLR for roaming number enquiry procedures.
roamingNumberEnquiryContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is VLR if Initiator is HLR
	INITIATOR CONSUMER OF {
	roamingNumberEnquiryPackage-v3}
	ID	{map-ac roamingNbEnquiry(3) version3(3)} }

The following application-context-name is assigned to the v2-equivalent application-context:
	ID	{map-ac roamingNbEnquiry(3) version2(2)}

The following application-context-name is assigned to the v1-equivalent application-context:
	ID	{map-ac roamingNbEnquiry(3) version1(1)}

17.3.2.5	Void
17.3.2.6	Location Information Retrieval
This application-context is used between GMSC and HLR or between GMSC and NPLR or between gsmSCF and HLR when retrieving location information. For the GMSC - NPLR interface version 1, version 2 and version 3 of this application context are applicable.
locationInfoRetrievalContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is HLR or NPLR if Initiator is GMSC
	-- Responder is HLR if Initiator is gsmSCF
	INITIATOR CONSUMER OF {
	interrogationPackage-v3}
	ID	{map-ac locInfoRetrieval(5) version3(3)} }

The following application-context-name is assigned to the v2-equivalent application-context:
	ID	{map-ac locInfoRetrieval(5) version2(2)}


The following application-context-name is assigned to the v1-equivalent application-context:
	ID	{map-ac locInfoRetrieval(5) version1(1)}

17.3.2.7	Call control transfer
This application context is used for the call control transfer procedure between the VMSC and the GMSC.
callControlTransferContext-v4 APPLICATION-CONTEXT ::= {
	-- Responder is GMSC if Initiator is VMSC
	INITIATOR CONSUMER OF {
	callControlTransferPackage-v4}
	ID	{map-ac callControlTransfer(6) version4(4)} }

The following application-context-name is assigned to the v3-equivalent application-context:
	ID	{map-ac callControlTransfer(6) version3(3)}
17.3.2.8	Void
17.3.2.9	Void
17.3.2.10	Void
17.3.2.11	Location registers restart
This application context is used between HLR and VLR or between HLR and SGSN for location register restart procedures or between CSS and VLR or between CSS and SGSN for CSG Subscriber Server restart procedures. For the HLR - VLR interface and for the HLR - SGSN interface version 1, version 2 and version 3 of this application context are applicable For the CSS - VLR interface and the CSS - SGSN interface version 3 of this application context is applicable.
resetContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is VLR or SGSN if Initiator is HLR or CSS
	INITIATOR CONSUMER OF {
	resetPackage-v3}
	ID	{map-ac reset(10) version3(3)} }

The following application-context-name is assigned to the v2-equivalent application-context:
	ID	{map-ac reset(10) version2(2)}

The following application-context-name is assigned to the v1-equivalent application-context:
	ID	{map-ac reset(10) version1(1)}

17.3.2.12	Handover control
This application context is used for handover procedures between MSCs.
handoverControlContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is MSCB if Initiator is MSCA
	INITIATOR CONSUMER OF {
	handoverControlPackage-v3}
	ID	{map-ac handoverControl(11) version3(3)} }

The following application-context-name is assigned to the v2-equivalent application-context:
	ID	{map-ac handoverControl(11) version2(2)}


The following application-context-name is assigned to the v1-equivalent application-context:
	ID	{map-ac handoverControl(11) version1(1)}

17.3.2.13	IMSI Retrieval
This application context is used for IMSI retrieval between HLR and VLR.
imsiRetrievalContext-v2 APPLICATION-CONTEXT ::= {
	-- Responder is HLR if Initiator is VLR
	INITIATOR CONSUMER OF {
	imsi-RetrievalPackage-v2}
	ID	{map-ac imsiRetrieval(26) version2(2)} }

This application-context is v2 only.
17.3.2.14	Equipment Management
This application context is used for equipment checking between MSC and EIR or between SGSN and EIR. For the SGSN - EIR interface version 1 and version 2 and version 3 of this application context are applicable: 
equipmentMngtContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is EIR if Initiator is MSC
	-- Responder is EIR if Initiator is SGSN
	INITIATOR CONSUMER OF {
	equipmentMngtPackage-v3}
	ID	{map-ac equipmentMngt(13) version3(3)} }

The following application-context-name is assigned to the v2-equivalent application-context:
equipmentMngtContext-v2 APPLICATION-CONTEXT ::= {
	-- Responder is EIR if Initiator is MSC
	-- Responder is EIR if Initiator is SGSN
	INITIATOR CONSUMER OF {
	equipmentMngtPackage-v2}
	ID	{map-ac equipmentMngt(13) version2(2)} }

The following application-context-name is assigned to the v1-equivalent application-context:
	ID	{map-ac equipmentMngt(13) version1(1)}

17.3.2.15	Information retrieval
This application context is used for authentication information retrieval between HLR and VLR or between HLR and SGSN. For the HLR - SGSN interface version 1 and version 2 and version 3 of this application context are applicable.
infoRetrievalContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is HLR if Initiator is VLR
	-- Responder is HLR if Initiator is SGSN
	INITIATOR CONSUMER OF {
	infoRetrievalPackage-v3}
	ID	{map-ac infoRetrieval(14) version3(3)} }

The following application-context-name is assigned to the v2-equivalent application-context:
infoRetrievalContext-v2 APPLICATION-CONTEXT ::= {
	-- Responder is HLR if Initiator is VLR
	-- Responder is HLR if Initiator is SGSN
	INITIATOR CONSUMER OF {
	infoRetrievalPackage-v2}
	ID	{map-ac infoRetrieval(14) version2(2)} }

The following application-context-name is assigned to the v1-equivalent application-context:
	ID	{map-ac infoRetrieval(14) version1(1)}

17.3.2.16	Inter-VLR information retrieval
This application context is used for information retrieval between VLRs. 
interVlrInfoRetrievalContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is VLR if Initiator is VLR
	INITIATOR CONSUMER OF {
	interVlrInfoRetrievalPackage-v3}
	ID	{map-ac interVlrInfoRetrieval(15) version3(3)} }

The v2-equivalent application-context is:
interVlrInfoRetrievalContext-v2 APPLICATION-CONTEXT ::= {
	-- Responder is VLR if Initiator is VLR
	INITIATOR CONSUMER OF {
	interVlrInfoRetrievalPackage-v2}
	ID	{map-ac interVlrInfoRetrieval(15) version2(2)} }

The v1-equivalent application-context is:
	ID	{map-ac infoRetrieval(14) version1(1)}

17.3.2.17	Stand Alone Subscriber Data Management
This application context is used for stand alone subscriber data management between HLR and VLR or between HLR and SGSN. For the HLR - SGSN interface only version 3 of this application context is applicable. Also this application context is used for stand alone subscriber data management between CSS and VLR or between CSS and SGSN. For the CSS – VLR interface and CSS – SGSN interface only version 3 of this application context is applicable:
subscriberDataMngtContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is VLR or SGSN if Initiator is HLR or CSS
	INITIATOR CONSUMER OF {
	subscriberDataMngtStandAlonePackage-v3}
	ID	{map-ac subscriberDataMngt(16) version3(3)} }

The following application-context-name is assigned to the v2-equivalent application-context:
	ID	{map-ac subscriberDataMngt(16) version2(2)}

The following application-context-name is assigned to the v1-equivalent application-context:
	ID	{map-ac subscriberDataMngt(16) version1(1)}

17.3.2.18	Tracing
This application context is used between HLR and VLR or between HLR and SGSN for stand alone tracing control procedures. For the HLR - SGSN interface version 1, version 2 and version 3 of this application context are applicable.
tracingContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is VLR or SGSN if Initiator is HLR
	INITIATOR CONSUMER OF {
	tracingStandAlonePackage-v3}
	ID	{map-ac tracing(17) version3(3)} }

The following application-context-name is assigned to the v2-equivalent application-context:
	ID	{map-ac tracing(17) version2(2)}

The following application-context-name is assigned to the v1-equivalent application-context:
	ID	{map-ac tracing(17) version1(1)}

17.3.2.19	Network functional SS handling
This application context is used for functional-like SS handling procedures between VLR and HLR.
networkFunctionalSsContext-v2 APPLICATION-CONTEXT ::= {
	-- Responder is HLR, Initiator is VLR
	INITIATOR CONSUMER OF {
	functionalSsPackage-v2}
	ID	{map-ac networkFunctionalSs(18) version2(2)} }

The v1-equivalent application-context is defined as follows:
networkFunctionalSsContext-v1 APPLICATION-CONTEXT ::= {
	-- Responder is HLR, Initiator is VLR
	INITIATOR CONSUMER OF {
	functionalSsPackage-v1 |
	unstructuredSsPackage-v1 |
	bindingPackage-v1}
	ID	{map-ac networkFunctionalSs(18) version1(1)} }

17.3.2.20	Network unstructured SS handling
This application context is used for handling stimuli-like procedures between HLR and VLR, between the HLR and gsmSCF, and between HLR and HLR.
networkUnstructuredSsContext-v2 APPLICATION-CONTEXT ::= {
	-- Responder is HLR, Initiator is VLR
	-- Responder is VLR, Initiator is HLR
	-- Responder is gsmSCF, Initiator is HLR
	-- Responder is HLR, Initiator is gsmSCF
	-- Responder is HLR, Initiator is HLR
	OPERATIONS OF {
	unstructuredSsPackage-v2}
	ID	{map-ac networkUnstructuredSs(19) version2(2)} }

The following application-context-name is assigned to the v1-equivalent application-context:
	ID	{map-ac networkFunctionalSs(18) version1(1)}

17.3.2.21	Short Message Gateway
This application context is used for short message gateway procedures.
shortMsgGatewayContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is HLR if Initiator is GMSC
	INITIATOR CONSUMER OF {
	shortMsgGatewayPackage-v3}
	ID	{map-ac shortMsgGateway(20) version3(3)} }

The following application-context-name is assigned to the v2-equivalent application-context:
	ID	{map-ac shortMsgGateway(20) version2(2)}

The following application-context-name is assigned to the v1-equivalent application-context:
	ID	{map-ac shortMsgGateway(20) version1(1)}

17.3.2.22	Mobile originating Short Message Relay
This application context is used between MSC and IWMSC or between SGSN and IWMSC for mobile originating short message relay procedures. For the SGSN - IWMSC interface version 1, version 2 and version 3 of this application context are applicable.
shortMsgMO-RelayContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is IWMSC if Initiator is MSC
	-- Responder is IWMSC if Initiator is SGSN
	INITIATOR CONSUMER OF {
	mo-ShortMsgRelayPackage-v3}
	ID	{map-ac shortMsgMO-Relay(21) version3(3)} }

The following application-context-name is assigned to the v2-equivalent application-context:
	ID	{map-ac shortMsgMO-Relay(21) version2(2)}

The following application-context-name is assigned to the v1-equivalent application-context:
	ID	{map-ac shortMsg-Relay(21) version1(1)}

17.3.2.23	Void
17.3.2.24	Short message alert
This application context is used for short message alerting procedures.
shortMsgAlertContext-v2 APPLICATION-CONTEXT ::= {
	-- Responder is IWMSC if Initiator is HLR
	INITIATOR CONSUMER OF {
	alertingPackage-v2}
	ID	{map-ac shortMsgAlert(23) version2(2)} }

The following application-context-name is symbolically assigned to the v1-equivalent application-context:
	ID	{map-ac shortMsgAlert(23) version1(1)}

17.3.2.25	Short message waiting data management
This application context is used between VLR and HLR or between SGSN and HLR for short message waiting data management procedures. For the SGSN - HLR interface only version 3 of this application context is applicable.
mwdMngtContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is HLR if Initiator is SGSN
	-- Responder is HLR if Initiator is VLR
	INITIATOR CONSUMER OF {
	mwdMngtPackage-v3}
	ID	{map-ac mwdMngt(24) version3(3)} }

The following application-context-name is assigned to the v2-equivalent application-context:
	ID	{map-ac mwdMngt(24) version2(2)}

The following application-context-name is assigned to the v1-equivalent application-context:
	ID	{map-ac mwdMngt(24) version1(1)}

17.3.2.26	Mobile terminating Short Message Relay
This application context is used between GMSC and MSC or between GMSC and SGSN for mobile terminating short message relay procedures. For the GMSC - SGSN interface version 2 and version 3 of this application context and the equivalent version 1 application context are applicable.
shortMsgMT-RelayContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is MSC or SGSN if Initiator is GMSC
	INITIATOR CONSUMER OF {
	mt-ShortMsgRelayPackage-v3}
	ID	{map-ac shortMsgMT-Relay(25) version3(3)} }

The following application-context-name is assigned to the v2-equivalent application-context:
	ID	{map-ac shortMsgMT-Relay(25) version2(2)}

The following application-context-name is assigned to the v1-equivalent application-context:
	ID	{map-ac shortMsg-Relay(21) version1(1)}

17.3.2.27	MS purging
This application context is used between HLR and VLR or between HLR and SGSN for MS purging procedures. For the SGSN - HLR interface only version 3 of this application context is applicable.
msPurgingContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is HLR if Initiator is VLR
	-- Responder is HLR if Initiator is SGSN
	INITIATOR CONSUMER OF {
	purgingPackage-v3}
	ID	{map-ac msPurging(27) version3(3)} }

The following application-context-name is assigned to the v2-equivalent application-context:
	ID	{map-ac msPurging(27) version2(2)}

17.3.2.28	Subscriber information enquiry
This application context is used between HLR and VLR or between HLR and SGSN for subscriber information enquiry procedures.
subscriberInfoEnquiryContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is VLR or SGSN if Initiator is HLR
	INITIATOR CONSUMER OF {
	subscriberInformationEnquiryPackage-v3}
	ID	{map-ac subscriberInfoEnquiry(28) version3(3)} }

This application-context is v3 only.
17.3.2.29	Any time information enquiry
This application context is used between gsmSCF and HLR or between gsmSCF and GMLC or between gsmSCF and NPLR for any time information enquiry procedures.
anyTimeInfoEnquiryContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is HLR or GMLC or NPLR if Initiator is gsmSCF
	INITIATOR CONSUMER OF {
	anyTimeInformationEnquiryPackage-v3}
	ID	{map-ac anyTimeInfoEnquiry(29) version3(3)} }

This application-context is v3 only.
17.3.2.30	Group Call Control
This application context is used between anchor MSC and relay MSC for group call and broadcast call procedures.
groupCallControlContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is relay MSC if Initiator is anchor MSC
	INITIATOR CONSUMER OF {
	groupCallControlPackage-v3}
	ID	{map-ac groupCallControl(31) version3(3)} }

This application-context is v3 only.
17.3.2.30A	Group Call Info Retrieval
This application context is used between group call serving MSC and visited MSC for group call and broadcast call procedures.
groupCallInfoRetControlContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is group call serving MSC if Initiator is visited MSC
	-- Responder is visited MSC if Initiator is group call serving MSC
	INITIATOR CONSUMER OF {
	groupCallInfoRetrievalPackage-v3}
	ID	{map-ac groupCallInfoRetrieval(45) version3(3)} }

This application-context is v3 only.
17.3.2.31	Void
17.3.2.32	Gprs Location Updating
This application context is used between HLR and SGSN for gprs location updating procedures.
gprsLocationUpdateContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is HLR if Initiator is SGSN
	INITIATOR CONSUMER OF {
	gprsLocationUpdatingPackage-v3}
	RESPONDER CONSUMER OF {
	subscriberDataMngtPackage-v3 |
	tracingPackage-v3}
	ID	{map-ac gprsLocationUpdate(32) version3(3)} }

This application-context is v3 only.
17.3.2.33	Gprs Location Information Retreival
This application context is used between HLR and GGSN when retrieving gprs location information.
gprsLocationInfoRetrievalContext-v4 APPLICATION-CONTEXT ::= {
	-- Responder is HLR if Initiator is GGSN
	INITIATOR CONSUMER OF {
	gprsInterrogationPackage-v4}
	ID	{map-ac gprsLocationInfoRetrieval(33) version4(4)} }

The following application-context-name is assigned to the v3-equivalent application-context:
	ID	{map-ac gprsLocationInfoRetrieval(33) version3(3)}


17.3.2.34	Failure Reporting
This application context is used between HLR and GGSN to inform that network requested PDP-context activation has failed.
failureReportContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is HLR if Initiator is GGSN
	INITIATOR CONSUMER OF {
	failureReportingPackage-v3}
	ID	{map-ac failureReport(34) version3(3)} }

This application-context is v3 only.
17.3.2.35	GPRS Notifying
This application context is used between HLR and GGSN for notifying that GPRS subscriber is present again.
gprsNotifyContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is GGSN if Initiator is HLR
	INITIATOR CONSUMER OF {
	gprsNotifyingPackage-v3}
	ID	{map-ac gprsNotify(35) version3(3)} }

This application-context is v3 only.
17.3.2.36	Supplementary Service invocation notification
This application context is used between the MSC and the gsmSCF and between the HLR and the gsmSCF for Supplementary Service invocation notification procedures.
ss-InvocationNotificationContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is gsmSCF, Initiator is MSC
	-- Responder is gsmSCF, Initiator is HLR
	INITIATOR CONSUMER OF {
	ss-InvocationNotificationPackage-v3} 
	ID	{map-ac ss-InvocationNotification(36) version3(3)} }

This application-context is v3 only.
17.3.2.37	Reporting
This application context is used between HLR and VLR for reporting procedures.
reportingContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is VLR if Initiator is HLR
	-- Responder is HLR if Initiator is VLR
	INITIATOR CONSUMER OF {
	setReportingStatePackage-v3 |
	statusReportPackage-v3 |
	remoteUserFreePackage-v3}
	RESPONDER CONSUMER OF {
	setReportingStatePackage-v3 |
	statusReportPackage-v3}
	ID	{map-ac reporting(7) version3(3)} }

This application-context is v3 only.
17.3.2.38	Call Completion
This application context is used between VLR and the HLR for subscriber control of call completion services.
callCompletionContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is HLR if Initiator is VLR
	INITIATOR CONSUMER OF {
	callCompletionPackage-v3}
	ID	{map-ac callCompletion(8) version3(3)} }

This application-context is v3 only.
17.3.2.39	Location Service Gateway
This application context is used for location service gateway procedures.
locationSvcGatewayContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is HLR if Initiator is GMLC
	INITIATOR CONSUMER OF {
	locationSvcGatewayPackage-v3}
	ID	{map-ac locationSvcGateway(37) version3(3)} }

17.3.2.40	Location Service Enquiry
This application context is used for location service enquiry procedures.
locationSvcEnquiryContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is MSC or SGSN if Initiator is GMLC
	-- Responder is GMLC if Initiator is MSC
	-- Responder is GMLC if Initiator is SGSN
	INITIATOR CONSUMER OF {
	locationSvcEnquiryPackage-v3 |
	locationSvcReportingPackage-v3}
	ID	{map-ac locationSvcEnquiry(38) version3 (3)} }

17.3.2.41	Void
17.3.2.42	Void
17.3.2.43	Void
17.3.2.44	IST Alerting
This application context is used between MSC (Visited MSC or Gateway MSC) and HLR for alerting services within IST procedures.
istAlertingContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is HLR if Initiator is VMSC
	-- Responder is HLR if Initiator is GMSC
	INITIATOR CONSUMER OF {
	ist-AlertingPackage-v3}
	ID	{map-ac alerting(4) version3(3)} }

This application-context is v3 only.
17.3.2.45	Service Termination
This application context is used between HLR and MSC (Visited MSC or Gateway MSC) for service termination services within IST procedures.
serviceTerminationContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is VMSC or GMSC if Initiator is HLR
	INITIATOR CONSUMER OF {
	serviceTerminationPackage-v3}
	ID	{map-ac serviceTermination(9) version3(3)} }

This application-context is v3 only.
17.3.2.46	Mobility Management event notification
This application context is used between VLR and gsmSCF for Mobility Management event notification procedures.
mm-EventReportingContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is gsmSCF, Initiator is VLR
	INITIATOR CONSUMER OF {
	mm-EventReportingPackage-v3} 
	ID	{map-ac mm-EventReporting(42) version3(3)} }

This application-context is v3 only.
17.3.2.47	Any time information handling
This application context is used between gsmSCF and HLR for any time information handling procedures.
anyTimeInfohandlingContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is HLR if Initiator is gsmSCF
	INITIATOR CONSUMER OF {
	anyTimeInformationHandlingPackage-v3}
	ID	{map-ac anyTimeInfoHandling(43) version3(3)} }

This application-context is v3 only.
17.3.2.48	Subscriber Data modification notification
This application context is used between HLR and gsmSCF for Subscriber Data modification notification procedures.
subscriberDataModificationNotificationContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is gsmSCF, Initiator is HLR
	INITIATOR CONSUMER OF {
	subscriberDataModificationNotificationPackage-v3} 
	ID	{map-ac subscriberDataModificationNotification(22) version3(3)} }

This application-context is v3 only.
17.3.2.49	Authentication Failure Report
This application context is used between VLR and HLR or SGSN and HLR for reporting of authentication failures.
authenticationFailureReportContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is HLR if Initiator is VLR
	-- Responder is HLR if Initiator is SGSN
	INITIATOR CONSUMER OF {
	authenticationFailureReportPackage-v3 }
	ID	{map-ac authenticationFailureReport(39) version3(3)} }

This application-context is v3 only.
17.3.2.50	Resource Management
This application context is used between GMSC and VMSC for resource management purpose.
resourceManagementContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is VMSC if Initiator is GMSC
	INITIATOR CONSUMER OF {
	resourceManagementPackage-v3 }
	ID	{map-ac resourceManagement(44) version3(3)} }

This application-context is v3 only.
17.3.2.51	Mobile terminating Short Message Relay VGCS
This application context is used between SMS-GMSC and MSC for mobile terminating short message relay procedures for VGCS. 
shortMsgMT-Relay-VGCS-Context-v3 APPLICATION-CONTEXT ::= {
	-- Responder is MSC if Initiator is SMS-GMSC
	INITIATOR CONSUMER OF {
	mt-ShortMsgRelay-VGCS-Package-v3}
	ID	{map-ac shortMsgMT-Relay-VGCS(41) version3(3)} }

This application-context is v3 only.
17.3.2.52	Vcsg Location Updating
This application context is used between CSS and VLR or between CSS and SGSN for vcsg location updating procedures.
vcsgLocationUpdateContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is CSS if Initiator is VLR or SGSN
	INITIATOR CONSUMER OF {
	vcsgLocationUpdatingPackage-v3}
	RESPONDER CONSUMER OF {
	subscriberDataMngtPackage-v3}
	ID	{map-ac vcsgLocationUpdate(46) version3(3)} }

This application-context is v3 only.
17.3.2.53	Vcsg Location Cancellation
This application context is used between CSS and VLR or between CSS and SGSN for vcsg location cancellation procedures.
vcsgLocationCancellationContext-v3 APPLICATION-CONTEXT ::= {
	-- Responder is VLR or SGSN if Initiator is CSS
	INITIATOR CONSUMER OF {
	vcsgLocationCancellationPackage-v3}
	ID	{map-ac vcsgLocationCancel(47) version3(3)} }

This application-context is v3 only.


17.3.3	ASN.1 Module for application-context-names
The following ASN.1 module summarises the application-context-name assigned to MAP application-contexts.
.$MAP-ApplicationContexts {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-ApplicationContexts (2) version19 (19)}

DEFINITIONS

::=

BEGIN


-- EXPORTS everything


IMPORTS
	gsm-NetworkId,
	ac-Id
FROM MobileDomainDefinitions {
   itu-t (0) identified-organization (4) etsi (0) mobileDomain (0)
   mobileDomainDefinitions (0) version1 (1)}
;

-- application-context-names

map-ac  OBJECT IDENTIFIER ::= {gsm-NetworkId ac-Id}

networkLocUpContext-v3  OBJECT IDENTIFIER ::=
	{map-ac networkLocUp(1) version3(3)}

locationCancellationContext-v3  OBJECT IDENTIFIER ::=
	{map-ac locationCancel(2) version3(3)}

roamingNumberEnquiryContext-v3  OBJECT IDENTIFIER ::=
	{map-ac roamingNbEnquiry(3) version3(3)}

authenticationFailureReportContext-v3  OBJECT IDENTIFIER ::=
	{map-ac authenticationFailureReport(39) version3(3)}

locationInfoRetrievalContext-v3  OBJECT IDENTIFIER ::=
	{map-ac locInfoRetrieval(5) version3(3)}

resetContext-v3  OBJECT IDENTIFIER ::=
	{map-ac reset(10) version3(3)}

handoverControlContext-v3  OBJECT IDENTIFIER ::=
	{map-ac handoverControl(11) version3(3)}

equipmentMngtContext-v3  OBJECT IDENTIFIER ::=
	{map-ac equipmentMngt(13) version3(3)}

infoRetrievalContext-v3  OBJECT IDENTIFIER ::=
	{map-ac infoRetrieval(14) version3(3)}

interVlrInfoRetrievalContext-v3  OBJECT IDENTIFIER ::=
	{map-ac interVlrInfoRetrieval(15) version3(3)}

subscriberDataMngtContext-v3  OBJECT IDENTIFIER ::=
	{map-ac subscriberDataMngt(16) version3(3)}

tracingContext-v3  OBJECT IDENTIFIER ::=
	{map-ac tracing(17) version3(3)}

networkFunctionalSsContext-v2  OBJECT IDENTIFIER ::=
	{map-ac networkFunctionalSs(18) version2(2)}

networkUnstructuredSsContext-v2  OBJECT IDENTIFIER ::=
	{map-ac networkUnstructuredSs(19) version2(2)}

shortMsgGatewayContext-v3  OBJECT IDENTIFIER ::=
	{map-ac shortMsgGateway(20) version3(3)}

shortMsgMO-RelayContext-v3  OBJECT IDENTIFIER ::=
	{map-ac shortMsgMO-Relay(21) version3(3)}

shortMsgAlertContext-v2  OBJECT IDENTIFIER ::=
	{map-ac shortMsgAlert(23) version2(2)}

mwdMngtContext-v3  OBJECT IDENTIFIER ::=
	{map-ac mwdMngt(24) version3(3)}

shortMsgMT-RelayContext-v3  OBJECT IDENTIFIER ::=
	{map-ac shortMsgMT-Relay(25) version3(3)}

shortMsgMT-Relay-VGCS-Context-v3  OBJECT IDENTIFIER ::=
	{map-ac shortMsgMT-Relay-VGCS(41) version3(3)}

imsiRetrievalContext-v2  OBJECT IDENTIFIER ::=
	{map-ac imsiRetrieval(26) version2(2)}

msPurgingContext-v3  OBJECT IDENTIFIER ::=
	{map-ac msPurging(27) version3(3)}

subscriberInfoEnquiryContext-v3  OBJECT IDENTIFIER ::=
	{map-ac subscriberInfoEnquiry(28) version3(3)}

anyTimeInfoEnquiryContext-v3  OBJECT IDENTIFIER ::=
	{map-ac anyTimeInfoEnquiry(29) version3(3)}

callControlTransferContext-v4  OBJECT IDENTIFIER ::=
	{map-ac callControlTransfer(6) version4(4)}

ss-InvocationNotificationContext-v3  OBJECT IDENTIFIER ::=
	{map-ac ss-InvocationNotification(36) version3(3)}

groupCallControlContext-v3  OBJECT IDENTIFIER ::=
	{map-ac groupCallControl(31) version3(3)}

groupCallInfoRetrievalContext-v3  OBJECT IDENTIFIER ::=
	{map-ac groupCallInfoRetrieval(45) version3(3)}

gprsLocationUpdateContext-v3  OBJECT IDENTIFIER ::=
	{map-ac gprsLocationUpdate(32) version3(3)}

gprsLocationInfoRetrievalContext-v4  OBJECT IDENTIFIER ::=
	{map-ac gprsLocationInfoRetrieval(33) version4(4)}

failureReportContext-v3  OBJECT IDENTIFIER ::=
	{map-ac failureReport(34) version3(3)}

gprsNotifyContext-v3  OBJECT IDENTIFIER ::=
	{map-ac gprsNotify(35) version3(3)}

reportingContext-v3  OBJECT IDENTIFIER ::=
	{map-ac reporting(7) version3(3)}

callCompletionContext-v3  OBJECT IDENTIFIER ::=
	{map-ac callCompletion(8) version3(3)}

istAlertingContext-v3  OBJECT IDENTIFIER ::=
	{map-ac istAlerting(4) version3(3)}

serviceTerminationContext-v3  OBJECT IDENTIFIER ::=
	{map-ac immediateTermination(9) version3(3)}

locationSvcGatewayContext-v3  OBJECT IDENTIFIER ::=
	{map-ac locationSvcGateway(37) version3(3)}

locationSvcEnquiryContext-v3  OBJECT IDENTIFIER ::=
	{map-ac locationSvcEnquiry(38) version3(3)}

mm-EventReportingContext-v3  OBJECT IDENTIFIER ::=
	{map-ac mm-EventReporting(42) version3(3)}

anyTimeInfoHandlingContext-v3  OBJECT IDENTIFIER ::=
	{map-ac anyTimeInfoHandling(43) version3(3)}

subscriberDataModificationNotificationContext-v3  OBJECT IDENTIFIER ::=
	{map-ac subscriberDataModificationNotification(22) version3(3)}

resourceManagementContext-v3  OBJECT IDENTIFIER ::=
	{map-ac resourceManagement(44) version3(3)}

vcsgLocationUpdateContext-v3  OBJECT IDENTIFIER ::=
	{map-ac vcsgLocationUpdate(46) version3(3)}

vcsgLocationCancellationContext-v3  OBJECT IDENTIFIER ::=
	{map-ac vcsgLocationCancel(47) version3(3)}


-- The following Object Identifiers are reserved for application-contexts
--  existing in previous versions of the protocol

-- AC Name & Version	Object Identifier
-- 
-- networkLocUpContext-v1	map-ac networkLocUp (1)	version1 (1)
-- networkLocUpContext-v2	map-ac networkLocUp (1)	version2 (2)
-- locationCancellationContext-v1	map-ac locationCancellation (2)	version1 (1)
-- locationCancellationContext-v2	map-ac locationCancellation (2)	version2 (2)
-- roamingNumberEnquiryContext-v1	map-ac roamingNumberEnquiry (3)	version1 (1)
-- roamingNumberEnquiryContext-v2	map-ac roamingNumberEnquiry (3)	version2 (2)
-- locationInfoRetrievalContext-v1	map-ac locationInfoRetrieval (5)	version1 (1)
-- locationInfoRetrievalContext-v2	map-ac locationInfoRetrieval (5)	version2 (2)
-- resetContext-v1	map-ac reset (10)	version1 (1)
-- resetContext-v2	map-ac reset (10)	version2 (2)
-- handoverControlContext-v1	map-ac handoverControl (11)	version1 (1)
-- handoverControlContext-v2	map-ac handoverControl (11)	version2 (2)
-- sIWFSAllocationContext-v3	map-ac sIWFSAllocation (12)	version3 (3)
-- equipmentMngtContext-v1	map-ac equipmentMngt (13)	version1 (1)
-- equipmentMngtContext-v2	map-ac equipmentMngt (13)	version2 (2)
-- infoRetrievalContext-v1	map-ac infoRetrieval (14)	version1 (1) 
-- infoRetrievalContext-v2	map-ac infoRetrieval (14)	version2 (2)
-- interVlrInfoRetrievalContext-v2	map-ac interVlrInfoRetrieval (15)	version2 (2)
-- subscriberDataMngtContext-v1	map-ac subscriberDataMngt (16)	version1 (1)
-- subscriberDataMngtContext-v2	map-ac subscriberDataMngt (16)	version2 (2)
-- tracingContext-v1	map-ac tracing (17)	version1 (1)
-- tracingContext-v2	map-ac tracing (17)	version2 (2)
-- networkFunctionalSsContext-v1	map-ac networkFunctionalSs (18)	version1 (1)
-- shortMsgGatewayContext-v1	map-ac shortMsgGateway (20)	version1 (1)
-- shortMsgGatewayContext-v2	map-ac shortMsgGateway (20)	version2 (2)
-- shortMsgRelayContext-v1	map-ac shortMsgRelay (21)	version1 (1)
-- shortMsgAlertContext-v1	map-ac shortMsgAlert (23)	version1 (1)
-- mwdMngtContext-v1	map-ac mwdMngt (24)	version1 (1)
-- mwdMngtContext-v2	map-ac mwdMngt (24)	version2 (2)
-- shortMsgMT-RelayContext-v2	map-ac shortMsgMT-Relay (25)	version2 (2)
-- msPurgingContext-v2	map-ac msPurging (27)	version2 (2) 
-- callControlTransferContext-v3	map-ac callControlTransferContext (6)	version3 (3) 
-- gprsLocationInfoRetrievalContext-v3	map-ac gprsLocationInfoRetrievalContext (33) version3 (3) 


.#END
17.4	MAP Dialogue Information
.$MAP-DialogueInformation {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-DialogueInformation (3) version19 (19)}

DEFINITIONS

IMPLICIT TAGS

::=

BEGIN

EXPORTS
	map-DialogueAS,
	MAP-DialoguePDU

;

IMPORTS
	gsm-NetworkId,
	as-Id
FROM MobileDomainDefinitions {
   itu-t (0) identified-organization (4) etsi (0) mobileDomain (0)
   mobileDomainDefinitions (0) version1 (1)}

	AddressString
FROM MAP-CommonDataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network(1) modules (3) map-CommonDataTypes (18) version19 (19)}

	ExtensionContainer
FROM MAP-ExtensionDataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version19 (19)}


;


-- abstract syntax name for MAP-DialoguePDU

map-DialogueAS  OBJECT IDENTIFIER ::=
	{gsm-NetworkId as-Id map-DialoguePDU (1) version1 (1)}

MAP-DialoguePDU ::= CHOICE {
	map-open	[0] MAP-OpenInfo,
	map-accept	[1] MAP-AcceptInfo,
	map-close	[2] MAP-CloseInfo,
	map-refuse	[3] MAP-RefuseInfo,
	map-userAbort	[4] MAP-UserAbortInfo,
	map-providerAbort	[5] MAP-ProviderAbortInfo}

MAP-OpenInfo ::= SEQUENCE {
	destinationReference	[0] AddressString	OPTIONAL,
	originationReference	[1] AddressString	OPTIONAL,
	...,
	extensionContainer	ExtensionContainer	OPTIONAL
	-- extensionContainer must not be used in version 2
	}

MAP-AcceptInfo ::= SEQUENCE {
	...,
	extensionContainer	ExtensionContainer	OPTIONAL
	-- extensionContainer must not be used in version 2
	}

MAP-CloseInfo ::= SEQUENCE {
	...,
	extensionContainer	ExtensionContainer	OPTIONAL
	-- extensionContainer must not be used in version 2
	}

MAP-RefuseInfo ::= SEQUENCE {
	reason	Reason,
	...,
	extensionContainer	ExtensionContainer	OPTIONAL,
	-- extensionContainer must not be used in version 2
	alternativeApplicationContext	OBJECT IDENTIFIER	OPTIONAL
	-- alternativeApplicationContext must not be used in version 2
	}

Reason ::= ENUMERATED {
	noReasonGiven	(0),
	invalidDestinationReference	(1),
	invalidOriginatingReference	(2)}

MAP-UserAbortInfo ::= SEQUENCE {
	map-UserAbortChoice	MAP-UserAbortChoice,
	...,
	extensionContainer	ExtensionContainer	OPTIONAL
	-- extensionContainer must not be used in version 2
	}

MAP-UserAbortChoice ::= CHOICE {
	userSpecificReason	[0] NULL,
	userResourceLimitation	[1] NULL,
	resourceUnavailable	[2] ResourceUnavailableReason,
	applicationProcedureCancellation	[3] ProcedureCancellationReason}

ResourceUnavailableReason ::= ENUMERATED {
	shortTermResourceLimitation  (0),
	longTermResourceLimitation  (1)}

ProcedureCancellationReason ::= ENUMERATED {
	handoverCancellation  (0),
	radioChannelRelease  (1),
	networkPathRelease  (2),
	callRelease  (3),
	associatedProcedureFailure  (4),
	tandemDialogueRelease  (5),
	remoteOperationsFailure  (6)}

MAP-ProviderAbortInfo ::= SEQUENCE {
	map-ProviderAbortReason	MAP-ProviderAbortReason,
	...,
	extensionContainer	ExtensionContainer	OPTIONAL
	-- extensionContainer must not be used in version 2
	}

MAP-ProviderAbortReason ::= ENUMERATED {
	abnormalDialogue  (0),
	invalidPDU  (1)}

.#END

17.5	MAP operation and error codes
.$MAP-Protocol {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-Protocol (4) version19 (19)}

DEFINITIONS

::=

BEGIN

IMPORTS
OPERATION
FROM Remote-Operations-Information-Objects {
joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)}

	updateLocation,
	cancelLocation,
	cancelVcsgLocation,
	purgeMS,
	sendIdentification,
	updateGprsLocation,
	updateVcsgLocation,
	prepareHandover,
	sendEndSignal,
	processAccessSignalling,
	forwardAccessSignalling,
	prepareSubsequentHandover,
	sendAuthenticationInfo,
authenticationFailureReport,
	checkIMEI,
	insertSubscriberData,
	deleteSubscriberData,
	reset,
	forwardCheckSS-Indication,
	restoreData,
	provideSubscriberInfo,
	anyTimeInterrogation,
	anyTimeSubscriptionInterrogation,
	anyTimeModification,
	sendRoutingInfoForGprs,
	failureReport,
	noteMsPresentForGprs,
	noteMM-Event,
	noteSubscriberDataModified


FROM MAP-MobileServiceOperations {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-MobileServiceOperations (5)
   version19 (19)}

	activateTraceMode,
	deactivateTraceMode,
	sendIMSI
FROM MAP-OperationAndMaintenanceOperations {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-OperationAndMaintenanceOperations (6)
   version19 (19)}

	sendRoutingInfo,
	provideRoamingNumber,
	resumeCallHandling,
	setReportingState,
	statusReport,
	remoteUserFree,
	ist-Alert,
	ist-Command,
	releaseResources
FROM MAP-CallHandlingOperations {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-CallHandlingOperations (7)
   version19 (19)}

	registerSS,
	eraseSS,
	activateSS,
	deactivateSS,
	interrogateSS,
	processUnstructuredSS-Request,
	unstructuredSS-Request,
	unstructuredSS-Notify,
	registerPassword,
	getPassword,
	ss-InvocationNotification,
	registerCC-Entry,
	eraseCC-Entry
FROM MAP-SupplementaryServiceOperations {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-SupplementaryServiceOperations (8)
   version19 (19)}

	sendRoutingInfoForSM,
	mo-ForwardSM,
	mt-ForwardSM,
	reportSM-DeliveryStatus,
	alertServiceCentre,
	informServiceCentre,
	readyForSM,
	mt-ForwardSM-VGCS
FROM MAP-ShortMessageServiceOperations {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-ShortMessageServiceOperations (9)
   version19 (19)}

	prepareGroupCall,
	processGroupCallSignalling,
	forwardGroupCallSignalling,
	sendGroupCallEndSignal,
	sendGroupCallInfo
FROM MAP-Group-Call-Operations {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-Group-Call-Operations (22)
   version19 (19)}

	provideSubscriberLocation,
	sendRoutingInfoForLCS,
	subscriberLocationReport
FROM MAP-LocationServiceOperations {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-LocationServiceOperations (24)
   version19 (19)}


;
Supported-MAP-Operations OPERATION ::= {updateLocation | cancelLocation | cancelVcsgLocation | 
purgeMS | 
sendIdentification | updateGprsLocation | updateVcsgLocation | prepareHandover | sendEndSignal | 
processAccessSignalling | forwardAccessSignalling | prepareSubsequentHandover | 
sendAuthenticationInfo | authenticationFailureReport | checkIMEI | insertSubscriberData | 
deleteSubscriberData | reset | forwardCheckSS-Indication | restoreData | provideSubscriberInfo | 
anyTimeInterrogation | anyTimeSubscriptionInterrogation | anyTimeModification | 
sendRoutingInfoForGprs | failureReport |noteMsPresentForGprs | noteMM-Event | 
noteSubscriberDataModified | activateTraceMode | deactivateTraceMode | sendIMSI | 
sendRoutingInfo | provideRoamingNumber | resumeCallHandling | setReportingState | statusReport | 
remoteUserFree | ist-Alert | 
ist-Command | registerSS | eraseSS | activateSS | deactivateSS | interrogateSS | 
processUnstructuredSS-Request | unstructuredSS-Request | unstructuredSS-Notify | 
registerPassword | getPassword | ss-InvocationNotification | registerCC-Entry | eraseCC-Entry | 
sendRoutingInfoForSM | mo-ForwardSM | mt-ForwardSM | reportSM-DeliveryStatus | 
alertServiceCentre | informServiceCentre | readyForSM | prepareGroupCall | 
processGroupCallSignalling | forwardGroupCallSignalling | sendGroupCallEndSignal |
provideSubscriberLocation | sendRoutingInfoForLCS | subscriberLocationReport | 
releaseResources | mt-ForwardSM-VGCS | sendGroupCallInfo }



-- The following operation codes are reserved for operations
-- existing in previous versions of the protocol

-- Operation Name	AC used	Oper. Code
-- 
-- sendParameters	map-ac infoRetrieval (14) version1 (1)	local:9
-- processUnstructuredSS-Data	map-ac networkFunctionalSs (18) version1 (1)	local:19
-- performHandover	map-ac handoverControl (11) version1 (1)	local:28
-- performSubsequentHandover	map-ac handoverControl (11) version1 (1)	local:30
-- provideSIWFSNumber	map-ac sIWFSAllocation (12) version3 (3)	local:31
-- siwfs-SignallingModify	map-ac sIWFSAllocation (12) version3 (3)	local:32
-- noteInternalHandover	map-ac handoverControl (11) version1 (1)	local:35
-- noteSubscriberPresent	map-ac mwdMngt (24) version1 (1)	local:48
-- alertServiceCentreWithoutResult	map-ac shortMsgAlert (23) version1 (1)	local:49
-- traceSubscriberActivity	map-ac handoverControl (11) version1 (1)	local:52
-- beginSubscriberActivity	map-ac networkFunctionalSs (18) version1 (1)	local:54

-- The following error codes are reserved for errors
-- existing in previous versions of the protocol

-- Error Name	AC used	Error Code
-- 
-- unknownBaseStation	map-ac handoverControl (11) version1 (1)	local:2
-- invalidTargetBaseStation	map-ac handoverControl (11) version1 (1)	local:23
-- noRadioResourceAvailable	map-ac handoverControl (11) version1 (1)	local:24


.#END
17.6	MAP operations and errors
17.6.1	Mobile Service Operations
.$MAP-MobileServiceOperations {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-MobileServiceOperations (5)
   version19 (19)}

DEFINITIONS

::=

BEGIN

EXPORTS

	-- location registration operations
	updateLocation,
	cancelLocation,
	purgeMS,
	sendIdentification, 

	-- gprs location registration operations
	updateGprsLocation,

	-- vcsg location registration operations
	updateVcsgLocation,
	cancelVcsgLocation,

	-- subscriber information enquiry operations
	provideSubscriberInfo,

	-- any time information enquiry operations
	anyTimeInterrogation,

	-- any time information handling operations
	anyTimeSubscriptionInterrogation,
	anyTimeModification, 

	-- subscriber data modification notification operations
	noteSubscriberDataModified,


	-- handover operations
	prepareHandover,
	sendEndSignal,
	processAccessSignalling,
	forwardAccessSignalling,
	prepareSubsequentHandover,

	-- authentication management operations
	sendAuthenticationInfo, 
authenticationFailureReport,

	-- IMEI management operations
	checkIMEI,

	-- subscriber management operations
	insertSubscriberData,
	deleteSubscriberData,

	-- fault recovery operations
	reset,
	forwardCheckSS-Indication,
	restoreData,

-- gprs location information retrieval operations
	sendRoutingInfoForGprs,
	
	-- failure reporting operations
	failureReport,
	
	-- gprs notification operations
	noteMsPresentForGprs,

-- Mobility Management operations
noteMM-Event

;

IMPORTS
	OPERATION
FROM Remote-Operations-Information-Objects {
joint-iso-itu-t remote-operations(4)
  informationObjects(5) version1(0)} 

	systemFailure,
	dataMissing,
	unexpectedDataValue,
	unknownSubscriber,
	unknownMSC,
	unidentifiedSubscriber,
	unknownEquipment,
	roamingNotAllowed, 
	ati-NotAllowed,
	noHandoverNumberAvailable,
	subsequentHandoverFailure,
	absentSubscriber,
	mm-EventNotSupported,
	atsi-NotAllowed,
	atm-NotAllowed,
	bearerServiceNotProvisioned,
	teleserviceNotProvisioned,
	callBarred,
	illegalSS-Operation,
	ss-ErrorStatus,
	ss-NotAvailable,
	ss-Incompatibility,
	ss-SubscriptionViolation,
	informationNotAvailable,
	targetCellOutsideGroupCallArea


FROM MAP-Errors {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-Errors (10) version19 (19)}

	UpdateLocationArg,
	UpdateLocationRes,
	CancelLocationArg,
	CancelLocationRes, 
	PurgeMS-Arg, 
	PurgeMS-Res,
	SendIdentificationArg,
	SendIdentificationRes, 
	UpdateGprsLocationArg,
	UpdateGprsLocationRes,
	UpdateVcsgLocationArg,
	UpdateVcsgLocationRes, 
	CancelVcsgLocationArg,
	CancelVcsgLocationRes,
	PrepareHO-Arg,
	PrepareHO-Res,
ForwardAccessSignalling-Arg,
ProcessAccessSignalling-Arg,
SendEndSignal-Arg,
SendEndSignal-Res,
PrepareSubsequentHO-Res,
	PrepareSubsequentHO-Arg,
	SendAuthenticationInfoArg,
	SendAuthenticationInfoRes, 
	AuthenticationFailureReportArg,
	AuthenticationFailureReportRes,
	CheckIMEI-Arg,
	CheckIMEI-Res,
	InsertSubscriberDataArg,
	InsertSubscriberDataRes,
	DeleteSubscriberDataArg,
	DeleteSubscriberDataRes,
	ResetArg,
	RestoreDataArg,
	RestoreDataRes,
	ProvideSubscriberInfoArg,
	ProvideSubscriberInfoRes,
	AnyTimeSubscriptionInterrogationArg,
	AnyTimeSubscriptionInterrogationRes,
	AnyTimeModificationArg,
	AnyTimeModificationRes,
	NoteSubscriberDataModifiedArg,
	NoteSubscriberDataModifiedRes,
	AnyTimeInterrogationArg,
	AnyTimeInterrogationRes,
	SendRoutingInfoForGprsArg,
	SendRoutingInfoForGprsRes,
	FailureReportArg,
	FailureReportRes,
	NoteMsPresentForGprsArg,
	NoteMsPresentForGprsRes,
	NoteMM-EventArg,
	NoteMM-EventRes


FROM MAP-MS-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-MS-DataTypes (11) version19 (19)}

;


-- location registration operations

updateLocation  OPERATION ::= {	--Timer m
	ARGUMENT
	UpdateLocationArg
	RESULT
	UpdateLocationRes
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	unknownSubscriber |
	roamingNotAllowed}
	CODE	local:2 }

cancelLocation  OPERATION ::= {	--Timer m
	ARGUMENT
	CancelLocationArg
	RESULT
	CancelLocationRes
	-- optional
	ERRORS {
	dataMissing |
	unexpectedDataValue}
	CODE	local:3 }

purgeMS  OPERATION ::= {	--Timer m
	ARGUMENT
	PurgeMS-Arg
	RESULT
	PurgeMS-Res
	-- optional
	ERRORS{
	dataMissing |
	unexpectedDataValue|
	unknownSubscriber}
	CODE	local:67 }

sendIdentification  OPERATION ::= {	--Timer s
	ARGUMENT
	SendIdentificationArg
	RESULT
	SendIdentificationRes
	ERRORS {
	dataMissing |
	unidentifiedSubscriber}
	CODE	local:55 }

-- gprs location registration operations

updateGprsLocation  OPERATION ::= {	--Timer m
	ARGUMENT
	UpdateGprsLocationArg
	RESULT
	UpdateGprsLocationRes
	ERRORS {
	systemFailure |
	unexpectedDataValue |
	unknownSubscriber |
	roamingNotAllowed}
	CODE	local:23 }

-- subscriber information enquiry operations

provideSubscriberInfo  OPERATION ::= {	--Timer m
	ARGUMENT
	ProvideSubscriberInfoArg
	RESULT
	ProvideSubscriberInfoRes
	ERRORS {
	dataMissing |
	unexpectedDataValue}
	CODE	local:70 }

-- any time information enquiry operations

anyTimeInterrogation  OPERATION ::= {	--Timer m
	ARGUMENT
	AnyTimeInterrogationArg
	RESULT
	AnyTimeInterrogationRes
	ERRORS {
	systemFailure | 
	ati-NotAllowed |
	dataMissing |
	unexpectedDataValue |
	unknownSubscriber}
	CODE	local:71 }

-- any time information handling operations

anyTimeSubscriptionInterrogation  OPERATION ::= {	--Timer m
	ARGUMENT
	AnyTimeSubscriptionInterrogationArg
	RESULT
	AnyTimeSubscriptionInterrogationRes
	ERRORS {
	atsi-NotAllowed |
	dataMissing |
	unexpectedDataValue |
	unknownSubscriber |
	bearerServiceNotProvisioned |
	teleserviceNotProvisioned |
	callBarred |
	illegalSS-Operation |
	ss-NotAvailable |
	informationNotAvailable}
	CODE	local:62 }

anyTimeModification  OPERATION ::= {	--Timer m
	ARGUMENT
	AnyTimeModificationArg
	RESULT
	AnyTimeModificationRes
	ERRORS {
	atm-NotAllowed |
	dataMissing |
	unexpectedDataValue |
	unknownSubscriber |
	bearerServiceNotProvisioned |
	teleserviceNotProvisioned |
	callBarred |
	illegalSS-Operation |
	ss-SubscriptionViolation |
	ss-ErrorStatus |
	ss-Incompatibility |
	informationNotAvailable}
	CODE	local:65 }

-- subscriber data modification notification operations

noteSubscriberDataModified  OPERATION ::= {	--Timer m
	ARGUMENT
	NoteSubscriberDataModifiedArg
	RESULT
	NoteSubscriberDataModifiedRes
	-- optional
	ERRORS {
	dataMissing |
	unexpectedDataValue |
	unknownSubscriber}
	CODE	local:5 }

-- handover operations

prepareHandover  OPERATION ::= {	--Timer m
	ARGUMENT
	PrepareHO-Arg
	RESULT
	PrepareHO-Res
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	noHandoverNumberAvailable |
	targetCellOutsideGroupCallArea }
	CODE	local:68 }

sendEndSignal  OPERATION ::= {	--Timer l
	ARGUMENT
	SendEndSignal-Arg
	RESULT
	SendEndSignal-Res
	CODE	local:29 }

processAccessSignalling  OPERATION ::= {	--Timer s
	ARGUMENT
	ProcessAccessSignalling-Arg
	CODE	local:33 }

forwardAccessSignalling  OPERATION ::= {	--Timer s
	ARGUMENT
	ForwardAccessSignalling-Arg
	CODE	local:34 }

prepareSubsequentHandover  OPERATION ::= {	--Timer m
	ARGUMENT
	PrepareSubsequentHO-Arg
	RESULT
	PrepareSubsequentHO-Res
	ERRORS {
	unexpectedDataValue |
	dataMissing |
	unknownMSC |
	subsequentHandoverFailure}
	CODE	local:69 }

-- authentication management operations

sendAuthenticationInfo  OPERATION ::= {	--Timer m
	ARGUMENT
	SendAuthenticationInfoArg
	-- optional
	-- within a dialogue sendAuthenticationInfoArg shall not be present in
	-- subsequent invoke components. If received in a subsequent invoke component
	-- it shall be discarded.

	RESULT
	SendAuthenticationInfoRes
	-- optional
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	unknownSubscriber}
	CODE	local:56 }

authenticationFailureReport  OPERATION ::= {	--Timer m
	ARGUMENT
	AuthenticationFailureReportArg
	RESULT
	AuthenticationFailureReportRes
	-- optional
	ERRORS {
	systemFailure |
	unexpectedDataValue |
	unknownSubscriber}
	CODE	local:15 }

-- IMEI management operations

checkIMEI  OPERATION ::= {	--Timer m
	ARGUMENT
	CheckIMEI-Arg
	RESULT
	CheckIMEI-Res
	ERRORS {
	systemFailure |
	dataMissing |
	unknownEquipment}
	CODE	local:43 }

-- subscriber management operations

insertSubscriberData  OPERATION ::= {	--Timer m
	ARGUMENT
	InsertSubscriberDataArg
	RESULT
	InsertSubscriberDataRes
	-- optional
	ERRORS {
	dataMissing |
	unexpectedDataValue |
	unidentifiedSubscriber}
	CODE	local:7 }

deleteSubscriberData  OPERATION ::= {	--Timer m
	ARGUMENT
	DeleteSubscriberDataArg
	RESULT
	DeleteSubscriberDataRes
	-- optional
	ERRORS {
	dataMissing |
	unexpectedDataValue |
	unidentifiedSubscriber}
	CODE	local:8 }

-- fault recovery operations

reset  OPERATION ::= {	--Timer m
	ARGUMENT
	ResetArg
	CODE	local:37 }

forwardCheckSS-Indication  OPERATION ::= {	--Timer s
	CODE	local:38 }

restoreData  OPERATION ::= {	--Timer m
	ARGUMENT
	RestoreDataArg
	RESULT
	RestoreDataRes
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	unknownSubscriber}
	CODE	local:57 }

-- gprs location information retrieval operations

sendRoutingInfoForGprs  OPERATION ::= {	--Timer m
	ARGUMENT
	SendRoutingInfoForGprsArg
	RESULT
	SendRoutingInfoForGprsRes
	ERRORS {
	absentSubscriber |
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	unknownSubscriber |
	callBarred }
	CODE	local:24 }

-- failure reporting operations

failureReport  OPERATION ::= {	--Timer m
	ARGUMENT
	FailureReportArg
	RESULT
	FailureReportRes
	-- optional
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	unknownSubscriber}
	CODE	local:25 }

-- gprs notification operations

noteMsPresentForGprs  OPERATION ::= {	--Timer m
	ARGUMENT
	NoteMsPresentForGprsArg
	RESULT
	NoteMsPresentForGprsRes
	-- optional
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	unknownSubscriber}
	CODE	local:26 }

noteMM-Event  OPERATION ::= {	--Timer m
	ARGUMENT
	NoteMM-EventArg
	RESULT
	NoteMM-EventRes
	ERRORS {
	dataMissing |
	unexpectedDataValue |
	unknownSubscriber |
	mm-EventNotSupported}
	CODE	local:89 }

-- vcsg location registration operations

updateVcsgLocation  OPERATION ::= {	--Timer m
	ARGUMENT
	UpdateVcsgLocationArg
	RESULT
	UpdateVcsgLocationRes
	ERRORS {
	systemFailure |
	unexpectedDataValue |
	unknownSubscriber}
	CODE	local:53 }

cancelVcsgLocation  OPERATION ::= {	--Timer m
	ARGUMENT
	CancelVcsgLocationArg
	RESULT
	CancelVcsgLocationRes
	-- optional
	ERRORS {
	dataMissing |
	unexpectedDataValue}
	CODE	local:36 }

.#END
17.6.2	Operation and Maintenance Operations
.$MAP-OperationAndMaintenanceOperations {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-OperationAndMaintenanceOperations (6)
   version19 (19)}

DEFINITIONS

::=

BEGIN

EXPORTS
	activateTraceMode,
	deactivateTraceMode,
	sendIMSI
;

IMPORTS
	OPERATION
FROM Remote-Operations-Information-Objects {
joint-iso-itu-t remote-operations(4)
  informationObjects(5) version1(0)}

	systemFailure,
	dataMissing,
	unexpectedDataValue,
	facilityNotSupported,
	unknownSubscriber,
	unidentifiedSubscriber,
	tracingBufferFull
FROM MAP-Errors {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-Errors (10) version19 (19)}

	ActivateTraceModeArg,
	ActivateTraceModeRes,
	DeactivateTraceModeArg,
	DeactivateTraceModeRes
FROM MAP-OM-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-OM-DataTypes (12) version19 (19)}

	ISDN-AddressString,
	IMSI
FROM MAP-CommonDataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-CommonDataTypes (18) version19 (19)}
;


activateTraceMode  OPERATION ::= {	--Timer m
	ARGUMENT
	ActivateTraceModeArg
	RESULT
	ActivateTraceModeRes
	-- optional
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	facilityNotSupported |
	unidentifiedSubscriber |
	tracingBufferFull}
	CODE	local:50 }

deactivateTraceMode  OPERATION ::= {	--Timer m
	ARGUMENT
	DeactivateTraceModeArg
	RESULT
	DeactivateTraceModeRes
	-- optional
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	facilityNotSupported |
	unidentifiedSubscriber}
	CODE	local:51 }

sendIMSI  OPERATION ::= {	--Timer m
	ARGUMENT
	ISDN-AddressString
	RESULT
	IMSI
	ERRORS {
	dataMissing |
	unexpectedDataValue |
	unknownSubscriber}
	CODE	local:58 }

.#END
17.6.3	Call Handling Operations
.$MAP-CallHandlingOperations {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-CallHandlingOperations (7)
   version19 (19)}

DEFINITIONS

::=

BEGIN

EXPORTS
	sendRoutingInfo,
	provideRoamingNumber,
	resumeCallHandling,
	setReportingState,
	statusReport,
	remoteUserFree,
	ist-Alert,
	ist-Command,
	releaseResources
;

IMPORTS
	OPERATION
FROM Remote-Operations-Information-Objects {
joint-iso-itu-t remote-operations(4)
  informationObjects(5) version1(0)}

	systemFailure,
	dataMissing,
	unexpectedDataValue,
	facilityNotSupported,
	or-NotAllowed,
	unknownSubscriber,
	numberChanged,
	bearerServiceNotProvisioned,
	teleserviceNotProvisioned,
	noRoamingNumberAvailable,
	absentSubscriber,
	busySubscriber,
	noSubscriberReply,
	callBarred,
	forwardingViolation,
	forwardingFailed,
	cug-Reject,
	resourceLimitation,
	incompatibleTerminal,
	unidentifiedSubscriber

FROM MAP-Errors {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-Errors (10) version19 (19)}
	SendRoutingInfoArg,
	SendRoutingInfoRes,
	ProvideRoamingNumberArg,
	ProvideRoamingNumberRes,
	ResumeCallHandlingArg,
	ResumeCallHandlingRes,
	SetReportingStateArg,
	SetReportingStateRes,
	StatusReportArg,
	StatusReportRes,
	RemoteUserFreeArg,
	RemoteUserFreeRes,
	IST-AlertArg,
	IST-AlertRes,
	IST-CommandArg,
	IST-CommandRes,
	ReleaseResourcesArg,
	ReleaseResourcesRes
FROM MAP-CH-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-CH-DataTypes (13) version19 (19)}

;

sendRoutingInfo  OPERATION ::= {	--Timer m
-- The timer is set to the upper limit of the range if the GMSC supports pre-paging.
	ARGUMENT
	SendRoutingInfoArg
	RESULT
	SendRoutingInfoRes
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	facilityNotSupported |
	or-NotAllowed |
	unknownSubscriber |
	numberChanged |
	bearerServiceNotProvisioned |
	teleserviceNotProvisioned |
	absentSubscriber |
	busySubscriber |
	noSubscriberReply |
	callBarred |
	cug-Reject |
	forwardingViolation}
	CODE	local:22 }

provideRoamingNumber  OPERATION ::= {	--Timer m
-- The timer is set to the upper limit of the range if the HLR supports pre-paging.
	ARGUMENT
	ProvideRoamingNumberArg
	RESULT
	ProvideRoamingNumberRes
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	facilityNotSupported |
	or-NotAllowed |
	absentSubscriber |
	noRoamingNumberAvailable}
	CODE	local:4 }

resumeCallHandling  OPERATION ::= {	--Timer m
	ARGUMENT
	ResumeCallHandlingArg
	RESULT
	ResumeCallHandlingRes
	-- optional
	ERRORS {
	forwardingFailed |
	or-NotAllowed |
	unexpectedDataValue |
	dataMissing }
	CODE	local:6 }

setReportingState  OPERATION ::= {	--Timer m
	ARGUMENT
	SetReportingStateArg
	RESULT
	SetReportingStateRes
	-- optional
	ERRORS {
	systemFailure |
	unidentifiedSubscriber |
	unexpectedDataValue |
	dataMissing |
	resourceLimitation |
	facilityNotSupported}
	CODE	local:73 }

statusReport  OPERATION ::= {	--Timer m
	ARGUMENT
	StatusReportArg
	RESULT
	StatusReportRes
	-- optional
	ERRORS {
	unknownSubscriber |
	systemFailure |
	unexpectedDataValue |
	dataMissing}
	CODE	local:74 }

remoteUserFree  OPERATION ::= {	--Timer ml
	ARGUMENT
	RemoteUserFreeArg
	RESULT
	RemoteUserFreeRes
	ERRORS {
	unexpectedDataValue |
	dataMissing |
	incompatibleTerminal |
	absentSubscriber |
	systemFailure |
	busySubscriber}
	CODE	local:75 }

ist-Alert  OPERATION ::= {	--Timer m
	ARGUMENT
	IST-AlertArg
	RESULT
	IST-AlertRes
	-- optional
	ERRORS {
	unexpectedDataValue |
	resourceLimitation |
	unknownSubscriber |
	systemFailure |
	facilityNotSupported}
	CODE	local:87 }

ist-Command  OPERATION::= {	--Timer m
	ARGUMENT
	IST-CommandArg
	RESULT
	IST-CommandRes
	-- optional
	ERRORS {
	unexpectedDataValue |
	resourceLimitation |
	unknownSubscriber |
	systemFailure |
	facilityNotSupported}
	CODE	local:88 }

releaseResources  OPERATION::= {	--Timer m
	ARGUMENT
	ReleaseResourcesArg
	RESULT
	ReleaseResourcesRes
	-- optional
	ERRORS {
	unexpectedDataValue |
	systemFailure }
	CODE	local:20 }

.#END
17.6.4	Supplementary service operations
.$MAP-SupplementaryServiceOperations {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-SupplementaryServiceOperations (8)
   version19 (19)}

DEFINITIONS

::=

BEGIN

EXPORTS
	registerSS,
	eraseSS,
	activateSS,
	deactivateSS,
	interrogateSS,
	processUnstructuredSS-Request,
	unstructuredSS-Request,
	unstructuredSS-Notify,
	registerPassword,
	getPassword,
	ss-InvocationNotification,
	registerCC-Entry,
	eraseCC-Entry
;

IMPORTS
	OPERATION
FROM Remote-Operations-Information-Objects {
joint-iso-itu-t remote-operations(4)
  informationObjects(5) version1(0)}

	systemFailure,
	dataMissing,
	unexpectedDataValue,
	unknownSubscriber,
	bearerServiceNotProvisioned,
	teleserviceNotProvisioned,
	callBarred,
	illegalSS-Operation,
	ss-ErrorStatus,
	ss-NotAvailable,
	ss-SubscriptionViolation,
	ss-Incompatibility,
	pw-RegistrationFailure,
	negativePW-Check,
	numberOfPW-AttemptsViolation,
	unknownAlphabet,
	ussd-Busy,
	absentSubscriber,
	illegalSubscriber,
	illegalEquipment,
	shortTermDenial,
	longTermDenial,
	facilityNotSupported
FROM MAP-Errors {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-Errors (10) version19 (19)}

	RegisterSS-Arg,
	SS-Info,
	SS-ForBS-Code,
	InterrogateSS-Res,
	USSD-Arg,
	USSD-Res,
	Password,
	GuidanceInfo,
	SS-InvocationNotificationArg,
	SS-InvocationNotificationRes,
	RegisterCC-EntryArg,
	RegisterCC-EntryRes,
	EraseCC-EntryArg,
	EraseCC-EntryRes
FROM MAP-SS-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-SS-DataTypes (14) version19 (19)}

	SS-Code
FROM MAP-SS-Code {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-SS-Code (15) version19 (19)}
;


-- supplementary service handling operations

registerSS  OPERATION ::= {	--Timer m
	ARGUMENT
	RegisterSS-Arg
	RESULT
	SS-Info
	-- optional
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	bearerServiceNotProvisioned |
	teleserviceNotProvisioned |
	callBarred |
	illegalSS-Operation |
	ss-ErrorStatus |
	ss-Incompatibility}
	CODE	local:10 }

eraseSS  OPERATION ::= {	--Timer m
	ARGUMENT
	SS-ForBS-Code
	RESULT
	SS-Info
	-- optional
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	bearerServiceNotProvisioned |
	teleserviceNotProvisioned |
	callBarred |
	illegalSS-Operation |
	ss-ErrorStatus
	}
	CODE	local:11 }

activateSS  OPERATION ::= {	--Timer m
	ARGUMENT
	SS-ForBS-Code
	RESULT
	SS-Info
	-- optional
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	bearerServiceNotProvisioned |
	teleserviceNotProvisioned |
	callBarred |
	illegalSS-Operation |
	ss-ErrorStatus |
	ss-SubscriptionViolation |
	ss-Incompatibility |
	negativePW-Check |
	numberOfPW-AttemptsViolation}
	CODE	local:12 }

deactivateSS  OPERATION ::= {	--Timer m
	ARGUMENT
	SS-ForBS-Code
	RESULT
	SS-Info
	-- optional
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	bearerServiceNotProvisioned |
	teleserviceNotProvisioned |
	callBarred |
	illegalSS-Operation |
	ss-ErrorStatus |
	ss-SubscriptionViolation |
	negativePW-Check |
	numberOfPW-AttemptsViolation}
	CODE	local:13 }

interrogateSS  OPERATION ::= {	--Timer m
	ARGUMENT
	SS-ForBS-Code
	RESULT
	InterrogateSS-Res
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	bearerServiceNotProvisioned |
	teleserviceNotProvisioned |
	callBarred |
	illegalSS-Operation |
	ss-NotAvailable}
	CODE	local:14 }

processUnstructuredSS-Request  OPERATION ::= {	--Timer 10 minutes
	ARGUMENT
	USSD-Arg
	RESULT
	USSD-Res
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	unknownAlphabet |
	callBarred}
	CODE	local:59 }

unstructuredSS-Request  OPERATION ::= {	--Timer ml
	ARGUMENT
	USSD-Arg
	RESULT
	USSD-Res
	-- optional
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	absentSubscriber |
	illegalSubscriber |
	illegalEquipment |
	unknownAlphabet |
	ussd-Busy}
	CODE	local:60 }

unstructuredSS-Notify  OPERATION ::= {	--Timer ml
	ARGUMENT
	USSD-Arg
	RETURN RESULT TRUE
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	absentSubscriber |
	illegalSubscriber |
	illegalEquipment |
	unknownAlphabet |
	ussd-Busy}
	CODE	local:61 }

registerPassword  OPERATION ::= {	--Timer ml
	ARGUMENT
	SS-Code
	RESULT
	Password
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	callBarred |
	ss-SubscriptionViolation |
	pw-RegistrationFailure |
	negativePW-Check |
	numberOfPW-AttemptsViolation}
--	LINKED {
--	getPassword}
	CODE	local:17 }

getPassword  OPERATION ::= {	--Timer m
	ARGUMENT
	GuidanceInfo
	RESULT
	Password
	CODE	local:18 }

ss-InvocationNotification  OPERATION ::= {	--Timer m
	ARGUMENT
	SS-InvocationNotificationArg
	RESULT
	SS-InvocationNotificationRes
	-- optional
	ERRORS {
	dataMissing |
	unexpectedDataValue |
	unknownSubscriber}
	CODE	local:72 }

registerCC-Entry  OPERATION ::= {	--Timer m
	ARGUMENT
	RegisterCC-EntryArg
	RESULT
	RegisterCC-EntryRes
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	callBarred |
	illegalSS-Operation |
	ss-ErrorStatus |
	ss-Incompatibility |
	shortTermDenial |
	longTermDenial |
	facilityNotSupported}
	CODE	local:76 }

eraseCC-Entry  OPERATION ::= {	--Timer m
	ARGUMENT
	EraseCC-EntryArg
	RESULT
	EraseCC-EntryRes
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	callBarred |
	illegalSS-Operation |
	ss-ErrorStatus}
	CODE	local:77 }

.#END
17.6.5	Short message service operations
.$MAP-ShortMessageServiceOperations {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-ShortMessageServiceOperations (9)
   version19 (19)}

DEFINITIONS

::=

BEGIN

EXPORTS
	sendRoutingInfoForSM,
	mo-ForwardSM,
	mt-ForwardSM,
	reportSM-DeliveryStatus,
	alertServiceCentre,
	informServiceCentre,
	readyForSM,
	mt-ForwardSM-VGCS
;

IMPORTS
	OPERATION
FROM Remote-Operations-Information-Objects {
joint-iso-itu-t remote-operations(4)
  informationObjects(5) version1(0)}

	systemFailure,
	dataMissing,
	unexpectedDataValue,
	facilityNotSupported,
	unknownSubscriber,
	unidentifiedSubscriber,
	illegalSubscriber,
	illegalEquipment,
	teleserviceNotProvisioned,
	callBarred,
	subscriberBusyForMT-SMS,
	sm-DeliveryFailure,
	messageWaitingListFull,
	absentSubscriberSM
FROM MAP-Errors {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-Errors (10) version19 (19)}

	RoutingInfoForSM-Arg,
	RoutingInfoForSM-Res,
	MO-ForwardSM-Arg,
	MO-ForwardSM-Res,
	MT-ForwardSM-Arg,
	MT-ForwardSM-Res,
	ReportSM-DeliveryStatusArg,
	ReportSM-DeliveryStatusRes,
	AlertServiceCentreArg,
	InformServiceCentreArg,
	ReadyForSM-Arg,
	ReadyForSM-Res,
	MT-ForwardSM-VGCS-Arg,
	MT-ForwardSM-VGCS-Res
FROM MAP-SM-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-SM-DataTypes (16) version19 (19)}

;

sendRoutingInfoForSM  OPERATION ::= {	--Timer m
	ARGUMENT
	RoutingInfoForSM-Arg
	RESULT
	RoutingInfoForSM-Res
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	facilityNotSupported |
	unknownSubscriber |
	teleserviceNotProvisioned |
	callBarred |
	absentSubscriberSM}
	CODE	local:45 }

mo-ForwardSM  OPERATION ::= {	--Timer ml
	ARGUMENT
	MO-ForwardSM-Arg
	RESULT
	MO-ForwardSM-Res
	-- optional
	ERRORS {
	systemFailure |
	unexpectedDataValue |
	facilityNotSupported |
	sm-DeliveryFailure}
	CODE	local:46 }

mt-ForwardSM  OPERATION ::= {	--Timer ml
	-- the timer value may be subject to negotiation between GMSC and IP-SM-GW
	ARGUMENT
	MT-ForwardSM-Arg
	RESULT
	MT-ForwardSM-Res
	-- optional
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	facilityNotSupported |
	unidentifiedSubscriber |
	illegalSubscriber |
	illegalEquipment |
	subscriberBusyForMT-SMS |
	sm-DeliveryFailure |
	absentSubscriberSM}
	CODE	local:44 }

reportSM-DeliveryStatus  OPERATION ::= {	--Timer s
	ARGUMENT
	ReportSM-DeliveryStatusArg
	RESULT
	ReportSM-DeliveryStatusRes
	-- optional
	ERRORS {
	dataMissing |
	unexpectedDataValue |
	unknownSubscriber |
	messageWaitingListFull}
	CODE	local:47 }

alertServiceCentre  OPERATION ::= {	--Timer s
	ARGUMENT
	AlertServiceCentreArg
	RETURN RESULT TRUE
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue}
	CODE	local:64 }

informServiceCentre  OPERATION ::= {	--Timer s
	ARGUMENT
	InformServiceCentreArg
	CODE	local:63 }

readyForSM  OPERATION ::= {	--Timer m
	ARGUMENT
	ReadyForSM-Arg
	RESULT
	ReadyForSM-Res
	-- optional
	ERRORS {
	dataMissing |
	unexpectedDataValue |
	facilityNotSupported |
	unknownSubscriber}
	CODE	local:66 }

mt-ForwardSM-VGCS  OPERATION ::= {	--Timer ml
	ARGUMENT
	MT-ForwardSM-VGCS-Arg
	RESULT
	MT-ForwardSM-VGCS-Res
	-- optional
	ERRORS {
	systemFailure |
	unexpectedDataValue }
	CODE	local:21 }


.#END
17.6.6	Errors
.$MAP-Errors {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-Errors (10) version19 (19)}

DEFINITIONS

::=

BEGIN

EXPORTS

	-- generic errors
	systemFailure,
	dataMissing,
	unexpectedDataValue,
	facilityNotSupported,
	incompatibleTerminal,
	resourceLimitation,

	-- identification and numbering errors
	unknownSubscriber,
	numberChanged,
	unknownMSC,
	unidentifiedSubscriber,
	unknownEquipment,

	-- subscription errors
	roamingNotAllowed,
	illegalSubscriber,
	illegalEquipment,
	bearerServiceNotProvisioned,
	teleserviceNotProvisioned,

	-- handover errors
	noHandoverNumberAvailable,
	subsequentHandoverFailure, 
	targetCellOutsideGroupCallArea,

	-- operation and maintenance errors
	tracingBufferFull,

	-- call handling errors
	or-NotAllowed,
	noRoamingNumberAvailable,
	busySubscriber,
	noSubscriberReply,
	absentSubscriber,
	callBarred,
	forwardingViolation,
	forwardingFailed,
	cug-Reject,

	-- any time interrogation errors
	ati-NotAllowed,

	-- any time information handling errors
	atsi-NotAllowed,
	atm-NotAllowed,
	informationNotAvailable,

	-- supplementary service errors
	illegalSS-Operation,
	ss-ErrorStatus,
	ss-NotAvailable,
	ss-SubscriptionViolation,
	ss-Incompatibility,
	unknownAlphabet,
	ussd-Busy,
	pw-RegistrationFailure,
	negativePW-Check,
	numberOfPW-AttemptsViolation,
	shortTermDenial,
	longTermDenial,

	-- short message service errors
	subscriberBusyForMT-SMS,
	sm-DeliveryFailure,
	messageWaitingListFull,
	absentSubscriberSM,

	-- Group Call errors
	noGroupCallNumberAvailable, 
	ongoingGroupCall,

	-- location service errors
	unauthorizedRequestingNetwork,
	unauthorizedLCSClient,
	positionMethodFailure,
	unknownOrUnreachableLCSClient,

	-- Mobility Management errors
	mm-EventNotSupported


;

IMPORTS
	ERROR
FROM Remote-Operations-Information-Objects {joint-iso-itu-t remote-operations(4)
  informationObjects(5) version1(0) }

	SS-Status
FROM MAP-SS-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-SS-DataTypes (14) version19 (19)}

	SS-IncompatibilityCause,
	PW-RegistrationFailureCause,
	SM-DeliveryFailureCause,
	SystemFailureParam,
	DataMissingParam,
	UnexpectedDataParam,
	FacilityNotSupParam,
	UnknownSubscriberParam,
	NumberChangedParam,
	UnidentifiedSubParam,
	RoamingNotAllowedParam,
	IllegalSubscriberParam,
	IllegalEquipmentParam,
	BearerServNotProvParam,
	TeleservNotProvParam,
	TracingBufferFullParam,
	NoRoamingNbParam,
	OR-NotAllowedParam,
	AbsentSubscriberParam,
	BusySubscriberParam,
	NoSubscriberReplyParam,
	CallBarredParam,
	ForwardingViolationParam,
	ForwardingFailedParam,
	CUG-RejectParam, 
	ATI-NotAllowedParam,
	SubBusyForMT-SMS-Param,
	MessageWaitListFullParam,
	AbsentSubscriberSM-Param,
	ResourceLimitationParam,
	NoGroupCallNbParam,
	IncompatibleTerminalParam,
	ShortTermDenialParam,
	LongTermDenialParam,
	UnauthorizedRequestingNetwork-Param,
	UnauthorizedLCSClient-Param,
	PositionMethodFailure-Param,
UnknownOrUnreachableLCSClient-Param,
	MM-EventNotSupported-Param,
ATSI-NotAllowedParam,
ATM-NotAllowedParam,
IllegalSS-OperationParam,
SS-NotAvailableParam,
SS-SubscriptionViolationParam,
InformationNotAvailableParam,
TargetCellOutsideGCA-Param,
OngoingGroupCallParam
FROM MAP-ER-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-ER-DataTypes (17) version19 (19)}
;

-- generic errors

systemFailure  ERROR ::= {
	PARAMETER
	SystemFailureParam
	-- optional
	CODE	local:34 }

dataMissing  ERROR ::= {
	PARAMETER
	DataMissingParam
	-- optional
	-- DataMissingParam must not be used in version <3
	CODE	local:35 }

unexpectedDataValue  ERROR ::= {
	PARAMETER
	UnexpectedDataParam
	-- optional
	-- UnexpectedDataParam must not be used in version <3
	CODE	local:36 }

facilityNotSupported  ERROR ::= {
	PARAMETER
	FacilityNotSupParam
	-- optional
	-- FacilityNotSupParam must not be used in version <3
	CODE	local:21 }

incompatibleTerminal  ERROR ::= {
	PARAMETER
	IncompatibleTerminalParam
	-- optional
	CODE	local:28 }

resourceLimitation  ERROR ::= {
	PARAMETER
	ResourceLimitationParam
	-- optional
	CODE	local:51 }

-- identification and numbering errors

unknownSubscriber  ERROR ::= {
	PARAMETER
	UnknownSubscriberParam
	-- optional
	-- UnknownSubscriberParam must not be used in version <3
	CODE	local:1 }

numberChanged  ERROR ::= {
	PARAMETER
	NumberChangedParam
	-- optional
	CODE	local:44 }

unknownMSC  ERROR ::= {
	CODE	local:3 }

unidentifiedSubscriber  ERROR ::= {
	PARAMETER
	UnidentifiedSubParam
	-- optional
	-- UunidentifiedSubParam must not be used in version <3
	CODE	local:5 }

unknownEquipment  ERROR ::= {
	CODE	local:7 }

-- subscription errors

roamingNotAllowed  ERROR ::= {
	PARAMETER
	RoamingNotAllowedParam
	CODE	local:8 }

illegalSubscriber  ERROR ::= {
	PARAMETER
	IllegalSubscriberParam
	-- optional
	-- IllegalSubscriberParam must not be used in version <3
	CODE	local:9 }

illegalEquipment  ERROR ::= {
	PARAMETER
	IllegalEquipmentParam
	-- optional
	-- IllegalEquipmentParam must not be used in version <3
	CODE	local:12 }

bearerServiceNotProvisioned  ERROR ::= {
	PARAMETER
	BearerServNotProvParam
	-- optional
	-- BearerServNotProvParam must not be used in version <3
	CODE	local:10 }

teleserviceNotProvisioned  ERROR ::= {
	PARAMETER
	TeleservNotProvParam
	-- optional
	-- TeleservNotProvParam must not be used in version <3
	CODE	local:11 }

-- handover errors

noHandoverNumberAvailable  ERROR ::= {
	CODE	local:25 }

subsequentHandoverFailure  ERROR ::= {
	CODE	local:26 }

targetCellOutsideGroupCallArea  ERROR ::= {
	PARAMETER
	TargetCellOutsideGCA-Param
	-- optional
	CODE	local:42 }

-- operation and maintenance errors

tracingBufferFull  ERROR ::= {
	PARAMETER
	TracingBufferFullParam
	-- optional
	CODE	local: 40 }

-- call handling errors

noRoamingNumberAvailable  ERROR ::= {
	PARAMETER
	NoRoamingNbParam
	-- optional
	CODE	local:39 }

absentSubscriber  ERROR ::= {
	PARAMETER
	AbsentSubscriberParam
	-- optional
	-- AbsentSubscriberParam must not be used in version <3
	CODE	local:27 }

busySubscriber  ERROR ::= {
	PARAMETER
	BusySubscriberParam
	-- optional
	CODE	local:45 }

noSubscriberReply  ERROR ::= {
	PARAMETER
	NoSubscriberReplyParam
	-- optional
	CODE	local:46 }

callBarred  ERROR ::= {
	PARAMETER
	CallBarredParam
	-- optional
	CODE	local:13 }

forwardingViolation  ERROR ::= {
	PARAMETER
	ForwardingViolationParam
	-- optional
	CODE	local:14 }

forwardingFailed  ERROR ::= {
	PARAMETER
	ForwardingFailedParam
	-- optional
	CODE	local:47 }

cug-Reject  ERROR ::= {
	PARAMETER
	CUG-RejectParam
	-- optional
	CODE	local:15 }

or-NotAllowed  ERROR ::= {
	PARAMETER
	OR-NotAllowedParam
	-- optional
	CODE	local:48 }

-- any time interrogation errors
ati-NotAllowed  ERROR ::= {
	PARAMETER
	ATI-NotAllowedParam
	-- optional
	CODE	local:49 }

-- any time information handling errors
atsi-NotAllowed  ERROR ::= {
	PARAMETER
	ATSI-NotAllowedParam
	-- optional
	CODE	local:60 }

atm-NotAllowed  ERROR ::= {
	PARAMETER
	ATM-NotAllowedParam
	-- optional
	CODE	local:61 }

informationNotAvailable  ERROR ::= {
	PARAMETER
	InformationNotAvailableParam
	-- optional
	CODE	local:62 }

-- supplementary service errors

illegalSS-Operation  ERROR ::= {
	PARAMETER
	IllegalSS-OperationParam
	-- optional
	-- IllegalSS-OperationParam must not be used in version <3
	CODE	local:16 }

ss-ErrorStatus  ERROR ::= {
	PARAMETER
	SS-Status
	-- optional
	CODE	local:17 }

ss-NotAvailable  ERROR ::= {
	PARAMETER
	SS-NotAvailableParam
	-- optional
	-- SS-NotAvailableParam must not be used in version <3
	CODE	local:18 }

ss-SubscriptionViolation  ERROR ::= {
	PARAMETER
	SS-SubscriptionViolationParam
	-- optional
	-- SS-SubscriptionViolationParam must not be used in version <3
	CODE	local:19 }

ss-Incompatibility  ERROR ::= {
	PARAMETER
	SS-IncompatibilityCause
	-- optional
	CODE	local:20 }

unknownAlphabet  ERROR ::= {
	CODE	local:71 }

ussd-Busy  ERROR ::= {
	CODE	local:72 }

pw-RegistrationFailure  ERROR ::= {
	PARAMETER
	PW-RegistrationFailureCause
	CODE	local:37 }

negativePW-Check  ERROR ::= {
	CODE	local:38 }

numberOfPW-AttemptsViolation  ERROR ::= {
	CODE	local:43 }

shortTermDenial  ERROR ::= {
	PARAMETER
	ShortTermDenialParam
	-- optional
	CODE	local:29 }

longTermDenial  ERROR ::= {
	PARAMETER
	LongTermDenialParam
	-- optional
	CODE	local:30 }

-- short message service errors

subscriberBusyForMT-SMS  ERROR ::= {
	PARAMETER
	SubBusyForMT-SMS-Param
	-- optional
	CODE	local:31 }

sm-DeliveryFailure  ERROR ::= {
	PARAMETER
	SM-DeliveryFailureCause
	CODE	local:32 }

messageWaitingListFull  ERROR ::= {
	PARAMETER
	MessageWaitListFullParam
	-- optional
	CODE	local:33 }

absentSubscriberSM  ERROR ::= {
	PARAMETER
	AbsentSubscriberSM-Param
	-- optional
	CODE	local:6 }

-- Group Call errors

noGroupCallNumberAvailable  ERROR ::= {
	PARAMETER
	NoGroupCallNbParam
	-- optional
	CODE	local:50 }

ongoingGroupCall  ERROR ::= {
	PARAMETER
	OngoingGroupCallParam
	-- optional
	CODE	local:22 }

-- location service errors

unauthorizedRequestingNetwork  ERROR ::= {
	PARAMETER
	UnauthorizedRequestingNetwork-Param
	-- optional
	CODE	local:52 }

unauthorizedLCSClient  ERROR ::= {
	PARAMETER
	UnauthorizedLCSClient-Param
	-- optional
	CODE	local:53 }

positionMethodFailure  ERROR ::= {
	PARAMETER
	PositionMethodFailure-Param
	-- optional
	CODE	local:54 }

unknownOrUnreachableLCSClient  ERROR ::= {
	PARAMETER
	UnknownOrUnreachableLCSClient-Param
	-- optional
	CODE	local:58 }

mm-EventNotSupported  ERROR ::= {
	PARAMETER
	MM-EventNotSupported-Param
	-- optional
	CODE	local:59 }


.#END
17.6.7	Group Call operations
.$MAP-Group-Call-Operations {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-Group-Call-Operations (22)
   version19 (19)}

DEFINITIONS

::=

BEGIN

EXPORTS
	prepareGroupCall,
	sendGroupCallEndSignal,
	forwardGroupCallSignalling,
	processGroupCallSignalling,
	sendGroupCallInfo
;

IMPORTS
	OPERATION
FROM Remote-Operations-Information-Objects {
joint-iso-itu-t remote-operations(4)
  informationObjects(5) version1(0)}

	systemFailure,
	unexpectedDataValue,
	noGroupCallNumberAvailable,
	ongoingGroupCall,
	unknownSubscriber,
	teleserviceNotProvisioned,
	dataMissing
FROM MAP-Errors {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-Errors (10) version19 (19)}

	PrepareGroupCallArg,
	PrepareGroupCallRes,
	SendGroupCallEndSignalArg,
	SendGroupCallEndSignalRes,
	ForwardGroupCallSignallingArg,
	ProcessGroupCallSignallingArg,
	SendGroupCallInfoArg,
	SendGroupCallInfoRes
FROM MAP-GR-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-GR-DataTypes (23) version19 (19)}

;

prepareGroupCall  OPERATION ::= {	--Timer m
	ARGUMENT
	PrepareGroupCallArg
	RESULT
	PrepareGroupCallRes
	ERRORS {
	systemFailure |
	noGroupCallNumberAvailable |
	unexpectedDataValue}
	CODE	local:39 }

sendGroupCallEndSignal  OPERATION ::= {	--Timer l
	ARGUMENT
	SendGroupCallEndSignalArg
	RESULT
	SendGroupCallEndSignalRes
	CODE	local:40 }

processGroupCallSignalling  OPERATION ::= {	--Timer s
	ARGUMENT
	ProcessGroupCallSignallingArg
	CODE	local:41 }

forwardGroupCallSignalling  OPERATION ::= {	--Timer s
	ARGUMENT
	ForwardGroupCallSignallingArg
	CODE	local:42 }

sendGroupCallInfo  OPERATION ::= {	--Timer m
	ARGUMENT
	SendGroupCallInfoArg
	RESULT
	SendGroupCallInfoRes
	ERRORS {
	systemFailure |
	ongoingGroupCall |
	unexpectedDataValue |
	dataMissing |
	teleserviceNotProvisioned |
	unknownSubscriber}
	CODE	local:84 }


.#END
17.6.8	Location service operations
.$MAP-LocationServiceOperations {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-LocationServiceOperations (24)
   version19 (19)}

DEFINITIONS

::=

BEGIN

EXPORTS
	provideSubscriberLocation,
sendRoutingInfoForLCS,
subscriberLocationReport
;

IMPORTS
	OPERATION
FROM Remote-Operations-Information-Objects {
joint-iso-itu-t remote-operations(4)
  informationObjects(5) version1(0)}

systemFailure,
	dataMissing,
	unexpectedDataValue,
	facilityNotSupported,
	unknownSubscriber,
	absentSubscriber,
	unauthorizedRequestingNetwork,
	unauthorizedLCSClient,
	positionMethodFailure,
	resourceLimitation,
	unknownOrUnreachableLCSClient,
	unidentifiedSubscriber,
	illegalEquipment,
	illegalSubscriber
FROM MAP-Errors {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-Errors (10) version19 (19)}

	RoutingInfoForLCS-Arg,
	RoutingInfoForLCS-Res,
	ProvideSubscriberLocation-Arg,
	ProvideSubscriberLocation-Res,
	SubscriberLocationReport-Arg,
	SubscriberLocationReport-Res
FROM MAP-LCS-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-LCS-DataTypes (25) version19 (19)}
;

sendRoutingInfoForLCS  OPERATION ::= {	--Timer m
	ARGUMENT
	RoutingInfoForLCS-Arg
	RESULT
	RoutingInfoForLCS-Res
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	facilityNotSupported |
	unknownSubscriber |
	absentSubscriber |
	unauthorizedRequestingNetwork }
	CODE	local:85 }

provideSubscriberLocation  OPERATION ::= {	--Timer ml
	ARGUMENT
	ProvideSubscriberLocation-Arg
	RESULT
	ProvideSubscriberLocation-Res
	ERRORS {
	systemFailure |
	dataMissing |
	unexpectedDataValue |
	facilityNotSupported |
	unidentifiedSubscriber |
	illegalSubscriber |
	illegalEquipment |
	absentSubscriber |
	unauthorizedRequestingNetwork |
	unauthorizedLCSClient |
	positionMethodFailure }
	CODE	local:83 }

subscriberLocationReport  OPERATION ::= {	--Timer m
	ARGUMENT
	SubscriberLocationReport-Arg
	RESULT
	SubscriberLocationReport-Res
	ERRORS {
	systemFailure |
	dataMissing |
	resourceLimitation |
	unexpectedDataValue |
	unknownSubscriber |
	unauthorizedRequestingNetwork |
	unknownOrUnreachableLCSClient}
	CODE	local:86 }


.#END

17.6.9	Void

17.7	MAP constants and data types
17.7.1	Mobile Service data types
.$MAP-MS-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-MS-DataTypes (11) version19 (19)}

DEFINITIONS

IMPLICIT TAGS

::=

BEGIN

EXPORTS

	-- location registration types
	UpdateLocationArg,
	UpdateLocationRes,
	CancelLocationArg,
	CancelLocationRes, 
	PurgeMS-Arg, 
	PurgeMS-Res,
	SendIdentificationArg,
	SendIdentificationRes, 
	UpdateGprsLocationArg,
	UpdateGprsLocationRes,
	IST-SupportIndicator, 
	SupportedLCS-CapabilitySets,
	UpdateVcsgLocationArg,
	UpdateVcsgLocationRes,
	CancelVcsgLocationArg,
	CancelVcsgLocationRes,


	-- handover types
	ForwardAccessSignalling-Arg,
	PrepareHO-Arg,
	PrepareHO-Res,
	PrepareSubsequentHO-Arg, 
	PrepareSubsequentHO-Res,
	ProcessAccessSignalling-Arg,
	SendEndSignal-Arg,
	SendEndSignal-Res,

	-- authentication management types
	SendAuthenticationInfoArg,
	SendAuthenticationInfoRes, 
	AuthenticationFailureReportArg,
AuthenticationFailureReportRes,

	-- security management types
	Kc, 
	Cksn,

	-- equipment management types
	CheckIMEI-Arg,
	CheckIMEI-Res,

	-- subscriber management types
	InsertSubscriberDataArg,
	InsertSubscriberDataRes, 
	LSAIdentity,
	DeleteSubscriberDataArg,
	DeleteSubscriberDataRes,
	Ext-QoS-Subscribed,
	Ext2-QoS-Subscribed, 
	Ext3-QoS-Subscribed, 
	Ext4-QoS-Subscribed,
	SubscriberData,
	ODB-Data,
	SubscriberStatus,
	ZoneCodeList,
	maxNumOfZoneCodes, 
	O-CSI, 
D-CSI,
	O-BcsmCamelTDPCriteriaList, 
	T-BCSM-CAMEL-TDP-CriteriaList,
	SS-CSI,
	ServiceKey,
	DefaultCallHandling,
	DefaultSMS-Handling,
	DefaultGPRS-Handling,
	CamelCapabilityHandling,
	BasicServiceCriteria,
	SupportedCamelPhases,
	OfferedCamel4CSIs,
	OfferedCamel4Functionalities,
	maxNumOfCamelTDPData,
	CUG-Index, 
	CUG-Info,
	CUG-Interlock,
	InterCUG-Restrictions,
	IntraCUG-Options,
	NotificationToMSUser, 
	QoS-Subscribed,
IST-AlertTimerValue,
	T-CSI,
	T-BcsmTriggerDetectionPoint,
APN,
AdditionalInfo,

	-- fault recovery types
	ResetArg,
	RestoreDataArg,
	RestoreDataRes,

-- provide subscriber info types 
GeographicalInformation, 
MS-Classmark2,
GPRSMSClass,

	-- subscriber information enquiry types
	ProvideSubscriberInfoArg,
	ProvideSubscriberInfoRes,
	SubscriberInfo,
	LocationInformation,
	LocationInformationGPRS,
	SubscriberState,
	GPRSChargingID, 
MNPInfoRes,
	RouteingNumber,

	-- any time information enquiry types
	AnyTimeInterrogationArg,
	AnyTimeInterrogationRes,

	-- any time information handling types
	AnyTimeSubscriptionInterrogationArg,
	AnyTimeSubscriptionInterrogationRes,
	AnyTimeModificationArg,
	AnyTimeModificationRes,

	-- subscriber data modification notification types
	NoteSubscriberDataModifiedArg,
	NoteSubscriberDataModifiedRes,

	-- gprs location information retrieval types
	SendRoutingInfoForGprsArg,
	SendRoutingInfoForGprsRes,

	-- failure reporting types
	FailureReportArg,
	FailureReportRes,

	-- gprs notification types
	NoteMsPresentForGprsArg,
	NoteMsPresentForGprsRes,

	-- Mobility Management types
NoteMM-EventArg,
	NoteMM-EventRes,
	NumberPortabilityStatus,
	PagingArea,

	-- VGCS / VBS types types
GroupId, 
Long-GroupId,
AdditionalSubscriptions

;

IMPORTS
	maxNumOfSS,
	SS-SubscriptionOption,
	SS-List,
	SS-ForBS-Code,
	Password,
	OverrideCategory,
	CliRestrictionOption
FROM MAP-SS-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-SS-DataTypes (14) version19 (19)}

	SS-Code
FROM MAP-SS-Code {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-SS-Code (15) version19 (19)}

	Ext-BearerServiceCode
FROM MAP-BS-Code {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-BS-Code (20) version19 (19)}

	Ext-TeleserviceCode
FROM MAP-TS-Code {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-TS-Code (19) version19 (19)}

	AddressString,
ISDN-AddressString, 
	ISDN-SubaddressString, 
	FTN-AddressString,
	AccessNetworkSignalInfo,
	IMSI, 
	IMEI,
	TMSI,
	HLR-List,
	LMSI,
	Identity,
	GlobalCellId,
	CellGlobalIdOrServiceAreaIdOrLAI,
	Ext-BasicServiceCode,
	NAEA-PreferredCI,
	EMLPP-Info, 
	MC-SS-Info,
	SubscriberIdentity,
	AgeOfLocationInformation,
	LCSClientExternalID,
	LCSClientInternalID,
	Ext-SS-Status,
	LCSServiceTypeID,
	ASCI-CallReference,
	TBCD-STRING,
	LAIFixedLength,
	PLMN-Id,
EMLPP-Priority,
GSN-Address,
DiameterIdentity,
Time,
E-UTRAN-CGI,
NR-CGI,
TA-Id, 
NR-TA-Id,
RAIdentity,
NetworkNodeDiameterAddress
FROM MAP-CommonDataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-CommonDataTypes (18) version19 (19)}

	ExtensionContainer
FROM MAP-ExtensionDataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version19 (19)}

	AbsentSubscriberDiagnosticSM
FROM MAP-ER-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-ER-DataTypes (17) version19 (19)}

	TracePropagationList
FROM MAP-OM-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-OM-DataTypes (12) version19 (19)}

;

-- location registration types

UpdateLocationArg ::= SEQUENCE {
	imsi	IMSI,
	msc-Number	[1] ISDN-AddressString,
	vlr-Number	ISDN-AddressString,
	lmsi	[10] LMSI	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	... ,
	vlr-Capability	[6] VLR-Capability	OPTIONAL,
	informPreviousNetworkEntity	[11]	NULL	OPTIONAL,
	cs-LCS-NotSupportedByUE	[12]	NULL	OPTIONAL,
	v-gmlc-Address	[2]	GSN-Address	OPTIONAL,
	add-info	[13] ADD-Info	OPTIONAL,
	pagingArea	[14] PagingArea	OPTIONAL,
	skipSubscriberDataUpdate	[15] NULL	OPTIONAL, 
	-- The skipSubscriberDataUpdate parameter in the UpdateLocationArg and the ADD-Info
	-- structures carry the same semantic.
	restorationIndicator	[16]	NULL	OPTIONAL,
	eplmn-List	[3] EPLMN-List	OPTIONAL,
	mme-DiameterAddress	[4] NetworkNodeDiameterAddress	OPTIONAL
	}

VLR-Capability ::= SEQUENCE{
	supportedCamelPhases 	[0] SupportedCamelPhases	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	... ,
	solsaSupportIndicator	[2] NULL	OPTIONAL,
	istSupportIndicator	[1] IST-SupportIndicator	OPTIONAL,
	superChargerSupportedInServingNetworkEntity	[3] SuperChargerInfo	OPTIONAL,
	longFTN-Supported	[4]	NULL	OPTIONAL,
	supportedLCS-CapabilitySets	[5]	SupportedLCS-CapabilitySets	OPTIONAL,
	offeredCamel4CSIs	[6] OfferedCamel4CSIs	OPTIONAL,
	supportedRAT-TypesIndicator	[7]	SupportedRAT-Types	OPTIONAL,
	longGroupID-Supported	[8]	NULL	OPTIONAL,
	mtRoamingForwardingSupported	[9]	NULL	OPTIONAL,
	msisdn-lessOperation-Supported	[10]	NULL	OPTIONAL,
	reset-ids-Supported	[11]	NULL	OPTIONAL }

SupportedRAT-Types::= BIT STRING {
	utran  (0),
	geran  (1),
	gan    (2),
	i-hspa-evolution (3),
	e-utran	(4),
	nb-iot	(5)} (SIZE (2..8))
	-- exception handling: bits 6 to 7 shall be ignored if received and not understood
	


SuperChargerInfo ::= CHOICE {
	sendSubscriberData	[0] NULL,
	subscriberDataStored	[1] AgeIndicator }

AgeIndicator ::= OCTET STRING (SIZE (1..6))
	-- The internal structure of this parameter is implementation specific.

IST-SupportIndicator ::=  ENUMERATED {
	basicISTSupported	(0),
	istCommandSupported	(1),
	...}
-- exception handling:
-- reception of values > 1 shall be mapped to ' istCommandSupported '

SupportedLCS-CapabilitySets ::= BIT STRING {
	lcsCapabilitySet1 (0),
	lcsCapabilitySet2 (1),
	lcsCapabilitySet3 (2),
	lcsCapabilitySet4 (3) ,
	lcsCapabilitySet5 (4) } (SIZE (2..16)) 
-- Core network signalling capability set1 indicates LCS Release98 or Release99 version.
-- Core network signalling capability set2 indicates LCS Release4.
-- Core network signalling capability set3 indicates LCS Release5.
-- Core network signalling capability set4 indicates LCS Release6.
-- Core network signalling capability set5 indicates LCS Release7 or later version.
-- A node shall mark in the BIT STRING all LCS capability sets it supports. 
-- If no bit is set then the sending node does not support LCS.
-- If the parameter is not sent by an VLR then the VLR may support at most capability set1.
-- If the parameter is not sent by an SGSN then no support for LCS is assumed.
-- An SGSN is not allowed to indicate support of capability set1.
-- Other bits than listed above shall be discarded.

UpdateLocationRes ::= SEQUENCE {
	hlr-Number	ISDN-AddressString,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	add-Capability	NULL	OPTIONAL,
	pagingArea-Capability	[0]NULL	OPTIONAL }

ADD-Info ::= SEQUENCE {
	imeisv	[0] IMEI,
	skipSubscriberDataUpdate	[1] NULL	OPTIONAL,
	-- The skipSubscriberDataUpdate parameter in the UpdateLocationArg and the ADD-Info
	-- structures carry the same semantic.
	...}


PagingArea ::= SEQUENCE SIZE (1..5) OF LocationArea 


LocationArea ::= CHOICE {
	laiFixedLength	[0] LAIFixedLength,
	lac	[1] LAC}


LAC ::= OCTET STRING (SIZE (2))
	-- Refers to Location Area Code of the Location Area Identification defined in 
     -- 3GPP TS 23.003 [17].
	-- Location Area Code according to 3GPP TS 24.008 [35]

CancelLocationArg ::= [3] SEQUENCE {
	identity	Identity,
	cancellationType	CancellationType	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	typeOfUpdate	[0] TypeOfUpdate	OPTIONAL,
	mtrf-SupportedAndAuthorized	[1] NULL	OPTIONAL,
	mtrf-SupportedAndNotAuthorized	[2] NULL	OPTIONAL,
	newMSC-Number	[3] ISDN-AddressString	OPTIONAL,
	newVLR-Number	[4] ISDN-AddressString	OPTIONAL,
	new-lmsi	[5] LMSI	OPTIONAL,
	reattach-Required	[6] NULL	OPTIONAL
	}
	--mtrf-SupportedAndAuthorized and mtrf-SupportedAndNotAuthorized shall not
	-- both be present

TypeOfUpdate ::= ENUMERATED {
	sgsn-change (0),
	mme-change (1),
	...}
	-- TypeOfUpdate shall be absent if CancellationType is different from updateProcedure
	-- and initialAttachProcedure

CancellationType ::= ENUMERATED {
	updateProcedure	(0),
	subscriptionWithdraw	(1),
	...,
	initialAttachProcedure               (2)}
	-- The HLR shall not send values other than listed above

CancelLocationRes ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

PurgeMS-Arg ::= [3] SEQUENCE {
	imsi	IMSI,
	vlr-Number	[0] ISDN-AddressString	OPTIONAL,
	sgsn-Number	[1]	ISDN-AddressString	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	locationInformation	[2] LocationInformation	OPTIONAL,
	locationInformationGPRS	[3] LocationInformationGPRS	OPTIONAL,
	locationInformationEPS	[4] LocationInformationEPS	OPTIONAL }

PurgeMS-Res ::= SEQUENCE {
	freezeTMSI	[0]	NULL	OPTIONAL,
	freezeP-TMSI	[1]	NULL	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	freezeM-TMSI	[2]	NULL	OPTIONAL }

SendIdentificationArg ::= SEQUENCE {
	tmsi	TMSI,
	numberOfRequestedVectors	NumberOfRequestedVectors	OPTIONAL,
	-- within a dialogue numberOfRequestedVectors shall be present in 
	-- the first service request and shall not be present in subsequent service requests. 
	-- If received in a subsequent service request it shall be discarded. 
	segmentationProhibited	NULL	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	msc-Number	ISDN-AddressString	OPTIONAL,
	previous-LAI	[0] LAIFixedLength	OPTIONAL,
	hopCounter	[1] HopCounter	OPTIONAL,
	mtRoamingForwardingSupported	[2] NULL	OPTIONAL,
	newVLR-Number	[3] ISDN-AddressString	OPTIONAL,
	new-lmsi	[4] LMSI	OPTIONAL }

HopCounter ::= INTEGER (0..3)

SendIdentificationRes ::= [3] SEQUENCE {
	imsi	IMSI	OPTIONAL,
	-- IMSI shall be present in the first (or only) service response of a dialogue.
	-- If multiple service requests are present in a dialogue then IMSI
	-- shall not be present in any service response other than the first one.
	authenticationSetList	AuthenticationSetList	OPTIONAL,
	currentSecurityContext	[2]CurrentSecurityContext	OPTIONAL,
	extensionContainer	[3] ExtensionContainer	OPTIONAL,
	...,
	lastUsedLtePLMN-Id	[4] PLMN-Id	OPTIONAL,
	mtCallPendingFlag	[5]	NULL	OPTIONAL }

-- authentication management types

AuthenticationSetList ::= CHOICE {
	tripletList	[0] TripletList,
	quintupletList	[1] QuintupletList }

TripletList ::= SEQUENCE SIZE (1..5) OF
	AuthenticationTriplet

QuintupletList ::= SEQUENCE SIZE (1..5) OF
	AuthenticationQuintuplet

AuthenticationTriplet ::= SEQUENCE {
	rand	RAND,
	sres	SRES,
	kc	Kc,
	...}

AuthenticationQuintuplet ::= SEQUENCE {
	rand	RAND,
	xres	XRES,
	ck	CK,
	ik	IK,
	autn	AUTN,
	...}

CurrentSecurityContext ::= CHOICE {
	gsm-SecurityContextData	[0] GSM-SecurityContextData,
	umts-SecurityContextData	[1] UMTS-SecurityContextData }

GSM-SecurityContextData ::= SEQUENCE {
	kc	Kc,
	cksn	Cksn,
	... }

UMTS-SecurityContextData ::= SEQUENCE {
	ck	CK,
	ik	IK,
	ksi	KSI,
	... }

RAND ::= OCTET STRING (SIZE (16))

SRES ::= OCTET STRING (SIZE (4))

Kc ::= OCTET STRING (SIZE (8))

XRES ::= OCTET STRING (SIZE (4..16))

CK ::= OCTET STRING (SIZE (16))

IK ::= OCTET STRING (SIZE (16))

AUTN ::= OCTET STRING (SIZE (16))

AUTS ::= OCTET STRING (SIZE (14))

Cksn ::= OCTET STRING (SIZE (1))
	-- The internal structure is defined in 3GPP TS 24.008

KSI ::= OCTET STRING (SIZE (1))
	-- The internal structure is defined in 3GPP TS 24.008

AuthenticationFailureReportArg ::= SEQUENCE {
	imsi	IMSI,
	failureCause	FailureCause,
	extensionContainer	ExtensionContainer	OPTIONAL,
	... ,
	re-attempt	BOOLEAN	OPTIONAL,
	accessType	AccessType	OPTIONAL,
	rand	RAND	OPTIONAL,
	vlr-Number	[0] ISDN-AddressString	OPTIONAL,
	sgsn-Number	[1] ISDN-AddressString	OPTIONAL }

AccessType ::= ENUMERATED {
	call (0),
	emergencyCall (1),
	locationUpdating (2),
	supplementaryService (3),
	shortMessage (4),
	gprsAttach (5),
	routingAreaUpdating (6),
	serviceRequest (7),
	pdpContextActivation (8),
	pdpContextDeactivation (9),
	...,
	gprsDetach (10)}
	-- exception handling:
	-- received values greater than 10 shall be ignored.

AuthenticationFailureReportRes ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

FailureCause ::= ENUMERATED {
	wrongUserResponse  (0),
	wrongNetworkSignature  (1)}

-- gprs location registration types

UpdateGprsLocationArg ::= SEQUENCE {
	imsi	IMSI,
	sgsn-Number	ISDN-AddressString,	
	sgsn-Address	GSN-Address,
	extensionContainer	ExtensionContainer	OPTIONAL,
	... ,
	sgsn-Capability	[0] SGSN-Capability	OPTIONAL,
	informPreviousNetworkEntity	[1]	NULL	OPTIONAL,
	ps-LCS-NotSupportedByUE	[2]	NULL	OPTIONAL,
	v-gmlc-Address	[3]	GSN-Address	OPTIONAL,
	add-info	[4]  ADD-Info	OPTIONAL,
	eps-info	[5]	EPS-Info	OPTIONAL,
	servingNodeTypeIndicator	[6]	NULL	OPTIONAL,
	skipSubscriberDataUpdate	[7] NULL	OPTIONAL,
	usedRAT-Type	[8] Used-RAT-Type	OPTIONAL,
	gprsSubscriptionDataNotNeeded	[9] NULL	OPTIONAL,
	nodeTypeIndicator	[10] NULL	OPTIONAL,
	areaRestricted	[11] NULL	OPTIONAL,
	ue-reachableIndicator	[12]	NULL	OPTIONAL, 
	epsSubscriptionDataNotNeeded	[13] NULL	OPTIONAL,
	ue-srvcc-Capability	[14] UE-SRVCC-Capability	OPTIONAL,
	eplmn-List	[15] EPLMN-List	OPTIONAL,
	mmeNumberforMTSMS	[16] ISDN-AddressString	OPTIONAL,
	smsRegisterRequest	[17] SMSRegisterRequest	OPTIONAL,
	sms-Only	[18] NULL	OPTIONAL,
	removalofMMERegistrationforSMS	[22] NULL	OPTIONAL,
	sgsn-Name	[19] DiameterIdentity	OPTIONAL,
	sgsn-Realm	[20]	DiameterIdentity	OPTIONAL,
	lgd-supportIndicator	[21] NULL	OPTIONAL,
	adjacentPLMN-List	[23] AdjacentPLMN-List	OPTIONAL }

SMSRegisterRequest::= ENUMERATED {
	sms-registration-required  (0),
	sms-registration-not-preferred  (1),
	no-preference  (2),
	...}

Used-RAT-Type::= ENUMERATED {
	utran  (0),
	geran  (1),
	gan    (2),
	i-hspa-evolution (3),
	e-utran	(4),
	...,
	nb-iot	(5)}
	-- The value e-utran indicates wide-band e-utran

EPS-Info ::= CHOICE{
	pdn-gw-update	[0] PDN-GW-Update,
	isr-Information	[1] ISR-Information }

PDN-GW-Update ::= SEQUENCE{
	apn	[0] APN	OPTIONAL,
	pdn-gw-Identity	[1] PDN-GW-Identity	OPTIONAL,
	contextId	[2] ContextId                     OPTIONAL,
	extensionContainer	[3] ExtensionContainer	OPTIONAL,
	... }
--	The pdn-gw-update IE shall include the pdn-gw-Identity, and the apn or/and the contextID. 
--	The HSS shall ignore the eps-info IE if it includes a pdn-gw-update IE which does not 
--	include pdn-gw-Identity.
--	The pdn-gw-Identity is defined as OPTIONAL for backward compatility reason with  
--	outdated earlier versions of this specification.


ISR-Information::= BIT STRING {
	updateLocation  (0),
	cancelSGSN  (1),
	initialAttachIndicator  (2)} (SIZE (3..8))
	-- exception handling: reception of unknown bit assignments in the
	-- ISR-Information data type shall be discarded by the receiver 

SGSN-Capability ::= SEQUENCE{
	solsaSupportIndicator	NULL	OPTIONAL,
	extensionContainer	[1] ExtensionContainer	OPTIONAL,
	... ,
	superChargerSupportedInServingNetworkEntity	[2] SuperChargerInfo	OPTIONAL ,
	gprsEnhancementsSupportIndicator	[3] NULL	OPTIONAL,
	supportedCamelPhases 	[4] SupportedCamelPhases	OPTIONAL,
	supportedLCS-CapabilitySets	[5]  SupportedLCS-CapabilitySets	OPTIONAL,
	offeredCamel4CSIs	[6] OfferedCamel4CSIs	OPTIONAL,
	smsCallBarringSupportIndicator	[7]	NULL	OPTIONAL,	supportedRAT-TypesIndicator	[8]	SupportedRAT-Types	OPTIONAL,
	supportedFeatures	[9] SupportedFeatures	OPTIONAL,
	t-adsDataRetrieval	[10] NULL	OPTIONAL,
	homogeneousSupportOfIMSVoiceOverPSSessions [11] BOOLEAN	OPTIONAL,
	--	"true" indicates homogeneous support, "false" indicates homogeneous non-support
	--	in the complete SGSN or MME area
	cancellationTypeInitialAttach	[12]	NULL	OPTIONAL,
	msisdn-lessOperation-Supported	[14]	NULL	OPTIONAL,
	updateofHomogeneousSupportOfIMSVoiceOverPSSessions [15] NULL	OPTIONAL,
	reset-ids-Supported	[16]	NULL	OPTIONAL,
	ext-SupportedFeatures	[17]	Ext-SupportedFeatures	OPTIONAL
	}
	--	the supportedFeatures , t-adsDataRetrieval, 
	--	homogeneousSupportOfIMSVoiceOverPSSessions
	--	/updateofHomogeneousSupportOfIMSVoiceOverPSSessions and
	--	ext-SupportedFeatures are also applied to the MME/IWF

SupportedFeatures::= BIT STRING {
	odb-all-apn (0),
	odb-HPLMN-APN (1),
	odb-VPLMN-APN (2),
	odb-all-og (3),
	odb-all-international-og (4),
	odb-all-int-og-not-to-HPLMN-country (5),
	odb-all-interzonal-og (6),
	odb-all-interzonal-og-not-to-HPLMN-country (7),
	odb-all-interzonal-og-and-internat-og-not-to-HPLMN-country (8),
	regSub (9),
	trace (10),
	lcs-all-PrivExcep (11),
	lcs-universal (12),
	lcs-CallSessionRelated (13),
	lcs-CallSessionUnrelated (14),
	lcs-PLMN-operator (15),
	lcs-ServiceType (16),
	lcs-all-MOLR-SS (17),
	lcs-basicSelfLocation (18),
	lcs-autonomousSelfLocation (19),
	lcs-transferToThirdParty (20),
	sm-mo-pp (21),
	barring-OutgoingCalls (22),
	baoc (23),
	boic (24),
	boicExHC (25),
	localTimeZoneRetrieval (26),
	additionalMsisdn (27),
	smsInMME (28),
	smsInSGSN (29),
	ue-Reachability-Notification (30),
	state-Location-Information-Retrieval (31),
	partialPurge (32),
	gddInSGSN (33),
	sgsnCAMELCapability (34),
	pcscf-Restoration (35),
	dedicatedCoreNetworks (36), 
	non-IP-PDN-Type-APNs (37),
	non-IP-PDP-Type-APNs (38),
	nrAsSecondaryRAT (39) } (SIZE (26..40))
	--	for the definition and usage of the above features see the 3GPP TS 29.272 [144].
	--	Additional supported features are encoded in Ext-SupportedFeatures bit string.


Ext-SupportedFeatures ::= BIT STRING {
	unlicensedSpectrumAsSecondaryRAT (0) } (SIZE (1..40))

UE-SRVCC-Capability::= ENUMERATED {
	ue-srvcc-not-supported  (0),
	ue-srvcc-supported  (1),
	...}

UpdateGprsLocationRes ::= SEQUENCE {
	hlr-Number	ISDN-AddressString,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	add-Capability	NULL	OPTIONAL,
	sgsn-mmeSeparationSupported	[0] NULL	OPTIONAL,
	mmeRegisteredforSMS	[1] NULL	OPTIONAL }

EPLMN-List ::= SEQUENCE SIZE (1..50) OF
	PLMN-Id

AdjacentPLMN-List ::= SEQUENCE SIZE (1..50) OF
	PLMN-Id


-- handover types

ForwardAccessSignalling-Arg ::= [3] SEQUENCE {
	an-APDU	AccessNetworkSignalInfo,
	integrityProtectionInfo	[0] IntegrityProtectionInformation	OPTIONAL,
	encryptionInfo	[1] EncryptionInformation	OPTIONAL,
	keyStatus	[2]	KeyStatus	OPTIONAL,
	allowedGSM-Algorithms	[4]	AllowedGSM-Algorithms	OPTIONAL,
	allowedUMTS-Algorithms	[5]	AllowedUMTS-Algorithms	OPTIONAL,
	radioResourceInformation	[6] RadioResourceInformation	OPTIONAL,
	extensionContainer	[3]	ExtensionContainer	OPTIONAL,
	...,
	radioResourceList	[7]	RadioResourceList	OPTIONAL,
	bssmap-ServiceHandover	[9]	BSSMAP-ServiceHandover	OPTIONAL,
	ranap-ServiceHandover	[8]	RANAP-ServiceHandover	OPTIONAL,
	bssmap-ServiceHandoverList	[10]	BSSMAP-ServiceHandoverList	OPTIONAL,
	currentlyUsedCodec	[11] Codec	OPTIONAL,
	iuSupportedCodecsList	[12] SupportedCodecsList	OPTIONAL,
	rab-ConfigurationIndicator	[13] NULL	OPTIONAL,
	iuSelectedCodec	[14]	Codec	OPTIONAL,
	alternativeChannelType	[15]	RadioResourceInformation	OPTIONAL,
	tracePropagationList	[17]	TracePropagationList	OPTIONAL,
	aoipSupportedCodecsListAnchor	[18] AoIPCodecsList	OPTIONAL,
	aoipSelectedCodecTarget	[19] AoIPCodec	OPTIONAL,
	uesbi-Iu	[20]	UESBI-Iu	OPTIONAL,
	imeisv	[21]	IMEI	OPTIONAL }

AllowedGSM-Algorithms ::= OCTET STRING (SIZE (1))
	-- internal structure is coded as Algorithm identifier octet from
	-- Permitted Algorithms defined in 3GPP TS 48.008
	-- A node shall mark all GSM algorithms that are allowed in MSC-B

AllowedUMTS-Algorithms ::= SEQUENCE {
	integrityProtectionAlgorithms	[0]	PermittedIntegrityProtectionAlgorithms	OPTIONAL,
	encryptionAlgorithms	[1]	PermittedEncryptionAlgorithms	OPTIONAL,
	extensionContainer	[2]	ExtensionContainer	OPTIONAL,
	...}

PermittedIntegrityProtectionAlgorithms ::=
	OCTET STRING (SIZE (1..maxPermittedIntegrityProtectionAlgorithmsLength))
	-- Octets contain a complete PermittedIntegrityProtectionAlgorithms data type 
	-- as defined in 3GPP TS 25.413, encoded according to the encoding scheme 
	-- mandated by 3GPP TS 25.413. 
	-- Padding bits are included, if needed, in the least significant bits of the 
	-- last octet of the octet string. 


maxPermittedIntegrityProtectionAlgorithmsLength INTEGER ::= 9

PermittedEncryptionAlgorithms ::=
	OCTET STRING (SIZE (1..maxPermittedEncryptionAlgorithmsLength))
	-- Octets contain a complete PermittedEncryptionAlgorithms data type 
	-- as defined in 3GPP TS 25.413, encoded according to the encoding scheme 
	-- mandated by 3GPP TS 25.413
	-- Padding bits are included, if needed, in the least significant bits of the 
	-- last octet of the octet string. 


maxPermittedEncryptionAlgorithmsLength INTEGER ::= 9

KeyStatus ::= ENUMERATED {
	old  (0),
	new  (1),
	...}
	-- exception handling:
	-- received values in range 2-31 shall be treated as "old"
	-- received values greater than 31 shall be treated as "new"

PrepareHO-Arg ::= [3] SEQUENCE {
	targetCellId	[0] GlobalCellId	OPTIONAL,
	ho-NumberNotRequired	NULL	OPTIONAL, 
	targetRNCId	[1] RNCId	OPTIONAL,
	an-APDU	[2] AccessNetworkSignalInfo	OPTIONAL,
	multipleBearerRequested	[3] NULL	OPTIONAL,
	imsi	[4] IMSI	OPTIONAL,
	integrityProtectionInfo	[5] IntegrityProtectionInformation	OPTIONAL,
	encryptionInfo	[6] EncryptionInformation	OPTIONAL,
	radioResourceInformation	[7] RadioResourceInformation	OPTIONAL,
	allowedGSM-Algorithms	[9]	AllowedGSM-Algorithms	OPTIONAL,
	allowedUMTS-Algorithms	[10]	AllowedUMTS-Algorithms	OPTIONAL,
	radioResourceList	[11] RadioResourceList	OPTIONAL,
	extensionContainer	[8] ExtensionContainer	OPTIONAL,
	... ,
	rab-Id	[12] RAB-Id	OPTIONAL,
	bssmap-ServiceHandover	[13]	BSSMAP-ServiceHandover	OPTIONAL,
	ranap-ServiceHandover	[14]	RANAP-ServiceHandover	OPTIONAL, 
	bssmap-ServiceHandoverList	[15]	BSSMAP-ServiceHandoverList	OPTIONAL,
	asciCallReference	[20]	ASCI-CallReference	OPTIONAL,
	geran-classmark	[16] GERAN-Classmark	OPTIONAL,
	iuCurrentlyUsedCodec	[17] Codec	OPTIONAL,
	iuSupportedCodecsList	[18] SupportedCodecsList	OPTIONAL,
	rab-ConfigurationIndicator	[19] NULL	OPTIONAL,
	uesbi-Iu	[21]	UESBI-Iu	OPTIONAL,
	imeisv	[22]	IMEI	OPTIONAL,
	alternativeChannelType	[23]	RadioResourceInformation	OPTIONAL,
	tracePropagationList	[25]	TracePropagationList	OPTIONAL,
	aoipSupportedCodecsListAnchor	[26] AoIPCodecsList	OPTIONAL,
	regionalSubscriptionData	[27] ZoneCodeList	OPTIONAL,
	lclsGlobalCallReference	[28]	LCLS-GlobalCallReference	OPTIONAL,
	lcls-Negotiation	[29]	LCLS-Negotiation	OPTIONAL,
	lcls-Configuration-Preference	[30]	LCLS-ConfigurationPreference	OPTIONAL,
	csg-SubscriptionDataList	[31] CSG-SubscriptionDataList	OPTIONAL
	}

LCLS-GlobalCallReference ::= OCTET STRING (SIZE (13..15))
	-- Octets are coded as specified in 3GPP TS 29.205 [146]


LCLS-Negotiation::= BIT STRING {
	permission-indicator-not-allowed-bit	(0),
	permission-indicator-spare-bit	(1)} (SIZE (2..8))
	--for definition and allowed combination of bits 0 and 1 see 3GPP TS 29.205
	-- exception handling: bits 2 to 7 shall be ignored if received and not understood
	

LCLS-ConfigurationPreference::= BIT STRING {
	forward-data-sending-indicator	(0),
	backward-data-sending-indicator	(1),
	forward-data-reception-indicator	(2),
	backward-data-reception-indicator	(3)} (SIZE (4..8))
	-- exception handling: bits 4 to 7 shall be ignored if received and not understood
	

BSSMAP-ServiceHandoverList ::= SEQUENCE SIZE (1.. maxNumOfServiceHandovers) OF
	BSSMAP-ServiceHandoverInfo

BSSMAP-ServiceHandoverInfo ::= SEQUENCE {
	bssmap-ServiceHandover	BSSMAP-ServiceHandover,
	rab-Id	RAB-Id,
	-- RAB Identity is needed to relate the service handovers with the radio access bearers. 
	...}

maxNumOfServiceHandovers  INTEGER ::= 7

BSSMAP-ServiceHandover ::= OCTET STRING (SIZE (1))
	-- Octets are coded according the Service Handover information element in
	-- 3GPP TS 48.008.

RANAP-ServiceHandover ::= OCTET STRING (SIZE (1))
	-- Octet contains a complete Service-Handover data type 
	-- as defined in 3GPP TS 25.413, encoded according to the encoding scheme 
	-- mandated by 3GPP TS 25.413
	-- Padding bits are included in the least significant bits. 


RadioResourceList ::= SEQUENCE SIZE (1.. maxNumOfRadioResources) OF
	RadioResource

RadioResource ::= SEQUENCE {
	radioResourceInformation	RadioResourceInformation,
	rab-Id	RAB-Id,
	-- RAB Identity is needed to relate the radio resources with the radio access bearers. 
	...}

maxNumOfRadioResources  INTEGER ::= 7

PrepareHO-Res ::= [3] SEQUENCE {
	handoverNumber	[0] ISDN-AddressString	OPTIONAL,
	relocationNumberList	[1]	RelocationNumberList	OPTIONAL,
	an-APDU	[2]	AccessNetworkSignalInfo	OPTIONAL,
	multicallBearerInfo	[3]	MulticallBearerInfo	OPTIONAL,
	multipleBearerNotSupported	NULL	OPTIONAL,
	selectedUMTS-Algorithms	[5]	SelectedUMTS-Algorithms	OPTIONAL,
	chosenRadioResourceInformation	[6] ChosenRadioResourceInformation	OPTIONAL,
	extensionContainer	[4]	ExtensionContainer	OPTIONAL,
	...,
	iuSelectedCodec	[7] Codec	OPTIONAL,
	iuAvailableCodecsList	[8] CodecList	OPTIONAL,
	aoipSelectedCodecTarget	[9] AoIPCodec	OPTIONAL,
	aoipAvailableCodecsListMap	[10] AoIPCodecsList	OPTIONAL }

SelectedUMTS-Algorithms ::= SEQUENCE {
	integrityProtectionAlgorithm	[0]	ChosenIntegrityProtectionAlgorithm	OPTIONAL,
	encryptionAlgorithm	[1]	ChosenEncryptionAlgorithm	OPTIONAL,
	extensionContainer	[2]	ExtensionContainer	OPTIONAL,
	...}

ChosenIntegrityProtectionAlgorithm ::= OCTET STRING (SIZE (1))
	-- Octet contains a complete IntegrityProtectionAlgorithm data type 
	-- as defined in 3GPP TS 25.413, encoded according to the encoding scheme 
	-- mandated by 3GPP TS 25.413
	-- Padding bits are included in the least significant bits. 

ChosenEncryptionAlgorithm ::= OCTET STRING (SIZE (1))
	-- Octet contains a complete EncryptionAlgorithm data type 
	-- as defined in 3GPP TS 25.413, encoded according to the encoding scheme 
	-- mandated by 3GPP TS 25.413
	-- Padding bits are included in the least significant bits. 

ChosenRadioResourceInformation ::= SEQUENCE {
	chosenChannelInfo	[0] ChosenChannelInfo	OPTIONAL,
	chosenSpeechVersion	[1] ChosenSpeechVersion	OPTIONAL,
	...}

ChosenChannelInfo ::= OCTET STRING (SIZE (1))
	-- Octets are coded according the Chosen Channel information element in 3GPP TS 48.008

ChosenSpeechVersion ::= OCTET STRING (SIZE (1))
	-- Octets are coded according the Speech Version (chosen) information element in 3GPP TS
	-- 48.008 

PrepareSubsequentHO-Arg ::= [3] SEQUENCE {
	targetCellId	[0] GlobalCellId	OPTIONAL,
	targetMSC-Number	[1] ISDN-AddressString,
	targetRNCId	[2] RNCId	OPTIONAL,
	an-APDU	[3]	AccessNetworkSignalInfo	OPTIONAL,
	selectedRab-Id	[4]	RAB-Id	OPTIONAL,
	extensionContainer	[5]	ExtensionContainer	OPTIONAL,
	...,
	geran-classmark	[6] GERAN-Classmark	OPTIONAL,
	rab-ConfigurationIndicator	[7] NULL	OPTIONAL }

PrepareSubsequentHO-Res ::= [3] SEQUENCE {
	an-APDU	AccessNetworkSignalInfo,
	extensionContainer	[0]	ExtensionContainer	OPTIONAL,
	...}

ProcessAccessSignalling-Arg ::= [3] SEQUENCE {
	an-APDU	AccessNetworkSignalInfo,
	selectedUMTS-Algorithms	[1]	SelectedUMTS-Algorithms	OPTIONAL,
	selectedGSM-Algorithm	[2]	SelectedGSM-Algorithm	OPTIONAL,
	chosenRadioResourceInformation	[3] ChosenRadioResourceInformation OPTIONAL,
	selectedRab-Id	[4] RAB-Id	OPTIONAL,
	extensionContainer	[0]	ExtensionContainer	OPTIONAL,
	...,
	iUSelectedCodec	[5] Codec	OPTIONAL,
	iuAvailableCodecsList	[6] CodecList	OPTIONAL,
	aoipSelectedCodecTarget	[7] AoIPCodec	OPTIONAL,
	aoipAvailableCodecsListMap	[8] AoIPCodecsList	OPTIONAL }

AoIPCodecsList ::= SEQUENCE {
	codec1	[1] AoIPCodec,
	codec2	[2] AoIPCodec	OPTIONAL,
	codec3	[3] AoIPCodec	OPTIONAL,
	codec4	[4] AoIPCodec	OPTIONAL,
	codec5	[5] AoIPCodec	OPTIONAL,
	codec6	[6] AoIPCodec	OPTIONAL,
	codec7	[7] AoIPCodec	OPTIONAL,
	codec8	[8] AoIPCodec	OPTIONAL,
	extensionContainer	[9] ExtensionContainer	OPTIONAL,
	...}
	-- Codecs are sent in priority order where codec1 has highest priority

AoIPCodec ::= OCTET STRING (SIZE (1..3))

	-- The internal structure is defined as follows:
	-- octet 1	Coded as Speech Codec Elements in 3GPP TS 48.008
	--	with the exception that FI, PI, PT and TF bits shall
	--	be set to 0
	-- octets 2,3	Optional; in case of AMR codec types it defines
	--	the supported codec configurations as defined in
	--	3GPP TS 48.008

SupportedCodecsList ::= SEQUENCE {
	utranCodecList	[0] CodecList	OPTIONAL,
	geranCodecList	[1] CodecList	OPTIONAL,
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	...}

CodecList ::= SEQUENCE {
	codec1	[1] Codec,
	codec2	[2] Codec	OPTIONAL,
	codec3	[3] Codec	OPTIONAL,
	codec4	[4] Codec	OPTIONAL,
	codec5	[5] Codec	OPTIONAL,
	codec6	[6] Codec	OPTIONAL,
	codec7	[7] Codec	OPTIONAL,
	codec8	[8] Codec	OPTIONAL,
	extensionContainer	[9] ExtensionContainer	OPTIONAL,
	...}
	-- Codecs are sent in priority order where codec1 has highest priority

Codec ::= OCTET STRING (SIZE (1..4))

	-- The internal structure is defined as follows:
	-- octet 1	Coded as Codec Identification code in 3GPP TS 26.103
	-- octets 2,3,4	Parameters for the Codec as defined in 3GPP TS
	--	26.103, if available, length depending on the codec

GERAN-Classmark ::= OCTET STRING (SIZE (2..87))
	-- Octets are coded according the GERAN Classmark information element in 3GPP TS 48.008

SelectedGSM-Algorithm ::= OCTET STRING (SIZE (1))
	-- internal structure is coded as Algorithm identifier octet from Chosen Encryption
	-- Algorithm defined in 3GPP TS 48.008
	-- A node shall mark only the selected GSM algorithm

SendEndSignal-Arg ::= [3] SEQUENCE {
	an-APDU	AccessNetworkSignalInfo,
	extensionContainer	[0]	ExtensionContainer	OPTIONAL,
	...}

SendEndSignal-Res ::= SEQUENCE {
	extensionContainer	[0]	ExtensionContainer	OPTIONAL,
	...}

RNCId ::= OCTET STRING (SIZE (7))
	-- The internal structure is defined as follows:
	-- octet 1 bits 4321	Mobile Country Code 1st digit
	--         bits 8765	Mobile Country Code 2nd digit
	-- octet 2 bits 4321	Mobile Country Code 3rd digit
	--         bits 8765	Mobile Network Code 3rd digit
	--	or filler (1111) for 2 digit MNCs
	-- octet 3 bits 4321	Mobile Network Code 1st digit
	--         bits 8765	Mobile Network Code 2nd digit
	-- octets 4 and 5	Location Area Code according to 3GPP TS 24.008
	-- octets 6 and 7	RNC Id or Extended RNC Id value according to
	--	3GPP TS 25.413

RelocationNumberList ::= SEQUENCE SIZE (1..maxNumOfRelocationNumber) OF
	RelocationNumber

MulticallBearerInfo ::= INTEGER (1..maxNumOfRelocationNumber)

RelocationNumber ::= SEQUENCE {
	handoverNumber	ISDN-AddressString,
	rab-Id	RAB-Id,
	-- RAB Identity is needed to relate the calls with the radio access bearers. 
	...}

RAB-Id ::= INTEGER (1..maxNrOfRABs)

maxNrOfRABs INTEGER ::= 255

maxNumOfRelocationNumber  INTEGER ::= 7

RadioResourceInformation ::= OCTET STRING (SIZE (3..13))
	-- Octets are coded according the Channel Type information element in 3GPP TS 48.008

IntegrityProtectionInformation ::= OCTET STRING (SIZE (18..maxNumOfIntegrityInfo))
	-- Octets contain a complete IntegrityProtectionInformation data type 
	-- as defined in 3GPP TS 25.413, encoded according to the encoding scheme 
	-- mandated by 3GPP TS 25.413
	-- Padding bits are included, if needed, in the least significant bits of the 
	-- last octet of the octet string. 

maxNumOfIntegrityInfo INTEGER ::= 100

EncryptionInformation ::= OCTET STRING (SIZE (18..maxNumOfEncryptionInfo))
	-- Octets contain a complete EncryptionInformation data type 
	-- as defined in 3GPP TS 25.413, encoded according to the encoding scheme 
	-- mandated by 3GPP TS 25.413
	-- Padding bits are included, if needed, in the least significant bits of the 
	-- last octet of the octet string. 

maxNumOfEncryptionInfo INTEGER ::= 100

-- authentication management types

SendAuthenticationInfoArg ::= SEQUENCE {
	imsi	[0] IMSI,
	numberOfRequestedVectors	NumberOfRequestedVectors,
	segmentationProhibited	NULL	OPTIONAL,
	immediateResponsePreferred	[1] NULL	OPTIONAL,
	re-synchronisationInfo	Re-synchronisationInfo	OPTIONAL,
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	...,
	requestingNodeType	[3] RequestingNodeType	OPTIONAL,
	requestingPLMN-Id	[4] PLMN-Id	OPTIONAL,
	numberOfRequestedAdditional-Vectors	[5] NumberOfRequestedVectors	OPTIONAL,
	additionalVectorsAreForEPS	[6] NULL	OPTIONAL,
	ueUsageTypeRequestIndication	[7] NULL	OPTIONAL }	


NumberOfRequestedVectors ::= INTEGER (1..5)

Re-synchronisationInfo ::= SEQUENCE {
	rand	RAND,
	auts	AUTS,
	...}

SendAuthenticationInfoRes ::= [3] SEQUENCE {
	authenticationSetList	AuthenticationSetList	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	eps-AuthenticationSetList	[2] EPS-AuthenticationSetList	OPTIONAL,
	ueUsageType	[3] UE-UsageType	OPTIONAL }

EPS-AuthenticationSetList ::= SEQUENCE SIZE (1..5) OF
	EPC-AV

UE-UsageType::= OCTET STRING (SIZE (4))
	-- octets are coded as defined in 3GPP TS 29.272 [144] 

EPC-AV ::= SEQUENCE {
	rand	RAND,
	xres	XRES,
	autn	AUTN,
	kasme	KASME,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

KASME ::= OCTET STRING (SIZE (32))

RequestingNodeType ::= ENUMERATED {
	vlr  (0),
	sgsn  (1),
	...,
	s-cscf  (2),
	bsf  (3),
	gan-aaa-server  (4),
	wlan-aaa-server  (5),
	mme	(16),
	mme-sgsn	(17)
	}
	-- the values 2, 3, 4 and 5 shall not be used on the MAP-D or Gr interfaces
	-- exception handling:
	-- received values in the range (6-15) shall be treated as "vlr"
	-- received values greater than 17 shall be treated as "sgsn"

-- equipment management types

CheckIMEI-Arg ::= SEQUENCE {
	imei	IMEI,
	requestedEquipmentInfo	RequestedEquipmentInfo,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

CheckIMEI-Res ::= SEQUENCE {
	equipmentStatus	EquipmentStatus	OPTIONAL,
	bmuef	UESBI-Iu	OPTIONAL,
	extensionContainer	[0] ExtensionContainer	OPTIONAL,
	...}

RequestedEquipmentInfo::= BIT STRING {
	equipmentStatus  (0),
	bmuef  (1)} (SIZE (2..8))
	-- exception handling: reception of unknown bit assignments in the
	-- RequestedEquipmentInfo data type shall be discarded by the receiver 

UESBI-Iu ::= SEQUENCE {
	uesbi-IuA	[0] UESBI-IuA	OPTIONAL,
	uesbi-IuB	[1] UESBI-IuB	OPTIONAL,
	...}

UESBI-IuA	::= BIT STRING (SIZE(1..128))
-- See 3GPP TS 25.413

UESBI-IuB	::= BIT STRING (SIZE(1..128))
-- See 3GPP TS 25.413

EquipmentStatus ::= ENUMERATED {
	whiteListed  (0),
	blackListed  (1),
	greyListed  (2)}

-- subscriber management types

InsertSubscriberDataArg ::= SEQUENCE {
	imsi	[0] IMSI	OPTIONAL,
	COMPONENTS OF	SubscriberData,
	extensionContainer	[14] ExtensionContainer	OPTIONAL,
	... ,	
	naea-PreferredCI	[15] NAEA-PreferredCI	OPTIONAL,
	-- naea-PreferredCI is included at the discretion of the HLR operator.
	gprsSubscriptionData	[16] GPRSSubscriptionData	OPTIONAL,
	roamingRestrictedInSgsnDueToUnsupportedFeature [23]	NULL	
		OPTIONAL, 
	networkAccessMode	[24] NetworkAccessMode	OPTIONAL,
	lsaInformation	[25] LSAInformation	OPTIONAL,
	lmu-Indicator	[21]	NULL	OPTIONAL,
	lcsInformation	[22]	LCSInformation	OPTIONAL,
	istAlertTimer	[26] IST-AlertTimerValue	OPTIONAL,
	superChargerSupportedInHLR	[27] AgeIndicator	OPTIONAL,
	mc-SS-Info	[28] MC-SS-Info	OPTIONAL,
	cs-AllocationRetentionPriority	[29] CS-AllocationRetentionPriority	OPTIONAL,
	sgsn-CAMEL-SubscriptionInfo	[17] SGSN-CAMEL-SubscriptionInfo	OPTIONAL,
	chargingCharacteristics	[18]	ChargingCharacteristics	OPTIONAL,
	accessRestrictionData	[19] AccessRestrictionData	OPTIONAL,
	ics-Indicator	[20]	BOOLEAN	OPTIONAL,
	eps-SubscriptionData	[31]	EPS-SubscriptionData	OPTIONAL,
	csg-SubscriptionDataList	[32] CSG-SubscriptionDataList	OPTIONAL,
	ue-ReachabilityRequestIndicator	[33]	NULL	OPTIONAL,
	sgsn-Number	[34]	ISDN-AddressString	OPTIONAL,
	mme-Name	[35]	DiameterIdentity	OPTIONAL,
	subscribedPeriodicRAUTAUtimer	[36]	SubscribedPeriodicRAUTAUtimer	OPTIONAL,
	vplmnLIPAAllowed	[37]	NULL	OPTIONAL,
	mdtUserConsent	[38]	BOOLEAN	OPTIONAL,
	subscribedPeriodicLAUtimer	[39]	SubscribedPeriodicLAUtimer	OPTIONAL,
	vplmn-Csg-SubscriptionDataList	[40]	VPLMN-CSG-SubscriptionDataList	OPTIONAL,
	additionalMSISDN	[41]	ISDN-AddressString	OPTIONAL,
	psAndSMS-OnlyServiceProvision	[42]	NULL	OPTIONAL,
	smsInSGSNAllowed	[43]	NULL	OPTIONAL,
	cs-to-ps-SRVCC-Allowed-Indicator	[44]	NULL	OPTIONAL,
	pcscf-Restoration-Request	[45]	NULL	OPTIONAL,
	adjacentAccessRestrictionDataList	[46] AdjacentAccessRestrictionDataList	OPTIONAL,
	imsi-Group-Id-List	[47] IMSI-GroupIdList	OPTIONAL,
	ueUsageType	[48] UE-UsageType	OPTIONAL,
	userPlaneIntegrityProtectionIndicator	[49] NULL	OPTIONAL,
	dl-Buffering-Suggested-Packet-Count	[50]	DL-Buffering-Suggested-Packet-Count	OPTIONAL,
	reset-Id-List	[51]	Reset-Id-List	OPTIONAL,
	eDRX-Cycle-Length-List	[52] EDRX-Cycle-Length-List	OPTIONAL,
	ext-AccessRestrictionData	[53] Ext-AccessRestrictionData	OPTIONAL,
	iab-Operation-Allowed-Indicator	[54]	NULL	OPTIONAL }
	-- If the Network Access Mode parameter is sent, it shall be present only in 
	-- the first sequence if seqmentation is used

EDRX-Cycle-Length-List ::= SEQUENCE SIZE (1..8) OF
	EDRX-Cycle-Length

EDRX-Cycle-Length ::= SEQUENCE {
	rat-Type	[0]	Used-RAT-Type,
	eDRX-Cycle-Length-Value	[1]	EDRX-Cycle-Length-Value,
	...}
	-- The eDRX-Cycle-Length contains the subscribed eDRX-Cycle-Length applicable to a 
	-- a specific RAT Type.


EDRX-Cycle-Length-Value ::= OCTET STRING (SIZE (1))
	-- The EDRX-Cycle-Length-Value shall be encoded as specified in clause 7.3.216 of 
	-- 3GPP TS 29.272 [144]. 


Reset-Id-List ::= SEQUENCE SIZE (1..50) OF
	Reset-Id

Reset-Id ::= OCTET STRING (SIZE (1..4)) 
	-- Reset-Ids shall be unique within the HPLMN.


DL-Buffering-Suggested-Packet-Count ::= INTEGER (-1..2147483647)
	-- values are defined in 3GPP TS 29.272 [144]
	

Group-Service-ID ::= INTEGER (0..4294967295)
	-- values are defined in 3GPP TS 29.272 [144]
	

Local-GroupID ::= OCTET STRING (SIZE (1..10)) 
	-- Refers to Local group ID defined by an operator identified by the PLMN-ID.
	--	for details see 3GPP TS 29.272 [144]

IMSI-GroupIdList ::= SEQUENCE SIZE (1..50) OF
	IMSI-GroupId

IMSI-GroupId ::= SEQUENCE {
	group-Service-Id	[0]	Group-Service-ID,
	plmnId	[1]	PLMN-Id,
	local-Group-ID	[2]	Local-GroupID,
	...}

SubscribedPeriodicRAUTAUtimer ::= INTEGER (0..4294967295)
	-- This parameter carries the subscribed periodic TAU/RAU timer value in seconds as
	-- specified in 3GPP TS 24.008 [35].

SubscribedPeriodicLAUtimer ::= INTEGER (0..4294967295)
	-- This parameter carries the subscribed periodic LAU timer value in seconds as 
	-- specified in 3GPP TS 24.008 [35].

CSG-SubscriptionDataList ::= SEQUENCE SIZE (1..50) OF
	CSG-SubscriptionData

CSG-SubscriptionData ::= SEQUENCE {
	csg-Id	CSG-Id,
	expirationDate	Time	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	lipa-AllowedAPNList	[0] LIPA-AllowedAPNList	OPTIONAL,
	plmn-Id	[1] PLMN-Id	OPTIONAL
}

VPLMN-CSG-SubscriptionDataList ::= SEQUENCE SIZE (1..50) OF
	CSG-SubscriptionData

CSG-Id ::= BIT STRING (SIZE (27))
	-- coded according to 3GPP TS 23.003 [17].

LIPA-AllowedAPNList ::= SEQUENCE SIZE (1..maxNumOfLIPAAllowedAPN) OF
	APN

maxNumOfLIPAAllowedAPN  INTEGER ::= 50


EPS-SubscriptionData ::= SEQUENCE {
	apn-oi-Replacement	[0]	APN-OI-Replacement	OPTIONAL,
	-- this apn-oi-Replacement refers to the UE level apn-oi-Replacement.
	rfsp-id	[2]	RFSP-ID	OPTIONAL,
	ambr	[3]	AMBR	OPTIONAL,
	apn-ConfigurationProfile	[4]	APN-ConfigurationProfile	OPTIONAL,
	stn-sr	[6]	ISDN-AddressString	OPTIONAL,
	extensionContainer	[5]	ExtensionContainer	OPTIONAL,
	...,
	mps-CSPriority	[7]	NULL	OPTIONAL,
	mps-EPSPriority	[8]	NULL	OPTIONAL,
	subscribed-vsrvcc	[9]	NULL	OPTIONAL }
	-- mps-CSPriority by its presence indicates that the UE is subscribed to the eMLPP in 
	-- the CS domain, referring to the 3GPP TS 29.272 [144] for details.
	-- mps-EPSPriority by its presence indicates that the UE is subscribed to the MPS in 
	-- the EPS domain, referring to the 3GPP TS 29.272 [144] for details. 
	--  
	-- subscribed-vsrvcc by its presence indicates that the UE is subscribed to the vSRVCC in 
	-- the EPS domain, referring to the 3GPP TS 29.272 [144] for details.

APN-OI-Replacement ::=  OCTET STRING (SIZE (9..100))
	-- Octets are coded as APN Operator Identifier according to TS 3GPP TS 23.003 [17] 

RFSP-ID ::=  INTEGER (1..256)

APN-ConfigurationProfile ::= SEQUENCE {
	defaultContext	ContextId,
	completeDataListIncluded	NULL	OPTIONAL,
	-- If segmentation is used, completeDataListIncluded may only be present in the
	-- first segment of APN-ConfigurationProfile.
	epsDataList	[1]	EPS-DataList,
	extensionContainer	[2]	ExtensionContainer	OPTIONAL,
	... ,
	additionalDefaultContext	[3]	ContextId	OPTIONAL
	--	for details see the 3GPP TS 29.272 [144].
 }

EPS-DataList ::= SEQUENCE SIZE (1..maxNumOfAPN-Configurations) OF
	APN-Configuration


maxNumOfAPN-Configurations  INTEGER ::= 50


APN-Configuration ::= SEQUENCE {
	contextId	[0] ContextId,
	pdn-Type	[1] PDN-Type,
	servedPartyIP-IPv4-Address	[2] PDP-Address	OPTIONAL,
	apn	[3] APN,
	eps-qos-Subscribed	[4] EPS-QoS-Subscribed,
	pdn-gw-Identity	[5] PDN-GW-Identity	OPTIONAL,
	pdn-gw-AllocationType	[6] PDN-GW-AllocationType	OPTIONAL,
	vplmnAddressAllowed	[7] NULL	OPTIONAL,
	chargingCharacteristics	[8] ChargingCharacteristics	OPTIONAL,
	ambr	[9] AMBR	OPTIONAL,
	specificAPNInfoList	[10] SpecificAPNInfoList	OPTIONAL,	extensionContainer	[11] ExtensionContainer	OPTIONAL, 
	servedPartyIP-IPv6-Address	[12] PDP-Address	OPTIONAL,
	...,
	apn-oi-Replacement	[13] APN-OI-Replacement	OPTIONAL,
	-- this apn-oi-Replacement refers to the APN level apn-oi-Replacement.
	sipto-Permission	[14] SIPTO-Permission	OPTIONAL,
	lipa-Permission	[15] LIPA-Permission	OPTIONAL,
	restoration-Priority	[16] Restoration-Priority	OPTIONAL,
	sipto-local-network-Permission	[17] SIPTO-Local-Network-Permission	OPTIONAL,
	wlan-offloadability	[18] WLAN-Offloadability	OPTIONAL,
	non-IP-PDN-Type-Indicator	[19]	NULL	OPTIONAL,
	nIDD-Mechanism	[20]	NIDD-Mechanism	OPTIONAL,
	sCEF-ID	[21]	FQDN	OPTIONAL,
	pdn-ConnectionContinuity	[22]	PDN-ConnectionContinuity	OPTIONAL
	-- absence of pdn-ConnectionContinuity indicates that the handling is left to
	-- local VPLMN policy
 }

PDN-ConnectionContinuity ::= ENUMERATED {
	maintainPDN-Connection	(0),
	disconnectPDN-ConnectionWithReactivationRequest	(1),
	disconnectPDN-ConnectionWithoutReactivationRequest	(2)
 }

NIDD-Mechanism ::= ENUMERATED {
	sGi-based-data-delivery	(0),
	sCEF-based-data-delivery	(1)
	-- The default value, when this information element is not present, is
	-- sGi-based-data-delivery (0)
 }

PDN-Type ::= OCTET STRING (SIZE (1))
	-- Octet is coded  as follows:
	--	Bits
	--	3 2 1
	--	0 0 1 IPv4
	--	0 1 0 IPv6
	--	0 1 1 IPv4v6
	--	1 0 0 IPv4_or_IPv6
	--	Bits 8-4 shall be coded as zero.
	--	for details see 3GPP TS 29.272 [144]

EPS-QoS-Subscribed ::= SEQUENCE {
	qos-Class-Identifier	[0] QoS-Class-Identifier,
	allocation-Retention-Priority	[1] Allocation-Retention-Priority,
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	... }

AMBR ::= SEQUENCE {
	max-RequestedBandwidth-UL	[0] Bandwidth,
	max-RequestedBandwidth-DL	[1] Bandwidth,
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	...,
	extended-Max-RequestedBandwidth-UL	[3] BandwidthExt	OPTIONAL,
	extended-Max-RequestedBandwidth-DL	[4] BandwidthExt	OPTIONAL
	-- extended-Max-RequestedBandwidth-UL/DL shall be populated according to the 
	-- description of the corresponding parameters in 3GPP TS 29.272 [144]
}


SpecificAPNInfoList ::= SEQUENCE SIZE (1..maxNumOfSpecificAPNInfos) OF
	SpecificAPNInfo

maxNumOfSpecificAPNInfos  INTEGER ::= 50

SpecificAPNInfo ::= SEQUENCE {
	apn	[0] APN,
	pdn-gw-Identity	[1] PDN-GW-Identity,
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	... }

Bandwidth ::= INTEGER 
	-- bits per second

BandwidthExt ::= INTEGER 
	-- kilobits per second

QoS-Class-Identifier ::= INTEGER (1..9)
	-- values are defined in  3GPP TS 29.212



Allocation-Retention-Priority ::= SEQUENCE {
	priority-level	[0] INTEGER,
	pre-emption-capability	[1] BOOLEAN	OPTIONAL,
	pre-emption-vulnerability	[2] BOOLEAN	OPTIONAL,
	extensionContainer	[3] ExtensionContainer	OPTIONAL,
	... }

PDN-GW-Identity ::= SEQUENCE {
	pdn-gw-ipv4-Address	[0] PDP-Address	OPTIONAL,
	pdn-gw-ipv6-Address	[1] PDP-Address	OPTIONAL,
	pdn-gw-name	[2] FQDN	OPTIONAL,
	extensionContainer	[3] ExtensionContainer	OPTIONAL,
	... }

FQDN ::=  OCTET STRING (SIZE (9..255))


PDN-GW-AllocationType ::= ENUMERATED {
	static	(0),
	dynamic	(1)}


WLAN-Offloadability ::= SEQUENCE {
	wlan-offloadability-EUTRAN	[0] WLAN-Offloadability-Indication 	OPTIONAL,
	wlan-offloadability-UTRAN	[1] WLAN-Offloadability-Indication	OPTIONAL,
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	... }

WLAN-Offloadability-Indication ::= ENUMERATED {
	notAllowed   (0),
	allowed      (1)}



AccessRestrictionData ::= BIT STRING {
	utranNotAllowed (0),
	geranNotAllowed (1),
	ganNotAllowed   (2),
	i-hspa-evolutionNotAllowed (3),
	wb-e-utranNotAllowed (4),
	ho-toNon3GPP-AccessNotAllowed (5),
	nb-iotNotAllowed (6),
	enhancedCoverageNotAllowed (7) } (SIZE (2..8))
	-- exception handling: 
	-- The VLR shall ignore the access restriction data related to an access type not 
	-- supported by the node.
	-- The handling of the access restriction data by the SGSN is described in clause 
	-- 5.3.19 of TS 23.060, in clause 7.5.3 of TS 29.060 and clause 7.3.6 of TS 29.274. 
	-- Additional access restrictions are encoded in Ext-AccessRestrictionData bit string.
	

Ext-AccessRestrictionData ::= BIT STRING {
	nrAsSecondaryRATNotAllowed (0),
	unlicensedSpectrumAsSecondaryRATNotAllowed (1) } (SIZE (1..32))

AdjacentAccessRestrictionDataList ::= SEQUENCE SIZE (1..50) OF
	AdjacentAccessRestrictionData

AdjacentAccessRestrictionData ::= SEQUENCE {
	plmnId	[0]	PLMN-Id,
	accessRestrictionData	[1]	AccessRestrictionData,
	... ,
	ext-AccessRestrictionData	[2]	Ext-AccessRestrictionData	OPTIONAL }

CS-AllocationRetentionPriority ::= OCTET STRING (SIZE (1))
	-- This data type encodes each priority level defined in TS 23.107 as the binary value
	-- of the priority level.

IST-AlertTimerValue ::= INTEGER (15..255)

LCSInformation ::= SEQUENCE {
	gmlc-List	[0]	GMLC-List	OPTIONAL,
	lcs-PrivacyExceptionList	[1]	LCS-PrivacyExceptionList	OPTIONAL,
	molr-List	[2]	MOLR-List	OPTIONAL,
	...,
	add-lcs-PrivacyExceptionList	[3]	LCS-PrivacyExceptionList	OPTIONAL }
	-- add-lcs-PrivacyExceptionList may be sent only if lcs-PrivacyExceptionList is
	-- present and contains four instances of LCS-PrivacyClass. If the mentioned condition
	-- is not satisfied the receiving node shall discard add-lcs-PrivacyExceptionList.
	-- If an LCS-PrivacyClass is received both in lcs-PrivacyExceptionList and in
	-- add-lcs-PrivacyExceptionList with the same SS-Code, then the error unexpected 
	-- data value shall be returned.

GMLC-List ::= SEQUENCE SIZE (1..maxNumOfGMLC) OF
	ISDN-AddressString
	-- if segmentation is used, the complete GMLC-List shall be sent in one segment

maxNumOfGMLC  INTEGER ::= 5

NetworkAccessMode ::= ENUMERATED {
	packetAndCircuit	(0),
	onlyCircuit	(1),
	onlyPacket	(2),
	...}
	-- if unknown values are received in NetworkAccessMode
	-- they shall be discarded.

GPRSDataList ::= SEQUENCE SIZE (1..maxNumOfPDP-Contexts) OF
	PDP-Context

maxNumOfPDP-Contexts  INTEGER ::= 50

PDP-Context ::= SEQUENCE {
	pdp-ContextId	ContextId,
	pdp-Type	[16] PDP-Type,
	pdp-Address	[17] PDP-Address	OPTIONAL,
	qos-Subscribed	[18] QoS-Subscribed,
	vplmnAddressAllowed	[19] NULL	OPTIONAL,
	apn	[20] APN,
	extensionContainer	[21] ExtensionContainer	OPTIONAL,
	... ,
	ext-QoS-Subscribed	[0] Ext-QoS-Subscribed	OPTIONAL, 
	pdp-ChargingCharacteristics	[1] ChargingCharacteristics	OPTIONAL,
	ext2-QoS-Subscribed	[2] Ext2-QoS-Subscribed	OPTIONAL,
	-- ext2-QoS-Subscribed may be present only if ext-QoS-Subscribed is present.
	ext3-QoS-Subscribed	[3] Ext3-QoS-Subscribed	OPTIONAL,
	-- ext3-QoS-Subscribed may be present only if ext2-QoS-Subscribed is present.
	ext4-QoS-Subscribed	[4] Ext4-QoS-Subscribed	OPTIONAL,
	-- ext4-QoS-Subscribed may be present only if ext3-QoS-Subscribed is present. 
	apn-oi-Replacement	[5]	APN-OI-Replacement	OPTIONAL,
	-- this apn-oi-Replacement refers to the APN level apn-oi-Replacement and has
	-- higher priority than UE level apn-oi-Replacement.
	ext-pdp-Type	[6] Ext-PDP-Type	OPTIONAL,
	-- contains the value IPv4v6 defined in 3GPP TS 29.060 [105], if the PDP can be
	-- accessed by dual-stack UEs
	ext-pdp-Address	[7] PDP-Address	OPTIONAL,
	-- contains an additional IP address in case of dual-stack static IP address assignment
	-- for the UE.
	-- it may contain an IPv4 or an IPv6 address/prefix, and it may be present
	-- only if pdp-Address is present; if both are present, each parameter shall
	-- contain a different type of address (IPv4 or IPv6).
	ambr	[10] AMBR	OPTIONAL,
	-- this ambr contains the AMBR associated to the APN included in the 
	-- PDP-Context (APN-AMBR).
	sipto-Permission	[8] SIPTO-Permission	OPTIONAL,
	lipa-Permission	[9] LIPA-Permission	OPTIONAL,
	restoration-Priority	[11] Restoration-Priority	OPTIONAL,
	sipto-local-network-Permission	[12] SIPTO-Local-Network-Permission	OPTIONAL,
	nIDD-Mechanism	[13]	NIDD-Mechanism	OPTIONAL,
	sCEF-ID	[14]	FQDN	OPTIONAL
	}

Restoration-Priority ::= OCTET STRING (SIZE (1))
	-- Octet 1:
	--  Restoration Priority. This octet encodes the Restoration Priority,
	--  as the binary value of the Restoration-Priority described in 3GPP TS 29.272 [144].

SIPTO-Permission ::= ENUMERATED {
	siptoAboveRanAllowed  (0),
	siptoAboveRanNotAllowed  (1)
	}

SIPTO-Local-Network-Permission ::= ENUMERATED {
	siptoAtLocalNetworkAllowed  (0),
	siptoAtLocalNetworkNotAllowed  (1)
	}

LIPA-Permission ::= ENUMERATED {
	lipaProhibited  (0),
	lipaOnly  (1),
	lipaConditional  (2)
	}

ContextId ::= INTEGER (1..maxNumOfPDP-Contexts)

GPRSSubscriptionData ::= SEQUENCE {
	completeDataListIncluded	NULL	OPTIONAL,
	-- If segmentation is used, completeDataListIncluded may only be present in the
	-- first segment of GPRSSubscriptionData.
	gprsDataList	[1]	GPRSDataList,
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	...,
	apn-oi-Replacement	[3]	APN-OI-Replacement	OPTIONAL
	-- this apn-oi-Replacement refers to the UE level apn-oi-Replacement.
 }

SGSN-CAMEL-SubscriptionInfo ::= SEQUENCE {
	gprs-CSI	[0]	GPRS-CSI	OPTIONAL,
	mo-sms-CSI	[1]	SMS-CSI	OPTIONAL,
	extensionContainer	[2]	ExtensionContainer	OPTIONAL,
	...,
	mt-sms-CSI	[3]	SMS-CSI	OPTIONAL,
	mt-smsCAMELTDP-CriteriaList	[4]	MT-smsCAMELTDP-CriteriaList	OPTIONAL,
	mg-csi	[5]	MG-CSI	OPTIONAL
	}

GPRS-CSI ::= SEQUENCE {
	gprs-CamelTDPDataList	[0] GPRS-CamelTDPDataList	OPTIONAL,
	camelCapabilityHandling	[1] CamelCapabilityHandling	OPTIONAL,
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	notificationToCSE	[3]	NULL	OPTIONAL,
	csi-Active	[4]	NULL	OPTIONAL,
	...}
--	notificationToCSE and csi-Active shall not be present when GPRS-CSI is sent to SGSN.
--	They may only be included in ATSI/ATM ack/NSDC message. 
--	GPRS-CamelTDPData and  camelCapabilityHandling shall be present in 
--	the GPRS-CSI sequence.
--	If GPRS-CSI is segmented, gprs-CamelTDPDataList and camelCapabilityHandling shall be 
--	present in the first segment

GPRS-CamelTDPDataList ::= SEQUENCE SIZE (1..maxNumOfCamelTDPData) OF
	GPRS-CamelTDPData
--	GPRS-CamelTDPDataList shall not contain more than one instance of
--	GPRS-CamelTDPData containing the same value for gprs-TriggerDetectionPoint.

GPRS-CamelTDPData ::= SEQUENCE {
	gprs-TriggerDetectionPoint	[0] GPRS-TriggerDetectionPoint,
	serviceKey	[1] ServiceKey,
	gsmSCF-Address	[2] ISDN-AddressString,
	defaultSessionHandling	[3] DefaultGPRS-Handling,
	extensionContainer	[4] ExtensionContainer	OPTIONAL,
	...
	}

DefaultGPRS-Handling ::= ENUMERATED {
	continueTransaction (0) ,
	releaseTransaction (1) ,
	...}
-- exception handling:
-- reception of values in range 2-31 shall be treated as "continueTransaction"
-- reception of values greater than 31 shall be treated as "releaseTransaction"

GPRS-TriggerDetectionPoint ::= ENUMERATED {
	attach	(1),
	attachChangeOfPosition	(2),
	pdp-ContextEstablishment	(11),
	pdp-ContextEstablishmentAcknowledgement	(12),
	pdp-ContextChangeOfPosition	(14),
	... }
-- exception handling:
-- For GPRS-CamelTDPData sequences containing this parameter with any
-- other value than the ones listed the receiver shall ignore the whole 
-- GPRS-CamelTDPDatasequence.

APN ::=  OCTET STRING (SIZE (2..63))
	-- Octets are coded according to TS 3GPP TS 23.003 [17] 

PDP-Type ::= OCTET STRING (SIZE (2))
	-- Octets are coded according to TS 3GPP TS 29.060 [105]
	-- Only the values PPP, IPv4, IPv6 and Non-IP are allowed for this parameter.

Ext-PDP-Type ::= OCTET STRING (SIZE (2))
	-- Octets are coded, similarly to PDP-Type, according to TS 3GPP TS 29.060 [105].
	-- Only the value IPv4v6 is allowed for this parameter.

PDP-Address ::= OCTET STRING (SIZE (1..16))
	-- Octets are coded according to TS 3GPP TS 29.060 [105]

	-- The possible size values are:
	-- 1-7 octets  X.25 address type
	--  4  octets  IPv4 address type
	-- 16  octets  Ipv6 address type

QoS-Subscribed ::= OCTET STRING (SIZE (3))
	-- Octets are coded according to TS 3GPP TS 24.008 [35] Quality of Service Octets 
	-- 3-5.

Ext-QoS-Subscribed ::= OCTET STRING (SIZE (1..9))
	-- OCTET 1: 
	--  Allocation/Retention Priority (This octet encodes each priority level defined in
	--     23.107 as the binary value of the priority level, declaration in 29.060)
	-- Octets 2-9 are coded according to 3GPP TS 24.008 [35] Quality of Service Octets 
	-- 6-13.

Ext2-QoS-Subscribed ::= OCTET STRING (SIZE (1..3))
	-- Octets 1-3 are coded according to 3GPP TS 24.008 [35] Quality of Service Octets 14-16.
	-- If Quality of Service information is structured with 14 octet length, then
	-- Octet 1 is coded according to 3GPP TS 24.008 [35] Quality of Service Octet 14.

Ext3-QoS-Subscribed ::= OCTET STRING (SIZE (1..2))
	-- Octets 1-2 are coded according to 3GPP TS 24.008 [35] Quality of Service Octets 17-18.

Ext4-QoS-Subscribed ::= OCTET STRING (SIZE (1))
	-- Octet 1:
	--  Evolved Allocation/Retention Priority. This octet encodes the Priority Level (PL),
	--  the Preemption Capability (PCI) and Preemption Vulnerability  (PVI) values, as
	--  described in 3GPP TS 29.060 [105].

ChargingCharacteristics ::= OCTET STRING (SIZE (2))
	-- Octets are coded according to 3GPP TS 32.215.

LSAOnlyAccessIndicator ::= ENUMERATED {
	accessOutsideLSAsAllowed  (0),
	accessOutsideLSAsRestricted (1)}

LSADataList ::= SEQUENCE SIZE (1..maxNumOfLSAs) OF
	LSAData

maxNumOfLSAs  INTEGER ::= 20

LSAData ::= SEQUENCE {
	lsaIdentity	[0] LSAIdentity,
	lsaAttributes	[1] LSAAttributes,
	lsaActiveModeIndicator	[2] NULL	OPTIONAL,
	extensionContainer	[3] ExtensionContainer	OPTIONAL,
	...}

LSAInformation ::= SEQUENCE {
	completeDataListIncluded	NULL	OPTIONAL,

	-- If segmentation is used, completeDataListIncluded may only be present in the
	-- first segment.
	lsaOnlyAccessIndicator	[1]	LSAOnlyAccessIndicator	OPTIONAL,
	lsaDataList	[2]	LSADataList	OPTIONAL,
	extensionContainer	[3] ExtensionContainer	OPTIONAL,
	...}

LSAIdentity ::= OCTET STRING (SIZE (3))
	-- Octets are coded according to TS 3GPP TS 23.003 [17]

LSAAttributes ::= OCTET STRING (SIZE (1))
	-- Octets are coded according to TS 3GPP TS 48.008 [49]

SubscriberData ::= SEQUENCE {
	msisdn	[1] ISDN-AddressString	OPTIONAL,
	category	[2] Category	OPTIONAL,
	subscriberStatus	[3] SubscriberStatus	OPTIONAL,
	bearerServiceList	[4] BearerServiceList	OPTIONAL,
	-- The exception handling for reception of unsupported / not allocated
	-- bearerServiceCodes is defined in clause 8.8.1
	teleserviceList	[6] TeleserviceList	OPTIONAL,
	-- The exception handling for reception of unsupported / not allocated
	-- teleserviceCodes is defined in clause 8.8.1
	provisionedSS	[7] Ext-SS-InfoList	OPTIONAL,
	odb-Data	[8] ODB-Data	OPTIONAL,
	roamingRestrictionDueToUnsupportedFeature  [9] NULL	OPTIONAL,
	regionalSubscriptionData	[10] ZoneCodeList	OPTIONAL,
	vbsSubscriptionData	[11] VBSDataList	OPTIONAL,
	vgcsSubscriptionData	[12] VGCSDataList	OPTIONAL,
	vlrCamelSubscriptionInfo	[13] VlrCamelSubscriptionInfo	OPTIONAL
	}

Category ::= OCTET STRING (SIZE (1))
	-- The internal structure is defined in ITU-T Rec Q.763.

SubscriberStatus ::= ENUMERATED {
	serviceGranted  (0),
	operatorDeterminedBarring  (1)}

BearerServiceList ::= SEQUENCE SIZE (1..maxNumOfBearerServices) OF
	Ext-BearerServiceCode

maxNumOfBearerServices  INTEGER ::= 50

TeleserviceList ::= SEQUENCE SIZE (1..maxNumOfTeleservices) OF
	Ext-TeleserviceCode

maxNumOfTeleservices  INTEGER ::= 20

ODB-Data ::= SEQUENCE {
	odb-GeneralData	ODB-GeneralData,
	odb-HPLMN-Data	ODB-HPLMN-Data	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

ODB-GeneralData ::= BIT STRING {
	allOG-CallsBarred  (0),
	internationalOGCallsBarred  (1),
	internationalOGCallsNotToHPLMN-CountryBarred  (2),
	interzonalOGCallsBarred (6),
	interzonalOGCallsNotToHPLMN-CountryBarred (7),
	interzonalOGCallsAndInternationalOGCallsNotToHPLMN-CountryBarred (8),
	premiumRateInformationOGCallsBarred  (3),
	premiumRateEntertainementOGCallsBarred  (4),
	ss-AccessBarred  (5),
	allECT-Barred (9),
	chargeableECT-Barred (10),
	internationalECT-Barred (11),
	interzonalECT-Barred (12),
	doublyChargeableECT-Barred (13),
	multipleECT-Barred (14),
	allPacketOrientedServicesBarred (15),
	roamerAccessToHPLMN-AP-Barred  (16),
	roamerAccessToVPLMN-AP-Barred  (17),
	roamingOutsidePLMNOG-CallsBarred  (18),
	allIC-CallsBarred  (19),
	roamingOutsidePLMNIC-CallsBarred  (20),
	roamingOutsidePLMNICountryIC-CallsBarred  (21),
	roamingOutsidePLMN-Barred  (22),
	roamingOutsidePLMN-CountryBarred  (23),
	registrationAllCF-Barred  (24),
	registrationCFNotToHPLMN-Barred  (25),
	registrationInterzonalCF-Barred  (26),
	registrationInterzonalCFNotToHPLMN-Barred  (27),
	registrationInternationalCF-Barred  (28)} (SIZE (15..32))
	-- exception handling: reception of unknown bit assignments in the
	-- ODB-GeneralData type shall be treated like unsupported ODB-GeneralData
	-- When the ODB-GeneralData type is removed from the HLR for a given subscriber, 
	-- in NoteSubscriberDataModified operation sent toward the gsmSCF 
	-- all bits shall be set to "O".

ODB-HPLMN-Data ::= BIT STRING {
	plmn-SpecificBarringType1  (0),
	plmn-SpecificBarringType2  (1),
	plmn-SpecificBarringType3  (2),
	plmn-SpecificBarringType4  (3)} (SIZE (4..32))
	-- exception handling: reception of unknown bit assignments in the
	-- ODB-HPLMN-Data type shall be treated like unsupported ODB-HPLMN-Data 
	-- When the ODB-HPLMN-Data type is removed from the HLR for a given subscriber, 
	-- in NoteSubscriberDataModified operation sent toward the gsmSCF
	-- all bits shall be set to "O".

Ext-SS-InfoList ::= SEQUENCE SIZE (1..maxNumOfSS) OF
	Ext-SS-Info

Ext-SS-Info ::= CHOICE {
	forwardingInfo	[0] Ext-ForwInfo,
	callBarringInfo	[1] Ext-CallBarInfo,
	cug-Info	[2] CUG-Info,
	ss-Data	[3] Ext-SS-Data,
	emlpp-Info	[4] EMLPP-Info}

Ext-ForwInfo ::= SEQUENCE {
	ss-Code	SS-Code,
	forwardingFeatureList	Ext-ForwFeatureList,
	extensionContainer	[0] ExtensionContainer	OPTIONAL,
	...}

Ext-ForwFeatureList ::= SEQUENCE SIZE (1..maxNumOfExt-BasicServiceGroups) OF
	Ext-ForwFeature

Ext-ForwFeature ::= SEQUENCE {
	basicService	Ext-BasicServiceCode	OPTIONAL,
	ss-Status	[4] Ext-SS-Status,
	forwardedToNumber	[5] ISDN-AddressString	OPTIONAL,
	-- When this data type is sent from an HLR which supports CAMEL Phase 2
	-- to a VLR that supports CAMEL Phase 2 the VLR shall not check the
	-- format of the number
	forwardedToSubaddress	[8] ISDN-SubaddressString	OPTIONAL,
	forwardingOptions	[6] Ext-ForwOptions	OPTIONAL,
	noReplyConditionTime	[7] Ext-NoRepCondTime	OPTIONAL,
	extensionContainer	[9] ExtensionContainer	OPTIONAL,
	...,
	longForwardedToNumber	[10] FTN-AddressString	OPTIONAL }

Ext-ForwOptions ::= OCTET STRING (SIZE (1..5))

	-- OCTET 1:

	--  bit 8: notification to forwarding party
	--	0  no notification
	--	1  notification

	--  bit 7: redirecting presentation
	--	0 no presentation  
	--	1  presentation

	--  bit 6: notification to calling party
	--	0  no notification
	--	1  notification

	--  bit 5: 0 (unused)

	--  bits 43: forwarding reason
	--	00  ms not reachable
	--	01  ms busy
	--	10  no reply
	--	11  unconditional

	-- bits 21: 00 (unused)

	-- OCTETS 2-5: reserved for future use. They shall be discarded if
	-- received and not understood.

Ext-NoRepCondTime ::= INTEGER (1..100)
	-- Only values 5-30 are used.
	-- Values in the ranges 1-4 and 31-100 are reserved for future use
	-- If received:
	--	values 1-4 shall be mapped on to value 5
	--	values 31-100 shall be mapped on to value 30

Ext-CallBarInfo ::= SEQUENCE {
	ss-Code	SS-Code,
	callBarringFeatureList	Ext-CallBarFeatureList,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

Ext-CallBarFeatureList ::= SEQUENCE SIZE (1..maxNumOfExt-BasicServiceGroups) OF
	Ext-CallBarringFeature

Ext-CallBarringFeature ::= SEQUENCE {
	basicService	Ext-BasicServiceCode	OPTIONAL,
	ss-Status	[4] Ext-SS-Status,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

CUG-Info ::= SEQUENCE {
	cug-SubscriptionList	CUG-SubscriptionList,
	cug-FeatureList	CUG-FeatureList	OPTIONAL,
	extensionContainer	[0] ExtensionContainer	OPTIONAL,
	...}

CUG-SubscriptionList ::= SEQUENCE SIZE (0..maxNumOfCUG) OF
	CUG-Subscription

CUG-Subscription ::= SEQUENCE {
	cug-Index	CUG-Index,
	cug-Interlock	CUG-Interlock,
	intraCUG-Options	IntraCUG-Options,
	basicServiceGroupList	Ext-BasicServiceGroupList	OPTIONAL,
	extensionContainer	[0] ExtensionContainer	OPTIONAL,
	...}

CUG-Index ::= INTEGER (0..32767)
	-- The internal structure is defined in ETS 300 138.

CUG-Interlock ::= OCTET STRING (SIZE (4))

IntraCUG-Options ::= ENUMERATED {
	noCUG-Restrictions  (0),
	cugIC-CallBarred  (1),
	cugOG-CallBarred  (2)}

maxNumOfCUG  INTEGER ::= 10

CUG-FeatureList ::= SEQUENCE SIZE (1..maxNumOfExt-BasicServiceGroups) OF
	CUG-Feature

Ext-BasicServiceGroupList ::= SEQUENCE SIZE (1..maxNumOfExt-BasicServiceGroups) OF
	Ext-BasicServiceCode

maxNumOfExt-BasicServiceGroups  INTEGER ::= 32

CUG-Feature ::= SEQUENCE {
	basicService	Ext-BasicServiceCode	OPTIONAL,
	preferentialCUG-Indicator	CUG-Index	OPTIONAL,
	interCUG-Restrictions	InterCUG-Restrictions,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

InterCUG-Restrictions ::= OCTET STRING (SIZE (1))

	-- bits 876543: 000000 (unused)
	-- Exception handling:
	-- bits 876543 shall be ignored if received and not understood

	-- bits 21
	--	00  CUG only facilities
	--	01  CUG with outgoing access
	--	10  CUG with incoming access
	--	11  CUG with both outgoing and incoming access

Ext-SS-Data ::= SEQUENCE {
	ss-Code	SS-Code,
	ss-Status	[4] Ext-SS-Status,
	ss-SubscriptionOption	SS-SubscriptionOption	OPTIONAL,
	basicServiceGroupList	Ext-BasicServiceGroupList	OPTIONAL,
	extensionContainer	[5] ExtensionContainer	OPTIONAL,
	...}

LCS-PrivacyExceptionList ::= SEQUENCE SIZE (1..maxNumOfPrivacyClass) OF
	LCS-PrivacyClass

maxNumOfPrivacyClass  INTEGER ::= 4

LCS-PrivacyClass ::= SEQUENCE {
	ss-Code	SS-Code,
	ss-Status	Ext-SS-Status,
	notificationToMSUser	[0] NotificationToMSUser	OPTIONAL,
	-- notificationToMSUser may be sent only for SS-codes callSessionRelated
	-- and callSessionUnrelated. If not received for SS-codes callSessionRelated
	-- and callSessionUnrelated,
	-- the default values according to 3GPP TS 23.271 shall be assumed.
	externalClientList	[1] ExternalClientList	OPTIONAL,
	-- externalClientList may be sent only for SS-code callSessionUnrelated to a
	-- visited node that does not support LCS Release 4 or later versions.
	-- externalClientList may be sent only for SS-codes callSessionUnrelated and
	-- callSessionRelated to a visited node that supports LCS Release 4 or later versions.
	plmnClientList	[2] PLMNClientList	OPTIONAL,
	-- plmnClientList may be sent only for SS-code plmnoperator.
	extensionContainer	[3] ExtensionContainer	OPTIONAL,
	...,
	ext-externalClientList	[4] Ext-ExternalClientList	OPTIONAL,
	-- Ext-externalClientList may be sent only if the visited node supports LCS Release 4 or
	-- later versions, the user did specify more than 5 clients, and White Book SCCP is used.
	serviceTypeList	[5]	ServiceTypeList	OPTIONAL
	-- serviceTypeList may be sent only for SS-code serviceType and if the visited node
	-- supports LCS Release 5 or later versions.
	-- 
	-- if segmentation is used, the complete LCS-PrivacyClass shall be sent in one segment
}

ExternalClientList ::= SEQUENCE SIZE (0..maxNumOfExternalClient) OF
	ExternalClient

maxNumOfExternalClient  INTEGER ::= 5

PLMNClientList ::= SEQUENCE SIZE (1..maxNumOfPLMNClient) OF
	LCSClientInternalID

maxNumOfPLMNClient  INTEGER ::= 5

Ext-ExternalClientList ::= SEQUENCE SIZE (1..maxNumOfExt-ExternalClient) OF
	ExternalClient

maxNumOfExt-ExternalClient  INTEGER ::= 35

ExternalClient ::= SEQUENCE {
	clientIdentity	LCSClientExternalID,
	gmlc-Restriction	[0] GMLC-Restriction	OPTIONAL,
	notificationToMSUser	[1] NotificationToMSUser	OPTIONAL,
	-- If notificationToMSUser is not received, the default value according to 
	-- 3GPP TS 23.271 shall be assumed.
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	... }

GMLC-Restriction ::= ENUMERATED {
	gmlc-List	(0),
	home-Country	(1) ,
	... }
-- exception handling:
-- At reception of any other value than the ones listed the receiver shall ignore
-- GMLC-Restriction.

NotificationToMSUser ::= ENUMERATED {
	notifyLocationAllowed	(0),
	notifyAndVerify-LocationAllowedIfNoResponse	(1),
	notifyAndVerify-LocationNotAllowedIfNoResponse	(2),
	...,
	locationNotAllowed (3) }
-- exception handling:
-- At reception of any other value than the ones listed the receiver shall ignore
-- NotificationToMSUser.

ServiceTypeList ::= SEQUENCE SIZE (1..maxNumOfServiceType) OF
	ServiceType

maxNumOfServiceType  INTEGER ::= 32

ServiceType ::= SEQUENCE {
	serviceTypeIdentity	LCSServiceTypeID,
	gmlc-Restriction	[0] GMLC-Restriction	OPTIONAL,
	notificationToMSUser	[1] NotificationToMSUser	OPTIONAL,
	-- If notificationToMSUser is not received, the default value according to 
	-- 3GPP TS 23.271 shall be assumed.
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	... }

MOLR-List ::= SEQUENCE SIZE (1..maxNumOfMOLR-Class) OF
	MOLR-Class

maxNumOfMOLR-Class  INTEGER ::= 3

MOLR-Class ::= SEQUENCE {
	ss-Code	SS-Code,
	ss-Status	Ext-SS-Status,
	extensionContainer	[0] ExtensionContainer	OPTIONAL,
	...}

ZoneCodeList ::= SEQUENCE SIZE (1..maxNumOfZoneCodes)
	OF ZoneCode

ZoneCode ::= OCTET STRING (SIZE (2))
	-- internal structure is defined in TS 3GPP TS 23.003 [17]

maxNumOfZoneCodes  INTEGER ::= 10

InsertSubscriberDataRes ::= SEQUENCE {
	teleserviceList	[1] TeleserviceList	OPTIONAL,
	bearerServiceList	[2] BearerServiceList	OPTIONAL,
	ss-List	[3] SS-List	OPTIONAL,
	odb-GeneralData	[4] ODB-GeneralData	OPTIONAL,
	regionalSubscriptionResponse	[5] RegionalSubscriptionResponse	OPTIONAL,
	supportedCamelPhases	[6] SupportedCamelPhases	OPTIONAL,
	extensionContainer	[7] ExtensionContainer	OPTIONAL,
	... ,
	offeredCamel4CSIs	[8] OfferedCamel4CSIs	OPTIONAL,
	supportedFeatures	[9] SupportedFeatures	OPTIONAL,
	ext-SupportedFeatures	[10] Ext-SupportedFeatures	OPTIONAL }

RegionalSubscriptionResponse ::= ENUMERATED {
	networkNode-AreaRestricted	(0),
	tooManyZoneCodes	(1),
	zoneCodesConflict	(2),
	regionalSubscNotSupported	(3)}

DeleteSubscriberDataArg ::= SEQUENCE {
	imsi	[0] IMSI,
	basicServiceList	[1] BasicServiceList	OPTIONAL,
	-- The exception handling for reception of unsupported/not allocated
	-- basicServiceCodes is defined in clause 6.8.2
	ss-List	[2] SS-List	OPTIONAL,
	roamingRestrictionDueToUnsupportedFeature [4] NULL	OPTIONAL,
	regionalSubscriptionIdentifier	[5] ZoneCode	OPTIONAL,
	vbsGroupIndication	[7] NULL	OPTIONAL,
	vgcsGroupIndication	[8] NULL	OPTIONAL,
	camelSubscriptionInfoWithdraw	[9] NULL	OPTIONAL,
	extensionContainer	[6] ExtensionContainer	OPTIONAL,
	...,
	gprsSubscriptionDataWithdraw	[10] GPRSSubscriptionDataWithdraw	OPTIONAL,
	roamingRestrictedInSgsnDueToUnsuppportedFeature [11] NULL	OPTIONAL,
	lsaInformationWithdraw	[12] LSAInformationWithdraw	OPTIONAL,
	gmlc-ListWithdraw	[13]	NULL	OPTIONAL,
	istInformationWithdraw	[14] NULL	OPTIONAL,
	specificCSI-Withdraw	[15] SpecificCSI-Withdraw	OPTIONAL,
	chargingCharacteristicsWithdraw	[16] NULL	OPTIONAL,
	stn-srWithdraw	[17] NULL	OPTIONAL,
	epsSubscriptionDataWithdraw	[18] EPS-SubscriptionDataWithdraw	OPTIONAL,
	apn-oi-replacementWithdraw	[19] NULL	OPTIONAL,
	csg-SubscriptionDeleted	[20]	NULL	OPTIONAL,
	subscribedPeriodicTAU-RAU-TimerWithdraw	[22]	NULL	OPTIONAL,
	subscribedPeriodicLAU-TimerWithdraw	[23]	NULL	OPTIONAL,
	subscribed-vsrvccWithdraw	[21] NULL	OPTIONAL,
	vplmn-Csg-SubscriptionDeleted	[24]	NULL	OPTIONAL,
	additionalMSISDN-Withdraw	[25]	NULL	OPTIONAL,
	cs-to-ps-SRVCC-Withdraw	[26]	NULL	OPTIONAL,
	imsiGroupIdList-Withdraw	[27]	NULL	OPTIONAL,
	userPlaneIntegrityProtectionWithdraw	[28] NULL	OPTIONAL,
	dl-Buffering-Suggested-Packet-Count-Withdraw	[29] NULL	OPTIONAL,
	ue-UsageTypeWithdraw	[30] NULL	OPTIONAL,
	reset-idsWithdraw	[31]	NULL	OPTIONAL,
	iab-OperationWithdraw	[32]	NULL	OPTIONAL }

SpecificCSI-Withdraw ::= BIT STRING {
	o-csi (0),
	ss-csi (1),
	tif-csi (2),
	d-csi (3),
	vt-csi (4),
	mo-sms-csi (5),
	m-csi (6),
	gprs-csi (7),
	t-csi (8),
	mt-sms-csi (9),
	mg-csi (10),
	o-IM-CSI (11), 
	d-IM-CSI (12),
	vt-IM-CSI (13) } (SIZE(8..32)) 
-- exception handling:
-- bits 11 to 31 shall be ignored if received by a non-IP Multimedia Core Network entity.
-- bits 0-10 and 14-31 shall be ignored if received by an IP Multimedia Core Network entity.
-- bits 11-13 are only applicable in an IP Multimedia Core Network.
-- Bit 8 and bits 11-13 are only applicable for the NoteSubscriberDataModified operation.

GPRSSubscriptionDataWithdraw ::= CHOICE {
	allGPRSData	NULL,
	contextIdList	ContextIdList}

EPS-SubscriptionDataWithdraw ::= CHOICE {
	allEPS-Data	NULL,
	contextIdList	ContextIdList}

ContextIdList ::= SEQUENCE SIZE (1..maxNumOfPDP-Contexts) OF
	ContextId

LSAInformationWithdraw ::= CHOICE {
	allLSAData	NULL,
	lsaIdentityList	LSAIdentityList }

LSAIdentityList ::= SEQUENCE SIZE (1..maxNumOfLSAs) OF
	LSAIdentity

BasicServiceList ::= SEQUENCE SIZE (1..maxNumOfBasicServices) OF
	Ext-BasicServiceCode

maxNumOfBasicServices  INTEGER ::= 70

DeleteSubscriberDataRes ::= SEQUENCE {
	regionalSubscriptionResponse	[0] RegionalSubscriptionResponse	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

VlrCamelSubscriptionInfo ::= SEQUENCE {
	o-CSI	[0] O-CSI	OPTIONAL,
	extensionContainer	[1] ExtensionContainer	OPTIONAL,
	...,
	ss-CSI	[2] SS-CSI	OPTIONAL,
	o-BcsmCamelTDP-CriteriaList	[4] O-BcsmCamelTDPCriteriaList	OPTIONAL,
	tif-CSI	[3] NULL	OPTIONAL,
	m-CSI	[5] M-CSI	OPTIONAL,
	mo-sms-CSI	[6] SMS-CSI	OPTIONAL,
	vt-CSI	[7] T-CSI	OPTIONAL,
	t-BCSM-CAMEL-TDP-CriteriaList	[8] T-BCSM-CAMEL-TDP-CriteriaList	OPTIONAL,
	d-CSI	[9] D-CSI	OPTIONAL,
	mt-sms-CSI	[10] SMS-CSI	OPTIONAL,
	mt-smsCAMELTDP-CriteriaList	[11]	MT-smsCAMELTDP-CriteriaList	OPTIONAL
	}

MT-smsCAMELTDP-CriteriaList ::= SEQUENCE SIZE (1.. maxNumOfCamelTDPData) OF
	MT-smsCAMELTDP-Criteria

MT-smsCAMELTDP-Criteria ::= SEQUENCE {
	sms-TriggerDetectionPoint	SMS-TriggerDetectionPoint,
	tpdu-TypeCriterion	[0]	TPDU-TypeCriterion	OPTIONAL,
	... }

TPDU-TypeCriterion ::= SEQUENCE SIZE (1..maxNumOfTPDUTypes) OF
	MT-SMS-TPDU-Type


maxNumOfTPDUTypes INTEGER ::= 5

MT-SMS-TPDU-Type ::= ENUMERATED {
	sms-DELIVER	(0),
	sms-SUBMIT-REPORT	(1),
	sms-STATUS-REPORT	(2),
	... }

--	exception handling:
--	For TPDU-TypeCriterion sequences containing this parameter with any
--	other value than the ones listed above the receiver shall ignore 
--	the whole TPDU-TypeCriterion sequence.
--	In CAMEL phase 4, sms-SUBMIT-REPORT shall not be used and a received TPDU-TypeCriterion
--	sequence containing sms-SUBMIT-REPORT shall be wholly ignored.

D-CSI ::= SEQUENCE {
	dp-AnalysedInfoCriteriaList	[0] DP-AnalysedInfoCriteriaList	OPTIONAL,
	camelCapabilityHandling	[1] CamelCapabilityHandling	OPTIONAL,
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	notificationToCSE	[3]	NULL	OPTIONAL,
	csi-Active	[4]	NULL	OPTIONAL,
	...} 
--	notificationToCSE and csi-Active shall not be present when D-CSI is sent to VLR/GMSC.
--	They may only be included in ATSI/ATM ack/NSDC message.
--	DP-AnalysedInfoCriteria and  camelCapabilityHandling shall be present in 
--	the D-CSI sequence.
--	If D-CSI is segmented, then the first segment shall contain dp-AnalysedInfoCriteriaList
--	and camelCapabilityHandling. Subsequent segments shall not contain
--	camelCapabilityHandling, but may contain dp-AnalysedInfoCriteriaList.

DP-AnalysedInfoCriteriaList  ::= SEQUENCE SIZE (1..maxNumOfDP-AnalysedInfoCriteria) OF
	DP-AnalysedInfoCriterium

maxNumOfDP-AnalysedInfoCriteria INTEGER ::= 10

DP-AnalysedInfoCriterium ::= SEQUENCE {
	dialledNumber	ISDN-AddressString,
	serviceKey	ServiceKey,
	gsmSCF-Address	ISDN-AddressString,
	defaultCallHandling	DefaultCallHandling,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

SS-CSI ::= SEQUENCE {
	ss-CamelData	SS-CamelData,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	notificationToCSE	[0]	NULL	OPTIONAL,
	csi-Active	[1]	NULL	OPTIONAL
--	notificationToCSE and csi-Active shall not be present when SS-CSI is sent to VLR.
--	They may only be included in ATSI/ATM ack/NSDC message.
}

SS-CamelData  ::= SEQUENCE {
	ss-EventList	SS-EventList,
	gsmSCF-Address	ISDN-AddressString,
	extensionContainer	[0] ExtensionContainer	OPTIONAL, 
	...}

SS-EventList  ::= SEQUENCE SIZE (1..maxNumOfCamelSSEvents) OF SS-Code
	-- Actions for the following SS-Code values are defined in CAMEL Phase 3:
	-- ect	SS-Code ::= '00110001'B
	-- multiPTY	SS-Code ::= '01010001'B
	-- cd	SS-Code ::= '00100100'B
	-- ccbs	SS-Code ::= '01000100'B
	-- all other SS codes shall be ignored
	-- When SS-CSI is sent to the VLR, it shall not contain a marking for ccbs.
	-- If the VLR receives SS-CSI containing a marking for ccbs, the VLR shall discard the
	-- ccbs marking in SS-CSI.

maxNumOfCamelSSEvents INTEGER ::= 10

O-CSI ::= SEQUENCE {
	o-BcsmCamelTDPDataList	O-BcsmCamelTDPDataList,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	camelCapabilityHandling	[0] CamelCapabilityHandling	OPTIONAL,
	notificationToCSE	[1]	NULL	OPTIONAL,
	csiActive	[2]	NULL	OPTIONAL}
--	notificationtoCSE and csiActive shall not be present when O-CSI is sent to VLR/GMSC.
--	They may only be included in ATSI/ATM ack/NSDC message.
--	O-CSI shall not be segmented.

O-BcsmCamelTDPDataList ::= SEQUENCE SIZE (1..maxNumOfCamelTDPData) OF
	O-BcsmCamelTDPData
	-- O-BcsmCamelTDPDataList shall not contain more than one instance of
	-- O-BcsmCamelTDPData containing the same value for o-BcsmTriggerDetectionPoint.
	-- For CAMEL Phase 2, this means that only one instance of O-BcsmCamelTDPData is allowed
	-- with o-BcsmTriggerDetectionPoint being equal to DP2.

maxNumOfCamelTDPData  INTEGER ::= 10

O-BcsmCamelTDPData ::= SEQUENCE {
	o-BcsmTriggerDetectionPoint	O-BcsmTriggerDetectionPoint,
	serviceKey	ServiceKey,
	gsmSCF-Address	[0] ISDN-AddressString,
	defaultCallHandling	[1] DefaultCallHandling,
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	...
	}

ServiceKey ::= INTEGER (0..2147483647)

O-BcsmTriggerDetectionPoint ::= ENUMERATED {
	collectedInfo (2),
	...,
	routeSelectFailure (4) }
	-- exception handling:
	-- For O-BcsmCamelTDPData sequences containing this parameter with any
	-- other value than the ones listed the receiver shall ignore the whole 
	-- O-BcsmCamelTDPDatasequence. 
	-- For O-BcsmCamelTDP-Criteria sequences containing this parameter with any
	-- other value than the ones listed the receiver shall ignore the whole
	-- O-BcsmCamelTDP-Criteria sequence.

O-BcsmCamelTDPCriteriaList ::= SEQUENCE SIZE (1..maxNumOfCamelTDPData) OF
	O-BcsmCamelTDP-Criteria 

T-BCSM-CAMEL-TDP-CriteriaList ::= SEQUENCE SIZE (1..maxNumOfCamelTDPData) OF
	T-BCSM-CAMEL-TDP-Criteria 

O-BcsmCamelTDP-Criteria ::= SEQUENCE {
	o-BcsmTriggerDetectionPoint	O-BcsmTriggerDetectionPoint,	
	destinationNumberCriteria	[0] DestinationNumberCriteria	OPTIONAL,
	basicServiceCriteria	[1] BasicServiceCriteria	OPTIONAL,
	callTypeCriteria	[2] CallTypeCriteria	OPTIONAL,
	...,
	o-CauseValueCriteria	[3] O-CauseValueCriteria	OPTIONAL,
	extensionContainer	[4] ExtensionContainer	OPTIONAL }

T-BCSM-CAMEL-TDP-Criteria ::= SEQUENCE {
	t-BCSM-TriggerDetectionPoint	T-BcsmTriggerDetectionPoint,	
	basicServiceCriteria	[0] BasicServiceCriteria	OPTIONAL,
	t-CauseValueCriteria	[1] T-CauseValueCriteria	OPTIONAL,
	... }

DestinationNumberCriteria  ::= SEQUENCE {
	matchType	[0] MatchType,
	destinationNumberList	[1] DestinationNumberList	OPTIONAL,
	destinationNumberLengthList	[2] DestinationNumberLengthList	OPTIONAL,
	-- one or both of destinationNumberList and destinationNumberLengthList 
	-- shall be present
	...}

DestinationNumberList  ::= SEQUENCE SIZE	(1..maxNumOfCamelDestinationNumbers) OF
	ISDN-AddressString
	-- The receiving entity shall not check the format of a number in
	-- the dialled number list

DestinationNumberLengthList  ::= SEQUENCE SIZE (1..maxNumOfCamelDestinationNumberLengths) OF 
		INTEGER(1..maxNumOfISDN-AddressDigits)

BasicServiceCriteria   ::= SEQUENCE SIZE(1..maxNumOfCamelBasicServiceCriteria) OF
	Ext-BasicServiceCode

maxNumOfISDN-AddressDigits  INTEGER ::= 15

maxNumOfCamelDestinationNumbers  INTEGER ::= 10

maxNumOfCamelDestinationNumberLengths  INTEGER ::= 3

maxNumOfCamelBasicServiceCriteria  INTEGER ::= 5

CallTypeCriteria       ::= ENUMERATED {
	forwarded	(0),
	notForwarded	(1)}

MatchType       ::= ENUMERATED {
	inhibiting	(0),
	enabling	(1)}

O-CauseValueCriteria   ::= SEQUENCE SIZE(1..maxNumOfCAMEL-O-CauseValueCriteria) OF
	CauseValue

T-CauseValueCriteria   ::= SEQUENCE SIZE(1..maxNumOfCAMEL-T-CauseValueCriteria) OF
	CauseValue

maxNumOfCAMEL-O-CauseValueCriteria  INTEGER ::= 5

maxNumOfCAMEL-T-CauseValueCriteria  INTEGER ::= 5

CauseValue ::= OCTET STRING (SIZE(1))
-- Type extracted from Cause parameter in ITU-T Recommendation Q.763.
-- For the use of cause value refer to ITU-T Recommendation Q.850.

DefaultCallHandling ::= ENUMERATED {
	continueCall (0) ,
	releaseCall (1) ,
	...}
	-- exception handling:
	-- reception of values in range 2-31 shall be treated as "continueCall"
	-- reception of values greater than 31 shall be treated as "releaseCall"

CamelCapabilityHandling ::= INTEGER(1..16) 
	-- value 1 = CAMEL phase 1,
	-- value 2 = CAMEL phase 2,
	-- value 3 = CAMEL Phase 3,
	-- value 4 = CAMEL phase 4:
	-- reception of values greater than 4 shall be treated as CAMEL phase 4.

SupportedCamelPhases ::= BIT STRING {
	phase1 (0),
	phase2 (1),
	phase3 (2),
	phase4 (3)} (SIZE (1..16)) 
-- A node shall mark in the BIT STRING all CAMEL Phases it supports.
-- Other values than listed above shall be discarded.

OfferedCamel4CSIs ::= BIT STRING {	
	o-csi	(0),
	d-csi	(1),
	vt-csi	(2),
	t-csi	(3),
	mt-sms-csi	(4),
	mg-csi	(5),
	psi-enhancements	(6) 
} (SIZE (7..16))
-- A node supporting Camel phase 4 shall mark in the BIT STRING all Camel4 CSIs 
-- it offers.
-- Other values than listed above shall be discarded.

OfferedCamel4Functionalities ::= BIT STRING {	
	initiateCallAttempt	(0),
	splitLeg	(1),
	moveLeg	(2),
	disconnectLeg	(3),
	entityReleased	(4),
	dfc-WithArgument	(5),
	playTone	(6),
	dtmf-MidCall	(7),
	chargingIndicator	(8),
	alertingDP	(9),
	locationAtAlerting	(10),
	changeOfPositionDP	(11),
	or-Interactions	(12),
	warningToneEnhancements	(13),
	cf-Enhancements	(14),
	subscribedEnhancedDialledServices	(15),
	servingNetworkEnhancedDialledServices (16),
	criteriaForChangeOfPositionDP	(17),
	serviceChangeDP	(18),
	collectInformation	(19)
} (SIZE (15..64))
-- A node supporting Camel phase 4 shall mark in the BIT STRING all CAMEL4 
-- functionalities it offers.
-- Other values than listed above shall be discarded.

SMS-CSI ::= SEQUENCE {
	sms-CAMEL-TDP-DataList	[0] SMS-CAMEL-TDP-DataList	OPTIONAL,
	camelCapabilityHandling	[1] CamelCapabilityHandling	OPTIONAL,
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	notificationToCSE	[3] NULL	OPTIONAL,
	csi-Active	[4] NULL	OPTIONAL,
	...}
--	notificationToCSE and csi-Active shall not be present
--	when MO-SMS-CSI or MT-SMS-CSI is sent to VLR or SGSN.
--	They may only be included in ATSI/ATM ack/NSDC message.
--	SMS-CAMEL-TDP-Data and  camelCapabilityHandling shall be present in 
--	the SMS-CSI sequence.
--	If SMS-CSI is segmented, sms-CAMEL-TDP-DataList and camelCapabilityHandling shall be 
--	present in the first segment

SMS-CAMEL-TDP-DataList ::= SEQUENCE SIZE (1..maxNumOfCamelTDPData) OF
	SMS-CAMEL-TDP-Data
--	SMS-CAMEL-TDP-DataList shall not contain more than one instance of
--	SMS-CAMEL-TDP-Data containing the same value for sms-TriggerDetectionPoint.

SMS-CAMEL-TDP-Data ::= SEQUENCE {
	sms-TriggerDetectionPoint	[0] SMS-TriggerDetectionPoint,
	serviceKey	[1] ServiceKey,
	gsmSCF-Address	[2] ISDN-AddressString,
	defaultSMS-Handling	[3] DefaultSMS-Handling,
	extensionContainer	[4] ExtensionContainer	OPTIONAL,
	...
	}

SMS-TriggerDetectionPoint ::= ENUMERATED {
	sms-CollectedInfo (1),
	...,
	sms-DeliveryRequest (2)
	}
--	exception handling:
--	For SMS-CAMEL-TDP-Data and MT-smsCAMELTDP-Criteria sequences containing this 
--	parameter with any other value than the ones listed the receiver shall ignore
--	the whole sequence.
--
--	If this parameter is received with any other value than sms-CollectedInfo
--	in an SMS-CAMEL-TDP-Data sequence contained in mo-sms-CSI, then the receiver shall
--	ignore the whole SMS-CAMEL-TDP-Data sequence.
--
--	If this parameter is received with any other value than sms-DeliveryRequest
--	in an SMS-CAMEL-TDP-Data sequence contained in mt-sms-CSI then the receiver shall
--	ignore the whole SMS-CAMEL-TDP-Data sequence.
--
--	If this parameter is received with any other value than sms-DeliveryRequest
--	in an MT-smsCAMELTDP-Criteria sequence then the receiver shall
--	ignore the whole MT-smsCAMELTDP-Criteria sequence.

DefaultSMS-Handling ::= ENUMERATED {
	continueTransaction (0) ,
	releaseTransaction (1) ,
	...}
--	exception handling:
--	reception of values in range 2-31 shall be treated as "continueTransaction"
--	reception of values greater than 31 shall be treated as "releaseTransaction"

M-CSI ::= SEQUENCE {
	mobilityTriggers	MobilityTriggers,
	serviceKey	ServiceKey,
	gsmSCF-Address	[0]	ISDN-AddressString,
	extensionContainer	[1]	ExtensionContainer	OPTIONAL,
	notificationToCSE	[2] NULL	OPTIONAL,
	csi-Active	[3] NULL	OPTIONAL,
	...}
--	notificationToCSE and csi-Active shall not be present when M-CSI is sent to VLR.
--	They may only be included in ATSI/ATM ack/NSDC message.

MG-CSI ::= SEQUENCE {
	mobilityTriggers	MobilityTriggers,
	serviceKey	ServiceKey,
	gsmSCF-Address	[0]	ISDN-AddressString,
	extensionContainer	[1]	ExtensionContainer	OPTIONAL,
	notificationToCSE	[2] NULL	OPTIONAL,
	csi-Active	[3] NULL	OPTIONAL,
	...}
--	notificationToCSE and csi-Active shall not be present when MG-CSI is sent to SGSN.
--	They may only be included in ATSI/ATM ack/NSDC message.

MobilityTriggers  ::= SEQUENCE SIZE (1..maxNumOfMobilityTriggers) OF
	MM-Code

maxNumOfMobilityTriggers INTEGER ::= 10

MM-Code ::= OCTET STRING (SIZE (1))
--	This type is used to indicate a Mobility Management event.
--	Actions for the following MM-Code values are defined in CAMEL Phase 4:
--
--	CS domain MM events:
--	Location-update-in-same-VLR	MM-Code ::= '00000000'B
--	Location-update-to-other-VLR	MM-Code ::= '00000001'B
--	IMSI-Attach	MM-Code ::= '00000010'B
--	MS-initiated-IMSI-Detach	MM-Code ::= '00000011'B
--	Network-initiated-IMSI-Detach	MM-Code ::= '00000100'B
--
--	PS domain MM events:
--	Routeing-Area-update-in-same-SGSN	MM-Code ::= '10000000'B
--	Routeing-Area-update-to-other-SGSN-update-from-new-SGSN
--	MM-Code ::= '10000001'B
--	Routeing-Area-update-to-other-SGSN-disconnect-by-detach
--	MM-Code ::= '10000010'B
--	GPRS-Attach	MM-Code ::= '10000011'B
--	MS-initiated-GPRS-Detach	MM-Code ::= '10000100'B
--	Network-initiated-GPRS-Detach	MM-Code ::= '10000101'B 
--	Network-initiated-transfer-to-MS-not-reachable-for-paging
--	MM-Code ::= '10000110'B
--
--	If the MSC receives any other MM-code than the ones listed above for the
--	CS domain, then the MSC shall ignore that MM-code.
--	If the SGSN receives any other MM-code than the ones listed above for the
--	PS domain, then the SGSN shall ignore that MM-code.

T-CSI ::= SEQUENCE {
	t-BcsmCamelTDPDataList	T-BcsmCamelTDPDataList,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	camelCapabilityHandling	[0] CamelCapabilityHandling	OPTIONAL,
	notificationToCSE	[1] NULL	OPTIONAL,
	csi-Active	[2] NULL	OPTIONAL}
--	notificationToCSE and csi-Active shall not be present when VT-CSI/T-CSI is sent
--	to VLR/GMSC.
--	They may only be included in ATSI/ATM ack/NSDC message.
--	T-CSI shall not be segmented.

T-BcsmCamelTDPDataList ::= SEQUENCE SIZE (1..maxNumOfCamelTDPData) OF
	T-BcsmCamelTDPData
	--- T-BcsmCamelTDPDataList shall not contain more than one instance of
	--- T-BcsmCamelTDPData containing the same value for t-BcsmTriggerDetectionPoint.
	--- For CAMEL Phase 2, this means that only one instance of T-BcsmCamelTDPData is allowed
	--- with t-BcsmTriggerDetectionPoint being equal to DP12. 
	--- For CAMEL Phase 3, more TDP's are allowed.

T-BcsmCamelTDPData ::= SEQUENCE {
	t-BcsmTriggerDetectionPoint	T-BcsmTriggerDetectionPoint,
	serviceKey	ServiceKey,
	gsmSCF-Address	[0] ISDN-AddressString,
	defaultCallHandling	[1] DefaultCallHandling,
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	...}

T-BcsmTriggerDetectionPoint ::= ENUMERATED {
	termAttemptAuthorized (12),
	... ,
	tBusy (13),
	tNoAnswer (14)}
	-- exception handling:
	-- For T-BcsmCamelTDPData sequences containing this parameter with any other
	-- value than the ones listed above, the receiver shall ignore the whole
	-- T-BcsmCamelTDPData sequence.

-- gprs location information retrieval types

SendRoutingInfoForGprsArg ::= SEQUENCE {
	imsi	[0] IMSI,
	ggsn-Address	[1] GSN-Address	OPTIONAL, 
	ggsn-Number	[2]	ISDN-AddressString,
	extensionContainer	[3] ExtensionContainer	OPTIONAL,
	...}

SendRoutingInfoForGprsRes ::= SEQUENCE {
	sgsn-Address	[0] GSN-Address,
	ggsn-Address	[1]	GSN-Address	OPTIONAL,
	mobileNotReachableReason	[2]	AbsentSubscriberDiagnosticSM	OPTIONAL,
	extensionContainer	[3] ExtensionContainer	OPTIONAL,
	...}

-- failure report types

FailureReportArg ::= SEQUENCE {
	imsi	[0] IMSI,
	ggsn-Number	[1] ISDN-AddressString	,
	ggsn-Address	[2] GSN-Address	OPTIONAL,
	extensionContainer	[3] ExtensionContainer	OPTIONAL,
	...}

FailureReportRes ::= SEQUENCE {
	ggsn-Address	[0] GSN-Address	OPTIONAL,
	extensionContainer	[1] ExtensionContainer	OPTIONAL,
	...}

-- gprs notification types

NoteMsPresentForGprsArg ::= SEQUENCE {
	imsi	[0] IMSI,
	sgsn-Address	[1] GSN-Address,
	ggsn-Address	[2] GSN-Address	OPTIONAL,
	extensionContainer	[3] ExtensionContainer	OPTIONAL,
	...}

NoteMsPresentForGprsRes ::= SEQUENCE {
	extensionContainer	[0] ExtensionContainer	OPTIONAL,
	...}

-- fault recovery types

ResetArg ::= SEQUENCE {
	sendingNodenumber	SendingNode-Number,
	hlr-List	HLR-List	OPTIONAL,
	-- The hlr-List parameter shall only be applicable for a restart of the HSS/HLR.
	extensionContainer	[0] ExtensionContainer	OPTIONAL,
	...,
	reset-Id-List	[1]	Reset-Id-List	OPTIONAL,
	subscriptionData	[2]	InsertSubscriberDataArg	OPTIONAL,
	subscriptionDataDeletion	[3]	DeleteSubscriberDataArg	OPTIONAL}

SendingNode-Number ::= CHOICE {
	hlr-Number	ISDN-AddressString,
	css-Number	[1] ISDN-AddressString}

RestoreDataArg ::= SEQUENCE {
	imsi	IMSI,
	lmsi	LMSI	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	... ,
	vlr-Capability	[6] VLR-Capability	OPTIONAL,
	restorationIndicator	[7]	NULL	OPTIONAL 
 }

RestoreDataRes ::= SEQUENCE {
	hlr-Number	ISDN-AddressString,
	msNotReachable	NULL	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

-- VBS/VGCS types

VBSDataList ::= SEQUENCE SIZE (1..maxNumOfVBSGroupIds) OF
	VoiceBroadcastData

VGCSDataList ::= SEQUENCE SIZE (1..maxNumOfVGCSGroupIds) OF
	VoiceGroupCallData

maxNumOfVBSGroupIds  INTEGER ::= 50

maxNumOfVGCSGroupIds  INTEGER ::= 50

VoiceGroupCallData  ::= SEQUENCE {
	groupId	GroupId, 
	-- groupId shall be filled with six TBCD fillers (1111)if the longGroupId is present  
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	additionalSubscriptions	AdditionalSubscriptions	OPTIONAL,
	additionalInfo	[0] AdditionalInfo	OPTIONAL,
	longGroupId	[1] Long-GroupId	OPTIONAL }

	-- VoiceGroupCallData containing a longGroupId shall not be sent to VLRs that did not
	-- indicate support of long Group IDs within the Update Location or Restore Data 
	-- request message

AdditionalInfo ::= BIT STRING (SIZE (1..136))
--	Refers to Additional Info as specified in 3GPP TS 43.068 

AdditionalSubscriptions ::= BIT STRING {
	privilegedUplinkRequest (0),
	emergencyUplinkRequest (1),
	emergencyReset (2)} (SIZE (3..8))
-- Other bits than listed above shall be discarded.

VoiceBroadcastData ::= SEQUENCE {
	groupid	GroupId, 
	-- groupId shall be filled with six TBCD fillers (1111)if the longGroupId is present
	broadcastInitEntitlement	NULL	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	longGroupId	[0] Long-GroupId	OPTIONAL }
	
-- VoiceBroadcastData containing a longGroupId shall not be sent to VLRs that did not
-- indicate support of long Group IDs within the Update Location or Restore Data 
	-- request message

GroupId  ::= TBCD-STRING (SIZE (3))
	-- When Group-Id is less than six characters in length, the TBCD filler (1111)
	-- is used to fill unused half octets.
	-- Refers to the Group Identification as specified in 3GPP TS 23.003 
	-- and 3GPP TS 43.068/ 43.069

Long-GroupId  ::= TBCD-STRING (SIZE (4))
	-- When Long-Group-Id is less than eight characters in length, the TBCD filler (1111)
	-- is used to fill unused half octets.
	-- Refers to the Group Identification as specified in 3GPP TS 23.003 
	-- and 3GPP TS 43.068/ 43.069


-- provide subscriber info types

ProvideSubscriberInfoArg ::= SEQUENCE {
	imsi	[0] IMSI,
	lmsi	[1] LMSI	OPTIONAL,
	requestedInfo	[2] RequestedInfo,
	extensionContainer	[3] ExtensionContainer	OPTIONAL,
	...,
	callPriority	[4]	EMLPP-Priority	OPTIONAL
	}

ProvideSubscriberInfoRes ::= SEQUENCE {
	subscriberInfo	SubscriberInfo,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

SubscriberInfo ::= SEQUENCE {
	locationInformation	[0] LocationInformation	OPTIONAL,
	subscriberState	[1] SubscriberState	OPTIONAL,
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	... ,
	locationInformationGPRS	[3] LocationInformationGPRS	OPTIONAL,
	ps-SubscriberState	[4] PS-SubscriberState	OPTIONAL,
	imei	[5] IMEI	OPTIONAL,
	ms-Classmark2	[6] MS-Classmark2	OPTIONAL,
	gprs-MS-Class	[7] GPRSMSClass	OPTIONAL,
	mnpInfoRes	[8] MNPInfoRes	OPTIONAL,
	imsVoiceOverPS-SessionsIndication	[9] IMS-VoiceOverPS-SessionsInd	OPTIONAL,
	lastUE-ActivityTime	[10] Time	OPTIONAL,
	lastRAT-Type	[11] Used-RAT-Type	OPTIONAL,
	eps-SubscriberState	[12] PS-SubscriberState	OPTIONAL,
	locationInformationEPS	[13] LocationInformationEPS	OPTIONAL,
	timeZone	[14] TimeZone	OPTIONAL,
	daylightSavingTime	[15] DaylightSavingTime	OPTIONAL,
	locationInformation5GS	[16] LocationInformation5GS	OPTIONAL }

--	If the HLR receives locationInformation, subscriberState or ms-Classmark2 from an SGSN or
--	MME (via an IWF), it shall discard them.
--	If the HLR receives locationInformationGPRS, ps-SubscriberState, gprs-MS-Class or
--	locationInformationEPS (outside the locationInformation IE) from a VLR, it shall
--	discard them.
--	If the HLR receives parameters which it has not requested, it shall discard them.
--	The locationInformation5GS IE should be absent if UE did not access via 5GS and IM-SSF.

IMS-VoiceOverPS-SessionsInd ::= ENUMERATED {
	imsVoiceOverPS-SessionsNotSupported	(0),
	imsVoiceOverPS-SessionsSupported	(1),
	unknown	(2)
	}
--	"unknown" shall not be used within ProvideSubscriberInfoRes

TimeZone ::= OCTET STRING (SIZE (2..3))
--	Refer to the 3GPP TS 29.272 [144] for details.

DaylightSavingTime ::= ENUMERATED {
	noAdjustment	(0),
	plusOneHourAdjustment	(1),
	plusTwoHoursAdjustment	(2)
	}
--	Refer to the 3GPP TS 29.272 [144] for details.

MNPInfoRes ::= SEQUENCE {
	routeingNumber	[0] RouteingNumber	OPTIONAL,
	imsi	[1] IMSI	OPTIONAL,
	msisdn	[2] ISDN-AddressString	OPTIONAL,
	numberPortabilityStatus	[3] NumberPortabilityStatus	OPTIONAL,
	extensionContainer	[4] ExtensionContainer	OPTIONAL,
	... }
--	The IMSI parameter contains a generic IMSI, i.e. it is not tied necessarily to the 
--	Subscriber. MCC and MNC values in this IMSI shall point to the Subscription Network of 
--	the Subscriber. See 3GPP TS 23.066 [108].

RouteingNumber ::= TBCD-STRING (SIZE (1..5))


NumberPortabilityStatus ::= ENUMERATED {
	notKnownToBePorted	(0),
	ownNumberPortedOut	(1),
	foreignNumberPortedToForeignNetwork	(2),
	...,
	ownNumberNotPortedOut	(4),
	foreignNumberPortedIn	(5)
	}
	--	exception handling: 
	--  reception of other values than the ones listed the receiver shall ignore the 
	--  whole NumberPortabilityStatus;
	--  ownNumberNotPortedOut or foreignNumberPortedIn may only be included in Any Time 
	--  Interrogation message.

MS-Classmark2 ::= OCTET STRING (SIZE (3))
	-- This parameter carries the value part of the MS Classmark 2 IE defined in 
	-- 3GPP TS 24.008 [35].

GPRSMSClass ::= SEQUENCE {
	mSNetworkCapability	[0] MSNetworkCapability,
	mSRadioAccessCapability	[1] MSRadioAccessCapability	OPTIONAL
	}

MSNetworkCapability ::= OCTET STRING (SIZE (1..8))
	-- This parameter carries the value part of the MS Network Capability IE defined in 
	-- 3GPP TS 24.008 [35].
	
MSRadioAccessCapability ::= OCTET STRING (SIZE (1..50))
	-- This parameter carries the value part of the MS Radio Access Capability IE defined in
	-- 3GPP TS 24.008 [35].

RequestedInfo ::= SEQUENCE {
	locationInformation	[0] NULL	OPTIONAL,
	subscriberState	[1] NULL	OPTIONAL,
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	..., 
	currentLocation	[3] NULL	OPTIONAL,
	requestedDomain	[4] DomainType	OPTIONAL,
	imei	[6] NULL	OPTIONAL,
	ms-classmark	[5] NULL	OPTIONAL,
	mnpRequestedInfo	[7] NULL	OPTIONAL,
	locationInformationEPS-Supported	[11] NULL	OPTIONAL,
	t-adsData	[8] NULL	OPTIONAL,
	requestedNodes	[9] RequestedNodes	OPTIONAL,
	servingNodeIndication	[10] NULL	OPTIONAL,
	localTimeZoneRequest	[12] NULL	OPTIONAL
 }

--	currentLocation and locationInformationEPS-Supported shall be absent if 
--	locationInformation is absent
--	t-adsData shall be absent in messages sent to the VLR
--	requestedNodes shall be absent if requestedDomain is "cs-Domain"
--	servingNodeIndication shall be absent if locationInformation is absent;
--	servingNodeIndication shall be absent if current location is present;
--	servingNodeIndication indicates by its presence that only the serving node's
--	address (MME-Name or SGSN-Number or VLR-Number) is requested.

DomainType ::=  ENUMERATED {
	cs-Domain	(0),
	ps-Domain	(1),
	...}
-- exception handling:
-- reception of values > 1 shall be mapped to 'cs-Domain'

RequestedNodes ::= BIT STRING {
	mme	(0),
	sgsn	(1)} (SIZE (1..8))
-- Other bits than listed above shall be discarded.

LocationInformation ::= SEQUENCE {
	ageOfLocationInformation	AgeOfLocationInformation	OPTIONAL,
	geographicalInformation	[0] GeographicalInformation	OPTIONAL,
	vlr-number	[1] ISDN-AddressString	OPTIONAL,
	locationNumber	[2] LocationNumber	OPTIONAL,
	cellGlobalIdOrServiceAreaIdOrLAI	[3] CellGlobalIdOrServiceAreaIdOrLAI	OPTIONAL,
	extensionContainer	[4] ExtensionContainer	OPTIONAL,
	... ,
	selectedLSA-Id	[5] LSAIdentity	OPTIONAL,
	msc-Number	[6] ISDN-AddressString	OPTIONAL,
	geodeticInformation	[7] GeodeticInformation	OPTIONAL, 
	currentLocationRetrieved	[8] NULL	OPTIONAL,
	sai-Present	[9] NULL	OPTIONAL,
	locationInformationEPS	[10] LocationInformationEPS	OPTIONAL,
	userCSGInformation	[11] UserCSGInformation	OPTIONAL }
-- sai-Present indicates that the cellGlobalIdOrServiceAreaIdOrLAI parameter contains
-- a Service Area Identity.
-- currentLocationRetrieved shall be present 
-- if the location information were retrieved after a successfull paging.
-- if the locationinformationEPS IE is present then the cellGlobalIdOrServiceAreaIdOrLAI IE,
-- the ageOfLocationInformation IE, the geographicalInformation IE, the geodeticInformation IE
-- and the currentLocationRetrieved IE (outside the locationInformationEPS IE) shall be
-- absent. As an exception, both the cellGlobalIdOrServiceAreaIdOrLAI IE including an LAI and 
-- the locationinformationEPS IE may be present in a MAP-NOTE-MM-EVENT.
-- UserCSGInformation contains the CSG ID, Access mode, and the CSG Membership Indication in
-- the case the Access mode is Hybrid Mode.
-- The locationInformationEPS IE should be absent if locationInformationEPS-Supported was not
-- received in the RequestedInfo IE. 

LocationInformationEPS ::= SEQUENCE {
	e-utranCellGlobalIdentity	[0] E-UTRAN-CGI	OPTIONAL,
	trackingAreaIdentity	[1] TA-Id	OPTIONAL,
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	geographicalInformation	[3] GeographicalInformation	OPTIONAL,
	geodeticInformation	[4] GeodeticInformation	OPTIONAL,
	currentLocationRetrieved	[5] NULL	OPTIONAL,
	ageOfLocationInformation	[6] AgeOfLocationInformation	OPTIONAL,
	...,
	mme-Name	[7] DiameterIdentity	OPTIONAL }
-- currentLocationRetrieved shall be present if the location information
-- was retrieved after successful paging.


LocationInformationGPRS ::= SEQUENCE {
	cellGlobalIdOrServiceAreaIdOrLAI	[0] CellGlobalIdOrServiceAreaIdOrLAI OPTIONAL,
	routeingAreaIdentity	[1] RAIdentity	OPTIONAL,
	geographicalInformation	[2] GeographicalInformation	OPTIONAL,
	sgsn-Number	[3] ISDN-AddressString	OPTIONAL,
	selectedLSAIdentity	[4] LSAIdentity	OPTIONAL,
	extensionContainer	[5] ExtensionContainer	OPTIONAL,
	...,
	sai-Present	[6] NULL	OPTIONAL,
	geodeticInformation	[7] GeodeticInformation	OPTIONAL,
	currentLocationRetrieved	[8] NULL	OPTIONAL,
	ageOfLocationInformation	[9] AgeOfLocationInformation	OPTIONAL,
	userCSGInformation	[10] UserCSGInformation	OPTIONAL }
-- sai-Present indicates that the cellGlobalIdOrServiceAreaIdOrLAI parameter contains
-- a Service Area Identity.
-- currentLocationRetrieved shall be present if the location information
-- was retrieved after successful paging.
-- UserCSGInformation contains the CSG ID, Access mode, and the CSG Membership Indication in
-- the case the Access mode is Hybrid Mode. 


LocationInformation5GS ::= SEQUENCE {
	nrCellGlobalIdentity	[0] NR-CGI	OPTIONAL,
	e-utranCellGlobalIdentity	[1] E-UTRAN-CGI	OPTIONAL,
	geographicalInformation	[2] GeographicalInformation	OPTIONAL,
	geodeticInformation	[3] GeodeticInformation	OPTIONAL,
	amf-address	[4] FQDN	OPTIONAL,
	trackingAreaIdentity	[5] TA-Id	OPTIONAL,
	currentLocationRetrieved	[6] NULL	OPTIONAL,
	ageOfLocationInformation	[7] AgeOfLocationInformation	OPTIONAL,
	vplmnId	[8] PLMN-Id	OPTIONAL,
	localtimeZone	[9] TimeZone	OPTIONAL,
	rat-Type	[10] Used-RAT-Type	OPTIONAL,
	extensionContainer	[11] ExtensionContainer	OPTIONAL,
	...,
	nrTrackingAreaIdentity	[12] NR-TA-Id	OPTIONAL
	}
-- currentLocationRetrieved shall be present if the location information
-- was retrieved after successful paging.


UserCSGInformation ::= SEQUENCE {
	csg-Id	[0] CSG-Id,
	extensionContainer	[1] ExtensionContainer	OPTIONAL,
	...,
	accessMode	[2] OCTET STRING (SIZE(1))	OPTIONAL,
	cmi	[3] OCTET STRING (SIZE(1))	OPTIONAL }
-- The encoding of the accessMode and cmi parameters are as defined in 3GPP TS 29.060 [105].

GeographicalInformation ::= OCTET STRING (SIZE (8))
--	Refers to geographical Information defined in 3GPP TS 23.032.
--	Only the description of an ellipsoid point with uncertainty circle
--	as specified in 3GPP TS 23.032 is allowed to be used
--	The internal structure according to 3GPP TS 23.032 is as follows:
--	Type of shape (ellipsoid point with uncertainty circle)	1 octet
--	Degrees of Latitude	3 octets
--	Degrees of Longitude	3 octets
--	Uncertainty code	1 octet

GeodeticInformation ::= OCTET STRING (SIZE (10))
--	Refers to Calling Geodetic Location defined in Q.763 (1999).
--	Only the description of an ellipsoid point with uncertainty circle
--	as specified in Q.763 (1999) is allowed to be used
--	The internal structure according to Q.763 (1999) is as follows:
--	Screening and presentation indicators	1 octet
--	Type of shape (ellipsoid point with uncertainty circle)	1 octet
--	Degrees of Latitude	3 octets
--	Degrees of Longitude	3 octets
--	Uncertainty code	1 octet
--	Confidence	1 octet

LocationNumber ::= OCTET STRING (SIZE (2..10))
	-- the internal structure is defined in ITU-T Rec Q.763

SubscriberState ::= CHOICE {
	assumedIdle	[0] NULL,
	camelBusy	[1] NULL,
	netDetNotReachable	NotReachableReason,
	notProvidedFromVLR	[2] NULL}

PS-SubscriberState ::= CHOICE {
	notProvidedFromSGSNorMME	[0] NULL,
	ps-Detached	[1] NULL,
	ps-AttachedNotReachableForPaging	[2] NULL,
	ps-AttachedReachableForPaging	[3] NULL,
	ps-PDP-ActiveNotReachableForPaging	[4] PDP-ContextInfoList,
	ps-PDP-ActiveReachableForPaging	[5] PDP-ContextInfoList,
	netDetNotReachable	NotReachableReason }

PDP-ContextInfoList ::= SEQUENCE SIZE (1..maxNumOfPDP-Contexts) OF
	PDP-ContextInfo

PDP-ContextInfo ::= SEQUENCE {
	pdp-ContextIdentifier	[0] ContextId,
	pdp-ContextActive	[1] NULL	OPTIONAL,
	pdp-Type	[2] PDP-Type,
	pdp-Address	[3] PDP-Address	OPTIONAL,
	apn-Subscribed	[4] APN	OPTIONAL,
	apn-InUse	[5] APN	OPTIONAL,
	nsapi	[6] NSAPI	OPTIONAL,
	transactionId	[7] TransactionId	OPTIONAL,
	teid-ForGnAndGp	[8] TEID	OPTIONAL,
	teid-ForIu	[9] TEID	OPTIONAL,
	ggsn-Address	[10] GSN-Address	OPTIONAL,
	qos-Subscribed	[11] Ext-QoS-Subscribed	OPTIONAL,
	qos-Requested	[12] Ext-QoS-Subscribed	OPTIONAL,
	qos-Negotiated	[13] Ext-QoS-Subscribed	OPTIONAL,
	chargingId	[14] GPRSChargingID	OPTIONAL,
	chargingCharacteristics	[15] ChargingCharacteristics	OPTIONAL,
	rnc-Address	[16] GSN-Address	OPTIONAL,
	extensionContainer	[17] ExtensionContainer	OPTIONAL,
	...,
	qos2-Subscribed	[18] Ext2-QoS-Subscribed	OPTIONAL,
	-- qos2-Subscribed may be present only if qos-Subscribed is present.
	qos2-Requested	[19] Ext2-QoS-Subscribed	OPTIONAL,
	-- qos2-Requested may be present only if qos-Requested is present.
	qos2-Negotiated	[20] Ext2-QoS-Subscribed	OPTIONAL,
	-- qos2-Negotiated may be present only if qos-Negotiated is present.
	qos3-Subscribed	[21] Ext3-QoS-Subscribed	OPTIONAL,
	-- qos3-Subscribed may be present only if qos2-Subscribed is present.
	qos3-Requested	[22] Ext3-QoS-Subscribed	OPTIONAL,
	-- qos3-Requested may be present only if qos2-Requested is present.
	qos3-Negotiated	[23] Ext3-QoS-Subscribed	OPTIONAL,
	-- qos3-Negotiated may be present only if qos2-Negotiated is present.
	qos4-Subscribed	[25] Ext4-QoS-Subscribed	OPTIONAL,
	-- qos4-Subscribed may be present only if qos3-Subscribed is present.
	qos4-Requested	[26] Ext4-QoS-Subscribed	OPTIONAL,
	-- qos4-Requested may be present only if qos3-Requested is present.
	qos4-Negotiated	[27] Ext4-QoS-Subscribed	OPTIONAL,
	-- qos4-Negotiated may be present only if qos3-Negotiated is present. 
	ext-pdp-Type	[28] Ext-PDP-Type	OPTIONAL,
	-- contains the value IPv4v6 defined in 3GPP TS 29.060 [105], if the PDP can be
	-- accessed by dual-stack UEs.
	ext-pdp-Address	[29] PDP-Address	OPTIONAL
	-- contains an additional IP address in case of dual-stack static IP address assignment
	-- for the UE.
	-- it may contain an IPv4 or an IPv6 address/prefix, and it may be present
	-- only if pdp-Address is present; if both are present, each parameter shall
	-- contain a different type of address (IPv4 or IPv6).

}

NSAPI ::= INTEGER (0..15)
--	This type is used to indicate the Network layer Service Access Point

TransactionId ::= OCTET STRING (SIZE (1..2))
--	This type carries the value part of the transaction identifier which is used in the 
--	session management messages on the access interface. The encoding is defined in 
--	3GPP TS 24.008

TEID ::= OCTET STRING (SIZE (4))
--	This type carries the value part of the Tunnel Endpoint Identifier which is used to 
--	distinguish between different tunnels between the same pair of entities which communicate 
--	using the GPRS Tunnelling Protocol The encoding is defined in 3GPP TS 29.060.

GPRSChargingID ::= OCTET STRING (SIZE (4))
--	The Charging ID is a unique four octet value generated by the GGSN when 
--	a PDP Context is activated. A Charging ID is generated for each activated context.
--	The encoding is defined in 3GPP TS 29.060.

NotReachableReason ::= ENUMERATED {
	msPurged (0),
	imsiDetached (1),
	restrictedArea (2),
	notRegistered (3)}

-- any time interrogation info types

AnyTimeInterrogationArg ::= SEQUENCE {
	subscriberIdentity	[0] SubscriberIdentity,
	requestedInfo	[1] RequestedInfo,
	gsmSCF-Address	[3] ISDN-AddressString,
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	...}

AnyTimeInterrogationRes ::= SEQUENCE {
	subscriberInfo	SubscriberInfo,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

-- any time information handling types

AnyTimeSubscriptionInterrogationArg ::= SEQUENCE {
	subscriberIdentity	[0] SubscriberIdentity,
	requestedSubscriptionInfo	[1] RequestedSubscriptionInfo,
	gsmSCF-Address	[2] ISDN-AddressString,
	extensionContainer	[3] ExtensionContainer	OPTIONAL,
	longFTN-Supported	[4]	NULL	OPTIONAL,
	...}

AnyTimeSubscriptionInterrogationRes ::= SEQUENCE {
	callForwardingData	[1] CallForwardingData	OPTIONAL,
	callBarringData	[2] CallBarringData	OPTIONAL,
	odb-Info	[3] ODB-Info	OPTIONAL,
	camel-SubscriptionInfo	[4] CAMEL-SubscriptionInfo	OPTIONAL,
	supportedVLR-CAMEL-Phases	[5] SupportedCamelPhases	OPTIONAL,
	supportedSGSN-CAMEL-Phases	[6] SupportedCamelPhases	OPTIONAL,
	extensionContainer	[7] ExtensionContainer	OPTIONAL,
	... ,
	offeredCamel4CSIsInVLR	[8] OfferedCamel4CSIs	OPTIONAL,
	offeredCamel4CSIsInSGSN	[9] OfferedCamel4CSIs	OPTIONAL,
	msisdn-BS-List	[10] MSISDN-BS-List	OPTIONAL,
	csg-SubscriptionDataList	[11] CSG-SubscriptionDataList	OPTIONAL, 
	cw-Data	[12]	CallWaitingData	OPTIONAL,
	ch-Data	[13]	CallHoldData	OPTIONAL,
	clip-Data	[14] ClipData	OPTIONAL,
	clir-Data	[15]	ClirData	OPTIONAL,
	ect-data	[16] EctData	OPTIONAL }

CallWaitingData ::= SEQUENCE {
	cwFeatureList	[1] Ext-CwFeatureList,
	notificationToCSE	[2] NULL	OPTIONAL,
	... }

Ext-CwFeatureList ::= SEQUENCE SIZE (1..maxNumOfExt-BasicServiceGroups) OF
	Ext-CwFeature

Ext-CwFeature ::= SEQUENCE {
	basicService	[1] Ext-BasicServiceCode, 
	ss-Status	[2] Ext-SS-Status,
	... }

ClipData ::= SEQUENCE {
	ss-Status	[1] Ext-SS-Status,
	overrideCategory	[2] OverrideCategory,
	notificationToCSE	[3] NULL	OPTIONAL,
	... }	

ClirData ::= SEQUENCE {
	ss-Status	[1] Ext-SS-Status,
	cliRestrictionOption	[2] CliRestrictionOption	OPTIONAL,
	notificationToCSE	[3] NULL	OPTIONAL,
	... }

CallHoldData ::= SEQUENCE {
	ss-Status	[1] Ext-SS-Status,
	notificationToCSE	[2] NULL	OPTIONAL,
	... }

EctData ::= SEQUENCE {
	ss-Status	[1] Ext-SS-Status,
	notificationToCSE	[2] NULL	OPTIONAL,
	... }

RequestedSubscriptionInfo ::= SEQUENCE {
	requestedSS-Info	[1] SS-ForBS-Code	OPTIONAL,
	odb	[2] NULL	OPTIONAL,
	requestedCAMEL-SubscriptionInfo	[3] RequestedCAMEL-SubscriptionInfo	OPTIONAL,
	supportedVLR-CAMEL-Phases	[4] NULL	OPTIONAL,
	supportedSGSN-CAMEL-Phases	[5] NULL	OPTIONAL,
	extensionContainer	[6] ExtensionContainer	OPTIONAL,
	...,
	additionalRequestedCAMEL-SubscriptionInfo
	[7] AdditionalRequestedCAMEL-SubscriptionInfo
		OPTIONAL,
	msisdn-BS-List	[8] NULL	OPTIONAL,
	csg-SubscriptionDataRequested	[9] NULL	OPTIONAL,
	cw-Info	[10]	NULL	OPTIONAL,
	clip-Info	[11] NULL	OPTIONAL,
	clir-Info	[12] NULL	OPTIONAL,
	hold-Info	[13] NULL	OPTIONAL,
	ect-Info	[14] NULL	OPTIONAL }

MSISDN-BS-List ::= SEQUENCE SIZE (1..maxNumOfMSISDN) OF
	MSISDN-BS

maxNumOfMSISDN  INTEGER ::= 50


MSISDN-BS ::= SEQUENCE {
	msisdn	ISDN-AddressString,	
	basicServiceList	[0]	BasicServiceList	OPTIONAL,
	extensionContainer	[1]	ExtensionContainer	OPTIONAL,
	...}

RequestedCAMEL-SubscriptionInfo ::= ENUMERATED {
	o-CSI	(0),
	t-CSI	(1),
	vt-CSI	(2),
	tif-CSI	(3),
	gprs-CSI	(4),
	mo-sms-CSI	(5),
	ss-CSI	(6),
	m-CSI	(7),
	d-csi	(8)}

AdditionalRequestedCAMEL-SubscriptionInfo ::= ENUMERATED {
	mt-sms-CSI	(0),
	mg-csi	(1),
	o-IM-CSI	(2),
	d-IM-CSI	(3),
	vt-IM-CSI	(4),
	...}
--	exception handling: unknown values shall be discarded by the receiver.

CallForwardingData ::= SEQUENCE {
	forwardingFeatureList	Ext-ForwFeatureList,
	notificationToCSE	NULL	OPTIONAL,
	extensionContainer	[0] ExtensionContainer	OPTIONAL,
	...}

CallBarringData ::= SEQUENCE {
	callBarringFeatureList	Ext-CallBarFeatureList,
	password	Password	OPTIONAL,
	wrongPasswordAttemptsCounter	WrongPasswordAttemptsCounter	OPTIONAL,
	notificationToCSE	NULL	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

WrongPasswordAttemptsCounter ::= INTEGER (0..4)

ODB-Info ::= SEQUENCE {
	odb-Data	ODB-Data,
	notificationToCSE	NULL	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

CAMEL-SubscriptionInfo ::= SEQUENCE {
	o-CSI	[0]	O-CSI	OPTIONAL,
	o-BcsmCamelTDP-CriteriaList	[1]	O-BcsmCamelTDPCriteriaList	OPTIONAL, 
	d-CSI	[2]	D-CSI	OPTIONAL,
	t-CSI	[3]	T-CSI	OPTIONAL,
	t-BCSM-CAMEL-TDP-CriteriaList	[4]	T-BCSM-CAMEL-TDP-CriteriaList	OPTIONAL,
	vt-CSI	[5]	T-CSI	OPTIONAL,
	vt-BCSM-CAMEL-TDP-CriteriaList	[6]	T-BCSM-CAMEL-TDP-CriteriaList	OPTIONAL,
	tif-CSI	[7]	NULL	OPTIONAL,
	tif-CSI-NotificationToCSE	[8]	NULL	OPTIONAL,
	gprs-CSI	[9]	GPRS-CSI	OPTIONAL,
	mo-sms-CSI	[10]	SMS-CSI	OPTIONAL,
	ss-CSI	[11]	SS-CSI	OPTIONAL,
	m-CSI	[12]	M-CSI	OPTIONAL,
	extensionContainer	[13]	ExtensionContainer	OPTIONAL,
	...,
	specificCSIDeletedList	[14]	SpecificCSI-Withdraw	OPTIONAL,
	mt-sms-CSI	[15]	SMS-CSI	OPTIONAL,
	mt-smsCAMELTDP-CriteriaList	[16]	MT-smsCAMELTDP-CriteriaList	OPTIONAL,
	mg-csi	[17]	MG-CSI	OPTIONAL,
	o-IM-CSI	[18] O-CSI	OPTIONAL,
	o-IM-BcsmCamelTDP-CriteriaList	[19] O-BcsmCamelTDPCriteriaList	OPTIONAL,
	d-IM-CSI	[20] D-CSI	OPTIONAL,
	vt-IM-CSI	[21] T-CSI	OPTIONAL,
	vt-IM-BCSM-CAMEL-TDP-CriteriaList	[22]	T-BCSM-CAMEL-TDP-CriteriaList	OPTIONAL
	}

AnyTimeModificationArg ::= SEQUENCE {
	subscriberIdentity	[0]	SubscriberIdentity,
	gsmSCF-Address	[1]	ISDN-AddressString,
	modificationRequestFor-CF-Info	[2]	ModificationRequestFor-CF-Info OPTIONAL,
	modificationRequestFor-CB-Info	[3]	ModificationRequestFor-CB-Info OPTIONAL,
	modificationRequestFor-CSI	[4]	ModificationRequestFor-CSI	OPTIONAL,
	extensionContainer	[5]	ExtensionContainer	OPTIONAL,
	longFTN-Supported	[6]	NULL	OPTIONAL,
	...,
	modificationRequestFor-ODB-data	[7]	ModificationRequestFor-ODB-data OPTIONAL,
	modificationRequestFor-IP-SM-GW-Data	[8]	ModificationRequestFor-IP-SM-GW-Data OPTIONAL,
	activationRequestForUE-reachability	[9]	RequestedServingNode	OPTIONAL,
	modificationRequestFor-CSG	[10]	ModificationRequestFor-CSG	OPTIONAL,
	modificationRequestFor-CW-Data	[11] ModificationRequestFor-CW-Info	OPTIONAL,
	modificationRequestFor-CLIP-Data	[12] ModificationRequestFor-CLIP-Info	OPTIONAL,
	modificationRequestFor-CLIR-Data	[13] ModificationRequestFor-CLIR-Info	OPTIONAL,
	modificationRequestFor-HOLD-Data	[14] ModificationRequestFor-CH-Info	OPTIONAL,
	modificationRequestFor-ECT-Data	[15] ModificationRequestFor-ECT-Info	OPTIONAL }

ModificationRequestFor-CW-Info ::= SEQUENCE {
	basicService	[0]	Ext-BasicServiceCode	OPTIONAL,
	ss-Status	[1]	Ext-SS-Status	OPTIONAL,
	modifyNotificationToCSE	[2]	ModificationInstruction	OPTIONAL,
	extensionContainer	[3]	ExtensionContainer	OPTIONAL,
	...}

ModificationRequestFor-CH-Info ::= SEQUENCE {
	ss-Status	[0]	Ext-SS-Status	OPTIONAL,
	modifyNotificationToCSE	[1]	ModificationInstruction	OPTIONAL,
	extensionContainer	[2]	ExtensionContainer	OPTIONAL,
	...}

ModificationRequestFor-ECT-Info ::= SEQUENCE {
	ss-Status	[0]	Ext-SS-Status	OPTIONAL,
	modifyNotificationToCSE	[1]	ModificationInstruction	OPTIONAL,
	extensionContainer	[2]	ExtensionContainer	OPTIONAL,
	...}

ModificationRequestFor-CLIR-Info ::= SEQUENCE {
	ss-Status	[0]	Ext-SS-Status	OPTIONAL,
	cliRestrictionOption	[1]  CliRestrictionOption	OPTIONAL,
	modifyNotificationToCSE	[2]	ModificationInstruction	OPTIONAL,
	extensionContainer	[3]	ExtensionContainer	OPTIONAL,
	...}

ModificationRequestFor-CLIP-Info ::= SEQUENCE {
	ss-Status	[0]	Ext-SS-Status	OPTIONAL,
	overrideCategory	[1]  OverrideCategory	OPTIONAL,
	modifyNotificationToCSE	[2]	ModificationInstruction	OPTIONAL,
	extensionContainer	[3]	ExtensionContainer	OPTIONAL,
	...}


ModificationRequestFor-CSG ::= SEQUENCE {
	modifyNotificationToCSE	[0]	ModificationInstruction	OPTIONAL,
	extensionContainer	[1]	ExtensionContainer	OPTIONAL,
	...}

RequestedServingNode ::= BIT STRING {
	mmeAndSgsn  (0)} (SIZE (1..8))

ServingNode ::= BIT STRING {
	mme (0),
	sgsn (1)} (SIZE (2..8))
-- Other bits than listed above shall be discarded.

AnyTimeModificationRes ::= SEQUENCE {
	ss-InfoFor-CSE	[0]	Ext-SS-InfoFor-CSE	OPTIONAL,
	camel-SubscriptionInfo	[1]	CAMEL-SubscriptionInfo	OPTIONAL,
	extensionContainer	[2]	ExtensionContainer	OPTIONAL,
	...,
	odb-Info	[3]	ODB-Info	OPTIONAL,
	cw-Data	[4]	CallWaitingData	OPTIONAL,
	ch-Data	[5]	CallHoldData	OPTIONAL,
	clip-Data	[6] ClipData	OPTIONAL,
	clir-Data	[7]	ClirData	OPTIONAL,
	ect-data	[8] EctData	OPTIONAL,
	serviceCentreAddress	[9] AddressString	OPTIONAL
 }

ModificationRequestFor-CF-Info ::= SEQUENCE {
	ss-Code	[0]	SS-Code,
	basicService	[1]	Ext-BasicServiceCode	OPTIONAL,
	ss-Status	[2]	Ext-SS-Status	OPTIONAL,
	forwardedToNumber	[3]	AddressString	OPTIONAL,
	forwardedToSubaddress	[4]	ISDN-SubaddressString	OPTIONAL,
	noReplyConditionTime	[5]	Ext-NoRepCondTime	OPTIONAL,
	modifyNotificationToCSE	[6]	ModificationInstruction	OPTIONAL,
	extensionContainer	[7]	ExtensionContainer	OPTIONAL,
	...}

ModificationRequestFor-CB-Info ::= SEQUENCE {
	ss-Code	[0]	SS-Code,
	basicService	[1]	Ext-BasicServiceCode	OPTIONAL,
	ss-Status	[2]	Ext-SS-Status	OPTIONAL,
	password	[3]	Password	OPTIONAL,
	wrongPasswordAttemptsCounter	[4]	WrongPasswordAttemptsCounter	OPTIONAL,
	modifyNotificationToCSE	[5]	ModificationInstruction	OPTIONAL,
	extensionContainer	[6]	ExtensionContainer	OPTIONAL,
	...}

ModificationRequestFor-ODB-data ::= SEQUENCE {
	odb-data	[0]	ODB-Data	OPTIONAL,
	modifyNotificationToCSE	[1]	ModificationInstruction	OPTIONAL,
	extensionContainer	[2]	ExtensionContainer	OPTIONAL,
	...}

ModificationRequestFor-CSI ::= SEQUENCE {
	requestedCamel-SubscriptionInfo	[0]	RequestedCAMEL-SubscriptionInfo,
	modifyNotificationToCSE	[1]	ModificationInstruction	OPTIONAL,
	modifyCSI-State	[2]	ModificationInstruction	OPTIONAL,
	extensionContainer	[3]	ExtensionContainer	OPTIONAL,
	...,
	additionalRequestedCAMEL-SubscriptionInfo
	[4] AdditionalRequestedCAMEL-SubscriptionInfo
		OPTIONAL }
-- requestedCamel-SubscriptionInfo shall be discarded if
-- additionalRequestedCAMEL-SubscriptionInfo is received

ModificationRequestFor-IP-SM-GW-Data ::= SEQUENCE {
	modifyRegistrationStatus	[0]	ModificationInstruction	OPTIONAL,
	extensionContainer	[1]	ExtensionContainer	OPTIONAL,
	...,
	ip-sm-gw-DiameterAddress	[2]	NetworkNodeDiameterAddress	OPTIONAL
	-- ip-sm-gw-DiameterAddress may be present when ModificationInstruction is "activate"
	}

ModificationInstruction ::= ENUMERATED {
	deactivate	(0),
	activate	(1)}

-- subscriber data modification notification types

NoteSubscriberDataModifiedArg ::= SEQUENCE {
	imsi	IMSI,
	msisdn	ISDN-AddressString,
	forwardingInfoFor-CSE	[0] Ext-ForwardingInfoFor-CSE	OPTIONAL,
	callBarringInfoFor-CSE	[1] Ext-CallBarringInfoFor-CSE	OPTIONAL,
	odb-Info	[2] ODB-Info	OPTIONAL,
	camel-SubscriptionInfo	[3] CAMEL-SubscriptionInfo	OPTIONAL,
	allInformationSent	[4] NULL	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	ue-reachable	[5] ServingNode	OPTIONAL,
	csg-SubscriptionDataList	[6] CSG-SubscriptionDataList	OPTIONAL,
	cw-Data	[7]	CallWaitingData	OPTIONAL,
	ch-Data	[8]	CallHoldData	OPTIONAL,
	clip-Data	[9] ClipData	OPTIONAL,
	clir-Data	[10]	ClirData	OPTIONAL,
	ect-data	[11] EctData	OPTIONAL }

NoteSubscriberDataModifiedRes ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

-- mobility management event notificatioon info types

NoteMM-EventArg::= SEQUENCE {
	serviceKey	ServiceKey,
	eventMet	[0]	MM-Code,
	imsi	[1]	IMSI,
	msisdn	[2]	ISDN-AddressString,
	locationInformation	[3]	LocationInformation	OPTIONAL,
	supportedCAMELPhases	[5]	SupportedCamelPhases	OPTIONAL,
	extensionContainer	[6]	ExtensionContainer	OPTIONAL,
	...,
	locationInformationGPRS	[7]	LocationInformationGPRS	OPTIONAL,
	offeredCamel4Functionalities	[8] OfferedCamel4Functionalities	OPTIONAL
}

NoteMM-EventRes ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

Ext-SS-InfoFor-CSE ::= CHOICE {
	forwardingInfoFor-CSE	[0] Ext-ForwardingInfoFor-CSE,
	callBarringInfoFor-CSE	[1] Ext-CallBarringInfoFor-CSE
	}

Ext-ForwardingInfoFor-CSE ::= SEQUENCE {
	ss-Code	[0]	SS-Code,
	forwardingFeatureList	[1]	Ext-ForwFeatureList,
	notificationToCSE	[2]	NULL	OPTIONAL,
	extensionContainer	[3]	ExtensionContainer	OPTIONAL,
	...}

Ext-CallBarringInfoFor-CSE ::= SEQUENCE {
	ss-Code	[0]	SS-Code,
	callBarringFeatureList	[1]	Ext-CallBarFeatureList,
	password	[2]	Password	OPTIONAL,
	wrongPasswordAttemptsCounter	[3]	WrongPasswordAttemptsCounter	OPTIONAL,
	notificationToCSE	[4]	NULL	OPTIONAL,
	extensionContainer	[5]	ExtensionContainer	OPTIONAL,
	...}

-- vcsg location registration types

UpdateVcsgLocationArg ::= SEQUENCE {
	imsi	IMSI,
	msisdn	[2] ISDN-AddressString	OPTIONAL,
	vlr-Number	[0] ISDN-AddressString	OPTIONAL,
	sgsn-Number	[1] ISDN-AddressString	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	... }

UpdateVcsgLocationRes ::= SEQUENCE {
	temporaryEmptySubscriptiondataIndicator	NULL	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	... }

CancelVcsgLocationArg ::= SEQUENCE {
	identity	Identity,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...
	}

CancelVcsgLocationRes ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	... }


.#END
17.7.2	Operation and maintenance data types
.$MAP-OM-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-OM-DataTypes (12) version19 (19)}

DEFINITIONS

IMPLICIT TAGS

::=

BEGIN

EXPORTS
	ActivateTraceModeArg,
	ActivateTraceModeRes,
	DeactivateTraceModeArg,
	DeactivateTraceModeRes,
	TracePropagationList
;

IMPORTS
	AddressString,
	IMSI,
	GSN-Address,
	GlobalCellId,
	E-UTRAN-CGI,
	TA-Id,
	RAIdentity,
	LAIFixedLength,
	PLMN-Id
FROM MAP-CommonDataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-CommonDataTypes (18) version19 (19)}

	ExtensionContainer
FROM MAP-ExtensionDataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version19 (19)}

;

ActivateTraceModeArg ::= SEQUENCE {
	imsi	[0] IMSI	OPTIONAL,
	traceReference	[1] TraceReference,
	traceType	[2] TraceType,
	omc-Id	[3] AddressString	OPTIONAL,
	extensionContainer	[4] ExtensionContainer	OPTIONAL,
	...,
	traceReference2	[5] TraceReference2	OPTIONAL,
	traceDepthList	[6] TraceDepthList	OPTIONAL,
	traceNE-TypeList	[7] TraceNE-TypeList	OPTIONAL,
	traceInterfaceList	[8] TraceInterfaceList	OPTIONAL,
	traceEventList	[9] TraceEventList	OPTIONAL,
	traceCollectionEntity	[10] GSN-Address	OPTIONAL,
	mdt-Configuration	[11] MDT-Configuration	OPTIONAL
	}

MDT-Configuration ::= SEQUENCE {
	jobType	JobType,
	areaScope	AreaScope	OPTIONAL,
	listOfMeasurements	ListOfMeasurements	OPTIONAL,
	reportingTrigger	[0] ReportingTrigger	OPTIONAL,
	reportInterval	ReportInterval	OPTIONAL,
	reportAmount	[1] ReportAmount	OPTIONAL,
	eventThresholdRSRP	EventThresholdRSRP	OPTIONAL,
	eventThresholdRSRQ	[2] EventThresholdRSRQ	OPTIONAL,
	loggingInterval	[3] LoggingInterval	OPTIONAL,
	loggingDuration	[4] LoggingDuration	OPTIONAL,
	extensionContainer	[5] ExtensionContainer	OPTIONAL,
	...,
	measurementPeriodUMTS	[6] PeriodUMTS	OPTIONAL,
	measurementPeriodLTE	[7] PeriodLTE	OPTIONAL,
	collectionPeriodRRM-UMTS	[8] PeriodUMTS	OPTIONAL,
	collectionPeriodRRM-LTE	[9] PeriodLTE	OPTIONAL,
	positioningMethod	[10] PositioningMethod	OPTIONAL,
	measurementQuantity	[11] MeasurementQuantity	OPTIONAL,
	eventThreshold1F	[12] EventThreshold1F	OPTIONAL,
	eventThreshold1I	[13] EventThreshold1I	OPTIONAL,
	mdt-Allowed-PLMN-List	[14] MDT-Allowed-PLMNId-List	OPTIONAL }

MDT-Allowed-PLMNId-List ::= SEQUENCE SIZE (1..16) OF
	PLMN-Id
PeriodUMTS ::= ENUMERATED {
	d250ms (0),
	d500ms (1),
	d1000ms (2),
	d2000ms (3),
	d3000ms (4),
	d4000ms (5),
	d6000ms (6),
	d8000ms (7),
	d12000ms (8),
	d16000ms (9),
	d20000ms (10),
	d24000ms (11),
	d28000ms (12),
	d32000ms (13),
	d64000ms (14)}

PeriodLTE ::= ENUMERATED {
	d1024ms (0),
	d1280ms (1),
	d2048ms (2),
	d2560ms (3),
	d5120ms (4),
	d10240ms (5),
	d1min (6)}

PositioningMethod ::= OCTET STRING (SIZE (1))
	-- Octet is coded as described in 3GPP TS 32.422 [132].

MeasurementQuantity ::= OCTET STRING (SIZE (1))
	-- Octet is coded as described in 3GPP TS 32.422 [132].

EventThreshold1F ::= INTEGER
	(-120..165)

EventThreshold1I ::= INTEGER
	(-120..-25)

JobType ::= ENUMERATED {
	immediate-MDT-only (0),
	logged-MDT-only (1),
	trace-only (2),
	immediate-MDT-and-trace (3)}

AreaScope ::= SEQUENCE {
	cgi-List	[0] CGI-List	OPTIONAL,
	e-utran-cgi-List	[1] E-UTRAN-CGI-List	OPTIONAL,
	routingAreaId-List	[2] RoutingAreaId-List	OPTIONAL,
	locationAreaId-List	[3] LocationAreaId-List	OPTIONAL,
	trackingAreaId-List	[4] TrackingAreaId-List	OPTIONAL,
	extensionContainer	[5] ExtensionContainer	OPTIONAL,
	... }

CGI-List ::= SEQUENCE SIZE (1..32) OF
	GlobalCellId

E-UTRAN-CGI-List ::= SEQUENCE SIZE (1..32) OF
	E-UTRAN-CGI

RoutingAreaId-List ::= SEQUENCE SIZE (1..8) OF
	RAIdentity

LocationAreaId-List ::= SEQUENCE SIZE (1..8) OF
	LAIFixedLength

TrackingAreaId-List ::= SEQUENCE SIZE (1..8) OF
	TA-Id

ListOfMeasurements ::= OCTET STRING (SIZE (4))
	-- Octets are coded as described in 3GPP TS 32.422.

ReportingTrigger ::= OCTET STRING (SIZE (1))
	-- Octet is coded as described in 3GPP TS 32.422.

ReportInterval ::= ENUMERATED {
	umts250ms (0),
	umts500ms (1),
	umts1000ms (2),
	umts2000ms (3),
	umts3000ms (4),
	umts4000ms (5),
	umts6000ms (6),
	umts8000ms (7),
	umts12000ms (8),
	umts16000ms (9),
	umts20000ms (10),
	umts24000ms (11),
	umts28000ms (12),
	umts32000ms (13),
	umts64000ms (14),
	lte120ms (15),
	lte240ms (16),
	lte480ms (17),
	lte640ms (18),
	lte1024ms (19),
	lte2048ms (20),
	lte5120ms (21),
	lte10240ms (22),
	lte1min (23),
	lte6min (24),
	lte12min (25),
	lte30min (26),
	lte60min (27)}


ReportAmount ::= ENUMERATED {
	d1 (0),
	d2 (1),
	d4 (2),
	d8 (3),
	d16 (4),
	d32 (5),
	d64 (6),
	infinity (7)}

EventThresholdRSRP ::= INTEGER
	(0..97)

EventThresholdRSRQ ::= INTEGER
	(0..34)

LoggingInterval ::= ENUMERATED {
	d1dot28 (0),
	d2dot56 (1),
	d5dot12 (2),
	d10dot24 (3),
	d20dot48 (4),
	d30dot72 (5),
	d40dot96 (6),
	d61dot44 (7)}

LoggingDuration ::= ENUMERATED {
	d600sec (0),
	d1200sec (1),
	d2400sec (2),
	d3600sec (3),
	d5400sec (4),
	d7200sec (5)}

TraceReference ::= OCTET STRING (SIZE (1..2))

TraceReference2 ::= OCTET STRING (SIZE (3))

TraceRecordingSessionReference ::= OCTET STRING (SIZE (2))

TraceType ::= INTEGER
	(0..255)
	-- Trace types are fully defined in  3GPP TS 52.008. [61]

TraceDepthList ::= SEQUENCE {
	msc-s-TraceDepth	[0] TraceDepth	OPTIONAL,
	mgw-TraceDepth	[1] TraceDepth	OPTIONAL,
	sgsn-TraceDepth	[2] TraceDepth	OPTIONAL,
	ggsn-TraceDepth	[3] TraceDepth	OPTIONAL,
	rnc-TraceDepth	[4] TraceDepth	OPTIONAL,
	bmsc-TraceDepth	[5] TraceDepth	OPTIONAL,
	... ,
	mme-TraceDepth	[6] TraceDepth	OPTIONAL,
	sgw-TraceDepth	[7] TraceDepth	OPTIONAL,
	pgw-TraceDepth	[8] TraceDepth	OPTIONAL,
	eNB-TraceDepth	[9] TraceDepth	OPTIONAL,
	msc-s-TraceDepthExtension	[10] TraceDepthExtension	OPTIONAL,
	mgw-TraceDepthExtension	[11] TraceDepthExtension	OPTIONAL,
	sgsn-TraceDepthExtension	[12] TraceDepthExtension	OPTIONAL,
	ggsn-TraceDepthExtension	[13] TraceDepthExtension	OPTIONAL,
	rnc-TraceDepthExtension	[14] TraceDepthExtension	OPTIONAL,
	bmsc-TraceDepthExtension	[15] TraceDepthExtension	OPTIONAL,
	mme-TraceDepthExtension	[16] TraceDepthExtension	OPTIONAL,
	sgw-TraceDepthExtension	[17] TraceDepthExtension	OPTIONAL,
	pgw-TraceDepthExtension	[18] TraceDepthExtension	OPTIONAL,
	eNB-TraceDepthExtension	[19] TraceDepthExtension	OPTIONAL }

-- If one of the TraceDepthExtension types is sent, the corresponding TraceDepth type
-- shall also be sent with the same enumeration value to allow the receiver not supporting
-- the Extension to fall back to the non extended type.
-- If one of the TraceDepthExtension types is received and supported, the corresponding
-- TraceDepth type shall be ignored.

TraceDepth ::= ENUMERATED {
	minimum (0),
	medium (1),
	maximum (2),
	...}
-- The value medium is applicable only for RNC. For other network elements, if value medium
-- is received, value minimum shall be applied.

TraceDepthExtension ::= ENUMERATED {
	minimumWithoutVendorSpecificExtension (0),
	mediumWithoutVendorSpecificExtension (1),
	maximumWithoutVendorSpecificExtension (2),
	...}
-- The value mediumWithoutVendorSpecificExtension is applicable only for RNC. For other 
-- network elements, if value mediumWithoutVendorSpecificExtension is received, value
-- minimumWithoutVendorSpecificExtension shall be applied.

TraceNE-TypeList ::= BIT STRING {
	msc-s (0),
	mgw (1),
	sgsn (2),
	ggsn (3),
	rnc (4),
	bm-sc (5) ,
	mme (6),
	sgw (7),
	pgw (8),
	eNB (9)} (SIZE (6..16))
-- Other bits than listed above shall be discarded.

TraceInterfaceList ::= SEQUENCE {
	msc-s-List	[0] MSC-S-InterfaceList	OPTIONAL,
	mgw-List	[1] MGW-InterfaceList	OPTIONAL,
	sgsn-List	[2] SGSN-InterfaceList	OPTIONAL,
	ggsn-List	[3] GGSN-InterfaceList	OPTIONAL,
	rnc-List	[4] RNC-InterfaceList	OPTIONAL,
	bmsc-List	[5] BMSC-InterfaceList	OPTIONAL,
	...,
	mme-List	[6] MME-InterfaceList	OPTIONAL,
	sgw-List	[7] SGW-InterfaceList	OPTIONAL,
	pgw-List	[8] PGW-InterfaceList	OPTIONAL,
	eNB-List	[9] ENB-InterfaceList	OPTIONAL}

MSC-S-InterfaceList ::= BIT STRING {
	a (0),
	iu (1),
	mc (2),
	map-g (3),
	map-b (4),
	map-e (5),
	map-f (6),
	cap (7),
	map-d (8),
	map-c (9)} (SIZE (10..16))
-- Other bits than listed above shall be discarded.

MGW-InterfaceList ::= BIT STRING {
	mc (0),
	nb-up (1),
	iu-up (2)} (SIZE (3..8))
-- Other bits than listed above shall be discarded.

SGSN-InterfaceList ::= BIT STRING {
	gb (0),
	iu (1),
	gn (2),
	map-gr (3),
	map-gd (4),
	map-gf (5),
	gs (6),
	ge (7),
	s3 (8),
	s4 (9),
	s6d (10)} (SIZE (8..16))
-- Other bits than listed above shall be discarded.

GGSN-InterfaceList ::= BIT STRING {
	gn (0),
	gi (1),
	gmb (2)} (SIZE (3..8))
-- Other bits than listed above shall be discarded.

RNC-InterfaceList ::= BIT STRING {
	iu (0),
	iur (1),
	iub (2),
	uu (3)} (SIZE (4..8))
-- Other bits than listed above shall be discarded.

BMSC-InterfaceList ::= BIT STRING {
	gmb (0)} (SIZE (1..8))
-- Other bits than listed above shall be discarded.

MME-InterfaceList ::= BIT STRING {
	s1-mme (0),
	s3 (1),
	s6a (2),
	s10 (3),
	s11 (4)} (SIZE (5..8))
-- Other bits than listed above shall be discarded.

SGW-InterfaceList ::= BIT STRING {
	s4 (0),
	s5 (1),
	s8b (2),
	s11 (3),
	gxc (4)} (SIZE (5..8))
-- Other bits than listed above shall be discarded.

PGW-InterfaceList ::= BIT STRING {
	s2a (0),
	s2b (1),
	s2c (2),
	s5 (3),
	s6b (4),
	gx (5),
	s8b (6),
	sgi (7)} (SIZE (8..16))
-- Other bits than listed above shall be discarded.

ENB-InterfaceList ::= BIT STRING {
	s1-mme (0),
	x2 (1),
	uu (2)} (SIZE (3..8))
-- Other bits than listed above shall be discarded.

TraceEventList ::= SEQUENCE {
	msc-s-List	[0] MSC-S-EventList	OPTIONAL,
	mgw-List	[1] MGW-EventList	OPTIONAL,
	sgsn-List	[2] SGSN-EventList	OPTIONAL,
	ggsn-List	[3] GGSN-EventList	OPTIONAL,
	bmsc-List	[4] BMSC-EventList	OPTIONAL,
	...,
	mme-List	[5] MME-EventList	OPTIONAL,
	sgw-List	[6] SGW-EventList	OPTIONAL,
	pgw-List	[7] PGW-EventList	OPTIONAL}

MSC-S-EventList ::= BIT STRING {
	mo-mtCall (0),
	mo-mt-sms (1),
	lu-imsiAttach-imsiDetach (2),
	handovers (3),
	ss (4)} (SIZE (5..16))
-- Other bits than listed above shall be discarded.

MGW-EventList ::= BIT STRING {
	context (0)} (SIZE (1..8))
-- Other bits than listed above shall be discarded.

SGSN-EventList ::= BIT STRING {
	pdpContext (0),
	mo-mt-sms (1),
	rau-gprsAttach-gprsDetach (2),
	mbmsContext (3)} (SIZE (4..16))
-- Other bits than listed above shall be discarded.

GGSN-EventList ::= BIT STRING {
	pdpContext (0),
	mbmsContext (1)} (SIZE (2..8))
-- Other bits than listed above shall be discarded.

BMSC-EventList ::= BIT STRING {
	mbmsMulticastServiceActivation (0)} (SIZE (1..8))
-- Other bits than listed above shall be discarded.

MME-EventList ::= BIT STRING {
	ue-initiatedPDNconectivityRequest (0),
	serviceRequestts (1),
	initialAttachTrackingAreaUpdateDetach (2),
	ue-initiatedPDNdisconnection (3),
	bearerActivationModificationDeletion (4),
	handover (5)} (SIZE (6..8))
-- Other bits than listed above shall be discarded.

SGW-EventList ::= BIT STRING {
	pdn-connectionCreation (0),
	pdn-connectionTermination (1),
	bearerActivationModificationDeletion (2)} (SIZE (3..8))
-- Other bits than listed above shall be discarded.

PGW-EventList ::= BIT STRING {
	pdn-connectionCreation (0),
	pdn-connectionTermination (1),
	bearerActivationModificationDeletion (2)} (SIZE (3..8))
-- Other bits than listed above shall be discarded.

TracePropagationList ::= SEQUENCE {
	traceReference	[0] TraceReference	OPTIONAL,
	traceType	[1] TraceType	OPTIONAL,
	traceReference2	[2] TraceReference2	OPTIONAL,
	traceRecordingSessionReference	[3] TraceRecordingSessionReference OPTIONAL,
	rnc-TraceDepth	[4] TraceDepth	OPTIONAL,
	rnc-InterfaceList	[5] RNC-InterfaceList	OPTIONAL,
	msc-s-TraceDepth	[6] TraceDepth	OPTIONAL,
	msc-s-InterfaceList	[7] MSC-S-InterfaceList	OPTIONAL,
	msc-s-EventList	[8] MSC-S-EventList	OPTIONAL,
	mgw-TraceDepth	[9] TraceDepth	OPTIONAL,
	mgw-InterfaceList	[10] MGW-InterfaceList	OPTIONAL,
	mgw-EventList	[11] MGW-EventList	OPTIONAL,
	...,
	rnc-TraceDepthExtension	[12] TraceDepthExtension	OPTIONAL,
	msc-s-TraceDepthExtension	[13] TraceDepthExtension	OPTIONAL,
	mgw-TraceDepthExtension	[14] TraceDepthExtension	OPTIONAL
}
-- If one of the TraceDepthExtension types is sent, the corresponding TraceDepth type
-- shall also be sent with the same enumeration value to allow the receiver not supporting
-- the Extension to fall back to the non extended type.
-- If one of the TraceDepthExtension types is received and supported, the corresponding
-- TraceDepth type shall be ignored.

ActivateTraceModeRes ::= SEQUENCE {
	extensionContainer	[0] ExtensionContainer	OPTIONAL,
	...,
	traceSupportIndicator	[1]	NULL	OPTIONAL
	}

DeactivateTraceModeArg ::= SEQUENCE {
	imsi	[0] IMSI	OPTIONAL,
	traceReference	[1] TraceReference,
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	...,
	traceReference2	[3] TraceReference2	OPTIONAL
	}

DeactivateTraceModeRes ::= SEQUENCE {
	extensionContainer	[0] ExtensionContainer	OPTIONAL,
	...}

.#END
17.7.3	Call handling data types
.$MAP-CH-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-CH-DataTypes (13) version19 (19)}

DEFINITIONS

IMPLICIT TAGS

::=

BEGIN

EXPORTS
	SendRoutingInfoArg,
	SendRoutingInfoRes,
	ProvideRoamingNumberArg,
	ProvideRoamingNumberRes,
	ResumeCallHandlingArg,
	ResumeCallHandlingRes,
	NumberOfForwarding,
	SuppressionOfAnnouncement,
	CallReferenceNumber,
	SetReportingStateArg,
	SetReportingStateRes,
	StatusReportArg,
	StatusReportRes,
	RemoteUserFreeArg,
	RemoteUserFreeRes,
	IST-AlertArg,
	IST-AlertRes,
	IST-CommandArg,
IST-CommandRes,
UU-Data,
ReleaseResourcesArg,
ReleaseResourcesRes
;

IMPORTS
	SubscriberInfo,
	SupportedCamelPhases,
	OfferedCamel4CSIs,
	CUG-Interlock,
	O-CSI, 
	D-CSI,
	O-BcsmCamelTDPCriteriaList, 
	T-BCSM-CAMEL-TDP-CriteriaList,
	IST-SupportIndicator,
	IST-AlertTimerValue,
	T-CSI,
	NumberPortabilityStatus,
	PagingArea
FROM MAP-MS-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-MS-DataTypes (11) version19 (19)}

	ForwardingOptions,
	SS-List,
	CCBS-Feature
FROM MAP-SS-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-SS-DataTypes (14) version19 (19)}

	ISDN-AddressString,
	ISDN-SubaddressString,
	FTN-AddressString,
	ExternalSignalInfo,
	Ext-ExternalSignalInfo,
	IMSI,
	LMSI,
	Ext-BasicServiceCode,
	AlertingPattern,
	NAEA-PreferredCI,
	EMLPP-Priority,
	PLMN-Id
FROM MAP-CommonDataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-CommonDataTypes (18) version19 (19)}

	ExtensionContainer
FROM MAP-ExtensionDataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version19 (19)}
;


CUG-CheckInfo ::= SEQUENCE {
	cug-Interlock	CUG-Interlock,
	cug-OutgoingAccess	NULL	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

NumberOfForwarding ::= INTEGER (1..5)

SendRoutingInfoArg ::= SEQUENCE {
	msisdn	[0] ISDN-AddressString,
	cug-CheckInfo	[1] CUG-CheckInfo	OPTIONAL,
	numberOfForwarding	[2] NumberOfForwarding	OPTIONAL,
	interrogationType	[3] InterrogationType,
	or-Interrogation	[4] NULL	OPTIONAL,
	or-Capability	[5] OR-Phase	OPTIONAL,
	gmsc-OrGsmSCF-Address	[6] ISDN-AddressString,
	callReferenceNumber	[7] CallReferenceNumber	OPTIONAL,
	forwardingReason	[8] ForwardingReason	OPTIONAL,
	basicServiceGroup	[9] Ext-BasicServiceCode	OPTIONAL,
	networkSignalInfo	[10] ExternalSignalInfo	OPTIONAL,
	camelInfo	[11] CamelInfo	OPTIONAL,
	suppressionOfAnnouncement	[12] SuppressionOfAnnouncement	OPTIONAL,
	extensionContainer	[13] ExtensionContainer	OPTIONAL,
	...,
	alertingPattern	[14] AlertingPattern	OPTIONAL,
	ccbs-Call	[15] NULL	OPTIONAL,
	supportedCCBS-Phase	[16]	SupportedCCBS-Phase	OPTIONAL,
	additionalSignalInfo	[17] Ext-ExternalSignalInfo	OPTIONAL,
	istSupportIndicator	[18] IST-SupportIndicator	OPTIONAL,
	pre-pagingSupported	[19]	NULL	OPTIONAL,
	callDiversionTreatmentIndicator	[20]	CallDiversionTreatmentIndicator	OPTIONAL,
	longFTN-Supported	[21]	NULL	OPTIONAL,
	suppress-VT-CSI	[22]	NULL	OPTIONAL,
	suppressIncomingCallBarring	[23]	NULL	OPTIONAL,
	gsmSCF-InitiatedCall	[24]	NULL	OPTIONAL,
	basicServiceGroup2	[25] Ext-BasicServiceCode	OPTIONAL,
	networkSignalInfo2	[26] ExternalSignalInfo	OPTIONAL,
	suppressMTSS	[27] SuppressMTSS	OPTIONAL,
	mtRoamingRetrySupported	[28] NULL	OPTIONAL,
	callPriority	[29]	EMLPP-Priority	OPTIONAL
	}

SuppressionOfAnnouncement ::= NULL

SuppressMTSS ::= BIT STRING {
	suppressCUG	(0),
	suppressCCBS	(1) } (SIZE (2..16))
	--	Other bits than listed above shall be discarded

InterrogationType ::= ENUMERATED {
	basicCall  (0),
	forwarding  (1)}

OR-Phase ::= INTEGER (1..127)

CallReferenceNumber ::= OCTET STRING (SIZE (1..8))

ForwardingReason ::= ENUMERATED {
	notReachable  (0),
	busy  (1),
	noReply  (2)}

SupportedCCBS-Phase ::= INTEGER (1..127) 
-- exception handling:
-- Only value 1 is used.
-- Values in the ranges 2-127 are reserved for future use.
-- If received values 2-127 shall be mapped on to value 1.

CallDiversionTreatmentIndicator ::= OCTET STRING (SIZE(1))
--	callDiversionAllowed (xxxx xx01)
--	callDiversionNotAllowed (xxxx xx10)
--	network default is call diversion allowed

SendRoutingInfoRes ::= [3] SEQUENCE {
	imsi	[9] IMSI	OPTIONAL,
	-- IMSI must be present if SendRoutingInfoRes is not segmented.
	-- If the TC-Result-NL segmentation option is taken the IMSI must be
	-- present in one segmented transmission of SendRoutingInfoRes.
	extendedRoutingInfo	ExtendedRoutingInfo	OPTIONAL,
	cug-CheckInfo	[3] CUG-CheckInfo	OPTIONAL,
	cugSubscriptionFlag	[6] NULL	OPTIONAL,
	subscriberInfo	[7] SubscriberInfo	OPTIONAL,
	ss-List	[1] SS-List	OPTIONAL,
	basicService	[5] Ext-BasicServiceCode	OPTIONAL,
	forwardingInterrogationRequired	[4] NULL	OPTIONAL,
	vmsc-Address	[2] ISDN-AddressString	OPTIONAL,
	extensionContainer	[0] ExtensionContainer	OPTIONAL,
	... ,
	naea-PreferredCI	[10] NAEA-PreferredCI	OPTIONAL,
	-- naea-PreferredCI is included at the discretion of the HLR operator.
	ccbs-Indicators	[11] CCBS-Indicators	OPTIONAL,
	msisdn	[12] ISDN-AddressString	OPTIONAL,
	numberPortabilityStatus	[13] NumberPortabilityStatus	OPTIONAL,
	istAlertTimer	[14] IST-AlertTimerValue	OPTIONAL,
	supportedCamelPhasesInVMSC	[15]	SupportedCamelPhases	OPTIONAL,
	offeredCamel4CSIsInVMSC	[16] OfferedCamel4CSIs	OPTIONAL,
	routingInfo2	[17] RoutingInfo	OPTIONAL,
	ss-List2	[18] SS-List	OPTIONAL,
	basicService2	[19] Ext-BasicServiceCode	OPTIONAL,
	allowedServices	[20] AllowedServices	OPTIONAL,
	unavailabilityCause	[21] UnavailabilityCause	OPTIONAL,
	releaseResourcesSupported	[22] NULL	OPTIONAL,
	gsm-BearerCapability	[23] ExternalSignalInfo	OPTIONAL
	}

AllowedServices ::= BIT STRING {
	firstServiceAllowed	(0),
	secondServiceAllowed	(1) } (SIZE (2..8))
	--	firstService is the service indicated in the networkSignalInfo
	--	secondService is the service indicated in the networkSignalInfo2
	--	Other bits than listed above shall be discarded

UnavailabilityCause ::= ENUMERATED {
	bearerServiceNotProvisioned	(1),
	teleserviceNotProvisioned	(2),
	absentSubscriber	(3),
	busySubscriber	(4),
	callBarred	(5),
	cug-Reject	(6),
	...}
	--	exception handling: 
	--	Reception of other values than the ones listed shall result in the service
	--	being unavailable for that call.

CCBS-Indicators ::= SEQUENCE {
	ccbs-Possible	[0]	NULL	OPTIONAL,
	keepCCBS-CallIndicator	[1]	NULL	OPTIONAL,
	extensionContainer	[2]	ExtensionContainer	OPTIONAL,
	...}

RoutingInfo ::= CHOICE {
	roamingNumber	ISDN-AddressString,
	forwardingData	ForwardingData}

ForwardingData ::= SEQUENCE {
	forwardedToNumber	[5] ISDN-AddressString	OPTIONAL,
	-- When this datatype is sent from an HLR which supports CAMEL Phase 2
	-- to a GMSC which supports CAMEL Phase 2 the GMSC shall not check the
	-- format of the number
	forwardedToSubaddress	[4] ISDN-SubaddressString	OPTIONAL,
	forwardingOptions	[6] ForwardingOptions	OPTIONAL,
	extensionContainer	[7] ExtensionContainer	OPTIONAL,
	...,
	longForwardedToNumber	[8] FTN-AddressString	OPTIONAL}

ProvideRoamingNumberArg ::= SEQUENCE {
	imsi	[0] IMSI,
	msc-Number	[1] ISDN-AddressString,
	msisdn	[2] ISDN-AddressString	OPTIONAL,
	lmsi	[4] LMSI	OPTIONAL,
	gsm-BearerCapability	[5] ExternalSignalInfo	OPTIONAL,
	networkSignalInfo	[6] ExternalSignalInfo	OPTIONAL,
	suppressionOfAnnouncement	[7] SuppressionOfAnnouncement	OPTIONAL,
	gmsc-Address	[8] ISDN-AddressString	OPTIONAL,
	callReferenceNumber	[9] CallReferenceNumber	OPTIONAL,
	or-Interrogation	[10] NULL	OPTIONAL,
	extensionContainer	[11] ExtensionContainer	OPTIONAL,
	... ,
	alertingPattern	[12] AlertingPattern	OPTIONAL,
	ccbs-Call	[13] NULL	OPTIONAL,
	supportedCamelPhasesInInterrogatingNode	[15] SupportedCamelPhases	OPTIONAL,
	additionalSignalInfo	[14] Ext-ExternalSignalInfo	OPTIONAL,
	orNotSupportedInGMSC	[16] NULL	OPTIONAL,
	pre-pagingSupported	[17] NULL	OPTIONAL,
	longFTN-Supported	[18]	NULL	OPTIONAL,
	suppress-VT-CSI	[19]	NULL	OPTIONAL,
	offeredCamel4CSIsInInterrogatingNode	[20] OfferedCamel4CSIs	OPTIONAL,
	mtRoamingRetrySupported	[21] NULL	OPTIONAL,
	pagingArea	[22] PagingArea	OPTIONAL,
	callPriority	[23]	EMLPP-Priority	OPTIONAL,
	mtrf-Indicator	[24] NULL	OPTIONAL,
	oldMSC-Number	[25] ISDN-AddressString	OPTIONAL,
	lastUsedLtePLMN-Id	[26] PLMN-Id	OPTIONAL
	}

ProvideRoamingNumberRes ::= SEQUENCE {
	roamingNumber	ISDN-AddressString,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	releaseResourcesSupported	NULL	OPTIONAL,
	vmsc-Address	ISDN-AddressString	OPTIONAL }

ResumeCallHandlingArg ::= SEQUENCE {
	callReferenceNumber	[0] CallReferenceNumber	OPTIONAL,
	basicServiceGroup	[1] Ext-BasicServiceCode	OPTIONAL,
	forwardingData	[2] ForwardingData	OPTIONAL,
	imsi	[3] IMSI	OPTIONAL,
	cug-CheckInfo	[4] CUG-CheckInfo	OPTIONAL,
	o-CSI	[5] O-CSI	OPTIONAL,
	extensionContainer	[7] ExtensionContainer	OPTIONAL,
	ccbs-Possible	[8]	NULL	OPTIONAL,
	msisdn	[9]	ISDN-AddressString	OPTIONAL,
	uu-Data	[10] UU-Data	OPTIONAL,
	allInformationSent	[11] NULL	OPTIONAL,
	...,
	d-csi	[12]	D-CSI	OPTIONAL,
	o-BcsmCamelTDPCriteriaList	[13]	O-BcsmCamelTDPCriteriaList	OPTIONAL,
	basicServiceGroup2	[14] Ext-BasicServiceCode	OPTIONAL,
	mtRoamingRetry	[15] NULL	OPTIONAL
	}

UU-Data ::= SEQUENCE {
	uuIndicator	[0] UUIndicator	OPTIONAL,
	uui	[1] UUI	OPTIONAL,
	uusCFInteraction	[2] NULL	OPTIONAL,
	extensionContainer	[3] ExtensionContainer	OPTIONAL,
	...}

UUIndicator ::= OCTET STRING (SIZE (1))
	-- Octets are coded according to ETS 300 356

UUI  ::= OCTET STRING (SIZE (1..131))
	-- Octets are coded according to ETS 300 356

ResumeCallHandlingRes ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

CamelInfo ::= SEQUENCE {
	supportedCamelPhases	SupportedCamelPhases,
	suppress-T-CSI	NULL	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	... ,
	offeredCamel4CSIs	[0] OfferedCamel4CSIs	OPTIONAL }

ExtendedRoutingInfo ::= CHOICE {
	routingInfo	RoutingInfo,
	camelRoutingInfo	[8] CamelRoutingInfo}

CamelRoutingInfo ::= SEQUENCE {
	forwardingData	ForwardingData	OPTIONAL,
	gmscCamelSubscriptionInfo	[0] GmscCamelSubscriptionInfo,
	extensionContainer	[1] ExtensionContainer	OPTIONAL,
	...}

GmscCamelSubscriptionInfo ::= SEQUENCE {
	t-CSI	[0] T-CSI	OPTIONAL,
	o-CSI	[1] O-CSI	OPTIONAL,
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	...,
	o-BcsmCamelTDP-CriteriaList	[3] O-BcsmCamelTDPCriteriaList	OPTIONAL,
	t-BCSM-CAMEL-TDP-CriteriaList	[4]	T-BCSM-CAMEL-TDP-CriteriaList	OPTIONAL,
	d-csi	[5]	D-CSI	OPTIONAL}

SetReportingStateArg ::= SEQUENCE {
	imsi	[0]	IMSI	OPTIONAL,
	lmsi	[1]	LMSI	OPTIONAL,
	ccbs-Monitoring	[2]	ReportingState	OPTIONAL,
	extensionContainer	[3]	ExtensionContainer	OPTIONAL,
	...}

ReportingState ::= ENUMERATED {
	stopMonitoring	(0),
	startMonitoring	(1),
	...}
	-- exception handling:
	-- reception of values 2-10 shall be mapped to 'stopMonitoring' 
	-- reception of values > 10 shall be mapped to 'startMonitoring'

SetReportingStateRes ::= SEQUENCE{
	ccbs-SubscriberStatus	[0]	CCBS-SubscriberStatus	OPTIONAL,
	extensionContainer	[1]	ExtensionContainer	OPTIONAL,
	...}

CCBS-SubscriberStatus ::= ENUMERATED {
	ccbsNotIdle	(0),
	ccbsIdle	(1),
	ccbsNotReachable	(2),
	...}
	--  exception handling: 
	--  reception of values 3-10 shall be mapped to 'ccbsNotIdle'
	--  reception of values 11-20 shall be mapped to 'ccbsIdle'
	--  reception of values > 20 shall be mapped to 'ccbsNotReachable' 

StatusReportArg ::= SEQUENCE{
	imsi	[0]	IMSI,
	eventReportData	[1]	EventReportData	OPTIONAL,
	callReportdata	[2]	CallReportData	OPTIONAL,
	extensionContainer	[3]	ExtensionContainer	OPTIONAL,
	...}

EventReportData ::= SEQUENCE{
	ccbs-SubscriberStatus	[0]	CCBS-SubscriberStatus	OPTIONAL,
	extensionContainer	[1]	ExtensionContainer	OPTIONAL,
	...}

CallReportData ::= SEQUENCE{
	monitoringMode	[0]	MonitoringMode	OPTIONAL,
	callOutcome	[1]	CallOutcome	OPTIONAL,
	extensionContainer	[2]	ExtensionContainer	OPTIONAL,
	...}

MonitoringMode ::= ENUMERATED {
	a-side	(0),
	b-side	(1),
	...}
	--	exception handling: 
	--  reception of values 2-10 shall be mapped 'a-side'
	--  reception of values > 10 shall be mapped to 'b-side'

CallOutcome ::= ENUMERATED {
	success	(0),
	failure	(1),
	busy	(2),
	...}
	--	exception handling: 
	--  reception of values 3-10 shall be mapped to 'success'
	--  reception of values 11-20 shall be mapped to 'failure'
	--  reception of values > 20 shall be mapped to 'busy'

StatusReportRes ::= SEQUENCE {
	extensionContainer	[0]	ExtensionContainer	OPTIONAL,
	...}

RemoteUserFreeArg ::= SEQUENCE{
	imsi	[0]	IMSI,
	callInfo	[1]	ExternalSignalInfo,
	ccbs-Feature	[2]	CCBS-Feature,
	translatedB-Number	[3]	ISDN-AddressString,
	replaceB-Number	[4]	NULL	OPTIONAL,
	alertingPattern	[5]	AlertingPattern	OPTIONAL,
	extensionContainer	[6]	ExtensionContainer	OPTIONAL,
	...}

RemoteUserFreeRes ::= SEQUENCE{
	ruf-Outcome	[0]	RUF-Outcome,
	extensionContainer	[1]	ExtensionContainer	OPTIONAL,
	...}

RUF-Outcome ::= ENUMERATED{
	accepted (0),
	rejected (1),
	noResponseFromFreeMS (2), -- T4 Expiry
	noResponseFromBusyMS (3), -- T10 Expiry
	udubFromFreeMS (4),
	udubFromBusyMS (5),
	...}
	-- exception handling:
	-- reception of values 6-20 shall be mapped to 'accepted'
	-- reception of values 21-30 shall be mapped to 'rejected'
	-- reception of values 31-40 shall be mapped to 'noResponseFromFreeMS'
	-- reception of values 41-50 shall be mapped to 'noResponseFromBusyMS'
	-- reception of values 51-60 shall be mapped to 'udubFromFreeMS'
	-- reception of values > 60 shall be mapped to 'udubFromBusyMS'

IST-AlertArg ::= SEQUENCE{
	imsi	[0]	IMSI,
	extensionContainer	[1]	ExtensionContainer	OPTIONAL,
	...}

IST-AlertRes ::= SEQUENCE{
	istAlertTimer	[0]	IST-AlertTimerValue	OPTIONAL,
	istInformationWithdraw	[1]	NULL	OPTIONAL,
	callTerminationIndicator	[2]	CallTerminationIndicator	OPTIONAL,
	extensionContainer	[3]	ExtensionContainer	OPTIONAL,
	...}

IST-CommandArg ::= SEQUENCE{
	imsi	[0]	IMSI,
	extensionContainer	[1]	ExtensionContainer	OPTIONAL,
	...}

IST-CommandRes ::= SEQUENCE{
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

CallTerminationIndicator ::= ENUMERATED {
	terminateCallActivityReferred	(0),
	terminateAllCallActivities	(1),
	...}
	-- exception handling:
	-- reception of values 2-10 shall be mapped to ' terminateCallActivityReferred ' 
	-- reception of values > 10 shall be mapped to ' terminateAllCallActivities '

	-- In MSCs not supporting linkage of all call activities, any value received shall
	-- be interpreted as ' terminateCallActivityReferred '

ReleaseResourcesArg ::= SEQUENCE{
	msrn	ISDN-AddressString, 
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

ReleaseResourcesRes ::= SEQUENCE{
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}


.#END
17.7.4	Supplementary service data types
.$MAP-SS-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-SS-DataTypes (14) version19 (19)}

DEFINITIONS

IMPLICIT TAGS

::=

BEGIN

EXPORTS
	RegisterSS-Arg,
	SS-Info,
	SS-Status,
	SS-SubscriptionOption,
	SS-ForBS-Code,
	InterrogateSS-Res,
	USSD-Arg,
	USSD-Res, 
	USSD-DataCodingScheme,
	USSD-String,
	Password,
	GuidanceInfo,
	SS-List,
	SS-InfoList,
	OverrideCategory,
	CliRestrictionOption,
	NoReplyConditionTime,
	ForwardingOptions,
	maxNumOfSS,
	SS-Data,
	SS-InvocationNotificationArg,
	SS-InvocationNotificationRes,
	CCBS-Feature,
	RegisterCC-EntryArg,
	RegisterCC-EntryRes,
	EraseCC-EntryArg,
	EraseCC-EntryRes
;

IMPORTS
	AddressString,
	ISDN-AddressString,
	ISDN-SubaddressString,
	FTN-AddressString,
	IMSI,
	BasicServiceCode,
	AlertingPattern,
	EMLPP-Priority, 
	MaxMC-Bearers,
	MC-Bearers,
	ExternalSignalInfo
FROM MAP-CommonDataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-CommonDataTypes (18) version19 (19)}

	ExtensionContainer
FROM MAP-ExtensionDataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version19 (19)}

	SS-Code
FROM MAP-SS-Code {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-SS-Code (15) version19 (19)}
;


RegisterSS-Arg ::= SEQUENCE {
	ss-Code	SS-Code,
	basicService	BasicServiceCode	OPTIONAL,
	forwardedToNumber	[4] AddressString	OPTIONAL,
	forwardedToSubaddress	[6] ISDN-SubaddressString	OPTIONAL,
	noReplyConditionTime	[5] NoReplyConditionTime	OPTIONAL,
	...,
	defaultPriority	[7] EMLPP-Priority	OPTIONAL,
	nbrUser	[8] MC-Bearers	OPTIONAL,
	longFTN-Supported	[9]	NULL	OPTIONAL }

NoReplyConditionTime ::= INTEGER (5..30)

SS-Info ::= CHOICE {
	forwardingInfo	[0] ForwardingInfo,
	callBarringInfo	[1] CallBarringInfo,
	ss-Data	[3] SS-Data}

ForwardingInfo ::= SEQUENCE {
	ss-Code	SS-Code	OPTIONAL,
	forwardingFeatureList	ForwardingFeatureList,
	...}

ForwardingFeatureList ::= 
	SEQUENCE SIZE (1..maxNumOfBasicServiceGroups) OF
	ForwardingFeature

ForwardingFeature ::= SEQUENCE {
	basicService	BasicServiceCode	OPTIONAL,
	ss-Status	[4] SS-Status	OPTIONAL,
	forwardedToNumber	[5] ISDN-AddressString	OPTIONAL,
	forwardedToSubaddress	[8] ISDN-SubaddressString	OPTIONAL,
	forwardingOptions	[6] ForwardingOptions	OPTIONAL,
	noReplyConditionTime	[7] NoReplyConditionTime	OPTIONAL,
	...,
	longForwardedToNumber	[9] FTN-AddressString	OPTIONAL }

SS-Status ::= OCTET STRING (SIZE (1))

	-- bits 8765: 0000 (unused)
	-- bits 4321: Used to convey the "P bit","R bit","A bit" and "Q bit",
	--	 representing supplementary service state information
	--	 as defined in TS 3GPP TS 23.011 [22]

	-- bit 4: "Q bit"

	-- bit 3: "P bit"

	-- bit 2: "R bit"

	-- bit 1: "A bit"

ForwardingOptions ::= OCTET STRING (SIZE (1))

	-- bit 8: notification to forwarding party
	--	0  no notification
	--	1  notification

	-- bit 7: redirecting presentation
	--	0 no presentation  
	--	1  presentation

	-- bit 6: notification to calling party
	--	0  no notification
	--	1  notification

	-- bit 5: 0 (unused)

	-- bits 43: forwarding reason
	--	00  ms not reachable
	--	01  ms busy
	--	10  no reply
	--	11  unconditional when used in a SRI Result, 
	--	 or call deflection when used in a RCH Argument
	-- bits 21: 00 (unused)

CallBarringInfo ::= SEQUENCE {
	ss-Code	SS-Code	OPTIONAL,
	callBarringFeatureList	CallBarringFeatureList,
	...}

CallBarringFeatureList ::= SEQUENCE SIZE (1..maxNumOfBasicServiceGroups) OF
	CallBarringFeature

CallBarringFeature ::= SEQUENCE {
	basicService	BasicServiceCode	OPTIONAL,
	ss-Status	[4] SS-Status	OPTIONAL,
	...}

SS-Data ::= SEQUENCE {
	ss-Code	SS-Code	OPTIONAL,
	ss-Status	[4] SS-Status	OPTIONAL,
	ss-SubscriptionOption	SS-SubscriptionOption	OPTIONAL,
	basicServiceGroupList	BasicServiceGroupList	OPTIONAL,
	...,
	defaultPriority	EMLPP-Priority	OPTIONAL,
	nbrUser	[5] MC-Bearers	OPTIONAL
	}

SS-SubscriptionOption ::= CHOICE {
	cliRestrictionOption	[2] CliRestrictionOption,
	overrideCategory	[1] OverrideCategory}

CliRestrictionOption ::= ENUMERATED {
	permanent  (0),
	temporaryDefaultRestricted  (1),
	temporaryDefaultAllowed  (2)}

OverrideCategory ::= ENUMERATED {
	overrideEnabled  (0),
	overrideDisabled  (1)}

SS-ForBS-Code ::= SEQUENCE {
	ss-Code	SS-Code,
	basicService	BasicServiceCode	OPTIONAL,
	...,
	longFTN-Supported	[4]	NULL	OPTIONAL }

GenericServiceInfo ::= SEQUENCE {
	ss-Status	SS-Status,
	cliRestrictionOption	CliRestrictionOption	OPTIONAL,
	...,
	maximumEntitledPriority	[0] EMLPP-Priority	OPTIONAL,
	defaultPriority	[1] EMLPP-Priority	OPTIONAL,
	ccbs-FeatureList	[2] CCBS-FeatureList	OPTIONAL,
	nbrSB	[3] MaxMC-Bearers	OPTIONAL,
	nbrUser	[4] MC-Bearers	OPTIONAL,
	nbrSN	[5] MC-Bearers	OPTIONAL }

CCBS-FeatureList ::= SEQUENCE SIZE (1..maxNumOfCCBS-Requests) OF
	CCBS-Feature

maxNumOfCCBS-Requests  INTEGER ::= 5

CCBS-Feature ::= SEQUENCE {
	ccbs-Index	[0] CCBS-Index	OPTIONAL,
	b-subscriberNumber	[1] ISDN-AddressString	OPTIONAL,
	b-subscriberSubaddress	[2] ISDN-SubaddressString	OPTIONAL,
	basicServiceGroup	[3] BasicServiceCode	OPTIONAL,
	...}

CCBS-Index  ::= INTEGER (1..maxNumOfCCBS-Requests)

InterrogateSS-Res ::= CHOICE {
	ss-Status	[0] SS-Status,
	basicServiceGroupList	[2] BasicServiceGroupList,
	forwardingFeatureList	[3] ForwardingFeatureList,
	genericServiceInfo	[4]	GenericServiceInfo }

USSD-Arg ::= SEQUENCE {
	ussd-DataCodingScheme	USSD-DataCodingScheme,
	ussd-String	USSD-String,
	... ,
	alertingPattern	AlertingPattern	OPTIONAL,
	msisdn	[0] ISDN-AddressString	OPTIONAL }

USSD-Res ::= SEQUENCE {
	ussd-DataCodingScheme	USSD-DataCodingScheme,
	ussd-String	USSD-String,
	...}

USSD-DataCodingScheme ::= OCTET STRING (SIZE (1))
	-- The structure of the USSD-DataCodingScheme is defined by
	-- the Cell Broadcast Data Coding Scheme as described in
	-- TS 3GPP TS 23.038 [25]

USSD-String ::= OCTET STRING (SIZE (1..maxUSSD-StringLength))
	-- The structure of the contents of the USSD-String is dependent
	-- on the USSD-DataCodingScheme as described in TS 3GPP TS 23.038 [25].

maxUSSD-StringLength  INTEGER ::= 160

Password ::= NumericString
	(FROM ("0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"))
	(SIZE (4))

GuidanceInfo ::= ENUMERATED {
	enterPW  (0),
	enterNewPW  (1),
	enterNewPW-Again  (2)}
	-- How this information is really delivered to the subscriber
	-- (display, announcement, ...) is not part of this
	-- specification.

SS-List ::= SEQUENCE SIZE (1..maxNumOfSS) OF
	SS-Code

maxNumOfSS  INTEGER ::= 30

SS-InfoList ::= SEQUENCE SIZE (1..maxNumOfSS) OF
	SS-Info

BasicServiceGroupList ::= SEQUENCE SIZE (1..maxNumOfBasicServiceGroups) OF
	BasicServiceCode

maxNumOfBasicServiceGroups  INTEGER ::= 13

SS-InvocationNotificationArg ::= SEQUENCE {
	imsi	[0] IMSI,
	msisdn	[1] ISDN-AddressString,
	ss-Event	[2] SS-Code,
	-- The following SS-Code values are allowed :
	-- ect	SS-Code ::= '00110001'B
	-- multiPTY	SS-Code ::= '01010001'B
	-- cd	SS-Code ::= '00100100'B
	-- ccbs	SS-Code ::= '01000100'B
	ss-EventSpecification	[3] SS-EventSpecification	OPTIONAL,
	extensionContainer	[4] ExtensionContainer	OPTIONAL,
	...,
	b-subscriberNumber	[5]	ISDN-AddressString	OPTIONAL,
	ccbs-RequestState	[6]	CCBS-RequestState	OPTIONAL
	}

CCBS-RequestState ::= ENUMERATED {
	request 	(0),
	recall 	(1),
	active 	(2),
	completed	(3),
	suspended	(4),
	frozen	(5),
	deleted	(6)
	}

SS-InvocationNotificationRes ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...
	}

SS-EventSpecification ::= SEQUENCE SIZE (1..maxEventSpecification) OF
	AddressString

maxEventSpecification  INTEGER ::= 2

RegisterCC-EntryArg ::= SEQUENCE {
	ss-Code	[0]	SS-Code,
	ccbs-Data	[1]	CCBS-Data	OPTIONAL,
	...}

CCBS-Data ::= SEQUENCE {
	ccbs-Feature	[0]	CCBS-Feature,
	translatedB-Number	[1]	ISDN-AddressString,
	serviceIndicator	[2]	ServiceIndicator	OPTIONAL,
	callInfo	[3]	ExternalSignalInfo,
	networkSignalInfo	[4]	ExternalSignalInfo,
	...}

ServiceIndicator ::= BIT STRING {
	clir-invoked (0),
	camel-invoked (1)} (SIZE(2..32)) 
	-- exception handling:
	-- bits 2 to 31 shall be ignored if received and not understood

RegisterCC-EntryRes ::= SEQUENCE {
	ccbs-Feature	[0] CCBS-Feature	OPTIONAL,
	...}

EraseCC-EntryArg ::= SEQUENCE {
	ss-Code	[0]	SS-Code,
	ccbs-Index	[1]	CCBS-Index	OPTIONAL,
	...}

EraseCC-EntryRes ::= SEQUENCE {
	ss-Code	[0]	SS-Code,
	ss-Status	[1] SS-Status	OPTIONAL,
	...}

.#END
17.7.5	Supplementary service codes
.$MAP-SS-Code {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-SS-Code (15) version19 (19)}

DEFINITIONS

::=

BEGIN

SS-Code ::= OCTET STRING (SIZE (1))
	-- This type is used to represent the code identifying a single
	-- supplementary service, a group of supplementary services, or
	-- all supplementary services. The services and abbreviations
	-- used are defined in TS 3GPP TS 22.004 [5]. The internal structure is
	-- defined as follows:
	--
	-- bits 87654321: group (bits 8765), and specific service
	-- (bits 4321)

allSS	SS-Code ::= '00000000'B
	-- reserved for possible future use
	-- all SS

allLineIdentificationSS	SS-Code ::= '00010000'B
	-- reserved for possible future use
	-- all line identification SS
clip	SS-Code ::= '00010001'B
	-- calling line identification presentation
clir	SS-Code ::= '00010010'B
	-- calling line identification restriction
colp	SS-Code ::= '00010011'B
	-- connected line identification presentation
colr	SS-Code ::= '00010100'B
	-- connected line identification restriction
mci	SS-Code ::= '00010101'B
	-- reserved for possible future use
	-- malicious call identification

allNameIdentificationSS	SS-Code ::= '00011000'B
	-- all name identification SS
cnap	SS-Code ::= '00011001'B
	-- calling name presentation

	-- SS-Codes '00011010'B to '00011111'B are reserved for future 
	-- NameIdentification Supplementary Service use.

allForwardingSS	SS-Code ::= '00100000'B
	-- all forwarding SS
cfu	SS-Code ::= '00100001'B
	-- call forwarding unconditional
allCondForwardingSS	SS-Code ::= '00101000'B
	-- all conditional forwarding SS
cfb	SS-Code ::= '00101001'B
	-- call forwarding on mobile subscriber busy
cfnry	SS-Code ::= '00101010'B
	-- call forwarding on no reply
cfnrc	SS-Code ::= '00101011'B
	-- call forwarding on mobile subscriber not reachable 
cd	SS-Code ::= '00100100'B
	-- call deflection

allCallOfferingSS	SS-Code ::= '00110000'B
	-- reserved for possible future use
	-- all call offering SS includes also all forwarding SS
ect	SS-Code ::= '00110001'B
	-- explicit call transfer
mah	SS-Code ::= '00110010'B
	-- reserved for possible future use
	-- mobile access hunting

allCallCompletionSS	SS-Code ::= '01000000'B
	-- reserved for possible future use
	-- all Call completion SS
cw	SS-Code ::= '01000001'B
	-- call waiting
hold	SS-Code ::= '01000010'B
	-- call hold
ccbs-A	SS-Code ::= '01000011'B
	-- completion of call to busy subscribers, originating side
	-- this SS-Code is used only in InsertSubscriberData, DeleteSubscriberData 
	-- and InterrogateSS
ccbs-B	SS-Code ::= '01000100'B
	-- completion of call to busy subscribers, destination side
	-- this SS-Code is used only in InsertSubscriberData and DeleteSubscriberData
mc	SS-Code ::= '01000101'B
	-- multicall

allMultiPartySS	SS-Code ::= '01010000'B
	-- reserved for possible future use
	-- all multiparty SS
multiPTY	SS-Code ::= '01010001'B
	-- multiparty

allCommunityOfInterest-SS	SS-Code ::= '01100000'B
	-- reserved for possible future use
	-- all community of interest SS
cug	SS-Code ::= '01100001'B
	-- closed user group

allChargingSS	SS-Code ::= '01110000'B
	-- reserved for possible future use
	-- all charging SS
aoci	SS-Code ::= '01110001'B
	-- advice of charge information
aocc	SS-Code ::= '01110010'B
	-- advice of charge charging

allAdditionalInfoTransferSS	SS-Code ::= '10000000'B
	-- reserved for possible future use
	-- all additional information transfer SS
uus1	SS-Code ::= '10000001'B
	-- UUS1 user-to-user signalling 
uus2	SS-Code ::= '10000010'B
	-- UUS2 user-to-user signalling
uus3	SS-Code ::= '10000011'B
	-- UUS3 user-to-user signalling

allBarringSS	SS-Code ::= '10010000'B
	-- all barring SS
barringOfOutgoingCalls	SS-Code ::= '10010001'B
	-- barring of outgoing calls
baoc	SS-Code ::= '10010010'B
	-- barring of all outgoing calls
boic	SS-Code ::= '10010011'B
	-- barring of outgoing international calls
boicExHC	SS-Code ::= '10010100'B
	-- barring of outgoing international calls except those directed
	-- to the home PLMN Country
barringOfIncomingCalls	SS-Code ::= '10011001'B
	-- barring of incoming calls
baic	SS-Code ::= '10011010'B
	-- barring of all incoming calls
bicRoam	SS-Code ::= '10011011'B
	-- barring of incoming calls when roaming outside home PLMN
	-- Country

allPLMN-specificSS	SS-Code ::= '11110000'B
plmn-specificSS-1	SS-Code ::= '11110001'B
plmn-specificSS-2	SS-Code ::= '11110010'B
plmn-specificSS-3	SS-Code ::= '11110011'B
plmn-specificSS-4	SS-Code ::= '11110100'B
plmn-specificSS-5	SS-Code ::= '11110101'B
plmn-specificSS-6	SS-Code ::= '11110110'B
plmn-specificSS-7	SS-Code ::= '11110111'B
plmn-specificSS-8	SS-Code ::= '11111000'B
plmn-specificSS-9	SS-Code ::= '11111001'B
plmn-specificSS-A	SS-Code ::= '11111010'B
plmn-specificSS-B	SS-Code ::= '11111011'B
plmn-specificSS-C	SS-Code ::= '11111100'B
plmn-specificSS-D	SS-Code ::= '11111101'B
plmn-specificSS-E	SS-Code ::= '11111110'B
plmn-specificSS-F	SS-Code ::= '11111111'B

allCallPrioritySS	SS-Code ::= '10100000'B
	-- reserved for possible future use
	-- all call priority SS
emlpp	SS-Code ::= '10100001'B
	-- enhanced Multilevel Precedence Pre-emption (EMLPP) service

allLCSPrivacyException	SS-Code ::= '10110000'B
	-- all LCS Privacy Exception Classes
universal	SS-Code ::= '10110001'B
	-- allow location by any LCS client
callSessionRelated	SS-Code ::= '10110010'B
	-- allow location by any value added LCS client to which a call/session 
	-- is established from the target MS
callSessionUnrelated	SS-Code ::= '10110011'B
	-- allow location by designated external value added LCS clients
plmnoperator	SS-Code ::= '10110100'B
	-- allow location by designated PLMN operator LCS clients 
serviceType	SS-Code ::= '10110101'B
	-- allow location by LCS clients of a designated LCS service type

allMOLR-SS	SS-Code ::= '11000000'B
	-- all Mobile Originating Location Request Classes
basicSelfLocation	SS-Code ::= '11000001'B
	-- allow an MS to request its own location
autonomousSelfLocation	SS-Code ::= '11000010'B
	-- allow an MS to perform self location without interaction
	-- with the PLMN for a predetermined period of time
transferToThirdParty	SS-Code ::= '11000011'B
	-- allow an MS to request transfer of its location to another LCS client

.#END
17.7.6	Short message data types
.$MAP-SM-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-SM-DataTypes (16) version19 (19)}

DEFINITIONS

IMPLICIT TAGS

::=

BEGIN

EXPORTS
	RoutingInfoForSM-Arg,
	RoutingInfoForSM-Res,
	MO-ForwardSM-Arg,
	MO-ForwardSM-Res,
	MT-ForwardSM-Arg,
	MT-ForwardSM-Res,
	ReportSM-DeliveryStatusArg,
	ReportSM-DeliveryStatusRes,
	AlertServiceCentreArg,
	InformServiceCentreArg,
	ReadyForSM-Arg, 
	ReadyForSM-Res,
	SM-DeliveryOutcome,
	AlertReason,
	Additional-Number,
	MT-ForwardSM-VGCS-Arg,
	MT-ForwardSM-VGCS-Res
;

IMPORTS
	AddressString,
	ISDN-AddressString,
	SignalInfo,
	IMSI,
	LMSI,
	ASCI-CallReference,
	Time,
	NetworkNodeDiameterAddress,
	HLR-Id

FROM MAP-CommonDataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-CommonDataTypes (18) version19 (19)}

	AbsentSubscriberDiagnosticSM
FROM MAP-ER-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-ER-DataTypes (17) version19 (19)}

	ExtensionContainer
FROM MAP-ExtensionDataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version19 (19)}
;


RoutingInfoForSM-Arg ::= SEQUENCE {
	msisdn	[0] ISDN-AddressString,
	sm-RP-PRI	[1] BOOLEAN,
	serviceCentreAddress	[2] AddressString,
	extensionContainer	[6] ExtensionContainer	OPTIONAL,
	... ,
	gprsSupportIndicator	[7]	NULL	OPTIONAL,
	-- gprsSupportIndicator is set only if the SMS-GMSC supports
	-- receiving of two numbers from the HLR
	sm-RP-MTI	[8] SM-RP-MTI	OPTIONAL,
	sm-RP-SMEA	[9] SM-RP-SMEA	OPTIONAL,
	sm-deliveryNotIntended	[10] SM-DeliveryNotIntended	OPTIONAL,
	ip-sm-gwGuidanceIndicator	[11] NULL	OPTIONAL,
	imsi	[12] IMSI	OPTIONAL,
	t4-Trigger-Indicator	[14] NULL	OPTIONAL,
	singleAttemptDelivery	[13]	NULL	OPTIONAL,
	correlationID	[15] CorrelationID	OPTIONAL,
	smsf-supportIndicator	[16] NULL	OPTIONAL }

SM-DeliveryNotIntended ::= ENUMERATED {
	onlyIMSI-requested  (0),
	onlyMCC-MNC-requested  (1),
	...}

SM-RP-MTI ::= INTEGER (0..10)
	-- 0 SMS Deliver 
	-- 1 SMS Status Report
	-- other values are reserved for future use and shall be discarded if
	-- received

SM-RP-SMEA ::= OCTET STRING (SIZE (1..12))
	-- this parameter contains an address field which is encoded 
	-- as defined in 3GPP TS 23.040. An address field contains 3 elements :
	--	address-length
	--	type-of-address
	--	address-value

RoutingInfoForSM-Res ::= SEQUENCE {
	imsi	IMSI,
	locationInfoWithLMSI	[0] LocationInfoWithLMSI,
	extensionContainer	[4] ExtensionContainer	OPTIONAL,
	...,
	ip-sm-gwGuidance	[5] IP-SM-GW-Guidance	OPTIONAL }

IP-SM-GW-Guidance ::= SEQUENCE {
	minimumDeliveryTimeValue	SM-DeliveryTimerValue,
	recommendedDeliveryTimeValue	SM-DeliveryTimerValue,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

LocationInfoWithLMSI ::= SEQUENCE {
	networkNode-Number	[1] ISDN-AddressString,
	lmsi	LMSI	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	gprsNodeIndicator	[5]	NULL	OPTIONAL,
	-- gprsNodeIndicator is set only if the SGSN number is sent as the 
	-- Network Node Number
	additional-Number	[6] Additional-Number	OPTIONAL,
	networkNodeDiameterAddress	[7] NetworkNodeDiameterAddress	OPTIONAL,
	additionalNetworkNodeDiameterAddress	[8] NetworkNodeDiameterAddress	OPTIONAL,
	thirdNumber	[9] Additional-Number	OPTIONAL,
	thirdNetworkNodeDiameterAddress	[10] NetworkNodeDiameterAddress	OPTIONAL,
	imsNodeIndicator	[11] NULL	OPTIONAL, 
	-- gprsNodeIndicator and imsNodeIndicator shall not both be present.
	-- additionalNumber and thirdNumber shall not both contain the same type of number. 
	smsf-3gpp-Number	[12]	ISDN-AddressString	OPTIONAL,
	smsf-3gpp-DiameterAddress	[13]	NetworkNodeDiameterAddress	OPTIONAL,
	smsf-non-3gpp-Number	[14]	ISDN-AddressString	OPTIONAL,
	smsf-non-3gpp-DiameterAddress	[15]	NetworkNodeDiameterAddress	OPTIONAL,
	smsf-3gpp-address-indicator	[16]	NULL	OPTIONAL,
	smsf-non-3gpp-address-indicator	[17]	NULL	OPTIONAL
	--
	-- If smsf-supportIndicator was not included in the request, in RoutingInfoForSM-Arg, 
	-- then smsf-3gpp Number/DiameterAddress, smsf-non-3gpp Number/DiameterAddress and
	-- smsf-address-indicator and smsf-non-3gpp-address-indicator shall be absent.
	--
	-- If smsf-3gpp-address-indicator is present, it indicates that the networkNode-Number
	-- (and networkNodeDiameterAddress, if present) contains the address of an SMSF for
	-- 3GPP access.
	--
	-- If smsf-non-3gpp-address-indicator is present, it indicates that the
	-- networkNode-Number (and networkNodeDiameterAddress, if present) contains the
	-- address of an SMSF for non 3GPP access.
	--
	-- At most one of gprsNodeIndicator, imsNodeIndicator, smsf-3gpp-address-indicator
	-- and smsf-non-3gpp-address-indicator shall be present. Absence of all these
	-- indicators indicate that the networkNode-Number (and networkNodeDiameterAddress,
	-- if present) contains the address of an MSC/MME.

	}

Additional-Number ::= CHOICE {
	msc-Number	[0] ISDN-AddressString,
	sgsn-Number	[1] ISDN-AddressString}
	-- msc-number can be the MSC number or 
	-- the SMS Router number or the MME number for MT SMS
	-- sgsn-number can be the SGSN number or the SMS Router number 

MO-ForwardSM-Arg ::= SEQUENCE {
	sm-RP-DA	SM-RP-DA,
	sm-RP-OA	SM-RP-OA,
	sm-RP-UI	SignalInfo,
	extensionContainer	ExtensionContainer	OPTIONAL,
	... ,
	imsi	IMSI	OPTIONAL,
	correlationID	[0] CorrelationID	OPTIONAL,
	sm-DeliveryOutcome	[1] SM-DeliveryOutcome	OPTIONAL
 }

MO-ForwardSM-Res ::= SEQUENCE {
	sm-RP-UI	SignalInfo	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

MT-ForwardSM-Arg ::= SEQUENCE {
	sm-RP-DA	SM-RP-DA,
	sm-RP-OA	SM-RP-OA,
	sm-RP-UI	SignalInfo,
	moreMessagesToSend	NULL	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	smDeliveryTimer	SM-DeliveryTimerValue	OPTIONAL,
	smDeliveryStartTime	Time	OPTIONAL,
	smsOverIP-OnlyIndicator	[0] NULL	OPTIONAL,
	correlationID	[1] CorrelationID	OPTIONAL,
	maximumRetransmissionTime	[2] Time	OPTIONAL,
	smsGmscAddress	[3] ISDN-AddressString	OPTIONAL,
	smsGmscDiameterAddress	[4] NetworkNodeDiameterAddress	OPTIONAL }
	-- SM-DeliveryTimerValue contains the value used by the SMS-GMSC

CorrelationID ::= SEQUENCE {
	hlr-id	[0] HLR-Id	OPTIONAL,
	sip-uri-A	[1] SIP-URI	OPTIONAL,
	sip-uri-B	[2] SIP-URI}

SIP-URI ::= OCTET STRING 
-- octets are coded as defined in IETF RFC 3261 

MT-ForwardSM-Res ::= SEQUENCE {
	sm-RP-UI	SignalInfo	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	... }

SM-RP-DA ::= CHOICE {
	imsi	[0] IMSI,
	lmsi	[1] LMSI,
	serviceCentreAddressDA	[4] AddressString,
	noSM-RP-DA	[5] NULL}

SM-RP-OA ::= CHOICE {
	msisdn	[2] ISDN-AddressString,
	serviceCentreAddressOA	[4] AddressString,
	noSM-RP-OA	[5] NULL}

SM-DeliveryTimerValue ::= INTEGER (30..600)

ReportSM-DeliveryStatusArg ::= SEQUENCE {
	msisdn	ISDN-AddressString,
	serviceCentreAddress	AddressString,
	sm-DeliveryOutcome	SM-DeliveryOutcome,
	absentSubscriberDiagnosticSM	[0] AbsentSubscriberDiagnosticSM
		OPTIONAL,
	extensionContainer	[1] ExtensionContainer	OPTIONAL,
	...,
	gprsSupportIndicator	[2]	NULL	OPTIONAL,
	-- gprsSupportIndicator is set only if the SMS-GMSC supports 
	-- handling of two delivery outcomes
	deliveryOutcomeIndicator	[3]	NULL	OPTIONAL,
	-- DeliveryOutcomeIndicator is set when the SM-DeliveryOutcome
	-- is for GPRS
	additionalSM-DeliveryOutcome	[4]	SM-DeliveryOutcome	OPTIONAL,
	-- If received, additionalSM-DeliveryOutcome is for GPRS
	-- If DeliveryOutcomeIndicator is set, then AdditionalSM-DeliveryOutcome shall be absent
	additionalAbsentSubscriberDiagnosticSM	[5]	AbsentSubscriberDiagnosticSM OPTIONAL,
	-- If received additionalAbsentSubscriberDiagnosticSM is for GPRS
	-- If DeliveryOutcomeIndicator is set, then AdditionalAbsentSubscriberDiagnosticSM 
	-- shall be absent
	ip-sm-gw-Indicator	[6]	NULL	OPTIONAL,
	-- the ip-sm-gw indicator indicates by its presence that sm-deliveryOutcome
	-- is for delivery via IMS
	-- If present, deliveryOutcomeIndicator shall be absent.
	ip-sm-gw-sm-deliveryOutcome	[7]	SM-DeliveryOutcome	OPTIONAL, 
	-- If received ip-sm-gw-sm-deliveryOutcome is for delivery via IMS
	-- If ip-sm-gw-Indicator is set, then ip-sm-gw-sm-deliveryOutcome shall be absent
	ip-sm-gw-absentSubscriberDiagnosticSM	[8]	AbsentSubscriberDiagnosticSM	OPTIONAL,
	-- If received ip-sm-gw-sm-absentSubscriberDiagnosticSM is for delivery via IMS
	-- If ip-sm-gw-Indicator is set, then ip-sm-gw-sm-absentSubscriberDiagnosticSM 
	-- shall be absent
	imsi	[9] IMSI	OPTIONAL,
	singleAttemptDelivery	[10] NULL	OPTIONAL,
	correlationID	[11]	CorrelationID	OPTIONAL,
	smsf-3gpp-deliveryOutcomeIndicator	[12]	NULL	OPTIONAL,
	-- smsf-3gpp-deliveryOutcome is set when the SM-DeliveryOutcome
	-- is for 3GPP-SMSF
	smsf-3gpp-deliveryOutcome	[13]	SM-DeliveryOutcome	OPTIONAL,
	-- If smsf-3gpp-deliveryOutcomeIndicator is set, then smsf-3gpp-deliveryOutcome
	-- shall be absent
	smsf-3gpp-absentSubscriberDiagSM	[14]	AbsentSubscriberDiagnosticSM	OPTIONAL,
	-- If smsf-3gpp-deliveryOutcomeIndicator is set, then
	-- smsf-3gpp-absentSubscriberDiagSM shall be absent
	smsf-non-3gpp-deliveryOutcomeIndicator	[15]	NULL	OPTIONAL,
	-- smsf-non-3gpp-deliveryOutcomeIndicator is set when the SM-DeliveryOutcome
	-- is for non-3GPP-SMSF
	smsf-non-3gpp-deliveryOutcome	[16]	SM-DeliveryOutcome	OPTIONAL,
	-- If smsf-non-3gpp-deliveryOutcomeIndicator is set, then smsf-non-3gpp-deliveryOutcome
	-- shall be absent
	smsf-non-3gpp-absentSubscriberDiagSM	[17]	AbsentSubscriberDiagnosticSM	OPTIONAL
	-- If smsf-non-3gpp-deliveryOutcomeIndicator is set, then
	-- smsf-non-3gpp-absentSubscriberDiagSM shall be absent

}

SM-DeliveryOutcome ::= ENUMERATED {
	memoryCapacityExceeded  (0),
	absentSubscriber  (1),
	successfulTransfer  (2)}

ReportSM-DeliveryStatusRes ::= SEQUENCE {
	storedMSISDN	ISDN-AddressString	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

AlertServiceCentreArg ::= SEQUENCE {
	msisdn	ISDN-AddressString,
	serviceCentreAddress	AddressString,
	...,
	imsi	IMSI	OPTIONAL,
	correlationID	CorrelationID	OPTIONAL,
	maximumUeAvailabilityTime	[0] Time	OPTIONAL,
	smsGmscAlertEvent	[1] SmsGmsc-Alert-Event	OPTIONAL,
	smsGmscDiameterAddress	[2] NetworkNodeDiameterAddress	OPTIONAL,
	newSGSNNumber	[3] ISDN-AddressString	OPTIONAL,
	newSGSNDiameterAddress	[4] NetworkNodeDiameterAddress	OPTIONAL,
	newMMENumber	[5] ISDN-AddressString	OPTIONAL,
	newMMEDiameterAddress	[6] NetworkNodeDiameterAddress	OPTIONAL,
	newMSCNumber	[7] ISDN-AddressString	OPTIONAL }

SmsGmsc-Alert-Event ::= ENUMERATED {
	msAvailableForMtSms  (0),
	msUnderNewServingNode  (1)  }

InformServiceCentreArg ::= SEQUENCE {
	storedMSISDN	ISDN-AddressString	OPTIONAL,
	mw-Status	MW-Status	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	... ,
	absentSubscriberDiagnosticSM	AbsentSubscriberDiagnosticSM	OPTIONAL,
	additionalAbsentSubscriberDiagnosticSM	[0]	AbsentSubscriberDiagnosticSM	OPTIONAL,
	-- additionalAbsentSubscriberDiagnosticSM may be present only if 
	-- absentSubscriberDiagnosticSM is present.
	-- if included, additionalAbsentSubscriberDiagnosticSM is for GPRS and
	-- absentSubscriberDiagnosticSM is for non-GPRS
	smsf3gppAbsentSubscriberDiagnosticSM	[1] AbsentSubscriberDiagnosticSM	OPTIONAL,
	smsfNon3gppAbsentSubscriberDiagnosticSM	[2] AbsentSubscriberDiagnosticSM	OPTIONAL }

MW-Status ::= BIT STRING {
	sc-AddressNotIncluded  (0),
	mnrf-Set  (1),
	mcef-Set  (2) ,
	mnrg-Set	(3),
	mnr5g-Set (4),
	mnr5gn3g-Set (5)} (SIZE (6..16))
	-- exception handling:
	-- bits 6 to 15 shall be ignored if received and not understood

ReadyForSM-Arg ::= SEQUENCE {
	imsi	[0] IMSI,
	alertReason	AlertReason,
	alertReasonIndicator	NULL	OPTIONAL,
	-- alertReasonIndicator is set only when the alertReason 
	-- sent to HLR is for GPRS
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	additionalAlertReasonIndicator	[1] NULL	OPTIONAL,
	-- additionalAlertReasonIndicator is set only when the alertReason
	-- sent to HLR is for IP-SM-GW
	maximumUeAvailabilityTime	Time	OPTIONAL }

ReadyForSM-Res ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

AlertReason ::= ENUMERATED {
	ms-Present  (0),
	memoryAvailable  (1)}

MT-ForwardSM-VGCS-Arg ::= SEQUENCE {
	asciCallReference	ASCI-CallReference,
	sm-RP-OA	SM-RP-OA,
	sm-RP-UI	SignalInfo,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

MT-ForwardSM-VGCS-Res ::= SEQUENCE {
	sm-RP-UI	[0] SignalInfo	OPTIONAL,
	dispatcherList	[1] DispatcherList	OPTIONAL,
	ongoingCall	NULL	OPTIONAL,
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	...,
	additionalDispatcherList	[3] AdditionalDispatcherList	OPTIONAL }
	-- additionalDispatcherList shall be absent if dispatcherList is absent or 
	-- contains less than 5 ISDN-AddressStrings

DispatcherList ::= 
	SEQUENCE SIZE (1..maxNumOfDispatchers) OF
	ISDN-AddressString

maxNumOfDispatchers  INTEGER ::= 5

AdditionalDispatcherList ::= 
	SEQUENCE SIZE (1..maxNumOfAdditionalDispatchers) OF
	ISDN-AddressString

maxNumOfAdditionalDispatchers  INTEGER ::= 15


.#END
17.7.7	Error data types
.$MAP-ER-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-ER-DataTypes (17) version19 (19)}

DEFINITIONS

IMPLICIT TAGS

::=

BEGIN

EXPORTS
	RoamingNotAllowedParam,
	CallBarredParam,
	CUG-RejectParam,
	SS-IncompatibilityCause,
	PW-RegistrationFailureCause,
	SM-DeliveryFailureCause,
	SystemFailureParam,
	DataMissingParam,
	UnexpectedDataParam,
	FacilityNotSupParam,
	OR-NotAllowedParam,
	UnknownSubscriberParam,
	NumberChangedParam,
	UnidentifiedSubParam,
	IllegalSubscriberParam,
	IllegalEquipmentParam,
	BearerServNotProvParam,
	TeleservNotProvParam,
	TracingBufferFullParam,
	NoRoamingNbParam,
	AbsentSubscriberParam,
	BusySubscriberParam,
	NoSubscriberReplyParam,
	ForwardingViolationParam,
	ForwardingFailedParam, 
	ATI-NotAllowedParam,
	SubBusyForMT-SMS-Param,
	MessageWaitListFullParam,
	AbsentSubscriberSM-Param,
	AbsentSubscriberDiagnosticSM,
	ResourceLimitationParam,
	NoGroupCallNbParam,
	IncompatibleTerminalParam,
	ShortTermDenialParam,
	LongTermDenialParam,
	UnauthorizedRequestingNetwork-Param,
	UnauthorizedLCSClient-Param,
	PositionMethodFailure-Param,
UnknownOrUnreachableLCSClient-Param,
	MM-EventNotSupported-Param,
ATSI-NotAllowedParam,
ATM-NotAllowedParam,
IllegalSS-OperationParam,
SS-NotAvailableParam,
SS-SubscriptionViolationParam,
InformationNotAvailableParam,
TargetCellOutsideGCA-Param,
OngoingGroupCallParam,
PositionMethodFailure-Diagnostic,
UnauthorizedLCSClient-Diagnostic

;

IMPORTS
	SS-Status
FROM MAP-SS-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-SS-DataTypes (14) version19 (19)}

	SignalInfo,
	BasicServiceCode,
	NetworkResource,
	AdditionalNetworkResource,
	IMSI,
	Time
FROM MAP-CommonDataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-CommonDataTypes (18) version19 (19)}


	SS-Code
FROM MAP-SS-Code {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-SS-Code (15) version19 (19)}

	ExtensionContainer
FROM MAP-ExtensionDataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version19 (19)}
;

RoamingNotAllowedParam ::= SEQUENCE {
	roamingNotAllowedCause	RoamingNotAllowedCause,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	additionalRoamingNotAllowedCause	[0] AdditionalRoamingNotAllowedCause OPTIONAL }

--	if the additionalRoamingNotallowedCause is received by the MSC/VLR or SGSN then the 
--	roamingNotAllowedCause shall be discarded.

AdditionalRoamingNotAllowedCause ::= ENUMERATED {
	supportedRAT-TypesNotAllowed (0),
	...}

RoamingNotAllowedCause ::= ENUMERATED {
	plmnRoamingNotAllowed  (0),
	operatorDeterminedBarring  (3)}

CallBarredParam ::= CHOICE {
	callBarringCause	CallBarringCause,
	-- call BarringCause must not be used in version 3 and higher
	extensibleCallBarredParam	ExtensibleCallBarredParam
	-- extensibleCallBarredParam must not be used in version <3
	}

CallBarringCause ::= ENUMERATED {
	barringServiceActive  (0),
	operatorBarring  (1)}

ExtensibleCallBarredParam ::= SEQUENCE {
	callBarringCause	CallBarringCause	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	... ,
	unauthorisedMessageOriginator	[1] NULL	OPTIONAL,
	anonymousCallRejection	[2] NULL	OPTIONAL }

-- unauthorisedMessageOriginator and anonymousCallRejection shall be mutually exclusive. 


CUG-RejectParam ::= SEQUENCE {
	cug-RejectCause	CUG-RejectCause	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

CUG-RejectCause ::= ENUMERATED {
	incomingCallsBarredWithinCUG  (0),
	subscriberNotMemberOfCUG  (1),
	requestedBasicServiceViolatesCUG-Constraints  (5),
	calledPartySS-InteractionViolation  (7)}

SS-IncompatibilityCause ::= SEQUENCE {
	ss-Code	[1] SS-Code	OPTIONAL,
	basicService	BasicServiceCode	OPTIONAL,
	ss-Status	[4] SS-Status	OPTIONAL,
	...}

PW-RegistrationFailureCause ::= ENUMERATED {
	undetermined  (0),
	invalidFormat  (1),
	newPasswordsMismatch  (2)}

SM-EnumeratedDeliveryFailureCause ::= ENUMERATED {
	memoryCapacityExceeded  (0),
	equipmentProtocolError  (1),
	equipmentNotSM-Equipped  (2),
	unknownServiceCentre  (3),
	sc-Congestion  (4),
	invalidSME-Address  (5),
	subscriberNotSC-Subscriber  (6)}

SM-DeliveryFailureCause ::= SEQUENCE {
	sm-EnumeratedDeliveryFailureCause	SM-EnumeratedDeliveryFailureCause,
	diagnosticInfo	SignalInfo	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

AbsentSubscriberSM-Param ::= SEQUENCE {
	absentSubscriberDiagnosticSM	AbsentSubscriberDiagnosticSM	OPTIONAL,
	-- AbsentSubscriberDiagnosticSM can be either for non-GPRS 
	-- or for GPRS
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	additionalAbsentSubscriberDiagnosticSM 	[0]	AbsentSubscriberDiagnosticSM	OPTIONAL,
	-- if received, additionalAbsentSubscriberDiagnosticSM 
	-- is for GPRS and absentSubscriberDiagnosticSM is 
	-- for non-GPRS
	imsi	[1] IMSI	OPTIONAL,
	-- when sent from HLR to IP-SM-GW, IMSI shall be present if UNRI is not set 
	-- to indicate that the absent condition is met for CS and PS but not for IMS. 
	requestedRetransmissionTime	[2] Time	OPTIONAL,
	userIdentifierAlert	[3] IMSI	OPTIONAL }

AbsentSubscriberDiagnosticSM ::= INTEGER (0..255)
	-- AbsentSubscriberDiagnosticSM values are defined in 3GPP TS 23.040

SystemFailureParam ::= CHOICE {
	networkResource	NetworkResource,
	-- networkResource must not be used in version 3
	extensibleSystemFailureParam	ExtensibleSystemFailureParam
	-- extensibleSystemFailureParam must not be used in version <3
	}

ExtensibleSystemFailureParam ::= SEQUENCE {
	networkResource	NetworkResource	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	additionalNetworkResource	[0] AdditionalNetworkResource	OPTIONAL,
	failureCauseParam	[1] FailureCauseParam	OPTIONAL }

FailureCauseParam ::= ENUMERATED {
	limitReachedOnNumberOfConcurrentLocationRequests (0),
	... }
	-- if unknown value is received in FailureCauseParam it shall be ignored


DataMissingParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

UnexpectedDataParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	unexpectedSubscriber [0]	NULL	OPTIONAL}
-- the unexpectedSubscriber indication in the unexpectedDataValue error shall not be used
-- for operations that allow the unidentifiedSubscriber error.

FacilityNotSupParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	shapeOfLocationEstimateNotSupported [0]	NULL	OPTIONAL,
	neededLcsCapabilityNotSupportedInServingNode [1] NULL	OPTIONAL }

OR-NotAllowedParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

UnknownSubscriberParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	unknownSubscriberDiagnostic	UnknownSubscriberDiagnostic	OPTIONAL}

UnknownSubscriberDiagnostic ::= ENUMERATED {
	imsiUnknown  (0),
	gprs-eps-SubscriptionUnknown  (1),
	...,
	npdbMismatch  (2)}
	-- if unknown values are received in	
	-- UnknownSubscriberDiagnostic they shall be discarded

NumberChangedParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

UnidentifiedSubParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

IllegalSubscriberParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

IllegalEquipmentParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

BearerServNotProvParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

TeleservNotProvParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

TracingBufferFullParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

NoRoamingNbParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

AbsentSubscriberParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	absentSubscriberReason	[0] AbsentSubscriberReason	OPTIONAL}

AbsentSubscriberReason ::= ENUMERATED {
	imsiDetach (0),
	restrictedArea (1),
	noPageResponse (2),
	... ,
	purgedMS (3),
	mtRoamingRetry (4),
	busySubscriber (5)}
-- exception handling: at reception of other values than the ones listed the 
-- AbsentSubscriberReason shall be ignored. 
-- The AbsentSubscriberReason: purgedMS is defined for the Super-Charger feature 
-- (see TS 23.116). If this value is received in a Provide Roaming Number response
-- it shall be mapped to the AbsentSubscriberReason: imsiDetach in the Send Routeing
-- Information response
-- The AbsentSubscriberReason: mtRoamingRetry is used during MT Roaming Retry, 
-- see 3GPP TS 23.018[97].
-- The AbsentSubscriberReason: busySubscriber is used during MT Roaming Forwarding, 
-- see 3GPP TS 23.018[97].

BusySubscriberParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	ccbs-Possible	[0] NULL	OPTIONAL,
	ccbs-Busy	[1] NULL	OPTIONAL}

NoSubscriberReplyParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

ForwardingViolationParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

ForwardingFailedParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

ATI-NotAllowedParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

ATSI-NotAllowedParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

ATM-NotAllowedParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

IllegalSS-OperationParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

SS-NotAvailableParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

SS-SubscriptionViolationParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

InformationNotAvailableParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

SubBusyForMT-SMS-Param ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	... ,
	gprsConnectionSuspended	NULL	OPTIONAL }
	-- If GprsConnectionSuspended is not understood it shall 
	-- be discarded

MessageWaitListFullParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

ResourceLimitationParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

NoGroupCallNbParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

IncompatibleTerminalParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

ShortTermDenialParam ::= SEQUENCE {
	...}

LongTermDenialParam ::= SEQUENCE {
	...}

UnauthorizedRequestingNetwork-Param ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

UnauthorizedLCSClient-Param ::= SEQUENCE {
	unauthorizedLCSClient-Diagnostic	[0] UnauthorizedLCSClient-Diagnostic	OPTIONAL,
	extensionContainer	[1] ExtensionContainer	OPTIONAL,
	... }

UnauthorizedLCSClient-Diagnostic ::= ENUMERATED {
	noAdditionalInformation (0),
	clientNotInMSPrivacyExceptionList (1),
	callToClientNotSetup (2),
	privacyOverrideNotApplicable (3),
	disallowedByLocalRegulatoryRequirements (4),
	...,
	unauthorizedPrivacyClass (5),
	unauthorizedCallSessionUnrelatedExternalClient (6),
	unauthorizedCallSessionRelatedExternalClient (7) }
--	exception handling:
--	any unrecognized value shall be ignored

PositionMethodFailure-Param ::= SEQUENCE {
	positionMethodFailure-Diagnostic	[0] PositionMethodFailure-Diagnostic	OPTIONAL,
	extensionContainer	[1] ExtensionContainer	OPTIONAL,
	... }

PositionMethodFailure-Diagnostic ::= ENUMERATED {
	congestion  (0),
	insufficientResources  (1),
	insufficientMeasurementData  (2),
	inconsistentMeasurementData  (3),
	locationProcedureNotCompleted  (4),
	locationProcedureNotSupportedByTargetMS  (5),
	qoSNotAttainable  (6),
	positionMethodNotAvailableInNetwork	(7),
	positionMethodNotAvailableInLocationArea	(8),
	... }
--	exception handling:
--	any unrecognized value shall be ignored

UnknownOrUnreachableLCSClient-Param ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

MM-EventNotSupported-Param ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

TargetCellOutsideGCA-Param ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

OngoingGroupCallParam ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}


.#END
17.7.8	Common data types
.$MAP-CommonDataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-CommonDataTypes (18) version19 (19)}

DEFINITIONS

IMPLICIT TAGS

::=

BEGIN

EXPORTS

	-- general data types and values
	AddressString,
	ISDN-AddressString,
	maxISDN-AddressLength,
	FTN-AddressString,
	ISDN-SubaddressString,
	ExternalSignalInfo, 
	Ext-ExternalSignalInfo, 
AccessNetworkSignalInfo,
	SignalInfo,
	maxSignalInfoLength,
	AlertingPattern,
	TBCD-STRING,
	DiameterIdentity,
	Time,
	HLR-Id,

	-- data types for numbering and identification
	IMSI,
	TMSI, 
	Identity,
	SubscriberId,
	IMEI,
	HLR-List,
	LMSI,
	GlobalCellId,
	NetworkResource,
	AdditionalNetworkResource,
	NAEA-PreferredCI, 
	NAEA-CIC, 
	ASCI-CallReference,
	SubscriberIdentity,
	PLMN-Id,
	E-UTRAN-CGI,
	NR-CGI,
	TA-Id, 
	NR-TA-Id,
	RAIdentity,
	NetworkNodeDiameterAddress,

	-- data types for CAMEL
	CellGlobalIdOrServiceAreaIdOrLAI, 
	CellGlobalIdOrServiceAreaIdFixedLength,
	LAIFixedLength,

	-- data types for subscriber management
	BasicServiceCode,
	Ext-BasicServiceCode,
	EMLPP-Info,
	EMLPP-Priority, 
	MC-SS-Info,
	MaxMC-Bearers,
	MC-Bearers,
	Ext-SS-Status,

	-- data types for geographic location
	AgeOfLocationInformation,
	LCSClientExternalID,
	LCSClientInternalID,
	LCSServiceTypeID,

	-- gprs location registration types
	GSN-Address

;

IMPORTS
	TeleserviceCode,
	Ext-TeleserviceCode
FROM MAP-TS-Code {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-TS-Code (19) version19 (19)}

	BearerServiceCode,
	Ext-BearerServiceCode
FROM MAP-BS-Code {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-BS-Code (20) version19 (19)}

	SS-Code
FROM MAP-SS-Code {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-SS-Code (15) version19 (19)}

	ExtensionContainer
FROM MAP-ExtensionDataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version19 (19)}
;


-- general data types

TBCD-STRING ::= OCTET STRING
	-- This type (Telephony Binary Coded Decimal String) is used to
	-- represent several digits from 0 through 9, *, #, a, b, c, two
	-- digits per octet, each digit encoded 0000 to 1001 (0 to 9),
	-- 1010 (*), 1011 (#), 1100 (a), 1101 (b) or 1110 (c); 1111 used
	-- as filler when there is an odd number of digits.

	-- bits 8765 of octet n encoding digit 2n
	-- bits 4321 of octet n encoding digit 2(n-1) +1

DiameterIdentity ::= OCTET STRING (SIZE(9..255))
-- content of DiameterIdentity is defined in IETF RFC 3588 [139]

AddressString ::= OCTET STRING (SIZE (1..maxAddressLength))
	-- This type is used to represent a number for addressing
	-- purposes. It is composed of
	--	a)	one octet for nature of address, and numbering plan
	--	indicator.
	--	b)	digits of an address encoded as TBCD-String.

	-- a)	The first octet includes a one bit extension indicator, a
	--	3 bits nature of address indicator and a 4 bits numbering
	--	plan indicator, encoded as follows:

	-- bit 8: 1  (no extension)

	-- bits 765: nature of address indicator
	--	000  unknown
	--	001  international number
	--	010  national significant number
	--	011  network specific number
	--	100  subscriber number
	--	101  reserved
	--	110  abbreviated number
	--	111  reserved for extension

	-- bits 4321: numbering plan indicator
	--	0000  unknown
	--	0001  ISDN/Telephony Numbering Plan (Rec ITU-T E.164)
	--	0010  spare
	--	0011  data numbering plan (ITU-T Rec X.121)
	--	0100  telex numbering plan (ITU-T Rec F.69)
	--	0101  spare
	--	0110  land mobile numbering plan (ITU-T Rec E.212)
	--	0111  spare
	--	1000  national numbering plan
	--	1001  private numbering plan
	--	1111  reserved for extension

	--	all other values are reserved.

	-- b)	The following octets representing digits of an address
	--	encoded as a TBCD-STRING.

maxAddressLength  INTEGER ::= 20

ISDN-AddressString ::= 
	AddressString (SIZE (1..maxISDN-AddressLength))
	-- This type is used to represent ISDN numbers.

maxISDN-AddressLength  INTEGER ::= 9

FTN-AddressString ::= 
	AddressString (SIZE (1..maxFTN-AddressLength))
	-- This type is used to represent forwarded-to numbers. 
	-- If NAI = international the first digits represent the country code (CC)
	-- and the network destination code (NDC) as for E.164.

maxFTN-AddressLength  INTEGER ::= 15

ISDN-SubaddressString ::= 
	OCTET STRING (SIZE (1..maxISDN-SubaddressLength))
	-- This type is used to represent ISDN subaddresses.
	-- It is composed of
	--	a)	one octet for type of subaddress and odd/even indicator.
	--	b)	20 octets for subaddress information.

	--	a)	The first octet includes a one bit extension indicator, a
	--	3 bits type of subaddress and a one bit odd/even indicator,
	--	encoded as follows:

	--	bit 8: 1  (no extension)

	--	bits 765: type of subaddress
	--	000  NSAP (X.213/ISO 8348 AD2)
	--	010  User Specified
	--	All other values are reserved

	--	bit 4: odd/even indicator
	--	0  even number of address signals
	--	1  odd number of address signals
	--	The odd/even indicator is used when the type of subaddress
	--	is "user specified" and the coding is BCD.

	--	bits 321: 000 (unused)

	--	b) Subaddress information.
	--	The NSAP X.213/ISO8348AD2 address shall be formatted as specified
	--	by octet 4 which contains the Authority and Format Identifier
	--	(AFI). The encoding is made according to the "preferred binary
	--	encoding" as defined in X.213/ISO834AD2. For the definition
	--	of this type of subaddress, see ITU-T Rec I.334.

	--	For User-specific subaddress, this field is encoded according
	--	to the user specification, subject to a maximum length of 20
	--	octets. When interworking with X.25 networks BCD coding should
	--	be applied.

maxISDN-SubaddressLength  INTEGER ::= 21

ExternalSignalInfo ::= SEQUENCE {
	protocolId	ProtocolId,
	signalInfo	SignalInfo,
	-- Information about the internal structure is given in
	-- clause 7.6.9.
	extensionContainer	ExtensionContainer	OPTIONAL,
	-- extensionContainer must not be used in version 2
	...}

SignalInfo ::= OCTET STRING (SIZE (1..maxSignalInfoLength))

maxSignalInfoLength  INTEGER ::= 200
	-- This NamedValue represents the theoretical maximum number of octets which is
	-- available to carry a single instance of the SignalInfo data type,
	-- without requiring segmentation to cope with the network layer service.
	-- However, the actual maximum size available for an instance of the data
	-- type may be lower, especially when other information elements
	-- have to be included in the same component.

ProtocolId ::= ENUMERATED {
	gsm-0408  (1),
	gsm-0806  (2),
	gsm-BSSMAP  (3),
	-- Value 3 is reserved and must not be used
	ets-300102-1  (4)}

Ext-ExternalSignalInfo ::= SEQUENCE {
	ext-ProtocolId	Ext-ProtocolId,
	signalInfo	SignalInfo,
	-- Information about the internal structure is given in
	-- clause 7.6.9.10
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

Ext-ProtocolId ::= ENUMERATED {
	ets-300356  (1),
	... 
	}
-- exception handling:
-- For Ext-ExternalSignalInfo sequences containing this parameter with any
-- other value than the ones listed the receiver shall ignore the whole 
-- Ext-ExternalSignalInfo sequence.

AccessNetworkSignalInfo ::= SEQUENCE {
	accessNetworkProtocolId	AccessNetworkProtocolId,
	signalInfo	LongSignalInfo,
	-- Information about the internal structure is given in clause 7.6.9.1
	
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

LongSignalInfo ::= OCTET STRING (SIZE (1..maxLongSignalInfoLength))

maxLongSignalInfoLength  INTEGER ::= 2560
	-- This Named Value represents the maximum number of octets which is available
	-- to carry a single instance of the LongSignalInfo data type using
	-- White Book SCCP with the maximum number of segments.
	-- It takes account of the octets used by the lower layers of the protocol, and
	-- other information elements which may be included in the same component.

AccessNetworkProtocolId ::= ENUMERATED {
	ts3G-48006   (1),
	ts3G-25413 (2),
	...}
	-- exception handling:
	-- For AccessNetworkSignalInfo sequences containing this parameter with any
	-- other value than the ones listed the receiver shall ignore the whole 
	-- AccessNetworkSignalInfo sequence.

AlertingPattern ::= OCTET STRING (SIZE (1) )
	-- This type is used to represent Alerting Pattern

	--	bits 8765 : 0000 (unused)

	--	bits 43 : type of Pattern
	--	00 level
	--	01 category
	--	10 category
	--	all other values are reserved.

	--	bits 21 : type of alerting

alertingLevel-0   AlertingPattern ::= '00000000'B
alertingLevel-1   AlertingPattern ::= '00000001'B
alertingLevel-2   AlertingPattern ::= '00000010'B
	-- all other values of Alerting level are reserved
	-- Alerting Levels are defined in GSM 02.07
	
alertingCategory-1   AlertingPattern ::= '00000100'B
alertingCategory-2   AlertingPattern ::= '00000101'B
alertingCategory-3   AlertingPattern ::= '00000110'B
alertingCategory-4   AlertingPattern ::= '00000111'B
alertingCategory-5   AlertingPattern ::= '00001000'B
	-- all other values of Alerting Category are reserved
	-- Alerting categories are defined in GSM 02.07

GSN-Address ::= OCTET STRING (SIZE (5..17))
	-- Octets are coded according to TS 3GPP TS 23.003 [17]

Time ::= OCTET STRING (SIZE (4))
	-- Octets are coded according to IETF RFC 3588 [139]


-- data types for numbering and identification

IMSI ::= TBCD-STRING (SIZE (3..8))
	-- digits of MCC, MNC, MSIN are concatenated in this order.

Identity ::= CHOICE {
	imsi	IMSI,
	imsi-WithLMSI	IMSI-WithLMSI}

IMSI-WithLMSI ::= SEQUENCE {
	imsi	IMSI,
	lmsi	LMSI,
	-- a special value 00000000 indicates that the LMSI is not in use
	...}

ASCI-CallReference ::= TBCD-STRING (SIZE (1..8))
	-- digits of VGCS/VBS-area,Group-ID are concatenated in this order if there is a
	-- VGCS/VBS-area.

TMSI ::= OCTET STRING (SIZE (1..4))

SubscriberId ::= CHOICE {
	imsi	[0] IMSI,
	tmsi	[1] TMSI}

IMEI ::= TBCD-STRING (SIZE (8))
	--	Refers to International Mobile Station Equipment Identity
	--	and Software Version Number (SVN) defined in TS 3GPP TS 23.003 [17].
	--	If the SVN is not present the last octet shall contain the
	--	digit 0 and a filler.
	--	If present the SVN shall be included in the last octet.

HLR-Id ::= IMSI
	-- leading digits of IMSI, i.e. (MCC, MNC, leading digits of
	-- MSIN) forming HLR Id defined in TS 3GPP TS 23.003 [17].

HLR-List ::= SEQUENCE SIZE (1..maxNumOfHLR-Id) OF
	HLR-Id

maxNumOfHLR-Id  INTEGER ::= 50

LMSI ::= OCTET STRING (SIZE (4))

GlobalCellId ::= OCTET STRING (SIZE (5..7))
	-- Refers to Cell Global Identification defined in TS 3GPP TS 23.003 [17].
	-- The internal structure is defined as follows:
	-- octet 1 bits 4321	Mobile Country Code 1st digit
	--         bits 8765	Mobile Country Code 2nd digit
	-- octet 2 bits 4321	Mobile Country Code 3rd digit
	--         bits 8765	Mobile Network Code 3rd digit
	--	or filler (1111) for 2 digit MNCs
	-- octet 3 bits 4321	Mobile Network Code 1st digit
	--         bits 8765	Mobile Network Code 2nd digit
	-- octets 4 and 5	Location Area Code according to TS 3GPP TS 24.008 [35]
	-- octets 6 and 7	Cell Identity (CI) according to TS 3GPP TS 24.008 [35]

NetworkResource ::= ENUMERATED {
	plmn  (0),
	hlr  (1),
	vlr  (2),
	pvlr  (3),
	controllingMSC  (4),
	vmsc  (5),
	eir  (6),
	rss  (7)}

AdditionalNetworkResource ::= ENUMERATED {
	sgsn (0),
	ggsn (1),
	gmlc (2),
	gsmSCF (3),
	nplr (4),
	auc (5),
	... ,
	ue (6),
	mme (7)}
	-- if unknown value is received in AdditionalNetworkResource
	-- it shall be ignored.


NAEA-PreferredCI ::= SEQUENCE {
	naea-PreferredCIC	[0] NAEA-CIC,
	extensionContainer	[1] ExtensionContainer	OPTIONAL,
	...}

NAEA-CIC ::= OCTET STRING (SIZE (3))
	-- The internal structure is defined by the Carrier Identification
	-- parameter in ANSI T1.113.3. Carrier codes between "000" and "999" may
	-- be encoded as 3 digits using "000" to "999" or as 4 digits using 
	-- "0000" to "0999". Carrier codes between "1000" and "9999" are encoded
	-- using 4 digits.

SubscriberIdentity ::= CHOICE {
	imsi	[0] IMSI,
	msisdn	[1] ISDN-AddressString
	}

LCSClientExternalID ::= SEQUENCE {
	externalAddress	[0] ISDN-AddressString	OPTIONAL,
	extensionContainer	[1] ExtensionContainer	OPTIONAL,
	... }

LCSClientInternalID ::= ENUMERATED {
	broadcastService	(0),
	o-andM-HPLMN	(1),
	o-andM-VPLMN	(2),
	anonymousLocation	(3),
	targetMSsubscribedService	(4),
	... }
-- for a CAMEL phase 3 PLMN operator client, the value targetMSsubscribedService shall be used

LCSServiceTypeID ::= INTEGER (0..127)
	-- the integer values 0-63 are reserved for Standard LCS service types
	-- the integer values 64-127 are reserved for Non Standard LCS service types

-- Standard LCS Service Types
emergencyServices	LCSServiceTypeID ::= 0
emergencyAlertServices	LCSServiceTypeID ::= 1
personTracking	LCSServiceTypeID ::= 2
fleetManagement	LCSServiceTypeID ::= 3
assetManagement	LCSServiceTypeID ::= 4
trafficCongestionReporting	LCSServiceTypeID ::= 5
roadsideAssistance	LCSServiceTypeID ::= 6
routingToNearestCommercialEnterprise	LCSServiceTypeID ::= 7
navigation	LCSServiceTypeID ::= 8
	--this service type is reserved for use in previous releases
citySightseeing	LCSServiceTypeID ::= 9
localizedAdvertising	LCSServiceTypeID ::= 10
mobileYellowPages	LCSServiceTypeID ::= 11 
trafficAndPublicTransportationInfo	LCSServiceTypeID ::= 12
weather	LCSServiceTypeID ::= 13
assetAndServiceFinding	LCSServiceTypeID ::= 14
gaming	LCSServiceTypeID ::= 15
findYourFriend	LCSServiceTypeID ::= 16
dating	LCSServiceTypeID ::= 17
chatting	LCSServiceTypeID ::= 18
routeFinding	LCSServiceTypeID ::= 19
whereAmI	LCSServiceTypeID ::= 20

-- The values of LCSServiceTypeID are defined according to 3GPP TS 22.071.

-- Non Standard LCS Service Types
serv64	LCSServiceTypeID ::= 64
serv65	LCSServiceTypeID ::= 65
serv66	LCSServiceTypeID ::= 66
serv67	LCSServiceTypeID ::= 67
serv68	LCSServiceTypeID ::= 68
serv69	LCSServiceTypeID ::= 69
serv70	LCSServiceTypeID ::= 70
serv71	LCSServiceTypeID ::= 71
serv72	LCSServiceTypeID ::= 72
serv73	LCSServiceTypeID ::= 73
serv74	LCSServiceTypeID ::= 74
serv75	LCSServiceTypeID ::= 75
serv76	LCSServiceTypeID ::= 76
serv77	LCSServiceTypeID ::= 77
serv78	LCSServiceTypeID ::= 78
serv79	LCSServiceTypeID ::= 79
serv80	LCSServiceTypeID ::= 80
serv81	LCSServiceTypeID ::= 81
serv82	LCSServiceTypeID ::= 82
serv83	LCSServiceTypeID ::= 83
serv84	LCSServiceTypeID ::= 84
serv85	LCSServiceTypeID ::= 85
serv86	LCSServiceTypeID ::= 86
serv87	LCSServiceTypeID ::= 87
serv88	LCSServiceTypeID ::= 88
serv89	LCSServiceTypeID ::= 89
serv90	LCSServiceTypeID ::= 90
serv91	LCSServiceTypeID ::= 91
serv92	LCSServiceTypeID ::= 92
serv93	LCSServiceTypeID ::= 93
serv94	LCSServiceTypeID ::= 94
serv95	LCSServiceTypeID ::= 95
serv96	LCSServiceTypeID ::= 96
serv97	LCSServiceTypeID ::= 97
serv98	LCSServiceTypeID ::= 98
serv99	LCSServiceTypeID ::= 99
serv100	LCSServiceTypeID ::= 100
serv101	LCSServiceTypeID ::= 101
serv102	LCSServiceTypeID ::= 102
serv103	LCSServiceTypeID ::= 103
serv104	LCSServiceTypeID ::= 104
serv105	LCSServiceTypeID ::= 105
serv106	LCSServiceTypeID ::= 106
serv107	LCSServiceTypeID ::= 107
serv108	LCSServiceTypeID ::= 108
serv109	LCSServiceTypeID ::= 109
serv110	LCSServiceTypeID ::= 110
serv111	LCSServiceTypeID ::= 111
serv112	LCSServiceTypeID ::= 112
serv113	LCSServiceTypeID ::= 113
serv114	LCSServiceTypeID ::= 114
serv115	LCSServiceTypeID ::= 115
serv116	LCSServiceTypeID ::= 116
serv117	LCSServiceTypeID ::= 117
serv118	LCSServiceTypeID ::= 118
serv119	LCSServiceTypeID ::= 119
serv120	LCSServiceTypeID ::= 120
serv121	LCSServiceTypeID ::= 121
serv122	LCSServiceTypeID ::= 122
serv123	LCSServiceTypeID ::= 123
serv124	LCSServiceTypeID ::= 124
serv125	LCSServiceTypeID ::= 125
serv126	LCSServiceTypeID ::= 126
serv127	LCSServiceTypeID ::= 127

PLMN-Id ::= OCTET STRING (SIZE (3))
	-- The internal structure is defined as follows:
	-- octet 1 bits 4321	Mobile Country Code 1st digit
	--         bits 8765	Mobile Country Code 2nd digit
	-- octet 2 bits 4321	Mobile Country Code 3rd digit
	--         bits 8765	Mobile Network Code 3rd digit
	--	or filler (1111) for 2 digit MNCs
	-- octet 3 bits 4321	Mobile Network Code 1st digit
	--         bits 8765	Mobile Network Code 2nd digit

E-UTRAN-CGI ::= OCTET STRING (SIZE (7))
	-- Octets are coded as described in 3GPP TS 29.118 [152].

NR-CGI ::= OCTET STRING (SIZE (8))
	-- Octets are coded as described in 3GPP TS 38.413 [153].

TA-Id ::= OCTET STRING (SIZE (5))
	-- Octets are coded as described in 3GPP TS 29.118 [152].

NR-TA-Id ::= OCTET STRING (SIZE (6))
	-- Octets are coded as described in 3GPP TS 38.413 [153].

RAIdentity ::= OCTET STRING (SIZE (6))
-- Routing Area Identity is coded in accordance with 3GPP TS 29.060 [105].
-- It shall contain the value part defined in 3GPP TS 29.060 only. I.e. the 3GPP TS 29.060
-- type identifier octet shall not be included.

NetworkNodeDiameterAddress::= SEQUENCE {
	diameter-Name	[0] DiameterIdentity,
	diameter-Realm	[1] DiameterIdentity }

-- data types for CAMEL

CellGlobalIdOrServiceAreaIdOrLAI ::= CHOICE {
	cellGlobalIdOrServiceAreaIdFixedLength	[0] CellGlobalIdOrServiceAreaIdFixedLength,
	laiFixedLength	[1] LAIFixedLength}

CellGlobalIdOrServiceAreaIdFixedLength ::= OCTET STRING (SIZE (7))
	-- Refers to Cell Global Identification or Service Are Identification
	-- defined in 3GPP TS 23.003.
	-- The internal structure is defined as follows:
	-- octet 1 bits 4321	Mobile Country Code 1st digit
	--         bits 8765	Mobile Country Code 2nd digit
	-- octet 2 bits 4321	Mobile Country Code 3rd digit
	--         bits 8765	Mobile Network Code 3rd digit
	--	or filler (1111) for 2 digit MNCs
	-- octet 3 bits 4321	Mobile Network Code 1st digit
	--         bits 8765	Mobile Network Code 2nd digit
	-- octets 4 and 5	Location Area Code according to 3GPP TS 24.008
	-- octets 6 and 7	Cell Identity (CI) value or 
	--	Service Area Code (SAC) value 
	--	according to 3GPP TS 23.003

LAIFixedLength ::= OCTET STRING (SIZE (5))
	-- Refers to Location Area Identification defined in 3GPP TS 23.003 [17].
	-- The internal structure is defined as follows:
	-- octet 1 bits 4321	Mobile Country Code 1st digit
	--         bits 8765	Mobile Country Code 2nd digit
	-- octet 2 bits 4321	Mobile Country Code 3rd digit
	--         bits 8765	Mobile Network Code 3rd digit
	--	or filler (1111) for 2 digit MNCs
	-- octet 3 bits 4321	Mobile Network Code 1st digit
	--         bits 8765	Mobile Network Code 2nd digit
	-- octets 4 and 5	Location Area Code according to 3GPP TS 24.008 [35]

-- data types for subscriber management

BasicServiceCode ::= CHOICE {
	bearerService	[2] BearerServiceCode,
	teleservice	[3] TeleserviceCode}

Ext-BasicServiceCode ::= CHOICE {
	ext-BearerService	[2] Ext-BearerServiceCode,
	ext-Teleservice	[3] Ext-TeleserviceCode}

EMLPP-Info ::= SEQUENCE {
	maximumentitledPriority	EMLPP-Priority,
	defaultPriority	EMLPP-Priority,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

EMLPP-Priority ::= INTEGER (0..15)
	-- The mapping from the values A,B,0,1,2,3,4 to the integer-value is
	-- specified as follows where A is the highest and 4 is the lowest
	-- priority level
	-- the integer values 7-15 are spare and shall be mapped to value 4

priorityLevelA	EMLPP-Priority ::= 6
priorityLevelB	EMLPP-Priority ::= 5
priorityLevel0	EMLPP-Priority ::= 0
priorityLevel1	EMLPP-Priority ::= 1
priorityLevel2	EMLPP-Priority ::= 2
priorityLevel3	EMLPP-Priority ::= 3
priorityLevel4	EMLPP-Priority ::= 4

MC-SS-Info ::= SEQUENCE {
	ss-Code	[0] SS-Code,
	ss-Status	[1] Ext-SS-Status,
	nbrSB	[2] MaxMC-Bearers,
	nbrUser	[3] MC-Bearers,
	extensionContainer	[4] ExtensionContainer	OPTIONAL,
	...}

MaxMC-Bearers ::= INTEGER (2..maxNumOfMC-Bearers)

MC-Bearers ::= INTEGER (1..maxNumOfMC-Bearers)

maxNumOfMC-Bearers  INTEGER ::= 7

Ext-SS-Status ::= OCTET STRING (SIZE (1..5))

	-- OCTET 1:
	--
	-- bits 8765: 0000 (unused)
	-- bits 4321: Used to convey the "P bit","R bit","A bit" and "Q bit",
	--	 representing supplementary service state information
	--	 as defined in TS 3GPP TS 23.011 [22]

	-- bit 4: "Q bit"

	-- bit 3: "P bit"

	-- bit 2: "R bit"

	-- bit 1: "A bit"

	-- OCTETS 2-5: reserved for future use. They shall be discarded if
	-- received and not understood.


	-- data types for geographic location

AgeOfLocationInformation ::= INTEGER (0..32767)
-- the value represents the elapsed time in minutes since the last
-- network contact of the mobile station (i.e. the actuality of the
-- location information).
-- value "0" indicates that the MS is currently in contact with the
--           network
-- value "32767" indicates that the location information is at least
--               32767 minutes old

.#END
17.7.9	Teleservice Codes
.$MAP-TS-Code {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-TS-Code (19) version19 (19)}

DEFINITIONS

::=

BEGIN

TeleserviceCode ::= OCTET STRING (SIZE (1))
	-- This type is used to represent the code identifying a single
	-- teleservice, a group of teleservices, or all teleservices. The
	-- services are defined in TS GSM 22.003 [4].
	-- The internal structure is defined as follows:

	-- bits 87654321: group (bits 8765) and specific service
	-- (bits 4321)

Ext-TeleserviceCode ::= OCTET STRING (SIZE (1..5))
	-- This type is used to represent the code identifying a single
	-- teleservice, a group of teleservices, or all teleservices. The
	-- services are defined in TS GSM 22.003 [4].
	-- The internal structure is defined as follows:

	-- OCTET 1:
	-- bits 87654321: group (bits 8765) and specific service
	-- (bits 4321)

	-- OCTETS 2-5: reserved for future use. If received the
    -- Ext-TeleserviceCode shall be
	-- treated according to the exception handling defined for the
	-- operation that uses this type.

	-- Ext-TeleserviceCode includes all values defined for TeleserviceCode.

allTeleservices	TeleserviceCode ::= '00000000'B

allSpeechTransmissionServices	TeleserviceCode ::= '00010000'B
telephony	TeleserviceCode ::= '00010001'B
emergencyCalls	TeleserviceCode ::= '00010010'B

allShortMessageServices	TeleserviceCode ::= '00100000'B
shortMessageMT-PP	TeleserviceCode ::= '00100001'B
shortMessageMO-PP	TeleserviceCode ::= '00100010'B

allFacsimileTransmissionServices	TeleserviceCode ::= '01100000'B
facsimileGroup3AndAlterSpeech	TeleserviceCode ::= '01100001'B
automaticFacsimileGroup3	TeleserviceCode ::= '01100010'B
facsimileGroup4	TeleserviceCode ::= '01100011'B

-- The following non-hierarchical Compound Teleservice Groups
-- are defined in TS 3GPP TS 22.030:
allDataTeleservices	TeleserviceCode ::= '01110000'B
	-- covers Teleservice Groups 'allFacsimileTransmissionServices'
	-- and 'allShortMessageServices'
allTeleservices-ExeptSMS	TeleserviceCode ::= '10000000'B
	-- covers Teleservice Groups 'allSpeechTransmissionServices' and
	-- 'allFacsimileTransmissionServices'
--
-- Compound Teleservice Group Codes are only used in call
-- independent supplementary service operations, i.e. they
-- are not used in InsertSubscriberData or in
-- DeleteSubscriberData messages.

allVoiceGroupCallServices	TeleserviceCode ::= '10010000'B
voiceGroupCall	TeleserviceCode ::= '10010001'B
voiceBroadcastCall	TeleserviceCode ::= '10010010'B

allPLMN-specificTS	TeleserviceCode ::= '11010000'B
plmn-specificTS-1	TeleserviceCode ::= '11010001'B
plmn-specificTS-2	TeleserviceCode ::= '11010010'B
plmn-specificTS-3	TeleserviceCode ::= '11010011'B
plmn-specificTS-4	TeleserviceCode ::= '11010100'B
plmn-specificTS-5	TeleserviceCode ::= '11010101'B
plmn-specificTS-6	TeleserviceCode ::= '11010110'B
plmn-specificTS-7	TeleserviceCode ::= '11010111'B
plmn-specificTS-8	TeleserviceCode ::= '11011000'B
plmn-specificTS-9	TeleserviceCode ::= '11011001'B
plmn-specificTS-A	TeleserviceCode ::= '11011010'B
plmn-specificTS-B	TeleserviceCode ::= '11011011'B
plmn-specificTS-C	TeleserviceCode ::= '11011100'B
plmn-specificTS-D	TeleserviceCode ::= '11011101'B
plmn-specificTS-E	TeleserviceCode ::= '11011110'B
plmn-specificTS-F	TeleserviceCode ::= '11011111'B

.#END
17.7.10	Bearer Service Codes
.$MAP-BS-Code {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-BS-Code (20) version19 (19)}

DEFINITIONS

::=

BEGIN

BearerServiceCode ::= OCTET STRING (SIZE (1))
	-- This type is used to represent the code identifying a single
	-- bearer service, a group of bearer services, or all bearer
	-- services. The services are defined in TS 3GPP TS 22.002 [3].
	-- The internal structure is defined as follows:
	--
	-- plmn-specific bearer services:
	-- bits 87654321: defined by the HPLMN operator

	-- rest of bearer services:
	-- bit 8: 0 (unused)
	-- bits 7654321: group (bits 7654), and rate, if applicable
	-- (bits 321)

Ext-BearerServiceCode ::= OCTET STRING (SIZE (1..5))
	-- This type is used to represent the code identifying a single
	-- bearer service, a group of bearer services, or all bearer
	-- services. The services are defined in TS 3GPP TS 22.002 [3].
	-- The internal structure is defined as follows:
	--
	-- OCTET 1:
	-- plmn-specific bearer services:
	-- bits 87654321: defined by the HPLMN operator
	--
	-- rest of bearer services:
	-- bit 8: 0 (unused)
	-- bits 7654321: group (bits 7654), and rate, if applicable
	-- (bits 321)

	-- OCTETS 2-5: reserved for future use. If received the
    -- Ext-TeleserviceCode shall be
	-- treated according to the exception handling defined for the
	-- operation that uses this type. 


	-- Ext-BearerServiceCode includes all values defined for BearerServiceCode.

allBearerServices	BearerServiceCode ::= '00000000'B

allDataCDA-Services	BearerServiceCode ::= '00010000'B
dataCDA-300bps	BearerServiceCode ::= '00010001'B
dataCDA-1200bps	BearerServiceCode ::= '00010010'B
dataCDA-1200-75bps	BearerServiceCode ::= '00010011'B
dataCDA-2400bps	BearerServiceCode ::= '00010100'B
dataCDA-4800bps	BearerServiceCode ::= '00010101'B
dataCDA-9600bps	BearerServiceCode ::= '00010110'B
general-dataCDA	BearerServiceCode ::= '00010111'B

allDataCDS-Services	BearerServiceCode ::= '00011000'B
dataCDS-1200bps	BearerServiceCode ::= '00011010'B
dataCDS-2400bps	BearerServiceCode ::= '00011100'B
dataCDS-4800bps	BearerServiceCode ::= '00011101'B
dataCDS-9600bps	BearerServiceCode ::= '00011110'B
general-dataCDS	BearerServiceCode ::= '00011111'B

allPadAccessCA-Services	BearerServiceCode ::= '00100000'B
padAccessCA-300bps	BearerServiceCode ::= '00100001'B
padAccessCA-1200bps	BearerServiceCode ::= '00100010'B
padAccessCA-1200-75bps	BearerServiceCode ::= '00100011'B
padAccessCA-2400bps	BearerServiceCode ::= '00100100'B
padAccessCA-4800bps	BearerServiceCode ::= '00100101'B
padAccessCA-9600bps	BearerServiceCode ::= '00100110'B
general-padAccessCA	BearerServiceCode ::= '00100111'B

allDataPDS-Services	BearerServiceCode ::= '00101000'B
dataPDS-2400bps	BearerServiceCode ::= '00101100'B
dataPDS-4800bps	BearerServiceCode ::= '00101101'B
dataPDS-9600bps	BearerServiceCode ::= '00101110'B
general-dataPDS	BearerServiceCode ::= '00101111'B

allAlternateSpeech-DataCDA	BearerServiceCode ::= '00110000'B

allAlternateSpeech-DataCDS	BearerServiceCode ::= '00111000'B

allSpeechFollowedByDataCDA	BearerServiceCode ::= '01000000'B

allSpeechFollowedByDataCDS	BearerServiceCode ::= '01001000'B

-- The following non-hierarchical Compound Bearer Service
-- Groups are defined in TS 3GPP TS 22.030:
allDataCircuitAsynchronous	BearerServiceCode ::= '01010000'B
	-- covers "allDataCDA-Services", "allAlternateSpeech-DataCDA" and
	-- "allSpeechFollowedByDataCDA"
allAsynchronousServices	BearerServiceCode ::= '01100000'B
	-- covers "allDataCDA-Services", "allAlternateSpeech-DataCDA",
	-- "allSpeechFollowedByDataCDA" and "allPadAccessCDA-Services"
allDataCircuitSynchronous	BearerServiceCode ::= '01011000'B
	-- covers "allDataCDS-Services", "allAlternateSpeech-DataCDS" and
	-- "allSpeechFollowedByDataCDS"
allSynchronousServices	BearerServiceCode ::= '01101000'B
	-- covers "allDataCDS-Services", "allAlternateSpeech-DataCDS",
	-- "allSpeechFollowedByDataCDS" and "allDataPDS-Services"
--
-- Compound Bearer Service Group Codes are only used in call
-- independent supplementary service operations, i.e. they
-- are not used in InsertSubscriberData or in
-- DeleteSubscriberData messages.

allPLMN-specificBS	BearerServiceCode ::= '11010000'B
plmn-specificBS-1	BearerServiceCode ::= '11010001'B
plmn-specificBS-2	BearerServiceCode ::= '11010010'B
plmn-specificBS-3	BearerServiceCode ::= '11010011'B
plmn-specificBS-4	BearerServiceCode ::= '11010100'B
plmn-specificBS-5	BearerServiceCode ::= '11010101'B
plmn-specificBS-6	BearerServiceCode ::= '11010110'B
plmn-specificBS-7	BearerServiceCode ::= '11010111'B
plmn-specificBS-8	BearerServiceCode ::= '11011000'B
plmn-specificBS-9	BearerServiceCode ::= '11011001'B
plmn-specificBS-A	BearerServiceCode ::= '11011010'B
plmn-specificBS-B	BearerServiceCode ::= '11011011'B
plmn-specificBS-C	BearerServiceCode ::= '11011100'B
plmn-specificBS-D	BearerServiceCode ::= '11011101'B
plmn-specificBS-E	BearerServiceCode ::= '11011110'B
plmn-specificBS-F	BearerServiceCode ::= '11011111'B

.#END
17.7.11	Extension data types
.$MAP-ExtensionDataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version19 (19)}

DEFINITIONS

IMPLICIT TAGS

::=

BEGIN

EXPORTS

	PrivateExtension,
	ExtensionContainer,
	SLR-ArgExtensionContainer;


-- IOC for private MAP extensions


MAP-EXTENSION  ::= CLASS {
	&ExtensionType	OPTIONAL,
	&extensionId	OBJECT IDENTIFIER }
	-- The length of the Object Identifier shall not exceed 16 octets and the
	-- number of components of the Object Identifier shall not exceed 16

-- data types

ExtensionContainer ::= SEQUENCE {
	privateExtensionList	[0]PrivateExtensionList	OPTIONAL, 
	pcs-Extensions	[1]PCS-Extensions	OPTIONAL,
	...}

SLR-ArgExtensionContainer ::= SEQUENCE {
	privateExtensionList	[0]PrivateExtensionList	OPTIONAL, 
	slr-Arg-PCS-Extensions	[1]SLR-Arg-PCS-Extensions	OPTIONAL,
	...}

PrivateExtensionList ::= SEQUENCE SIZE (1..maxNumOfPrivateExtensions) OF
	PrivateExtension

PrivateExtension ::= SEQUENCE {
	extId	MAP-EXTENSION.&extensionId
	({ExtensionSet}),
	extType	MAP-EXTENSION.&ExtensionType
	({ExtensionSet}{@extId})	OPTIONAL}

maxNumOfPrivateExtensions  INTEGER ::= 10

ExtensionSet	MAP-EXTENSION ::=
	{...
	-- ExtensionSet is the set of all defined private extensions
	}
	-- Unsupported private extensions shall be discarded if received.

PCS-Extensions ::= SEQUENCE {
	...}

SLR-Arg-PCS-Extensions ::= SEQUENCE {
	...,
	na-ESRK-Request	[0]	NULL	OPTIONAL }

.#END

17.7.12	Group Call data types
.$MAP-GR-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-GR-DataTypes (23) version19 (19)}

DEFINITIONS

IMPLICIT TAGS

::=

BEGIN

EXPORTS
	PrepareGroupCallArg,
	PrepareGroupCallRes,
	SendGroupCallEndSignalArg,
	SendGroupCallEndSignalRes,
	ForwardGroupCallSignallingArg,
	ProcessGroupCallSignallingArg,
	SendGroupCallInfoArg,
	SendGroupCallInfoRes
;

IMPORTS
	ISDN-AddressString,
	IMSI, 
	TMSI,
	EMLPP-Priority,
	ASCI-CallReference,
	SignalInfo,
	GlobalCellId,
	AccessNetworkSignalInfo
FROM MAP-CommonDataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-CommonDataTypes (18) version19 (19)}

	Ext-TeleserviceCode
FROM MAP-TS-Code {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-TS-Code (19) version19 (19)}

	Kc,
	AdditionalInfo,
	GroupId,
Long-GroupId,
	AdditionalSubscriptions,
	Cksn
FROM MAP-MS-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-MS-DataTypes (11) version19 (19)}

	ExtensionContainer
FROM MAP-ExtensionDataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version19 (19)}
;


PrepareGroupCallArg ::= SEQUENCE {
	teleservice	Ext-TeleserviceCode,
	asciCallReference	ASCI-CallReference,
	codec-Info	CODEC-Info,
	cipheringAlgorithm	CipheringAlgorithm,
	groupKeyNumber-Vk-Id	[0] GroupKeyNumber	OPTIONAL,
	groupKey	[1] Kc	OPTIONAL, 
	-- this parameter shall not be sent and shall be discarded if received
	priority	[2] EMLPP-Priority	OPTIONAL,
	uplinkFree	[3] NULL	OPTIONAL,
	extensionContainer	[4] ExtensionContainer	OPTIONAL,
	...,
	vstk	[5] VSTK	OPTIONAL,
	vstk-rand	[6] VSTK-RAND	OPTIONAL,
	talkerChannelParameter	[7] NULL	OPTIONAL,
	uplinkReplyIndicator	[8] NULL	OPTIONAL}

VSTK ::= OCTET STRING (SIZE (16))

VSTK-RAND ::= OCTET STRING (SIZE (5))
	-- The 36 bit value is carried in bit 7 of octet 1 to bit 4 of octet 5
	-- bits 3, 2, 1, and 0 of octet 5 are padded with zeros.

PrepareGroupCallRes ::= SEQUENCE {
	groupCallNumber	ISDN-AddressString,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

SendGroupCallEndSignalArg ::= SEQUENCE {
	imsi	IMSI	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	talkerPriority	[0]TalkerPriority	OPTIONAL,
	additionalInfo	[1]AdditionalInfo	OPTIONAL }

TalkerPriority ::= ENUMERATED {
	normal  (0),
	privileged  (1),
	emergency  (2)}

SendGroupCallEndSignalRes ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL,
	...}

ForwardGroupCallSignallingArg ::= SEQUENCE {
	imsi	IMSI	OPTIONAL,
	uplinkRequestAck	[0] NULL	OPTIONAL,
	uplinkReleaseIndication	[1] NULL	OPTIONAL,
	uplinkRejectCommand	[2] NULL	OPTIONAL,
	uplinkSeizedCommand	[3] NULL	OPTIONAL,
	uplinkReleaseCommand	[4] NULL	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	..., 
	stateAttributes	[5] StateAttributes	OPTIONAL,
	talkerPriority	[6] TalkerPriority	OPTIONAL,
	additionalInfo	[7] AdditionalInfo	OPTIONAL,
	emergencyModeResetCommandFlag	[8] NULL	OPTIONAL,
	sm-RP-UI	[9] SignalInfo	OPTIONAL,
	an-APDU	[10] AccessNetworkSignalInfo	OPTIONAL
 }

ProcessGroupCallSignallingArg ::= SEQUENCE {
	uplinkRequest	[0] NULL	OPTIONAL,
	uplinkReleaseIndication	[1] NULL	OPTIONAL,
	releaseGroupCall	[2] NULL	OPTIONAL,
	extensionContainer	ExtensionContainer	OPTIONAL,
	...,
	talkerPriority	[3] TalkerPriority	OPTIONAL,
	additionalInfo	[4] AdditionalInfo	OPTIONAL,
	emergencyModeResetCommandFlag	[5] NULL	OPTIONAL,
	an-APDU	[6] AccessNetworkSignalInfo	OPTIONAL }

GroupKeyNumber ::= INTEGER (0..15)

CODEC-Info ::= OCTET STRING (SIZE (5..10))
	-- Refers to channel type
	-- coded according to 3GPP TS 48.008 [49] and including Element identifier and Length	

CipheringAlgorithm ::= OCTET STRING (SIZE (1))
	-- Refers to 'permitted algorithms' in 'encryption information'
	-- coded according to 3GPP TS 48.008 [49]:
	
	-- Bits 8-1 
	-- 8765 4321
	-- 0000 0001	No encryption
	-- 0000 0010	GSM A5/1
	-- 0000 0100	GSM A5/2
	-- 0000 1000	GSM A5/3
	-- 0001 0000	GSM A5/4
	-- 0010 0000	GSM A5/5
	-- 0100 0000	GSM A5/6
	-- 1000 0000	GSM A5/7

StateAttributes ::= SEQUENCE {
	downlinkAttached	[5] NULL	OPTIONAL,
	uplinkAttached	[6] NULL	OPTIONAL,
	dualCommunication	[7] NULL	OPTIONAL,
	callOriginator	[8] NULL	OPTIONAL }

	-- Refers to 3GPP TS 44.068 for definitions of StateAttributes fields. 


SendGroupCallInfoArg ::= SEQUENCE {
	requestedInfo	RequestedInfo,
	groupId	Long-GroupId, 
	teleservice	Ext-TeleserviceCode,
	cellId	[0] GlobalCellId	OPTIONAL,
	imsi	[1] IMSI	OPTIONAL,
	tmsi	[2] TMSI	OPTIONAL,
	additionalInfo	[3] AdditionalInfo	OPTIONAL,
	talkerPriority	[4] TalkerPriority	OPTIONAL,
	cksn	[5] Cksn	OPTIONAL,
	extensionContainer	[6] ExtensionContainer	OPTIONAL,
	... }

RequestedInfo ::= ENUMERATED {
	anchorMSC-AddressAndASCI-CallReference	(0),
	imsiAndAdditionalInfoAndAdditionalSubscription	(1),
	... }
--	exception handling:
--	an unrecognized value shall be rejected by the receiver with a return error cause of 
--	unexpected data value

SendGroupCallInfoRes ::= SEQUENCE {
	anchorMSC-Address	[0] ISDN-AddressString	OPTIONAL,
	asciCallReference	[1] ASCI-CallReference	OPTIONAL,
	imsi	[2] IMSI	OPTIONAL,
	additionalInfo	[3] AdditionalInfo	OPTIONAL,
	additionalSubscriptions	[4] AdditionalSubscriptions	OPTIONAL,
	kc	[5] Kc	OPTIONAL,
	extensionContainer	[6] ExtensionContainer	OPTIONAL,
	... }


.#END

17.7.13	Location service data types
.$MAP-LCS-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-LCS-DataTypes (25) version19 (19)}

DEFINITIONS
IMPLICIT TAGS
::=
BEGIN

EXPORTS
	RoutingInfoForLCS-Arg,
	RoutingInfoForLCS-Res,
	ProvideSubscriberLocation-Arg,
	ProvideSubscriberLocation-Res,
	SubscriberLocationReport-Arg,
	SubscriberLocationReport-Res,
LocationType, 
DeferredLocationEventType,
LCSClientName,
LCS-QoS,
Horizontal-Accuracy,
ResponseTime,
Ext-GeographicalInformation, 
VelocityEstimate,
SupportedGADShapes,
Add-GeographicalInformation,
LCSRequestorID, 
LCS-ReferenceNumber,
LCSCodeword,
AreaEventInfo,
ReportingPLMNList,
PeriodicLDRInfo,
SequenceNumber,
LCSClientType,
LCS-Priority,
OccurrenceInfo,
IntervalTime
;

IMPORTS
	AddressString,
	ISDN-AddressString,
	IMEI,
	IMSI,
	LMSI,
	SubscriberIdentity,
	AgeOfLocationInformation,
	LCSClientExternalID,
	LCSClientInternalID,
LCSServiceTypeID,
CellGlobalIdOrServiceAreaIdOrLAI,
PLMN-Id,
	GSN-Address,
	DiameterIdentity
FROM MAP-CommonDataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-CommonDataTypes (18) version19 (19)}

	ExtensionContainer,
	SLR-ArgExtensionContainer
FROM MAP-ExtensionDataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version19 (19)}

	USSD-DataCodingScheme,
USSD-String
FROM MAP-SS-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3)
   map-SS-DataTypes (14) version19 (19)}

	APN,
	SupportedLCS-CapabilitySets
FROM MAP-MS-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-MS-DataTypes (11) version19 (19)}

	Additional-Number
FROM MAP-SM-DataTypes {
   itu-t identified-organization (4) etsi (0) mobileDomain (0)
   gsm-Network (1) modules (3) map-SM-DataTypes (16) version19 (19)}
;


RoutingInfoForLCS-Arg ::= SEQUENCE {
	mlcNumber	[0] ISDN-AddressString,
	targetMS	[1] SubscriberIdentity,
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	...}

RoutingInfoForLCS-Res ::= SEQUENCE {
	targetMS	[0] SubscriberIdentity,
	lcsLocationInfo	[1] LCSLocationInfo,
	extensionContainer	[2] ExtensionContainer	OPTIONAL,
	...,
	v-gmlc-Address	[3]	GSN-Address	OPTIONAL,
	h-gmlc-Address	[4]	GSN-Address	OPTIONAL,
	ppr-Address	[5]	GSN-Address	OPTIONAL,
	additional-v-gmlc-Address	[6]	GSN-Address	OPTIONAL }

LCSLocationInfo ::= SEQUENCE {
	networkNode-Number	ISDN-AddressString,
	-- NetworkNode-number can be msc-number, sgsn-number or a dummy value of "0"
	lmsi	[0] LMSI	OPTIONAL,
	extensionContainer	[1] ExtensionContainer	OPTIONAL,
	... ,
	gprsNodeIndicator	[2] NULL	OPTIONAL,
	-- gprsNodeIndicator is set only if the SGSN number is sent as the Network Node Number
	additional-Number	[3] Additional-Number	OPTIONAL,
	supportedLCS-CapabilitySets	[4]	SupportedLCS-CapabilitySets	OPTIONAL,
	additional-LCS-CapabilitySets	[5]	SupportedLCS-CapabilitySets	OPTIONAL,
	mme-Name	[6]	DiameterIdentity	OPTIONAL,
	aaa-Server-Name	[8]	DiameterIdentity	OPTIONAL,
	sgsn-Name	[9]	DiameterIdentity	OPTIONAL,
	sgsn-Realm	[10]	DiameterIdentity	OPTIONAL
	}

ProvideSubscriberLocation-Arg ::= SEQUENCE {
	locationType	LocationType,
	mlc-Number	ISDN-AddressString,
	lcs-ClientID	[0] LCS-ClientID	OPTIONAL,
	privacyOverride	[1] NULL	OPTIONAL,
	imsi	[2] IMSI	OPTIONAL,
	msisdn	[3] ISDN-AddressString	OPTIONAL,
	lmsi	[4] LMSI	OPTIONAL,
	imei	[5] IMEI	OPTIONAL,
	lcs-Priority	[6] LCS-Priority	OPTIONAL,
	lcs-QoS	[7] LCS-QoS	OPTIONAL,
	extensionContainer	[8] ExtensionContainer	OPTIONAL,
	... ,
	supportedGADShapes	[9]	SupportedGADShapes	OPTIONAL,
	lcs-ReferenceNumber	[10]	LCS-ReferenceNumber	OPTIONAL,
	lcsServiceTypeID	[11]	LCSServiceTypeID	OPTIONAL,
	lcsCodeword	[12]	LCSCodeword	OPTIONAL,
	lcs-PrivacyCheck	[13]	LCS-PrivacyCheck	OPTIONAL,
	areaEventInfo	[14]	AreaEventInfo	OPTIONAL,
	h-gmlc-Address	[15]	GSN-Address	OPTIONAL,
	mo-lrShortCircuitIndicator	[16] NULL	OPTIONAL,
	periodicLDRInfo	[17] PeriodicLDRInfo	OPTIONAL,
	reportingPLMNList	[18] ReportingPLMNList	OPTIONAL }

	-- one of imsi or msisdn is mandatory
	-- If a location estimate type indicates activate deferred location or cancel deferred 
	-- location, a lcs-Reference number shall be included.

LocationType ::= SEQUENCE {
	locationEstimateType	[0] LocationEstimateType,
	...,
	deferredLocationEventType	[1] DeferredLocationEventType	OPTIONAL }

LocationEstimateType ::= ENUMERATED {
	currentLocation	(0),
	currentOrLastKnownLocation	(1),
	initialLocation	(2),
	...,
	activateDeferredLocation	(3),
	cancelDeferredLocation	(4) ,
	notificationVerificationOnly	(5) }
--	exception handling:
--	a ProvideSubscriberLocation-Arg containing an unrecognized LocationEstimateType
--	shall be rejected by the receiver with a return error cause of unexpected data value

DeferredLocationEventType ::= BIT STRING {
	msAvailable	(0) ,
	enteringIntoArea	(1),
	leavingFromArea	(2),
	beingInsideArea	(3) ,
	periodicLDR	(4)  } (SIZE (1..16)) 
-- beingInsideArea is always treated as oneTimeEvent regardless of the possible value
-- of occurrenceInfo inside areaEventInfo.
-- exception handling:
-- a ProvideSubscriberLocation-Arg containing other values than listed above in 
-- DeferredLocationEventType shall be rejected by the receiver with a return error cause of 
-- unexpected data value.

LCS-ClientID ::= SEQUENCE {
	lcsClientType	[0] LCSClientType,
	lcsClientExternalID	[1] LCSClientExternalID	OPTIONAL,
	lcsClientDialedByMS	[2] AddressString	OPTIONAL,
	lcsClientInternalID	[3] LCSClientInternalID	OPTIONAL,
	lcsClientName	[4] LCSClientName	OPTIONAL,
	...,
	lcsAPN	[5] APN	OPTIONAL,
	lcsRequestorID	[6] LCSRequestorID	OPTIONAL }

LCSClientType ::= ENUMERATED {
	emergencyServices	(0),
	valueAddedServices	(1),
	plmnOperatorServices	(2),
	lawfulInterceptServices	(3),
	... }
	--	exception handling:
	--	unrecognized values may be ignored if the LCS client uses the privacy override
	--	otherwise, an unrecognized value shall be treated as unexpected data by a receiver
	--	a return error shall then be returned if received in a MAP invoke 

LCSClientName ::= SEQUENCE {
	dataCodingScheme	[0] USSD-DataCodingScheme,
	nameString	[2] NameString,
	...,
	lcs-FormatIndicator	[3] LCS-FormatIndicator	OPTIONAL }

-- The USSD-DataCodingScheme shall indicate use of the default alphabet through the
-- following encoding
--	bit	7 6 5 4 3 2 1 0
--	0 0 0 0 1 1 1 1

NameString ::= USSD-String (SIZE (1..maxNameStringLength))

maxNameStringLength  INTEGER ::= 63

LCSRequestorID ::= SEQUENCE {
	dataCodingScheme	[0] USSD-DataCodingScheme,
	requestorIDString	[1] RequestorIDString,
	...,
	lcs-FormatIndicator	[2] LCS-FormatIndicator	OPTIONAL }

RequestorIDString ::= USSD-String (SIZE (1..maxRequestorIDStringLength))

maxRequestorIDStringLength  INTEGER ::= 63

LCS-FormatIndicator ::= ENUMERATED {
	logicalName	(0),
	e-mailAddress	(1),
	msisdn	(2),
	url	(3),
	sipUrl	(4),
	... }

LCS-Priority ::= OCTET STRING (SIZE (1))
	-- 0 = highest priority
	-- 1 = normal priority
	-- all other values treated as 1 

LCS-QoS ::= SEQUENCE {
	horizontal-accuracy	[0] Horizontal-Accuracy	OPTIONAL,
	verticalCoordinateRequest	[1] NULL	OPTIONAL,
	vertical-accuracy	[2] Vertical-Accuracy	OPTIONAL,	responseTime	[3] ResponseTime	OPTIONAL,
	extensionContainer	[4] ExtensionContainer	OPTIONAL,
	...,
	velocityRequest	[5] NULL	OPTIONAL
}

Horizontal-Accuracy ::= OCTET STRING (SIZE (1))
	-- bit 8 = 0
	-- bits 7-1 = 7 bit Uncertainty Code defined in 3GPP TS 23.032. The horizontal location 
	-- error should be less than the error indicated by the uncertainty code with 67%
	-- confidence.

Vertical-Accuracy ::= OCTET STRING (SIZE (1))
	-- bit 8 = 0
	-- bits 7-1 = 7 bit Vertical Uncertainty Code defined in 3GPP TS 23.032. 
	-- The vertical location error should be less than the error indicated 
	-- by the uncertainty code with 67% confidence.

ResponseTime ::= SEQUENCE {
	responseTimeCategory	ResponseTimeCategory,
	...}
--	note: an expandable SEQUENCE simplifies later addition of a numeric response time.

ResponseTimeCategory ::= ENUMERATED {
	lowdelay  (0),
	delaytolerant  (1),
	... }
--	exception handling:
--	an unrecognized value shall be treated the same as value 1 (delaytolerant)

SupportedGADShapes ::= BIT STRING {
	ellipsoidPoint  (0),
	ellipsoidPointWithUncertaintyCircle (1),
	ellipsoidPointWithUncertaintyEllipse (2),
	polygon (3),
	ellipsoidPointWithAltitude (4),
	ellipsoidPointWithAltitudeAndUncertaintyElipsoid (5),
	ellipsoidArc  (6) } (SIZE (7..16))
-- A node shall mark in the BIT STRING all Shapes defined in 3GPP TS 23.032 it supports.
-- exception handling: bits 7 to 15 shall be ignored if received.

LCS-ReferenceNumber::= OCTET STRING (SIZE(1))

LCSCodeword ::= SEQUENCE {
	dataCodingScheme	[0] USSD-DataCodingScheme,
	lcsCodewordString	[1] LCSCodewordString,
	...}

LCSCodewordString ::= USSD-String (SIZE (1..maxLCSCodewordStringLength))

maxLCSCodewordStringLength  INTEGER ::= 20

LCS-PrivacyCheck ::= SEQUENCE {
	callSessionUnrelated	[0] PrivacyCheckRelatedAction,
	callSessionRelated	[1] PrivacyCheckRelatedAction	OPTIONAL,
	...}

PrivacyCheckRelatedAction ::= ENUMERATED {
	allowedWithoutNotification (0),
	allowedWithNotification (1),
	allowedIfNoResponse (2),
	restrictedIfNoResponse (3),
	notAllowed (4),
	...}
--	exception handling:
--	a ProvideSubscriberLocation-Arg containing an unrecognized PrivacyCheckRelatedAction
--	shall be rejected by the receiver with a return error cause of unexpected data value

AreaEventInfo ::= SEQUENCE {
	areaDefinition	[0]	AreaDefinition,
	occurrenceInfo	[1]	OccurrenceInfo	OPTIONAL,
	intervalTime	[2]	IntervalTime	OPTIONAL,
	...}

AreaDefinition ::= SEQUENCE {
	areaList	[0]	AreaList,
	...}

AreaList ::= SEQUENCE SIZE (1..maxNumOfAreas) OF Area

maxNumOfAreas  INTEGER ::= 10

Area ::= SEQUENCE {
	areaType	[0]	AreaType,
	areaIdentification	[1]	AreaIdentification,
	...}

AreaType ::= ENUMERATED {
	countryCode	(0),
	plmnId	(1),
	locationAreaId	(2),
	routingAreaId	(3),
	cellGlobalId	(4),
	...,
	utranCellId	(5) }

AreaIdentification ::= OCTET STRING (SIZE (2..7))
	-- The internal structure is defined as follows:
	-- octet 1 bits 4321	Mobile Country Code 1st digit
	--         bits 8765	Mobile Country Code 2nd digit
	-- octet 2 bits 4321	Mobile Country Code 3rd digit
	--         bits 8765	Mobile Network Code 3rd digit if 3 digit MNC included
	--	or filler (1111)
	-- octet 3 bits 4321	Mobile Network Code 1st digit
	--         bits 8765	Mobile Network Code 2nd digit
	-- octets 4 and 5	Location Area Code (LAC) for Local Area Id,
	--	Routing Area Id and Cell Global Id
	-- octet 6	Routing Area Code (RAC) for Routing Area Id
	-- octets 6 and 7	Cell Identity (CI) for Cell Global Id
	-- octets 4 until 7	Utran Cell Identity (UC-Id) for Utran Cell Id

OccurrenceInfo ::= ENUMERATED {
	oneTimeEvent	(0),
	multipleTimeEvent	(1),
	...}

IntervalTime ::= INTEGER (1..32767)
	-- minimum interval time between area reports in seconds

PeriodicLDRInfo ::= SEQUENCE {
	reportingAmount	ReportingAmount,
	reportingInterval	ReportingInterval,
	...}
-- reportingInterval x reportingAmount shall not exceed 8639999 (99 days, 23 hours,
-- 59 minutes and 59 seconds) for compatibility with OMA MLP and RLP

ReportingAmount ::= INTEGER (1..maxReportingAmount)

maxReportingAmount INTEGER ::= 8639999

ReportingInterval ::= INTEGER (1..maxReportingInterval)
-- ReportingInterval is in seconds

maxReportingInterval INTEGER ::= 8639999

ReportingPLMNList::= SEQUENCE {
	plmn-ListPrioritized	[0] NULL		OPTIONAL,
	plmn-List		[1] PLMNList,
	...}

PLMNList::= SEQUENCE SIZE (1..maxNumOfReportingPLMN) OF
	ReportingPLMN

maxNumOfReportingPLMN INTEGER ::= 20

ReportingPLMN::= SEQUENCE {
	plmn-Id		[0] PLMN-Id,
	ran-Technology		[1] RAN-Technology	OPTIONAL,
	ran-PeriodicLocationSupport	[2] NULL		OPTIONAL,
	...}

RAN-Technology ::= ENUMERATED {
	gsm	(0),
	umts	(1),
	...}

ProvideSubscriberLocation-Res ::= SEQUENCE {
	locationEstimate	Ext-GeographicalInformation,
	ageOfLocationEstimate	[0] AgeOfLocationInformation	OPTIONAL,
	extensionContainer	[1] ExtensionContainer	OPTIONAL,
	... ,
	add-LocationEstimate	[2] Add-GeographicalInformation	OPTIONAL,
	deferredmt-lrResponseIndicator	[3] NULL	OPTIONAL,
	geranPositioningData	[4] PositioningDataInformation	OPTIONAL,
	utranPositioningData	[5] UtranPositioningDataInfo	OPTIONAL,
	cellIdOrSai	[6] CellGlobalIdOrServiceAreaIdOrLAI	OPTIONAL,
	sai-Present	[7] NULL	OPTIONAL,
	accuracyFulfilmentIndicator	[8] AccuracyFulfilmentIndicator	OPTIONAL,
	velocityEstimate	[9] VelocityEstimate	OPTIONAL,
	mo-lrShortCircuitIndicator	[10] NULL	OPTIONAL,
	geranGANSSpositioningData	[11] GeranGANSSpositioningData	OPTIONAL,
	utranGANSSpositioningData	[12] UtranGANSSpositioningData	OPTIONAL,	targetServingNodeForHandover	[13] ServingNodeAddress	OPTIONAL,
	utranAdditionalPositioningData	[14] UtranAdditionalPositioningData	OPTIONAL,
	utranBaroPressureMeas	[15] UtranBaroPressureMeas	OPTIONAL,
	utranCivicAddress	[16] UtranCivicAddress	OPTIONAL }

--	if deferredmt-lrResponseIndicator is set, locationEstimate is ignored.

-- the add-LocationEstimate parameter shall not be sent to a node that did not indicate the
-- geographic shapes supported in the ProvideSubscriberLocation-Arg
-- The locationEstimate and the add-locationEstimate parameters shall not be sent if
-- the supportedGADShapes parameter has been received in ProvideSubscriberLocation-Arg
-- and the shape encoded in locationEstimate or add-LocationEstimate is not marked
-- as supported in supportedGADShapes. In such a case ProvideSubscriberLocation
-- shall be rejected with error FacilityNotSupported with additional indication
-- shapeOfLocationEstimateNotSupported.
-- sai-Present indicates that the cellIdOrSai parameter contains a Service Area Identity.

AccuracyFulfilmentIndicator ::= ENUMERATED {
	requestedAccuracyFulfilled  (0),
	requestedAccuracyNotFulfilled  (1),
	...	}

Ext-GeographicalInformation ::= OCTET STRING (SIZE (1..maxExt-GeographicalInformation))
	-- Refers to geographical Information defined in 3GPP TS 23.032.
	-- This is composed of 1 or more octets with an internal structure according to
	-- 3GPP TS 23.032
	-- Octet 1: Type of shape, only the following shapes in 3GPP TS 23.032 are allowed:
	--	(a) Ellipsoid point with uncertainty circle
	--	(b) Ellipsoid point with uncertainty ellipse
	--	(c) Ellipsoid point with altitude and uncertainty ellipsoid
	--	(d) Ellipsoid Arc
	--	(e) Ellipsoid Point
	-- Any other value in octet 1 shall be treated as invalid
	-- Octets 2 to 8 for case (a) – Ellipsoid point with uncertainty circle
	--	Degrees of Latitude	3 octets
	--	Degrees of Longitude	3 octets
	--	Uncertainty code	1 octet
	-- Octets 2 to 11 for case (b) – Ellipsoid point with uncertainty ellipse:
	--	Degrees of Latitude	3 octets
	--	Degrees of Longitude	3 octets
	--	Uncertainty semi-major axis	1 octet
	--	Uncertainty semi-minor axis	1 octet
	--	Angle of major axis	1 octet
	--	Confidence	1 octet
	-- Octets 2 to 14 for case (c) – Ellipsoid point with altitude and uncertainty ellipsoid
	--	Degrees of Latitude	3 octets
	--	Degrees of Longitude	3 octets
	--	Altitude	2 octets
	--	Uncertainty semi-major axis	1 octet
	--	Uncertainty semi-minor axis	1 octet
	--	Angle of major axis	1 octet
	--	Uncertainty altitude	1 octet
	--	Confidence	1 octet
	-- Octets 2 to 13 for case (d) – Ellipsoid Arc
	--	Degrees of Latitude	3 octets
	--	Degrees of Longitude	3 octets
	--	Inner radius	2 octets
	--	Uncertainty radius	1 octet
	--	Offset angle	1 octet
	--	Included angle	1 octet
	--	Confidence	1 octet
	-- Octets 2 to 7 for case (e) – Ellipsoid Point
	--	Degrees of Latitude	3 octets
	--	Degrees of Longitude	3 octets

	--
	-- An Ext-GeographicalInformation parameter comprising more than one octet and
	-- containing any other shape or an incorrect number of octets or coding according
	-- to 3GPP TS 23.032 shall be treated as invalid data by a receiver.
	--
	-- An Ext-GeographicalInformation parameter comprising one octet shall be discarded
	-- by the receiver if an Add-GeographicalInformation parameter is received 
	-- in the same message.
	--
	-- An Ext-GeographicalInformation parameter comprising one octet shall be treated as
	-- invalid data by the receiver if an Add-GeographicalInformation parameter is not
	-- received in the same message.

maxExt-GeographicalInformation  INTEGER ::= 20
	-- the maximum length allows for further shapes in 3GPP TS 23.032 to be included in later 
	-- versions of 3GPP TS 29.002

VelocityEstimate ::= OCTET STRING (SIZE (4..7))
	-- Refers to Velocity description defined in 3GPP TS 23.032.
	-- This is composed of 4 or more octets with an internal structure according to
	-- 3GPP TS 23.032
	-- Octet 1: Type of velocity, only the following types in 3GPP TS 23.032 are allowed:
	--	(a) Horizontal Velocity
	--	(b) Horizontal with Vertical Velocity
	--	(c) Horizontal Velocity with Uncertainty
	--	(d) Horizontal with Vertical Velocity and Uncertainty
	-- For types Horizontal with Vertical Velocity and Horizontal with Vertical Velocity
	-- and Uncertainty, the direction of the Vertical Speed is also included in Octet 1
	-- Any other value in octet 1 shall be treated as invalid
	-- Octets 2 to 4 for case (a) Horizontal velocity:
	--	Bearing	1 octet
	--	Horizontal Speed	2 octets
	-- Octets 2 to 5 for case (b) – Horizontal with Vertical Velocity:
	--	Bearing	1 octet
	--	Horizontal Speed	2 octets
	--	Vertical Speed	1 octet
	-- Octets 2 to 5 for case (c) – Horizontal velocity with Uncertainty:
	--	Bearing	1 octet
	--	Horizontal Speed	2 octets
	--	Uncertainty Speed	1 octet
	-- Octets 2 to 7 for case (d) – Horizontal with Vertical Velocity and Uncertainty:
	--	Bearing	1 octet
	--	Horizontal Speed	2 octets
	--	Vertical Speed	1 octet
	--	Horizontal Uncertainty Speed	1 octet
	--	Vertical Uncertainty Speed	1 octet

PositioningDataInformation ::= OCTET STRING (SIZE (2..maxPositioningDataInformation))
	-- Refers to the Positioning Data defined in 3GPP TS 49.031.
	-- This is composed of 2 or more octets with an internal structure according to
	-- 3GPP TS 49.031. 

maxPositioningDataInformation INTEGER ::= 10
	-- 

UtranPositioningDataInfo ::= OCTET STRING (SIZE (3..maxUtranPositioningDataInfo))
	-- Refers to the Position Data defined in 3GPP TS 25.413.
	-- This is composed of the positioningDataDiscriminator and the positioningDataSet
	-- included in positionData as defined in 3GPP TS 25.413.

maxUtranPositioningDataInfo INTEGER ::= 11
	-- 

GeranGANSSpositioningData ::= OCTET STRING (SIZE (2..maxGeranGANSSpositioningData))
	-- Refers to the GANSS Positioning Data defined in 3GPP TS 49.031.
	-- This is composed of 2 or more octets with an internal structure according to
	-- 3GPP TS 49.031. 

maxGeranGANSSpositioningData INTEGER ::= 10
	-- 

UtranGANSSpositioningData ::= OCTET STRING (SIZE (1..maxUtranGANSSpositioningData))
	-- Refers to the Position Data defined in 3GPP TS 25.413.
	-- This is composed of the GANSS-PositioningDataSet only, included in PositionData
     -- as defined in 3GPP TS 25.413.

maxUtranGANSSpositioningData INTEGER ::= 9
	-- 

UtranAdditionalPositioningData ::= OCTET STRING (SIZE (1..maxUtranAdditionalPositioningData))
	-- Refers to the Position Data defined in 3GPP TS 25.413.
	-- This is composed of the Additional-PositioningDataSet only, included in PositionData
	-- as defined in 3GPP TS 25.413.

maxUtranAdditionalPositioningData INTEGER ::= 8
	-- 

UtranBaroPressureMeas ::= INTEGER (30000..115000)
	-- Refers to the barometric pressure measurement defined in 3GPP TS 25.413.
	-- This is composed of the BarometricPressureMeasurement only as defined in 3GPP TS
	-- 25.413. 

UtranCivicAddress ::= OCTET STRING 
	-- Refers to the civic address defined in 3GPP TS 25.413.
	-- This is composed of the CivicAddress only as defined in 3GPP TS 25.413.

Add-GeographicalInformation ::= OCTET STRING (SIZE (1..maxAdd-GeographicalInformation))
	-- Refers to geographical Information defined in 3GPP TS 23.032.
	-- This is composed of 1 or more octets with an internal structure according to 
	-- 3GPP TS 23.032
	-- Octet 1: Type of shape, all the shapes defined in 3GPP TS 23.032 are allowed:
	-- Octets 2 to n (where n is the total number of octets necessary to encode the shape
	-- according to 3GPP TS 23.032) are used to encode the shape itself in accordance with the
	-- encoding defined in 3GPP TS 23.032
	--
	-- An Add-GeographicalInformation parameter, whether valid or invalid, received 
	-- together with a valid Ext-GeographicalInformation parameter in the same message 
	-- shall be discarded.
	--
	-- An Add-GeographicalInformation parameter containing any shape not defined in 
	-- 3GPP TS 23.032 or an incorrect number of octets or coding according to 
	-- 3GPP TS 23.032 shall be treated as invalid data by a receiver if not received 
	-- together with a valid Ext-GeographicalInformation parameter in the same message.

maxAdd-GeographicalInformation  INTEGER ::= 91
	-- the maximum length allows support for all the shapes currently defined in 3GPP TS 23.032

SubscriberLocationReport-Arg ::= SEQUENCE {
	lcs-Event	LCS-Event,
	lcs-ClientID	LCS-ClientID, 
	lcsLocationInfo	LCSLocationInfo,
	msisdn	[0] ISDN-AddressString	OPTIONAL,
	imsi	[1] IMSI	OPTIONAL,
	imei	[2] IMEI	OPTIONAL,
	na-ESRD	[3] ISDN-AddressString	OPTIONAL,
	na-ESRK	[4] ISDN-AddressString	OPTIONAL,
	locationEstimate	[5] Ext-GeographicalInformation	OPTIONAL,
	ageOfLocationEstimate	[6] AgeOfLocationInformation	OPTIONAL,
	slr-ArgExtensionContainer	[7] SLR-ArgExtensionContainer	OPTIONAL,
	... ,
	add-LocationEstimate	[8] Add-GeographicalInformation	OPTIONAL,
	deferredmt-lrData	[9] Deferredmt-lrData	OPTIONAL, 
	lcs-ReferenceNumber	[10] LCS-ReferenceNumber	OPTIONAL,
	geranPositioningData	[11] PositioningDataInformation	OPTIONAL,
	utranPositioningData	[12] UtranPositioningDataInfo	OPTIONAL,
	cellIdOrSai	[13]	CellGlobalIdOrServiceAreaIdOrLAI	OPTIONAL,
	h-gmlc-Address	[14]	GSN-Address	OPTIONAL,
	lcsServiceTypeID	[15]	LCSServiceTypeID	OPTIONAL,
	sai-Present	[17] NULL	OPTIONAL,
	pseudonymIndicator	[18] NULL	OPTIONAL,
	accuracyFulfilmentIndicator	[19] AccuracyFulfilmentIndicator	OPTIONAL,
	velocityEstimate	[20] VelocityEstimate	OPTIONAL,
	sequenceNumber	[21] SequenceNumber	OPTIONAL,
	periodicLDRInfo	[22] PeriodicLDRInfo	OPTIONAL,
	mo-lrShortCircuitIndicator	[23] NULL	OPTIONAL,
	geranGANSSpositioningData	[24] GeranGANSSpositioningData	OPTIONAL,
	utranGANSSpositioningData	[25] UtranGANSSpositioningData	OPTIONAL,
	targetServingNodeForHandover	[26] ServingNodeAddress	OPTIONAL,
	utranAdditionalPositioningData	[27] UtranAdditionalPositioningData	OPTIONAL,
	utranBaroPressureMeas	[28] UtranBaroPressureMeas	OPTIONAL,
	utranCivicAddress	[29] UtranCivicAddress	OPTIONAL }

	-- one of msisdn or imsi is mandatory
	-- a location estimate that is valid for the locationEstimate parameter should 
	-- be transferred in this parameter in preference to the add-LocationEstimate.
	-- the deferredmt-lrData parameter shall be included if and only if the lcs-Event
	-- indicates a deferredmt-lrResponse.
	-- if the lcs-Event indicates a deferredmt-lrResponse then the locationEstimate 
	-- and the add-locationEstimate parameters shall not be sent if the 
	-- supportedGADShapes parameter had been received in ProvideSubscriberLocation-Arg
	-- and the shape encoded in locationEstimate or add-LocationEstimate was not marked
	-- as supported in supportedGADShapes. In such a case terminationCause 
	-- in deferredmt-lrData shall be present with value 
	-- shapeOfLocationEstimateNotSupported. 
	-- If a lcs event indicates deferred mt-lr response, the lcs-Reference number shall be 
	-- included. 
	-- sai-Present indicates that the cellIdOrSai parameter contains a Service Area Identity.

Deferredmt-lrData ::= SEQUENCE {
	deferredLocationEventType	DeferredLocationEventType,
	terminationCause	[0] TerminationCause	OPTIONAL,
	lcsLocationInfo	[1] LCSLocationInfo	OPTIONAL,
	...}
	-- lcsLocationInfo may be included only if a terminationCause is present 
	-- indicating mt-lrRestart.

LCS-Event ::= ENUMERATED {
	emergencyCallOrigination  (0),
	emergencyCallRelease  (1), 
	mo-lr  (2),
	...,
	deferredmt-lrResponse  (3) ,
	deferredmo-lrTTTPInitiation  (4),
	emergencyCallHandover (5)  }
	--	deferredmt-lrResponse is applicable to the delivery of a location estimate 
	--	for an LDR initiated earlier by either the network (via an MT-LR activate deferred 
	--	location) or the UE (via a deferred MO-LR TTTP initiation)
	--	exception handling:
	--	a SubscriberLocationReport-Arg containing an unrecognized LCS-Event
	--	shall be rejected by a receiver with a return error cause of unexpected data value

TerminationCause ::= ENUMERATED {
	normal  (0),
	errorundefined  (1),
	internalTimeout  (2),
	congestion  (3),
	mt-lrRestart  (4),
	privacyViolation  (5),
	...,
	shapeOfLocationEstimateNotSupported (6) ,
	subscriberTermination (7),
	uETermination (8),
	networkTermination (9)  } 
-- mt-lrRestart shall be used to trigger the GMLC to restart the location procedure, 
-- either because the sending node knows that the terminal has moved under coverage 
-- of another MSC or SGSN (e.g. Send Identification received), or because the subscriber
-- has been deregistered due to a Cancel Location received from HLR.
--
-- exception handling
-- an unrecognized value shall be treated the same as value 1 (errorundefined) 

SequenceNumber ::= INTEGER (1..maxReportingAmount)

ServingNodeAddress ::= CHOICE {
	msc-Number	[0] ISDN-AddressString,
	sgsn-Number	[1] ISDN-AddressString,
	mme-Number	[2] DiameterIdentity }

SubscriberLocationReport-Res ::= SEQUENCE {
	extensionContainer	ExtensionContainer	OPTIONAL, 
	..., 
	na-ESRK	[0] ISDN-AddressString	OPTIONAL,
	na-ESRD	[1] ISDN-AddressString	OPTIONAL,
	h-gmlc-Address	[2]	GSN-Address	OPTIONAL,
	mo-lrShortCircuitIndicator	[3] NULL	OPTIONAL,
	reportingPLMNList	[4] ReportingPLMNList	OPTIONAL,
	lcs-ReferenceNumber	[5]	LCS-ReferenceNumber	OPTIONAL }

-- na-ESRK and na-ESRD are mutually exclusive
--
-- exception handling
-- receipt of both na-ESRK and na-ESRD shall be treated the same as a return error


.#END
17.7.14	Void

18	General on MAP user procedures
18.1	Introduction
Clauses 18 to 25 describe the use of MAP services for GSM signalling procedures. GSM signalling procedures may involve one or several interfaces running one or several application protocols. The present document addresses only the signalling procedures which require at least the use of one MAP service.
When a signalling procedure takes place in the network, an application process invocation is created in each system component involved. Part of the application process invocation acts as a MAP user and handles one or several MAP dialogues. For each dialogue it employs an instance of the MAP service provider. It may also use other communication services to exchange information on other interfaces, but detailed description of these aspects is outside the scope of the present document.
18.2	Common aspects of user procedure descriptions
18.2.1	General conventions
For each signalling procedure the present document provides a brief textual overview accompanied by a flow diagram which represent the functional interactions between system components. Functional interactions are labelled using the MAP service name when the interaction results from a service request or by this service name followed by the symbol "ack" when this interaction results from a service response.
For each of the system components involved, the present document also provides a detailed textual description of the application process behaviour as well as an SDL diagram. SDL diagrams describe the sequence of events, as seen by the MAP-User, which occurs at MAP service provider boundaries as well as external events which occur at other interfaces and which impact on the previous sequence.
External events do not necessarily correspond to the messages of other protocols used in the system component. The MAP-user procedures are described as if a set of interworking functions (IWF) between the MAP-user and the other protocol entities was implemented (see figure 18.2/1). Such interworking functions are assumed to perform either an identity mapping or some processing or translation as required to eliminate information irrelevant to the MAP-user.
The mapping of service primitives on to protocol elements is described in clauses 14 to 17.
GSM signalling procedures are built from one or more sub-procedures (e.g. authentication, ciphering, ...). Sub‑procedures from which signalling procedures are built are represented using SDL MACRO descriptions.
In case of any discrepancy between the textual descriptions and the SDL descriptions, the latter take precedence.
18.2.2	Naming conventions
Events related to MAP are represented by MAP service primitives. The signal names used in the SDL diagrams are derived from the service primitive names defined in clauses 7 to 12, with some lexical transformations for readability and parsability purposes (blanks between words are replaced by underscores, the first letter of each word is capitalised).
Events received and sent on other interfaces are named by appending the message or signal name to a symbol representing the interface type, with some lexical transformations for readability and parsability purposes (blanks between words are replaced by underscores, the first letter of each word is capitalised).
The following symbols are used to represent the interface types:
"I":	For interfaces to the fixed network. "I" stands for ISUP interface.
"A":	For interfaces between the MSC and the BSS (i.e. A-interfaces);
"Gb":	For interfaces between the SGSN and the BSS (i.e. Gb-interfaces);
"OM":	For network management interfaces (communication with OMC, MML interface, ...);
"SC":	For interfaces to a Service Centre;
"HO_CA":	For internal interfaces to the Handover Control Application.
"US":	For a local USSD application.
These naming conventions can be summarised by the following BNF description:
<Event_Name>	::= <MAP_Primitive> | <External_Event>
<MAP_Primitive>	::= <MAP_Open> | <MAP_Close> | <MAP_U_Abort> | <MAP_P_Abort> |
	  	<MAP_Specific> | <MAP_Notice>
<MAP_Open>	::= MAP_Open_Req | MAP_Open_Ind | MAP_Open_Rsp | MAP_Open_Cnf
<MAP_Close>	::= MAP_Close_Req | MAP_Close_Ind
<MAP_U_Abort>	::= MAP_U_Abort_Req | MAP_U_Abort_Ind
<MAP_P_Abort>	::= MAP_P_Abort_Ind
<MAP_Notice>	::= MAP_Notice_Ind
<MAP_Specific>	::= <MAP_Req> | <MAP_Ind> | <MAP_Rsp> | <MAP_Cnf>
<MAP_Req>	::= MAP_<Service_Name>_Req
<MAP_Ind>	::= MAP_<Service_Name>_Ind
<MAP_Rsp>	::= MAP_<Service_Name>_Rsp
<MAP_Cnf>	::= MAP_<Service_Name>_Cnf
<External_Event>	::= <Interface_Type>_<External_Signal>
<Interface_Type>	::= I | A | Gb | OM | SC | HO AC | US
<External_Signal>	::= <Lexical_Unit>
<Service_Name>	::= <Lexical_Unit>
<Lexical_Unit>	::= <Lexical_Component> | <Lexical_Unit>_ <Lexical_Component>
<Lexical_Component>	::= <Upper_Case_Letter><Letter_Or_Digit_List>
<Letter_Or_Digit_List>	::= <Letter_Or_Digit> | <Letter_Or_Digit_List><Letter_Or_Digit>
<Letter_Or_Digit>	::= <Letter> | <Digit>
<Letter>		::= <Lower_Case_Letter> | <Upper_Case_Letter>
<Upper_Case_Letter>	::= A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z
<Lower_Case_Letter>	::= a|b|c|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r|s|t|u|v|w|x|y|z
<Digit>		::= 1|2|3|4|5|6|7|8|9|0
Figure 18.2/1: Interfaces applicable to the MAP-User
18.2.3	Convention on primitives parameters
18.2.3.1	Open service
When the originating and destination reference parameters shall be included in the MAP-OPEN request primitive, their value are indicated as a comment to the signal which represents this primitive.
18.2.3.2	Close service
When a pre-arranged released is requested, a comment is attached to the signal which represents the MAP-CLOSE request primitive. In the absence of comment, a normal release is assumed.
18.2.4	Version handling at dialogue establishment
Unless explicitly indicated in subsequent clauses, the following principles regarding version handling procedures at dialogue establishment are applied by the MAP-user.
18.2.4.1	Behaviour at the initiating side
When a MAP user signalling procedure has to be executed, the MAP-user issues a MAP-OPEN request primitive with an appropriate application-context-name. If several names are supported (i.e. several versions) a suitable one is selected using the procedures described in clause 5.
 
If version n is selected (where 1 < n <= highest existing version) and a MAP-OPEN Confirm primitive is received in response to the MAP-OPEN request with a result parameter set to "refused" and a diagnostic parameter indicating "application context not supported" or "potential version incompatibility problem", the MAP-User issues a new MAP-OPEN request primitive with the equivalent version y context (where 1 <= y < n). This is informally represented in the SDL diagrams by task symbols indicating 'Perform Vr procedure".
18.2.4.2	Behaviour at the responding side
On receipt of a MAP-OPEN indication primitive, the MAP-User analyses the application-context-name and executes the procedure associated with the requested version context. For example,if it refers to a version one context, the associated V1 procedure is executed; if it refers to a version two context, the associated V2 procedure is executed;etc.
18.2.5	Abort Handling
Unless explicitly indicated in subsequent clauses, the following principles are applied by the MAP-user regarding abort handling procedures:
On receipt of a MAP-P-ABORT indication or MAP-U-ABORT Indication primitive from any MAP-provider invocation, the MAP-User issues a MAP-U-ABORT Request primitive to each MAP-provider invocation associated with the same user procedure.
If applicable a decision is made to decide if the affected user procedure has to be retried or not.
18.2.6	SDL conventions
The MAP SDLs make use of a number of SDL concepts and conventions, where not all of them may be widely known. Therefore, this clause outlines the use of a few concepts and conventions to improve understanding of the MAP SDLs.
The MAP User SDLs make use of SDL Processes, Procedures and Macros. Processes are independent from each other even if one process starts another one: The actions of both of them have no ordering in time. SDL Procedures and Macros are just used to ease writing of the specification: They contain parts of a behaviour used in several places, and the corresponding Procedure/Macro definition has to be expanded at the position of the Procedure/Macro call.
All Processes are started at system initialisation and live forever, unless process creation/termination is indicated explicitly (i.e. a process is created by some other process).
The direction of Input/Output Signals in the SDL graphs is used to indicate the entity to which/from which communication is directed. If a process A communicates in parallel with processes B and C, all Inputs/Outputs to/from B are directed to one side, whereas communication with C is directed to the other side. However, there has been no formal convention used that communication to a certain entity (e.g. a HLR) will always be directed to a certain side (e.g. right).
In each state all those Input Signals are listed, which result in an action and/or state change. If an Input Signal is not listed in a state, receipt of this input should lead to an implicit consumption without any action or state change (according to the SDL rules). This implicit consumption is mainly used for receipt of the MAP DELIMITER indication and for receipt of a MAP CLOSE indication, except for a premature MAP CLOSE.
18.3	Interaction between MAP Provider and MAP Users
Each MAP User is defined by at least one SDL process. On the dialogue initiating side, the MAP User will create a new instance of a MAP Provider implicit by issuing a MAP-OPEN request. This instance corresponds to a TC Dialogue and lives as long as the dialogue exists (see also clause 14.3). There is a fixed relation between MAP User and this Provider instance, i.e. all MAP service primitives from the MAP User for this dialogue are sent to this instance and all TC components received by this MAP Provider are mapped onto service primitives sent to this MAP User.
On the receiving side a MAP Provider instance is created implicit by receipt of a TC BEGIN indication. The corresponding MAP User is determined by the Application Context name included in this primitive, i.e. each Application Context is associated with one and only one MAP User. An instance of this User will be created implicitly by receiving a MAP-OPEN indication. Note that in some cases there exist several SDL Processes for one MAP User (Application Context), e.g. the processes Register_SS_HLR, Erase_SS_HLR, Activate_SS_HLR, Deactivate_SS_HLR, Interrogate_SS_HLR, and Register_Password for the AC Network_Functional_SS_Handling. In these cases, a coordinator process is introduced acting as a MAP User, which in turn starts a sub-process depending on the first MAP service primitive received.
19	Mobility procedures
19.1	Location management Procedures
The signalling procedures in this clause support:
-	Interworking between the VLR and the HLR and between the VLR and the previous VLR (PVLR) when a non-GPRS subscriber performs a location update to a new VLR service area;
-	Interworking between the SGSN, the HLR and the VLR when a subscriber with both GPRS and non-GPRS subscriptions performs a routeing area update in an SGSN and the Gs interface is implemented;
-	Interworking between the SGSN and the VLR when a GPRS subscriber performs a routeing area update to a new SGSN service area;
-	Interworking between the HLR and the VLR and between the HLR and the SGSN to delete a subscriber record from the VLR or the SGSN;
-	Interworking between the VLR and the HLR and between the SGSN and the HLR to report to the HLR that a subscriber record has been purged from the VLR or the SGSN.
The MAP co-ordinating process in the HLR to handle a dialogue opened with the network location updating context is shown in figure 19.1/1. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind	see clause 25.1.1.

Figure 19.1/1: Process Location_Management_Coordinator_HLR
19.1.1	Location updating
19.1.1.1	General
The stage 2 specification for GPRS is in 3GPP TS 23.060 [104]. The interworking between the MAP signalling procedures and the GPRS procedures in the SGSN and the HLR is shown by the transfer of signals between these procedures.
The message flow for successful inter-VLR location updating when the IMSI can be retrieved from the PVLR is shown in figure 19.1.1/2.
The message flow for successful inter-VLR location updating when the IMSI cannot be retrieved from the PVLR is shown in figure 19.1.1/3.
The message flow for successful GPRS Attach/RA update procedure (Gs interface not installed) is shown in figure 19.1.1/4.
The message flow for successful GPRS Attach/RA update procedure combined with a successful VLR location updating (Gs interface installed) is shown in figure 19.1.1/5.

PVLR = Previous VLR

1)	A_LU_REQUEST (Note 1)
2)	MAP_SEND_IDENTIFICATION_req/ind
3)	MAP_SEND_IDENTIFICATION_rsp/cnf
4)	MAP_UPDATE_LOCATION_req/ind
5)	MAP_CANCEL_LOCATION_req/ind
6)	MAP_CANCEL_LOCATION_rsp/cnf
7)	MAP_ACTIVATE_TRACE_MODE_req/ind (Note 2)
8)	MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 2)
9)	MAP_INSERT_SUBSCRIBER_DATA_req/ind
10)	MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf
11)	MAP_UPDATE_LOCATION_rsp/cnf
12)	A_LU_CONFIRM (Note 1)

NOTE 1:	For details of the procedure on the radio path, see 3GPP TS 24.008 [35]. Services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path.
NOTE 2:	Services printed in italics are optional.

Figure 19.1.1/2: Message flow for location updating to a new VLR area,
when the IMSI can be retrieved from the previous VLR


PVLR = Previous VLR

1)	A_LU_REQUEST (Note 1)
2)	A_IDENTITY_REQUEST (Note 1)
3)	A_IDENTITY_RESPONSE (Note 1)
4)	MAP_UPDATE_LOCATION_req/ind
5)	MAP_CANCEL_LOCATION_req/ind
6)	MAP_CANCEL_LOCATION_rsp/cnf
7)	MAP_ACTIVATE_TRACE_MODE_req/ind (Note 2)
8)	MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 2)
9)	MAP_INSERT_SUBSCRIBER_DATA_req/ind
10)	MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf
11)	MAP_UPDATE_LOCATION_rsp/cnf
12)	A_LU_CONFIRM (Note 1)

NOTE 1:	For details of the procedure on the radio path, see 3GPP TS 24.008 [35]. Services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path.
NOTE 2:	Services printed in italics are optional.

Figure 19.1.1/3: Message flow for location updating to a new VLR area,
when the IMSI cannot be retrieved from the previous VLR

PSGSN = Previous SGSN

1)	Gb_ATTACH_REQUEST or RA_UPDATE_REQUEST (Note 1, note 2)
2)	MAP_UPDATE_GPRS_LOCATION_req/ind
3)	MAP_CANCEL_LOCATION_req/ind
4)	MAP_CANCEL_LOCATION_rsp/cnf
5)	MAP_ACTIVATE_TRACE_MODE_req/ind (Note 3)
6)	MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 3)
7)	MAP_INSERT_SUBSCRIBER_DATA_req/ind
8)	MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf
9)	MAP_UPDATE_GPRS_LOCATION_rsp/cnf
10)	Gb_ATTACH_ACCEPT or RA_UPDATE_ACCEPT (Note 1)

NOTE 1:	For details of the procedure on the radio path, see 3GPP TS 24.008 [35]. The services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path.
NOTE 2:	For security functions (authentication, ciphering, IMEI check) triggering refer to 3GPP TS 23.060 [104]. The MAP signalling invoked for these functions is described in clause 25 of the present document.
NOTE 3:	Services printed in italics are optional.
NOTE 4:	Refer to 3GPP TS 23.060 [104] for termination of the procedure and triggering of the signalling on the interface between the BSS and the SGSN.

Figure 19.1.1/4: Message flow for GPRS location updating (Gs interface not installed)


1)	Gb_ATTACH_REQUEST or RA_UPDATE_REQUEST (Note 1, note 2)
2)	MAP_UPDATE_GPRS_LOCATION_req/ind
3)	MAP_CANCEL_LOCATION_req/ind
4)	MAP_CANCEL_LOCATION_rsp/cnf
5)	MAP_ACTIVATE_TRACE_MODE_req/ind (Note 3)
6)	MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 3)
7)	MAP_INSERT_SUBSCRIBER_DATA_req/ind
8)	MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf
9)	MAP_UPDATE_GPRS_LOCATION_rsp/cnf
10)	Gs_LOCATION_UPDATE_REQUEST (Note 4)
11)	MAP_UPDATE_LOCATION_req/ind (Note 5)
12)	MAP_INSERT_SUBSCRIBER_DATA_req/ind
13)	MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf
14)	MAP_UPDATE_LOCATION_rsp/cnf
15)	Gs_LOCATION_UPDATE_ACCEPT (Note 4)
16)	Gb_ATTACH_ACCEPT or RA_UPDATE_ACCEPT (Note 1)
17)	Gb_TMSI_REALLOCATION_COMPLETE (Note 1)
18)	Gs_TMSI_REALLOCATION_COMPLETE (Note 4)

NOTE 1:	For details of the procedure on the radio path, see 3GPP TS 24.008 [35]. The services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path.
NOTE 2:	For security functions (authentication, ciphering, IMEI check) triggering refer to 3GPP TS 23.060 [104]. MAP processes invoked for those procedures are described in clause 25.5.
NOTE 3:	Services printed in italics are optional.
NOTE 5:	For details of the procedure on the path between the SGSN and the VLR, see 3GPP TS 29.018 [106]. The services shown in chain lines indicate the trigger provided by the signalling on the path between the SGSN and the VLR, and the signalling triggered on the path between the SGSN and the VLR.
NOTE 4:	Refer to 3GPP TS 23.060 [104] for termination of the procedure and triggering of the signalling on the interface between the BSS and the SGSN.
NOTE 5:	For simplicity, the Location Cancellation procedure towards the previous VLR and optional tracing activation towards the new VLR are not shown in this figure.

Figure 19.1.1/5: Message flow for GPRS location updating (Gs interface installed)
19.1.1.2	Procedures in the VLR
The MAP process in the VLR for location updating for a non-GPRS subscriber is shown in figure 19.1.1/6. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2.
The MAP process in the VLR to retrieve the IMSI of a subscriber from the previous VLR (PVLR) is shown in figure 19.1.1/7. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2.
The process in the VLR for location updating for a GPRS subscriber when the Gs interface is installed is shown in figure 19.1.1/8. 
The macro GPRS_Location_Update_Completion_VLR is shown in figure 19.1.1/9. The macro invokes a process not defined in this clause; the definition of this process can be found as follows:
Subscriber_Present_VLR	see clause 25.10.1.
The macro GPRS_Update_HLR_VLR is shown in figure 19.1.1/10. The macro invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2;
Insert_Subs_Data_VLR		see clause 25.7.1;
Activate_Tracing_VLR		see clause 25.9.4.
19.1.1.3	Procedure in the PVLR
The MAP process in the PVLR to handle a request for the IMSI of a subscriber from the new VLR is shown in figure 19.1.1/11. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind		see clause 25.1.1.
19.1.1.4	Procedure in the SGSN
The MAP process in the SGSN for location updating for a GPRS subscriber is shown in figure 19.1.1/12. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2;
Insert_Subs_Data_SGSN	see clause 25.7.2;
Activate_Tracing_SGSN	see clause 25.9.5.
Sheet 2: The procedure Check_User_Error_In_Serving_Network_Entity is specific to Super-Charger; it is specified in 3GPP TS 23.116 [110].
19.1.1.5	Procedures in the HLR
The MAP process in the HLR to handle a location updating request from a VLR is shown in figure 19.1.1/13. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Check_Confirmation		see clause 25.2.2.
The MAP process in the HLR to handle a location updating request from an SGSN is shown in figure 19.1.1/14. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind		see clause 25.1.1;
Check_Indication		see clause 25.2.1;
Check_Confirmation		see clause 25.2.2;
Control_Tracing_With_SGSN_HLR	see clause 25.9.7.
Sheet 2: The procedure Super_Charged_Cancel_Location_HLR is specific to Super-Charger; it is specified in 3GPP TS 23.116 [110]. If the HLR does not support the Super-Charger functionality, processing continues from the "No" exit of the test "Result=Pass?".
Sheet 2: The procedure Super_Charged_Location_Updating_HLR is specific to Super-Charger; it is specified in 3GPP TS 23.116 [110]. If the HLR does not support the Super-Charger functionality, processing continues from the "No" exit of the test "Result=Pass?". 
Sheet 2: If the HLR supports the Administrative Restriction of Subscribers' Access feature and roaming is allowed in the VPLMN then the HLR may check the "Supported RAT Types" received from the VLR against the access restriction parameters. If this check fails then the decision box "Roaming allowed in this PLMN" shall take the exit "No".
The MAP process in the HLR to notify Short Message Service Centres that a subscriber is now reachable is shown in figure 19.1.1/15. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Alert_Service_Centre_HLR	see clause 25.10.3.


Figure 19.1.1/6 (sheet 1 of 2): Process Update_Location_VLR

Figure 19.1.1/6 (sheet 2 of 2): Process Update_Location_VLR 

Figure 19.1.1/7 (sheet 1 of 2): Process Send_Identification_VLR

Figure 19.1.1/7 (sheet 2 of 2): Process Send_Identification_VLR

Figure 19.1.1/8 (sheet 1 of 2): Process GPRS_Update_Location_Area_VLR

Figure 19.1.1/8 (sheet 2 of 2): Process GPRS_Update_Location_Area_VLR

Figure 19.1.1/9: Macro GPRS_Location_Update_Completion_VLR

Figure 19.1.1/10 (sheet 1 of 2): Macro GPRS_Update_HLR_VLR

Figure 19.1.1/10 (sheet 2 of 2): Macro GPRS_Update_HLR_VLR

Figure 19.1.1/11 (sheet 1 of 2): Process Send_Identification_PVLR

Figure 19.1.1/11 (sheet 2 of 2): Process Send_Identification_PVLR

Figure 19.1.1/12 (sheet 1 of 2): Process Update_GPRS_Location_SGSN

Figure 19.1.1/12 (sheet 2 of 2): Process Update_GPRS_Location_SGSN

Figure 19.1.1/13 (sheet 1 of 3): Process Update_Location_HLR 

Figure 19.1.1/13 (sheet 2 of 3): Process Update_Location_HLR

Figure 19.1.1/13 (sheet 3 of 3): Process Update_Location_HLR

Figure 19.1.1/14 (sheet 1 of 2): Process Update_GPRS_Location_HLR

Figure 19.1.1/14 (sheet 2 of 2): Process Update_GPRS_Location_HLR

Figure 19.1.1/15: Process Subscriber_Present_HLR
19.1.1A	Location updating for VCSG
19.1.1A.1	General
The message flow for successful VCSG location updating between VLR and CSS or between SGSN and CSS is shown in figure 19.1.1A/1.

1)	MAP_UPDATE_VCSG_LOCATION_req/ind
2)	MAP_INSERT_SUBSCRIBER_DATA_req/ind
3)	MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf
4)	MAP_UPDATE_VCSG_LOCATION_rsp/cnf

Figure 19.1.1A/1: Message flow for VCSG location updating
19.1.1A.2	Procedures in the VLR
The MAP process in the VLR for VCSG location updating for a roaming subscriber is shown in figure 19.1.1A/2. 
The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2;
Insert_Subs_Data_VLR		see clause 25.7.2.
19.1.1A.3	Procedures in the SGSN
The MAP process in the SGSN for VCSG location updating for a roaming subscriber is shown in figure 19.1.1A/3. 
The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2;
Insert_Subs_Data_SGSN	see clause 25.7.2.
19.1.1A.4	Procedures in the CSS
The MAP process in the CSS to handle a VCSG location updating request from a VLR or SGSN is shown in figure 19.1.1A/4. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind		see clause 25.1.1;
Check_Indication		see clause 25.2.1;
Check_Confirmation		see clause 25.2.2;
Insert_VCSG_Subs_Data_Framed_CSS	see clause 19.5A.1.



Figure 19.1.1A/2 (sheet 1 of 2): Process Update_VCSG_Location_VLR

Figure 19.1.1A/2 (sheet 2 of 2): Process Update_VCSG_Location_VLR

Figure 19.1.1A/3 (sheet 1 of 2): Process Update_VCSG_Location_SGSN

Figure 19.1.1A/3 (sheet 2 of 2): Process Update_VCSG_Location_SGSN

Figure 19.1.1A/4 (sheet 1 of 2): Process Update_VCSG_Location_CSS

Figure 19.1.1A/4 (sheet 2 of 2): Process Update_VCSG_Location_CSS
19.1.2	Location Cancellation
19.1.2.1	General
Location cancellation is used to delete a subscriber record from the serving node (VLR or SGSN). The procedure is invoked:
-	because the subscriber has registered with a new serving node, or
-	because the HPLMN operator has decided to delete the subscriber record from the serving node, e.g. because the subscription has been withdrawn, or because roaming restrictions have been imposed. Location cancellation can be used to force location updating including updating of subscriber data in the serving node at the next subscriber access.
The message flow for location cancellation for a non-GPRS subscriber is shown in figure 19.1.2/1.
The message flow for location cancellation for a GPRS subscriber is shown in figure 19.1.2/2.


1)	MAP_UPDATE_LOCATION_req/ind
2)	MAP_CANCEL_LOCATION_req/ind
3)	MAP_CANCEL_LOCATION_rsp/cnf

NOTE:	The service shown in dotted lines indicates the trigger provided by other MAP signalling.

Figure 19.1.2/1: Message flow for Location Cancellation (non-GPRS)


1)	MAP_UPDATE_GPRS_LOCATION_req/ind
2)	MAP_CANCEL_LOCATION_req/ind
3)	MAP_CANCEL_LOCATION_rsp/cnf

NOTE:	The service shown in dotted lines indicates the trigger provided by other MAP signalling.

Figure 19.1.2/2: Message flow for Location Cancellation (GPRS)
19.1.2.2	Procedure in the HLR
The MAP process in the HLR to cancel the location information in a VLR is shown in figure 19.1.2/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2.
The MAP process in the HLR to cancel the location information in a VLR as an independent process invoked from another process is shown in figure 19.1.2/4.
The MAP process in the HLR to cancel the location information in an SGSN is shown in figure 19.1.2/5. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2.
The MAP process in the HLR to cancel the location information in an SGSN as an independent process invoked from another process is shown in figure 19.1.2/6.
19.1.2.3	Procedure in the VLR
The MAP process in the VLR to handle a location cancellation request is shown in figure 19.1.2/7. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind		see clause 25.1.1.
19.1.2.4	Procedure in the SGSN
The MAP process in the SGSN to handle a location cancellation request is shown in figure 19.1.2/8. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind		see clause 25.1.1.


Figure 19.1.2/3: Process Cancel_Location_HLR

Figure 19.1.2/4: Process Cancel_Location_Child_HLR

Figure 19.1.2/5: Process Cancel_GPRS_Location_HLR

Figure 19.1.2/6: Process Cancel_GPRS_Location_Child_HLR

Figure 19.1.2/7: Process Cancel_Location_VLR

Figure 19.1.2/8: Process Cancel_Location_SGSN
19.1.2A	Location Cancellation for VCSG
19.1.2A.1	General
Location cancellation for VCSG is used to delete a subscriber record from the serving node (VLR or SGSN). The procedure is invoked:
-	because there is a removal of the CSG subscription data in the CSS and of the MS registration
-	because the CSS has decided to cancel the registration of the MS which does not have CSG subscription data in the CSS.
NOTE:	How the CSS determines when to cancel the registration of the MS is implementation dependent.
The message flow for VCSG location cancellation for a subscriber is shown in figure 19.1.2A/1.


1)	MAP_CANCEL_VCSG_LOCATION_req/ind
2)	MAP_CANCEL_VCSG_LOCATION_rsp/cnf


Figure 19.1.2A/1: Message flow for VCSG Location Cancellation 
19.1.2A.2	Procedure in the CSS
The MAP process in the CSS to cancel the VCSG location information in a VLR is shown in figure 19.1.2A/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2.
The MAP process in the CSS to cancel the VCSG location information in a SGSN is shown in figure 19.1.2A/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2.

19.1.2A.3	Procedure in the VLR
The MAP process in the VLR to handle a VCSG location cancellation request is shown in figure 19.1.2A/4. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind		see clause 25.1.1.
19.1.2A.4	Procedure in the SGSN
The MAP process in the SGSN to handle a VCSG location cancellation request is shown in figure 19.1.2A/5. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind		see clause 25.1.1.


Figure 19.1.2A/2: Process Cancel_VCSG_Location_CSS

Figure 19.1.2A/3: Process Cancel_VCSG_Location_VLR

Figure 19.1.2A/4: Process Cancel_VCSG_Location_SGSN

19.1.3	Void
19.1.4	MS Purging
19.1.4.1	General
O&M procedures in the VLR or SGSN can trigger MS purging either because of administrative action or because the MS has been inactive for an extended period. The O&M process in the VLR or in the SGSN should ensure that during the MS purging procedure any other attempt to access the MS record is blocked, to maintain consistency of data.
The message flow for a VLR to report MS purging to the HLR is shown in figure 19.1.4/1.
The message flow for an SGSN to report MS purging to the HLR is shown in figure 19.1.4/2.


1)	MAP_PURGE_MS_req/ind
2)	MAP_PURGE_MS_rsp/cnf

Figure 19.1.4/1: Message flow for MS purging (non-GPRS)



1)	MAP_PURGE_MS_req/ind
2)	MAP_PURGE_MS_rsp/cnf

Figure 19.1.4/2: Message flow for MS purging (GPRS)
19.1.4.2	Procedure in the VLR
The MAP process in the VLR to report MS purging to the HLR is shown in figure 19.1.4/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2.
19.1.4.3	Procedure in the SGSN 
The MAP process in the SGSN to report MS purging to the HLR is shown in figure 19.1.4/4. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2.
Sheet 1: The procedure Purge_MS_In_Serving_Network_Entity is specific to Super-Charger; it is specified in 3GPP TS 23.116 [110]. If the HLR does not support the Super-Charger functionality, processing continues from the "No" exit of the test "Result=Pass?".
19.1.4.4	Procedure in the HLR
The MAP process in the HLR to handle a notification from a VLR or an SGSN that an MS record has been purged is shown in figure 19.1.4/5. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind		see clause 25.1.1;
Check_Indication		see clause 25.2.1.
If the notification was received from a VLR, the MAP process communicates with the location management application process specified in 3GPP TS 23.012 [23]; if the notification was received from an SGSN, the MAP process communicates with the GPRS mobility management application process specified in 3GPP TS 23.060 [104].


Figure 19.1.4/3: Process Purge_MS_VLR

Figure 19.1.4/4 (sheet 1 of 2): Process Purge_MS_SGSN

Figure 19.1.4/4 (sheet 2 of 2): Process Purge_MS_SGSN

Figure 19.1.4/5: Process Purge_MS_HLR
19.2	Handover procedures
19.2.1	General
In this clause, the term "Inter-MSC handover" is used to denote handover or relocation between different MSCs.
The interfaces involved for Inter-MSC handover are shown in figure 19.2/1. There are two Inter-MSC handover procedures:
1)	Basic Inter-MSC handover:
	The call is handed over from the controlling MSC(MSC—A) to another MSC(MSC—B) (figure 19.2/1a).
	Figure 19.2/2 shows the message flow for a successful handover from MSC‑A to MSC—B, including a request for handover number allocation from MSC‑B to VLR‑B.
2)	Subsequent Inter-MSC handover:
	After the call has been handed over from MSC‑A to MSC‑B, a further handover either to MSC‑A (figure 19.2/1a) or to a third MSC (MSC‑B') (figure 19.2/1b) may be  necessary in order to continue the call.
	Figure 19.2/3 shows the message flow for a successful subsequent handover to MSC‑B'. For a successful subsequent handover to MSC‑A, the messages to and from MSC‑B' and VLR‑B' are omitted..

a) Basic handover procedure MSC‑A to MSC‑B 
and subsequent handover procedure MSC‑B to MSC‑A.

b) Subsequent handover procedure MSC‑B to MSC‑B'.
Figure 19.2/1: Interface structure for handover


1)	MAP_PREPARE_HANDOVER_req/ind
2)	MAP_ALLOCATE_HANDOVER_NUMBER_req/ind
3)	MAP_SEND_HANDOVER_REPORT_req/ind
4)	MAP_PREPARE_HANDOVER_rsp/cnf
5)	MAP_SEND_HANDOVER_REPORT_rsp/cnf (Note)
6)	MAP_PROCESS_ACCESS_SIGNALLING_req/ind
7)	MAP_SEND_END_SIGNAL_req/ind
8)	MAP_FORWARD_ACCESS_SIGNALLING_req/ind
9)	MAP_PROCESS_ACCESS_SIGNALLING_req/ind
10)	MAP_SEND_END_SIGNAL_rsp/cnf

NOTE:	This can be sent at any time after the connection between MSC‑A and MSC‑B is established.

Figure 19.2/2: Example of a successful basic handover procedure to MSC‑B


1)	MAP_PREPARE_HANDOVER_req/ind
2)	MAP_ALLOCATE_HANDOVER_NUMBER_req/ind
3)	MAP_SEND_HANDOVER_REPORT_req/ind
4)	MAP_PREPARE_HANDOVER_rsp/cnf
5)	MAP_SEND_HANDOVER_REPORT_rsp/cnf (Note 1)
6)	MAP_PROCESS_ACCESS_SIGNALLING_req/ind
7)	MAP_SEND_END_SIGNAL_req/ind
8)	MAP_PREPARE_SUBSEQUENT_HANDOVER_req/ind
9)	MAP_PREPARE_HANDOVER_req/ind
10)	MAP_ALLOCATE_HANDOVER_NUMBER_req/ind
11)	MAP_SEND_HANDOVER_REPORT_req/ind
12)	MAP_PREPARE_HANDOVER_rsp/cnf
13)	MAP_SEND_HANDOVER_REPORT_rsp/cnf (Note 2)
14)	MAP_PREPARE_SUBSEQUENT_HANDOVER_rsp/cnf
15)	MAP_PROCESS_ACCESS_SIGNALLING_req/ind
16)	MAP_SEND_END_SIGNAL_req/ind
17)	MAP_SEND_END_SIGNAL_rsp/cnf (Note 3)

NOTE 1:	This can be sent at any time after the connection between MSC‑A and MSC‑B is established.
NOTE 2:	This can be sent at any time after the connection between MSC‑A and MSC‑B' is established.
NOTE 3:	At this stage, the subsequent handover is complete. Any further interworking between MSC‑A and MSC‑B' is the same as the interworking between MSC‑A and MSC‑B after basic handover

Figure 19.2/3: Example of a successful subsequent handover to a third MSC
The MAP signalling procedures for inter-MSC handover support the allocation of a handover number or one or more relocation numbers and the transfer of encapsulated BSSAP or RANAP messages.
The minimum application context version for the MAP handover application context shall be:
-	version 3 for inter-MSC UTRAN to UTRAN handover;
-	version 3 for inter-MSC intersystem handover from GSM BSS to UTRAN;
-	version 2 for inter-MSC intersystem handover from UTRAN to GSM BSS.
NOTE:	If the MAP handover application context version 2 is used, subsequent handover to UTRAN is not possible.
The minimum application context version for the MAP handover application context should be version 2 for inter-MSC handover from GSM BSS to GSM BSS.
NOTE:	If the MAP handover application context version 2 or lower is used, subsequent handover to UTRAN is not possible.
The BSSAP or RANAP messages encapsulated in MAP messages are processed by the Handover Control Application in each MSC. The information in the encapsulated BSSAP or RANAP messages is passed from the Handover Control Application to the MAP process at the sending end; the notation used in the SDL diagrams for the MAP processes is "HO_CA_MESSAGE_ind(Message transfer)". The information in the encapsulated BSSAP or RANAP messages is passed from the MAP process to the Handover Control Application at the sending end; the notation used in the SDL diagrams for the MAP processes is "HO_CA_MESSAGE_req(Message transfer)".
For details of the interworking between the A-interface and MAP procedures or the Iu-interface and MAP procedures, see 3GPP TS 23.009 [21] and 3GPP TS 29.010 [58].
19.2.2	Procedure in MSC‑A
This clause describes the inter-MSC handover procedure in MSC‑A; it covers basic inter-MSC handover to another MSC (MSC‑B) and subsequent inter-MSC handover to a third MSC (MSC‑B') or back to the controlling MSC (MSC‑A).
The MAP process in MSC‑A to handle inter-MSC handover is shown in figure 19.2/4. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf		see clause 25.1.2;
Check_Indication		see clause 25.2.1.
Check_Confirmation		see clause 25.2.2.
Communication between the MAP handover process and the Handover Control application is represented by the HO_CA_MESSAGE service. For a detailed description of the interworking between the Handover Control applications in different MSCs for the inter-MSC handover procedure, see 3GPP TS 23.009 [21].
19.2.2.1	Basic handover
The handling in MSC‑A for basic inter-MSC handover is shown in sheets 1 to 6 of figure 19.2/4.
Sheet 1: The MAP_PREPARE_HANDOVER request may contain:
-	an indication that handover number allocation is not required;
-	the target Cell ID, for compatibility for handover to GSM;
-	the target RNC ID, for SRNS relocation or inter-system handover from GSM to UMTS;
-	the IMSI;
-	UMTS encryption information and UMTS integrity protection information, which are necessary for inter-system handover from GSM to UMTS;
-	GSM radio resource information (channel type); 
-	the LCLS Global Call Reference;
 -	the LCLS-Negotiation;
-	the LCLS-Configuration-Preference.
The conditions for the presence of these parameters and the processing in MSC‑B (3G_MSC‑B) are described in detail in 3GPP TS 29.010 [58], 3GPP TS 23.009 [21] and 3GPP TS 29.205 [146].
Sheet 2: The MAP_PREPARE_HANDOVER confirmation contains one of:
-	no handover number, if the MAP_PREPARE_HANDOVER request included an indication that handover number allocation is not required;
-	a handover number;
-	one or more relocation numbers.
Sheet 2: The MAP_PREPARE_HANDOVER confirmation contains BSSAP or RANAP signalling information, which is passed to the Handover Control application in MSC‑A.
Sheet 2: If the MAP_PREPARE_HANDOVER confirmation contains an indication that MSC‑B does not support multiple bearers, the Handover Control application in MSC‑A may request handover of one bearer to the same cell in MSC‑B.
Sheet 5: If the original MAP_PREPARE_HANDOVER request included a parameter indicating that handover number allocation is not required, the Handover Control application in MSC‑A may request a handover number (or one or more relocation numbers); this triggers a further MAP_PREPARE_HANDOVER request towards MSC‑B.
19.2.2.2	Handling of access signalling
The Handover Control application in MSC‑A may forward access signalling to any of the MS, RNS‑B or BSS‑B using the MAP_FORWARD_ACCESS_SIGNALLING service; any of the MS, RNS‑B or BSS‑B may forward access signalling to the Handover Control application in MSC‑A using the MAP_PROCESS_ACCESS_SIGNALLING service. These are non-confirmed services.
19.2.2.3	Subsequent handover
The handling in MSC‑A for subsequent inter-MSC handover is shown in sheets 7 & 8 of figure 19.2/4. If the Handover Control Application determines that the call is to be handed over to a third MSC (MSC‑B') it triggers another instance of the MAP process to handle the basic handover to MSC‑B', and reports the result of the subsequent handover to the instance of the MAP process which handles the dialogue with MSC‑B.
Sheet 8: While the MAP process in MSC‑A is waiting for the completion of subsequent handover, it relays access signalling between the Handover Control application and the MS, RNS‑B or BSS‑B as described in clause 19.2.2.2.
19.2.3	Procedure in MSC‑B
This clause describes the handover or relocation procedure in MSC‑B; it covers basic handover or relocation from the controlling MSC (MSC‑A) and subsequent handover or relocation.
The MAP process in MSC‑B to handle handover or relocation is shown in figure 19.2/5. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind		see clause 25.1.1;
Receive_Open_Cnf		see clause 25.1.2;
Check_Indication		see clause 25.2.1.
Check_Confirmation		see clause 25.2.2.
Communication between the MAP handover process and the Handover Control application is represented by the HO_CA_MESSAGE service. For a detailed description of the interworking between the Handover Control applications in different MSCs for the inter-MSC handover procedure, see 3GPP TS 23.009 [21].
The ordering of allocation of handover number and radio resources shown in the SDL diagrams is not mandatory.
19.2.3.1	Basic handover
The handling in MSC‑B for basic inter-MSC handover is shown in sheets 1 to 7 of figure 19.2/5.
Sheet 2: If the MAP_PREPARE_HANDOVER indication included a parameter requesting multiple bearers but MSC‑B does not support multiple bearers, MSC‑B sends a MAP_PREPARE_HANDOVER response indicating that multiple bearers are not supported, and waits for a possible MAP_PREPARE_HANDOVER indication requesting handover of a single bearer.
Sheet 6: If the original MAP_PREPARE_HANDOVER indication included a parameter indicating that handover number allocation is not required, MSC‑A may send a further MAP_PREPARE_HANDOVER request to request the allocation of a handover number (or one or more relocation numbers).
19.2.3.2	Handling of access signalling
The Handover Control application in MSC‑A may forward access signalling to any of the MS, RNS‑B or BSS‑B using the MAP_FORWARD_ACCESS_SIGNALLING service; any of the MS, RNS‑B or BSS‑B may forward access signalling to the Handover Control application in MSC‑A using the MAP_PROCESS_ACCESS_SIGNALLING service. These are non-confirmed services. Signals to or from any of the MS, RNS‑B or BSS‑B are routed through the Handover Control application in MSC‑B.
19.2.3.3	Subsequent handover
The handling in MSC‑B for subsequent inter-MSC handover is shown in sheet 8 of figure 19.2/5.
While the MAP process in MSC‑B is waiting for the completion of subsequent handover, it relays access signalling between MSC‑A and the MS, RNS‑B or BSS‑B through the Handover Control application as described in clause 19.2.3.2.
19.2.4	Macro Receive_Error_From_HO_CA
This macro is used by the handover processes in MSC‑A and MSC‑B to receive errors from the Handover Control Application at any state of a handover process.
19.2.5	Procedure in VLR‑B
The process in VLR-B to handle a request for a handover number is shown in figure 19.2/7. The process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind		see clause 25.1.1;
Check_Indication		see clause 25.2.1.


Figure 19.2/4 (sheet 1 of 8): Process HO_MSC_A

Figure 19.2/4 (sheet 2 of 8): Process HO_MSC_A

Figure 19.2/4 (sheet 3 of 8): Process HO_MSC_A

Figure 19.2/4 (sheet 4 of 8): Process HO_MSC_A

Figure 19.2/4 (sheet 5 of 8): Process HO_MSC_A

Figure 19.2/4 (sheet 6 of 8): Process HO_MSC_A

Figure 19.2/4 (sheet 7 of 8): Process HO_MSC_A

Figure 19.2/4 (sheet 8 of 8): Process HO_MSC_A

Figure 19.2/5 (sheet 1 of 8): Process HO_MSC_B

Figure 19.2/5 (sheet 2 of 8): Process HO_MSC_B

Figure 19.2/5 (sheet 3 of 8): Process HO_MSC_B

Figure 19.2/5 (sheet 4 of 8): Process HO_MSC_B

Figure 19.2/5 (sheet 5 of 8): Process HO_MSC_B

Figure 19.2/5 (sheet 6 of 8): Process HO_MSC_B

Figure 19.2/5 (sheet 7 of 8): Process HO_MSC_B

Figure 19.2/5 (sheet 8 of 8): Process HO_MSC_B

Figure 19.2/6: Macro Receive_error_from_HO_CA

Figure 19.2/7: Process HO_VLR_B
19.3	Fault recovery procedures
When a location register has restarted after a fault, the fault recovery procedures ensure that the subscriber data in the VLR or in the SGSN become consistent with the subscriber data that are stored in the HLR for the MS concerned and that the location information in the HLR , the VLR and the SGSN reflect accurately the current location of the MS.
The stage 2 specification of fault recovery procedures in location registers is 3GPP TS 23.007 [19].
19.3.1	VLR fault recovery procedures
19.3.1.1 General
Restoration of an IMSI record in a VLR can be triggered by a location registration request from the MS or by a request from the HLR for a roaming number to route a mobile terminated call to the MS. If the restoration is triggered by a location registration request from the MS, the VLR performs the location updating procedure described in 3GPP TS 23.012 [23] and clause 19.1.1 of the present document. If the restoration is triggered by a request for a roaming number, the VLR provides the roaming number and triggers an independent dialogue to restore the subscriber data as described in 3GPP TS 23.018 [97]. The message flow for data restoration triggered by a request for a roaming number is shown in figure 19.3.1/1.


1)	MAP_PROVIDE_ROAMING_NUMBER_req/ind
2)	MAP_PROVIDE_ROAMING_NUMBER_rsp/cnf
3)	MAP_SEND_AUTHENTICATION_INFO_req/ind (Note 1, note 2)
4)	MAP_SEND_AUTHENTICATION_INFO_rsp/cnf (Note 1, note 2)
5)	MAP_RESTORE_DATA_req/ind
6)	MAP_ACTIVATE_TRACE_MODE_req/ind (Note 1, note 3)
7)	MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 1, note 3)
8)	MAP_INSERT_SUBSCRIBER_DATA_req/ind
9)	MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf
10)	MAP_RESTORE_DATA_rsp/cnf

NOTE 1:	Services printed in italics are optional.
NOTE 2:	If authentication is required.
NOTE 3:	If subscriber tracing is active in the HLR.

Figure 19.3/1: Message flow for VLR restoration at mobile terminated call set-up
19.3.1.2	Procedure in the VLR
The procedure in the VLR to handle a dialogue for subscriber data restoration is defined in clause 21.2.6 of the present document.
19.3.1.3	Procedure in the HLR
The MAP process in the HLR to handle a request for data restoration in the VLR is shown in figure 19.3.1/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Check_Indication		see clause 25.2.1;
Control_Tracing_With_VLR_HLR	see clause 25.9.6.


Figure 19.3.1/2: Process Restore_Data_HLR
19.3.2	HLR fault recovery procedures
19.3.2.1	General
For the HLR, periodic back-up of data to non-volatile memory is mandatory.
Data that have been changed after the last back-up and before the restart of the HLR cannot be recovered by reload from the non-volatile memory. Therefore, a restoration procedure is triggered for each IMSI record that has been affected by the HLR fault at the first authenticated radio contact with the MS concerned.
As an implementation option, a notification can be forwarded to the MS to alert the subscriber to check the parameters for supplementary services that allow subscriber controlled input (MAP_FORWARD_CHECK_SS_INDICATION service). If the VLR receives this notification from the HLR it shall forward the notification to the MS. If the Gs-interface is implemented the VLR shall not forward this notification.
A restoration procedure may also be triggered for IMSI records that shares subscription data with other IMSI records when the shared subscription data is modified, added or deleted. This option presumes the support of Reset-IDs.
The message flow for HLR restoration for a non-GPRS subscriber is shown in figure 19.3.2/1.
The message flow for HLR restoration for a GPRS subscriber is shown in figure 19.3.2/2.


1)	MAP_RESET_req/ind
2)	MAP_PROCESS_ACCESS_REQUEST_req/ind
3)	MAP_UPDATE_LOCATION_req/ind
4)	MAP_ACTIVATE_TRACE_MODE_req/ind (Note 1, Note 2)
5)	MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 1, Note 2)
6)	MAP_INSERT_SUBSCRIBER_DATA_req/ind
7)	MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf
8)	MAP_UPDATE_LOCATION_rsp/cnf 
9)	MAP_FORWARD_CHECK_SS_INDICATION_req/ind (Note 1)
10)	MAP_FORWARD_CHECK_SS_INDICATION_req/ind (Note 1)

NOTE 1:	Services printed in italics are optional.
NOTE 2:	If subscriber tracing is active in the HLR.

Steps 2 to 10 may be skipped if the procedure is used to update shared subscription data.

Figure 19.3.2/1: Message flow for HLR restoration (non-GPRS)



1)	MAP_RESET_req/ind
2)	MAP_UPDATE_GPRS_LOCATION_req/ind
3)	MAP_ACTIVATE_TRACE_MODE_req/ind (Note 1, Note 2)
4)	MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 1, Note 2)
5)	MAP_INSERT_SUBSCRIBER_DATA_req/ind
6)	MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf
7)	MAP_UPDATE_GPRS_LOCATION_rsp/cnf 

NOTE 1:	Services printed in italics are optional.
NOTE 2:	If subscriber tracing is active in the HLR.

Steps 2 to 7 may be skipped if the procedure is used to update shared subscription data.


Figure 19.3.2/2: Message flow for HLR restoration (GPRS)
19.3.2.2	Procedure in the HLR
The MAP process in the HLR to notify the relevant serving nodes that the HLR has restarted is shown in figure 19.3.2/3.
The SGSN address list includes one instance of the address of each SGSN in which (according to the HLR data retrieved from the non-volatile memory) there is at least one subscriber registered who is affected by the HLR restart.
The VLR address list includes one instance of the address of each VLR in which (according to the HLR data retrieved from the non-volatile memory) there is at least one subscriber registered who is affected by the HLR restart.
The MAP process in the HLR to notify a VLR that the HLR has restarted is shown in figure 19.3.2/4. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Cnf		see clause 25.1.2.
The MAP process in the HLR to notify an SGSN that the HLR has restarted is shown in figure 19.3.2/5. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Cnf		see clause 25.1.2.
19.3.2.3	Procedure in the VLR
The MAP process in the VLR to handle a notification that an HLR has restarted is shown in figure 19.3.2/6. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind		see clause 25.1.1.
When Reset-IDs are not supported or not present in the MAP_RESET indication, the VLR uses the HLR number or the HLR identity list included in the MAP_RESET indication to identify the IMSI records which are affected by the HLR restart. 
When Reset-IDs are supported and present in the MAP_RESET indication, the VLR uses the Reset-IDs included in the MAP_RESET indication to identify the affected IMSI records.
The task "Update Data" includes any required action to let the update come into effect.
If the update of shared subscription data requires only local updates in the VLR (i.e., the update of the profile does not imply to initiate any signalling interaction towards other network nodes), the updates should be performed immediately (e.g. deleting an Operator Determined Barring).
If the update of shared subscription data implies initiating a signalling interaction towards other nodes, the signalling towards other nodes should be deferred to the next authenticated radio contact with that UE.
NOTE:	The rational for the recommendation to defer signalling towards other nodes until the next authenticated radio contact is to consider impacts to the network only when the updates are required, and to spread the signalling towards other nodes over some time, based on user's activity.
To avoid high processing/signalling load resulting from shared subscription data update, processing/signalling actions resulting from data updates in the VLR may take a maximum operator configuration-depending time.

19.3.2.4	Procedure in the SGSN
The MAP process in the SGSN to handle a notification that an HLR has restarted is shown in figure 19.3.2/7. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind		see clause 25.1.1.
When Reset-IDs are not supported or not present in the MAP_RESET indication, the SGSN uses the HLR number or the HLR identity list included in the MAP_RESET indication to identify the IMSI records which are affected by the HLR restart. 
When Reset-IDs are supported and present in the MAP_RESET indication, the SGSN uses the Reset-IDs included in the MAP_RESET indication to identify the affected IMSI records.
The task "Update Data" includes any required action to let the update come into effect.
If the update of shared subscription data requires only local updates in the SGSN (i.e., the update of the profile does not imply to initiate any signalling interaction towards other network nodes), the updates should be performed immediately (e.g. deleting an Operator Determined Barring).
If the update of shared subscription data implies initiating a signalling interaction towards other nodes, the signalling towards other nodes should be deferred to the next authenticated radio contact with that UE.
NOTE:	The rational for the recommendation to defer signalling towards other nodes until the next authenticated radio contact is to consider impacts to the network only when the updates are required, and to spread the signalling towards other nodes over some time, based on user's activity.
To avoid high processing/signalling load resulting from shared subscription data update, processing/signalling actions resulting from data updates in the SGSN may take a maximum operator configuration-depending time.


Figure 19.3.2/3: Process Restart_HLR

Figure 19.3.2/4: Process Send_Reset_To_VLR_HLR

Figure 19.3.2/5: Process Send_Reset_To_SGSN_HLR

Figure 19.3.2/6: Process Receive_Reset_VLR

Figure 19.3.2/7: Process Receive_Reset_SGSN
19.3.3	CSS fault recovery procedures
19.3.3.1	General
For the CSS, periodic back-up of data to non-volatile memory is mandatory.
Serving node numbers that have been changed after the last back-up and before the restart of the CSS cannot be recovered by reload from the non-volatile memory. Therefore, a restoration procedure is triggered for each IMSI record that has been affected by the CSS fault at the first authenticated radio contact with the MS concerned.
The message flow for CSS restoration for a non-GPRS subscriber is shown in figure 19.3.3/1.
The message flow for CSS restoration for a GPRS subscriber is shown in figure 19.3.3/2.


1)	MAP_RESET_req/ind
2)	MAP_UPDATE_VCSG_LOCATION_req/ind
3)	MAP_INSERT_SUBSCRIBER_DATA_req/ind
4)	MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf
5)	MAP_UPDATE_VCSG_LOCATION_rsp/cnf 


Figure 19.3.3/1: Message flow for CSS restoration (non-GPRS)



1)	MAP_RESET_req/ind
2)	MAP_UPDATE_VCSG_LOCATION_req/ind
3)	MAP_INSERT_SUBSCRIBER_DATA_req/ind
4)	MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf
5)	MAP_UPDATE_VCSG_LOCATION_rsp/cnf 


Figure 19.3.3/2: Message flow for CSS restoration (GPRS)
19.3.3.2	Procedure in the CSS
The MAP process in the CSS to notify the relevant serving nodes that the CSS has restarted is shown in figure 19.3.3/3.
The SGSN address list includes one instance of the address of each SGSN in which (according to the CSS data retrieved from the non-volatile memory) there is at least one subscriber registered who is affected by the CSS restart.
The VLR address list includes one instance of the address of each VLR in which (according to the CSS data retrieved from the non-volatile memory) there is at least one subscriber registered who is affected by the CSS restart.
The MAP process in the CSS to notify a VLR that the CSS has restarted is shown in figure 19.3.3/4. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Cnf		see clause 25.1.2.
The MAP process in the CSS to notify an SGSN that the CSS has restarted is shown in figure 19.3.3/5. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Cnf		see clause 25.1.2.
19.3.3.3	Procedure in the VLR
The MAP process in the VLR to handle a notification that a CSS has restarted is shown in figure 19.3.3/6. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind		see clause 25.1.1.
The VLR uses the CSS number (filled in Sending Node number parameter) included in the MAP_RESET indication to identify the user's IMSI records which are affected by the CSS restart.
19.3.3.4	Procedure in the SGSN
The MAP process in the SGSN to handle a notification that a CSS has restarted is shown in figure 19.3.3/6. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind		see clause 25.1.1.
The SGSN uses the CSS number (filled in Sending Node number parameter) included in the MAP_RESET indication to identify the user's IMSI records which are affected by the CSS restart.


Figure 19.3.3/3: Process Restart_CSS

Figure 19.3.3/4: Process Send_Reset_To_VLR_CSS

Figure 19.3.3/5: Process Send_Reset_To_SGSN_CSS

Figure 19.3.3/6: Process Receive_Reset_From_CSS_VLR

Figure 19.3.3/7: Process Receive_Reset_From_CSS_SGSN
19.4	Mobility Management event notification procedure
19.4.1	General
The Mobility Management event notification procedure is used to notify a gsmSCF about the successful completion of a Mobility Management event.
The message flow for Mobility Management event notification is shown in figure 19.4/1.
 

1)	MAP_REPORT_MM_EVENT_req/ind
2)	MAP_REPORT_MM_EVENT_rsp/cnf

Figure 19.5/1: Message flow for Mobility Management event notification
19.4.2	Procedure in the VLR or SGSN
The MAP process in the VLR or the SGSN to report a Mobility Management event to the gsmSCF is shown in figure 19.4/2.The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation:		see clause 25.2.2.
19.4.3	Procedure in the gsmSCF
The MAP process in the gsmSCF to handle the report of a Mobility Management event is shown in figure 19.4/3.The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind		see clause 25.1.1;


Figure 19.4/2: Process Notify_MM_Event_VLR_Or_SGSN

Figure 19.4/3: Process Notify_MM_Event_gsmSCF
19.5	HLR Insert Subscriber Data macros
19.5.1	Macro Insert_Subs_Data_Framed_HLR
This macro is used to transfer subscriber data to the VLR as part of an existing dialogue for location updating or data restoration. The macro invokes a macro and a process not defined in this clause; the definitions of the macro and the process can be found as follows:
Wait_For_Insert_Subs_Data_Cnf	see clause 25.7.5;
Send_Insert_Subs_Data_HLR:	see clause 25.7.7.
The HLR may wait for each MAP_INSERT_SUBSCRIBER_DATA request to be acknowledged before it sends the next request, or it may handle the requests and the confirmations in parallel.
If the VLR has indicated that it does not support a service or feature (e.g. Closed User Group or Advice Of Charge Charging Level) which the HLR operator regards as essential for the subscriber, the macro Wait_for_Insert_Subs_Data_Cnf takes the Replace_Service exit; the HLR sets the Roaming Restriction Due To Unsupported Feature flag to roaming restricted and sends Roaming Restriction Due To Unsupported Feature in a subsequent MAP_INSERT_SUBSCRIBER_DATA request.
If the HLR operator does not regard the unsupported service or feature as essential for the subscriber but the macro Wait_for_Insert_Subs_Data_Cnf takes the Replace_Service exit, the HLR sends the data for a replacement service in a subsequent MAP_INSERT_SUBSCRIBER_DATA request.
If subscriber data for CAMEL Phase 2 or later services are sent to a VLR which does not support the appropriate phase of CAMEL, the service behaviour may be unpredictable or incorrect. The HLR should therefore ensure that at the conclusion of a stand alone Insert Subscriber data procedure the data in the VLR do not require a capability that the VLR does not have. Possible mechanisms to ensure this are described in 3GPP TS 23.078 [98]. 
The HLR should send a Forwarded-to number which is not in E.164 international format to the VLR only when the HLR has ascertained that the VLR supports CAMEL Phase 2 or later. Thus, the ISD message containing the Forwarded-to number which is not in E.164 international format shall be sent to the VLR only if the HLR previously received confirmation from the VLR at Location Update that CAMEL Phase 2 or later is supported.
19.5.2	Macro Insert_GPRS_Subs_Data_Framed_HLR
This macro is used to transfer subscriber data to the SGSN as part of an existing dialogue for location updating. The macro invokes a macro and a process not defined in this clause; the definitions of the macro and the process can be found as follows:
Wait_For_Insert_GPRS_Subs_Data_Cnf	see clause 25.7.5;
Send_Insert_Subs_Data_HLR:	see clause 25.7.7.
The HLR may wait for each MAP_INSERT_SUBSCRIBER_DATA request to be acknowledged before it sends the next request, or it may handle the requests and the confirmations in parallel.
If the SGSN has indicated that it does not support a service or feature which the HLR operator regards as essential for the subscriber, the macro Wait_for_Insert_GPRS_Subs_Data_Cnf takes the Replace_Service exit; the HLR sets the Roaming Restricted In SGSN Due To Unsupported Feature flag to roaming restricted and sends Roaming Restricted In SGSN Due To Unsupported Feature in a subsequent MAP_INSERT_SUBSCRIBER_DATA request.
If the HLR operator does not regard the unsupported service or feature as essential for the subscriber but the macro Wait_for_Insert_GPRS_Subs_Data_Cnf takes the Replace_Service exit, the HLR sends the data for a replacement service in a subsequent MAP_INSERT_SUBSCRIBER_DATA request.


Figure 19.5/1: Macro Insert_Subs_Data_Framed_HLR

Figure 19.5/2: Macro Insert_GPRS_Subs_Data_Framed_HLR
19.5A	CSS Insert Subscriber Data macros
19.5A.1	Macro Insert_VCSG_Subs_Data_Framed_CSS
This macro is used to transfer CSG subscriber data from the CSS to the VLR or the SGSN as part of an existing dialogue for VCSG location updating. The macro invokes a macro and a process not defined in this clause; the definitions of the macro and the process can be found as follows:
Wait_For_Insert_VCSG_Subs_Data_Cnf	see clause 25.7.9;
Send_Insert_VCSG_Subs_Data_CSS:	see clause 25.7.10.
The CSS may wait for each MAP_INSERT_SUBSCRIBER_DATA request to be acknowledged before it sends the next request, or it may handle the requests and the confirmations in parallel.
If the VLR or the SGSN has indicated that it does not support a service or feature which the CSS operator regards as essential for the subscriber, the macro Wait_for_Insert_VCSG_Subs_Data_Cnf takes the Replace_Service exit.
If the CSS operator does not regard the unsupported service or feature as essential for the subscriber but the macro Wait_for_Insert_VCSG_Subs_Data_Cnf takes the Replace_Service exit, the CSS sends the data for a replacement service in a subsequent MAP_INSERT_SUBSCRIBER_DATA request.
 
Figure 19.5A/1: Macro Insert_VCSG_Subs_Data_Framed_CSS
20	Operation and maintenance procedures
20.1	General
The Operation and Maintenance procedures are used to support operation and maintenance of the network.
The following procedures exist for operation and maintenance purposes:
i)	Tracing procedures;
ii)	Subscriber Data Management procedures;
iii)	Subscriber Identity procedure.
The following application contexts refer to complex MAP Users consisting of several processes:
-	subscriberDataManagementContext;
-	tracingContext.
Each of these two application contexts needs a co-ordinating process in the VLR or in the SGSN as described in the following clauses.
20.1.1	Tracing Co-ordinator for the VLR
The Tracing Co-ordinator process in the VLR is shown the figure 20.1/1. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind		see clause 25.1.1.
20.1.2	Tracing Co-ordinator for the SGSN
The Tracing Co-ordinator process in the SGSN is shown in figure 20.1/2. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind		see clause 25.1.1.
20.1.3	Subscriber Data Management Co-ordinator for the VLR
The Subscriber Data Management Co-ordinator process in the VLR is shown in figure 20.1/3 and figure 20.1/5. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind		see clause 25.1.1.
20.1.4	Subscriber Data Management Co-ordinator for the SGSN
The Subscriber Data Management Co-ordinator process in the SGSN is shown in figure 20.1/4 and figure 20.1/6. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind		see clause 25.1.1.


Figure 20.1/1: Process Co_Tracing_VLR

Figure 20.1/2: Process Co_Tracing_SGSN

Figure 20.1/3: Process Co_SDM_VLR

Figure 20.1/4: Process Co_SDM_SGSN

Figure 20.1/5: Process Co_CSG_SDM_VLR

Figure 20.1/6: Process Co_CSG_SDM_SGSN
20.2	Tracing procedures
Three types of tracing procedures exist:
i)	Subscriber tracing management procedures;
ii)	Subscriber tracing procedures;
iii)	Event tracing procedures.
The subscriber tracing management procedures are used to manage the status and the type of the tracing. The subscriber tracing activation procedure is used at location updating or data restoration when the trace mode of a subscriber is set active in the HLR or, as a stand alone procedure, when the subscriber is already registered and the trace mode becomes active in the HLR. The procedures to activate tracing in the VLR are shown in figures 20.2/1 and 20.2/3. The procedures to activate tracing in the SGSN are shown in figures 20.2/2 and 20.2/4.


1)	Subscriber Tracing Activation
2)	MAP_ACTIVATE_TRACE_MODE_req/ind
3)	MAP_ACTIVATE_TRACE_MODE_rsp/cnf
4)	Subscriber Tracing Activation Accepted

Figure 20.2/1: Stand-alone subscriber tracing activation procedure for non-GPRS



1)	Subscriber Tracing Activation
2)	MAP_ACTIVATE_TRACE_MODE_req/ind
3)	MAP_ACTIVATE_TRACE_MODE_rsp/cnf
4)	Subscriber Tracing Activation Accepted

Figure 20.2/2: Stand-alone subscriber tracing activation procedure for GPRS



1)	MAP_UPDATE_LOCATION or MAP_RESTORE_DATA_req/ind
2)	MAP_ACTIVATE_TRACE_MODE_req/ind
3)	MAP_ACTIVATE_TRACE_MODE_rsp/cnf
4)	MAP_UPDATE_LOCATION_rsp/cnf or MAP_RESTORE_DATA_rsp/cnf

Figure 20.2/3: Subscriber tracing activation procedure at location updating or data restoration



1)	MAP_UPDATE_GPRS_LOCATION_req/ind
2)	MAP_ACTIVATE_TRACE_MODE_req/ind
3)	MAP_ACTIVATE_TRACE_MODE_rsp/cnf
4)	MAP_UPDATE_GPRS_LOCATION_rsp/cnf

Figure 20.2/4: Subscriber tracing activation procedure at GPRS location updating
The MAP_ACTIVATE_TRACE_MODE request includes the IMSI, trace reference, trace type and identity of the OMC. 
The subscriber tracing deactivation procedure is used when tracing of a subscriber in the VLR or in the SGSN is no longer required. The procedures are shown in figures 20.2/5 and 20.2/6.


1)	Subscriber Tracing Deactivation
2)	MAP_DEACTIVATE_TRACE_MODE_req/ind
3)	MAP_DEACTIVATE_TRACE_MODE_rsp/cnf
4)	Subscriber Tracing Deactivation Accepted

Figure 20.2/5: Subscriber tracing deactivation procedure for non-GPRS


1)	Subscriber Tracing Deactivation
2)	MAP_DEACTIVATE_TRACE_MODE_req/ind
3)	MAP_DEACTIVATE_TRACE_MODE_rsp/cnf
4)	Subscriber Tracing Deactivation Accepted

Figure 20.2/6: Subscriber tracing deactivation procedure for GPRS
The subscriber tracing procedures are used when the VLR detects any subscriber related activity for which the trace mode is activated, e.g. the VLR receives a MAP_PROCESS_ACCESS_REQUEST indication. The procedure is shown in figure 20.2/7.


1)	MAP_PROCESS_ACCESS_REQUEST_req/ind
2)	MAP_TRACE_SUBSCRIBER_ACTIVITY_req/ind
3)	Subscriber tracing information

Figure 20.2/7: Subscriber tracing procedure in the serving MSC
20.2.1	Subscriber tracing activation procedure
20.2.1.1	Procedures in the HLR
A subscriber tracing activation request from the OMC starts the appropriate process in the HLR: ATM_With_VLR_HLR if tracing is required in the MSC/VLR, ATM_With_SGSN_HLR if tracing is required in the SGSN.
The process in the HLR to activate tracing in the VLR is shown in figure 20.2/8. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2.
Sheet 1: If the Repeat attempt counter has reached its limit, the test "Repeat Attempt" takes the "No" exit; otherwise the test takes the "Yes" exit. The number of repeat attempts and the interval between successive repeat attempts are operator options.
The process in the HLR to activate tracing in the SGSN is shown in figure 20.2/9. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2.
Sheet 1: If the Repeat attempt counter has reached its limit, the test "Repeat Attempt" takes the "No" exit; otherwise the test takes the "Yes" exit. The number of repeat attempts and the interval between successive repeat attempts are operator options.
20.2.1.2	Procedure in the VLR
The process in the VLR to activate tracing in a stand-alone dialogue is shown in figure 20.2/10. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Check_Indication		see clause 25.2.1.
20.2.1.3	Procedure in the SGSN
The process in the SGSN to activate tracing in a stand-alone dialogue is shown in figure 20.2/11. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Check_Indication		see clause 25.2.1.
20.2.2	Subscriber tracing deactivation procedure
20.2.2.1	Procedures in the HLR
A subscriber tracing deactivation request from the OMC starts the appropriate process in the HLR: DTM_HLR_With_VLR if tracing is no longer required in the MSC/VLR, DTM_HLR_With_SGSN if tracing is no longer required in the SGSN.
The process in the HLR to deactivate tracing in the VLR is shown in figure 20.2/12. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2.
Sheet 1: If the Repeat attempt counter has reached its limit, the test "Repeat Attempt" takes the "No" exit; otherwise the test takes the "Yes" exit. The number of repeat attempts and the interval between successive repeat attempts are operator options.
The process in the HLR to deactivate tracing in the SGSN is shown in figure 20.2/13. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2.
Sheet 1: If the Repeat attempt counter has reached its limit, the test "Repeat Attempt" takes the "No" exit; otherwise the test takes the "Yes" exit. The number of repeat attempts and the interval between successive repeat attempts are operator options.
20.2.2.2	Procedure in the VLR
The process in the VLR to deactivate tracing is shown in figure 20.2/14. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Check_Indication		see clause 25.2.1.
20.2.2.3	Procedure in the SGSN
The process in the SGSN to deactivate tracing is shown in figure 20.2/15. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Check_Indication		see clause 25.2.1.


Figure 20.2/8 (sheet 1 of 2): Process ATM_With_VLR_HLR

Figure 20.2/8 (sheet 2 of 2): Process ATM_With_VLR_HLR

Figure 20.2/9 (sheet 1 of 2): Process ATM_with_SGSN_HLR

Figure 20.2/9 (sheet 2 of 2): Process ATM_with_SGSN_HLR

Figure 20.2/10: Process ATM_Standalone_VLR

Figure 20.2/11: Process ATM_Standalone_SGSN

Figure 20.2/12 (sheet 1 of 2): Process DTM_with_VLR_HLR

Figure 20.2/12 (sheet 2 of 2): Process DTM_with_VLR_HLR

Figure 20.2/13 (sheet 1 of 2): Process DTM_with_SGSN_HLR

Figure 20.2/13 (sheet 2 of 2): Process DTM_with_SGSN_HLR

Figure 20.2/14: Process DTM_Standalone_VLR

Figure 20.2/15: Process DTM_Standalone_SGSN
20.3	Subscriber data management procedures for HLR
Two types of subscriber data management procedures exist:
1)	Subscriber Deletion;
2)	Subscriber Data Modification.
The subscriber deletion and subscriber data modification procedures are initiated by the OMC (see figures 20.3/1 , 20.3/2, 20.3/3 and 20.3/4).


1)	Delete Subscriber
2)	MAP_CANCEL_LOCATION_req/ind
3)	MAP_CANCEL_LOCATION_rsp/cnf
4)	Subscriber Deleted

Figure 20.3/1: Subscriber deletion procedure for non-GPRS
In the subscriber deletion procedure for a non-GPRS subscriber the subscriber data are removed from the VLR and the HLR. The HLR uses the MAP_CANCEL_LOCATION service.


1)	Delete GPRS Subscriber
2)	MAP_CANCEL_LOCATION_req/ind
3)	MAP_CANCEL_LOCATION_rsp/cnf 
4)	GPRS Subscriber Deleted

Figure 20.3/2: Subscriber deletion procedure for GPRS
In the subscriber deletion procedure for a GPRS subscriber the subscriber data are removed from the SGSN and the HLR. The HLR uses the MAP_CANCEL_LOCATION service.


1)	Modify Subscriber Data
2)	MAP_CANCEL_LOCATION_req/ind, MAP_INSERT_SUBSCRIBER_DATA_req/ind or
MAP_DELETE_SUBSCRIBER_DATA_req/ind
3)	MAP_CANCEL_LOCATION_rsp/cnf, MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf or
MAP_DELETE_SUBSCRIBER_DATA_rsp/cnf
4)	Subscriber Data Modified

Figure 20.3/3: Subscriber data modification procedure for non-GPRS

1)	Modify GPRS Subscriber Data
2)	MAP_CANCEL_LOCATION_req/ind, MAP_INSERT_SUBSCRIBER_DATA_req/ind or	
MAP_DELETE_SUBSCRIBER_DATA_req/ind
3)	MAP_CANCEL_LOCATION_rsp/cnf, MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf or	
MAP_DELETE_SUBSCRIBER_DATA_rsp/cnf
4)	GPRS Subscriber Data Modified

Figure 20.3/4: Subscriber data modification procedure for GPRS
In the subscriber data modification procedure the subscriber data are modified in the HLR and when necessary also in the VLR or in the SGSN. The HLR initiates one of the MAP_INSERT_SUBSCRIBER_DATA, MAP_DELETE_SUBSCRIBER_DATA or MAP_CANCEL_LOCATION services depending on the modified data.
20.3.1	Subscriber deletion procedure
20.3.1.1	Procedure in the HLR
The subscriber deletion process in the HLR is shown in figure 20.3/5. The MAP process invokes processes not defined in this clause; the definitions of these processes can be found as follows:
Cancel_GPRS_Location_Child_HLR	see clause 19.1.2.2;
Cancel_Location_Child_HLR		see clause 19.1.2.2.
20.3.1.2	Procedure in the VLR
The subscriber deletion procedure in the VLR is described in clause 19.1.2.3 of the present document.
20.3.1.3	Procedure in the SGSN
The subscriber deletion procedure in the SGSN is described in clause 19.1. 2.4 of the present document.
20.3.2	Subscriber data modification procedure
20.3.2.1	Procedure in the HLR
The OMC can modify the subscriber data in several different ways. The modifications can be categorised in the following groups:
1)	data shall be modified in the HLR; no effect in the VLR;
2)	data shall be modified in both the HLR and the VLR;
3)	withdrawal of a basic service or a supplementary service requiring change to VLR data;
4)	modification affects the roaming permission for the subscriber and the subscriber record shall be removed from the VLR data base;
5)	withdrawal of non-GPRS Subscription caused by a change of Network Access Mode;
6)	data shall be modified in the HLR; no effect in the SGSN;
7)	data shall be modified in both the HLR and the SGSN;
8)	withdrawal of GPRS subscription data or a basic service or a supplementary service requiring change to SGSN data;
9)	modification affects the roaming permission for the subscriber and the subscriber record shall be removed from the SGSN data base;
10)	withdrawal of GPRS Subscription caused by a change of Network Access Mode;
11)	authentication algorithm or authentication key of the subscriber is modified.
In cases 2 and 7 the HLR uses the MAP_INSERT_SUBSCRIBER_DATA service.
In cases 3 and 8 the HLR uses the MAP_DELETE_SUBSCRIBER_DATA service.
In cases 4, 5, 9, 10 and 11 the HLR uses the MAP_CANCEL_LOCATION service.
If the deletion of subscriber data fails, the HLR may repeat the request; the number of repeat attempts and the time in between are HLR operator options, depending on the error returned by the VLR or the SGSN.
The subscriber data modification process in the HLR is shown in figure 20.3/6. The MAP process invokes processes not defined in this clause; the definitions of these processes can be found as follows:
Insert_Subs_Data_Stand_Alone_HLR	see clause 25.7.3;
Cancel_Location_Child_HLR		see clause 19.1.2.2;
Insert_GPRS_Subs_Data_Stand_Alone_HLR	see clause 25.7.4;
Cancel_GPRS_Location_Child_HLR	see clause 19.1.2.2.
The macro Delete_Subscriber_Data_HLR is shown in figure 20.3/7. The macro invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf			see clause 25.1.2;
Check_Confirmation			see clause 25.2.2.
The macro Delete_GPRS_Subscriber_Data_HLR is shown in figure 20.3/8. The macro invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf			see clause 25.1.2;
Check_Confirmation			see clause 25.2.2.
20.3.2.2	Procedures in the VLR
The process in the VLR to update subscriber data in a stand-alone dialogue is shown in figure 20.3/9. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Check_Indication			see clause 25.2.1;
Insert_Subs_Data_VLR		see clause 25.7.1.
The process in the VLR to delete subscriber data is shown in figure 20.3/10. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Check_Indication			see clause 25.2.1.
20.3.2.3	Procedures in the SGSN
The process in the SGSN to update subscriber data in a stand-alone dialogue is shown in figure 20.3/11. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Check_Indication			see clause 25.2.1;
Insert_Subs_Data_SGSN		see clause 25.7.2.
The process in the SGSN to delete subscriber data is shown in figure 20.3/12. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Check_Indication			see clause 25.2.1.


Figure 20.3/5: Process Delete_Subscriber_HLR

Figure 20.3/6 (sheet 1 of 2): Process Modify_Data_HLR

Figure 20.3/6 (sheet 2 of 2): Process Modify_Data_HLR

Figure 20.3/7: Macro Delete_Subscriber_Data_HLR

Figure 20.3/8: Macro Delete_GPRS_Subscriber_Data_HLR

Figure 20.3/9 (sheet 1 of 2): Process Ins_Subs_Data_Stand_Alone_VLR

Figure 20.3/9 (sheet 2 of 2): Process Ins_Subs_Data_Stand_Alone_VLR

Figure 20.3/10: Process Delete_Subs_Data_VLR

Figure 20.3/11 (sheet 1 of 2): Process Ins_Subs_Data_Stand_Alone_SGSN

Figure 20.3/11 (sheet 2 of 2): Process Ins_Subs_Data_Stand_Alone_SGSN

Figure 20.3/12: Process Delete_Subs_Data_SGSN
20.3A	Subscriber Data Management procedures for CSS
Two types of subscriber data management procedures exist:
1)	Subscriber Deletion;
2)	Subscriber Data Modification.
The subscriber deletion and subscriber data modification procedures are initiated by the OMC (see figures 20.3A/1, 20.3A/2, 20.3A/3 and 20.3A/4).


1)	Delete Subscriber
2)	MAP_DELETE_SUBSCRIBER_DATA_req/ind
3)	MAP_DELETE_SUBSCRIBER_DATA_rsp/cnf
4)	Subscriber Deleted

Figure 20.3A/1: Subscriber deletion procedure for non-GPRS
In the subscriber deletion procedure for a non-GPRS subscriber the CSG subscription data for the subscriber in the VPLMN are removed from the VLR and the CSS. The CSS uses the MAP_DELETE_SUBSCRIBER_DATA service.


1)	Delete GPRS Subscriber
2)	MAP_DELETE_SUBSCRIBER_DATA_req/ind
3)	MAP_DELETE_SUBSCRIBER_DATA_rsp/cnf 
4)	GPRS Subscriber Deleted

Figure 20.3A/2: Subscriber deletion procedure for GPRS
In the subscriber deletion procedure for a GPRS subscriber the CSG subscription data for the GPRS subscriber in the VPLMN are removed from the SGSN and the CSS. The CSS uses the MAP_DELETE_SUBSCRIBER_DATA service.


1)	Modify Subscriber Data
2)	MAP_INSERT_SUBSCRIBER_DATA_req/ind or MAP_DELETE_SUBSCRIBER_DATA_req/ind
3)	MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf or MAP_DELETE_SUBSCRIBER_DATA_rsp/cnf
4)	Subscriber Data Modified

Figure 20.3A/3: Subscriber data modification procedure for non-GPRS


1)	Modify GPRS Subscriber Data
2)	MAP_INSERT_SUBSCRIBER_DATA_req/ind or MAP_DELETE_SUBSCRIBER_DATA_req/ind
3)	MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf or MAP_DELETE_SUBSCRIBER_DATA_rsp/cnf 
4)	GPRS Subscriber Data Modified

Figure 20.3A/4: Subscriber data modification procedure for GPRS
In the subscriber data modification procedure the CSG subscription data in the VPLMN for the subscriber data are modified in the CSS and when necessary also in the VLR or in the SGSN. The CSS initiates one of the MAP_INSERT_SUBSCRIBER_DATA or MAP_DELETE_SUBSCRIBER_DATA services depending on the modified data.
20.3A.1	Subscriber deletion procedure
20.3A.1.1	Procedure in the CSS
The process in the CSS to delete subscriber is shown in figure 20.3A/5. In this case the CSS uses the MAP_DELETE_SUBSCRIBER_DATA service.
20.3A.1.2	Procedure in the VLR
The process in the VLR for the CSG subscriber deletion procedure is shown in figure 20.3A/9.
20.3A.1.3	Procedure in the SGSN
The process in the SGSN for the CSG subscriber deletion procedure is shown in figure 20.3A/11.
20.3A.2	Subscriber data modification procedure
20.3A.2.1	Procedure in the CSS
The OMC can modify the CSG subscriber data in several different ways. The modifications can be categorised in the following groups:
1)	CSG subsctiption data shall be modified in the CSS; no effect in the VLR;
2)	CSG subsctiption data shall be modified in both the CSS and the VLR;
3)	withdrawal of CSG subscription data requiring change to VLR data.
4)	CSG subsctiption data shall be modified in the CSS; no effect in the SGSN;
5)	CSG subsctiption data shall be modified in both the CSS and the SGSN;
6)	withdrawal of CSG subscription data requiring change to SGSN data.
In cases 2 and 5 the CSS uses the MAP_INSERT_SUBSCRIBER_DATA service.
In cases 3 and 6 the CSS uses the MAP_DELETE_SUBSCRIBER_DATA service.
If the deletion of CSG subscriber data fails, the CSS may repeat the request; the number of repeat attempts and the time in between are CSS operator options, depending on the error returned by the VLR or the SGSN. The CSS removes the routeting information after the completion of CSG subscriber data deletion procedure.
The CSG subscriber data modification process in the CSS is shown in figure 20.3A/6. The MAP process invokes processes not defined in this clause; the definitions of these processes can be found as follows:
Insert_VCSG_Subs_Data_Stand_Alone_CSS	see clause 25.7.8;
The macro Delete_VCSG_Subs_Data_CSS is shown in figure 20.3A/7. The macro invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf			see clause 25.1.2;
Check_Confirmation			see clause 25.2.2.
20.3A.2.2	Procedures in the VLR
The process in the VLR to update CSG subscription data in the VPLMN for the subscriber in a stand-alone dialogue is shown in figure 20.3A/8. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Check_Indication			see clause 25.2.1;
Insert_Subs_Data_VLR		see clause 25.7.1.
The process in the VLR to delete CSG subscriber data is shown in figure 20.3A/9. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Check_Indication			see clause 25.2.1.
20.3A.2.3	Procedures in the SGSN
The process in the SGSN to update CSG subscription data in the VPLMN for the GPRS subscriber in a stand-alone dialogue is shown in figure 20.3A/10. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Check_Indication			see clause 25.2.1;
Insert_Subs_Data_SGSN		see clause 25.7.2.
The process in the SGSN to delete subscriber data is shown in figure 20.3A/11. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Check_Indication			see clause 25.2.1.


Figure 20.3A/5: Process Delete_Subscriber_CSS

Figure 20.3A/6 (sheet 1 of 2): Process Modify_Data_CSS

Figure 20.3A/6 (sheet 2 of 2): Process Modify_Data_CSS
 
Figure 20.3A/7: Macro Delete_VCSG_Subs_Data_CSS

Figure 20.3A/8 (sheet 1 of 2): Process Ins_VCSG_Subs_Data_Stand_Alone_VLR

Figure 20.3A/8 (sheet 2 of 2): Process Ins_VCSG_Subs_Data_Stand_Alone_VLR

Figure 20.3A/9: Process Delete_VCSG_Subs_Data_VLR

Figure 20.3A/10 (sheet 1 of 2): Process Ins_VCSG_Subs_Data_Stand_Alone_SGSN

Figure 20.3A/10 (sheet 2 of 2): Process Ins_VCSG_Subs_Data_Stand_Alone_SGSN

Figure 20.3A/11: Process Delete_VCSG_Subs_Data_SGSN
20.4	Subscriber Identity procedure
In the subscriber identity procedure the IMSI of the subscriber is retrieved from the HLR. The procedure is shown in figure 20.4/1.


1)	Identity request
2)	MAP_SEND_IMSI_req/ind
3)	MAP_SEND_IMSI_rsp/cnf
4)	Identity confirm
Figure 20.4/1: The subscriber identity procedure
20.4.1	Procedure in the VLR
The subscriber identity process in the VLR is shown in figure 20.4/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf			see clause 25.1.2;
Check_Confirmation			see clause 25.2.2.
20.4.2	Procedure in the HLR
The subscriber identity process in the HLR is shown in figure 20.4/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind			see clause 25.1.1;
Check_Indication			see clause 25.2.1.


Figure 20.4/2: Process Send_IMSI_VLR

Figure 20.4/3: Process Send_IMSI_HLR
21	Call handling procedures
21.1	General
The MAP call handling procedures are used:
-	to retrieve routeing information to handle a mobile terminating call;
-	to transfer control of a call back to the GMSC if the call is to be forwarded;
-	to retrieve and transfer information between anchor MSC and relay MSC for inter MSC group calls / broadcast calls;
-	to handle the reporting of MS status for call completion services;
-	to handle the notification of remote user free for CCBS;
-	to handle the alerting and termination of ongoing call activities for a specific subscriber;
-	to handle early release of no longer needed resources;
-	to relay a mobile terminating call from the old to the new MSC during the Mobile Terminating Roaming Forwarding procedure.
The procedures to handle a mobile originating call and a mobile terminating call after the call has arrived at the destination MSC do not require any signalling over a MAP interface. These procedures are specified in 3GPP TS 23.018 [97].
The stage 2 specification for the retrieval of routeing information to handle a mobile terminating call is in 3GPP TS 23.018 [97]; modifications to this procedure for CAMEL are specified in 3GPP TS 23.078 [98], for optimal routeing of a basic mobile-to-mobile call in 3GPP TS 23.079 [99] and for CCBS in 3GPP TS 23.093 [107]. The interworking between the MAP signalling procedures and the call handling procedures for each entity (GMSC, HLR and VLR) is shown by the transfer of signals between these procedures.
The stage 2 specification for the transfer of control of a call back to the GMSC if the call is to be forwarded is in 3GPP TS 23.079 [99]. The interworking between the MAP signalling procedures and the call handling procedures for each entity (VMSC and GMSC) is shown by the transfer of signals between these procedures.
The stage 2 specifications for inter MSC group calls / broadcast calls are in 3GPP TS 43.068 [100] and 3GPP TS 43.069 [101]. The interworking between the MAP signalling procedures and the group call /broadcast call procedures for each entity (Anchor MSC and Relay MSC) is shown by the transfer of signals between these procedures.
The interworking between the call handling procedures and signalling protocols other than MAP are shown in 3GPP TS 23.018, 3GPP TS 23.078 and 3GPP TS 23.079 [99].
The stage 2 specification for the handling of reporting of MS status for call completion services and notification of remote user free for CCBS is in 3GPP TS 23.093 [107].
The stage 2 specification for the Mobile Terminating Roaming Forwarding procedure is in 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23].
21.2	Retrieval of routing information
21.2.1	General
The message flows for successful retrieval of routeing information for a mobile terminating call are shown in figure 21.2/1 (mobile terminating call which has not been optimally routed) and 21.2/2 (mobile-to-mobile call which has been optimally routed). The message flow for successful  retrieval of routeing information for a gsmSCF initiated call is shown in figure 21.2/3. The message flow for a successful  Mobile Terminating Roaming Forwarding procedure is shown in figure 21.2/4.


1)	I_IAM (Note 1)
2)	MAP_SEND_ROUTING_INFORMATION_req/ind (Note 2)
3)	MAP_PROVIDE_SUBSCRIBER_INFO_req/ind (Note 3, Note 4)
4)	MAP_PROVIDE_SUBSCRIBER_INFO_rsp/cnf (Note 4)
5)	MAP_SEND_ROUTING_INFORMATION_rsp/cnf (Note 4)
6)	MAP_SEND_ROUTING_INFORMATION_req/ind (Note 4)
7)	MAP_PROVIDE_ROAMING_NUMBER_req/ind
8)	MAP_PROVIDE_ROAMING_NUMBER_rsp/cnf
9)	MAP_SEND_ROUTING_INFORMATION_rsp/cnf
10)	I_IAM (Note 1)
11)	MAP_RESTORE_DATA_req/ind (Note 4)
12)	MAP_INSERT_SUBSCRIBER_DATA_req/ind (Note 4)
13)	MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf (Note 4)
12)	MAP_RESTORE_DATA_rsp/cnf (Note 4)

NOTE 1:	TUP or ISUP may be used in signalling between MSCs, depending on the network type between the MSCs. For further details on the TUP and ISUP procedures refer to the following ITU-T Recommendations and ETSI specification:
	-	Q.721‑725 ‑ Telephone User Part (TUP);
	-	ETS 300 356-1 ‑ Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part	(ISUP) version 2 for the international interface; Part 1: Basic services.
NOTE 2:	This service may also be used by an ISDN exchange for obtaining routing information from the HLR.
NOTE 3:	As a network operator option, the HLR sends MAP_PROVIDE_SUBSCRIBER_INFORMATION to the VLR. For further details on the CAMEL procedures refer to 3GPP TS 23.078 [98].
NOTE 4:	Services printed in italics are optional.

Figure 21.2/1: Message flow for retrieval of routeing information (non-optimally routed call)


1)	I_IAM (Note 1)
2)	MAP_SEND_ROUTING_INFORMATION_req/ind
3)	MAP_PROVIDE_SUBSCRIBER_INFO_req/ind (Note 2)
4)	MAP_PROVIDE_SUBSCRIBER_INFO_rsp/cnf (Note 2)
5)	MAP_PROVIDE_ROAMING_NUMBER_req/ind (Note 2)
6)	MAP_PROVIDE_ROAMING_NUMBER_rsp/cnf (Note 2)
7)	MAP_SEND_ROUTING_INFORMATION_rsp/cnf
8)	I_IAM (Note 1)
9)	MAP_RESTORE_DATA_req/ind (Note 3)
10)	MAP_INSERT_SUBSCRIBER_DATA_req/ind (Note 3)
11)	MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf (Note 3)
12)	MAP_RESTORE_DATA_rsp/cnf (Note 3)

NOTE 1:	TUP or ISUP may be used in signalling between MSCs, depending on the network type between the MSCs. For further details on the TUP and ISUP procedures refer to the following ITU-T Recommendations & ETSI specification:
	-	Q.721‑725 ‑ Telephone User Part (TUP);
	-	ETS 300 356-1 ‑ Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part	(ISUP) version 2 for the international interface; Part 1: Basic services.
NOTE 2:	For Optimal Routeing phase 1, only one of the information flows for Provide Subscriber Info and Provide Roaming Number is used.
NOTE 3:	Services printed in italics are optional.

Figure 21.2/2: Message flow for retrieval of routeing information (optimally routed call)


1)	MAP_SEND_ROUTING_INFORMATION_req/ind
2)	MAP_SEND_ROUTING_INFORMATION_rsp/cnf (Note 1)
3)	MAP_SEND_ROUTING_INFORMATION_req/ind (Note 1)
4)	MAP_PROVIDE_ROAMING_NUMBER_req/ind
5)	MAP_PROVIDE_ROAMING_NUMBER_rsp/cnf
6)	MAP_SEND_ROUTING_INFORMATION_rsp/cnf
7)	MAP_RESTORE_DATA_req/ind (Note 1)
8)	MAP_INSERT_SUBSCRIBER_DATA_req/ind (Note 1)
9)	MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf (Note 1)
10)	MAP_RESTORE_DATA_rsp/cnf (Note 1)

NOTE 1:	Services printed in italics are optional.

Figure 21.2/3: Message flow for retrieval of routeing information for a gsmSCF initiated call 
The following MAP services are used to retrieve routing information:
MAP_SEND_ROUTING_INFORMATION	see clause 10.1;
MAP_PROVIDE_ROAMING_NUMBER	see clause 10.2;
MAP_PROVIDE_SUBSCRIBER_INFO	see clause 8.11.2;
MAP_RESTORE_DATA	see clause 8.10.3.


1)	I_IAM
2)	MAP_CANCEL_LOCATION_req/ind 
3)	MAP_PROVIDE_ROAMING_NUMBER_req/ind
4)	MAP_ PROVIDE_ROAMING_NUMBER_rsp/cnf
5)	I_IAM

Figure 21.2/4: Message flow for Mobile Terminating Roaming Forwarding
The following MAP services are used for the Mobile Terminating Roaming Forwarding procedure:
MAP_PROVIDE_ ROAMING_NUMBER	see clause 10.2;

21.2.2	Procedure in the GMSC
The MAP process in the GMSC to retrieve routeing information for a mobile terminating call is shown in figure 21.2/6. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
Sheet 1: if the MAP_SEND_ROUTING_INFORMATION request included the OR Interrogation parameter, the test "OR interrogation?" takes the "Yes" exit; otherwise the test takes the "No" exit.
21.2.9	Process in the gsmSCF
For the purposes of retrieving routeing information from the HLR, the gsmSCF takes the role of the GMSC  and follows the process specified in clause 21.2.2.
21.2.4	Procedure in the HLR
The MAP process in the HLR to retrieve routeing information for a mobile terminating call is shown in figure 21.2/7. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind	see clause 25.1.1;
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
Sheet 3: if the MAP_PROVIDE_ROAMING_NUMBER request included the OR Interrogation parameter, the test "OR interrogation?" takes the "Yes" exit; otherwise the test takes the "No" exit.
21.2.5	Procedure in the VLR to provide a roaming number
The MAP process in the VLR to provide a roaming number for a mobile terminating call is shown in figure 21.2/8. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind	see clause 25.1.1;
21.2.6	Procedure in the VLR to restore subscriber data
The MAP process in the HLR to restore subscriber data is shown in figure 21.2/9. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2;
Insert_Subs_Data_VLR	see clause 25.7.1;
Activate_Tracing_VLR	see clause 25.9.4.
21.2.7	Procedure in the VLR to provide subscriber information
The MAP process in the VLR to provide subscriber information for a mobile terminating call subject to CAMEL invocation is shown in figure 21.2/9. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind	see clause 25.1.1;
21.2.8	Procedure in the old VLR to request a Roaming Number (MTRF) 
The MAP process in the old VLR for Mobile Terminating Roaming Forwarding is shown in figure 21.2/11. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Cnf	see clause 25.1.2
Check_Confirmation	see clause 25.2.2


Figure 21.2/6 (sheet 1 of 2): Process SRI_GMSC

Figure 21.2/6 (sheet 2 of 2): Process SRI_GMSC

Figure 21.2/7 (sheet 1 of 3): Process SRI_HLR

Figure 21.2/7 (sheet 2 of 3): Process SRI_HLR

Figure 21.2/7 (sheet 3 of 3): Process SRI_HLR

Figure 21.2/8: Process PRN_VLR

Figure 21.2/9: Process Restore_Data_VLR

Figure 21.2/10: Process PSI_VLR

Figure 21.2/11: Process PRN_Old_VLR
21.3	Transfer of call handling
21.3.1	General
The message flow for successful transfer of call handling to forward a call is shown in figure 21.3/1.


1)	MAP_RESUME_CALL_HANDLING_req/ind
2)	MAP_SEND_ROUTING_INFORMATION_req/ind (Note 2)
3)	MAP_SEND_ROUTING_INFORMATION_rsp/cnf (Note 2)
4)	MAP_RESUME_CALL_HANDLING_rsp/cnf
5)	I_REL (Note 1)
6)	I_IAM (Note 1)

NOTE 1:	TUP or ISUP may be used in signalling between MSCs, depending on the network type between the MSCs. For further details on the TUP and ISUP procedures refer to the following ITU-T Recommendations & ETSI specification:
	-	Q.721‑725 ‑ Telephone User Part (TUP);
	-	ETS 300 356-1 ‑ Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part	(ISUP) version 2 for the international interface; Part 1: Basic services.
NOTE 2:	Services printed in italics are optional.

Figure 21.3/1: Message flow for transfer of call handling
If the HLR indicated in the response to the original request for routeing information that forwarding interrogation is required, the GMSC executes the Send Routeing Information procedure with the HLR to obtain forwarding information; otherwise the GMSC uses the forwarding data which were sent in the MAP_RESUME_CALL_HANDLING req/ind.
21.3.2	Process in the VMSC
The MAP process in the VMSC to retrieve routeing information for a mobile terminating call is shown in figure 21.3/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
If the capacity of a message signal unit in the lower layers of the protocol is enough to carry all the information which has to be sent to the GMSC, the test "Segmentation needed?" takes the "No" exit; otherwise the test takes the "Yes" exit.
21.3.3	Process in the GMSC
The MAP process in the GMSC to handle a request for the GMSC to resume call handling is shown in figure 21.3/3. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind	see clause 25.1.1;
If the parameter All Information Sent was present in the MAP_RESUME_CALL_HANDLING indication, the test "All Information Sent" takes the "Yes" exit; otherwise the test takes the "No" exit.


Figure 21.3/2: Process RCH_VMSC

Figure 21.3/3: Process RCH_GMSC
21.4	Inter MSC Group Call Procedures
21.4.1	General
The message flow for successful inter MSC group call / broadcast call set-up is shown in figure 21.4/1.


1)	I_IAM (Note 1)
2)	MAP_PREPARE_GROUP_CALL_req/ind
3)	MAP_PREPARE_GROUP_CALL_rsp/cnf
4)	I_IAM (Note 1)
5)	MAP_SEND_GROUP_CALL_END_SIGNAL_req/ind
6)	I_ACM (Note 1)
7)	I_ACM (Note 1)
8)	MAP_FORWARD_GROUP_CALL_SIGNALLING_req/ind (Note 2)
9)	MAP_PROCESS_GROUP_CALL_SIGNALLING_req/ind (Note 2)
10)	MAP_SEND_GROUP_CALL_END_SIGNAL_rsp/cnf
11)	I_REL (Note 3)
12)	I_REL (Note 3)

NOTE 1:	TUP or ISUP may be used in signalling between MSCs, depending on the network type between the MSCs. For further details on the TUP and ISUP procedures refer to the following ITU-T Recommendations and ETSI specification:
	-	Q.721‑725 ‑ Telephone User Part (TUP);
	-	ETS 300 356-1 ‑ Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part	(ISUP) version 2 for the international interface; Part 1: Basic services.
NOTE 2:	The MAP_FORWARD_GROUP_CALL_SIGNALLING and MAP_PROCESS_GROUP_CALL_SIGNALLING services are not applicable for voice broadcast calls.
NOTE 3:	The call can be released from the PSTN/ISDN or the Relay MSC

Figure 21.4/1: Message flow for inter MSC group call / broadcast call
21.4.2	Process in the Anchor MSC
The MAP process in the Anchor MSC to retrieve and transfer information from / to the Relay MSC for VBS and VGCS calls is shown in figure 21.4/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Indication	see clause 25.2.1;
Check_Confirmation	see clause 25.2.2.
21.4.3	Process in the Relay MSC
The MAP process in the Relay MSC to receive and transfer information from / to the Anchor MSC for VBS and VGCS calls is shown in figure 21.4/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind	see clause 25.1.2;
Check_Indication	see clause 25.2.1.


Figure 21.4/2 (sheet 1 of 2): Process ASCI_Anchor_MSC

Figure 21.4/2 (sheet 2 of 2): Process ASCI_Anchor_MSC

Figure 21.4/3 (sheet 1 of 2): Process ASCI_Relay_MSC

Figure 21.4/3 (sheet 2 of 2): Process ASCI_Relay_MSC
21.4A	Inter MSC Group Call Info Retrieval
21.4A.1	General
The message flow for successful inter MSC group call info retrieval is shown in figure 21.4A/1.

Figure 21.4A/1: Message flow for inter MSC group call info retrieval
21.4A.2	Process in the MSC
The MAP process in the MSC to retrieve and group call information is shown in figure 21.4A/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
Receive_Open_Ind	see clause 25.1.2;


Figure 21.4A/2 (sheet 1 of 2): Process Group_Call_Info_Retrieval_MSC

Figure 21.4A/2 (sheet 2 of 2): Process Group_Call_Info_Retrieval_MSC

21.5	Void
21.6	CCBS: monitoring and reporting the status of the subscriber
21.6.1	Reporting co-ordinator process in the VLR
The MAP co-ordinating process in the VLR to handle a dialogue opened with the reporting application context is shown in figure 21.6/6. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind	see clause 25.1.1.

21.6.2	Setting the reporting state – stand-alone
The message flow for setting the reporting state in a stand-alone dialogue is shown in figure 21.6/1.


1)	MAP_SET_REPORTING_STATE_req/ind
2)	MAP_SET_REPORTING_STATE_rsp/cnf

Figure 21.6/1: Message flow for setting the reporting state – stand-alone dialogue
21.6.2.1	Process in the HLR
The MAP process in the HLR to set the reporting state in the VLR in a stand-alone dialogue is shown in figure 21.6/7. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
The result of a request to stop reporting is not reported to the CCBS application in the HLR.
21.6.2.2	Process in the VLR
The MAP process in the VLR to set the reporting state is shown in figure 21.6/8.
The macro Set_Reporting_State_VLR is shown in figure 21.6/9.
21.6.3	Status Reporting
The message flows for reporting the status of a subscriber are shown in figures 21.6/2 and 21.6/3.


1)	MAP_STATUS_REPORT_req/ind
2)	MAP_STATUS_REPORT_rsp/cnf

Figure 21.6/2: Message flow for status reporting, when monitoring continues in the VLR


1)	MAP_STATUS_REPORT_req/ind
2)	MAP_STATUS_REPORT_rsp/cnf
3)	MAP_SET_REPORTING_STATE_req/ind
4)	MAP_SET_REPORTING_STATE_rsp/cnf

Figure 21.6/3: Message flow for status reporting, when monitoring stops
The MAP_SET_REPORTING_STATE request is used to stop monitoring in the VLR. If the HLR requires the VLR to continue monitoring, it closes the dialogue without sending a MAP_SET_REPORTING_STATE request.
21.6.3.1	Process in the VLR 
The MAP process in the VLR to send a status report to the HLR is shown in figure 21.6/10. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
This process can be used to report:
-	an event, such as the user becoming free, or 
-	the result of a CCBS call attempt
to the HLR
21.6.3.2	Process in the HLR 
The MAP process in the HLR to handle a status report is shown in figure 21.6/11. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind	see clause 25.1.1;
It is an implementation option whether to send the MAP_DELIMITER request before invoking the macro Set_Reporting_State_HLR.
The macro Receive_Status_Report_HLR is shown in figure 21.6/12.
The macro Set_Reporting_State_HLR is shown in figure 21.6/13. The macro invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Check_Confirmation	see clause 25.2.2.
21.6.4	CCBS: Remote User Free
The message flows for handling remote user free are shown in figures 21.6/4 and 21.6/5.


1)	MAP_REMOTE_USER_FREE_req/ind
2)	MAP_REMOTE_USER_FREE_rsp/cnf

Figure 21.6/4: Remote User Free: recall not accepted


1)	MAP_REMOTE_USER_FREE_req/ind
2)	MAP_REMOTE_USER_FREE_rsp/cnf
3)	MAP_STATUS_REPORT_req/ind
4)	MAP_STATUS_REPORT_rsp/cnf

Figure 21.6/5: Remote User Free: recall accepted
21.6.4.1	Process in the HLR 
The MAP process in the HLR to handle Remote User Free is shown in figure 21.6/14. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
21.6.3.2	Process in the VLR 
The MAP process in the VLR to handle Remote User Free is shown in figure 21.6/15. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Check_Confirmation	see clause 25.2.2.


Figure 21.6/6: Process Reporting_Coord_VLR

Figure 21.6/7: Process Set_Reporting_State_Stand_Alone_HLR

Figure 21.6/8: Process Set_Reporting_State_VLR

Figure 21.6/9: Macro Receive_Set_Reporting_State_VLR

Figure 21.6/10 (sheet 1 of 2): Process Send_Status_Report_VLR

Figure 21.6/10 (sheet 2 of 2): Process Send_Status_Report_VLR

Figure 21.6/11: Process Status Report_HLR

Figure 21.6/12: Macro Receive_Status_Report_HLR

Figure 21.6/13: Macro Set_Reporting_State_HLR

Figure 21.6/14: Process Remote_User_Free_HLR

Figure 21.6/15 (sheet 1 of 2): Process Remote_User_Free_VLR

Figure 21.6/15 (sheet 2 of 2): Process Remote_User_Free_VLR
21.7	Void
21.8	Void
21.9	Immediate Service Termination (IST)
21.9.1	IST Alert
The Immediate Service Termination Alert procedure is used to keep track of the call activities performed by subscribers who are marked as being subject to IST monitoring and, possibly, to terminate the call activities for which the alert was sent, or all the call activities related to the subscriber for whom the alert was sent.
The message flow for alerting is shown in figure 21.9/1; the MSC may be a Visited MSC or a Gateway MSC.


1)	MAP_IST_ALERT_req/ind
2)	MAP_IST_ALERT_rsp/cnf

Figure 21.9/1: Message flow for IST Alert
21.9.1.1	Procedure in the MSC
The MAP process in the MSC (Visited MSC or Gateway MSC) is shown in figure 21.9/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
	Receive_Open_Cnf	see clause 25.1.2;
	Check_Confirmation	see clause 25.2.2.
21.9.1.2	Procedure in the HLR
The MAP process in the HLR is shown in figure 21.9/4. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind	see clause 25.1.1;
21.9.2	IST Command
The Immediate Service Termination Command procedure is used to terminate the call activities related to a subscriber.
The message flow for the IST Command procedure is shown in figure 21.9/2; the MSC may be a Visited MSC or a Gateway MSC.


1)	MAP_IST_COMMAND_req/ind
2)	MAP_IST_COMMAND_rsp/cnf

Figure 21.9/2: Message flow for IST Command
21.9.2.1	Procedure in the HLR
The MAP process in the HLR is shown in figure 21.9/5. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
21.9.2.2	Procedure in the MSC
The MAP process in the MSC is shown in figure 21.9.6. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
	Receive_Open_Ind	see clause 25.1.1.


Figure 21.9/3: Process IST_Alert_MSC

Figure 21.9/4: Process IST_Alert_HLR

Figure 21.9/5: Process IST_Command_HLR

Figure 21.9/6: Process IST_Command_MSC
21.10	Resource Management
21.10.1	General
The message flow for successful release of resources is shown in figure 21.10/1.


1)	I_IAM (Note 1)
2)	MAP_SEND_ROUTING_INFORMATION_req/ind 
3)	MAP_PROVIDE_ROAMING_NUMBER_req/ind 
4)	I_REL (Note 1)
5)	MAP_PROVIDE_ROAMING_NUMBER_rsp/cnf
6)	MAP_SEND_ROUTING_INFORMATION_rsp/cnf 
7)	MAP_RELEASE_RESOURCES (Note 2)

NOTE 1:	TUP or ISUP may be used in signalling between MSCs, depending on the network type between the MSCs. For further details on the TUP and ISUP procedures refer to the following ITU-T Recommendations & ETSI specification:
	-	Q.721‑725 ‑ Telephone User Part (TUP);
	-	ETS 300 356-1 ‑ Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part	(ISUP) version 2 for the international interface; Part 1: Basic services.
NOTE 2:	Services printed in italics are optional.

Figure 21.10/1: Message flow for early release of resources
21.3.2	Process in the GMSC
The MAP process in the GMSC to release resources is shown in figure 21.10/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
21.3.3	Process in the VMSC
The MAP process in the VMSC to handle a request for the GMSC to release resources is shown in figure 21.10/3. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind	see clause 25.1.1;


Figure 21.10/2: Process Release Resources_GMSC

Figure 21.10/3: Process Release Resources_VMSC
22	Supplementary services procedures
22.1	Supplementary service co-ordinator processes
22.1.1	Supplementary service co-ordinator process for the MSC
The co-ordinator process in the MSC to handle a CM connection request with CM service type Supplementary service activation is shown in figure 22.1/1. The process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Process_Access_Request_MSC	see clause 25.4.1.
22.1.2	Void
22.1.3	Functional supplementary service co-ordinator process for the HLR
The MAP co-ordinator process in the HLR to handle a dialogue opened with the networkFunctionalSS application context is shown in figure 22.1/3. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind	see clause 25.1.1.
22.1.4	Call completion supplementary service co-ordinator process for the HLR
The MAP co-ordinator process in the HLR to handle a dialogue opened with the callCompletion application context is shown in figure 22.1/4. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind	see clause 25.1.1.


Figure 22.1/1 (sheet 1 of 2): Process SS_Coordinator_MSC

Figure 22.1/1 (sheet 2 of 2): Process SS_Coordinator_MSC
Figure 22.1/2 void

Figure 22.1/3: Process SS_Coordinator_HLR

Figure 22.1/4: Process CC_Coordinator_HLR
22.2	Registration procedure
22.2.1	General
The registration procedure is used to register data related to a supplementary service in the HLR. The registration procedure is a fully transparent communication between the MS and the HLR, except that some services may be invoked as a result of the procedure, as described in the clauses below.
The registration procedure is shown in figure 22.2.1/1.
The following services may be used:
MAP_PROCESS_ACCESS_REQUEST	(see clauses 8 and 25);
MAP_TRACE_SUBSCRIBER_ACTIVITY	(see clauses 9 and 25);
MAP_PROVIDE_IMSI		(see clauses 8 and 25);
MAP_FORWARD_NEW_TMSI	(see clauses 8 and 25);
MAP_AUTHENTICATE		(see clauses 8 and 25);
MAP_SET_CIPHERING_MODE	(see clauses 8 and 25);
MAP_CHECK_IMEI		(see clauses 8 and 25);
MAP_READY_FOR_SM		(see clauses 12 and 25);
MAP_INSERT_SUBSCRIBER_DATA	(see clauses 8 and 25);
The following service is certainly used:
MAP_REGISTER_SS		(defined in clause 11).


1)	A_CM_SERV_REQ (Note 1)
2)	MAP_PROCESS_ACCESS_REQUEST (Note 2)
3)	A_REGISTER_SS (Note 1)
4)	MAP_REGISTER_SS_req/ind
5)	MAP_REGISTER_SS_req/ind
6)	MAP_REGISTER_SS_rsp/cnf
7)	MAP_REGISTER_SS_rsp/cnf
8)	A_REGISTER_SS ack (Note 1)
9)	MAP_INSERT_SUBSCRIBER_DATA_req/ind (Note 3)
10)	MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf (Note 3)

NOTE 1:	For details of the procedure on the radio path, see 3GPP TS 24.008 [35], 3GPP TS 24.010 [36], 3GPP TS 24.08x and 3GPP TS 24.09x. Services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path.
NOTE 2:	For details of the Process Access Request procedure, refer to clause 25.4 in the present document.
NOTE 3:	Services printed in italics are optional.

Figure 22.2.1/1: Message flow for supplementary service registration
22.2.2	Procedure in the MSC
The A_REGISTER_SS service indication received by the MAP process in the MSC contains the SS-Code and any parameters that are related to the supplementary service.
The MAP user transfers the received information to the VLR in the MAP_REGISTER_SS request without checking the contents of the service indication. Rules for the mapping are described in 3GPP TS 29.011 [59].
The information in the MAP_REGISTER_SS confirm from the VLR is relayed to the MS in the A_REGISTER_SS response message as described in 3GPP TS 24.08x, 3GPP TS 24.08x and 3GPP TS 29.011.
For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]).
The registration process in the MSC is shown in figure 22.2.2/1.
22.2.3	Procedure in the VLR
The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind		see clause 25.1.1;
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2;
Process_Access_Request_VLR	see clause 25.4.2.
The MAP process in the VLR transfers the information received in the MAP_REGISTER_SS indication to the HLR in the MAP_REGISTER_SS request without checking the contents. The MAP_OPEN request includes the IMSI of the subscriber as the destination reference and the VLR number as the originating reference.
If the MAP_REGISTER_SS confirm is properly formed and contains a result or a user error, the MAP process in the VLR shall transfer the information contained in this primitive to the MSC in the MAP_REGISTER_SS response.
For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]).
The registration process in the VLR is shown in figure 22.2.3/1.
22.2.4	Procedure in the HLR
The MAP process invokes a macro and a process not defined in this clause; the definitions of the macro and process can be found as follows:
Check_Indication			see clause 25.2.1;
Insert_Subs_Data_Stand_Alone_HLR	see clause 25.7.3.
The supplementary service request shall be processed according to 3GPP TS 23.011 [22] and the 23.08x and 23.09x-series of technical specifications. This handling may lead to a successful result, a partially successful result or an error being returned.
For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]):
The registration process in the HLR is shown in figure 22.2.4/1.


Figure 22.2.2/1: Process Register_SS_MSC

Figure 22.2.3/1 (sheet 1 of 2): Process Register_SS_VLR

Figure 22.2.3/1 (sheet 2 of 2): Process Register_SS_VLR

Figure 22.2.4/1: Process Register_SS_HLR
22.3	Erasure procedure
22.3.1	General
The erasure procedure is used to erase data related to a supplementary service in the HLR. The erasure procedure is a fully transparent communication between the MS and the HLR, except that some services may be invoked as a result of the procedure, as described in the clauses below.
The erasure procedure is shown in figure 22.3.1/1.
The following services may be used:
MAP_PROCESS_ACCESS_REQUEST	(see clauses 8 and 25);
MAP_TRACE_SUBSCRIBER_ACTIVITY	(see clauses 9 and 25);
MAP_PROVIDE_IMSI		(see clauses 8 and 25);
MAP_FORWARD_NEW_TMSI	(see clauses 8 and 25);
MAP_AUTHENTICATE		(see clauses 8 and 25);
MAP_SET_CIPHERING_MODE	(see clauses 8 and 25);
MAP_CHECK_IMEI		(see clauses 8 and 25);
MAP_READY_FOR_SM		(see clauses 12 and 25);
MAP_INSERT_SUBSCRIBER_DATA	(see clauses 8 and 25);
The following service is certainly used:
MAP_ERASE_SS		(defined in clause 11).


1)	A_CM_SERV_REQ (Note 1)
2)	MAP_PROCESS_ACCESS_REQUEST (Note 2)
3)	A_ERASE_SS (Note 1)
4)	MAP_ERASE_SS_req/ind
5)	MAP_ERASE_SS_req/ind
6)	MAP_ERASE_SS_rsp/cnf
7)	MAP_ERASE_SS_rsp/cnf
8)	A_ERASE_SS ack (Note 1)
9)	MAP_INSERT_SUBSCRIBER_DATA_req/ind (Note 3)
10)	MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf (Note 3)

NOTE 1:	For details of the procedure on the radio path, see 3GPP TS 24.008 [35], 3GPP TS 24.010 [36], 3GPP TS 24.08x and 3GPP TS 24.09x. Services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path.
NOTE 2:	For details of the Process Access Request procedure, refer to clause 25.4 in the present document.
NOTE 3:	Services printed in italics are optional.

Figure 22.3.1/1: Message flow for supplementary service erasure
22.3.2	Procedure in the MSC
The MSC procedure for erasure is identical to that specified for registration in clause 22.2.2. The text and diagrams in clause 22.2.2 apply with all references to registration changed to erasure.
22.3.3	Procedure in the VLR
The VLR procedure for erasure is identical to that specified for registration in clause 22.2.3. The text and diagrams in clause 22.2.3 apply with all references to registration changed to erasure.
22.3.4	Procedure in the HLR
The HLR procedure for erasure is identical to that specified for registration in clause 22.2.4. The text and diagrams in clause 22.2.4 apply with all references to registration changed to erasure.
22.4	Activation procedure
22.4.1	General
The activation procedure is used to activate a supplementary service in the HLR. The activation procedure is a fully transparent communication between the MS and the HLR, except that some services may be invoked as a result of the procedure, as described in the clauses below.
The activation procedure is shown in figure 22.4.1/1.
The following services may be used:
MAP_PROCESS_ACCESS_REQUEST	(see clauses 8 and 25);
MAP_TRACE_SUBSCRIBER_ACTIVITY	(see clauses 9 and 25);
MAP_PROVIDE_IMSI		(see clauses 8 and 25);
MAP_FORWARD_NEW_TMSI	(see clauses 8 and 25);
MAP_AUTHENTICATE		(see clauses 8 and 25);
MAP_SET_CIPHERING_MODE	(see clauses 8 and 25);
MAP_CHECK_IMEI		(see clauses 8 and 25);
MAP_READY_FOR_SM		(see clauses 12 and 25);
MAP_GET_PASSWORD		(defined in clause 11);
MAP_INSERT_SUBSCRIBER_DATA	(see clauses 8 and 25);
The following service is certainly used:
MAP_ACTIVATE_SS		(defined in clause 11).


1)	A_CM_SERV_REQ (Note 1)
2)	MAP_PROCESS_ACCESS_REQUEST (Note 2)
3)	A_ACTIVATE_SS (Note 1)
4)	MAP_ACTIVATE_SS_req/ind
5)	MAP_ACTIVATE_SS_req/ind
6)	MAP_GET_PASSWORD_req/ind (Note 3)
7)	MAP_GET_PASSWORD_req/ind (Note 3)
8)	A_GET_PASSWORD (Note 1, Note 3)
9)	A_GET_PASSWORD ack (Note 1, Note 3)
10)	MAP_GET_PASSWORD_rsp/cnf (Note 3)
11)	MAP_GET_PASSWORD_rsp/cnf (Note 3)
12)	MAP_ACTIVATE_SS_rsp/cnf
13)	MAP_ACTIVATE_SS_rsp/cnf
14)	A_ACTIVATE_SS ack (Note 1)
15)	MAP_INSERT_SUBSCRIBER_DATA_req/ind (Note 3)
16)	MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf (Note 3)

NOTE 1:	For details of the procedure on the radio path, see 3GPP TS 24.008 [35], 3GPP TS 24.010 [36], 3GPP TS 24.08x and 3GPP TS 24.09x. Services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path.
NOTE 2:	For details of the Process Access Request procedure, refer to clause 25.4 of this document.
NOTE 3:	Services printed in italics are optional.

Figure 22.4.1/1: Message flow for supplementary service activation
22.4.2	Procedure in the MSC
The A_ACTIVATE_SS service indication received by the MAP user in the MSC contains the SS-Code and any parameters related to the supplementary service.
The MSC transfers the received information to the VLR in the MAP_ACTIVATE_SS request without checking the contents of the service indication. Rules for the mapping are described in 3GPP TS 29.011 [59].
The information in the MAP_ACTIVATE_SS confirm from the VLR is relayed to the MS in the A_ACTIVATE_SS response message, as described in TS 24.08x, 3GPP TS 24.08x and 3GPP TS 29.011.
For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]).
The activation process in the MSC is shown in figure 22.4.2/1.
22.4.3	Procedure in the VLR
The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind		see clause 25.1.1;
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2;
Process_Access_Request_VLR	see clause 25.4.2.
The MAP process in the VLR transfers the information received in the MAP_ACTIVATE_SS indication to the HLR in the MAP_ACTIVATE_SS request without checking the contents. The MAP_OPEN request includes the IMSI of the subscriber as the destination reference and the VLR number as the originating reference.
If the MAP_REGISTER_SS confirm is properly formed and contains a result or a user error, the MAP process in the VLR shall transfer the information contained in this primitive to the MSC in the MAP_ACTIVATE_SS response.
For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]).
The activation process in the VLR is shown in figure 22.4.3/1.
22.4.4	Procedure in the HLR
The MAP process invokes a macro and a process not defined in this clause; the definitions of the macro and process can be found as follows:
Check_Indication			see clause 25.2.1;
Insert_Subs_Data_Stand_Alone_HLR	see clause 25.7.3.
The supplementary service request shall be processed according to 3GPP TS 23.011 [22] and the 23.08x and 23.09x-series of technical specifications. This handling may lead to a successful result, a partially successful result or an error being returned.
For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]):
The activation process in the HLR is shown in figure 22.4.4/1.


Figure 22.4.2/1: Process Activate_SS_MSC

Figure 22.4.3/1 (sheet 1 of 2): Process Activate_SS_VLR

Figure 22.4.3/1 (sheet 2 of 2): Process Activate_SS_VLR

Figure 22.4.4/1 (sheet 1 of 2): Process Activate_SS_HLR

Figure 22.4.4/1 (sheet 2 of 2): Process Activate_SS_HLR
22.5	Deactivation procedure
22.5.1	General
The deactivation procedure is used to deactivate a supplementary service in the HLR. The deactivation procedure is a fully transparent communication between the MS and the HLR, except that some services may be invoked as a result of the procedure, as described in the clauses below.
The deactivation procedure is shown in figure 22.5.1/1.
The following services may be used:
MAP_PROCESS_ACCESS_REQUEST	(see clauses 8 and 25);
MAP_TRACE_SUBSCRIBER_ACTIVITY	(see clauses 9 and 25);
MAP_PROVIDE_IMSI		(see clauses 8 and 25);
MAP_FORWARD_NEW_TMSI	(see clauses 8 and 25);
MAP_AUTHENTICATE		(see clauses 8 and 25);
MAP_SET_CIPHERING_MODE	(see clauses 8 and 25);
MAP_CHECK_IMEI		(see clauses 8 and 25);
MAP_READY_FOR_SM		(see clauses 12 and 25);
MAP_GET_PASSWORD		(defined in clause 11);
MAP_INSERT_SUBSCRIBER_DATA	(see clauses 8 and 25);
The following service is certainly used:
MAP_DEACTIVATE_SS		(defined in clause 11).


1)	A_CM_SERV_REQ (Note 1)
2)	MAP_PROCESS_ACCESS_REQUEST (Note 2)
3)	A_DEACTIVATE_SS (Note 1)
4)	MAP_DEACTIVATE_SS_req/ind
5)	MAP_DEACTIVATE_SS_req/ind
6)	MAP_GET_PASSWORD_req/ind (Note 3)
7)	MAP_GET_PASSWORD_req/ind (Note 3)
8)	A_GET_PASSWORD (Note 1, Note 3)
9)	A_GET_PASSWORD ack (Note 1, Note 3)
10)	MAP_GET_PASSWORD_rsp/cnf (Note 3)
11)	MAP_GET_PASSWORD_rsp/cnf (Note 3)
12)	MAP_DEACTIVATE_SS_rsp/cnf
13)	MAP_DEACTIVATE_SS_rsp/cnf
14)	A_DEACTIVATE_SS ack (Note 1)
15)	MAP_INSERT_SUBSCRIBER_DATA_req/ind (Note 3)
16)	MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf (Note 3)

NOTE 1:	For details of the procedure on the radio path, see 3GPP TS 24.008 [35], 3GPP TS 24.010 [36], 3GPP TS 24.08x and 3GPP TS 24.09x. Services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path.
NOTE 2:	For details of the Process Access Request procedure, refer to clause 25.4 in the present document.
NOTE 3:	Services printed in italics are optional.

Figure 22.5.1/1: Message flow for supplementary service deactivation
22.5.2	Procedure in the MSC
The MSC procedure for deactivation is identical to that specified for activation in clause 22.4.2. The text and diagrams in clause 22.4.2 apply with all references to activation changed to deactivation.
22.5.3	Procedures in the VLR
The VLR procedure for deactivation is identical to that specified for activation in clause 22.4.3. The text and diagrams in clause 22.4.3 apply with all references to activation changed to deactivation.
22.5.4	Procedures in the HLR
The HLR procedure for deactivation is identical to that specified for activation in clause 22.4.4. The text and diagrams in clause 22.4.4 apply with all references to activation changed to deactivation.
22.6	Interrogation procedure
22.6.1	General
The interrogation procedure is used to retrieve information related to a supplementary service from the VLR or the HLR. It is the VLR which decides whether an interrogation request should be forwarded to the HLR or not. Some non-supplementary service related services may be invoked as a result of the procedure, as described in the clauses below.
The interrogation procedure is shown in figure 22.6.1/1.
The following services may be used:
MAP_PROCESS_ACCESS_REQUEST	(see clauses 8 and 25);
MAP_TRACE_SUBSCRIBER_ACTIVITY	(see clauses 9 and 25);
MAP_PROVIDE_IMSI		(see clauses 8 and 25);
MAP_FORWARD_NEW_TMSI	(see clauses 8 and 25);
MAP_AUTHENTICATE		(see clauses 8 and 25);
MAP_SET_CIPHERING_MODE	(see clauses 8 and 25);
MAP_CHECK_IMEI		(see clauses 8 and 25);
MAP_READY_FOR_SM		(see clauses 12 and 25);
The following service is certainly used:
MAP_INTERROGATE_SS		(defined in clause 11).


1)	A_CM_SERV_REQ (Note 1)
2)	MAP_PROCESS_ACCESS_REQUEST (Note 2)
3)	A_INTERROGATE_SS (Note 1)
4)	MAP_INTERROGATE_SS_req/ind
5)	MAP_INTERROGATE_SS_req/ind
6)	MAP_INTERROGATE_SS_rsp/cnf
7)	MAP_INTERROGATE_SS_rsp/cnf
8)	A_INTERROGATE_SS ack (Note 1)

NOTE 1:	For details of the procedure on the radio path, see 3GPP TS 24.008 [35], 3GPP TS 24.010 [36], 3GPP TS 24.08x and 3GPP TS 24.09x. Services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path.
NOTE 2:	For details of the Process Access Request procedure, refer to clause 25.4 in the present document.
NOTE 3:	Services printed in italics are optional.

Figure 22.6.1/1: Message flow for supplementary service interrogation
22.6.2	Procedure in the MSC
The MSC procedures for interrogation are identical to those specified for registration in clause 22.2.2. The text and diagrams in clause 22.2.2 apply with all references to registration changed to interrogation.
22.6.3	Procedures in the VLR
The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind		see clause 25.1.1;
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2;
Process_Access_Request_VLR	see clause 25.4.2.
The interrogation is answered either by the VLR or by the HLR, depending on the service interrogated.
1)	Interrogation to be handled by the VLR
The supplementary service request shall be processed according to 3GPP TS 23.011 [22] and the 23.08x and 23.09x-series of technical specifications. This handling may lead to a successful result, a partially successful result or an error being returned.
For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]).
2)	Interrogation to be handled by the HLR
If the interrogation is to be handled by the HLR, the MAP process in the VLR transfers the information received in the MAP_INTERROGATE_SS indication to the HLR in the MAP_INTERROGATE_SS request without checking the contents of the service indication. The MAP_OPEN request includes the IMSI of the subscriber as the destination reference and the VLR number as the originating reference.
If the MAP_INTERROGATE_SS confirm is properly formed and contains a result or a user error, the MAP process in the VLR shall transfer the information contained in this primitive to the MSC in the MAP_INTERROGATE_SS response.
For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]).
The Interrogation process in the VLR is shown in figure 22.6.3/1.
22.6.4	Procedure in the HLR
The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Check_Indication			see clause 25.2.1.
The HLR acts as follows:
The interrogation is answered either by the VLR or by the HLR, depending on the service interrogated.
1)	Interrogation to be handled by the VLR
	If the interrogation procedure should have been answered by the VLR, then the HLR assumes that the VLR does not support the interrogated supplementary service, and returns the SS Not Available error to the VLR.
2)	Interrogation to be handled by HLR
	The supplementary service request shall be processed according to 3GPP TS 23.011 [22] and the 23.08x and 23.09x-series of technical specifications. This handling may lead to either a successful result or an error being returned.
For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]).
The Interrogation process in the HLR is shown in figure 22.6.4/1.


Figure 22.6.3/1 (sheet 1 of 2): Process Interrogate_SS_VLR

Figure 22.6.3/1 (sheet 2 of 2): Process Interrogate_SS_VLR

Figure 22.6.4/1: Process Interrogate_SS_HLR
22.7	Void
Figure 22.7.2/1 void 
Figure 22.7.3/1 void
22.8	Password registration procedure
22.8.1	General
The password registration procedure is used to register a password in the HLR. The password registration procedure is a fully transparent communication between the MS and the HLR, except that some services may be invoked as a result of the procedure, as described below.
The password registration procedure is shown in figure 22.8.1/1.
The following services may be used:
MAP_PROCESS_ACCESS_REQUEST	(see clauses 8 and 25);
MAP_TRACE_SUBSCRIBER_ACTIVITY	(see clauses 9 and 25);
MAP_PROVIDE_IMSI		(see clauses 8 and 25);
MAP_FORWARD_NEW_TMSI		(see clauses 8 and 25);
MAP_AUTHENTICATE		(see clauses 8 and 25);
MAP_SET_CIPHERING_MODE		(see clauses 8 and 25);
MAP_CHECK_IMEI		(see clauses 8 and 25);
MAP_READY_FOR_SM		(see clauses 12 and 25);
The following services are certainly used:
MAP_REGISTER_PASSWORD		(defined in clause 11);
MAP_GET_PASSWORD		(defined in clause 11).


1)	A_CM_SERV_REQ (Note 1)
2)	MAP_PROCESS_ACCESS_REQUEST (Note 2)
3)	A_REGISTER_PASSWORD (Note 1)
4)	MAP_REGISTER_PASSWORD_req/ind
5)	MAP_REGISTER_PASSWORD_req/ind
6)	MAP_GET_PASSWORD_req/ind (Note 3)
7)	MAP_GET_PASSWORD_req/ind (Note 3)
8)	A_GET_PASSWORD (Note 1, Note 3)
9)	A_GET_PASSWORD ack (Note 1, Note 3)
10)	MAP_GET_PASSWORD_rsp/cnf (Note 3)
11)	MAP_GET_PASSWORD_rsp/cnf (Note 3)
12)	MAP_GET_PASSWORD_req/ind (Note 3)
13)	MAP_GET_PASSWORD_req/ind (Note 3)
14)	A_GET_PASSWORD (Note 1, Note 3)
15)	A_GET_PASSWORD ack (Note 1, Note 3)
16)	MAP_GET_PASSWORD_rsp/cnf (Note 3)
17)	MAP_GET_PASSWORD_rsp/cnf (Note 3)
18)	MAP_GET_PASSWORD_req/ind (Note 3)
19)	MAP_GET_PASSWORD_req/ind (Note 3)
20)	A_GET_PASSWORD (Note 1, Note 3)
21)	A_GET_PASSWORD ack (Note 1, Note 3)
22)	MAP_GET_PASSWORD_rsp/cnf (Note 3)
23)	MAP_GET_PASSWORD_rsp/cnf (Note 3)
24)	MAP_REGISTER_PASSWORD_rsp/cnf
25)	MAP_REGISTER_PASSWORD_rsp/cnf
26)	A_REGISTER_PASSWORD (Note 1)

NOTE 1:	For details of the procedure on the radio path, see 3GPP TS 24.008 [35], 3GPP TS 24.010 [36], 3GPP TS 24.08x and 3GPP TS 24.09x. Services shown in dotted lines are triggers/ triggered signalling on the radio path.
NOTE 2:	For details of the Process Access Request procedure, refer to clause 25.4 in the present document.
NOTE 3:	The use of each of the three MAP_GET_PASSWORD operations is described in clause 22.8.4.

Figure 22.8.1/1: Message flow for supplementary service password registration
22.8.2	Procedure in the MSC
The password registration procedure in the MSC is identical to that for activation specified in clause 22.4.2. All the text and diagrams in clause 22.4.2 apply with all references to activation changed to password registration.
22.8.3	Procedure in the VLR
The password registration procedure in the VLR is identical to that for activation specified in clause 22.4.3. All the text and diagrams in clause 22.4.3 apply with all references to activation changed to password registration.
22.8.4	Procedure in the HLR
The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Check_Indication			see clause 25.2.1.
The HLR shall process the MAP_REGISTER_PASSWORD indication as specified in 3GPP TS 23.011 [22]. During the handling of password registration, the password procedure is initiated (as specified in 3GPP TS 23.011 [22]) This involves the sending of MAP_GET_PASSWORD requests to the VLR.
The password registration process in the HLR is shown in figure 22.8.4/1.


Figure 22.8.4/1 (sheet 1 of 2): Process Register_PW_HLR

Figure 22.8.4/1 (sheet 2 of 2): Process Register_PW_HLR
22.9	Mobile Initiated USSD procedure
22.9.1	General
The procedure supports supplementary service signalling procedures which allow PLMN specific services to be introduced.
The message flow for the procedure can be found in 3GPP TS 23.090 [34].
The following services may be used:
MAP_PROCESS_ACCESS_REQUEST		(see clauses 8 and 25);
MAP_TRACE_SUBSCRIBER_ACTIVITY	(see clauses 9 and 25);
MAP_PROVIDE_IMSI			(see clauses 8 and 25);
MAP_FORWARD_NEW_TMSI		(see clauses 8 and 25);
MAP_AUTHENTICATE			(see clauses 8 and 25);
MAP_SET_CIPHERING_MODE		(see clauses 8 and 25);
MAP_CHECK_IMEI			(see clauses 8 and 25);
MAP_READY_FOR_SM			(see clauses 12 and 25);
MAP_UNSTRUCTURED_SS_REQUEST	(defined in clause 11);
MAP_UNSTRUCTURED_SS_NOTIFY		(defined in clause 11).
The following service is certainly used:
MAP_PROCESS_UNSTRUCTURED_SS_REQUEST	(defined in clause 11).
22.9.2	Procedure in the MSC
The process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Check_Confirmation		see clause 25.2.2.
The A_PROCESS_UNSTRUCTURED_SS_REQUEST from the MS contains information input by the user; the message may be fed to an application contained locally in the MSC or to the VLR. The rules for determining this are specified in 3GPP TS 23.090 [34].
1)	Message Destined for the VLR
If the message is destined for the VLR then the MSC shall transfer the message to the VLR using the mapping specified in detail in 3GPP TS 29.011 [59].
2)	Message Destined for the Local Application
If the message is destined for the local USSD application then the MSC shall transfer the information contained in the message to the application.
The process in the MSC is shown in figure 22.9.2/1.
22.9.3	Procedure in the VLR
The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2;
Process_Access_Request_VLR	see clause 25.4.2.
The MAP_PROCESS_UNSTRUCTURED_SS_REQUEST from the MSC contains information input by the user; the message may be fed to an application contained locally in the VLR or to the HLR. The rules for determining this are specified in 3GPP TS 23.090 [34].
1)	Message Destined for the HLR
If the message is destined for the HLR then the VLR shall transfer the message transparently to the HLR.
2)	Message Destined for the Local Application
If the message is destined for the local USSD application then the VLR shall transfer the information contained in the message to the application.
The process in the VLR is shown in figure 22.9.3/1.
22.9.4	Procedure in the HLR
The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind		see clause 25.1.1;
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2.
The MAP_PROCESS_UNSTRUCTURED_SS_REQUEST from the VLR contains information input by the user. If the alphabet used for the message is understood then the message shall be fed to an application contained locally in the HLR or to the gsmSCF or to a secondary HLR where the USSD application is located.
1)	Message Destined for the Local Application
If the message is destined for the local USSD application then the HLR shall transfer the information contained in the message to the local application.
2)	Message Destined for the gsmSCF or the secondary HLR
If the message is destined for the gsmSCF or the secondary HLR then the primary HLR shall transfer the message transparently to the next node.
The process in the primary HLR is shown in figure 22.9.4/1.
22.9.5	Procedures in the gsmSCF/secondary HLR
The MAP process invokes a macro not defined in this clause; the definition of this macros can be found as follows:
Receive_Open_Ind		see clause 25.1.1.
The process in the gsmSCF or secondary HLR is shown in figure 22.9.5/1.


Figure 22.9.2/1 (sheet 1 of 3): Process MS_Init_USSD_MSC

Figure 22.9.2/1 (sheet 2 of 3): Process MS_Init_USSD_MSC

Figure 22.9.2/1 (sheet 3 of 3): Process MS_Init_USSD_MSC

Figure 22.9.3/1 (sheet 1 of 4): Process MS_Init_USSD_VLR

Figure 22.9.3/1 (sheet 2 of 4): Process MS_Init_USSD_VLR

Figure 22.9.3/1 (sheet 3 of 4): Process_MS_Init_USSD_VLR

Figure 22.9.3/1 (sheet 4 of 4): Process_MS_Init_USSD_VLR
Figure 22.9.3/2 void

Figure 22.9.4/1 (sheet 1 of 4): Process MS_Init_USSD_HLR

Figure 22.9.4/1 (sheet 2 of 4): Process MS_Init_USSD_HLR

Figure 22.9.4/1 (sheet 3 of 4): Process MS_Init_USSD_HLR

Figure 22.9.4/1 (sheet 4 of 4): Process MS_Init_USSD_HLR

Figure 22.9.5/1 (sheet 1 of 2): Process MS_Init_USSD_gsmSCF_Secondary_HLR

Figure 22.9.5/1 (sheet 2 of 2): Process MS_Init_USSD_gsmSCF_Secondary_HLR
22.10	Network initiated USSD procedure
22.10.1	General
The procedure supports supplementary service signalling procedures which allow PLMN specific services to be introduced.
The message flow for the procedure can be found in 3GPP TS 23.090 [34].
The following services may be used:
MAP_PAGE			(see clauses 8 and 25);
MAP_SEARCH_FOR_MOBILE_SUBSCRIBER	(see clauses 8 and 25);
MAP_PROCESS_ACCESS_REQUEST	(see clauses 8 and 25);
MAP_AUTHENTICATE		(see clauses 8 and 25);
MAP_SET_CIPHERING_MODE		(see clauses 8 and 25);
MAP_FORWARD_NEW_TMSI		(see clauses 8 and 25);
MAP_READY_FOR_SM		(see clauses 12 and 25).
At least one of the following services will certainly be used, and both may be used:
MAP_UNSTRUCTURED_SS_REQUEST	(defined in clause 11);
MAP_UNSTRUCTURED_SS_NOTIFY	(defined in clause 11).
22.10.2	Procedure in the MSC
The process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind		see clause 25.1.1;
Receive_Open_Cnf		see clause 25.1.2;
Page_MSC		see clause 25.3.1;
Search_For_MS_MSC		see clause 25.3.2;
Process_Access_Request_MSC	see clause 25.4.1.
The process in the MSC is shown in figure 22.10.2/1.
22.10.3	Procedure in the VLR
The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind		see clause 25.1.1;
Receive_Open_Cnf		see clause 25.1.2;
Check_Indication		see clause 25.2.1;
Check_Confirmation		see clause 25.2.2.
The process in the VLR is shown in figure 22.10.3/1.
MSC Initiated USSD
If a USSD application in the MSC wishes to use the network initiated USSD procedure, and a connection to the MS does not exist then the MSC opens a dialogue with the VLR. This dialogue leads to the VLR performing page or search using the macro Start_USSD_VLR.
Macro Start_USSD_VLR
The macro invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Check_Confirmation		see clause 25.2.1;
Process_Access_Request_VLR	see clause 25.4.2.
The macro is shown in figure 22.10.3/2.
22.10.4	Procedure in the HLR
The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind		see clause 25.1.1;
Receive_Open_Cnf		see clause 25.1.2;
Check_Indication		see clause 25.2.1;
Check_Confirmation		see clause 25.2.2.
The process in the primary HLR is shown in figures 22.10.4/1 and 22.10.4/2.
22.10.5	Procedure in the gsmSCF or secondary HLR
The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2.
The procedure in the gsmSCF or secondary HLR is shown in figure 22.10.5/1.


Figure 22.10.2/1 (sheet 1 of 4): Process NW_Init_USSD_MSC

Figure 22.10.2/1 (sheet 2 of 4): Process NW_Init_USSD_MSC

Figure 22.10.2/1 (sheet 3 of 4): Process NW_Init_USSD_MSC

Figure 22.10.2/1 (sheet 4 of 4): Process NW_Init_USSD_MSC

Figure 22.10.3/1 (sheet 1 of 5): Process NW_Init_USSD_VLR

Figure 22.10.3/1 (sheet 2 of 5): Process NW_Init_USSD_VLR

Figure 22.10.3/1 (sheet 3 of 5): Process NW_Init_USSD_VLR

Figure 22.10.3/1 (sheet 4 of 5): Process NW_Init_USSD_VLR

Figure 22.10.3/1 (sheet 5 of 5): Process NW_Init_USSD_VLR

Figure 22.10.3/2 (sheet 1 of 2): Macro Start_USSD_VLR

Figure 22.10.3/2 (sheet 2 of 2): Macro Start_USSD_VLR

Figure 22.10.4/1 (sheet 1 of 5): Process NW_Init_USSD_HLR

Figure 22.10.4/1 (sheet 2 of 5): Process NW_Init_USSD_HLR

Figure 22.10.4/1 (sheet 3 of 5): Process NW_Init_USSD_HLR

Figure 22.10.4/1 (sheet 4 of 5): Process NW_Init_USSD_HLR

Figure 22.10.4/1 (sheet 5 of 5): Process NW_Init_USSD_HLR

Figure 22.10.4/2: Macro Start_USSD_HLR

Figure 22.10.5/1 (sheet 1 of 2): Process NW_Init_USSD_gsmSCF_secondary_HLR

Figure 22.10.5/1 (sheet 2 of 2): Process NW_Init_USSD_gsmSCF_Secondary_HLR
22.11	Common macros for clause 22
The following macros are used for the description of more than one of the supplementary service processes described in clause 22.
22.11.1	SS Password handling macros
Macro Get_Password_MSC
This macro is used by the MSC to relay a request for password from the VLR to the MS, and to relay a response from the MS back to the VLR. The macro is shown in figure 22.11.1/1.
Macro Get_Password_VLR
This macro is used by the VLR to relay a request for password from the HLR to the MSC, and to relay a response from the MSC back to the HLR. The macro invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Check_Indication			see clause 25.2.1.
The macro is shown in figure 22.11.1/2.
22.11.2	Void 


Figure 22.11.1/1: Macro Get_Password_MSC

Figure 22.11.1/2: Macro Get_Password_VLR
Figure 22.11.2/1 void
Figure 22.11.2/2 void
Figure 22.11.2/3 void
Figure 22.11.2/4 void
Figure 22.11.2/5 void
22.12	Supplementary Service Invocation Notification procedure
22.12.1	General
The Supplementary Service Invocation Notification procedure is used to notify a gsmSCF about the invocation of a GSM Supplementary Service.
The supplementary service invocation notification procedure is shown in figure 22.12.1/1.
The following service is certainly used:
MAP_SS_INVOCATION_NOTIFY		(defined in clause 11).

1)	MAP_SS_INVOCATION_NOTIFY_req/ind
2)	MAP_SS_INVOCATION_NOTIFY_rsp/cnf

Figure 22.12.1/1: Message flow for supplementary service invocation notification
22.12.2	Procedure in the MSC
The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf			see clause 25.1.2;
Check_Confirmation			see clause 25.2.2.
The supplementary service invocation notification process in the MSC is shown in figure 22.12.2/1.
22.12.3	Procedure in the gsmSCF
The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind			see clause 25.1.1.
The supplementary service invocation notification process in thegsmSCF is shown in figure 22.12.3/1.

Figure 22.12.2/1: Process Notify_SS_Invocation_MSC

Figure 22.12.3/1: Process Note_SS_Invocation_gsmSCF
22.13	Activation of a CCBS request
22.13.1	General
The message flow to activate a CCBS request is shown in figure 22.13.1/1.
The following service is certainly used:
MAP_REGISTER_CC_ENTRY		(defined in clause 11).


1)	MAP_REGISTER_CC_ENTRY_req/ind
2)	MAP_REGISTER_CC_ENTRY_rsp/cnf

Figure 22.13.1/1: Message flow to activate a CCBS request
22.13.2	Procedure in the VLR
The MAP process in the VLR to activate a CCBS request is shown in figure 22.13.2/1. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
22.13.3	Procedure in the HLR
The MAP process in the HLR to activate a CCBS request is shown in figure 22.13.2/1.


Figure 22.13.2/1: Process Register_CC_Entry_VLR

Figure 22.13.3/1: Process Register_CC_Entry_HLR
22.14	Deactivation of a CCBS request
22.14.1	General
The message flow to deactivate a CCBS request is shown in figure 22.14.1/1.
The following service is certainly used:
MAP_ERASE_CC_ENTRY		(defined in clause 11).


1)	MAP_ERASE_CC_ENTRY_req/ind
2)	MAP_ERASE_CC_ENTRY_rsp/cnf

Figure 22.14.1/1: Message flow to deactivate a CCBS request
22.14.2	Procedure in the VLR
The MAP process in the VLR to deactivate a CCBS request is shown in figure 22.14.2/1. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
22.14.3	Procedure in the HLR
The MAP process in the HLR to deactivate a CCBS request is shown in figure 22.14.2/1.


Figure 22.14.2/1: Process Erase_CC_Entry_VLR

Figure 22.14.3/1: Process Erase_CC_Entry_HLR
23	Short message service procedures
23.1	General
The short message service procedures are used to control both mobile originated and mobile terminated short message transfer.
Four procedures exist for short message services:
-	mobile originated short message service transfer;
-	mobile terminated short message service transfer;
-	short message alert procedure;
-	short message delivery status report procedure.
The following application context refers to a complex MAP user consisting of several processes:
-	shortMessageGatewayContext.
This application context needs a co-ordinating process in the HLR. Additionally a co-ordinating process needed for the mobile originated situation in the MSC, because the A_CM_SERV_REQ message does not distinguish between mobile originated short message transfer and the short message alert procedures.
NOTE:	the A_CM_SERV_REQ message is not used for SMS over GPRS. The modelling is based on the assumption that the SGSN will trigger the appropriate process, according to whether an RP_MO_DATA or an RP_SM_MEMORY_AVAILABLE is received over the LLC layer.
When the "SMS in MME" architecture option is supported, the clause 23 and its associated figures applies where HSS replaces HLR and where MME is handled as a MSC, except the procedures between  the serving MSC and the VLR which, here, are not applicable to the MME.
NOTE:	MSC and MME cannot be both registered as serving nodes for MT SMS at a given time (cf 3GPP TS 23.272 [2])
23.1.1	Mobile originated short message service Co-ordinator for the MSC
The process starts when the MSC receives an A_CM_SERV_REQ message (see 3GPP TS 24.008 [35]), with a CM service type indicating short message service, from the A-interface. The process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Process_Access_Request_MSC	see clause 25.4.1.
If the macro Process_Access_Request_MSC takes the "OK" exit (which means that the MSC has sent an A_CM_SERVICE_ACCEPT to the MS), , the MS initiates mobile originated short message transfer or sends an indication that it has memory available for more short messages. 
The SMS Co-ordinator process in the MSC is shown in figure 23.1/1.
23.1.2	Short message Gateway Co-ordinator for the HLR
The process starts when the HLR receives a MAP_OPEN indication using when the application context shortMessageGatewayContext. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind	see clause 25.1.1.
The SM Gateway Co-ordinator process in the HLR is shown in figure 23.1/2.
If the Receive_Open_Ind macro takes the Vr exit then HLR shall perform the MAP dialogue as specified for the appropriate application context version. Depending on the subscriber data, handling at the MAP user application level may be performed as specified in clauses 23.3.2 and 23.5.2 of the present document:


Figure 23.1/1 (sheet 1 of 2): Process Co_SMS_MSC

Figure 23.1/1 (sheet 2 of 2): Process Co_SMS_MSC

Figure 23.1/2: Process Co_SM_Gateway_HLR
23.2	The mobile originated short message transfer procedure
The mobile originated short message service procedure is used to forward a short message from a mobile subscriber to a Service Centre. The message flow for the mobile originated short message service procedure is shown in figure 23.2/1.


1)	Short Message (3GPP TS 24.011 [37]).
2)	MAP_SEND_INFO_FOR_MO_SMS (*).
3)	MAP_SEND_INFO_FOR_MO_SMS_ACK (*).
4)	TCAP BEGIN (**)
4a)	TCAP CONTINUE (**)
4b)	MAP_MO_FORWARD_SHORT_MESSAGE.
5)	Short message (3GPP TS 23.040).
6)	Short message Acknowledgement (3GPP TS 23.040).
7)	MAP_MO_FORWARD_SHORT_MESSAGE_ACK.
8)	Short Message Acknowledgement (3GPP TS 24.011 [37]).
(*)	Messages 2) and 3) are not used by the SGSN.
(**)	If
a)
	the capacity of a message signal unit in the lower layers of the protocol is enough to carry the	content of the MAP_OPEN request and the content of the	MAP_MO_FORWARD_SHORT_MESSAGE request in a single TC message

and
	b)	the Interworking MSC operator and the serving node (MSC or SGSN) operator agreed	not to use the TCAP handshake countermeasure against SMS fraud for messages	exchanged between their networks (see 3GPP TS 33.204 [34a])

	then
 the TCAP handshake may be omitted.

Figure 23.2/1: Mobile originated short message transfer
In addition the following MAP services are used:
MAP_PROCESS_ACCESS_REQUEST	(see clause 8.3); (*)
MAP_AUTHENTICATE	(see clause 8.5); (*)
MAP_SET_CIPHERING_MODE	(see clause 8.6); (*)
MAP_PROVIDE_IMSI	(see clause 8.9); (*)
MAP_CHECK_IMEI	(see clause 8.7); 
MAP_FORWARD_NEW_TMSI	(see clause 8.9); (*)
MAP_TRACE_SUBSCRIBER_ACTIVITY	(see clause 9.1); (*)
MAP_READY_FOR_SM	(see clause 12.4).
(*)	These services are not used by the SGSN.
23.2.1	Procedure in the serving MSC
Any CAMEL-specific handling defined in this clause is omitted if the MSC does not support CAMEL control of MO SMS, or if the subscriber does not have a subscription for CAMEL control of MO SMS.
The process starts when the MSC receives a short message from the MS. The process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Indication	see clause 25.2.1;
Check_Confirmation	see clause 25.2.2.
Sheet 1: If the MSC is integrated with the SMS-IWMSC, it communicates directly with the Short Message Service Centre (SMSC) using one of the protocols described in 3GPP TS 23.039 [25a]; otherwise it communicates with the SMS-IWMSC using MAP.
Sheet 3: If the capacity of a message signal unit in the lower layers of the protocol is enough to carry the content of the MAP_OPEN request and the content of the MAP_MO_FORWARD_SHORT_MESSAGE request in a single TC message, the test "Message segmentation needed" takes the "No" exit; otherwise the test takes the "Yes" exit.
Sheet 3:The decision box "TCAP Handshake required" takes the "yes" or "no" exit depending on agreements between the serving MSC's operator and the SMS-IWMSC's operator (see 3GPP TS 33.204 [34a]).
The mobile originated short message service process in the MSC is shown in figure 23.2/2.
23.2.2	Procedure in the VLR
Any CAMEL-specific handling defined in this clause is omitted if the VLR does not support CAMEL control of MO SMS.
The process starts when the VLR receives a dialogue opening request followed by a MAP_PROCESS_ACCESS_REQUEST including a CM service type Short Message Service. The process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind		see clause 25.1.1;
Check_Indication		see clause 25.2.1;
Process_Access_Request_VLR	see clause 25.4.2.
The mobile originated short message transfer process in the VLR is shown in figure 23.2/3.
23.2.3	Procedure in the SGSN
Any CAMEL-specific handling defined in this clause is omitted if the SGSN does not support CAMEL control of MO SMS, or if the subscriber does not have a subscription for CAMEL control of MO SMS.
The process starts when the SGSN receives a short message received from the MS over the Gb interface. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
Sheet 2: If the capacity of a message signal unit in the lower layers of the protocol is enough to carry the content of the MAP_OPEN request and the content of the MAP_MO_FORWARD_SHORT_MESSAGE request in a single TC message, the test "Message segmentation needed" takes the "No" exit; otherwise the test takes the "Yes" exit. 
Sheet 2:The decision box "TCAP Handshake required" takes the "yes" or "no" exit depending on agreements between the serving SGSN's operator and the SMS-IWMSC's operator (see 3GPP TS 33.204 [34a]).
The mobile originated short message service process in the SGSN is shown in figure 23.2/4.
23.2.4	Procedure in the SMS Interworking MSC (SMS-IWMSC)
This procedure applies only when the SMS-IWMSC is not integrated with the serving MSC or SGSN.
The process starts when the SMS-IWMSC receives a dialogue opening request with the application context shortMsgMO-RelayContext. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind	see clause 25.1.1;
Check_Indication	see clause 25.2.1.
Sheet 1:The decision box "TCAP Handshake required" takes the "yes" or "no" exit depending on agreements between the SMS-IWMSC's operator and the serving node's operator (see 3GPP TS 33.204 [34a]).
The mobile originated short message service transfer process in the SMS-IWMSC is shown in figure 23.2/5.


Figure 23.2/2 (sheet 1 of 4): Process MO_SM_MSC

Figure 23.2/2 (sheet 2 of 4): Process MO_SM_MSC 

Figure 23.2/2 (sheet 3 of 4): Process MO_SM_MSC

Figure 23.2/2 (sheet 4 of 4): Process MO_SM_MSC

Figure 23.2/3 (sheet 1 of 2): Process MOSM_VLR

Figure 23.2/3 (sheet 2 of 2): Process MO_SM_VLR

Figure 23.2/4 (sheet 1 of 3): Process MO_SM_SGSN

Figure 23.2/4 (sheet 2 of 3): Process MO_SM_SGSN

Figure 23.2/4 (sheet 3 of 3): Process MO_SM_SGSN

Figure 23.2/5 (sheet 1 of 2): Process MO_SM_IWMSC


Figure 23.2/5 (sheet 2 of 2): Process MO_SM_IWMSC
23.3	The mobile terminated short message transfer procedure
The mobile terminated short message transfer procedure is used for forwarding a short message or several short messages from a Service Centre to a mobile subscriber. The message flow for the mobile terminated short message procedure for a single short message transfer is shown in figure 23.3/1.

Figure 23.3/1: Mobile terminated short message service procedures
1)	Short Message (3GPP TS 23.040).
2)	MAP_SEND_ROUTING_INFO_FOR_SM.
3)	MAP_SEND_ROUTING_INFO_FOR_SM_ACK.
4)	TCAP BEGIN (***)
4a)	TCAP CONTINUE (***)
4b)	MAP_MT_FORWARD_SHORT_MESSAGE.
The message should include the timer value used at the SMS-GMSC for the supervision of  the MAP_MT_FORWARD_SHORT_MESSAGE_ACK.
5)	MAP_SEND_INFO_FOR_MT_SMS (*).
5a)	MAP_CONTINUE_CAMEL_SMS_HANDLING (*)(**)
5b)	MAP_SEND_INFO_FOR_MT_SMS (*)(**)
6)	MAP_PAGE/MAP_SEARCH_FOR_MOBILE_SUBSCRIBER (*).
7)	Page (3GPP TS 24.008 [35]).
8)	Page response (3GPP TS 24.008 [35]).
9)	MAP_PROCESS_ACCESS_REQUEST_ACK and
MAP_SEARCH_FOR_MOBILE_SUBSCRIBER_ACK (*).
10)	MAP_SEND_INFO_FOR_MT_SMS_ACK (*).
11)	Short Message (3GPP TS 24.011 [37]).
12)	Short Message Acknowledgement (3GPP TS 24.011 [37]).
13)	MAP_MT_FORWARD_SHORT_MESSAGE_ACK.
14)	Short Message Acknowledgement (3GPP TS 23.040).

(*)	Messages 5), 5a), 5b), 6), 9), and 10) are not used by the SGSN.
(**)	These messages are used only for a subscriber provisioned with MT-SMS-CSI in the VLR.
(***)	If 
	a)
-	the capacity of a message signal unit in the lower layers of the protocol is enough to carry the	content of the MAP_OPEN request and the content of the	MAP_MT_FORWARD_SHORT_MESSAGE request in a single TC message, 

	and
	b)	the SMS Gateway MSC operator and the serving node (MSC or SGSN) operator
	agreed not to use the TCAP handshake countermeasure against SMS fraud for
	messages exchanged between their networks (see 3GPP TS 33.204 [34a])
	then
	the TCAP handshake may be omitted.

The message flow for the mobile terminated short message procedure for multiple short message transfer is shown in figure 23.3/2.

Figure 23.3/2: Mobile terminated short message procedure for multiple short message transfer
1)	Short Message (3GPP TS 23.040 [26]).
2)	MAP_SEND_ROUTING_INFO_FOR_SM.
3)	MAP_SEND_ROUTING_INFO_FOR_SM_ACK.
4)	TCAP BEGIN (***)
4a	TCAP CONTINUE (***)
4b)	MAP_MT_FORWARD_SHORT_MESSAGE (note 1). 
The message should include the timer value used at the SMS-GMSC for the supervision of  the MAP_MT_FORWARD_SHORT_MESSAGE_ACK.
5)	MAP_SEND_INFO_FOR_MT_SMS (*).
5a)	MAP_CONTINUE_CAMEL_SMS_HANDLING (*)(**)
5b)	MAP_SEND_INFO_FOR_MT_SMS (*)(**)
6)	MAP_PAGE/MAP_SEARCH_FOR_MOBILE_SUBSCRIBER (*).
7)	Page (3GPP TS 48.008 [49]).
8)	Page response (3GPP TS 24.008 [35]).
9)	MAP_PROCESS_ACCESS_REQUEST_ACK and	
MAP_SEARCH_FOR_MOBILE_SUBSCRIBER_ACK (*).
10)	MAP_SEND_INFO_FOR_MT_SMS_ACK (*).
11)	Short Message (3GPP TS 24.011 [37]).
12)	Short Message Acknowledgement (3GPP TS 24.011 [37]).
13)	MAP_MT_FORWARD_SHORT_MESSAGE_ACK.
14)	Short Message Acknowledgement (3GPP TS 23.040 [26]).
15)	Short Message (3GPP TS 23.040 [26]).
16)	MAP_MT_FORWARD_SHORT_MESSAGE (note 2). 
The message should include the timer value used at the SMS-GMSC for the supervision of  the MAP_MT_FORWARD_SHORT_MESSAGE_ACK.
17)	Short Message (3GPP TS 24.011 [37]).
18)	Short Message Acknowledgement (3GPP TS 24.011 [37]).
19)	MAP_MT_FORWARD_SHORT_MESSAGE_ACK.
20)	Short Message Acknowledgement (3GPP TS 23.040 [26]).

(*)	Messages 5), 5a), 5b) 6), 9), and 10) are not used by the SGSN.
(**)	These messages are used only for a subscriber provisioned with MT-SMS-CSI in the VLR.
(***)	If 
	a)	the capacity of a message signal unit in the lower layers of the protocol is enough to carry the	content of the MAP_OPEN request and the content of the	MAP_MT_FORWARD_SHORT_MESSAGE request in a single TC message, 
	and
	b)	the SMS Gateway MSC operator and the serving node (MSC or SGSN) operator
	agreed not to use the TCAP handshake countermeasure against SMS fraud for
	messages exchanged between their networks (see 3GPP TS 33.204 [34a])
	then the TCAP handshake may be omitted.

NOTE 1:	The "More Messages To Send" flag is TRUE.
NOTE 2:	The "More Messages To Send" flag is FALSE.

In the multiple short message transfer the service MAP_MT_FORWARD_SHORT_MESSAGE can be used several times. However, the short message transfer is always acknowledged to the Service Centre before the next short message is sent.
In addition the following MAP services are used:
MAP_PROCESS_ACCESS_REQUEST	(see clause 8.3); (*)
MAP_PAGE	(see clause 8.2); (*)
MAP_SEARCH_FOR_MS	(see clause 8.2); (*)
MAP_AUTHENTICATE	(see clause 8.5); (*)
MAP_SET_CIPHERING_MODE	(see clause 8.6); (*)
MAP_CHECK_IMEI	(see clause 8.7);
MAP_FORWARD_NEW_TMSI	(see clause 8.9); (*)
MAP_REPORT_SM_DELIVERY_STATUS	(see clause 12.3);
MAP_INFORM_SERVICE_CENTRE	(see clause 12.6);
MAP_TRACE_SUBSCRIBER_ACTIVITY	(see clause 9.1); (*)
MAP_READY_FOR_SM	(see clause 12.4).
(*)	These services are not used by the SGSN.
A message flow example for the mobile terminated short message procedure for a single short message transfer in an environment that makes use of an SMS Router for MT-short-message-transfer is shown in figure 23.3/2a.
NOTE: This message flow can be applied only if no IP-SM-GW deployed in the same network.

Figure 23.3/2a Mobile terminated short message procedure with SMS Router
1)	Short Message (3GPP TS 23.040 [26])
2) & 3)	MAP_SEND_ROUTING_INFO_FOR_SM
NOTE:	The HLR relays the message MAP_SEND_ROUTING_INFO_FOR_SM received from the SMS-GMSC to the SMS Router on SCCP level. How this is done is implementation specific.
4)	MAP_SEND_ROUTING_INFO_FOR_SM
5)	MAP_SEND_ROUTING_INFO_FOR_SM_ACK and conditionally MAP_INFORM_SERVICE_CENTRE
6)	MAP_SEND_ROUTING_INFO_FOR_SM_ACK and conditionally MAP_INFORM_SERVICE_CENTRE
7)	Conditionally: Inform Service Centre (3GPP TS 23.040 [26])
8)	MAP_MT_FORWARD_SHORT_MESSAGE 
The message should include the timer value used at the SMS-GMSC for the supervision of  the MAP_MT_FORWARD_SHORT_MESSAGE_ACK.
NOTE:	In this example the SMS-GMSC decides to attempt delivery via MSC. Therefore the SCCP called party SSN shall be set to SSN for MSC.
9)	MAP_MT_FORWARD_SHORT_MESSAGE 
The message should include the timer value used at the SMS-GMSC for the supervision of  the MAP_MT_FORWARD_SHORT_MESSAGE_ACK.
10)	MAP_MT_FORWARD_SHORT_MESSAGE_ERROR
NOTE:	In this example delivery via the MSC is unsuccessful e.g. due to IMSI detached
11)	MAP_MT_FORWARD_SHORT_MESSAGE_ERROR
12)	MAP_MT_FORWARD_SHORT_MESSAGE
NOTE:	In this example the SMS-GMSC decides to retry delivery via the SGSN. Therefore the SCCP called party SSN shall be set to the SSN for SGSN.
13)	MAP_MT_FORWARD_SHORT_MESSAGE 
The message should include the timer value used at the SMS-GMSC for the supervision of  the MAP_MT_FORWARD_SHORT_MESSAGE_ACK.
14)	MAP_MT_FORWARD_SHORT_MESSAGE_ACK
NOTE:	In this example delivery via SGSN is successful
15)	MAP_MT_FORWARD_SHORT_MESSAGE_ACK
16)	Conditionally: MAP_REPORT_SM_DELIVERY_STATUS
NOTE:	In this example unsuccessful delivery via MSC and successful delivery via SGSN is reported
17)	MAP_REPORT_SM_DELIVERY_STATUS_Ack
18)	Short Message Acknowledgement (3GPP TS 23.040 [26]).

A message flow example for the mobile terminated short message procedure for a single short message transfer in an environment that makes use of an IP-SM-GW (see 3GPP TS 23.204 [134]) for MT-short-message-transfer is shown in figure 23.3/2b.
NOTE:	SMS Routers can apply this message flow as well.


Figure 23.3/2b Mobile terminated short message procedure with IP-SM-GW
1)	Short Message (3GPP TS 23.040 [26])
2)	MAP_SEND_ROUTING_INFO_FOR_SM
	the message is forwarded to the IP-SM-GW assigned to the recipient of the SM
	the message may contain IP-SM-GW Guidance support indication
3)	MAP_SEND_ROUTING_INFO_FOR_SM
4)	MAP_SEND_ROUTING_INFO_FOR_SM
	since the message is received from an IP-SM-GW, it is not forwarded to an IP-SM-GW
5)	MAP_SEND_ROUTING_INFO_FOR_SM_ACK and conditionally MAP_INFORM_SERVICE_CENTRE
6)	MAP_SEND_ROUTING_INFO_FOR_SM_ACK and conditionally MAP_INFORM_SERVICE_CENTRE
	The IP-SM-GW returns its own address within the network node number parameter
	The message may include IP-SM-GW Guidance
7)	Conditionally: Inform Service Centre (3GPP TS 23.040 [26])
8)	MAP_MT_FORWARD_SHORT_MESSAGE
	If the IP-SM-GW-Guidance support indicator was present in message 2 and IP-SM-GW-Guidance was present in message 6, message 8 shall contain the used timer value for supervision of MAP_MT_FORWARD_SHORT_MESSAGE_ACK; the used timer should be identical to the recommended value received in message 6 to ensure that the IP-SM-GW can attempt delivery to multiple domains if necessary  and shall not be lower than the minimum value received in message 6 to ensure that an IP-SM-GW can attempt delivery to at least one domain. 
Otherwise, The message should include the timer value used at the SMS-GMSC for the supervision of  the MAP_MT_FORWARD_SHORT_MESSAGE_ACK.
9)	MAP_MT_FORWARD_SHORT_MESSAGE_ACK
10)	Conditionally: MAP_REPORT_SM_DELIVERY_STATUS
NOTE:	As an IP-SM-GW is deployed the message is acknowledged ignoring its content
11)	MAP_REPORT_SM_DELIVERY_STATUS_Ack
12)	Conditionally: MAP_REPORT_SM_DELIVERY_STATUS 
	since the message is received from an IP-SM-GW, it is processed
13)	MAP_REPORT_SM_DELIVERY_STATUS_Ack
NOTE:	Step 12 and 13 is independent of steps 10, 11, and 14. They can run in parallel.
14)	Short Message Acknowledgement (3GPP TS 23.040 [26]).

23.3.1	Procedure in the SMS-GMSC
Any CAMEL-specific handling described in this clause is omitted if the SMS-GMSC does not support CAMEL. CAMEL-specific handling is invoked only if the SMS-GMSC is integrated with the VMSC.
The process starts when the SMS-GMSC receives an SC_RP_MT_DATA indication from a Service Centre. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2.
Process MT_SM_GMSC sheet 1: If the MAP_SEND_ROUTING_INFO_FOR_SM confirmation included an LMSI, it shall be included in the sm-RP-DA information field of the first MAP_MT_FORWARD_SHORT_MESSAGE request sent to the serving MSC. In this case, the IMSI shall be included in the Destination Reference of the MAP_OPEN request. The SMS-GMSC shall not send an LMSI to an SGSN. If the SMS-GMSC does not send an LMSI to the serving node, the sm-RP-DA information field in the first MAP_MT_FORWARD_SHORT_MESSAGE request sent to the serving MSC or SGSN shall contain the IMSI, and the Destination Reference in the MAP_OPEN request shall not be present. The parameter SM_RP_OA shall contain the Service Centre address.
Process MT_SM_GMSC sheet 1: The indication of which number belongs to the SGSN and which to the MSC, received from the HLR in the MAP_SEND_ROUTING_INFO_FOR_SM confirm (see clause 23.3.2) will enable the SMS-GMSC to map the causes received from one or both serving nodes into the appropriate causes for non GPRS, GPRS or both, and send them to the SC and the HLR.
Process MT_SM_GMSC sheet 2: The SMS-GMSC maps "Unexpected data value" and "System failure" MAP errors from the serving node to a "System failure" RP_ERROR error cause. The mapping between other MAP error causes and the RP_ERROR error cause is given in 3GPP TS 23.040 [26] and 3GPP TS 24.011 [37].
Process MT_SM_GMSC sheet 2: If the SMS-GMSC receives both MSC and SGSN numbers from the HLR as routeing information, it may choose which serving node to use for the first delivery attempt.
Process MT_SM_GMSC sheet 2: If the SMS-GMSC makes two delivery attempts, it may report the result of each delivery attempt to the HLR according to the conditions described below.
Procedure MT_SM_Delivery_Attempt_GMSC sheet 1: if the macro MT_SM_Transfer_MSC takes the Error exit, the SMS-GMSC maps the MAP User Error to the corresponding SC_RP error, as defined in 3GPP TS 23.040 [26].
Procedure MT_SM_Delivery_Attempt_GMSC sheet 3: The decision box "TCAP Handshake required" takes the "yes" or "no" exit depending on agreements between the GMSC's operator and the serving node's operator (see 3GPP TS 33.204 [34a]).
Procedure MT_SM_Delivery_Attempt_GMSC sheet 1, sheet 2, sheet 4, sheet 5: The SMS-GMSC invokes the macro Report_SM_Delivery_Stat_GMSC if:
-	the reason received from the serving node for failure to deliver the message is absent subscriber_SM, unidentified subscriber or SM delivery failure with error cause "MS memory capacity exceeded", and the SC address is not yet included in the MWD set, or
-	the reason received from the serving node for failure to deliver the message is absent subscriber_SM, unidentified subscriber or SM delivery failure with error cause MS memory capacity exceeded, and the corresponding flag in the HLR (as indicated in the information received in the MAP_INFORM_ SERVICE_CENTRE) is not set, or
-	the reason received from the serving node (MSC or SGSN) for failure to deliver the message is absent subscriber_SM and the absent subscriber diagnostic is different from the absent subscriber diagnostic received in the MAP_INFORM_ SERVICE_CENTRE.
Procedure MT_SM_Delivery_Attempt_GMSC sheet 1, sheet 2, sheet 4, sheet 5: If absent subscriber diagnostic information (see 3GPP TS 23.040 [26]) is included with the absent subscriber_SM error indication then the SMS-GMSC relays this information to the HLR using the MAP_REPORT_SM_DELIVERY_STATUS service.
Procedure MT_SM_Delivery_Attempt_GMSC sheet 1, sheet 4: The More Messages To Send flag is set to TRUE or FALSE according to the information received from the Service Centre.
Procedure MT_SM_Delivery_Attempt_GMSC sheet 3: If the capacity of a message signal unit in the lower layers of the protocol is enough to carry the content of the MAP_OPEN request and the content of the MAP_MT_FORWARD_SHORT_MESSAGE request in a single TC message, the test "Message segmentation needed" takes the "No" exit; otherwise the test takes the "Yes" exit.
The mobile terminated short message transfer process in the SMS-GMSC is shown in figure 23.3/3. The procedure MT_SM_Delivery_Attempt_GMSC is shown in figure 23.3/4. The macro MT_SM_Transfer_MSC is shown in figure 23.3/7.
The SMS-GMSC may include the Maximum Retransmission Time IE in the MT Forward Short Message Request to indicate that it is capable to retransmit the Short Message until the indicated maximum retransmission time, if the following conditions are fulfilled:
-	the destination user pertains to the PLMN of the SMS-GMSC; and
-	if an SMS Router is used for MT SMS sent to destination users pertaining to the PLMN of the SMS-GMSC, the SMS Router is known to support the Alert Service Centre procedure specified in clause 12.5. 
The SMS-GMSC shall include its E.164 number in the SMS-GMSC address and, if available its Diameter Identity in the SMS-GMSC Diameter Address in the request if it also includes the Maximum-Retransmission-Time IE.  
If subsequently, the SMS-GMSC receives an Alert Service Centre request from an MME (via an IWF), SGSN or MSC, the SMS-GMSC shall retransmit pending MT SMS(s) for the destination user identified by the User Identifier Alert, to the same serving node if the SMS-GMSC Alert Event indicates that the MS is available for MT SMS, or to the new serving node if the SMS-GMSC Alert Event indicates that the MS has moved under the coverage of another MME, SGSN or MSC. In the latter case, if neither New MSC Number, nor New SGSN Number, nor New SGSN Diameter Address, nor New MME Number, nor New MME Diameter Address are received in the Alert Service Centre request, the SMS-GMSC shall initiate a Send Routing Info for SM procedure to retrieve the new serving node 's address from the HLR.
23.3.2	Procedure in the HLR
The process starts when the HLR receives a MAP_SEND_ROUTING_INFO_FOR_SM indication from the SMS-GMSC. If an SMS Router is deployed, the HLR receives MAP_SEND_ROUTING_INFO_FOR_SM from the SMS Router (step 4 in figure 23.3/2a); relaying a message received from the SMS-GMSC to the SMS Router on SCCP level (steps 2 and 3 in figure 23.3/2a) is done by implementation specific means and is not shown in figure 23.3/5.
The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Check_Indication		see clause 25.2.1.
Sheet 1: The decision box "Relay to IP-SM-GW" takes the "yes" exit if an IP-SM-GW is deployed and the message was not received from an IP-SM-GW.
Sheet 3: If the SMS-GMSC does not support GPRS functionality, it uses the protocol defined in the Release 96 version of this specification. The parameter "msc-Number" in "RoutingInfoForSM-Res" in the Release 96 version of the protocol definition corresponds to the parameter "networkNode-Number" in "RoutingInfoForSM-Res" in the Release 97 (and later) version of the protocol definition; therefore if the HLR populates the parameter "networkNode-Number" with the SGSN number, the Release 96 SMS-GMSC will interpret the SGSN number as an MSC number. If the HLR populates the "gprsNodeIndicator" parameter in the MAP_SEND_ROUTING_INFO_FOR_SM response, a Release 96 SMS-GMSC will silently discard the parameter.
Sheet 5: If the HLR received a LMSI from the VLR at location updating, it shall include the LMSI in the MAP_SEND_ROUTING_INFO_FOR_SM response only if the MAP_SEND_ROUTING_INFO_FOR_SM response also includes the MSC number.
The mobile terminated short message transfer process in the HLR is shown in figure 23.3/5.
23.3.3	Procedure in the Serving MSC
Any CAMEL-specific handling defined in this clause is omitted if the MSC does not support CAMEL control of MT SMS, or if the subscriber does not have a subscription for CAMEL control of MT SMS.
The process starts when the MSC receives a dialogue opening request with the application context shortMsgMT-RelayContext. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind		see clause 25.1.1;
Check_Indication		see clause 25.2.1.
The mobile terminated short message transfer process in the serving MSC is shown in figure 23.3/6 
Procedure MT_SM_VMSC sheet 1: The decision box "TCAP Handshake required" takes the "yes" or "no" exit depending on agreements between the Serving MSC's operator and the SMS Gateway MSC's operator (see 3GPP TS 33.204 [34a]).
The macro MT_SM_Transfer_MSC may be invoked either in a stand-alone serving MSC or in a serving MSC which is integrated with the SMS-GMSC. It is used to transfer the first MT short message of a possible sequence of messages. The macro invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Check_Confirmation		see clause 25.2.2.
Page_MSC		see clause 25.3.1;
Search_for_MS_MSC	see clause 25.3.2;
Process_Access_Request_MSC	see clause 25.4.1;
Trace_Subscriber_Activity_MSC	see clause 25.9.1.
The macro MT_SM_Transfer_MSC is shown in figure 23.3/7. The macro Check_Subscr_Identity_For_MT_SMS is shown in figure 23.3/8. 
3GPP TS 29.118 [152] specifies the extensions applicable to the MT SMS procedure over SGs for a UE using extended idle mode DRX (as defined in 3GPP TS 23.682 [148]).
If the MS is using a power saving mechanism such as extended idle mode DRX (see 3GPP TS 23.682 [148]), and if the MT Forward Short Message Request includes the Maximum Retransmission Time IE, an MSC using Deployment Option 2 (see clause 8.2.4a.1 of 3GPP TS 23.272 [143] and 3GPP TS 23.040 [6]) may return an MT Forward Short Message Response with the User Error set to Absent Subscriber_SM and with the Requested-Retransmission-Time IE requesting the SMS-GMSC to retransmit the Short Message at a later time prior to the Maximum Retransmission Time. In that case, the MSC shall store (if not already done) the SMS-GMSC address and, if available, the SMS-GMSC Diameter Identity received in the request and shall not set the MNRF flag.  
NOTE:	This mechanism does not cause additional signalling at the HSS to retransmit the Short Message.
An MSC using Deployment Option 2 (see clause 8.2.4a.1 of 3GPP TS 23.272 [143] and 3GPP TS 23.040 [6]) shall initiate the MAP Service Center Alert procedure to alert the SMS-GMSC when the UE, for which one or more MT SMS have been requested to be retransmitted at a later time, becomes available for MT SMS delivery or moves under the coverage of another MSC prior to the requested SM retransmission time. The MSC shall then delete the stored SMS-GMSC address after the Alert Service Centre procedure is completed.

23.3.4	Procedure in the VLR
Any CAMEL-specific handling defined in this clause is omitted if the VLR does not support CAMEL control of MT SMS.
The process starts when the VLR receives a dialogue opening request from the MSC. The process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind		see clause 25.1.1;
Check_Indication		see clause 25.2.1;
Check_Confirmation		see clause 25.2.2;
Process_Access_Request_VLR	see clause 25.4.2.
The mobile terminated short message transfer process in the VLR is shown in figure 23.3/9.
If the VLR has no IMSI record, or if the record is marked "Subscriber Data Not Confirmed by HLR", the VLR may perform the data restoration procedure as specified in clause 4.2.2 in 3GPP TS 23.007 [19].
23.3.5	Procedure in the SGSN
Any CAMEL-specific handling defined in this clause is omitted if the SGSN does not support CAMEL control of MT SMS, or if the subscriber does not have a subscription for CAMEL control of MT SMS.
The process starts when the SGSN receives a dialogue opening request with the application context shortMsgMT-RelayContext. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind		see clause 25.1.1;
Check_Indication		see clause 25.2.1.
The mobile terminated short message transfer process in the SGSN is shown in figure 23.3/10. 
Procedure MT_SM_SGSN sheet 1: The decision box "TCAP Handshake required" takes the "yes" or "no" exit depending on agreements between the Serving SGSN's operator and the SMS Gateway MSC's operator (see 3GPP TS 33.204 [34a]).
The macro MT_SM_Transfer_SGSN is used to transfer the first MT short message of a possible sequence of messages. It is shown in figure 23.3/11.
If the MS is using extended idle mode DRX (as defined in 3GPP TS 23.682 [148]) and the MS is expected to respond to paging shortly or within the time frame indicated by the SM-Delivery-Timer and SM-Delivery-Start-Time IEs, the SGSN should page the MS and attempt to deliver the short message to the MS.
If the MS is using extended idle mode DRX (as defined in 3GPP TS 23.682 [148]) and the MS is expected to not respond to paging shortly or within the time frame indicated by the SM-Delivery-Timer and SM-Delivery-Start-Time IEs, the SGSN may behave as specified in figure 23.3/11 for an MS that is not reachachable, i.e. set the MNRG flag and return an Absent Subscriber Error to the SMS-GMSC, while still paging the MS.
NOTE 1:	This mechanism is not intended for MSs which are known to wake up shortly (e.g. within the next 10 seconds) as enough time needs to elapse, between the sending of the MT Forward Short Message Response and the subsequent Ready For SM procedure towards the HLR when the MS becomes reachable, for the Report SM Delivery Status procedure to take place beforehand from the SMS-GMSC to the HLR.
If the MS is using a power saving mechanism such as extended idle mode DRX (see 3GPP TS 23.682 [148]), and if the MT Forward Short Message Request includes the Maximum Retransmission Time IE, the SGSN may return an MT Forward Short Message Response with the User Error set to Absent Subscriber_SM and with the Requested-Retransmission-Time IE requesting the SMS-GMSC to retransmit the Short Message at a later time prior to the Maximum Retransmission Time. In that case, the SGSN shall store (if not already done) the SMS-GMSC address and, if available, the SMS-GMSC Diameter Identity received in the request and shall not set the MNRG flag.  
NOTE 2:	This mechanism does not cause additional signalling at the HSS to retransmit the Short Message.
The SGSN shall initiate the MAP Service Center Alert procedure to alert the SMS-GMSC when the UE, for which one or more MT SMS have been requested to be retransmitted at a later time, becomes available for MT SMS delivery or moves under the coverage of another MME or SGSN prior to the requested SM retransmission time. The SGSN shall then delete the stored SMS-GMSC address after the Alert Service Centre procedure is completed.
The macro Check_Subscr_Identity_For_MT_SMS is shown in figure 23.3/8. The page and search procedures are shown in figures 23.3/12 and 23.3/13.
23.3.6	Procedure in the SMS Router
If SMS Router is deployed together with IP-SM-GW, then mobile terminated short message transfer process for IP-SM-GW applies as described in clause 23.3.7.
The mobile terminated short message transfer process in the SMS Router is shown in figure 23.3/14.
Procedure MT_SM_SMS_ROUTER sheet 2: Allocated MT Correlation IDs have a limited lifetime, managed by Timer T1. The value of Timer T1 shall be operator configurable (its value being dependant on such factors as subscriber base, network size, number of roaming/SMS‑interworking partners, average and peak SMS traffic load, etc.). 
The value of the timer T1 shall cover at least the time indicated by the SM Delivery Start Time and SM Delivery Timer and, if the SMS Router support the Alert Service Centre procedure specified in clause 12.5, the Maximum Retransmission Time signalled in the MAP-MT-FORWARD-SHORT-MESSAGE.
Procedure MT_SM_SMS_ROUTER sheet 2: MAP parameters to be stored against the MT Correlation ID are IMSI, networkNode-Number, gprsNodeIndicator, and additional-Number (if and as received within MAP_SEND_ROUTING_INFO_FOR_SHORT_MESSAGE_cnf), and optionally MSISDN as received within MAP_SEND_ROUTING_INFO_FOR_SHORT_MESSAGE_ind from the SMS-GMSC (and relayed by the HLR)). The SMS Router may also store the GT, or just the CC and NDC parts of the GT, of the SMS-GMSC from which the MAP_SEND_ROUTING_INFO_FOR_SHORT_MESSAGE_ind was received.
Procedure MT_SM_SMS_ROUTER sheet 3: The SCCP called party SSN received with Open_ind is used to decide whether the new dialogue is opend with the MSC or with the SGSN.
The detail of replacing RP-OA is described in TS23.040 [26].
Procedure MT_SM_SMS_ROUTER sheet 4: The decision box "Retry expected" takes the "Yes" exit if two addresses were received from the HLR, the first delivery attempt was unsuccessful, and the second attempt has not yet been made.
Procedure MT_SM_SMS_ROUTER sheet 4: The task "Release MT Correlation ID" includes deleting of data stored against the MT Correlation ID.
If the MT Forward Short Message Request includes the Maximum-Retransmission-Time IE, the SMS Router shall store the SMS-GMSC address and, if available, the SMS-GMSC Diameter Identity received in the request and replace it by its SMS Router address (E.164 number) and, if available, its SMS Router Diameter Identity when forwarding the request to the MME (via an IFW), SGSN or MSC.
If the MT Forward Short Message Response includes the Requested-Retransmission-Time IE, the SMS Router shall include the User Identifier Alert IE when forwarding the response to the SMS-GMSC.
NOTE:	The User Identifier Alert is further used in the Alert Service Centre procedure specified in clause 12.5 to enable the SMS-GMSC to identify and retransmit all pending MT SMS messages towards the destination user.
When receiving an Alert Service Centre request from an MME (via an IWF), SGSN or MSC, the SMS-Router shall replace the IMSI received in the IMSI IE by the User Identifier Alert previously sent in the MT Forward Short Message Response, and forward that request to the SMS-GMSC.
23.3.7	Procedure in the IP-SM-GW 
Process MT_SM_IPSMGW sheet 3: After unsuccessful delivery via the S-CSCF the IP-SM-GW may retry delivery via MSC and/or SGSN if MSC address and/or SGSN address are available (unless the reported error was "memory capacity exceeded" in which case a retry shall not be done). If the retry is successful, a positive response is returned to the SMS-GMSC. If the retry is unsuccessful, an error indication is returned to the SMS-GMSC as follows:
If one of the error indications received from S-CSCF, MSC, or SGSN is AbsentsSubscriberSM or  UnidentifiedSubscriber, this error shall be returned to the SMS-GMSC.
Process MT_SM_IPSMGW sheet 3: The IP-SM-GW invokes the macro Report_SM_Delivery_Stat_IPSMGW if: 
-	the reason for failure to deliver the message is absent subscriber_SM, unidentified subscriber or SM delivery failure with error cause "MS memory capacity exceeded", and the SC address is not yet included in the MWD set, or
-	the reason for failure to deliver the message is absent subscriber_SM, unidentified subscriber or SM delivery failure with error cause MS memory capacity exceeded, and the corresponding flag in the HLR (as indicated in the information received in the MAP_INFORM_SERVICE_CENTRE) is not set, or
-	the reason for failure to deliver the message is absent subscriber_SM and the absent subscriber diagnostic is different from the absent subscriber diagnostic received in the MAP_INFORM_SERVICE_CENTRE.

The mobile terminated short message transfer process in the IP-SM-GW is shown in figure 23.3/15.



Figure 23.3/3 (sheet 1 of 2): Process MT_SM_GMSC

Figure 23.3/3 (sheet 2 of 2): Process MT_SM_GMSC

Figure 23.3/4 (sheet 1 of 8): Procedure MT_SM_Delivery_Attempt_GMSC
 
Figure 23.3/4 (sheet 2 of 8): Procedure MT_SM_Delivery_Attempt_GMSC

Figure 23.3/4 (sheet 3 of 8): Procedure MT_SM_Delivery_Attempt_GMSC
 
Figure 23.3/4 (sheet 4 of 8): Procedure MT_SM_Delivery_Attempt_GMSC

Figure 23.3/4 (sheet 5 of 8): Procedure MT_SM_Delivery_Attempt_GMSC

Figure 23.3/4 (sheet 6 of 8): Procedure MT_SM_Delivery_Attempt_GMSC

Figure 23.3/4 (sheet 7 of 8): Procedure MT_SM_Delivery_Attempt_GMSC

Figure 23.3/4 (sheet 8 of 8): Procedure MT_SM_Delivery_Attempt_GMSC

Figure 23.3/5 (sheet 1 of 6): Process MT_SM_HLR

Figure 23.3/5 (sheet 2 of 6): Process MT_SM_HLR

Figure 23.3/5 (sheet 3 of 6): Process MT_SM_HLR

Figure 23.3/5 (sheet 4 of 6): Process MT_SM_HLR

Figure 23.3/5 (sheet 5 of 6): Process MT_SM_HLR

Figure 23.3/5 (sheet 6 of 6): Process MT_SM_HLR

Figure 23.3/5a (sheet 1 of 1): Procedure Perform_Relaying

Figure 23.3/6 (sheet 1 of 4): Procedure MT_SM_VMSC

Figure 23.3/6 (sheet 2 of 4): Procedure MT_SM_VMSC

Figure 23.3/6 (sheet 3 of 4): Procedure MT_SM_VMSC

Figure 23.3/6 (sheet 4 of 4): Procedure MT_SM_VMSC

Figure 23.3/7 (sheet 1 of 4): Macro MT_SM_Transfer_MSC

Figure 23.3/7 (sheet 2 of 4): Macro MT_SM_Transfer_MSC

Figure 23.3/7 (sheet 3 of 4): Macro MT_SM_Transfer_MSC

Figure 23.3/7 (sheet 4 of 4): Macro MT_SM_Transfer_MSC

Figure 23.3/8: Macro Check_Subscr_Identity_For_MT_SMS

Figure 23.3/9 (sheet 1 of 3): Process MT_SM_VLR

Figure 23.3/9 (sheet 2 of 3): Process MT_SM_VLR

Figure 23.3/9 (sheet 3 of 3): Process MT_SM_VLR

Figure 23.3/10 (sheet 1 of 4): Process MT_SM_SGSN

Figure 23.3/10 (sheet 2 of 4): Process MT_SM_ SGSN

Figure 23.3/10 (sheet 3 of 4): Process MT_SM_ SGSN

Figure 23.3/10 (sheet 4 of 4): Process MT_SM_ SGSN

Figure 23.3/11 (sheet 1 of 3): Macro MT_SM_TRANSFER_SGSN

Figure 23.3/11 (sheet 2 of 3): Macro MT_SM_TRANSFER_SGSN

Figure 23.3/11 (sheet 3 of 3): Macro MT_SM_TRANSFER_SGSN

Figure 23.3/12 (sheet 1 of 1): Procedure Page_SMS_SGSN

Figure 23.3/13 (sheet 1 of 1): Procedure Search_SMS_SGSN

Figure 23.3/14 (sheet 1 of 4): Process MT_SM_ SMS_ROUTER 

Figure 23.3/14 (sheet 2 of 4): Process MT_SM_ SMS_ROUTER

Figure 23.3/14 (sheet 3 of 4): Process MT_SM_ SMS_ROUTER

Figure 23.3/14 (sheet 4 of 4): Process MT_SM_ SMS_ROUTER

Figure 23.3/15 (sheet 1 of 3): Process MT_SM_ IPSMGW

Figure 23.3/15 (sheet 2 of 3): Process MT_SM_ IPSMGW

Figure 23.3/15 (sheet 3 of 3): Process MT_SM_ IPSMGW
23.4	The Short Message Alert procedure
The Short Message Alert procedure is used to alert the Service Centre when the mobile subscriber is active after a short message transfer has failed because the mobile subscriber is not reachable, or when the MS has indicated that it has memory capacity to accept a short message.
The message flow for the Short Message Alert procedure for the case when the mobile subscriber was not reachable is shown in figure 23.4/1.


1)	CM Service Request (**), Page response or Location Updating (3GPP TS 24.008 [35]).
2)	MAP_PROCESS_ACCESS_REQUEST / MAP_UPDATE_LOCATION_AREA (**).
3)	MAP_READY_FOR_SM (Mobile Present) / MAP_UPDATE_LOCATION /
Supplementary Service Control Request (*).
4)	MAP_READY_FOR_SM_ACK (*).
5)	MAP_ALERT_SERVICE_CENTRE (notes 1 and 2).
6)	Alert Service Centre (3GPP TS 23.040).
7)	MAP_ALERT_SERVICE_CENTRE_ACK.
NOTE 1:	To all Service Centres in the Message Waiting List.
NOTE 2:	The HLR initiates the MAP_ALERT_SERVICE_CENTRE service only if the MS Memory Capacity Exceeded flag is clear.
(*)	For GPRS, messages 3) and 4) are sent/received by the SGSN.
(**)	These messages are not used by the SGSN.

Figure 23.4/1: Short message alert procedure (Mobile is present)
The message flow for the Short Message Alert procedure for the case where the MS indicates that it has memory capacity to accept one or more short messages is shown in figure 23.4/2.


1)	SM memory capacity available ( 3GPP TS 24.011 [37]).
2)	MAP_READY_FOR_SM (Memory Available) (*).
3)	MAP_READY_FOR_SM (Memory Available) (**).
4)	MAP_READY_FOR_SM_ACK (**).
5)	MAP_READY_FOR_SM_ACK (*).
6)	SM memory capacity available (Acknowledge) (3GPP TS 24.011 [37]).
7)	MAP_ALERT_SERVICE_CENTRE (note).
8)	Alert Service Centre (3GPP TS 23.040).
9)	MAP_ALERT_SERVICE_CENTRE_ACK.
NOTE:	To all Service Centres in the Message Waiting List.
(*)	Messages 2) and 5) are not used by the SGSN.
(**)	For GPRS, messages 3) and 4) are sent/received by the SGSN.

Figure 23.4/2: Short message alert procedure (MS memory capacity available)
In addition the following MAP services are used in the MS memory available case:
MAP_PROCESS_ACCESS_REQUEST	(see clause 8.3); (*)
MAP_AUTHENTICATE	(see clause 8.5); (*)
MAP_SET_CIPHERING_MODE	(see clause 8.6); (*)
MAP_PROVIDE_IMSI	(see clause 8.9); (*)
MAP_CHECK_IMEI	(see clause 8.7); 
MAP_FORWARD_NEW_TMSI	(see clause 8.9); (*)
MAP_TRACE_SUBSCRIBER_ACTIVITY	(see clause 9.1). (*)
(*)	These services are not used by the SGSN.
The Short Message Alert procedure when the MS indicates successful transfer after polling is shown in figure 23.4/3.


1)	MAP_REPORT_SM_DELIVERY_STATUS (Successful Transfer).
2)	MAP_REPORT_SM_DELIVERY_STATUS_ACK.
3)	MAP_ALERT_SERVICE_CENTRE (note).
4)	Alert Service Centre (3GPP TS 23.040).
5)	MAP_ALERT_SERVICE_CENTRE_ACK.
NOTE:	To all Service Centres in the Message Waiting List.

Figure 23.4/3: Short message alert procedure (Successful transfer after polling)
23.4.1	Procedure in the Serving MSC – the MS has memory available
The process starts when the MSC receives a notification from the MS that it has memory available. The process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Check_Confirmation	see clause 25.2.2.
The short message alert process in the MSC for the MS memory capacity available case is shown in figure 23.4/4.
23.4.2	Procedures in the VLR
23.4.2.1	The Mobile Subscriber is present
If the VLR successfully handles a MAP_PROCESS_ACCESS_REQUEST indication or a MAP_UPDATE_LOCATION_AREA indication while the MS Not Reachable Flag (MNRF) is set, the VLR sends a MAP_READY_FOR_SM request to the HLR. The Alert Reason is set to indicate that the mobile subscriber is present for non GPRS. If authentication fails during the handling of a MAP_PROCESS_ACCESS_REQUEST indication or a MAP_UPDATE_LOCATION_AREA indication, the VLR shall not send a MAP_READY_FOR_SM request to the HLR. The process in the VLR is described in detail in clause 25.10.1.
23.4.2.2	The MS has memory available
The process starts when the VLR receives dialogue opening request followed by a MAP_PROCESS_ACCESS_REQUEST indication including a CM service type Short Message Service. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind	see clause 25.1.1;
Receive_Open_Cnf	see clause 25.1.2;
Check_Indication	see clause 25.2.1;
Check_Confirmation	see clause 25.2.2.
The short message alert process in the VLR for the MS memory capacity available case is shown in figure 23.4/5.
23.4.3	Procedures in the SGSN
23.4.3.1	The Mobile Subscriber is present
If the SGSN successfully handles a Page response, Attach request or Routing Area Update request message (3GPP TS 24.008 [35]), while the MS Not Reachable for GPRS (MNRG) flag is set, the SGSN sends a MAP_READY_FOR_SM request to the HLR. The Alert Reason is set to indicate that the mobile subscriber is present for GPRS. If authentication fails during the handling of a Page response, Attach request or Routing Area Update request, the SGSN shall not send a MAP_READY_FOR_SM request to the HLR
The process in the SGSN is described in detail in clause 25.10.23.
23.4.3.2	The Mobile Equipment has memory available
The process starts when the SGSN receives an RP_SM_MEMORY_AVAILABLE indication from the MS. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
The short message alert procedure in the SGSN for the MS memory capacity available case is shown in figure 23.4/6.
23.4.4	Procedure in the HLR
The process starts when the HLR receives a dialogue opening request using the application context mwdMngtContext. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind	see clause 25.1.1;
Check_Indication	see clause 25.2.1;
Alert_Service_Centre_HLR	see clause 25.10.3.
Sheet 1: If the dialogue opening request is from an SGSN, version 2 and version 1 of the application context are not applicable.
The short message alert process in the HLR is shown in figure 23.4/7.
23.4.5	Procedure in the SMS Interworking MSC
The process starts when the SMS-IWMSC receives a dialogue opening request using the application context shortMsgAlertContext. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind	see clause 25.1.1;
Check_Indication	see clause 25.2.1.
The short message alert process in the SMS-IWMSC is shown in figure 23.4/8.


Figure 23.4/4: Procedure SM_Alert_MSC

Figure 23.4/5 (sheet 1 of 2): Procedure SM_Alert_VLR

Figure 23.4/5 (sheet 2 of 2): Procedure SM_Alert_VLR

Figure 23.4/6 (sheet 1 of 2): Process SM_Alert_SGSN

Figure 23.4/6 (sheet 2 of 2): Process SM_Alert_SGSN

Figure 23.4/7 (sheet 1 of 2): Process SM_Alert_HLR

Figure 23.4/7 (sheet 2 of 2): Process SM_Alert_HLR


Figure 23.4/8: Process Alert_SC_IWMSC
23.5	The SM delivery status report procedure
The SM delivery status report procedure is used:
-	to set the Service Centre address into the message waiting list in the HLR after short message delivery has failed because the subscriber is absent or unidentified or the memory capacity is exceeded. The procedure sets: 
-	the Memory Capacity Exceeded Flag (MCEF) in the HLR if the MS memory does not have room for more messages;
-	and/or the MS Not Reachable Flag for non-GPRS if there is no record for the subscriber in the VLR or the subscriber does not respond to paging for delivery via the MSC;
-	and/or the MS Not Reachable for GPRS (MNRG) flag if there is no record for the subscriber in the SGSN or the subscriber does not respond to paging for delivery via the SGSN; 
-	and/or the UE Not Reachable for IP (UNRI) flag if delivery via the IMS was not successful.
-	to report to the HLRthat delivery has succeeded. The conditions for report of a successful delivery are described in clause 23.3.1.
The message flow for the SM delivery status report procedure is shown in figure 23.5/1.


1)	MAP_MT_FORWARD_SHORT_MESSAGE_ACK/_NACK (Absent subscriber_SM,
unidentified subscriber or memory capacity exceeded).
2)	MAP_REPORT_SM_DELIVERY_STATUS. (The HLR ignores the content of this message when an IP-SM-GW is deployed)
2a)	MAP_REPORT_SM_DELIVERY_STATUS (sent only by IP-SM-GW)
2b)	MAP-REPORT_SM_DELIVERY_STATUS_ACK.
3)	MAP_REPORT_SM_DELIVERY_STATUS_ACK.
4)	Short Message Negative Acknowledgement (3GPP TS 23.040).

Figure 23.5/1: Short message delivery status report procedure
23.5.1	Procedure in the SMS-GMSC
The conditions for the GMSC to invoke the short message delivery status report procedure are specified in clause 23.3.1.
The short message delivery status report macro in the SMS-GMSC is shown in figure 23.5/2.
23.5.2	Procedure in the HLR
When the HLR receives a MAP_REPORT_SM_DELIVERY_STATUS indication while an IP-SM-GW is deployed in the network and the message is not received from an IP-SM-GW, it ignores the information received in the message; otherwise it acts as described in clause 23.6, macro Report_SM_Delivery_Stat_HLR.
The short message delivery status report process in the HLR is shown in figure 23.5/3.
23.5.3	Procedure in the IP-SM-GW
The conditions for the IP-SM-GW and for SMS Router, if deployed with IP-SM-GW, to invoke the short message delivery status report procedure are specified in clause 23.3.7.
The short message delivery status report macro in the IP-SM-GW is shown in figure 23.5/4.



Figure 23.5/2: Macro Report_SM_Delivery_Stat_GMSC

Figure 23.5/3: Process SM_Delivery_Status_Report_HLR

Figure 23.5/4: Macro Report_SM_Delivery_Stat_IPSMGW
23.6	The macro Report_SM_Delivery_Stat_HLR
This macro is invoked when the HLR receives a MAP_REPORT_SM_DELIVERY_STATUS indication from the SMS-GMSC. The macro invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Check_Indication	see clause 25.2.1;
Alert_Service_Centre_HLR	see clause 25.10.3.
Sheet 1: If the MAP_REPORT_SM_DELIVERY_STATUS indication did not include the GPRS support indicator, the HLR deduces the domain for which the delivery report applies as follows:
-	if the subscriber is a GPRS-only subscriber, the report applies for GPRS;
-	if the subscriber is a non-GPRS-only subscriber, the report applies for non-GPRS;
-	if the subscriber is a GPRS and non-GPRS subscriber and the subscription option for MT SMS delivery when the SMS-GMSC does not support GPRS is set to "Delivery via the SGSN", the report applies for GPRS;
-	if the subscriber is a GPRS and non-GPRS subscriber and the subscription option for MT SMS delivery when the SMS-GMSC does not support GPRS is set to "Delivery via the MSC", the report applies for non-GPRS;
The short message delivery status report macro in the HLR is shown in figure 23.6/1.


Figure 23.6/1 (sheet 1 of 2): Macro Report_SM_Delivery_Stat_HLR

Figure 23.6/1 (sheet 2 of 2): Macro Report_SM_Delivery_Stat_HLR
23.7	The mobile terminated short message transfer procedure for VGCS
The mobile terminated short message transfer for VGCS procedure is used for forwarding a short message from a Service Centre to the group call anchor MSC. The message flow for the mobile terminated short message transfer procedure for VGCS is shown in figure 23.7/1.

Figure 23.7/1: Mobile terminated short message for VGCS service procedures
1)	Short Message (3GPP TS 23.040).
2)	TCAP BEGIN (*)
3)	TCAP CONTINUE (*)
4)	MAP_MT_FORWARD_SM_FOR_VGCS.
5)	GCR_SMS_INTERROGATION (3GPP TS 43.068).
6)	GCR_SMS_INTERROGATION_ACK (3GPP TS 43.068).
7)	MAP_MT_FORWARD_SM_FOR_VGCS_ACK.
8)	Short Message Acknowledgement (3GPP TS 23.040).

(*)	If 
	a)
-	the capacity of a message signal unit in the lower layers of the protocol is enough to carry the	content of the MAP_OPEN request and the content of the MAP_MT_FORWARD_SM_FOR_VGCS request in a single TC message, 

	and
	b)	the SMS Gateway MSC operator and the serving node (Anchor-MSC) operator
	agreed not to use the TCAP handshake countermeasure against SMS fraud for
	messages exchanged between their networks (see 3GPP TS 33.204 [34a])
	then
	the TCAP handshake may be omitted.

23.7.1	Procedure in the SMS-GMSC
The process starts when the SMS-GMSC receives an SC_RP_MT_DATA indication from a Service Centre. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf		see clause 25.1.2;
Check_Confirmation		see clause 25.2.2.
The mobile terminated short message transfer for VGCS process in the SMS-GMSC is shown in figure 23.7/2. 
23.7.2	Procedure in the Anchor MSC
The process starts when the MSC receives a dialogue opening request with the application context shortMsgMT-Relay-VGCS-Context. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind		see clause 25.1.1;
The mobile terminated short message transfer for VGCS process in the Anchor MSC is shown in figure 23.7/3 
Procedure MT_SM_VGCS_GMSC sheet 1: The decision box "TCAP Handshake required" takes the "yes" or "no" exit depending on agreements between the Serving MSC's operator and the SMS Gateway MSC's operator (see 3GPP TS 33.204 [34a]).

Figure 23.7/2 (sheet 1 of 2): Process MT_SM_VGCS_GMSC

Figure 23.7/2 (sheet 2 of 2): Process MT_SM_VGCS_GMSC

Figure 23.7/3 (sheet 1 of 2): Process MT_SM_VGCS_Anchor MSC

Figure 23.7/3 (sheet 2 of 2): Process MT_SM_VGCS_Anchor MSC
24	GPRS process description
The MAP GPRS procedures are used for the Network Requested PDP-Context Activation procedures.
The stage 2 specification for General Packet Radio Service (GPRS) is in 3GPP TS 23.060 [104].
24.1	Procedure for retrieval of routeing information for GPRS
24.1.1	Process in the GGSN 
The MAP process in the GGSN to request routeing information for a network requested PDP context activation is shown in figure 24.1/2. The MAP process invokes macros not defined in this clause; the definition of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
24.1.2	Process in the HLR 
The MAP process in the HLR to provide routing information for a network-requested PDP context activation is shown in figure 24.1/1. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind	see clause 25.1.1;
Check_Indication	see clause 25.2.1.


Figure 24.1/1: Process SRI_GPRS_GGSN

Figure 24.1/2: Process SRI_GPRS_HLR
24.2	Procedure for reporting failure to establish a network requested PDP context
24.2.1	Process in the GGSN
The MAP process in the GGSN to report the failure to establish a network requested PDP context is shown in figure 24.2/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
24.2.2	Process in the HLR
The MAP process in the HLR to handle a notification from the GGSN that a network requested PDP context could not be established is shown in figure 24.2/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind	see clause 25.1.1;
Check Indication	see clause 25.2.1.


Figure 24.2/1: Process Failure_Report_GGSN

Figure 24.2/2: Process Failure_Report_HLR
24.3	Procedure for reporting that an MS has become reachable for GPRS
24.3.1	Process in the HLR
The MAP process in the HLR to report that an MS is reachable for GPRS is shown in figure 24.3/1. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
24.3.2	Process in the GGSN for Note Ms Present For Gprs
The MAP process in the GGSN to handle a notification that the subscriber is present for GPRS again is shown in figure 24.3/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind	see clause 25.1.1;
Check_Indication	see clause 25.2.1.


Figure 24.3/1: Process Note_MS_Present_For_GPRS_HLR

Figure 24.3/2: Process Note_MS_Present_For_GPRS_GGSN
24A	CSE interrogation and control of subscriber data
24A.1	General
The MAP procedures for interrogation and control of subscriber data are used to allow the CSE:
-	to retrieve subscriber data from the HLR;
-	to modify subscriber data in the HLR;
-	to receive notification from the HLR when there is a change in subscriber data;
-	to request information about the location of a subscriber from the HLR or the GMLC;
-	to request information about the state of a subscriber from the HLR.
The following application context refers to a complex MAP user consisting of several processes:
-	anyTimeInfoHandlingContext
This application context needs a co-ordinating process in the HLR.
The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind	see clause 25.1.1;
The Any Time Info Handling Co-ordinator process in the HLR is shown in figure 24A.1/1.


Figure 24A.1/1: Process Co_ATIH_HLR
24A.2	Any Time Subscription Interrogation procedure
24A.2.1	General
The message flow for successful retrieval of subscription information related to an any time subscription interrogation from the CAMEL server are shown in figure 24A.1/1.  In an IP Multimedia Core Network, an IM-SSF can take on the role of a gsmSCF for this procedure (see 3GPP TS 23.278 [125]).  

Figure 24A.2/1: Message flow for any time subscription interrogation
The following MAP service is used to retrieve requested information:
MAP_ANY_TIME_SUBSCRIPTION_INTERROGATION	see clause 8.11.3.
24A.2.2	Process in the gsmSCF
The MAP process in the gsmSCF to obtain subscription information in response to a request from the application process in the gsmSCF is shown in figure 24A.2/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2
24A.2.3	Process in the HLR
The MAP process in the HLR to provide subscription information in response to an interrogation from the CAMEL server is shown in figure 24A.2/3. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Check_Indication	see clause 25.2.2
If the MAP_ANY_TIME_SUBSCRIPTION_INTERROGATION service response cannot be carried in a single TC-Result component, it is carried in one or more TC-Result-NL components (each sent in a TC-CONTINUE), followed by a TC-Result-L component in a TC-END message.


Figure 24A.2/2: Process ATSI_gsmSCF

Figure 24A.2/3: Process ATSI_HLR
24A.3	Any Time Modification procedure
24A.3.1	General
The message flow for successful modification of subscription information related to an any time modification request from the CAMEL server is shown in figure 24A.3/1

Figure 24A.3/1: Message flow for any time modification
The following MAP service is used to modify subscription information:
MAP_ANY_TIME_MODIFICATION			see clause 8.11.4.
24A.3.2	Process in the gsmSCF
The MAP process in the gsmSCF to modify subscription information in response to a request from the application process in the gsmSCF is shown in figure 24A.3/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2
24A.3.3	Process in the HLR
The MAP process in the HLR to modify subscriber information in response to a modification request from the CAMEL server is shown in figure 24A.3/3. The MAP process invokes a macro and a process not defined in this clause; the definitions of these can be found as follows:
Check_Indication		see clause 25.2.2;
Insert_Subs_Data_Stand_Alone_HLR	see clause 25.7.3;
If the macro takes the OK exit, the MAP process waits for a service indication.
If the MAP_ANY_TIME_MODIFICATION service response cannot be carried in a single TC-Result component, it is carried in one or more TC-Result-NL components (each sent in a TC-CONTINUE), followed by a TC-Result-L component in a TC-END message. 
If the serving node (VLR or SGSN) is to be updated after the modification, the MAP process creates an instance of the appropriate process (Insert_Subs_Data_Stand_Alone_HLR for VLR update, Insert_GPRS_Subs_Data_Stand_Alone_HLR for SGSN update).


Figure 24A.3/2: Process ATM_gsmSCF

Figure 24A.3/3: Process ATM_HLR
24A.4	Subscriber Data Modification Notification procedure
24A.4.1	General
The Subscriber Data Modification Notification procedure is used to notify a gsmSCF about the modification of subscriber data. In an IP Multimedia Core Network, an IM-SSF can take on the role of a gsmSCF for this procedure.
The stage 2 specification for Subscriber Data Modification Notification is in 3GPP TS 23.078 [98] and 3GPP TS 23.278 [125]. The interworking between the MAP signalling procedures and the Subscriber Data Modification Notification procedures for each entity (HLR, gsmSCF) is shown by the transfer of signals between these processes.
The following services are used:

Figure 24A.4/1: Message flow for subscriber data modification notification
The following MAP service is used to send the notification to the gsmSCF:
MAP_NOTE_SUBSCRIBER_DATA_MODIFIED		see clause 8.11.5.
24A.4.2	Process in the HLR
The MAP process in the HLR to send modified data to the gsmSCF is shown in figure 24A.4/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
If the required information cannot be carried in a single MAP_NOTE_SUBSCRIBER_DATA_MODIFIED service request, the HLR segments the information into two or more requests. The "All Information Sent" parameter is omitted from each request except the last.
Sheet 2: If the MAP_NOTE_SUBSCRIBER_DATA_MODIFIED service request contained the "All Information Sent" parameter, the test "All information sent" takes the "Yes" exit.
24A.4.3	Process in the gsmSCF
The MAP process in the gsmSCF to handle a notification to the gsmSCF of change of subscriber data is shown in figure 24A.4/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind	see clause 25.1.1;
Check_Indication	see clause 25.2.1
If the MAP_NOTE_SUBSCRIBER_DATA_MODIFIED service indication contained the "All Information Sent" parameter, the test "All information sent" takes the "Yes" exit.
If the test "All information sent" takes the "No" exit, the MAP process stores the data received in the MAP_NOTE_SUBSCRIBER_DATA_MODIFIED service indication. If the test "All information sent" takes the "Yes" exit, the MAP process assembles the data received in all the MAP_NOTE_SUBSCRIBER_DATA_MODIFIED service indications received in the dialogue and sends the assembled data to the application process in the gsmSCF.


Figure 24A.4/2 (sheet 1 of 2): Process NSDC_HLR

Figure 24A.4/2 (sheet 2 of 2): Process NSDC_HLR

Figure 24A.4/3: Process NSDC_gsmSCF
24A.5	Any Time Interrogation procedure
24A.5.1 General
The message flows for successful retrieval of subscriber information related to an any time interrogation from the CAMEL server are shown in figure 24A.5/1 for interrogation directed to an HLR and figure 24A.5/2 for interrogation directed to a GMLC.


1)	MAP_ANY_TIME_INTERROGATION_req/ind
2)	MAP_PROVIDE_SUBSCRIBER_INFO_req/ind
3)	MAP_PROVIDE_SUBSCRIBER_INFO_rsp/cnf
4)	MAP_ANY_TIME_INTERROGATION_rsp/cnf

Figure 24A.5/1: Message flow for any time interrogation (gsmSCF to HLR)
The following MAP services are used to retrieve information about the status and/or location of a subscriber:
MAP_ANY_TIME_INTERROGATION	see clause 8.11.1;
MAP_PROVIDE_SUBSCRIBER_INFO	see clause 8.11.2.
The HLR sends the MAP_PROVIDE_SUBSCRIBER_INFO request to the SGSN or the VLR, according to the domain for which the gsmSCF requested the information.


1)	MAP_ANY_TIME_INTERROGATION_req/ind
2)	MAP_ANY_TIME_INTERROGATION_rsp/cnf

Figure 24A.5/2: Message flow for any time interrogation (gsmSCF to GMLC)
The following MAP service is used to retrieve location information from a GMLC:
MAP_ANY_TIME_INTERROGATION	see clause 8.11.1;
In addition, the GMLC may use MAP Services specific to Location Services.
24A.5.2	Procedures in the gsmSCF
The process in the gsmSCF to request information about the location and/or state of a subscriber from the HLR is shown in figure 24A.5/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
The process in the gsmSCF to request location information from the GMLC is shown in figure 24A.5/4. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
24A.5.3	Procedure in the HLR
The MAP process in the HLR to provide subscriber information in response to an interrogation from the CAMEL server is shown in figure 24A.5/5. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind	see clause 25.1.1;
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
24A.5.4	Procedure in the GMLC
The MAP process in the GMLC to provide location information in response to a request from the gsmSCF is shown in figure 24A.5/6. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows:
Receive_Open_Ind	see clause 25.1.1.


Figure 24A.5/3: Process ATI_To_HLR_gsmSCF 

Figure 24A.5/4: Process ATI_To_GMLC_gsmSCF 

Figure 24A.5/5 (sheet 1 of 2): Process ATI_HLR

Figure 24A.5/5 (sheet 2 of 2): Process ATI_HLR

Figure 24A.5/6: Process ATI_GMLC
24B	Location Services process description
24B.1	Routeing information retrieval procedure for LCS
24B.1.1	General
The message flow for successful retrieval of routeing information related to location services is shown in figure 24B.1/1.

Figure 24B.1/1: Message flow for retrieval of routeing information for LCS
The following MAP service is used to retrieve routeing information:
MAP_SEND_ROUTING_INFO_FOR_LCS		see clause 13A.1.
24B.1.2	Process in the GMLC
The MAP process in the GMLC to request routeing information for LCS is shown in figure 24B.1/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
24B.1.3	Process in the HLR
The MAP process in the HLR to handle a request for routeing information for LCS is shown in figure 24B.1/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind	see clause 25.1.1;
Check_Indication	see clause 25.2.1.


Figure 24B.1/2: Process SRI_LCS_GMLC

Figure 24B.1/3: Process SRI_LCS_HLR
24B.2	Provide Subscriber Location procedure
24B.2.1	General
The message flow for successful retrieval of the location information of a target MS related to location services is shown in figure 24B.1/1.

Figure 24B.2/1: Message flow for retrieval of location information
The following MAP service is used to retrieve location information:
MAP_PROVIDE_SUBSCRIBER_LOCATION		see clause 13A.2.
24B.2.2	Process in the GMLC
The MAP process in the GMLC to request location information from an MSC or an SGSN is shown in figure 24B.2/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
24B.2.3	Process in the MSC
The MAP process in the MSC to handle a request for location information from a GMLC is shown in figure 24B.2/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind	see clause 25.1.1;
Check_Indication	see clause 25.2.1.
24B.2.4	Process in the SGSN
The MAP process in the SGSN to handle a request for location information from a GMLC is shown in figure 24B.2/4. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind	see clause 25.1.1;
Check_Indication	see clause 25.2.1.


Figure 24B.2/2: Process PSL_GMLC

Figure 24B.2/3: Process PSL_MSC

Figure 24B.2/4: Process PSL_SGSN
24B.3	Subscriber Location Report procedure
24B.3.1	General
The message flow for successful report of the location information of a target MS related to location services is shown in figure 24B.3/1.

Figure 24B.3/1: Message flow for report of the location information
The following MAP services are used to report location information:
MAP_SUBSCRIBER_LOCATION_REPORT		see clause 13A.3.
24B.3.2	Process in the MSC
The MAP process in the MSC to send a subscriber location report to the GMLC is shown in figure 24B.3/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
24B.3.3	Process in the SGSN
The MAP process in the SGSN to send a subscriber location report to the GMLC is shown in figure 24B.3/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Cnf	see clause 25.1.2;
Check_Confirmation	see clause 25.2.2.
24B.3.4	Process in the GMLC
The MAP process in the GMLC to handle a subscriber location report is shown in figure 24B.3/4. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows:
Receive_Open_Ind	see clause 25.1.1;
Check_Indication	see clause 25.2.1.


Figure 24B.3/2: Process SLR_MSC

Figure 24B.3/3: Process SLR_SGSN

Figure 24B.3/4: Process SLR_GMLC
25	General macro description
25.1	MAP_OPEN handling macros
25.1.1	Macro Receive_Open_Ind
This macro is used by a MAP service-user procedure when a peer entity requests opening of a dialogue.
25.1.2	Macro Receive_Open_Cnf
This macro is used by a user procedure after it has requested opening of a dialogue towards a peer entity.


Figure 25.1/1 (sheet 1 of 2): Macro Receive_Open_Ind

Figure 25.1/1 (sheet 2 of 2): Macro Receive_Open_Ind

Figure 25.1/2: Macro Receive_Open_Cnf

Figure 25.1/3: Macro Check_Reference
25.2	Macros to check the content of indication and confirmation primitives
25.2.1	Macro Check_Indication
This macro checks that an indication includes all the parameters required by the application, no more and no less, and that the parameters are all within the correct range. It does not handle syntax checking; that is part of the function of the MAP protocol machine.
25.2.2	Macro Check_Confirmation
This macro checks whether a confirmation contains an error or a result, and if it contains a result whether the result is correctly formed.


Figure 25.2/1: Macro Check_Indication

Figure 25.2/2: Macro Check_Confirmation
25.3	The page and search macros
25.3.1	Macro PAGE_MSC
This macro is called if an unstructured SS notification, a network-initiated unstructured SS request or a mobile terminating short message is to be delivered to the MS and the current location area identity of the MS is known in the VLR.
If an MM-connection over the radio link already exists for the given IMSI, the MSC sets the access connection status according to the characteristics of the existing connection (i.e. RR-connection established, ciphering mode on/off, MM-connection existing and authenticated or not).
If the MSC pages the MS and the VLR provided the TMSI, the MSC uses it to identify the MS at the radio interface; otherwise the MSC uses the IMSI. The MSC also uses the IMSI to determine the page group (see 3GPP TS 24.008 [35]).
If the MS responds with a channel request containing an establishment cause which is not "answer to paging" the MSC sends a MAP_PAGE response primitive with user error Busy Subscriber. This gives priority to the mobile originating request. Alternatively, as an implementation option, the MSC may treat this as a response to paging, which gives priority to the mobile terminating request.
If the paging is for MT SMS delivery and the VLR aborts the transaction before the MSC receives a response from the MS, the MSC aborts the transaction with the SMS-GMSC.
25.3.2	Macro Search_For_MS_MSC
This macro is called if an unstructured SS notification, a network-initiated unstructured SS request or a mobile terminating short message is to be delivered to the MS and the current location area identity of the MS is not known in VLR.
If an MM-connection over the radio link already exists for the given IMSI, the MSC returns a MAP_SEARCH_FOR_MS response containing the IMSI and current location area identification of the called MS to the VLR and sets the access connection status according to the characteristics of the existing connection (i.e. RR-connection established, ciphering mode on/off, MM-connection existing and authenticated or not).
If the MSC pages the MS, the MSC uses the IMSI to identify the subscriber and the page group (see 3GPP TS 24.008 [35]). 
If the MS responds with a channel request containing an establishment cause which is not "answer to paging" the MSC sends a MAP_SEARCH_FOR_MS response with user error Busy Subscriber. This gives priority to the mobile originating request. Alternatively, as an implementation option, the MSC may treat this as a response to paging, which gives priority to the mobile terminating request.
If the paging is for MT SMS delivery and the VLR aborts the transaction before the MSC receives a response from the MS, the MSC aborts the transaction with the SMS-GMSC.


Figure 25.3/1: Macro Page_MSC

Figure 25.3/2: Macro Search_for_MS_MSC
25.4	Macros for handling an Access Request
These macros are invoked when a MS accesses the network, e.g. to submit an MO short message or when responding to paging. The macros handle identification and authentication of the mobile subscriber as well as invocation of security related features (see 3GPP TS 42.009 [6]).
25.4.1	Macro Process_Access_Request_MSC
Sheet 1: The MAP_PROCESS_ACCESS_REQUEST request includes the following parameters: 
-	the received subscriber identification (IMSI, TMSI);
-	the CM service type, indicating the type of request;
-	the status of the access connection, i.e. whether a connection to this MS already exists and if so, whether it is already authenticated and ciphered;
-	the current location area id of the MS; and
-	the CKSN received from the MS.
Sheet 2, sheet 3: If the MSC receives an A_SETUP indication while it is waiting for further instructions from the VLR or for the acknowledgment of TMSI reallocation from the MS, the MSC saves the setup request for processing after control has returned from the macro Process_Access_Request_MSC to the calling process.
Sheet 3: When the MSC is waiting for a possible instruction to allocate a new TMSI, a MAP_DELIMITER indication indicates that TMSI reallocation is not required.
Sheet 3: If the MS sends a TMSI reallocation failure in response to the TMSI reallocation command, the MSC takes the OK exit; the VLR treats the lack of response as a provider error (see macro Process_Access_Request_VLR).
25.4.2	Macro Process_Access_Request_VLR
Sheet 3: If the MSC does not send a positive response to the MAP_FORWARD_NEW_TMSI request, this is treated as a MAP_FORWARD_NEW_TMSI confirmation containing a provider error. The Macro takes the Error exit. If TMSI reallocation does not succeed, the old TMSI is frozen, to prevent it from being reallocated. In this case, both old and new TMSIs are regarded as valid.
25.4.3	Macro Obtain_Identity_VLR
This macro is invoked by the macro Process_Access_Request_VLR if the subscriber's identity is not known in the VLR.
It is an operator option to allow or prevent retrieval of the IMSI without encryption.
25.4.4	Process Update_Location_Child_VLR
This process is started when the subscriber successfully accesses the network, e.g. for mobile originated short message submission, response to paging or supplementary services handling. 
The procedure Notify_gsmSCF is specified in 3GPP TS 23.078.


Figure 25.4/1 (sheet 1 of 3): Macro Process_Access_Request_MSC

Figure 25.4/1 (sheet 2 of 3): Macro Process_Access_Request_MSC

Figure 25.4/1 (sheet 3 of 3): Macro Process_Access_Request_MSC

Figure 25.4/2 (sheet 1 of 3): Macro Process_Access_Request_VLR

Figure 25.4/2 (sheet 2 of 3): Macro Process_Access_Request_VLR

Figure 25.4/2 (sheet 3 of 3): Macro Process_Access_Request_VLR

Figure 25.4/3: Macro Obtain_Identity_VLR

Figure 25.4/4 (sheet 1 of 2): Process Update_Location_Child_VLR

Figure 25.4/4 (sheet 2 of 2): Process Update_Location_Child_VLR
25.5	Authentication macros and processes
The following macros are used in the network in order to enable authentication of a mobile subscriber.
25.5.1	Macro Authenticate_MSC
This macro is used by the MSC to relay a request for authentication transparently from the VLR to the MS, wait for a response from the MS and relay the response from the MS back to the VLR. 
25.5.2	Macro Authenticate_VLR
This macro is used by the VLR to control the authentication of a subscriber.
Sheet 1: The test "Received SRES=Expected SRES" indicates:
-	a comparison of the Signed RESult received from the MS with the Signed RESult received from the HLR, if GSM authentication is used (see 3GPP TS 43.020 [24]), or
-	a comparison of the RESult received from the MS with the expected RESult received from the HLR, if UMTS authentication is used (see 3GPP TS 33.102).
25.5.3	Macro Obtain_Authent_Params_VLR
This macro is used by the VLR to request authentication vectors from the HLR.
Sheet 1, sheet 2, sheet 3: It is an operator option whether to allow the re-use of old authentication triplets.
Sheet 2, sheet 3: Old UMTS quintuplets shall not be re-used.
Sheet 2: if the VLR requests more authentication vectors in the same dialogue, the subsequent MAP_SEND_AUTHENTIFICATION_INFO request has no parameters.
25.5.4	Process Obtain_Authentication_Sets_VLR
This process is initiated by the VLR to fetch authentication vectors from a subscriber's HLR independently of any other processing. 
25.5.5	Process Obtain_Authent_Sets_SGSN
The procedure for authentication when the serving node is an SGSN is described in 3GPP TS 23.060 [104] and 3GPP TS 24.008 [35].
This Process is used by the SGSN to request authentication vectors from the HLR.
Sheet 1, sheet 2: It is an operator option whether to allow the re-use of old authentication triplets.
Sheet 2: Old UMTS quintuplets shall not be re-used.
25.5.6	Process Obtain_Authent_Sets_HLR
This process is used to provide authentication vectors (triplets or quintuplets) in response to a request from a VLR or an SGSN. 
Upon receipt of an authentication information request for a UMTS subscriber, the HLR shall return authentication quintuplets. If the user is a GSM subscriber, the HLR shall return authentication triplets.
25.5.7	Authentication Failure Reporting
25.5.7.1	General
The Authentication Failure Report procedure is used to notify an HLR about the occurrence of an authentication failure in the SGSN or VLR.
The message flows for this procedure are shown in figures 25.5/7& 25.5/8.

Figure 25.5/7: Message Flow for Authentication Failure Report – VLR to HLR

Figure 25.5/8: Message Flow for Authentication Failure Report – SGSN to HLR
25.5.7.2	Process in the VLR
25.5.7.3	Process in the SGSN
25.5.7.4	Process in the HLR


Figure 25.5/1: Macro Authenticate_MSC

Figure 25.5/2 (sheet 1 of 2): Macro Authenticate_VLR

Figure 25.5/2 (sheet 2 of 2): Macro Authenticate_VLR

Figure 25.5/3 (sheet 1 of 3): Macro Obtain_Authent_Params_VLR

Figure 25.5/3 (sheet 2 of 3): Macro Obtain_Authent_Params_VLR

Figure 25.5/3 (sheet 3 of 3): Macro Obtain_Authent_Params_VLR

Figure 25.5/4: Process Obtain_Authent_Sets_VLR

Figure 25.5/5 (sheet 1 of 2): Process Obtain_Authent_Sets_SGSN

Figure 25.5/5 (sheet 2 of 2): Process Obtain_Authent_Sets_SGSN

Figure 25.5/6 (sheet 1 of 2): Process Obtain_Authent_Sets_HLR

Figure 25.5/6 (sheet 2 of 2): Process Obtain_Authent_Sets_HLR

Figure 25.5/7: Procedure Check_Available_Vectors

Figure 25.5/9: Process Report_Authentication_Failure_VLR

Figure 25.5/10: Process Report_Authentication_Failure_SGSN

Figure 25.5/11: Process Note_Authentication_Failure_HLR
25.6	IMEI Handling Macros
The following macros are used in the network in order to enable handling and checking of the mobile equipment identity.
25.6.1	Macro Check_IMEI_MSC
This macro is used by the MSC to receive a request from the VLR, relay it to the EIR, and pass the result from the EIR back to the VLR.
Sheet 1: If the dialogue with the EIR drops back to a previous protocol version and the EIR returned an error, the MSC relays the error to the VLR in the MAP_CHECK_IMEI response. If the dialogue with the EIR failed, or the EIR returned a badly formed result, the MSC sends a System Failure error to the VLR in the MAP_CHECK_IMEI response.
25.6.2	Macro Check_IMEI_VLR
This macro is used by the VLR to control the check of a mobile equipment's IMEI. It may also be used to request the BMUEF from the EIR.
25.6.3	Process Check_IMEI_SGSN
This process is used by the SGSN to control the check of a mobile equipment's IMEI. It may also be used to request the BMUEF from the EIR.
25.6.4	Process Check_IMEI_EIR
This process is used by the EIR to obtain the status of a mobile equipment, upon request from the MSC or from the SGSN. It may also be used to obtain the BMUEF.
25.6.5	Macro Obtain_IMEI_MSC
This macro is used by the MSC to respond to a request from the VLR to provide the IMEI. 
25.6.6	Macro Obtain_IMEI_VLR
This macro is used by the VLR to obtain the IMEI from the MSC.


Figure 25.6/1 (sheet 1 of 2): Macro Check_IMEI_MSC

Figure 25.6/1 (sheet 2 of 2): Macro Check_IMEI_MSC

Figure 25.6/2: Macro Check_IMEI_VLR

Figure 25.6/3 (sheet 1 of 2): Process Check_IMEI_SGSN

Figure 25.6/3 (sheet 2 of 2): Process Check_IMEI_SGSN

Figure 25.6/4: Process Check_IMEI_EIR

Figure 25.6/5: Macro Obtain_IMEI_MSC

Figure 25.6/6: Macro Obtain_IMEI_VLR
25.7	Insert Subscriber Data macros and processes
25.7.1	Macro Insert_Subs_Data_VLR
This macro is used by any procedure in the VLR that triggers the reception of subscriber data (e.g. Update Location, Update VCSG Location or Restore Data).
25.7.2	Macro Insert_Subs_Data_SGSN
This macro is used by any procedure that triggers the reception of subscriber data (e.g. Update GPRS Location or Update VCSG Location ).
25.7.3	Process Insert_Subs_Data_Stand_Alone_HLR
This process is used by HLR to transfer subscriber data to the VLR in a stand alone mode, i.e. in a separate dialogue. This is done whenever a change of subscriber data is performed either by the operator or by the subscriber and this change has to be reported to the VLR.
Sheet 1: The HLR may wait for each MAP_INSERT_SUBSCRIBER_DATA request to be acknowledged before it sends the next request, or it may handle the requests and the confirmations in parallel.
Sheet 1, sheet 2: If the VLR has indicated that it does not support a service or feature (e.g. Closed User Group or Advice Of Charge Charging Level) which the HLR operator regards as essential for the subscriber, the macro Wait_for_Insert_Subs_Data_Cnf takes the Replace_Service exit; the HLR sets the Roaming Restriction Due To Unsupported Feature flag to roaming restricted and sends Roaming Restriction Due To Unsupported Feature in a subsequent MAP_INSERT_SUBSCRIBER_DATA request.
Sheet 1, sheet 2: If the HLR operator does not regard the unsupported service or feature as essential for the subscriber but the macro Wait_for_Insert_Subs_Data_Cnf takes the Replace_Service exit, the HLR sends the data for a replacement service in a subsequent MAP_INSERT_SUBSCRIBER_DATA request.
Sheet 2: It is an operator option whether to repeat the download of subscriber data if the VLR returns an error response. The number of repeat attempts and the interval between them is also an operator option, depending on the error response from the VLR.
If subscriber data for CAMEL Phase 2 or later services are sent to a VLR which does not support the appropriate phase of CAMEL, the service behaviour may be unpredictable or incorrect. The HLR should therefore ensure that at the conclusion of a stand alone Insert Subscriber data procedure the data in the VLR do not require a capability that the VLR does not have. Possible mechanisms to ensure this are described in 3GPP TS 23.078 [98]. 
The HLR should send a Forwarded-to number which is not in E.164 international format to the VLR only when the HLR has ascertained that the VLR supports CAMEL Phase 2 or later. Thus, the ISD message containing the Forwarded-to number which is not in E.164 international format shall be sent to the VLR only if the HLR previously received confirmation from the VLR at Location Update that CAMEL Phase 2 or later is supported.
25.7.4	Process Insert_GPRS_Subs_Data_Stand_Alone_HLR
This process is used by the HLR to transfer subscriber data from the HLR to the SGSN in a stand alone mode, i.e. in a separate dialogue. This is done whenever a change of subscriber data is performed either by the operator or by the subscriber and this change has to be reported to the SGSN.
Sheet 1: The HLR may wait for each MAP_INSERT_SUBSCRIBER_DATA request to be acknowledged before it sends the next request, or it may handle the requests and the confirmations in parallel.
Sheet 1, sheet 2: If the SGSN has indicated that it does not support a service or feature which the HLR operator regards as essential for the subscriber, the macro Wait_for_Insert_GPRS_Subs_Data_Cnf takes the Replace_Service exit; the HLR sets the Roaming Restricted In SGSN Due To Unsupported Feature flag to roaming restricted and sends Roaming Restricted In SGSN Due To Unsupported Feature in a subsequent MAP_INSERT_SUBSCRIBER_DATA request.
Sheet 1, sheet 2: If the HLR operator does not regard the unsupported service or feature as essential for the subscriber but the macro Wait_for_Insert_GPRS_Subs_Data_Cnf takes the Replace_Service exit, the HLR sends the data for a replacement service in a subsequent MAP_INSERT_SUBSCRIBER_DATA request.
Sheet 2: It is an operator option whether to repeat the download of subscriber data if the SGSN returns an error response. The number of repeat attempts and the interval between them is also an operator option, depending on the error response from the SGSN.
25.7.5	Macro Wait_for_Insert_Subs_Data_Cnf
This macro is used by any process or macro that describes the handling in the HLR of the transfer of subscriber data to the VLR (e.g. Update Location or Restore Data).
25.7.6	Macro Wait_for_Insert_GPRS_Subs_Data_Cnf
This macro is used by any process or macro that describes the handling in the HLR of the transfer of subscriber data to the SGSN (e.g. Update GPRS Location).
25.7.7	Process Send_Insert_Subs_Data_HLR
This process is used by any process or macro in the HLR where a MAP_INSERT_SUBSCRIBER_DATA request is sent to the VLR or to the SGSN.
25.7.8	Process Insert_VCSG_Subs_Data_Stand_Alone_CSS
This process is used by the CSS to transfer CSG subscriber data from the CSS to the VLR or the SGSN in a stand alone mode, i.e. in a separate dialogue. This is done whenever a change of CSG subscriber data in the CSS is performed either by the operator or by the subscriber and this change has to be reported to the VLR or the SGSN.
Sheet 1: The CSS may wait for each MAP_INSERT_SUBSCRIBER_DATA request to be acknowledged before it sends the next request, or it may handle the requests and the confirmations in parallel.
Sheet 1, sheet 2: If the VLR or the SGSN has indicated that it does not support a service or feature which the CSS operator regards as essential for the subscriber, the macro Wait_for_Insert_VCSG_Subs_Data_Cnf takes the Replace_Service exit.
Sheet 1, sheet 2: If the CSS operator does not regard the unsupported service or feature as essential for the subscriber but the macro Wait_for_Insert_VCSG_Subs_Data_Cnf takes the Replace_Service exit, the CSS sends the data for a replacement service in a subsequent MAP_INSERT_SUBSCRIBER_DATA request.
Sheet 2: It is an operator option whether to repeat the download of CSG subscriber data if the VLR or theSGSN returns an error response. The number of repeat attempts and the interval between them is also an operator option, depending on the error response from the VLR or the SGSN.
25.7.9	Macro Wait_for_Insert_VCSG_Subs_Data_Cnf
This macro is used by any process or macro that describes the handling in the CSS of the transfer of CSG subscriber data to the VLR or to the SGSN (e.g. Update VCSG Location).
25.7.10	Process Send_Insert_VCSG_Subs_Data_CSS
This process is used by any process or macro in the CSS where a MAP_INSERT_SUBSCRIBER_DATA request is sent to the VLR or to the SGSN.



Figure 25.7/1: Macro Insert_Subs_Data_VLR

Figure 25.7/2: Macro Insert_Subs_Data_SGSN

Figure 25.7/3 (sheet 1 of 2): Process Insert_Subs_Data_Stand_Alone_HLR

Figure 25.7/3 (sheet 2 of 2): Process Insert_Subs_Data_Stand_Alone_HLR

Figure 25.7/4 (sheet 1 of 2): Process Insert_GPRS_Subs_Data_Stand_Alone_HLR

Figure 25.7/4 (sheet 2 of 2): Process Insert_GPRS_Subs_Data_Stand_Alone_HLR

Figure 25.7/5: Macro Wait_for_Insert_Subs_Data_Cnf

Figure 25.7/6: Macro Wait_for_Insert_GPRS_Subs_Data_Cnf

Figure 25.7/7: Process Send_Insert_Subs_Data_HLR

Figure 25.7/8 (sheet 1 of 2): Process Insert_VCSG_Subs_Data_Stand_Alone_CSS
 
Figure 25.7/8 (sheet 2 of 2): Process Insert_VCSG_Subs_Data_Stand_Alone_CSS

Figure 25.7/9: Macro Wait_for_Insert_VCSG_Subs_Data_Cnf

Figure 25.7/10: Process Send_Insert_VCSG_Subs_Data_CSS
25.8	Request IMSI Macros
25.8.1	Macro Obtain_IMSI_MSC
This macro describes the handling of the request received from the VLR to provide the IMSI of a subscriber (e.g. at Location Updating).
25.8.2	Macro Obtain_IMSI_VLR
This macro describes the way VLR requests the MSC the IMSI of a subscriber (e.g. at Location Updating).


Figure 25.8/1: Macro Obtain_IMSI_MSC

Figure 25.8/2: Macro Obtain_IMSI_VLR
25.9	Tracing macros
25.9.1	Macro Trace_Subscriber_Activity_MSC
This macro shows the handling in the MSC for a request from the VLR to trace the activity of a subscriber.
25.9.2	Macro Trace_Subscriber_Activity_VLR
This macro is called during the handling of subscriber activity in the VLR to activate tracing if necessary.
25.9.3	Macro Trace_Subscriber_Activity_SGSN
This macro is called during the handling of subscriber activity in the SGSN to activate tracing if necessary.
25.9.4	Macro Activate_Tracing_VLR
This macro shows the handling in the VLR for a request from the HLR to activate tracing for a subscriber.
25.9.5	Macro Activate_Tracing_SGSN
This macro shows the handling in the SGSN for a request from the HLR to activate tracing for a subscriber.
25.9.6	Macro Control_Tracing_With_VLR_HLR
This macro shows the handling in the HLR to activate tracing in the VLR if it is required during a dialogue between the VLR and the HLR
25.9.7	Macro Control_Tracing_With_SGSN_HLR
This macro shows the handling in the HLR to activate tracing in the SGSN if it is required during a dialogue between the SGSN and the HLR


Figure 25.9/1: Macro Trace_Subscriber_Activity_MSC

Figure 25.9/2: Macro Trace_Subscriber_Activity_VLR

Figure 25.9/3: Macro Trace_Subscriber_Activity_SGSN

Figure 25.9/4: Macro Activate_Tracing_VLR

Figure 25.9/5: Macro Activate_Tracing_SGSN

Figure 25.9/6: Macro Control_Tracing_With_VLR_HLR

Figure 25.9/7: Macro Control_Tracing_With_SGSN_HLR
25.10	Short Message Alert procedures
25.10.1	Process Subscriber_Present_VLR 
The VLR invokes the process Subscriber_Present_VLR when the mobile subscriber becomes active. The general description of the short message alert procedures is in clause 23.4 of the present document.
25.10.2	Process SubscriberPresent_SGSN
The SGSN invokes the process Subscriber_Present_SGSN when it receives a Page response, a GPRS Attach request or a Routing area update request message (3GPP TS 24.008 [35]). The general description of the short message alert procedures is in clause 23.4 of the present document.
25.10.3	Macro Alert_Service_Centre_HLR
The HLR invokes the macro Alert_Service_Centre_HLR when Service Centre(s) are to be alerted.
25.10.4	Process Alert_SC_HLR
It is an operator option to resend the MAP_ALERT_SERVICE_CENTRE request to the SMS-IWMSC if the alert is unsuccessful. The number of repeat attempts and the interval between them is also an operator option. The service centre address should be purged from the MWD list if the alert is consistently unsuccessful.


Figure 25.10/1: Process Subscriber_Present_VLR

Figure 25.10/2: Process Subscriber_Present_SGSN

Figure 25.10/3: Macro Alert_Service_Centre_HLR

Figure 25.10/4: Process Alert_SC_HLR
Annex A (informative):
ASN.1 Cross-reference listing and fully expanded sources
The ASN.1 Cross-reference listing and the fully expanded ASN.1 sources of the MAP protocol are provided for information at http://www.3gpp.org/ftp/Specs/archive/29_series/29.002/ASN.1/
Annex B (informative):	Void
Annex C (informative):	
Message Segmentation Mechanisms
Various segmentation mechanisms are in use to overcome the problem where a MAP parameter carried in an Invoke, Result (or Error) component is too long to fit into a single SCCP UDT message. These mechanisms are:
C.1	SCCP segmentation
Instead of one UDT message several XUDT messages are used according to 
	Signalling Connection Control Part, Signalling System no. 7 ITU-T recommendation (07/96) Q.711 to Q.716 ('White Book SCCP').
This mechanism may be used for all MAP messages. If no segmentation mechanism at the TCAP or MAP level is available, this is the only remaining possibility.
This mechanism has no impact on the MAP provider level and above; the MAP provider sees the parameter as being sent in a single segment.
It should be noted that not all SCCP transit nodes (world wide) currently support the transfer of XUDT messages. Therefore XUDT messages may be lost without notice, depending on the route the message takes. The routes which successive messages take between two end points can differ because of load balancing. It is therefore recommended that this mechanism is used only for:
a)	messages which do not cross PLMN boundaries (when the PLMN operator ensures that all SCCP transit nodes within his PLMN support White Book SCCP)
b)	messages with low priority i.e. loss of the message does not result in serious misoperation.
It should be noted that the decision whether or not a message crosses PLMN boundaries needs to be taken at the MAP application level; it is therefore based on the message's operation code rather than on the SCCP called party address, i.e. only messages which never cross PLMN boundaries due to the type of message (SendIdentification, SendRoutingInfo without OR, AnyTimeInterrogation, ...) can be regarded as not crossing PLMN boundaries.
C.2	TCAP segmentation
At the TCAP level the following segmentation mechanisms are available:
C.2.1	Empty Begin
In a dialogue with AC version >1 the first forward message (Begin) must contain a Dialogue Portion. Instead of sending the Dialogue Portion and the Component Portion in the first forward message, an empty Begin (i.e. without a Component Portion) is sent, followed (after successful dialogue establishment) by a Continue message which can carry a longer Component Portion since no Dialogue Portion is present in the second forward message. 
C.2.2	Empty Continue
In a dialogue with AC version >1 the first backward message (Continue / End) must contain a Dialogue Portion. Instead of sending the Dialogue Portion and the Component Portion in the first backward message, an empty Continue (i.e. without a Component Portion) is sent, followed by a Continue/End message which can carry a longer Component Portion since no Dialogue Portion is present in the second backward message. 
C.2.3	TC-Result-NL
A Result component may be segmented into one or several Result-Not-Last components followed by a Result-Last component. As specified in clause 15.6.3, the MAP user parameter shall be split so that each segment is compatible with the type defined for the parameter of the result of the associated operation.
Note that this segmentation mechanism runs the risk that the message carrying the Result-Last component arrives before the message carrying a Result-Not-Last component which results in failure. The use of SCCP class 1 "Sequence guaranteed", which raises the chance of in sequence delivery, is recommended.
C.3	MAP Segmentation
At the MAP level the following segmentation mechanisms are available:
C.3.1	Invoke without explicit indication
An Invoke component may be segmented into several Invoke components. These may be sent in burst mode (in which case SCCP class 1 is recommended) or in acknowledged mode. The receiving node does not get an indication of whether or not more segments will be received, so it must not close the dialogue. The MAP user parameter shall be split so that each segment is compatible with the type defined for the parameter of the invoke of the associated operation.
C.3.2	Invoke with explicit indication
An Invoke component may be segmented into several Invoke components sent in acknowledged mode. Each component contains at the MAP level an indication of whether or not subsequent components will follow. The receiving node terminates the dialogue when the last component is received. The MAP user parameter shall be split so that each segment is compatible with the type defined for the parameter of the invoke of the associated operation.
C.3.3	Result
A Result (last) component may be segmented into several Result (last) components sent in acknowledged mode where a new (empty) Invoke component serves as an acknowledgment. The last segment is not acknowledged. The MAP user parameter shall be split so that each segment is compatible with the type defined for the parameter of the result of the associated operation.
The following tables show the applicability of the mechanisms described above:
AC Version 4:
Parameter
SCCP-segmentation
Empty Begin
Empty Continue
TC-Result-NL
Invoke without indication
Invoke with indication
Result
ResumeCallHandlingArg
allowed
not allowed
n.a.
n.a.
not allowed
recommended
n.a.

AC Version 3:
Parameter
SCCP-segmentation
Empty Begin
Empty Continue
TC-Result-NL
Invoke without indication
Invoke with indication
Result
InsertSubscriberDataArg
risky
not allowed
n.a.
n.a.
recommended
n.a.
n.a.
SendIdentificationRes
allowed
n.a.
not allowed
not allowed
n.a.
n.a.
recommended
PrepareHO-Arg
allowed
not allowed
n.a.
n.a.
not allowed
n.a.
n.a.
PrepareHO-Res
allowed
n.a.
recommended
not recommended
n.a.
n.a.
not allowed
ProcessAccessSignalling-Arg
allowed
n.a.
n.a.
n.a.
not allowed
n.a.
n.a.
ForwardAccessSignalling-Arg
allowed
n.a.
n.a.
n.a.
not allowed
n.a.
n.a.
PrepareSubsequentHO-Arg
allowed
n.a.
n.a.
n.a.
not allowed
n.a.
n.a.
PrepareSubsequentHO-Res
allowed
n.a.
n.a
not recommended
n.a.
n.a.
not allowed
SendAuthenticationInfoRes
risky
n.a.
not allowed
not allowed
n.a.
n.a.
recommended
ProvideSubscriberInfoRes
allowed
n.a.
not allowed
not recommended
n.a.
n.a.
not allowed
AnyTimeInterrogationRes
allowed
n.a.
not allowed
not recommended
n.a.
n.a.
not allowed
AnyTimeModificationRes
allowed
n.a.
not allowed
recommended
n.a.
n.a.
not allowed
AnyTimeSubscriptionInterrogationRes
allowed
n.a.
not allowed
recommended
n.a.
n.a.
not allowed
noteSubscriberDataModifiedArg
allowed
not allowed
n.a.
n.a.
not allowed
recommended
n.a.
SendRoutingInfoRes
allowed
n.a.
not allowed
recommended
n.a.
n.a.
not allowed
MO-ForwardSM-Arg
risky
recommended
n.a.
n.a.
not allowed
n.a.
n.a.
MT-ForwardSM-Arg
risky
recommended
n.a.
n.a.
not allowed
n.a.
n.a.

AC Version 2:
Parameter
SCCP-segmentation
Empty Begin
Empty Continue
TC-Result-NL
Invoke without indication
Invoke with indication
Result
InsertSubscriberDataArg
risky
not allowed
not allowed
n.a.
recommended
n.a.
n.a.
SendIdentificationRes
allowed
n.a.
not allowed
not recommended
n.a.
n.a.
not allowed
SendAuthenticationInfoRes
risky
n.a.
not allowed
not recommended
n.a.
n.a.
not allowed
ForwardSM-Arg
risky
recommended
n.a.
n.a.
not allowed
n.a.
n.a.
PrepareHO-Res
allowed
n.a.
recommended
not recommended
n.a.
n.a.
not allowed

AC Version 1:
Parameter
SCCP-segmentation
Empty Begin
Empty Continue
TC-Result-NL
Invoke without indication
Invoke with indication
Result
InsertSubscriberDataArg
risky
n.a.
n.a.
n.a.
recommended
n.a.
n.a.
SentParameterList
risky
n.a.
n.a.
recommended
n.a.
n.a.
not allowed

In the tables above the keywords "recommended", "allowed", "risky", "not recommended", "not allowed" and "n.a." are used as follows:
"recommended"
indicates that the normative part of this specification explicitly specifies the use of this mechanism for the parameter in question;
"allowed"
indicates that the normative part of this specification allows the use of this mechanism for the sending node and mandates support of this mechanism for the receiving node;
"risky"
indicates that the mechanism is "allowed".However, the use of this mechanism for the parameter in question may result in serious misoperation because SCCP transit nodes are not guaranteed to support XUDT messages.
"not recommended"
indicates that the normative part of this specification does not explicitly specify the use of this mechanism for the parameter in question.
"not allowed"
indicates that the normative part of this specification implicitly prohibits the use of this mechanism for the parameter in question.
"n.a."
indicates that the mechanism is not applicable for the parameter in question.

Annex D (informative):	Void
Annex E (informative):
Change History

Date
TSG #
TSG Doc.
CR
Rev
Subject/Comment
New

04
N2-99227
A002
3
Use of E interface
3.1.0

04
N2-99578
A003

Introduction of TIF-CSI for Call Deflection
3.1.0

04
N2-99233
A004

Clarification in ASN.1 encoding of O-CSI and T-CSI
3.1.0

04
N2-99269
A005

Introduction of MSISDN in USSD operation
3.1.0

04
N2-99650
A006

Modification of the O-CSI ASN.1 structure
3.1.0

04
N2-99250
A007

Adding of MAP_DELIMITER_req to the Status report operation
3.1.0

04
N2-99628
A008

Correction to the Purge MS "Detailed procedure in the HLR"
3.1.0

04
N2-99677
A009

Adding of MNP-indicator to the SRI ack
3.1.0

04
N2-99228
A010

New subscription options for call forwarding
3.1.0

04
N2-99585
A011

Adding the support of ANSI SCCP which is required in North America (World Zone 1)
3.1.0

04
N2-99515
A012

Introduction of 3-digit MNCs correction
3.1.0

04
N2-99520
A013

Export of NAEA-CIC
3.1.0

04
N2-99548
A014

Clarification to text to identify how the LSA data relevant in the current VPLMN can be determined
3.1.0

04
3C99-468
A015

Alignment with 04.80
3.1.0

04
N2-99519
A016

VBS data
3.1.0

04
N2-99461
A017

Introduction of Data Missing error to the Resume Call Handling
3.1.0

04
N2-99583
A018

Removal of 3-digit MNCs
3.1.0

04
N2-99676
A019

Corrections of mapping from MAP service to TC service
3.1.0

04
3C99-206
A020

Introduction of UUS service to Resume Call Handling
3.1.0

05
N2-99906
021

Clarification on VLR CAMEL Subscription Info
3.2.0

05
N2-99908
022

Clarification on DestinationNumberCriteria
3.2.0

05
N2-99910
023

Removal of TDP-Criteria from RCH
3.2.0

05
N2-99934
025

Various corrections related to GGSN-HLR Interface.
3.2.0

05
N2-99936
034

Update Location handling for GPRS-only subscription
3.2.0

05
N2-99938
035

Correction of OP & AC definitions for NoteMS-PresentForGPRS
3.2.0

05
N2-99952
036

Removal of redundant information from RCH
3.2.0

05
N2-99956
026

OR capability IE in PRN
3.2.0

05
N2-99964
024
1
GMSC-CAMEL phase 2 support IE in PRN
3.2.0

05
N2-99A19
028

Alignment of 29.002 with 02.67
3.2.0

05
N2-99A45
029
1
Non-CAMEL IST implementation
3.2.0

05
N2-99B57
027
2
Addition of the information elements and the ASN.1 definitions for Pre-paging
3.2.0

05
N2-99C27
042

Clarification on 'Supported CAMEL Phases' in ISD ack
3.2.0

05
N2-99C78
044

Editing error correction on VLR capabilities
3.2.0

05
N2-99D06
043
1
Addition of exception handling to the CancellationType
3.2.0

05
N2-99D33
046

Clarification of LR-REJECT cause corresponding to RoamingRestrictionDueTo UnsupportedFeature
3.2.0

05
N2-99D35
047

Clarification of returning the MSISDN in SRIack
3.2.0

06
N2-99G06
033
3
Introduction of the Super-Charger Concept in TS 29.002
3.3.0

06
N2-99G18
032
2
Introduction of White Book SCCP in MAP
3.3.0

06
N2-99G50
070

Addition of GGSN number for the SRIforGPRS
3.3.0

06
N2-99J88
075
1
Introduction of Follow Me
3.3.0

06
N2-99K12
077

Use of SSN for GPRS
3.3.0

06
N2-99K24
069

Correction of the USSD procedure in the HLR.
3.3.0

06
N2-99K52
060
1
MAP Impacts for Location Services (LCS)
3.3.0

06
N2-99K58
045
4
Authentication Enhancements
3.3.0

06
N2-99K60
050
5
QoS-Subscribed field modification
3.3.0

06
N2-99L20
073
1
Introduction of CAMEL Phase 3 in 3GPP TS 29.002
3.3.0

06
N2-99J52
074

Restructuring of MAP Location Management Procedures for the Circuit Switched Domain
3.3.0

06
N2-99J92
068

Update of SDLs to support Super-Charger
3.3.0





New version created to fix a CR implementation error
3.3.1

07
N2B000436
048
5
Introduction of Multicall
3.4.0

07
N2B000319
059
1
Alternative solution for ALR
3.4.0

07
N2B000461
063
4
MNP Database Mismatch
3.4.0

07
N2B000375
066
5
Addition of the FTN-AddressString
3.4.0

07
N2B000456
079
4
Correction of SS Invocation Notification for CCBS
3.4.0

07
N2A000023
080

Corrections to ATSI, ATM, NCSD
3.4.0

07
N2B000046
083

Privacy notification/verification for call related privacy class
3.4.0

07
N2B000142
084
2
Addition of CS Allocation/retention priority
3.4.0

07
N2B000144
086
1
Editorial cleanup of 29.002
3.4.0

07
N2B000100
087

Correction of LSA information
3.4.0

07
N2B000067
089

Security interworking between release 99 and pre-99 MSC/VLRs
3.4.0

07
N2B000113
090
1
Improving GPRS charging efficiency
3.4.0

07
N2B000120
094
2
QoS-Subscribed field enhancements
3.4.0

07
N2B000322
095
1
RANAP support on the E-interface
3.4.0

07
N2B000191
099

UMTS Authentication
3.4.0

07
N2B000466
100
5
Support of 3G Handover, including Multicall
3.4.0

07
N2B000372
101
1
Introduction of Service Area Identification
3.4.0

07
N2B000380
102
2
Clarification on Authentication Info Retrieval
3.4.0

07
N2B000330
103
1
Addition of UMTS security to MAP B interface
3.4.0

07
N2B000244
104

Re-Synchronisation Info
3.4.0

07
N2B000324
105
1
Introduction of additional service parameters for inter-system handover
3.4.0

07
N2B000281
107

Removal of architectural information from clause 4
3.4.0

07
N2-000454
110
1
Introduction of Authentication Failure Report
3.4.0

07
N2B000357
111

Use of MAP private extensions to implement region-specific requirements
3.4.0

07
N2B000470
112

Prioritisation of MAP application context related to VGCS/VBS
3.4.0

07
N2B000472
113

Correction of SS-Codes for LCS
3.4.0

08
N4-000098
115
1
Minor corrections to CAMEL3 NSDC/ATM/ATSI information flows
3.5.0

08
N4-000094
117
1
Using DSD to delete CCBS-B from the subscriber
3.5.0

08
N4-000089
118
1
Indication in PRN of support of Long FTNs
3.5.0

08
N4-000073
120
1
QoS-Subscribed field enhancements
3.5.0

08
N4-000050
121

Correction of introduction of additional service parameters for inter-system handover
3.5.0

08
N4-000100
122
2
Proposed information flow on NSDC
3.5.0

08
N4-000321
124
3
CAMEL Subscription Info
3.5.0

08
N4-000068
125

Clarification to GMLC List definition
3.5.0

08
N4-000320
127
1
Optionality of parameters in d-csi and in sms-csi
3.5.0

08
N4-000209
130

Version 3 tags for handover messages
3.5.0

08
N4-000211
132

Correction of version handling at dialogue establishment
3.5.0

08
N4-000357
133
1
Various corrections and/or cleanup to 29.002
3.5.0

08
N4-000217
134

Correction of errors in Figure 25.1/1: Macro Receive_Open_Ind
3.5.0

08
N4-000326
135
1
Addition of charging characteristics per PDP context
3.5.0

08
N4-000264
138

Clarification of SAI-ack segmentation procedure
3.5.0

08
N4-000392
139
1
Indication of unsupported position method
3.5.0

08
N4-000276
141

Clarification for ReportSM-DeliveryStatus operation
3.5.0

08
N4-000349
142
1
Addition of a parameter in the subsequent Handover from UMTS to GSM with Multicall
3.5.0

08
N4-000278
143

Editorial correction to MSC-A handover SDLs
3.5.0

08
N4-000378
144
1
Use of NAM parameter with MAP-INSERT-SUBSCRIBER-DATA service between HLR and SGSN
3.5.0

08
N4-000293
145

Addition of state attributes in Forward group call signalling
3.5.0

08
N4-000294
146

New user error 'target cell outside group call area' in MAP Prepare Handover message
3.5.0

08
N4-000374
149

Correction to the description of MAP-MO-Forward-Short-Message service
3.5.0

08
N4-000407
148
4
Changes to MAP for secure transport of MAP messages
4.0.0

08



Version 4.0.1 created to allow inclusion of automatic update of Annexes A and B and of clause 17
4.0.1

09
N4-000543
152
1
Clarifications for secure MAP transport
4.1.0

09
N4-000539
153
1
Generalization of version handling text in clause 18.2.4
4.1.0

09
N4-000491
158

Deletion of informative Annexe C
4.1.0

09
N4-000540
159

Aligning 29.002 with 25.413 (UTRAN Iu Interface RANAP Signalling)
4.1.0

09
N4-000541
160

AUTS and AUTN parameter length
4.1.0

09
N4-000744
161
2
Clarification on Authentication Failure Report ack
4.1.0

09
N4-000666
163
1
Correction on Location Information
4.1.0

09
N4-000777
174
2
Optionality of parameters in GPRS-CSI
4.1.0

09
N4-000788
176
1
Correction to QoS indication
4.1.0

09
N4-000747
178
1
Clarification of use of Radio Resource Information
4.1.0

09
N4-000750
180
2
Correction to MSC-A handover SDLs
4.1.0

09
N4-000736
182

Removal of LSAIdentity from NoteMM-EventArg
4.1.0

09
N4-000772
184

LCS Support for CAMEL Phase 3
4.1.0

09
N4-000751
186
1
Correction to MSC-A handover SDLs
4.1.0

09
N4-000779
188

Clarification for segmentation of D-CSI and SMS-CSI
4.1.0

10
N4-000912
166
3
Corrections and clarifications for USSD procedures on the HLR - gsmSCF interface
4.2.0

10
N4-000908
191
1
Corrections of ISD data structure for CAMEL phase 3
4.2.0

10
N4-001069
193
2
USSD Corrections for Follow Me
4.2.0

10
N4-001071
196
1
GSM to 3G Handover: MAP parameter Target Cell ID
4.2.0

10
N4-000921
198

ASN.1 description of targetCellId
4.2.0

10
N4-001073
200
1
IMSI in MAP_PREPARE_HANDOVER
4.2.0

10
N4-001076
208
1
Alignment of the Target RNC-ID
4.2.0

10
N4-001089
211
1
Export of GSN-Address data type
4.2.0

10
N4-001095
212

Transport of long RANAP messages on MAP-E interface
4.2.0

-
-
-
-
Automatic update of annexes A and B
4.2.1

11
N4-010036
206
1
Correction to LCS application context
4.3.0

11
N4-010276
215
2
Add parameters to ISD and SRI for GPRS to handle ODB for PS
4.3.0

11
N4-010033
217

Correction to maximum number of RAB's
4.3.0

11
N4-010198
222
2
PS domain support for LCS Release 4
4.3.0

11
N4-010058
224

Failure of Update GPRS Location when HLR is not reachable
4.3.0

11
N4-010287
231
1
Extension of call related privacy class for LCS Release 4
4.3.0

11
N4-010375
232
2
Maximum number of LCS Clients
4.3.0

11
N4-010261
234

MAP over IP according to SIGTRAN
4.3.0

11
N4-010465
236
1
Requesting node type in authentication set request
4.3.0

11
N4-010360
246

Adding EXPORT definition for LSAIdentity
4.3.0

11
N4-010361
247

Removing duplicate parameters from ss-CSI
4.3.0

11
N4-010362
248

Correction to description of SS-CSI in HLR to VLR information flow
4.3.0

11
N4-010365
250

GSM to UMTS handover: addition of MAP parameter RNC ID
4.3.0

11
N4-010393
252

Clarification of the use of multicall bearer information
4.3.0

11
N4-010428
258

Adding EXPORT definition for GeographicalInformation
4.3.0

11
N4-010446
260

Failure of Authentication Parameter GPRS when HLR is not reachable
4.3.0

11
N4-010484
262
1
Correction to D-CSI
4.3.0

12
N4-010728
239
4
Addition of selected UMTS algorithm indication to the handover procedures
4.4.0

12
N4-010730
241
4
Addition of allowed GSM algorithms indication to the handover procedures
4.4.0

12
N4-010733
244
4
Addition of allowed UMTS algorithm indication to the handover procedures
4.4.0

12
N4-010735
245
4
Addition of selected GSM algorithm indication to the handover procedures
4.4.0

12
N4-010739
254
2
Addition of radio resource list to the handover procedures
4.4.0

12
NP-010247
256
3
Addition of GSM channel type and GSM chosen channel indications to handover procedures
4.4.0

12
N4-010787
264
3
Add support in MAP for all shapes defined in 23.032
4.4.0

12
N4-010633
270
1
Correction to description of RNCId parameter
4.4.0

12
N4-010635
272
1
Correction to Encryption Information and Integrity Protection parameters
4.4.0

12
N4-010767
279
3
Essential drawbacks on services due to introduction of Super-Charger function
4.4.0

12
N4-010741
283
1
Introduction of selected Rab-id to the Process Access Signalling operation
4.4.0

12
N4-010673
285

Mistake in the definition of Authentication Failure Report Application Context
4.4.0

12
N4-010551
266

Add support in MAP for Ellipsoid Point
4.4.0

12
N4-010778
168
5
Security Header modification
4.4.0

12
N4-010785
267
3
Additional Parameters in Authentication Failure Report
4.4.0

12
N4-010783
268
3
MS presence notification procedure for LCS
4.4.0

12
N4-010790
289
2
Component level granularity of protection
4.4.0





Corrupted headers fixed
4.4.1

13
N4-010840
290

Clarifications on long forwarded-to numbers
4.5.0

13
N4-010929
291
1
Corrections for Deferred MT-LR
4.5.0

13
N4-010930
292
2
Clarifications on SupportedLCS-CapabilitySets
4.5.0

13
N4-010958
295
2
Corrections on the introduction of LCS for PS domain
4.5.0

13
N4-010970
302
2
Additional SGSN related values to Access Type
4.5.0

13
N4-010976
306

Addition of data type definitions to EXPORT statements for the usage in CAP
4.5.0

13
N4-011017
307
2
Minimum MAP application context for intersystem MSC handover from GSM to UMTS
4.5.0

13
N4-011019
309
2
Minimum MAP application context for intersystem MSC handover from UMTS to GSM
4.5.0

13
N4-010845
277
1
Correction on the SDL of NW initiated USSD operations
4.5.0

13



Editorial Clean up
4.5.0

14
N4-011031
313

Clarification on LCS parameters in MAP
4.6.0

14
N4-011043
314

Handling of linked operations in the MAP protocol machine
4.6.0

14
N4-011285
316

Corrections on the SDL diagrams for LCS
4.6.0

14
N4-011198
318
1
Indication of deletion of CSI in Notify Subscriber Data Change
4.6.0

14
N4-011074
320

Correct length of Add-GeographicalInformation
4.6.0

14
N4-011091
322

Clarify encoding of RNC Id
4.6.0

14
N4-011094
324

Clarify encoding of RANAP parameters in MAP
4.6.0

14
N4-011097
325

Clarifications on long forwarded-to numbers
4.6.0

14
N4-011227
331
1
Clarification of methodology for maintaining data consistency in Supercharger
4.6.0

14
N4-011173
334

Addition of RAB ID to Prepare Handover procedure
4.6.0

14
N4-011175
336

Correction to the Allowed GSM Algorithms parameter
4.6.0

14
N4-011177
337
1
Correction of references
4.6.0

14
N4-011190
339

CUG-Info is not exported from 29.002
4.6.0

14
N4-011209
341

Clarification on NSCD when data is withdrawn
4.6.0

14
N4-011211
343

Clarification of sending CAMEL information in stand alone ISD case
4.6.0

14
N4-011262
344

Correction of the priority for "SRI for LCS"
4.6.0

14
N4-011273
347

ASN.1 correction
4.6.0

14
N4-011437
349
2
Handling of MNRR in the HLR & SMS-GMSC
4.6.0

14
N4-011433
354
1
Minimum MAP application context for G2G inter-MSC handover
4.6.0

14
N4-011439
359
2
Alignment of parameter lengths with those prescribed in 08.08
4.6.0

14
N4-011423
360
1
Aligning the security header elements with TS33.200
4.6.0

14
N4-011394
364

Syntax error in the ATM result and ATSI result
4.6.0

14
N4-011381
355
1
LCS Capability Handling for UE's
5.0.0

15
N4-020300
368
4
Collective CAMEL Phase 4 CR
5.1.0

15
N4-020013
373

Inclusion of complete ODB data in ATSI and NSDC
5.1.0

15
N4-020266
381
2
Introduction of the "Requestor ID"
5.1.0

15
N4-020068
386

Correction to AC version of gprsLocationInfoRetrievalContext
5.1.0

15
N4-020248
390
1
Incomplete description of Restore Data parameters
5.1.0

15
N4-020183
403

Clarification on CODEC-Info
5.1.0

15
N4-020250
407
1
ODB alignment
5.1.0

16
N4-020530
428
2
LCS: error handling if shape not supported by GMLC
5.2.0

16
N4-020622
453

Addition of Radio Resource List to the Forward Access Signalling operation
5.2.0

16
N4-020641
460

Clarification on Resume Call Handling
5.2.0

16
N4-020746
440
2
Clarification on SendAuthenticationInfo
5.2.0

16
N4-020750
446
1
Addition of Service Handover parameters to MAP Handover messages
5.2.0

16
N4-020318
398

Check of NAM and Requesting Node Type on receipt of SendAuthenticationInfo
5.2.0

16
N4-020333
410

Handling the MNRR flag in the HLR & SMS-GMSC
5.2.0

16
N4-020499
420
1
Clarfication of introducing Session related and unrelated class
5.2.0

16
N4-020511
430
1
Corrections on the introduction of LCS for PS domain
5.2.0

16
N4-020743
448
1
Corrections in SS-code chapter
5.2.0

16
N4-020408
423

Clarification of handling of MT-SMS-TPDU-Type and SMS-TDP
5.2.0

16
N4-020410
425

Clarify conditions to trigger restart of MTLR-Deferred procedure
5.2.0

16
N4-020468
414
1
Corrections to the handling of Any Time Interrogation and Provide Subscriber Info
5.2.0

16
N4-020476
435
1
Change PS-connected in PS-PDPactive
5.2.0

16
N4-020483
422
1
Triggering of gsmSCF for MT-SMS-CSI
5.2.0

16
N4-020485
408
2
Transferring the MS classmark & IMEI to the gsmSCF
5.2.0

16
N4-020543
441

Correction of Object Identifiers for ASN.1 modules
5.2.0

16
N4-020608
450

Enhancement to LCS in the PS domain
5.2.0

16
N4-020623
454

Addition of Location Information GPRS to Note MM Event operation
5.2.0

16
N4-020703
421
4
LCS: Codeword and Service Type
5.2.0

16
N4-020756
436
2
Splitting of CAMEL phase 4
5.2.0

17
N4-021001
437
3
Compatible upgrade to ASN.1:1997 of 29.002
5.3.0

17
NP-020399
462
2
Introduction of GERAN classmark
5.3.0

17
N4-020841
465

Clarification on Call Deflection
5.3.0

17
N4-021040
470
1
Correction to the usage of "Roaming not allowed" error
5.3.0

17
N4-021041
471
1
Clarifications on Send Identification
5.3.0

17
N4-021094
479
2
Handling of partial implementations of CAMEL phase 4
5.3.0

17
N4-021047
480

Removal of ChargingNotification feature
5.3.0

17
N4-020810
481

CR29.002-443 (rel5) on extensions to ATM for CAMEL control of IMS
5.3.0

17
N4-020809
482

CR to 29.002 for the support of the MAP Si interface
5.3.0

18
N4-021290
499

Correction to segmentation of O-CSI and T-CSI
5.4.0

18
N4-021418
508

ODB correction
5.4.0

18
N4-021563
511
1
Addtion of reference number to deferred location request procedure
5.4.0

18
N4-021573
516
2
Correction to the Service Handover parameters
5.4.0

18
N4-021299
442
3
Description of MT SM delivery via two serving nodes
5.4.0

18
N4-021294
474
2
Correction of handling of MT-SMS in the SGSN
5.4.0

18
N4-021124
475

ODB and CB for SMS
5.4.0

18
N4-021153
486

Correction of IMEI check for SGSN
5.4.0

18
N4-021467
489
5
Available codecs list and selected codec indication
5.4.0

18
N4-021194
490

Clarification of the use of Requested CAMEL Subscription Info parameters
5.4.0

18
N4-021252
495

Correction to RCH – adding O-CSI trigger criteria
5.4.0

18
N4-021264
496

Additional MM-Code for MG-CSI
5.4.0

18
N4-021296
497
1
Additional handling of partial implementations of CAMEL phase 4
5.4.0

18
N4-021383
512

Correcion of Codeword Handling
5.4.0

18
N4-021443
513

Reference to TS 23.078 in TS 29.002 regarding handling of VMSC address is missing
5.4.0

18
N4-021524
521
1
Editorial clean‑up
5.4.0

18
N4-021531
522

Introduction of the CHOICE element "netDetNotReachable" for PS-SubscriberState
5.4.0

18
N4-021260
491
1
Addition of LCS Format Indicator to LCS Client ID
6.0.0

18
N4-021504
517
2
Addition of V-GMLC Address to the Update Location and Update GPRS Location requests
6.0.0

18
N4-021567
518
3
Addition of V-GMLC and H-GMLC Addresses to the Send Routing Info for LCS response
6.0.0

18-
N4-021506
519
2
Addition of PPR Address to the Send Routing Info for LCS response
6.0.0

19
N4-030234
509
3
Introduction of Call Barring for SMS in PS domain
6.1.0

19
N4-030325
524
3
Clean-up of SMS procedures chapter
6.1.0

19
NP-030068
545
2
Correction to interactions between CAMEL control of MO SMS and barring
6.1.0

19
N4-030061
526

Incrementing ASN.1 module versions
6.1.0

19
N4-030063
528

LCS diagnostic alignment
6.1.0

19
N4-030054
529

Addition of LCS Capability Set 4
6.1.0

19
N4-030301
533
1
Correction to the definitions of Radio Resource List and BSSMAP Service Handover List
6.1.0

19
N4-030305
541
2
Handover of Group Calls where MSC-B has bearer established
6.1.0

19
N4-030287
551
1
Change of SS-Code List description for Insert Subscriber Data
6.1.0

19
N4-030289
559
1
Missing of "Continue Monitoring message" in SDL 21.7_3.2
6.1.0

19
N4-030297
563
1
Alignment of TS 29.002 with TS 23.107 regarding QoS subscribed data
6.1.0

19
N4-030222
566
1
Introduction of MSC Number as a new parameter in MAP-SEND-IDENTIFICATION operation
6.1.0

20
N4-030692
536
2
Additional SGSN Related Access Type – Detach
6.2.0

20
N4-030658
568
4
Addition of Positioning Data IE to Provide Subscriber Location and Send Location Report
6.2.0

20
N4-030638
574
1
Provision of SDL diagrams and removal of redundant text in chapter 25
6.2.0

20
N4-030713
595
2
Removal of redundant text from 29.002 Chapter 23
6.2.0

20
N4-030439
599

LCS Client external ID
6.2.0

20
N4-030682
607
1
Provision of SDL diagrams and removal of redundant text in chapter 22
6.2.0

20
N4-030608
608
1
Addition of LCS capability sets to MAP_SRI_for_LCS response
6.2.0

20
N4-030647
612
1
Enhancement of the CheckIMEI operation to retrieve the BMUEF
6.2.0

20
N4-030678
619
1
Correction to naming of PRN parameter
6.2.0

20
N4-030609
624
1
Addition of Privacy Check Related Action to Provide Subscriber Location request
6.2.0

20
N4-030642
610
1
Transfer of UE-specific behaviour bitmap at handover
6.2.0

20
N4-030601
633

Missing SMSs over MSC even if the MS is capable of such sending
6.2.0

21
N4-031043
584
2
Correction to MAP Process Secure_MAP_DSM SDLs 
6.3.0

21
N4-031053
664
1
Correction of encoding description of Group-Id
6.3.0

21
N4-030828
657

Reduce maximum length of  "LCS Requestor ID" and "LCS Codeword".
6.3.0

21
N4-030922
647
1
UESBI -IU format
6.3.0

21
N4-031069
616
3
Incorrect Charging with MNP
6.3.0

21
N4-031057
660
2
Notification of the 2nd BSG in case of Late CF with OR
6.3.0

21
N4-031059
614
3
HLR Interrogation for SCUDIF calls
6.3.0

21
N4-030785
644

Removal of tables in clause 7.6
6.3.0

21
N4-030806
649

Correction of References
6.3.0

21
N4-030815
648

Correction of wrong AC name in the table in 17.1.6
6.3.0

21
N4-030824
654

New LCS Service Types
6.3.0

21
N4-030951
671

SS-Barring Category
6.3.0

21
N4-031006
650
1
Add SGSN, GGSN, GMLC, gsmSCF, NPLR and AuC to network resource parameter
6.3.0

21
N4-0301038
645
1
Introduction of North American Interim Location Based Routing of Emergency Call
6.3.0

21
N4-031065
674

Positioning Data for UTRAN LCS
6.3.0

21
N4-030953
637
1
Provision of SDL diagrams and removal of redundant text in chapter 19
6.3.0

21
N4-030745
639

Provision of SDL diagrams and removal of redundant text in chapter 20
6.3.0

21
N4-030747
641

Provision of SDL diagrams and removal of redundant text in chapter 21
6.3.0

21
N4-030748
642

Removal of SIWF description
6.3.0

21
N4-030749
643

Deletion of redundant Annex D
6.3.0

22
N4-031098
677

Enhancements for the Partial Implementation for "Change of position procedure armed with criteria"
6.4.0

22
N4-031135
687

Collective CR for Rel-6 Enhanced Dialled Services
6.4.0

22
N4-031274
648
2
Message Segmentation Mechanisms
6.4.0

22
N4-031315
703

Addition of requestingPLMN-ID to Send Authentication Info Request
6.4.0

22
N4-031372
680
2
Addition of CGI to LCS procedures
6.4.0

22
N4-031373
696
2
Include v-gmlc parameter in RESTORE DATA MAP message
6.4.0

22
N4-031365
702
2
Deferred MT-LR Area Event
6.4.0

22
N4-031132
686

More spare bits for CAMEL4 enhancements
6.4.0

22
N4-031163
692

Clarification on D-CSI segmentation
6.4.0

22
N4-031342
676
2
MNP correction for prepaid charging
6.4.0

22
N4-031338
695
1
Remove reduntant option for retrieval of routeing information in figure 21.2.3
6.4.0

22
N4-031108
679

Modification of description for conditions on inclusion of Positioning Data
6.4.0

22
N4-031317
689
2
HSDPA impacts to MAP
6.4.0

22
NP-030533
704

EXPORT data types to CAP (Change of position armed with criteria)
6.4.0

23
N4-040310
668
3
Codec Modification/ Mid-Call Codec Negotiation after Inter-MSC Relocation
6.5.0

23
N4-040193
670
2
Correction of Inter-MSC SRSN Relocation procedure
6.5.0

23
N4-040249
701
3
Introduction of Presence Stage 3 (Ph, Pc and Pg) to the MAP interface
6.5.0

23
N4-040333
708
2
Correction to Insert Subscriber Data message for LCS SS
6.5.0

23
N4-040328
709
1
SCCP segmentation for Inter PLMN MAP message
6.5.0

23
N4-040327
711
2
Inclusion of UTRAN Positioning Data parameter
6.5.0

23
N4-040284
717
1
Include administrative restriction subscription parameter
6.5.0

23
N4-040340
720
2
Add new Unavailability cause for SCUDIF
6.5.0

23
N4-040171
721

CR implemented by fault
6.5.0

23
N4-040182
724

Removal of R-GMLC Address
6.5.0

23
N4-040322
725
1
MO-LR Service Identity support
6.5.0

23
N4-040267
726
1
CAMEL4 SCUDIF notification during active call for prepay
6.5.0

24
N4-040520
731

Introduction of North American Interim Location Based Routing of Emergency Call
6.6.0

24
N4-040585
735

Modify IMEI parameter usage definition in MAP-PSL and MAP-SLR
6.6.0

24
N4-040600
736

Addition of SAI-Present indication to the LCS procedures
6.6.0

24
N4-040601
737

Clarification on the use of MSISDN parameter for Follow Me functionality
6.6.0

24
N4-04732
734
1
Add Additional V-GMLC parameter in MAP-SRI-INFO-FOR-LCS
6.6.0

24
N4-040736
718
6
Addition of IMEISV to Update Location Procedure for ADD function
6.6.0

25
N4-040929
739

Export of UU-Data data type
6.7.0

25
N4-041021
743

Wrong SDL flow page implemented
6.7.0

25
N4-041128
732
2
Pre-Paging Resource Optimization
6.7.0

26
N4-041272
747

Incorrect Implementation of CR 731
6.8.0

26
N4-041477
752

Correction to the service response parameters of ATI
6.8.0

26
N4-041662
746
1
Introducing VGCS/VBS ciphering
6.8.0

26
N4-041683
757
2
Clarification about returning authentication data for a subscriber (GSM or UMTS)
6.8.0

26
N4-041684
748
1
LCS Capability Handling for UE's
6.8.0

26
N4-041685
753
1
Enable NA-ESRD Provision from a GMLC for E911 Location in North America
6.8.0

26
N4-041641
740
2
SMS Fraud countermeasures
6.8.0

27
N4-050212
749
1
Management Based Activation Impacts
6.9.0

27
N4-050369
761
1
Addition of LAI to SendIdentification Request
6.9.0

27
N4-050430
760
1
Subscribed Charging Characteristics
6.9.0

27
N4-050444
759
1
Addition of TCAP-Handshake for MO-ForwardSM
6.9.0

27
N4-050446
745
2
Introduction of Hop Counter for Send Identification
6.9.0

27
N4-050463
738
8
Rel-6 trace management additions to trace activation and deactivation procedures
6.9.0

27
N4-050467
763
2
Pseudonym indicator support in MO-LR
6.9.0

28
C4-050737
769
1
Correction to Trace parameters to allow trace at the BM-SC
6.10.0

28
C4-050832
770
6
Full RANAP support of network initiated SCUDIF
6.10.0

28
C4-050895
766
2
Clarification on the use of Access Restriction Data parameter
6.10.0

28
C4-050784
765
1
Addition of CollectInformation procedure to OfferedCAMEL4Functionalities
7.0.0

29
C4-051013
771

ASN.1 module version update
7.1.0

29
C4-051295
776
2
Enabling the Providing of Velocity
7.1.0

29
C4-051333
772
1
Support of talker priorities and talker identity presentation
7.1.0

29
C4-051334
773
1
Delivery of SMS to voice group call
7.1.0

29
C4-051368
777
2
CS data Mobile Terminating calls from PSTN
7.1.0

29
C4-051336
780
2
Correction on misalignment with stage 2 for Location Services
7.1.0

30
C4-051775
783
2
Addition of UMTS Trace parameters to handover procedure
7.2.0

31
C4-060320
794
1
Addition of UMTS Trace parameters to handover procedure
7.3.0

31
C4-060295
790
1
Removal of MAPsec material
7.3.0

31
C4-060315
787
1
addition of "supported RAT types indicator" during location/routing area update
7.3.0

31
C4-060378
792
1
Addition of Periodic Location Feature Support
7.3.0

31
C4-060434
781
3
New LocationType for the notification based on current location of target UE
7.3.0

31
C4-060318
788
1
SMS Relay Application Context Names for Version 1
7.3.0

31
C4-060041
789

Precision on segmentation of MAP GPRSSubscriptionData parameter
7.3.0

31
C4-060250
801

Improvements to VGCS Call Establishment
7.3.0

31
C4-060011
786

Addition of Authentication Domains in MAP Send Authentication Info
7.3.0

32
C4-060813
0808
2
List of MSISDNs and Basic Service Code for MAP Any Time Subscription Interrogation.
7.4.0

32
C4-060499
0803

Correction of LCS parameter for emergency call usage
7.4.0

32
C4-060680
0814

SSN for FFN
7.4.0

32
C4-060706
0817

Removal of MAPsec material
7.4.0

33
CP-060522
0818
1
Removal of ASN.1 Expanded Source
7.5.0

33
C4-061047
0805
1
Interoperability between VBS/VGCS and RANflex
7.5.0

34
CP-060741
0795
1
Support of SMS over IP networks
7.6.0

34
C4-061800
0828
1
Extension of Group ID
7.6.0

34
C4-061633
0829

Addition of Teleservice Code to SendGroupCallInfo
7.6.0

34
C4-061775
0834

Accuracy Fulfillment Indicator parameter to MAP SLR for deferred MT-LR
7.6.0

34
C4-060693
0832
2
Optional Suppress Terminating Services Bit String in SRI
7.6.0

34
C4-061632
0807
2
Introduction of sending application-specific data to group call members
8.0.0

35
C4-070140
0843

ASN.1 module version update
8.1.0

35
C4-070097
0837

Corrections to RAB Configuration Indicator and Iu-Selected codec
8.1.0

35
C4-070229
0840

Addition of capability to route MT-SMs via the HPLMN of the receiving MS
8.1.0

36
C4-070388
0849

Mobile Termination whilst the MS is moving to another MSC
8.2.0

36
C4-070394
0842
2
Addition of SMS over IP functionality
8.2.0

36
CP-070476
0859

Detailed procedure in the IP-SM-GW
8.2.0

37
C4-071055
0862

QoS Extension
8.3.0

37
C4-071072
0863

Talker Channel Parameter
8.3.0

37
C4-071266
0869

LMSI For MT-SMS
8.3.0

37
C4-071281
0873
1
NPI for the call forwarding to number
8.3.0

37
C4-071285
0864
1
Limit on number of concurrent MT-LR location requests
8.3.0

37
C4-071383
0868
2
Corrections to SMS over IP handling
8.3.0

38
C4-071724
0876

TCRT: Clarification on coding of Notification Data
8.4.0

38
C4-071815
0879

Removal of CCBS_Call_Report_Ack and Event_Report_Ack
8.4.0

38
C4-071855
0881

Restriction on the use of ccbs-A SS indication
8.4.0

38
C4-071891
0877
3
SMS Router Optimization
8.4.0

38
C4-071997
0875
1
Behaviour of the IP-SM-GW for SM Delivery Status Report
8.4.0

39
C4-080267
0885

Updating of RAT Types
8.5.0

39
C4-080148
0883

SDL correction for procedure Check_Available_Vectors
8.5.0

39
C4-080532
0886
2
HLR involvement in SMS Router Optimization
8.5.0

40
C4-081277
0888
1
Extension of Group ID
8.6.0

40
C4-080647
0882
1
Paging optimization with A/Iu flex
8.6.0

41
C4-081730
0890

Addition of IMS Centralized Service subscription information
8.7.0

41
C4-082447
0891
1
eMLPP Priority in MAP SRI, PRN and PSI request
8.7.0

41
C4-082335
0892
1
Gr+ enhancements for EPS
8.7.0

42
C4-082721
0894

Gr alignment
8.8.0

42
C4-082758
0896

RAT Frequency Selection Priority
8.8.0

42
C4-083029
0899

Change in AMBR placement
8.8.0

42
C4-083221
0901

PDN-GW-Identity
8.8.0

42
C4-083223
0902

APN-OIReplacement
8.8.0

42
C4-083247
0903

Access Restriction
8.8.0

42
CP-080706
0906
1
Access Restriction Data Handling
8.8.0

42
Cp-080771
0895
4
Closed Subscriber Group
8.8.0

42



SDL files added in Zip-file
8.8.1

43
C4-090140
0908

Context Identifier for Update or Removal of PDN GW
8.9.0

43
C4-090269
0911

Handling LCS Subscription Data
8.9.0

43
C4-090507
0914

PDN GW Update for Wildcard APN
8.9.0

43
C4-090701
0909
1
Ready for SM
8.9.0

43
C4-090855
0915

Handling SMS Subscription Data
8.9.0

43
C4-090889
0916

Allocation Retention Priority Definition
8.9.0

44
C4-091071
0919

SMS over IP
8.10.0

44
C4-091028
0917

MAP RESTORE DATA service
8.10.0

44
C4-091377
0921
1
Subscription Data Clarification for MAP Interface
8.10.0

44
C4-091429
0920
1
Trace
8.10.0

44
C4-091435
0922
1
Supported Features
8.10.0

44
CP-090379
0923
1
User Data Download
8.10.0

45
C4-091713
0924

Notification of SMS over IP Non-Delivery for E-UTRAN and UE Reachability
8.11.0

45
C4-092244
0927

SGSN interface list for trace
8.11.0

45
C4-092254
0925
2
Cancel Location for Initial Attach
8.11.0

45
C4-092291
0929

Fix APN-Configuration to support dual IP addresses
8.11.0

46
C4-094140
0941
1
Alignment of specifications on Usage of MAP_SEND_AUTHENTICATION_INFO
8.12.0

46
C4-093972
0942
1
SMS over SGs charging
8.12.0

46
C4-094136
0936
1
Subscription to Notification of UE Reachability
8.12.0

46
C4-093588
0935
1
Evolved ARP
9.0.0

46
C4-093294
0932
2
APN level APN-OI-Replacement
9.0.0

46
C4-093221
0933
1
ICS-Flag
9.0.0

47
C4-100386
0949

Correction to the location information EPS IE
9.1.0

47
C4-101003
0951
1
User CSG Information for CAMEL
9.1.0

47
C4-100946
0945
2
Support of Location Continuity on the Lg Interface
9.1.0

47
C4-100947
0958
2
Enhancement of MAP-SEND-ROUTING-INFO-FOR-LCS Service for EPS
9.1.0

47
C4-100264
0943

Evolved ARP Corrections
9.1.0

47
C4-100920
0928
4
AoIP – MAP level codec negotiation for GSM codecs
9.1.0

47
C4-100265
0944

Dual Stack support in GPRS
9.1.0

47
C4-100353
0939
2
Support MT Roaming Retry on Pre-paging
9.1.0

47
C4-100892
0954
1
TCRT: Uplink reply procedure
9.1.0

47
C4-100881
0956
1
TADS support in MAP
9.1.0

47
C4-101010
0950
1
UE-AMBR in GPRS Subscription
9.1.0

47
CP-100234
0960

Incorrect KASME length
9.1.0

47
CP-100203
0952
5
EPS Subcsriber State and Location Information Request
9.1.0

48
C4-101236
0971

CR implementation CR 642
9.2.0

48
C4-101403
0963
1
Correction to missing GANSS position data in Provide Subscriber Location and Provide Subscriber Location Report services
9.2.0

48
C4-101400
0967
1
Tracking Area Identity Length
9.2.0

48
C4-101131
0961

ASN.1 Module Version Update
9.2.0

48
C4-101135
0962

EPS state and location retrieval
9.2.0

49
C4-101802
0975
1
Sending of MME name or SGSN Number to the VLR during the data restoration procedure
9.3.0

49
C4-101805
0977
1
Data Restoration for SMS
9.3.0

49
C4-102251
0966
3
MAP SRI Return Error message
9.3.0

49
C4-102269
0985
1
EPS Subscription Data over Gr
9.3.0

49
C4-102376
0980
3
RP-OA modification in SMS Router
9.3.0

49
C4-101809
0976
1
Addition of SIPTO permissions in PS subscription data
10.0.0

49
C4-102250
0957
4
Prevention of Timeout in IP-SM-GW
10.0.0

49
CP-100608
0979
2
Addition of  SS codes to the ATSI and ATM procedures
10.0.0

50
C4-103099
0990
2
locationInformationEPS in Subscriber Info response
10.1.0

50
C4-102699
0988
1
Removal of MAP Update GPRS Location message during detach or last PDN connection deactivation via 3GPP access
10.1.0

50
C4-102737
0993
1
URRP for SGSN
10.1.0

50
C4-103156
1005

Location data including only serving node address
10.1.0

50
C4-103157
0997
2
Correction to ATM for call waiting
10.1.0

50
C4-103314
1002
2
Periodic TAU/RAU timer in HSS subscription
10.1.0

50
C4-102614
0991

ASN.1 module version upgrade
10.1.0

50
C4-102687
0987
1
Addition of MPS Priority in Subscription Data
10.1.0

50
C4-102809
0986
1
Addition of LIPA permission in Subscription Data
10.1.0

51
C4-110389
1006
2
UE SRVCC Capability Support in MAP Message
10.2.0

51
C4-110292
1008
1
Use of recovered MME Name / SGSN Name in MSC/VLR
10.2.0

51
C4-110133
1009

Zone Code Propagation at Handover
10.2.0

51
C4-110665
1016

Retrieval of T-ADS data via MAP ATI
10.2.0

51
C4-110759
1018
1
Mobile Terminating Roaming Forwarding  
10.2.0

51
C4-110778
1007
2
Minimization of Drive Tests (MDT)
10.2.0

51
C4-110793
1015
1
Introduction of LCLS functionality in TS 29.002
10.2.0

51
C4-110958
1017
2
Enhancements of T-ADS data retrieval via MAP ATI
10.2.0

52
C4-111112
1024

Correction on Subscriber Data Withdrawal
10.3.0

52
C4-111611
1030
2
Missing MME Name in EPS Location Information
10.3.0

52
C4-111534
1020
1
MDT user consent
10.3.0

52
C4-111567
1021
1
SC Address in IP-SM-GW Register Response
10.3.0

52
C4-111402
1025
1
Periodic LAU timer in HSS subscription
10.3.0

52
C4-111414
1026
1
New LMSI handling for MTRF
10.3.0

52
C4-111416
1029
1
Addition of VMSC Address in PRN Ack
10.3.0

53
C4-112067
1047

Use of UE-Reachability by SGSN
10.4.0

53
C4-112081
1042
1
APN-AMBR for GPRS
10.4.0

53
C4-112096
1033
1
MTRF and Super Charger interactions
10.4.0

53
C4-111986
1043

ASN.1 exports for 32.298
11.0.0

53
C4-112033
1032
1
Addition of Anonymous Call Rejection in the CS domain
11.0.0

53
C4-112209
1037
2
Add vSRVCC updates to the Gr interface
11.0.0

53
C4-112222
1040
2
MAP-READY-FOR-SM for IP-SM-GW
11.0.0

54
C4-112930
1053
1
Provide Subscriber Information handling for UE under LTE
11.1.0

54
C4-112988
1063

PDN-Type
11.1.0

54
C4-112990
1056
1
Equivalent PLMN CSG Subscription Request
11.1.0

54
C4-113037
1055
2
LCLS negotiation MAP update
11.1.0

54
C4-112464
1039
4
Cancellation type initial attach
11.1.0

55
C4-120406
1064
1
Initial Attach Indication in MAP_CANCEL_LOCATION
11.2.0

55
C4-120420
1073
1
Removal of Subscribed Periodic TAU/RAU timer in HSS subscription
11.2.0

55
C4-120528
1072
2
User Unknown Error in Provide Subscriber Info MAP operation
11.2.0

55
C4-120224
1066

UE reachability
11.2.0

55
C4-120322
1070

TC-RT: Introduction of group IDs with prefix
11.2.0

55
C4-120416
1067
1
CSG subscription data propagation
11.2.0

55
C4-120423
1069
1
Trace Depth
11.2.0

56
C4-120707
1078

Editorial corrections to TS 29.002
11.3.0

56
C4-120713
1079

Equivalent PLMN CSG Subscription Request for CS
11.3.0

56
C4-120732
1080

EPS location in MAP Note MM Event
11.3.0

56
C4-120959
1065
3
CSG ID and Local Time for NPLI
11.3.0

56
C4-121086
1082

Clarification on HLR procedure for SMS delivery via IP-SM-GW
11.3.0

56
C4-121222
1059
4
Procedures for Update VCSG Location service
11.3.0

56
C4-121223
1049
9
Retrieving CSG subscription data from the CSS to the VLR/SGSN
11.3.0

56
C4-121227
1060
5
CSG Data Management in the VPLMN
11.3.0

57
C4-121465
1089
-
TC RT: Number of Dispatcher extension
11.4.0

57
C4-121635
1088
1
Check IMEI Error
11.4.0

57
C4-121805
1092
2
Local Time Zone
11.4.0

57
C4-121534
1084
1
IMSI in MAP-MO-FORWARD-SHORT-MESSAGE
11.4.0

57
C4-121817
1068
5
PS additional number
11.4.0

57
C4-121813
1090
2
SRI for SM and MME Diameter address
11.4.0

57
C4-121802
1091
2
MSISDN-less MT-SMS
11.4.0

57
C4-121625
1083
1
PS only subscription w/o MSISDN
11.4.0

57
C4-121809
1077
4
SMS in MME/SGSN
11.4.0

57
C4-121648
1085
1
CSS Reset Procedures
11.4.0

57
C4-121650
1086
2
Temporary empty CSG suscription data
11.4.0

58
C4-122660
1106
4
Clarification on EPS Info
11.5.0

58
C4-122497
1108
1
Pdp Type
11.5.0

58
C4-122164
1093
1
Trace Depth extension
11.5.0

58
C4-121847
1094

AC version for Reset
11.5.0

58
C4-122469
1095
4
MSISDN-less UEs
11.5.0

58
C4-122476
1096
3
T4 Device Trigger via IMS
11.5.0

58
C4-122187
1097
2
T4 Trigger indication to IP-SM-GW
11.5.0

58
C4-122190
1098
2
Add Diameter Addresses to MT-SMS target node registrations
11.5.0

58
C4-121870
1099

IMSI in AbsentSubscriberSM-param
11.5.0

58
C4-122165
1101
1
Handling of current security context during inter-VLR location update
11.5.0

59
C4-130330
1118
1
SGSN acting on access restriction e-utranNotAllowed
11.6.0

59
C4-130293
1119
1
Registration for SMS Request for SMS in SGSN
11.6.0

59
C4-130305
1120
1
MDT parameters
11.6.0

59
C4-130335
1121
1
Providing Diameter identity of the SGSN to the GMLC over Lh interface
12.0.0

59
C4-130340
1122
1
SGSN indicating support of Lgd interface and providing its Diameter identity to HLR over Gr interface
12.0.0

59
C4-130423
1123
2
Validity Time of Short Message
12.0.0

59
C4-130256
1114

Mobile Terminating call pending flag in MAP Send Identification response
12.0.0

60
C4-131046
1147
2
Subscribed RFSP index for Gn SGSNs
12.1.0

60
C4-131061
1142
3
MME identity for restoration procedures
12.1.0

60
C4-130603
1128

Expicit T4-Trigger Indicator in SRI-SM
12.1.0

60
C4-130929
1126
1
Restoration Priority during SGW and PGW restoration procedures
12.1.0

60
CP-130379
1132
3
SIPTO permission for Local Network enhancements
12.1.0

60
C4-130859
1131
1
Clarification on RNC ID value
12.1.0

60
C4-130979
1129
1
Storing Last known Location Information of purged UE in HSS
12.1.0

60
C4-131040
1135
2
Maximum value for subscribed periodic timers
12.1.0

61
C4-131488
1158
2
Addition of Missing Supported Features
12.2.0

61
C4-131261
1160

ASN.1 module version update
12.2.0

61
C4-131540
1149
1
Returning to former LTE PLMN after CSFB
12.2.0

61
C4-131398
1152
2
Complements for Gdd support
12.2.0

61
C4-131445
1153
1
GERAN Iu Mode
12.2.0

61
C4-131478
1150
2
CancelLocation requesting reattach
12.2.0

61
C4-131529
1161

Enforcing access restriction during I-RAT RAU/TAU procedures
12.2.0

61
C4-131370
1130
2
SMS for IMS UE to IMS UE without MSISDN
12.2.0

62
C4-131758
1162
1
Addition of a reference to TS 23.018 for MTRF optimal routing
12.3.0

62
C4-131759
1163
1
Removal of Editor's Notes for Single-shot SM
12.3.0

62
C4-131764
1165
1
Clarification on Serving Node for SMS
12.3.0

62
C4-132011
1167

MME Initiated Removal of MME Registration for SMS
12.3.0

62
C4-132125
1169
1
Update of Homogeneous Support of IMS Voice Over PS Sessions
12.3.0

62
C4-132202
1171
1
Time Zone retrieval from a Gn/Gp-SGSN
12.3.0

63
C4-140243
1174
1
Addition of SGSN CAMEL Capability to SupportedFeatures
12.4.0

64
C4-140515
1177

CS to PS SRVCC
12.5.0

64
C4-140897
1179

Indication of IMEISV during Inter-MSC Handover
12.5.0

65
C4-141526
1181
1
P-CSCF Restoration Indication
12.6.0

65
C4-141653
1182
1
Closing TS 29.234 and reused AVP in TS 29.273
12.6.0

66
C4-141778
1183
1
MDT PLMN List
12.7.0

66
C4-142039
1187
1
WLAN offloadability for MAP
12.7.0

68
C4-150647
1188
1
Access restriction per VPLMN
13.0.0

68
C4-150880
1190

Access Restriction Data per PLMN
13.0.0

69
C4-151177
1191

ASN.1 module version update
13.1.0

70
C4-151631
1194

Reference Correction
13.2.0

70
C4-151813
1192
1
Introducing IMSI-Group ID Lists to the insert subscriber data
13.2.0

70
C4-151801
1195
1
Retrieval of "UE Usage Type" over MAP-Gr
13.2.0

70
C4-152198
1196
1
Positioning enhancement impacts on MAP protocol
13.2.0

70
CP-150868
1198
2
Mobile Terminating SMS handling for extended Idle mode DRX – Additional Option
13.2.0

70
CP-150869
1197
2
Mobile Terminating SMS handling for extended Idle mode DRX
13.2.0

71
C4-161271
1202
1
Alert procedure from MME/SGSN to SMS-GMSC for MT SMS to UE using eDRX
13.3.0

71
C4-161062
1200

Requested Retransmission Time in MT-Forward-SM response
13.3.0

71
C4-161527
1205
2
New PDN-Type for Cellular IoT
13.3.0

71
C4-161492
1204
2
Addition of NB-IoT radio access type to the Access-Restriction-Data feature
13.3.0

71
C4-161161
1203

Time Zone in MAP-Any-Time-Interrogation
13.3.0

71
C4-161317
1201
1
User Plane Integrity Protection Indicator
13.3.0

72
C4-162090
1213

Clause Numbering
13.4.0

72
C4-163271
1215
3
Group-Service-Id
13.4.0
2016-06
CT#72
CP-160217
1216
1
Use of recovered MME Name / SGSN Name in MSC/VLR
14.0.0
2016-06
CT#72
CP-160217
1214
1
Zone Code Propagation at Handover
14.0.0
2016-09
CT#73
CP-160430
1219

Retrieval of T-ADS data via MAP ATI
14.1.0
2016-09
CT#73
CP-160583
1218
2
Mobile Terminating Roaming Forwarding  
14.1.0
2016-09
CT#73
CP-160423
1221
1
Minimization of Drive Tests (MDT)
14.1.0
2016-12
CT#74
CP-160667
1225
1
Introduction of LCLS functionality in TS 29.002
14.2.0
2016-12
CT#74
CP-160665
1229
1
Enhancements of T-ADS data retrieval via MAP ATI
14.2.0
2016-12
CT#74
CP-160659
1227

Correction on Subscriber Data Withdrawal
14.2.0
2016-12
CT#74
CP-160683
1230
3
Missing MME Name in EPS Location Information
14.2.0
2016-12
CT#74
CP-160657
1233

MDT user consent
14.2.0
2016-12
CT#74
CP-160683
1231
1
SC Address in IP-SM-GW Register Response
14.2.0
2017-03
CT#75
CP-170034
1236

T4 Triggering
14.3.0
2017-03
CT#75
CP-170039
1234
1
Enhanced Coverage
14.3.0
2017-03
CT#75
CP-170039
1235
1
Inter-RAT PDN-Continuity
14.3.0
2017-03
CT#76
CP-171039
1237
-
T-ADS info retrieval
15.0.0
2017-09
CT#77
CP-172021
1239
-
ASN.1 module version update
15.1.0
2017-12
CT#78
CP-173016
1243
2
Correction on subscribed eDRX parameter value
15.2.0
2017-12
CT#78
CP-173036
1240
-
Access Restrictions to NR as Secondary RAT
15.2.0
2017-12
CT#78
CP-173036
1241
-
Extended Qos
15.2.0
2018-03
CT#79
CP-180027
1244
2
Access restriction to unlicensed spectrum as secondary RAT
15.3.0
2018-10




Cover page version number was corrected
15.3.1
2018-12
CT#82
C4-187638
1245
2
Location Information used by IM-SSF in 5G
15.4.0
2019-06
CT#84
CP-191020
1249

ASN.1 corrections
15.5.0
2019-06
CT#84
CP-191058
1250
1
SMSF Address
15.5.0
2020-03
CT#87
CP-200049
1253

Correction on Location Information used by IM-SSF in 5G
15.6.0
2020-03
CT#87
CP-200027
1251
3
Addition of IAB operation permission to subscriber data
16.0.0
2020-12
CT#90e
CP-203027
1255

Inform SC
16.1.0
2020-12
CT#90e
CP-203027
1257

SMSF parameter description
16.1.0
2021-03
CT#91e
CP-210053
1260

Correction on length of 5GS TAI
16.2.0
2021-06
CT#92e
CP-211074
1262

ASN.1 module version update
16.3.0

