network interworking between gsm map and ansi-41 · pdf filenetwork interworking between gsm...
TRANSCRIPT
3GPP2 N.S0028
Version 1.0.0
Version Date: April 2002
Network Interworking Between GSM MAP and ANSI-41 MAP Rev. B
Revision: 0
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 [email protected]. Requests to reproduce individual Organizational Partner's documents should be directed to that Organizational Partner. See www.3gpp2.org for more information.
N.S0028-0
Revision History
Revision Date
Rev. 0 Initial Publication April 2002
Note
This specification is an extract of TIA TR-46.3 J-STD-038-B.
(This page is intentionally left blank)
N.S0028-0
Version 1 i
1
Abstract 2
3
This standard addresses the interworking and interoperability between ANSI-41 MAP[1] and GSM 4 MAP[4] based networks in the support of subscribers roaming between networks. The 5 interworking and interoperability functionality of the services, information flows, and message 6 mappings are specified. 7
This standard consists of four volumes: 8
Volume 0 - Overview and Interworking Reference Model 9
Volume 1 - Service Descriptions 10
Volume 2 - Information Flows 11
Volume 3 - Message Mappings 12
13
This is Volume 0 - an overview of the Interworking and Interoperability Function (IIF) and the 14 associated network reference model. 15
16
N.S0028-0
Version 1 ii
1
Document Revision History 2
3
Revision Date Version Comment
0
March 2001
Post Ballot version with ballot comments
A May 2001 0 Version 0- Addition of GPRS in GSM Foreign Mode
A June 2001 1 Version 1 – Editorial Changes
B July 2001 3 Version 3: Addition of CDMA/GSM two way roaming
B March 2002 5 Version V&V: Addition of CDMA/GSM two way and one roaming
4
5
N.S0028-0
Version 1 iii
1
Contents 2
Abstract........................................................................................................................................ i 3
Document Revision History.......................................................................................................... ii 4
Contents..................................................................................................................................... iii 5
List of Tables.............................................................................................................................. vi 6
List of Figures............................................................................................................................ vii 7
Foreword...................................................................................................................................viii 8
1 Introduction.....................................................................................................................1 9
1.1 General ..............................................................................................................1 10
1.2 Purpose..............................................................................................................1 11
1.3 Scope.................................................................................................................1 12
1.4 Organization.......................................................................................................1 13
2 References .....................................................................................................................3 14
3 Definitions and Acronyms................................................................................................4 15
3.1 Definitions ..........................................................................................................4 16
3.2 Acronyms ...........................................................................................................6 17
4 Overview of Internetwork Roaming..................................................................................8 18
5 IIF Reference Model and Description...............................................................................9 19
5.1 Reference Model ................................................................................................9 20
5.2 Description .........................................................................................................9 21
5.2.1 Provisioned Subscriber Data ...............................................................10 22
5.3 Interworking for Network Interfaces...................................................................11 23
5.3.1 HLR - VLR Interface............................................................................12 24
5.3.2 Originating / Gateway MSC - Serving MSC Interface............................13 25
5.3.3 MC / SMS-SC - Serving MSC Interface ...............................................14 26
N.S0028-0
Version 1 iv
5.3.4 HLR – SGSN Interface.........................................................................16 1
5.4 IIF Implementation Alternatives.........................................................................16 2
5.4.1 IIF Resides within a GSM Network Entity..............................................17 3
5.4.2 IIF Resides within ANSI-41 Network Entity ...........................................17 4
5.4.3 IIF Resides within External Network Element........................................18 5
5.4.4 IIF Resides within Both ANSI-41 and GSM Network Entities.................18 6
Abstract........................................................................................................................................ i 7
Document Revision History.......................................................................................................... ii 8
Contents..................................................................................................................................... iii 9
List of Tables...............................................................................................................................v 10
List of Figures............................................................................................................................. vi 11
Foreword................................................................................................................................... vii 12
1 Introduction.....................................................................................................................1 13
1.1 General ..............................................................................................................1 14
1.2 Purpose..............................................................................................................1 15
1.3 Scope.................................................................................................................1 16
1.4 Organization.......................................................................................................1 17
2 References .....................................................................................................................2 18
3 Definitions and Acronyms................................................................................................3 19
3.1 Definitions ..........................................................................................................3 20
3.2 Acronyms ...........................................................................................................4 21
4 Overview of Internetwork Roaming..................................................................................6 22
5 IIF Reference Model and Description...............................................................................7 23
5.1 Reference Model ................................................................................................7 24
5.2 Description .........................................................................................................7 25
5.2.1 Provisioned Subscriber Data .................................................................7 26
N.S0028-0
Version 1 v
5.3 Interworking for Network Interfaces.....................................................................8 1
5.3.1 HLR - VLR Interface..............................................................................8 2
5.3.2 Originating / Gateway MSC - Serving MSC Interface............................10 3
5.3.3 MC / SMS-SC - Serving MSC Interface ...............................................10 4
5.4 IIF Implementation Alternatives.........................................................................12 5
5.4.1 IIF Resides within a GSM Network Entity..............................................12 6
5.4.2 IIF Resides within ANSI-41 Network Entity ...........................................12 7
5.4.3 IIF Resides within External Network Element........................................13 8
5.4.4 IIF Resides within Both ANSI-41 and GSM Network Entities.................13 9
10
11
N.S0028-0
Version 1 vi
1
List of Tables 2
3
There are no tables in this volume. 4
5
N.S0028-0
Version 1 vii
1
List of Figures 2
3
Figure 1: IIF Reference Model ................................................................................................... 9 4
Figure 2: HLR - VLR Interface...................................................................................................12 5
Figure 3: Originating / Gateway MSC - Serving MSC Interface..................................................14 6
Figure 4: MC / SMS-SC - Serving MSC Interface ......................................................................15 7
Figure 5: HLR- SGSN Interface.................................................................................................16 8
Figure 6: IIF Resides within GSM Network Element ..................................................................17 9
Figure 7: IIF Resides within ANSI-41 Network Element .............................................................17 10
Figure 8: IIF Resides within External Network Element .............................................................18 11
Figure 9: IIF Resides within both ANSI-41 and GSM Network Elements....................................18 12
Figure 1: IIF Reference Model ................................................................................................... 7 13
Figure 2: HLR - VLR Interface.................................................................................................... 9 14
Figure 3: Originating / Gateway MSC - Serving MSC Interface..................................................10 15
Figure 4: MC / SMS-SC - Serving MSC Interface ......................................................................11 16
Figure 5: IIF Resides within GSM Network Element ..................................................................12 17
Figure 6: IIF Resides within ANSI-41 Network Element .............................................................12 18
Figure 7: IIF Resides within External Network Element .............................................................13 19
Figure 8: IIF Resides within both ANSI-41 and GSM Network Elements....................................13 20
21
22
N.S0028-0
Version 1 viii
1
Foreword 2
This foreword is not part of this standard. 3
This standard addresses the interworking and interoperability between ANSI-41 MAP and GSM 4 based networks in the support of subscribers roaming between networks. The objective of the 5 standard is to achieve fully automatic, two-way interoperability between the heterogeneous 6 networks. Services supported by this standard are described along with the associated 7 information flows and message mappings. However, not all services and associated capabilities 8 of ANSI-41 MAP and GSM MAP are supported by this standard. In general the attempt has been 9 to focus on the key subscriber services needed in the market. 10
The focus of the first release of this standard was on common GSM and ANSI-136 TDMA 11 services and associated network signaling (i.e. ANSI-41 MAP and GSM MAP). A prerequisite for 12 this interoperability is multi-mode mobile stations with an enhanced SIM card for roaming 13 between ANSI-136, GSM, and AMPS networks. 14
The first release of the standard did not define or require changes to existing ANSI-41 MAP or 15 GSM MAP to achieve the described interworking and interoperability. However, due to 16 differences between the services and associated capabilities of the MAP protocols, complete and 17 fully transparent interoperability may not have been achieved for some services. Future releases 18 of this standard may require changes to ANSI-41 MAP, GSM MAP and the associated services to 19 achieve full transparency while roaming between the different networks. 20
Additional or alternate service descriptions, information flows, and message mappings may be 21 required to support other air interfaces supported by ANSI-41 MAP (e.g., IS-95, CDMA2000). 22 This may be accomplished in a future release of this standard. 23
Aspects of TIA/EIA-136 Revision C have been incorporated into the standard. 24
Revision A adds GPRS service capability in GSM Foreign Mode. 25
Revision BC adds two way roaming between GSM and IS-95 CDMA systems. A prerequisite for 26 this interoperability is multi-mode mobile stations with an enhanced SIM card for roaming 27 between IS-95 and GSM networks. 28
Information disclosed in this document is subject to the export jurisdiction of the US Department of 29 Commerce as specified in Export Administration Regulations (title 15 CFR parts 730 through 774 30 inclusive). The information contained herein may not be exported or re-exported to Cuba, Iran, Iraq, Libya, 31 North Korea, Sudan, or Syria. Contact the Telecommunications Industry Association, Arlington, VA or 32 http://ftp.tiaonline.org/tr-45/tr45ahag/public%20documents. 33
34
35
N.S0028-0
Version 1 ix
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
(This page is intentionally left blank) 16
N.S0028-0
1
1
1 Introduction 2
1.1 General 3
When a subscriber to one network type (e.g., ANSI-41) roams to a network of another type (e.g., 4 GSM), interworking and interoperability functions are required to support roaming and enable 5 service. This standard describes an Interworking and Interoperability Function (IIF) to support this 6 cross-technology roaming between ANSI-41 and GSM networks. The IIF supports a multi-mode 7 mobile station with a removable Subscriber Identity Module (SIM). The standard also defines the 8 required network message mappings between ANSI-41 MAP and GSM MAP to support the 9 mobile terminal and associated services. 10
This standard includes the support of cross-technology roaming between an ANSI-41 based 11 network and a GPRS network. The GPRS network may be coupled with a GSM network. This 12 feature requires enhancement to the Interworking and Interoperability Function (IIF) which 13 supports a multi-mode mobile station and Subscriber Identity Module (SIM) with GPRS 14 functionality. 15
16
1.2 Purpose 17
The purpose for this standard is to define and describe the functions necessary for roaming 18 between ANSI-41 MAP and GSM MAP based networks in the support of roaming subscribers. 19 This includes a capability to allow a subscriber to an ANSI-41 based network (e.g., a TDMA or 20 CDMAn ANSI-136 native subscriber) with a mobile terminal supporting GPRS service to roam to 21 a GPRS network in GSM Foreign Mode. GPRS support for IS-95 handsets is not addressed in 22 this release of the standard. 23
1.3 Scope 24
The scope of this standard are the services, information flows and message mappings which 25 require interworking and interoperability functional specifications to support roaming between 26 ANSI-41 MAP and GSM MAP networks. 27
The scope of this volume is to provide a description of interstandard roaming along with an 28 overview and network reference model for the Interworking and Interoperability Function (IIF). 29
1.4 Organization 30
This standard is divided into four separate volumes: 31
Volume 0 - Overview and Network Reference Model 32
Volume 1 - Service Descriptions 33
Volume 2 - Information Flows 34
Volume 3 - Message Mappings 35
36
Volume 0 is organized as follows: 37
1 Introduction - provides an overview, purpose, scope, and organization of this volume. 38
N.S0028-0
Version 1 2
2 References - is a list of references used in the preparation of this volume of this Interim 1 Standard. 2
3 Definitions and Acronyms - defines words and acronyms that are used in this volume of this 3 Interim Standard. 4
4 Overview of Internetwork Roaming - provides an overview of interstandard roaming and 5 defines the terms used to describe it. 6
5 IIF Reference Model and Description - provides an architecture description of the 7 Interoperability and Interworking Function (IIF), an overview of its functionality, 8 and description of its relationship and interfaces to other network elements. 9
10
N.S0028-0
3
1
2 References 2
3
[1] TIA/EIA-136: “TDMA Cellular/PCS--Radio Interface--Mobile Station-Base Station 4 Compatibility Standard,” March 2000, ANSI. 5
6
[2] TIA/EIA-41-D: “Cellular Radiotelecommunications Intersystem Operations,” December 1997, 7 ANSI. 8
9
[3] TIA/EIA-553: “Mobile Station – Land Station Compatibility Specification,” September 1989, 10 ANSI. 11
[4] GSM 09.02 Version 6.2.0 Release 1997 “Digital cellular telecommunication system (Phase 12 2+); Mobile Application Part (MAP) specification”, August 1998, ETSI. 13
14
[5] TIA/EIA/IS-129, “Interworking/Interoperability Between DCS 1900 and IS-41 Based MAPs for 15 1800 MHz Personal Communications Systems,” Phase 1, July 1996. 16
[6] TIA/EIA/IS-637”Short Message Services for Wideband Spread Spectrum Cellular Systems” 17
[7] TIA/EIA/IS 737A”IS-41 support for data services for digital terminals (TDMA and CDMA)” 18
[8] TIA/EIA/IS 735 “IS-41 support for IS-95-A (advanced CDMA)” 19
[9] TIA/EIA/TSB58-E A “Administration of Parameter Value Assignments for TIA/EIA Spread 20 Spectrum Standards” , January 2002 21
22
[10] TIA/EIA-95-B - Mobile Station-Base Station Compatibility Standard for Dual-Mode Spread 23 Spectrum Systems; Published October 1998. 24 25 [11] "TIA/EIA-IS-2000-A, cdma2000 Series, March 2000, plus addenda"Mobile Station-Base 26 Station Compatibility Standard for Dual-Mode Spread Spectrum Systems; 27 [12] TIA/EIA-868 – ANSI-41-D Network Based Enhancements to support one-way roaming to 28 GSM, Published TBD. 29
[12]"Enhanced Cryptographic Algorithms, Revision B," TR45AHAG, Published TBD 30
31
N.S0028-0
Version 1 4
1
3 Definitions and Acronyms 2
3.1 Definitions 3
AMPS 4
Advanced Mobile Phone Service (AMPS) is the same as EIA/TIA-553[3], which is an analog air 5 interface protocol standard for mobile stations and their associated base stations. AMPS 6 networks use ANSI-41 for intersystem signaling. 7
ANSI-41 8
ANSI-41, as used in this document, refers to TIA/EIA-41[2] and the modifications and 9 enhancements as noted in IS-751 and IS-807. This is a network protocol standard to support 10 intersystem operation of cellular networks, such as ANSI-136 or CDMAIS-95 networks. Key 11 intersystem support defined by ANSI-41 includes automatic roaming, intersystem handoff, and 12 intersystem operation, administration, and maintenance. Among other things, ANSI-41 defines 13 the interfaces between MSCs, between the MSC/VLR and the HLR/AC, and between the MSC 14 and the Short Message Service Center (SMS-SC) or Teleservice Server (TS). 15
ANSI-136 16
ANSI-136, as used in this document, refers to TIA/EIA-136[1], which is a TDMA air interface 17 protocol standard for mobile stations and their associated base stations. ANSI-136 is a dual-18 mode standard that includes digital (TDMA) operation at 800 MHz and 1900 MHz, and analog 19 (AMPS) operation at 800 MHz. ANSI-136 networks use ANSI-41 for intersystem signaling. 20
ANSI-136 Mode 21
ANSI-136 mode indicates the condition or state of a mobile station accessing an ANSI-136 22 network. 23
ANSI-136 Foreign Mode 24
ANSI-136 foreign mode indicates the condition or state of a GSM native subscriber accessing an 25 ANSI-136 network. 26
ANSI-136 Native Mode 27
ANSI-136 native mode indicates the condition or state of an ANSI-136 native subscriber 28 accessing an ANSI-136 network. 29
ANSI-136 Native Subscriber 30
ANSI-136 native subscriber indicates an end user whose primary or home subscription resides in 31 an ANSI-136 network. These subscribers include both home subscribers from the ANSI-136 32 network, as well as roamers from other ANSI-136 networks. 33
34
CDMA CDMA as used in this document, refers to TIA/EIA -95 [9] or TIA/EIA-2000 [10], which is a 35 CDMA 36 air interface protocol standard for mobile stations and their associated base stations. CDMA is a 37 dual-mode standard that includes digital (CDMA) operation and analog (AMPS) operation. CDMA 38 networks use ANSI-41 for intersystem signaling. 39
CDMA Mode 40
CDMA mode indicates the condition or state of a mobile station accessing an CDMA network. 41 42
N.S0028-0
5
CDMA Foreign Mode 1 CDMA foreign mode indicates the condition or state of a GSM native subscriber accessing a 2 CDMA network. 3 4 CDMA Native Mode 5 CDMA native mode indicates the condition or state of an CDMA native subscriber accessing an 6 CDMA network. 7 8 CDMA Native Subscriber 9 CDMA native subscriber indicates an end user whose primary or home subscription resides in an 10 CDMA network. These subscribers include both home subscribers from the CDMA network, as 11 well as roamers from other CDMA networks. 12
13
GPRS in GSM Foreign Mode 14
GPRS in GSM Foreign Mode is a subset of GSM Foreign Mode and indicates the condition or 15 state of an ANSI-41136 native subscriber accessing a GPRS network; the GPRS network may be 16 coupled with a GSM network. 17
18
GSM 19
Global System for Mobile Communications (GSM) defines both air interface and network 20 intersystem protocol standards for mobile stations (MS), base station systems (BSS), and 21 network switching systems (NSS). 22
GSM Mode 23
GSM mode indicates the condition or state of a mobile station accessing a GSM network. 24
GSM Foreign Mode 25
GSM foreign mode indicates the condition or state of an ANSI-41136 or an IS-95 native 26 subscriber accessing a GSM network. 27
GSM Native Mode 28
GSM native mode indicates the condition or state of a GSM native subscriber accessing a GSM 29 network. 30
GSM Native Subscriber 31
GSM native subscriber indicates an end user whose primary or home subscription resides in a 32 GSM network. These subscribers include both home subscribers from the GSM network, as well 33 as roamers from other GSM networks. 34
Mobile Equipment 35
The radio transceiver, main processing unit, and man-machine interface necessary to access the 36 radio network. 37
Mobile Station 38
The mobile equipment and the SIM together make up the mobile station, which is the wireless 39 radiotelephone used by the subscriber. 40
Subscriber Identity Module (SIM) 41
A smart card that plugs into the mobile equipment and that contains the authentication 42 algorithms, and stores service-oriented subscription information. 43
N.S0028-0
Version 1 6
3.2 Acronyms 1
AC Authentication Center in ANSI TIA/EIA-41 based networks 2
AuC Authentication Center in GSM networks 3
AMPS Advanced Mobile Phone Service 4
ANSI American National Standards Institute 5
CDMA Code-Division Multiple Access 6
EIA Electronics Industries Association 7
ESN Electronic Serial Number 8
ETSI European Telecommunications Standards Institute 9
GMSC Gateway Mobile Switching Center 10
GSM Global System for Mobile Communication 11
GGSN Gateway GPRS Serving Node 12
GPRS General Packet Radio Service 13
HLR Home Location Register 14
HPLMN Home Public Land Mobile Network 15
IIF Interworking and Interoperability Function 16
IMSI International Mobile Subscriber Identity 17
ITU International Telecommunications Union 18
MAP Mobile Application Part 19
MC ANSI-41136 Message Center (for SMS) 20
ME Mobile Equipment 21
MIN Mobile Identification Number 22
MS Mobile Station 23
MSC Mobile Switching Center 24
MSID Mobile Station Identity 25
MSISDN Mobile Subscriber ISDN Number 26
PDP Packet Data Protocol 27
N.S0028-0
7
PLMN Public Land Mobile Network 1
SGSN Serving GPRS Support Node 2
SIM Subscriber Identity Module 3
SMS Short Message Service 4
SMS-GMSC GSM Short Message Service Gateway Mobile Switching Center 5
SMS-IWMSC GSM Short Message Service Interworking Mobile Switching Center 6
SMS-SC GSM Short Message Service Center 7
SS7 Signaling System 7 8
TDMA Time Division Multiple Access 9
TIA Telecommunications Industry Association 10
VLR Visited Location Register 11
12
N.S0028-0
Version 1 8
1
4 Overview of Internetwork Roaming 2
Commercial mobile radio networks are implemented using several different standards. Some 3 example radio access networks based on different standards include Advanced Mobile Phone 4 Service (AMPS) based on TIA-553, Time Division Multiple Access (TDMA) based on ANSI-136, 5 Code Division Multiple Access (CDMA) based on IS-95 and TDMA based on the Global System 6 for Mobile Communication (GSM) standard. Furthermore, both ANSI-136 TDMAand CDMAIS-95 7 and GSM uses different network signaling standards. 8
In order to provide greater service ubiquity and flexibility, the need to offer subscribers access to 9 multiple networks based on different standards has been identified. Depending on the types of 10 networks available in the subscriber's location, the subscriber shall access service on a network 11 based on one of several different standards. 12
The type of network provided in the subscriber's home location area is native for this subscriber. 13 When the subscriber accesses any network using this technology or standard, the subscriber is 14 operating in native mode. Conversely, when the subscriber accesses a network using a 15 technology or standard which is different from the home location's network, the subscriber is 16 operating in foreign mode. Interstandard roaming allows the subscriber to seamlessly obtain 17 service in foreign mode. 18
19
N.S0028-0
9
1
5 IIF Reference Model and Description 2
3
5.1 Reference Model 4
The Interworking and Interoperability Function (IIF) provides a signaling control interface between 5 ANSI-41 and GSM network entities. This interface is provided to enable service access when a 6 subscriber operates in a foreign network whose signaling protocol is different from the home 7 network's protocol. Figure 1 below depicts the family of network interfaces provided by the IIF in 8 interconnecting networks. 9
10
Figure 1: IIF Reference Model 11
12
5.2 Description 13
GSM and ANSI-41 network entities rely on different network signaling protocols to support 14 mobility management and service realization. When a subscriber to a network supported by 15 ANSI-41 network entities (i.e., a native TDMAANSI-136 or ICDMAS-95 subscriber) accesses a 16 visited GSM network, the visited network uses GSM Mobile Application Part (MAP) signaling, 17 while the controlling home network uses ANSI-41 MAP signaling. Likewise, when a native GSM 18 subscriber accesses a visited ANSI-41 based network (i.e., an ANSI-136 TDMA or CDMAIS-95 19 network), the visited network uses ANSI-41 MAP signaling, while the controlling home network 20 uses GSM MAP signaling. 21
To support “seamless” interoperability of service between GSM and ANSI-41 network entities, an 22 interworking and interoperability function (IIF) or gateway shall map message flows between 23 GSM and ANSI-41 MAP. Analog AMPS capability, which is defined as a subset of ANSI-41136, is 24 also supported by ANSI-41 MAP. 25
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
N.S0028-0
Version 1 10
In most cases, the IIF interprets a signaling message in one protocol and converts it to the 1 equivalent operation in the other network protocol. 2
5.2.1 Provisioned Subscriber Data 3
The IIF does not duplicate the subscriber’s existing HLR, but provides a gateway to any visited 4 network that uses a foreign MAP protocol. The original source of subscription data remains in the 5 home network’s HLR. Most of this data shall not reside in the IIF, but shall be dynamically 6 converted and translated between GSM and ANSI-41 MAP messages as needed. 7
Nevertheless, some basic subscriber identity information needs to be provisioned in the IIF to 8 support this mapping process, such as: 9
• International Mobile Subscriber Identity (IMSI) 10
• Mobile Identification Number (MIN) 11
• Electronic Serial Number (ESN) 12
• Terminal type 13
• Network Access Mode (non-GPRS, GPRS or both) 14
Authentication and encryption services are critical functions that shall be supported with network 15 interoperability. These capabilities are managed in both GSM and ANSI-41 networks by the 16 Authentication Center (AuC or AC), which can be physically separated from the associated HLR 17 or integrated with it. Different authentication processes and algorithms are defined for GSM and 18 ANSI-41. Therefore, subscriber specific authentication data shall be provisioned and maintained 19 on both a GSM AuC and ANSI-41 AC, in order to support service on either network. 20
Subscriber data that needs to be maintained includes: 21
For ANSI-136-41 network: 22
• Ki (GSM subscriber authentication key) 23
• Triplets or groups of Kc (cipher key), RAND, XRES,CKSN (cipher key sequence 24 number), and SRES (signed response) for GSM based authentication and ciphering 25
• A-key (AMPS/ANSI-136 or IS-95 authentication key) 26
• SSD-A (AMPS/ANSI-136 or IS-95 shared secret data for authentication) 27
• SSD-B (AMPS/ANSI-136 or IS-95 shared secret data used for generated signaling 28 message encryption (SME) and voice privacy (VP) masks: the 29 CDMAPrivateLongCodeMask or the TDMA VoicePrivacyMask . 30
31
The foreign mode Authentication Center can be integrated into the IIF gateway or implemented 32 as a separate network element. 33
Optionally, IIF may support one way-roaming only from CDMA to GSM network. In this case no 34 data is provisioned at IIF level and ANSI-41 HLR/AC must be compliant with TIA/EIA -868 [11]. 35 All the changes are made on the assumption the new requirements for UIM/handsets are 36 working. 37 The following items are basic assumptions on which the optional one-way roaming scenario is 38 based: 39 The IIF is not provisioned with any subscriber data 40 There is no subscriber specific data stored in the IIF. 41 The Home System is enhanced to support ANSI -41-to-GSM roaming 42 The ANSI-41 Home System has enhanced authentication capabilities to support roaming of 43 subscribers to GSM systems. Subscribers may be using multi-mode mobile stations capable of 44
N.S0028-0
11
roaming into a GSM system or UIMs that are inserted into GSM terminal equipment. A valid SSD 1 is generated in the UIM before the user can roam to a GSM system 2 A valid SSD value must be generated in the UIM (or multi-mode MS) before the subscriber can 3 roam into a GSM system. The IIF functions as a VLR in its interaction with the ANSI -41 Home 4 System 5 The ANSI-41 AC shares SSD with the IIF for subscribers roaming in a GSM network. The IIF 6 generates the triplets (RAND, XRES, KC) used by the GSM system. The triplet generation function 7 is specified in section 2.2.4.1 of “Enhanced Cryptographic Algorithms, Revision B.” 8 9 After the subscriber is registered in a GSM system, the IIF reports authentication failures to the 10 ANSI-41 system using the AuthenticationFailureReport operation. 11 SSD is shared with the IIF until registration in the GSM system is canceled. The ANSI -41 12 AC/HLR can cancel registration using the RegistrationCancellation operation. 13 The IIF shall remove the subscriber’s SSD when registration in the GSM system is canceled. 14 SSD Update cannot be performed when the MS is roaming in a GSM system 15 A new SystemCapabilities parameter value shall be defined to indicate a GSM system 16 A SystemCapabilities parameter value indicating GSM system shall be used by the IIF to indicate 17 that the Serving network is using GSM authentication and privacy procedures. This indicates that 18 SSD Update cannot be performed. It also indicates that the ESN sent to the ANSI-41 home 19 system was not received from the MS. The IIF functions as a GSM HLR/AC in its interactions 20 with the GSM system 21 The IIF provides the GSM triplets needed for authentication and privacy in the GSM system. The 22 IIF generates triplets using the SSD value stored in the UIM (or multi-mode MS). 23 When roaming in a GSM system, the UIM uses the “authentication” algorithm supported 24 by the IIF 25 When roaming is a GSM system, the UIM (or multi-mode MS) must use an authentication 26 algorithm supported by the IIF for the computation of the cipher key and the response to the 27 random challenge. 28 The ANSI-41 home system is expected to update SSD when the MS returns to an ANSI-41 29 system 30 The subscriber’s SSD should be updated when the user returns to an ANSI-41 system. 31 The IIF shall prevent disclosure of SSD values received from ANSI -41 systems 32 The IIF shall provide a secure method of storing SSD values received from ANSI-41 systems. 33 The 34 SSD values shall not be disclosed nor transmitted to any other network entity. 35 The IIF shall be able to request the MS’s ESN in the AuthenticationRequest INVOKE sent 36 to the home ANSI-41 system 37
To support GPRS service in GSM Foreign Mode, GPRS specific subscriber data also needs to be 38 provisioned in the IIF such as : 39
• GGSN-list (GGSN Number and optional IP address) 40
• PDP Type 41
• PDP Address (if dynamic addressing is not allowed) 42
• Quality of Service Subscribed 43
5.3 Interworking for Network Interfaces 44
This following describes the individual network interfaces for which interoperability is provided by 45 the IIF. For each particular interoperability function and interface interworking, the IIF 46 simultaneously emulates a network element using foreign protocol messaging and a 47 corresponding network element using native protocol messaging. For each particular messaging 48 operation, the IIF converts the operation from the foreign protocol to the native protocol, and vice 49
N.S0028-0
Version 1 12
versa. The emulation functions in the IIF conform to existing ANSI-41 and GSM protocols when 1 communicating over the external interfaces. 2
The following figures depict the emulated network elements within the IIF using hashed lines. The 3 hashed lines connecting emulated network elements within the IIF represent internal, conversion 4 or mapping interfaces. All solid connecting lines depict standard ANSI-41 or GSM interfaces 5 based on existing protocol. 6
The arrow above each figure represents information exchange for the top half of the figure, while 7 the arrow below each figure represents information exchange for the bottom half of the figure. 8
5.3.1 HLR - VLR Interface 9
The IIF provides an interface between the subscriber's HLR and any VLR which uses a foreign 10 network signaling protocol. This interworking is provided over the interface reference "D" depicted 11 in the network reference model. Figure 2 below depicts the interworking and control interface 12 provided by the IIF in this case. 13
14
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
15
Figure 2: HLR - VLR Interface 16
17
5.3.1.1 ANSI-136 Foreign Mode Implementation for GSM Subscriber 18
When a GSM native subscriber operates in ANSI-136 foreign mode, the mobile station shall use 19 the ANSI-136 air interface. The interoperability gateway or IIF shall provide both ANSI-41 HLR 20 and GSM VLR emulation to allow the subscriber to automatically register and obtain service. To 21 the visited ANSI-41 network, the subscriber appears to register with the IIF, emulating an 22 ANSI-41 HLR. This emulated ANSI-41 HLR acts as a limited proxy for the actual GSM HLR, with 23 the true GSM HLR retaining ultimate control. At the same time, to the home GSM network, the 24 subscriber appears to register from the IIF, emulating a GSM VLR. The IIF links ANSI-41 MAP 25 operations and data to the equivalent GSM MAP operations and data, and vice versa, in order to 26 support interoperability. 27
N.S0028-0
13
To support ANSI-136 foreign mode operation, an ANSI-136 Authentication Center (AC) can be 1 integrated into the IIF gateway or implemented as a separate network element. 2
3
5.3.1.2 GSM Foreign Mode Implementation for ANSI-136 Subscriber 4
Similarly, when an ANSI-136 native subscriber operates in GSM foreign mode, the mobile station 5 shall use the GSM air interface. The interoperability gateway or IIF shall provide both GSM HLR 6 and ANSI-41 VLR emulation to allow the subscriber to automatically register and obtain service. 7 To the visited GSM network, the subscriber appears to register with the IIF, emulating a GSM 8 HLR. This emulated GSM HLR acts as a limited proxy for the actual ANSI-41 HLR, with the true 9 ANSI-41 HLR retaining ultimate control. At the same time, to the home ANSI-136 network, the 10 subscriber appears to register from the IIF, emulating an ANSI-136 VLR. The IIF links GSM MAP 11 operations and data to the equivalent ANSI-41 MAP operations and data, and vice versa, in order 12 to support interoperability. 13
To support GSM foreign mode operation, a GSM Authentication Center (AuC) can be integrated 14 into the IIF gateway or implemented as a separate network element. 15
5.3.1.3 CDMAIS-95 Foreign Mode Implementation for GSM Subscriber 16
When a GSM native subscriber operates in IS-95 foreign mode, the mobile station shall use the 17 IS-95 CDMA air interface. The interoperability gateway or IIF shall provide both ANSI-41 HLR and 18 GSM VLR emulation to allow the subscriber to automatically register and obtain service. To the 19 visited ANSI-41 network, the subscriber appears to register with the IIF, emulating an ANSI-41 20 HLR. This emulated ANSI-41 HLR acts as a limited proxy for the actual GSM HLR, with the true 21 GSM HLR retaining ultimate control. At the same time, to the home GSM network, the subscriber 22 appears to register from the IIF, emulating a GSM VLR. The IIF links ANSI-41 MAP operations 23 and data to the equivalent GSM MAP operations and data, and vice versa, in order to support 24 interoperability. 25
To support IS-95 foreign mode operation, an IS-95 Authentication Center (AC) can be integrated 26 into the IIF gateway or implemented as a separate network element. 27
28
5.3.1.4 GSM Foreign Mode Implementation for IS-95CDMA Subscriber 29
Similarly, when an IS-95CDMA native subscriber operates in GSM foreign mode, the mobile 30 station shall use the GSM air interface. The interoperability gateway or IIF shall provide both 31 GSM HLR and ANSI-41 VLR emulation to allow the subscriber to automatically register and 32 obtain service. To the visited GSM network, the subscriber appears to register with the IIF, 33 emulating a GSM HLR. This emulated GSM HLR acts as a limited proxy for the actual ANSI-41 34 HLR, with the true ANSI-41 HLR retaining ultimate control. At the same time, to the home IS-35 95CDMA network, the subscriber appears to register from the IIF, emulating an IS-95CDMA VLR. 36 The IIF links GSM MAP operations and data to the equivalent ANSI-41 MAP operations and data, 37 and vice versa, in order to support interoperability. 38
To support GSM foreign mode operation, a GSM Authentication Center (AuC) can be integrated 39 into the IIF gateway or implemented as a separate network element. 40
41
42
5.3.2 Originating / Gateway MSC - Serving MSC Interface 43
The IIF provides a MAP interface between the subscriber's originating or gateway MSC to a 44 serving MSC which uses a foreign network signaling protocol. This interworking is provided over 45 the interface reference "E" depicted in the network reference model. In this case, no ISUP or MF 46
N.S0028-0
Version 1 14
signaling is supported over this interface. Figure 3 below depicts the interworking and control 1 interface provided by the IIF in this case. 2
This interface is key to supporting optimal routing for late call forwarding, where the serving MSC 3 wishes to signal back to the originating or gateway MSC in order to request forwarding of the call. 4 In order to support optimal routing for late call forwarding, the IIF provides originating or gateway 5 MSC emulation. 6
7
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
8
Figure 3: Originating / Gateway MSC - Serving MSC Interface 9
10
5.3.3 MC / SMS-SC - Serving MSC Interface 11
The IIF provides an interface from the subscriber's short message service message center (MC / 12 SMS-SC) to a serving MSC which uses a foreign network signaling protocol. This interworking is 13 provided over the interface references "Q" and "E" depicted in the network reference model. In 14 the case of ANSI-41 messaging, the MC has a direct "Q" interface to the serving MSC. In the 15 case of GSM messaging, the SMS-SC interfaces with the serving MSC via the SMS Interworking 16 MSC (SMS-IWMSC) or the SMS Gateway MSC (SMS-GMSC) over the "E" interface. Figure 4 17 below depicts the interworking and control interface provided by the IIF in this case. 18
19
20
N.S0028-0
15
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
1
Figure 4: MC / SMS-SC - Serving MSC Interface 2
3
5.3.3.1 ANSI-41136 Foreign Mode Implementation for GSM Subscriber 4
For short message service (SMS) interoperability, the IIF shall provide ANSI-41 Message Center 5 (MC) emulation, acting as a limited proxy for the subscriber’s GSM Short Message Service 6 Center (SMS-SC). The IIF links GSM MAP operations and data to the equivalent ANSI-41 MAP 7 operations and data, and vice versa. 8
9
5.3.3.2 GSM Foreign Mode Implementation for ANSI-41136 Subscriber 10
For SMS interoperability, the IIF shall provide GSM SMS-SC emulation, as well as SMS-GMSC 11 or SMS-IWMSC emulation, acting as a limited proxy for the subscriber’s ANSI-41 MC. The IIF 12 links ANSI-41 MAP operations and data to the equivalent GSM MAP operations and data, and 13 vice versa. In some cases, the IIF may need to originate short messages in order to support 14 interoperability. 15
16
N.S0028-0
Version 1 16
1
5.3.4 HLR – SGSN Interface 2
3
The IIF provides an interface between the subscriber's HLR and any SGSN which uses a foreign 4 network signaling protocol. This interworking is provided over the interface reference "Gr" 5 depicted in the network reference model. Figure 5 below depicts the interworking and control 6 interface provided by the IIF in this case. 7
8
Figure 5: HLR- SGSN Interface 9
10
5.3.4.1 GPRS in GSM Foreign Mode Implementation for ANSI-41136 Subscriber 11
When an ANSI-41136 native subscriber operates GPRS in GSM foreign mode, the mobile station 12 shall use the GSM air interface. The interoperability gateway or IIF shall provide both GSM HLR 13 and ANSI-41 VLR emulation to allow the subscriber to automatically register and obtain service. 14 To the visited GSM network, the subscriber appears to register with the IIF, emulating a GSM 15 HLR. This emulated GSM HLR acts as a limited proxy for the actual ANSI-41 HLR, with the true 16 ANSI-41 HLR retaining ultimate control. At the same time, to the home ANSI-41 network, the 17 subscriber appears to register from the IIF, emulating an ANSI-41 VLR. The IIF links GSM MAP 18 operations and data to the equivalent ANSI-41 MAP operations and data, and vice versa, in order 19 to support interoperability. 20
To support GSM foreign mode operation, a GSM Authentication Center (AuC) can be integrated 21 into the IIF gateway or implemented as a separate network element. 22
23
5.4 IIF Implementation Alternatives 24
There are four alternatives for the implementation of the IIF functional element with respect to the 25 network reference model and the network entities that are served. See “5 IIF Reference Model 26 and Description” for applicable interfaces. 27
ANSI-41 Subscriber roamingto GPRS network
IIF
SGSNGSMHLR
ANSI-41VLR
ANSI-41HLR
GrD
TIA/EIA-41Network Entities
GSM NetworkEntities
N.S0028-0
17
5.4.1 IIF Resides within a GSM Network Entity 1
The IIF may reside entirely inside an existing GSM network entity as a separate functional 2 element. Each of the interfaces can be supported with this implementation alternative. 3
G S M N e tw o rk E lem en t
T IA /E IA -4 1 N e tw o rk E le m e n t
IIF
4
Figure 6: IIF Resides within GSM Network Element 5
6
5.4.2 IIF Resides within ANSI-41 Network Entity 7
The IIF may reside entirely inside an existing ANSI-41 network entity as a separate functional 8 element. Each of the interfaces can be supported with this implementation alternative. 9
G S M N etw o rk E lem en t
T IA /E IA -4 1 N e tw o rk E le m e n t
IIF
10
Figure 7: IIF Resides within ANSI-41 Network Element 11
12
13
N.S0028-0
Version 1 18
1
5.4.3 IIF Resides within External Network Element 2
The IIF may reside external to any existing ANSI-41 or GSM network entity as a separate network 3 element. Each of the interfaces can be supported with this implementation alternative. 4
GSM Network Element
TIA/EIA-41 Network Element
External Network Element
IIF
5
Figure 8: IIF Resides within External Network Element 6
7
5.4.4 IIF Resides within Both ANSI-41 and GSM Network Entities 8
Finally, the IIF may reside within both existing ANSI-41 and GSM network entities at the same 9 time. In this case, each individual subscriber is likely to be served by one particular IIF, although 10 the use of multiple IIFs per subscriber is possible. Again, each of the interfaces can be supported 11 with this implementation alternative. While multiple IIFs can support one particular subscriber, 12 each network interworking function would be supported by one specific IIF implementation. 13
14
GSM Network Element
TIA/EIA-41 Network Element
IIF IIF
15
Figure 9: IIF Resides within both ANSI-41 and GSM Network Elements 16
17
N.S0028-0
Ballot Version i
Abstract 1
This standard addresses the interworking and interoperability between ANSI-41 MAP[3] and GSM 2 MAP[21] based networks in the support of subscribers roaming between networks. The interworking 3 and interoperability functionality of the services, information flows, and message mappings are 4 specified. 5
This standard consists of four Volumes: 6
Volume 0 - Overview and Interworking Reference Model 7
Volume 1 - Service Descriptions 8
Volume 2 - Information Flows 9
Volume 3 - Message Mappings 10
This is Volume 1. Volume 1 is based on ANSI-664[1] and GSM stage 1’s (see GSM 02-series e.g., 11 GSM 02.04, etc. in the References section). Some modifications (primarily simplifications) were made 12 for the purpose of specifying the degree of interoperability desired. ANSI-664 services and GSM 13 services do not necessarily align. 14
15
N.S0028-0
Ballot Version ii
1
Document Revision History 2
3
Revision Date
Version Comments
0 March 2001 Initial Release J-STD-038
A April 12, 2001 0 Added Section 4.10 GPRS.
A May 23, 2001 1 Misc. editorial changes.
A June 26, 2001 2 New Foreword; Modifications to 4.10.2.4.
A August 01, 2001 3 Editorial changes.
A August 01, 2001 4 Editorial changes; Modifications to 4.10.2.8 SMS Impacts.
A August 14, 2001 5 Editorial changes; Modifications to 4.10 GPRS.
A August 15, 2001 6 Ballot Version; Modifications to 4.10 GPRS
4
B July 2001 3 Version 3: Addition of CDMA/GSM two way roaming
B March 2002 5 Version V&V: Addition of CDMA/GSM two way and one roaming
5
N.S0028-0
Ballot Version iii
Contents
N.S0028-0
Ballot Version iv
Abstract.............................................................................................................................................. i
Document Revision History................................................................................................................ ii
Contents........................................................................................................................................... iii
List of Tables.................................................................................................................................... vi
List of Figures.................................................................................................................................. vii
Foreword.........................................................................................................................................viii
1 Introduction .................................................................................................................................1
1.1 General 1
1.2 Purpose 1
1.3 Scope 1
1.4 Organization 2
2 References..................................................................................................................................3
3 Definitions and Acronyms............................................................................................................5
3.1 Definitions 5
3.2 Acronyms 8
4 Stage 1 Service Descriptions.....................................................................................................10
4.1 Authentication..................................................................................................................10
4.2 Call Forwarding................................................................................................................17
4.3 Optimal Routing for Late Call Forwarding.........................................................................48
4.4 Call Waiting (CW) ............................................................................................................53
4.5 Three-Way Calling (3WC) and Multi-Party (MPTY)..........................................................64
4.6 Calling Number / Line Identification Presentation..............................................................75
4.7 Call Barring (CB) and Operator Determined Barring (ODB) ..............................................81
4.8 Short Message Teleservice Support (ANSI-41 Networks).................................................89
4.9 Message Waiting Notification ...........................................................................................96
4.10 GPRS in GSM Foreign mode .........................................................................................102
Abstract.............................................................................................................................................. i
Document Revision History................................................................................................................ ii
Contents........................................................................................................................................... iii
List of Tables.....................................................................................................................................v
List of Figures................................................................................................................................... vi
Foreword......................................................................................................................................... vii
1 Introduction .................................................................................................................................1
N.S0028-0
Ballot Version v
N.S0028-0
Ballot Version vi
List of Tables
Table 1: CW Subscription Options ................................................................................................... 53
Table 2: 2-Way State for Call Waiting ............................................................................................. 56
Table 3: 2-Way Notification State for Call Waiting ........................................................................... 57
Table 4: 2-Way CW State for Call Waiting........................................................................................ 58
Table 5: ANSI-41 Foreign Mode Interoperability for Barring of Outgoing Calls .................................. 82
Table 6: GSM Foreign Mode Interoperability for Outgoing Call Restrictions...................................... 82
Table 7: Call Barring Activation Options........................................................................................... 83
Table 8: Call Barring Deactivation Options....................................................................................... 84
Table 1: CW Subscription Options ................................................................................................... 51
Table 2: 2-Way State for Call Waiting ............................................................................................. 54
Table 3: 2-Way Notification State for Call Waiting ........................................................................... 55
Table 4: 2-Way CW State for Call Waiting........................................................................................ 56
Table 5: ANSI-41 Foreign Mode Interoperability for Barring of Outgoing Calls .................................. 80
Table 6: GSM Foreign Mode Interoperability for Outgoing Call Restrictions...................................... 80
Table 7: Call Barring Activation Options........................................................................................... 81
Table 8: Call Barring Deactivation Options....................................................................................... 82
N.S0028-0
Ballot Version vii
List of Figures There are no figures in this volume.
N.S0028-0
Ballot Version viii
1
Foreword 2
This foreword is not part of this standard. 3
This standard addresses the interworking and interoperability between ANSI-41 MAP and GSM 4 based networks in the support of subscribers roaming between networks. The objective of the 5 standard is to achieve fully automatic, two-way interoperability between the heterogeneous networks. 6 Services supported by this standard are described along with the associated information flows and 7 message mappings. However, not all services and associated capabilities of ANSI-41 MAP and GSM 8 MAP are supported by this standard. In general the attempt has been to focus on the key subscriber 9 services needed in the market. 10
The focus of the first release of this standard was on common GSM and ANSI-136 TDMA services 11 and associated network signaling (i.e. ANSI-41 MAP and GSM MAP). A pre-requisite for this 12 interoperability is multi-mode mobile stations with an enhanced SIM card for roaming between ANSI-13 136, GSM, and AMPS networks. 14
The first release of the standard did not define or require changes to existing ANSI-41 MAP or GSM 15 MAP to achieve the described interworking and interoperability. However, due to differences between 16 the services and associated capabilities of the MAP protocols, complete and fully transparent 17 interoperability may not have been achieved for some services. Future releases of this standard may 18 require changes to ANSI-41 MAP, GSM MAP and the associated services to achieve full 19 transparency while roaming between the different networks. 20
Additional or alternate service descriptions, information flows, and message mappings may be 21 required to support other air interfaces supported by ANSI-41 MAP (e.g., IS-95, cdmaOne and 22 cdma2000). This may be accomplished in a future release of this standard. 23
Aspects of TIA/EIA-136 Rev C have been incorporated into this standard. 24
Revision A adds the capability of getting GPRS services when roaming in GSM Foreign Mode. 25
26
Revision B adds roaming between GSM and CDMA systems27
N.S0028-0
Ballot Version 1
1 Introduction 1
2
1.1 General 3
When a subscriber to one network type (e.g., ANSI-41) roams to a network of another type (e.g., 4 GSM), interworking and interoperability functions are required to support roaming and enable service. 5 This standard describes an Interworking and Interoperability Function (IIF) to support this cross-6 technology roaming between ANSI-41 and GSM networks. The IIF supports a multi-mode mobile 7 station with a removable Subscriber Identity Module (SIM). The standard also defines the required 8 network message mappings between ANSI-41 MAP and GSM MAP to support the mobile terminal 9 and associated services. 10
This standard includes the support of cross-technology roaming from an ANSI-41 based network to a 11 GPRS network. The GPRS network may be coupled with a GSM network. This feature requires 12 enhancement to the Interworking and Interoperability Function (IIF) which supports a multi-mode 13 mobile station and Subscriber Identity Module (SIM) with GPRS functionality. 14
15
1.2 Purpose 16
The purpose for this standard is to define and describe the functions necessary for roaming between 17 ANSI-41 MAP and GSM MAP based networks in the support of roaming subscribers. This includes a 18 capability to allow a subscriber to an ANSI-41 based network (e.g., an ANSI-136 or CDMA native 19 subscriber) with a mobile terminal supporting GPRS service to roam to a GPRS network in GSM 20 Foreign Mode. 21
22
1.3 Scope 23
The scope of this standard are the services, information flows, and message mappings which require 24 interworking and interoperability functional specifications to support roaming between ANSI-41 MAP 25 and GSM MAP networks. 26
The scope of this volume is a high level (stage 1) description of the services and functionality required 27 to support GSM and ANSI-41 network interoperability. In particular, when in foreign mode (roaming in 28 non-native mode technology), subscribers are able to: 29
� roam and register (with authentication); 30
� originate and terminate calls; 31
� have the following supplementary services operate: 32
- Call Forwarding, 33
- Call Waiting, 34
- Calling Number Identification Presentation - Line Identification Presentation, 35
- Call Barring, and 36
- GSM Multi-Party - ANSI-41 3-way Calling and Conference; 37
N.S0028-0
Ballot Version 2
� have Short Message Service access and Message Waiting Notification; 1
� have Late Call Forwarding optimally routed; and 2
� have GPRS service in GSM Foreign Mode. 3
4
1.4 Organization 5
This standard is organized into the following volumes: 6
Volume 0 - Overview and Interworking Reference Model 7
Volume 1 - Service Descriptions 8
Volume 2 - Information Flows 9
Volume 3 - Message Mappings 10
This volume 1 is organized according to the following: 11
2 References - a list of references. 12
3 Definitions and Acronyms - definions of words and acronyms. 13
4 Stage 1 Service Descriptions - descriptions of the interoperable network features. 14
15
N.S0028-0
Ballot Version 3
2 References 1
2
[1] TIA/EIA-664: “Cellular Features Description”, Telecommunications Industry Association; 3 February 2000, ANSI. 4
[2] TIA/EIA-136: “TDMA Cellular/PCS--Radio Interface--Mobile Station-Base Station Compatibility 5 Standard,” March 2000, ANSI. 6
[3] TIA/EIA-41-D: “Cellular Radiotelecommunications Intersystem Operations,” December 1997, 7 ANSI. 8
[4] TIA/EIA/IS-751, "TIA/EIA 41-D Modifications to Support IMSI, February 1998". 9
[5] TIA/EIA/IS-807, "TIA/EIA-41-D Enhancements for Internationalization". 10
[6] EIA/TIA-553: “Mobile Station – Land Station Compatibility Specification,” September 1989, 11 ANSI. 12
[7] “Common Cryptographic Algorithms, Revision C,” October 27, 1998, TR45AHAG. 13
[8] TIA/EIA-136-510 “Authentication, encryption of signaling information/user data and privacy”. 14
[9] GSM 02.04 version 6.1.1 Release 1997, “General on Supplementary Services”, (Phase 2+), 15 ETSI. 16
[10] GSM 02.09 version 6.1.0 Release 1997, “Digital cellular telecommunications system Security 17 Aspects”, (Phase 2+), ETSI. 18
[11] GSM 02.30 version 6.1.0 Release 1997, “Man-Machine Interface (MMI) of the Mobile Station”, 19 (Phase 2+), ETSI. 20
[12] GSM 02.41 version 6.0.0, Release 1997, "Operator Determined Barring (ODB)", (Phase 2+), 21 ETSI. 22
[13] GSM 02.79 version 6.0.0, Release 1997, “Support of Optimal Routeing (SOR) Service 23 Definition (Stage 1)”, (Phase 2+), ETSI. 24
[14] GSM 02.81 version 7.0.0 Release 1998, “Line Identification Supplementary Services – Stage 1“ 25 (Phase 2+), ETSI. 26
[15] GSM 02.82 version 6.0.0 Release 1997, “Call Forwarding (CF) Supplementary Services - Stage 27 1” (Phase 2+), ETSI. 28
[16] GSM 02.83 version 6.0.0 Release 1997, “Call Waiting (CW) and Call Holding (HOLD) 29 Supplementary Services - Stage 1”, (Phase 2+), ETSI. 30
[17] GSM 02.84 version 6.0.0 Release 1997, “MultiParty (MPTY) Supplementary Services – Stage 31 1”, (Phase 2+), ETSI. 32
[18] GSM 02.85 version 6.0.0 Release 1997, “Closed User Group (CUG) Supplementary Services – 33 Stage 1 ”, (Phase 2+), ETSI. 34
[19] GSM 02.86 version 6.0.0 Release 1997, “Advice of Charge (AOC) Supplementary Services – 35 Stage 1”, (Phase 2+), ETSI. 36
[20] GSM 02.88 version 6.0.0 Release 1997, “Call Barring (CB) Supplementary Services – Stage 1” 37 (Phase 2+), ETSI. 38
N.S0028-0
Ballot Version 4
[21] GSM 09.02 version 6.2.0 Release 1997, “Digital cellular communication system (Phase2+); 1 Mobile Application Part (MAP) specification”, August 1998, ETSI 2
[22] GSM 02.60 version 6.3.1 Release 1997 “General Packet Radio Service (GPRS); Service 3 Description, Stage 1 4
[23] TIA/EIA/IS 737A”IS-41 support for data services for digital terminals (TDMA and CDMA)” 5
[24] TIA/EIA/IS 735 “IS-41 support for IS-95-A (advanced CDMA)” 6
[25] TIA/EIA/TSB58-E “Administration of Parameter Value Assignments for TIA/EIA Spread 7 Spectrum Standards” , January 2002 8
[26] TIA/EIA-95-B - Mobile Station-Base Station Compatibility Standard for Dual-Mode Spread 9 Spectrum Systems; Published October 1998. 10 11 [27] "TIA/EIA-IS-2000-A, cdma2000 Series, March 2000, plus addenda"Mobile Station-Base Station 12 Compatibility Standard for Dual-Mode Spread Spectrum Systems; 13 [28] TIA/EIA-868 – ANSI-41-D Network Based Enhancements to support one-way roaming to 14 GSM, Published TBD. [12]"Enhanced Cryptographic Algorithms, Revision B," TR45AHAG, Published TBD 15
16
17
N.S0028-0
Ballot Version 5
3 Definitions and Acronyms 1
2
3.1 Definitions 3
AMPS 4 5 Advanced Mobile Phone Service (AMPS) is the same as ANSI EIA/TIA-553[6], which as an analog air 6 interface protocol standard for mobile stations and their associated base stations. AMPS networks 7 use ANSI-41 for intersystem signaling. 8 9 ANSI-41 10 11 ANSI-41, as used in this document, refers to TIA/EIA-41[3] and the modifications and enhancements 12 as noted in IS-751[4] and IS-807[5]. This is a network protocol standard to support intersystem 13 operation of cellular networks, such as ANSI-136 or CDMA networks. Key intersystem support 14 defined by ANSI-41 includes automatic roaming, intersystem handoff, and intersystem operation, 15 administration, and maintenance. Among other things, ANSI-41 defines the interfaces between 16 MSCs, between the MSC/VLR and the HLR/AC, and between the MSC and the Short Message 17 Service Center (SMS-C) or Teleservice Server (TS). 18 19 ANSI-136 20 21 ANSI-136, as used in this document, refers to TIA/EIA-136[2], which is a TDMA air interface protocol 22 standard for mobile stations and their associated base stations. ANSI-136 is a dual-mode standard 23 that includes digital (TDMA) operation at 800 MHz and 1900 MHz, and analog (AMPS) operation at 24 800 MHz. ANSI-136 networks use ANSI-41 for intersystem signaling. 25 26 ANSI-136 Mode 27 28 ANSI-136 mode indicates the condition or state of a mobile station accessing an ANSI-136 network. 29 30 ANSI-136 Foreign Mode 31 32 ANSI-136 foreign mode indicates the condition or state of a GSM native subscriber accessing an 33 ANSI-136 network. 34 35 ANSI-136 Native Mode 36 37 ANSI-136 native mode indicates the condition or state of an ANSI-136 native subscriber accessing an 38 ANSI-136 network. 39 40 ANSI-136 Native Subscriber 41 42 ANSI-136 native subscriber indicates an end user whose primary or home subscription resides in an 43 ANSI-136 network. These subscribers include both home subscribers from the ANSI-136 network, as 44 well as roamers from other ANSI-136 networks. 45 46 ANSI-41 Foreign Mode 47 48 ANSI-41 foreign mode indicates the condition or state of a GSM native subscriber accessing an 49 ANSI-41 based network. 50
N.S0028-0
Ballot Version 6
1 2 3 GSM 4 5 Global System for Mobile Communications (GSM) defines both air interface and network intersystem 6 protocol standards for mobile stations (MS), base station systems (BSS), and network switching 7 systems (NSS). 8 9 GSM CS attached 10
GSM circuit-switched services attached means that the subscriber is attached to a GSM MSC. This is 11 also referred to as IMSI attached. 12
GSM CS detached 13
GSM circuit-switched services detached means that the subscriber is detached from a GSM MSC. 14 This is also referred to as IMSI detached. 15 16 GSM Foreign Mode 17 18 GSM foreign mode indicates the condition or state of an ANSI-136 ANSI-41 native subscriber 19 accessing a GSM network. 20 21 22 GPRS HLR 23
General Packet Radio Service Home Location Register is the HLR responsible for GPRS functions. It 24 interfaces with the SGSN and GGSN and Authentication Center. 25 26 GSM Mode 27 28 GSM mode indicates the condition or state of a mobile station accessing a GSM network. 29 30 GSM Native Mode 31 32 GSM native mode indicates the condition or state of a GSM native subscriber accessing a GSM 33 network. 34 35 GSM Native Subscriber 36 37 GSM native subscriber indicates an end user whose primary or home subscription resides in a GSM 38 network. These subscribers include both home subscribers from the GSM network, as well as 39 roamers from other GSM networks. 40 41 CDMA 42 43 CDMA as used in this document, refers to TIA/EIA -95 [9] or TIA/EIA-2000 [10], which is a CDMA 44 air interface protocol standard for mobile stations and their associated base stations. CDMA is a 45 dual-mode standard that includes digital (CDMA) operation and analog (AMPS) operation. CDMA 46 networks use ANSI-41 for intersystem signaling. 47
CDMA Mode 48
CDMA mode indicates the condition or state of a mobile station accessing an CDMA network. 49 50 51
N.S0028-0
Ballot Version 7
CDMA Foreign Mode 1 CDMA foreign mode indicates the condition or state of a GSM native subscriber accessing a CDMA 2 network. 3 4 CDMA Native Mode 5 CDMA native mode indicates the condition or state of an CDMA native subscriber accessing an 6 CDMA network. 7 8 CDMA Native Subscriber 9 CDMA native subscriber indicates an end user whose primary or home subscription resides in an 10 CDMA network. These subscribers include both home subscribers from the CDMA network, as 11 well as roamers from other CDMA networks. 12 13 GPRS in GSM Foreign Mode 14
GPRS in GSM Foreign Mode is a subset of GSM Foreign Mode and indicates the condition or state of 15 an ANSI-136 41 native subscriber accessing a GPRS network; the GPRS network may be coupled 16 with a GSM network. 17 18 Late Call Forwarding 19 20 Call Forwarding invoked after the call has been offered to the terminating VMSC (e.g., CFB, 21 CFNA/CFNRy, CFNRc) . 22 23 Mobile Equipment 24 25 The radio transceiver, main processing unit, and man-machine interface necessary to access the 26 radio network. 27
Mobile Station 28 29 The mobile equipment and the SIM together make up the mobile station, which is the wireless 30 radiotelephone used by the subscriber. 31 32 Subscriber Identity Module 33 34 A smart card that plugs into the mobile equipment and that contains the authentication algorithms, 35 and stores service-oriented subscription information. 36
37
38
39
N.S0028-0
Ballot Version 8
3.2 Acronyms 1
AC Authentication Center in ANSI TIA/EIA-41 based networks 2
AuC Authentication Center in GSM networks 3
AMPS Advanced Mobile Phone Service 4
ANSI American National Standards Institute 5
BAIC Barring of All Incoming Calls 6
BAOC Barring of All Outgoing Calls 7
BIC-Roam Barring of Incoming Calls while Roaming Outside HPLMN Country 8
BMI Base Station, Mobile Switching System, and Interworking Function 9
BOIC Barring of Outgoing International Calls 10
BOIC-exHC Baring of Outgoing International Calls Except to HPLMN Country 11
CDMA Code-Division Multiple Access 12
CFB Call Forwarding Busy 13
CFNA Call Forwarding No Answer 14
CFNRc Call Forwarding Not Reachable 15
CFNRy Call Forwarding No Reply 16
CS Circuit-Switched 17
EDGE Enhanced Data Rates Through Global Evolution 18
EIA Electronics Industry Association 19
ESN Electronic Serial Number 20
ETSI European Telecommunications Standards Institute 21
FC Feature Code 22
FSM GSM Forward Short Message 23
GGSN Gateway GPRS Support Node 24
GPRS General Packet Radio Service 25
GSM Global System for Mobile Communications 26
HLR Home Location Register 27
HPLMN Home Public Land Mobile Network 28
IIF Interworking and Interoperability Function 29
IMSI International Mobile Subscriber Identity 30
ITU International Telecommunications Union 31
MAP Mobile Application Part 32
N.S0028-0
Ballot Version 9
MC ANSI-41136 Message Center (for SMS) 1
ME Mobile Equipment 2
MO Mobile Originated 3
MS Mobile Station 4
MSC Mobile Switching Center 5
MT Mobile Terminated 6
MWN Message Waiting Notification 7
ODB Operator Determined Barring 8
OTA Over-the-Air Activation 9
PCS Personal Communications Service 10
PIN Personal Identification Number 11
PLMN Public Land Mobile Network 12
SGSN Serving GPRS Support Node 13
SID System Identity 14
SIM Subscriber Identity Module 15
SMDPP ANSI-41 SMS message 16
SMS Short Message Service 17
SMS-C GSM Short Message Service Center 18
TDMA Time Division Multiple Access 19
TIA Telecommunications Industry Association 20
UWCC Universal Wireless Communications Consortium 21
VLR Visitor Location Register 22
VPLMN Visitor Public Land Mobile Network 23
24
N.S0028-0
Ballot Version 10
4 Stage 1 Service Descriptions 1
When in foreign mode (e.g., GSM or ANSI-136 ANSI-41 subscribers accessing respectively ANSI-2 41136 or GSM networks), subscribers are able: 3
� to roam and register (with authentication) 4
� to originate and terminate calls 5
� to have the following supplementary services operate: 6
o Call Forwarding, 7
o Call Waiting, Calling Number/Line Identification Presentation, 8
o Call Barring, and 9
o GSM Multi-Party - ANSI-41 3-way Calling and Conference; 10
� to have short message service and Message Waiting Notification; and 11
� to have late call forwarding optimally routed. 12
4.1 Authentication 13
Authentication defines the ability for a wireless network to confirm the identity of a mobile station at 14 the time of connection, and to ensure the validity of this identity during the complete connection time. 15 This is achieved through the use of cryptographic schemes based on secret key algorithms. 16
4.1.1 General Description 17
The authentication procedure starts based on network events received by the mobile station. These 18 events include mobile station origination, termination, registration and R-DATA messages in ANSI-41 19 TDMA or CDMA-136. These events are dependent of the technology used and are different in GSM 20 and ANSI-136. The authentication procedure involves an authentication center on the network side 21 and an authentication module in the mobile station. It is initiated by a random number sent from the 22 authentication center to the authentication module. The authentication module uses this random 23 value and a combination of secret data and internal values to create an authentication value and a 24 key that is optionally used for encryption. This authentication value is sent back to the authentication 25 center, which verifies its validity by computing it again based on the same input. A successful 26 outcome of the authentication process occurs only when it can be demonstrated that the 27 authentication 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 no 29 data is provisioned at IIF level, IIF must generate the GSM triplets using as input the authentication 30 parameters returned by ANSI-41 HLR/AC, and ANSI-41 HLR/AC must be compliant with PN-4925 (to 31 be published as TIA/EIA-868 [28]. All the changes are made on the assumption the new requirements 32 for UIM/handsets are working. 33
4.1.1.1 Applicability to Telecommunications Services 34
Not identified. 35
36
N.S0028-0
Ballot Version 11
1
4.1.2 Normal Procedures With Successful Outcome 2
In ANSI-41136 native and foreign mode, the authentication procedure is done according to the 3 procedures defined in TIA/EIA-136-510 [8] for TDMA or according to TIA/EIA-95 for a CDMA.. 4
In GSM native and foreign mode, the authentication procedure is done according to the procedures 5 defined in GSM 02.09 [10]. 6
ANSI-136 Mode 7
The ANSI-136 authentication module is defined by the ANSI-136 directory. It holds the secret data 8 and internal values used during the authentication process. 9
The secret data used in the ANSI-136 authentication process is the shared secret data (SSD). The 10 internal values used within the ANSI-136 authentication process are the ESN, the MIN1 and the 11 MIN2. 12
CDMA Mode 13
The secret data used in the CDMA authentication process is the shared secret data (SSD). The 14 internal values used within the CDMA authentication process are the ESN, and the IMSI. 15 Authentication on IMSI is done in a CDMA mobile according to the IS-95 specification by extracting 16 10 digits from the IMSI. (IMSI_S). 17
ANSI-41 Mode 18
The ANSI-41 authentication module is defined by the air-interface specific directory in the mobile 19 station. The data used for authentication is as define by the Common Cryphtograpic Algorithm 20 (CAVE)add reference). 21
22
23
GSM Mode 24
The GSM authentication module is defined by the GSM directory in the SIM. The SIM card can 25 support multiple GSM subscriptions and each one has its own authentication module. 26
The secret data used in the GSM authentication process is the Ki. There is no internal data used in 27 the GSM authentication process. 28
4.1.2.1 Authorization (or Provision) 29
In GSM mode, the secret data (Ki) is stored in advance in the network’s Authentication Center (AuC) 30 as well as the SIM’s authentication module at the time of personalization of the SIM. This secret data 31 on the SIM cannot be modified after the issuance of the SIM. 32
In ANSI mode, the secret data (A-key) is stored in advance in the network’s Authentication Center 33 (AC) as well as the mobile’s station authentication module at the time of provisioning. This secret data 34 maybe overwritten with a new value via reprovisioning or over the air parameter administration 35
In ANSI-13641, the shared secret data (SSD) is generated from a root secret data (A-Key). This root 36 secret data is stored in advance in the authentication module and can be modified after issuance. The 37 generation of the secret data is done by the authentication center issuing an SSD UPDATE request 38 with the appropriate parameters. 39
N.S0028-0
Ballot Version 12
4.1.2.2 De-Authorization (or Withdrawal) 1
The de-authorization is done at the Authentication Center. 2
4.1.2.3 Registration 3
None identified. 4
4.1.2.4 De-Registration (or Erasure) 5
None identified. 6
4.1.2.5 Activation 7
Activation is performed by the operator or serving system. 8
4.1.2.6 De-Activation 9
De-activation is performed by the operator or serving system. 10
4.1.2.7 Invocation 11
The authentication function is invoked in the mobile station by selecting the appropriate directory 12 (GSM or ANSI-41136) on the authentication module and sending the appropriate command (RUN 13 AUTH ALGO or RUN CAVE)command, with the appropriate parameters (random value, option flag, 14 internal values). The authentication function is invoked in the network by the receipt of an 15 authentication message from the mobile station. 16
4.1.2.8 Normal Operation with Successful Outcome 17
If the Authentication Signature result calculated by the mobile station and sent to the BMI (Base 18 Station, Mobile Switching Center, Interworking Function) matches the result calculated by the BMI 19 then call processing and feature access is allowed by the BMI. 20
4.1.3 Exception Procedures or Unsuccessful Outcome 21
In the event that the mobile station cannot provide the correct Authentication Signature result to the 22 BMI then call processing and feature access is may be denied not allowed by the BMI. 23
4.1.3.1 Registration 24
None identified. 25
4.1.3.2 De-Registration / Erasure 26
None identified. 27
4.1.3.3 Activation 28
None identified. 29
4.1.3.4 De-Activation 30
None identified. 31
4.1.3.5 Invocation 32
N.S0028-0
Ballot Version 13
None identified. 1
4.1.3.6 Exceptions While Roaming 2
None identified. 3
4.1.3.7 Exceptions During Intersystem Handoff 4
None identified. 5
4.1.4 Alternate Procedures 6
None identified. 7
8
4.1.5 Interactions With Other Features and Services 9
10
4.1.5.1 Advice of charge (AoC) 11
None identified. 12
4.1.5.2 Barring of All Outgoing Calls (BAOC) 13
None identified. 14
4.1.5.3 Barring of Outgoing International Calls (BOIC) 15
None identified. 16
4.1.5.4 Barring of Outgoing International Calls except those directed to the Home PLMN 17 (BOIC-exHC) 18
None identified. 19
4.1.5.5 Barring of All Incoming Calls (BAIC) 20
None identified. 21
4.1.5.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam) 22
None identified. 23
4.1.5.7 Call Delivery (CD) 24
If the Authentication Signature result at the mobile station does not match that of the BMI then Call 25 Delivery shall not be allowed. 26
4.1.5.8 Call Forwarding—Busy (CFB) 27
None identified. 28
4.1.5.9 Call Forwarding—Default (CFD) 29
N.S0028-0
Ballot Version 14
None identified. 1
4.1.5.10 Call Forwarding—No Answer / No Reply (CFNA / CFNRy) 2
None identified. 3
4.1.5.11 Call Forwarding—Not Reachable (CFNRc) 4
None identified. 5
4.1.5.12 Call Forwarding—Unconditional (CFU) 6
None identified. 7
4.1.5.13 Call Transfer (CT) 8
None identified. 9
4.1.5.14 Call Waiting / Call Hold (CW / HOLD) 10
None identified. 11
4.1.5.15 Calling Number / Line Identification Presentation (CNIP / CLIP) 12
None identified. 13
4.1.5.16 Calling Number / Line Identification Restriction (CNIR / CLIR) 14
None identified. 15
4.1.5.17 Calling Name Presentation (CNAP) 16
None identified. 17
4.1.5.18 Calling Name Restriction (CNAR) 18
None identified. 19
4.1.5.19 Closed User Group (CUG) 20
None identified. 21
4.1.5.20 Conference Calling / Multi Party Service (CC / MPTY) 22
A special challenge shall be made to the mobile station by the BMI in order to activate this feature. If 23 the Authentication Signature result at the mobile station does not match that of the BMI then this 24 feature shall not be allowed. 25
4.1.5.21 Do Not Disturb (DND) 26
None identified. 27
4.1.5.22 Emergency Services (Future) 28
None identified. 29
N.S0028-0
Ballot Version 15
4.1.5.23 Flexible Alerting (FA) 1
None identified. 2
4.1.5.24 Message Waiting Notification (MWN) 3
None identified. 4
4.1.5.25 Mobile Access Hunting (MAH) 5
None identified. 6
4.1.5.26 Password Call Acceptance (PCA) 7
None identified. 8
4.1.5.27 Preferred Language (PL) 9
None identified. 10
4.1.5.28 Priority Access and Channel Assignment (PACA) 11
None identified. 12
4.1.5.29 Remote Feature Control (RFC) 13
None identified. 14
4.1.5.30 Selective Call Acceptance (SCA) 15
None identified. 16
4.1.5.31 Subscriber PIN Access (SPINA) 17
The Authentication Feature shall take precedence over the SPINA feature. 18
4.1.5.32 Subscriber PIN Intercept (SPINI) 19
The Authentication Feature shall take precedence over the SPINI feature. 20
4.1.5.33 Three-Way Calling / Multi Party Service (3WC / MPTY) 21
A special challenge shall be made to the mobile station by the BMI in order to activate this feature. If 22 the Authentication Signature result at the mobile station does not match that of the BMI then this 23 feature shall not be allowed. 24
4.1.5.34 Voice Message Retrieval (VMR) 25
If this feature requires the mobile station to originate a call from the mobile station and the 26 Authentication Signature result at the mobile station does not match that of the BMI then this feature 27 shall not be allowed. 28
4.1.5.35 Voice Privacy (VP) 29
N.S0028-0
Ballot Version 16
The Voice Privacy elements (e.g., for ANSI-41136 ,TDMA or CDMA) are derived from the same 1 secret A-Key as for the Authentication algorithm. If the HLR/AC for the mobile subscriber does not 2 have knowledge of this information it shall not be able to activate the Voice Privacy feature. 3
N.S0028-0
Ballot Version 17
4.2 Call Forwarding 1
2
4.2.1 General Description 3
Call Forwarding, permits a called subscriber to have the system send incoming calls addressed to the 4 called subscriber’s Directory Number to another Directory Number (forward-to number) under certain 5 conditions (e.g., busy, not reachable, or no reply). 6
GSM 02.82[15] 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[1] 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
17
N.S0028-0
Ballot Version 18
4.2.2 Call Forwarding Unconditional (CFU) 1
2
4.2.2.1 General Description 3
Call Forwarding—Unconditional (CFU) permits a called subscriber to send incoming calls addressed 4 to the called subscriber’s Directory Number to another Directory Number (forward-to number) or to 5 the called subscriber’s designated voice mail box. 6
4.2.2.1.1 Applicability to Telecommunications Services 7
CFU is applicable to voice telecommunication services. 8
9
4.2.2.2 Normal Procedures With Successful Outcome 10
11
4.2.2.2.1 Authorization (or Provision) 12
CFU may be generally available or may be provided after pre-arrangement with the service provider. 13 The authorization (provision) may have subscription options. These options are defined in either 14 GSM 02.82[15] (i.e., GSM native mode subscribers) or ANSI-664[1] (e.g., ANSI-41,TDMA136 or 15 CDMA native mode subscribers). Authorization or Provisioning may occur while operating in foreign 16 mode. 17
4.2.2.2.2 De-Authorization (or Withdrawal) 18
CFU may be withdrawn by the service provider, at the subscriber’s request or for administrative 19 reasons. De-authorization or withdrawal may occur while operating in foreign mode. 20
4.2.2.2.3 Registration 21
If the subscriber is authorized for Fixed Registration, the forward-to number shall be registered upon 22 authorization (provision). Mobile stations operating in foreign mode may attempt to perform 23 registration procedures normally supported in native mode. 24
The forward-to-number may be registered by the service provider upon authorization (provision) for 25 Variable Registration subscribers 26
GSM foreign mode: A forward-to-number may be registered by a Variable Registration authorized 27 subscriber specifying the CFU registration feature code and a forward-to number termination address 28 as in: 29
* FC + termination address + SEND . 30
Alternatively, if the mobile station offers menu driven control of registration, the mobile station is 31 expected to generate the equivalent GSM functional signaling towards the network. 32
ANSI-41 foreign mode: Registration can take place with an appropriate control procedure by the 33 subscriber, per GSM 02.30[11]. In ANSI-41 foreign mode, if the equivalent GSM feature code (MMI) 34 is manually entered by the user, the mobile station is expected to issue the relevant ANSI-13641 35 feature code entry. 36
N.S0028-0
Ballot Version 19
Alternatively, if the mobile station offers menu driven control of registration, the mobile station is 1 expected to generate the equivalent ANSI-13641 feature code entry and resulting call origination 2 based on the menu driven entry. 3
If the registration is accepted, the system shall indicate success using either GSM or ANSI-13641 4 signaling techniques depending on the mode of operation. 5
4.2.2.2.4 De-Registration (or Erasure) 6
Mobile stations operating in foreign mode may attempt to perform De-Registration or Erasure 7 procedures normally supported in native mode. 8
A forward-to-number may be de-registered upon de-activation (at the home service provider option). 9
GSM foreign mode: If the de-registration is to be separate from de-activation, the de-registration 10 feature code must be distinct from the corresponding de-activation feature code. 11
GSM foreign mode: CFU may be de-registered by a Variable Registration authorized subscriber 12 specifying the CFU de-registration feature code, as in: 13
* FC0 + SEND . 14
Alternatively, if the mobile station offers menu driven control of registration, the mobile station is 15 expected to generate the equivalent GSM functional signaling towards the network. 16
ANSI-41 foreign mode: The subscriber can specifically erase a previous registration with an 17 appropriate control procedure, per GSM 02.30[11]. In ANSI-41 foreign mode, if the equivalent GSM 18 feature code (MMI) is manually entered by the user, the mobile station is expected to issue the 19 necessary ANSI-13641 feature code to the network. 20
CFU shall be de-registered upon de-authorization or withdrawal. 21
4.2.2.2.5 Activation 22
Mobile stations operating in foreign mode may attempt to perform Activation procedures normally 23 supported in native mode. 24
If the subscriber is authorized for Permanent Activation, CFU shall be activated upon authorization 25 (provision). 26
CFU may be activated upon authorization or registration for Demand Activation authorized 27 subscribers. CFU may be activated upon registration for Variable Registration authorized subscribers. 28
GSM foreign mode: A previously registered forward-to-number may be activated by a Demand 29 Activation authorized subscriber specifying a CFU activation feature code, as in: 30
* FC + SEND . 31
Alternatively, if the mobile station offers menu driven control of activation, the mobile station is 32 expected to generate the equivalent GSM functional signaling. 33
ANSI-41 foreign mode: The MS shall be allowed to activate CFU by a control procedure (e.g., using 34 the MMI command described in GSM 02.30[11]). In ANSI-41 foreign mode, if the equivalent GSM 35 feature code (MMI) is manually entered by the user, the mobile station is expected to issue the 36 necessary ANSI-13641 feature code to the network. 37
If the activation is accepted, the system shall indicate success using either GSM or ANSI-13641 38 signaling techniques depending on the mode of operation. 39
N.S0028-0
Ballot Version 20
The serving system may provide a courtesy call to the forward-to number shortly after this feature is 1 activated permitting the subscriber to verify the validity of the forward-to-number. 2
4.2.2.2.6 De-Activation 3
GSM foreign mode: CFU may be de-activated by a Demand Activation authorized subscriber 4 specifying the CFB de-activation feature code, as in: 5
* FC0 + SEND . 6
Alternatively, if the mobile station offers menu driven control of de-activation, the mobile station is 7 expected to generate the equivalent GSM functional signaling. 8
ANSI-41 foreign mode: The user may deactivate CFU by means of an appropriate control procedure 9 (e.g., as described in GSM 02.30[11]). In ANSI-41 foreign mode, if the equivalent GSM feature code 10 (MMI) is manually entered by the user, the mobile station is expected to issue the necessary ANSI-11 13641 feature code to the network. 12
If the de-activation is accepted, the system shall indicate success using either GSM or ANSI-13641 13 signaling techniques depending on the mode of operation. Registered information shall not be 14 erased. 15
CFU shall be de-activated upon de-authorization (withdrawal) or de-registration (erasure). 16
4.2.2.2.7 Invocation 17
The feature treatment is invoked unconditionally when there is an incoming call and CFU is active. 18
4.2.2.3 Normal Operation with Successful Outcome 19
When CFU is active, incoming calls for the subscriber shall be forwarded unconditionally to the 20 forward-to number. 21
GSM Foreign Mode: When an incoming call is forwarded unconditionally the forward-to-party shall 22 receive a notification that the call has been forwarded. The calling party may also receive a 23 notification that the call has been forwarded. 24
ANSI-41 foreign mode: When an incoming call is forwarded unconditionally the served mobile 25 subscriber may receive a notification that the call has been forwarded. 26
4.2.2.3.1 Call Detail Record / Charging Requirements 27
For GSM and ANSI-41 based network interoperability, no new or special recording capabilities are 28 needed. 29
30
N.S0028-0
Ballot Version 21
1
4.2.2.4 Exception Procedures or Unsuccessful Outcome 2
3
4.2.2.4.1 Registration 4
If the system cannot accept a registration request, the served mobile subscriber shall receive a 5 notification that registration of call forwarding unconditional was not successful. Possible causes are: 6
� service not subscribed to; 7
� forward-to number is invalid directory number; 8
� use of an operator access prefix; 9
� insufficient information; 10
� forward-to number is a special service code (e.g., police); 11
� forward-to number is the directory number of the mobile subscriber herself. 12
4.2.2.4.2 De-Registration (Erasure) 13
If the subscriber is not authorized for the request, the system shall apply feature denial treatment 14 when de-registration is attempted. 15
4.2.2.4.3 Activation 16
If the subscriber is not authorized for the request, or if a forward-to-number is not properly registered, 17 the system shall apply feature denial treatment when activation is attempted. 18
4.2.2.4.4 De-Activation 19
If the subscriber is not authorized for the request, the system shall apply feature denial treatment 20 when de-activation is attempted. 21
4.2.2.4.5 Invocation 22
If the forwarded call cannot be routed to the forward-to-destination, then the call shall be given the 23 appropriate treatment, such as applying the Special Information Tone for intercept to the calling party. 24
Precautions shall be taken to preclude undesirable looping of forwarded numbers within the MSC or 25 between the MSC and other switching centers. If such looping is detected, the call forwarding shall be 26 given the appropriate treatment, such as applying the Special Information Tone for intercept to the 27 calling party. 28
4.2.2.4.6 Exceptions While Roaming 29
None identified. 30
4.2.2.4.7 Exceptions During Intersystem Handoff 31
None identified. 32
4.2.2.5 Alternate Procedures 33
N.S0028-0
Ballot Version 22
None identified. 1
4.2.2.6 Interactions With Other Features and Services 2
3
4.2.2.6.1 Advice of charge (AoC) 4
See GSM 02.86[19]. 5
4.2.2.6.2 Barring of All Outgoing Calls (BAOC) 6
None identified at this time.. 7
4.2.2.6.3 Barring of Outgoing International Calls (BOIC) 8
None identified at this time.. 9
4.2.2.6.4 Barring of Outgoing International Calls except those directed to the Home PLMN 10 (BOIC-exHC) 11
None identified at this time. 12
4.2.2.6.5 Barring of All Incoming Calls (BAIC) 13
None identified at this time. 14
4.2.2.6.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam) 15
None identified at this time. 16
4.2.2.6.7 Call Delivery (CD) 17
CFU takes precedence over CD. That is, calls arriving when CFU is active are forwarded 18 unconditionally and not given CD treatment. 19
4.2.2.6.8 Call Forwarding—Busy (CFB) 20
CFU takes precedence over CFB. That is, calls arriving when CFU is active shall be forwarded 21 unconditionally and not given CFB treatment 22
4.2.2.6.9 Call Forwarding—Default (CFD) 23
CFU takes precedence over CFD. That is, calls arriving when CFU is active shall be forwarded 24 unconditionally and not given CFD treatment. 25
4.2.2.6.10 Call Forwarding—No Answer / No Reply /Not Reachable (CFNA / CFNRy/CFNRc) 26
CFU takes precedence over CFNA/CFNRy/CFNRc. That is, an incoming call arriving for a subscriber 27 with both CFU and CFNA/CFNRy/CFNRc active shall be forwarded with CFU. 28
4.2.2.6.11 Call Transfer (CT) 29
None identified. 30
N.S0028-0
Ballot Version 23
4.2.2.6.12 Call Waiting / Call Hold (CW / HOLD) 1
CFU takes precedence over CW. That is, calls arriving when CFU is active shall be forwarded 2 unconditionally and not given CW treatment. 3
4.2.2.6.13 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 / CLIP 5 supplementary service, the forward-to user shall receive the number of the original calling user, if this 6 calling user has not subscribed to or invoked the CNIR / CLIR supplementary service. 7
4.2.2.6.14 Calling Number / Line Identification Restriction (CNIR / CLIR) 8
If the calling number indicates presentation restricted, the calling number shall not be presented to 9 the called party or the forward-to-party. 10
If the called (redirecting) subscriber has CFU active and CNIR is either Permanently Restricted or the 11 default is Presentation Restricted, the redirecting number shall indicate presentation restricted to 12 prevent presentation to the forward-to-party or to the forward-to station. 13
4.2.2.6.15 Calling Name Presentation (CNAP) 14
When a call has been forwarded and the forward-to-party has been provided with the CNAP 15 supplementary service, the forward-to user shall receive the name of the original calling user, if this 16 calling user has not subscribed to or invoked the CNAR or CNIR / CLIR supplementary service. 17
4.2.2.6.16 Calling Name Restriction (CNAR) 18
If the calling name or number indicates presentation restricted, the calling name or number shall not 19 be presented to the called party or the forward-to-party. 20
If the called (redirecting) subscriber has CFU active and CNAR or CNIR is either Permanently 21 Restricted, or the default is Presentation Restricted, the redirecting name shall indicate presentation 22 restricted to prevent presentation to the forward-to-party. 23
4.2.2.6.17 Closed User Group (CUG) 24
See GSM 02.85[18]. 25
4.2.2.6.18 Conference Calling / Multi Party Service (CC / MPTY) 26
None identified. 27
4.2.2.6.19 Do Not Disturb (DND) 28
None identified at this time. 29
4.2.2.6.20 Emergency Services (Future) 30
None identified at this time. 31
4.2.2.6.21 Flexible Alerting (FA) 32
None identified at this time. 33
4.2.2.6.22 Message Waiting Notification (MWN) 34
N.S0028-0
Ballot Version 24
None identified. 1
4.2.2.6.23 Mobile Access Hunting (MAH) 2
None identified at this time. 3
4.2.2.6.24 Password Call Acceptance (PCA) 4
None identified at this time. 5
4.2.2.6.25 Preferred Language (PL) 6
None identified. 7
4.2.2.6.26 Priority Access and Channel Assignment (PACA) 8
None identified at this time. 9
4.2.2.6.27 Remote Feature Control (RFC) 10
CFU Registration shall be allowed via RFC in ANSI-41136 mode, or via functional messaging in GSM 11 mode. 12
4.2.2.6.28 Selective Call Acceptance (SCA) 13
None identified at this time. 14
4.2.2.6.29 Subscriber PIN Access (SPINA) 15
None identified at this time. 16
4.2.2.6.30 Subscriber PIN Intercept (SPINI) 17
None identified. 18
4.2.2.6.31 Three-Way Calling / Multi Party Service (3WC / MPTY) 19
None identified. 20
4.2.2.6.32 Voice Message Retrieval (VMR) 21
None identified. 22
4.2.2.6.33 Voice Privacy (VP) 23
None identified. 24
25
N.S0028-0
Ballot Version 25
4.2.3 Call Forwarding - Busy (CFB) 1
2
4.2.3.1 General Description 3
Call Forwarding—Busy (CFB) permits a called subscriber to have the system send incoming calls 4 addressed to the called subscriber’s Directory Number to another Directory Number (forward-to 5 number) or to the called subscriber’s designated voice mail box, when the subscriber is engaged in a 6 call or service. CFB does not impact a subscriber’s ability to originate calls. 7
4.2.3.1.1 Applicability to Telecommunications Services 8
CFB is applicable to voice telecommunications services. 9
4.2.3.2 Normal Procedures With Successful Outcome 10
11
4.2.3.2.1 Authorization (or Provision) 12
CFB may be generally available or may be provided after pre-arrangement with the service provider. 13 The authorization (provision) may have the subscription options. These options are defined in either 14 GSM 02.82[15] (i.e., GSM native mode subscribers) or ANSI-664[1] (e.g., ANSI-41,TDMA136 or 15 CDMA native mode subscribers). Authorization or Provisioning may occur while operating in foreign 16 mode. 17
4.2.3.2.2 De-Authorization (or Withdrawal) 18
CFB may be withdrawn at the subscriber’s request or for administrative reasons. De-authorization or 19 withdrawal may occur while operating in foreign mode. 20
4.2.3.2.3 Registration 21
If the subscriber is authorized for Fixed Registration, the forward-to number shall be registered upon 22 authorization (provision). 23
The CFB forward-to number may be registered by the service provider upon authorization (provision) 24 for Variable Registration subscribers. Mobile stations operating in foreign mode may attempt to 25 perform registration procedures normally supported in native mode. 26
GSM foreign mode: A forward-to-number may be registered by a Variable Registration authorized 27 subscriber specifying the CFB registration feature code and a forward-to number termination address 28 as in: 29
* FC + termination address + SEND .Alternatively, if the mobile station offers menu driven control 30
of registration, the mobile station is expected to generate the equivalent GSM functional signaling 31 towards the network. 32
ANSI-41 foreign mode: Registration may take place with an appropriate control procedure by the 33 subscriber, per GSM 02.30[11]. In ANSI-41 foreign mode, if the equivalent GSM mode feature code 34 (MMI) is manually entered by the user, the mobile station is expected to issue the relevant ANSI-35 13641 feature code entry. 36
N.S0028-0
Ballot Version 26
Alternatively, if the mobile station offers menu driven control of registration, the mobile station is 1 expected to generate the equivalent ANSI-13641 feature code entry and resulting call origination 2 based on the menu driven entry. 3
If the registration is accepted, the system shall indicate success using either GSM or ANSI-13641 4 signaling techniques depending on the mode of operation. 5
4.2.3.2.4 De-Registration (or Erasure) 6
Mobile stations operating in foreign mode may attempt to perform De-Registration or Erasure 7 procedures normally supported in native mode. 8
Forward-to numbers may be de-registered upon de-activation (at the home service provider option). 9
GSM foreign mode: If the de-registration is to be separate from de-activation, the de-registration 10 feature code must be distinct from the corresponding de-activation feature code. 11
GSM foreign mode: CFB may be de-registered by a Variable Registration authorized subscriber 12 specifying the CFB de-registration feature code, as in: 13
* FC0 + SEND . 14
Alternatively, if the mobile station offers menu driven control of registration, the mobile station is 15 expected to generate the GSM functional signaling towards the network. 16
ANSI-41 foreign mode: The subscriber can specifically erase a previous registration with an 17 appropriate control procedure, per GSM 02.30[11]. In ANSI-41 foreign mode, if the equivalent GSM 18 mode feature code is manually entered by the user, the mobile station is expected to issue the 19 necessary ANSI-13641 feature code to the network. 20
CFB shall be de-registered upon de-authorization or withdrawal. 21
4.2.3.2.5 Activation 22
Mobile stations operating in foreign mode may attempt to perform Activation procedures normally 23 supported in native mode. 24
If the subscriber is authorized for Permanent Activation, CFB shall be activated upon authorization 25 (provision). 26
CFB may be activated upon registration for Demand Activation authorized subscribers. CFB may be 27 activated upon registration for Variable Registration authorized subscribers. 28
GSM foreign mode: A previously registered forward-to number may be activated by a Demand 29 Activation authorized subscriber specifying a CFB activation feature code, as in: 30
* FC + SEND . 31
Alternatively, if the mobile station offers menu driven control of activation, the mobile station is 32 expected to generate the equivalent GSM functional signaling. 33
ANSI-41 foreign mode: The MS shall be allowed to activate CFB by for example using the MMI 34 command described in GSM 02.30[11]. In ANSI-41 foreign mode, if the equivalent GSM mode feature 35 code (MMI) is manually entered by the user, the mobile station is expected to issue the necessary 36 ANSI-13641 feature code to the network. 37
If the activation is accepted, the system shall indicate success with using either GSM or ANSI-13641 38 signaling techniques depending on the mode of operation. 39
N.S0028-0
Ballot Version 27
The serving system may provide a courtesy call to the forward-to number shortly after this feature is 1 activated permitting the subscriber to verify the validity of the forward-to number. 2
4.2.3.2.6 De-Activation 3
GSM foreign mode: CFB may be de-activated by a Demand Activation authorized subscriber 4 specifying the CFB de-activation feature code, as in: 5
* FC0 + SEND . 6
Alternatively, if the mobile station offers menu driven control of de-activation, the mobile station is 7 expected to generate the equivalent GSM functional signaling. 8
ANSI-41 foreign mode: The user may deactivate CFB by means of an appropriate control procedure 9 (e.g., as described in GSM 02.30[11]). In ANSI-41 foreign mode, if the equivalent GSM mode feature 10 code (MMI) is manually entered by the user, the mobile station is expected to issue the necessary 11 ANSI-13641 feature code to the network. 12
If the de-activation is accepted, the system shall indicate success with using either GSM or ANSI-13 13641 signaling techniques depending on the mode of operation. Registered information shall not be 14 erased. 15
CFB shall be de-activated upon de-authorization (withdrawal) or de-registration (erasure). 16
4.2.3.2.7 Invocation 17
The feature treatment is invoked when there is an incoming call while the subscriber is considered to 18 be busy (i.e., in any state other than the idle state) and CFB is active. 19
4.2.3.3 Normal Operation with Successful Outcome 20
When CFB is active, incoming calls for the subscriber shall be forwarded to the forward-to number 21 when the subscriber is considered to be busy. 22
GSM Foreign Mode: When an incoming call is forwarded on mobile subscriber busy with the 23 condition network determined user busy (NDUB) the forward-to-party shall receive a notification that 24 the call has been forwarded. The calling party may also receive a notification that the call has been 25 forwarded. 26
ANSI-41 foreign mode: When an incoming call is forwarded due to a busy condition the served 27 mobile subscriber may receive a notification that the call has been forwarded. 28
4.2.3.3.1 Call Detail Record / Charging Requirements 29
For GSM and ANSI-41 based network interoperability, no new or special recording capabilities are 30 needed. 31
32
N.S0028-0
Ballot Version 28
1
4.2.3.4 Exception Procedures or Unsuccessful Outcome 2
3
4.2.3.4.1 Registration 4
If the system cannot accept a registration request, the served mobile subscriber shall receive a 5 notification that call forwarding on mobile subscriber busy registration was not successful. Possible 6 causes are: 7
� service not subscribed to; 8
� forward-to number is invalid directory number; 9
� use of an operator access prefix; 10
� insufficient information; 11
� forward-to number is a special service code (e.g., police); 12
� forward-to number is the directory number of the mobile subscriber herself. 13
4.2.3.4.2 De-Registration (Erasure) 14
If the subscriber is not authorized for the request, the system shall apply feature denial treatment 15 when de-registration is attempted. 16
4.2.3.4.3 Activation 17
If the subscriber is not authorized for the request, or if a forward-to number is not properly registered, 18 the system shall apply feature denial treatment when activation is attempted. 19
4.2.3.4.4 De-Activation 20
If the subscriber is not authorized for the request, the system shall apply feature denial treatment 21 when de-activation is attempted. 22
4.2.3.4.5 Invocation 23
If the forwarded call cannot be routed to the forward-to destination, then the call shall be given the 24 appropriate treatment, such as applying the Special Information Tone for intercept to the calling party. 25
Precautions shall be taken to preclude undesirable looping of forwarded numbers within the MSC or 26 between the MSC and other switching centers. If such looping is detected, the call forwarding shall be 27 given the appropriate treatment, such as applying the Special Information Tone for intercept to the 28 calling party. 29
4.2.3.4.6 Exceptions While Roaming 30
None identified. 31
4.2.3.4.7 Exceptions During Intersystem Handoff 32
None identified. 33
34
N.S0028-0
Ballot Version 29
4.2.3.5 Alternate Procedures 1
None identified. 2
3
4.2.3.6 Interactions With Other Features and Services 4
5
4.2.3.6.1 Advice of charge (AoC) 6
See GSM 02.86[19]. 7
4.2.3.6.2 Barring of All Outgoing Calls (BAOC) 8
None identified at this time. 9
4.2.3.6.3 Barring of Outgoing International Calls (BOIC) 10
None identified at this time. 11
4.2.3.6.4 Barring of Outgoing International Calls except those directed to the Home PLMN 12 (BOIC-exHC) 13
None identified at this time. 14
4.2.3.6.5 Barring of All Incoming Calls (BAIC) 15
None identified at this time. 16
4.2.3.6.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam) 17
None identified at this time. 18
4.2.3.6.7 Call Delivery (CD) 19
CD affects CFB. That is, if CD is inactive while the subscriber is roaming, the subscriber is considered 20 to be inaccessible. Even if the subscriber has CFB active, incoming calls shall be given the subscriber 21 inaccessible treatment. 22
If CD is active and registered for a roaming subscriber, or if the subscriber is at home, CFB works 23 normally. 24
If the call is delivered to the subscriber, the subscriber is busy, and the subscriber has CFB active, 25 the call shall be diverted to the CFB forward-to number. 26
4.2.3.6.8 Call Forwarding—Busy (CFB) 27
Not applicable. 28
4.2.3.6.9 Call Forwarding—Default (CFD) 29
CFB takes precedence over CFD. That is, calls arriving to a busy subscriber with CFB and CFD 30 active shall be forwarded by CFB and not given CFD treatment. 31
4.2.3.6.10 Call Forwarding—No Answer / No Reply (CFNA / CFNRy) 32
N.S0028-0
Ballot Version 30
CFB is mutually exclusive with CFNA / CFNRy. That is, calls arriving to a busy subscriber with CFB 1 and CFNA / CFNRy active shall be forwarded by CFB and not given CFNA / CFNRy treatment. 2
4.2.3.6.11 Call Forwarding—Not Reachable (CFNRc) 3
CFB is mutually exclusive with CFNRc. That is, calls arriving to a busy subscriber with CFB and 4 CFNRc active shall be forwarded by CFB and not given CFNRc treatment. 5
4.2.3.6.12 Call Forwarding—Unconditional (CFU) 6
CFU takes precedence over CFB. That is, calls arriving when CFU is active shall be forwarded 7 unconditionally and not given CFB treatment. 8
4.2.3.6.13 Call Transfer (CT) 9
None identified. 10
4.2.3.6.14 Call Waiting / Call Hold (CW / HOLD) 11
CW is invoked before CFB. If a call arrives for a busy subscriber able to receive a second call, the 12 called subscriber has both CW and CFB active, and no call is already waiting to be answered; the call 13 is presented to the subscriber with CW notification. If the CW call is not accepted, CFB is not invoked. 14
If a call arrives for a busy subscriber, the called subscriber has both CW and CFB active, and if the 15 called subscriber is unable to receive a second call or has a call waiting to be answered; the call shall 16 be forwarded immediately by CFB. 17
4.2.3.6.15 Calling Number / Line Identification Presentation (CNIP / CLIP) 18
When a call has been forwarded and the forward-to user has been provided with the CNIP / CLIP 19 supplementary service, the forward-to user shall receive the number of the original calling user, if this 20 calling user has not subscribed to or invoked the CNIR / CLIR supplementary service. 21
4.2.3.6.16 Calling Number / Line Identification Restriction (CNIR / CLIR) 22
If the calling number indicates presentation restricted, the calling number shall not be presented to 23 the called party, the called station, the forward-to party, or the forward-to station. 24
If the called (redirecting) subscriber has CFB invoked and either the CNIR mode is Permanently 25 Restricted or the CNIR Default is Presentation Restricted, the redirecting number shall indicate 26 presentation restricted to prevent presentation to the forward-to party or to the forward-to station. 27
4.2.3.6.17 Calling Name Presentation (CNAP) 28
When a call has been forwarded and the forward-to user has been provided with the CNAP 29 supplementary service, the forward-to user shall receive the name of the original calling user, if this 30 calling user has not subscribed to or invoked the CNAR or CNIR / CLIR supplementary service. 31
4.2.3.6.18 Calling Name Restriction (CNAR) 32
If the calling name or number indicates presentation restricted, the calling name or number shall not 33 be presented to the called party, the called station, the forward-to party, or the forward-to station. 34
If the called (redirecting) subscriber has CFB invoked and either the CNAR or CNIR mode is 35 Permanently Restricted, or the CNAR or CNIR Default is Presentation Restricted, the redirecting 36 name shall indicate presentation restricted to prevent presentation to the forward-to party or to the 37 forward-to station. 38
N.S0028-0
Ballot Version 31
4.2.3.6.19 Closed User Group (CUG) 1
See GSM 02.85[18]. 2
4.2.3.6.20 Conference Calling / Multi Party Service (CC / MPTY) 3
None identified. 4
4.2.3.6.21 Do Not Disturb (DND) 5
None identified at this time. 6
4.2.3.6.22 Emergency Services 7
None identified at this time. 8
4.2.3.6.23 Flexible Alerting (FA) 9
None identified at this time. 10
4.2.3.6.24 Message Waiting Notification (MWN) 11
None identified. 12
4.2.3.6.25 Mobile Access Hunting (MAH) 13
None identified at this time. 14
4.2.3.6.26 Password Call Acceptance (PCA) 15
None identified at this time. 16
4.2.3.6.27 Preferred Language (PL) 17
None identified. 18
4.2.3.6.28 Priority Access and Channel Assignment (PACA) 19
None identified at this time. 20
4.2.3.6.29 Remote Feature Control (RFC) 21
CFB Registration shall be allowed via RFC in ANSI-41136 mode, or via functional messaging in GSM 22 mode. 23
4.2.3.6.30 Selective Call Acceptance (SCA) 24
None identified at this time. 25
4.2.3.6.31 Subscriber PIN Access (SPINA) 26
None identified at this time. 27
4.2.3.6.32 Subscriber PIN Intercept (SPINI) 28
None identified. 29
N.S0028-0
Ballot Version 32
4.2.3.6.33 Three-Way Calling / Multi Party Service (3WC / MPTY) 1
None identified. 2
4.2.3.6.34 Voice Message Retrieval (VMR) 3
None identified. 4
4.2.3.6.35 Voice Privacy (VP) 5
None identified. 6
7
N.S0028-0
Ballot Version 33
4.2.4 Call Forwarding No Answer/ No Reply/Not Reachable 1 (CFNA/CFNRy/CFNRc) 2
3
4.2.4.1 General Description 4
Call Forwarding—No Answer (CFNA) permits a called subscriber to have the system send incoming 5 calls addressed to the called subscriber’s Directory Number to another Directory Number (forward-to 6 number) or to the called subscriber’s designated voice mail box, when the subscriber fails to answer, 7 or is otherwise inaccessible (including no paging response, the subscriber’s location is not known the 8 subscriber is reported as inactive, Call Delivery not active for a roaming subscriber, Do Not Disturb 9 active, etc.). 10
Call Forwarding No Reply (CFNRy) permits a called subscriber to have the system send all incoming 11 calls, or just those associated with a specific Basic service group, addressed to the called mobile 12 subscriber'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 all 14 incoming calls, or just those associated with a specific Basic service group, addressed to the called 15 mobile subscriber's directory number and which meet not reachable to another directory number. 16
4.2.4.1.1 Applicability to Telecommunications Services 17
CFNA/CFNRy/CFNRc is applicable to voice telecommunication services. 18
4.2.4.2 Normal Procedures With Successful Outcome 19
20
4.2.4.2.1 Authorization (or Provision) 21
CFNA/CFNRy/CFNRc may be generally available or may be provided after pre-arrangement with the 22 service provider. The authorization (provision) may have subscription options. These options are 23 defined in either GSM 02.82[15] (i.e., GSM native mode subscribers) or ANSI-664[1] (e.g., ANSI-136 24 41, TDMA or CDMA native mode subscribers). Authorization or Provisioning may occur while 25 operating in foreign mode. 26
4.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 for 28 administrative reasons. De-authorization or withdrawal may occur while operating in foreign mode. 29
4.2.4.2.3 Registration 30
If the subscriber is authorized for Fixed Registration, the forward-to number shall be registered upon 31 authorization (provision). Mobile stations operating in foreign mode may attempt to perform 32 registration procedures normally supported in native mode. 33
The forward-to-number may be registered by the service provider upon authorization (provision) for 34 Variable Registration subscribers 35
GSM foreign mode: A forward-to-number may be registered by a Variable Registration authorized 36 subscriber specifying the CFNA registration feature code and a forward-to number termination 37 address as in: 38
N.S0028-0
Ballot Version 34
* FC + termination address + SEND 1
Alternatively, if the mobile station offers menu driven control of registration, the mobile station is 2 expected to generate the equivalent GSM functional signaling towards the network. 3
ANSI-41 foreign mode: Registration can take place with an appropriate control procedure by the 4 subscriber, per GSM 02.30[11]. In ANSI-41 foreign mode, if the equivalent GSM feature code (MMI) 5 is manually entered by the user, the mobile station is expected to issue the relevant ANSI-13641 6 feature code entry. 7
Alternatively, if the mobile station offers menu driven control of registration, the mobile station is 8 expected to generate the equivalent ANSI-13641 feature code entry and resulting call origination 9 based on the menu driven entry. 10
If the registration is accepted, the system shall indicate success using either GSM or ANSI-13641 11 signaling techniques depending on the mode of operation. 12
4.2.4.2.4 De-Registration (or Erasure) 13
Mobile stations operating in foreign mode may attempt to perform De-Registration or Erasure 14 procedures normally supported in native mode. 15
A forward-to-number may be de-registered upon de-activation (at the home service provider option). 16
GSM foreign mode: If the de-registration is to be separate from de-activation, the de-registration 17 feature code must be distinct from the corresponding de-activation feature code. 18
GSM foreign mode: CFNA may be de-registered by a Variable Registration authorized subscriber 19 specifying the CFNA de-registration feature code, as in: 20
* FC0 + SEND . 21
Alternatively, if the mobile station offers menu driven control of registration, the mobile station is 22 expected to generate the equivalent GSM functional signaling towards the network. 23
ANSI-41 foreign mode: The subscriber can specifically erase a previous registration with an 24 appropriate control procedure, per GSM 02.30[11]. In ANSI-41 foreign mode, if the equivalent GSM 25 feature code (MMI) is manually entered by the user, the mobile station is expected to issue the 26 necessary ANSI-13641 feature code to the network. 27
CFNA/CFNRy/CFNRc shall be de-registered upon de-authorization or withdrawal. 28
4.2.4.2.5 Activation 29
Mobile stations operating in foreign mode may attempt to perform Activation procedures normally 30 supported in native mode. 31
If the subscriber is authorized for Permanent Activation, CFNA shall be activated upon authorization 32 (provision). 33
CFNA may be activated upon authorization or registration for Demand Activation authorized 34 subscribers. CFNA may be activated upon registration for Variable Registration authorized 35 subscribers. 36
GSM foreign mode: A previously registered forward-to-number may be activated by a Demand 37 Activation authorized subscriber specifying a CFNA activation feature code, as in: 38
* FC + SEND . 39
N.S0028-0
Ballot Version 35
Alternatively, if the mobile station offers menu driven control of activation, the mobile station is 1 expected to generate the equivalent GSM functional signaling. 2
ANSI-41 foreign mode: The MS shall be allowed to activate CFNRy/CFNRc by using an appropriate 3 control procedure (e.g. using the MMI command described in GSM 02.30[11]). In ANSI-41 foreign 4 mode, if the equivalent GSM feature code (MMI) is manually entered by the user, the mobile station is 5 expected to issue the necessary ANSI-13641 feature code to the network. 6
If the activation is accepted, the system shall indicate success using either GSM or ANSI-13641 7 signaling techniques depending on the mode of operation. 8
The serving system may provide a courtesy call to the forward-to number shortly after this feature is 9 activated permitting the subscriber to verify the validity of the forward-to-number. 10
4.2.4.2.6 De-Activation 11
GSM foreign mode: CFNA may be de-activated by a Demand Activation authorized subscriber 12 specifying the CFNA de-activation feature code, as in: 13
* FC0 + SEND . 14
Alternatively, if the mobile station offers menu driven control of de-activation, the mobile station is 15 expected to generate the equivalent GSM functional signaling. 16
ANSI-41 foreign mode: The user may deactivate CFNRy/CFNRc by means of an appropriate control 17 procedure (e.g., as described in GSM 02.30[11]). In ANSI-41 foreign mode, if the equivalent GSM 18 feature code (MMI) is manually entered by the user, the mobile station is expected to issue the 19 necessary ANSI-13641 feature code to the network. 20
If the de-activation is accepted, the system shall indicate success using either GSM or ANSI-13641 21 signaling techniques depending on the mode of operation. Registered information shall not be 22 erased. 23
CFNA/CFNRy/CFNRc shall be de-activated upon de-authorization (withdrawal) or de-registration 24 (erasure). 25
4.2.4.2.7 Invocation 26
The feature treatment is invoked when there is an incoming call and either CFNA, CFNRy or CFNRc 27 is active and the necessary conditions have been met – see GSM 02.82[15] and ANSI-664[1]. 28
4.2.4.3 Normal Operation with Successful Outcome 29
When CFNA/CFNRy/CFNRc is active, incoming calls for the subscriber shall be forwarded due to not 30 reachable (e.g., no response to paging) or no reply to the forward-to number. 31
GSM Foreign Mode: When an incoming call is forwarded due to no reply or not reachable, the 32 forward-to-party shall receive a notification that the call has been forwarded. The calling party may 33 also receive a notification that the call has been forwarded. 34
ANSI-41 foreign mode: When an incoming call is forwarded due to no answer the served mobile 35 subscriber may receive a notification that the call has been forwarded. 36
4.2.4.3.1 Call Detail Record / Charging Requirements 37
For GSM and ANSI-41 based network interoperability, no new or special recording capabilities are 38 needed. 39
N.S0028-0
Ballot Version 36
1
4.2.4.4 Exception Procedures or Unsuccessful Outcome 2
3
4.2.4.4.1 Registration 4
If the system cannot accept a registration request, the served mobile subscriber shall receive a 5 notification that registration of CFNA/CFNRy/CFNRc was not successful. Possible causes are: 6
� service not subscribed to; 7
� forward-to number is invalid directory number; 8
� use of an operator access prefix; 9
� insufficient information; 10
� forward-to number is a special service code (e.g., police); 11
� forward-to number is the directory number of the mobile subscriber herself. 12
4.2.4.4.2 De-Registration (Erasure) 13
If the subscriber is not authorized for the request, the system shall apply feature denial treatment 14 when de-registration is attempted. 15
4.2.4.4.3 Activation 16
If the subscriber is not authorized for the request, or if a forward-to-number is not properly registered, 17 the system shall apply feature denial treatment when activation is attempted. 18
4.2.4.4.4 De-Activation 19
If the subscriber is not authorized for the request, the system shall apply feature denial treatment 20 when de-activation is attempted. 21
4.2.4.4.5 Invocation 22
If the forwarded call cannot be routed to the forward-to-destination, then the call shall be given the 23 appropriate treatment, such as applying the Special Information Tone for intercept to the calling party. 24
Precautions shall be taken to preclude undesirable looping of forwarded numbers within the MSC or 25 between the MSC and other switching centers. If such looping is detected, the call forwarding shall be 26 given the appropriate treatment, such as applying the Special Information Tone for intercept to the 27 calling party. 28
4.2.4.4.6 Exceptions While Roaming 29
None identified. 30
4.2.4.4.7 Exceptions During Intersystem Handoff 31
None identified. 32
4.2.4.5 Alternate Procedures 33
N.S0028-0
Ballot Version 37
None identified. 1
4.2.4.6 Interactions With Other Features and Services 2
3
4.2.4.6.1 Advice of charge (AoC) 4
See GSM 02.86[19]. 5
4.2.4.6.2 Barring of All Outgoing Calls (BAOC) 6
None identified at this time. 7
4.2.4.6.3 Barring of Outgoing International Calls (BOIC) 8
None identified at this time. 9
4.2.4.6.4 Barring of Outgoing International Calls except those directed to the Home PLMN 10 (BOIC-exHC) 11
None identified at this time. 12
4.2.4.6.5 Barring of All Incoming Calls (BAIC) 13
None identified at this time. 14
4.2.4.6.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam) 15
None identified at this time. 16
4.2.4.6.7 Call Delivery (CD) 17
CD affects CFNA. That is, if CD is inactive while the subscriber is roaming, the subscriber is 18 considered to be inaccessible. If the subscriber has CFNA active, incoming calls shall be diverted to 19 the CFNA forward-to number. 20
If CD is active and registered for a roaming subscriber, or if the subscriber is at home, CFNA works 21 normally. 22
If the call is presented to the subscriber, the call is not answered, and the subscriber has CFNA 23 active, the call shall be diverted to the CFNA forward-to number. 24
4.2.4.6.8 Call Forwarding—Busy (CFB) 25
CFB is mutually exclusive with CFNA/CFNRy/CFNRc. That is, calls arriving to a busy subscriber with 26 CFB and CFNA/CFNRy/CFNRc active shall be forwarded by CFB and not given 27 CFNA/CFNRy/CFNRc treatment. 28
4.2.4.6.9 Call Forwarding—Default (CFD) 29
CFNA takes precedence over CFD. That is, an incoming call to an inaccessible or non-answering 30 subscriber with both CFNA and CFD active shall be forwarded using CFNA. 31
4.2.4.6.10 Call Transfer (CT) 32
N.S0028-0
Ballot Version 38
None identified. 1
2
N.S0028-0
Ballot Version 39
1
4.2.4.6.11 Call Waiting / Call Hold (CW / HOLD) 2
CW is invoked before CFNA/CFNRy. If a call arrives for a busy subscriber able to receive a second 3 call, the called subscriber has both CW and CFNA/CFNRy active, and no call is waiting to be 4 answered; the call is presented to the subscriber with CW notification. If the call is not answered 5 within a period of time after applying the first CW notification, it shall be given no answer treatment. 6
CFNRc is invoked before CW. 7
4.2.4.6.12 Calling Number / Line Identification Presentation (CNIP / CLIP) 8
When a call has been forwarded and the forward-to user has been provided with the CNIP / CLIP 9 supplementary service, the forward-to user shall receive the number of the original calling user, if this 10 calling party has not subscribed to or invoked the CNIR / CLIR supplementary service. 11
4.2.4.6.13 Calling Number / Line Identification Restriction (CNIR / CLIR) 12
If the calling number indicates presentation restricted, the calling number shall not be presented to 13 the called party or the forward-to-party. 14
If the called (redirecting) subscriber has CFNA/CFNRy/CFNRc active and CNIR is either Permanently 15 Restricted or the default is Presentation Restricted, the redirecting number shall indicate presentation 16 restricted to prevent presentation to the forward-to-party or to the forward-to station. 17
4.2.4.6.14 Calling Name Presentation (CNAP) 18
When a call has been forwarded and the forward-to-party has been provided with the CNAP 19 supplementary service, the forward-to user shall receive the name of the original calling user, if this 20 calling user has not subscribed to or invoked the CNAR or CNIR / CLIR supplementary service. 21
4.2.4.6.15 Calling Name Restriction (CNAR) 22
If the calling name or number indicates presentation restricted, the calling name or number shall not 23 be presented to the called party or the forward-to-party. 24
If the called (redirecting) subscriber has CFNA/CFNRy/CFNRc active and CNAR or CNIR is either 25 Permanently Restricted, or the default is Presentation Restricted, the redirecting name shall indicate 26 presentation restricted to prevent presentation to the forward-to-party. 27
4.2.4.6.16 Closed User Group (CUG) 28
See GSM 02.85[18]. 29
4.2.4.6.17 Conference Calling / Multi Party Service (CC / MPTY) 30
None identified. 31
4.2.4.6.18 Do Not Disturb (DND) 32
None identified at this time. 33
4.2.4.6.19 Emergency Services 34
None identified at this time. 35
N.S0028-0
Ballot Version 40
4.2.4.6.20 Flexible Alerting (FA) 1
None identified at this time. 2
4.2.4.6.21 Message Waiting Notification (MWN) 3
None identified. 4
4.2.4.6.22 Mobile Access Hunting (MAH) 5
None identified at this time. 6
4.2.4.6.23 Password Call Acceptance (PCA) 7
None identified at this time. 8
4.2.4.6.24 Preferred Language (PL) 9
None identified. 10
4.2.4.6.25 Priority Access and Channel Assignment (PACA) 11
None identified at this time. 12
4.2.4.6.26 Remote Feature Control (RFC) 13
CFNA/CFNRy/CFNRc Registration shall be allowed via RFC in ANSI-13641 mode, or via functional 14 messaging in GSM mode. 15
4.2.4.6.27 Selective Call Acceptance (SCA) 16
None identified at this time. 17
4.2.4.6.28 Subscriber PIN Access (SPINA) 18
None identified at this time. 19
4.2.4.6.29 Subscriber PIN Intercept (SPINI) 20
None identified. 21
4.2.4.6.30 Three-Way Calling / Multi Party Service (3WC / MPTY) 22
None identified. 23
4.2.4.6.31 Voice Message Retrieval (VMR) 24
None identified. 25
4.2.4.6.32 Voice Privacy (VP) 26
None identified. 27
28
N.S0028-0
Ballot Version 41
4.2.5 Call Forwarding Default 1
4.2.5.1 General Description 2
Call Forwarding—Default (CFD) permits a called subscriber to send incoming calls addressed to the 3 called subscriber’s Directory Number to the subscriber’s designated voice mail box or to another 4 Directory Number (forward-to number), when the subscriber is engaged in a call, does not respond to 5 paging, does not answer the call within a specified period after being alerted or is otherwise 6 inaccessible (including no paging response, the subscriber’s location is not known, the subscriber is 7 reported as inactive, Call Delivery not active for a roaming subscriber, Do Not Disturb active, etc.). 8
4.2.5.1.1 Applicability to Telecommunications Services 9
CFD is applicable to voice telecommunication services. 10
4.2.5.2 Normal Procedures With Successful Outcome 11
12
4.2.5.2.1 Authorization (or Provision) 13
CFD may be generally available or may be provided after pre-arrangement with the service provider. 14 The authorization (provision) may have subscription options. These options are defined in 15 ANSI-664[1] (e.g., ANSI-136 41, TDMA or CDMA native mode subscribers). Authorization or 16 Provisioning may occur while operating in foreign mode. 17
4.2.5.2.2 De-Authorization (or Withdrawal) 18
CFD may be withdrawn by the service provider, at the subscriber’s request, or for administrative 19 reasons. De-authorization or withdrawal may occur while operating in foreign mode. 20
4.2.5.2.3 Registration 21
If the subscriber is authorized for Fixed Registration, the forward-to number shall be registered upon 22 authorization (provision). Mobile stations operating in foreign mode may attempt to perform 23 registration procedures normally supported in native mode. 24
The forward-to-number may be registered by the service provider upon authorization (provision) for 25 Variable Registration subscribers 26
GSM foreign mode: A forward-to-number may be registered by a Variable Registration authorized 27 subscriber specifying the CFD registration feature code and a forward-to number termination address 28 as in: 29
* FC + termination address + SEND . 30
Alternatively, if the mobile station offers menu driven control of registration, the mobile station is 31 expected to generate the equivalent GSM functional signaling towards the network. 32
If the registration is accepted, the system shall indicate success using either GSM signaling 33 techniques. 34
4.2.5.2.4 De-Registration (or Erasure) 35
Mobile stations operating in foreign mode, may attempt to perform De-Registration or Erasure 36 procedures normally supported in native mode. 37
N.S0028-0
Ballot Version 42
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-registration 2 feature 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 subscriber 4 specifying 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 is 7 expected to generate the equivalent GSM functional signaling towards the network. 8
CFD shall be de-registered upon de-authorization or withdrawal. 9
4.2.5.2.5 Activation 10
Mobile stations operating in foreign mode may attempt to perform Activation procedures normally 11 supported in native mode. 12
If the subscriber is authorized for Permanent Activation, CFD shall be activated upon authorization 13 (provision). 14
CFD may be activated upon authorization or registration for Demand Activation authorized 15 subscribers. 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 Demand 17 Activation 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 is 20 expected to generate the equivalent GSM functional signaling. 21
If the activation is accepted, the system shall indicate success using GSM or ANSI-13641 signaling 22 techniques. 23
The serving system may provide a courtesy call to the forward-to number shortly after this feature is 24 activated permitting the subscriber to verify the validity of the forward-to-number. 25
4.2.5.2.6 De-Activation 26
GSM foreign mode: CFD may be de-activated by a Demand Activation authorized subscriber 27 specifying 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 is 30 expected to generate the equivalent GSM functional signaling. 31
If the de-activation is accepted, the system shall indicate success using either GSM signaling 32 techniques. Registered information shall not be erased. 33
CFD shall be de-activated upon de-authorization (withdrawal) or de-registration (erasure). 34
35
N.S0028-0
Ballot Version 43
1
4.2.5.2.7 Invocation 2
The feature treatment is invoked when there is an incoming call, CFD is active and the necessary 3 conditions have been met – See ANSI-664[1]. 4
4.2.5.3 Normal Operation with Successful Outcome 5
When CFD is active, incoming calls for the subscriber shall be forwarded due to not reachable (e.g., 6 no response to paging), no reply, or busy to the forward-to number. 7
GSM Foreign Mode: When an incoming call is forwarded due to CFD, the forward-to-party shall 8 receive a notification that the call has been forwarded. The calling party may also receive a 9 notification that the call has been forwarded. 10
4.2.5.3.1 Call Detail Record / Charging Requirements 11
For GSM and ANSI-41 based network interoperability, no new or special recording capabilities are 12 needed. 13
4.2.5.4 Exception Procedures or Unsuccessful Outcome 14
15
4.2.5.4.1 Registration 16
If the system cannot accept a registration request, the served mobile subscriber shall receive a 17 notification that registration of CFD was not successful. Possible causes are: 18
� service not subscribed to; 19
� forward-to number is invalid directory number; 20
� use of an operator access prefix; 21
� insufficient information; 22
� forward-to number is a special service code (e.g., police); 23
� forward-to number is the directory number of the mobile subscriber herself. 24
4.2.5.4.2 De-Registration (Erasure) 25
If the subscriber is not authorized for the request, the system shall apply feature denial treatment 26 when de-registration is attempted. 27
4.2.5.4.3 Activation 28
If the subscriber is not authorized for the request, or if a forward-to-number is not properly registered, 29 the system shall apply feature denial treatment when activation is attempted. 30
4.2.5.4.4 De-Activation 31
If the subscriber is not authorized for the request, the system shall apply feature denial treatment 32 when de-activation is attempted. 33
34
N.S0028-0
Ballot Version 44
1
4.2.5.4.5 Invocation 2
If the forwarded call cannot be routed to the forward-to-destination, then the call shall be given the 3 appropriate treatment, such as applying the Special Information Tone for intercept to the calling party. 4
Precautions shall be taken to preclude undesirable looping of forwarded numbers within the MSC or 5 between the MSC and other switching centers. If such looping is detected, the call forwarding shall be 6 given the appropriate treatment, such as applying the Special Information Tone for intercept to the 7 calling party. 8
4.2.5.4.6 Exceptions While Roaming 9
None identified. 10
4.2.5.4.7 Exceptions During Intersystem Handoff 11
None identified. 12
4.2.5.5 Alternate Procedures 13
None identified. 14
4.2.5.6 Interactions With Other Features and Services 15
4.2.5.6.1 Call Delivery (CD) 16
CD affects CFD. That is, if CD is inactive while the subscriber is roaming, the subscriber is 17 considered to be inaccessible. If the subscriber has CFD active, incoming calls shall be diverted to 18 the CFD forward-to number. 19
4.2.5.6.2 Call Forwarding—Busy (CFB) 20
CFB takes precedence over CFD. That is, calls arriving to a busy subscriber with CFB and CFD 21 active shall be forwarded by CFB and not given CFD treatment. 22
4.2.5.6.3 Call Transfer (CT) 23
None identified. 24
4.2.5.6.4 Call Waiting / Call Hold (CW / HOLD) 25
CW is invoked before CFD. If a call arrives for a busy subscriber able to receive a second call, the 26 called subscriber has both CW and CFD active, and no call is waiting to be answered; the call is 27 presented to the subscriber with CW notification. If the call is not answered within a period of time 28 after applying the first CW notification, it shall be given no answer treatment. 29
4.2.5.6.5 Calling Number / Line Identification Presentation (CNIP / CLIP) 30
When a call has been forwarded and the forward-to user has been provided with the CNIP / CLIP 31 supplementary service, the forward-to user shall receive the number of the original calling user, if this 32 calling user has not subscribed to or invoked the CNIR / CLIR supplementary service. 33
4.2.5.6.6 Calling Number / Line Identification Restriction (CNIR / CLIR) 34
N.S0028-0
Ballot Version 45
If the calling number indicates presentation restricted, the calling number shall not be presented to 1 the called party or the forward-to-party. 2
If the called (redirecting) subscriber has CFD active and CNIR is either Permanently Restricted or the 3 default is Presentation Restricted, the redirecting number shall indicate presentation restricted to 4 prevent presentation to the forward-to-party or to the forward-to station. 5
4.2.5.6.7 Calling Name Presentation (CNAP) 6
When a call has been forwarded and the forward-to-party has been provided with the CNAP 7 supplementary service, the forward-to user shall receive the name of the original calling user, if this 8 calling user has not subscribed to or invoked the CNAR or CNIR / CLIR supplementary service. 9
4.2.5.6.8 Calling Name Restriction (CNAR) 10
If the calling name or number indicates presentation restricted, the calling name or number shall not 11 be presented to the called party or the forward-to-party. 12
If the called (redirecting) subscriber has CFD active and CNAR or CNIR is either Permanently 13 Restricted, or the default is Presentation Restricted, the redirecting name shall indicate presentation 14 restricted to prevent presentation to the forward-to-party. 15
4.2.5.6.9 Closed User Group (CUG) 16
See GSM 02.85[18]. 17
4.2.5.6.10 Conference Calling / Multi Party Service (CC / MPTY) 18
None identified. 19
4.2.5.6.11 Do Not Disturb (DND) 20
None identified at this time. 21
4.2.5.6.12 Emergency Services 22
None identified at this time. 23
4.2.5.6.13 Flexible Alerting (FA) 24
None identified at this time. 25
4.2.5.6.14 Message Waiting Notification (MWN) 26
None identified. 27
4.2.5.6.15 Mobile Access Hunting (MAH) 28
None identified at this time. 29
4.2.5.6.16 Password Call Acceptance (PCA) 30
None identified at this time. 31
4.2.5.6.17 Preferred Language (PL) 32
N.S0028-0
Ballot Version 46
None identified. 1
2
N.S0028-0
Ballot Version 47
1
4.2.5.6.18 Priority Access and Channel Assignment (PACA) 2
None identified at this time. 3
4.2.5.6.19 Remote Feature Control (RFC) 4
CFD Registration shall be allowed via RFC in ANSI-13641 mode, or via functional messaging in GSM 5 mode. 6
4.2.5.6.20 Selective Call Acceptance (SCA) 7
None identified at this time. 8
4.2.5.6.21 Subscriber PIN Access (SPINA) 9
None identified at this time. 10
4.2.5.6.22 Subscriber PIN Intercept (SPINI) 11
None identified. 12
4.2.5.6.23 Three-Way Calling / Multi Party Service (3WC / MPTY) 13
None identified. 14
4.2.5.6.24 Voice Message Retrieval (VMR) 15
None identified. 16
4.2.5.6.25 Voice Privacy (VP) 17
None identified. 18
N.S0028-0
Ballot Version 48
4.3 Optimal Routing for Late Call Forwarding 1
2
4.3.1 General Description 3
Optimal Routing for Late Call Forwarding is a network feature which enables calls for a mobile 4 subscriber who is not available to be routed from the called party HPLMN directly to a specified 5 forward-to destination. 6
In GSM Optimal Routing for Late Call Forwarding by the HPLMN is a subset of the capabilities 7 provided in GSM Support for Optimal Routing (SOR) Phase I per GSM 02.79[13]. With SOR, the 8 interrogating PLMN (IPLMN) decides whether or not to optimize routing by taking into account 9 information provided by the called party HPLMN. The HPLMN can decide, on a call-by-call basis, 10 whether or not to allow OR. 11
GSM SOR provides additional capabilities for OR under other conditions and by systems other than 12 the HPLMN, which are outside the scope of this feature. 13
In ANSI-41 networks Optimal Routing for Late Call Forwarding can be provided automatically for 14 every 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. 16 There is no subscriber initiated registration, activation, or invocation. 17
4.3.1.1 Applicability to Telecommunications Services 18
Optimal Routing for Late Call Forwarding is applicable to all circuit switched Telecommunications 19 Service. 20
4.3.2 Normal Procedures with Successful Outcome 21
Optimal Routing for Late Call Forwarding refers to the scenario in which party A (mobile or wireline) 22 attempts to call mobile subscriber B who may have calls forwarded to party C (mobile or wireline). In 23 GSM, the consideration of whether or not to invoke OR depends upon the relative locations HPLMN-24 B, VPLMN-B, and HPLMN-C. Both the HPLMN-B and the VPLMN-B must be capable of supporting 25 Optimal Routing for Late Call Forwarding. The VPLMN-B determines if Optimal Routing for Late Call 26 Forwarding 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 any 29 country. 30
HPLMN- B acts as the interrogating PLMN, and launches a query to the HLR to determine the 31 location and status of B. 32
If the response from the HLR indicates that B is active and reachable, then HPLMN-B proceeds to 33 initiate call setup to VPLMN-B. 34
Upon receipt of call setup request from HPLMN-B, VPLMN-B proceeds to page B. If call cannot be 35 completed successfully (e.g., Busy, No Page Response or No Answer), and B has call forwarding 36 active, then HPLMN-B proceeds to initiate call forwarding to the forward-to number. Call setup to the 37 forward to party is done directly from HPLMN-B rather than through VPLMN-B. Without optimal 38 routing in GSM call leg would have been setup initially to VPLMN-B, and from there to C. 39
4.3.2.1 Call Detail Record 40
N.S0028-0
Ballot Version 49
For GSM and ANSI-41 based network interoperability, no new or special recording capabilities are 1 needed. 2
4.3.3 Exception Procedures or Unsuccessful Outcome 3
4.3.3.1 Non-support for OR in the called party HPLMN 4
If the HPLMN of the called party is a GSM system which does not support OR, Optimal Routing for 5 Late Call Forwarding cannot be invoked. 6
4.3.3.2 Non-support for OR in the called party VPLMN 7
If a subscriber whose HPLMN is an ANSI-41 or GSM system that supports OR registers in a VPLMN 8 with a GSM system that does not support OR, then Optimal Routing for Late Call Forwarding cannot 9 be invoked. 10
4.3.3.3 Calls to special mobile network numbers 11
If the called number is a special mobile network number of the HPLMN and the HPLMN is a GSM 12 system, then the HPLMN has to guarantee that the call terminates at the correct destination. This can 13 be achieved by denying OR for this call or by sending an appropriate error cause, or by implementing 14 special handling. 15
4.3.3.4 Exceptions while Roaming 16
None identified. 17
4.3.3.5 Exceptions during Intersystem Handoff 18
None identified. 19
4.3.4 Alternate Procedures 20
None identified. 21
4.3.5 Interactions with Other Features and Services 22
4.3.5.1 Advice of Charge 23
Depending on the particular call scenario, AoC may not work properly. For example, the subscriber 24 may be charged a rate that is associated with non-optimal routing. 25
4.3.5.2 Barring of All Outgoing Calls (BAOC) 26
None identified. 27
4.3.5.3 Barring of Outgoing International Calls (BOIC) 28
None identified. 29
4.3.5.4 Barring of All Incoming Calls (BAIC) 30
BAIC takes precedence over Optimal Routing for Late Call Forwarding, and all incoming calls are 31 given denial treatment. 32
N.S0028-0
Ballot Version 50
Barring of Incoming Calls when Roaming Outside the Home PLMN Country (BIC-Roam) 1
No impact. 2
4.3.5.5 Call Forwarding Busy (CFB) 3
The interaction between Optimal Routing for Late Call Forwarding and CFB is as described in 4.3.1 4 above. Optimal Routing for Late Call Forwarding does not impact the forwarded number or the 5 ultimate call delivery to the forwarded party – only intermediate routing. 6
4.3.5.6 Call Forwarding Default (CFD) 7
The interaction between Optimal Routing for Late Call Forwarding and CFD is as described in 4.3.1 8 above. Optimal Routing for Late Call Forwarding does not impact the forwarded number or the 9 ultimate call delivery to the forwarded party – only intermediate routing. 10
4.3.5.7 Call Forwarding Busy No Answer / No Reply (CFNA) 11
The interaction between Optimal Routing for Late Call Forwarding and CFNA is as described in 4.3.1. 12 Optimal Routing for Late Call Forwarding does not impact the forwarded number or the ultimate call 13 delivery to the forwarded party – only intermediate routing. 14
4.3.5.8 Call Forwarding—Not Reachable (CFNRc) 15
There is no interaction between Optimal Routing for Late Call Forwarding and CFU since CFU is 16 invoked in the called party HPLMN before call setup to the serving system is initiated. (ANSI-41: it 17 depends on when paging occurs!). 18
4.3.5.9 Call Forwarding Unconditional (CFU) 19
There is no interaction between Optimal Routing for Late Call Forwarding and CFU since CFU is 20 invoked in the called party HPLMN before call setup to the serving system is initiated. 21
4.3.5.10 Call Transfer (CT) 22
None identified. 23
4.3.5.11 Call Waiting / Call Hold (CW / HOLD) 24
None identified. 25
4.3.5.12 Calling Number / Line Identification Presentation (CNIP / CLIP) 26
None identified. 27
4.3.5.13 Calling Number / Line Identification Restriction (CNIR / CLIR) 28
None identified. 29
4.3.5.14 Calling Name Presentation (CNAP) 30
None identified. 31
4.3.5.15 Calling Name Restriction (CNAR) 32
None identified. 33
N.S0028-0
Ballot Version 51
4.3.5.16 Closed User Group (CUG) 1
None identified. 2
4.3.5.17 Do Not Disturb (DND) 3
Same as CFU. 4
4.3.5.18 Emergency Services 5
None identified. 6
4.3.5.19 Law Enforcement or CALEA 7
None identified. 8
4.3.5.20 Message Waiting Notification (MWN) 9
None identified. 10
4.3.5.21 Mobile Access Hunting (MAH) 11
None identified. 12
4.3.5.22 Password Call Acceptance (PCA) 13
Applicable to ANSI-136 (ANSI-41 ) networks only. None identified. 14
4.3.5.23 Preferred Language (PL) 15
None identified. 16
4.3.5.24 Priority Access and Channel Assignment (PACA) 17
Applicable to ANSI-136 (ANSI-41) networks only. None identified. 18
4.3.5.25 Remote Feature Control (RFC) 19
Applicable to ANSI-136 (ANSI-41) networks only. None identified. 20
4.3.5.26 Selective Call Acceptance (SCA) 21
Applicable to ANSI-136 (ANSI-41) networks only. Callers that are not able to provide the correct 22 password are given denial treatment. Calls that are allowed may be subjected to OR treatment. 23
4.3.5.27 Subscriber PIN Access (SPINA) 24
Applicable to ANSI-136 (ANSI-41) networks only. None identified. 25
4.3.5.28 Subscriber PIN Intercept (SPINI) 26
Applicable to ANSI-136 (ANSI-41) networks only. None identified. 27
4.3.5.29 Voice Message Retrieval (VMR) 28
None identified. 29
N.S0028-0
Ballot Version 52
4.3.5.30 Voice Privacy (VP) 1
None identified. 2
4.3.5.31 3-Way Calls or Conference Calls 3
None identified. 4
5
N.S0028-0
Ballot Version 53
4.4 Call Waiting (CW) 1
2
4.4.1 General Description 3
Call Waiting (CW) provides notification to a controlling subscriber of an incoming call while the 4 subscriber’s call is in the 2-way state. Subsequently, the controlling subscriber can either answer or 5 ignore the incoming call. If the controlling subscriber answers the second call, it may alternate 6 between the two calls. 7
This service operates when the traffic channel at the controlling subscriber is not available and is 8 engaged in an active or held call. When a third party attempts to connect to that termination, the 9 controlling subscriber is given an appropriate indication of the waiting call. The maximum number of 10 waiting calls at one time per mobile access is one. In ANSI-13641 mode, this means that no further 11 calls are offered to the subscriber while a call is waiting. In GSM mode, another call can be offered to 12 the subscriber while a call is waiting, but only one call may be waiting at any time. 13
4.4.1.1 Applicability to Telecommunications Services 14
Call Waiting is applicable to circuit switched voice telecommunications services. 15
16
4.4.2 Normal Procedures With Successful Outcome 17
18
4.4.2.1 Authorization (or Provision) 19
No new authorization procedures are needed for either GSM or ANSI-41 foreign mode operation of 20 call waiting. The following describes authorization procedures for both GSM and ANSI-13641 native 21 modes. 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 subscribed 24 to and to which it is applicable, i.e. not provisioned to any subset of these BS. 25
ANSI-41136 native subscriber: CW may be authorized for the following options: 26
Table 1: CW Subscription Options 27
Subscription Options Values
Temporary Cancellation Demand. The subscriber is authorized to cancel or de-activate CW for a single call.
Permanent. CW may not be canceled or de-activated for a single call.
Activation Demand. The subscriber is authorized to control the activation and de-activation of CW.
Permanent. CW is active while authorized (unless canceled).
N.S0028-0
Ballot Version 54
1
4.4.2.2 De-Authorization (or Withdrawal) 2
CW may be withdrawn at the subscriber’s request or for administrative reasons. 3
4.4.2.3 Registration 4
CW has no registration. 5
4.4.2.4 De-Registration (or Erasure) 6
CW has no de-registration. 7
4.4.2.5 Activation 8
In both GSM and ANSI-41 foreign modes, the subscriber shall be provided with menu selections by 9 the mobile station to allow him/or her to activate the call waiting feature. Menu selections shall also be 10 available to the subscriber while in native mode as well. In addition, the user may also be able to 11 activate call waiting (depending on individual service provider’s preference) through the use of the 12 keypad, as follows: 13
ANSI-13641 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 activation 16 feature code, as in: 17
* FC + SEND . 18
If the activation is accepted, the system shall indicate success with feature confirmation treatment. 19
20
GSM native and foreign modes: This supplementary service shall be activated either collectively 21 for all applicable Basic Services or on a Basic Service group basis by the subscriber using a control 22 procedure, as specified in GSM 02.30[11], or by the service provider. The controlling subscriber shall 23 be informed by the network of the success or otherwise of her action. 24
4.4.2.6 De-Activation 25
In both GSM and ANSI-41 foreign modes, the subscriber shall be provided with menu selections by 26 the mobile station to allow him/or her to de-activate the call waiting feature. Menu selections shall 27 also be available to the subscriber while in native mode as well. In addition, the user may also be able 28 to de-activate call waiting (depending on individual service provider’s preference) through the use of 29 the keypad, as follows: 30
ANSI-13641 native and foreign mode: 31
CW shall be de-activated upon de-authorization. 32
CW Demand De-Activation: 33
CW may be de-activated by a Demand Activation authorized subscriber specifying a CW 34 de-activation feature code, as in: 35
* FC0 + SEND . 36
N.S0028-0
Ballot Version 55
If the de-activation is accepted, the system shall indicate success with feature confirmation treatment. 1
Temporary Cancellation During a Call (ANSI-13641 Native Mode Only): 2
CW may be canceled during a single call by a Demand Cancellation authorized subscriber issuing a 3 flash request and then specifying a CCW feature code, as in: 4
* FC0 + SEND . 5
If the cancellation is accepted, the system may indicate success with feature confirmation treatment 6 and then reconnect the call. At the completion of the call, CW shall resume the activation state prior 7 to using the cancel CW feature code. 8
Temporary Cancellation With a Call Setup Request (ANSI-13641 Native Mode Only): 9
CW may be canceled for a single call concurrently with a call request by a Demand Cancellation 10 authorized subscriber specifying a CCW feature code and a termination address, as in: 11
* FC0 + # + termination address + SEND . 12
Alternatively: 13
* FC + termination address + SEND 14
is possible, if a fixed length Temporary Cancellation feature code is distinct from the de-activation 15 feature code. 16
If the cancellation is accepted, the system may indicate success with feature confirmation treatment 17 and then the call is allowed to proceed toward the termination address. At the completion of the call, 18 CW shall resume the activation state prior to using the cancel CW feature code. 19
GSM native and foreign mode: The service shall be deactivated either collectively for all applicable 20 Basic Services or on a Basic Service group basis by the subscriber using a control procedure, as 21 specified in GSM 02.30[11], or by the service provider. The controlling subscriber shall be informed 22 by the network of the success or otherwise of her action. 23
4.4.2.7 Invocation 24
CW is invoked when a incoming call attempt arrives for a subscriber who is already engaged in 25 conversation on a prior call, who does not have another call waiting, and who has CW active. 26
There are functions or actions which exist on GSM (in GSM 02.83[16]), but do not exist in ANSI-27 13641, and vice versa (see charts below). In order to achieve a seamless user Interface when 28 roaming, it would be better to either provide the menu selections as it is in a GSM handset, or some 29 other mechanism that can achieve the same goal. 30
4.4.3 Normal Operation with Successful Outcome 31
Menu selections shall be provided by the mobile station, in both foreign and native modes, to allow 32 the subscriber to control the operation of calls involving call waiting. Because, in general, GSM 33 networks provide more capabilities related to call waiting operation, the menu-driven procedures may 34 be different for a given subscriber depending on whether the serving network is GSM or ANSI-13641. 35 In addition to the use of menu selections, a subscriber may use the keypad entries (shown in the 36 tables below) to control the operation of calls involving call waiting. Note that the subscriber would 37 need to use different set of keypad entries depending on whether the serving network is GSM or 38 ANSI-13641, and thus the use of the shown keypad entries to control the operation of the calls is not 39 encouraged. In general, the menu-driven approach would be preferred instead. 40
N.S0028-0
Ballot Version 56
The following tables describe the call party actions and system reactions for CW on GSM and ANSI-1 13641. 2
Table 2: 2-Way State for Call Waiting 3
State 2-way Condition The controlling subscriber is alerting the other party, or the controlling subscriber is in a two-way conversation with the other party.
GSM Called Party Action
ANSI-13641 Called Party Action
System Reaction
A call arrives from a calling party for a controlling subscriber in a two-way conversation and with CW active.
A call arrives from a calling party for a controlling subscriber in a two-way conversation and with CW active.
CW notification is applied to the controlling subscriber. The CW notification is repeated once if the waiting call is not answered. Audible ringing is applied to the calling party until the call is answered or given no answer treatment. Go to the 2-way CW notification state.
N.S0028-0
Ballot Version 57
1
The CW notification may be an audible Call Waiting Tone injected into the voice path, a message on 2 the alphanumeric display, or both. 3
Table 3: 2-Way Notification State for Call Waiting 4
State 2-way CW notification
Condition The controlling subscriber is in a two-way conversation with the other party and call waiting notification is applied.
GSM Called Party Action
ANSI-4136 Called Party Action
System Reaction
The controlling subscriber signals a flash request by pressing 2 +
SEND key .
The controlling subscriber signals a flash request by pressing the SEND
key without digits.
Remove the call waiting notification. Place the other party on hold. Connect the controlling subscriber and the calling party. Go to the 2-way CW state.
The controlling subscriber requests a disconnect by pressing the END key.
The controlling subscriber requests a disconnect by pressing the END
key.
Release the other party. Remove the call waiting notification. Apply the alerting to the controlling subscriber for the calling party. Go to the Alerting state.
The controlling subscriber signals a flash request by pressing 1 +
SEND key .
No equivalent function.
Release the other party. Remove the call waiting notification. Connect the controlling subscriber and the calling party. Go to the 2-way CW notification state.
The controlling subscriber signals a flash request by pressing 0 +
SEND key .
No equivalent function.
Remove the call waiting notification. Place the UDUB condition to the calling party for busying treatment. Go to the 2-way CW notification state.
5
6
N.S0028-0
Ballot Version 58
Table 4: 2-Way CW State for Call Waiting 1
State 2-way CW Condition The controlling subscriber is in a two-way conversation with the other party and a third party is on hold.
GSM Called Party Action
ANSI-4136 Called party Action
System Reaction
The controlling subscriber signals a flash request by pressing 2 + SEND
key.
The controlling subscriber signals a flash request by pressing the SEND
key without digits.
Place the other party on hold. Connect the controlling subscriber and the third party. Remain in the 2-way CW state.
No equivalent function.
The controlling subscriber requests a disconnect by pressing the END
key.
Release the other party. Apply the recall distinctive alerting for the third party to recall the controlling subscriber. Optionally apply audible alerting to the held party. Go to the Alerting state.
The controlling subscriber signals a flash request by pressing 1+ SEND
key.
No equivalent function.
Release the other party. Connect the controlling subscriber and the held party. Go to the 2-way CW notification state.
The controlling subscriber signals a flash request by pressing 0+ SEND
key.
No equivalent function.
The held party is released. Remain in the 2-way CW state.
The controlling subscriber requests a disconnect by pressing the END
key.
No equivalent function.
Release all calls.
2
4.4.3.1 Call Detail Record / Charging Requirements 3
For GSM and ANSI-41 based network interoperability, no new or special recording capabilities are 4 needed. 5
4.4.3.2 Interrogation 6
In foreign modes, the interrogation procedure is not supported. 7
GSM native mode 8
N.S0028-0
Ballot Version 59
The controlling subscriber may interrogate the network by the use of a control procedure, as specified 1 in GSM 02.30[11]. The network shall respond with an appropriate indication telling the subscriber 2 whether the service is supported in this network and, if so, provide a list of all Basic Service groups to 3 which the Call waiting supplementary service is active. 4
4.4.4 Exception Procedures or Unsuccessful Outcome 5
6
4.4.4.1 Registration 7
None identified. 8
4.4.4.2 De-Registration / Erasure 9
None identified. 10
4.4.4.3 Activation 11
If the subscriber is not authorized for the request, the system shall apply feature denial treatment 12 when activation is attempted. 13
4.4.4.4 De-Activation 14
Demand De-Activation: If the subscriber is not authorized for the request, the system shall apply 15 feature denial treatment when de-activation is attempted. 16
Temporary Cancellation (ANSI-13641 native mode only): If the subscriber is not authorized for 17 the request, the system shall apply feature denial treatment when de-activation is attempted. 18
Temporary Cancellation With a Call Setup Request (ANSI-13641 native mode only): If the 19 subscriber is not authorized for a Temporary Cancellation request made concurrently with a call setup 20 request, the system shall apply feature denial treatment and the call setup shall be denied. 21
4.4.4.5 Invocation 22
If the controlling subscriber is not authorized, if the controlling subscriber is alerting the other party, or 23 if resources are not available; give the calling party busy treatment. Remain in the 2-way state. 24
4.4.4.6 Exceptions While Roaming 25
None identified. 26
4.4.4.7 Exceptions During Intersystem Handoff 27
None identified. 28
4.4.5 Alternate Procedures 29
None identified. 30
4.4.6 Interactions With Other Features and Services 31
32
N.S0028-0
Ballot Version 60
4.4.6.1 Advice of charge (AoC) 1
None identified. 2
4.4.6.2 Barring of All Outgoing Calls (BAOC) 3
None identified. 4
4.4.6.3 Barring of Outgoing International Calls (BOIC) 5
None identified. 6
4.4.6.4 Barring of Outgoing International Calls except those directed to the Home PLMN 7 (BOIC-exHC) 8
None identified. 9
4.4.6.5 Barring of All Incoming Calls (BAIC) 10
None identified. 11
4.4.6.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam) 12
None identified. 13
4.4.6.7 Call Delivery (CD) 14
No interactions between CD and CW in foreign mode. 15
While the subscriber is in native mode, CD may affect CW. That is, if CD is inactive while the 16 subscriber is roaming, the subscriber is considered to be inaccessible. Even if the subscriber has CW 17 active, incoming calls shall be given the subscriber inaccessible treatment. 18
If CD is active and registered for a roaming subscriber, or if the subscriber is at home, CW works 19 normally. 20
4.4.6.8 Call Forwarding—Busy (CFB) 21
CW is invoked before CFB. If a call arrives for a busy subscriber able to receive a second call, the 22 called subscriber has both CW and CFB active, and no call is already waiting to be answered; the call 23 is presented to the subscriber with CW notification. If the CW call is not accepted, CFB is not invoked. 24
If a call arrives for a busy subscriber, the called subscriber has both CW and CFB active, and if the 25 called subscriber is unable to receive a second call or has a call waiting to be answered; the call shall 26 be forwarded immediately by CFB. 27
4.4.6.9 Call Forwarding—Default (CFD) 28
CW is invoked before CFD. If a call arrives for a busy subscriber able to receive a second call, the 29 called subscriber has both CW and CFD active, and no call is waiting to be answered; the call is 30 presented to the subscriber with CW notification. If the call is not answered within a period of time 31 after applying the first CW notification, it shall be given no answer treatment. 32
If a call arrives for a busy subscriber, the called subscriber has both CW and CFD active, and if the 33 called subscriber is unable to receive a second call or has a call waiting to be answered; the call shall 34 be forwarded immediately by CFD. 35
N.S0028-0
Ballot Version 61
4.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, the 2 called subscriber has both CW and CFNA active, and no call is waiting to be answered; the call is 3 presented to the subscriber with CW notification. If the call is not answered within a period of time 4 after 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 the 6 called subscriber is unable to receive a second call or has a call waiting to be answered; the call shall 7 be given busy treatment. 8
4.4.6.11 Call Forwarding—Not Reachable (CFNRc) 9
None identified. 10
4.4.6.12 Call Forwarding—Unconditional (CFU) 11
CFU takes precedence over CW. That is, calls arriving when CFU is active are forwarded 12 unconditionally and not given CW treatment. 13
4.4.6.13 Call Transfer (CT) 14
CT and CW are mutually exclusive. A call incoming to a controlling subscriber setting up or engaged 15 in a CT shall be given busy treatment, even if the called subscriber has CW active. 16
4.4.6.14 Call Waiting / Call Hold (CW / HOLD) 17
Not applicable. 18
4.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 notification 20 according to CNIP’s procedures. 21
4.4.6.16 Calling Number / Line Identification Restriction (CNIR / CLIR) 22
None identified. 23
4.4.6.17 Calling Name Presentation (CNAP) 24
None identified. 25
4.4.6.18 Calling Name Restriction (CNAR) 26
None identified. 27
4.4.6.19 Closed User Group (CUG) 28
None identified. 29
4.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 and 31 the subscriber shall be considered to be busy. 32
4.4.6.21 Do Not Disturb (DND) 33
N.S0028-0
Ballot Version 62
DND takes precedence over CW. That is, calls arriving for a subscriber with DND and CW active shall 1 be refused and not be given CW treatment. 2
4.4.6.22 Emergency Services 3
None identified. 4
4.4.6.23 Flexible Alerting (FA) 5
CW of the FA Pilot Directory Number shall apply to calls to the Pilot Directory Number when the FA 6 group is considered to be busy, but one or more members that have CW active are able to accept a 7 CW call. CW alerting shall be applied to the members of the FA group able to accept a CW call. If the 8 FA Pilot Directory Number does not have CW active, CW may not apply. 9
4.4.6.24 Message Waiting Notification (MWN) 10
MWN pip tone may not be applied if the affected subscriber has requested CW cancellation or has 11 CW de-active. 12
MWN pip tone shall not be applied for the call waiting legs of a call. 13
The CW activation feature code may be the same as the MWN pip tone activation feature code. The 14 CW de-activation feature code may be the same as the MWN pip tone de-activation feature code. 15 The Cancel Call Waiting (CCW) feature code may be the same as the Cancel Message Waiting 16 Notification (CMWN) feature code. 17
4.4.6.25 Mobile Access Hunting (MAH) 18
Interaction between MAH and CW is beyond the scope of this Standard. The following describes a 19 possible implementation: 20
For a single user MAH group, CW may be applied to a busy MAH member. 21
For a multiple user MAH group, CW of the MAH Pilot Directory Number shall apply to calls to the Pilot 22 Directory Number when the MAH group is considered to be busy, but one or more of the MAH 23 members that have CW active are able to accept a CW call. CW alerting shall be applied to the 24 members of the MAH group able to accept a CW call. If the MAH Pilot Directory Number does not 25 have CW active, CW may not apply. 26
4.4.6.26 Password Call Acceptance (PCA) 27
PCA takes precedence over CW. Incoming calls to the subscriber with PCA and CW active shall be 28 screened by the PCA feature before being considered for CW. 29
4.4.6.27 Preferred Language (PL) 30
None identified. 31
4.4.6.28 Priority Access and Channel Assignment (PACA) 32
PACA has precedence over CW. The CW feature shall not be invoked for incoming calls to a 33 subscriber waiting for a PACA channel, as the subscriber shall be considered to be busy. 34
4.4.6.29 Remote Feature Control (RFC) 35
None identified. 36
N.S0028-0
Ballot Version 63
4.4.6.30 Selective Call Acceptance (SCA) 1
SCA takes precedence over CW. Incoming calls to the subscriber with SCA and CW active shall be 2 screened by the SCA feature before being considered for CW. 3
4.4.6.31 Subscriber PIN Access (SPINA) 4
CW feature code requests shall be denied for an MS while SPINA is active. 5
4.4.6.32 Subscriber PIN Intercept (SPINI) 6
None identified. 7
4.4.6.33 Three-Way Calling / Multi Party Service (3WC / MPTY) 8
3WC and CW are mutually exclusive. A call incoming to a controlling subscriber setting up or 9 engaged in a three-way call shall be given busy treatment, even if the called subscriber has CW 10 active. 11
A flash request from a subscriber authorized for 3WC, while CW alerting is being applied, shall be 12 used to respond to the CW call. If the controlling subscriber still desires a three-way call, it must first 13 dispose of the CW call before requesting a three-way call. 14
4.4.6.34 Voice Message Retrieval (VMR) 15
None identified. 16
4.4.6.35 Voice Privacy (VP) 17
None identified. 18
19
N.S0028-0
Ballot Version 64
4.5 Three-Way Calling (3WC) and Multi-Party (MPTY) 1
2
4.5.1 General Description 3
ANSI-13641 Mode: Three-Way Calling (3WC) provides the subscriber the capability of adding a third 4 party to an established two-party call, so that all three parties may communicate in a three-way call. If 5 either of the two non-controlling parties to an established three-way call disconnects, the remaining 6 party is re-connected to the controlling subscriber as a normal two-party call. If the controlling 7 subscriber of a three-way call disconnects, the conference circuit and all other parties are released. 8 Digits included with flash requests when a termination address is not expected may be ignored. 9 Native 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 or 11 separated (i.e. removed from the multi-party call but remain connected to the served mobile 12 subscriber). The maximum number of remote parties is 5. 13
4.5.1.1 Applicability to Telecommunications Services 14
3WC/MPTY is applicable to voice telecommunication services. 15
4.5.2 Normal Procedures With Successful Outcome 16
17
4.5.2.1 Authorization (or Provision) 18
GSM native subscribers: This supplementary service is provisioned for all Basic services 19 subscribed to and to which it is applicable, i.e. not provisioned to any subset of these BS. The 20 provision of the Call Hold supplementary service is also required. 21
ANSI-13641 native subscribers: 3WC may be generally available or may be provided after pre-22 arrangement with the service provider. 23
4.5.2.2 De-Authorization (or Withdrawal) 24
3WC/MPTY may be withdrawn at the subscriber’s request or for administrative reasons. 25
4.5.2.3 Registration 26
3WC/MPTY has no registration. 27
4.5.2.4 De-Registration (or Erasure) 28
3WC/MPTY has no de-registration. 29
4.5.2.5 Activation 30
3WC/MPTY is activated upon authorization. 31
4.5.2.6 De-Activation 32
3WC/MPTY shall be de-activated upon de-authorization. 33
N.S0028-0
Ballot Version 65
4.5.2.7 Invocation 1
ANSI-13641 Mode: 3WC is invoked when the appropriate flash request is sent and the feature is 2 authorized. 3
GSM Mode: Multi-Party service is invoked by the served mobile subscriber by use of a control 4 procedure, as defined in GSM 02.30[11]. 5
4.5.3 Normal Operation with Successful Outcome 6
7
4.5.3.1 ANSI-13641 Mode 8
1. 3WC allows a controlling subscriber to add a third party to an existing two-way call. If necessary, 9 the last party added to a call may be dropped. 10
2. The controlling subscriber presses the SEND key without digits while in a two-way conversation to 11 put the other party on hold. 12
� One party is on hold. The system is waiting for the controlling subscriber to enter a feature code 13 or the address of a third party, 14
� If the controlling subscriber presses the SEND key without digits, the system reconnects the held 15 party. 16
� If the controlling subscriber presses the END key, the system releases the controlling subscriber. 17 Apply distinctive recall alerting to the controlling subscriber to recall the held party. 18
� If the controlling subscriber enters termination address + SEND, the system attempts to 19 establish a connection to the third party specified by the termination address allowing the 20 controlling subscriber to hear call progress tones and announcements. 21
� If the controlling subscriber enters a feature code, *FC + SEND, the system acts upon the 22 feature code. Apply feature confirmation treatment. 23
� If the controlling subscriber enters *FC + # + termination address + SEND, the system acts upon 24 the feature code. Applies feature confirmation treatment. Attempts to establish a connection to 25 the third party specified by the termination address allowing the controlling subscriber to hear 26 call progress tones and announcements. 27
� If an incoming call arrives for the controlling subscriber, the system applies busy treatment to the 28 calling party. 29
� If the held party disconnects, the system release the held party. The voice channel may be 30 released. Any further action by the subscriber is treated as a new service request. 31
3. One party is on hold. The controlling subscriber is alerting the other party, or the controlling 32 subscriber is in a two-way conversation with a third party, 33
� If the controlling subscriber presses the SEND key without digits, the system connects the 34 controlling, held and third parties into a three-way call. 35
� If the controlling subscriber presses the END key, the system releases the controlling subscriber 36 and the third party. Apply distinctive recall alerting to the controlling subscriber to recall the held 37 party. 38
� If the controlling subscriber enters digits + SEND key, the system ignores any accompanying 39 digits. Connects the controlling, held and third parties into a three-way call. 40
N.S0028-0
Ballot Version 66
� If the third party answers, the system allows a conversation with the third party. 1
� If the third party disconnects, the system releases the third party. Connects the held party. 2
� If an incoming call arrives for the controlling subscriber, the system applies busy treatment to the 3 calling party. 4
� If the held party disconnects, the system releases the held party. 5
4. A connection is established between the controlling subscriber, a second party and a third party. 6
� If the controlling subscriber presses the SEND key without digits, the system releases the third 7 party. Connect the controlling subscriber and the second party. 8
� If the controlling subscriber presses the END key, the system releases the controlling subscriber 9 and two other parties. 10
� If the controlling subscriber enters digits + SEND key, the system ignores any accompanying 11 digits. Releases the third party. Connect the controlling subscriber and the second party. 12
� If the third party answers, the system allows a conversation with the third party. 13
� If the third party disconnects, the system releases the third party and connects the controlling 14 subscriber and the second party. 15
� If an incoming call arrives for the controlling subscriber, the system applies busy treatment to the 16 calling party. 17
� If the second party disconnects, the system releases the second party. Connect the controlling 18 subscriber and the third party. 19
4.5.3.2 GSM Mode 20
Only the served mobile subscriber shall be able to add remote parties to the multi-party call as 21 specified in GSM 02.84[17]. 22
4.5.3.2.1 Beginning the multi-party call 23
When the served mobile subscriber invokes multi-party, the network joins the active call and the call 24 on hold together into a multi-party call in which the served mobile subscriber and the remote parties 25 can all communicate with one another. 26
4.5.3.2.2 Managing an active multi-party call 27
During an active multi-party call, the served mobile subscriber shall be able to: 28
29
1. Add another remote party, 30
to which a private communication has been established, if the number of remote parties does not 31 then exceed the maximum number allowed, which results in an active multi-party call. 32
A MPTY invoke notification shall be sent towards all remote parties. A Retrieve notification 33 (according to GSM 02.83[16]) shall be sent towards all previously held remote parties. 34
2. Put the connection to multi-party call on hold: 35
(i.e., place her connection to the multi-party call on hold (and typically later retrieve it)). The served 36 mobile subscriber may make an enquiry call (e.g., to a potential new remote party) or process a 37
N.S0028-0
Ballot Version 67
Call Waiting request from this state. While the multi-party call is on hold the remaining remote 1 parties in the multi-party call can have communication with each other. 2
As a result of this scenario, the inquiry call or the accepted waiting call can be added to the multi-3 party call or released. If the call is released by the served mobile subscriber or by the remote 4 party, the served mobile subscriber is in control of a held multi-party call. 5
A Hold notification (according to GSM 02.83[16]) shall be sent towards all remote parties. 6
3. Separate a remote party: 7
Explicitly choose one remote party to have a private communication with. This results in that 8 remote party being removed from the multi-party call which is placed on hold, and the conversation 9 between the served mobile subscriber and the designated remote party being a normal active call. 10 The remaining remote parties may have communication with each other in this state. 11
As a result of this scenario the private communication can be added again to the multi-party call or 12 released. If the private call is released by the served mobile subscriber or by the remote party, the 13 served mobile subscriber is in control of a held multi-party call. 14
A Hold notification (according to GSM 02.83[16]) shall be sent towards all remote parties, except 15 the designated remote party to which a private communication was established. 16
4. Terminate the entire multi-party call. 17
When the served mobile subscriber releases, this is interpreted as a request for termination of the 18 entire multi-party call even if there are calls on hold. 19
No further notification shall be sent. 20
5. Disconnect a remote party: 21
Explicitly release the remote parties on a one at a time basis. In the case when no remote parties 22 remain, the multi-party call is terminated. 23
The notification about the held multiparty call towards the served mobile subscriber is given by 24 the MS, not by the network. 25
4.5.3.2.3 Managing a held multi-party call 26
During a held multi-party call the served mobile subscriber shall be able to: 27
1. Retrieve the held multi-party call, which results in an active multi-party call. 28
2. Initiate a new call. 29
3. Process a Call Waiting request. 30
4. Disconnect the held multi-party call. All calls belonging to the multi-party call shall be released. 31
5. Disconnect a single remote party. 32
During a held multi-party call the served mobile subscriber shall NOT be able to: Retrieve a single 33 remote party. 34
4.5.3.2.4 Managing a single call and a MPTY 35
a) Single active call 36
If the served mobile subscriber is connected to a single active call (regardless whether it is a private 37 communication or a new initiated call) and has a MPTY on hold, she is able to: 38
N.S0028-0
Ballot Version 68
1. Disconnect the single active call. 1
2. Disconnect the held MPTY. 2
3. Disconnect both. All calls, even if they are on hold, shall be released. 3
4. Join the single active call and the held MPTY together. 4
This would result in an active MPTY, except if the number of remote parties exceeds the number 5 allowed. 6
A MPTY invoke notification shall be sent towards all remote parties. 7
A Retrieve notification (according to GSM 02.83[16]) shall be sent towards the previously held 8 remote party. 9
5. Alternate between both calls. 10
11
b) Active MPTY and held call 12
If the served mobile subscriber is connected to a active MPTY and has a single call on hold, she is 13 able to: 14
1. Disconnect the active MPTY. 15
2. Disconnect the single held call. 16
3. Disconnect both. All calls, even if they are on hold, shall be released. 17
4. Join the single held call and the active MPTY together. 18
This would result in an active MPTY, except if the number of remote parties exceeds the number 19 allowed. 20
A MPTY invoke notification shall be sent towards all remote parties. A Retrieve notification 21 (according to GSM 02.83[16]) shall be sent towards all previously held remote parties. 22
5. Alternate between both calls. 23
If the served mobile subscriber is connected to an active Multi Party call and has a single call on 24 hold, a request for establishing a private communication shall be rejected by the network. (Because 25 this would lead to an active call and two calls on hold, which is not supported according to the GSM 26 Call Hold Supplementary Service). 27
An indication shall be given to the served mobile subscriber with the reason for failure. 28
4.5.3.2.5 Remote parties in a Multi-Party Call 29
Any of the remote parties shall be able to: 30
1. Put her connection to the multi-party call on hold (and typically later retrieve it). The requirements 31 of the Call Hold service then apply; 32
2. Release from the multi-party call. 33
If a remote party releases and no remote party then remains, the requirements of the normal call 34 release procedures then apply. 35
N.S0028-0
Ballot Version 69
4.5.3.3 Call Detail Record / Charging Requirements 1
For GSM and ANSI-41 based network interoperability, no new or special recording capabilities are 2 needed. 3
4.5.3.4 Interrogation 4
GSM mode 5
The controlling subscriber may interrogate the network by the use of a control procedure, as specified 6 in GSM 02.30[11]. The network shall respond with an appropriate indication telling the subscriber 7 whether the service is supported in this network and, if so, provide a list of all Basic Service groups to 8 which the Call waiting supplementary service is active. 9
4.5.4 Exception Procedures or Unsuccessful Outcome 10
11
4.5.4.1 Registration 12
None identified. 13
4.5.4.2 De-Registration / Erasure 14
None identified. 15
4.5.4.3 Activation 16
None identified. 17
4.5.4.4 De-Activation 18
None identified. 19
4.5.4.5 Invocation 20
ANSI-13641 Mode 21
The controlling subscriber is alerting the other party, or the controlling subscriber is in a two-way 22 conversation with the other party, if the controlling subscriber presses the SEND key, the system 23 applies denial treatment. Retain connections. 24
One party is on hold, and the system is waiting for the controlling subscriber to enter a feature code 25 or the address of a third party, 26
if the controlling subscriber enters the termination address + SEND key, if the subscriber is not 27 authorized for the request, resources are not available, or the termination address was not 28 acceptable; then ignore any accompanying digits and the system applies denial treatment. Retain 29 existing connection to party on hold. 30
if the controlling subscriber enters *FC + SEND key, if the subscriber is not authorized for the request, 31 resources are not available, or the termination address was not acceptable; then ignore any 32 accompanying digits and the system applies denial treatment. Retain existing connection to party on 33 hold. 34
if the controlling subscriber enters *FC + # + termination address + SEND key, if the subscriber is not 35 authorized for the request, resources are not available, or the termination address was not 36
N.S0028-0
Ballot Version 70
acceptable; then ignore any accompanying digits and the system applies denial treatment. Retain 1 existing connection to party on hold. 2
GSM Mode 3
If a served mobile subscriber attempts to invoke multi-party service and the network cannot accept 4 that request, the request shall be rejected and an indication shall be given to the served mobile 5 subscriber with a reason for denial. Some possible reasons for rejection are: 6
� service not subscribed; 7
� resources cannot be allocated; 8
� conflicting situation with other supplementary services; 9
� calls are not in appropriate state (e.g., one or more calls are not answered or are in the process 10 of being cleared); 11
� service not supported by the local PLMN. 12
If the service provider cannot satisfy the request to add a further remote party (e.g., if the multi-party 13 call has been cleared or if the maximum number of remote parties allowed has already been reached) 14 the served mobile subscriber shall receive an indication that the request is denied, with the reason for 15 failure. 16
If the radio path of the served mobile subscriber is lost permanently for any reason, the multi-party 17 call shall be released. 18
4.5.4.6 Exceptions While Roaming 19
None identified. 20
4.5.4.7 Exceptions During Intersystem Handoff 21
None identified. 22
4.5.5 Alternate Procedures 23
ANSI-13641 Mode 24
An alternative procedures has been identified for 3WC. This procedure builds upon the normal 3WC 25 procedures. 26
The controlling subscriber is alerting the other party, or the controlling subscriber is in a two-way 27 conversation with the other party: 28
If the controlling subscriber enters a termination address + SEND , the system puts the other party 29
on hold. Atempts to establish a connection to the termination address. 30
If the controlling subscriber enters a termination address + SEND , if the other party is alerting, the 31
controlling subscriber is not authorized for the request, resources are not available, or the 32 termination address was not acceptable; the system applies denial treatment. Reconnects the 33 controlling subscriber and the second party. 34
If the controlling subscriber enters *FC + # + termination address + SEND , the system acts upon 35
the feature code. The system applies feature confirmation treatment. Puts the other party on 36 hold. Attempts to establish a connection to the termination address. 37
N.S0028-0
Ballot Version 71
If the controlling subscriber enters *FC + # + termination address + SEND , the system acts upon 1
the feature code. If the other party is alerting, the controlling subscriber is not authorized for the 2 request, resources are not available, or the termination address was not acceptable; the system 3 applies for denial treatment. Reconnects the controlling subscriber and the second party. 4
5
GSM Mode 6
None identified. 7
8
4.5.6 Interactions With Other Features and Services 9
10
4.5.6.1 Advice of charge (AoC) 11
None identified. 12
4.5.6.2 Barring of All Outgoing Calls (BAOC) 13
None identified. 14
4.5.6.3 Barring of Outgoing International Calls (BOIC) 15
None identified. 16
4.5.6.4 Barring of Outgoing International Calls except those directed to the Home PLMN 17 (BOIC-exHC) 18
None identified. 19
4.5.6.5 Barring of All Incoming Calls (BAIC) 20
None identified. 21
4.5.6.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam) 22
None identified. 23
4.5.6.7 Call Delivery (CD) 24
None identified. 25
4.5.6.8 Call Forwarding—Busy (CFB) 26
None identified. 27
4.5.6.9 Call Forwarding—Default (CFD) 28
None identified. 29
4.5.6.10 Call Forwarding—No Answer / No Reply (CFNA / CFNRy) 30
N.S0028-0
Ballot Version 72
None identified. 1
4.5.6.11 Call Forwarding—Not Reachable (CFNRc) 2
None identified. 3
4.5.6.12 Call Forwarding—Unconditional (CFU) 4
None identified. 5
4.5.6.13 Call Transfer (CT) 6
ANSI-13641 Mode 7
CT takes precedence over 3WC. When the controlling subscriber disconnects on an active three-way 8 call, and also has CT active, then the disconnect shall be used to transfer the call and the two non-9 controlling parties remain connected. 10
To avoid a call transfer, the controlling subscriber may force a three-way call to disconnect by 11 sending a flash request to drop the last party added and then disconnecting the remaining party. 12
3WC takes precedence over CT for the interpretation of flash requests. If the controlling subscriber 13 presses SEND in the Holding 2-way state (and both CT and 3WC are active), the result is a 14
conference request rather than a CT drop party request. If the controlling subscriber presses SEND 15
while in the 3-way state, the last party is requested to be dropped. 16
4.5.6.14 Call Waiting / Call Hold (CW / HOLD) 17
ANSI-13641 Mode 18
3WC and CW are mutually exclusive. A call incoming to a controlling subscriber setting up or 19 engaged in a three-way call shall be given busy treatment, even if the called subscriber has CW 20 active. 21
A flash request from a subscriber authorized for 3WC, while CW alerting is being applied, shall be 22 used to respond to the CW call. If the controlling subscriber still desires a three-way call, it must first 23 dispose of the CW call before requesting a three-way call. 24
GSM Mode 25
A user who is active on a multi-party call, either as the served mobile subscriber or as remote party, 26 may receive an indication of a waiting call, provided that the maximum number of calls at the mobile 27 equipment is not exceeded. 28
After the multi-party call has been put on hold by this user, the waiting call may be accepted by the 29 user. 30
Any party involved in an active multi-party call may place the connection to the multi-party call on hold 31 and later retrieve it. 32
4.5.6.15 Calling Number / Line Identification Presentation (CNIP / CLIP) 33
None identified. 34
4.5.6.16 Calling Number / Line Identification Restriction (CNIR / CLIR) 35
ANSI-13641 Mode 36
N.S0028-0
Ballot Version 73
If the 3WC controlling subscriber activates the Temporary CNIR Mode during the setup of a 3WC leg, 1 then the Temporary CNIR activation applies only to that call leg. 2
If the 3WC controlling subscriber de-activates the Temporary CNIR Mode during the setup of a 3WC 3 leg, then the Temporary CNIR de-activation applies only to that call leg. 4
4.5.6.17 Calling Name Presentation (CNAP) 5
None identified. 6
4.5.6.18 Calling Name Restriction (CNAR) 7
None identified. 8
4.5.6.19 Closed User Group (CUG) 9
None identified. 10
See GSM 02.85[18], Section 1.6.84.1. 11
4.5.6.20 Conference Calling / Multi Party Service (CC / MPTY) 12
ANSI-13641 Mode 13
3WC takes precedence over CC. That is, a subscriber cannot add more parties to a 3WC call (in 14 effect trying to convert the 3WC call into a CC call). A 3WC can be converted to a two-way call with a 15 flash request to drop the last party. The two-way call can be converted into a conference call. 16
GSM Mode 17
It shall be possible for any remote party in a multi-party call to alternate between two different multi-18 party calls. 19
Served Mobile Subscriber: 20
The served mobile subscriber cannot control more than one multi-party call at a time. 21
It shall not be possible to invoke multi-party service if either or both of the initial calls are active parts 22 of one or two other multi-party calls. 23
Multi-Party call controlled by one of the remote parties: 24
The network shall not be required to prevent that a leg to one of the other remote parties can be part 25 of another multi-party call controlled by that remote party. 26
4.5.6.21 Connected line identification presentation 27
GSM Native Subscriber 28
Remote parties in an existing multi-party call who have subscribed to connected line number 29 identification presentation shall not receive a new remote party’s number whenever a served mobile 30 subscriber adds a new remote party to the multi-party call. 31
4.5.6.22 Do Not Disturb (DND) 32
None identified. 33
4.5.6.23 Emergency Services 34
N.S0028-0
Ballot Version 74
None identified. 1
4.5.6.24 Flexible Alerting (FA) 2
None identified. 3
4.5.6.25 Message Waiting Notification (MWN) 4
MWN pip tone shall only be applied for the first leg of the call. 5
4.5.6.26 Mobile Access Hunting (MAH) 6
None identified. 7
4.5.6.27 Password Call Acceptance (PCA) 8
None identified. 9
4.5.6.28 Preferred Language (PL) 10
None identified. 11
4.5.6.29 Priority Access and Channel Assignment (PACA) 12
None identified. 13
4.5.6.30 Remote Feature Control (RFC) 14
None identified. 15
4.5.6.31 Selective Call Acceptance (SCA) 16
None identified. 17
4.5.6.32 Subscriber PIN Access (SPINA) 18
3WC shall not be activated while SPINA is active. 19
4.5.6.33 Subscriber PIN Intercept (SPINI) 20
The service provider may require the 3WC invoking subscriber (with SPINI active) to enter the SPINI 21 PIN when initiating a three-way call. That is, the subscriber shall be requested to enter the SPINI PIN, 22 if the call leg to the third party meets the call type criteria for SPINI. 23
4.5.6.34 Three-Way Calling / Multi Party Service (3WC / MPTY) 24
Not applicable. 25
4.5.6.35 Voice Message Retrieval (VMR) 26
None identified. 27
4.5.6.36 Voice Privacy (VP) 28
None identified. 29
30
N.S0028-0
Ballot Version 75
1
4.6 Calling Number / Line Identification Presentation 2
3
4.6.1 General Description 4
Calling Number Identification Presentation (CNIP) or Calling Line Identification Presentation (CLIP) 5 provides the number identification of the calling party to the called subscriber. The terminating 6 network may receive the Calling Number Identification (CNI) as part of basic call setup. CNIP / CLIP 7 does not impact a subscriber's ability to originate calls or to receive calls. 8
9
4.6.1.1 Applicability to Telecommunications Services 10
For GSM native mode: CLIP applies to all circuit switched telecommunication services. 11
For ANSI native mode: CNIP applies to voice telecommunication services only. 12
4.6.2 GSM and ANSI-13641 interoperability Feature Mapping 13
The definition of which feature capabilities are mapped between GSM (in GSM 02.81[14]) and ANSI-14 13641 modes is described below. 15
16
4.6.2.1 ANSI-41 foreign mode Capabilities (GSM --> ANSI-13641 Feature Mapping) 17
The ability of the subscriber’s serving system to override calling number or line presentation 18 restriction invoked from the calling party’s serving system or PLMN is not supported. 19
Connected Line Identification Presentation and Restriction (COLP / COLR) is not supported. 20
Interrogation of the status of CLIP is not supported. 21
4.6.2.2 GSM Foreign Mode Capabilities (ANSI-13641 --> GSM Feature Mapping) 22
The ability to display multiple calling party numbers, a sub-address, or a redirecting number is not 23 explicitly defined. 24
If the called subscriber has call forwarding unconditional active, the ability to present the calling 25 number identification to the subscriber during an abbreviated (or reminder) alert is not supported. 26
4.6.3 Normal Procedures With Successful Outcome 27
4.6.3.1 Authorization (or Provision) 28
CNIP / CLIP shall be generally available after pre-arrangement with the service provider. 29
4.6.3.2 De-Authorization (or Withdrawal) 30
CNIP / CLIP may be withdrawn at the subscriber’s request or for administrative reasons. 31
4.6.3.3 Registration 32
N.S0028-0
Ballot Version 76
CNIP / CLIP has no registration. 1
4.6.3.4 De-Registration (or Erasure) 2
CNIP / CLIP has no de-registration (or erasure). 3
4.6.3.5 Activation 4
CNIP / CLIP shall be activated upon authorization (or provision). 5
4.6.3.6 De-Activation 6
CNIP / CLIP shall be de-activated upon de-authorization (or withdrawal). 7
4.6.3.7 Invocation 8
The network automatically invokes CNIP / CLIP upon incoming call set-up when calling number 9 identification is available and presentation is not restricted. 10
4.6.4 Normal Operation with Successful Outcome 11
If CNIP / CLIP service is authorized and active, and calling number identification is available, the 12 called party’s serving network shall provide the calling number identification during alerting on 13 incoming calls. In addition to or instead of the calling number identification the subscriber shall also 14 be given a Presentation Indicator and Screening Indicator associated with the calling number 15 identification. 16
The originating network shall be capable of transmitting up to 15 digits of calling party number. The 17 subscriber’s serving system must likewise be capable of delivering up to 15 digits of calling party 18 number. 19
If CNIP / CLIP service is not authorized or active, no calling number identification, presentation 20 indicator, or screening indicator shall be delivered to the subscriber, even if it is available to the 21 serving system. 22
4.6.4.1 Call Detail Record / Charging Requirements 23
For GSM and ANSI-41 based network interoperability, no new or special recording capabilities are 24 needed. 25
4.6.4.2 Interrogation 26
GSM mode only: The subscriber can request the status of the CLIP supplementary service. 27
28
4.6.5 Exception Procedures or Unsuccessful Outcome 29
30
4.6.5.1 Registration 31
None identified. 32
4.6.5.2 De-Registration / Erasure 33
N.S0028-0
Ballot Version 77
None identified. 1
4.6.5.3 Activation 2
None identified. 3
4.6.5.4 De-Activation 4
None identified. 5
4.6.5.5 Invocation 6
In some situations with insufficient signaling capability, if the calling party number identification is not 7 available, the called party / subscriber shall receive an indication that calling number identity is not 8 available. This indication may include an alphanumeric display indicatingnumber not available. 9
For an international call with calling party number identification not available, the called party / 10 subscriber shall receive an indication that calling number identity is not available. This indication may 11 include an alphanumeric display indicating number not available. 12
4.6.5.6 Exceptions While Roaming 13
Some serving systems may not offer CNIP / CLIP to any subscriber. In this case, the subscriber shall 14 receive no indication or display during alerting of an incoming call. 15
4.6.5.7 Exceptions During Intersystem Handoff 16
Some serving systems may not offer CNIP / CLIP to any subscriber. In this case, the subscriber shall 17 receive no indication or display during alerting of an incoming call. 18
4.6.6 Alternate Procedures 19
None identified. 20
21
4.6.7 Interactions With Other Features and Services 22
23
4.6.7.1 Advice of charge (AoC) 24
None identified. 25
4.6.7.2 Barring of All Outgoing Calls (BAOC) 26
None identified. 27
4.6.7.3 Barring of Outgoing International Calls (BOIC) 28
None identified. 29
4.6.7.4 Barring of Outgoing International Calls except those directed to the Home PLMN 30 (BOIC-exHC) 31
None identified. 32
N.S0028-0
Ballot Version 78
4.6.7.5 Barring of All Incoming Calls (BAIC) 1
When BAIC is active, the subscriber shall receive no calling party identification or display. 2
4.6.7.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam) 3
When BIC-Roam is active and invoked, the subscriber shall receive no calling party identification or 4 display. 5
4.6.7.7 Call Delivery (CD) 6
When Call Delivery is not active, the subscriber shall receive no calling party identification or display. 7
4.6.7.8 Call Forwarding—Busy (CFB) 8
None identified. 9
4.6.7.9 Call Forwarding—Default (CFD) 10
None identified. 11
4.6.7.10 Call Forwarding—No Answer / No Reply (CFNA / CFNRy) 12
None identified. 13
4.6.7.11 Call Forwarding—Not Reachable (CFNRc) 14
None identified. 15
4.6.7.12 Call Forwarding—Unconditional (CFU) 16
ANSI-13641 mode only: If the called subscriber has CNIP / CLIP active, the calling number 17 identification may be presented to the subscriber during an abbreviated (or reminder) alert in 18 accordance with CNIP / CLIP procedures. 19
4.6.7.13 Call Transfer (CT) 20
None identified. 21
4.6.7.14 Call Waiting / Call Hold (CW / HOLD) 22
If the called subscriber has CNIP / CLIP active, the calling party identification shall be presented to 23 the subscriber with the call waiting notification. 24
4.6.7.14.1 Calling Number / Line Identification Presentation (CNIP / CLIP) 25
Not applicable. 26
4.6.7.15 Calling Number / Line Identification Restriction (CNIR / CLIR) 27
CNIR / CLIR takes precedence over CNIP / CLIP. 28
4.6.7.16 Calling Name Presentation (CNAP) 29
Authorization and activation of CNAP may be linked to the authorization and activation of CNIP / 30 CLIP. 31
N.S0028-0
Ballot Version 79
4.6.7.17 Calling Name Restriction (CNAR) 1
Authorization and activation of CNAR may be linked to the authorization and activation of CNIR / 2 CLIR. 3
4.6.7.18 Closed User Group (CUG) 4
None identified. 5
4.6.7.19 Conference Calling / Multi Party Service (CC / MPTY) 6
None identified. 7
4.6.7.20 Do Not Disturb (DND) 8
DND takes precedence over CNIP / CLIP. When DND is active and invoked, the subscriber shall 9 receive no calling party identification or display. 10
4.6.7.21 Emergency Services 11
None identified. 12
4.6.7.22 Flexible Alerting (FA) 13
None identified. 14
4.6.7.23 Message Waiting Notification (MWN) 15
None identified. 16
4.6.7.24 Mobile Access Hunting (MAH) 17
None identified. 18
4.6.7.25 Over the Air Activation (OTA) 19
None identified. 20
4.6.7.26 Password Call Acceptance (PCA) 21
None identified. 22
4.6.7.27 Preferred Language (PL) 23
It shall be possible to present information in the subscriber’s preferred language. 24
4.6.7.28 Priority Access and Channel Assignment (PACA) 25
None identified. 26
4.6.7.29 Remote Feature Control (RFC) 27
None identified. 28
4.6.7.30 Selective Call Acceptance (SCA) 29
N.S0028-0
Ballot Version 80
None identified. 1
4.6.7.31 Subscriber PIN Access (SPINA) 2
None identified. 3
4.6.7.32 Subscriber PIN Intercept (SPINI) 4
None identified. 5
4.6.7.33 Three-Way Calling / Multi Party Service (3WC / MPTY) 6
None identified. 7
4.6.7.34 Voice Message Retrieval (VMR) 8
None identified. 9
4.6.7.35 Voice Privacy (VP) 10
None identified. 11
12
N.S0028-0
Ballot Version 81
4.7 Call Barring (CB) and Operator Determined Barring (ODB) 1
2
4.7.1 General Description 3
Call Barring (CB) Supplementary service consists of Outgoing Call Barring (OCB) and Incoming Call 4 Barring (ICB). It denies a mobile subscriber the ability to originate/terminate certain types of calls. 5 These can be applied separately per basic service group. 6
Operator Determined Barring (ODB) allows the network operator or service provider to regulate, by 7 means of an exceptional procedure, access by the subscribers to services, by the barring of certain 8 categories 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 to 10 new subscribers, or to those who have not promptly paid their bills. It may only be applied to the 11 service provider's own subscribers. 12
Application of Operator Determined Barring is controlled by the Service Provider on a subscriber-13 basis (automatically applies to all basic service groups), by administrative interaction with the HLR; 14 this interface is not standardized. 15
With the exception of the barring of roaming, the HLR effects Operator Determined Barring in a 16 similar manner to Service Provider Call Barring supplementary service. Consequently, the VLR and 17 MSC also execute the relevant Barring Conditions in similar manners. It is noted that there is no 18 password usage. Roaming is barred by the HLR when the MS is in a PLMN other than the Home 19 PLMN 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, 21 although portions of it may be implemented by an operator using ANSI-41. The following sections 22 separately describe the following GSM ODB options for which interoperability can be supported in 23 some form at least (note that the first two are also Call Barring supplementary services): 24
� Barring outgoing calls 25
� Barring incoming calls 26
� Barring of roaming 27
� Barring of Supplementary Services Management 28
� Barring of registration of call forward-to numbers 29
� Barring of invocation of call transfer 30
� Description of Barring of Outgoing Calls 31
The operator may select a barring program that prevents certain types of outgoing calls from being 32 originated by the MS. 33
ODB in GSM is documented in GSM 02.41[12]. Call Barring Supplementary Services in GSM is 34 documented in GSM 02.88[20]. 35
Barring of outgoing calls with a wider range of conditions can be implemented using the ANSI-41 36 Origination Indicator parameter, which is provided by the HLR to the serving MSC/VLR upon 37 subscriber registration, as defined in Chapter 5 of ANSI-41[3]. The Origination Indicator specifies 38 which types of call originations are permitted, as opposed to which types of call originations are 39 barred or restricted in GSM. 40
N.S0028-0
Ballot Version 82
The main problem for roaming interoperability is that for GSM and ANSI-41 the call barring programs 1 are based on different screening criteria. In GSM barring is based on the concept of PLMN, and calls 2 are generally permitted to all terminals within the country of a particular PLMN (i.e., fixed and mobile 3 terminals). ANSI-41 allows more specific barring programs such as ‘local calls only’, or a specific DN. 4 As a result of this conflict, IIF functionality is required to support subscribers using their non-native 5 mode. 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 Calls 8
GSM Native Mode ANSI-41 Equivalent
Bar all outgoing calls Origination denied
Bar all outgoing international calls National long distance allowed (which includes local calls).
Bar all outgoing international calls except to HPLMN country (BOIC-exHC)
National long distance allowed (which includes local calls).
9
Table 6: GSM Foreign Mode Interoperability for Outgoing Call Restrictions 10
ANSI-41 Native Mode GSM Equivalent (option: either ODB or OCB)
Origination denied Bar all outgoing calls (BAOC)
Local Calls Only Allowed Bar all outgoing calls (BAOC)
Selected leading digits of directory number 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
4.7.1.1 Description of Barring of Incoming Calls 12
Barring of incoming calls takes place at the HLR for native mode and foreign mode. To support 13 interoperability of barring incoming calls when roaming outside the HPLMN country (BIC-Roam), the 14 true serving system identity (SID) must be passed to the HLR upon registration. Otherwise, this 15 feature must be supported from the IIF. 16
4.7.1.2 Description of ODB Barring of Roaming 17
Barring of roaming takes place at the HLR. There is no IIF involvement, beyond the mapping of 18 registration operations between GSM and ANSI-41 based networks. Upon activation of ODB for 19 barring of roaming and ODB Barring of all Outgoing Calls when Roaming Outside the HPLMN 20 country, the HLR can be set to deny registration. The degree of granularity to which roaming can be 21 denied (e.g., roaming outside home PLMN country) shall be determined by the HLR capabilities. 22
N.S0028-0
Ballot Version 83
4.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 involvement 2 (other than transfer of services management requests between GSM and ANSI-41 based networks). 3 Upon activation of ODB for barring of supplementary services management, the HLR can be set to 4 deny these user operations. The degree to which supplementary services management can be 5 denied shall be determined by the HLR capabilities. 6
4.7.1.4 Description of ODB Barring of Registration of Call Forward-to Numbers 7
Barring of registration of call forward-to numbers takes place at the HLR. There is no IIF involvement. 8 Upon activation of ODB for barring of registration of call forward-to numbers, the HLR can be set to 9 deny registration of these numbers. The degree of granularity to which registration can be denied 10 (e.g., Barring of registration of any international call forward-to number) shall be determined by the 11 HLR capabilities. 12
4.7.1.5 Description of ODB Barring of Invocation of Call Transfer 13
Barring of call transfer is possible in ANSI-41 based networks by restriction in the subscriber profile. 14 There is no IIF involvement. It is not possible to conditionally bar call transfer (based on the charging 15 conditions for the various call legs) as described in the GSM ODB Stage 1 description. 16
4.7.1.6 Applicability to Telecommunications Services 17
CB and ODB applies to all telecommunications services except emergency calls and possibly certain 18 outgoing free calls (e.g., calls to customer care). 19
4.7.2 Normal Procedures with Successful Outcome 20
ODB is an administrative feature. There are no user procedures for authorization, de-authorization, 21 registration, or de-registration. 22
4.7.2.1 Activation 23
Table 7: Call Barring Activation Options 24
Activation Option Procedure
ODB Service provider controlled activation Determined by the service provider at provisioning time or at a later date due to administrative reasons. Cannot be controlled by the subscriber.
Call Barring Service provider controlled activation
Determined by the service provider at provisioning time or at a later date due to administrative reasons. Can be controlled by the subscriber in GSM native mode.
25 26
N.S0028-0
Ballot Version 84
4.7.2.2 De-activation 1
Table 8: Call Barring Deactivation Options 2
De-Activation Option Procedure
ODB Service provider controlled activation Determined by the service provider at provisioning time or at a later date due to administrative reasons. Cannot be controlled by the subscriber.
Call Barring Service provider controlled activation
Determined by the service provider at provisioning time or at a later date due to administrative reasons. Can be controlled by the subscriber in GSM native mode.
3
4.7.2.3 Invocation 4
Call Barring and ODB are invoked automatically by the network for subscribers that have it active, 5 upon subscriber or network actions that are barred. 6
4.7.3 Normal Operation with Successful Outcome 7
A subscriber that attempts to originate a call for which call barring or operator determined barring of 8 outgoing calls has been activated shall receive call denial treatment (e.g., a re-order tone and 9 announcement). Likewise, a caller that attempts to terminate a call for which call barring or operator 10 determined barring of incoming calls has been activated shall receive call denial treatment (e.g., a re-11 order tone and announcement). 12
A subscriber that attempts to perform other barred operations (e.g., management of supplementary 13 services) shall receive a notification indicating denial of the operation. 14
Call Barring and ODB does not affect the origination of emergency calls. 15
4.7.3.1 Call Detail Record 16
For GSM and ANSI-41 based network interoperability, no new or special recording capabilities are 17 needed. 18
19
4.7.4 Exception Procedures or Unsuccessful Outcome 20
21
4.7.4.1 Provisioning 22
Since GSM PLMNs may not support many of the provisioning criteria in ANSI-41 networks, service 23 provisioning shall revert to the closest available criterion as described above. 24
4.7.4.2 Exceptions while Roaming 25
None identified. 26
N.S0028-0
Ballot Version 85
4.7.4.3 Exceptions during Intersystem Handoff 1
None identified. 2
3
4.7.5 Interactions with Other Features and Services 4
5
4.7.5.1 Advice of Charge (AoC) or Prepaid Charging (PPC) 6
AoC and PPC take precedence over Call Barring and ODB in the following sense. If service is denied 7 by the AoC or PPC application due to non-payment, then calls shall not be delivered to or sent from 8 the mobile subscriber even if the barring program criteria are met. Whether or not forwarding to the 9 diversion number is done is beyond the scope of this document. 10
4.7.5.2 Barring of Incoming Calls (Call Barring Supplementary Services) 11
Calls shall be denied if either Operator Determined Barring or Barring Of Incoming Calls determine 12 that the call is to be barred. 13
If a call is barred due to both Operator Determined Barring and Barring Of Incoming Calls, then the 14 message or notification returned towards the caller shall be the same as if the barring was due solely 15 to Operator Determined Barring. 16
4.7.5.3 Barring of Outgoing Calls (Call Barring Supplementary Services) 17
Calls shall be denied if either Operator Determined Barring or Barring Of Outgoing Calls determine 18 that the call is to be barred. 19
If a call is barred due to both Operator Determined Barring and Barring Of Outgoing Calls, then the 20 message or notification returned towards the caller shall be the same as if the barring was due solely 21 to Operator Determined Barring. 22
4.7.5.4 Call Delivery (CD) 23
Call Barring and ODB takes precedence over CD. If an incoming call arrives for a subscriber with 24 Barring / ODB and CD active, the call is managed by the barring program first. Only if Call Barring 25 and ODB accepts the call, is CD attempted. If Barring / ODB refuses the call, the call is given barring / 26 ODB refusal treatment. 27
4.7.5.5 Call Forwarding—Busy (CFB) 28
Call Barring (CB)/ODB takes precedence over CFB. If an incoming call arrives for a subscriber with 29 both CB/ODB and CFB active, the call is screened by the CB/ODB program first. If CB and ODB 30 accepts the call, an attempt is made to deliver or terminate the call to the subscriber. If the subscriber 31 is busy, then CFB is invoked. 32
If CFB is in contravention of a Call Barring / Operator Determined Barring Category, when the latter is 33 activated, then the activation shall result in making CFB quiescent. If the subscriber attempts to 34 activate a new CFB program in contravention of a Call Barring / Operator Determined Barring 35 Category, then the activation shall be denied, and the subscriber informed of the denial. 36
4.7.5.6 ANSI-13641 Call Forwarding—Default (CFD) 37
N.S0028-0
Ballot Version 86
CB/ODB takes precedence over CFD. If an incoming call arrives for a subscriber with CB/ODB and 1 CFD active, the call is screened by CB/ODB first. If CB and ODB accepts the call, an attempt is made 2 to deliver or terminate the call to the subscriber. If the subscriber does not or cannot answer the call, 3 then CFD is invoked. 4
If CFD is in contravention of a Call Barring / Operator Determined Barring Category, when the latter is 5 activated, then the activation shall result in making CFD quiescent. If the subscriber attempts to 6 activate a new CFD program in contravention of a Call Barring / Operator Determined Barring 7 Category, then the activation shall be denied, and the subscriber informed of the denial. 8
Call Forwarding—No Answer (ANSI-13641 CFNA = GSM CF No Reply (CFNRy) and GSM CF Not 9 Reachable (CFNRc)) 10
CB/ODB takes precedence over CFNA. If an incoming call arrives for a subscriber with CB/ODB and 11 CFNA active, the call is screened by CB/ODB first. If CB and ODB accepts the call, an attempt is 12 made to deliver or terminate the call to the subscriber. If the subscriber does not or cannot answer the 13 call, then CFNA is invoked. 14
If CFNA is in contravention of a Call Barring / Operator Determined Barring Category, when the latter 15 is activated, then the activation shall result in making CFNA quiescent. If the subscriber attempts to 16 activate a new CFNA program in contravention of a Call Barring / Operator Determined Barring 17 Category, then the activation shall be denied, and the subscriber informed of the denial. 18
4.7.5.7 Call Forwarding—Unconditional (CFU) 19
Interaction between ODB and CFU is beyond the scope of this Standard. The following describes a 20 possible implementation: 21
CB/ODB takes precedence over CFU. If an incoming call arrives for a subscriber with CB/ODB and 22 CFU active, incoming calls are denied according to the ODB option, except when Barring of Incoming 23 Calls when Roaming Outside the HPLMN country is active, CFU has precedence). 24
If CFU is in contravention of a Call Barring/ Operator Determined Barring Category, when the latter is 25 activated, then the activation shall result in making CFU quiescent, (except in the case of Barring of 26 Incoming Calls when Roaming outside the HPLMN Country, in which case CFU takes precedence). If 27 the subscriber attempts to activate a new CFU program in contravention of a Call Barring / Operator 28 Determined Barring Category, then the activation shall be denied, and the subscriber informed of the 29 denial. 30
4.7.5.8 Call Transfer (CT) 31
If the subscriber attempts to invoke a call transfer in contravention of a Call Barring / Operator 32 Determined Barring category, then the invocation shall be denied, and the subscriber informed of the 33 denial. 34
4.7.5.9 Call Waiting (CW) or Call Hold (CH) 35
ODB takes precedence over CW. Incoming calls to the subscriber with CB/ODB and CW active shall 36 be screened by the CB/ODB feature before being considered for CW. 37
4.7.5.10 Calling Number/Line Identification Presentation (CNIP/CLIP) 38
None identified. 39
4.7.5.11 Calling Number/Line Identification Restriction (CNIR/CLIR) 40
If the calling number indicatespresentation restricted, the calling number shall not be presented to the 41 called party, the called station, the diversion party, or the diversion station. 42
N.S0028-0
Ballot Version 87
4.7.5.12 Closed User Group (CUG) 1
See GSM 02.85[18]. 2
If a call is barred due to both Call Barring / Operator Determined Barring and CUG restrictions, then 3 the message or notification returned towards the caller shall be the same as if the barring was due 4 solely to Call Barring / Operator Determined Barring. 5
4.7.5.13 Conference Calling / Multi Party Service (CC / MPTY) 6
None identified. 7
4.7.5.14 Do Not Disturb (DND) 8
Interaction between CB/ODB and DND is beyond the scope of this Standard. The following describes 9 a possible implementation: 10
CB/ODB takes precedence over DND. That is, an incoming call to a subscriber with CB/ODB and 11 DND active is given CB/ODB treatment. 12
4.7.5.15 Emergency Services 13
Emergency Services takes precedence over CB/ODB. A call to or from an authorized emergency 14 service bureau shall not be refused by CB/ODB. 15
4.7.5.16 Flexible Alerting (FA) 16
Interaction between FA and CB/ODB is beyond the scope of this Standard. The following describes a 17 possible implementation: 18
CB/ODB on the FA Pilot Directory Number takes precedence over FA. That is, calls to the FA Pilot 19 Directory Number with ODB active are given ODB treatment first. If CB/ODB screening fails, the call 20 is refused. If CB/ODB screening passes, the call is given FA treatment. 21
4.7.5.17 Message Waiting Notification (MWN) 22
None identified. 23
4.7.5.18 Mobile Access Hunting (MAH) 24
Interaction between MAH and CB/ODB is beyond the scope of this Standard. The following describes 25 a possible implementation: 26
CB/ODB of the MAH Pilot Directory Number takes precedence over MAH. That is, calls to the MAH 27 Pilot Directory Number with CB/ODB active are given CB/ODB treatment first. If CB/ODB screening 28 fails, the call is refused. If CB/ODB screening passes, the call is given MAH treatment. 29
4.7.5.19 Password Call Acceptance (BIC) 30
Not applicable. 31
4.7.5.20 Preferred Language (PL) 32
None identified. 33
4.7.5.21 Priority Access and Channel Assignment (PACA) 34
N.S0028-0
Ballot Version 88
None identified. 1
4.7.5.22 Remote Feature Control (RFC) 2
TBD. 3
4.7.5.23 Subscriber PIN Access (SPINA) 4
None identified 5
4.7.5.24 Subscriber PIN Intercept (SPINI) 6
None identified. 7
4.7.5.25 Three-Way Calling (3WC) 8
None identified. 9
4.7.5.26 Voice Message Retrieval (VMR) 10
None identified. 11
4.7.5.27 Voice Privacy (VP) 12
None identified. 13
N.S0028-0
Ballot Version 89
4.8 Short Message Teleservice Support (ANSI-41136 Networks) 1
2
4.8.1 General Description 3
A short message teleservice is a mechanism for information delivery end to end between two Short 4 Message Entities (SMEs). The source of the information may be a mobile station or a Teleservice 5 Server (TS). The information may be text based, (e.g., an ANSI-41136 Cellular Messaging 6 Teleservice (TDMA or CDMA CMTCMT or an CDMA CMT) message or a GSM short message 7 service (SMS) text message), or it may be coded information destined for the mobile station’s storage 8 and use, (e.g., over the air activation or programming data, or GSM Message Waiting Indication 9 (MWI)). In ANSI-41136, unique teleservice formats are defined to deliver different types of 10 information. Conversely, in GSM, both text based and coded information is generically delivered via 11 GSM SMS. The information delivered from the source to the destination is known as user data. 12
SMS teleservices require the use of a Short Message Service Center (SMS-C), also called a 13 Message Center (MC) or Teleservice Server (TS) in ANSI-41136, to provide store and forward 14 functions. Thus, an ANSI-41136 or GSM network needs to support the transfer of SMS teleservice 15 messages between the SMS-C and the mobile station. For each subscriber, a different SMS-C may 16 be assigned as the home SMS-C for each SMS teleservice. For mobile originated teleservices, the 17 address of the home SMS-C can be provided by the mobile station. The address of the SMS-C would 18 be used for routing purposes in the network when the mobile station originates a SMS teleservice 19 message. 20
Two different categories of point-to-point SMS teleservices have been defined: mobile originated 21 (MO) and mobile terminated (MT). Mobile originated SMS messages shall be transported from a 22 mobile station to the subscriber’s home SMS-C. These may be destined for other mobile users, or for 23 subscribers on a fixed network. Mobile terminated messages shall be transported from the SMS-C to 24 a mobile station. These may be sent to the SMS-C from other mobile users (via a mobile originated 25 SMS teleservice) or from a variety of other sources, (e.g., speech, telex, facsimile, and gateway 26 server). 27
An active mobile station (MS) shall be able to receive an SMS teleservice message at any time it is in 28 service on a GSM or ANSI-41136 digital network, independently of whether or not there is a voice or 29 data call in progress. An acknowledgement message shall always be returned to the SMS-C, either 30 confirming that the mobile station has received the teleservice message, or informing the SMS-C that 31 it was impossible to deliver the short message to the mobile station, including the reason why. 32
An active mobile station shall be able to submit a teleservice message at any time it is in service on a 33 GSM or ANSI-41136 digital network, independently of whether or not there is a voice or data call in 34 progress. An acknowledgement message shall always be returned to the mobile station, either 35 confirming that the SMS-C has received the teleservice message, or informing the mobile station that 36 it was impossible to deliver the teleservice message to the SMS-C, including the reason why. 37
Both ANSI-41136 and GSM native subscribers shall be capable of submitting and receiving SMS 38 teleservice messages in both native and foreign mode. Note that teleservice delivery is not supported 39 in analog AMPS mode. 40
The support of privacy indicators, character sets, validity periods and alert options shall be limited by 41 existing standards. 42
43
N.S0028-0
Ballot Version 90
4.8.2 Normal Procedures with Successful Outcome 1
This section describes the normal procedures that result in a successful outcome. 2
4.8.2.1 Authorization (or Provision) 3
The service is made available to an individual subscriber after necessary arrangements have been 4 made with the home service provider. Authorized service may include: 5
� Only mobile originated SMS teleservices 6
� Only mobile terminated SMS teleservices 7
� Both mobile originated and mobile terminated SMS teleservices 8
4.8.2.2 De-Authorization (or Withdrawal) 9
The service is removed on an individual basis from subscribers provided with the service after 10 necessary arrangements have been made with the home service provider. Authorized service may 11 include: 12
� Only mobile originated SMS teleservices 13
� Only mobile terminated SMS teleservices 14
� Both mobile originated and mobile terminated SMS teleservices 15
4.8.2.3 Registration 16
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 mobile 18 station: 19
SMS-C address(es) as needed for different mobile originated SMS teleservices or applications. 20
4.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
4.8.2.5 Activation 25
Both mobile originated and mobile terminated SMS teleservices shall be activated as the result of 26 authorization. When operating in GSM or ANSI-41 foreign mode, there is no special activation 27 process required. 28
4.8.2.6 De-Activation 29
Both mobile originated and mobile terminated SMS teleservice de-activation shall be the result of de-30 authorization. When operating in GSM or ANSI-41 foreign mode, there is no special de-activation 31 process required. 32
33
N.S0028-0
Ballot Version 91
4.8.2.7 Invocation 1
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
4.8.2.8 Interrogation 5
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-C 7 addresses registered on their mobile station. 8
4.8.3 Normal Operation with Successful Outcome 9
For mobile terminated SMS teleservices, the following normal operation applies. Upon receiving a 10 request from an SME, the SMS-C shall: 11
� Determine the location of the mobile station 12
� Attempt to deliver the user data to the mobile station 13
� 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 station 15 shall send user data to the network including the following information: 16
� Destination address; 17
� Home SMS-C address; 18
� Originating mobile identifier 19
� If notification is required. 20
If notification was requested, an indication shall be passed back to the user. 21
4.8.3.1 Call Detail Record / Charging Requirements 22
For GSM and ANSI-13641 interoperability, no new or special recording capabilities are needed. 23
4.8.4 Exception Procedures or Unsuccessful Outcome 24
This section describes abnormal situations not described in “Normal Operation with Successful 25 Outcome”. Procedures on time-outs, unexpected signaling responses, and other such events may be 26 defined. 27
4.8.4.1 Authorization (or Provision) 28
An attempt to re-provision an already provisioned service shall result in an indication to the service 29 provider. 30
4.8.4.2 De-Authorization / Withdrawal 31
An attempt to withdraw a service that has not been provisioned shall result in an indication being 32 provided to the service provider. 33
N.S0028-0
Ballot Version 92
4.8.4.3 Registration 1
None identified at this time. 2
4.8.4.4 De-registration / Erasure 3
Not applicable. 4
4.8.4.5 Activation 5
Not applicable. 6
4.8.4.6 De-Activation 7
Not applicable. 8
4.8.4.7 Invocation 9
For mobile terminated teleservices, if the SMS-C attempts to deliver user data to the mobile station 10 and 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 network 19 and is unsuccessful, the user shall be presented with an indication. Possible causes may include: 20
� insufficient network resources 21
� service not supported 22
� service not subscribed to 23
� insufficient information; 24
� conflicting situation with other supplementary services (e.g., call barring has been activated). 25
4.8.4.8 Interrogation 26
Not applicable. 27
4.8.4.9 Exceptions while Roaming 28
None. 29
4.8.4.10 Exceptions during Intersystem Handoff 30
None Identified 31
N.S0028-0
Ballot Version 93
4.8.5 Alternate Procedures 1
None Identified 2
4.8.6 Interactions with Other Features and Services 3
4
4.8.6.1 Advice of charge (AoC) 5
None Identified 6
4.8.6.2 Barring of All Outgoing Calls (BAOC) 7
Per GSM 02.04[9], BAOC shall inhibit SMS origination, but this interaction is generally not invoked. 8
4.8.6.3 Barring of Outgoing International Calls (BOIC) 9
Per GSM 02.04[9], BOIC shall inhibit SMS origination, but this interaction is generally not invoked. 10
4.8.6.4 Barring of Outgoing International Calls except those directed to the Home PLMN 11 (BOIC-exHC) 12
Per GSM 02.04[9], BOIC-exHC shall inhibit SMS origination, but this interaction is generally not 13 invoked. 14
4.8.6.5 Barring of All Incoming Calls (BAIC) 15
Per GSM 02.04[9], BAIC shall inhibit SMS delivery, but this interaction is generally not invoked. 16
4.8.6.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam) 17
Per GSM 02.04[9], BIC-Roam shall inhibit SMS delivery, but this interaction is generally not invoked. 18
4.8.6.7 Call Delivery (CD) 19
None Identified 20
4.8.6.8 Call Forwarding—Busy (CFB) 21
None Identified 22
4.8.6.9 Call Forwarding—Default (CFD) 23
None Identified 24
4.8.6.10 Call Forwarding—No Answer / No Reply (CFNA / CFNRy) 25
None Identified 26
4.8.6.11 Call Forwarding—Not Reachable (CFNRc) 27
None Identified 28
4.8.6.12 Call Forwarding—Unconditional (CFU) 29
N.S0028-0
Ballot Version 94
None Identified 1
4.8.6.13 Call Transfer (CT) 2
None Identified 3
4.8.6.14 Call Waiting / Call Hold (CW / HOLD) 4
None Identified 5
4.8.6.15 Calling Number / Line Identification Presentation (CNIP / CLIP) 6
None Identified 7
4.8.6.16 Calling Number / Line Identification Restriction (CNIR / CLIR) 8
None Identified 9
4.8.6.17 Calling Name Presentation (CNAP) 10
None Identified 11
4.8.6.18 Calling Name Restriction (CNAR) 12
None Identified 13
4.8.6.19 Closed User Group (CUG) 14
None Identified 15
4.8.6.20 Conference Calling / Multi Party Service (CC / MPTY) 16
None Identified 17
4.8.6.21 Do Not Disturb (DND) 18
None Identified 19
4.8.6.22 Emergency Services 20
None Identified 21
4.8.6.23 Flexible Alerting (FA) 22
None Identified 23
4.8.6.24 Message Waiting Notification (MWN) 24
None Identified 25
4.8.6.25 Mobile Access Hunting (MAH) 26
None Identified 27
4.8.6.26 Password Call Acceptance (PCA) 28
N.S0028-0
Ballot Version 95
None Identified 1
4.8.6.27 Preferred Language (PL) 2
None Identified 3
4.8.6.28 Priority Access and Channel Assignment (PACA) 4
None Identified 5
4.8.6.29 Remote Feature Control (RFC) 6
None Identified 7
4.8.6.30 Selective Call Acceptance (SCA) 8
None Identified 9
4.8.6.31 Subscriber PIN Access (SPINA) 10
None Identified 11
4.8.6.32 Subscriber PIN Intercept (SPINI) 12
None Identified 13
4.8.6.33 Three-Way Calling / Multi Party Service (3WC / MPTY) 14
None Identified 15
4.8.6.34 Voice Message Retrieval (VMR) 16
None Identified 17
4.8.6.35 Voice Privacy (VP) 18
None Identified 19
N.S0028-0
Ballot Version 96
4.9 Message Waiting Notification 1
2
4.9.1 General Description 3
Message Waiting Notification (MWN) informs authorized and activated subscribers when a voice 4 message is available for retrieval. 5
MWN may use pip tone, alert pip tone, or a MS display indication (including message waiting 6 indication and message waiting count) to inform a subscriber of an unretrieved voice message(s). 7 Once all voice messages have been retrieved, the pip tone, alert pip tone, or a MS display indication 8 must be removed. 9
Pip tone notification provides an audible, stuttered tone to the subscriber in the initial moment of a call 10 origination or termination. Alert pip tone provides an audible alert tone to the subscriber when the MS 11 is idle. MS display indication provides an icon or display text or both indications of the number of 12 unretrieved voice messages (i.e. count). 13
If MS display indication with count is provided, and the number of unretrieved voice messages has 14 increased, 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 other 16 features or supplementary services. 17
4.9.1.1 Applicability to Telecommunications Services 18
Message Waiting Notification applies to voice telecommunication services. 19
4.9.1.2 GSM and ANSI-13641 interoperability Feature Mapping 20
The definition of which feature capabilities are mapped between GSM and ANSI-13641 modes is 21 described below. 22
4.9.1.2.1 ANSI-41 foreign mode Capabilities (GSM --> ANSI-13641 Feature Mapping) 23
MWN is done via an MS display message waiting indication. An MS display message waiting count is 24 provided 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
4.9.1.2.2 GSM Foreign Mode Capabilities (ANSI-13641 --> GSM Feature Mapping) 27
Audible pip tone notification is not supported, but MS display indication shall be provided as required. 28 The ability to activate and de-activate various means of MWN alerting shall not be supported. 29
4.9.2 Normal Procedures With Successful Outcome 30
4.9.2.1 Authorization (or Provision) 31
MWN may be generally available or may be provided after pre-arrangement with the service provider. 32 Pip tone, alert pip tone, or MS display indication (including message waiting indication and message 33 waiting count) are provided at the option of the service provider in ANSI-13641 mode. Only MS 34 display indication is provided in GSM mode. 35
N.S0028-0
Ballot Version 97
Authorization on demand by the subscriber, as described in ANSI-664[1], shall be optionally 1 supported in ANSI-13641 native mode only. 2
4.9.2.2 De-Authorization (or Withdrawal) 3
MWN is withdrawn by the service provider. 4
4.9.2.3 Registration 5
MWN is registered upon authorization. 6
4.9.2.4 De-Registration (or Erasure) 7
MWN is de-registered upon de-authorization. 8
4.9.2.5 Activation 9
MWN shall be activated upon authorization. Activation on demand by the subscriber, as described in 10 ANSI-664[1], shall be optionally supported in ANSI-13641 native mode only. 11
4.9.2.6 De-Activation 12
MWN shall be de-activated upon de-authorization. 13
4.9.2.7 Invocation 14
MWN alert pip tone is invoked when the first voice message is left in a VMS for a particular 15 subscriber. MWN alert pip tone is also invoked upon MS power up and there is one or more 16 unretrieved voice messages in the VMS. Alert pip tone notification is provided when authorized by the 17 service provider in ANSI-13641 mode only. 18
MWN pip tone is invoked when a voice message is left and remains unretrieved in a Voice Message 19 System (VMS) for a particular subscriber, and the subscriber originates a call or answers an incoming 20 call. Pip tone notification is provided when authorized by the service provider in ANSI-13641 mode 21 only. 22
MS display indication is invoked when a voice message is left in a VMS for a particular subscriber. It 23 is also invoked when ANSI-41 registration procedures are invoked for a subscriber and there is an 24 unretrieved voice message in the VMS for the subscriber. In ANSI-13641 mode, the message waiting 25 count indication may be updated each time the number of messages in the VMS changes. 26
4.9.3 Normal Operation with Successful Outcome 27
Alert pip tone shall be applied when the MS powers up and a voice message remains unretrieved in 28 the VMS. The alert pip tone shall also be applied when the first voice message is left on a VMS and 29 the MS is available and not engaged in a call or service request. 30
Pip tone notification shall be inserted into the voice channel when the subscriber originates a call or 31 answers an incoming call and a voice message is awaiting retrieval. 32
The MS display message waiting indication shall be provided to an MS as long as there is an 33 unretrieved voice message in the VMS. The MS display indication (including message waiting 34 indication and message waiting count) is removed from the MS after the last voice message has been 35 retrieved from the VMS. 36
4.9.3.1 Call Detail Record / Charging Requirements 37
N.S0028-0
Ballot Version 98
For GSM and ANSI-41 based network interoperability, no new or special recording capabilities are 1 needed. 2
4.9.3.2 Interrogation 3
Not applicable 4
4.9.4 Exception Procedures or Unsuccessful Outcome 5
6
4.9.4.1 Registration 7
None identified. 8
4.9.4.2 De-Registration / Erasure 9
None identified. 10
4.9.4.3 Activation 11
None identified. 12
4.9.4.4 De-Activation 13
None identified. 14
4.9.4.5 Invocation 15
None identified. 16
4.9.4.6 Exceptions While Roaming 17
None identified. 18
4.9.4.7 Exceptions During Intersystem Handoff 19
None identified. 20
4.9.5 Alternate Procedures 21
None identified. 22
4.9.6 Interactions With Other Features and Services 23
24
4.9.6.1 Advice of charge (AoC) 25
None identified. 26
4.9.6.2 Barring of All Outgoing Calls (BAOC) 27
None identified. 28
N.S0028-0
Ballot Version 99
4.9.6.3 Barring of Outgoing International Calls (BOIC) 1
None identified. 2
4.9.6.4 Barring of Outgoing International Calls except those directed to the Home PLMN 3 (BOIC-exHC) 4
None identified. 5
4.9.6.5 Barring of All Incoming Calls (BAIC) 6
None identified. 7
4.9.6.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam) 8
None identified. 9
4.9.6.7 Call Delivery (CD) 10
None identified. 11
4.9.6.8 Call Forwarding—Busy (CFB) 12
None identified. 13
4.9.6.9 Call Forwarding—Default (CFD) 14
None identified. 15
4.9.6.10 Call Forwarding—No Answer / No Reply (CFNA / CFNRy) 16
None identified. 17
4.9.6.11 Call Forwarding—Not Reachable (CFNRc) 18
None identified. 19
4.9.6.12 Call Forwarding—Unconditional (CFU) 20
None identified. 21
4.9.6.13 Call Transfer (CT) 22
None identified. 23
4.9.6.14 Call Waiting / Call Hold (CW / HOLD) 24
No pip tone notification shall be provided if call waiting has been deactivated. 25
4.9.6.15 Calling Number / Line Identification Presentation (CNIP / CLIP) 26
None identified. 27
4.9.6.16 Calling Number / Line Identification Restriction (CNIR / CLIR) 28
None identified. 29
N.S0028-0
Ballot Version 100
4.9.6.17 Calling Name Presentation (CNAP) 1
None identified. 2
4.9.6.18 Calling Name Restriction (CNAR) 3
None identified. 4
4.9.6.19 Closed User Group (CUG) 5
None identified. 6
4.9.6.20 Conference Calling / Multi Party Service (CC / MPTY) 7
Any pip tone notification shall only be applied to the primary leg of a multiparty call. 8
4.9.6.21 Do Not Disturb (DND) 9
MWN MS indication, count, and pip tone takes precedence over DND. MWN indication and pip tone 10 may still be applied while DND is active. 11
DND takes precedence over MWN alert pip tone. That is, while DND is active, alerting shall not be 12 applied. 13
4.9.6.22 Emergency Services 14
None identified. 15
4.9.6.23 Flexible Alerting (FA) 16
None identified. 17
4.9.6.24 Message Waiting Notification (MWN) 18
Not applicable. 19
4.9.6.25 Mobile Access Hunting (MAH) 20
None identified. 21
4.9.6.26 Over the Air Activation (OTA) 22
None identified. 23
4.9.6.27 Password Call Acceptance (PCA) 24
None identified. 25
4.9.6.28 Preferred Language (PL) 26
None identified. 27
4.9.6.29 Priority Access and Channel Assignment (PACA) 28
None identified. 29
N.S0028-0
Ballot Version 101
4.9.6.30 Remote Feature Control (RFC) 1
None identified. 2
4.9.6.31 Selective Call Acceptance (SCA) 3
None identified. 4
4.9.6.32 Subscriber PIN Access (SPINA) 5
None identified. 6
4.9.6.33 Subscriber PIN Intercept (SPINI) 7
None identified. 8
4.9.6.34 Three-Way Calling / Multi Party Service (3WC / MPTY) 9
Any pip tone notification shall only be applied to the primary leg of a three-way call. 10
4.9.6.35 Voice Message Retrieval (VMR) 11
None identified. 12
4.9.6.36 Voice Privacy (VP) 13
None identified. 14
15
N.S0028-0
Ballot Version 102
4.10 GPRS in GSM Foreign mode 1
GPRS in GSM Foreign mode applies to the case where an ANSI-41 based subscriber (e.g., an ANSI-2 41, TDMA or CDMA136 native subscriber) has registered on a GPRS network [22]. 3
GPRS in GSM Foreign Mode allows a subscriber to an ANSI-41 based network (e.g., an ANSI-41, 4 TDMA or CDMA136 native subscriber) to obtain GPRS service (i.e., register for service) in GSM 5 Foreign Mode. There is no impact on ANSI-41 Foreign Mode. There is no communication between a 6 GSM SGSN and an ANSI-41 MSC and a mobile can not operate simultaneously on GPRS and ANSI-7 41 systems. 8
In GSM Foreign Mode it is required that the handset register on a GSM network or a GPRS network 9 to be in GSM Foreign Mode. The GPRS network may be coupled with a GSM network (i.e., one 10 PLMN can provide both GSM circuit-switched and packet service). 11
4.10.1 General Description 12
GPRS is applicable to telecommunications services and can be a bearer for SMS teleservices. 13
4.10.2 Normal Procedures With Successful Outcome 14
Subscribers operating GPRS in GSM foreign mode (e.g., ANSI-41, TDMA or CDMA136 native 15 subscribers) shall be able to send and receive GPRS service packets when attached to a GPRS 16 network. 17
4.10.2.1 Authorization (or Provision) 18
GPRS subscription data must be provisioned and stored on the IIF, acting as the GPRS HLR. It may 19 be possible to provision a TDMA ANSI-41 native subscriber with GPRS only service and no GSM CS 20 service. 21
4.10.2.2 De-Authorization (or Withdrawal) 22
The de-authorization shall be possible at the IIF, acting as the GPRS HLR, as well as at the 23 Authentication Center. 24
4.10.2.3 Authentication 25
The GPRS network shall query the IIF, acting as a GPRS HLR, to verify the authentication 26 parameters. This may occur upon with GPRS attach and GPRS routing area update operations. 27
4.10.2.4 ANSI-41 registration 28
ANSI-41 registration occurs when the subscriber roams into an ANSI-41 network and is: 29
� registered on a GSM MSC and a GPRS SGSN; or 30
� registered on a GPRS SGSN; or 31
� registered on a GSM MSC. 32
ANSI-41 registration in all of these conditions shall result in a cancel location towards one or both of 33 the GSM MSC and GPRS SGSN, if the subscriber is registered to that network element. 34
4.10.2.5 GPRS Attach 35
N.S0028-0
Ballot Version 103
The MS shall perform a GPRS attach to access GPRS services. This can be immediately after the 1 MS has been switched on or later as the user decides to use the GPRS service. 2
A successful GPRS attach requires a valid GPRS subscription. 3
The GPRS attach itself may be performed as one of the following: 4
� GPRS only attach; or 5
� GPRS attach when GSM CS attached; or 6
� combined GPRS and GSM CS attach. 7
If one of the above GPRS attaches takes place when previously registered on an ANSI-41 network, 8 normal registration cancellation within the ANSI-41 network shall take place. 9
4.10.2.6 GPRS Detach 10
A GPRS detach allows: 11
� an MS to inform the network that it does not want to access GPRS services any longer; and 12
� the network to inform the MS that it does not have access to the GPRS services any longer. 13
The GPRS detach itself may be performed as one of the following: 14
� GPRS only detach; 15
� GPRS detach when GSM CS attached; 16
� combined GPRS and GSM CS detach. 17
The MS is detached either explicitly or implicitly as follows: 18
� Explicit Detach: the network or the MS explicitly requests detach. 19
� Implicit Detach: the network detaches the MS, without notifying the MS. 20
4.10.2.7 GPRS Routing Area Update 21
A routing area update occurs when a GPRS attached MS detects that it has entered a new routing 22 area or when the periodic routing area update timer has expired. These may be combined with GSM 23 CS location area updates depending on the network mode of operation. 24
The following GPRS Routing Area Updates are possible: 25
� intra SGSN Routing Area Update. 26
� inter SGSN Routing Area Update. 27
The following combined RA and LA updates takes place when an association exists between the 28 SGSN and the MSC [22]: 29
� combined Intra SGSN RA and LA update. 30
� combined Inter SGSN RA and LA update. 31
4.10.2.8 SMS Impacts 32
GPRS has the following impacts on SMS: 33
N.S0028-0
Ballot Version 104
� When operating GPRS in GSM Foreign mode, and both GPRS attached and GSM CS 1 attached, the mobile may originate mobile-originated SMS messages either thru the GSM 2 network or the GPRS network. When operating only in GPRS mode, SMS originations thru the 3 GPRS network shall be possible. 4
� When operating GPRS in GSM Foreign mode, and both GPRS attached and GSM CS 5 attached, the mobile shall receive mobile-terminated SMS messages either thru the GSM 6 network or the GPRS network. When operating in GPRS only mode, SMS terminations shall be 7 possible. 8
For GSM native subscribers in GSM native mode, the GSM SMS Service Center (i.e., SMSC) queries 9 the combined GSM-GPRS HLR for routing information and the HLR responds with both the SGSN 10 address as well as the GSM MSC address. Then the SMSC decides to send the SMS message to 11 either the GPRS SGSN or the GSM MSC. 12
For GPRS in GSM Foreign Mode the ANSI MC shall query the ANSI-41 HLR for the ANSI-41 MSC 13 address and shall be instructed to route the ANSI-41 formatted SMS message to the IIF, emulating 14 both an ANSI-41 MSC and a GSM SMSC, for any of the following conditions: 15
� when the subscriber is both GSM CS attached and GPRS attached; or 16
� when the subscriber is GPRS only attached; or 17
� when the subscriber is GSM CS only attached. 18
The IIF shall then convert the mobile-terminated ANSI-41 SMS message to a GSM-formatted SMS 19 message and, acting like a GSM SMSC, send it to the GSM MSC or the GPRS SGSN. If the MS is 20 reachable a Network option for routing the SMS messages may be as follows: 21
� first - send to the GPRS SGSN; 22
� second - send to the GSM MSC. 23
4.10.3 Exception Procedures or Unsuccessful Outcome 24
In the event that the IIF is not able to authenticate the GPRS subscriber, the GPRS service shall be 25 denied. If the ANSI-41 registration process fails due to location update failure or authentication failure, 26 the MS shall be denied access to the GPRS network. 27
In the event that the IIF receives a mobile terminating ANSI-41 formatted SMS message, and if the 28 IIF detects that the GSM Foreign Mode subscriber is not reachable (for both packet and circuit-29 switched services), the IIF shall reply to the ANSI-41 Message Center with an error and when the IIF 30 detects that the subscriber is again reachable, either GPRS or non-GPRS, then the IIF shall notify the 31 Message Center to retransmit the ANSI-41 formatted SMS message to the IIF. 32
The GPRS SGSN shall notify (i.e., alert) the IIF, acting as a GPRS HLR, when the handset has 33 memory available and when the handset is “MS present”. 34
GSM GPRS HLR fault recovery procedures shall also apply to the IIF acting as the GPRS HLR. 35
4.10.3.1 GPRS Attach 36
None identified. 37
4.10.3.2 GPRS Detach 38
None identified. 39
4.10.3.3 Exceptions While Roaming 40
N.S0028-0
Ballot Version 105
None identified. 1
4.10.3.4 Exceptions During Intersystem Handoff 2
None identified. 3
4.10.4 Alternate Procedures 4
None identified. 5
4.10.5 Interactions With Other Features and Services 6
7
4.10.5.1 Advice of charge (AoC) 8
None identified 9
4.10.5.2 Authentication 10
GSM authentication procedures are required to be supported by the IIF in the GPRS home network. 11 For GPRS in GSM Foreign Mode the authentication procedure is done according to the procedures 12 defined in GSM 02.09[21]. 13
4.10.5.3 Barring of All Outgoing Calls (BAOC) 14
ODB_BAOC may be provisioned in the IIF, acting as a GPRS HLR, and it applies to Mobile 15 Originated SMS via the GPRS network. 16
4.10.5.4 Barring of Outgoing International Calls (BOIC) 17
ODB_BOIC may be provisioned in the IIF, emulating a GPRS HLR, and it applies to Mobile 18 Originated SMS via the GPRS network. 19
4.10.5.5 Barring of Outgoing International Calls except those directed to the Home PLMN 20 (BOIC-exHC) 21
ODB_BOIC-exHC may be provisioned in the IIF, emulating a GPRS HLR, and it applies to Mobile 22 Originated SMS via the GPRS network. 23
4.10.5.6 Operator Determined Barring PLMN-specific 24
Four ODB PLMN-specific barring programs may be provisioned in the IIF, emulating a GPRS HLR, 25 and each applies to Mobile Originated SMS via the GPRS network. 26
4.10.5.7 Barring of All Incoming Calls (BAIC) 27
ODB_BAIC may be provisioned in the IIF, emulating a GPRS HLR, and it applies for GPRS and 28 Mobile Terminated SMS deliveries thru the GPRS network. 29
4.10.5.8 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam) 30
None identified. 31
4.10.5.9 Call Delivery (CD) 32
N.S0028-0
Ballot Version 106
When a subscriber receives a call termination attempt when operating in GSM foreign mode (e.g., 1 ASNI-41, TDMA or CDMA136 native subscriber) and connected to a GPRS network, the GSM 2 Circuit-switched paging is sent through the GPRS SGSN and the IIF is not impacted.1 3
Call terminations to the subscriber (e.g., ANSI-41, TDMA or CDMA136 native subscriber) operating in 4 GPRS only mode shall not be possible. However, it is possible for the IIF to send a SMS message to 5 the user thru the GPRS network indicating the calling party number of the missed call. 6
4.10.5.10 Call Forwarding—Busy (CFB) 7
None identified. 8
4.10.5.11 Call Forwarding—Default (CFD) 9
None identified. 10
4.10.5.12 Call Forwarding—No Answer / No Reply (CFNA / CFNRy) 11
None identified. 12
4.10.5.13 Call Forwarding—Not Reachable (CFNRc) 13
None identified. 14
4.10.5.14 Call Forwarding—Unconditional (CFU) 15
None identified. 16
4.10.5.15 Call Transfer (CT) 17
None identified. 18
4.10.5.16 Call Waiting / Call Hold (CW / HOLD) 19
None identified. 20
4.10.5.17 Calling Number / Line Identification Presentation (CNIP / CLIP) 21
None identified. 22
4.10.5.18 Calling Number / Line Identification Restriction (CNIR / CLIR) 23
None identified. 24
4.10.5.19 Calling Name Presentation (CNAP) 25
None identified. 26
4.10.5.20 Calling Name Restriction (CNAR) 27
1 The MSC and SGSN are both GSM.
N.S0028-0
Ballot Version 107
None identified. 1
4.10.5.21 Closed User Group (CUG) 2
None identified. 3
4.10.5.22 Conference Calling / Multi Party Service (CC / MPTY) 4
None identified. 5
4.10.5.23 Do Not Disturb (DND) 6
None identified. 7
4.10.5.24 Emergency Services (Future) 8
None identified. 9
4.10.5.25 Flexible Alerting (FA) 10
None identified. 11
4.10.5.26 Message Waiting Notification (MWN) 12
None identified. 13
4.10.5.27 Mobile Access Hunting (MAH) 14
None identified. 15
4.10.5.28 Password Call Acceptance (PCA) 16
None identified. 17
4.10.5.29 Preferred Language (PL) 18
None identified. 19
4.10.5.30 Priority Access and Channel Assignment (PACA) 20
None identified. 21
4.10.5.31 Remote Feature Control (RFC) 22
None identified. 23
4.10.5.32 Selective Call Acceptance (SCA) 24
None identified. 25
4.10.5.33 Subscriber PIN Access (SPINA) 26
None identified. 27
4.10.5.34 Subscriber PIN Intercept (SPINI) 28
N.S0028-0
Ballot Version 108
None identified. 1
4.10.5.35 Three-Way Calling / Multi Party Service (3WC / MPTY) 2
None Identified. 3
4.10.5.36 Voice Message Retrieval (VMR) 4
None identified. 5
4.10.5.37 Voice Privacy (VP) 6
None identified. 7
8
N.S0028
Post Ballot Version i
Abstract 1
This standard addresses the interworking and interoperability between ANSI-41 MAP and GSM MAP 2 based networks in the support of subscribers roaming between networks. The interworking and 3 interoperability functionality of the services, information flows, and message mappings are specified. 4
This standard consists of four volumes: 5
Volume 0- Overview and Interworking Reference Model 6
Volume 1- Service Descriptions 7
Volume 2- Information Flows 8
Volume 3- Message Mappings 9
This is Volume 2 – Information Flows 10
11
N.S0028
Post Ballot Version ii
Document Revision History 1
Revision Date Version Comment
0 December 2000 Ballot Version
0 March 2001 Inclusion of agreed Ballot Comments
A April 2001 0 Rev A – Inclusion of GPRS
A May 2001 1 New sections added (4.13.1.9 & 4.13.1.10) dealing with authentication failure and registration failure. Alignment of section 4.13 with previous agreed ballot comments.
A June 2001 2 Editorial changes
A 1st August 2001 3 Editorial changes
A 14th August 2001
4 Various technical & editorial changes incorporated during August 7th Conference call
A 15th August 2001
5 Ballot Version - Technical changes to 4.13 GPRS
A 26th November 2001
6 Incorporation of agreed ballot comments from both TIA and T1.
B July 2001 3 Version 3: Addition of CDMA/GSM two way roaming
B March 2002 5 Version V&V: Addition of CDMA/GSM two way and one roaming
2
N.S0028
Post Ballot Version iii
Contents 1
Abstract .............................................................................................................................................. i 2
Document Revision History................................................................................................................ ii 3
List of Tables ...................................................................................................................................xiii 4
List of Figures ................................................................................................................................. xiv 5
Foreword .......................................................................................................................................xxiii 6
1 Introduction ...........................................................................................................................1 7
1.1 General........................................................................................................................1 8
1.2 Purpose.......................................................................................................................1 9
1.3 Scope ..........................................................................................................................1 10
1.4 Organization ................................................................................................................1 11
2 References............................................................................................................................3 12
3 Definitions and Acronyms......................................................................................................5 13
3.1 Definitions....................................................................................................................5 14
3.2 Acronyms ....................................................................................................................9 15
4 Stage 2 Information Flows...................................................................................................12 16
4.1 Location Registration .................................................................................................12 17 4.1.1 Location Registration in GSM Foreign Mode.....................................................12 18
4.1.1.1 MS registers in a GSM network when previously registered in an ANSI-41 19 network 12 20
4.1.1.2 MS location updates in a different MSC/VLR.....................................................14 21 4.1.1.3 IMSI Detach .....................................................................................................15 22 4.1.1.4 IMSI Attach.......................................................................................................16 23
4.1.2 Location Registration in ANSI-41 Foreign Mode................................................17 24 4.1.2.1 MS registers in an ANSI-41 network when previously registered in a GSM 25
network 17 26 4.1.2.2 MS location updates in a different MSC/VLR.....................................................19 27 4.1.2.3 MS Powers Off .................................................................................................20 28 4.1.2.4 MS Powers On .................................................................................................20 29
4.1.3 Location Registration in Native Mode................................................................20 30 4.1.3.1 MS registers in an ANSI-41 network when previously registered in a GSM 31
network 20 32 4.1.3.2 MS registers in a GSM network when previously registered in an ANSI-41 33
network 22 34
4.2 Fault Recovery Procedures........................................................................................24 35 4.2.1 Fault Recovery Procedures in GSM Foreign Mode............................................24 36
4.2.1.1 Recovery from Failure at the ANSI-41 HLR.......................................................24 37 4.2.1.2 Recovery from Failure at the IIF........................................................................25 38 4.2.1.3 Recovery from Failure at the serving GSM VLR................................................26 39
4.2.2 Fault Recovery Procedures in ANSI-41 Foreign Mode ......................................27 40
N.S0028
Post Ballot Version iv
4.2.2.1 Recovery from Failure at the GSM HLR............................................................27 1 4.2.2.2 Recovery from Failure at the IIF........................................................................28 2 4.2.2.3 Recovery from Data Failure at the ANSI-41 VLR...............................................28 3
4.3 Authentication............................................................................................................29 4 4.3.1 ANSI-41 Foreign Mode Authentication Activation ..............................................29 5
4.3.1.1 Receiving AUTHREQ Message ........................................................................29 6 4.3.1.2 Receiving AFREPORT Message ......................................................................31 7 4.3.1.3 Receiving ASREPORT Message ......................................................................33 8 4.3.1.4 Receiving BSCHALL Message .........................................................................35 9 4.3.1.5 Receiving AUTHDIR Message..........................................................................37 10 4.3.1.6 Receiving COUNTREQ Message .....................................................................39 11
4.3.2 GSM Foreign Mode Authentication Activation ...................................................41 12 4.3.2.1 Authentication Related Messages.....................................................................41 13
4.4 Subscriber Data Management....................................................................................43 14 4.4.1 Subscriber Data Management Procedures in ANSI-41 Foreign Mode................43 15
4.4.1.1 Subscriber Deletion ..........................................................................................43 16 4.4.1.2 Subscriber Data Modification ............................................................................44 17
4.4.2 Subscriber Data Management Procedures in GSM Foreign Mode.....................47 18 4.4.2.1 Subscriber Deletion ..........................................................................................47 19 4.4.2.2 Modifying Subscriber Data................................................................................48 20
4.5 Automatic Call Delivery ..............................................................................................49 21 4.5.1 Automatic Call Delivery Activation/Deactivation.................................................49 22 4.5.2 Automatic Call Delivery Invocation....................................................................49 23
4.5.2.1 Call Delivery to ANSI-41 Subscriber Roaming in GSM Network ........................49 24 4.5.2.2 Delivery to an ANSI-41 Subscriber Roaming in a GSM Network – 25
Unsuccessful Case...........................................................................................50 26 4.5.2.3 Call Delivery to a GSM Subscriber Roaming in ANSI-41 Network – 27
Successful Case...............................................................................................51 28 4.5.2.4 Call Delivery to a GSM Subscriber Roaming in ANSI-41 Network – 29
Unsuccessful Case...........................................................................................52 30
4.6 Call Forwarding..........................................................................................................53 31 4.6.1 Call forwarding scenarios for ANSI-41 foreign mode .........................................53 32
4.6.1.1 Call forwarding unconditional (CFU)..................................................................53 33 4.6.1.2 Call forwarding busy (CFB)...............................................................................61 34 4.6.1.3 Call forwarding no reply (CFNRy) .....................................................................66 35 4.6.1.4 Call forwarding not reachable (CFNRc).............................................................69 36
4.6.2 Call forwarding scenarios for GSM foreign mode ..............................................73 37 4.6.2.1 Call forwarding unconditional (CFU)..................................................................73 38 4.6.2.2 Call forwarding busy (CFB)...............................................................................78 39 4.6.2.3 Call forwarding no answer (CFNA)....................................................................86 40
4.7 Optimal Routing for Late Call Forwarding...................................................................88 41 4.7.1 ANSI-41 Foreign Mode .....................................................................................88 42
4.7.1.1 ANSI-41 Foreign Mode - Success condition......................................................88 43 4.7.1.2 ANSI-41 Foreign Mode - Failure condition ........................................................91 44
4.7.2 GSM Foreign Mode ..........................................................................................92 45 4.7.2.1 GSM Foreign Mode - Success Case.................................................................92 46 4.7.2.2 GSM Foreign Mode - Failure case ....................................................................94 47
N.S0028
Post Ballot Version v
4.8 Call Waiting ...............................................................................................................95 1 4.8.1 Call Waiting Activation......................................................................................95 2
4.8.1.1 ANSI-41 Foreign Mode Successful Call Waiting Activation................................95 3 4.8.1.2 ANSI-41 Foreign Mode Unsuccessful Call Waiting Activation............................96 4 4.8.1.3 GSM Foreign Mode Feature Activation .............................................................98 5
4.8.2 Call Waiting Deactivation..................................................................................99 6 4.8.2.1 ANSI-41 Foreign Mode Call Waiting Deactivation .............................................99 7 4.8.2.2 GSM Foreign Mode Feature Deactivation .......................................................101 8
4.9 Calling Number / Line Identification Presentation/Restriction ....................................104 9 4.9.1 Handling of calling number/ line identification presentation..............................104 10
4.9.1.1 GSM Foreign Mode ........................................................................................104 11 4.9.1.2 ANSI-41 Foreign Mode ...................................................................................106 12
4.9.2 Handling of calling number/ line identification restriction..................................107 13 4.9.2.1 General 107 14 4.9.2.2 GSM Foreign Mode ........................................................................................107 15 4.9.2.3 ANSI-41 Foreign Mode ...................................................................................107 16
4.10 Call Barring and Operator Determined Barring .........................................................108 17 4.10.1 Activation of Barring at VLR............................................................................108 18
4.10.1.1 Activation of Call Restrictions while in GSM Foreign Mode ............................108 19 4.10.1.2 Activation of Call Barring while in ANSI-41 Foreign Mode..............................109 20
4.10.2 Invocation of Barring of Incoming Calls ...........................................................109 21 4.10.2.1 GSM Foreign Mode.......................................................................................109 22 4.10.2.2 ANSI-41 Foreign Mode .................................................................................109 23
4.10.3 Invocation of Barring of Roaming....................................................................109 24 4.10.3.1 GSM Foreign Mode.......................................................................................109 25 4.10.3.2 ANSI-41 Foreign Mode .................................................................................111 26
4.10.4 Invocation of Barring of Supplementary Services Management .......................111 27 4.10.4.1 GSM Foreign Mode.......................................................................................111 28 4.10.4.2 ANSI-41 Foreign Mode .................................................................................113 29
4.11 Short Message Service............................................................................................114 30 4.11.1 Assumptions...................................................................................................114 31 4.11.2 Mobile Station only Supports GHOST/WEMT .................................................115 32
4.11.2.1 Short Message from CMT Mobile Station to GHOST/WEMT Mobile Station 33 both in Native Mode........................................................................................115 34
4.11.2.2 Short Message sent from GHOST/WEMT Mobile Station to CMT Mobile 35 Station, both in Native Mode...........................................................................116 36
4.11.3 Mobile Terminating SMS in GSM Foreign Mode..............................................117 37 4.11.3.1 Successful Mobile Terminating ANSI-41 SMS (CMT) mapped to GSM SMS..117 38 4.11.3.2 Successful Mobile Terminating ANSI-41 SMS (GHOST/WEMT) Mapped to 39
GSM SMS ......................................................................................................119 40 4.11.3.3 Unsuccessful Mobile Terminated Delivery (Failure at MSC)...........................121 41 4.11.3.4 Unsuccessful Mobile Terminated Delivery (Failure at IIF) ..............................123 42 4.11.3.5 Alerting for an ANSI-41 Subscriber in GSM Foreign Mode.............................124 43
4.11.4 Mobile Terminated SMS in ANSI-41 Foreign Mode .........................................124 44 4.11.4.1 Successful GSM SMS mapped to ANSI-41 (CMT) SMS................................125 45 4.11.4.2 Successful GSM SMS mapped to ANSI-41 (GHOST/WEMT) SMS................127 46 4.11.4.3 Unsuccessful GSM SMS mapped to ANSI-41 SMS (Failure at MS) ...............128 47
N.S0028
Post Ballot Version vi
4.11.4.4 Unsuccessful Delivery to GSM Subscriber (Postponed at MSC) ....................129 1 4.11.4.5 Unsuccessful Delivery to GSM Subscriber (Failure at IIF)..............................132 2 4.11.4.6 Alerting for a GSM Subscriber in ANSI-41 Foreign Mode...............................132 3
4.11.5 Message Flows for Mobile Originated SMS in GSM Foreign Mode..................134 4 4.11.5.1 Successful Mobile Originated Delivery ..........................................................134 5 4.11.5.2 Unsuccessful Mobile Originated (Failure at MC) ............................................135 6 4.11.5.3 Unsuccessful Mobile Originated (Failure at IIF) .............................................136 7
4.11.6 Message Flows for Mobile Originated SMS in ANSI-41 Foreign Mode.............136 8 4.11.6.1 Successful Mobile Originated Delivery ..........................................................137 9 4.11.6.2 Unsuccessful Mobile Originated (Failure at SMSC) .......................................138 10 4.11.6.3 Unsuccessful Mobile Originated (Failure at IIF) .............................................139 11
4.12 Message Waiting Notification ...................................................................................140 12 4.12.1 GSM Foreign Mode ........................................................................................140 13
4.12.1.1 Indicator in ANSI-41 Registration Notification Return Result mapped to GSM 14 SMS 141 15
4.12.1.2 ANSI-41 Qualification Directive mapped to GSM SMS...................................143 16 4.12.1.3 Handling when GSM MSC/VLR only supports GSM Phase 1 (MAP V1).........144 17 4.12.1.4 Handling at SMS delivery failure at the IIF.....................................................145 18 4.12.1.5 Handling at SMS delivery failure at the MSC/VLR or at the Mobile Station.....147 19
4.12.2 ANSI-41 Foreign Mode ...................................................................................148 20 4.12.2.1 GSM SMS mapped to ANSI-41 Qualification Directive...................................149 21 4.12.2.2 GSM SMS mapped to ANSI-41 SMS using GHOST or WEMT Teleservice....151 22 4.12.2.3 Clearing of MWN Information after Retrieval of Messages while in ANSI-41 23
Foreign Mode – QualDir Method.....................................................................154 24 4.12.2.4 Handling at SMS delivery failure at the IIF.....................................................157 25 4.12.2.5 Handling at SMS delivery failure at the MSC/VLR – QualDir Method .............158 26 4.12.2.6 Handling at SMS delivery failure at the MSC/VLR – GHOST/WEMT SMS 27
Method 159 28 4.12.2.7 GSM SMS mapped to ANSI-41 Qualification Directive and to Registration 29
Notification Return Result ...............................................................................162 30
4.13 GPRS in GSM Foreign Mode ...................................................................................166 31 4.13.1 Location Registration Scenarios......................................................................166 32
4.13.1.1 GPRS Attach (not currently registered)..........................................................167 33 4.13.1.2 GPRS Attach when currently registered in an ANSI-41 network.....................171 34 4.13.1.3 Inter-SGSN routing area update....................................................................175 35 4.13.1.4 GPRS- Attach when only GSM CS Attached ................................................179 36 4.13.1.5 Combined GSM and GPRS attach when not currently registered...................181 37 4.13.1.6 Combined Inter-SGSN Routeing Area/Location Area Update.........................189 38 4.13.1.7 Inter-SGSN routing area update when GSM CS and GPRS attached (GSM 39
MSC remains constant) ..................................................................................193 40 4.13.1.8 Combined Attach When Currently Registered in an ANSI-41 MSC ................196 41 4.13.1.9 Authentication Failure at the IIF.....................................................................205 42 4.13.1.10 Registration Failure at the ANSI-41HLR.....................................................205 43
4.13.2 Location Deregistration Scenarios ..................................................................205 44 4.13.2.1 GSM CS (IMSI) Detach while GPRS and GSM CS Attached .........................205 45 4.13.2.2 GPRS Detach While Attached for Both GPRS and GSM CS Services ...........205 46 4.13.2.3 GPRS Detach While Attached for GPRS Services Only.................................205 47 4.13.2.4 Combined GPRS Detach and GSM CS (IMSI) Detach...................................205 48
N.S0028
Post Ballot Version vii
4.13.2.5 GPRS Detach Followed By Purge .................................................................206 1 4.13.2.6 IIF - Initiated Detach.....................................................................................208 2
4.13.3 SMS Scenarios...............................................................................................209 3 4.13.3.1 SMS Scenarios for Mobile Terminated SMS while GPRS Attached ...............209 4 4.13.3.1.1 Successful Mobile Terminated ANSI-41 SMS (CMT) Mapped to GSM SMS 209 5 4.13.3.1.2 Successful Mobile Terminating ANSI-41 SMS (GHOST/WEMT) Mapped to 6
GSM SMS ......................................................................................................211 7 4.13.3.1.3 Unsuccessful Mobile Terminated Delivery (Failure at SGSN) ......................212 8 4.13.3.1.4 Unsuccessful Mobile Terminated Delivery (Failure at IIF) ............................213 9 4.13.3.1.5 Alerting for an ANSI-41 Subscriber for GPRS in GSM Foreign Mode...........214 10
4.13.4 Message Flows for Mobile Originated SMS when operating GPRS in GSM Foreign 11 Mode .................................................................................................215 12
4.13.4.1 Successful Mobile Originated SMS to MC......................................................215 13 4.13.4.2 Unsuccessful Mobile Originated (Failure at MC).............................................216 14 4.13.4.3 Unsuccessful Mobile Originated (Failure at IIF)..............................................217 15
4.13.5 Message Waiting Notification while GPRS Attached in GSM Foreign Mode ....218 16 4.13.5.1 Indicator in ANSI-41 Registration Notification Return Result mapped to GSM SMS219 17
4.13.5.2 ANSI-41 Qualification Directive mapped to GSM SMS ...................................221 18 4.13.5.3 Handling at SMS delivery failure at the SGSN or at the Mobile Station...........222 19
4.13.6. Call Delivery Scenarios..................................................................................224 20 4.13.6.1 Call Delivery Scenarios in GSM Foreign Mode while GSM CS and GPRS 21
Attached.........................................................................................................224 22 4.13.6.1.1 Call Delivery to ANSI-41 Subscriber Roaming on a GSM/GPRS Network...224 23 4.13.6.1.2 Call Delivery to ANSI-41 Subscriber Roaming in a GPRS Network 24
(Unsuccessful)................................................................................................226 25 4.13.6.2 Successful Network-Requested PDP Context Activation Procedure ..............228 26 4.13.6.3 Unsuccessful Network-Requested PDP Context Activation Procedure...........229 27
4.13.7 Packet Domain Subscriber Data in the IIF......................................................229 28
Annex A (informative) ....................................................................................................................230 29
Abstract ......................................................................................................................................... i 30
Document Revision History ........................................................................................................... ii 31
Contents ...................................................................................................................................... iii 32
List of Tables ..............................................................................................................................viii 33
List of Figures .............................................................................................................................. ix 34
Foreword ................................................................................................................................... xiv 35
1 Introduction ...........................................................................................................................1 36
1.1 General........................................................................................................................1 37
1.2 Purpose.......................................................................................................................1 38
1.3 Scope ..........................................................................................................................1 39
1.4 Organization ................................................................................................................1 40
N.S0028
Post Ballot Version viii
2 References............................................................................................................................2 1
3 Definitions and Acronyms......................................................................................................3 2
3.1 Definitions....................................................................................................................3 3
3.2 Acronyms ....................................................................................................................6 4
4 Stage 2 Information Flows.....................................................................................................9 5
4.1 Location Registration ...................................................................................................9 6 4.1.1 Location Registration in GSM Foreign Mode.......................................................9 7
4.1.1.1 MS registers in a GSM network when previously registered in an ANSI-41 8 network 9 9
4.1.1.2 MS location updates in a different MSC/VLR.....................................................11 10 4.1.1.3 IMSI Detach .....................................................................................................12 11 4.1.1.4 IMSI Attach.......................................................................................................13 12
4.1.2 Location Registration in ANSI-41 Foreign Mode................................................14 13 4.1.2.1 MS registers in an ANSI-41 network when previously registered in a GSM 14
network 14 15 4.1.2.2 MS location updates in a different MSC/VLR.....................................................16 16 4.1.2.3 MS Powers Off .................................................................................................17 17 4.1.2.4 MS Powers On .................................................................................................17 18
4.1.3 Location Registration in Native Mode................................................................17 19 4.1.3.1 MS registers in an ANSI-41 network when previously registered in a GSM 20
network 17 21 4.1.3.2 MS registers in a GSM network when previously registered in an ANSI-41 22
network 19 23
4.2 Fault Recovery Procedures........................................................................................21 24 4.2.1 Fault Recovery Procedures in GSM Foreign Mode............................................21 25
4.2.1.1 Recovery from Failure at the ANSI-41 HLR.......................................................21 26 4.2.1.2 Recovery from Failure at the IIF........................................................................22 27 4.2.1.3 Recovery from Failure at the serving GSM VLR................................................23 28
4.2.2 Fault Recovery Procedures in ANSI-41 Foreign Mode ......................................24 29 4.2.2.1 Recovery from Failure at the GSM HLR............................................................24 30 4.2.2.2 Recovery from Failure at the IIF........................................................................25 31 4.2.2.3 Recovery from Data Failure at the ANSI-41 VLR...............................................25 32
4.3 Authentication............................................................................................................26 33 4.3.1 ANSI-41 Foreign Mode Authentication Activation ..............................................26 34
4.3.1.1 Receiving AUTHREQ Message ........................................................................26 35 4.3.1.2 Receiving AFREPORT Message ......................................................................28 36 4.3.1.3 Receiving ASREPORT Message ......................................................................30 37 4.3.1.4 Receiving BSCHALL Message .........................................................................32 38 4.3.1.5 Receiving AUTHDIR Message..........................................................................34 39 4.3.1.6 Receiving COUNTREQ Message .....................................................................36 40
4.3.2 GSM Foreign Mode Authentication Activation ...................................................38 41 4.3.2.1 Authentication Related Messages.....................................................................38 42
4.4 Subscriber Data Management....................................................................................40 43 4.4.1 Subscriber Data Management Procedures in ANSI-41 Foreign Mode................40 44
4.4.1.1 Subscriber Deletion ..........................................................................................40 45 4.4.1.2 Subscriber Data Modification ............................................................................41 46
N.S0028
Post Ballot Version ix
4.4.2 Subscriber Data Management Procedures in GSM Foreign Mode.....................44 1 4.4.2.1 Subscriber Deletion ..........................................................................................44 2 4.4.2.2 Modifying Subscriber Data................................................................................45 3
4.5 Automatic Call Delivery ..............................................................................................46 4 4.5.1 Automatic Call Delivery Activation/Deactivation.................................................46 5 4.5.2 Automatic Call Delivery Invocation....................................................................46 6
4.5.2.1 Call Delivery to ANSI-136 Subscriber Roaming in GSM Network.......................46 7 4.5.2.2 Delivery to an ANSI-136 Subscriber Roaming in a GSM Network – 8
Unsuccessful Case...........................................................................................47 9 4.5.2.3 Call Delivery to a GSM Subscriber Roaming in ANSI-41 Network – 10
Successful Case...............................................................................................48 11 4.5.2.4 Call Delivery to a GSM Subscriber Roaming in ANSI-41 Network – 12
Unsuccessful Case...........................................................................................48 13
4.6 Call Forwarding..........................................................................................................50 14 4.6.1 Call forwarding scenarios for ANSI-41 foreign mode .........................................50 15
4.6.1.1 Call forwarding unconditional (CFU)..................................................................50 16 4.6.1.2 Call forwarding busy (CFB)...............................................................................58 17 4.6.1.3 Call forwarding no reply (CFNRy) .....................................................................63 18 4.6.1.4 Call forwarding not reachable (CFNRc).............................................................66 19
4.6.2 Call forwarding scenarios for GSM foreign mode ..............................................70 20 4.6.2.1 Call forwarding unconditional (CFU)..................................................................70 21 4.6.2.2 Call forwarding busy (CFB)...............................................................................75 22 4.6.2.3 Call forwarding no answer (CFNA)....................................................................83 23
4.7 Optimal Routing for Late Call Forwarding...................................................................85 24 4.7.1 ANSI-41 Foreign Mode .....................................................................................85 25
4.7.1.1 ANSI-41 Foreign Mode - Success condition......................................................85 26 4.7.1.2 ANSI-41 Foreign Mode - Failure condition ........................................................88 27
4.7.2 GSM Foreign Mode ..........................................................................................89 28 4.7.2.1 GSM Foreign Mode - Success Case.................................................................89 29 4.7.2.2 GSM Foreign Mode - Failure case ....................................................................91 30
4.8 Call Waiting ...............................................................................................................92 31 4.8.1 Call Waiting Activation......................................................................................92 32
4.8.1.1 ANSI-41 Foreign Mode Successful Call Waiting Activation................................92 33 4.8.1.2 ANSI-41 Foreign Mode Unsuccessful Call Waiting Activation............................93 34 4.8.1.3 GSM Foreign Mode Feature Activation .............................................................95 35
4.8.2 Call Waiting Deactivation..................................................................................96 36 4.8.2.1 ANSI-41 Foreign Mode Call Waiting Deactivation .............................................96 37 4.8.2.2 GSM Foreign Mode Feature Deactivation .........................................................98 38
4.9 Calling Number / Line Identification Presentation/Restriction ....................................101 39 4.9.1 Handling of calling number/ line identification presentation..............................101 40
4.9.1.1 GSM Foreign Mode ........................................................................................101 41 4.9.1.2 ANSI-41 Foreign Mode ...................................................................................103 42
4.9.2 Handling of calling number/ line identification restriction..................................104 43 4.9.2.1 General 104 44 4.9.2.2 GSM Foreign Mode ........................................................................................104 45 4.9.2.3 ANSI-41 Foreign Mode ...................................................................................104 46
4.10 Call Barring and Operator Determined Barring .........................................................105 47
N.S0028
Post Ballot Version x
4.10.1 Activation of Barring at VLR............................................................................105 1 4.10.1.1 Activation of Call Restrictions while in GSM Foreign Mode ............................105 2 4.10.1.2 Activation of Call Barring while in ANSI-41 Foreign Mode..............................106 3
4.10.2 Invocation of Barring of Incoming Calls ...........................................................106 4 4.10.2.1 GSM Foreign Mode.......................................................................................106 5 4.10.2.2 ANSI-41 Foreign Mode .................................................................................106 6
4.10.3 Invocation of Barring of Roaming....................................................................106 7 4.10.3.1 GSM Foreign Mode.......................................................................................106 8 4.10.3.2 ANSI-41 Foreign Mode .................................................................................108 9
4.10.4 Invocation of Barring of Supplementary Services Management .......................108 10 4.10.4.1 GSM Foreign Mode.......................................................................................108 11 4.10.4.2 ANSI-41 Foreign Mode .................................................................................110 12
4.11 Short Message Service............................................................................................111 13 4.11.1 Assumptions...................................................................................................111 14 4.11.2 Mobile Station only Supports GHOST.............................................................112 15
4.11.2.1 Short Message from CMT Mobile Station to GHOST Mobile Station both in 16 Native Mode ...................................................................................................112 17
4.11.2.2 Short Message sent from GHOST Mobile Station to CMT Mobile Station, 18 both in Native Mode........................................................................................113 19
4.11.3 Mobile Terminating SMS in GSM Foreign Mode..............................................114 20 4.11.3.1 Successful Mobile Terminating ANSI-136 SMS (CMT) mapped to GSM 21
SMS 114 22 4.11.3.2 Successful Mobile Terminating ANSI-136 SMS (GHOST) Mapped to GSM 23
SMS 115 24 4.11.3.3 Unsuccessful Mobile Terminated Delivery (Failure at MSC)...........................116 25 4.11.3.4 Unsuccessful Mobile Terminated Delivery (Failure at IIF) ..............................118 26 4.11.3.5 Alerting for an ANSI-136 Subscriber in GSM Foreign Mode...........................119 27
4.11.4 Mobile Terminated SMS in ANSI-41 Foreign Mode .........................................119 28 4.11.4.1 Successful GSM SMS mapped to ANSI-136 (CMT) SMS ..............................120 29 4.11.4.2 Successful GSM SMS mapped to ANSI-136 (GHOST) SMS .........................122 30 4.11.4.3 Unsuccessful GSM SMS mapped to ANSI-136 SMS (Failure at MS) .............123 31 4.11.4.4 Unsuccessful Delivery to GSM Subscriber (Postponed at MSC) ....................124 32 4.11.4.5 Unsuccessful Delivery to GSM Subscriber (Failure at IIF)..............................126 33 4.11.4.6 Alerting for a GSM Subscriber in ANSI-41 Foreign Mode...............................127 34
4.11.5 Message Flows for Mobile Originated SMS in GSM Foreign Mode..................128 35 4.11.5.1 Successful Mobile Originated Delivery ..........................................................128 36 4.11.5.2 Unsuccessful Mobile Originated (Failure at MC) ............................................129 37 4.11.5.3 Unsuccessful Mobile Originated (Failure at IIF) .............................................130 38
4.11.6 Message Flows for Mobile Originated SMS in ANSI-41 Foreign Mode.............130 39 4.11.6.1 Successful Mobile Originated Delivery ..........................................................131 40 4.11.6.2 Unsuccessful Mobile Originated (Failure at SMSC) .......................................132 41 4.11.6.3 Unsuccessful Mobile Originated (Failure at IIF) .............................................133 42
4.12 Message Waiting Notification ...................................................................................134 43 4.12.1 GSM Foreign Mode ........................................................................................134 44
4.12.1.1 Indicator in ANSI-41 Registration Notification Return Result mapped to GSM 45 SMS 135 46
4.12.1.2 ANSI-41 Qualification Directive mapped to GSM SMS...................................137 47 4.12.1.3 Handling when GSM MSC/VLR only supports GSM Phase 1 (MAP V1).........138 48
N.S0028
Post Ballot Version xi
4.12.1.4 Handling at SMS delivery failure at the IIF.....................................................139 1 4.12.1.5 Handling at SMS delivery failure at the MSC/VLR or at the Mobile Station.....141 2
4.12.2 ANSI-41 Foreign Mode ...................................................................................142 3 4.12.2.1 GSM SMS mapped to ANSI-41 Qualification Directive...................................143 4 4.12.2.2 GSM SMS mapped to TDMA SMS using GHOST Teleservice.......................144 5 4.12.2.3 Clearing of MWN Information after Retrieval of Messages while in ANSI-41 6
Foreign Mode – QualDir Method.....................................................................146 7 4.12.2.4 Handling at SMS delivery failure at the IIF.....................................................148 8 4.12.2.5 Handling at SMS delivery failure at the MSC/VLR – QualDir Method .............149 9 4.12.2.6 Handling at SMS delivery failure at the MSC/VLR – GHOST SMS Method ....150 10 4.12.2.7 GSM SMS mapped to ANSI-41 Qualification Directive and to Registration 11
Notification Return Result ...............................................................................152 12
4.13 GPRS in GSM Foreign Mode ...................................................................................154 13 4.13.1 Location Registration Scenarios......................................................................154 14
4.13.1.1 GPRS Attach (not currently registered)..........................................................155 15 4.13.1.2 GPRS Attach when currently registered in an ANSI-41 network.....................159 16 4.13.1.3 Inter-SGSN routing area update....................................................................163 17 4.13.1.4 GPRS- Attach when only GSM CS Attached ................................................167 18 4.13.1.5 Combined GSM and GPRS attach when not currently registered...................169 19 4.13.1.6 Combined Inter-SGSN Routeing Area/Location Area Update.........................177 20 4.13.1.7 Inter-SGSN routing area update when GSM CS and GPRS attached (GSM 21
MSC remains constant) ..................................................................................181 22 4.13.1.8 Combined Attach When Currently Registered in an ANSI-41 MSC ................184 23 4.13.1.9 Authentication Failure at the IIF.....................................................................193 24 4.13.1.10 Registration Failure at the ANSI-41HLR.....................................................193 25
4.13.2 Location Deregistration Scenarios ..................................................................193 26 4.13.2.1 GSM CS (IMSI) Detach while GPRS and GSM CS Attached .........................193 27 4.13.2.2 GPRS Detach While Attached for Both GPRS and GSM CS Services ...........193 28 4.13.2.3 GPRS Detach While Attached for GPRS Services Only.................................193 29 4.13.2.4 Combined GPRS Detach and GSM CS (IMSI) Detach...................................193 30 4.13.2.5 GPRS Detach Followed By Purge .................................................................194 31 4.13.2.6 IIF - Initiated Detach.....................................................................................196 32
4.13.3 SMS Scenarios...............................................................................................197 33 4.13.3.1 SMS Scenarios for Mobile Terminated SMS while GPRS Attached ...............197 34 4.13.3.1.1 Successful Mobile Terminated ANSI-136 SMS (CMT) Mapped to GSM 35
SMS...............................................................................................................197 36 4.13.3.1.2 Successful Mobile Terminating ANSI-136 SMS (GHOST) Mapped to GSM 37
SMS...............................................................................................................199 38 4.13.3.1.3 Unsuccessful Mobile Terminated Delivery (Failure at SGSN) ......................200 39 4.13.3.1.4 Unsuccessful Mobile Terminated Delivery (Failure at IIF) ............................201 40 4.13.3.1.5 Alerting for an ANSI-136 Subscriber for GPRS in GSM Foreign Mode.........202 41
4.13.4 Message Flows for Mobile Originated SMS when operating GPRS in GSM Foreign 42 Mode .................................................................................................203 43
4.13.4.1 Successful Mobile Originated SMS to MC......................................................203 44 4.13.4.2 Unsuccessful Mobile Originated (Failure at MC).............................................204 45 4.13.4.3 Unsuccessful Mobile Originated (Failure at IIF)..............................................205 46
4.13.5 Message Waiting Notification while GPRS Attached in GSM Foreign Mode ....206 47 4.13.5.1 Indicator in ANSI-41 Registration Notification Return Result mapped to GSM SMS207 48
N.S0028
Post Ballot Version xii
4.13.5.2 ANSI-41 Qualification Directive mapped to GSM SMS ...................................209 1 4.13.5.3 Handling at SMS delivery failure at the SGSN or at the Mobile Station...........210 2
4.13.6. Call Delivery Scenarios..................................................................................212 3 4.13.6.1 Call Delivery Scenarios in GSM Foreign Mode while GSM CS and GPRS 4
Attached.........................................................................................................212 5 4.13.6.1.1 Call Delivery to ANSI-136 Subscriber Roaming on a GSM/GPRS Network.212 6 4.13.6.1.2 Call Delivery to ANSI-136 Subscriber Roaming in a GPRS Network 7
(Unsuccessful)................................................................................................214 8 4.13.6.2 Successful Network-Requested PDP Context Activation Procedure ..............216 9 4.13.6.3 Unsuccessful Network-Requested PDP Context Activation Procedure...........217 10
4.13.7 Packet Domain Subscriber Data in the IIF......................................................217 11
Annex A (informative) ..............................................................................................................218 12 13
14
15
N.S0028
Post Ballot Version xiii
List of Tables 1
There are no tables in this volume. 2
3
4
N.S0028
Post Ballot Version xiv
List of Figures 1
Figure 1: Registration on a GSM Network – GSM Foreign Mode ...................................................12 2
Figure 2: Registration in a different MSC/VLR – GSM Foreign Mode.............................................14 3
Figure 3: Registration on an ANSI-41 network – ANSI-41 Foreign Mode .......................................17 4
Figure 4: Registration in a different MSC/VLR – ANSI-41 Foreign Mode........................................19 5
Figure 5: Registration in an ANSI-41 Network (Native Mode).........................................................21 6
Figure 6: Registration in a GSM Network (Native Mode)................................................................22 7
Figure 7: Failure at the ANSI-41 HLR (GSM Foreign Mode) ..........................................................24 8
Figure 8: IIF Failure (GSM Foreign Mode).....................................................................................25 9
Figure 9: Terminating Call Flow following a GSM VLR Failure .......................................................26 10
Figure 10: Failure at a GSM HLR (ANSI-41 Foreign Mode) ...........................................................27 11
Figure 11: AUTHREQ - Successful Case ......................................................................................29 12
Figure 12: AUTHREQ - Unsuccessful Case ..................................................................................30 13
Figure 13: AFREPORT - Successful Case ....................................................................................31 14
Figure 14: AFREPORT - Unsuccessful Case ................................................................................32 15
Figure 15: ASREPORT - Successful Case ....................................................................................33 16
Figure 16: ASREPORT - Unsuccessful Case ................................................................................34 17
Figure 17: BSCHALL - Successful Case .......................................................................................35 18
Figure 18: BSCHALL - Unsuccessful Case ...................................................................................36 19
Figure 19: AUTHDIR - Successful Case........................................................................................37 20
Figure 20: AUTHDIR - Unsuccessful Case....................................................................................38 21
Figure 21: COUNTREQ - Successful Case ...................................................................................39 22
Figure 22: COUNTREQ - Unsuccessful Case ...............................................................................40 23
Figure 23: SEND_AUTH_INFO.....................................................................................................41 24
Figure 24: SEND_PARAMETER with Request for Authentication Set............................................42 25
Figure 25: Subscriber Deletion – ANSI-41 Foreign Mode ..............................................................43 26
Figure 26: Insert Subscriber Data Procedure.................................................................................44 27
Figure 27: Delete Subscriber Data Procedure ...............................................................................45 28
Figure 28: Cancel Location Procedure ..........................................................................................46 29
Figure 29: Subscriber Deletion- GSM Foreign Mode .....................................................................47 30
Figure 30: Subscriber Data Modification........................................................................................48 31
Figure 31: Call Delivery to ANSI-41 Subscriber Roaming in a GSM Network .................................49 32
N.S0028
Post Ballot Version xv
Figure 32: Unsuccessful Call Delivery to an ANSI-41 Subscriber Roaming in a GSM Network.......50 1
Figure 33: Call Delivery to GSM Subscriber Roaming in an ANSI-41 Network ...............................51 2
Figure 34: Unsuccessful Call Delivery to GSM Subscriber Roaming in an ANSI-41 Network..........52 3
Figure 35: CFU registration...........................................................................................................53 4
Figure 36: CFU deregistration (erasure)........................................................................................55 5
Figure 37: CFU activation .............................................................................................................57 6
Figure 38: CFU deactivation .........................................................................................................59 7
Figure 39: CFU invocation ............................................................................................................60 8
Figure 40: CFB invocation (Scenario 1a, “CFB#=MSRN method”).................................................62 9
Figure 41: CFB invocation (Scenario 1b, “AbsentSubscriber method”)...........................................63 10
Figure 42: CFB invocation (Scenario 2, without OR)......................................................................64 11
Figure 43: CFNRy invocation (Scenario 1, without OR) .................................................................67 12
Figure 44: CFNRc invocation (Scenario 1) ....................................................................................70 13
Figure 45: CFNRc invocation (Scenario 2, without OR) .................................................................71 14
Figure 46: CFU registration...........................................................................................................73 15
Figure 47: CFU deregistration (erasure)........................................................................................74 16
Figure 48: CFU activation .............................................................................................................75 17
Figure 49: CFU deactivation .........................................................................................................76 18
Figure 50: CFU invocation ............................................................................................................77 19
Figure 51: Obtaining forward-to numbers ......................................................................................78 20
Figure 52: CFB registration...........................................................................................................79 21
Figure 53: CFB deregistration (erasure) ........................................................................................81 22
Figure 54: CFB activation..............................................................................................................82 23
Figure 55: CFB deactivation..........................................................................................................83 24
Figure 57: CFNA invocation (Scenario 1, without OR) ...................................................................87 25
Figure 58: Optimal Routing with Late Call Forwarding (ANSI-41 Foreign Mode) Success Case .....88 26
Figure 59: Optimal Routing with Late Call Forwarding (ANSI-41 Foreign Mode) Failure Case........91 27
Figure 60: Optimal Routing with Late Call Forwarding (GSM Foreign Mode) Success Case ..........92 28
Figure 61: Optimal Routing with Late Call Forwarding (GSM Foreign Mode) Failure Case.............94 29
Figure 62: ANSI-41 Foreign Mode Call Waiting Activation .............................................................95 30
Figure 63: ANSI-41 Foreign Mode Unsuccessful Call Waiting Activation .......................................97 31
Figure 64: GSM Foreign Mode Call Waiting Activation ..................................................................98 32
Figure 65: ANSI-41 Foreign Mode Call Waiting Deactivation .......................................................100 33
N.S0028
Post Ballot Version xvi
Figure 66: GSM Foreign Mode Call Waiting Deactivation ............................................................102 1
Figure 67: Calling number/ line identification presentation: mobile station or fixed terminal to 2 mobile station – GSM Foreign Mode .....................................................................104 3
Figure 68: Calling number/ line identification presentation: mobile station or fixed terminal to 4 mobile station – ANSI-41 Foreign Mode................................................................106 5
Figure 69: Activation of Call Restriction - GSM Foreign Mode......................................................108 6
Figure 70: Activation of Call Barring – ANSI-41 Foreign Mode.....................................................109 7
Figure 71: Invocation of Barring of Roaming – GSM Foreign Mode ............................................110 8
Figure 72: Invocation of Barring of Roaming – ANSI-41 Foreign Mode ........................................111 9
Figure 73: Invocation of Barring of Supplementary Service Control – GSM Foreign Mode ...........112 10
Figure 74: Invocation of Barring of Supplementary Services Management – ANSI-41 Foreign 11 Mode ....................................................................................................................113 12
Figure 75: Short Message from a TDMA or CDMA CMT phone to a GHOST or WEMT mobile 13 station, both in native mode ..................................................................................115 14
Figure 76: Short Message from a GHOST or WEMT mobile station to a TDMA CMT or CDMA 15 CMT Phone, both in native mode..........................................................................116 16
Figure 77: Successful Mobile Terminating ANSI-41 SMS (CMT) mapped to GSM SMS...............118 17
Figure 78: Successful Mobile Terminating ANSI-41 SMS (GHOST/WEMT) mapped to GSM 18 SMS .....................................................................................................................120 19
Figure 79: Unsuccessful Mobile Terminated Delivery (Failure at MSC)........................................121 20
Figure 80: Unsuccessful Mobile Terminated Delivery (Failure at IIF)............................................123 21
Figure 81: Alerting for an ANSI-41 Subscriber in GSM Foreign Mode..........................................124 22
Figure 82: Successful GSM SMS mapped to ANSI-41 (CMT) SMS .............................................125 23
Figure 83: Successful GSM SMS mapped to ANSI-41 (GHOST/WEMT) SMS.............................127 24
Figure 84: Successful GSM SMS mapped to ANSI-41 SMS (Failure at MS) ................................128 25
Figure 85: Unsuccessful Delivery to GSM Subscriber (Postponed at MSC) .................................130 26
Figure 86: Unsuccessful Delivery to GSM Subscriber (Failure at IIF)...........................................132 27
Figure 87: Alerting for a GSM Subscriber in ANSI-41 Foreign Mode............................................133 28
Figure 88: Successful Mobile Originated Delivery........................................................................134 29
Figure 89: Unsuccessful Mobile Originated (Failure at MC) .........................................................135 30
Figure 90: Unsuccessful Mobile Originated (Failure at IIF)...........................................................136 31
Figure 91: Successful Mobile Originated Delivery – ANSI-41 Foreign Mode ................................137 32
Figure 92: Successful Mobile Originated (Failure at SMSC) – ANSI-41 Foreign Mode.................138 33
Figure 93: Unsuccessful Mobile Originated (Failure at IIF) – ANSI-41 Foreign Mode ...................139 34
Figure 94: Indicator in ANSI-41 Registration Notification Return Result mapped to GSM SMS.....141 35
N.S0028
Post Ballot Version xvii
Figure 95: ANSI-41 Qualification Directive mapped to GSM SMS...............................................143 1
Figure 96: Handling when GSM MSC/VLR only supports GSM Phase 1 (MAP V1)......................144 2
Figure 97: Handling at SMS delivery failure at the IIF .................................................................145 3
Figure 98: Handling at SMS delivery failure at the MSC/VLR or at the MS..................................147 4
Figure 99: GSM SMS mapped to ANSI-41 Qualification Directive................................................150 5
Figure 100: GSM SMS mapped to ANSI-41 using GHOST/WEMT Teleservice ...........................153 6
Figure 101: Clearing of MWN Information after Retrieval of Messages while in ANSI-41 7 Foreign mode – Qualdir Method............................................................................155 8
Figure 102: Handling at SMS delivery failure at the IIF ................................................................157 9
Figure 103: Handling at SMS delivery failure at the MSC/VLR Qualdir Method............................158 10
Figure 104: Handling at SMS delivery failure at the MSC/VLR – GHOST/WEMT SMS Method....160 11
Figure 105: GSM SMS mapped to ANSI-41 Qualification Directive and to Registration 12 Notification Return Result .....................................................................................164 13
Figure 106: GPRS Attach (Option1: with timer) ...........................................................................167 14
Figure 107: GPRS Attach (Option 2: without timer)......................................................................169 15
Figure 108: GPRS Attach when currently registered in ANSI-41 (Option 1: with timer).................171 16
Figure 109: GPRS Attach when currently registered in ANSI-41 (Option 2: without timer)............173 17
Figure 112: GPRS Attach when GSM CS Attached. ....................................................................179 18
Figure 113: Combined GPRS and GSM attach (Option 1: With timer)..........................................181 19
Figure 114: Combined GPRS and GSM attach (Option 2: Without timer and without support 20 for multiple MSCIDs).............................................................................................183 21
Figure 115: Combined GPRS and GSM attach (Option 3: IIF supports multiple MSCIDs). ...........186 22
Figure 116: Combined Inter-SGSN RA/LA update.......................................................................190 23
Figure: 117: Inter-SGSN routing area update when GSM CS and GPRS Attached (MSC 24 remains constant) .................................................................................................194 25
Figure 118: Combined Attach when registered on a ANSI-41 MSC (Option 1: With timer) ...........198 26
Figure 119: Combined attach when registered on a ANSI-41 MSC (Option 2: without timer ).......201 27
Figure 119: Combined attach when registered on a ANSI-41 MSC (Option 2: without timer ).......202 28
Figure 120: MS in GSM Foreign Mode Performing GPRS Detach Followed by Purge..................206 29
Figure 121: IIF - Initiated Detach.................................................................................................208 30
Figure 122: Successful Mobile Terminating ANSI-41 SMS (CMT) mapped to GSM SMS............209 31
Figure 123: Successful Mobile Terminating ANSI-41 SMS (GHOST/WEMT) mapped to GSM 32 SMS .....................................................................................................................211 33
Figure 124: Unsuccessful Mobile Terminated Delivery (Failure at SGSN)....................................212 34
Figure 125: Unsuccessful Mobile Terminated Delivery (Failure at IIF)..........................................213 35
N.S0028
Post Ballot Version xviii
Figure 126: Alerting for an ANSI-41 Subscriber in GSM Foreign Mode ........................................214 1
Figure 127: Successful Mobile Originated Delivery.....................................................................215 2
Figure 128: Unsuccessful Mobile Originated Delivery (Failure at MC)..........................................216 3
Figure 129: Unsuccessful Mobile Originated (Failure at IIF).........................................................217 4
Figure 130: Indicator in ANSI-41 Registration Notification Return Result mapped to GSM 5 SMS ....................................................................................................................219 6
Figure 131: ANSI-41 Qualification Directive mapped to GSM SMS..............................................221 7
Figure 132: Handling at SMS delivery failure at the SGSN or at the MS ......................................222 8
Figure 133: Call Delivery to ANSI-41 Subscriber Roaming in GSM/GPRS Network .....................224 9
Figure 134: MS Notification of a “Missed” Call via SMS...............................................................226 10
Figure 1: Registration on a GSM Network – GSM Foreign Mode .....................................................9 11
Figure 2: Registration in a different MSC/VLR – GSM Foreign Mode.............................................11 12
Figure 3: Registration on an ANSI-41 network – ANSI-41 Foreign Mode .......................................14 13
Figure 4: Registration in a different MSC/VLR – ANSI-41 Foreign Mode........................................16 14
Figure 5: Registration in an ANSI-41 Network (Native Mode).........................................................18 15
Figure 6: Registration in a GSM Network (Native Mode)................................................................19 16
Figure 7: Failure at the ANSI-41 HLR (GSM Foreign Mode) ..........................................................21 17
Figure 8: IIF Failure (GSM Foreign Mode).....................................................................................22 18
Figure 9: Terminating Call Flow following a GSM VLR Failure .......................................................23 19
Figure 10: Failure at a GSM HLR (ANSI-41 Foreign Mode) ...........................................................24 20
Figure 11: AUTHREQ - Successful Case ......................................................................................26 21
Figure 12: AUTHREQ - Unsuccessful Case ..................................................................................27 22
Figure 13: AFREPORT - Successful Case ....................................................................................28 23
Figure 14: AFREPORT - Unsuccessful Case ................................................................................29 24
Figure 15: ASREPORT - Successful Case ....................................................................................30 25
Figure 16: ASREPORT - Unsuccessful Case ................................................................................31 26
Figure 17: BSCHALL - Successful Case .......................................................................................32 27
Figure 18: BSCHALL - Unsuccessful Case ...................................................................................33 28
Figure 19: AUTHDIR - Successful Case........................................................................................34 29
Figure 20: AUTHDIR - Unsuccessful Case....................................................................................35 30
Figure 21: COUNTREQ - Successful Case ...................................................................................36 31
Figure 22: COUNTREQ - Unsuccessful Case ...............................................................................37 32
Figure 23: SEND_AUTH_INFO.....................................................................................................38 33
N.S0028
Post Ballot Version xix
Figure 24: SEND_PARAMETER with Request for Authentication Set............................................39 1
Figure 25: Subscriber Deletion – ANSI-41 Foreign Mode ..............................................................40 2
Figure 26: Insert Subscriber Data Procedure.................................................................................41 3
Figure 27: Delete Subscriber Data Procedure ...............................................................................42 4
Figure 28: Cancel Location Procedure ..........................................................................................43 5
Figure 29: Subscriber Deletion- GSM Foreign Mode .....................................................................44 6
Figure 30: Subscriber Data Modification........................................................................................45 7
Figure 31: Call Delivery to ANSI-41 Subscriber Roaming in a GSM Network .................................46 8
Figure 32: Unsuccessful Call Delivery to an ANSI-136 Subscriber Roaming in a GSM 9 Network ..................................................................................................................47 10
Figure 33: Call Delivery to GSM Subscriber Roaming in an ANSI-41 Network ...............................48 11
Figure 34: Unsuccessful Call Delivery to GSM Subscriber Roaming in an ANSI-41 Network..........49 12
Figure 35: CFU registration...........................................................................................................50 13
Figure 36: CFU deregistration (erasure)........................................................................................52 14
Figure 37: CFU activation .............................................................................................................54 15
Figure 38: CFU deactivation .........................................................................................................56 16
Figure 39: CFU invocation ............................................................................................................57 17
Figure 40: CFB invocation (Scenario 1a, “CFB#=MSRN method”).................................................59 18
Figure 41: CFB invocation (Scenario 1b, “AbsentSubscriber method”)...........................................60 19
Figure 42: CFB invocation (Scenario 2, without OR)......................................................................61 20
Figure 43: CFNRy invocation (Scenario 1, without OR) .................................................................64 21
Figure 44: CFNRc invocation (Scenario 1) ....................................................................................67 22
Figure 45: CFNRc invocation (Scenario 2, without OR) .................................................................68 23
Figure 46: CFU registration...........................................................................................................70 24
Figure 47: CFU deregistration (erasure)........................................................................................71 25
Figure 48: CFU activation .............................................................................................................72 26
Figure 49: CFU deactivation .........................................................................................................73 27
Figure 50: CFU invocation ............................................................................................................74 28
Figure 51: Obtaining forward-to numbers ......................................................................................75 29
Figure 52: CFB registration...........................................................................................................76 30
Figure 53: CFB deregistration (erasure) ........................................................................................78 31
Figure 54: CFB activation..............................................................................................................79 32
Figure 55: CFB deactivation..........................................................................................................80 33
N.S0028
Post Ballot Version xx
Figure 57: CFNA invocation (Scenario 1, without OR) ...................................................................84 1
Figure 58: Optimal Routing with Late Call Forwarding (ANSI-41 Foreign Mode) Success Case .....85 2
Figure 59: Optimal Routing with Late Call Forwarding (ANSI-41 Foreign Mode) Failure Case........88 3
Figure 60: Optimal Routing with Late Call Forwarding (GSM Foreign Mode) Success Case ..........89 4
Figure 61: Optimal Routing with Late Call Forwarding (GSM Foreign Mode) Failure Case.............91 5
Figure 62: ANSI-41 Foreign Mode Call Waiting Activation .............................................................92 6
Figure 63: ANSI-41 Foreign Mode Unsuccessful Call Waiting Activation .......................................94 7
Figure 64: GSM Foreign Mode Call Waiting Activation ..................................................................95 8
Figure 65: ANSI-41 Foreign Mode Call Waiting Deactivation .........................................................97 9
Figure 66: GSM Foreign Mode Call Waiting Deactivation ..............................................................99 10
Figure 67: Calling number/ line identification presentation: mobile station or fixed terminal to 11 mobile station – GSM Foreign Mode .....................................................................101 12
Figure 68: Calling number/ line identification presentation: mobile station or fixed terminal to 13 mobile station – ANSI-41 Foreign Mode................................................................103 14
Figure 69: Activation of Call Restriction - GSM Foreign Mode......................................................105 15
Figure 70: Activation of Call Barring – ANSI-41 Foreign Mode.....................................................106 16
Figure 71: Invocation of Barring of Roaming – GSM Foreign Mode ............................................107 17
Figure 72: Invocation of Barring of Roaming – ANSI-41 Foreign Mode ........................................108 18
Figure 73: Invocation of Barring of Supplementary Service Control – GSM Foreign Mode ...........109 19
Figure 74: Invocation of Barring of Supplementary Services Management – ANSI-41 Foreign 20 Mode ....................................................................................................................110 21
Figure 75: Short Message from a TDMA CMT phone to a GHOST mobile station, both in 22 native mode..........................................................................................................112 23
Figure 76: Short Message from a GHOST mobile station to a TDMA CMT Phone, both in 24 native mode..........................................................................................................113 25
Figure 77: Successful Mobile Terminating ANSI-136 SMS (CMT) mapped to GSM SMS.............114 26
Figure 78: Successful Mobile Terminating ANSI-136 SMS (GHOST) mapped to GSM SMS........115 27
Figure 79: Unsuccessful Mobile Terminated Delivery (Failure at MSC)........................................116 28
Figure 80: Unsuccessful Mobile Terminated Delivery (Failure at IIF)............................................118 29
Figure 81: Alerting for an ANSI-136 Subscriber in GSM Foreign Mode ........................................119 30
Figure 82: Successful GSM SMS mapped to ANSI-136 (CMT) SMS ...........................................120 31
Figure 83: Successful GSM SMS mapped to ANSI-136 (GHOST) SMS ......................................122 32
Figure 84: Successful GSM SMS mapped to ANSI-136 SMS (Failure at MS) ..............................123 33
Figure 85: Unsuccessful Delivery to GSM Subscriber (Postponed at MSC) .................................125 34
Figure 86: Unsuccessful Delivery to GSM Subscriber (Failure at IIF)...........................................126 35
N.S0028
Post Ballot Version xxi
Figure 87: Alerting for a GSM Subscriber in ANSI-41 Foreign Mode............................................127 1
Figure 88: Successful Mobile Originated Delivery........................................................................128 2
Figure 89: Unsuccessful Mobile Originated (Failure at MC) .........................................................129 3
Figure 90: Unsuccessful Mobile Originated (Failure at IIF)...........................................................130 4
Figure 91: Successful Mobile Originated Delivery – ANSI-41 Foreign Mode ................................131 5
Figure 92: Successful Mobile Originated (Failure at SMSC) – ANSI-41 Foreign Mode.................132 6
Figure 93: Unsuccessful Mobile Originated (Failure at IIF) – ANSI-41 Foreign Mode ...................133 7
Figure 94: Indicator in ANSI-41 Registration Notification Return Result mapped to GSM SMS.....135 8
Figure 95: ANSI-41 Qualification Directive mapped to GSM SMS...............................................137 9
Figure 96: Handling when GSM MSC/VLR only supports GSM Phase 1 (MAP V1)......................138 10
Figure 97: Handling at SMS delivery failure at the IIF .................................................................139 11
Figure 98: Handling at SMS delivery failure at the MSC/VLR or at the MS..................................141 12
Figure 99: GSM SMS mapped to ANSI-41 Qualification Directive................................................143 13
Figure 100: GSM SMS mapped to TDMA using GHOST Teleservice ..........................................145 14
Figure 101: Clearing of MWN Information after Retrieval of Messages while in ANSI-41 15 Foreign mode – Qualdir Method............................................................................146 16
Figure 102: Handling at SMS delivery failure at the IIF ................................................................148 17
Figure 103: Handling at SMS delivery failure at the MSC/VLR Qualdir Method............................149 18
Figure 104: Handling at SMS delivery failure at the MSC/VLR – GHOST SMS Method ...............150 19
Figure 105: GSM SMS mapped to ANSI-41 Qualification Directive and to Registration 20 Notification Return Result .....................................................................................152 21
Figure 106: GPRS Attach (Option1: with timer) ...........................................................................155 22
Figure 107: GPRS Attach (Option 2: without timer)......................................................................157 23
Figure 108: GPRS Attach when currently registered in ANSI-41 (Option 1: with timer).................159 24
Figure 109: GPRS Attach when currently registered in ANSI-41 (Option 2: without timer)............161 25
Figure 112: GPRS Attach when GSM CS Attached. ....................................................................167 26
Figure 113: Combined GPRS and GSM attach (Option 1: With timer)..........................................169 27
Figure 114: Combined GPRS and GSM attach (Option 2: Without timer and without support 28 for multiple MSCIDs).............................................................................................171 29
Figure 115: Combined GPRS and GSM attach (Option 3: IIF supports multiple MSCIDs). ...........174 30
Figure 116: Combined Inter-SGSN RA/LA update.......................................................................178 31
Figure: 117: Inter-SGSN routing area update when GSM CS and GPRS Attached (MSC 32 remains constant) .................................................................................................182 33
Figure 118: Combined Attach when registered on a ANSI-41 MSC (Option 1: With timer) ...........186 34
Figure 119: Combined attach when registered on a ANSI-41 MSC (Option 2: without timer ).......190 35
N.S0028
Post Ballot Version xxii
Figure 120: MS in GSM Foreign Mode Performing GPRS Detach Followed by Purge..................194 1
Figure 121: IIF - Initiated Detach.................................................................................................196 2
Figure 122: Successful Mobile Terminating ANSI-136 SMS (CMT) mapped to GSM SMS..........197 3
Figure 123: Successful Mobile Terminating ANSI-136 SMS (GHOST) mapped to GSM SMS......199 4
Figure 124: Unsuccessful Mobile Terminated Delivery (Failure at SGSN)....................................200 5
Figure 125: Unsuccessful Mobile Terminated Delivery (Failure at IIF)..........................................201 6
Figure 126: Alerting for an ANSI-136 Subscriber in GSM Foreign Mode ......................................202 7
Figure 127: Successful Mobile Originated Delivery.....................................................................203 8
Figure 128: Unsuccessful Mobile Originated Delivery (Failure at MC)..........................................204 9
Figure 129: Unsuccessful Mobile Originated (Failure at IIF).........................................................205 10
Figure 130: Indicator in ANSI-41 Registration Notification Return Result mapped to GSM 11 SMS ....................................................................................................................207 12
Figure 131: ANSI-41 Qualification Directive mapped to GSM SMS..............................................209 13
Figure 132: Handling at SMS delivery failure at the SGSN or at the MS ......................................210 14
Figure 133: Call Delivery to ANSI-136 Subscriber Roaming in GSM/GPRS Network ...................212 15
Figure 134: MS Notification of a “Missed” Call via SMS...............................................................214 16
17
18
N.S0028
Post Ballot Version xxiii
Foreword 1
This foreword is not part of this standard. 2
This standard addresses the interworking and interoperability between TIA/EIA IS41 MAP and GSM 3 based networks in the support of subscribers roaming between networks. The objective of the 4 standard is to achieve fully automatic, two-way interoperability between the heterogeneous networks. 5 Services supported by this standard are described along with the associated information flows and 6 message mappings. However, not all services and associated capabilities of ANSI-41 MAP and GSM 7 MAP are supported by this standard. In general the attempt has been to focus on the key subscriber 8 services needed in the market. 9
The focus of the first release of this standard was on common GSM and ANSI-136 TDMA services 10 and associated network signaling (i.e. ANSI-41 MAP and GSM MAP). A pre-requisite for this 11 interoperability is multi-mode mobile stations with an enhanced SIM card for roaming between 12 ANSI-136, GSM, and AMPS networks. 13
The first release of the standard did not define or require changes to existing ANSI-41 MAP or GSM 14 MAP to achieve the described interworking and interoperability. However, due to differences between 15 the services and associated capabilities of the MAP protocols, complete and fully transparent 16 interoperability may not have been achieved for some services. Future releases of this standard may 17 require changes to ANSI-41 MAP, GSM MAP and the associated services to achieve full 18 transparency while roaming between the different networks. 19
Additional or alternate service descriptions, information flows, and message mappings may be 20 required to support other air interfaces supported by ANSI-41 MAP (e.g., IS-95, CDMA2000). This 21 may be accomplished in future release of this standard. 22
Existing ANSI-41 and GSM standard specifications cover the use and value of timers controlling the 23 various operations. Therefore, these timers are not part of this standard. However, care should be 24 taken when allocating actual timer values in order to support interoperability between ANSI-41 MAP 25 and GSM MAP. 26
Aspects of TIA/EIA-136 Rev C have been incorporated into this standard. 27
Revision A adds GPRS service capability in GSM Foreign Mode. 28
29
Revision B adds two way roaming between GSM and CDMA systems 30
Information disclosed in this document is subject to the export jurisdiction of the US Department of Commerce 31 as specified in Export Administration Regulations (title 15 CFR parts 730 through 774 inclusive). The 32 information contained herein may not be exported or re-exported to Cuba, Iran, Iraq, Libya, North Korea, 33 Sudan, or Syria. Contact the Telecommunications Industry Association, Arlington, VA or 34 http://ftp.tiaonline.org/tr-45/tr45ahag/public%20documents. 35
N.S0028
Post Ballot Version 1
1 Introduction 1
1.1 General 2
When a subscriber to one network type (e.g., ANSI-41) roams to a network of another type (e.g., 3 GSM), interworking and interoperability functions are required to support the subscriber and enable 4 service. This standard describes an Interworking and Interoperability Function (IIF) to support this 5 cross-technology roaming between ANSI-41 and GSM networks. The IIF supports a multi-mode 6 mobile station with a removable Subscriber Identity Module (SIM). The standard also defines the 7 required network message mappings between ANSI-41 MAP and GSM MAP to support the mobile 8 terminal and associated services. 9
This standard includes the support of cross-technology roaming from an ANSI-41 based network to a 10 GPRS network. The GPRS network may be coupled with a GSM network. This feature requires 11 enhancement to the Interworking and Interoperability Function (IIF) which supports a multi-mode 12 mobile station and Subscriber Identity Module (SIM) with GPRS functionality. 13
Optionally, IIF may support one way-roaming only from CDMA to GSM network. In this case since no 14 data is provisioned at IIF level, IIF must generate the GSM triplets using as input the authentication 15 parameters returned by ANSI-41 HLR/AC. and ANSI-41 HLR/AC must be compliant with PN-4925 (to 16 be published as TIA/EIA-868 [28]. All the changes are made on the assumption the new requirements 17 for UIM/handsets are working. (Annex B) 18
1.2 Purpose 19
The purpose for this standard is to define and describe the functions necessary for roaming between 20 ANSI-41 MAP [1] and GSM MAP [6] based networks in the support of roaming subscribers. This 21 includes a capability to allow a subscriber to an ANSI-41 based network (e.g., an ANSI-136 41, 22 TDMA or CDMA native subscriber) with a mobile terminal supporting GPRS service to roam to a 23 GPRS network in GSM Foreign Mode. 24
1.3 Scope 25
The scope of this standard are the services, information flows and message mappings which require 26 interworking and interoperability functional specifications to support roaming between ANSI-41 MAP 27 and GSM MAP networks. 28
The scope of this volume describes the “Information Flows” and addresses the functionality required 29 to support GSM and ANSI-41 network interoperability. 30
1.4 Organization 31
This standard is organized into the following volumes: 32
Volume 0 – Overview and Interworking Reference Model 33
Volume 1 – Service Descriptions 34
Volume 2 – Information Flows 35
Volume 3 – Message Mappings 36
This volume is organized according to the following: 37
2 References - a list of references specific to this volume of the Standard. 38
N.S0028
Post Ballot Version 2
3 Definitions and Acronyms - defines words and acronyms that are specific to this volume. 1
4 Information flows - Message Flows and functionality of the interoperable network features. 2
3
N.S0028
Post Ballot Version 3
2 References 1
[1] TIA/EIA IS-41-D: “Cellular Radiotelecommunications Intersystem Operations,” December 2 1997, ANSI. 3
[2] TIA/EIA/IS-751: “TIA/EIA-41-D Modifications to support IMSI”, PN-3892 version 7. 4
[3] TIA/EIA/IS-807: “TIA/EIA-41-D Enhancements for Internationalization” 5
[4] TS 100 901 v 6.1.0 (1998-07); “Digital cellular telecommunications system (Phase 2+); 6 Technical realization of the Short Message Service (SMS); Point-to-Point (PP),” (GSM 03.40 7 version 6.1.0 Release 1997) 8
[5] TS 100 542 v 7.0.1 (1999-07); "Digital cellular telecommunications system (Phase 2+); Line 9 identification supplementary services;Stage2 (GSM 03.81 version 7.0.1 Release 1998). 10
[6] TS 100 974 v 6.2.0 (1998-11): “Digital cellular telecommunication system (Phase 2+); Mobile 11 Application Part (MAP) specification,” (GSM 09.02 version 6.2.0 Release 1997). 12
[7] TS 100 974 v 7.1.0 (1999-08): “Digital cellular telecommunication system (Phase 2+); Mobile 13 Application Part (MAP) specification,” (GSM 09.02 version 7.1.0 Release 1998). 14
[8] TS 101 629 v 6.0.0 (1999-04): "Digital cellular telecommunication system (Phase 2+); 15 Support of Optimal Routeing (SOR); Service definition (Stage 1)". (GSM 02.79 v 6.0.0 16 Release 1997) 17
[9] TS 101 045 v 6.2.0 (1999-11): "Digital cellular telecommunication system (Phase 2+); 18 Support of Optimal Routeing (SOR); Technical realisation" (GSM 03.79 v 6.2.0 Release 19 1997). 20
[10] Draft ETSI EN 301 344: “Digital cellular telecommunication system (Phase 2+); General 21 Packet Radio Service; Service description (Stage 2)" (GSM 03.60 v 6.8.0 Release 1997). 22
[11] TIA/EIA/IS 737A”IS-41 support for data services for digital terminals (TDMA and CDMA)” 23
[12] TIA/EIA/IS 735 “IS-41 support for IS-95-A (advanced CDMA)” 24
[13] TIA/EIA/TSB58-E “Administration of Parameter Value Assignments for TIA/EIA Spread 25 Spectrum Standards” , January 2002 26
[14] TIA/EIA-95-B - Mobile Station-Base Station Compatibility Standard for Dual-Mode Spread 27 Spectrum Systems; Published October 1998. 28 29 [15] "TIA/EIA-IS-2000-A, cdma2000 Series, March 2000, plus addenda"Mobile Station-Base Station 30 Compatibility Standard for Dual-Mode Spread Spectrum Systems; 31 [16] TIA/EIA-868 – ANSI-41-D Network Based Enhancements to support one-way roaming to 32 GSM, Published TBD. [12]"Enhanced Cryptographic Algorithms, Revision B," TR45AHAG, Published TBD 33
34
35
N.S0028
Post Ballot Version 4
1
N.S0028
Post Ballot Version 5
3 Definitions and Acronyms 1
3.1 Definitions 2
AMPS 3
Advanced Mobile Phone Service (AMPS) is the same as EIA/TIA-553, which as an analog air 4 interface protocol standard for mobile stations and their associated base stations. AMPS networks 5 use ANSI-41 for intersystem signaling. 6
ANSI-41 7
ANSI-41 is the same as TIA/EIA IS-41 with the modifications and enhancements contained in IS751 8 [2] and IS 807 [3] . ANSI-41 is the North American version of ITU defined MAP. Key intersystem 9 support defined by ANSI-41 includes automatic roaming, intersystem handoff, and intersystem 10 operation, administration, and maintenance. Among other things, ANSI-41 defines the interfaces 11 between MSCs, between the MSC/VLR and the HLR/AC, and between the MSC and the Short 12 Message Service Center (SMS-C) or Teleservice Server (TS). 13
ANSI-136 14
ANSI-136 is the same as TIA/EIA-136, which is a TDMA air interface protocol standard for mobile 15 stations and their associated base stations. ANSI-136 is a dual-mode standard that includes digital 16 (TDMA) operation at 800 MHz and 1900 MHz, and analog (AMPS) operation at 800 MHz. ANSI-136 17 networks use ANSI-41 for intersystem signaling. 18
ANSI-136 Mode 19
ANSI-136 mode indicates the condition or state of a mobile station accessing an ANSI-136 network. 20
ANSI-136 Foreign Mode 21
ANSI-136 foreign mode indicates the condition or state of a GSM native subscriber accessing an 22 ANSI-136 network. 23
ANSI-136 Native Mode 24
ANSI-136 native mode indicates the condition or state of an ANSI-136 native subscriber accessing an 25 ANSI-136 network. 26
ANSI-136 Native Subscriber 27
ANSI-136 native subscriber indicates an end user whose primary or home subscription resides in an 28 ANSI-136 network. These subscribers include both home subscribers from the ANSI-136 network, as 29 well as roamers from other ANSI-136 networks. 30
ANSI-41 Foreign Mode 31
ANSI-41 foreign mode indicates the condition or state of a GSM native subscriber accessing an 32 ANSI-41 based network. 33
ANSI-41 Subscriber 34
ANSI-41 subscriber indicates an end user whose primary or home subscription resides in an ANSI-41 35 based network. These subscribers include both home subscribers from ANSI-41 based networks as 36 well as roamers from other ANSI-41 based networks. 37
CDMA 38
N.S0028
Post Ballot Version 6
CDMA as used in this document, refers to TIA/EIA -95 [9] or TIA/EIA-2000 [10], which is a CDMA 1 air interface protocol standard for mobile stations and their associated base stations. CDMA is a 2 dual-mode standard that includes digital (CDMA) operation and analog (AMPS) operation. CDMA 3 networks use ANSI-41 for intersystem signaling. 4
B.1.1.1.1.1 CDMA Mode 5
CDMA mode indicates the condition or state of a mobile station accessing an CDMA network. 6 7 CDMA Foreign Mode 8 CDMA foreign mode indicates the condition or state of a GSM native subscriber accessing a CDMA 9 network. 10 11 CDMA Native Mode 12 CDMA native mode indicates the condition or state of an CDMA native subscriber accessing an 13 CDMA network. 14 15 CDMA Native Subscriber 16 CDMA native subscriber indicates an end user whose primary or home subscription resides in an 17 CDMA network. These subscribers include both home subscribers from the CDMA network, as well 18 as roamers from other CDMA networks. 19 20
Class A mobile 21
Class A mobile station is a GSM mobile that can operate in Class A mode: both GSM circuit-switched 22 and GPRS packet services simultaneously. 23 24 Class B mobile 25
Class B mobile station is a GAIT or GSM mobile that operates in Class B mode: can operate 26 alternatively GSM circuit-switched or GPRS packet services (1 type service at a time). The mobile 27 can be attached to GSM and GPRS networks simultaneously in this case. The subscriber cannot be 28 simultaneously attached to an ANSI-41 MSC. 29 30 Class C mobile 31
Class C mobile station is a GSM mobile that can only operate in Class C mode: GSM circuit-switched 32 only or GPRS packet services only. The mobile is attached to only one network at a time. 33 34 GSM 35
Global System for Mobile Communications (GSM) defines both air interface and network intersystem 36 protocol standards for mobile stations (MS), base station systems (BSS), and network switching 37 systems (NSS). 38
GSM CS attached 39
GSM circuit-switched services attached means that the subscriber is attached to a GSM MSC. This is 40 also referred to as IMSI attached 41
GSM CS detached 42
GSM circuit-switched services detached means that the subscriber is detached from a GSM MSC. 43 This is also referred to as IMSI detached. 44 45 GSM Mode 46
GSM mode indicates the condition or state of a mobile station accessing a GSM network. 47
N.S0028
Post Ballot Version 7
GSM Foreign Mode 1
GSM foreign mode indicates the condition or state of an ANSI-136 41 native subscriber accessing a 2 GSM network. 3
GPRS HLR 4
General Packet Radio Service Home Location Register is the HLR responsible for GPRS functions. It 5 interfaces with the SGSN and GGSN and Authentication Center. 6 7 GPRS in GSM Foreign Mode 8
GPRS in GSM Foreign Mode is a subset of GSM Foreign Mode and indicates the condition or state of 9 an ANSI-136 41 native subscriber accessing a GPRS network; the GPRS network may be coupled 10 with a GSM network. 11 12 GSM Native Mode 13
GSM native mode indicates the condition or state of a GSM native subscriber accessing a GSM 14 network. 15
16
N.S0028
Post Ballot Version 8
GSM Native Subscriber 1
GSM native subscriber indicates an end user whose primary or home subscription resides in a GSM 2 network. These subscribers include both home subscribers from the GSM network, as well as 3 roamers from other GSM networks. 4
Mobile Station 5
The mobile equipment and the SIM together make up the mobile station, which is the wireless 6 radiotelephone used by the subscriber. 7
Subscriber Identity Module 8
A smart card that plugs into the mobile equipment and that contains the authentication algorithms, 9 and stores service-oriented subscription information. 10
11
12
N.S0028
Post Ballot Version 9
3.2 Acronyms 1
AC Authentication Center in TIA/EIA-41 based networks 2
ADN Abbreviated Dialing Numbers 3
AuC Authentication Center in GSM networks 4
AMPS Advanced Mobile Phone Service 5
ANSI American National Standards Institute 6
BAIC Barring of All Incoming Calls 7
BAOC Barring of All Outgoing Calls 8
BIC-Roam Barring of Incoming Calls while Roaming Outside HPLMN Country 9
BOIC Barring of Outgoing International Calls 10
BOIC-exHC Baring of Outgoing International Calls Except to HPLMN Country 11
CDMA Code-Division Multiple Access 12
CFB Call Forwarding Busy 13
CFNA Call Forwarding No Answer 14
CFNRc Call Forwarding Not Reachable 15
CFNRy Call Forwarding No Reply 16
CFU Call Forwarding Unconditional 17
CPHS Common PCN Handset Specification 18
DCS Data Coding Scheme 19
EIA Electronics Industry Association 20
ESN Electronic Serial Number 21
ETSI European Telecommunications Standards Institute 22
EUI ESN Usage Indicator 23
FC Feature Code 24
FDN Fixed Dialing Numbers 25
FSM Forward Short Message 26
GGSN Gateway GPRS Support Node 27
GHOST GSM Hosted SMS Teleservice 28
GMSC Gateway Mobile Switching Center 29
GPRS General Packet Radio Service 30
GSM Global System for Mobile Communications 31
HLPI Higher Layer Protocol Indicator 32
N.S0028
Post Ballot Version 10
HLR Home Location Register 1
HPLMN Home Public Land Mobile Network 2
IIF Interworking and Interoperability Function 3
IMEI International Mobile Equipment Identifier 4
IMSI International Mobile Subscriber Identity 5
Interim OAA Interim Over-the-Air Activation 6
IRDB Intelligent Roaming Database 7
ITU International Telecommunications Union 8
MAP Mobile Application Part 9
MC ANSI-136 41 Message Center (for SMS) 10
MDN Mobile Directory Number 11
ME Mobile Equipment 12
MIN Mobile Identification Number 13
MO Mobile Originated 14
MS Mobile Station 15
MSC Mobile Switching Center 16
MSCIN MSC Identification Number 17
MSID Mobile Station Identity 18
MSISDN Mobile Subscriber ISDN Number 19
MSRN Mobile Station Routing Number 20
MT Mobile Terminated 21
MWN Message Waiting Notification 22
NAM Numeric Assignment Module 23
NSDB Network Selection Database 24
ODB Operator Determined Barring 25
OTA Over-the-Air Activation 26
PCS Personal Communications Service 27
PDU Packet Data Unit 28
PIN Personal Identification Number 29
PLMN Public Land Mobile Network 30
PRN Provide Roaming Number 31
PSAP Public Safety Access Point 32
N.S0028
Post Ballot Version 11
SESN SIM Electronic Serial Number 1
SGSN Serving GPRS Support Node 2
SID System Identity 3
SIM Subscriber Identity Module 4
SMDPP Short Message Delivery Point-to-Point 5
SMS Short Message Service 6
SMS-C GSM Short Message Service Center 7
SOC System Operator Code 8
SS7 Signaling System 7 9
TDMA Time Division Multiple Access 10
TP-FCS TP Failure Cause 11
TIA Telecommunications Industry Association 12
TLDN Temporary Location Directory Number 13
TMSI Temporary Mobile Station Identity 14
TS Teleservice Server 15
TSAR Teleservice Segmentation and Reassembly 16
UWCC Universal Wireless Communications Consortium 17
UDH Universal Data Header 18
VLR Visitor Location Register 19
VPLMN Visitor Public Land Mobile Network 20
WAP Wireless Application Protocol 21
WEMT Wireless Enhanced Messaging Teleservices 22
23
24
N.S0028
Post Ballot Version 12
4 Stage 2 Information Flows 1
4.1 Location Registration 2
4.1.1 Location Registration in GSM Foreign Mode 3
B.1.1.2 4.1.1.1 MS registers in a GSM network when previously registered in an 4 ANSI-41 network 5
When an ANSI-136 41 subscriber registers in a GSM network, when previously registered in an 6 ANSI-41 network, the MS performs a location update using the IMSI as shown in Figure 1. The IIF 7 emulates both a GSM HLR/AuC and an ANSI-41 VLR in this case. 8
9
Figure 1: Registration on a GSM Network – GSM Foreign Mode 10
11
MSMSC/VLR IIF HLR
Update Location Req
Authentication Info
Authentication Info Ack
Authentication Req
AuthenticationRes
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
N.S0028
Post Ballot Version 13
a. MS powers up and registers in a GSM network. The MS sends an Update Location Request 1 (which includes the IMSI) to the network. 2
b. If the serving VLR does not have authentication information in order to perform authentication 3 i.e. authentication triplets, it requests authentication information from the IIF. The IIF emulates 4 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 the 9 IMSI. 10
g. The IIF translates the GSM MAP Update Location Request into an ANSI-41 MAP REGNOT 11 and sends the REGNOT to the subscribers home HLR. The IIF is emulating an ANSI-41 VLR 12 when it sends the REGNOT. If necessary, the subscriber IMSI in the Update Location 13 Request is mapped to the associated MIN. 14
If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall 15 be passed in the REGNOT to the subscriber’s HLR. This ESN may not match the currently 16 validated dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for 17 this subscriber. 18
h. The HLR updates its location information and deletes the previous VLR record by sending a 19 REGCANC to the previous VLR. 20
i. The VLR acknowledges the REGCANC 21
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 Data Procedure 23 towards the serving VLR. This procedure is used to download subscriber data to the serving 24 VLR. Multiple Insert Subscriber Data transactions may be necessary to complete the transfer 25 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, the 28 IIF returns an acknowledgement for the Update Location Request. 29
30
N.S0028
Post Ballot Version 14
B.1.1.3 4.1.1.2 MS location updates in a different MSC/VLR 1
When an ANSI-136 41 subscriber roams within a GSM PLMN and registers in a different MSC/VLR 2 area, the 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 Mode 5
a. MS powers up and registers in a different MSC/VLR in the same GSM network. The MS sends 6 an Update Location Request (which includes the IMSI) to the network. 7
8 b. If the serving VLR does not have authentication information in order to perform authentication 9
i.e. authentication triplets, it requests authentication information from the IIF. The IIF emulates 10 a GSM HLR/AuC in this case. 11
12 c. The IIF returns the necessary authentication information. 13 14 d. VLR initiates authentication towards the MS. 15 16 e. 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
N.S0028
Post Ballot Version 15
1 f. VLR initiates Location Updating towards the IIF. The Update Location Request contains the 2
IMSI. 3 4 g. The IIF sends a Cancel Location request to the previous VLR (PVLR) that the subscriber was 5
registered on. 6 7 h. The PVLR deletes the subscriber record and acknowledges the request. 8
9 i. Optionally, the IIF may send a Registration Notification to the HLR to indicate the changed 10
location. 11 12
If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall 13 be passed in the REGNOT to the subscriber’s HLR. This ESN may not match the currently 14 validated dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for this 15 subscriber. 16 17
j. The HLR acknowledges the REGNOT. 18 19 k. The IIF initiates the GSM MAP Insert Subscriber Data Procedure towards the serving VLR. This 20
procedure is used to download subscriber data to the new serving VLR. Multiple Insert 21 Subscriber Data transactions may be necessary to complete the transfer of subscriber data to 22 the VLR. 23
24 l. The VLR acknowledges the Insert Subscriber Data operation(s). 25 26 m. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF 27
returns an acknowledgement for the Update Location Request. 28 29 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 or 31 TIMSI may be used as described in GSM 09.02 [6]. The IIF however, is not informed. 32
B.1.1.4 4.1.1.3 IMSI Detach 33
If a MS powers off while operating in GSM Foreign mode, and the IMSI Detach procedure is 34 supported, it shall perform an IMSI Detach as described in GSM 09.02 [6]. Neither the IIF or the home 35 HLR is informed. 36
Terminating calls intended for this ANSI-136 41 subscriber, shall therefore be treated in the home 37 HLR as if that subscriber was available. 38
If the MS remains inactive for an extended period of time (determined by operator), the VLR may 39 delete the subscriber record associated with that MS and shall send an MS PURGE to the IIF. In this 40 case, the IIF shall send an MS INACTIVE towards the ANSI-41 HLR and the ANSI-41 HLR shall 41 follow the procedures outlined in ANSI-41 [1]. (Terminating calls intended for this ANSI-136 41 42 subscriber, shall therefore be treated in the home HLR as if that subscriber was not available). 43
44
N.S0028
Post Ballot Version 16
B.1.1.5 4.1.1.4 IMSI Attach 1
If an MS powers on and registers on the same MSC/VLR (that has not deleted the subscriber record) 2 while operating in GSM Foreign mode and the IMSI Attach procedure is supported, it shall perform an 3 IMSI Attach as described in GSM 09.02 [6]. 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), 5 while operating in GSM Foreign mode and the IMSI Attach procedure is supported, it shall perform an 6 IMSI Attach as described in GSM 09.02 [6]. The IIF shall be informed as shown in Section 4.1.1.2. 7 (however the IIF shall not send a Cancel Location to the MSC/VLR as it is the same MSC/VLR). 8
If an MS powers on and registers on a different MSC/VLR, while operating in GSM Foreign mode and 9 the IMSI Attach procedure is supported, it shall perform an IMSI Attach as described in GSM 09.02 10 [6]. The IIF shall be informed as shown in Section 4.1.1.2. 11
12
N.S0028
Post Ballot Version 17
4.1.2 Location Registration in ANSI-41 Foreign Mode 1
B.1.1.6 4.1.2.1 MS registers in an ANSI-41 network when previously registered in a 2 GSM network 3
When a GSM subscriber registers in an ANSI-41 network, when previously registered in a GSM 4 network, the MS performs a location update using an IMSI or MIN as shown in Figure 3. The IIF 5 emulates both an ANSI-41 HLR and a GSM VLR in this case. 6
7
Figure 3: Registration on an ANSI-41 network – ANSI-41 Foreign Mode 8
9
a. Upon MS power up, if global authentication is active, the MS first sends an Authentication 10 message to the network. The MS then sends a Registration message (which includes the IMSI 11 or MIN) to the network. 12
13 b. If global authentication is active upon registration, the serving VLR initiates an AUTHREQ 14
towards the IIF. The IIF emulates an ANSI-41 HLR/AC in this case. 15 16
The reported ESN for this subscriber shall be dynamic to support SIM-based roaming. The IIF 17 shall authenticate the subscriber using this reported ESN. 18 19
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
N.S0028
Post Ballot Version 18
c. The IIF acknowledges the authentication request. If authentication is successful, the IIF shall 1 store the reported ESN as the currently validated dynamic ESN for this subscriber. The 2 currently validated dynamic ESN shall be maintained by the ANSI-41 HLR emulation function in 3 the IIF. 4
5 d. VLR sends a REGNOT message to the IIF. 6 7 e. The IIF translates the ANSI-41 MAP REGNOT into a GSM MAP Update Location Request 8
(which includes the IMSI) and sends the Update Location Request to the subscribers home 9 HLR. The IIF is emulating a GSM VLR when it sends the Update Location Request. 10
11 f. The HLR updates its location information and deletes the previous VLR record by sending a 12
Cancel Location to the previous VLR. 13 14 g. The VLR acknowledges the Cancel Location. Note: The GSM Insert Subscriber data procedure 15
between the HLR and the IIF takes place between steps g and h. 16 17 h. The HLR acknowledges the Update Location Request 18 19 i. The IIF acknowledges the REGNOT. The acknowledgement also contains the subscriber data 20
download to the new serving VLR. 21 22 j. The MSC/VLR acknowledges the Registration message from the MS. 23
24
N.S0028
Post Ballot Version 19
B.1.1.7 4.1.2.2 MS location updates in a different MSC/VLR 1
When a GSM subscriber roams within an ANSI-41 network and registers in a different MSC/VLR 2 area, 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 Mode 5
6
a. MS powers up and registers in a new MSC/VLR in the same ANSI-41 network. If global 7 authentication is active, the MS sends an Authentication message to the network. The MS also 8 sends a Registration message (which includes the IMSI / MIN) to the network. 9
10 b. If global authentication is active upon registration, the serving VLR initiates an AUTHREQ 11
towards the IIF. The IIF emulates an ANSI-41 HLR/AC in this case. 12 13
The reported ESN for this subscriber shall be dynamic to support SIM-based roaming. The IIF 14 shall authenticate the subscriber using this reported ESN. 15 16
c. The IIF acknowledges the authentication request. If authentication is successful, the IIF shall 17 store the reported ESN as the currently validated dynamic ESN for this subscriber. 18
19
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
N.S0028
Post Ballot Version 20
The currently validated dynamic ESN shall be maintained by the ANSI-41 HLR emulation 1 function in the IIF. 2
3 d. VLR sends a REGNOT message to the IIF. 4 5 e. The IIF deletes the subscriber record in the previous VLR (PVLR), by sending a REGCANC to 6
the PVLR. 7 8
f. The PVLR acknowledges the REGCANC. 9 10
g. Optionally, the IIF may send an Update Location Request to the HLR to indicate the changed 11 location. 12
13 h. The HLR acknowledges the update location. 14
15 i. The IIF acknowledges the REGNOT. 16
17 j. The new serving MSC/VLR acknowledges the Registration message from the MS. 18 19
B.1.1.8 4.1.2.3 MS Powers Off 20
If a mobile station powers off while operating in ANSI-41 Foreign mode, the IIF receives an MS 21 INACTIVE message from the serving VLR. This results in the IIF setting the ‘IMSI Detached’ Flag. If 22 the MS remains inactive for an extended period of time (determined by operator), the IIF may delete 23 the subscriber record associated with that MS and send an MS Purge to the HLR. 24
B.1.1.9 4.1.2.4 MS Powers On 25
If a mobile station powers on and registers on an MSC/VLR, while operating in ANSI-41 Foreign 26 mode, normal registration procedures apply. 27
4.1.3 Location Registration in Native Mode 28
B.1.1.10 4.1.3.1 MS registers in an ANSI-41 network when previously registered in a 29 GSM network 30
When an ANSI subscriber registers in an ANSI-41 network (Native Mode), when previously registered 31 in a GSM Network (Foreign Mode), the MS performs a location update and the temporary subscriber 32 data in the IIF is deleted as shown in figure 5. 33
N.S0028
Post Ballot Version 21
Figure 5: Registration in an ANSI-41 Network (Native Mode) 1
2
a. MS powers up and registers in a new MSC/VLR in an ANSI-41 network. 3 If global authentication is active upon registration, the serving VLR initiates an AUTHREQ 4 towards the ANSI-41 HLR. 5
The reported ESN for this subscriber shall be dynamic to support SIM-based roaming. The HLR 6 shall authenticate the subscriber using this reported ESN. 7 8
c. The HLR acknowledges the authentication request. If authentication is successful, the HLR shall 9 store the reported ESN as the currently validated dynamic ESN for this subscriber. 10
11 d. The serving VLR sends a REGNOT to the HLR. 12 13 e. The HLR sends a REGCANC to the IIF. 14 15 f. The IIF deletes the temporary subscriber data and sends a Cancel Location to the previous VLR 16
in the GSM network. 17 18 g. The previous VLR deletes the relevant subscriber data and acknowledges the request. 19 20 h. The IIF acknowledges the REGCANC. 21 22 i. HLR updates the new serving VLR. 23 24 j. The VLR acknowledges the update towards the MS. 25
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
N.S0028
Post Ballot Version 22
B.1.1.11 4.1.3.2 MS registers in a GSM network when previously registered in an ANSI-1 41 network 2
When a GSM subscriber registers in a GSM network (Native Mode), when previously registered in an 3 ANSI-41 Network (Foreign Mode), the MS performs a location update and the temporary subscriber 4 data in the IIF is deleted as shown in figure 6. 5
Figure 6: Registration in a GSM Network (Native Mode) 6
7
a. MS powers up and registers in a new MSC/VLR in a GSM network. 8 9 b. The serving VLR sends an Update Location Request to the HLR. 10 11 c. The HLR sends a Cancel Location to the IIF. 12 13 d. The IIF deletes the temporary subscriber data and sends a REGCANC to the previous VLR in the 14
ANSI-41 network. 15 16 e. The Previous VLR deletes the relevant subscriber data and acknowledges the request. 17 18 f. The IIF acknowledges the Cancel Location Request. 19 20
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
N.S0028
Post Ballot Version 23
g. HLR updates the new serving VLR. 1 2 h. The VLR acknowledges the update. 3 4 i. The HLR acknowledges the Update Location Request. 5 6 j. The VLR acknowledges the Update Location Request towards the MS. 7
8
9
N.S0028
Post Ballot Version 24
4.2 Fault Recovery Procedures 1
After a fault of a location register, the fault recovery procedures ensure that the subscriber data in the 2 VLR becomes consistent with the subscriber data that are stored in the IIF (emulating an HLR) or that 3 subscriber data in the IIF (emulating a VLR) becomes consistent with the subscriber data that are 4 stored in the HLR for the MS concerned, and that the location information in the IIF (emulating an 5 HLR) and VLR or the HLR and IIF (emulating a VLR) reflect accurately the current location of the MS. 6
Existing fault recovery procedures described in GSM 09.02 [6] or ANSI-41D [1] are directly applicable 7 to the IIF, while the IIF is emulating a GSM or ANSI 41 functional entity. 8
4.2.1 Fault Recovery Procedures in GSM Foreign Mode 9
B.1.1.12 4.2.1.1 Recovery from Failure at the ANSI-41 HLR 10
When the ANSI-41 HLR returns to a stable state after suffering a failure, it shall send the IIF 11 (emulating an ANSI-41 VLR) an UnreliableRoamerDataDirective message (UNRELDIR) as described 12 in ANSI 41.3 D [1], informing the IIF that it has experienced a failure which has rendered the HLR’s 13 roaming MS data unreliable. Figure 7 below shows the call flow. 14
When the roaming MS next makes radio contact, the serving GSM VLR shall initiate the location 15 updating procedure towards the IIF. 16
17
Figure 7: Failure at the ANSI-41 HLR (GSM Foreign Mode) 18
19
a. HLR returns to stable state following a failure and sends an UNRELDIR towards the IIF. 20 21 b. The IIF acknowledges the request and removes all the temporary subscriber data of all the MSs 22
associated with that HLR from its memory. 23 24 c. The IIF may reload its data from a non-volatile backup (optional) and shall send a RESET 25
towards each of the serving VLRs. The RESET message contains a unique identity, identifying 26 the ANSI-41 HLR that failed and that is connected to the IIF. 27
28
When the MS next establishes authenticated radio contact (including a mobile originated call 29 attempt), the VLR initiates location updating towards the IIF (See 4.1.1). 30
VLR IIF HLR
GSM NETWORK ANSI-41 NETWORK
UNRELDIR
RESET
unreldir
a
b
c
N.S0028
Post Ballot Version 25
B.1.1.13 4.2.1.2 Recovery from Failure at the IIF 1
If the IIF suffers a failure, it shall follow the recovery procedure described in GSM 09.02 [6] section 2 19.3.2 (i.e. IIF is acting like a GSM HLR). As part of the recovery procedure, the IIF shall send all the 3 serving GSM VLRs a RESET message for each associated ANSI-41 HLR as shown in step a) in 4 Figure 8. The message shall contain a unique identifier for the ANSI-41 HLR. In addition, the IIF shall 5 send a BULKDEREG to all affected ANSI-41 HLRs (i.e. IIF is acting like an ANSI-41 VLR). 6
Figure 8: IIF Failure (GSM Foreign Mode) 7
a. The IIF sends a RESET towards each of the affected VLRs, containing a unique identity, 8 identifying the ANSI-41 HLRs connected to the IIF. 9
10 b. The IIF sends a BULKDEREG towards all the affected ANSI-41 HLRs. On reception of the 11
BULKDEREG the HLR(s) follow(s) the procedures as described in ANSI-41.6D [1]. 12 13 c. The ANSI-41 HLR(s) responds with a bulkdereg. 14 15 When the MS next establishes authenticated radio contact (including a mobile originated call 16 attempt), the VLR initiates location updating towards the IIF (See 4.1.1). 17 18 19
20
VLR IIF HLR
GSM NETWORK ANSI-41 NETWORK
RESET
BULKDEREG
a
b
cbulkdereg
N.S0028
Post Ballot Version 26
B.1.1.14 4.2.1.3 Recovery from Failure at the serving GSM VLR 1
If the VLR suffers a failure, it shall follow the recovery procedure described in GSM 09.02 [6] section 2 19.3.1. As part of the recovery procedure, when a MS next establishes authenticated radio contact, 3 the 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 shall 5 send a RESTORE DATA message to the IIF as shown in Figure 9. 6
Figure 9: Terminating Call Flow following a GSM VLR Failure 7
8
a. Terminating call arrives for MS following a GSM VLR failure. 9 10 b,c,d The IIF follows normal mobile terminated call handling procedures (See 4.5.2.1). 11 12 e. The VLR may request more authentication sets prior to sending Restore Data to the IIF to request 13
subscriber data. 14 15 f. 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
19
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
N.S0028
Post Ballot Version 27
4.2.2 Fault Recovery Procedures in ANSI-41 Foreign Mode 1
B.1.1.15 4.2.2.1 Recovery from Failure at the GSM HLR 2
When a GSM HLR undergoes a restart, it shall follow the procedures described in GSM 09.02 [6] 3 section 19.3.2. As part of the recovery procedure, the HLR sends the IIF a RESET message, 4 informing the IIF that it has experienced a failure, which has rendered the HLR’s roaming MS data 5 unreliable. When the roaming MS next makes radio contact, the serving ANSI-41 VLR shall initiate 6 the location updating procedure towards the IIF. Figure 10 below shows the call flow. 7
8 Figure 10: Failure at a GSM HLR (ANSI-41 Foreign Mode) 9
10
a. The HLR follows the recovery procedures described in GSM 09.02 [6] section 19.3.2. The 11 affected sends a RESET towards the IIF. 12
13 b. The IIF follows the procedures described in GSM 09.02 [6] section 19.3.2 on reception of the 14
RESET and sends an UNRELDIR towards each of the serving ANSI-41 VLRs. The UNRELDIR 15 message contains a unique identity, identifying the affected GSM HLR. 16
17 c. The VLR follows the procedures described in ANSI-41.3 [1] and ANSI-41.6 [1] and acknowledges 18
the UNRELDIR. 19 20 When the MS next establishes authenticated radio contact (including a mobile originated call 21 attempt), the VLR initiates location updating towards the IIF (See 4.1.2.1). 22 23
24
HLR IIF VLR
GSM NETWORKANSI-41 NETWORK
UNRELDIR
RESET
unreldir
a
b
c
N.S0028
Post Ballot Version 28
B.1.1.16 4.2.2.2 Recovery from Failure at the IIF 1
If the IIF suffers a failure, it shall follow the recovery procedure described in ANSI-41.6 [1] (i.e. IIF is 2 acting like an ANSI HLR). As part of the recovery procedure, the IIF shall send all the serving 3 ANSI-41 VLRs an UNRELDIR message for each associated GSM HLR as shown in steps b and c in 4 Figure 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 call 6 attempt), 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 RESTORE 8 DATA towards the requesting GSM HLR. 9
B.1.1.17 4.2.2.3 Recovery from Data Failure at the ANSI-41 VLR 10
If the ANSI-41 VLR suffers a failure, it shall follow the recovery procedure described in ANSI-41.6 [1]. 11 As part of the recovery procedure, when an MS next establishes authenticated radio contact, the VLR 12 shall initiate location updating towards the IIF. 13
Upon receipt of a BULKDEREG, the IIF shall clear the location pointer for those MSs that were 14 registered on that VLR. If following the reception of a BULKDEREG, the IIF receives a request for 15 routing information, the terminating call towards the MS shall not be possible until the MS has 16 performed a successful location registration. 17
18
N.S0028
Post Ballot Version 29
4.3 Authentication 1
4.3.1 ANSI-41 Foreign Mode Authentication Activation 2
B.1.1.18 4.3.1.1 Receiving AUTHREQ Message 3
B.1.1.18.1 4.3.1.1.1 Successful AUTHREQ Response Received from ANSI-41 AC 4
5
ANSI-41 Serving System
MSC/VLR IIFANSI-41
AC
a
b
c
d
AUTHREQ
authreq
AUTHREQ
authreq
6
Figure 11: AUTHREQ - Successful Case 7
a,b,c,d The IIF is emulating an ANSI-41 HLR. For successful processing, see to ANSI-41 [1]. 8
9
N.S0028
Post Ballot Version 30
B.1.1.18.2 4.3.1.1.2 AUTHREQ Failure Reported by IIF 1
2
ANSI-41ServingSystem
MSC/VLR IIFANSI-41
AC
a
b
c
d
AUTHREQ
authreq
AUTHREQ
authreq
(error handling)
(error handling)
3
Figure 12: AUTHREQ - Unsuccessful Case 4
5
a,b,c,d The IIF is emulating an ANSI-41 HLR. For error handling see to ANSI-41 [1]. 6
7
N.S0028
Post Ballot Version 31
B.1.1.19 4.3.1.2 Receiving AFREPORT Message 1
B.1.1.19.1 4.3.1.2.1 Successful AFREPORT Response Received from ANSI-41 AC 2
3
ANSI-41 Serving System
MSC/VLR IIFANSI-41
AC
a
b
c
d
AFREPORT
afreport
AFREPORT
afreport
4
Figure 13: AFREPORT - Successful Case 5
6
a,b,c,d The IIF is emulating an ANSI-41 HLR. For successful processing, see to ANSI-41 [1]. 7
8
9
N.S0028
Post Ballot Version 32
B.1.1.19.2 4.3.1.2.2 AFREPORT failure reported by IIF 1
2
ANSI-41ServingSystem
MSC/VLR IIFANSI-41
AC
a
b
c
d
AFREPORT
afreport
AFREPORT
afreport
(error handling)
(error handling)
3
Figure 14: AFREPORT - Unsuccessful Case 4
5
a,b,c,d The IIF is emulating an ANSI-41 HLR. For error handling see to ANSI-41.D [1]. 6
7
N.S0028
Post Ballot Version 33
B.1.1.20 4.3.1.3 Receiving ASREPORT Message 1
B.1.1.20.1 4.3.1.3.1 Successful ASREPORT Response Received from ANSI-41 AC 2
3
ANSI-41 Serving System
MSC/VLR IIFANSI-41
AC
a
b
c
d
ASREPORT
asreport
ASREPORT
asreport
4
Figure 15: ASREPORT - Successful Case 5
6
a,b,c,d The IIF is emulating an ANSI-41 HLR. For successful processing, see to ANSI-41 [1]. 7
8
N.S0028
Post Ballot Version 34
B.1.1.20.2 4.3.1.3.2 ASREPORT Failure Reported by IIF 1
2
ANSI-41ServingSystem
MSC/VLR IIFANSI-41
AC
a
b
c
d
ASREPORT
asreport
ASREPORT
asreport
(error handling)
(error handling)
3
Figure 16: ASREPORT - Unsuccessful Case 4
5
a,b,c,d The IIF is emulating an ANSI-41 HLR. For error handling see to ANSI-41 [1]. 6
7
N.S0028
Post Ballot Version 35
B.1.1.21 4.3.1.4 Receiving BSCHALL Message 1
B.1.1.21.1 4.3.1.4.1 Successful BSCHALL Response Received from ANSI-41 AC 2
3
ANSI-41ServingSystem
MSC/VLR IIFANSI-41
AC
a
b
c
d
BSCHALL
bschall
BSCHALL
bschall
4
Figure 17: BSCHALL - Successful Case 5
6
a,b,c,d The IIF is emulating an ANSI-41 HLR. For successful processing, see to ANSI-41 [1]. 7
8
N.S0028
Post Ballot Version 36
B.1.1.21.2 4.3.1.4.2 BSCHALL Failure Reported by IIF 1
2
ANSI-41ServingSystem
MSC/VLR IIFANSI-41
AC
a
b
c
d
BSCHALL
bschall
BSCHALL
bschall
(error handling)
(error handling)
3
Figure 18: BSCHALL - Unsuccessful Case 4
5
a,b,c,d The IIF is emulating an ANSI-41 HLR. For error handling see to ANSI-41 [1]. 6
7
N.S0028
Post Ballot Version 37
B.1.1.22 4.3.1.5 Receiving AUTHDIR Message 1
B.1.1.22.1 4.3.1.5.1 Successful AUTHDIR Response Received from Serving System 2
3
ANSI-41 Serving System
MSC/VLR IIFANSI-41
AC
a
b
c
d
AUTHDIR
authdir
AUTHDIR
authdir
4
Figure 19: AUTHDIR - Successful Case 5
6
a,b,c,d The IIF is emulating an ANSI-41 HLR. For successful processing, see to ANSI-41 [1]. 7
8
N.S0028
Post Ballot Version 38
B.1.1.22.2 4.3.1.5.2 AUTHDIR failure Received from Serving System 1
2
ANSI-41ServingSystem
MSC/VLR IIFANSI-41
AC
a
b
c
d
AUTHDIR
authdir
AUTHDIR
authdir
(error handling)
(error handling)
3
Figure 20: AUTHDIR - Unsuccessful Case 4
5
a,b,c,d The IIF is emulating an ANSI-41 HLR. For error handling see to ANSI-41 [1]. 6
7
N.S0028
Post Ballot Version 39
B.1.1.23 4.3.1.6 Receiving COUNTREQ Message 1
B.1.1.23.1 4.3.1.6.1 Successful COUNTREQ Response Received from Serving System 2
3
ANSI-41 Serving System
MSC/VLR IIFANSI-41
AC
a
b
c
d
COUNTREQ
countreq
COUNTREQ
countreq
4
Figure 21: COUNTREQ - Successful Case 5
6
a,b,c,d The IIF is emulating an ANSI-41 HLR. For successful processing, see to ANSI-41 [1]. 7
8
N.S0028
Post Ballot Version 40
B.1.1.23.2 4.3.1.6.2 COUNTREQ Failure Received from Serving System 1
2 ANSI-41ServingSystem
MSC/VLR IIFANSI-41
AC
a
b
c
d
COUNTREQ
countreq
COUNTREQ
countreq
(error handling)
(error handling)
3
Figure 22: COUNTREQ - Unsuccessful Case 4
5
a,b,c,d The IIF is emulating an ANSI-41 HLR. For error handling see to ANSI-41 [1]. 6
7
N.S0028
Post Ballot Version 41
B.1.2 4.3.2 GSM Foreign Mode Authentication Activation 1
B.1.2.1 4.3.2.1 Authentication Related Messages 2
B.1.2.1.1 4.3.2.1.1 Receiving SEND_AUTHENTICATION_INFO (Version 2 MAP) 3
4
MSC/VLRIIF
a
b
c
d
SEND_AUTH_INFO
send_auth_info
GSMServingSystem
GSMAuC
SEND_AUTH_INFO
send_auth_info
5
Figure 23: SEND_AUTH_INFO 6
7
a,b,c,d The IIF is emulating a GSM HLR. For successful processing, see to GSM 09.02 [6]. 8
9
N.S0028
Post Ballot Version 42
B.1.2.1.2 4.3.2.1.2 Receiving SEND_PARAMETER (Version 1 MAP) 1
2
MSC/VLRIIF
a
b
c
d
SEND_PARAMETER
send_parameter
GSM Serving System
GSM AuC
SEND_PARAMETER
send_parameter
3
Figure 24: SEND_PARAMETER with Request for Authentication Set 4
5
a,b,c,d The IIF is emulating a GSM HLR. For successful processing, see to GSM 09.02 [6]. 6
7
N.S0028
Post Ballot Version 43
4.4 Subscriber Data Management 1
4.4.1 Subscriber Data Management Procedures in ANSI-41 Foreign Mode 2
Two types of subscriber data management procedures are defined in GSM 09.02 [6]. These 3 procedures impact the GSM subscribers HLR, the IIF and the serving VLR when the subscriber is 4 operating in ANSI-41 Foreign Mode. For these procedures, only modification to temporary subscriber 5 data in the IIF is addressed. The procedures are (1) Subscriber Deletion and (2) Subscriber Data 6 Modification. 7
B.1.2.2 4.4.1.1 Subscriber Deletion 8
In this procedure, temporary subscriber data shall be removed from the HLR, IIF and the serving 9 MSC/VLR as shown in Figure 25. 10
Figure 25: Subscriber Deletion – ANSI-41 Foreign Mode 11
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 to 13 the IIF. 14
c. The IIF deletes the temporary subscriber data from the IIF and sends a Registration 15 Cancellation to the serving MSC/VLR. The CancellationType in this operation shall be set to 16 “Discontinue” to tear down any active call. 17
d. The VLR deletes the subscriber data from the VLR and returns an acknowledgement to the 18 IIF. 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
N.S0028
Post Ballot Version 44
e. The IIF acknowledges the cancel location request. 1
f. The HLR acknowledges the delete subscriber request. 2 3
B.1.2.3 4.4.1.2 Subscriber Data Modification 4
The OMC can modify subscriber data in several different ways e.g. withdrawal of a basic or 5 supplementary service, roaming modifications, data modifications to both HLR and VLR. Depending 6 on the data modification required, one of three MAP procedures is initiated from the HLR towards the 7 IIF. These procedures are described in more detail in GSM 09.02 [6]. 8
B.1.2.3.1 4.4.1.2.1 Insert Subscriber Data Procedure 9
Where data is required to be modified in the HLR, IIF and the serving VLR, the HLR initiates the 10 Insert Subscriber Data Procedure towards the IIF as shown in Figure 26. 11
Figure 26: Insert Subscriber Data Procedure 12
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 Data 14 Operation towards the IIF. 15
c. The IIF modifies the subscriber data in the IIF and sends a QUALDIR to the serving MSC/VLR. 16 There may be some cases where the subscriber data change cannot be mapped to an 17 associated ANSI-136 41 subscriber profile modification. In this case, no QualDir operation shall 18 be initiated. 19
d. The serving MSC/VLR modifies the subscriber data and acknowledges the QUALDIR 20
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
N.S0028
Post Ballot Version 45
e. The IIF acknowledges the Insert Subscriber Data Request. 1
f. The HLR acknowledges the request to modify subscriber data. 2 3
B.1.2.3.2 4.4.1.2.2 Delete Subscriber Data Procedure 4
If a basic or supplementary service is withdrawn, which requires a change to VLR data, the HLR 5 initiates the Delete Subscriber Data Procedure towards the IIF as shown in Figure 27. 6
7
Figure 27: Delete Subscriber Data Procedure 8
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 Subscriber 10 Data Operation towards the IIF. 11
c. The IIF deletes the relevant subscriber data in the IIF and sends a QUALDIR to the serving 12 MSC/VLR. There may be some cases where the subscriber data deletion cannot be mapped 13 to an associated ANSI-136 41 subscriber profile modification. In this case, no QualDir 14 operation shall be initiated. 15
d. The serving MSC/VLR deletes the relevant subscriber data and acknowledges the QUALDIR. 16
e. The IIF acknowledges the Delete Subscriber Data Request. 17
f. The HLR acknowledges the request to modify subscriber data. 18
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
N.S0028
Post Ballot Version 46
B.1.2.3.3 4.4.1.2.3 Cancel Location Procedure 1
If roaming modifications are required, which require the subscriber to be removed from the VLR data, 2 the HLR initiates the Cancel Location Procedure towards the IIF as shown in Figure 28. 3
Figure 28: Cancel Location Procedure 4
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 Location 6 Operation towards the IIF. 7
c. The IIF deletes the temporary subscriber data in the IIF and sends a REGCANC to the 8 serving MSC/VLR. 9
d. The serving MSC/VLR deletes the relevant subscriber data and acknowledges the 10 REGCANC. 11
e. The IIF acknowledges the Cancel Location Request. 12
f. The HLR acknowledges the request to modify subscriber data. 13 14
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
N.S0028
Post Ballot Version 47
4.4.2 Subscriber Data Management Procedures in GSM Foreign Mode 1 Subscriber data management procedures are defined in ANSI 41-D, Section 6. These procedures 2 impact the ANSI-136 41 subscribers HLR, the IIF and the serving VLR when the subscriber is 3 operating in GSM Foreign Mode. For these procedures, only modification to temporary subscriber 4 data in the IIF is addressed. 5
B.1.2.4 4.4.2.1 Subscriber Deletion 6
The OMC may request that subscriber data relating to a particular subscriber is removed from the 7 HLR. In this case, subscriber data shall also be removed from the IIF and the serving MSC/VLR as 8 shown in Figure 29. 9
Figure 29: Subscriber Deletion- GSM Foreign Mode 10
a. OMC initiates a request to delete a subscriber 11
b. The HLR deletes the subscriber data from the HLR and sends a REGCANC to the IIF. 12
c. The IIF deletes the temporary subscriber data from the IIF and sends a Cancel Location to the 13 serving VLR. 14
d. The VLR acknowledges the cancel location 15
e. The IIF acknowledges the REGCANC 16
f. The HLR acknowledges the request to delete subscriber data. 17 18
MSC/VLR
IIF HLR
GSM NETWORKNSI-41 NETWO RK
OMC
Sub Data Delete
Sub Data Delete Ack
REGCANC
regcanc
b
e
f
Cancel Location
Cancel Location Ack
N.S0028
Post Ballot Version 48
B.1.2.5 4.4.2.2 Modifying Subscriber Data 1
The OMC may request that subscriber data relating to a particular subscriber is modified (e.g., the 2 authorization or de-authorization of a particular feature). In this case, subscriber data may also be 3 required to be modified in the IIF and the serving MSC/VLR as shown in Figure 30. 4
Figure 30: Subscriber Data Modification 5
6
a. OMC initiates a request to modify subscriber data 7
b. The HLR modifies the subscriber data from the HLR and sends a QUALDIR to the IIF. 8
c. The IIF modifies the temporary subscriber data and sends Insert Subscriber Data to the VLR if for 9 example, a feature has been authorized or activated. 10
Note: The IIF sends a Delete Subscriber Data message if for example, a feature has been 11 de-authorized or de-activated. There may be multiple ISD or DSD operations. There may be 12 some cases where the subscriber data change cannot be mapped to an associated GSM 13 subscriber profile modification. In this case, no ISD or DSD operation shall be initiated. 14
d. The VLR acknowledges the request 15
e. The IIF acknowledges the QUALDIR 16
f. The HLR acknowledges the request to modify subscriber data 17
18
MSC/VLR
IIF HLR
GSM NETWORKNSI-41 NETWO RK
OMC
Sub Data Change
Sub Data Change Ack
QUALDIR
qualdir
b
e
f
Insert Sub Data
Insert Sub Data Ack
N.S0028
Post Ballot Version 49
4.5 Automatic Call Delivery 1
This section depicts the interactions between network entities in various situations related to GSM 2 and ANSI-41 foreign mode operation and automatic call delivery. These scenarios are not meant to 3 be exhaustive. 4
4.5.1 Automatic Call Delivery Activation/Deactivation 5
Activation and deactivation of call delivery is not required to be supported. 6
4.5.2 Automatic Call Delivery Invocation 7
Automatic call delivery is invoked when an incoming call attempt arrives for a subscriber who is 8 roaming. Call delivery scenarios for both the case in which an ANSI-136 41 subscriber is roaming in a 9 GSM network and the case in which a GSM subscriber is roaming in an ANSI-41 network are 10 provided. 11
B.1.2.6 4.5.2.1 Call Delivery to ANSI-136 41 Subscriber Roaming in GSM Network 12
d
LOCREQ
locreq
ROUTREQ
MSC/VLR HLR
IIF
a
b
c
e
f
Serving System
Call setup
GSMMSC/VLR
Provide Roaming No.
PRN Ack
routreq
g
Incoming CallFrom PSTN
h
13
Figure 31: Call Delivery to ANSI-41 Subscriber Roaming in a GSM Network 14
a. A call origination and the dialed MS address digits (i.e., directory number) are received by the 15 Originating 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; this 17 association 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. 19
d. The IIF forwards a Provide Roaming Number message to the VLR/GSM MSC where the MS is 20 registered. If necessary, mapping from MIN to IMSI is done by the IIF. 21
e. The VLR/GSM MSC returns a Provide Roaming Number Ack message to the IIF that includes an 22 MSRN. 23
N.S0028
Post Ballot Version 50
f. The IIF returns a routreq message to the HLR that includes a TLDN (Temporary Local Directory 1 Number), set to the received MSRN, in the Digits (Destination) parameter. Note that the MSRN is 2 always in international format. It is assumed that the gateway MSC on the ANSI-41 side is 3 capable of supporting internationally formatted TLDNs. 4
g. When the routreq is received by the HLR, it returns a locreq to the Originating MSC. The locreq 5 includes routing information in the form of the TerminationList parameter, along with an indication 6 of the reason for extending the incoming call (i.e., for Call Delivery, in this case) in the 7 DMH_RedirectionIndicator parameter. 8
h. Upon receiving the locreq, the Originating MSC sets up a voice path to the Serving GSM MSC 9 (using a protocol such as SS7 ISUP). 10
B.1.2.7 4.5.2.2 Delivery to an ANSI-136 41 Subscriber Roaming in a GSM Network – 11 Unsuccessful Case 12
In the following scenario, call delivery to an ANSI-136 41 subscriber roaming in a GSM network fails 13 during the processing of the Provide Roaming Number message (e.g., no roaming number is 14 available, absent subscriber). 15
d
LOCREQ
locreq Ret Error
ROUTREQ
MSC/VLR HLR
IIF
a
b
c
e
f
Serving System
GSMMSC/VLR
Provide Roaming No.
PRN Return Error
routreq Ret Error
g
Incoming CallFrom PSTN
16
Figure 32: Unsuccessful Call Delivery to an ANSI-136 41 Subscriber Roaming in a GSM 17 Network 18
a. A call origination and the dialed MS address digits (i.e., directory number) are received by the 19 Originating ANSI-41 MSC from the PSTN destined to a subscriber to the ANSI-41 network. 20
b. The Originating ANSI-41 MSC sends a LOCREQ message to the ANSI-41 HLR associated with 21 the called subscriber; this association is made through the dialed MS address digits. 22
c. The ANSI-41 HLR sends a ROUTREQ message to the IIF emulating the VLR where the MS is 23 registered. If necessary, mapping from IMSI to MIN is done beforehand by the IIF. 24
d. The IIF forwards a Provide Roaming Number message to the GSM VLR/MSC where the MS is 25 registered. 26
e. The GSM VLR/MSC determines that either no roaming numbers are available or subscriber is not 27 reachable and it replies with a PRN Return Error message. 28
N.S0028
Post Ballot Version 51
f. The IIF sends a RoutingRequest RETURN ERROR message. 1
g. The ANSI-41 HLR sends a LocationRequest RETURN ERROR message. 2
B.1.2.8 4.5.2.3 Call Delivery to a GSM Subscriber Roaming in ANSI-41 Network – 3 Successful Case 4
d
Send Routing Info
SRI Ack
Provide Roaming No.
GSMMSC/VLR
GSMHLR
IIF
a
b
c
e
f
Serving System
Call setup
MSC/VLR
ROUTREQ
routreq
PRN Ack
g
Incoming CallFrom PSTN
h
5
Figure 33: Call Delivery to GSM Subscriber Roaming in an ANSI-41 Network 6
a. A call origination and the dialed MS address digits (i.e., directory number) are received by the 7 Originating MSC from the PSTN destined to a subscriber to the GSM network. 8
b. The Gateway GSM MSC sends a Send Routing Information message to the GSM HLR 9 associated with the called subscriber; this association is made through the dialed MS address 10 digits. 11
c. The GSM HLR sends a Provide Roaming Number message to the IIF emulating the VLR where 12 the MS is registered. If necessary, mapping from IMSI to MIN is done beforehand by the IIF. 13
d. The IIF forwards a ROUTREQ message to the VLR/MSC where the MS is registered. 14
e. The serving VLR/ MSC returns a routreq message that includes a TLDN to the IIF. 15
f. The IIF returns a Provide Roaming Number Ack message that includes an MSRN (set to the 16 received TLDN) to the GSM HLR. If the TLDN is not received in international format, the IIF shall 17 first convert the TLDN to international format (by prepending the country code associated with the 18 serving system) before setting the MSRN equal to it. 19
g. When the Provide Roaming Number Ack is received by the GSM HLR, it returns a Send Routing 20 Information Ack message to the Gateway GSM MSC. 21
h. Upon receiving the Send Routing Information Ack message, the Gateway GSM MSC sets up a 22 voice path to the Serving MSC (using a protocol such as SS7 ISUP). 23
N.S0028
Post Ballot Version 52
B.1.2.9 4.5.2.4 Call Delivery to a GSM Subscriber Roaming in ANSI-41 Network – 1 Unsuccessful Case 2
In the following scenario, call delivery to a GSM subscriber roaming in an ANSI-41 network fails 3 because the user is either ‘not reachable’ as determined by the IIF or does not answer a page sent by 4 the serving system during the processing of the RouteRequest message, and call forwarding is not 5 active for the subscriber. 6
d
Send Routing Info
SRI Ret Error
Provide Roaming No.
GSMMSC/VLR
GSMHLR
IIF
a
b
c
e
f
Serving System
MSC/VLR
ROUTREQ
routreq[ACCDEN]
PRN Ret Error
g
Incoming CallFrom PSTN
7
Figure 34: Unsuccessful Call Delivery to GSM Subscriber Roaming in an ANSI-41 Network 8
a. A call origination and the dialed MS address digits (i.e., directory number) are received by the 9 Originating MSC from the PSTN destined to a subscriber to the GSM network. 10
b. The Gateway GSM MSC sends a Send Routing Information message to the GSM HLR 11 associated with the called subscriber; this association is made through the dialed MS address 12 digits. 13
c. The GSM HLR sends a Provide Roaming Number message to the IIF emulating the VLR where 14 the MS is registered. If necessary, mapping from IMSI to MIN is done beforehand by the IIF. If 15 the IIF determines that the called subscriber is not reachable, it returns an absent subscriber error 16 as in step f. 17
d. If the IIF determines that the subscriber is reachable, it forwards a ROUTREQ message to the 18 VLR/MSC where the MS is registered. 19
e. The VLR/MSC pages the subscriber does not get a response and returns a routreq message with 20 an AccessDeniedReason parameter set to NoPageResponse. 21
f. The IIF returns a Provide Roaming Number Return Error message with the error code set to 22 Subscriber Absent to the subscriber’s GSM HLR. 23
g. The GSM HLR sends a Send Routing Information Return Error message to the Gateway GSM 24 MSC with the Subscriber Absent error code, and the appropriate treatment (e.g. announcement) 25 is provided to the incoming call by the Gateway GSM MSC. 26
27
N.S0028
Post Ballot Version 53
4.6 Call Forwarding 1
4.6.1 Call forwarding scenarios for ANSI-41 foreign mode 2
The scenarios in this section illustrate the call forwarding information flows applicable to a GSM 3 native subscriber roaming in an ANSI-41 network (i.e., ANSI-41 foreign mode). 4
B.1.2.10 4.6.1.1 Call forwarding unconditional (CFU) 5
The following scenarios illustrate the call forwarding unconditional (CFU) information flows applicable 6 to ANSI-41 foreign mode operation. 7
B.1.2.10.1 4.6.1.1.1 CFU registration 8
This scenario illustrates the CFU registration information flows applicable to ANSI-41 foreign mode 9 operation. 10
h
e
f
g
a
b
c
d
REG_SS
HLR VMSC 2
GSM Home System
ANSI-136 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
11
Figure 35: CFU registration 12
13
N.S0028
Post Ballot Version 54
a. The ANSI-41 serving system receives dialed digits from the subscriber’s mobile station (MS). The 1 serving system detects a “*” character as the first dialed digit. This indicates that the dialed digits 2 are a feature code string.1 3
4 b. The serving system sends a FEATREQ message to the IIF, including the digits received from the 5
subscriber. 6 7 c. The IIF parses the received digit string. In this case, the subscriber has requested to register a 8
call forwarding number. The IIF sends a REG_SS message to the GSM HLR.2 9 10 d. The HLR processes the request and returns a reg_ss message to the IIF, indicating operation 11
success. 12 13 e. The IIF sends a featreq message to the serving system, indicating a successful feature control 14
request. 15 16 f. The serving system sends a feature confirmation signal to the subscriber. 17 18 g. 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 forward 20 number). 21
22 h. The IIF responds with an ISD acknowledgement message. Note that, if the subscriber’s profile is 23
too large for a single ISD message, then multiple ISD exchanges may be executed between the 24 GSM HLR and the IIF. 25
26 i. The GSM HLR completes the operation by closing the TCAP transaction. 27 28 j. The IIF converts the revised GSM profile data into ANSI-41 equivalents. If this results in a change 29
in the value of the subscriber’s ANSI-41 profile, the IIF includes the revised ANSI-41 profile data 30 in a QUALDIR message it sends to the serving system. 31
32 k. The serving system stores the new profile information and responds with a qualdir message. 33
34
B.1.2.10.2 4.6.1.1.2 CFU deregistration (erasure) 35
This scenario illustrates the CFU deregistration information flows applicable to ANSI-41 foreign mode 36 operation. 37
1 Some ANSI-41 serving systems may perform further digit analysis before concluding that the digits represent 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 while roaming on the ANSI-41 serving system.
2 Because the IIF must provide the new call forwarding number digits in the REG_SS message, these digits shall be provided by the subscriber (or the subscriber’s mobile station).
N.S0028
Post Ballot Version 55
h
e
f
g
a
b
c
d
ERASE_SS
HLR VMSC 2
GSM Home System
ANSI-136 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
1
Figure 36: CFU deregistration (erasure) 2
a. The ANSI-41 serving system receives dialed digits from the subscriber’s mobile station (MS). The 3 serving system detects a “*” character as the first dialed digit. This indicates that the dialed digits 4 are a feature code string. 5
6 b. The serving system sends a FEATREQ message to the IIF, including the digits received from the 7
subscriber. 8 9 c. The IIF parses the received digit string. In this case, the subscriber has requested to erase a call 10
forwarding number. The IIF sends an ERASE_SS message to the GSM HLR. 11 12 d. The HLR processes the request and returns an erase_ss message to the IIF, indicating operation 13
success. 14 15 16 e. The IIF sends a featreq message to the serving system, indicating a successful feature control 17
request. 18 19 f. The serving system sends a feature confirmation signal to the subscriber. 20 21 g. The GSM HLR initiates a service profile update by sending an Insert Subscriber Data (ISD) 22
message to the IIF, containing the new or modified profile data (e.g., the new ss-status value). 23 24 25
N.S0028
Post Ballot Version 56
h. The IIF responds with an ISD acknowledgement message. Note that, if the subscriber’s profile is 1 too large for a single ISD message, then multiple ISD exchanges may be executed between the 2 GSM HLR and the IIF. 3
4 i. The GSM HLR completes the operation by closing the TCAP transaction. 5 6 j. The IIF converts the revised GSM profile data into ANSI-41 equivalents. If this results in a change 7
in the value of the subscriber’s ANSI-41 profile, the IIF includes the revised ANSI-41 profile data 8 in a QUALDIR message it sends to the serving system. 9
10 k. The serving system stores the new profile information and responds with a qualdir message. 11
12
N.S0028
Post Ballot Version 57
1
B.1.2.10.3 4.6.1.1.3 CFU activation 2
This scenario illustrates the CFU activation information flows applicable to ANSI-41 foreign mode 3 operation. 4
QUALDIR
qualdir
h
e
f
g
a
b
c
d
ACT_SS
HLR VMSC 2
GSM Home System
ANSI-136 Serving System
FEATREQ [digits]
featreq [success]
MS
Subscriber
feature code digits
act_ss
feature confirmation
ANSI-41GSM
IIF
j
i
k
ISD
isd
[TCAP End]
5
Figure 37: CFU activation 6
a. The ANSI-41 serving system receives dialed digits from the subscriber’s mobile station (MS). The 7 serving system detects a “*” character as the first dialed digit. This indicates that the dialed digits 8 are a feature code string. 9
10 b. The serving system sends a FEATREQ message to the IIF, including the digits received from the 11
subscriber. 12 13 c. The IIF parses the received digit string. In this case, the subscriber has requested to activate call 14
forwarding. The IIF sends an ACT_SS message to the GSM HLR. 15 16 d. The HLR processes the request and returns an act_ss message to the IIF, indicating operation 17
success. 18 19 e. The IIF sends a featreq message to the serving system, indicating a successful feature control 20
request. 21 22 f. The serving system sends a feature confirmation signal to the subscriber. 23 24
N.S0028
Post Ballot Version 58
g. The GSM HLR initiates a service profile update by sending an Insert Subscriber Data (ISD) 1 message to the IIF, containing the new or modified profile data (e.g., the new ss-status value). 2
3 h. The IIF responds with an ISD acknowledgement message. Note that, if the subscriber’s profile is 4
too large for a single ISD message, then multiple ISD exchanges may be executed between the 5 GSM HLR and the IIF. 6
7 i. The GSM HLR completes the operation by closing the TCAP transaction. 8 9 j. The IIF converts the revised GSM profile data into ANSI-41 equivalents. If this results in a change 10
in the value of the subscriber’s ANSI-41 profile, the IIF includes the revised ANSI-41 profile data 11 in a QUALDIR message it sends to the serving system. 12
13 k. The serving system stores the new profile information and responds with a qualdir message. 14 15
16
N.S0028
Post Ballot Version 59
B.1.2.10.4 4.6.1.1.4 CFU deactivation 1
This scenario illustrates the CFU deactivation information flows applicable to ANSI-41 foreign mode 2 operation. 3
QUALDIR
qualdir
h
e
f
g
a
b
c
d
DEACT_SS
HLR VMSC 2
GSM Home System
ANSI-136 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]
4
Figure 38: CFU deactivation 5
a. The ANSI-41 serving system receives dialed digits from the subscriber’s mobile station (MS). The 6 serving system detects a “*” character as the first dialed digit. This indicates that the dialed digits 7 are a feature code string. 8
9 b. The serving system sends a FEATREQ message to the IIF, including the digits received from the 10
subscriber. 11 12 c. The IIF parses the received digit string. In this case, the subscriber has requested to deactivate 13
call forwarding. The IIF sends a DEACT_SS message to the GSM HLR. 14 15 d. The HLR processes the request and returns a deact_ss message to the IIF, indicating operation 16
success. 17 18 e. The IIF sends a featreq message to the serving system, indicating a successful feature control 19
request. 20 21 f. The serving system sends a feature confirmation signal to the subscriber. 22 23
N.S0028
Post Ballot Version 60
g. The GSM HLR initiates a service profile update by sending an Insert Subscriber Data (ISD) 1 message to the IIF, containing the new or modified profile data (e.g., the new ss-status value). 2
3 h. The IIF responds with an ISD acknowledgement message. Note that, if the subscriber’s profile is 4
too large for a single ISD message, then multiple ISD exchanges may be executed between the 5 GSM HLR and the IIF. 6
7 i. The GSM HLR completes the operation by closing the TCAP transaction. 8 9 j. The IIF converts the revised GSM profile data into ANSI-41 equivalents. If this results in a change 10
in the value of the subscriber’s ANSI-41 profile, the IIF includes the revised ANSI-41 profile data 11 in a QUALDIR message it sends to the serving system. 12
13 k. The serving system stores the new profile information and responds with a qualdir message. 14 15
B.1.2.10.5 4.6.1.1.5 CFU Interrogation 16
While in ANSI-41 foreign mode, the GSM subscriber does not have the capability to interrogate the 17 CFU service. An attempt to perform such an operation shall result in an error response 18
B.1.2.10.6 4.6.1.1.6 CFU invocation 19
This scenario illustrates the CFU invocation information flows applicable to ANSI-41 foreign mode 20 operation. 21
d
c
GMSC HLR VMSC 2
a
b
GSM Home System
ANSI-136 Serving System
GSM Gateway
SRI
sri [CFU#]
forward call to CFU #
incoming call
ANSI-41GSM
IIF
22
Figure 39: CFU invocation 23
a. The GSM gateway MSC (GMSC) receives an incoming call for the subscriber. 24 25 b. The GMSC sends a SRI message to the HLR. 26 27 c. The GSM HLR determines that the subscriber has CFU registered and active; therefore, the HLR 28
responds with the subscriber’s CFU forward-to number in the sri message. 29 30 d. The GMSC forwards the call to the CFU forward-to number. 31
32
N.S0028
Post Ballot Version 61
B.1.2.11 4.6.1.2 Call forwarding busy (CFB) 1
2 The following scenarios illustrate the call forwarding busy (CFB) information flows applicable to ANSI-3 41 foreign mode operation. 4
B.1.2.11.1 4.6.1.2.1 CFB registration 5
See 4.6.1.1.1 for the CFB registration information flows applicable to ANSI-41 foreign mode 6 operation, since they are the same as those for CFU. 7
B.1.2.11.2 4.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 mode 9 operation, since they are the same as those for CFU. 10
B.1.2.11.3 4.6.1.2.3 CFB activation 11
See 4.6.1.1.3 for the CFB activation information flows applicable to ANSI-41 foreign mode operation, 12 since they are the same as those for CFU. 13
B.1.2.11.4 4.6.1.2.4 CFB deactivation 14
See 4.6.1.1.4 for the CFB deactivation information flows applicable to ANSI-41 foreign mode 15 operation, since they are the same as those for CFU. 16
B.1.2.11.5 4.6.1.2.5 CFB Interrogation 17
While in ANSI-41 foreign mode, the GSM subscriber does not have the capability to interrogate the 18 CFB service. An attempt to perform such an operation shall result in an error response. 19
B.1.2.11.6 4.6.1.2.6 CFB invocation 20
The following scenarios illustrate the CFB invocation information flows applicable to ANSI-41 foreign 21 mode operation. 22
B.1.2.11.6.1 4.6.1.2.6.1 CFB invocation (Scenario 1a, “CFB#=MSRN method”) 23
In this scenario, the busy condition is detected by the ANSI-41 serving system when the 24 RoutingRequest Invoke message is received, and the IIF returns the CFB forward-to number (i.e., as 25 the MSRN) to the GSM HLR in the ProvideRoamingNumber Return Result message. 26
N.S0028
Post Ballot Version 62
i
h
g
GMSC HLR VMSC 2
a
b
c
d
e
GSM Home System
ANSI-136 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
1
Figure 40: CFB invocation (Scenario 1a, “CFB#=MSRN method”) 2
a. The GSM GMSC receives an incoming call for the subscriber. 3 4 b. The GMSC sends a SRI message to the HLR. 5 6 c. The HLR sends a PRN message to the current GSM serving system; i.e., the IIF. 7 8 d. The IIF sends a ROUTREQ message to the ANSI-41 serving system. 9 10 e. The serving system determines that the subscriber is busy. 11 12 f. Therefore, the serving system returns a routreq message, containing the AccessDeniedReason 13
parameter set to the value Busy. 14 15
The IIF determines that CFB is active for the subscriber. The IIF sends the subscriber’s CFB 16 forward-to number as the MSRN in the prn message. 17
18 g. NOTE: From the GSM HLR and GMSC’s perspectives, the call is routed to a MSRN; they are not 19
aware that the call is being forwarded. Therefore, there may be billing issues associated with this 20 handling. Another drawback is that it is not possible to provide the GSM notification of forwarding 21 to the calling party functionality. It is also critical that the GMSC have controls built in to limit the 22 potential for call looping (e.g., if two dual-mode roaming subscribers have forwarded their calls to 23 each other). 24
25 h. The GSM HLR returns an sri message containing the CFB forward-to number as the MSRN to 26
the GMSC. 27 28 i. The GMSC establishes a call to the CFB forward-to number. 29 30
31
N.S0028
Post Ballot Version 63
B.1.2.11.6.2 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 the 2 RoutingRequest Invoke message is received, and the IIF returns an AbsentSubscriber error code to 3 the 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-136 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
5
Figure 41: CFB invocation (Scenario 1b, “AbsentSubscriber method”) 6
7 a-f. Same as Section 4.6.1.2.6.1, steps a-f. 8 9 g. The IIF determines that CFB is active for the subscriber. The IIF sends the AbsentSubscriber 10
error code in a ProvideRoamingNumber Return Error message. 11 12
NOTE: This directs the GSM HLR to initiate CFNRc processing if this feature is active in the 13 subscriber’s profile. While this handling complies with the GSM MAP Version 2 standard and 14 avoids the potential problems of other approaches, it requires that the CFNRc feature be active 15 and does not allow different handling of busy versus not reachable conditions. 16
17 h. The GSM HLR returns an sri message, directing the GMSC to forward the call to the CFNRc 18
forward-to number. 19 20
i. The GMSC forwards the call to the CFB forward-to number. 21 22
23
N.S0028
Post Ballot Version 64
B.1.2.11.6.3 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 the 2 RoutingRequest Invoke message is received and while attempting to complete the call to the TLDN, 3 and 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-136 Serving System
ANSI-41GSM
IIF
6
Figure 42: CFB invocation (Scenario 2, without OR) 7
a. The GSM GMSC receives an incoming call for the subscriber. 8 9 b. The GMSC sends a SRI message to the HLR. 10 11 c. The HLR sends a PRN message to the current GSM serving system; i.e., the IIF. 12 13 d. The IIF sends a ROUTREQ message to the ANSI-41 serving system. Note that this message 14
shall contain the MSCID and PC_SSN parameters corresponding to the IIF. The serving system 15 may use this information to route any subsequent REDREQ message, as in step-j. 16
17
N.S0028
Post Ballot Version 65
e. The serving system determines that the subscriber is available; therefore, it returns a routreq 1 message, containing a routing number (called a temporary local directory number, or TLDN, in 2 ANSI-41) to the IIF. 3
4 f. The IIF responds to the GSM HLR with a prn message including the MSRN that it derives from 5
the TLDN; i.e., if the received TLDN is not in international format, then the IIF converts the TLDN 6 into international format for use as the MSRN by adding country code digit(s) associated with the 7 country of the serving system. 8
9 g. The GSM HLR returns an sri message containing the MSRN to the GMSC. 10 11 h. The GMSC establishes a call to the MSRN. 12 13 i. The serving system determines that the subscriber is busy. Note: If call waiting (CW) is active, the 14
serving system would normally invoke CW under these circumstances. 15 16 j. The serving system sends a REDREQ message to the IIF (e.g., using the routing information 17
provided in step-d), indicating that call redirection is requested due to a subscriber busy condition. 18 19 k. Since the IIF is not able to redirect the call (i.e., optimal routing is not possible), it rejects the 20
redirection request. 21 22 l. If the serving system is able to redirect the call, it sends a TRANUMREQ message to the IIF, 23
requesting the CFB forward-to number. Note that not all ANSI-41 systems have implemented this 24 redirection capability. Without this capability, the call shall fail, possibly with a tone or 25 announcement to the calling party. 26
27 m. The IIF determines that CFB is active for the subscriber. Therefore, the IIF responds with a 28
tranumreq message including the subscriber’s CFB forward-to number. 29 30 n. The serving system forwards the call to the CFB forward-to number. 31
B.1.2.11.6.4 4.6.1.2.6.4 CFB invocation (Scenario 2, with OR) 32
In this scenario, the busy condition is detected by the ANSI-41 serving system after the 33 RoutingRequest Invoke message is received and while attempting to complete the call to the TLDN, 34 and optimal routing is invoked. 35
This scenario is covered in Section 4.7.1. 36
37
N.S0028
Post Ballot Version 66
B.1.2.12 4.6.1.3 Call forwarding no reply (CFNRy) 1
The following scenarios illustrate the call forwarding no reply (CFNRy) information flows applicable to 2 ANSI-41 foreign mode operation. 3
B.1.2.12.1 4.6.1.3.1 CFNRy registration 4
See 4.6.1.1.1 for the CFNRy registration information flows applicable to ANSI-41 foreign mode 5 operation, since they are the same as those for CFU.
3 6
B.1.2.12.2 4.6.1.3.2 CFNRy deregistration (erasure) 7
See 4.6.1.1.2 for the CFNRy deregistration information flows applicable to ANSI-41 foreign mode 8 operation, since they are the same as those for CFU.3 9
B.1.2.12.3 4.6.1.3.3 CFNRy activation 10
See 4.6.1.1.3 for the CFNRy activation information flows applicable to ANSI-41 foreign mode 11 operation, since they are the same as those for CFU. 3 12
B.1.2.12.4 4.6.1.3.4 CFNRy deactivation 13
See 4.6.1.1.4 for the CFNRy deactivation information flows applicable to ANSI-41 foreign mode 14 operation, since they are the same as those for CFU. 3 15
B.1.2.12.5 4.6.1.3.5 CFNRy invocation 16
The following scenarios illustrate the CFNRy invocation information flows applicable to ANSI-41 17 foreign mode operation. 18
19
3 The ANSI-136 serving system may not directly support CFNRy registration or activation, but only support registration or activation of call forwarding no answer (CFNA). In this case, CFNA registration or activation shall result in the registration or activation of both CFNRy and call forwarding not reachable (CFNRc).
N.S0028
Post Ballot Version 67
B.1.2.12.5.1 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 attempting to 2 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-136 Serving System
ANSI-41GSM
IIF
4
Figure 43: CFNRy invocation (Scenario 1, without OR) 5
6
a-h. Same as Section 4.6.1.2.6.3, steps a-h. 7 8
i. The serving system determines that the subscriber does not answer the alert. 9 10 j. The serving system sends a REDREQ message to the IIF (e.g., using the routing 11
information provided in step-d), indicating that call redirection is requested due to a subscriber no 12 answer condition. 13
14 k. Since the IIF is not able to redirect the call (i.e., optimal routing is not possible), it rejects the 15
redirection request 16 17
N.S0028
Post Ballot Version 68
l. If the serving system is able to redirect the call, it sends a TRANUMREQ message to the IIF, 1 requesting the CFNA (i.e., GSM CFNRy) forward-to number. Note that not all ANSI-41 systems 2 have implemented this redirection capability. Without this capability, the call shall fail, possibly 3 with a tone or announcement to the calling party. 4
5 m. The IIF determines that CFNRy is active for the subscriber. Therefore, the IIF responds with a 6
tranumreq message including the subscriber’s CFNRy forward-to number. 7 8 n. The serving system forwards the call to the CFNRy forward-to number. 9
B.1.2.12.5.2 4.6.1.3.5.2. CFNRy invocation (Scenario 1, with OR) 10
In this scenario, the no reply condition is detected by the ANSI-41 serving system while attempting to 11 complete the call to the TLDN, and optimal routing is invoked. 12
This scenario is addressed in Section 4.7.1. 13
14
N.S0028
Post Ballot Version 69
B.1.2.13 4.6.1.4 Call forwarding not reachable (CFNRc) 1
The following scenarios illustrate the call forwarding not reachable (CFNRc) information flows 2 applicable to ANSI-41 foreign mode operation. 3
B.1.2.13.1 4.6.1.4.1 CFNRc registration 4
See 4.6.1.1.1 for the CFNRc registration information flows applicable to ANSI-41 foreign mode 5 operation.4 6
B.1.2.13.2 4.6.1.4.2 CFNRc deregistration (erasure) 7
See 4.6.1.1.2 for the CFNRc deregistration information flows applicable to ANSI-41 foreign mode 8
operation, since they are the same as those for CFU. 4 9
B.1.2.13.3 4.6.1.4.3 CFNRc activation 10
See 4.6.1.1.3 for the CFNRc activation information flows applicable to ANSI-41 foreign mode 11
operation, since they are the same as those for CFU. 4 12
B.1.2.13.4 4.6.1.4.4 CFNRc deactivation 13
See 4.6.1.1.4 for the CFNRc deactivation information flows applicable to ANSI-41 foreign mode 14
operation, since they are the same as those for CFU. 4 15
B.1.2.13.5 4.6.1.4.5 CFNRc invocation 16
The following scenarios illustrate the CFNRc invocation information flows applicable to ANSI-41 17 foreign mode operation. 18
19
20
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 this case, CFNA registration or activation shall result in the registration or activation of both CFNRc and CFNRy.
N.S0028
Post Ballot Version 70
B.1.2.13.5.1 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 serving 2 system when the RoutingRequest Invoke message is received. 3
i
h
g
GMSC HLR VMSC2
a
b
c
d
e
GSMHome
ANSI-136Serving
ROUTREQ
routreq [No response]
GSMGateway
PRN
SRI
sri [CFNRc #]
prn_RE[AbsentSubscriber]
f
forward call to CFNRc#
No responseto paging
incoming call
ANSI-41GSM
IIF
4
Figure 44: CFNRc invocation (Scenario 1) 5
a. The GSM GMSC receives an incoming call for the subscriber. 6 7 b. The GMSC sends a SRI message to the HLR. 8 9 c. The HLR sends a PRN message to the current GSM serving system (i.e., the IIF). 10 11 d. If the IIF determines that the called subscriber is not reachable, it returns an absent subscriber 12
error, otherwise, the IIF sends a ROUTREQ message to the ANSI-41 serving system. 13 14 e. The serving system determines that the subscriber is no reachable (e.g., does not respond to 15
paging). 16 17 f. Therefore, the serving system returns a routreq message, containing the AccessDeniedReason 18
parameter set to the value No Page Response. 19 20 g. The IIF determines that CFNRc is active for the subscriber. The IIF sends the AbsentSubscriber 21
error code in a ProvideRoamingNumber Return Error message. 22 23 h. The GSM HLR returns a sri message, directing the GMSC to forward the call to the CFNRc 24
forward-to number. 25 26 i. The GMSC forwards the call to the CFB forward-to number. 27
28
N.S0028
Post Ballot Version 71
B.1.2.13.5.2 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 the 2 RoutingRequest Invoke message is received and while attempting to complete the call to the TLDN, 3 and optimal routing is not invoked. 4
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 Page Response]
tranumreq [CFNRc #]
forward call to CFNRc #
No response to paging
incoming call
REDREQ [No Page Response, BillingID1]
ROUTREQ [BillingID1]
VMSC 2
ANSI-136 Serving System
ANSI-41GSM
IIF
5
Figure 45: CFNRc invocation (Scenario 2, without OR) 6
7
a-h. Same as Section 4.6.1.2.6.3, steps a-h. 8 9 i. The serving system determines that the mobile station does not respond to paging. 10 11 j. The serving system sends a REDREQ message to the IIF (e.g., using the routing information 12
provided in step d), indicating that call redirection is requested due to a subscriber no page 13 response condition. 14
15 k. Since the IIF is not able to redirect the call (i.e., optimal routing is not possible), it rejects the 16
redirection request. 17 18
N.S0028
Post Ballot Version 72
If the serving system is able to redirect the call, it sends a TRANUMREQ message to the IIF, 1 requesting the forward-to number appropriate for the no page response condition. Note that not 2 all ANSI-41 systems have implemented this redirection capability. Without this capability, the call 3 shall fail, possibly with a tone or announcement to the calling party. 4
5 l. The IIF determines that CFNRc is active for the subscriber. Therefore, the IIF responds with a 6
tranumreq message including the subscriber’s CFNRc forward-to number. 7 8 m. The serving system forwards the call to the CFNRc forward-to number. 9
B.1.2.13.5.3 4.6.1.4.5.3 CFNRc invocation (Scenario 2, with OR) 10
In this scenario, the not reachable condition is detected by the ANSI-41 serving system after the 11 RoutingRequest Invoke message is received and while attempting to complete the call to the TLDN, 12 and optimal routing is invoked. 13
This scenario is addressed in Section 4.7.1. 14
15
N.S0028
Post Ballot Version 73
B.1.3 4.6.2 Call forwarding scenarios for GSM foreign mode 1 The scenarios in this section illustrate the call forwarding information flows applicable to an ANSI-136 2 41 native subscriber roaming in a GSM network; i.e., GSM foreign mode. 3
B.1.3.1 4.6.2.1 Call forwarding unconditional (CFU) 4
The following scenarios illustrate the call forwarding unconditional (CFU) information flows applicable 5 to GSM foreign mode operation. 6
B.1.3.1.1 4.6.2.1.1 CFU registration 7
This scenario illustrates the CFU registration information flows applicable to GSM foreign mode 8 operation. 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
10
Figure 46: CFU registration 11
12
a. The GSM serving system receives an A_REG_SS message from the subscriber’s mobile station 13 (MS), indicating that the subscriber wishes to change his CFU forward-to number. 14
15 b. The serving system sends a REG_SS message to the IIF, constructed based on the information 16
received in the A_REG_SS message. 17 18
c. The IIF translates the information received in the REG_SS message into a corresponding digit 19 string (e.g., based on internal tables) and sends this string to the ANSI-41 HLR in a FEATREQ 20 message. 21
22 d. The HLR processes the request and returns a featreq message to the IIF, indicating operation 23
success. 24 25
e. The IIF sends a reg_ss message to the serving system, indicating a successful feature control 26 request. 27
28 f. The serving system sends a registration response message to the subscriber. 29 30
N.S0028
Post Ballot Version 74
Note: The process of registering the call forward number may also result in activation of the service. 1 This is based on HLR (i.e., carrier) determined policy. 2
B.1.3.1.2 4.6.2.1.2 CFU deregistration (erasure) 3
This scenario illustrates the CFU deregistration information flows applicable to GSM foreign mode 4 operation. 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
6
Figure 47: CFU deregistration (erasure) 7
a. The GSM serving system receives an A_ERASE_SS message from the subscriber’s mobile 8 station (MS), indicating that the subscriber wishes to deregister the CFU service. 9
10 b. The serving system sends an ERASE_SS message to the IIF, constructed based on the 11
information received in the A_ERASE_SS message. 12 13
c. The IIF translates the information received in the ERASE_SS message into a corresponding digit 14 string (e.g., based on internal tables) and sends this string to the ANSI-41 HLR in a FEATREQ 15 message. 16
17 d. The HLR processes the request and returns a featreq message to the IIF, indicating operation 18
success. 19 20
e. The IIF sends an erase_ss message to the serving system, indicating a successful feature control 21 request. 22
23 f. The serving system sends a deregistration response message to the subscriber. 24
25 Note: The process of deregistering the call forward service also results in deactivation of the service. 26
27
N.S0028
Post Ballot Version 75
B.1.3.1.3 4.6.2.1.3 CFU activation 1
This scenario illustrates the CFU activation information flows applicable to GSM foreign mode 2 operation. 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
4
Figure 48: CFU activation 5
a. The GSM serving system receives an A_ACT_SS message from the subscriber’s mobile station 6 (MS), indicating that the subscriber wishes to activate the CFU service. 7
8 b. The serving system sends an ACT_SS message to the IIF, constructed based on the information 9
received in the A_ACT_SS message. 10 11
c. The IIF translates the information received in the ACT_SS message into a corresponding digit 12 string (e.g., based on internal tables) and sends this string to the ANSI-41 HLR in a FEATREQ 13 message. 14
15 d. The HLR processes the request and returns a featreq message to the IIF, indicating operation 16
success. 17 18
e. The IIF sends an act_ss message to the serving system, indicating a successful feature control 19 request. 20
21 f. The serving system sends an activation response message to the subscriber. 22
B.1.3.1.4 4.6.2.1.4 CFU deactivation 23
24 This scenario illustrates the CFU deactivation information flows applicable to GSM foreign mode 25 operation. 26
27
N.S0028
Post Ballot Version 76
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
1
Figure 49: CFU deactivation 2
3
a. The GSM serving system receives an A_DEACT_SS message from the subscriber’s mobile 4 station (MS), indicating that the subscriber wishes to deactivate the CFU service. 5
6 b. The serving system sends a DEACT_SS message to the IIF, constructed based on the 7
information received in the A_DEACT_SS message. 8 9
c. The IIF translates the information received in the DEACT_SS message into a corresponding digit 10 string (e.g., based on internal tables) and sends this string to the ANSI-41 HLR in a FEATREQ 11 message. 12
13 d. The HLR processes the request and returns a featreq message to the IIF, indicating operation 14
success. 15 16
e. The IIF sends a deact_ss message to the serving system, indicating a successful feature control 17 request. 18
19 f. The serving system sends a deactivation response message to the subscriber. 20
21
N.S0028
Post Ballot Version 77
B.1.3.1.5 4.6.2.1.5 CFU invocation 1
This scenario illustrates the CFU invocation information flows applicable to GSM foreign mode 2 operation. 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
5
Figure 50: CFU invocation 6
a. The ANSI-41 originating MSC (OMSC) receives an incoming call for the subscriber. 7 8
b. The OMSC sends a LOCREQ message to the HLR. 9 10
c. The HLR determines that the subscriber has CFU registered and active; therefore, the HLR 11 responds with the subscriber’s CFU forward-to number in the locreq message. 12
13 d. The OMSC forwards the call to the CFU forward-to number. 14
15
N.S0028
Post Ballot Version 78
B.1.3.2 4.6.2.2 Call forwarding busy (CFB) 1
The following scenarios illustrate the call forwarding busy (CFB) information flows applicable to GSM 2 foreign mode operation. 3
Since the ANSI-41 HLR does not provide the CFB forward-to number to the serving system until the 4 feature is actually invoked—versus the GSM method, whereby the HLR provides the forward-to 5 number(s) to the serving system as part of the subscriber’s profile information at registration time—6 the IIF shall use the ANSI-41 TransferToNumberRequest operation to obtain the CFB forward-to 7 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
9
Figure 51: Obtaining forward-to numbers 10
a. The subscriber registers on a GSM serving system using the normal registration signaling 11 process. 12
13 b. If the subscriber’s ANSI-41 profile indicates that CFB is authorized and active, and the IIF 14
determines that it does may not have the current CFB forward-to number, then the IIF sends a 15 TRANUMREQ message to the HLR requesting the CFB forward-to number. 16
17 c. The HLR responds with the CFB forward-to number in the tranumreq message. 18
19 d. If the subscriber’s ANSI-41 profile indicates that CFNA is authorized and active, and the IIF 20
determines that it does may not have the current CFNA forward-to number, then the IIF sends a 21 TRANUMREQ message to the HLR requesting the CFNA forward-to number. 22
23 e. The HLR responds with the CFNA forward-to number in the tranumreq message. 24 25 f-h. If the CFB forward-to number or CFNA forward-to number, or both numbers do not correspond 26
with the numbers previously provided to the GSM serving system, then the IIF sends the modified 27 information to the GSM serving system using the InsertSubscriberData operation. The CFNA 28 forward-to number shall be populated as both the CFNRc and CFNRy forward-to numbers. 29
N.S0028
Post Ballot Version 79
B.1.3.2.1 4.6.2.2.1 CFB registration 1
This scenario illustrates the CFB registration information flows applicable to GSM foreign mode 2 operation. 3
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
4
Figure 52: CFB registration 5
a. The GSM serving system receives an A_REG_SS message from the subscriber’s mobile station 6 (MS), indicating that the subscriber wishes to change his call forwarding number. 7
8 b. The serving system sends a REG_SS message to the IIF, constructed based on the information 9
received in the A_REG_SS message. 10 11
c. The IIF translates the information received in the REG_SS message into a corresponding digit 12 string (e.g., based on internal tables) and sends this string to the ANSI-41 HLR in a FEATREQ 13 message. 14
15 d. The HLR processes the request and returns a featreq message to the IIF, indicating operation 16
success. 17 18
e. The IIF sends a reg_ss message to the serving system, indicating a successful feature control 19 request. 20
21
N.S0028
Post Ballot Version 80
f. The serving system sends a registration response message to the subscriber. 1 2 g-h. If the subscriber’s ANSI-41 profile changes as a result of the operation (e.g., the service was 3
previously authorized, but not activated), the HLR sends a QUALDIR message to the IIF, 4 containing the new profile information. 5 6
i. If the IIF determines that the subscriber’s call forwarding number may have changed, it sends a 7 TRANUMREQ message to the HLR to request the new number. 8
9 j. The HLR responds with the subscriber’s call forwarding number in the tranumreq message. 10
11 k-m. If the subscriber’s GSM profile has changed as a result of these operations, then the IIF sends 12
the modified profile information to the serving system via an InsertSubscriberData message 13 exchange. 14 15
Note: The process of registering the call forwarding number may also result in activation of the 16 service. This is based on HLR (i.e., carrier) determined policy. 17
18
N.S0028
Post Ballot Version 81
B.1.3.2.2 4.6.2.2.2 CFB deregistration (erasure) 1
This scenario illustrates the CFB deregistration information flows applicable to GSM foreign mode 2 operation. 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
4
Figure 53: CFB deregistration (erasure) 5
6
a. The GSM serving system receives an A_ERASE_SS message from the subscriber’s mobile 7 station (MS), indicating that the subscriber wishes to deregister the call forward service. 8
9 b. The serving system sends an ERASE_SS message to the IIF, constructed based on the 10
information received in the A_ERASE_SS message. 11 12
c. The IIF translates the information received in the ERASE_SS message into a corresponding digit 13 string (e.g., based on internal tables) and sends this string to the ANSI-41 HLR in a FEATREQ 14 message. 15
16 d. The HLR processes the request and returns a featreq message to the IIF, indicating operation 17
success. 18 19
e. The IIF sends an erase_ss message to the serving system, indicating a successful feature control 20 request. 21
22 f. The serving system sends a deregistration response message to the subscriber. 23 24
N.S0028
Post Ballot Version 82
g-h. If the subscriber’s ANSI-41 profile changes as a result of the operation (e.g., the service was 1 previously authorized and activated), the HLR sends a QUALDIR message to the IIF, containing 2 the new profile information. 3
4 i-k. If the subscriber’s GSM profile has changed as a result of these operations, then the IIF sends 5
the modified profile information to the serving system via an InsertSubscriberData message 6 exchange. 7
8 Note: The process of deregistering the call forwarding service also results in deactivation of the 9 service. 10
11
B.1.3.2.3 4.6.2.2.3 CFB activation 12
This scenario illustrates the CFB activation information flows applicable to GSM foreign mode 13 operation. 14
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
15
Figure 54: CFB activation 16
17
a. The GSM serving system receives an A_ACT_SS message from the subscriber’s mobile station 18 (MS), indicating that the subscriber wishes to activate the call forward service. 19
20 b. The serving system sends an ACT_SS message to the IIF, constructed based on the information 21
received in the A_ACT_SS message. 22 23
N.S0028
Post Ballot Version 83
c. The IIF translates the information received in the ACT_SS message into a corresponding digit 1 string (e.g., based on internal tables) and sends this string to the ANSI-41 HLR in a FEATREQ 2 message. 3
4 d. The HLR processes the request and returns a featreq message to the IIF, indicating operation 5
success. 6 7
e. The IIF sends an act_ss message to the serving system, indicating a successful feature control 8 request. 9
10 f. The serving system sends an activation response message to the subscriber. 11
12 g-h. If the subscriber’s ANSI-41 profile changes as a result of the operation (e.g., the service was 13
previously authorized but not active), the HLR sends a QUALDIR message to the IIF, containing 14 the new profile information. 15
16 i-k. If the subscriber’s GSM profile has changed as a result of these operations, then the IIF sends 17
the modified profile information to the serving system via an InsertSubscriberData message 18 exchange. 19
B.1.3.2.4 4.6.2.2.4 CFB deactivation 20
This scenario illustrates the CFB deactivation information flows applicable to GSM foreign mode 21 operation. 22
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
23
Figure 55: CFB deactivation 24
N.S0028
Post Ballot Version 84
1
a. The GSM serving system receives an A_DEACT_SS message from the subscriber’s mobile 2 station (MS), indicating that the subscriber wishes to deactivate the call forward service. 3
4 b. The serving system sends a DEACT_SS message to the IIF, constructed based on the 5
information received in the A_DEACT_SS message. 6 7
c. The IIF translates the information received in the DEACT_SS message into a corresponding digit 8 string (e.g., based on internal tables) and sends this string to the ANSI-41 HLR in a FEATREQ 9 message. 10
11 d. The HLR processes the request and returns a featreq message to the IIF, indicating operation 12
success. 13 14
e. The IIF sends a deact_ss message to the serving system, indicating a successful feature control 15 request. 16
17 f. The serving system sends a deactivation response message to the subscriber. 18
19 g-h. If the subscriber’s ANSI-41 profile changes as a result of the operation (e.g., the service was 20
previously authorized and active), the HLR sends a QUALDIR message to the IIF, containing the 21 new profile information. 22
23 i-k. If the subscriber’s GSM profile has changed as a result of these operations, then the IIF sends 24
the modified profile information to the serving system via an InsertSubscriberData message 25 exchange. 26
B.1.3.2.5 4.6.2.2.5 CFB invocation 27
The following scenarios illustrate the CFB invocation information flows applicable to GSM foreign 28 mode operation. 29
30
N.S0028
Post Ballot Version 85
B.1.3.2.5.1 4.6.2.2.5.1 CFB invocation (without OR) 1
In this scenario, the busy condition is detected by the GSM serving system while attempting to 2 complete the call to the TLDN, and optimal routing is not invoked. 3
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
4
Figure 56: CFB invocation (without OR) 5
a. The ANSI-41 originating MSC (OMSC) receives an incoming call for the subscriber. 6 7
b. The OMSC sends a LOCREQ message to the HLR. 8 9
c. The HLR sends a ROUTREQ message to the current serving system; i.e., the IIF. 10 11
d. The IIF sends a PRN message to the GSM serving system. 12 13
e. The serving system returns a prn message, containing a routing number (called a mobile station 14 roaming number, or MSRN, in GSM) to the IIF. 15
16 f. The IIF responds to the HLR with a routreq message including the TLDN that it derives from the 17
MSRN. Note that the TLDN is typically in international format. 18 19
g. The HLR returns a locreq message containing the TLDN to the OMSC. 20 21
h. The OMSC establishes a call to the TLDN. 22 23
i-j. The serving system determines that the subscriber is busy and forwards the call to the CFB 24 forward-to number. 25
26
N.S0028
Post Ballot Version 86
B.1.3.2.5.2 4.6.2.2.5.2 CFB invocation (with OR) 1
In this scenario, the busy condition is detected by the GSM serving system while attempting to 2 complete the call to the TLDN, and optimal routing is invoked. 3
This scenario is addressed in Section 4.7.2. 4
B.1.3.3 4.6.2.3 Call forwarding no answer (CFNA) 5
The following scenarios illustrate the call forwarding no answer (CFNA) information flows applicable 6 to GSM foreign mode operation. 7
Since the ANSI-41 HLR does not provide the CFNA forward-to number to the serving system until the 8 feature is actually invoked—versus the GSM method, whereby the HLR provides the forward-to 9 number(s) to the serving system as part of the subscriber’s profile information at registration time—10 the IIF shall use the ANSI-41 TransferToNumberRequest operation to obtain the CFNA forward-to 11 number. This is illustrated in Figure 51 and described in Section 4.6.2.2. 12
Note that ANSI-41, unlike GSM, does not distinguish the “not reachable” condition from the “no reply” 13 condition. Therefore, if ANSI-41 CFNA is activated, then both of the GSM CFNRy and CFNRc 14 services shall be considered activated. 15
B.1.3.3.1 4.6.2.3.1 CFNA registration 16
See 4.6.2.2.1 for the CFNA registration information flows applicable to GSM foreign mode operation, 17 since they are the same as those for CFB. Both CFNRy and CFNRc shall be registered in the IIF and 18 GSM VLR. 19
B.1.3.3.2 4.6.2.3.2 CFNA deregistration (erasure) 20
See 4.6.2.2.2 for the CFNA deregistration information flows applicable to GSM foreign mode 21 operation, since they are the same as those for CFB. Both CFNRy and CFNRc shall be deregistered 22 in the IIF and GSM VLR. 23
B.1.3.3.3 4.6.2.3.3 CFNA activation 24
See 4.6.2.2.3 for the CFNA activation information flows applicable to GSM foreign mode operation, 25 since they are the same as those for CFB. Both CFNRy and CFNRc shall be activated in the IIF and 26 GSM VLR. 27
B.1.3.3.4 4.6.2.3.4 CFNA deactivation 28
See 4.6.2.2.4 for the CFNA deactivation information flows applicable to GSM foreign mode operation, 29 since they are the same as those for CFB. Both CFNRy and CFNRc shall be deactivated in the IIF 30 and GSM VLR. 31
B.1.3.3.5 4.6.2.3.5 CFNA invocation 32
The following scenarios illustrate the CFNA invocation information flows applicable to GSM foreign 33 mode operation. 34
B.1.3.3.5.1 4.6.2.3.5.1 CFNA invocation (Scenario 1, without OR) 35
In this scenario, the no reply condition is detected by the GSM serving system while attempting to 36 complete the call to the TLDN, and optimal routing is not invoked. 37
N.S0028
Post Ballot Version 87
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
1
Figure 57: CFNA invocation (Scenario 1, without OR) 2
a-h. Same as Section 4.6.2.2.5.1, steps a-h. 3 4 i-j. The serving system determines that the subscriber does not answer the alert and forwards the 5
call to the CFNRy forward-to number. 6 7
B.1.3.3.5.2 4.6.2.3.5.2 CFNA invocation (Scenario 1, with OR) 8
In this scenario, the no reply condition is detected by the GSM serving system while attempting to 9 complete the call to the TLDN, and optimal routing is invoked. 10 11 This scenario is addressed in Section 4.7.2. 12
13
N.S0028
Post Ballot Version 88
4.7 Optimal Routing for Late Call Forwarding 1
The following scenarios cover the interoperability to support Optimal Routing for Late Call 2 Forwarding. The signaling is based on ANSI-41 Rev. D [1] and GSM 9.02 [6]. 3
From GSM 02.79 [8] and GSM 03.79 [9], Late Call Forwarding is Call Forwarding performed after the 4 call has been extended to the Visited PLMN (VPLMN) of the forwarding subscriber (i.e., Conditional 5 Call Forwarding on Busy, Conditional Call Forwarding on No Reply, and Conditional Call Forwarding 6 on Not Reachable detected in the VPLMN of the forwarding subscriber). Late Call Forwarding may be 7 invoked in the Interrogating PLMN (IPLMN) or in the VPLMN of the forwarding subscriber. 8
Assumptions: 9
1) The Subscriber has forwarding enabled. 10
2) Optimal Routing is enabled. 11
The following scenarios address the case where the forwarding attempt is done by the IPLMN. 12
4.7.1 ANSI-41 Foreign Mode 13
B.1.3.4 4.7.1.1 ANSI-41 Foreign Mode - Success condition 14
Scenario: GSM Subscriber A makes a call origination attempt at GMSC-A to a GSM Subscriber B 15 who is roaming and registered in an ANSI-41 network at MSC-B. Subscriber B has call forwarding set 16 to an address at MSC-C. 17
18
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
19
Figure 58: Optimal Routing with Late Call Forwarding (ANSI-41 Foreign Mode) Success Case 20
21
N.S0028
Post Ballot Version 89
a. GSM GMSC-A receives a call origination stimulus from Subscriber A. 1 2
b. If GMSC-A recognizes subscriber B's address as belonging to a GSM PLMN, it checks the 3 identity of HPLMN-B and shall follow the following procedures: 4
5 (i) If GMSC-A is in the same PLMN as the HLR-B, GMSC-A sends a request for routing 6 information to Subscriber B's HLR. This GSM-SRI request contains: 7
8 - an indication of the phase of optimal routing supported by the GMSC-A; 9 10 - the E-164 address of GMSC-A; 11 12 - the Call Reference Number. 13 14 (ii) If GMSC-A is in a different PLMN from HLR-B, it sends a request for routing information to 15 Subscriber B's HLR. This GSM-SRI request contains all parameters as in item (i) above as well 16 as an indication that it is an optimal routing inquiry (OR interrogation indicator). 17
18 19
c. Subscriber B's GSM HLR determines that Subscriber B is roaming at MSC-B and sends a GSM-20 Provide Roaming Number message, which also contains the GMSC address, the Call Reference 21 Number and the OR interrogation indicator if it was received in the GSM-SRI to an IIF acting on 22 behalf of MSC-B to get a roaming number. The E-164 address of GMSC-A shall be provided in 23 the message, as specified in GSM 03.79. 24 25
d. The IIF relays this request to the ANSI-41 MSC/VLR-B by sending an ANSI-41-Routing Request 26 message. The originating address in this message is provided as a routing address back to the 27 IIF. 28 29
e. The ANSI-41 MSC/VLR-B acknowledges the ANSI-41-Routing Request message with the 30 Temporary Local Directory Number (TLDN). 31 32
f. Upon receipt of the ANSI-41-Routing Request message, the IIF sends an MSRN to Subscriber 33 B's GSM HLR in the GSM-Provide Roaming Number Acknowledgment message. 34 35
g. Subscriber B's GSM HLR relays this information to GMSC-A using the GSM-Send Routing 36 Information Acknowledgment message. This message includes MSRN and optionally a 37 ForwardedInterrogationRequired (FIR) parameter, which indicates whether the GMSC-A shall 38 interrogate the HLR for routing information for late call forwarding. 39
40 h. GMSC-A starts a call setup procedure using the MSRN (TLDN) as Subscriber B's called address 41
at ANSI-41 MSC/VLR-B). 42 43
i. The incoming call at ANSI-41 MSC/VLR-B can not be terminated because of reasons such as No 44 Answer, No Page Response, or Unavailable. An ANSI-41-Redirection Request message with a 45 RedirectionReason parameter is then sent to the IIF based on the originating address received in 46 the ANSI-41-Route Request message at step d. 47
48 j. The IIF sends GSM-Resume Call Handling message to GMSC-A based on the GMSC-A address 49
received in the GSM-Provide Roaming Number. Note that the GSM-Resume Call Handling 50 includes the same Call Reference Number received in the GSM-Provide Roaming Number, the 51 cause for termination failure (forwarding reason) and the forwarding number at MSC-C plus all 52 necessary parameters required for call forwarding. 53 54
k. If the ForwardedInterrogationRequired parameter was received from Subscriber B's GSM HLR in 55 the GSM-Send Routing Information Acknowledgement message at step g, , GMSC-A sends a 56
N.S0028
Post Ballot Version 90
GSM-Send Routing Information message to Subscriber B's GSM HLR requesting it to send a call 1 forwarding information. 2
3 Otherwise, it is assumed that all forwarding information is ready available at GMSC-A and an 4 acknowledgment of the GSM-Resume Call Handling message is sent to the IIF (step m). 5
6 l. If a corresponding forwarded-to number is available at subscriber B's GSM HLR, GMSC-A 7
receives a GSM-Send Routing Information Acknowledge message with the necessary forwarding 8 information. 9
10 In case of an error, a GSM-Send Routing Information Error message is sent to GMSC-A and 11 GMSC-A uses the forwarding information from step j. 12
13 m. GMSC-A sends an acknowledgment of the GSM-Resume Call Handling message. 14 15 n. Upon receipt of GSM-Resume Call Handling Acknowledgment message, the IIF acknowledges 16
the ANSI-41-Redirection Request message. 17 18
In case of an error, the IIF rejects the redirection request and the ANSI-MSC-B initiates a call 19 forwarding procedure extend the call to MSC-C. See Section 6.2. 20
21 o. If step n is successful, GMSC-A releases all circuit-associated resources specific to ANSI-41 22
MSC/VLR-B. 23 24 p. GMSC-A starts a call setup procedure using the call forwarded-to number as Subscriber B’s 25
address at ANSI-41 MSC-C. 26 27
28
N.S0028
Post Ballot Version 91
B.1.3.5 4.7.1.2 ANSI-41 Foreign Mode - Failure condition 1
Scenario: GSM Subscriber A makes a call origination attempt at GMSC-A to GSM Subscriber B 2 roaming and registered in an ANSI-41 network at MSC-B. Subscriber B has call forwarding set to an 3 address 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]
5
Figure 59: Optimal Routing with Late Call Forwarding (ANSI-41 Foreign Mode) Failure Case 6
a.-l.These steps are the same as the success case. 7 8
m. If GMSC-A determines that it cannot forward the call via an optimal route, it returns a Resume 9 Call Handling error to the IIF. 10
11 n. The redirection request at step i. is rejected. 12 13 o. The ANSI-41 MSC/VLR-B sends an ANSI-41 TransferToNumberRequest message to the IIF with 14
the RedirectionReason parameter. 15 16 p. The IIF returns the ANSI-41 TransferToNumberResponse message to the ANSI-41 MSC/VLR-B 17
with the forward-to number in the TerminationList parameter along with an indication of the 18 reason (DMH_RedirectionIndicator) for extending the incoming call. 19 20
q. The ANSI-41 MSC/VLR-B forwards the incoming call to MSC-C. 21 22
N.S0028
Post Ballot Version 92
4.7.2 GSM Foreign Mode 1
B.1.3.6 4.7.2.1 GSM Foreign Mode - Success Case 2
Scenario: ANSI-41 Subscriber A makes a call origination attempt at ANSI-41 MSC-A to ANSI-41 3 Subscriber B roaming and registered in a GSM network at MSC-B. Subscriber B has call forwarding 4 set 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
6
Figure 60: Optimal Routing with Late Call Forwarding (GSM Foreign Mode) Success Case 7
a. ANSI-41 MSC-A receives a call origination stimulus from Subscriber A. 8 9
b. The ANSI-41 MSC-A sends an ANSI-41-Location Request message for routing information to 10 Subscriber B's ANSI-41 HLR with the MSCID address of the originating MSC (ANSI-41 MSC-A). 11 12
c. Subscriber B's ANSI-41 HLR determines that Subscriber B is roaming at MSC-B and sends a 13 ANSI-41-Routing Request message number with the MSCID address of the ANSI-41 MSC-A 14 received in step b. to an IIF acting on behalf of MSC-B to get a roaming number. 15 16
d. The IIF relays this request to GSM MSC/VLR-B by sending a GSM-Provide Roaming Number 17 message. The IIF generates two parameters: the Call Reference number (for the VLR/MSC-B to 18 use in the GSM-RCH) and the GMSC address set to the IIF address, to indicate that the IIF is 19 capable of supporting optimal routing for late call forwarding. 20 21
e. GSM MSC/VLR-B acknowledges the GSM - Provide Roaming Number message with the Mobile 22 Subscriber Roaming Number (MSRN). 23
24 f. Upon receipt of this message, the IIF sends the TLDN to Subscriber B's ANSI-41 HLR in the 25
ANSI-41-Routing Request message. 26
N.S0028
Post Ballot Version 93
1 g. Subscriber B's ANSI-41 HLR relays this information to ANSI-41 MSC-A via the ANSI-41-Location 2
Request (Acknowledgment) message. 3 4 h. ANSI-41 MSC starts a call setup procedure using TLDN (MSRN) as Subscriber B's called 5
address at GSM MSC/VLR-B. The incoming call can not be terminated at GSM MSC/VLR-B 6 because of reasons such as Busy, Not Reachable, or No Reply. 7 8
i. Since the GMSC address and the Call Reference Number parameters were present in the 9 GSM-Provide Roaming Number message the GSM MSC-B sends a GSM-Resume Call Handling 10 message to the IIF with the received Call Reference number and all necessary information 11 required for call forwarding. 12
13 If optimal routing is not supported the call is forwarded by GSM MSC-B using the forwarding 14 information available. 15
16 j. When optimal routing is supported and the IIF receives the GSM-Resume Call Handling 17
message, the IIF sends an ANSI-41-Redirecion Request message with the Redirection Reason to 18 the ANSI-41 MSC-A supporting subscriber A's call origination attempt. 19
20 k. The ANSI-41 MSC-A passes this Redirection Reason to the Subscriber B's ANSI-41 HLR in the 21
ANSI-41-Transfer To Number message to get call forwarding number information. 22 23 l. Based on the Redirection Reason, the ANSI-41 HLR returns the corresponding forwarded-to 24
number to ANSI-41 MSC/VLR-A. 25 26 m. If ANSI-41 MSC-A received forwarded-to number from ANSI-41 HLR, it sends 27
ANSI-41-Redirection Request (Acknowledgment) message to the IIF. 28 29 In case of an error, ANSI-41 MSC-A rejects the redirection request. The IIF then returns a 30 GSM-Resume Call Handling Error message to GSM MSC-B, which then attempts to forward the 31 call to MSC-C using the forwarding information available. 32
33 n. Upon receiving the ANSI-41-Redirection Request (Acknowledgment) in step m., the IIF sends a 34
GSM-Resume Call Handling Acknowledgment message to GSM MSC-B. 35 36 o. The ANSI-41 MSC-A releases all circuit-associated resources specific to GSM MSC/VLR-B. 37
38 p. The ANSI-41 MSC-A starts a call setup procedure using the call forwarded-to number as 39
Subscriber B's address at MSC-C. 40 41
N.S0028
Post Ballot Version 94
B.1.3.7 4.7.2.2 GSM Foreign Mode - Failure case 1
Scenario: ANSI-41 Subscriber A makes a call origination attempt at ANSI-41 MSC-A to ANSI-41 2 Subscriber B roaming and registered in a GSM network at MSC-B. Subscriber B has call forwarding 3 set to an address at MSC-C. Optimal Routing fails at IPLMN. Subscriber B is not IMSI detached. 4
5 ANSI-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
6
Figure 61: Optimal Routing with Late Call Forwarding (GSM Foreign Mode) Failure Case 7
a.-l.These steps are the same as the Success Case. 8 9
m. The redirection request at step j. is rejected. 10 11 n. The IIF sends a GSM-Resume Call Handling Error message to GSM MSC-B. 12
13 o. The GSM MSC-B forwards the incoming call to MSC-C. 14
15
N.S0028
Post Ballot Version 95
4.8 Call Waiting 1
This section depicts the interactions between network entities in various situations related to GSM 2 and ANSI-41 foreign mode operation and Call Waiting (CW). 3
4.8.1 Call Waiting Activation 4
B.1.3.8 4.8.1.1 ANSI-41 Foreign Mode Successful Call Waiting Activation 5
This scenario describes a successful call waiting activation by a native GSM subscriber roaming in an 6 ANSI-41 network. 7
d
i
FEATREQ [DGTSDIAL]
featreq [FEATRESULT, ANNLIST]
*FC [SEND]
MS MSC/VLR
IIF
a
b
c
e
f
g
Serving System
h
QUALDIR
qualdir
feature confirmation
call release
GSMHLR
ActivateSS
ActivateSS Ack
Insert Subscriber Data
ISD Ack
k
j
8
Figure 62: ANSI-41 Foreign Mode Call Waiting Activation 9
a. The subscriber requests activation of call waiting. The MS converts the user-entered MMI/menu 10 selections to feature codes. (e.g. *FC). The MS sends this feature code string to the Serving 11 MSC. 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 emulating the 13 HLR associated with the MS. 14
N.S0028
Post Ballot Version 96
c. The IIF determines the digit string pertains to the activation of call waiting and then sends an 1 Activate SS message to the HLR to request activation of call waiting. 5 2
d. The HLR returns an Activate SS Ack message to the IIF indicating a successful activation of call 3 waiting. 4
e. The IIF sends a featreq to the Serving MSC containing the feature request confirmation 5 indication. 6
f. When the featreq is received from the IIF, the Serving MSC provides treatment to the served MS 7 based on the information contained in the response. In this case, the treatment is to apply feature 8 confirmation. 9
g. The Serving MSC releases the call. 10
h. Because the request resulted in a change to the subscriber’s service profile (i.e., the call waiting 11 feature was activated), the HLR reports the change by sending an Insert Subscriber Data 12 message to the IIF emulating the Serving MSC/VLR. 13
i. The IIF returns an Insert Subscriber Data Ack message to the HLR. 14
j. The IIF sends a QUALDIR message to the Serving MSC/VLR. 15
k. The Serving MSC/VLR returns a qualdir to the IIF. 16
B.1.3.9 4.8.1.2 ANSI-41 Foreign Mode Unsuccessful Call Waiting Activation 17
The following scenario describes an unsuccessful call waiting activation by a native GSM subscriber 18 roaming in an ANSI-41 network. 19
20
5 Most likely, the GSM 02.30 standardized MMI would be mapped to the equivalent GSM functional message.
N.S0028
Post Ballot Version 97
d
FEATREQ [DGTSDIAL]
featreq [FEATRESULT, ANNLIST]
*FC [SEND]
MS MSC/VLR
IIF
a
b
c
e
f
g
Serving System
feature confirmation
call release
GSMHLR
ActivateSS
ActivateSS Ack [User error]
1
Figure 63: ANSI-41 Foreign Mode Unsuccessful Call Waiting Activation 2
a. The subscriber requests activation of call waiting. The MS converts the user-entered MMI/menu 3 selections to feature codes. (e.g. *FC). The MS sends this feature code string to the Serving 4 MSC. During analysis of the digit string, the Serving MSC detects a feature code string. 5
b. The digit string is included in a FEATREQ and sent from the Serving MSC to the IIF emulating the 6 HLR associated with the MS. 7
c. The IIF determines the digit string pertains to the activation of call waiting and then sends an 8 Activate SS message to the HLR to request activation of call waiting. 6 9
d. The HLR returns an Activate SS Ack message to the IIF indicating an unsuccessful activation of 10 call waiting. 11
e. The IIF sends a featreq to the Serving MSC containing a Feature Result parameter set to 12 “Unsuccessful”. In addition, it may include an AnnouncementList code that corresponds to the 13 User error parameter included in the Activate SS Ack message sent by the GSM HLR. 14
f. When the featreq is received from the IIF, the Serving MSC provides treatment to the served MS 15 based on the information contained in the response. 16
g. The Serving MSC sends a Release message to the MS. 17
18
19
6 Most likely, the GSM 02.30 standardized MMI would be mapped to the equivalent GSM functional message.
N.S0028
Post Ballot Version 98
B.1.3.10 4.8.1.3 GSM Foreign Mode Feature Activation 1
This scenario describes a successful call waiting activation by a native ANSI-136 41 subscriber 2 roaming in a GSM network. 3
d
i
FEATREQ [DGTSDIAL]
featreq [FEATRESULT, ANNLIST]
MSGSMMSC/VLR
IIF
a
b
c
e
f
g
h
QUALDIR
qualdir
Activate SS Ack
HLR
Activate SS
Activate SS Ack
Insert Subscriber Data
ISD Ack
j
Activate SS
4
Figure 64: GSM Foreign Mode Call Waiting Activation 5
a. The subscriber requests activation of call waiting. The MS interprets the user-entered 6 MMI/menu selections. The MS sends a request for activation of call waiting (by issuing an 7 Activate SS operation). 8
b. The Serving GSM MSC sends an Activate SS message to the IIF emulating the HLR 9 associated with the subscriber. The message specifies the call waiting supplementary service 10 for the activation being requested. 11
c. The IIF converts the call waiting Activate SS message to a particular feature code (e.g. *FC). 12 The IIF includes this feature code (including *) in the Digits (Dialed) parameter of a 13 FEATREQ 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. 15
e. The IIF returns an Activate SS Ack message back to the Serving GSM MSC. Any parameters 16 the HLR may have included that provide instructions for treatment towards the user (such as 17 AnnouncementList) shall be ignored by the IIF and not mapped into the message sent to the 18 Serving GSM MSC. 19
f. When the Activate SS Ack message is received from the IIF, the Serving GSM MSC sends a 20 message to the MS to indicate that the call waiting activation had been successful. 21
N.S0028
Post Ballot Version 99
g. Because the request resulted in a change to the subscriber’s service profile (i.e., the call 1 waiting feature was activated), the HLR reports the change by sending a QUALDIR message 2 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. 4
i. The Serving GSM MSC/VLR returns an Insert Subscriber Data Ack to the IIF. 5
j. The IIF returns a qualdir message to the HLR. 6
Note that the GSM foreign mode unsuccessful call waiting activation case parallels the ANSI-41 7 foreign mode unsuccessful call waiting activation case shown in the previous section. 8
4.8.2 Call Waiting Deactivation 9
B.1.3.11 4.8.2.1 ANSI-41 Foreign Mode Call Waiting Deactivation 10
This scenario describes a successful call waiting deactivation by a native GSM subscriber roaming in 11 an ANSI-41 network. 12
13
N.S0028
Post Ballot Version 100
d
i
FEATREQ [DGTSDIAL]
featreq [FEATRESULT, ANNLIST]
*FC0 [SEND]
MS MSC/VLR
IIF
a
b
c
e
f
g
ANSI-136 Serving System
h
QUALDIR
qualdir
feature confirmation
call release
GSMHLR
DeactivateSS
DeactivateSS Ack
Insert Subscriber Data
ISD Ack
k
j
1
Figure 65: ANSI-41 Foreign Mode Call Waiting Deactivation 2
a. The subscriber selects a menu entry in order to deactivate call waiting. The MS converts the 3 user-entered MMI/menu selections to feature codes. (e.g. *FC0). The MS sends this digit string 4 towards the network. The digit string is received by the Serving MSC. During analysis of the digit 5 string, the Serving MSC detects a feature code string. 6
b. The dialed digits are included in a FEATREQ and sent from the Serving MSC to the IIF emulating 7 the HLR associated with the MS. 8
c. The IIF determines the digit string pertains to the deactivation of call waiting and then sends a 9 Deactivate SS message to the HLR to request deactivation of call waiting. 7 10
d. The HLR returns a Deactivate SS Ack message to the IIF indicating a successful deactivation of 11 call waiting. 12
7 Most likely, the GSM 02.30 standardized MMI would be mapped to the equivalent GSM functional message.
N.S0028
Post Ballot Version 101
e. The IIF sends a featreq to the Serving MSC containing the feature request confirmation 1 indication. 2
f. When the featreq is received from the IIF, the Serving MSC provides treatment to the served MS 3 based on the information contained in the response. In this case, the treatment is to apply feature 4 confirmation. 5
g. The Serving MSC releases the call. 6
h. Because the request resulted in a change to the subscriber’s service profile (i.e., the call waiting 7 feature was deactivated), the HLR reports the change by sending an Insert Subscriber Data 8 message to the IIF emulating the Serving MSC/VLR. 9
i. The IIF returns an Insert Subscriber Data Ack message to the HLR. 10
j. The IIF sends a QUALDIR message to the Serving MSC/VLR. 11
k. The Serving MSC/VLR returns a qualdir to the IIF. 12
B.1.3.12 4.8.2.2 GSM Foreign Mode Feature Deactivation 13
This scenario describes a successful call waiting deactivation by a native ANSI-136 41 subscriber 14 roaming in a GSM network. 15
16
N.S0028
Post Ballot Version 102
d
i
FEATREQ [DGTSDIAL]
featreq [FEATRESULT, ANNLIST]
MS GSMMSC/VLR
IIF
a
b
c
e
f
g
GSM Serving System
h
QUALDIR
qualdir
Deactivate SS Ack
HLR
Deactivate SS
Deactivate SS Ack
Insert Subscriber Data
ISD Ack
j
Deactivate SS
1
Figure 66: GSM Foreign Mode Call Waiting Deactivation 2
a. The subscriber requests activation of call waiting. The MS associates the MMI/menu selection 3 provided by the subscriber with a request to deactivate call waiting. The MS sends a request for 4 deactivation of call waiting (by issuing a Deactivate SS operation). 5
b. The Serving GSM MSC sends a Deactivate SS message to the IIF emulating the HLR associated 6 with the subscriber. The message specifies the call waiting supplementary service for the 7 deactivation being requested. 8
c. The IIF converts the call waiting Deactivate SS message to a particular digit string (e.g. *FC0). 9 The IIF includes this digit string (including *) in the Digits (Dialed) parameter of a FEATREQ 10 message and sends the message to the subscriber’s HLR. 11
d. The HLR returns a featreq message to the IIF indicating a successful call waiting deactivation. 12
e. The IIF returns a Deactivate SS Ack message back to the Serving GSM MSC. Any parameters 13 the HLR may have included that provide instructions for treatment towards the user (such as 14 AnnouncementList) shall be ignored by the IIF and not mapped into the message sent to the 15 Serving GSM MSC. 16
N.S0028
Post Ballot Version 103
f. When the Deactivate SS Ack message is received from the IIF, the Serving GSM MSC sends a 1 message to the MS to indicate that the call waiting deactivation had been successful. 2
g. Because the request resulted in a change to the subscriber’s service profile (i.e., the call waiting 3 feature was deactivated), the HLR reports the change by sending a QUALDIR message to the IIF 4 emulating the Serving GSM MSC/VLR. 5
h. The IIF sends an Insert Subscriber Data message to the Serving GSM MSC/VLR. 6
i. The Serving GSM MSC/VLR returns an Insert Subscriber Data Ack to the IIF. 7
j. The IIF returns a qualdir message to the HLR. 8 9
10
N.S0028
Post Ballot Version 104
4.9 Calling Number / Line Identification Presentation/Restriction 1
4.9.1 Handling of calling number/ line identification presentation 2
B.1.3.13 4.9.1.1 GSM Foreign Mode 3
If CNIP / CLIP service is authorized and active, the calling party number is available and presentation 4 is allowed, the called party’s serving network shall provide the calling party number to the called party 5 during call alerting as in Figure 67 below. 6
7
8
Figure 67: Calling number/ line identification presentation: 9 mobile station or fixed terminal to mobile station – GSM Foreign Mode 10
a. An incoming call for the called party is received at his/her home network. 11 12
b. The calling party number may be carried in the calling party number digits parameter as specified 13 in TIA/EIA-41-5-D [1]. 14
15 c. The calling party number may be carried in the calling party number string parameter as specified 16
in TIA/EIA-41-5-D [1]. 17 18 d. The calling party number may be carried in the additional signal information element as specified 19
in GSM 09.02 [7]. 20 21
e. The VLR returns a roaming number for routing purposes. 22 23
f. The IIF maps the MSRN it receives from the VLR into the TLDN field in the routreq. 24
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
N.S0028
Post Ballot Version 105
1 g. The HLR returns a locreq to the MSC with the routing information it received from the IIF. 2 3 h. The trunk signaling between the MSC’s may transit a number of intermediate signaling networks 4
of various capabilities. As such, there is no guarantee that the calling party number can be 5 conveyed using the ISUP/TUP signaling capabilities. 6
7 i. The MSC delivers the calling party identification during the call setup operation with the MS. The 8
calling party subaddress is passed if it is received from the originating network. The Calling Party 9 No, Presentation Indicator (PI), and Screening Indicator (SI) shall be sent in accordance with 10 GSM 03.81 [5]. 11
12 Note: Where a calling party number is delivered both via MAP signaling and ISUP/TUP signaling, the 13
number delivered via MAP signaling takes precedence. 14 15 Note: When an additional calling party number is also available for presentation purposes, the 16
additional calling party number (subject to CNIP/CLIR) shall be presented in preference to any 17 other calling party number. 18
19
B.1.3.13.1 4.9.1.1.1 Interrogation 20
The subscriber can request the status of the supplementary service when operating in GSM foreign 21 mode and be informed if the service is provided to him/her. 22
23
N.S0028
Post Ballot Version 106
B.1.3.14 4.9.1.2 ANSI-41 Foreign Mode 1
If CNIP / CLIP service is authorized and active, the calling party number is available and presentation 2 is allowed, the called party’s serving network shall provide the calling party number to the called party 3 during call alerting as in Figure 68 below. 4
5
Figure 68: Calling number/ line identification presentation: 6 mobile station or fixed terminal to mobile station – ANSI-41 Foreign Mode 7
a. An incoming call for the called party is received at his/her home network. 8 9 b. The calling party number may be carried in the additional signal information element as specified 10
in GSM 09.02 [7]. 11 12 c. The calling party number may be carried in the additional signal information element as specified 13
in GSM 09.02 [7]. 14 15 d. The calling party number may be carried in the calling party number string parameter as specified 16
in ANSI-41.5 [1]. 17 18 e. The MSC returns a TLDN for routing purposes 19 20 f. The IIF maps the TLDN it receives from the MSC into the MSRN field in the Provide Roaming No 21
Ack. 22 23 g. The HLR returns an SRI Ack to the GMSC with the routing information it received from the IIF. 24 25
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)
N.S0028
Post Ballot Version 107
h. The trunk signaling between the MSC’s may transit a number of intermediate signaling networks 1 of various capabilities. As such, there is no guarantee that the calling party number can be 2 conveyed using the ISUP/TUP signaling capabilities. 3
4 i. The mobile station receives an incoming call alert, which contains the calling party identification 5
information. 6 7 Note: Where a calling party number is delivered both via MAP signaling and ISUP/TUP signaling, 8
the number delivered via MAP signaling takes precedence. 9
B.1.3.14.1 4.9.1.2.1 Interrogation 10
The subscriber cannot request the status of the supplementary service in ANSI-41 Foreign mode. 11
4.9.2 Handling of calling number/ line identification restriction 12
B.1.3.15 4.9.2.1 General 13
If the calling subscriber has calling number/line identification restriction authorized and active and it is 14 impossible to indicate to the terminating network (due to interworking) that the number shall not be 15 presented to the terminating party, the calling number/line identity shall not be delivered to the 16 terminating network. 17
B.1.3.16 4.9.2.2 GSM Foreign Mode 18
If CNIR / CLIR service is authorized and active, the calling party number is available and presentation 19 is restricted, the called party’s serving network shall not present the calling party number to the called 20 party during call alerting. An indication that the calling party number is restricted shall be delivered to 21 the called party. 22
B.1.3.16.1 4.9.2.2.1 Interrogation 23
The subscriber can request the status of the CNIR /CLIR supplementary service and be informed if 24 the service is provided to him/her and which mode is provided, i.e. permanent or temporary and if 25 temporary, what the default value is (i.e. allowed or restricted). 26
B.1.3.17 4.9.2.3 ANSI-41 Foreign Mode 27
If CNIR / CLIR service is authorized and active, the calling party number is available and presentation 28 is restricted, the called party’s serving network shall not present the calling party number to the called 29 party during call alerting. An indication that the calling party number is restricted shall be delivered to 30 the called party. 31
B.1.3.17.1 4.9.2.3.1 Interrogation 32
The subscriber cannot request the status of the supplementary service. 33
34
N.S0028
Post Ballot Version 108
4.10 Call Barring and Operator Determined Barring 1
This section describes the interoperability at the IIF to support ANSI-41 outgoing call restrictions, 2 GSM Operator Determined Barring (ODB), and GSM Call Barring Supplementary Services. The 3 scenarios included are illustrative and not exhaustive. 4
ODB is a GSM administrative feature. As described in associated Stage 1 documentation, direct 5 mapping of many GSM ODB or call barring options does not exist in ANSI-136 41 mode. Likewise, 6 many ANSI-41 outgoing call restrictions do not directly map to equivalent GSM ODB or call barring 7 options. 8
4.10.1 Activation of Barring at VLR 9
These call flows apply only to Call Barring Supplementary Services, ANSI-41 call restrictions, or ODB 10 programs (e.g., Barring of Outgoing Calls) for which barring is performed at the VLR. Any barring or 11 call restrictions applied in the HLR shall result in the appropriate restrictions being downloaded to the 12 serving VLR/MSC via the IIF. 13
B.1.3.18 4.10.1.1 Activation of Call Restrictions while in GSM Foreign Mode 14
This scenario describes the successful activation of call restrictions for a native ANSI-136 41 15 subscriber roaming in a GSM network at a time when the subscriber is currently registered. 16
a
b
c
d
ISD Ack
HLRVLR/MSC
Insert Subscriber Data
qualdir
IIF
QUALDIR
17
Figure 69: Activation of Call Restriction - GSM Foreign Mode 18
a. Call restrictions are applied at the ANSI-41 HLR. The HLR sends an appropriate 19 QualificationDirective INVOKE message to the IIF emulating the VLR where the subscriber is 20 roaming. 21 22
b. The IIF forwards a corresponding Insert Subscriber Data message to the GSM VLR. 23 24 c. The VLR sends an Insert Subscriber Data acknowledgement to the IIF. 25
26 d. The IIF forwards a QualificationDirective RETURN RESULT message to the HLR. 27
28
29
N.S0028
Post Ballot Version 109
B.1.3.19 4.10.1.2 Activation of Call Barring while in ANSI-41 Foreign Mode 1
This scenario describes the successful application of ODB or call barring for a native GSM subscriber 2 roaming in an ANSI-41 network. 3
a
b
c
dISD Ack
HLRVLR/MSC
Insert Subscriber Data
qualdir
IIF
QUALDIR
4
Figure 70: Activation of Call Barring – ANSI-41 Foreign Mode 5
6
a. ODB or call barring is applied at the GSM HLR. The HLR sends an appropriate Insert Subscriber 7 Data message to the IIF emulating the VLR where the subscriber is roaming. 8
9 b. The IIF forwards a corresponding QualificationDirective INVOKE message to the ANSI-41 VLR. 10 11 c. The VLR sends a QualificationDirective RETURN RESULT to the IIF. 12 13 d. The IIF forwards an Insert Subscriber Data acknowledgement message to the HLR. 14
4.10.2 Invocation of Barring of Incoming Calls 15
B.1.3.20 4.10.2.1 GSM Foreign Mode 16
Barring of incoming calls is performed at the ANSI-41 HLR. There is no IIF involvement. 17
B.1.3.21 4.10.2.2 ANSI-41 Foreign Mode 18
Barring of incoming calls is performed at the GSM HLR. There is no IIF involvement. 19
4.10.3 Invocation of Barring of Roaming 20
Barring of Roaming is performed at the HLR. The following subsections, however, illustrate the 21 signaling at the IIF when a barred subscriber attempts to roam into a GSM or ANSI-41 Foreign 22 network. 23
B.1.3.22 4.10.3.1 GSM Foreign Mode 24
This scenario describes the successful barring of roaming for a native ANSI-136 41 subscriber 25 attempting to roam into a GSM network. 26
N.S0028
Post Ballot Version 110
a
b
c
dUL Ack
MSC/VLR HLR
Update Location
regnot
IIF
REGNOT
1
Figure 71: Invocation of Barring of Roaming – GSM Foreign Mode 2
3
a. A native ANSI-136 41 subscriber with barring of Roaming active, attempts to register in a 4 GSM network. The GSM VLR sends an Update Location message to the IIF emulating the 5 subscriber’s HLR. 6
7 b. The IIF issues a RegistrationNotification INVOKE to the HLR. 8
9 c. The HLR determines that roaming is denied in this case, returns a RegistrationNotification 10
RETURN RESULT with AuthorizationDenied set to Not Authorized for the MSC. Optionally, a 11 RegistrationCancellation message may be sent to the previous Serving MSC/VLR (if 12 registration was in an ANSI-41 network) or to the IIF (if registration was in a GSM network). 13
14 d. The IIF issues an Update Location acknowledgement with User Error set to Roaming Not 15
Allowed. The VLR denies the registration attempt. 16 17
N.S0028
Post Ballot Version 111
B.1.3.23 4.10.3.2 ANSI-41 Foreign Mode 1
This scenario describes the successful ODB barring of roaming for a native GSM subscriber 2 attempting to roam into an ANSI-41 network. 3
a
b
c
d
UL Ack
MSC/VLR
HLR
Update Location
regnot
IIF
REGNOT
4
Figure 72: Invocation of Barring of Roaming – ANSI-41 Foreign Mode 5
6
a. A native GSM subscriber with ODB barring of Roaming active, attempts to register in an ANSI-41 7 network. The ANSI-41 VLR sends an RegistrationNotification INVOKE to the IIF emulating the 8 subscriber’s HLR. 9
10 b. The IIF issues an Update Location message to the HLR. 11 12 c. The HLR determines that roaming is denied in this case, returns an Update Location 13
acknowledgement with User Error set to Roaming Not Allowed. Optionally, a Cancel Location 14 message may be sent to the previous Serving MSC/VLR (if registration was in a GSM network) or 15 to the IIF (if registration was in an ANSI-41 network). 16
17 d. The IIF issues a RegistrationNotification RETURN RESULT with AuthorizationDenied set to Not 18
Authorized for the MSC. The VLR denies the registration attempt. 19
4.10.4 Invocation of Barring of Supplementary Services Management 20
Barring of Supplementary Services Management is performed at the HLR. The following subsections, 21 however, illustrate the signaling at the IIF when a subscriber attempts to activate a supplementary 22 service in a GSM or ANSI-41 Foreign network, while Barring of Supplementary Services Management 23 is in effect. 24
B.1.3.24 4.10.4.1 GSM Foreign Mode 25
This scenario describes the successful barring of supplementary service control for a native 26 ANSI-136 41 subscriber in a GSM network. 27
N.S0028
Post Ballot Version 112
a
b
c
dActivate SS Ack
MSC/VLR HLR
Activate SS
featreq
IIF
FEATREQ
1
Figure 73: Invocation of Barring of Supplementary Service Control – GSM Foreign Mode 2
3
a. A native ANSI-136 41 subscriber attempts to activate a feature to which he is not authorized. The 4 MSC sends an Activate SS message to the IIF emulating the subscriber’s HLR. 5 6
b. The IIF issues a FeatureRequest INVOKE message to the HLR. 7 8 c. The HLR, determining that the subscriber is not authorized, sends a FeatureRequest RETURN 9
RESULT, with FeatureResult set to Unsuccessful to the IIF. 10 11 d. The IIF issues an Activate SS acknowledgement, with User Error set to SS Subscription Violation 12
to the VLR. The VLR denies the activation. 13
14
N.S0028
Post Ballot Version 113
B.1.3.25 4.10.4.2 ANSI-41 Foreign Mode 1
This scenario describes the successful ODB barring of supplementary services management for a 2 native GSM subscriber in an ANSI-41 network. 3
a
b
c
d
Activate SS Ack
MSC/VLR HLR
Activate SS
featreq
IIF
FEATREQ
4
Figure 74: Invocation of Barring of Supplementary Services Management – ANSI-41 Foreign 5 Mode 6
a. 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 sends a 8 FeatureRequest INVOKE to the IIF emulating the subscriber’s HLR. 9 10
b. The IIF issues an Activate SS message to the HLR. 11 12 c. The HLR, determining that ODB barring is in effect for this subscriber, sends an Activate SS 13
acknowledgement, with User Error set to SS Subscription Violation to the IIF. 14 15 d. The IIF issues a FeatureRequest RETURN RESULT, with FeatureResult set to Unsuccessful to 16
the VLR. The VLR denies the activation. 17
18
N.S0028
Post Ballot Version 114
4.11 Short Message Service 1
This section illustrates the interactions between network entities in various situations related to GSM 2 and ANSI-41 foreign mode operation for Short Message Service. 3
4.11.1 Assumptions 4 The 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 from the 7 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 use a 9 teleservice server address which maps to the IIF. When the IIF receives this address it shall be 10 mapped to the corresponding message center. 11
• The MO SMS first goes to the originator’s Message Center (MC) and then to the recipient’s 12 Message Center. 13
Only foreign mode message flows are described. Native mode message flows are as defined for the 14 native mode technology except in 4.11.2 which addresses GHOST/WEMT-CMT interworking within 15 an ANSI-41 network. Note: CMT applies for CDMA or ANSI-136 subscriber, GHOST applies only for 16 ANSI-136 subscriber and WEMT only for CDMA subscribers. 17
18
19
N.S0028
Post Ballot Version 115
4.11.2 Mobile Station only Supports GHOST/WEMT 1
If the mobile station only supports GHOST (GSM Hosted SMS Teleservice) or WEMT, there shall be 2 a need for CMT (Cellular Messaging Transport) to GHOST/WEMT and GHOST/WEMT to CMT 3 conversion in the ANSI-41 network (i.e., in native mode), most probably in the Message Centers. This 4 is depicted in the next two diagrams. 5
B.1.3.26 4.11.2.1 Short Message from CMT Mobile Station to GHOST/WEMT Mobile 6 Station both in Native Mode 7
8
MS-A TDMAMSC
MC-A MC-B TDMAHLR
a
b
c
d
e
f
g
h
i
SMDPP (CMT)
smdpp [ACK]
TDMAMSC
SMD-REQ (CMT)
SMD-ACK
SMDPP (CMT)
SMDPP (GHOST)
smdpp [ACK]
smdpp [ACK]
SMSREQ
smsreq
(SMS delivered toMobile Stationusing GHOST)
9
Figure 75: Short Message from a TDMA or CDMA CMT phone to a GHOST or WEMT mobile 10 station, both in native mode 11
Notes: 12
Message Center B (MC-B) is responsible for converting CMT to GHOST/WEMT. 13
MC-A and MC-B could be one and the same. 14
15
16
N.S0028
Post Ballot Version 116
B.1.3.27 4.11.2.2 Short Message sent from GHOST/WEMT Mobile Station to CMT Mobile 1 Station, both in Native Mode 2
3
MS-A TDMAMSC
MC-A MC-B TDMAHLR
a
b
c
d
e
f
g
h
i
SMDPP (GHOST)
smdpp [ACK]
TDMAMSC
SMD-REQ (GHOST)
SMD-ACK
SMDPP (CMT)
SMDPP (CMT)
smdpp [ACK]
smdpp [ACK]
SMSREQ
smsreq
(SMS delivered toMobile Stationusing CMT)
j
k 4
Figure 76: Short Message from a GHOST or WEMT mobile station to a TDMA CMT or CDMA 5 CMT Phone, both in native mode 6
Notes: 7
Message Center A (MC-A) is responsible for converting GHOST GHOST/WEMT to CMT. This is 8 done so that only the operators using GHOST/WEMT would need to have a modified Message 9 Center. In the event that MS-B also uses GHOST/WEMT and that MC-A is not the same as MC-B, 10 then MC-B would have to re-convert from CMT to GHOST/WEMT, unless there is some way for MC-11 A to know that MS-B also uses GHOST/WEMT. 12
In the event that MC-A and MC-B are one and the same, and that MS-B also uses GHOST/WEMT, 13 then no conversion is needed. 14
15
16
N.S0028
Post Ballot Version 117
4.11.3 Mobile Terminating SMS in GSM Foreign Mode 1
This section discusses the delivery of the short message, i.e. how to deliver it to the roaming 2 subscriber once the message has been delivered in the recipient’s Message Center. 3
On the TDMA ANSI-41 side, the short message may have been originated in CMT or GHOST/WEMT 4 format. So the IIF has to convert either CMT or GHOST/WEMT to GSM SMS. 5
B.1.3.28 4.11.3.1 Successful Mobile Terminating ANSI-136 41 SMS (CMT) mapped to 6 GSM SMS 7
8
9
N.S0028
Post Ballot Version 118
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
1 TDMA
MCTDMAHLR IIF
GSMMSC/VLR
MS
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
2
Figure 77: Successful Mobile Terminating ANSI-136 41 SMS (CMT) mapped to GSM SMS 3
4 a. The ANSI-136 41 Message Center (MC) receives a short message for a specific subscriber. 5
Note: This step is shown for completeness only and is not repeated in subsequent call flows. 6 7 b. The Message Center sends an SMS Request message to the ANSI-41 HLR of the short 8
message recipient to request a routing address for delivering the short message to that 9 subscriber. 10
11
N.S0028
Post Ballot Version 119
c. Since the subscriber has a current valid location stored in the HLR, the HLR returns it to the MC 1 in the SMS Request Return Result message. 2
3 d. The Message Center then sends a Short Message Delivery Point to Point message to the IIF, 4
which is seen as the current serving ANSI-41 MSC/VLR for that subscriber. Note that in this 5 case, the format used by the MC is the CMT format (Cellular Messaging Transport). Note that 6 alternatively, the ANSI-136 41 MC could translate the original CMT SMS to GHOST or WEMT 7 format before sending it to the IIF if the IIF only supports the GHOST format. In this case the IIF 8 would convert ANSI-136 TDMA GHOST or CDMA WEMT into GSM format (see Section 9 4.11.3.2) instead of ANSI-136 41 CMT into GSM format. 10
e. Upon reception of the Short Message Delivery Point to Point message from the ANSI-136 41 11 MC, the IIF originates a FORWARD SHORT MESSAGE to the serving GSM MSC/VLR after 12 having translated the short message into GSM format. The IIF is then acting as a GSM SMS-13 GMSC. 14
15 f. The serving GSM MSC/VLR sends the short message to the mobile station. Note: This step is 16
shown for completeness only and is not repeated in subsequent call flows. 17 18
g. The mobile station acknowledges the delivery of the short message. Note: This step is shown 19 for completeness only and is not repeated in subsequent call flows. 20
21 h. The serving GSM MSC/VLR sends the result of the Forward Short Message to the IIF. 22 23 i. The IIF sends the result of the Short Message Delivery Point to Point to the ANSI-136 41 24
Message Center. 25
B.1.3.29 4.11.3.2 Successful Mobile Terminating ANSI-136 41 SMS (GHOST/WEMT) 26 Mapped to GSM SMS 27
28
29
N.S0028
Post Ballot Version 120
Figure 78: Successful Mobile Terminating ANSI-136 41 SMS (GHOST/WEMT) mapped to GSM 1 SMS 2
a. The ANSI-41 MC sends a SMSRequest Invoke message to the HLR, including as arguments the 3 MIN (MSISDN) of the mobile station and SMS Notification Indicator. 4
b. The HLR determines if the message shall be forwarded to the MS and sends a response back in 5 a SMSRequest Return Result, with the SMS_Address set to the IIF address (point code or E.164 6 address). 7
c. The MC formats a GHOST/WEMT teleservice and sends it to the IIF in an SMDPP message. 8
d. Upon receipt of the SMDPP message, the IIF builds a FORWARD SHORT MESSAGE, stripping 9 off the GHOST/WEMT teleservice and using the encapsulated GSM SMS transfer PDU, and 10 routes it to the VMSC. 11
e. The VMSC packages the GSM SMS RP-DATA into a CP-DATA message and delivers it across 12 the GSM air interface to the mobile station. The mobile station acknowledges receipt of the CP-13 DATA and RP-DATA messages via CP-ACK and CP-ACK[RP-ACK], respectively. Upon 14 successful receipt of the RP-ACK, the VMSC shall send a positive acknowledgement Forward 15 Short Message back to the IIF. 16
f. The IIF maps the received Forward Short Message into a SMDPP Return Result and sends it to 17 the MC. 18
ANSI-41 GSM
smdpp [ACK]
MC HLR IIF VMSC
a
d
a
c
b
SMDPP
SMSREQ
smsreq
FORWARD SHORT MESSAGE
Forward Short Messagee
f
N.S0028
Post Ballot Version 121
B.1.3.30 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/WEMT 2
format. 3
Figure 79: Unsuccessful Mobile Terminated Delivery (Failure at MSC) 4
5 a. The ANSI-41 MC sends a SMSRequest Invoke message to the HLR, including as arguments the 6
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 back in 8 a SMSRequest Return Result, with the SMS_Address set to the IIF address (point code or E.164 9 address). 10
c. The MC formats a GHOST/WEMT teleservice or a CMT short message and sends it to the IIF in 11 an SMDPP message. 12
d. Upon receipt of the SMDPP message, the IIF builds a FORWARD SHORT MESSAGE, stripping 13 off the GHOST/WEMT teleservice and using the encapsulated GSM SMS transfer PDU, and 14 routes it to the VMSC. If the message received is in the CMT format, the IIF maps this information 15 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 across 17 the GSM air interface to the mobile station. The mobile station negatively acknowledges either 18 the CP-DATA message or the RP-DATA message. The VMSC sends a negative 19 acknowledgement 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 to 21 the MC. In addition, the IIF sets one of the GSM SMS flags as defined in the GSM 03.40 22 specification [4] according to the error cause received from the VMSC; that is, the Mobile 23 Subscriber Not Reachable Flag (MNRF) shall be set if the error cause is “absent subscriber”, and 24 the Memory Capacity Exceeded Flag (MCEF) shall be set if the error cause is “memory capacity 25 exceeded”. Additionally, the IIF emulating the ANSI-41 MSC shall set and store the SMS 26 Delivery Pending flag with the MC parameters received in the SMDPP (for later delivery in the 27
ANSI-41 GSM
smdpp [NAK]
MC HLR IIF VMSC
a
d
a
c
b
SMDPP
SMSREQ
smsreq
FORWARD SHORT MESSAGE
Forward Short Messagee
f
N.S0028
Post Ballot Version 122
SMSNOT) – note that this “SMS Delivery Pending” flag/data serves the same purpose as a GSM 1 HLR’s “Message Waiting Data” flag/data. [However, note that if an ANSI-41 REGCAN is received 2 from the ANSI-41 HLR before the SMS Delivery Pending Flag is cleared, then the regcanc 3 response shall contain the SMS_MessageWaitingIndicator, and all flags are cleared (i.e., MNRF, 4 MCEF, and SMS Delivery Pending Flag)]. 5
6 7
N.S0028
Post Ballot Version 123
B.1.3.31 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/WEMT 2 format. 3 4
Figure 80: Unsuccessful Mobile Terminated Delivery (Failure at IIF) 5
a. The ANSI-41 MC sends a SMSRequest Invoke message to the HLR, including as arguments the 6 MIN (MSISDN) or IMSI 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 back in 8 a SMSRequest Return Result, with the SMS_Address set to the IIF address (point code or E.164 9 address). 10
c. The MC formats a GHOST/WEMT teleservice and sends it to the IIF in an SMDPP message. 11
d. Upon receipt of the SMDPP message, the IIF examines the GSM 03.40 HLR flags (MNRF/MCEF) 12 and determines that the MS is unable to receive a Short Message. The IIF indicates this fact in 13 the SMDPP Return Result. It includes the cause for the failure in the SMS_CauseCode 14 parameter of the SMDPP Return Result. The IIF shall set & store the SMS Delivery Pending Flag 15 with the data received in the SMDPP message (for later delivery in the SMSNOT). 16
17
ANSI-41 GSM
smdpp [NAK]
MC HLR IIF VMSC
a
d
a
c
b
SMDPP
SMSREQ
smsreq
N.S0028
Post Ballot Version 124
B.1.3.32 4.11.3.5 Alerting for an ANSI-136 41 Subscriber in GSM Foreign Mode 1
The following scenario applies to short messages originated in either CMT or GHOST/WEMT format. 2
3
Figure 81: Alerting for an ANSI-136 41 Subscriber in GSM Foreign Mode 4
5
a. The VMSC sends a READY FOR SM (MAP V2) to the IIF, including as arguments the IMSI and 6 Alert Reason. Note: The SMS notification can also be triggered when the VMSC sends a 7 NoteMSPresent (MAP V1) or an UpdateLocation. 8
b. If the IIF has GSM 03.40 flags set, then these flags shall be cleared according to the “alert 9 reason”; that is, if the “alert reason” is “memory available”, then both the MCEF and MNRF flags 10 are cleared, and if the “alert reason” is “MS present”, then the MNRF flag is cleared. If the 11 UpdateLocation is received, then the MNRF flag is cleared. The IIF sends a Ready for SM 12 response to the VMSC with no arguments. 13
c. If the IIF has the SMS Delivery Pending Flag set, and if the MCEF flag is not set, then the IIF 14 sends a SMSNOT to each of the subscriber’s MCs stored with the SMS Delivery Pending Flag. 15 The SMSNOT shall contain; the MIN (MSISDN) as mapped from the IMSI, ESN, and 16 SMS_Address containing the IIF address. 17
d. The MC sends a SMSNOT Return Result to the IIF, then the IIF clears the SMS Delivery Pending 18 Flag, then proceeds to send the mobile station a mobile terminated GHOST/WEMT teleservice 19 message according to 4.11.3.2. 20
21 4.11.4 Mobile Terminated SMS in ANSI-41 Foreign Mode 22
This section describes the message flows for delivering a CMT or GHOST/WEMT teleservice when 23 the mobile station is operating in ANSI-41 Foreign Mode. Since on the TDMA ANSI-41 side, the short 24 message may need to be in CMT or GHOST/WEMT format, the IIF has to convert the GSM SMS to 25 either CMT or GHOST/WEMT. 26
27
ANSI-41 GSM
smsnot
MC HLR IIF VMSC
READY FOR SM
Ready fro SM
a
d
a
c
b
SMSNOT
N.S0028
Post Ballot Version 125
B.1.3.33 4.11.4.1 Successful GSM SMS mapped to ANSI-136 41 (CMT) SMS 1
2
Figure 82: Successful GSM SMS mapped to ANSI-136 41 (CMT) SMS 3
a. The GSM Short Message Service Center (SMSC) receives a short message for a specific 4 subscriber. Note: This step is shown for completeness only and is not repeated in subsequent 5 call flows. 6
7 b. The SMS-GMSC originates a Send Routing Info for Short Message to the GSM HLR of the short 8
message recipient to request a routing address for delivering the short message to that 9 subscriber. 10
11 c. Since the subscriber has a current valid location stored in the HLR, the HLR returns it to the 12
SMS-GMSC in the Send Routing Info for Short Message Result message. 13 14 d. The SMS-GMSC then sends a Forward Short Message to the IIF, seen as the serving GSM 15
MSC/VLR. 16 17 e. Upon reception of the Forward Short Message from the SMS-GMSC, the IIF originates a Short 18
Message Delivery Point to Point message to the serving ANSI-41 MSC/VLR after having 19 translated the short message into IS-136 41 CMT format. The IIF is then acting as an ANSI-136 20 41 Message Center. 21
22 f. The serving ANSI-41 MSC/VLR sends the short message to the mobile station and an 23
acknowledgement is sent back to the MSC/VLR. 24 25
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)
N.S0028
Post Ballot Version 126
g. The serving ANSI-41 MSC/VLR sends the result of the Short Message Delivery Point to Point 1 message to the IIF. 2
3 h. The IIF sends the result of the Forward Short Message to the GSM SMS-GMSC. 4
5
6
N.S0028
Post Ballot Version 127
B.1.3.34 4.11.4.2 Successful GSM SMS mapped to ANSI-136 41 (GHOST/WEMT) SMS 1
This method uses the tunneling concept. Instead of translating the GSM SMS to an ANSI-136 41 2 CMT SMS format, the IIF shall package the GSM SMS into an ANSI-136TDMA SMS with the 3 teleservice GHOST (GSM Hosted SMS Teleservice) or CDMA SMS with teleservice WEMT.. 4
5 6
Figure 83: Successful GSM SMS mapped to ANSI-136 41 (GHOST/WEMT) SMS 7
8
a. The SMSC receives a request to deliver a short message to a GSM subscriber. It sends to the 9 GSM HLR a SEND ROUTING INFO FOR SM, including as arguments the MSISDN, Priority, and 10 Service Centre address. 11
b. The HLR determines if the message shall be forwarded to the MS and sends a response back to 12 the SMSC in a Send Routing Info for SM, including as arguments the IMSI of the MS and 13 Network Node Number of the IIF. 14
c. The SMSC originates a FORWARD SHORT MESSAGE to the address provided by the HLR (i.e., 15 IIF), including as arguments the IMSI, Service Centre Address, and GSM SMS-DELIVER PDU 16 (and optionally if more messages are to be sent). 17
Upon receipt of the FORWARD SHORT MESSAGE, the IIF shall build an ANSI-41 SMDPP , 18 encapsulating the GSM SMS transfer PDU in the GHOST/WEMT teleservice. The IIF shall route 19 the SMDPP message to the serving MSC. The serving MSC maps the SMDPP message into an 20 R-DATA message and sends it to the mobile station over the TDMA or CDMAANSI-136 air 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 (GHOST)
smdpp [ACK]
g
h
N.S0028
Post Ballot Version 128
interface. The mobile station shall acknowledge receipt of the R-DATA message and 1 GHOST/WEMT teleservice by sending an R-DATA ACCEPT message to the MSC. 2
3
d. After receiving the R-DATA ACCEPT message, the serving MSC sends a positive 4 acknowledgement SMDPP Return Result to the IIF. 5
e. The IIF maps the received SMDPP Return Result to a Forward Short Message, and sends it to 6 the GSM SMSC. 7
f. The SMSC send a REPORT SM DELIVERY STATUS to the HLR, including as arguments the 8 MSISDN, SMSC Address, and Successful Transfer. The SMSC sends this message based on 9 the procedures described in GSM 03.40 [4] and GSM 09.02 [6]. 10
g. The HLR shall set the appropriate flags as specified in the GSM specifications (GSM 09.02 and 11 03.40), then send a Report SM Delivery Status to the SMSC. 12
B.1.3.35 4.11.4.3 Unsuccessful GSM SMS mapped to ANSI-136 41 SMS (Failure at MS) 13
The following scenario applies to short messages delivered in either CMT or GHOST/WEMT format. 14
Figure 84: Successful GSM SMS mapped to ANSI-136 41 SMS (Failure at MS) 15
16
a. The SMSC receives a request to deliver a short message to a GSM subscriber. It sends to the 17 GSM HLR a SEND ROUTING INFO FOR SM, including as arguments the MSISDN, Priority, and 18 Service Center address. 19
b. The HLR determines if the message shall be forwarded to the MS and sends a response back to 20 the SMSC in a Send Routing Info for SM, including as arguments the IMSI of the MS and 21 Network Node Number of 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
N.S0028
Post Ballot Version 129
c. The SMSC originates a FORWARD SHORT MESSAGE to the address provided by the HLR (i.e., 1 IIF), including as arguments the IMSI, Service Center Address, and GSM SMS-DELIVER PDU 2 (and optionally if more messages are to be sent). 3
d. Upon receipt of the FORWARD SHORT MESSAGE, the IIF builds an ANSI-41 SMDPP message, 4 encapsulating the GSM SMS transfer PDU in a GHOST/WEMT teleservice, and routes it to the 5 serving MSC. The IIF can also convert the message into ANSI-136 41 CMT format. The serving 6 MSC converts the SMDPP message into an R-DATA message and sends it to the mobile station 7 over the ANSI-136TDMA or CDMA air interface. The mobile station returns an R-DATA REJECT 8 message to the MSC, indicating an error in the receipt of the message. 9
e. Upon receipt of the R-DATA REJECT, the serving MSC maps the ANSI-136 41 R-Cause code to 10 the appropriate ANSI-41 SMS_CauseCode value, and sends a negative acknowledgement 11 SMDPP Return Result back to the IIF. 12
f. The IIF sets the SMS Delivery Pending Flag in the IIF and maps the received SMDPP Return 13 Result into a Forward Short Message and sends it to the SMSC, after mapping the 14 SMS_CauseCode to the appropriate GSM MAP error. 15
g. The SMSC sends a REPORT SM DELIVERY STATUS to the HLR, including as arguments the 16 MSISDN, SMSC Address, and Error Cause. The SMSC sends this message based on the 17 procedures described in GSM 03.40 [4] and GSM 09.02 [6]. 18
h. The HLR shall set the appropriate flags as specified in the GSM specifications (GSM 09.02 and 19 03.40), then send a Report SM Delivery Status to the SMSC. 20
B.1.3.36 4.11.4.4 Unsuccessful Delivery to GSM Subscriber (Postponed at MSC) 21
The following scenario applies to short messages delivered in either CMT or GHOST/WEMT format. 22
23
24
N.S0028
Post Ballot Version 130
Figure 85: Unsuccessful Delivery to GSM Subscriber (Postponed at MSC) 1
a. The SMSC receives a request to deliver a short message to a GSM subscriber. It sends to the 2 GSM HLR a SEND ROUTING INFO FOR SM, including as arguments the MSISDN, Priority, and 3 Service Centre address. 4
b. The HLR determines if the message shall be forwarded to the MS and sends a response back to 5 the SMSC in a Send Routing Info for SM, including as arguments the IMSI of the MS and 6 Network Node Number of the IIF. 7
c. The SMSC originates a FORWARD SHORT MESSAGE to the address provided by the HLR (i.e., 8 IIF), including as arguments the IMSI, Service Centre Address, and GSM SMS-DELIVER PDU 9 (and optionally if more messages are to be sent). 10
d. Upon receipt of the FORWARD SHORT MESSAGE, the IIF builds an ANSI-41 SMDPP message, 11 encapsulating the GSM SMS transfer PDU in a GHOST/WEMT teleservice, and routes it to the 12 serving MSC. The IIF can also convert the message into ANSI-136 41 CMT format. The 13 addressed MS is temporarily unavailable for short message delivery and notification was 14 requested. 15
e. The MSC responds with a negative acknowledgement SMS_CauseCode carried in the SMDPP 16 Return Result indicating delivery is postponed and returns it to the source of the corresponding 17 SMDPP (i.e., IIF). The MSC sets its SMS Delivery Pending Flag. 18
f. The IIF sets the SMS Delivery Pending Flag in the IIF and maps the received SMDPP Return 19 Result into a Forward Short Message and sends it to the SMSC, after mapping the 20 SMS_CauseCode to the appropriate GSM MAP error. 21
g. The SMSC sends a REPORT SM DELIVERY STATUS to the HLR, including as arguments the 22 MSISDN, SMSC Address, and Error Cause. The SMSC sends this message based on the 23 procedures described in GSM 03.40 [4] and GSM 09.02 [6]. 24
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
N.S0028
Post Ballot Version 131
h. The HLR shall set the appropriate flags as specified in the GSM specifications (GSM 09.02 and 1 03.40), then send a Report SM Delivery Status to the SMSC. 2
3
N.S0028
Post Ballot Version 132
B.1.3.37 4.11.4.5 Unsuccessful Delivery to GSM Subscriber (Failure at IIF) 1
2
Figure 86: Unsuccessful Delivery to GSM Subscriber (Failure at IIF) 3
a. The SMSC receives a request to deliver a short message to a GSM subscriber. It sends to the 4 GSM HLR a SEND ROUTING INFO FOR SM, including as arguments the MSISDN, Priority, and 5 Service Centre address. 6
b. The HLR determines if the message shall be forwarded to the MS and sends a response back to 7 the SMSC in a Send Routing Info for SM, including as arguments the IMSI of the MS and Network 8 Node Number of the IIF. 9
c. The SMSC originates a FORWARD SHORT MESSAGE to the address provided by the HLR (i.e., 10 IIF), including as arguments the IMSI, Service Centre Address, and GSM SMS-DELIVER PDU 11 (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 be 13 unavailable or the SMS Waiting Indicator flag is set, then the IIF builds a Forward Short Message 14 and send it back to the SMSC. 15
e. The SMSC sends a REPORT SM DELIVERY STATUS to the HLR, including as arguments the 16 MSISDN, SMSC Address, and Error Cause. 17
f. The HLR shall set the appropriate flags as specified in the GSM specifications (GSM 09.02 and 18 03.40) and sends a Report SM Delivery Status to the SMSC. The SMSC sends this message 19 based on the procedures described in GSM 03.40 [4] and GSM 09.02 [6]. 20
B.1.3.38 4.11.4.6 Alerting for a GSM Subscriber in ANSI-41 Foreign Mode 21
In the event that the delivery of the short message to the ANSI-41 network is not possible, the IIF 22 shall be notified by the serving ANSI-41 MSC/VLR when the subscriber is available again. This shall 23 be done by receiving a Registration Notification or an SMS Notification message. This is illustrated in 24
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
N.S0028
Post Ballot Version 133
the following diagram. The following scenario applies to short messages delivered in either CMT or 1 GHOST/WEMT format. 2
3
Figure 87: Alerting for a GSM Subscriber in ANSI-41 Foreign Mode 4
a. The IIF receives either (1) an SMSNOT, or (2) a REGNOT when the ANSI-41 SMS Delivery 5 Pending Flag is set at the IIF or the SMS_Address parameter is present in the REGNOT. 6
b. The IIF alerts the GSM HLR by sending a READY FOR SM including as arguments the IMSI and 7 MS-Present. 8
c. The HLR shall send a Ready for SM to the IIF. If the SMS Waiting Indicator flag is set in the IIF, 9 then it is cleared. 10
d. The IIF returns a Return Result acknowledgement message. 11
e. The HLR originates an ALERT SERVICE CENTRE to the SMSC address stored in the HLR, 12 including as arguments the MSISDN, and SMSC Address. 13
f. The SMSC sends an Alert Service Centre to the HLR, then proceeds to send the mobile station a 14 mobile terminated GSM SMS message according to 4.11.4.2. 15
16
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
N.S0028
Post Ballot Version 134
1 4.11.5 Message Flows for Mobile Originated SMS in GSM Foreign Mode 2
This section describes the message flows for originating a short message to the subscriber’s home 3 message center when the mobile station is operating in GSM Foreign Mode. The following scenarios 4 apply to short messages delivered to the MC in either CMT or GHOST/WEMT format. 5
B.1.3.39 4.11.5.1 Successful Mobile Originated Delivery 6
Figure 88: Successful Mobile Originated Delivery 7
a. The VMSC originates a FORWARD SHORT MESSAGE to the address provided by the MS (i.e., 8 IIF), including as arguments the Service Centre Address, MSISDN and GSM SMS-SUBMIT PDU. 9
b. Upon receipt of the FORWARD SHORT MESSAGE, the IIF builds an ANSI-41 SMDPP message, 10 encapsulating the GSM SMS transfer PDU in a GHOST/WEMT teleservice, and routes it to the 11 originator’s home MC. The IIF can also map the Forward Short Message into a CMT short 12 message. 13
c. The MC sends a positive acknowledgement SMDPP Return Result to the IIF. 14
d. The IIF maps the received SMDPP Return Result to a Forward Short Message, and sends it to 15 the VMSC. 16
17
18
GSM ANSI-41
FORWARD SHORT MESSAGE
Forward Short Message
VMSC HLR IIF MC
SMDPP
smdpp [ACK]
a
d
a
c
b
N.S0028
Post Ballot Version 135
B.1.3.40 4.11.5.2 Unsuccessful Mobile Originated (Failure at MC) 1
Figure 89: Unsuccessful Mobile Originated (Failure at MC) 2
3
a. The VMSC originates a FORWARD SHORT MESSAGE to the address provided by the MS (i.e., 4 IIF), including as arguments the Service Centre Address, MSISDN and GSM SMS-SUBMIT PDU. 5
b. Upon receipt of the FORWARD SHORT MESSAGE, the IIF builds an ANSI-41 SMDPP message 6 encapsulating the GSM SMS transfer PDU in a GHOST/WEMT teleservice, and routes it to the 7 MC. The IIF can also map the Forward Short Message into a CMT short message. 8
c. The MC sends a negative acknowledgement SMDPP Return Result to the IIF. 9
d. The IIF maps the received SMDPP Return Result to a Forward Short Message with the 10 appropriate cause code value, and sends it to the VMSC. 11
12
13
GSM ANSI-41
FORWARD SHORT MESSAGE
Forward Short Message
VMSC HLR IIF MC
SMDPP
smdpp [NAK]
a
d
a
c
b
N.S0028
Post Ballot Version 136
B.1.3.41 4.11.5.3 Unsuccessful Mobile Originated (Failure at IIF) 1
2 Figure 90: Unsuccessful Mobile Originated (Failure at IIF) 3
4
a. The VMSC 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-SUBMIT PDU. 6
b. Upon receipt of the FORWARD SHORT MESSAGE, the IIF builds a negative acknowledgement 7 Forward Short Message and sends it to the VMSC. 8
9
4.11.6 Message Flows for Mobile Originated SMS in ANSI-41 Foreign Mode 10
This section describes the message flows for originating a short message to the subscriber’s home 11 message center when the mobile station is operating in ANSI-41 Foreign Mode. The following 12 scenarios apply to short messages originated in either CMT or GHOST/WEMT format. 13
14
GSM ANSI-41
FORWARD SHORT MESSAGE
Forward Short Message
VMSC HLR IIF MC
a
b
N.S0028
Post Ballot Version 137
B.1.3.42 4.11.6.1 Successful Mobile Originated Delivery 1
Figure 91: Successful Mobile Originated Delivery – ANSI-41 Foreign Mode 2
a. The VMSC originates a SMDPP invoke to the address provided by the MS (i.e., IIF), including as 3 arguments the Teleservice Server Address, MIN (MSISDN), and GSM SMS-SUBMIT PDU 4 encapsulated in the GHOST/WEMT teleservice. The mobile originated message can also be in 5 the CMT format. 6
b. Upon receipt of the SMDPP invoke, the IIF builds a FORWARD SHORT MESSAGE, and routes it 7 to the SMSC. 8
c. The SMSC sends a positive acknowledgement Forward Short Message to the IIF. 9
d. The IIF maps the received Forward Short Message to a SMDPP Return Result and sends it to the 10 VMSC. 11
12
ANSI-41 GSM
SMDPP
smdpp [ACK]
VMSC HLR IIF SMSC
FORWARD SHORT MESSAGE
Forward Short Message
a
d
a
c
b
N.S0028
Post Ballot Version 138
B.1.3.43 4.11.6.2 Unsuccessful Mobile Originated (Failure at SMSC) 1
Figure 92: Successful Mobile Originated (Failure at SMSC) – ANSI-41 Foreign Mode 2
3
a. The VMSC originates a SMDPP invoke to the address provided by the MS (i.e., IIF), including as 4 arguments the Teleservice Server Address, MIN (MSISDN) and GSM SMS-SUBMIT PDU 5 encapsulated in the GHOST/WEMT teleservice. The mobile originated message can also be in 6 the CMT format. 7
b. Upon receipt of the SMDPP message, the IIF builds a FORWARD SHORT MESSAGE, stripping 8 off the GHOST GHOST/WEMT teleservice and using the encapsulated GSM SMS transfer PDU, 9 and routes it to the SMSC. 10
c. The SMSC sends a negative acknowledgement Forward Short Message to the IIF. 11
d. The IIF maps the received Forward Short Message into a SMDPP Return Result and sends it to 12 the VMSC. 13
14
ANSI-41 GSM
SMDPP
smdpp [NAK]
VMSC HLR IIF SMSC
FORWARD SHORT MESSAGE
Forward Short Message
a
d
a
c
b
N.S0028
Post Ballot Version 139
B.1.3.44 4.11.6.3 Unsuccessful Mobile Originated (Failure at IIF) 1
2
Figure 93: Unsuccessful Mobile Originated (Failure at IIF) – ANSI-41 Foreign Mode 3
4
a. The VMSC originates a SMDPP invoke to the address provided by the MS (i.e., IIF), including as 5 arguments the Teleservice Server Address, MIN (MSISDN) and GSM SMS-SUBMIT PDU 6 encapsulated in the GHOST/WEMT teleservice. The mobile originated message can also be in 7 the CMT format. 8
b. Upon receipt of the SMDPP message, the IIF builds a negative acknowledgement SMDPP 9 Return Result and sends it to the VMSC. 10
11
ANSI-41 GSM
SMDPP
smdpp [NAK]
VMSC HLR IIF SMSC
a
b
N.S0028
Post Ballot Version 140
4.12 Message Waiting Notification 1
This contribution illustrates the interactions between network entities in various situations related to 2 GSM and ANSI-41 foreign mode operation and Message Waiting Notification. 3
4.12.1 GSM Foreign Mode 4
For a native ANSI-136 41 subscriber roaming in a GSM environment, there can be two events that 5 trigger the IIF to send the Message Waiting Notification (MWN) using the GSM SMS to the Mobile 6 Station (MS). The first one is at registration (location update), if there is an indication in the ANSI-41 7 HLR that messages have been delivered to the subscriber’s voice mail box, the ANSI-41 HLR shall 8 indicate that in the Registration Notification Return Result message. This shall trigger the IIF to send 9 a GSM SMS with the MWN information. This is shown in Section 4.12.1.1 The second event is when 10 the HLR receives a Message Waiting Notification for a subscriber that is already registered. In this 11 case, the ANSI-41 HLR shall send a Qualification Directive message to the IIF which shall translate it 12 into a GSM SMS with MWN indication. This is shown in Section 4.12.1.2 13
14
N.S0028
Post Ballot Version 141
B.1.3.45 4.12.1.1 Indicator in ANSI-41 Registration Notification Return Result mapped to 1 GSM SMS 2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Figure 94: Indicator in ANSI-41 Registration Notification Return Result mapped to GSM SMS 30
a. The Voice Mail System (VMS) receives a voice mail for a specific subscriber. 31 32 b. The VMS send the “Message Waiting Notification” (MWN) to the ANSI-41 HLR of the voice mail 33
recipient. Note that the interface between the VMS and the ANSI-41 HLR is not standardized in 34 ANSI-41 [1]. Note also that at that point in time, the subscriber is not registered in any serving 35 system, so the HLR just keeps the information that a voice mail was received. 36
37 c. The Mobile Station accesses a serving system and originates an update location request. 38 39
Forw.Short Message
SMS Delivery Ack
SMS Delivery (MWN)
FORW.SHORT MESSAGE (MWN)
Update Loc Accept
update location
Insert_sub_data
INSERT_SUB_DATA
regnot (MWNCOUNT, MWNTYPE)
UPDATE LOCATION
Update Loc Req
“Message Waiting Notification”
Vmail Delivery
REGNOT
VMS
ANSI-41
IIF GSM MSC/VLR
MS
a
b
c
d
e
f
g
h
i
j
k
l
m
n
①
②
N.S0028
Post Ballot Version 142
d. The Update Location is sent from the serving GSM MSC/VLR to the IIF, seen as the GSM HLR 1 for that subscriber. 2
3 e. The IIF sends a Registration Notification to the ANSI-41 HLR of the subscriber. 4 5 f. The ANSI-41 HLR replies with the Registration Notification Return Result containing the 6
“Message Waiting Notification” information that consists of two parameters: 7 MessageWaitingNotificationCount (MWNCOUNT) and MessageWaitingNotificationType 8 (MWNTYPE). For a description of these parameters, see the ANSI-41 specifications, sections 9 6.5.2.78 and 6.5.2.79 [1]. 10
11 ➀ At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification 12 is to be delivered to the Mobile Station. 13
14 g. The IIF sends Insert Subscriber Data to the serving GSM MSC/VLR. Note that there could be 15
more than one Insert Subscriber Data message depending on the subscriber profile. 16 17 h. The serving GSM MSC/VLR returns the Insert Subscriber Data result. Note that there could be 18
more than one such result message, one matching every Insert Subscriber Data message. 19 20 i. The IIF completes the location update by sending the Update Location result message to the 21
serving GSM MSC/VLR. 22 23 j. The serving GSM MSC/VLR confirms the update location to the mobile station. 24 25 k. Since the REGNOT return result from event f contained the Message Waiting Notification 26
information, this triggers the IIF to originate an SMS with MWN information by sending Forward 27 Short Message to the serving GSM MSC/VLR. The IIF is then acting as a GSM SMS-GMSC. The 28 IIF is to encode the MWN information in the SMS with three methods, namely, UDH, DCS, and 29 CPHS. See to Volume 3 for the encoding details. 30
31 l. The serving GSM MSC/VLR sends the short message with the MWN information to the mobile 32
station. 33 34 m. The mobile station acknowledges the delivery of the short message. 35 36 n. The serving GSM MSC/VLR sends the result of the Forward Short Message to the IIF. 37 38
➁ At this point, the IIF clears the MWN flag. The reception of the Forward Short Message Result 39 without error indicates that the MWN information was delivered successfully to the Mobile Station. 40
41
N.S0028
Post Ballot Version 143
B.1.3.46 4.12.1.2 ANSI-41 Qualification Directive mapped to GSM SMS 1
2 3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Figure 95: ANSI-41 Qualification Directive mapped to GSM SMS 21
a. The Voice Mail System (VMS) receives a voice mail for a specific subscriber. 22 23 b. The VMS send the “Message Waiting Notification” (MWN) to the ANSI-41 HLR of the voice mail 24
recipient. Note that the interface between the VMS and the ANSI-41 HLR is not standardized in 25 ANSI-41 [1]. 26
27 c. Since the subscriber has a current valid location stored in the HLR, the HLR initiates a 28
Qualification Directive message with the MWN information to the IIF acting as the serving ANSI-29 41 MSC/VLR. The MWN information consists of two parameters: 30 MessageWaitingNotificationCount (MWNCOUNT) and MessageWaitingNotificationType 31 (MWNTYPE). For a description of these parameters, see to the ANSI-41-D specifications, 32 sections 6.5.2.78 and 6.5.2.79 [1]. 33
34 ① At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification 35 is to be delivered to the Mobile Station. 36
37 d. The IIF sends the result of the Qualification Directive message to the ANSI-41 HLR. 38 39 e. The IIF also originates an SMS with MWN information by sending a Forward Short Message to 40
the serving GSM MSC/VLR. The IIF is then acting as a GSM SMS-GMSC. The IIF is to encode 41 the MWN information in the SMS with three methods, namely, UDH, DCS, and CPHS. See to 42 Volume 3 for the encoding details. 43
44
QUALDIR (MWNCOUNT, MWNTYPE)
Forw.Short Message
SMS Delivery Ack
SMS Delivery (MWN)
FORW.SHORT MESSAGE (MWN)
qualdir
“Message Waiting Notification”
Vmail Delivery
ANSI-41 VMS ANSI-
41 IIF GSM
MSC/VLR MS
a
b
c
d
e
f
g
h
①
②
N.S0028
Post Ballot Version 144
f. The serving GSM MSC/VLR sends the short message with the MWN information to the mobile 1 station. 2
3 g. The mobile station acknowledges the delivery of the short message. 4 5 h. The serving GSM MSC/VLR sends the result of the Forward Short Message to the IIF. 6 7
➁ At this point, the IIF clears the MWN flag. The reception of the Forward Short Message Result 8 without error indicates that the MWN information was delivered successfully to the Mobile Station. 9
B.1.3.47 4.12.1.3 Handling when GSM MSC/VLR only supports GSM Phase 1 (MAP V1) 10
After the IIF has received a Qualification Directive message with MWN information or received the 11 MWN information through a Registration Notification Return Result, a Forward Short Message with 12 MWN information needs to be sent to the serving GSM MSC/VLR. This was shown in Sections 13 4.12.1.1 and 4.12.1.2. However, it is possible that the serving GSM MSC/VLR does not support the 14 MAP V2 Application Context. In this case, the IIF shall receive an ABORT message and shall re-send 15 the Forward Short Message with MWN information using MAP V1 instead of MAP V2. This is 16 illustrated in the following diagram. 17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
Figure 96: Handling when GSM MSC/VLR only supports GSM Phase 1 (MAP V1) 36
a. The IIF receives Message Waiting Notification (MWN) information from a Qualification Directive 37 or a Registration Notification Return Result. This was described in Sections 4.12.1.1 and 38 4.12.1.2. 39 ➀ At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification 40 is to be delivered to the Mobile Station. 41
42
MWN “Information”
FORW.SHORT MSG (MWN) – V1
FORW.SHORT MSG (MWN) – V2
Forw.Short Message
SMS Delivery Ack
SMS Delivery (MWN)
IIF GSM MSC/ VLR
MS
a
b
c c
d
e
f
g
①
②
ABORT
N.S0028
Post Ballot Version 145
b. The IIF originates an SMS with MWN information by sending Forward Short Message using MAP 1 V2 to the serving GSM MSC/VLR. The IIF is then acting as a GSM SMS-GMSC. The IIF is to 2 encode the MWN information in the SMS with three methods, namely, UDH, DCS, and CPHS. 3
4 c. Since the serving GSM MSC/VLR does not support the MAP V2 Application Context, it returns an 5
Abort message to the IIF. 6 7 d. The IIF then re-sends a Forward Short Message with MWN information to the serving GSM 8
MSC/VLR, but this time using MAP V1. In this case, the MWN information can be encoded with 9 only two encoding methods, namely, DCS and CPHS. 10
11 e. The serving GSM MSC/VLR sends the short message with the MWN information to the mobile 12
station. 13 14 f. The mobile station acknowledges the delivery of the short message. 15 16 g. The serving GSM MSC/VLR sends the result of the Forward Short Message to the IIF. 17 18
➁ At this point, the IIF clears the MWN flag. The reception of the Forward Short Message Result 19 without error indicates that the MWN information was delivered successfully to the Mobile Station. 20
B.1.3.48 4.12.1.4 Handling at SMS delivery failure at the IIF 21
This section describes the case where the error occurs at the IIF, for example, an unrecognized 22 Mobile Identity Number (MIN). 23
24
25
26
27
28
29
30
31
32
33
Figure 97: Handling at SMS delivery failure at the IIF 34
a. The Voice Mail System (VMS) receives a voice mail for a specific subscriber. 35 36
b. The VMS send the “Message Waiting Notification” (MWN) to the ANSI-41 HLR of the voice mail 37 recipient. Note that the interface between the VMS and the ANSI-41 HLR is not standardized in 38 ANSI-41 [1]. 39
40 c. Since the subscriber has a current valid location stored in the HLR, the HLR initiates a 41
Qualification Directive message with the MWN information to the IIF acting as the serving ANSI-42 41 MSC/VLR. The MWN information consists of two parameters: 43 MessageWaitingNotificationCount (MWNCOUNT) and MessageWaitingNotificationType 44 (MWNTYPE). For a description of these parameters, see to the ANSI-41-D specifications, 45 sections 6.5.2.78 and 6.5.2.79 [1]. 46
Vmail Delivery
“Message Waiting Notification”
Qualdir Return Error
QUALDIR (MWNCOUNT), MWNTYPE)
VMS IIF
a
b
c c
ANSI-41
N.S0028
Post Ballot Version 146
1 d. An error is encountered so that the IIF cannot process the Qualification Directive message and 2
sends a Return Error message to the ANSI-41 HLR with the proper error code as per ANSI-41 3 Specifications, Chapter 6, Section 4.32.2, Table 42 [1]. 4
5
N.S0028
Post Ballot Version 147
B.1.3.49 4.12.1.5 Handling at SMS delivery failure at the MSC/VLR or at the Mobile 1 Station 2
The IIF is to keep a Message Waiting Notification (MWN) flag for each subscriber in its database. In 3 the event of a failure to deliver a short message with MWN to the mobile station, the IIF is to keep the 4 MWN flag set. Another Forward Short Message with MWN information shall be sent, triggered by the 5 reception of a subsequent GSM Update Location message, a Ready for Short Message, or a Note 6 MS Present message. This is illustrated in the following diagram. 7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
Figure 98: Handling at SMS delivery failure at the MSC/VLR or at the MS 35
a. The IIF receives Message Waiting Notification (MWN) information from a Qualification Directive 36 or a Registration Notification Return Result. This was described in Sections 4.12.1.1 and 37 4.12.1.2. 38
“Acknowledgement”
NOTE MS PRES – V1
READY FOR SM (AlertReason) -V2
UPDATE LOCATION
Time elapsed
Error, Abort, Reject, timeout
MWN “Information”
FORW.SHORT MSG (MWN) – V2
FORW.SHORT MSG (MWN) – V2
Forw.Short Message
SMS Delivery Error
SMS Delivery (MWN)
IIF GSM MSC/ VLR
MS
a
b
c c
d
e
f
g
①
②
h
i
j
k
l
m
n
SMS Delivery Ack
SMS Delivery (MWN)
N.S0028
Post Ballot Version 148
➀ At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification 1 is to be delivered to the Mobile Station. 2
3 b. The IIF originates an SMS with MWN information by sending Forward Short Message using MAP 4
V2 to the serving GSM MSC/VLR. The IIF is then acting as a GSM SMS-GMSC. The IIF is to 5 encode the MWN information in the SMS with three methods, namely, UDH, DCS, and CPHS. 6 See to Volume 3 for the encoding details. 7
8 c. The serving GSM MSC/VLR may attempt to deliver the short message or may immediately find 9
out that there is an error and reply (step e below) to the IIF. 10 11 d. The Mobile Station returns an error message to the SMS delivery. 12 13 e. The serving GSM MSC/VLR sends an Error, Abort or Reject message to the IIF, either resulting 14
from the reception of an error message from the MS or from an internal event such as an error or 15 a timeout. Note also, that a timeout may also occur in the IIF itself. Note that this may result in 16 the IIF setting the GSM 03.40 MNRF/MCEF flag depending on the error cause received (see 17 section 4.11.3.3 “Unsuccessful Mobile Terminated Delivery (Failure at MSC)”. 18
19 f. Time elapsed. 20 21 g. A new serving GSM MSC/VLR sends an Update Location message to the IIF acting as a GSM 22
HLR for that subscriber. Note that the normal Update Location sequence is not shown in this 23 diagram. Or it could be a 24
25 h. Ready for Short Message (MAP V2) or a 26 27 i. Note MS Present Message (MAP V1) 28 29 j. The IIF shall reply with the corresponding acknowledgement message. Note that in the case of 30
the Note MS Present message, there shall be no acknowledgement. Upon receipt of g, h, or i 31 above, the procedures in section 4.11.3.5 “Alerting for an ANSI-136 41 Subscriber in GSM 32 Foreign Mode” apply (GSM 03.40 flags may be cleared and the SMSNOT may be sent to the MC 33 if appropriate). 34
35 k. Triggered by event g, h, or i above, the IIF originates a new Forward Short Message with MWN 36
information to the serving GSM MSC/VLR. The IIF is to encode the MWN information in the SMS 37 with three methods, namely, UDH, DCS, and CPHS. See to Volume 3 for the encoding details. 38
39 l. The serving GSM MSC/VLR sends the short message with the MWN information to the mobile 40
station. 41 42 m. The mobile station acknowledges the delivery of the short message. 43 44 n. The serving GSM MSC/VLR sends the result of the Forward Short Message to the IIF. 45
➁ At this point, the IIF clears the MWN flag. The reception of the Forward Short Message Result 46 without error indicates that the MWN information was delivered successfully to the Mobile Station. 47
4.12.2 ANSI-41 Foreign Mode 48
For the native GSM subscribers roaming in ANSI-41 networks, there are two implementation options. 49 The GSM SMS containing the Message Waiting Notification information is either converted by the IIF 50 to a ANSI-41 Qualification Directive with Message Waiting Notification information as shown in 51 Section 4.12.2.1, or converted to a GHOST or WEMT ANSI-136 41 short message as shown in 52 Section 4.12.2.2. 53
54
N.S0028
Post Ballot Version 149
B.1.3.50 4.12.2.1 GSM SMS mapped to ANSI-41 Qualification Directive 1
2 3
N.S0028
Post Ballot Version 150
①
Vmail Delivery
FORW. MOBILE TERM SM (MWN)
SEND ROUTING INFO FOR SM (MWN) Send Routing Info for SM FORW. SHORT MESSAGE (MWN)
QUALDIR(MWNCOUNT, MWNTYPE)
(MWN delivered to Mobile Station)
Qualdir
Forw . Short Message (error: absent sub.) Forw . Mobile Term SM (error)
GSM SC
GSM SMS- GMSC
GSM HLR IIF
ANSI-41 MSC
a
b
c
d
e
f
g
h
i
j Report SM (error) DeliveryStatus k
1
①
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
TDMAMSC
a
b
c
d
e
f
g
h
i
jReport SM (error)DeliveryStatus k
2
Figure 99: GSM SMS mapped to ANSI-41 Qualification Directive 3
a. The GSM Service Center (SC) receives a voice mail for a specific subscriber. 4 5
N.S0028
Post Ballot Version 151
b. The SC sends the Forward Mobile Terminating Short Message with Message Waiting Notification 1 (MWN) information to the GSM SMS-GMSC. 2
3 c. The GSM SMS-GMSC enquires about the subscriber location by sending the Send Routing 4
Information For Short Message to the HLR. 5 6 d. The HLR replies with the Send Routing Information For Short Message result. It is assumed that 7
the native GSM subscriber has already made a registration in the ANSI-41 MSC/VLR. 8 9 e. The GSM SMS-GMSC originates an SMS with MWN information by sending Forward Short 10
Message to IIF then acting as a serving GSM MSC/VLR. This requires GSM MAP phase 2 or 11 higher. 12 13 ➀ At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification 14 is to be delivered to the Mobile Station. If the GSM SMS-GMSC only supports GSM MAP phase 1 15 and delivers MWN via pure text SMS, then a pure text SMS shall be delivered to the IIF. The IIF 16 shall then translate it into a CMT or GHOST/WEMT IS-136 SMS. Note that this then becomes a 17 simple SMS mapping covered in Section 4.12.2.2. 18
19 f. Upon reception of the Forward Short Message with MWN information, the IIF shall initiate a 20
Qualification Directive message with MWN information to the serving ANSI-41 MSC/VLR. The IIF 21 is then acting as an ANSI-41 HLR. The MWN information consists of two parameters: 22 MessageWaitingNotificationCount (MWNCOUNT) and MessageWaitingNotificationType 23 (MWNTYPE). For a description of these parameters, see to the ANSI-41-D specifications 24 sections 6.5.2.78 and 6.5.2.79 [1]. Alternatively, a GHOST/WEMT short message could be sent 25 instead of the Qualification Directive message (see Section 4.12.2.2) if the IIF has the possibility 26 to confirm that the Mobile Station is SMS-capable. 27
28 g. In this step, the MWN information shall be delivered to the mobile station. 29 30 h. The serving ANSI-41 MSC/VLR sends the Qualification Directive Return Result to the IIF. Note 31
that this result message does not guaranty that the MWN information was delivered successfully 32 to the Mobile Station, it just means that the MSC/VLR received the Qualification Directive 33 message, therefore the MWN flag shall not be cleared at this point by the IIF. 34
35 i. The IIF sends the result of the Forward Short Message to the GSM SMS-GMSC with error code 36
“absent subscriber” so that the home system assumes that the delivery failed in case the 37 subscriber goes back to the home system without having retrieved the mail messages. This way, 38 at the reception of the Update Location message, the HLR shall send an Alert-SC message so 39 that the MWN information (in a short message) is once again sent to the Mobile Station. 40
41 j. The SMS-GMSC sends the result of the Forward Mobile Terminating Short Message to the 42
Service Center. Note that depending on the Service Center implementation, this may cause the 43 SMS to be re-sent periodically instead of waiting for the ALERTSC message indicating that the 44 subscriber is again available to receive short messages. 45
46 k. The SMS-GMSC reports the error to the HLR, which shall set the proper flags as per GSM 03.40 47
[4] so that an Alert-SC message is sent when necessary as explained in step i above. 48
B.1.3.51 4.12.2.2 GSM SMS mapped to TDMA ANSI-41 SMS using GHOST or WEMT 49 Teleservice 50
This method uses the tunneling concept. Instead of translating the GSM SMS with Message Waiting 51 Notification information to an ANSI-41 Qualification Directive with MWN information, the IIF shall 52 package the GSM SMS into an ANSI-136 41 SMS with the new teleservice GHOST (GSM Hosted 53 SMS Teleservice) or WEMT. 54
N.S0028
Post Ballot Version 152
Event g only works with Mobile Stations (MS) capable of handling GHOST or WEMT. The MS shall 1 remove the ANSI-136 41 part of the message (the envelope) and send the GSM SMS Packet Data 2 Units (PDU) to the GSM part of the mobile station to handle the GSM SMS, in this case, containing 3 the Message Waiting Notification information. Specifically, the ANSI-41 MSC shall convert the 4 SMDPP to an R-DATA message which has a HLPI (higher layer protocol identifier) that indicates 5 GHOST/WEMT. The payload of the R-DATA message is the GSM SMS which is effectively identified 6 as the target application whenever HLPI = GHOST/WEMT. 7
8
N.S0028
Post Ballot Version 153
GSM SC
GSM SMS- GMSC
GSM HLR IIF
ANSI-41 MSC
a
b
c
d
e
f
g
h
i
j
FORW. TERM SM
SEND INFO FOR SM
Send Info for SM FORW. MESSAGE
SMDPP (MWN)
(SMS delivered Mobile Station)
smdpp
Forw . Mobile Term SM
Vmail Delivery
Forw . Short Message
1 GSMSC
GSMSMS-
GMSC
GSMHLR IIF
TDMAMSC
a
b
c
d
e
f
g
h
i
j
FORW. MOBILE TERM SM (MWN)
SEND ROUTINGINFO FOR SM (MWN)
Send Routing Info for SM
FORW. SHORT MESSAGE (MWN)
SMDPP (GHOST, MWN)
(SMS delivered toMobile Station)
smdpp (GHOST)
Forw. Mobile Term SM
VmailDelivery
Forw. Short Message
2
Figure 100: GSM SMS mapped to TDMA ANSI-41 using GHOST/WEMT Teleservice 3
N.S0028
Post Ballot Version 154
a. The GSM Service Center (SC) receives a voice mail for a specific subscriber. 1 2 b. The SC sends the Forward Mobile Terminating Short Message with Message Waiting Notification 3
(MWN) information to the GSM SMS-GMSC. 4 5 c. The GSM SMS-GMSC inquires about the subscriber location by sending the Send Routing 6
Information For Short Message to the HLR. 7 8 d. The HLR replies with the Send Routing Information For Short Message result. It is assumed that 9
the native GSM subscriber has already made a registration in the ANSI-41 MSC/VLR. 10 11 e. The GSM SMS-GMSC originates an SMS with MWN information by sending Forward Short 12
Message to IIF then acting as a serving GSM MSC/VLR. 13 14
This requires GSM MAP phase 2 or higher. If the GSM SMS-GMSC only supports GSM MAP 15 phase 1 and delivers MWN via pure text SMS, then a pure text SMS shall be delivered to the IIF. 16 The IIF shall then translate it into a CMT or GHOST/WEMT IS-136ANSI-41 SMS. Note that this 17 then becomes a simple SMS mapping covered in Section 4.11. 18
19 f. Upon reception of the Forward Short Message with MWN information, the IIF shall initiate a Short 20
Message Delivery Point to Point with Teleservice GHOST/WEMT to the serving ANSI-41 21 MSC/VLR. The IIF is then acting as an ANSI-136 41 Message Center (MC). Inside of this 22 GHOST/WEMT short message is the GSM short message containing the MWN information. 23
24 g. In this step, the GHOST/WEMT Short Message containing the GSM short message containing 25
the MWN information shall be delivered to the mobile station. 26 27 h. The serving ANSI-41 MSC/VLR sends the Short Message Delivery Point to Point Return Result 28
to the IIF. 29 30 i. The IIF sends the result of the Forward Short Message to the GSM SMS-GMSC. 31 32 j. The SMS-GMSC sends the result of the Forward Mobile Terminating Short Message to the 33
Service Center. 34
B.1.3.52 4.12.2.3 Clearing of MWN Information after Retrieval of Messages while in ANSI-35 41 Foreign Mode – QualDir Method 36
This section describes the case where the messages are retrieved while a GSM subscriber is still 37 roaming in ANSI-41 foreign mode. 38 39
N.S0028
Post Ballot Version 155
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
1
QUALDIR(MWNCOUNT,MWNTYPE)
(mwn delivered toMobile Station)
Qualdir
TDMAMSC
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: absent sub.)
Forw. Mobile Term SM (error)
GSMSC
GSMSMS-
GMSC
GSMHLR IIF
a
b
c
d
e
kReport SM (error)DeliveryStatus
2
Figure 101: Clearing of MWN Information after Retrieval of Messages while in ANSI-41 Foreign 3 mode – Qualdir Method 4
a. The voice mail messages are retrieved from the GSM subscriber. 5
N.S0028
Post Ballot Version 156
1 b. The SC sends the Forward Mobile Terminating Short Message with Message Waiting Notification 2
(MWN) information set to “clear” to the GSM SMS-GMSC. 3 4 c. The GSM SMS-GMSC enquires about the subscriber location by sending the Send Routing 5
Information For Short Message to the HLR. 6 7 d. The HLR replies with the Send Routing Information For Short Message result. It is assumed that 8
the native GSM subscriber has already made a registration in the ANSI-41 MSC/VLR. Another 9 requirement is that the Service Center sets the priority of this SMS to “high” to make sure that the 10 SMS is sent (Section 3.2.5 of GSM 03.40). This is necessary since the IIF had previously 11 responded with absent subscriber and the HLR had set some flags that could have prevented the 12 delivery of this new SMS. 13
14 e. The GSM SMS-GMSC originates an SMS with MWN information (set to “clear”) by sending 15
Forward Short Message to IIF then acting as a serving GSM MSC/VLR. This requires a GSM 16 phase 2 support or higher. 17
18 f. Upon reception of the Forward Short Message with MWN information (set to “clear”), the IIF shall 19
initiate a Qualification Directive message with MWN information (set to “clear”) to the serving 20 ANSI-41 MSC/VLR. The IIF is then acting as an ANSI-41 HLR. The MWN information consists of 21 two parameters: MessageWaitingNotificationCount (MWNCOUNT) and 22 MessageWaitingNotificationType (MWNTYPE). For a description of these parameters, see to the 23 ANSI-41-D specifications, sections 6.5.2.78 and 6.5.2.79 [1]. 24
25 g. In this step, the MWN information (set to “clear”) shall be delivered to the mobile station. 26 27 h. The serving ANSI-41 MSC/VLR sends the Qualification Directive Return Result to the IIF. Note 28
that this result message does not guaranty that the MWN information (set to ”clear”) was 29 delivered successfully to the Mobile Station, it just means that the MSC/VLR received the 30 Qualification Directive message, so the MWN flag shall not be cleared at this point by the IIF. 31
32 i. The IIF sends the result of the Forward Short Message to the GSM SMS-GMSC with error code 33
“absent subscriber” so that the home system assumes that the delivery failed in case the 34 subscriber goes back to the home system without having received the clearing notification from 35 the serving MSC. This way, at the reception of the Update Location message, the HLR shall send 36 an Alert-SC message so that the MWN information (in a short message) is once again sent to the 37 Mobile Station. 38
39 j. The SMS-GMSC sends the result of the Forward Mobile Terminating Short Message to the 40
Service Center. Note that depending on the Service Center implementation, this may cause the 41 SMS to be re-sent periodically instead of waiting for the ALERTSC message indicating that the 42 subscriber is again available to receive short messages. 43
44 k. The SMS-GMSC reports the error to the HLR, which shall set the proper flags as per GSM 03.40 45
[4] so that an Alert-SC message is sent when necessary as explained in step i above. 46 47
N.S0028
Post Ballot Version 157
B.1.3.53 4.12.2.4 Handling at SMS delivery failure at the IIF 1
2
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
f
g
hReport SM (error)DeliveryStatus
3
Figure 102: Handling at SMS delivery failure at the IIF 4
a. The GSM Service Center (SC) receives a voice mail for a specific subscriber. 5 6 b. The SC sends the Forward Mobile Terminating Short Message with Message Waiting Notification 7
(MWN) information to the GSM SMS-GMSC. 8 9 c. The GSM SMS-GMSC enquires about the subscriber location by sending the Send Routing 10
Information For Short Message to the HLR. 11 12 d. The HLR replies with the Send Routing Information For Short Message result. It is assumed that 13
the native GSM subscriber has already made a registration in the ANSI-41 MSC/VLR. 14 15 e. The GSM SMS-GMSC originates an SMS with MWN information by sending Forward Short 16
Message to IIF then acting as a serving GSM MSC/VLR. 17 18 f. Upon reception of the Forward Short Message with MWN information, the IIF encounters an error 19
and sends the result of the Forward Short Message to the GSM SMS-GMSC with the proper error 20 code as per GSM Specifications 09.02 [6]. 21
22 g. The SMS-GMSC sends the result of the Forward Mobile Terminating Short Message to the 23
Service Center. 24 25 h. The SMS-GMSC reports the error to the HLR, which sets the proper flags as per GSM 03.40 [4] 26
so that an Alert-SC message is sent when necessary. 27 28
N.S0028
Post Ballot Version 158
B.1.3.54 4.12.2.5 Handling at SMS delivery failure at the MSC/VLR – QualDir Method 1
2
Vmail Delivery
FORW. MOBILE TERM SM (MWN)
SEND ROUTING INFO FOR SM (MWN) Send Routing Info for SM FORW. SHORT MESSAGE (MWN)
QUALDIR(MWNCOUNT, MWNTYPE)
Qualdir Return Error
GSM SC
GSM SMS- GMSC
GSM HLR IIF
ANSI-41 MSC
a
b
c
d
e
f
g
h
i
Forw . Short Message (error) Forw . Mobile Term SM (error)
①
j Report SM (error) DeliveryStatus
3
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
TDMAMSC
a
b
c
d
e
f
g
h
i
Forw. Short Message (error)
Forw. Mobile Term SM (error)
①
j
Report SM (error)DeliveryStatus
4
Figure 103: Handling at SMS delivery failure at the MSC/VLR Qualdir Method 5
a. The GSM Service Center (SC) receives a voice mail for a specific subscriber. 6 7
N.S0028
Post Ballot Version 159
b. The SC sends the Forward Mobile Terminating Short Message with Message Waiting Notification 1 (MWN) information to the GSM SMS-GMSC. 2
3 c. The GSM SMS-GMSC inquires about the subscriber location by sending the Send Routing 4
Information for Short Message to the HLR. 5 6 d. The HLR replies with the Send Routing Information for Short Message result. It is assumed that 7
the native GSM subscriber has already made a registration in the ANSI-41 MSC/VLR. 8 9 e. The GSM SMS-GMSC originates an SMS with MWN information by sending Forward Short 10
Message to IIF then acting as a serving GSM MSC/VLR. This requires GSM phase 2 support or 11 higher. 12 ① At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification 13 is to be delivered to the Mobile Station. 14
15 f. The IIF shall also initiate a Qualification Directive message with MWN information to the serving 16
ANSI-41 MSC/VLR. The IIF is then acting as an ANSI-41 HLR. The MWN information consists of 17 two parameters: MessageWaitingNotificationCount (MWNCOUNT) and 18 MessageWaitingNotificationType (MWNTYPE). For a description of these parameters, see to the 19 ANSI-41-D specifications, sections 6.5.2.78 and 6.5.2.79 [1]. 20
21 g. The serving ANSI-41 MSC/VLR encounters an error and sends the Qualification Directive Return 22
Error to the IIF, as per the ANSI-41 Specifications, Chapter 6, Section 4.32.2, Table 42. 23 h. The IIF sends the error result of the Forward Short Message to the GSM SMS-GMSC. 24 25 i. The SMS-GMSC sends the result of the Forward Mobile Terminating Short Message to the 26
Service Center. 27 28
j. The SMS-GMSC reports the error to the HLR which sets the proper flags as per GSM 03.40 [4] 29 so that an Alert-SC message is sent when necessary. 30
31
B.1.3.55 4.12.2.6 Handling at SMS delivery failure at the MSC/VLR – GHOST/WEMT SMS 32 Method 33
34
N.S0028
Post Ballot Version 160
VmailDelivery
FORW. MOBILE TERM SM (MWN)
SEND ROUTINGINFO FOR SM (MWN)
Send Routing Info for SM
FORW. SHORT MESSAGE (MWN)
GSMSC
GSMSMS-GMSC
GSMHLR IIF
TDMAMSC
a
b
c
d
e
f
g
h
i
j
Forw. Short Message (error)
Forw. Mobile Term SM (error)
Report SM (error)DeliveryStatus
SMDPP (GHOST, MWN)
smdpp (error)
1
Figure 104: Handling at SMS delivery failure at the MSC/VLR – GHOST/WEMT SMS Method 2
a. The GSM Service Center (SC) receives a voice mail for a specific subscriber. 3 4 b. The SC sends the Forward Mobile Terminating Short Message with Message Waiting Notification 5
(MWN) information to the GSM SMS-GMSC. 6 7 c. The GSM SMS-GMSC inquires about the subscriber location by sending the Send Routing 8
Information for Short Message to the HLR. 9 10 d. The HLR replies with the Send Routing Information for Short Message result. It is assumed that 11
the native GSM subscriber has already made a registration in the ANSI-41 MSC/VLR. 12 13 e. The GSM SMS-GMSC originates an SMS with MWN information by sending Forward Short 14
Message to IIF then acting as a serving GSM MSC/VLR. This requires GSM phase 2 support or 15 higher. 16
17 f. Upon reception of the Forward Short Message with MWN information, the IIF shall initiate a Short 18
Message Delivery Point to Point with Teleservice GHOST/WEMT to the serving ANSI-41 19 MSC/VLR. The IIF is then acting as an ANSI-136 41 Message Center (MC). Inside of this GHOST 20 or WEMT short message is the GSM short message containing the MWN information. 21
22 g. The serving ANSI-41 MSC/VLR encounters an error and sends the Short Message Delivery Point 23
to Point Return error to the IIF. 24 25 h. The IIF sends the result of the Forward Short Message to the GSM SMS-GMSC with the proper 26
error code. . 27 28 i. The SMS-GMSC sends the result of the Forward Mobile Terminating Short Message to the 29
Service Center. 30
N.S0028
Post Ballot Version 161
1 j. The SMS-GMSC shall report the error to the HLR. 2
3
N.S0028
Post Ballot Version 162
B.1.3.56 4.12.2.7 GSM SMS mapped to ANSI-41 Qualification Directive and to 1 Registration Notification Return Result 2
3
N.S0028
Post Ballot Version 163
①
Vmail Delivery
FORW. MOBILE TERM SM (MWN)
SEND ROUTING INFO FOR SM (MWN) Send Routing Info for SM FORW. SHORT MESSAGE (MWN) QUALDIR
(MWNCOUNT, MWNTYPE)
(MWN delivered to Mobile Station)
Forw . Short Message (error: absent sub.) Forw . Mobile Term SM (error)
GSM SC
GSM SMS-
GMSC
GSM HLR
IIF ANSI-41 MSC 1
a
b
c
d
e
f
g
h
i
j Report SM (error) DeliveryStatus k
l
j
Time elapsed
(MWN delivered to Mobile Station)
REGNOT m
n
o
Regnot (MWNCOUNT, MWNTYPE)
ANSI-41 MSC 2
1
N.S0028
Post Ballot Version 164
①
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 TDMAMSC 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)
TDMAMSC 2
1
Figure 105: GSM SMS mapped to ANSI-41 Qualification Directive and to Registration 2 Notification Return Result 3
a. The GSM Service Center (SC) receives a voice mail for a specific subscriber. 4 5 b. The SC sends the Forward Mobile Terminating Short Message with Message Waiting Notification 6
(MWN) information to the GSM SMS-GMSC 7 8 c. The GSM SMS-GMSC inquires about the subscriber location by sending the Send Routing 9
Information For Short Message to the HLR. 10 11 d. The HLR replies with the Send Routing Information For Short Message result. It is assumed that 12
the native GSM subscriber has already made a registration in the ANSI-41 MSC/VLR. 13 14 e. The GSM SMS-GMSC originates an SMS with MWN information by sending Forward Short 15
Message to IIF then acting as a serving GSM MSC/VLR. This requires GSM phase 2 support or 16 higher. 17 ① At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification 18 is to be delivered to the Mobile Station. If the handset only supports GSM phase 1, then a pure 19 text SMS shall be delivered to the IIF. The IIF shall then translate it into a CMT or GHOST/WEMT 20 IS-136ANSI-41 SMS. Note that this then becomes a simple SMS mapping covered in Section 21 4.11. 22
N.S0028
Post Ballot Version 165
1 f. Upon reception of the Forward Short Message with MWN information, the IIF shall initiate a 2
Qualification Directive message with MWN information to the serving ANSI-41 MSC/VLR. The IIF 3 is then acting as an ANSI-41 HLR. The MWN information consists of two parameters: 4 MessageWaitingNotificationCount (MWNCOUNT) and MessageWaitingNotificationType 5 (MWNTYPE). For a description of these parameters, see to the ANSI-41 specifications, sections 6 6.5.2.78 and 6.5.2.79 [1]. Alternatively, a GHOST/WEMT short message could be sent instead of 7 the Qualification Directive message (see Section 4.12.2.2) if the IIF has the possibility to confirm 8 that the Mobile Station is SMS-capable. 9
10 g. In this step, the MWN information shall be delivered to the mobile station. 11 12 h. The serving ANSI-41 MSC/VLR sends the Qualification Directive Return Result to the IIF. Note 13
that this result message does not guaranty that the MWN information was delivered successfully 14 to the Mobile Station, it just means that the MSC/VLR received the Qualification Directive 15 message, therefore the MWN flag shall not be cleared at this point by the IIF. 16
17 i. The IIF sends the result of the Forward Short Message to the GSM SMS-GMSC with error code 18
“absent subscriber” so that the home system assumes that the delivery failed in case the 19 subscriber goes back to the home system without having retrieved the mail messages. This way, 20 at the reception of the Update Location message, the HLR shall send an Alert-SC message so 21 that the MWN information (in a short message) is once again sent to the Mobile Station. 22
23 j. The SMS-GMSC sends the result of the Forward Mobile Terminating Short Message to the 24
Service Center. Note that depending on the Service Center implementation, this may cause the 25 SMS to be re-sent periodically instead of waiting for the ALERTSC message indicating that the 26 subscriber is again available to receive short messages. 27
28 k. The SMS-GMSC reports the error to the HLR, which sets the proper flags as per GSM 03.40 [4] 29
so that an Alert-SC message is sent when necessary as explained in step i above. 30 31 l. Time elapses before the MS re-registers. 32 33 m. A Registration Notification is sent from the serving ANSI-41 MSC 2 to the IIF. 34 35 n. The IIF discovers that the MWN flag is still set. The IIF sends back the MWN in the Registration 36
Notification Return Result along with the other registration information (e.g. other Profile 37 parameters) to the serving ANSI-41 MSC/VLR. The IIF is then acting as an ANSI-41 HLR. The 38 MWN information consists of two parameters: MessageWaitingNotificationCount (MWNCOUNT) 39 and MessageWaitingNotificationType (MWNTYPE). For a description of these parameters, see to 40 the ANSI-41 specifications, sections 6.5.2.78 and 6.5.2.79 [1]. 41
42 o. In this step, the MWN information shall be delivered to the mobile station. Since there is no 43
acknowledgement from the regnot Return Result, there is no guarantee that the MWN information 44 was delivered successfully to the Mobile Station. The MWN flag shall not be cleared at this point 45 by the IIF. 46
47
N.S0028
Post Ballot Version 166
4.13 GPRS in GSM Foreign Mode 1
This section describes the support of GPRS service for ANSI-136 41 subscribers roaming in a GSM 2 radio environment. 3
To support multiple network configuration requirements this standard defines several optional 4 capabilities 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 subscription 6 data. The services to be provided are provisioned in the IIF by means outside the scope of this 7 standard. 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 GSM network 9 through either a GSM MSC (for GSM-CS service) or an SGSN (for GPRS service) or through both. 10 The attachments may be done in series, i.e. first one service and then another, or simultaneously. 11
The IIF may implement a timer, GPRS_LU, to reduce the number of location updates in the ANSI-41 12 network when an MS is capable of both MSC-CS and GPRS services. If the timer is supported, then 13 when a Location Update is received from the SGSN for an MS that is capable of both GSM_CS and 14 GPRS service, the IIF starts the timer and then performs the ‘Insert Subscriber Data’ procedure to the 15 SGSN. The IIF sends the REGNOT to the HLR only after the expiry of the timer or the receipt of the 16 Location Update from the GSM MSC. 17
When the timer is not started, either because : 18
- it is not supported; or 19
- the MS is provisioned for GPRS only service; or 20
- the MS is already CS attached; or 21
- the IIF does not support multiple MSCIDs; 22
then the IIF sends the REGNOT to the HLR and waits for a response before performing the ‘Insert 23 Subscriber Data’ procedure to the SGSN. 24
The IIF may support multiple MSCIDs to separately identify each GSM MSC and each SGSN when 25 an MS is attached for either or both services. When multiple MSCIDs are supported the IIF shall 26 notify the ANSI-41 HLR whenever the MS registers on a different SGSN, GSM MSC or both. 27
An IIF that does not support multiple MSCIDs shall always convey its own identity towards the ANSI-28 41 HLR. 29
Subscriber Data Management procedures shall follow similar procedures as described in 4.4.2. In 30 the case of subscriber deletion, it shall also result in the deletion of any GPRS subscription data in the 31 IIF, for that subscriber. In this case, the IIF shall also send a Cancel Location Request to the serving 32 SGSN. The ANSI-41 HLR does not have the capability to request the modification of GPRS 33 subscription data in the IIF. Modification of GPRS subscriber data in the IIF shall be in accordance 34 with GSM 09.02 [6] via an OMC directly connected to the IIF. 35
4.13.1 Location Registration ScenariosIn each of the following scenarios, the following 36 interactions are not shown :- 37
Interactions between SGSNs 38
Interactions between SGSNs and GGSNs 39
Existing procedures defined in GSM 03.60 [10], describing the actions between SGSNs or between 40 an SGSN and a GGSN for scenarios involving interaction between those functional elements also 41 apply. 42
N.S0028
Post Ballot Version 167
Existing procedures and timers defined in GSM 03.60 [10], describing the actions between the SGSN 1 and the GSM HLR also apply between the SGSN and the IIF (emulating a GSM HLR). 2
The combined attach and location registration procedures described, require support of the optional 3 Gs interface as described in GSM 03.60[10]. 4
It should be noted that certain scenarios may only be relevant to certain MS types. For a full 5 description of the various MS types see GSM 03.60 [10]. 6
4.13.1.1 GPRS Attach (not currently registered) 7
If an MS requests GPRS service when currently not registered in the IIF, the MS performs a GPRS 8 attach request using its IMSI. The IIF acts like a GPRS HLR/AuC in this case. The subscriber's 9 ANSI-41 HLR has no knowledge of this request, but the IIF makes it aware of the attachment to an 10 SGSN via a REGNOT. If timer GPRS_LU is used then the message flow is as shown in Figure 106. 11 If timer GPRS_LU is not used then the message flow is as shown in Figure 107. 12
Figure 106: GPRS Attach (Option1: with timer) 13
a. MS performs a GPRS Attach. . 14
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to 15 perform authentication i.e. authentication triplets, it requests authentication information from the 16 IIF. The IIF emulates a GSM HLR/AuC in this case supporting GPRS. 17
MS SGSN IIF HLR
GPRS Attach Req
Authentication Info
Authentication Info Ack
Authentication Req
Authentication Res
Update GPRS Location Req
GSM NETWORKANSI-41 NETWORK
Insert Sub Data
Insert Sub Data Ack
Update GPRS Location Ack
GPRS Attach Ack
(IMSI)
(IMSI, SGSN Address)
a
b
c
d
e
f
g
h
i
jREGNOT
regnotk
GPRS_LU
l
N.S0028
Post Ballot Version 168
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 Location 4 Request contains the IMSI. 5
g. The IIF validates whether the GPRS service request is authorized. Since GPRS service is 6 requested, and the subscriber is currently PS-deregistered, it initiates the GSM MAP Insert 7 Subscriber Data Procedure towards the SGSN after the subscriber has been successfully 8 authorized. This procedure is used to download GPRS subscriber data to the SGSN. Multiple 9 Insert Subscriber Data transactions may be necessary to complete the transfer of subscriber data 10 to the SGSN. 11
h. The SGSN acknowledges the ISD Operation(s). 12
i. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF 13 returns an acknowledgement to the Update GPRS Location Request. 14
j. After the IIF’s GPRS_LU timer expires, the IIF shall send a registration notification (REGNOT) to 15 the ANSI-41 HLR. The REGNOT shall contain the MSID (MIN/IMSI), the ESN , the MSCID , etc. 16 If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall be 17 passed in the REGNOT to the subscriber’s HLR. The ANSI-41 HLR records the address of the IIF 18 as the serving ANSI-41 MSC. Although call delivery may not be possible, SMS delivery is made 19 possible by registering the IIF as the ANSI-41 MSC with the ANSI-41 HLR. 20
k. The ANSI-41 HLR sends an acknowledgment to the registration with a regnot. The IIF may 21 ignore the CS-related profile information, since the subscriber is only GPRS-attached (and not 22 GSM CS-attached). Only the provisioned SMS parameters in the regnot (profile) may be mapped 23 and sent to the SGSN in an Insert Subscriber Data message (e.g., as in the next figure). 24 (Alternatively, SMS parameters related to GPRS could be provisioned directly on the IIF and sent 25 to the SGSN in step g.) 26
If a negative regnot response is received from the ANSI-41 HLR, (then as a Network option) the 27 IIF may perform an initiated detach procedure as described in section 4.13.2.6. 28
l. The SGSN acknowledges the GPRS Attach Request. 29
30
N.S0028
Post Ballot Version 169
Figure 107: GPRS Attach (Option 2: without timer) 1
2
a. MS performs a GPRS Attach. 3
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to 4 perform authentication i.e. authentication triplets, it requests authentication information from the 5 IIF. 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 Location 10 Request contains the IMSI. 11
g. The REGNOT shall contain the MSID (MIN/IMSI), the ESN, the MSCID etc. If SIM-based roaming 12 is authorized, an initially provisioned, fixed ESN for this subscriber shall be passed in the 13 REGNOT to the subscriber’s HLR. The ANSI-41 HLR records the address of the IIF as the 14 serving ANSI-41 MSC. Although call delivery may not be possible, SMS delivery is made 15 possible by registering the IIF as the ANSI-41 MSC with the ANSI-41 HLR. 16
h. The ANSI-41 HLR sends an acknowledgment to the registration with a regnot. The IIF may 17 ignore the CS-related profile information, since the MS is only GPRS-attached (and not GSM CS-18 attached). Only the provisioned SMS parameters in the regnot (profile) may be mapped and sent 19 to the SGSN in an Insert Subscriber Data message. 20
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
N.S0028
Post Ballot Version 170
i. The IIF validates whether the GPRS service request is authorized. Since GPRS service is 1 requested, and the subscriber is currently PS-deregistered, it initiates the GSM MAP Insert 2 Subscriber Data Procedure towards the SGSN after the subscriber has been successfully 3 authorized. This procedure is used to download GPRS subscriber data to the SGSN. Multiple 4 Insert Subscriber Data transactions may be necessary to complete the transfer of subscriber data 5 to the SGSN. 6
j. The SGSN acknowledges the ISD Operation(s). 7
k. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF 8 returns an acknowledgement to the Update GPRS Location Request. 9
l. The SGSN acknowledges the GPRS Attach request. 10
11
N.S0028
Post Ballot Version 171
4.13.1.2 GPRS Attach when currently registered in an ANSI-41 network 1
If an MS requests GPRS service when currently registered in an ANSI-41 network, the SGSN sends 2 an Update GPRS location update using its IMSI. The IIF acts like a GPRS HLR/AuC and an ANSI-41 3 VLR in this case. To the subscriber's ANSI-41 HLR, the subscriber becomes registered on the IIF 4 acting as an ANSI-41 MSC. If timer GPRS_LU is used then the message flow is as shown in Figure 5 108. If timer GPRS_LU is not used then the message flow is as shown in Figure 109. 6
Figure 108: GPRS Attach when currently registered in ANSI-41 (Option 1: with timer) 7
8 a. MS performs a GPRS Attach. 9
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to 10 perform authentication i.e. authentication triplets, it requests authentication information from the 11 IIF. The IIF emulates a GSM HLR/AuC in this case supporting GPRS. 12
c. The IIF returns the necessary authentication information, if applicable. 13
d. SGSN initiates authentication towards the MS. 14
e. MS responds to the authentication request. 15
f. SGSN initiates a MAP GPRS location update towards the IIF. The Update GPRS Location 16 Request contains the IMSI. 17
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 NETWORK
N.S0028
Post Ballot Version 172
g. The IIF validates whether the GPRS service request is authorized. Since GPRS service is 1 requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert Subscriber 2 Data Procedure towards the SGSN after the subscriber has been successfully authorized. This 3 procedure is used to download GPRS subscriber data to the SGSN. Multiple Insert Subscriber 4 Data transactions may be necessary to complete the transfer of subscriber data to the SGSN. 5
h. The SGSN acknowledges the ISD Operation(s). 6
i. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF 7 returns an acknowledgement to the Update GPRS Location Request. 8
j. After the IIF’s GPRS_LU timer expires, the IIF shall send a registration notification (REGNOT) 9 to the ANSI-41 HLR. The REGNOT shall contain the MSID (MIN/IMSI), the ESN, the MSCID, 10 etc. If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber 11 shall be passed in the REGNOT to the subscriber’s HLR. The ANSI-41 HLR records the 12 address of the IIF as the serving ANSI-41 MSC. Although call delivery may not be possible, 13 SMS delivery is made possible by registering the IIF as the ANSI-41 MSC with the ANSI-41 14 HLR. 15
k. The ANSI-41 HLR updates its location information and deletes the previous VLR record by 16 sending a REGCANC to the previous MSC/VLR. 17
l. The VLR acknowledges the REGCANC. 18
m. The ANSI-41 HLR sends an acknowledgment to the registration with a regnot. The IIF may 19 ignore the CS-related profile information, since the MS is only GPRS-attached (and not GSM 20 CS-attached). 21
If a negative regnot response is received from the ANSI-41 HLR, (then as a Network option) the 22 IIF may perform an initiated detach procedure as described in section 4.13.2.6. 23
n. The SGSN acknowledges the GPRS Attach request. 24
25
N.S0028
Post Ballot Version 173
Figure 109: GPRS Attach when currently registered in ANSI-41 (Option 2: without timer) 1
2 a. MS performs a GPRS Attach. . 3
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to 4 perform authentication i.e. authentication triplets, it requests authentication information from the 5 IIF. 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 Location 10 Request contains the IMSI. 11
g. The REGNOT shall contain the MSID (MIN/IMSI), the ESN, the MSCID, etc. If SIM-based 12 roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall be passed in the 13 REGNOT to the subscriber’s HLR. The ANSI-41 HLR records the address of the IIF as the 14
MS SGSN IIF HLR
GPRS Attach Req
Authentication Info
Authentication Info Ack
Authentication Req
Authentication Res
Update GPRS Location Req
REGNOT
regnot
GSM NETWORK ANSI-41 NETWORK
Insert Sub Data
Insert Sub Data Ack
Update GPRS Location Ack
GPRS Attach Ack
MSC/VLR
REGCAN
regcan
(IMSI)
(IMSI, SGSNAddress)
(MSID, ESNF,MSCID or MSCIN)
a
b
c
d
e
f
g
h
i
j
k
l
m
n
N.S0028
Post Ballot Version 174
serving ANSI-41 MSC. Although call delivery may not be possible, SMS delivery is made 1 possible by registering the IIF as the ANSI-41 MSC with the ANSI-41 HLR. 2
h. The ANSI-41 HLR updates its location information and deletes the previous VLR record by 3 sending a REGCANC to the previous MSC/VLR. 4
i. The VLR acknowledges the REGCANC. 5
j. The ANSI-41 HLR sends an acknowledgment to the registration with a regnot. 6
k. The IIF validates whether the GPRS service request is authorized. Since GPRS service is 7 requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert Subscriber 8 Data Procedure towards the SGSN after the subscriber has been successfully authorized. This 9 procedure is used to download GPRS subscriber data to the SGSN. Multiple Insert Subscriber 10 Data transactions may be necessary to complete the transfer of subscriber data to the SGSN. 11
l. The SGSN acknowledges the ISD Operation(s). 12
m. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF 13 returns an acknowledgement to the Update GPRS Location Request. 14
n. The SGSN acknowledges the GPRS Attach request. 15 16
17
N.S0028
Post Ballot Version 175
4.13.1.3 Inter-SGSN routing area update 1
If an MS requests a GPRS routing area update while registered on a GPRS SGSN only. The 2 message flow is as shown in Figure 110 and 111, depending on whether the timer GPRS_LU is 3 supported 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 to 7 perform authentication i.e. authentication triplets, it requests authentication information from the 8 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 Location 13 Request contains the IMSI. The IIF starts the GPRS_LU timer. 14
g. The IIF (acting like a GPRS HLR) shall also send 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
GPRS_LU
inter-SGSN Routing Area Update Acceptp
N.S0028
Post Ballot Version 176
h. The IIF shall receive a Cancel Location acknowledgement from the previous SGSN. 1
i. The IIF validates whether the GPRS service request is authorized. Since GPRS service is 2 requested, it initiates the GSM MAP Insert Subscriber Data Procedure towards the SGSN after 3 the subscriber has been successfully authorized. This procedure is used to download GPRS 4 subscriber data to the SGSN. Multiple Insert Subscriber Data transactions may be necessary to 5 complete the transfer of subscriber data to the SGSN. 6
j. The SGSN acknowledges the ISD Operation(s). 7
k. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF 8 returns an acknowledgement to the Update GPRS Location Request. 9
Note: Steps l,m,n & o are optional depending on whether the IIF supports multiple MSCIDs. 10
l. After the IIF’s GPRS_LU timer expires, the IIF shall send a registration notification (REGNOT) to 11 the ANSI-41 HLR. The REGNOT shall contain the MSID (MIN/IMSI), the ESN, the MSCID, etc. If 12 SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall be 13 passed in the REGNOT to the subscriber’s HLR. The ANSI-41 HLR records the address of the IIF 14 as the serving ANSI-41 MSC. Although call delivery may not be possible, SMS delivery is made 15 possible by registering the IIF as the ANSI-41 MSC with the ANSI-41 HLR. 16
m. The HLR updates its location information and deletes the previous VLR record by sending a 17 REGCANC to the previous MSC/VLR, which in this case is the IIF (if in step l, the IIF sent a 18 REGNOT with a different MSCID (IIF address corresponding to the current SGSN) than the 19 MSCID sent corresponding to the previous SGSN). 20
n. The IIF acknowledges the REGCANC. 21
o. The ANSI-41 HLR sends an acknowledgment to the registration with a regnot. The IIF may 22 ignore the CS-related profile information, since the MS is only GPRS-attached (and not GSM CS-23 attached). 24
25
N.S0028
Post Ballot Version 177
Related to Figure 110, if a negative regnot response is received from the ANSI-41 HLR, (then as 1 a Network option) the IIF may perform an initiated detach procedure as described in section 2 4.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 in order 7 to perform authentication i.e. authentication triplets, it requests authentication information 8 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 Location 13 Request contains the IMSI. 14
g. The IIF sends a Cancel Location to the previous SGSN. 15
h. IIF shall receive an acknowledgement for the Cancel Location. 16
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
N.S0028
Post Ballot Version 178
i. If the IIF implementation supports multiple MSCIDs, then it shall send a REGNOT to the 1 ANSI-41 HLR with the MSCID corresponding to the new SGSN. Then the IIF shall correlate 2 that MSCID with the GSM MSCID when receiving mobile terminated SMS messages (so that 3 the IIF can deliver them to the SGSN). 4
j. This is a continuation of the optional procedure started in item i. IIF receives REGCANC. The 5 IIF needs to keep both the current MSCID associated to the SGSN as well as the current 6 MSCID associated to the MSC. The IIF must also keep a record of the last MSCID which 7 was sent to the ANSI-41 HLR to know that is the one stored in the ANSI-41 HLR. 8
k. This is a continuation of the optional procedure started in item i. IIF sends regcanc response. 9
l. This is a continuation of the optional procedure started in item i. IIF receives regnot 10 response. 11
m. The IIF validates whether the GPRS service request is authorized. Since GPRS service is 12 requested, it initiates the GSM MAP Insert Subscriber Data Procedure towards the SGSN 13 after the subscriber has been successfully authorized. This procedure is used to download 14 GPRS subscriber data to the SGSN. Multiple Insert Subscriber Data transactions may be 15 necessary to complete the transfer of subscriber data to the SGSN. 16
n. The SGSN acknowledges the ISD Operation(s). 17
o. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the 18 IIF returns an acknowledgement to the Update GPRS Location Request. 19
p. The SGSN acknowledges the Routing Area Update request. 20
21 22
N.S0028
Post Ballot Version 179
4.13.1.4 GPRS- Attach when only GSM CS Attached 1
If an MS roams while registered in a GSM serving MSC, and the MS requests GPRS attach, the MS 2 performs a GPRS attach and the network responds as shown in Figure 112. Note that the GSM MSC 3 does not update the IIF (emulating the GSM HLR). The serving MSC remains constant. 4
Figure 112: GPRS Attach when GSM CS Attached. 5
a. MS performs a GPRS Attach. 6
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to 7 perform authentication i.e. authentication triplets, it requests authentication information from the 8 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 Location 13 Request contains the IMSI. 14
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
N.S0028
Post Ballot Version 180
g. If the IIF implementation supports multiple MSCIDs, then it shall send a REGNOT to the ANSI-41 1 HLR with the MSCID corresponding to the new SGSN. 2
h. This is a continuation of the optional procedure started in item g. IIF receives REGCANC. 3
i. This is a continuation of the optional procedure started in item g. IIF sends regcanc response. 4
j. This is a continuation of the optional procedure started in item g. IIF receives regnot response.] 5
k. The IIF validates whether the GPRS service request is authorized. Since GPRS service is 6 requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert Subscriber 7 Data Procedure towards the SGSN after the subscriber has been successfully authorized. This 8 procedure is used to download GPRS subscriber data to the SGSN. Multiple Insert Subscriber 9 Data transactions may be necessary to complete the transfer of subscriber data to the SGSN. 10
l. The SGSN acknowledges the ISD Operation(s). 11
m. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF 12 returns an acknowledgement to the Update GPRS Location Request. 13
n. The SGSN sends a BSSAP+LocationUpdateRequest to the GSM MSC over the Gs interface. 14 The GSM MSC creates the association with the SGSN by storing the SGSN Number. The MSC 15 does not see a need to notify the IIF (emulating the GSM HLR, since there is no change to the 16 CS location update parameters). 17
o. The GSM MSC acknowledges the BSSAP+LocationUpdateRequest over the Gs interface by 18 sending the Accept message. 19
p. The SGSN acknowledges the GPRS Attach request from the MS. 20
21
22
N.S0028
Post Ballot Version 181
1
4.13.1.5 Combined GSM and GPRS attach when not currently registered 2
If an MS requests a combined GSM and GPRS attach when not registered in the IIF, then the SGSN 3 first requests a GPRS location update to the IIF (acting as a GPRS HLR) and then a CS location 4 update through the GSM MSC as depicted in Figure 114. 5
6 Figure 113: Combined GPRS and GSM attach (Option 1: With timer). 7
a. MS performs a GPRS attach. 8
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to 9 perform authentication i.e. authentication triplets, it requests authentication information from the 10 IIF. The IIF emulates a GSM HLR/AuC in this case supporting GPRS. 11
c. The IIF returns the necessary authentication information, if applicable. 12
d. SGSN initiates authentication towards the MS. 13
e. MS responds to the authentication request. 14
f. SGSN initiates a MAP GPRS location update towards the IIF. The Update GPRS Location 15 Request contains the IMSI. The IIF starts timer GPRS LU. 16
g. The IIF validates whether the GPRS service request is authorized. Since GPRS service is 17 requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert Subscriber 18
Combined Attach Req (IMSI)
MS SGSNMSC IIF
Authentication Info
Authentication Info AckAuthentication Req
Authentication Res
a
b
cd
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 ackUpdate Location ack
q
r
BSSAP+-Location Update AcceptCombined Attach Accept
GSM NETWORK ANSI-41 NETWORK
N.S0028
Post Ballot Version 182
Data Procedure towards the SGSN after the subscriber has been successfully authorized. This 1 procedure is used to download GPRS subscriber data to the SGSN. Multiple Insert Subscriber 2 Data transactions may be necessary to complete the transfer of subscriber data to the SGSN. 3
h. The SGSN acknowledges the ISD Operation(s). 4
i. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF 5 returns an acknowledgement to the Update GPRS Location Request. 6
j. The SGSN sends a BSSAP+LocationUpdateRequest to the GSM MSC over the Gs interface. 7 The GSM MSC creates the association with the SGSN by storing the SGSN Number. 8
k. The MSC determines that it needs to notify the IIF (emulating the GSM HLR), since there is a 9 change to the CS location update parameters. The MSC sends the Update Location operation to 10 the IIF (emulating the GSM HLR). The IIF stops timer GPRS LU. 11
l. The IIF shall send a Registration Notification (REGNOT) to the ANSI-41 HLR to indicate the 12 changed location (MSCID associated with the new GSM MSC). 13
If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall be 14 passed in the REGNOT to the subscriber’s HLR. This ESN may not match the currently validated 15 dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for this subscriber. 16
m. The ANSI-41 HLR acknowledges the registration and sends back the subscriber’s information. 17 This information is for non-GPRS services. 18
n. The IIF sends MAP INSERT SUBSCRIBER DATA message(s) to the GSM MSC providing GSM 19 CS information based on the contents of the regnot (profile). 20
o. The GSM MSC acknowledges receipt of the Insert Subscriber Data information. 21
p. The IIF acknowledges the completion of the Update Location procedure and sends the Update 22 Location Acknowledgement to the GSM MSC. 23
q. The GSM MSC acknowledges the BSSAP+LocationUpdateRequest over the Gs interface to the 24 SGSN by sending the Accept message. 25
r. The SGSN acknowledges the combined GPRS and GSM Attach request from the MS. 26
27
28
N.S0028
Post Ballot Version 183
Figure 114: Combined GPRS and GSM attach (Option 2: Without timer and without support for 1 multiple MSCIDs). 2
3
Combined Attach Req (IMSI)
MS SGSNMSC IIF
Authentication Info
Authentication Info AckAuthentication Req
Authentication Res
a
b
cd
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 DataISD ack
Update Location ack
q
r
BSSAP+-Location Update AcceptCombined Attach Accept
GSM NETWORK ANSI-41 NETWORK
REGNOT
Regnot ack
N.S0028
Post Ballot Version 184
a. MS performs a GPRS attach. 1
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to 2 perform authentication i.e. authentication triplets, it requests authentication information from the 3 IIF. 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 Location 8 Request contains the IMSI. 9
g. The IIF shall send a Registration Notification (REGNOT) to the ANSI-41 HLR to indicate the 10 changed location. 11
If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall be 12 passed in the REGNOT to the subscriber’s HLR. This ESN may not match the currently validated 13 dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for this subscriber. 14
h. The ANSI-41 HLR acknowledges the registration and sends back the subscriber’s information in 15 the regnot response. 16
i. The IIF validates whether the GPRS service request is authorized. Since GPRS service is 17 requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert Subscriber 18 Data Procedure towards the SGSN after the subscriber has been successfully authorized. This 19 procedure is used to download GPRS subscriber data to the SGSN. Multiple Insert Subscriber 20 Data transactions may be necessary to complete the transfer of subscriber data to the SGSN. 21
j. The SGSN acknowledges the ISD Operation(s). 22
k. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF 23 returns an acknowledgement to the Update GPRS Location Request. 24
l. The SGSN sends a BSSAP+LocationUpdateRequest to the GSM MSC over the Gs interface. 25 The GSM MSC creates the association with the SGSN by storing the SGSN Number. 26
m. The MSC determines that it needs to notify the IIF (emulating the GSM HLR), since there is a 27 change to the CS location update parameters. The MSC sends the Update Location operation to 28 the IIF (emulating the GSM HLR). The IIF does not send a REGNOT in this case, because it does 29 not support multiple MSCIDs. 30
n. The IIF sends MAP INSERT SUBSCRIBER DATA message(s) to the GSM MSC providing GSM 31 CS information based on the contents of the regnot (profile). 32
o. The GSM MSC acknowledges receipt of the Insert Subscriber Data information. 33
p. The IIF acknowledges the completion of the Update Location procedure and sends the Update 34 Location Acknowledgement to the GSM MSC. 35
q. The GSM MSC acknowledges the BSSAP+LocationUpdateRequest over the Gs interface to the 36 SGSN by sending the Accept message. 37
r. The SGSN acknowledges the combined GPRS and GSM Attach request from the MS. 38
39
40
N.S0028
Post Ballot Version 185
1
2
Combined Attach Req (IMSI)
MS SGSNMSC IIF
Authentication Info
Authentication Info AckAuthentication Req
Authentication Res
a
b
cd
e
HLR
Update GPRS Location Req (IMSI)
Insert Sub Data
Insert Sub Data Ack
f
g
h
i
j
k
Update gprs location ack
GSM NETWORK ANSI-41 NETWORK
REGNOT
Regnot ack
N.S0028
Post Ballot Version 186
Figure 115: Combined GPRS and GSM attach (Option 3: IIF supports multiple MSCIDs). 1
2 3
s
MS
l
m
n
SGSN MSC IIF HLR
o
r
t
v
p
q
u
BSSAP+-Location Update Req
REGNOT
Update Location Req
BSSAP+-Location Update AcceptGPRS Attach Accept/Routing Area Update Accept
Update Location ack
Insert Sub Data
Insert Sub Data Ack
REGCANC
regcanc
regnot
ANSI-41 NETWORKGSM NETWORK
N.S0028
Post Ballot Version 187
a. MS performs a GPRS attach. 1
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to 2 perform authentication i.e. authentication triplets, it requests authentication information from the 3 IIF. 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 Location 8 Request contains the IMSI. 9
g. The IIF shall send a Registration Notification (REGNOT) to the ANSI-41 HLR to indicate the 10 changed location (MSCID associated to the new GSM SGSN). 11
If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall be 12 passed in the REGNOT to the subscriber’s HLR. This ESN may not match the currently validated 13 dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for this subscriber. 14
h. The ANSI-41 HLR acknowledges the registration and sends back the subscriber’s information in 15 a regnot response. 16
i. The IIF validates whether the GPRS service request is authorized. Since GPRS service is 17 requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert Subscriber 18 Data Procedure towards the SGSN after the subscriber has been successfully authorized. This 19 procedure is used to download GPRS subscriber data to the SGSN. Multiple Insert Subscriber 20 Data transactions may be necessary to complete the transfer of subscriber data to the SGSN. 21
j. The SGSN acknowledges the ISD Operation(s). 22
k. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF 23 returns an acknowledgement to the Update GPRS Location Request. 24
l. The SGSN sends a BSSAP+LocationUpdateRequest to the GSM MSC over the Gs interface. 25 The GSM MSC creates the association with the SGSN by storing the SGSN Number. 26
m. The MSC determines that it needs to notify the IIF (emulating the GSM HLR), since there is a 27 change to the CS location update parameters. The MSC sends the Update Location operation to 28 the IIF (emulating the GSM HLR). 29
n. The IIF shall send a Registration Notification (REGNOT) to the ANSI-41 HLR to indicate the 30 changed location (MSCID associated to the new GSM MSC). 31
If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall be 32 passed in the REGNOT to the subscriber’s HLR. This ESN may not match the currently validated 33 dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for this subscriber. 34
o. IIF receives a REGCANC. The IIF needs to keep both the current MSCID associated to the 35 SGSN as well as the current MSCID associated to the MSC. The IIF must also keep a record of 36 the last MSCID which was sent to the ANSI-41 HLR to know that is the one stored in the ANSI-41 37 HLR. 38
p. IIF sends regcanc response. 39
q. The ANSI-41 HLR acknowledges the registration and sends back the subscriber’s information. 40
r. The IIF sends MAP INSERT SUBSCRIBER DATA message(s) to the GSM MSC providing GSM 41 CS information based on the contents of the regnot (profile). 42
N.S0028
Post Ballot Version 188
s. The GSM MSC acknowledges receipt of the Insert Subscriber Data information. 1
t. The IIF acknowledges the completion of the Update Location procedure and sends the Update 2 Location Acknowledgement to the GSM MSC. 3
u. The GSM MSC acknowledges the BSSAP+LocationUpdateRequest over the Gs interface to the 4 SGSN by sending the Accept message. 5
v. The SGSN acknowledges the combined GPRS and GSM Attach request from the MS. 6 7
N.S0028
Post Ballot Version 189
4.13.1.6 Combined Inter-SGSN Routeing Area/Location Area Update 1
If an MS requests a combined routeing area update when previously registered on a different SGSN 2 and GSM MSC, then the SGSN first requests a GPRS location update to the IIF (acting as a GPRS 3 HLR) and then a CS location update. 4
5
inter-SGSN Routing Area Update
MS
Authentication Req
Authentication Res
(IMSI)a
b
c
d
e
fUpdate GPRS Location Req (IMSI)
SGSNMSC IIF
Authentication Info
Authentication Info Ack
HLRPMSC/VLRPrev
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
regcanck
REGCANC
GSM NETWORK GSM NETWORKANSI-41
N.S0028
Post Ballot Version 190
1
Figure 116: Combined Inter-SGSN RA/LA update 2
a. MS sends a Routeing Area Update request 3
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to 4 perform authentication i.e. authentication triplets, it requests authentication information from the 5 IIF. 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 Location 10 Request contains the IMSI. 11
g. In the case of a combined attach when registered on a different MSC and SGSN, and in the case 12 of a combined inter-SGSN routing area update case when previously registered on a different 13 MSC and SGSN, the IIF (acting like a GPRS HLR) shall also send a Cancel Location to the 14 previous SGSN 15
h. IIF shall receive an acknowledgement for the Cancel Location. 16
y
MS
p
q
r
s
t
SGSNMSC IIF HLR
PMSC/VLRPrev
SGSN
u
x
z
bb
v
w
aa
BSSAP+-Location Update Req
Cancel Location
Cancel Location Ack
REGNOT
Update Location Req
BSSAP+-Location Update AcceptGPRS Attach Accept/Routing Area Update Accept
Update Location ack
Insert Sub Data
Insert Sub Data Ack
REGCANC
regcanc
regnot
ANSI-41GSM NETWORK GSM NETWORK
N.S0028
Post Ballot Version 191
i. If the IIF implementation supports multiple MSCIDs, then it shall send a REGNOT to the ANSI-41 1 MSC with the MSCID corresponding to the new SGSN. 2
j. This is a continuation of the optional procedure started in item i. IIF receives REGCANC. The IIF 3 needs to keep both the current MSCID associated to the SGSN as well as the current MSCID 4 associated to the MSC. The IIF must also keep a record of the last MSCID which was sent to the 5 ANSI-41 HLR to know that is the one stored in the ANSI-41 HLR. 6
k. This is a continuation of the optional procedure started in item i. IIF sends regcanc response. 7
l. This is a continuation of the optional procedure started in item i. IIF receives regnot response. 8
m. The IIF validates whether the GPRS service request is authorized. Since GPRS service is 9 requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert Subscriber 10 Data Procedure towards the SGSN after the subscriber has been successfully authorized. This 11 procedure is used to download GPRS subscriber data to the SGSN. Multiple Insert Subscriber 12 Data transactions may be necessary to complete the transfer of subscriber data to the SGSN. 13
n. The SGSN acknowledges the ISD Operation(s). 14
o. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF 15 returns an acknowledgement to the Update GPRS Location Request. 16
p. The SGSN sends a BSSAP+LocationUpdateRequest to the GSM MSC over the Gs interface. 17 The GSM MSC creates the association with the SGSN by storing the SGSN Number. 18
q. The MSC determines that it needs to notify the IIF (emulating the GSM HLR), since there is a 19 change to the CS location update parameters, so the IIF sends the Update Location operation to 20 the IIF (emulating the GSM HLR). 21
r. The IIF sends a Cancel Location to the previous GSM MSC/VLR if a change in MSC has been 22 detected. 23
s. The IIF receives the Cancel Location acknowledgement. 24
t. If the IIF implementation supports multiple IIF MSCIDs, then it shall send a Registration 25 Notification (REGNOT) to the ANSI-41 HLR to indicate the changed location (MSCID associated 26 to the new GSM MSC). 27
If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall be 28 passed in the REGNOT to the subscriber’s HLR. This ESN may not match the currently validated 29 dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for this subscriber. 30
u. This is a continuation of the optional procedure started in item t. The IIF receives a REGCANC if 31 the MSCID just sent in item (t) is a different one than stored in the ANSI-41 HLR. IIF receives 32 REGCANC. The IIF needs to keep both the current MSCID associated to the SGSN as well as 33 the current MSCID associated to the MSC. The IIF must also keep a record of the last MSCID 34 which was sent to the ANSI-41 HLR to know that is the one stored in the ANSI-41 HLR. 35
v. This is a continuation of the optional procedure started in item t. The IIF acknowledges the 36 regcanc. 37
w. This is a continuation of the optional procedure started in item t. The IIF receives the regnot 38 response with the subscriber’s information. This information is for non-GPRS services. 39
x. The IIF sends MAP INSERT SUBSCRIBER DATA message(s) to the GSM MSC providing GSM 40 CS information based on the contents of the regnot (profile). 41
y. The GSM MSC acknowledges receipt of the Insert Subscriber Data information. 42
N.S0028
Post Ballot Version 192
z. The IIF acknowledges the completion of the Update Location procedure and sends the Update 1 Location Acknowledgement to the GSM MSC. 2
aa. The GSM MSC acknowledges the BSSAP+LocationUpdateRequest over the Gs interface to the 3 SGSN by sending the Accept message. 4
bb. The SGSN acknowledges the GPRS Attach request from the MS. 5
6
7
8
N.S0028
Post Ballot Version 193
4.13.1.7 Inter-SGSN routing area update when GSM CS and GPRS attached (GSM MSC 1 remains constant) 2
An MS request a GPRS routing area update while registered in a GSM serving MSC and GPRS 3 attached. In this case, the change of routing areas is within one Location area (and the MSC remains 4 constant) as shown in Figure 118. Note that the GSM MSC does not update the IIF (emulating the 5 GSM HLR). 6
7
N.S0028
Post Ballot Version 194
1
Figure: 117: Inter-SGSN routing area update when GSM CS and GPRS Attached (MSC remains 2 constant) 3
MS
p
q
r
SGSNMSC IIF HLR Prev
SGSNBSSAP+-Location Update Req
BSSAP+-Location Update Accept
Routing Area UpdateAccept
ANSI-41GSM NETWORK GSM NETWORK
inter-SGSN Routing Area Update
MS
Authentication Req
Authentication Res
(IMSI)a
b
c
d
e
fUpdate GPRS Location Req (IMSI)
SGSNMSC IIF
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
GSM NETWORK GSM NETWORKANSI-41
N.S0028
Post Ballot Version 195
1
a. MS sends a Routing Area Update request. 2
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to 3 perform authentication i.e. authentication triplets, it requests authentication information from the 4 IIF. 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 Location 9 Request contains the IMSI. 10
g. The IIF (acting like a GPRS HLR) shall send a Cancel Location to the previous SGSN 11
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 the ANSI-41 13 MSC with the MSCID corresponding to the new SGSN. The IIF shall correlate that MSCID with 14 the GSM MSCID when receiving mobile terminated SMS messages (so that the IIF can deliver 15 them to the MSC). 16
j. This is a continuation of the optional procedure started in item i. IIF receives REGCANC. The IIF 17 needs to keep both the current MSCID associated to the SGSN as well as the current MSCID 18 associated to the MSC. The IIF must also keep a record of the last MSCID which was sent to the 19 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 is 23 requested, it initiates the GSM MAP Insert Subscriber Data Procedure towards the SGSN after 24 the subscriber has been successfully authorized. This procedure is used to download GPRS 25 subscriber data to the SGSN. Multiple Insert Subscriber Data transactions may be necessary to 26 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 IIF 29 returns 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), since there 32 is no change to the CS location update parameters, so the IIF does not send the Update Location 33 operation to the IIF (emulating the GSM HLR). The GSM MSC acknowledges the 34 BSSAP+LocationUpdateRequest over the Gs interface to the SGSN by sending the Accept 35 message. 36
r. The SGSN acknowledges the Routing Area Update request from the MS. 37
38
N.S0028
Post Ballot Version 196
4.13.1.8 Combined Attach When Currently Registered in an ANSI-41 MSC 1
This scenario describes the case where a mobile that is currently registered in an ANSI-41 MSC 2 performs a combined attach for both GPRS and non-GPRS services. 3
4
N.S0028
Post Ballot Version 197
1
GPRS Attach Req(IMSI)
MS
Authentication Req
Authentication Res
a
b
c
d
e
f
g
h
i
j
k
l
m
n
Update GPRS Location Req (IMSI)
SGSNMSC IIF
Authentication Info
Authentication Info Ack
Insert Sub Data
Insert Sub Data Ack
BSSAP+-Location Update Req
HLR
Update gprs location ack
PMSC/VLR
f
g
h
i
j
k
l
m
REGNOT
REGCANC
regcanc
Update Location Req
GPRS_LU
GSM NETWORK
ANSI-41 ANSI-41
N.S0028
Post Ballot Version 198
1
Figure 118: Combined Attach when registered on a ANSI-41 MSC (Option 1: With timer) 2
3 4
MS SGSN MSC IIF
BSSAP+-Location Update Accept
GPRS Attach Accept
o
p
q
r
s
t
HLR
Update Locationack
Insert Sub Data
Insert Sub Data Ack
Regnot ack
GSM NETWORK ANSI-41 NETWORK
N.S0028
Post Ballot Version 199
1
a. MS performs a GPRS Attach. 2
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to 3 perform authentication i.e. authentication triplets, it requests authentication information from the 4 IIF. 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 Location 9 Request contains the IMSI. The IIF starts timer GPRS LU. 10
g. The IIF validates whether the GPRS service request is authorized. Since GPRS service is 11 requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert Subscriber 12 Data Procedure towards the SGSN after the subscriber has been successfully authorized. This 13 procedure is used to download GPRS subscriber data to the SGSN. Multiple Insert Subscriber 14 Data transactions may be necessary to complete the transfer of subscriber data to the SGSN. 15
h. The SGSN acknowledges the ISD Operation(s). 16
i. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF 17 returns an acknowledgement to the Update GPRS Location Request. 18
j. The SGSN sends a BSSAP+LocationUpdateRequest to the GSM MSC over the Gs interface. 19 The GSM MSC creates the association with the SGSN by storing the SGSN Number. 20
k. The MSC determines that it needs to notify the IIF (emulating the GSM HLR), since there is a 21 change to the CS location update parameters. The MSC sends the Update Location operation to 22 the IIF (emulating the GSM HLR). The IIF stops timer GPRS LU. 23
l. The IIF shall send a Registration Notification (REGNOT) to the ANSI-41 HLR to indicate the 24 changed location (MSCID associated with the new GSM MSC). 25
If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall be 26 passed in the REGNOT to the subscriber’s HLR. This ESN may not match the currently validated 27 dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for this subscriber. 28
m. The HLR updates its location information and deletes the previous VLR record by sending a 29 REGCANC to the previous MSC/VLR. 30
n. The VLR acknowledges the REGCANC. 31
o. The ANSI-41 HLR acknowledges the registration and sends back the subscriber’s information. 32 This information is for non-GPRS services 33
p. The IIF sends MAP INSERT SUBSCRIBER DATA message(s) to the GSM MSC providing GSM 34 CS information based on the contents of the regnot (profile). 35
q. The GSM MSC acknowledges receipt of the Insert Subscriber Data information. 36
r. The IIF acknowledges the completion of the Update Location procedure and sends the Update 37 Location Acknowledgement to the GSM MSC. 38
s. The GSM MSC acknowledges the BSSAP+LocationUpdateRequest over the Gs interface to the 39 SGSN by sending the Accept message. 40
t. The SGSN acknowledges the combined GPRS and GSM attach request from the MS. 41
N.S0028
Post Ballot Version 200
1
N.S0028
Post Ballot Version 201
1
GPRS Attach Req (IMSI)
MS
Authentication Req
Authentication Res
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
Insert Sub Data
Insert Sub Data Ack
Update gprs location ack
g
h
i
j
k
l
m
REGNOT
Regnot ack
regcanc
REGCANC
GSM NETWORK ANSI-41 NETWORK
N.S0028
Post Ballot Version 202
Figure 119: Combined attach when registered on a ANSI-41 MSC (Option 2: without timer ) 1
2
u
MS
n
o
p
SGSN MSC IIF HLRPMSC/VLR
q
t
v
x
r
s
w
BSSAP+-Location Update Req
REGNOT
Update Location Req
BSSAP+-Location Update Accept
GPRS Attach Accept
Update Location ack
Insert Sub Data
Insert Sub Data Ack
REGCANC
regcanc
regnot
ANSI-41 NETWORKGSM NETWORK
N.S0028
Post Ballot Version 203
1
a. MS performs a GPRS attach. 2
b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order 3 to perform authentication i.e. authentication triplets, it requests authentication information 4 from the IIF. 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 Location 9 Request contains the IMSI. 10
g. The IIF shall send a Registration Notification (REGNOT) to the ANSI-41 HLR to indicate the 11 changed location. 12
If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall 13 be passed in the REGNOT to the subscriber’s HLR. This ESN may not match the currently 14 validated dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for 15 this subscriber. 16
h. ANSI-41 HLR sends a REGCANC to the ANSI-41 MSC on which the MS was previously 17 registered. 18
i. ANSI-41 MSC sends regcanc response. 19
j. The ANSI-41 HLR acknowledges the registration and sends back the subscriber’s information 20 in a regnot response. 21
k. The IIF validates whether the GPRS service request is authorized. Since GPRS service is 22 requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert 23 Subscriber Data Procedure towards the SGSN after the subscriber has been successfully 24 authorized. This procedure is used to download GPRS subscriber data to the SGSN. Multiple 25 Insert Subscriber Data transactions may be necessary to complete the transfer of subscriber 26 data to the SGSN. 27
l. The SGSN acknowledges the ISD Operation(s). 28
m. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the 29 IIF returns an acknowledgement to the Update GPRS Location Request. 30
n. The SGSN sends a BSSAP+LocationUpdateRequest to the GSM MSC over the Gs interface. 31 The GSM MSC creates the association with the SGSN by storing the SGSN Number (e.g. for 32 later CS paging over the Gs interface upon a call delivery attempt). 33
o. The MSC determines that it needs to notify the IIF (emulating the GSM HLR), since there is a 34 change to the CS location update parameters. The MSC sends the Update Location 35 operation to the IIF (emulating the GSM HLR). 36
p. If the IIF implementation supports multiple MSCIDs, then it shall send a Registration 37 Notification (REGNOT) to the ANSI-41 HLR to indicate the changed location (MSCID 38 associated to the new GSM MSC). 39
If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall 40 be passed in the REGNOT to the subscriber’s HLR. This ESN may not match the currently 41
N.S0028
Post Ballot Version 204
validated dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for 1 this subscriber. 2
q. This is a continuation of the optional procedure started in item p. The IIF receives a 3 REGCANC if the MSCID just sent in item (p) is a different one than stored in the ANSI-41 4 HLR. The IIF needs to keep both the current MSCID associated to the SGSN as well as the 5 current MSCID associated to the MSC. The IIF must also keep a record of the last MSCID 6 which was sent to the ANSI-41 HLR to know that is the one stored in the ANSI-41 HLR. 7
r. This is a continuation of the optional procedure started in item p. The IIF acknowledges the 8 regcanc. 9
s. This is a continuation of the optional procedure started in item p. The IIF receives the regnot 10 response with the subscriber’s information. This information is for non-GPRS services. 11
t. The IIF sends MAP INSERT SUBSCRIBER DATA message(s) to the GSM MSC providing 12 GSM CS information based on the contents of the regnot (profile). 13
u. The GSM MSC acknowledges receipt of the Insert Subscriber Data information. 14
v. The IIF acknowledges the completion of the Update Location procedure and sends the 15 Update Location Acknowledgement to the GSM MSC. 16
w. The GSM MSC acknowledges the BSSAP+LocationUpdateRequest over the Gs interface to 17 the SGSN by sending the Accept message. 18
x. The SGSN acknowledges the combined GPRS and GSM attach request from the MS. 19
20
N.S0028
Post Ballot Version 205
4.13.1.9 Authentication Failure at the IIF 1
In any of the scenarios shown previously in 4.13.1 (assuming authentication is performed), 2 authentication may fail at the IIF. 3
In the event that authentication fails at the IIF (emulating a GSM HLR), it shall send a response to the 4 SGSN indicating the reason for failure. 5
Note: The ANSI-41 HLR is not informed about a registration attempt if authentication fails at the IIF. 6
4.13.1.10 Registration Failure at the ANSI-41HLR 7
In any of the scenarios shown previously in 4.13.1 where the ANSI-41 HLR is informed about the 8 registration attempt (assuming authentication is successful or not performed), the registration 9 procedure may fail. 10
In the event that the ANSI-41 HLR denies the registration attempt, it shall send a regnot to the IIF 11 indicating the reason for failure. If the IIF determines that the MS is already registered in an SGSN, it 12 shall send a Cancel Location to the SGSN. Otherwise, the IIF sends an update GPRS location 13 response indicating the reason for failure. 14
4.13.2 Location Deregistration Scenarios 15
16 4.13.2.1 GSM CS (IMSI) Detach while GPRS and GSM CS Attached 17
A GPRS mobile attached for both GPRS and non-GPRS services can request a detach for circuit 18 services (IMSI detach). The IIF is not notified about the MS initiated detachment and hence the ANSI-19 41 HLR is not informed. 20
4.13.2.2 GPRS Detach While Attached for Both GPRS and GSM CS Services 21
A GPRS mobile attached for both GPRS and non-GPRS services can request a GPRS detach. The 22 IIF is not notified about the MS initiated detachment and hence the ANSI-41 HLR is not informed. 23
4.13.2.3 GPRS Detach While Attached for GPRS Services Only 24
In GPRS, the GPRS HLR is not notified when a GPRS subscriber performs a GPRS detach. Hence, 25 the IIF (which is emulating the GPRS HLR) shall not be notified of the GPRS detach. In this case, a 26 GPRS subscriber performs a Detach request that is handled by the SGSN and GGSN to remove MM 27 and PDP contexts. There is no interworking with circuit services. 28
4.13.2.4 Combined GPRS Detach and GSM CS (IMSI) Detach 29
A GPRS mobile attached for both GPRS and non-GPRS services can request a combined detach 30 from GPRS and non-GPRS services. The IIF is not notified about the MS initiated detachment and 31 hence the ANSI-41 HLR is not informed. 32
33
34
N.S0028
Post Ballot Version 206
4.13.2.5 GPRS Detach Followed By Purge 1
The IIF becomes involved in a detach procedure when the detach procedure is followed by a purge 2 MS procedure. The following scenario shows the case where a GAIT mobile is attached for services 3 to an SGSN-only. The mobile performs a GPRS detach. After accepting the detach request, the 4 SGSN is configured to initiate a purge MS procedure (after some pre-configured time period). In a 5 case when the MS is still GSM CS attached, the MS-Inactive is not sent by the IIF. Likewise, if an 6 MSC sends the PurgeMS operation to the IIF when the subscriber is still GPRS attached, the IIF 7 would not send the MS-Inactive to the ANSI-41 HLR. 8
9
Figure 120: MS in GSM Foreign Mode Performing GPRS Detach Followed by Purge 10
11
a. The MS performs a Detach Request to detach from GPRS services. This MS was attached for 12 GPRS services only. 13
b. The SGSN exchanges signaling information with the GGSN to remove PDP contexts on the 14 GGSN for the subscriber. 15
c. See (b) 16
d. The SGSN accepts the detach from the MS and sends a Detach Accept. 17
e. The SGSN is configured to delete MM contexts as soon as the Detach Accept is sent. Hence, 18 the SGSN notifies the IIF (acting as a GPRS HLR) that it has deleted the MM context for the MS. 19
MS ANSI-41HLR
IIFSGSN
Detach Request
Signalingwith GGSN
Detach Accept
Purge MS
Purge MS Ack
MSINACTIVE
msinactive
a
b
c
d
e
f
g
h
N.S0028
Post Ballot Version 207
f. The IIF acknowledges the Purge Operation and marks in its GPRS subscription data for the 1 subscriber that the GPRS data has been purged. 2
g. The IIF sends an MSINACTIVE to the ANSI-41 HLR to de-register the MS from the IIF (acting as 3 an ANSI-41 MSC). 4
h. The ANSI-41 HLR acknowledges the MSINACTIVE operation 5
6
N.S0028
Post Ballot Version 208
4.13.2.6 IIF - Initiated Detach 1
The IIF initiated detach procedure is initiated by the IIF. The procedure results in the removal of a 2 subscribers PDP contexts at the SGSN. 3
4
Figure 121: IIF - Initiated Detach 5
a. The IIF requests deletion of a subscribers PDP contexts from the SGSN by sending a Cancel 6 Location (IMSI, Cancellation Type) to the SGSN with Cancellation Type set to Subscription 7 Withdraw. 8
1 9 b. The SGSN informs the MS that it has been detached by sending Detach Request (Detach 10
Type) to the MS. Detach Type shall indicate that the MS is not requested to make a new attach 11 and PDP context activation. 12
1 13 c. The active PDP contexts in the GGSNs are de-activated by the SGSN sending Delete PDP 14
Context Request messages to the GGSNs. 15 1 16
d. The GGSNs acknowledge the Delete Request 17 1 18 e. If the MS was both IMSI-attached and GPRS–attached the SGSN sends a GPRS Detach 19
Indication (IMSI) to the VLR. 20 1 21 f. The MS sends a Detach Accept to the SGSN any time after step b. 22
1 23 g. The SGSN confirms the deletion of the PDP contexts with a Cancel Location Ack (IMSI). 24
1 25
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
N.S0028
Post Ballot Version 209
1Note: In some cases the IIF may send an MS Inactive towards the ANSI-41 HLR (but not if CS 1 services are still to be offered). 2 3 4.13.3 SMS Scenarios 4
This section describes the scenarios for MS terminated and MS originated SMS while the mobile in 5 roaming in a GPRS network in GSM foreign mode. 6
4.13.3.1 SMS Scenarios for Mobile Terminated SMS while GPRS Attached 7
a.If the subscriber is both GSM CS attached as well as GPRS attached, then the IIF shall act like a 8 GSM SMS-SC. 9
The scenarios that follow only show the SMS delivery via GPRS. 10
4.13.3.1.1 Successful Mobile Terminated ANSI-136 41 SMS (CMT) Mapped to GSM SMS 11
12
Figure 122: Successful Mobile Terminating ANSI-136 41 SMS (CMT) mapped to GSM SMS 13
14 a. The ANSI-136 41 Message Center (MC) receives a short message for a specific subscriber. 15
Note: This step is shown for completeness only and is not repeated in subsequent call flows. 16 17 b. The Message Center sends an SMS Request message to the ANSI-41 HLR of the short message 18
recipient to request a routing address for delivering the short message to that subscriber. 19 20 c. Since the subscriber has a current valid location stored in the HLR, the HLR returns it to the MC 21
in the SMS Request Return Result message. 22 23 d. The Message Center then sends a Short Message Delivery Point to Point message to the IIF, 24
which is seen as the current serving ANSI-41 MSC/VLR for that subscriber. Note that in this case, 25
TDMAMC
TDMAHLR 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
N.S0028
Post Ballot Version 210
the format used by the MC is the CMT format (Cellular Messaging Transport). Note that 1 alternatively, the ANSI-136 41 MC could translate the original CMT SMS to GHOST/WEMT 2 format before sending it to the IIF if the IIF only supports the GHOST/WEMT format. In this case 3 the IIF would convert ANSI-136 41 GHOST/WEMT into GSM format (see Section 4.13.3.1.2) 4 instead of ANSI-136 41 CMT into GSM format. 5
6 e. Upon reception of the Short Message Delivery Point to Point message from the ANSI-136 41 MC, 7
the IIF originates a FORWARD SHORT MESSAGE to the SGSN after having translated the short 8 message into GSM format. The IIF is then acting as a GSM SMS-GMSC. 9
10 f. The SGSN sends the short message to the mobile station. Note: This step is shown for 11
completeness only and is not repeated in subsequent call flows. 12 13 g. The mobile station acknowledges the delivery of the short message. Note: This step is shown for 14
completeness only and is not repeated in subsequent call flows. 15 16 h. The SGSN sends the result of the Forward Short Message to the IIF. 17 18 i. The IIF sends the result of the Short Message Delivery Point to Point to the ANSI-136 41 19
Message Center. 20
21
22
23
N.S0028
Post Ballot Version 211
1
4.13.3.1.2 Successful Mobile Terminating ANSI-136 41 SMS (GHOST/WEMT) Mapped to GSM 2
SMS 3
4 Figure 123: Successful Mobile Terminating ANSI-136 41 SMS (GHOST/WEMT) mapped to GSM 5
SMS 6
7
a. The ANSI-41 MC sends a SMSRequest Invoke message to the HLR, including as arguments the 8 MIN (MSISDN) of the mobile station and SMS Notification Indicator. 9
b. The HLR determines if the message shall be forwarded to the MS and sends a response back in 10 a SMSRequest Return Result, with the SMS_Address set to the IIF address (point code or E.164 11 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 builds a FORWARD SHORT MESSAGE, stripping 14 off the GHOST/WEMT teleservice and using the encapsulated GSM SMS transfer PDU, and 15 routes it to the SGSN as a first choice. Alternatively, the IIF could send the FSM to the GSM MSC 16 (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 across 18 the GSM air interface to the mobile station. The mobile station acknowledges receipt of the CP-19 DATA and RP-DATA messages via CP-ACK and CP-ACK[RP-ACK], respectively. Upon 20 successful receipt of the RP-ACK, the SGSN shall send a positive acknowledgement Forward 21 Short Message back to the IIF. 22
f. The IIF maps the received Forward Short Message into a SMDPP Return Result and sends it to 23 the MC. 24
ANSI-41 GSM
smdpp [ACK]
MC HLR IIF SGSN
a
d
a
c
b
SMDPP
SMSREQ
smsreq
FORWARD SHORT MESSAGE
Forward Short Message e
f
N.S0028
Post Ballot Version 212
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/WEMT 2
format. 3
4
Figure 124: Unsuccessful Mobile Terminated Delivery (Failure at SGSN) 5
6 a. The ANSI-41 MC sends a SMSRequest Invoke message to the HLR, including as arguments the 7
MIN (MSISDN) of the mobile station and SMS Notification Indicator. 8
b. The HLR determines if the message shall be forwarded to the MS and sends a response back in 9 a SMSRequest Return Result, with the SMS_Address set to the IIF address (point code or E.164 10 address). 11
c. The MC formats a GHOST/WEMT teleservice or a CMT short message and sends it to the IIF in 12 an SMDPP message. 13
d. Upon receipt of the SMDPP message, the IIF builds a FORWARD SHORT MESSAGE, stripping 14 off the GHOST/WEMT teleservice and using the encapsulated GSM SMS transfer PDU, and 15 routes it to the SGSN. If the message received is in the CMT format, the IIF maps this information 16 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 across 18 the GSM air interface to the mobile station. The mobile station negatively acknowledges either 19 the CP-DATA message or the RP-DATA message. The SGSN sends a negative 20 acknowledgement 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 to 22 the MC. In addition, the IIF sets one of the GSM SMS flags as defined in the GSM 03.40 23 specification [4] according to the error cause received from the SGSN; that is, the Mobile 24 Subscriber Not GPRS Reachable Flag (MNRG) shall be set if the error cause is “absent 25
ANSI-41 GSM
smdpp [NAK]
MC HLR IIF SGSN
a
d
a
c
b
SMDPP
SMSREQ
smsreq
FORWARD SHORT MESSAGE
Forward Short Messagee
f
N.S0028
Post Ballot Version 213
subscriber”, and the Memory Capacity Exceeded Flag (MCEF) shall be set if the error cause is 1 “memory capacity exceeded”. Additionally, the IIF emulating the ANSI-41 MSC shall set and 2 store the SMS Delivery Pending flag with the MC parameters received in the SMDPP (for later 3 delivery in the SMSNOT) – note that this “SMS Delivery Pending” flag/data serves the same 4 purpose as a GSM HLR’s “Message Waiting Data” flag/data. [However, note that if an ANSI-41 5 REGCAN is received from the ANSI-41 HLR before the SMS Delivery Pending Flag is cleared, 6 then the regcanc response shall contain the SMS_MessageWaitingIndicator, and all flags are 7 cleared (i.e., MNRG, MNRF, MCEF, and SMS Delivery Pending Flag)]. 8
4.13.3.1.4 Unsuccessful Mobile Terminated Delivery (Failure at IIF) 9
The following scenario applies to short message delivery failure in either CMT or GHOST/WEMT 10 format. 11
12
13
Figure 125: Unsuccessful Mobile Terminated Delivery (Failure at IIF) 14
15
a. The ANSI-41 MC sends a SMSRequest Invoke message to the HLR, including as arguments the 16 MIN (MSISDN) or IMSI of the mobile station and SMS Notification Indicator. 17
b. The HLR determines if the message shall be forwarded to the MS and sends a response back in 18 a SMSRequest Return Result, with the SMS_Address set to the IIF address (point code or E.164 19 address). 20
c. The MC formats a GHOST/WEMT teleservice and sends it to the IIF in an SMDPP message. 21
d. Upon receipt of the SMDPP message, the IIF examines the GSM 03.40 HLR flags (if “both MNRC 22 and MNRG” or ”MCEF” is set) and determines that the MS is unable to receive a Short Message. 23 The IIF indicates this fact in the SMDPP Return Result. It includes the cause for the failure in the 24 SMS_CauseCode parameter of the SMDPP Return Result. The IIF shall set & store the SMS 25 Delivery Pending Flag with the data received in the SMDPP message (for later delivery in the 26 SMSNOT). If the 03.40 flag is set to MNRG and if the flag is not set to MNRC, then the SMDPP 27 shall be delivered to the GSM MSC as described in GAIT phase 1. If 03.40 flag is set to MNRC 28 and not MNRG nor MCEF, then SMS delivery is possible through the SGSN as shown in section 29 4.13.3.1. 30
31
ANSI-41 GSM
smdpp [NAK]
MC HLR IIF SGSN
a
d
a
c
b
SMDPP
SMSREQ
smsreq
N.S0028
Post Ballot Version 214
1
4.13.3.1.5 Alerting for an ANSI-136 41 Subscriber for GPRS in GSM Foreign Mode 2
The following scenario applies to short messages originated in either CMT or GHOST/WEMT format. 3
4
Figure 126: Alerting for an ANSI-136 41 Subscriber in GSM Foreign Mode 5
a. The SGSN sends a READY FOR SM to the IIF, including as arguments the IMSI, Alert Reason 6 Indicator and Alert Reason. Note: The SMS notification can also be triggered when the SGSN 7 sends an Update GPRS Location. This happens when an MS for whom messages are pending 8 re-attaches or performs an inter-SGSN routing area update, the SGSN sends an Update GPRS 9 Location 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 IIF 11 sends a SMSNOT to each of the subscriber’s MCs stored with the SMS Delivery Pending Flag. 12 The SMSNOT shall contain; the MIN (MSISDN) as mapped from the IMSI, ESN, and 13 SMS_Address containing the IIF address. 14
c. The MC sends a SMSNOT Return Result to the IIF, then the IIF clears the SMS Delivery Pending 15 Flag, then proceeds to send the mobile station a mobile terminated CMT or GHOST/WEMT 16 teleservice message. 17
d. If the IIF has GSM 03.40 flags set, then these flags shall be cleared according to the “alert 18 reason”; that is, if the “alert reason” is “memory available”, then both the MCEF and MNRG flags 19 are cleared, and if the “alert reason” is “MS present”, then the MNRG flag is cleared. If the 20 UpdateGPRSLocation is received, then the MNRG flag is cleared. The IIF sends a Ready for SM 21 response to the SGSN with no arguments. 22
23
24
SMSC HLR IIF
ANSI-41 GSM
MSC
READY FOR SM
ready for SM
SMSNOT
smsnot
a
b
c
d
N.S0028
Post Ballot Version 215
4.13.4 Message Flows for Mobile Originated SMS when operating GPRS in 1 GSM Foreign Mode 2
This section describes the message flows for originating a short message to the subscriber’s home 3 message center when the mobile station is operating GPRS in GSM Foreign Mode. The following 4 scenarios 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 MC 6
7
Figure 127: Successful Mobile Originated Delivery 8
9
a. 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-SUBMIT PDU. 11
b. Upon receipt of the FORWARD SHORT MESSAGE, the IIF builds an ANSI-41 SMDPP message, 12 encapsulating the GSM SMS transfer PDU in a GHOST/WEMT teleservice, and routes it to the 13 originator’s home MC. The IIF can also map the Forward Short Message into a CMT short 14 message. 15
c. The MC sends a positive acknowledgement SMDPP Return Result to the IIF. 16
d. The IIF maps the received SMDPP Return Result to a Forward Short Message, and sends it to 17 the SGSN. 18
19
GSM ANSI-41
FORWARD SHORT MESSAGE
Forward Short Message
SGSN HLR IIF MC
SMDPP
smdpp [ACK]
a
d
a
c
b
N.S0028
Post Ballot Version 216
4.13.4.2 Unsuccessful Mobile Originated (Failure at MC) 1
2
Figure 128: Unsuccessful Mobile Originated Delivery (Failure at MC) 3
4
a. 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-SUBMIT PDU. 6
b. Upon receipt of the FORWARD SHORT MESSAGE, the IIF builds an ANSI-41 SMDPP message 7 encapsulating the GSM SMS transfer PDU in a GHOST/WEMT teleservice, and routes it to the 8 MC. The IIF can also map the Forward Short Message into a CMT short message. 9
c. The MC sends a negative acknowledgement SMDPP Return Result to the IIF. 10
d. The IIF maps the received SMDPP Return Result to a Forward Short Message with the 11 appropriate cause code value, and sends it to the SGSN. 12
13
GSM ANSI-41
FORWARD SHORT MESSAGE
Forward Short Message
SGSN HLR IIF MC
SMDPP
smdpp [NAK]
a
d
a
c
b
N.S0028
Post Ballot Version 217
4.13.4.3 Unsuccessful Mobile Originated (Failure at IIF) 1
2 Figure 129: Unsuccessful Mobile Originated (Failure at IIF) 3
4
a. 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-SUBMIT PDU. 6
b. Upon receipt of the FORWARD SHORT MESSAGE, the IIF builds a negative acknowledgement 7 Forward Short Message and sends it to the SGSN. 8
9
10
GSM ANSI-41
FORWARD SHORT MESSAGE
Forward Short Message
SGSN HLR IIF MC
a
b
N.S0028
Post Ballot Version 218
4.13.5 Message Waiting Notification while GPRS Attached in GSM Foreign 1 Mode 2
This section illustrates the interactions between network entities in various situations related to mobile 3 originations and GPRS in GSM foreign mode and Message Waiting Notification. For a native ANSI-4 136 ANSI-41 subscriber roaming in a GSM environment, there can be two events that trigger the IIF 5 to send the Message Waiting Notification (MWN) using the GSM SMS to the Mobile Station (MS). 6 The first one is at registration (update GPRS location), if there is an indication in the ANSI-41 HLR 7 that messages have been delivered to the subscriber’s voice mail box, the ANSI-41 HLR shall 8 indicate that in the Registration Notification Return Result message. This shall trigger the IIF to send 9 a GSM SMS with the MWN information. This is shown in section 4.13.5.1. The second event is when 10 the HLR receives a Message Waiting Notification for a subscriber that is already registered. In this 11 case, the ANSI-41 HLR shall send a Qualification Directive message to the IIF which shall translate it 12 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 a 14 GSM SMS-SC. 15
The scenarios that follow only show the MWN SMS delivery via GPRS. 16
17
N.S0028
Post Ballot Version 219
4.13.5.1 Indicator in ANSI-41 Registration Notification Return Result mapped to 1 GSM SMS 2
Figure 130: Indicator in ANSI-41 Registration Notification Return Result mapped to GSM SMS 3
a. The Voice Mail System (VMS) receives a voice mail for a specific subscriber. 4 5 b. The VMS send the “Message Waiting Notification” (MWN) to the ANSI-41 HLR of the voice mail 6
recipient. Note that the interface between the VMS and the ANSI-41 HLR is not standardized in 7 ANSI-41.D [1]. Note also that at that point in time, the subscriber is not registered in any serving 8 system, so the HLR just keeps the information that a voice mail was received. 9
10 c. The Mobile Station accesses a serving system and originates an update location request. 11 12 d. The Update Location is sent from the serving GSM MSC/VLR to the IIF, seen as the GSM HLR 13
for that subscriber. 14 15 e. The IIF sends a Registration Notification to the ANSI-41 HLR of the subscriber. 16 17 f. The ANSI-41 HLR replies with the Registration Notification Return Result containing the 18
“Message Waiting Notification” information that consists of two parameters: 19 MessageWaitingNotificationCount (MWNCOUNT) and MessageWaitingNotificationType 20 (MWNTYPE). For a description of these parameters, refer to the ANSI-41.D specifications, 21 sections 6.5.2.78 and 6.5.2.79 [1]. 22
n TDMAVMS
TDMAHLR IIF
GSMSGSN 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
①
②
N.S0028
Post Ballot Version 220
1 ➀ At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification is to 2 be delivered to the Mobile Station. 3 4 g. The IIF sends Insert Subscriber Data to the serving GSM SGSN. Note that there could be more 5
than one Insert Subscriber Data message depending on the subscriber profile. 6 7 h. The serving GSM SGSN returns the Insert Subscriber Data result. Note that there could be more 8
than one such result message, one matching every Insert Subscriber Data message. 9 10 i. The IIF completes the location update by sending the Update Location result message to the 11
serving GSM SGSN. 12 13 j. The serving GSM SGSN confirms the update location to the mobile station. 14 15 k. Since the REGNOT return result from event f contained the Message Waiting Notification 16
information, this triggers the IIF to originate an SMS with MWN information by sending Forward 17 Short Message to the serving GSM SGSN. The IIF is then acting as a GSM SMS-GMSC. The IIF 18 is to encode the MWN information in the SMS with three methods, namely, UDH, DCS, and 19 CPHS. Refer to Volume 3 for the encoding details. 20
21 l. The serving GSM SGSN sends the short message with the MWN information to the mobile 22
station. 23 24 m. The mobile station acknowledges the delivery of the short message. 25 26 n. The serving GSM SGSN sends the result of the Forward Short Message to the IIF. 27 28 ➁ At this point, the IIF clears the MWN flag. The reception of the Forward Short Message Result 29 without error indicates that the MWN information was delivered successfully to the Mobile Station. 30
31 32
N.S0028
Post Ballot Version 221
1 4.13.5.2 ANSI-41 Qualification Directive mapped to GSM SMS 2
Figure 131: ANSI-41 Qualification Directive mapped to GSM SMS 3
a. The Voice Mail System (VMS) receives a voice mail for a specific subscriber. 4 5 b. The VMS send the “Message Waiting Notification” (MWN) to the ANSI-41 HLR of the voice mail 6
recipient. Note that the interface between the VMS and the ANSI-41 HLR is not standardized in 7 ANSI-41 [1]. 8
9 c. Since the subscriber has a current valid location stored in the HLR, the HLR initiates a 10
Qualification Directive message with the MWN information to the IIF acting as the serving ANSI-11 41 MSC/VLR. The MWN information consists of two parameters: 12 MessageWaitingNotificationCount (MWNCOUNT) and MessageWaitingNotificationType 13 (MWNTYPE). For a description of these parameters, refer to the ANSI-41-D specifications, 14 sections 6.5.2.78 and 6.5.2.79 [1]. 15
16 ➀ At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification 17 is to be delivered to the Mobile Station. 18
19 d. The IIF sends the result of the Qualification Directive message to the ANSI-41 HLR. 20 21 e. The IIF also originates an SMS with MWN information by sending a Forward Short Message to 22
the serving GSM SGSN. The IIF is then acting as a GSM SMS-GMSC. The IIF is to encode the 23 MWN information in the SMS with three methods, namely, UDH, DCS, and CPHS. Refer to 24 Volume 3 for the encoding details. 25
26
.............................................................
①
GSMSGSN MS
e
f
g
h
FORW. SHORTMESSAGE (MWN)
SMS Delivery (MWN)
SMS DeliveryAck
Forw. Short Message
②
TDMAVMS
TDMAHLR
a
b
c
VmailDelivery
“Message WaitingNotification”
QUALDIR(MWNCOUNT,MWNTYPE)
qualdir
IIF
d
N.S0028
Post Ballot Version 222
f. The serving GSM SGSN sends the short message with the MWN information to the mobile 1 station. 2
3 g. The mobile station acknowledges the delivery of the short message. 4 5 h. The serving GSM SGSN sends the result of the Forward Short Message to the IIF. 6 7 ➁ At this point, the IIF clears the MWN flag. The reception of the Forward Short Message Result 8 without error indicates that the MWN information was delivered successfully to the Mobile Station. 9
4.13.5.3 Handling at SMS delivery failure at the SGSN or at the Mobile Station 10
The IIF is to keep a Message Waiting Notification (MWN) flag for each subscriber in its database. In 11 the event of a failure to deliver a short message with MWN to the mobile station, the IIF is to keep the 12 MWN flag set. Another Forward Short Message with MWN information shall be sent, triggered by the 13 reception of a subsequent GSM Update Location message, a Ready for Short Message, or a Note 14 MS Present message. This is illustrated in the following diagram. 15
16
Figure 132: Handling at SMS delivery failure at the SGSN or at the MS 17
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②
①
N.S0028
Post Ballot Version 223
a. The IIF receives Message Waiting Notification (MWN) information from a Qualification Directive 1 or a Registration Notification Return Result. This was described in Sections 4.13.5.1 and 2 4.13.5.2. 3
4 ➀ At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification 5 is to be delivered to the Mobile Station. 6
7 b. The IIF originates an SMS with MWN information by sending Forward Short Message using MAP 8
V2 to the serving GSM SGSN. The IIF is then acting as a GSM SMS-GMSC. The IIF is to encode 9 the MWN information in the SMS with three methods, namely, UDH, DCS, and CPHS. Refer to 10 Volume 3 for the encoding details. 11
12 c. The serving GSM SGSN may attempt to deliver the short message or may immediately find out 13
that there is an error and reply (step e below) to the IIF. 14 15 d. The Mobile Station returns an error message to the SMS delivery. 16 17 e. The serving GSM SGSN sends an Error, Abort or Reject message to the IIF, either resulting from 18
the reception of an error message from the MS or from an internal event such as an error or a 19 timeout. Note also, that a timeout may also occur in the IIF itself. Note that this may result in the 20 IIF setting the GSM 03.40 MNRF/MNRG/MCEF flag depending on the error cause received (see 21 section 4.13.3.1.3 “Unsuccessful Mobile Terminated Delivery (Failure at SGSN)”. 22
23 f. Time elapsed. 24 25 g. A new serving GSM SGSN sends an Update GPRS Location message to the IIF acting as a GSM 26
HLR for that subscriber. Note that the normal Update Location sequence is not shown in this 27 diagram. Or it could be a 28
29 h. Ready for Short Message (MAP V3) 30 31 32 i. The IIF shall reply with the corresponding acknowledgement message. Upon receipt of g, h, or i 33
above, the procedures in section 4.13.3.1.5 “Alerting for an ANSI-136 41 Subscriber for GPRS in 34 GSM Foreign Mode” apply (GSM 03.40 flags may be cleared and the SMSNOT may be sent to 35 the MC if appropriate). 36
37 j. Triggered by event g, h, or i above, the IIF originates a new Forward Short Message with MWN 38
information to the serving GSM SGSN. The IIF is to encode the MWN information in the SMS with 39 three methods, namely, UDH, DCS, and CPHS. 40
41 k. The serving GSM SGSN sends the short message with the MWN information to the mobile 42
station. 43 44 l. The mobile station acknowledges the delivery of the short message. 45 46 m. The serving GSM SGSN sends the result of the Forward Short Message to the IIF. 47 48 49 ➁ At this point, the IIF clears the MWN flag. The reception of the Forward Short Message Result 50 without error indicates that the MWN information was delivered successfully to the Mobile Station. 51
52
53
N.S0028
Post Ballot Version 224
4.13.6. Call Delivery Scenarios 1
This section describes the scenarios for call delivery to an MS that is roaming in a GPRS network in 2 GSM foreign mode. 3
4.13.6.1 Call Delivery Scenarios in GSM Foreign Mode while GSM CS and GPRS Attached 4
5
4.13.6.1.1 Call Delivery to ANSI-136 41 Subscriber Roaming on a GSM/GPRS Network 6
Figure 133: Call Delivery to ANSI-136 41 Subscriber Roaming in GSM/GPRS Network 7
8
a. The originating ANSI-41 MSC receives an incoming call from the PSTN for a subscriber that is 9 roaming in a GSM/GPRS network. This MS is registered simultaneously with an SGSN and a 10 GSM MSC/VLR. 11
b. The O-MSC sends a LOCREQ to the ANSI-41 HLR 12
c. The ANSI-41 HLR knows the address of the IIF (acting as an ANSI-41 serving MSC) and sends a 13 ROUTEREQ to it 14
d. The call may be delivered if the IIF determines that the called MS is registered with on a GSM 15 MSC/VLR. As such, the IIF (acting as a GSM HLR) sends the serving GSM MSC/VLR a MAP 16 Provide Roaming Number (PRN). 17
MS IIFMSCSGSN HLR
a
b
c
d
e
f
g
h
i
GSM ANSI
O-MSC
Incoming callLOCREQ
ROUTEREQ
routereq
locreq
ISUP signaling / SS7PAGING-REQ
Paging Procedure
SUSPEND ToBSS
PRN
prn
j
k
N.S0028
Post Ballot Version 225
e. The serving GSM MSC/VLR responds with a prn to the PRN operation providing a temporary 1 routing number. 2
f. The IIF forwards this number to the ANSI-41 HLR in the routereq. 3
g. The ANSI-41 HLR forwards a locreq to the O-MSC with the temporary routing number. 4
h. The O-MSC proceeds to contact the serving GSM MSC/VLR exchanging ISUP signaling for call 5 setup. 6
i. The serving GSM MSC/VLR realizes that the MS is actually attached to an SGSN. So the GSM 7 serving MSC/VLR sends a BSSAP+PAGING-REQUEST to the SGSN. 8
j. The SGSN executes a Paging procedure for circuit services. 9
k. The MS sends a SUSPEND REQ to the BSS that may be forwarded to the SGSN. At this point, 10 the MS can respond to the page via GSM cell sites to the serving GSM MSC/VLR. 11
12
N.S0028
Post Ballot Version 226
4.13.6.1.2 Call Delivery to ANSI-136 41 Subscriber Roaming in a GPRS Network 1 (Unsuccessful) 2
The following scenario describes the case where a subscriber in GSM foreign mode is roaming in a 3 GPRS network. The MS is attached for GPRS-only services. The IIF has already registered itself (as 4 an ANSI-41 MSC) with the ANSI-41 HLR. Since the MS is attached for GPRS-only service, incoming 5 calls are not deliverable to the subscriber. This scenario attempts to describe what happens in the 6 case of an incoming call to an MS attached for GPRS services only. 7
8 Figure 134: MS Notification of a “Missed” Call via SMS 9
10
a. The O-MSC receives an incoming call for the subscriber roaming in the GSM network 11
b. The O-MSC sends the HLR a LOCREQ 12
c. The HLR has the address of the IIF (acting as an ANSI-41 MSC) and sends a ROUTEREQ to the 13 IIF 14
d. The IIF recognizes that fact this is a GAIT subscriber roaming in a GSM network. The IIF, from 15 its dynamic data, sees that the subscriber is attached for GPRS-only services and hence, cannot 16 have call delivery. The IIF sends a routreq with the field “AccessDeniedReason” set to 17 “Unavailable” or “No Page Response”. 18
e. The HLR returns a locreq to the O-MSC. At this point, the calling party may receive secondary 19 treatment. 20
SGSN HLRIIF MSC
a
b
c
d
e
f
g
h
GSM ANSI
MS
Incoming call
LOCREQ
ROUTEREQ
routereq
locreq
FSM
fsm
SMS Exchange
N.S0028
Post Ballot Version 227
f. The IIF contains the functionality to act as an SMS-SC. In this case, the IIF has the calling party 1 DN available (from the ROUTEREQ message). The IIF proceeds to act as an SMS-SC and 2 sends an FSM to the SGSN requesting the SGSN to deliver an SMS message containing the 3 calling party’s DN to the MS. 4
g. The SGSN sends the MS the SMS message containing the DN of the calling party and the MS 5 acknowledges receipt of the SMS message. 6
h. The SGSN acknowledges the request and sends back an fsm. 7
8
N.S0028
Post Ballot Version 228
4.13.6.2 Successful Network-Requested PDP Context Activation Procedure 1
The network requested PDP Context Activation procedure allows the GGSN to initiate the activation 2 of a PDP context when a data packet arrives for a particular PDP address and no PDP context has 3 been previously established. 4
5
1Figure 135: Successful Network Requested PDP context Activation 6
1 7
a. When receiving a PDP PDU the GGSN follows the procedures described in GSM 03.60 [10] 8 1 9
b. The GGSN may send a Send Routeing Information for GPRS (IMSI) message to the IIF. 10 1 11
c. The IIF determines if the request can be served. If the request can be served it returns a Send 12 Routeing Information for GPRS Ack (IMSI, SGSN Address) to the GGSN. If the request cannot 13 be served it returns a Send Routeing Information for GPRS Ack (IMSI, MAP Error Cause). 14
15
d. Steps d through l are provided for completeness and are outside the scope of this specification. 16
Note: Certain security procedures as in step h) may be invoked. 17
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
N.S0028
Post Ballot Version 229
4.13.6.3 Unsuccessful Network-Requested PDP Context Activation Procedure 1
If the PDP context requested by the GGSN cannot be established, the IIF in conjunction with the 2 SGSN and GGSN may perform the Protection and Mobile User Activity Procedures as described in 3 GSM 03.60 [10]. The IIF acting as a GPRS HLR shall follow the same procedures as the GSM HLR. 4
4.13.7 Packet Domain Subscriber Data in the IIF 5
GPRS subscriber data shall be provisioned in the IIF (emulating a GPRS HLR) to support GPRS 6 service capability in GSM Foreign mode. The IIF shall store the same subscription information as 7 identified in GSM 03.60 [10]. 8
It may be possible to provision an ANSI-136 41 native subscriber with GPRS-only service (and no 9 GSM CS service) 10
11
N.S0028
Post Ballot Version 230
Annex A (informative) 1
The following is an example of some of the timers defined in existing ANSI-41 and GSM 2 specifications. 3
As an example, the GSM timer controlling, the Update Location Request is defined to be in the range 4 15s to 30s whereas the equivalent ANSI-41 timer controlling the REGNOT is defined to be a default 5 value of 12s. 6
7
N.S0028
Post Ballot Version 231
LOCATION REGISTRATION PROCEDURES
GSM Operation
Timer Value ANSI-41 Operation
Timer Value
Update Location Request
15s to 30s REGNOT 12s
Insert Sub Data
15s to 30s
CALL DELIVERY PROCEDURES
GSM Operation
Timer Value ANSI-41 Operation
Timer Value
Provide Roaming Number
15s to 30s ROUTREQ 10s
SUBSCRIBER DATA MANAGEMENT PROCEDURES
GSM Operation
Timer Value ANSI-41 Operation
Timer Value
Cancel Location Request
15s to 30s REGCANC 6s
Delete Sub Data
15s to 30s QUALDIR 6s
SUPPLEMENTARY SERVICE PROCEDURES
GSM Operation
Timer Value ANSI-41 Operation
Timer Value
REGISTER SS 15s to 30s FEATREQ 16s
ERASE SS 15s to 30s
ACTIVATE SS 15s to 30s
DE-ACTIVATE SS
15s to 30s
OPTIMAL ROUTING PROCEDURES
GSM Operation
Timer Value ANSI-41 Operation
Timer Value
Resume Call Handling
15s to 30s REDREQ 22s
TRANUMREQ 16s
SHORT MESSAGE PROCEDURES
GSM Operation
Timer Value ANSI-41 Operation
Timer Value
Forward SM 1m to 10m SMDPP 6s 1
Notes: GSM timer values are defined as a range of values, whereas ANSI-41 defines a default timer 2 value. 3
4
N.S0028
Post Ballot Version 232
Annex B - CDMA to GSM One-way Roaming Only 1
Optionally, IIF may support one way-roaming only from CDMA to GSM network. In this case, all the 2 flows below are applicable only in GSM Foreign Mode. ANSI-41 HLR/AC must be compliant with 3 TIA/EIA-868 [16]. All the changes are made on the assumption the new requirements for 4 UIM/handsets are working. 5
6
N.S0028
Post Ballot Version 233
B.1 - Successful Authentication on Initial Access in 1
GSM System 2
3 This scenario illustrates the successful authentication of an MS on the initial MS access is a GSM 4 system 5
6
Figure 136 – Successful Authentication on Initial Access in GSM System 7
8
a) The MS determines that a new serving system has been entered. The MS registers at the new GSM 9 serving system and provides its IMSI. 10
11 b) The GSM serving system sends a SEND_AUTHENTICATION_INFO to the IIF. 12
13 c) The IIF sends an AUTHREQ to the HLR associated with the MS. The MSCID parameter identifies the 14
IIF. The SYSCAP parameter is set to indicate GSM system. The ESN parameter is set to a default 15 value. The SYSACCTYPE parameter is set to indicate GSM system access. 16
AC HLR
IIF
SEND_AUTH_INFO (IMSI)
AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC)
Authreq (SSD, ESN)
Authreq (SSD, ESN)
SEND_AUTH_INFO ack (AuthenticationSetList)
UPDATE LOCATION (IMSI)
MSC/ VLR
authentication (RAND)
authentication ack (SRES)
a
b
c
d
e
h
i
j
k
l
m
MSC/ VLR
ANSI-41 GSM
Location area update (IMSI)
AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC)
ASREPORT (MSCID, MSID, UCHALRPT)
ASREPORT (MSCID, MSID, UCHALRPT)
asreport[]
g
o REGNOT [MSCID, TRANSCAP, SYSCAP, MSID, ESN, SYSAC]
ART ART
ASRRT
ASRRT ASRRT
asreport[] ASRT
N.S0028
Post Ballot Version 234
1 d) The HLR forwards the AUTHREQ to the AC. 2
3 e) The AC determines that the subscriber is roaming in a GSM system. The AC includes the SSD 4
parameter in the authreq sent to the HLR. The ESN parameter is set to the indicated MS’s ESN. 5 6
f) The HLR forwards the authreq to the IIF. 7 8 g) The IIF stores the received SSD and ESN. The IIF computes one or more groups of GSM triplets using 9
the subscriber’s SSD. The IIF sends a SEND_AUTHENTICATION_INFO ack to the GSM system and 10 includes the groups of triplets. 11
12 h) The GSM system issues a random challenge to the MS 13
14 i) The MS responds to the challenge with the computed response. 15
16 j) The GSM system compares the response received from the MS with the expected response. In this 17
scenario, the response is equal to the expected response. The GSM system sends a 18 UPDATE_LOCATION to the IIF. The IMSI is used to identify the MS. 19
20 k) The IIF sends an ASREPORT to the HLR associated with the MS. The UCHALRPT parameter is set 21
to indicate Unique Challenge successful. 22 23
l) The HLR forwards the ASREPORT to the AC. 24 25
m) The AC sends an asreport to the HLR. 26 27
n) The HLR forwards the asreport to the IIF. 28 29
o) The IIF sends a REGNOT to the HLR 30 31
p) The HLR sends a regnot to the IIF with the subscriber’s service profile 32 33
q) The IIF sends an INSERT_SUBSCRIBER_DATA to the GSM system. 34 35
r) The GSM systems sends an INSERT_SUBSCRIBER_DATA ack to the IIF. 36 37
s) The IIF sends an LOCATION_UPDATE ack to the GSM system. 38 39
t) The GSM system sends a location area update ack to the MS. 40
41
N.S0028
Post Ballot Version 235
B.2 Authentication Failure on Initial Access in GSM System 1
This scenario illustrates an authentication failure on the initial MS access is a GSM system. 2 The GSM system reports the authentication failure to the IIF. 3 4
5
Figure 137 - Authentication Failure on Initial Access in GSM System 6
7
AC HLR
IIF
SEND_AUTH_INFO (IMSI)
AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC)
Authreq (SSD, ESN)
Authreq (SSD, ESN)
SEND_AUTH_INFO ack (AuthenticationSetList)
UPDATE LOCATION (IMSI)
MSC/ VLR
authentication (RAND)
authentication ack (SRES)
a
b
c
d
e
h
i
j
k
l
m
MSC/ VLR
ANSI-41 GSM
Location area update (IMSI)
AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC)
ASREPORT (MSCID, MSID, UCHALRPT)
ASREPORT (MSCID, MSID, UCHALRPT)
asreport[DENACC]
g
o AUTHENTICATION_FAILURE
ART ART
ASRRT
ASRRT ASRRT
asreport[DENACC]
N.S0028
Post Ballot Version 236
a-i. Same as Scenario 5.Y.1, Steps a-i. 1 2 j) The GSM system compares the response received from the MS with the expected response. In this 3
scenario, the response does equal to the expected response. The GSM system sends an 4 AUTHENTICATION_FAILURE to the IIF. The subscriber’s IMSI is used to identify the MS. 5
6 k) The IIF sends an ASREPORT to the HLR associated with the MS. The UCHALRPT parameter is set 7
to indicate Unique Challenge failed. 8 9
l) The HLR forwards the ASREPORT to the AC. 10 11
m) The AC includes the DENACC parameter and sends an asreport to the HLR. 12 13
n) The HLR forwards the asreport to the IIF. The IIF removes the SSD, ESN and other information 14 stored for the MS. 15
16 o) The IIF sends an AUTHENTICATION_FAILURE ack to the GSM system. 17
18 p) The GSM system sends a location area update reject to the MS.19
N.S0028
Post Ballot Version 237
B.3 Authentication Failure on Initial Access 1
in GSM System – Authentication Failure 2
Message Not Supported 3
4 This scenario illustrates an authentication failure on the initial MS access is a GSM system. The GSM 5 system doe not report the authentication failure to the IIF 6
7 Figure 138 - Authentication Failure on Initial Access in GSM System – Authentication 8 Failure Message Not Supported 9 10 a-i. Same as Scenario 5.Y.1, Steps a-i. 11 12 j) The GSM system compares the response received from the MS with the expected response. In this 13
scenario, the response does equal to the expected response. The GSM system compares the response 14 received from the MS with the expected response. In this scenario, the response does equal to the 15 expected response. The GSM system sends a location area update reject to the MS. 16
17 k) An IIF timer expires when no message for the MS is received from the GSM system. 18
19
AC HLR
IIF
SEND_AUTH_INFO (IMSI)
AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC)
Authreq (SSD, ESN)
Authreq (SSD, ESN)
SEND_AUTH_INFO ack (AuthenticationSetList)
Location area update reject
MSC/ VLR
authentication (RAND)
authentication ack (SRES)
a
b
c
d
e
h
i
j
k
l
m
MSC/ VLR
ANSI-41 GSM
Location area update (IMSI)
AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC)
ASREPORT (MSCID, MSID, UCHALRPT)
ASREPORT (MSCID, MSID, UCHALRPT)
asreport[DENACC]
g
o
ART ART
ASRRT
ASRRT ASRRT
asreport[DENACC]
timer expiry
timer
N.S0028
Post Ballot Version 238
l) The IIF sends an ASREPORT to the HLR associated with the MS. The UCHALRPT parameter is set 1 to indicate Unique Challenge failed. 2
3 m) The HLR forwards the ASREPORT to the AC. 4
5 n) The AC includes the DENACC parameter and sends an asreport to the HLR. 6
7 o) The HLR forwards the asreport to the IIF. The IIF removes the SSD, ESN and other information stored 8
for the MS. 9 10
11
N.S0028
Post Ballot Version 239
B.4 GSM System Request for Additional Triplets 1
This scenario illustrates a GSM system requesting addition triplets after the MS is register in the serving GSM 2 system. 3 4
Figure 139 - GSM System Request for Additional Triplets 5 6
a) The GSM system determines that additional triplets are required and sends a 7 SEND_AUTHENTICATION_INFO to the IIF. The IMSI identifies the subscriber. 8
b) The IIF computes one or more groups of triplets and includes them in the response to 9 the GSM system. (Note, the IIF may have pre-computed triplets for the MS that it 10 sends to the GSM system). 11
AC HLR
IIF
SEND_AUTHENTICATION_INFO (IMSI)
SEND_AUTH_INFO ack (AuthenticationSetList)
MSC/ VLR
a
b
MSC/ VLR
ANSI-41 GSM
N.S0028
i
Abstract 1
2
This standard addresses the interworking and interoperability between ANSI-41 MAP and GSM 3 based networks in the support of subscribers roaming between networks. The interworking and 4 interoperability functionality of the services, information flows, and message mappings are 5 specified. This standard consists of four Volumes: 6
7
Volume 0 - Overview and Interworking Reference Model 8
Volume 1 - Service Descriptions 9
Volume 2 - Information Flows 10
Volume 3 - Message Mappings 11
12
This is Volume 3. 13
14
N.S0028
ii
1
Document Revision History 2
Revision Date
Version Comments
0 March 2001 Initial Release J-STD-038
A May 23, 2001 draft GPRS text added: section 4.6.
A July 9, 2001 0 Misc. editorial changes.
A August 1, 2001 1 Review changes.
A August 14, 2001 1 Review changes.
A August 15, 2001 2 Editorial changes. Ballot version.
A November 27, 2001
3 Incorporation of agreed ballot comments
B July 2001 3 Version 3: Addition of CDMA/GSM two way roaming
B March 2002 5 Version V&V: Addition of CDMA/GSM two way and one roaming
3
4
5
6
N.S0028
iii
1
Contents 2
3
ABSTRACT .......................................................................................................................................I 4
DOCUMENT REVISION HISTORY....................................................................................................II 5
CONTENTS .....................................................................................................................................III 6
LIST OF TABLES .......................................................................................................................... VII 7
LIST OF FIGURES........................................................................................................................XXI 8
FOREWORD................................................................................................................................XXII 9
1 INTRODUCTION........................................................................................................................1 10
1.1 General............................................................................................................................................... 1 11
1.2 Purpose............................................................................................................................................... 1 12
1.3 Scope .................................................................................................................................................. 1 13
1.4 Organization ...................................................................................................................................... 1 14
2 REFERENCES...........................................................................................................................3 15
3 DEFINITIONS AND ACRONYMS...............................................................................................4 16
3.1 Definitions .......................................................................................................................................... 4 17
3.2 Acronyms ........................................................................................................................................... 6 18
4 MESSAGE MAPPINGS............................................................................................................10 19
4.1 Mobility Procedures......................................................................................................................... 10 20 4.1.1 Location Registration ................................................................................................................. 10 21 4.1.2 Fault Recovery ........................................................................................................................... 23 22
4.2 Call Handing Procedures................................................................................................................. 26 23 4.2.1 Automatic Call Delivery............................................................................................................. 26 24 4.2.2 Invocation of Conditional Call Forwarding in ANSI-41 Foreign Mode ........................................ 40 25 4.2.3 Optimal Routing after Late Call Forwarding ............................................................................... 44 26
4.3 Supplementary Services Procedures................................................................................................ 53 27
N.S0028
iv
4.3.1 SS Activation and Deactivation................................................................................................... 53 1 4.3.2 SS Registration and Erasure........................................................................................................ 70 2 4.3.3 Retrieval of Forward-To Number................................................................................................ 94 3 4.3.4 Calling Number / Line Identification Presentation/Restriction ..................................................... 98 4
4.4 O&M Procedures........................................................................................................................... 105 5 4.4.1 Detailed Procedures.................................................................................................................. 105 6 4.4.2 Mapping of Messages, Parameters & Parameter Values............................................................. 106 7 4.4.3 Error Handling ......................................................................................................................... 126 8
4.5 Short Message Procedures (ANSI-41 Network) ............................................................................ 131 9 4.5.1 Short Message Service via CMT............................................................................................... 131 10 4.5.2 Short Message Service via GHOST or WEMT.......................................................................... 150 11 4.5.3 Message Waiting Notification................................................................................................... 161 12
4.6 GPRS IN GSM FOREIGN MODE........................................................................................170 13 4.6.1 Mobility Procedures ................................................................................................................. 170 14 4.6.2 Automatic Call Delivery........................................................................................................... 177 15 4.6.3 Short Message Procedures for ANSI-41 subscriber ................................................................... 180 16 4.6.4 Short Message Service via GHOST or WEMT.......................................................................... 183 17 4.6.5 Message Waiting Notification................................................................................................... 184 18
ANNEX A SHORT MESSAGE SERVICE PROCEDURES WITHIN AN ANSI-136 NETWORK ......186 19
A.1 CMT to GHOST Delivery.............................................................................................................. 186 20 A.1.1 Detailed Procedures.................................................................................................................. 186 21 A.1.2 Mapping of Messages, Parameters & Parameter Values............................................................. 186 22 A.1.3 Error Handling ......................................................................................................................... 188 23
A.2 GHOST to CMT Delivery.............................................................................................................. 188 24 A.2.1 Detailed Procedures.................................................................................................................. 189 25 A.2.2 Mapping of Messages, Parameters & Parameter Values............................................................. 190 26 A.2.3 Error Handling ......................................................................................................................... 194 27
A.3 Callback Number ........................................................................................................................... 195 28 A.3.1 Detailed Procedures.................................................................................................................. 195 29 A.3.2 Message Mapping, Parameters and Parameters Values .............................................................. 196 30 A.3.3 Error Handling ......................................................................................................................... 196 31
ANNEX B CAUSE CODE MAPPING AT NON-IIF NODES............................................................197 32
ANNEX C: CDMA TO GSM ONE-WAY ROAMING ONLY.............................................................198 33
ABSTRACT .......................................................................................................................................I 34
DOCUMENT REVISION HISTORY....................................................................................................II 35
CONTENTS .....................................................................................................................................III 36
LIST OF TABLES ............................................................................................................................ V 37
N.S0028
v
LIST OF FIGURES......................................................................................................................... XII 1
FOREWORD................................................................................................................................. XIII 2
1 INTRODUCTION........................................................................................................................1 3
1.1 General ..................................................................................................................................1 4
1.2 Purpose .................................................................................................................................1 5
1.3 Scope.....................................................................................................................................1 6
1.4 Organization..........................................................................................................................1 7
2 REFERENCES...........................................................................................................................3 8
3 DEFINITIONS AND ACRONYMS...............................................................................................4 9
3.1 Definitions .............................................................................................................................4 10
3.2 Acronyms ..............................................................................................................................6 11
4 MESSAGE MAPPINGS..............................................................................................................9 12
4.1 Mobility Procedures..............................................................................................................9 13 4.1.1 Location Registration........................................................................................................9 14 4.1.2 Fault Recovery...............................................................................................................22 15
4.2 Call Handing Procedures....................................................................................................25 16 4.2.1 Automatic Call Delivery ..................................................................................................25 17 4.2.2 Invocation of Conditional Call Forwarding in ANSI-41 Foreign Mode...............................38 18 4.2.3 Optimal Routing after Late Call Forwarding ....................................................................42 19
4.3 Supplementary Services Procedures.................................................................................51 20 4.3.1 SS Activation and Deactivation.......................................................................................51 21 4.3.2 SS Registration and Erasure ..........................................................................................68 22 4.3.3 Retrieval of Forward-To Number ....................................................................................92 23 4.3.4 Calling Number / Line Identification Presentation/Restriction...........................................96 24
4.4 O&M Procedures...............................................................................................................103 25 4.4.1 Detailed Procedures.....................................................................................................103 26 4.4.2 Mapping of Messages, Parameters & Parameter Values ..............................................104 27 4.4.3 Error Handling..............................................................................................................123 28
4.5 Short Message Procedures (ANSI-136 Network) .............................................................128 29 4.5.1 Short Message Service via CMT ..................................................................................128 30 4.5.2 Short Message Service via GHOST..............................................................................145 31 4.5.3 Message Waiting Notification .......................................................................................156 32
4.6 GPRS IN GSM FOREIGN MODE........................................................................................165 33 4.6.1 Mobility Procedures......................................................................................................165 34
N.S0028
vi
4.6.2 Automatic Call Delivery ................................................................................................172 1 4.6.3 Short Message Procedures for ANSI-136 subscriber ....................................................175 2 4.6.4 Short Message Service via GHOST..............................................................................178 3 4.6.5 Message Waiting Notification .......................................................................................179 4
ANNEX A SHORT MESSAGE SERVICE PROCEDURES WITHIN AN ANSI-136 NETWORK ......181 5
A.1 CMT to GHOST Delivery....................................................................................................181 6 A.1.1 Detailed Procedures.....................................................................................................181 7 A.1.2 Mapping of Messages, Parameters & Parameter Values ..............................................181 8 A.1.3 Error Handling..............................................................................................................183 9
A.2 GHOST to CMT Delivery....................................................................................................183 10 A.2.1 Detailed Procedures.....................................................................................................184 11 A.2.2 Mapping of Messages, Parameters & Parameter Values ..............................................185 12 A.2.3 Error Handling..............................................................................................................189 13
A.3 Callback Number...............................................................................................................190 14 A.3.1 Detailed Procedures.....................................................................................................190 15 A.3.2 Message Mapping, Parameters and Parameters Values...............................................191 16 A.3.3 Error Handling..............................................................................................................191 17
ANNEX B CAUSE CODE MAPPING AT NON-IIF NODES............................................................192 18 19
20
N.S0028
vii
1
List of Tables 2
3
Table 1: Location Updating in GSM Foreign Mode Message Mapping........................................13 4
Table 2: Location Updating in ANSI-41 Foreign Mode Message Mapping...................................14 5
Table 3: MS Purging Message Mapping.....................................................................................14 6
Table 4: Location Cancellation Message Mapping......................................................................14 7
Table 5: UPDATE_LOCATION_REQUEST ↔ REGNOT Parameter Mapping............................14 8
Table 6: INSERT_SUBSCRIBER_DATA_REQUEST ↔ regnot Parameter Mapping ..................16 9
Table 7: UPDATE LOCATION RESPONSE ↔ regnot Parameter Mapping ................................17 10
Table 8: MS_PURGE_REQUEST ↔ MS INACTIVE Parameter Mapping...................................17 11
Table 9: CANCEL_LOCATION_REQUEST ↔ REGCANC Parameter Mapping .........................18 12
Table 10: UPDATE_LOCATION_RESPONSE to regnot Error Mapping .....................................21 13
Table 11: regnot return errors to UPDATE_LOCATION_RESPONSE Error Mapping .................22 14
Table 12 Fault Recovery Message Mapping ..............................................................................24 15
Table 13: GSM RESET ↔ ANSI UNRELDIR Parameter Mapping..............................................24 16
Table 14: Automatic Call Delivery Message Mapping.................................................................28 17
Table 15: ROUTREQ ↔ PROVIDE_ROAMING_NUMBER_REQUEST Parameter 18 Mapping ...................................................................................................................29 19
Table 16: Provide Roaming Number Response ↔ Routreq Return Result Parameter 20 Mapping ...................................................................................................................31 21
Table 17: PROVIDE_ROAMING_NUMBER_RESPONSE to Routreq Return Error Mapping 22 (ANSI-41Foreign Mode) ...........................................................................................31 23
Table 18: Routreq Return Error to Provide Roaming Number Response Error Mapping 24 (GSM Foreign mode)................................................................................................32 25
Table 19: Provide Roaming Number Request default parameter ................................................33 26
Table 20: RoutingRequest Return Result default parameters .....................................................34 27
Table 21: Routing Request Invoke default parameter.................................................................35 28
Table 22: PRN response User Error to routreq Return Error Mapping .......................................38 29
N.S0028
viii
Table 23: PRN Response Provider Error to routereq Return Error Mapping................................38 1
Table 24: RoutingRequest Return Result to User Error in the PRN response Error Mapping ......39 2
Table 25: Routing Request Return Error to PRN User Error Mapping.........................................39 3
Table 26: ROUTEREQ Return Result to Provide Roaming Number Response parameter 4 mapping (Option 1)...................................................................................................41 5
Table 27: ROUTREQ Return Result to Provide Roaming Number Response Parameter 6 Mapping (Option 2)...................................................................................................42 7
Table 28: Return Error to User Error in the PRN response Error Mapping ..................................43 8
Table 29: Optimal Routing for Late Call Forwarding Message Mapping......................................46 9
Table 30: GSM Provide_Roaming_Number ↔ ANSI-41 ROUTEREQ Parameter Mapping.........47 10
Table 31: Mapping of Parameter values.....................................................................................48 11
Table 32: Provide_Roaming_Number_Response ↔ routereq Parameter Mapping.....................48 12
Table 33: Mapping of Parameter Values ....................................................................................48 13
Table 34: Resume_Call_Handling ↔ REDREQ Parameter Mapping..........................................49 14
Table 35: Mapping of Parameters Values ..................................................................................49 15
Table 36: Resume_Call_Handling_Response ↔ redreq Parameter Mapping .............................49 16
Table 37: ANSI-41 Redirection_Reason to GSM Forwarding_Reason........................................50 17
Table 38: GSM Forwarding_Reason to ANSI-41 Redirection_Reason........................................50 18
Table 39: Provide_Roaming_Number to Routing_Request Error Mapping..................................51 19
Table 40: Routing_Request to Provide_Roaming_Number Error Mapping..................................51 20
Table 41: Resume_Call_Handling to Redirection_Request Error Mapping .................................52 21
Table 42: Redirection_Request to Resume_Call_Handling Error Mapping .................................52 22
Table 43: Supplementary Service Activation and Deactivation Message Mapping ......................56 23
Table 44: Activate/Deactivate SS Request ↔ FEATREQ Parameter Mapping............................56 24
Table 45: Activate/Deactivate SS Response ↔ Feature Request Return Result Parameter 25 Mapping ...................................................................................................................58 26
Table 46: Activate/Deactivate SS Response ↔ Feature Request Return Error Mapping.............59 27
Table 47: Activate/Deactivate SS Request to FEATREQ Parameter Mapping ............................59 28
Table 48: FEATREQ default parameter......................................................................................60 29
N.S0028
ix
Table 49: Activate/Deactivate SS Response default parameter values .......................................61 1
Table 50: Feature Request Invoke to Activate/Deactivate SS Request Parameter Mapping........62 2
Table 51: Activate/Deactivate SS Request default parameter.....................................................62 3
Table 52: FeatureRequest Return Result default parameter.......................................................63 4
Table 53: FeatureRequest Return Result to User Error in the Activate/Deactivate SS 5 Response Error Mapping..........................................................................................66 6
Table 54: FeatureRequest Return Error to Activate/Deactivate SS Response Error 7 Mapping ...................................................................................................................66 8
Table 55: Activate/Deactivate SS Response User Error to FeatureRequest Return Result 9 Mapping ...................................................................................................................67 10
Table 56: Activate/Deactivate SS Response User Error to FeatureRequest Return Error 11 Mapping ...................................................................................................................68 12
Table 57: Activate/Deactivate SS Response Provider Error to Feature Request Return 13 Error Mapping ..........................................................................................................69 14
Table 58: Supplementary Service Registration Message Mapping .............................................72 15
Table 59: Register SS Request ↔ FEATREQ parameter mapping.............................................73 16
Table 60: Register SS Response ↔ Feature Request Return Result Parameter Mapping ..........74 17
Table 61: Register SS Response ↔ Return Error Parameter Mapping.......................................75 18
Table 62: Register SS Request to Feature Request Invoke parameter mapping.........................76 19
Table 63: FEATREQ default parameter......................................................................................77 20
Table 64: Register SS Response default parameter values........................................................78 21
Table 65: FEATREQ to Register SS Request parameter mapping .............................................79 22
Table 66: Register SS Request default parameter......................................................................79 23
Table 67: FeatureRequest Return Result default parameter.......................................................80 24
Table 68: FeatureRequest Return Result to User Error in the Register SS Response 25 mapping ...................................................................................................................82 26
Table 69: Supplementary Service Erasure Message Mapping....................................................85 27
Table 70: Erase SS Request ↔ FEATREQ parameter mapping.................................................85 28
Table 71: Erase SS Response ↔ Feature Request Return Result parameter mapping ..............86 29
Table 72: Erase SS Response ↔ Return Error parameter mapping ...........................................87 30
Table 73: Erase SS Request to FEATREQ parameter mapping .................................................88 31
N.S0028
x
Table 74: Feature Request Invoke default parameter.................................................................89 1
Table 75: Erase SS Response default parameter values............................................................90 2
Table 76: FEATREQ to Erase SS Request parameter mapping ................................................91 3
Table 77: Erase SS Request default parameter .........................................................................91 4
Table 78: FeatureRequest Return Result default parameter.......................................................92 5
Table 79: FeatureRequest Return Result to Register SS Response User Error ..........................93 6
Table 80: Retrieval of Forward-to-Number in GSM Foreign Mode ..............................................95 7
Table 81: TransferToNumberRequest Return Result to Insert Subscriber Data parameter 8 mapping ...................................................................................................................96 9
Table 82: TransferToNumberRequest Return Result to Insert Subscriber Data Request 10 value mapping..........................................................................................................97 11
Table 83: Routing Request ↔ Provide Roaming Number Request (Network Provided 12 number) Parmater Mapping......................................................................................99 13
Table 84: Routing Request ↔ Provide Roaming Number Request (User Provided number) 14 Parameter Mapping................................................................................................100 15
Table 85: Routing Request ↔ Provide Roaming Number Request (Two calling party 16 numbers) Parameter Mapping ................................................................................101 17
Table 86: Routing Request ↔ Provide Roaming Number Request(Caller Id Restricted) 18 Parameter Mapping................................................................................................103 19
Table 87: Cancel_Location_Request ↔ REGCAN (Subscriber Deletion) Mapping ...................107 20
Table 88: Mapping of GSM MAP Messages ↔ ANSI MAP Messages (Subscriber Data 21 Modification)...........................................................................................................107 22
Table 89: Delete_Subscriber_Data ↔ Qualdir Mapping (Subscriber Data Modification)............107 23
Table 90: CANCEL_LOCATION_REQUEST ↔ REGCANC Parameter Mapping .....................108 24
Table 91: INSERT_SUBSCRIBER_DATA_REQUEST ↔ QUALDIR Parameter Mapping.........108 25
Table 92: INSERT_SUBSCRIBER_DATA_REQUEST ↔ profile ‘macro’ Mapping....................109 26
Table 93: Forwarding Information List to Calling Features Indicator Parameter Mapping ..........112 27
Table 94: Regional Subscription Data to Geographic Authorization Parameter Mapping...........114 28
Table 95: Call Barring Information List to Origination Indicator Parameter Mapping..................114 29
Table 96: SSData List to Calling Features Indicator Parameter Mapping..................................117 30
Table 97: Operator Determined Barring general data to Origination Indicator 31 Parameter Mapping................................................................................................119 32
N.S0028
xi
Table 98: Operator Determined Barring HPLMN data to Origination Indicator Parameter 1 Mapping .................................................................................................................121 2
Table 99: Operator Determined Barring HPLMN data to Restriction digits Parameter 3 Mapping .................................................................................................................121 4
Table 100: Call Barring Information List to SMS Origination Restrictions Parameter 5 Mapping .................................................................................................................122 6
Table 101: Call Barring Information List to SMS Termination Restrictions Parameter 7 Mapping .................................................................................................................123 8
Table 102: Call Barring Information List to Termination Restriction Code Parameter 9 Mapping .................................................................................................................124 10
Table 103: SSData List to SMS Origination Restrictions Parameter Mapping ...........................125 11
Table 104: SSData List to SMS Termination Restrictions Parameter Mapping..........................125 12
Table 105: ISD_RESPONSE and DSD_RESPONSE to Qualdir Return Error Mapping.............130 13
Table 106: Qualdir Return Error to INSERT_SUBSCRIBER_DATA_RESPONSE and 14 DELETE_SUSBCRIBER_DATA_RESPONSE Error Mapping.................................130 15
If the response to FSM indicates a failure in the delivery of the short message, the IIF shall 16 map the cause value received to a corresponding SMS_CauseCode value in 17 the SMDPP Return Result, as described in.............................................................132 18
Table 107: Short Message Service in GSM Foreign Mode (for CMT) Message Mapping ..........134 19
Table 108: Short Message Service in ANSI-41 Foreign Mode (for CMT) Message Mapping ....134 20
Table 109: SMDPP to MT_Forward Short Message Parameter Mapping for GSM Foreign 21 Mode......................................................................................................................135 22
Table 110: MT_Forward Short Message to SMDPP Parameter Mapping for ANSI-41 23 Foreign Mode.........................................................................................................136 24
Table 111: SM-RP-UI in MT_FORWARD_SHORT_MESSAGE for MAP V2 Parameter 25 Values for GSM Foreign Mode ...............................................................................136 26
Table 112: SM-RP-UI in MT_FORWARD_SHORT_MESSAGE for MAP V1 Parameter 27 Encoding for GSM Foreign Mode............................................................................138 28
Table 113: SMS_Bearer Data in Mobile Terminating SMDPP Parameter Encoding for 29 ANSI-41 Foreign Mode...........................................................................................139 30
Table 114: Forward_Short_Message to ANSI-41_SMDPP Parameter Mapping for MO SMS 31 in GSM Foreign Mode ............................................................................................140 32
Table 115: ANSI-41 SMDPP to GSM Forward_Short_Message Parameter Mapping for MO 33 SMS in ANSI-41 Foreign Mode...............................................................................141 34
Table 116: Forward_Short_Message to SMS_CauseCode Values in SMDPP Return Result 35 Error Mapping ........................................................................................................147 36
N.S0028
xii
Table 117: SMDPP to Forward_Short_Message Error Mapping ...............................................149 1
If the User Error parameter is populated in the GSM_FSM_ACK, then map this value into 2 the SMS_CauseCode according to.........................................................................151 3
Next, it populates the stored originating SMSC address and transaction ID. If the User 4 Error parameter is populated in GSM_FSM_ACK, then this value is mapped into 5 the SMS_CauseCode according to.........................................................................153 6
Table 118: Short Message Service (for GHOST or WEMT) Message Mapping.........................153 7
Table 119: Alerting for an ANSI-41 Subscriber in GSM Foreign Mode Parameter Mapping.......154 8
Table 120: Alerting for a GSM Subscriber in ANSI-41 Foreign Mode Parameter Mapping ........155 9
Table 121: SMDPP to Forward Short Message for Mobile Terminated 10 GHOST/WEMTTeleservice Parameter Mapping in GSM Foreign Mode ..................155 11
Table 122: Forward Short Message to SMDPP for Mobile Terminated GHOST/WEMT 12 Teleservice Parameter Mapping in ANSI Foreign Mode..........................................156 13
Table 123: Forward Short Message to SMDPP for Mobile Originated GHOST/WEMT in 14 GSM Foreign Mode Parameter Mapping.................................................................157 15
Table 124: SMDPP to Forward Short Message for Mobile Originated GHOST/WEMT 16 Teleservice Parameter Mapping in ANSI-41 Foreign Mode.....................................158 17
Table 125: HLPI for GHOST ....................................................................................................158 18
The IIF is responsible for mapping GSM MAP_FSM_ACK Return Errors to ANSI-41 19 SMS_CauseCodes according to.............................................................................159 20
Table 126: Teleservice Server Address Mapping in IIF.............................................................160 21
Table 127: Message Waiting Notification in GSM Foreign Mode Message Mapping .................163 22
Table 128: Message Waiting Notification in ANSI-41 Foreign Mode Message Mapping ............163 23
Table 129: Regnot to Forward Short Message for Message Waiting Notification Parameter 24 Mapping .................................................................................................................164 25
Table 130: QUALDIR to Forward Short Message for Message Waiting Notification 26 Parameter Mapping................................................................................................164 27
Table 131: Forward Short Message to QUALDIR for Message Waiting Notification 28 Parameter Mapping................................................................................................165 29
Table 132: Forward Short Message to SMDPP for Message Waiting Notification Parameter 30 Mapping .................................................................................................................165 31
Table 133: SM-RP-UI in Message FORWARD-SHORT-MESSAGE For MAP V2 Parameter 32 Encoding................................................................................................................166 33
Table 134: SM-RP-UI in Message FORWARD_SHORT-MESSAGE for MAP V1 Parameter 34 Encoding................................................................................................................168 35
N.S0028
xiii
Table 135: qualdir return error to FORWARD_SHORT_MESSAGE response Error 1 Mapping .................................................................................................................169 2
Table 136: SMSDPP to FORWARD_SHORT_MESSAGE response Error Mapping .................169 3
Table 137: Location Updating GPRS in GSM Foreign Mode Message Mapping .......................171 4
Table 138: MAP_UPDATE_GPRS_LOCATION_REQUEST → REGNOT Parameter 5 Mapping .................................................................................................................172 6
Table 139: MAP_INSERT_SUBSCRIBER_DATA_REQUEST → regnot Parameter Mapping ...173 7
Table 140: MAP_UPDATE GPRS LOCATION RESPONSE → regnot Parameter Mapping.......174 8
Table 141: MAP_INSERT_SUBSCRIBER_DATA_REQUEST → profile ‘macro’ Mapping.........175 9
Table 141 A: ROUTREQ → MT_Forward Short Message Parameter Mapping ........................178 10
If the response to FSM indicates a failure in the delivery of the short message, the IIF shall 11 map the cause value received to a corresponding SMS_CauseCode value in 12 the SMDPP Return Result, as described in.............................................................181 13
Table 142: Alerting for an ANSI-41 Subscriber for GPRS in GSM Foreign Mode Parameter 14 Mapping .................................................................................................................182 15
If the User Error parameter is populated in the GSM_FSM_ACK, then map this value into 16 the SMS_CauseCode according to.........................................................................183 17
Table 143: ANSI-136-710 to GHOST Parameter Mapping........................................................187 18
Table 144: TP Derived Values .................................................................................................188 19
Table 145: GHOST to ANSI-136-710 Parameter Mapping........................................................190 20
Table 146: CMT Derived Values ..............................................................................................191 21
Table 147: SMS_CauseCode to TP-STATUS Mapping............................................................192 22
Table 148: SMS-STATUS-REPORT Derived Values................................................................194 23
Table 149: RP-ERROR Cause to R-Cause for Mobile Station Response to Mobile 24 Terminated Transfer Attempt. .................................................................................197 25
Table 150: ANSI-41 SMS_CauseCode to ANSI-136 R-Cause Code Mapping ..........................198 26
Table 151: ANSI-136 R-Cause Code to RP-ERROR Cause Mapping within the Mobile 27 Station ...................................................................................................................198 28
Table 152: UPDATE_LOCATION_REQUEST ->REGNOT Parameter Mapping .......................199 29
Table 1: Location Updating in GSM Foreign Mode Message Mapping........................................12 30
Table 2: Location Updating in ANSI-41 Foreign Mode Message Mapping...................................13 31
Table 3: MS Purging Message Mapping.....................................................................................13 32
N.S0028
xiv
Table 4: Location Cancellation Message Mapping......................................................................13 1
Table 5: UPDATE_LOCATION_REQUEST ↔ REGNOT Parameter Mapping............................13 2
Table 6: INSERT_SUBSCRIBER_DATA_REQUEST ↔ regnot Parameter Mapping ..................15 3
Table 7: UPDATE LOCATION RESPONSE ↔ regnot Parameter Mapping ................................16 4
Table 8: MS_PURGE_REQUEST ↔ MS INACTIVE Parameter Mapping...................................16 5
Table 9: CANCEL_LOCATION_REQUEST ↔ REGCANC Parameter Mapping .........................17 6
Table 10: UPDATE_LOCATION_RESPONSE to regnot Error Mapping .....................................20 7
Table 11: regnot return errors to UPDATE_LOCATION_RESPONSE Error Mapping .................21 8
Table 12 Fault Recovery Message Mapping ..............................................................................23 9
Table 13: GSM RESET ↔ ANSI UNRELDIR Parameter Mapping..............................................23 10
Table 14: Automatic Call Delivery Message Mapping.................................................................27 11
Table 15: ROUTREQ ↔ PROVIDE_ROAMING_NUMBER_REQUEST Parameter 12 Mapping ...................................................................................................................28 13
Table 16: Provide Roaming Number Response ↔ Routreq Return Result Parameter 14 Mapping ...................................................................................................................30 15
Table 17: PROVIDE_ROAMING_NUMBER_RESPONSE to Routreq Return Error Mapping 16 (ANSI-41Foreign Mode) ...........................................................................................30 17
Table 18: Routreq Return Error to Provide Roaming Number Response Error Mapping 18 (GSM Foreign mode)................................................................................................30 19
Table 19: Provide Roaming Number Request default parameter ................................................31 20
Table 20: RoutingRequest Return Result default parameters .....................................................32 21
Table 21: Routing Request Invoke default parameter.................................................................33 22
Table 22: PRN response User Error to routreq Return Error Mapping .......................................36 23
Table 23: PRN Response Provider Error to routereq Return Error Mapping................................36 24
Table 24: RoutingRequest Return Result to User Error in the PRN response Error Mapping ......37 25
Table 25: Routing Request Return Error to PRN User Error Mapping.........................................37 26
Table 26: ROUTEREQ Return Result to Provide Roaming Number Response parameter 27 mapping (Option 1)...................................................................................................39 28
Table 27: ROUTREQ Return Result to Provide Roaming Number Response Parameter 29 Mapping (Option 2)...................................................................................................40 30
Table 28: Return Error to User Error in the PRN response Error Mapping ..................................41 31
N.S0028
xv
Table 29: Optimal Routing for Late Call Forwarding Message Mapping......................................44 1
Table 30: GSM Provide_Roaming_Number ↔ ANSI-41 ROUTEREQ Parameter Mapping.........45 2
Table 31: Mapping of Parameter values.....................................................................................46 3
Table 32: Provide_Roaming_Number_Response ↔ routereq Parameter Mapping.....................46 4
Table 33: Mapping of Parameter Values ....................................................................................46 5
Table 34: Resume_Call_Handling ↔ REDREQ Parameter Mapping..........................................47 6
Table 35: Mapping of Parameters Values ..................................................................................47 7
Table 36: Resume_Call_Handling_Response ↔ redreq Parameter Mapping .............................47 8
Table 37: ANSI-41 Redirection_Reason to GSM Forwarding_Reason........................................48 9
Table 38: GSM Forwarding_Reason to ANSI-41 Redirection_Reason........................................48 10
Table 39: Provide_Roaming_Number to Routing_Request Error Mapping..................................49 11
Table 40: Routing_Request to Provide_Roaming_Number Error Mapping..................................49 12
Table 41: Resume_Call_Handling to Redirection_Request Error Mapping .................................50 13
Table 42: Redirection_Request to Resume_Call_Handling Error Mapping .................................50 14
Table 43: Supplementary Service Activation and Deactivation Message Mapping ......................54 15
Table 44: Activate/Deactivate SS Request ↔ FEATREQ Parameter Mapping............................54 16
Table 45: Activate/Deactivate SS Response ↔ Feature Request Return Result Parameter 17 Mapping ...................................................................................................................56 18
Table 46: Activate/Deactivate SS Response ↔ Feature Request Return Error Mapping.............57 19
Table 47: Activate/Deactivate SS Request to FEATREQ Parameter Mapping ............................57 20
Table 48: FEATREQ default parameter......................................................................................58 21
Table 49: Activate/Deactivate SS Response default parameter values .......................................59 22
Table 50: Feature Request Invoke to Activate/Deactivate SS Request Parameter Mapping........60 23
Table 51: Activate/Deactivate SS Request default parameter.....................................................60 24
Table 52: FeatureRequest Return Result default parameter.......................................................61 25
Table 53: FeatureRequest Return Result to User Error in the Activate/Deactivate SS 26 Response Error Mapping..........................................................................................64 27
Table 54: FeatureRequest Return Error to Activate/Deactivate SS Response Error 28 Mapping ...................................................................................................................64 29
N.S0028
xvi
Table 55: Activate/Deactivate SS Response User Error to FeatureRequest Return Result 1 Mapping ...................................................................................................................65 2
Table 56: Activate/Deactivate SS Response User Error to FeatureRequest Return Error 3 Mapping ...................................................................................................................66 4
Table 57: Activate/Deactivate SS Response Provider Error to Feature Request Return 5 Error Mapping ..........................................................................................................67 6
Table 58: Supplementary Service Registration Message Mapping .............................................70 7
Table 59: Register SS Request ↔ FEATREQ parameter mapping.............................................71 8
Table 60: Register SS Response ↔ Feature Request Return Result Parameter Mapping ..........72 9
Table 61: Register SS Response ↔ Return Error Parameter Mapping.......................................73 10
Table 62: Register SS Request to Feature Request Invoke parameter mapping.........................74 11
Table 63: FEATREQ default parameter......................................................................................75 12
Table 64: Register SS Response default parameter values........................................................76 13
Table 65: FEATREQ to Register SS Request parameter mapping .............................................77 14
Table 66: Register SS Request default parameter......................................................................77 15
Table 67: FeatureRequest Return Result default parameter.......................................................78 16
Table 68: FeatureRequest Return Result to User Error in the Register SS Response 17 mapping ...................................................................................................................80 18
Table 69: Supplementary Service Erasure Message Mapping....................................................83 19
Table 70: Erase SS Request ↔ FEATREQ parameter mapping.................................................83 20
Table 71: Erase SS Response ↔ Feature Request Return Result parameter mapping ..............84 21
Table 72: Erase SS Response ↔ Return Error parameter mapping ...........................................85 22
Table 73: Erase SS Request to FEATREQ parameter mapping .................................................86 23
Table 74: Feature Request Invoke default parameter.................................................................87 24
Table 75: Erase SS Response default parameter values............................................................88 25
Table 76: FEATREQ to Erase SS Request parameter mapping ................................................89 26
Table 77: Erase SS Request default parameter .........................................................................89 27
Table 78: FeatureRequest Return Result default parameter.......................................................90 28
Table 79: FeatureRequest Return Result to Register SS Response User Error ..........................91 29
Table 80: Retrieval of Forward-to-Number in GSM Foreign Mode ..............................................93 30
N.S0028
xvii
Table 81: TransferToNumberRequest Return Result to Insert Subscriber Data parameter 1 mapping ...................................................................................................................94 2
Table 82: TransferToNumberRequest Return Result to Insert Subscriber Data Request 3 value mapping..........................................................................................................95 4
Table 83: Routing Request ↔ Provide Roaming Number Request (Network Provided 5 number) Parmater Mapping......................................................................................97 6
Table 84: Routing Request ↔ Provide Roaming Number Request (User Provided number) 7 Parameter Mapping..................................................................................................98 8
Table 85: Routing Request ↔ Provide Roaming Number Request (Two calling party 9 numbers) Parameter Mapping ..................................................................................99 10
Table 86: Routing Request ↔ Provide Roaming Number Request(Caller Id Restricted) 11 Parameter Mapping................................................................................................101 12
Table 87: Cancel_Location_Request ↔ REGCAN (Subscriber Deletion) Mapping ...................105 13
Table 88: Mapping of GSM MAP Messages ↔ ANSI MAP Messages (Subscriber Data 14 Modification)...........................................................................................................105 15
Table 89: Delete_Subscriber_Data ↔ Qualdir Mapping (Subscriber Data Modification)............105 16
Table 90: CANCEL_LOCATION_REQUEST ↔ REGCANC Parameter Mapping .....................106 17
Table 91: INSERT_SUBSCRIBER_DATA_REQUEST ↔ QUALDIR Parameter Mapping.........106 18
Table 92: INSERT_SUBSCRIBER_DATA_REQUEST ↔ profile ‘macro’ Mapping....................107 19
Table 93: Forwarding Information List to Calling Features Indicator Parameter Mapping ..........109 20
Table 94: Regional Subscription Data to Geographic Authorization Parameter Mapping...........111 21
Table 95: Call Barring Information List to Origination Indicator Parameter Mapping..................111 22
Table 96: SSData List to Calling Features Indicator Parameter Mapping..................................114 23
Table 97: Operator Determined Barring general data to Origination Indicator 24 Parameter Mapping................................................................................................116 25
Table 98: Operator Determined Barring HPLMN data to Origination Indicator Parameter 26 Mapping .................................................................................................................118 27
Table 99: Operator Determined Barring HPLMN data to Restriction digits Parameter 28 Mapping .................................................................................................................118 29
Table 100: Call Barring Information List to SMS Origination Restrictions Parameter 30 Mapping .................................................................................................................119 31
Table 101: Call Barring Information List to SMS Termination Restrictions Parameter 32 Mapping .................................................................................................................120 33
N.S0028
xviii
Table 102: Call Barring Information List to Termination Restriction Code Parameter 1 Mapping .................................................................................................................121 2
Table 103: SSData List to SMS Origination Restrictions Parameter Mapping ...........................122 3
Table 104: SSData List to SMS Termination Restrictions Parameter Mapping..........................122 4
Table 105: ISD_RESPONSE and DSD_RESPONSE to Qualdir Return Error Mapping.............127 5
Table 106: Qualdir Return Error to INSERT_SUBSCRIBER_DATA_RESPONSE and 6 DELETE_SUSBCRIBER_DATA_RESPONSE Error Mapping.................................127 7
If the response to FSM indicates a failure in the delivery of the short message, the IIF shall 8 map the cause value received to a corresponding SMS_CauseCode value in 9 the SMDPP Return Result, as described in.............................................................129 10
Table 107: Short Message Service in GSM Foreign Mode (for CMT) Message Mapping ..........131 11
Table 108: Short Message Service in ANSI-136 Foreign Mode (for CMT) Message 12 Mapping .................................................................................................................131 13
Table 109: SMDPP to MT_Forward Short Message Parameter Mapping for GSM Foreign 14 Mode......................................................................................................................132 15
Table 110: MT_Forward Short Message to SMDPP Parameter Mapping for ANSI-41 16 Foreign Mode.........................................................................................................133 17
Table 111: SM-RP-UI in MT_FORWARD_SHORT_MESSAGE for MAP V2 Parameter 18 Values for GSM Foreign Mode ...............................................................................133 19
Table 112: SM-RP-UI in MT_FORWARD_SHORT_MESSAGE for MAP V1 Parameter 20 Encoding for GSM Foreign Mode............................................................................134 21
Table 113: SMS_Bearer Data in Mobile Terminating SMDPP Parameter Encoding for 22 ANSI-41 Foreign Mode...........................................................................................135 23
Table 114: Forward_Short_Message to ANSI-41_SMDPP Parameter Mapping for MO SMS 24 in GSM Foreign Mode ............................................................................................136 25
Table 115: ANSI-41 SMDPP to GSM Forward_Short_Message Parameter Mapping for MO 26 SMS in ANSI-41 Foreign Mode...............................................................................137 27
Table 116: Forward_Short_Message to SMS_CauseCode Values in SMDPP Return Result 28 Error Mapping ........................................................................................................142 29
Table 117: SMDPP to Forward_Short_Message Error Mapping ...............................................144 30
If the User Error parameter is populated in the GSM_FSM_ACK, then map this value into 31 the SMS_CauseCode according to.........................................................................146 32
Next, it populates the stored originating SMSC address and transaction ID. If the User 33 Error parameter is populated in GSM_FSM_ACK, then this value is mapped into 34 the SMS_CauseCode according to.........................................................................148 35
Table 118: Short Message Service (for GHOST) Message Mapping ........................................148 36
N.S0028
xix
Table 119: Alerting for an ANSI-136 Subscriber in GSM Foreign Mode Parameter Mapping.....149 1
Table 120: Alerting for a GSM Subscriber in ANSI-136 Foreign Mode Parameter Mapping.......150 2
Table 121: SMDPP to Forward Short Message for Mobile Terminated GHOST Teleservice 3 Parameter Mapping in GSM Foreign Mode.............................................................150 4
Table 122: Forward Short Message to SMDPP for Mobile Terminated GHOST Teleservice 5 Parameter Mapping in ANSI Foreign Mode.............................................................151 6
Table 123: Forward Short Message to SMDPP for Mobile Originated GHOST in GSM 7 Foreign Mode Parameter Mapping .........................................................................152 8
Table 124: SMDPP to Forward Short Message for Mobile Originated GHOST Teleservice 9 Parameter Mapping in ANSI-41 Foreign Mode........................................................153 10
Table 125: HLPI for GHOST ....................................................................................................153 11
The IIF is responsible for mapping GSM MAP_FSM_ACK Return Errors to ANSI-41 12 SMS_CauseCodes according to.............................................................................154 13
Table 126: Teleservice Server Address Mapping in IIF.............................................................154 14
Table 127: Message Waiting Notification in GSM Foreign Mode Message Mapping .................158 15
Table 128: Message Waiting Notification in ANSI-136 Foreign Mode Message Mapping ..........158 16
Table 129: Regnot to Forward Short Message for Message Waiting Notification Parameter 17 Mapping .................................................................................................................159 18
Table 130: QUALDIR to Forward Short Message for Message Waiting Notification 19 Parameter Mapping................................................................................................159 20
Table 131: Forward Short Message to QUALDIR for Message Waiting Notification 21 Parameter Mapping................................................................................................160 22
Table 132: Forward Short Message to SMDPP for Message Waiting Notification Parameter 23 Mapping .................................................................................................................160 24
Table 133: SM-RP-UI in Message FORWARD-SHORT-MESSAGE For MAP V2 Parameter 25 Encoding................................................................................................................161 26
Table 134: SM-RP-UI in Message FORWARD_SHORT-MESSAGE for MAP V1 Parameter 27 Encoding................................................................................................................163 28
Table 135: qualdir return error to FORWARD_SHORT_MESSAGE response Error 29 Mapping .................................................................................................................164 30
Table 136: SMSDPP to FORWARD_SHORT_MESSAGE response Error Mapping .................164 31
Table 137: Location Updating GPRS in GSM Foreign Mode Message Mapping .......................166 32
Table 138: MAP_UPDATE_GPRS_LOCATION_REQUEST → REGNOT Parameter 33 Mapping .................................................................................................................167 34
N.S0028
xx
Table 139: MAP_INSERT_SUBSCRIBER_DATA_REQUEST → regnot Parameter Mapping ...168 1
Table 140: MAP_UPDATE GPRS LOCATION RESPONSE → regnot Parameter Mapping.......169 2
Table 141: MAP_INSERT_SUBSCRIBER_DATA_REQUEST → profile ‘macro’ Mapping.........170 3
Table 141 A: ROUTREQ → MT_Forward Short Message Parameter Mapping ........................173 4
Table 142: Alerting for an ANSI-136 Subscriber for GPRS in GSM Foreign Mode 5 Parameter Mapping................................................................................................177 6
Table 143: ANSI-136-710 to GHOST Parameter Mapping........................................................182 7
Table 144: TP Derived Values .................................................................................................183 8
Table 145: GHOST to ANSI-136-710 Parameter Mapping........................................................185 9
Table 146: CMT Derived Values ..............................................................................................186 10
Table 147: SMS_CauseCode to TP-STATUS Mapping............................................................187 11
Table 148: SMS-STATUS-REPORT Derived Values................................................................189 12
Table 149: RP-ERROR Cause to R-Cause for Mobile Station Response to Mobile 13 Terminated Transfer Attempt. .................................................................................192 14
Table 150: ANSI-41 SMS_CauseCode to ANSI-136 R-Cause Code Mapping ..........................193 15
Table 151: ANSI-136 R-Cause Code to RP-ERROR Cause Mapping within the Mobile 16 Station ...................................................................................................................193 17
18
19
N.S0028
xxi
1
List of Figures 2
3
There are no figures in this volume. 4
5
N.S0028
xxii
1
Foreword 2
3
This foreword is not part of this standard. 4
This standard addresses the interworking and interoperability between ANSI-41 MAP and GSM 5 based networks in the support of subscribers roaming between networks. The objective of the 6 standard is to achieve fully automatic, two-way interoperability between the heterogeneous 7 networks. Services supported by this standard are described along with the associated information 8 flows and message mappings. However, not all services and associated capabilities of ANSI-41 9 MAP and GSM MAP are supported by this standard. In general the attempt has been to focus on 10 the key subscriber services needed in the market. 11
The focus of this the first release of this standard is on common GSM and ANSI-136 TDMA 12 services and associated network signaling (i.e. ANSI-41 MAP and GSM MAP). A pre-requisite for 13 this interoperability is Multi-mode mobile stations with an enhanced SIM card for roaming between 14 ANSI-136, GSM, and AMPS networks. 15
The first release of the standard did not define or require changes to existing ANSI-41 MAP or GSM 16 MAP to achieve the described interworking and interoperability. However, due to differences 17 between the services and associated capabilities of the MAP protocols, complete and fully 18 transparent interoperability may not have been achieved for some services. Future releases of this 19 standard may require changes to ANSI-41 MAP, GSM MAP and the associated services to achieve 20 full transparency while roaming between the different networks. 21
Additional or alternate service descriptions, information flows, and message mappings may be 22 required to support other air interfaces supported by ANSI-41 MAP (e.g., IS-95, cdmaOne, and 23 cdma2000). This may be accomplished in future release of this standard. 24
Aspects of TIA/EIA-136 Revision C have been incorporated into this standard. 25
Revision A adds the capability of getting GPRS services when roaming in GSM Foreign Mode. 26
Revision B adds two way roaming between GSM and CDMA systems 27
Information disclosed in this document is subject to the export jurisdiction of the US Department of 28 Commerce as specified in Export Administration Regulations (title 15 CFR parts 730 through 774 inclusive). 29 The information contained herein may not be exported or re-exported to Cuba, Iran, Iraq, Libya, North Korea, 30 Sudan, or Syria. Contact the Telecommunications Industry Association, Arlington, VA or 31 http://ftp.tiaonline.org/tr-45/tr45ahag/public%20documents 32
33
34
35
36
37
38
39
40
N.S0028
xxiii
1
2
3
4
5
6
(This page intentionally left blank.) 7
N.S0028
1
1 Introduction 1
2
1.1 General 3
4
When a subscriber to one network type (e.g., ANSI-41) roams to a network of another type 5 (e.g., GSM), interworking and interoperability functions are required to support roaming and 6 enable service. This standard describes an Interworking and Interoperability Function (IIF) to 7 support this cross-technology roaming between ANSI-41 and GSM networks. The IIF supports 8 a multi-mode mobile station with a removable Subscriber Identity Module (SIM). The standard 9 also defines the required network message mappings between ANSI-41 MAP and GSM MAP to 10 support the mobile terminal and associated services. 11
This standard includes the support of cross-technology roaming from an ANSI-41 based 12 network to a GPRS network. The GPRS network may be coupled with a GSM network. This 13 feature requires enhancement to the Interworking and Interoperability Function (IIF) which 14 supports a multi-mode mobile station and Subscriber Identity Module (SIM) with GPRS 15 functionality. 16
Optionally, IIF may support one way-roaming only from CDMA to GSM network. In this case, all 17 the relevant mapping tables described are applicable only in GSM Foreign Mode and for this 18
scenario they applied as unidirectional only. (Annex C) 19
20
1.2 Purpose 21
22
The purpose for this standard is to define and describe the functions necessary for roaming 23 between ANSI-41 MAP and GSM MAP based networks in the support of roaming subscribers. 24 This includes a capability to allow a subscriber to an ANSI-41 based network (e.g., an ANSI-25 136 41, TDMA or CDMA native subscriber) with a mobile terminal supporting GPRS service to 26 roam to a GPRS network in GSM Foreign Mode. 27
1.3 Scope 28
29
The scope of this standard are the services, information flows, and message mappings which 30 require interworking and interoperability functional specifications to support roaming between 31 ANSI-41 MAP [6] and GSM MAP [3] networks. 32
� The scope of this volume is to describe the processing, messages and parameters for 33 GPRS/GSM and ANSI-41 network interoperability. 34
1.4 Organization 35
36
This standard is organized into the following volumes: 37
N.S0028
2
Volume 0 - Overview and Interworking Reference Model 1
Volume 1 - Service Descriptions 2
Volume 2 - Information Flows 3
Volume 3 - Message Flows 4
5
This volume is organized according to the following: 6
2 References - is a list of references specific to this volume of the standard. 7
3 Definitions and Acronyms - defines words and acronyms that are used in this volume of 8 the standard. 9
4 Message Mappings - describes the stage 3 processing required to map messages 10 between ANSI-41 and GSM MAP. 11
Annex A Short Message Service Procedures within an ANSI-136 Network - contains a 12 description of mapping CMT to GHOST mapping for Short Messages. 13
Annex B Cause Code Mapping at non-IIF nodes - contains a description of cause code 14 mappings at non-IIF nodes. 15
Annex C One-way roaming from CDMA to GSM - contains a descriptio 16
Of the optional one-way roaming procedures, mappings 17
18
N.S0028
3
1
2 References 2
3
[1] GSM 03.18 Version 6.2.0 Release 1997 “ Digital cellular communication system (Phase 4 2+); Basic call handling; Technical realisation”, November 1998, ETSI. 5
[2] GSM 03.79 version 6.2.0 release 1997, “Digital cellular telecommunications system 6 (Phase 2+); Support of Optimal Routeing (SOR) Technical Realisation”. 7
[3] GSM 09.02 Version 6.2.0 Release 1997 “ Digital cellular communication system (Phase 8 2+); Mobile Application Part (MAP) specification”, August 1998, ETSI; 9
[4] GSM 02.60 version 6.3.1 Release 1997 “General Packet Radio Service (GPRS); Service 10 Description, Stage 1” 11
[5] GSM 03.60 version 6.8.0 Release 1997 “General Packet Radio Service (GPRS); Stage 12 2” 13
14
[6] TIA/EIA-41-D: “Cellular Radiotelecommunications Intersystem Operations,” December 15 1997, ANSI. 16
[7] TIA/EIA/IS-751: “TIA/EIA-41-D Modifications to support IMSI”, February 1998 17
[8]TIA/EIA/IS-807: “TIA/EIA-41-D Enhancements for Internationalization”, August 1999 18
[8] TIA/EIA/IS 737A”IS-41 support for data services for digital terminals (TDMA and CDMA)” 19
[8] TIA/EIA/IS 735 “IS-41 support for IS-95-A (advanced CDMA)” 20
[9] TIA/EIA/TSB58-E “Administration of Parameter Value Assignments for TIA/EIA Spread 21 Spectrum Standards” , January 2002 22
[10] TIA/EIA-95-B - Mobile Station-Base Station Compatibility Standard for Dual-Mode Spread 23 Spectrum Systems; Published October 1998. 24 25 [11] "TIA/EIA-IS-2000-A, cdma2000 Series, March 2000, plus addenda"Mobile Station-Base 26 Station Compatibility Standard for Dual-Mode Spread Spectrum Systems; 27 [12] TIA/EIA-868 – ANSI-41-D Network Based Enhancements to support one-way roaming to 28
GSM, Published TBD. [12]"Enhanced Cryptographic Algorithms, Revision B," TR45AHAG, Published 29 TBD 30
31
32
33
N.S0028
4
1
3 Definitions and Acronyms 2
3
3.1 Definitions 4
5 AMPS 6 7 Advanced Mobile Phone Service (AMPS) is the same as ANSI EIA/TIA-553, which is an analog 8 air interface protocol standard for mobile stations and their associated base stations. AMPS 9 networks use ANSI-41 for intersystem signaling. 10 11 ANSI-41 12 13 ANSI-41 is the same as ANSI TIA/EIA-41, which is a network protocol standard to support 14 intersystem operation of cellular networks, such as ANSI-136 networks. ANSI-41 is the North 15 American version of ITU defined MAP. Key intersystem support defined by ANSI-41 includes 16 automatic roaming, intersystem handoff, and intersystem operation, administration, and 17 maintenance. Among other things, ANSI-41 defines the interfaces between MSCs, between the 18 MSC/VLR and the HLR/AC, and between the MSC and the Short Message Service Center 19 (SMS-C) or Teleservice Server (TS). 20 21 ANSI-136 22 23 ANSI-136 is the same as ANSI TIA/EIA-136, which is a TDMA air interface protocol standard 24 for mobile stations and their associated base stations. ANSI-136 is a dual-mode standard that 25 includes digital (TDMA) operation at 800 MHz and 1900 MHz, and analog (AMPS) operation at 26 800 MHz. ANSI-136 networks use ANSI-41 for intersystem signaling. 27 28 ANSI-136 Mode 29 30 ANSI-136 mode indicates the condition or state of a mobile station accessing an ANSI-136 31 network. 32 33 ANSI-136 Foreign Mode 34 35 ANSI-136 foreign mode indicates the condition or state of a GSM native subscriber accessing 36 an ANSI-136 network. 37 38 ANSI-136 Native Mode 39 40 ANSI-136 native mode indicates the condition or state of an ANSI-136 native subscriber 41 accessing an ANSI-136 network. 42 43 ANSI-136 Native Subscriber 44 45 ANSI-136 native subscriber indicates an end user whose primary or home subscription resides 46 in an ANSI-136 network. These subscribers include both home subscribers from the ANSI-136 47 network, as well as roamers from other ANSI-136 networks. 48 49 50
N.S0028
5
ANSI-41 Foreign Mode 1
ANSI-41 foreign mode indicates the condition or state of a GSM native subscriber accessing an 2 ANSI-41 based network. 3
CDMA 4 CDMA as used in this document, refers to TIA/EIA -95 [9] or TIA/EIA-2000 [10], which is a 5 CDMA air interface protocol standard for mobile stations and their associated base stations. 6 CDMA is a dual-mode standard that includes digital (CDMA) operation and analog (AMPS) 7 operation. CDMA networks use ANSI-41 for intersystem signaling. 8
CDMA Mode 9
CDMA mode indicates the condition or state of a mobile station accessing an CDMA network. 10 11 CDMA Foreign Mode 12 CDMA foreign mode indicates the condition or state of a GSM native subscriber accessing a 13 CDMA network. 14 15 CDMA Native Mode 16 CDMA native mode indicates the condition or state of an CDMA native subscriber accessing an 17 CDMA network. 18 19 CDMA Native Subscriber 20 CDMA native subscriber indicates an end user whose primary or home subscription resides in 21 an 22 CDMA network. These subscribers include both home subscribers from the CDMA network, as 23 well as roamers from other CDMA networks. 24
Class A mobile 25
Class A mobile station is a GSM mobile that can operate in Class A mode: both GSM circuit-26 switched and GPRS packet services simultaneously. 27
Class B mobile 28
Class B mobile station is a GSM mobile that operates in Class B mode: it can operate 29 alternatively in GSM circuit-switched or in GPRS packet services (1 type service at a time). The 30 mobile can be attached to GSM and GPRS networks simultaneously in this case. The 31 subscriber cannot be simultaneously attached to a TDMA ANSI-41 MSC. 32
Class C mobile 33
Class C mobile station is a GSM mobile that can only operate in Class C mode: GSM circuit-34 switched only or GPRS packet services only. The mobile is attached to only one network at a 35 time. 36
GPRS HLR 37
General Packet Radio Service Home Location Register is the HLR responsible for GPRS 38 functions. It interfaces with the SGSN and GGSN and Authentication Center. 39
GPRS in GSM Foreign Mode 40
GPRS in GSM Foreign Mode is a subset of GSM Foreign Mode and indicates the condition or 41 state of an ANSI-136 41native subscriber accessing a GPRS network; the GPRS network may 42 be coupled with a GSM network. 43
GSM 44 45
N.S0028
6
Global System for Mobile Communications (GSM) defines both air interface and network 1 intersystem protocol standards for mobile stations (MS), base station systems (BSS), and 2 network switching systems (NSS). 3 4 GSM CS attached 5
GSM circuit-switched services attached means that the subscriber is attached to a GSM MSC. 6 This is also referred to as IMSI attached. 7
GSM CS detached 8
GSM circuit-switched services detached means that the subscriber is detached from a GSM 9 MSC. This is also referred to as IMSI detached. 10
11 GSM Mode 12 13 GSM mode indicates the condition or state of a mobile station accessing a GSM network. 14 15 GSM Foreign Mode 16 17 GSM foreign mode indicates the condition or state of an ANSI-136 41 native subscriber 18 accessing a GSM network. 19 20 GSM Native Mode 21 22 GSM native mode indicates the condition or state of a GSM native subscriber accessing a GSM 23 network. 24 25 GSM Native Subscriber 26 27 GSM native subscriber indicates an end user whose primary or home subscription resides in a 28 GSM network. These subscribers include both home subscribers from the GSM network, as 29 well as roamers from other GSM networks. 30
31 Mobile Station 32 33 The mobile equipment and the SIM together make up the mobile station, which is the wireless 34 radiotelephone used by the subscriber. 35 36 Subscriber Identity Module 37
A smart card that plugs into the mobile equipment and that contains the authentication 38 algorithms, and stores service-oriented subscription information. 39
40
3.2 Acronyms 41
42
AC Authentication center 43
ANSI American National Standards Institute 44
BAIC Barring of All Incoming Calls 45
BAOC Barring of All Outgoing Calls 46
N.S0028
7
BIC-Roam Barring of Incoming Calls while Roaming Outside HPLMN Country 1
BMI Base Station, Mobile Switching System, and Interworking Function 2
BOIC Barring of Outgoing International Calls 3
BOIC-exHC Barring of Outgoing International Calls Except to HPLMN Country 4
CDMA Code-Division Multiple Access 5
CFB Call Forwarding Busy 6
CFNA Call Forwarding No Answer 7
CFNRc Call Forwarding Not Reachable 8
CFNRy Call Forwarding No Reply 9
CFU Call Forwarding Unconditional 10
CPHS Common PCN Handset Specification 11
CS Circuit-Switched 12
DCS Data Coding Scheme 13
EDGE Enhanced Data Rates Through Global Evolution 14
EIA Electronics Industry Association 15
ESN Electronic Serial Number 16
ETSI European Telecommunications Standards Institute 17
FC Feature Code 18
FSM Forward Short Message 19
GGSN Gateway GPRS Support Node 20
GHOST GSM Hosted SMS Teleservice 21
GMSC Gateway Mobile Switching Center 22
GPRS General Packet Radio Service 23
GSM Global System for Mobile Communications 24
HLPI Higher Layer Protocol Indicator 25
HLR Home Location Register 26
HPLMN Home Public Land Mobile Network 27
IIF Interworking and Interoperability Function 28
IMSI International Mobile Subscriber Identity 29
ITU International Telecommunications Union 30
MAP Mobile Application Part 31
MC ANSI-136 41 Message Center (for SMS) 32
N.S0028
8
MDN Mobile Directory Number 1
ME Mobile Equipment 2
MIN Mobile Identification Number 3
MO Mobile Originated 4
MS Mobile Station 5
MSC Mobile Switching Center 6
MSCID MSC Identification Number 7
MSID Mobile Station Identity 8
MSISDN Mobile Subscriber ISDN Number 9
MSRN Mobile Station Routing Number 10
MT Mobile Terminated 11
MWN Message Waiting Notification 12
ODB Operator Determined Barring 13
OR Optimal Routing 14
PCS Personal Communication Service 15
PDU Packet Data Unit 16
PIN Personal Identification Number 17
PLMN Public Land Mobile Network 18
SGSN Serving GPRS Support Node 19
PRN Provide Roaming Number 20
SC Service Center 21
SID System Identity 22
SIM Subscriber Identity Module 23
SMDPP Short Message Delivery Point-to-Point 24
SME Short Message Entity 25
SMS Short Message Service 26
SMS-C GSM Short Message Service Center 27
SS7 Signaling System 7 28
TDMA Time Division Multiple Access 29
TIA Telecommunications Industry Association 30
TLDN Temporary Location Directory Number 31
TSAR Teleservice Segmentation and Reassembly 32
N.S0028
9
UDH Universal Data Header 1
VLR Visitor Location Register 2
VPLMN Visitor Public Land Mobile Network 3
WEMT Wireless Enhanced Messaging Teleservices 4
5
6
N.S0028
10
1
4 Message Mappings 2
3
The IIF shall perform the translation of messages, parameters and parameter values in 4 accordance with the tables included in this volume of the standard. The following notation is 5 used in accordance with the definitions given in GSM 09.02 [3] and ANSI-41 [6], [7], 0. 6
Within the following tables, the parameters are identified as either being: 7
M Mandatory, 8
C Conditional 9
O Service Provider Optional 10
U Service User Optional 11
The following notation is used in this standard to identify parameters as being syntactically 12 optional but semantically required to be sent by the IIF in order to support interoperability: 13
R Required. 14
Refer to GSM 09.02 [3] and ANSI-41 [6], [7], 0 for a description of the messages, parameters 15 and parameter values. 16
When the IIF receives either a GSM MAP message or an ANSI MAP message, it shall apply 17 the following rules regarding the handling of parameters within those messages: 18
� The IIF shall populate mandatory parameters in messages sent by the IIF, regardless 19 of whether mapping of parameters is possible. 20
� The IIF may populate optional parameters in messages sent by the IIF, regardless of 21 whether mapping of parameters is possible. 22
All parameters shall be populated in accordance with GSM 09.02 [3] or ANSI-41 [6], [7], 0. 23
Where there is no direct mapping for parameters, a hyphen (‘-‘) has been entered in the 24 corresponding table. 25
26
4.1 Mobility Procedures 27
28
Existing mobility procedures described in either GSM 09.02 [3] or ANSI-41 [6] are also directly 29 applicable to the IIF when it is emulating a GSM or ANSI-41 functional network element. 30 Enhancements/modifications to ANSI-41 [7], 0 are also applicable. 31
4.1.1 Location Registration 32
33
The location registration procedure is used to update the location information held in the 34 network. This location information is used to route incoming calls and short messages to the 35 roaming subscriber. 36
N.S0028
11
The Location registration procedure is also used to cancel location information held in the 1 network. 2
4.1.1.1 Detailed Procedures 3
4
4.1.1.1.1 Location Updating 5
6
The IIF contains location information (vlr number) relating to the roaming subscriber. Therefore, 7 the IIF needs to be updated at each change in VLR. The IIF shall translate GSM MAP 8 messages to ANSI-41 MAP messages and vice versa, when the subscribers home HLR needs 9 updating. The subscriber’s home HLR needs to be updated only in the following cases: 10
When the subscriber’s MS registers in a GSM network, when previously registered in an ANSI-11 41 network; 12
When the subscribers MS registers in an ANSI-41 network, when previously registered in a 13 GSM network; 14
Optionally, the subscriber’s home HLR may be updated in the following cases: 15
When the subscribers MS (accessing a GSM Network) registers in another VLR within the 16 same GSM network; 17
When the subscribers MS (accessing an ANSI-41 Network) registers in another VLR within the 18 same ANSI-41 network; 19
20
When the HLR is updated, the IIF conveys a unique identifier to the HLR identifying the serving 21 MSC/VLR. 22
If the IIF receives a GSM MAP _UPDATE_LOCATION_REQUEST, it shall compare the 23 received location information with any previously stored location information. If the received 24 and previously stored location information are different, the IIF shall determine if the location 25 updating is allowed and update the corresponding subscriber record accordingly and send a 26 GSM MAP _CANCEL_LOCATION_REQUEST to the old VLR. If there is no previously stored 27 location information in the IIF, the IIF shall determine if the location updating is allowed and 28 update the corresponding subscriber record accordingly. In either case, if the HLR is required 29 to be updated, then the IIF shall send an ANSI_MAP_REGNOT to the HLR and await a 30 response. 31
If the response indicates that the location updating procedure has been successful, then the IIF 32 shall update the corresponding subscriber record and send a GSM MAP 33 _INSERT_SUBSCRIBER_DATA_REQUEST to the serving VLR and await a response. If the 34 response indicates success, the IIF completes the location updating procedure by sending a 35 GSM MAP _UPDATE_LOCATION_RESPONSE to the serving VLR. The GSM MAP 36 _UPDATE_LOCATION_RESPONSE contains a unique identifier, identifying the HLR. 37 Otherwise, the IIF sends a GSM MAP _UPDATE_LOCATION_RESPONSE to the serving VLR 38 indicating the reason why the location updating procedure was not successful. 39
If the response indicates that the location updating procedure has been unsuccessful, then the 40 IIF shall not update the corresponding subscriber record and shall send a GSM MAP 41 _UPDATE_LOCATION_RESPONSE to the serving VLR indicating the reason for failure. 42
If the IIF receives an ANSI_MAP_REGNOT, it shall compare the received location information 43 with any previously stored location information. If the received and previously stored location 44
N.S0028
12
information is different, the IIF shall update the corresponding subscriber record and send an 1 ANSI_MAP_REGCANC to the old VLR. If there is no previously stored location information in 2 the IIF, the corresponding subscriber record is updated. In either case, if the HLR is required to 3 be updated, then the IIF shall send a GSM MAP _UPDATE_LOCATION_REQUEST to the HLR 4 and await a response. 5
If the response indicates that the location updating procedure has been successful, then the IIF 6 shall update the corresponding subscriber record and send an ANSI_MAP_regnot to the 7 serving VLR. The ANSI_MAP_regnot contains a unique identifier, identifying the HLR. 8
If the response indicates that the location updating procedure has been unsuccessful, then the 9 IIF shall not update the corresponding subscriber record and shall send an ANSI_MAP_regnot 10 to the serving VLR indicating the reason for failure. 11
If the IIF receives a GSM MAP _MS_PURGE_REQUEST, it shall check the contents of the 12 message for errors. If errors exist, the IIF shall send a GSM MAP _MS_PURGE_RESPONSE 13 indicating the reason for failure and the MS purged flag shall not be set. If no errors exist, the 14 IIF shall check if the received VLR number matches the stored VLR number. 15
If the received VLR number and the stored VLR number match, the IIF shall set the MS purged 16 flag and shall send both a GSM MAP _MS_PURGE_RESPONSE to the VLR (including the 17 Freeze TMSI parameter) and an ANSI_MAP_MS_INACTIVE to the HLR and awaits a response 18 from the HLR. 19
If the received VLR number and the stored VLR number do not match, the IIF sends a GSM 20 MAP _PURGE_MS_RESPONSE containing an empty result to indicate successful outcome 21 and the MS purged flag is not set. 22
When the IIF receives a response from the HLR, it shall follow the VLR procedures outlined in 23 ANSI-41 [6]. 24
If the IIF receives an ANSI_MAP_MS_INACTIVE, it shall check the contents of the message for 25 errors. If errors exist, the IIF shall send an ANSI_MAP_ms_inactive indicating the reason for 26 failure and shall not set the MS state to inactive. If no errors exist, the IIF shall set the MS state 27 to inactive and follow the HLR procedures described in ANSI-41 [6]. If the state of the MS 28 remains inactive for a period of time (time controlled by operator), the IIF may send a GSM 29 MAP _MS_PURGE_REQUEST to the HLR. 30
4.1.1.1.2 Location Cancellation 31
32
If the IIF receives a GSM MAP _CANCEL_LOCATION_REQUEST as part of a location 33 cancellation procedure it shall check the contents of the message for errors. If errors exist, the 34 corresponding temporary subscriber data is not deleted and the IIF shall send a GSM MAP 35 _CANCEL_LOCATION_RESPONSE indicating the reason for failure to the HLR. If no errors 36 exist, the IIF shall delete the corresponding temporary subscriber data and send an 37 ANSI_MAP_REGCANC to the VLR and await a response. 38
If the response indicates that the location cancellation procedure has been successful, then the 39 IIF shall send a GSM MAP _CANCEL_LOCATION_RESPONSE to the HLR. 40
If the response indicates that the location cancellation procedure has been unsuccessful, then 41 the IIF shall send a GSM MAP _CANCEL_LOCATION_RESPONSE to the HLR indicating 42 successful deletion of subscriber data (i.e., ignore the error). 43
If the IIF receives an ANSI_MAP_REGCANC and the message can be processed, the IIF shall 44 delete the corresponding temporary subscriber data and send a GSM MAP 45 _CANCEL_LOCATION_REQUEST to the VLR and await a response. 46
N.S0028
13
If the response indicates that the location cancellation procedure has been successful, then the 1 IIF shall send an ANSI_MAP_regcanc to the HLR. 2
If the response indicates that the location cancellation procedure has been unsuccessful, then 3 the IIF shall send an ANSI_MAP_regcanc to the HLR indicating successful deletion of 4 subscriber data (i.e., ignore the error). The IIF may retry to sending the 5 ANSI_MAP_REGCANC before responding to the HLR. 6
If the IIF receives an ANSI_MAP_REGCANC and the message cannot be processed, the 7 corresponding temporary subscriber data shall not be deleted and the IIF shall send an 8 ANSI_MAP_regcanc to the HLR indicating reason for failure. 9
4.1.1.2 Mapping of Messages, Parameters & Parameter Values 10
11
4.1.1.2.1 Mapping of Messages 12
13
Table 1 shows the mapping between GSM MAP messages and ANSI MAP messages related 14 to Location Registration. 15
Table 1: Location Updating in GSM Foreign Mode Message Mapping 16
GSM MAP Messages ANSI MAP Messages
UPDATE_LOCATION_REQUEST REGNOT
INSERT_SUBSCRIBER_DATA_REQUEST Regnot
UPDATE_LOCATION_RESPONSE Regnot1
17
18
1This message can also contain error values if the location updating procedure is unsuccessful. 19 If the location updating procedure fails, the mapping is as shown in 4.1.1.3.20
N.S0028
14
Table 2 shows the mapping between GSM MAP messages and ANSI MAP messages related 1 to Location Registration in ANSI-41 Foreign Mode. 2
Table 2: Location Updating in ANSI-41 Foreign Mode Message Mapping 3
GSM MAP Messages ANSI MAP Messages
UPDATE_LOCATION_REQUEST REGNOT
UPDATE_LOCATION_RESPONSE Regnot
4
Table 3 shows the mapping between GSM MAP messages and ANSI MAP messages (MS 5 Purging, regardless of mode of operation) 6
7
Table 3: MS Purging Message Mapping 8
GSM MAP Messages ANSI MAP Messages
MS_PURGE MS Inactive
9
10
Table 4 shows the mapping between GSM MAP messages and ANSI MAP messages related 11 to Location Cancellation. 12
Table 4: Location Cancellation Message Mapping 13
GSM MAP Messages ANSI MAP Messages
CANCEL_LOCATION_REQUEST REGCANC
CANCEL_LOCATION_RESPONSE regcanc
14
4.1.1.2.2 Mapping of Parameters 15
16
Table 5 through Table 9 shows the mapping of parameters, which the IIF shall perform 17 regardless of the mode of operation (GSM Foreign Mode or ANSI-41 Foreign Mode). 18
Table 5: UPDATE_LOCATION_REQUEST ↔↔↔↔ REGNOT Parameter Mapping 19
GSM MAP _UPDATE_LOCATION_REQUEST
Status ANSI_MAP_REGNOT Status
ElectronicSerialNumber M IMSI M
MSID M
MSC Address M1 MSCID (Serving MSC)1 M
- QualificationInformationCode M
- SystemMyTypeCode M
- MSCIdentificationNumber O
N.S0028
15
1
Table 5: UPDATE_LOCATION_REQUEST ↔ REGNOT Parameter Mapping (concluded) 2
GSM MAP _UPDATE_LOCATION_REQUEST
Status ANSI_MAP_REGNOT Status
VLR Number M -
- PC_SSN (Serving MSC or VLR) O
- SystemAccessType2 O
TerminalType2 O
- TransactionCapability2 O
LMSI U -
Supported CAMEL Phases C -
3 1 These parameters are used to convey a unique identifier from the IIF to the HLR, identifying 4 the serving MSC/VLR. 5
2Parameters are included in ANSI specifications IS-41-C and later. 6
7
N.S0028
16
1
Table 6 shows the mapping of parameters for GSM MAP 2 _INSERT_SUBSCRIBER_DATA_REQUEST to regnot. 3
Table 6: INSERT_SUBSCRIBER_DATA_REQUEST ↔↔↔↔ regnot Parameter Mapping 4
GSM MAP _INSERT_SUBSCRIBER_DATA_REQUEST
Status regnot Status
- SystemMYTypeCode (VLR or HLR)
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 O
IMSI C -
5
6 1This parameter is itself a macro containing a number of other parameters. As far as mapping 7 of parameters is concerned, the IIF shall map the contents of the ‘Profile’ macro in the ANSI-41-8 D ‘regnot’ to the contents of the GSM MAP _INSERT_SUBSCRIBER_DATA_REQUEST as 9 shown in Table 92 10
11
N.S0028
17
Table 7: UPDATE LOCATION RESPONSE ↔↔↔↔ regnot Parameter Mapping 1
GSM MAP _UPDATE_LOCATION_RESPONSE
Status regnot Status
- SystemMYTypeCode (VLR or HLR)
M
- AuthorizationDenied O
- Authorization Period O
- ControlChannelData O
- DeniedAuthorizationPeriod O
- Digits (Carrier) O
- Digits (Destination) O
HLR number1, 2 R MSCID (HLR)2 R
- Profile “Macro”3 O
- ReceivedSignalQuality O
- SenderIdentificationNumber O
- SMS_MessageWaitingIndicator O
- SystemAccessData O
- MSID O
2
1The presence of this parameter is mandatory in case of successful HLR updating. 3 2These parameters are used to convey a unique identifier from the IIF to the serving MSC/VLR, 4 identifying the HLR. 5
3This parameter is itself a macro containing a number of other parameters. As far as mapping 6 of parameters is concerned, the IIF shall map the contents of the ‘Profile’ macro in the ANSI-41-7 D ‘regnot’ to the contents of the GSM MAP _INSERT_SUBSCRIBER_DATA_REQUEST as 8 shown in Table 92. 9
Table 8: MS_PURGE_REQUEST ↔↔↔↔ MS INACTIVE Parameter Mapping 10
GSM MAP _MS_PURGE_REQUEST
Status MS INACTIVE Status
IMSI M MSID M
VLR Number C -
- ESN M
- CallHistoryCount O
- DeregistrationType O
- LocationAreaId O
- SenderIdentificationNumber O
- SMSMessageWaitingIndicator O
11
12
N.S0028
18
Table 9: CANCEL_LOCATION_REQUEST ↔↔↔↔ REGCANC Parameter Mapping 1
GSM MAP _CANCEL_LOCATION_REQUEST
Status ANSI_MAP_REGCANC Status
ESN M IMSI M
MSID M
LMSI C -
Cancellation Type C1 Cancellation Type O
- ControlChannelData O
- ReceivedSignalQuality O
- SenderIdentificationNumber O
SystemAccessData O 2
1Cancellation Type is only used between the HLR and the SGSN for GPRS procedures. 3 Cancellation Type is not applicable between HLR and VLR. 4
4.1.1.3 Error Handling 5
6
Error handling defined in GSM 09.02 [3] and ANSI-41 [6] is directly applicable to the IIF, when 7 the IIF is emulating a GSM or ANSI-41 network functional element. 8
4.1.1.3.1 Location Updating 9
10
If the Location Updating procedure fails at an ANSI-41 HLR, the HLR shall respond by either 11 sending: 12 An ANSI_MAP_regnot in a TCAP RETURN RESULT indicating authorization denied 13 (AUTHDEN) to the IIF, with one of the following reasons as defined in ANSI-41 [6]: 14
Appropriate AUTHDEN Values in ANSI_MAP_regnot RETURN RESULT 15
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.
N.S0028
19
TerminalType mismatch
1
The ANSI-MAP-regnot may optionally, indicate: 2
• The authorization period (DENAUTHPER) as defined in ANSI-41 [6] 3
• Access Info as defined in ANSI-41 [6] 4
Or, an ANSI_MAP_regnot in a TCAP RETURN ERROR one of the following error codes as 5 defined in ANSI-41 [6]: 6
Appropriate Error Codes in ANSI_MAP_regnot RETURN ERROR 7
Error Codes
MSID/HLRMismatch
ResourceShortage
OperationNotSupported
ParameterError
SystemFailure
8
9
N.S0028
20
1
Appropriate Error Codes in ANSI_MAP_regnot RETURN ERROR (concluded) 2
3
Error Codes
UnrecognizedParameterValue
MissingParameter
4
The IIF is therefore responsible for mapping any errors it receives from the HLR in the ANSI-5 MAP-regnot to an equivalent error in the GSM-MAP-UPDATE-LOCATION RESPONSE towards 6 the serving GSM MSC/VLR. 7
8
The GSM-MAP-UPDATE-LOCATION RESPONSE may include one the following ‘user’ errors 9 as defined in GSM 09.02 [3]: 10
Appropriate User Errors 11
User Errors
unknown subscriber;
roaming not allowed;
system failure;
unexpected data value.
12
The following ‘provider errors’ (protocol related errors) are also defined in GSM 09.02 [3]: 13
Appropriate Provider Errors 14
duplicated invoke Id;
not supported service;
mistyped parameter;
resource limitation;
initiating release (i.e., the peer has already initiated release of the dialogue and the service
has to be released);
unexpected response from the peer;
service completion failure;
no response from the peer;
invalid response received.
15
N.S0028
21
If the Location Updating procedure fails at a GSM HLR, it returns a GSM MAP 1 _UPDATE_LOCATION_RESPONSE to the IIF, indicating a ‘user error’ as indicated above. 2 The IIF is therefore responsible for mapping any errors it receives into a corresponding error in 3 the ANSI_MAP_regnot towards the serving ANSI MSC/VLR. For further description of these 4 errors and when they are used, refer to either GSM 09.02 [3] or ANSI-41 [6]. 5
Table below provides the mapping of both user errors and provider errors to the equivalent 6 value in either the AUTHDEN parameter in the ANSI_MAP_regnot RETURN RESULT or the 7 RETURN ERROR for ANSI-41 Foreign Mode. 8
Table 10: UPDATE_LOCATION_RESPONSE to regnot Error Mapping 9
UPDATE_LOCATION_RESPONSE (Errors)
Regnot
Unknown subscriber SystemFailure
roaming not allowed Not Authorized for the MSC
system failure SystemFailure
unexpected data value SystemFailure
duplicated invoke Id SystemFailure
not supported service SystemFailure
mistyped parameter SystemFailure
resource limitation SystemFailure
initiating release SystemFailure
unexpected response from the peer SystemFailure
service completion failure SystemFailure
no response from the peer SystemFailure
invalid response received SystemFailure
10
11
Table 11 provides the mapping for GSM Foreign Mode. 12
13
N.S0028
22
1
Table 11: regnot return errors to UPDATE_LOCATION_RESPONSE Error Mapping 2
Regnot UPDATE_LOCATION_RESPONSE (Errors)
Delinquent account System failure
Invalid serial number System failure
Stolen unit System failure
Duplicate unit System failure
Unassigned directory number System failure
Unspecified System failure
Multiple access System failure
Not Authorized for the MSC Roaming not allowed
Missing authentication parameters System failure
TerminalType mismatch System failure
MSID/HLRMismatch Unknown subscriber
ResourceShortage System failure
OperationNotSupported System failure
ParameterError System failure
SystemFailure System failure
UnrecognizedParameterValue System failure
MissingParameter System failure
3
4.1.1.3.2 Location Cancellation 4
5
If the Location Cancellation procedure fails at the IIF, existing procedures described in GSM 6 09.02 [3] and ANSI-41 [6] apply. 7
8
N.S0028
23
1
4.1.2 Fault Recovery 2
3
After the fault of a location register, the fault recovery procedures ensure that subscriber data in 4 the VLR becomes consistent with the subscriber data stored in the IIF or that subscriber data in 5 the IIF becomes consistent with the subscriber data that are stored in the HLR for the MS 6 concerned and that the location information in the IIF and VLR or HLR and IIF reflect accurately 7 the current location of the MS. 8
9
4.1.2.1 Detailed Procedures 10
11
If the IIF receives an ANSI_MAP_UNRELDIR, it shall send a RETURN RESULT and clear the 12 records of those MSs associated with the requesting HLR. The IIF shall then send a GSM MAP 13 _RESET towards the serving VLR containing a unique identity, identifying the ANSI-41 HLR. 14 When the MS concerned next establishes authenticated radio contact (including a mobile 15 originated call attempt), the IIF shall receive a GSM MAP _UPDATE_LOCATION_REQUEST 16 and shall follow the procedures outlined in 17
4.1.1 Location Registration. 18
If the IIF receives a GSM MAP _RESET, it shall derive all involved MSs of that HLR either from 19 the HLR Identity List (if present), or from the HLR number. The IIF shall then mark these MSs 20 with the indicator "Location Information Confirmed in HLR" set to "Not Confirmed". The IIF shall 21 then send an ANSI_MAP_UNRELDIR towards the serving VLR containing a unique identity, 22 identifying the GSM HLR. The status "Not Confirmed" of the indicator "Location Information 23 Confirmed in HLR" forces the IIF to invoke the GSM MAP _UPDATE_LOCATION service after 24 establishment of authenticated radio contact with the MS concerned. 25
If the IIF suffers a failure, while operating in GSM Foreign Mode, it shall send a GSM MAP 26 _RESET to the serving GSM VLR once it has returned to a stable state. The IIF shall not 27 receive a response. The IIF may also send an ANSI_MAP_BULKDEREG to the ANSI-41 HLR. 28
If the IIF suffers a failure, while operating in ANSI-41Foreign Mode, it shall send an 29 ANSI_MAP_UNRELDIR to the serving ANSI-41 VLR once it has returned to a stable state. The 30 IIF shall receive an indication of success or failure. 31
If the IIF receives an ANSI_MAP_BULKDEREG, it shall send a RETURN RESULT to the 32 requesting VLR and clear the location pointer of those MSs that were registered in the 33 requesting VLR. Otherwise, the IIF shall send a RETURN ERROR with an appropriate error 34 value to the requesting VLR. 35
36
4.1.2.2 Mapping of Messages, Parameters & Parameter Values 37
38
The IIF shall perform the mapping of messages, parameters and parameter values related to 39 fault recovery in accordance with the tables presented in 4.1.2.2. 40
41
N.S0028
24
1
4.1.2.2.1 Mapping of Messages 2
3
Table 12 shows the mapping between GSM MAP messages and ANSI MAP messages related 4 to fault recovery in either mode of operation (GSM Foreign mode or IS-136 41 Foreign mode) 5
Table 12 Fault Recovery Message Mapping 6
GSM MAP Messages ANSI MAP Messages
RESET UNRELDIR
7
4.1.2.2.2 Mapping of Parameters 8
9
Table 13 shows the mapping of parameters, which the IIF shall perform regardless of the mode 10 of operation (GSM Foreign Mode or ANSI-41Foreign Mode). 11
Table 13: GSM RESET ↔↔↔↔ ANSI UNRELDIR Parameter Mapping 12
GSM MAP _RESET Status ANSI_MAP_UNRELDIR Status
HLR Id LIST U
HLR Number1 M MSCID (HLR) 1 R
13 1These parameters are used to convey a unique identifier from the IIF to the serving VLR, 14 identifying the true HLR. 15
16
N.S0028
25
1
4.1.2.3 Error Handling 2
3
Error handling defined in GSM 09.02 [3] and ANSI-41 [6] is directly applicable to the IIF, when 4 the IIF is emulating a GSM or ANSI-41 network functional element. 5
If the Fault Recovery procedure fails at an ANSI-41 VLR, the VLR shall respond by either 6 sending: 7
An ANSI_MAP_unreldir in a TCAP RETURN ERROR with one of the following error codes as 8 defined in ANSI-41 [6]: 9
10
Appropriate Error Codes in ANSI_MAP_unreldir RETURN ERROR 11
12
Error Codes
ResourceShortage
OperationNotSupported
SystemFailure
13
There are no error handling procedures defined in GSM09.02 [3] covering the case where Fault 14 Recovery procedures fail at a GSM VLR i.e. the GSM MAP _RESET service is a non-confirmed 15 service. As such, the IIF shall not map ANSI-41 error values to equivalent GSM error values. 16
If the Fault Recovery procedure fails at the IIF following the reception of an 17 ANSI_MAP_BULKDEREG, the IIF shall respond by sending an ANSI_MAP_bulkdereg in a 18 TCAP RETURN ERROR with one of the following error codes as defined in ANSI-41 [6]: 19
20
Appropriate Error Codes in ANSI_MAP_bulkdereg RETURN ERROR 21
22
Error Codes
ResourceShortage
OperationNotSupported
SystemFailure
UnrecognizedParameterValue
23
24
N.S0028
26
1
4.2 Call Handing Procedures 2
3
Existing call handling procedures described in either GSM 09.02 [3] or ANSI-41 [6] are also 4 directly applicable to the Interworking and Interoperability Function (IIF) when it is emulating a 5 GSM or ANSI-41 functional network element. 6
7
4.2.1 Automatic Call Delivery 8
9
4.2.1.1 Detailed Procedures 10
11
The Automatic Call Delivery procedure is invoked in the IIF, when a terminating call attempt 12 results in a request for routing information from the IIF. 13
The following procedures are applicable at the IIF for Automatic Call Delivery: 14
4.2.1.1.1 GSM Foreign Mode 15
16
If the IIF receives an ANSI MAP_RoutingRequest Invoke message from the ANSI-41 HLR, it 17 shall check if the terminating call can be placed to that subscriber. The IIF shall then deduce 18 the IMSI from the MSID for that subscriber and populate the corresponding field of the 19 MAP_PROVIDE_ROAMING_NUMBER message. 20
The IIF shall store the BillingID received in the ANSI MAP_RoutingRequest Invoke message to 21 later be able to populate the corresponding field in the ANSI MAP_RoutingRequest Return 22 Result message. 23
If the MobileDirectoryNumber field is present and in an international format in the 24 MAP_RoutingRequest Invoke message, the IIF shall populate the MSISDN field in the 25 MAP_PROVIDE_ROAMING_NUMBER message with it. If the MobileDirectoryNumber is in 26 National format, the IIF shall convert it to an International format before populating the MSISDN 27 field1. 28
The IIF shall then populate the MSC Number field in the 29 MAP_PROVIDE_ROAMING_NUMBER message with the serving MSC Number that had been 30 stored in the IIF at the time of the subscriber’s location registration. 31
The IIF shall then send the MAP_PROVIDE_ROAMING_NUMBER message to the GSM 32 MSC/VLR and wait for a response. 33
If the response indicates that the retrieval of routing information procedure has been 34 successful, the IIF shall deduce the MSRN from the MAP_PROVIDE_ROAMING_NUMBER 35 ack and populate the field Digits (Destination) in the MAP_RoutingRequest Return Result. The 36
1 As an alternative, the MSISDN may also be retrieved directly from the Subscriber profile, pre-provisioned in the IIF.
N.S0028
27
IIF shall populate the BillingID field with the value of the BillingID received in the 1 RoutingRequest Invoke message. 2
The IIF shall then populate the MSCID (Serving) field with its own ID and forward it to the ANSI-3 41 HLR. 4
If the response is unsuccessful, the IIF shall map any error code it receives to either an 5 AccessDeniedReason value in the MAP_RoutingRequest Return Result or to an Error Code in 6 a Return Error message. 7
For the cases of failure at the IIF on reception of the MAP_RoutingRequest Invoke message 8 (e.g. missing expected parameter, unknown subscriber), the procedures described in ANSI-41 9 [6] are also applicable to the IIF. 10
For the cases of failure at the IIF on reception of the PROVIDE_ROAMING_NUMBER 11 response, the procedures described in GSM 09.02 [3] for retrieval of routing information are 12 also applicable to the IIF. 13
14
4.2.1.1.2 ANSI-41 Foreign Mode 15
16
If the IIF receives a MAP_PROVIDE_ROAMING_NUMBER message from the GSM HLR, it 17 shall check if the terminating call can be placed to that subscriber. 18
If the IIF determines that the subscriber is Not Reachable, it shall send a 19 MAP_PROVIDE_ROAMING_NUMBER Response message with User Error field indicating 20 Absent Subscriber to the GSM HLR. 21
Otherwise, the IIF shall deduce the MSID and ESN from the IMSI and populate the 22 corresponding fields of the ANSI MAP_RoutingRequest Invoke. 23
The IIF shall create a billing ID for that transaction and populate the corresponding field of the 24 ANSI MAP_RoutingRequest Invoke. 25
The MSCID address field shall be set to the IIF address. 26
The IIF shall also assign a predefined value (vendor specific) to the SystemMyTypeCode field, 27 indicating the IIF vendor identity. 28
If the MSISDN field is present in the MAP_PROVIDE_ROAMING_NUMBER, the IIF shall 29 populate the MobileDirectoryNumber field in the RoutingRequest Invoke message with it1. 30
The IIF shall set the MSCIdentificationNumber and PC_SSN fields to its own ID. 31
The IIF shall then send the RoutingRequest Invoke message to the ANSI-41 MSC/VLR and 32 wait for a response. 33
If the response indicates that the retrieval of routing information procedure has been 34 successful, the IIF shall deduce the MSRN from the Digits (Destination) field of the 35 RoutingRequest Return Result and populate the MSRN field in the 36 MAP_PROVIDE_ROAMING_NUMBER ack. The MSRN shall have an E.164 format. Therefore, 37 if the TLDN is not in international format, the IIF shall add the country code digits associated 38 with the country of the serving system The IIF shall then forward the 39 MAP_PROVIDE_ROAMING_NUMBER ack to the GSM HLR. 40
1 As an alternative, the MSISDN may also be retrieved directly from the Subscriber profile, pre-provisioned in the IIF.
N.S0028
28
If the response is unsuccessful, the IIF may receive a RoutingRequest Return Result with the 1 field AccessReasonDenied present, or a ReturnError message with an Error Code value. The 2 IIF shall map any Access Reason Denied or Error Code it receives to a User or Provider Error 3 in the MAP_PROVIDE_ROAMING_NUMBER return error. 4
For the cases of failure at the IIF on reception of the MAP_PROVIDE_ROAMING_NUMBER 5 request, (e.g. missing expected parameter, unidentified subscriber), the procedure described in 6 GSM 09.02 [3] for retrieval of routing information are applicable to the IIF. 7
For the cases of failure at the IIF on reception of the MAP_RoutingRequest Invoke message 8 return Result, the procedure described in ANSI-41 [6] for automatic call delivery is applicable to 9 the IIF. 10
11
4.2.1.2 Mapping of Messages, Parameters & Parameter Values 12
13
4.2.1.2 presents the mapping of messages, parameters and parameter values that the IIF shall 14 perform. The mapping in the following tables is applicable to the generic Call delivery 15 scenarios. For mapping of parameters relevant to the Optimal Routing cases, refer to 4.2.3. For 16 mapping of parameters relevant to CLIP/CLIR refer to 4.3.4. 17
18
4.2.1.2.1 Mapping of Messages 19
20
Table 14 shows the mapping between GSM MAP messages and ANSI MAP messages related 21 to Automatic Call Delivery regardless of the mode of operation (GSM Foreign Mode or ANSI-41 22 Foreign Mode) 23
Table 14: Automatic Call Delivery Message Mapping 24
GSM MAP Message ANSI-41 MAP Message
PROVIDE ROAMING NUMBER REQUEST
Routreq
PROVIDE ROAMING NUMBER REQUEST REPONSE
routereq
25
N.S0028
29
1
4.2.1.2.2 Mapping of Parameters 2
3
Table 15 and Table 16 show the mapping of parameters, which the IIF shall perform regardless 4 of the mode of operation (GSM Foreign Mode or ANSI-41 Foreign Mode). 5
Table 15: ROUTREQ ↔↔↔↔ PROVIDE_ROAMING_NUMBER_REQUEST Parameter Mapping 6
ROUTREQ Status Provide Roaming Number Request
Status
BillingID (Originating) M -
ElectronicSerialNumber M -
MobileStationIDentity M IMSI M
MSCID (Originating MSC) M
SystemMyTypeCode (Originating MSC)
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 -
7
N.S0028
30
Table 15: ROUTREQ ↔↔↔↔ PROVIDE_ROAMING_NUMBER_REQUEST Parameter Mapping 1 (concluded) 2
ROUTREQ Status Provide Roaming Number Request
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 Announcement
C
- Call Reference Number R
(Note 5)
- OR Interrogation C
- Alerting Pattern C
- CCBS Call C
CDMAServiceOption O -GSM BearerServiceCode or GSM TeleService
O (Note 6)
3
Note 1: For encoding of those parameters, refer to “4.3.4 Calling Number/Line Identification 4 Presentation/Restriction”. 5
Note 2: If present from the PRN request 6
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 record 8
Note 5: Only for Optimal Routing after late Call Forwarding 9
-Note 6: Optional, if the network settings support data, a mapping may be performed as 10 described in Table 92 11
12
N.S0028
31
1
The following table shows the mapping of parameters between the Provide Roaming Number 2 Response and the Routing Request Return Result messages regardless of the mode of 3 operation (GSM Foreign Mode or ANSI-41 Foreign Mode). 4
Table 16: Provide Roaming Number Response ↔↔↔↔ Routreq Return Result Parameter 5 Mapping 6
Provide Roaming Number ack Status Routreq Return Result Status
Roaming Number* M Digits (Destination) R
- MSCID (Serving) M
User Error* R (Note 1)
AccessDeniedReason R (Note 2)
- BillingID (Anchor) R
- ConditionallyDeniedReason O
- MSCIdentificationNumber R
- PC_SSN (Serving MSC) O
GSM BearerServiceCode or GSM TeleService (Note 3)
O CDMAServiceOption O
7
* These parameters are mutually exclusive 8
Note 1: If the request is unsuccessful. 9
Note 2: If User Error is present in Provide Roaming Number ack. 10
-Note 3: Optional, if the network settings support data, a mapping may be performed as 11 described in Table 92 12
13
Or 14
Table 17: PROVIDE_ROAMING_NUMBER_RESPONSE to Routreq Return Error Mapping 15 (ANSI-41Foreign Mode) 16
Provide Roaming Number ack Status RoutingRequest Return Error
Status
User Error C
Provider Error C
Error Code
O
17
For detailed mapping of User/Provider Error parameter value to the AccessDeniedReason 18 parameter, see Table 22 and Table 23. 19
20
N.S0028
32
Table 18: Routreq Return Error to Provide Roaming Number Response Error Mapping 1 (GSM Foreign mode) 2
Routing Request Return Error Status Provide Roaming Number ack
Status
Error Code O User Error
C
3
N.S0028
33
1
4.2.1.2.2.1 Mapping of parameter values in GSM Foreign Mode 2
3
Default parameter value 4
Table 19 presents how the IIF shall populate the parameters of the Provide Roaming Number 5 message to be sent to the GSM VLR. These fields do not have an equivalent in the received 6 Routing Request Invoke message. 7
Table 19: Provide Roaming Number Request default parameter 8
Parameter Name Status Value
MSC Number M ISDN number of the serving MSC. Stored in the IIF at the time of location registration.
LMSI C Local Mobile Subscriber Identity. Shall be present if the LMSI was sent to the IIF at location updating
GSM Bearer Capability C Shall be absent
Network Signal Info C Shall be absent
Suppression of Announcement C CAMEL Specific Information Element (IE)
Call Reference Number C Not required unless Optimal Routing for LateCall Forwarding is supported by the IIF.
GMSC address C Not required unless CAMEL or Optimal Routing for Late Call Forwarding is supported by the IIF (and if so, it shall be set to the IIF address)
OR Interrogation C Not required to be sent by the IIF (however may be received as a result of Optimal Routing)
Alerting Pattern C CAMEL Specific Information Element (IE)
CCBS Call C CCBS Specific IE
9
10
N.S0028
34
1
Table 20 presents how the IIF shall populate the parameters of the Routing Request Return 2 Result message to be sent to the ANSI-41 HLR. These fields cannot be mapped from the 3 received Provide Roaming Number request message. 4
Table 20: RoutingRequest Return Result default parameters 5
Parameter Name Status Default Value
MSCID (Serving) M Shall be set to the serving MSC address
BillingID (Anchor) O When the IIF receives the Routing Request Invoke message it shall store the BillingID and use it to populate this field.
AccessDeniedReason O See Table 24
ConditionallyDeniedReason O Shall be absent.
MSCIdentificationNumber O Shall be set to the serving MSC address
PC_SSN (Serving MSC) O Shall be absent
-CDMAServiceOption O If received in Invoke or from Profile
6
7
N.S0028
35
1
4.2.1.2.2.2 Mapping of parameter values in ANSI-41 Foreign Mode 2
3
Default parameter value 4
Table 21 presents how the IIF shall populate the parameters of the Routing Request Invoke 5 message to be sent to the ANSI-41 VLR. These fields cannot be mapped from the received 6 Provide Roaming Number request message. 7
Table 21: Routing Request Invoke default parameter 8
ROUTEREQ Status Default Value
BillingID (Originating) M Shall be created by the IIF
ElectronicSerialNumber M Shall be deducted from the IMSI received in the PRN request. For each subscriber provisioned in the IIF, there must be a table defining a correspondence between IMSI on the one hand and MIN/ESN on the other hand.
MSCID (Originating MSC) M Shall be set to the IIF address.
SystemMyTypeCode (IIF vendor Id)) M Assigned by the IIF
AlertCode O May be absent
CallingPartyNumberString1 O See Table 83 to Table 86
CallingPartyNumberString2 O See Table 83 to Table 86
CallingPartySubaddress O See Table 83 to Table 86
DestinationDigits O Shall be absent
DMH_AccountCodeDigits O Shall be absent
DMH_AlternateBillingDigits O Shall be absent
DMH_BillingDigits O Shall be absent
LegInformation O Shall be absent (not a multileg call)
LocationAreaID O Shall be absent
MSCIdentificationNumber O Shall be set to identify the IIF, as the information may be required at a later time by the ANSI VMSC to redirect the call.
NoAnswerTime O Shall be absent
OneTimeFeatureIndicator O Shall be absent
PC_SSN (Originating MSC) O Shall be set to identify the IIF, as the information may be required at a later time by the ANSI VMSC to redirect the call.
PilotBillingID O Shall be absent [multi leg call]
PilotNumber O Shall be absent [pilot directory number for a multi-leg call]
9
N.S0028
36
Table 21: Routing Request Invoke default parameter (concluded) 1
ROUTEREQ Status Default Value
RedirectingNumberString O Shall be absent
RedirectingSubAddress O Shall be absent
SenderIdentificationNumber O Shall be absent
TerminationTreatment O Shall be absent or set to 1 (MS Termination which is also the default value)
TerminationTriggers O Shall be absent. Define the treatment to apply (termination or redirection)
VoiceMailboxNumber O Shall be absent
VoiceMailPIN O Shall be absent
-CDMAServiceOption O From Profile or from Location Request Invoke if received
2
4.2.1.3 Error Handling 3
4
The following tables present the appropriate GSM MSC/VLR negative response to a Provide 5 Roaming Number message as described in GSM 09.02 [3]. 6
Appropriate User Error value: 7
User Error value
Absent Subscriber
No roaming Number available
Facility Not supported
System Failure
Data Missing
Unexpected Data Value
8
Appropriate Provider Error value: 9
Provider Error value
Duplicated Invoke ID
Not supported service
Mistyped parameter
Resource limitation
Initiating Release
N.S0028
37
1
2
Appropriate Provider Error value (concluded): 3
Provider Error value
Unexpected response from the peer
Service Completion Failure
No response from the peer
Invalid response received
4
The following tables present the appropriate ANSI-41 MSC/VLR negative response to a 5 Routing Request Invoke message as described in ANSI-41 [6]. 6
7
Appropriate AccessDeniedReason parameter values in the RoutingRequest Return 8 Result: 9
AccessDeniedReason
Inactive
Busy
No page Response
Unavailable
10
Appropriate Error Code parameter value in the Return Error message: 11
Error Code value
UnrecognizedMIN
UnrecognizedESN
ResourceShortage
OperationNotSupported
ParameterError (Note 1)
UnrecognizedParameterValue
SystemFailure
MissingParameter
12
Note 1: The FaultyParameter field shall be present and populated with the appropriate Parameter 13 Identifier. 14
15
N.S0028
38
1
4.2.1.3.1 GSM Foreign Mode 2
3
The IIF is responsible for the mapping of the User Error/Provider Error received in the Provide 4 Roaming Number response to the appropriate AccessDeniedReason in the RoutingRequest 5 Return Result message or Error Code in the Return Error. 6
The following tables present the preferred mapping. 7
Table 22: PRN response User Error to routreq Return Error Mapping 8
User Error value received in PRN response
AccessDeniedReason in routreq or Error Code in Return Error.
Absent Subscriber AccessDeniedReason to Unavailable
No roaming Number available Error Code to System Failure
Facility Not supported Error Code to System Failure
System Failure Error Code to System Failure
Data Missing Error Code to System Failure
Unexpected Data Value Error Code to System Failure
9
10
Table 23: PRN Response Provider Error to routereq Return Error Mapping 11
Provider Error value received in PRN Confirm.
Error Code value in Return Error
Duplicated Invoke ID System Failure
Not supported service System Failure
Mistyped parameter System Failure
Resource limitation System Failure
Initiating Release System Failure
Unexpected response from the peer System Failure
Service Completion Failure System Failure
No response from the peer System Failure
Invalid response received System Failure
12
13
N.S0028
39
1
4.2.1.3.2 ANSI-41 Foreign Mode 2
3
The IIF is responsible for the mapping of the AccessDeniedReason received in the 4 RoutingRequest Return Result or Error Code received in the Return Error to the appropriate 5 User 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 Error 8 Mapping 9
AccessDeniedReason received in the RoutingRequest Return Result
User Error in the PRN response
Inactive Absent Subscriber
Busy Absent Subscriber
No page Response Absent Subscriber
Unavailable Absent Subscriber
10
Table 25: Routing Request Return Error to PRN User Error Mapping 11
Error Code value User Error in the PRN response
UnrecognizedMIN System Failure
UnrecognizedESN System Failure
ResourceShortage System Failure
OperationNotSupported System Failure
ParameterError System Failure
UnrecognizedParameterValue System Failure
SystemFailure System Failure
MissingParameter System Failure
12
13
N.S0028
40
1
4.2.2 Invocation of Conditional Call Forwarding in ANSI-41 Foreign Mode 2
3
Existing call forwarding procedures described in either GSM 09.02 [3] or ANSI-41 [6] are also 4 directly applicable to the IIF when it is emulating a GSM or ANSI-41 functional network element. 5 Enhancements and modifications to ANSI-41 [7], 0 are also applicable. 6
7
4.2.2.1 Detailed Procedures 8
9
4.2.2.1.1 Invocation of Call Forwarding before the call has been routed to the serving 10 MSC 11
12
The Call Forwarding procedure is invoked in the IIF when a terminating call attempt results in 13 an “unavailable” indication and the IIF is required to provide treatment for the “unavailable” 14 situation. 15
The following procedures are applicable at the IIF for Call Forwarding invocation: 16
If the IIF receives an ANSI_MAP_routreq indicating ‘access denied’, the IIF shall determine if 17 call forwarding is applicable for the call. 18
If call forwarding is applicable for the call, the IIF shall send a GSM MAP _PROVIDE 19 ROAMING_NUMBER_RESPONSE to the HLR. 20
The IIF shall process the forwarding request in one of the following two optional methods: 21
• Send the Forward_To_Number that corresponds to the access denied reason (stored 22 for the subscriber in the IIF). Refer to Table 26 or, 23
• Send a user error indicating “Absent Subscriber”. Refer to Table 27. 24
If call forwarding is not applicable for the call, the IIF shall follow the procedures outlined in 25 4.2.1 of this document 26
If the IIF receives an ANSI_MAP routreq Return Error or a Reject message, the IIF shall map 27 the Error Code it receives to a suitable User Error in the 28 MAP_PROVIDE_ROAMING_NUMBER RESPONSE as described in 4.2.1 of this document 29
For the cases of failure at the IIF on reception of the MAP_RoutingRequest Return Result, the 30 procedure described in ANSI-41 [6] for automatic call delivery is applicable to the IIF. 31
32
4.2.2.1.2 Invocation of Call Forwarding after the call has been routed to the serving 33 MSC 34
35
If the called party is either busy, not reachable or does not answer the call, the serving MSC 36 may redirect the call by sending REDREQ to the IIF, indicating the reason for failure. 37
If the IIF receives an ANSI_MAP_REDREQ, it shall determine if the message can be 38 processed: 39
N.S0028
41
If the message can be processed and optimal routing is supported, the IIF shall 1 follow the procedures outlined in 4.2.3 of this document for Optimal Routing for 2 late call forwarding. 3
If the message can be processed but optimal routing is not supported, the IIF 4 shall send an ANSI_MAP_redreq Reject message. On receipt of the Reject 5 message, the serving MSC may attempt to redirect the call by sending a 6 TRANUMREQ message to the IIF. 7
If the message cannot be processed, the IIF shall send an ANSI_MAP redreq 8 Return Reject message with the appropriate error code. On receipt of the Return 9 Reject message, the serving MSC may attempt to redirect the call by sending a 10 TRANUMREQ message to the IIF. 11
If the IIF receives an ANSI_MAP_TRANUMREQ, it shall determine if the 12 message can be processed. 13
If the message can be processed, the IIF shall send an ANSI_MAP_tranumreq 14 indicating the forwarded-to-number. 15
If the message cannot be processed, the IIF shall send an ANSI_MAP tranumreq indicating the 16 reason for failure. 17
18
4.2.2.2 Mapping of Messages, Parameters & Parameter Values 19
20
4.2.2.2 presents the mapping of messages, parameters and parameter values that the IIF shall 21 perform. 22
4.2.2.2.1 Mapping of Messages 23
24
These messages are the same as those in 4.2.1.2.1. 25
26
4.2.2.2.2 Mapping of Parameters 27
28
Table 26 represents how the IIF shall map the value of the parameter it has received to 29 populate the fields of the message it shall transmit. 30
Table 26: ROUTEREQ Return Result to Provide Roaming Number Response parameter 31 mapping (Option 1) 32
Routing Request Return Result Status Provide Roaming Number ack. Status
AccessDeniedReason = Busy, Inactive, No Page Response or Unavailable
O Roaming Number C
33
34
N.S0028
42
Table 27: ROUTREQ Return Result to Provide Roaming Number Response Parameter 1 Mapping (Option 2) 2
Return Error Status Provide Roaming Number ack Status
AccessDeniedReason = Busy, Inactive, No Page Response or Unavailable
O User Error = Absent Subscriber C
3
Default parameters value 4
N/A 5
4.2.2.3 Error Handling 6
7
The following table presents the appropriate GSM MSC/VLR negative response to a Provide 8 Roaming Number message as described in GSM 09.02 [3]. 9
Appropriate User Error value: 10
User Error value
Absent Subscriber
No roaming Number available
Facility Not supported
System Failure
Data Missing
Unexpected Data Value
11
Appropriate Provider Error value: 12
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
13
N.S0028
43
The following table presents the appropriate ANSI-41 MSC/VLR negative response to a 1 Routing Request Invoke message as described in in ANSI-41 [6]. 2
Appropriate AccessDeniedReason parameter values in the RoutingRequest Return Result: 3
4
AccessDeniedReason
Inactive
Busy
No page Response
Unavailable
5
Appropriate Error Code parameter value in the Return Error message: 6
7
Error Code value
UnrecognizedESN
ResourceShortage
OperationNotSupported
ParameterError*
UnrecognizedParameterValue*
SystemFailure
MissingParameter*
8
Table 28: Return Error to User Error in the PRN response Error Mapping 9
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
10
11
N.S0028
44
4.2.3 Optimal Routing after Late Call Forwarding 1
2
An optimal routing for late call forwarding procedure covers the interoperability between 3 ANSI-41 and GSM MAP signaling to support Optimal Routing after Late Call Forwarding. This 4 signaling is based on ANSI-41 [6] and GSM 9.02 [3]. 5
From GSM 03.79 [2], a Late Call Forwarding procedure is defined as Call Forwarding 6 performed after the call has been extended to the Visited PLMN (VPLMN) of the forwarding 7 subscriber. This forwarding is based on subscription of supplementary services like Conditional 8 Call Forwarding on Busy, Conditional Call Forwarding on No Reply, and Conditional Call 9 Forwarding on Not Reachable detected in the VPLMN of the forwarding subscriber. Note that 10 the Late Call Forwarding procedure may be invoked in the Interrogating PLMN (IPLMN) or in 11 the VPLMN of the forwarding subscriber. 12
The procedure is applicable when the Subscriber has appropriate forwarding service active; 13 and Optimal Routing is enabled. 14
15
4.2.3.1 Detailed Procedures 16
17
Roaming may occur either from ANSI-41 to GSM network or vice versa. Since the solutions and 18 ultimate functionality provided to the roaming subscriber are not symmetrical, the Optimal 19 Routing for Late Call Forwarding procedure is different in both cases. 4.2.3.1 defines roaming 20 procedures when roaming from GSM to ANSI-41 network and roaming from ANSI-41 to GSM 21 network respectively. 22
23
4.2.3.1.1 ANSI-41 Foreign Mode 24
25
When the IIF receives a GSM-Provide Roaming Number message, it stores GMSC Address, 26 Call Reference Number and OR Interrogation Indicator parameters if they are present. It then 27 sends an ANSI-41Routing Request message to the VLR and awaits a response. 28
If successful ANSI-41 Routing Request response is received from VLR, it converts Temporary 29 Location Directory Number (TLDN) in to Mobile Subscriber Roaming Number (MSRN) and send 30 this information to HLR in GSM-Provide Roaming Number Acknowledge message. 31
Otherwise, the IIF sends a GSM-Provide Roaming Number negative response to HLR and 32 discards GMSC Address, Call Reference Number and OR Interrogation Indicator parameter 33 information if present. 34
If the IIF receives ANSI-41 Redirection Request message, it shall check GMSC Address. 35
If GMSC Address is available, it shall map Redirection Reason parameter to Forwarding 36 Reason. The IIF sends this information in addition to the Call Reference Number and 37 Forwarding Number in GSM-Resume Call Handling message to originating MSC using GMSC 38 Address and await a response. 39
N.S0028
45
Otherwise, the IIF rejects the ANSI-41 Redirection Request. 1
If the IIF receives GSM-Resume Call Handling Acknowledge message, it sends response of 2 ANSI-41- Redirection Request message to the MSC. Otherwise, if negative response of GSM-3 Resume Call Handling is received, the IIF shall send ANSI-41-Redreq Return Error with an 4 appropriate error code to the MSC. 5
6
4.2.3.1.2 GSM Foreign Mode 7
8
When the IIF receives an ANSI-41-Routing Request message, it stores Originating MSC ID, 9 TERMTRMT if present. The IIF then generates a Call Reference Number and sends it as a 10 parameter in the a GSM-Provide Roaming Number message to the VLR along with the GMSC 11 address set to the IIF address and along with the GMSC address set to the IIF address awaits 12 a response. 13
If successful GSM-Provide Roaming Number Acknowledge is received from VLR, it converts 14 MSRN to TLDN and sends this information to HLR in ANSI-41-Routing Request response 15 message. 16
Otherwise, the IIF sends an ANSI-41- Routing Request negative response (routreq) to HLR and 17 discards information of Originating MSCID and TERMTRMT (if present). 18
If the IIF receives GSM-Resume Call Handling, it shall use its Call Reference Number 19 parameter to corelate and determine the ANSI-41 originating MSC, and the IIF shall map the 20 Forwarding Reason parameter to Redirection Reason. The IIF sends this information to the 21 originating MSC in the ANSI-41-Redirection Request message and awaits a response. 22
If the IIF receives ANSI-41-Redirection Request response message, it sends a GSM-Resume 23 Call Handling Acknowledge message to the MSC. Otherwise, if negative response is received 24 (in form of return error), the IIF shall send GSM-Resume Call Handling Return Error with an 25 appropriate error code to the MSC. 26
The IIF shall perform the translation of messages, parameters and parameter values related to 27 Optimal Routing Support for Late Call Forwarding procedure in accordance with the tables 28 presented here. Refer to GSM 3.18 [1] and GSM 3.79 [2] and ANSI -41 [6] for a description of 29 messages, parameters and parameter values. 30
31
N.S0028
46
1
4.2.3.2 Mapping of Messages, Parameters & Parameter Values 2
3
4.2.3.2.1 Mapping of Messages 4
5
Table 29 shows the translation between GSM MAP messages and ANSI-41 MAP messages 6 related to Optimal Routing Support for Late Call Forwarding procedure. 7
Table 29: Optimal Routing for Late Call Forwarding Message Mapping 8
GSM MAP Message ANSI-41 MAP Message
GSM-Provide Roaming Number Request ROUTEREQ
GSM- Provide Roaming Number Acknowledge
routereq
GSM-Resume Call Handling REDREQ
GSM-Resume Call Handling Acknowledge redreq
9
4.2.3.2.2 Mapping of Parameters 10
11
The following tables show the mapping of parameters, which the IIF shall perform regardless of 12 the mode of operation. 13
14
N.S0028
47
1
Table 30: GSM Provide_Roaming_Number ↔↔↔↔ ANSI-41 ROUTEREQ Parameter Mapping 2
GSM Provide_Roaming_Number Status ANSI-41-Route_Request (ROUTEREQ)
Status
IMSI M MSID M
ESN M
MSC Number M -
MSISDN (Note 1) R MDN R
LMSI 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
DMHData:
- DMH AccountCodeDigits O
- DMH AlternateBillingDigits O
3
4
N.S0028
48
1
Table 30: GSM Provide_Roaming_Number ↔↔↔↔ ANSI-41 ROUTEREQ Parameter Mapping 2 (concluded) 3
GSM Provide_Roaming_Number Status ANSI-41-Route_Request (ROUTEREQ)
Status
- 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 values 7
IMSI MSID See Automatic Call Delivery
ESN See Automatic Call Delivery
MSISDN MDN See Automatic Call Delivery
Billing ID See Automatic Call Delivery
MSCID See Automatic Call Delivery
8
Table 32: Provide_Roaming_Number_Response ↔↔↔↔ routereq Parameter Mapping 9
Provide_Roaming_Number_Response
Status ANSI-41 Route_Request (routereq)
Status
Roaming Number M TLDN [DGTSDEST] M
- MSCID M
- BILLID M
User 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
Table 33: Mapping of Parameter Values 13
Roaming Number TLDN See Automatic Call Delivery
MSCID See Automatic Call Delivery
BILLID See Automatic Call Delivery
User Error ACCDEN See Automatic Call Delivery
14
N.S0028
49
1
Table 34: Resume_Call_Handling ↔↔↔↔ REDREQ Parameter Mapping 2
GSM Resume_Call_Handling Status ANSI-41 Redirection_Request (REDREQ)
Status
Call Reference Number M -
Basic Service group M -
IMSI M MSID M
ESN M
ForwardingData:
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
3
Table 35: Mapping of Parameters Values 4
IMSI MSID See Automatic Call Delivery
MSN See Automatic Call Delivery
Forwarding Reason
REDREASON See below
BILLID See Automatic Call Delivery
5
Table 36: Resume_Call_Handling_Response ↔↔↔↔ redreq Parameter Mapping 6
Resume_Call_Handling_Response
Status Redirection_Request (redreq) Status
- -
7
8
N.S0028
50
1
4.2.3.2.3 Mapping ANSI-41 Redirection_Reason and GSM Forwarding Reason for 2 ANSI-41 Foreign Mode 3
4
Table 37: ANSI-41 Redirection_Reason to GSM Forwarding_Reason 5
Redirection_Reason Forwarding_Reason
Busy Call Forwarding Busy
No Answer Call Forwarding No Reply
No Page Response Call Forwarding Not Reachable
Call Accepted (Note1, Note2) -
Unavailable Call Forwarding Not Reachable
Unroutable Call Forwarding Not Reachable
Call Refused (Note2) -
6
Notes: 7
1. The "Call Accepted" redirection reason shall not be received from the terminating ANSI-41 8 MSC in ANSI-41-Redirection Request. Hence the mapping of this value may not be 9 applicable. 10
2. These Redirection Reasons do not map to any existing GSM Forwarding Reasons. As a 11 result, if the IIF receives an ANSI-41-Redirection Request message with one of these 12 Redirection Reasons, it shall reject the request. Hence the mapping of this value may not 13 be applicable. 14
15
4.2.3.2.4 Mapping Forwarding Reason to Redirection Reason for GSM Foreign Mode 16
17
Table 38: GSM Forwarding_Reason to ANSI-41 Redirection_Reason 18
Forwarding_Reason Redirectionion_Reason
Call Forwarding Busy Busy
Call Forwarding No Reply No Answer
Call Forwarding Not Reachable No Page Response OR Unavailable
19
20
N.S0028
51
1
4.2.3.3 Error Handling 2
3
Negative Response of GSM-Provide Roaming Number 4
The serving MSC determines that it is unable to provide a routing number and returns this 5 indication to the IIF via a GSM Provide Roaming Number RETURN ERROR component with an 6 error code. 7
Negative Response of GSM-Resume Call Handling 8
The Originating MSC determines that it is unable to redirect the call and returns this indication 9 to 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 MSC 12 consults its internal data structures to determine if the MS is already engaged in a call on this 13 MSC. If termination is to a voice mailbox, the Serving MSC verifies the VMS availability. Finding 14 the MS or VMS busy (or otherwise unable to receive calls), the Serving MSC returns an 15 appropriate indication to the IIF in the ANSI-41 Routing Request response message (routreq). 16 Parameters included are MSCID and ACCDEN. The IIF then forwards the response of ANSI-41 17 Routing 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 indication 20 to the Serving MSC via an ANSI-41-Redirection Request RETURN ERROR component with an 21 error code. 22
4.2.3.3.1 Error Code Mapping 23
24
Table 39: Provide_Roaming_Number to Routing_Request Error Mapping 25
Provide_Roaming_Number User and Provider 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_Number 27 operation without the OR indication to allow for normal routing 28
29
For other error mappings see Automatic Call Delivery, Error Handling, GSM Foreign Mode. 30
Table 40: Routing_Request to Provide_Roaming_Number Error Mapping 31
Routing_Request Error Codes Provide_Roaming_Number User Errors
- -
32
For error mappings see Automatic Call Delivery, Error Handling, ANSI-136 41 Foreign Mode. 33
N.S0028
52
1
Table 41: Resume_Call_Handling to Redirection_Request Error Mapping 2
Resume_Call_Handling
User and Provider Errors
Redirection_Request
Error Codes
OR not allowed (Note 1) SystemFailure
Forwarding failed SystemFailure
Duplicated Invoke ID SystemFailure
Not Supported Service System Failure
Mistyped Parameter System Failure
Resource Limitation System Failure
Initiating Release SystemFailure
Unexpected Response From the Peer SystemFailure
Service Completion Failure SystemFailure
No Response from the Peer SystemFailure
Invalid Response Received SystemFailure
3
Note 1: This error should not occur. The process requires the GMSC support OR. 4
5
Table 42: Redirection_Request to Resume_Call_Handling Error Mapping 6
Redirection_Request
Error Codes
Resume_Call_Handling
User Errors
MissingParameter OR-NotAllowedForwardingFailed
UnrecognizedParameterValue OR-NotAllowedForwardingFailed
UnrecognizedMIN OR-NotAllowedForwardingFailed
UnrecognizedESN OR-NotAllowedForwardingFailed
MIN/HLRMismatch OR-NotAllowedForwardingFailed
OperationSequenceProblem OR-NotAllowedForwardingFailed
TrunkUnavailable OR-NotAllowedForwardingFailed
SystemFailure OR-NotAllowedForwardingFailed
FeatureInactive OR-NotAllowedForwardingFailed
ParameterError OR-NotAllowedForwardingFailed
OperationNotSupported OR-NotAllowedForwardingFailed
ResourceShortage OR-NotAllowedForwardingFailed
7
8
N.S0028
53
1
4.3 Supplementary Services Procedures 2
3
4.3.1 SS Activation and Deactivation 4
5
Because of the similarities in the procedures and signaling between the supplementary service 6 activation and deactivation cases, these are combined into one description. Furthermore, 4.3.1 7 makes use of terms such as "Activate/Deactivate" or 8 "MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS". In all cases in which such terms are used, for 9 activation cases the terms "Activate" or "MAP_ACTIVATE_SS" terms apply. For deactivation 10 cases, the terms "Deactivate" or "MAP_DEACTIVATE_SS" apply. 11
12
4.3.1.1 Detailed Procedures 13
14
4.3.1.1 contains the procedures in the IIF for the case in which the subscriber requests either 15 an activation or deactivation of one of the following supplementary services while roaming in 16 foreign mode (i.e., while roaming in a network of a technology different from that of its home 17 network): 18
19
• Call Waiting (in both GSM and ANSI-136 41 foreign modes) 20
• Call Forwarding Unconditional (in both GSM and ANSI-136 41 foreign modes) 21
• Call Forwarding Busy (in both GSM and ANSI-136 41 foreign modes) 22
• Call Forwarding No Reply (in ANSI-136 41 foreign-mode only) 23
• Call Forwarding Not Reachable (in ANSI-136 41 foreign-mode only) 24
• Call Forwarding No Answer (in GSM foreign-mode only) 25
26
4.3.1.1.1 GSM Foreign Mode 27
28
While in GSM Foreign Mode, the principal role of the IIF, with respect to supplementary service 29 activation and deactivation, is that of handling the GSM MAP_ACTIVATE_SS message (for 30 activation) or the GSM MAP_DEACTIVATE_SS message (for deactivation), as follows: If the 31 IIF receives an GSM MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS message from the GSM 32 serving system, it shall verify the correct format and content of the message as described in 33 GSM 09.02 [3]. 34
For cases in which the received message contains a "Basic service" parameter, the IIF shall 35 also verify that the request for activation/deactivation applies to (at least) speech. If the 36 received request does not include "speech" as one of the services to which the request applies, 37 the IIF shall respond with either a GSM MAP_ACTIVATE_SS or GSM MAP_DEACTIVATE_SS 38 Response message that includes a "User error" parameter with a value of "Illegal SS 39
N.S0028
54
operation". Note that cases in which no "Basic service" parameter is included in the received 1 message are acceptable, since, by default, no "Basic service" parameter indicates that the 2 request applies to all services. 3
4
If the format and content of the message is correct, the IIF shall determine the location of the 5 subscriber’s HLR and send to it an ANSI-41 FeatureRequest INVOKE message populated as 6 described in Table 44 and Table 48. If a failure occurs at the IIF on reception of the GSM 7 MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS message (e.g. missing data), the procedures 8 described in GSM 09.02 [3] are applicable to the IIF. 9
If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF receives an ANSI-41 10 FeatureRequest Return Result message with a FeatureResult parameter set to successful, the 11 IIF shall send a GSM MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS Response message back 12 towards the serving system populated as described in Table 45. 13
If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF instead receives an ANSI-41 14 FeatureRequest Return Result message with a FeatureResult parameter set to unsuccessful, 15 the IIF shall send a GSM MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS Response message 16 back towards the serving system populated as described in Table 45 and Table 53. 17
If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF instead receives an ANSI-41 18 FeatureRequest Return Error message, the IIF shall send a GSM MAP_ACTIVATE_SS/ 19 MAP_DEACTIVATE_SS Response message back towards the serving system populated as 20 described in Table 54. 21
Note that successful supplementary service activation/deactivation cases in GSM foreign mode 22 may result in the subscriber's ANSI-41 HLR sending out an ANSI-41 QUALDIR message to the 23 serving system. For these cases, the IIF would need to map the message to a GSM MAP 24 Insert Subscriber Data message. The mapping of an ANSI-41 QUALDIR message to a GSM 25 MAP Insert Subscriber Data message is covered in the Subscriber Data Management. 26
27
4.3.1.1.2 ANSI-136 41 Foreign Mode 28
29
While in ANSI-136 41 Foreign Mode, the principal role of the IIF, with respect to supplementary 30 service activation, is that of handling the ANSI-41 FeatureRequest INVOKE message, as 31 follows: If the IIF receives an ANSI-41 FeatureRequest INVOKE message from the ANSI-41 32 serving system, it shall verify the correct format and content of the message as described in 33 ANSI-41 [6]. 34
If format and content of the message is correct, the IIF shall determine the location of the 35 subscriber’s HLR and send a GSM MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS Request 36 message populated as described inTable 44 and Table 50. 37
For cases in which the FeatureRequest INVOKE message includes a feature code 38 corresponding to Call Forwarding No Answer, and if the IIF is configured to do so, the IIF may 39 send two MAP_ACTIVATE_SS/ MAP_DEACTIVATE_SS messages, one indicating Call 40 Forwarding No Reply and the other indicating Call Forwarding Not Reachable. These messages 41 may be sent in parallel. The mapping in Table 44 and Table 50 would still be applicable. 42
43
For the cases of failure at the IIF on reception of the ANSI-41 FeatureRequest Return Result 44 message (e.g. parameter error, unrecognized subscriber), the procedures described in ANSI-41 45 [6] are applicable to the IIF. 46
N.S0028
55
If, in response to the a GSM MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS message, the IIF 1 receives a GSM MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS Response message with neither 2 a User Error nor Provider Error parameter, the IIF shall send an ANSI-41 FeatureRequest 3 Return Result message back towards the serving system populated as described in Table 45. 4 For those cases in which two requests had been previously sent by the IIF, the IIF would wait 5 until receiving the responses to both requests before sending the FeatureRequest Return Result 6 message. For cases in which both responses indicate success, the mapping in Table 45 may be 7 applied to either of the responses (as an IIF implementation option). For cases in which one of 8 the responses indicates success and the other failure, the mapping in Table 45 applies to the 9 successful response. 10
If, in response to the GSM MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS message, the IIF 11 instead receives a GSM MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS Response message 12 with a User Error, the IIF shall send either an ANSI-41 FeatureRequest Return Result 13 populated as described in Table 55 or a Return Error populated as described in Table 56. If a 14 Provider Error parameter is included in the received GSM 15 MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS Response message, the IIF shall send an ANSI-16 41 FeatureRequest Return Error message populated with an Error Code as shown in Table 57. 17
For cases in which two requests had been previously sent by the IIF, and both responses 18 indicate failure, the mapping described in Table 55 or Table 56 may be applied to either of the 19 responses (as an IIF implementation option). 20
Note that successful supplementary service activation/deactivation cases in ANSI-136 41 21 foreign mode may result in the subscriber's GSM HLR sending out a GSM MAP Insert 22 Subscriber Data message to the serving system. For these cases, the IIF would need to map 23 the message to an ANSI-41 QUALDIR message. The mapping of GSM MAP Insert Subscriber 24 Data message to an ANSI-41 QUALDIR message is covered in the Subscriber Data 25 Management. 26
27
N.S0028
56
1
4.3.1.2 Mapping of Messages, Parameters & Parameter Values 2
3
4.3.1.2.1 Mapping of Messages 4
5
The following table shows the mapping of messages for the Activation and Deactivation of 6 Supplementary Services. 7
Table 43: Supplementary Service Activation and Deactivation Message Mapping 8
GSM MAP Message ANSI-41 MAP Message
Activate SS Request FEATREQ
Deactivate SS Request FEATREQ
Activate SS Request Response featreq
Deactivate SS Request Response featreq
9
10
4.3.1.2.2 Mapping of parameters 11
12
The following tables show the mapping between the parameters in GSM MAP messages and 13 parameters in the corresponding ANSI-41 messages. The relationships between the 14 parameters shown in the tables are meant to be bi-directional. 15
Table 44: Activate/Deactivate SS Request ↔↔↔↔ FEATREQ Parameter Mapping 16
Activate/Deactivate SS Request Status FEATREQ Status
SS-Code M Digits (Dialed) M
Basic 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
17
18
N.S0028
57
1
Table 44: Activate/Deactivate SS Request ↔↔↔↔ FEATREQ Parameter Mapping (concluded) 2
Activate/Deactivate SS Request Status FEATREQ Status
- PC_SSN O
- SenderIdentificationNumber O
- TransactionCapability O
3
4
N.S0028
58
Table 45: Activate/Deactivate SS Response ↔↔↔↔ Feature Request Return Result Parameter 1 Mapping 2
Activate/Deactivate SS Response
Status Feature Request Return Result Status
Call forwarding information C -
Call barring information C -
SS-Data C -
- FeatureResult (Note1) M
User Error C Announcement List O
Provider 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 a 4 Provider Error is received in the ACTIVATE/DEACTIVATE SS RESPONSE. Or, a User Error 5 mapped to an appropriate value shall be returned if the FeatureResult parameter is set to 6 “Unsuccessful”. See Table 53 7
8
N.S0028
59
Table 46: Activate/Deactivate SS Response ↔↔↔↔ Feature Request Return Error Mapping 1
Activate/Deactivate SS Response
Status Return Error Status
Call forwarding information C
Call barring information C
SS-Data C
User Error C
Provider Error O
Error Code O
- Faulty Parameter O
2
4.3.1.2.2.1 Mapping of parameter values in GSM Foreign Mode 3
4
Activate/Deactivate SS Request to Feature Request Invoke mapping 5
6
This table represents how the IIF shall map the value of the parameter it has received to 7 populate the fields of the message it shall transmit. 8
Table 47: Activate/Deactivate SS Request to FEATREQ Parameter Mapping 9
Activate/Deactivate SS Request Status FEATREQ Status
SS-Code M Digits (Dialed)
This parameter shall consist of an ANSI-41 feature code. The IIF shall support a table mapping GSM supplementary service operations (e.g. CFB activation) to ANSI-41 feature codes.
M
10
Note that no parameter in the FeatureRequest INVOKE message currently supports the 11 mapping from the GSM MAP parameter "Basic service". The "GSM Foreign Mode" part of 12
4.3.2 SS Registration and Erasure contains procedures pertaining to the handling of the "Basic 13 service" parameter, when included in the received GSM MAP message. 14
15
N.S0028
60
1
Default parameter values 2
This table presents how the IIF shall populate the parameters of the Feature Request Invoke 3 message to be sent to the ANSI-41 VLR. These fields cannot be mapped from the received 4 Activate/Deactivate SS request message. 5
Table 48: FEATREQ default parameter 6
FEATREQ Status Default Value
ElectronicSerialNumber M Shall be derived from IMSI information previously received during GSM MAP_OPEN procedures.
MSID (Either MIN or IMSI) M Shall be obtained from mapping from the IMSI received previously (during GSM MAP_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 same unique ID used during registration to identify 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
8
Feature Request Return Result to Activate/Deactivate SS Response mapping 9
10
Mapping of parameter values 11
12
For the successful case (in which a FeatureRequest Return Result is received with the 13 FeatureResult parameter set to “successful”) there are no meaningful parameter mappings to 14 support. For those successful cases, the “Default parameter values” describes how the 15 corresponding GSM Activate/Deactivate SS Response message shall be populated. For the 16 unsuccessful cases, 4.3.1.3 Error Handling describes the appropriate mappings. 17
N.S0028
61
1
Default parameter values 2
3
This table describes the population of the parameters in the Activate/Deactivate SS Response 4 message for successful activation/deactivation cases (i.e. when the received Feature Request 5 Return Result contains a FeatureResult parameter set to “successful”). 6
Table 49: Activate/Deactivate SS Response default parameter values 7
Activate/Deactivate SS Response
Status Default Value
Call forwarding information C Included for cases in which activation request concerned one of the call forwarding features, based on stored information in IIF. SS-Code portion of parameter equal to that in the Activate/Deactivate SS request, and with A-bit of SS-Status portion within this parameter set to either “1” (for activation case) or "0" (for deactivation case). Other bits in field are set to reflect current status of subscriber's profile.
Call barring information C Subscriber activation/deactivation of call barring services not required to be supported by IIF, thus population of this parameter not required.
SS-Data C Included for cases in which activation request concerned Call Waiting, based on stored information in IIF. SS-Code portion of parameter equal to Call Waiting, and with A-bit of SS-Status portion within this parameter set to either “1” (for activation case) or "0" (for deactivation case). Other bits in field are set to reflect current status of subscriber's profile.
8
9
N.S0028
62
1
4.3.1.2.2.2 Mapping of parameter values in ANSI-136 41 Foreign Mode 2
3
Feature Request Invoke to Activate/Deactivate SS Request mapping 4
5
Table 50 represents how the IIF shall map the value of the parameter it has received to 6 populate the fields of the message it shall transmit. 7
8
Table 50: Feature Request Invoke to Activate/Deactivate SS Request Parameter Mapping 9
FEATREQ Status Activate/Deactivate SS Request Status
Digits (Dialed) M SS-Code
The IIF shall support a table mapping ANSI-41 feature codes to GSM supplementary service operations.
M
10
Default parameter values 11
12
Table 51 presents how the IIF shall populate the parameters of the Activate/Deactivate SS 13 Request message to be sent to the GSM HLR. These fields do not have an equivalent in the 14 received Feature Request Invoke message. 15
Table 51: Activate/Deactivate SS Request default parameter 16
Parameter Name Status Value
Basic services C Not required to be included. (Activation/deactivation operation shall apply to all service groups when absent.)
17
GSM Activate/Deactivate SS Response to ANSI-41 Feature Request Return Result 18 mapping 19
20
Mapping of parameter values 21
For the successful case (in which there’s no User error or Provider Error in the received GSM 22 Activate/Deactivate SS Response message), there are no meaningful parameter mappings to 23 support. For those successful cases, the “Default parameter values” describes how the 24 corresponding ANSI-41 FeatureRequest Return Result shall be populated. For the 25 unsuccessful cases, Table 46 describes the appropriate mappings. 26
27
N.S0028
63
1
Default parameter values 2
Table 52 presents how the IIF shall populate the parameters of the Feature Request Return 3 Result message to be sent to the ANSI-41 VLR for successful activation cases. Note that the 4 population of the message may differ for non-activation cases. 5
Table 52: FeatureRequest Return Result default parameter 6
Parameter Name Status Default Value
FeatureResult 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
8
N.S0028
64
1
4.3.1.3 Error Handling 2
3
The following table presents the appropriate GSM MSC/VLR negative response to an 4 Activate/Deactivate SS message as described in GSM 09.02 [3]. 5
Appropriate User Error value: 6
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
7
Appropriate Provider Error value: 8
9
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
10
N.S0028
65
The following table presents the appropriate ANSI-41 MSC/VLR negative response to a 1 Feature Request Invoke message as described in ANSI-41 [6]. 2
Appropriate AccessDeniedReason parameter values in the FeatureRequest Return Result 3 (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
10
N.S0028
66
1
4.3.1.3.1 GSM Foreign Mode 2
3
For cases in which a FeatureRequest Return Result is received by the IIF with a FeatureResult 4 parameter set to “unsuccessful”, if the AnnouncementList parameter is also present, the IIF 5 may use the contents of the AnnouncementList in order to provide a better mapping to the User 6 Error 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 SS 9 Response Error Mapping 10
FeatureRequest Return Result Activate/Deactivate SS Response
FeatureResult ="unsuccessful"
AnnouncementList="UnauthorizedFeatureCode"
User Error = "SS subscription violation"
Or
User Error = “Illegal SS Operation”
FeatureResult ="unsuccessful"
AnnouncementList not present
User Error="System Failure"
11
Table 54: FeatureRequest Return Error to Activate/Deactivate SS Response Error 12 Mapping 13
Error Code value User Error
UnrecognizedMIN System Failure
UnrecognizedESN System Failure
MIN/HLRMismatch System Failure
OperationSequenceProblem System Failure
ResourceShortage System Failure
OperationNotSupported System Failure
ParameterError System Failure
SystemFailure System Failure
UnrecognizedParameterValue System Failure
SystemFailure System Failure
MissingParameter System Failure
14
15
N.S0028
67
1
4.3.1.3.2 ANSI-136 41 Foreign Mode 2
3
The IIF is responsible for the translation of the User Error/Provider Error received in the 4 Activate/Deactivate SS Response to either the appropriate FeatureRequest Return Result 5 message (with FeatureResult set to “unsuccessful” and, if supported, the AnnouncementList 6 parameter) or Error Code in the FeatureRequest Return Error, as shown in the following two 7 tables (Table 55 and Table 56). 8
Table 55: Activate/Deactivate SS Response User Error to FeatureRequest Return Result 9 Mapping 10
Activate/Deactivate SS Response User Error
FeatureRequest Return Result
SS subscription violation FeatureResult="unsuccessful"
AnnouncementList = “UnauthorizedFeatureCode” (if parameter supported by serving system)
11
12
N.S0028
68
1
Table 56: Activate/Deactivate SS Response User Error to FeatureRequest Return Error 2 Mapping 3
Activate/Deactivate SS Response User Error
FeatureRequest Return Error Error Code
System Failure System Failure
Data Missing System Failure
Unexpected Data Value System Failure
Bearer service not provisioned Not applicable to SS activation/deactivation requests sent by IIF (If received, may be mapped to System Failure)
Teleservice not provisioned Not applicable to SS activation/deactivation requests sent by IIF (If received, may be mapped to System Failure)
Call Barred Not applicable to SS activation/deactivation requests sent by IIF (If received, may be mapped to System Failure)
Illegal SS operation Not applicable to SS activation/deactivation requests sent by IIF (If received, may be mapped to System Failure)
SS error status Not applicable to SS activation/deactivation requests sent by IIF (If received, may be mapped to System Failure)
SS incompatibility Not applicable to SS activation/deactivation requests sent by IIF (If received, may be mapped to System Failure)
Negative PW check Not applicable to SS activation/deactivation requests sent by IIF (If received, may be mapped to System Failure)
Number of PW Attempts Violation Not applicable to SS activation/deactivation requests sent by IIF (If received, may be mapped to System Failure)
4
5
N.S0028
69
1
Table 57: Activate/Deactivate SS Response Provider Error to Feature Request Return 2 Error Mapping 3
Provider Error value received in Activate/Deactivate SS Response
Feature Request Return Error
Error Code
Duplicated Invoke ID System Failure
Not supported service System Failure
Mistyped parameter System Failure
Resource limitation System Failure
Initiating Release System Failure
Unexpected response from the peer System Failure
Service Completion Failure System Failure
No response from the peer System Failure
Invalid response received System Failure
4
5
N.S0028
70
1
4.3.2 SS Registration and Erasure 2
3
4.3.2.1 Registration 4
5
4.3.2.1.1 Detailed Procedures 6
7
4.3.2.1.1 contains the procedures in the IIF for the case in which the subscriber requests 8 registration of information in association with one of the following supplementary services while 9 roaming in foreign mode (i.e., while roaming in a network of a technology different from that of 10 its home network): 11
• Call Forwarding Unconditional (in both GSM and ANSI-136 41 foreign modes) 12
• Call Forwarding Busy (in both GSM and ANSI-136 41 foreign modes) 13
• Call Forwarding No Reply (in ANSI-136 41 foreign-mode only) 14
• Call Forwarding Not Reachable (in ANSI-136 41 foreign-mode only) 15
• Call Forwarding No Answer (in GSM foreign-mode only) 16
17
4.3.2.1.1.1 GSM Foreign Mode 18
19
While in GSM Foreign Mode, the principal role of the IIF, with respect to supplementary service 20 registration is that of handling the GSM MAP_REGISTER_SS as follows: If the IIF receives an 21 GSM MAP_REGISTER_SS message from the GSM serving system, it shall verify the correct 22 format and content of the message as described in GSM 09.02 [3]. 23
24
For cases in which the received message contains a "Basic service" parameter, the IIF shall 25 also verify that the request for registration applies to (at least) speech. If the received request 26 does not include "speech" as one of the services to which the request applies, the IIF shall 27 respond with either a GSM MAP_REGISTER_SS Response message that includes a "User 28 error" parameter with a value of "Illegal SS Operation". Note that cases in which no "Basic 29 service" parameter is included in the received message are acceptable, since, by default, no 30 "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 the 33 subscriber’s HLR and send to it an ANSI-41 FeatureRequest INVOKE message populated as 34 described in Table 59, Table 62 and Table 63. If a failure occurs at the IIF on reception of the 35 GSM MAP_REGISTER_SS message (e.g. missing data), the procedures described in GSM 36 09.02 [3] are applicable to the IIF. 37
38
N.S0028
71
If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF receives an ANSI-41 1 FeatureRequest Return Result message with a FeatureResult parameter set to successful, the 2 IIF shall send a GSM MAP_REGISTER_SS Response message back towards the serving 3 system 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-41 5 FeatureRequest Return Result message with a FeatureResult parameter set to unsuccessful, 6 the IIF shall send a GSM MAP_REGISTER_SS Response message back towards the serving 7 system 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-41 9 FeatureRequest Return Error message, the IIF shall send a GSM MAP_REGISTER_SS 10 Response 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 result 12 in the subscriber's ANSI-41 HLR sending out an ANSI-41 QUALDIR message to the serving 13 system. For these cases, the IIF would need to map the message to a GSM MAP Insert 14 Subscriber Data message. The mapping of an ANSI-41 QUALDIR message to a GSM MAP 15 Insert Subscriber Data message is covered in the Subscriber Data Management. 16
17
4.3.2.1.1.2 ANSI-136 41 Foreign Mode 18
19
While in ANSI-136 41 Foreign Mode, the principal role of the IIF, with respect to supplementary 20 service registration, is that of handling the ANSI-41 FeatureRequest INVOKE message, as 21 follows: if the IIF receives an ANSI-41 FeatureRequest INVOKE message from the ANSI-41 22 serving system, it shall verify the correct format and content of the message as described in 23 ANSI-41 [6]. If format and content of the message is correct, the IIF shall determine the 24 location of the subscriber’s HLR and send a GSM MAP_REGISTER_SS Request message 25 populated as described in in Table 59, Table 66 and Table 67. For cases in which the 26 FeatureRequest INVOKE message includes a feature code corresponding to Call Forwarding 27 No Answer, and if the IIF is configured to do so, the IIF may send two MAP_REGISTER_SS 28 messages, one indicating Call Forwarding No Reply and the other indicating Call Forwarding 29 Not Reachable. These messages may be sent in parallel. The mapping in Table 59, Table 66 30 and Table 73 should still be applicable. 31
32
For the cases of failure at the IIF on reception of the ANSI-41 FeatureRequest Return Result 33 message (e.g. parameter error, unrecognized subscriber), the procedures described in ANSI-41 34 [6] are applicable to the IIF. 35
If, in response to the a GSM MAP_REGISTER_SS Request message, the IIF receives a GSM 36 MAP_REGISTER_SS Response message with neither a User Error nor Provider Error 37 parameter, the IIF shall send an ANSI-41 FeatureRequest Return Result message back towards 38 the serving system populated as described in Table 60 and Table 67. For those cases in which 39 two requests had been previously sent by the IIF, the IIF would wait until receiving the 40 responses to both requests before sending the FeatureRequest Return Result message. For 41 cases in which both responses indicate success, the mapping in Table 60 may be applied to 42 either of the responses (as an IIF implementation option). For cases in which one of the 43 responses indicates success and the other failure, the mapping in Table 60 applies to the 44 successful response. 45
If, in response to the GSM MAP_REGISTER_SS Request message, the IIF instead receives a 46 GSM MAP_REGISTER_SS Response message with a User Error, the IIF shall send either an 47 ANSI-41 FeatureRequest Return or a Return Error as described in 4.3.2.2.3 Error Handling. 48
N.S0028
72
If a Provider Error parameter is included in the received GSM MAP_REGISTER_SS Response 1 message, the IIF shall send an ANSI-41 FeatureRequest Return Error message populated with 2 an Error Code as described in 4.3.2.2.3 Error Handling. For cases in which two requests 3 had been previously sent by the IIF, and both responses indicate failure, the procedures 4 described may be applied to either of the responses (as an IIF implementation option). 5
Note that successful supplementary service registration cases in ANSI-136 41 foreign mode 6 may result in the subscriber's GSM HLR sending out a GSM MAP Insert Subscriber Data 7 message to the serving system. For these cases, the IIF would need to map the message to 8 an ANSI-41 QUALDIR message. The mapping of GSM MAP Insert Subscriber Data message 9 to an ANSI-41 QUALDIR message is covered in the Subscriber Data Management. 10
11
4.3.2.1.2 Mapping of Messages, Parameters & Parameter Values 12
13
4.3.2.1.2 presents the mapping of messages, parameters and parameter values that the IIF 14 shall perform. 15
16
4.3.2.1.2.1 Mapping of Messages 17
18
Table 58 shows the mapping of messages for Supplementary Service Registration 19
Table 58: Supplementary Service Registration Message Mapping 20
GSM MAP Message ANSI-41 MAP Message
REGISTER SS REQUEST FEATREQ
REGITER SS REQUEST RESPONSE featreq
21
N.S0028
73
1
4.3.2.1.2.2 Mapping of parameters 2
3
The following tables show the mapping between the parameters in GSM MAP messages and 4 parameters in the corresponding ANSI-41 messages. The relationships between the 5 parameters shown in the tables are meant to be bi-directional. 6
Table 59: Register SS Request ↔↔↔↔ FEATREQ parameter mapping 7
REGISTER SS REQUEST Status FEATREQ Status
SS-Code M
Forwarded-to number with subaddress
C
Digits (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
8
9
10
N.S0028
74
Table 60: Register SS Response ↔↔↔↔ Feature Request Return Result Parameter Mapping 1
Register SS Response Status Feature Request Return Result Status
EMLPP default priority C -
Forwarding information C -
FeatureResult (Note 1) M
User Error C Announcement List O
Provider 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 is 3 received in the REGISTER SS RESPONSE, or the User Error shall be mapped to an 4 appropriate value if an Unsuccessful value is received in Feature Result. See Table 68. 5
6
7
8
N.S0028
75
Table 61: Register SS Response ↔↔↔↔ Return Error Parameter Mapping 1
Register SS Response Status Return Error Status
EMLPP default priority C
Forwarding information C
User Error C
Provider Error O
Error Code O
- Faulty Parameter O
2
. 3
4
5
N.S0028
76
1
4.3.2.1.2.2.1 Mapping of parameter values in GSM Foreign Mode 2 3
Register SS Request to Feature Request Invoke mapping 4
5
Table 62 represents how the IIF shall map the value of the parameter it has received to 6 populate the fields of the message it shall transmit. 7
Table 62: Register SS Request to Feature Request Invoke parameter mapping 8
Register SS Request Status FEATREQ Status
SS-Code/
Forwarded-to number with subaddress
M
C
Digits (Dialed)
This parameter is made up of digits that make up a feature code, plus a forwarded-to number. The IIF shall obtain the feature code from a table mapping GSM supplementary service operations (e.g. CFB registration) to ANSI-41 feature codes. The forwarded-to number component is obtained from the "Forwarded-to number with subadress" parameter. Note that any included subaddress in that parameter is ignored.
M
9
Note that no parameter in the FeatureRequest INVOKE message currently supports the 10 mapping from the GSM MAP parameter "Basic service". The "GSM Foreign Mode" of 11
4.3.2 SS Registration and Erasure contains procedures pertaining to the handling of the "Basic 12 service" parameter, when included in the received GSM MAP message. 13
14
N.S0028
77
1
Default parameter values 2
3
Table 63 presents how the IIF shall populate the parameters of the Feature Request Invoke 4 message to be sent to the ANSI-41 HLR. These fields cannot be mapped from the received 5 Register SS request message. 6
Table 63: FEATREQ default parameter 7
8 FEATREQ Status Default Value
ElectronicSerialNumber M Shall be derived from IMSI previously obtained from GSM MAP_OPEN information.
MSID (Either MIN or IMSI) M Shall be obtained from mapping from the IMSI previously obtained from GSM MAP_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 same unique ID used during registration to identify serving MSC.
MSCIdentificationNumber O May be included from IIF data. Set to the Serving 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.
9
10
Feature Request Return Result to Register SS Response mapping 11
12
Mapping of parameter values 13
14
For the successful case (in which a FeatureRequest Return Result is received with the 15 FeatureResult parameter set to “successful”) there are no meaningful parameter mappings to 16
N.S0028
78
support. For those successful cases, the “Default parameter values” describes how the 1 corresponding GSM Register SS Response message shall be populated. For the unsuccessful 2 cases, refer to 4.3.2.2.3 Error Handling. 3
4
Default parameter values 5
6
Table 64 describes the population of the parameters in the Register SS Response message for 7 successful registration cases (i.e. when the received Feature Request Return Result contains a 8 FeatureResult parameter set to “successful”). 9
10
Table 64: Register SS Response default parameter values 11
Register SS Response Status Default Value
Call forwarding information C The forwarded-to number of the "Forwarding feature" parameter within the "Call forwarding information" parameter is populated using the registered address. The suggested values for other parameters are as follows:
- SS-Code: The code of the call forwarding supplementary service to which the registration applies.
- Basic Service Group: not included;
- SS-Status: Based on current status of feature;
- forwarded-to subaddress: not included;
- forwarding options: not included;
- no reply condition timer: May be included only for Call Forwarding No Reply cases.
EMLPP default priority C Not applicable. May be ignored when received.
12
13
N.S0028
79
1
4.3.2.1.2.2.2 Mapping of parameter values ANSI-136 41 Foreign Mode 2 3
Feature Request Invoke to Register SS Request mapping 4
5
Table 65 represents how the IIF shall map the value of the parameter it has received to 6 populate the fields of the message it shall transmit. 7
Table 65: FEATREQ to Register SS Request parameter mapping 8
FEATREQ Status Register SS Request Status
Digits (Dialed) M SS-Code
The IIF shall support a table mapping ANSI-41 feature codes to GSM supplementary service operations (e.g. CFB registration)
M
Digits (Dialed) M Forwarded-to number with subaddress
Populated from the forwarded-to number portion of the Digits (Dialed) parameter.
M
9
Default parameter values 10
Table 66 presents how the IIF shall populate the parameters of the Register SS Request 11 message to be sent to the GSM HLR. These fields do not have an equivalent in the received 12 Feature Request Invoke message. 13
Table 66: Register SS Request default parameter 14
Parameter Name Status Value
Basic services C Not required to be included. (Registration operation shall apply to all service groups when absent.)
No reply condition time C Not required to be included.
EMLPP default C Not required to be included.
15
16
N.S0028
80
1
GSM Register SS Response to ANSI-41 Feature Request Return Result mapping 2
3
Mapping of parameter values 4
For the successful case (in which there’s no User error or Provider Error in the received GSM 5 Register SS Response message), there are no meaningful parameter mappings to support. 6 For those successful cases, the “Default parameter values” describes how the corresponding 7 ANSI-41 FeatureRequest Return Result shall be populated. For the unsuccessful cases, refer 8 to 4.3.2.2.3 Error Handling. 9
10
Default parameter values 11
Table 67 presents how the IIF shall populate the parameters of the Feature Request Return 12 Result message to be sent to the ANSI-41 VLR for successful supplementary service 13 registration cases. Note that the population of the message may differ for non-registration 14 cases. 15
Table 67: FeatureRequest Return Result default parameter 16
Parameter Name Status Default Value
FeatureResult 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
18
N.S0028
81
1
Table 67: FeatureRequest Return Result default parameter (concluded) 2
Parameter Name Status Default Value
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.
3
4
N.S0028
82
1
4.3.2.1.3 Error Handling 2
3
The error handling procedures specified for supplementary service activation apply also for the 4 supplementary service registration case, with the following modification: the User Error values 5 "SS subscription violation", "Negative PW Check", and "Number of PW Attempts Violation", 6 although valid for the activation case, are not valid for the registration case. If any of those 7 values are received in the User Error parameter of a Register SS Response, they may be 8 mapped to "System Failure". Also, the IIF may not include any of those User Error values in 9 the Register SS Response messages it sends. 10
Table 68: FeatureRequest Return Result to User Error in the Register SS Response 11 mapping 12
FeatureRequest Return Result User Error in the Register SS Response
FeatureResult ="unsuccessful"
AnnouncementList="UnauthorizedFeatureCode"
User Error = "SS subscription violation"
FeatureResult ="unsuccessful"
AnnouncementList not present
User Error="System Failure"
13
4.3.2.2 Erasure 14
15
4.3.2.2.1 Detailed Procedures 16
17
4.3.2.2.1 contains the procedures in the IIF for the case in which the subscriber requests 18 erasure (de-registration) of information in association with one of the following supplementary 19 services while roaming in foreign mode (i.e., while roaming in a network of a technology 20 different from that of its home network): 21
22
• Call Forwarding Unconditional (in both GSM and ANSI-136 41 foreign modes) 23
• Call Forwarding Busy (in both GSM and ANSI-136 41 foreign modes) 24
• Call Forwarding No Reply (in ANSI-136 41 foreign-mode only) 25
• Call Forwarding Not Reachable (in ANSI-136 41 foreign-mode only) 26
• Call Forwarding No Answer (in GSM foreign-mode only) 27
28
4.3.2.2.1.1 GSM Foreign Mode 29
30
N.S0028
83
While in GSM Foreign Mode, the principal role of the IIF, with respect to supplementary service 1 erasure is that of handling the GSM MAP_ERASE_SS as follows: If the IIF receives an GSM 2 MAP_ERASE_SS message from the GSM serving system, it shall verify the correct format and 3 content of the message as described in GSM 09.02 [3]. 4
5
For cases in which the received message contains a "Basic service" parameter, the IIF shall 6 also verify that the request for erasure applies to (at least) speech. If the received request does 7 not include "speech" as one of the services to which the request applies, the IIF shall respond 8 with either a GSM MAP_ERASE_SS Response message that includes a "User error" 9 parameter with a value of "Illegal SS Operation". Note that cases in which no "Basic service" 10 parameter is included in the received message are acceptable, since, by default, no "Basic 11 service" parameter indicates that the request applies to all services. 12
13
If the format and content of the message is correct, the IIF shall determine the location of the 14 subscriber’s HLR and send to it an ANSI-41 FeatureRequest INVOKE message populated as 15 described in Table 70, Table 73 and Table 74. If a failure occurs at the IIF on reception of the 16 GSM MAP_ERASE_SS message (e.g. missing data), the procedures described in GSM 09.02 17 [3] are applicable to the IIF. 18
19
If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF receives an ANSI-41 20 FeatureRequest Return Result message with a FeatureResult parameter set to successful, the 21 IIF shall send a GSM MAP_ERASE_SS Response message back towards the serving system 22 populated as described in Table 71 and Table 75. 23
24
If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF instead receives an ANSI-41 25 FeatureRequest Return Result message with a FeatureResult parameter set to unsuccessful, 26 the IIF shall send a GSM MAP_ERASE_SS Response message back towards the serving 27 system as described in Table 71 and Table 79. 28
If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF instead receives an ANSI-41 29 FeatureRequest Return Error message, the IIF shall send a GSM MAP_ERASE_SS Response 30 message back towards the serving system as described in 4.3.2.2.3 Error Handling. 31
Note that successful supplementary service erasure cases in GSM foreign mode may result in 32 the subscriber's ANSI-41 HLR sending out an ANSI-41 QUALDIR message to the serving 33 system. For these cases, the IIF would need to map the message to a GSM MAP Insert 34 Subscriber Data message. The mapping of an ANSI-41 QUALDIR message to a GSM MAP 35 Insert Subscriber Data message is covered in the Subscriber Data Management. 36
37
4.3.2.2.1.2 ANSI-136 41 Foreign Mode 38
39
While in ANSI-136 41 Foreign Mode, the principal role of the IIF, with respect to supplementary 40 service erasure, is that of handling the ANSI-41 FeatureRequest INVOKE message, as follows: 41 If the IIF receives an ANSI-41 FeatureRequest INVOKE message from the ANSI-41 serving 42 system, it shall verify the correct format and content of the message as described in ANSI-41 [6]. 43 If format and content of the message is correct, the IIF shall determine the location of the 44 subscriber’s HLR and send a GSM MAP_ERASE_SS Request message populated as described 45 in Table 70 and Table 77. For cases in which the FeatureRequest INVOKE message includes a 46
N.S0028
84
feature code corresponding to Call Forwarding No Answer, and if the IIF is configured to do so, 1 the IIF may send two MAP_ERASE_SS messages, one indicating Call Forwarding No Reply and 2 the other indicating Call Forwarding Not Reachable. These messages may be sent in parallel. 3 The mapping in Table 70,Table 75 and Table 77 would still be applicable. 4
For the cases of failure at the IIF on reception of the ANSI-41 FeatureRequest Return Result 5 message (e.g. parameter error, unrecognized subscriber), the procedures described in ANSI-41 6 [6] are applicable to the IIF. 7
If in response to the a GSM MAP_ERASE_SS Request message, the IIF receives a GSM 8 MAP_ERASE_SS Response message with neither a User Error nor Provider Error parameter, 9 the IIF shall send an ANSI-41 FeatureRequest Return Result message back towards the serving 10 system populated as described in Table 71. For those cases in which two requests had been 11 previously sent by the IIF, the IIF would wait until receiving the responses to both requests 12 before sending the FeatureRequest Return Result message. For cases in which both responses 13 indicate success, the mapping in Table 71 may be applied to either of the responses (as an IIF 14 implementation option). For cases in which one of the responses indicates success and the 15 other failure, the mapping in Table 71, Table 75 and Table 86 applies to the successful 16 response. 17
If, in response to the GSM MAP_ERASE_SS Request message, the IIF instead receives a 18 GSM MAP_ERASE_SS Response message with a User Error, the IIF shall send either an 19 ANSI-41 FeatureRequest Return Result or a Return Error as described in 4.3.2.2.3 Error 20 Handling If a Provider Error parameter is included in the received GSM MAP_ERASE_SS 21 Response message, the IIF shall send an ANSI-41 FeatureRequest Return Error message 22 populated with an Error Code. For cases in which two requests had been previously sent by the 23 IIF, and both responses indicate failure, the procedures described in 4.3.2.2.3 Error Handling 24 may be applied to either of the responses (as an IIF implementation option). 25
26
Note that successful supplementary service erasure cases in ANSI-136 41 foreign mode may 27 result in the subscriber's GSM HLR sending out a GSM MAP Insert Subscriber Data message 28 to the serving system. For these cases, the IIF would need to map the message to an ANSI-41 29 QUALDIR message. The mapping of GSM MAP Insert Subscriber Data message to an ANSI-30 41 QUALDIR message is covered in the Subscriber Data Management. 31
32
4.3.2.2.2 Mapping of Messages, Parameters & Parameter Values 33
34
4.3.2.2.2 presents the mapping of messages, parameters and parameter values that the IIF 35 shall perform. 36
37
4.3.2.2.2.1 Mapping of Messages 38
39
40
N.S0028
85
1
Table 69 shows the mapping of messages for Supplementary Service Erasure. 2
Table 69: Supplementary Service Erasure Message Mapping 3
GSM MAP Message ANSI-41 MAP Message
ERASE SS REQUEST FEATREQ
ERASE SS REQUEST RESPONSE featreq
4
4.3.2.2.2.2 Mapping of parameters 5
6
The following tables show the mapping between the parameters in GSM MAP messages and 7 parameters in the corresponding ANSI-41 messages. The relationships between the 8 parameters shown in the tables are meant to be bi-directional. 9
Table 70: Erase SS Request ↔↔↔↔ FEATREQ parameter mapping 10
Erase SS Request Status FEATREQ Status
SS-Code M Digits (Dialed) M
Basic 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
11
12
13
N.S0028
86
Table 71: Erase SS Response ↔↔↔↔ Feature Request Return Result parameter mapping 1
Erase SS Response Status Feature Request Return Result Status
Forwarding information C -
- FeatureResult (Note1) M
User Error C Announcement List O
Provider 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 is 3 received in the ERASE SS RESPONSE 4
5
6
N.S0028
87
1
Table 72: Erase SS Response ↔↔↔↔ Return Error parameter mapping 2
Erase SS Response Status Return Error Status
Call forwarding information C -
User Error C
Provider Error O
Error Code O
- Faulty Parameter O
3
4
5
6
N.S0028
88
1
4.3.2.2.2.2.1 Mapping of parameter values in GSM Foreign Mode 2 3
Erase SS Request to Feature Request Invoke mapping 4
5
Table 73 represents how the IIF shall map the value of the parameter it has received to 6 populate the fields of the message it shall transmit. 7
Table 73: Erase SS Request to FEATREQ parameter mapping 8
Erase SS Request Status FEATREQ Status
SS-Code M Digits (Dialed)
This parameter shall be made up of digits that make up the feature code string that corresponds to erasure (de-registration) of the information that pertains to the supplementary service specified in the SS-Code parameter. The IIF shall obtain the feature code from a table mapping GSM supplementary service operations (e.g. CFB erasure) to ANSI-41 feature codes.
M
9
Note that no parameter in the FeatureRequest INVOKE message currently supports the 10 mapping from the GSM MAP parameter "Basic service". The "GSM Foreign Mode" part of 11
4.3.2 SS Registration and Erasure contains procedures pertaining to the handling of the "Basic 12 service" parameter, when included in the received GSM MAP message. 13
14
N.S0028
89
1
Default parameter values 2
3
Table 74 presents how the IIF shall populate the parameters of the Feature Request Invoke 4 message to be sent to the ANSI-41 VLR. These fields cannot be mapped from the received 5 Erase SS request message. 6
Table 74: Feature Request Invoke default parameter 7
FEATREQ Status Default Value
ElectronicSerialNumber 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_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 same unique ID used during registration to identify 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.
8
9
N.S0028
90
1
Feature Request Return Result to Erase SS Response mapping 2
3
Mapping of parameter values 4
5
For the successful case (in which a FeatureRequest Return Result is received with the 6 FeatureResult parameter set to “successful”) there are no meaningful parameter mappings to 7 support. For those successful cases, the “Default parameter values” describes how the 8 corresponding GSM Erase SS Response message shall be populated. For the unsuccessful 9 cases, refer to 4.3.2.2.3 Error Handling 10
11
Default parameter values 12
13
Table 75 describes the population of the parameters in the Erase SS Response message for 14 successful erasure cases (i.e. when the received Feature Request Return Result contains a 15 FeatureResult parameter set to “successful”). 16
Table 75: Erase SS Response default parameter values 17
Erase SS Response Status Default Value
Call forwarding information
C The suggested values for the fields in this parameter are as follows:
- SS-Code: The code of the call forwarding supplementary service to which the registration applies.
- 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 for Call Forwarding No Reply cases.
18
19
N.S0028
91
1
4.3.2.2.2.2.2 Mapping of parameter values in ANSI-136 41 Foreign Mode 2 3
Feature Request Invoke to Erase SS Request mapping 4
5
Table 76 represents how the IIF shall map the value of the parameter it has received to 6 populate the fields of the message it shall transmit. 7
Table 76: FEATREQ to Erase SS Request parameter mapping 8
FEATREQ Status Erase SS Request Status
Digits (Dialed) M SS-Code
The IIF shall support a table mapping ANSI-41 feature codes to GSM supplementary service operations (e.g. CFB erasure)
M
9
10
Default parameter values 11
12
This table presents how the IIF shall populate the parameters of the Erase SS Request 13 message to be sent to the GSM HLR. These fields do not have an equivalent in the received 14 Feature Request Invoke message. 15
Table 77: Erase SS Request default parameter 16
Parameter Name Status Value
Basic services C Not required to be included. (Registration operation shall apply to all service groups when absent.)
17
18
N.S0028
92
1
GSM Erase SS Response to ANSI-41 Feature Request Return Result mapping 2
3
Mapping of parameter values 4
5
For the successful case (in which there is no User error or Provider Error present in the 6 received GSM Erase SS Response message), there are no meaningful parameter mappings to 7 support. For those successful cases, the “Default parameter values” describes how the 8 corresponding ANSI-41 FeatureRequest Return Result shall be populated. For the 9 unsuccessful cases, refer to 4.3.2.2.3 Error Handling. 10
11
Default parameter values 12
13
This table presents how the IIF shall populate the parameters of the Feature Request Return 14 Result message to be sent to the ANSI-41 HLR for successful erasure cases. Note that the 15 population of the message may differ for non-erasure cases. 16
17
Table 78: FeatureRequest Return Result default parameter 18
Parameter Name Status Default Value
FeatureResult 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.
19
20
N.S0028
93
1
Table 78: FeatureRequest Return Result default parameter (concluded) 2
Parameter Name Status Default Value
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.
3
4.3.2.2.3 Error Handling 4
5
The error handling procedures specified for supplementary service activation apply also for the 6 supplementary service erasure case, with the following modification: the User Error values "SS 7 subscription violation", "SS incompatibility", "Negative PW Check", and "Number of PW 8 Attempts Violation", although valid for the activation case, are not valid for the erasure case. If 9 any of those values are received in the User Error parameter of a Register SS Response, they 10 may be mapped to "System Failure". Also, the IIF may not include any of those User Error 11 values in the Erase SS Response messages it sends. 12
13
Table 79: FeatureRequest Return Result to Register SS Response User Error 14
FeatureRequest Return Result User Error in the Erase SS Response
FeatureResult ="unsuccessful"
AnnouncementList="UnauthorizedFeatureCode"
User Error = "SS subscription violation"
FeatureResult ="unsuccessful"
AnnouncementList not present
User Error="System Failure"
15
16
17
N.S0028
94
1
4.3.3 Retrieval of Forward-To Number 2
3
4.3.3.1 Detailed Procedures 4
5
The following procedures are applicable at the IIF for retrieval of forwarded-to-number, in GSM 6 foreign mode. These procedures are applicable for Call Forwarding Busy (CFB) and Call 7 Forwarding No Answer (CFNA), which will be referred to as Conditional Call Forwarding. 8
In GSM, the HLR provides the forwarded-to-number(s) to the serving MSC/VLR as part of the 9 profile update procedure, in the MAP_Insert_Subscriber_Data message (or, as part of the 10 response to a MAP_Interrogate_SS request). The ANSI-41 HLR, however, only provides this 11 information when the Call Forwarding feature is actually invoked. Therefore, in GSM foreign 12 mode, in order to the able to include the forwarded-to-number(s) in the 13 MAP_Insert_Subscriber_Data message to the serving system during profile updates, the IIF 14 has to, beforehand, explicitly request the ANSI-41 HLR for the forwarded-to-number(s). The IIF 15 makes this request to the ANSI-41 HLR via the TransferToNumberRequest Invoke message. 16 (Note that two separate TRANUMREQ messages may be needed: one for CFB and another for 17 CFNA. The two requests may be sent in parallel by the IIF). The IIF shall then store the 18 received forwarded-to numbers for subsequent use. 19
Specifically, before a MAP_Insert_Subscriber_Data message is sent by the IIF, the IIF shall 20 determine if it needs to query the ANSI-41 HLR for the CFB or CFNA forwarded-to number(s). 21
In general, the IIF needs to query the ANSI-41 HLR at least for the case in which the 22 CFB/CFNA feature is authorized and active for the subscriber, and the profile update procedure 23 is being performed immediately after an initial successful location update of the subscriber in 24 GSM foreign mode1. Other cases for initiating the query may be supported by the IIF as 25 follows: 26
a) After a recent successful forwarded-to number registration pertaining to either the CFB or 27 CFNA feature. 28
(Note, however, that a query after a forwarded-to number registration may not be 29 necessary if the IIF saves the forwarded-to number while processing the registration 30 messages.) 31
After a successful location update when either the CFB or CFNA feature is authorized, but not 32 necessarily active. 33
(This case differs from the mandatory case in that the CFB/CFNA feature need not be 34 active in order to initiate the query. Supporting this case would make it unnecessary for 35 the query to be performed after an activation of the CFB/CFNA feature) 36
b) After a recent successful activation of either the CFB or CFNA feature. 37
(Note that this case would only be needed if the IIF had not queried the ANSI-41 HLR 38 previously. In particular if the IIF, during the initial location update, does not perform the 39 query because the CFB/CFNA feature is not active.) 40
c) On a regular basis (e.g. timer-based) 41
1 Note that this refers only to the successful location update case. There's no need for the IIF to perform this procedure for unsuccessful cases.
N.S0028
95
(Supporting this case would be useful for accounting for the possibility of a network 1 administrator-initiated change of the forwarded-to DN(s)). 2
The IIF shall populate the TransferToNumberRequest Invoke message in a manner compliant 3 with ANSI-41 [6]. The IIF shall then send the TransferToNumberRequest Invoke message to 4 the 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 been 6 successful, the IIF shall map the forwarded-to-number information (along with any other 7 subscriber profile information received in either the QualificationDirective Invoke or 8 RegistrationNotification RETURN RESULT) into a MAP_Insert_Subscriber_Data Request 9 message. As shown in Table 81 and Table 82, the Forwarded-to-Number field of the 10 TransferToNumberRequest RETURN RESULT shall be mapped from the Digits (Destination) 11 field in the MAP_Insert_Subscriber_Data message. In addition, if the registration deals with Call 12 Forwarding No Answer, the No Reply Condition Time parameter in the 13 MAP_Insert_Subscriber_Data message should be populated with the content of the 14 NoAnswerTime field in the TransferToNumberRequest RETURN RESULT message. 15
In case of a failure, the IIF may receive either a TransferToNumberRequest RETURN RESULT 16 with the field AccessDeniedReason present, or a Return Error or Reject message with an Error 17 Code value. For those cases in which a failure occurs, the IIF shall continue to use a 18 previously obtained forwarded-to number, if available. If no previously obtained forwarded-to 19 number is available at the IIF, the IIF shall not populate the corresponding information (i.e., the 20 Forwarded-to-Number field within the Forwarding Information List parameter) in the 21 MAP_Insert_Subscriber_Data Request message. 22
4.3.3.2 Mapping of Messages, Parameters & Parameter Values 23
24
Note: the mapping of the QualificationDirective Invoke message to the 25 MAP_Insert_Subscriber_Data Request message is described in details in 4.4 O&M 26 Procedures. Therefore, 4.3.3.2 focuses on the mapping of TransferToNumberRequest return 27 result to the relevant MAP_Insert_Subscriber_Data field. Not all Insert Subscriber Data fields 28 are shown in the following tables. 29
4.3.3.2.1 Mapping of Messages 30
31
The following table shows the mapping of messages for Retrieval of Forward-to-Number in 32 GSM Foreign Mode. 33
Table 80: Retrieval of Forward-to-Number in GSM Foreign Mode 34
ANSI MAP MESSAGE GSM MAP MESSAGE
Transfer to Number Request Return Result INSERT SUBSCRIBER DATA
35
36
N.S0028
96
1
4.3.3.2.2 Mapping of parameters 2
3
The following tables are only for GSM Foreign Mode. 4
5
Table 81: TransferToNumberRequest Return Result to Insert Subscriber Data parameter 6 mapping 7
TransferToNumberRequest Return Result
Status Insert Subscriber Data Status
Digits (Destination)
or TerminationList (see Note 1)
M
O
Forwarded-to-Number (within Forwarding 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 (Set to 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 TeleService
O
8
Note 1: When TerminationList parameter is present, the Digits (Destination) parameter is 9 ignored. 10
-Note 2: Optional, if the network settings support data, a mapping may be performed as 11 described in Table 92 12
13
N.S0028
97
1
TransferToNumberRequest Return Result to Insert Subscriber Data Request 2
3
Mapping of parameters value 4
Table 82 represents how the IIF shall map the value of the parameter it has received to 5 populate the fields of the message it shall transmit. 6
7
Table 82: TransferToNumberRequest Return Result to Insert Subscriber Data Request 8 value mapping 9
TransferToNumberRequest Return Result
Status Insert Subscriber Data Request Status
Digits (Destination) or
DestinationDigits parameter within TerminationList (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 or GSM TeleService
O
10
11
Note 1: When TerminationList parameter is present, the Digits (Destination) parameter of the 12 TransferToNumberRequest RETURN RESULT is ignored. 13
Note 2: There may be up to three forwarded-to number parameters with the Insert Subscriber 14 Data Request message mapped from TransferToNumberRequest information: one for Call 15 Forwarding Busy, one for Call Forwarding No Reply (mapped from CFNA results), and another 16 for Call Forwarding Not Reachable (also mapped from CFNA results). 17
Note 3: Optional, if the network settings support data, a mapping may be performed as 18 described in Table 92. 19
20
Default parameter value 21
22
The other parameters in the TransferToNumberRequest Return Result message are not 23 mapped to any of the Insert Subscriber Data Request parameters. 24
25
N.S0028
98
1
4.3.3.3 Error Handling 2
3
No mapping between ANSI-41 and GSM MAP messages is required for cases in which the 4 forwarded-to number retrieval operation fails. Refer to 4.3.3.1 Detailed Procedures for a 5 description of the IIF procedures when the forwarded-to number retrieval operation fails. 6
7
4.3.4 Calling Number / Line Identification Presentation/Restriction 8
9
The calling number/line identification Presentation/Restriction procedure is used to determine 10 whether the calling party number should be presented to the called party. 11
12
4.3.4.1 Handling of calling number/ line identification presentation 13
14
4.3.4.1.1 Detailed Procedures 15
16
If CNIP / CLIP service is authorized and active, the calling party number is available and 17 presentation is allowed, the called party’s serving network shall provide the calling party 18 number to the called party during call alerting. 19
If the IIF receives a GSM MAP _PROVIDE_ROAMING_Request with the Calling Party Number 20 in the Additional Signal Info field correctly populated, the IIF shall send an 21 ANSI_MAP_ROUTEREQ to the serving MSC/VLR with the Calling Party Number field correctly 22 mapped. 23
If the IIF receives an ANSI_MAP_ROUTREQ with the Calling Party Number field in the 24 Additional Signal Info field correctlty populated, the IIF shall send a GSM MAP 25 _PROVIDE_ROAMING_NUMBER_Request to the serving MSC/VLR with the Calling Party 26 Number field correctly mapped. 27
28
4.3.4.1.2 Mapping of Messages, Parameters & Parameter Values 29
30
4.3.4.1.2.1 Mapping of Messages 31
32
The mapping of messages is in accordance with 4.2.1, with the exception that GSM 09.02 [3] is 33 supported. 34
35
N.S0028
99
1
4.3.4.1.2.2 Mapping of Parameters 2
3
The following tables show the mapping of parameters specific to handling calling number/line 4 presentation/restrcition, which the IIF shall perform regardless of the mode of operation (GSM 5 Foreign Mode or ANSI-136 41 Foreign Mode). The mapping of other parameters not specific to 6 handling calling number/line presentation/restriction can be found in 4.2.1, with the exception 7 that GSM 09.02 [3] is supported. 8
9
Note: The tables are constructed in such a way that the parameter names appear first and any 10 information contained within those parameters are shown as indented text. 11
12
Table 83: Routing Request ↔↔↔↔ Provide Roaming Number Request (Network Provided 13 number) Parmater Mapping 14
Routing Request Status Provide Roaming Number Status
CallingPartyNumberString1 (Network Provided No):-
Type Of Digits:- Calling Party Number
Nature of Number:- National, Presentation Allowed, Network Provided
Numbering Plan:- Telephony Numbering
Encoding:- IA5
Characters:- Digits
O
AdditionalSignalInfo:-
CallingPartyNumber:-
-
Screening Indicator: Network Provided
Presentation Indicator: Presentation Allowed
-
-
Line Identity: E164 address of Calling Party
C
15
16
N.S0028
100
1
Table 84: Routing Request ↔↔↔↔ Provide Roaming Number Request (User Provided 2 number) Parameter Mapping 3
Route Request Status Provide Roaming Number Status
CallingPartyNumberString2 (User Provided No):-
Type Of Digits:- Calling Party Number
Nature of Number:- National,Presentation Allowed,
User Provided, not screened
Numbering Plan:- Telephony Numbering
Encoding:- IA5
Characters:- Digits
O
AddititonalSignalInfo:-
CallingPartyNumber:-
-
Screening Indicator: User Provided, not screened
Presentation Indicator: Presentation Allowed
-
-
Line Identity: E164 address of Calling Party
C
4
5
6
N.S0028
101
Table 85: Routing Request ↔↔↔↔ Provide Roaming Number Request (Two calling party 1 numbers) Parameter Mapping 2
Route Request Status Provide Roaming Number Status
CallingPartyNumberString1 (Network Provided No):-
Type Of Digits:- Calling Party Number
Nature of Number:- National, Presentation Allowed,
Network Provided
Numbering Plan:- Telephony Numbering
Encoding:-IA5
Characters:- Digits
O
AdditionalSignalInfo:-
CallingPartyNumber:-
-
Screening Indicator: Network Provided
Presentation Indicator: Presentation Allowed
-
-
Line Identity: E164 address of Calling Party
C
CallingPartyNumberString2 (User Provided No):-
Type Of Digits:- Calling Party Number
Nature of Number:- National, Presentation Allowed
User Provided
Numbering Plan:- Telephony Numbering
Encoding:- IA5
Characters:- Digits
O
Generic Number:-
-
Screening Indicator: User Provided, not screened
-
-
Line Identity: E164 address of Calling Party
3
N.S0028
102
4.3.4.2 Handling of calling number/ line identification restriction 1
2
4.3.4.2.1 Detailed Procedures 3
4
If the calling subscriber has calling number/line identification restriction authorized and active 5 and it is impossible to indicate to the terminating network (due to interworking) that the number 6 shall not be presented to the terminating party, the calling number/line identity shall not be 7 delivered to the terminating network. 8
If CNIR / CLIR service is authorized and active, the calling party number is available and 9 presentation is restricted, the called party’s serving network shall not present the calling party 10 number to the called party during call alerting. An indication that the calling party number is 11 restricted shall be delivered to the called party. 12
13
4.3.4.2.2 Mapping of Messages, Parameters and Parameter Values 14
15
4.3.4.2.2.1 Mapping of Messages 16
17
Messages for Calling number/line identification restriction is the same as 4.3.4.1. 18
19
4.3.4.2.2.2 Mapping of Parameters 20
21
The following table shows the mapping of parameters for calling name/line restriction, which the 22 IIF shall perform regardless of the mode of operation (ANSI-41 Foreign Mode or GSM Foreign 23 mode). 24
25
N.S0028
103
1
Table 86: Routing Request ↔↔↔↔ Provide Roaming Number Request(Caller Id Restricted) 2 Parameter Mapping 3
Routing Request Status Provide Roaming Number Status
CallingPartyNumberString1 (Network Provided No):-
Type Of Digits:- Calling Party Number
Nature of Number:- National, Presentation Restricted,
Network Provided
Numbering Plan:- Telephony Numbering
Encoding:- IA5
Characters:-Digits
O
AdditionallSignalInfo:-
CallingPartyNumber:-
-
Screening Indicator: Network Provided,
Presentation Indicator: Presentation Restrcited
-
-
Line Identity: E164 address of Calling Party
C
4
5
N.S0028
104
1
4.3.4.3 Error Handling 2
3
For the cases of failure at the IIF on reception of an ANSI_ MAP_RoutingRequest return Result, 4 the procedures described in ANSI-41 [6] for automatic call delivery is applicable to the IIF. 5
For the cases of failure at the IIF on resception of a GSM MAP 6 _PROVIDE_ROAMING_NUMBER_Response, the procedures described in GSM 09.02 [3] are 7 applicable to the IIF. 8
9
If the IIF receives a GSM MAP _PROVIDE_ROAMING_NUMBER_Request indicating an error 10 code, the IIF shall map that error code it receives to a suitable error in the ANSI_MAP_routereq 11 as described in 4.2.1 12
13
If the IIF receives an ANSI_MAP_routreq indicating an error code, the IIF shall map that error 14 code it receives to a suitable error in the GSM MAP 15 _PROVIDE_ROAMING_NUMBER_Response as described in 4.2.1. 16
17
18
N.S0028
105
1
4.4 O&M Procedures 2
3
Existing operation and maintenance procedures described in either GSM 09.02 [3] or ANSI-41 4 [6] are also directly applicable to the IIF when it is emulating a GSM or ANSI-41 functional 5 network element. Enhancements/modifications to ANSI-41 [7], 0 are also applicable. 6
7
4.4.1 Detailed Procedures 8
9
Subscriber data management procedures are used to either delete or modify, subscriber data 10 held in the network. These procedures are initiated by the OMC. 11
12
Subscriber data management procedures also cover ANSI-41 specific procedures, describing 13 the retrieval of subscriber data from network elements. 14
15
The IIF contains both permanent subscriber data (can only be changed by administration 16 means) and temporary subscriber data (may be changed as a result of normal operation of the 17 system) relating to the roaming subscriber. 18
19
4.4.1.1 Subscriber Deletion Procedure 20
21
If the IIF receives a GSM MAP _CANCEL_LOCATION_REQUEST, it shall follow the location 22 cancellation procedures outlined in this document for Location Registration (see 4.1.1). 23
If the IIF receives an ANSI_MAP_REGCANC, it shall follow the location cancellation 24 procedures outlined in this document for Location Registration (see 4.1.1). 25
26
4.4.1.2 Subscriber Data Modification Procedure (ANSI-136 41 Foreign Mode) 27
28
If the IIF receives either a GSM MAP _INSERT_SUBSCRIBER_DATA_REQUEST, or a GSM 29 MAP _DELETE_SUBSCRIBER_DATA_REQUEST, it shall follow the VLR procedures 30 described in GSM 09.02 [3]. 31
As part of the subscriber data modification procedure, the IIF may send an 32 ANSI_MAP_QUALDIR to the serving ANSI-41 VLR and await a response. 33
If the response indicates success, the IIF shall modify the corresponding subscriber data and 34 send a GSM MAP _INSERT_SUBSCRIBER_DATA_RESPONSE to the GSM HLR. 35
36
N.S0028
106
If the response indicates failure, the received subscriber data is stored by IIF even if there is a 1 failure reported from the visited (foreign mode) system and the IIF shall send the reason for 2 failure in a GSM MAP _INSERT_SUBSCRIBER_DATA_RESPONSE to the GSM HLR. 3
4
4.4.1.3 Subscriber Data Modification Procedure (GSM Foreign Mode) 5
6
If the IIF receives an ANSI_MAP_QUALDIR, it shall follow the VLR procedures described in 7 ANSI-41 [6]. 8
As part of the subscriber data modification procedure, the IIF may send either a GSM MAP 9 _INSERT_SUBSCRIBER_DATA_REQUEST or a GSM MAP 10 _DELETE_SUBSCRIBER_DATA_REQUEST to the serving GSM VLR and await a response. 11
If the response indicates success, the IIF shall modify the corresponding subscriber data and 12 send an ANSI_MAP_qualdir to the ANSI-41 HLR. 13
If the response indicates failure, the received subscriber data is stored by IIF even if there is a 14 failure reported from the visited (foreign mode) system and the IIF shall send the reason for 15 failure in the ANSI_MAP_qualdir to the ANSI-41 HLR. 16
4.4.1.4 Subscriber Data Retrieval 17
18
If the IIF receives an ANSI_MAP_QUALREQ, it shall follow the ANSI-41 HLR procedures 19 described in ANSI-41 [6]. The IIF is not required to retrieve subscriber data from the GSM 20 HLR. 21
22
4.4.2 Mapping of Messages, Parameters & Parameter Values 23
24
The IIF shall perform the translation of messages, parameters and parameter values related to 25 subscriber data management in accordance with the tables presented. 26
27
4.4.2.1 Mapping of Messages 28
29
Table 87 shows the mapping between GSM MAP messages and ANSI-41 MAP messages 30 related to Subscriber Deletion. Table 88 and Table 89, show the mapping between GSM MAP 31 messages and ANSI-41 MAP messages related to Subscriber Data Modification. 32
33
N.S0028
107
1
Table 87: Cancel_Location_Request ↔↔↔↔ REGCAN (Subscriber Deletion) Mapping 2
GSM MAP Messages ANSI MAP Messages
CANCEL_LOCATION_REQUEST REGCANC
CANCEL_LOCATION_RESPONSE (Note 1) regcanc return result
CANCEL_LOCATION_RESPONSE (Note 2) regcanc Return Error
3
Note 1: In the successful case, the CANCEL_LOCATION_RESPONSE is an empty result i.e. 4 contains no parameters other than the invoke Id. 5
Note 2: This message can also contain error values if the subscriber deletion procedure is 6 unsuccessful. If the subscriber deletion procedure fails, the mapping is as shown. See 4.4.3 7 Error Handling for more information. 8
9
Table 88: Mapping of GSM MAP Messages ↔↔↔↔ ANSI MAP Messages (Subscriber Data 10 Modification) 11
GSM MAP Messages ANSI MAP Messages
INSERT_SUBSCRIBER_DATA_REQUEST QUALDIR
INSERT_SUBSCRIBER_DATA_RESPONSE qualdir (Note 2)
INSERT_SUBSCRIBER_DATA_RESPONSE
(Note 1) qualdir Return Error
12
Table 89: Delete_Subscriber_Data ↔↔↔↔ Qualdir Mapping (Subscriber Data Modification) 13
GSM MAP Messages ANSI MAP Messages
DELETE_SUBSCRIBER_DATA_REQUEST QUALDIR
DELETE_SUBSCRIBER_DATA_RESPONSE qualdir Return Result (Note 2)
DELETE_SUBSCRIBER_DATA_RESPONSE
(Note 1) qualdir Return Error
14
Note 1: These messages can also contain error values if the subscriber data modification 15 procedure is unsuccessful. If the subscriber data modification procedure fails, the mapping is 16 as shown. See 4.4.3 Error Hanlding for more information. 17
Note 2: The qualdir Return Result is an empty response i.e. contains no parameters other than 18 the Invoke Id. 19
20
N.S0028
108
1
4.4.2.2 Mapping of Parameters 2
3
The following tables show the mapping of parameters, which the IIF shall perform regardless of 4 the mode of operation (GSM Foreign Mode or ANSI-41 Foreign Mode). 5
Table 90: CANCEL_LOCATION_REQUEST ↔↔↔↔ REGCANC Parameter Mapping 6
CANCEL_LOCATION_REQUEST Status REGCANC Status
IMSI M MSID M
LMSI C -
Cancellation Type C Cancellation Type O
ControlChannelData O
ReceivedSignalQuality O
SenderIdentifcationNumber O
SystemAccessData O
7
Note 1: Cancellation Type is only used between the HLR and the SGSN for GPRS procedures. 8 Cancellation Type is not applicable between HLR and VLR. 9
Table 91: INSERT_SUBSCRIBER_DATA_REQUEST ↔↔↔↔ QUALDIR Parameter Mapping 10
INSERT_SUBSCRIBER_DATA_REQUEST
Status QUALDIR Status
ElectronicSerialNumber M IMSI C
MSID M
QualificationInformationCode M
SystemMyTypeCode (HLR or VLR)
M
AuthorizationDenied O
AuthorizationPeriod O
DeniedAuthorizationPeriod O
Digits (Carrier) O
Digits (Destination) O
LocationAreaID O
Profile “Macro”1 O
- SenderIdentificationNumber O
11
1This parameter is itself a macro containing a number of other parameters. As far as mapping 12 of parameters is concerned, the IIF shall map the contents of the ‘Profile’ macro in the ANSI-41-13 D ‘QUALDIR Invoke’ to the contents of the GSM MAP 14 _INSERT_SUBSCRIBER_DATA_REQUEST as shown in Table 92. 15
16
N.S0028
109
1
Table 92: INSERT_SUBSCRIBER_DATA_REQUEST ↔↔↔↔ profile ‘macro’ Mapping 2
INSERT_SUBSCRIBER_DATA_REQUEST
Status ‘profile’ macro Status
- AuthenticationCapability
O
MSISDN C MobileDirectoryNumber O
Category C -
Subscriber Status C -
Bearer service List C -
Teleservice List C
Forwarding information List C CallingFeaturesIndicator1 O
- CarrierDigits O
- DMH_AccountCodeDigits O
- DMH_AlternateBillingDigits O
- DMH_BillingDigits O
Regional Subscription Data C -
- GeographicAuthorization O
- MessageWaitingNotificationCount O
- MessageWaitingNotificationType O
Call barring information List3 C OriginationIndicator2 O
VLR CAMEL Subscription Info4 C OriginationTriggers4 O
- PACAIndicator O
CUG information List C -
SS-Data List C6 CallingFeaturesIndicator1 O
EMLPP Subscription Data C -
Operator Determined Barring General data
C OriginationIndicator2 O
Operator Determined Barring HPLMN data5
C OriginationIndicator2 O
Operator Determined Barring HPLMN data5
C RestrictionDigits O
Roaming Restriction Due To Unsupported Feature
C -
- RoutingDigits O
Call barring information List3 C SMS_OriginationRestrictions7 O
Call barring information List3 C SMS_TerminationRestrictions8 O
- SPINIPIN O
- SPINITriggers O
3
4
N.S0028
110
1
Table 92: INSERT_SUBSCRIBER_DATA_REQUEST ↔↔↔↔ profile ‘macro’ Mapping 2 (concluded) 3
INSERT_SUBSCRIBER_DATA_REQUEST
Status ‘profile’ macro Status
Call barring information List3 C TerminationRestrictionCode O
VLR CAMEL Subscription Info C TerminationTriggers4 O
Voice Broadcast Data C
Voice Group Call Data C -
- PreferredLanguageIndicator O
SS-Data List6 SMS_OriginationRestrictions7 O
SS-Data List6
SMS_TerminationRestrictions8 O
-GSM BearerServiceCode or GSM TeleService
O CDMAServiceOptionList9 O
4 1The CallingFeaturesIndicator parameter provides a status of several ANSI supplementary 5 services. This information may map into one or more GSM MAP parameters as shown in Table 6 92. 7 2The OriginationIndicator parameter defines the type of calls that a MS is allowed to make. 8 This information may map into one or more GSM MAP parameters as shown in Table 92. 9
3The Call barring information List is a list of the call barring supplementary services that are 10 either active, quiescent or not active for individual or all teleservices. This information may map 11 into one or more ANSI MAP parameters as shown in Table 92. 12
4 If this information is received by the IIF it does have to be mapped. 13 5Operator Determined Barring HPLMN data may map into one or more ANSI MAP parameters 14 as shown in Table 92. 15
6The SS-Data List may map into one or more ANSI MAP parameters as shown in Table 92. 16
7The SMS_OriginationRestrictions may map into one or more GSM MAP parameters as shown 17 in Table 92. 18 8The SMS_TerminationRestrictions may map into one or more ANSI MAP parameters as 19 shown in Table 92. 20
9The CDMAServiceOptionList may map into one or more GSM MAP parameters (e.g.: 21 ADS (9.6kbps) to “CDA-9600 bps” BearerServiceCode; 22 G3FAX to “FacsimileGroup3” GSMTeleService; 23 Packet Data Service (PDS) to “dataPDS” BearerServiceCode). 24
25
Parameter Value Mapping 26
Table 93 through Table 104 shows the mapping of parameter values (more commonly referred 27 to as ASN.1 data types in GSM09.02 [3] which the IIF shall perform based on the parameter 28 mapping shown in Table 92. If there is no direct mapping for parameter values, a ‘-‘ has been 29 entered in the corresponding table. The implication therefore, is that those services/features 30
N.S0028
111
and/or subscription options may not be available when roaming in either a GSM or ANSI-41 1 PLMN. 2
3
The ASN.1 data type encoding is specified in GSM09.02 [3]. 4
5
N.S0028
112
Table 93: Forwarding Information List to Calling Features Indicator Parameter Mapping 1
GSM_Forwarding Information List ANSI-41_Calling Features Indicator
SSCode
AllForwardingSS
CFU
AllConditionalForwardingSS
CFB
CFNRy
CFNRc
CD
FeatureActivityStatus
CFU + CFNA +CFB
CFU
CFNA +CFB
CFB
CFNA1
CFNA1
-
BasicService2
Refer to GSM 09.02[1] for Basic Service Codes
-
SSStatus
Q P R A3
0 0 0 0
0 0 0 14
0 0 1 04
0 0 1 14
0 1 0 0
0 1 0 14
0 1 1 0
0 1 1 1
1 0 0 04
1 0 0 14
1 0 1 04
1 0 1 14
FeatureActivityStatus
Not authorized
-
-
-
Authorized but de-activated
-
Authorized but de-activated
Authorized and activated
-
-
-
-
2
3
N.S0028
113
1
Table 93: Forwarding Information List to Calling Features Indicator Parameter Mapping 2 (concluded) 3
GSM_Forwarding Information List ANSI-41_Calling Features Indicator
1 1 0 04
1 1 0 14
1 1 1 04
1 1 1 1
-
-
-
Authorized and activated
ForwardedToNumber
E164 Address
-
ForwardedToSubaddress
E164 Address
-
ForwardingOptions
Notification to forwarding party
Notification to calling party
Forwarding reason
-
NoReplyConditionTime -
4
1The ANSI-41 CFNA value maps to both GSM values CFNRc and CFNRy. 5 2GSM allows call forwarding services to be operated on a per basic service group basis. ANSI-6 41 on the other hand has no concept of basic service groups. Therefore, one or more GSM 7 basic services or basic service groups shall map to all basic services in ANSI-41. 8 3The QPRA bits, refer to the Quiescent, Provisioned, Registered & Activation status of the 9 various call forwarding services e.g. QPRA = 0110 means that the status of that call forwarding 10 service is not quiescent, provisioned, registered, not active. 11 4These combinations are not applicable to GSM Call Forwarding services. 12
13
14
N.S0028
114
1
Table 94: Regional Subscription Data to Geographic Authorization Parameter Mapping 2
GSM_Regional Subscription Data ANSI-41_Geographic Authorization
ZoneCode
See GSM 09.02 [1] for definition of zone code1
GeographicAuthorization
Authorized for all MarketIDs served by the VLR
Authorized for this MarketID only
Authorized for this MarketID and SwitchNo only
Authorized for this locationAreaID within a MarketID only
3 1Based on the zone code, which identifies those regions or zones where a roaming is allowed, 4 these values may map to one or more values in the Geographic Authorization. 5
Table 95: Call Barring Information List to Origination Indicator Parameter Mapping 6
GSM_Call Barring Information List ANSI-41_Origination Indicator
SSCode
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
7
8
N.S0028
115
1
Table 95: Call Barring Information List to Origination Indicator Parameter Mapping 2 (concluded) 3
GSM_Call Barring Information List ANSI-41_Origination Indicator
BAOC,BOIC, BOIC-exHC
-
-
BarringOfIncomingCalls
BAIC
BIC-Roam
BAOC
or of international E.164 number6
Selected leading digits of directory number or of international E.164 number and local calls6
International calls
Single Directory number or international E.164 number
-
-
-
-
BasicService
See GSM 09.02[1] for Basic Service codes
-
SSStatus
Q P R A
See GSM 09.02[1] for SSStatus values
-
4
5
Note (a): If the origination indicator value received indicates ‘prior agreement’ this may map into 6 one or more GSM SS Codes depending on the agreement between roaming partners. 7
12If the IIF receives any of these GSM SSCodes, they shall map to the same ANSI-41 allowed 8 call type as shown in Table 95. 9
N.S0028
116
3If the IIF receives the ANSI-41 allowed call type set to ‘origination denied’, this shall be 1 mapped as shown in Table 95. 2
4If the IIF receives the ANSI-41 allowed call type set to ‘national long distance’, this shall be 3 mapped as shown in Table 95. 4 5If the IIF receives the ANSI-41 allowed call type set to ‘local calls only’ this shall be mapped as 5 shown in Table 95. 6 6If the IIF receives the ANSI-41 allowed call type as shown, this may be mapped to one or more 7 GSM SSCode values as shown in Table 95. 8
9
N.S0028
117
1
Table 96: SSData List to Calling Features Indicator Parameter Mapping 2
GSM_SSData List ANSI-41_Calling Features Indicator
SSCode
CW + CH
-
-
-
MPTY
Note (a)
CLIR
CLIP
CLIP
-
COLP
COLR
CNAP
ECT
CCBS-A
CCBS-B
AoCI
AoCC
FeatureActivityStatus
CW
CT
VP
CD
3WC
CNIROver
CNIR
CNIP2
CNIP1
PCW
-
-
-
-
-
-
-
-
3
4
N.S0028
118
1
Table 96: SSData List to Calling Features Indicator Parameter Mapping (concluded) 2
GSM_SSData List ANSI-41_Calling Features Indicator
UUS
PLMNSpecific
-
-
BasicService1
See GSM 09.02[1] for Basic Service codes
-
SSStatus(need to map to SMSMo & MT Restriction in ANSI)
Q P R A
0 0 0 0
0 0 0 12
0 0 1 02
0 0 1 12
0 1 0 0
0 1 0 1
0 1 1 02
0 1 1 1
1 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-activated
Authorized and activated
-
Authorized and activated
-
-
-
-
-
-
-
-
CLIRestrictionOption3
Permanent
TemporaryDefaultRestricted
TemporaryDefaultAllowed
Feature Activity Status
-
Authorized and activated
Authorized and deactivated
OverrideCategory4
OverrideEnabled
OverrideDisabled
Feature Activity Status
Authorized and activated
Authorized and deactivated
3
N.S0028
119
1
Note (a): There is no equivalent GSM SSCode value for CNIROver. The override restriction 2 capability in GSM is a subscription option whose value is reflected by the OverrideCategory 3 4
1GSM allows supplementary services to be operated on a per basic service group basis. ANSI-5 41 on the other hand has no concept of basic service groups. Therefore, one or more GSM 6 basic services or basic service groups shall map to all basic services in ANSI-41. 7
2These combinations are not applicable to the GSM supplementary services defined by their 8 SSCode in Table 96 9 3The CLIRestriction option is equivalent to the ANSI-41 Feature Activity Status, CNIR. If the 10 CLIRestriction is temporary default restricted, this equates to the value ‘Authorized and 11 activated’ in the CNIR feature activity status. If the CLIRestriction is temporary default allowed, 12 this equates to the value ‘Authorized but deactivated’ in the CNIR feature activity status. There 13 is no equivalent in ANSI-41 to permanently restricted. 14 4The GSM override category is equivalent to the ANSI-41 Feature Activity Status, CNIROver. 15 If the Override Category is enabled, this equates to the value ‘Authorized and activated’ in the 16 CNIROver feature activity status. If the Override Category is disabled, this equates to the value 17 ‘Authorized but deactivated’ in the CNIROver feature activity status. 18
Table 97: Operator Determined Barring general data to Origination Indicator 19 Parameter Mapping 20
GSM_Operator determined barring (general) ANSI-41_Origination Indicator
ODB-General data
AllOG-callsBarred
InternationalOGCalls Barred1
InternationalOGCallsNotToHPLMN-CountryBarred1
InterzonalOGCallsBarred1
InterzonalOGCallsNotToHPLMN-CountryBarred1
Allowed Call Types
Origination denied
National long distance2
National long distance
Selected leading digits of directory number or of international E.164 number and local calls
Selected leading digits of directory number or of international E.164 number and local calls
21
22
N.S0028
120
1
Table 97: Operator Determined Barring general data to Origination Indicator 2 Parameter Mapping (concluded) 3
GSM_Operator determined barring (general) ANSI-41_Origination Indicator
InterzonalandInternationalOGCallsNotToHPLMN-CountryBarred1
PremiumRateInformationOGCallsBarred1
PremiumRateEntertainmentOGCallsBarred1
SSAccessBarred
AllECTBarred
ChargeableECTBarred
InternationalECTBarred
InterzonalECTBarred
DoublyChargedECTBarred
MultipleECTBarred
Selected leading digits of directory number or of international E.164 number and local calls
Selected leading digits of directory number or of international E.164 number and local calls
Selected leading digits of directory number or of international E.164 number and local calls
-
-
-
-
-
-
4
Note: The mapping shown in Table 97 applies in one direction only i.e. from GSM to ANSI-41. 5 The corresponding ANSI-41 values received by the IIF in “profile” macro parameter, it shall be 6 mapped according to Table 95. 7
8 1If the IIF receives any of these GSM ODB general data, they shall map to the same ANSI-41 9 allowed call type as shown in Table 97. 10
11
N.S0028
121
1
Table 98: Operator Determined Barring HPLMN data to Origination Indicator Parameter 2 Mapping 3
GSM_Operator determined barring (HPLMN)
ANSI-41_Origination Indicator
ODB-HPLMN data
PLMN-SpecificBarringType1
Allowed Call Types
-
4
Table 99: Operator Determined Barring HPLMN data to Restriction digits Parameter 5 Mapping 6
GSM_Operator determined barring (HPLMN)
ANSI-41_Restriction Digits
ODB-HPLMN data
PLMN-SpecificBarringType1
Type of Number
-
7
8
N.S0028
122
Table 100: Call Barring Information List to SMS Origination Restrictions Parameter 1 Mapping 2
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
4
N.S0028
123
1
Table 100: Call Barring Information List to SMS Origination Restrictions Parameter 2 Mapping (concluded) 3
GSM_Call Barring Information List ANSI-41_SMS Origination Restrictions
BasicService
See GSM 09.02[1] for Basic Service codes
-
SSStatus
Q P R A
See GSM 09.02[1] for SSStatus values
-
4
Table 101: Call Barring Information List to SMS Termination Restrictions Parameter 5 Mapping 6
GSM_Call Barring Information List ANSI-41_SMS Termination Restrictions
SSCode
AllBarringSS
BarringOfOutgoingCalls
BAOC
-
-
BOIC
BOIC-exHC
BAOC
BarringOfIncomingCalls
BAIC
BIC-Roam
-
-
-
Default
-
-
Block All
Allow Specific
Allow All
-
-
-
-
-
-
Reserve Charges
Block Direct
Allow Direct
BasicService
See GSM 09.02[1] for Basic Service codes
-
SSStatus
Q P R A
See GSM 09.02[1] for SSStatus values
-
7
8
N.S0028
124
Table 102: Call Barring Information List to Termination Restriction Code Parameter 1 Mapping 2
GSM_Call Barring Information List ANSI-41_Termination Restriction Code
SSCode
AllBarringSS
BarringOfOutgoingCalls
BAOC
BOIC
BOIC-exHC
BAOC
BarringOfIncomingCalls
BAIC
BIC-Roam
-
Termination RC
-
-
-
-
-
-
-
Termination denied
-
Unrestricted
BasicService
See GSM 09.02[1] for Basic Service codes
-
SSStatus
Q P R A
See GSM 09.02[1] for SSStatus values
-
3
4
N.S0028
125
Table 103: SSData List to SMS Origination Restrictions Parameter Mapping 1
GSM_SSData List ANSI-41 SMS Origination Restrictions
SSCode
See GSM 09.02 [1] for SS Codes
-
BasicService
See GSM 09.02 [1] for complete list of Basic Services
Default
Block All1
SSStatus
-
CLIRestrictionOption
-
OverrideCategory
-
2
1In the case where the BasicService does not indicate that SMS is available, this shall be mapped to 3 ‘Block All’. 4
Table 104: SSData List to SMS Termination Restrictions Parameter Mapping 5
GSM_SSData List ANSI-41 SMS Termination Restrictions
SSCode
See GSM 09.02 [1] for SS Codes
-
BasicService
See GSM 09.02 [1] for complete list of Basic Services
Default
Block All1
SSStatus
-
CLIRestrictionOption
-
OverrideCategory
-
6
1In the case where the BasicService does not indicate that SMS is available, this shall be mapped to 7 ‘Block All’. 8
9
N.S0028
126
1
4.4.3 Error Handling 2
3
Error handling defined in GSM 09.02 [3] and ANSI-41 [6] is directly applicable to the IIF, when 4 the IIF is emulating a GSM or ANSI-41 network functional element. 5
Subscriber Deletion 6
If the Subscriber Deletion procedure fails at an ANSI-41 VLR, the VLR shall respond by either 7 sending: 8
9 An ANSI_MAP_regcanc in a TCAP RETURN RESULT indicating cancellation denied 10 (CANDEN) to the IIF, with one of the following reasons as defined in ANSI-41 [6] 11
Appropriate CANDEN Values in ANSI_MAP_regcanc RETURN RESULT 12
CANDEN Value
Multiple access
Busy
13
The ANSI_MAP regcanc may optionally indicate: 14
• CallHistoryCount 15
• ControlChannelData 16
• ReceivedSignalQuality 17
• SMS_MessageWaitingIndicator 18
• SystemAccessData 19
as defined in ANSI-41 [6] 20
Or, an ANSI_MAP regcanc in a TCAP RETURN ERROR one of the following error codes as 21 defined in ANSI-41 [6]: 22
Appropriate Error Codes in ANSI_MAP_regcanc RETURN ERROR 23
Error Codes
UnrecognizedESN
OperationSequenceProblem
ResourceShortage
OperationNotSupported
ParameterError
SystemFailure
24
N.S0028
127
The IIF is therefore responsible for mapping any errors it receives from the ANSI-41 VLR in the 1 ANSI_MAP regcanc to an equivalent error in the GSM MAP 2 _CANCEL_LOCATION_RESPONSE towards the GSM HLR. 3
4
The GSM MAP _CANCEL_LOCATION_RESPONSE may include one the following ‘user’ 5 errors as defined in GSM 09.02 [3]: 6
Appropriate User Errors 7
User Errors
unexpected data value;
data missing;
8
The following ‘provider errors’ (protocol related errors) are also defined in GSM 09.02 [3]: 9
Appropriate Provider Errors 10
Provider Errors
duplicated invoke Id;
not supported service;
mistyped parameter;
resource limitation;
initiating release (i.e., the peer has already initiated release of the dialogue
and the service has to be released);
unexpected response from the peer;
service completion failure;
no response from the peer;
invalid response received.
11
If the Subscriber Deletion procedure fails at a GSM VLR, it returns a GSM MAP 12 _CANCEL_LOCATION_RESPONSE to the IIF, indicating an ‘user error’ as indicated above. The 13 IIF is therefore responsible for mapping any errors it receives into a corresponding error in the 14 ANSI_MAP regcanc towards the ANSI-41 HLR. For further description of these errors and when 15 they are used, refer to either GSM 09.02 [3] or ANSI-41 [6]. 16
The « Location Registration » provides the mapping of both user errors and provider errors in 17 the GSM MAP _CANCEL_LOCATION_RESPONSE to the equivalent value in either the 18 CANDEN parameter in the ANSI_MAP regcanc RETURN RESULT or the RETURN ERROR. 19
20
21
N.S0028
128
1
Subscriber Data Modification 2
If the Subscriber Data Modification procedure fails at an ANSI-41 VLR, the VLR shall respond 3 by sending:- 4
5 An ANSI_MAP qualdir in a TCAP RETURN ERROR with one of the following reasons as 6 defined in ANSI-41 [6]: 7
Appropriate Provider Errors 8
Provider Errors
duplicated invoke Id;
not supported service;
mistyped parameter;
resource limitation;
initiating release (i.e., the peer has already initiated release of the dialogue
and the service has to be released);
unexpected response from the peer;
service completion failure;
no response from the peer;
invalid response received.
9
The IIF is therefore responsible for mapping any errors it receives from the ANSI-41 VLR in the 10 ANSI_MAP qualdir to an equivalent error in the GSM MAP 11 _INSERT_SUBSCRIBER_DATA_RESPONSE or the GSM MAP 12 _DELETE_SUSBCRIBER_DATA_RESPONSE towards the GSM HLR. 13
14
The GSM MAP _INSERT_SUBSCRIBER_DATA_RESPONSE and the GSM 15 MAP_DELETE_SUBSCRIBER_DATA RESPONSE may include one the following ‘user’ errors 16 as defined in GSM 09.02 [3]: 17
Appropriate User Errors 18
User Errors
unidentified subscriber;
data missing;
unexpected data value.
19
N.S0028
129
The following ‘provider errors’ are also defined in GSM 09.02 [3]: 1
2
Appropriate Provider Errors 3
Provider Errors
duplicated invoke Id;
not supported service;
mistyped parameter;
resource limitation;
initiating release (i.e. the peer has already initiated release of the
dialogue and the service has to be released);
unexpected response from the peer;
service completion failure;
no response from the peer;
invalid response received.
4
If the Subscriber Data Modification procedure fails at a GSM VLR, it returns either a GSM MAP 5 _INSERT_SUBSCRIBER_DATA_RESPONSE or a GSM MAP 6 _DELETE_SUBSCRIBER_DATA_RESPONSE to the IIF, indicating a ‘user error’ as indicated 7 above. The IIF is therefore responsible for mapping any errors it receives into a corresponding 8 error in the ANSI_MAP qualdir towards the ANSI-41 HLR. For further description of these 9 errors and when they are used, refer to either GSM 09.02 [3] or ANSI-41 [6]. 10
Table 105 below provides the mapping of both user errors and provider errors in the GSM MAP 11 _INSERT_SUBSCRIBER_DATA_RESPONSE and GSM MAP 12 _DELETE_SUBSCRIBER_DATA_RESPONSE to the equivalent value in the ANSI_MAP 13 qualdir RETURN ERROR for ANSI-41 Foreign mode. Table 106 provides the mapping for GSM 14 Foreign mode. 15
16
N.S0028
130
1
Table 105: ISD_RESPONSE and DSD_RESPONSE to Qualdir Return Error Mapping 2
INSERT/DELETE_SUBSCRIBER_DATA_RESPONSE (Errors)
Qualdir Return Error
Unidentified subscriber Unrecognized MSID
Data missing SystemFailure
Unexpected data value SystemFailure
Duplicated Invoke Id SystemFailure
Not supported service SystemFailure
Mistyped parameter SystemFailure
Resource limitation SystemFailure
Initiating release SystemFailure
Unexpected response from the peer SystemFailure
Service completion failure SystemFailure
No response from the peer SystemFailure
Invalid response received SystemFailure
3
Table 106: Qualdir Return Error to INSERT_SUBSCRIBER_DATA_RESPONSE and 4 DELETE_SUSBCRIBER_DATA_RESPONSE Error Mapping 5
Qualdir Return Error INSERT/DELETE_SUBSCRIBER_DATA_RESPONSE (Errors)
Unrecognized MSID Unidentified subscriber
Unrecognized ESN Unexpected data value
ResourceShortage Unexpected data value
OperationNotSupported Unexpected data value
ParameterError Unexpected data value
SystemFailure Unexpected data value
UnrecognizedParameterValue Unexpected data value
Missing Parameter Data Missing
6
7
8
N.S0028
131
1
4.5 Short Message Procedures (ANSI-136 41 Network) 2
3
Existing mobility procedures described in either GSM 09.02 [3] or ANSI-41 [6] are also directly 4 applicable to the IIF when it is emulating a GSM or ANSI-41 functional network element. 5
6
4.5.1 Short Message Service via CMT 7
8
The Short Message Service procedure is used to deliver short text messages to and from 9 mobile subscribers. 10
11
4.5.1.1 Detailed Procedures 12
13
The following procedures are applicable at the IIF for Short Message Service. Mobile 14 Terminating SMS and Mobile Originated SMS using the CMT teleservice ID are described in 15 4.5.1.1. 16
17
4.5.1.1.1 Mobile Terminating SMS in GSM foreign mode 18
19
If the IIF receives an ANSI-41 Short Message Delivery Point to Point message from the home 20 Message Center, it shall check if the subscriber location is known and if the subscriber is active. 21 If both conditions are true, the IIF shall format and send a GSM_ 22 MAP_FORWARD_SHORT_MESSAGE to the GSM MSC/VLR serving the mobile. Refer to 23 Table 109 for the mapping of parameters from ANSI_SMDPP to GSM MAP 24 _FORWARD_SHORT_MESSAGE. 25
If a successful response is received for the FSM, the IIF shall send a SMDPP Return Result 26 message to the home Message Center 27
If the subscriber’s location is not known, or if the subscriber is inactive or if the response to the 28 FSM indicates the short message was not delivered to the mobile, the IIF shall set the SMS 29 Delivery Pending flag for the subscriber. The IIF shall then send an SMDPP Return Result 30 message with an appropriate SMS_CauseCode value to the home MC. Refer to 4.5.1.3 Error 31 Handling for the values of SMS_CauseCode returned. 32
If errors are detected when the SMDPP is received, the message may be rejected if it cannot 33 be processed or if mandatory parameters are missing. Otherwise, the IIF shall send an SMDPP 34 Return Result message with the appropriate SMS_CauseCode value. Refer to 4.5.1.3 Error 35 Handling for the description of error conditions and corresponding SMS_CauseCode values. 36
N.S0028
132
If the response to FSM indicates a failure in the delivery of the short message, the IIF 1 shall map the cause value received to a corresponding SMS_CauseCode value in the 2
SMDPP Return Result, as described in 3
4
5
6
Table 116. 7
8
If the response to FSM indicates that the receiving entity does not support MAP V2, the GSM 9 MAP_FORWARD_SHORT_MESSAGE is formatted in MAP V1 and sent again to the serving 10 MSC/VLR. 11
12
4.5.1.1.2 Alerting in GSM Foreign Mode 13
14
If the IIF receives a GSM MAP _READY_FOR-SHORT_MESSAGE (MAP V2) or a 15 GSM_UPDATE_LOCATION message, or a GSM MAP _NOTE_MS_PRESENT message (MAP 16 V1) and the Delivery pending flag is set for the subscriber, the IIF shall send an 17 ANSI_MAP_SMS_NOTIFICATION message to the home Message Center. The flag shall then 18 be cleared. The home MC shall re-send message SMDPP to deliver the short message to the 19 subscriber as described previously. 20
21
4.5.1.1.3 Mobile Terminating SMS in ANSI-136 41 Foreign Mode 22
23
If the IIF receives a GSM_FORWARD_SHORT_MESSAGE, it shall format and send an 24 ANSI_MAP Short Message Delivery Point to Point message to the serving TDMA ANSI-41 25 MSC/VLR. Refer to Table 110, Table 111 and Table 112 for the mapping of parameters from 26 GSM MAP _FORWARD_SHORT_MESSAGE to ANSI_SMDPP. 27
If the IIF receives a positive acknowledgment to the SMDPP message, it shall send a positive 28 acknowledgment to the Forward Short Message. 29
If the IIF receives a negative acknowledgment to the SMDPP message, it shall set the Mobile 30 Not Reachable flag for the subscriber and shall map the received SMS_CauseCode value into 31 a corresponding error code in the FSM Response message as described in Table 117. 32
If the IIF detects errors in the FORWARD_SHORT_MESSAGE, an error indication is sent in the 33 response message. This shall cause the GSM MSC/VLR to send an error indication to the GSM 34 HLR. Refer to 4.5.1.3 Error Handling for error detection on reception of FSM. 35
If a Return Error or Reject is received in response to the ANSI_MAP_SMSDPP INVOKE, the 36 error code is mapped into the corresponding Forward Short Message error code as described 37 in Table 117. 38
39
N.S0028
133
4.5.1.1.4 Alerting in ANSI-136 41 Foreign Mode 1
2
If the IIF receives an ANSI_MAP Registration Notification message or an ANSI_MAP SMS 3 Notification message, and the SMS Delivery Pending flag is set for a mobile subscriber, it shall 4 send a GSM MAP _READY_FOR-SHORT_MESSAGE (MAP V2) or a GSM MAP 5 _NOTE_MS_PRESENT message (MAP V1) to the GSM HLR. This shall cause the HLR to 6 send an indication to the GSM SMSC that shall trigger the re-sending of the Short message. 7
8
4.5.1.1.5 Mobile Originating SMS in GSM Foreign Mode 9
10
If the IIF receives a GSM_FORWARD_SHORT_MESSAGE for a mobile originated short 11 message, it shall format and send an ANSI_MAP_SMDPP message to the serving TDMA 12 ANSI-41 Message Center. Refer to Table 114 for the mapping of parameters from GSM MAP 13 _FORWARD_SHORT_MESSAGE to ANSI_SMDPP. 14
If the IIF receives a positive acknowledgment to the SMDPP message, it shall send a positive 15 acknowledgment to the Forward Short Message. 16
If the IIF receives a negative acknowledgment to the SMDPP message, it shall map the 17 received SMS_CauseCode value into a corresponding error code in the FSM Response 18 message as described in Table 117 19
If the IIF detects errors in the FORWARD_SHORT_MESSAGE, an error indication is sent in the 20 response message. Refer to 4.5.1.3 for the handling of errors at the reception of FSM. 21
22
4.5.1.1.6 Mobile Originating SMS in ANSI-136 41 Foreign Mode 23
24
If the IIF receives an ANSI-SMDPP message from the Serving MSC, it shall format and send a 25 GSM MAP_FORWARD_SHORT_MESSAGE to the GSM Message Center of the subscriber. 26 Refer to Table 115 for the mapping of parameters from ANSI_SMDPP to GSM MAP 27 _FORWARD_SHORT_MESSAGE. 28
If a successful response is received for the FSM, the IIF shall send a SMDPP Return Result 29 message to the MSC/VLR. 30
If errors are detected when the SMDPP is received, the message may be rejected if it cannot 31 be processed or if mandatory parameters are missing. Otherwise, the IIF shall send an SMDPP 32 Return Result message with the appropriate SMS_CauseCode value. Refer to 4.5.1.3 Error 33 Handling for the description of error conditions and corresponding SMS_CauseCode values. 34
If the response to FSM indicates that the receiving entity does not support MAP V2, the GSM 35 MAP_FORWARD_SHORT_MESSAGE is formatted in MAP V1 and sent again to the serving 36 MSC/VLR. 37
38
N.S0028
134
1
4.5.1.2 Mapping of Messages, Parameters & Parameter Values 2
3
4.5.1.2.1 Mapping of Messages 4
5
The IIF shall perform the mapping of messages, parameters and parameter values related to 6 Short Message Service in accordance with the tables presented. 7
Table 107 shows the mapping between ANSI MAP messages and GSM MAP messages 8 related to Short Message Service in GSM Foreign Mode. Table 108 shows the mapping 9 between GSM MAP messages and ANSI MAP messages related to Short Message Service in 10 ANSI-136 41 Foreign Mode. 11
Table 107: Short Message Service in GSM Foreign Mode (for CMT) Message Mapping 12
ANSI MAP Messages GSM MAP Messages
SMDPP
FORWARD_SHORT_MESSAGE
13
Table 108: Short Message Service in ANSI-136 41 Foreign Mode (for CMT) Message 14 Mapping 15
GSM MAP Messages ANSI MAP Messages
FORWARD_SHORT_MESSAGE
SMDPP
16
17
N.S0028
135
1
4.5.1.2.2 Mapping of Parameters 2
3
Table 109 through Table 115 show the mapping of parameters, which the IIF shall perform. 4
Table 109: SMDPP to MT_Forward Short Message Parameter Mapping for GSM Foreign 5 Mode 6
ANSI SMDPP Status GSM MT FSM Status
MSID O
Note 1
SMS_OriginalDestinationAddress (= MSID)
O
Note 1
SM-RP-DA = IMSI
M
SMS-Originating-Address (= MC Address)
O SM-RP-OA = IIF address in international format. See 4.5.2.4
M
User Data Unit (in SMS_Bearer_Data)
M SM-RP-UI
See Table 111 and Table 112 for details of encoding of this parameter.
M
- More Messages to Send = no M
Note 2
7
Note 1: MSID and SMS_Original_Destination_Address should be the same. 8
Note 2: This parameter is only valid for MAP V2. 9
10
N.S0028
136
1
Table 110: MT_Forward Short Message to SMDPP Parameter Mapping for ANSI-41 2 Foreign Mode 3
GSM MT FSM Status ANSI SMDPP Status
MSID R SM-RP-DA= IMSI M
ESN O
SM-RP-UI
M SMS Bearer Data
See Table 113 for encoding of this parameter.
M
-
SMS Teleservice Identifier set to value (= CMT)
M
SM-RP-OA (=SMS-SC Address) M SMSOriginating Address (= IIF Address) See 4.5.2.4
R
4
The IIF shall support the mapping of parameters in Forward Short Message in both MAP V1 5 and MAP V2. Encoding of parameter SM-RP-UI is different depending on the MAP version 6 being encoded in the message. The two following tables describe the coding for each version 7 of MAP. 8
9
Table 111describes the setting of field values for parameter SM-RP-UI for MAP V2. 10
Table 111: SM-RP-UI in MT_FORWARD_SHORT_MESSAGE for MAP V2 Parameter Values 11 for GSM Foreign Mode 12
FIELD VALUE
Message 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 IIF
User Data Length Number of characters
User Data If TDMA CMT, the The IS-136 SMS message (parameter User Data) converted to the GSM default alphabet, unless it is sent as an 8-bit data. Truncate message length if longer than 134 octets (152 characters).
If CDMA CMT, the IS-95 SMS message (parameter User Data) converted to the GSM default alphabet, unless it is sent as an 8-bit data. Truncate message length if longer than 134 octets (152 characters) (only MAP V2). Truncate message length if longer than 134
N.S0028
137
octets (152 characters) for MAP V2 (160 characters for MAP V1).
Originating Address The address of the original SME. Use the value received in parameter SMS Original Originating Address in SMDPP.
1
2
N.S0028
138
1
Table 111: SM-RP-UI in MT_FORWARD_SHORT_MESSAGE for MAP V2 Parameter Values 2 for GSM Foreign Mode (concluded) 3
FIELD VALUE
Data Coding Scheme - Set bit numbers 7654 to data coding (value 1111).
Set bit number 3 to 0.
- Set bit 2 to value default alphabet if received parameter Encoder Identifier has value “IRA” or “Latin-1, otherwise set to value “8-bit”.
- Set bit numbers 1&0 to value “Class 0” if received parameter Urgency Indicator has value “Very Urgent”, otherwise set to value “Class 1”.
4
The following table describes the setting of field values for parameter SM-RP-UI for MAP V1. 5
Table 112: SM-RP-UI in MT_FORWARD_SHORT_MESSAGE for MAP V1 Parameter 6 Encoding for GSM Foreign Mode 7
FIELD VALUE
Message 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 IIF
User Data Length Number of characters
User Data
Originating Address The address of the original SME. Use the value received in parameter SMS Original Originating Address in SMDPP.
Data Coding Scheme Use the coding value “default alphabet”
8
9
N.S0028
139
1
Table 113: SMS_Bearer Data in Mobile Terminating SMDPP Parameter Encoding for 2 ANSI-41 Foreign Mode 3
FIELD VALUE
Message type indicator (M) 000 “SMS Deliver”
Message Reference (M) created by IIF
Privacy 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: 0
User Data Structure Type: 00
User Data: GSM User Data from SM-RP-UI translated to the IS-136 IRA alphabet
If CDMA CMT:
Encoding Identifier: possible values are unspecified, IS-91 EPM, 7-bit ASCII, and IA5
MSG_ENCODING: Set to 7-bit ASCII if received message is in GSM default alphabet, otherwise set to Octet, unspecified.
MST:omitted
NUM_FIELDS: Number of characters
CHARi: GSM SMS message.If encoding identifier has value 7-bit ASCII (ANSI X3.4), translate GSM SMS message to the 7-bit ASCII alphabet.
4
5
N.S0028
140
1
Table 114: Forward_Short_Message to ANSI-41_SMDPP Parameter Mapping for MO SMS 2 in GSM Foreign Mode 3
GSM Forward Short Message Status ANSI SMDPP Status
Note 1 ESN O
Note 1 MSID O
SMS Teleservice ID = CMT M
SMS_Originating Address (=IIF Address)
O
SM-RP-OA (A-MSISDN) M
Note 1
SMS_Original Originating Address (= A-MSID)
R
SMS_Original DestinationOriginating Address Sub Address (not sent)
O
SM-RP-UI: TP-Destination address (B-MSISDN)
M SMS_Original Destination Address
R
SMS_Original Originating Address Sub Address (not sent)
O
SMS_Charge Indicator (not sent) O
SMS_Message Count (not sent) O
SMS_Notification Indicator (not sent)
O
SM-RP-DA (IIF Address) M SMS_Destination Address (= MC address retrieved from mapping in database) See 4.5.2.4
R
SM-RP-UI
TP-Message-Type-Indicator
TP-Reject-Duplicates (ignored)
TP-Validity-Period
TP-Validity-Period-Format
TP-Reply-Path (ignored)
TP-User-Data-Header-Indicator (ignored)
TP-Status-Report-Request (ignored)
TP-Message-Reference
TP-Protocol-Identifier (ignored)
TP-Data-Coding-Scheme
TP-User-Data-Length
M SMS Bearer Data
TP-Message-Type-Indicator
TP-Validity-Period
TP-Delivery-Ack-Request (=prohibit)
TP-Message-Reference
TP-Urgent-Indicator
TP-User-Data-Unit
M
4
5
N.S0028
141
1
Table 114: Forward_Short_Message to ANSI-41_SMDPP Parameter Mapping for MO SMS 2 in GSM Foreign Mode (concluded) 3
GSM Forward Short Message Status ANSI SMDPP Status
TP-User-Data
TP-Privacy_indicator (=not restricted)
TP-Manual-Ack-Request (=prohibit)
TP-Message-Updating (=do not overwrite)
TP-Deferred-Delivery-Time (=not set)
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)
4
Note 1: MSID and ESN are supplied based on MSISDN received in SM-RP-OA 5
6
Table 115: ANSI-41 SMDPP to GSM Forward_Short_Message Parameter Mapping for MO 7 SMS in ANSI-41 Foreign Mode 8
ANSI SMDPP Status GSM Forward Short Message Status
SMS Teleservice ID M -
ESN O -
MSID O -
SMS_Charge Indicator O -
SMS_Message Count O -
SMS_Notification Indicator O -
9
10
N.S0028
142
1
Table 115: ANSI-41 SMDPP to GSM Forward_Short_Message Parameter Mapping for MO 2 SMS in ANSI-41 Foreign Mode (continued) 3
ANSI SMDPP Status GSM Forward Short Message Status
SMS_Destination Address (IIF Address)
O SM-RP-DA: SC Address (retrieved from mapping in IIF database) see 4.5.2.4
M
SMS_Original Destination Address (B-MSISDN)
O TP_Destination-Address within SM-RP-UI
M
SMS_Original Destination Sub Address
O -
SMS_Originating Address O -
SMS_Original Originating Address (A-MSID)
O SM-RP-OA: A-MSISDN M
SMS_Original Originating Sub Address
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- SET
TP-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
4
5
N.S0028
143
1
Table 115: ANSI-41 SMDPP to GSM Forward_Short_Message Parameter Mapping for MO 2 SMS 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 Data
MSG_ENCODING: For CDMA, possible values are unspecified, IS-91 EPM, 7-bit ASCII, and IA5.
MST:Message type IS-95 or IS-136 is used NUM_FIELDS: Number of characters. Messages above GSM limit will be truncated.
CHARi: IS-95 or IS-136 SMS message itself
TP-Destination-Address = SMS-Original-Destination Address.
N.S0028
144
1
N.S0028
145
1
4.5.1.3 Error Handling 2
3
Error handling at the reception of a Forward Short Message in the IIF 4
5
1. If a mandatory parameter is missing (MAP V2), a Forward Short Message Response 6 with 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 Response 8 with the indication “Mistyped Parameter” is sent back to the SMS-GMSC. 9
3. A Forward Short Message Response with the problem code “Mistyped Parameter” is 10 sent 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 Message 16 Response 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 Response 18 with 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, Forward 20 Short Message Response with the indication “Unidentified Subscriber” is sent back to 21 the SMS-GMSC. 22
7. If location is unknown or inactive, send back to the SMS-GMSC a Forward Short 23 Message Response message with the indication “Absent Subscriber”. 24
8. If the subscriber has an ANSI SMS termination restriction, a Forward Short Message 25 Response message with indication “Facility Not Supported” is sent back to the SMS-26 GMSC. 27
9. If the short message contents could not be extracted from the SM-RP-UI parameter, send 28 back to the SMS-GMSC a Forward Short Message Response message with the 29 indication “System Failure”. 30
31
N.S0028
146
1
Error Handling at the Reception of ANSI-41 SMDPP 2
3
1. If the subscriber is not connected in the IIF then a SMDPP RR with cause code “SMS 4 Termination Denied” is returned. 5
If the ESN received does not match stored ESN then a SMDPP RR with cause code 6 “SMS Termination Denied” or “Address Translation Failure” is returned. 7
When the SMSNotification Indicator: “Notify when available” is not set, and the MS is 8 inactive or the subscriber’s location is unknown, a SMDPP RR with one of the following 9 cause 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 is 16 inactive or the subscribers location is unknown then a SMDPP RR with cause code 17 “SMS Delivery Postponed” is returned. 18
If the subscriber does not have SMS service then a SMDPP RR with cause code “SMS 19 Termination Denied” is returned. 20
2. If a SMDPP Invoke arrives at the IIF WITH A Teleservice ID that is not supported by the 21 IIF, 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 RR 23 with cause code “Missing mandatory parameter” is returned. 24
4. If the subscriber’s profile is not available, a SMDPP RR with cause code “Destination No 25 Longer at this Address” is returned. 26
5. If the GSM MSC/VLR is on a Barring List, a SMDPP RR with cause code “SMS Delivery 27 Postponed” “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 it 30 doesn’t require notification, or the IIF doesn’t set the delivery pending flag. 31
32
Error Mapping from GSM FSM to ANSI SMDPP to support Mobile Terminating SMS in 33 GSM Foreign and Mobile Originating SMS in ANSI-41 Foreign Mode 34
N.S0028
147
1
2
3
4
Table 116: Forward_Short_Message to SMS_CauseCode Values in SMDPP Return Result 5 Error Mapping 6
GSM FORWARD_SHORT_MESSAGE RESPONSE
ANSI SMDPP Return Result SMS-CauseCode Value
Absent Subscriber SMS Delivery Postponed OR No Page Response
Subscriber Busy for MT SMS SMS Delivery Postponed OR Destination Busy
Memory Capacity exceeded Destination resource shortage
System Failure Other network problem OR Network failure
DataMissing Other general problem OR Missing Mandatory Parameter
UnexpectedDataValue Encoding problem OR Unexpected Parameter value
7
8
N.S0028
148
1
Table 116: Forward_Short_Message to SMS_CauseCode Values in SMDPP Return Result 2 Error Mapping (concluded) 3
GSM FORWARD_SHORT_MESSAGE RESPONSE
ANSI SMDPP Return Result SMS-CauseCode Value
FacilityNotSupported SMS not supported
Unknown Subscriber Address translation failure
Illegal Subscriber Address translation failure OR SMS termination denied
SM-DeliveryFailure
cause: Equipment Protocol Error
Other radio interface problem OR No Acknowledgement
SM-DeliveryFailure
cause: Equipment Not SM-Equipped
Other terminal problem OR No Acknowledgement
SM-DeliveryFailure cause: unknownSC Address translation failure
SM-DeliveryFailure cause: SC-Congestion Network resource shortage OR No Acknowledgement
SM-DeliveryFailure cause: invalid SME-Addr
Address translation failure OR No Acknowledgement
SM-DeliveryFailure cause: subscriberNotSC-Subscriber
SMS origination denied OR No Acknowledgement
Absent Subscriber SM No acknowledgment OR No page response
Encoding Error Network Failure
Unidentified Subscriber Address Vacant
Illegal Equipment Other General Problems
Any other error Network Failure
4
Note: Unidentified Subscriber and Illegal Equipment may be treated as Any Other Error and 5 may be mapped to Network failure. 6
7
N.S0028
149
1
Error Mapping from ANSI SMSDPP to GSM FSM to support Mobile Terminating SMS in 2 ANSI-41 Foreign Mode and Mobile Originated SMS in GSM Foreign Mode 3
Table 117: SMDPP to Forward_Short_Message Error Mapping 4
SMSDPP (Cause Code) FORWARD_SHORT_MESSAGE Response
Destination Busy Subscriber Busy for MT-SMS
Address Vacant Absent Subscriber
No Page Response Absent Subscriber
No Acknowledgement Absent Subscriber
Destination Out of Service Absent Subscriber
Destination No Longer at this Address Absent Subscriber
SMS not supported FacilityNotSupported
Destination resource shortage SM-DeliveryFailure with cause “MemoryCapacityExceeded”
Other radio interface problem SM-DeliveryFailure with cause “equipmentProtocolError”
Unrecognized parameter value or Encoding problem
SM-DeliveryFailure with cause “equipmentProtocolError”
Radio interface incompatibility or Other terminal problems
SM-DeliveryFailure with cause “equipmentProtocolError”
SMS Delivery Postponed Absent Subscriber OR System Failure
Any other value System Failure
5
N.S0028
150
1
4.5.2 Short Message Service via GHOST or WEMT 2
3
4.5.2.1 Detailed Procedures 4
5
SMS Alert Procedure 6
The SMS Alert procedure is used for alerting the SMSC when the mobile subscriber is active 7 and available for short messaging after a short message transfer has failed because the mobile 8 subscriber is not reachable or when the Mobile Station (MS) has indicated that it has no 9 memory capacity to accept a short message. 10
11
4.5.2.1.1 Alerting for an ANSI-136 41 Subscriber in GSM Foreign Mode 12
13
IIF Receiving a READY_FOR_SM 14
Upon receipt of a READY_FOR_SM message, the IIF shall store the originating Visited MSC 15 (VMSC) address in the subscriber’s profile and Invoke ID. It shall map the 16 GSM_READY_FOR_SM message to the ANSI_SMSNOT INVOKE message as described in 17 Table 119. 18
It shall populate the SMS_Address parameter with the IIF address. All other parameters are 19 ignored. 20
The ANSI_SMSNOT INVOKE is then transmitted to the subscriber’s SMSC with local 21 Transaction ID. Finally, the IIF shall return a READY_FOR_SM_ACK message with no 22 arguments to the originating VMSC. 23
24
IIF Receiving a SMSNOT RETURN RESULT 25
Upon receipt of a SMSNOT RR message, the IIF shall associate the SMSNOT Transaction ID 26 with the Invoke ID. 27
28
4.5.2.1.2 Alerting for a GSM Subscriber in ANSI-136 41 Foreign Mode 29
30
IIF Receiving a SMSNOT INVOKE 31
Upon receipt of a SMSNOT message, the IIF shall store the originating VMSC address and 32 Transaction ID. The IIF shall map the ANSI_SMSNOT message to the 33 GSM_READY_FOR_SM. The parameters shall be mapped as described in Table 120. 34
The GSM_READY_FOR_SM is transmitted to the subscriber’s HLR with local Invoke ID. 35 Finally, the IIF shall return a SMSNOT RR to the originating VMSC. 36
37
N.S0028
151
IIF Receiving a REGNOT INVOKE 1
Alternatively, the IIF may receive a REGNOT message indicating an update in location of the 2 MS. Upon receipt of the REGNOT message, the IIF shall determine if the SMS Delivery 3 Pending 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 address 5 and 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. 7 The Alert Reason parameter is populated with the value - MS Present. All other parameters 8 are ignored. 9
The GSM_READY_FOR_SM is transmitted to the subscriber’s HLR with local Invoke ID. . 10 Finally, the IIF shall return a REGNOT RR to the originating VMSC. 11
12
IIF Receiving a GSM_READY_FOR_SM_ACK 13
Upon receipt of a GSM_READY_FOR_SM_ACK message, the IIF shall associate the 14 GSM_READY_FOR_SM_ACK Invoke ID with Transaction ID. 15
16
Short Message Service for GHOST 17
4.5.2.1.3 SMS Delivery for an ANSI-136 41 Subscriber in GSM Foreign Mode 18
19
IIF Receiving SMSDeliveryPointToPoint INVOKE 20
Upon receipt of an SMSDeliveryPointToPoint INVOKE message, the IIF shall store the 21 originating MC address and transaction ID. It shall map the ANSI_SMDPP message into a 22 GSM_FSM message and populate the subscriber’s known VMSC into the DPC. The mapping 23 of parameters is described in Table 121. 24
The IIF transmits the GSM_FSM message with local Invoke ID. 25
26
IIF Receiving FORWARD_SHORT_MESSAGE_ACK 27
Upon receipt of the FORWARD_SHORT_MESSAGE_ACK message, the IIF shall associate the 28 Invoke ID with SMDPP transaction ID and map the GSM_FSM_ACK message into an 29 ANSI_SMDPP RETURN RESULT. 30
Next, it populates the stored originating SMSC address into the DPC and populates the 31 transaction ID. 32
If the User Error parameter is populated in the GSM_FSM_ACK, then map this value into 33 the SMS_CauseCode according to 34
35
36
37
Table 116. 38
N.S0028
152
Finally, the ANSI_SMDPP RR is transmitted to the originating SMSC. 1
2
4.5.2.1.4 SMS Delivery for a GSM Subscriber in ANSI-136 41 Foreign Mode 3
4
IIF Receiving MT_FORWARD_SHORT_MESSAGE 5
Upon receipt of the MT_FORWARD_SHORT_MESSAGE message, the IIF shall store the 6 originating SMSC address and Invoke ID. It shall map the GSM_FSM message into an 7 ANSI_SMDPP INVOKE message and populate the subscriber’s known VMSC into the DPC. 8 The mapping of parameters is described in Table 122. 9
The IIF transmits the ANSI_SMDPP INVOKE message with local transaction ID 10
11
IIF Receiving SMDPP RETURN RESULT 12
Upon receipt of a SMSDeliveryPointToPoint RR message, the IIF shall associate the SMDPP 13 transaction ID with Invoke ID and map the ANSI_SMDPP RR to GSM_FSM_ACK. 14
Next, it populates the stored originating SMSC address and Invoke ID. If the SMS_CauseCode 15 parameter is populated in the ANSI_SMDPP RR message, then map value into User error 16 parameter according to Table 117. 17
Finally, transmit the GSM_FSM_ACK to the originating SMSC. 18
19
4.5.2.1.5 SMS Origination for an ANSI-136 41 Subscriber in GSM Foreign Mode 20
21
IIF Receiving MO_FORWARD_SHORT_MESSAGE 22
Upon receipt of a MO_FORWARD_SHORT_MESSAGE, the IIF shall store the address of the 23 originating VMSC and Invoke ID. It shall map the GSM_MO_FSM to ANSI_SMDPP INVOKE. 24 The address of the subscriber’s TSA (from the SM RP DA – Service Center Address) is 25 mapped according to 4.5.2.4 into the SMS_DestinationAddress. The mapping of parameters is 26 described in Table 123. 27
The IIF transmits the ANSI_SMDPP INVOKE message with local transaction ID. 28
IIF Receiving SMDPP RETURN RESULT 29
Upon receipt of a SMSDeliveryPointToPoint RR message, the IIF shall associate the SMDPP 30 transaction ID with Invoke ID and map the ANSI_SMDPP RR to the GSM_FSM_ACK. 31
Next, it populates the stored originating SMSC address and Invoke ID. If SMS_CauseCode 32 parameter is populated in the ANSI_SMDPP RR message, then map value into User error 33 parameter according to Table 117. 34
Finally, transmit the GSM_FSM_ACK to the originating VMSC. 35
36
4.5.2.1.6 SMS Origination for a GSM Subscriber in ANSI-136 41 Foreign Mode 37
38
N.S0028
153
IIF Receiving SMSDeliveryPointToPoint INVOKE 1
Upon receipt of an SMSDeliveryPointToPoint INVOKE message, the IIF shall store the address 2 of the originating VMSC and Transaction ID and map the ANSI_SMDPP INVOKE to the 3 GSM_MO_FSM. The mapping of parameters is described in Table 124. 4
The IIF transmits the GSM_FSM message with local Invoke ID. 5
6
IIF Receiving FORWARD_SHORT_MESSAGE_ACK 7
Upon receipt of the FORWARD_SHORT_MESSAGE_ACK message, the IIF shall associate the 8 Invoke ID with SMDPP transaction ID. The GSM_FSM_ACK message is mapped into an 9 ANSI_SMDPP RETURN RESULT. 10
Next, it populates the stored originating SMSC address and transaction ID. If the User 11 Error parameter is populated in GSM_FSM_ACK, then this value is mapped into the 12
SMS_CauseCode according to 13
14
15
16
Table 116. 17
Finally, transmit the ANSI_SMDPP RR to the originating VMSC. 18
19
4.5.2.2 Mapping of Messages, Parameters & Parameter Values 20
21
The IIF shall perform the mapping of messages, parameters and parameter values related to 22 Short Message Service in accordance with the tables presented next. 23
24
4.5.2.2.1 Mapping of Messages 25
26
Table 118: Short Message Service (for GHOST or WEMT) Message Mapping 27
ANSI MAP Messages GSM MAP Messages
SMSNOT READY_FOR_SM
28
4.5.2.2.2 Mapping of Parameters 29
30
N.S0028
154
The mapping of the GSM MAP _READY_FOR_SM message to the ANSI_SMSNOT message 1 is per Table 119. 2
Table 119: Alerting for an ANSI-136 41 Subscriber in GSM Foreign Mode Parameter 3 Mapping 4
GSM MAP _READY_FOR_SM Status ANSI_SMSNOT Status
ESN M IMSI M
MSID M
Alert Reason (MS present or Memory Available)
M -
SMS_Address (IIF Address) R
5
6
N.S0028
155
The mapping of the ANSI_SMSNOT message to the GSM MAP _READY_FOR_SM message 1 is per Table 120. 2
Table 120: Alerting for a GSM Subscriber in ANSI-136 41 Foreign Mode Parameter 3 Mapping 4
ANSI_SMSNOT Status GSM MAP _READY_FOR_SM Status
ESN M
MSID M
IMSI R
SMS_Address (Serving MSC) O -
Alert Reason (MS present) M
5
4.5.2.2.3 SMS Delivery for an ANSI-136 41 Subscriber in GSM Foreign Mode 6
7
When the IIF receives an SMDPP Invoke from an ANSI-136/41 SMSC for an ANSI-136/41 MS 8 roaming in a GSM network, it stores the Originating MC address, converts the SMDPP to a 9 MAP_FSM, replaces the Originating Address by the address of the IIF, and sends the message 10 to the serving GSM MSC. Upon receipt of the MAP_FSM_ACK from the serving MSC, the IIF 11 converts the message to an SMDPP Return Result, replaces the Originating Address with its 12 own address and replaces the Destination Address with the previously stored address of the 13 ANSI-136/41 SMSC. See Table 121. 14
Table 121: SMDPP to Forward Short Message for Mobile Terminated GHOST/WEMT 15 Teleservice Parameter Mapping in GSM Foreign Mode 16
SMDPP Status MT FSM Status
SMS Bearer Data M SM-RP-UI M
SMS Teleservice ID =GHOST or WEMT
M -
ESN O -
MSID (Note 1) O
SMS_OriginalDestinationAddress (= MSID) (Note 1)
O
SM-RP-DA = IMSI
M
SMS_ChargeIndicator O -
SMS_DestinationAddress O -
SMS_MessageCount O -
SMS_NotificationIndicator O -
SMS_OriginalDestinationSub Address
O -
SMS_Original Originating Address
O -
SMS_Original Originating Address Sub Address
O -
SMS_Originating Address (= MC Address)
O SM-RP-OA (set to IIF address) See 4.5.2.4
M
17
N.S0028
156
Note 1: MSID and SMS-Original-Destination Address should be the same 1
2
4.5.2.2.4 SMS Delivery for a GSM Subscriber in ANSI-136 41 Foreign Mode 3
4
When the IIF receives a MAP_FSM destined for an MS roaming in an ANSI-136/41 network, it 5 stores the originating Service Center address locally, and replaces the Service Center Address 6 in the outgoing SMDPP message by E.164 address of the IIF. Upon receipt of an SMDPP 7 Return Result from the serving ANSI-136/41 MSC, the IIF converts it to a MAP_FSM_ACK, and 8 places the previously stored Originating Service Center address in the Destination Address. 9 See Table 122. 10
Table 122: Forward Short Message to SMDPP for Mobile Terminated GHOST/WEMT 11 Teleservice Parameter Mapping in ANSI Foreign Mode 12
MT FSM Status SMDPP Status
MSID R SM-RP-DA =
IMSI
M
SMS-Original_Destination-Address = MSID
O
SM-RP-OA =
Service center address OA
M SMS_Originating Address = IIF Address . See 4.5.2.4
O
SM-RP-UI M SMS_BearerData M
- SMS_Teleservice Identifier = GHOST or WEMT
M
More Messages to Send C - -
ESN (Not used)
SMS_Charge Indicator (Not used)
SMS_Destination Address (Not used)
SMS_Message Count (Not used)
SMS_Notification Indicator (Not used)
SMS_Original Originating Address (Not used)
SMS_OriginalDestinationAddress (Not used)
SMS_Original Destination Sub Address (Not used)
13
14
4.5.2.2.5 SMS Origination for an ANSI-136 41 Subscriber in GSM Foreign Mode 15
16
N.S0028
157
When the IIF receives a MAP_FSM originated from a MS roaming in a GSM network, it stores 1 the VMSC address locally and replaces the VMSC address in the outgoing SMDPP message 2 by the E.164 address of the IIF (placed in the SCCP Calling Party Address). Upon receipt of an 3 SMDPP Return Result from the MC, the IIF converts it to a MAP_FSM_ACK and places the 4 previously stored VMSC address in the SCCP Called Party Address. See Table 123. 5
Table 123: Forward Short Message to SMDPP for Mobile Originated GHOST/WEMT in 6 GSM Foreign Mode Parameter Mapping 7
GSM MO FSM Status ANSI SMDPP Status
SM-RP-DA =
Service Center Address DA = IIF Address
M SMS_DestinationAddress= MC Address. See 4.5.2.4
R
SM-RP-OA =
A-MSISDN
M
Note 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 to IIF 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 Sub Address (Not used)
-
SMS_Original Originating Address Sub Address (Not used)
8
Note 1: MSID and ESN are mapped from MSISDN received in SM-RP-OA 9
10
4.5.2.2.6 SMS Origination for a GSM Subscriber in ANSI-136 41 Foreign Mode 11
12
When the IIF receives a SMDPP Invoke originated from a MS roaming in an ANSI-136 41 13 network, it stores the VMSC address locally and replaces the VMSC address in the outgoing 14 MT FSM message by the E.164 address of the IIF (placed in the SCCP Calling Party Address). 15 It also internally maps the TSAF from the SMS_Destination Address into the TSAH and places 16 that value in the RP-Destination Address per 4.5.2.4 Identification of the IIF SS7 Address for 17 Mobile Originated Services. Upon receipt of a MAP_FSM_ACK from the MC, the IIF converts it 18
N.S0028
158
to a SMDPP Return Result and places the previously stored VMSC address in the SCCP 1 Called Party Address. See Table 124. 2
Table 124: SMDPP to Forward Short Message for Mobile Originated GHOST/WEMT 3 Teleservice Parameter Mapping in ANSI-41 Foreign Mode 4
ANSI SMDPP Status GSM MO FSM Status
SMS Bearer Data M SM-RP-UI M
SMS Teleservice ID =GHOST or WEMT
M -
ESN O -
MSID O
(Note 1)
-
SMS_Charge Indicator O -
SMS_Destination Address O SM-RP-DA: Service Center Address (retrieved from mapping in IIF database). See 4.5.2.4
M
SMS_Message Count O -
SMS_Notification Indicator O -
SMS_Original Destination Address
O -
SMS_Original Destination Sub Address
O -
SMS_Original Originating Address
(A-MSID)
O SM-RP-OA (A-MSISDN) M
SMS_Original Originating Address Sub Address
O -
SMS_Originating Address O -
Note 1: If MSID is received it should be the same as the SMS_OriginalOriginating Address 5
6
GHOST shall use the HLPI shown below. TSAR may or may not be applied to the GHOST 7 teleservice. 8
Table 125: HLPI for GHOST 9
HLPI Subfield Coding
Teleservice Type Indicator Subfield 0 - Standardized Teleservice
Teleservice Segmentation and Reassembly Subfield
May or may not have TSAR sub-layer
0 - No TSAR
1 - TSAR is being used
Teleservice Protocol Identifier Subfield 000111
10
N.S0028
159
4.5.2.3 Error Handling 1
2
4.5.2.3.1 Error handling at the reception of a Forward Short Message in the IIF 3
4
Refer to 4.5.1.3 Error Handling 5
4.5.2.3.2 Error handling at the reception of a SMDPP message in the IIF 6
7
Refer to 4.5.1.3 Error Handling 8
4.5.2.3.3 Cause Code Mapping at the IIF 9
10
At the IIF, the ANSI-41 SMS_CauseCode is mapped to a return error in the GSM 11 MAP_FSM_ACK message according to Table 117 12
The IIF is responsible for mapping GSM MAP_FSM_ACK Return Errors to ANSI-41 13 SMS_CauseCodes according to 14
15
16
17
Table 116. 18
19
4.5.2.4 Identification of the IIF SS7 Address for Mobile Originated Services 20
21
The following SS7 address mapping scheme is defined in order to resolve the ambiguity that 22 occurs when a roaming subscriber attempts to invoke mobile originated teleservices. 23 Specifically, instead of using only a single Teleservice Server Address (TSA) as the SS7 SCCP 24 Called Party Address, a pair of E.164 addresses are defined for each Teleservice Server 25 Address Center (e.g., MC or SMSC). This pair of addresses (native and foreign mode TSAs) is 26 used to enable the routing of incoming messages to the IIF from the serving foreign network, 27 while messages that originate in a network that uses the same technology as the home network 28 bypass the IIF and are routed directly to the MC. The native mode address can be translated 29 using global title translation to the actual SS7 address (DPC and SSN) of the MC while the 30 foreign mode address is a virtual address that points (via global title translation) to the IIF. 31 There is a one-to-one mapping in the IIF between the home and foreign mode addresses for 32 each MC, as shown in Table 126. Note that there is a many-to-one relationship between the 33 virtual addresses and the actual IIF address. 34
While roaming in foreign mode, the mobile station uses the foreign mode address in order to 35 ensure that messages are first routed to the IIF. The IIF performs message translation, and 36 inserts the native mode address, i.e., an E.164 number that is translatable by the network to the 37 actual MC destination SS7 address. 38
N.S0028
160
Table 126: Teleservice Server Address Mapping in IIF 1
Home Technology Address Foreign Technology Address
TSAH1 ↔ TSAF1
TSAH2 ↔ TSAF2
TSAH3 ↔ TSAF3
2
3
N.S0028
161
1
4.5.3 Message Waiting Notification 2
3
The Message Waiting Notification procedure is used to notify a mobile subscriber of voice mail 4 messages added or removed in his voice mail system. 5
6
4.5.3.1 Detailed Procedures 7
The following procedures are applicable at the IIF for Message Waiting Notification. 8
9
GSM Foreign Mode 10
Two events can trigger the sending of updated MWN information by the IIF to the serving GSM 11 MSC/VLR, when an ANSI-136 41 native subscriber is roaming in GSM Foreign Mode. 12
13
4.5.3.1.1 Registration Notification Return Result with MWN Information Received 14
15
When the ANSI-136 41 native subscriber registers in a GSM MSC/VLR, a GSM 16 MAP_UPDATE_LOCATION message is received at the IIF. This shall trigger an ANSI MAP 17 REGISTRATION_NOTIFICATION message to be sent by the IIF to the TDMA ANSI-41 home 18 HLR. 19
If the IIF receives a Registration Notification Return Result message with MWNCOUNT and 20 MWNTYPE parameters set to valid values, it shall set the Message Waiting Notification flag 21 and it shall send a GSM MAP_INSERT_SUB_DATA message(s) to the GSM MSC/VLR from 22 which it had received a previous GSM MAP_UPDATE_LOCATION message. 23
The IIF shall also send an Update Location acknowledge message and send it to the GSM 24 MSC/VLR. 25
The IIF shall then format and send a GSM MAP_FORWARD_SHORT_MESSAGE. Refer to 26 Table 129 for the mapping of parameters from ANSI-Regnot return result to GSM MAP 27 _FORWARD_SHORT_MESSAGE. 28
If a successful response is received for the FSM, the IIF shall clear the Message Waiting 29 Notification flag. 30
If the response to FSM indicates that the receiving node does not support MAP V2, the 31 GSM_FSM message shall be reformatted in MAP V1 and sent again. 32
If the response to FSM indicates an error condition, or if a time out occurs, the MWN 33 information is sent in a new GSM MAP _FORWARD_SHORT_MESSAGE when the IIF 34 receives a new GSM MAP _UPDATE_LOCATION, GSM MAP 35 _READY_FOR_SHORT_MESSAGE or GSM MAP _NOTE_MS_PRESENT message. 36
37
4.5.3.1.2 Qualification Directive Invoke Received 38
39
N.S0028
162
If the IIF receives a QUALDIR INVOKE message from the TDMA ANSI-41 HLR with 1 MWNCOUNT and MNWTYPE parameters set to valid values, it shall set the Message waiting 2 Notification flag and it shall send a GSM MAP FORWARD_SHORT_MESSAGE. Refer to Table 3 130 for the mapping of parameters between ANSI-QUALDIR and GSM-4 _MAP_FORWARD_SHORT_MESSAGE. 5
If an error is detected in the QUALDIR INVOKE message, a Reject or Return Error message is 6 sent back to the sending node. No other processing is executed. 7
If a successful response is received for the FSM, the IF shall clear the Message Waiting 8 Notification flag. 9
If the error in the response to FSM indicates that the receiving node does not support MAP V2, 10 the GSM_FSM message shall be reformatted in MAP V1 and sent again. 11
If an error is received in the response to FSM, or if a time out occurs, the MWN information is 12 sent in a new GSM MAP _FORWARD_SHORT_MESSAGE when the IIF receives a new GSM 13 MAP _UPDATE_LOCATION, GSM MAP _READY_FOR_SHORT_MESSAGE or GSM MAP 14 _NOTE_MS_PRESENT message. 15
16
ANSI-136 41 Foreign Mode 17
Two methods of delivering Message Waiting Notification to a native GSM subscriber roaming in 18 ANSI-136 41 are supported. 19
20
4.5.3.1.3 GSM SMS Mapped to ANSI-41 Qualification Directive Invoke 21
22
If the IIF receives a GSM_FORWARD_SHORT_MESSAGE with MWN information, it shall set 23 the message waiting Notification flag and it shall format and send an ANSI_MAP_ QUALDIR 24 message to the serving ANSI-41 MSC/VLR. Refer to Table 131 for the mapping of parameters 25 from GSM MAP _FORWARD_SHORT_MESSAGE to ANSI_QUALDIR. 26
When the IIF receives a positive acknowledgment to the Qualification Directive message, it 27 shall send an acknowledgment to the Forward Short Message with an error indication of 28 “absent subscriber”. This shall ensure that the MWN information is delivered again from the 29 home system when the subscriber returns home. 30
If the MS registers in a different ANSI-41 MSC/VLR after some time, the MWN information is 31 delivered in the Registration Return Result message 32
If the IIF detects errors in the FORWARD_SHORT_MESSAGE, an error indication is sent in the 33 response message. This shall cause the GSM MSC/VLR to send an error indication to the GSM 34 Message Center. 35
If a Return Error or Reject is received in response to the ANSI_MAP Qualification Directive 36 INVOKE, the error code is mapped into the corresponding Forward Short Message error code 37 as described in Table 135. 38
39
N.S0028
163
1
4.5.3.1.4 GSM SMS Mapped to TDMAANSI-41 SMS using GHOST or WEMT 2
3
If the IIF receives GSM MAP _FORWARD_SHORT_MESSAGE for a mobile that is GHOST or 4 WEMT capable, it shall send an ANSI_MAP Short Message Delivery Point to Point INVOKE 5 message. Refer to Table 132 for the mapping of parameters from GSM MAP 6 _FORWARD_SHORT_MESSAGE to ANSI-SMDPP. 7
When the Return Result for the SMDPP is received, the IIF sends back a positive 8 acknowledgement to the Forward Short Message. 9
10
If the IIF detects errors in the FORWARD_SHORT_MESSAGE, an error indication is sent in the 11 response message. This shall cause the GSM MSC/VLR to send an error indication to the GSM 12 Message Center. 13
If a Return Error or Reject is received in response to the ANSI_MAP Short Message Delivery 14 Point to Point INVOKE, the error code is mapped into the corresponding Forward Short 15 Message error code as described in Table 117. 16
17
4.5.3.2 Mapping of Messages, Parameters & Parameter Values 18
19
The IIF shall perform the mapping of messages, parameters and parameter values related to 20 message waiting notification in accordance with the tables presented. Within the following 21 tables, the parameters are identified as either being Mandatory (M), Conditional (C), Service 22 Provider Optional (O) or Service User Optional (U) in accordance with the definitions given in 23 GSM 09.02 [3] and ANSI-41 [6], [7], 0. 24
Table 127 shows the mapping between ANSI MAP messages and GSM MAP messages 25 related to Message Waiting Notification in GSM Foreign ModeTable 128 shows the mapping 26 between GSM MAP messages and ANSI MAP messages related to Message Waiting 27 Notification in ANSI-136 41 Foreign Mode. 28
Table 127: Message Waiting Notification in GSM Foreign Mode Message Mapping 29
ANSI MAP Messages GSM MAP Messages
Regnot FORWARD_SHORT_MESSAGE
QUALDIR FORWARD_SHORT_MESASGE
30
Table 128: Message Waiting Notification in ANSI-136 41 Foreign Mode Message Mapping 31
GSM MAP Messages ANSI MAP Messages
FORWARD_SHORT_MESSAGE QUALDIR
FORWARD_SHORT_MESSAGE SMDPP
32
N.S0028
164
When the IIF receives either a GSM MAP message or an ANSI MAP message, it shall apply 1 the following rules regarding the handling of parameters within those messages: 2
The IIF shall populate mandatory parameters in messages sent by the IIF, regardless of 3 whether mapping of parameters is possible. 4
The IIF may populate optional parameters in messages sent by the IIF, regardless of whether 5 mapping of parameters is possible. 6
All parameters shall be populated in accordance with either GSM 09.02 [3] or ANSI-41 [6], [7], 7 0. 8
9
Table 129 through Table 134 show the mapping of parameters, which the IIF shall perform 10 regardless of the mode of operation (GSM Foreign Mode or ANSI-136 41 Foreign Mode). 11 Where there is no direct mapping for parameters, a ‘-‘ has been entered in the corresponding 12 table. 13
Table 129: Regnot to Forward Short Message for Message Waiting Notification 14 Parameter Mapping 15
ANSI-41 Regnot Return Result Status GSM MT FSM Status
SM-RP-DA = IMSI M
SM-RP-OA = IIF address M
MWNCount (from Profile) O
MWNType (from Profile) O
SM-RP-UI
See Table 133 and Table 134 for details of encoding of this parameter.
M
More Messages to Send = no M
Note 1
16
Table 130: QUALDIR to Forward Short Message for Message Waiting Notification 17 Parameter Mapping 18
ANSI-41 QUALDIR GSM MT FSM
MSID SM-RP-DA (M) = IMSI
SM-RP-OA (M) = IIF address
MWNCount (from Profile)
MWNType (from Profile)
SM-RP-UI (M)
See Table 133 and Table 134 for details of encoding of this parameter.
_
More Messages to Send (M) = no
(Note 1)
19
Note 1: This parameter is only valid for MAP V2. 20
21
N.S0028
165
1
Table 131: Forward Short Message to QUALDIR for Message Waiting Notification 2 Parameter Mapping 3
GSM MT FSM Status ANSI QUALDIR Status
M MSID M IMSI
ESN M
_ QualificationInformationCode = Profile only
M
_
SystemMyTypeCode M
M MWNCount (in Profile) R SM-RP-UI
MWNType (in Profile) R
4
Table 132: Forward Short Message to SMDPP for Message Waiting Notification 5 Parameter Mapping 6
GSM MT FSM Status ANSI SMDPP Status
SM-RP-UI (M) M SMS_BearerData M
_ SMS_TeleserviceIdentifier = GHOST or WEMT
M
Originating Address M SMS-OriginalOriginatingAddress O
M ESN O IMSI
MSID R
7
8
N.S0028
166
1
Table 133: SM-RP-UI in Message FORWARD-SHORT-MESSAGE For MAP V2 Parameter 2 Encoding 3
FIELD VALUE ENCODING METHOD
Message Type Indicator
Set to value “SMS-DELIVER” All
More Messages to Send
Set to value “No more messages are waiting for the MS in this SC”
All
Reply Path Set to value “TP-Reply-Path is not set in this SMS-DELIVER”
All
Status Report Indication
Set to value “A status report is not requested”
All
Protocol Identifier Set to value “0” All
Service Center Time Stamp
Created by the IIF All
User Data Length Number of characters All
Originating Address Encoded as follows to support delivering of MWN information for the CPHS encoding method:
- First octet: Set value to 00000100 (address length).
- Second octet: Type of address. Bit 7 set to value 1, bits 654 set to value 101 (alphanumeric) and bits 3210 set to value 0000 (numbering plan id).
- Third octet: First address value. Set bit number 0 to value 1 to enable and value 1 to disable indication. Set bits 321 with value 000 (voice message waiting indicator). 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
4
5
N.S0028
167
1
Table 133: SM-RP-UI in Message FORWARD-SHORT-MESSAGE For MAP V2 Parameter 2 Encoding (concluded) 3
FIELD VALUE ENCODING METHOD
Data Coding Scheme - Set bit numbers 7654 to discard (value 1100) message.
- Set bit number 3 to enable (1) or disable indication (0).
- Set bit number 2 to 0.
- Set bit numbers 10 to Mail Message Indication (value 00).
DCS
User Data Header Indicator
parameter (one bit) indicating that the UD
field contains a Header. Set to value “The beginning of the TP-UD field contains a Header in addition to the short message”.
UD
User Data one space character using the default alphabet
UD
User Data Header - First octet: Length of the User Data Header.
- Second octet: Information Element Identifier (IEI) = Special SMS Message Indication (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 (Voice Message Waiting).
- Fifth octet: Number of messages waiting.
- Rest of octets: Beginning of short message
UD
4
5
N.S0028
168
1
Table 134: SM-RP-UI in Message FORWARD_SHORT-MESSAGE for MAP V1 Parameter 2 Encoding 3
FIELD VALUE ENCODING METHOD
Message Type Indicator Set to value “SMS-DELIVER” All
More 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 All
User Data Length Number of characters All
User Data one space character using the default alphabet
All
Originating Address Encoded as follows to support delivering of MWN information for the CPHS encoding method:
- First octet: Set value to 00000100 (address length).
- Second octet: Type of address. Bit 7 set to value 1, bits 654 set to value 101 (alphanumeric) and bits 3210 set to value 0000 (numbering plan id).
- Third octet: First address value. Set bit number 0 to value 1 to enable and value 0 to disable indication. Set bits 321 with value 000 (voice message waiting indicator). 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 (value 1100) message.
- Set bit number 3 to enable (1) or disable indication (0).
- Set bit number 2 to 0.
- Set bit numbers 10 to Mail Message Indication (value 00).
DCS
4
5
N.S0028
169
1
4.5.3.3 Error Handling 2
3
4.5.3.3.1 Error Handling at the Reception of a Forward Short Message 4
5
Refer to 4.5.1.3 Error Handling 6
4.5.3.3.2 Error Mapping from ANSI QUALDIR to GSM FSM 7
8
Table 135: qualdir return error to FORWARD_SHORT_MESSAGE response Error 9 Mapping 10
QUALDIR (Errors) FORWARD_SHORT_MESSAGE
Unrecognized MSID SMS Delivery Failure
Unrecognized ESN SMS Delivery Failure
ResourceShortage SMS Delivery Failure
OperationNotSupported SMS Delivery Failure
ParameterError SMS Delivery Failure
SystemFailure SMS Delivery Failure
UnrecognizedParameterValue SMS Delivery Failure
MissingParameter SMS Delivery Failure
11
4.5.3.3.3 Error Mapping from ANSI SMSDPP to GSM FSM 12
13
Table 136: SMSDPP to FORWARD_SHORT_MESSAGE response Error Mapping 14
SMSDPP (Cause Code) FORWARD_SHORT_MESSAGE
Destination Busy Subscriber Busy for MT-SMS
Address Vacant Absent Subscriber
No Pager Response Absent Subscriber
No Acknowledgement Absent Subscriber
Destination Out of Service Absent Subscriber
Destination No Longer at this Address Absent Subscriber
SMS Delivery Postponed Absent Subscriber
Any other value System Failure
15
16
N.S0028
170
4.6 GPRS in GSM Foreign mode 1
2
The following text describes the procedures in the IIF for the case in which an ANSI-136 41 3 subscriber requests GPRS service while operating in GSM foreign mode. 4
Note: There is no GPRS service for GSM subscribers roaming in an ANSI-136 41 radio 5 environment. 6
4.6.1 Mobility Procedures 7
8
Existing mobility procedures described in either GSM 09.02 [3] or ANSI-41 [6] are also directly 9 applicable to the IIF when it is emulating a GSM or ANSI-41 functional network element. 10 Enhancements and modifications to GSM 02.60 [4] and ANSI-41 [7], 0 are also applicable. 11
12
4.6.1.1 Detailed Procedures 13
14
The following text contains the procedures in the IIF for the case in which the ANSI-41 15 subscriber requests GPRS services while roaming in foreign mode (i.e., while roaming in a 16 GSM network). 17
4.6.1.1.1 GPRS Location Updating 18
19
The IIF contains location information (SGSN number) relating to the roaming subscriber. 20 Therefore, the IIF needs to be updated at each change in SGSN. The IIF shall translate GSM 21 MAP messages to ANSI-41 MAP messages and vice versa when the subscribers home ANSI-22 41 HLR needs updating. The subscriber’s ANSI-41 HLR shall be updated in the following 23 cases: 24
• When the subscriber’s MS registers in an SGSN in a GSM network, when previously 25 registered in an ANSI-41 network; 26
• When the subscriber’s MS registers in an ANSI-41 network, when previously registered in 27 an SGSN in a GSM network; 28
The subscriber’s home HLR may be updated in the following cases: 29
• When the subscriber’s MS (accessing a GSM Network) registers in another SGSN within 30 the same GSM network. The IIF acts like a GPRS HLR/AuC in this case. 31
• When the subscriber’s MS (accessing a GSM network) registers in a SGSN when 32 previously registered in a GSM VLR within the same GSM network. 33
When the HLR is updated, the IIF conveys a unique identifier to the ANSI-41 HLR identifying 34 the SGSN/GSM VLR or IIF, depending on Multiple MSCIDs optional support. 35
If the IIF receives a GSM_ MAP_UPDATE_GPRS_LOCATION _REQUEST, it shall compare 36 the received routing area information with any previously stored routing area information. If the 37 received and previously stored routing area information are different, the IIF shall determine if 38 the location updating is allowed and update the corresponding subscriber record accordingly 39
N.S0028
171
and send a GSM MAP _CANCEL_LOCATION_REQUEST to the old SGSN. If there is no 1 previously SGSN stored routing area information in the IIF, the IIF shall determine if the location 2 updating is allowed and update the corresponding subscriber record accordingly. 3
If the IIF receives a GSM MAP _MS_PURGE_REQUEST, it shall check the contents of the 4 message for errors. If errors exist, the IIF shall send a GSM MAP _MS_PURGE_RESPONSE 5 indicating the reason for failure and the MS purged flag shall not be set. If no errors exist, the 6 IIF shall check if the received SGSN number matches the stored SGSN number. 7
If the received SGSN number and the stored SGSN number match, the IIF shall set the MS 8 purged flag and shall send both a GSM MAP _MS_PURGE_RESPONSE to the SGSN and an 9 ANSI_MAP_MS_INACTIVE to the ANSI-41 HLR and awaits a response from the HLR. 10
If the received SGSN number and the stored SGSN number do not match, the IIF sends a GSM 11 MAP _PURGE_MS_RESPONSE containing an empty result to indicate that the MS purged flag 12 is not set. 13
If the MS requests a combined GSM and GPRS attach, then the SGSN requests a GPRS 14 location update to the IIF (acting as a GPRS HLR) and then the GSM-MSC requests a CS 15 location update. CS location update and mobility procedures are described in 4.1 Mobility 16 Procedures. 17
18
4.6.1.2 Mapping of Messages, Parameters & Parameter Values 19
20
The following tables present the mapping of presents the mapping of messages, parameters 21 and parameter values that the IIF shall perform. 22
23
4.6.1.2.1 Mapping of Messages 24
25
Table 137 shows the mapping between GSM MAP messages and ANSI MAP messages 26 related to GPRS Location Registration when necessary. 27
Table 137: Location Updating GPRS in GSM Foreign Mode Message Mapping 28
GSM MAP Messages ANSI MAP Messages
MAP_UPDATE_GPRS_LOCATION_REQUEST REGNOT
MAP_INSERT_SUBSCRIBER_DATA_REQUEST1 regnot
MAP_UPDATE_GPRS_LOCATION_RESPONSE regnot2
29
1This procedure is used to download GPRS subscriber data to the SGSN. 30 2This message can also contain error values if the location updating procedure is unsuccessful. 31 If the location updating procedure fails, the mapping is as shown in 4.1.1.3. 32
Table 3 shows the mapping between GSM MAP messages and ANSI MAP messages for MS 33 Purge operation. Table 4 shows the mapping between GSM MAP messages and ANSI MAP 34 messages related to Location Cancellation. 35
36
N.S0028
172
4.6.1.2.1.2 Mapping of Parameters 1
2
The following tables show the mapping between the parameters in GSM MAP messages and 3 parameters in the corresponding ANSI-41 messages when necessary. 4
Table 138: MAP_UPDATE_GPRS_LOCATION_REQUEST →→→→ REGNOT Parameter Mapping 5
GSM MAP _UPDATE_GPRS_LOCATION_REQUEST
Status ANSI_MAP_REGNOT Status
ElectronicSerialNumber M IMSI M
MSID M
SGSN address M MSCID (Serving MSC)1 M
SGSN Number M -
QualificationInformationCode M
- SystemMyTypeCode M
- MSCIdentificationNumber O
- PC_SSN (Serving MSC or VLR) O
- SystemAccessType2 O
- TerminalType2 O
- TransactionCapability2 O
6
1This parameter is used to convey an identity from the IIF to the ANSI-41 HLR identifying either 7 the SGSN or the IIF. In the case where the IIF supports multiple MSCIDs this identity is a 8 unique identity associated with the SGSN. Otherwize, the identity shall be that of the IIF. 9
2Parameters are included in ANSI-41-C and later. 10
11
N.S0028
173
1
Table 139 shows the mapping of parameters for GSM MAP 2 _INSERT_SUBSCRIBER_DATA_REQUEST to Regnot when necessary. 3
Table 139: MAP_INSERT_SUBSCRIBER_DATA_REQUEST →→→→ regnot Parameter Mapping 4
GSM MAP _INSERT_SUBSCRIBER_DATA_REQUEST
Status regnot Status
- SystemMYTypeCode (VLR or HLR)
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 O
IMSI C -
5
6 1This parameter is itself a macro containing a number of other parameters. As far as mapping 7 of parameters is concerned, the IIF shall map the contents of the ‘Profile’ macro in the ANSI-41-8 D ‘regnot’ to the contents of the GSM MAP _INSERT_SUBSCRIBER_DATA_REQUEST as 9 shown in Table 140: 10
11
N.S0028
174
Table 140: MAP_UPDATE GPRS LOCATION RESPONSE →→→→ regnot Parameter Mapping 1
GSM MAP _UPDATE_ GPRS_LOCATION_RESPONSE
Status
regnot Status
- SystemMYTypeCode (VLR or HLR)
M
- AuthorizationDenied O
- Authorization Period O
- ControlChannelData O
- DeniedAuthorizationPeriod O
- Digits (Carrier) O
- Digits (Destination) O
HLR number 1, 2 R MSCID (HLR) 2 R
- Profile “Macro”3 O
- ReceivedSignalQuality O
- SenderIdentificationNumber O
- SMS_MessageWaitingIndicator O
- SystemAccessData O
- MSID O 1The presence of this parameter is mandatory in case of successful HLR updating. 2 2These parameters are used to convey a unique identifier from the IIF to the serving MSC/VLR, 3 identifying the HLR. 4 3This parameter is itself a macro containing a number of other parameters. As far as mapping 5 of parameters is concerned, the IIF shall map the contents of the ‘Profile’ macro in the ANSI-41-6 D ‘regnot’ to the contents of the GSM MAP _INSERT_SUBSCRIBER_DATA_REQUEST as 7 shown in Table 92. 8
9
As far as mapping of parameters is concerned, the IIF shall map the contents of the ‘Profile’ 10 macro in the ANSI-41-D GSM MAP _INSERT_SUBSCRIBER_DATA_REQUEST as shown in 11 Table 141: 12
13
N.S0028
175
1
Table 141: MAP_INSERT_SUBSCRIBER_DATA_REQUEST →→→→ profile ‘macro’ Mapping 2
MAP_INSERT_SUBSCRIBER_DATA_REQUEST
Status regnot Status
IMSI C MSID M
- AuthenticationCapability
O
MSISDN C MobileDirectoryNumber O
Category C -
Subscriber Status C -
Bearer service List C -
Teleservice List C
Forwarding information List C CallingFeaturesIndicator1 O
- CarrierDigits O
- DMH_AccountCodeDigits O
- DMH_AlternateBillingDigits O
- DMH_BillingDigits O
Regional Subscription Data C -
- GeographicAuthorization O
- MessageWaitingNotificationCount O
- MessageWaitingNotificationType O
Call barring information List3 C OriginationIndicator2 O
VLR CAMEL Subscription Info4 C OriginationTriggers4 O
- PACAIndicator O
CUG information List C -
SS-Data List C6 CallingFeaturesIndicator1 O
EMLPP Subscription Data C -
Operator Determined Barring General data
C OriginationIndicator2 O
Operator Determined Barring HPLMN data5
C OriginationIndicator2 O
Operator Determined Barring HPLMN data5
C RestrictionDigits O
Roaming Restriction Due To Unsupported Feature
C -
- RoutingDigits O
Call barring information List3 C SMS_OriginationRestrictions7 O
Call barring information List3 C SMS_TerminationRestrictions8 O
- SPINIPIN O
- SPINITriggers O
N.S0028
176
1
2
Table 141: MAP_INSERT_SUBSCRIBER_DATA_REQUEST →→→→ macro profile Mapping 3 (concluded) 4
MAP_INSERT_SUBSCRIBER_DATA_REQUEST
Status ‘profile’ macro Status
Call barring information List3 C TerminationRestrictionCode O
VLR CAMEL Subscription Info C TerminationTriggers4 O
Voice Broadcast Data C
Voice Group Call Data C -
- PreferredLanguageIndicator O
SS-Data List6 SMS_OriginationRestrictions7 O
SS-Data List6
SMS_TerminationRestrictions8 O
North American Equal Access preferred Carrier Id
U -
Roaming Restricted In SGSN Due To Unsupported Feature9
C -
GPRS Subscription Data10 C -
Network access mode11 C -
5 1The CallingFeaturesIndicator parameter provides a status of several ANSI supplementary 6 services. This information may map into one or more GSM MAP parameters as shown in Table 7 92. 8 2The OriginationIndicator parameter defines the type of calls that a MS is allowed to make. 9 This information may map into one or more GSM MAP parameters as shown in Table 92. 10
3The Call barring information List is a list of the call barring supplementary services that are 11 either active, quiescent or not active for individual or all teleservices. This information may map 12 into one or more ANSI MAP parameters as shown in Table 92. 13
4 Camel/WIN interworking is out of the scope of this version of the standard. 14 5Operator Determined Barring HPLMN data may map into one or more ANSI MAP parameters 15 as shown in Table 92. 16
6The SS-Data List may map into one or more ANSI MAP parameters as shown in Table 92. 17 7The SMS_OriginationRestrictions may map into one or more GSM MAP parameters as shown 18 in Table 92. 19 8The SMS_TerminationRestrictions may map into one or more ANSI MAP parameters as 20 shown in Table 92. 21
9The IIFmay decide to include this parameter in the request if certain services or features are 22 indicated as not supported by the SGSN. This parameter is used only by the SGSN. 23 10This parameter contains a list of PDP-contexts a user has subscribed to. At GPRS location 24 updating the IIF shall include the complete GPRS Subscription Data. When there is a change in 25
N.S0028
177
GPRS subscriber data the IIF shall include only the new and/or modified PDP contexts. When 1 the SGSN receives GPRS Subscription Data it shall check if the received data has to be 2 considered as the entire GPRS subscription data. If so, it shall replace the stored GPRS 3 Subscription Data with the received data set, otherwise it shall replace the data only for the 4 modified PDP contexts (if any) and add the new PDP contexts (if any) to the stored GPRS 5 Subscription Data. If GPRS Subscription Data is omitted in the Insert Subscriber Data operation 6 the SGSN shall keep the previously stored GPRS Subscription Data.If the SGSN detects that 7 there is overlapping in the information received within a dialogue, it shall send the error 8 Unexpected Data Value. This parameter is used only by the SGSN. 9
11This parameter defines the access capabilities of a registered MS. 10
Error handling, Fault Recovery procedures and Error Code mapping are described in 4.1 11 Mobility Procedures. 12
4.6.2 Automatic Call Delivery 13
14
The Automatic Call Delivery procedure is invoked in the IIF, when a terminating call attempt 15 results in a request for routing information from the IIF. 16
The following procedures are applicable at the IIF for GPRS in GSM Foreign mode Automatic 17 Call Delivery: 18
19
4.6.2.1 Detailed Procedures 20
21
If the IIF receives an ANSI MAP_RoutingRequest Invoke message from the ANSI-41 HLR, it 22 shall check if the terminating call can be placed to that subscriber. Call delivery to an MS that is 23 roaming in a GPRS network in GSM foreign mode shall be delivered only if the subscriber is 24 registered with a GSM serving MSC/VLR. As such, the IIF (acting as a GSM HLR) sends the 25 GSM serving MSC/VLR a MAP Provide Roaming Number (PRN) see 4.2.1 Call Delivery. 26
27
If the MS is attached for GPRS-only services, incoming calls are not deliverable to the 28 subscriber. Upon the reception of ROUTEREQ, the IIF determines if the MS is attached for 29 GPRS-only services and if so, the IIF shall not deliver the call. The IIF sends a routreq with the 30 field “AccessDeniedReason” set to “No Page Response” or “Unavailable”. 31
4.6.2.1.1 Mapping of Messages, Parameters & Parameter Values 32
33
In this case, the IIF has the calling party DN available (from the ROUTEREQ message). Upon 34 the reception of a ROUTREQ, if the MS is only GPRS attached, the IIF proceeds to act as an 35 SMS-SC and sends an FSM to the SGSN requesting the SGSN to deliver an SMS message 36 containing the calling party’s DN to the MS. The mapping of parameters is shown in the 37 following table: 38
39
40
N.S0028
178
Table 141 A: ROUTREQ →→→→ MT_Forward Short Message Parameter Mapping 1
ROUTREQ Status MT_Forward Short Status
BillingID (Originating) M -
ElectronicSerialNumber M -
MobileStationIDentity M
SM-RP-DA = IMSI
M
- SM-RP-OA = IIF address in international format. See 4.5.2.4
M
MSCID (Originating MSC) M
- More Messages to Send = no M
SystemMyTypeCode (Originating MSC)
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 -
RedirectingNumberString O -
2
3
4
5
6
N.S0028
179
Table 141 A : ROUTREQ →→→→ MT_Forward Short Message Parameter Mapping (concluded) 1
ROUTREQ Status MT_Forward Short Status
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 Announcement
C
- 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 Identification 3 Presentation/Restriction”. 4
Note 2: May also be directly retrieved from the subscriber profile pre-provisioned in the IIF. 5
6
4.6.2.1.1.1 Error Code Mapping 7
8
Appropriate errors for an MS attached to both GPRS and non-GPRS services are described in 9 4.2.1.3 10
11
Appropriate AccessDeniedReason parameter values in the RoutingRequest Return Result for 12 the case of a call delivery attempt to an MS attached for GPRS-only services: 13
14
AccessDeniedReason
Unavailable
No page Response
15
N.S0028
180
4.6.3 Short Message Procedures for ANSI-136 41 subscriber 1
The following describes the procedures for MS terminated and MS originated SMS while the 2 MS is roaming in a GPRS network in GSM foreign mode and is GPRS attached. 3
Existing mobility procedures described in either GSM 09.02 [3] and GSM 03.60 [5] or ANSI-41 4 [6], [7], 0 are also directly applicable to the IIF when it is emulating a GPRS, GSM or ANSI-41 5 functional network element. 6
If the MS is both GSM CS attached as well as GPRS attached, then the IIF shall act as a GSM 7 SMS-SC. 8
4.6.3.1 Short Message Service via CMT 9
10
The Short Message Service procedure is used to deliver short text messages to and from 11 mobile subscribers. 12
4.6.3.1.1 Detailed Procedures 13
14
The following procedures are applicable at the IIF for Short Message Service. Mobile 15 Terminating SMS and Mobile Originated SMS using the CMT teleservice ID are described. 16
17
4.6.3.1.1.1 Mobile Terminating SMS 18
19
If the IIF receives an ANSI-41 Short Message Delivery Point to Point message it shall check if 20 the MS location is known and if the subscriber is reachable. If both conditions are true, the IIF 21 shall format and send a GSM_ MAP_FORWARD_SHORT_MESSAGE (FSM) to the SGSN 22 serving the mobile. Refer to Table 109 for the mapping of parameters from ANSI_SMDPP to 23 GSM MAP _FORWARD_SHORT_MESSAGE. 24
If a successful response is received for the FSM, the IIF shall return SMDPP Return Result 25 message. If the MS's location is not known, or if the MS is not reachable or if the response to 26 the FSM indicates the short message was not delivered to the mobile, the IIF shall set the SMS 27 Delivery Pending flag for the subscriber. The IIF shall then return an SMDPP Return Result 28 message with an appropriate SMS_CauseCode value. Refer to 4.5.1.3 Error Handling for the 29 values of SMS_CauseCode returned. 30
If errors are detected when the SMDPP is received, the message may be rejected if it cannot 31 be processed or if mandatory parameters are missing. Otherwise, the IIF shall return a SMDPP 32 Return Result message with the appropriate SMS_CauseCode value. Refer to 4.5.1.3 Error 33 Handling for the description of error conditions and corresponding SMS_CauseCode values. 34
N.S0028
181
If the response to FSM indicates a failure in the delivery of the short message, the IIF 1 shall map the cause value received to a corresponding SMS_CauseCode value in the 2
SMDPP Return Result, as described in 3
4
5
6
Table 116. 7
8
4.6.3.1.1.2 Alerting for GPRS in GSM Foreign Mode in either CMT or GHOST/WEMT 9 format 10
11
The SMS Alert procedure is used for alerting the SGSN when the MS is available for short 12 messaging after a short message transfer has failed because the mobile subscriber is not 13 reachable or when the MS has indicated that it has no memory capacity to accept a short 14 message. 15
Upon receipt of a READY_FOR_SM message, the IIF shall store the originating SGSN address 16 and Invoke ID in the subscriber’s profile. It shall map the GSM_READY_FOR_SM message to 17 the ANSI_SMSNOT INVOKE message as described in Table 119. 18
It shall populate the SMS_Address parameter with the IIF address. All other parameters are 19 ignored. 20
The ANSI_SMSNOT INVOKE is then transmitted to the subscriber’s SGSN with local 21 Transaction ID. Finally, the IIF shall return a READY_FOR_SM_ACK message with no 22 arguments to the originating SGSN. 23
Upon receipt of a SMSNOT RR message, the IIF shall associate the SMSNOT Transaction ID 24 with the Invoke ID. 25
If the IIF receives a GSM MAP _READY_FOR-SHORT_MESSAGE and the Delivery pending 26 flag is set for the subscriber, the IIF shall send an ANSI_MAP_SMS_NOTIFICATION message 27 to the home Message Center. The IIF shall clear the MNRG flag if Alert Reason is set to MS 28 present or The Memory Capacity Exceeded Flag (MCEF) flag if Alert Reason is set to Memory 29 Available and the flags were previously set. If the Alert Reason indicates the mobile present for 30 non GPRS situation, or when the update location procedure has been successfully completed 31 or Supplementary Service Control request is received, the MS not reachable flag (MNR) is 32 cleared and the service centre alert procedure is initiated. If the memory capacity exceeded flag 33 is set, the MS not reachable flag is cleared and stored reason for absence for non GPRS are 34 cleared but the alert procedure is not started. If the Alert Reason indicates the mobile present 35 for GPRS situation, or when the Update GPRS location procedure has been successfully 36 completed, the MS not reachable for GPRS (MNRG) flag is cleared and the service centre alert 37 procedure is initiated. The mapping of parameters is described in Table 142. 38
The ANSI-41 MC shall re-send message SMDPP to deliver the short message to the subscriber. 39
40
N.S0028
182
1
Table 142: Alerting for an ANSI-136 41 Subscriber for GPRS in GSM Foreign Mode 2 Parameter Mapping 3
GSM MAP _READY_FOR_SM Status ANSI_SMSNOT Status
ESN M IMSI M
MSID M
Alert Reason M -
Alert Reason Indicator 1 C
SMS_Address (IIF Address) R 1This parameter indicates that the alert reason is sent to the HLR due to GPRS activity. 4
5
4.6.3.1.1.3 Mobile Originating SMS for GPRS in GSM Foreign Mode 6
7
If the IIF receives a GSM_FORWARD_SHORT_MESSAGE for a mobile originated short 8 message, it shall format and send an ANSI_MAP_SMDPP message to the home Message 9 Center. Refer to Table 114 for the mapping of parameters from GSM MAP 10 _FORWARD_SHORT_MESSAGE to ANSI_SMDPP. 11
If the IIF receives a positive acknowledgment to the SMDPP message, it shall send a positive 12 acknowledgment to the Forward Short Message. 13
If the IIF receives a negative acknowledgment to the SMDPP message, it shall map the 14 received SMS_CauseCode value into a corresponding error code in the FSM Response 15 message as described in Table 117. Also the IIF shall set the Mobile Not Reachable for GPRS 16 (MNRG) GSM SMS flag. 17
If the IIF detects errors in the FORWARD_SHORT_MESSAGE, an error indication is sent in the 18 response message. Refer to 4.5.1.3 for the handling of errors at the reception of FSM. 19
20
N.S0028
183
1
4.6.3.1.2 Mapping of Messages, Parameters & Parameter Values 2
3
The IIF shall perform the mapping of messages, parameters and parameter values related to 4 Short Message Service in accordance with the tables presented in 4.5.1.2.1. 5
4.6.3.1.3 Error Handling 6
7
Error handling is described in 4.5.1.3 8
4.6.4 Short Message Service via GHOST or WEMT 9
10
4.6.4.1 Detailed Procedures 11
12
4.6.4.1.1 SMS Delivery for an ANSI-136 41 Subscriber for GPRS in GSM Foreign 13 Mode 14
15
Upon receipt of an SMSDeliveryPointToPoint INVOKE message, the IIF shall store the 16 originating MC address and transaction ID. It shall map the ANSI_SMDPP message into a 17 GSM_FSM message and populate the subscriber’s known SGSN into the DPC. The IIF 18 transmits the GSM_FSM message with local Invoke ID. 19
The mapping of parameters is described in Table 121. 20
The IIF transmits the GSM_FSM message with local Invoke ID. 21
Upon receipt of the FORWARD_SHORT_MESSAGE_ACK message, the IIF shall associate the 22 Invoke ID with SMDPP transaction ID and map the GSM_FSM_ACK message into an 23 ANSI_SMDPP RETURN RESULT. 24
Next, it populates the stored originating SGSN address into the DPC and populates the 25 transaction ID. 26
If the User Error parameter is populated in the GSM_FSM_ACK, then map this value into 27 the SMS_CauseCode according to 28
29
30
31
Table 116. 32
Finally, the ANSI_SMDPP RR is transmitted to the originator. 33
N.S0028
184
4.6.4.1.2 SMS Origination 1
2
Upon receipt of a MO_FORWARD_SHORT_MESSAGE, the IIF shall store the address of the 3 originating SGSN and Invoke ID. It shall map the GSM_MO_FSM to ANSI_SMDPP INVOKE. 4 The address of the subscriber’s TSA (from the SM RP DA – Service Center Address) is 5 mapped according to 4.5.2.4 into the SMS_DestinationAddress. The IIF transmits the 6 ANSI_SMDPP INVOKE message with local transaction ID. The mapping of parameters is 7 described in Table 123. 8
Upon receipt of a SMSDeliveryPointToPoint RR message, the IIF shall associate the SMDPP 9 transaction ID with Invoke ID and map the ANSI_SMDPP RR to the GSM_FSM_ACK. 10
Next, it populates the stored originating SGSN address and Invoke ID. If SMS_CauseCode 11 parameter is populated in the ANSI_SMDPP RR message, then map value into User error 12 parameter according to Table 117. 13
Finally, transmit the GSM_FSM_ACK to the originating SGSN. 14
4.6.4.2 Mapping of Messages, Parameters & Parameter Values 15
16
The IIF shall perform the mapping of messages, parameters and parameter values related to 17 Short Message Service in accordance with the tables presented in 4.5.2.2. 18
19
4.6.4.3 Error Handling 20
21
Error handling is described in 4.5.1.3 22
4.6.5 Message Waiting Notification 23
24
The Message Waiting Notification procedure is used to notify a mobile subscriber of voice mail 25 messages added or removed in his voice mail system. 4.6.5 shows only the changes needed to 26 support GPRS service for an ANSI-136 41 subscriber in GSM foreign mode. 27
�If the subscriber is both GSM CS attached as well as GPRS attached, then the IIF shall act 28 like a GSM SMS-SC. 29
4.6.5.1 Detailed Procedures 30
4.6.5.1.1 Registration Notification Return Result with MWN Information Received 31
32
When the IIF receives a Registration Notification Return Result message with MWNCOUNT 33 and MWNTYPE parameters set to valid values, it shall send a GSM SMS with the MWN 34 information. 35
The IIF shall then format and send a GSM MAP_FORWARD_SHORT_MESSAGE. Refer to 36 Table 129 for the mapping of parameters from ANSI-41 regnot return result to GSM MAP 37 _FORWARD_SHORT_MESSAGE. 38
N.S0028
185
If a successful response is received for the FSM, the IIF shall clear the Message Waiting 1 Notification flag. 2
If the response to FSM indicates an error condition, or if a time out occurs, the MWN 3 information is sent in a new GSM MAP _FORWARD_SHORT_MESSAGE when the IIF 4 receives a new GSM MAP _UPDATE_GPRS_LOCATION, GSM MAP 5 _READY_FOR_SHORT_MESSAGE or GSM MAP _NOTE_MS_PRESENT message. 6
When the IIF receives a QUALDIR INVOKE message from the ANSI-41 HLR with 7 MWNCOUNT and MNWTYPE parameters set to valid values, it shall set the Message waiting 8 Notification flag and the IIF shall send a GSM MAP FORWARD_SHORT_MESSAGE. Refer to 9 Table 130 for the mapping of parameters between ANSI-QUALDIR and GSM-10 _MAP_FORWARD_SHORT_MESSAGE. 11
If an error is detected in the QUALDIR INVOKE message, a Reject or Return Error message is 12 sent back to the sending node. No other processing is executed. 13
If a successful response is received for the FSM, the IIF shall clear the Message Waiting 14 Notification flag. 15
If an error is received in the response to FSM, or if a time out occurs, the MWN information is 16 sent in a new GSM MAP _FORWARD_SHORT_MESSAGE when the IIF receives a new GSM 17 MAP _UPDATE_GPRS_LOCATION, GSM MAP _READY_FOR_SHORT_MESSAGE or GSM 18 MAP _NOTE_MS_PRESENT message. 19
4.6.5.2 Mapping of Messages, Parameters & Parameter Values 20
21
The IIF shall perform the mapping of messages, parameters and parameter values related to 22 message waiting notification in accordance with 4.5.3.2. 23
4.6.5.3 Error Handling 24
25
Refer to 4.5.1.3 Error Handling 26
27
4.6.5.3.1 Error Mapping 28
29
Refer to 4.5.3.3.2 Error Mapping. 30
31
32
33
34
N.S0028
186
1
2
ANNEX A Short Message Service Procedures 3
within an ANSI-136 Network 4
(Normative) 5
6
GHOST may be used as the delivery teleservice from a short message entity to a mobile 7 station operating in ANSI-136 Native Mode through a SMSC, which is providing IIF functionality 8 at the GSM TP-layer. In this case, normal ANSI-41 procedures are used to deliver the GHOST 9 teleservice between ANSI-41 network elements and normal ANSI-136 procedures are used to 10 deliver the GHOST teleservice from the serving MSC to the mobile station. The SMSC is 11 responsible for identifying the MS as GHOST capable and for packaging the short message in 12 the proper format using the GHOST teleservice for delivery to the MS. 13
14
A.1 CMT to GHOST Delivery 15
16
If the short message entity is an MS originating a message using the Cellular Messaging 17 Teleservice (CMT) teleservice to the GHOST MS, then upon receipt of the CMT message the 18 SMSC proceeds as follows. 19
20
A.1.1 Detailed Procedures 21
22
After determining the incoming CMT message is destined for an MS that supports the GHOST 23 teleservice, (the method to perform this identification is internal to the SMSC and beyond the 24 scope of this standard) the SMSC shall determine the status and location of the targeted MS 25 using normal ANSI-41 procedures. 26
If the MS is unavailable or the location is unknown, the SMSC shall set an internal retry 27 schedule or wait for notification from HLR. Otherwise, it shall populate address delivery 28 information and optional parameters per normal ANSI-41 procedures. Next, it shall map the 29 contents of the SMS_BearerData per Table 143 and populate the SMS_TeleserviceIdentifier 30 with the GHOST teleservice identifier. Finally, it shall transmit the SMDPP INVOKE message 31 to the serving MSC. 32
33
A.1.2 Mapping of Messages, Parameters & Parameter Values 34
35
When the SMSC receives the SMDPP Invoke message from a CMT capable MS, the SMSC 36 follows normal ANSI-41 procedures except it replaces the CMT value of 32513d with the 37
N.S0028
187
GHOST value. In addition, the following parameter mapping related to ANSI-136-710 shall be 1 performed as indicated in Table 143. 2
3
4
Table 143: ANSI-136-710 to GHOST Parameter Mapping. 5
SMDPP/CMT Parameter Status Handling
ANSI-136 Message Type Indicator
M Only SMS_SUBMIT shall be relayed as a GHOST message. SMS_DELIVERY_ACK and SMS_MANUAL_ACK shall be discarded if the destination is a GHOST MS.
ANSI-136 Message Reference M -
ANSI-136 Privacy Indicator M -
ANSI-136 Urgency Indicator M Not mapped. Handled by the SMSC.
ANSI-136 Delivery Acknowledgement Request
M Not mapped. See note 1.
ANSI-136 Manual Acknowledgement Request
M -
ANSI-136 Message Updating M Not mapped. Handled internally by the MC.
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 of user data as described in §A.2.1 Detailed Procedures
ANSI-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.1
ANSI-136 Call Back Number Presentation
O -
ANSI-136 Call Back Number Alpha Tag
O -
6
Note 1: In GSM, delivery acknowledgement indicates that the data is stored at the MS. In ANSI-7 136, delivery acknowledgement is triggered by an action of the MS user (displaying the 8 message). Therefore this parameter is not mapped. It is a local decision for the operator as to 9 how to treat MO messages requesting these acknowledgements. The recommended procedure 10 for operators is for the MC to return a SMS DELIVERY ACK to the originator upon receipt of a 11 positive delivery confirmation from the terminating mobile. The procedures and format of the 12 SMS DELIVERY ACK message shall follow ANSI-136-710. 13
N.S0028
188
1
Table 144 describes where the parameters in the MT GHOST message are derived from: 2
Table 144: TP Derived Values 3
Parameter in MT GHOST message
Status Value/derivation
TP-Message-Type-Indicator M SMS-DELIVER
TP-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_OriginalOriginatingAddress
TP-Protocol-Identifier M Set to 00000000
TP-Data-Coding-Scheme M Set based on information in the ANSI-136 User Data Unit
Set bit number 3 per §A.2.1 Detailed Procedures
Set bit numbers 1&0 to value “Class 1”.
TP-Service-Center-Timestamp M Set by the MC to the appropriate value
TP-User-Data-Length M Set based on information in the ANSI-136 User Data Unit
TP-User-Data O Set based on information in the ANSI-136 User Data Unit.
4
5
A.1.3 Error Handling 6
7
No additional error handling procedures beyond those in ANSI-41D are required. 8
9
A.2 GHOST to CMT Delivery 10
11
GHOST may be used to deliver teleservices from a mobile station operating in ANSI-136 Native 12 Mode to an MS-based short message entity, which only supports the CMT ID without the 13 involvement of an IIF. 14
N.S0028
189
1
A.2.1 Detailed Procedures 2
3
The mobile station formulates a GSM SMS PDU and adds the GHOST header to the GSM 4 SMS PDU. If required, it adds the TSAR header to the GHOST teleservice. Next, it inserts the 5 GHOST teleservice into the Higher Layer Protocol Data Unit of the R-Data Unit and adds the 6 GHOST HLPI. An R-DATA message is formulated and sent to the ANSI-136 BMI. 7
The ANSI-136 MSC follows normal procedures and translates the R-DATA message to an 8 ANSI-41 SMDPP Invoke message and sends it to the originator’s home MC. The MC 9 destination address can be specified in the Teleservice Server Address. {Alternatively, MIN to 10 MC GTT or a routing table in the MSC may be used if the TSA is not present.} The MSC does 11 not open the Higher Layer Protocol Data Unit, but converts it directly to SMS_BearerData. 12
For the mobile station in ANSI-136 Native Mode, the Teleservice Server Address shall indicate 13 that the home Teleservice Server is the home Message Center. Upon receipt of the SMDPP 14 Invoke message, the SMSC responds with a SMDPP RR per normal ANSI-41 procedures. 15
The SMSC then identifies the destination address as an MS that supports CMT. (The method to 16 perform this identification is internal to the SMSC and beyond the scope of this standard.) It 17 then determines the status and location of the targeted MS using normal ANSI-41 procedures. 18 If the MS is unavailable or location is unknown, the SMSC shall set its internal retry schedule or 19 wait for notification from HLR 20
Otherwise, it shall populate the address delivery information and optional parameters per 21 normal ANSI-41 procedures. Next, it maps the contents of the SMS_BearerData per Table 145 22 and MT CMT message are derived from 23
Table 146 and populates the SMS_TeleserviceIdentifier with the CMT teleservice identifier. 24
Finally, the SMSC transmits the SMDPP Invoke message to the serving MSC. 25
26
Supported user data mappings 27
28
The following user data mappings should be supported: 29 30
IS-136 Encoding GSM TP-Data-Coding-Scheme
IRA/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.
31
32
N.S0028
190
1
A.2.2 Mapping of Messages, Parameters & Parameter Values 2
3
When the SMSC receives the SMDPP Invoke message from a GHOST capable MS, the SMSC 4 follows normal ANSI-41 procedures except it replaces the GHOST value of {to be provided by 5 TR45.3} with the CMT value of 32513d. In addition, the following parameter mapping related to 6 ANSI-136-710 shall be performed as indicated in Table 145. 7
Table 145: GHOST to ANSI-136-710 Parameter Mapping 8
Parameter in MT GHOST message Value/derivation
TP-Message-Type-Indicator SMS-DELIVER
TP-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_OriginalOriginatingAddress
TP-Protocol-Identifier Set to 00000000
TP-Data-Coding-Scheme Set based on information in the ANSI-136 User Data Unit
Set bit number 3 per §A.2.1 Detailed Procedures
Set bit numbers 1&0 to value “Class 1”.
TP-Service-Center-Timestamp Set by the MC to the appropriate value
TP-User-Data-Length Set based on information in the ANSI-136 User Data Unit
TP-User-Data Set based on information in the ANSI-136 User Data Unit.
9
10
N.S0028
191
1
Table 146 describes where the parameters in the MT CMT message are derived from 2
Table 146: CMT Derived Values 3
SMDPP/GHOST Parameter Handling
TP-Message-Type-Indicator Only SMS-SUBMIT shall be relayed as a CMT message. SMS-STATUS-REPORT shall be discarded if the destination is a CMT MS.
TP-Reject-Duplicates Not mapped. Handled internally by the MC.
TP-Validity-Period-Format Not mapped. Handled internally by the MC.
TP-Reply-Path Not mapped
TP-User-Data-Header-Indicator If the TP-UDHI indicates that the TP-UD contains a header then the MC shall interpret the header. The MC may, depending on the values in the header, discard the message, ignore the header or process the header and modify the ANSI-136 User Data Unit
TP-Status-Report-Request Not mapped. Handled internally by the MC. See Table 148
TP-Message-Reference Mapped to ANSI-136 Message Reference
TP-Destination-Address Mapped to SMS_OriginalDestinationAddress
TP-Protocol-Identifier Not mapped. Handled internally by the MC.
TP-Data-Coding-Scheme Mapped to ANSI-136 User Data Unit
TP-Validity-Period Not mapped. Handled internally by the MC.
TP-User-Data-Length Mapped to ANSI-136 User Data Unit
TP-User-Data Mapped to ANSI-136 User Data Unit
4
If the TP-Status-Report-Request is requested, then Table 148 provides mapping to identify the 5 status of a message being sent to a CMT mobile from a GHOST mobile. The SMS-STATUS-6 REPORT is encapsulated in a new SMDPP message to the status requester. The derived 7 values for the SMS-STATUS-REPORT are contained in Table 148. 8
9
N.S0028
192
1
Table 147: SMS_CauseCode to TP-STATUS Mapping 2
SMS_CauseCode
(ANSI-41)
TP-STATUS
(GSM)
Short message transaction completed
None sent. Positive ACK.
0000000 Short message received by the SME
Not mapped.
(future item for SMPP interworking)
0000001 Short message forwarded by the SC to the SME but the SC is unable to confirm delivery
Not applicable. 0000010 Short message replaced by the SC
Reserved values
0000011..0001111 Reserved
0010000..0011111 Values specific to each SC
Temporary error, SC still trying to transfer SM
0000 0010 Network resource shortage
0100000 Congestion
0010 0100 SMS delivery postponed
0100001 SME busy
Not mapped 0100010 No response from SME
0100 0010 Other radio interface problems
0100011 Service rejected
Not mapped 0100100 Quality of service not available
Not mapped 0100101 Error in SME
Not mapped 0100110..0101111 Reserved
Not mapped 0110000..0111111 Values specific to each SC
Permanent error, SC is not making any more transfer attempts
0110 0000 Encoding problem 1000000 Remote procedure error
0010 0110 Destination no longer at this address
1000001 Incompatible destination
3
4
N.S0028
193
1
Table 147: SMS_CauseCode to TP-STATUS Mapping (concluded) 2
SMS_CauseCode
(ANSI-41)
TP-STATUS
(GSM)
0010 0111 Other terminal problem
1000010 Connection rejected by SME
Not mapped 1000011 Not obtainable
Not mapped 1000100 Quality of service not available
Not mapped 1000101 No interworking available
MC internal procedure 1000110 SM Validity Period Expired
MC internal procedure 1000111 SM Deleted by originating SME
MC internal procedure 1001000 SM Deleted by SC Administration
MC internal procedure 1001001 SM does not exist (The SM may have previously existed in the SC but the SC no longer has knowledge of it or the SM may never have previously existed in the SC)
Not mapped 1001010..1001111 Reserved
Not mapped 1010000..1011111 Values specific to each SC
Temporary error, SC is not making any more transfer attempts
0010 0011 Destination resource shortage
1100000 Congestion
Not mapped 1100001 SME busy
Not mapped 1100010 No response from SME
0110 0100 SMS not supported 1100011 Service rejected
Not mapped 1100100 Quality of service not available
Not mapped 1100101 Error in SME
Not mapped 1100110..1101001 Reserved
Not mapped 1101010..1101111 Reserved
Not mapped 1110000..1111111 Values specific to each SC
3
All other values mapped to Service Rejected (0110 0011). 4
5
N.S0028
194
1
Table 148: SMS-STATUS-REPORT Derived Values 2
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 = 0
TP-More-Messages-to-Send M Set to value = 1
TP-Status-Report-Qualifier M Set to value = 0
TP-Message-Reference M Set by the MC to the appropriate value
TP-Recipient-Address M Set by the MC to the appropriate value
TP-Service-Center-Time-Stamp M Set by the MC to the appropriate value
TP-Discharge-Time M Set by the MC to the appropriate value
TP-Status M Set per Table 147
TP-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 Handling 5
6
No additional error handling procedures beyond those in ANSI-41D are required. 7
8
9
N.S0028
195
1
A.3 Callback Number 2
The Callback service enables SMS subscribers to be able to return calls to callers automatically 3 in an easy-to-use manner. Callers may provide their callback number to the SMSC by various 4 methods, 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 Address 8
� As part of the text body of a short message 9
The callback number can be dialed through a single button (e.g., pressing the SEND key) or a 10 simple key sequence (i.e., 3 or less keystrokes) of the MS. Using the capabilities of the MS, 11 the user may edit the callback number prior to originating the call. 12
13
A.3.1 Detailed Procedures 14
15
A.3.1.1 CMT to GHOST 16
17
The CMT mobile shall follow existing procedures as described in ANSI-136-710 to transmit a 18 callback number. If the MO-SMS is routed through an IIF to get to the subscriber’s home 19 SMSC, callback number information is in the application layer of the message and thus is 20 passed transparently. 21
Upon receipt at the SMSC, if the message contains the Callback Number parameter, then the 22 SMSC shall extract the callback number from this parameter and place it at the end of the TP-23 User-Data field preceded by the phrase “CALLBACK: <space>”. Carriers should limit the 24 message size they inform their subscribers that they are allowed to send to account for the 25 sending of the callback number. 26
27
A.3.1.2 External SME (SMPP to GHOST) 28
29
Upon receiving of a submitted short message for delivery, the SMSC shall determine if the 30 recipient’s mobile requires short message delivery via GHOST. This determination by the 31 SMSC is an internal process and is beyond the scope of this document. If the recipient’s 32 mobile uses CMT to receive short messages, then the SMSC shall delivery the message via 33 procedures as defined in ANSI-136-710. If the recipient’s mobile uses GHOST, then the SMSC 34 shall extract the callback number from the SMPP callback_num parameter and place it at the 35 end of the TP-User-Data field preceded by the phrase “CALLBACK: <space>”. Carriers should 36 limit the message size they inform their subscribers that they are allowed to send to account for 37 the sending of the callback number. 38
39
N.S0028
196
A.3.1.3 GHOST to CMT 1
2
Since there is no GSM equivalent to the ANSI-136 Callback Number parameter, two solutions 3 exist to provide equivalent feature functionality. 4
1. The SMSC shall parse each message looking for a callback number based upon 5 a set of rules to determine the Callback number. It shall then place this number in 6 the ANSI-136 Callback Number parameter. 7
2. The SMSC shall transparently map the TP-User-Data to the SMS_BearerData 8 per Table 122. The MS shall be capable of parsing the message and extracting 9 the callback number based upon the number appearing in the MS display screen. 10 The subscriber shall be able to press one button (e.g., SEND key) to callback the 11 number showing on the display screen. 12
Solution 2 above is the recommended procedure to provide a callback number under this 13 scenario. 14
15
A.3.2 Message Mapping, Parameters and Parameters Values 16
17
A.3.2.1 CMT to GHOST 18
19
Mapping for messages, parameters and parameter values shall be as according to §A.1.220 Mapping of Messages, Parameters & Parameter Values. 21
22
A.3.2.2 External SME 23
24
ANSI-41/136 mapping for messages, parameters and parameter values for a GHOST message 25 is not affected by the Callback Number procedures. 26
27
A.3.2.3 GHOST to CMT 28
29
Mapping for messages, parameters and parameter values shall be as according to §A.2.230 Mapping of Messages, Parameters & Parameter Values. 31
32
A.3.3 Error Handling 33
34
No additional error handling procedures beyond those in ANSI-41D are required. 35
36
N.S0028
197
1
ANNEX B Cause Code Mapping at Non-IIF Nodes 2
(Informative) 3
4
This annex is informative and describes processing that does not affect the IIF. 5
6
A mobile station shall respond to a received GHOST teleservice after processing the relay 7 layer. If the relay layer generates a failure, then the mobile station shall map the resulting RP-8 Cause value into its equivalent R-Cause code according to Table 149. 9
Table 149: RP-ERROR Cause to R-Cause for Mobile Station Response to Mobile 10 Terminated Transfer Attempt. 11
GSM RP-ERROR Cause ANSI-136 R-Cause
Memory capacity exceeded (22) Memory capacity exceeded (22)
Invalid short message transfer reference value (81)
Invalid short message transfer reference value (81)
Semantically incorrect message(95) Invalid message, unspecified (95)
Invalid mandatory information (96) Mandatory information element error (96)
Message type nonexistent or not implemented (97)
Message type non-existent or not implemented (97)
Message not compatible with short message protocol state (98)
Message not compatible with the short message transfer state (101)
Information element nonexistent or not implemented (99)
Information element non-existent or not implemented (99)
Protocol error, unspecified (111) Protocol error, unspecified (111)
Interworking, unspecified (127) Interworking, unspecified (127)
All other values Protocol error, unspecified (111)
12
At the ANSI-136 MSC, the R-Cause code returned by a mobile station is mapped into a 13 corresponding ANSI-41 SMS_CauseCode for inclusion in an SMDPP Return Result message. 14
At the ANSI-136 MSC, the ANSI-41 SMS_CauseCodes are mapped to ANSI-136 R-DATA 15 REJECT R-Cause codes according to Table 150. The mobile station in turn maps the R-Cause 16 codes to RP-ERROR Causes according to Table 151. 17
18
N.S0028
198
1
Table 150: ANSI-41 SMS_CauseCode to ANSI-136 R-Cause Code Mapping 2
ANSI-41 SMS_CauseCode ANSI-136 R-Cause
Network failure (3) Network out of order (38)
Other network problems (5) Network out of order (38)
SMS origination denied (97) Unidentified subscriber (28) or Facility 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)
3
Table 151: ANSI-136 R-Cause Code to RP-ERROR Cause Mapping within the Mobile 4 Station 5
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)
6
ANNEX C: CDMA to GSM One-way Roaming Only 7
(Informative) 8
9
10
Optionally, IIF may support one way-roaming only from CDMA to GSM networks. 11
In this case, all the mapping tables are applicable only in GSM Foreign Mode. 12
The IIF maps the ANSI-41 authentication parameters to the GSM triplets 13
All the changes are made on the assumption that the new requirements for UIM/handsets are 14 working. Table 152 shows the location updating mapping in the GSM foreign mode. 15
N.S0028
199
Table 152: UPDATE_LOCATION_REQUEST ->REGNOT Parameter Mapping 1
GSM MAP _UPDATE_LOCATION_REQUEST
Status ANSI_MAP_REGNOT Status
ElectronicSerialNumber M IMSI M
MSID M
MSC Address M1 MSCID (Serving MSC)1 M
- QualificationInformationCode M
- SystemMyTypeCode M
- MSCIdentificationNumber O
2
Table 152: UPDATE_LOCATION_REQUEST ↔ REGNOT Parameter Mapping (concluded) 3
GSM MAP _UPDATE_LOCATION_REQUEST
Status ANSI_MAP_REGNOT Status
VLR Number M -
- PC_SSN (Serving MSC or VLR) O
- SystemAccessType2 O
TerminalType2 O
- TransactionCapability2 O
LMSI U -
Supported CAMEL Phases C -
- -SYSACCTYPE3 O
4 1 These parameters are used to convey a unique identifier from the IIF to the HLR, identifying 5 the serving MSC/VLR. 6
2Parameters are included in ANSI specifications IS-41-C and later. 7
3 SYSACCTYPE parameter is required for the one-way CDMA to GSM roaming optional 8 scenario and in this case the parameter must be set by IIF to indicate GSM access type. 9
10
11
N.S0028
200
1
2