network inter working between gsm map and ansi-41 cdma
Post on 07-Jun-2015
123 Views
Preview:
TRANSCRIPT
3GPP2 X.S0023
Version 1.0
Version Date: July, 2004
Network Interworking Between GSM MAP and TIA-41 MAP – CDMA2000 Support
Revision: B
COPYRIGHT 3GPP2 and its Organizational Partners claim copyright in this document and individual Organizational Partners may copyright and issue documents or standards publications in individual Organizational Partner's name based on this document. Requests for reproduction of this document should be directed to the 3GPP2 Secretariat at secretariat@3gpp2.org. Requests to reproduce individual Organizational Partner's documents should be directed to that Organizational Partner. See www.3gpp2.org for more information.
Revision History
Revision Date Rev. B v1.0 Initial Publication (Note 1) July 2004
Notes 1. The specification is an extract of J-STD-038-B.
X.S0023
0-i
NNNeeetttwwwooorrrkkk IIInnnttteeerrrwwwooorrrkkkiiinnnggg BBBeeetttwwweeeeeennn GGGSSSMMM MMMAAAPPP aaannnddd TTTIIIAAA---444111 MMMAAAPPP;;;1
RRReeevvviiisssiiiooonnn BBB ––– CCCDDDMMMAAA222000000000 SSSuuuppppppooorrrttt2
VVVooollluuummmeee 000 ––– OOOvvveeerrrvvviiieeewww aaannnddd NNNeeetttwwwooorrrkkk RRReeefffeeerrreeennnccceee MMMooodddeeelll3
(((RRReeevvviiisssiiiooonnn ooofff JJJ---SSSTTTDDD---000333888---AAA VVVooollluuummmeee 000)))4
X.S0023
0-ii
Abstract1
This standard addresses the interworking and interoperability between ANSI-41 MAP[2] and GSM2MAP[4] based networks in the support of subscribers roaming between networks. The3interworking and interoperability functionality of the services, information flows, and message4mappings are specified.5This standard consists of four volumes:6
Volume 0 - Overview and Interworking Reference Model7Volume 1 - Service Descriptions8Volume 2 - Information Flows9Volume 3 - Message Mappings10
This Volume contains an overview of the Interworking and Interoperability Function (IIF) and the11associated network reference model.12
X.S0023
0-iii
Contents1
Abstract....................................................................................................................................................ii2
Contents ................................................................................................................................................. iii3
List of Tables ...........................................................................................................................................v4
List of Figures.........................................................................................................................................vi5
Foreword................................................................................................................................................vii6
1 Introduction ............................................................................................................................... 17
1.1 General........................................................................................................................ 18
1.2 Purpose ....................................................................................................................... 19
1.3 Scope .......................................................................................................................... 110
2 References................................................................................................................................ 211
3 Definitions and Acronyms ........................................................................................................ 412
3.1 Definitions.................................................................................................................... 413
3.2 Acronyms .................................................................................................................... 714
4 Overview of Internetwork Roaming ....................................................................................... 1115
5 IIF Reference Model and Description.................................................................................... 1216
5.1 Reference Model....................................................................................................... 1217
5.2 Description ................................................................................................................ 1218
5.2.1 Provisioned Subscriber Data ..................................................................... 1319
5.3 Interworking for Network Interfaces ......................................................................... 1520
5.3.1 HLR - VLR Interface................................................................................... 1621
5.3.2 Originating / Gateway MSC - Serving MSC Interface ............................... 1822
5.3.3 MC / SMS-SC - Serving MSC Interface .................................................... 1923
5.3.4 HLR – SGSN Interface................................................................................ 2024
X.S0023
0-iv
5.4 IIF Implementation Alternatives................................................................................ 211
5.4.1 IIF Resides within a GSM Network Entity .................................................. 212
5.4.2 IIF Resides within ANSI-41 Network Entity................................................ 213
5.4.3 IIF Resides within External Network Element............................................ 224
5.4.4 IIF Resides within Both ANSI-41 and GSM Network Entities ................... 2256
X.S0023
0-v
List of Tables1
There are no tables in this volume.2
X.S0023
0-vi
List of Figures1
Figure 1: IIF Reference Model............................................................................................................ 122Figure 2: HLR - VLR Interface............................................................................................................ 163Figure 3: Originating / Gateway MSC - Serving MSC Interface........................................................ 184Figure 4: MC / SMS-SC - Serving MSC Interface ............................................................................. 195Figure 5: HLR- SGSN Interface.......................................................................................................... 206Figure 6: IIF Resides within GSM Network Element ......................................................................... 217Figure 7: IIF Resides within ANSI-41 Network Element.................................................................... 218Figure 8: IIF Resides within External Network Element .................................................................... 229Figure 9: IIF Resides within both ANSI-41 and GSM Network Elements......................................... 2210
11
X.S0023
0-vii
Foreword1
This foreword is not part of this standard.2This standard addresses the interworking and interoperability between ANSI-41 MAP and GSM3based networks in the support of subscribers roaming between networks. The objective of the4standard is to achieve fully automatic, two-way interoperability between the heterogeneous5networks. Services supported by this standard are described along with the associated6information flows and message mappings. However, not all services and associated capabilities7of ANSI-41 MAP and GSM MAP are supported by this standard. In general the attempt has been8to focus on the key subscriber services needed in the market.9The focus of the first release of this standard was on common GSM and ANSI-136 TDMA10services and associated network signaling (i.e. ANSI-41 MAP and GSM MAP). A prerequisite for11this interoperability is multi-mode mobile stations with an enhanced SIM card for roaming12between ANSI-136, GSM, and AMPS networks.13The first release of the standard did not define or require changes to existing ANSI-41 MAP or14GSM MAP to achieve the described interworking and interoperability. However, due to15differences between the services and associated capabilities of the MAP protocols, complete and16fully transparent interoperability may not have been achieved for some services. Future releases17of this standard may require changes to ANSI-41 MAP, GSM MAP and the associated services to18achieve full transparency while roaming between the different networks.19Aspects of TIA/EIA-136 Revision C have been incorporated into the standard.20
Revision A adds GPRS service capability in GSM Foreign Mode.21Revision B adds one-way and two-way roaming between GSM and CDMA systems.22
23
X.S0023
0-1
1 Introduction1
1.1 General2
When a subscriber to one network type (e.g., ANSI-41) roams to a network of another type (e.g.,3GSM), interworking and interoperability functions are required to support roaming and enable4service. This standard describes an Interworking and Interoperability Function (IIF) to support this5cross-technology roaming between ANSI-41 and GSM networks. The IIF supports a multi-mode6mobile station with a removable Subscriber Identity Module (SIM). The standard also defines the7required network message mappings between ANSI-41 MAP and GSM MAP to support the8mobile terminal and associated services.9This standard includes the support of cross-technology roaming from an ANSI-41 based network10to a GPRS network. The GPRS network may be coupled with a GSM network. This feature11requires enhancement to the Interworking and Interoperability Function (IIF) which supports a12multi-mode mobile station and SIM with GPRS functionality.13
1.2 Purpose14
The purpose for this standard is to define and describe the functions necessary for roaming15between ANSI-41 MAP and GSM MAP based networks in the support of roaming subscribers.16This includes a capability to allow a subscriber to an ANSI-41 based network (e.g., a TDMA or17CDMA native subscriber) with a mobile terminal supporting GPRS service to roam to a GPRS18network in GSM Foreign Mode.19
1.3 Scope20
The scope of this standard are the services, information flows and message mappings which21require interworking and interoperability functional specifications to support roaming between22ANSI-41 MAP and GSM MAP networks.23
The scope of this volume is to provide a description of interstandard roaming along with an24overview and network reference model for the Interworking and Interoperability Function (IIF).25
X.S0023
0-2
2 References1
[1] TIA/EIA-136: “TDMA Third Generation Wireless,” March 2000, ANSI.2[2] TIA/EIA-41-D: “Cellular Radiotelecommunications Intersystem Operations,” December3
1997, ANSI.4[3] TIA/EIA-553: “Mobile Station – Land Station Compatibility Specification,” September5
1989, ANSI.6[4] GSM 09.02 Version 6.2.0 Release 1997 “Digital cellular telecommunication system7
(Phase 2+); Mobile Application Part (MAP) specification”, August 1998, ETSI.8[5] TIA/EIA/IS-129, “Interworking/Interoperability Between DCS 1900 and IS-41 Based MAPs9
for 1800 MHz Personal Communications Systems,” Phase 1, July 1996.10[6] TIA/EIA/IS-737-A “IS-41 support for data services for digital terminals (TDMA and11
CDMA)”.12[7] TIA/EIA/IS- 735 “IS-41 support for IS-95-A (advanced CDMA)”.13[8] TIA/EIA/TSB58-E “Administration of Parameter Value Assignments for TIA/EIA Spread14
Spectrum Standards”, January 2002.15[9] TIA/EIA-95-B “Mobile Station-Base Station Compatibility Standard for Dual-Mode Spread16
Spectrum Systems”; Published October 1998.17[10] “TIA/EIA-IS-2000-A, cdma2000 Series, March 2000, plus addenda” Mobile Station-Base18
Station Compatibility Standard for Dual-Mode Spread Spectrum Systems.19[11] TIA/EIA-868 – ANSI-41-D Network Based Enhancements to support one-way roaming to20
GSM, in press.21[12] “Enhanced Cryptographic Algorithms, Revision B,” TR-45 AHAG, March, 2002.22[13] TIA/EIA/IS-751, “TIA/EIA 41-D Modifications to Support IMSI, February 1998”.23[14] TIA/EIA/IS-807, “TIA/EIA-41-D Enhancements for Internationalization”; August, 1999.24[15] TIA/EIA-664: “Cellular Features Description”, Telecommunications Industry Association;25
February 2000, ANSI.26[16] “Common Cryptographic Algorithms, Revision C,” October 27, 1998, TR-45 AHAG.27[17] TIA/EIA-136-510 “Authentication, encryption of signaling information/user data and28
privacy”.29[18] GSM 02.04 version 6.1.1 Release 1997, “General on Supplementary Services”,30
(Phase 2+), ETSI.31[19] GSM 02.09 version 6.1.0 Release 1997, “Digital cellular telecommunications system32
Security Aspects”, (Phase 2+), ETSI.33[20] GSM 02.30 version 6.1.0 Release 1997, “Man-Machine Interface (MMI) of the Mobile34
Station”, (Phase 2+), ETSI.35[21] GSM 02.41 version 6.0.0, Release 1997, "Operator Determined Barring (ODB)",36
(Phase 2+), ETSI.37[22] GSM 02.79 version 6.0.0, Release 1997, “Support of Optimal Routeing (SOR) Service38
Definition (Stage 1)”, (Phase 2+), ETSI.39
X.S0023
0-3
[23] GSM 02.81 version 7.0.0 Release 1998, “Line Identification Supplementary Services –1Stage 1“ (Phase 2+), ETSI.2
[24] GSM 02.82 version 6.0.0 Release 1997, “Call Forwarding (CF) Supplementary Services -3Stage 1” (Phase 2+), ETSI.4
[25] GSM 02.83 version 6.0.0 Release 1997, “Call Waiting (CW) and Call Holding (HOLD)5Supplementary Services - Stage 1”, (Phase 2+), ETSI.6
[26] GSM 02.84 version 6.0.0 Release 1997, “MultiParty (MPTY) Supplementary Services –7Stage 1”, (Phase 2+), ETSI.8
[27] GSM 02.85 version 6.0.0 Release 1997, “Closed User Group (CUG) Supplementary9Services – Stage 1 ”, (Phase 2+), ETSI.10
[28] GSM 02.86 version 6.0.0 Release 1997, “Advice of Charge (AOC) Supplementary11Services – Stage 1”, (Phase 2+), ETSI.12
[29] GSM 02.88 version 6.0.0 Release 1997, “Call Barring (CB) Supplementary Services –13Stage 1” (Phase 2+), ETSI.14
[30] GSM 02.60 version 6.3.1 Release 1997 “General Packet Radio Service (GPRS); Service15Description, Stage 1.16
[31] GSM 03.18 Version 6.2.0 Release 1997 “ Digital cellular communication system17(Phase 2+); Basic call handling; Technical realisation”, November 1998, ETSI.18
[32] GSM 03.79 version 6.2.0 Release 1997, “Digital cellular telecommunications system19(Phase 2+); Support of Optimal Routeing (SOR) Technical Realisation”.20
[33] GSM 03.60 version 6.8.0 Release 1997 “General Packet Radio Service (GPRS);21Stage 2”.22
[34] GSM 03.81 version 6.0.0 Release 1997 “Line Identification Supplementary Services;23Stage 2”.24
[35] GSM 03.40 version 6.2.0 Release 1997 “Technical realization of the Short Message25Service (SMS)”.26
X.S0023
0-4
3 Definitions and Acronyms1
3.1 Definitions2
AMPS3Advanced Mobile Phone Service (AMPS) is the same as EIA/TIA-553 [3], which is an analog air4interface protocol standard for mobile stations and their associated base stations. AMPS5networks use ANSI-41 for intersystem signaling.6
ANSI-417ANSI-41, as used in this document, refers to TIA/EIA-41[2] and the modifications and8enhancements as noted in IS-751 and IS-807. This is a network protocol standard to support9intersystem operation of cellular networks, such as TDMA or CDMA networks. Key intersystem10support defined by ANSI-41 includes automatic roaming, intersystem handoff, and intersystem11operation, administration, and maintenance. Among other things, ANSI-41 defines the interfaces12between MSCs, between the MSC/VLR and the HLR/AC, and between the MSC and the Short13Message Service Center (SMS-SC) or Teleservice Server (TS).14
ANSI-13615ANSI-136, as used in this document, refers to TIA/EIA-136[1], which is a TDMA air interface16protocol standard for mobile stations and their associated base stations. ANSI-136 is a dual-17mode standard that includes digital (TDMA) operation at 800 MHz and 1900 MHz, and analog18(AMPS) operation at 800 MHz. ANSI-136 networks use ANSI-41 for intersystem signaling.19
ANSI-136 Mode20ANSI-136 mode indicates the condition or state of a mobile station accessing an ANSI-13621network.22
ANSI-136 Foreign Mode23ANSI-136 foreign mode indicates the condition or state of a GSM native subscriber accessing an24ANSI-136 network.25
ANSI-136 Native Mode26ANSI-136 native mode indicates the condition or state of an ANSI-136 native subscriber27accessing an ANSI-136 network.28
ANSI-136 Native Subscriber29ANSI-136 native subscriber indicates an end user whose primary or home subscription resides in30an ANSI-136 network. These subscribers include both home subscribers from the ANSI-13631network, as well as roamers from other ANSI-136 networks.32
ANSI-41 Foreign Mode33ANSI-41 foreign mode indicates the condition or state of a GSM native subscriber accessing an34ANSI-41 based network35
X.S0023
0-5
CDMA1CDMA as used in this document, refers to TIA/EIA -95 [9] or TIA/EIA-2000 [10], which is a CDMA2air interface protocol standard for mobile stations and their associated base stations. CDMA is a3dual-mode standard that includes digital (CDMA) operation and analog (AMPS) operation. CDMA4networks use ANSI-41 for intersystem signaling.5
CDMA Foreign Mode6CDMA foreign mode indicates the condition or state of a GSM native subscriber accessing a7CDMA network.8
CDMA Mode9CDMA mode indicates the condition or state of a mobile station accessing a CDMA network.10
CDMA Native Mode11CDMA native mode indicates the condition or state of an CDMA native subscriber accessing an12CDMA network.13
CDMA Native Subscriber14CDMA native subscriber indicates an end user whose primary or home subscription resides in an15CDMA network. These subscribers include both home subscribers from the CDMA network, as16well as roamers from other CDMA networks.17
Class A mobile18Class A mobile station is a GSM mobile that can operate in Class A mode: both GSM circuit-19switched and GPRS packet services simultaneously.20
Class B mobile21Class B mobile station is a GAIT or GSM mobile that operates in Class B mode: can operate22alternatively GSM circuit-switched or GPRS packet services (1 type service at a time). The mobile23can be attached to GSM and GPRS networks simultaneously in this case. The subscriber cannot24be simultaneously attached to an ANSI-41 MSC.25
Class C mobile26Class C mobile station is a GSM mobile that can only operate in Class C mode: GSM circuit-27switched only or GPRS packet services only. The mobile is attached to only one network at a28time.29
GPRS HLR30General Packet Radio Service Home Location Register is the HLR responsible for GPRS31functions. It interfaces with the SGSN and GGSN and Authentication Center.32
GPRS in GSM Foreign Mode33GPRS in GSM Foreign Mode is a subset of GSM Foreign Mode and indicates the condition or34state of an ANSI-41 native subscriber accessing a GPRS network. The GPRS network may be35coupled with a GSM network.36
GSM37Global System for Mobile Communications (GSM) defines both air interface and network38intersystem protocol standards for mobile stations (MS), base station systems (BSS), and39network switching systems (NSS).40
X.S0023
0-6
GSM CS attached1GSM circuit-switched services attached means that the subscriber is attached to a GSM MSC.2This is also referred to as IMSI attached3
GSM CS detached4GSM circuit-switched services detached means that the subscriber is detached from a GSM5MSC. This is also referred to as IMSI detached.6
GSM Foreign Mode7GSM foreign mode indicates the condition or state of an ANSI-41 native subscriber accessing a8GSM network.9
GSM Mode10GSM mode indicates the condition or state of a mobile station accessing a GSM network.11
GSM Native Mode12GSM native mode indicates the condition or state of a GSM native subscriber accessing a GSM13network.14
GSM Native Subscriber15GSM native subscriber indicates an end user whose primary or home subscription resides in a16GSM network. These subscribers include both home subscribers from the GSM network, as well17as roamers from other GSM networks.18
Late Call Forwarding19Call Forwarding invoked after the call has been offered to the terminating VMSC (e.g., CFB,20CFNA/CFNRy, CFNRc) .21
Mobile Equipment22The radio transceiver, main processing unit, and man-machine interface necessary to access the23radio network.24
Mobile Station25The mobile equipment and the SIM together make up the mobile station, which is the wireless26radiotelephone used by the subscriber.27
Subscriber Identity Module28A smart card that plugs into the mobile equipment and that contains the authentication29algorithms, and stores service-oriented subscription information.30
X.S0023
0-7
3.2 Acronyms1
AC Authentication Center in ANSI TIA/EIA-41 based networks2
ADN Abbreviated Dialing Numbers3
AMPS Advanced Mobile Phone Service4
ANSI American National Standards Institute5
AuC Authentication Center in GSM networks6
BAIC Barring of All Incoming Calls7
BAOC Barring of All Outgoing Calls8
BIC-Roam Barring of Incoming Calls while Roaming Outside HPLMN Country9
BMI Base Station, Mobile Switching System, and Interworking Function10
BOIC Barring of Outgoing International Calls11
BOIC-exHC Baring of Outgoing International Calls Except to HPLMN Country12
CDMA Code-Division Multiple Access13
CFB Call Forwarding Busy14
CFNA Call Forwarding No Answer15
CFNRc Call Forwarding Not Reachable16
CFNRy Call Forwarding No Reply17
CFU Call Forwarding Unconditional18
CPHS Common PCN Handset Specification19
CS Circuit-Switched20
DCS Data Coding Scheme21
EDGE Enhanced Data Rates Through Global Evolution22
EIA Electronics Industries Association23
ESN Electronic Serial Number24
ETSI European Telecommunications Standards Institute25
X.S0023
0-8
EUI ESN Usage Indicator1
FC Feature Code2
FDN Fixed Dialing Numbers3
FSM Forward Short Message4
GGSN Gateway GPRS Serving Node5
GGSN Gateway GPRS Serving Node6
GHOST GSM Hosted SMS Teleservice7
GMSC Gateway Mobile Switching Center8
GPRS General Packet Radio Service9
GSM Global System for Mobile Communications10
GSM Global System for Mobile Communications11
HLPI Higher Layer Protocol Indicator12
HLR Home Location Register13
HPLMN Home Public Land Mobile Network14
IIF Interworking and Interoperability Function15
IMEI International Mobile Equipment Identifier16
IMSI International Mobile Subscriber Identity17
Interim OAA Interim Over-the-Air Activation18
IRDB Intelligent Roaming Database19
ISUP ISDN User Part20
ITU International Telecommunications Union21
MAP Mobile Application Part22
MC ANSI-41 Message Center (for SMS)23
MDN Mobile Directory Number24
ME Mobile Equipment25
MF Multi-Frequency26
X.S0023
0-9
MIN Mobile Identification Number1
MO Mobile Originated2
MS Mobile Station3
MSC Mobile Switching Center4
MSID Mobile Station Identity5
MSISDN Mobile Subscriber ISDN Number6
MSRN Mobile Station Routing Number7
MT Mobile Terminated8
MWN Message Waiting Notification9
NAM Numeric Assignment Module10
NSDB Network Selection Database11
ODB Operator Determined Barring12
OR Optimal Routing13
OTA Over-the-Air Activation14
PCS Personal Communications Service15
PDP Packet Data Protocol16
PDU Packet Data Unit17
PIN Personal Identification Number18
PLMN Public Land Mobile Network19
PRN Provide Roaming Number20
PSAP Public Safety Access Point21
SC Service Center22
SESN SIM Electronic Serial Number23
SGSN Serving GPRS Support Node24
SID System Identity25
SIM Subscriber Identity Module26
X.S0023
0-10
SMDPP Short Message Delivery Point-to-Point1
SME Short Message Entity2
SMS Short Message Service3
SMS-GMSC GSM Short Message Service Gateway Mobile Switching Center4
SMS-IWMSC GSM Short Message Service Interworking Mobile Switching Center5
SMS-SC GSM Short Message Service Center6
SOC System Operator Code7
SS7 Signaling System 78
TDMA Time Division Multiple Access9
TIA Telecommunications Industry Association10
TLDN Temporary Location Directory Number11
TMSI Temporary Mobile Station Identity12
TP-FCS TP Failure Cause13
TS Teleservice Server14
TSAR Teleservice Segmentation and Reassembly15
UDH Universal Data Header16
VLR Visitor Location Register17
VPLMN Visitor Public Land Mobile Network18
WAP Wireless Application Protocol19
WEMT Wireless Enhanced Messaging Teleservices20
X.S0023
0-11
4 Overview of Internetwork Roaming1
Commercial mobile radio networks are implemented using several different standards. Some2example radio access networks based on different standards include Advanced Mobile Phone3Service (AMPS) based on TIA-553, Time Division Multiple Access (TDMA) based on ANSI-136,4Code Division Multiple Access (CDMA) based on IS-95 and TDMA based on the Global System5for Mobile Communication (GSM) standard. Furthermore, both TDMA and CDMA and GSM uses6different network signaling standards.7In order to provide greater service ubiquity and flexibility, the need to offer subscribers access to8multiple networks based on different standards has been identified. Depending on the types of9networks available in the subscriber's location, the subscriber shall access service on a network10based on one of several different standards.11The type of network provided in the subscriber's home location area is native for this subscriber.12When the subscriber accesses any network using this technology or standard, the subscriber is13operating in native mode. Conversely, when the subscriber accesses a network using a14technology or standard which is different from the home location's network, the subscriber is15operating in foreign mode. Interstandard roaming allows the subscriber to seamlessly obtain16service in foreign mode.17
X.S0023
0-12
5 IIF Reference Model and Description1
5.1 Reference Model2
The Interworking and Interoperability Function (IIF) provides a signaling control interface between3ANSI-41 and GSM network entities. This interface is provided to enable service access when a4subscriber operates in a foreign network whose signaling protocol is different from the home5network's protocol. Figure 1 below depicts the family of network interfaces provided by the IIF in6interconnecting networks.7
Figure 1: IIF Reference Model8
5.2 Description9
GSM and ANSI-41 network entities rely on different network signaling protocols to support10mobility management and service realization. When a subscriber to a network supported by11ANSI-41 network entities (i.e., a native TDMA or CDMA subscriber) accesses a visited GSM12network, the visited network uses GSM Mobile Application Part (MAP) signaling, while the13controlling home network uses ANSI-41 MAP signaling. Likewise, when a native GSM subscriber14accesses a visited ANSI-41 based network, the visited network uses ANSI-41 MAP signaling,15while the controlling home network uses GSM MAP signaling.16To support “seamless” interoperability of service between GSM and ANSI-41 network entities, an17interworking and interoperability function (IIF) or gateway shall map messages between GSM and18ANSI-41 MAP. ANSI-41 MAP also supports analog AMPS capability, which is defined as a subset19of ANSI-136.20In most cases, the IIF interprets a signaling message in one protocol and converts it to the21equivalent signaling message in the other network protocol.22
AC
MSC
HLR
VLR
MC
H
TIA/EIA-41Network Entities
GSMNetwork Entities
AuC
MSC
HLR
VLR
H
IIF
SMS-SC
D
D
D
D
EQ
N
EE
SMS-IWMSC
SMS-GMSCE
SGSN
Gr
X.S0023
0-13
5.2.1 Provisioned Subscriber Data1
The IIF does not duplicate the subscriber’s existing HLR, but provides a gateway to any visited2network that uses a foreign MAP protocol. The original source of subscription data remains in the3home network’s HLR. Most of this data shall not reside in the IIF, but shall be dynamically4converted and translated between GSM and ANSI-41 MAP messages as needed.5Nevertheless, some basic subscriber identity information needs to be provisioned in the IIF to6support this mapping process, such as:7
• International Mobile Subscriber Identity (IMSI)8
• Mobile Identification Number (MIN)9
• Electronic Serial Number (ESN)10
• Terminal type11
• Network Access Mode (non-GPRS, GPRS or both)12
Authentication and encryption services are critical functions that shall be supported with network13interoperability. These capabilities are managed in both GSM and ANSI-41 networks by the14Authentication Center (AuC or AC), which can be physically separated from the associated HLR15or integrated with it. Different authentication processes and algorithms are defined for GSM and16ANSI-41. Therefore, subscriber specific authentication data shall be provisioned and maintained17on both a GSM AuC and ANSI-41 AC, in order to support service on either network.18Subscriber data that needs to be maintained for ANSI-41 networks includes:19
• Ki (GSM subscriber authentication key)20
• Triplets or groups of Kc (cipher key), CKSN (cipher key sequence number), and SRES21(signed response) for GSM based authentication and ciphering22
• A-key (AMPS/ANSI-136 or IS-95 authentication key)23
• SSD-A (AMPS/ANSI-136 or IS-95 shared secret data for authentication)24
• SSD-B (AMPS/ANSI-136 or IS-95 shared secret data used for generated signaling25message encryption (SME) and voice privacy (VP) masks: the26CDMAPrivateLongCodeMask or the TDMA VoicePrivacyMask)27
The foreign mode Authentication Center can be integrated into the IIF gateway or implemented28as a separate network element.29Optionally, IIF may support one-way roaming only from CDMA to GSM network. In this case no30data is provisioned at IIF level and ANSI-41 HLR/AC must be compliant with TIA/EIA -868 [11].31All the changes are made on the assumption the new requirements for UIM/handsets are32working.33
34The following items are basic assumptions on which the optional one-way roaming scenario is35based:36
37• The IIF is not provisioned with any subscriber data.38
• There is no subscriber specific data stored in the IIF.39
• The Home System is enhanced to support ANSI -41-to-GSM roaming.40
X.S0023
0-14
• The ANSI-41 Home System has enhanced authentication capabilities to support roaming1of subscribers to GSM systems. Subscribers may be using multi-mode mobile stations2capable of roaming into a GSM system or UIMs that are inserted into GSM terminal3equipment. A valid SSD is generated in the UIM before the user can roam to a GSM4system5
• A valid SSD value must be generated in the UIM (or multi-mode MS) before the6subscriber can roam into a GSM system. The IIF functions as a VLR in its interaction with7the ANSI -41 Home System8
• The ANSI-41 AC shares SSD with the IIF for subscribers roaming in a GSM network. The9IIF generates the triplets (RAND, XRES, KC) used by the GSM system. The triplet10generation function is specified in section 2.2.4.1 of “Enhanced Cryptographic Algorithms,11Revision B.”12
• After the subscriber is registered in a GSM system, the IIF reports authentication failures13to the ANSI-41 system using the AuthenticationFailureReport operation. SSD is shared14with the IIF until registration in the GSM system is canceled. The ANSI -41 AC/HLR can15cancel registration using the RegistrationCancellation operation.16
• The IIF shall remove the subscriber’s SSD when registration in the GSM system is17canceled. SSD Update cannot be performed when the MS is roaming in a GSM system18
• A new SystemCapabilities parameter value shall be defined to indicate a GSM system19
• A SystemCapabilities parameter value indicating GSM system shall be used by the IIF to20indicate that the Serving network is using GSM authentication and privacy procedures.21This indicates that22
• SSD Update cannot be performed. It also indicates that the ESN sent to the ANSI-4123home system was not received from the MS. The IIF functions as a GSM HLR/AC in its24interactions with the GSM system25
• The IIF provides the GSM triplets needed for authentication and privacy in the GSM26system. The27
• IIF generates triplets using the SSD value stored in the UIM (or multi-mode MS).28
• When roaming in a GSM system, the UIM uses the “authentication” algorithm supported29by the IIF30
• When roaming is a GSM system, the UIM (or multi-mode MS) must use an authentication31algorithm supported by the IIF for the computation of the cipher key and the response to32the random challenge.33
• The ANSI-41 home system is expected to update SSD when the MS returns to an34ANSI–41 system35
• The subscriber’s SSD should be updated when the user returns to an ANSI-41 system.36
• The IIF shall prevent disclosure of SSD values received from ANSI-41 systems37
• The IIF shall provide a secure method of storing SSD values received from ANSI-4138systems.39
• The SSD values shall not be disclosed nor transmitted to any other network entity.40
X.S0023
0-15
• The IIF shall be able to request the MS’s ESN in the AuthenticationRequest INVOKE sent1to the home ANSI-41 system2
3To support GPRS service in GSM Foreign Mode, GPRS specific subscriber data also needs to be4provisioned in the IIF such as :5
• GGSN-list (GGSN Number and optional IP address)6
• PDP Type7
• PDP Address (if dynamic addressing is not allowed)8
• Quality of Service Subscribed9
5.3 Interworking for Network Interfaces10
This following describes the individual network interfaces for which interoperability is provided by11the IIF. For each particular interoperability function and interface interworking, the IIF12simultaneously emulates a network element using foreign protocol messaging and a13corresponding network element using native protocol messaging. The emulation functions in the14IIF conform to existing ANSI-41 and GSM protocols when communicating over the external15interfaces.16The following figures depict the emulated network elements within the IIF using dashed lines. The17dashed lines connecting emulated network elements within the IIF represent internal, conversion18or mapping interfaces. All solid connecting lines depict standard ANSI-41 or GSM interfaces19based on existing protocols.20The arrow above each figure represents information exchange for the top half of the figure, while21the arrow below each figure represents information exchange for the bottom half of the figure.22
X.S0023
0-16
5.3.1 HLR - VLR Interface1
The IIF provides an interface between the subscriber's HLR and any VLR which uses a foreign2network signaling protocol. This interworking is provided over the interface reference "D" depicted3in the network reference model. Figure 2 below depicts the interworking and control interface4provided by the IIF in this case.5
ANSI-41HLR
TIA/EIA-41Network Entities
GSMNetwork Entities
D
D
D
D
ANSI-41 subscriber roamingto GSM network
GSM subscriber roamingto ANSI-41 network
IIF
ANSI-41VLR
ANSI-41VLR
ANSI-41HLR
GSMHLR
GSMVLR
GSMHLR
GSMVLR
6Figure 2: HLR - VLR Interface7
5.3.1.1 ANSI-136 Foreign Mode Implementation for GSM Subscriber8
When a GSM native subscriber operates in ANSI-136 foreign mode, the mobile station shall use9the ANSI-136 air interface. The interoperability gateway or IIF shall provide both ANSI-41 HLR10and GSM VLR emulation to allow the subscriber to automatically register and obtain service. To11the visited ANSI-41 network, the subscriber appears to register with the IIF, emulating an12ANSI-41 HLR. This emulated ANSI-41 HLR acts as a limited proxy for the actual GSM HLR, with13the true GSM HLR retaining ultimate control. At the same time, to the home GSM network, the14subscriber appears to register from the IIF, emulating a GSM VLR. The IIF links ANSI-41 MAP15operations and data to the equivalent GSM MAP operations and data, and vice versa, in order to16support interoperability.17To support ANSI-136 foreign mode operation, an ANSI-136 Authentication Center (AC) can be18integrated into the IIF gateway or implemented as a separate network element.19
5.3.1.2 GSM Foreign Mode Implementation for ANSI-136 Subscriber20
Similarly, when an ANSI-136 native subscriber operates in GSM foreign mode, the mobile station21shall use the GSM air interface. The interoperability gateway or IIF shall provide both GSM HLR22and ANSI-41 VLR emulation to allow the subscriber to automatically register and obtain service.23To the visited GSM network, the subscriber appears to register with the IIF, emulating a GSM24HLR. This emulated GSM HLR acts as a limited proxy for the actual ANSI-41 HLR, with the true25ANSI-41 HLR retaining ultimate control. At the same time, to the home ANSI-136 network, the26subscriber appears to register from the IIF, emulating an ANSI-136 VLR. The IIF links GSM MAP27
X.S0023
0-17
operations and data to the equivalent ANSI-41 MAP operations and data, and vice versa, in order1to support interoperability.2To support GSM foreign mode operation, a GSM Authentication Center (AuC) can be integrated3into the IIF gateway or implemented as a separate network element.4
5.3.1.3 CDMA Foreign Mode Implementation for GSM Subscriber5When a GSM native subscriber operates in IS-95 foreign mode, the mobile station shall use the6CDMA air interface. The interoperability gateway or IIF shall provide both ANSI-41 HLR and GSM7VLR emulation to allow the subscriber to automatically register and obtain service. To the visited8ANSI-41 network, the subscriber appears to register with the IIF, emulating an ANSI-41 HLR.9This emulated ANSI-41 HLR acts as a limited proxy for the actual GSM HLR, with the true GSM10HLR retaining ultimate control. At the same time, to the home GSM network, the subscriber11appears to register from the IIF, emulating a GSM VLR. The IIF links ANSI-41 MAP operations12and data to the GSM MAP operations and data, and vice versa, in order to support13interoperability.14
5.3.1.4 GSM Foreign Mode Implementation for CDMA Subscriber15Similarly, when an CDMA native subscriber operates in GSM foreign mode, the mobile station16shall use the GSM air interface. The interoperability gateway or IIF shall provide both GSM HLR17and ANSI-41 VLR emulation to allow the subscriber to automatically register and obtain service.18To the visited GSM network, the subscriber appears to register with the IIF, emulating a GSM19HLR. This emulated GSM HLR acts as a limited proxy for the actual ANSI-41 HLR, with the true20ANSI-41 HLR retaining ultimate control. At the same time, to the home CDMA network, the21subscriber appears to register from the IIF, emulating an CDMA VLR. The IIF links GSM MAP22operations and data to the ANSI-41 MAP operations and data, and vice versa, in order to support23interoperability.24
X.S0023
0-18
5.3.2 Originating / Gateway MSC - Serving MSC Interface1
The IIF provides a MAP interface between the subscriber's originating or gateway MSC to a2serving MSC which uses a foreign network signaling protocol. This interworking is provided over3the interface reference "E" depicted in the network reference model. In this case, no ISUP or MF4signaling is supported over this interface. Figure 3 below depicts the interworking and control5interface provided by the IIF in this case.6This interface is key to supporting optimal routing for late call forwarding, where the serving MSC7wishes to signal back to the originating or gateway MSC in order to request forwarding of the call.8In order to support optimal routing for late call forwarding, the IIF provides originating or gateway9MSC emulation.10
TIA/EIA-41Network Entities
GSMNetwork Entities
E
E
E
E
ANSI-41 subscriber roamingto GSM network
GSM subscriber roamingto ANSI-41 network
IIF
ANSI-41Originating
MSC
ANSI-41Serving
MSC
ANSI-41Serving
MSC
ANSI-41Originating
MSC
GSMGateway
MSC
GSMServing
MSC
GSMServing
MSC
GSMGateway
MSC
11Figure 3: Originating / Gateway MSC - Serving MSC Interface12
X.S0023
0-19
5.3.3 MC / SMS-SC - Serving MSC Interface1
The IIF provides an interface from the subscriber's short message service message center (MC /2SMS-SC) to a serving MSC which uses a foreign network signaling protocol. This interworking is3provided over the interface references "Q" and "E" depicted in the network reference model. In4the case of ANSI-41 messaging, the MC has a direct "Q" interface to the serving MSC. In the5case of GSM messaging, the SMS-SC interfaces with the serving MSC via the SMS Interworking6MSC (SMS-IWMSC) or the SMS Gateway MSC (SMS-GMSC) over the "E" interface. Figure 47below depicts the interworking and control interface provided by the IIF in this case.8
TIA/EIA-41Network Entities
GSMNetwork Entities
ANSI-41 subscriber roamingto GSM network
GSM subscriber roamingto ANSI-41 network
IIF
GSMSMS-
IWMSC
GSMSMS-GMSC
GSMSMS-SC
GSMSMS-SC
GSMSMS-
IWMSC
GSMSMS-GMSC
ANSI-41Serving
MSC
ANSI-41MC
ANSI-41MC
ANSI-41Serving
MSC GSMServing
MSC
GSMServing
MSC
Q
Q
E
E
E
E
9Figure 4: MC / SMS-SC - Serving MSC Interface10
5.3.3.1 ANSI-41 Foreign Mode Implementation for GSM Subscriber11
For short message service (SMS) interoperability, the IIF shall provide ANSI-41 Message Center12(MC) emulation, acting as a limited proxy for the subscriber’s GSM Short Message Service13Center (SMS-SC). The IIF links GSM MAP operations and data to the equivalent ANSI-41 MAP14operations and data, and vice versa.15
5.3.3.2 GSM Foreign Mode Implementation for ANSI-41 Subscriber16
For SMS interoperability, the IIF shall provide GSM SMS-SC emulation, as well as SMS-GMSC17or SMS-IWMSC emulation, acting as a limited proxy for the subscriber’s ANSI-41 MC. The IIF18links ANSI-41 MAP operations and data to the equivalent GSM MAP operations and data, and19vice versa. In some cases, the IIF may need to originate short messages in order to support20interoperability.21
X.S0023
0-20
5.3.4 HLR – SGSN Interface1
The IIF provides an interface between the subscriber's HLR and any SGSN which uses a foreign2network signaling protocol. This interworking is provided over the interface reference "Gr"3depicted in the network reference model. Figure 5 below depicts the interworking and control4interface provided by the IIF in this case.5
ANSI-41 Subscriber roamingto GPRS network
IIF
SGSNGSMHLR
ANSI-41VLR
ANSI-41HLR
GrD
TIA/EIA-41Network Entities
GSM NetworkEntities
6Figure 5: HLR- SGSN Interface7
5.3.4.1 GPRS in GSM Foreign Mode Implementation for ANSI-41 Subscriber8
When an ANSI-41 native subscriber operates GPRS in GSM foreign mode, the mobile station9shall use the GSM air interface. The interoperability gateway or IIF shall provide both GSM HLR10and ANSI-41 VLR emulation to allow the subscriber to automatically register and obtain service.11To the visited GSM network, the subscriber appears to register with the IIF, emulating a GSM12HLR. This emulated GSM HLR acts as a limited proxy for the actual ANSI-41 HLR. At the same13time, to the home ANSI-41 network, the subscriber appears to register from the IIF, emulating an14ANSI-41 VLR. The IIF links GSM MAP operations and data to the equivalent ANSI-41 MAP15operations and data, and vice versa, in order to support interoperability.16To support GPRS in GSM foreign mode operation, a GSM Authentication Center (AuC) can be17integrated into the IIF gateway or implemented as a separate network element.18
X.S0023
0-21
5.4 IIF Implementation Alternatives1
There are four alternatives for the implementation of the IIF functional element with respect to the2network reference model and the network entities that are served. See “5 IIF Reference Model3and Description” for applicable interfaces.4
5.4.1 IIF Resides within a GSM Network Entity5
The IIF may reside entirely inside an existing GSM network entity as a separate functional6element. Each of the interfaces can be supported with this implementation alternative.7
GSMNetworkElement
TIA/EIA-41NetworkElement
IIF
8
Figure 6: IIF Resides within GSM Network Element9
5.4.2 IIF Resides within ANSI-41 Network Entity10
The IIF may reside entirely inside an existing ANSI-41 network entity as a separate functional11element. Each of the interfaces can be supported with this implementation alternative.12
GSMNetworkElement
TIA/EIA-41NetworkElement
IIF
13
Figure 7: IIF Resides within ANSI-41 Network Element14
X.S0023
0-22
5.4.3 IIF Resides within External Network Element1
The IIF may reside external to any existing ANSI-41 or GSM network entity as a separate network2element. Each of the interfaces can be supported with this implementation alternative.3
GSMNetworkElement
TIA/EIA-41NetworkElement
ExternalNetworkElement
IIF
4
Figure 8: IIF Resides within External Network Element5
5.4.4 IIF Resides within Both ANSI-41 and GSM Network Entities6
Finally, the IIF may reside within both existing ANSI-41 and GSM network entities at the same7time. In this case, each individual subscriber is likely to be served by one particular IIF, although8the use of multiple IIFs per subscriber is possible. Again, each of the interfaces can be supported9with this implementation alternative. While multiple IIFs can support one particular subscriber,10each network interworking function would be supported by one specific IIF implementation.11
GSMNetworkElement
TIA/EIA-41NetworkElement
IIF IIF
12
Figure 9: IIF Resides within both ANSI-41 and GSM Network Elements13
14
X.S0023
1-i
NNNeeetttwwwooorrrkkk IIInnnttteeerrrwwwooorrrkkkiiinnnggg BBBeeetttwwweeeeeennn GGGSSSMMM MMMAAAPPP aaannnddd TTTIIIAAA---444111 MMMAAAPPP;;;1
RRReeevvviiisssiiiooonnn BBB ––– CCCDDDMMMAAA222000000000 SSSuuuppppppooorrrttt2
VVVooollluuummmeee 111 ––– SSSeeerrrvvviiiccceee DDDeeessscccrrriiippptttiiiooonnnsss3
(((RRReeevvviiisssiiiooonnn ooofff JJJ---SSSTTTDDD---000333888---AAA VVVooollluuummmeee 111)))4
Abstract5
This volume is based on ANSI-664 [15] and GSM stage 1’s (see GSM 02-series e.g., GSM 02.04,6etc. in the References section). Some modifications (primarily simplifications) were made for the7purpose of specifying the degree of interoperability desired. ANSI-664 services and GSM services do8not necessarily align.9
X.S0023
1-ii
ContentsAbstract........................................................................................................................................................... iContents ........................................................................................................................................................ iiList of Tables .................................................................................................................................................iiiList of Figures............................................................................................................................................... ivForeword........................................................................................................................................................ v1 Introduction .............................................................................................................................................1
1.1 General 11.2 Purpose 11.3 Scope 1
2 Stage 1 Service Descriptions.................................................................................................................22.1 Authentication ...........................................................................................................................22.2 Call Forwarding.........................................................................................................................8
2.3 Optimal Routing for Late Call Forwarding .............................................................................362.4 Call Waiting (CW) ...................................................................................................................402.5 Three-Way Calling (3WC) and Multi-Party (MPTY) .............................................................512.6 Calling Number / Line Identification Presentation .................................................................632.7 Call Barring (CB) and Operator Determined Barring (ODB).................................................682.8 Short Message Teleservice Support (ANSI-41 Networks) ...................................................762.9 Message Waiting Notification.................................................................................................832.10 GPRS in GSM Foreign mode.................................................................................................88
X.S0023
1-iii
List of Tables
Table 1: CW Subscription Options ............................................................................................................. 40
Table 2: 2-Way State for Call Waiting....................................................................................................... 43
Table 3: 2-Way Notification State for Call Waiting ................................................................................... 44
Table 4: 2-Way CW State for Call Waiting................................................................................................. 45
Table 5: ANSI-41 Foreign Mode Interoperability for Barring of Outgoing Calls ....................................... 69
Table 6: GSM Foreign Mode Interoperability for Outgoing Call Restrictions ........................................... 69
Table 7: Call Barring Activation Options .................................................................................................... 70
Table 8: Call Barring Deactivation Options................................................................................................ 71
X.S0023
1-iv
List of FiguresThere are no figures in this volume.
X.S0023
1-v
Foreword1
This foreword is not part of this standard.2
This standard addresses the interworking and interoperability between ANSI-41 MAP and GSM3based networks in the support of subscribers roaming between networks. The objective of the4standard is to achieve fully automatic, two-way interoperability between the heterogeneous networks.5Services supported by this standard are described along with the associated information flows and6message mappings. However, not all services and associated capabilities of ANSI-41 MAP and GSM7MAP are supported by this standard. In general the attempt has been to focus on the key subscriber8services needed in the market.9
The focus of the first release of this standard was on common GSM and ANSI-136 TDMA services10and associated network signaling (i.e. ANSI-41 MAP and GSM MAP). A pre-requisite for this11interoperability is multi-mode mobile stations with an enhanced SIM card for roaming between ANSI-12136, GSM, and AMPS networks.13
The first release of the standard did not define or require changes to existing ANSI-41 MAP or GSM14MAP to achieve the described interworking and interoperability. However, due to differences between15the services and associated capabilities of the MAP protocols, complete and fully transparent16interoperability may not have been achieved for some services. Future releases of this standard may17require changes to ANSI-41 MAP, GSM MAP and the associated services to achieve full18transparency while roaming between the different networks.19
Aspects of TIA/EIA-136 Rev C have been incorporated into this standard.20
Revision A adds the capability of getting GPRS services when roaming in GSM Foreign Mode.21
Revision B adds roaming between GSM and CDMA systems.22
X.S0023
1-1
1 Introduction1
1.1 General2
When a subscriber to one network type (e.g., ANSI-41) roams to a network of another type (e.g.,3GSM), interworking and interoperability functions are required to support roaming and enable service.4This standard describes an Interworking and Interoperability Function (IIF) to support this cross-5technology roaming between ANSI-41 and GSM networks. The IIF supports a multi-mode mobile6station with a removable Subscriber Identity Module (SIM). The standard also defines the required7network message mappings between ANSI-41 MAP and GSM MAP to support the mobile terminal8and associated services.9
This standard includes the support of cross-technology roaming from an ANSI-41 based network to a10GPRS network. The GPRS network may be coupled with a GSM network. This feature requires11enhancement to the Interworking and Interoperability Function (IIF) which supports a multi-mode12mobile station and Subscriber Identity Module (SIM) with GPRS functionality.13
1.2 Purpose14
The purpose for this standard is to define and describe the functions necessary for roaming between15ANSI-41 MAP and GSM MAP based networks in the support of roaming subscribers. This includes a16capability to allow a subscriber to an ANSI-41 based network (e.g., an ANSI-136 or CDMA native17subscriber) with a mobile terminal supporting GPRS service to roam to a GPRS network in GSM18Foreign Mode.19
1.3 Scope20
The scope of this standard are the services, information flows, and message mappings which require21interworking and interoperability functional specifications to support roaming between ANSI-41 MAP22and GSM MAP networks.23
The scope of this volume is a high level (stage 1) description of the services and functionality required24to support GSM and ANSI-41 network interoperability. In particular, when in foreign mode (roaming in25non-native mode technology), subscribers are able to:26
roam and register (with authentication);27
originate and terminate calls;28
have the following supplementary services operate:29
- Call Forwarding,30
- Call Waiting,31
- Calling Number Identification Presentation - Line Identification Presentation,32
- Call Barring, and33
- GSM Multi-Party - ANSI-41 3-way Calling and Conference;34
have Short Message Service access and Message Waiting Notification;35
have Late Call Forwarding optimally routed; and36
have GPRS service in GSM Foreign Mode.37
38
X.S0023
1-2
2 Stage 1 Service Descriptions1
When in foreign mode (e.g., GSM or ANSI-41 subscribers accessing respectively ANSI-41 or GSM2networks), subscribers are able:3
to roam and register (with authentication)4
to originate and terminate calls5
to have the following supplementary services operate:6
o Call Forwarding,7
o Call Waiting, Calling Number/Line Identification Presentation,8
o Call Barring, and9
o GSM Multi-Party - ANSI-41 3-way Calling and Conference;10
to have short message service and Message Waiting Notification; and11
to have late call forwarding optimally routed.12
2.1 Authentication13
Authentication defines the ability for a wireless network to confirm the identity of a mobile station at14the time of connection, and to ensure the validity of this identity during the complete connection time.15This is achieved through the use of cryptographic schemes based on secret key algorithms.16
2.1.1 General Description17
The authentication procedure starts based on network events received by the mobile station. These18events include mobile station origination, termination, registration and R-DATA messages in ANSI-4119TDMA or CDMA. These events are dependent of the technology used and are different in GSM and20ANSI-41. The authentication procedure involves an authentication center on the network side and an21authentication module in the mobile station. It is initiated by a random number sent from the22authentication center to the authentication module. The authentication module uses this random23value and a combination of secret data and internal values to create an authentication value and a24key that is optionally used for encryption. This authentication value is sent back to the authentication25center, which verifies its validity by computing it again based on the same input. A successful26outcome of the authentication process occurs only when it can be demonstrated that the27authentication module and the authentication center possess identical sets of secret values.28
Optionally, IIF may support one-way roaming only from CDMA to GSM network. In this case since no29data is provisioned at IIF level, IIF must generate the GSM triplets using as input the authentication30parameters returned by ANSI-41 HLR/AC, and ANSI-41 HLR/AC must be compliant with PN-4925 (to31be published as TIA/EIA-868 28]. All the changes are made on the assumption the new requirements32for UIM/handsets are working.33
2.1.1.1 Applicability to Telecommunications Services34
Not identified.35
X.S0023
1-3
2.1.2 Normal Procedures With Successful Outcome1
In ANSI-41 native and foreign mode, the authentication procedure is done according to the2procedures defined in TIA/EIA-136-510 [17].3
In GSM native and foreign mode, the authentication procedure is done according to the procedures4defined in GSM 02.09 [19].5
ANSI-136 Mode6
The ANSI-136 authentication module is defined by the ANSI-136 directory. It holds the secret data7and internal values used during the authentication process.8
The secret data used in the ANSI-136 authentication process is the shared secret data (SSD). The9internal values used within the ANSI-136 authentication process are the ESN, the MIN1 and the10MIN2.11
GSM Mode12
The GSM authentication module is defined by the GSM directory in the SIM. The SIM card can13support multiple GSM subscriptions and each one has its own authentication module.14
The secret data used in the GSM authentication process is the Ki. There is no internal data used in15the GSM authentication process.16
ANSI-41 Mode17
The ANSI-41 authentication module is defined by the air-interface-specific directory in the mobile18station. The data used for authentication is as defined by the Common Cryptographic Algorithm19(CAVE) The ANSI-41 mode includes the ANSI-136 Mode described above.20
2.1.2.1 Authorization (or Provision)21
In GSM mode, the secret data (Ki) is stored in advance in the network’s Authentication Center (AuC)22as well as the SIM’s authentication module at the time of personalization of the SIM. This secret data23on the SIM cannot be modified after the issuance of the SIM.24
In ANSI mode, the secret data (A-key) is stored in advance in the network’s Authentication Center25(AC) as well as the mobile’s station authentication module at the time of provisioning. This secret data26maybe overwritten with a new value via reprovisioning or over the air parameter administration for27CDMA28
In ANSI-136, the shared secret data (SSD) is generated from a root secret data (A-Key). This root29secret data is stored in advance in the authentication module and can be modified after issuance. The30generation of the secret data is done by the authentication center issuing an SSD UPDATE request31with the appropriate parameters.32
2.1.2.2 De-Authorization (or Withdrawal)33
The de-authorization is done at the Authentication Center.34
2.1.2.3 Registration35
None identified.36
2.1.2.4 De-Registration (or Erasure)37
None identified.38
X.S0023
1-4
2.1.2.5 Activation1
Activation is performed by the operator or serving system.2
2.1.2.6 De-Activation3
De-activation is performed by the operator or serving system.4
2.1.2.7 Invocation5
The authentication function is invoked in the mobile station by selecting the appropriate directory6(GSM or ANSI-41) on the authentication module and sending the appropriate command (RUN AUTH7ALGO or RUN CAVE), with the appropriate parameters (random value, option flag, internal values).8The authentication function is invoked in the network by the receipt of an authentication message9from the mobile station.10
2.1.2.8 Normal Operation with Successful Outcome11
If the Authentication Signature result calculated by the mobile station and sent to the BMI (Base12Station, Mobile Switching Center, Interworking Function) matches the result calculated by the BMI13then call processing and feature access is allowed by the BMI.14
2.1.3 Exception Procedures or Unsuccessful Outcome15
In the event that the mobile station cannot provide the correct Authentication Signature result to the16BMI then call processing and feature access may be denied by the BMI.17
2.1.3.1 Registration18
None identified.19
2.1.3.2 De-Registration / Erasure20
None identified.21
2.1.3.3 Activation22
None identified.23
2.1.3.4 De-Activation24
None identified.25
2.1.3.5 Invocation26
None identified.27
2.1.3.6 Exceptions While Roaming28
None identified.29
2.1.3.7 Exceptions During Intersystem Handoff30
None identified.31
2.1.4 Alternate Procedures32
None identified.33
X.S0023
1-5
2.1.5 Interactions With Other Features and Services1
2.1.5.1 Advice of charge (AoC)2
None identified.3
2.1.5.2 Barring of All Outgoing Calls (BAOC)4
None identified.5
2.1.5.3 Barring of Outgoing International Calls (BOIC)6
None identified.7
2.1.5.4 Barring of Outgoing International Calls except those directed to the Home PLMN8(BOIC-exHC)9
None identified.10
2.1.5.5 Barring of All Incoming Calls (BAIC)11
None identified.12
2.1.5.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam)13
None identified.14
2.1.5.7 Call Delivery (CD)15
If the Authentication Signature result at the mobile station does not match that of the BMI then Call16Delivery shall not be allowed.17
2.1.5.8 Call Forwarding—Busy (CFB)18
None identified.19
2.1.5.9 Call Forwarding—Default (CFD)20
None identified.21
2.1.5.10 Call Forwarding—No Answer / No Reply (CFNA / CFNRy)22
None identified.23
2.1.5.11 Call Forwarding—Not Reachable (CFNRc)24
None identified.25
2.1.5.12 Call Forwarding—Unconditional (CFU)26
None identified.27
2.1.5.13 Call Transfer (CT)28
None identified.29
2.1.5.14 Call Waiting / Call Hold (CW / HOLD)30
None identified.31
2.1.5.15 Calling Number / Line Identification Presentation (CNIP / CLIP)32
None identified.33
X.S0023
1-6
2.1.5.16 Calling Number / Line Identification Restriction (CNIR / CLIR)1
None identified.2
2.1.5.17 Calling Name Presentation (CNAP)3
None identified.4
2.1.5.18 Calling Name Restriction (CNAR)5
None identified.6
2.1.5.19 Closed User Group (CUG)7
None identified.8
2.1.5.20 Conference Calling / Multi Party Service (CC / MPTY)9
A special challenge shall be made to the mobile station by the BMI in order to activate this feature. If10the Authentication Signature result at the mobile station does not match that of the BMI then this11feature shall not be allowed.12
2.1.5.21 Do Not Disturb (DND)13
None identified.14
2.1.5.22 Emergency Services (Future)15
None identified.16
2.1.5.23 Flexible Alerting (FA)17
None identified.18
2.1.5.24 Message Waiting Notification (MWN)19
None identified.20
2.1.5.25 Mobile Access Hunting (MAH)21
None identified.22
2.1.5.26 Password Call Acceptance (PCA)23
None identified.24
2.1.5.27 Preferred Language (PL)25
None identified.26
2.1.5.28 Priority Access and Channel Assignment (PACA)27
None identified.28
2.1.5.29 Remote Feature Control (RFC)29
None identified.30
2.1.5.30 Selective Call Acceptance (SCA)31
None identified.32
2.1.5.31 Subscriber PIN Access (SPINA)33
The Authentication Feature shall take precedence over the SPINA feature.34
X.S0023
1-7
2.1.5.32 Subscriber PIN Intercept (SPINI)1
The Authentication Feature shall take precedence over the SPINI feature.2
2.1.5.33 Three-Way Calling / Multi Party Service (3WC / MPTY)3
A special challenge shall be made to the mobile station by the BMI in order to activate this feature. If4the Authentication Signature result at the mobile station does not match that of the BMI then this5feature shall not be allowed.6
2.1.5.34 Voice Message Retrieval (VMR)7
If this feature requires the mobile station to originate a call from the mobile station and the8Authentication Signature result at the mobile station does not match that of the BMI then this feature9shall not be allowed.10
2.1.5.35 Voice Privacy (VP)11
The Voice Privacy elements (e.g., for ANSI-41 TDMA or CDMA) are derived from the same secret12A–Key as for the Authentication algorithm. If the HLR/AC for the mobile subscriber does not have13knowledge of this information it shall not be able to activate the Voice Privacy feature.14
X.S0023
1-8
2.2 Call Forwarding1
2
2.2.1 General Description3
Call Forwarding, permits a called subscriber to have the system send incoming calls addressed to the4called subscriber’s Directory Number to another Directory Number (forward-to number) under certain5conditions (e.g., busy, not reachable, or no reply).6
GSM 02.82 [24] defines the following call forwarding supplementary services:7
Call forwarding unconditional (CFU);8
Call forwarding on mobile subscriber busy (CFB);9
Call forwarding on no reply (CFNRy);10
Call forwarding on mobile subscriber not reachable (CFNRc).11
ANSI-664 [15] defines the following call forwarding supplementary services:12
Call forwarding – Unconditional (CFU)13
Call forwarding – Busy (CFB)14
Call forwarding - No answer (CFNA)15
Call forwarding – Default (CFD)16
X.S0023
1-9
2.2.2 Call Forwarding Unconditional (CFU)1
2
2.2.2.1 General Description3
Call Forwarding—Unconditional (CFU) permits a called subscriber to send incoming calls addressed4to the called subscriber’s Directory Number to another Directory Number (forward-to number) or to5the called subscriber’s designated voice mail box.6
2.2.2.1.1 Applicability to Telecommunications Services7
CFU is applicable to voice telecommunication services.8
2.2.2.2 Normal Procedures With Successful Outcome9
10
2.2.2.2.1 Authorization (or Provision)11
CFU may be generally available or may be provided after pre-arrangement with the service provider.12The authorization (provision) may have subscription options. These options are defined in either GSM1302.82 [24] (i.e., GSM native mode subscribers) or ANSI-664 [15] (e.g., ANSI-41 TDMA or CDMA14native mode subscribers). Authorization or Provisioning may occur while operating in foreign mode.15
2.2.2.2.2 De-Authorization (or Withdrawal)16
CFU may be withdrawn by the service provider, at the subscriber’s request or for administrative17reasons. De-authorization or withdrawal may occur while operating in foreign mode.18
2.2.2.2.3 Registration19
If the subscriber is authorized for Fixed Registration, the forward-to number shall be registered upon20authorization (provision). Mobile stations operating in foreign mode may attempt to perform21registration procedures normally supported in native mode.22
The forward-to-number may be registered by the service provider upon authorization (provision) for23Variable Registration subscribers24
GSM foreign mode: A forward-to-number may be registered by a Variable Registration authorized25subscriber specifying the CFU registration feature code and a forward-to number termination address26as in:27
*FC + termination address + SEND .28
Alternatively, if the mobile station offers menu driven control of registration, the mobile station is29expected to generate the equivalent GSM functional signaling towards the network.30
ANSI-41 foreign mode: Registration can take place with an appropriate control procedure by the31subscriber, per GSM 02.30 [20]. In ANSI-41 foreign mode, if the equivalent GSM feature code (MMI)32is manually entered by the user, the mobile station is expected to issue the relevant ANSI-41 feature33code entry.34
Alternatively, if the mobile station offers menu driven control of registration, the mobile station is35expected to generate the equivalent ANSI-41 feature code entry and resulting call origination based36on the menu driven entry.37
If the registration is accepted, the system shall indicate success using either GSM or ANSI-4138signaling techniques depending on the mode of operation.39
X.S0023
1-10
2.2.2.2.4 De-Registration (or Erasure)1
Mobile stations operating in foreign mode may attempt to perform De-Registration or Erasure2procedures normally supported in native mode.3
A forward-to-number may be de-registered upon de-activation (at the home service provider option).4
GSM foreign mode: If the de-registration is to be separate from de-activation, the de-registration5feature code must be distinct from the corresponding de-activation feature code.6
GSM foreign mode: CFU may be de-registered by a Variable Registration authorized subscriber7specifying the CFU de-registration feature code, as in:8
*FC0 + SEND .9
Alternatively, if the mobile station offers menu driven control of registration, the mobile station is10expected to generate the equivalent GSM functional signaling towards the network.11
ANSI-41 foreign mode: The subscriber can specifically erase a previous registration with an12appropriate control procedure, per GSM 02.30 [20]. In ANSI-41 foreign mode, if the equivalent GSM13feature code (MMI) is manually entered by the user, the mobile station is expected to issue the14necessary ANSI-41 feature code to the network.15
CFU shall be de-registered upon de-authorization or withdrawal.16
2.2.2.2.5 Activation17
Mobile stations operating in foreign mode may attempt to perform Activation procedures normally18supported in native mode.19
If the subscriber is authorized for Permanent Activation, CFU shall be activated upon authorization20(provision).21
CFU may be activated upon authorization or registration for Demand Activation authorized22subscribers. CFU may be activated upon registration for Variable Registration authorized subscribers.23
GSM foreign mode: A previously registered forward-to-number may be activated by a Demand24Activation authorized subscriber specifying a CFU activation feature code, as in:25
*FC + SEND .26
Alternatively, if the mobile station offers menu driven control of activation, the mobile station is27expected to generate the equivalent GSM functional signaling.28
ANSI-41 foreign mode: The MS shall be allowed to activate CFU by a control procedure (e.g., using29the MMI command described in GSM 02.30 [20]). In ANSI-41 foreign mode, if the equivalent GSM30feature code (MMI) is manually entered by the user, the mobile station is expected to issue the31necessary ANSI-41 feature code to the network.32
If the activation is accepted, the system shall indicate success using either GSM or ANSI-41 signaling33techniques depending on the mode of operation.34
The serving system may provide a courtesy call to the forward-to number shortly after this feature is35activated permitting the subscriber to verify the validity of the forward-to-number.36
X.S0023
1-11
2.2.2.2.6 De-Activation1
GSM foreign mode: CFU may be de-activated by a Demand Activation authorized subscriber2specifying the CFB de-activation feature code, as in:3
*FC0 + SEND .4
Alternatively, if the mobile station offers menu driven control of de-activation, the mobile station is5expected to generate the equivalent GSM functional signaling.6
ANSI-41 foreign mode: The user may deactivate CFU by means of an appropriate control procedure7(e.g., as described in GSM 02.30 [20]). In ANSI-41 foreign mode, if the equivalent GSM feature code8(MMI) is manually entered by the user, the mobile station is expected to issue the necessary ANSI-419feature code to the network.10
If the de-activation is accepted, the system shall indicate success using either GSM or ANSI-4111signaling techniques depending on the mode of operation. Registered information shall not be12erased.13
CFU shall be de-activated upon de-authorization (withdrawal) or de-registration (erasure).14
2.2.2.2.7 Invocation15
The feature treatment is invoked unconditionally when there is an incoming call and CFU is active.16
2.2.2.3 Normal Operation with Successful Outcome17
When CFU is active, incoming calls for the subscriber shall be forwarded unconditionally to the18forward-to number.19
GSM Foreign Mode: When an incoming call is forwarded unconditionally the forward-to-party shall20receive a notification that the call has been forwarded. The calling party may also receive a21notification that the call has been forwarded.22
ANSI-41 foreign mode: When an incoming call is forwarded unconditionally the served mobile23subscriber may receive a notification that the call has been forwarded.24
2.2.2.3.1 Call Detail Record / Charging Requirements25
For GSM and ANSI-41 based network interoperability, no new or special recording capabilities are26needed.27
X.S0023
1-12
2.2.2.4 Exception Procedures or Unsuccessful Outcome1
2
2.2.2.4.1 Registration3
If the system cannot accept a registration request, the served mobile subscriber shall receive a4notification that registration of call forwarding unconditional was not successful. Possible causes are:5
service not subscribed to;6
forward-to number is invalid directory number;7
use of an operator access prefix;8
insufficient information;9
forward-to number is a special service code (e.g., police);10
forward-to number is the directory number of the mobile subscriber herself.11
2.2.2.4.2 De-Registration (Erasure)12
If the subscriber is not authorized for the request, the system shall apply feature denial treatment13when de-registration is attempted.14
2.2.2.4.3 Activation15
If the subscriber is not authorized for the request, or if a forward-to-number is not properly registered,16the system shall apply feature denial treatment when activation is attempted.17
2.2.2.4.4 De-Activation18
If the subscriber is not authorized for the request, the system shall apply feature denial treatment19when de-activation is attempted.20
2.2.2.4.5 Invocation21
If the forwarded call cannot be routed to the forward-to-destination, then the call shall be given the22appropriate treatment, such as applying the Special Information Tone for intercept to the calling party.23
Precautions shall be taken to preclude undesirable looping of forwarded numbers within the MSC or24between the MSC and other switching centers. If such looping is detected, the call forwarding shall be25given the appropriate treatment, such as applying the Special Information Tone for intercept to the26calling party.27
2.2.2.4.6 Exceptions While Roaming28
None identified.29
2.2.2.4.7 Exceptions During Intersystem Handoff30
None identified.31
2.2.2.5 Alternate Procedures32
None identified.33
2.2.2.6 Interactions With Other Features and Services34
2.2.2.6.1 Advice of charge (AoC)35
See GSM 02.86 [28].36
X.S0023
1-13
2.2.2.6.2 Barring of All Outgoing Calls (BAOC)1
None identified at this time.2
2.2.2.6.3 Barring of Outgoing International Calls (BOIC)3
None identified at this time.4
2.2.2.6.4 Barring of Outgoing International Calls except those directed to the Home PLMN5(BOIC-exHC)6
None identified at this time.7
2.2.2.6.5 Barring of All Incoming Calls (BAIC)8
None identified at this time.9
2.2.2.6.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam)10
None identified at this time.11
2.2.2.6.7 Call Delivery (CD)12
CFU takes precedence over CD. That is, calls arriving when CFU is active are forwarded13unconditionally and not given CD treatment.14
2.2.2.6.8 Call Forwarding—Busy (CFB)15
CFU takes precedence over CFB. That is, calls arriving when CFU is active shall be forwarded16unconditionally and not given CFB treatment17
2.2.2.6.9 Call Forwarding—Default (CFD)18
CFU takes precedence over CFD. That is, calls arriving when CFU is active shall be forwarded19unconditionally and not given CFD treatment.20
2.2.2.6.10 Call Forwarding—No Answer / No Reply /Not Reachable (CFNA / CFNRy/CFNRc)21
CFU takes precedence over CFNA/CFNRy/CFNRc. That is, an incoming call arriving for a subscriber22with both CFU and CFNA/CFNRy/CFNRc active shall be forwarded with CFU.23
2.2.2.6.11 Call Transfer (CT)24
None identified.25
2.2.2.6.12 Call Waiting / Call Hold (CW / HOLD)26
CFU takes precedence over CW. That is, calls arriving when CFU is active shall be forwarded27unconditionally and not given CW treatment.28
2.2.2.6.13 Calling Number / Line Identification Presentation (CNIP / CLIP)29
When a call has been forwarded and the forward-to user has been provided with the CNIP / CLIP30supplementary service, the forward-to user shall receive the number of the original calling user, if this31calling user has not subscribed to or invoked the CNIR / CLIR supplementary service.32
2.2.2.6.14 Calling Number / Line Identification Restriction (CNIR / CLIR)33
If the calling number indicates presentation restricted, the calling number shall not be presented to34the called party or the forward-to-party.35
X.S0023
1-14
If the called (redirecting) subscriber has CFU active and CNIR is either Permanently Restricted or the1default is Presentation Restricted, the redirecting number shall indicate presentation restricted to2prevent presentation to the forward-to-party or to the forward-to station.3
2.2.2.6.15 Calling Name Presentation (CNAP)4
When a call has been forwarded and the forward-to-party has been provided with the CNAP5supplementary service, the forward-to user shall receive the name of the original calling user, if this6calling user has not subscribed to or invoked the CNAR or CNIR / CLIR supplementary service.7
2.2.2.6.16 Calling Name Restriction (CNAR)8
If the calling name or number indicates presentation restricted, the calling name or number shall not9be presented to the called party or the forward-to-party.10
If the called (redirecting) subscriber has CFU active and CNAR or CNIR is either Permanently11Restricted, or the default is Presentation Restricted, the redirecting name shall indicate presentation12restricted to prevent presentation to the forward-to-party.13
2.2.2.6.17 Closed User Group (CUG)14
See GSM 02.85 [27].15
2.2.2.6.18 Conference Calling / Multi Party Service (CC / MPTY)16
None identified.17
2.2.2.6.19 Do Not Disturb (DND)18
None identified at this time.19
2.2.2.6.20 Emergency Services (Future)20
None identified at this time.21
2.2.2.6.21 Flexible Alerting (FA)22
None identified at this time.23
2.2.2.6.22 Message Waiting Notification (MWN)24
None identified.25
2.2.2.6.23 Mobile Access Hunting (MAH)26
None identified at this time.27
2.2.2.6.24 Password Call Acceptance (PCA)28
None identified at this time.29
2.2.2.6.25 Preferred Language (PL)30
None identified.31
2.2.2.6.26 Priority Access and Channel Assignment (PACA)32
None identified at this time.33
2.2.2.6.27 Remote Feature Control (RFC)34
CFU Registration shall be allowed via RFC in ANSI-41 mode, or via functional messaging in GSM35mode.36
X.S0023
1-15
2.2.2.6.28 Selective Call Acceptance (SCA)1
None identified at this time.2
2.2.2.6.29 Subscriber PIN Access (SPINA)3
None identified at this time.4
2.2.2.6.30 Subscriber PIN Intercept (SPINI)5
None identified.6
2.2.2.6.31 Three-Way Calling / Multi Party Service (3WC / MPTY)7
None identified.8
2.2.2.6.32 Voice Message Retrieval (VMR)9
None identified.10
2.2.2.6.33 Voice Privacy (VP)11
None identified.12
X.S0023
1-16
2.2.3 Call Forwarding - Busy (CFB)1
2
2.2.3.1 General Description3
Call Forwarding—Busy (CFB) permits a called subscriber to have the system send incoming calls4addressed to the called subscriber’s Directory Number to another Directory Number (forward-to5number) or to the called subscriber’s designated voice mail box, when the subscriber is engaged in a6call or service. CFB does not impact a subscriber’s ability to originate calls.7
2.2.3.1.1 Applicability to Telecommunications Services8
CFB is applicable to voice telecommunications services.9
2.2.3.2 Normal Procedures With Successful Outcome10
11
2.2.3.2.1 Authorization (or Provision)12
CFB may be generally available or may be provided after pre-arrangement with the service provider.13The authorization (provision) may have the subscription options. These options are defined in either14GSM 02.82 [24] (i.e., GSM native mode subscribers) or ANSI-664 [15] (e.g., ANSI-41 native mode15subscribers). Authorization or Provisioning may occur while operating in foreign mode.16
2.2.3.2.2 De-Authorization (or Withdrawal)17
CFB may be withdrawn at the subscriber’s request or for administrative reasons. De-authorization or18withdrawal may occur while operating in foreign mode.19
2.2.3.2.3 Registration20
If the subscriber is authorized for Fixed Registration, the forward-to number shall be registered upon21authorization (provision).22
The CFB forward-to number may be registered by the service provider upon authorization (provision)23for Variable Registration subscribers. Mobile stations operating in foreign mode may attempt to24perform registration procedures normally supported in native mode.25
GSM foreign mode: A forward-to-number may be registered by a Variable Registration authorized26subscriber specifying the CFB registration feature code and a forward-to number termination address27as in:28
*FC + termination address + SEND .29
Alternatively, if the mobile station offers menu driven control of registration, the mobile station is30expected to generate the equivalent GSM functional signaling towards the network.31
ANSI-41 foreign mode: Registration may take place with an appropriate control procedure by the32subscriber, per GSM 02.30 [20]. In ANSI-41 foreign mode, if the equivalent GSM mode feature code33(MMI) is manually entered by the user, the mobile station is expected to issue the relevant ANSI-4134feature code entry.35
Alternatively, if the mobile station offers menu driven control of registration, the mobile station is36expected to generate the equivalent ANSI-41 feature code entry and resulting call origination based37on the menu driven entry.38
X.S0023
1-17
If the registration is accepted, the system shall indicate success using either GSM or ANSI-411signaling techniques depending on the mode of operation.2
2.2.3.2.4 De-Registration (or Erasure)3
Mobile stations operating in foreign mode may attempt to perform De-Registration or Erasure4procedures normally supported in native mode.5
Forward-to numbers may be de-registered upon de-activation (at the home service provider option).6
GSM foreign mode: If the de-registration is to be separate from de-activation, the de-registration7feature code must be distinct from the corresponding de-activation feature code.8
GSM foreign mode: CFB may be de-registered by a Variable Registration authorized subscriber9specifying the CFB de-registration feature code, as in:10
*FC0 + SEND .11
Alternatively, if the mobile station offers menu driven control of registration, the mobile station is12expected to generate the GSM functional signaling towards the network.13
ANSI-41 foreign mode: The subscriber can specifically erase a previous registration with an14appropriate control procedure, per GSM 02.30 [20]. In ANSI-41 foreign mode, if the equivalent GSM15mode feature code is manually entered by the user, the mobile station is expected to issue the16necessary ANSI-41 feature code to the network.17
CFB shall be de-registered upon de-authorization or withdrawal.18
2.2.3.2.5 Activation19
Mobile stations operating in foreign mode may attempt to perform Activation procedures normally20supported in native mode.21
If the subscriber is authorized for Permanent Activation, CFB shall be activated upon authorization22(provision).23
CFB may be activated upon registration for Demand Activation authorized subscribers. CFB may be24activated upon registration for Variable Registration authorized subscribers.25
GSM foreign mode: A previously registered forward-to number may be activated by a Demand26Activation authorized subscriber specifying a CFB activation feature code, as in:27
*FC + SEND .28
Alternatively, if the mobile station offers menu driven control of activation, the mobile station is29expected to generate the equivalent GSM functional signaling.30
ANSI-41 foreign mode: The MS shall be allowed to activate CFB by for example using the MMI31command described in GSM 02.30 [20]. In ANSI-41 foreign mode, if the equivalent GSM mode32feature code (MMI) is manually entered by the user, the mobile station is expected to issue the33necessary ANSI-41 feature code to the network.34
If the activation is accepted, the system shall indicate success with using either GSM or ANSI-4135signaling techniques depending on the mode of operation.36
The serving system may provide a courtesy call to the forward-to number shortly after this feature is37activated permitting the subscriber to verify the validity of the forward-to number.38
X.S0023
1-18
2.2.3.2.6 De-Activation1
GSM foreign mode: CFB may be de-activated by a Demand Activation authorized subscriber2specifying the CFB de-activation feature code, as in:3
*FC0 + SEND .4
Alternatively, if the mobile station offers menu driven control of de-activation, the mobile station is5expected to generate the equivalent GSM functional signaling.6
ANSI-41 foreign mode: The user may deactivate CFB by means of an appropriate control procedure7(e.g., as described in GSM 02.30 [20]). In ANSI-41 foreign mode, if the equivalent GSM mode feature8code (MMI) is manually entered by the user, the mobile station is expected to issue the necessary9ANSI-41 feature code to the network.10
If the de-activation is accepted, the system shall indicate success with using either GSM or ANSI-4111signaling techniques depending on the mode of operation. Registered information shall not be12erased.13
CFB shall be de-activated upon de-authorization (withdrawal) or de-registration (erasure).14
2.2.3.2.7 Invocation15
The feature treatment is invoked when there is an incoming call while the subscriber is considered to16be busy (i.e., in any state other than the idle state) and CFB is active.17
2.2.3.3 Normal Operation with Successful Outcome18
When CFB is active, incoming calls for the subscriber shall be forwarded to the forward-to number19when the subscriber is considered to be busy.20
GSM Foreign Mode: When an incoming call is forwarded on mobile subscriber busy with the21condition network determined user busy (NDUB) the forward-to-party shall receive a notification that22the call has been forwarded. The calling party may also receive a notification that the call has been23forwarded.24
ANSI-41 foreign mode: When an incoming call is forwarded due to a busy condition the served25mobile subscriber may receive a notification that the call has been forwarded.26
2.2.3.3.1 Call Detail Record / Charging Requirements27
For GSM and ANSI-41 based network interoperability, no new or special recording capabilities are28needed.29
2.2.3.4 Exception Procedures or Unsuccessful Outcome30
31
2.2.3.4.1 Registration32
If the system cannot accept a registration request, the served mobile subscriber shall receive a33notification that call forwarding on mobile subscriber busy registration was not successful. Possible34causes are:35
X.S0023
1-19
service not subscribed to;1
forward-to number is invalid directory number;2
use of an operator access prefix;3
insufficient information;4
forward-to number is a special service code (e.g., police);5
forward-to number is the directory number of the mobile subscriber herself.6
2.2.3.4.2 De-Registration (Erasure)7
If the subscriber is not authorized for the request, the system shall apply feature denial treatment8when de-registration is attempted.9
2.2.3.4.3 Activation10
If the subscriber is not authorized for the request, or if a forward-to number is not properly registered,11the system shall apply feature denial treatment when activation is attempted.12
2.2.3.4.4 De-Activation13
If the subscriber is not authorized for the request, the system shall apply feature denial treatment14when de-activation is attempted.15
2.2.3.4.5 Invocation16
If the forwarded call cannot be routed to the forward-to destination, then the call shall be given the17appropriate treatment, such as applying the Special Information Tone for intercept to the calling party.18
Precautions shall be taken to preclude undesirable looping of forwarded numbers within the MSC or19between the MSC and other switching centers. If such looping is detected, the call forwarding shall be20given the appropriate treatment, such as applying the Special Information Tone for intercept to the21calling party.22
2.2.3.4.6 Exceptions While Roaming23
None identified.24
2.2.3.4.7 Exceptions During Intersystem Handoff25
None identified.26
2.2.3.5 Alternate Procedures27
None identified.28
2.2.3.6 Interactions With Other Features and Services29
30
2.2.3.6.1 Advice of charge (AoC)31
See GSM 02.86 [28].32
2.2.3.6.2 Barring of All Outgoing Calls (BAOC)33
None identified at this time.34
X.S0023
1-20
2.2.3.6.3 Barring of Outgoing International Calls (BOIC)1
None identified at this time.2
2.2.3.6.4 Barring of Outgoing International Calls except those directed to the Home PLMN3(BOIC-exHC)4
None identified at this time.5
2.2.3.6.5 Barring of All Incoming Calls (BAIC)6
None identified at this time.7
2.2.3.6.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam)8
None identified at this time.9
2.2.3.6.7 Call Delivery (CD)10
CD affects CFB. That is, if CD is inactive while the subscriber is roaming, the subscriber is considered11to be inaccessible. Even if the subscriber has CFB active, incoming calls shall be given the subscriber12inaccessible treatment.13
If CD is active and registered for a roaming subscriber, or if the subscriber is at home, CFB works14normally.15
If the call is delivered to the subscriber, the subscriber is busy, and the subscriber has CFB active,16the call shall be diverted to the CFB forward-to number.17
2.2.3.6.8 Call Forwarding—Busy (CFB)18
Not applicable.19
2.2.3.6.9 Call Forwarding—Default (CFD)20
CFB takes precedence over CFD. That is, calls arriving to a busy subscriber with CFB and CFD21active shall be forwarded by CFB and not given CFD treatment.22
2.2.3.6.10 Call Forwarding—No Answer / No Reply (CFNA / CFNRy)23
CFB is mutually exclusive with CFNA / CFNRy. That is, calls arriving to a busy subscriber with CFB24and CFNA / CFNRy active shall be forwarded by CFB and not given CFNA / CFNRy treatment.25
2.2.3.6.11 Call Forwarding—Not Reachable (CFNRc)26
CFB is mutually exclusive with CFNRc. That is, calls arriving to a busy subscriber with CFB and27CFNRc active shall be forwarded by CFB and not given CFNRc treatment.28
2.2.3.6.12 Call Forwarding—Unconditional (CFU)29
CFU takes precedence over CFB. That is, calls arriving when CFU is active shall be forwarded30unconditionally and not given CFB treatment.31
2.2.3.6.13 Call Transfer (CT)32
None identified.33
2.2.3.6.14 Call Waiting / Call Hold (CW / HOLD)34
CW is invoked before CFB. If a call arrives for a busy subscriber able to receive a second call, the35called subscriber has both CW and CFB active, and no call is already waiting to be answered; the call36is presented to the subscriber with CW notification. If the CW call is not accepted, CFB is not invoked.37
X.S0023
1-21
If a call arrives for a busy subscriber, the called subscriber has both CW and CFB active, and if the1called subscriber is unable to receive a second call or has a call waiting to be answered; the call shall2be forwarded immediately by CFB.3
2.2.3.6.15 Calling Number / Line Identification Presentation (CNIP / CLIP)4
When a call has been forwarded and the forward-to user has been provided with the CNIP / CLIP5supplementary service, the forward-to user shall receive the number of the original calling user, if this6calling user has not subscribed to or invoked the CNIR / CLIR supplementary service.7
2.2.3.6.16 Calling Number / Line Identification Restriction (CNIR / CLIR)8
If the calling number indicates presentation restricted, the calling number shall not be presented to9the called party, the called station, the forward-to party, or the forward-to station.10
If the called (redirecting) subscriber has CFB invoked and either the CNIR mode is Permanently11Restricted or the CNIR Default is Presentation Restricted, the redirecting number shall indicate12presentation restricted to prevent presentation to the forward-to party or to the forward-to station.13
2.2.3.6.17 Calling Name Presentation (CNAP)14
When a call has been forwarded and the forward-to user has been provided with the CNAP15supplementary service, the forward-to user shall receive the name of the original calling user, if this16calling user has not subscribed to or invoked the CNAR or CNIR / CLIR supplementary service.17
2.2.3.6.18 Calling Name Restriction (CNAR)18
If the calling name or number indicates presentation restricted, the calling name or number shall not19be presented to the called party, the called station, the forward-to party, or the forward-to station.20
If the called (redirecting) subscriber has CFB invoked and either the CNAR or CNIR mode is21Permanently Restricted, or the CNAR or CNIR Default is Presentation Restricted, the redirecting22name shall indicate presentation restricted to prevent presentation to the forward-to party or to the23forward-to station.24
2.2.3.6.19 Closed User Group (CUG)25
See GSM 02.85 [27].26
2.2.3.6.20 Conference Calling / Multi Party Service (CC / MPTY)27
None identified.28
2.2.3.6.21 Do Not Disturb (DND)29
None identified at this time.30
2.2.3.6.22 Emergency Services31
None identified at this time.32
2.2.3.6.23 Flexible Alerting (FA)33
None identified at this time.34
2.2.3.6.24 Message Waiting Notification (MWN)35
None identified.36
2.2.3.6.25 Mobile Access Hunting (MAH)37
None identified at this time.38
X.S0023
1-22
2.2.3.6.26 Password Call Acceptance (PCA)1
None identified at this time.2
2.2.3.6.27 Preferred Language (PL)3
None identified.4
2.2.3.6.28 Priority Access and Channel Assignment (PACA)5
None identified at this time.6
2.2.3.6.29 Remote Feature Control (RFC)7
CFB Registration shall be allowed via RFC in ANSI-41 mode, or via functional messaging in GSM8mode.9
2.2.3.6.30 Selective Call Acceptance (SCA)10
None identified at this time.11
2.2.3.6.31 Subscriber PIN Access (SPINA)12
None identified at this time.13
2.2.3.6.32 Subscriber PIN Intercept (SPINI)14
None identified.15
2.2.3.6.33 Three-Way Calling / Multi Party Service (3WC / MPTY)16
None identified.17
2.2.3.6.34 Voice Message Retrieval (VMR)18
None identified.19
2.2.3.6.35 Voice Privacy (VP)20
None identified.21
X.S0023
1-23
2.2.4 Call Forwarding No Answer/ No Reply/Not Reachable1(CFNA/CFNRy/CFNRc)2
3
2.2.4.1 General Description4
Call Forwarding—No Answer (CFNA) permits a called subscriber to have the system send incoming5calls addressed to the called subscriber’s Directory Number to another Directory Number (forward-to6number) or to the called subscriber’s designated voice mail box, when the subscriber fails to answer,7or is otherwise inaccessible (including no paging response, the subscriber’s location is not known the8subscriber is reported as inactive, Call Delivery not active for a roaming subscriber, Do Not Disturb9active, etc.).10
Call Forwarding No Reply (CFNRy) permits a called subscriber to have the system send all incoming11calls, or just those associated with a specific Basic service group, addressed to the called mobile12subscriber's directory number and which meet no reply to another directory number.13
Call Forwarding Not Reachable (CFNRc) permits a called subscriber to have the system send all14incoming calls, or just those associated with a specific Basic service group, addressed to the called15mobile subscriber's directory number and which meet not reachable to another directory number.16
2.2.4.1.1 Applicability to Telecommunications Services17
CFNA/CFNRy/CFNRc is applicable to voice telecommunication services.18
2.2.4.2 Normal Procedures With Successful Outcome19
20
2.2.4.2.1 Authorization (or Provision)21
CFNA/CFNRy/CFNRc may be generally available or may be provided after pre-arrangement with the22service provider. The authorization (provision) may have subscription options. These options are23defined in either GSM 02.82 [24] (i.e., GSM native mode subscribers) or ANSI-664 [15] (e.g., ANSI-4124TDMA or CDMA native mode subscribers). Authorization or Provisioning may occur while operating in25foreign mode.26
2.2.4.2.2 De-Authorization (or Withdrawal)27
CFNA/CFNRy/CFNRc may be withdrawn by the service provider, at the subscriber’s request, or for28administrative reasons. De-authorization or withdrawal may occur while operating in foreign mode.29
2.2.4.2.3 Registration30
If the subscriber is authorized for Fixed Registration, the forward-to number shall be registered upon31authorization (provision). Mobile stations operating in foreign mode may attempt to perform32registration procedures normally supported in native mode.33
The forward-to-number may be registered by the service provider upon authorization (provision) for34Variable Registration subscribers35
X.S0023
1-24
GSM foreign mode: A forward-to-number may be registered by a Variable Registration authorized1subscriber specifying the CFNA registration feature code and a forward-to number termination2address as in:3
*FC + termination address + SEND 4
Alternatively, if the mobile station offers menu driven control of registration, the mobile station is5expected to generate the equivalent GSM functional signaling towards the network.6
ANSI-41 foreign mode: Registration can take place with an appropriate control procedure by the7subscriber, per GSM 02.30 [20]. In ANSI-41 foreign mode, if the equivalent GSM feature code (MMI)8is manually entered by the user, the mobile station is expected to issue the relevant ANSI-41 feature9code entry.10
Alternatively, if the mobile station offers menu driven control of registration, the mobile station is11expected to generate the equivalent ANSI-41 feature code entry and resulting call origination based12on the menu driven entry.13
If the registration is accepted, the system shall indicate success using either GSM or ANSI-4114signaling techniques depending on the mode of operation.15
2.2.4.2.4 De-Registration (or Erasure)16
Mobile stations operating in foreign mode may attempt to perform De-Registration or Erasure17procedures normally supported in native mode.18
A forward-to-number may be de-registered upon de-activation (at the home service provider option).19
GSM foreign mode: If the de-registration is to be separate from de-activation, the de-registration20feature code must be distinct from the corresponding de-activation feature code.21
GSM foreign mode: CFNA may be de-registered by a Variable Registration authorized subscriber22specifying the CFNA de-registration feature code, as in:23
*FC0 + SEND .24
Alternatively, if the mobile station offers menu driven control of registration, the mobile station is25expected to generate the equivalent GSM functional signaling towards the network.26
ANSI-41 foreign mode: The subscriber can specifically erase a previous registration with an27appropriate control procedure, per GSM 02.30 [20]. In ANSI-41 foreign mode, if the equivalent GSM28feature code (MMI) is manually entered by the user, the mobile station is expected to issue the29necessary ANSI-41 feature code to the network.30
CFNA/CFNRy/CFNRc shall be de-registered upon de-authorization or withdrawal.31
2.2.4.2.5 Activation32
Mobile stations operating in foreign mode may attempt to perform Activation procedures normally33supported in native mode.34
If the subscriber is authorized for Permanent Activation, CFNA shall be activated upon authorization35(provision).36
CFNA may be activated upon authorization or registration for Demand Activation authorized37subscribers. CFNA may be activated upon registration for Variable Registration authorized38subscribers.39
X.S0023
1-25
GSM foreign mode: A previously registered forward-to-number may be activated by a Demand1Activation authorized subscriber specifying a CFNA activation feature code, as in:2
*FC + SEND .3
Alternatively, if the mobile station offers menu driven control of activation, the mobile station is4expected to generate the equivalent GSM functional signaling.5
ANSI-41 foreign mode: The MS shall be allowed to activate CFNRy/CFNRc by using an appropriate6control procedure (e.g. using the MMI command described in GSM 02.30 [20]). In ANSI-41 foreign7mode, if the equivalent GSM feature code (MMI) is manually entered by the user, the mobile station is8expected to issue the necessary ANSI-41 feature code to the network.9
If the activation is accepted, the system shall indicate success using either GSM or ANSI-41 signaling10techniques depending on the mode of operation.11
The serving system may provide a courtesy call to the forward-to number shortly after this feature is12activated permitting the subscriber to verify the validity of the forward-to-number.13
2.2.4.2.6 De-Activation14
GSM foreign mode: CFNA may be de-activated by a Demand Activation authorized subscriber15specifying the CFNA de-activation feature code, as in:16
*FC0 + SEND .17
Alternatively, if the mobile station offers menu driven control of de-activation, the mobile station is18expected to generate the equivalent GSM functional signaling.19
ANSI-41 foreign mode: The user may deactivate CFNRy/CFNRc by means of an appropriate control20procedure (e.g., as described in GSM 02.30 [20]). In ANSI-41 foreign mode, if the equivalent GSM21feature code (MMI) is manually entered by the user, the mobile station is expected to issue the22necessary ANSI-41 feature code to the network.23
If the de-activation is accepted, the system shall indicate success using either GSM or ANSI-4124signaling techniques depending on the mode of operation. Registered information shall not be25erased.26
CFNA/CFNRy/CFNRc shall be de-activated upon de-authorization (withdrawal) or de-registration27(erasure).28
2.2.4.2.7 Invocation29
The feature treatment is invoked when there is an incoming call and either CFNA, CFNRy or CFNRc30is active and the necessary conditions have been met – see GSM 02.82 [24] and ANSI-664 [15].31
2.2.4.3 Normal Operation with Successful Outcome32
When CFNA/CFNRy/CFNRc is active, incoming calls for the subscriber shall be forwarded due to not33reachable (e.g., no response to paging) or no reply to the forward-to number.34
GSM Foreign Mode: When an incoming call is forwarded due to no reply or not reachable, the35forward-to-party shall receive a notification that the call has been forwarded. The calling party may36also receive a notification that the call has been forwarded.37
ANSI-41 foreign mode: When an incoming call is forwarded due to no answer the served mobile38subscriber may receive a notification that the call has been forwarded.39
X.S0023
1-26
2.2.4.3.1 Call Detail Record / Charging Requirements1
For GSM and ANSI-41 based network interoperability, no new or special recording capabilities are2needed.3
2.2.4.4 Exception Procedures or Unsuccessful Outcome4
5
2.2.4.4.1 Registration6
If the system cannot accept a registration request, the served mobile subscriber shall receive a7notification that registration of CFNA/CFNRy/CFNRc was not successful. Possible causes are:8
service not subscribed to;9
forward-to number is invalid directory number;10
use of an operator access prefix;11
insufficient information;12
forward-to number is a special service code (e.g., police);13
forward-to number is the directory number of the mobile subscriber herself.14
2.2.4.4.2 De-Registration (Erasure)15
If the subscriber is not authorized for the request, the system shall apply feature denial treatment16when de-registration is attempted.17
2.2.4.4.3 Activation18
If the subscriber is not authorized for the request, or if a forward-to-number is not properly registered,19the system shall apply feature denial treatment when activation is attempted.20
2.2.4.4.4 De-Activation21
If the subscriber is not authorized for the request, the system shall apply feature denial treatment22when de-activation is attempted.23
2.2.4.4.5 Invocation24
If the forwarded call cannot be routed to the forward-to-destination, then the call shall be given the25appropriate treatment, such as applying the Special Information Tone for intercept to the calling party.26
Precautions shall be taken to preclude undesirable looping of forwarded numbers within the MSC or27between the MSC and other switching centers. If such looping is detected, the call forwarding shall be28given the appropriate treatment, such as applying the Special Information Tone for intercept to the29calling party.30
2.2.4.4.6 Exceptions While Roaming31
None identified.32
2.2.4.4.7 Exceptions During Intersystem Handoff33
None identified.34
2.2.4.5 Alternate Procedures35
None identified.36
X.S0023
1-27
2.2.4.6 Interactions With Other Features and Services1
2
2.2.4.6.1 Advice of charge (AoC)3
See GSM 02.86 [28].4
2.2.4.6.2 Barring of All Outgoing Calls (BAOC)5
None identified at this time.6
2.2.4.6.3 Barring of Outgoing International Calls (BOIC)7
None identified at this time.8
2.2.4.6.4 Barring of Outgoing International Calls except those directed to the Home PLMN9(BOIC-exHC)10
None identified at this time.11
2.2.4.6.5 Barring of All Incoming Calls (BAIC)12
None identified at this time.13
2.2.4.6.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam)14
None identified at this time.15
2.2.4.6.7 Call Delivery (CD)16
CD affects CFNA. That is, if CD is inactive while the subscriber is roaming, the subscriber is17considered to be inaccessible. If the subscriber has CFNA active, incoming calls shall be diverted to18the CFNA forward-to number.19
If CD is active and registered for a roaming subscriber, or if the subscriber is at home, CFNA works20normally.21
If the call is presented to the subscriber, the call is not answered, and the subscriber has CFNA22active, the call shall be diverted to the CFNA forward-to number.23
2.2.4.6.8 Call Forwarding—Busy (CFB)24
CFB is mutually exclusive with CFNA/CFNRy/CFNRc. That is, calls arriving to a busy subscriber with25CFB and CFNA/CFNRy/CFNRc active shall be forwarded by CFB and not given26CFNA/CFNRy/CFNRc treatment.27
2.2.4.6.9 Call Forwarding—Default (CFD)28
CFNA takes precedence over CFD. That is, an incoming call to an inaccessible or non-answering29subscriber with both CFNA and CFD active shall be forwarded using CFNA.30
2.2.4.6.10 Call Transfer (CT)31
None identified.32
X.S0023
1-28
2.2.4.6.11 Call Waiting / Call Hold (CW / HOLD)1
CW is invoked before CFNA/CFNRy. If a call arrives for a busy subscriber able to receive a second2call, the called subscriber has both CW and CFNA/CFNRy active, and no call is waiting to be3answered; the call is presented to the subscriber with CW notification. If the call is not answered4within a period of time after applying the first CW notification, it shall be given no answer treatment.5
CFNRc is invoked before CW.6
2.2.4.6.12 Calling Number / Line Identification Presentation (CNIP / CLIP)7
When a call has been forwarded and the forward-to user has been provided with the CNIP / CLIP8supplementary service, the forward-to user shall receive the number of the original calling user, if this9calling party has not subscribed to or invoked the CNIR / CLIR supplementary service.10
2.2.4.6.13 Calling Number / Line Identification Restriction (CNIR / CLIR)11
If the calling number indicates presentation restricted, the calling number shall not be presented to12the called party or the forward-to-party.13
If the called (redirecting) subscriber has CFNA/CFNRy/CFNRc active and CNIR is either Permanently14Restricted or the default is Presentation Restricted, the redirecting number shall indicate presentation15restricted to prevent presentation to the forward-to-party or to the forward-to station.16
2.2.4.6.14 Calling Name Presentation (CNAP)17
When a call has been forwarded and the forward-to-party has been provided with the CNAP18supplementary service, the forward-to user shall receive the name of the original calling user, if this19calling user has not subscribed to or invoked the CNAR or CNIR / CLIR supplementary service.20
2.2.4.6.15 Calling Name Restriction (CNAR)21
If the calling name or number indicates presentation restricted, the calling name or number shall not22be presented to the called party or the forward-to-party.23
If the called (redirecting) subscriber has CFNA/CFNRy/CFNRc active and CNAR or CNIR is either24Permanently Restricted, or the default is Presentation Restricted, the redirecting name shall indicate25presentation restricted to prevent presentation to the forward-to-party.26
2.2.4.6.16 Closed User Group (CUG)27
See GSM 02.85 [27].28
2.2.4.6.17 Conference Calling / Multi Party Service (CC / MPTY)29
None identified.30
2.2.4.6.18 Do Not Disturb (DND)31
None identified at this time.32
2.2.4.6.19 Emergency Services33
None identified at this time.34
2.2.4.6.20 Flexible Alerting (FA)35
None identified at this time.36
2.2.4.6.21 Message Waiting Notification (MWN)37
None identified.38
X.S0023
1-29
2.2.4.6.22 Mobile Access Hunting (MAH)1
None identified at this time.2
2.2.4.6.23 Password Call Acceptance (PCA)3
None identified at this time.4
2.2.4.6.24 Preferred Language (PL)5
None identified.6
2.2.4.6.25 Priority Access and Channel Assignment (PACA)7
None identified at this time.8
2.2.4.6.26 Remote Feature Control (RFC)9
CFNA/CFNRy/CFNRc Registration shall be allowed via RFC in ANSI-41 mode, or via functional10messaging in GSM mode.11
2.2.4.6.27 Selective Call Acceptance (SCA)12
None identified at this time.13
2.2.4.6.28 Subscriber PIN Access (SPINA)14
None identified at this time.15
2.2.4.6.29 Subscriber PIN Intercept (SPINI)16
None identified.17
2.2.4.6.30 Three-Way Calling / Multi Party Service (3WC / MPTY)18
None identified.19
2.2.4.6.31 Voice Message Retrieval (VMR)20
None identified.21
2.2.4.6.32 Voice Privacy (VP)22
None identified.23
X.S0023
1-30
2.2.5 Call Forwarding Default1
2
2.2.5.1 General Description3
Call Forwarding—Default (CFD) permits a called subscriber to send incoming calls addressed to the4called subscriber’s Directory Number to the subscriber’s designated voice mail box or to another5Directory Number (forward-to number), when the subscriber is engaged in a call, does not respond to6paging, does not answer the call within a specified period after being alerted or is otherwise7inaccessible (including no paging response, the subscriber’s location is not known, the subscriber is8reported as inactive, Call Delivery not active for a roaming subscriber, Do Not Disturb active, etc.).9
2.2.5.1.1 Applicability to Telecommunications Services10
CFD is applicable to voice telecommunication services.11
2.2.5.2 Normal Procedures With Successful Outcome12
13
2.2.5.2.1 Authorization (or Provision)14
CFD may be generally available or may be provided after pre-arrangement with the service provider.15The authorization (provision) may have subscription options. These options are defined in16ANSI-664 [15] (e.g., ANSI-41 TDMA or CDMA native mode subscribers). Authorization or17Provisioning may occur while operating in foreign mode.18
2.2.5.2.2 De-Authorization (or Withdrawal)19
CFD may be withdrawn by the service provider, at the subscriber’s request, or for administrative20reasons. De-authorization or withdrawal may occur while operating in foreign mode.21
2.2.5.2.3 Registration22
If the subscriber is authorized for Fixed Registration, the forward-to number shall be registered upon23authorization (provision). Mobile stations operating in foreign mode may attempt to perform24registration procedures normally supported in native mode.25
The forward-to-number may be registered by the service provider upon authorization (provision) for26Variable Registration subscribers27
GSM foreign mode: A forward-to-number may be registered by a Variable Registration authorized28subscriber specifying the CFD registration feature code and a forward-to number termination address29as in:30
*FC + termination address + SEND .31
Alternatively, if the mobile station offers menu driven control of registration, the mobile station is32expected to generate the equivalent GSM functional signaling towards the network.33
If the registration is accepted, the system shall indicate success using either GSM signaling34techniques.35
2.2.5.2.4 De-Registration (or Erasure)36
Mobile stations operating in foreign mode, may attempt to perform De-Registration or Erasure37procedures normally supported in native mode.38
X.S0023
1-31
A forward-to-number may be de-registered upon de-activation (at the home service provider option).1
GSM foreign mode: If the de-registration is to be separate from de-activation, the de-registration2feature code must be distinct from the corresponding de-activation feature code.3
GSM foreign mode: CFD may be de-registered by a Variable Registration authorized subscriber4specifying the CFD de-registration feature code, as in:5
*FC0 + SEND .6
Alternatively, if the mobile station offers menu driven control of registration, the mobile station is7expected to generate the equivalent GSM functional signaling towards the network.8
CFD shall be de-registered upon de-authorization or withdrawal.9
2.2.5.2.5 Activation10
Mobile stations operating in foreign mode may attempt to perform Activation procedures normally11supported in native mode.12
If the subscriber is authorized for Permanent Activation, CFD shall be activated upon authorization13(provision).14
CFD may be activated upon authorization or registration for Demand Activation authorized15subscribers. CFD may be activated upon registration for Variable Registration authorized subscribers.16
GSM foreign mode: A previously registered forward-to-number may be activated by a Demand17Activation authorized subscriber specifying a CFD activation feature code, as in:18
*FC + SEND .19
Alternatively, if the mobile station offers menu driven control of activation, the mobile station is20expected to generate the equivalent GSM functional signaling.21
If the activation is accepted, the system shall indicate success using GSM or ANSI-41 signaling22techniques.23
The serving system may provide a courtesy call to the forward-to number shortly after this feature is24activated permitting the subscriber to verify the validity of the forward-to-number.25
2.2.5.2.6 De-Activation26
GSM foreign mode: CFD may be de-activated by a Demand Activation authorized subscriber27specifying the CFD de-activation feature code, as in:28
*FC0 + SEND .29
Alternatively, if the mobile station offers menu driven control of de-activation, the mobile station is30expected to generate the equivalent GSM functional signaling.31
If the de-activation is accepted, the system shall indicate success using either GSM signaling32techniques. Registered information shall not be erased.33
CFD shall be de-activated upon de-authorization (withdrawal) or de-registration (erasure).34
2.2.5.2.7 Invocation35
The feature treatment is invoked when there is an incoming call, CFD is active and the necessary36conditions have been met – See ANSI-664 [15].37
X.S0023
1-32
2.2.5.3 Normal Operation with Successful Outcome1
When CFD is active, incoming calls for the subscriber shall be forwarded due to not reachable (e.g.,2no response to paging), no reply, or busy to the forward-to number.3
GSM Foreign Mode: When an incoming call is forwarded due to CFD, the forward-to-party shall4receive a notification that the call has been forwarded. The calling party may also receive a5notification that the call has been forwarded.6
2.2.5.3.1 Call Detail Record / Charging Requirements7
For GSM and ANSI-41 based network interoperability, no new or special recording capabilities are8needed.9
2.2.5.4 Exception Procedures or Unsuccessful Outcome10
11
2.2.5.4.1 Registration12
If the system cannot accept a registration request, the served mobile subscriber shall receive a13notification that registration of CFD was not successful. Possible causes are:14
service not subscribed to;15
forward-to number is invalid directory number;16
use of an operator access prefix;17
insufficient information;18
forward-to number is a special service code (e.g., police);19
forward-to number is the directory number of the mobile subscriber herself.20
2.2.5.4.2 De-Registration (Erasure)21
If the subscriber is not authorized for the request, the system shall apply feature denial treatment22when de-registration is attempted.23
2.2.5.4.3 Activation24
If the subscriber is not authorized for the request, or if a forward-to-number is not properly registered,25the system shall apply feature denial treatment when activation is attempted.26
2.2.5.4.4 De-Activation27
If the subscriber is not authorized for the request, the system shall apply feature denial treatment28when de-activation is attempted.29
2.2.5.4.5 Invocation30
If the forwarded call cannot be routed to the forward-to-destination, then the call shall be given the31appropriate treatment, such as applying the Special Information Tone for intercept to the calling party.32
Precautions shall be taken to preclude undesirable looping of forwarded numbers within the MSC or33between the MSC and other switching centers. If such looping is detected, the call forwarding shall be34given the appropriate treatment, such as applying the Special Information Tone for intercept to the35calling party.36
X.S0023
1-33
2.2.5.4.6 Exceptions While Roaming1
None identified.2
2.2.5.4.7 Exceptions During Intersystem Handoff3
None identified.4
2.2.5.5 Alternate Procedures5
None identified.6
2.2.5.6 Interactions With Other Features and Services7
2.2.5.6.1 Call Delivery (CD)8
CD affects CFD. That is, if CD is inactive while the subscriber is roaming, the subscriber is9considered to be inaccessible. If the subscriber has CFD active, incoming calls shall be diverted to10the CFD forward-to number.11
2.2.5.6.2 Call Forwarding—Busy (CFB)12
CFB takes precedence over CFD. That is, calls arriving to a busy subscriber with CFB and CFD13active shall be forwarded by CFB and not given CFD treatment.14
2.2.5.6.3 Call Transfer (CT)15
None identified.16
2.2.5.6.4 Call Waiting / Call Hold (CW / HOLD)17
CW is invoked before CFD. If a call arrives for a busy subscriber able to receive a second call, the18called subscriber has both CW and CFD active, and no call is waiting to be answered; the call is19presented to the subscriber with CW notification. If the call is not answered within a period of time20after applying the first CW notification, it shall be given no answer treatment.21
2.2.5.6.5 Calling Number / Line Identification Presentation (CNIP / CLIP)22
When a call has been forwarded and the forward-to user has been provided with the CNIP / CLIP23supplementary service, the forward-to user shall receive the number of the original calling user, if this24calling user has not subscribed to or invoked the CNIR / CLIR supplementary service.25
2.2.5.6.6 Calling Number / Line Identification Restriction (CNIR / CLIR)26
If the calling number indicates presentation restricted, the calling number shall not be presented to27the called party or the forward-to-party.28
If the called (redirecting) subscriber has CFD active and CNIR is either Permanently Restricted or the29default is Presentation Restricted, the redirecting number shall indicate presentation restricted to30prevent presentation to the forward-to-party or to the forward-to station.31
2.2.5.6.7 Calling Name Presentation (CNAP)32
When a call has been forwarded and the forward-to-party has been provided with the CNAP33supplementary service, the forward-to user shall receive the name of the original calling user, if this34calling user has not subscribed to or invoked the CNAR or CNIR / CLIR supplementary service.35
X.S0023
1-34
2.2.5.6.8 Calling Name Restriction (CNAR)1
If the calling name or number indicates presentation restricted, the calling name or number shall not2be presented to the called party or the forward-to-party.3
If the called (redirecting) subscriber has CFD active and CNAR or CNIR is either Permanently4Restricted, or the default is Presentation Restricted, the redirecting name shall indicate presentation5restricted to prevent presentation to the forward-to-party.6
2.2.5.6.9 Closed User Group (CUG)7
See GSM 02.85 [27].8
2.2.5.6.10 Conference Calling / Multi Party Service (CC / MPTY)9
None identified.10
2.2.5.6.11 Do Not Disturb (DND)11
None identified at this time.12
2.2.5.6.12 Emergency Services13
None identified at this time.14
2.2.5.6.13 Flexible Alerting (FA)15
None identified at this time.16
2.2.5.6.14 Message Waiting Notification (MWN)17
None identified.18
2.2.5.6.15 Mobile Access Hunting (MAH)19
None identified at this time.20
2.2.5.6.16 Password Call Acceptance (PCA)21
None identified at this time.22
2.2.5.6.17 Preferred Language (PL)23
None identified.24
2.2.5.6.18 Priority Access and Channel Assignment (PACA)25
None identified at this time.26
2.2.5.6.19 Remote Feature Control (RFC)27
CFD Registration shall be allowed via RFC in ANSI-41 mode, or via functional messaging in GSM28mode.29
2.2.5.6.20 Selective Call Acceptance (SCA)30
None identified at this time.31
2.2.5.6.21 Subscriber PIN Access (SPINA)32
None identified at this time.33
X.S0023
1-35
2.2.5.6.22 Subscriber PIN Intercept (SPINI)1
None identified.2
2.2.5.6.23 Three-Way Calling / Multi Party Service (3WC / MPTY)3
None identified.4
2.2.5.6.24 Voice Message Retrieval (VMR)5
None identified.6
2.2.5.6.25 Voice Privacy (VP)7
None identified.8
X.S0023
1-36
2.3 Optimal Routing for Late Call Forwarding1
2
2.3.1 General Description3
Optimal Routing for Late Call Forwarding is a network feature which enables calls for a mobile4subscriber who is not available to be routed from the called party HPLMN directly to a specified5forward-to destination.6
In GSM Optimal Routing for Late Call Forwarding by the HPLMN is a subset of the capabilities7provided in GSM Support for Optimal Routing (SOR) Phase I per GSM 02.79 [22]. With SOR, the8interrogating PLMN (IPLMN) decides whether or not to optimize routing by taking into account9information provided by the called party HPLMN. The HPLMN can decide, on a call-by-call basis,10whether or not to allow OR.11
GSM SOR provides additional capabilities for OR under other conditions and by systems other than12the HPLMN, which are outside the scope of this feature.13
In ANSI-41 networks Optimal Routing for Late Call Forwarding can be provided automatically for14every call by ANSI-41 call delivery procedures, and is not considered a supplementary service.15
OR is a network feature, and therefore is transparent to the subscriber, except possibly in charging.16There is no subscriber initiated registration, activation, or invocation.17
2.3.1.1 Applicability to Telecommunications Services18
Optimal Routing for Late Call Forwarding is applicable to all circuit switched Telecommunications19Service.20
2.3.2 Normal Procedures with Successful Outcome21
Optimal Routing for Late Call Forwarding refers to the scenario in which party A (mobile or wireline)22attempts to call mobile subscriber B who may have calls forwarded to party C (mobile or wireline). In23GSM, the consideration of whether or not to invoke OR depends upon the relative locations HPLMN-24B, VPLMN-B, and HPLMN-C. Both the HPLMN-B and the VPLMN-B must be capable of supporting25Optimal Routing for Late Call Forwarding. The VPLMN-B determines if Optimal Routing for Late Call26Forwarding is feasible, but the HPLMN-B controls the invocation of this feature.27
Using GSM terminogy, the interrogating PLMN (IPLMN) in the following scenario is HPLMN-B.28
Party A originates a call to party B. A may be a fixed or mobile subscriber, and A may be in any29country.30
HPLMN- B acts as the interrogating PLMN, and launches a query to the HLR to determine the31location and status of B.32
If the response from the HLR indicates that B is active and reachable, then HPLMN-B proceeds to33initiate call setup to VPLMN-B.34
Upon receipt of call setup request from HPLMN-B, VPLMN-B proceeds to page B. If call cannot be35completed successfully (e.g., Busy, No Page Response or No Answer), and B has call forwarding36active, then HPLMN-B proceeds to initiate call forwarding to the forward-to number. Call setup to the37forward to party is done directly from HPLMN-B rather than through VPLMN-B. Without optimal38routing in GSM call leg would have been setup initially to VPLMN-B, and from there to C.39
X.S0023
1-37
2.3.2.1 Call Detail Record1
For GSM and ANSI-41 based network interoperability, no new or special recording capabilities are2needed.3
2.3.3 Exception Procedures or Unsuccessful Outcome4
2.3.3.1 Non-support for OR in the called party HPLMN5
If the HPLMN of the called party is a GSM system which does not support OR, Optimal Routing for6Late Call Forwarding cannot be invoked.7
2.3.3.2 Non-support for OR in the called party VPLMN8
If a subscriber whose HPLMN is an ANSI-41 or GSM system that supports OR registers in a VPLMN9with a GSM system that does not support OR, then Optimal Routing for Late Call Forwarding cannot10be invoked.11
2.3.3.3 Calls to special mobile network numbers12
If the called number is a special mobile network number of the HPLMN and the HPLMN is a GSM13system, then the HPLMN has to guarantee that the call terminates at the correct destination. This can14be achieved by denying OR for this call or by sending an appropriate error cause, or by implementing15special handling.16
2.3.3.4 Exceptions while Roaming17
None identified.18
2.3.3.5 Exceptions during Intersystem Handoff19
None identified.20
2.3.4 Alternate Procedures21
None identified.22
2.3.5 Interactions with Other Features and Services23
2.3.5.1 Advice of Charge24
Depending on the particular call scenario, AoC may not work properly. For example, the subscriber25may be charged a rate that is associated with non-optimal routing.26
2.3.5.2 Barring of All Outgoing Calls (BAOC)27
None identified.28
2.3.5.3 Barring of Outgoing International Calls (BOIC)29
None identified.30
2.3.5.4 Barring of All Incoming Calls (BAIC)31
BAIC takes precedence over Optimal Routing for Late Call Forwarding, and all incoming calls are32given denial treatment.33
Barring of Incoming Calls when Roaming Outside the Home PLMN Country (BIC-Roam)34
No impact.35
X.S0023
1-38
2.3.5.5 Call Forwarding Busy (CFB)1
The interaction between Optimal Routing for Late Call Forwarding and CFB is as described in 2.3.12above. Optimal Routing for Late Call Forwarding does not impact the forwarded number or the3ultimate call delivery to the forwarded party – only intermediate routing.4
2.3.5.6 Call Forwarding Default (CFD)5
The interaction between Optimal Routing for Late Call Forwarding and CFD is as described in 2.3.16above. Optimal Routing for Late Call Forwarding does not impact the forwarded number or the7ultimate call delivery to the forwarded party – only intermediate routing.8
2.3.5.7 Call Forwarding Busy No Answer / No Reply (CFNA)9
The interaction between Optimal Routing for Late Call Forwarding and CFNA is as described in 2.3.1.10Optimal Routing for Late Call Forwarding does not impact the forwarded number or the ultimate call11delivery to the forwarded party – only intermediate routing.12
2.3.5.8 Call Forwarding—Not Reachable (CFNRc)13
There is no interaction between Optimal Routing for Late Call Forwarding and CFU since CFU is14invoked in the called party HPLMN before call setup to the serving system is initiated. (ANSI-41: it15depends on when paging occurs!).16
2.3.5.9 Call Forwarding Unconditional (CFU)17
There is no interaction between Optimal Routing for Late Call Forwarding and CFU since CFU is18invoked in the called party HPLMN before call setup to the serving system is initiated.19
2.3.5.10 Call Transfer (CT)20
None identified.21
2.3.5.11 Call Waiting / Call Hold (CW / HOLD)22
None identified.23
2.3.5.12 Calling Number / Line Identification Presentation (CNIP / CLIP)24
None identified.25
2.3.5.13 Calling Number / Line Identification Restriction (CNIR / CLIR)26
None identified.27
2.3.5.14 Calling Name Presentation (CNAP)28
None identified.29
2.3.5.15 Calling Name Restriction (CNAR)30
None identified.31
2.3.5.16 Closed User Group (CUG)32
None identified.33
2.3.5.17 Do Not Disturb (DND)34
Same as CFU.35
2.3.5.18 Emergency Services36
None identified.37
X.S0023
1-39
2.3.5.19 Law Enforcement or CALEA1
None identified.2
2.3.5.20 Message Waiting Notification (MWN)3
None identified.4
2.3.5.21 Mobile Access Hunting (MAH)5
None identified.6
2.3.5.22 Password Call Acceptance (PCA)7
Applicable to ANSI-41 networks only. None identified.8
2.3.5.23 Preferred Language (PL)9
None identified.10
2.3.5.24 Priority Access and Channel Assignment (PACA)11
Applicable to ANSI-41 networks only. None identified.12
2.3.5.25 Remote Feature Control (RFC)13
Applicable to ANSI-41 networks only. None identified.14
2.3.5.26 Selective Call Acceptance (SCA)15
Applicable to ANSI-41 networks only. Callers that are not able to provide the correct password are16given denial treatment. Calls that are allowed may be subjected to OR treatment.17
2.3.5.27 Subscriber PIN Access (SPINA)18
Applicable to ANSI-41 networks only. None identified.19
2.3.5.28 Subscriber PIN Intercept (SPINI)20
Applicable to ANSI-41 networks only. None identified.21
2.3.5.29 Voice Message Retrieval (VMR)22
None identified.23
2.3.5.30 Voice Privacy (VP)24
None identified.25
2.3.5.31 3-Way Calls or Conference Calls26
None identified.27
28
X.S0023
1-40
2.4 Call Waiting (CW)1
2
2.4.1 General Description3
Call Waiting (CW) provides notification to a controlling subscriber of an incoming call while the4subscriber’s call is in the 2-way state. Subsequently, the controlling subscriber can either answer or5ignore the incoming call. If the controlling subscriber answers the second call, it may alternate6between the two calls.7
This service operates when the traffic channel at the controlling subscriber is not available and is8engaged in an active or held call. When a third party attempts to connect to that termination, the9controlling subscriber is given an appropriate indication of the waiting call. The maximum number of10waiting calls at one time per mobile access is one. In ANSI-41 mode, this means that no further calls11are offered to the subscriber while a call is waiting. In GSM mode, another call can be offered to the12subscriber while a call is waiting, but only one call may be waiting at any time.13
2.4.1.1 Applicability to Telecommunications Services14
Call Waiting is applicable to circuit switched voice telecommunications services.15
16
2.4.2 Normal Procedures With Successful Outcome17
18
2.4.2.1 Authorization (or Provision)19
No new authorization procedures are needed for either GSM or ANSI-41 foreign mode operation of20call waiting. The following describes authorization procedures for both GSM and ANSI-41 native21modes.22
CW may be generally available or may be provided after pre-arrangement with the service provider.23
GSM native subscriber: This supplementary service is provisioned for all Basic services subscribed24to and to which it is applicable, i.e. not provisioned to any subset of these BS.25
ANSI-41 native subscriber: CW may be authorized for the following options:26
Table 1: CW Subscription Options27
Subscription Options Values
Temporary Cancellation Demand. The subscriber is authorized tocancel or de-activate CW for a single call.
Permanent. CW may not be canceled orde-activated for a single call.
Activation Demand. The subscriber is authorized tocontrol the activation and de-activation ofCW.
Permanent. CW is active while authorized(unless canceled).
X.S0023
1-41
1
2.4.2.2 De-Authorization (or Withdrawal)2
CW may be withdrawn at the subscriber’s request or for administrative reasons.3
2.4.2.3 Registration4
CW has no registration.5
2.4.2.4 De-Registration (or Erasure)6
CW has no de-registration.7
2.4.2.5 Activation8
In both GSM and ANSI-41 foreign modes, the subscriber shall be provided with menu selections by9the mobile station to allow him/or her to activate the call waiting feature. Menu selections shall also be10available to the subscriber while in native mode as well. In addition, the user may also be able to11activate call waiting (depending on individual service provider’s preference) through the use of the12keypad, as follows:13
ANSI-41 native and foreign modes:14
CW may be activated upon authorization.15
CW may be activated by a Demand Activation authorized subscriber specifying a CW activation16feature code, as in:17
*FC + SEND .18
If the activation is accepted, the system shall indicate success with feature confirmation treatment.19
GSM native and foreign modes: This supplementary service shall be activated either collectively20for all applicable Basic Services or on a Basic Service group basis by the subscriber using a control21procedure, as specified in GSM 02.30 [20], or by the service provider. The controlling subscriber shall22be informed by the network of the success or otherwise of her action.23
2.4.2.6 De-Activation24
In both GSM and ANSI-41 foreign modes, the subscriber shall be provided with menu selections by25the mobile station to allow him/or her to de-activate the call waiting feature. Menu selections shall26also be available to the subscriber while in native mode as well. In addition, the user may also be able27to de-activate call waiting (depending on individual service provider’s preference) through the use of28the keypad, as follows:29
ANSI-41 native and foreign mode:30
CW shall be de-activated upon de-authorization.31
CW Demand De-Activation:32
CW may be de-activated by a Demand Activation authorized subscriber specifying a CW33de-activation feature code, as in:34
*FC0 + SEND .35
If the de-activation is accepted, the system shall indicate success with feature confirmation treatment.36
Temporary Cancellation During a Call (ANSI-41 Native Mode Only):37
X.S0023
1-42
CW may be canceled during a single call by a Demand Cancellation authorized subscriber issuing a1flash request and then specifying a CCW feature code, as in:2
*FC0 + SEND .3
If the cancellation is accepted, the system may indicate success with feature confirmation treatment4and then reconnect the call. At the completion of the call, CW shall resume the activation state prior5to using the cancel CW feature code.6
Temporary Cancellation With a Call Setup Request (ANSI-41 Native Mode Only):7
CW may be canceled for a single call concurrently with a call request by a Demand Cancellation8authorized subscriber specifying a CCW feature code and a termination address, as in:9
*FC0 + # + termination address + SEND .10
Alternatively:11
*FC + termination address + SEND 12
is possible, if a fixed length Temporary Cancellation feature code is distinct from the de-activation13feature code.14
If the cancellation is accepted, the system may indicate success with feature confirmation treatment15and then the call is allowed to proceed toward the termination address. At the completion of the call,16CW shall resume the activation state prior to using the cancel CW feature code.17
GSM native and foreign mode: The service shall be deactivated either collectively for all applicable18Basic Services or on a Basic Service group basis by the subscriber using a control procedure, as19specified in GSM 02.30 [20], or by the service provider. The controlling subscriber shall be informed20by the network of the success or otherwise of her action.21
2.4.2.7 Invocation22
CW is invoked when a incoming call attempt arrives for a subscriber who is already engaged in23conversation on a prior call, who does not have another call waiting, and who has CW active.24
There are functions or actions which exist on GSM (in GSM 02.83 [25]), but do not exist in ANSI-41,25and vice versa (see charts below). In order to achieve a seamless user Interface when roaming, it26would be better to either provide the menu selections as it is in a GSM handset, or some other27mechanism that can achieve the same goal.28
X.S0023
1-43
2.4.3 Normal Operation with Successful Outcome1
Menu selections shall be provided by the mobile station, in both foreign and native modes, to allow2the subscriber to control the operation of calls involving call waiting. Because, in general, GSM3networks provide more capabilities related to call waiting operation, the menu-driven procedures may4be different for a given subscriber depending on whether the serving network is GSM or ANSI-41. In5addition to the use of menu selections, a subscriber may use the keypad entries (shown in the tables6below) to control the operation of calls involving call waiting. Note that the subscriber would need to7use different set of keypad entries depending on whether the serving network is GSM or ANSI-41,8and thus the use of the shown keypad entries to control the operation of the calls is not encouraged.9In general, the menu-driven approach would be preferred instead.10
The following tables describe the call party actions and system reactions for CW on GSM and11ANSI-41.12
Table 2: 2-Way State for Call Waiting13
State: 2-way Condition The controlling subscriber is alerting theother party, or the controlling subscriberis in a two-way conversation with theother party.
GSM Called PartyAction
ANSI-41 Called PartyAction
System Reaction
A call arrives from acalling party for acontrolling subscriberin a two-wayconversation and withCW active.
A call arrives from acalling party for acontrollingsubscriber in atwo-wayconversation andwith CW active.
CW notification is applied to thecontrolling subscriber. The CWnotification is repeated once if thewaiting call is not answered.Audible ringing is applied to thecalling party until the call isanswered or given no answertreatment. Go to the 2-way CWnotification state.
14
X.S0023
1-44
The CW notification may be an audible Call Waiting Tone injected into the voice path, a message on1the alphanumeric display, or both.2
Table 3: 2-Way Notification State for Call Waiting3
State: 2-waynotification
Condition The controlling subscriber is in atwo-way conversation with the otherparty and call waiting notification isapplied.
GSM Called PartyAction
ANSI-41 Called PartyAction
System Reaction
The controllingsubscriber signalsa flash request bypressing 2 +SEND key .
The controllingsubscriber signals aflash request bypressing the SEND
key without digits.
Remove the call waitingnotification. Place the otherparty on hold. Connect thecontrolling subscriber andthe calling party. Go to the2-way CW state.
The controllingsubscriberrequests adisconnect bypressing the END
key.
The controllingsubscriber requestsa disconnect bypressing the END
key.
Release the other party.Remove the call waitingnotification. Apply thealerting to the controllingsubscriber for the callingparty. Go to the Alertingstate.
The controllingsubscriber signalsa flash request bypressing 1 +SEND key .
No equivalentfunction.
Release the other party.Remove the call waitingnotification. Connect thecontrolling subscriber andthe calling party. Go to the2-way CW notification state.
The controllingsubscriber signalsa flash request bypressing 0 +SEND key .
No equivalentfunction.
Remove the call waitingnotification. Place the UDUBcondition to the calling partyfor busying treatment. Go tothe 2-way CW notificationstate.
4
X.S0023
1-45
Table 4: 2-Way CW State for Call Waiting1
State: 2-way CW Condition The controlling subscriber is in atwo-way conversation with the otherparty and a third party is on hold.
GSM Called PartyAction
ANSI-41 Called partyAction
System Reaction
The controllingsubscriber signals aflash request bypressing 2 + SEND
key.
The controllingsubscriber signals aflash request bypressing the SEND
key without digits.
Place the other party onhold. Connect thecontrolling subscriberand the third party.Remain in the 2-way CWstate.
No equivalentfunction.
The controllingsubscriber requestsa disconnect bypressing the END
key.
Release the other party.Apply the recall distinctivealerting for the third partyto recall the controllingsubscriber. Optionallyapply audible alerting tothe held party. Go to theAlerting state.
The controllingsubscriber signals aflash request bypressing 1+ SEND
key.
No equivalentfunction.
Release the other party.Connect the controllingsubscriber and the heldparty. Go to the 2-wayCW notification state.
The controllingsubscriber signals aflash request bypressing 0+ SEND
key.
No equivalentfunction.
The held party isreleased. Remain in the2-way CW state.
The controllingsubscriber requestsa disconnect bypressing the END
key.
No equivalentfunction.
Release all calls.
2
2.4.3.1 Call Detail Record / Charging Requirements3
For GSM and ANSI-41 based network interoperability, no new or special recording capabilities are4needed.5
X.S0023
1-46
2.4.3.2 Interrogation1
In foreign modes, the interrogation procedure is not supported.2
GSM native mode3
The controlling subscriber may interrogate the network by the use of a control procedure, as specified4in GSM 02.30 [20]. The network shall respond with an appropriate indication telling the subscriber5whether the service is supported in this network and, if so, provide a list of all Basic Service groups to6which the Call waiting supplementary service is active.7
2.4.4 Exception Procedures or Unsuccessful Outcome8
9
2.4.4.1 Registration10
None identified.11
2.4.4.2 De-Registration / Erasure12
None identified.13
2.4.4.3 Activation14
If the subscriber is not authorized for the request, the system shall apply feature denial treatment15when activation is attempted.16
2.4.4.4 De-Activation17
Demand De-Activation: If the subscriber is not authorized for the request, the system shall apply18feature denial treatment when de-activation is attempted.19
Temporary Cancellation (ANSI-41 native mode only): If the subscriber is not authorized for the20request, the system shall apply feature denial treatment when de-activation is attempted.21
Temporary Cancellation With a Call Setup Request (ANSI-41 native mode only): If the22subscriber is not authorized for a Temporary Cancellation request made concurrently with a call setup23request, the system shall apply feature denial treatment and the call setup shall be denied.24
2.4.4.5 Invocation25
If the controlling subscriber is not authorized, if the controlling subscriber is alerting the other party, or26if resources are not available; give the calling party busy treatment. Remain in the 2-way state.27
2.4.4.6 Exceptions While Roaming28
None identified.29
2.4.4.7 Exceptions During Intersystem Handoff30
None identified.31
2.4.5 Alternate Procedures32
None identified.33
X.S0023
1-47
2.4.6 Interactions With Other Features and Services1
2
2.4.6.1 Advice of charge (AoC)3
None identified.4
2.4.6.2 Barring of All Outgoing Calls (BAOC)5
None identified.6
2.4.6.3 Barring of Outgoing International Calls (BOIC)7
None identified.8
2.4.6.4 Barring of Outgoing International Calls except those directed to the Home PLMN9(BOIC-exHC)10
None identified.11
2.4.6.5 Barring of All Incoming Calls (BAIC)12
None identified.13
2.4.6.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam)14
None identified.15
2.4.6.7 Call Delivery (CD)16
No interactions between CD and CW in foreign mode.17
While the subscriber is in native mode, CD may affect CW. That is, if CD is inactive while the18subscriber is roaming, the subscriber is considered to be inaccessible. Even if the subscriber has CW19active, incoming calls shall be given the subscriber inaccessible treatment.20
If CD is active and registered for a roaming subscriber, or if the subscriber is at home, CW works21normally.22
2.4.6.8 Call Forwarding—Busy (CFB)23
CW is invoked before CFB. If a call arrives for a busy subscriber able to receive a second call, the24called subscriber has both CW and CFB active, and no call is already waiting to be answered; the call25is presented to the subscriber with CW notification. If the CW call is not accepted, CFB is not invoked.26
If a call arrives for a busy subscriber, the called subscriber has both CW and CFB active, and if the27called subscriber is unable to receive a second call or has a call waiting to be answered; the call shall28be forwarded immediately by CFB.29
2.4.6.9 Call Forwarding—Default (CFD)30
CW is invoked before CFD. If a call arrives for a busy subscriber able to receive a second call, the31called subscriber has both CW and CFD active, and no call is waiting to be answered; the call is32presented to the subscriber with CW notification. If the call is not answered within a period of time33after applying the first CW notification, it shall be given no answer treatment.34
If a call arrives for a busy subscriber, the called subscriber has both CW and CFD active, and if the35called subscriber is unable to receive a second call or has a call waiting to be answered; the call shall36be forwarded immediately by CFD.37
X.S0023
1-48
2.4.6.10 Call Forwarding—No Answer / No Reply (CFNA / CFNRy)1
CW is invoked before CFNA. If a call arrives for a busy subscriber able to receive a second call, the2called subscriber has both CW and CFNA active, and no call is waiting to be answered; the call is3presented to the subscriber with CW notification. If the call is not answered within a period of time4after applying the first CW notification, it shall be given no answer treatment.5
If a call arrives for a busy subscriber, the called subscriber has both CW and CFNA active, and if the6called subscriber is unable to receive a second call or has a call waiting to be answered; the call shall7be given busy treatment.8
2.4.6.11 Call Forwarding—Not Reachable (CFNRc)9
None identified.10
2.4.6.12 Call Forwarding—Unconditional (CFU)11
CFU takes precedence over CW. That is, calls arriving when CFU is active are forwarded12unconditionally and not given CW treatment.13
2.4.6.13 Call Transfer (CT)14
CT and CW are mutually exclusive. A call incoming to a controlling subscriber setting up or engaged15in a CT shall be given busy treatment, even if the called subscriber has CW active.16
2.4.6.14 Call Waiting / Call Hold (CW / HOLD)17
Not applicable.18
2.4.6.15 Calling Number / Line Identification Presentation (CNIP / CLIP)19
If the called subscriber has CNIP and CW active, the CNI shall be presented with the CW notification20according to CNIP’s procedures.21
2.4.6.16 Calling Number / Line Identification Restriction (CNIR / CLIR)22
None identified.23
2.4.6.17 Calling Name Presentation (CNAP)24
None identified.25
2.4.6.18 Calling Name Restriction (CNAR)26
None identified.27
2.4.6.19 Closed User Group (CUG)28
None identified.29
2.4.6.20 Conference Calling / Multi Party Service (CC / MPTY)30
CC takes precedence over CW. If CC is invoked, CW shall not be invoked for an incoming call and31the subscriber shall be considered to be busy.32
2.4.6.21 Do Not Disturb (DND)33
DND takes precedence over CW. That is, calls arriving for a subscriber with DND and CW active shall34be refused and not be given CW treatment.35
2.4.6.22 Emergency Services36
None identified.37
X.S0023
1-49
2.4.6.23 Flexible Alerting (FA)1
CW of the FA Pilot Directory Number shall apply to calls to the Pilot Directory Number when the FA2group is considered to be busy, but one or more members that have CW active are able to accept a3CW call. CW alerting shall be applied to the members of the FA group able to accept a CW call. If the4FA Pilot Directory Number does not have CW active, CW may not apply.5
2.4.6.24 Message Waiting Notification (MWN)6
MWN pip tone may not be applied if the affected subscriber has requested CW cancellation or has7CW de-active.8
MWN pip tone shall not be applied for the call waiting legs of a call.9
The CW activation feature code may be the same as the MWN pip tone activation feature code. The10CW de-activation feature code may be the same as the MWN pip tone de-activation feature code.11The Cancel Call Waiting (CCW) feature code may be the same as the Cancel Message Waiting12Notification (CMWN) feature code.13
2.4.6.25 Mobile Access Hunting (MAH)14
Interaction between MAH and CW is beyond the scope of this Standard. The following describes a15possible implementation:16
For a single user MAH group, CW may be applied to a busy MAH member.17
For a multiple user MAH group, CW of the MAH Pilot Directory Number shall apply to calls to the Pilot18Directory Number when the MAH group is considered to be busy, but one or more of the MAH19members that have CW active are able to accept a CW call. CW alerting shall be applied to the20members of the MAH group able to accept a CW call. If the MAH Pilot Directory Number does not21have CW active, CW may not apply.22
2.4.6.26 Password Call Acceptance (PCA)23
PCA takes precedence over CW. Incoming calls to the subscriber with PCA and CW active shall be24screened by the PCA feature before being considered for CW.25
2.4.6.27 Preferred Language (PL)26
None identified.27
2.4.6.28 Priority Access and Channel Assignment (PACA)28
PACA has precedence over CW. The CW feature shall not be invoked for incoming calls to a29subscriber waiting for a PACA channel, as the subscriber shall be considered to be busy.30
2.4.6.29 Remote Feature Control (RFC)31
None identified.32
2.4.6.30 Selective Call Acceptance (SCA)33
SCA takes precedence over CW. Incoming calls to the subscriber with SCA and CW active shall be34screened by the SCA feature before being considered for CW.35
2.4.6.31 Subscriber PIN Access (SPINA)36
CW feature code requests shall be denied for an MS while SPINA is active.37
2.4.6.32 Subscriber PIN Intercept (SPINI)38
None identified.39
X.S0023
1-50
2.4.6.33 Three-Way Calling / Multi Party Service (3WC / MPTY)1
3WC and CW are mutually exclusive. A call incoming to a controlling subscriber setting up or2engaged in a three-way call shall be given busy treatment, even if the called subscriber has CW3active.4
A flash request from a subscriber authorized for 3WC, while CW alerting is being applied, shall be5used to respond to the CW call. If the controlling subscriber still desires a three-way call, it must first6dispose of the CW call before requesting a three-way call.7
2.4.6.34 Voice Message Retrieval (VMR)8
None identified.9
2.4.6.35 Voice Privacy (VP)10
None identified.11
12
X.S0023
1-51
2.5 Three-Way Calling (3WC) and Multi-Party (MPTY)1
2
2.5.1 General Description3
ANSI-41 Mode: Three-Way Calling (3WC) provides the subscriber the capability of adding a third4party to an established two-party call, so that all three parties may communicate in a three-way call. If5either of the two non-controlling parties to an established three-way call disconnects, the remaining6party is re-connected to the controlling subscriber as a normal two-party call. If the controlling7subscriber of a three-way call disconnects, the conference circuit and all other parties are released.8Digits included with flash requests when a termination address is not expected may be ignored.9Native mode user interface capabilities while operating in foreign mode are mobile station dependent.10
GSM Mode: Once a multi-party call is active, remote parties may be added, disconnected or11separated (i.e. removed from the multi-party call but remain connected to the served mobile12subscriber). The maximum number of remote parties is 5.13
2.5.1.1 Applicability to Telecommunications Services14
3WC/MPTY is applicable to voice telecommunication services.15
2.5.2 Normal Procedures With Successful Outcome16
17
2.5.2.1 Authorization (or Provision)18
GSM native subscribers: This supplementary service is provisioned for all Basic services19subscribed to and to which it is applicable, i.e. not provisioned to any subset of these BS. The20provision of the Call Hold supplementary service is also required.21
ANSI-41 native subscribers: 3WC may be generally available or may be provided after pre-22arrangement with the service provider.23
2.5.2.2 De-Authorization (or Withdrawal)24
3WC/MPTY may be withdrawn at the subscriber’s request or for administrative reasons.25
2.5.2.3 Registration26
3WC/MPTY has no registration.27
2.5.2.4 De-Registration (or Erasure)28
3WC/MPTY has no de-registration.29
2.5.2.5 Activation30
3WC/MPTY is activated upon authorization.31
2.5.2.6 De-Activation32
3WC/MPTY shall be de-activated upon de-authorization.33
2.5.2.7 Invocation34
ANSI-41 Mode: 3WC is invoked when the appropriate flash request is sent and the feature is35authorized.36
X.S0023
1-52
GSM Mode: Multi-Party service is invoked by the served mobile subscriber by use of a control1procedure, as defined in GSM 02.30 [20].2
2.5.3 Normal Operation with Successful Outcome3
4
2.5.3.1 ANSI-41 Mode5
1. 3WC allows a controlling subscriber to add a third party to an existing two-way call. If necessary,6the last party added to a call may be dropped.7
2. The controlling subscriber presses the SEND key without digits while in a two-way conversation to8put the other party on hold.9
One party is on hold. The system is waiting for the controlling subscriber to enter a feature code10or the address of a third party,11
If the controlling subscriber presses the SEND key without digits, the system reconnects the held12party.13
If the controlling subscriber presses the END key, the system releases the controlling subscriber.14Apply distinctive recall alerting to the controlling subscriber to recall the held party.15
If the controlling subscriber enters termination address + SEND, the system attempts to establish16a connection to the third party specified by the termination address allowing the controlling17subscriber to hear call progress tones and announcements.18
If the controlling subscriber enters a feature code, *FC + SEND, the system acts upon the feature19code. Apply feature confirmation treatment.20
If the controlling subscriber enters *FC + # + termination address + SEND, the system acts upon21the feature code. Applies feature confirmation treatment. Attempts to establish a connection to22the third party specified by the termination address allowing the controlling subscriber to hear call23progress tones and announcements.24
If an incoming call arrives for the controlling subscriber, the system applies busy treatment to the25calling party.26
If the held party disconnects, the system release the held party. The voice channel may be27released. Any further action by the subscriber is treated as a new service request.28
X.S0023
1-53
3. One party is on hold. The controlling subscriber is alerting the other party, or the controlling1subscriber is in a two-way conversation with a third party,2
If the controlling subscriber presses the SEND key without digits, the system connects the3controlling, held and third parties into a three-way call.4
If the controlling subscriber presses the END key, the system releases the controlling subscriber5and the third party. Apply distinctive recall alerting to the controlling subscriber to recall the held6party.7
If the controlling subscriber enters digits + SEND key, the system ignores any accompanying8digits. Connects the controlling, held and third parties into a three-way call.9
If the third party answers, the system allows a conversation with the third party.10
If the third party disconnects, the system releases the third party. Connects the held party.11
If an incoming call arrives for the controlling subscriber, the system applies busy treatment to the12calling party.13
If the held party disconnects, the system releases the held party.14
4. A connection is established between the controlling subscriber, a second party and a third party.15
If the controlling subscriber presses the SEND key without digits, the system releases the third16party. Connect the controlling subscriber and the second party.17
If the controlling subscriber presses the END key, the system releases the controlling subscriber18and two other parties.19
If the controlling subscriber enters digits + SEND key, the system ignores any accompanying20digits. Releases the third party. Connect the controlling subscriber and the second party.21
If the third party answers, the system allows a conversation with the third party.22
If the third party disconnects, the system releases the third party and connects the controlling23subscriber and the second party.24
If an incoming call arrives for the controlling subscriber, the system applies busy treatment to the25calling party.26
If the second party disconnects, the system releases the second party. Connect the controlling27subscriber and the third party.28
2.5.3.2 GSM Mode29
Only the served mobile subscriber shall be able to add remote parties to the multi-party call as30specified in GSM 02.84 [26].31
2.5.3.2.1 Beginning the multi-party call32
When the served mobile subscriber invokes multi-party, the network joins the active call and the call33on hold together into a multi-party call in which the served mobile subscriber and the remote parties34can all communicate with one another.35
X.S0023
1-54
2.5.3.2.2 Managing an active multi-party call1
During an active multi-party call, the served mobile subscriber shall be able to:2
1. Add another remote party,3
to which a private communication has been established, if the number of remote parties does not4then exceed the maximum number allowed, which results in an active multi-party call.5
A MPTY invoke notification shall be sent towards all remote parties. A Retrieve notification6(according to GSM 02.83 [25]) shall be sent towards all previously held remote parties.7
2. Put the connection to multi-party call on hold:8
(i.e., place her connection to the multi-party call on hold (and typically later retrieve it)). The served9mobile subscriber may make an enquiry call (e.g., to a potential new remote party) or process a10Call Waiting request from this state. While the multi-party call is on hold the remaining remote11parties in the multi-party call can have communication with each other.12
As a result of this scenario, the inquiry call or the accepted waiting call can be added to the multi-13party call or released. If the call is released by the served mobile subscriber or by the remote14party, the served mobile subscriber is in control of a held multi-party call.15
A Hold notification (according to GSM 02.83 [25]) shall be sent towards all remote parties.16
3. Separate a remote party:17
Explicitly choose one remote party to have a private communication with. This results in that18remote party being removed from the multi-party call which is placed on hold, and the conversation19between the served mobile subscriber and the designated remote party being a normal active call.20The remaining remote parties may have communication with each other in this state.21
As a result of this scenario the private communication can be added again to the multi-party call or22released. If the private call is released by the served mobile subscriber or by the remote party, the23served mobile subscriber is in control of a held multi-party call.24
A Hold notification (according to GSM 02.83 [25]) shall be sent towards all remote parties, except the25designated remote party to which a private communication was established.26
4. Terminate the entire multi-party call.27
When the served mobile subscriber releases, this is interpreted as a request for termination of the28entire multi-party call even if there are calls on hold.29
No further notification shall be sent.30
5. Disconnect a remote party:31
Explicitly release the remote parties on a one at a time basis. In the case when no remote parties32remain, the multi-party call is terminated.33
The notification about the held multiparty call towards the served mobile subscriber is given by the34MS, not by the network.35
X.S0023
1-55
2.5.3.2.3 Managing a held multi-party call1
During a held multi-party call the served mobile subscriber shall be able to:2
1. Retrieve the held multi-party call, which results in an active multi-party call.3
2. Initiate a new call.4
3. Process a Call Waiting request.5
4. Disconnect the held multi-party call. All calls belonging to the multi-party call shall be released.6
5. Disconnect a single remote party.7
During a held multi-party call the served mobile subscriber shall NOT be able to: Retrieve a single8remote party.9
2.5.3.2.4 Managing a single call and a MPTY10
a) Single active call11
If the served mobile subscriber is connected to a single active call (regardless whether it is a private12communication or a new initiated call) and has a MPTY on hold, she is able to:13
1. Disconnect the single active call.14
2. Disconnect the held MPTY.15
3. Disconnect both. All calls, even if they are on hold, shall be released.16
4. Join the single active call and the held MPTY together.17
This would result in an active MPTY, except if the number of remote parties exceeds the number18allowed.19
A MPTY invoke notification shall be sent towards all remote parties.20
A Retrieve notification (according to GSM 02.83 [25]) shall be sent towards the previously held21remote party.22
5. Alternate between both calls.23
24
b) Active MPTY and held call25
If the served mobile subscriber is connected to a active MPTY and has a single call on hold, she is26able to:27
1. Disconnect the active MPTY.28
2. Disconnect the single held call.29
3. Disconnect both. All calls, even if they are on hold, shall be released.30
4. Join the single held call and the active MPTY together.31
This would result in an active MPTY, except if the number of remote parties exceeds the number32allowed.33
A MPTY invoke notification shall be sent towards all remote parties. A Retrieve notification34(according to GSM 02.83 [25]) shall be sent towards all previously held remote parties.35
X.S0023
1-56
5. Alternate between both calls.1
If the served mobile subscriber is connected to an active Multi Party call and has a single call on2hold, a request for establishing a private communication shall be rejected by the network. (Because3this would lead to an active call and two calls on hold, which is not supported according to the GSM4Call Hold Supplementary Service).5
An indication shall be given to the served mobile subscriber with the reason for failure.6
2.5.3.2.5 Remote parties in a Multi-Party Call7
Any of the remote parties shall be able to:8
1. Put their connection to the multi-party call on hold (and typically later retrieve it). The requirements9of the Call Hold service then apply;10
2. Release from the multi-party call.11
If a remote party releases and no remote party then remains, the requirements of the normal call12release procedures then apply.13
2.5.3.3 Call Detail Record / Charging Requirements14
For GSM and ANSI-41 based network interoperability, no new or special recording capabilities are15needed.16
2.5.3.4 Interrogation17
GSM mode18
The controlling subscriber may interrogate the network by the use of a control procedure, as specified19in GSM 02.30 [20]. The network shall respond with an appropriate indication telling the subscriber20whether the service is supported in this network and, if so, provide a list of all Basic Service groups to21which the Call waiting supplementary service is active.22
2.5.4 Exception Procedures or Unsuccessful Outcome23
24
2.5.4.1 Registration25
None identified.26
2.5.4.2 De-Registration / Erasure27
None identified.28
2.5.4.3 Activation29
None identified.30
2.5.4.4 De-Activation31
None identified.32
X.S0023
1-57
2.5.4.5 Invocation1
ANSI-41 Mode2
The controlling subscriber is alerting the other party, or the controlling subscriber is in a two-way3conversation with the other party, if the controlling subscriber presses the SEND key, the system4applies denial treatment. Retain connections.5
One party is on hold, and the system is waiting for the controlling subscriber to enter a feature code6or the address of a third party,7
• if the controlling subscriber enters the termination address + SEND key, if the subscriber is8not authorized for the request, resources are not available, or the termination address was9not acceptable; then ignore any accompanying digits and the system applies denial10treatment. Retain existing connection to party on hold.11
• if the controlling subscriber enters *FC + SEND key, if the subscriber is not authorized for the12request, resources are not available, or the termination address was not acceptable; then13ignore any accompanying digits and the system applies denial treatment. Retain existing14connection to party on hold.15
• if the controlling subscriber enters *FC + # + termination address + SEND key, if the16subscriber is not authorized for the request, resources are not available, or the termination17address was not acceptable; then ignore any accompanying digits and the system applies18denial treatment. Retain existing connection to party on hold.19
GSM Mode20
If a served mobile subscriber attempts to invoke multi-party service and the network cannot accept21that request, the request shall be rejected and an indication shall be given to the served mobile22subscriber with a reason for denial. Some possible reasons for rejection are:23
service not subscribed;24
resources cannot be allocated;25
conflicting situation with other supplementary services;26
calls are not in appropriate state (e.g., one or more calls are not answered or are in the process27of being cleared);28
service not supported by the local PLMN.29
If the service provider cannot satisfy the request to add a further remote party (e.g., if the multi-party30call has been cleared or if the maximum number of remote parties allowed has already been reached)31the served mobile subscriber shall receive an indication that the request is denied, with the reason for32failure.33
If the radio path of the served mobile subscriber is lost permanently for any reason, the multi-party34call shall be released.35
2.5.4.6 Exceptions While Roaming36
None identified.37
2.5.4.7 Exceptions During Intersystem Handoff38
None identified.39
X.S0023
1-58
2.5.5 Alternate Procedures1
ANSI-412
An alternative procedures has been identified for 3WC. This procedure builds upon the normal 3WC3procedures.4
The controlling subscriber is alerting the other party, or the controlling subscriber is in a two-way5conversation with the other party:6
If the controlling subscriber enters a termination address + SEND , the system puts the other7party on hold. Atempts to establish a connection to the termination address.8
If the controlling subscriber enters a termination address + SEND , if the other party is alerting,9the controlling subscriber is not authorized for the request, resources are not available, or the10termination address was not acceptable; the system applies denial treatment. Reconnects the11controlling subscriber and the second party.12
If the controlling subscriber enters *FC + # + termination address + SEND , the system acts upon13the feature code. The system applies feature confirmation treatment. Puts the other party on14hold. Attempts to establish a connection to the termination address.15
If the controlling subscriber enters *FC + # + termination address + SEND , the system acts upon16the feature code. If the other party is alerting, the controlling subscriber is not authorized for the17request, resources are not available, or the termination address was not acceptable; the system18applies for denial treatment. Reconnects the controlling subscriber and the second party.19
20
GSM Mode21
None identified.22
23
2.5.6 Interactions With Other Features and Services24
25
2.5.6.1 Advice of charge (AoC)26
None identified.27
2.5.6.2 Barring of All Outgoing Calls (BAOC)28
None identified.29
2.5.6.3 Barring of Outgoing International Calls (BOIC)30
None identified.31
2.5.6.4 Barring of Outgoing International Calls except those directed to the Home PLMN32(BOIC-exHC)33
None identified.34
2.5.6.5 Barring of All Incoming Calls (BAIC)35
None identified.36
X.S0023
1-59
2.5.6.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam)1
None identified.2
2.5.6.7 Call Delivery (CD)3
None identified.4
2.5.6.8 Call Forwarding—Busy (CFB)5
None identified.6
2.5.6.9 Call Forwarding—Default (CFD)7
None identified.8
2.5.6.10 Call Forwarding—No Answer / No Reply (CFNA / CFNRy)9
None identified.10
2.5.6.11 Call Forwarding—Not Reachable (CFNRc)11
None identified.12
2.5.6.12 Call Forwarding—Unconditional (CFU)13
None identified.14
2.5.6.13 Call Transfer (CT)15
ANSI-41 Mode16
CT takes precedence over 3WC. When the controlling subscriber disconnects on an active three-way17call, and also has CT active, then the disconnect shall be used to transfer the call and the two non-18controlling parties remain connected.19
To avoid a call transfer, the controlling subscriber may force a three-way call to disconnect by20sending a flash request to drop the last party added and then disconnecting the remaining party.21
3WC takes precedence over CT for the interpretation of flash requests. If the controlling subscriber22presses SEND in the Holding 2-way state (and both CT and 3WC are active), the result is a23conference request rather than a CT drop party request. If the controlling subscriber presses SEND 24while in the 3-way state, the last party is requested to be dropped.25
2.5.6.14 Call Waiting / Call Hold (CW / HOLD)26
ANSI-41 Mode27
3WC and CW are mutually exclusive. A call incoming to a controlling subscriber setting up or28engaged in a three-way call shall be given busy treatment, even if the called subscriber has CW29active.30
A flash request from a subscriber authorized for 3WC, while CW alerting is being applied, shall be31used to respond to the CW call. If the controlling subscriber still desires a three-way call, it must first32dispose of the CW call before requesting a three-way call.33
GSM Mode34
A user who is active on a multi-party call, either as the served mobile subscriber or as remote party,35may receive an indication of a waiting call, provided that the maximum number of calls at the mobile36equipment is not exceeded.37
X.S0023
1-60
After the user has put the multi-party call on hold, the user may accept the waiting call.1
Any party involved in an active multi-party call may place the connection to the multi-party call on hold2and later retrieve it.3
2.5.6.15 Calling Number / Line Identification Presentation (CNIP / CLIP)4
None identified.5
2.5.6.16 Calling Number / Line Identification Restriction (CNIR / CLIR)6
ANSI-41 Mode7
If the 3WC controlling subscriber activates the Temporary CNIR Mode during the setup of a 3WC leg,8then the Temporary CNIR activation applies only to that call leg.9
If the 3WC controlling subscriber de-activates the Temporary CNIR Mode during the setup of a 3WC10leg, then the Temporary CNIR de-activation applies only to that call leg.11
2.5.6.17 Calling Name Presentation (CNAP)12
None identified.13
2.5.6.18 Calling Name Restriction (CNAR)14
None identified.15
2.5.6.19 Closed User Group (CUG)16
None identified.17
See GSM 02.85 [27], Section 1.6.84.1.18
2.5.6.20 Conference Calling / Multi Party Service (CC / MPTY)19
ANSI-41 Mode20
3WC takes precedence over CC. That is, a subscriber cannot add more parties to a 3WC call (in21effect trying to convert the 3WC call into a CC call). A 3WC can be converted to a two-way call with a22flash request to drop the last party. The two-way call can be converted into a conference call.23
GSM Mode24
It shall be possible for any remote party in a multi-party call to alternate between two different multi-25party calls.26
Served Mobile Subscriber:27
The served mobile subscriber cannot control more than one multi-party call at a time.28
It shall not be possible to invoke multi-party service if either or both of the initial calls are active parts29of one or two other multi-party calls.30
Multi-Party call controlled by one of the remote parties:31
The network shall not be required to prevent that a leg to one of the other remote parties can be part32of another multi-party call controlled by that remote party.33
X.S0023
1-61
2.5.6.21 Connected line identification presentation1
GSM Native Subscriber2
Remote parties in an existing multi-party call who have subscribed to connected line number3identification presentation shall not receive a new remote party’s number whenever a served mobile4subscriber adds a new remote party to the multi-party call.5
2.5.6.22 Do Not Disturb (DND)6
None identified.7
2.5.6.23 Emergency Services8
None identified.9
2.5.6.24 Flexible Alerting (FA)10
None identified.11
2.5.6.25 Message Waiting Notification (MWN)12
MWN pip tone shall only be applied for the first leg of the call.13
2.5.6.26 Mobile Access Hunting (MAH)14
None identified.15
2.5.6.27 Password Call Acceptance (PCA)16
None identified.17
2.5.6.28 Preferred Language (PL)18
None identified.19
2.5.6.29 Priority Access and Channel Assignment (PACA)20
None identified.21
2.5.6.30 Remote Feature Control (RFC)22
None identified.23
2.5.6.31 Selective Call Acceptance (SCA)24
None identified.25
2.5.6.32 Subscriber PIN Access (SPINA)26
3WC shall not be activated while SPINA is active.27
2.5.6.33 Subscriber PIN Intercept (SPINI)28
The service provider may require the 3WC invoking subscriber (with SPINI active) to enter the SPINI29PIN when initiating a three-way call. That is, the subscriber shall be requested to enter the SPINI PIN,30if the call leg to the third party meets the call type criteria for SPINI.31
2.5.6.34 Three-Way Calling / Multi Party Service (3WC / MPTY)32
Not applicable.33
2.5.6.35 Voice Message Retrieval (VMR)34
None identified.35
X.S0023
1-62
2.5.6.36 Voice Privacy (VP)1
None identified.2
X.S0023
1-63
2.6 Calling Number / Line Identification Presentation1
2
2.6.1 General Description3
Calling Number Identification Presentation (CNIP) or Calling Line Identification Presentation (CLIP)4provides the number identification of the calling party to the called subscriber. The terminating5network may receive the Calling Number Identification (CNI) as part of basic call setup. CNIP / CLIP6does not impact a subscriber's ability to originate calls or to receive calls.7
8
2.6.1.1 Applicability to Telecommunications Services9
For GSM native mode: CLIP applies to all circuit switched telecommunication services.10
For ANSI native mode: CNIP applies to voice telecommunication services only.11
2.6.2 GSM and ANSI-41 interoperability Feature Mapping12
The definition of which feature capabilities are mapped between GSM (in GSM 02.81 [23]) and13ANSI-41 modes is described below.14
2.6.2.1 ANSI-41 foreign mode Capabilities (GSM --> ANSI-41 Feature Mapping)15
The ability of the subscriber’s serving system to override calling number or line presentation16restriction invoked from the calling party’s serving system or PLMN is not supported.17
Connected Line Identification Presentation and Restriction (COLP / COLR) is not supported.18
Interrogation of the status of CLIP is not supported.19
2.6.2.2 GSM Foreign Mode Capabilities (ANSI-41 --> GSM Feature Mapping)20
The ability to display multiple calling party numbers, a sub-address, or a redirecting number is not21explicitly defined.22
If the called subscriber has call forwarding unconditional active, the ability to present the calling23number identification to the subscriber during an abbreviated (or reminder) alert is not supported.24
2.6.3 Normal Procedures With Successful Outcome25
2.6.3.1 Authorization (or Provision)26
CNIP / CLIP shall be generally available after pre-arrangement with the service provider.27
2.6.3.2 De-Authorization (or Withdrawal)28
CNIP / CLIP may be withdrawn at the subscriber’s request or for administrative reasons.29
2.6.3.3 Registration30
CNIP / CLIP has no registration.31
2.6.3.4 De-Registration (or Erasure)32
CNIP / CLIP has no de-registration (or erasure).33
X.S0023
1-64
2.6.3.5 Activation1
CNIP / CLIP shall be activated upon authorization (or provision).2
2.6.3.6 De-Activation3
CNIP / CLIP shall be de-activated upon de-authorization (or withdrawal).4
2.6.3.7 Invocation5
The network automatically invokes CNIP / CLIP upon incoming call set-up when calling number6identification is available and presentation is not restricted.7
2.6.4 Normal Operation with Successful Outcome8
If CNIP / CLIP service is authorized and active, and calling number identification is available, the9called party’s serving network shall provide the calling number identification during alerting on10incoming calls. In addition to or instead of the calling number identification the subscriber shall also11be given a Presentation Indicator and Screening Indicator associated with the calling number12identification.13
The originating network shall be capable of transmitting up to 15 digits of calling party number. The14subscriber’s serving system must likewise be capable of delivering up to 15 digits of calling party15number.16
If CNIP / CLIP service is not authorized or active, no calling number identification, presentation17indicator, or screening indicator shall be delivered to the subscriber, even if it is available to the18serving system.19
2.6.4.1 Call Detail Record / Charging Requirements20
For GSM and ANSI-41 based network interoperability, no new or special recording capabilities are21needed.22
2.6.4.2 Interrogation23
GSM mode only: The subscriber can request the status of the CLIP supplementary service.24
2.6.5 Exception Procedures or Unsuccessful Outcome25
26
2.6.5.1 Registration27
None identified.28
2.6.5.2 De-Registration / Erasure29
None identified.30
2.6.5.3 Activation31
None identified.32
2.6.5.4 De-Activation33
None identified.34
X.S0023
1-65
2.6.5.5 Invocation1
In some situations with insufficient signaling capability, if the calling party number identification is not2available, the called party / subscriber shall receive an indication that calling number identity is not3available. This indication may include an alphanumeric display indicatingnumber not available.4
For an international call with calling party number identification not available, the called party /5subscriber shall receive an indication that calling number identity is not available. This indication may6include an alphanumeric display indicating number not available.7
2.6.5.6 Exceptions While Roaming8
Some serving systems may not offer CNIP / CLIP to any subscriber. In this case, the subscriber shall9receive no indication or display during alerting of an incoming call.10
2.6.5.7 Exceptions During Intersystem Handoff11
Some serving systems may not offer CNIP / CLIP to any subscriber. In this case, the subscriber shall12receive no indication or display during alerting of an incoming call.13
2.6.6 Alternate Procedures14
None identified.15
2.6.7 Interactions With Other Features and Services16
17
2.6.7.1 Advice of charge (AoC)18
None identified.19
2.6.7.2 Barring of All Outgoing Calls (BAOC)20
None identified.21
2.6.7.3 Barring of Outgoing International Calls (BOIC)22
None identified.23
2.6.7.4 Barring of Outgoing International Calls except those directed to the Home PLMN24(BOIC-exHC)25
None identified.26
2.6.7.5 Barring of All Incoming Calls (BAIC)27
When BAIC is active, the subscriber shall receive no calling party identification or display.28
2.6.7.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam)29
When BIC-Roam is active and invoked, the subscriber shall receive no calling party identification or30display.31
2.6.7.7 Call Delivery (CD)32
When Call Delivery is not active, the subscriber shall receive no calling party identification or display.33
2.6.7.8 Call Forwarding—Busy (CFB)34
None identified.35
X.S0023
1-66
2.6.7.9 Call Forwarding—Default (CFD)1
None identified.2
2.6.7.10 Call Forwarding—No Answer / No Reply (CFNA / CFNRy)3
None identified.4
2.6.7.11 Call Forwarding—Not Reachable (CFNRc)5
None identified.6
2.6.7.12 Call Forwarding—Unconditional (CFU)7
ANSI-41 mode only: If the called subscriber has CNIP / CLIP active, the calling number8identification may be presented to the subscriber during an abbreviated (or reminder) alert in9accordance with CNIP / CLIP procedures.10
2.6.7.13 Call Transfer (CT)11
None identified.12
2.6.7.14 Call Waiting / Call Hold (CW / HOLD)13
If the called subscriber has CNIP / CLIP active, the calling party identification shall be presented to14the subscriber with the call waiting notification.15
2.6.7.14.1 Calling Number / Line Identification Presentation (CNIP / CLIP)16
Not applicable.17
2.6.7.15 Calling Number / Line Identification Restriction (CNIR / CLIR)18
CNIR / CLIR takes precedence over CNIP / CLIP.19
2.6.7.16 Calling Name Presentation (CNAP)20
Authorization and activation of CNAP may be linked to the authorization and activation of CNIP /21CLIP.22
2.6.7.17 Calling Name Restriction (CNAR)23
Authorization and activation of CNAR may be linked to the authorization and activation of CNIR /24CLIR.25
2.6.7.18 Closed User Group (CUG)26
None identified.27
2.6.7.19 Conference Calling / Multi Party Service (CC / MPTY)28
None identified.29
2.6.7.20 Do Not Disturb (DND)30
DND takes precedence over CNIP / CLIP. When DND is active and invoked, the subscriber shall31receive no calling party identification or display.32
2.6.7.21 Emergency Services33
None identified.34
2.6.7.22 Flexible Alerting (FA)35
None identified.36
X.S0023
1-67
2.6.7.23 Message Waiting Notification (MWN)1
None identified.2
2.6.7.24 Mobile Access Hunting (MAH)3
None identified.4
2.6.7.25 Over the Air Activation (OTA)5
None identified.6
2.6.7.26 Password Call Acceptance (PCA)7
None identified.8
2.6.7.27 Preferred Language (PL)9
It shall be possible to present information in the subscriber’s preferred language.10
2.6.7.28 Priority Access and Channel Assignment (PACA)11
None identified.12
2.6.7.29 Remote Feature Control (RFC)13
None identified.14
2.6.7.30 Selective Call Acceptance (SCA)15
None identified.16
2.6.7.31 Subscriber PIN Access (SPINA)17
None identified.18
2.6.7.32 Subscriber PIN Intercept (SPINI)19
None identified.20
2.6.7.33 Three-Way Calling / Multi Party Service (3WC / MPTY)21
None identified.22
2.6.7.34 Voice Message Retrieval (VMR)23
None identified.24
2.6.7.35 Voice Privacy (VP)25
None identified.26
27
X.S0023
1-68
2.7 Call Barring (CB) and Operator Determined Barring (ODB)1
2
2.7.1 General Description3
Call Barring (CB) Supplementary service consists of Outgoing Call Barring (OCB) and Incoming Call4Barring (ICB). It denies a mobile subscriber the ability to originate/terminate certain types of calls.5These can be applied separately per basic service group.6
Operator Determined Barring (ODB) allows the network operator or service provider to regulate, by7means of an exceptional procedure, access by the subscribers to services, by the barring of certain8categories of outgoing or incoming calls or of roaming.9
The purpose of this network feature is to be able to limit the service provider's financial exposure to10new subscribers, or to those who have not promptly paid their bills. It may only be applied to the11service provider's own subscribers.12
Application of Operator Determined Barring is controlled by the Service Provider on a subscriber-13basis (automatically applies to all basic service groups), by administrative interaction with the HLR;14this interface is not standardized.15
With the exception of the barring of roaming, the HLR effects Operator Determined Barring in a16similar manner to Service Provider Call Barring supplementary service. Consequently, the VLR and17MSC also execute the relevant Barring Conditions in similar manners. It is noted that there is no18password usage. Roaming is barred by the HLR when the MS is in a PLMN other than the Home19PLMN or not in the Home PLMN Country as applicable.20
Operator Determined Barring is a GSM feature. An identical feature does not exist in ANSI-41,21although portions of it may be implemented by an operator using ANSI-41. The following sections22separately describe the following GSM ODB options for which interoperability can be supported in23some form at least (note that the first two are also Call Barring supplementary services):24
Barring outgoing calls25
Barring incoming calls26
Barring of roaming27
Barring of Supplementary Services Management28
Barring of registration of call forward-to numbers29
Barring of invocation of call transfer30
Description of Barring of Outgoing Calls31
The operator may select a barring program that prevents certain types of outgoing calls from being32originated by the MS.33
ODB in GSM is documented in GSM 02.41 [21]. Call Barring Supplementary Services in GSM is34documented in GSM 02.88 [29].35
Barring of outgoing calls with a wider range of conditions can be implemented using the ANSI-4136Origination Indicator parameter, which is provided by the HLR to the serving MSC/VLR upon37subscriber registration, as defined in Chapter 5 of ANSI-41 [2]. The Origination Indicator specifies38which types of call originations are permitted, as opposed to which types of call originations are39barred or restricted in GSM.40
X.S0023
1-69
The main problem for roaming interoperability is that for GSM and ANSI-41 the call barring programs1are based on different screening criteria. In GSM barring is based on the concept of PLMN, and calls2are generally permitted to all terminals within the country of a particular PLMN (i.e., fixed and mobile3terminals). ANSI-41 allows more specific barring programs such as ‘local calls only’, or a specific DN.4As a result of this conflict, IIF functionality is required to support subscribers using their non-native5mode.6
The mapping of GSM and ANSI-41 outgoing barring conditions may be accomplished as follows:7
Table 5: ANSI-41 Foreign Mode Interoperability for Barring of Outgoing Calls8
GSM Native Mode ANSI-41 Equivalent
Bar all outgoing calls Origination denied
Bar all outgoing international calls National long distance allowed (whichincludes local calls).
Bar all outgoing international callsexcept to HPLMN country (BOIC-exHC)
National long distance allowed (whichincludes local calls).
9
Table 6: GSM Foreign Mode Interoperability for Outgoing Call Restrictions10
ANSI-41 Native Mode GSM Equivalent (option: either ODB orOCB)
Origination denied Bar all outgoing calls (BAOC)
Local Calls Only Allowed Bar all outgoing calls (BAOC)
Selected leading digits of directorynumber allowed
Bar all outgoing calls (BAOC)
National long distance allowed Bar outgoing international calls (BOIC)
Allow international calls No barring
Allow single directory number only(i.e., hotline)
Bar all outgoing calls (BAOC)
11
2.7.1.1 Description of Barring of Incoming Calls12
Barring of incoming calls takes place at the HLR for native mode and foreign mode. To support13interoperability of barring incoming calls when roaming outside the HPLMN country (BIC-Roam), the14true serving system identity (SID) must be passed to the HLR upon registration. Otherwise, this15feature must be supported from the IIF.16
2.7.1.2 Description of ODB Barring of Roaming17
Barring of roaming takes place at the HLR. There is no IIF involvement, beyond the mapping of18registration operations between GSM and ANSI-41 based networks. Upon activation of ODB for19barring of roaming and ODB Barring of all Outgoing Calls when Roaming Outside the HPLMN20country, the HLR can be set to deny registration. The degree of granularity to which roaming can be21denied (e.g., roaming outside home PLMN country) shall be determined by the HLR capabilities.22
X.S0023
1-70
2.7.1.3 Description of ODB Barring of Supplementary Services Management.1
Barring of supplementary services management takes place at the HLR. There is no IIF involvement2(other than transfer of services management requests between GSM and ANSI-41 based networks).3Upon activation of ODB for barring of supplementary services management, the HLR can be set to4deny these user operations. The degree to which supplementary services management can be5denied shall be determined by the HLR capabilities.6
2.7.1.4 Description of ODB Barring of Registration of Call Forward-to Numbers7
Barring of registration of call forward-to numbers takes place at the HLR. There is no IIF involvement.8Upon activation of ODB for barring of registration of call forward-to numbers, the HLR can be set to9deny registration of these numbers. The degree of granularity to which registration can be denied10(e.g., Barring of registration of any international call forward-to number) shall be determined by the11HLR capabilities.12
2.7.1.5 Description of ODB Barring of Invocation of Call Transfer13
Barring of call transfer is possible in ANSI-41 based networks by restriction in the subscriber profile.14There is no IIF involvement. It is not possible to conditionally bar call transfer (based on the charging15conditions for the various call legs) as described in the GSM ODB Stage 1 description.16
2.7.1.6 Applicability to Telecommunications Services17
CB and ODB applies to all telecommunications services except emergency calls and possibly certain18outgoing free calls (e.g., calls to customer care).19
2.7.2 Normal Procedures with Successful Outcome20
ODB is an administrative feature. There are no user procedures for authorization, de-authorization,21registration, or de-registration.22
2.7.2.1 Activation23
Table 7: Call Barring Activation Options24
Activation Option Procedure
ODB Service provider controlled activation Determined by the service provider atprovisioning time or at a later date due toadministrative reasons. Cannot be controlled bythe subscriber.
Call Barring Service provider controlledactivation
Determined by the service provider atprovisioning time or at a later date due toadministrative reasons. Can be controlled by thesubscriber in GSM native mode.
25
X.S0023
1-71
2.7.2.2 De-activation1
Table 8: Call Barring Deactivation Options2
De-Activation Option Procedure
ODB Service provider controlled activation Determined by the service provider atprovisioning time or at a later date due toadministrative reasons. Cannot be controlled bythe subscriber.
Call Barring Service provider controlledactivation
Determined by the service provider atprovisioning time or at a later date due toadministrative reasons. Can be controlled by thesubscriber in GSM native mode.
3
2.7.2.3 Invocation4
Call Barring and ODB are invoked automatically by the network for subscribers that have it active,5upon subscriber or network actions that are barred.6
2.7.3 Normal Operation with Successful Outcome7
A subscriber that attempts to originate a call for which call barring or operator determined barring of8outgoing calls has been activated shall receive call denial treatment (e.g., a re-order tone and9announcement). Likewise, a caller that attempts to terminate a call for which call barring or operator10determined barring of incoming calls has been activated shall receive call denial treatment (e.g., a re-11order tone and announcement).12
A subscriber that attempts to perform other barred operations (e.g., management of supplementary13services) shall receive a notification indicating denial of the operation.14
Call Barring and ODB does not affect the origination of emergency calls.15
2.7.3.1 Call Detail Record16
For GSM and ANSI-41 based network interoperability, no new or special recording capabilities are17needed.18
2.7.4 Exception Procedures or Unsuccessful Outcome19
20
2.7.4.1 Provisioning21
Since GSM PLMNs may not support many of the provisioning criteria in ANSI-41 networks, service22provisioning shall revert to the closest available criterion as described above.23
2.7.4.2 Exceptions while Roaming24
None identified.25
2.7.4.3 Exceptions during Intersystem Handoff26
None identified.27
X.S0023
1-72
2.7.5 Interactions with Other Features and Services1
2
2.7.5.1 Advice of Charge (AoC) or Prepaid Charging (PPC)3
AoC and PPC take precedence over Call Barring and ODB in the following sense. If service is denied4by the AoC or PPC application due to non-payment, then calls shall not be delivered to or sent from5the mobile subscriber even if the barring program criteria are met. Whether or not forwarding to the6diversion number is done is beyond the scope of this document.7
2.7.5.2 Barring of Incoming Calls (Call Barring Supplementary Services)8
Calls shall be denied if either Operator Determined Barring or Barring Of Incoming Calls determine9that the call is to be barred.10
If a call is barred due to both Operator Determined Barring and Barring Of Incoming Calls, then the11message or notification returned towards the caller shall be the same as if the barring was due solely12to Operator Determined Barring.13
2.7.5.3 Barring of Outgoing Calls (Call Barring Supplementary Services)14
Calls shall be denied if either Operator Determined Barring or Barring Of Outgoing Calls determine15that the call is to be barred.16
If a call is barred due to both Operator Determined Barring and Barring Of Outgoing Calls, then the17message or notification returned towards the caller shall be the same as if the barring was due solely18to Operator Determined Barring.19
2.7.5.4 Call Delivery (CD)20
Call Barring and ODB takes precedence over CD. If an incoming call arrives for a subscriber with21Barring / ODB and CD active, the call is managed by the barring program first. Only if Call Barring22and ODB accepts the call, is CD attempted. If Barring / ODB refuses the call, the call is given barring /23ODB refusal treatment.24
2.7.5.5 Call Forwarding—Busy (CFB)25
Call Barring (CB)/ODB takes precedence over CFB. If an incoming call arrives for a subscriber with26both CB/ODB and CFB active, the call is screened by the CB/ODB program first. If CB and ODB27accepts the call, an attempt is made to deliver or terminate the call to the subscriber. If the subscriber28is busy, then CFB is invoked.29
If CFB is in contravention of a Call Barring / Operator Determined Barring Category, when the latter is30activated, then the activation shall result in making CFB quiescent. If the subscriber attempts to31activate a new CFB program in contravention of a Call Barring / Operator Determined Barring32Category, then the activation shall be denied, and the subscriber informed of the denial.33
2.7.5.6 ANSI-41 Call Forwarding—Default (CFD)34
CB/ODB takes precedence over CFD. If an incoming call arrives for a subscriber with CB/ODB and35CFD active, the call is screened by CB/ODB first. If CB and ODB accepts the call, an attempt is made36to deliver or terminate the call to the subscriber. If the subscriber does not or cannot answer the call,37then CFD is invoked.38
If CFD is in contravention of a Call Barring / Operator Determined Barring Category, when the latter is39activated, then the activation shall result in making CFD quiescent. If the subscriber attempts to40activate a new CFD program in contravention of a Call Barring / Operator Determined Barring41Category, then the activation shall be denied, and the subscriber informed of the denial.42
X.S0023
1-73
Call Forwarding—No Answer (ANSI-41 CFNA = GSM CF No Reply (CFNRy) and GSM CF Not1Reachable (CFNRc))2
CB/ODB takes precedence over CFNA. If an incoming call arrives for a subscriber with CB/ODB and3CFNA active, the call is screened by CB/ODB first. If CB and ODB accepts the call, an attempt is4made to deliver or terminate the call to the subscriber. If the subscriber does not or cannot answer the5call, then CFNA is invoked.6
If CFNA is in contravention of a Call Barring / Operator Determined Barring Category, when the latter7is activated, then the activation shall result in making CFNA quiescent. If the subscriber attempts to8activate a new CFNA program in contravention of a Call Barring / Operator Determined Barring9Category, then the activation shall be denied, and the subscriber informed of the denial.10
2.7.5.7 Call Forwarding—Unconditional (CFU)11
Interaction between ODB and CFU is beyond the scope of this Standard. The following describes a12possible implementation:13
CB/ODB takes precedence over CFU. If an incoming call arrives for a subscriber with CB/ODB and14CFU active, incoming calls are denied according to the ODB option, except when Barring of Incoming15Calls when Roaming Outside the HPLMN country is active, CFU has precedence).16
If CFU is in contravention of a Call Barring/ Operator Determined Barring Category, when the latter is17activated, then the activation shall result in making CFU quiescent, (except in the case of Barring of18Incoming Calls when Roaming outside the HPLMN Country, in which case CFU takes precedence). If19the subscriber attempts to activate a new CFU program in contravention of a Call Barring / Operator20Determined Barring Category, then the activation shall be denied, and the subscriber informed of the21denial.22
2.7.5.8 Call Transfer (CT)23
If the subscriber attempts to invoke a call transfer in contravention of a Call Barring / Operator24Determined Barring category, then the invocation shall be denied, and the subscriber informed of the25denial.26
2.7.5.9 Call Waiting (CW) or Call Hold (CH)27
ODB takes precedence over CW. Incoming calls to the subscriber with CB/ODB and CW active shall28be screened by the CB/ODB feature before being considered for CW.29
2.7.5.10 Calling Number/Line Identification Presentation (CNIP/CLIP)30
None identified.31
2.7.5.11 Calling Number/Line Identification Restriction (CNIR/CLIR)32
If the calling number indicatespresentation restricted, the calling number shall not be presented to the33called party, the called station, the diversion party, or the diversion station.34
2.7.5.12 Closed User Group (CUG)35
See GSM 02.85 [27].36
If a call is barred due to both Call Barring / Operator Determined Barring and CUG restrictions, then37the message or notification returned towards the caller shall be the same as if the barring was due38solely to Call Barring / Operator Determined Barring.39
2.7.5.13 Conference Calling / Multi Party Service (CC / MPTY)40
None identified.41
X.S0023
1-74
2.7.5.14 Do Not Disturb (DND)1
Interaction between CB/ODB and DND is beyond the scope of this Standard. The following describes2a possible implementation:3
CB/ODB takes precedence over DND. That is, an incoming call to a subscriber with CB/ODB and4DND active is given CB/ODB treatment.5
2.7.5.15 Emergency Services6
Emergency Services takes precedence over CB/ODB. A call to or from an authorized emergency7service bureau shall not be refused by CB/ODB.8
2.7.5.16 Flexible Alerting (FA)9
Interaction between FA and CB/ODB is beyond the scope of this Standard. The following describes a10possible implementation:11
CB/ODB on the FA Pilot Directory Number takes precedence over FA. That is, calls to the FA Pilot12Directory Number with ODB active are given ODB treatment first. If CB/ODB screening fails, the call13is refused. If CB/ODB screening passes, the call is given FA treatment.14
2.7.5.17 Message Waiting Notification (MWN)15
None identified.16
2.7.5.18 Mobile Access Hunting (MAH)17
Interaction between MAH and CB/ODB is beyond the scope of this Standard. The following describes18a possible implementation:19
CB/ODB of the MAH Pilot Directory Number takes precedence over MAH. That is, calls to the MAH20Pilot Directory Number with CB/ODB active are given CB/ODB treatment first. If CB/ODB screening21fails, the call is refused. If CB/ODB screening passes, the call is given MAH treatment.22
2.7.5.19 Password Call Acceptance (BIC)23
Not applicable.24
2.7.5.20 Preferred Language (PL)25
None identified.26
2.7.5.21 Priority Access and Channel Assignment (PACA)27
None identified.28
2.7.5.22 Remote Feature Control (RFC)29
TBD.30
2.7.5.23 Subscriber PIN Access (SPINA)31
None identified32
2.7.5.24 Subscriber PIN Intercept (SPINI)33
None identified.34
2.7.5.25 Three-Way Calling (3WC)35
None identified.36
X.S0023
1-75
2.7.5.26 Voice Message Retrieval (VMR)1
None identified.2
2.7.5.27 Voice Privacy (VP)3
None identified.4
X.S0023
1-76
2.8 Short Message Teleservice Support (ANSI-41 Networks)1
2
2.8.1 General Description3
A short message teleservice is a mechanism for information delivery end to end between two Short4Message Entities (SMEs). The source of the information may be a mobile station or a Teleservice5Server (TS). The information may be text based, (e.g., an ANSI-41 Cellular Messaging Teleservice6(TDMA or CDMA CMT) message or a GSM short message service (SMS) text message), or it may be7coded information destined for the mobile station’s storage and use, (e.g., over the air activation or8programming data, or GSM Message Waiting Indication (MWI)). In ANSI-41, unique teleservice9formats are defined to deliver different types of information. Conversely, in GSM, both text based and10coded information is generically delivered via GSM SMS. The information delivered from the source11to the destination is known as user data.12
SMS teleservices require the use of a Short Message Service Center (SMS-C), also called a13Message Center (MC) or Teleservice Server (TS) in ANSI-41, to provide store and forward functions.14Thus, an ANSI-41 or GSM network needs to support the transfer of SMS teleservice messages15between the SMS-C and the mobile station. For each subscriber, a different SMS-C may be assigned16as the home SMS-C for each SMS teleservice. For mobile originated teleservices, the address of the17home SMS-C can be provided by the mobile station. The address of the SMS-C would be used for18routing purposes in the network when the mobile station originates a SMS teleservice message.19
Two different categories of point-to-point SMS teleservices have been defined: mobile originated20(MO) and mobile terminated (MT). Mobile originated SMS messages shall be transported from a21mobile station to the subscriber’s home SMS-C. These may be destined for other mobile users, or for22subscribers on a fixed network. Mobile terminated messages shall be transported from the SMS-C to23a mobile station. These may be sent to the SMS-C from other mobile users (via a mobile originated24SMS teleservice) or from a variety of other sources, (e.g., speech, telex, facsimile, and gateway25server).26
An active mobile station (MS) is allowed to receive an SMS teleservice message at any time it is in27service on a GSM or ANSI-41 digital network, independently of whether or not there is a voice or data28call in progress. An acknowledgement message shall always be returned to the SMS-C, either29confirming that the mobile station has received the teleservice message, or informing the SMS-C that30it was impossible to deliver the short message to the mobile station, including the reason why.31
An active mobile station is allowed to submit a teleservice message at any time it is in service on a32GSM or ANSI-41 digital network, independently of whether or not there is a voice or data call in33progress. An acknowledgement message shall always be returned to the mobile station, either34confirming that the SMS-C has received the teleservice message, or informing the mobile station that35it was impossible to deliver the teleservice message to the SMS-C, including the reason why.36
Both ANSI-41 and GSM native subscribers shall be capable of submitting and receiving SMS37teleservice messages in both native and foreign mode. Note that teleservice delivery is not supported38in analog AMPS mode.39
The support of privacy indicators, character sets, validity periods and alert options shall be limited by40existing standards.41
X.S0023
1-77
2.8.2 Normal Procedures with Successful Outcome1
This section describes the normal procedures that result in a successful outcome.2
2.8.2.1 Authorization (or Provision)3
The service is made available to an individual subscriber after necessary arrangements have been4made with the home service provider. Authorized service may include:5
Only mobile originated SMS teleservices6
Only mobile terminated SMS teleservices7
Both mobile originated and mobile terminated SMS teleservices8
2.8.2.2 De-Authorization (or Withdrawal)9
The service is removed on an individual basis from subscribers provided with the service after10necessary arrangements have been made with the home service provider. Authorized service may11include:12
Only mobile originated SMS teleservices13
Only mobile terminated SMS teleservices14
Both mobile originated and mobile terminated SMS teleservices15
2.8.2.3 Registration16
Mobile terminated SMS teleservice registration shall be as a result of Authorization.17
For mobile originated SMS teleservices the following information shall be registered in the mobile18station:19
SMS-C address(es) as needed for different mobile originated SMS teleservices or applications.20
2.8.2.4 De-Registration (or Erasure)21
Mobile terminated SMS teleservice de-registration shall be as a result of withdrawal.22
For mobile originated SMS teleservices the following information may be erased in the mobile station:23
SMS-C address(es) as needed for different mobile originated SMS teleservices or applications.24
2.8.2.5 Activation25
Both mobile originated and mobile terminated SMS teleservices shall be activated as the result of26authorization. When operating in GSM or ANSI-41 foreign mode, there is no special activation27process required.28
2.8.2.6 De-Activation29
Both mobile originated and mobile terminated SMS teleservice de-activation shall be the result of de-30authorization. When operating in GSM or ANSI-41 foreign mode, there is no special de-activation31process required.32
X.S0023
1-78
2.8.2.7 Invocation1
Invocation shall be the result of:2
A mobile station needing to send user data to another Short Message Entity (SME).3
A SME needing to send user data to a mobile station.4
2.8.2.8 Interrogation5
Interrogation shall not be possible for mobile terminated SMS teleservices.6
For mobile originated SMS teleservices, the user shall be able to interrogate if they have any SMS-C7addresses registered on their mobile station.8
2.8.3 Normal Operation with Successful Outcome9
For mobile terminated SMS teleservices, the following normal operation applies. Upon receiving a10request from an SME, the SMS-C shall:11
Determine the location of the mobile station12
Attempt to deliver the user data to the mobile station13
If notification was requested, an indication shall be passed back to the user.14
For mobile originated SMS teleservices, the following normal operation applies. The mobile station15shall send user data to the network including the following information:16
Destination address;17
Home SMS-C address;18
Originating mobile identifier19
If notification is required.20
If notification was requested, an indication shall be passed back to the user.21
2.8.3.1 Call Detail Record / Charging Requirements22
For GSM and ANSI-41 interoperability, no new or special recording capabilities are needed.23
2.8.4 Exception Procedures or Unsuccessful Outcome24
This section describes abnormal situations not described in “Normal Operation with Successful25Outcome”. Procedures on time-outs, unexpected signaling responses, and other such events may be26defined.27
2.8.4.1 Authorization (or Provision)28
An attempt to re-provision an already provisioned service shall result in an indication to the service29provider.30
2.8.4.2 De-Authorization / Withdrawal31
An attempt to withdraw a service that has not been provisioned shall result in an indication being32provided to the service provider.33
X.S0023
1-79
2.8.4.3 Registration1
None identified at this time.2
2.8.4.4 De-registration / Erasure3
Not applicable.4
2.8.4.5 Activation5
Not applicable.6
2.8.4.6 De-Activation7
Not applicable.8
2.8.4.7 Invocation9
For mobile terminated teleservices, if the SMS-C attempts to deliver user data to the mobile station10and is unsuccessful, an indication shall be presented to the SMS-C. Possible causes may include:11
insufficient network resources;12
service not supported;13
service not subscribed to;14
insufficient mobile memory resources;15
insufficient information;16
conflicting situation with other supplementary services (e.g., call barring has been activated);17
subscriber not reachable.18
For mobile originated teleservices, if the mobile station attempts to deliver user data to the network19and is unsuccessful, the user shall be presented with an indication. Possible causes may include:20
insufficient network resources21
service not supported22
service not subscribed to23
insufficient information;24
conflicting situation with other supplementary services (e.g., call barring has been activated).25
2.8.4.8 Interrogation26
Not applicable.27
2.8.4.9 Exceptions while Roaming28
None.29
2.8.4.10 Exceptions during Intersystem Handoff30
None Identified31
2.8.5 Alternate Procedures32
None Identified33
X.S0023
1-80
2.8.6 Interactions with Other Features and Services1
2
2.8.6.1 Advice of charge (AoC)3
None Identified4
2.8.6.2 Barring of All Outgoing Calls (BAOC)5
Per GSM 02.04 [18], BAOC shall inhibit SMS origination, but this interaction is generally not invoked.6
2.8.6.3 Barring of Outgoing International Calls (BOIC)7
Per GSM 02.04 [18], BOIC shall inhibit SMS origination, but this interaction is generally not invoked.8
2.8.6.4 Barring of Outgoing International Calls except those directed to the Home PLMN9(BOIC-exHC)10
Per GSM 02.04 [18], BOIC-exHC shall inhibit SMS origination, but this interaction is generally not11invoked.12
2.8.6.5 Barring of All Incoming Calls (BAIC)13
Per GSM 02.04 [18], BAIC shall inhibit SMS delivery, but this interaction is generally not invoked.14
2.8.6.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam)15
Per GSM 02.04 [18], BIC-Roam shall inhibit SMS delivery, but this interaction is generally not16invoked.17
2.8.6.7 Call Delivery (CD)18
None Identified19
2.8.6.8 Call Forwarding—Busy (CFB)20
None Identified21
2.8.6.9 Call Forwarding—Default (CFD)22
None Identified23
2.8.6.10 Call Forwarding—No Answer / No Reply (CFNA / CFNRy)24
None Identified25
2.8.6.11 Call Forwarding—Not Reachable (CFNRc)26
None Identified27
2.8.6.12 Call Forwarding—Unconditional (CFU)28
None Identified29
2.8.6.13 Call Transfer (CT)30
None Identified31
2.8.6.14 Call Waiting / Call Hold (CW / HOLD)32
None Identified33
2.8.6.15 Calling Number / Line Identification Presentation (CNIP / CLIP)34
None Identified35
X.S0023
1-81
2.8.6.16 Calling Number / Line Identification Restriction (CNIR / CLIR)1
None Identified2
2.8.6.17 Calling Name Presentation (CNAP)3
None Identified4
2.8.6.18 Calling Name Restriction (CNAR)5
None Identified6
2.8.6.19 Closed User Group (CUG)7
None Identified8
2.8.6.20 Conference Calling / Multi Party Service (CC / MPTY)9
None Identified10
2.8.6.21 Do Not Disturb (DND)11
None Identified12
2.8.6.22 Emergency Services13
None Identified14
2.8.6.23 Flexible Alerting (FA)15
None Identified16
2.8.6.24 Message Waiting Notification (MWN)17
None Identified18
2.8.6.25 Mobile Access Hunting (MAH)19
None Identified20
2.8.6.26 Password Call Acceptance (PCA)21
None Identified22
2.8.6.27 Preferred Language (PL)23
None Identified24
2.8.6.28 Priority Access and Channel Assignment (PACA)25
None Identified26
2.8.6.29 Remote Feature Control (RFC)27
None Identified28
2.8.6.30 Selective Call Acceptance (SCA)29
None Identified30
2.8.6.31 Subscriber PIN Access (SPINA)31
None Identified32
2.8.6.32 Subscriber PIN Intercept (SPINI)33
None Identified34
X.S0023
1-82
2.8.6.33 Three-Way Calling / Multi Party Service (3WC / MPTY)1
None Identified2
2.8.6.34 Voice Message Retrieval (VMR)3
None Identified4
2.8.6.35 Voice Privacy (VP)5
None Identified6
X.S0023
1-83
2.9 Message Waiting Notification1
2
2.9.1 General Description3
Message Waiting Notification (MWN) informs authorized and activated subscribers when a voice4message is available for retrieval.5
MWN may use pip tone, alert pip tone, or a MS display indication (including message waiting6indication and message waiting count) to inform a subscriber of an unretrieved voice message(s).7Once all voice messages have been retrieved, the pip tone, alert pip tone, or a MS display indication8must be removed.9
Pip tone notification provides an audible, stuttered tone to the subscriber in the initial moment of a call10origination or termination. Alert pip tone provides an audible alert tone to the subscriber when the MS11is idle. MS display indication provides an icon or display text or both indications of the number of12unretrieved voice messages (i.e. count).13
If MS display indication with count is provided, and the number of unretrieved voice messages has14increased, the display indication on the MS must be updated.15
MWN does not impact a subscriber’s ability to originate calls or to receive calls, or to use other16features or supplementary services.17
2.9.1.1 Applicability to Telecommunications Services18
Message Waiting Notification applies to voice telecommunication services.19
2.9.1.2 GSM and ANSI-41 interoperability Feature Mapping20
The definition of which feature capabilities are mapped between GSM and ANSI-41 modes is21described below.22
2.9.1.2.1 ANSI-41 foreign mode Capabilities (GSM --> ANSI-41Feature Mapping)23
MWN is done via an MS display message waiting indication. An MS display message waiting count is24provided to the MS as available. The MS shall be capable of receiving the count.25
MWN via an MS display indication may be supplemented with audible pip tone alerting.26
2.9.1.2.2 GSM Foreign Mode Capabilities (ANSI-41--> GSM Feature Mapping)27
Audible pip tone notification is not supported, but MS display indication shall be provided as required.28The ability to activate and de-activate various means of MWN alerting shall not be supported.29
2.9.2 Normal Procedures With Successful Outcome30
2.9.2.1 Authorization (or Provision)31
MWN may be generally available or may be provided after pre-arrangement with the service provider.32Pip tone, alert pip tone, or MS display indication (including message waiting indication and message33waiting count) are provided at the option of the service provider in ANSI-41mode. Only the MS display34indication is provided in GSM mode.35
Authorization on demand by the subscriber, as described in ANSI-664 [15], shall be optionally36supported in ANSI-41native mode only.37
X.S0023
1-84
2.9.2.2 De-Authorization (or Withdrawal)1
MWN may be withdrawn by the service provider.2
2.9.2.3 Registration3
MWN is registered upon authorization.4
2.9.2.4 De-Registration (or Erasure)5
MWN is de-registered upon de-authorization.6
2.9.2.5 Activation7
MWN shall be activated upon authorization. Activation on demand by the subscriber, as described in8ANSI-664 [15], shall be optionally supported in ANSI-41native mode only.9
2.9.2.6 De-Activation10
MWN shall be de-activated upon de-authorization.11
2.9.2.7 Invocation12
MWN alert pip tone is invoked when the first voice message is left in a VMS for a particular13subscriber. MWN alert pip tone is also invoked upon MS power up and there is one or more14unretrieved voice messages in the VMS. Alert pip tone notification is provided when authorized by the15service provider in ANSI-41mode only.16
MWN pip tone is invoked when a voice message is left and remains unretrieved in a Voice Message17System (VMS) for a particular subscriber, and the subscriber originates a call or answers an incoming18call. Pip tone notification is provided when authorized by the service provider in ANSI-41mode only.19
MS display indication is invoked when a voice message is left in a VMS for a particular subscriber. It20is also invoked when ANSI-41 registration procedures are invoked for a subscriber and there is an21unretrieved voice message in the VMS for the subscriber. In ANSI-41mode, the message waiting22count indication may be updated each time the number of messages in the VMS changes.23
2.9.3 Normal Operation with Successful Outcome24
Alert pip tone shall be applied when the MS powers up and a voice message remains unretrieved in25the VMS. The alert pip tone shall also be applied when the first voice message is left on a VMS and26the MS is available and not engaged in a call or service request.27
Pip tone notification shall be inserted into the voice channel when the subscriber originates a call or28answers an incoming call and a voice message is awaiting retrieval.29
The MS display message waiting indication shall be provided to an MS as long as there is an30unretrieved voice message in the VMS. The MS display indication (including message waiting31indication and message waiting count) is removed from the MS after the last voice message has been32retrieved from the VMS.33
2.9.3.1 Call Detail Record / Charging Requirements34
For GSM and ANSI-41 based network interoperability, no new or special recording capabilities are35needed.36
2.9.3.2 Interrogation37
Not applicable38
X.S0023
1-85
2.9.4 Exception Procedures or Unsuccessful Outcome1
2
2.9.4.1 Registration3
None identified.4
2.9.4.2 De-Registration / Erasure5
None identified.6
2.9.4.3 Activation7
None identified.8
2.9.4.4 De-Activation9
None identified.10
2.9.4.5 Invocation11
None identified.12
2.9.4.6 Exceptions While Roaming13
None identified.14
2.9.4.7 Exceptions During Intersystem Handoff15
None identified.16
2.9.5 Alternate Procedures17
None identified.18
2.9.6 Interactions With Other Features and Services19
20
2.9.6.1 Advice of charge (AoC)21
None identified.22
2.9.6.2 Barring of All Outgoing Calls (BAOC)23
None identified.24
2.9.6.3 Barring of Outgoing International Calls (BOIC)25
None identified.26
2.9.6.4 Barring of Outgoing International Calls except those directed to the Home PLMN27(BOIC-exHC)28
None identified.29
2.9.6.5 Barring of All Incoming Calls (BAIC)30
None identified.31
X.S0023
1-86
2.9.6.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam)1
None identified.2
2.9.6.7 Call Delivery (CD)3
None identified.4
2.9.6.8 Call Forwarding—Busy (CFB)5
None identified.6
2.9.6.9 Call Forwarding—Default (CFD)7
None identified.8
2.9.6.10 Call Forwarding—No Answer / No Reply (CFNA / CFNRy)9
None identified.10
2.9.6.11 Call Forwarding—Not Reachable (CFNRc)11
None identified.12
2.9.6.12 Call Forwarding—Unconditional (CFU)13
None identified.14
2.9.6.13 Call Transfer (CT)15
None identified.16
2.9.6.14 Call Waiting / Call Hold (CW / HOLD)17
No pip tone notification shall be provided if call waiting has been deactivated.18
2.9.6.15 Calling Number / Line Identification Presentation (CNIP / CLIP)19
None identified.20
2.9.6.16 Calling Number / Line Identification Restriction (CNIR / CLIR)21
None identified.22
2.9.6.17 Calling Name Presentation (CNAP)23
None identified.24
2.9.6.18 Calling Name Restriction (CNAR)25
None identified.26
2.9.6.19 Closed User Group (CUG)27
None identified.28
2.9.6.20 Conference Calling / Multi Party Service (CC / MPTY)29
Any pip tone notification shall only be applied to the primary leg of a multiparty call.30
2.9.6.21 Do Not Disturb (DND)31
MWN MS indication, count, and pip tone takes precedence over DND. MWN indication and pip tone32may still be applied while DND is active.33
X.S0023
1-87
DND takes precedence over MWN alert pip tone. That is, while DND is active, alerting shall not be1applied.2
2.9.6.22 Emergency Services3
None identified.4
2.9.6.23 Flexible Alerting (FA)5
None identified.6
2.9.6.24 Message Waiting Notification (MWN)7
Not applicable.8
2.9.6.25 Mobile Access Hunting (MAH)9
None identified.10
2.9.6.26 Over the Air Activation (OTA)11
None identified.12
2.9.6.27 Password Call Acceptance (PCA)13
None identified.14
2.9.6.28 Preferred Language (PL)15
None identified.16
2.9.6.29 Priority Access and Channel Assignment (PACA)17
None identified.18
2.9.6.30 Remote Feature Control (RFC)19
None identified.20
2.9.6.31 Selective Call Acceptance (SCA)21
None identified.22
2.9.6.32 Subscriber PIN Access (SPINA)23
None identified.24
2.9.6.33 Subscriber PIN Intercept (SPINI)25
None identified.26
2.9.6.34 Three-Way Calling / Multi Party Service (3WC / MPTY)27
Any pip tone notification shall only be applied to the primary leg of a three-way call.28
2.9.6.35 Voice Message Retrieval (VMR)29
None identified.30
2.9.6.36 Voice Privacy (VP)31
None identified.32
X.S0023
1-88
2.10 GPRS in GSM Foreign mode1
GPRS in GSM Foreign mode applies to the case where an ANSI-41ANSI-41 based subscriber (e.g.,2an ANSI-41 TDMA or CDMA native subscriber) has registered on a GPRS network [30].3
GPRS in GSM Foreign Mode allows a subscriber to an ANSI-41 based network (e.g., an ANSI-414TDMA or CDMA native subscriber) to obtain GPRS service (i.e., register for service) in GSM Foreign5Mode. There is no impact on ANSI-41 Foreign Mode. There is no communication between a GSM6SGSN and an ANSI-41 MSC and a mobile can not operate simultaneously on GPRS and ANSI-417systems.8
In GSM Foreign Mode it is required that the handset register on a GSM network or a GPRS network9to be in GSM Foreign Mode. The GPRS network may be coupled with a GSM network (i.e., one10PLMN can provide both GSM circuit-switched and packet service).11
2.10.1 General Description12
GPRS is a GSM Bearer Service that provides a packet data transmission scheme within the PLMN.13GPRS can also be used as a bearer for SMS teleservices.14
2.10.2 Normal Procedures With Successful Outcome15
Subscribers operating GPRS in GSM foreign mode (e.g., ANSI-41 TDMA or CDMA native16subscribers) shall be able to send and receive GPRS service packets when attached to a GPRS17network.18
2.10.2.1 Authorization (or Provision)19
GPRS subscription data must be provisioned and stored on the IIF, acting as the GPRS HLR. It may20be possible to provision an ANSI-41 TDMA or CDMA native subscriber with GPRS only service and21no GSM CS service.22
2.10.2.2 De-Authorization (or Withdrawal)23
The de-authorization shall be possible at the IIF, acting as the GPRS HLR, as well as at the24Authentication Center.25
2.10.2.3 Authentication26
The GPRS network shall query the IIF, acting as a GPRS HLR, to verify the authentication27parameters. This may occur upon with GPRS attach and GPRS routing area update operations.28
2.10.2.4 ANSI-41 registration29
ANSI-41 registration occurs when the subscriber roams into an ANSI-41 network and is:30
registered on a GSM MSC and a GPRS SGSN; or31
registered on a GPRS SGSN; or32
registered on a GSM MSC.33
ANSI-41 registration in all of these conditions shall result in a cancel location towards one or both of34the GSM MSC and GPRS SGSN, if the subscriber is registered to that network element.35
X.S0023
1-89
2.10.2.5 GPRS Attach1
The MS shall perform a GPRS attach to access GPRS services. This can be immediately after the2MS has been switched on or later as the user decides to use the GPRS service.3
A successful GPRS attach requires a valid GPRS subscription.4
The GPRS attach itself may be performed as one of the following:5
GPRS only attach; or6
GPRS attach when GSM CS attached; or7
combined GPRS and GSM CS attach.8
If one of the above GPRS attaches takes place when previously registered on an ANSI-41 network,9normal registration cancellation within the ANSI-41 network shall take place.10
2.10.2.6 GPRS Detach11
A GPRS detach allows:12
an MS to inform the network that it does not want to access GPRS services any longer; and13
the network to inform the MS that it does not have access to the GPRS services any longer.14
The GPRS detach itself may be performed as one of the following:15
GPRS only detach;16
GPRS detach when GSM CS attached;17
combined GPRS and GSM CS detach.18
The MS is detached either explicitly or implicitly as follows:19
Explicit Detach: the network or the MS explicitly requests detach.20
Implicit Detach: the network detaches the MS, without notifying the MS.21
2.10.2.7 GPRS Routing Area Update22
A routing area update occurs when a GPRS attached MS detects that it has entered a new routing23area or when the periodic routing area update timer has expired. These may be combined with GSM24CS location area updates depending on the network mode of operation.25
The following GPRS Routing Area Updates are possible:26
intra SGSN Routing Area Update.27
inter SGSN Routing Area Update.28
The following combined RA and LA updates takes place when an association exists between the29SGSN and the MSC [30]:30
combined Intra SGSN RA and LA update.31
combined Inter SGSN RA and LA update.32
X.S0023
1-90
2.10.2.8 SMS Impacts1
GPRS has the following impacts on SMS:2
When operating GPRS in GSM Foreign mode, and both GPRS attached and GSM CS3attached, the mobile may originate mobile-originated SMS messages either thru the GSM4network or the GPRS network. When operating only in GPRS mode, SMS originations thru the5GPRS network shall be possible.6
When operating GPRS in GSM Foreign mode, and both GPRS attached and GSM CS7attached, the mobile shall receive mobile-terminated SMS messages either thru the GSM8network or the GPRS network. When operating in GPRS only mode, SMS terminations shall be9possible.10
For GSM native subscribers in GSM native mode, the GSM SMS Service Center (i.e., SMSC) queries11the combined GSM-GPRS HLR for routing information and the HLR responds with both the SGSN12address as well as the GSM MSC address. Then the SMSC decides to send the SMS message to13either the GPRS SGSN or the GSM MSC.14
For GPRS in GSM Foreign Mode the ANSI-41 MC shall query the ANSI-41 HLR for the ANSI-4115MSC address and shall be instructed to route the ANSI-41 formatted SMS message to the IIF,16emulating both an ANSI-41 MSC and a GSM SMSC, for any of the following conditions:17
when the subscriber is both GSM CS attached and GPRS attached; or18
when the subscriber is GPRS only attached; or19
when the subscriber is GSM CS only attached.20
The IIF shall then convert the mobile-terminated ANSI-41 SMS message to a GSM-formatted SMS21message and, acting like a GSM SMSC, send it to the GSM MSC or the GPRS SGSN. If the MS is22reachable a Network option for routing the SMS messages may be as follows:23
first - send to the GPRS SGSN;24
second - send to the GSM MSC.25
2.10.3 Exception Procedures or Unsuccessful Outcome26
In the event that the IIF is not able to authenticate the GPRS subscriber, the GPRS service shall be27denied. If the ANSI-41 registration process fails due to location update failure or authentication failure,28the MS shall be denied access to the GPRS network.29
In the event that the IIF receives a mobile terminating ANSI-41 formatted SMS message, and if the30IIF detects that the GSM Foreign Mode subscriber is not reachable (for both packet and circuit-31switched services), the IIF shall reply to the ANSI-41 Message Center with an error and when the IIF32detects that the subscriber is again reachable, either GPRS or non-GPRS, then the IIF shall notify the33Message Center to retransmit the ANSI-41 formatted SMS message to the IIF.34
The SGSN notifies (i.e., alert) the IIF, acting as a GPRS HLR, when the handset has memory35available and when the handset is “MS present”.36
GSM GPRS HLR fault recovery procedures shall also apply to the IIF acting as the GPRS HLR.37
2.10.3.1 GPRS Attach38
None identified.39
X.S0023
1-91
2.10.3.2 GPRS Detach1
None identified.2
2.10.3.3 Exceptions While Roaming3
None identified.4
2.10.3.4 Exceptions During Intersystem Handoff5
None identified.6
2.10.4 Alternate Procedures7
None identified.8
2.10.5 Interactions With Other Features and Services9
10
2.10.5.1 Advice of charge (AoC)11
None identified12
2.10.5.2 Authentication13
GSM authentication procedures are required to be supported by the IIF in the GPRS home network.14For GPRS in GSM Foreign Mode the authentication procedure is done according to the procedures15defined in GSM 09.02 [4].16
2.10.5.3 Barring of All Outgoing Calls (BAOC)17
ODB_BAOC may be provisioned in the IIF, acting as a GPRS HLR, and it applies to Mobile18Originated SMS via the GPRS network.19
2.10.5.4 Barring of Outgoing International Calls (BOIC)20
ODB_BOIC may be provisioned in the IIF, emulating a GPRS HLR, and it applies to Mobile21Originated SMS via the GPRS network.22
2.10.5.5 Barring of Outgoing International Calls except those directed to the Home PLMN23(BOIC-exHC)24
ODB_BOIC-exHC may be provisioned in the IIF, emulating a GPRS HLR, and it applies to Mobile25Originated SMS via the GPRS network.26
2.10.5.6 Operator Determined Barring PLMN-specific27
Four ODB PLMN-specific barring programs may be provisioned in the IIF, emulating a GPRS HLR,28and each applies to Mobile Originated SMS via the GPRS network.29
2.10.5.7 Barring of All Incoming Calls (BAIC)30
ODB_BAIC may be provisioned in the IIF, emulating a GPRS HLR, and it applies for GPRS and31Mobile Terminated SMS deliveries thru the GPRS network.32
2.10.5.8 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam)33
None identified.34
X.S0023
1-92
2.10.5.9 Call Delivery (CD)1
When a subscriber receives a call termination attempt when operating in GSM foreign mode (e.g.,2ASNI-41 TDMA or CDMAnative subscriber) and connected to a GPRS network, the GSM Circuit-3switched paging is sent through the GPRS SGSN and the IIF is not impacted.14
Call terminations to the subscriber (e.g., ANSI-41 TDMA or CDMAnative subscriber) operating in5GPRS only mode shall not be possible. However, it is possible for the IIF to send a SMS message to6the user thru the GPRS network indicating the calling party number of the missed call.7
2.10.5.10 Call Forwarding—Busy (CFB)8
None identified.9
2.10.5.11 Call Forwarding—Default (CFD)10
None identified.11
2.10.5.12 Call Forwarding—No Answer / No Reply (CFNA / CFNRy)12
None identified.13
2.10.5.13 Call Forwarding—Not Reachable (CFNRc)14
None identified.15
2.10.5.14 Call Forwarding—Unconditional (CFU)16
None identified.17
2.10.5.15 Call Transfer (CT)18
None identified.19
2.10.5.16 Call Waiting / Call Hold (CW / HOLD)20
None identified.21
2.10.5.17 Calling Number / Line Identification Presentation (CNIP / CLIP)22
None identified.23
2.10.5.18 Calling Number / Line Identification Restriction (CNIR / CLIR)24
None identified.25
2.10.5.19 Calling Name Presentation (CNAP)26
None identified.27
2.10.5.20 Calling Name Restriction (CNAR)28
None identified.29
2.10.5.21 Closed User Group (CUG)30
None identified.31
1 The MSC and SGSN are both GSM.
X.S0023
1-93
2.10.5.22 Conference Calling / Multi Party Service (CC / MPTY)1
None identified.2
2.10.5.23 Do Not Disturb (DND)3
None identified.4
2.10.5.24 Emergency Services (Future)5
None identified.6
2.10.5.25 Flexible Alerting (FA)7
None identified.8
2.10.5.26 Message Waiting Notification (MWN)9
None identified.10
2.10.5.27 Mobile Access Hunting (MAH)11
None identified.12
2.10.5.28 Password Call Acceptance (PCA)13
None identified.14
2.10.5.29 Preferred Language (PL)15
None identified.16
2.10.5.30 Priority Access and Channel Assignment (PACA)17
None identified.18
2.10.5.31 Remote Feature Control (RFC)19
None identified.20
2.10.5.32 Selective Call Acceptance (SCA)21
None identified.22
2.10.5.33 Subscriber PIN Access (SPINA)23
None identified.24
2.10.5.34 Subscriber PIN Intercept (SPINI)25
None identified.26
2.10.5.35 Three-Way Calling / Multi Party Service (3WC / MPTY)27
None Identified.28
2.10.5.36 Voice Message Retrieval (VMR)29
None identified.30
2.10.5.37 Voice Privacy (VP)31
None identified.32
33
X.S0023
2-i
NNNeeetttwwwooorrrkkk IIInnnttteeerrrwwwooorrrkkkiiinnnggg BBBeeetttwwweeeeeennn GGGSSSMMM MMMAAAPPP aaannnddd TTTIIIAAA---444111 MMMAAAPPP;;;1
RRReeevvviiisssiiiooonnn BBB ––– CCCDDDMMMAAA222000000000 SSSuuuppppppooorrrttt2
VVVooollluuummmeee 222 ––– IIInnnfffooorrrmmmaaatttiiiooonnn FFFlllooowwwsss3
(((RRReeevvviiisssiiiooonnn ooofff JJJ---SSSTTTDDD---000333888---AAA VVVooollluuummmeee 222)))4
Abstract5
This Volume contains the information flows for GSM MAP/TIA-41 MAP interworking.6
X.S0023
2-ii
Contents1
Abstract.....................................................................................................................................................i2
Contents ..................................................................................................................................................ii3
List of Tables .........................................................................................................................................vii4
List of Figures....................................................................................................................................... viii5
Foreword................................................................................................................................................xii6
1 Introduction ............................................................................................................................... 171.1 General .................................................................................................................................. 18
2 Purpose..................................................................................................................................... 19
3 Scope ........................................................................................................................................ 110
4 Stage 2 Information Flows ....................................................................................................... 2114.1 Location Registration ............................................................................................................ 212
4.1.1 Location Registration in GSM Foreign Mode................................................................ 2134.1.1.1 MS registers in a GSM network when previously registered in an14
ANSI-41 network........................................................................................ 2154.1.1.2 MS location updates in a different MSC/VLR........................................... 4164.1.1.3 IMSI Detach ............................................................................................... 5174.1.1.4 IMSI Attach................................................................................................. 618
4.1.2 Location Registration in ANSI-41 Foreign Mode .......................................................... 7194.1.2.1 MS registers in an ANSI-41 network when previously registered in20
a GSM network .......................................................................................... 7214.1.2.2 MS location updates in a different MSC/VLR........................................... 9224.1.2.3 MS Powers Off......................................................................................... 10234.1.2.4 MS Powers On......................................................................................... 1024
4.1.3 Location Registration in Native Mode ......................................................................... 11254.1.3.1 MS registers in an ANSI-41 network when previously registered in26
a GSM network ........................................................................................ 11274.1.3.2 MS registers in a GSM network when previously registered in an28
ANSI-41 network...................................................................................... 13294.2 Fault Recovery Procedures ................................................................................................ 1530
4.2.1 Fault Recovery Procedures in GSM Foreign Mode.................................................... 15314.2.1.1 Recovery from Failure at the ANSI-41 HLR ........................................... 15324.2.1.2 Recovery from Failure at the IIF.............................................................. 16334.2.1.3 Recovery from Failure at the serving GSM VLR.................................... 1734
4.2.2 Fault Recovery Procedures in ANSI-41 Foreign Mode .............................................. 18354.2.2.1 Recovery from Failure at the GSM HLR................................................. 18364.2.2.2 Recovery from Failure at the IIF.............................................................. 19374.2.2.3 Recovery from Data Failure at the ANSI-41 VLR................................... 1938
4.4 Subscriber Data Management............................................................................................ 2039
X.S0023
2-iii
4.4.1 Subscriber Data Management Procedures in ANSI-41 Foreign Mode...................... 2014.4.1.1 Subscriber Deletion ................................................................................. 2024.4.1.2 Subscriber Data Modification .................................................................. 213
4.4.2 Subscriber Data Management Procedures in GSM Foreign Mode ........................... 2444.4.2.1 Subscriber Deletion ................................................................................. 2454.4.2.2 Modifying Subscriber Data ...................................................................... 256
4.5 Automatic Call Delivery....................................................................................................... 2674.5.1 Automatic Call Delivery Activation/Deactivation ......................................................... 2684.5.2 Automatic Call Delivery Invocation.............................................................................. 269
4.5.2.1 Call Delivery to ANSI-41Subscriber Roaming in GSM Network............ 26104.5.2.2 Delivery to an ANSI-41Subscriber Roaming in a GSM Network –11
Unsuccessful Case .................................................................................. 28124.5.2.3 Call Delivery to a GSM Subscriber Roaming in ANSI-41 Network –13
Successful Case ...................................................................................... 29144.5.2.4 Call Delivery to a GSM Subscriber Roaming in ANSI-41 Network –15
Unsuccessful Case .................................................................................. 30164.6 Call Forwarding ................................................................................................................... 3117
4.6.1 Call forwarding scenarios for ANSI-41 foreign mode ................................................. 31184.6.1.1 Call forwarding unconditional (CFU)....................................................... 31194.6.1.2 Call forwarding busy (CFB) ..................................................................... 39204.6.1.3 Call forwarding no reply (CFNRy) ........................................................... 44214.6.1.4 Call forwarding not reachable (CFNRc).................................................. 4722
4.6.2 Call forwarding scenarios for GSM foreign mode....................................................... 51234.6.2.1 Call forwarding unconditional (CFU)....................................................... 51244.6.2.2 Call forwarding busy (CFB) ..................................................................... 56254.6.2.3 Call forwarding no answer (CFNA) ......................................................... 6626
4.7 Optimal Routing for Late Call Forwarding.......................................................................... 68274.7.1 ANSI-41 Foreign Mode ................................................................................................ 6928
4.7.1.1 ANSI-41 Foreign Mode - Success condition .......................................... 69294.7.1.2 ANSI-41 Foreign Mode - Failure condition ............................................. 7230
4.7.2 GSM Foreign Mode...................................................................................................... 73314.7.2.1 GSM Foreign Mode - Success Case ...................................................... 73324.7.2.2 GSM Foreign Mode - Failure case.......................................................... 7533
4.8 Call Waiting ......................................................................................................................... 76344.8.1 Call Waiting Activation ................................................................................................. 7635
4.8.1.1 ANSI-41 Foreign Mode Successful Call Waiting Activation................... 76364.8.1.2 ANSI-41 Foreign Mode Unsuccessful Call Waiting Activation............... 78374.8.1.3 GSM Foreign Mode Feature Activation .................................................. 7938
4.8.2 Call Waiting Deactivation............................................................................................. 81394.8.2.1 ANSI-41 Foreign Mode Call Waiting Deactivation ................................. 81404.8.2.2 GSM Foreign Mode Feature Deactivation.............................................. 8341
4.9 Calling Number / Line Identification Presentation/Restriction........................................... 85424.9.1 Handling of calling number/ line identification presentation ....................................... 8543
4.9.1.1 GSM Foreign Mode ................................................................................. 85444.9.1.2 ANSI-41 Foreign Mode............................................................................ 8745
4.9.2 Handling of calling number/ line identification restriction ........................................... 8946
X.S0023
2-iv
4.9.2.1 General..................................................................................................... 8914.9.2.2 GSM Foreign Mode ................................................................................. 8924.9.2.3 ANSI-41 Foreign Mode............................................................................ 893
4.10 Call Barring and Operator Determined Barring ................................................................. 9044.10.1 Activation of Barring at VLR......................................................................................... 905
4.10.1.1 Activation of Call Restrictions while in GSM Foreign Mode................... 9064.10.1.2 Activation of Call Barring while in ANSI-41 Foreign Mode..................... 917
4.10.2 Invocation of Barring of Incoming Calls....................................................................... 9284.10.2.1 GSM Foreign Mode ................................................................................. 9294.10.2.2 ANSI-41 Foreign Mode............................................................................ 9210
4.10.3 Invocation of Barring of Roaming ................................................................................ 92114.10.3.1 GSM Foreign Mode ................................................................................. 92124.10.3.2 ANSI-41 Foreign Mode............................................................................ 9313
4.10.4 Invocation of Barring of Supplementary Services Management................................ 94144.10.4.1 GSM Foreign Mode ................................................................................. 94154.10.4.2 ANSI-41 Foreign Mode............................................................................ 9516
4.11 Short Message Service....................................................................................................... 96174.11.1 Assumptions ................................................................................................................. 96184.11.2 Mobile Station only Supports GHOST/WEMT ............................................................ 9719
4.11.2.1 Short Message from CMT Mobile Station to GHOST/WEMT Mobile20Station both in Native Mode .................................................................... 9721
4.11.2.2 Short Message sent from GHOST/WEMT Mobile Station to CMT22Mobile Station, both in Native Mode ....................................................... 9823
4.11.3 Mobile Terminating SMS in GSM Foreign Mode ........................................................ 99244.11.3.1 Successful Mobile Terminating ANSI-41SMS (CMT) mapped to25
GSM SMS ................................................................................................ 99264.11.3.2 Successful Mobile Terminating ANSI-41SMS (GHOST/WEMT)27
Mapped to GSM SMS............................................................................ 101284.11.3.3 Unsuccessful Mobile Terminated Delivery (Failure at MSC)............... 102294.11.3.4 Unsuccessful Mobile Terminated Delivery (Failure at IIF)................... 104304.11.3.5 Alerting for an ANSI-41Subscriber in GSM Foreign Mode .................. 10531
4.11.4 Mobile Terminated SMS in ANSI-41 Foreign Mode ................................................. 106324.11.4.1 Successful GSM SMS mapped to ANSI-41(CMT) SMS...................... 106334.11.4.2 Successful GSM SMS mapped to ANSI-41(GHOST/WEMT) SMS .... 108344.11.4.3 Unsuccessful GSM SMS mapped to ANSI-41SMS (Failure at MS).... 110354.11.4.4 Unsuccessful Delivery to GSM Subscriber (Postponed at MSC)........ 112364.11.4.5 Unsuccessful Delivery to GSM Subscriber (Failure at IIF) .................. 114374.11.4.6 Alerting for a GSM Subscriber in ANSI-41 Foreign Mode ................... 11538
4.11.5 Message Flows for Mobile Originated SMS in GSM Foreign Mode ........................ 116394.11.5.1 Successful Mobile Originated Delivery ................................................. 116404.11.5.2 Unsuccessful Mobile Originated (Failure at MC).................................. 117414.11.5.3 Unsuccessful Mobile Originated (Failure at IIF) ................................... 11842
4.11.6 Message Flows for Mobile Originated SMS in ANSI-41 Foreign Mode................... 119434.11.6.1 Successful Mobile Originated Delivery ................................................. 119444.11.6.2 Unsuccessful Mobile Originated (Failure at SMSC)............................. 120454.11.6.3 Unsuccessful Mobile Originated (Failure at IIF) ................................... 12146
X.S0023
2-v
4.12 Message Waiting Notification ........................................................................................... 12214.12.1 GSM Foreign Mode.................................................................................................... 1222
4.12.1.1 Indicator in ANSI-41 Registration Notification Return Result3mapped to GSM SMS............................................................................ 1234
4.12.1.2 ANSI-41 Qualification Directive mapped to GSM SMS........................ 12554.12.1.3 Handling when GSM MSC/VLR only supports GSM Phase 1 (MAP6
V1) .......................................................................................................... 12774.12.1.4 Handling at SMS delivery failure at the IIF ........................................... 12984.12.1.5 Handling at SMS delivery failure at the MSC/VLR or at the Mobile9
Station .................................................................................................... 130104.12.2 ANSI-41 Foreign Mode .............................................................................................. 13211
4.12.2.1 GSM SMS mapped to ANSI-41 Qualification Directive........................ 132124.12.2.2 GSM SMS mapped to ANSI-41 SMS using GHOST or WEMT13
Teleservice............................................................................................. 134144.12.2.3 Clearing of MWN Information after Retrieval of Messages while in15
ANSI-41 Foreign Mode – QualDir Method............................................ 136164.12.2.4 Handling at SMS delivery failure at the IIF ........................................... 138174.12.2.5 Handling at SMS delivery failure at the MSC/VLR – QualDir18
Method ................................................................................................... 140194.12.2.6 Handling at SMS delivery failure at the MSC/VLR –20
GHOST/WEMT SMS Method................................................................ 142214.12.2.7 GSM SMS mapped to ANSI-41 Qualification Directive and to22
Registration Notification Return Result................................................. 144234.13 GPRS in GSM Foreign Mode ........................................................................................... 14724
4.13.1 Location Registration Scenarios................................................................................ 148254.13.1.1 GPRS Attach (not currently registered) ................................................ 14826GPRS Attach when currently registered in an ANSI-41 network ............................. 152274.13.1.3 Inter-SGSN routing area update ........................................................... 156284.13.1.4 GPRS- Attach when only GSM CS Attached ...................................... 160294.13.1.5 Combined GSM and GPRS attach when not currently registered ...... 162304.13.1.6 Combined Inter-SGSN Routeing Area/Location Area Update............. 169314.13.1.7 Inter-SGSN routing area update when GSM CS and GPRS32
attached (GSM MSC remains constant)............................................... 172334.13.1.8 Combined Attach When Currently Registered in an ANSI-41 MSC.... 174344.13.1.9 Authentication Failure at the IIF ............................................................ 178354.13.1.10 Registration Failure at the ANSI-41HLR............................................... 17836
4.13.2 Location Deregistration Scenarios ............................................................................ 179374.13.2.1 GSM CS (IMSI) Detach while GPRS and GSM CS Attached ............. 179384.13.2.2 GPRS Detach While Attached for Both GPRS and GSM CS39
Services.................................................................................................. 179404.13.2.3 GPRS Detach While Attached for GPRS Services Only ..................... 179414.13.2.4 Combined GPRS Detach and GSM CS (IMSI) Detach ....................... 179424.13.2.5 GPRS Detach Followed By Purge ........................................................ 180434.13.2.6 IIF - Initiated Detach ............................................................................. 18144
4.13.3 SMS Scenarios........................................................................................................... 182454.13.3.1 SMS Scenarios for Mobile Terminated SMS while GPRS Attached... 18246
X.S0023
2-vi
4.13.3.1.1 Successful Mobile Terminated ANSI-41SMS (CMT) Mapped to GSM1SMS........................................................................................................ 1822
4.13.3.1.2 Successful Mobile Terminating ANSI-41SMS (GHOST/WEMT)3Mapped to GSM SMS............................................................................ 1844
4.13.3.1.3 Unsuccessful Mobile Terminated Delivery (Failure at SGSN)................ 18554.13.3.1.4 Unsuccessful Mobile Terminated Delivery (Failure at IIF)...................... 18764.13.3.1.5 Alerting for an ANSI-41Subscriber for GPRS in GSM Foreign Mode .... 1887
4.13.4 Message Flows for Mobile Originated SMS when operating GPRS in GSM Foreign8Mode 18994.13.4.1 Successful Mobile Originated SMS to MC ................................................. 189104.13.4.2 Unsuccessful Mobile Originated (Failure at MC)........................................ 190114.13.4.3 Unsuccessful Mobile Originated (Failure at IIF) ......................................... 19112
4.13.5 Message Waiting Notification while GPRS Attached in GSM Foreign Mode.......... 192134.13.5.1 Indicator in ANSI-41 Registration Notification Return Result mapped to GSM SMS19314
4.13.5.2 ANSI-41 Qualification Directive mapped to GSM SMS.............................. 195154.13.5.3 Handling at SMS delivery failure at the SGSN or at the Mobile Station ... 19716
4.13.6. Call Delivery Scenarios............................................................................................. 199174.13.6.1 Call Delivery Scenarios in GSM Foreign Mode while GSM CS and18
GPRS Attached...................................................................................... 199194.13.6.1.1 Call Delivery to ANSI-41Subscriber Roaming on a GSM/GPRS20
Network .................................................................................................. 199214.13.6.1.2 Call Delivery to ANSI-41Subscriber Roaming in a GPRS Network22
(Unsuccessful) ....................................................................................... 201234.13.6.2 Successful Network-Requested PDP Context Activation Procedure.. 203244.13.6.3 Unsuccessful Network-Requested PDP Context Activation25
Procedure............................................................................................... 204264.13.7 Packet Domain Subscriber Data in the IIF............................................................... 20427
Annex A (informative) ........................................................................................................................ 20528
Annex B - CDMA to GSM One-way Roaming Only.......................................................................... 20729B.1 Successful Authentication on Initial Access in GSM System.......................................... 20730B. 2 Authentication Failure on Initial Access in GSM System ................................................ 20931B.3 Authentication Failure on Initial Access in GSM System – Authentication Failure Message32
Not Supported ................................................................................................................... 21133B.4 GSM System Request for Additional Triplets .................................................................. 21334
35
36
X.S0023
2-vii
List of Tables1
There are no tables in this volume.2
3
X.S0023
2-viii
List of Figures1
Figure 1: Registration on a GSM Network – GSM Foreign Mode ....................................................... 22
Figure 2: Registration in a different MSC/VLR – GSM Foreign Mode................................................. 43
Figure 3: Registration on an ANSI-41 network – ANSI-41 Foreign Mode........................................... 74
Figure 4: Registration in a different MSC/VLR – ANSI-41 Foreign Mode ........................................... 95
Figure 5: Registration in an ANSI-41 Network (Native Mode) ........................................................... 116
Figure 6: Registration in a GSM Network (Native Mode)................................................................... 137
Figure 7: Failure at the ANSI-41 HLR (GSM Foreign Mode) ............................................................. 158
Figure 8: IIF Failure (GSM Foreign Mode).......................................................................................... 169
Figure 9: Terminating Call Flow following a GSM VLR Failure.......................................................... 1710
Figure 10: Failure at a GSM HLR (ANSI-41 Foreign Mode) .............................................................. 1811
Figure 25: Subscriber Deletion – ANSI-41 Foreign Mode.................................................................. 2012
Figure 26: Insert Subscriber Data Procedure ..................................................................................... 2113
Figure 27: Delete Subscriber Data Procedure.................................................................................... 2214
Figure 28: Cancel Location Procedure ............................................................................................... 2315
Figure 29: Subscriber Deletion- GSM Foreign Mode ......................................................................... 2416
Figure 30: Subscriber Data Modification............................................................................................. 2517
Figure 31: Call Delivery to ANSI-41 Subscriber Roaming in a GSM Network .................................. 2618
Figure 32: Unsuccessful Call Delivery to an ANSI-41Subscriber Roaming in a GSM19Network......................................................................................................................... 2820
Figure 33: Call Delivery to GSM Subscriber Roaming in an ANSI-41 Network ................................ 2921
Figure 34: Unsuccessful Call Delivery to GSM Subscriber Roaming in an ANSI-41 Network ......... 3022
Figure 35: CFU registration ................................................................................................................. 3123
Figure 36: CFU deregistration (erasure) ............................................................................................. 3324
Figure 37: CFU activation .................................................................................................................... 3525
Figure 38: CFU deactivation................................................................................................................ 3726
Figure 39: CFU invocation ................................................................................................................... 3827
Figure 40: CFB invocation (Scenario 1a, “CFB#=MSRN method”) ................................................... 4028
Figure 41: CFB invocation (Scenario 1b, “AbsentSubscriber method”) ............................................ 4229
Figure 42: CFB invocation (Scenario 2, without OR) ......................................................................... 4330
Figure 43: CFNRy invocation (Scenario 1, without OR)..................................................................... 4631
Figure 44: CFNRc invocation (Scenario 1) ......................................................................................... 4832
X.S0023
2-ix
Figure 45: CFNRc invocation (Scenario 2, without OR)..................................................................... 491
Figure 46: CFU registration ................................................................................................................. 512
Figure 47: CFU deregistration (erasure) ............................................................................................. 523
Figure 48: CFU activation .................................................................................................................... 534
Figure 49: CFU deactivation................................................................................................................ 545
Figure 50: CFU invocation ................................................................................................................... 556
Figure 51: Obtaining forward-to numbers ........................................................................................... 567
Figure 52: CFB registration.................................................................................................................. 578
Figure 53: CFB deregistration (erasure) ............................................................................................. 599
Figure 54: CFB activation .................................................................................................................... 6110
Figure 55: CFB deactivation ................................................................................................................ 6311
Figure 57: CFNA invocation (Scenario 1, without OR)....................................................................... 6712
Figure 58: Optimal Routing with Late Call Forwarding (ANSI-41 Foreign Mode) Success13Case.............................................................................................................................. 6914
Figure 59: Optimal Routing with Late Call Forwarding (ANSI-41 Foreign Mode) Failure15Case.............................................................................................................................. 7216
Figure 60: Optimal Routing with Late Call Forwarding (GSM Foreign Mode) Success Case.......... 7317
Figure 61: Optimal Routing with Late Call Forwarding (GSM Foreign Mode) Failure Case ............ 7518
Figure 62: ANSI-41 Foreign Mode Call Waiting Activation ................................................................ 7619
Figure 63: ANSI-41 Foreign Mode Unsuccessful Call Waiting Activation ......................................... 7820
Figure 64: GSM Foreign Mode Call Waiting Activation...................................................................... 7921
Figure 65: ANSI-41 Foreign Mode Call Waiting Deactivation............................................................ 8122
Figure 66: GSM Foreign Mode Call Waiting Deactivation ................................................................. 8323
Figure 67: Calling number/ line identification presentation: mobile station or fixed terminal to24mobile station – GSM Foreign Mode........................................................................... 8525
Figure 68: Calling number/ line identification presentation: mobile station or fixed terminal to26mobile station – ANSI-41 Foreign Mode ..................................................................... 8727
Figure 69: Activation of Call Restriction - GSM Foreign Mode .......................................................... 9028
Figure 70: Activation of Call Barring – ANSI-41 Foreign Mode ......................................................... 9129
Figure 71: Invocation of Barring of Roaming – GSM Foreign Mode ................................................ 9230
Figure 72: Invocation of Barring of Roaming – ANSI-41 Foreign Mode............................................ 9331
Figure 73: Invocation of Barring of Supplementary Service Control – GSM Foreign Mode............. 9432
Figure 74: Invocation of Barring of Supplementary Services Management – ANSI-4133Foreign Mode ............................................................................................................... 9534
X.S0023
2-x
Figure 75: Short Message from a TDMA or CDMA CMT phone to a GHOST or WEMT1mobile station, both in native mode............................................................................. 972
Figure 76: Short Message from a GHOST or WEMT mobile station to a TDMA CMT or3CDMA CMT Phone, both in native mode.................................................................... 984
Figure 77: Successful Mobile Terminating ANSI-41SMS (CMT) mapped to GSM SMS.................. 995
Figure 78: Successful Mobile Terminating ANSI-41SMS (GHOST/WEMT) mapped to GSM6SMS ............................................................................................................................ 1017
Figure 79: Unsuccessful Mobile Terminated Delivery (Failure at MSC).......................................... 1028
Figure 80: Unsuccessful Mobile Terminated Delivery (Failure at IIF) ............................................. 1049
Figure 81: Alerting for an ANSI-41Subscriber in GSM Foreign Mode............................................. 10510
Figure 82: Successful GSM SMS mapped to ANSI-41(CMT) SMS ................................................ 10611
Figure 83: Successful GSM SMS mapped to ANSI-41(GHOST/WEMT) SMS............................... 10812
Figure 84: Successful GSM SMS mapped to ANSI-41SMS (Failure at MS) .................................. 11013
Figure 85: Unsuccessful Delivery to GSM Subscriber (Postponed at MSC) .................................. 11214
Figure 86: Unsuccessful Delivery to GSM Subscriber (Failure at IIF)............................................. 11415
Figure 87: Alerting for a GSM Subscriber in ANSI-41 Foreign Mode.............................................. 11516
Figure 88: Successful Mobile Originated Delivery............................................................................ 11617
Figure 89: Unsuccessful Mobile Originated (Failure at MC) ............................................................ 11718
Figure 90: Unsuccessful Mobile Originated (Failure at IIF).............................................................. 11819
Figure 91: Successful Mobile Originated Delivery – ANSI-41 Foreign Mode ................................. 11920
Figure 92: Successful Mobile Originated (Failure at SMSC) – ANSI-41 Foreign Mode ................. 12021
Figure 93: Unsuccessful Mobile Originated (Failure at IIF) – ANSI-41 Foreign Mode ................... 12122
Figure 94: Indicator in ANSI-41 Registration Notification Return Result mapped to GSM23SMS ............................................................................................................................ 12324
Figure 95: ANSI-41 Qualification Directive mapped to GSM SMS................................................. 12525
Figure 96: Handling when GSM MSC/VLR only supports GSM Phase 1 (MAP V1) ...................... 12726
Figure 97: Handling at SMS delivery failure at the IIF..................................................................... 12927
Figure 98: Handling at SMS delivery failure at the MSC/VLR or at the MS ................................... 13028
Figure 99: GSM SMS mapped to ANSI-41 Qualification Directive .................................................. 13229
Figure 100: GSM SMS mapped to ANSI-41 using GHOST/WEMT Teleservice ............................ 13430
Figure 101: Clearing of MWN Information after Retrieval of Messages while in ANSI-4131Foreign mode – Qualdir Method................................................................................ 13632
Figure 102: Handling at SMS delivery failure at the IIF.................................................................... 13833
Figure 103: Handling at SMS delivery failure at the MSC/VLR Qualdir Method............................. 14034
X.S0023
2-xi
Figure 104: Handling at SMS delivery failure at the MSC/VLR – GHOST/WEMT SMS1Method........................................................................................................................ 1422
Figure 105: GSM SMS mapped to ANSI-41 Qualification Directive and to Registration3Notification Return Result .......................................................................................... 1444
Figure 106: GPRS Attach (Option1: with timer)................................................................................ 1495
Figure 107: GPRS Attach (Option 2: without timer) ......................................................................... 1506
Figure 108: GPRS Attach when currently registered in ANSI-41 (Option 1: with timer)................. 1527
Figure 109: GPRS Attach when currently registered in ANSI-41 (Option 2: without timer)............ 1548
Figure 112: GPRS Attach when GSM CS Attached......................................................................... 1609
Figure 113: Combined GPRS and GSM attach (Option 1: With timer). .......................................... 16210
Figure 114: Combined GPRS and GSM attach (Option 2: Without timer and without11support for multiple MSCIDs). ................................................................................... 16412
Figure 115: Combined GPRS and GSM attach (Option 3: IIF supports multiple MSCIDs)............ 16613
Figure 116: Combined Inter-SGSN RA/LA update........................................................................... 16914
Figure 117: Inter-SGSN routing area update when GSM CS and GPRS Attached15(MSC remains constant) ............................................................................................ 17216
Figure 118: Combined Attach when registered on a ANSI-41 MSC (Option 1: With timer) ........... 17417
Figure 119: Combined attach when registered on a ANSI-41 MSC (Option 2: without timer ) ...... 17618
Figure 120: MS in GSM Foreign Mode Performing GPRS Detach Followed by Purge.................. 18019
Figure 121: IIF - Initiated Detach....................................................................................................... 18120
Figure 122: Successful Mobile Terminating ANSI-41SMS (CMT) mapped to GSM SMS............. 18221
Figure 123: Successful Mobile Terminating ANSI-41SMS (GHOST/WEMT) mapped to22GSM SMS................................................................................................................... 18423
Figure 124: Unsuccessful Mobile Terminated Delivery (Failure at SGSN) ..................................... 18524
Figure 125: Unsuccessful Mobile Terminated Delivery (Failure at IIF) ........................................... 18725
Figure 126: Alerting for an ANSI-41Subscriber in GSM Foreign Mode........................................... 18826
Figure 127: Successful Mobile Originated Delivery......................................................................... 18927
Figure 128: Unsuccessful Mobile Originated Delivery (Failure at MC)............................................ 19028
Figure 129: Unsuccessful Mobile Originated (Failure at IIF)............................................................ 19129
Figure 130: Indicator in ANSI-41 Registration Notification Return Result mapped to GSM30SMS ............................................................................................................................ 19331
Figure 131: ANSI-41 Qualification Directive mapped to GSM SMS................................................ 19532
Figure 132: Handling at SMS delivery failure at the SGSN or at the MS........................................ 19733
Figure 133: Call Delivery to ANSI-41Subscriber Roaming in GSM/GPRS Network....................... 19934
Figure 134: MS Notification of a “Missed” Call via SMS .................................................................. 20135
X.S0023
2-xii
1
Foreword2
This foreword is not part of this standard.3
This standard addresses the interworking and interoperability between TIA/EIA IS41 MAP and GSM4based networks in the support of subscribers roaming between networks. The objective of the5standard is to achieve fully automatic, two-way interoperability between the heterogeneous networks.6Services supported by this standard are described along with the associated information flows and7message mappings. However, not all services and associated capabilities of ANSI-41 MAP and GSM8MAP are supported by this standard. In general the attempt has been to focus on the key subscriber9services needed in the market.10
The focus of the first release of this standard was on common GSM and ANSI-136 TDMA services11and associated network signaling (i.e. ANSI-41 MAP and GSM MAP). A pre-requisite for this12interoperability is multi-mode mobile stations with an enhanced SIM card for roaming between13ANSI-136, GSM, and AMPS networks.14
The first release of the standard did not define or require changes to existing ANSI-41 MAP or GSM15MAP to achieve the described interworking and interoperability. However, due to differences between16the services and associated capabilities of the MAP protocols, complete and fully transparent17interoperability may not have been achieved for some services. Future releases of this standard may18require changes to ANSI-41 MAP, GSM MAP and the associated services to achieve full19transparency while roaming between the different networks.20
Existing ANSI-41 and GSM standard specifications cover the use and value of timers controlling the21various operations. Therefore, these timers are not part of this standard. However, care should be22taken when allocating actual timer values in order to support interoperability between ANSI-41 MAP23and GSM MAP.24
Aspects of TIA/EIA-136 Rev C have been incorporated into this standard.25
Revision A adds GPRS service capability in GSM Foreign Mode.26
Revison B adds two way roaming between GSM and CDMA systems.27
X.S0023
2-1
1 Introduction1
1.1 General2
When a subscriber to one network type (e.g., ANSI-41) roams to a network of another type (e.g.,3GSM), interworking and interoperability functions are required to support the subscriber and enable4service. This standard describes an Interworking and Interoperability Function (IIF) to support this5cross-technology roaming between ANSI-41 and GSM networks. The IIF supports a multi-mode6mobile station with a removable Subscriber Identity Module (SIM). The standard also defines the7required network message mappings between ANSI-41 MAP and GSM MAP to support the mobile8terminal and associated services.9
This standard includes the support of cross-technology roaming from an ANSI-41 based network to10a GPRS network. The GPRS network may be coupled with a GSM network. This feature requires11enhancement to the Interworking and Interoperability Function (IIF) which supports a multi-mode12mobile station and Subscriber Identity Module (SIM) with GPRS functionality.13
Optionally, the IIF may support one way-roaming only from CDMA to GSM network. In this case14since no data is provisioned at the IIF level, it must generate the GSM triplets using as input the15authentication parameters returned by the ANSI-41 HLR/AC, and the ANSI-41 HLR/AC must be16compliant with PN-4925 (to be published as TIA/EIA-868 [11]). All the changes are made on the17assumption the new requirements for UIM/handsets are implemented. (Annex B)18
2 Purpose19
The purpose of this standard is to define and describe the functions necessary for roaming between20ANSI-41 MAP [2] and GSM MAP [4] based networks in the support of roaming subscribers. This21includes a capability to allow a subscriber to an ANSI-41 based network (e.g., an ANSI-41 TDMA or22CDMA native subscriber) with a mobile terminal supporting GPRS service to roam to a GPRS23network in GSM Foreign Mode.24
3 Scope25
The scope of this standard are the services, information flows and message mappings which26require interworking and interoperability functional specifications to support roaming between27ANSI-41 MAP and GSM MAP networks.28
The scope of this volume describes the “Information Flows” and addresses the functionality required29to support GSM and ANSI-41 network interoperability.30
X.S0023
2-2
4 Stage 2 Information Flows1
4.1 Location Registration2
4.1.1 Location Registration in GSM Foreign Mode3
4.1.1.1 MS registers in a GSM network when previously registered in an ANSI-41 network4
When an ANSI-41subscriber registers in a GSM network, when previously registered in an ANSI-415network, the MS performs a location update using the IMSI as shown in Figure 1. The IIF emulates6both a GSM HLR/AuC and an ANSI-41 VLR in this case.7
8
Figure 1: Registration on a GSM Network – GSM Foreign Mode9
MSMSC/VLR
IIF HLR
Update Location Req
Authentication Info
Authentication Info Ack
Authentication Req
Authentication Res
Update Location Req
REGNOT
regnot
GSM NETWORK ANSI-41 NETWORK
Insert Sub Data
Insert Sub Data Ack
Update Location Ack
Update Location Ack
MSC/VLR
REGCANC
regcanc
(IMSI)
(IMSI)
(MIN/IMSI)
a
b
c
d
e
f
g
h
i
j
k
l
m
n
X.S0023
2-3
a. MS powers up and registers in a GSM network. The MS sends an Update Location Request1(which includes the IMSI) to the network.2
b. If the serving VLR does not have authentication information in order to perform3authentication i.e. authentication triplets, it requests authentication information from the IIF.4The IIF emulates a GSM HLR/AuC in this case.5
c. The IIF returns the necessary authentication information.6
d. VLR initiates authentication towards the MS.7
e. MS responds to the authentication request.8
f. VLR initiates Location Updating towards the IIF. The Update Location Request contains the9IMSI.10
g. The IIF translates the GSM MAP Update Location Request into an ANSI-41 MAP REGNOT11and sends the REGNOT to the subscribers home HLR. The IIF is emulating an ANSI-4112VLR when it sends the REGNOT. If necessary, the subscriber IMSI in the Update Location13Request is mapped to the associated MIN.14
If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber15shall be passed in the REGNOT to the subscriber’s HLR. This ESN may not match the16currently validated dynamic ESN for this subscriber, but the HLR shall also accept this fixed17ESN for this subscriber.18
h. The HLR updates its location information and deletes the previous VLR record by sending a19REGCANC to the previous VLR.20
i. The VLR acknowledges the REGCANC21
j. The HLR returns an acknowledgement to the REGNOT (regnot)22
k. When the IIF receives the regnot, it initiates the GSM MAP Insert Subscriber Data23Procedure towards the serving VLR. This procedure is used to download subscriber data to24the serving VLR. Multiple Insert Subscriber Data transactions may be necessary to25complete the transfer of subscriber data to the VLR.26
l. The VLR acknowledges the Insert Subscriber Data operation(s).27
m. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the28IIF returns an acknowledgement for the Update Location Request.29
X.S0023
2-4
4.1.1.2 MS location updates in a different MSC/VLR1
When an ANSI-41subscriber roams within a GSM PLMN and registers in a different MSC/VLR area,2the MS performs a location update using the IMSI as shown in Figure 2.3
4
Figure 2: Registration in a different MSC/VLR – GSM Foreign Mode5a. MS powers up and registers in a different MSC/VLR in the same GSM network. The MS6
sends an Update Location Request (which includes the IMSI) to the network.78
b. If the serving VLR does not have authentication information in order to perform authentication9i.e. authentication triplets, it requests authentication information from the IIF. The IIF emulates10a GSM HLR/AuC in this case.11
12c. The IIF returns the necessary authentication information.13
14d. VLR initiates authentication towards the MS.15
16e. MS responds to the authentication request.17
18
MSMSC/VLR IIF PVLR
Update Location Req
Authentication Info
Authentication Info Ack
Authentication Req
Authentication Res
Update Location Req
Cancel Location
Cancel Location Ack
Insert Sub Data
Insert Sub Data Ack
Update Location Ack
Update Location Ack
(IMSI)
(IMSI)
a
b
c
d
e
f
g
h
i
j
k
l
HLR
REGNOT
regnot
m
n
X.S0023
2-5
1f. VLR initiates Location Updating towards the IIF. The Update Location Request contains the2
IMSI.34
g. The IIF sends a Cancel Location request to the previous VLR (PVLR) that the subscriber was5registered on.6
7h. The PVLR deletes the subscriber record and acknowledges the request.8
9i. Optionally, the IIF may send a Registration Notification to the HLR to indicate the changed10
location.1112
If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall13be passed in the REGNOT to the subscriber’s HLR. This ESN may not match the currently14validated dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for15this subscriber.16
17j. The HLR acknowledges the REGNOT.18
19k. The IIF initiates the GSM MAP Insert Subscriber Data Procedure towards the serving VLR.20
This procedure is used to download subscriber data to the new serving VLR. Multiple Insert21Subscriber Data transactions may be necessary to complete the transfer of subscriber data to22the VLR.23
24l. The VLR acknowledges the Insert Subscriber Data operation(s).25
26m. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the27
IIF returns an acknowledgement for the Update Location Request.2829
n. The new MSC/VLR acknowledges the location update request from the MS.30
Note: If the MS performs a location update in the same MSC/VLR area, either the IMSI or31TIMSI may be used as described in GSM 09.02 [4]. The IIF however, is not informed.32
4.1.1.3 IMSI Detach33
If an MS powers off while operating in GSM Foreign mode, and the IMSI Detach procedure is34supported, it shall perform an IMSI Detach as described in GSM 09.02 [4]. Neither the IIF or the35home HLR is informed.36
Terminating calls intended for this ANSI-41 subscriber, shall therefore be treated in the home HLR37as if that subscriber was available.38
If the MS remains inactive for an extended period of time (determined by operator), the VLR may39delete the subscriber record associated with that MS and shall send an MS PURGE to the IIF. In40this case, the IIF shall send an MS INACTIVE towards the ANSI-41 HLR and the ANSI-41 HLR shall41follow the procedures outlined in ANSI-41 [2]. Terminating calls intended for this ANSI-41subscriber42shall be treated in the home HLR as if that subscriber was not available.43
X.S0023
2-6
4.1.1.4 IMSI Attach1
If an MS powers on and registers on the same MSC/VLR (that has not deleted the subscriber2record) while operating in GSM Foreign mode and the IMSI Attach procedure is supported, it shall3perform an IMSI Attach as described in GSM 09.02 [4]. Neither the IIF or the home HLR is informed.4
If an MS powers on and registers on the same MSC/VLR (that has deleted the subscriber record),5while operating in GSM Foreign mode and the IMSI Attach procedure is supported, it shall perform6an IMSI Attach as described in GSM 09.02 [4]. The IIF shall be informed as shown in Section74.1.1.2. (however the IIF shall not send a Cancel Location to the MSC/VLR as it is the same8MSC/VLR).9
If an MS powers on and registers on a different MSC/VLR, while operating in GSM Foreign mode10and the IMSI Attach procedure is supported, it shall perform an IMSI Attach as described in GSM1109.02 [4]. The IIF shall be informed as shown in Section 4.1.1.2.12
X.S0023
2-7
4.1.2 Location Registration in ANSI-41 Foreign Mode1
4.1.2.1 MS registers in an ANSI-41 network when previously registered in a GSM network2
When a GSM subscriber registers in an ANSI-41 network, when previously registered in a GSM3network, the MS performs a location update using an IMSI or MIN as shown in Figure 3. The IIF4emulates both an ANSI-41 HLR and a GSM VLR in this case.5
6
Figure 3: Registration on an ANSI-41 network – ANSI-41 Foreign Mode78
a. Upon MS power up, if global authentication is active, the MS first sends an Authentication9message to the network. The MS then sends a Registration message (which includes the10IMSI or MIN) to the network.11
12b. If global authentication is active upon registration, the serving VLR initiates an AUTHREQ13
towards the IIF. The IIF emulates an ANSI-41 HLR/AC in this case.1415
The reported ESN for this subscriber shall be dynamic to support SIM-based roaming. The16IIF shall authenticate the subscriber using this reported ESN.17
18
MSMSC/VLR IIF HLR
Registration
AUTH REQ
Auth req
REGNOT
Update Location Req
Update Location Ack
ANSI-41 NETWORK GSM NETWORK
regnot
Reg_ack
MSC/VLR
Cancel Location
Cancel Loc Ack
(MIN/IMSI)
(IMSI)
a
b
c
d
e
f
g
h
i
j
X.S0023
2-8
c. The IIF acknowledges the authentication request. If authentication is successful, the IIF shall1store the reported ESN as the currently validated dynamic ESN for this subscriber. The2currently validated dynamic ESN shall be maintained by the ANSI-41 HLR emulation function3in the IIF.4
5d. VLR sends a REGNOT message to the IIF.6
7e. The IIF translates the ANSI-41 MAP REGNOT into a GSM MAP Update Location Request8
(which includes the IMSI) and sends the Update Location Request to the subscribers home9HLR. The IIF is emulating a GSM VLR when it sends the Update Location Request.10
11f. The HLR updates its location information and deletes the previous VLR record by sending a12
Cancel Location to the previous VLR.1314
g. The VLR acknowledges the Cancel Location. Note: The GSM Insert Subscriber data15procedure between the HLR and the IIF takes place between steps g and h.16
17h. The HLR acknowledges the Update Location Request18
19i. The IIF acknowledges the REGNOT. The acknowledgement also contains the subscriber data20
download to the new serving VLR.2122
j. The MSC/VLR acknowledges the Registration message from the MS.23
X.S0023
2-9
4.1.2.2 MS location updates in a different MSC/VLR1
When a GSM subscriber roams within an ANSI-41 network and registers in a different MSC/VLR2area, the MS performs a location update using an IMSI or MIN as shown in Figure 4.3
4
Figure 4: Registration in a different MSC/VLR – ANSI-41 Foreign Mode5a. MS powers up and registers in a new MSC/VLR in the same ANSI-41 network. If global6
authentication is active, the MS sends an Authentication message to the network. The MS7also sends a Registration message (which includes the IMSI / MIN) to the network.8
9b. If global authentication is active upon registration, the serving VLR initiates an AUTHREQ10
towards the IIF. The IIF emulates an ANSI-41 HLR/AC in this case.1112
The reported ESN for this subscriber shall be dynamic to support SIM-based roaming. The13IIF shall authenticate the subscriber using this reported ESN.14
15c. The IIF acknowledges the authentication request. If authentication is successful, the IIF shall16
store the reported ESN as the currently validated dynamic ESN for this subscriber.1718
MSMSC/VLR IIF PVLR
Registration
AUTH REQ
Auth req
REGNOT
REGCANC
regcanc
regnot
Reg_ack
(MIN/IMSI)
(MIN)
a
b
c
d
e
f
g
h
HLR
i
j
Location Update Req
Location Update Ack
X.S0023
2-10
The currently validated dynamic ESN shall be maintained by the ANSI-41 HLR emulation1function in the IIF.2
3d. VLR sends a REGNOT message to the IIF.4
5e. The IIF deletes the subscriber record in the previous VLR (PVLR), by sending a REGCANC to6
the PVLR.78
f. The PVLR acknowledges the REGCANC.910
g. Optionally, the IIF may send an Update Location Request to the HLR to indicate the changed11location.12
13h. The HLR acknowledges the update location.14
15i. The IIF acknowledges the REGNOT.16
17j. The new serving MSC/VLR acknowledges the Registration message from the MS.18
194.1.2.3 MS Powers Off20
If a mobile station powers off while operating in ANSI-41 Foreign mode, the IIF receives an MS21INACTIVE message from the serving VLR. This results in the IIF setting the ‘IMSI Detached’ Flag.22If the MS remains inactive for an extended period of time (determined by operator), the IIF may23delete the subscriber record associated with that MS and send an MS Purge to the HLR.24
4.1.2.4 MS Powers On25
If a mobile station powers on and registers on an MSC/VLR, while operating in ANSI-41 Foreign26mode, normal registration procedures apply.27
X.S0023
2-11
4.1.3 Location Registration in Native Mode1
4.1.3.1 MS registers in an ANSI-41 network when previously registered in a GSM network2
When an ANSI subscriber registers in an ANSI-41 network (Native Mode), when previously3registered in a GSM Network (Foreign Mode), the MS performs a location update and the temporary4subscriber data in the IIF is deleted as shown in figure 5.5
MSMSC/VLR
HLR IIF
Registration(MSID)
REGNOT(MSID)
REGCANC(MSID)
regcanc
regnot
Reg_ack
a
b
c
f
g
h
PVLR
d
e
Cancel Location(IMSI)
Cancel Location Ack
ANSI-41 NETWORK GSM NETWORK
AUTH REQ
Auth req
i
j
67
Figure 5: Registration in an ANSI-41 Network (Native Mode)8a. MS powers up and registers in a new MSC/VLR in an ANSI-41 network.9
If global authentication is active upon registration, the serving VLR initiates an AUTHREQ10towards the ANSI-41 HLR.11
The reported ESN for this subscriber shall be dynamic to support SIM-based roaming. The12HLR shall authenticate the subscriber using this reported ESN.13
14c. The HLR acknowledges the authentication request. If authentication is successful, the HLR15
shall store the reported ESN as the currently validated dynamic ESN for this subscriber.1617
d. The serving VLR sends a REGNOT to the HLR.1819
e. The HLR sends a REGCANC to the IIF.20
X.S0023
2-12
1f. The IIF deletes the temporary subscriber data and sends a Cancel Location to the previous VLR2
in the GSM network.34
g. The previous VLR deletes the relevant subscriber data and acknowledges the request.56
h. The IIF acknowledges the REGCANC.78
i. HLR updates the new serving VLR.910
j. The VLR acknowledges the update towards the MS.11
X.S0023
2-13
4.1.3.2 MS registers in a GSM network when previously registered in an ANSI-41 network1
When a GSM subscriber registers in a GSM network (Native Mode), when previously registered in2an ANSI-41 Network (Foreign Mode), the MS performs a location update and the temporary3subscriber data in the IIF is deleted as shown in figure 6.4
MSMSC/VLR
HLR IIF
Update Location Req(IMSI)
Update Location Req(IMSI)
Cancel Location(IMSI)
Cancel Location Ack
Insert Sub Data
Insert Sub Data Ack
Update Location Ack
Update Location Ack
a
b
c
f
g
h
i
j
PVLR
d
e
REGCANC(MSID)
regcanc
GSM NETWORK ANSI-41 NETWORK
5Figure 6: Registration in a GSM Network (Native Mode)6
a. MS powers up and registers in a new MSC/VLR in a GSM network.78
b. The serving VLR sends an Update Location Request to the HLR.910
c. The HLR sends a Cancel Location to the IIF.1112
d. The IIF deletes the temporary subscriber data and sends a REGCANC to the previous VLR in13the ANSI-41 network.14
15e. The Previous VLR deletes the relevant subscriber data and acknowledges the request.16
17f. The IIF acknowledges the Cancel Location Request.18
19g. HLR updates the new serving VLR.20
X.S0023
2-14
1h. The VLR acknowledges the update.2
3i. The HLR acknowledges the Update Location Request.4
5j. The VLR acknowledges the Update Location Request towards the MS.6
7
X.S0023
2-15
4.2 Fault Recovery Procedures1
After a fault of a location register, the fault recovery procedures ensure that the subscriber data in2the VLR becomes consistent with the subscriber data that are stored in the IIF (emulating an HLR)3or that subscriber data in the IIF (emulating a VLR) becomes consistent with the subscriber data4that are stored in the HLR for the MS concerned, and that the location information in the IIF5(emulating an HLR) and VLR or the HLR and IIF (emulating a VLR) reflect accurately the current6location of the MS.7
Existing fault recovery procedures described in GSM 09.02 [4] or ANSI-41D [2] are directly8applicable to the IIF, while the IIF is emulating a GSM or ANSI 41 functional entity.9
4.2.1 Fault Recovery Procedures in GSM Foreign Mode10
4.2.1.1 Recovery from Failure at the ANSI-41 HLR11
When the ANSI-41 HLR returns to a stable state after suffering a failure, it shall send the IIF12(emulating an ANSI-41 VLR) an UnreliableRoamerDataDirective message (UNRELDIR) as13described in ANSI 41.3 D [2], informing the IIF that it has experienced a failure which has rendered14the HLR’s roaming MS data unreliable. Figure 7 below shows the call flow.15
When the roaming MS next makes radio contact, the serving GSM VLR shall initiate the location16updating procedure towards the IIF.17
18
Figure 7: Failure at the ANSI-41 HLR (GSM Foreign Mode)1920
a. HLR returns to stable state following a failure and sends an UNRELDIR towards the IIF.2122
b. The IIF acknowledges the request and removes all the temporary subscriber data of all the MSs23associated with that HLR from its memory.24
25c. The IIF may reload its data from a non-volatile backup (optional) and shall send a RESET26
towards each of the serving VLRs. The RESET message contains a unique identity, identifying27the ANSI-41 HLR that failed and that is connected to the IIF.28
29
VLR IIF HLR
GSM NETWORK ANSI-41 NETWORK
UNRELDIR
RESET
unreldir
a
b
c
X.S0023
2-16
When the MS next establishes authenticated radio contact (including a mobile originated call1attempt), the VLR initiates location updating towards the IIF (See 4.1.1).2
4.2.1.2 Recovery from Failure at the IIF3
If the IIF suffers a failure, it shall follow the recovery procedure described in GSM 09.02 [4] section419.3.2 (i.e. IIF is acting like a GSM HLR). As part of the recovery procedure, the IIF shall send all5the serving GSM VLRs a RESET message for each associated ANSI-41 HLR as shown in step a) in6Figure 8. The message shall contain a unique identifier for the ANSI-41 HLR. In addition, the IIF7shall send a BULKDEREG to all affected ANSI-41 HLRs (i.e. IIF is acting like an ANSI-41 VLR).8
Figure 8: IIF Failure (GSM Foreign Mode)9a. The IIF sends a RESET towards each of the affected VLRs, containing a unique identity,10
identifying the ANSI-41 HLRs connected to the IIF.1112
b. The IIF sends a BULKDEREG towards all the affected ANSI-41 HLRs. On reception of the13BULKDEREG the HLR(s) follow(s) the procedures as described in ANSI-41.6D [2].14
15c. The ANSI-41 HLR(s) responds with a bulkdereg.16
17When the MS next establishes authenticated radio contact (including a mobile originated call18attempt), the VLR initiates location updating towards the IIF (See 4.1.1).19
2021
VLR IIF HLR
GSM NETWORK ANSI-41 NETWORK
RESET
BULKDEREG
a
b
cbulkdereg
X.S0023
2-17
4.2.1.3 Recovery from Failure at the serving GSM VLR1
If the VLR suffers a failure, it shall follow the recovery procedure described in GSM 09.02 [4] section219.3.1. As part of the recovery procedure, when a MS next establishes authenticated radio contact,3the VLR shall initiate location updating towards the IIF (See 4.1.1).4
If the VLR receives a request for a roaming number from the IIF following a failure, the VLR shall5send a RESTORE DATA message to the IIF as shown in Figure 9.6
Figure 9: Terminating Call Flow following a GSM VLR Failure78
a. Terminating call arrives for MS following a GSM VLR failure.910
b,c,d The IIF follows normal mobile terminated call handling procedures (See 4.5.2.1).1112
e. The VLR may request more authentication sets prior to sending Restore Data to the IIF to13request subscriber data.14
15f. The IIF downloads subscriber data to the VLR.16
g. The VLR acknowledges the operation.17
h. The IIF acknowledges the Restore Data Operation.18
VLR IIF HLR
GSM NETWORKANSI-41 NETWORK
PROVIDE ROAMING NO
INSERT SUB DATA
INSERT SUB DATA ACK
a
b
c
d
e
f
g
h
ROUTREQ
RESTORE DATA
RESTORE DATA ACK
PROVIDE ROAMING NO ACK
routreq
X.S0023
2-18
4.2.2 Fault Recovery Procedures in ANSI-41 Foreign Mode1
4.2.2.1 Recovery from Failure at the GSM HLR2
When a GSM HLR undergoes a restart, it shall follow the procedures described in GSM 09.02 [4]3section 19.3.2. As part of the recovery procedure, the HLR sends the IIF a RESET message,4informing the IIF that it has experienced a failure, which has rendered the HLR’s roaming MS data5unreliable. When the roaming MS next makes radio contact, the serving ANSI-41 VLR shall initiate6the location updating procedure towards the IIF. Figure 10 below shows the call flow.7
8Figure 10: Failure at a GSM HLR (ANSI-41 Foreign Mode)9
10
a. The HLR follows the recovery procedures described in GSM 09.02 [4] section 19.3.2. The11affected sends a RESET towards the IIF.12
13b. The IIF follows the procedures described in GSM 09.02 [4] section 19.3.2 on reception of the14
RESET and sends an UNRELDIR towards each of the serving ANSI-41 VLRs. The UNRELDIR15message contains a unique identity, identifying the affected GSM HLR.16
17c. The VLR follows the procedures described in ANSI-41.3 [2] and ANSI-41.6 [2] and18
acknowledges the UNRELDIR.1920
When the MS next establishes authenticated radio contact (including a mobile originated call21attempt), the VLR initiates location updating towards the IIF (See 4.1.2.1).22
23
HLR IIF VLR
GSM NETWORKANSI-41 NETWORK
UNRELDIR
RESET
unreldir
a
b
c
X.S0023
2-19
4.2.2.2 Recovery from Failure at the IIF1
If the IIF suffers a failure, it shall follow the recovery procedure described in ANSI-41.6 [2] (i.e. IIF is2acting like an ANSI HLR). As part of the recovery procedure, the IIF shall send all the serving3ANSI-41 VLRs an UNRELDIR message for each associated GSM HLR as shown in steps b and c in4Figure 10. The message shall contain a unique identifier for the GSM HLR.5
When the MS next establishes authenticated radio contact (including a mobile originated call6attempt), the VLR initiates location updating towards the IIF (See 4.1.2.2).7
If following an IIF failure, the IIF receives a request for routing information, it shall send a RESTORE8DATA towards the requesting GSM HLR.9
4.2.2.3 Recovery from Data Failure at the ANSI-41 VLR10
If the ANSI-41 VLR suffers a failure, it shall follow the recovery procedure described in ANSI-41.611[2]. As part of the recovery procedure, when an MS next establishes authenticated radio contact,12the VLR shall initiate location updating towards the IIF.13
Upon receipt of a BULKDEREG, the IIF shall clear the location pointer for those MSs that were14registered on that VLR. If following the reception of a BULKDEREG, the IIF receives a request for15routing information, the terminating call towards the MS shall not be possible until the MS has16performed a successful location registration.17
X.S0023
2-20
4.4 Subscriber Data Management1
4.4.1 Subscriber Data Management Procedures in ANSI-41 Foreign Mode2Two types of subscriber data management procedures are defined in GSM 09.02 [4]. These3procedures impact the GSM subscribers HLR, the IIF and the serving VLR when the subscriber is4operating in ANSI-41 Foreign Mode. For these procedures, only modification to temporary5subscriber data in the IIF is addressed. The procedures are (1) Subscriber Deletion and (2)6Subscriber Data Modification.7
4.4.1.1 Subscriber Deletion8
In this procedure, temporary subscriber data shall be removed from the HLR, IIF and the serving9MSC/VLR as shown in Figure 25.10
Figure 25: Subscriber Deletion – ANSI-41 Foreign Mode11
a. Operations and Maintenance Center (OMC) initiates a request to delete a subscriber.12
b. The HLR deletes the subscriber data from the HLR and sends a Cancel Location request to13the IIF.14
c. The IIF deletes the temporary subscriber data from the IIF and sends a Registration15Cancellation to the serving MSC/VLR. The CancellationType in this operation shall be set to16“Discontinue” to tear down any active call.17
d. The VLR deletes the subscriber data from the VLR and returns an acknowledgement to the18IIF.19
MSC/VLR IIF HLR
ANSI-41 NETWORK GSM NETWORK
OMC
Delete Subscriber
Subscriber Deleted
Cancel Location
Cancel Location Ack
REGISTRATION_CANCELLATION
Registration_cancellation
a
b
c
d
e
f
X.S0023
2-21
e. The IIF acknowledges the cancel location request.1
f. The HLR acknowledges the delete subscriber request.23
4.4.1.2 Subscriber Data Modification4
The OMC can modify subscriber data in several different ways e.g. withdrawal of a basic or5supplementary service, roaming modifications, data modifications to both HLR and VLR. Depending6on the data modification required, one of three MAP procedures is initiated from the HLR towards7the IIF. These procedures are described in more detail in GSM 09.02 [4].8
4.4.1.2.1 Insert Subscriber Data Procedure9
Where data is required to be modified in the HLR, IIF and the serving VLR, the HLR initiates the10Insert Subscriber Data Procedure towards the IIF as shown in Figure 26.11
Figure 26: Insert Subscriber Data Procedure12
a. OMC initiates a request to modify subscriber data.13
b. The HLR modifies the subscriber data in the HLR and initiates the Insert Subscriber Data14Operation towards the IIF.15
c. The IIF modifies the subscriber data in the IIF and sends a QUALDIR to the serving MSC/VLR.16There may be some cases where the subscriber data change cannot be mapped to an17associated ANSI-41subscriber profile modification. In this case, no QualDir operation shall be18initiated.19
d. The serving MSC/VLR modifies the subscriber data and acknowledges the QUALDIR20
MSC/VLR IIF HLR
ANSI-41 NETWORK GSM NETWORK
OMC
Modify Subscriber Data
Subscriber Data Modified
Insert Subscriber Data
Insert Subscriber Data Ack
a
b
c
d
e
f
QUALDIR
qualdir
X.S0023
2-22
e. The IIF acknowledges the Insert Subscriber Data Request.1
f. The HLR acknowledges the request to modify subscriber data.23
4.4.1.2.2 Delete Subscriber Data Procedure4
If a basic or supplementary service is withdrawn, which requires a change to VLR data, the HLR5initiates the Delete Subscriber Data Procedure towards the IIF as shown in Figure 27.6
7
Figure 27: Delete Subscriber Data Procedure8
a. OMC initiates a request to modify subscriber data.9
b. The HLR deletes the relevant subscriber data in the HLR and initiates the Delete Subscriber10Data Operation towards the IIF.11
c. The IIF deletes the relevant subscriber data in the IIF and sends a QUALDIR to the serving12MSC/VLR. There may be some cases where the subscriber data deletion cannot be13mapped to an associated ANSI-41subscriber profile modification. In this case, no QualDir14operation shall be initiated.15
d. The serving MSC/VLR deletes the relevant subscriber data and acknowledges the16QUALDIR.17
e. The IIF acknowledges the Delete Subscriber Data Request.18
f. The HLR acknowledges the request to modify subscriber data.19
MSC/VLR IIF HLR
ANSI-41 NETWORK GSM NETWORK
OMC
Modify Subscriber Data
Subscriber Data Modified
Delete Subscriber Data
Delete Subscriber Data Ack
a
b
c
d
e
f
QUALDIR
qualdir
X.S0023
2-23
4.4.1.2.3 Cancel Location Procedure1
If roaming modifications are required, which require the subscriber to be removed from the VLR2data, the HLR initiates the Cancel Location Procedure towards the IIF as shown in Figure 28.3
Figure 28: Cancel Location Procedure4
a. OMC initiates a request to modify subscriber data.5
b. The HLR deletes the relevant subscriber data in the HLR and initiates the Cancel Location6Operation towards the IIF.7
c. The IIF deletes the temporary subscriber data in the IIF and sends a REGCANC to the8serving MSC/VLR.9
d. The serving MSC/VLR deletes the relevant subscriber data and acknowledges the10REGCANC.11
e. The IIF acknowledges the Cancel Location Request.12
f. The HLR acknowledges the request to modify subscriber data.13
MSC/VLR IIF HLR
ANSI-41 NETWORK GSM NETWORK
OMC
Modify Subscriber Data
Subscriber Data Modified
Cancel Location
Cancel Location Ack
REGISTRATION_CANCELLATION
Registration_cancellation
a
b
c
d
e
f
X.S0023
2-24
MSC/VLR
IIF HLR
GSM NETWORKANSI-41 NETWORK
OMC
Sub Data Delete
Sub Data Delete Ack
REGCANC
regcanc
a
b
c
d
e
f
Cancel Location
Cancel Location Ack
4.4.2 Subscriber Data Management Procedures in GSM Foreign Mode1Subscriber data management procedures are defined in ANSI 41-D, Section 6. These procedures2impact the ANSI-41subscribers HLR, the IIF and the serving VLR when the subscriber is operating3in GSM Foreign Mode. For these procedures, only modification to temporary subscriber data in the4IIF is addressed.5
4.4.2.1 Subscriber Deletion6
The OMC may request that subscriber data relating to a particular subscriber is removed from the7HLR. In this case, subscriber data shall also be removed from the IIF and the serving MSC/VLR as8shown in Figure 29.9
10
Figure 29: Subscriber Deletion- GSM Foreign Mode11a. OMC initiates a request to delete a subscriber12
b. The HLR deletes the subscriber data from the HLR and sends a REGCANC to the IIF.13
c. The IIF deletes the temporary subscriber data from the IIF and sends a Cancel Location to the14serving VLR.15
d. The VLR acknowledges the cancel location16
e. The IIF acknowledges the REGCANC17
f. The HLR acknowledges the request to delete subscriber data.18
X.S0023
2-25
MSC/VLR
IIF HLR
GSM NETWORKANSI-41 NETWORK
OMC
Sub Data Change
Sub Data Change Ack
QUALDIR
qualdir
a
b
c
d
e
f
Insert Sub Data
Insert Sub Data Ack
4.4.2.2 Modifying Subscriber Data1
The OMC may request that subscriber data relating to a particular subscriber is modified (e.g., the2authorization or de-authorization of a particular feature). In this case, subscriber data may also be3required to be modified in the IIF and the serving MSC/VLR as shown in Figure 30.4
5
Figure 30: Subscriber Data Modification67
a. OMC initiates a request to modify subscriber data8
b. The HLR modifies the subscriber data from the HLR and sends a QUALDIR to the IIF.9
c. The IIF modifies the temporary subscriber data and sends Insert Subscriber Data to the VLR if10for example, a feature has been authorized or activated.11
Note: The IIF sends a Delete Subscriber Data message if for example, a feature has been12de-authorized or de-activated. There may be multiple ISD or DSD operations. There may be13some cases where the subscriber data change cannot be mapped to an associated GSM14subscriber profile modification. In this case, no ISD or DSD operation shall be initiated.15
d. The VLR acknowledges the request16
e. The IIF acknowledges the QUALDIR17
f. The HLR acknowledges the request to modify subscriber data18
19
X.S0023
2-26
4.5 Automatic Call Delivery1
This section depicts the interactions between network entities in various situations related to GSM2and ANSI-41 foreign mode operation and automatic call delivery. These scenarios are not meant to3be exhaustive.4
4.5.1 Automatic Call Delivery Activation/Deactivation5Activation and deactivation of call delivery is not required to be supported.6
4.5.2 Automatic Call Delivery Invocation7Automatic call delivery is invoked when an incoming call attempt arrives for a subscriber who is8roaming. Call delivery scenarios for both the case in which an ANSI-41subscriber is roaming in a9GSM network and the case in which a GSM subscriber is roaming in an ANSI-41 network are10provided.11
4.5.2.1 Call Delivery to ANSI-41Subscriber Roaming in GSM Network12
d
LOCREQ
locreq
ROUTREQ
MSC/VLR
HLR IIF
a
b
c
e
f
Serving System
Call setup
GSM MSC/VLR
Provide Roaming No.
PRN Ack
routreq
g
Incoming CallFrom PSTN
h
13Figure 31: Call Delivery to ANSI-41 Subscriber Roaming in a GSM Network14
a. A call origination and the dialed MS address digits (i.e., directory number) are received by the15Originating MSC from the PSTN destined to a subscriber to the ANSI-41 network.16
b. The Originating MSC sends a LOCREQ to the HLR associated with the called subscriber; this17association is made through the dialed MS address digits.18
c. The HLR sends a ROUTREQ to the IIF emulating the VLR where the MS is registered.19d. The IIF forwards a Provide Roaming Number message to the VLR/GSM MSC where the MS is20
registered. If necessary, mapping from MIN to IMSI is done by the IIF.21e. The VLR/GSM MSC returns a Provide Roaming Number Ack message to the IIF that includes22
an MSRN.23
X.S0023
2-27
f. The IIF returns a routreq message to the HLR that includes a TLDN (Temporary Local Directory1Number), set to the received MSRN, in the Digits (Destination) parameter. Note that the MSRN2is always in international format. It is assumed that the gateway MSC on the ANSI-41 side is3capable of supporting internationally formatted TLDNs.4
g. When the routreq is received by the HLR, it returns a locreq to the Originating MSC. The locreq5includes routing information in the form of the TerminationList parameter, along with an6indication of the reason for extending the incoming call (i.e., for Call Delivery, in this case) in the7DMH_RedirectionIndicator parameter.8
h. Upon receiving the locreq, the Originating MSC sets up a voice path to the Serving GSM MSC9(using a protocol such as SS7 ISUP).10
X.S0023
2-28
4.5.2.2 Delivery to an ANSI-41Subscriber Roaming in a GSM Network – Unsuccessful Case1
In the following scenario, call delivery to an ANSI-41subscriber roaming in a GSM network fails2during the processing of the Provide Roaming Number message (e.g., no roaming number is3available, absent subscriber).4
d
LOCREQ
locreq Ret Error
ROUTREQ
MSC/VLR
HLR IIF
a
b
c
e
f
Serving System
GSM MSC/ VLR
Provide Roaming No.
PRN Return Error
routreq Ret Error
g
Incoming CallFrom PSTN
ANSI-41 Home System
5Figure 32: Unsuccessful Call Delivery to an ANSI-41Subscriber Roaming in a GSM Network6
a. A call origination and the dialed MS address digits (i.e., directory number) are received by the7Originating ANSI-41 MSC from the PSTN destined to a subscriber to the ANSI-41 network.8
b. The Originating ANSI-41 MSC sends a LOCREQ message to the ANSI-41 HLR associated with9the called subscriber; this association is made through the dialed MS address digits.10
c. The ANSI-41 HLR sends a ROUTREQ message to the IIF emulating the VLR where the MS is11registered. If necessary, mapping from IMSI to MIN is done beforehand by the IIF.12
d. The IIF forwards a Provide Roaming Number message to the GSM VLR/MSC where the MS is13registered.14
e. The GSM VLR/MSC determines that either no roaming numbers are available or subscriber is15not reachable and it replies with a PRN Return Error message.16
f. The IIF sends a RoutingRequest RETURN ERROR message.17g. The ANSI-41 HLR sends a LocationRequest RETURN ERROR message.18
X.S0023
2-29
4.5.2.3 Call Delivery to a GSM Subscriber Roaming in ANSI-41 Network – Successful Case1
d
Send Routing Info
SRI Ack
Provide Roaming No.
GSMMSC/VLR
GSMHLR IIF
a
b
c
e
f
ANSI-41 Serving System
Call setup
MSC/VLR
ROUTREQ
routreq
PRN Ack
g
Incoming CallFrom PSTN
h
GSM Home System
2Figure 33: Call Delivery to GSM Subscriber Roaming in an ANSI-41 Network3
a. A call origination and the dialed MS address digits (i.e., directory number) are received by the4Originating MSC from the PSTN destined to a subscriber to the GSM network.5
b. The Gateway GSM MSC sends a Send Routing Information message to the GSM HLR6associated with the called subscriber; this association is made through the dialed MS address7digits.8
c. The GSM HLR sends a Provide Roaming Number message to the IIF emulating the VLR where9the MS is registered. If necessary, mapping from IMSI to MIN is done beforehand by the IIF.10
d. The IIF forwards a ROUTREQ message to the VLR/MSC where the MS is registered.11e. The serving VLR/ MSC returns a routreq message that includes a TLDN to the IIF.12f. The IIF returns a Provide Roaming Number Ack message that includes an MSRN (set to the13
received TLDN) to the GSM HLR. If the TLDN is not received in international format, the IIF14shall first convert the TLDN to international format (by prepending the country code associated15with the serving system) before setting the MSRN equal to it.16
g. When the Provide Roaming Number Ack is received by the GSM HLR, it returns a Send17Routing Information Ack message to the Gateway GSM MSC.18
h. Upon receiving the Send Routing Information Ack message, the Gateway GSM MSC sets up a19voice path to the Serving MSC (using a protocol such as SS7 ISUP).20
X.S0023
2-30
4.5.2.4 Call Delivery to a GSM Subscriber Roaming in ANSI-41 Network – Unsuccessful Case1
In the following scenario, call delivery to a GSM subscriber roaming in an ANSI-41 network fails2because the user is either ‘not reachable’ as determined by the IIF or does not answer a page sent3by the serving system during the processing of the RouteRequest message, and call forwarding is4not active for the subscriber.5
d
Send Routing Info
SRI Ret Error
Provide Roaming No.
GSMMSC/VLR
GSMHLR IIF
a
b
c
e
f
ANSI-41 Serving System
MSC/VLR
ROUTREQ
routreq[ACCDEN]
PRN Ret Error
g
Incoming CallFrom PSTN
GSM Home System
6Figure 34: Unsuccessful Call Delivery to GSM Subscriber Roaming in an ANSI-41 Network7
a. A call origination and the dialed MS address digits (i.e., directory number) are received by the8Originating MSC from the PSTN destined to a subscriber to the GSM network.9
b. The Gateway GSM MSC sends a Send Routing Information message to the GSM HLR10associated with the called subscriber; this association is made through the dialed MS address11digits.12
c. The GSM HLR sends a Provide Roaming Number message to the IIF emulating the VLR where13the MS is registered. If necessary, mapping from IMSI to MIN is done beforehand by the IIF. If14the IIF determines that the called subscriber is not reachable, it returns an absent subscriber15error as in step f.16
d. If the IIF determines that the subscriber is reachable, it forwards a ROUTREQ message to the17VLR/MSC where the MS is registered.18
e. The VLR/MSC pages the subscriber does not get a response and returns a routreq message19with an AccessDeniedReason parameter set to NoPageResponse.20
f. The IIF returns a Provide Roaming Number Return Error message with the error code set to21Subscriber Absent to the subscriber’s GSM HLR.22
g. The GSM HLR sends a Send Routing Information Return Error message to the Gateway GSM23MSC with the Subscriber Absent error code, and the appropriate treatment (e.g. announcement)24is provided to the incoming call by the Gateway GSM MSC.25
X.S0023
2-31
4.6 Call Forwarding1
4.6.1 Call forwarding scenarios for ANSI-41 foreign mode2The scenarios in this section illustrate the call forwarding information flows applicable to a GSM3native subscriber roaming in an ANSI-41 network (i.e., ANSI-41 foreign mode).4
4.6.1.1 Call forwarding unconditional (CFU)5
The following scenarios illustrate the call forwarding unconditional (CFU) information flows6applicable to ANSI-41 foreign mode operation.7
4.6.1.1.1 CFU registration8
This scenario illustrates the CFU registration information flows applicable to ANSI-41 foreign mode9operation.10
h
e
f
g
a
b
c
d
REG_SS
HLR VMSC 2
GSM Home System
ANSI-41 Serving System
FEATREQ [digits]
featreq [success]
MS
Subscriber
feature code digits
reg_ss
feature confirmation
ANSI-41GSM
IIF
j
i
k
ISD
isd
[TCAP End]
QUALDIR
qualdir
11Figure 35: CFU registration12
13
X.S0023
2-32
a. The ANSI-41 serving system receives dialed digits from the subscriber’s mobile station (MS).1The serving system detects a “*” character as the first dialed digit. This indicates that the dialed2digits are a feature code string.13
4b. The serving system sends a FEATREQ message to the IIF, including the digits received from5
the subscriber.67
c. The IIF parses the received digit string. In this case, the subscriber has requested to register a8call forwarding number. The IIF sends a REG_SS message to the GSM HLR.29
10d. The HLR processes the request and returns a reg_ss message to the IIF, indicating operation11
success.1213
e. The IIF sends a featreq message to the serving system, indicating a successful feature control14request.15
16f. The serving system sends a feature confirmation signal to the subscriber.17
18g. The GSM HLR initiates a service profile update by sending an Insert Subscriber Data (ISD)19
message to the IIF, containing the new or modified profile data (e.g., the new call forward20number).21
22h. The IIF responds with an ISD acknowledgement message. Note that, if the subscriber’s profile23
is too large for a single ISD message, then multiple ISD exchanges may be executed between24the GSM HLR and the IIF.25
26i. The GSM HLR completes the operation by closing the TCAP transaction.27
28j. The IIF converts the revised GSM profile data into ANSI-41 equivalents. If this results in a29
change in the value of the subscriber’s ANSI-41 profile, the IIF includes the revised ANSI-4130profile data in a QUALDIR message it sends to the serving system.31
32k. The serving system stores the new profile information and responds with a qualdir message.33
34
1 Some ANSI-41 serving systems may perform further digit analysis before concluding that the digitsrepresent a feature code string. This analysis may also include screening for allowable feature code strings(e.g., cellular A-side codes only). This may limit the ability of the subscriber to control features whileroaming on the ANSI-41 serving system.
2 Because the IIF must provide the new call forwarding number digits in the REG_SS message, these digitsshall be provided by the subscriber (or the subscriber’s mobile station).
X.S0023
2-33
4.6.1.1.2 CFU deregistration (erasure)1
This scenario illustrates the CFU deregistration information flows applicable to ANSI-41 foreign2mode operation.3
h
e
f
g
a
b
c
d
ERASE_SS
HLR VMSC 2
GSM Home System
ANSI-41 Serving System
FEATREQ [digits]
featreq [success]
MS
Subscriber
feature code digits
erase_ss
feature confirmation
ANSI-41GSM
IIF
j
i
k
ISD
isd
[TCAP End]
QUALDIR
qualdir
4Figure 36: CFU deregistration (erasure)5
a. The ANSI-41 serving system receives dialed digits from the subscriber’s mobile station (MS).6The serving system detects a “*” character as the first dialed digit. This indicates that the dialed7digits are a feature code string.8
9b. The serving system sends a FEATREQ message to the IIF, including the digits received from10
the subscriber.1112
c. The IIF parses the received digit string. In this case, the subscriber has requested to erase a13call forwarding number. The IIF sends an ERASE_SS message to the GSM HLR.14
15d. The HLR processes the request and returns an erase_ss message to the IIF, indicating16
operation success.171819
e. The IIF sends a featreq message to the serving system, indicating a successful feature control20request.21
22f. The serving system sends a feature confirmation signal to the subscriber.23
X.S0023
2-34
1g. The GSM HLR initiates a service profile update by sending an Insert Subscriber Data (ISD)2
message to the IIF, containing the new or modified profile data (e.g., the new ss-status value).345
h. The IIF responds with an ISD acknowledgement message. Note that, if the subscriber’s profile6is too large for a single ISD message, then multiple ISD exchanges may be executed between7the GSM HLR and the IIF.8
9i. The GSM HLR completes the operation by closing the TCAP transaction.10
11j. The IIF converts the revised GSM profile data into ANSI-41 equivalents. If this results in a12
change in the value of the subscriber’s ANSI-41 profile, the IIF includes the revised ANSI-4113profile data in a QUALDIR message it sends to the serving system.14
15k. The serving system stores the new profile information and responds with a qualdir message.16
X.S0023
2-35
14.6.1.1.3 CFU activation2
This scenario illustrates the CFU activation information flows applicable to ANSI-41 foreign mode3operation.4
QUALDIR
qualdir
h
e
f
g
a
b
c
d
ACT_SS
HLR VMSC2
GSMHome System
ANSI-41Serving System
FEATREQ [digits]
featreq [success]
MS
Subscriber
feature codedigits
act_ss
featureconfirmation
ANSI-41GSM
IIF
j
i
k
ISD
isd
[TCAP End]
5Figure 37: CFU activation6
a. The ANSI-41 serving system receives dialed digits from the subscriber’s mobile station (MS).7The serving system detects a “*” character as the first dialed digit. This indicates that the dialed8digits are a feature code string.9
10b. The serving system sends a FEATREQ message to the IIF, including the digits received from11
the subscriber.1213
c. The IIF parses the received digit string. In this case, the subscriber has requested to activate14call forwarding. The IIF sends an ACT_SS message to the GSM HLR.15
16d. The HLR processes the request and returns an act_ss message to the IIF, indicating operation17
success.1819
e. The IIF sends a featreq message to the serving system, indicating a successful feature control20request.21
22
X.S0023
2-36
f. The serving system sends a feature confirmation signal to the subscriber.12
g. The GSM HLR initiates a service profile update by sending an Insert Subscriber Data (ISD)3message to the IIF, containing the new or modified profile data (e.g., the new ss-status value).4
5h. The IIF responds with an ISD acknowledgement message. Note that, if the subscriber’s profile6
is too large for a single ISD message, then multiple ISD exchanges may be executed between7the GSM HLR and the IIF.8
9i. The GSM HLR completes the operation by closing the TCAP transaction.10
11j. The IIF converts the revised GSM profile data into ANSI-41 equivalents. If this results in a12
change in the value of the subscriber’s ANSI-41 profile, the IIF includes the revised ANSI-4113profile data in a QUALDIR message it sends to the serving system.14
15k. The serving system stores the new profile information and responds with a qualdir message.16
17
X.S0023
2-37
4.6.1.1.4 CFU deactivation1
This scenario illustrates the CFU deactivation information flows applicable to ANSI-41 foreign mode2operation.3
QUALDIR
qualdir
h
e
f
g
a
b
c
d
DEACT_SS
HLR VMSC 2
GSM Home System
ANSI-41 Serving System
FEATREQ [digits]
featreq [success]
MS
Subscriber
feature code digits
deact_ss
feature confirmation
ANSI-41GSM
IIF
j
i
k
ISD
isd
[TCAP End]
4Figure 38: CFU deactivation5
a. The ANSI-41 serving system receives dialed digits from the subscriber’s mobile station (MS).6The serving system detects a “*” character as the first dialed digit. This indicates that the dialed7digits are a feature code string.8
9b. The serving system sends a FEATREQ message to the IIF, including the digits received from10
the subscriber.1112
c. The IIF parses the received digit string. In this case, the subscriber has requested to deactivate13call forwarding. The IIF sends a DEACT_SS message to the GSM HLR.14
15d. The HLR processes the request and returns a deact_ss message to the IIF, indicating operation16
success.1718
e. The IIF sends a featreq message to the serving system, indicating a successful feature control19request.20
21f. The serving system sends a feature confirmation signal to the subscriber.22
23
X.S0023
2-38
g. The GSM HLR initiates a service profile update by sending an Insert Subscriber Data (ISD)1message to the IIF, containing the new or modified profile data (e.g., the new ss-status value).2
3h. The IIF responds with an ISD acknowledgement message. Note that, if the subscriber’s profile4
is too large for a single ISD message, then multiple ISD exchanges may be executed between5the GSM HLR and the IIF.6
7i. The GSM HLR completes the operation by closing the TCAP transaction.8
9j. The IIF converts the revised GSM profile data into ANSI-41 equivalents. If this results in a10
change in the value of the subscriber’s ANSI-41 profile, the IIF includes the revised ANSI-4111profile data in a QUALDIR message it sends to the serving system.12
13k. The serving system stores the new profile information and responds with a qualdir message.14
154.6.1.1.5 CFU Interrogation16
While in ANSI-41 foreign mode, the GSM subscriber does not have the capability to interrogate the17CFU service. An attempt to perform such an operation shall result in an error response18
4.6.1.1.6 CFU invocation19
This scenario illustrates the CFU invocation information flows applicable to ANSI-41 foreign mode20operation.21
d
c
GMSC HLR VMSC2
a
b
GSMHome System
ANSI-41Serving System
GSMGateway
SRI
sri [CFU#]
forward call to CFU #
incoming call
ANSI-41GSM
IIF
22Figure 39: CFU invocation23
a. The GSM gateway MSC (GMSC) receives an incoming call for the subscriber.2425
b. The GMSC sends a SRI message to the HLR.2627
c. The GSM HLR determines that the subscriber has CFU registered and active; therefore, the28HLR responds with the subscriber’s CFU forward-to number in the sri message.29
30d. The GMSC forwards the call to the CFU forward-to number.31
X.S0023
2-39
4.6.1.2 Call forwarding busy (CFB)1
2The following scenarios illustrate the call forwarding busy (CFB) information flows applicable to3ANSI-41 foreign mode operation.44.6.1.2.1 CFB registration5
See 4.6.1.1.1 for the CFB registration information flows applicable to ANSI-41 foreign mode6operation, since they are the same as those for CFU.74.6.1.2.2 CFB deregistration (erasure)8
See 4.6.1.1.2 for the CFB deregistration information flows applicable to ANSI-41 foreign mode9operation, since they are the same as those for CFU.104.6.1.2.3 CFB activation11
See 4.6.1.1.3 for the CFB activation information flows applicable to ANSI-41 foreign mode12operation, since they are the same as those for CFU.134.6.1.2.4 CFB deactivation14
See 4.6.1.1.4 for the CFB deactivation information flows applicable to ANSI-41 foreign mode15operation, since they are the same as those for CFU.164.6.1.2.5 CFB Interrogation17
While in ANSI-41 foreign mode, the GSM subscriber does not have the capability to interrogate the18CFB service. An attempt to perform such an operation shall result in an error response.19
X.S0023
2-40
4.6.1.2.6 CFB invocation1
The following scenarios illustrate the CFB invocation information flows applicable to ANSI-41 foreign2mode operation.3
4.6.1.2.6.1 CFB invocation (Scenario 1a, “CFB#=MSRN method”)4
In this scenario, the busy condition is detected by the ANSI-41 serving system when the5RoutingRequest Invoke message is received, and the IIF returns the CFB forward-to number (i.e.,6as the MSRN) to the GSM HLR in the ProvideRoamingNumber Return Result message.7
i
h
g
GMSC HLR VMSC 2
a
b
c
d
e
GSM Home System
ANSI-41 Serving System
ROUTREQ
routreq [Busy]
GSM Gateway
PRN
SRI
sri [CFB #]
prn [CFB #]
f
setup call to MSRN=CFB #
Subscriber is detected busy
incoming call
ANSI-41GSM
IIF
8Figure 40: CFB invocation (Scenario 1a, “CFB#=MSRN method”)9
a. The GSM GMSC receives an incoming call for the subscriber.1011
b. The GMSC sends a SRI message to the HLR.1213
c. The HLR sends a PRN message to the current GSM serving system; i.e., the IIF.1415
d. The IIF sends a ROUTREQ message to the ANSI-41 serving system.1617
e. The serving system determines that the subscriber is busy.1819
f. Therefore, the serving system returns a routreq message, containing the AccessDeniedReason20parameter set to the value Busy.21
22The IIF determines that CFB is active for the subscriber. The IIF sends the subscriber’s CFB23forward-to number as the MSRN in the prn message.24
25
X.S0023
2-41
g. NOTE: From the GSM HLR and GMSC’s perspectives, the call is routed to a MSRN; they are1not aware that the call is being forwarded. Therefore, there may be billing issues associated2with this handling. Another drawback is that it is not possible to provide the GSM notification of3forwarding to the calling party functionality. It is also critical that the GMSC have controls built in4to limit the potential for call looping (e.g., if two dual-mode roaming subscribers have forwarded5their calls to each other).6
7h. The GSM HLR returns an sri message containing the CFB forward-to number as the MSRN to8
the GMSC.910
i. The GMSC establishes a call to the CFB forward-to number.1112
X.S0023
2-42
4.6.1.2.6.2 CFB invocation (Scenario 1b, “AbsentSubscriber method”)1
In this scenario, the busy condition is detected by the ANSI-41 serving system when the2RoutingRequest Invoke message is received, and the IIF returns an AbsentSubscriber error code to3the GSM HLR in the ProvideRoamingNumber Return Error message.4
i
h
g
GMSC HLR VMSC 2
a
b
c
d
e
GSM Home System
ANSI-41 Serving System
ROUTREQ
routreq [Busy]
GSM Gateway
PRN
SRI
sri [CFNRc #]
prn_RE [AbsentSubscriber]
f
forward call to CFNRc#
Subscriber is detected busy
incoming call
ANSI-41GSM
IIF
5Figure 41: CFB invocation (Scenario 1b, “AbsentSubscriber method”)6
7a-f. Same as Section 4.6.1.2.6.1, steps a-f.8
9g. The IIF determines that CFB is active for the subscriber. The IIF sends the AbsentSubscriber10
error code in a ProvideRoamingNumber Return Error message.1112
NOTE: This directs the GSM HLR to initiate CFNRc processing if this feature is active in the13subscriber’s profile. While this handling complies with the GSM MAP Version 2 standard and14avoids the potential problems of other approaches, it requires that the CFNRc feature be active15and does not allow different handling of busy versus not reachable conditions.16
17h. The GSM HLR returns an sri message, directing the GMSC to forward the call to the CFNRc18
forward-to number.1920
i. The GMSC forwards the call to the CFB forward-to number.2122
X.S0023
2-43
4.6.1.2.6.3 CFB invocation (Scenario 2, without OR)1
In this scenario, the busy condition is detected by the ANSI-41 serving system after the2RoutingRequest Invoke message is received and while attempting to complete the call to the TLDN,3and optimal routing is not invoked.4
5
n
h
i
j
k
l
m
g
GMSC HLR
a
b
c
d
e
GSM Home System
ROUTREQ [BillingID1]
routreq [TLDN]
GSM Gateway
PRN
SRI
sri [MSRN]
prn [MSRN]f
setup call to MSRN
REDREQ [Busy, BillingID1]
redreq [reject]
TRANUMREQ [Busy]
tranumreq [CFB #]
forward call to CFB #
Subscriber is detected busy
incoming call
VMSC 2
ANSI-41 Serving System
ANSI-41GSM
IIF
6Figure 42: CFB invocation (Scenario 2, without OR)7
a. The GSM GMSC receives an incoming call for the subscriber.89
b. The GMSC sends a SRI message to the HLR.1011
c. The HLR sends a PRN message to the current GSM serving system; i.e., the IIF.1213
d. The IIF sends a ROUTREQ message to the ANSI-41 serving system. Note that this message14shall contain the MSCID and PC_SSN parameters corresponding to the IIF. The serving system15may use this information to route any subsequent REDREQ message, as in step-j.16
17
X.S0023
2-44
e. The serving system determines that the subscriber is available; therefore, it returns a routreq1message, containing a routing number (called a temporary local directory number, or TLDN, in2ANSI-41) to the IIF.3
4f. The IIF responds to the GSM HLR with a prn message including the MSRN that it derives from5
the TLDN; i.e., if the received TLDN is not in international format, then the IIF converts the6TLDN into international format for use as the MSRN by adding country code digit(s) associated7with the country of the serving system.8
9g. The GSM HLR returns an sri message containing the MSRN to the GMSC.10
11h. The GMSC establishes a call to the MSRN.12
13i. The serving system determines that the subscriber is busy. Note: If call waiting (CW) is active,14
the serving system would normally invoke CW under these circumstances.1516
j. The serving system sends a REDREQ message to the IIF (e.g., using the routing information17provided in step-d), indicating that call redirection is requested due to a subscriber busy18condition.19
20k. Since the IIF is not able to redirect the call (i.e., optimal routing is not possible), it rejects the21
redirection request.2223
l. If the serving system is able to redirect the call, it sends a TRANUMREQ message to the IIF,24requesting the CFB forward-to number. Note that not all ANSI-41 systems have implemented25this redirection capability. Without this capability, the call shall fail, possibly with a tone or26announcement to the calling party.27
28m. The IIF determines that CFB is active for the subscriber. Therefore, the IIF responds with a29
tranumreq message including the subscriber’s CFB forward-to number.3031
n. The serving system forwards the call to the CFB forward-to number.324.6.1.2.6.4 CFB invocation (Scenario 2, with OR)33
In this scenario, the busy condition is detected by the ANSI-41 serving system after the34RoutingRequest Invoke message is received and while attempting to complete the call to the TLDN,35and optimal routing is invoked.36This scenario is covered in Section 4.7.1.37
4.6.1.3 Call forwarding no reply (CFNRy)38
The following scenarios illustrate the call forwarding no reply (CFNRy) information flows applicable39to ANSI-41 foreign mode operation.40
X.S0023
2-45
4.6.1.3.1 CFNRy registration1
See 4.6.1.1.1 for the CFNRy registration information flows applicable to ANSI-41 foreign mode2operation, since they are the same as those for CFU.334.6.1.3.2 CFNRy deregistration (erasure)4
See 4.6.1.1.2 for the CFNRy deregistration information flows applicable to ANSI-41 foreign mode5operation, since they are the same as those for CFU.364.6.1.3.3 CFNRy activation7
See 4.6.1.1.3 for the CFNRy activation information flows applicable to ANSI-41 foreign mode8operation, since they are the same as those for CFU. 394.6.1.3.4 CFNRy deactivation10
See 4.6.1.1.4 for the CFNRy deactivation information flows applicable to ANSI-41 foreign mode11operation, since they are the same as those for CFU. 3124.6.1.3.5 CFNRy invocation13
The following scenarios illustrate the CFNRy invocation information flows applicable to ANSI-4114foreign mode operation.15
3 The ANSI-136 serving system may not directly support CFNRy registration or activation, but onlysupport registration or activation of call forwarding no answer (CFNA). In this case, CFNA registration oractivation shall result in the registration or activation of both CFNRy and call forwarding not reachable(CFNRc).
X.S0023
2-46
4.6.1.3.5.1 CFNRy invocation (Scenario 1, without OR)1
In this scenario, the no reply condition is detected by the ANSI-41 serving system while attempting2to complete the call to the TLDN, and optimal routing is not invoked.3
n
h
i
j
k
l
m
g
GMSC HLR
a
b
c
d
e
GSM Home System
routreq [TLDN]
GSM Gateway
PRN
SRI
sri [MSRN]
prn [MSRN]f
setup call to MSRN
redreq [reject]
TRANUMREQ [No Answer]
tranumreq [CFNRy #]
forward call to CFNRy #
Subscriber does not answer
incoming call
REDREQ [No answer, BillingID1]
ROUTREQ [BillingID1]
VMSC 2
ANSI-41 Serving System
ANSI-41GSM
IIF
4Figure 43: CFNRy invocation (Scenario 1, without OR)5
6
a-h.Same as Section 4.6.1.2.6.3, steps a-h.78
i. The serving system determines that the subscriber does not answer the alert.910
j. The serving system sends a REDREQ message to the IIF (e.g., using the routing11information provided in step-d), indicating that call redirection is requested due to a subscriber12no answer condition.13
14
X.S0023
2-47
k. Since the IIF is not able to redirect the call (i.e., optimal routing is not possible), it rejects the1redirection request2
3l. If the serving system is able to redirect the call, it sends a TRANUMREQ message to the IIF,4
requesting the CFNA (i.e., GSM CFNRy) forward-to number. Note that not all ANSI-41 systems5have implemented this redirection capability. Without this capability, the call shall fail, possibly6with a tone or announcement to the calling party.7
8m. The IIF determines that CFNRy is active for the subscriber. Therefore, the IIF responds with a9
tranumreq message including the subscriber’s CFNRy forward-to number.1011
n. The serving system forwards the call to the CFNRy forward-to number.124.6.1.3.5.2. CFNRy invocation (Scenario 1, with OR)13
In this scenario, the no reply condition is detected by the ANSI-41 serving system while attempting14to complete the call to the TLDN, and optimal routing is invoked.15This scenario is addressed in Section 4.7.1.16
4.6.1.4 Call forwarding not reachable (CFNRc)17
The following scenarios illustrate the call forwarding not reachable (CFNRc) information flows18applicable to ANSI-41 foreign mode operation.19
4.6.1.4.1 CFNRc registration20
See 4.6.1.1.1 for the CFNRc registration information flows applicable to ANSI-41 foreign mode21operation.4224.6.1.4.2 CFNRc deregistration (erasure)23
See 4.6.1.1.2 for the CFNRc deregistration information flows applicable to ANSI-41 foreign mode24operation, since they are the same as those for CFU. 425
4.6.1.4.3 CFNRc activation26
See 4.6.1.1.3 for the CFNRc activation information flows applicable to ANSI-41 foreign mode27operation, since they are the same as those for CFU. 428
4.6.1.4.4 CFNRc deactivation29
See 4.6.1.1.4 for the CFNRc deactivation information flows applicable to ANSI-41 foreign mode30operation, since they are the same as those for CFU. 431
4.6.1.4.5 CFNRc invocation32
The following scenarios illustrate the CFNRc invocation information flows applicable to ANSI-4133foreign mode operation.34
35
4 The ANSI-136 serving system may not directly support CFNRc registration or activation,but only support registration or activation of call forwarding no answer (CFNA). In thiscase, CFNA registration or activation shall result in the registration or activation of bothCFNRc and CFNRy.
X.S0023
2-48
4.6.1.4.5.1 CFNRc invocation (Scenario 1)1
In this scenario, the not reachable condition is detected either by the IIF or by the ANSI-41 serving2system when the RoutingRequest Invoke message is received.3
4Figure 44: CFNRc invocation (Scenario 1)5
a. The GSM GMSC receives an incoming call for the subscriber.67
b. The GMSC sends a SRI message to the HLR.89
c. The HLR sends a PRN message to the current GSM serving system (i.e., the IIF).1011
d. If the IIF determines that the called subscriber is not reachable, it returns an absent12subscriber error, otherwise, the IIF sends a ROUTREQ message to the ANSI-41 serving13system.14
15e. The serving system determines that the subscriber is no reachable (e.g., does not respond to16
paging).1718
f. Therefore, the serving system returns a routreq message, containing the19AccessDeniedReason parameter set to the value No Page Response.20
21g. The IIF determines that CFNRc is active for the subscriber. The IIF sends the22
AbsentSubscriber error code in a ProvideRoamingNumber Return Error message.2324
h. The GSM HLR returns a sri message, directing the GMSC to forward the call to the CFNRc25forward-to number.26
27i. The GMSC forwards the call to the CFB forward-to number.28
X.S0023
2-49
4.6.1.4.5.2 CFNRc invocation (Scenario 2, without OR)1
In this scenario, the not reachable condition is detected by the ANSI-41 serving system after the2RoutingRequest Invoke message is received and while attempting to complete the call to the TLDN,3and optimal routing is not invoked.4
5Figure 45: CFNRc invocation (Scenario 2, without OR)6
7a-h. Same as Section 4.6.1.2.6.3, steps a-h.8
9i. The serving system determines that the mobile station does not respond to paging.10
11j. The serving system sends a REDREQ message to the IIF (e.g., using the routing information12
provided in step d), indicating that call redirection is requested due to a subscriber no page13response condition.14
15
X.S0023
2-50
k. Since the IIF is not able to redirect the call (i.e., optimal routing is not possible), it rejects the1redirection request.2
3
If the serving system is able to redirect the call, it sends a TRANUMREQ message to the4IIF, requesting the forward-to number appropriate for the no page response condition. Note5that not all ANSI-41 systems have implemented this redirection capability. Without this6capability, the call shall fail, possibly with a tone or announcement to the calling party.7
8l. The IIF determines that CFNRc is active for the subscriber. Therefore, the IIF responds with a9
tranumreq message including the subscriber’s CFNRc forward-to number.1011
m. The serving system forwards the call to the CFNRc forward-to number.124.6.1.4.5.3 CFNRc invocation (Scenario 2, with OR)13
In this scenario, the not reachable condition is detected by the ANSI-41 serving system after the14RoutingRequest Invoke message is received and while attempting to complete the call to the TLDN,15and optimal routing is invoked.16This scenario is addressed in Section 4.7.1.17
X.S0023
2-51
4.6.2 Call forwarding scenarios for GSM foreign mode1The scenarios in this section illustrate the call forwarding information flows applicable to an2ANSI-41native subscriber roaming in a GSM network; i.e., GSM foreign mode.3
4.6.2.1 Call forwarding unconditional (CFU)4
The following scenarios illustrate the call forwarding unconditional (CFU) information flows5applicable to GSM foreign mode operation.6
4.6.2.1.1 CFU registration7
This scenario illustrates the CFU registration information flows applicable to GSM foreign mode8operation.9
e
f
a
b
c
d
REG_SS
HLR VMSC 2
ANSI-41 Home System
GSM Serving System
FEATREQ [digits]
featreq [success]
MS
Subscriber
A_REG_SS
reg_ss
a_reg_ss
GSMANSI-41
IIF
10Figure 46: CFU registration11
12a. The GSM serving system receives an A_REG_SS message from the subscriber’s mobile13
station (MS), indicating that the subscriber wishes to change his CFU forward-to number.1415
b. The serving system sends a REG_SS message to the IIF, constructed based on the information16received in the A_REG_SS message.17
18c. The IIF translates the information received in the REG_SS message into a corresponding digit19
string (e.g., based on internal tables) and sends this string to the ANSI-41 HLR in a FEATREQ20message.21
22d. The HLR processes the request and returns a featreq message to the IIF, indicating operation23
success.2425
e. The IIF sends a reg_ss message to the serving system, indicating a successful feature control26request.27
28f. The serving system sends a registration response message to the subscriber.29
30
X.S0023
2-52
Note: The process of registering the call forward number may also result in activation of the service.1This is based on HLR (i.e., carrier) determined policy.24.6.2.1.2 CFU deregistration (erasure)3
This scenario illustrates the CFU deregistration information flows applicable to GSM foreign mode4operation.5
e
f
a
b
c
d
ERASE_SS
HLR VMSC 2
ANSI-41 Home System
GSM Serving System
FEATREQ [digits]
featreq [success]
MS
Subscriber
A_ERASE_SS
erase_ss
a_erase_ss
GSMANSI-41
IIF
6Figure 47: CFU deregistration (erasure)7
a. The GSM serving system receives an A_ERASE_SS message from the subscriber’s mobile8station (MS), indicating that the subscriber wishes to deregister the CFU service.9
10b. The serving system sends an ERASE_SS message to the IIF, constructed based on the11
information received in the A_ERASE_SS message.1213
c. The IIF translates the information received in the ERASE_SS message into a corresponding14digit string (e.g., based on internal tables) and sends this string to the ANSI-41 HLR in a15FEATREQ message.16
17d. The HLR processes the request and returns a featreq message to the IIF, indicating operation18
success.1920
e. The IIF sends an erase_ss message to the serving system, indicating a successful feature21control request.22
23f. The serving system sends a deregistration response message to the subscriber.24
25Note: The process of deregistering the call forward service also results in deactivation of the26service.27
X.S0023
2-53
4.6.2.1.3 CFU activation1
This scenario illustrates the CFU activation information flows applicable to GSM foreign mode2operation.3
e
f
a
b
c
d
ACT_SS
HLR VMSC 2
ANSI-41 Home System
GSM Serving System
FEATREQ [digits]
featreq [success]
MS
Subscriber
A_ACT_SS
act_ss
a_act_ss
GSMANSI-41
IIF
4Figure 48: CFU activation5
a. The GSM serving system receives an A_ACT_SS message from the subscriber’s mobile station6(MS), indicating that the subscriber wishes to activate the CFU service.7
8b. The serving system sends an ACT_SS message to the IIF, constructed based on the9
information received in the A_ACT_SS message.1011
c. The IIF translates the information received in the ACT_SS message into a corresponding digit12string (e.g., based on internal tables) and sends this string to the ANSI-41 HLR in a FEATREQ13message.14
15d. The HLR processes the request and returns a featreq message to the IIF, indicating operation16
success.1718
e. The IIF sends an act_ss message to the serving system, indicating a successful feature control19request.20
21f. The serving system sends an activation response message to the subscriber.22
X.S0023
2-54
4.6.2.1.4 CFU deactivation1
2This scenario illustrates the CFU deactivation information flows applicable to GSM foreign mode3operation.4
5
e
f
a
b
c
d
DEACT_SS
HLR VMSC 2
ANSI-41 Home System
GSM Serving System
FEATREQ [digits]
featreq [success]
MS
Subscriber
A_DEACT_SS
deact_ss
a_deact_ss
GSMANSI-41
IIF
6Figure 49: CFU deactivation7
8a. The GSM serving system receives an A_DEACT_SS message from the subscriber’s mobile9
station (MS), indicating that the subscriber wishes to deactivate the CFU service.1011
b. The serving system sends a DEACT_SS message to the IIF, constructed based on the12information received in the A_DEACT_SS message.13
14c. The IIF translates the information received in the DEACT_SS message into a corresponding15
digit string (e.g., based on internal tables) and sends this string to the ANSI-41 HLR in a16FEATREQ message.17
18d. The HLR processes the request and returns a featreq message to the IIF, indicating operation19
success.2021
e. The IIF sends a deact_ss message to the serving system, indicating a successful feature22control request.23
24f. The serving system sends a deactivation response message to the subscriber.25
X.S0023
2-55
4.6.2.1.5 CFU invocation1
This scenario illustrates the CFU invocation information flows applicable to GSM foreign mode2operation.3
4
d
c
GMSC HLR VMSC 2
a
bLOCREQ
locreq [CFU#]
forward call to CFU #
incoming call
ANSI-41 Home System
GSM Serving System
GSMANSI-41
IIF
ANSI-41 Originating MSC
5Figure 50: CFU invocation6
a. The ANSI-41 originating MSC (OMSC) receives an incoming call for the subscriber.78
b. The OMSC sends a LOCREQ message to the HLR.910
c. The HLR determines that the subscriber has CFU registered and active; therefore, the HLR11responds with the subscriber’s CFU forward-to number in the locreq message.12
13d. The OMSC forwards the call to the CFU forward-to number.14
X.S0023
2-56
4.6.2.2 Call forwarding busy (CFB)1
The following scenarios illustrate the call forwarding busy (CFB) information flows applicable to2GSM foreign mode operation.3Since the ANSI-41 HLR does not provide the CFB forward-to number to the serving system until the4feature is actually invoked—versus the GSM method, whereby the HLR provides the forward-to5number(s) to the serving system as part of the subscriber’s profile information at registration6time—the IIF shall use the ANSI-41 TransferToNumberRequest operation to obtain the CFB7forward-to number. This is illustrated in Figure 51.8
h
e
f
g
a
b
c
d
HLR VMSC 2
ANSI-41 Home System
GSM Serving System
MS
Subscriber
GSMANSI-41
IIF
ISD
isd
[TCAP End]
TRANUMREQ
tranumreq
Normal registration process
TRANUMREQ
tranumreq
9Figure 51: Obtaining forward-to numbers10
a. The subscriber registers on a GSM serving system using the normal registration signaling11process.12
13b. If the subscriber’s ANSI-41 profile indicates that CFB is authorized and active, and the IIF14
determines that it does may not have the current CFB forward-to number, then the IIF sends a15TRANUMREQ message to the HLR requesting the CFB forward-to number.16
17c. The HLR responds with the CFB forward-to number in the tranumreq message.18
19d. If the subscriber’s ANSI-41 profile indicates that CFNA is authorized and active, and the IIF20
determines that it does may not have the current CFNA forward-to number, then the IIF sends a21TRANUMREQ message to the HLR requesting the CFNA forward-to number.22
23e. The HLR responds with the CFNA forward-to number in the tranumreq message.24
25f-h. If the CFB forward-to number or CFNA forward-to number, or both numbers do not26
correspond with the numbers previously provided to the GSM serving system, then the IIF27sends the modified information to the GSM serving system using the InsertSubscriberData28
X.S0023
2-57
operation. The CFNA forward-to number shall be populated as both the CFNRc and CFNRy1forward-to numbers.2
4.6.2.2.1 CFB registration3
This scenario illustrates the CFB registration information flows applicable to GSM foreign mode4operation.5
m
h
e
f
g
a
b
c
d
REG_SS
HLR VMSC 2
ANSI-41 Home System
GSM Serving System
FEATREQ [digits]
featreq [success]
MS
Subscriber
A_REG_SS
reg_ss
a_reg_ss
GSMANSI-41
IIF
j
i
kISD
isd
[TCAP End]
TRANUMREQ
tranumreq
QUALDIR
qualdir
l
6Figure 52: CFB registration7
a. The GSM serving system receives an A_REG_SS message from the subscriber’s mobile8station (MS), indicating that the subscriber wishes to change his call forwarding number.9
10b. The serving system sends a REG_SS message to the IIF, constructed based on the information11
received in the A_REG_SS message.1213
c. The IIF translates the information received in the REG_SS message into a corresponding digit14string (e.g., based on internal tables) and sends this string to the ANSI-41 HLR in a FEATREQ15message.16
17d. The HLR processes the request and returns a featreq message to the IIF, indicating operation18
success.19
X.S0023
2-58
1e. The IIF sends a reg_ss message to the serving system, indicating a successful feature control2
request.34
f. The serving system sends a registration response message to the subscriber.56
g-h. If the subscriber’s ANSI-41 profile changes as a result of the operation (e.g., the service was7previously authorized, but not activated), the HLR sends a QUALDIR message to the IIF,8containing the new profile information.9
10i. If the IIF determines that the subscriber’s call forwarding number may have changed, it sends a11
TRANUMREQ message to the HLR to request the new number.1213
j. The HLR responds with the subscriber’s call forwarding number in the tranumreq message.1415
k-m. If the subscriber’s GSM profile has changed as a result of these operations, then the IIF16sends the modified profile information to the serving system via an InsertSubscriberData17message exchange.18
19Note: The process of registering the call forwarding number may also result in activation of the20service. This is based on HLR (i.e., carrier) determined policy.21
X.S0023
2-59
4.6.2.2.2 CFB deregistration (erasure)1
This scenario illustrates the CFB deregistration information flows applicable to GSM foreign mode2operation.3
h
e
f
g
a
b
c
d
HLR VMSC 2
ANSI-41 Home System
GSM Serving System
MS
Subscriber
GSMANSI-41
IIF
j
i
k
ERASE_SS
FEATREQ [digits]
featreq [success]
A_ERASE_SS
erase_ss
a_erase_ss
ISD
isd
[TCAP End]
QUALDIR
qualdir
4Figure 53: CFB deregistration (erasure)5
6a. The GSM serving system receives an A_ERASE_SS message from the subscriber’s mobile7
station (MS), indicating that the subscriber wishes to deregister the call forward service.89
b. The serving system sends an ERASE_SS message to the IIF, constructed based on the10information received in the A_ERASE_SS message.11
12c. The IIF translates the information received in the ERASE_SS message into a corresponding13
digit string (e.g., based on internal tables) and sends this string to the ANSI-41 HLR in a14FEATREQ message.15
16d. The HLR processes the request and returns a featreq message to the IIF, indicating operation17
success.1819
e. The IIF sends an erase_ss message to the serving system, indicating a successful feature20control request.21
22f. The serving system sends a deregistration response message to the subscriber.23
X.S0023
2-60
1g-h. If the subscriber’s ANSI-41 profile changes as a result of the operation (e.g., the service was2
previously authorized and activated), the HLR sends a QUALDIR message to the IIF, containing3the new profile information.4
5i-k. If the subscriber’s GSM profile has changed as a result of these operations, then the IIF6
sends the modified profile information to the serving system via an InsertSubscriberData7message exchange.8
9Note: The process of deregistering the call forwarding service also results in deactivation of the10service.11
12
X.S0023
2-61
4.6.2.2.3 CFB activation1
This scenario illustrates the CFB activation information flows applicable to GSM foreign mode2operation.3
h
e
f
g
a
b
c
d
j
i
k
ACT_SS
FEATREQ [digits]
featreq [success]
A_ACT_SS
act_ss
a_act_ss
ISD
isd
[TCAP End]
QUALDIR
qualdir
HLR VMSC 2
ANSI-41 Home System
GSM Serving System
MS
Subscriber
GSMANSI-41
IIF
4Figure 54: CFB activation5
6a. The GSM serving system receives an A_ACT_SS message from the subscriber’s mobile station7
(MS), indicating that the subscriber wishes to activate the call forward service.89
b. The serving system sends an ACT_SS message to the IIF, constructed based on the10information received in the A_ACT_SS message.11
12c. The IIF translates the information received in the ACT_SS message into a corresponding digit13
string (e.g., based on internal tables) and sends this string to the ANSI-41 HLR in a FEATREQ14message.15
16d. The HLR processes the request and returns a featreq message to the IIF, indicating operation17
success.1819
e. The IIF sends an act_ss message to the serving system, indicating a successful feature control20request.21
22f. The serving system sends an activation response message to the subscriber.23
X.S0023
2-62
1g-h. If the subscriber’s ANSI-41 profile changes as a result of the operation (e.g., the service was2
previously authorized but not active), the HLR sends a QUALDIR message to the IIF, containing3the new profile information.4
5i-k. If the subscriber’s GSM profile has changed as a result of these operations, then the IIF6
sends the modified profile information to the serving system via an InsertSubscriberData7message exchange.8
X.S0023
2-63
4.6.2.2.4 CFB deactivation1
This scenario illustrates the CFB deactivation information flows applicable to GSM foreign mode2operation.3
h
e
f
g
a
b
c
d
j
i
k
DEACT_SS
FEATREQ [digits]
featreq [success]
A_DEACT_SS
deact_ss
a_deact_ss
ISD
isd
[TCAP End]
QUALDIR
qualdir
HLR VMSC 2
ANSI-41 Home System
GSM Serving System
MS
Subscriber
GSMANSI-41
IIF
4Figure 55: CFB deactivation5
6
a. The GSM serving system receives an A_DEACT_SS message from the subscriber’s mobile7station (MS), indicating that the subscriber wishes to deactivate the call forward service.8
9b. The serving system sends a DEACT_SS message to the IIF, constructed based on the10
information received in the A_DEACT_SS message.1112
c. The IIF translates the information received in the DEACT_SS message into a corresponding13digit string (e.g., based on internal tables) and sends this string to the ANSI-41 HLR in a14FEATREQ message.15
16d. The HLR processes the request and returns a featreq message to the IIF, indicating operation17
success.1819
e. The IIF sends a deact_ss message to the serving system, indicating a successful feature20control request.21
22f. The serving system sends a deactivation response message to the subscriber.23
24
X.S0023
2-64
g-h. If the subscriber’s ANSI-41 profile changes as a result of the operation (e.g., the service was1previously authorized and active), the HLR sends a QUALDIR message to the IIF, containing2the new profile information.3
4i-k. If the subscriber’s GSM profile has changed as a result of these operations, then the IIF5
sends the modified profile information to the serving system via an InsertSubscriberData6message exchange.7
X.S0023
2-65
4.6.2.2.5 CFB invocation1
The following scenarios illustrate the CFB invocation information flows applicable to GSM foreign2mode operation.3
4.6.2.2.5.1 CFB invocation (without OR)4
In this scenario, the busy condition is detected by the GSM serving system while attempting to5complete the call to the TLDN, and optimal routing is not invoked.6
OMSC HLR VMSC 2
ANSI-41 Originating MSC
ANSI-41 Home System
GSM Serving System
GSMANSI-41
IIF
h
i
j
g
a
b
c
d
e
PRN
prn [MSRN]
ROUTREQ
LOCREQ
locreq [TLDN]
routreq [TLDN]f
setup call to TLDN
forward call to CFB #
Subscriber is detected busy
incoming call
7Figure 56: CFB invocation (without OR)8
a. The ANSI-41 originating MSC (OMSC) receives an incoming call for the subscriber.910
b. The OMSC sends a LOCREQ message to the HLR.1112
c. The HLR sends a ROUTREQ message to the current serving system; i.e., the IIF.1314
d. The IIF sends a PRN message to the GSM serving system.1516
e. The serving system returns a prn message, containing a routing number (called a mobile station17roaming number, or MSRN, in GSM) to the IIF.18
19f. The IIF responds to the HLR with a routreq message including the TLDN that it derives from the20
MSRN. Note that the TLDN is typically in international format.2122
g. The HLR returns a locreq message containing the TLDN to the OMSC.2324
h. The OMSC establishes a call to the TLDN.25
X.S0023
2-66
1i-j. The serving system determines that the subscriber is busy and forwards the call to the CFB2
forward-to number.34.6.2.2.5.2 CFB invocation (with OR)4
In this scenario, the busy condition is detected by the GSM serving system while attempting to5complete the call to the TLDN, and optimal routing is invoked.6This scenario is addressed in Section 4.7.2.74.6.2.3 Call forwarding no answer (CFNA)8
The following scenarios illustrate the call forwarding no answer (CFNA) information flows applicable9to GSM foreign mode operation.10Since the ANSI-41 HLR does not provide the CFNA forward-to number to the serving system until11the feature is actually invoked—versus the GSM method, whereby the HLR provides the forward-to12number(s) to the serving system as part of the subscriber’s profile information at registration13time—the IIF shall use the ANSI-41 TransferToNumberRequest operation to obtain the CFNA14forward-to number. This is illustrated in Figure 51 and described in Section 4.6.2.2.15Note that ANSI-41, unlike GSM, does not distinguish the “not reachable” condition from the “no16reply” condition. Therefore, if ANSI-41 CFNA is activated, then both of the GSM CFNRy and CFNRc17services shall be considered activated.184.6.2.3.1 CFNA registration19
See 4.6.2.2.1 for the CFNA registration information flows applicable to GSM foreign mode20operation, since they are the same as those for CFB. Both CFNRy and CFNRc shall be registered21in the IIF and GSM VLR.224.6.2.3.2 CFNA deregistration (erasure)23
See 4.6.2.2.2 for the CFNA deregistration information flows applicable to GSM foreign mode24operation, since they are the same as those for CFB. Both CFNRy and CFNRc shall be25deregistered in the IIF and GSM VLR.264.6.2.3.3 CFNA activation27
See 4.6.2.2.3 for the CFNA activation information flows applicable to GSM foreign mode operation,28since they are the same as those for CFB. Both CFNRy and CFNRc shall be activated in the IIF and29GSM VLR.304.6.2.3.4 CFNA deactivation31
See 4.6.2.2.4 for the CFNA deactivation information flows applicable to GSM foreign mode32operation, since they are the same as those for CFB. Both CFNRy and CFNRc shall be deactivated33in the IIF and GSM VLR.34
X.S0023
2-67
4.6.2.3.5 CFNA invocation1
The following scenarios illustrate the CFNA invocation information flows applicable to GSM foreign2mode operation.34.6.2.3.5.1 CFNA invocation (Scenario 1, without OR)4
In this scenario, the no reply condition is detected by the GSM serving system while attempting to5complete the call to the TLDN, and optimal routing is not invoked.6
OMSC HLR VMSC 2
ANSI-41 Originating MSC
ANSI-41 Home System
GSM Serving System
GSMANSI-41
IIF
h
i
j
g
a
b
c
d
e
PRN
prn [MSRN]
ROUTREQ
LOCREQ
locreq [TLDN]
routreq [TLDN]f
setup call to TLDN
forward call to CFNRy #
Subscriber does not answer
incoming call
7Figure 57: CFNA invocation (Scenario 1, without OR)8
a-h. Same as Section 4.6.2.2.5.1, steps a-h.910
i-j. The serving system determines that the subscriber does not answer the alert and forwards11the call to the CFNRy forward-to number.12
134.6.2.3.5.2 CFNA invocation (Scenario 1, with OR)14
In this scenario, the no reply condition is detected by the GSM serving system while attempting to15complete the call to the TLDN, and optimal routing is invoked.16
17This scenario is addressed in Section 4.7.2.18
X.S0023
2-68
4.7 Optimal Routing for Late Call Forwarding1
The following scenarios cover the interoperability to support Optimal Routing for Late Call2Forwarding. The signaling is based on ANSI-41 Rev. D [2] and GSM 9.02 [4].3From GSM 02.79 [22] and GSM 03.79 [32], Late Call Forwarding is Call Forwarding performed after4the call has been extended to the Visited PLMN (VPLMN) of the forwarding subscriber (i.e.,5Conditional Call Forwarding on Busy, Conditional Call Forwarding on No Reply, and Conditional6Call Forwarding on Not Reachable detected in the VPLMN of the forwarding subscriber). Late Call7Forwarding may be invoked in the Interrogating PLMN (IPLMN) or in the VPLMN of the forwarding8subscriber.9Assumptions:10
1) The Subscriber has forwarding enabled.112) Optimal Routing is enabled.12
The following scenarios address the case where the forwarding attempt is done by the IPLMN.13
X.S0023
2-69
4.7.1 ANSI-41 Foreign Mode1
4.7.1.1 ANSI-41 Foreign Mode - Success condition2
Scenario: GSM Subscriber A makes a call origination attempt at GMSC-A to a GSM Subscriber B3who is roaming and registered in an ANSI-41 network at MSC-B. Subscriber B has call forwarding4set to an address at MSC-C.5
GSM(GMSC-A)
GSM(B’s HLR) IIF
ANSI-41(MSC-B/VLR) (MSC-C)
Establish Connection Attempt
Connection Release
Call Forward Setup
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
Call Origination
Send Routing Info
[ORphase,GMSC#,CR#,ORinterrog(Opt.)]
Provide Roaming Number
[GMSC#,CR#,ORinterrog(Opt.)]
ROUTEREQ [billing ID]
Routereq [TLDN]
Provide Roaming Number Ack[MSRN]
Send Routing InfoAck [MSRN, FIR]
Resume Call Handling [CR#,reason, forwarding#]
REDREQ [REDREASON, billing ID]
Send Routing Info [forwarding reason]
Send Routing InfoAck [forwarding #]
Resume Call HandlingAck
redreq
67
Figure 58: Optimal Routing with Late Call Forwarding (ANSI-41 Foreign Mode) Success Case89
a. GSM GMSC-A receives a call origination stimulus from Subscriber A.1011
b. If GMSC-A recognizes subscriber B's address as belonging to a GSM PLMN, it checks the12identity of HPLMN-B and shall follow the following procedures:13
14(i) If GMSC-A is in the same PLMN as the HLR-B, GMSC-A sends a request for routing15information to Subscriber B's HLR. This GSM-SRI request contains:16
17- an indication of the phase of optimal routing supported by the GMSC-A;18
19- the E-164 address of GMSC-A;20
21- the Call Reference Number.22
23
X.S0023
2-70
(ii) If GMSC-A is in a different PLMN from HLR-B, it sends a request for routing information to1Subscriber B's HLR. This GSM-SRI request contains all parameters as in item (i) above as well2as an indication that it is an optimal routing inquiry (OR interrogation indicator).3
45
c. Subscriber B's GSM HLR determines that Subscriber B is roaming at MSC-B and sends a6GSM-Provide Roaming Number message, which also contains the GMSC address, the Call7Reference Number and the OR interrogation indicator if it was received in the GSM-SRI to an8IIF acting on behalf of MSC-B to get a roaming number. The E-164 address of GMSC-A shall be9provided in the message, as specified in GSM 03.79.10
11d. The IIF relays this request to the ANSI-41 MSC/VLR-B by sending an ANSI-41-Routing Request12
message. The originating address in this message is provided as a routing address back to the13IIF.14
15e. The ANSI-41 MSC/VLR-B acknowledges the ANSI-41-Routing Request message with the16
Temporary Local Directory Number (TLDN).1718
f. Upon receipt of the ANSI-41-Routing Request message, the IIF sends an MSRN to Subscriber19B's GSM HLR in the GSM-Provide Roaming Number Acknowledgment message.20
21g. Subscriber B's GSM HLR relays this information to GMSC-A using the GSM-Send Routing22
Information Acknowledgment message. This message includes MSRN and optionally a23ForwardedInterrogationRequired (FIR) parameter, which indicates whether the GMSC-A shall24interrogate the HLR for routing information for late call forwarding.25
26h. GMSC-A starts a call setup procedure using the MSRN (TLDN) as Subscriber B's called27
address at ANSI-41 MSC/VLR-B).2829
i. The incoming call at ANSI-41 MSC/VLR-B can not be terminated because of reasons such as30No Answer, No Page Response, or Unavailable. An ANSI-41-Redirection Request message31with a RedirectionReason parameter is then sent to the IIF based on the originating address32received in the ANSI-41-Route Request message at step d.33
34j. The IIF sends GSM-Resume Call Handling message to GMSC-A based on the GMSC-A35
address received in the GSM-Provide Roaming Number. Note that the GSM-Resume Call36Handling includes the same Call Reference Number received in the GSM-Provide Roaming37Number, the cause for termination failure (forwarding reason) and the forwarding number at38MSC-C plus all necessary parameters required for call forwarding.39
40k. If the ForwardedInterrogationRequired parameter was received from Subscriber B's GSM HLR41
in the GSM-Send Routing Information Acknowledgement message at step g, , GMSC-A sends a42GSM-Send Routing Information message to Subscriber B's GSM HLR requesting it to send a43call forwarding information.44
45Otherwise, it is assumed that all forwarding information is ready available at GMSC-A and an46acknowledgment of the GSM-Resume Call Handling message is sent to the IIF (step m).47
48l. If a corresponding forwarded-to number is available at subscriber B's GSM HLR, GMSC-A49
receives a GSM-Send Routing Information Acknowledge message with the necessary50forwarding information.51
52
X.S0023
2-71
In case of an error, a GSM-Send Routing Information Error message is sent to GMSC-A and1GMSC-A uses the forwarding information from step j.2
3m. GMSC-A sends an acknowledgment of the GSM-Resume Call Handling message.4
5n. Upon receipt of GSM-Resume Call Handling Acknowledgment message, the IIF acknowledges6
the ANSI-41-Redirection Request message.78
In case of an error, the IIF rejects the redirection request and the ANSI-MSC-B initiates a call9forwarding procedure extend the call to MSC-C. See Section 6.2.10
11o. If step n is successful, GMSC-A releases all circuit-associated resources specific to ANSI-4112
MSC/VLR-B.1314
p. GMSC-A starts a call setup procedure using the call forwarded-to number as Subscriber B’s15address at ANSI-41 MSC-C.16
17
X.S0023
2-72
4.7.1.2 ANSI-41 Foreign Mode - Failure condition1
Scenario: GSM Subscriber A makes a call origination attempt at GMSC-A to GSM Subscriber B2roaming and registered in an ANSI-41 network at MSC-B. Subscriber B has call forwarding set to an3address at MSC-C. Optimal Routing fails at IPLMN.4
GSM(GMSC-A)
GSM(B’s HLR) IIF
ANSI-41(MSC-B/VLR) (MSC-C)
Establish Connection Attempt
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
Call Origination
Send Routing Info[ORphase,GMSC#, CR#,ORinterrog(opt.)]
Provide Roaming Number[GMSC#,CR#,ORinterrog(opt.)] ROUTEREQ
Routereq [TLDN]
Provide Roaming Number Ack[MSRN]
Send Routing InfoAck [MSRN, FIR]
Resume Call Handling [CR#,reason, forwarding #]
REDREQ [REDREASON]
Send Routing Info [forwarding reason]
Send Routing InfoAck [forwarding #]
Resume Call Handling Error
redreq (reject)
q qForward Call
TRANUMREQ [REDREASON]
tranumreq [TERMLIST, REDIND]
56
Figure 59: Optimal Routing with Late Call Forwarding (ANSI-41 Foreign Mode) Failure Case7a.-l.These steps are the same as the success case.8
9m. If GMSC-A determines that it cannot forward the call via an optimal route, it returns a Resume10
Call Handling error to the IIF.1112
n. The redirection request at step i. is rejected.1314
o. The ANSI-41 MSC/VLR-B sends an ANSI-41 TransferToNumberRequest message to the IIF15with the RedirectionReason parameter.16
17p. The IIF returns the ANSI-41 TransferToNumberResponse message to the ANSI-41 MSC/VLR-B18
with the forward-to number in the TerminationList parameter along with an indication of the19reason (DMH_RedirectionIndicator) for extending the incoming call.20
21q. The ANSI-41 MSC/VLR-B forwards the incoming call to MSC-C.22
X.S0023
2-73
4.7.2 GSM Foreign Mode1
4.7.2.1 GSM Foreign Mode - Success Case2
Scenario: ANSI-41 Subscriber A makes a call origination attempt at ANSI-41 MSC-A to ANSI-413Subscriber B roaming and registered in a GSM network at MSC-B. Subscriber B has call forwarding4set to an address at MSC-C. Subscriber B is not IMSI detached.5
ANSI-41(MSC-A)
ANSI-41(B’s HLR) IIF
GSM(VLR/MSC-B) (MSC-C)
Establish Connection Attempt
Connection Release
Call Forward Setup
Call Origination
LOCREQ
ROUTEREQ
Provide Roaming Number[GMSC#,CR#]
Provide Roaming NumberAck [MSRN]
Routereq [TLDN]
Locreq [TLDN]
Resume Call Handling [CR#,reason]
tranumreq
Resume Call HandlingAck
REDREQ [REDREASON]
redreq
TRANUMREQ [REDREASON]
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
67
Figure 60: Optimal Routing with Late Call Forwarding (GSM Foreign Mode) Success Case8a. ANSI-41 MSC-A receives a call origination stimulus from Subscriber A.9
10b. The ANSI-41 MSC-A sends an ANSI-41-Location Request message for routing information to11
Subscriber B's ANSI-41 HLR with the MSCID address of the originating MSC (ANSI-41 MSC-12A).13
14c. Subscriber B's ANSI-41 HLR determines that Subscriber B is roaming at MSC-B and sends a15
ANSI-41-Routing Request message number with the MSCID address of the ANSI-41 MSC-A16received in step b. to an IIF acting on behalf of MSC-B to get a roaming number.17
18d. The IIF relays this request to GSM MSC/VLR-B by sending a GSM-Provide Roaming Number19
message. The IIF generates two parameters: the Call Reference number (for the VLR/MSC-B20to use in the GSM-RCH) and the GMSC address set to the IIF address, to indicate that the IIF is21capable of supporting optimal routing for late call forwarding.22
23e. GSM MSC/VLR-B acknowledges the GSM - Provide Roaming Number message with the24
Mobile Subscriber Roaming Number (MSRN).25
X.S0023
2-74
1f. Upon receipt of this message, the IIF sends the TLDN to Subscriber B's ANSI-41 HLR in the2
ANSI-41-Routing Request message.34
g. Subscriber B's ANSI-41 HLR relays this information to ANSI-41 MSC-A via the ANSI-41-5Location Request (Acknowledgment) message.6
7h. ANSI-41 MSC starts a call setup procedure using TLDN (MSRN) as Subscriber B's called8
address at GSM MSC/VLR-B. The incoming call can not be terminated at GSM MSC/VLR-B9because of reasons such as Busy, Not Reachable, or No Reply.10
11i. Since the GMSC address and the Call Reference Number parameters were present in the12
GSM-Provide Roaming Number message the GSM MSC-B sends a GSM-Resume Call13Handling message to the IIF with the received Call Reference number and all necessary14information required for call forwarding.15
16If optimal routing is not supported the call is forwarded by GSM MSC-B using the forwarding17information available.18
19j. When optimal routing is supported and the IIF receives the GSM-Resume Call Handling20
message, the IIF sends an ANSI-41-Redirecion Request message with the Redirection Reason21to the ANSI-41 MSC-A supporting subscriber A's call origination attempt.22
23k. The ANSI-41 MSC-A passes this Redirection Reason to the Subscriber B's ANSI-41 HLR in the24
ANSI-41-Transfer To Number message to get call forwarding number information.2526
l. Based on the Redirection Reason, the ANSI-41 HLR returns the corresponding forwarded-to27number to ANSI-41 MSC/VLR-A.28
29m. If ANSI-41 MSC-A received forwarded-to number from ANSI-41 HLR, it sends30
ANSI-41-Redirection Request (Acknowledgment) message to the IIF.3132
In case of an error, ANSI-41 MSC-A rejects the redirection request. The IIF then returns a33GSM-Resume Call Handling Error message to GSM MSC-B, which then attempts to forward the34call to MSC-C using the forwarding information available.35
36n. Upon receiving the ANSI-41-Redirection Request (Acknowledgment) in step m., the IIF sends a37
GSM-Resume Call Handling Acknowledgment message to GSM MSC-B.3839
o. The ANSI-41 MSC-A releases all circuit-associated resources specific to GSM MSC/VLR-B.4041
p. The ANSI-41 MSC-A starts a call setup procedure using the call forwarded-to number as42Subscriber B's address at MSC-C.43
X.S0023
2-75
4.7.2.2 GSM Foreign Mode - Failure case1
Scenario: ANSI-41 Subscriber A makes a call origination attempt at ANSI-41 MSC-A to ANSI-412Subscriber B roaming and registered in a GSM network at MSC-B. Subscriber B has call forwarding3set to an address at MSC-C. Optimal Routing fails at IPLMN. Subscriber B is not IMSI detached.4
5ANSI-41(MSC-A)
ANSI-41(B’s HLR) IIF
GSM(VLR/MSC-B) (MSC-C)
Establish Connection Attempt
Forward Call
Call Origination
LOCREQ
ROUTEREQ
Provide Roaming Number [GMSC#,CR#]
Provide Roaming NumberAck [MSRN]
Routereq [TLDN]
Locreq [TLDN]
Resume Call Handling [CR#,reason]
tranumreq
Resume Call Handling Error
REDREQ [REDREASON]
redreq (reject)
TRANUMREQ [REDREASON]
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
67
Figure 61: Optimal Routing with Late Call Forwarding (GSM Foreign Mode) Failure Case8a.-l.These steps are the same as the Success Case.9
10m. The redirection request at step j. is rejected.11
12n. The IIF sends a GSM-Resume Call Handling Error message to GSM MSC-B.13
14o. The GSM MSC-B forwards the incoming call to MSC-C.15
X.S0023
2-76
4.8 Call Waiting1
This section depicts the interactions between network entities in various situations related to GSM2and ANSI-41 foreign mode operation and Call Waiting (CW).3
4.8.1 Call Waiting Activation4
4.8.1.1 ANSI-41 Foreign Mode Successful Call Waiting Activation5
This scenario describes a successful call waiting activation by a native GSM subscriber roaming in6an ANSI-41 network.7
8Figure 62: ANSI-41 Foreign Mode Call Waiting Activation9
a. The subscriber requests activation of call waiting. The MS converts the user-entered MMI/menu10selections to feature codes. (e.g. *FC). The MS sends this feature code string to the Serving11MSC. During analysis of the digit string, the Serving MSC detects a feature code string.12
b. The digit string is included in a FEATREQ and sent from the Serving MSC to the IIF emulating13the HLR associated with the MS.14
X.S0023
2-77
c. The IIF determines the digit string pertains to the activation of call waiting and then sends an1Activate SS message to the HLR to request activation of call waiting. 52
d. The HLR returns an Activate SS Ack message to the IIF indicating a successful activation of call3waiting.4
e. The IIF sends a featreq to the Serving MSC containing the feature request confirmation5indication.6
f. When the featreq is received from the IIF, the Serving MSC provides treatment to the served7MS based on the information contained in the response. In this case, the treatment is to apply8feature confirmation.9
g. The Serving MSC releases the call.10h. Because the request resulted in a change to the subscriber’s service profile (i.e., the call waiting11
feature was activated), the HLR reports the change by sending an Insert Subscriber Data12message to the IIF emulating the Serving MSC/VLR.13
i. The IIF returns an Insert Subscriber Data Ack message to the HLR.14j. The IIF sends a QUALDIR message to the Serving MSC/VLR.15k. The Serving MSC/VLR returns a qualdir to the IIF.16
5 Most likely, the GSM 02.30 standardized MMI would be mapped to the equivalent GSMfunctional message.
X.S0023
2-78
4.8.1.2 ANSI-41 Foreign Mode Unsuccessful Call Waiting Activation1
The following scenario describes an unsuccessful call waiting activation by a native GSM subscriber2roaming in an ANSI-41 network.3
4
5Figure 63: ANSI-41 Foreign Mode Unsuccessful Call Waiting Activation6
a. The subscriber requests activation of call waiting. The MS converts the user-entered MMI/menu7selections to feature codes. (e.g. *FC). The MS sends this feature code string to the Serving8MSC. During analysis of the digit string, the Serving MSC detects a feature code string.9
b. The digit string is included in a FEATREQ and sent from the Serving MSC to the IIF emulating10the HLR associated with the MS.11
c. The IIF determines the digit string pertains to the activation of call waiting and then sends an12Activate SS message to the HLR to request activation of call waiting. 613
d. The HLR returns an Activate SS Ack message to the IIF indicating an unsuccessful activation of14call waiting.15
e. The IIF sends a featreq to the Serving MSC containing a Feature Result parameter set to16“Unsuccessful”. In addition, it may include an AnnouncementList code that corresponds to the17User error parameter included in the Activate SS Ack message sent by the GSM HLR.18
f. When the featreq is received from the IIF, the Serving MSC provides treatment to the served19MS based on the information contained in the response.20
g. The Serving MSC sends a Release message to the MS.2122
6 Most likely, the GSM 02.30 standardized MMI would be mapped to the equivalent GSMfunctional message.
X.S0023
2-79
4.8.1.3 GSM Foreign Mode Feature Activation1
This scenario describes a successful call waiting activation by a native ANSI-136 subscriber2roaming in a GSM network.3
4Figure 64: GSM Foreign Mode Call Waiting Activation5
a. The subscriber requests activation of call waiting. The MS interprets the user-entered6MMI/menu selections. The MS sends a request for activation of call waiting (by issuing an7Activate SS operation).8
b. The Serving GSM MSC sends an Activate SS message to the IIF emulating the HLR9associated with the subscriber. The message specifies the call waiting supplementary10service for the activation being requested.11
c. The IIF converts the call waiting Activate SS message to a particular feature code (e.g.12*FC). The IIF includes this feature code (including *) in the Digits (Dialed) parameter of a13FEATREQ message and sends the message to the subscriber’s HLR.14
d. The HLR returns a featreq message to the IIF indicating a successful call waiting activation.15e. The IIF returns an Activate SS Ack message back to the Serving GSM MSC. Any16
parameters the HLR may have included that provide instructions for treatment towards the17user (such as AnnouncementList) shall be ignored by the IIF and not mapped into the18message sent to the Serving GSM MSC.19
f. When the Activate SS Ack message is received from the IIF, the Serving GSM MSC sends20a message to the MS to indicate that the call waiting activation had been successful.21
X.S0023
2-80
g. Because the request resulted in a change to the subscriber’s service profile (i.e., the call1waiting feature was activated), the HLR reports the change by sending a QUALDIR2message to the IIF emulating the Serving GSM MSC/VLR.3
h. The IIF sends an Insert Subscriber Data message to the Serving GSM MSC/VLR.4i. The Serving GSM MSC/VLR returns an Insert Subscriber Data Ack to the IIF.5j. The IIF returns a qualdir message to the HLR.6
Note that the GSM foreign mode unsuccessful call waiting activation case parallels the ANSI-417foreign mode unsuccessful call waiting activation case shown in the previous section.8
X.S0023
2-81
4.8.2 Call Waiting Deactivation1
4.8.2.1 ANSI-41 Foreign Mode Call Waiting Deactivation2
This scenario describes a successful call waiting deactivation by a native GSM subscriber roaming3in an ANSI-41 network.4
5
6Figure 65: ANSI-41 Foreign Mode Call Waiting Deactivation7
a. The subscriber selects a menu entry in order to deactivate call waiting. The MS converts the8user-entered MMI/menu selections to feature codes. (e.g. *FC0). The MS sends this digit string9towards the network. The digit string is received by the Serving MSC. During analysis of the10digit string, the Serving MSC detects a feature code string.11
b. The dialed digits are included in a FEATREQ and sent from the Serving MSC to the IIF12emulating the HLR associated with the MS.13
X.S0023
2-82
c. The IIF determines the digit string pertains to the deactivation of call waiting and then sends a1Deactivate SS message to the HLR to request deactivation of call waiting. 72
d. The HLR returns a Deactivate SS Ack message to the IIF indicating a successful deactivation of3call waiting.4
e. The IIF sends a featreq to the Serving MSC containing the feature request confirmation5indication.6
f. When the featreq is received from the IIF, the Serving MSC provides treatment to the served7MS based on the information contained in the response. In this case, the treatment is to apply8feature confirmation.9
g. The Serving MSC releases the call.10h. Because the request resulted in a change to the subscriber’s service profile (i.e., the call waiting11
feature was deactivated), the HLR reports the change by sending an Insert Subscriber Data12message to the IIF emulating the Serving MSC/VLR.13
i. The IIF returns an Insert Subscriber Data Ack message to the HLR.14j. The IIF sends a QUALDIR message to the Serving MSC/VLR.15k. The Serving MSC/VLR returns a qualdir to the IIF.16
7 Most likely, the GSM 02.30 standardized MMI would be mapped to the equivalent GSMfunctional message.
X.S0023
2-83
4.8.2.2 GSM Foreign Mode Feature Deactivation1
This scenario describes a successful call waiting deactivation by a native ANSI-41subscriber2roaming in a GSM network.3
4
5Figure 66: GSM Foreign Mode Call Waiting Deactivation6
a. The subscriber requests activation of call waiting. The MS associates the MMI/menu selection7provided by the subscriber with a request to deactivate call waiting. The MS sends a request for8deactivation of call waiting (by issuing a Deactivate SS operation).9
b. The Serving GSM MSC sends a Deactivate SS message to the IIF emulating the HLR10associated with the subscriber. The message specifies the call waiting supplementary service11for the deactivation being requested.12
c. The IIF converts the call waiting Deactivate SS message to a particular digit string (e.g. *FC0).13The IIF includes this digit string (including *) in the Digits (Dialed) parameter of a FEATREQ14message and sends the message to the subscriber’s HLR.15
d. The HLR returns a featreq message to the IIF indicating a successful call waiting deactivation.16e. The IIF returns a Deactivate SS Ack message back to the Serving GSM MSC. Any parameters17
the HLR may have included that provide instructions for treatment towards the user (such as18AnnouncementList) shall be ignored by the IIF and not mapped into the message sent to the19Serving GSM MSC.20
f. When the Deactivate SS Ack message is received from the IIF, the Serving GSM MSC sends a21message to the MS to indicate that the call waiting deactivation had been successful.22
X.S0023
2-84
g. Because the request resulted in a change to the subscriber’s service profile (i.e., the call waiting1feature was deactivated), the HLR reports the change by sending a QUALDIR message to the2IIF emulating the Serving GSM MSC/VLR.3
h. The IIF sends an Insert Subscriber Data message to the Serving GSM MSC/VLR.4i. The Serving GSM MSC/VLR returns an Insert Subscriber Data Ack to the IIF.5j. The IIF returns a qualdir message to the HLR.6
7
X.S0023
2-85
4.9 Calling Number / Line Identification Presentation/Restriction1
4.9.1 Handling of calling number/ line identification presentation2
4.9.1.1 GSM Foreign Mode3
If CNIP / CLIP service is authorized and active, the calling party number is available and4presentation is allowed, the called party’s serving network shall provide the calling party number to5the called party during call alerting as in Figure 67 below.6
78
Figure 67: Calling number/ line identification presentation:9mobile station or fixed terminal to mobile station – GSM Foreign Mode10
a. An incoming call for the called party is received at his/her home network.1112
b. The calling party number may be carried in the calling party number digits parameter as13specified in TIA/EIA-41-5-D [2].14
15c. The calling party number may be carried in the calling party number string parameter as16
specified in TIA/EIA-41-5-D [2].1718
d. The calling party number may be carried in the additional signal information element as19specified in GSM 09.02 [4].20
21e. The VLR returns a roaming number for routing purposes.22
23
MSC HLR IIFMSC/VLR
ANSI-41 NETWORK
MS
GSM NETWORK
Incoming call to DN
LOCREQ
ROUTREQ
Routreq (TLDN = MSRN)
Locreq (TLDN = MSRN)
Provide Roaming No
Prov Roaming No Ack
Call Setup
Alert
(MSRN)
(Calling Party No))
(Calling Party No,PI, SI, Sub-address)
(Calling Party No)
(Calling Party No)
(Calling Party No)
a
b
c
d
e
f
g
h
i
X.S0023
2-86
f. The IIF maps the MSRN it receives from the VLR into the TLDN field in the routreq.12
g. The HLR returns a locreq to the MSC with the routing information it received from the IIF.34
h. The trunk signaling between the MSC’s may transit a number of intermediate signaling networks5of various capabilities. As such, there is no guarantee that the calling party number can be6conveyed using the ISUP/TUP signaling capabilities.7
8i. The MSC delivers the calling party identification during the call setup operation with the MS.9
The calling party subaddress is passed if it is received from the originating network. The Calling10Party No, Presentation Indicator (PI), and Screening Indicator (SI) shall be sent in accordance11with GSM 03.81 [34].12
13Note: Where a calling party number is delivered both via MAP signaling and ISUP/TUP signaling,14
the number delivered via MAP signaling takes precedence.1516
Note: When an additional calling party number is also available for presentation purposes, the17additional calling party number (subject to CNIP/CLIR) shall be presented in preference to any18other calling party number.19
204.9.1.1.1 Interrogation21
The subscriber can request the status of the supplementary service when operating in GSM foreign22mode and be informed if the service is provided to him/her.23
X.S0023
2-87
4.9.1.2 ANSI-41 Foreign Mode1
If CNIP / CLIP service is authorized and active, the calling party number is available and2presentation is allowed, the called party’s serving network shall provide the calling party number to3the called party during call alerting as in Figure 68 below.4
5
Figure 68: Calling number/ line identification presentation:6mobile station or fixed terminal to mobile station – ANSI-41 Foreign Mode7
a. An incoming call for the called party is received at his/her home network.89
b. The calling party number may be carried in the additional signal information element as10specified in GSM 09.02 [4].11
12c. The calling party number may be carried in the additional signal information element as13
specified in GSM 09.02 [4].1415
d. The calling party number may be carried in the calling party number string parameter as16specified in ANSI-41.5 [2].17
18e. The MSC returns a TLDN for routing purposes19
20f. The IIF maps the TLDN it receives from the MSC into the MSRN field in the Provide Roaming21
No Ack.2223
g. The HLR returns an SRI Ack to the GMSC with the routing information it received from the IIF.2425
GMSC HLR IIFMSC/VLR
GSM NETWORK
MS
ANSI-41 NETWORK
Incoming call to DN
Send Routing Info
Provide Roaming No
Prov Roaming No Ack
SRI Ack
ROUTREQ
routreq
Call Setup
Alert
(TLDN)
(Calling Party No))
(Calling Party No)
(Calling Party No)
(Calling Party No)
a
b
c
d
e
f
g
h
i
(MSRN =TLDN)
(MSRN = TLDN)
(Calling Party No)
X.S0023
2-88
h. The trunk signaling between the MSC’s may transit a number of intermediate signaling networks1of various capabilities. As such, there is no guarantee that the calling party number can be2conveyed using the ISUP/TUP signaling capabilities.3
4i. The mobile station receives an incoming call alert, which contains the calling party identification5
information.67
Note: Where a calling party number is delivered both via MAP signaling and ISUP/TUP signaling,8the number delivered via MAP signaling takes precedence.9
4.9.1.2.1 Interrogation10
The subscriber cannot request the status of the supplementary service in ANSI-41 Foreign mode.11
X.S0023
2-89
4.9.2 Handling of calling number/ line identification restriction1
4.9.2.1 General2
If the calling subscriber has calling number/line identification restriction authorized and active and it3is impossible to indicate to the terminating network (due to interworking) that the number shall not4be presented to the terminating party, the calling number/line identity shall not be delivered to the5terminating network.64.9.2.2 GSM Foreign Mode7
If CNIR / CLIR service is authorized and active, the calling party number is available and8presentation is restricted, the called party’s serving network shall not present the calling party9number to the called party during call alerting. An indication that the calling party number is10restricted shall be delivered to the called party.114.9.2.2.1 Interrogation12
The subscriber can request the status of the CNIR /CLIR supplementary service and be informed if13the service is provided to him/her and which mode is provided, i.e. permanent or temporary and if14temporary, what the default value is (i.e. allowed or restricted).154.9.2.3 ANSI-41 Foreign Mode16
If CNIR / CLIR service is authorized and active, the calling party number is available and17presentation is restricted, the called party’s serving network shall not present the calling party18number to the called party during call alerting. An indication that the calling party number is19restricted shall be delivered to the called party.204.9.2.3.1 Interrogation21
The subscriber cannot request the status of the supplementary service.22
X.S0023
2-90
4.10 Call Barring and Operator Determined Barring1
This section describes the interoperability at the IIF to support ANSI-41 outgoing call restrictions,2GSM Operator Determined Barring (ODB), and GSM Call Barring Supplementary Services. The3scenarios included are illustrative and not exhaustive.4
ODB is a GSM administrative feature. As described in associated Stage 1 documentation, direct5mapping of many GSM ODB or call barring options does not exist in ANSI-41mode. Likewise, many6ANSI-41 outgoing call restrictions do not directly map to equivalent GSM ODB or call barring7options.8
4.10.1 Activation of Barring at VLR9These call flows apply only to Call Barring Supplementary Services, ANSI-41 call restrictions, or10ODB programs (e.g., Barring of Outgoing Calls) for which barring is performed at the VLR. Any11barring or call restrictions applied in the HLR shall result in the appropriate restrictions being12downloaded to the serving VLR/MSC via the IIF.13
4.10.1.1 Activation of Call Restrictions while in GSM Foreign Mode14
This scenario describes the successful activation of call restrictions for a native ANSI-41subscriber15roaming in a GSM network at a time when the subscriber is currently registered.16
a
b
c
d
ISD Ack
ANSI-41HLR
GSMVLR/MSC
Insert Subscriber Data
qualdir
IIF
QUALDIR
17Figure 69: Activation of Call Restriction - GSM Foreign Mode18
a. Call restrictions are applied at the ANSI-41 HLR. The HLR sends an appropriate19QualificationDirective INVOKE message to the IIF emulating the VLR where the subscriber is20roaming.21
22b. The IIF forwards a corresponding Insert Subscriber Data message to the GSM VLR.23
24c. The VLR sends an Insert Subscriber Data acknowledgement to the IIF.25
26d. The IIF forwards a QualificationDirective RETURN RESULT message to the HLR.27
28
X.S0023
2-91
4.10.1.2 Activation of Call Barring while in ANSI-41 Foreign Mode1
This scenario describes the successful application of ODB or call barring for a native GSM2subscriber roaming in an ANSI-41 network.3
a
b
c
dISD Ack
GSMHLR
ANSI-41VLR/MSC
Insert Subscriber Data
qualdir
IIF
QUALDIR
4Figure 70: Activation of Call Barring – ANSI-41 Foreign Mode5
6a. ODB or call barring is applied at the GSM HLR. The HLR sends an appropriate Insert7
Subscriber Data message to the IIF emulating the VLR where the subscriber is roaming.89
b. The IIF forwards a corresponding QualificationDirective INVOKE message to the ANSI-41 VLR.1011
c. The VLR sends a QualificationDirective RETURN RESULT to the IIF.1213
d. The IIF forwards an Insert Subscriber Data acknowledgement message to the HLR.14
X.S0023
2-92
4.10.2 Invocation of Barring of Incoming Calls1
4.10.2.1 GSM Foreign Mode2
Barring of incoming calls is performed at the ANSI-41 HLR. There is no IIF involvement.3
4.10.2.2 ANSI-41 Foreign Mode4
Barring of incoming calls is performed at the GSM HLR. There is no IIF involvement.5
4.10.3 Invocation of Barring of Roaming6Barring of Roaming is performed at the HLR. The following subsections, however, illustrate the7signaling at the IIF when a barred subscriber attempts to roam into a GSM or ANSI-41 Foreign8network.9
4.10.3.1 GSM Foreign Mode10
This scenario describes the successful barring of roaming for a native ANSI-41subscriber11attempting to roam into a GSM network.12
a
b
c
dUL Ack
GSMMSC/VLR
ANSI-41HLR
Update Location
regnot
IIF
REGNOT
13Figure 71: Invocation of Barring of Roaming – GSM Foreign Mode14
15a. A native ANSI-41subscriber with barring of Roaming active, attempts to register in a GSM16
network. The GSM VLR sends an Update Location message to the IIF emulating the17subscriber’s HLR.18
19b. The IIF issues a RegistrationNotification INVOKE to the HLR.20
21c. The HLR determines that roaming is denied in this case, returns a RegistrationNotification22
RETURN RESULT with AuthorizationDenied set to Not Authorized for the MSC. Optionally,23a RegistrationCancellation message may be sent to the previous Serving MSC/VLR (if24registration was in an ANSI-41 network) or to the IIF (if registration was in a GSM network).25
26d. The IIF issues an Update Location acknowledgement with User Error set to Roaming Not27
Allowed. The VLR denies the registration attempt.28
X.S0023
2-93
4.10.3.2 ANSI-41 Foreign Mode1
This scenario describes the successful ODB barring of roaming for a native GSM subscriber2attempting to roam into an ANSI-41 network.3
a
b
c
d
UL Ack
ANSI-41MSC/VLR
GSMHLR
Update Location
regnot
IIF
REGNOT
4Figure 72: Invocation of Barring of Roaming – ANSI-41 Foreign Mode5
6a. A native GSM subscriber with ODB barring of Roaming active, attempts to register in an7
ANSI-41 network. The ANSI-41 VLR sends an RegistrationNotification INVOKE to the IIF8emulating the subscriber’s HLR.9
10b. The IIF issues an Update Location message to the HLR.11
12c. The HLR determines that roaming is denied in this case, returns an Update Location13
acknowledgement with User Error set to Roaming Not Allowed. Optionally, a Cancel Location14message may be sent to the previous Serving MSC/VLR (if registration was in a GSM network)15or to the IIF (if registration was in an ANSI-41 network).16
17d. The IIF issues a RegistrationNotification RETURN RESULT with AuthorizationDenied set to Not18
Authorized for the MSC. The VLR denies the registration attempt.19
X.S0023
2-94
4.10.4 Invocation of Barring of Supplementary Services Management1Barring of Supplementary Services Management is performed at the HLR. The following2subsections, however, illustrate the signaling at the IIF when a subscriber attempts to activate a3supplementary service in a GSM or ANSI-41 Foreign network, while Barring of Supplementary4Services Management is in effect.5
4.10.4.1 GSM Foreign Mode6
This scenario describes the successful barring of supplementary service control for a native7ANSI-41subscriber in a GSM network.8
a
b
c
dActivate SS Ack
GSMMSC/VLR
ANSI-41HLR
Activate SS
featreq
IIF
FEATREQ
9Figure 73: Invocation of Barring of Supplementary Service Control – GSM Foreign Mode10
11
a. A native ANSI-41subscriber attempts to activate a feature to which he is not authorized. The12MSC sends an Activate SS message to the IIF emulating the subscriber’s HLR.13
14b. The IIF issues a FeatureRequest INVOKE message to the HLR.15
16c. The HLR, determining that the subscriber is not authorized, sends a FeatureRequest RETURN17
RESULT, with FeatureResult set to Unsuccessful to the IIF.1819
d. The IIF issues an Activate SS acknowledgement, with User Error set to SS Subscription20Violation to the VLR. The VLR denies the activation.21
X.S0023
2-95
4.10.4.2 ANSI-41 Foreign Mode1
This scenario describes the successful ODB barring of supplementary services management for a2native GSM subscriber in an ANSI-41 network.3
a
b
c
d
Activate SS Ack
ANSI-41MSC/VLR
GSMHLR
Activate SS
featreq
IIF
FEATREQ
4Figure 74: Invocation of Barring of Supplementary Services Management – ANSI-41 Foreign5
Mode6a. A native GSM subscriber with ODB barring of Supplementary Services Management active,7
roaming in an ANSI-41 network, attempts to activate a supplementary service. The MSC sends8a FeatureRequest INVOKE to the IIF emulating the subscriber’s HLR.9
10b. The IIF issues an Activate SS message to the HLR.11
12c. The HLR, determining that ODB barring is in effect for this subscriber, sends an Activate SS13
acknowledgement, with User Error set to SS Subscription Violation to the IIF.1415
d. The IIF issues a FeatureRequest RETURN RESULT, with FeatureResult set to Unsuccessful to16the VLR. The VLR denies the activation.17
X.S0023
2-96
4.11 Short Message Service1
This section illustrates the interactions between network entities in various situations related to GSM2and ANSI-41 foreign mode operation for Short Message Service.3
4.11.1 Assumptions4The following assumptions are made in the message flows:5
• The SMS-GMSC and SMS-IWMSC functions are combined in the SMSC.6
• The user data received in the GSM SMS-DELIVER and GSM SMS-SUBMIT is tunneled from7the Short Message Entity (SME) to the Mobile Station (MS).8
• When the MS wishes to originate a short message and is operating in foreign mode, it shall use9a teleservice server address which maps to the IIF. When the IIF receives this address it shall10be mapped to the corresponding message center.11
• The MO SMS first goes to the originator’s Message Center (MC) and then to the recipient’s12Message Center.13
Only foreign mode message flows are described. Native mode message flows are as defined for the14native mode technology except in 4.11.2 which addresses GHOST/WEMT-CMT interworking within15an ANSI-41 network. Note: CMT applies for CDMA or ANSI-136 subscribers, GHOST applies only16for ANSI-136 subscribers, and WEMT only for CDMA subscribers.17
X.S0023
2-97
4.11.2 Mobile Station only Supports GHOST/WEMT1If the mobile station only supports GHOST (GSM Hosted SMS Teleservice) or WEMT, there shall2be a need for CMT (Cellular Messaging Transport) to GHOST/WEMT and GHOST/WEMT to CMT3conversion in the ANSI-41 network (i.e., in native mode), most probably in the Message Centers.4This is depicted in the next two diagrams.5
4.11.2.1 Short Message from CMT Mobile Station to GHOST/WEMT Mobile Station6both in Native Mode7
SMD-REQ(CMT)a
MC-A MC-B ANSI-41HLR
ANSI-41MSC
MS-A ANSI-41MSC
SMDPP(CMT)
smdpp[ACK]
SMD-ACK
b
c
d
e
f
g
h
i
j
k
SMDPP(CMT)
smdpp[ACK]
SMSREQ
smsreq
SMDPP(GHOST/WEMT)
(SMS delivered to MSusing GHOST/WEMT)
smdpp [ACK]8
Figure 75: Short Message from a TDMA or CDMA CMT phone to a GHOST or WEMT mobile9station, both in native mode10
Notes:11
Message Center B (MC-B) is responsible for converting CMT to GHOST/WEMT.12
MC-A and MC-B could be one and the same.13
14
X.S0023
2-98
4.11.2.2 Short Message sent from GHOST/WEMT Mobile Station to CMT Mobile1Station, both in Native Mode2
SMD-REQ(GHOST/WEMT)a
MC-A MC-B ANSI-41HLR
ANSI-41MSC
MS-A ANSI-41MSC
SMDPP(GHOST/WEMT)
smdpp[ACK]
SMD-ACK
b
c
d
e
f
g
h
i
j
k
SMDPP(CMT)
smdpp[ACK]
SMSREQ
smsreq
SMDPP(CMT)
(SMS delivered to MSusing CMT)
smdpp [ACK]3
Figure 76: Short Message from a GHOST or WEMT mobile station to a TDMA CMT or CDMA4CMT Phone, both in native mode5
Notes:6
Message Center A (MC-A) is responsible for converting GHOST/WEMT to CMT. This is done so7that only the operators using GHOST/WEMT would need to have a modified Message Center. In8the event that MS-B also uses GHOST/WEMT and that MC-A is not the same as MC-B, then MC-B9would have to re-convert from CMT to GHOST/WEMT, unless there is some way for MC-A to know10that MS-B also uses GHOST/WEMT.11
In the event that MC-A and MC-B are one and the same, and that MS-B also uses GHOST/WEMT,12then no conversion is needed.13
14
X.S0023
2-99
4.11.3 Mobile Terminating SMS in GSM Foreign Mode1This section discusses the delivery of the short message, i.e. how to deliver it to the roaming2subscriber once the message has been delivered in the recipient’s Message Center.3
On the ANSI-41 side, the short message may have been originated in CMT or GHOST/WEMT4format. So the IIF has to convert either CMT or GHOST/WEMT to GSM SMS.5
4.11.3.1 Successful Mobile Terminating ANSI-41SMS (CMT) mapped to GSM SMS6
ANSI-41 MC
ANSI-41 HLR IIF
GSM MSC/ VLR
MS
a
b
c
d
e
f
g
h
i
SMS Delivery
SMSREQUEST
SMDPP (CMT)
smdpp [ACK]
FORWARD SHORT MESSAGE
SMS Delivery
SMS Delivery Ack
Forward Short Message
smsrequest
78
Figure 77: Successful Mobile Terminating ANSI-41SMS (CMT) mapped to GSM SMS910
a. The ANSI-41Message Center (MC) receives a short message for a specific subscriber. Note:11This step is shown for completeness only and is not repeated in subsequent call flows.12
13b. The Message Center sends an SMS Request message to the ANSI-41 HLR of the short14
message recipient to request a routing address for delivering the short message to that15subscriber.16
17c. Since the subscriber has a current valid location stored in the HLR, the HLR returns it to the18
MC in the SMS Request Return Result message.1920
d. The Message Center then sends a Short Message Delivery Point to Point message to the IIF,21which is seen as the current serving ANSI-41 MSC/VLR for that subscriber. Note that in this22case, the format used by the MC is the CMT format (Cellular Messaging Transport). Note that23alternatively, the ANSI-41MC could translate the original CMT SMS to GHOST/WEMT format24before sending it to the IIF if the IIF only supports the GHOST format. In this case the IIF would25convert TDMA GHOST or CDMA WEMT into GSM format (see Section 4.11.3.2) instead of26ANSI-41CMT into GSM format.27
X.S0023
2-100
e. Upon reception of the Short Message Delivery Point to Point message from the ANSI-41MC,1the IIF originates a FORWARD SHORT MESSAGE to the serving GSM MSC/VLR after having2translated the short message into GSM format. The IIF is then acting as a GSM SMS-GMSC.3
4f. The serving GSM MSC/VLR sends the short message to the mobile station. Note: This step is5
shown for completeness only and is not repeated in subsequent call flows.67
g. The mobile station acknowledges the delivery of the short message. Note: This step is shown8for completeness only and is not repeated in subsequent call flows.9
10h. The serving GSM MSC/VLR sends the result of the Forward Short Message to the IIF.11
12i. The IIF sends the result of the Short Message Delivery Point to Point to the ANSI-41Message13
Center.14
X.S0023
2-101
4.11.3.2 Successful Mobile Terminating ANSI-41SMS (GHOST/WEMT) Mapped to GSM1SMS2
3Figure 78: Successful Mobile Terminating ANSI-41SMS (GHOST/WEMT) mapped to GSM SMS4
a. The ANSI-41 MC sends a SMSRequest Invoke message to the HLR, including as arguments5the MIN (MSISDN) of the mobile station and SMS Notification Indicator.6
b. The HLR determines if the message shall be forwarded to the MS and sends a response back7in a SMSRequest Return Result, with the SMS_Address set to the IIF address (point code or8E.164 address).9
c. The MC formats a GHOST/WEMT teleservice and sends it to the IIF in an SMDPP message.10d. Upon receipt of the SMDPP message, the IIF builds a FORWARD SHORT MESSAGE,11
stripping off the GHOST/WEMT teleservice and using the encapsulated GSM SMS transfer12PDU, and routes it to the VMSC.13
e. The VMSC packages the GSM SMS RP-DATA into a CP-DATA message and delivers it across14the GSM air interface to the mobile station. The mobile station acknowledges receipt of the CP-15DATA and RP-DATA messages via CP-ACK and CP-ACK[RP-ACK], respectively. Upon16successful receipt of the RP-ACK, the VMSC shall send a positive acknowledgement Forward17Short Message back to the IIF.18
f. The IIF maps the received Forward Short Message into a SMDPP Return Result and sends it to19the MC.20
ANSI-41 GSM
smdpp [ACK]
MC HLR IIF VMSC
a
d
a
c
b
SMDPP
SMSREQ
smsreq
FORWARD SHORT MESSAGE
Forward Short Message e
f
X.S0023
2-102
4.11.3.3 Unsuccessful Mobile Terminated Delivery (Failure at MSC)1
The following scenario applies to short message delivery failure in either CMT or GHOST/WEMT2
format.3
Figure 79: Unsuccessful Mobile Terminated Delivery (Failure at MSC)45
a. The ANSI-41 MC sends a SMSRequest Invoke message to the HLR, including as arguments6the MIN (MSISDN) of the mobile station and SMS Notification Indicator.7
b. The HLR determines if the message shall be forwarded to the MS and sends a response back8in a SMSRequest Return Result, with the SMS_Address set to the IIF address (point code or9E.164 address).10
c. The MC formats a GHOST/WEMT teleservice or a CMT short message and sends it to the IIF in11an SMDPP message.12
d. Upon receipt of the SMDPP message, the IIF builds a FORWARD SHORT MESSAGE,13stripping off the GHOST/WEMT teleservice and using the encapsulated GSM SMS transfer14PDU, and routes it to the VMSC. If the message received is in the CMT format, the IIF maps15this information into a short message in GSM format.16
e. The VMSC packages the GSM SMS RP-DATA into a CP-DATA message and delivers it across17the GSM air interface to the mobile station. The mobile station negatively acknowledges either18the CP-DATA message or the RP-DATA message. The VMSC sends a negative19acknowledgement Forward Short Message (with appropriate cause value) back to the IIF.20
f. The IIF maps the received Forward Short Message into a SMDPP Return Result and sends it to21the MC. In addition, the IIF sets one of the GSM SMS flags as defined in the GSM 03.4022specification [35] according to the error cause received from the VMSC; that is, the Mobile23Subscriber Not Reachable Flag (MNRF) shall be set if the error cause is “absent subscriber”,24and the Memory Capacity Exceeded Flag (MCEF) shall be set if the error cause is “memory25capacity exceeded”. Additionally, the IIF emulating the ANSI-41 MSC shall set and store the26
ANSI-41 GSM
smdpp [NAK]
MC HLR IIF VMSC
a
d
a
c
b
SMDPP
SMSREQ
smsreq
FORWARD SHORT MESSAGE
Forward Short Message e
f
X.S0023
2-103
SMS Delivery Pending flag with the MC parameters received in the SMDPP (for later delivery in1the SMSNOT) – note that this “SMS Delivery Pending” flag/data serves the same purpose as a2GSM HLR’s “Message Waiting Data” flag/data. [However, note that if an ANSI-41 REGCAN is3received from the ANSI-41 HLR before the SMS Delivery Pending Flag is cleared, then the4regcanc response shall contain the SMS_MessageWaitingIndicator, and all flags are cleared5(i.e., MNRF, MCEF, and SMS Delivery Pending Flag)].6
7
X.S0023
2-104
4.11.3.4 Unsuccessful Mobile Terminated Delivery (Failure at IIF)1
The following scenario applies to short message delivery failure in either CMT or GHOST/WEMT2format.3
4
Figure 80: Unsuccessful Mobile Terminated Delivery (Failure at IIF)5a. The ANSI-41 MC sends a SMSRequest Invoke message to the HLR, including as arguments6
the MIN (MSISDN) or IMSI of the mobile station and SMS Notification Indicator.7b. The HLR determines if the message shall be forwarded to the MS and sends a response back8
in a SMSRequest Return Result, with the SMS_Address set to the IIF address (point code or9E.164 address).10
c. The MC formats a GHOST/WEMT teleservice and sends it to the IIF in an SMDPP message.11d. Upon receipt of the SMDPP message, the IIF examines the GSM 03.40 HLR flags12
(MNRF/MCEF) and determines that the MS is unable to receive a Short Message. The IIF13indicates this fact in the SMDPP Return Result. It includes the cause for the failure in the14SMS_CauseCode parameter of the SMDPP Return Result. The IIF shall set & store the SMS15Delivery Pending Flag with the data received in the SMDPP message (for later delivery in the16SMSNOT).17
ANSI-41 GSM
smdpp [NAK]
MC HLR IIF VMSC
a
d
a
c
b
SMDPP
SMSREQ
smsreq
X.S0023
2-105
4.11.3.5 Alerting for an ANSI-41Subscriber in GSM Foreign Mode1
The following scenario applies to short messages originated in either CMT or GHOST/WEMT2format.3
4
Figure 81: Alerting for an ANSI-41Subscriber in GSM Foreign Mode56
a. The VMSC sends a READY FOR SM (MAP V2) to the IIF, including as arguments the IMSI and7Alert Reason. Note: The SMS notification can also be triggered when the VMSC sends a8NoteMSPresent (MAP V1) or an UpdateLocation.9
b. If the IIF has GSM 03.40 flags set, then these flags shall be cleared according to the “alert10reason”; that is, if the “alert reason” is “memory available”, then both the MCEF and MNRF flags11are cleared, and if the “alert reason” is “MS present”, then the MNRF flag is cleared. If the12UpdateLocation is received, then the MNRF flag is cleared. The IIF sends a Ready for SM13response to the VMSC with no arguments.14
c. If the IIF has the SMS Delivery Pending Flag set, and if the MCEF flag is not set, then the IIF15sends a SMSNOT to each of the subscriber’s MCs stored with the SMS Delivery Pending Flag.16The SMSNOT shall contain; the MIN (MSISDN) as mapped from the IMSI, ESN, and17SMS_Address containing the IIF address.18
d. The MC sends a SMSNOT Return Result to the IIF, then the IIF clears the SMS Delivery19Pending Flag, then proceeds to send the mobile station a mobile terminated GHOST/WEMT20teleservice message according to 4.11.3.2.21
22
ANSI-41 GSM
smsnot
MC HLR IIF VMSC
READY FOR SM
Ready fro SM
a
d
a
c
b
SMSNOT
X.S0023
2-106
4.11.4 Mobile Terminated SMS in ANSI-41 Foreign Mode1This section describes the message flows for delivering a CMT or GHOST/WEMT teleservice when2the mobile station is operating in ANSI-41 Foreign Mode. Since on the ANSI-41 side, the short3message may need to be in CMT or GHOST/WEMT format, the IIF has to convert the GSM SMS to4either CMT or GHOST/WEMT.5
4.11.4.1 Successful GSM SMS mapped to ANSI-41(CMT) SMS6
7
Figure 82: Successful GSM SMS mapped to ANSI-41(CMT) SMS8a. The GSM Short Message Service Center (SMSC) receives a short message for a specific9
subscriber. Note: This step is shown for completeness only and is not repeated in subsequent10call flows.11
12b. The SMS-GMSC originates a Send Routing Info for Short Message to the GSM HLR of the13
short message recipient to request a routing address for delivering the short message to that14subscriber.15
16c. Since the subscriber has a current valid location stored in the HLR, the HLR returns it to the17
SMS-GMSC in the Send Routing Info for Short Message Result message.1819
d. The SMS-GMSC then sends a Forward Short Message to the IIF, seen as the serving GSM20MSC/VLR.21
22e. Upon reception of the Forward Short Message from the SMS-GMSC, the IIF originates a Short23
Message Delivery Point to Point message to the serving ANSI-41 MSC/VLR after having24
GSM ANSI-41
SMSC HLR IIF MSC
a
d
a
c
b
e
f
FORWARD SHORT MESAGE
Forward Short Message
SEND ROUTING INFO FOR SM
Send Routing Info For SM
SMDPP (CMT)
smdpp [CMT] g
h
SMSDelivery
(SMS delivered toMobile Station)
X.S0023
2-107
translated the short message into IS-41 CMT format. The IIF is then acting as an1ANSI-41Message Center.2
3f. The serving ANSI-41 MSC/VLR sends the short message to the mobile station and an4
acknowledgement is sent back to the MSC/VLR.56
g. The serving ANSI-41 MSC/VLR sends the result of the Short Message Delivery Point to Point7message to the IIF.8
9h. The IIF sends the result of the Forward Short Message to the GSM SMS-GMSC.10
11
X.S0023
2-108
4.11.4.2 Successful GSM SMS mapped to ANSI-41(GHOST/WEMT) SMS1
This method uses the tunneling concept. Instead of translating the GSM SMS to an ANSI-41CMT2SMS format, the IIF shall package the GSM SMS into a TDMA SMS with the teleservice GHOST3(GSM Hosted SMS Teleservice) or CDMA SMS with teleservice WEMT.4
5
Figure 83: Successful GSM SMS mapped to ANSI-41(GHOST/WEMT) SMS67
a. The SMSC receives a request to deliver a short message to a GSM subscriber. It sends to the8GSM HLR a SEND ROUTING INFO FOR SM, including as arguments the MSISDN, Priority,9and Service Centre address.10
b. The HLR determines if the message shall be forwarded to the MS and sends a response back11to the SMSC in a Send Routing Info for SM, including as arguments the IMSI of the MS and12Network Node Number of the IIF.13
c. The SMSC originates a FORWARD SHORT MESSAGE to the address provided by the HLR14(i.e., IIF), including as arguments the IMSI, Service Centre Address, and GSM SMS-DELIVER15PDU (and optionally if more messages are to be sent).16
GSM ANSI-41
SMSC HLR IIF MSC
a
d
a
c
b
e
f
FORWARD SHORT MESAGE
Forward Short Message
REPORT SM DELIVERY STATUS
Report SM Delivery Status
SEND ROUTING INFO FOR SM
Send Routing Info For SM
SMDPP (GHOST)
smdpp [ACK]
g
h
X.S0023
2-109
Upon receipt of the FORWARD SHORT MESSAGE, the IIF shall build an ANSI-41 SMDPP ,1encapsulating the GSM SMS transfer PDU in the GHOST/WEMT teleservice. The IIF shall2route the SMDPP message to the serving MSC. The serving MSC maps the SMDPP3message into an R-DATA message and sends it to the mobile station over the TDMA or4CDMA air interface. The mobile station shall acknowledge receipt of the R-DATA message5and GHOST/WEMT teleservice by sending an R-DATA ACCEPT message to the MSC.6
7
d. After receiving the R-DATA ACCEPT message, the serving MSC sends a positive8acknowledgement SMDPP Return Result to the IIF.9
e. The IIF maps the received SMDPP Return Result to a Forward Short Message, and sends it to10the GSM SMSC.11
f. The SMSC send a REPORT SM DELIVERY STATUS to the HLR, including as arguments the12MSISDN, SMSC Address, and Successful Transfer. The SMSC sends this message based on13the procedures described in GSM 03.40 [35] and GSM 09.02 [4].14
g. The HLR shall set the appropriate flags as specified in the GSM specifications (GSM 09.02 and1503.40), then send a Report SM Delivery Status to the SMSC.16
X.S0023
2-110
4.11.4.3 Unsuccessful GSM SMS mapped to ANSI-41SMS (Failure at MS)1
The following scenario applies to short messages delivered in either CMT or GHOST/WEMT format.2
Figure 84: Successful GSM SMS mapped to ANSI-41SMS (Failure at MS)34
a. The SMSC receives a request to deliver a short message to a GSM subscriber. It sends to the5GSM HLR a SEND ROUTING INFO FOR SM, including as arguments the MSISDN, Priority,6and Service Center address.7
b. The HLR determines if the message shall be forwarded to the MS and sends a response back8to the SMSC in a Send Routing Info for SM, including as arguments the IMSI of the MS and9Network Node Number of the IIF.10
c. The SMSC originates a FORWARD SHORT MESSAGE to the address provided by the HLR11(i.e., IIF), including as arguments the IMSI, Service Center Address, and GSM SMS-DELIVER12PDU (and optionally if more messages are to be sent).13
d. Upon receipt of the FORWARD SHORT MESSAGE, the IIF builds an ANSI-41 SMDPP14message, encapsulating the GSM SMS transfer PDU in a GHOST/WEMT teleservice, and15routes it to the serving MSC. The IIF can also convert the message into ANSI-41CMT format.16The serving MSC converts the SMDPP message into an R-DATA message and sends it to the17mobile station over the TDMA or CDMA air interface. The mobile station returns an R-DATA18REJECT message to the MSC, indicating an error in the receipt of the message.19
e. Upon receipt of the R-DATA REJECT, the serving MSC maps the ANSI-41R-Cause code to the20appropriate ANSI-41 SMS_CauseCode value, and sends a negative acknowledgement SMDPP21Return Result back to the IIF.22
GSM ANSI-41
SMSC HLR IIF MSC
a
d
a
c
b
e
f
FORWARD SHORT MESAGE
Forward Short Message
REPORT SM DELIVERY STATUS
Report SM Delivery Status
SEND ROUTING INFO FOR SM
Send Routing Info For SM
SMDPP
smdpp [NAK]
g
h
X.S0023
2-111
f. The IIF sets the SMS Delivery Pending Flag in the IIF and maps the received SMDPP Return1Result into a Forward Short Message and sends it to the SMSC, after mapping the2SMS_CauseCode to the appropriate GSM MAP error.3
g. The SMSC sends a REPORT SM DELIVERY STATUS to the HLR, including as arguments the4MSISDN, SMSC Address, and Error Cause. The SMSC sends this message based on the5procedures described in GSM 03.40 [35] and GSM 09.02 [4].6
h. The HLR shall set the appropriate flags as specified in the GSM specifications (GSM 09.02 and703.40), then send a Report SM Delivery Status to the SMSC.8
X.S0023
2-112
4.11.4.4 Unsuccessful Delivery to GSM Subscriber (Postponed at MSC)1
The following scenario applies to short messages delivered in either CMT or GHOST/WEMT format.2
3Figure 85: Unsuccessful Delivery to GSM Subscriber (Postponed at MSC)4
a. The SMSC receives a request to deliver a short message to a GSM subscriber. It sends to the5GSM HLR a SEND ROUTING INFO FOR SM, including as arguments the MSISDN, Priority,6and Service Centre address.7
b. The HLR determines if the message shall be forwarded to the MS and sends a response back8to the SMSC in a Send Routing Info for SM, including as arguments the IMSI of the MS and9Network Node Number of the IIF.10
c. The SMSC originates a FORWARD SHORT MESSAGE to the address provided by the HLR11(i.e., IIF), including as arguments the IMSI, Service Centre Address, and GSM SMS-DELIVER12PDU (and optionally if more messages are to be sent).13
d. Upon receipt of the FORWARD SHORT MESSAGE, the IIF builds an ANSI-41 SMDPP14message, encapsulating the GSM SMS transfer PDU in a GHOST/WEMT teleservice, and15routes it to the serving MSC. The IIF can also convert the message into ANSI-41CMT format.16The addressed MS is temporarily unavailable for short message delivery and notification was17requested.18
e. The MSC responds with a negative acknowledgement SMS_CauseCode carried in the SMDPP19Return Result indicating delivery is postponed and returns it to the source of the corresponding20SMDPP (i.e., IIF). The MSC sets its SMS Delivery Pending Flag.21
GSM ANSI-41
SMSC HLR IIF MSC
a
d
a
c
b
e
f
FORWARD SHORT MESAGE
Forward Short Message
REPORT SM DELIVERY STATUS
Report SM Delivery Status
SEND ROUTING INFO FOR SM
Send Routing Info For SM
SMDPP
smdpp [NAK]
g
h
X.S0023
2-113
f. The IIF sets the SMS Delivery Pending Flag in the IIF and maps the received SMDPP Return1Result into a Forward Short Message and sends it to the SMSC, after mapping the2SMS_CauseCode to the appropriate GSM MAP error.3
g. The SMSC sends a REPORT SM DELIVERY STATUS to the HLR, including as arguments the4MSISDN, SMSC Address, and Error Cause. The SMSC sends this message based on the5procedures described in GSM 03.40 [35] and GSM 09.02 [4].6
h. The HLR shall set the appropriate flags as specified in the GSM specifications (GSM 09.02 and703.40), then send a Report SM Delivery Status to the SMSC.8
X.S0023
2-114
4.11.4.5 Unsuccessful Delivery to GSM Subscriber (Failure at IIF)1
2
Figure 86: Unsuccessful Delivery to GSM Subscriber (Failure at IIF)3a. The SMSC receives a request to deliver a short message to a GSM subscriber. It sends to the4
GSM HLR a SEND ROUTING INFO FOR SM, including as arguments the MSISDN, Priority,5and Service Centre address.6
b. The HLR determines if the message shall be forwarded to the MS and sends a response back7to the SMSC in a Send Routing Info for SM, including as arguments the IMSI of the MS and8Network Node Number of the IIF.9
c. The SMSC originates a FORWARD SHORT MESSAGE to the address provided by the HLR10(i.e., IIF), including as arguments the IMSI, Service Centre Address, and GSM SMS-DELIVER11PDU (and optionally if more messages are to be sent).12
d. Upon receipt of the FORWARD SHORT MESSAGE at the IIF, if the subscriber is known to be13unavailable or the SMS Waiting Indicator flag is set, then the IIF builds a Forward Short14Message and send it back to the SMSC.15
e. The SMSC sends a REPORT SM DELIVERY STATUS to the HLR, including as arguments the16MSISDN, SMSC Address, and Error Cause.17
f. The HLR shall set the appropriate flags as specified in the GSM specifications (GSM 09.02 and1803.40) and sends a Report SM Delivery Status to the SMSC. The SMSC sends this message19based on the procedures described in GSM 03.40 [35] and GSM 09.02 [4].20
GSM ANSI-41
SMSC HLR IIF MSC
a
d
a
c
b
e
f
FORWARD SHORT MESAGE
Forward Short Message
REPORT SM DELIVERY STATUS
Report SM Delivery Status
SEND ROUTING INFO FOR SM
Send Routing Info For SM
X.S0023
2-115
4.11.4.6 Alerting for a GSM Subscriber in ANSI-41 Foreign Mode1
In the event that the delivery of the short message to the ANSI-41 network is not possible, the IIF2shall be notified by the serving ANSI-41 MSC/VLR when the subscriber is available again. This shall3be done by receiving a Registration Notification or an SMS Notification message. This is illustrated4in the following diagram. The following scenario applies to short messages delivered in either CMT5or GHOST/WEMT format.6
7
Figure 87: Alerting for a GSM Subscriber in ANSI-41 Foreign Mode8a. The IIF receives either (1) an SMSNOT, or (2) a REGNOT when the ANSI-41 SMS Delivery9
Pending Flag is set at the IIF or the SMS_Address parameter is present in the REGNOT.10b. The IIF alerts the GSM HLR by sending a READY FOR SM including as arguments the IMSI11
and MS-Present.12c. The HLR shall send a Ready for SM to the IIF. If the SMS Waiting Indicator flag is set in the IIF,13
then it is cleared.14d. The IIF returns a Return Result acknowledgement message.15e. The HLR originates an ALERT SERVICE CENTRE to the SMSC address stored in the HLR,16
including as arguments the MSISDN, and SMSC Address.17f. The SMSC sends an Alert Service Centre to the HLR, then proceeds to send the mobile station18
a mobile terminated GSM SMS message according to 4.11.4.2.19
SMSC HLR IIF
GSM ANSI-41
MSC
SMSNOT or REGNOT
smsnot or regnot
READY FOR SM
Ready for SM
a
b
c
d
e
f
ALERT SERVICE CENTRE
alert service centre
X.S0023
2-116
14.11.5 Message Flows for Mobile Originated SMS in GSM Foreign Mode2This section describes the message flows for originating a short message to the subscriber’s home3message center when the mobile station is operating in GSM Foreign Mode. The following4scenarios apply to short messages delivered to the MC in either CMT or GHOST/WEMT format.5
4.11.5.1 Successful Mobile Originated Delivery6
Figure 88: Successful Mobile Originated Delivery7a. The VMSC originates a FORWARD SHORT MESSAGE to the address provided by the MS8
(i.e., IIF), including as arguments the Service Centre Address, MSISDN and GSM SMS-9SUBMIT PDU.10
b. Upon receipt of the FORWARD SHORT MESSAGE, the IIF builds an ANSI-41 SMDPP11message, encapsulating the GSM SMS transfer PDU in a GHOST/WEMT teleservice, and12routes it to the originator’s home MC. The IIF can also map the Forward Short Message into a13CMT short message.14
c. The MC sends a positive acknowledgement SMDPP Return Result to the IIF.15d. The IIF maps the received SMDPP Return Result to a Forward Short Message, and sends it to16
the VMSC.1718
GSM ANSI-41
FORWARD SHORT MESSAGE
Forward Short Message
VMSC HLR IIF MC
SMDPP
smdpp [ACK]
a
d
a
c
b
X.S0023
2-117
4.11.5.2 Unsuccessful Mobile Originated (Failure at MC)1
Figure 89: Unsuccessful Mobile Originated (Failure at MC)23
a. The VMSC originates a FORWARD SHORT MESSAGE to the address provided by the MS4(i.e., IIF), including as arguments the Service Centre Address, MSISDN and GSM SMS-5SUBMIT PDU.6
b. Upon receipt of the FORWARD SHORT MESSAGE, the IIF builds an ANSI-41 SMDPP7message encapsulating the GSM SMS transfer PDU in a GHOST/WEMT teleservice, and8routes it to the MC. The IIF can also map the Forward Short Message into a CMT short9message.10
c. The MC sends a negative acknowledgement SMDPP Return Result to the IIF.11d. The IIF maps the received SMDPP Return Result to a Forward Short Message with the12
appropriate cause code value, and sends it to the VMSC.1314
GSM ANSI-41
FORWARD SHORT MESSAGE
Forward Short Message
VMSC HLR IIF MC
SMDPP
smdpp [NAK]
a
d
a
c
b
X.S0023
2-118
4.11.5.3 Unsuccessful Mobile Originated (Failure at IIF)1
2Figure 90: Unsuccessful Mobile Originated (Failure at IIF)3
4
a. The VMSC originates a FORWARD SHORT MESSAGE to the address provided by the MS5(i.e., IIF), including as arguments the Service Centre Address, MSISDN and GSM SMS-6SUBMIT PDU.7
b. Upon receipt of the FORWARD SHORT MESSAGE, the IIF builds a negative acknowledgement8Forward Short Message and sends it to the VMSC.9
10
GSM ANSI-41
FORWARD SHORT MESSAGE
Forward Short Message
VMSC HLR IIF MC
a
b
X.S0023
2-119
4.11.6 Message Flows for Mobile Originated SMS in ANSI-41 Foreign Mode1This section describes the message flows for originating a short message to the subscriber’s home2message center when the mobile station is operating in ANSI-41 Foreign Mode. The following3scenarios apply to short messages originated in either CMT or GHOST/WEMT format.4
4.11.6.1 Successful Mobile Originated Delivery5
Figure 91: Successful Mobile Originated Delivery – ANSI-41 Foreign Mode6a. The VMSC originates a SMDPP invoke to the address provided by the MS (i.e., IIF), including7
as arguments the Teleservice Server Address, MIN (MSISDN), and GSM SMS-SUBMIT PDU8encapsulated in the GHOST/WEMT teleservice. The mobile originated message can also be in9the CMT format.10
b. Upon receipt of the SMDPP invoke, the IIF builds a FORWARD SHORT MESSAGE, and routes11it to the SMSC.12
c. The SMSC sends a positive acknowledgement Forward Short Message to the IIF.13
d. The IIF maps the received Forward Short Message to a SMDPP Return Result and sends it to14the VMSC.15
ANSI-41 GSM
SMDPP
smdpp [ACK]
VMSC HLR IIF SMSC
FORWARD SHORT MESSAGE
Forward Short Message
a
d
a
c
b
X.S0023
2-120
4.11.6.2 Unsuccessful Mobile Originated (Failure at SMSC)1
Figure 92: Successful Mobile Originated (Failure at SMSC) – ANSI-41 Foreign Mode23
a. The VMSC originates a SMDPP invoke to the address provided by the MS (i.e., IIF), including4as arguments the Teleservice Server Address, MIN (MSISDN) and GSM SMS-SUBMIT PDU5encapsulated in the GHOST/WEMT teleservice. The mobile originated message can also be in6the CMT format.7
b. Upon receipt of the SMDPP message, the IIF builds a FORWARD SHORT MESSAGE,8stripping off the GHOST/WEMT teleservice and using the encapsulated GSM SMS transfer9PDU, and routes it to the SMSC.10
c. The SMSC sends a negative acknowledgement Forward Short Message to the IIF.11d. The IIF maps the received Forward Short Message into a SMDPP Return Result and sends it to12
the VMSC.13
ANSI-41 GSM
SMDPP
smdpp [NAK]
VMSC HLR IIF SMSC
FORWARD SHORT MESSAGE
Forward Short Message
a
d
a
c
b
X.S0023
2-121
4.11.6.3 Unsuccessful Mobile Originated (Failure at IIF)1
2
Figure 93: Unsuccessful Mobile Originated (Failure at IIF) – ANSI-41 Foreign Mode34
a. The VMSC originates a SMDPP invoke to the address provided by the MS (i.e., IIF), including5as arguments the Teleservice Server Address, MIN (MSISDN) and GSM SMS-SUBMIT PDU6encapsulated in the GHOST/WEMT teleservice. The mobile originated message can also be in7the CMT format.8
b. Upon receipt of the SMDPP message, the IIF builds a negative acknowledgement SMDPP9Return Result and sends it to the VMSC.10
ANSI-41 GSM
SMDPP
smdpp [NAK]
VMSC HLR IIF SMSC
a
b
X.S0023
2-122
4.12 Message Waiting Notification1
This contribution illustrates the interactions between network entities in various situations related to2GSM and ANSI-41 foreign mode operation and Message Waiting Notification.3
4.12.1 GSM Foreign Mode4For a native ANSI-41subscriber roaming in a GSM environment, there can be two events that5trigger the IIF to send the Message Waiting Notification (MWN) using the GSM SMS to the Mobile6Station (MS). The first one is at registration (location update), if there is an indication in the ANSI-417HLR that messages have been delivered to the subscriber’s voice mail box, the ANSI-41 HLR shall8indicate that in the Registration Notification Return Result message. This shall trigger the IIF to send9a GSM SMS with the MWN information. This is shown in Section 4.12.1.1 The second event is10when the HLR receives a Message Waiting Notification for a subscriber that is already registered. In11this case, the ANSI-41 HLR shall send a Qualification Directive message to the IIF which shall12translate it into a GSM SMS with MWN indication. This is shown in Section 4.12.1.213
X.S0023
2-123
4.12.1.1 Indicator in ANSI-41 Registration Notification Return Result mapped to GSM1SMS2
3
456789
10111213141516171819202122232425262728
Figure 94: Indicator in ANSI-41 Registration Notification Return Result mapped to GSM SMS29a. The Voice Mail System (VMS) receives a voice mail for a specific subscriber.30
31b. The VMS send the “Message Waiting Notification” (MWN) to the ANSI-41 HLR of the voice mail32
recipient. Note that the interface between the VMS and the ANSI-41 HLR is not standardized in33
ANSI-41HLR
Forw.ShortMessage
SMS Delivery Ack
SMS Delivery (MWN)
FORW.SHORTMESSAGE (MWN)
Update Loc Accept
update location
Insert_sub_data
INSERT_SUB_DATA
regnot (MWNCOUNT,MWNTYPE)
UPDATELOCATION
Update Loc Req
“Message WaitingNotification”
VmailDelivery
REGNOT
VMS IIF GSMMSC/VLR
MS
a
b
c
d
e
f
g
h
i
j
k
l
m
n
X.S0023
2-124
ANSI-41 [2]. Note also that at that point in time, the subscriber is not registered in any serving1system, so the HLR just keeps the information that a voice mail was received.2
3c. The Mobile Station accesses a serving system and originates an update location request.4
5d. The Update Location is sent from the serving GSM MSC/VLR to the IIF, seen as the GSM HLR6
for that subscriber.78
e. The IIF sends a Registration Notification to the ANSI-41 HLR of the subscriber.910
f. The ANSI-41 HLR replies with the Registration Notification Return Result containing the11“Message Waiting Notification” information that consists of two parameters:12MessageWaitingNotificationCount (MWNCOUNT) and MessageWaitingNotificationType13(MWNTYPE). For a description of these parameters, see the ANSI-41 specifications, sections146.5.2.78 and 6.5.2.79 [2].15
16At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification17is to be delivered to the Mobile Station.18
19g. The IIF sends Insert Subscriber Data to the serving GSM MSC/VLR. Note that there could be20
more than one Insert Subscriber Data message depending on the subscriber profile.2122
h. The serving GSM MSC/VLR returns the Insert Subscriber Data result. Note that there could be23more than one such result message, one matching every Insert Subscriber Data message.24
25i. The IIF completes the location update by sending the Update Location result message to the26
serving GSM MSC/VLR.2728
j. The serving GSM MSC/VLR confirms the update location to the mobile station.2930
k. Since the REGNOT return result from event f contained the Message Waiting Notification31information, this triggers the IIF to originate an SMS with MWN information by sending Forward32Short Message to the serving GSM MSC/VLR. The IIF is then acting as a GSM SMS-GMSC.33The IIF is to encode the MWN information in the SMS with three methods, namely, UDH, DCS,34and CPHS. See to Volume 3 for the encoding details.35
36l. The serving GSM MSC/VLR sends the short message with the MWN information to the mobile37
station.3839
m. The mobile station acknowledges the delivery of the short message.4041
n. The serving GSM MSC/VLR sends the result of the Forward Short Message to the IIF.4243
At this point, the IIF clears the MWN flag. The reception of the Forward Short Message Result44without error indicates that the MWN information was delivered successfully to the Mobile45Station.46
X.S0023
2-125
4.12.1.2 ANSI-41 Qualification Directive mapped to GSM SMS1
23456789
1011121314151617
Figure 95: ANSI-41 Qualification Directive mapped to GSM SMS18a. The Voice Mail System (VMS) receives a voice mail for a specific subscriber.19
20b. The VMS send the “Message Waiting Notification” (MWN) to the ANSI-41 HLR of the voice mail21
recipient. Note that the interface between the VMS and the ANSI-41 HLR is not standardized in22ANSI-41 [2].23
24c. Since the subscriber has a current valid location stored in the HLR, the HLR initiates a25
Qualification Directive message with the MWN information to the IIF acting as the serving26ANSI-41 MSC/VLR. The MWN information consists of two parameters:27MessageWaitingNotificationCount (MWNCOUNT) and MessageWaitingNotificationType28(MWNTYPE). For a description of these parameters, see to the ANSI-41-D specifications,29sections 6.5.2.78 and 6.5.2.79 [2].30
31At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification32is to be delivered to the Mobile Station.33
34d. The IIF sends the result of the Qualification Directive message to the ANSI-41 HLR.35
36e. The IIF also originates an SMS with MWN information by sending a Forward Short Message to37
the serving GSM MSC/VLR. The IIF is then acting as a GSM SMS-GMSC. The IIF is to encode38
ANSI-41HLR
QUALDIR (MWNCOUNT,MWNTYPE)
Forw.ShortMessage
SMS Delivery Ack
FORW.SHORTMESSAGE (MWN)
qualdir
“Message WaitingNotification”
VmailDelivery
VMS IIF GSMMSC/VLR MS
a
b
c
d
e
f
g
h
SMS Delivery (MWN)
X.S0023
2-126
the MWN information in the SMS with three methods, namely, UDH, DCS, and CPHS. See to1Volume 3 for the encoding details.2
3f. The serving GSM MSC/VLR sends the short message with the MWN information to the mobile4
station.56
g. The mobile station acknowledges the delivery of the short message.78
h. The serving GSM MSC/VLR sends the result of the Forward Short Message to the IIF.910
At this point, the IIF clears the MWN flag. The reception of the Forward Short Message Result11without error indicates that the MWN information was delivered successfully to the Mobile12Station.13
X.S0023
2-127
4.12.1.3 Handling when GSM MSC/VLR only supports GSM Phase 1 (MAP V1)1
After the IIF has received a Qualification Directive message with MWN information or received the2MWN information through a Registration Notification Return Result, a Forward Short Message with3MWN information needs to be sent to the serving GSM MSC/VLR. This was shown in Sections44.12.1.1 and 4.12.1.2. However, it is possible that the serving GSM MSC/VLR does not support the5MAP V2 Application Context. In this case, the IIF shall receive an ABORT message and shall re-6send the Forward Short Message with MWN information using MAP V1 instead of MAP V2. This is7illustrated in the following diagram.8
9
1011121314151617181920212223
Figure 96: Handling when GSM MSC/VLR only supports GSM Phase 1 (MAP V1)24a. The IIF receives Message Waiting Notification (MWN) information from a Qualification Directive25
or a Registration Notification Return Result. This was described in Sections 4.12.1.1 and264.12.1.2.27At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification28is to be delivered to the Mobile Station.29
30b. The IIF originates an SMS with MWN information by sending Forward Short Message using31
MAP V2 to the serving GSM MSC/VLR. The IIF is then acting as a GSM SMS-GMSC. The IIF is32to encode the MWN information in the SMS with three methods, namely, UDH, DCS, and33CPHS.34
35c. Since the serving GSM MSC/VLR does not support the MAP V2 Application Context, it returns36
an Abort message to the IIF.3738
d. The IIF then re-sends a Forward Short Message with MWN information to the serving GSM39MSC/VLR, but this time using MAP V1. In this case, the MWN information can be encoded with40only two encoding methods, namely, DCS and CPHS.41
42e. The serving GSM MSC/VLR sends the short message with the MWN information to the mobile43
station.44
GSMMSC/VLR
MWN “Information”
FORW.SHORTMSG (MWN) – V1
FORW.SHORTMSG (MWN) – V2
Forw.ShortMessage
SMS Delivery Ack
SMS Delivery (MWN)
IIF MS
a
b
cc
d
e
f
g
ABORT
X.S0023
2-128
1f. The mobile station acknowledges the delivery of the short message.2
3g. The serving GSM MSC/VLR sends the result of the Forward Short Message to the IIF.4
5At this point, the IIF clears the MWN flag. The reception of the Forward Short Message Result6without error indicates that the MWN information was delivered successfully to the Mobile7Station.8
X.S0023
2-129
4.12.1.4 Handling at SMS delivery failure at the IIF1
This section describes the case where the error occurs at the IIF, for example, an unrecognized2Mobile Identity Number (MIN).3
4
5
6
7
8
9
10
11
12
Figure 97: Handling at SMS delivery failure at the IIF13a. The Voice Mail System (VMS) receives a voice mail for a specific subscriber.14
15b. The VMS send the “Message Waiting Notification” (MWN) to the ANSI-41 HLR of the voice mail16
recipient. Note that the interface between the VMS and the ANSI-41 HLR is not standardized in17ANSI-41 [2].18
19c. Since the subscriber has a current valid location stored in the HLR, the HLR initiates a20
Qualification Directive message with the MWN information to the IIF acting as the serving21ANSI-41 MSC/VLR. The MWN information consists of two parameters:22MessageWaitingNotificationCount (MWNCOUNT) and MessageWaitingNotificationType23(MWNTYPE). For a description of these parameters, see to the ANSI-41-D specifications,24sections 6.5.2.78 and 6.5.2.79 [2].25
26d. An error is encountered so that the IIF cannot process the Qualification Directive message and27
sends a Return Error message to the ANSI-41 HLR with the proper error code as per ANSI-4128Specifications, Chapter 6, Section 4.32.2, Table 42 [2].29
Vmail Delivery
“Message WaitingNotification”
Qualdir Return Error
QUALDIR (MWNCOUNT),MWNTYPE)
VMS IIF
a
b
cc
ANSI-41HLR
X.S0023
2-130
4.12.1.5 Handling at SMS delivery failure at the MSC/VLR or at the Mobile Station1
The IIF is to keep a Message Waiting Notification (MWN) flag for each subscriber in its database. In2the event of a failure to deliver a short message with MWN to the mobile station, the IIF is to keep3the MWN flag set. Another Forward Short Message with MWN information shall be sent, triggered4by the reception of a subsequent GSM Update Location message, a Ready for Short Message, or a5Note MS Present message. This is illustrated in the following diagram.6
7
89
10111213141516171819202122232425262728293031
Figure 98: Handling at SMS delivery failure at the MSC/VLR or at the MS32
“Acknowledgement”
NOTE MS PRES – V1
READY FOR SM(AlertReason) -V2
UPDATE LOCATION
Time elapsed
Error, Abort,Reject, timeout
MWN “Information”
FORW.SHORTMSG (MWN) – V2
FORW.SHORTMSG (MWN) – V2
Forw.ShortMessage
SMS Delivery Error
SMS Delivery (MWN)
IIFGSMMSC/VLR
MS
a
b
cc
d
e
f
g
h
i
jh
k
l
m
n
SMS Delivery Ack
SMS Delivery (MWN)
X.S0023
2-131
a. The IIF receives Message Waiting Notification (MWN) information from a Qualification Directive1or a Registration Notification Return Result. This was described in Sections 4.12.1.1 and24.12.1.2.3At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification4is to be delivered to the Mobile Station.5
6b. The IIF originates an SMS with MWN information by sending Forward Short Message using7
MAP V2 to the serving GSM MSC/VLR. The IIF is then acting as a GSM SMS-GMSC. The IIF is8to encode the MWN information in the SMS with three methods, namely, UDH, DCS, and9CPHS. See to Volume 3 for the encoding details.10
11c. The serving GSM MSC/VLR may attempt to deliver the short message or may immediately find12
out that there is an error and reply (step e below) to the IIF.1314
d. The Mobile Station returns an error message to the SMS delivery.1516
e. The serving GSM MSC/VLR sends an Error, Abort or Reject message to the IIF, either resulting17from the reception of an error message from the MS or from an internal event such as an error18or a timeout. Note also, that a timeout may also occur in the IIF itself. Note that this may result19in the IIF setting the GSM 03.40 MNRF/MCEF flag depending on the error cause received (see20section 4.11.3.3 “Unsuccessful Mobile Terminated Delivery (Failure at MSC)”.21
22f. Time elapsed.23
24g. A new serving GSM MSC/VLR sends an Update Location message to the IIF acting as a GSM25
HLR for that subscriber. Note that the normal Update Location sequence is not shown in this26diagram. Or it could be a27
28h. Ready for Short Message (MAP V2) or a29
30i. Note MS Present Message (MAP V1)31
32j. The IIF shall reply with the corresponding acknowledgement message. Note that in the case of33
the Note MS Present message, there shall be no acknowledgement. Upon receipt of g, h, or i34above, the procedures in section 4.11.3.5 “Alerting for an ANSI-41Subscriber in GSM Foreign35Mode” apply (GSM 03.40 flags may be cleared and the SMSNOT may be sent to the MC if36appropriate).37
38k. Triggered by event g, h, or i above, the IIF originates a new Forward Short Message with MWN39
information to the serving GSM MSC/VLR. The IIF is to encode the MWN information in the40SMS with three methods, namely, UDH, DCS, and CPHS. See to Volume 3 for the encoding41details.42
43l. The serving GSM MSC/VLR sends the short message with the MWN information to the mobile44
station.4546
m. The mobile station acknowledges the delivery of the short message.4748
n. The serving GSM MSC/VLR sends the result of the Forward Short Message to the IIF.49At this point, the IIF clears the MWN flag. The reception of the Forward Short Message Result50without error indicates that the MWN information was delivered successfully to the Mobile51Station.52
X.S0023
2-132
4.12.2 ANSI-41 Foreign Mode1For the native GSM subscribers roaming in ANSI-41 networks, there are two implementation2options. The GSM SMS containing the Message Waiting Notification information is either converted3by the IIF to a ANSI-41 Qualification Directive with Message Waiting Notification information as4shown in Section 4.12.2.1, or converted to a GHOST/WEMT ANSI-41short message as shown in5Section 4.12.2.2.6
4.12.2.1 GSM SMS mapped to ANSI-41 Qualification Directive7
8
VmailDelivery
FORW. MOBILE TERM SM (MWN)
SEND ROUTINGINFO FOR SM (MWN)
Send Routing Info for SM
FORW. SHORT MESSAGE (MWN)
QUALDIR(MWNCOUNT,MWNTYPE)
(MWN delivered toMobile Station)
Qualdir
Forw. Short Message (error: absent sub.)
Forw. Mobile Term SM (error)
GSMSC
GSMSMS-
GMSC
GSMHLR IIF
ANSI-41MSC
a
b
c
d
e
f
g
h
i
jReport SM (error)DeliveryStatus k9
10
Figure 99: GSM SMS mapped to ANSI-41 Qualification Directive11a. The GSM Service Center (SC) receives a voice mail for a specific subscriber.12
13b. The SC sends the Forward Mobile Terminating Short Message with Message Waiting14
Notification (MWN) information to the GSM SMS-GMSC.1516
c. The GSM SMS-GMSC enquires about the subscriber location by sending the Send Routing17Information For Short Message to the HLR.18
19d. The HLR replies with the Send Routing Information For Short Message result. It is assumed that20
the native GSM subscriber has already made a registration in the ANSI-41 MSC/VLR.2122
e. The GSM SMS-GMSC originates an SMS with MWN information by sending Forward Short23Message to IIF then acting as a serving GSM MSC/VLR. This requires GSM MAP phase 2 or24higher.25
26
X.S0023
2-133
At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification1is to be delivered to the Mobile Station. If the GSM SMS-GMSC only supports GSM MAP phase21 and delivers MWN via pure text SMS, then a pure text SMS shall be delivered to the IIF. The3IIF shall then translate it into a CMT or GHOST/WEMT ANSI-41 SMS. Note that this then4becomes a simple SMS mapping covered in Section 4.12.2.2.5
6f. Upon reception of the Forward Short Message with MWN information, the IIF shall initiate a7
Qualification Directive message with MWN information to the serving ANSI-41 MSC/VLR. The8IIF is then acting as an ANSI-41 HLR. The MWN information consists of two parameters:9MessageWaitingNotificationCount (MWNCOUNT) and MessageWaitingNotificationType10(MWNTYPE). For a description of these parameters, see to the ANSI-41-D specifications11sections 6.5.2.78 and 6.5.2.79 [2]. Alternatively, a GHOST/WEMT short message could be sent12instead of the Qualification Directive message (see Section 4.12.2.2) if the IIF has the possibility13to confirm that the Mobile Station is SMS-capable.14
15g. In this step, the MWN information shall be delivered to the mobile station.16
17h. The serving ANSI-41 MSC/VLR sends the Qualification Directive Return Result to the IIF. Note18
that this result message does not guaranty that the MWN information was delivered19successfully to the Mobile Station, it just means that the MSC/VLR received the Qualification20Directive message, therefore the MWN flag shall not be cleared at this point by the IIF.21
22i. The IIF sends the result of the Forward Short Message to the GSM SMS-GMSC with error code23
“absent subscriber” so that the home system assumes that the delivery failed in case the24subscriber goes back to the home system without having retrieved the mail messages. This25way, at the reception of the Update Location message, the HLR shall send an Alert-SC26message so that the MWN information (in a short message) is once again sent to the Mobile27Station.28
29j. The SMS-GMSC sends the result of the Forward Mobile Terminating Short Message to the30
Service Center. Note that depending on the Service Center implementation, this may cause the31SMS to be re-sent periodically instead of waiting for the ALERTSC message indicating that the32subscriber is again available to receive short messages.33
34k. The SMS-GMSC reports the error to the HLR, which shall set the proper flags as per GSM35
03.40 [35] so that an Alert-SC message is sent when necessary as explained in step i above.36
X.S0023
2-134
4.12.2.2 GSM SMS mapped to ANSI-41 SMS using GHOST or WEMT Teleservice1
This method uses the tunneling concept. Instead of translating the GSM SMS with Message Waiting2Notification information to an ANSI-41 Qualification Directive with MWN information, the IIF shall3package the GSM SMS into an ANSI-41SMS with the new teleservice GHOST (GSM Hosted SMS4Teleservice)/WEMT.5
Event g only works with Mobile Stations (MS) capable of handling GHOST or WEMT. The MS shall6remove the ANSI-41part of the message (the envelope) and send the GSM SMS Packet Data Units7(PDU) to the GSM part of the mobile station to handle the GSM SMS, in this case, containing the8Message Waiting Notification information. Specifically, the ANSI-41 MSC shall convert the SMDPP9to an R-DATA message which has a HLPI (higher layer protocol identifier) that indicates10GHOST/WEMT. The payload of the R-DATA message is the GSM SMS which is effectively11identified as the target application whenever HLPI = GHOST/WEMT.12
GSMSC
GSMSMS-GMSC
GSMHLR IIF
ANSI-41MSC
a
b
c
d
e
f
g
h
i
j
FORW.MOBILE TERM SM(MWN) SEND
ROUTINGINFO FOR SM(MWN) SendRouting Info for SMFORW. SHORT MESSAGE(MWN)
SMDPP (MWN)
(SMS deliveredtoMobile Station)
smdpp(GHOST)
Forw. Mobile Term SM
VmailDelivery
Forw. Short Message
1314
Figure 100: GSM SMS mapped to ANSI-41 using GHOST/WEMT Teleservice15a. The GSM Service Center (SC) receives a voice mail for a specific subscriber.16
17b. The SC sends the Forward Mobile Terminating Short Message with Message Waiting18
Notification (MWN) information to the GSM SMS-GMSC.1920
c. The GSM SMS-GMSC inquires about the subscriber location by sending the Send Routing21Information For Short Message to the HLR.22
23d. The HLR replies with the Send Routing Information For Short Message result. It is assumed that24
the native GSM subscriber has already made a registration in the ANSI-41 MSC/VLR.25
X.S0023
2-135
1e. The GSM SMS-GMSC originates an SMS with MWN information by sending Forward Short2
Message to IIF then acting as a serving GSM MSC/VLR.34
This requires GSM MAP phase 2 or higher. If the GSM SMS-GMSC only supports GSM MAP5phase 1 and delivers MWN via pure text SMS, then a pure text SMS shall be delivered to the6IIF. The IIF shall then translate it into a CMT or GHOST/WEMT ANSI-41 SMS. Note that this7then becomes a simple SMS mapping covered in Section 4.11.8
9f. Upon reception of the Forward Short Message with MWN information, the IIF shall initiate a10
Short Message Delivery Point to Point with Teleservice GHOST/WEMT to the serving ANSI-4111MSC/VLR. The IIF is then acting as an ANSI-41Message Center (MC). Inside of this12GHOST/WEMT short message is the GSM short message containing the MWN information.13
14g. In this step, the GHOST/WEMT Short Message containing the GSM short message containing15
the MWN information shall be delivered to the mobile station.1617
h. The serving ANSI-41 MSC/VLR sends the Short Message Delivery Point to Point Return Result18to the IIF.19
20i. The IIF sends the result of the Forward Short Message to the GSM SMS-GMSC.21
22j. The SMS-GMSC sends the result of the Forward Mobile Terminating Short Message to the23
Service Center.24
X.S0023
2-136
4.12.2.3 Clearing of MWN Information after Retrieval of Messages while in ANSI-411Foreign Mode – QualDir Method2
This section describes the case where the messages are retrieved while a GSM subscriber is still3roaming in ANSI-41 foreign mode.4
5
QUALDIR(MWNCOUNT, MWNTYPE)
( mwn delivered to Mobile Station)
Qualdir
ANSI-41 MSC
f
g
h
i
j
Vmail Retrieval
FORW. MOBILE TERM SM ( mwn)
SEND ROUTING INFO FOR SM ( mwn) Send Routing Info for SM FORW. SHORT MESSAGE ( mwn)
Forw . Short Message (error: absent sub.) Forw . Mobile Term SM (error)
GSM SC
GSM SMS- GMSC
GSM HLR IIF
a
b
c
d
e
k Report SM (error) DeliveryStatus
67
Figure 101: Clearing of MWN Information after Retrieval of Messages while in ANSI-418Foreign mode – Qualdir Method9
a. The voice mail messages are retrieved from the GSM subscriber.1011
b. The SC sends the Forward Mobile Terminating Short Message with Message Waiting12Notification (MWN) information set to “clear” to the GSM SMS-GMSC.13
14c. The GSM SMS-GMSC enquires about the subscriber location by sending the Send Routing15
Information For Short Message to the HLR.1617
d. The HLR replies with the Send Routing Information For Short Message result. It is assumed that18the native GSM subscriber has already made a registration in the ANSI-41 MSC/VLR. Another19requirement is that the Service Center sets the priority of this SMS to “high” to make sure that20the SMS is sent (Section 3.2.5 of GSM 03.40). This is necessary since the IIF had previously21responded with absent subscriber and the HLR had set some flags that could have prevented22the delivery of this new SMS.23
24e. The GSM SMS-GMSC originates an SMS with MWN information (set to “clear”) by sending25
Forward Short Message to IIF then acting as a serving GSM MSC/VLR. This requires a GSM26phase 2 support or higher.27
X.S0023
2-137
1f. Upon reception of the Forward Short Message with MWN information (set to “clear”), the IIF2
shall initiate a Qualification Directive message with MWN information (set to “clear”) to the3serving ANSI-41 MSC/VLR. The IIF is then acting as an ANSI-41 HLR. The MWN information4consists of two parameters: MessageWaitingNotificationCount (MWNCOUNT) and5MessageWaitingNotificationType (MWNTYPE). For a description of these parameters, see to6the ANSI-41-D specifications, sections 6.5.2.78 and 6.5.2.79 [2].7
8g. In this step, the MWN information (set to “clear”) shall be delivered to the mobile station.9
10h. The serving ANSI-41 MSC/VLR sends the Qualification Directive Return Result to the IIF. Note11
that this result message does not guaranty that the MWN information (set to ”clear”) was12delivered successfully to the Mobile Station, it just means that the MSC/VLR received the13Qualification Directive message, so the MWN flag shall not be cleared at this point by the IIF.14
15i. The IIF sends the result of the Forward Short Message to the GSM SMS-GMSC with error code16
“absent subscriber” so that the home system assumes that the delivery failed in case the17subscriber goes back to the home system without having received the clearing notification from18the serving MSC. This way, at the reception of the Update Location message, the HLR shall19send an Alert-SC message so that the MWN information (in a short message) is once again20sent to the Mobile Station.21
22j. The SMS-GMSC sends the result of the Forward Mobile Terminating Short Message to the23
Service Center. Note that depending on the Service Center implementation, this may cause the24SMS to be re-sent periodically instead of waiting for the ALERTSC message indicating that the25subscriber is again available to receive short messages.26
27k. The SMS-GMSC reports the error to the HLR, which shall set the proper flags as per GSM28
03.40 [35] so that an Alert-SC message is sent when necessary as explained in step i above.29
X.S0023
2-138
4.12.2.4 Handling at SMS delivery failure at the IIF1
SMDPP (GHOST,WEMT)
smdpp error
f
g
h
i
j
VmailRetrieval
FORW. MOBILE TERM SM (mwn)
SEND ROUTINGINFO FOR SM (mwn)
Send Routing Info for SM
FORW. SHORT MESSAGE (mwn)
Forw. Short Message (error)Forw. Mobile Term.
SM (error)
GSMSC
GSMSMS-
GMSC
GSMHLR IIF
a
b
c
d
e
k
Report SM (error)Delivery Status
ANSI-41MSC
23
Figure 102: Handling at SMS delivery failure at the IIF4a. The GSM Service Center (SC) receives a voice mail for a specific subscriber.5
6b. The SC sends the Forward Mobile Terminating Short Message with Message Waiting7
Notification (MWN) information to the GSM SMS-GMSC.89
c. The GSM SMS-GMSC enquires about the subscriber location by sending the Send Routing10Information For Short Message to the HLR.11
12d. The HLR replies with the Send Routing Information For Short Message result. It is assumed that13
the native GSM subscriber has already made a registration in the ANSI-41 MSC/VLR.1415
e. The GSM SMS-GMSC originates an SMS with MWN information by sending Forward Short16Message to IIF then acting as a serving GSM MSC/VLR.17
18f. Upon reception of the Forward Short Message with MWN information, the IIF encounters an19
error and sends the result of the Forward Short Message to the GSM SMS-GMSC with the20proper error code as per GSM Specifications 09.02 [4].21
22g. The SMS-GMSC sends the result of the Forward Mobile Terminating Short Message to the23
Service Center.24
X.S0023
2-139
1h. The SMS-GMSC reports the error to the HLR, which sets the proper flags as per GSM 03.40 [4]2
so that an Alert-SC message is sent when necessary.3
X.S0023
2-140
4.12.2.5 Handling at SMS delivery failure at the MSC/VLR – QualDir Method1
2
VmailDelivery
FORW. MOBILE TERM SM (MWN)
SEND ROUTINGINFO FOR SM (MWN)
Send Routing Info for SM
FORW. SHORT MESSAGE (MWN)
QUALDIR(MWNCOUNT,MWNTYPE)
Qualdir Return Error
GSMSC
GSMSMS-
GMSC
GSMHLR IIF
ANSI-41MSC
a
b
c
d
e
f
g
h
i
Forw. Short Message (error)
Forw. Mobile Term SM (error)
jReport SM (error)DeliveryStatus
34
Figure 103: Handling at SMS delivery failure at the MSC/VLR Qualdir Method5a. The GSM Service Center (SC) receives a voice mail for a specific subscriber.6
7b. The SC sends the Forward Mobile Terminating Short Message with Message Waiting8
Notification (MWN) information to the GSM SMS-GMSC.910
c. The GSM SMS-GMSC inquires about the subscriber location by sending the Send Routing11Information for Short Message to the HLR.12
13d. The HLR replies with the Send Routing Information for Short Message result. It is assumed that14
the native GSM subscriber has already made a registration in the ANSI-41 MSC/VLR.1516
e. The GSM SMS-GMSC originates an SMS with MWN information by sending Forward Short17Message to IIF then acting as a serving GSM MSC/VLR. This requires GSM phase 2 support or18higher.19At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification20is to be delivered to the Mobile Station.21
22f. The IIF shall also initiate a Qualification Directive message with MWN information to the serving23
ANSI-41 MSC/VLR. The IIF is then acting as an ANSI-41 HLR. The MWN information consists24of two parameters: MessageWait ingNoti f icat ionCount (MWNCOUNT) and25MessageWaitingNotificationType (MWNTYPE). For a description of these parameters, see to26the ANSI-41-D specifications, sections 6.5.2.78 and 6.5.2.79 [2].27
28
X.S0023
2-141
g. The serving ANSI-41 MSC/VLR encounters an error and sends the Qualification Directive1Return Error to the IIF, as per the ANSI-41 Specifications, Chapter 6, Section 4.32.2, Table 42.2
h. The IIF sends the error result of the Forward Short Message to the GSM SMS-GMSC.34
i. The SMS-GMSC sends the result of the Forward Mobile Terminating Short Message to the5Service Center.6
7j. The SMS-GMSC reports the error to the HLR which sets the proper flags as per GSM 03.408
[35] so that an Alert-SC message is sent when necessary.910
X.S0023
2-142
4.12.2.6 Handling at SMS delivery failure at the MSC/VLR – GHOST/WEMT SMS1Method2
SMDPP (GHOST,WEMT)
smdpp error
f
g
h
i
j
VmailRetrieval
FORW. MOBILE TERM SM (mwn)
SEND ROUTINGINFO FOR SM (mwn)
Send Routing Info for SM
FORW. SHORT MESSAGE (mwn)
Forw. Short Message (error)Forw. Mobile Term.
SM (error)
GSMSC
GSMSMS-
GMSC
GSMHLR IIF
a
b
c
d
e
k
Report SM (error)Delivery Status
ANSI-41MSC
34
Figure 104: Handling at SMS delivery failure at the MSC/VLR – GHOST/WEMT SMS Method5a. The GSM Service Center (SC) receives a voice mail for a specific subscriber.6
7b. The SC sends the Forward Mobile Terminating Short Message with Message Waiting8
Notification (MWN) information to the GSM SMS-GMSC.910
c. The GSM SMS-GMSC inquires about the subscriber location by sending the Send Routing11Information for Short Message to the HLR.12
13d. The HLR replies with the Send Routing Information for Short Message result. It is assumed that14
the native GSM subscriber has already made a registration in the ANSI-41 MSC/VLR.1516
e. The GSM SMS-GMSC originates an SMS with MWN information by sending Forward Short17Message to IIF then acting as a serving GSM MSC/VLR. This requires GSM phase 2 support or18higher.19
20f. Upon reception of the Forward Short Message with MWN information, the IIF shall initiate a21
Short Message Delivery Point to Point with Teleservice GHOST/WEMT to the serving ANSI-4122MSC/VLR. The IIF is then acting as an ANSI-41Message Center (MC). Inside of this23GHOST/WEMT short message is the GSM short message containing the MWN information.24
X.S0023
2-143
1g. The serving ANSI-41 MSC/VLR encounters an error and sends the Short Message Delivery2
Point to Point Return error to the IIF.34
h. The IIF sends the result of the Forward Short Message to the GSM SMS-GMSC with the proper5error code. .6
7i. The SMS-GMSC sends the result of the Forward Mobile Terminating Short Message to the8
Service Center.910
j. The SMS-GMSC shall report the error to the HLR.11
X.S0023
2-144
4.12.2.7 GSM SMS mapped to ANSI-41 Qualification Directive and to Registration1Notification Return Result2
3
VmailDelivery
FORW. MOBILE TERM SM (MWN)
SEND ROUTINGINFO FOR SM (MWN)
Send Routing Info for SM
FORW. SHORT MESSAGE (MWN) QUALDIR
(MWNCOUNT,MWNTYPE)
(MWN delivered toMobile Station)
Forw. Short Message (error: absent sub.)
Forw. Mobile Term SM (error)
GSMSC
GSMSMS-GMSC
GSMHLR
IIF ANSI-41MSC 1
a
b
c
d
e
f
g
h
i
jReport SM (error)DeliveryStatus k
l
j
Time elapsed
(MWN delivered toMobile Station)
REGNOT m
n
o
Regnot(MWNCOUNT,MWNTYPE)
ANSI-41MSC 2
45
Figure 105: GSM SMS mapped to ANSI-41 Qualification Directive and to Registration6Notification Return Result7
a. The GSM Service Center (SC) receives a voice mail for a specific subscriber.89
b. The SC sends the Forward Mobile Terminating Short Message with Message Waiting10Notification (MWN) information to the GSM SMS-GMSC11
12c. The GSM SMS-GMSC inquires about the subscriber location by sending the Send Routing13
Information For Short Message to the HLR.1415
d. The HLR replies with the Send Routing Information For Short Message result. It is assumed that16the native GSM subscriber has already made a registration in the ANSI-41 MSC/VLR.17
18
X.S0023
2-145
e. The GSM SMS-GMSC originates an SMS with MWN information by sending Forward Short1Message to IIF then acting as a serving GSM MSC/VLR. This requires GSM phase 2 support or2higher.3At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification4is to be delivered to the Mobile Station. If the handset only supports GSM phase 1, then a pure5text SMS shall be delivered to the IIF. The IIF shall then translate it into a CMT or6GHOST/WEMT ANSI-41 SMS. Note that this then becomes a simple SMS mapping covered in7Section 4.11.8
9f. Upon reception of the Forward Short Message with MWN information, the IIF shall initiate a10
Qualification Directive message with MWN information to the serving ANSI-41 MSC/VLR. The11IIF is then acting as an ANSI-41 HLR. The MWN information consists of two parameters:12MessageWaitingNotificationCount (MWNCOUNT) and MessageWaitingNotificationType13(MWNTYPE). For a description of these parameters, see to the ANSI-41 specifications, sections146.5.2.78 and 6.5.2.79 [2]. Alternatively, a GHOST/WEMT short message could be sent instead15of the Qualification Directive message (see Section 4.12.2.2) if the IIF has the possibility to16confirm that the Mobile Station is SMS-capable.17
18g. In this step, the MWN information shall be delivered to the mobile station.19
20h. The serving ANSI-41 MSC/VLR sends the Qualification Directive Return Result to the IIF. Note21
that this result message does not guaranty that the MWN information was delivered22successfully to the Mobile Station, it just means that the MSC/VLR received the Qualification23Directive message, therefore the MWN flag shall not be cleared at this point by the IIF.24
25i. The IIF sends the result of the Forward Short Message to the GSM SMS-GMSC with error code26
“absent subscriber” so that the home system assumes that the delivery failed in case the27subscriber goes back to the home system without having retrieved the mail messages. This28way, at the reception of the Update Location message, the HLR shall send an Alert-SC29message so that the MWN information (in a short message) is once again sent to the Mobile30Station.31
32j. The SMS-GMSC sends the result of the Forward Mobile Terminating Short Message to the33
Service Center. Note that depending on the Service Center implementation, this may cause the34SMS to be re-sent periodically instead of waiting for the ALERTSC message indicating that the35subscriber is again available to receive short messages.36
37k. The SMS-GMSC reports the error to the HLR, which sets the proper flags as per GSM 03.4038
[35] so that an Alert-SC message is sent when necessary as explained in step i above.3940
l. Time elapses before the MS re-registers.4142
m. A Registration Notification is sent from the serving ANSI-41 MSC 2 to the IIF.4344
n. The IIF discovers that the MWN flag is still set. The IIF sends back the MWN in the Registration45Notification Return Result along with the other registration information (e.g. other Profile46parameters) to the serving ANSI-41 MSC/VLR. The IIF is then acting as an ANSI-41 HLR. The47MWN information consists of two parameters: MessageWaitingNotificationCount (MWNCOUNT)48and MessageWaitingNotificationType (MWNTYPE). For a description of these parameters, see49to the ANSI-41 specifications, sections 6.5.2.78 and 6.5.2.79 [2].50
51o. In this step, the MWN information shall be delivered to the mobile station. Since there is no52
acknowledgement from the regnot Return Result, there is no guarantee that the MWN53
X.S0023
2-146
information was delivered successfully to the Mobile Station. The MWN flag shall not be cleared1at this point by the IIF.2
X.S0023
2-147
4.13 GPRS in GSM Foreign Mode1
This section describes the support of GPRS service for ANSI-41subscribers roaming in a GSM2radio environment.3
To support multiple network configuration requirements this standard defines several optional4capabilities that may be implemented. The scenarios in this section are not exhaustive.5
The services offered are dependent on both the MS capabilities and the users GPRS subscription6data. The services to be provided are provisioned in the IIF by means outside the scope of this7standard. Provisioning in the IIF is required to support both voice and GPRS.8
When an MS is capable of both GSM-CS and GPRS service, it may be attached to the GSM9network through either a GSM MSC (for GSM-CS service) or an SGSN (for GPRS service) or10through both. The attachments may be done in series, i.e. first one service and then another, or11simultaneously.12
The IIF may implement a timer, GPRS_LU, to reduce the number of location updates in the13ANSI-41 network when an MS is capable of both MSC-CS and GPRS services. If the timer is14supported, then when a Location Update is received from the SGSN for an MS that is capable of15both GSM_CS and GPRS service, the IIF starts the timer and then performs the ‘Insert Subscriber16Data’ procedure to the SGSN. The IIF sends the REGNOT to the HLR only after the expiry of the17timer or the receipt of the Location Update from the GSM MSC.18
When the timer is not started, either because :19
- it is not supported; or20
- the MS is provisioned for GPRS only service; or21
- the MS is already CS attached; or22
- the IIF does not support multiple MSCIDs;23
then the IIF sends the REGNOT to the HLR and waits for a response before performing the ‘Insert24Subscriber Data’ procedure to the SGSN.25
The IIF may support multiple MSCIDs to separately identify each GSM MSC and each SGSN when26an MS is attached for either or both services. When multiple MSCIDs are supported the IIF shall27notify the ANSI-41 HLR whenever the MS registers on a different SGSN, GSM MSC or both.28
An IIF that does not support multiple MSCIDs shall always convey its own identity towards the29ANSI-41 HLR.30
Subscriber Data Management procedures shall follow similar procedures as described in 4.4.2. In31the case of subscriber deletion, it shall also result in the deletion of any GPRS subscription data in32the IIF, for that subscriber. In this case, the IIF shall also send a Cancel Location Request to the33serving SGSN. The ANSI-41 HLR does not have the capability to request the modification of GPRS34subscription data in the IIF. Modification of GPRS subscriber data in the IIF shall be in accordance35with GSM 09.02 [4] via an OMC directly connected to the IIF.36
X.S0023
2-148
4.13.1 Location Registration ScenariosIn each of the following scenarios, the following1interactions are not shown:2
Interactions between SGSNs3
Interactions between SGSNs and GGSNs4
Existing procedures defined in GSM 03.60 [33], describing the actions between SGSNs or between5an SGSN and a GGSN for scenarios involving interaction between those functional elements also6apply.7
Existing procedures and timers defined in GSM 03.60 [33], describing the actions between the8SGSN and the GSM HLR also apply between the SGSN and the IIF (emulating a GSM HLR).9
The combined attach and location registration procedures described, require support of the optional10Gs interface as described in GSM 03.60[33].11
It should be noted that certain scenarios may only be relevant to certain MS types. For a full12description of the various MS types see GSM 03.60 [33].13
4.13.1.1 GPRS Attach (not currently registered)14
If an MS requests GPRS service when currently not registered in the IIF, the MS performs a GPRS15attach request using its IMSI. The IIF acts like a GPRS HLR/AuC in this case. The subscriber's16ANSI-41 HLR has no knowledge of this request, but the IIF makes it aware of the attachment to an17SGSN via a REGNOT. If timer GPRS_LU is used then the message flow is as shown in Figure18106. If timer GPRS_LU is not used then the message flow is as shown in Figure 107.119
X.S0023
2-149
MS SGSN IIF HLRGPRS AttachReq. (IMSI)
Authentication Info
Authentication Info Ack
Authentication Req
AuthenticationRes
Update GPRS Location Req
GSM NETWORK ANSI-41 NETWORK
Insert Sub Data
Insert Sub Data Ack
Update GPRS Location Ack
GPRS Attach Ack
(IMSI, SGSN Address)
a
b
c
d
e
f
g
h
i
jREGNOT
regnotk
GPRS_LU
l
1Figure 106: GPRS Attach (Option1: with timer)2
a. MS performs a GPRS Attach.3
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to4perform authentication i.e. authentication triplets, it requests authentication information from the5IIF. The IIF emulates a GSM HLR/AuC in this case supporting GPRS.6
c. The IIF returns the necessary authentication information, if applicable.7
d. SGSN initiates authentication towards the MS.8
e. MS responds to the authentication request.9
f. SGSN initiates a MAP GPRS location update towards the IIF. The Update GPRS Location10Request contains the IMSI.11
g. The IIF validates whether the GPRS service request is authorized. Since GPRS service is12requested, and the subscriber is currently PS-deregistered, it initiates the GSM MAP Insert13Subscriber Data Procedure towards the SGSN after the subscriber has been successfully14authorized. This procedure is used to download GPRS subscriber data to the SGSN. Multiple15Insert Subscriber Data transactions may be necessary to complete the transfer of subscriber16data to the SGSN.17
h. The SGSN acknowledges the ISD Operation(s).18
X.S0023
2-150
i. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF1returns an acknowledgement to the Update GPRS Location Request.2
j. After the IIF’s GPRS_LU timer expires, the IIF shall send a registration notification (REGNOT)3to the ANSI-41 HLR. The REGNOT shall contain the MSID (MIN/IMSI), the ESN , the MSCID ,4etc. If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber5shall be passed in the REGNOT to the subscriber’s HLR. The ANSI-41 HLR records the6address of the IIF as the serving ANSI-41 MSC. Although call delivery may not be possible,7SMS delivery is made possible by registering the IIF as the ANSI-41 MSC with the ANSI-418HLR.9
k. The ANSI-41 HLR sends an acknowledgment to the registration with a regnot. The IIF may10ignore the CS-related profile information, since the subscriber is only GPRS-attached (and not11GSM CS-attached). Only the provisioned SMS parameters in the regnot (profile) may be12mapped and sent to the SGSN in an Insert Subscriber Data message (e.g., as in the next13figure). (Alternatively, SMS parameters related to GPRS could be provisioned directly on the IIF14and sent to the SGSN in step g.)15
If a negative regnot response is received from the ANSI-41 HLR, (then as a Network option) the16IIF may perform an initiated detach procedure as described in section 4.13.2.6.17
l. The SGSN acknowledges the GPRS Attach Request.18
MS SGSN IIF HLR
GPRS Attach Req
Authentication Info
Authentication Info Ack
Authentication Req
Authentication Res
Update GPRS Location Req
GSM NETWORK ANSI-41 NETWORK
(IMSI)
(IMSI, SGSN Address)
a
b
c
d
e
f
gREGNOT
Insert Sub Data
Insert Sub Data Ack
Update GPRS Location Ack
GPRS Attach Accept
h
i
j
Regnot ack
k
l
19Figure 107: GPRS Attach (Option 2: without timer)20
21
X.S0023
2-151
a. MS performs a GPRS Attach.1
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to2perform authentication i.e. authentication triplets, it requests authentication information from the3IIF. The IIF emulates a GSM HLR/AuC in this case supporting GPRS.4
c. The IIF returns the necessary authentication information, if applicable.5
d. SGSN initiates authentication towards the MS.6
e. MS responds to the authentication request.7
f. SGSN initiates a MAP GPRS location update towards the IIF. The Update GPRS Location8Request contains the IMSI.9
g. The REGNOT shall contain the MSID (MIN/IMSI), the ESN, the MSCID etc. If SIM-based10roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall be passed in11the REGNOT to the subscriber’s HLR. The ANSI-41 HLR records the address of the IIF as the12serving ANSI-41 MSC. Although call delivery may not be possible, SMS delivery is made13possible by registering the IIF as the ANSI-41 MSC with the ANSI-41 HLR.14
h. The ANSI-41 HLR sends an acknowledgment to the registration with a regnot. The IIF may15ignore the CS-related profile information, since the MS is only GPRS-attached (and not GSM16CS-attached). Only the provisioned SMS parameters in the regnot (profile) may be mapped17and sent to the SGSN in an Insert Subscriber Data message.18
i. The IIF validates whether the GPRS service request is authorized. Since GPRS service is19requested, and the subscriber is currently PS-deregistered, it initiates the GSM MAP Insert20Subscriber Data Procedure towards the SGSN after the subscriber has been successfully21authorized. This procedure is used to download GPRS subscriber data to the SGSN. Multiple22Insert Subscriber Data transactions may be necessary to complete the transfer of subscriber23data to the SGSN.24
j. The SGSN acknowledges the ISD Operation(s).25
k. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF26returns an acknowledgement to the Update GPRS Location Request.27
l. The SGSN acknowledges the GPRS Attach request.28
X.S0023
2-152
GPRS Attach when currently registered in an ANSI-41 network1
If an MS requests GPRS service when currently registered in an ANSI-41 network, the SGSN sends2an Update GPRS location update using its IMSI. The IIF acts like a GPRS HLR/AuC and an3ANSI-41 VLR in this case. To the subscriber's ANSI-41 HLR, the subscriber becomes registered on4the IIF acting as an ANSI-41 MSC. If timer GPRS_LU is used then the message flow is as shown in5Figure 108. If timer GPRS_LU is not used then the message flow is as shown in Figure 109.6
GPRS Attach Req
MS
Authentication Req
Authentication Res
(IMSI)a
b
c
d
e
f
g
h
i
j
k
l
m
nGPRS Attach Accept
o
Update GPRS Location Req (IMSI)
SGSNMSC IIF
Authentication Info
Authentication Info Ack
Insert Sub Data
Insert Sub Data Ack
HLR
Update gprs location ack
GPRS_LU
REGNOT
Regnot ack
PMSC/VLR
REGCANC
regcanc
GSM NETWORK ANSI-41 NETWORK7
Figure 108: GPRS Attach when currently registered in ANSI-41 (Option 1: with timer)89
a. MS performs a GPRS Attach.10
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to11perform authentication i.e. authentication triplets, it requests authentication information from the12IIF. The IIF emulates a GSM HLR/AuC in this case supporting GPRS.13
c. The IIF returns the necessary authentication information, if applicable.14
d. SGSN initiates authentication towards the MS.15
e. MS responds to the authentication request.16
f. SGSN initiates a MAP GPRS location update towards the IIF. The Update GPRS Location17Request contains the IMSI.18
X.S0023
2-153
g. The IIF validates whether the GPRS service request is authorized. Since GPRS service is1requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert2Subscriber Data Procedure towards the SGSN after the subscriber has been successfully3authorized. This procedure is used to download GPRS subscriber data to the SGSN. Multiple4Insert Subscriber Data transactions may be necessary to complete the transfer of subscriber5data to the SGSN.6
h. The SGSN acknowledges the ISD Operation(s).7
i. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the8IIF returns an acknowledgement to the Update GPRS Location Request.9
j. After the IIF’s GPRS_LU timer expires, the IIF shall send a registration notification (REGNOT)10to the ANSI-41 HLR. The REGNOT shall contain the MSID (MIN/IMSI), the ESN, the MSCID,11etc. If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber12shall be passed in the REGNOT to the subscriber’s HLR. The ANSI-41 HLR records the13address of the IIF as the serving ANSI-41 MSC. Although call delivery may not be possible,14SMS delivery is made possible by registering the IIF as the ANSI-41 MSC with the ANSI-4115HLR.16
k. The ANSI-41 HLR updates its location information and deletes the previous VLR record by17sending a REGCANC to the previous MSC/VLR.18
l. The VLR acknowledges the REGCANC.19
m. The ANSI-41 HLR sends an acknowledgment to the registration with a regnot. The IIF may20ignore the CS-related profile information, since the MS is only GPRS-attached (and not GSM21CS-attached).22
If a negative regnot response is received from the ANSI-41 HLR, (then as a Network option)23the IIF may perform an initiated detach procedure as described in section 4.13.2.6.24
n. The SGSN acknowledges the GPRS Attach request.25
X.S0023
2-154
MS SGSN IIF HLR
GPRS Req (IMSI)ffRRReAttach Authentication Info
Authentication
InfoAck
Authentication Req
Authentication Res
Update GPRS Location Req (IMSI, SGSN Address)
REGNOT (MSID, ESN MSCID or MSCIN)
regnot
GSM NETWORK ANSI-41 NETWORK
Insert SubData
Insert Sub AckDataUpdate GPRSLocation
Ack
GPRS Ack
MSC/VLR
REGCAN
regcan
a
b
c
d
e
f
g
h
i
j
k
l
m
n
GPRS_LU
12
Figure 109: GPRS Attach when currently registered in ANSI-41 (Option 2: without timer)34
a. MS performs a GPRS Attach.5
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to6perform authentication i.e. authentication triplets, it requests authentication information from the7IIF. The IIF emulates a GSM HLR/AuC in this case supporting GPRS.8
c. The IIF returns the necessary authentication information, if applicable.9
d. SGSN initiates authentication towards the MS.10
e. MS responds to the authentication request.11
f. SGSN initiates a MAP GPRS location update towards the IIF. The Update GPRS Location12Request contains the IMSI.13
g. The REGNOT shall contain the MSID (MIN/IMSI), the ESN, the MSCID, etc. If SIM-based14roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall be passed in15
X.S0023
2-155
the REGNOT to the subscriber’s HLR. The ANSI-41 HLR records the address of the IIF as the1serving ANSI-41 MSC. Although call delivery may not be possible, SMS delivery is made2possible by registering the IIF as the ANSI-41 MSC with the ANSI-41 HLR.3
h. The ANSI-41 HLR updates its location information and deletes the previous VLR record by4sending a REGCANC to the previous MSC/VLR.5
i. The VLR acknowledges the REGCANC.6
j. The ANSI-41 HLR sends an acknowledgment to the registration with a regnot.7
k. The IIF validates whether the GPRS service request is authorized. Since GPRS service is8requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert Subscriber9Data Procedure towards the SGSN after the subscriber has been successfully authorized. This10procedure is used to download GPRS subscriber data to the SGSN. Multiple Insert Subscriber11Data transactions may be necessary to complete the transfer of subscriber data to the SGSN.12
l. The SGSN acknowledges the ISD Operation(s).13
m. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF14returns an acknowledgement to the Update GPRS Location Request.15
n. The SGSN acknowledges the GPRS Attach request.1617
X.S0023
2-156
4.13.1.3 Inter-SGSN routing area update1
If an MS requests a GPRS routing area update while registered on a GPRS SGSN only. The2message flow is as shown in Figure 110 and 111, depending on whether the timer GPRS_LU is3supported on the IIF.4
Figure 110: Inter-SGSN routing area update (Option 1: with timer)5
a. MS sends a Routing Area Update request.6
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to7perform authentication i.e. authentication triplets, it requests authentication information from the8IIF. The IIF emulates a GSM HLR/AuC in this case supporting GPRS.9
c. The IIF returns the necessary authentication information, if applicable.10
d. SGSN initiates authentication towards the MS.11
e. MS responds to the authentication request.12
f. SGSN initiates a MAP GPRS location update towards the IIF. The Update GPRS Location13Request contains the IMSI. The IIF starts the GPRS_LU timer.14
inter-SGSN Routing Area Update
MS
Authentication Req
Authentication Res
(IMSI) a b
c
d e
f Update GPRS Location Req (IMSI)
SGSN IIF
Authentication Info Authentication Info Ack
HLR Prev SGSN
f
g
h
i
j
k
l
m
n
Insert Sub Data
Insert Sub Data Ack
Update gprs location ack
g
h
i
j
k
l
m
REGNOT
Regnot ack
Cancel Location
Cancel Location Ack
o
regcanc
REGCANC
GPRS NETWORK GPRS NETWORK ANSI-41
GPRS_LU
inter-SGSN Routing Area Update Accept p
X.S0023
2-157
g. The IIF (acting like a GPRS HLR) shall also send a Cancel Location to the previous SGSN.1
h. The IIF shall receive a Cancel Location acknowledgement from the previous SGSN.2
i. The IIF validates whether the GPRS service request is authorized. Since GPRS service is3requested, it initiates the GSM MAP Insert Subscriber Data Procedure towards the SGSN after4the subscriber has been successfully authorized. This procedure is used to download GPRS5subscriber data to the SGSN. Multiple Insert Subscriber Data transactions may be necessary to6complete the transfer of subscriber data to the SGSN.7
j. The SGSN acknowledges the ISD Operation(s).8
k. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF9returns an acknowledgement to the Update GPRS Location Request.10
Note: Steps l,m,n & o are optional depending on whether the IIF supports multiple MSCIDs.11
l. After the IIF’s GPRS_LU timer expires, the IIF shall send a registration notification (REGNOT)12to the ANSI-41 HLR. The REGNOT shall contain the MSID (MIN/IMSI), the ESN, the MSCID,13etc. If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber14shall be passed in the REGNOT to the subscriber’s HLR. The ANSI-41 HLR records the15address of the IIF as the serving ANSI-41 MSC. Although call delivery may not be possible,16SMS delivery is made possible by registering the IIF as the ANSI-41 MSC with the ANSI-4117HLR.18
m. The HLR updates its location information and deletes the previous VLR record by sending a19REGCANC to the previous MSC/VLR, which in this case is the IIF (if in step l, the IIF sent a20REGNOT with a different MSCID (IIF address corresponding to the current SGSN) than the21MSCID sent corresponding to the previous SGSN).22
n. The IIF acknowledges the REGCANC.23
o. The ANSI-41 HLR sends an acknowledgment to the registration with a regnot. The IIF may24ignore the CS-related profile information, since the MS is only GPRS-attached (and not GSM25CS-attached).26
X.S0023
2-158
Related to Figure 110, if a negative regnot response is received from the ANSI-41 HLR, (then1as a Network option) the IIF may perform an initiated detach procedure as described in section24.13.2.6.3
p. The SGSN acknowledges the GPRS routing area update.4
Figure 111: Inter-SGSN routing area update (Option 2: without timer)5
a. MS sends a Routing Area Update request. .6
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in7order to perform authentication i.e. authentication triplets, it requests authentication8information from the IIF. The IIF emulates a GSM HLR/AuC in this case supporting GPRS.9
c. The IIF returns the necessary authentication information, if applicable.10
d. SGSN initiates authentication towards the MS.11
e. MS responds to the authentication request.12
f. SGSN initiates a MAP GPRS location update towards the IIF. The Update GPRS Location13Request contains the IMSI.14
g. The IIF sends a Cancel Location to the previous SGSN.15
inter-SGSN Routing Area Update
MS
Authentication Req
Authentication Res
(IMSI)a
b
c
d
e
fUpdate GPRS Location Req (IMSI)
SGSNIIF
Authentication Info
Authentication Info Ack
HLR PrevSGSN
f
g
h
i
j
k
l
m
n
Insert Sub Data
Insert Sub Data Ack
Update gprs location ack
g
h
i
j
k
l
m
REGNOT
Regnot ack
Cancel Location
Cancel Location Ack
o
regcanc
REGCANC
GPRS NETWORK GPRS NETWORKANSI-41
inter-SGSN Routing Area Update Acceptp
X.S0023
2-159
h. IIF shall receive an acknowledgement for the Cancel Location.1
i. If the IIF implementation supports multiple MSCIDs, then it shall send a REGNOT to the2ANSI-41 HLR with the MSCID corresponding to the new SGSN. Then the IIF shall correlate3that MSCID with the GSM MSCID when receiving mobile terminated SMS messages (so4that the IIF can deliver them to the SGSN).5
j. This is a continuation of the optional procedure started in item i. IIF receives REGCANC.6The IIF needs to keep both the current MSCID associated to the SGSN as well as the7current MSCID associated to the MSC. The IIF must also keep a record of the last MSCID8which was sent to the ANSI-41 HLR to know that is the one stored in the ANSI-41 HLR.9
k. This is a continuation of the optional procedure started in item i. IIF sends regcanc10response.11
l. This is a continuation of the optional procedure started in item i. IIF receives regnot12response.13
m. The IIF validates whether the GPRS service request is authorized. Since GPRS service is14requested, it initiates the GSM MAP Insert Subscriber Data Procedure towards the SGSN15after the subscriber has been successfully authorized. This procedure is used to download16GPRS subscriber data to the SGSN. Multiple Insert Subscriber Data transactions may be17necessary to complete the transfer of subscriber data to the SGSN.18
n. The SGSN acknowledges the ISD Operation(s).19
o. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the20IIF returns an acknowledgement to the Update GPRS Location Request.21
p. The SGSN acknowledges the Routing Area Update request.22
23
X.S0023
2-160
4.13.1.4 GPRS- Attach when only GSM CS Attached1
If an MS roams while registered in a GSM serving MSC, and the MS requests GPRS attach, the MS2performs a GPRS attach and the network responds as shown in Figure 112. Note that the GSM3MSC does not update the IIF (emulating the GSM HLR). The serving MSC remains constant.4
GPRS Attach Req
MS
Authentication Req
Authentication Res
(IMSI)a
b
c
d
e
fUpdate GPRS Location Req (IMSI)
SGSNMSC IIF
Authentication Info
Authentication Info Ack
HLRPMSC/VLR
f
g
h
i
j
k
l
m
n
Insert Sub Data
Insert Sub Data Ack
Update gprs location ack
g
h
i
j
k
l
m
REGNOT
Regnot ack
o
regcanc
REGCANC
GSM NETWORK GSM NETWORKANSI-41
BSSAP+-Location Update Req
p
BSSAP+-Location Update Accept
GPRS Attach Accept
5Figure 112: GPRS Attach when GSM CS Attached.6
a. MS performs a GPRS Attach.7
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to8perform authentication i.e. authentication triplets, it requests authentication information from the9IIF. The IIF emulates a GSM HLR/AuC in this case supporting GPRS.10
c. The IIF returns the necessary authentication information, if applicable.11
d. SGSN initiates authentication towards the MS.12
e. MS responds to the authentication request.13
f. SGSN initiates a MAP GPRS location update towards the IIF. The Update GPRS Location14Request contains the IMSI.15
g. If the IIF implementation supports multiple MSCIDs, then it shall send a REGNOT to the16ANSI-41 HLR with the MSCID corresponding to the new SGSN.17
X.S0023
2-161
h. This is a continuation of the optional procedure started in item g. IIF receives REGCANC.1
i. This is a continuation of the optional procedure started in item g. IIF sends regcanc response.2
j. This is a continuation of the optional procedure started in item g. IIF receives regnot response.]3
k. The IIF validates whether the GPRS service request is authorized. Since GPRS service is4requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert Subscriber5Data Procedure towards the SGSN after the subscriber has been successfully authorized. This6procedure is used to download GPRS subscriber data to the SGSN. Multiple Insert Subscriber7Data transactions may be necessary to complete the transfer of subscriber data to the SGSN.8
l. The SGSN acknowledges the ISD Operation(s).9
m. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF10returns an acknowledgement to the Update GPRS Location Request.11
n. The SGSN sends a BSSAP+LocationUpdateRequest to the GSM MSC over the Gs interface.12The GSM MSC creates the association with the SGSN by storing the SGSN Number. The MSC13does not see a need to notify the IIF (emulating the GSM HLR, since there is no change to the14CS location update parameters).15
o. The GSM MSC acknowledges the BSSAP+LocationUpdateRequest over the Gs interface by16sending the Accept message.17
p. The SGSN acknowledges the GPRS Attach request from the MS.18
19
X.S0023
2-162
4.13.1.5 Combined GSM and GPRS attach when not currently registered1
If an MS requests a combined GSM and GPRS attach when not registered in the IIF, then the2SGSN first requests a GPRS location update to the IIF (acting as a GPRS HLR) and then a CS3location update through the GSM MSC as depicted in Figure 114.4
MS SGSNMSC
IIF
Authentication Info
Authentication Info AckAuthentication Req
Authentication Res
a
b
c
d
e
HLR
Update GPRS Location Req (IMSI)
Insert Sub Data
Insert Sub Data Ack
BSSAP+-Location Update Req
f
g
h
i
j
k
l
m
o
Update gprs location ack
Update Location Req
GPRS_LU
REGNOT
Regnot ack
p
nInsert Subscriber Data
ISD ack
Update Location ack
q
r
BSSAP+-Location Update Accept
Combined Attach Accept
GSM NETWORK ANSI-41 NETWORK
Combined Attach Req (IMSI)
5Figure 113: Combined GPRS and GSM attach (Option 1: With timer).6
a. MS performs a GPRS attach.7
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to8perform authentication i.e. authentication triplets, it requests authentication information from the9IIF. The IIF emulates a GSM HLR/AuC in this case supporting GPRS.10
c. The IIF returns the necessary authentication information, if applicable.11
d. SGSN initiates authentication towards the MS.12
e. MS responds to the authentication request.13
f. SGSN initiates a MAP GPRS location update towards the IIF. The Update GPRS Location14Request contains the IMSI. The IIF starts timer GPRS LU.15
g. The IIF validates whether the GPRS service request is authorized. Since GPRS service is16requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert Subscriber17Data Procedure towards the SGSN after the subscriber has been successfully authorized. This18procedure is used to download GPRS subscriber data to the SGSN. Multiple Insert Subscriber19Data transactions may be necessary to complete the transfer of subscriber data to the SGSN.20
X.S0023
2-163
h. The SGSN acknowledges the ISD Operation(s).1
i. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF2returns an acknowledgement to the Update GPRS Location Request.3
j. The SGSN sends a BSSAP+LocationUpdateRequest to the GSM MSC over the Gs interface.4The GSM MSC creates the association with the SGSN by storing the SGSN Number.5
k. The MSC determines that it needs to notify the IIF (emulating the GSM HLR), since there is a6change to the CS location update parameters. The MSC sends the Update Location operation7to the IIF (emulating the GSM HLR). The IIF stops timer GPRS LU.8
l. The IIF shall send a Registration Notification (REGNOT) to the ANSI-41 HLR to indicate the9changed location (MSCID associated with the new GSM MSC).10
If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall11be passed in the REGNOT to the subscriber’s HLR. This ESN may not match the currently12validated dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for this13subscriber.14
m. The ANSI-41 HLR acknowledges the registration and sends back the subscriber’s information.15This information is for non-GPRS services.16
n. The IIF sends MAP INSERT SUBSCRIBER DATA message(s) to the GSM MSC providing GSM17CS information based on the contents of the regnot (profile).18
o. The GSM MSC acknowledges receipt of the Insert Subscriber Data information.19
p. The IIF acknowledges the completion of the Update Location procedure and sends the Update20Location Acknowledgement to the GSM MSC.21
q. The GSM MSC acknowledges the BSSAP+LocationUpdateRequest over the Gs interface to the22SGSN by sending the Accept message.23
r. The SGSN acknowledges the combined GPRS and GSM Attach request from the MS.24
25
26
X.S0023
2-164
Combined Attach Req (IMSI)
MS SGSN MSCIIF
Authentication Info
Authentication Info AckAuthentication Req
Authentication Res
a
b
c
d
e
HLR
Update GPRS Location Req (IMSI)
Insert Sub Data
Insert Sub Data Ack
BSSAP+-Location Update Req
f
g
h
i
j
k
l
m
o
Update gprs location ack
Update Location Req
p
nInsert Subscriber Data
ISD ack
Update Location ack
q
r
BSSAP+-Location Update Accept
Combined Attach Accept
GSM NETWORK ANSI-41 NETWORK
REGNOT
Regnot ack
1Figure 114: Combined GPRS and GSM attach (Option 2: Without timer and without support2
for multiple MSCIDs).3a. MS performs a GPRS attach.4
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to5perform authentication i.e. authentication triplets, it requests authentication information from the6IIF. The IIF emulates a GSM HLR/AuC in this case supporting GPRS.7
c. The IIF returns the necessary authentication information, if applicable.8
d. SGSN initiates authentication towards the MS.9
e. MS responds to the authentication request.10
f. SGSN initiates a MAP GPRS location update towards the IIF. The Update GPRS Location11Request contains the IMSI.12
g. The IIF shall send a Registration Notification (REGNOT) to the ANSI-41 HLR to indicate the13changed location.14
If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall15be passed in the REGNOT to the subscriber’s HLR. This ESN may not match the currently16validated dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for this17subscriber.18
h. The ANSI-41 HLR acknowledges the registration and sends back the subscriber’s information in19the regnot response.20
X.S0023
2-165
i. The IIF validates whether the GPRS service request is authorized. Since GPRS service is1requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert Subscriber2Data Procedure towards the SGSN after the subscriber has been successfully authorized. This3procedure is used to download GPRS subscriber data to the SGSN. Multiple Insert Subscriber4Data transactions may be necessary to complete the transfer of subscriber data to the SGSN.5
j. The SGSN acknowledges the ISD Operation(s).6
k. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF7returns an acknowledgement to the Update GPRS Location Request.8
l. The SGSN sends a BSSAP+LocationUpdateRequest to the GSM MSC over the Gs interface.9The GSM MSC creates the association with the SGSN by storing the SGSN Number.10
m. The MSC determines that it needs to notify the IIF (emulating the GSM HLR), since there is a11change to the CS location update parameters. The MSC sends the Update Location operation12to the IIF (emulating the GSM HLR). The IIF does not send a REGNOT in this case, because it13does not support multiple MSCIDs.14
n. The IIF sends MAP INSERT SUBSCRIBER DATA message(s) to the GSM MSC providing GSM15CS information based on the contents of the regnot (profile).16
o. The GSM MSC acknowledges receipt of the Insert Subscriber Data information.17
p. The IIF acknowledges the completion of the Update Location procedure and sends the Update18Location Acknowledgement to the GSM MSC.19
q. The GSM MSC acknowledges the BSSAP+LocationUpdateRequest over the Gs interface to the20SGSN by sending the Accept message.21
r. The SGSN acknowledges the combined GPRS and GSM Attach request from the MS.22
X.S0023
2-166
MS SGSN MSC IIF HLR
a
l
k
o
m
i
h
e
d
g
f
p
n
j
c
b
v
u
t
s
r
q
Combined Attach Req (IMSI)
Authentication Info
Authentication Info Ack
Authentication Req
Authentication Res
Update GPRS Location Req (IMSI)
REGNOT
Regnot ack
Insert Sub Data
Insert Sub Data Ack
Update gprs location ack
BSSAP+-Location Update Req
Update Location Req
REGNOT
REGCANC
regcanc
regnot
Insert Sub Data
Insert Sub Data Ack
Update Location ack
GPRS Attach Accept/Routing Area Update Accept
GSM NETWORK ANSI-41 NETWORK
BSSAP+-Location Update Accept
12
Figure 115: Combined GPRS and GSM attach (Option 3: IIF supports multiple MSCIDs).34
a. MS performs a GPRS attach.5
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to6perform authentication i.e. authentication triplets, it requests authentication information from the7IIF. The IIF emulates a GSM HLR/AuC in this case supporting GPRS.8
c. The IIF returns the necessary authentication information, if applicable.9
X.S0023
2-167
d. SGSN initiates authentication towards the MS.1
e. MS responds to the authentication request.2
f. SGSN initiates a MAP GPRS location update towards the IIF. The Update GPRS Location3Request contains the IMSI.4
g. The IIF shall send a Registration Notification (REGNOT) to the ANSI-41 HLR to indicate the5changed location (MSCID associated to the new GSM SGSN).6
If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall7be passed in the REGNOT to the subscriber’s HLR. This ESN may not match the currently8validated dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for this9subscriber.10
h. The ANSI-41 HLR acknowledges the registration and sends back the subscriber’s information in11a regnot response.12
i. The IIF validates whether the GPRS service request is authorized. Since GPRS service is13requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert Subscriber14Data Procedure towards the SGSN after the subscriber has been successfully authorized. This15procedure is used to download GPRS subscriber data to the SGSN. Multiple Insert Subscriber16Data transactions may be necessary to complete the transfer of subscriber data to the SGSN.17
j. The SGSN acknowledges the ISD Operation(s).18
k. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF19returns an acknowledgement to the Update GPRS Location Request.20
l. The SGSN sends a BSSAP+LocationUpdateRequest to the GSM MSC over the Gs interface.21The GSM MSC creates the association with the SGSN by storing the SGSN Number.22
m. The MSC determines that it needs to notify the IIF (emulating the GSM HLR), since there is a23change to the CS location update parameters. The MSC sends the Update Location operation24to the IIF (emulating the GSM HLR).25
n. The IIF shall send a Registration Notification (REGNOT) to the ANSI-41 HLR to indicate the26changed location (MSCID associated to the new GSM MSC).27
If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall28be passed in the REGNOT to the subscriber’s HLR. This ESN may not match the currently29validated dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for this30subscriber.31
o. IIF receives a REGCANC. The IIF needs to keep both the current MSCID associated to the32SGSN as well as the current MSCID associated to the MSC. The IIF must also keep a record of33the last MSCID which was sent to the ANSI-41 HLR to know that is the one stored in the34ANSI-41 HLR.35
p. IIF sends regcanc response.36
q. The ANSI-41 HLR acknowledges the registration and sends back the subscriber’s information.37
r. The IIF sends MAP INSERT SUBSCRIBER DATA message(s) to the GSM MSC providing GSM38CS information based on the contents of the regnot (profile).39
s. The GSM MSC acknowledges receipt of the Insert Subscriber Data information.40
X.S0023
2-168
t. The IIF acknowledges the completion of the Update Location procedure and sends the Update1Location Acknowledgement to the GSM MSC.2
u. The GSM MSC acknowledges the BSSAP+LocationUpdateRequest over the Gs interface to the3SGSN by sending the Accept message.4
v. The SGSN acknowledges the combined GPRS and GSM Attach request from the MS.5
X.S0023
2-169
4.13.1.6 Combined Inter-SGSN Routeing Area/Location Area Update1
If an MS requests a combined routeing area update when previously registered on a different SGSN2and GSM MSC, then the SGSN first requests a GPRS location update to the IIF (acting as a GPRS3HLR) and then a CS location update.4
MS SGSN MSCPrev
SGSNPMSC/
VLR
a
l
k
o
m
i
h
e
d
g
f
p
n
j
c
b
v
u
t
s
r
q
Inter-SGSN Routing Area Update (IMSI)
Authentication Info
Authentication Info Ack
Authentication Req
Authentication Res
Update GPRS Location Req (IMSI)
Insert Sub Data
Insert Sub Data Ack
Update gprs location ack
Update Location Req
REGNOT
REGCANC
regcanc
regnot
Cancel Location
Cancel Location Ack
GPRS Attach Accept/Routing Area Update Accept
GSM NETWORK ANSI-41 NETWORK
y
x
w
ab
aa
z
IIF HLR
BSSAP+-Location Update Req
BSSAP+-Location Update Req
Update Location ack
Insert Sub Data Ack
Insert Sub Data
REGNOT
REGCANC
regcanc
regnot
Cancel Location
Cancel Location Ack
GSM NETWORK56
Figure 116: Combined Inter-SGSN RA/LA update7
X.S0023
2-170
a. MS sends a Routeing Area Update request1
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to2perform authentication i.e. authentication triplets, it requests authentication information from the3IIF. The IIF emulates a GSM HLR/AuC in this case supporting GPRS.4
c. The IIF returns the necessary authentication information, if applicable.5
d. SGSN initiates authentication towards the MS.6
e. MS responds to the authentication request.7
f. SGSN initiates a MAP GPRS location update towards the IIF. The Update GPRS Location8Request contains the IMSI.9
g. In the case of a combined attach when registered on a different MSC and SGSN, and in the10case of a combined inter-SGSN routing area update case when previously registered on a11different MSC and SGSN, the IIF (acting like a GPRS HLR) shall also send a Cancel Location to12the previous SGSN13
h. IIF shall receive an acknowledgement for the Cancel Location.14
i. If the IIF implementation supports multiple MSCIDs, then it shall send a REGNOT to the15ANSI-41 MSC with the MSCID corresponding to the new SGSN.16
j. This is a continuation of the optional procedure started in item i. IIF receives REGCANC. The17IIF needs to keep both the current MSCID associated to the SGSN as well as the current18MSCID associated to the MSC. The IIF must also keep a record of the last MSCID which was19sent to the ANSI-41 HLR to know that is the one stored in the ANSI-41 HLR.20
k. This is a continuation of the optional procedure started in item i. IIF sends regcanc response.21
l. This is a continuation of the optional procedure started in item i. IIF receives regnot response.22
m. The IIF validates whether the GPRS service request is authorized. Since GPRS service is23requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert Subscriber24Data Procedure towards the SGSN after the subscriber has been successfully authorized. This25procedure is used to download GPRS subscriber data to the SGSN. Multiple Insert Subscriber26Data transactions may be necessary to complete the transfer of subscriber data to the SGSN.27
n. The SGSN acknowledges the ISD Operation(s).28
o. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF29returns an acknowledgement to the Update GPRS Location Request.30
p. The SGSN sends a BSSAP+LocationUpdateRequest to the GSM MSC over the Gs interface.31The GSM MSC creates the association with the SGSN by storing the SGSN Number.32
q. The MSC determines that it needs to notify the IIF (emulating the GSM HLR), since there is a33change to the CS location update parameters, so the IIF sends the Update Location operation34to the IIF (emulating the GSM HLR).35
r. The IIF sends a Cancel Location to the previous GSM MSC/VLR if a change in MSC has been36detected.37
s. The IIF receives the Cancel Location acknowledgement.38
t. If the IIF implementation supports multiple IIF MSCIDs, then it shall send a Registration39Notification (REGNOT) to the ANSI-41 HLR to indicate the changed location (MSCID40associated to the new GSM MSC).41
X.S0023
2-171
If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall1be passed in the REGNOT to the subscriber’s HLR. This ESN may not match the currently2validated dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for this3subscriber.4
u. This is a continuation of the optional procedure started in item t. The IIF receives a REGCANC5if the MSCID just sent in item (t) is a different one than stored in the ANSI-41 HLR. IIF receives6REGCANC. The IIF needs to keep both the current MSCID associated to the SGSN as well as7the current MSCID associated to the MSC. The IIF must also keep a record of the last MSCID8which was sent to the ANSI-41 HLR to know that is the one stored in the ANSI-41 HLR.9
v. This is a continuation of the optional procedure started in item t. The IIF acknowledges the10regcanc.11
w. This is a continuation of the optional procedure started in item t. The IIF receives the regnot12response with the subscriber’s information. This information is for non-GPRS services.13
x. The IIF sends MAP INSERT SUBSCRIBER DATA message(s) to the GSM MSC providing GSM14CS information based on the contents of the regnot (profile).15
y. The GSM MSC acknowledges receipt of the Insert Subscriber Data information.16
z. The IIF acknowledges the completion of the Update Location procedure and sends the Update17Location Acknowledgement to the GSM MSC.18
aa. The GSM MSC acknowledges the BSSAP+LocationUpdateRequest over the Gs interface to the19SGSN by sending the Accept message.20
bb. The SGSN acknowledges the GPRS Attach request from the MS.21
22
X.S0023
2-172
4.13.1.7 Inter-SGSN routing area update when GSM CS and GPRS attached (GSM MSC1remains constant)2
An MS request a GPRS routing area update while registered in a GSM serving MSC and GPRS3attached. In this case, the change of routing areas is within one Location area (and the MSC4remains constant) as shown in Figure 118. Note that the GSM MSC does not update the IIF5(emulating the GSM HLR).6
MS SGSN MSCPrev
SGSN
a
l
k
o
m
i
h
e
d
g
f
p
n
j
c
b
r
q
Inter-SGSN Routing Area Update (IMSI)
Authentication Info
Authentication Info Ack
Authentication Req
Authentication Res
Update GPRS Location Req (IMSI)
Insert Sub Data
Insert Sub Data Ack
Update gprs location ack
BSSAP+-Location Update Accept
REGNOT
REGCANC
regcanc
regnot
GSM NETWORK ANSI-41 NETWORK
IIF HLR
BSSAP+-Location Update Req
Routing Area Update Accept
Cancel Location
Cancel Location Ack
78
Figure 117: Inter-SGSN routing area update when GSM CS and GPRS Attached9(MSC remains constant)10
X.S0023
2-173
1a. MS sends a Routing Area Update request.2
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to3perform authentication i.e. authentication triplets, it requests authentication information from the4IIF. The IIF emulates a GSM HLR/AuC in this case supporting GPRS.5
c. The IIF returns the necessary authentication information, if applicable.6
d. SGSN initiates authentication towards the MS.7
e. MS responds to the authentication request.8
f. SGSN initiates a MAP GPRS location update towards the IIF. The Update GPRS Location9Request contains the IMSI.10
g. The IIF (acting like a GPRS HLR) shall send a Cancel Location to the previous SGSN11
h. IIF shall receive an acknowledgement for the Cancel Location.12
i. If the IIF implementation supports multiple MSCIDs, then it shall send a REGNOT to the13ANSI-41 MSC with the MSCID corresponding to the new SGSN. The IIF shall correlate that14MSCID with the GSM MSCID when receiving mobile terminated SMS messages (so that the IIF15can deliver them to the MSC).16
j. This is a continuation of the optional procedure started in item i. IIF receives REGCANC. The17IIF needs to keep both the current MSCID associated to the SGSN as well as the current18MSCID associated to the MSC. The IIF must also keep a record of the last MSCID which was19sent to the ANSI-41 HLR to know that is the one stored in the ANSI-41 HLR.20
k. This is a continuation of the optional procedure started in item i. IIF sends regcanc response.21
l. This is a continuation of the optional procedure started in item i. IIF receives regnot response.22
m. The IIF validates whether the GPRS service request is authorized. Since GPRS service is23requested, it initiates the GSM MAP Insert Subscriber Data Procedure towards the SGSN after24the subscriber has been successfully authorized. This procedure is used to download GPRS25subscriber data to the SGSN. Multiple Insert Subscriber Data transactions may be necessary to26complete the transfer of subscriber data to the SGSN.27
n. The SGSN acknowledges the ISD Operation(s).28
o. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF29returns an acknowledgement to the Update GPRS Location Request.30
p. The SGSN sends a BSSAP+LocationUpdateRequest to the GSM MSC over the Gs interface.31
q. The MSC determines that it does not need to notify the IIF (emulating the GSM HLR), since32there is no change to the CS location update parameters, so the IIF does not send the Update33Location operation to the IIF (emulating the GSM HLR). The GSM MSC acknowledges the34BSSAP+LocationUpdateRequest over the Gs interface to the SGSN by sending the Accept35message.36
r. The SGSN acknowledges the Routing Area Update request from the MS.37
X.S0023
2-174
4.13.1.8 Combined Attach When Currently Registered in an ANSI-41 MSC1
This scenario describes the case where a mobile that is currently registered in an ANSI-41 MSC2performs a combined attach for both GPRS and non-GPRS services.3
ANSI-41 NETWORK
MS SGSN MSCPMSC/
VLR
a
l
k
o
m
i
h
e
d
g
f
p
n
j
c
b
r
q
GPRS Attach Req (IMSI)
Authentication Info
Authentication Info Ack
Authentication Req
Authentication Res
Update GPRS Location Req (IMSI)
Insert Sub Data
Insert Sub Data Ack
Update gprs location ack
Insert Sub Data Ack
REGNOT
REGCANC
regcanc
regnot ack
GSM NETWORK ANSI-41 NETWORK
IIF HLR
BSSAP+-Location Update Req
Insert Sub Data
t
s
Update location Req
BSSAP+-Location Update Accept
Update location ack
GPRS Attach Accept
GPRS_LU
45
Figure 118: Combined Attach when registered on a ANSI-41 MSC (Option 1: With timer)6a. MS performs a GPRS Attach.7
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to8perform authentication i.e. authentication triplets, it requests authentication information from the9IIF. The IIF emulates a GSM HLR/AuC in this case supporting GPRS.10
c. The IIF returns the necessary authentication information, if applicable.11
X.S0023
2-175
d. SGSN initiates authentication towards the MS.1
e. MS responds to the authentication request.2
f. SGSN initiates a MAP GPRS location update towards the IIF. The Update GPRS Location3Request contains the IMSI. The IIF starts timer GPRS LU.4
g. The IIF validates whether the GPRS service request is authorized. Since GPRS service is5requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert Subscriber6Data Procedure towards the SGSN after the subscriber has been successfully authorized. This7procedure is used to download GPRS subscriber data to the SGSN. Multiple Insert Subscriber8Data transactions may be necessary to complete the transfer of subscriber data to the SGSN.9
h. The SGSN acknowledges the ISD Operation(s).10
i. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF11returns an acknowledgement to the Update GPRS Location Request.12
j. The SGSN sends a BSSAP+LocationUpdateRequest to the GSM MSC over the Gs interface.13The GSM MSC creates the association with the SGSN by storing the SGSN Number.14
k. The MSC determines that it needs to notify the IIF (emulating the GSM HLR), since there is a15change to the CS location update parameters. The MSC sends the Update Location operation16to the IIF (emulating the GSM HLR). The IIF stops timer GPRS LU.17
l. The IIF shall send a Registration Notification (REGNOT) to the ANSI-41 HLR to indicate the18changed location (MSCID associated with the new GSM MSC).19
If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall20be passed in the REGNOT to the subscriber’s HLR. This ESN may not match the currently21validated dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for this22subscriber.23
m. The HLR updates its location information and deletes the previous VLR record by sending a24REGCANC to the previous MSC/VLR.25
n. The VLR acknowledges the REGCANC.26
o. The ANSI-41 HLR acknowledges the registration and sends back the subscriber’s information.27This information is for non-GPRS services28
p. The IIF sends MAP INSERT SUBSCRIBER DATA message(s) to the GSM MSC providing GSM29CS information based on the contents of the regnot (profile).30
q. The GSM MSC acknowledges receipt of the Insert Subscriber Data information.31
r. The IIF acknowledges the completion of the Update Location procedure and sends the Update32Location Acknowledgement to the GSM MSC.33
s. The GSM MSC acknowledges the BSSAP+LocationUpdateRequest over the Gs interface to the34SGSN by sending the Accept message.35
t. The SGSN acknowledges the combined GPRS and GSM attach request from the MS.36
X.S0023
2-176
ANSI-41 NETWORK
MS SGSN MSCPMSC/
VLR
a
l
k
o
m
i
h
e
d
g
f
p
n
j
c
b
r
q
GPRS Attach Req (IMSI)
Authentication Info
Authentication Info Ack
Authentication Req
Authentication Res
Update GPRS Location Req (IMSI)
Insert Sub Data
Insert Sub Data Ack
Update gprs location ack
Insert Sub Data Ack
REGNOT
REGCANC
regcanc
regnot ack
GSM NETWORK ANSI-41 NETWORK
IIF HLR
BSSAP+-Location Update Req
Insert Sub Datat
s
Update location Req
BSSAP+-Location Update Accept
Update location ack
GPRS Attach Accept
REGNOT
REGCANC
regcanc
regnot
x
v
w
u
1Figure 119: Combined attach when registered on a ANSI-41 MSC (Option 2: without timer )2
a. MS performs a GPRS attach.3
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in4order to perform authentication i.e. authentication triplets, it requests authentication5information from the IIF. The IIF emulates a GSM HLR/AuC in this case supporting GPRS.6
X.S0023
2-177
c. The IIF returns the necessary authentication information, if applicable.1
d. SGSN initiates authentication towards the MS.2
e. MS responds to the authentication request.3
f. SGSN initiates a MAP GPRS location update towards the IIF. The Update GPRS Location4Request contains the IMSI.5
g. The IIF shall send a Registration Notification (REGNOT) to the ANSI-41 HLR to indicate the6changed location.7
If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber8shall be passed in the REGNOT to the subscriber’s HLR. This ESN may not match the9currently validated dynamic ESN for this subscriber, but the HLR shall also accept this fixed10ESN for this subscriber.11
h. ANSI-41 HLR sends a REGCANC to the ANSI-41 MSC on which the MS was previously12registered.13
i. ANSI-41 MSC sends regcanc response.14
j. The ANSI-41 HLR acknowledges the registration and sends back the subscriber’s15information in a regnot response.16
k. The IIF validates whether the GPRS service request is authorized. Since GPRS service is17requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert18Subscriber Data Procedure towards the SGSN after the subscriber has been successfully19authorized. This procedure is used to download GPRS subscriber data to the SGSN.20Multiple Insert Subscriber Data transactions may be necessary to complete the transfer of21subscriber data to the SGSN.22
l. The SGSN acknowledges the ISD Operation(s).23
m. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the24IIF returns an acknowledgement to the Update GPRS Location Request.25
n. The SGSN sends a BSSAP+LocationUpdateRequest to the GSM MSC over the Gs26interface. The GSM MSC creates the association with the SGSN by storing the SGSN27Number (e.g. for later CS paging over the Gs interface upon a call delivery attempt).28
o. The MSC determines that it needs to notify the IIF (emulating the GSM HLR), since there is29a change to the CS location update parameters. The MSC sends the Update Location30operation to the IIF (emulating the GSM HLR).31
p. If the IIF implementation supports multiple MSCIDs, then it shall send a Registration32Notification (REGNOT) to the ANSI-41 HLR to indicate the changed location (MSCID33associated to the new GSM MSC).34
If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber35shall be passed in the REGNOT to the subscriber’s HLR. This ESN may not match the36currently validated dynamic ESN for this subscriber, but the HLR shall also accept this fixed37ESN for this subscriber.38
q. This is a continuation of the optional procedure started in item p. The IIF receives a39REGCANC if the MSCID just sent in item (p) is a different one than stored in the ANSI-4140HLR. The IIF needs to keep both the current MSCID associated to the SGSN as well as the41current MSCID associated to the MSC. The IIF must also keep a record of the last MSCID42which was sent to the ANSI-41 HLR to know that is the one stored in the ANSI-41 HLR.43
X.S0023
2-178
r. This is a continuation of the optional procedure started in item p. The IIF acknowledges the1regcanc.2
s. This is a continuation of the optional procedure started in item p. The IIF receives the3regnot response with the subscriber’s information. This information is for non-GPRS4services.5
t. The IIF sends MAP INSERT SUBSCRIBER DATA message(s) to the GSM MSC providing6GSM CS information based on the contents of the regnot (profile).7
u. The GSM MSC acknowledges receipt of the Insert Subscriber Data information.8
v. The IIF acknowledges the completion of the Update Location procedure and sends the9Update Location Acknowledgement to the GSM MSC.10
w. The GSM MSC acknowledges the BSSAP+LocationUpdateRequest over the Gs interface to11the SGSN by sending the Accept message.12
x. The SGSN acknowledges the combined GPRS and GSM attach request from the MS.13
4.13.1.9 Authentication Failure at the IIF14
In any of the scenarios shown previously in 4.13.1 (assuming authentication is performed),15authentication may fail at the IIF.16
In the event that authentication fails at the IIF (emulating a GSM HLR), it shall send a response to17the SGSN indicating the reason for failure.18
Note: The ANSI-41 HLR is not informed about a registration attempt if authentication fails at the IIF.19
4.13.1.10 Registration Failure at the ANSI-41HLR20
In any of the scenarios shown previously in 4.13.1 where the ANSI-41 HLR is informed about the21registration attempt (assuming authentication is successful or not performed), the registration22procedure may fail.23
In the event that the ANSI-41 HLR denies the registration attempt, it shall send a regnot to the IIF24indicating the reason for failure. If the IIF determines that the MS is already registered in an SGSN,25it shall send a Cancel Location to the SGSN. Otherwise, the IIF sends an update GPRS location26response indicating the reason for failure.27
X.S0023
2-179
4.13.2 Location Deregistration Scenarios12
4.13.2.1 GSM CS (IMSI) Detach while GPRS and GSM CS Attached3
A GPRS mobile attached for both GPRS and non-GPRS services can request a detach for circuit4services (IMSI detach). The IIF is not notified about the MS initiated detachment and hence the5ANSI-41 HLR is not informed.6
4.13.2.2 GPRS Detach While Attached for Both GPRS and GSM CS Services7
A GPRS mobile attached for both GPRS and non-GPRS services can request a GPRS detach. The8IIF is not notified about the MS initiated detachment and hence the ANSI-41 HLR is not informed.9
4.13.2.3 GPRS Detach While Attached for GPRS Services Only10
In GPRS, the GPRS HLR is not notified when a GPRS subscriber performs a GPRS detach. Hence,11the IIF (which is emulating the GPRS HLR) shall not be notified of the GPRS detach. In this case, a12GPRS subscriber performs a Detach request that is handled by the SGSN and GGSN to remove13MM and PDP contexts. There is no interworking with circuit services.14
4.13.2.4 Combined GPRS Detach and GSM CS (IMSI) Detach15
A GPRS mobile attached for both GPRS and non-GPRS services can request a combined detach16from GPRS and non-GPRS services. The IIF is not notified about the MS initiated detachment and17hence the ANSI-41 HLR is not informed.18
X.S0023
2-180
4.13.2.5 GPRS Detach Followed By Purge1
The IIF becomes involved in a detach procedure when the detach procedure is followed by a purge2MS procedure. The following scenario shows the case where a GAIT mobile is attached for3services to an SGSN-only. The mobile performs a GPRS detach. After accepting the detach4request, the SGSN is configured to initiate a purge MS procedure (after some pre-configured time5period). In a case when the MS is still GSM CS attached, the MS-Inactive is not sent by the IIF.6Likewise, if an MSC sends the PurgeMS operation to the IIF when the subscriber is still GPRS7attached, the IIF would not send the MS-Inactive to the ANSI-41 HLR.8
MS SGSNANSI-41/
HLR
a
h
e
d
g
f
c
b
Detach Request
Purge MS Ack
MS INACTIVE
Signaling with GGSN
Purge MS
IIF
Detach Accept
ms inactive
GGSN
Signaling with GGSN
910
Figure 120: MS in GSM Foreign Mode Performing GPRS Detach Followed by Purge1112
a. The MS performs a Detach Request to detach from GPRS services. This MS was attached for13GPRS services only.14
b. The SGSN exchanges signaling information with the GGSN to remove PDP contexts on the15GGSN for the subscriber.16
c. See (b)17
d. The SGSN accepts the detach from the MS and sends a Detach Accept.18
e. The SGSN is configured to delete MM contexts as soon as the Detach Accept is sent. Hence,19the SGSN notifies the IIF (acting as a GPRS HLR) that it has deleted the MM context for the20MS.21
f. The IIF acknowledges the Purge Operation and marks in its GPRS subscription data for the22subscriber that the GPRS data has been purged.23
g. The IIF sends an MSINACTIVE to the ANSI-41 HLR to de-register the MS from the IIF (acting24as an ANSI-41 MSC).25
h. The ANSI-41 HLR acknowledges the MSINACTIVE operation26
X.S0023
2-181
4.13.2.6 IIF - Initiated Detach1
The IIF initiated detach procedure is initiated by the IIF. The procedure results in the removal of a2subscribers PDP contexts at the SGSN.3
4
Figure 121: IIF - Initiated Detach5a. The IIF requests deletion of a subscribers PDP contexts from the SGSN by sending a Cancel6
Location (IMSI, Cancellation Type) to the SGSN with Cancellation Type set to Subscription7Withdraw.8
9b. The SGSN informs the MS that it has been detached by sending Detach Request (Detach10
Type) to the MS. Detach Type shall indicate that the MS is not requested to make a new11attach and PDP context activation.12
13c. The active PDP contexts in the GGSNs are de-activated by the SGSN sending Delete PDP14
Context Request messages to the GGSNs.1516
d. The GGSNs acknowledge the Delete Request1718
e. If the MS was both IMSI-attached and GPRS–attached the SGSN sends a GPRS Detach19Indication (IMSI) to the VLR.20
21f. The MS sends a Detach Accept to the SGSN any time after step b.22
23g. The SGSN confirms the deletion of the PDP contexts with a Cancel Location Ack (IMSI).24
25Note: In some cases the IIF may send an MS Inactive towards the ANSI-41 HLR (but not if CS26services are still to be offered).27
Delete PDP Context Response
Delete PDP Context Request
Detach Accept
Detach Request
Cancel Location
MS SGSN IIF
a
b
c
d
e
f
g
GGSN MSC/VLR
Cancel Location Ack
GPRS Detach Indication
X.S0023
2-182
4.13.3 SMS Scenarios1
This section describes the scenarios for MS terminated and MS originated SMS while the mobile in2roaming in a GPRS network in GSM foreign mode.3
4.13.3.1 SMS Scenarios for Mobile Terminated SMS while GPRS Attached4
If the subscriber is both GSM CS attached as well as GPRS attached, then the IIF shall act like a5GSM SMS-SC.6
The scenarios that follow only show the SMS delivery via GPRS.7
4.13.3.1.1 Successful Mobile Terminated ANSI-41SMS (CMT) Mapped to GSM SMS8
ANSI-41MC
ANSI-41HLR IIF
SGSNMS
a
b
c
d
e
f
g
h
i
SMSDelivery
SMSREQUEST
SMDPP (CMT)
smdpp [ACK]
FORWARD SHORT MESSAGE
SMS Delivery
SMS Delivery Ack
Forward Short Message
smsrequest
9Figure 122: Successful Mobile Terminating ANSI-41SMS (CMT) mapped to GSM SMS10
11a. The ANSI-41Message Center (MC) receives a short message for a specific subscriber. Note:12
This step is shown for completeness only and is not repeated in subsequent call flows.1314
b. The Message Center sends an SMS Request message to the ANSI-41 HLR of the short15message recipient to request a routing address for delivering the short message to that16subscriber.17
18c. Since the subscriber has a current valid location stored in the HLR, the HLR returns it to the MC19
in the SMS Request Return Result message.2021
d. The Message Center then sends a Short Message Delivery Point to Point message to the IIF,22which is seen as the current serving ANSI-41 MSC/VLR for that subscriber. Note that in this23case, the format used by the MC is the CMT format (Cellular Messaging Transport). Note that24alternatively, the ANSI-41MC could translate the original CMT SMS to GHOST/WEMT format25before sending it to the IIF if the IIF only supports the GHOST/WEMT format. In this case the IIF26
X.S0023
2-183
would convert ANSI-41GHOST/WEMT into GSM format (see Section 4.13.3.1.2) instead of1ANSI-41CMT into GSM format.2
3e. Upon reception of the Short Message Delivery Point to Point message from the ANSI-41MC,4
the IIF originates a FORWARD SHORT MESSAGE to the SGSN after having translated the5short message into GSM format. The IIF is then acting as a GSM SMS-GMSC.6
7f. The SGSN sends the short message to the mobile station. Note: This step is shown for8
completeness only and is not repeated in subsequent call flows.910
g. The mobile station acknowledges the delivery of the short message. Note: This step is shown11for completeness only and is not repeated in subsequent call flows.12
13h. The SGSN sends the result of the Forward Short Message to the IIF.14
15i. The IIF sends the result of the Short Message Delivery Point to Point to the ANSI-41Message16
Center.17
X.S0023
2-184
4.13.3.1.2 Successful Mobile Terminating ANSI-41SMS (GHOST/WEMT) Mapped to GSM SMS1
2
34
Figure 123: Successful Mobile Terminating ANSI-41SMS (GHOST/WEMT) mapped to GSM5SMS6
7a. The ANSI-41 MC sends a SMSRequest Invoke message to the HLR, including as arguments8
the MIN (MSISDN) of the mobile station and SMS Notification Indicator.9b. The HLR determines if the message shall be forwarded to the MS and sends a response back10
in a SMSRequest Return Result, with the SMS_Address set to the IIF address (point code or11E.164 address).12
c. The MC formats a GHOST/WEMT teleservice and sends it to the IIF in an SMDPP message.13d. Upon receipt of the SMDPP message, the IIF builds a FORWARD SHORT MESSAGE,14
stripping off the GHOST/WEMT teleservice and using the encapsulated GSM SMS transfer15PDU, and routes it to the SGSN as a first choice. Alternatively, the IIF could send the FSM to16the GSM MSC (if the 03.40 MNRC flag is not set).17
e. The SGSN packages the GSM SMS RP-DATA into a CP-DATA message and delivers it across18the GSM air interface to the mobile station. The mobile station acknowledges receipt of the CP-19DATA and RP-DATA messages via CP-ACK and CP-ACK[RP-ACK], respectively. Upon20successful receipt of the RP-ACK, the SGSN shall send a positive acknowledgement Forward21Short Message back to the IIF.22
f. The IIF maps the received Forward Short Message into a SMDPP Return Result and sends it to23the MC.24
X.S0023
2-185
4.13.3.1.3 Unsuccessful Mobile Terminated Delivery (Failure at SGSN)1
The following scenario applies to short message delivery failure in either CMT or GHOST/WEMT2format.3
4Figure 124: Unsuccessful Mobile Terminated Delivery (Failure at SGSN)5
6a. The ANSI-41 MC sends a SMSRequest Invoke message to the HLR, including as arguments7
the MIN (MSISDN) of the mobile station and SMS Notification Indicator.8b. The HLR determines if the message shall be forwarded to the MS and sends a response back9
in a SMSRequest Return Result, with the SMS_Address set to the IIF address (point code or10E.164 address).11
c. The MC formats a GHOST/WEMT teleservice or a CMT short message and sends it to the IIF in12an SMDPP message.13
d. Upon receipt of the SMDPP message, the IIF builds a FORWARD SHORT MESSAGE,14stripping off the GHOST/WEMT teleservice and using the encapsulated GSM SMS transfer15PDU, and routes it to the SGSN. If the message received is in the CMT format, the IIF maps this16information into a short message in GSM format.17
e. The SGSN packages the GSM SMS RP-DATA into a CP-DATA message and delivers it across18the GSM air interface to the mobile station. The mobile station negatively acknowledges either19the CP-DATA message or the RP-DATA message. The SGSN sends a negative20acknowledgement Forward Short Message (with appropriate cause value) back to the IIF.21
f. The IIF maps the received Forward Short Message into a SMDPP Return Result and sends it to22the MC. In addition, the IIF sets one of the GSM SMS flags as defined in the GSM 03.4023specification [35] according to the error cause received from the SGSN; that is, the Mobile24Subscriber Not GPRS Reachable Flag (MNRG) shall be set if the error cause is “absent25subscriber”, and the Memory Capacity Exceeded Flag (MCEF) shall be set if the error cause is26“memory capacity exceeded”. Additionally, the IIF emulating the ANSI-41 MSC shall set and27
X.S0023
2-186
store the SMS Delivery Pending flag with the MC parameters received in the SMDPP (for later1delivery in the SMSNOT) – note that this “SMS Delivery Pending” flag/data serves the same2purpose as a GSM HLR’s “Message Waiting Data” flag/data. [However, note that if an ANSI-413REGCAN is received from the ANSI-41 HLR before the SMS Delivery Pending Flag is cleared,4then the regcanc response shall contain the SMS_MessageWaitingIndicator, and all flags are5cleared (i.e., MNRG, MNRF, MCEF, and SMS Delivery Pending Flag)].6
X.S0023
2-187
4.13.3.1.4 Unsuccessful Mobile Terminated Delivery (Failure at IIF)1
The following scenario applies to short message delivery failure in either CMT or GHOST/WEMT2format.3
4
MC HLR IIF
ANSI-41 GSM
MSC
SMSREQ
SMDPP
a
b
c
d
SMSREQ
smdpp [NAK]
5Figure 125: Unsuccessful Mobile Terminated Delivery (Failure at IIF)6
7a. The ANSI-41 MC sends a SMSRequest Invoke message to the HLR, including as arguments8
the MIN (MSISDN) or IMSI of the mobile station and SMS Notification Indicator.9b. The HLR determines if the message shall be forwarded to the MS and sends a response back10
in a SMSRequest Return Result, with the SMS_Address set to the IIF address (point code or11E.164 address).12
c. The MC formats a GHOST/WEMT teleservice and sends it to the IIF in an SMDPP message.13
d. Upon receipt of the SMDPP message, the IIF examines the GSM 03.40 HLR flags (if “both14MNRC and MNRG” or ”MCEF” is set) and determines that the MS is unable to receive a Short15Message. The IIF indicates this fact in the SMDPP Return Result. It includes the cause for the16failure in the SMS_CauseCode parameter of the SMDPP Return Result. The IIF shall set &17store the SMS Delivery Pending Flag with the data received in the SMDPP message (for later18delivery in the SMSNOT). If the 03.40 flag is set to MNRG and if the flag is not set to MNRC,19then the SMDPP shall be delivered to the GSM MSC as described in GAIT phase 1. If 03.4020flag is set to MNRC and not MNRG nor MCEF, then SMS delivery is possible through the SGSN21as shown in section 4.13.3.1.22
23
24
X.S0023
2-188
4.13.3.1.5 Alerting for an ANSI-41Subscriber for GPRS in GSM Foreign Mode1
The following scenario applies to short messages originated in either CMT or GHOST/WEMT2format.3
4
Figure 126: Alerting for an ANSI-41Subscriber in GSM Foreign Mode5
a. The SGSN sends a READY FOR SM to the IIF, including as arguments the IMSI, Alert Reason6Indicator and Alert Reason. Note: The SMS notification can also be triggered when the SGSN7sends an Update GPRS Location. This happens when an MS for whom messages are pending8re-attaches or performs an inter-SGSN routing area update, the SGSN sends an Update GPRS9Location message to the IIF.10
b. If the IIF has the SMS Delivery Pending Flag set, and if the MCEF flag is not set, then the IIF11sends a SMSNOT to each of the subscriber’s MCs stored with the SMS Delivery Pending Flag.12The SMSNOT shall contain; the MIN (MSISDN) as mapped from the IMSI, ESN, and13SMS_Address containing the IIF address.14
c. The MC sends a SMSNOT Return Result to the IIF, then the IIF clears the SMS Delivery15Pending Flag, then proceeds to send the mobile station a mobile terminated CMT or16GHOST/WEMT teleservice message.17
d. If the IIF has GSM 03.40 flags set, then these flags shall be cleared according to the “alert18reason”; that is, if the “alert reason” is “memory available”, then both the MCEF and MNRG19flags are cleared, and if the “alert reason” is “MS present”, then the MNRG flag is cleared. If the20UpdateGPRSLocation is received, then the MNRG flag is cleared. The IIF sends a Ready for21SM response to the SGSN with no arguments.22
23
SMSC HLR IIF
ANSI-41 GSM
MSC
READY FOR SM
ready for SM
SMSNOT
smsnot
a
b
c
d
X.S0023
2-189
4.13.4 Message Flows for Mobile Originated SMS when operating GPRS in1GSM Foreign Mode2
This section describes the message flows for originating a short message to the subscriber’s home3message center when the mobile station is operating GPRS in GSM Foreign Mode. The following4scenarios apply to short messages delivered to the MC in either CMT or GHOST/WEMT format.5
4.13.4.1 Successful Mobile Originated SMS to MC6
SGSN HLR IIF
GSM ANSI-41
MC
a
b
c
d
SMDPP
smdpp [ACK]
FORWARD SHORT MESSAGE
Forward Short Message
7Figure 127: Successful Mobile Originated Delivery8
9a. The SGSN originates a FORWARD SHORT MESSAGE to the address provided by the MS (i.e.,10
IIF), including as arguments the Service Center Address, MSISDN and GSM SMS-SUBMIT11PDU.12
b. Upon receipt of the FORWARD SHORT MESSAGE, the IIF builds an ANSI-41 SMDPP13message, encapsulating the GSM SMS transfer PDU in a GHOST/WEMT teleservice, and14routes it to the originator’s home MC. The IIF can also map the Forward Short Message into a15CMT short message.16
c. The MC sends a positive acknowledgement SMDPP Return Result to the IIF.17d. The IIF maps the received SMDPP Return Result to a Forward Short Message, and sends it to18
the SGSN.19
X.S0023
2-190
4.13.4.2 Unsuccessful Mobile Originated (Failure at MC)1
SGSN HLR IIF
GSM ANSI-41
MC
a
b
c
d
SMDPP
smdpp [NAK]
FORWARD SHORT MESSAGE
Forward Short Message
2Figure 128: Unsuccessful Mobile Originated Delivery (Failure at MC)3
4a. The SGSN originates a FORWARD SHORT MESSAGE to the address provided by the MS (i.e.,5
IIF), including as arguments the Service Centre Address, MSISDN and GSM SMS-SUBMIT6PDU.7
b. Upon receipt of the FORWARD SHORT MESSAGE, the IIF builds an ANSI-41 SMDPP8message encapsulating the GSM SMS transfer PDU in a GHOST/WEMT teleservice, and9routes it to the MC. The IIF can also map the Forward Short Message into a CMT short10message.11
c. The MC sends a negative acknowledgement SMDPP Return Result to the IIF.12d. The IIF maps the received SMDPP Return Result to a Forward Short Message with the13
appropriate cause code value, and sends it to the SGSN.14
X.S0023
2-191
4.13.4.3 Unsuccessful Mobile Originated (Failure at IIF)1
2Figure 129: Unsuccessful Mobile Originated (Failure at IIF)3
a. The SGSN originates a FORWARD SHORT MESSAGE to the address provided by the MS (i.e.,4IIF), including as arguments the Service Centre Address, MSISDN and GSM SMS-SUBMIT5PDU.6
b. Upon receipt of the FORWARD SHORT MESSAGE, the IIF builds a negative acknowledgement7Forward Short Message and sends it to the SGSN.8
9
GSM ANSI-41
FORWARD SHORT MESSAGE
Forward Short Message
SGSN HLR IIIF MC
a
b
X.S0023
2-192
4.13.5 Message Waiting Notification while GPRS Attached in GSM Foreign1Mode2
This section illustrates the interactions between network entities in various situations related to3mobile originations and GPRS in GSM foreign mode and Message Waiting Notification. For a native4ANSI-41subscriber roaming in a GSM environment, there can be two events that trigger the IIF to5send the Message Waiting Notification (MWN) using the GSM SMS to the Mobile Station (MS). The6first one is at registration (update GPRS location), if there is an indication in the ANSI-41 HLR that7messages have been delivered to the subscriber’s voice mail box, the ANSI-41 HLR shall indicate8that in the Registration Notification Return Result message. This shall trigger the IIF to send a GSM9SMS with the MWN information. This is shown in section 4.13.5.1. The second event is when the10HLR receives a Message Waiting Notification for a subscriber that is already registered. In this11case, the ANSI-41 HLR shall send a Qualification Directive message to the IIF which shall translate12it into a GSM SMS with MWN indication. This is shown in Section 4.13.5.2.13
If the subscriber is both GSM CS attached as well as GPRS attached, then the IIF shall act like a14GSM SMS-SC.15
The scenarios that follow only show the MWN SMS delivery via GPRS.16
X.S0023
2-193
4.13.5.1 Indicator in ANSI-41 Registration Notification Return Result mapped1to GSM SMS2
ANSI-41VMS
IIFGSMSGSN MS
a
b
c
d
e
f
g
h
i
j
VmailDelivery
“Message WaitingNotification”
GPRS attach reqUPDATE GPRS
LOCATION
REGNOT
regnot (MWNCOUNT, MWNTYPE)
INSERT_SUB_DATA
Insert_sub_data
update gprs location
GPRS Accept
FORW. SHORTMESSAGE (MWN)
SMS Delivery (MWN)
SMS Delivery Ack
Forw. Short Message
k
l
m
n
ANSI-41HLR
34
Figure 130: Indicator in ANSI-41 Registration Notification Return Result mapped to GSM SMS5a. The Voice Mail System (VMS) receives a voice mail for a specific subscriber.6
7b. The VMS send the “Message Waiting Notification” (MWN) to the ANSI-41 HLR of the voice mail8
recipient. Note that the interface between the VMS and the ANSI-41 HLR is not standardized in9ANSI-41.D [2]. Note also that at that point in time, the subscriber is not registered in any serving10system, so the HLR just keeps the information that a voice mail was received.11
12c. The Mobile Station accesses a serving system and originates an update location request.13
14d. The Update Location is sent from the serving GSM MSC/VLR to the IIF, seen as the GSM HLR15
for that subscriber.1617
e. The IIF sends a Registration Notification to the ANSI-41 HLR of the subscriber.1819
f. The ANSI-41 HLR replies with the Registration Notification Return Result containing the20“Message Waiting Notification” information that consists of two parameters:21MessageWaitingNotificationCount (MWNCOUNT) and MessageWaitingNotificationType22
X.S0023
2-194
(MWNTYPE). For a description of these parameters, refer to the ANSI-41.D specifications,1sections 6.5.2.78 and 6.5.2.79 [2].2
3At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification is to4be delivered to the Mobile Station.5
6g. The IIF sends Insert Subscriber Data to the serving GSM SGSN. Note that there could be more7
than one Insert Subscriber Data message depending on the subscriber profile.89
h. The serving GSM SGSN returns the Insert Subscriber Data result. Note that there could be10more than one such result message, one matching every Insert Subscriber Data message.11
12i. The IIF completes the location update by sending the Update Location result message to the13
serving GSM SGSN.1415
j. The serving GSM SGSN confirms the update location to the mobile station.1617
k. Since the REGNOT return result from event f contained the Message Waiting Notification18information, this triggers the IIF to originate an SMS with MWN information by sending Forward19Short Message to the serving GSM SGSN. The IIF is then acting as a GSM SMS-GMSC. The20IIF is to encode the MWN information in the SMS with three methods, namely, UDH, DCS, and21CPHS. Refer to Volume 3 for the encoding details.22
23l. The serving GSM SGSN sends the short message with the MWN information to the mobile24
station.2526
m. The mobile station acknowledges the delivery of the short message.2728
n. The serving GSM SGSN sends the result of the Forward Short Message to the IIF.2930
At this point, the IIF clears the MWN flag. The reception of the Forward Short Message Result31without error indicates that the MWN information was delivered successfully to the Mobile Station.32
33
X.S0023
2-195
4.13.5.2 ANSI-41 Qualification Directive mapped to GSM SMS1
GSMSGSN MS
e
f
g
h
FORW. SHORTMESSAGE (MWN)
SMS Delivery (MWN)
SMS DeliveryAck
Forw. Short Message
VMSANSI-41
HLR
a
b
c
VmailDelivery
“Message WaitingNotification”
QUALDIR(MWNCOUNT,MWNTYPE)
qualdir
IIF
d
2Figure 131: ANSI-41 Qualification Directive mapped to GSM SMS3
a. The Voice Mail System (VMS) receives a voice mail for a specific subscriber.45
b. The VMS send the “Message Waiting Notification” (MWN) to the ANSI-41 HLR of the voice mail6recipient. Note that the interface between the VMS and the ANSI-41 HLR is not standardized in7ANSI-41 [2].8
9c. Since the subscriber has a current valid location stored in the HLR, the HLR initiates a10
Qualification Directive message with the MWN information to the IIF acting as the serving11ANSI-41 MSC/VLR. The MWN information consists of two parameters:12MessageWaitingNotificationCount (MWNCOUNT) and MessageWaitingNotificationType13(MWNTYPE). For a description of these parameters, refer to the ANSI-41-D specifications,14sections 6.5.2.78 and 6.5.2.79 [2].15
16At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification17is to be delivered to the Mobile Station.18
19d. The IIF sends the result of the Qualification Directive message to the ANSI-41 HLR.20
21e. The IIF also originates an SMS with MWN information by sending a Forward Short Message to22
the serving GSM SGSN. The IIF is then acting as a GSM SMS-GMSC. The IIF is to encode the23MWN information in the SMS with three methods, namely, UDH, DCS, and CPHS. Refer to24Volume 3 for the encoding details.25
26f. The serving GSM SGSN sends the short message with the MWN information to the mobile27
station.2829
g. The mobile station acknowledges the delivery of the short message.3031
h. The serving GSM SGSN sends the result of the Forward Short Message to the IIF.3233
X.S0023
2-196
At this point, the IIF clears the MWN flag. The reception of the Forward Short Message Result1without error indicates that the MWN information was delivered successfully to the Mobile Station.2
X.S0023
2-197
4.13.5.3 Handling at SMS delivery failure at the SGSN or at the Mobile Station1
The IIF is to keep a Message Waiting Notification (MWN) flag for each subscriber in its database. In2the event of a failure to deliver a short message with MWN to the mobile station, the IIF is to keep3the MWN flag set. Another Forward Short Message with MWN information shall be sent, triggered4by the reception of a subsequent GSM Update Location message, a Ready for Short Message, or a5Note MS Present message. This is illustrated in the following diagram.6
7
Figure 132: Handling at SMS delivery failure at the SGSN or at the MS8a. The IIF receives Message Waiting Notification (MWN) information from a Qualification Directive9
or a Registration Notification Return Result. This was described in Sections 4.13.5.1 and104.13.5.2.11
12At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification13is to be delivered to the Mobile Station.14
15b. The IIF originates an SMS with MWN information by sending Forward Short Message using16
MAP V2 to the serving GSM SGSN. The IIF is then acting as a GSM SMS-GMSC. The IIF is to17encode the MWN information in the SMS with three methods, namely, UDH, DCS, and CPHS.18Refer to Volume 3 for the encoding details.19
IIFGSMSGSN MS
d
e
f
g
FORW. SHORTMSG (MWN) – V3
SMS Delivery (MWN)
SMS Delivery Error
Error, Abort,Reject, timeout
c
b
aMWN “Information”
Time elapsed
UPDATE GPRS LOCATION
h
i
j
k
FORW. SHORTMSG (MWN) – V3
SMS Delivery (MWN)
SMS Delivery AckForw. Short Message
READY FOR SM(AlertReason) – V3
“Acknowledgement”
l
m
n
X.S0023
2-198
1c. The serving GSM SGSN may attempt to deliver the short message or may immediately find out2
that there is an error and reply (step e below) to the IIF.34
d. The Mobile Station returns an error message to the SMS delivery.56
e. The serving GSM SGSN sends an Error, Abort or Reject message to the IIF, either resulting7from the reception of an error message from the MS or from an internal event such as an error8or a timeout. Note also, that a timeout may also occur in the IIF itself. Note that this may result9in the IIF setting the GSM 03.40 MNRF/MNRG/MCEF flag depending on the error cause10received (see section 4.13.3.1.3 “Unsuccessful Mobile Terminated Delivery (Failure at SGSN)”.11
12f. Time elapsed.13
14g. A new serving GSM SGSN sends an Update GPRS Location message to the IIF acting as a15
GSM HLR for that subscriber. Note that the normal Update Location sequence is not shown in16this diagram. Or it could be a17
18h. Ready for Short Message (MAP V3)19
2021
i. The IIF shall reply with the corresponding acknowledgement message. Upon receipt of g, h, or i22above, the procedures in section 4.13.3.1.5 “Alerting for an ANSI-41Subscriber for GPRS in23GSM Foreign Mode” apply (GSM 03.40 flags may be cleared and the SMSNOT may be sent to24the MC if appropriate).25
26j. Triggered by event g, h, or i above, the IIF originates a new Forward Short Message with MWN27
information to the serving GSM SGSN. The IIF is to encode the MWN information in the SMS28with three methods, namely, UDH, DCS, and CPHS.29
30k. The serving GSM SGSN sends the short message with the MWN information to the mobile31
station.3233
l. The mobile station acknowledges the delivery of the short message.3435
m. The serving GSM SGSN sends the result of the Forward Short Message to the IIF.363738
At this point, the IIF clears the MWN flag. The reception of the Forward Short Message Result39without error indicates that the MWN information was delivered successfully to the Mobile Station.40
41
X.S0023
2-199
4.13.6. Call Delivery Scenarios1
This section describes the scenarios for call delivery to an MS that is roaming in a GPRS network in2GSM foreign mode.3
4.13.6.1 Call Delivery Scenarios in GSM Foreign Mode while GSM CS and GPRS Attached4
5
4.13.6.1.1 Call Delivery to ANSI-41Subscriber Roaming on a GSM/GPRS Network6
Figure 133: Call Delivery to ANSI-41Subscriber Roaming in GSM/GPRS Network78
a. The originating ANSI-41 MSC receives an incoming call from the PSTN for a subscriber that is9roaming in a GSM/GPRS network. This MS is registered simultaneously with an SGSN and a10GSM MSC/VLR.11
b. The O-MSC sends a LOCREQ to the ANSI-41 HLR12
c. The ANSI-41 HLR knows the address of the IIF (acting as an ANSI-41 serving MSC) and sends13a ROUTEREQ to it14
d. The call may be delivered if the IIF determines that the called MS is registered with on a GSM15MSC/VLR. As such, the IIF (acting as a GSM HLR) sends the serving GSM MSC/VLR a MAP16Provide Roaming Number (PRN).17
e. The serving GSM MSC/VLR responds with a prn to the PRN operation providing a temporary18routing number.19
MS IIFMSCSGSN HLR
a
b
c
d
ef
g
h
i
GSM ANSI-41
O-MSC
Incoming call
LOCREQ
ROUTEREQ
routereq
locreq
ISUP signaling / SS7PAGING-REQ
Paging Procedure
SUSPEND To BSS
PRN
prn
j
k
X.S0023
2-200
f. The IIF forwards this number to the ANSI-41 HLR in the routereq.1
g. The ANSI-41 HLR forwards a locreq to the O-MSC with the temporary routing number.2
h. The O-MSC proceeds to contact the serving GSM MSC/VLR exchanging ISUP signaling for call3setup.4
i. The serving GSM MSC/VLR realizes that the MS is actually attached to an SGSN. So the GSM5serving MSC/VLR sends a BSSAP+PAGING-REQUEST to the SGSN.6
j. The SGSN executes a Paging procedure for circuit services.7
k. The MS sends a SUSPEND REQ to the BSS that may be forwarded to the SGSN. At this point,8the MS can respond to the page via GSM cell sites to the serving GSM MSC/VLR.9
X.S0023
2-201
4.13.6.1.2 Call Delivery to ANSI-41Subscriber Roaming in a GPRS Network (Unsuccessful)1
The following scenario describes the case where a subscriber in GSM foreign mode is roaming in a2GPRS network. The MS is attached for GPRS-only services. The IIF has already registered itself3(as an ANSI-41 MSC) with the ANSI-41 HLR. Since the MS is attached for GPRS-only service,4incoming calls are not deliverable to the subscriber. This scenario attempts to describe what5happens in the case of an incoming call to an MS attached for GPRS services only.6
7Figure 134: MS Notification of a “Missed” Call via SMS8
9
a. The O-MSC receives an incoming call for the subscriber roaming in the GSM network10
b. The O-MSC sends the HLR a LOCREQ11
c. The HLR has the address of the IIF (acting as an ANSI-41 MSC) and sends a ROUTEREQ to12the IIF13
d. The IIF recognizes that fact this is a GAIT subscriber roaming in a GSM network. The IIF, from14its dynamic data, sees that the subscriber is attached for GPRS-only services and hence,15cannot have call delivery. The IIF sends a routreq with the field “AccessDeniedReason” set to16“Unavailable” or “No Page Response”.17
e. The HLR returns a locreq to the O-MSC. At this point, the calling party may receive secondary18treatment.19
f. The IIF contains the functionality to act as an SMS-SC. In this case, the IIF has the calling party20DN available (from the ROUTEREQ message). The IIF proceeds to act as an SMS-SC and21
SGSN HLRIIF MSC
a
b
c
d
e
f
g
h
GSM ANSI-41
MS
Incoming call
LOCREQ
ROUTEREQ
routereq
locreq
FSM
fsm
SMS Exchange
X.S0023
2-202
sends an FSM to the SGSN requesting the SGSN to deliver an SMS message containing the1calling party’s DN to the MS.2
g. The SGSN sends the MS the SMS message containing the DN of the calling party and the MS3acknowledges receipt of the SMS message.4
h. The SGSN acknowledges the request and sends back an fsm.5
X.S0023
2-203
4.13.6.2 Successful Network-Requested PDP Context Activation Procedure1
The network requested PDP Context Activation procedure allows the GGSN to initiate the activation2of a PDP context when a data packet arrives for a particular PDP address and no PDP context has3been previously established.4
5
Figure 135: Successful Network Requested PDP context Activation6
7
a. When receiving a PDP PDU the GGSN follows the procedures described in GSM 03.60 [33]89
b. The GGSN may send a Send Routeing Information for GPRS (IMSI) message to the IIF.1011
c. The IIF determines if the request can be served. If the request can be served it returns a12Send Routeing Information for GPRS Ack (IMSI, SGSN Address) to the GGSN. If the request13cannot be served it returns a Send Routeing Information for GPRS Ack (IMSI, MAP Error14Cause).15
16
Activate PDP context Accept
Create PDP Context Response
Create PDP Context Request
Activate PDP context Request
SRI for GPRS
Ack
PDU Notification Request
Request PDP context Activation
SRI for GPRS
MS SGSN GGSN
a
b
c
d
e
f
g
IIF
PDP PDU
PDU Notification Response
Send Auth Info
Send Auth Info
Ack
h
i
j
k
l
X.S0023
2-204
d. Steps d through l are provided for completeness and are outside the scope of this1specification.2
Note: Certain security procedures as in step h) may be invoked.3
4.13.6.3 Unsuccessful Network-Requested PDP Context Activation Procedure4
If the PDP context requested by the GGSN cannot be established, the IIF in conjunction with the5SGSN and GGSN may perform the Protection and Mobile User Activity Procedures as described in6GSM 03.60 [33]. The IIF acting as a GPRS HLR shall follow the same procedures as the GSM7HLR.8
4.13.7 Packet Domain Subscriber Data in the IIF9GPRS subscriber data shall be provisioned in the IIF (emulating a GPRS HLR) to support GPRS10service capability in GSM Foreign mode. The IIF shall store the same subscription information as11identified in GSM 03.60 [33].12
It may be possible to provision an ANSI-41native subscriber with GPRS-only service (and no GSM13CS service)14
X.S0023
2-205
Annex A (informative)1
The following is an example of some of the timers defined in existing ANSI-41 and GSM2specifications.3
As an example, the GSM timer controlling, the Update Location Request is defined to be in the4range 15s to 30s whereas the equivalent ANSI-41 timer controlling the REGNOT is defined to be a5default value of 12s.6
7
LOCATION REGISTRATION PROCEDURESGSM
OperationTimer Value ANSI-41
OperationTimer Value
UpdateLocationRequest
15s to 30s REGNOT 12s
Insert SubData
15s to 30s
CALL DELIVERY PROCEDURESGSM
OperationTimer Value ANSI-41
OperationTimer Value
ProvideRoamingNumber
15s to 30s ROUTREQ 10s
SUBSCRIBER DATA MANAGEMENT PROCEDURESGSM
OperationTimer Value ANSI-41
OperationTimer Value
CancelLocationRequest
15s to 30s REGCANC 6s
Delete SubData
15s to 30s QUALDIR 6s
SUPPLEMENTARY SERVICE PROCEDURESGSM
OperationTimer Value ANSI-41
OperationTimer Value
REGISTERSS
15s to 30s FEATREQ 16s
ERASE SS 15s to 30sACTIVATE SS 15s to 30sDE-ACTIVATE
SS15s to 30s
X.S0023
2-206
OPTIMAL ROUTING PROCEDURESGSM
OperationTimer Value ANSI-41
OperationTimer Value
Resume CallHandling
15s to 30s REDREQ 22s
TRANUMREQ 16sSHORT MESSAGE PROCEDURES
GSMOperation
Timer Value ANSI-41Operation
Timer Value
Forward SM 1m to 10m SMDPP 6s1
Notes: GSM timer values are defined as a range of values, whereas ANSI-41 defines a default timer2value.3
X.S0023
2-207
Annex B - CDMA to GSM One-way Roaming Only1
Optionally, IIF may support one way-roaming only from CDMA to GSM network. In this case, all the2flows below are applicable only in GSM Foreign Mode. ANSI-41 HLR/AC must be compliant with3TIA/EIA-868 [11]. All the changes are made on the assumption the new requirements for4UIM/handsets are working.5
B.1 Successful Authentication on Initial Access in GSM System6
7This scenario illustrates the successful authentication of an MS on the initial MS access is a GSM8system9
10
Figure 136 – Successful Authentication on Initial Access in GSM System11
12
a) The MS determines that a new serving system has been entered. The MS registers at the new GSM13serving system and provides its IMSI.14
15b) The GSM serving system sends a SEND_AUTHENTICATION_INFO to the IIF.16
ACHLR
IIF
SEND_AUTH_INFO (IMSI)
AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC) AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC) Authreq (SSD, ESN)
Authreq (SSD, ESN)
SEND_AUTH_INFO ack (AuthenticationSetList)
UPDATE LOCATION (IMSI)
MS
authentication (RAND)
authentication ack (SRES)
a
b
c
d
e
f
h
i
j
k
l
m
MSC/VLR
ANSI-41 GSM
Location area update (IMSI)
AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC) AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC)
ASREPORT (MSCID, MSID, UCHALRPT)
ASREPORT (MSCID, MSID, UCHALRPT)
asreport[] n
g
o
REGNOT [MSCID, TRANSCAP, SYSCAP, MSID, ESN, SYSAC]
ART ART
ASRRT
ASRRT ASRRT asreport[]
ASRT
X.S0023
2-208
1c) The IIF sends an AUTHREQ to the HLR associated with the MS. The MSCID parameter identifies the2
IIF. The SYSCAP parameter is set to indicate GSM system. The ESN parameter is set to a default3value. The SYSACCTYPE parameter is set to indicate GSM system access.4
5d) The HLR forwards the AUTHREQ to the AC.6
7e) The AC determines that the subscriber is roaming in a GSM system. The AC includes the SSD8
parameter in the authreq sent to the HLR. The ESN parameter is set to the indicated MS’s ESN.910
f) The HLR forwards the authreq to the IIF.1112
g) The IIF stores the received SSD and ESN. The IIF computes one or more groups of GSM triplets using13the subscriber’s SSD. The IIF sends a SEND_AUTHENTICATION_INFO ack to the GSM system and14includes the groups of triplets.15
16h) The GSM system issues a random challenge to the MS17
18i) The MS responds to the challenge with the computed response.19
20j) The GSM system compares the response received from the MS with the expected response. In this21
scenario, the response is equal to the expected response. The GSM system sends a22UPDATE_LOCATION to the IIF. The IMSI is used to identify the MS.23
24k) The IIF sends an ASREPORT to the HLR associated with the MS. The UCHALRPT parameter is set25
to indicate Unique Challenge successful.2627
l) The HLR forwards the ASREPORT to the AC.2829
m) The AC sends an asreport to the HLR.3031
n) The HLR forwards the asreport to the IIF.3233
o) The IIF sends a REGNOT to the HLR3435
p) The HLR sends a regnot to the IIF with the subscriber’s service profile3637
q) The IIF sends an INSERT_SUBSCRIBER_DATA to the GSM system.3839
r) The GSM systems sends an INSERT_SUBSCRIBER_DATA ack to the IIF.4041
s) The IIF sends an LOCATION_UPDATE ack to the GSM system.4243
t) The GSM system sends a location area update ack to the MS.444546
X.S0023
2-209
B. 2 Authentication Failure on Initial Access in GSM System1
This scenario illustrates an authentication failure on the initial MS access is a GSM system.2The GSM system reports the authentication failure to the IIF.3
ACHLR
IIF
SEND_AUTH_INFO (IMSI)
AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC) AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC) Authreq (SSD, ESN)
Authreq (SSD, ESN)
SEND_AUTH_INFO ack (AuthenticationSetList)
AUTHENTICATION FAILURE (IMSI)
MS
authentication (RAND)
authentication ack (SRES)
a
b
c
d
e
f
h
i
j
k
l
m
MSC/VLR
ANSI-41 GSM
Location area update (IMSI)
AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC) AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC)
ASREPORT (MSCID, MSID, UCHALRPT)
ASREPORT (MSCID, MSID, UCHALRPT)
asreport[DENACC] n
p
g
o
AUTHENTICATION_FAILURE
location area update reject
ART ART
ASRRT
ASRRT ASRRT asreport[DENACC]
4Figure 137 - Authentication Failure on Initial Access in GSM System5
X.S0023
2-210
a-i. Same as Scenario 5.Y.1, Steps a-i.12
j) The GSM system compares the response received from the MS with the expected response. In this3scenario, the response does equal to the expected response. The GSM system sends an4AUTHENTICATION_FAILURE to the IIF. The subscriber’s IMSI is used to identify the MS.5
6k) The IIF sends an ASREPORT to the HLR associated with the MS. The UCHALRPT parameter is set7
to indicate Unique Challenge failed.89
l) The HLR forwards the ASREPORT to the AC.1011
m) The AC includes the DENACC parameter and sends an asreport to the HLR.1213
n) The HLR forwards the asreport to the IIF. The IIF removes the SSD, ESN and other information14stored for the MS.15
16o) The IIF sends an AUTHENTICATION_FAILURE ack to the GSM system.17
18p) The GSM system sends a location area update reject to the MS.19
X.S0023
2-211
B.3 Authentication Failure on Initial Access in GSM System –1Authentication Failure Message Not Supported2
3This scenario illustrates an authentication failure on the initial MS access is a GSM system. The GSM4system doe not report the authentication failure to the IIF5
ACHLR
IIF
SEND_AUTH_INFO (IMSI)
AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC) AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC) Authreq (SSD, ESN)
Authreq (SSD, ESN)
SEND_AUTH_INFO ack (AuthenticationSetList)
Location area update reject
MS
authentication (RAND)
authentication ack (SRES)
a
b
c
d
e
f
h
i
j
k
l
m
MSC/VLR
ANSI-41 GSM
Location area update (IMSI)
AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC) AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC)
ASREPORT (MSCID, MSID, UCHALRPT)
ASREPORT (MSCID, MSID, UCHALRPT)
asreport[DENACC]
n
g
o
ART ART
ASRRT
ASRRT ASRRT asreport[DENACC]
timer expiry
timer
67
Figure 138 - Authentication Failure on Initial Access in GSM System – Authentication Failure Message8Not Supported9
10a-i. Same as Scenario 5.Y.1, Steps a-i.11
12j) The GSM system compares the response received from the MS with the expected response. In this13
scenario, the response does equal to the expected response. The GSM system compares the response14received from the MS with the expected response. In this scenario, the response does equal to the15expected response. The GSM system sends a location area update reject to the MS.16
17k) An IIF timer expires when no message for the MS is received from the GSM system.18
19l) The IIF sends an ASREPORT to the HLR associated with the MS. The UCHALRPT parameter is set20
to indicate Unique Challenge failed.21
X.S0023
2-212
1m) The HLR forwards the ASREPORT to the AC.2
3n) The AC includes the DENACC parameter and sends an asreport to the HLR.4
5o) The HLR forwards the asreport to the IIF. The IIF removes the SSD, ESN and other information stored6
for the MS.78
X.S0023
2-213
B.4 GSM System Request for Additional Triplets1
This scenario illustrates a GSM system requesting addition triplets after the MS is register in the serving GSM2system.3
4
Figure 139 - GSM System Request for Additional Triplets5
6a) The GSM system determines that additional triplets are required and sends a7
SEND_AUTHENTICATION_INFO to the IIF. The IMSI identifies the subscriber.8b) The IIF computes one or more groups of triplets and includes them in the response to9
the GSM system. (Note, the IIF may have pre-computed triplets for the MS that it10sends to the GSM system).11
12
ACHLR
IIF
SEND_AUTHENTICATION_INFO (IMSI)
Authreq (SSD, ESN)
SEND_AUTH_INFO ack (AuthenticationSetList)
Location area update reject
MS
authentication (RAND)
authentication ack (SRES)
a
b
d
e
f
h
i
j
k
l
m
MSC/VLR
ANSI-41 GSM
AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC)
ASREPORT (MSCID, MSID, UCHALRPT)
ASREPORT (MSCID, MSID, UCHALRPT)
asreport[DENACC]
n
g
o
ASRRT
ASRRT ASRRT asreport[DENACC]
timer expiry
timer
X.S0023
3-i
NNNeeetttwwwooorrrkkk IIInnnttteeerrrwwwooorrrkkkiiinnnggg BBBeeetttwwweeeeeennn GGGSSSMMM MMMAAAPPP aaannnddd TTTIIIAAA---444111 MMMAAAPPP;;;1
RRReeevvviiisssiiiooonnn BBB ––– CCCDDDMMMAAA222000000000 SSSuuuppppppooorrrttt2
VVVooollluuummmeee 333 ––– MMMeeessssssaaagggeee MMMaaappppppiiinnngggsss3
(((RRReeevvviiisssiiiooonnn ooofff JJJ---SSSTTTDDD---000333888---AAA VVVooollluuummmeee 333)))4
Abstract5
This volume contains the mappings between GSM MAP messages and TIA-41 MAP messages.6
X.S0023
3-ii
Contents1
ABSTRACT.................................................................................................................................................... I2
CONTENTS................................................................................................................................................... II3
LIST OF TABLES........................................................................................................................................IV4
LIST OF FIGURES ......................................................................................................................................XI5
FOREWORD ...............................................................................................................................................XII6
1 INTRODUCTION ...................................................................................................................................17
1.1 General..............................................................................................................................................................18
1.2 Purpose..............................................................................................................................................................19
1.3 Scope..................................................................................................................................................................110
4 MESSAGE MAPPINGS ........................................................................................................................211
4.1 Mobility Procedures ........................................................................................................................................2124.1.1 Location Registration ................................................................................................................................2134.1.2 Fault Recovery.........................................................................................................................................1514
4.2 Call Handing Procedures..............................................................................................................................19154.2.1 Automatic Call Delivery .........................................................................................................................19164.2.2 Invocation of Conditional Call Forwarding in ANSI-41 Foreign Mode...............................................32174.2.3 Optimal Routing after Late Call Forwarding .........................................................................................3618
4.3 Supplementary Services Procedures...........................................................................................................45194.3.2 SS Registration and Erasure....................................................................................................................61204.3.3 Retrieval of Forward-To Number ...........................................................................................................83214.3.4 Calling Number / Line Identification Presentation/Restriction.............................................................8722
4.4 O&M Procedures...........................................................................................................................................92234.4.1 Detailed Procedures.................................................................................................................................92244.4.2 Mapping of Messages, Parameters & Parameter Values .......................................................................93254.4.3 Error Handling.......................................................................................................................................11126
4.5 Short Message Procedures (ANSI-41 Network) ......................................................................................116274.5.1 Short Message Service via CMT ..........................................................................................................116284.5.2 Short Message Service via GHOST or WEMT ...................................................................................132294.5.3 Message Waiting Notification ..............................................................................................................14230
4.6 GPRS IN GSM FOREIGN MODE.............................................................................................151314.6.1 Mobility Procedures ..............................................................................................................................151324.6.2 Automatic Call Delivery .......................................................................................................................15933
X.S0023
3-iii
4.6.3 Short Message Procedures for ANSI-41 subscriber.............................................................................16214.6.4 Short Message Service via GHOST or WEMT ...................................................................................16524.6.5 Message Waiting Notification ..............................................................................................................1663
ANNEX A SHORT MESSAGE SERVICE PROCEDURES WITHIN AN ANSI-136 NETWORK..........1684
A.1 CMT to GHOST Delivery...........................................................................................................................1685A.1.1 Detailed Procedures...............................................................................................................................1686A.1.2 Mapping of Messages, Parameters & Parameter Values .....................................................................1697A.1.3 Error Handling.......................................................................................................................................1708
A.2 GHOST to CMT Delivery...........................................................................................................................1709A.2.1 Detailed Procedures...............................................................................................................................17010A.2.2 Mapping of Messages, Parameters & Parameter Values .....................................................................17211A.2.3 Error Handling.......................................................................................................................................17612
A.3 Callback Number.........................................................................................................................................17713A.3.1 Detailed Procedures...............................................................................................................................17714A.3.2 Message Mapping, Parameters and Parameters Values.......................................................................17815A.3.3 Error Handling.......................................................................................................................................17816
ANNEX B CAUSE CODE MAPPING AT NON-IIF NODES...................................................................17917
ANNEX C: CDMA TO GSM ONE-WAY ROAMING ONLY....................................................................1811819
X.S0023
3-iv
List of Tables1
2
Table 1: Location Updating in GSM Foreign Mode Message Mapping............................................... 53
Table 2: Location Updating in ANSI-41 Foreign Mode Message Mapping ......................................... 54
Table 3: MS Purging Message Mapping............................................................................................... 65
Table 4: Location Cancellation Message Mapping............................................................................... 66
Table 5: UPDATE_LOCATION_REQUEST REGNOT Parameter Mapping.................................. 77
Table 6: INSERT_SUBSCRIBER_DATA_REQUEST regnot Parameter Mapping ....................... 88
Table 7: UPDATE LOCATION RESPONSE regnot Parameter Mapping....................................... 99
Table 8: MS_PURGE_REQUEST MS INACTIVE Parameter Mapping ......................................... 910
Table 9: CANCEL_LOCATION_REQUEST REGCAN Parameter Mapping................................ 1011
Table 10: UPDATE_LOCATION_RESPONSE to regnot Error Mapping .......................................... 1412
Table 11: regnot return errors to UPDATE_LOCATION_RESPONSE Error Mapping..................... 1513
Table 12 Fault Recovery Message Mapping ...................................................................................... 1614
Table 13: GSM RESET ANSI UNRELDIR Parameter Mapping ................................................... 1715
Table 14: Automatic Call Delivery Message Mapping........................................................................ 2116
Table 15: ROUTREQ PROVIDE_ROAMING_NUMBER_REQUEST Parameter17Mapping ............................................................................................................................. 2218
Table 16: Provide Roaming Number Response Routreq Return Result Parameter19Mapping ............................................................................................................................. 2420
Table 17: PROVIDE_ROAMING_NUMBER_RESPONSE to Routreq Return Error Mapping21(ANSI-41Foreign Mode) .................................................................................................... 2422
Table 18: Routreq Return Error to Provide Roaming Number Response Error Mapping23(GSM Foreign mode) ........................................................................................................ 2524
Table 19: Provide Roaming Number Request default parameter...................................................... 2525
Table 20: RoutingRequest Return Result default parameters ........................................................... 2626
Table 21: Routing Request Invoke default parameter........................................................................ 2727
Table 22: PRN response User Error to routreq Return Error Mapping ............................................ 3028
X.S0023
3-v
Table 23: PRN Response Provider Error to routereq Return Error Mapping.................................... 311
Table 24: RoutingRequest Return Result to User Error in the PRN response Error Mapping......... 312
Table 25: Routing Request Return Error to PRN User Error Mapping.............................................. 313
Table 26: ROUTEREQ Return Result to Provide Roaming Number Response parameter4mapping (Option 1)............................................................................................................ 345
Table 27: ROUTREQ Return Result to Provide Roaming Number Response Parameter6Mapping (Option 2)............................................................................................................ 347
Table 28: Return Error to User Error in the PRN response Error Mapping....................................... 368
Table 29: Optimal Routing for Late Call Forwarding Message Mapping........................................... 389
Table 30: GSM Provide_Roaming_Number ANSI-41 ROUTEREQ Parameter Mapping ........... 3910
Table 31: Mapping of Parameter values ............................................................................................. 4011
Table 32: Provide_Roaming_Number_Response routereq Parameter Mapping ........................ 4012
Table 33: Mapping of Parameter Values ............................................................................................ 4113
Table 34: Resume_Call_Handling REDREQ Parameter Mapping............................................... 4114
Table 35: Mapping of Parameters Values........................................................................................... 4115
Table 36: Resume_Call_Handling_Response redreq Parameter Mapping ................................. 4116
Table 37: ANSI-41 Redirection_Reason to GSM Forwarding_Reason............................................. 4217
Table 38: GSM Forwarding_Reason to ANSI-41 Redirection_Reason............................................. 4218
Table 39: Provide_Roaming_Number to Routing_Request Error Mapping ...................................... 4319
Table 40: Routing_Request to Provide_Roaming_Number Error Mapping ...................................... 4320
Table 41: Resume_Call_Handling to Redirection_Request Error Mapping...................................... 4421
Table 42: Redirection_Request to Resume_Call_Handling Error Mapping...................................... 4422
Table 43: Supplementary Service Activation and Deactivation Message Mapping.......................... 4723
Table 44: Activate/Deactivate SS Request FEATREQ Parameter Mapping................................ 4824
Table 45: Activate/Deactivate SS Response Feature Request Return Result Parameter25Mapping ............................................................................................................................. 4926
Table 46: Activate/Deactivate SS Response Feature Request Return Error Mapping ............... 5027
Table 47: Activate/Deactivate SS Request to FEATREQ Parameter Mapping ................................ 5028
X.S0023
3-vi
Table 48: FEATREQ default parameter.............................................................................................. 511
Table 49: Activate/Deactivate SS Response default parameter values............................................ 522
Table 50: Feature Request Invoke to Activate/Deactivate SS Request Parameter Mapping .......... 533
Table 51: Activate/Deactivate SS Request default parameter........................................................... 534
Table 52: FeatureRequest Return Result default parameter............................................................. 545
Table 53: FeatureRequest Return Result to User Error in the Activate/Deactivate SS6Response Error Mapping .................................................................................................. 577
Table 54: FeatureRequest Return Error to Activate/Deactivate SS Response Error8Mapping ............................................................................................................................. 579
Table 55: Activate/Deactivate SS Response User Error to FeatureRequest Return Result10Mapping ............................................................................................................................. 5811
Table 56: Activate/Deactivate SS Response User Error to FeatureRequest Return Error12Mapping ............................................................................................................................. 5913
Table 57: Activate/Deactivate SS Response Provider Error to Feature Request Return14Error Mapping.................................................................................................................... 6015
Table 58: Supplementary Service Registration Message Mapping................................................... 6316
Table 59: Register SS Request FEATREQ parameter mapping .................................................. 6417
Table 60: Register SS Response Feature Request Return Result Parameter Mapping............. 6518
Table 61: Register SS Response Return Error Parameter Mapping............................................ 6619
Table 62: Register SS Request to Feature Request Invoke parameter mapping............................. 6620
Table 63: FEATREQ default parameter.............................................................................................. 6721
Table 64: Register SS Response default parameter values.............................................................. 6822
Table 65: FEATREQ to Register SS Request parameter mapping................................................... 6923
Table 66: Register SS Request default parameter............................................................................. 6924
Table 67: FeatureRequest Return Result default parameter............................................................. 7025
Table 68: FeatureRequest Return Result to User Error in the Register SS Response26mapping ............................................................................................................................. 7127
Table 69: Supplementary Service Erasure Message Mapping.......................................................... 7428
Table 70: Erase SS Request FEATREQ parameter mapping ...................................................... 7529
Table 71: Erase SS Response Feature Request Return Result parameter mapping ................. 7630
X.S0023
3-vii
Table 72: Erase SS Response Return Error parameter mapping ................................................ 771
Table 73: Erase SS Request to FEATREQ parameter mapping....................................................... 772
Table 74: Feature Request Invoke default parameter........................................................................ 783
Table 75: Erase SS Response default parameter values .................................................................. 794
Table 76: FEATREQ to Erase SS Request parameter mapping...................................................... 795
Table 77: Erase SS Request default parameter................................................................................. 806
Table 78: FeatureRequest Return Result default parameter............................................................. 817
Table 79: FeatureRequest Return Result to Register SS Response User Error .............................. 828
Table 80: Retrieval of Forward-to-Number in GSM Foreign Mode.................................................... 849
Table 81: TransferToNumberRequest Return Result to Insert Subscriber Data parameter10mapping ............................................................................................................................. 8511
Table 82: TransferToNumberRequest Return Result to Insert Subscriber Data Request12value mapping ................................................................................................................... 8613
Table 83: Routing Request Provide Roaming Number Request (Network Provided14number) Parameter Mapping............................................................................................ 8815
Table 84: Routing Request Provide Roaming Number Request (User Provided number)16Parameter Mapping........................................................................................................... 8917
Table 85: Routing Request Provide Roaming Number Request (Two calling party18numbers) Parameter Mapping.......................................................................................... 9019
Table 86: Routing Request Provide Roaming Number Request(Caller Id Restricted)20Parameter Mapping........................................................................................................... 9121
Table 87: Cancel_Location_Request REGCAN (Subscriber Deletion) Mapping......................... 9322
Table 88: Mapping of GSM MAP Messages ANSI MAP Messages (Subscriber Data23Modification) ...................................................................................................................... 9324
Table 89: Delete_Subscriber_Data Qualdir Mapping (Subscriber Data Modification)................. 9425
Table 90: CANCEL_LOCATION_REQUEST REGCAN Parameter Mapping.............................. 9426
Table 91: INSERT_SUBSCRIBER_DATA_REQUEST QUALDIR Parameter Mapping ............. 9527
Table 92: INSERT_SUBSCRIBER_DATA_REQUEST profile ‘macro’ Mapping ......................... 9628
Table 93: Forwarding Information List to Calling Features Indicator Parameter Mapping ............... 9829
Table 94: Regional Subscription Data to Geographic Authorization Parameter Mapping.............. 10030
X.S0023
3-viii
Table 95: Call Barring Information List to Origination Indicator Parameter Mapping ..................... 1011
Table 96: SSData List to Calling Features Indicator Parameter Mapping....................................... 1032
Table 97: Operator Determined Barring general data to Origination Indicator3Parameter Mapping......................................................................................................... 1054
Table 98: Operator Determined Barring HPLMN data to Origination Indicator Parameter5Mapping ........................................................................................................................... 1066
Table 99: Operator Determined Barring HPLMN data to Restriction digits Parameter7Mapping ........................................................................................................................... 1068
Table 100: Call Barring Information List to SMS Origination Restrictions Parameter9Mapping ........................................................................................................................... 10710
Table 101: Call Barring Information List to SMS Termination Restrictions Parameter11Mapping ........................................................................................................................... 10812
Table 102: Call Barring Information List to Termination Restriction Code Parameter13Mapping ........................................................................................................................... 10914
Table 103: SSData List to SMS Origination Restrictions Parameter Mapping ............................... 11015
Table 104: SSData List to SMS Termination Restrictions Parameter Mapping.............................. 11016
Table 105: ISD_RESPONSE and DSD_RESPONSE to Qualdir Return Error Mapping................ 11517
Table 106: Qualdir Return Error to INSERT_SUBSCRIBER_DATA_RESPONSE and18DELETE_SUSBCRIBER_DATA_RESPONSE Error Mapping ..................................... 11519
Table 107: Short Message Service in GSM Foreign Mode (for CMT) Message Mapping ............. 11920
Table 108: Short Message Service in ANSI-41 Foreign Mode (for CMT) Message Mapping ...... 11921
Table 109: SMDPP to MT_Forward Short Message Parameter Mapping for GSM Foreign22Mode ................................................................................................................................ 12023
Table 110: MT_Forward Short Message to SMDPP Parameter Mapping for ANSI-4124Foreign Mode .................................................................................................................. 12025
Table 111: SM-RP-UI in MT_FORWARD_SHORT_MESSAGE for MAP V2 Parameter26Values for GSM Foreign Mode ....................................................................................... 12127
Table 112: SM-RP-UI in MT_FORWARD_SHORT_MESSAGE for MAP V1 Parameter28Encoding for GSM Foreign Mode................................................................................... 12229
Table 113: SMS_Bearer Data in Mobile Terminating SMDPP Parameter Encoding for30ANSI-41 Foreign Mode ................................................................................................... 12331
Table 114: Forward_Short_Message to ANSI-41_SMDPP Parameter Mapping for MO SMS32in GSM Foreign Mode..................................................................................................... 12433
X.S0023
3-ix
Table 115: ANSI-41 SMDPP to GSM Forward_Short_Message Parameter Mapping for MO1SMS in ANSI-41 Foreign Mode ...................................................................................... 1262
Table 116: Forward_Short_Message to SMS_CauseCode Values in SMDPP Return Result3Error Mapping.................................................................................................................. 1304
Table 117: SMDPP to Forward_Short_Message Error Mapping..................................................... 1315
Table 118: Short Message Service (for GHOST or WEMT) Message Mapping............................. 1356
Table 119: Alerting for an ANSI-41 Subscriber in GSM Foreign Mode Parameter Mapping ......... 1367
Table 120: Alerting for a GSM Subscriber in ANSI-41 Foreign Mode Parameter Mapping ........... 1368
Table 121: SMDPP to Forward Short Message for Mobile Terminated GHOST/WEMT9Teleservice Parameter Mapping in GSM Foreign Mode ............................................... 13710
Table 122: Forward Short Message to SMDPP for Mobile Terminated GHOST/WEMT11Teleservice Parameter Mapping in ANSI Foreign Mode............................................... 13812
Table 123: Forward Short Message to SMDPP for Mobile Originated GHOST/WEMT in13GSM Foreign Mode Parameter Mapping ....................................................................... 13914
Table 124: SMDPP to Forward Short Message for Mobile Originated GHOST/WEMT15Teleservice Parameter Mapping in ANSI-41 Foreign Mode.......................................... 14016
Table 125: HLPI for GHOST.............................................................................................................. 14117
Table 126: Teleservice Server Address Mapping in IIF ................................................................... 14218
Table 127: Message Waiting Notification in GSM Foreign Mode Message Mapping..................... 14419
Table 128: Message Waiting Notification in ANSI-41 Foreign Mode Message Mapping ............... 14520
Table 129: regnot to Forward Short Message for Message Waiting Notification Parameter21Mapping ........................................................................................................................... 14522
Table 130: QUALDIR to Forward Short Message for Message Waiting Notification23Parameter Mapping......................................................................................................... 14624
Table 131: Forward Short Message to QUALDIR for Message Waiting Notification25Parameter Mapping......................................................................................................... 14626
Table 132: Forward Short Message to SMDPP for Message Waiting Notification Parameter27Mapping ........................................................................................................................... 14628
Table 133: SM-RP-UI in Message FORWARD-SHORT-MESSAGE For MAP V2 Parameter29Encoding.......................................................................................................................... 14730
Table 134: SM-RP-UI in Message FORWARD_SHORT-MESSAGE for MAP V1 Parameter31Encoding.......................................................................................................................... 14932
X.S0023
3-x
Table 135: qualdir return error to FORWARD_SHORT_MESSAGE response Error1Mapping ........................................................................................................................... 1502
Table 136: SMSDPP to FORWARD_SHORT_MESSAGE response Error Mapping..................... 1503
Table 137: Location Updating GPRS in GSM Foreign Mode Message Mapping ........................... 1524
Table 138: MAP_UPDATE_GPRS_LOCATION_REQUEST REGNOT Parameter5Mapping ........................................................................................................................... 1536
Table 139: MAP_INSERT_SUBSCRIBER_DATA_REQUEST regnot Parameter Mapping...... 1547
Table 140: MAP_UPDATE GPRS LOCATION RESPONSE regnot Parameter Mapping ......... 1558
Table 141: MAP_INSERT_SUBSCRIBER_DATA_REQUEST profile ‘macro’ Mapping............ 1569
Table 142: ROUTREQ MT_Forward Short Message Parameter Mapping................................ 16010
Table 143: Alerting for an ANSI-41 Subscriber for GPRS in GSM Foreign Mode Parameter11Mapping ........................................................................................................................... 16312
Table 144: ANSI-136-710 to GHOST Parameter Mapping.............................................................. 16913
Table 145: TP Derived Values........................................................................................................... 17014
Table 146: GHOST to ANSI-136-710 Parameter Mapping.............................................................. 17215
Table 147: CMT Derived Values ....................................................................................................... 17316
Table 148: SMS_CauseCode to TP-STATUS Mapping................................................................... 17417
Table 149: SMS-STATUS-REPORT Derived Values....................................................................... 17618
Table 150: RP-ERROR Cause to R-Cause for Mobile Station Response to Mobile19Terminated Transfer Attempt.......................................................................................... 17920
Table 151: ANSI-41 SMS_CauseCode to ANSI-136 R-Cause Code Mapping .............................. 18021
Table 152: ANSI-136 R-Cause Code to RP-ERROR Cause Mapping within the Mobile22Station.............................................................................................................................. 18023
Table 153: UPDATE_LOCATION_REQUEST ->REGNOT Parameter Mapping ........................... 18124
25
X.S0023
3-xi
List of Figures1
2
There are no figures in this volume.3
X.S0023
3-xii
Foreword1
2
This foreword is not part of this standard.3
This standard addresses the interworking and interoperability between ANSI-41 MAP and GSM4based networks in the support of subscribers roaming between networks. The objective of the5standard is to achieve fully automatic, two-way interoperability between the heterogeneous6networks. Services supported by this standard are described along with the associated information7flows and message mappings. However, not all services and associated capabilities of ANSI-418MAP and GSM MAP are supported by this standard. In general the attempt has been to focus on9the key subscriber services needed in the market.10
The focus of this standard is on common GSM and ANSI-136/TIA-2000 TDMA and CDMA services11and associated network signaling (i.e. ANSI-41 MAP and GSM MAP). A pre-requisite for this12interoperability is Multi-mode mobile stations with an enhanced SIM card for roaming between13ANSI-41 and GSM networks.14
The first release of the standard did not define or require changes to existing ANSI-41 MAP or GSM15MAP to achieve the described interworking and interoperability. However, due to differences16between the services and associated capabilities of the MAP protocols, complete and fully17transparent interoperability may not have been achieved for some services. Future releases of this18standard may require changes to ANSI-41 MAP, GSM MAP and the associated services to achieve19full transparency while roaming between the different networks.20
Aspects of TIA/EIA-136 Revision C have been incorporated into this standard.21
Revision A added the capability of getting GPRS services when roaming in GSM Foreign Mode.22
Revision B added two way roaming between GSM and CDMA systems23
X.S0023
3-1
1 Introduction1
2
1.1 General3
When a subscriber to one network type (e.g., ANSI-41) roams to a network of another type4(e.g., GSM), interworking and interoperability functions are required to support roaming and5enable service. This standard describes an Interworking and Interoperability Function (IIF) to6support this cross-technology roaming between ANSI-41 and GSM networks. The IIF supports7a multi-mode mobile station with a removable Subscriber Identity Module (SIM). The standard8also defines the required network message mappings between ANSI-41 MAP and GSM MAP to9support the mobile terminal and associated services.10
This standard includes the support of cross-technology roaming from an ANSI-41 based11network to a GPRS network. The GPRS network may be coupled with a GSM network. This12feature requires enhancement to the Interworking and Interoperability Function (IIF) which13supports a multi-mode mobile station and Subscriber Identity Module (SIM) with GPRS14functionality. GPRS foreign mode roaming requires a subscription in the GSM domain. There is15no interaction with the CDMA packet data network infrastructure defined.16
Optionally, IIF may support one way-roaming only from CDMA to GSM network. In this case, all17the relevant mapping tables described are applicable only in GSM Foreign Mode and for this18scenario they apply as unidirectional only. (Annex C)19
1.2 Purpose20
The purpose of this standard is to define and describe the functions necessary for roaming21between ANSI-41 MAP and GSM MAP based networks in the support of roaming subscribers.22This includes a capability to allow a subscriber to an ANSI-41 based network (e.g., an ANSI-4123TDMA or CDMA native subscriber) with a mobile terminal supporting GPRS service to roam to24a GPRS network in GSM Foreign Mode.25
1.3 Scope26
The scope of this standard is the services, information flows, and message mappings which27require interworking and interoperability functional specifications to support roaming between28ANSI-41 MAP [2] and GSM MAP [4] networks.29
The scope of this volume is to describe the processing, messages and parameters for30GPRS/GSM and ANSI-41 network interoperability.31
X.S0023
3-2
4 Message Mappings1
2
The IIF shall perform the translation of messages, parameters and parameter values in3accordance with the tables included in this volume of the standard. The following notation is4used in accordance with the definitions given in GSM 09.02 [4] and ANSI-41 [2].5
Within the following tables, the parameters are identified as either being:6
M Mandatory,7
C Conditional8
O Service Provider Optional9
U Service User Optional10
The following notation is used in this standard to identify parameters as being syntactically11optional but semantically required to be sent by the IIF in order to support interoperability:12
R Required.13
Refer to GSM 09.02 [4] and ANSI-41 [2] for a description of the messages, parameters and14parameter values.15
When the IIF receives either a GSM MAP message or an ANSI MAP message, it shall apply16the following rules regarding the handling of parameters within those messages:17
The IIF shall populate mandatory parameters in messages sent by the IIF, regardless18of whether mapping of parameters is possible.19
The IIF may populate optional parameters in messages sent by the IIF, regardless of20whether mapping of parameters is possible.21
All parameters shall be populated in accordance with GSM 09.02 [4] and ANSI-41 [2].22
Where there is no direct mapping for parameters, a hyphen (‘-‘) has been entered in the23corresponding table.24
25
4.1 Mobility Procedures26
Existing mobility procedures described in either GSM 09.02 [4] or ANSI-41 [2] are also directly27applicable to the IIF when it is emulating a GSM or ANSI-41 functional network element.28Enhancements/modifications to ANSI-41 [2] are also applicable.29
4.1.1 Location Registration30The location registration procedure is used to update the location information held in the31network. This location information is used to route incoming calls and short messages to the32roaming subscriber.33
The Location registration procedure is also used to cancel location information held in the34network.35
X.S0023
3-3
4.1.1.1 Detailed Procedures12
4.1.1.1.1 Location Updating34
The IIF contains location information (vlr number) relating to the roaming subscriber. Therefore,5the IIF needs to be updated at each change in VLR. The IIF shall translate GSM MAP6messages to ANSI-41 MAP messages and vice versa, when the subscribers home HLR needs7updating. The subscriber’s home HLR needs to be updated only in the following cases:8
When the subscriber’s MS registers in a GSM network, when previously registered in9an ANSI-41 network;10
When the subscribers MS registers in an ANSI-41 network, when previously registered11in a GSM network;12
Optionally, the subscriber’s home HLR may be updated in the following cases:13
When the subscribers MS (accessing a GSM Network) registers in another VLR within14the same GSM network;15
When the subscribers MS (accessing an ANSI-41 Network) registers in another VLR16within the same ANSI-41 network;17
When the HLR is updated, the IIF conveys a unique identifier to the HLR identifying the serving18MSC/VLR.19
If the IIF receives a GSM MAP _UPDATE_LOCATION_REQUEST, it shall compare the20received location information with any previously stored location information. If the received21and previously stored location information are different, the IIF shall determine if the location22updating is allowed and update the corresponding subscriber record accordingly and send a23GSM MAP _CANCEL_LOCATION_REQUEST to the old VLR. If there is no previously stored24location information in the IIF, the IIF shall determine if the location updating is allowed and25update the corresponding subscriber record accordingly. In either case, if the HLR is required26to be updated, then the IIF shall send an ANSI_MAP_REGNOT to the HLR and await a27response.28
If the response indicates that the location updating procedure has been successful, then the IIF29shall update the corresponding subscriber record and send a GSM MAP30_INSERT_SUBSCRIBER_DATA_REQUEST to the serving VLR and await a response. If the31response indicates success, the IIF completes the location updating procedure by sending a32GSM MAP _UPDATE_LOCATION_RESPONSE to the serving VLR. The GSM MAP33_UPDATE_LOCATION_RESPONSE contains a unique identifier, identifying the HLR.34Otherwise, the IIF sends a GSM MAP _UPDATE_LOCATION_RESPONSE to the serving VLR35indicating the reason why the location updating procedure was not successful.36
If the response indicates that the location updating procedure has been unsuccessful, then the37IIF shall not update the corresponding subscriber record and shall send a GSM MAP38_UPDATE_LOCATION_RESPONSE to the serving VLR indicating the reason for failure.39
If the IIF receives an ANSI_MAP_REGNOT, it shall compare the received location information40with any previously stored location information. If the received and previously stored location41information is different, the IIF shall update the corresponding subscriber record and send an42ANSI_MAP_REGCAN to the old VLR. If there is no previously stored location information in43
X.S0023
3-4
the IIF, the corresponding subscriber record is updated. In either case, if the HLR is required to1be updated, then the IIF shall send a GSM MAP _UPDATE_LOCATION_REQUEST to the HLR2and await a response.3
If the response indicates that the location updating procedure has been successful, then the IIF4shall update the corresponding subscriber record and send an ANSI_MAP_regnot to the5serving VLR. The ANSI_MAP_regnot contains a unique identifier, identifying the HLR.6
If the response indicates that the location updating procedure has been unsuccessful, then the7IIF shall not update the corresponding subscriber record and shall send an ANSI_MAP_regnot8to the serving VLR indicating the reason for failure.9
If the IIF receives a GSM MAP _MS_PURGE_REQUEST, it shall check the contents of the10message for errors. If errors exist, the IIF shall send a GSM MAP _MS_PURGE_RESPONSE11indicating the reason for failure and the MS purged flag shall not be set. If no errors exist, the12IIF shall check if the received VLR number matches the stored VLR number.13
If the received VLR number and the stored VLR number match, the IIF shall set the MS purged14flag and shall send both a GSM MAP _MS_PURGE_RESPONSE to the VLR (including the15Freeze TMSI parameter) and an ANSI_MAP_MS_INACTIVE to the HLR and awaits a response16from the HLR.17
If the received VLR number and the stored VLR number do not match, the IIF sends a GSM18MAP _PURGE_MS_RESPONSE containing an empty result to indicate successful outcome19and the MS purged flag is not set.20
When the IIF receives a response from the HLR, it shall follow the VLR procedures outlined in21ANSI-41 [2].22
If the IIF receives an ANSI_MAP_MS_INACTIVE, it shall check the contents of the message for23errors. If errors exist, the IIF shall send an ANSI_MAP_ms_inactive indicating the reason for24failure and shall not set the MS state to inactive. If no errors exist, the IIF shall set the MS state25to inactive and follow the HLR procedures described in ANSI-41 [2]. If the state of the MS26remains inactive for a period of time (time controlled by operator), the IIF may send a GSM27MAP _MS_PURGE_REQUEST to the HLR.28
4.1.1.1.2 Location Cancellation2930
If the IIF receives a GSM MAP _CANCEL_LOCATION_REQUEST as part of a location31cancellation procedure it shall check the contents of the message for errors. If errors exist, the32corresponding temporary subscriber data is not deleted and the IIF shall send a GSM MAP33_CANCEL_LOCATION_RESPONSE indicating the reason for failure to the HLR. If no errors34exist, the IIF shall delete the corresponding temporary subscriber data and send an35ANSI_MAP_REGCAN to the VLR and await a response.36
If the response indicates that the location cancellation procedure has been successful, then the37IIF shall send a GSM MAP _CANCEL_LOCATION_RESPONSE to the HLR.38
If the response indicates that the location cancellation procedure has been unsuccessful, then39the IIF shall send a GSM MAP _CANCEL_LOCATION_RESPONSE to the HLR indicating40successful deletion of subscriber data (i.e., ignore the error).41
X.S0023
3-5
If the IIF receives an ANSI_MAP_REGCAN and the message can be processed, the IIF shall1delete the corresponding temporary subscriber data and send a GSM MAP2_CANCEL_LOCATION_REQUEST to the VLR and await a response.3
If the response indicates that the location cancellation procedure has been successful, then the4IIF shall send an ANSI_MAP_regcan to the HLR.5
If the response indicates that the location cancellation procedure has been unsuccessful, then6the IIF shall send an ANSI_MAP_regcan to the HLR indicating successful deletion of subscriber7data (i.e., ignore the error). The IIF may retry to sending the ANSI_MAP_REGCAN before8responding to the HLR.9
If the IIF receives an ANSI_MAP_REGCAN and the message cannot be processed, the10corresponding temporary subscriber data shall not be deleted and the IIF shall send an11ANSI_MAP_regcan to the HLR indicating reason for failure.12
4.1.1.2 Mapping of Messages, Parameters & Parameter Values1314
4.1.1.2.1 Mapping of Messages1516
Table 1 shows the mapping between GSM MAP messages and ANSI MAP messages related17to Location Registration.18
Table 1: Location Updating in GSM Foreign Mode Message Mapping19
GSM MAP Messages ANSI MAP MessagesUPDATE_LOCATION_REQUEST REGNOTINSERT_SUBSCRIBER_DATA_REQUEST regnotUPDATE_LOCATION_RESPONSE regnot1
20
211This message can also contain error values if the location updating procedure is unsuccessful.22If the location updating procedure fails, the mapping is as shown in 4.1.1.3Table 2 shows the23mapping between GSM MAP messages and ANSI MAP messages related to Location24Registration in ANSI-41 Foreign Mode.25
Table 2: Location Updating in ANSI-41 Foreign Mode Message Mapping26
GSM MAP Messages ANSI MAP MessagesUPDATE_LOCATION_REQUEST REGNOTUPDATE_LOCATION_RESPONSE regnot
27
X.S0023
3-6
Table 3 shows the mapping between GSM MAP messages and ANSI MAP messages (MS1Purging, regardless of mode of operation)2
3
Table 3: MS Purging Message Mapping4
GSM MAP Messages ANSI MAP MessagesMS_PURGE MS Inactive
5
6
Table 4 shows the mapping between GSM MAP messages and ANSI MAP messages related7to Location Cancellation.8
Table 4: Location Cancellation Message Mapping9
GSM MAP Messages ANSI MAP MessagesCANCEL_LOCATION_REQUEST REGCANCANCEL_LOCATION_RESPONSE regcan
10
X.S0023
3-7
4.1.1.2.2 Mapping of Parameters12
Table 5 through Table 9 shows the mapping of parameters, which the IIF shall perform3regardless of the mode of operation (GSM Foreign Mode or ANSI-41 Foreign Mode).4
Table 5: UPDATE_LOCATION_REQUEST REGNOT Parameter Mapping5
GSM MAP_UPDATE_LOCATION_REQUEST
Status ANSI_MAP_REGNOT Status
ElectronicSerialNumber MIMSI MMSID M
MSC Address M1 MSCID (Serving MSC)1 M- QualificationInformationCode M- SystemMyTypeCode M- MSCIdentificationNumber OVLR Number M -- PC_SSN (Serving MSC or VLR) O- SystemAccessType2 O
TerminalType2 O- TransactionCapability2 OLMSI U -Supported CAMEL Phases C -
1 These parameters are used to convey a unique identifier from the IIF to the HLR,6identifying the serving MSC/VLR.7
2 Parameters are included in ANSI specifications IS-41-C and later.8
X.S0023
3-8
1
Table 6 shows the mapping of parameters for GSM MAP2_INSERT_SUBSCRIBER_DATA_REQUEST to regnot.3
Table 6: INSERT_SUBSCRIBER_DATA_REQUEST regnot Parameter Mapping4
GSM MAP_INSERT_SUBSCRIBER_DATA_REQUEST
Status regnot Status
- SystemMYTypeCode (VLR orHLR)
M
- AuthorizationDenied O- Authorization Period O- ControlChannelData O- DeniedAuthorizationPeriod O- Digits (Carrier) O- Digits (Destination) O- MSCID (HLR) O- Profile “Macro”1 O- ReceivedSignalQuality O- SenderIdentificationNumber O- SMS_MessageWaitingIndicator O- SystemAccessData O- MSID OIMSI C -
51 This parameter is itself a macro containing a number of other parameters. The IIF shall6
map the contents of the ‘Profile’ macro in the ANSI-41-D ‘regnot’ to the contents of the7GSM MAP _INSERT_SUBSCRIBER_DATA_REQUEST as shown in Table 928
X.S0023
3-9
Table 7: UPDATE LOCATION RESPONSE regnot Parameter Mapping1
GSM MAP_UPDATE_LOCATION_RESPONSE
Status regnot Status
- SystemMYTypeCode (VLR orHLR)
M
- AuthorizationDenied O- Authorization Period O- ControlChannelData O- DeniedAuthorizationPeriod O- Digits (Carrier) O- Digits (Destination) OHLR number1, 2 R MSCID (HLR)2 R- Profile “Macro”3 O- ReceivedSignalQuality O- SenderIdentificationNumber O- SMS_MessageWaitingIndicator O- SystemAccessData O- MSID O
21 The presence of this parameter is mandatory in case of successful HLR updating.32 These parameters are used to convey a unique identifier from the IIF to the serving4
MSC/VLR, identifying the HLR.53 This parameter is itself a macro containing a number of other parameters. As far as6
mapping of parameters is concerned, the IIF shall map the contents of the ‘Profile’ macro in7the ANSI-41-D ‘regnot’ to the contents of the GSM MAP8_INSERT_SUBSCRIBER_DATA_REQUEST as shown in Table 92.9
Table 8: MS_PURGE_REQUEST MS INACTIVE Parameter Mapping10
GSM MAP_MS_PURGE_REQUEST
Status MS INACTIVE Status
IMSI M MSID MVLR Number C -- ESN M- CallHistoryCount O- DeregistrationType O- LocationAreaId O- SenderIdentificationNumber O- SMSMessageWaitingIndicator O
11
X.S0023
3-10
1
Table 9: CANCEL_LOCATION_REQUEST REGCAN Parameter Mapping2
GSM MAP_CANCEL_LOCATION_REQUEST
Status ANSI_MAP_REGCAN Status
ESN MIMSI MMSID M
LMSI C -Cancellation Type C1 Cancellation Type O- ControlChannelData O- ReceivedSignalQuality O- SenderIdentificationNumber O
SystemAccessData O3
1 Cancellation Type is only used between the HLR and the SGSN for GPRS procedures.4Cancellation Type is not applicable between HLR and VLR.5
4.1.1.3 Error Handling67
Error handling defined in GSM 09.02 [4] and ANSI-41 [2] is directly applicable to the IIF, when8the IIF is emulating a GSM or ANSI-41 network functional element.9
X.S0023
3-11
4.1.1.3.1 Location Updating12
If the Location Updating procedure fails at an ANSI-41 HLR, the HLR shall respond by either3sending:4
5An ANSI_MAP_regnot in a TCAP RETURN RESULT indicating authorization denied6(AUTHDEN) to the IIF, with one of the following reasons as defined in ANSI-41 [2]:7
Appropriate AUTHDEN Values in ANSI_MAP_regnot RETURN RESULT8
AUTHDEN Value
Delinquent account.
Invalid serial number.
Stolen unit.
Duplicate unit.
Unassigned directory number.
Unspecified.
Multiple access.
Not Authorized for the MSC.
Missing authentication parameters.
TerminalType mismatch
9
The ANSI-MAP-regnot may optionally, indicate:10
• The authorization period (DENAUTHPER) as defined in ANSI-41 [2]11
• Access Info as defined in ANSI-41 [2]12
X.S0023
3-12
Or, an ANSI_MAP_regnot in a TCAP RETURN ERROR one of the following error codes as1defined in ANSI-41 [2]:2
Appropriate Error Codes in ANSI_MAP_regnot RETURN ERROR3
Error Codes
MSID/HLRMismatch
ResourceShortage
OperationNotSupported
ParameterError
SystemFailure
UnrecognizedParameterValue
MissingParameter
The IIF is therefore responsible for mapping any errors it receives from the HLR in the ANSI-4MAP-regnot to an equivalent error in the GSM-MAP-UPDATE-LOCATION RESPONSE towards5the serving GSM MSC/VLR.6
7
The GSM-MAP-UPDATE-LOCATION RESPONSE may include one the following ‘user’ errors8as defined in GSM 09.02 [4]:9
Appropriate User Errors10
User Errors
unknown subscriber;
roaming not allowed;
system failure;
unexpected datavalue.
11
X.S0023
3-13
The following ‘provider errors’ (protocol related errors) are also defined in GSM 09.02 [4]:1
Appropriate Provider Errors2
duplicated invoke Id;
not supported service;
mistyped parameter;
resource limitation;
initiating release (i.e., the peer has alreadyinitiated 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.
3
If the Location Updating procedure fails at a GSM HLR, it returns a GSM MAP4_UPDATE_LOCATION_RESPONSE to the IIF, indicating a ‘user error’ as indicated above.5The IIF is therefore responsible for mapping any errors it receives into a corresponding error in6the ANSI_MAP_regnot towards the serving ANSI MSC/VLR. For further description of these7errors and when they are used, refer to either GSM 09.02 [4] or ANSI-41 [2].8
X.S0023
3-14
The table below provides the mapping of both user errors and provider errors to the equivalent1value in either the AUTHDEN parameter in the ANSI_MAP_regnot RETURN RESULT or the2RETURN ERROR for ANSI-41 Foreign Mode.3
Table 10: UPDATE_LOCATION_RESPONSE to regnot Error Mapping4
UPDATE_LOCATION_RESPONSE(Errors)
regnot
Unknown subscriber SystemFailureroaming not allowed Not Authorized for the MSCsystem failure SystemFailureunexpected data value SystemFailureduplicated invoke Id SystemFailurenot supported service SystemFailure
mistyped parameter SystemFailureresource limitation SystemFailureinitiating release SystemFailureunexpected response from the peer SystemFailureservice completion failure SystemFailureno response from the peer SystemFailureinvalid response received SystemFailure
5
6
X.S0023
3-15
Table 11 provides the mapping for GSM Foreign Mode.1
Table 11: regnot return errors to UPDATE_LOCATION_RESPONSE Error Mapping2
regnot UPDATE_LOCATION_RESPONSE(Errors)
Delinquent account System failureInvalid serial number System failureStolen unit System failureDuplicate unit System failureUnassigned directory number System failureUnspecified System failureMultiple access System failureNot Authorized for the MSC Roaming not allowedMissing authentication parameters System failureTerminalType mismatch System failureMSID/HLRMismatch Unknown subscriberResourceShortage System failureOperationNotSupported System failureParameterError System failureSystemFailure System failureUnrecognizedParameterValue System failureMissingParameter System failure
3
4.1.1.3.2 Location Cancellation4If the Location Cancellation procedure fails at the IIF, existing procedures described in GSM509.02 [4] and ANSI-41 [2] apply.6
4.1.2 Fault Recovery78
After the fault of a location register, the fault recovery procedures ensure that subscriber data in9the VLR becomes consistent with the subscriber data stored in the IIF or that subscriber data in10the IIF becomes consistent with the subscriber data that are stored in the HLR for the MS11concerned and that the location information in the IIF and VLR or HLR and IIF reflect accurately12the current location of the MS.13
14
4.1.2.1 Detailed Procedures1516
If the IIF receives an ANSI_MAP_UNRELDIR, it shall send a RETURN RESULT and clear the17records of those MSs associated with the requesting HLR. The IIF shall then send a GSM MAP18
X.S0023
3-16
_RESET towards the serving VLR containing a unique identity, identifying the ANSI-41 HLR.1When the MS concerned next establishes authenticated radio contact (including a mobile2originated call attempt), the IIF shall receive a GSM MAP _UPDATE_LOCATION_REQUEST3and shall follow the procedures outlined in4
4.1.1 Location Registration.5
If the IIF receives a GSM MAP _RESET, it shall derive all involved MSs of that HLR either from6the HLR Identity List (if present), or from the HLR number. The IIF shall then mark these MSs7with the indicator "Location Information Confirmed in HLR" set to "Not Confirmed". The IIF shall8then send an ANSI_MAP_UNRELDIR towards the serving VLR containing a unique identity,9identifying the GSM HLR. The status "Not Confirmed" of the indicator "Location Information10Confirmed in HLR" forces the IIF to invoke the GSM MAP _UPDATE_LOCATION service after11establishment of authenticated radio contact with the MS concerned.12
If the IIF suffers a failure, while operating in GSM Foreign Mode, it shall send a GSM MAP13_RESET to the serving GSM VLR once it has returned to a stable state. The IIF shall not14receive a response. The IIF may also send an ANSI_MAP_BULKDEREG to the ANSI-41 HLR.15
If the IIF suffers a failure, while operating in ANSI-41Foreign Mode, it shall send an16ANSI_MAP_UNRELDIR to the serving ANSI-41 VLR once it has returned to a stable state. The17IIF shall receive an indication of success or failure.18
If the IIF receives an ANSI_MAP_BULKDEREG, it shall send a RETURN RESULT to the19requesting VLR and clear the location pointer of those MSs that were registered in the20requesting VLR. Otherwise, the IIF shall send a RETURN ERROR with an appropriate error21value to the requesting VLR.22
23
4.1.2.2 Mapping of Messages, Parameters & Parameter Values2425
The IIF shall perform the mapping of messages, parameters and parameter values related to26fault recovery in accordance with the tables presented in 4.1.2.2.27
4.1.2.2.1 Mapping of Messages2829
Table 12 shows the mapping between GSM MAP messages and ANSI MAP messages related30to fault recovery in either mode of operation (GSM Foreign mode or IS-41 Foreign mode)31
Table 12 Fault Recovery Message Mapping32
GSM MAP Messages ANSI MAP MessagesRESET UNRELDIR
33
X.S0023
3-17
4.1.2.2.2 Mapping of Parameters1Table 13 shows the mapping of parameters, which the IIF shall perform regardless of the mode2of operation (GSM Foreign Mode or ANSI-41Foreign Mode).3
Table 13: GSM RESET ANSI UNRELDIR Parameter Mapping4
GSM MAP _RESET Status ANSI_MAP_UNRELDIR StatusHLR Id LIST UHLR Number1 M MSCID (HLR) 1 R
51 These parameters are used to convey a unique identifier from the IIF to the serving VLR,6
identifying the true HLR.7
4.1.2.3 Error Handling89
Error handling defined in GSM 09.02 [4] and ANSI-41 [2] is directly applicable to the IIF, when10the IIF is emulating a GSM or ANSI-41 network functional element.11
If the Fault Recovery procedure fails at an ANSI-41 VLR, the VLR shall respond by either12sending:13
An ANSI_MAP_unreldir in a TCAP RETURN ERROR with one of the following error codes as14defined in ANSI-41 [2]:15
16
Appropriate Error Codes in ANSI_MAP_unreldir RETURN ERROR17
18
Error Codes
ResourceShortage
OperationNotSupported
SystemFailure
19
There are no error handling procedures defined in GSM 09.02 [4] covering the case where20Fault Recovery procedures fail at a GSM VLR i.e. the GSM MAP _RESET service is a non-21confirmed service. As such, the IIF shall not map ANSI-41 error values to equivalent GSM22error values.23
X.S0023
3-18
If the Fault Recovery procedure fails at the IIF following the reception of an1ANSI_MAP_BULKDEREG, the IIF shall respond by sending an ANSI_MAP_bulkdereg in a2TCAP RETURN ERROR with one of the following error codes as defined in ANSI-41 [2]:3
4
Appropriate Error Codes in ANSI_MAP_bulkdereg RETURN ERROR5
6
Error Codes
ResourceShortage
OperationNotSupported
SystemFailure
UnrecognizedParameterValue
X.S0023
3-19
4.2 Call Handing Procedures1
2
Existing call handling procedures described in either GSM 09.02 [4] or ANSI-41 [2] are also3directly applicable to the Interworking and Interoperability Function (IIF) when it is emulating a4GSM or ANSI-41 functional network element.5
6
4.2.1 Automatic Call Delivery78
4.2.1.1 Detailed Procedures910
The Automatic Call Delivery procedure is invoked in the IIF, when a terminating call attempt11results in a request for routing information from the IIF.12
The following procedures are applicable at the IIF for Automatic Call Delivery:13
4.2.1.1.1 GSM Foreign Mode1415
If the IIF receives an ANSI MAP_RoutingRequest Invoke message from the ANSI-41 HLR, it16shall check if the terminating call can be placed to that subscriber. The IIF shall then deduce17the IMSI from the MSID for that subscriber and populate the corresponding field of the18MAP_PROVIDE_ROAMING_NUMBER message.19
The IIF shall store the BillingID received in the ANSI MAP_RoutingRequest Invoke message to20later be able to populate the corresponding field in the ANSI MAP_RoutingRequest Return21Result message.22
If the MobileDirectoryNumber field is present and in an international format in the23MAP_RoutingRequest Invoke message, the IIF shall populate the MSISDN field in the24MAP_PROVIDE_ROAMING_NUMBER message with it. If the MobileDirectoryNumber is in25National format, the IIF shall convert it to an International format before populating the MSISDN26field1.27
The IIF shall then populate the MSC Number field in the28MAP_PROVIDE_ROAMING_NUMBER message with the serving MSC Number that had been29stored in the IIF at the time of the subscriber’s location registration.30
The IIF shall then send the MAP_PROVIDE_ROAMING_NUMBER message to the GSM31MSC/VLR and wait for a response.32
If the response indicates that the retrieval of routing information procedure has been33successful, the IIF shall deduce the MSRN from the MAP_PROVIDE_ROAMING_NUMBER34ack and populate the field Digits (Destination) in the MAP_RoutingRequest Return Result. The35
1 As an alternative, the MSISDN may also be retrieved directly from the Subscriber profile,pre-provisioned in the IIF.
X.S0023
3-20
IIF shall populate the BillingID field with the value of the BillingID received in the1RoutingRequest Invoke message.2
The IIF shall then populate the MSCID (Serving) field with its own ID and forward it to the3ANSI-41 HLR.4
If the response is unsuccessful, the IIF shall map any error code it receives to either an5AccessDeniedReason value in the MAP_RoutingRequest Return Result or to an Error Code in6a Return Error message.7
For the cases of failure at the IIF on reception of the MAP_RoutingRequest Invoke message8(e.g. missing expected parameter, unknown subscriber), the procedures described in ANSI-419[2] are also applicable to the IIF.10
For the cases of failure at the IIF on reception of the PROVIDE_ROAMING_NUMBER11response, the procedures described in GSM 09.02 [4] for retrieval of routing information are12also applicable to the IIF.13
14
4.2.1.1.2 ANSI-41 Foreign Mode15If the IIF receives a MAP_PROVIDE_ROAMING_NUMBER message from the GSM HLR, it16shall check if the terminating call can be placed to that subscriber.17
If the IIF determines that the subscriber is Not Reachable, it shall send a18MAP_PROVIDE_ROAMING_NUMBER Response message with User Error field indicating19Absent Subscriber to the GSM HLR.20
Otherwise, the IIF shall deduce the MSID and ESN from the IMSI and populate the21corresponding fields of the ANSI MAP_RoutingRequest Invoke.22
The IIF shall create a billing ID for that transaction and populate the corresponding field of the23ANSI MAP_RoutingRequest Invoke.24
The MSCID address field shall be set to the IIF address.25
The IIF shall also assign a predefined value (vendor specific) to the SystemMyTypeCode field,26indicating the IIF vendor identity.27
If the MSISDN field is present in the MAP_PROVIDE_ROAMING_NUMBER, the IIF shall28populate the MobileDirectoryNumber field in the RoutingRequest Invoke message with it1.29
The IIF shall set the MSCIdentificationNumber and PC_SSN fields to its own ID.30
The IIF shall then send the RoutingRequest Invoke message to the ANSI-41 MSC/VLR and31wait for a response.32
If the response indicates that the retrieval of routing information procedure has been33successful, the IIF shall deduce the MSRN from the Digits (Destination) field of the34RoutingRequest Return Result and populate the MSRN field in the35MAP_PROVIDE_ROAMING_NUMBER ack. The MSRN shall have an E.164 format. Therefore,36if the TLDN is not in international format, the IIF shall add the country code digits associated37
1 As an alternative, the MSISDN may also be retrieved directly from the Subscriber profile,pre-provisioned in the IIF.
X.S0023
3-21
with the country of the serving system The IIF shall then forward the1MAP_PROVIDE_ROAMING_NUMBER ack to the GSM HLR.2
If the response is unsuccessful, the IIF may receive a RoutingRequest Return Result with the3field AccessReasonDenied present, or a ReturnError message with an Error Code value. The4IIF shall map any Access Reason Denied or Error Code it receives to a User or Provider Error5in the MAP_PROVIDE_ROAMING_NUMBER return error.6
For the cases of failure at the IIF on reception of the MAP_PROVIDE_ROAMING_NUMBER7request, (e.g. missing expected parameter, unidentified subscriber), the procedure described in8GSM 09.02 [4] for retrieval of routing information are applicable to the IIF.9
For the cases of failure at the IIF on reception of the MAP_RoutingRequest Invoke message10return Result, the procedure described in ANSI-41 [2] for automatic call delivery is applicable to11the IIF.12
13
4.2.1.2 Mapping of Messages, Parameters & Parameter Values1415
4.2.1.2 presents the mapping of messages, parameters and parameter values that the IIF shall16perform. The mapping in the following tables is applicable to the generic Call delivery17scenarios. For mapping of parameters relevant to the Optimal Routing cases, refer to 4.2.3. For18mapping of parameters relevant to CLIP/CLIR refer to 4.3.4.19
20
4.2.1.2.1 Mapping of Messages2122
Table 14 shows the mapping between GSM MAP messages and ANSI MAP messages related23to Automatic Call Delivery regardless of the mode of operation (GSM Foreign Mode or ANSI-4124Foreign Mode)25
Table 14: Automatic Call Delivery Message Mapping26
GSM MAP Message ANSI-41 MAP MessagePROVIDE ROAMING NUMBERREQUEST
Routreq
PROVIDE ROAMING NUMBERREQUEST REPONSE
routereq
X.S0023
3-22
4.2.1.2.2 Mapping of Parameters1Table 15 and Table 16 show the mapping of parameters, which the IIF shall perform regardless2of the mode of operation (GSM Foreign Mode or ANSI-41 Foreign Mode).3
Table 15: ROUTREQ PROVIDE_ROAMING_NUMBER_REQUEST Parameter Mapping4
ROUTREQ Status Provide Roaming NumberRequest
Status
BillingID (Originating) M -ElectronicSerialNumber M -MobileStationIDentity M IMSI MMSCID (Originating MSC) MSystemMyTypeCode (OriginatingMSC)
M -
AlertCode O -CallingPartyNumberString1(Note 1)
O -
CallingPartyNumberString2(Note 1)
O -
CallingPartySubaddress O -DestinationDigits O -DMH_AccountCodeDigits O -DMH_AlternateBillingDigits O -DMH_BillingDigits O -LegInformation O -LocationAreaID O -MobileDirectoryNumber R
(Note 2)MSISDN(Note 3)
R (Note 4)
MSCIdentificationNumber R -NoAnswerTime O -OneTimeFeatureIndicator O -PC_SSN (Originating MSC) R -PilotBillingID O -PilotNumber O -RedirectingNumberString O -RedirectingSubAddress O -SenderIdentificationNumber O -TerminationTreatment O -
5
X.S0023
3-23
Table 15: ROUTREQ PROVIDE_ROAMING_NUMBER_REQUEST Parameter Mapping1(concluded)2
ROUTREQ Status Provide Roaming NumberRequest
Status
TerminationTriggers O -VoiceMailboxNumber O -VoiceMailPIN O -- MSC Number M- LMSI U- GMSC address R
(Note 5)- GSM Bearer Capability C- Network Signal Info C- Suppression of
AnnouncementC
- Call Reference Number R(Note 5)
- OR Interrogation C- Alerting Pattern C- CCBS Call CCDMAService Option O GSM BearerServiceCode O (Note
6)3
Note 1: For encoding of those parameters, refer to “4.3.4 Calling Number/Line Identification4Presentation/Restriction”.5
Note 2: If present from the PRN request6
Note 3: May also be directly retrieved from the subscriber profile pre-provisioned in the IIF.7
Note 4: Only if the IIF requires it to be included in the call data record8
Note 5: Only for Optimal Routing after late Call Forwarding9
Note 6: Optional, if the network settings support data, a mapping may be performed as10described in Table 9211
X.S0023
3-24
The following table shows the mapping of parameters between the Provide Roaming Number1Response and the Routing Request Return Result messages regardless of the mode of2operation (GSM Foreign Mode or ANSI-41 Foreign Mode).3
Table 16: Provide Roaming Number Response Routreq Return Result Parameter4Mapping5
Provide Roaming Number ack Status Routreq Return Result StatusRoaming Number* M Digits (Destination) R- MSCID (Serving) MUser Error* R
(Note1)
AccessDeniedReasonR(Note2)
- BillingID (Anchor) R- ConditionallyDeniedReason O- MSCIdentificationNumber R- PC_SSN (Serving MSC) OGSM Bearer Capability (Note 3) O CDMAServiceOption O
6
* These parameters are mutually exclusive7
Note 1: If the request is unsuccessful.8
Note 2: If User Error is present in Provide Roaming Number ack.9
-Note 3: Optional, if the network settings support data, a mapping may be performed as10described in Table 9211
Or12
Table 17: PROVIDE_ROAMING_NUMBER_RESPONSE to Routreq Return Error Mapping13(ANSI-41Foreign Mode)14
Provide Roaming Number ack Status RoutingRequest ReturnError
Status
User Error CProvider Error C
Error Code O
15
For detailed mapping of User/Provider Error parameter value to the AccessDeniedReason16parameter, see Table 22 and Table 23.17
18
X.S0023
3-25
Table 18: Routreq Return Error to Provide Roaming Number Response Error Mapping1(GSM Foreign mode)2
Routing Request Return Error Status Provide Roaming Numberack
Status
Error Code O User Error C
4.2.1.2.2.1 Mapping of parameter values in GSM Foreign Mode3Default parameter value4
Table 19 presents how the IIF shall populate the parameters of the Provide Roaming Number5message to be sent to the GSM VLR. These fields do not have an equivalent in the received6Routing Request Invoke message.7
Table 19: Provide Roaming Number Request default parameter8
Parameter Name Status ValueMSC Number M ISDN number of the serving MSC.
Stored in the IIF at the time of locationregistration.
LMSI C Local Mobile Subscriber Identity. Shallbe present if the LMSI was sent to theIIF at location updating
GSM Bearer Capability C Shall be absentNetwork Signal Info C Shall be absentSuppression of Announcement C CAMEL Specific Information Element
(IE)Call Reference Number C Not required unless Optimal Routing
for LateCall Forwarding is supportedby the IIF.
GMSC address C Not required unless CAMEL or OptimalRouting for Late Call Forwarding issupported by the IIF (and if so, it shallbe set to the IIF address)
OR Interrogation C Not required to be sent by the IIF(however may be received as a resultof Optimal Routing)
Alerting Pattern C CAMEL Specific Information Element(IE)
CCBS Call C CCBS Specific IE9
X.S0023
3-26
1
Table 20 presents how the IIF shall populate the parameters of the Routing Request Return2Result message to be sent to the ANSI-41 HLR. These fields cannot be mapped from the3received Provide Roaming Number response message.4
Table 20: RoutingRequest Return Result default parameters5
Parameter Name Status Default ValueMSCID (Serving) M Shall be set to the serving MSC
addressBillingID (Anchor) O When the IIF receives the Routing
Request Invoke message it shallstore the BillingID and use it topopulate this field.
AccessDeniedReason O See Table 24ConditionallyDeniedReason O Shall be absent.MSCIdentificationNumber O Shall be set to the serving MSC
addressPC_SSN (Serving MSC) O Shall be absentCDMAServiceOption O If received in Invoke or from Profile
6
X.S0023
3-27
4.2.1.2.2.2 Mapping of parameter values in ANSI-41 Foreign Mode1Default parameter value2
Table 21 presents how the IIF shall populate the parameters of the Routing Request Invoke3message to be sent to the ANSI-41 VLR. These fields cannot be mapped from the received4Provide Roaming Number request message.5
Table 21: Routing Request Invoke default parameter6
ROUTEREQ Status Default ValueBillingID (Originating) M Shall be created by the IIFElectronicSerialNumber M Shall be deducted from the IMSI received
in the PRN request. For each subscriberprovisioned in the IIF, there must be atable defining a correspondence betweenIMSI on the one hand and MIN/ESN onthe other hand.
MSCID (Originating MSC) M Shall be set to the IIF address.SystemMyTypeCode (IIF vendor Id)) M Assigned by the IIFAlertCode O May be absentCallingPartyNumberString1 O See Table 83 to Table 86CallingPartyNumberString2 O See Table 83 to Table 86CallingPartySubaddress O See Table 83 to Table 86DestinationDigits O Shall be absentDMH_AccountCodeDigits O Shall be absentDMH_AlternateBillingDigits O Shall be absentDMH_BillingDigits O Shall be absentLegInformation O Shall be absent (not a multileg call)LocationAreaID O Shall be absentMSCIdentificationNumber O Shall be set to identify the IIF, as the
information may be required at a latertime by the ANSI VMSC to redirect thecall.
NoAnswerTime O Shall be absentOneTimeFeatureIndicator O Shall be absentPC_SSN (Originating MSC) O Shall be set to identify the IIF, as the
information may be required at a latertime by the ANSI VMSC to redirect thecall.
PilotBillingID O Shall be absent [multi leg call]PilotNumber O Shall be absent [pilot directory number for
a multi-leg call]7
X.S0023
3-28
Table 21: Routing Request Invoke default parameter (concluded)1
ROUTEREQ Status Default ValueRedirectingNumberString O Shall be absentRedirectingSubAddress O Shall be absentSenderIdentificationNumber O Shall be absentTerminationTreatment O Shall be absent or set to 1 (MS
Termination which is also the defaultvalue)
TerminationTriggers O Shall be absent. Define thetreatment to apply (termination orredirection)
VoiceMailboxNumber O Shall be absentVoiceMailPIN O Shall be absentCDMAServiceOption O From Profile or from Location
Request Invoke if received
4.2.1.3 Error Handling2The following tables present the appropriate GSM MSC/VLR negative response to a Provide3Roaming Number message as described in GSM 09.02 [4].4
Appropriate User Error value:5
User Error value
Absent Subscriber
No roaming Number available
Facility Not supported
System Failure
Data Missing
Unexpected Data Value
X.S0023
3-29
Appropriate Provider Error value:1
Provider Error value
Duplicated Invoke ID
Not supported service
Mistyped parameter
Resource limitation
Initiating Release
Unexpected response from the peer
Service Completion Failure
No response from the peer
Invalid response received
2
The following tables present the appropriate ANSI-41 MSC/VLR negative response to a3Routing Request Invoke message as described in ANSI-41 [2].4
5
Appropriate AccessDeniedReason parameter values in the RoutingRequest Return6Result:7
AccessDeniedReason
Inactive
Busy
No page Response
Unavailable
8
X.S0023
3-30
Appropriate Error Code parameter value in the Return Error message:1
Error Code value
UnrecognizedMIN
UnrecognizedESN
ResourceShortage
OperationNotSupported
ParameterError (Note 1)
UnrecognizedParameterValue
SystemFailure
MissingParameter
2
Note 1: The FaultyParameter field shall be present and populated with the appropriate Parameter3Identifier.4
4.2.1.3.1 GSM Foreign Mode56
The IIF is responsible for the mapping of the User Error/Provider Error received in the Provide7Roaming Number response to the appropriate AccessDeniedReason in the RoutingRequest8Return Result message or Error Code in the Return Error.9
The following tables present the preferred mapping.10
Table 22: PRN response User Error to routreq Return Error Mapping11
User Error value received in PRNresponse
AccessDeniedReason in routreq or ErrorCode in Return Error.
Absent Subscriber AccessDeniedReason to UnavailableNo roaming Number available Error Code to System FailureFacility Not supported Error Code to System FailureSystem Failure Error Code to System FailureData Missing Error Code to System FailureUnexpected Data Value Error Code to System Failure
12
13
X.S0023
3-31
Table 23: PRN Response Provider Error to routereq Return Error Mapping1
Provider Error value received in PRNConfirm.
Error Code value in Return Error
Duplicated Invoke ID System FailureNot supported service System FailureMistyped parameter System FailureResource limitation System FailureInitiating Release System FailureUnexpected response from the peer System FailureService Completion Failure System FailureNo response from the peer System FailureInvalid response received System Failure
4.2.1.3.2 ANSI-41 Foreign Mode23
The IIF is responsible for the mapping of the AccessDeniedReason received in the4RoutingRequest Return Result or Error Code received in the Return Error to the appropriate5User Error/Provider Error in the Provide Roaming Number response message.6
The following tables present the preferred mapping.7
Table 24: RoutingRequest Return Result to User Error in the PRN response Error8Mapping9
AccessDeniedReason received in theRoutingRequest Return Result
User Error in the PRN response
Inactive Absent SubscriberBusy Absent SubscriberNo page Response Absent SubscriberUnavailable Absent Subscriber
Table 25: Routing Request Return Error to PRN User Error Mapping10
Error Code value User Error in the PRN responseUnrecognizedMIN System FailureUnrecognizedESN System FailureResourceShortage System FailureOperationNotSupported System FailureParameterError System FailureUnrecognizedParameterValue System FailureSystemFailure System FailureMissingParameter System Failure
X.S0023
3-32
4.2.2 Invocation of Conditional Call Forwarding in ANSI-41 Foreign Mode12
Existing call forwarding procedures described in either GSM 09.02 [4] or ANSI-41 [2] are also3directly applicable to the IIF when it is emulating a GSM or ANSI-41 functional network element.4Enhancements and modifications to ANSI-41 [2] are also applicable.5
4.2.2.1 Detailed Procedures67
4.2.2.1.1 Invocation of Call Forwarding before the call has been routed to the serving8MSC9
10
The Call Forwarding procedure is invoked in the IIF when a terminating call attempt results in11an “unavailable” indication and the IIF is required to provide treatment for the “unavailable”12situation.13
The following procedures are applicable at the IIF for Call Forwarding invocation:14
If the IIF receives an ANSI_MAP_routreq indicating ‘access denied’, the IIF shall determine if15call forwarding is applicable for the call.16
If call forwarding is applicable for the call, the IIF shall send a GSM MAP _PROVIDE17ROAMING_NUMBER_RESPONSE to the HLR.18
The IIF shall process the forwarding request in one of the following two optional methods:19
• Send the Forward_To_Number that corresponds to the access denied reason (stored20for the subscriber in the IIF). Refer to Table 26 or,21
• Send a user error indicating “Absent Subscriber”. Refer to Table 27.22
If call forwarding is not applicable for the call, the IIF shall follow the procedures outlined in234.2.1 of this document24
If the IIF receives an ANSI_MAP routreq Return Error or a Reject message, the IIF shall map25the Error Code it receives to a suitable User Error in the26MAP_PROVIDE_ROAMING_NUMBER RESPONSE as described in 4.2.1 of this document27
For the cases of failure at the IIF on reception of the MAP_RoutingRequest Return Result, the28procedure described in ANSI-41 [2] for automatic call delivery is applicable to the IIF.29
X.S0023
3-33
4.2.2.1.2 Invocation of Call Forwarding after the call has been routed to the serving1MSC2
3
If the called party is either busy, not reachable or does not answer the call, the serving MSC4may redirect the call by sending REDREQ to the IIF, indicating the reason for failure.5
If the IIF receives an ANSI_MAP_REDREQ, it shall determine if the message can be6processed:7
If the message can be processed and optimal routing is supported, the IIF shall follow8the procedures outlined in 4.2.3 of this document for Optimal Routing for late call9forwarding.10
If the message can be processed but optimal routing is not supported, the IIF shall11send an ANSI_MAP_redreq Reject message. On receipt of the Reject message, the12serving MSC may attempt to redirect the call by sending a TRANUMREQ message to13the IIF.14
If the message cannot be processed, the IIF shall send an ANSI_MAP redreq Return15Reject message with the appropriate error code. On receipt of the Return Reject16message, the serving MSC may attempt to redirect the call by sending a TRANUMREQ17message to the IIF.18
If the IIF receives an ANSI_MAP_TRANUMREQ, it shall determine if the message can19be processed.20
If the message can be processed, the IIF shall send an ANSI_MAP_tranumreq21indicating the forwarded-to-number.22
If the message cannot be processed, the IIF shall send an ANSI_MAP tranumreq indicating the23reason for failure.24
25
4.2.2.2 Mapping of Messages, Parameters & Parameter Values2627
4.2.2.2 presents the mapping of messages, parameters and parameter values that the IIF shall28perform.29
4.2.2.2.1 Mapping of Messages3031
These messages are the same as those in 4.2.1.2.1.32
33
X.S0023
3-34
4.2.2.2.2 Mapping of Parameters12
Table 26 represents how the IIF shall map the value of the parameter it has received to3populate the fields of the message it shall transmit.4
Table 26: ROUTEREQ Return Result to Provide Roaming Number Response parameter5mapping (Option 1)6
Routing Request Return Result Status Provide Roaming Number ack. StatusAccessDeniedReason = Busy,Inactive, No Page Response orUnavailable
O Roaming Number C
7
8
Table 27: ROUTREQ Return Result to Provide Roaming Number Response Parameter9Mapping (Option 2)10
Return Error Status Provide Roaming Number ack StatusAccessDeniedReason = Busy,Inactive, No Page Response orUnavailable
O User Error = Absent Subscriber C
11
Default parameters value12
N/A13
4.2.2.3 Error Handling1415
The following table presents the appropriate GSM MSC/VLR negative response to a Provide16Roaming Number message as described in GSM 09.02 [4].17
Appropriate User Error value:18
User Error value
Absent Subscriber
No roaming Number available
Facility Not supported
System Failure
Data Missing
Unexpected Data Value
19
X.S0023
3-35
Appropriate Provider Error value:1
Provider Error value
Duplicated Invoke ID
Not supported service
Mistyped parameter
Resource limitation
Initiating Release
Unexpected response from the peer
Service Completion Failure
No response from the peer
Invalid response received
2
The following table presents the appropriate ANSI-41 MSC/VLR negative response to a3Routing Request Invoke message as described in in ANSI-41 [2].4
Appropriate AccessDeniedReason parameter values in the RoutingRequest Return Result:5
6
AccessDeniedReason
Inactive
Busy
No page Response
Unavailable
7
Appropriate Error Code parameter value in the Return Error message:8
9
Error Code value
UnrecognizedESN
ResourceShortage
OperationNotSupported
ParameterError*
UnrecognizedParameterValue*
SystemFailure
MissingParameter*
X.S0023
3-36
1
Table 28: Return Error to User Error in the PRN response Error Mapping2
Error Code value User Error
UnrecognizedESN System Failure
ResourceShortage System Failure
OperationNotSupported System Failure
ParameterError System Failure
UnrecognizedParameterValue System Failure
SystemFailure System Failure
MissingParameter System Failure
4.2.3 Optimal Routing after Late Call Forwarding34
An optimal routing for late call forwarding procedure covers the interoperability between5ANSI-41 and GSM MAP signaling to support Optimal Routing after Late Call Forwarding. This6signaling is based on ANSI-41 [2] and GSM 09.02 [4].7
From GSM 03.79 [32], a Late Call Forwarding procedure is defined as Call Forwarding8performed after the call has been extended to the Visited PLMN (VPLMN) of the forwarding9subscriber. This forwarding is based on subscription of supplementary services like Conditional10Call Forwarding on Busy, Conditional Call Forwarding on No Reply, and Conditional Call11Forwarding on Not Reachable detected in the VPLMN of the forwarding subscriber. Note that12the Late Call Forwarding procedure may be invoked in the Interrogating PLMN (IPLMN) or in13the VPLMN of the forwarding subscriber.14
The procedure is applicable when the Subscriber has appropriate forwarding service active;15and Optimal Routing is enabled.16
17
4.2.3.1 Detailed Procedures1819
Roaming may occur either from ANSI-41 to GSM network or vice versa. Since the solutions and20ultimate functionality provided to the roaming subscriber are not symmetrical, the Optimal21Routing for Late Call Forwarding procedure is different in both cases. 4.2.3.1 defines roaming22procedures when roaming from GSM to ANSI-41 network and roaming from ANSI-41 to GSM23network respectively.24
25
X.S0023
3-37
4.2.3.1.1 ANSI-41 Foreign Mode12
When the IIF receives a GSM-Provide Roaming Number message, it stores GMSC Address,3Call Reference Number and OR Interrogation Indicator parameters if they are present. It then4sends an ANSI-41Routing Request message to the VLR and awaits a response.5
If successful ANSI-41 Routing Request response is received from VLR, it converts Temporary6Location Directory Number (TLDN) in to Mobile Subscriber Roaming Number (MSRN) and send7this information to HLR in GSM-Provide Roaming Number Acknowledge message.8
Otherwise, the IIF sends a GSM-Provide Roaming Number negative response to HLR and9discards GMSC Address, Call Reference Number and OR Interrogation Indicator parameter10information if present.11
If the IIF receives ANSI-41 Redirection Request message, it shall check GMSC Address.12
If GMSC Address is available, it shall map Redirection Reason parameter to Forwarding13Reason. The IIF sends this information in addition to the Call Reference Number and14Forwarding Number in GSM-Resume Call Handling message to originating MSC using GMSC15Address and await a response.16
Otherwise, the IIF rejects the ANSI-41 Redirection Request.17
If the IIF receives GSM-Resume Call Handling Acknowledge message, it sends response of18ANSI-41- Redirection Request message to the MSC. Otherwise, if negative response of GSM-19Resume Call Handling is received, the IIF shall send ANSI-41-Redreq Return Error with an20appropriate error code to the MSC.21
4.2.3.1.2 GSM Foreign Mode2223
When the IIF receives an ANSI-41-Routing Request message, it stores Originating MSC ID,24TERMTRMT if present. The IIF then generates a Call Reference Number and sends it as a25parameter in the a GSM-Provide Roaming Number message to the VLR along with the GMSC26address set to the IIF address and along with the GMSC address set to the IIF address awaits27a response.28
If successful GSM-Provide Roaming Number Acknowledge is received from VLR, it converts29MSRN to TLDN and sends this information to HLR in ANSI-41-Routing Request response30message.31
Otherwise, the IIF sends an ANSI-41- Routing Request negative response (routreq) to HLR and32discards information of Originating MSCID and TERMTRMT (if present).33
If the IIF receives GSM-Resume Call Handling, it shall use its Call Reference Number34parameter to corelate and determine the ANSI-41 originating MSC, and the IIF shall map the35Forwarding Reason parameter to Redirection Reason. The IIF sends this information to the36originating MSC in the ANSI-41-Redirection Request message and awaits a response.37
If the IIF receives ANSI-41-Redirection Request response message, it sends a GSM-Resume38Call Handling Acknowledge message to the MSC. Otherwise, if negative response is received39
X.S0023
3-38
(in form of return error), the IIF shall send GSM-Resume Call Handling Return Error with an1appropriate error code to the MSC.2
The IIF shall perform the translation of messages, parameters and parameter values related to3Optimal Routing Support for Late Call Forwarding procedure in accordance with the tables4presented here. Refer to GSM 03.18 [31] and GSM 03.79 [32] and ANSI-41 [2] for a description5of messages, parameters and parameter values.6
4.2.3.2 Mapping of Messages, Parameters & Parameter Values78
4.2.3.2.1 Mapping of Messages9
10Table 29 shows the translation between GSM MAP messages and ANSI-41 MAP messages11related to Optimal Routing Support for Late Call Forwarding procedure.12
Table 29: Optimal Routing for Late Call Forwarding Message Mapping13
GSM MAP Message ANSI-41 MAP MessageGSM-Provide Roaming Number Request ROUTEREQGSM- Provide Roaming NumberAcknowledge
routereq
GSM-Resume Call Handling REDREQGSM-Resume Call Handling Acknowledge redreq
14
X.S0023
3-39
4.2.3.2.2 Mapping of Parameters12
The following tables show the mapping of parameters, which the IIF shall perform regardless of3the mode of operation.4
Table 30: GSM Provide_Roaming_Number ANSI-41 ROUTEREQ Parameter Mapping5
GSM Provide_Roaming_Number Status ANSI-41-Route_Request(ROUTEREQ)
Status
IMSI M MSID M
ESN MMSC Number M -MSISDN (Note 1) R MDN RLMSI O -GSM Bearer Capability C -ISDN BC C -ISDN LLC C -ISDN HLC C -Alerting Pattern C -GMSC Address (Note 2) R -Call Reference Number R -OR Interrogation Indicator C -
MSCID (Originating MSC) M- Billing ID M- System My Type Code M- PC_SSN R- LocationAreaID O- TERMTRMT O- TERMTRIG O- LEGINFO O- OTFI O
CNIinfoASCII:- CallingPartyNumber-String 1 O- CallingPartyNumber- String 2 O- Redirecting Number O- Calling Party Subaddress O- Redirecting Subaddress O
X.S0023
3-40
1
Table 30: GSM Provide_Roaming_Number ANSI-41 ROUTEREQ Parameter Mapping2(concluded)3
GSM Provide_Roaming_Number Status ANSI-41-Route_Request(ROUTEREQ)
Status
DMHData:- DMH AccountCodeDigits O- DMH AlternateBillingDigits O
- DMH_BillingDigits O
- MobileDirectoryNumber O
- VMSPIN O
- VMBOX O
4
Note 1: Alternatively a provisioning number may be mapped to the MDN.5
Note 2: The GMSC Address is used by the IIF to route information to the originating MSC.6
Table 31: Mapping of Parameter values7
IMSI MSID See Automatic Call DeliveryESN See Automatic Call Delivery
MSISDN MDN See Automatic Call DeliveryBilling ID See Automatic Call DeliveryMSCID See Automatic Call Delivery
8
Table 32: Provide_Roaming_Number_Response routereq Parameter Mapping9
Provide_Roaming_Number_Response
Status ANSI-41 Route_Request(routereq)
Status
Roaming Number M TLDN [DGTSDEST] M- MSCID M- BILLID MUser Error C ACCDEN (Note 1) M- PC_SSN R
10
Note 1: Used only with the negative response of ANSI-41-Routing Request message.11
12
X.S0023
3-41
Table 33: Mapping of Parameter Values1
Roaming Number TLDN See Automatic Call DeliveryMSCID See Automatic Call DeliveryBILLID See Automatic Call Delivery
User Error ACCDEN See Automatic Call Delivery2
3
Table 34: Resume_Call_Handling REDREQ Parameter Mapping4
GSM Resume_Call_Handling Status ANSI-41 Redirection_Request(REDREQ)
Status
Call Reference Number M -
Basic Service group M -IMSI M MSID M
ESN MForwardingData: Forwarding Reason M REDREASON M Forwarded-to-Number M - Notification to Calling Party M - Forwarded-to-Subaddress C -CUG Interlock C -CUG Outgoing Access C -Originating CSI C -- BILLID M- LEGINFO O
5
Table 35: Mapping of Parameters Values6
IMSI MSID See Automatic Call DeliveryMSN See Automatic Call Delivery
ForwardingReason
REDREASON See below
BILLID See Automatic Call Delivery7
Table 36: Resume_Call_Handling_Response redreq Parameter Mapping8
Resume_Call_Handling_Response
Status Redirection_Request (redreq) Status
- -
X.S0023
3-42
4.2.3.2.3 Mapping ANSI-41 Redirection_Reason and GSM Forwarding Reason for1ANSI-41 Foreign Mode2
3
Table 37: ANSI-41 Redirection_Reason to GSM Forwarding_Reason4
Redirection_Reason Forwarding_ReasonBusy Call Forwarding BusyNo Answer Call Forwarding No ReplyNo Page Response Call Forwarding Not ReachableCall Accepted (Note1, Note2) -Unavailable Call Forwarding Not ReachableUnroutable Call Forwarding Not ReachableCall Refused (Note2) -
5
Notes:6
1. The "Call Accepted" redirection reason shall not be received from the terminating ANSI-417MSC in ANSI-41-Redirection Request. Hence the mapping of this value may not be8applicable.9
2. These Redirection Reasons do not map to any existing GSM Forwarding Reasons. As a10result, if the IIF receives an ANSI-41-Redirection Request message with one of these11Redirection Reasons, it shall reject the request. Hence the mapping of this value may not12be applicable.13
14
4.2.3.2.4 Mapping Forwarding Reason to Redirection Reason for GSM Foreign Mode1516
Table 38: GSM Forwarding_Reason to ANSI-41 Redirection_Reason17
Forwarding_Reason Redirectionion_ReasonCall Forwarding Busy BusyCall Forwarding No Reply No AnswerCall Forwarding Not Reachable No Page Response OR Unavailable
18
X.S0023
3-43
1
4.2.3.3 Error Handling23
Negative Response of GSM-Provide Roaming Number4
The serving MSC determines that it is unable to provide a routing number and returns this5indication to the IIF via a GSM Provide Roaming Number RETURN ERROR component with an6error code.7
Negative Response of GSM-Resume Call Handling8
The Originating MSC determines that it is unable to redirect the call and returns this indication9to the IIF via a GSM Resume Call Handling RETURN ERROR component with an error code.10
Negative Response of ANSI-41-Routing Request (ROUTEREQ)11
If TERMTRMT (TerminationTreatment) indicates termination to an MS, the Serving MSC12consults its internal data structures to determine if the MS is already engaged in a call on this13MSC. If termination is to a voice mailbox, the Serving MSC verifies the VMS availability. Finding14the MS or VMS busy (or otherwise unable to receive calls), the Serving MSC returns an15appropriate indication to the IIF in the ANSI-41 Routing Request response message (routreq).16Parameters included are MSCID and ACCDEN. The IIF then forwards the response of ANSI-4117Routing Request message to the HLR.18
Negative Response of ANSI-41-Redirection Request (REDREQ)19
The Originating MSC determines that it is unable to redirect the call and returns this indication20to the Serving MSC via an ANSI-41-Redirection Request RETURN ERROR component with an21error code.22
4.2.3.3.1 Error Code Mapping2324
Table 39: Provide_Roaming_Number to Routing_Request Error Mapping25
Provide_Roaming_Number User andProvider Errors
Routing_Request Error Codes
OR not allowed (Note 1) -26
Note 1: If 'OR not allowed' is returned, the IIF should retry the Provide_Roaming_Number27operation without the OR indication to allow for normal routing28
29For other error mappings see Automatic Call Delivery, Error Handling, GSM Foreign Mode.30
Table 40: Routing_Request to Provide_Roaming_Number Error Mapping31
Routing_Request Error Codes Provide_Roaming_Number User Errors- -
32
X.S0023
3-44
For error mappings see Automatic Call Delivery, Error Handling, ANSI-41 Foreign Mode.1
2
Table 41: Resume_Call_Handling to Redirection_Request Error Mapping3
Resume_Call_HandlingUser and Provider Errors
Redirection_RequestError Codes
OR not allowed (Note 1) SystemFailureForwarding failed SystemFailureDuplicated Invoke ID SystemFailureNot Supported Service System FailureMistyped Parameter System FailureResource Limitation System FailureInitiating Release SystemFailureUnexpected Response From the Peer SystemFailureService Completion Failure SystemFailureNo Response from the Peer SystemFailureInvalid Response Received SystemFailure
4
Note 1: This error should not occur. The process requires the GMSC support OR.5
6
Table 42: Redirection_Request to Resume_Call_Handling Error Mapping7
Redirection_Request Error Codes
Resume_Call_Handling User Errors
MissingParameter OR-NotAllowed
UnrecognizedParameterValue OR-NotAllowed
UnrecognizedMIN OR-NotAllowed
UnrecognizedESN OR-NotAllowed
MIN/HLRMismatch OR-NotAllowed
OperationSequenceProblem OR-NotAllowed
TrunkUnavailable OR-NotAllowed
SystemFailure OR-NotAllowed
FeatureInactive OR-NotAllowed
ParameterError OR-NotAllowed
OperationNotSupported OR-NotAllowed
ResourceShortage OR-NotAllowed
8
X.S0023
3-45
1
4.3 Supplementary Services Procedures2
3
4.3.1 SS Activation and Deactivation45
Because of the similarities in the procedures and signaling between the supplementary service6activation and deactivation cases, these are combined into one description. Furthermore, 4.3.17makes use of terms such as "Activate/Deactivate" or8"MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS". In all cases in which such terms are used, for9activation cases the terms "Activate" or "MAP_ACTIVATE_SS" terms apply. For deactivation10cases, the terms "Deactivate" or "MAP_DEACTIVATE_SS" apply.11
12
4.3.1.1 Detailed Procedures1314
4.3.1.1 contains the procedures in the IIF for the case in which the subscriber requests either15an activation or deactivation of one of the following supplementary services while roaming in16foreign mode (i.e., while roaming in a network of a technology different from that of its home17network):18
19
• Call Waiting (in both GSM and ANSI-41 foreign modes)20
• Call Forwarding Unconditional (in both GSM and ANSI-41 foreign modes)21
• Call Forwarding Busy (in both GSM and ANSI-41 foreign modes)22
• Call Forwarding No Reply (in ANSI-41 foreign-mode only)23
• Call Forwarding Not Reachable (in ANSI-41 foreign-mode only)24
• Call Forwarding No Answer (in GSM foreign-mode only)25
26
4.3.1.1.1 GSM Foreign Mode2728
While in GSM Foreign Mode, the principal role of the IIF, with respect to supplementary service29activation and deactivation, is that of handling the GSM MAP_ACTIVATE_SS message (for30activation) or the GSM MAP_DEACTIVATE_SS message (for deactivation), as follows: If the31IIF receives an GSM MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS message from the GSM32serving system, it shall verify the correct format and content of the message as described in33GSM 09.02 [4].34
For cases in which the received message contains a "Basic service" parameter, the IIF shall35also verify that the request for activation/deactivation applies to (at least) speech. If the36received request does not include "speech" as one of the services to which the request applies,37
X.S0023
3-46
the IIF shall respond with either a GSM MAP_ACTIVATE_SS or GSM MAP_DEACTIVATE_SS1Response message that includes a "User error" parameter with a value of "Illegal SS2operation". Note that cases in which no "Basic service" parameter is included in the received3message are acceptable, since, by default, no "Basic service" parameter indicates that the4request applies to all services.5
If the format and content of the message is correct, the IIF shall determine the location of the6subscriber’s HLR and send to it an ANSI-41 FeatureRequest INVOKE message populated as7described in Table 44 and Table 48. If a failure occurs at the IIF on reception of the GSM8MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS message (e.g. missing data), the procedures9described in GSM 09.02 [4] are applicable to the IIF.10
If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF receives an ANSI-4111FeatureRequest Return Result message with a FeatureResult parameter set to successful, the12IIF shall send a GSM MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS Response message back13towards the serving system populated as described in Table 45.14
If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF instead receives an ANSI-4115FeatureRequest Return Result message with a FeatureResult parameter set to unsuccessful,16the IIF shall send a GSM MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS Response message17back towards the serving system populated as described in Table 45 and Table 53.18
If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF instead receives an ANSI-4119FeatureRequest Return Error message, the IIF shall send a GSM MAP_ACTIVATE_SS/20MAP_DEACTIVATE_SS Response message back towards the serving system populated as21described in Table 54.22
Note that successful supplementary service activation/deactivation cases in GSM foreign mode23may result in the subscriber's ANSI-41 HLR sending out an ANSI-41 QUALDIR message to the24serving system. For these cases, the IIF would need to map the message to a GSM MAP25Insert Subscriber Data message. The mapping of an ANSI-41 QUALDIR message to a GSM26MAP Insert Subscriber Data message is covered in the Subscriber Data Management.27
4.3.1.1.2 ANSI-41 Foreign Mode2829
While in ANSI-41 Foreign Mode, the principal role of the IIF, with respect to supplementary30service activation, is that of handling the ANSI-41 FeatureRequest INVOKE message, as31follows: If the IIF receives an ANSI-41 FeatureRequest INVOKE message from the ANSI-4132serving system, it shall verify the correct format and content of the message as described in33ANSI-41 [2].34
If format and content of the message is correct, the IIF shall determine the location of the35subscriber’s HLR and send a GSM MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS Request36message populated as described in Table 44 and Table 50.37
For cases in which the FeatureRequest INVOKE message includes a feature code38corresponding to Call Forwarding No Answer, and if the IIF is configured to do so, the IIF may39send two MAP_ACTIVATE_SS/ MAP_DEACTIVATE_SS messages, one indicating Call40Forwarding No Reply and the other indicating Call Forwarding Not Reachable. These messages41may be sent in parallel. The mapping in Table 44 and Table 50 would still be applicable.42
43
X.S0023
3-47
For the cases of failure at the IIF on reception of the ANSI-41 FeatureRequest Return Result1message (e.g. parameter error, unrecognized subscriber), the procedures described in2ANSI-41 [2] are applicable to the IIF.3
If, in response to the a GSM MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS message, the IIF4receives a GSM MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS Response message with neither5a User Error nor Provider Error parameter, the IIF shall send an ANSI-41 FeatureRequest6Return Result message back towards the serving system populated as described in Table 45.7For those cases in which two requests had been previously sent by the IIF, the IIF would wait8until receiving the responses to both requests before sending the FeatureRequest Return Result9message. For cases in which both responses indicate success, the mapping in Table 45 may be10applied to either of the responses (as an IIF implementation option). For cases in which one of11the responses indicates success and the other failure, the mapping in Table 45 applies to the12successful response.13
If, in response to the GSM MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS message, the IIF14instead receives a GSM MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS Response message15with a User Error, the IIF shall send either an ANSI-41 FeatureRequest Return Result16populated as described in Table 55 or a Return Error populated as described in Table 56. If a17Provider Error parameter is included in the received GSM18MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS Response message, the IIF shall send an19ANSI-41 FeatureRequest Return Error message populated with an Error Code as shown in20Table 57.21
For cases in which two requests had been previously sent by the IIF, and both responses22indicate failure, the mapping described in Table 55 or Table 56 may be applied to either of the23responses (as an IIF implementation option).24
Note that successful supplementary service activation/deactivation cases in ANSI-41 foreign25mode may result in the subscriber's GSM HLR sending out a GSM MAP Insert Subscriber Data26message to the serving system. For these cases, the IIF would need to map the message to27an ANSI-41 QUALDIR message. The mapping of GSM MAP Insert Subscriber Data message28to an ANSI-41 QUALDIR message is covered in the Subscriber Data Management.29
4.3.1.2 Mapping of Messages, Parameters & Parameter Values3031
4.3.1.2.1 Mapping of Messages32The following table shows the mapping of messages for the Activation and Deactivation of33Supplementary Services.34
Table 43: Supplementary Service Activation and Deactivation Message Mapping35
GSM MAP Message ANSI-41 MAP MessageActivate SS Request FEATREQDeactivate SS Request FEATREQActivate SS Request Response featreq
Deactivate SS Request Response featreq
X.S0023
3-48
4.3.1.2.2 Mapping of parameters1The following tables show the mapping between the parameters in GSM MAP messages and2parameters in the corresponding ANSI-41 messages. The relationships between the3parameters shown in the tables are meant to be bi-directional.4
Table 44: Activate/Deactivate SS Request FEATREQ Parameter Mapping5
Activate/Deactivate SS Request Status FEATREQ StatusSS-Code M Digits (Dialed) MBasic services C -- ElectronicSerialNumber M- MSID (Either MIN or IMSI) M- BillingID (Originating) O- CallingPartyNumberString1 O- CallingPartyNumberString2 O- CallingPartySubaddress O- ConferenceCallingIndicator O- MobileDirectoryNumber O- MSCID (Serving) O- MSCIdentificationNumber O- OneTimeFeatureIndicator OActivate/Deactivate SS Request Status FEATREQ Status- PC_SSN O- SenderIdentificationNumber O- TransactionCapability O
X.S0023
3-49
Table 45: Activate/Deactivate SS Response Feature Request Return Result Parameter1Mapping2
Activate/Deactivate SSResponse
Status Feature Request Return Result Status
Call forwarding information C -Call barring information C -SS-Data C -- FeatureResult (Note1) MUser Error C Announcement List OProvider Error O -- ActionCode O- Access Denied Reason O- CallingPartyNumberString1 O- CallingPartyNumberString2 O- CallingPartySubaddress O- CarrierDigits O- ConferenceCallingIndicator O- Digits (Dialed) O- DMH_AccountCodeDigits O- DMH_AlternateBillingDigits O- DMH_BillingDigits O- DMH_RedirectionIndicator O- GroupInformation O- MobileDirectoryNumber O- NoAnswerTime O- OneTimeFeatureIndicator O- PACAIndicator O- PilotNumber O- RedirectingNumberDigits O- RedirectingNumberString O- RedirectingSubaddress O- RoutingDigits O- TerminationList O- TerminationTriggers O
3
Note 1: The FeatureResult parameter shall be mapped to “Unsuccessful” if a User Error or a4Provider Error is received in the ACTIVATE/DEACTIVATE SS RESPONSE. Or, a User Error5mapped to an appropriate value shall be returned if the FeatureResult parameter is set to6“Unsuccessful”. See Table 537
X.S0023
3-50
1
Table 46: Activate/Deactivate SS Response Feature Request Return Error Mapping2
Activate/Deactivate SSResponse
Status Return Error Status
Call forwarding information CCall barring information CSS-Data CUser Error CProvider Error O
Error Code O
- Faulty Parameter O3
4.3.1.2.2.1 Mapping of parameter values in GSM Foreign Mode45
Activate/Deactivate SS Request to Feature Request Invoke mapping6
7
This table represents how the IIF shall map the value of the parameter it has received to8populate the fields of the message it shall transmit.9
Table 47: Activate/Deactivate SS Request to FEATREQ Parameter Mapping10
Activate/Deactivate SS Request Status FEATREQ StatusSS-Code M Digits (Dialed)
This parameter shall consist ofan ANSI-41 feature code. TheIIF shall support a table mappingGSM supplementary serviceoperations (e.g. CFB activation)to ANSI-41 feature codes.
M
11
Note that no parameter in the FeatureRequest INVOKE message currently supports the12mapping from the GSM MAP parameter "Basic service". The "GSM Foreign Mode" part of13
4.3.2 SS Registration and Erasure contains procedures pertaining to the handling of the "Basic14service" parameter, when included in the received GSM MAP message.15
X.S0023
3-51
1
Default parameter values2
This table presents how the IIF shall populate the parameters of the Feature Request Invoke3message to be sent to the ANSI-41 VLR. These fields cannot be mapped from the received4Activate/Deactivate SS request message.5
Table 48: FEATREQ default parameter6
FEATREQ Status Default ValueElectronicSerialNumber M Shall be derived from IMSI information
previously received during GSMMAP_OPEN procedures.
MSID (Either MIN or IMSI) M Shall be obtained from mapping from theIMSI received previously (during GSMMAP_OPEN procedures)
BillingID (Originating) O Not required to be included in message.CallingPartyNumberString1 O Not required to be included in message.CallingPartyNumberString2 O Not required to be included in message.CallingPartySubaddress O Not required to be included in message.ConferenceCallingIndicator O Not required to be included in message.MobileDirectoryNumber O May be optionally included in message
from IIF’s data.MSCID (Serving) O May be included from IIF internal data. It is
recommended that it be set to the sameunique ID used during registration toidentify serving MSC.
MSCIdentificationNumber O May be included from IIF data.OneTimeFeatureIndicator O Not required to be included in message.PC_SSN O May be included from IIF data.SenderIdentificationNumber O May be included from IIF data.TransactionCapability O If included, it shall be populated based on
IIF’s MAP interworking capabilities.7
Feature Request Return Result to Activate/Deactivate SS Response mapping8
Mapping of parameter values9
For the successful case (in which a FeatureRequest Return Result is received with the10FeatureResult parameter set to “successful”) there are no meaningful parameter mappings to11support. For those successful cases, the “Default parameter values” describes how the12corresponding GSM Activate/Deactivate SS Response message shall be populated. For the13unsuccessful cases, 4.3.1.3 Error Handling describes the appropriate mappings.14
X.S0023
3-52
Default parameter values1
This table describes the population of the parameters in the Activate/Deactivate SS Response2message for successful activation/deactivation cases (i.e. when the received Feature Request3Return Result contains a FeatureResult parameter set to “successful”).4
Table 49: Activate/Deactivate SS Response default parameter values5
Activate/Deactivate SSResponse
Status Default Value
Call forwarding information C Included for cases in which activationrequest concerned one of the callforwarding features, based on storedinformation in IIF. SS-Code portion ofparameter equal to that in theActivate/Deactivate SS request, and withA-bit of SS-Status portion within thisparameter set to either “1” (for activationcase) or "0" (for deactivation case). Otherbits in field are set to reflect current statusof subscriber's profile.
Call barring information C Subscriber activation/deactivation of callbarring services not required to besupported by IIF, thus population of thisparameter not required.
SS-Data C Included for cases in which activationrequest concerned Call Waiting, based onstored information in IIF. SS-Code portionof parameter equal to Call Waiting, andwith A-bit of SS-Status portion within thisparameter set to either “1” (for activationcase) or "0" (for deactivation case). Otherbits in field are set to reflect current statusof subscriber's profile.
6
X.S0023
3-53
4.3.1.2.2.2 Mapping of parameter values in ANSI-41 Foreign Mode12
Feature Request Invoke to Activate/Deactivate SS Request mapping3
Table 50 represents how the IIF shall map the value of the parameter it has received to4populate the fields of the message it shall transmit.5
Table 50: Feature Request Invoke to Activate/Deactivate SS Request Parameter Mapping6
FEATREQ Status Activate/Deactivate SS Request StatusDigits (Dialed) M SS-Code
The IIF shall support a tablemapping ANSI-41 feature codesto GSM supplementary serviceoperations.
M
7
Default parameter values8
Table 51 presents how the IIF shall populate the parameters of the Activate/Deactivate SS9Request message to be sent to the GSM HLR. These fields do not have an equivalent in the10received Feature Request Invoke message.11
Table 51: Activate/Deactivate SS Request default parameter12
Parameter Name Status ValueBasic services C Not required to be included.
(Activation/deactivation operation shallapply to all service groups when absent.)
13
GSM Activate/Deactivate SS Response to ANSI-41 Feature Request Return Result14mapping15
Mapping of parameter values16
For the successful case (in which there’s no User error or Provider Error in the received GSM17Activate/Deactivate SS Response message), there are no meaningful parameter mappings to18support. For those successful cases, the “Default parameter values” describes how the19corresponding ANSI-41 FeatureRequest Return Result shall be populated. For the20unsuccessful cases, Table 46 describes the appropriate mappings.21
X.S0023
3-54
1
Default parameter values2
Table 52 presents how the IIF shall populate the parameters of the Feature Request Return3Result message to be sent to the ANSI-41 VLR for successful activation cases. Note that the4population of the message may differ for non-activation cases.5
Table 52: FeatureRequest Return Result default parameter6
Parameter Name Status Default ValueFeatureResult M Set to “successful”AccessDeniedReason O Not required to be included.ActionCode O Not required to be included.AnnouncementList O Not required to be included.CallingPartyNumberString1 O Not required to be included.CallingPartyNumberString2 O Not required to be included.CallingPartySubaddress O Not required to be included.CarrierDigits O Not required to be included.ConferenceCallingIndicator O Not required to be included.Digits (Dialed) O Not required to be included.DMH_AccountCodeDigits O Not required to be included.DMH_AlternateBillingDigits O Not required to be included.DMH_BillingDigits O Not required to be included.DMH_RedirectionIndicator O Not required to be included.GroupInformation O Not required to be included.MobileDirectoryNumber O Not required to be included.NoAnswerTime O Not required to be included.OneTimeFeatureIndicator O Not required to be included.PACAIndicator O Not required to be included.PilotNumber O Not required to be included.RedirectingNumberDigits O Not required to be included.RedirectingNumberString O Not required to be included.RedirectingSubaddress O Not required to be included.RoutingDigits O Not required to be included.TerminationList O Not required to be included.TerminationTriggers O Not required to be included.
7
X.S0023
3-55
4.3.1.3 Error Handling12
The following table presents the appropriate GSM MSC/VLR negative response to an3Activate/Deactivate SS message as described in GSM 09.02 [4].4
Appropriate User Error value:5
User Error value
System Failure
Data Missing
Unexpected Data Value
Bearer service not provisioned
Teleservice not provisioned
Call Barred
Illegal SS operation
SS error status
SS subscription violation
SS incompatibility (Activation case only)
Negative PW check
Number of PW Attempts Violation
6
Appropriate Provider Error value:7
8
Provider Error value
Duplicated Invoke ID
Not supported service
Mistyped parameter
Resource limitation
Initiating Release
Unexpected response from the peer
Service Completion Failure
No response from the peer
Invalid response received
9
X.S0023
3-56
The following table presents the appropriate ANSI-41 MSC/VLR negative response to a1Feature Request Invoke message as described in ANSI-41 [2].2
Appropriate AccessDeniedReason parameter values in the FeatureRequest Return Result3(Note, however, that none of these values are applicable to the feature activation scenarios):4
5
AccessDeniedReason
Unassigned directory number
Inactive
Busy
No page Response
Unavailable
TerminationDenied
6
7
Appropriate Error Code parameter value in the Return Error message:8
Error Code value
UnrecognizedMIN
UnrecognizedESN
MIN/HLRMismatch
OperationSequenceProblem
ResourceShortage
OperationNotSupported
ParameterError
SystemFailure
UnrecognizedParameterValue
9
X.S0023
3-57
1
4.3.1.3.1 GSM Foreign Mode23
For cases in which a FeatureRequest Return Result is received by the IIF with a FeatureResult4parameter set to “unsuccessful”, if the AnnouncementList parameter is also present, the IIF5may use the contents of the AnnouncementList in order to provide a better mapping to the User6Error in the Activate/Deactivate SS Response message, as shown in Table 53:7
8
Table 53: FeatureRequest Return Result to User Error in the Activate/Deactivate SS9Response Error Mapping10
FeatureRequest Return Result Activate/Deactivate SS ResponseFeatureResult ="unsuccessful"AnnouncementList="UnauthorizedFeatureCode"
User Error = "SS subscription violation"OrUser Error = “Illegal SS Operation”
FeatureResult ="unsuccessful"AnnouncementList not present
User Error="System Failure"
11
Table 54: FeatureRequest Return Error to Activate/Deactivate SS Response Error12Mapping13
Error Code value User ErrorUnrecognizedMIN System FailureUnrecognizedESN System FailureMIN/HLRMismatch System FailureOperationSequenceProblem System FailureResourceShortage System FailureOperationNotSupported System FailureParameterError System FailureSystemFailure System FailureUnrecognizedParameterValue System FailureSystemFailure System FailureMissingParameter System Failure
14
X.S0023
3-58
1
4.3.1.3.2 ANSI-41 Foreign Mode23
The IIF is responsible for the translation of the User Error/Provider Error received in the4Activate/Deactivate SS Response to either the appropriate FeatureRequest Return Result5message (with FeatureResult set to “unsuccessful” and, if supported, the AnnouncementList6parameter) or Error Code in the FeatureRequest Return Error, as shown in the following two7tables (Table 55 and Table 56).8
Table 55: Activate/Deactivate SS Response User Error to FeatureRequest Return Result9Mapping10
Activate/Deactivate SS Response UserError
FeatureRequest Return Result
SS subscription violation FeatureResult="unsuccessful"AnnouncementList =“UnauthorizedFeatureCode” (if parametersupported by serving system)
X.S0023
3-59
1
Table 56: Activate/Deactivate SS Response User Error to FeatureRequest Return Error2Mapping3
Activate/Deactivate SS Response UserError
FeatureRequest Return Error Error Code
System Failure System FailureData Missing System FailureUnexpected Data Value System FailureBearer service not provisioned Not applicable to SS
activation/deactivation requests sent by IIF(If received, may be mapped to SystemFailure)
Teleservice not provisioned Not applicable to SSactivation/deactivation requests sent by IIF(If received, may be mapped to SystemFailure)
Call Barred Not applicable to SSactivation/deactivation requests sent by IIF(If received, may be mapped to SystemFailure)
Illegal SS operation Not applicable to SSactivation/deactivation requests sent by IIF(If received, may be mapped to SystemFailure)
SS error status Not applicable to SSactivation/deactivation requests sent by IIF(If received, may be mapped to SystemFailure)
SS incompatibility Not applicable to SSactivation/deactivation requests sent by IIF(If received, may be mapped to SystemFailure)
Negative PW check Not applicable to SSactivation/deactivation requests sent by IIF(If received, may be mapped to SystemFailure)
Number of PW Attempts Violation Not applicable to SSactivation/deactivation requests sent by IIF(If received, may be mapped to SystemFailure)
4
X.S0023
3-60
1
Table 57: Activate/Deactivate SS Response Provider Error to Feature Request Return2Error Mapping3
Provider Error value received inActivate/Deactivate SS Response
Feature Request Return ErrorError Code
Duplicated Invoke ID System FailureNot supported service System FailureMistyped parameter System FailureResource limitation System FailureInitiating Release System FailureUnexpected response from the peer System FailureService Completion Failure System FailureNo response from the peer System FailureInvalid response received System Failure
4
X.S0023
3-61
1
4.3.2 SS Registration and Erasure23
4.3.2.1 Registration45
4.3.2.1.1 Detailed Procedures67
4.3.2.1.1 contains the procedures in the IIF for the case in which the subscriber requests8registration of information in association with one of the following supplementary services while9roaming in foreign mode (i.e., while roaming in a network of a technology different from that of10its home network):11
• Call Forwarding Unconditional (in both GSM and ANSI-41 foreign modes)12
• Call Forwarding Busy (in both GSM and ANSI-41 foreign modes)13
• Call Forwarding No Reply (in ANSI-13641 foreign-mode only)14
• Call Forwarding Not Reachable (in ANSI-13641 foreign-mode only)15
• Call Forwarding No Answer (in GSM foreign-mode only)16
17
4.3.2.1.1.1 GSM Foreign Mode1819
While in GSM Foreign Mode, the principal role of the IIF, with respect to supplementary service20registration is that of handling the GSM MAP_REGISTER_SS as follows: If the IIF receives an21GSM MAP_REGISTER_SS message from the GSM serving system, it shall verify the correct22format and content of the message as described in GSM 09.02 [4].23
24
For cases in which the received message contains a "Basic service" parameter, the IIF shall25also verify that the request for registration applies to (at least) speech. If the received request26does not include "speech" as one of the services to which the request applies, the IIF shall27respond with either a GSM MAP_REGISTER_SS Response message that includes a "User28error" parameter with a value of "Illegal SS Operation". Note that cases in which no "Basic29service" parameter is included in the received message are acceptable, since, by default, no30"Basic service" parameter indicates that the request applies to all services.31
32
If the format and content of the message is correct, the IIF shall determine the location of the33subscriber’s HLR and send to it an ANSI-41 FeatureRequest INVOKE message populated as34described in Table 59, Table 62 and Table 63. If a failure occurs at the IIF on reception of the35GSM MAP_REGISTER_SS message (e.g. missing data), the procedures described in GSM3609.02 [4] are applicable to the IIF.37
38
X.S0023
3-62
If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF receives an ANSI-411FeatureRequest Return Result message with a FeatureResult parameter set to successful, the2IIF shall send a GSM MAP_REGISTER_SS Response message back towards the serving3system populated as described in Table 60 and Table 64.4
If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF instead receives an ANSI-415FeatureRequest Return Result message with a FeatureResult parameter set to unsuccessful,6the IIF shall send a GSM MAP_REGISTER_SS Response message back towards the serving7system as described in 4.3.2.2.3 Error Handling.8
If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF instead receives an ANSI-419FeatureRequest Return Error message, the IIF shall send a GSM MAP_REGISTER_SS10Response message back towards the serving system as described in 4.3.2.2.3 Error Handling.11
Note that successful supplementary service registration cases in GSM foreign mode may result12in the subscriber's ANSI-41 HLR sending out an ANSI-41 QUALDIR message to the serving13system. For these cases, the IIF would need to map the message to a GSM MAP Insert14Subscriber Data message. The mapping of an ANSI-41 QUALDIR message to a GSM MAP15Insert Subscriber Data message is covered in the Subscriber Data Management.16
17
4.3.2.1.1.2 ANSI-41 Foreign Mode1819
While in ANSI-41 Foreign Mode, the principal role of the IIF, with respect to supplementary20service registration, is that of handling the ANSI-41 FeatureRequest INVOKE message, as21follows: if the IIF receives an ANSI-41 FeatureRequest INVOKE message from the ANSI-4122serving system, it shall verify the correct format and content of the message as described in23ANSI-41 [2]. If format and content of the message is correct, the IIF shall determine the24location of the subscriber’s HLR and send a GSM MAP_REGISTER_SS Request message25populated as described in in Table 59, Table 66 and Table 67. For cases in which the26FeatureRequest INVOKE message includes a feature code corresponding to Call Forwarding27No Answer, and if the IIF is configured to do so, the IIF may send two MAP_REGISTER_SS28messages, one indicating Call Forwarding No Reply and the other indicating Call Forwarding29Not Reachable. These messages may be sent in parallel. The mapping in Table 59, Table 6630and Table 73 should still be applicable.31
32
For the cases of failure at the IIF on reception of the ANSI-41 FeatureRequest Return Result33message (e.g. parameter error, unrecognized subscriber), the procedures described in34ANSI-41 [2] are applicable to the IIF.35
If, in response to the a GSM MAP_REGISTER_SS Request message, the IIF receives a GSM36MAP_REGISTER_SS Response message with neither a User Error nor Provider Error37parameter, the IIF shall send an ANSI-41 FeatureRequest Return Result message back towards38the serving system populated as described in Table 60 and Table 67. For those cases in which39two requests had been previously sent by the IIF, the IIF would wait until receiving the40responses to both requests before sending the FeatureRequest Return Result message. For41cases in which both responses indicate success, the mapping in Table 60 may be applied to42either of the responses (as an IIF implementation option). For cases in which one of the43responses indicates success and the other failure, the mapping in Table 60 applies to the44successful response.45
X.S0023
3-63
If, in response to the GSM MAP_REGISTER_SS Request message, the IIF instead receives a1GSM MAP_REGISTER_SS Response message with a User Error, the IIF shall send either an2ANSI-41 FeatureRequest Return or a Return Error as described in 4.3.2.2.3 Error Handling.3If a Provider Error parameter is included in the received GSM MAP_REGISTER_SS Response4message, the IIF shall send an ANSI-41 FeatureRequest Return Error message populated with5an Error Code as described in 4.3.2.2.3 Error Handling. For cases in which two requests6had been previously sent by the IIF, and both responses indicate failure, the procedures7described may be applied to either of the responses (as an IIF implementation option).8
Note that successful supplementary service registration cases in ANSI-41 foreign mode may9result in the subscriber's GSM HLR sending out a GSM MAP Insert Subscriber Data message10to the serving system. For these cases, the IIF would need to map the message to an ANSI-4111QUALDIR message. The mapping of GSM MAP Insert Subscriber Data message to an12ANSI-41 QUALDIR message is covered in the Subscriber Data Management.13
14
4.3.2.1.2 Mapping of Messages, Parameters & Parameter Values1516
4.3.2.1.2 presents the mapping of messages, parameters and parameter values that the IIF17shall perform.18
19
4.3.2.1.2.1 Mapping of Messages2021
Table 58 shows the mapping of messages for Supplementary Service Registration22
Table 58: Supplementary Service Registration Message Mapping23
GSM MAP Message ANSI-41 MAP MessageREGISTER SS REQUEST FEATREQ
REGITER SS REQUEST RESPONSE featreq
24
X.S0023
3-64
4.3.2.1.2.2 Mapping of parameters1The following tables show the mapping between the parameters in GSM MAP messages and2parameters in the corresponding ANSI-41 messages. The relationships between the3parameters shown in the tables are meant to be bi-directional.4
Table 59: Register SS Request FEATREQ parameter mapping5
REGISTER SS REQUEST Status FEATREQ StatusSS-Code MForwarded-to number withsubaddress
CDigits (Dialed) M
Basic services C -No reply condition time C -EMLPP default priority C -- ElectronicSerialNumber M- MSID (Either MIN or IMSI) M- BillingID (Originating) O- CallingPartyNumberString1 O- CallingPartyNumberString2 O- CallingPartySubaddress O- ConferenceCallingIndicator O- MobileDirectoryNumber O- MSCID (Serving) O- MSCIdentificationNumber O- OneTimeFeatureIndicator O- PC_SSN O- SenderIdentificationNumber O- TransactionCapability O
6
X.S0023
3-65
Table 60: Register SS Response Feature Request Return Result Parameter Mapping1
Register SS Response Status Feature Request Return Result StatusEMLPP default priority C -Forwarding information C -
FeatureResult (Note 1) MUser Error C Announcement List OProvider Error O -- ActionCode O- Access Denied Reason O- CallingPartyNumberString1 O- CallingPartyNumberString2 O- CallingPartySubaddress O- CarrierDigits O- ConferenceCallingIndicator O- Digits (Dialed) O- DMH_AccountCodeDigits O- DMH_AlternateBillingDigits O- DMH_BillingDigits O- DMH_RedirectionIndicator O- GroupInformation O- MobileDirectoryNumber O- NoAnswerTime O- OneTimeFeatureIndicator O- PACAIndicator O- PilotNumber O- RedirectingNumberDigits O- RedirectingNumberString O- RedirectingSubaddress O- RoutingDigits O- TerminationList O- TerminationTriggers O
2
Note 1: The FeatureResult parameter shall be mapped to an error value if a User Error is3received in the REGISTER SS RESPONSE, or the User Error shall be mapped to an4appropriate value if an Unsuccessful value is received in Feature Result. See Table 68.5
X.S0023
3-66
Table 61: Register SS Response Return Error Parameter Mapping1
Register SS Response Status Return Error StatusEMLPP default priority CForwarding information CUser Error CProvider Error O
Error Code O
- Faulty Parameter O2
4.3.2.1.2.2.1 Mapping of parameter values in GSM Foreign Mode34
Register SS Request to Feature Request Invoke mapping56
Table 62 represents how the IIF shall map the value of the parameter it has received to7populate the fields of the message it shall transmit.8
Table 62: Register SS Request to Feature Request Invoke parameter mapping9
Register SS Request Status FEATREQ StatusSS-Code/Forwarded-to number withsubaddress
MC
Digits (Dialed)This parameter is made up ofdigits that make up a featurecode, plus a forwarded-tonumber. The IIF shall obtain thefeature code from a tablemapping GSM supplementaryservice operations (e.g. CFBregistration) to ANSI-41 featurecodes. The forwarded-to numbercomponent is obtained from the"Forwarded-to number withsubadress" parameter. Note thatany included subaddress in thatparameter is ignored.
M
10
Note that no parameter in the FeatureRequest INVOKE message currently supports the11mapping from the GSM MAP parameter "Basic service". The "GSM Foreign Mode" of12
4.3.2 SS Registration and Erasure contains procedures pertaining to the handling of the "Basic13service" parameter, when included in the received GSM MAP message.14
X.S0023
3-67
Default parameter values1
Table 63 presents how the IIF shall populate the parameters of the Feature Request Invoke2message to be sent to the ANSI-41 HLR. These fields cannot be mapped from the received3Register SS request message.4
Table 63: FEATREQ default parameter56
FEATREQ Status Default ValueElectronicSerialNumber M Shall be derived from IMSI previously
obtained from GSM MAP_OPENinformation.
MSID (Either MIN or IMSI) M Shall be obtained from mapping from theIMSI previously obtained from GSMMAP_OPEN information.
BillingID (Originating) O Not required to be included in message.CallingPartyNumberString1 O Not required to be included in message.CallingPartyNumberString2 O Not required to be included in message.CallingPartySubaddress O Not required to be included in message.ConferenceCallingIndicator O Not required to be included in message.MobileDirectoryNumber O May be optionally included in message
from IIF’s data.MSCID (Serving) O May be included from IIF internal data. It is
recommended that it be set to the sameunique ID used during registration toidentify serving MSC.
MSCIdentificationNumber O May be included from IIF data. Set to theServing MSC's address.
OneTimeFeatureIndicator O Not required to be included in message.PC_SSN O May be included from IIF data.SenderIdentificationNumber O May be included from IIF data.TransactionCapability O If included, it shall be populated based on
IIF’s MAP interworking capabilities.7
X.S0023
3-68
Feature Request Return Result to Register SS Response mapping1
2
Mapping of parameter values3
For the successful case (in which a FeatureRequest Return Result is received with the4FeatureResult parameter set to “successful”) there are no meaningful parameter mappings to5support. For those successful cases, the “Default parameter values” describes how the6corresponding GSM Register SS Response message shall be populated. For the unsuccessful7cases, refer to 4.3.2.2.3 Error Handling.8
9
Default parameter values10
Table 64 describes the population of the parameters in the Register SS Response message for11successful registration cases (i.e. when the received Feature Request Return Result contains a12FeatureResult parameter set to “successful”).13
Table 64: Register SS Response default parameter values14
Register SS Response Status Default ValueCall forwarding information C The forwarded-to number of the
"Forwarding feature" parameter within the"Call forwarding information" parameter ispopulated using the registered address.The suggested values for otherparameters are as follows:- SS-Code: The code of the callforwarding supplementary service to whichthe registration applies.- Basic Service Group: not included;- SS-Status: Based on current status offeature;- forwarded-to subaddress: not included;- forwarding options: not included;- no reply condition timer: May be includedonly for Call Forwarding No Reply cases.
EMLPP default priority C Not applicable. May be ignored whenreceived.
15
X.S0023
3-69
4.3.2.1.2.2.2 Mapping of parameter values ANSI-41 Foreign Mode12
Feature Request Invoke to Register SS Request mapping3
Table 65 represents how the IIF shall map the value of the parameter it has received to4populate the fields of the message it shall transmit.5
Table 65: FEATREQ to Register SS Request parameter mapping6
FEATREQ Status Register SS Request Status
Digits (Dialed) M SS-CodeThe IIF shall support a tablemapping ANSI-41 feature codesto GSM supplementary serviceoperations (e.g. CFBregistration)
M
Digits (Dialed) M Forwarded-to number withsubaddressPopulated from the forwarded-tonumber portion of the Digits(Dialed) parameter.
M
7
Default parameter values8
Table 66 presents how the IIF shall populate the parameters of the Register SS Request9message to be sent to the GSM HLR. These fields do not have an equivalent in the received10Feature Request Invoke message.11
Table 66: Register SS Request default parameter12
Parameter Name Status ValueBasic services C Not required to be included. (Registration
operation shall apply to all service groupswhen absent.)
No reply condition time C Not required to be included.EMLPP default C Not required to be included.
13
X.S0023
3-70
1
GSM Register SS Response to ANSI-41 Feature Request Return Result mapping2
3
Mapping of parameter values4
For the successful case (in which there’s no User error or Provider Error in the received GSM5Register SS Response message), there are no meaningful parameter mappings to support.6For those successful cases, the “Default parameter values” describes how the corresponding7ANSI-41 FeatureRequest Return Result shall be populated. For the unsuccessful cases, refer8to 4.3.2.2.3 Error Handling.9
10
Default parameter values11
Table 67 presents how the IIF shall populate the parameters of the Feature Request Return12Result message to be sent to the ANSI-41 VLR for successful supplementary service13registration cases. Note that the population of the message may differ for non-registration14cases.15
Table 67: FeatureRequest Return Result default parameter16
Parameter Name Status Default ValueFeatureResult M Set to “successful”AccessDeniedReason O Not required to be included.ActionCode O Not required to be included.AnnouncementList O Not required to be included.CallingPartyNumberString1 O Not required to be included.CallingPartyNumberString2 O Not required to be included.CallingPartySubaddress O Not required to be included.CarrierDigits O Not required to be included.ConferenceCallingIndicator O Not required to be included.Digits (Dialed) O Not required to be included.DMH_AccountCodeDigits O Not required to be included.DMH_AlternateBillingDigits O Not required to be included.DMH_BillingDigits O Not required to be included.DMH_RedirectionIndicator O Not required to be included.GroupInformation O Not required to be included.MobileDirectoryNumber O Not required to be included.NoAnswerTime O Not required to be included.OneTimeFeatureIndicator O Not required to be included.
17
X.S0023
3-71
1
Table 67: FeatureRequest Return Result default parameter (concluded)2
Parameter Name Status Default ValuePACAIndicator O Not required to be included.PilotNumber O Not required to be included.RedirectingNumberDigits O Not required to be included.RedirectingNumberString O Not required to be included.RedirectingSubaddress O Not required to be included.RoutingDigits O Not required to be included.TerminationList O Not required to be included.TerminationTriggers O Not required to be included.
3
4.3.2.1.3 Error Handling45
The error handling procedures specified for supplementary service activation apply also for the6supplementary service registration case, with the following modification: the User Error values7"SS subscription violation", "Negative PW Check", and "Number of PW Attempts Violation",8although valid for the activation case, are not valid for the registration case. If any of those9values are received in the User Error parameter of a Register SS Response, they may be10mapped to "System Failure". Also, the IIF may not include any of those User Error values in11the Register SS Response messages it sends.12
Table 68: FeatureRequest Return Result to User Error in the Register SS Response13mapping14
FeatureRequest Return Result User Error in the Register SS ResponseFeatureResult ="unsuccessful"AnnouncementList="UnauthorizedFeatureCode"
User Error = "SS subscription violation"
FeatureResult ="unsuccessful"AnnouncementList not present
User Error="System Failure"
15
X.S0023
3-72
4.3.2.2 Erasure12
4.3.2.2.1 Detailed Procedures34
4.3.2.2.1 contains the procedures in the IIF for the case in which the subscriber requests5erasure (de-registration) of information in association with one of the following supplementary6services while roaming in foreign mode (i.e., while roaming in a network of a technology7different from that of its home network):8
9
• Call Forwarding Unconditional (in both GSM and ANSI-41 foreign modes)10
• Call Forwarding Busy (in both GSM and ANSI-41 foreign modes)11
• Call Forwarding No Reply (in ANSI-41 foreign-mode only)12
• Call Forwarding Not Reachable (in ANSI-41 foreign-mode only)13
• Call Forwarding No Answer (in GSM foreign-mode only)14
15
4.3.2.2.1.1 GSM Foreign Mode1617
While in GSM Foreign Mode, the principal role of the IIF, with respect to supplementary service18erasure is that of handling the GSM MAP_ERASE_SS as follows: If the IIF receives an GSM19MAP_ERASE_SS message from the GSM serving system, it shall verify the correct format and20content of the message as described in GSM 09.02 [4].21
22
For cases in which the received message contains a "Basic service" parameter, the IIF shall23also verify that the request for erasure applies to (at least) speech. If the received request does24not include "speech" as one of the services to which the request applies, the IIF shall respond25with either a GSM MAP_ERASE_SS Response message that includes a "User error"26parameter with a value of "Illegal SS Operation". Note that cases in which no "Basic service"27parameter is included in the received message are acceptable, since, by default, no "Basic28service" parameter indicates that the request applies to all services.29
30
If the format and content of the message is correct, the IIF shall determine the location of the31subscriber’s HLR and send to it an ANSI-41 FeatureRequest INVOKE message populated as32described in Table 70, Table 73 and Table 74. If a failure occurs at the IIF on reception of the33GSM MAP_ERASE_SS message (e.g. missing data), the procedures described in GSM 09.0234[4] are applicable to the IIF.35
36
If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF receives an ANSI-4137FeatureRequest Return Result message with a FeatureResult parameter set to successful, the38
X.S0023
3-73
IIF shall send a GSM MAP_ERASE_SS Response message back towards the serving system1populated as described in Table 71 and Table 75.2
3
If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF instead receives an ANSI-414FeatureRequest Return Result message with a FeatureResult parameter set to unsuccessful,5the IIF shall send a GSM MAP_ERASE_SS Response message back towards the serving6system as described in Table 71 and Table 79.7
If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF instead receives an ANSI-418FeatureRequest Return Error message, the IIF shall send a GSM MAP_ERASE_SS Response9message back towards the serving system as described in 4.3.2.2.3 Error Handling.10
Note that successful supplementary service erasure cases in GSM foreign mode may result in11the subscriber's ANSI-41 HLR sending out an ANSI-41 QUALDIR message to the serving12system. For these cases, the IIF would need to map the message to a GSM MAP Insert13Subscriber Data message. The mapping of an ANSI-41 QUALDIR message to a GSM MAP14Insert Subscriber Data message is covered in the Subscriber Data Management.15
16
4.3.2.2.1.2 ANSI-41 Foreign Mode1718
While in ANSI-41 Foreign Mode, the principal role of the IIF, with respect to supplementary19service erasure, is that of handling the ANSI-41 FeatureRequest INVOKE message, as follows:20If the IIF receives an ANSI-41 FeatureRequest INVOKE message from the ANSI-41 serving21system, it shall verify the correct format and content of the message as described in ANSI-4122[2]. If format and content of the message is correct, the IIF shall determine the location of the23subscriber’s HLR and send a GSM MAP_ERASE_SS Request message populated as described24in Table 70 and Table 77. For cases in which the FeatureRequest INVOKE message includes a25feature code corresponding to Call Forwarding No Answer, and if the IIF is configured to do so,26the IIF may send two MAP_ERASE_SS messages, one indicating Call Forwarding No Reply and27the other indicating Call Forwarding Not Reachable. These messages may be sent in parallel.28The mapping in Table 70,Table 75 and Table 77 would still be applicable.29
For the cases of failure at the IIF on reception of the ANSI-41 FeatureRequest Return Result30message (e.g. parameter error, unrecognized subscriber), the procedures described in31ANSI-41 [2] are applicable to the IIF.32
If in response to the a GSM MAP_ERASE_SS Request message, the IIF receives a GSM33MAP_ERASE_SS Response message with neither a User Error nor Provider Error parameter,34the IIF shall send an ANSI-41 FeatureRequest Return Result message back towards the serving35system populated as described in Table 71. For those cases in which two requests had been36previously sent by the IIF, the IIF would wait until receiving the responses to both requests37before sending the FeatureRequest Return Result message. For cases in which both responses38indicate success, the mapping in Table 71 may be applied to either of the responses (as an IIF39implementation option). For cases in which one of the responses indicates success and the40other failure, the mapping in Table 71, Table 75 and Table 86 applies to the successful41response.42
If, in response to the GSM MAP_ERASE_SS Request message, the IIF instead receives a43GSM MAP_ERASE_SS Response message with a User Error, the IIF shall send either an44ANSI-41 FeatureRequest Return Result or a Return Error as described in 4.3.2.2.3 Error45Handling If a Provider Error parameter is included in the received GSM MAP_ERASE_SS46
X.S0023
3-74
Response message, the IIF shall send an ANSI-41 FeatureRequest Return Error message1populated with an Error Code. For cases in which two requests had been previously sent by the2IIF, and both responses indicate failure, the procedures described in 4.3.2.2.3 Error Handling3may be applied to either of the responses (as an IIF implementation option).4
Note that successful supplementary service erasure cases in ANSI-41 foreign mode may result5in the subscriber's GSM HLR sending out a GSM MAP Insert Subscriber Data message to the6serving system. For these cases, the IIF would need to map the message to an ANSI-417QUALDIR message. The mapping of GSM MAP Insert Subscriber Data message to an8ANSI-41 QUALDIR message is covered in the Subscriber Data Management.9
4.3.2.2.2 Mapping of Messages, Parameters & Parameter Values104.3.2.2.2 presents the mapping of messages, parameters and parameter values that the IIF11shall perform.12
13
4.3.2.2.2.1 Mapping of Messages14Table 69 shows the mapping of messages for Supplementary Service Erasure.15
Table 69: Supplementary Service Erasure Message Mapping16
GSM MAP Message ANSI-41 MAP MessageERASE SS REQUEST FEATREQ
ERASE SS REQUEST RESPONSE featreq
17
X.S0023
3-75
4.3.2.2.2.2 Mapping of parameters1The following tables show the mapping between the parameters in GSM MAP messages and2parameters in the corresponding ANSI-41 messages. The relationships between the3parameters shown in the tables are meant to be bi-directional.4
Table 70: Erase SS Request FEATREQ parameter mapping5
Erase SS Request Status FEATREQ StatusSS-Code M Digits (Dialed) MBasic services C -- ElectronicSerialNumber M- MSID (Either MIN or IMSI) M- BillingID (Originating) O- CallingPartyNumberString1 O- CallingPartyNumberString2 O- CallingPartySubaddress O- ConferenceCallingIndicator O- MobileDirectoryNumber O- MSCID (Serving) O- MSCIdentificationNumber O- OneTimeFeatureIndicator O- PC_SSN O- SenderIdentificationNumber O- TransactionCapability O
6
X.S0023
3-76
Table 71: Erase SS Response Feature Request Return Result parameter mapping1
Erase SS Response Status Feature Request Return Result StatusForwarding information C -- FeatureResult (Note1) MUser Error C Announcement List OProvider Error O -- ActionCode O- Access Denied Reason O- CallingPartyNumberString1 O- CallingPartyNumberString2 O- CallingPartySubaddress O- CarrierDigits O- ConferenceCallingIndicator O- Digits (Dialed) O- DMH_AccountCodeDigits O- DMH_AlternateBillingDigits O- DMH_BillingDigits O- DMH_RedirectionIndicator O- GroupInformation O- MobileDirectoryNumber O- NoAnswerTime O- OneTimeFeatureIndicator O- PACAIndicator O- PilotNumber O- RedirectingNumberDigits O- RedirectingNumberString O- RedirectingSubaddress O- RoutingDigits O- TerminationList O- TerminationTriggers O
2
Note 1: The FeatureResult parameter shall be mapped to an error value if a User Error is3received in the ERASE SS RESPONSE4
5
X.S0023
3-77
1
Table 72: Erase SS Response Return Error parameter mapping2
Erase SS Response Status Return Error StatusCall forwarding information C -User Error CProvider Error O
Error Code O
- Faulty Parameter O3
4.3.2.2.2.2.1 Mapping of parameter values in GSM Foreign Mode45
Erase SS Request to Feature Request Invoke mapping6
Table 73 represents how the IIF shall map the value of the parameter it has received to7populate the fields of the message it shall transmit.8
Table 73: Erase SS Request to FEATREQ parameter mapping9
Erase SS Request Status FEATREQ StatusSS-Code M Digits (Dialed)
This parameter shall be made upof digits that make up the featurecode string that corresponds toerasure (de-registration) of theinformation that pertains to thesupplementary service specifiedin the SS-Code parameter. TheIIF shall obtain the feature codefrom a table mapping GSMsupplementary serviceoperations (e.g. CFB erasure) toANSI-41 feature codes.
M
10
Note that no parameter in the FeatureRequest INVOKE message currently supports the11mapping from the GSM MAP parameter "Basic service". The "GSM Foreign Mode" part of12
13
4.3.2 SS Registration and Erasure contains procedures pertaining to the handling of the "Basic14service" parameter, when included in the received GSM MAP message.15
X.S0023
3-78
Default parameter values1
2
Table 74 presents how the IIF shall populate the parameters of the Feature Request Invoke3message to be sent to the ANSI-41 VLR. These fields cannot be mapped from the received4Erase SS request message.5
Table 74: Feature Request Invoke default parameter6
FEATREQ Status Default ValueElectronicSerialNumber M Shall be derived from IMSI previously
obtained from GSM MAP_OPEN information.MSID (MIN or IMSI) M Shall be obtained from mapping from the IMSI
obtained previously from GSM MAP_OPENinformation.
BillingID (Originating) O Not required to be included in message.CallingPartyNumberString1 O Not required to be included in message.CallingPartyNumberString2 O Not required to be included in message.CallingPartySubaddress O Not required to be included in message.ConferenceCallingIndicator O Not required to be included in message.MobileDirectoryNumber O May be optionally included in message from
IIF’s data.MSCID (Serving) O May be included from IIF internal data. It is
recommended that it be set to the sameunique ID used during registration to identifyserving MSC.
MSCIdentificationNumber O May be included from IIF data.OneTimeFeatureIndicator O Not required to be included in message.PC_SSN O May be included from IIF data.SenderIdentificationNumber O May be included from IIF data.TransactionCapability O If included, it shall be populated based on
IIF’s MAP interworking capabilities.7
Feature Request Return Result to Erase SS Response mapping8
9
Mapping of parameter values10
11
For the successful case (in which a FeatureRequest Return Result is received with the12FeatureResult parameter set to “successful”) there are no meaningful parameter mappings to13support. For those successful cases, the “Default parameter values” describes how the14corresponding GSM Erase SS Response message shall be populated. For the unsuccessful15cases, refer to 4.3.2.2.3 Error Handling16
17
X.S0023
3-79
Default parameter values1
Table 75 describes the population of the parameters in the Erase SS Response message for2successful erasure cases (i.e. when the received Feature Request Return Result contains a3FeatureResult parameter set to “successful”).4
Table 75: Erase SS Response default parameter values5
Erase SS Response Status Default ValueCall forwardinginformation
C The suggested values for the fields in this parameterare as follows:- SS-Code: The code of the call forwardingsupplementary service to which the registrationapplies.- Basic Service Group: not included;- SS-Status: Based on current status of feature;- forwarded-to number: not included;- forwarded-to subaddress: not included;- forwarding options: not included;- no reply condition timer: May be included only forCall Forwarding No Reply cases.
6
4.3.2.2.2.2.2 Mapping of parameter values in ANSI-41 Foreign Mode78
Feature Request Invoke to Erase SS Request mapping9
Table 76 represents how the IIF shall map the value of the parameter it has received to10populate the fields of the message it shall transmit.11
Table 76: FEATREQ to Erase SS Request parameter mapping12
FEATREQ Status Erase SS Request StatusDigits (Dialed) M SS-Code
The IIF shall support a tablemapping ANSI-41 feature codesto GSM supplementary serviceoperations (e.g. CFB erasure)
M
13
X.S0023
3-80
Default parameter values1
This table presents how the IIF shall populate the parameters of the Erase SS Request2message to be sent to the GSM HLR. These fields do not have an equivalent in the received3Feature Request Invoke message.4
Table 77: Erase SS Request default parameter5
Parameter Name Status ValueBasic services C Not required to be included. (Registration operation
shall apply to all service groups when absent.)6
GSM Erase SS Response to ANSI-41 Feature Request Return Result mapping7Mapping of parameter values8
For the successful case (in which there is no User error or Provider Error present in the9received GSM Erase SS Response message), there are no meaningful parameter mappings to10support. For those successful cases, the “Default parameter values” describes how the11corresponding ANSI-41 FeatureRequest Return Result shall be populated. For the12unsuccessful cases, refer to 4.3.2.2.3 Error Handling.13
X.S0023
3-81
Default parameter values1
This table presents how the IIF shall populate the parameters of the Feature Request Return2Result message to be sent to the ANSI-41 HLR for successful erasure cases. Note that the3population of the message may differ for non-erasure cases.4
Table 78: FeatureRequest Return Result default parameter5
Parameter Name Status Default ValueFeatureResult M Set to “successful”AccessDeniedReason O Not required to be included.ActionCode O Not required to be included.AnnouncementList O Not required to be included.CallingPartyNumberString1 O Not required to be included.CallingPartyNumberString2 O Not required to be included.CallingPartySubaddress O Not required to be included.CarrierDigits O Not required to be included.ConferenceCallingIndicator O Not required to be included.Digits (Dialed) O Not required to be included.DMH_AccountCodeDigits O Not required to be included.DMH_AlternateBillingDigits O Not required to be included.DMH_BillingDigits O Not required to be included.DMH_RedirectionIndicator O Not required to be included.GroupInformation O Not required to be included.MobileDirectoryNumber O Not required to be included.NoAnswerTime O Not required to be included.OneTimeFeatureIndicator O Not required to be included.PACAIndicator O Not required to be included.PilotNumber O Not required to be included.RedirectingNumberDigits O Not required to be included.RedirectingNumberString O Not required to be included.RedirectingSubaddress O Not required to be included.RoutingDigits O Not required to be included.TerminationList O Not required to be included.TerminationTriggers O Not required to be included.
X.S0023
3-82
4.3.2.2.3 Error Handling12
The error handling procedures specified for supplementary service activation apply also for the3supplementary service erasure case, with the following modification: the User Error values "SS4subscription violation", "SS incompatibility", "Negative PW Check", and "Number of PW5Attempts Violation", although valid for the activation case, are not valid for the erasure case. If6any of those values are received in the User Error parameter of a Register SS Response, they7may be mapped to "System Failure". Also, the IIF may not include any of those User Error8values in the Erase SS Response messages it sends.9
10
Table 79: FeatureRequest Return Result to Register SS Response User Error11
FeatureRequest Return Result User Error in the Erase SS ResponseFeatureResult ="unsuccessful"AnnouncementList="UnauthorizedFeatureCode"
User Error = "SS subscription violation"
FeatureResult ="unsuccessful"AnnouncementList not present
User Error="System Failure"
12
X.S0023
3-83
4.3.3 Retrieval of Forward-To Number12
4.3.3.1 Detailed Procedures34
The following procedures are applicable at the IIF for retrieval of forwarded-to-number, in GSM5foreign mode. These procedures are applicable for Call Forwarding Busy (CFB) and Call6Forwarding No Answer (CFNA), which will be referred to as Conditional Call Forwarding.7
In GSM, the HLR provides the forwarded-to-number(s) to the serving MSC/VLR as part of the8profile update procedure, in the MAP_Insert_Subscriber_Data message (or, as part of the9response to a MAP_Interrogate_SS request). The ANSI-41 HLR, however, only provides this10information when the Call Forwarding feature is actually invoked. Therefore, in GSM foreign11mode, in order to the able to include the forwarded-to-number(s) in the12MAP_Insert_Subscriber_Data message to the serving system during profile updates, the IIF13has to, beforehand, explicitly request the ANSI-41 HLR for the forwarded-to-number(s). The IIF14makes this request to the ANSI-41 HLR via the TransferToNumberRequest Invoke message.15(Note that two separate TRANUMREQ messages may be needed: one for CFB and another for16CFNA. The two requests may be sent in parallel by the IIF). The IIF shall then store the17received forwarded-to numbers for subsequent use.18
Specifically, before a MAP_Insert_Subscriber_Data message is sent by the IIF, the IIF shall19determine if it needs to query the ANSI-41 HLR for the CFB or CFNA forwarded-to number(s).20
In general, the IIF needs to query the ANSI-41 HLR at least for the case in which the21CFB/CFNA feature is authorized and active for the subscriber, and the profile update procedure22is being performed immediately after an initial successful location update of the subscriber in23GSM foreign mode1. Other cases for initiating the query may be supported by the IIF as24follows:25
a) After a recent successful forwarded-to number registration pertaining to either the CFB or26CFNA feature.27
(Note, however, that a query after a forwarded-to number registration may not be28necessary if the IIF saves the forwarded-to number while processing the registration29messages.)30
After a successful location update when either the CFB or CFNA feature is authorized, but not31necessarily active.32
(This case differs from the mandatory case in that the CFB/CFNA feature need not be33active in order to initiate the query. Supporting this case would make it unnecessary for34the query to be performed after an activation of the CFB/CFNA feature)35
b) After a recent successful activation of either the CFB or CFNA feature.36
(Note that this case would only be needed if the IIF had not queried the ANSI-41 HLR37previously. In particular if the IIF, during the initial location update, does not perform the38query because the CFB/CFNA feature is not active.)39
c) On a regular basis (e.g. timer-based)40
1 Note that this refers only to the successful location update case. There's no need for theIIF to perform this procedure for unsuccessful cases.
X.S0023
3-84
(Supporting this case would be useful for accounting for the possibility of a network1administrator-initiated change of the forwarded-to DN(s)).2
The IIF shall populate the TransferToNumberRequest Invoke message in a manner compliant3with ANSI-41 [2]. The IIF shall then send the TransferToNumberRequest Invoke message to4the ANSI-41 HLR, start the Transfer-To-Number Request Timer, and wait for a response.5
If the response indicates that the retrieval of forwarded-to-number procedure has been6successful, the IIF shall map the forwarded-to-number information (along with any other7subscriber profile information received in either the QualificationDirective Invoke or8RegistrationNotification RETURN RESULT) into a MAP_Insert_Subscriber_Data Request9message. As shown in Table 81 and Table 82, the Forwarded-to-Number field of the10TransferToNumberRequest RETURN RESULT shall be mapped from the Digits (Destination)11field in the MAP_Insert_Subscriber_Data message. In addition, if the registration deals with Call12Forwarding No Answer, the No Reply Condition Time parameter in the13MAP_Insert_Subscriber_Data message should be populated with the content of the14NoAnswerTime field in the TransferToNumberRequest RETURN RESULT message.15
In case of a failure, the IIF may receive either a TransferToNumberRequest RETURN RESULT16with the field AccessDeniedReason present, or a Return Error or Reject message with an Error17Code value. For those cases in which a failure occurs, the IIF shall continue to use a18previously obtained forwarded-to number, if available. If no previously obtained forwarded-to19number is available at the IIF, the IIF shall not populate the corresponding information (i.e., the20Forwarded-to-Number field within the Forwarding Information List parameter) in the21MAP_Insert_Subscriber_Data Request message.22
4.3.3.2 Mapping of Messages, Parameters & Parameter Values2324
Note: the mapping of the QualificationDirective Invoke message to the25MAP_Insert_Subscriber_Data Request message is described in details in 4.4 O&M26Procedures. Therefore, 4.3.3.2 focuses on the mapping of TransferToNumberRequest return27result to the relevant MAP_Insert_Subscriber_Data field. Not all Insert Subscriber Data fields28are shown in the following tables.29
4.3.3.2.1 Mapping of Messages3031
The following table shows the mapping of messages for Retrieval of Forward-to-Number in32GSM Foreign Mode.33
Table 80: Retrieval of Forward-to-Number in GSM Foreign Mode34
ANSI MAP MESSAGE GSM MAP MESSAGETransfer to Number Request Return Result INSERT SUBSCRIBER DATA
35
X.S0023
3-85
4.3.3.2.2 Mapping of parameters1The following tables are only for GSM Foreign Mode.2
3
Table 81: TransferToNumberRequest Return Result to Insert Subscriber Data parameter4mapping5
TransferToNumberRequestReturn Result
Status Insert Subscriber Data Status
Digits (Destination)or TerminationList (see Note 1)
MO
Forwarded-to-Number (withinForwarding Information List)
C
AccessDeniedReason O -ActionCode O -AnnouncementList O -CallingPartyString1 O -CallingPartyString2 O -CallingPartySubaddress O -Digits (Carrier) O -DMH_AccountCodeDigits O -DMH_AlternateBillingDigits O -DMH_BillingDigits O -DMH_RedirectionIndicator (Setto CFB or CFNA)
O -
GroupInformation O -MobileDirectoryNumber O -NoAnswerTime O No Reply Condition time (within
Forwarding Information List)C
RedirectingNumberDigits O -RedirectingNumberString O -RedirectingSubaddress O -TerminationTriggers O -CDMAServiceOption (Note 2) O -GSM BearerServiceCode or
GSm TeleServiceO
6
Note 1: When TerminationList parameter is present, the Digits (Destination) parameter is7ignored.8
Note 2: Optional, if the network settings support data, a mapping may be performed as9described in Table 92.10
X.S0023
3-86
TransferToNumberRequest Return Result to Insert Subscriber Data Request1
Mapping of parameters value2
Table 82 represents how the IIF shall map the value of the parameter it has received to3populate the fields of the message it shall transmit.4
Table 82: TransferToNumberRequest Return Result to Insert Subscriber Data Request5value mapping6
TransferToNumberRequest ReturnResult
Status Insert Subscriber Data Request Status
Digits (Destination) orDestinationDigits parameter withinTerminationList (See Note 1)This is the forwarded-to-number.Format is Type of Digits (1 octet),Nature of Number (1 octet),Numbering Plan (4 bits), Encoding(4 bits), Number of Digits (1 octet),and actual digits in BCD.
M Forwarding Information List Forwarded-to-Number(See Note 2)E.164 format
C
NoAnswerTime O Forwarding Information List No Reply Condition time
C
CDMAServiceOption (Note 3) O -GSM BearerServiceCode orGSM TeleService
O
Note 1: When TerminationList parameter is present, the Digits (Destination) parameter of the7TransferToNumberRequest RETURN RESULT is ignored.8
Note 2: There may be up to three forwarded-to number parameters with the Insert Subscriber9Data Request message mapped from TransferToNumberRequest information: one for Call10Forwarding Busy, one for Call Forwarding No Reply (mapped from CFNA results), and another11for Call Forwarding Not Reachable (also mapped from CFNA results).12
Note 3: Optional, if the network settings support data, a maping may be performed as13described in Table 92.14
Default parameter value15
The other parameters in the TransferToNumberRequest Return Result message are not16mapped to any of the Insert Subscriber Data Request parameters.17
4.3.3.3 Error Handling1819
No mapping between ANSI-41 and GSM MAP messages is required for cases in which the20forwarded-to number retrieval operation fails. Refer to 4.3.3.1 Detailed Procedures for a21description of the IIF procedures when the forwarded-to number retrieval operation fails.22
23
X.S0023
3-87
4.3.4 Calling Number / Line Identification Presentation/Restriction1The calling number/line identification Presentation/Restriction procedure is used to determine2whether the calling party number should be presented to the called party.3
4.3.4.1 Handling of calling number/ line identification presentation4
4.3.4.1.1 Detailed Procedures5If CNIP / CLIP service is authorized and active, the calling party number is available and6presentation is allowed, the called party’s serving network shall provide the calling party7number to the called party during call alerting.8
If the IIF receives a GSM MAP _PROVIDE_ROAMING_Request with the Calling Party Number9in the Additional Signal Info field correctly populated, the IIF shall send an ANSI_MAP10ROUTEREQ to the serving MSC/VLR with the Calling Party Number field correctly mapped.11
If the IIF receives an ANSI_MAP ROUTREQ with the Calling Party Number field in the12Additional Signal Info field correctlty populated, the IIF shall send a GSM MAP13_PROVIDE_ROAMING_NUMBER_Request to the serving MSC/VLR with the Calling Party14Number field correctly mapped.15
4.3.4.1.2 Mapping of Messages, Parameters & Parameter Values16
4.3.4.1.2.1 Mapping of Messages17The mapping of messages is in accordance with 4.2.1, with the exception that GSM 09.02 [4] is18supported.19
X.S0023
3-88
4.3.4.1.2.2 Mapping of Parameters1The following tables show the mapping of parameters specific to handling calling number/line2presentation/restrcition, which the IIF shall perform regardless of the mode of operation (GSM3Foreign Mode or ANSI-41 Foreign Mode). The mapping of other parameters not specific to4handling calling number/line presentation/restriction can be found in 4.2.1, with the exception5that GSM 09.02 [4] is supported.6
Note: The tables are constructed in such a way that the parameter names appear first and any7information contained within those parameters are shown as indented text.8
Table 83: Routing Request Provide Roaming Number Request (Network Provided9number) Parameter Mapping10
Routing Request Status Provide Roaming Number StatusCallingPartyNumberString1(Network Provided No):-
Type Of Digits:- Calling PartyNumber
Nature of Number:- National,Presentation Allowed, NetworkProvided
Numbering Plan:- TelephonyNumbering
Encoding:- IA5
Characters:- Digits
O AdditionalSignalInfo:-CallingPartyNumber:-
-
Screening Indicator: NetworkProvidedPresentation Indicator:Presentation Allowed
-
-
Line Identity: E164 address ofCalling Party
C
X.S0023
3-89
Table 84: Routing Request Provide Roaming Number Request (User Provided1number) Parameter Mapping2
Route Request Status Provide Roaming Number StatusCallingPartyNumberString2(User Provided No):-
Type Of Digits:- Calling PartyNumber
Nature of Number:-National,Presentation Allowed,User Provided, not screened
Numbering Plan:- TelephonyNumbering
Encoding:- IA5
Characters:- Digits
O AddititonalSignalInfo:-CallingPartyNumber:-
-
Screening Indicator: UserProvided, not screenedPresentation Indicator:Presentation Allowed
-
-
Line Identity: E164 address ofCalling Party
C
3
X.S0023
3-90
Table 85: Routing Request Provide Roaming Number Request (Two calling party1numbers) Parameter Mapping2
Route Request Status Provide Roaming Number StatusCallingPartyNumberString1(Network Provided No):-
Type Of Digits:- Calling PartyNumber
Nature of Number:- National,Presentation Allowed,Network Provided
Numbering Plan:- TelephonyNumbering
Encoding:-IA5
Characters:- Digits
O AdditionalSignalInfo:-CallingPartyNumber:-
-
Screening Indicator: NetworkProvidedPresentation Indicator:Presentation Allowed
-
-
Line Identity: E164 address ofCalling Party
C
CallingPartyNumberString2(User Provided No):-
Type Of Digits:- Calling PartyNumber
Nature of Number:- National,Presentation AllowedUser Provided
Numbering Plan:- TelephonyNumbering
Encoding:- IA5
Characters:- Digits
O Generic Number:-
-
Screening Indicator: UserProvided, not screened
-
-
Line Identity: E164 address ofCalling Party
3
4.3.4.2 Handling of calling number/ line identification restriction4
4.3.4.2.1 Detailed Procedures5If the calling subscriber has calling number/line identification restriction authorized and active6and it is impossible to indicate to the terminating network (due to interworking) that the number7shall not be presented to the terminating party, the calling number/line identity shall not be8delivered to the terminating network.9
If CNIR / CLIR service is authorized and active, the calling party number is available and10presentation is restricted, the called party’s serving network shall not present the calling party11
X.S0023
3-91
number to the called party during call alerting. An indication that the calling party number is1restricted shall be delivered to the called party.2
4.3.4.2.2 Mapping of Messages, Parameters and Parameter Values3
4.3.4.2.2.1 Mapping of Messages4Messages for Calling number/line identification restriction is the same as 4.3.4.1.5
4.3.4.2.2.2 Mapping of Parameters6The following table shows the mapping of parameters for calling name/line restriction, which the7IIF shall perform regardless of the mode of operation (ANSI-41 Foreign Mode or GSM Foreign8mode).9
Table 86: Routing Request Provide Roaming Number Request(Caller Id Restricted)10Parameter Mapping11
Routing Request Status Provide Roaming Number Status
CallingPartyNumberString1(Network Provided No):-
Type Of Digits:- Calling PartyNumber
Nature of Number:- National,Presentation Restricted,Network Provided
Numbering Plan:- TelephonyNumbering
Encoding:- IA5
Characters:-Digits
O AdditionallSignalInfo:-CallingPartyNumber:-
-
Screening Indicator: NetworkProvided,Presentation Indicator:Presentation Restrcited
-
-
Line Identity: E164 address ofCalling Party
C
4.3.4.3 Error Handling12For the cases of failure at the IIF on reception of an ANSI_ MAP_RoutingRequest return Result,13the procedures described in ANSI-41 [2] for automatic call delivery is applicable to the IIF.14
For the cases of failure at the IIF on resception of a GSM MAP15_PROVIDE_ROAMING_NUMBER_Response, the procedures described in GSM 09.02 [4] are16applicable to the IIF.17
If the IIF receives a GSM MAP _PROVIDE_ROAMING_NUMBER_Request indicating an error18code, the IIF shall map that error code it receives to a suitable error in the ANSI_MAP_routereq19as described in 4.2.120
If the IIF receives an ANSI_MAP_routreq indicating an error code, the IIF shall map that error21code it receives to a suitable error in the GSM MAP22_PROVIDE_ROAMING_NUMBER_Response as described in 4.2.1.23
X.S0023
3-92
4.4 O&M Procedures1
Existing operation and maintenance procedures described in either GSM 09.02 [4] or ANSI-412[2] are also directly applicable to the IIF when it is emulating a GSM or ANSI-41 functional3network element. Enhancements/modifications to ANSI-41 [2] are also applicable.4
4.4.1 Detailed Procedures5Subscriber data management procedures are used to either delete or modify, subscriber data6held in the network. These procedures are initiated by the OMC.7
Subscriber data management procedures also cover ANSI-41 specific procedures, describing8the retrieval of subscriber data from network elements.9
The IIF contains both permanent subscriber data (can only be changed by administration10means) and temporary subscriber data (may be changed as a result of normal operation of the11system) relating to the roaming subscriber.12
4.4.1.1 Subscriber Deletion Procedure13If the IIF receives a GSM MAP _CANCEL_LOCATION_REQUEST, it shall follow the location14cancellation procedures outlined in this document for Location Registration (see 4.1.1).15
If the IIF receives an ANSI_MAP_REGCAN, it shall follow the location cancellation procedures16outlined in this document for Location Registration (see 4.1.1).17
4.4.1.2 Subscriber Data Modification Procedure (ANSI-41 Foreign Mode)18If the IIF receives either a GSM MAP _INSERT_SUBSCRIBER_DATA_REQUEST, or a GSM19MAP _DELETE_SUBSCRIBER_DATA_REQUEST, it shall follow the VLR procedures20described in GSM 09.02 [4].21
As part of the subscriber data modification procedure, the IIF may send an22ANSI_MAP_QUALDIR to the serving ANSI-41 VLR and await a response.23
If the response indicates success, the IIF shall modify the corresponding subscriber data and24send a GSM MAP _INSERT_SUBSCRIBER_DATA_RESPONSE to the GSM HLR.25
If the response indicates failure, the received subscriber data is stored by IIF even if there is a26failure reported from the visited (foreign mode) system and the IIF shall send the reason for27failure in a GSM MAP _INSERT_SUBSCRIBER_DATA_RESPONSE to the GSM HLR.28
4.4.1.3 Subscriber Data Modification Procedure (GSM Foreign Mode)29If the IIF receives an ANSI_MAP_QUALDIR, it shall follow the VLR procedures described in30ANSI-41 [2].31
As part of the subscriber data modification procedure, the IIF may send either a GSM MAP32_INSERT_SUBSCRIBER_DATA_REQUEST or a GSM MAP33_DELETE_SUBSCRIBER_DATA_REQUEST to the serving GSM VLR and await a response.34
If the response indicates success, the IIF shall modify the corresponding subscriber data and35send an ANSI_MAP_qualdir to the ANSI-41 HLR.36
If the response indicates failure, the received subscriber data is stored by IIF even if there is a37failure reported from the visited (foreign mode) system and the IIF shall send the reason for38failure in the ANSI_MAP_qualdir to the ANSI-41 HLR.39
X.S0023
3-93
4.4.1.4 Subscriber Data Retrieval1If the IIF receives an ANSI_MAP_QUALREQ, it shall follow the ANSI-41 HLR procedures2described in ANSI-41 [2]. The IIF is not required to retrieve subscriber data from the GSM3HLR.4
4.4.2 Mapping of Messages, Parameters & Parameter Values5The IIF shall perform the translation of messages, parameters and parameter values related to6subscriber data management in accordance with the tables presented.7
4.4.2.1 Mapping of Messages8Table 87 shows the mapping between GSM MAP messages and ANSI-41 MAP messages9related to Subscriber Deletion. Table 88 and Table 89, show the mapping between GSM MAP10messages and ANSI-41 MAP messages related to Subscriber Data Modification.11
Table 87: Cancel_Location_Request REGCAN (Subscriber Deletion) Mapping12
GSM MAP Messages ANSI MAP MessagesCANCEL_LOCATION_REQUEST REGCANCANCEL_LOCATION_RESPONSE (Note 1) regcan return resultCANCEL_LOCATION_RESPONSE (Note 2) regcan Return Error
13
Note 1: In the successful case, the CANCEL_LOCATION_RESPONSE is an empty result i.e.14contains no parameters other than the invoke Id.15
Note 2: This message can also contain error values if the subscriber deletion procedure is16unsuccessful. If the subscriber deletion procedure fails, the mapping is as shown. See 4.4.317Error Handling for more information.18
19
Table 88: Mapping of GSM MAP Messages ANSI MAP Messages (Subscriber Data20Modification)21
GSM MAP Messages ANSI MAP MessagesINSERT_SUBSCRIBER_DATA_REQUEST QUALDIR
INSERT_SUBSCRIBER_DATA_RESPONSE qualdir (Note 2)
INSERT_SUBSCRIBER_DATA_RESPONSE(Note 1)
qualdir Return Error
22
X.S0023
3-94
Table 89: Delete_Subscriber_Data Qualdir Mapping (Subscriber Data Modification)1
GSM MAP Messages ANSI MAP MessagesDELETE_SUBSCRIBER_DATA_REQUEST QUALDIR
DELETE_SUBSCRIBER_DATA_RESPONSE qualdir Return Result (Note 2)
DELETE_SUBSCRIBER_DATA_RESPONSE(Note 1)
qualdir Return Error
2
Note 1: These messages can also contain error values if the subscriber data modification3procedure is unsuccessful. If the subscriber data modification procedure fails, the mapping is4as shown. See 4.4.3 Error Hanlding for more information.5
Note 2: The qualdir Return Result is an empty response i.e. contains no parameters other than6the Invoke Id.7
4.4.2.2 Mapping of Parameters8The following tables show the mapping of parameters, which the IIF shall perform regardless of9the mode of operation (GSM Foreign Mode or ANSI-41 Foreign Mode).10
Table 90: CANCEL_LOCATION_REQUEST REGCAN Parameter Mapping11
CANCEL_LOCATION_REQUEST Status REGCAN StatusIMSI M MSID MLMSI C -Cancellation Type C Cancellation Type O
ControlChannelData OReceivedSignalQuality OSenderIdentifcationNumber OSystemAccessData O
12
Note 1: Cancellation Type is only used between the HLR and the SGSN for GPRS procedures.13Cancellation Type is not applicable between HLR and VLR.14
X.S0023
3-95
Table 91: INSERT_SUBSCRIBER_DATA_REQUEST QUALDIR Parameter Mapping1
INSERT_SUBSCRIBER_DATA_REQUEST
Status QUALDIR Status
ElectronicSerialNumber MIMSI CMSID MQualificationInformationCode MSystemMyTypeCode (HLR orVLR)
M
AuthorizationDenied OAuthorizationPeriod ODeniedAuthorizationPeriod ODigits (Carrier) ODigits (Destination) OLocationAreaID OProfile “Macro”1 O
- SenderIdentificationNumber O2
1 This parameter is itself a macro containing a number of other parameters. As far as3mapping of parameters is concerned, the IIF shall map the contents of the ‘Profile’ macro in4the ANSI-41-D ‘QUALDIR Invoke’ to the contents of the GSM MAP5_INSERT_SUBSCRIBER_DATA_REQUEST as shown in Table 92.6
X.S0023
3-96
Table 92: INSERT_SUBSCRIBER_DATA_REQUEST profile ‘macro’ Mapping1
INSERT_SUBSCRIBER_DATA_REQUEST
Status ‘profile’ macro Status
- AuthenticationCapability O
MSISDN C MobileDirectoryNumber OCategory C -Subscriber Status C -Bearer service List C -Teleservice List CForwarding information List C CallingFeaturesIndicator1 O- CarrierDigits O- DMH_AccountCodeDigits O- DMH_AlternateBillingDigits O- DMH_BillingDigits ORegional Subscription Data C -- GeographicAuthorization O- MessageWaitingNotificationCount O- MessageWaitingNotificationType OCall barring information List3 C OriginationIndicator2 OVLR CAMEL Subscription Info4 C OriginationTriggers4 O- PACAIndicator OCUG information List C -SS-Data List C6 CallingFeaturesIndicator1 OEMLPP Subscription Data C -Operator Determined BarringGeneral data
C OriginationIndicator2 O
Operator Determined BarringHPLMN data5
C OriginationIndicator2 O
Operator Determined BarringHPLMN data5
C RestrictionDigits O
Roaming Restriction Due ToUnsupported Feature
C -
- RoutingDigits OCall barring information List3 C SMS_OriginationRestrictions7 OCall barring information List3 C SMS_TerminationRestrictions8 O- SPINIPIN O- SPINITriggers O
X.S0023
3-97
Table 92: INSERT_SUBSCRIBER_DATA_REQUEST profile ‘macro’ Mapping1(concluded)2
INSERT_SUBSCRIBER_DATA_REQUEST
Status ‘profile’ macro Status
Call barring information List3 C TerminationRestrictionCode OVLR CAMEL Subscription Info C TerminationTriggers4 OVoice Broadcast Data CVoice Group Call Data C -- PreferredLanguageIndicator OSS-Data List6 SMS_OriginationRestrictions7 OSS-Data List6 SMS_TerminationRestrictions8 O-GSM BearerServiceCode orGSM TeleService
O CDMAServiceOptionList9 O
31 The CallingFeaturesIndicator parameter provides a status of several ANSI supplementary4
services. This information may map into one or more GSM MAP parameters as shown in5Table 92.6
2 The OriginationIndicator parameter defines the type of calls that a MS is allowed to make.7This information may map into one or more GSM MAP parameters as shown in Table 92.8
3 The Call barring information List is a list of the call barring supplementary services that are9either active, quiescent or not active for individual or all teleservices. This information may10map into one or more ANSI MAP parameters as shown in Table 92.11
4 If this information is received by the IIF it does have to be mapped.125 Operator Determined Barring HPLMN data may map into one or more ANSI MAP13
parameters as shown in Table 92.146 The SS-Data List may map into one or more ANSI MAP parameters as shown in Table 92.157 The SMS_OriginationRestrictions may map into one or more GSM MAP parameters as16
shown in Table 92.178 The SMS_TerminationRestrictions may map into one or more ANSI MAP parameters as18
shown in Table 92.199 The CDMAServiceOptionList may map into one or more GSM MAP parameters (e.g., ADS20
(9.6 kpps) to “CDA-9600 bps” BearerServiceCode; G3FAX to “FacsimileGroup3”21GSMTeleService; PacketDataService (PDS) to “dataPDS” BearerServiceCode).22
X.S0023
3-98
Parameter Value Mapping1
Table 93 through Table 104 shows the mapping of parameter values (more commonly referred2to as ASN.1 data types in GSM 09.02 [4] which the IIF shall perform based on the parameter3mapping shown in Table 92. If there is no direct mapping for parameter values, a ‘-‘ has been4entered in the corresponding table. The implication therefore, is that those services/features5and/or subscription options may not be available when roaming in either a GSM or ANSI-416PLMN.7
The ASN.1 data type encoding is specified in GSM 09.02 [4].8
Table 93: Forwarding Information List to Calling Features Indicator Parameter Mapping9
GSM_Forwarding Information List ANSI-41_Calling Features IndicatorSSCode
AllForwardingSS
CFU
AllConditionalForwardingSS
CFB
CFNRy
CFNRc
CD
FeatureActivityStatus
CFU + CFNA +CFB
CFU
CFNA +CFB
CFB
CFNA1
CFNA1
-BasicService2
Refer to GSM 09.02 [4] for Basic ServiceCodes
-
SSStatus
Q P R A3
0 0 0 00 0 0 14
0 0 1 04
0 0 1 14
0 1 0 00 1 0 14
0 1 1 00 1 1 11 0 0 04
1 0 0 14
1 0 1 04
1 0 1 14
1 1 0 04
1 1 0 14
1 1 1 04
1 1 1 1
FeatureActivityStatus
Not authorized---Authorized but de-activated-Authorized but de-activatedAuthorized and activated-------Authorized and activated
X.S0023
3-99
Table 93: Forwarding Information List to Calling Features Indicator Parameter Mapping1(concluded)2
GSM_Forwarding Information List ANSI-41_Calling Features IndicatorForwardedToNumber
E164 Address
-
ForwardedToSubaddress
E164 Address
-
ForwardingOptions
Notification to forwarding party
Notification to calling party
Forwarding reason
-
NoReplyConditionTime -3
1 The ANSI-41 CFNA value maps to both GSM values CFNRc and CFNRy.42 GSM allows call forwarding services to be operated on a per basic service group basis.5
ANSI-41 on the other hand has no concept of basic service groups. Therefore, one or more6GSM basic services or basic service groups shall map to all basic services in ANSI-41.7
3 The QPRA bits, refer to the Quiescent, Provisioned, Registered & Activation status of the8various call forwarding services e.g. QPRA = 0110 means that the status of that call9forwarding service is not quiescent, provisioned, registered, not active.10
4 These combinations are not applicable to GSM Call Forwarding services.11
X.S0023
3-100
Table 94: Regional Subscription Data to Geographic Authorization Parameter Mapping1
GSM_Regional Subscription Data ANSI-41_Geographic Authorization
ZoneCode
See GSM 09.02 [4] for definition of zonecode1
GeographicAuthorization
Authorized for all MarketIDs served by theVLR
Authorized for this MarketID only
Authorized for this MarketID and SwitchNoonly
Authorized for this locationAreaID within aMarketID only
21Based on the zone code, which identifies those regions or zones where a roaming is allowed,3these values may map to one or more values in the Geographic Authorization.4
X.S0023
3-101
Table 95: Call Barring Information List to Origination Indicator Parameter Mapping1
GSM_Call Barring Information List ANSI-41_Origination IndicatorSSCode
See Note (a)
AllBarringSS1
BarringOfOutgoingCalls1
BAOC1
BOIC2
BOIC-exHC2
BAOC
BAOC, BOIC, BOIC-exHC
Allowed Call Types
Prior Agreement
Orignation denied
Origination denied
Origination denied3
National long distance4
National long distance
Local calls only5
Selected leading digits of directory or ofinternational E.164 number6
BAOC,BOIC, BOIC-exHC
-
-
BarringOfIncomingCalls
BAIC
BIC-Roam
BAOC
Selected leading digits of directory numberor of international E.164 number and localcalls6
International calls
Single Directory number or internationalE.164 number
-
-
-
-
BasicService
See GSM 09.02 [4] for Basic Servicecodes
-
SSStatusQ P R A
See GSM 09.02 [4] for SSStatus values
-
2
X.S0023
3-102
Note (a): If the origination indicator value received indicates ‘prior agreement’ this may map into1one or more GSM SS Codes depending on the agreement between roaming partners.21,2 If the IIF receives any of these GSM SSCodes, they shall map to the same ANSI-413
allowed call type as shown in Table 95.43 If the IIF receives the ANSI-41 allowed call type set to ‘origination denied’, this shall be5
mapped as shown in Table 95.64 If the IIF receives the ANSI-41 allowed call type set to ‘national long distance’, this shall be7
mapped as shown in Table 95.85 If the IIF receives the ANSI-41 allowed call type set to ‘local calls only’ this shall be mapped9
as shown in Table 95.106 If the IIF receives the ANSI-41 allowed call type as shown, this may be mapped to one or11
more GSM SSCode values as shown in Table 95.12
X.S0023
3-103
Table 96: SSData List to Calling Features Indicator Parameter Mapping1
GSM_SSData List ANSI-41_Calling Features IndicatorSSCode
CW + CH
-
-
-
MPTY
Note (a)
CLIR
CLIP
CLIP
-
COLP
COLR
CNAP
ECT
CCBS-A
CCBS-B
AoCI
AoCC
UUS
PLMNSpecific
FeatureActivityStatus
CW
CT
VP
CD
3WC
CNIROver
CNIR
CNIP2
CNIP1
PCW
-
-
-
-
-
-
-
-
-
-BasicService1
See GSM 09.02 [4] for Basic Servicecodes
-
2
X.S0023
3-104
1
Table 96: SSData List to Calling Features Indicator Parameter Mapping (concluded)2
GSM_SSData List ANSI-41_Calling Features IndicatorSSStatus(need to map to SMSMo & MTRestriction in ANSI)
Q P R A
0 0 0 00 0 0 12
0 0 1 02
0 0 1 12
0 1 0 00 1 0 10 1 1 02
0 1 1 11 0 0 02
1 0 0 12
1 0 1 02
1 0 1 12
1 1 0 02
1 1 0 12
1 1 1 02
1 1 1 12
FeatureActivityStatus
Not authorized---Authorized but de-activatedAuthorized and activated-Authorized and activated--------
CLIRestrictionOption3
PermanentTemporaryDefaultRestrictedTemporaryDefaultAllowed
Feature Activity Status-Authorized and activatedAuthorized and deactivated
OverrideCategory4
OverrideEnabledOverrideDisabled
Feature Activity StatusAuthorized and activatedAuthorized and deactivated
3
Note (a): There is no equivalent GSM SSCode value for CNIROver. The override restriction4capability in GSM is a subscription option whose value is reflected by the OverrideCategory51 GSM allows supplementary services to be operated on a per basic service group basis.6
ANSI-41 on the other hand has no concept of basic service groups. Therefore, one or7more GSM basic services or basic service groups shall map to all basic services in8ANSI-41.9
2 These combinations are not applicable to the GSM supplementary services defined by their10SSCode in Table 9611
X.S0023
3-105
3 The CLIRestriction option is equivalent to the ANSI-41 Feature Activity Status, CNIR. If the1CLIRestriction is temporary default restricted, this equates to the value ‘Authorized and2activated’ in the CNIR feature activity status. If the CLIRestriction is temporary default3allowed, this equates to the value ‘Authorized but deactivated’ in the CNIR feature activity4status. There is no equivalent in ANSI-41 to permanently restricted.5
4 The GSM override category is equivalent to the ANSI-41 Feature Activity Status,6CNIROver. If the Override Category is enabled, this equates to the value ‘Authorized and7activated’ in the CNIROver feature activity status. If the Override Category is disabled, this8equates to the value ‘Authorized but deactivated’ in the CNIROver feature activity status.9
Table 97: Operator Determined Barring general data to Origination Indicator10Parameter Mapping11
GSM_Operator determined barring (general) ANSI-41_Origination Indicator
ODB-General data
AllOG-callsBarred
InternationalOGCalls Barred1
InternationalOGCallsNotToHPLMN-CountryBarred1
InterzonalOGCallsBarred1
InterzonalOGCallsNotToHPLMN-CountryBarred1
InterzonalandInternationalOGCallsNotToHPLMN-CountryBarred1
PremiumRateInformationOGCallsBarred1
PremiumRateEntertainmentOGCallsBarred1
Allowed Call Types
Origination denied
National long distance2
National long distance
Selected leading digits of directorynumber or of international E.164number and local calls
Selected leading digits of directorynumber or of international E.164number and local calls
Selected leading digits of directorynumber or of international E.164number and local calls
Selected leading digits of directorynumber or of international E.164number and local calls
Selected leading digits of directorynumber or of international E.164number and local calls
12
X.S0023
3-106
Table 97: Operator Determined Barring general data to Origination Indicator1Parameter Mapping (concluded)2
GSM_Operator determined barring (general) ANSI-41_Origination IndicatorSSAccessBarred
AllECTBarred
ChargeableECTBarred
InternationalECTBarred
InterzonalECTBarred
DoublyChargedECTBarred
MultipleECTBarred
-
-
-
-
-
-
3
Note: The mapping shown in Table 97 applies in one direction only i.e. from GSM to ANSI-41.4The corresponding ANSI-41 values received by the IIF in “profile” macro parameter, it shall be5mapped according to Table 95.61If the IIF receives any of these GSM ODB general data, they shall map to the same ANSI-417allowed call type as shown in Table 97.8
9
Table 98: Operator Determined Barring HPLMN data to Origination Indicator Parameter10Mapping11
GSM_Operator determined barring(HPLMN)
ANSI-41_Origination Indicator
ODB-HPLMN data
PLMN-SpecificBarringType1
Allowed Call Types
-12
Table 99: Operator Determined Barring HPLMN data to Restriction digits Parameter13Mapping14
GSM_Operator determined barring(HPLMN)
ANSI-41_Restriction Digits
ODB-HPLMN data
PLMN-SpecificBarringType1
Type of Number
-
X.S0023
3-107
Table 100: Call Barring Information List to SMS Origination Restrictions Parameter1Mapping2
GSM_Call Barring Information List ANSI-41_SMS Origination Restrictions
SSCode
AllBarringSS
BarringOfOutgoingCalls
BAOC
-
-
BOIC
BOIC-exHC
BAOC
BarringOfIncomingCalls
BAIC
BIC-Roam
-
-
-
-
-
Default
-
-
Block All
Allow Specific
Allow All
-
-
-
-
-
-
Direct
Block Direct
Allow Direct
ForceMessageCenter
Force Indirect
3
X.S0023
3-108
1
Table 100: Call Barring Information List to SMS Origination Restrictions Parameter2Mapping (concluded)3
GSM_Call Barring Information List ANSI-41_SMS Origination RestrictionsBasicServiceSee GSM 09.02 [4] for Basic Servicecodes
-
SSStatusQ P R ASee GSM 09.02 [4] for SSStatus values
-
4
Table 101: Call Barring Information List to SMS Termination Restrictions Parameter5Mapping6
GSM_Call Barring Information List ANSI-41_SMS Termination RestrictionsSSCodeAllBarringSSBarringOfOutgoingCallsBAOC--BOICBOIC-exHCBAOCBarringOfIncomingCallsBAICBIC-Roam---
Default--Block AllAllow SpecificAllow All------Reserve ChargesBlock DirectAllow Direct
BasicServiceSee GSM 09.02 [4] for Basic Servicecodes
-
SSStatusQ P R ASee GSM 09.02 [4] for SSStatus values
-
7
X.S0023
3-109
Table 102: Call Barring Information List to Termination Restriction Code Parameter1Mapping2
GSM_Call Barring Information List ANSI-41_Termination Restriction Code
SSCodeAllBarringSSBarringOfOutgoingCallsBAOCBOICBOIC-exHCBAOCBarringOfIncomingCallsBAICBIC-Roam-
Termination RC-------Termination denied-Unrestricted
BasicServiceSee GSM 09.02 [4] for Basic Servicecodes
-
SSStatusQ P R ASee GSM 09.02 [4] for SSStatus values
-
3
X.S0023
3-110
Table 103: SSData List to SMS Origination Restrictions Parameter Mapping1
GSM_SSData List ANSI-41 SMS Origination Restrictions
SSCodeSee GSM 09.02 [4] for SS Codes
-
BasicServiceSee GSM 09.02 [4] for complete list ofBasic Services
DefaultBlock All1
SSStatus -
CLIRestrictionOption -
OverrideCategory -2
1In the case where the BasicService does not indicate that SMS is available, this shall be mapped to3‘Block All’.4
Table 104: SSData List to SMS Termination Restrictions Parameter Mapping5
GSM_SSData List ANSI-41 SMS Termination Restrictions
SSCodeSee GSM 09.02 [4] for SS Codes
-
BasicServiceSee GSM 09.02 [4] for complete list ofBasic Services
DefaultBlock All1
SSStatus -
CLIRestrictionOption -
OverrideCategory -1In the case where the BasicService does not indicate that SMS is available, this shall be mapped to6‘Block All’.7
X.S0023
3-111
4.4.3 Error Handling1Error handling defined in GSM 09.02 [4] and ANSI-41 [2] is directly applicable to the IIF, when2the IIF is emulating a GSM or ANSI-41 network functional element.3
Subscriber Deletion4
If the Subscriber Deletion procedure fails at an ANSI-41 VLR, the VLR shall respond by either5sending:6
7An ANSI_MAP_regcan in a TCAP RETURN RESULT indicating cancellation denied (CANDEN)8to the IIF, with one of the following reasons as defined in ANSI-41 [2]9
Appropriate CANDEN Values in ANSI_MAP_regcan RETURN RESULT10
CANDEN Value
Multiple access
Busy
11
The ANSI_MAP regcan may optionally indicate:12
• CallHistoryCount13
• ControlChannelData14
• ReceivedSignalQuality15
• SMS_MessageWaitingIndicator16
• SystemAccessData17
as defined in ANSI-41 [2]18
Or, an ANSI_MAP regcan in a TCAP RETURN ERROR one of the following error codes as19defined in ANSI-41 [2]:20
Appropriate Error Codes in ANSI_MAP_regcan RETURN ERROR21
Error Codes
UnrecognizedESN
OperationSequenceProblem
ResourceShortage
OperationNotSupported
ParameterError
SystemFailure
22
The IIF is therefore responsible for mapping any errors it receives from the ANSI-41 VLR in the23ANSI_MAP regcan to an equivalent error in the GSM MAP24_CANCEL_LOCATION_RESPONSE towards the GSM HLR.25
X.S0023
3-112
1
The GSM MAP _CANCEL_LOCATION_RESPONSE may include one the following ‘user’2errors as defined in GSM 09.02 [4]:3
Appropriate User Errors4
User Errors
unexpected datavalue;
data missing;
5
The following ‘provider errors’ (protocol related errors) are also defined in GSM 09.02 [4]:6
Appropriate Provider Errors7
Provider Errors
duplicated invoke Id;
not supported service;
mistyped parameter;
resource limitation;
initiating release (i.e., the peer hasalready 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.
8
If the Subscriber Deletion procedure fails at a GSM VLR, it returns a GSM MAP9_CANCEL_LOCATION_RESPONSE to the IIF, indicating an ‘user error’ as indicated above. The10IIF is therefore responsible for mapping any errors it receives into a corresponding error in the11ANSI_MAP regcan towards the ANSI-41 HLR. For further description of these errors and when12they are used, refer to either GSM 09.02 [4] or ANSI-41 [2].13
The Location Registration provides the mapping of both user errors and provider errors in the14GSM MAP _CANCEL_LOCATION_RESPONSE to the equivalent value in either the CANDEN15parameter in the ANSI_MAP regcan RETURN RESULT or the RETURN ERROR.16
17
X.S0023
3-113
Subscriber Data Modification1
If the Subscriber Data Modification procedure fails at an ANSI-41 VLR, the VLR shall respond2by sending:-3
4An ANSI_MAP qualdir in a TCAP RETURN ERROR with one of the following reasons as5defined in ANSI-41 [2]:6
Appropriate Provider Errors7
Provider Errors
duplicated invoke Id;
not supported service;
mistyped parameter;
resource limitation;
initiating release (i.e., the peer hasalready 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.
8
The IIF is therefore responsible for mapping any errors it receives from the ANSI-41 VLR in the9ANSI_MAP qualdir to an equivalent error in the GSM MAP10_INSERT_SUBSCRIBER_DATA_RESPONSE or the GSM MAP11_DELETE_SUSBCRIBER_DATA_RESPONSE towards the GSM HLR.12
13
The GSM MAP _INSERT_SUBSCRIBER_DATA_RESPONSE and the GSM14MAP_DELETE_SUBSCRIBER_DATA RESPONSE may include one the following ‘user’ errors15as defined in GSM 09.02 [4]:16
Appropriate User Errors17
User Errors
unidentifiedsubscriber;
data missing;
unexpected datavalue.
18
X.S0023
3-114
The following ‘provider errors’ are also defined in GSM 09.02 [4]:1
Appropriate Provider Errors2
Provider Errors
duplicated invoke Id;
not supported service;
mistyped parameter;
resource limitation;
initiating release (i.e. the peer hasalready initiated release of the
dialogue and the service has to bereleased);
unexpected response from thepeer;
service completion failure;
no response from the peer;
invalid response received.
3
If the Subscriber Data Modification procedure fails at a GSM VLR, it returns either a GSM MAP4_INSERT_SUBSCRIBER_DATA_RESPONSE or a GSM MAP5_DELETE_SUBSCRIBER_DATA_RESPONSE to the IIF, indicating a ‘user error’ as indicated6above. The IIF is therefore responsible for mapping any errors it receives into a corresponding7error in the ANSI_MAP qualdir towards the ANSI-41 HLR. For further description of these8errors and when they are used, refer to either GSM 09.02 [4] or ANSI-41 [2].9
Table 105 below provides the mapping of both user errors and provider errors in the GSM MAP10_INSERT_SUBSCRIBER_DATA_RESPONSE and GSM MAP11_DELETE_SUBSCRIBER_DATA_RESPONSE to the equivalent value in the ANSI_MAP12qualdir RETURN ERROR for ANSI-41 Foreign mode. Table 106 provides the mapping for GSM13Foreign mode.14
X.S0023
3-115
Table 105: ISD_RESPONSE and DSD_RESPONSE to Qualdir Return Error Mapping1
INSERT/DELETE_SUBSCRIBER_DATA_RESPONSE (Errors)
Qualdir Return Error
Unidentified subscriber Unrecognized MSIDData missing SystemFailureUnexpected data value SystemFailureDuplicated Invoke Id SystemFailureNot supported service SystemFailureMistyped parameter SystemFailureResource limitation SystemFailureInitiating release SystemFailureUnexpected response from the peer SystemFailureService completion failure SystemFailureNo response from the peer SystemFailureInvalid response received SystemFailure
2
Table 106: Qualdir Return Error to INSERT_SUBSCRIBER_DATA_RESPONSE and3DELETE_SUSBCRIBER_DATA_RESPONSE Error Mapping4
Qualdir Return Error INSERT/DELETE_SUBSCRIBER_DATA_RESPONSE (Errors)
Unrecognized MSID Unidentified subscriberUnrecognized ESN Unexpected data valueResourceShortage Unexpected data valueOperationNotSupported Unexpected data valueParameterError Unexpected data valueSystemFailure Unexpected data valueUnrecognizedParameterValue Unexpected data valueMissing Parameter Data Missing
5
6
X.S0023
3-116
1
4.5 Short Message Procedures (ANSI-41 Network)2
3
Existing mobility procedures described in either GSM 09.02 [4] or ANSI-41 [2] are also directly4applicable to the IIF when it is emulating a GSM or ANSI-41 functional network element.5
6
4.5.1 Short Message Service via CMT78
The Short Message Service procedure is used to deliver short text messages to and from9mobile subscribers.10
11
4.5.1.1 Detailed Procedures1213
The following procedures are applicable at the IIF for Short Message Service. Mobile14Terminating SMS and Mobile Originated SMS using the CMT teleservice ID are described in154.5.1.1.16
17
4.5.1.1.1 Mobile Terminating SMS in GSM foreign mode1819
If the IIF receives an ANSI-41 Short Message Delivery Point to Point message from the home20Message Center, it shall check if the subscriber location is known and if the subscriber is active.21If both conditions are true, the IIF shall format and send a GSM_22MAP_FORWARD_SHORT_MESSAGE to the GSM MSC/VLR serving the mobile. Refer to23Table 109 for the mapping of parameters from ANSI_SMDPP to GSM MAP24_FORWARD_SHORT_MESSAGE.25
If a successful response is received for the FSM, the IIF shall send a SMDPP Return Result26message to the home Message Center27
If the subscriber’s location is not known, or if the subscriber is inactive or if the response to the28FSM indicates the short message was not delivered to the mobile, the IIF shall set the SMS29Delivery Pending flag for the subscriber. The IIF shall then send an SMDPP Return Result30message with an appropriate SMS_CauseCode value to the home MC. Refer to 4.5.1.3 Error31Handling for the values of SMS_CauseCode returned.32
If errors are detected when the SMDPP is received, the message may be rejected if it cannot33be processed or if mandatory parameters are missing. Otherwise, the IIF shall send an SMDPP34Return Result message with the appropriate SMS_CauseCode value. Refer to 4.5.1.3 Error35Handling for the description of error conditions and corresponding SMS_CauseCode values.36
X.S0023
3-117
If the response to FSM indicates a failure in the delivery of the short message, the IIF shall map1the cause value received to a corresponding SMS_CauseCode value in the SMDPP Return2Result, as described in Table 116.3
If the response to FSM indicates that the receiving entity does not support MAP V2, the GSM4MAP_FORWARD_SHORT_MESSAGE is formatted in MAP V1 and sent again to the serving5MSC/VLR.6
4.5.1.1.2 Alerting in GSM Foreign Mode78
If the IIF receives a GSM MAP _READY_FOR-SHORT_MESSAGE (MAP V2) or a9GSM_UPDATE_LOCATION message, or a GSM MAP _NOTE_MS_PRESENT message (MAP10V1) and the Delivery pending flag is set for the subscriber, the IIF shall send an11ANSI_MAP_SMS_NOTIFICATION message to the home Message Center. The flag shall then12be cleared. The home MC shall re-send message SMDPP to deliver the short message to the13subscriber as described previously.14
4.5.1.1.3 Mobile Terminating SMS in ANSI-41 Foreign Mode1516
If the IIF receives a GSM_FORWARD_SHORT_MESSAGE, it shall format and send an17ANSI_MAP Short Message Delivery Point to Point message to the serving TDMA MSC/VLR.18Refer to Table 110, Table 111 and Table 112 for the mapping of parameters from GSM MAP19_FORWARD_SHORT_MESSAGE to ANSI_SMDPP.20
If the IIF receives a positive acknowledgment to the SMDPP message, it shall send a positive21acknowledgment to the Forward Short Message.22
If the IIF receives a negative acknowledgment to the SMDPP message, it shall set the Mobile23Not Reachable flag for the subscriber and shall map the received SMS_CauseCode value into24a corresponding error code in the FSM Response message as described in Table 117.25
If the IIF detects errors in the FORWARD_SHORT_MESSAGE, an error indication is sent in the26response message. This shall cause the GSM MSC/VLR to send an error indication to the GSM27HLR. Refer to 4.5.1.3 Error Handling for error detection on reception of FSM.28
If a Return Error or Reject is received in response to the ANSI_MAP_SMSDPP INVOKE, the29error code is mapped into the corresponding Forward Short Message error code as described30in Table 117.31
4.5.1.1.4 Alerting in ANSI--41 Foreign Mode3233
If the IIF receives an ANSI_MAP Registration Notification message or an ANSI_MAP SMS34Notification message, and the SMS Delivery Pending flag is set for a mobile subscriber, it shall35send a GSM MAP _READY_FOR-SHORT_MESSAGE (MAP V2) or a GSM MAP36_NOTE_MS_PRESENT message (MAP V1) to the GSM HLR. This shall cause the HLR to37send an indication to the GSM SMSC that shall trigger the re-sending of the Short message.38
X.S0023
3-118
4.5.1.1.5 Mobile Originating SMS in GSM Foreign Mode12
If the IIF receives a GSM_FORWARD_SHORT_MESSAGE for a mobile originated short3message, it shall format and send an ANSI_MAP_SMDPP message to the serving ANSI-414Message Center. Refer to Table 114 for the mapping of parameters from GSM MAP5_FORWARD_SHORT_MESSAGE to ANSI_SMDPP.6
If the IIF receives a positive acknowledgment to the SMDPP message, it shall send a positive7acknowledgment to the Forward Short Message.8
If the IIF receives a negative acknowledgment to the SMDPP message, it shall map the9received SMS_CauseCode value into a corresponding error code in the FSM Response10message as described in Table 11711
If the IIF detects errors in the FORWARD_SHORT_MESSAGE, an error indication is sent in the12response message. Refer to 4.5.1.3 for the handling of errors at the reception of FSM.13
4.5.1.1.6 Mobile Originating SMS in ANSI-41 Foreign Mode1415
If the IIF receives an ANSI-SMDPP message from the Serving MSC, it shall format and send a16GSM MAP_FORWARD_SHORT_MESSAGE to the GSM Message Center of the subscriber.17Refer to Table 115 for the mapping of parameters from ANSI_SMDPP to GSM MAP18_FORWARD_SHORT_MESSAGE.19
If a successful response is received for the FSM, the IIF shall send a SMDPP Return Result20message to the MSC/VLR.21
If errors are detected when the SMDPP is received, the message may be rejected if it cannot22be processed or if mandatory parameters are missing. Otherwise, the IIF shall send an SMDPP23Return Result message with the appropriate SMS_CauseCode value. Refer to 4.5.1.3 Error24Handling for the description of error conditions and corresponding SMS_CauseCode values.25
If the response to FSM indicates that the receiving entity does not support MAP V2, the GSM26MAP_FORWARD_SHORT_MESSAGE is formatted in MAP V1 and sent again to the serving27MSC/VLR.28
X.S0023
3-119
4.5.1.2 Mapping of Messages, Parameters & Parameter Values12
4.5.1.2.1 Mapping of Messages34
The IIF shall perform the mapping of messages, parameters and parameter values related to5Short Message Service in accordance with the tables presented.6
Table 107 shows the mapping between ANSI MAP messages and GSM MAP messages7related to Short Message Service in GSM Foreign Mode. Table 108 shows the mapping8between GSM MAP messages and ANSI MAP messages related to Short Message Service in9ANSI-41 Foreign Mode.10
Table 107: Short Message Service in GSM Foreign Mode (for CMT) Message Mapping11
ANSI MAP Messages GSM MAP Messages
SMDPP FORWARD_SHORT_MESSAGE
12
Table 108: Short Message Service in ANSI-41 Foreign Mode (for CMT) Message Mapping13
GSM MAP Messages ANSI MAP Messages
FORWARD_SHORT_MESSAGE SMDPP
X.S0023
3-120
4.5.1.2.2 Mapping of Parameters1Table 109 through Table 115 show the mapping of parameters, which the IIF shall perform.2
Table 109: SMDPP to MT_Forward Short Message Parameter Mapping for GSM Foreign3Mode4
ANSI SMDPP Status GSM MT FSM StatusMSID O
Note 1SMS_OriginalDestinationAddress (= MSID)
ONote 1
SM-RP-DA = IMSI M
SMS-Originating-Address (= MCAddress)
O SM-RP-OA = IIF address ininternational format. See 4.5.2.4
M
User Data Unit (inSMS_Bearer_Data)
M SM-RP-UISee Table 111 and Table 112 fordetails of encoding of thisparameter.
M
- More Messages to Send = no MNote 2
5Note 1: MSID and SMS_Original_Destination_Address should be the same.6
Note 2: This parameter is only valid for MAP V2.7
Table 110: MT_Forward Short Message to SMDPP Parameter Mapping for ANSI-418Foreign Mode9
GSM MT FSM Status ANSI SMDPP StatusMSID RSM-RP-DA= IMSI MESN O
SM-RP-UI M SMS Bearer Data SeeTable 113 for encoding of thisparameter.
M
- SMS Teleservice Identifier set tovalue (= CMT)
M
SM-RP-OA (=SMS-SC Address) M SMSOriginating Address (= IIFAddress) See 4.5.2.4
R
10
The IIF shall support the mapping of parameters in Forward Short Message in both MAP V111and MAP V2. Encoding of parameter SM-RP-UI is different depending on the MAP version12being encoded in the message. The two following tables describe the coding for each version13of MAP.14
X.S0023
3-121
1
Table 111 describes the setting of field values for parameter SM-RP-UI for MAP V2.2
Table 111: SM-RP-UI in MT_FORWARD_SHORT_MESSAGE for MAP V2 Parameter Values3for GSM Foreign Mode4
FIELD VALUEMessage Type Indicator Set to value “SMS-DELIVER”More Messages to Send Set to value “No more messages are waiting for the MS
in this SC”Reply Path Set to value “TP-Reply-Path is not set in this SMS-
DELIVER”Status Report Indication Set to value “A status report is not requested”Protocol Identifier Set to value “0”Service Center Time Stamp Created by the IIFUser Data Length Number of charactersUser Data If TDMA CMT, the IS-136 SMS message (parameter
User Data) converted to the GSM default alphabet,unless it is sent as an 8-bit data. Truncate messagelength if longer than 134 octets (152 characters).IIf CDMA CMT, the IS-95 SMS message (parameterUser Data) converted to the GSM default alphabet,unless it is sent as an 8-bit data. Truncate messagelength if longer than 134 octets (152 characters) (onlyMAP V2). Truncate message length if longer than 134octets (152 characters) for MAP V2 (160 characters forMAP V1).
Originating Address The address of the original SME. Use the value receivedin parameter SMS Original Originating Address inSMDPP.
Data Coding Scheme - Set bit numbers 7, 6, 5, 4 to data coding (value 1111).Set bit number 3 to 0.
- Set bit 2 to value default alphabet if receivedparameter Encoder Identifier has value “IRA” or “Latin-1, otherwise set to value “8-bit”.- Set bit numbers 1&0 to value “Class 0” if receivedparameter Urgency Indicator has value “Very Urgent”,otherwise set to value “Class 1”.
5
X.S0023
3-122
The following table describes the setting of field values for parameter SM-RP-UI for MAP V1.1
Table 112: SM-RP-UI in MT_FORWARD_SHORT_MESSAGE for MAP V1 Parameter2Encoding for GSM Foreign Mode3
FIELD VALUEMessage Type Indicator Set to value “SMS-DELIVER”More Messages to Send Set to value “No more messages are waiting for the MS
in this SC”Protocol Identifier Set to value “0”Service Center Time Stamp Created by the IIFUser Data Length Number of charactersUser DataOriginating Address The address of the original SME. Use the value received
in parameter SMS Original Originating Address inSMDPP.
Data Coding Scheme Use the coding value “default alphabet”
4
X.S0023
3-123
Table 113: SMS_Bearer Data in Mobile Terminating SMDPP Parameter Encoding for1ANSI-41 Foreign Mode2
FIELD VALUEMessage type indicator (M) 000 “SMS Deliver”Message Reference (M) created by IIFPrivacy Indicator (M) 000 “Not restricted”Urgency Indicator (M) 11 “Very urgent” if class 0 coded in the TP-DCS received,
01 “Normal” otherwise.Delivery ack request (M) Set to value “Delivery acknowledge prohibited”Manual ack request (M) Set to value “Manual acknowledge prohibited”Message Updating (M) 1 “new”Validity (M) 000 “indefinite”Display time (M) 01 “Default”User Data Unit (M) Encoding Identifier: 00001 “IRA”
Length Modifier: 0User Data Structure Type: 00User Data: GSM User Data from SM-RP-UI translated tothe IS-136 IRA alphabetIf CDMA CMT:
Encoding Identifier: possible values areunspecified, IS-91 EPM, 7-bit ASCII, and IA5
MSG_ENCODING: Set to 7-bit ASCII if receivedmessage is in GSM default alphabet, otherwise set toOctet, unspecified.
MST:omitted
NUM_FIELDS: Number of characters
CHARi: GSM SMS message. If encoding identifierhas value 7-bit ASCII (ANSI X3.4), translate GSMSMS message to the 7-bit ASCII alphabet.
3
X.S0023
3-124
1
Table 114: Forward_Short_Message to ANSI-41_SMDPP Parameter Mapping for MO SMS2in GSM Foreign Mode3
GSM Forward Short Message Status ANSI SMDPP StatusNote 1 ESN ONote 1 MSID O
SMS Teleservice ID = CMT MSMS_Originating Address (=IIFAddress)
O
SM-RP-OA (A-MSISDN) MNote 1
SMS_Original OriginatingAddress (= A-MSID)
R
SMS_OriginalDestinationAddress SubAddress (not sent)
O
SM-RP-UI: TP-Destinationaddress (B-MSISDN)
M SMS_Original DestinationAddress
R
SMS_Original OriginatingAddress Sub Address (not sent)
O
SMS_Charge Indicator (not sent) OSMS_Message Count (not sent) OSMS_Notification Indicator (notsent)
O
SM-RP-DA (IIF Address) M SMS_Destination Address (= MCaddress retrieved from mappingin database) See 4.5.2.4
R
SM-RP-UITP-Message-Type-IndicatorTP-Reject-Duplicates (ignored)TP-Validity-PeriodTP-Validity-Period-FormatTP-Reply-Path (ignored)TP-User-Data-Header-Indicator(ignored)TP-Status-Report-Request(ignored)TP-Message-ReferenceTP-Protocol-Identifier (ignored)TP-Data-Coding-SchemeTP-User-Data-Length
M SMS Bearer DataTP-Message-Type-Indicator
TP-Validity-Period
TP-Delivery-Ack-Request(=prohibit)
TP-Message-Reference
TP-Urgent-Indicator TP-User-Data-Unit
M
4
X.S0023
3-125
Table 114: Forward_Short_Message to ANSI-41_SMDPP Parameter Mapping for MO SMS1in GSM Foreign Mode (concluded)2
GSM Forward Short Message Status ANSI SMDPP StatusTP-User-Data
TP-Privacy_indicator (=notrestricted)TP-Manual-Ack-Request(=prohibit)TP-Message-Updating (=do notoverwrite)TP-Deferred-Delivery-Time (=notset)TP-Call-Back-Number (=not set)TP-Call-Back-Number-Presentation-Indicator (=not set)TP-Call-Back-Number-Alpha-Tag(=not set)TP-Multilingual-Call-Back-Number (=not set)TP-Multilingual-Call-Back-Number-Alpha (=not set)TP-Multilingual-Destination-Address (=not set)
3
Note 1: MSID and ESN are supplied based on MSISDN received in SM-RP-OA4
5
X.S0023
3-126
Table 115: ANSI-41 SMDPP to GSM Forward_Short_Message Parameter Mapping for MO1SMS in ANSI-41 Foreign Mode2
ANSI SMDPP Status GSM Forward Short Message StatusSMS Teleservice ID M -ESN O -MSID O -SMS_Charge Indicator O -SMS_Message Count O -SMS_Notification Indicator O -SMS_Destination Address (IIFAddress)
O SM-RP-DA: SC Address(retrieved from mapping in IIFdatabase) see 4.5.2.4
M
SMS_Original DestinationAddress (B-MSISDN)
O TP_Destination-Address withinSM-RP-UI
M
SMS_Original Destination SubAddress
O -
SMS_Originating Address O -SMS_Original OriginatingAddress (A-MSID)
O SM-RP-OA: A-MSISDN M
SMS_Original Originating SubAddress
O -
SMS Bearer Data- TP-Message-Type-
Indicator-
- TP-Validity-Period--
- -
- TP-Message-Reference-
- TP-User-Data-Unit TP-Urgent-Indicator
- TP-Delivery-Ack-Request(ignored)
M SM-RP-UI- TP-Message-Type-
Indicator- TP-Reject-Duplicates=TRUE
- TP-Validity-Period- TP-Validity-Period-Format- TP-Reply-Path = NOT-SETTP-User-Data-Header-Indicator=NO-HEADER- TP-Status-Report-Request=NO- TP-Message-Reference- TP-Protocol-Identifier = 0- TP-Data-Coding-Scheme TP-User-Data-Length TP-User-Data
M
3
X.S0023
3-127
1Table 115: ANSI-41 SMDPP to GSM Forward_Short_Message Parameter Mapping for MO2SMS in ANSI-41 Foreign Mode (concluded)3
ANSI SMDPP Status GSM Forward Short Message Status- TP-Privacy_Indicator
(ignored)- TP-Manual-Ack-Request
(ignored)- TP-Message-Updating
(ignored)- TP-Deferred-Delivery-
Time (ignored)- TP-Call-Back-Number
(ignored)- TP-Call-Back-Number-
Presentation-Indicator(ignored)
- TP-Call-Back-Number-Alpha-Tag (ignored)
- TP-Multilingual-Call-Back-Number (ignored)
- TP-Multilingual-Call-Back-Number-Alpha(ignored)
TP-Multilingual-Destination-Address (ignored)
- User DataMSG_ENCODING: ForCDMA, possible values areunspecified, IS-91 EPM, 7-bitASCII, and IA5.
MST:Message type IS-95or IS-136 is usedNUM_FIELDS: Numberof characters. Messagesabove GSM limit will betruncated.
CHARi: IS-95 or IS-136SMS message itself
\
X.S0023
3-128
1
4.5.1.3 Error Handling23
Error handling at the reception of a Forward Short Message in the IIF4
5
1. If a mandatory parameter is missing (MAP V2), a Forward Short Message Response6with the indication “Data Missing” is sent back to the SMS-GMSC.7
2. If a mandatory parameter is missing (MAP V1), a Forward Short Message Response8with the indication “Mistyped Parameter” is sent back to the SMS-GMSC.9
3. A Forward Short Message Response with the problem code “Mistyped Parameter” is10sent in the following cases:11
• A parameter tag is not one of those associated with the operation.12
• The received value is not a value of the type associated with the operation.13
• Erroneous tag and length information.14
• Exceeding of the defined size of an ASN.1 module.15
4. If the SM-RP-DA parameter does not have an IMSI number, a Forward Short Message16Response with the indication “Unexpected Data Value” is sent back to the SMS-GMSC.17
5. If the SM-RP-OA parameter does not have a SC, a Forward Short Message Response18with the indication “Unexpected Data Value” is sent back to the SMS-GMSC.19
6. If the subscriber is not connected in the IIF or if the profile is not available, Forward20Short Message Response with the indication “Unidentified Subscriber” is sent back to21the SMS-GMSC.22
7. If location is unknown or inactive, send back to the SMS-GMSC a Forward Short23Message Response message with the indication “Absent Subscriber”.24
8. If the subscriber has an ANSI SMS termination restriction, a Forward Short Message25Response message with indication “Facility Not Supported” is sent back to the SMS-26GMSC.27
9. If the short message contents could not be extracted from the SM-RP-UI parameter, send28back to the SMS-GMSC a Forward Short Message Response message with the29indication “System Failure”.30
X.S0023
3-129
1
Error Handling at the Reception of ANSI-41 SMDPP2
3
1. If the subscriber is not connected in the IIF then a SMDPP RR with cause code “SMS4Termination Denied” is returned.5
If the ESN received does not match stored ESN then a SMDPP RR with cause code6“SMS Termination Denied” or “Address Translation Failure” is returned.7
When the SMSNotification Indicator: “Notify when available” is not set, and the MS is8inactive or the subscriber’s location is unknown, a SMDPP RR with one of the following9cause codes is returned:10
11• “SMS Termination Denied”12
• “Destination Out of Service”13
• “No page response”14
• “Destination no longer at this address”15
When the SMSNotification Indicator: “Notify when available” is set, and the MS is16inactive or the subscribers location is unknown then a SMDPP RR with cause code17“SMS Delivery Postponed” is returned.18
If the subscriber does not have SMS service then a SMDPP RR with cause code “SMS19Termination Denied” is returned.20
2. If a SMDPP Invoke arrives at the IIF WITH A Teleservice ID that is not supported by the21IIF, then it shall return a SMDPP RR with cause code “Invalid Teleservice ID”.22
3. If a mandatory parameter is missing or if the MSID parameter is missing, a SMDPP RR23with cause code “Missing mandatory parameter” is returned.24
4. If the subscriber’s profile is not available, a SMDPP RR with cause code “Destination No25Longer at this Address” is returned.26
5. If the GSM MSC/VLR is on a Barring List, a SMDPP RR with cause code “SMS Delivery27Postponed” “SMS Termination Denied” is returned.28
6. If any other error is detected, a SMDPP RR with cause code “Network Failure” is returned.29
Note: The IIF should not use “SMS Delivery Postponed” if the ANSI-41 MC indicates that it30doesn’t require notification, or the IIF doesn’t set the delivery pending flag.31
32
X.S0023
3-130
Error Mapping from GSM FSM to ANSI SMDPP to support Mobile Terminating SMS in1GSM Foreign and Mobile Originating SMS in ANSI-41 Foreign Mode2
Table 116: Forward_Short_Message to SMS_CauseCode Values in SMDPP Return Result3Error Mapping4
GSM FORWARD_SHORT_MESSAGERESPONSE
ANSI SMDPP Return Result SMS-CauseCode Value
Absent Subscriber SMS Delivery Postponed ORNo Page Response
Subscriber Busy for MT SMS SMS Delivery Postponed ORDestination Busy
Memory Capacity exceeded Destination resource shortageSystem Failure Other network problem OR Network failureDataMissing Other general problem OR
Missing Mandatory ParameterUnexpectedDataValue Encoding problem OR
Unexpected Parameter valueFacilityNotSupported SMS not supportedUnknown Subscriber Address translation failureIllegal Subscriber Address translation failure OR
SMS termination deniedSM-DeliveryFailurecause: Equipment Protocol Error
Other radio interface problem ORNo Acknowledgement
SM-DeliveryFailurecause: Equipment Not SM-Equipped
Other terminal problem ORNo Acknowledgement
SM-DeliveryFailure cause: unknownSC Address translation failureSM-DeliveryFailure cause: SC-Congestion Network resource shortage OR
No AcknowledgementSM-DeliveryFailure cause: invalid SME-Addr
Address translation failure ORNo Acknowledgement
SM-DeliveryFailurecause: subscriberNotSC-Subscriber
SMS origination denied ORNo Acknowledgement
Absent Subscriber SM No acknowledgment ORNo page response
Encoding Error Network Failure
Unidentified Subscriber Address Vacant
Illegal Equipment Other General ProblemsAny other error Network Failure
5
Note: Unidentified Subscriber and Illegal Equipment may be treated as Any Other Error and6may be mapped to Network failure.7
X.S0023
3-131
1
Error Mapping from ANSI SMSDPP to GSM FSM to support Mobile Terminating SMS in2ANSI-41 Foreign Mode and Mobile Originated SMS in GSM Foreign Mode3
Table 117: SMDPP to Forward_Short_Message Error Mapping4
SMSDPP (Cause Code) FORWARD_SHORT_MESSAGEResponse
Destination Busy Subscriber Busy for MT-SMSAddress Vacant Absent SubscriberNo Page Response Absent SubscriberNo Acknowledgement Absent SubscriberDestination Out of Service Absent SubscriberDestination No Longer at this Address Absent SubscriberSMS not supported FacilityNotSupported
Destination resource shortage SM-DeliveryFailure with cause“MemoryCapacityExceeded”
Other radio interface problem SM-DeliveryFailure with cause“equipmentProtocolError”
Unrecognized parameter value orEncoding problem
SM-DeliveryFailure with cause“equipmentProtocolError”
Radio interface incompatibility or Otherterminal problems
SM-DeliveryFailure with cause“equipmentProtocolError”
SMS Delivery Postponed Absent Subscriber OR System Failure
Any other value System Failure
5
X.S0023
3-132
4.5.2 Short Message Service via GHOST or WEMT12
4.5.2.1 Detailed Procedures34
SMS Alert Procedure5
The SMS Alert procedure is used for alerting the SMSC when the mobile subscriber is active6and available for short messaging after a short message transfer has failed because the mobile7subscriber is not reachable or when the Mobile Station (MS) has indicated that it has no8memory capacity to accept a short message.9
4.5.2.1.1 Alerting for an ANSI-41 Subscriber in GSM Foreign Mode1011
IIF Receiving a READY_FOR_SM12
Upon receipt of a READY_FOR_SM message, the IIF shall store the originating Visited MSC13(VMSC) address in the subscriber’s profile and Invoke ID. It shall map the14GSM_READY_FOR_SM message to the ANSI_SMSNOT INVOKE message as described in15Table 119.16
It shall populate the SMS_Address parameter with the IIF address. All other parameters are17ignored.18
The ANSI_SMSNOT INVOKE is then transmitted to the subscriber’s SMSC with local19Transaction ID. Finally, the IIF shall return a READY_FOR_SM_ACK message with no20arguments to the originating VMSC.21
22
IIF Receiving a SMSNOT RETURN RESULT23
Upon receipt of a SMSNOT RR message, the IIF shall associate the SMSNOT Transaction ID24with the Invoke ID.25
4.5.2.1.2 Alerting for a GSM Subscriber in ANSI-41 Foreign Mode2627
IIF Receiving a SMSNOT INVOKE28
Upon receipt of a SMSNOT message, the IIF shall store the originating VMSC address and29Transaction ID. The IIF shall map the ANSI_SMSNOT message to the30GSM_READY_FOR_SM. The parameters shall be mapped as described in Table 120.31
The GSM_READY_FOR_SM is transmitted to the subscriber’s HLR with local Invoke ID.32Finally, the IIF shall return a SMSNOT RR to the originating VMSC.33
X.S0023
3-133
IIF Receiving a REGNOT INVOKE1
Alternatively, the IIF may receive a REGNOT message indicating an update in location of the2MS. Upon receipt of the REGNOT message, the IIF shall determine if the SMS Delivery3Pending Flag is set. If the DPF is not set, the IIF follow normal procedures according to 4.1.14
Location Registration. If the DPF is set, the IIF shall store the originating VMSC address5and Transaction ID. The IIF shall create a GSM_READY_FOR_SM.6
The content of the MSID is mapped to the equivalent IMSI and place in the IMSI parameter.7The Alert Reason parameter is populated with the value - MS Present. All other parameters8are ignored.9
The GSM_READY_FOR_SM is transmitted to the subscriber’s HLR with local Invoke ID. .10Finally, the IIF shall return a REGNOT RR to the originating VMSC.11
IIF Receiving a GSM_READY_FOR_SM_ACK12
Upon receipt of a GSM_READY_FOR_SM_ACK message, the IIF shall associate the13GSM_READY_FOR_SM_ACK Invoke ID with Transaction ID.14
4.5.2.1.3 SMS Delivery for an ANSI--41 Subscriber in GSM Foreign Mode1516
IIF Receiving SMSDeliveryPointToPoint INVOKE17
Upon receipt of an SMSDeliveryPointToPoint INVOKE message, the IIF shall store the18originating MC address and transaction ID. It shall map the ANSI_SMDPP message into a19GSM_FSM message and populate the subscriber’s known VMSC into the DPC. The mapping20of parameters is described in Table 121.21
The IIF transmits the GSM_FSM message with local Invoke ID.22
IIF Receiving FORWARD_SHORT_MESSAGE_ACK23
Upon receipt of the FORWARD_SHORT_MESSAGE_ACK message, the IIF shall associate the24Invoke ID with SMDPP transaction ID and map the GSM_FSM_ACK message into an25ANSI_SMDPP RETURN RESULT.26
Next, it populates the stored originating SMSC address into the DPC and populates the27transaction ID.28
If the User Error parameter is populated in the GSM_FSM_ACK, then map this value into the29SMS_CauseCode according to Table 116.30
Finally, the ANSI_SMDPP RR is transmitted to the originating SMSC.31
X.S0023
3-134
4.5.2.1.4 SMS Delivery for a GSM Subscriber in ANSI-41 Foreign Mode12
IIF Receiving MT_FORWARD_SHORT_MESSAGE3
Upon receipt of the MT_FORWARD_SHORT_MESSAGE message, the IIF shall store the4originating SMSC address and Invoke ID. It shall map the GSM_FSM message into an5ANSI_SMDPP INVOKE message and populate the subscriber’s known VMSC into the DPC.6The mapping of parameters is described in Table 122.7
The IIF transmits the ANSI_SMDPP INVOKE message with local transaction ID8
IIF Receiving SMDPP RETURN RESULT9
Upon receipt of a SMSDeliveryPointToPoint RR message, the IIF shall associate the SMDPP10transaction ID with Invoke ID and map the ANSI_SMDPP RR to GSM_FSM_ACK.11
Next, it populates the stored originating SMSC address and Invoke ID. If the SMS_CauseCode12parameter is populated in the ANSI_SMDPP RR message, then map value into User error13parameter according to Table 117.14
Finally, transmit the GSM_FSM_ACK to the originating SMSC.15
4.5.2.1.5 SMS Origination for an ANSI-41 Subscriber in GSM Foreign Mode1617
IIF Receiving MO_FORWARD_SHORT_MESSAGE18
Upon receipt of a MO_FORWARD_SHORT_MESSAGE, the IIF shall store the address of the19originating VMSC and Invoke ID. It shall map the GSM_MO_FSM to ANSI_SMDPP INVOKE.20The address of the subscriber’s TSA (from the SM RP DA – Service Center Address) is21mapped according to 4.5.2.4 into the SMS_DestinationAddress. The mapping of parameters is22described in Table 123.23
The IIF transmits the ANSI_SMDPP INVOKE message with local transaction ID.24
IIF Receiving SMDPP RETURN RESULT25
Upon receipt of a SMSDeliveryPointToPoint RR message, the IIF shall associate the SMDPP26transaction ID with Invoke ID and map the ANSI_SMDPP RR to the GSM_FSM_ACK.27
Next, it populates the stored originating SMSC address and Invoke ID. If SMS_CauseCode28parameter is populated in the ANSI_SMDPP RR message, then map value into User error29parameter according to Table 117.30
Finally, transmit the GSM_FSM_ACK to the originating VMSC.31
X.S0023
3-135
4.5.2.1.6 SMS Origination for a GSM Subscriber in ANSI-41 Foreign Mode12
IIF Receiving SMSDeliveryPointToPoint INVOKE3
Upon receipt of an SMSDeliveryPointToPoint INVOKE message, the IIF shall store the address4of the originating VMSC and Transaction ID and map the ANSI_SMDPP INVOKE to the5GSM_MO_FSM. The mapping of parameters is described in Table 124.6
The IIF transmits the GSM_FSM message with local Invoke ID.7
IIF Receiving FORWARD_SHORT_MESSAGE_ACK8
Upon receipt of the FORWARD_SHORT_MESSAGE_ACK message, the IIF shall associate the9Invoke ID with SMDPP transaction ID. The GSM_FSM_ACK message is mapped into an10ANSI_SMDPP RETURN RESULT.11
Next, it populates the stored originating SMSC address and transaction ID. If the User Error12parameter is populated in GSM_FSM_ACK, then this value is mapped into the13SMS_CauseCode according to Table 116.14
Finally, transmit the ANSI_SMDPP RR to the originating VMSC.15
4.5.2.2 Mapping of Messages, Parameters & Parameter Values1617
The IIF shall perform the mapping of messages, parameters and parameter values related to18Short Message Service in accordance with the tables presented next.19
4.5.2.2.1 Mapping of Messages2021
Table 118: Short Message Service (for GHOST or WEMT) Message Mapping22
ANSI MAP Messages GSM MAP Messages
SMSNOT READY_FOR_SM
SMDPP FORWARD_SHORT_MESSAGE
X.S0023
3-136
4.5.2.2.2 Mapping of Parameters12
The mapping of the GSM MAP _READY_FOR_SM message to the ANSI_SMSNOT message3is per Table 119.4
Table 119: Alerting for an ANSI-41 Subscriber in GSM Foreign Mode Parameter Mapping5
GSM MAP _READY_FOR_SM Status ANSI_SMSNOT StatusESN MIMSI MMSID M
Alert Reason (MS present orMemory Available)
M -
SMS_Address (IIF Address) R6
The mapping of the ANSI_SMSNOT message to the GSM MAP _READY_FOR_SM message7is per Table 120.8
Table 120: Alerting for a GSM Subscriber in ANSI-41 Foreign Mode Parameter Mapping9
ANSI_SMSNOT Status GSM MAP _READY_FOR_SM StatusESN MMSID M
IMSI R
SMS_Address (Serving MSC) O -Alert Reason (MS present) M
10
X.S0023
3-137
4.5.2.2.3 SMS Delivery for an ANSI-41 Subscriber in GSM Foreign Mode12
When the IIF receives an SMDPP Invoke from an ANSI-41 SMSC for an ANSI-41 MS roaming3in a GSM network, it stores the Originating MC address, converts the SMDPP to a MAP_FSM,4replaces the Originating Address by the address of the IIF, and sends the message to the5serving GSM MSC. Upon receipt of the MAP_FSM_ACK from the serving MSC, the IIF6converts the message to an SMDPP Return Result, replaces the Originating Address with its7own address and replaces the Destination Address with the previously stored address of the8ANSI-41 SMSC. See Table 121.9
Table 121: SMDPP to Forward Short Message for Mobile Terminated GHOST/WEMT10Teleservice Parameter Mapping in GSM Foreign Mode11
SMDPP Status MT FSM StatusSMS Bearer Data M SM-RP-UI MSMS Teleservice ID =GHOST orWEMT
M -
ESN O -MSID (Note 1) OSMS_OriginalDestinationAddress (= MSID) (Note 1)
OSM-RP-DA = IMSI M
SMS_ChargeIndicator O -SMS_DestinationAddress O -SMS_MessageCount O -SMS_NotificationIndicator O -SMS_OriginalDestinationSubAddress
O -
SMS_Original OriginatingAddress
O -
SMS_Original OriginatingAddress Sub Address
O -
SMS_Originating Address (= MCAddress)
O SM-RP-OA (set to IIF address)See 4.5.2.4
M
12
Note 1: MSID and SMS-Original-Destination Address should be the same13
14
X.S0023
3-138
4.5.2.2.4 SMS Delivery for a GSM Subscriber in ANSI-41 Foreign Mode12
When the IIF receives a MAP_FSM destined for an MS roaming in an ANSI-136/41 network, it3stores the originating Service Center address locally, and replaces the Service Center Address4in the outgoing SMDPP message by E.164 address of the IIF. Upon receipt of an SMDPP5Return Result from the serving ANSI-136/41 MSC, the IIF converts it to a MAP_FSM_ACK, and6places the previously stored Originating Service Center address in the Destination Address.7See Table 122.8
Table 122: Forward Short Message to SMDPP for Mobile Terminated GHOST/WEMT9Teleservice Parameter Mapping in ANSI Foreign Mode10
MT FSM Status SMDPP StatusMSID RSM-RP-DA =
IMSIM
SMS-Original_Destination-Address = MSID
O
SM-RP-OA =Service center address OA
M SMS_Originating Address = IIFAddress . See 4.5.2.4
O
SM-RP-UI M SMS_BearerData M- SMS_Teleservice Identifier =
GHOST or WEMTM
More Messages to Send C - -ESN (Not used)SMS_Charge Indicator (Notused)SMS_Destination Address (Notused)SMS_Message Count (Not used)SMS_Notification Indicator (Notused)SMS_Original OriginatingAddress (Not used)SMS_OriginalDestinationAddress (Not used)
11
X.S0023
3-139
4.5.2.2.5 SMS Origination for an ANSI-41 Subscriber in GSM Foreign Mode12
When the IIF receives a MAP_FSM originated from a MS roaming in a GSM network, it stores3the VMSC address locally and replaces the VMSC address in the outgoing SMDPP message4by the E.164 address of the IIF (placed in the SCCP Calling Party Address). Upon receipt of an5SMDPP Return Result from the MC, the IIF converts it to a MAP_FSM_ACK and places the6previously stored VMSC address in the SCCP Called Party Address. See Table 123.7
Table 123: Forward Short Message to SMDPP for Mobile Originated GHOST/WEMT in8GSM Foreign Mode Parameter Mapping9
GSM MO FSM Status ANSI SMDPP StatusSM-RP-DA =Service Center Address DA = IIFAddress
M SMS_DestinationAddress= MCAddress. See 4.5.2.4
R
SM-RP-OA =A-MSISDN
MNote 1
SMS_OriginalOriginating Address=A-MSID
R
SM-RP-UI M SMS_BearerData M- SMS_Teleservice Identifier =
GHOST or WEMT (Set by IIF)M
- SMS_Originating Address (Set toIIF address)
O
- Note 1 MSID O- Note 1 ESN O- SMS_Charge Indicator (Not used)- SMS_Message Count (Not used)- SMS_Notification Indicator (Not
used)
- SMS_OriginalDestinationAddress(Not used)
-SMS_Original Destination SubAddress (Not used)
- SMS_Original OriginatingAddress Sub Address (Not used)
10
Note 1: MSID and ESN are mapped from MSISDN received in SM-RP-OA11
12
X.S0023
3-140
4.5.2.2.6 SMS Origination for a GSM Subscriber in ANSI-41 Foreign Mode12
When the IIF receives a SMDPP Invoke originated from a MS roaming in an ANSI-41 network,3it stores the VMSC address locally and replaces the VMSC address in the outgoing MT FSM4message by the E.164 address of the IIF (placed in the SCCP Calling Party Address). It also5internally maps the TSAF from the SMS_Destination Address into the TSAH and places that6value in the RP-Destination Address per 4.5.2.4 Identification of the IIF SS7 Address for7Mobile Originated Services. Upon receipt of a MAP_FSM_ACK from the MC, the IIF converts it8to a SMDPP Return Result and places the previously stored VMSC address in the SCCP9Called Party Address. See Table 124.10
Table 124: SMDPP to Forward Short Message for Mobile Originated GHOST/WEMT11Teleservice Parameter Mapping in ANSI-41 Foreign Mode12
ANSI SMDPP Status GSM MO FSM StatusSMS Bearer Data M SM-RP-UI MSMS Teleservice ID =GHOST orWEMT
M -
ESN O -MSID O
(Note 1)-
SMS_Charge Indicator O -SMS_Destination Address O SM-RP-DA: Service Center
Address (retrieved from mappingin IIF database). See 4.5.2.4
M
SMS_Message Count O -SMS_Notification Indicator O -SMS_Original DestinationAddress
O -
SMS_Original Destination SubAddress
O -
SMS_Original OriginatingAddress(A-MSID)
O SM-RP-OA (A-MSISDN) M
SMS_Original OriginatingAddress Sub Address
O -
SMS_Originating Address O -Note 1: If MSID is received it should be the same as the SMS_OriginalOriginating Address13
14
X.S0023
3-141
GHOST shall use the HLPI shown below. TSAR may or may not be applied to the GHOST1teleservice.2
Table 125: HLPI for GHOST3
HLPI Subfield CodingTeleservice Type Indicator Subfield 0 - Standardized TeleserviceTeleservice Segmentation andReassembly Subfield
May or may not have TSAR sub-layer
0 - No TSAR
1 - TSAR is being usedTeleservice Protocol Identifier Subfield 000111
4
4.5.2.3 Error Handling5
4.5.2.3.1 Error handling at the reception of a Forward Short Message in the IIF6Refer to 4.5.1.3 Error Handling7
4.5.2.3.2 Error handling at the reception of a SMDPP message in the IIF8Refer to 4.5.1.3 Error Handling9
4.5.2.3.3 Cause Code Mapping at the IIF1011
At the IIF, the ANSI-41 SMS_CauseCode is mapped to a return error in the GSM12MAP_FSM_ACK message according to Table 11713
The IIF is responsible for mapping GSM MAP_FSM_ACK Return Errors to ANSI-4114SMS_CauseCodes according to Table 116.15
16
X.S0023
3-142
4.5.2.4 Identification of the IIF SS7 Address for Mobile Originated Services1The following SS7 address mapping scheme is defined in order to resolve the ambiguity that2occurs when a roaming subscriber attempts to invoke mobile originated teleservices.3Specifically, instead of using only a single Teleservice Server Address (TSA) as the SS7 SCCP4Called Party Address, a pair of E.164 addresses are defined for each Teleservice Server5Address Center (e.g., MC or SMSC). This pair of addresses (native and foreign mode TSAs) is6used to enable the routing of incoming messages to the IIF from the serving foreign network,7while messages that originate in a network that uses the same technology as the home network8bypass the IIF and are routed directly to the MC. The native mode address can be translated9using global title translation to the actual SS7 address (DPC and SSN) of the MC while the10foreign mode address is a virtual address that points (via global title translation) to the IIF.11There is a one-to-one mapping in the IIF between the home and foreign mode addresses for12each MC, as shown in Table 126. Note that there is a many-to-one relationship between the13virtual addresses and the actual IIF address.14
While roaming in foreign mode, the mobile station uses the foreign mode address in order to15ensure that messages are first routed to the IIF. The IIF performs message translation, and16inserts the native mode address, i.e., an E.164 number that is translatable by the network to the17actual MC destination SS7 address.18
Table 126: Teleservice Server Address Mapping in IIF19
Home Technology Address Foreign Technology AddressTSAH1 ↔ TSAF1
TSAH2 ↔ TSAF2
TSAH3 ↔ TSAF3
20
4.5.3 Message Waiting Notification21The Message Waiting Notification procedure is used to notify a mobile subscriber of voice mail22messages added or removed in his voice mail system.23
4.5.3.1 Detailed Procedures24The following procedures are applicable at the IIF for Message Waiting Notification.25
GSM Foreign Mode26
Two events can trigger the sending of updated MWN information by the IIF to the serving GSM27MSC/VLR, when an ANSI-41 native subscriber is roaming in GSM Foreign Mode.28
4.5.3.1.1 Registration Notification Return Result with MWN Information Received29When the ANSI-41 native subscriber registers in a GSM MSC/VLR, a GSM30MAP_UPDATE_LOCATION message is received at the IIF. This shall trigger an ANSI MAP31REGISTRATION_NOTIFICATION message to be sent by the IIF to the ANSI-41 home HLR.32
If the IIF receives a Registration Notification Return Result message with MWNCOUNT and33MWNTYPE parameters set to valid values, it shall set the Message Waiting Notification flag34and it shall send a GSM MAP_INSERT_SUB_DATA message(s) to the GSM MSC/VLR from35which it had received a previous GSM MAP_UPDATE_LOCATION message.36
X.S0023
3-143
The IIF shall also send an Update Location acknowledge message and send it to the GSM1MSC/VLR.2
The IIF shall then format and send a GSM MAP_FORWARD_SHORT_MESSAGE. Refer to3Table 129 for the mapping of parameters from ANSI-regnot return result to GSM MAP4_FORWARD_SHORT_MESSAGE.5
If a successful response is received for the FSM, the IIF shall clear the Message Waiting6Notification flag.7
If the response to FSM indicates that the receiving node does not support MAP V2, the8GSM_FSM message shall be reformatted in MAP V1 and sent again.9
If the response to FSM indicates an error condition, or if a time out occurs, the MWN10information is sent in a new GSM MAP _FORWARD_SHORT_MESSAGE when the IIF11receives a new GSM MAP _UPDATE_LOCATION, GSM MAP12_READY_FOR_SHORT_MESSAGE or GSM MAP _NOTE_MS_PRESENT message.13
4.5.3.1.2 Qualification Directive Invoke Received14If the IIF receives a QUALDIR INVOKE message from the ANSI-41 HLR with MWNCOUNT and15MNWTYPE parameters set to valid values, it shall set the Message waiting Notification flag and16it shall send a GSM MAP FORWARD_SHORT_MESSAGE. Refer to Table 130 for the mapping17of parameters between ANSI-QUALDIR and GSM-_MAP_FORWARD_SHORT_MESSAGE.18
If an error is detected in the QUALDIR INVOKE message, a Reject or Return Error message is19sent back to the sending node. No other processing is executed.20
If a successful response is received for the FSM, the IF shall clear the Message Waiting21Notification flag.22
If the error in the response to FSM indicates that the receiving node does not support MAP V2,23the GSM_FSM message shall be reformatted in MAP V1 and sent again.24
If an error is received in the response to FSM, or if a time out occurs, the MWN information is25sent in a new GSM MAP _FORWARD_SHORT_MESSAGE when the IIF receives a new GSM26MAP _UPDATE_LOCATION, GSM MAP _READY_FOR_SHORT_MESSAGE or GSM MAP27_NOTE_MS_PRESENT message.28
ANSI-41 Foreign Mode29
Two methods of delivering Message Waiting Notification to a native GSM subscriber roaming in30ANSI-41 are supported.31
4.5.3.1.3 GSM SMS Mapped to ANSI-41 Qualification Directive Invoke32If the IIF receives a GSM_FORWARD_SHORT_MESSAGE with MWN information, it shall set33the message waiting Notification flag and it shall format and send an ANSI_MAP_ QUALDIR34message to the serving ANSI-41 MSC/VLR. Refer to Table 131 for the mapping of parameters35from GSM MAP _FORWARD_SHORT_MESSAGE to ANSI_QUALDIR.36
When the IIF receives a positive acknowledgment to the Qualification Directive message, it37shall send an acknowledgment to the Forward Short Message with an error indication of38“absent subscriber”. This shall ensure that the MWN information is delivered again from the39home system when the subscriber returns home.40
X.S0023
3-144
If the MS registers in a different ANSI-41 MSC/VLR after some time, the MWN information is1delivered in the Registration Return Result message2
If the IIF detects errors in the FORWARD_SHORT_MESSAGE, an error indication is sent in the3response message. This shall cause the GSM MSC/VLR to send an error indication to the GSM4Message Center.5
If a Return Error or Reject is received in response to the ANSI_MAP Qualification Directive6INVOKE, the error code is mapped into the corresponding Forward Short Message error code7as described in Table 135.8
4.5.3.1.4 GSM SMS Mapped to ANSI-41 SMS using GHOST or WEMT9If the IIF receives GSM MAP _FORWARD_SHORT_MESSAGE for a mobile that is GHOST or10WEMT capable, it shall send an ANSI_MAP Short Message Delivery Point to Point INVOKE11message. Refer to Table 132 for the mapping of parameters from GSM MAP12_FORWARD_SHORT_MESSAGE to ANSI-SMDPP.13
When the Return Result for the SMDPP is received, the IIF sends back a positive14acknowledgement to the Forward Short Message.15
If the IIF detects errors in the FORWARD_SHORT_MESSAGE, an error indication is sent in the16response message. This shall cause the GSM MSC/VLR to send an error indication to the GSM17Message Center.18
If a Return Error or Reject is received in response to the ANSI_MAP Short Message Delivery19Point to Point INVOKE, the error code is mapped into the corresponding Forward Short20Message error code as described in Table 117.21
4.5.3.2 Mapping of Messages, Parameters & Parameter Values22The IIF shall perform the mapping of messages, parameters and parameter values related to23message waiting notification in accordance with the tables presented. Within the following24tables, the parameters are identified as either being Mandatory (M), Conditional (C), Service25Provider Optional (O) or Service User Optional (U) in accordance with the definitions given in26GSM 09.02 [4] and ANSI-41 [2].27
Table 127 shows the mapping between ANSI MAP messages and GSM MAP messages28related to Message Waiting Notification in GSM Foreign ModeTable 128 shows the mapping29between GSM MAP messages and ANSI MAP messages related to Message Waiting30Notification in ANSI-41 Foreign Mode.31
Table 127: Message Waiting Notification in GSM Foreign Mode Message Mapping32
ANSI MAP Messages GSM MAP Messagesregnot FORWARD_SHORT_MESSAGE
QUALDIR FORWARD_SHORT_MESASGE
33
X.S0023
3-145
Table 128: Message Waiting Notification in ANSI-41 Foreign Mode Message Mapping1
GSM MAP Messages ANSI MAP MessagesFORWARD_SHORT_MESSAGE QUALDIR
FORWARD_SHORT_MESSAGE SMDPP
2
When the IIF receives either a GSM MAP message or an ANSI MAP message, it shall apply3the following rules regarding the handling of parameters within those messages:4
The IIF shall populate mandatory parameters in messages sent by the IIF, regardless of5whether mapping of parameters is possible.6
The IIF may populate optional parameters in messages sent by the IIF, regardless of whether7mapping of parameters is possible.8
All parameters shall be populated in accordance with either GSM 09.02 [4] or ANSI-41 [2].9
10
Table 129 through Table 134 show the mapping of parameters, which the IIF shall perform11regardless of the mode of operation (GSM Foreign Mode or ANSI-41 Foreign Mode). Where12there is no direct mapping for parameters, a ‘-‘ has been entered in the corresponding table.13
Table 129: regnot to Forward Short Message for Message Waiting Notification Parameter14Mapping15
ANSI-41 regnot Return Result Status GSM MT FSM StatusSM-RP-DA = IMSI MSM-RP-OA = IIF address M
MWNCount (from Profile) O
MWNType (from Profile) O
SM-RP-UISee Table 133 and Table 134 fordetails of encoding of thisparameter.
M
More Messages to Send = no MNote 1
16
X.S0023
3-146
Table 130: QUALDIR to Forward Short Message for Message Waiting Notification1Parameter Mapping2
ANSI-41 QUALDIR GSM MT FSMMSID SM-RP-DA (M) = IMSI
SM-RP-OA (M) = IIF addressMWNCount (from Profile)MWNType (from Profile)
SM-RP-UI (M)See Table 133 and Table 134 for details ofencoding of this parameter.
_ More Messages to Send (M) = no(Note 1)
3
Note 1: This parameter is only valid for MAP V2.4
Table 131: Forward Short Message to QUALDIR for Message Waiting Notification5Parameter Mapping6
GSM MT FSM Status ANSI QUALDIR StatusM MSID MIMSI
ESN M_ QualificationInformationCode =
Profile onlyM
_ SystemMyTypeCode M
M MWNCount (in Profile) RSM-RP-UIMWNType (in Profile) R
7
Table 132: Forward Short Message to SMDPP for Message Waiting Notification8Parameter Mapping9
GSM MT FSM Status ANSI SMDPP Status SM-RP-UI (M) M SMS_BearerData M_ SMS_TeleserviceIdentifier =
GHOST or WEMTM
Originating Address M SMS-OriginalOriginatingAddress OM ESN OIMSI
MSID R10
X.S0023
3-147
Table 133: SM-RP-UI in Message FORWARD-SHORT-MESSAGE For MAP V2 Parameter1Encoding2
FIELD VALUE ENCODINGMETHOD
Message TypeIndicator
Set to value “SMS-DELIVER” All
More Messages toSend
Set to value “No more messages are waitingfor the MS in this SC”
All
Reply Path Set to value “TP-Reply-Path is not set in thisSMS-DELIVER”
All
Status ReportIndication
Set to value “A status report is notrequested”
All
Protocol Identifier Set to value “0” All
Service Center TimeStamp
Created by the IIF All
User Data Length Number of characters AllOriginating Address Encoded as follows to support delivering of
MWN information for the CPHS encodingmethod:
- First octet: Set value to 00000100(address length).- Second octet: Type of address. Bit 7 set tovalue 1, bits 654 set to value 101(alphanumeric) and bits 3210 set to value0000 (numbering plan id).- Third octet: First address value. Set bitnumber 0 to value 1 to enable and value 1to disable indication. Set bits 321 with value000 (voice message waiting indicator). Setbits 654 with value 001. Set bit 7 with value0 for first indicator.- Fourth octet: Second address value. Setbits 76543210 with value 0.
CPHS
3
X.S0023
3-148
1
Table 133: SM-RP-UI in Message FORWARD-SHORT-MESSAGE For MAP V2 Parameter2Encoding (concluded)3
FIELD VALUE ENCODINGMETHOD
Data Coding Scheme - Set bit numbers 7654 to discard (value1100) message.- Set bit number 3 to enable (1) or disableindication (0).- Set bit number 2 to 0.- Set bit numbers 10 to Mail MessageIndication (value 00).
DCS
User Data HeaderIndicator
parameter (one bit) indicating that the UD
field contains a Header. Set to value “Thebeginning of the TP-UD field contains aHeader in addition to the short message”.
UD
User Data one space character using the defaultalphabet
UD
User Data Header - First octet: Length of the User DataHeader.- Second octet: Information ElementIdentifier (IEI) = Special SMS MessageIndication (value 01).- Third octet: Length of this IEI (value 2).- Fourth octet: Bit 7 is Store(1)/Discard(0)message. Bits 0-6 with value 0 (VoiceMessage Waiting).- Fifth octet: Number of messages waiting.- Rest of octets: Beginning of short message
UD
4
X.S0023
3-149
Table 134: SM-RP-UI in Message FORWARD_SHORT-MESSAGE for MAP V1 Parameter1Encoding2
FIELD VALUE ENCODINGMETHOD
Message Type Indicator Set to value “SMS-DELIVER” AllMore Messages to Send Set to value “No more messages are
waiting for the MS in this SC”All
Protocol Identifier Set to value “0” All
Service Center Time Stamp Created by the IIF AllUser Data Length Number of characters AllUser Data one space character using the default
alphabetAll
Originating Address Encoded as follows to support deliveringof MWN information for the CPHSencoding method:
- First octet: Set value to 00000100(address length).- Second octet: Type of address. Bit 7set to value 1, bits 654 set to value 101(alphanumeric) and bits 3210 set tovalue 0000 (numbering plan id).- Third octet: First address value. Set bitnumber 0 to value 1 to enable and value0 to disable indication. Set bits 321 withvalue 000 (voice message waitingindicator). Set bits 654 with value 001.Set bit 7 with value 0 for first indicator.- Fourth octet: Second address value.Set bits 76543210 with value 0.
CPHS
Data Coding Scheme - Set bit numbers 7654 to discard (value1100) message.- Set bit number 3 to enable (1) ordisable indication (0).- Set bit number 2 to 0.- Set bit numbers 10 to Mail MessageIndication (value 00).
DCS
3
X.S0023
3-150
4.5.3.3 Error Handling1
4.5.3.3.1 Error Handling at the Reception of a Forward Short Message2Refer to 4.5.1.3 Error Handling3
4.5.3.3.2 Error Mapping from ANSI QUALDIR to GSM FSM4
Table 135: qualdir return error to FORWARD_SHORT_MESSAGE response Error5Mapping6
QUALDIR (Errors) FORWARD_SHORT_MESSAGEUnrecognized MSID SMS Delivery FailureUnrecognized ESN SMS Delivery FailureResourceShortage SMS Delivery FailureOperationNotSupported SMS Delivery FailureParameterError SMS Delivery FailureSystemFailure SMS Delivery FailureUnrecognizedParameterValue SMS Delivery Failure
MissingParameter SMS Delivery Failure
7
4.5.3.3.3 Error Mapping from ANSI SMSDPP to GSM FSM89
Table 136: SMSDPP to FORWARD_SHORT_MESSAGE response Error Mapping10
SMSDPP (Cause Code) FORWARD_SHORT_MESSAGEDestination Busy Subscriber Busy for MT-SMSAddress Vacant Absent SubscriberNo Pager Response Absent SubscriberNo Acknowledgement Absent SubscriberDestination Out of Service Absent SubscriberDestination No Longer at this Address Absent SubscriberSMS Delivery Postponed Absent Subscriber
Any other value System Failure
X.S0023
3-151
4.6 GPRS in GSM Foreign mode1
2
The following text describes the procedures in the IIF for the case in which an ANSI-413subscriber requests GPRS service while operating in GSM foreign mode.4
Note: There is no GPRS service for GSM subscribers roaming in an ANSI-41 radio5environment.6
4.6.1 Mobility Procedures78
Existing mobility procedures described in either GSM 09.02 [4] or ANSI-41 [2] are also directly9applicable to the IIF when it is emulating a GSM or ANSI-41 functional network element.10Enhancements and modifications to GSM 02.60 [30] and ANSI-41 [2] are also applicable.11
12
4.6.1.1 Detailed Procedures1314
The following text contains the procedures in the IIF for the case in which the ANSI-4115subscriber requests GPRS services while roaming in foreign mode (i.e., while roaming in a16GSM network).17
4.6.1.1.1 GPRS Location Updating18The IIF contains location information (SGSN number) relating to the roaming subscriber.19Therefore, the IIF needs to be updated at each change in SGSN. The IIF shall translate GSM20MAP messages to ANSI-41 MAP messages and vice versa when the subscribers home21ANSI-41 HLR needs updating. The subscriber’s ANSI-41 HLR shall be updated in the following22cases:23
• When the subscriber’s MS registers in an SGSN in a GSM network, when previously24registered in an ANSI-41 network;25
• When the subscriber’s MS registers in an ANSI-41 network, when previously registered in26an SGSN in a GSM network;27
The subscriber’s home HLR may be updated in the following cases:28
• When the subscriber’s MS (accessing a GSM Network) registers in another SGSN within29the same GSM network. The IIF acts like a GPRS HLR/AuC in this case.30
• When the subscriber’s MS (accessing a GSM network) registers in a SGSN when31previously registered in a GSM VLR within the same GSM network.32
When the HLR is updated, the IIF conveys a unique identifier to the ANSI-41 HLR identifying33the SGSN/GSM VLR or IIF, depending on Multiple MSCIDs optional support.34
If the IIF receives a GSM_ MAP_UPDATE_GPRS_LOCATION _REQUEST, it shall compare35the received routing area information with any previously stored routing area information. If the36received and previously stored routing area information are different, the IIF shall determine if37
X.S0023
3-152
the location updating is allowed and update the corresponding subscriber record accordingly1and send a GSM MAP _CANCEL_LOCATION_REQUEST to the old SGSN. If there is no2previously SGSN stored routing area information in the IIF, the IIF shall determine if the location3updating is allowed and update the corresponding subscriber record accordingly.4
If the IIF receives a GSM MAP _MS_PURGE_REQUEST, it shall check the contents of the5message for errors. If errors exist, the IIF shall send a GSM MAP _MS_PURGE_RESPONSE6indicating the reason for failure and the MS purged flag shall not be set. If no errors exist, the7IIF shall check if the received SGSN number matches the stored SGSN number.8
If the received SGSN number and the stored SGSN number match, the IIF shall set the MS9purged flag and shall send both a GSM MAP _MS_PURGE_RESPONSE to the SGSN and an10ANSI_MAP_MS_INACTIVE to the ANSI-41 HLR and awaits a response from the HLR.11
If the received SGSN number and the stored SGSN number do not match, the IIF sends a GSM12MAP _PURGE_MS_RESPONSE containing an empty result to indicate that the MS purged flag13is not set.14
If the MS requests a combined GSM and GPRS attach, then the SGSN requests a GPRS15location update to the IIF (acting as a GPRS HLR) and then the GSM-MSC requests a CS16location update. CS location update and mobility procedures are described in 4.1 Mobility17Procedures.184.6.1.2 Mapping of Messages, Parameters & Parameter Values19
The following tables present the mapping of presents the mapping of messages, parameters20and parameter values that the IIF shall perform.21
4.6.1.2.1 Mapping of Messages22
Table 137 shows the mapping between GSM MAP messages and ANSI MAP messages23related to GPRS Location Registration when necessary.24
Table 137: Location Updating GPRS in GSM Foreign Mode Message Mapping25
GSM MAP Messages ANSI MAP MessagesMAP_UPDATE_GPRS_LOCATION_REQUEST REGNOTMAP_INSERT_SUBSCRIBER_DATA_REQUEST1 regnotMAP_UPDATE_GPRS_LOCATION_RESPONSE regnot2
261 This procedure is used to download GPRS subscriber data to the SGSN.272 This message can also contain error values if the location updating procedure is28
unsuccessful. If the location updating procedure fails, the mapping is as shown in 4.1.1.3.29
Table 3 shows the mapping between GSM MAP messages and ANSI MAP messages for MS30Purge operation. Table 4 shows the mapping between GSM MAP messages and ANSI MAP31messages related to Location Cancellation.32
33
X.S0023
3-153
4.6.1.2.1.2 Mapping of Parameters1
2
The following tables show the mapping between the parameters in GSM MAP messages and3parameters in the corresponding ANSI-41 messages when necessary.4
Table 138: MAP_UPDATE_GPRS_LOCATION_REQUEST REGNOT Parameter Mapping5
GSM MAP_UPDATE_GPRS_LOCATION_REQUEST
Status ANSI_MAP_REGNOT Status
ElectronicSerialNumber MIMSI MMSID M
SGSN address M MSCID (Serving MSC)1 MSGSN Number M -
QualificationInformationCode M- SystemMyTypeCode M- MSCIdentificationNumber O- PC_SSN (Serving MSC or VLR) O- SystemAccessType2 O- TerminalType2 O- TransactionCapability2 O
61This parameter is used to convey an identity from the IIF to the ANSI-41 HLR identifying either7the SGSN or the IIF. In the case where the IIF supports multiple MSCIDs this identity is a8unique identity associated with the SGSN. Otherwize, the identity shall be that of the IIF.92Parameters are included in IS-41-C and later.10
X.S0023
3-154
1
Table 139 shows the mapping of parameters for GSM MAP2_INSERT_SUBSCRIBER_DATA_REQUEST to regnot when necessary.3
Table 139: MAP_INSERT_SUBSCRIBER_DATA_REQUEST regnot Parameter Mapping4
GSM MAP_INSERT_SUBSCRIBER_DATA_REQUEST
Status regnot Status
- SystemMYTypeCode (VLR orHLR)
M
- AuthorizationDenied O- Authorization Period O- ControlChannelData O- DeniedAuthorizationPeriod O- Digits (Carrier) O- Digits (Destination) O- MSCID (HLR) O- Profile “Macro”1 O- ReceivedSignalQuality O- SenderIdentificationNumber O- SMS_MessageWaitingIndicator O- SystemAccessData O- MSID OIMSI C -
51 This parameter is itself a macro containing a number of other parameters. As far as6
mapping of parameters is concerned, the IIF shall map the contents of the ‘Profile’ macro in7the ANSI-41-D ‘regnot’ to the contents of the GSM MAP8_INSERT_SUBSCRIBER_DATA_REQUEST as shown in Table 140:9
X.S0023
3-155
Table 140: MAP_UPDATE GPRS LOCATION RESPONSE regnot Parameter Mapping1
GSM MAP _UPDATE_GPRS_LOCATION_RESPONSE
Status
regnot Status
- SystemMYTypeCode (VLR orHLR)
M
- AuthorizationDenied O- Authorization Period O- ControlChannelData O- DeniedAuthorizationPeriod O- Digits (Carrier) O- Digits (Destination) OHLR number 1, 2 R MSCID (HLR) 2 R- Profile “Macro”3 O- ReceivedSignalQuality O- SenderIdentificationNumber O- SMS_MessageWaitingIndicator O- SystemAccessData O- MSID O
1 The presence of this parameter is mandatory in case of successful HLR updating.22 These parameters are used to convey a unique identifier from the IIF to the serving3
MSC/VLR, identifying the HLR.43 This parameter is itself a macro containing a number of other parameters. As far as5
mapping of parameters is concerned, the IIF shall map the contents of the ‘Profile’ macro in6the ANSI-41-D ‘regnot’ to the contents of the GSM MAP7_INSERT_SUBSCRIBER_DATA_REQUEST as shown in Table 92.8
9
X.S0023
3-156
As far as mapping of parameters is concerned, the IIF shall map the contents of the ‘Profile’1macro in the ANSI-41-D GSM MAP _INSERT_SUBSCRIBER_DATA_REQUEST as shown in2Table 141:3
Table 141: MAP_INSERT_SUBSCRIBER_DATA_REQUEST profile ‘macro’ Mapping4
MAP_INSERT_SUBSCRIBER_DATA_REQUEST
Status regnot Status
IMSI C MSID M
- AuthenticationCapability O
MSISDN C MobileDirectoryNumber OCategory C -Subscriber Status C -Bearer service List C -Teleservice List CForwarding information List C CallingFeaturesIndicator1 O- CarrierDigits O- DMH_AccountCodeDigits O- DMH_AlternateBillingDigits O- DMH_BillingDigits ORegional Subscription Data C -- GeographicAuthorization O- MessageWaitingNotificationCount O- MessageWaitingNotificationType OCall barring information List3 C OriginationIndicator2 OVLR CAMEL Subscription Info4 C OriginationTriggers4 O- PACAIndicator OCUG information List C -SS-Data List C6 CallingFeaturesIndicator1 OEMLPP Subscription Data C -Operator Determined BarringGeneral data
C OriginationIndicator2 O
Operator Determined BarringHPLMN data5
C OriginationIndicator2 O
Operator Determined BarringHPLMN data5
C RestrictionDigits O
Roaming Restriction Due ToUnsupported Feature
C -
- RoutingDigits OCall barring information List3 C SMS_OriginationRestrictions7 O
X.S0023
3-157
Table 141: MAP_INSERT_SUBSCRIBER_DATA_REQUEST macro profile Mapping1(concluded)2
MAP_INSERT_SUBSCRIBER_DATA_REQUEST
Status ‘profile’ macro Status
Call barring information List3 C SMS_TerminationRestrictions8 O- SPINIPIN O- SPINITriggers OCall barring information List3 C TerminationRestrictionCode OVLR CAMEL Subscription Info C TerminationTriggers4 OVoice Broadcast Data CVoice Group Call Data C -- PreferredLanguageIndicator OSS-Data List6 SMS_OriginationRestrictions7 O
SS-Data List6
SMS_TerminationRestrictions8 O
North American Equal Accesspreferred Carrier Id
U -
Roaming Restricted In SGSNDue To Unsupported Feature9
C -
GPRS Subscription Data10 C -Network access mode11 C -
31 The CallingFeaturesIndicator parameter provides a status of several ANSI supplementary4
services. This information may map into one or more GSM MAP parameters as shown in5Table 92.6
2 The OriginationIndicator parameter defines the type of calls that a MS is allowed to make.7This information may map into one or more GSM MAP parameters as shown in Table 92.8
3 The Call barring information List is a list of the call barring supplementary services that are9either active, quiescent or not active for individual or all teleservices. This information may10map into one or more ANSI MAP parameters as shown in Table 92.11
4 Camel/WIN interworking is out of the scope of this version of the standard.125 Operator Determined Barring HPLMN data may map into one or more ANSI MAP13
parameters as shown in Table 92.146 The SS-Data List may map into one or more ANSI MAP parameters as shown in Table 92.157 The SMS_OriginationRestrictions may map into one or more GSM MAP parameters as16
shown in Table 92.178 The SMS_TerminationRestrictions may map into one or more ANSI MAP parameters as18
shown in Table 92.199 The IIFmay decide to include this parameter in the request if certain services or features20
are indicated as not supported by the SGSN. This parameter is used only by the SGSN.21
X.S0023
3-158
10 This parameter contains a list of PDP-contexts a user has subscribed to. At GPRS location1updating the IIF shall include the complete GPRS Subscription Data. When there is a2change in GPRS subscriber data the IIF shall include only the new and/or modified PDP3contexts. When the SGSN receives GPRS Subscription Data it shall check if the received4data has to be considered as the entire GPRS subscription data. If so, it shall replace the5stored GPRS Subscription Data with the received data set, otherwise it shall replace the6data only for the modified PDP contexts (if any) and add the new PDP contexts (if any) to7the stored GPRS Subscription Data. If GPRS Subscription Data is omitted in the Insert8Subscriber Data operation the SGSN shall keep the previously stored GPRS Subscription9Data.If the SGSN detects that there is overlapping in the information received within a10dialogue, it shall send the error Unexpected Data Value. This parameter is used only by the11SGSN.12
11 This parameter defines the access capabilities of a registered MS.13
Error handling, Fault Recovery procedures and Error Code mapping are described in 4.114Mobility Procedures.15
X.S0023
3-159
4.6.2 Automatic Call Delivery1The Automatic Call Delivery procedure is invoked in the IIF, when a terminating call attempt2results in a request for routing information from the IIF.3
The following procedures are applicable at the IIF for GPRS in GSM Foreign mode Automatic4Call Delivery:5
4.6.2.1 Detailed Procedures6If the IIF receives an ANSI MAP_RoutingRequest Invoke message from the ANSI-41 HLR, it7shall check if the terminating call can be placed to that subscriber. Call delivery to an MS that is8roaming in a GPRS network in GSM foreign mode shall be delivered only if the subscriber is9registered with a GSM serving MSC/VLR. As such, the IIF (acting as a GSM HLR) sends the10GSM serving MSC/VLR a MAP Provide Roaming Number (PRN) see 4.2.1 Call Delivery.11
If the MS is attached for GPRS-only services, incoming calls are not deliverable to the12subscriber. Upon the reception of ROUTEREQ, the IIF determines if the MS is attached for13GPRS-only services and if so, the IIF shall not deliver the call. The IIF sends a routreq with the14field “AccessDeniedReason” set to “No Page Response” or “Unavailable”.15
X.S0023
3-160
4.6.2.1.1 Mapping of Messages, Parameters & Parameter Values1In this case, the IIF has the calling party DN available (from the ROUTEREQ message). Upon2the reception of a ROUTREQ, if the MS is only GPRS attached, the IIF proceeds to act as an3SMS-SC and sends an FSM to the SGSN requesting the SGSN to deliver an SMS message4containing the calling party’s DN to the MS. The mapping of parameters is shown in the5following table:6
Table 142: ROUTREQ MT_Forward Short Message Parameter Mapping7
ROUTREQ Status MT_Forward Short StatusBillingID (Originating) M -ElectronicSerialNumber M -MobileStationIDentity M SM-RP-DA = IMSI M
- SM-RP-OA = IIF address ininternational format. See4.5.2.4
M
MSCID (Originating MSC) M- More Messages to Send = no MSystemMyTypeCode (OriginatingMSC)
M -
AlertCode O -CallingPartyNumberString1(Note 1)
O SM-RP-UI M
CallingPartyNumberString2(Note 1)
O SM-RP-UI M
CallingPartySubaddress O -DestinationDigits O -DMH_AccountCodeDigits O -DMH_AlternateBillingDigits O -DMH_BillingDigits O -LegInformation O -LocationAreaID O -MobileDirectoryNumber O MSISDN
(Note 2)R
MSCIdentificationNumber R -NoAnswerTime O -OneTimeFeatureIndicator O -PC_SSN (Originating MSC) R -PilotBillingID O -PilotNumber O -
X.S0023
3-161
Table 142: ROUTREQ MT_Forward Short Message Parameter Mapping (concluded)1
ROUTREQ Status MT_Forward Short StatusRedirectingNumberString O -
RedirectingSubAddress O -SenderIdentificationNumber O -TerminationTreatment O -TerminationTriggers O -VoiceMailboxNumber O -VoiceMailPIN O -- MSC Number M- LMSI U- GMSC address R
- GSM Bearer Capability C- Network Signal Info C- Suppression of
AnnouncementC
- Call Reference Number R
- OR Interrogation C- Alerting Pattern C- CCBS Call C
2
Note 1: For encoding of those parameters, refer to “4.3.4 Calling Number/Line Identification3Presentation/Restriction”.4
Note 2: May also be directly retrieved from the subscriber profile pre-provisioned in the IIF.5
4.6.2.1.1.1 Error Code Mapping6
Appropriate errors for an MS attached to both GPRS and non-GPRS services are described in74.2.1.38
Appropriate AccessDeniedReason parameter values in the RoutingRequest Return Result for9the case of a call delivery attempt to an MS attached for GPRS-only services:10
AccessDeniedReason
Unavailable
No page Response
11
X.S0023
3-162
4.6.3 Short Message Procedures for ANSI-41 subscriber1The following describes the procedures for MS terminated and MS originated SMS while the2MS is roaming in a GPRS network in GSM foreign mode and is GPRS attached.3
Existing mobility procedures described in either GSM 09.02 [4] and GSM 03.60 Error!4Reference source not found. or ANSI-41 [2] are also directly applicable to the IIF when it is5emulating a GPRS, GSM or ANSI-41 functional network element.6
If the MS is both GSM CS attached as well as GPRS attached, then the IIF shall act as a GSM7SMS-SC.8
4.6.3.1 Short Message Service via CMT9The Short Message Service procedure is used to deliver short text messages to and from10mobile subscribers.11
4.6.3.1.1 Detailed Procedures12The following procedures are applicable at the IIF for Short Message Service. Mobile13Terminating SMS and Mobile Originated SMS using the CMT teleservice ID are described.14
4.6.3.1.1.1 Mobile Terminating SMS15If the IIF receives an ANSI-41 Short Message Delivery Point to Point message it shall check if16the MS location is known and if the subscriber is reachable. If both conditions are true, the IIF17shall format and send a GSM_ MAP_FORWARD_SHORT_MESSAGE (FSM) to the SGSN18serving the mobile. Refer to Table 109 for the mapping of parameters from ANSI_SMDPP to19GSM MAP _FORWARD_SHORT_MESSAGE.20
If a successful response is received for the FSM, the IIF shall return SMDPP Return Result21message. If the MS's location is not known, or if the MS is not reachable or if the response to22the FSM indicates the short message was not delivered to the mobile, the IIF shall set the SMS23Delivery Pending flag for the subscriber. The IIF shall then return an SMDPP Return Result24message with an appropriate SMS_CauseCode value. Refer to 4.5.1.3 Error Handling for the25values of SMS_CauseCode returned.26
If errors are detected when the SMDPP is received, the message may be rejected if it cannot27be processed or if mandatory parameters are missing. Otherwise, the IIF shall return a SMDPP28Return Result message with the appropriate SMS_CauseCode value. Refer to 4.5.1.3 Error29Handling for the description of error conditions and corresponding SMS_CauseCode values.30
If the response to FSM indicates a failure in the delivery of the short message, the IIF shall map31the cause value received to a corresponding SMS_CauseCode value in the SMDPP Return32Result, as described in Table 116.33
4.6.3.1.1.2 Alerting for GPRS in GSM Foreign Mode in either CMT or GHOST/WEMT34format35
The SMS Alert procedure is used for alerting the SGSN when the MS is available for short36messaging after a short message transfer has failed because the mobile subscriber is not37reachable or when the MS has indicated that it has no memory capacity to accept a short38message.39
X.S0023
3-163
Upon receipt of a READY_FOR_SM message, the IIF shall store the originating SGSN address1and Invoke ID in the subscriber’s profile. It shall map the GSM_READY_FOR_SM message to2the ANSI_SMSNOT INVOKE message as described in Table 119.3
It shall populate the SMS_Address parameter with the IIF address. All other parameters are4ignored.5
The ANSI_SMSNOT INVOKE is then transmitted to the subscriber’s SGSN with local6Transaction ID. Finally, the IIF shall return a READY_FOR_SM_ACK message with no7arguments to the originating SGSN.8
Upon receipt of a SMSNOT RR message, the IIF shall associate the SMSNOT Transaction ID9with the Invoke ID.10
If the IIF receives a GSM MAP _READY_FOR-SHORT_MESSAGE and the Delivery pending11flag is set for the subscriber, the IIF shall send an ANSI_MAP_SMS_NOTIFICATION message12to the home Message Center. The IIF shall clear the MNRG flag if Alert Reason is set to MS13present or The Memory Capacity Exceeded Flag (MCEF) flag if Alert Reason is set to Memory14Available and the flags were previously set. If the Alert Reason indicates the mobile present for15non GPRS situation, or when the update location procedure has been successfully completed16or Supplementary Service Control request is received, the MS not reachable flag (MNR) is17cleared and the service centre alert procedure is initiated. If the memory capacity exceeded flag18is set, the MS not reachable flag is cleared and stored reason for absence for non GPRS are19cleared but the alert procedure is not started. If the Alert Reason indicates the mobile present20for GPRS situation, or when the Update GPRS location procedure has been successfully21completed, the MS not reachable for GPRS (MNRG) flag is cleared and the service centre alert22procedure is initiated. The mapping of parameters is described in Table 143.23
The ANSI-41 MC shall re-send message SMDPP to deliver the short message to the subscriber.24
Table 143: Alerting for an ANSI-41 Subscriber for GPRS in GSM Foreign Mode Parameter25Mapping26
GSM MAP _READY_FOR_SM Status ANSI_SMSNOT StatusESN MIMSI MMSID M
Alert Reason M -Alert Reason Indicator 1 C
SMS_Address (IIF Address) R1 This parameter indicates that the alert reason is sent to the HLR due to GPRS activity.27
28
4.6.3.1.1.3 Mobile Originating SMS for GPRS in GSM Foreign Mode2930
If the IIF receives a GSM_FORWARD_SHORT_MESSAGE for a mobile originated short31message, it shall format and send an ANSI_MAP_SMDPP message to the home Message32Center. Refer to Table 114 for the mapping of parameters from GSM MAP33_FORWARD_SHORT_MESSAGE to ANSI_SMDPP.34
X.S0023
3-164
If the IIF receives a positive acknowledgment to the SMDPP message, it shall send a positive1acknowledgment to the Forward Short Message.2
If the IIF receives a negative acknowledgment to the SMDPP message, it shall map the3received SMS_CauseCode value into a corresponding error code in the FSM Response4message as described in Table 117. Also the IIF shall set the Mobile Not Reachable for GPRS5(MNRG) GSM SMS flag.6
If the IIF detects errors in the FORWARD_SHORT_MESSAGE, an error indication is sent in the7response message. Refer to 4.5.1.3 for the handling of errors at the reception of FSM.8
4.6.3.1.2 Mapping of Messages, Parameters & Parameter Values9The IIF shall perform the mapping of messages, parameters and parameter values related to10Short Message Service in accordance with the tables presented in 4.5.1.2.1.11
4.6.3.1.3 Error Handling12Error handling is described in 4.5.1.313
X.S0023
3-165
4.6.4 Short Message Service via GHOST or WEMT12
4.6.4.1 Detailed Procedures3
4.6.4.1.1 SMS Delivery for an ANSI-41 Subscriber for GPRS in GSM Foreign Mode4Upon receipt of an SMSDeliveryPointToPoint INVOKE message, the IIF shall store the5originating MC address and transaction ID. It shall map the ANSI_SMDPP message into a6GSM_FSM message and populate the subscriber’s known SGSN into the DPC. The IIF7transmits the GSM_FSM message with local Invoke ID.8
The mapping of parameters is described in Table 121.9
The IIF transmits the GSM_FSM message with local Invoke ID.10
Upon receipt of the FORWARD_SHORT_MESSAGE_ACK message, the IIF shall associate the11Invoke ID with SMDPP transaction ID and map the GSM_FSM_ACK message into an12ANSI_SMDPP RETURN RESULT.13
Next, it populates the stored originating SGSN address into the DPC and populates the14transaction ID.15
If the User Error parameter is populated in the GSM_FSM_ACK, then map this value into16the SMS_CauseCode according to Table 116.17Finally, the ANSI_SMDPP RR is transmitted to the originator.18
4.6.4.1.2 SMS Origination19Upon receipt of a MO_FORWARD_SHORT_MESSAGE, the IIF shall store the address of the20originating SGSN and Invoke ID. It shall map the GSM_MO_FSM to ANSI_SMDPP INVOKE.21The address of the subscriber’s TSA (from the SM RP DA – Service Center Address) is22mapped according to 4.5.2.4 into the SMS_DestinationAddress. The IIF transmits the23ANSI_SMDPP INVOKE message with local transaction ID. The mapping of parameters is24described in Table 123.25
Upon receipt of a SMSDeliveryPointToPoint RR message, the IIF shall associate the SMDPP26transaction ID with Invoke ID and map the ANSI_SMDPP RR to the GSM_FSM_ACK.27
Next, it populates the stored originating SGSN address and Invoke ID. If SMS_CauseCode28parameter is populated in the ANSI_SMDPP RR message, then map value into User error29parameter according to Table 117.30
Finally, transmit the GSM_FSM_ACK to the originating SGSN.31
4.6.4.2 Mapping of Messages, Parameters & Parameter Values32The IIF shall perform the mapping of messages, parameters and parameter values related to33Short Message Service in accordance with the tables presented in 4.5.2.2.34
4.6.4.3 Error Handling35Error handling is described in 4.5.1.336
X.S0023
3-166
4.6.5 Message Waiting Notification1The Message Waiting Notification procedure is used to notify a mobile subscriber of voice mail2messages added or removed in his voice mail system. 4.6.5 shows only the changes needed to3support GPRS service for an ANSI-41 subscriber in GSM foreign mode.4
If the subscriber is both GSM CS attached as well as GPRS attached, then the IIF shall act like5a GSM SMS-SC.6
4.6.5.1 Detailed Procedures7
4.6.5.1.1 Registration Notification Return Result with MWN Information Received8When the IIF receives a Registration Notification Return Result message with MWNCOUNT9and MWNTYPE parameters set to valid values, it shall send a GSM SMS with the MWN10information.11
The IIF shall then format and send a GSM MAP_FORWARD_SHORT_MESSAGE. Refer to12Table 129 for the mapping of parameters from ANSI-41 regnot return result to GSM MAP13_FORWARD_SHORT_MESSAGE.14
If a successful response is received for the FSM, the IIF shall clear the Message Waiting15Notification flag.16
If the response to FSM indicates an error condition, or if a time out occurs, the MWN17information is sent in a new GSM MAP _FORWARD_SHORT_MESSAGE when the IIF18receives a new GSM MAP _UPDATE_GPRS_LOCATION, GSM MAP19_READY_FOR_SHORT_MESSAGE or GSM MAP _NOTE_MS_PRESENT message.20
When the IIF receives a QUALDIR INVOKE message from the ANSI-41 HLR with21MWNCOUNT and MNWTYPE parameters set to valid values, it shall set the Message waiting22Notification flag and the IIF shall send a GSM MAP FORWARD_SHORT_MESSAGE. Refer to23Table 130 for the mapping of parameters between ANSI-QUALDIR and GSM-24_MAP_FORWARD_SHORT_MESSAGE.25
If an error is detected in the QUALDIR INVOKE message, a Reject or Return Error message is26sent back to the sending node. No other processing is executed.27
If a successful response is received for the FSM, the IIF shall clear the Message Waiting28Notification flag.29
If an error is received in the response to FSM, or if a time out occurs, the MWN information is30sent in a new GSM MAP _FORWARD_SHORT_MESSAGE when the IIF receives a new GSM31MAP _UPDATE_GPRS_LOCATION, GSM MAP _READY_FOR_SHORT_MESSAGE or GSM32MAP _NOTE_MS_PRESENT message.33
4.6.5.2 Mapping of Messages, Parameters & Parameter Values34The IIF shall perform the mapping of messages, parameters and parameter values related to35message waiting notification in accordance with 4.5.3.2.36
4.6.5.3 Error Handling37Refer to 4.5.1.3 Error Handling38
X.S0023
3-167
4.6.5.3.1 Error Mapping1Refer to 4.5.3.3.2 Error Mapping.2
X.S0023
3-168
ANNEX A Short Message Service Procedures1
within an ANSI-136 Network2
(Normative)3
GHOST may be used as the delivery teleservice from a short message entity to a mobile4station operating in ANSI-136 Native Mode through a SMSC, which is providing IIF functionality5at the GSM TP-layer. In this case, normal ANSI-41 procedures are used to deliver the GHOST6teleservice between ANSI-41 network elements and normal ANSI-136 procedures are used to7deliver the GHOST teleservice from the serving MSC to the mobile station. The SMSC is8responsible for identifying the MS as GHOST capable and for packaging the short message in9the proper format using the GHOST teleservice for delivery to the MS.10
A.1 CMT to GHOST Delivery11
If the short message entity is an MS originating a message using the Cellular Messaging12Teleservice (CMT) teleservice to the GHOST MS, then upon receipt of the CMT message the13SMSC proceeds as follows.14
A.1.1 Detailed Procedures15After determining the incoming CMT message is destined for an MS that supports the GHOST16teleservice, (the method to perform this identification is internal to the SMSC and beyond the17scope of this standard) the SMSC shall determine the status and location of the targeted MS18using normal ANSI-41 procedures.19
If the MS is unavailable or the location is unknown, the SMSC shall set an internal retry20schedule or wait for notification from HLR. Otherwise, it shall populate address delivery21information and optional parameters per normal ANSI-41 procedures. Next, it shall map the22contents of the SMS_BearerData per Error! Reference source not found. and populate the23SMS_TeleserviceIdentifier with the GHOST teleservice identifier. Finally, it shall transmit the24SMDPP INVOKE message to the serving MSC.25
X.S0023
3-169
A.1.2 Mapping of Messages, Parameters & Parameter Values1When the SMSC receives the SMDPP Invoke message from a CMT capable MS, the SMSC2follows normal ANSI-41 procedures except it replaces the CMT value of 32513d with the3GHOST value. In addition, the following parameter mapping related to ANSI-136-710 shall be4performed as indicated inTable 144.5
Table 144: ANSI-136-710 to GHOST Parameter Mapping.6
SMDPP/CMT Parameter Status HandlingANSI-136 Message TypeIndicator
M Only SMS_SUBMIT shall be relayed asa GHOST message.SMS_DELIVERY_ACK andSMS_MANUAL_ACK shall bediscarded if the destination is aGHOST MS.
ANSI-136 Message Reference M -ANSI-136 Privacy Indicator M -ANSI-136 Urgency Indicator M Not mapped. Handled by the SMSC.ANSI-136 DeliveryAcknowledgement Request
M Not mapped. See note 1.
ANSI-136 ManualAcknowledgement Request
M -
ANSI-136 Message Updating M Not mapped. Handled internally by theMC.
ANSI-136 User Data Unit M Mapped to TP-Data-Coding-Scheme,TP-User-Data and TP-User-Data-Length.The MC should support mapping ofuser data as described in A.2.1
Detailed ProceduresANSI-136 Validity Period O Not mapped. Handled internally by the
MC.ANSI-136 Deferred Delivery Time O Not mapped. Handled internally by the
MC.ANSI-136 Call Back Number O See A.3.1ANSI-136 Call Back NumberPresentation
O -
ANSI-136 Call Back NumberAlpha Tag
O -
7
Note 1: In GSM, delivery acknowledgement indicates that the data is stored at the MS. In ANSI-8136, delivery acknowledgement is triggered by an action of the MS user (displaying the9message). Therefore this parameter is not mapped. It is a local decision for the operator as to10how to treat MO messages requesting these acknowledgements. The recommended procedure11for operators is for the MC to return a SMS DELIVERY ACK to the originator upon receipt of a12
X.S0023
3-170
positive delivery confirmation from the terminating mobile. The procedures and format of the1SMS DELIVERY ACK message shall follow ANSI-136-710.2
Table 145 describes where the parameters in the MT GHOST message are derived from:3
Table 145: TP Derived Values4
Parameter in MT GHOSTmessage
Status Value/derivation
TP-Message-Type-Indicator M SMS-DELIVERTP-More-Messages-To-Send M Set appropriately by the MC based on
the MC message store.TP-Reply-Path M Set to “TP-Reply-Path parameter is not
set”TP-User-Data-Header-Indicator O Set to “the TP-UD field contains only
the short message”TP-Status-Report-Indicator O Set to “a status report will not be
returned to the SME”TP-Originating-Address M Set to the
SMS_OriginalOriginatingAddressTP-Protocol-Identifier M Set to 00000000TP-Data-Coding-Scheme M Set based on information in the ANSI-
136 User Data UnitSet bit number 3 per A.2.1
Detailed ProceduresSet bit numbers 1&0 to value “Class 1”.
TP-Service-Center-Timestamp M Set by the MC to the appropriate valueTP-User-Data-Length M Set based on information in the ANSI-
136 User Data UnitTP-User-Data O Set based on information in the ANSI-
136 User Data Unit.5
A.1.3 Error Handling6No additional error handling procedures beyond those in ANSI-41D are required.7
A.2 GHOST to CMT Delivery8
GHOST may be used to deliver teleservices from a mobile station operating in ANSI-136 Native9Mode to an MS-based short message entity, which only supports the CMT ID without the10involvement of an IIF.11
A.2.1 Detailed Procedures12The mobile station formulates a GSM SMS PDU and adds the GHOST header to the GSM13SMS PDU. If required, it adds the TSAR header to the GHOST teleservice. Next, it inserts the14
X.S0023
3-171
GHOST teleservice into the Higher Layer Protocol Data Unit of the R-Data Unit and adds the1GHOST HLPI. An R-DATA message is formulated and sent to the ANSI-136 BMI.2
The ANSI-136 MSC follows normal procedures and translates the R-DATA message to an3ANSI-41 SMDPP Invoke message and sends it to the originator’s home MC. The MC4destination address can be specified in the Teleservice Server Address. {Alternatively, MIN to5MC GTT or a routing table in the MSC may be used if the TSA is not present.} The MSC does6not open the Higher Layer Protocol Data Unit, but converts it directly to SMS_BearerData.7
For the mobile station in ANSI-136 Native Mode, the Teleservice Server Address shall indicate8that the home Teleservice Server is the home Message Center. Upon receipt of the SMDPP9Invoke message, the SMSC responds with a SMDPP RR per normal ANSI-41 procedures.10
The SMSC then identifies the destination address as an MS that supports CMT. (The method to11perform this identification is internal to the SMSC and beyond the scope of this standard.) It12then determines the status and location of the targeted MS using normal ANSI-41 procedures.13If the MS is unavailable or location is unknown, the SMSC shall set its internal retry schedule or14wait for notification from HLR15
Otherwise, it shall populate the address delivery information and optional parameters per16normal ANSI-41 procedures. Next, it maps the contents of the SMS_BearerData per Error!17Reference source not found. and MT CMT message are derived from18Table 146 and populates the SMS_TeleserviceIdentifier with the CMT teleservice identifier.19Finally, the SMSC transmits the SMDPP Invoke message to the serving MSC.20
Supported user data mappings21
The following user data mappings should be supported:2223
IS-136 Encoding GSM TP-Data-Coding-SchemeIRA/ITU.T50 GSM Default Alphabet. Mapping of the user data content should
be performed.User Specific 8-bit data. No mapping of user data content needs to be
performed.24
X.S0023
3-172
1
A.2.2 Mapping of Messages, Parameters & Parameter Values23
When the SMSC receives the SMDPP Invoke message from a GHOST capable MS, the SMSC4follows normal ANSI-41 procedures except it replaces the GHOST value of {to be provided by5TR45.3} with the CMT value of 32513d. In addition, the following parameter mapping related to6ANSI-136-710 shall be performed as indicated in Table 146.7
Table 146: GHOST to ANSI-136-710 Parameter Mapping8
Parameter in MT GHOST message Value/derivationTP-Message-Type-Indicator SMS-DELIVERTP-More-Messages-To-Send Set appropriately by the MC based on the
MC message store.TP-Reply-Path Set to “TP-Reply-Path parameter is not
set”TP-User-Data-Header-Indicator Set to “the TP-UD field contains only the
short message”TP-Status-Report-Indicator Set to “a status report will not be returned
to the SME”TP-Originating-Address Set to the
SMS_OriginalOriginatingAddressTP-Protocol-Identifier Set to 00000000TP-Data-Coding-Scheme Set based on information in the ANSI-136
User Data UnitSet bit number 3 per A.2.1 DetailedProceduresSet bit numbers 1&0 to value “Class 1”.
TP-Service-Center-Timestamp Set by the MC to the appropriate valueTP-User-Data-Length Set based on information in the ANSI-136
User Data UnitTP-User-Data Set based on information in the ANSI-136
User Data Unit.9
X.S0023
3-173
Table 147 describes where the parameters in the MT CMT message are derived from1
Table 147: CMT Derived Values2
SMDPP/GHOST Parameter HandlingTP-Message-Type-Indicator Only SMS-SUBMIT shall be relayed as a
CMT message. SMS-STATUS-REPORTshall be discarded if the destination is aCMT MS.
TP-Reject-Duplicates Not mapped. Handled internally by theMC.
TP-Validity-Period-Format Not mapped. Handled internally by theMC.
TP-Reply-Path Not mappedTP-User-Data-Header-Indicator If the TP-UDHI indicates that the TP-UD
contains a header then the MC shallinterpret the header. The MC may,depending on the values in the header,discard the message, ignore the header orprocess the header and modify the ANSI-136 User Data Unit
TP-Status-Report-Request Not mapped. Handled internally by theMC. See Table 149
TP-Message-Reference Mapped to ANSI-136 Message ReferenceTP-Destination-Address Mapped to
SMS_OriginalDestinationAddressTP-Protocol-Identifier Not mapped. Handled internally by the
MC.TP-Data-Coding-Scheme Mapped to ANSI-136 User Data UnitTP-Validity-Period Not mapped. Handled internally by the
MC.TP-User-Data-Length Mapped to ANSI-136 User Data UnitTP-User-Data Mapped to ANSI-136 User Data Unit
3
If the TP-Status-Report-Request is requested, then Table 149 provides mapping to identify the4status of a message being sent to a CMT mobile from a GHOST mobile. The SMS-STATUS-5REPORT is encapsulated in a new SMDPP message to the status requester. The derived6values for the SMS-STATUS-REPORT are contained in Table 149.7
X.S0023
3-174
1
Table 148: SMS_CauseCode to TP-STATUS Mapping2
SMS_CauseCode(ANSI-41)
TP-STATUS(GSM)
Short messagetransactioncompleted
None sent. PositiveACK.
0000000 Short message received bythe SME
Not mapped.(future item for SMPPinterworking)
0000001 Short message forwarded bythe SC to the SME but the SCis unable to confirm delivery
Not applicable. 0000010 Short message replaced bythe SC
Reserved values0000011..0001111 Reserved0010000..0011111 Values specific to each SCTemporary error,SC still trying totransfer SM
0000 0010 Network resourceshortage
0100000 Congestion
0010 0100 SMS deliverypostponed
0100001 SME busy
Not mapped 0100010 No response from SME0100 0010 Other radio interface
problems0100011 Service rejected
Not mapped 0100100 Quality of service notavailable
Not mapped 0100101 Error in SMENot mapped 0100110..0101111 ReservedNot mapped 0110000..0111111 Values specific to each SC
Permanent error,SC is not makingany more transferattempts
0110 0000 Encoding problem 1000000 Remote procedure error0010 0110 Destination no longer
at this address1000001 Incompatible destination
3
X.S0023
3-175
1
Table 148: SMS_CauseCode to TP-STATUS Mapping (concluded)2
SMS_CauseCode(ANSI-41)
TP-STATUS(GSM)
0010 0111 Other terminalproblem
1000010 Connection rejected by SME
Not mapped 1000011 Not obtainableNot mapped 1000100 Quality of service not
availableNot mapped 1000101 No interworking availableMC internal procedure 1000110 SM Validity Period ExpiredMC internal procedure 1000111 SM Deleted by originating
SMEMC internal procedure 1001000 SM Deleted by SC
AdministrationMC internal procedure 1001001 SM does not exist (The SM
may have previously existedin the SC but the SC nolonger has knowledge of it orthe SM may never havepreviously existed in the SC)
Not mapped 1001010..1001111 ReservedNot mapped 1010000..1011111 Values specific to each SC
Temporary error,SC is not makingany more transferattempts
0010 0011 Destination resourceshortage
1100000 Congestion
Not mapped 1100001 SME busyNot mapped 1100010 No response from SME
0110 0100 SMS not supported 1100011 Service rejectedNot mapped 1100100 Quality of service not
availableNot mapped 1100101 Error in SMENot mapped 1100110..1101001 ReservedNot mapped 1101010..1101111 ReservedNot mapped 1110000..1111111 Values specific to each SC
3
All other values mapped to Service Rejected (0110 0011).4
X.S0023
3-176
1
Table 149: SMS-STATUS-REPORT Derived Values2
Parameter in SMS-STATUS-REPORT
Status Value/derivation
TP-Message-Type-Indicator M Set to “SMS-STATUS-REPORT”TP-User-Data-Header-Indication O Not used or Set to value = 0TP-More-Messages-to-Send M Set to value = 1TP-Status-Report-Qualifier M Set to value = 0TP-Message-Reference M Set by the MC to the appropriate valueTP-Recipient-Address M Set by the MC to the appropriate valueTP-Service-Center-Time-Stamp M Set by the MC to the appropriate valueTP-Discharge-Time M Set by the MC to the appropriate valueTP-Status M Set per Table 148TP-Parameter-Indicator O -TP-Protocol-Identifier O -TP-Data-Coding-Scheme O -TP-User-Data-Length O -TP-User-Data O -
3
4
A.2.3 Error Handling56
No additional error handling procedures beyond those in ANSI-41D are required.7
8
X.S0023
3-177
1
A.3 Callback Number2
The Callback service enables SMS subscribers to be able to return calls to callers automatically3in an easy-to-use manner. Callers may provide their callback number to the SMSC by various4methods, including:5
DTMF entry through a voicemail system, etc.6
Paging the SMS subscriber directly (e.g., numeric paging entry)7
Automatically through the Original Origination Address8
As part of the text body of a short message9
The callback number can be dialed through a single button (e.g., pressing the SEND key) or a10simple key sequence (i.e., 3 or less keystrokes) of the MS. Using the capabilities of the MS,11the user may edit the callback number prior to originating the call.12
13
A.3.1 Detailed Procedures1415
A.3.1.1 CMT to GHOST1617
The CMT mobile shall follow existing procedures as described in ANSI-136-710 to transmit a18callback number. If the MO-SMS is routed through an IIF to get to the subscriber’s home19SMSC, callback number information is in the application layer of the message and thus is20passed transparently.21
Upon receipt at the SMSC, if the message contains the Callback Number parameter, then the22SMSC shall extract the callback number from this parameter and place it at the end of the TP-23User-Data field preceded by the phrase “CALLBACK: <space>”. Carriers should limit the24message size they inform their subscribers that they are allowed to send to account for the25sending of the callback number.26
27
A.3.1.2 External SME (SMPP to GHOST)2829
Upon receiving of a submitted short message for delivery, the SMSC shall determine if the30recipient’s mobile requires short message delivery via GHOST. This determination by the31SMSC is an internal process and is beyond the scope of this document. If the recipient’s32mobile uses CMT to receive short messages, then the SMSC shall delivery the message via33procedures as defined in ANSI-136-710. If the recipient’s mobile uses GHOST, then the SMSC34shall extract the callback number from the SMPP callback_num parameter and place it at the35end of the TP-User-Data field preceded by the phrase “CALLBACK: <space>”. Carriers should36limit the message size they inform their subscribers that they are allowed to send to account for37the sending of the callback number.38
39
X.S0023
3-178
A.3.1.3 GHOST to CMT12
Since there is no GSM equivalent to the ANSI-136 Callback Number parameter, two solutions3exist to provide equivalent feature functionality.4
1. The SMSC shall parse each message looking for a callback number based upon5a set of rules to determine the Callback number. It shall then place this number in6the ANSI-136 Callback Number parameter.7
2. The SMSC shall transparently map the TP-User-Data to the SMS_BearerData8per Table 122. The MS shall be capable of parsing the message and extracting9the callback number based upon the number appearing in the MS display screen.10The subscriber shall be able to press one button (e.g., SEND key) to callback the11number showing on the display screen.12
Solution 2 above is the recommended procedure to provide a callback number under this13scenario.14
15
A.3.2 Message Mapping, Parameters and Parameters Values1617
A.3.2.1 CMT to GHOST18Mapping for messages, parameters and parameter values shall be as according to19A.1.2 Mapping of Messages, Parameters & Parameter Values.20
A.3.2.2 External SME21ANSI-41/136 mapping for messages, parameters and parameter values for a GHOST message22is not affected by the Callback Number procedures.23
A.3.2.3 GHOST to CMT24Mapping for messages, parameters and parameter values shall be as according to25A.2.2 Mapping of Messages, Parameters & Parameter Values.26
A.3.3 Error Handling27No additional error handling procedures beyond those in ANSI-41D are required.28
X.S0023
3-179
1
ANNEX B Cause Code Mapping at Non-IIF Nodes2
(Informative)3
This annex is informative and describes processing that does not affect the IIF.4
A mobile station shall respond to a received GHOST teleservice after processing the relay5layer. If the relay layer generates a failure, then the mobile station shall map the resulting RP-6Cause value into its equivalent R-Cause code according to Table 150.7
Table 150: RP-ERROR Cause to R-Cause for Mobile Station Response to Mobile8Terminated Transfer Attempt.9
GSM RP-ERROR Cause ANSI-136 R-CauseMemory capacity exceeded (22) Memory capacity exceeded (22)Invalid short message transfer referencevalue (81)
Invalid short message transfer referencevalue (81)
Semantically incorrect message(95) Invalid message, unspecified (95)Invalid mandatory information (96) Mandatory information element error (96)Message type nonexistent or notimplemented (97)
Message type non-existent or notimplemented (97)
Message not compatible with shortmessage protocol state (98)
Message not compatible with the shortmessage transfer state (101)
Information element nonexistent or notimplemented (99)
Information element non-existent or notimplemented (99)
Protocol error, unspecified (111) Protocol error, unspecified (111)Interworking, unspecified (127) Interworking, unspecified (127)All other values Protocol error, unspecified (111)
10
At the ANSI-136 MSC, the R-Cause code returned by a mobile station is mapped into a11corresponding ANSI-41 SMS_CauseCode for inclusion in an SMDPP Return Result message.12
At the ANSI-136 MSC, the ANSI-41 SMS_CauseCodes are mapped to ANSI-136 R-DATA13REJECT R-Cause codes according to Table 151. The mobile station in turn maps the R-Cause14codes to RP-ERROR Causes according to Table 152.15
X.S0023
3-180
Table 151: ANSI-41 SMS_CauseCode to ANSI-136 R-Cause Code Mapping1
ANSI-41 SMS_CauseCode ANSI-136 R-CauseNetwork failure (3) Network out of order (38)Other network problems (5) Network out of order (38)
SMS origination denied (97) Unidentified subscriber (28) orFacility rejected (29)
SMS not supported (100) Requested facility not implemented (69)Address translation failure (1) Destination out of service (27) or
Unknown subscriber (30)Network resource shortage (2) Congestion (42)
2
Table 152: ANSI-136 R-Cause Code to RP-ERROR Cause Mapping within the Mobile3Station4
ANSI-136 R-Cause RP-ERROR Cause Destination out of service (27) Destination out of service (27) Unidentified subscriber (28) Unidentified subscriber (28) Facility rejected (29) Facility rejected (29)
Unknown subscriber (30) Unknown subscriber (30)Network out of order (38) Network out of order (38) Congestion (42) Congestion (42) Requested facility not implemented ((69) Requested facility not implemented (69)
5
6
X.S0023
3-181
ANNEX C: CDMA to GSM One-way Roaming Only1
(Informative)2
3
Optionally, IIF may support one way-roaming only from CDMA to GSM networks.4
In this case, all the mapping tables are applicable only in GSM Foreign Mode.5
The IIF maps the ANSI-41 authentication parameters to the GSM triplets6
All the changes are made on the assumption that the new requirements for UIM/handsets are7working. Table 152 shows the location updating mapping in the GSM foreign mode.8
9
Table 153: UPDATE_LOCATION_REQUEST ->REGNOT Parameter Mapping10
GSM MAP_UPDATE_LOCATION_REQUEST
Status ANSI_MAP_REGNOT Status
ElectronicSerialNumber MIMSI MMSID M
MSC Address M1 MSCID (Serving MSC)1 M- QualificationInformationCode M- SystemMyTypeCode M- MSCIdentificationNumber OVLR Number M -- PC_SSN (Serving MSC or VLR) O- SystemAccessType2 O
TerminalType2 O- TransactionCapability2 OLMSI U -Supported CAMEL Phases C -- -SYSACCTYPE3 O
111 These parameters are used to convey a unique identifier from the IIF to the HLR,12
identifying the serving MSC/VLR.132 Parameters are included in ANSI specifications IS-41-C and later.143 SYSACCTYPE parameter is required for the one-way CDMA to GSM roaming optional15
scenario and in this case the parameter must be set by IIF to indicate GSM access type.16
17
top related