Académique Documents
Professionnel Documents
Culture Documents
S0028
Version 1.0.0
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 secretariat@3gpp2.org. Requests to
reproduce individual Organizational Partner's documents should be directed
to that Organizational Partner. See www.3gpp2.org for more information.
N.S0028-0
Revision History
Revision Date
Note
2 Abstract
3
4 This standard addresses the interworking and interoperability between ANSI-41 MAP[1] and GSM
5 MAP[4] based networks in the support of subscribers roaming between networks. The
6 interworking and interoperability functionality of the services, information flows, and message
7 mappings are specified.
8 This standard consists of four volumes:
9 Volume 0 - Overview and Interworking Reference Model
10 Volume 1 - Service Descriptions
11 Volume 2 - Information Flows
12 Volume 3 - Message Mappings
13
14 This is Volume 0 - an overview of the Interworking and Interoperability Function (IIF) and the
15 associated network reference model.
16
Version 1 i
N.S0028-0
Version 1 ii
N.S0028-0
2 Contents
3 Abstract........................................................................................................................................i
5 Contents..................................................................................................................................... iii
6 List of Tables.............................................................................................................................. vi
8 Foreword...................................................................................................................................viii
9 1 Introduction.....................................................................................................................1
11 1.2 Purpose..............................................................................................................1
12 1.3 Scope.................................................................................................................1
13 1.4 Organization.......................................................................................................1
14 2 References .....................................................................................................................3
7 Abstract........................................................................................................................................i
9 Contents..................................................................................................................................... iii
10 List of Tables...............................................................................................................................v
11 List of Figures............................................................................................................................. vi
12 Foreword................................................................................................................................... vii
13 1 Introduction.....................................................................................................................1
15 1.2 Purpose..............................................................................................................1
16 1.3 Scope.................................................................................................................1
17 1.4 Organization.......................................................................................................1
18 2 References .....................................................................................................................2
Version 1 iv
N.S0028-0
Version 1 v
N.S0028-0
2 List of Tables
3
4 There are no tables in this volume.
5
Version 1 vi
N.S0028-0
2 List of Figures
3
4 Figure 1: IIF Reference Model ................................................................................................... 9
5 Figure 2: HLR - VLR Interface...................................................................................................12
6 Figure 3: Originating / Gateway MSC - Serving MSC Interface..................................................14
7 Figure 4: MC / SMS-SC - Serving MSC Interface ......................................................................15
8 Figure 5: HLR- SGSN Interface.................................................................................................16
9 Figure 6: IIF Resides within GSM Network Element ..................................................................17
10 Figure 7: IIF Resides within ANSI-41 Network Element .............................................................17
11 Figure 8: IIF Resides within External Network Element .............................................................18
12 Figure 9: IIF Resides within both ANSI-41 and GSM Network Elements ....................................18
13 Figure 1: IIF Reference Model ................................................................................................... 7
14 Figure 2: HLR - VLR Interface.................................................................................................... 9
15 Figure 3: Originating / Gateway MSC - Serving MSC Interface..................................................10
16 Figure 4: MC / SMS-SC - Serving MSC Interface ......................................................................11
17 Figure 5: IIF Resides within GSM Network Element ..................................................................12
18 Figure 6: IIF Resides within ANSI-41 Network Element .............................................................12
19 Figure 7: IIF Resides within External Network Element .............................................................13
20 Figure 8: IIF Resides within both ANSI-41 and GSM Network Elements....................................13
21
22
Version 1 vii
N.S0028-0
2 Foreword
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
8 information flows and message mappings. However, not all services and associated capabilities
9 of ANSI-41 MAP and GSM MAP are supported by this standard. In general the attempt has been
10 to focus on the key subscriber services needed in the market.
11 The focus of the first release of this standard was on common GSM and ANSI-136 TDMA
12 services and associated network signaling (i.e. ANSI-41 MAP and GSM MAP). A prerequisite for
13 this interoperability is multi-mode mobile stations with an enhanced SIM card for roaming
14 between 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
16 GSM MAP to achieve the described interworking and interoperability. However, due to
17 differences between the services and associated capabilities of the MAP protocols, complete and
18 fully transparent interoperability may not have been achieved for some services. Future releases
19 of this standard may require changes to ANSI-41 MAP, GSM MAP and the associated services to
20 achieve 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, CDMA2000).
23 This may be accomplished in a future release of this standard.
24 Aspects of TIA/EIA-136 Revision C have been incorporated into the standard.
25 Revision A adds GPRS service capability in GSM Foreign Mode.
26 Revision BC adds two way roaming between GSM and IS-95 CDMA systems. A prerequisite for
27 this interoperability is multi-mode mobile stations with an enhanced SIM card for roaming
28 between IS-95 and GSM networks.
29 Information disclosed in this document is subject to the export jurisdiction of the US Department of
30 Commerce as specified in Export Administration Regulations (title 15 CFR parts 730 through 774
31 inclusive). The information contained herein may not be exported or re-exported to Cuba, Iran, Iraq, Libya,
32 North Korea, Sudan, or Syria. Contact the Telecommunications Industry Association, Arlington, VA or
33 http://ftp.tiaonline.org/tr-45/tr45ahag/public%20documents.
34
35
Version 1 viii
N.S0028-0
1
2
3
4
9
10
11
12
13
14
15
16 (This page is intentionally left blank)
Version 1 ix
N.S0028-0
2 1 Introduction
3 1.1 General
4 When a subscriber to one network type (e.g., ANSI-41) roams to a network of another type (e.g.,
5 GSM), interworking and interoperability functions are required to support roaming and enable
6 service. This standard describes an Interworking and Interoperability Function (IIF) to support this
7 cross-technology roaming between ANSI-41 and GSM networks. The IIF supports a multi-mode
8 mobile station with a removable Subscriber Identity Module (SIM). The standard also defines the
9 required network message mappings between ANSI-41 MAP and GSM MAP to support the
10 mobile terminal and associated services.
11 This standard includes the support of cross-technology roaming between an ANSI-41 based
12 network and 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
17 1.2 Purpose
18 The purpose for this standard is to define and describe the functions necessary for roaming
19 between ANSI-41 MAP and GSM MAP based networks in the support of roaming subscribers.
20 This includes a capability to allow a subscriber to an ANSI-41 based network (e.g., a TDMA or
21 CDMAn ANSI-136 native subscriber) with a mobile terminal supporting GPRS service to roam to
22 a GPRS network in GSM Foreign Mode. GPRS support for IS-95 handsets is not addressed in
23 this release of the standard.
24 1.3 Scope
25 The scope of this standard are the services, information flows and message mappings which
26 require interworking and interoperability functional specifications to support roaming between
27 ANSI-41 MAP and GSM MAP networks.
28 The scope of this volume is to provide a description of interstandard roaming along with an
29 overview and network reference model for the Interworking and Interoperability Function (IIF).
30 1.4 Organization
31 This standard is divided into four separate volumes:
32 Volume 0 - Overview and Network Reference Model
33 Volume 1 - Service Descriptions
34 Volume 2 - Information Flows
35 Volume 3 - Message Mappings
36
37 Volume 0 is organized as follows:
38 1 Introduction - provides an overview, purpose, scope, and organization of this volume.
1
N.S0028-0
1 2 References - is a list of references used in the preparation of this volume of this Interim
2 Standard.
3 3 Definitions and Acronyms - defines words and acronyms that are used in this volume of this
4 Interim Standard.
5 4 Overview of Internetwork Roaming - provides an overview of interstandard roaming and
6 defines the terms used to describe it.
7 5 IIF Reference Model and Description - provides an architecture description of the
8 Interoperability and Interworking Function (IIF), an overview of its functionality,
9 and description of its relationship and interfaces to other network elements.
10
Version 1 2
N.S0028-0
2 2 References
3
4 [1] TIA/EIA-136: “TDMA Cellular/PCS--Radio Interface--Mobile Station-Base Station
5 Compatibility Standard,” March 2000, ANSI.
6
7 [2] TIA/EIA-41-D: “Cellular Radiotelecommunications Intersystem Operations,” December 1997,
8 ANSI.
9
10 [3] TIA/EIA-553: “Mobile Station – Land Station Compatibility Specification,” September 1989,
11 ANSI.
12 [4] GSM 09.02 Version 6.2.0 Release 1997 “Digital cellular telecommunication system (Phase
13 2+); Mobile Application Part (MAP) specification”, August 1998, ETSI.
14
15 [5] TIA/EIA/IS-129, “Interworking/Interoperability Between DCS 1900 and IS-41 Based MAPs for
16 1800 MHz Personal Communications Systems,” Phase 1, July 1996.
17 [6] TIA/EIA/IS-637”Short Message Services for Wideband Spread Spectrum Cellular Systems”
18 [7] TIA/EIA/IS 737A”IS-41 support for data services for digital terminals (TDMA and CDMA)”
22
23 [10] TIA/EIA-95-B - Mobile Station-Base Station Compatibility Standard for Dual-Mode Spread
24 Spectrum Systems; Published October 1998.
25
26 [11] "TIA/EIA-IS-2000-A, cdma2000 Series, March 2000, plus addenda"Mobile Station-Base
27 Station Compatibility Standard for Dual-Mode Spread Spectrum Systems;
28 [12] TIA/EIA-868 – ANSI-41-D Network Based Enhancements to support one-way roaming to
29 GSM, Published TBD.
30 [12]"Enhanced Cryptographic Algorithms, Revision B," TR45AHAG, Published TBD
31
3
N.S0028-0
Version 1 4
N.S0028-0
5
N.S0028-0
1 3.2 Acronyms
21 ME Mobile Equipment
23 MS Mobile Station
Version 1 6
N.S0028-0
7
N.S0028-0
Version 1 8
N.S0028-0
SMS
MC
SMS -SC
-IWMSC
N
Q
E SMS
AC H HLR -GMSC
D E
IIF D
D
HLR H AuC
VLR D
E
E
VLR
MSC Gr
MSC
SGSN
TIA/EIA-41
GSM
Network Entities Network Entities
10
11 Figure 1: IIF Reference Model
12
13 5.2 Description
14 GSM and ANSI-41 network entities rely on different network signaling protocols to support
15 mobility management and service realization. When a subscriber to a network supported by
16 ANSI-41 network entities (i.e., a native TDMAANSI-136 or ICDMAS-95 subscriber) accesses a
17 visited GSM network, the visited network uses GSM Mobile Application Part (MAP) signaling,
18 while the controlling home network uses ANSI-41 MAP signaling. Likewise, when a native GSM
19 subscriber accesses a visited ANSI-41 based network (i.e., an ANSI-136 TDMA or CDMAIS-95
20 network), the visited network uses ANSI-41 MAP signaling, while the controlling home network
21 uses GSM MAP signaling.
22 To support “seamless” interoperability of service between GSM and ANSI-41 network entities, an
23 interworking and interoperability function (IIF) or gateway shall map message flows between
24 GSM and ANSI-41 MAP. Analog AMPS capability, which is defined as a subset of ANSI-41136, is
25 also supported by ANSI-41 MAP.
9
N.S0028-0
1 In most cases, the IIF interprets a signaling message in one protocol and converts it to the
2 equivalent operation in the other network protocol.
Version 1 10
N.S0028-0
1 roaming into a GSM system or UIMs that are inserted into GSM terminal equipment. A valid SSD
2 is generated in the UIM before the user can roam to a GSM system
3 A valid SSD value must be generated in the UIM (or multi-mode MS) before the subscriber can
4 roam into a GSM system. The IIF functions as a VLR in its interaction with the ANSI -41 Home
5 System
6 The ANSI-41 AC shares SSD with the IIF for subscribers roaming in a GSM network. The IIF
7 generates the triplets (RAND, XRES, KC) used by the GSM system. The triplet generation function
8 is specified in section 2.2.4.1 of “Enhanced Cryptographic Algorithms, Revision B.”
9
10 After the subscriber is registered in a GSM system, the IIF reports authentication failures to the
11 ANSI-41 system using the AuthenticationFailureReport operation.
12 SSD is shared with the IIF until registration in the GSM system is canceled. The ANSI -41
13 AC/HLR can cancel registration using the RegistrationCancellation operation.
14 The IIF shall remove the subscriber’s SSD when registration in the GSM system is canceled.
15 SSD Update cannot be performed when the MS is roaming in a GSM system
16 A new SystemCapabilities parameter value shall be defined to indicate a GSM system
17 A SystemCapabilities parameter value indicating GSM system shall be used by the IIF to indicate
18 that the Serving network is using GSM authentication and privacy procedures. This indicates that
19 SSD Update cannot be performed. It also indicates that the ESN sent to the ANSI-41 home
20 system was not received from the MS. The IIF functions as a GSM HLR/AC in its interactions
21 with the GSM system
22 The IIF provides the GSM triplets needed for authentication and privacy in the GSM system. The
23 IIF generates triplets using the SSD value stored in the UIM (or multi-mode MS).
24 When roaming in a GSM system, the UIM uses the “authentication” algorithm supported
25 by the IIF
26 When roaming is a GSM system, the UIM (or multi-mode MS) must use an authentication
27 algorithm supported by the IIF for the computation of the cipher key and the response to the
28 random challenge.
29 The ANSI-41 home system is expected to update SSD when the MS returns to an ANSI-41
30 system
31 The subscriber’s SSD should be updated when the user returns to an ANSI-41 system.
32 The IIF shall prevent disclosure of SSD values received from ANSI -41 systems
33 The IIF shall provide a secure method of storing SSD values received from ANSI-41 systems.
34 The
35 SSD values shall not be disclosed nor transmitted to any other network entity.
36 The IIF shall be able to request the MS’s ESN in the AuthenticationRequest INVOKE sent
37 to the home ANSI-41 system
38 To support GPRS service in GSM Foreign Mode, GPRS specific subscriber data also needs to be
39 provisioned in the IIF such as :
40 • GGSN-list (GGSN Number and optional IP address)
41 • PDP Type
42 • PDP Address (if dynamic addressing is not allowed)
43 • Quality of Service Subscribed
11
N.S0028-0
1 versa. The emulation functions in the IIF conform to existing ANSI-41 and GSM protocols when
2 communicating over the external interfaces.
3 The following figures depict the emulated network elements within the IIF using hashed lines. The
4 hashed lines connecting emulated network elements within the IIF represent internal, conversion
5 or mapping interfaces. All solid connecting lines depict standard ANSI-41 or GSM interfaces
6 based on existing protocol.
7 The arrow above each figure represents information exchange for the top half of the figure, while
8 the arrow below each figure represents information exchange for the bottom half of the figure.
IIF
Version 1 12
N.S0028-0
1 To support ANSI-136 foreign mode operation, an ANSI-136 Authentication Center (AC) can be
2 integrated into the IIF gateway or implemented as a separate network element.
3
4 5.3.1.2 GSM Foreign Mode Implementation for ANSI-136 Subscriber
5 Similarly, when an ANSI-136 native subscriber operates in GSM foreign mode, the mobile station
6 shall use the GSM air interface. The interoperability gateway or IIF shall provide both GSM HLR
7 and ANSI-41 VLR emulation to allow the subscriber to automatically register and obtain service.
8 To the visited GSM network, the subscriber appears to register with the IIF, emulating a GSM
9 HLR. This emulated GSM HLR acts as a limited proxy for the actual ANSI-41 HLR, with the true
10 ANSI-41 HLR retaining ultimate control. At the same time, to the home ANSI-136 network, the
11 subscriber appears to register from the IIF, emulating an ANSI-136 VLR. The IIF links GSM MAP
12 operations and data to the equivalent ANSI-41 MAP operations and data, and vice versa, in order
13 to support interoperability.
14 To support GSM foreign mode operation, a GSM Authentication Center (AuC) can be integrated
15 into the IIF gateway or implemented as a separate network element.
16 5.3.1.3 CDMAIS-95 Foreign Mode Implementation for GSM Subscriber
17 When a GSM native subscriber operates in IS-95 foreign mode, the mobile station shall use the
18 IS-95 CDMA air interface. The interoperability gateway or IIF shall provide both ANSI-41 HLR and
19 GSM VLR emulation to allow the subscriber to automatically register and obtain service. To the
20 visited ANSI-41 network, the subscriber appears to register with the IIF, emulating an ANSI-41
21 HLR. This emulated ANSI-41 HLR acts as a limited proxy for the actual GSM HLR, with the true
22 GSM HLR retaining ultimate control. At the same time, to the home GSM network, the subscriber
23 appears to register from the IIF, emulating a GSM VLR. The IIF links ANSI-41 MAP operations
24 and data to the equivalent GSM MAP operations and data, and vice versa, in order to support
25 interoperability.
26 To support IS-95 foreign mode operation, an IS-95 Authentication Center (AC) can be integrated
27 into the IIF gateway or implemented as a separate network element.
28
29 5.3.1.4 GSM Foreign Mode Implementation for IS-95CDMA Subscriber
30 Similarly, when an IS-95CDMA native subscriber operates in GSM foreign mode, the mobile
31 station shall use the GSM air interface. The interoperability gateway or IIF shall provide both
32 GSM HLR and ANSI-41 VLR emulation to allow the subscriber to automatically register and
33 obtain service. To the visited GSM network, the subscriber appears to register with the IIF,
34 emulating a GSM HLR. This emulated GSM HLR acts as a limited proxy for the actual ANSI-41
35 HLR, with the true ANSI-41 HLR retaining ultimate control. At the same time, to the home IS-
36 95CDMA network, the subscriber appears to register from the IIF, emulating an IS-95CDMA VLR.
37 The IIF links GSM MAP operations and data to the equivalent ANSI-41 MAP operations and data,
38 and vice versa, in order to support interoperability.
39 To support GSM foreign mode operation, a GSM Authentication Center (AuC) can be integrated
40 into the IIF gateway or implemented as a separate network element.
41
42
13
N.S0028-0
1 signaling is supported over this interface. Figure 3 below depicts the interworking and control
2 interface provided by the IIF in this case.
3 This interface is key to supporting optimal routing for late call forwarding, where the serving MSC
4 wishes to signal back to the originating or gateway MSC in order to request forwarding of the call.
5 In order to support optimal routing for late call forwarding, the IIF provides originating or gateway
6 MSC emulation.
7
ANSI-41 subscriber roaming
to GSM network
IIF
Version 1 14
N.S0028-0
IIF
GSM GSM
SMS- E Serving
ANSI-41 IWMSC MSC
ANSI-41 GSM
Q Serving E
MC SMS-SC
MSC GSM
GSM
SMS-
SMS-
GMSC
ANSI-41 IWMSC
ANSI-41 E GSM
Serving Q MC SMS-SC
MSC GSM GSM
Serving E SMS-
MSC GMSC
15
N.S0028-0
IIF
Version 1 16
N.S0028-0
T IA /E IA - 4 1 G SM
N e tw o rk N e tw o rk
E le m e n t E le m e n t
IIF
T IA /E IA -4 1 GSM
N e tw o rk N e tw o rk
E le m e n t E le m e n t
IIF
10
17
N.S0028-0
External
Network
Element
IIF
TIA/EIA-41 GSM
Network Network
Element Element
8 5.4.4 IIF Resides within Both ANSI-41 and GSM Network Entities
9 Finally, the IIF may reside within both existing ANSI-41 and GSM network entities at the same
10 time. In this case, each individual subscriber is likely to be served by one particular IIF, although
11 the use of multiple IIFs per subscriber is possible. Again, each of the interfaces can be supported
12 with this implementation alternative. While multiple IIFs can support one particular subscriber,
13 each network interworking function would be supported by one specific IIF implementation.
14
TIA/EIA-41 GSM
Network Network
Element Element
IIF IIF
15
16 Figure 9: IIF Resides within both ANSI-41 and GSM Network Elements
17
Version 1 18
N.S0028-0
1 Abstract
2 This standard addresses the interworking and interoperability between ANSI-41 MAP[3] and GSM
3 MAP[21] based networks in the support of subscribers roaming between networks. The interworking
4 and interoperability functionality of the services, information flows, and message mappings are
5 specified.
6 This standard consists of four Volumes:
7 Volume 0 - Overview and Interworking Reference Model
8 Volume 1 - Service Descriptions
9 Volume 2 - Information Flows
10 Volume 3 - Message Mappings
11 This is Volume 1. Volume 1 is based on ANSI-664[1] and GSM stage 1’s (see GSM 02-series e.g.,
12 GSM 02.04, etc. in the References section). Some modifications (primarily simplifications) were made
13 for the purpose of specifying the degree of interoperability desired. ANSI-664 services and GSM
14 services do not necessarily align.
15
Ballot Version i
N.S0028-0
Ballot Version ii
N.S0028-0
Contents
Contents........................................................................................................................................... iii
List of Tables.................................................................................................................................... vi
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.1 Definitions 5
3.2 Acronyms 8
4.1 Authentication..................................................................................................................10
4.7 Call Barring (CB) and Operator Determined Barring (ODB) ..............................................81
Abstract.............................................................................................................................................. i
Contents........................................................................................................................................... iii
List of Tables..................................................................................................................................... v
List of Figures................................................................................................................................... vi
Foreword......................................................................................................................................... vii
Ballot Version iv
1 Introduction .................................................................................................................................1
N.S0028-0
Ballot Version v
N.S0028-0
List of Tables
Table 5: ANSI-41 Foreign Mode Interoperability for Barring of Outgoing Calls .................................. 82
Table 5: ANSI-41 Foreign Mode Interoperability for Barring of Outgoing Calls .................................. 80
Table 6: GSM Foreign Mode Interoperability for Outgoing Call Restrictions ...................................... 80
Ballot Version vi
N.S0028-0
List of Figures
There are no figures in this volume.
2 Foreword
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 networks.
7 Services supported by this standard are described along with the associated information flows and
8 message mappings. However, not all services and associated capabilities of ANSI-41 MAP and GSM
9 MAP are supported by this standard. In general the attempt has been to focus on the key subscriber
10 services needed in the market.
11 The focus of the first release of this standard was on common GSM and ANSI-136 TDMA services
12 and associated network signaling (i.e. ANSI-41 MAP and GSM MAP). A pre-requisite for this
13 interoperability is multi-mode mobile stations with an enhanced SIM card for roaming between ANSI-
14 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 between
17 the services and associated capabilities of the MAP protocols, complete and fully transparent
18 interoperability may not have been achieved for some services. Future releases of this standard may
19 require changes to ANSI-41 MAP, GSM MAP and the associated services to achieve full
20 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 a future release of this standard.
24 Aspects of TIA/EIA-136 Rev C have been incorporated into this standard.
25 Revision A adds the capability of getting GPRS services when roaming in GSM Foreign Mode.
26
27 Revision B adds roaming between GSM and CDMA systems
1 1 Introduction
2
3 1.1 General
4 When a subscriber to one network type (e.g., ANSI-41) roams to a network of another type (e.g.,
5 GSM), interworking and interoperability functions are required to support roaming and enable service.
6 This standard describes an Interworking and Interoperability Function (IIF) to support this cross-
7 technology roaming between ANSI-41 and GSM networks. The IIF supports a multi-mode mobile
8 station with a removable Subscriber Identity Module (SIM). The standard also defines the required
9 network message mappings between ANSI-41 MAP and GSM MAP to support the mobile terminal
10 and associated services.
11 This standard includes the support of cross-technology roaming from an ANSI-41 based network to a
12 GPRS network. The GPRS network may be coupled with a GSM network. This feature requires
13 enhancement to the Interworking and Interoperability Function (IIF) which supports a multi-mode
14 mobile station and Subscriber Identity Module (SIM) with GPRS functionality.
15
16 1.2 Purpose
17 The purpose for this standard is to define and describe the functions necessary for roaming between
18 ANSI-41 MAP and GSM MAP based networks in the support of roaming subscribers. This includes a
19 capability to allow a subscriber to an ANSI-41 based network (e.g., an ANSI-136 or CDMA native
20 subscriber) with a mobile terminal supporting GPRS service to roam to a GPRS network in GSM
21 Foreign Mode.
22
23 1.3 Scope
24 The scope of this standard are the services, information flows, and message mappings which require
25 interworking and interoperability functional specifications to support roaming between ANSI-41 MAP
26 and GSM MAP networks.
27 The scope of this volume is a high level (stage 1) description of the services and functionality required
28 to support GSM and ANSI-41 network interoperability. In particular, when in foreign mode (roaming in
29 non-native mode technology), subscribers are able to:
30 roam and register (with authentication);
33 - Call Forwarding,
34 - Call Waiting,
35 - Calling Number Identification Presentation - Line Identification Presentation,
36 - Call Barring, and
37 - GSM Multi-Party - ANSI-41 3-way Calling and Conference;
Ballot Version 1
N.S0028-0
5 1.4 Organization
6 This standard is organized into the following volumes:
7 Volume 0 - Overview and Interworking Reference Model
8 Volume 1 - Service Descriptions
9 Volume 2 - Information Flows
10 Volume 3 - Message Mappings
11 This volume 1 is organized according to the following:
12 2 References - a list of references.
13 3 Definitions and Acronyms - definions of words and acronyms.
14 4 Stage 1 Service Descriptions - descriptions of the interoperable network features.
15
Ballot Version 2
N.S0028-0
1 2 References
2
3 [1] TIA/EIA-664: “Cellular Features Description”, Telecommunications Industry Association;
4 February 2000, ANSI.
5 [2] TIA/EIA-136: “TDMA Cellular/PCS--Radio Interface--Mobile Station-Base Station Compatibility
6 Standard,” March 2000, ANSI.
7 [3] TIA/EIA-41-D: “Cellular Radiotelecommunications Intersystem Operations,” December 1997,
8 ANSI.
9 [4] TIA/EIA/IS-751, "TIA/EIA 41-D Modifications to Support IMSI, February 1998".
10 [5] TIA/EIA/IS-807, "TIA/EIA-41-D Enhancements for Internationalization".
11 [6] EIA/TIA-553: “Mobile Station – Land Station Compatibility Specification,” September 1989,
12 ANSI.
13 [7] “Common Cryptographic Algorithms, Revision C,” October 27, 1998, TR45AHAG.
14 [8] TIA/EIA-136-510 “Authentication, encryption of signaling information/user data and privacy”.
15 [9] GSM 02.04 version 6.1.1 Release 1997, “General on Supplementary Services”, (Phase 2+),
16 ETSI.
17 [10] GSM 02.09 version 6.1.0 Release 1997, “Digital cellular telecommunications system Security
18 Aspects”, (Phase 2+), ETSI.
19 [11] GSM 02.30 version 6.1.0 Release 1997, “Man-Machine Interface (MMI) of the Mobile Station”,
20 (Phase 2+), ETSI.
21 [12] GSM 02.41 version 6.0.0, Release 1997, "Operator Determined Barring (ODB)", (Phase 2+),
22 ETSI.
23 [13] GSM 02.79 version 6.0.0, Release 1997, “Support of Optimal Routeing (SOR) Service
24 Definition (Stage 1)”, (Phase 2+), ETSI.
25 [14] GSM 02.81 version 7.0.0 Release 1998, “Line Identification Supplementary Services – Stage 1“
26 (Phase 2+), ETSI.
27 [15] GSM 02.82 version 6.0.0 Release 1997, “Call Forwarding (CF) Supplementary Services - Stage
28 1” (Phase 2+), ETSI.
29 [16] GSM 02.83 version 6.0.0 Release 1997, “Call Waiting (CW) and Call Holding (HOLD)
30 Supplementary Services - Stage 1”, (Phase 2+), ETSI.
31 [17] GSM 02.84 version 6.0.0 Release 1997, “MultiParty (MPTY) Supplementary Services – Stage
32 1”, (Phase 2+), ETSI.
33 [18] GSM 02.85 version 6.0.0 Release 1997, “Closed User Group (CUG) Supplementary Services –
34 Stage 1 ”, (Phase 2+), ETSI.
35 [19] GSM 02.86 version 6.0.0 Release 1997, “Advice of Charge (AOC) Supplementary Services –
36 Stage 1”, (Phase 2+), ETSI.
37 [20] GSM 02.88 version 6.0.0 Release 1997, “Call Barring (CB) Supplementary Services – Stage 1”
38 (Phase 2+), ETSI.
Ballot Version 3
N.S0028-0
1 [21] GSM 09.02 version 6.2.0 Release 1997, “Digital cellular communication system (Phase2+);
2 Mobile Application Part (MAP) specification”, August 1998, ETSI
3 [22] GSM 02.60 version 6.3.1 Release 1997 “General Packet Radio Service (GPRS); Service
4 Description, Stage 1
5 [23] TIA/EIA/IS 737A”IS-41 support for data services for digital terminals (TDMA and CDMA)”
Ballot Version 4
N.S0028-0
3 3.1 Definitions
4 AMPS
5
6 Advanced Mobile Phone Service (AMPS) is the same as ANSI EIA/TIA-553[6], which as an analog air
7 interface protocol standard for mobile stations and their associated base stations. AMPS networks
8 use ANSI-41 for intersystem signaling.
9
10 ANSI-41
11
12 ANSI-41, as used in this document, refers to TIA/EIA-41[3] and the modifications and enhancements
13 as noted in IS-751[4] and IS-807[5]. This is a network protocol standard to support intersystem
14 operation of cellular networks, such as ANSI-136 or CDMA networks. Key intersystem support
15 defined by ANSI-41 includes automatic roaming, intersystem handoff, and intersystem operation,
16 administration, and maintenance. Among other things, ANSI-41 defines the interfaces between
17 MSCs, between the MSC/VLR and the HLR/AC, and between the MSC and the Short Message
18 Service Center (SMS-C) or Teleservice Server (TS).
19
20 ANSI-136
21
22 ANSI-136, as used in this document, refers to TIA/EIA-136[2], which is a TDMA air interface protocol
23 standard for mobile stations and their associated base stations. ANSI-136 is a dual-mode standard
24 that includes digital (TDMA) operation at 800 MHz and 1900 MHz, and analog (AMPS) operation at
25 800 MHz. ANSI-136 networks use ANSI-41 for intersystem signaling.
26
27 ANSI-136 Mode
28
29 ANSI-136 mode indicates the condition or state of a mobile station accessing an ANSI-136 network.
30
31 ANSI-136 Foreign Mode
32
33 ANSI-136 foreign mode indicates the condition or state of a GSM native subscriber accessing an
34 ANSI-136 network.
35
36 ANSI-136 Native Mode
37
38 ANSI-136 native mode indicates the condition or state of an ANSI-136 native subscriber accessing an
39 ANSI-136 network.
40
41 ANSI-136 Native Subscriber
42
43 ANSI-136 native subscriber indicates an end user whose primary or home subscription resides in an
44 ANSI-136 network. These subscribers include both home subscribers from the ANSI-136 network, as
45 well as roamers from other ANSI-136 networks.
46
47 ANSI-41 Foreign Mode
48
49 ANSI-41 foreign mode indicates the condition or state of a GSM native subscriber accessing an
50 ANSI-41 based network.
Ballot Version 5
N.S0028-0
1
2
3
4 GSM
5
6 Global System for Mobile Communications (GSM) defines both air interface and network intersystem
7 protocol standards for mobile stations (MS), base station systems (BSS), and network switching
8 systems (NSS).
9
10 GSM CS attached
11 GSM circuit-switched services attached means that the subscriber is attached to a GSM MSC. This is
12 also referred to as IMSI attached.
13 GSM CS detached
14 GSM circuit-switched services detached means that the subscriber is detached from a GSM MSC.
15 This is also referred to as IMSI detached.
16
17 GSM Foreign Mode
18
19 GSM foreign mode indicates the condition or state of an ANSI-136 ANSI-41 native subscriber
20 accessing a GSM network.
21
22
23 GPRS HLR
24 General Packet Radio Service Home Location Register is the HLR responsible for GPRS functions. It
25 interfaces with the SGSN and GGSN and Authentication Center.
26
27 GSM Mode
28
29 GSM mode indicates the condition or state of a mobile station accessing a GSM network.
30
31 GSM Native Mode
32
33 GSM native mode indicates the condition or state of a GSM native subscriber accessing a GSM
34 network.
35
36 GSM Native Subscriber
37
38 GSM native subscriber indicates an end user whose primary or home subscription resides in a GSM
39 network. These subscribers include both home subscribers from the GSM network, as well as
40 roamers from other GSM networks.
41
42 CDMA
43
44 CDMA as used in this document, refers to TIA/EIA -95 [9] or TIA/EIA-2000 [10], which is a CDMA
45 air interface protocol standard for mobile stations and their associated base stations. CDMA is a
46 dual-mode standard that includes digital (CDMA) operation and analog (AMPS) operation. CDMA
47 networks use ANSI-41 for intersystem signaling.
48 CDMA Mode
49 CDMA mode indicates the condition or state of a mobile station accessing an CDMA network.
50
51
Ballot Version 6
N.S0028-0
Ballot Version 7
N.S0028-0
1 3.2 Acronyms
2 AC Authentication Center in ANSI TIA/EIA-41 based networks
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 BMI Base Station, Mobile Switching System, and Interworking Function
10 BOIC Barring of Outgoing International Calls
11 BOIC-exHC Baring of Outgoing International Calls Except to HPLMN Country
12 CDMA Code-Division Multiple Access
13 CFB Call Forwarding Busy
14 CFNA Call Forwarding No Answer
15 CFNRc Call Forwarding Not Reachable
16 CFNRy Call Forwarding No Reply
17 CS Circuit-Switched
18 EDGE Enhanced Data Rates Through Global Evolution
19 EIA Electronics Industry Association
20 ESN Electronic Serial Number
21 ETSI European Telecommunications Standards Institute
22 FC Feature Code
23 FSM GSM Forward Short Message
24 GGSN Gateway GPRS Support Node
25 GPRS General Packet Radio Service
26 GSM Global System for Mobile Communications
27 HLR Home Location Register
28 HPLMN Home Public Land Mobile Network
29 IIF Interworking and Interoperability Function
30 IMSI International Mobile Subscriber Identity
31 ITU International Telecommunications Union
32 MAP Mobile Application Part
Ballot Version 8
N.S0028-0
Ballot Version 9
N.S0028-0
13 4.1 Authentication
14 Authentication defines the ability for a wireless network to confirm the identity of a mobile station at
15 the time of connection, and to ensure the validity of this identity during the complete connection time.
16 This is achieved through the use of cryptographic schemes based on secret key algorithms.
Ballot Version 10
N.S0028-0
14 The secret data used in the CDMA authentication process is the shared secret data (SSD). The
15 internal values used within the CDMA authentication process are the ESN, and the IMSI.
16 Authentication on IMSI is done in a CDMA mobile according to the IS-95 specification by extracting
17 10 digits from the IMSI. (IMSI_S).
18 ANSI-41 Mode
19 The ANSI-41 authentication module is defined by the air-interface specific directory in the mobile
20 station. The data used for authentication is as define by the Common Cryphtograpic Algorithm
21 (CAVE)add reference).
22
23
24 GSM Mode
25 The GSM authentication module is defined by the GSM directory in the SIM. The SIM card can
26 support multiple GSM subscriptions and each one has its own authentication module.
27 The secret data used in the GSM authentication process is the Ki. There is no internal data used in
28 the GSM authentication process.
Ballot Version 11
N.S0028-0
3 4.1.2.3 Registration
4 None identified.
7 4.1.2.5 Activation
8 Activation is performed by the operator or serving system.
9 4.1.2.6 De-Activation
10 De-activation is performed by the operator or serving system.
11 4.1.2.7 Invocation
12 The authentication function is invoked in the mobile station by selecting the appropriate directory
13 (GSM or ANSI-41136) on the authentication module and sending the appropriate command (RUN
14 AUTH ALGO or RUN CAVE)command, with the appropriate parameters (random value, option flag,
15 internal values). The authentication function is invoked in the network by the receipt of an
16 authentication message from the mobile station.
24 4.1.3.1 Registration
25 None identified.
28 4.1.3.3 Activation
29 None identified.
30 4.1.3.4 De-Activation
31 None identified.
32 4.1.3.5 Invocation
Ballot Version 12
N.S0028-0
1 None identified.
17 4.1.5.4 Barring of Outgoing International Calls except those directed to the Home PLMN
18 (BOIC-exHC)
19 None identified.
22 4.1.5.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam)
23 None identified.
Ballot Version 13
N.S0028-0
1 None identified.
Ballot Version 14
N.S0028-0
Ballot Version 15
N.S0028-0
1 The Voice Privacy elements (e.g., for ANSI-41136 ,TDMA or CDMA) are derived from the same
2 secret A-Key as for the Authentication algorithm. If the HLR/AC for the mobile subscriber does not
3 have knowledge of this information it shall not be able to activate the Voice Privacy feature.
Ballot Version 16
N.S0028-0
17
Ballot Version 17
N.S0028-0
21 4.2.2.2.3 Registration
22 If the subscriber is authorized for Fixed Registration, the forward-to number shall be registered upon
23 authorization (provision). Mobile stations operating in foreign mode may attempt to perform
24 registration procedures normally supported in native mode.
25 The forward-to-number may be registered by the service provider upon authorization (provision) for
26 Variable Registration subscribers
27 GSM foreign mode: A forward-to-number may be registered by a Variable Registration authorized
28 subscriber specifying the CFU registration feature code and a forward-to number termination address
29 as in:
*
31 Alternatively, if the mobile station offers menu driven control of registration, the mobile station is
32 expected to generate the equivalent GSM functional signaling towards the network.
33 ANSI-41 foreign mode: Registration can take place with an appropriate control procedure by the
34 subscriber, per GSM 02.30[11]. In ANSI-41 foreign mode, if the equivalent GSM feature code (MMI)
35 is manually entered by the user, the mobile station is expected to issue the relevant ANSI-13641
36 feature code entry.
Ballot Version 18
N.S0028-0
1 Alternatively, if the mobile station offers menu driven control of registration, the mobile station is
2 expected to generate the equivalent ANSI-13641 feature code entry and resulting call origination
3 based on the menu driven entry.
4 If the registration is accepted, the system shall indicate success using either GSM or ANSI-13641
5 signaling techniques depending on the mode of operation.
14 FC0 + SEND .
15 Alternatively, if the mobile station offers menu driven control of registration, the mobile station is
16 expected to generate the equivalent GSM functional signaling towards the network.
17 ANSI-41 foreign mode: The subscriber can specifically erase a previous registration with an
18 appropriate control procedure, per GSM 02.30[11]. In ANSI-41 foreign mode, if the equivalent GSM
19 feature code (MMI) is manually entered by the user, the mobile station is expected to issue the
20 necessary ANSI-13641 feature code to the network.
21 CFU shall be de-registered upon de-authorization or withdrawal.
22 4.2.2.2.5 Activation
23 Mobile stations operating in foreign mode may attempt to perform Activation procedures normally
24 supported in native mode.
25 If the subscriber is authorized for Permanent Activation, CFU shall be activated upon authorization
26 (provision).
27 CFU may be activated upon authorization or registration for Demand Activation authorized
28 subscribers. CFU may be activated upon registration for Variable Registration authorized subscribers.
29 GSM foreign mode: A previously registered forward-to-number may be activated by a Demand
30 Activation authorized subscriber specifying a CFU activation feature code, as in:
*
31 FC + SEND .
32 Alternatively, if the mobile station offers menu driven control of activation, the mobile station is
33 expected to generate the equivalent GSM functional signaling.
34 ANSI-41 foreign mode: The MS shall be allowed to activate CFU by a control procedure (e.g., using
35 the MMI command described in GSM 02.30[11]). In ANSI-41 foreign mode, if the equivalent GSM
36 feature code (MMI) is manually entered by the user, the mobile station is expected to issue the
37 necessary ANSI-13641 feature code to the network.
38 If the activation is accepted, the system shall indicate success using either GSM or ANSI-13641
39 signaling techniques depending on the mode of operation.
Ballot Version 19
N.S0028-0
1 The serving system may provide a courtesy call to the forward-to number shortly after this feature is
2 activated permitting the subscriber to verify the validity of the forward-to-number.
3 4.2.2.2.6 De-Activation
4 GSM foreign mode: CFU may be de-activated by a Demand Activation authorized subscriber
5 specifying the CFB de-activation feature code, as in:
*
6 FC0 + SEND .
7 Alternatively, if the mobile station offers menu driven control of de-activation, the mobile station is
8 expected to generate the equivalent GSM functional signaling.
9 ANSI-41 foreign mode: The user may deactivate CFU by means of an appropriate control procedure
10 (e.g., as described in GSM 02.30[11]). In ANSI-41 foreign mode, if the equivalent GSM feature code
11 (MMI) is manually entered by the user, the mobile station is expected to issue the necessary ANSI-
12 13641 feature code to the network.
13 If the de-activation is accepted, the system shall indicate success using either GSM or ANSI-13641
14 signaling techniques depending on the mode of operation. Registered information shall not be
15 erased.
16 CFU shall be de-activated upon de-authorization (withdrawal) or de-registration (erasure).
17 4.2.2.2.7 Invocation
18 The feature treatment is invoked unconditionally when there is an incoming call and CFU is active.
Ballot Version 20
N.S0028-0
4 4.2.2.4.1 Registration
5 If the system cannot accept a registration request, the served mobile subscriber shall receive a
6 notification that registration of call forwarding unconditional was not successful. Possible causes are:
7 service not subscribed to;
10 insufficient information;
16 4.2.2.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.2.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.2.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.
Ballot Version 21
N.S0028-0
1 None identified.
10 4.2.2.6.4 Barring of Outgoing International Calls except those directed to the Home PLMN
11 (BOIC-exHC)
12 None identified at this time.
15 4.2.2.6.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam)
16 None identified at this time.
Ballot Version 22
N.S0028-0
Ballot Version 23
N.S0028-0
1 None identified.
25
Ballot Version 24
N.S0028-0
21 4.2.3.2.3 Registration
22 If the subscriber is authorized for Fixed Registration, the forward-to number shall be registered upon
23 authorization (provision).
24 The CFB forward-to number may be registered by the service provider upon authorization (provision)
25 for Variable Registration subscribers. Mobile stations operating in foreign mode may attempt to
26 perform registration procedures normally supported in native mode.
27 GSM foreign mode: A forward-to-number may be registered by a Variable Registration authorized
28 subscriber specifying the CFB registration feature code and a forward-to number termination address
29 as in:
*
30 FC + termination address + SEND .Alternatively, if the mobile station offers menu driven control
31 of registration, the mobile station is expected to generate the equivalent GSM functional signaling
32 towards the network.
33 ANSI-41 foreign mode: Registration may take place with an appropriate control procedure by the
34 subscriber, per GSM 02.30[11]. In ANSI-41 foreign mode, if the equivalent GSM mode feature code
35 (MMI) is manually entered by the user, the mobile station is expected to issue the relevant ANSI-
36 13641 feature code entry.
Ballot Version 25
N.S0028-0
1 Alternatively, if the mobile station offers menu driven control of registration, the mobile station is
2 expected to generate the equivalent ANSI-13641 feature code entry and resulting call origination
3 based on the menu driven entry.
4 If the registration is accepted, the system shall indicate success using either GSM or ANSI-13641
5 signaling techniques depending on the mode of operation.
14 FC0 + SEND .
15 Alternatively, if the mobile station offers menu driven control of registration, the mobile station is
16 expected to generate the GSM functional signaling towards the network.
17 ANSI-41 foreign mode: The subscriber can specifically erase a previous registration with an
18 appropriate control procedure, per GSM 02.30[11]. In ANSI-41 foreign mode, if the equivalent GSM
19 mode feature code is manually entered by the user, the mobile station is expected to issue the
20 necessary ANSI-13641 feature code to the network.
21 CFB shall be de-registered upon de-authorization or withdrawal.
22 4.2.3.2.5 Activation
23 Mobile stations operating in foreign mode may attempt to perform Activation procedures normally
24 supported in native mode.
25 If the subscriber is authorized for Permanent Activation, CFB shall be activated upon authorization
26 (provision).
27 CFB may be activated upon registration for Demand Activation authorized subscribers. CFB may be
28 activated upon registration for Variable Registration authorized subscribers.
29 GSM foreign mode: A previously registered forward-to number may be activated by a Demand
30 Activation authorized subscriber specifying a CFB activation feature code, as in:
*
31 FC + SEND .
32 Alternatively, if the mobile station offers menu driven control of activation, the mobile station is
33 expected to generate the equivalent GSM functional signaling.
34 ANSI-41 foreign mode: The MS shall be allowed to activate CFB by for example using the MMI
35 command described in GSM 02.30[11]. In ANSI-41 foreign mode, if the equivalent GSM mode feature
36 code (MMI) is manually entered by the user, the mobile station is expected to issue the necessary
37 ANSI-13641 feature code to the network.
38 If the activation is accepted, the system shall indicate success with using either GSM or ANSI-13641
39 signaling techniques depending on the mode of operation.
Ballot Version 26
N.S0028-0
1 The serving system may provide a courtesy call to the forward-to number shortly after this feature is
2 activated permitting the subscriber to verify the validity of the forward-to number.
3 4.2.3.2.6 De-Activation
4 GSM foreign mode: CFB may be de-activated by a Demand Activation authorized subscriber
5 specifying the CFB de-activation feature code, as in:
*
6 FC0 + SEND .
7 Alternatively, if the mobile station offers menu driven control of de-activation, the mobile station is
8 expected to generate the equivalent GSM functional signaling.
9 ANSI-41 foreign mode: The user may deactivate CFB by means of an appropriate control procedure
10 (e.g., as described in GSM 02.30[11]). In ANSI-41 foreign mode, if the equivalent GSM mode feature
11 code (MMI) is manually entered by the user, the mobile station is expected to issue the necessary
12 ANSI-13641 feature code to the network.
13 If the de-activation is accepted, the system shall indicate success with using either GSM or ANSI-
14 13641 signaling techniques depending on the mode of operation. Registered information shall not be
15 erased.
16 CFB shall be de-activated upon de-authorization (withdrawal) or de-registration (erasure).
17 4.2.3.2.7 Invocation
18 The feature treatment is invoked when there is an incoming call while the subscriber is considered to
19 be busy (i.e., in any state other than the idle state) and CFB is active.
Ballot Version 27
N.S0028-0
4 4.2.3.4.1 Registration
5 If the system cannot accept a registration request, the served mobile subscriber shall receive a
6 notification that call forwarding on mobile subscriber busy registration was not successful. Possible
7 causes are:
8 service not subscribed to;
11 insufficient information;
17 4.2.3.4.3 Activation
18 If the subscriber is not authorized for the request, or if a forward-to number is not properly registered,
19 the system shall apply feature denial treatment when activation is attempted.
20 4.2.3.4.4 De-Activation
21 If the subscriber is not authorized for the request, the system shall apply feature denial treatment
22 when de-activation is attempted.
23 4.2.3.4.5 Invocation
24 If the forwarded call cannot be routed to the forward-to destination, then the call shall be given the
25 appropriate treatment, such as applying the Special Information Tone for intercept to the calling party.
26 Precautions shall be taken to preclude undesirable looping of forwarded numbers within the MSC or
27 between the MSC and other switching centers. If such looping is detected, the call forwarding shall be
28 given the appropriate treatment, such as applying the Special Information Tone for intercept to the
29 calling party.
Ballot Version 28
N.S0028-0
12 4.2.3.6.4 Barring of Outgoing International Calls except those directed to the Home PLMN
13 (BOIC-exHC)
14 None identified at this time.
17 4.2.3.6.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam)
18 None identified at this time.
Ballot Version 29
N.S0028-0
1 CFB is mutually exclusive with CFNA / CFNRy. That is, calls arriving to a busy subscriber with CFB
2 and CFNA / CFNRy active shall be forwarded by CFB and not given CFNA / CFNRy treatment.
Ballot Version 30
N.S0028-0
Ballot Version 31
N.S0028-0
Ballot Version 32
N.S0028-0
30 4.2.4.2.3 Registration
31 If the subscriber is authorized for Fixed Registration, the forward-to number shall be registered upon
32 authorization (provision). Mobile stations operating in foreign mode may attempt to perform
33 registration procedures normally supported in native mode.
34 The forward-to-number may be registered by the service provider upon authorization (provision) for
35 Variable Registration subscribers
36 GSM foreign mode: A forward-to-number may be registered by a Variable Registration authorized
37 subscriber specifying the CFNA registration feature code and a forward-to number termination
38 address as in:
Ballot Version 33
N.S0028-0
*
1 FC + termination address + SEND
2 Alternatively, if the mobile station offers menu driven control of registration, the mobile station is
3 expected to generate the equivalent GSM functional signaling towards the network.
4 ANSI-41 foreign mode: Registration can take place with an appropriate control procedure by the
5 subscriber, per GSM 02.30[11]. In ANSI-41 foreign mode, if the equivalent GSM feature code (MMI)
6 is manually entered by the user, the mobile station is expected to issue the relevant ANSI-13641
7 feature code entry.
8 Alternatively, if the mobile station offers menu driven control of registration, the mobile station is
9 expected to generate the equivalent ANSI-13641 feature code entry and resulting call origination
10 based on the menu driven entry.
11 If the registration is accepted, the system shall indicate success using either GSM or ANSI-13641
12 signaling techniques depending on the mode of operation.
21 FC0 + SEND .
22 Alternatively, if the mobile station offers menu driven control of registration, the mobile station is
23 expected to generate the equivalent GSM functional signaling towards the network.
24 ANSI-41 foreign mode: The subscriber can specifically erase a previous registration with an
25 appropriate control procedure, per GSM 02.30[11]. In ANSI-41 foreign mode, if the equivalent GSM
26 feature code (MMI) is manually entered by the user, the mobile station is expected to issue the
27 necessary ANSI-13641 feature code to the network.
28 CFNA/CFNRy/CFNRc shall be de-registered upon de-authorization or withdrawal.
29 4.2.4.2.5 Activation
30 Mobile stations operating in foreign mode may attempt to perform Activation procedures normally
31 supported in native mode.
32 If the subscriber is authorized for Permanent Activation, CFNA shall be activated upon authorization
33 (provision).
34 CFNA may be activated upon authorization or registration for Demand Activation authorized
35 subscribers. CFNA may be activated upon registration for Variable Registration authorized
36 subscribers.
37 GSM foreign mode: A previously registered forward-to-number may be activated by a Demand
38 Activation authorized subscriber specifying a CFNA activation feature code, as in:
*
39 FC + SEND .
Ballot Version 34
N.S0028-0
1 Alternatively, if the mobile station offers menu driven control of activation, the mobile station is
2 expected to generate the equivalent GSM functional signaling.
3 ANSI-41 foreign mode: The MS shall be allowed to activate CFNRy/CFNRc by using an appropriate
4 control procedure (e.g. using the MMI command described in GSM 02.30[11]). In ANSI-41 foreign
5 mode, if the equivalent GSM feature code (MMI) is manually entered by the user, the mobile station is
6 expected to issue the necessary ANSI-13641 feature code to the network.
7 If the activation is accepted, the system shall indicate success using either GSM or ANSI-13641
8 signaling techniques depending on the mode of operation.
9 The serving system may provide a courtesy call to the forward-to number shortly after this feature is
10 activated permitting the subscriber to verify the validity of the forward-to-number.
11 4.2.4.2.6 De-Activation
12 GSM foreign mode: CFNA may be de-activated by a Demand Activation authorized subscriber
13 specifying the CFNA de-activation feature code, as in:
*
14 FC0 + SEND .
15 Alternatively, if the mobile station offers menu driven control of de-activation, the mobile station is
16 expected to generate the equivalent GSM functional signaling.
17 ANSI-41 foreign mode: The user may deactivate CFNRy/CFNRc by means of an appropriate control
18 procedure (e.g., as described in GSM 02.30[11]). In ANSI-41 foreign mode, if the equivalent GSM
19 feature code (MMI) is manually entered by the user, the mobile station is expected to issue the
20 necessary ANSI-13641 feature code to the network.
21 If the de-activation is accepted, the system shall indicate success using either GSM or ANSI-13641
22 signaling techniques depending on the mode of operation. Registered information shall not be
23 erased.
24 CFNA/CFNRy/CFNRc shall be de-activated upon de-authorization (withdrawal) or de-registration
25 (erasure).
26 4.2.4.2.7 Invocation
27 The feature treatment is invoked when there is an incoming call and either CFNA, CFNRy or CFNRc
28 is active and the necessary conditions have been met – see GSM 02.82[15] and ANSI-664[1].
Ballot Version 35
N.S0028-0
4 4.2.4.4.1 Registration
5 If the system cannot accept a registration request, the served mobile subscriber shall receive a
6 notification that registration of CFNA/CFNRy/CFNRc was not successful. Possible causes are:
7 service not subscribed to;
10 insufficient information;
16 4.2.4.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.4.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.4.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.
Ballot Version 36
N.S0028-0
1 None identified.
10 4.2.4.6.4 Barring of Outgoing International Calls except those directed to the Home PLMN
11 (BOIC-exHC)
12 None identified at this time.
15 4.2.4.6.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam)
16 None identified at this time.
Ballot Version 37
N.S0028-0
1 None identified.
2
Ballot Version 38
N.S0028-0
Ballot Version 39
N.S0028-0
28
Ballot Version 40
N.S0028-0
21 4.2.5.2.3 Registration
22 If the subscriber is authorized for Fixed Registration, the forward-to number shall be registered upon
23 authorization (provision). Mobile stations operating in foreign mode may attempt to perform
24 registration procedures normally supported in native mode.
25 The forward-to-number may be registered by the service provider upon authorization (provision) for
26 Variable Registration subscribers
27 GSM foreign mode: A forward-to-number may be registered by a Variable Registration authorized
28 subscriber specifying the CFD registration feature code and a forward-to number termination address
29 as in:
*
31 Alternatively, if the mobile station offers menu driven control of registration, the mobile station is
32 expected to generate the equivalent GSM functional signaling towards the network.
33 If the registration is accepted, the system shall indicate success using either GSM signaling
34 techniques.
Ballot Version 41
N.S0028-0
1 A forward-to-number may be de-registered upon de-activation (at the home service provider option).
2 GSM foreign mode: If the de-registration is to be separate from de-activation, the de-registration
3 feature code must be distinct from the corresponding de-activation feature code.
4 GSM foreign mode: CFD may be de-registered by a Variable Registration authorized subscriber
5 specifying the CFD de-registration feature code, as in:
*
6 FC0 + SEND .
7 Alternatively, if the mobile station offers menu driven control of registration, the mobile station is
8 expected to generate the equivalent GSM functional signaling towards the network.
9 CFD shall be de-registered upon de-authorization or withdrawal.
10 4.2.5.2.5 Activation
11 Mobile stations operating in foreign mode may attempt to perform Activation procedures normally
12 supported in native mode.
13 If the subscriber is authorized for Permanent Activation, CFD shall be activated upon authorization
14 (provision).
15 CFD may be activated upon authorization or registration for Demand Activation authorized
16 subscribers. CFD may be activated upon registration for Variable Registration authorized subscribers.
17 GSM foreign mode: A previously registered forward-to-number may be activated by a Demand
18 Activation authorized subscriber specifying a CFD activation feature code, as in:
*
19 FC + SEND .
20 Alternatively, if the mobile station offers menu driven control of activation, the mobile station is
21 expected to generate the equivalent GSM functional signaling.
22 If the activation is accepted, the system shall indicate success using GSM or ANSI-13641 signaling
23 techniques.
24 The serving system may provide a courtesy call to the forward-to number shortly after this feature is
25 activated permitting the subscriber to verify the validity of the forward-to-number.
26 4.2.5.2.6 De-Activation
27 GSM foreign mode: CFD may be de-activated by a Demand Activation authorized subscriber
28 specifying the CFD de-activation feature code, as in:
*
29 FC0 + SEND .
30 Alternatively, if the mobile station offers menu driven control of de-activation, the mobile station is
31 expected to generate the equivalent GSM functional signaling.
32 If the de-activation is accepted, the system shall indicate success using either GSM signaling
33 techniques. Registered information shall not be erased.
34 CFD shall be de-activated upon de-authorization (withdrawal) or de-registration (erasure).
35
Ballot Version 42
N.S0028-0
2 4.2.5.2.7 Invocation
3 The feature treatment is invoked when there is an incoming call, CFD is active and the necessary
4 conditions have been met – See ANSI-664[1].
16 4.2.5.4.1 Registration
17 If the system cannot accept a registration request, the served mobile subscriber shall receive a
18 notification that registration of CFD was not successful. Possible causes are:
19 service not subscribed to;
22 insufficient information;
28 4.2.5.4.3 Activation
29 If the subscriber is not authorized for the request, or if a forward-to-number is not properly registered,
30 the system shall apply feature denial treatment when activation is attempted.
31 4.2.5.4.4 De-Activation
32 If the subscriber is not authorized for the request, the system shall apply feature denial treatment
33 when de-activation is attempted.
34
Ballot Version 43
N.S0028-0
2 4.2.5.4.5 Invocation
3 If the forwarded call cannot be routed to the forward-to-destination, then the call shall be given the
4 appropriate treatment, such as applying the Special Information Tone for intercept to the calling party.
5 Precautions shall be taken to preclude undesirable looping of forwarded numbers within the MSC or
6 between the MSC and other switching centers. If such looping is detected, the call forwarding shall be
7 given the appropriate treatment, such as applying the Special Information Tone for intercept to the
8 calling party.
Ballot Version 44
N.S0028-0
1 If the calling number indicates presentation restricted, the calling number shall not be presented to
2 the called party or the forward-to-party.
3 If the called (redirecting) subscriber has CFD active and CNIR is either Permanently Restricted or the
4 default is Presentation Restricted, the redirecting number shall indicate presentation restricted to
5 prevent presentation to the forward-to-party or to the forward-to station.
Ballot Version 45
N.S0028-0
1 None identified.
2
Ballot Version 46
N.S0028-0
Ballot Version 47
N.S0028-0
Ballot Version 48
N.S0028-0
1 For GSM and ANSI-41 based network interoperability, no new or special recording capabilities are
2 needed.
Ballot Version 49
N.S0028-0
1 Barring of Incoming Calls when Roaming Outside the Home PLMN Country (BIC-Roam)
2 No impact.
Ballot Version 50
N.S0028-0
Ballot Version 51
N.S0028-0
Ballot Version 52
N.S0028-0
Ballot Version 53
N.S0028-0
4 4.4.2.3 Registration
5 CW has no registration.
8 4.4.2.5 Activation
9 In both GSM and ANSI-41 foreign modes, the subscriber shall be provided with menu selections by
10 the mobile station to allow him/or her to activate the call waiting feature. Menu selections shall also be
11 available to the subscriber while in native mode as well. In addition, the user may also be able to
12 activate call waiting (depending on individual service provider’s preference) through the use of the
13 keypad, as follows:
14 ANSI-13641 native and foreign modes:
15 CW may be activated upon authorization.
16 CW may be activated by a Demand Activation authorized subscriber specifying a CW activation
17 feature code, as in:
*
18 FC + SEND .
19 If the activation is accepted, the system shall indicate success with feature confirmation treatment.
20
21 GSM native and foreign modes: This supplementary service shall be activated either collectively
22 for all applicable Basic Services or on a Basic Service group basis by the subscriber using a control
23 procedure, as specified in GSM 02.30[11], or by the service provider. The controlling subscriber shall
24 be informed by the network of the success or otherwise of her action.
25 4.4.2.6 De-Activation
26 In both GSM and ANSI-41 foreign modes, the subscriber shall be provided with menu selections by
27 the mobile station to allow him/or her to de-activate the call waiting feature. Menu selections shall
28 also be available to the subscriber while in native mode as well. In addition, the user may also be able
29 to de-activate call waiting (depending on individual service provider’s preference) through the use of
30 the keypad, as follows:
31 ANSI-13641 native and foreign mode:
32 CW shall be de-activated upon de-authorization.
33 CW Demand De-Activation:
34 CW may be de-activated by a Demand Activation authorized subscriber specifying a CW
35 de-activation feature code, as in:
*
36 FC0 + SEND .
Ballot Version 54
N.S0028-0
1 If the de-activation is accepted, the system shall indicate success with feature confirmation treatment.
2 Temporary Cancellation During a Call (ANSI-13641 Native Mode Only):
3 CW may be canceled during a single call by a Demand Cancellation authorized subscriber issuing a
4 flash request and then specifying a CCW feature code, as in:
*
5 FC0 + SEND .
6 If the cancellation is accepted, the system may indicate success with feature confirmation treatment
7 and then reconnect the call. At the completion of the call, CW shall resume the activation state prior
8 to using the cancel CW feature code.
9 Temporary Cancellation With a Call Setup Request (ANSI-13641 Native Mode Only):
10 CW may be canceled for a single call concurrently with a call request by a Demand Cancellation
11 authorized subscriber specifying a CCW feature code and a termination address, as in:
*
13 Alternatively:
*
15 is possible, if a fixed length Temporary Cancellation feature code is distinct from the de-activation
16 feature code.
17 If the cancellation is accepted, the system may indicate success with feature confirmation treatment
18 and then the call is allowed to proceed toward the termination address. At the completion of the call,
19 CW shall resume the activation state prior to using the cancel CW feature code.
20 GSM native and foreign mode: The service shall be deactivated either collectively for all applicable
21 Basic Services or on a Basic Service group basis by the subscriber using a control procedure, as
22 specified in GSM 02.30[11], or by the service provider. The controlling subscriber shall be informed
23 by the network of the success or otherwise of her action.
24 4.4.2.7 Invocation
25 CW is invoked when a incoming call attempt arrives for a subscriber who is already engaged in
26 conversation on a prior call, who does not have another call waiting, and who has CW active.
27 There are functions or actions which exist on GSM (in GSM 02.83[16]), but do not exist in ANSI-
28 13641, and vice versa (see charts below). In order to achieve a seamless user Interface when
29 roaming, it would be better to either provide the menu selections as it is in a GSM handset, or some
30 other mechanism that can achieve the same goal.
Ballot Version 55
N.S0028-0
1 The following tables describe the call party actions and system reactions for CW on GSM and ANSI-
2 13641.
Ballot Version 56
N.S0028-0
1
2 The CW notification may be an audible Call Waiting Tone injected into the voice path, a message on
3 the alphanumeric display, or both.
Ballot Version 57
N.S0028-0
6 4.4.3.2 Interrogation
7 In foreign modes, the interrogation procedure is not supported.
8 GSM native mode
Ballot Version 58
N.S0028-0
1 The controlling subscriber may interrogate the network by the use of a control procedure, as specified
2 in GSM 02.30[11]. The network shall respond with an appropriate indication telling the subscriber
3 whether the service is supported in this network and, if so, provide a list of all Basic Service groups to
4 which the Call waiting supplementary service is active.
7 4.4.4.1 Registration
8 None identified.
11 4.4.4.3 Activation
12 If the subscriber is not authorized for the request, the system shall apply feature denial treatment
13 when activation is attempted.
14 4.4.4.4 De-Activation
15 Demand De-Activation: If the subscriber is not authorized for the request, the system shall apply
16 feature denial treatment when de-activation is attempted.
17 Temporary Cancellation (ANSI-13641 native mode only): If the subscriber is not authorized for
18 the request, the system shall apply feature denial treatment when de-activation is attempted.
19 Temporary Cancellation With a Call Setup Request (ANSI-13641 native mode only): If the
20 subscriber is not authorized for a Temporary Cancellation request made concurrently with a call setup
21 request, the system shall apply feature denial treatment and the call setup shall be denied.
22 4.4.4.5 Invocation
23 If the controlling subscriber is not authorized, if the controlling subscriber is alerting the other party, or
24 if resources are not available; give the calling party busy treatment. Remain in the 2-way state.
Ballot Version 59
N.S0028-0
7 4.4.6.4 Barring of Outgoing International Calls except those directed to the Home PLMN
8 (BOIC-exHC)
9 None identified.
12 4.4.6.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam)
13 None identified.
Ballot Version 60
N.S0028-0
Ballot Version 61
N.S0028-0
1 DND takes precedence over CW. That is, calls arriving for a subscriber with DND and CW active shall
2 be refused and not be given CW treatment.
Ballot Version 62
N.S0028-0
Ballot Version 63
N.S0028-0
26 4.5.2.3 Registration
27 3WC/MPTY has no registration.
30 4.5.2.5 Activation
31 3WC/MPTY is activated upon authorization.
32 4.5.2.6 De-Activation
33 3WC/MPTY shall be de-activated upon de-authorization.
Ballot Version 64
N.S0028-0
1 4.5.2.7 Invocation
2 ANSI-13641 Mode: 3WC is invoked when the appropriate flash request is sent and the feature is
3 authorized.
4 GSM Mode: Multi-Party service is invoked by the served mobile subscriber by use of a control
5 procedure, as defined in GSM 02.30[11].
Ballot Version 65
N.S0028-0
1 If the third party answers, the system allows a conversation with the third party.
2 If the third party disconnects, the system releases the third party. Connects the held party.
3 If an incoming call arrives for the controlling subscriber, the system applies busy treatment to the
4 calling party.
5 If the held party disconnects, the system releases the held party.
6 4. A connection is established between the controlling subscriber, a second party and a third party.
7 If the controlling subscriber presses the SEND key without digits, the system releases the third
8 party. Connect the controlling subscriber and the second party.
9 If the controlling subscriber presses the END key, the system releases the controlling subscriber
10 and two other parties.
11 If the controlling subscriber enters digits + SEND key, the system ignores any accompanying
12 digits. Releases the third party. Connect the controlling subscriber and the second party.
13 If the third party answers, the system allows a conversation with the third party.
14 If the third party disconnects, the system releases the third party and connects the controlling
15 subscriber and the second party.
16 If an incoming call arrives for the controlling subscriber, the system applies busy treatment to the
17 calling party.
18 If the second party disconnects, the system releases the second party. Connect the controlling
19 subscriber and the third party.
Ballot Version 66
N.S0028-0
1 Call Waiting request from this state. While the multi-party call is on hold the remaining remote
2 parties in the multi-party call can have communication with each other.
3 As a result of this scenario, the inquiry call or the accepted waiting call can be added to the multi-
4 party call or released. If the call is released by the served mobile subscriber or by the remote
5 party, the served mobile subscriber is in control of a held multi-party call.
6 A Hold notification (according to GSM 02.83[16]) shall be sent towards all remote parties.
7 3. Separate a remote party:
8 Explicitly choose one remote party to have a private communication with. This results in that
9 remote party being removed from the multi-party call which is placed on hold, and the conversation
10 between the served mobile subscriber and the designated remote party being a normal active call.
11 The remaining remote parties may have communication with each other in this state.
12 As a result of this scenario the private communication can be added again to the multi-party call or
13 released. If the private call is released by the served mobile subscriber or by the remote party, the
14 served mobile subscriber is in control of a held multi-party call.
15 A Hold notification (according to GSM 02.83[16]) shall be sent towards all remote parties, except
16 the designated remote party to which a private communication was established.
17 4. Terminate the entire multi-party call.
18 When the served mobile subscriber releases, this is interpreted as a request for termination of the
19 entire multi-party call even if there are calls on hold.
20 No further notification shall be sent.
21 5. Disconnect a remote party:
22 Explicitly release the remote parties on a one at a time basis. In the case when no remote parties
23 remain, the multi-party call is terminated.
24 The notification about the held multiparty call towards the served mobile subscriber is given by
25 the MS, not by the network.
Ballot Version 67
N.S0028-0
Ballot Version 68
N.S0028-0
4 4.5.3.4 Interrogation
5 GSM mode
6 The controlling subscriber may interrogate the network by the use of a control procedure, as specified
7 in GSM 02.30[11]. The network shall respond with an appropriate indication telling the subscriber
8 whether the service is supported in this network and, if so, provide a list of all Basic Service groups to
9 which the Call waiting supplementary service is active.
12 4.5.4.1 Registration
13 None identified.
16 4.5.4.3 Activation
17 None identified.
18 4.5.4.4 De-Activation
19 None identified.
20 4.5.4.5 Invocation
21 ANSI-13641 Mode
22 The controlling subscriber is alerting the other party, or the controlling subscriber is in a two-way
23 conversation with the other party, if the controlling subscriber presses the SEND key, the system
24 applies denial treatment. Retain connections.
25 One party is on hold, and the system is waiting for the controlling subscriber to enter a feature code
26 or the address of a third party,
27 if the controlling subscriber enters the termination address + SEND key, if the subscriber is not
28 authorized for the request, resources are not available, or the termination address was not
29 acceptable; then ignore any accompanying digits and the system applies denial treatment. Retain
30 existing connection to party on hold.
31 if the controlling subscriber enters *FC + SEND key, if the subscriber is not authorized for the request,
32 resources are not available, or the termination address was not acceptable; then ignore any
33 accompanying digits and the system applies denial treatment. Retain existing connection to party on
34 hold.
35 if the controlling subscriber enters *FC + # + termination address + SEND key, if the subscriber is not
36 authorized for the request, resources are not available, or the termination address was not
Ballot Version 69
N.S0028-0
1 acceptable; then ignore any accompanying digits and the system applies denial treatment. Retain
2 existing connection to party on hold.
3 GSM Mode
4 If a served mobile subscriber attempts to invoke multi-party service and the network cannot accept
5 that request, the request shall be rejected and an indication shall be given to the served mobile
6 subscriber with a reason for denial. Some possible reasons for rejection are:
7 service not subscribed;
10 calls are not in appropriate state (e.g., one or more calls are not answered or are in the process
11 of being cleared);
12 service not supported by the local PLMN.
13 If the service provider cannot satisfy the request to add a further remote party (e.g., if the multi-party
14 call has been cleared or if the maximum number of remote parties allowed has already been reached)
15 the served mobile subscriber shall receive an indication that the request is denied, with the reason for
16 failure.
17 If the radio path of the served mobile subscriber is lost permanently for any reason, the multi-party
18 call shall be released.
29 If the controlling subscriber enters a termination address + SEND , the system puts the other party
30 on hold. Atempts to establish a connection to the termination address.
31 If the controlling subscriber enters a termination address + SEND , if the other party is alerting, the
32 controlling subscriber is not authorized for the request, resources are not available, or the
33 termination address was not acceptable; the system applies denial treatment. Reconnects the
34 controlling subscriber and the second party.
35 If the controlling subscriber enters *FC + # + termination address + SEND , the system acts upon
36 the feature code. The system applies feature confirmation treatment. Puts the other party on
37 hold. Attempts to establish a connection to the termination address.
Ballot Version 70
N.S0028-0
1 If the controlling subscriber enters *FC + # + termination address + SEND , the system acts upon
2 the feature code. If the other party is alerting, the controlling subscriber is not authorized for the
3 request, resources are not available, or the termination address was not acceptable; the system
4 applies for denial treatment. Reconnects the controlling subscriber and the second party.
5
6 GSM Mode
7 None identified.
8
17 4.5.6.4 Barring of Outgoing International Calls except those directed to the Home PLMN
18 (BOIC-exHC)
19 None identified.
22 4.5.6.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam)
23 None identified.
Ballot Version 71
N.S0028-0
1 None identified.
Ballot Version 72
N.S0028-0
1 If the 3WC controlling subscriber activates the Temporary CNIR Mode during the setup of a 3WC leg,
2 then the Temporary CNIR activation applies only to that call leg.
3 If the 3WC controlling subscriber de-activates the Temporary CNIR Mode during the setup of a 3WC
4 leg, then the Temporary CNIR de-activation applies only to that call leg.
Ballot Version 73
N.S0028-0
1 None identified.
Ballot Version 74
N.S0028-0
17 4.6.2.1 ANSI-41 foreign mode Capabilities (GSM --> ANSI-13641 Feature Mapping)
18 The ability of the subscriber’s serving system to override calling number or line presentation
19 restriction invoked from the calling party’s serving system or PLMN is not supported.
20 Connected Line Identification Presentation and Restriction (COLP / COLR) is not supported.
21 Interrogation of the status of CLIP is not supported.
22 4.6.2.2 GSM Foreign Mode Capabilities (ANSI-13641 --> GSM Feature Mapping)
23 The ability to display multiple calling party numbers, a sub-address, or a redirecting number is not
24 explicitly defined.
25 If the called subscriber has call forwarding unconditional active, the ability to present the calling
26 number identification to the subscriber during an abbreviated (or reminder) alert is not supported.
32 4.6.3.3 Registration
Ballot Version 75
N.S0028-0
4 4.6.3.5 Activation
5 CNIP / CLIP shall be activated upon authorization (or provision).
6 4.6.3.6 De-Activation
7 CNIP / CLIP shall be de-activated upon de-authorization (or withdrawal).
8 4.6.3.7 Invocation
9 The network automatically invokes CNIP / CLIP upon incoming call set-up when calling number
10 identification is available and presentation is not restricted.
26 4.6.4.2 Interrogation
27 GSM mode only: The subscriber can request the status of the CLIP supplementary service.
28
31 4.6.5.1 Registration
32 None identified.
Ballot Version 76
N.S0028-0
1 None identified.
2 4.6.5.3 Activation
3 None identified.
4 4.6.5.4 De-Activation
5 None identified.
6 4.6.5.5 Invocation
7 In some situations with insufficient signaling capability, if the calling party number identification is not
8 available, the called party / subscriber shall receive an indication that calling number identity is not
9 available. This indication may include an alphanumeric display indicatingnumber not available.
10 For an international call with calling party number identification not available, the called party /
11 subscriber shall receive an indication that calling number identity is not available. This indication may
12 include an alphanumeric display indicating number not available.
30 4.6.7.4 Barring of Outgoing International Calls except those directed to the Home PLMN
31 (BOIC-exHC)
32 None identified.
Ballot Version 77
N.S0028-0
3 4.6.7.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam)
4 When BIC-Roam is active and invoked, the subscriber shall receive no calling party identification or
5 display.
Ballot Version 78
N.S0028-0
Ballot Version 79
N.S0028-0
1 None identified.
Ballot Version 80
N.S0028-0
27 Barring of roaming
32 The operator may select a barring program that prevents certain types of outgoing calls from being
33 originated by the MS.
34 ODB in GSM is documented in GSM 02.41[12]. Call Barring Supplementary Services in GSM is
35 documented in GSM 02.88[20].
36 Barring of outgoing calls with a wider range of conditions can be implemented using the ANSI-41
37 Origination Indicator parameter, which is provided by the HLR to the serving MSC/VLR upon
38 subscriber registration, as defined in Chapter 5 of ANSI-41[3]. The Origination Indicator specifies
39 which types of call originations are permitted, as opposed to which types of call originations are
40 barred or restricted in GSM.
Ballot Version 81
N.S0028-0
1 The main problem for roaming interoperability is that for GSM and ANSI-41 the call barring programs
2 are based on different screening criteria. In GSM barring is based on the concept of PLMN, and calls
3 are generally permitted to all terminals within the country of a particular PLMN (i.e., fixed and mobile
4 terminals). ANSI-41 allows more specific barring programs such as ‘local calls only’, or a specific DN.
5 As a result of this conflict, IIF functionality is required to support subscribers using their non-native
6 mode.
7 The mapping of GSM and ANSI-41 outgoing barring conditions may be accomplished as follows:
Allow single directory number only Bar all outgoing calls (BAOC)
(i.e., hotline)
11
Ballot Version 82
N.S0028-0
23 4.7.2.1 Activation
Ballot Version 83
N.S0028-0
1 4.7.2.2 De-activation
4 4.7.2.3 Invocation
5 Call Barring and ODB are invoked automatically by the network for subscribers that have it active,
6 upon subscriber or network actions that are barred.
22 4.7.4.1 Provisioning
23 Since GSM PLMNs may not support many of the provisioning criteria in ANSI-41 networks, service
24 provisioning shall revert to the closest available criterion as described above.
Ballot Version 84
N.S0028-0
Ballot Version 85
N.S0028-0
1 CB/ODB takes precedence over CFD. If an incoming call arrives for a subscriber with CB/ODB and
2 CFD active, the call is screened by CB/ODB first. If CB and ODB accepts the call, an attempt is made
3 to deliver or terminate the call to the subscriber. If the subscriber does not or cannot answer the call,
4 then CFD is invoked.
5 If CFD is in contravention of a Call Barring / Operator Determined Barring Category, when the latter is
6 activated, then the activation shall result in making CFD quiescent. If the subscriber attempts to
7 activate a new CFD program in contravention of a Call Barring / Operator Determined Barring
8 Category, then the activation shall be denied, and the subscriber informed of the denial.
9 Call Forwarding—No Answer (ANSI-13641 CFNA = GSM CF No Reply (CFNRy) and GSM CF Not
10 Reachable (CFNRc))
11 CB/ODB takes precedence over CFNA. If an incoming call arrives for a subscriber with CB/ODB and
12 CFNA active, the call is screened by CB/ODB first. If CB and ODB accepts the call, an attempt is
13 made to deliver or terminate the call to the subscriber. If the subscriber does not or cannot answer the
14 call, then CFNA is invoked.
15 If CFNA is in contravention of a Call Barring / Operator Determined Barring Category, when the latter
16 is activated, then the activation shall result in making CFNA quiescent. If the subscriber attempts to
17 activate a new CFNA program in contravention of a Call Barring / Operator Determined Barring
18 Category, then the activation shall be denied, and the subscriber informed of the denial.
Ballot Version 86
N.S0028-0
Ballot Version 87
N.S0028-0
1 None identified.
Ballot Version 88
N.S0028-0
43
Ballot Version 89
N.S0028-0
16 4.8.2.3 Registration
17 Mobile terminated SMS teleservice registration shall be as a result of Authorization.
18 For mobile originated SMS teleservices the following information shall be registered in the mobile
19 station:
20 SMS-C address(es) as needed for different mobile originated SMS teleservices or applications.
25 4.8.2.5 Activation
26 Both mobile originated and mobile terminated SMS teleservices shall be activated as the result of
27 authorization. When operating in GSM or ANSI-41 foreign mode, there is no special activation
28 process required.
29 4.8.2.6 De-Activation
30 Both mobile originated and mobile terminated SMS teleservice de-activation shall be the result of de-
31 authorization. When operating in GSM or ANSI-41 foreign mode, there is no special de-activation
32 process required.
33
Ballot Version 90
N.S0028-0
1 4.8.2.7 Invocation
2 Invocation shall be the result of:
3 A mobile station needing to send user data to another Short Message Entity (SME).
5 4.8.2.8 Interrogation
6 Interrogation shall not be possible for mobile terminated SMS teleservices.
7 For mobile originated SMS teleservices, the user shall be able to interrogate if they have any SMS-C
8 addresses registered on their mobile station.
15 For mobile originated SMS teleservices, the following normal operation applies. The mobile station
16 shall send user data to the network including the following information:
17 Destination address;
20 If notification is required.
Ballot Version 91
N.S0028-0
1 4.8.4.3 Registration
2 None identified at this time.
5 4.8.4.5 Activation
6 Not applicable.
7 4.8.4.6 De-Activation
8 Not applicable.
9 4.8.4.7 Invocation
10 For mobile terminated teleservices, if the SMS-C attempts to deliver user data to the mobile station
11 and is unsuccessful, an indication shall be presented to the SMS-C. Possible causes may include:
12 insufficient network resources;
16 insufficient information;
17 conflicting situation with other supplementary services (e.g., call barring has been activated);
19 For mobile originated teleservices, if the mobile station attempts to deliver user data to the network
20 and is unsuccessful, the user shall be presented with an indication. Possible causes may include:
21 insufficient network resources
24 insufficient information;
25 conflicting situation with other supplementary services (e.g., call barring has been activated).
26 4.8.4.8 Interrogation
27 Not applicable.
Ballot Version 92
N.S0028-0
11 4.8.6.4 Barring of Outgoing International Calls except those directed to the Home PLMN
12 (BOIC-exHC)
13 Per GSM 02.04[9], BOIC-exHC shall inhibit SMS origination, but this interaction is generally not
14 invoked.
17 4.8.6.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam)
18 Per GSM 02.04[9], BIC-Roam shall inhibit SMS delivery, but this interaction is generally not invoked.
Ballot Version 93
N.S0028-0
1 None Identified
Ballot Version 94
N.S0028-0
1 None Identified
Ballot Version 95
N.S0028-0
23 4.9.1.2.1 ANSI-41 foreign mode Capabilities (GSM --> ANSI-13641 Feature Mapping)
24 MWN is done via an MS display message waiting indication. An MS display message waiting count is
25 provided to the MS as available. The MS shall be capable of receiving the count.
26 MWN via an MS display indication may be supplemented with audible pip tone alerting.
27 4.9.1.2.2 GSM Foreign Mode Capabilities (ANSI-13641 --> GSM Feature Mapping)
28 Audible pip tone notification is not supported, but MS display indication shall be provided as required.
29 The ability to activate and de-activate various means of MWN alerting shall not be supported.
Ballot Version 96
N.S0028-0
5 4.9.2.3 Registration
6 MWN is registered upon authorization.
9 4.9.2.5 Activation
10 MWN shall be activated upon authorization. Activation on demand by the subscriber, as described in
11 ANSI-664[1], shall be optionally supported in ANSI-13641 native mode only.
12 4.9.2.6 De-Activation
13 MWN shall be de-activated upon de-authorization.
14 4.9.2.7 Invocation
15 MWN alert pip tone is invoked when the first voice message is left in a VMS for a particular
16 subscriber. MWN alert pip tone is also invoked upon MS power up and there is one or more
17 unretrieved voice messages in the VMS. Alert pip tone notification is provided when authorized by the
18 service provider in ANSI-13641 mode only.
19 MWN pip tone is invoked when a voice message is left and remains unretrieved in a Voice Message
20 System (VMS) for a particular subscriber, and the subscriber originates a call or answers an incoming
21 call. Pip tone notification is provided when authorized by the service provider in ANSI-13641 mode
22 only.
23 MS display indication is invoked when a voice message is left in a VMS for a particular subscriber. It
24 is also invoked when ANSI-41 registration procedures are invoked for a subscriber and there is an
25 unretrieved voice message in the VMS for the subscriber. In ANSI-13641 mode, the message waiting
26 count indication may be updated each time the number of messages in the VMS changes.
Ballot Version 97
N.S0028-0
1 For GSM and ANSI-41 based network interoperability, no new or special recording capabilities are
2 needed.
3 4.9.3.2 Interrogation
4 Not applicable
7 4.9.4.1 Registration
8 None identified.
11 4.9.4.3 Activation
12 None identified.
13 4.9.4.4 De-Activation
14 None identified.
15 4.9.4.5 Invocation
16 None identified.
Ballot Version 98
N.S0028-0
3 4.9.6.4 Barring of Outgoing International Calls except those directed to the Home PLMN
4 (BOIC-exHC)
5 None identified.
8 4.9.6.6 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam)
9 None identified.
Ballot Version 99
N.S0028-0
15
25 4.10.2.3 Authentication
26 The GPRS network shall query the IIF, acting as a GPRS HLR, to verify the authentication
27 parameters. This may occur upon with GPRS attach and GPRS routing area update operations.
33 ANSI-41 registration in all of these conditions shall result in a cancel location towards one or both of
34 the GSM MSC and GPRS SGSN, if the subscriber is registered to that network element.
1 The MS shall perform a GPRS attach to access GPRS services. This can be immediately after the
2 MS has been switched on or later as the user decides to use the GPRS service.
3 A successful GPRS attach requires a valid GPRS subscription.
4 The GPRS attach itself may be performed as one of the following:
5 GPRS only attach; or
6 GPRS attach when GSM CS attached; or
7 combined GPRS and GSM CS attach.
8 If one of the above GPRS attaches takes place when previously registered on an ANSI-41 network,
9 normal registration cancellation within the ANSI-41 network shall take place.
1 When operating GPRS in GSM Foreign mode, and both GPRS attached and GSM CS
2 attached, the mobile may originate mobile-originated SMS messages either thru the GSM
3 network or the GPRS network. When operating only in GPRS mode, SMS originations thru the
4 GPRS network shall be possible.
5 When operating GPRS in GSM Foreign mode, and both GPRS attached and GSM CS
6 attached, the mobile shall receive mobile-terminated SMS messages either thru the GSM
7 network or the GPRS network. When operating in GPRS only mode, SMS terminations shall be
8 possible.
9 For GSM native subscribers in GSM native mode, the GSM SMS Service Center (i.e., SMSC) queries
10 the combined GSM-GPRS HLR for routing information and the HLR responds with both the SGSN
11 address as well as the GSM MSC address. Then the SMSC decides to send the SMS message to
12 either the GPRS SGSN or the GSM MSC.
13 For GPRS in GSM Foreign Mode the ANSI MC shall query the ANSI-41 HLR for the ANSI-41 MSC
14 address and shall be instructed to route the ANSI-41 formatted SMS message to the IIF, emulating
15 both an ANSI-41 MSC and a GSM SMSC, for any of the following conditions:
16 when the subscriber is both GSM CS attached and GPRS attached; or
19 The IIF shall then convert the mobile-terminated ANSI-41 SMS message to a GSM-formatted SMS
20 message and, acting like a GSM SMSC, send it to the GSM MSC or the GPRS SGSN. If the MS is
21 reachable a Network option for routing the SMS messages may be as follows:
22 first - send to the GPRS SGSN;
1 None identified.
10 4.10.5.2 Authentication
11 GSM authentication procedures are required to be supported by the IIF in the GPRS home network.
12 For GPRS in GSM Foreign Mode the authentication procedure is done according to the procedures
13 defined in GSM 02.09[21].
20 4.10.5.5 Barring of Outgoing International Calls except those directed to the Home PLMN
21 (BOIC-exHC)
22 ODB_BOIC-exHC may be provisioned in the IIF, emulating a GPRS HLR, and it applies to Mobile
23 Originated SMS via the GPRS network.
30 4.10.5.8 Barring of Incoming Calls when Roaming Outside the Home PLMN (BIC-Roam)
31 None identified.
1 When a subscriber receives a call termination attempt when operating in GSM foreign mode (e.g.,
2 ASNI-41, TDMA or CDMA136 native subscriber) and connected to a GPRS network, the GSM
3 Circuit-switched paging is sent through the GPRS SGSN and the IIF is not impacted.1
4 Call terminations to the subscriber (e.g., ANSI-41, TDMA or CDMA136 native subscriber) operating in
5 GPRS only mode shall not be possible. However, it is possible for the IIF to send a SMS message to
6 the user thru the GPRS network indicating the calling party number of the missed call.
1 None identified.
1 None identified.
1 Abstract
2 This standard addresses the interworking and interoperability between ANSI-41 MAP and GSM MAP
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 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 2 – Information Flows
11
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.
1 Contents
2Abstract ..............................................................................................................................................i
6Foreword .......................................................................................................................................xxiii
71 Introduction ...........................................................................................................................1
8 1.1 General........................................................................................................................1
9 1.2 Purpose .......................................................................................................................1
10 1.3 Scope ..........................................................................................................................1
11 1.4 Organization ................................................................................................................1
122 References............................................................................................................................3
30 Abstract .........................................................................................................................................i
36 1 Introduction ...........................................................................................................................1
37 1.1 General........................................................................................................................1
38 1.2 Purpose .......................................................................................................................1
39 1.3 Scope ..........................................................................................................................1
40 1.4 Organization ................................................................................................................1
1 2 References............................................................................................................................2
15
1 List of Tables
2 There are no tables in this volume.
3
1 List of Figures
2 Figure 1: Registration on a GSM Network – GSM Foreign Mode ...................................................12
3 Figure 2: Registration in a different MSC/VLR – GSM Foreign Mode .............................................14
4 Figure 3: Registration on an ANSI-41 network – ANSI-41 Foreign Mode .......................................17
5 Figure 4: Registration in a different MSC/VLR – ANSI-41 Foreign Mode........................................19
6 Figure 5: Registration in an ANSI-41 Network (Native Mode).........................................................21
7 Figure 6: Registration in a GSM Network (Native Mode)................................................................22
8 Figure 7: Failure at the ANSI-41 HLR (GSM Foreign Mode) ..........................................................24
9 Figure 8: IIF Failure (GSM Foreign Mode).....................................................................................25
10 Figure 9: Terminating Call Flow following a GSM VLR Failure .......................................................26
11 Figure 10: Failure at a GSM HLR (ANSI-41 Foreign Mode) ...........................................................27
12 Figure 11: AUTHREQ - Successful Case ......................................................................................29
13 Figure 12: AUTHREQ - Unsuccessful Case ..................................................................................30
14 Figure 13: AFREPORT - Successful Case ....................................................................................31
15 Figure 14: AFREPORT - Unsuccessful Case ................................................................................32
16 Figure 15: ASREPORT - Successful Case ....................................................................................33
17 Figure 16: ASREPORT - Unsuccessful Case ................................................................................34
18 Figure 17: BSCHALL - Successful Case .......................................................................................35
19 Figure 18: BSCHALL - Unsuccessful Case ...................................................................................36
20 Figure 19: AUTHDIR - Successful Case........................................................................................37
21 Figure 20: AUTHDIR - Unsuccessful Case....................................................................................38
22 Figure 21: COUNTREQ - Successful Case ...................................................................................39
23 Figure 22: COUNTREQ - Unsuccessful Case ...............................................................................40
24 Figure 23: SEND_AUTH_INFO.....................................................................................................41
25 Figure 24: SEND_PARAMETER with Request for Authentication Set............................................42
26 Figure 25: Subscriber Deletion – ANSI-41 Foreign Mode ..............................................................43
27 Figure 26: Insert Subscriber Data Procedure.................................................................................44
28 Figure 27: Delete Subscriber Data Procedure ...............................................................................45
29 Figure 28: Cancel Location Procedure ..........................................................................................46
30 Figure 29: Subscriber Deletion- GSM Foreign Mode .....................................................................47
31 Figure 30: Subscriber Data Modification........................................................................................48
32 Figure 31: Call Delivery to ANSI-41 Subscriber Roaming in a GSM Network .................................49
1 Figure 32: Unsuccessful Call Delivery to an ANSI-41 Subscriber Roaming in a GSM Network.......50
2 Figure 33: Call Delivery to GSM Subscriber Roaming in an ANSI-41 Network ...............................51
3 Figure 34: Unsuccessful Call Delivery to GSM Subscriber Roaming in an ANSI-41 Network..........52
4 Figure 35: CFU registration...........................................................................................................53
5 Figure 36: CFU deregistration (erasure)........................................................................................55
6 Figure 37: CFU activation .............................................................................................................57
7 Figure 38: CFU deactivation .........................................................................................................59
8 Figure 39: CFU invocation ............................................................................................................60
9 Figure 40: CFB invocation (Scenario 1a, “CFB#=MSRN method”).................................................62
10 Figure 41: CFB invocation (Scenario 1b, “AbsentSubscriber method”)...........................................63
11 Figure 42: CFB invocation (Scenario 2, without OR)......................................................................64
12 Figure 43: CFNRy invocation (Scenario 1, without OR) .................................................................67
13 Figure 44: CFNRc invocation (Scenario 1) ....................................................................................70
14 Figure 45: CFNRc invocation (Scenario 2, without OR) .................................................................71
15 Figure 46: CFU registration...........................................................................................................73
16 Figure 47: CFU deregistration (erasure)........................................................................................74
17 Figure 48: CFU activation .............................................................................................................75
18 Figure 49: CFU deactivation .........................................................................................................76
19 Figure 50: CFU invocation ............................................................................................................77
20 Figure 51: Obtaining forward-to numbers ......................................................................................78
21 Figure 52: CFB registration ...........................................................................................................79
22 Figure 53: CFB deregistration (erasure) ........................................................................................81
23 Figure 54: CFB activation..............................................................................................................82
24 Figure 55: CFB deactivation..........................................................................................................83
25 Figure 57: CFNA invocation (Scenario 1, without OR) ...................................................................87
26 Figure 58: Optimal Routing with Late Call Forwarding (ANSI-41 Foreign Mode) Success Case .....88
27 Figure 59: Optimal Routing with Late Call Forwarding (ANSI-41 Foreign Mode) Failure Case........91
28 Figure 60: Optimal Routing with Late Call Forwarding (GSM Foreign Mode) Success Case ..........92
29 Figure 61: Optimal Routing with Late Call Forwarding (GSM Foreign Mode) Failure Case.............94
30 Figure 62: ANSI-41 Foreign Mode Call Waiting Activation .............................................................95
31 Figure 63: ANSI-41 Foreign Mode Unsuccessful Call Waiting Activation .......................................97
32 Figure 64: GSM Foreign Mode Call Waiting Activation ..................................................................98
33 Figure 65: ANSI-41 Foreign Mode Call Waiting Deactivation .......................................................100
1 Figure 126: Alerting for an ANSI-41 Subscriber in GSM Foreign Mode ........................................214
2 Figure 127: Successful Mobile Originated Delivery.....................................................................215
3 Figure 128: Unsuccessful Mobile Originated Delivery (Failure at MC)..........................................216
4 Figure 129: Unsuccessful Mobile Originated (Failure at IIF).........................................................217
5 Figure 130: Indicator in ANSI-41 Registration Notification Return Result mapped to GSM
6 SMS ....................................................................................................................219
7 Figure 131: ANSI-41 Qualification Directive mapped to GSM SMS..............................................221
8 Figure 132: Handling at SMS delivery failure at the SGSN or at the MS ......................................222
9 Figure 133: Call Delivery to ANSI-41 Subscriber Roaming in GSM/GPRS Network .....................224
10 Figure 134: MS Notification of a “Missed” Call via SMS ...............................................................226
11 Figure 1: Registration on a GSM Network – GSM Foreign Mode .....................................................9
12 Figure 2: Registration in a different MSC/VLR – GSM Foreign Mode .............................................11
13 Figure 3: Registration on an ANSI-41 network – ANSI-41 Foreign Mode .......................................14
14 Figure 4: Registration in a different MSC/VLR – ANSI-41 Foreign Mode........................................16
15 Figure 5: Registration in an ANSI-41 Network (Native Mode).........................................................18
16 Figure 6: Registration in a GSM Network (Native Mode)................................................................19
17 Figure 7: Failure at the ANSI-41 HLR (GSM Foreign Mode) ..........................................................21
18 Figure 8: IIF Failure (GSM Foreign Mode).....................................................................................22
19 Figure 9: Terminating Call Flow following a GSM VLR Failure .......................................................23
20 Figure 10: Failure at a GSM HLR (ANSI-41 Foreign Mode) ...........................................................24
21 Figure 11: AUTHREQ - Successful Case ......................................................................................26
22 Figure 12: AUTHREQ - Unsuccessful Case ..................................................................................27
23 Figure 13: AFREPORT - Successful Case ....................................................................................28
24 Figure 14: AFREPORT - Unsuccessful Case ................................................................................29
25 Figure 15: ASREPORT - Successful Case ....................................................................................30
26 Figure 16: ASREPORT - Unsuccessful Case ................................................................................31
27 Figure 17: BSCHALL - Successful Case .......................................................................................32
28 Figure 18: BSCHALL - Unsuccessful Case ...................................................................................33
29 Figure 19: AUTHDIR - Successful Case........................................................................................34
30 Figure 20: AUTHDIR - Unsuccessful Case....................................................................................35
31 Figure 21: COUNTREQ - Successful Case ...................................................................................36
32 Figure 22: COUNTREQ - Unsuccessful Case ...............................................................................37
33 Figure 23: SEND_AUTH_INFO.....................................................................................................38
1 Figure 120: MS in GSM Foreign Mode Performing GPRS Detach Followed by Purge..................194
2 Figure 121: IIF - Initiated Detach.................................................................................................196
3 Figure 122: Successful Mobile Terminating ANSI-136 SMS (CMT) mapped to GSM SMS..........197
4 Figure 123: Successful Mobile Terminating ANSI-136 SMS (GHOST) mapped to GSM SMS ......199
5 Figure 124: Unsuccessful Mobile Terminated Delivery (Failure at SGSN)....................................200
6 Figure 125: Unsuccessful Mobile Terminated Delivery (Failure at IIF)..........................................201
7 Figure 126: Alerting for an ANSI-136 Subscriber in GSM Foreign Mode ......................................202
8 Figure 127: Successful Mobile Originated Delivery.....................................................................203
9 Figure 128: Unsuccessful Mobile Originated Delivery (Failure at MC)..........................................204
10 Figure 129: Unsuccessful Mobile Originated (Failure at IIF).........................................................205
11 Figure 130: Indicator in ANSI-41 Registration Notification Return Result mapped to GSM
12 SMS ....................................................................................................................207
13 Figure 131: ANSI-41 Qualification Directive mapped to GSM SMS..............................................209
14 Figure 132: Handling at SMS delivery failure at the SGSN or at the MS ......................................210
15 Figure 133: Call Delivery to ANSI-136 Subscriber Roaming in GSM/GPRS Network ...................212
16 Figure 134: MS Notification of a “Missed” Call via SMS ...............................................................214
17
18
1 Foreword
2 This foreword is not part of this standard.
3 This standard addresses the interworking and interoperability between TIA/EIA IS41 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
13 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 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, CDMA2000). This
22 may be accomplished in future release of this standard.
23 Existing ANSI-41 and GSM standard specifications cover the use and value of timers controlling the
24 various operations. Therefore, these timers are not part of this standard. However, care should be
25 taken when allocating actual timer values in order to support interoperability between ANSI-41 MAP
26 and GSM MAP.
27 Aspects of TIA/EIA-136 Rev C have been incorporated into this standard.
28 Revision A adds GPRS service capability in GSM Foreign Mode.
29
30 Revision B adds two way roaming between GSM and CDMA systems
31 Information disclosed in this document is subject to the export jurisdiction of the US Department of Commerce
32 as specified in Export Administration Regulations (title 15 CFR parts 730 through 774 inclusive). The
33 information contained herein may not be exported or re-exported to Cuba, Iran, Iraq, Libya, North Korea,
34 Sudan, or Syria. Contact the Telecommunications Industry Association, Arlington, VA or
35 http://ftp.tiaonline.org/tr-45/tr45ahag/public%20documents.
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 the subscriber 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 mobile
9 terminal 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 Optionally, IIF may support one way-roaming only from CDMA to GSM network. In this case since no
15 data is provisioned at IIF level, IIF must generate the GSM triplets using as input the authentication
16 parameters returned by ANSI-41 HLR/AC. and ANSI-41 HLR/AC must be compliant with PN-4925 (to
17 be published as TIA/EIA-868 [28]. All the changes are made on the assumption the new requirements
18 for UIM/handsets are working. (Annex B)
19 1.2 Purpose
20 The purpose for this standard is to define and describe the functions necessary for roaming between
21 ANSI-41 MAP [1] and GSM MAP [6] based networks in the support of roaming subscribers. This
22 includes a capability to allow a subscriber to an ANSI-41 based network (e.g., an ANSI-136 41,
23 TDMA or CDMA native subscriber) with a mobile terminal supporting GPRS service to roam to a
24 GPRS network in GSM Foreign Mode.
25 1.3 Scope
26 The scope of this standard are the services, information flows and message mappings which require
27 interworking and interoperability functional specifications to support roaming between ANSI-41 MAP
28 and GSM MAP networks.
29 The scope of this volume describes the “Information Flows” and addresses the functionality required
30 to support GSM and ANSI-41 network interoperability.
31 1.4 Organization
32 This standard is organized into the following volumes:
33 Volume 0 – Overview and Interworking Reference Model
34 Volume 1 – Service Descriptions
35 Volume 2 – Information Flows
36 Volume 3 – Message Mappings
37 This volume is organized according to the following:
38 2 References - a list of references specific to this volume of the Standard.
1 3 Definitions and Acronyms - defines words and acronyms that are specific to this volume.
2 4 Information flows - Message Flows and functionality of the interoperable network features.
3
1 2 References
2 [1] TIA/EIA IS-41-D: “Cellular Radiotelecommunications Intersystem Operations,” December
3 1997, ANSI.
6 [4] TS 100 901 v 6.1.0 (1998-07); “Digital cellular telecommunications system (Phase 2+);
7 Technical realization of the Short Message Service (SMS); Point-to-Point (PP),” (GSM 03.40
8 version 6.1.0 Release 1997)
9 [5] TS 100 542 v 7.0.1 (1999-07); "Digital cellular telecommunications system (Phase 2+); Line
10 identification supplementary services;Stage2 (GSM 03.81 version 7.0.1 Release 1998).
11 [6] TS 100 974 v 6.2.0 (1998-11): “Digital cellular telecommunication system (Phase 2+); Mobile
12 Application Part (MAP) specification,” (GSM 09.02 version 6.2.0 Release 1997).
13 [7] TS 100 974 v 7.1.0 (1999-08): “Digital cellular telecommunication system (Phase 2+); Mobile
14 Application Part (MAP) specification,” (GSM 09.02 version 7.1.0 Release 1998).
15 [8] TS 101 629 v 6.0.0 (1999-04): "Digital cellular telecommunication system (Phase 2+);
16 Support of Optimal Routeing (SOR); Service definition (Stage 1)". (GSM 02.79 v 6.0.0
17 Release 1997)
18 [9] TS 101 045 v 6.2.0 (1999-11): "Digital cellular telecommunication system (Phase 2+);
19 Support of Optimal Routeing (SOR); Technical realisation" (GSM 03.79 v 6.2.0 Release
20 1997).
21 [10] Draft ETSI EN 301 344: “Digital cellular telecommunication system (Phase 2+); General
22 Packet Radio Service; Service description (Stage 2)" (GSM 03.60 v 6.8.0 Release 1997).
23 [11] TIA/EIA/IS 737A”IS-41 support for data services for digital terminals (TDMA and CDMA)”
1 CDMA as used in this document, refers to TIA/EIA -95 [9] or TIA/EIA-2000 [10], which is a CDMA
2 air interface protocol standard for mobile stations and their associated base stations. CDMA is a
3 dual-mode standard that includes digital (CDMA) operation and analog (AMPS) operation. CDMA
4 networks use ANSI-41 for intersystem signaling.
5 B.1.1.1.1.1 CDMA Mode
6 CDMA mode indicates the condition or state of a mobile station accessing an CDMA network.
7
8 CDMA Foreign Mode
9 CDMA foreign mode indicates the condition or state of a GSM native subscriber accessing a CDMA
10 network.
11
12 CDMA Native Mode
13 CDMA native mode indicates the condition or state of an CDMA native subscriber accessing an
14 CDMA network.
15
16 CDMA Native Subscriber
17 CDMA native subscriber indicates an end user whose primary or home subscription resides in an
18 CDMA network. These subscribers include both home subscribers from the CDMA network, as well
19 as roamers from other CDMA networks.
20
21 Class A mobile
22 Class A mobile station is a GSM mobile that can operate in Class A mode: both GSM circuit-switched
23 and GPRS packet services simultaneously.
24
25 Class B mobile
26 Class B mobile station is a GAIT or GSM mobile that operates in Class B mode: can operate
27 alternatively GSM circuit-switched or GPRS packet services (1 type service at a time). The mobile
28 can be attached to GSM and GPRS networks simultaneously in this case. The subscriber cannot be
29 simultaneously attached to an ANSI-41 MSC.
30
31 Class C mobile
32 Class C mobile station is a GSM mobile that can only operate in Class C mode: GSM circuit-switched
33 only or GPRS packet services only. The mobile is attached to only one network at a time.
34
35 GSM
36 Global System for Mobile Communications (GSM) defines both air interface and network intersystem
37 protocol standards for mobile stations (MS), base station systems (BSS), and network switching
38 systems (NSS).
39 GSM CS attached
40 GSM circuit-switched services attached means that the subscriber is attached to a GSM MSC. This is
41 also referred to as IMSI attached
42 GSM CS detached
43 GSM circuit-switched services detached means that the subscriber is detached from a GSM MSC.
44 This is also referred to as IMSI detached.
45
46 GSM Mode
47 GSM mode indicates the condition or state of a mobile station accessing a GSM network.
12
1 3.2 Acronyms
2 AC Authentication Center in TIA/EIA-41 based networks
3 ADN Abbreviated Dialing Numbers
4 AuC Authentication Center in GSM networks
5 AMPS Advanced Mobile Phone Service
6 ANSI American National Standards Institute
7 BAIC Barring of All Incoming Calls
8 BAOC Barring of All Outgoing Calls
9 BIC-Roam Barring of Incoming Calls while Roaming Outside HPLMN Country
10 BOIC Barring of Outgoing International Calls
11 BOIC-exHC Baring of Outgoing International Calls Except to HPLMN Country
12 CDMA Code-Division Multiple Access
13 CFB Call Forwarding Busy
14 CFNA Call Forwarding No Answer
15 CFNRc Call Forwarding Not Reachable
16 CFNRy Call Forwarding No Reply
17 CFU Call Forwarding Unconditional
18 CPHS Common PCN Handset Specification
19 DCS Data Coding Scheme
20 EIA Electronics Industry Association
21 ESN Electronic Serial Number
22 ETSI European Telecommunications Standards Institute
23 EUI ESN Usage Indicator
24 FC Feature Code
25 FDN Fixed Dialing Numbers
26 FSM Forward Short Message
27 GGSN Gateway GPRS Support Node
28 GHOST GSM Hosted SMS Teleservice
29 GMSC Gateway Mobile Switching Center
30 GPRS General Packet Radio Service
31 GSM Global System for Mobile Communications
32 HLPI Higher Layer Protocol Indicator
24
regcanc
i
regnot j
9
10 Figure 1: Registration on a GSM Network – GSM Foreign Mode
11
1 a. MS powers up and registers in a GSM network. The MS sends an Update Location Request
2 (which includes the IMSI) to the network.
3 b. If the serving VLR does not have authentication information in order to perform authentication
4 i.e. authentication triplets, it requests authentication information from the IIF. The IIF emulates
5 a GSM HLR/AuC in this case.
6 c. The IIF returns the necessary authentication information.
7 d. VLR initiates authentication towards the MS.
8 e. MS responds to the authentication request.
9 f. VLR initiates Location Updating towards the IIF. The Update Location Request contains the
10 IMSI.
11 g. The IIF translates the GSM MAP Update Location Request into an ANSI-41 MAP REGNOT
12 and sends the REGNOT to the subscribers home HLR. The IIF is emulating an ANSI-41 VLR
13 when it sends the REGNOT. If necessary, the subscriber IMSI in the Update Location
14 Request is mapped to the associated MIN.
15 If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall
16 be passed in the REGNOT to the subscriber’s HLR. This ESN may not match the currently
17 validated dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for
18 this subscriber.
19 h. The HLR updates its location information and deletes the previous VLR record by sending a
20 REGCANC to the previous VLR.
21 i. The VLR acknowledges the REGCANC
22 j. The HLR returns an acknowledgement to the REGNOT (regnot)
23 k. When the IIF receives the regnot, it initiates the GSM MAP Insert Subscriber Data Procedure
24 towards the serving VLR. This procedure is used to download subscriber data to the serving
25 VLR. Multiple Insert Subscriber Data transactions may be necessary to complete the transfer
26 of subscriber data to the VLR.
27 l. The VLR acknowledges the Insert Subscriber Data operation(s).
28 m. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the
29 IIF returns an acknowledgement for the Update Location Request.
30
2 When an ANSI-136 41 subscriber roams within a GSM PLMN and registers in a different MSC/VLR
3 area, the MS performs a location update using the IMSI as shown in Figure 2.
REGNOT
i
regnot
j
4
5 Figure 2: Registration in a different MSC/VLR – GSM Foreign Mode
6 a. MS powers up and registers in a different MSC/VLR in the same GSM network. The MS sends
7 an Update Location Request (which includes the IMSI) to the network.
8
9 b. If the serving VLR does not have authentication information in order to perform authentication
10 i.e. authentication triplets, it requests authentication information from the IIF. The IIF emulates
11 a GSM HLR/AuC in this case.
12
13 c. The IIF returns the necessary authentication information.
14
15 d. VLR initiates authentication towards the MS.
16
17 e. MS responds to the authentication request.
18
1
2 f. VLR initiates Location Updating towards the IIF. The Update Location Request contains the
3 IMSI.
4
5 g. The IIF sends a Cancel Location request to the previous VLR (PVLR) that the subscriber was
6 registered on.
7
8 h. The PVLR deletes the subscriber record and acknowledges the request.
9
10 i. Optionally, the IIF may send a Registration Notification to the HLR to indicate the changed
11 location.
12
13 If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall
14 be passed in the REGNOT to the subscriber’s HLR. This ESN may not match the currently
15 validated dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for this
16 subscriber.
17
18 j. The HLR acknowledges the REGNOT.
19
20 k. The IIF initiates the GSM MAP Insert Subscriber Data Procedure towards the serving VLR. This
21 procedure is used to download subscriber data to the new serving VLR. Multiple Insert
22 Subscriber Data transactions may be necessary to complete the transfer of subscriber data to
23 the VLR.
24
25 l. The VLR acknowledges the Insert Subscriber Data operation(s).
26
27 m. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF
28 returns an acknowledgement for the Update Location Request.
29
30 n. The new MSC/VLR acknowledges the location update request from the MS.
31 Note: If the MS performs a location update in the same MSC/VLR area, either the IMSI or
32 TIMSI may be used as described in GSM 09.02 [6]. The IIF however, is not informed.
34 If a MS powers off while operating in GSM Foreign mode, and the IMSI Detach procedure is
35 supported, it shall perform an IMSI Detach as described in GSM 09.02 [6]. Neither the IIF or the home
36 HLR is informed.
37 Terminating calls intended for this ANSI-136 41 subscriber, shall therefore be treated in the home
38 HLR as if that subscriber was available.
39 If the MS remains inactive for an extended period of time (determined by operator), the VLR may
40 delete the subscriber record associated with that MS and shall send an MS PURGE to the IIF. In this
41 case, the IIF shall send an MS INACTIVE towards the ANSI-41 HLR and the ANSI-41 HLR shall
42 follow the procedures outlined in ANSI-41 [1]. (Terminating calls intended for this ANSI-136 41
43 subscriber, shall therefore be treated in the home HLR as if that subscriber was not available).
44
2 If an MS powers on and registers on the same MSC/VLR (that has not deleted the subscriber record)
3 while operating in GSM Foreign mode and the IMSI Attach procedure is supported, it shall perform an
4 IMSI Attach as described in GSM 09.02 [6]. Neither the IIF or the home HLR is informed.
5 If an MS powers on and registers on the same MSC/VLR (that has deleted the subscriber record),
6 while operating in GSM Foreign mode and the IMSI Attach procedure is supported, it shall perform an
7 IMSI Attach as described in GSM 09.02 [6]. The IIF shall be informed as shown in Section 4.1.1.2.
8 (however the IIF shall not send a Cancel Location to the MSC/VLR as it is the same MSC/VLR).
9 If an MS powers on and registers on a different MSC/VLR, while operating in GSM Foreign mode and
10 the IMSI Attach procedure is supported, it shall perform an IMSI Attach as described in GSM 09.02
11 [6]. The IIF shall be informed as shown in Section 4.1.1.2.
12
4 When a GSM subscriber registers in an ANSI-41 network, when previously registered in a GSM
5 network, the MS performs a location update using an IMSI or MIN as shown in Figure 3. The IIF
6 emulates both an ANSI-41 HLR and a GSM VLR in this case.
Auth req
c
REGNOT
d
regnot
i
Reg_ack
j
7
8 Figure 3: Registration on an ANSI-41 network – ANSI-41 Foreign Mode
9
10 a. Upon MS power up, if global authentication is active, the MS first sends an Authentication
11 message to the network. The MS then sends a Registration message (which includes the IMSI
12 or MIN) to the network.
13
14 b. If global authentication is active upon registration, the serving VLR initiates an AUTHREQ
15 towards the IIF. The IIF emulates an ANSI-41 HLR/AC in this case.
16
17 The reported ESN for this subscriber shall be dynamic to support SIM-based roaming. The IIF
18 shall authenticate the subscriber using this reported ESN.
19
1 c. The IIF acknowledges the authentication request. If authentication is successful, the IIF shall
2 store the reported ESN as the currently validated dynamic ESN for this subscriber. The
3 currently validated dynamic ESN shall be maintained by the ANSI-41 HLR emulation function in
4 the IIF.
5
6 d. VLR sends a REGNOT message to the IIF.
7
8 e. The IIF translates the ANSI-41 MAP REGNOT into a GSM MAP Update Location Request
9 (which includes the IMSI) and sends the Update Location Request to the subscribers home
10 HLR. The IIF is emulating a GSM VLR when it sends the Update Location Request.
11
12 f. The HLR updates its location information and deletes the previous VLR record by sending a
13 Cancel Location to the previous VLR.
14
15 g. The VLR acknowledges the Cancel Location. Note: The GSM Insert Subscriber data procedure
16 between the HLR and the IIF takes place between steps g and h.
17
18 h. The HLR acknowledges the Update Location Request
19
20 i. The IIF acknowledges the REGNOT. The acknowledgement also contains the subscriber data
21 download to the new serving VLR.
22
23 j. The MSC/VLR acknowledges the Registration message from the MS.
24
2 When a GSM subscriber roams within an ANSI-41 network and registers in a different MSC/VLR
3 area, the MS performs a location update using an IMSI or MIN as shown in Figure 4.
Auth req
c
REGNOT
d
REGCANC
e
(MIN)
regcanc
f
Location Update Req
g
regnot i
Reg_ack j
4
5 Figure 4: Registration in a different MSC/VLR – ANSI-41 Foreign Mode
6
7 a. MS powers up and registers in a new MSC/VLR in the same ANSI-41 network. If global
8 authentication is active, the MS sends an Authentication message to the network. The MS also
9 sends a Registration message (which includes the IMSI / MIN) to the network.
10
11 b. If global authentication is active upon registration, the serving VLR initiates an AUTHREQ
12 towards the IIF. The IIF emulates an ANSI-41 HLR/AC in this case.
13
14 The reported ESN for this subscriber shall be dynamic to support SIM-based roaming. The IIF
15 shall authenticate the subscriber using this reported ESN.
16
17 c. The IIF acknowledges the authentication request. If authentication is successful, the IIF shall
18 store the reported ESN as the currently validated dynamic ESN for this subscriber.
19
1 The currently validated dynamic ESN shall be maintained by the ANSI-41 HLR emulation
2 function in the IIF.
3
4 d. VLR sends a REGNOT message to the IIF.
5
6 e. The IIF deletes the subscriber record in the previous VLR (PVLR), by sending a REGCANC to
7 the PVLR.
8
9 f. The PVLR acknowledges the REGCANC.
10
11 g. Optionally, the IIF may send an Update Location Request to the HLR to indicate the changed
12 location.
13
14 h. The HLR acknowledges the update location.
15
16 i. The IIF acknowledges the REGNOT.
17
18 j. The new serving MSC/VLR acknowledges the Registration message from the MS.
19
20 B.1.1.8 4.1.2.3 MS Powers Off
21 If a mobile station powers off while operating in ANSI-41 Foreign mode, the IIF receives an MS
22 INACTIVE message from the serving VLR. This results in the IIF setting the ‘IMSI Detached’ Flag. If
23 the MS remains inactive for an extended period of time (determined by operator), the IIF may delete
24 the subscriber record associated with that MS and send an MS Purge to the HLR.
26 If a mobile station powers on and registers on an MSC/VLR, while operating in ANSI-41 Foreign
27 mode, normal registration procedures apply.
31 When an ANSI subscriber registers in an ANSI-41 network (Native Mode), when previously registered
32 in a GSM Network (Foreign Mode), the MS performs a location update and the temporary subscriber
33 data in the IIF is deleted as shown in figure 5.
AUTH REQ b
Auth req c
REGNOT d
(MSID)
REGCANC e
(MSID)
Cancel Location f
(IMSI)
Cancel Location Ack
g
regcanc h
regnot
i
Reg_ack j
3 When a GSM subscriber registers in a GSM network (Native Mode), when previously registered in an
4 ANSI-41 Network (Foreign Mode), the MS performs a location update and the temporary subscriber
5 data in the IIF is deleted as shown in figure 6.
MSC/ PVLR
MS HLR IIF
VLR
REGCANC
d
(MSID)
regcanc e
11 When the ANSI-41 HLR returns to a stable state after suffering a failure, it shall send the IIF
12 (emulating an ANSI-41 VLR) an UnreliableRoamerDataDirective message (UNRELDIR) as described
13 in ANSI 41.3 D [1], informing the IIF that it has experienced a failure which has rendered the HLR’s
14 roaming MS data unreliable. Figure 7 below shows the call flow.
15 When the roaming MS next makes radio contact, the serving GSM VLR shall initiate the location
16 updating procedure towards the IIF.
17
VLR HLR
IIF
UNRELDIR
a
unreldir
b
RESET
c
2 If the IIF suffers a failure, it shall follow the recovery procedure described in GSM 09.02 [6] section
3 19.3.2 (i.e. IIF is acting like a GSM HLR). As part of the recovery procedure, the IIF shall send all the
4 serving GSM VLRs a RESET message for each associated ANSI-41 HLR as shown in step a) in
5 Figure 8. The message shall contain a unique identifier for the ANSI-41 HLR. In addition, the IIF shall
6 send a BULKDEREG to all affected ANSI-41 HLRs (i.e. IIF is acting like an ANSI-41 VLR).
VLR HLR
IIF
RESET
a
BULKDEREG
b
bulkdereg
c
2 If the VLR suffers a failure, it shall follow the recovery procedure described in GSM 09.02 [6] section
3 19.3.1. As part of the recovery procedure, when a MS next establishes authenticated radio contact,
4 the VLR shall initiate location updating towards the IIF (See 4.1.1).
5 If the VLR receives a request for a roaming number from the IIF following a failure, the VLR shall
6 send a RESTORE DATA message to the IIF as shown in Figure 9.
VLR HLR
IIF
ROUTREQ
a
PROVIDE ROAMING NO
b
routreq
d
RESTORE DATA e
INSERT SUB DATA
f
ANSI-41 NETWORK
GSM NETWORK
19
3 When a GSM HLR undergoes a restart, it shall follow the procedures described in GSM 09.02 [6]
4 section 19.3.2. As part of the recovery procedure, the HLR sends the IIF a RESET message,
5 informing the IIF that it has experienced a failure, which has rendered the HLR’s roaming MS data
6 unreliable. When the roaming MS next makes radio contact, the serving ANSI-41 VLR shall initiate
7 the location updating procedure towards the IIF. Figure 10 below shows the call flow.
RESET
a
UNRELDIR
b
unreldir
c
ANSI-41 NETWORK
GSM NETWORK
8
9 Figure 10: Failure at a GSM HLR (ANSI-41 Foreign Mode)
10
11 a. The HLR follows the recovery procedures described in GSM 09.02 [6] section 19.3.2. The
12 affected sends a RESET towards the IIF.
13
14 b. The IIF follows the procedures described in GSM 09.02 [6] section 19.3.2 on reception of the
15 RESET and sends an UNRELDIR towards each of the serving ANSI-41 VLRs. The UNRELDIR
16 message contains a unique identity, identifying the affected GSM HLR.
17
18 c. The VLR follows the procedures described in ANSI-41.3 [1] and ANSI-41.6 [1] and acknowledges
19 the UNRELDIR.
20
21 When the MS next establishes authenticated radio contact (including a mobile originated call
22 attempt), the VLR initiates location updating towards the IIF (See 4.1.2.1).
23
24
2 If the IIF suffers a failure, it shall follow the recovery procedure described in ANSI-41.6 [1] (i.e. IIF is
3 acting like an ANSI HLR). As part of the recovery procedure, the IIF shall send all the serving
4 ANSI-41 VLRs an UNRELDIR message for each associated GSM HLR as shown in steps b and c in
5 Figure 10. The message shall contain a unique identifier for the GSM HLR.
6 When the MS next establishes authenticated radio contact (including a mobile originated call
7 attempt), the VLR initiates location updating towards the IIF (See 4.1.2.2).
8 If following an IIF failure, the IIF receives a request for routing information, it shall send a RESTORE
9 DATA towards the requesting GSM HLR.
11 If the ANSI-41 VLR suffers a failure, it shall follow the recovery procedure described in ANSI-41.6 [1].
12 As part of the recovery procedure, when an MS next establishes authenticated radio contact, the VLR
13 shall initiate location updating towards the IIF.
14 Upon receipt of a BULKDEREG, the IIF shall clear the location pointer for those MSs that were
15 registered on that VLR. If following the reception of a BULKDEREG, the IIF receives a request for
16 routing information, the terminating call towards the MS shall not be possible until the MS has
17 performed a successful location registration.
18
1 4.3 Authentication
2 4.3.1 ANSI-41 Foreign Mode Authentication Activation
3 B.1.1.18 4.3.1.1 Receiving AUTHREQ Message
ANSI-41
Serving
System
ANSI-41
MSC/VLR IIF
AC
AUTHREQ
a
AUTHREQ
b
authreq
c
authreq
d
6
7 Figure 11: AUTHREQ - Successful Case
8 a,b,c,d The IIF is emulating an ANSI-41 HLR. For successful processing, see to ANSI-41 [1].
ANSI-41
Serving
System
ANSI-41
MSC/VLR IIF
AC
AUTHREQ
a
AUTHREQ
b
authreq
c
(error handling)
authreq
d
(error handling)
3
4 Figure 12: AUTHREQ - Unsuccessful Case
5
6 a,b,c,d The IIF is emulating an ANSI-41 HLR. For error handling see to ANSI-41 [1].
ANSI-41
Serving
System
ANSI-41
MSC/VLR IIF
AC
AFREPORT
a
AFREPORT
b
afreport
c
afreport
d
4
5 Figure 13: AFREPORT - Successful Case
6
7 a,b,c,d The IIF is emulating an ANSI-41 HLR. For successful processing, see to ANSI-41 [1].
8
9
ANSI-41
Serving
System
ANSI-41
MSC/VLR IIF
AC
AFREPORT
a
AFREPORT
b
afreport
c
(error handling)
afreport
d
(error handling)
3
4 Figure 14: AFREPORT - Unsuccessful Case
5
6 a,b,c,d The IIF is emulating an ANSI-41 HLR. For error handling see to ANSI-41.D [1].
ANSI-41
Serving
System
ANSI-41
MSC/VLR IIF
AC
ASREPORT
a
ASREPORT
b
asreport
c
asreport
d
4
5 Figure 15: ASREPORT - Successful Case
6
7 a,b,c,d The IIF is emulating an ANSI-41 HLR. For successful processing, see to ANSI-41 [1].
ANSI-41
Serving
System
ANSI-41
MSC/VLR IIF
AC
ASREPORT
a
ASREPORT
b
asreport
c
(error handling)
asreport
d
(error handling)
3
4 Figure 16: ASREPORT - Unsuccessful Case
5
6 a,b,c,d The IIF is emulating an ANSI-41 HLR. For error handling see to ANSI-41 [1].
ANSI-41
Serving
System
ANSI-41
MSC/VLR IIF
AC
BSCHALL
a
BSCHALL
b
bschall
c
bschall
d
4
5 Figure 17: BSCHALL - Successful Case
6
7 a,b,c,d The IIF is emulating an ANSI-41 HLR. For successful processing, see to ANSI-41 [1].
ANSI-41
Serving
System
ANSI-41
MSC/VLR IIF
AC
BSCHALL
a
BSCHALL
b
bschall
c
(error handling)
bschall
d
(error handling)
3
4 Figure 18: BSCHALL - Unsuccessful Case
5
6 a,b,c,d The IIF is emulating an ANSI-41 HLR. For error handling see to ANSI-41 [1].
ANSI-41
Serving
System
ANSI-41
MSC/VLR IIF
AC
AUTHDIR
a
AUTHDIR
b
authdir
c
authdir
d
4
5 Figure 19: AUTHDIR - Successful Case
6
7 a,b,c,d The IIF is emulating an ANSI-41 HLR. For successful processing, see to ANSI-41 [1].
ANSI-41
Serving
System
ANSI-41
MSC/VLR IIF
AC
AUTHDIR
a
AUTHDIR
b
authdir
c
(error handling)
authdir
d
(error handling)
3
4 Figure 20: AUTHDIR - Unsuccessful Case
5
6 a,b,c,d The IIF is emulating an ANSI-41 HLR. For error handling see to ANSI-41 [1].
ANSI-41
Serving
System
ANSI-41
MSC/VLR IIF
AC
COUNTREQ
a
COUNTREQ
b
countreq
c
countreq
d
4
5 Figure 21: COUNTREQ - Successful Case
6
7 a,b,c,d The IIF is emulating an ANSI-41 HLR. For successful processing, see to ANSI-41 [1].
2
ANSI-41
Serving
System
ANSI-41
MSC/VLR IIF
AC
COUNTREQ
a
COUNTREQ
b
countreq
c
(error handling)
countreq
d
(error handling)
3
4 Figure 22: COUNTREQ - Unsuccessful Case
5
6 a,b,c,d The IIF is emulating an ANSI-41 HLR. For error handling see to ANSI-41 [1].
GSM
IIF MSC/VLR
AuC
SEND_AUTH_INFO
a
SEND_AUTH_INFO
b
send_auth_info
c
send_auth_info
d
5
6 Figure 23: SEND_AUTH_INFO
7
8 a,b,c,d The IIF is emulating a GSM HLR. For successful processing, see to GSM 09.02 [6].
GSM
Serving
System
GSM
IIF MSC/VLR
AuC
SEND_PARAMETER
a
SEND_PARAMETER
b
send_parameter
c
send_parameter
d
3
4 Figure 24: SEND_PARAMETER with Request for Authentication Set
5
6 a,b,c,d The IIF is emulating a GSM HLR. For successful processing, see to GSM 09.02 [6].
9 In this procedure, temporary subscriber data shall be removed from the HLR, IIF and the serving
10 MSC/VLR as shown in Figure 25.
Cancel Location b
REGISTRATION_
CANCELLATION c
Registration_
cancellation
d
Subscriber Deleted
f
GSM NETWORK
ANSI-41 NETWORK
13 b. The HLR deletes the subscriber data from the HLR and sends a Cancel Location request to
14 the IIF.
15 c. The IIF deletes the temporary subscriber data from the IIF and sends a Registration
16 Cancellation to the serving MSC/VLR. The CancellationType in this operation shall be set to
17 “Discontinue” to tear down any active call.
18 d. The VLR deletes the subscriber data from the VLR and returns an acknowledgement to the
19 IIF.
5 The OMC can modify subscriber data in several different ways e.g. withdrawal of a basic or
6 supplementary service, roaming modifications, data modifications to both HLR and VLR. Depending
7 on the data modification required, one of three MAP procedures is initiated from the HLR towards the
8 IIF. These procedures are described in more detail in GSM 09.02 [6].
10 Where data is required to be modified in the HLR, IIF and the serving VLR, the HLR initiates the
11 Insert Subscriber Data Procedure towards the IIF as shown in Figure 26.
QUALDIR c
qualdir
d
14 b. The HLR modifies the subscriber data in the HLR and initiates the Insert Subscriber Data
15 Operation towards the IIF.
16 c. The IIF modifies the subscriber data in the IIF and sends a QUALDIR to the serving MSC/VLR.
17 There may be some cases where the subscriber data change cannot be mapped to an
18 associated ANSI-136 41 subscriber profile modification. In this case, no QualDir operation shall
19 be initiated.
20 d. The serving MSC/VLR modifies the subscriber data and acknowledges the QUALDIR
5 If a basic or supplementary service is withdrawn, which requires a change to VLR data, the HLR
6 initiates the Delete Subscriber Data Procedure towards the IIF as shown in Figure 27.
QUALDIR
c
qualdir
d
7
8 Figure 27: Delete Subscriber Data Procedure
2 If roaming modifications are required, which require the subscriber to be removed from the VLR data,
3 the HLR initiates the Cancel Location Procedure towards the IIF as shown in Figure 28.
Cancel Location
b
REGISTRATION_
CANCELLATION c
Registration_
cancellation
d
6 b. The HLR deletes the relevant subscriber data in the HLR and initiates the Cancel Location
7 Operation towards the IIF.
8 c. The IIF deletes the temporary subscriber data in the IIF and sends a REGCANC to the
9 serving MSC/VLR.
10 d. The serving MSC/VLR deletes the relevant subscriber data and acknowledges the
11 REGCANC.
7 The OMC may request that subscriber data relating to a particular subscriber is removed from the
8 HLR. In this case, subscriber data shall also be removed from the IIF and the serving MSC/VLR as
9 shown in Figure 29.
REGCANC
b
Cancel Location
regc anc
e
NSI-41 NETWO RK
GSM NETWORK
2 The OMC may request that subscriber data relating to a particular subscriber is modified (e.g., the
3 authorization or de-authorization of a particular feature). In this case, subscriber data may also be
4 required to be modified in the IIF and the serving MSC/VLR as shown in Figure 30.
QUALDIR
b
qualdir
e
NSI-41 NETWO RK
GSM NETWORK
Serving System
MSC/ GSM
VLR IIF MSC/
HLR
Incoming Call VLR
From PSTN
a
LOCREQ
b
ROUTREQ c
routreq f
locreq
g
Call setup
h
13
14 Figure 31: Call Delivery to ANSI-41 Subscriber Roaming in a GSM Network
15 a. A call origination and the dialed MS address digits (i.e., directory number) are received by the
16 Originating MSC from the PSTN destined to a subscriber to the ANSI-41 network.
17 b. The Originating MSC sends a LOCREQ to the HLR associated with the called subscriber; this
18 association is made through the dialed MS address digits.
19 c. The HLR sends a ROUTREQ to the IIF emulating the VLR where the MS is registered.
20 d. The IIF forwards a Provide Roaming Number message to the VLR/GSM MSC where the MS is
21 registered. If necessary, mapping from MIN to IMSI is done by the IIF.
22 e. The VLR/GSM MSC returns a Provide Roaming Number Ack message to the IIF that includes an
23 MSRN.
1 f. The IIF returns a routreq message to the HLR that includes a TLDN (Temporary Local Directory
2 Number), set to the received MSRN, in the Digits (Destination) parameter. Note that the MSRN is
3 always in international format. It is assumed that the gateway MSC on the ANSI-41 side is
4 capable of supporting internationally formatted TLDNs.
5 g. When the routreq is received by the HLR, it returns a locreq to the Originating MSC. The locreq
6 includes routing information in the form of the TerminationList parameter, along with an indication
7 of the reason for extending the incoming call (i.e., for Call Delivery, in this case) in the
8 DMH_RedirectionIndicator parameter.
9 h. Upon receiving the locreq, the Originating MSC sets up a voice path to the Serving GSM MSC
10 (using a protocol such as SS7 ISUP).
13 In the following scenario, call delivery to an ANSI-136 41 subscriber roaming in a GSM network fails
14 during the processing of the Provide Roaming Number message (e.g., no roaming number is
15 available, absent subscriber).
Serving System
MSC/ GSM
VLR IIF MSC/
HLR
Incoming Call VLR
From PSTN
a
LOCREQ
b
ROUTREQ c
16
17 Figure 32: Unsuccessful Call Delivery to an ANSI-136 41 Subscriber Roaming in a GSM
18 Network
19 a. A call origination and the dialed MS address digits (i.e., directory number) are received by the
20 Originating ANSI-41 MSC from the PSTN destined to a subscriber to the ANSI-41 network.
21 b. The Originating ANSI-41 MSC sends a LOCREQ message to the ANSI-41 HLR associated with
22 the called subscriber; this association is made through the dialed MS address digits.
23 c. The ANSI-41 HLR sends a ROUTREQ message to the IIF emulating the VLR where the MS is
24 registered. If necessary, mapping from IMSI to MIN is done beforehand by the IIF.
25 d. The IIF forwards a Provide Roaming Number message to the GSM VLR/MSC where the MS is
26 registered.
27 e. The GSM VLR/MSC determines that either no roaming numbers are available or subscriber is not
28 reachable and it replies with a PRN Return Error message.
Serving System
GSM GSM
MSC/ IIF MSC/
HLR VLR
Incoming Call VLR
From PSTN
a
Send Routing Info
b
ROUTREQ
d
routreq
e
PRN Ack f
SRI Ack
g
Call setup
h
5
6 Figure 33: Call Delivery to GSM Subscriber Roaming in an ANSI-41 Network
7 a. A call origination and the dialed MS address digits (i.e., directory number) are received by the
8 Originating MSC from the PSTN destined to a subscriber to the GSM network.
9 b. The Gateway GSM MSC sends a Send Routing Information message to the GSM HLR
10 associated with the called subscriber; this association is made through the dialed MS address
11 digits.
12 c. The GSM HLR sends a Provide Roaming Number message to the IIF emulating the VLR where
13 the MS is registered. If necessary, mapping from IMSI to MIN is done beforehand by the IIF.
14 d. The IIF forwards a ROUTREQ message to the VLR/MSC where the MS is registered.
15 e. The serving VLR/ MSC returns a routreq message that includes a TLDN to the IIF.
16 f. The IIF returns a Provide Roaming Number Ack message that includes an MSRN (set to the
17 received TLDN) to the GSM HLR. If the TLDN is not received in international format, the IIF shall
18 first convert the TLDN to international format (by prepending the country code associated with the
19 serving system) before setting the MSRN equal to it.
20 g. When the Provide Roaming Number Ack is received by the GSM HLR, it returns a Send Routing
21 Information Ack message to the Gateway GSM MSC.
22 h. Upon receiving the Send Routing Information Ack message, the Gateway GSM MSC sets up a
23 voice path to the Serving MSC (using a protocol such as SS7 ISUP).
3 In the following scenario, call delivery to a GSM subscriber roaming in an ANSI-41 network fails
4 because the user is either ‘not reachable’ as determined by the IIF or does not answer a page sent by
5 the serving system during the processing of the RouteRequest message, and call forwarding is not
6 active for the subscriber.
Serving System
GSM GSM
MSC/ IIF MSC/
HLR VLR
Incoming Call VLR
From PSTN
a
Send Routing Info
b
ROUTREQ
d
routreq[ACCDEN]
e
7
8 Figure 34: Unsuccessful Call Delivery to GSM Subscriber Roaming in an ANSI-41 Network
9 a. A call origination and the dialed MS address digits (i.e., directory number) are received by the
10 Originating MSC from the PSTN destined to a subscriber to the GSM network.
11 b. The Gateway GSM MSC sends a Send Routing Information message to the GSM HLR
12 associated with the called subscriber; this association is made through the dialed MS address
13 digits.
14 c. The GSM HLR sends a Provide Roaming Number message to the IIF emulating the VLR where
15 the MS is registered. If necessary, mapping from IMSI to MIN is done beforehand by the IIF. If
16 the IIF determines that the called subscriber is not reachable, it returns an absent subscriber error
17 as in step f.
18 d. If the IIF determines that the subscriber is reachable, it forwards a ROUTREQ message to the
19 VLR/MSC where the MS is registered.
20 e. The VLR/MSC pages the subscriber does not get a response and returns a routreq message with
21 an AccessDeniedReason parameter set to NoPageResponse.
22 f. The IIF returns a Provide Roaming Number Return Error message with the error code set to
23 Subscriber Absent to the subscriber’s GSM HLR.
24 g. The GSM HLR sends a Send Routing Information Return Error message to the Gateway GSM
25 MSC with the Subscriber Absent error code, and the appropriate treatment (e.g. announcement)
26 is provided to the incoming call by the Gateway GSM MSC.
27
6 The following scenarios illustrate the call forwarding unconditional (CFU) information flows applicable
7 to ANSI-41 foreign mode operation.
9 This scenario illustrates the CFU registration information flows applicable to ANSI-41 foreign mode
10 operation.
GSM ANSI-136
Home System Serving System Subscriber
IIF
HLR VMSC MS
2
GSM ANSI-41
FEATREQ [digits]
b
REG_SS
c
reg_ss
d
featreq [success]
e
feature confirmation
f
ISD
g
isd
h
[TCAP End]
i
QUALDIR
j
qualdir
k
11
12 Figure 35: CFU registration
13
1 a. The ANSI-41 serving system receives dialed digits from the subscriber’s mobile station (MS). The
2 serving system detects a “*” character as the first dialed digit. This indicates that the dialed digits
3 are a feature code string.1
4
5 b. The serving system sends a FEATREQ message to the IIF, including the digits received from the
6 subscriber.
7
8 c. The IIF parses the received digit string. In this case, the subscriber has requested to register a
9 call forwarding number. The IIF sends a REG_SS message to the GSM HLR.2
10
11 d. The HLR processes the request and returns a reg_ss message to the IIF, indicating operation
12 success.
13
14 e. The IIF sends a featreq message to the serving system, indicating a successful feature control
15 request.
16
17 f. The serving system sends a feature confirmation signal to the subscriber.
18
19 g. The GSM HLR initiates a service profile update by sending an Insert Subscriber Data (ISD)
20 message to the IIF, containing the new or modified profile data (e.g., the new call forward
21 number).
22
23 h. The IIF responds with an ISD acknowledgement message. Note that, if the subscriber’s profile is
24 too large for a single ISD message, then multiple ISD exchanges may be executed between the
25 GSM HLR and the IIF.
26
27 i. The GSM HLR completes the operation by closing the TCAP transaction.
28
29 j. The IIF converts the revised GSM profile data into ANSI-41 equivalents. If this results in a change
30 in the value of the subscriber’s ANSI-41 profile, the IIF includes the revised ANSI-41 profile data
31 in a QUALDIR message it sends to the serving system.
32
33 k. The serving system stores the new profile information and responds with a qualdir message.
34
36 This scenario illustrates the CFU deregistration information flows applicable to ANSI-41 foreign mode
37 operation.
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).
GSM ANSI-136
Home System Serving System Subscriber
IIF
HLR VMSC MS
2
GSM ANSI-41
FEATREQ [digits]
b
ERASE_SS
c
erase_ss
d
featreq [success]
e
feature confirmation
f
ISD
g
isd
h
[TCAP End]
i
QUALDIR
j
qualdir
k
1
2 Figure 36: CFU deregistration (erasure)
3 a. The ANSI-41 serving system receives dialed digits from the subscriber’s mobile station (MS). The
4 serving system detects a “*” character as the first dialed digit. This indicates that the dialed digits
5 are a feature code string.
6
7 b. The serving system sends a FEATREQ message to the IIF, including the digits received from the
8 subscriber.
9
10 c. The IIF parses the received digit string. In this case, the subscriber has requested to erase a call
11 forwarding number. The IIF sends an ERASE_SS message to the GSM HLR.
12
13 d. The HLR processes the request and returns an erase_ss message to the IIF, indicating operation
14 success.
15
16
17 e. The IIF sends a featreq message to the serving system, indicating a successful feature control
18 request.
19
20 f. The serving system sends a feature confirmation signal to the subscriber.
21
22 g. The GSM HLR initiates a service profile update by sending an Insert Subscriber Data (ISD)
23 message to the IIF, containing the new or modified profile data (e.g., the new ss-status value).
24
25
1 h. The IIF responds with an ISD acknowledgement message. Note that, if the subscriber’s profile is
2 too large for a single ISD message, then multiple ISD exchanges may be executed between the
3 GSM HLR and the IIF.
4
5 i. The GSM HLR completes the operation by closing the TCAP transaction.
6
7 j. The IIF converts the revised GSM profile data into ANSI-41 equivalents. If this results in a change
8 in the value of the subscriber’s ANSI-41 profile, the IIF includes the revised ANSI-41 profile data
9 in a QUALDIR message it sends to the serving system.
10
11 k. The serving system stores the new profile information and responds with a qualdir message.
12
1
2 B.1.2.10.3 4.6.1.1.3 CFU activation
3 This scenario illustrates the CFU activation information flows applicable to ANSI-41 foreign mode
4 operation.
GSM ANSI-136
Home System Serving System Subscriber
IIF
HLR VMSC MS
2
GSM ANSI-41
FEATREQ [digits]
b
ACT_SS
c
act_ss
d
featreq [success]
e
feature confirmation
f
ISD
g
isd
h
[TCAP End]
i
QUALDIR
j
qualdir
k
5
6 Figure 37: CFU activation
7 a. The ANSI-41 serving system receives dialed digits from the subscriber’s mobile station (MS). The
8 serving system detects a “*” character as the first dialed digit. This indicates that the dialed digits
9 are a feature code string.
10
11 b. The serving system sends a FEATREQ message to the IIF, including the digits received from the
12 subscriber.
13
14 c. The IIF parses the received digit string. In this case, the subscriber has requested to activate call
15 forwarding. The IIF sends an ACT_SS message to the GSM HLR.
16
17 d. The HLR processes the request and returns an act_ss message to the IIF, indicating operation
18 success.
19
20 e. The IIF sends a featreq message to the serving system, indicating a successful feature control
21 request.
22
23 f. The serving system sends a feature confirmation signal to the subscriber.
24
1 g. The GSM HLR initiates a service profile update by sending an Insert Subscriber Data (ISD)
2 message to the IIF, containing the new or modified profile data (e.g., the new ss-status value).
3
4 h. The IIF responds with an ISD acknowledgement message. Note that, if the subscriber’s profile is
5 too large for a single ISD message, then multiple ISD exchanges may be executed between the
6 GSM HLR and the IIF.
7
8 i. The GSM HLR completes the operation by closing the TCAP transaction.
9
10 j. The IIF converts the revised GSM profile data into ANSI-41 equivalents. If this results in a change
11 in the value of the subscriber’s ANSI-41 profile, the IIF includes the revised ANSI-41 profile data
12 in a QUALDIR message it sends to the serving system.
13
14 k. The serving system stores the new profile information and responds with a qualdir message.
15
16
2 This scenario illustrates the CFU deactivation information flows applicable to ANSI-41 foreign mode
3 operation.
GSM ANSI-136
Home System Serving System Subscriber
IIF
HLR VMSC MS
2
GSM ANSI-41
FEATREQ [digits]
b
DEACT_SS
c
deact_ss
d
featreq [success]
e
feature confirmation
f
ISD
g
isd
h
[TCAP End]
i
QUALDIR
j
qualdir
k
4
5 Figure 38: CFU deactivation
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 deactivate
14 call forwarding. The IIF sends a DEACT_SS message to the GSM HLR.
15
16 d. The HLR processes the request and returns a deact_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
1 g. The GSM HLR initiates a service profile update by sending an Insert Subscriber Data (ISD)
2 message to the IIF, containing the new or modified profile data (e.g., the new ss-status value).
3
4 h. The IIF responds with an ISD acknowledgement message. Note that, if the subscriber’s profile is
5 too large for a single ISD message, then multiple ISD exchanges may be executed between the
6 GSM HLR and the IIF.
7
8 i. The GSM HLR completes the operation by closing the TCAP transaction.
9
10 j. The IIF converts the revised GSM profile data into ANSI-41 equivalents. If this results in a change
11 in the value of the subscriber’s ANSI-41 profile, the IIF includes the revised ANSI-41 profile data
12 in a QUALDIR message it sends to the serving system.
13
14 k. The serving system stores the new profile information and responds with a qualdir message.
15
16 B.1.2.10.5 4.6.1.1.5 CFU Interrogation
17 While in ANSI-41 foreign mode, the GSM subscriber does not have the capability to interrogate the
18 CFU service. An attempt to perform such an operation shall result in an error response
20 This scenario illustrates the CFU invocation information flows applicable to ANSI-41 foreign mode
21 operation.
GSM GSM ANSI-136
Gateway Home System Serving System
IIF
GMSC HLR VMSC
2
GSM ANSI-41
incoming call
a
SRI
b
sri [CFU#]
c
6 See 4.6.1.1.1 for the CFB registration information flows applicable to ANSI-41 foreign mode
7 operation, since they are the same as those for CFU.
9 See 4.6.1.1.2 for the CFB deregistration information flows applicable to ANSI-41 foreign mode
10 operation, since they are the same as those for CFU.
12 See 4.6.1.1.3 for the CFB activation information flows applicable to ANSI-41 foreign mode operation,
13 since they are the same as those for CFU.
15 See 4.6.1.1.4 for the CFB deactivation information flows applicable to ANSI-41 foreign mode
16 operation, since they are the same as those for CFU.
18 While in ANSI-41 foreign mode, the GSM subscriber does not have the capability to interrogate the
19 CFB service. An attempt to perform such an operation shall result in an error response.
21 The following scenarios illustrate the CFB invocation information flows applicable to ANSI-41 foreign
22 mode operation.
24 In this scenario, the busy condition is detected by the ANSI-41 serving system when the
25 RoutingRequest Invoke message is received, and the IIF returns the CFB forward-to number (i.e., as
26 the MSRN) to the GSM HLR in the ProvideRoamingNumber Return Result message.
IIF
GMSC HLR VMSC
2
GSM ANSI-41
incoming call
a
SRI
b
PRN
c
ROUTREQ
d
Subscriber is
detected busy e
routreq [Busy]
f
prn [CFB #]
g
sri [CFB #]
h
2 In this scenario, the busy condition is detected by the ANSI-41 serving system when the
3 RoutingRequest Invoke message is received, and the IIF returns an AbsentSubscriber error code to
4 the GSM HLR in the ProvideRoamingNumber Return Error message.
GSM GSM ANSI-136
Gateway Home System Serving System
IIF
GMSC HLR VMSC
2
GSM ANSI-41
incoming call
a
SRI
b
PRN
c
ROUTREQ
d
Subscriber is
detected busy e
routreq [Busy]
f
prn_RE
[AbsentSubscriber]
g
sri [CFNRc #]
h
2 In this scenario, the busy condition is detected by the ANSI-41 serving system after the
3 RoutingRequest Invoke message is received and while attempting to complete the call to the TLDN,
4 and optimal routing is not invoked.
5
GSM GSM ANSI-136
Gateway Home System Serving System
IIF
GMSC HLR VMSC
2
GSM ANSI-41
incoming call
a
SRI
b
PRN
c
ROUTREQ [BillingID1]
d
routreq [TLDN]
e
prn [MSRN]
f
sri [MSRN]
g
tranumreq [CFB #]
m
1 e. The serving system determines that the subscriber is available; therefore, it returns a routreq
2 message, containing a routing number (called a temporary local directory number, or TLDN, in
3 ANSI-41) to the IIF.
4
5 f. The IIF responds to the GSM HLR with a prn message including the MSRN that it derives from
6 the TLDN; i.e., if the received TLDN is not in international format, then the IIF converts the TLDN
7 into international format for use as the MSRN by adding country code digit(s) associated with the
8 country of the serving system.
9
10 g. The GSM HLR returns an sri message containing the MSRN to the GMSC.
11
12 h. The GMSC establishes a call to the MSRN.
13
14 i. The serving system determines that the subscriber is busy. Note: If call waiting (CW) is active, the
15 serving system would normally invoke CW under these circumstances.
16
17 j. The serving system sends a REDREQ message to the IIF (e.g., using the routing information
18 provided in step-d), indicating that call redirection is requested due to a subscriber busy condition.
19
20 k. Since the IIF is not able to redirect the call (i.e., optimal routing is not possible), it rejects the
21 redirection request.
22
23 l. If the serving system is able to redirect the call, it sends a TRANUMREQ message to the IIF,
24 requesting the CFB forward-to number. Note that not all ANSI-41 systems have implemented this
25 redirection capability. Without this capability, the call shall fail, possibly with a tone or
26 announcement to the calling party.
27
28 m. The IIF determines that CFB is active for the subscriber. Therefore, the IIF responds with a
29 tranumreq message including the subscriber’s CFB forward-to number.
30
31 n. The serving system forwards the call to the CFB forward-to number.
33 In this scenario, the busy condition is detected by the ANSI-41 serving system after the
34 RoutingRequest Invoke message is received and while attempting to complete the call to the TLDN,
35 and optimal routing is invoked.
36 This scenario is covered in Section 4.7.1.
37
2 The following scenarios illustrate the call forwarding no reply (CFNRy) information flows applicable to
3 ANSI-41 foreign mode operation.
5 See 4.6.1.1.1 for the CFNRy registration information flows applicable to ANSI-41 foreign mode
3
6 operation, since they are the same as those for CFU.
8 See 4.6.1.1.2 for the CFNRy deregistration information flows applicable to ANSI-41 foreign mode
9 operation, since they are the same as those for CFU.3
11 See 4.6.1.1.3 for the CFNRy activation information flows applicable to ANSI-41 foreign mode
12 operation, since they are the same as those for CFU. 3
14 See 4.6.1.1.4 for the CFNRy deactivation information flows applicable to ANSI-41 foreign mode
15 operation, since they are the same as those for CFU. 3
17 The following scenarios illustrate the CFNRy invocation information flows applicable to ANSI-41
18 foreign mode operation.
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).
2 In this scenario, the no reply condition is detected by the ANSI-41 serving system while attempting to
3 complete the call to the TLDN, and optimal routing is not invoked.
GSM GSM ANSI-136
Gateway Home System Serving System
IIF
GMSC HLR VMSC
2
GSM ANSI-41
incoming call
a
SRI
b
PRN
c
ROUTREQ [BillingID1]
d
routreq [TLDN]
e
prn [MSRN]
f
sri [MSRN]
g
tranumreq [CFNRy #]
m
9 i. The serving system determines that the subscriber does not answer the alert.
10
11 j. The serving system sends a REDREQ message to the IIF (e.g., using the routing
12 information provided in step-d), indicating that call redirection is requested due to a subscriber no
13 answer 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
1 l. If the serving system is able to redirect the call, it sends a TRANUMREQ message to the IIF,
2 requesting the CFNA (i.e., GSM CFNRy) forward-to number. Note that not all ANSI-41 systems
3 have implemented this redirection capability. Without this capability, the call shall fail, possibly
4 with a tone or announcement to the calling party.
5
6 m. The IIF determines that CFNRy is active for the subscriber. Therefore, the IIF responds with a
7 tranumreq message including the subscriber’s CFNRy forward-to number.
8
9 n. The serving system forwards the call to the CFNRy forward-to number.
11 In this scenario, the no reply condition is detected by the ANSI-41 serving system while attempting to
12 complete the call to the TLDN, and optimal routing is invoked.
13 This scenario is addressed in Section 4.7.1.
14
2 The following scenarios illustrate the call forwarding not reachable (CFNRc) information flows
3 applicable to ANSI-41 foreign mode operation.
5 See 4.6.1.1.1 for the CFNRc registration information flows applicable to ANSI-41 foreign mode
6 operation.4
8 See 4.6.1.1.2 for the CFNRc deregistration information flows applicable to ANSI-41 foreign mode
4
9 operation, since they are the same as those for CFU.
11 See 4.6.1.1.3 for the CFNRc activation information flows applicable to ANSI-41 foreign mode
4
12 operation, since they are the same as those for CFU.
14 See 4.6.1.1.4 for the CFNRc deactivation information flows applicable to ANSI-41 foreign mode
4
15 operation, since they are the same as those for CFU.
17 The following scenarios illustrate the CFNRc invocation information flows applicable to ANSI-41
18 foreign mode operation.
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.
2 In this scenario, the not reachable condition is detected either by the IIF or by the ANSI-41 serving
3 system when the RoutingRequest Invoke message is received.
GSM GSM ANSI-136
Gateway Home Serving
IIF
GMSC HLR VMSC
2
GSM ANSI-41
incoming call
a
SRI
b
PRN
c
ROUTREQ
d
No response
to paging e
routreq [No response]
f
prn_RE
[AbsentSubscriber]
g
sri [CFNRc #]
h
2 In this scenario, the not reachable condition is detected by the ANSI-41 serving system after the
3 RoutingRequest Invoke message is received and while attempting to complete the call to the TLDN,
4 and optimal routing is not invoked.
GSM GSM ANSI-136
Gateway Home System Serving System
IIF
GMSC HLR VMSC
2
GSM ANSI-41
incoming call
a
SRI
b
PRN
c
ROUTREQ [BillingID1]
d
routreq [TLDN]
e
prn [MSRN]
f
sri [MSRN]
g
1 If the serving system is able to redirect the call, it sends a TRANUMREQ message to the IIF,
2 requesting the forward-to number appropriate for the no page response condition. Note that not
3 all ANSI-41 systems have implemented this redirection capability. Without this capability, the call
4 shall fail, possibly with a tone or announcement to the calling party.
5
6 l. The IIF determines that CFNRc is active for the subscriber. Therefore, the IIF responds with a
7 tranumreq message including the subscriber’s CFNRc forward-to number.
8
9 m. The serving system forwards the call to the CFNRc forward-to number.
11 In this scenario, the not reachable condition is detected by the ANSI-41 serving system after the
12 RoutingRequest Invoke message is received and while attempting to complete the call to the TLDN,
13 and optimal routing is invoked.
14 This scenario is addressed in Section 4.7.1.
15
5 The following scenarios illustrate the call forwarding unconditional (CFU) information flows applicable
6 to GSM foreign mode operation.
8 This scenario illustrates the CFU registration information flows applicable to GSM foreign mode
9 operation.
ANSI-41 GSM
Home System Serving System Subscriber
IIF
HLR VMSC MS
2
ANSI-41 GSM
A_REG_SS
a
REG_SS
b
FEATREQ [digits]
c
featreq [success]
d
reg_ss
e
a_reg_ss
f
10
11 Figure 46: CFU registration
12
13 a. The GSM serving system receives an A_REG_SS message from the subscriber’s mobile station
14 (MS), indicating that the subscriber wishes to change his CFU forward-to number.
15
16 b. The serving system sends a REG_SS message to the IIF, constructed based on the information
17 received in the A_REG_SS message.
18
19 c. The IIF translates the information received in the REG_SS message into a corresponding digit
20 string (e.g., based on internal tables) and sends this string to the ANSI-41 HLR in a FEATREQ
21 message.
22
23 d. The HLR processes the request and returns a featreq message to the IIF, indicating operation
24 success.
25
26 e. The IIF sends a reg_ss message to the serving system, indicating a successful feature control
27 request.
28
29 f. The serving system sends a registration response message to the subscriber.
30
1 Note: The process of registering the call forward number may also result in activation of the service.
2 This is based on HLR (i.e., carrier) determined policy.
3 B.1.3.1.2 4.6.2.1.2 CFU deregistration (erasure)
4 This scenario illustrates the CFU deregistration information flows applicable to GSM foreign mode
5 operation.
ANSI-41 GSM
Home System Serving System Subscriber
IIF
HLR VMSC MS
2
ANSI-41 GSM
A_ERASE_SS
a
ERASE_SS
b
FEATREQ [digits]
c
featreq [success]
d
erase_ss
e
a_erase_ss
f
6
7 Figure 47: CFU deregistration (erasure)
8 a. The GSM serving system receives an A_ERASE_SS message from the subscriber’s mobile
9 station (MS), indicating that the subscriber wishes to deregister the CFU service.
10
11 b. The serving system sends an ERASE_SS message to the IIF, constructed based on the
12 information received in the A_ERASE_SS message.
13
14 c. The IIF translates the information received in the ERASE_SS message into a corresponding digit
15 string (e.g., based on internal tables) and sends this string to the ANSI-41 HLR in a FEATREQ
16 message.
17
18 d. The HLR processes the request and returns a featreq message to the IIF, indicating operation
19 success.
20
21 e. The IIF sends an erase_ss message to the serving system, indicating a successful feature control
22 request.
23
24 f. The serving system sends a deregistration response message to the subscriber.
25
26 Note: The process of deregistering the call forward service also results in deactivation of the service.
27
2 This scenario illustrates the CFU activation information flows applicable to GSM foreign mode
3 operation.
ANSI-41 GSM
Home System Serving System Subscriber
IIF
HLR VMSC MS
2
ANSI-41 GSM
A_ACT_SS
a
ACT_SS
b
FEATREQ [digits]
c
featreq [success]
d
act_ss
e
a_act_ss
f
4
5 Figure 48: CFU activation
6 a. The GSM serving system receives an A_ACT_SS message from the subscriber’s mobile station
7 (MS), indicating that the subscriber wishes to activate the CFU service.
8
9 b. The serving system sends an ACT_SS message to the IIF, constructed based on the information
10 received in the A_ACT_SS message.
11
12 c. The IIF translates the information received in the ACT_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 act_ss message to the serving system, indicating a successful feature control
20 request.
21
22 f. The serving system sends an activation response message to the subscriber.
24
25 This scenario illustrates the CFU deactivation information flows applicable to GSM foreign mode
26 operation.
27
ANSI-41 GSM
Home System Serving System Subscriber
IIF
HLR VMSC MS
2
ANSI-41 GSM
A_DEACT_SS
a
DEACT_SS
b
FEATREQ [digits]
c
featreq [success]
d
deact_ss
e
a_deact_ss
f
1
2 Figure 49: CFU deactivation
3
4 a. The GSM serving system receives an A_DEACT_SS message from the subscriber’s mobile
5 station (MS), indicating that the subscriber wishes to deactivate the CFU service.
6
7 b. The serving system sends a DEACT_SS message to the IIF, constructed based on the
8 information received in the A_DEACT_SS message.
9
10 c. The IIF translates the information received in the DEACT_SS message into a corresponding digit
11 string (e.g., based on internal tables) and sends this string to the ANSI-41 HLR in a FEATREQ
12 message.
13
14 d. The HLR processes the request and returns a featreq message to the IIF, indicating operation
15 success.
16
17 e. The IIF sends a deact_ss message to the serving system, indicating a successful feature control
18 request.
19
20 f. The serving system sends a deactivation response message to the subscriber.
21
2 This scenario illustrates the CFU invocation information flows applicable to GSM foreign mode
3 operation.
4
ANSI-41 ANSI-41 GSM
Originating MSC Home System Serving System
IIF
GMSC HLR VMSC
2
ANSI-41 GSM
incoming call
a
LOCREQ
b
locreq [CFU#]
c
2 The following scenarios illustrate the call forwarding busy (CFB) information flows applicable to GSM
3 foreign mode operation.
4 Since the ANSI-41 HLR does not provide the CFB forward-to number to the serving system until the
5 feature is actually invoked—versus the GSM method, whereby the HLR provides the forward-to
6 number(s) to the serving system as part of the subscriber’s profile information at registration time—
7 the IIF shall use the ANSI-41 TransferToNumberRequest operation to obtain the CFB forward-to
8 number. This is illustrated in Figure 51.
ANSI-41 GSM
Home System Serving System Subscriber
IIF
HLR VMSC MS
2
ANSI-41 GSM
a
Normal registration process
TRANUMREQ
b
tranumreq
c
TRANUMREQ
d
tranumreq
e
ISD
f
isd
g
[TCAP End]
h
9
10 Figure 51: Obtaining forward-to numbers
11 a. The subscriber registers on a GSM serving system using the normal registration signaling
12 process.
13
14 b. If the subscriber’s ANSI-41 profile indicates that CFB is authorized and active, and the IIF
15 determines that it does may not have the current CFB forward-to number, then the IIF sends a
16 TRANUMREQ message to the HLR requesting the CFB forward-to number.
17
18 c. The HLR responds with the CFB forward-to number in the tranumreq message.
19
20 d. If the subscriber’s ANSI-41 profile indicates that CFNA is authorized and active, and the IIF
21 determines that it does may not have the current CFNA forward-to number, then the IIF sends a
22 TRANUMREQ message to the HLR requesting the CFNA forward-to number.
23
24 e. The HLR responds with the CFNA forward-to number in the tranumreq message.
25
26 f-h. If the CFB forward-to number or CFNA forward-to number, or both numbers do not correspond
27 with the numbers previously provided to the GSM serving system, then the IIF sends the modified
28 information to the GSM serving system using the InsertSubscriberData operation. The CFNA
29 forward-to number shall be populated as both the CFNRc and CFNRy forward-to numbers.
2 This scenario illustrates the CFB registration information flows applicable to GSM foreign mode
3 operation.
ANSI-41 GSM
Home System Serving System Subscriber
IIF
HLR VMSC MS
2
ANSI-41 GSM
A_REG_SS
a
REG_SS
b
FEATREQ [digits]
c
featreq [success]
d
reg_ss
e
a_reg_ss
f
QUALDIR
g
qualdir
h
TRANUMREQ
i
tranumreq
j
ISD
k
isd
l
[TCAP End]
m
4
5 Figure 52: CFB registration
6 a. The GSM serving system receives an A_REG_SS message from the subscriber’s mobile station
7 (MS), indicating that the subscriber wishes to change his call forwarding number.
8
9 b. The serving system sends a REG_SS message to the IIF, constructed based on the information
10 received in the A_REG_SS message.
11
12 c. The IIF translates the information received in the REG_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 a reg_ss message to the serving system, indicating a successful feature control
20 request.
21
2 This scenario illustrates the CFB deregistration information flows applicable to GSM foreign mode
3 operation.
ANSI-41 GSM
Home System Serving System Subscriber
IIF
HLR VMSC MS
2
ANSI-41 GSM
A_ERASE_SS
a
ERASE_SS
b
FEATREQ [digits]
c
featreq [success]
d
erase_ss
e
a_erase_ss
f
QUALDIR
g
qualdir
h
ISD
i
isd
j
[TCAP End]
k
4
5 Figure 53: CFB deregistration (erasure)
6
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 call forward 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
1 g-h. If the subscriber’s ANSI-41 profile changes as a result of the operation (e.g., the service was
2 previously authorized and activated), the HLR sends a QUALDIR message to the IIF, containing
3 the new profile information.
4
5 i-k. If the subscriber’s GSM profile has changed as a result of these operations, then the IIF sends
6 the modified profile information to the serving system via an InsertSubscriberData message
7 exchange.
8
9 Note: The process of deregistering the call forwarding service also results in deactivation of the
10 service.
11
12 B.1.3.2.3 4.6.2.2.3 CFB activation
13 This scenario illustrates the CFB activation information flows applicable to GSM foreign mode
14 operation.
ANSI-41 GSM
Home System Serving System Subscriber
IIF
HLR VMSC MS
2
ANSI-41 GSM
A_ACT_SS
a
ACT_SS
b
FEATREQ [digits]
c
featreq [success]
d
act_ss
e
a_act_ss
f
QUALDIR
g
qualdir
h
ISD
i
isd
j
[TCAP End]
k
15
16 Figure 54: CFB activation
17
18 a. The GSM serving system receives an A_ACT_SS message from the subscriber’s mobile station
19 (MS), indicating that the subscriber wishes to activate the call forward service.
20
21 b. The serving system sends an ACT_SS message to the IIF, constructed based on the information
22 received in the A_ACT_SS message.
23
1 c. The IIF translates the information received in the ACT_SS message into a corresponding digit
2 string (e.g., based on internal tables) and sends this string to the ANSI-41 HLR in a FEATREQ
3 message.
4
5 d. The HLR processes the request and returns a featreq message to the IIF, indicating operation
6 success.
7
8 e. The IIF sends an act_ss message to the serving system, indicating a successful feature control
9 request.
10
11 f. The serving system sends an activation response message to the subscriber.
12
13 g-h. If the subscriber’s ANSI-41 profile changes as a result of the operation (e.g., the service was
14 previously authorized but not active), the HLR sends a QUALDIR message to the IIF, containing
15 the new profile information.
16
17 i-k. If the subscriber’s GSM profile has changed as a result of these operations, then the IIF sends
18 the modified profile information to the serving system via an InsertSubscriberData message
19 exchange.
21 This scenario illustrates the CFB deactivation information flows applicable to GSM foreign mode
22 operation.
ANSI-41 GSM
Home System Serving System Subscriber
IIF
HLR VMSC MS
2
ANSI-41 GSM
A_DEACT_SS
a
DEACT_SS
b
FEATREQ [digits]
c
featreq [success]
d
deact_ss
e
a_deact_ss
f
QUALDIR
g
qualdir
h
ISD
i
isd
j
[TCAP End]
k
23
24 Figure 55: CFB deactivation
1
2 a. The GSM serving system receives an A_DEACT_SS message from the subscriber’s mobile
3 station (MS), indicating that the subscriber wishes to deactivate the call forward service.
4
5 b. The serving system sends a DEACT_SS message to the IIF, constructed based on the
6 information received in the A_DEACT_SS message.
7
8 c. The IIF translates the information received in the DEACT_SS message into a corresponding digit
9 string (e.g., based on internal tables) and sends this string to the ANSI-41 HLR in a FEATREQ
10 message.
11
12 d. The HLR processes the request and returns a featreq message to the IIF, indicating operation
13 success.
14
15 e. The IIF sends a deact_ss message to the serving system, indicating a successful feature control
16 request.
17
18 f. The serving system sends a deactivation response message to the subscriber.
19
20 g-h. If the subscriber’s ANSI-41 profile changes as a result of the operation (e.g., the service was
21 previously authorized and active), the HLR sends a QUALDIR message to the IIF, containing the
22 new profile information.
23
24 i-k. If the subscriber’s GSM profile has changed as a result of these operations, then the IIF sends
25 the modified profile information to the serving system via an InsertSubscriberData message
26 exchange.
28 The following scenarios illustrate the CFB invocation information flows applicable to GSM foreign
29 mode operation.
30
2 In this scenario, the busy condition is detected by the GSM serving system while attempting to
3 complete the call to the TLDN, and optimal routing is not invoked.
ANSI-41 ANSI-41 GSM
Originating MSC Home System Serving System
IIF
OMSC HLR VMSC
2
ANSI-41 GSM
incoming call
a
LOCREQ
b
ROUTREQ
c
PRN
d
prn [MSRN]
e
routreq [TLDN]
f
locreq [TLDN]
g
Subscriber is
detected busy i
2 In this scenario, the busy condition is detected by the GSM serving system while attempting to
3 complete the call to the TLDN, and optimal routing is invoked.
4 This scenario is addressed in Section 4.7.2.
6 The following scenarios illustrate the call forwarding no answer (CFNA) information flows applicable
7 to GSM foreign mode operation.
8 Since the ANSI-41 HLR does not provide the CFNA forward-to number to the serving system until the
9 feature is actually invoked—versus the GSM method, whereby the HLR provides the forward-to
10 number(s) to the serving system as part of the subscriber’s profile information at registration time—
11 the IIF shall use the ANSI-41 TransferToNumberRequest operation to obtain the CFNA forward-to
12 number. This is illustrated in Figure 51 and described in Section 4.6.2.2.
13 Note that ANSI-41, unlike GSM, does not distinguish the “not reachable” condition from the “no reply”
14 condition. Therefore, if ANSI-41 CFNA is activated, then both of the GSM CFNRy and CFNRc
15 services shall be considered activated.
17 See 4.6.2.2.1 for the CFNA registration information flows applicable to GSM foreign mode operation,
18 since they are the same as those for CFB. Both CFNRy and CFNRc shall be registered in the IIF and
19 GSM VLR.
21 See 4.6.2.2.2 for the CFNA deregistration information flows applicable to GSM foreign mode
22 operation, since they are the same as those for CFB. Both CFNRy and CFNRc shall be deregistered
23 in the IIF and GSM VLR.
25 See 4.6.2.2.3 for the CFNA activation information flows applicable to GSM foreign mode operation,
26 since they are the same as those for CFB. Both CFNRy and CFNRc shall be activated in the IIF and
27 GSM VLR.
28 B.1.3.3.4 4.6.2.3.4 CFNA deactivation
29 See 4.6.2.2.4 for the CFNA deactivation information flows applicable to GSM foreign mode operation,
30 since they are the same as those for CFB. Both CFNRy and CFNRc shall be deactivated in the IIF
31 and GSM VLR.
32 B.1.3.3.5 4.6.2.3.5 CFNA invocation
33 The following scenarios illustrate the CFNA invocation information flows applicable to GSM foreign
34 mode operation.
35 B.1.3.3.5.1 4.6.2.3.5.1 CFNA invocation (Scenario 1, without OR)
36 In this scenario, the no reply condition is detected by the GSM serving system while attempting to
37 complete the call to the TLDN, and optimal routing is not invoked.
IIF
OMSC HLR VMSC
2
ANSI-41 GSM
incoming call
a
LOCREQ
b
ROUTREQ
c
PRN
d
prn [MSRN]
e
routreq [TLDN]
f
locreq [TLDN]
g
Subscriber does
not answer i
9 In this scenario, the no reply condition is detected by the GSM serving system while attempting to
10 complete the call to the TLDN, and optimal routing is invoked.
11
12 This scenario is addressed in Section 4.7.2.
13
15 Scenario: GSM Subscriber A makes a call origination attempt at GMSC-A to a GSM Subscriber B
16 who is roaming and registered in an ANSI-41 network at MSC-B. Subscriber B has call forwarding set
17 to an address at MSC-C.
18
19
20 Figure 58: Optimal Routing with Late Call Forwarding (ANSI-41 Foreign Mode) Success Case
21
1 GSM-Send Routing Information message to Subscriber B's GSM HLR requesting it to send a call
2 forwarding information.
3
4 Otherwise, it is assumed that all forwarding information is ready available at GMSC-A and an
5 acknowledgment of the GSM-Resume Call Handling message is sent to the IIF (step m).
6
7 l. If a corresponding forwarded-to number is available at subscriber B's GSM HLR, GMSC-A
8 receives a GSM-Send Routing Information Acknowledge message with the necessary forwarding
9 information.
10
11 In case of an error, a GSM-Send Routing Information Error message is sent to GMSC-A and
12 GMSC-A uses the forwarding information from step j.
13
14 m. GMSC-A sends an acknowledgment of the GSM-Resume Call Handling message.
15
16 n. Upon receipt of GSM-Resume Call Handling Acknowledgment message, the IIF acknowledges
17 the ANSI-41-Redirection Request message.
18
19 In case of an error, the IIF rejects the redirection request and the ANSI-MSC-B initiates a call
20 forwarding procedure extend the call to MSC-C. See Section 6.2.
21
22 o. If step n is successful, GMSC-A releases all circuit-associated resources specific to ANSI-41
23 MSC/VLR-B.
24
25 p. GMSC-A starts a call setup procedure using the call forwarded-to number as Subscriber B’s
26 address at ANSI-41 MSC-C.
27
28
2 Scenario: GSM Subscriber A makes a call origination attempt at GMSC-A to GSM Subscriber B
3 roaming and registered in an ANSI-41 network at MSC-B. Subscriber B has call forwarding set to an
4 address at MSC-C. Optimal Routing fails at IPLMN.
q Forward Call q
5
6 Figure 59: Optimal Routing with Late Call Forwarding (ANSI-41 Foreign Mode) Failure Case
7 a.-l.These steps are the same as the success case.
8
9 m. If GMSC-A determines that it cannot forward the call via an optimal route, it returns a Resume
10 Call Handling error to the IIF.
11
12 n. The redirection request at step i. is rejected.
13
14 o. The ANSI-41 MSC/VLR-B sends an ANSI-41 TransferToNumberRequest message to the IIF with
15 the RedirectionReason parameter.
16
17 p. The IIF returns the ANSI-41 TransferToNumberResponse message to the ANSI-41 MSC/VLR-B
18 with the forward-to number in the TerminationList parameter along with an indication of the
19 reason (DMH_RedirectionIndicator) for extending the incoming call.
20
21 q. The ANSI-41 MSC/VLR-B forwards the incoming call to MSC-C.
22
3 Scenario: ANSI-41 Subscriber A makes a call origination attempt at ANSI-41 MSC-A to ANSI-41
4 Subscriber B roaming and registered in a GSM network at MSC-B. Subscriber B has call forwarding
5 set to an address at MSC-C. Subscriber B is not IMSI detached.
6
7 Figure 60: Optimal Routing with Late Call Forwarding (GSM Foreign Mode) Success Case
8 a. ANSI-41 MSC-A receives a call origination stimulus from Subscriber A.
9
10 b. The ANSI-41 MSC-A sends an ANSI-41-Location Request message for routing information to
11 Subscriber B's ANSI-41 HLR with the MSCID address of the originating MSC (ANSI-41 MSC-A).
12
13 c. Subscriber B's ANSI-41 HLR determines that Subscriber B is roaming at MSC-B and sends a
14 ANSI-41-Routing Request message number with the MSCID address of the ANSI-41 MSC-A
15 received in step b. to an IIF acting on behalf of MSC-B to get a roaming number.
16
17 d. The IIF relays this request to GSM MSC/VLR-B by sending a GSM-Provide Roaming Number
18 message. The IIF generates two parameters: the Call Reference number (for the VLR/MSC-B to
19 use in the GSM-RCH) and the GMSC address set to the IIF address, to indicate that the IIF is
20 capable of supporting optimal routing for late call forwarding.
21
22 e. GSM MSC/VLR-B acknowledges the GSM - Provide Roaming Number message with the Mobile
23 Subscriber Roaming Number (MSRN).
24
25 f. Upon receipt of this message, the IIF sends the TLDN to Subscriber B's ANSI-41 HLR in the
26 ANSI-41-Routing Request message.
1
2 g. Subscriber B's ANSI-41 HLR relays this information to ANSI-41 MSC-A via the ANSI-41-Location
3 Request (Acknowledgment) message.
4
5 h. ANSI-41 MSC starts a call setup procedure using TLDN (MSRN) as Subscriber B's called
6 address at GSM MSC/VLR-B. The incoming call can not be terminated at GSM MSC/VLR-B
7 because of reasons such as Busy, Not Reachable, or No Reply.
8
9 i. Since the GMSC address and the Call Reference Number parameters were present in the
10 GSM-Provide Roaming Number message the GSM MSC-B sends a GSM-Resume Call Handling
11 message to the IIF with the received Call Reference number and all necessary information
12 required for call forwarding.
13
14 If optimal routing is not supported the call is forwarded by GSM MSC-B using the forwarding
15 information available.
16
17 j. When optimal routing is supported and the IIF receives the GSM-Resume Call Handling
18 message, the IIF sends an ANSI-41-Redirecion Request message with the Redirection Reason to
19 the ANSI-41 MSC-A supporting subscriber A's call origination attempt.
20
21 k. The ANSI-41 MSC-A passes this Redirection Reason to the Subscriber B's ANSI-41 HLR in the
22 ANSI-41-Transfer To Number message to get call forwarding number information.
23
24 l. Based on the Redirection Reason, the ANSI-41 HLR returns the corresponding forwarded-to
25 number to ANSI-41 MSC/VLR-A.
26
27 m. If ANSI-41 MSC-A received forwarded-to number from ANSI-41 HLR, it sends
28 ANSI-41-Redirection Request (Acknowledgment) message to the IIF.
29
30 In case of an error, ANSI-41 MSC-A rejects the redirection request. The IIF then returns a
31 GSM-Resume Call Handling Error message to GSM MSC-B, which then attempts to forward the
32 call to MSC-C using the forwarding information available.
33
34 n. Upon receiving the ANSI-41-Redirection Request (Acknowledgment) in step m., the IIF sends a
35 GSM-Resume Call Handling Acknowledgment message to GSM MSC-B.
36
37 o. The ANSI-41 MSC-A releases all circuit-associated resources specific to GSM MSC/VLR-B.
38
39 p. The ANSI-41 MSC-A starts a call setup procedure using the call forwarded-to number as
40 Subscriber B's address at MSC-C.
41
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. Optimal Routing fails at IPLMN. Subscriber B is not IMSI detached.
5
ANSI-41 ANSI-41 GSM
(MSC-A) (B’s HLR) IIF (VLR/MSC-B) (MSC-C)
Call Origination
a a
LOCREQ
b b
ROUTEREQ
c c
Provide Roaming Number [GMSC#,CR#]
d d
Provide Roaming NumberAck [MSRN]
e e
Routereq [TLDN]
f f
Locreq [TLDN]
g g
h Establish Connection Attempt h
Resume Call Handling [CR#,reason]
i i
j REDREQ [REDREASON]
j
TRANUMREQ [REDREASON]
k k
tranumreq
l l
redreq (reject)
m m
Resume Call Handling Error
n n
o Forward Call o
6
7 Figure 61: Optimal Routing with Late Call Forwarding (GSM Foreign Mode) Failure Case
8 a.-l.These steps are the same as the Success Case.
9
10 m. The redirection request at step j. is rejected.
11
12 n. The IIF sends a GSM-Resume Call Handling Error message to GSM MSC-B.
13
14 o. The GSM MSC-B forwards the incoming call to MSC-C.
15
6 This scenario describes a successful call waiting activation by a native GSM subscriber roaming in an
7 ANSI-41 network.
Serving System
MS MSC/ GSM
IIF
VLR HLR
*FC [SEND]
a
FEATREQ [DGTSDIAL]
b
ActivateSS
c
ActivateSS Ack
d
featreq [FEATRESULT, ANNLIST]
e
feature confirmation
f
call release
g
qualdir k
8
9 Figure 62: ANSI-41 Foreign Mode Call Waiting Activation
10 a. The subscriber requests activation of call waiting. The MS converts the user-entered MMI/menu
11 selections to feature codes. (e.g. *FC). The MS sends this feature code string to the Serving
12 MSC. During analysis of the digit string, the Serving MSC detects a feature code string.
13 b. The digit string is included in a FEATREQ and sent from the Serving MSC to the IIF emulating the
14 HLR associated with the MS.
1 c. The IIF determines the digit string pertains to the activation of call waiting and then sends an
2 Activate SS message to the HLR to request activation of call waiting. 5
3 d. The HLR returns an Activate SS Ack message to the IIF indicating a successful activation of call
4 waiting.
5 e. The IIF sends a featreq to the Serving MSC containing the feature request confirmation
6 indication.
7 f. When the featreq is received from the IIF, the Serving MSC provides treatment to the served MS
8 based on the information contained in the response. In this case, the treatment is to apply feature
9 confirmation.
10 g. The Serving MSC releases the call.
11 h. Because the request resulted in a change to the subscriber’s service profile (i.e., the call waiting
12 feature was activated), the HLR reports the change by sending an Insert Subscriber Data
13 message to the IIF emulating the Serving MSC/VLR.
14 i. The IIF returns an Insert Subscriber Data Ack message to the HLR.
15 j. The IIF sends a QUALDIR message to the Serving MSC/VLR.
16 k. The Serving MSC/VLR returns a qualdir to the IIF.
18 The following scenario describes an unsuccessful call waiting activation by a native GSM subscriber
19 roaming in an ANSI-41 network.
20
5 Most likely, the GSM 02.30 standardized MMI would be mapped to the equivalent GSM
functional message.
Serving System
MS MSC/ GSM
IIF
VLR HLR
*FC [SEND]
a
FEATREQ [DGTSDIAL]
b
ActivateSS
c
3 a. The subscriber requests activation of call waiting. The MS converts the user-entered MMI/menu
4 selections to feature codes. (e.g. *FC). The MS sends this feature code string to the Serving
5 MSC. During analysis of the digit string, the Serving MSC detects a feature code string.
6 b. The digit string is included in a FEATREQ and sent from the Serving MSC to the IIF emulating the
7 HLR associated with the MS.
8 c. The IIF determines the digit string pertains to the activation of call waiting and then sends an
9 Activate SS message to the HLR to request activation of call waiting. 6
10 d. The HLR returns an Activate SS Ack message to the IIF indicating an unsuccessful activation of
11 call waiting.
12 e. The IIF sends a featreq to the Serving MSC containing a Feature Result parameter set to
13 “Unsuccessful”. In addition, it may include an AnnouncementList code that corresponds to the
14 User error parameter included in the Activate SS Ack message sent by the GSM HLR.
15 f. When the featreq is received from the IIF, the Serving MSC provides treatment to the served MS
16 based on the information contained in the response.
17 g. The Serving MSC sends a Release message to the MS.
18
19
6 Most likely, the GSM 02.30 standardized MMI would be mapped to the equivalent GSM
functional message.
2 This scenario describes a successful call waiting activation by a native ANSI-136 41 subscriber
3 roaming in a GSM network.
GSM
MS MSC/
IIF HLR
VLR
Activate SS
a
Activate SS
b
FEATREQ [DGTSDIAL]
c
featreq [FEATRESULT, ANNLIST]
d
Activate SS Ack
e
Activate SS Ack
f
QUALDIR g
Insert Subscriber Data
h
ISD Ack i
qualdir
j
4
5 Figure 64: GSM Foreign Mode Call Waiting Activation
6 a. The subscriber requests activation of call waiting. The MS interprets the user-entered
7 MMI/menu selections. The MS sends a request for activation of call waiting (by issuing an
8 Activate SS operation).
9 b. The Serving GSM MSC sends an Activate SS message to the IIF emulating the HLR
10 associated with the subscriber. The message specifies the call waiting supplementary service
11 for the activation being requested.
12 c. The IIF converts the call waiting Activate SS message to a particular feature code (e.g. *FC).
13 The IIF includes this feature code (including *) in the Digits (Dialed) parameter of a
14 FEATREQ message and sends the message to the subscriber’s HLR.
15 d. The HLR returns a featreq message to the IIF indicating a successful call waiting activation.
16 e. The IIF returns an Activate SS Ack message back to the Serving GSM MSC. Any parameters
17 the HLR may have included that provide instructions for treatment towards the user (such as
18 AnnouncementList) shall be ignored by the IIF and not mapped into the message sent to the
19 Serving GSM MSC.
20 f. When the Activate SS Ack message is received from the IIF, the Serving GSM MSC sends a
21 message to the MS to indicate that the call waiting activation had been successful.
1 g. Because the request resulted in a change to the subscriber’s service profile (i.e., the call
2 waiting feature was activated), the HLR reports the change by sending a QUALDIR message
3 to the IIF emulating the Serving GSM MSC/VLR.
4 h. The IIF sends an Insert Subscriber Data message to the Serving GSM MSC/VLR.
5 i. The Serving GSM MSC/VLR returns an Insert Subscriber Data Ack to the IIF.
6 j. The IIF returns a qualdir message to the HLR.
7 Note that the GSM foreign mode unsuccessful call waiting activation case parallels the ANSI-41
8 foreign mode unsuccessful call waiting activation case shown in the previous section.
9 4.8.2 Call Waiting Deactivation
10 B.1.3.11 4.8.2.1 ANSI-41 Foreign Mode Call Waiting Deactivation
11 This scenario describes a successful call waiting deactivation by a native GSM subscriber roaming in
12 an ANSI-41 network.
13
MS MSC/ GSM
IIF
VLR HLR
*FC0 [SEND]
a
FEATREQ [DGTSDIAL]
b
DeactivateSS
c
DeactivateSS Ack
d
featreq [FEATRESULT, ANNLIST]
e
feature confirmation
f
call release
g
qualdir k
1
2 Figure 65: ANSI-41 Foreign Mode Call Waiting Deactivation
3 a. The subscriber selects a menu entry in order to deactivate call waiting. The MS converts the
4 user-entered MMI/menu selections to feature codes. (e.g. *FC0). The MS sends this digit string
5 towards the network. The digit string is received by the Serving MSC. During analysis of the digit
6 string, the Serving MSC detects a feature code string.
7 b. The dialed digits are included in a FEATREQ and sent from the Serving MSC to the IIF emulating
8 the HLR associated with the MS.
9 c. The IIF determines the digit string pertains to the deactivation of call waiting and then sends a
10 Deactivate SS message to the HLR to request deactivation of call waiting. 7
11 d. The HLR returns a Deactivate SS Ack message to the IIF indicating a successful deactivation of
12 call waiting.
7 Most likely, the GSM 02.30 standardized MMI would be mapped to the equivalent GSM
functional message.
1 e. The IIF sends a featreq to the Serving MSC containing the feature request confirmation
2 indication.
3 f. When the featreq is received from the IIF, the Serving MSC provides treatment to the served MS
4 based on the information contained in the response. In this case, the treatment is to apply feature
5 confirmation.
6 g. The Serving MSC releases the call.
7 h. Because the request resulted in a change to the subscriber’s service profile (i.e., the call waiting
8 feature was deactivated), the HLR reports the change by sending an Insert Subscriber Data
9 message to the IIF emulating the Serving MSC/VLR.
10 i. The IIF returns an Insert Subscriber Data Ack message to the HLR.
11 j. The IIF sends a QUALDIR message to the Serving MSC/VLR.
12 k. The Serving MSC/VLR returns a qualdir to the IIF.
14 This scenario describes a successful call waiting deactivation by a native ANSI-136 41 subscriber
15 roaming in a GSM network.
16
MS GSM
MSC/ IIF HLR
VLR
Deactivate SS
a
Deactivate SS
b
FEATREQ [DGTSDIAL]
c
featreq [FEATRESULT, ANNLIST]
d
Deactivate SS Ack
e
Deactivate SS Ack
f
QUALDIR g
Insert Subscriber Data
h
ISD Ack i
qualdir
j
1
2 Figure 66: GSM Foreign Mode Call Waiting Deactivation
3 a. The subscriber requests activation of call waiting. The MS associates the MMI/menu selection
4 provided by the subscriber with a request to deactivate call waiting. The MS sends a request for
5 deactivation of call waiting (by issuing a Deactivate SS operation).
6 b. The Serving GSM MSC sends a Deactivate SS message to the IIF emulating the HLR associated
7 with the subscriber. The message specifies the call waiting supplementary service for the
8 deactivation being requested.
9 c. The IIF converts the call waiting Deactivate SS message to a particular digit string (e.g. *FC0).
10 The IIF includes this digit string (including *) in the Digits (Dialed) parameter of a FEATREQ
11 message and sends the message to the subscriber’s HLR.
12 d. The HLR returns a featreq message to the IIF indicating a successful call waiting deactivation.
13 e. The IIF returns a Deactivate SS Ack message back to the Serving GSM MSC. Any parameters
14 the HLR may have included that provide instructions for treatment towards the user (such as
15 AnnouncementList) shall be ignored by the IIF and not mapped into the message sent to the
16 Serving GSM MSC.
1 f. When the Deactivate SS Ack message is received from the IIF, the Serving GSM MSC sends a
2 message to the MS to indicate that the call waiting deactivation had been successful.
3 g. Because the request resulted in a change to the subscriber’s service profile (i.e., the call waiting
4 feature was deactivated), the HLR reports the change by sending a QUALDIR message to the IIF
5 emulating the Serving GSM MSC/VLR.
6 h. The IIF sends an Insert Subscriber Data message to the Serving GSM MSC/VLR.
7 i. The Serving GSM MSC/VLR returns an Insert Subscriber Data Ack to the IIF.
8 j. The IIF returns a qualdir message to the HLR.
9
10
4 If CNIP / CLIP service is authorized and active, the calling party number is available and presentation
5 is allowed, the called party’s serving network shall provide the calling party number to the called party
6 during call alerting as in Figure 67 below.
MSC/
MSC HLR IIF MS
VLR
Incoming call to DN
a
LOCREQ
b
(Calling Party No)
ROUTREQ
c
(Calling Party No)
Provide Roaming No
d
(Calling Party No))
Prov Roaming No Ack
e
(MSRN)
Routreq (TLDN = MSRN)
f
Call Setup
h
(Calling Party No)
Alert
i
(Calling Party No,
PI, SI, Sub-address)
7
8
9 Figure 67: Calling number/ line identification presentation:
10 mobile station or fixed terminal to mobile station – GSM Foreign Mode
11 a. An incoming call for the called party is received at his/her home network.
12
13 b. The calling party number may be carried in the calling party number digits parameter as specified
14 in TIA/EIA-41-5-D [1].
15
16 c. The calling party number may be carried in the calling party number string parameter as specified
17 in TIA/EIA-41-5-D [1].
18
19 d. The calling party number may be carried in the additional signal information element as specified
20 in GSM 09.02 [7].
21
22 e. The VLR returns a roaming number for routing purposes.
23
24 f. The IIF maps the MSRN it receives from the VLR into the TLDN field in the routreq.
1
2 g. The HLR returns a locreq to the MSC with the routing information it received from the IIF.
3
4 h. The trunk signaling between the MSC’s may transit a number of intermediate signaling networks
5 of various capabilities. As such, there is no guarantee that the calling party number can be
6 conveyed using the ISUP/TUP signaling capabilities.
7
8 i. The MSC delivers the calling party identification during the call setup operation with the MS. The
9 calling party subaddress is passed if it is received from the originating network. The Calling Party
10 No, Presentation Indicator (PI), and Screening Indicator (SI) shall be sent in accordance with
11 GSM 03.81 [5].
12
13 Note: Where a calling party number is delivered both via MAP signaling and ISUP/TUP signaling, the
14 number delivered via MAP signaling takes precedence.
15
16 Note: When an additional calling party number is also available for presentation purposes, the
17 additional calling party number (subject to CNIP/CLIR) shall be presented in preference to any
18 other calling party number.
19
20 B.1.3.13.1 4.9.1.1.1 Interrogation
21 The subscriber can request the status of the supplementary service when operating in GSM foreign
22 mode and be informed if the service is provided to him/her.
23
2 If CNIP / CLIP service is authorized and active, the calling party number is available and presentation
3 is allowed, the called party’s serving network shall provide the calling party number to the called party
4 during call alerting as in Figure 68 below.
5
HLR MSC/
GMSC IIF MS
VLR
Incoming call to DN
a
1 h. The trunk signaling between the MSC’s may transit a number of intermediate signaling networks
2 of various capabilities. As such, there is no guarantee that the calling party number can be
3 conveyed using the ISUP/TUP signaling capabilities.
4
5 i. The mobile station receives an incoming call alert, which contains the calling party identification
6 information.
7
8 Note: Where a calling party number is delivered both via MAP signaling and ISUP/TUP signaling,
9 the number delivered via MAP signaling takes precedence.
10 B.1.3.14.1 4.9.1.2.1 Interrogation
11 The subscriber cannot request the status of the supplementary service in ANSI-41 Foreign mode.
12 4.9.2 Handling of calling number/ line identification restriction
13 B.1.3.15 4.9.2.1 General
14 If the calling subscriber has calling number/line identification restriction authorized and active and it is
15 impossible to indicate to the terminating network (due to interworking) that the number shall not be
16 presented to the terminating party, the calling number/line identity shall not be delivered to the
17 terminating network.
18 B.1.3.16 4.9.2.2 GSM Foreign Mode
19 If CNIR / CLIR service is authorized and active, the calling party number is available and presentation
20 is restricted, the called party’s serving network shall not present the calling party number to the called
21 party during call alerting. An indication that the calling party number is restricted shall be delivered to
22 the called party.
24 The subscriber can request the status of the CNIR /CLIR supplementary service and be informed if
25 the service is provided to him/her and which mode is provided, i.e. permanent or temporary and if
26 temporary, what the default value is (i.e. allowed or restricted).
28 If CNIR / CLIR service is authorized and active, the calling party number is available and presentation
29 is restricted, the called party’s serving network shall not present the calling party number to the called
30 party during call alerting. An indication that the calling party number is restricted shall be delivered to
31 the called party.
32 B.1.3.17.1 4.9.2.3.1 Interrogation
34
15 This scenario describes the successful activation of call restrictions for a native ANSI-136 41
16 subscriber roaming in a GSM network at a time when the subscriber is currently registered.
VLR/
HLR IIF MSC
QUALDIR
a
ISD Ack c
qualdir
d
17
18 Figure 69: Activation of Call Restriction - GSM Foreign Mode
19 a. Call restrictions are applied at the ANSI-41 HLR. The HLR sends an appropriate
20 QualificationDirective INVOKE message to the IIF emulating the VLR where the subscriber is
21 roaming.
22
23 b. The IIF forwards a corresponding Insert Subscriber Data message to the GSM VLR.
24
25 c. The VLR sends an Insert Subscriber Data acknowledgement to the IIF.
26
27 d. The IIF forwards a QualificationDirective RETURN RESULT message to the HLR.
28
29
2 This scenario describes the successful application of ODB or call barring for a native GSM subscriber
3 roaming in an ANSI-41 network.
VLR/
HLR IIF MSC
qualdir
c
ISD Ack
d
4
5 Figure 70: Activation of Call Barring – ANSI-41 Foreign Mode
6
7 a. ODB or call barring is applied at the GSM HLR. The HLR sends an appropriate Insert Subscriber
8 Data message to the IIF emulating the VLR where the subscriber is roaming.
9
10 b. The IIF forwards a corresponding QualificationDirective INVOKE message to the ANSI-41 VLR.
11
12 c. The VLR sends a QualificationDirective RETURN RESULT to the IIF.
13
14 d. The IIF forwards an Insert Subscriber Data acknowledgement message to the HLR.
15 4.10.2 Invocation of Barring of Incoming Calls
16 B.1.3.20 4.10.2.1 GSM Foreign Mode
17 Barring of incoming calls is performed at the ANSI-41 HLR. There is no IIF involvement.
19 Barring of incoming calls is performed at the GSM HLR. There is no IIF involvement.
20 4.10.3 Invocation of Barring of Roaming
21 Barring of Roaming is performed at the HLR. The following subsections, however, illustrate the
22 signaling at the IIF when a barred subscriber attempts to roam into a GSM or ANSI-41 Foreign
23 network.
25 This scenario describes the successful barring of roaming for a native ANSI-136 41 subscriber
26 attempting to roam into a GSM network.
MSC/
VLR IIF HLR
Update Location
a
REGNOT
b
regnot
c
UL Ack
d
1
2 Figure 71: Invocation of Barring of Roaming – GSM Foreign Mode
3
4 a. A native ANSI-136 41 subscriber with barring of Roaming active, attempts to register in a
5 GSM network. The GSM VLR sends an Update Location message to the IIF emulating the
6 subscriber’s HLR.
7
8 b. The IIF issues a RegistrationNotification INVOKE to the HLR.
9
10 c. The HLR determines that roaming is denied in this case, returns a RegistrationNotification
11 RETURN RESULT with AuthorizationDenied set to Not Authorized for the MSC. Optionally, a
12 RegistrationCancellation message may be sent to the previous Serving MSC/VLR (if
13 registration was in an ANSI-41 network) or to the IIF (if registration was in a GSM network).
14
15 d. The IIF issues an Update Location acknowledgement with User Error set to Roaming Not
16 Allowed. The VLR denies the registration attempt.
17
2 This scenario describes the successful ODB barring of roaming for a native GSM subscriber
3 attempting to roam into an ANSI-41 network.
MSC/ HLR
IIF
VLR
REGNOT
a
Update Location
b
UL Ack c
regnot
d
4
5 Figure 72: Invocation of Barring of Roaming – ANSI-41 Foreign Mode
6
7 a. A native GSM subscriber with ODB barring of Roaming active, attempts to register in an ANSI-41
8 network. The ANSI-41 VLR sends an RegistrationNotification INVOKE to the IIF emulating the
9 subscriber’s HLR.
10
11 b. The IIF issues an Update Location message to the HLR.
12
13 c. The HLR determines that roaming is denied in this case, returns an Update Location
14 acknowledgement with User Error set to Roaming Not Allowed. Optionally, a Cancel Location
15 message may be sent to the previous Serving MSC/VLR (if registration was in a GSM network) or
16 to the IIF (if registration was in an ANSI-41 network).
17
18 d. The IIF issues a RegistrationNotification RETURN RESULT with AuthorizationDenied set to Not
19 Authorized for the MSC. The VLR denies the registration attempt.
20 4.10.4 Invocation of Barring of Supplementary Services Management
21 Barring of Supplementary Services Management is performed at the HLR. The following subsections,
22 however, illustrate the signaling at the IIF when a subscriber attempts to activate a supplementary
23 service in a GSM or ANSI-41 Foreign network, while Barring of Supplementary Services Management
24 is in effect.
26 This scenario describes the successful barring of supplementary service control for a native
27 ANSI-136 41 subscriber in a GSM network.
MSC/
VLR IIF HLR
Activate SS
a
FEATREQ
b
featreq
c
Activate SS Ack
d
1
2 Figure 73: Invocation of Barring of Supplementary Service Control – GSM Foreign Mode
3
4 a. A native ANSI-136 41 subscriber attempts to activate a feature to which he is not authorized. The
5 MSC sends an Activate SS message to the IIF emulating the subscriber’s HLR.
6
7 b. The IIF issues a FeatureRequest INVOKE message to the HLR.
8
9 c. The HLR, determining that the subscriber is not authorized, sends a FeatureRequest RETURN
10 RESULT, with FeatureResult set to Unsuccessful to the IIF.
11
12 d. The IIF issues an Activate SS acknowledgement, with User Error set to SS Subscription Violation
13 to the VLR. The VLR denies the activation.
14
2 This scenario describes the successful ODB barring of supplementary services management for a
3 native GSM subscriber in an ANSI-41 network.
MSC/
VLR IIF HLR
FEATREQ a
Activate SS
b
Activate SS Ack c
featreq
d
4
5 Figure 74: Invocation of Barring of Supplementary Services Management – ANSI-41 Foreign
6 Mode
7 a. A native GSM subscriber with ODB barring of Supplementary Services Management active,
8 roaming in an ANSI-41 network, attempts to activate a supplementary service. The MSC sends a
9 FeatureRequest INVOKE to the IIF emulating the subscriber’s HLR.
10
11 b. The IIF issues an Activate SS message to the HLR.
12
13 c. The HLR, determining that ODB barring is in effect for this subscriber, sends an Activate SS
14 acknowledgement, with User Error set to SS Subscription Violation to the IIF.
15
16 d. The IIF issues a FeatureRequest RETURN RESULT, with FeatureResult set to Unsuccessful to
17 the VLR. The VLR denies the activation.
18
4 4.11.1 Assumptions
5 The following assumptions are made in the message flows:
7 • The user data received in the GSM SMS-DELIVER and GSM SMS-SUBMIT is tunneled from the
8 Short Message Entity (SME) to the Mobile Station (MS).
9 • When the MS wishes to originate a short message and is operating in foreign mode, it shall use a
10 teleservice server address which maps to the IIF. When the IIF receives this address it shall be
11 mapped to the corresponding message center.
12 • The MO SMS first goes to the originator’s Message Center (MC) and then to the recipient’s
13 Message Center.
14 Only foreign mode message flows are described. Native mode message flows are as defined for the
15 native mode technology except in 4.11.2 which addresses GHOST/WEMT-CMT interworking within
16 an ANSI-41 network. Note: CMT applies for CDMA or ANSI-136 subscriber, GHOST applies only for
17 ANSI-136 subscriber and WEMT only for CDMA subscribers.
18
19
6 B.1.3.26 4.11.2.1 Short Message from CMT Mobile Station to GHOST/WEMT Mobile
7 Station both in Native Mode
SMD-REQ (CMT)
a
SMDPP (CMT)
b
smdpp [ACK]
c
SMD-ACK
d
SMDPP (CMT)
e
smdpp [ACK]
f
SMSREQ
smsreq
SMDPP (GHOST)
g
(SMS delivered to
Mobile Station h
using GHOST)
smdpp [ACK] i
9
10 Figure 75: Short Message from a TDMA or CDMA CMT phone to a GHOST or WEMT mobile
11 station, both in native mode
12 Notes:
13 Message Center B (MC-B) is responsible for converting CMT to GHOST/WEMT.
14 MC-A and MC-B could be one and the same.
15
16
1 B.1.3.27 4.11.2.2 Short Message sent from GHOST/WEMT Mobile Station to CMT Mobile
2 Station, both in Native Mode
SMD-REQ (GHOST)
a
SMDPP (GHOST)
b
smdpp [ACK]
c
SMD-ACK
d
SMDPP (CMT)
e
smdpp [ACK]
f
SMSREQ
g
smsreq
h
SMDPP (CMT)
i
(SMS delivered to
Mobile Station j
using CMT)
smdpp [ACK]
k
4
5 Figure 76: Short Message from a GHOST or WEMT mobile station to a TDMA CMT or CDMA
6 CMT Phone, both in native mode
7 Notes:
8 Message Center A (MC-A) is responsible for converting GHOST GHOST/WEMT to CMT. This is
9 done so that only the operators using GHOST/WEMT would need to have a modified Message
10 Center. In the event that MS-B also uses GHOST/WEMT and that MC-A is not the same as MC-B,
11 then MC-B would have to re-convert from CMT to GHOST/WEMT, unless there is some way for MC-
12 A to know that MS-B also uses GHOST/WEMT.
13 In the event that MC-A and MC-B are one and the same, and that MS-B also uses GHOST/WEMT,
14 then no conversion is needed.
15
16
SMS
Delivery
a
SMSREQUEST
b
smsrequest
c
SMDPP (CMT)
d
FORWARD SHORT MESSAGE
e
SMS Delivery
f
SMS Delivery Ack
g
Forward Short Message
h
smdpp [ACK]
i
1
TDMA TDMA GSM
MC HLR IIF MSC/ MS
VLR
SMS
Delivery
a
SMSREQUEST
b
smsrequest
c
SMDPP (CMT)
d
FORWARD SHORT MESSAGE
e
SMS Delivery
f
SMS Delivery Ack
g
Forward Short Message
h
smdpp [ACK]
i
2
3 Figure 77: Successful Mobile Terminating ANSI-136 41 SMS (CMT) mapped to GSM SMS
4
5 a. The ANSI-136 41 Message Center (MC) receives a short message for a specific subscriber.
6 Note: This step is shown for completeness only and is not repeated in subsequent call flows.
7
8 b. The Message Center sends an SMS Request message to the ANSI-41 HLR of the short
9 message recipient to request a routing address for delivering the short message to that
10 subscriber.
11
1 c. Since the subscriber has a current valid location stored in the HLR, the HLR returns it to the MC
2 in the SMS Request Return Result message.
3
4 d. The Message Center then sends a Short Message Delivery Point to Point message to the IIF,
5 which is seen as the current serving ANSI-41 MSC/VLR for that subscriber. Note that in this
6 case, the format used by the MC is the CMT format (Cellular Messaging Transport). Note that
7 alternatively, the ANSI-136 41 MC could translate the original CMT SMS to GHOST or WEMT
8 format before sending it to the IIF if the IIF only supports the GHOST format. In this case the IIF
9 would convert ANSI-136 TDMA GHOST or CDMA WEMT into GSM format (see Section
10 4.11.3.2) instead of ANSI-136 41 CMT into GSM format.
11 e. Upon reception of the Short Message Delivery Point to Point message from the ANSI-136 41
12 MC, the IIF originates a FORWARD SHORT MESSAGE to the serving GSM MSC/VLR after
13 having translated the short message into GSM format. The IIF is then acting as a GSM SMS-
14 GMSC.
15
16 f. The serving GSM MSC/VLR sends the short message to the mobile station. Note: This step is
17 shown for completeness only and is not repeated in subsequent call flows.
18
19 g. The mobile station acknowledges the delivery of the short message. Note: This step is shown
20 for completeness only and is not repeated in subsequent call flows.
21
22 h. The serving GSM MSC/VLR sends the result of the Forward Short Message to the IIF.
23
24 i. The IIF sends the result of the Short Message Delivery Point to Point to the ANSI-136 41
25 Message Center.
28
29
ANSI-41 GSM
SMSREQ
a
smsreq
b
SMDPP
c
FORWARD SHORT MESSAGE
d
Forward Short Message
e
smdpp [ACK]
f
1 Figure 78: Successful Mobile Terminating ANSI-136 41 SMS (GHOST/WEMT) mapped to GSM
2 SMS
3 a. The ANSI-41 MC sends a SMSRequest Invoke message to the HLR, including as arguments the
4 MIN (MSISDN) of the mobile station and SMS Notification Indicator.
5 b. The HLR determines if the message shall be forwarded to the MS and sends a response back in
6 a SMSRequest Return Result, with the SMS_Address set to the IIF address (point code or E.164
7 address).
8 c. The MC formats a GHOST/WEMT teleservice and sends it to the IIF in an SMDPP message.
9 d. Upon receipt of the SMDPP message, the IIF builds a FORWARD SHORT MESSAGE, stripping
10 off the GHOST/WEMT teleservice and using the encapsulated GSM SMS transfer PDU, and
11 routes it to the VMSC.
12 e. The VMSC packages the GSM SMS RP-DATA into a CP-DATA message and delivers it across
13 the GSM air interface to the mobile station. The mobile station acknowledges receipt of the CP-
14 DATA and RP-DATA messages via CP-ACK and CP-ACK[RP-ACK], respectively. Upon
15 successful receipt of the RP-ACK, the VMSC shall send a positive acknowledgement Forward
16 Short Message back to the IIF.
17 f. The IIF maps the received Forward Short Message into a SMDPP Return Result and sends it to
18 the MC.
2 The following scenario applies to short message delivery failure in either CMT or GHOST/WEMT
ANSI-41 GSM
SMSREQ
a
smsreq
b
SMDPP
c
FORWARD SHORT MESSAGE
d
Forward Short Message
e
smdpp [NAK]
f
3 format.
4 Figure 79: Unsuccessful Mobile Terminated Delivery (Failure at MSC)
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 VMSC. 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 VMSC 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 VMSC 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 VMSC; that is, the Mobile
24 Subscriber Not Reachable Flag (MNRF) shall be set if the error cause is “absent subscriber”, and
25 the Memory Capacity Exceeded Flag (MCEF) shall be set if the error cause is “memory capacity
26 exceeded”. Additionally, the IIF emulating the ANSI-41 MSC shall set and store the SMS
27 Delivery Pending flag with the MC parameters received in the SMDPP (for later delivery in the
1 SMSNOT) – note that this “SMS Delivery Pending” flag/data serves the same purpose as a GSM
2 HLR’s “Message Waiting Data” flag/data. [However, note that if an ANSI-41 REGCAN is received
3 from the ANSI-41 HLR before the SMS Delivery Pending Flag is cleared, then the regcanc
4 response shall contain the SMS_MessageWaitingIndicator, and all flags are cleared (i.e., MNRF,
5 MCEF, and SMS Delivery Pending Flag)].
6
7
2 The following scenario applies to short message delivery failure in either CMT or GHOST/WEMT
3 format.
4
ANSI-41 GSM
SMSREQ
a
smsreq
b
SMDPP
c
smdpp [NAK]
d
2 The following scenario applies to short messages originated in either CMT or GHOST/WEMT format.
ANSI-41 GSM
READY FOR SM
a
Ready fro SM
b
SMSNOT
c
smsnot
d
3
4 Figure 81: Alerting for an ANSI-136 41 Subscriber in GSM Foreign Mode
5
6 a. The VMSC sends a READY FOR SM (MAP V2) to the IIF, including as arguments the IMSI and
7 Alert Reason. Note: The SMS notification can also be triggered when the VMSC sends a
8 NoteMSPresent (MAP V1) or an UpdateLocation.
9 b. If the IIF has GSM 03.40 flags set, then these flags shall be cleared according to the “alert
10 reason”; that is, if the “alert reason” is “memory available”, then both the MCEF and MNRF flags
11 are cleared, and if the “alert reason” is “MS present”, then the MNRF flag is cleared. If the
12 UpdateLocation is received, then the MNRF flag is cleared. The IIF sends a Ready for SM
13 response to the VMSC with no arguments.
14 c. If the IIF has the SMS Delivery Pending Flag set, and if the MCEF flag is not set, then the IIF
15 sends a SMSNOT to each of the subscriber’s MCs stored with the SMS Delivery Pending Flag.
16 The SMSNOT shall contain; the MIN (MSISDN) as mapped from the IMSI, ESN, and
17 SMS_Address containing the IIF address.
18 d. The MC sends a SMSNOT Return Result to the IIF, then the IIF clears the SMS Delivery Pending
19 Flag, then proceeds to send the mobile station a mobile terminated GHOST/WEMT teleservice
20 message according to 4.11.3.2.
21
22 4.11.4 Mobile Terminated SMS in ANSI-41 Foreign Mode
23 This section describes the message flows for delivering a CMT or GHOST/WEMT teleservice when
24 the mobile station is operating in ANSI-41 Foreign Mode. Since on the TDMA ANSI-41 side, the short
25 message may need to be in CMT or GHOST/WEMT format, the IIF has to convert the GSM SMS to
26 either CMT or GHOST/WEMT.
27
GSM ANSI-41
SMS
Delivery
a
(SMS delivered to f
Mobile Station)
smdpp [CMT]
g
Forward Short Message
h
1 g. The serving ANSI-41 MSC/VLR sends the result of the Short Message Delivery Point to Point
2 message to the IIF.
3
4 h. The IIF sends the result of the Forward Short Message to the GSM SMS-GMSC.
5
6
2 This method uses the tunneling concept. Instead of translating the GSM SMS to an ANSI-136 41
3 CMT SMS format, the IIF shall package the GSM SMS into an ANSI-136TDMA SMS with the
4 teleservice GHOST (GSM Hosted SMS Teleservice) or CDMA SMS with teleservice WEMT..
5
6
GSM ANSI-41
18 Upon receipt of the FORWARD SHORT MESSAGE, the IIF shall build an ANSI-41 SMDPP ,
19 encapsulating the GSM SMS transfer PDU in the GHOST/WEMT teleservice. The IIF shall route
20 the SMDPP message to the serving MSC. The serving MSC maps the SMDPP message into an
21 R-DATA message and sends it to the mobile station over the TDMA or CDMAANSI-136 air
1 interface. The mobile station shall acknowledge receipt of the R-DATA message and
2 GHOST/WEMT teleservice by sending an R-DATA ACCEPT message to the MSC.
3
4 d. After receiving the R-DATA ACCEPT message, the serving MSC sends a positive
5 acknowledgement SMDPP Return Result to the IIF.
6 e. The IIF maps the received SMDPP Return Result to a Forward Short Message, and sends it to
7 the GSM SMSC.
8 f. The SMSC send a REPORT SM DELIVERY STATUS to the HLR, including as arguments the
9 MSISDN, SMSC Address, and Successful Transfer. The SMSC sends this message based on
10 the procedures described in GSM 03.40 [4] and GSM 09.02 [6].
11 g. The HLR shall set the appropriate flags as specified in the GSM specifications (GSM 09.02 and
12 03.40), then send a Report SM Delivery Status to the SMSC.
13 B.1.3.35 4.11.4.3 Unsuccessful GSM SMS mapped to ANSI-136 41 SMS (Failure at MS)
14 The following scenario applies to short messages delivered in either CMT or GHOST/WEMT format.
GSM ANSI-41
15 Figure 84: Successful GSM SMS mapped to ANSI-136 41 SMS (Failure at MS)
16
17 a. The SMSC receives a request to deliver a short message to a GSM subscriber. It sends to the
18 GSM HLR a SEND ROUTING INFO FOR SM, including as arguments the MSISDN, Priority, and
19 Service Center address.
20 b. The HLR determines if the message shall be forwarded to the MS and sends a response back to
21 the SMSC in a Send Routing Info for SM, including as arguments the IMSI of the MS and
22 Network Node Number of the IIF.
1 c. The SMSC originates a FORWARD SHORT MESSAGE to the address provided by the HLR (i.e.,
2 IIF), including as arguments the IMSI, Service Center Address, and GSM SMS-DELIVER PDU
3 (and optionally if more messages are to be sent).
4 d. Upon receipt of the FORWARD SHORT MESSAGE, the IIF builds an ANSI-41 SMDPP message,
5 encapsulating the GSM SMS transfer PDU in a GHOST/WEMT teleservice, and routes it to the
6 serving MSC. The IIF can also convert the message into ANSI-136 41 CMT format. The serving
7 MSC converts the SMDPP message into an R-DATA message and sends it to the mobile station
8 over the ANSI-136TDMA or CDMA air interface. The mobile station returns an R-DATA REJECT
9 message to the MSC, indicating an error in the receipt of the message.
10 e. Upon receipt of the R-DATA REJECT, the serving MSC maps the ANSI-136 41 R-Cause code to
11 the appropriate ANSI-41 SMS_CauseCode value, and sends a negative acknowledgement
12 SMDPP Return Result back to the IIF.
13 f. The IIF sets the SMS Delivery Pending Flag in the IIF and maps the received SMDPP Return
14 Result into a Forward Short Message and sends it to the SMSC, after mapping the
15 SMS_CauseCode to the appropriate GSM MAP error.
16 g. The SMSC sends a REPORT SM DELIVERY STATUS to the HLR, including as arguments the
17 MSISDN, SMSC Address, and Error Cause. The SMSC sends this message based on the
18 procedures described in GSM 03.40 [4] and GSM 09.02 [6].
19 h. The HLR shall set the appropriate flags as specified in the GSM specifications (GSM 09.02 and
20 03.40), then send a Report SM Delivery Status to the SMSC.
22 The following scenario applies to short messages delivered in either CMT or GHOST/WEMT format.
23
24
GSM ANSI-41
1 h. The HLR shall set the appropriate flags as specified in the GSM specifications (GSM 09.02 and
2 03.40), then send a Report SM Delivery Status to the SMSC.
3
GSM ANSI-41
7 b. The HLR determines if the message shall be forwarded to the MS and sends a response back to
8 the SMSC in a Send Routing Info for SM, including as arguments the IMSI of the MS and Network
9 Node Number of the IIF.
10 c. The SMSC originates a FORWARD SHORT MESSAGE to the address provided by the HLR (i.e.,
11 IIF), including as arguments the IMSI, Service Centre Address, and GSM SMS-DELIVER PDU
12 (and optionally if more messages are to be sent).
13 d. Upon receipt of the FORWARD SHORT MESSAGE at the IIF, if the subscriber is known to be
14 unavailable or the SMS Waiting Indicator flag is set, then the IIF builds a Forward Short Message
15 and send it back to the SMSC.
16 e. The SMSC sends a REPORT SM DELIVERY STATUS to the HLR, including as arguments the
17 MSISDN, SMSC Address, and Error Cause.
18 f. The HLR shall set the appropriate flags as specified in the GSM specifications (GSM 09.02 and
19 03.40) and sends a Report SM Delivery Status to the SMSC. The SMSC sends this message
20 based on the procedures described in GSM 03.40 [4] and GSM 09.02 [6].
22 In the event that the delivery of the short message to the ANSI-41 network is not possible, the IIF
23 shall be notified by the serving ANSI-41 MSC/VLR when the subscriber is available again. This shall
24 be done by receiving a Registration Notification or an SMS Notification message. This is illustrated in
1 the following diagram. The following scenario applies to short messages delivered in either CMT or
2 GHOST/WEMT format.
GSM ANSI-41
SMSNOT or REGNOT
a
READY FOR SM
b
Ready for SM
c
smsnot or regnot
d
3
4 Figure 87: Alerting for a GSM Subscriber in ANSI-41 Foreign Mode
5 a. The IIF receives either (1) an SMSNOT, or (2) a REGNOT when the ANSI-41 SMS Delivery
6 Pending Flag is set at the IIF or the SMS_Address parameter is present in the REGNOT.
7 b. The IIF alerts the GSM HLR by sending a READY FOR SM including as arguments the IMSI and
8 MS-Present.
9 c. The HLR shall send a Ready for SM to the IIF. If the SMS Waiting Indicator flag is set in the IIF,
10 then it is cleared.
11 d. The IIF returns a Return Result acknowledgement message.
12 e. The HLR originates an ALERT SERVICE CENTRE to the SMSC address stored in the HLR,
13 including as arguments the MSISDN, and SMSC Address.
14 f. The SMSC sends an Alert Service Centre to the HLR, then proceeds to send the mobile station a
15 mobile terminated GSM SMS message according to 4.11.4.2.
16
1
2 4.11.5 Message Flows for Mobile Originated SMS in GSM Foreign Mode
3 This section describes the message flows for originating a short message to the subscriber’s home
4 message center when the mobile station is operating in GSM Foreign Mode. The following scenarios
5 apply to short messages delivered to the MC in either CMT or GHOST/WEMT format.
GSM ANSI-41
SMDPP
b
smdpp [ACK]
c
Forward Short Message
d
18
GSM ANSI-41
SMDPP
b
smdpp [NAK]
c
Forward Short Message
d
GSM ANSI-41
2
3 Figure 90: Unsuccessful Mobile Originated (Failure at IIF)
4
5 a. The VMSC originates a FORWARD SHORT MESSAGE to the address provided by the MS (i.e.,
6 IIF), including as arguments the Service Centre Address, MSISDN and GSM SMS-SUBMIT PDU.
7 b. Upon receipt of the FORWARD SHORT MESSAGE, the IIF builds a negative acknowledgement
8 Forward Short Message and sends it to the VMSC.
9
10 4.11.6 Message Flows for Mobile Originated SMS in ANSI-41 Foreign Mode
11 This section describes the message flows for originating a short message to the subscriber’s home
12 message center when the mobile station is operating in ANSI-41 Foreign Mode. The following
13 scenarios apply to short messages originated in either CMT or GHOST/WEMT format.
14
ANSI-41 GSM
SMDPP
a
ANSI-41 GSM
SMDPP
a
2 Figure 92: Successful Mobile Originated (Failure at SMSC) – 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 FORWARD SHORT MESSAGE, stripping
9 off the GHOST GHOST/WEMT teleservice and using the encapsulated GSM SMS transfer PDU,
10 and routes it to the SMSC.
11 c. The SMSC sends a negative acknowledgement Forward Short Message to the IIF.
12 d. The IIF maps the received Forward Short Message into a SMDPP Return Result and sends it to
13 the VMSC.
14
ANSI-41 GSM
SMDPP
a
smdpp [NAK]
b
3 Figure 93: Unsuccessful Mobile Originated (Failure at IIF) – ANSI-41 Foreign Mode
4
5 a. The VMSC originates a SMDPP invoke to the address provided by the MS (i.e., IIF), including as
6 arguments the Teleservice Server Address, MIN (MSISDN) and GSM SMS-SUBMIT PDU
7 encapsulated in the GHOST/WEMT teleservice. The mobile originated message can also be in
8 the CMT format.
9 b. Upon receipt of the SMDPP message, the IIF builds a negative acknowledgement SMDPP
10 Return Result and sends it to the VMSC.
11
3
4 ANSI- GSM MS
VMS IIF
41 MSC/VLR
5
Vmail
6
Delivery
a
7 “Message Waiting
Notification”
8 b
9
Update Loc Req c
10 UPDATE
11 LOCATION
d
12 REGNOT
13 e
regnot (MWNCOUNT,
14 MWNTYPE)
15 f
①
16 INSERT_SUB_DATA
g
17
Insert_sub_data
18 h
19 update location
i
20
21 Update Loc Accept
FORW.SHORT j
22 MESSAGE (MWN)
23 k
1 d. The Update Location is sent from the serving GSM MSC/VLR to the IIF, seen as the GSM HLR
2 for that subscriber.
3
4 e. The IIF sends a Registration Notification to the ANSI-41 HLR of the subscriber.
5
6 f. The ANSI-41 HLR replies with the Registration Notification Return Result containing the
7 “Message Waiting Notification” information that consists of two parameters:
8 MessageWaitingNotificationCount (MWNCOUNT) and MessageWaitingNotificationType
9 (MWNTYPE). For a description of these parameters, see the ANSI-41 specifications, sections
10 6.5.2.78 and 6.5.2.79 [1].
11
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 g. The IIF sends Insert Subscriber Data to the serving GSM MSC/VLR. Note that there could be
16 more than one Insert Subscriber Data message depending on the subscriber profile.
17
18 h. The serving GSM MSC/VLR returns the Insert Subscriber Data result. Note that there could be
19 more than one such result message, one matching every Insert Subscriber Data message.
20
21 i. The IIF completes the location update by sending the Update Location result message to the
22 serving GSM MSC/VLR.
23
24 j. The serving GSM MSC/VLR confirms the update location to the mobile station.
25
26 k. Since the REGNOT return result from event f contained the Message Waiting Notification
27 information, this triggers the IIF to originate an SMS with MWN information by sending Forward
28 Short Message to the serving GSM MSC/VLR. The IIF is then acting as a GSM SMS-GMSC. The
29 IIF is to encode the MWN information in the SMS with three methods, namely, UDH, DCS, and
30 CPHS. See to Volume 3 for the encoding details.
31
32 l. The serving GSM MSC/VLR sends the short message with the MWN information to the mobile
33 station.
34
35 m. The mobile station acknowledges the delivery of the short message.
36
37 n. The serving GSM MSC/VLR sends the result of the Forward Short Message to the IIF.
38
39 ➁At this point, the IIF clears the MWN flag. The reception of the Forward Short Message Result
40 without error indicates that the MWN information was delivered successfully to the Mobile Station.
41
2
3 ANSI-41
4 VMS ANSI- GSM
IIF MS
41 MSC/VLR
5
Vmail
6 Delivery
a
7 “Message Waiting
8 Notification”
b
9 QUALDIR (MWNCOUNT,
MWNTYPE)
10 c
qualdir ①
11
d
12 FORW.SHORT
13 MESSAGE (MWN)
e
14
SMS Delivery (MWN) f
15
16 SMS Delivery Ack g
17 Forw.Short
Message
18 h
19 ②
20
21 Figure 95: ANSI-41 Qualification Directive mapped to GSM SMS
22 a. The Voice Mail System (VMS) receives a voice mail for a specific subscriber.
23
24 b. The VMS send the “Message Waiting Notification” (MWN) to the ANSI-41 HLR of the voice mail
25 recipient. Note that the interface between the VMS and the ANSI-41 HLR is not standardized in
26 ANSI-41 [1].
27
28 c. Since the subscriber has a current valid location stored in the HLR, the HLR initiates a
29 Qualification Directive message with the MWN information to the IIF acting as the serving ANSI-
30 41 MSC/VLR. The MWN information consists of two parameters:
31 MessageWaitingNotificationCount (MWNCOUNT) and MessageWaitingNotificationType
32 (MWNTYPE). For a description of these parameters, see to the ANSI-41-D specifications,
33 sections 6.5.2.78 and 6.5.2.79 [1].
34
35 ① At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification
36 is to be delivered to the Mobile Station.
37
38 d. The IIF sends the result of the Qualification Directive message to the ANSI-41 HLR.
39
40 e. The IIF also originates an SMS with MWN information by sending a Forward Short Message to
41 the serving GSM MSC/VLR. The IIF is then acting as a GSM SMS-GMSC. The IIF is to encode
42 the MWN information in the SMS with three methods, namely, UDH, DCS, and CPHS. See to
43 Volume 3 for the encoding details.
44
1 f. The serving GSM MSC/VLR sends the short message with the MWN information to the mobile
2 station.
3
4 g. The mobile station acknowledges the delivery of the short message.
5
6 h. The serving GSM MSC/VLR sends the result of the Forward Short Message to the IIF.
7
8 ➁At this point, the IIF clears the MWN flag. The reception of the Forward Short Message Result
9 without error indicates that the MWN information was delivered successfully to the Mobile Station.
10 B.1.3.47 4.12.1.3 Handling when GSM MSC/VLR only supports GSM Phase 1 (MAP V1)
11 After the IIF has received a Qualification Directive message with MWN information or received the
12 MWN information through a Registration Notification Return Result, a Forward Short Message with
13 MWN information needs to be sent to the serving GSM MSC/VLR. This was shown in Sections
14 4.12.1.1 and 4.12.1.2. However, it is possible that the serving GSM MSC/VLR does not support the
15 MAP V2 Application Context. In this case, the IIF shall receive an ABORT message and shall re-send
16 the Forward Short Message with MWN information using MAP V1 instead of MAP V2. This is
17 illustrated in the following diagram.
18
GSM
19 IIF MSC/ MS
20 VLR
21 MWN “Information”
a
22 ① FORW.SHORT
MSG (MWN) – V2
23 b
24 ABORT
cc
25 FORW.SHORT
MSG (MWN) – V1
26 d
27
SMS Delivery (MWN)
28 e
33
34
35
36 Figure 96: Handling when GSM MSC/VLR only supports GSM Phase 1 (MAP V1)
37 a. The IIF receives Message Waiting Notification (MWN) information from a Qualification Directive
38 or a Registration Notification Return Result. This was described in Sections 4.12.1.1 and
39 4.12.1.2.
40 ➀At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification
41 is to be delivered to the Mobile Station.
42
1 b. The IIF originates an SMS with MWN information by sending Forward Short Message using MAP
2 V2 to the serving GSM MSC/VLR. The IIF is then acting as a GSM SMS-GMSC. The IIF is to
3 encode the MWN information in the SMS with three methods, namely, UDH, DCS, and CPHS.
4
5 c. Since the serving GSM MSC/VLR does not support the MAP V2 Application Context, it returns an
6 Abort message to the IIF.
7
8 d. The IIF then re-sends a Forward Short Message with MWN information to the serving GSM
9 MSC/VLR, but this time using MAP V1. In this case, the MWN information can be encoded with
10 only two encoding methods, namely, DCS and CPHS.
11
12 e. The serving GSM MSC/VLR sends the short message with the MWN information to the mobile
13 station.
14
15 f. The mobile station acknowledges the delivery of the short message.
16
17 g. The serving GSM MSC/VLR sends the result of the Forward Short Message to the IIF.
18
19 ➁At this point, the IIF clears the MWN flag. The reception of the Forward Short Message Result
20 without error indicates that the MWN information was delivered successfully to the Mobile Station.
22 This section describes the case where the error occurs at the IIF, for example, an unrecognized
23 Mobile Identity Number (MIN).
24
25 ANSI-
VMS IIF
41
26
27 Vmail Delivery
a
28 “Message Waiting
Notification”
29 b
QUALDIR (MWNCOUNT),
30 MWNTYPE) cc
31
Qualdir Return Error
32
33
34 Figure 97: Handling at SMS delivery failure at the IIF
35 a. The Voice Mail System (VMS) receives a voice mail for a specific subscriber.
36
37 b. The VMS send the “Message Waiting Notification” (MWN) to the ANSI-41 HLR of the voice mail
38 recipient. Note that the interface between the VMS and the ANSI-41 HLR is not standardized in
39 ANSI-41 [1].
40
41 c. Since the subscriber has a current valid location stored in the HLR, the HLR initiates a
42 Qualification Directive message with the MWN information to the IIF acting as the serving ANSI-
43 41 MSC/VLR. The MWN information consists of two parameters:
44 MessageWaitingNotificationCount (MWNCOUNT) and MessageWaitingNotificationType
45 (MWNTYPE). For a description of these parameters, see to the ANSI-41-D specifications,
46 sections 6.5.2.78 and 6.5.2.79 [1].
1
2 d. An error is encountered so that the IIF cannot process the Qualification Directive message and
3 sends a Return Error message to the ANSI-41 HLR with the proper error code as per ANSI-41
4 Specifications, Chapter 6, Section 4.32.2, Table 42 [1].
5
1 B.1.3.49 4.12.1.5 Handling at SMS delivery failure at the MSC/VLR or at the Mobile
2 Station
3 The IIF is to keep a Message Waiting Notification (MWN) flag for each subscriber in its database. In
4 the event of a failure to deliver a short message with MWN to the mobile station, the IIF is to keep the
5 MWN flag set. Another Forward Short Message with MWN information shall be sent, triggered by the
6 reception of a subsequent GSM Update Location message, a Ready for Short Message, or a Note
7 MS Present message. This is illustrated in the following diagram.
8
9 GSM
IIF MSC/ MS
10 VLR
11 MWN “Information”
a
12
① FORW.SHORT
13 MSG (MWN) – V2
b
14
SMS Delivery (MWN)
15 cc
1 ➀At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification
2 is to be delivered to the Mobile Station.
3
4 b. The IIF originates an SMS with MWN information by sending Forward Short Message using MAP
5 V2 to the serving GSM MSC/VLR. The IIF is then acting as a GSM SMS-GMSC. The IIF is to
6 encode the MWN information in the SMS with three methods, namely, UDH, DCS, and CPHS.
7 See to Volume 3 for the encoding details.
8
9 c. The serving GSM MSC/VLR may attempt to deliver the short message or may immediately find
10 out that there is an error and reply (step e below) to the IIF.
11
12 d. The Mobile Station returns an error message to the SMS delivery.
13
14 e. The serving GSM MSC/VLR sends an Error, Abort or Reject message to the IIF, either resulting
15 from the reception of an error message from the MS or from an internal event such as an error or
16 a timeout. Note also, that a timeout may also occur in the IIF itself. Note that this may result in
17 the IIF setting the GSM 03.40 MNRF/MCEF flag depending on the error cause received (see
18 section 4.11.3.3 “Unsuccessful Mobile Terminated Delivery (Failure at MSC)”.
19
20 f. Time elapsed.
21
22 g. A new serving GSM MSC/VLR sends an Update Location message to the IIF acting as a GSM
23 HLR for that subscriber. Note that the normal Update Location sequence is not shown in this
24 diagram. Or it could be a
25
26 h. Ready for Short Message (MAP V2) or a
27
28 i. Note MS Present Message (MAP V1)
29
30 j. The IIF shall reply with the corresponding acknowledgement message. Note that in the case of
31 the Note MS Present message, there shall be no acknowledgement. Upon receipt of g, h, or i
32 above, the procedures in section 4.11.3.5 “Alerting for an ANSI-136 41 Subscriber in GSM
33 Foreign Mode” apply (GSM 03.40 flags may be cleared and the SMSNOT may be sent to the MC
34 if appropriate).
35
36 k. Triggered by event g, h, or i above, the IIF originates a new Forward Short Message with MWN
37 information to the serving GSM MSC/VLR. The IIF is to encode the MWN information in the SMS
38 with three methods, namely, UDH, DCS, and CPHS. See to Volume 3 for the encoding details.
39
40 l. The serving GSM MSC/VLR sends the short message with the MWN information to the mobile
41 station.
42
43 m. The mobile station acknowledges the delivery of the short message.
44
45 n. The serving GSM MSC/VLR sends the result of the Forward Short Message to the IIF.
46 ➁At this point, the IIF clears the MWN flag. The reception of the Forward Short Message Result
47 without error indicates that the MWN information was delivered successfully to the Mobile Station.
48 4.12.2 ANSI-41 Foreign Mode
49 For the native GSM subscribers roaming in ANSI-41 networks, there are two implementation options.
50 The GSM SMS containing the Message Waiting Notification information is either converted by the IIF
51 to a ANSI-41 Qualification Directive with Message Waiting Notification information as shown in
52 Section 4.12.2.1, or converted to a GHOST or WEMT ANSI-136 41 short message as shown in
53 Section 4.12.2.2.
54
Vmail
Delivery
a
FORW. MOBILE
TERM SM (MWN)
b
SEND ROUTING
INFO FOR SM (MWN)
c
Send Routing
Info for SM
d
FORW. SHORT
MESSAGE (MWN)
QUALDIR(MWNCOUNT, e
① MWNTYPE)
f
(MWN delivered to
Mobile Station) g
Qualdir
h
Forw. Short Message (error: absent sub.)
Forw. Mobile
i
Term SM (error)
j
Report SM (error)
DeliveryStatus
k
1
GSM GSM GSM TDMA
SC SMS- HLR IIF MSC
GMSC
Vmail
Delivery
a
FORW. MOBILE
TERM SM (MWN)
b
SEND ROUTING
INFO FOR SM (MWN)
c
Send Routing
Info for SM
d
FORW. SHORT
MESSAGE (MWN) e
QUALDIR(MWNCOUNT,
① MWNTYPE)
f
(MWN delivered to
Mobile Station) g
Qualdir
h
Forw. Short Message (error: absent sub.)
i
Forw. Mobile
Term SM (error)
j
Report SM (error)
DeliveryStatus
k
2
3 Figure 99: GSM SMS mapped to ANSI-41 Qualification Directive
4 a. The GSM Service Center (SC) receives a voice mail for a specific subscriber.
5
1 b. The SC sends the Forward Mobile Terminating Short Message with Message Waiting Notification
2 (MWN) information 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.
9
10 e. The GSM SMS-GMSC originates an SMS with MWN information by sending Forward Short
11 Message to IIF then acting as a serving GSM MSC/VLR. This requires GSM MAP phase 2 or
12 higher.
13
14 ➀At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification
15 is to be delivered to the Mobile Station. If the GSM SMS-GMSC only supports GSM MAP phase 1
16 and delivers MWN via pure text SMS, then a pure text SMS shall be delivered to the IIF. The IIF
17 shall then translate it into a CMT or GHOST/WEMT IS-136 SMS. Note that this then becomes a
18 simple SMS mapping covered in Section 4.12.2.2.
19
20 f. Upon reception of the Forward Short Message with MWN information, the IIF shall initiate a
21 Qualification Directive message with MWN information to the serving ANSI-41 MSC/VLR. The IIF
22 is then acting as an ANSI-41 HLR. The MWN information consists of two parameters:
23 MessageWaitingNotificationCount (MWNCOUNT) and MessageWaitingNotificationType
24 (MWNTYPE). For a description of these parameters, see to the ANSI-41-D specifications
25 sections 6.5.2.78 and 6.5.2.79 [1]. Alternatively, a GHOST/WEMT short message could be sent
26 instead of the Qualification Directive message (see Section 4.12.2.2) if the IIF has the possibility
27 to confirm that the Mobile Station is SMS-capable.
28
29 g. In this step, the MWN information shall be delivered to the mobile station.
30
31 h. The serving ANSI-41 MSC/VLR sends the Qualification Directive Return Result to the IIF. Note
32 that this result message does not guaranty that the MWN information was delivered successfully
33 to the Mobile Station, it just means that the MSC/VLR received the Qualification Directive
34 message, therefore the MWN flag shall not be cleared at this point by the IIF.
35
36 i. The IIF sends the result of the Forward Short Message to the GSM SMS-GMSC with error code
37 “absent subscriber” so that the home system assumes that the delivery failed in case the
38 subscriber goes back to the home system without having retrieved the mail messages. This way,
39 at the reception of the Update Location message, the HLR shall send an Alert-SC message so
40 that the MWN information (in a short message) is once again sent to the Mobile Station.
41
42 j. The SMS-GMSC sends the result of the Forward Mobile Terminating Short Message to the
43 Service Center. Note that depending on the Service Center implementation, this may cause the
44 SMS to be re-sent periodically instead of waiting for the ALERTSC message indicating that the
45 subscriber is again available to receive short messages.
46
47 k. The SMS-GMSC reports the error to the HLR, which shall set the proper flags as per GSM 03.40
48 [4] so that an Alert-SC message is sent when necessary as explained in step i above.
49 B.1.3.51 4.12.2.2 GSM SMS mapped to TDMA ANSI-41 SMS using GHOST or WEMT
50 Teleservice
51 This method uses the tunneling concept. Instead of translating the GSM SMS with Message Waiting
52 Notification information to an ANSI-41 Qualification Directive with MWN information, the IIF shall
53 package the GSM SMS into an ANSI-136 41 SMS with the new teleservice GHOST (GSM Hosted
54 SMS Teleservice) or WEMT.
1 Event g only works with Mobile Stations (MS) capable of handling GHOST or WEMT. The MS shall
2 remove the ANSI-136 41 part of the message (the envelope) and send the GSM SMS Packet Data
3 Units (PDU) to the GSM part of the mobile station to handle the GSM SMS, in this case, containing
4 the Message Waiting Notification information. Specifically, the ANSI-41 MSC shall convert the
5 SMDPP to an R-DATA message which has a HLPI (higher layer protocol identifier) that indicates
6 GHOST/WEMT. The payload of the R-DATA message is the GSM SMS which is effectively identified
7 as the target application whenever HLPI = GHOST/WEMT.
Vmail
Delivery
a
FORW.
TERM SM b
SEND
INFO FOR SM
c
Send
Info for SM d
FORW.
MESSAGE
e
SMDPP (MWN)
f
(SMS delivered
Mobile Station)
g
smdpp
h
Forw. Short Message
i
Forw. Mobile
Term SM
j
1
GSM GSM GSM TDMA
SC SMS- HLR IIF MSC
GMSC
Vmail
Delivery
a
FORW. MOBILE
TERM SM (MWN) b
SEND ROUTING
INFO FOR SM (MWN)
c
Send Routing
Info for SM d
FORW. SHORT
MESSAGE (MWN)
e
SMDPP (GHOST, MWN)
f
(SMS delivered to
Mobile Station)
g
smdpp (GHOST)
h
Forw. Short Message
i
Forw. Mobile
Term SM
j
2
3 Figure 100: GSM SMS mapped to TDMA ANSI-41 using GHOST/WEMT Teleservice
1 a. The GSM Service Center (SC) receives a voice mail for a specific subscriber.
2
3 b. The SC sends the Forward Mobile Terminating Short Message with Message Waiting Notification
4 (MWN) information to the GSM SMS-GMSC.
5
6 c. The GSM SMS-GMSC inquires about the subscriber location by sending the Send Routing
7 Information For Short Message to the HLR.
8
9 d. The HLR replies with the Send Routing Information For Short Message result. It is assumed that
10 the native GSM subscriber has already made a registration in the ANSI-41 MSC/VLR.
11
12 e. The GSM SMS-GMSC originates an SMS with MWN information by sending Forward Short
13 Message to IIF then acting as a serving GSM MSC/VLR.
14
15 This requires GSM MAP phase 2 or higher. If the GSM SMS-GMSC only supports GSM MAP
16 phase 1 and delivers MWN via pure text SMS, then a pure text SMS shall be delivered to the IIF.
17 The IIF shall then translate it into a CMT or GHOST/WEMT IS-136ANSI-41 SMS. Note that this
18 then becomes a simple SMS mapping covered in Section 4.11.
19
20 f. Upon reception of the Forward Short Message with MWN information, the IIF shall initiate a Short
21 Message Delivery Point to Point with Teleservice GHOST/WEMT to the serving ANSI-41
22 MSC/VLR. The IIF is then acting as an ANSI-136 41 Message Center (MC). Inside of this
23 GHOST/WEMT short message is the GSM short message containing the MWN information.
24
25 g. In this step, the GHOST/WEMT Short Message containing the GSM short message containing
26 the MWN information shall be delivered to the mobile station.
27
28 h. The serving ANSI-41 MSC/VLR sends the Short Message Delivery Point to Point Return Result
29 to the IIF.
30
31 i. The IIF sends the result of the Forward Short Message to the GSM SMS-GMSC.
32
33 j. The SMS-GMSC sends the result of the Forward Mobile Terminating Short Message to the
34 Service Center.
35 B.1.3.52 4.12.2.3 Clearing of MWN Information after Retrieval of Messages while in ANSI-
36 41 Foreign Mode – QualDir Method
37 This section describes the case where the messages are retrieved while a GSM subscriber is still
38 roaming in ANSI-41 foreign mode.
39
Vmail
Retrieval
a
FORW. MOBILE
TERM SM (mwn)
SEND ROUTING
b
INFO FOR SM (mwn)
Send Routing
c
Info for SM
d
FORW. SHORT
MESSAGE (mwn)
QUALDIR(MWNCOUNT, e
MWNTYPE)
f
(mwn delivered to
Mobile Station) g
Qualdir
h
Forw. Short Message (error: absent sub.)
Forw. Mobile
i
Term SM (error)
Report SM (error)
j
DeliveryStatus
k
1
GSM GSM GSM TDMA
SC SMS- HLR IIF MSC
GMSC
Vmail
Retrieval
a
FORW. MOBILE
TERM SM (mwn)
b
SEND ROUTING
INFO FOR SM (mwn)
c
Send Routing
Info for SM d
FORW. SHORT
MESSAGE (mwn) e
QUALDIR(MWNCOUNT,
MWNTYPE)
f
(mwn delivered to
Mobile Station) g
Qualdir
h
Forw. Short Message (error: absent sub.)
i
Forw. Mobile
Term SM (error)
j
Report SM (error)
DeliveryStatus k
2
3 Figure 101: Clearing of MWN Information after Retrieval of Messages while in ANSI-41 Foreign
4 mode – Qualdir Method
5 a. The voice mail messages are retrieved from the GSM subscriber.
1
2 b. The SC sends the Forward Mobile Terminating Short Message with Message Waiting Notification
3 (MWN) information set to “clear” to the GSM SMS-GMSC.
4
5 c. The GSM SMS-GMSC enquires 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. Another
10 requirement is that the Service Center sets the priority of this SMS to “high” to make sure that the
11 SMS is sent (Section 3.2.5 of GSM 03.40). This is necessary since the IIF had previously
12 responded with absent subscriber and the HLR had set some flags that could have prevented the
13 delivery of this new SMS.
14
15 e. The GSM SMS-GMSC originates an SMS with MWN information (set to “clear”) by sending
16 Forward Short Message to IIF then acting as a serving GSM MSC/VLR. This requires a GSM
17 phase 2 support or higher.
18
19 f. Upon reception of the Forward Short Message with MWN information (set to “clear”), the IIF shall
20 initiate a Qualification Directive message with MWN information (set to “clear”) to the serving
21 ANSI-41 MSC/VLR. The IIF is then acting as an ANSI-41 HLR. The MWN information consists of
22 two parameters: MessageWaitingNotificationCount (MWNCOUNT) and
23 MessageWaitingNotificationType (MWNTYPE). For a description of these parameters, see to the
24 ANSI-41-D specifications, sections 6.5.2.78 and 6.5.2.79 [1].
25
26 g. In this step, the MWN information (set to “clear”) shall be delivered to the mobile station.
27
28 h. The serving ANSI-41 MSC/VLR sends the Qualification Directive Return Result to the IIF. Note
29 that this result message does not guaranty that the MWN information (set to ”clear”) was
30 delivered successfully to the Mobile Station, it just means that the MSC/VLR received the
31 Qualification Directive message, so the MWN flag shall not be cleared at this point by the IIF.
32
33 i. The IIF sends the result of the Forward Short Message to the GSM SMS-GMSC with error code
34 “absent subscriber” so that the home system assumes that the delivery failed in case the
35 subscriber goes back to the home system without having received the clearing notification from
36 the serving MSC. This way, at the reception of the Update Location message, the HLR shall send
37 an Alert-SC message so that the MWN information (in a short message) is once again sent to the
38 Mobile Station.
39
40 j. The SMS-GMSC sends the result of the Forward Mobile Terminating Short Message to the
41 Service Center. Note that depending on the Service Center implementation, this may cause the
42 SMS to be re-sent periodically instead of waiting for the ALERTSC message indicating that the
43 subscriber is again available to receive short messages.
44
45 k. The SMS-GMSC reports the error to the HLR, which shall set the proper flags as per GSM 03.40
46 [4] so that an Alert-SC message is sent when necessary as explained in step i above.
47
Vmail
Retrieval
a
FORW. MOBILE
TERM SM (MWN)
b
SEND ROUTING
INFO FOR SM (MWN)
c
Send Routing
Info for SM
d
FORW. SHORT
MESSAGE (MWN)
e
Forw. Short Message (error)
f
Forw. Mobile
Term SM (error) g
Report SM (error)
DeliveryStatus
h
3
4 Figure 102: Handling at SMS delivery failure at the IIF
5 a. The GSM Service Center (SC) receives a voice mail for a specific subscriber.
6
7 b. The SC sends the Forward Mobile Terminating Short Message with Message Waiting Notification
8 (MWN) information to the GSM SMS-GMSC.
9
10 c. The GSM SMS-GMSC enquires about the subscriber location by sending the Send Routing
11 Information For Short Message to the HLR.
12
13 d. The HLR replies with the Send Routing Information For Short Message result. It is assumed that
14 the native GSM subscriber has already made a registration in the ANSI-41 MSC/VLR.
15
16 e. The GSM SMS-GMSC originates an SMS with MWN information by sending Forward Short
17 Message to IIF then acting as a serving GSM MSC/VLR.
18
19 f. Upon reception of the Forward Short Message with MWN information, the IIF encounters an error
20 and sends the result of the Forward Short Message to the GSM SMS-GMSC with the proper error
21 code as per GSM Specifications 09.02 [6].
22
23 g. The SMS-GMSC sends the result of the Forward Mobile Terminating Short Message to the
24 Service Center.
25
26 h. The SMS-GMSC reports the error to the HLR, which sets the proper flags as per GSM 03.40 [4]
27 so that an Alert-SC message is sent when necessary.
28
1 B.1.3.54 4.12.2.5 Handling at SMS delivery failure at the MSC/VLR – QualDir Method
Vmail
Delivery
a
FORW. MOBILE
TERM SM (MWN)
b
SEND ROUTING
INFO FOR SM (MWN)
c
Send Routing
Info for SM
d
FORW. SHORT
MESSAGE (MWN)
QUALDIR(MWNCOUNT,
e
① MWNTYPE)
f
Qualdir Return Error
g
Forw. Short Message (error)
h
Forw. Mobile
Term SM (error)
Report SM (error)
i
DeliveryStatus
j
3
GSM GSM GSM TDMA
SC SMS- HLR IIF MSC
GMSC
Vmail
Delivery
a
FORW. MOBILE
TERM SM (MWN)
b
SEND ROUTING
INFO FOR SM (MWN)
c
Send Routing
Info for SM
d
FORW. SHORT
MESSAGE (MWN) e
QUALDIR(MWNCOUNT,
① MWNTYPE)
f
Qualdir Return Error
g
Forw. Short Message (error)
h
Forw. Mobile
Term SM (error)
i
Report SM (error)
DeliveryStatus
j
4
5 Figure 103: Handling at SMS delivery failure at the MSC/VLR Qualdir Method
6 a. The GSM Service Center (SC) receives a voice mail for a specific subscriber.
7
1 b. The SC sends the Forward Mobile Terminating Short Message with Message Waiting Notification
2 (MWN) information to the GSM SMS-GMSC.
3
4 c. The GSM SMS-GMSC inquires 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.
9
10 e. The GSM SMS-GMSC originates an SMS with MWN information by sending Forward Short
11 Message to IIF then acting as a serving GSM MSC/VLR. This requires GSM phase 2 support or
12 higher.
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.
15
16 f. The IIF shall also initiate a Qualification Directive message with MWN information to the serving
17 ANSI-41 MSC/VLR. The IIF is then acting as an ANSI-41 HLR. The MWN information consists of
18 two parameters: MessageWaitingNotificationCount (MWNCOUNT) and
19 MessageWaitingNotificationType (MWNTYPE). For a description of these parameters, see to the
20 ANSI-41-D specifications, sections 6.5.2.78 and 6.5.2.79 [1].
21
22 g. The serving ANSI-41 MSC/VLR encounters an error and sends the Qualification Directive Return
23 Error to the IIF, as per the ANSI-41 Specifications, Chapter 6, Section 4.32.2, Table 42.
24 h. The IIF sends the error result of the Forward Short Message to the GSM SMS-GMSC.
25
26 i. The SMS-GMSC sends the result of the Forward Mobile Terminating Short Message to the
27 Service Center.
28
29 j. The SMS-GMSC reports the error to the HLR which sets the proper flags as per GSM 03.40 [4]
30 so that an Alert-SC message is sent when necessary.
31
32 B.1.3.55 4.12.2.6 Handling at SMS delivery failure at the MSC/VLR – GHOST/WEMT SMS
33 Method
34
Vmail
Delivery
a
FORW. MOBILE
TERM SM (MWN)
b
SEND ROUTING
INFO FOR SM (MWN)
c
Send Routing
Info for SM
d
FORW. SHORT
MESSAGE (MWN) e
SMDPP (GHOST, MWN)
f
smdpp (error)
g
Forw. Short Message (error)
h
Forw. Mobile
Term SM (error)
i
Report SM (error)
DeliveryStatus j
1
2 Figure 104: Handling at SMS delivery failure at the MSC/VLR – GHOST/WEMT SMS Method
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
18 f. Upon reception of the Forward Short Message with MWN information, the IIF shall initiate a Short
19 Message Delivery Point to Point with Teleservice GHOST/WEMT to the serving ANSI-41
20 MSC/VLR. The IIF is then acting as an ANSI-136 41 Message Center (MC). Inside of this GHOST
21 or WEMT short message is the GSM short message containing the MWN information.
22
23 g. The serving ANSI-41 MSC/VLR encounters an error and sends the Short Message Delivery Point
24 to Point Return error to the IIF.
25
26 h. The IIF sends the result of the Forward Short Message to the GSM SMS-GMSC with the proper
27 error code. .
28
29 i. The SMS-GMSC sends the result of the Forward Mobile Terminating Short Message to the
30 Service Center.
1
2 j. The SMS-GMSC shall report the error to the HLR.
3
Vmail
Delivery
a
FORW. MOBILE
TERM SM (MWN)
b
SEND ROUTING
INFO FOR SM (MWN)
Send Routing
c
Info for SM
d
FORW. SHORT
MESSAGE (MWN) QUALDIR
(MWNCOUNT, e
MWNTYPE)
① f
(MWN delivered to
Mobile Station) g
h
Forw. Short Message (error: absent sub.)
Forw. Mobile
i
Term SM (error)
j
Report SM (error)
DeliveryStatus
k
Time elapsed
l
REGNOT
m
j
Regnot(MWNCOUNT,
MWNTYPE)
n
(MWN delivered to
Mobile Station) o
1
Vmail
Delivery
a
FORW. MOBILE
TERM SM (MWN)
b
SEND ROUTING
INFO FOR SM (MWN)
c
Send Routing
Info for SM
d
FORW. SHORT
QUALDIR
MESSAGE (MWN) e
(MWNCOUNT,
MWNTYPE)
① f
(MWN delivered to
Mobile Station) g
h
Forw. Short Message (error: absent sub.)
i
Forw. Mobile
Term SM (error)
j
Report SM (error)
DeliveryStatus
k
Time elapsed l
REGNOT
m
j
Regnot(MWNCOUNT,
MWNTYPE) n
(MWN delivered to
Mobile Station) o
1
2 Figure 105: GSM SMS mapped to ANSI-41 Qualification Directive and to Registration
3 Notification Return Result
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 inquires 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. This requires GSM phase 2 support or
17 higher.
18 ①At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification
19 is to be delivered to the Mobile Station. If the handset only supports GSM phase 1, then a pure
20 text SMS shall be delivered to the IIF. The IIF shall then translate it into a CMT or GHOST/WEMT
21 IS-136ANSI-41 SMS. Note that this then becomes a simple SMS mapping covered in Section
22 4.11.
1
2 f. Upon reception of the Forward Short Message with MWN information, the IIF shall initiate a
3 Qualification Directive message with MWN information to the serving ANSI-41 MSC/VLR. The IIF
4 is then acting as an ANSI-41 HLR. The MWN information consists of two parameters:
5 MessageWaitingNotificationCount (MWNCOUNT) and MessageWaitingNotificationType
6 (MWNTYPE). For a description of these parameters, see to the ANSI-41 specifications, sections
7 6.5.2.78 and 6.5.2.79 [1]. Alternatively, a GHOST/WEMT short message could be sent instead of
8 the Qualification Directive message (see Section 4.12.2.2) if the IIF has the possibility to confirm
9 that the Mobile Station is SMS-capable.
10
11 g. In this step, the MWN information shall be delivered to the mobile station.
12
13 h. The serving ANSI-41 MSC/VLR sends the Qualification Directive Return Result to the IIF. Note
14 that this result message does not guaranty that the MWN information was delivered successfully
15 to the Mobile Station, it just means that the MSC/VLR received the Qualification Directive
16 message, therefore the MWN flag shall not be cleared at this point by the IIF.
17
18 i. The IIF sends the result of the Forward Short Message to the GSM SMS-GMSC with error code
19 “absent subscriber” so that the home system assumes that the delivery failed in case the
20 subscriber goes back to the home system without having retrieved the mail messages. This way,
21 at the reception of the Update Location message, the HLR shall send an Alert-SC message so
22 that the MWN information (in a short message) is once again sent to the Mobile Station.
23
24 j. The SMS-GMSC sends the result of the Forward Mobile Terminating Short Message to the
25 Service Center. Note that depending on the Service Center implementation, this may cause the
26 SMS to be re-sent periodically instead of waiting for the ALERTSC message indicating that the
27 subscriber is again available to receive short messages.
28
29 k. The SMS-GMSC reports the error to the HLR, which sets the proper flags as per GSM 03.40 [4]
30 so that an Alert-SC message is sent when necessary as explained in step i above.
31
32 l. Time elapses before the MS re-registers.
33
34 m. A Registration Notification is sent from the serving ANSI-41 MSC 2 to the IIF.
35
36 n. The IIF discovers that the MWN flag is still set. The IIF sends back the MWN in the Registration
37 Notification Return Result along with the other registration information (e.g. other Profile
38 parameters) to the serving ANSI-41 MSC/VLR. The IIF is then acting as an ANSI-41 HLR. The
39 MWN information consists of two parameters: MessageWaitingNotificationCount (MWNCOUNT)
40 and MessageWaitingNotificationType (MWNTYPE). For a description of these parameters, see to
41 the ANSI-41 specifications, sections 6.5.2.78 and 6.5.2.79 [1].
42
43 o. In this step, the MWN information shall be delivered to the mobile station. Since there is no
44 acknowledgement from the regnot Return Result, there is no guarantee that the MWN information
45 was delivered successfully to the Mobile Station. The MWN flag shall not be cleared at this point
46 by the IIF.
47
36 4.13.1 Location Registration ScenariosIn each of the following scenarios, the following
37 interactions are not shown :-
38 Interactions between SGSNs
39 Interactions between SGSNs and GGSNs
40 Existing procedures defined in GSM 03.60 [10], describing the actions between SGSNs or between
41 an SGSN and a GGSN for scenarios involving interaction between those functional elements also
42 apply.
1 Existing procedures and timers defined in GSM 03.60 [10], describing the actions between the SGSN
2 and the GSM HLR also apply between the SGSN and the IIF (emulating a GSM HLR).
3 The combined attach and location registration procedures described, require support of the optional
4 Gs interface as described in GSM 03.60[10].
5 It should be noted that certain scenarios may only be relevant to certain MS types. For a full
6 description of the various MS types see GSM 03.60 [10].
7 4.13.1.1 GPRS Attach (not currently registered)
8 If an MS requests GPRS service when currently not registered in the IIF, the MS performs a GPRS
9 attach request using its IMSI. The IIF acts like a GPRS HLR/AuC in this case. The subscriber's
10 ANSI-41 HLR has no knowledge of this request, but the IIF makes it aware of the attachment to an
11 SGSN via a REGNOT. If timer GPRS_LU is used then the message flow is as shown in Figure 106.
12 If timer GPRS_LU is not used then the message flow is as shown in Figure 107.
1 i. The IIF validates whether the GPRS service request is authorized. Since GPRS service is
2 requested, and the subscriber is currently PS-deregistered, it initiates the GSM MAP Insert
3 Subscriber Data Procedure towards the SGSN after the subscriber has been successfully
4 authorized. This procedure is used to download GPRS subscriber data to the SGSN. Multiple
5 Insert Subscriber Data transactions may be necessary to complete the transfer of subscriber data
6 to the SGSN.
7 j. The SGSN acknowledges the ISD Operation(s).
8 k. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF
9 returns an acknowledgement to the Update GPRS Location Request.
10 l. The SGSN acknowledges the GPRS Attach request.
11
2 If an MS requests GPRS service when currently registered in an ANSI-41 network, the SGSN sends
3 an Update GPRS location update using its IMSI. The IIF acts like a GPRS HLR/AuC and an ANSI-41
4 VLR in this case. To the subscriber's ANSI-41 HLR, the subscriber becomes registered on the IIF
5 acting as an ANSI-41 MSC. If timer GPRS_LU is used then the message flow is as shown in Figure
6 108. If timer GPRS_LU is not used then the message flow is as shown in Figure 109.
MS SGSN PMSC/
MSC IIF HLR VLR
GPRS Attach Req
a
(IMSI)
Authentication Info b
Authentication Info Ack
c
Authentication Req
d
Authentication Res e
Update GPRS Location Req (IMSI)
f
Insert Sub Data
g
Insert Sub Data Ack GPRS_LU
h
Update gprs location ack
i
REGNOT
j
REGCANC
k
regcanc
l
Regnot ack
m
GPRS Attach Accept
n
o
GSM NETWORK ANSI-41 NETWORK
7 Figure 108: GPRS Attach when currently registered in ANSI-41 (Option 1: with timer)
8
9 a. MS performs a GPRS Attach.
10 b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to
11 perform authentication i.e. authentication triplets, it requests authentication information from the
12 IIF. The IIF emulates a GSM HLR/AuC in this case supporting GPRS.
13 c. The IIF returns the necessary authentication information, if applicable.
14 d. SGSN initiates authentication towards the MS.
15 e. MS responds to the authentication request.
16 f. SGSN initiates a MAP GPRS location update towards the IIF. The Update GPRS Location
17 Request contains the IMSI.
1 g. The IIF validates whether the GPRS service request is authorized. Since GPRS service is
2 requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert Subscriber
3 Data Procedure towards the SGSN after the subscriber has been successfully authorized. This
4 procedure is used to download GPRS subscriber data to the SGSN. Multiple Insert Subscriber
5 Data transactions may be necessary to complete the transfer of subscriber data to the SGSN.
6 h. The SGSN acknowledges the ISD Operation(s).
7 i. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF
8 returns an acknowledgement to the Update GPRS Location Request.
9 j. After the IIF’s GPRS_LU timer expires, the IIF shall send a registration notification (REGNOT)
10 to the ANSI-41 HLR. The REGNOT shall contain the MSID (MIN/IMSI), the ESN, the MSCID,
11 etc. If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber
12 shall be passed in the REGNOT to the subscriber’s HLR. The ANSI-41 HLR records the
13 address of the IIF as the serving ANSI-41 MSC. Although call delivery may not be possible,
14 SMS delivery is made possible by registering the IIF as the ANSI-41 MSC with the ANSI-41
15 HLR.
16 k. The ANSI-41 HLR updates its location information and deletes the previous VLR record by
17 sending a REGCANC to the previous MSC/VLR.
18 l. The VLR acknowledges the REGCANC.
19 m. The ANSI-41 HLR sends an acknowledgment to the registration with a regnot. The IIF may
20 ignore the CS-related profile information, since the MS is only GPRS-attached (and not GSM
21 CS-attached).
22 If a negative regnot response is received from the ANSI-41 HLR, (then as a Network option) the
23 IIF may perform an initiated detach procedure as described in section 4.13.2.6.
24 n. The SGSN acknowledges the GPRS Attach request.
25
regcan
i
regnot j
1 Figure 109: GPRS Attach when currently registered in ANSI-41 (Option 2: without timer)
2
3 a. MS performs a GPRS Attach. .
4 b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to
5 perform authentication i.e. authentication triplets, it requests authentication information from the
6 IIF. The IIF emulates a GSM HLR/AuC in this case supporting GPRS.
7 c. The IIF returns the necessary authentication information, if applicable.
8 d. SGSN initiates authentication towards the MS.
9 e. MS responds to the authentication request.
10 f. SGSN initiates a MAP GPRS location update towards the IIF. The Update GPRS Location
11 Request contains the IMSI.
12 g. The REGNOT shall contain the MSID (MIN/IMSI), the ESN, the MSCID, etc. If SIM-based
13 roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall be passed in the
14 REGNOT to the subscriber’s HLR. The ANSI-41 HLR records the address of the IIF as the
1 serving ANSI-41 MSC. Although call delivery may not be possible, SMS delivery is made
2 possible by registering the IIF as the ANSI-41 MSC with the ANSI-41 HLR.
3 h. The ANSI-41 HLR updates its location information and deletes the previous VLR record by
4 sending a REGCANC to the previous MSC/VLR.
5 i. The VLR acknowledges the REGCANC.
6 j. The ANSI-41 HLR sends an acknowledgment to the registration with a regnot.
7 k. The IIF validates whether the GPRS service request is authorized. Since GPRS service is
8 requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert Subscriber
9 Data Procedure towards the SGSN after the subscriber has been successfully authorized. This
10 procedure is used to download GPRS subscriber data to the SGSN. Multiple Insert Subscriber
11 Data transactions may be necessary to complete the transfer of subscriber data to the SGSN.
12 l. The SGSN acknowledges the ISD Operation(s).
13 m. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF
14 returns an acknowledgement to the Update GPRS Location Request.
15 n. The SGSN acknowledges the GPRS Attach request.
16
17
2 If an MS requests a GPRS routing area update while registered on a GPRS SGSN only. The
3 message flow is as shown in Figure 110 and 111, depending on whether the timer GPRS_LU is
4 supported on the IIF.
MS SGSN
IIF HLR Prev
SGSN
inter-SGSN Routing Area Update
a
(IMSI)
Authentication Info b
Authentication Info Ack
c
Authentication Req
d
Authentication Res e
Update GPRS Location Req (IMSI)
f
Cancel Location
g
Cancel Location Ack
h
Insert Sub Data
i
Insert Sub Data Ack
j
Update gprs location ack GPRS_LU
k
REGNOT
l
REGCANC
m
regcanc
n
Regnot ack
o
inter-SGSN Routing Area Update Accept
p
ANSI-41
GPRS NETWORK GPRS NETWORK
1 h. The IIF shall receive a Cancel Location acknowledgement from the previous SGSN.
2 i. The IIF validates whether the GPRS service request is authorized. Since GPRS service is
3 requested, it initiates the GSM MAP Insert Subscriber Data Procedure towards the SGSN after
4 the subscriber has been successfully authorized. This procedure is used to download GPRS
5 subscriber data to the SGSN. Multiple Insert Subscriber Data transactions may be necessary to
6 complete the transfer of subscriber data to the SGSN.
7 j. The SGSN acknowledges the ISD Operation(s).
8 k. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF
9 returns an acknowledgement to the Update GPRS Location Request.
10 Note: Steps l,m,n & o are optional depending on whether the IIF supports multiple MSCIDs.
11 l. After the IIF’s GPRS_LU timer expires, the IIF shall send a registration notification (REGNOT) to
12 the ANSI-41 HLR. The REGNOT shall contain the MSID (MIN/IMSI), the ESN, the MSCID, etc. If
13 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. The ANSI-41 HLR records the address of the IIF
15 as the serving ANSI-41 MSC. Although call delivery may not be possible, SMS delivery is made
16 possible by registering the IIF as the ANSI-41 MSC with the ANSI-41 HLR.
17 m. The HLR updates its location information and deletes the previous VLR record by sending a
18 REGCANC to the previous MSC/VLR, which in this case is the IIF (if in step l, the IIF sent a
19 REGNOT with a different MSCID (IIF address corresponding to the current SGSN) than the
20 MSCID sent corresponding to the previous SGSN).
21 n. The IIF acknowledges the REGCANC.
22 o. The ANSI-41 HLR sends an acknowledgment to the registration with a regnot. The IIF may
23 ignore the CS-related profile information, since the MS is only GPRS-attached (and not GSM CS-
24 attached).
25
1 Related to Figure 110, if a negative regnot response is received from the ANSI-41 HLR, (then as
2 a Network option) the IIF may perform an initiated detach procedure as described in section
3 4.13.2.6.
4 p. The SGSN acknowledges the GPRS routing area update.
MS SGSN
IIF HLR Prev
SGSN
inter-SGSN Routing Area Update
a
(IMSI)
Authentication Info b
Authentication Info Ack
c
Authentication Req
d
Authentication Res e
Update GPRS Location Req (IMSI)
f
Cancel Location
g
Cancel Location Ack
h
REGNOT i
REGCANC
j
regcanc
k
Regnot ack
l
Insert Sub Data
m
Insert Sub Data Ack
n
Update gprs location ack
o
inter-SGSN Routing Area Update Accept
ANSI-41 p
GPRS NETWORK GPRS NETWORK
1 i. If the IIF implementation supports multiple MSCIDs, then it shall send a REGNOT to the
2 ANSI-41 HLR with the MSCID corresponding to the new SGSN. Then the IIF shall correlate
3 that MSCID with the GSM MSCID when receiving mobile terminated SMS messages (so that
4 the IIF can deliver them to the SGSN).
5 j. This is a continuation of the optional procedure started in item i. IIF receives REGCANC. The
6 IIF needs to keep both the current MSCID associated to the SGSN as well as the current
7 MSCID associated to the MSC. The IIF must also keep a record of the last MSCID which
8 was sent to the ANSI-41 HLR to know that is the one stored in the ANSI-41 HLR.
9 k. This is a continuation of the optional procedure started in item i. IIF sends regcanc response.
10 l. This is a continuation of the optional procedure started in item i. IIF receives regnot
11 response.
12 m. The IIF validates whether the GPRS service request is authorized. Since GPRS service is
13 requested, it initiates the GSM MAP Insert Subscriber Data Procedure towards the SGSN
14 after the subscriber has been successfully authorized. This procedure is used to download
15 GPRS subscriber data to the SGSN. Multiple Insert Subscriber Data transactions may be
16 necessary to complete the transfer of subscriber data to the SGSN.
17 n. The SGSN acknowledges the ISD Operation(s).
18 o. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the
19 IIF returns an acknowledgement to the Update GPRS Location Request.
20 p. The SGSN acknowledges the Routing Area Update request.
21
22
2 If an MS roams while registered in a GSM serving MSC, and the MS requests GPRS attach, the MS
3 performs a GPRS attach and the network responds as shown in Figure 112. Note that the GSM MSC
4 does not update the IIF (emulating the GSM HLR). The serving MSC remains constant.
MS SGSN PMSC/
MSC IIF HLR VLR
GPRS Attach Req
a
(IMSI)
Authentication Info b
Authentication Info Ack
c
Authentication Req
d
Authentication Res e
Update GPRS Location Req (IMSI)
f
REGNOT
g
REGCANC
h
regcanc
i
Regnot ack
j
Insert Sub Data
k
Insert Sub Data Ack
l
Update gprs location ack
m
BSSAP+-Location Update Req
n
BSSAP+-Location Update Accept
o
GPRS Attach Accept p
GSM NETWORK ANSI-41 GSM NETWORK
1 g. If the IIF implementation supports multiple MSCIDs, then it shall send a REGNOT to the ANSI-41
2 HLR with the MSCID corresponding to the new SGSN.
3 h. This is a continuation of the optional procedure started in item g. IIF receives REGCANC.
4 i. This is a continuation of the optional procedure started in item g. IIF sends regcanc response.
5 j. This is a continuation of the optional procedure started in item g. IIF receives regnot response.]
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 sends a BSSAP+LocationUpdateRequest to the GSM MSC over the Gs interface.
15 The GSM MSC creates the association with the SGSN by storing the SGSN Number. The MSC
16 does not see a need to notify the IIF (emulating the GSM HLR, since there is no change to the
17 CS location update parameters).
18 o. The GSM MSC acknowledges the BSSAP+LocationUpdateRequest over the Gs interface by
19 sending the Accept message.
20 p. The SGSN acknowledges the GPRS Attach request from the MS.
21
22
1
2 4.13.1.5 Combined GSM and GPRS attach when not currently registered
3 If an MS requests a combined GSM and GPRS attach when not registered in the IIF, then the SGSN
4 first requests a GPRS location update to the IIF (acting as a GPRS HLR) and then a CS location
5 update through the GSM MSC as depicted in Figure 114.
MS SGSN IIF
MSC HLR
Combined Attach Req
(IMSI)
a
Authentication Info b
Authentication Info Ack
Authentication Req c
d
Authentication Res e
Update GPRS Location Req (IMSI)
f
Insert Sub Data
g
Insert Sub Data Ack GPRS_LU
h
Update gprs location ack
i
BSSAP+-Location Update Req
j
Update Location Req
k
REGNOT
l
Regnot ack m
Insert Subscriber Data
n
ISD ack
o
Update Location ack p
BSSAP+-Location Update Accept q
Combined Attach Accept
r
GSM NETWORK ANSI-41 NETWORK
6
7 Figure 113: Combined GPRS and GSM attach (Option 1: With timer).
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. The IIF starts timer GPRS LU.
17 g. The IIF validates whether the GPRS service request is authorized. Since GPRS service is
18 requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert Subscriber
1 Data Procedure towards the SGSN after the subscriber has been successfully authorized. This
2 procedure is used to download GPRS subscriber data to the SGSN. Multiple Insert Subscriber
3 Data transactions may be necessary to complete the transfer of subscriber data to the SGSN.
4 h. The SGSN acknowledges the ISD Operation(s).
5 i. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF
6 returns an acknowledgement to the Update GPRS Location Request.
7 j. The SGSN sends a BSSAP+LocationUpdateRequest to the GSM MSC over the Gs interface.
8 The GSM MSC creates the association with the SGSN by storing the SGSN Number.
9 k. The MSC determines that it needs to notify the IIF (emulating the GSM HLR), since there is a
10 change to the CS location update parameters. The MSC sends the Update Location operation to
11 the IIF (emulating the GSM HLR). The IIF stops timer GPRS LU.
12 l. The IIF shall send a Registration Notification (REGNOT) to the ANSI-41 HLR to indicate the
13 changed location (MSCID associated with the new GSM MSC).
14 If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall be
15 passed in the REGNOT to the subscriber’s HLR. This ESN may not match the currently validated
16 dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for this subscriber.
17 m. The ANSI-41 HLR acknowledges the registration and sends back the subscriber’s information.
18 This information is for non-GPRS services.
19 n. The IIF sends MAP INSERT SUBSCRIBER DATA message(s) to the GSM MSC providing GSM
20 CS information based on the contents of the regnot (profile).
21 o. The GSM MSC acknowledges receipt of the Insert Subscriber Data information.
22 p. The IIF acknowledges the completion of the Update Location procedure and sends the Update
23 Location Acknowledgement to the GSM MSC.
24 q. The GSM MSC acknowledges the BSSAP+LocationUpdateRequest over the Gs interface to the
25 SGSN by sending the Accept message.
26 r. The SGSN acknowledges the combined GPRS and GSM Attach request from the MS.
27
28
MS SGSN IIF
MSC HLR
Combined Attach Req
(IMSI)
a
Authentication Info b
Authentication Info Ack
Authentication Req c
d
Authentication Res e
Update GPRS Location Req (IMSI)
f
REGNOT
g
Regnot ack
h
Insert Sub Data
i
Insert Sub Data Ack
j
Update gprs location ack
k
BSSAP+-Location Update Req
l
Update Location Req
m
Insert Subscriber Data n
ISD ack
o
Update Location ack p
BSSAP+-Location Update Accept q
Combined Attach Accept
r
GSM NETWORK ANSI-41 NETWORK
1 Figure 114: Combined GPRS and GSM attach (Option 2: Without timer and without support for
2 multiple MSCIDs).
3
MS SGSN IIF
MSC HLR
Combined Attach Req
(IMSI)
a
Authentication Info b
Authentication Info Ack
Authentication Req c
d
Authentication Res e
Update GPRS Location Req (IMSI)
f
REGNOT
g
Regnot ack
h
Insert Sub Data
i
Insert Sub Data Ack
j
Update gprs location ack
k
MS
SGSN MSC IIF HLR
REGNOT
n
REGCANC
o
regcanc
p
regnot
q
Insert Sub Data
r
Insert Sub Data Ack
s
Update Location ack
t
BSSAP+-Location Update Accept
GPRS Attach Accept/ u
Routing Area Update
Accept v
1 Figure 115: Combined GPRS and GSM attach (Option 3: IIF supports multiple MSCIDs).
2
3
1 s. The GSM MSC acknowledges receipt of the Insert Subscriber Data information.
2 t. The IIF acknowledges the completion of the Update Location procedure and sends the Update
3 Location Acknowledgement to the GSM MSC.
4 u. The GSM MSC acknowledges the BSSAP+LocationUpdateRequest over the Gs interface to the
5 SGSN by sending the Accept message.
6 v. The SGSN acknowledges the combined GPRS and GSM Attach request from the MS.
7
2 If an MS requests a combined routeing area update when previously registered on a different SGSN
3 and GSM MSC, then the SGSN first requests a GPRS location update to the IIF (acting as a GPRS
4 HLR) and then a CS location update.
5
MS SGSN PMSC/
MSC IIF HLR Prev VLR
SGSN
inter-SGSN Routing Area Update
a
(IMSI)
Authentication Info b
Authentication Info Ack
c
Authentication Req
d
Authentication Res e
Update GPRS Location Req (IMSI)
f
Cancel Location
g
Cancel Location Ack
h
REGNOT i
REGCANC
j
regcanck
k
Regnot ack
l
Insert Sub Data
m
Insert Sub Data Ack
n
Update gprs location ack
o
ANSI-41
GSM NETWORK GSM NETWORK
MS SGSN PMSC/
MSC IIF HLR Prev VLR
SGSN
BSSAP+-Location Update Req
p
Update Location Req
q
Cancel Location
r
Cancel Location Ack
s
REGNOT
t
REGCANC
u
regcanc
v
regnot
w
Insert Sub Data
x
Insert Sub Data Ack
y
Update Location ack
z
BSSAP+-Location Update Accept
GPRS Attach Accept/ aa
Routing Area Update
Accept bb
ANSI-41
GSM NETWORK GSM NETWORK
1
2 Figure 116: Combined Inter-SGSN RA/LA update
3 a. MS sends a Routeing Area Update request
4 b. If the Serving GPRS Support Node (SGSN) does not have authentication information in order to
5 perform authentication i.e. authentication triplets, it requests authentication information from the
6 IIF. The IIF emulates a GSM HLR/AuC in this case supporting GPRS.
7 c. The IIF returns the necessary authentication information, if applicable.
8 d. SGSN initiates authentication towards the MS.
9 e. MS responds to the authentication request.
10 f. SGSN initiates a MAP GPRS location update towards the IIF. The Update GPRS Location
11 Request contains the IMSI.
12 g. In the case of a combined attach when registered on a different MSC and SGSN, and in the case
13 of a combined inter-SGSN routing area update case when previously registered on a different
14 MSC and SGSN, the IIF (acting like a GPRS HLR) shall also send a Cancel Location to the
15 previous SGSN
16 h. IIF shall receive an acknowledgement for the Cancel Location.
1 i. If the IIF implementation supports multiple MSCIDs, then it shall send a REGNOT to the ANSI-41
2 MSC with the MSCID corresponding to the new SGSN.
3 j. This is a continuation of the optional procedure started in item i. IIF receives REGCANC. The IIF
4 needs to keep both the current MSCID associated to the SGSN as well as the current MSCID
5 associated to the MSC. The IIF must also keep a record of the last MSCID which was sent to the
6 ANSI-41 HLR to know that is the one stored in the ANSI-41 HLR.
7 k. This is a continuation of the optional procedure started in item i. IIF sends regcanc response.
8 l. This is a continuation of the optional procedure started in item i. IIF receives regnot response.
9 m. The IIF validates whether the GPRS service request is authorized. Since GPRS service is
10 requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert Subscriber
11 Data Procedure towards the SGSN after the subscriber has been successfully authorized. This
12 procedure is used to download GPRS subscriber data to the SGSN. Multiple Insert Subscriber
13 Data transactions may be necessary to complete the transfer of subscriber data to the SGSN.
14 n. The SGSN acknowledges the ISD Operation(s).
15 o. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF
16 returns an acknowledgement to the Update GPRS Location Request.
17 p. The SGSN sends a BSSAP+LocationUpdateRequest to the GSM MSC over the Gs interface.
18 The GSM MSC creates the association with the SGSN by storing the SGSN Number.
19 q. The MSC determines that it needs to notify the IIF (emulating the GSM HLR), since there is a
20 change to the CS location update parameters, so the IIF sends the Update Location operation to
21 the IIF (emulating the GSM HLR).
22 r. The IIF sends a Cancel Location to the previous GSM MSC/VLR if a change in MSC has been
23 detected.
24 s. The IIF receives the Cancel Location acknowledgement.
25 t. If the IIF implementation supports multiple IIF MSCIDs, then it shall send a Registration
26 Notification (REGNOT) to the ANSI-41 HLR to indicate the changed location (MSCID associated
27 to the new GSM MSC).
28 If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall be
29 passed in the REGNOT to the subscriber’s HLR. This ESN may not match the currently validated
30 dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for this subscriber.
31 u. This is a continuation of the optional procedure started in item t. The IIF receives a REGCANC if
32 the MSCID just sent in item (t) is a different one than stored in the ANSI-41 HLR. IIF receives
33 REGCANC. The IIF needs to keep both the current MSCID associated to the SGSN as well as
34 the current MSCID associated to the MSC. The IIF must also keep a record of the last MSCID
35 which was sent to the ANSI-41 HLR to know that is the one stored in the ANSI-41 HLR.
36 v. This is a continuation of the optional procedure started in item t. The IIF acknowledges the
37 regcanc.
38 w. This is a continuation of the optional procedure started in item t. The IIF receives the regnot
39 response with the subscriber’s information. This information is for non-GPRS services.
40 x. 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 y. The GSM MSC acknowledges receipt of the Insert Subscriber Data information.
1 z. The IIF acknowledges the completion of the Update Location procedure and sends the Update
2 Location Acknowledgement to the GSM MSC.
3 aa. The GSM MSC acknowledges the BSSAP+LocationUpdateRequest over the Gs interface to the
4 SGSN by sending the Accept message.
5 bb. The SGSN acknowledges the GPRS Attach request from the MS.
6
7
8
1 4.13.1.7 Inter-SGSN routing area update when GSM CS and GPRS attached (GSM MSC
2 remains constant)
3 An MS request a GPRS routing area update while registered in a GSM serving MSC and GPRS
4 attached. In this case, the change of routing areas is within one Location area (and the MSC remains
5 constant) as shown in Figure 118. Note that the GSM MSC does not update the IIF (emulating the
6 GSM HLR).
7
MS SGSN
MSC IIF HLR Prev
SGSN
inter-SGSN Routing Area Update
a
(IMSI)
Authentication Info b
Authentication Info Ack
c
Authentication Req
d
Authentication Res e
Update GPRS Location Req (IMSI)
f
Cancel Location
g
Cancel Location Ack
h
REGNOT i
REGCANC
j
regcanc
k
Regnot ack
l
Insert Sub Data
m
Insert Sub Data Ack
n
Update gprs location ack
o
ANSI-41
GSM NETWORK GSM NETWORK
MS SGSN
MSC IIF HLR Prev
SGSN
BSSAP+-Location Update Req
p
BSSAP+-Location Update Accept
q
Routing Area Update
Accept
r
GSM NETWORK ANSI-41
GSM NETWORK
2 Figure: 117: Inter-SGSN routing area update when GSM CS and GPRS Attached (MSC remains
3 constant)
1
2 a. MS sends a Routing 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. The IIF (acting like a GPRS HLR) shall send a Cancel Location to the previous SGSN
12 h. IIF shall receive an acknowledgement for the Cancel Location.
13 i. If the IIF implementation supports multiple MSCIDs, then it shall send a REGNOT to the ANSI-41
14 MSC with the MSCID corresponding to the new SGSN. The IIF shall correlate that MSCID with
15 the GSM MSCID when receiving mobile terminated SMS messages (so that the IIF can deliver
16 them to the MSC).
17 j. This is a continuation of the optional procedure started in item i. IIF receives REGCANC. The IIF
18 needs to keep both the current MSCID associated to the SGSN as well as the current MSCID
19 associated to the MSC. The IIF must also keep a record of the last MSCID which was sent to the
20 ANSI-41 HLR to know that is the one stored in the ANSI-41 HLR.
21 k. This is a continuation of the optional procedure started in item i. IIF sends regcanc response.
22 l. This is a continuation of the optional procedure started in item i. IIF receives regnot response.
23 m. The IIF validates whether the GPRS service request is authorized. Since GPRS service is
24 requested, it initiates the GSM MAP Insert Subscriber Data Procedure towards the SGSN after
25 the subscriber has been successfully authorized. This procedure is used to download GPRS
26 subscriber data to the SGSN. Multiple Insert Subscriber Data transactions may be necessary to
27 complete the transfer of subscriber data to the SGSN.
28 n. The SGSN acknowledges the ISD Operation(s).
29 o. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF
30 returns an acknowledgement to the Update GPRS Location Request.
31 p. The SGSN sends a BSSAP+LocationUpdateRequest to the GSM MSC over the Gs interface.
32 q. The MSC determines that it does not need to notify the IIF (emulating the GSM HLR), since there
33 is no change to the CS location update parameters, so the IIF does not send the Update Location
34 operation to the IIF (emulating the GSM HLR). The GSM MSC acknowledges the
35 BSSAP+LocationUpdateRequest over the Gs interface to the SGSN by sending the Accept
36 message.
37 r. The SGSN acknowledges the Routing Area Update request from the MS.
38
2 This scenario describes the case where a mobile that is currently registered in an ANSI-41 MSC
3 performs a combined attach for both GPRS and non-GPRS services.
4
MS SGSN PMSC/
MSC IIF HLR VLR
GPRS Attach Req
(IMSI)
a
Authentication Info b
Authentication Info Ack
c
Authentication Req
d
Authentication Res e
Update GPRS Location Req (IMSI)
f
Insert Sub Data GPRS_LU
g
Insert Sub Data Ack h
Update gprs location ack
i
BSSAP+-Location Update Req
j
Update Location Req
k
REGNOT
l
REGCANC
m
regcanc
n
Regnot ack
o
Insert Sub Data p
Insert Sub Data Ack
q
Update Locationack
r
BSSAP+-Location Update Accept s
GPRS Attach Accept
t
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. The IIF starts timer GPRS LU.
11 g. The IIF validates whether the GPRS service request is authorized. Since GPRS service is
12 requested, and the MS is currently PS-deregistered, it initiates the GSM MAP Insert Subscriber
13 Data Procedure towards the SGSN after the subscriber has been successfully authorized. This
14 procedure is used to download GPRS subscriber data to the SGSN. Multiple Insert Subscriber
15 Data transactions may be necessary to complete the transfer of subscriber data to the SGSN.
16 h. The SGSN acknowledges the ISD Operation(s).
17 i. Once the IIF has received an acknowledgement to the Insert Subscriber Data operation, the IIF
18 returns an acknowledgement to the Update GPRS Location Request.
19 j. The SGSN sends a BSSAP+LocationUpdateRequest to the GSM MSC over the Gs interface.
20 The GSM MSC creates the association with the SGSN by storing the SGSN Number.
21 k. The MSC determines that it needs to notify the IIF (emulating the GSM HLR), since there is a
22 change to the CS location update parameters. The MSC sends the Update Location operation to
23 the IIF (emulating the GSM HLR). The IIF stops timer GPRS LU.
24 l. The IIF shall send a Registration Notification (REGNOT) to the ANSI-41 HLR to indicate the
25 changed location (MSCID associated with the new GSM MSC).
26 If SIM-based roaming is authorized, an initially provisioned, fixed ESN for this subscriber shall be
27 passed in the REGNOT to the subscriber’s HLR. This ESN may not match the currently validated
28 dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for this subscriber.
29 m. The HLR updates its location information and deletes the previous VLR record by sending a
30 REGCANC to the previous MSC/VLR.
31 n. The VLR acknowledges the REGCANC.
32 o. The ANSI-41 HLR acknowledges the registration and sends back the subscriber’s information.
33 This information is for non-GPRS services
34 p. The IIF sends MAP INSERT SUBSCRIBER DATA message(s) to the GSM MSC providing GSM
35 CS information based on the contents of the regnot (profile).
36 q. The GSM MSC acknowledges receipt of the Insert Subscriber Data information.
37 r. The IIF acknowledges the completion of the Update Location procedure and sends the Update
38 Location Acknowledgement to the GSM MSC.
39 s. The GSM MSC acknowledges the BSSAP+LocationUpdateRequest over the Gs interface to the
40 SGSN by sending the Accept message.
41 t. The SGSN acknowledges the combined GPRS and GSM attach request from the MS.
MS SGSN PMSC/
MSC IIF HLR VLR
GPRS Attach Req (IMSI)
a
Authentication Info b
Authentication Info Ack
c
Authentication Req
d
Authentication Res e
Update GPRS Location Req (IMSI)
f
REGNOT
g
REGCANC
h
regcanc
i
Regnot ack
j
Insert Sub Data
k
Insert Sub Data Ack
l
Update gprs location ack
m
MS PMSC/
SGSN MSC IIF HLR VLR
REGNOT
p
REGCANC
q
regcanc
r
regnot
s
Insert Sub Data
t
Insert Sub Data Ack
u
Update Location ack
v
BSSAP+-Location Update Accept
w
GPRS Attach Accept
x
1 Figure 119: Combined attach when registered on a ANSI-41 MSC (Option 2: without timer )
2
1 validated dynamic ESN for this subscriber, but the HLR shall also accept this fixed ESN for
2 this subscriber.
3 q. This is a continuation of the optional procedure started in item p. The IIF receives a
4 REGCANC if the MSCID just sent in item (p) is a different one than stored in the ANSI-41
5 HLR. The IIF needs to keep both the current MSCID associated to the SGSN as well as the
6 current MSCID associated to the MSC. The IIF must also keep a record of the last MSCID
7 which was sent to the ANSI-41 HLR to know that is the one stored in the ANSI-41 HLR.
8 r. This is a continuation of the optional procedure started in item p. The IIF acknowledges the
9 regcanc.
10 s. This is a continuation of the optional procedure started in item p. The IIF receives the regnot
11 response with the subscriber’s information. This information is for non-GPRS services.
12 t. The IIF sends MAP INSERT SUBSCRIBER DATA message(s) to the GSM MSC providing
13 GSM CS information based on the contents of the regnot (profile).
14 u. The GSM MSC acknowledges receipt of the Insert Subscriber Data information.
15 v. The IIF acknowledges the completion of the Update Location procedure and sends the
16 Update Location Acknowledgement to the GSM MSC.
17 w. The GSM MSC acknowledges the BSSAP+LocationUpdateRequest over the Gs interface to
18 the SGSN by sending the Accept message.
19 x. The SGSN acknowledges the combined GPRS and GSM attach request from the MS.
20
8 In any of the scenarios shown previously in 4.13.1 where the ANSI-41 HLR is informed about the
9 registration attempt (assuming authentication is successful or not performed), the registration
10 procedure may fail.
11 In the event that the ANSI-41 HLR denies the registration attempt, it shall send a regnot to the IIF
12 indicating the reason for failure. If the IIF determines that the MS is already registered in an SGSN, it
13 shall send a Cancel Location to the SGSN. Otherwise, the IIF sends an update GPRS location
14 response indicating the reason for failure.
18 A GPRS mobile attached for both GPRS and non-GPRS services can request a detach for circuit
19 services (IMSI detach). The IIF is not notified about the MS initiated detachment and hence the ANSI-
20 41 HLR is not informed.
21 4.13.2.2 GPRS Detach While Attached for Both GPRS and GSM CS Services
22 A GPRS mobile attached for both GPRS and non-GPRS services can request a GPRS detach. The
23 IIF is not notified about the MS initiated detachment and hence the ANSI-41 HLR is not informed.
24 4.13.2.3 GPRS Detach While Attached for GPRS Services Only
25 In GPRS, the GPRS HLR is not notified when a GPRS subscriber performs a GPRS detach. Hence,
26 the IIF (which is emulating the GPRS HLR) shall not be notified of the GPRS detach. In this case, a
27 GPRS subscriber performs a Detach request that is handled by the SGSN and GGSN to remove MM
28 and PDP contexts. There is no interworking with circuit services.
29 4.13.2.4 Combined GPRS Detach and GSM CS (IMSI) Detach
30 A GPRS mobile attached for both GPRS and non-GPRS services can request a combined detach
31 from GPRS and non-GPRS services. The IIF is not notified about the MS initiated detachment and
32 hence the ANSI-41 HLR is not informed.
33
34
2 The IIF becomes involved in a detach procedure when the detach procedure is followed by a purge
3 MS procedure. The following scenario shows the case where a GAIT mobile is attached for services
4 to an SGSN-only. The mobile performs a GPRS detach. After accepting the detach request, the
5 SGSN is configured to initiate a purge MS procedure (after some pre-configured time period). In a
6 case when the MS is still GSM CS attached, the MS-Inactive is not sent by the IIF. Likewise, if an
7 MSC sends the PurgeMS operation to the IIF when the subscriber is still GPRS attached, the IIF
8 would not send the MS-Inactive to the ANSI-41 HLR.
SGSN ANSI-41
MS IIF
HLR
Detach Request
a
b
Signaling
with GGSN
c
Detach Accept d
Purge MS e
Purge MS Ack f
MSINACTIVE g
msinactive h
9
10 Figure 120: MS in GSM Foreign Mode Performing GPRS Detach Followed by Purge
11
12 a. The MS performs a Detach Request to detach from GPRS services. This MS was attached for
13 GPRS services only.
14 b. The SGSN exchanges signaling information with the GGSN to remove PDP contexts on the
15 GGSN for the subscriber.
16 c. See (b)
17 d. The SGSN accepts the detach from the MS and sends a Detach Accept.
18 e. The SGSN is configured to delete MM contexts as soon as the Detach Accept is sent. Hence,
19 the SGSN notifies the IIF (acting as a GPRS HLR) that it has deleted the MM context for the MS.
1 f. The IIF acknowledges the Purge Operation and marks in its GPRS subscription data for the
2 subscriber that the GPRS data has been purged.
3 g. The IIF sends an MSINACTIVE to the ANSI-41 HLR to de-register the MS from the IIF (acting as
4 an ANSI-41 MSC).
5 h. The ANSI-41 HLR acknowledges the MSINACTIVE operation
6
2 The IIF initiated detach procedure is initiated by the IIF. The procedure results in the removal of a
3 subscribers PDP contexts at the SGSN.
4
Cancel Location
a
Detach Request
b
Delete PDP Context Request
c
Delete PDP Context Response
d
GPRS Detach Indication
e
Detach Accept
f
1 1Note: In some cases the IIF may send an MS Inactive towards the ANSI-41 HLR (but not if CS
2 services are still to be offered).
3
4 4.13.3 SMS Scenarios
5 This section describes the scenarios for MS terminated and MS originated SMS while the mobile in
6 roaming in a GPRS network in GSM foreign mode.
7 4.13.3.1 SMS Scenarios for Mobile Terminated SMS while GPRS Attached
8 a.If the subscriber is both GSM CS attached as well as GPRS attached, then the IIF shall act like a
9 GSM SMS-SC.
10 The scenarios that follow only show the SMS delivery via GPRS.
11 4.13.3.1.1 Successful Mobile Terminated ANSI-136 41 SMS (CMT) Mapped to GSM SMS
SMS
Delivery
a
SMSREQUEST
b
smsrequest
c
SMDPP (CMT)
d
FORWARD SHORT MESSAGE
e
SMS Delivery
f
SMS Delivery Ack
g
Forward Short Message
h
smdpp [ACK]
i
12
13 Figure 122: Successful Mobile Terminating ANSI-136 41 SMS (CMT) mapped to GSM SMS
14
15 a. The ANSI-136 41 Message Center (MC) receives a short message for a specific subscriber.
16 Note: This step is shown for completeness only and is not repeated in subsequent call flows.
17
18 b. The Message Center sends an SMS Request message to the ANSI-41 HLR of the short message
19 recipient to request a routing address for delivering the short message to that subscriber.
20
21 c. Since the subscriber has a current valid location stored in the HLR, the HLR returns it to the MC
22 in the SMS Request Return Result message.
23
24 d. The Message Center then sends a Short Message Delivery Point to Point message to the IIF,
25 which is seen as the current serving ANSI-41 MSC/VLR for that subscriber. Note that in this case,
1 the format used by the MC is the CMT format (Cellular Messaging Transport). Note that
2 alternatively, the ANSI-136 41 MC could translate the original CMT SMS to GHOST/WEMT
3 format before sending it to the IIF if the IIF only supports the GHOST/WEMT format. In this case
4 the IIF would convert ANSI-136 41 GHOST/WEMT into GSM format (see Section 4.13.3.1.2)
5 instead of ANSI-136 41 CMT into GSM format.
6
7 e. Upon reception of the Short Message Delivery Point to Point message from the ANSI-136 41 MC,
8 the IIF originates a FORWARD SHORT MESSAGE to the SGSN after having translated the short
9 message into GSM format. The IIF is then acting as a GSM SMS-GMSC.
10
11 f. The SGSN sends the short message to the mobile station. Note: This step is shown for
12 completeness only and is not repeated in subsequent call flows.
13
14 g. The mobile station acknowledges the delivery of the short message. Note: This step is shown for
15 completeness only and is not repeated in subsequent call flows.
16
17 h. The SGSN sends the result of the Forward Short Message to the IIF.
18
19 i. The IIF sends the result of the Short Message Delivery Point to Point to the ANSI-136 41
20 Message Center.
21
22
23
1
2 4.13.3.1.2 Successful Mobile Terminating ANSI-136 41 SMS (GHOST/WEMT) Mapped to GSM
ANSI-41 GSM
SMSREQ
a
smsreq
b
SMDPP
c
FORWARD SHORT MESSAGE
d
Forward Short Message
e
smdpp [ACK]
f
3 SMS
4
5 Figure 123: Successful Mobile Terminating ANSI-136 41 SMS (GHOST/WEMT) mapped to GSM
6 SMS
7
8 a. The ANSI-41 MC sends a SMSRequest Invoke message to the HLR, including as arguments the
9 MIN (MSISDN) of the mobile station and SMS Notification Indicator.
10 b. The HLR determines if the message shall be forwarded to the MS and sends a response back in
11 a SMSRequest Return Result, with the SMS_Address set to the IIF address (point code or E.164
12 address).
13 c. The MC formats a GHOST/WEMT teleservice and sends it to the IIF in an SMDPP message.
14 d. Upon receipt of the SMDPP message, the IIF builds a FORWARD SHORT MESSAGE, stripping
15 off the GHOST/WEMT teleservice and using the encapsulated GSM SMS transfer PDU, and
16 routes it to the SGSN as a first choice. Alternatively, the IIF could send the FSM to the GSM MSC
17 (if the 03.40 MNRC flag is not set).
18 e. The SGSN packages the GSM SMS RP-DATA into a CP-DATA message and delivers it across
19 the GSM air interface to the mobile station. The mobile station acknowledges receipt of the CP-
20 DATA and RP-DATA messages via CP-ACK and CP-ACK[RP-ACK], respectively. Upon
21 successful receipt of the RP-ACK, the SGSN shall send a positive acknowledgement Forward
22 Short Message back to the IIF.
23 f. The IIF maps the received Forward Short Message into a SMDPP Return Result and sends it to
24 the MC.
2 The following scenario applies to short message delivery failure in either CMT or GHOST/WEMT
ANSI-41 GSM
SMSREQ
a
smsreq
b
SMDPP
c
FORWARD SHORT MESSAGE
d
Forward Short Message
e
smdpp [NAK]
f
3 format.
4
5 Figure 124: Unsuccessful Mobile Terminated Delivery (Failure at SGSN)
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 or a CMT short message and sends it to the IIF in
13 an SMDPP message.
14 d. Upon receipt of the SMDPP message, the IIF builds a FORWARD SHORT MESSAGE, stripping
15 off the GHOST/WEMT teleservice and using the encapsulated GSM SMS transfer PDU, and
16 routes it to the SGSN. If the message received is in the CMT format, the IIF maps this information
17 into a short message in GSM format.
18 e. The SGSN packages the GSM SMS RP-DATA into a CP-DATA message and delivers it across
19 the GSM air interface to the mobile station. The mobile station negatively acknowledges either
20 the CP-DATA message or the RP-DATA message. The SGSN sends a negative
21 acknowledgement Forward Short Message (with appropriate cause value) 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. In addition, the IIF sets one of the GSM SMS flags as defined in the GSM 03.40
24 specification [4] according to the error cause received from the SGSN; that is, the Mobile
25 Subscriber Not GPRS Reachable Flag (MNRG) shall be set if the error cause is “absent
1 subscriber”, and the Memory Capacity Exceeded Flag (MCEF) shall be set if the error cause is
2 “memory capacity exceeded”. Additionally, the IIF emulating the ANSI-41 MSC shall set and
3 store the SMS Delivery Pending flag with the MC parameters received in the SMDPP (for later
4 delivery in the SMSNOT) – note that this “SMS Delivery Pending” flag/data serves the same
5 purpose as a GSM HLR’s “Message Waiting Data” flag/data. [However, note that if an ANSI-41
6 REGCAN is received from the ANSI-41 HLR before the SMS Delivery Pending Flag is cleared,
7 then the regcanc response shall contain the SMS_MessageWaitingIndicator, and all flags are
8 cleared (i.e., MNRG, MNRF, MCEF, and SMS Delivery Pending Flag)].
9 4.13.3.1.4 Unsuccessful Mobile Terminated Delivery (Failure at IIF)
10 The following scenario applies to short message delivery failure in either CMT or GHOST/WEMT
11 format.
12
ANSI-41 GSM
SMSREQ
a
smsreq
b
SMDPP
c
smdpp [NAK]
d
13
14 Figure 125: Unsuccessful Mobile Terminated Delivery (Failure at IIF)
15
16 a. The ANSI-41 MC sends a SMSRequest Invoke message to the HLR, including as arguments the
17 MIN (MSISDN) or IMSI of the mobile station and SMS Notification Indicator.
18 b. The HLR determines if the message shall be forwarded to the MS and sends a response back in
19 a SMSRequest Return Result, with the SMS_Address set to the IIF address (point code or E.164
20 address).
21 c. The MC formats a GHOST/WEMT teleservice and sends it to the IIF in an SMDPP message.
22 d. Upon receipt of the SMDPP message, the IIF examines the GSM 03.40 HLR flags (if “both MNRC
23 and MNRG” or ”MCEF” is set) and determines that the MS is unable to receive a Short Message.
24 The IIF indicates this fact in the SMDPP Return Result. It includes the cause for the failure in the
25 SMS_CauseCode parameter of the SMDPP Return Result. The IIF shall set & store the SMS
26 Delivery Pending Flag with the data received in the SMDPP message (for later delivery in the
27 SMSNOT). If the 03.40 flag is set to MNRG and if the flag is not set to MNRC, then the SMDPP
28 shall be delivered to the GSM MSC as described in GAIT phase 1. If 03.40 flag is set to MNRC
29 and not MNRG nor MCEF, then SMS delivery is possible through the SGSN as shown in section
30 4.13.3.1.
31
1
2 4.13.3.1.5 Alerting for an ANSI-136 41 Subscriber for GPRS in GSM Foreign Mode
3 The following scenario applies to short messages originated in either CMT or GHOST/WEMT format.
ANSI-41 GSM
READY FOR SM
a
SMSNOT
b
smsnot
c
ready for SM
d
4
5 Figure 126: Alerting for an ANSI-136 41 Subscriber in GSM Foreign Mode
6 a. The SGSN sends a READY FOR SM to the IIF, including as arguments the IMSI, Alert Reason
7 Indicator and Alert Reason. Note: The SMS notification can also be triggered when the SGSN
8 sends an Update GPRS Location. This happens when an MS for whom messages are pending
9 re-attaches or performs an inter-SGSN routing area update, the SGSN sends an Update GPRS
10 Location message to the IIF.
11 b. If the IIF has the SMS Delivery Pending Flag set, and if the MCEF flag is not set, then the IIF
12 sends a SMSNOT to each of the subscriber’s MCs stored with the SMS Delivery Pending Flag.
13 The SMSNOT shall contain; the MIN (MSISDN) as mapped from the IMSI, ESN, and
14 SMS_Address containing the IIF address.
15 c. The MC sends a SMSNOT Return Result to the IIF, then the IIF clears the SMS Delivery Pending
16 Flag, then proceeds to send the mobile station a mobile terminated CMT or GHOST/WEMT
17 teleservice message.
18 d. If the IIF has GSM 03.40 flags set, then these flags shall be cleared according to the “alert
19 reason”; that is, if the “alert reason” is “memory available”, then both the MCEF and MNRG flags
20 are cleared, and if the “alert reason” is “MS present”, then the MNRG flag is cleared. If the
21 UpdateGPRSLocation is received, then the MNRG flag is cleared. The IIF sends a Ready for SM
22 response to the SGSN with no arguments.
23
24
1 4.13.4 Message Flows for Mobile Originated SMS when operating GPRS in
2 GSM Foreign Mode
3 This section describes the message flows for originating a short message to the subscriber’s home
4 message center when the mobile station is operating GPRS in GSM Foreign Mode. The following
5 scenarios apply to short messages delivered to the MC in either CMT or GHOST/WEMT format.
6 4.13.4.1 Successful Mobile Originated SMS to MC
GSM ANSI-41
SMDPP
b
smdpp [ACK]
c
Forward Short Message
d
7
8 Figure 127: Successful Mobile Originated Delivery
9
10 a. The SGSN originates a FORWARD SHORT MESSAGE to the address provided by the MS (i.e.,
11 IIF), including as arguments the Service Center Address, MSISDN and GSM SMS-SUBMIT PDU.
12 b. Upon receipt of the FORWARD SHORT MESSAGE, the IIF builds an ANSI-41 SMDPP message,
13 encapsulating the GSM SMS transfer PDU in a GHOST/WEMT teleservice, and routes it to the
14 originator’s home MC. The IIF can also map the Forward Short Message into a CMT short
15 message.
16 c. The MC sends a positive acknowledgement SMDPP Return Result to the IIF.
17 d. The IIF maps the received SMDPP Return Result to a Forward Short Message, and sends it to
18 the SGSN.
19
GSM ANSI-41
SMDPP
b
smdpp [NAK]
c
Forward Short Message
d
GSM ANSI-41
2
3 Figure 129: Unsuccessful Mobile Originated (Failure at IIF)
4
5 a. The SGSN originates a FORWARD SHORT MESSAGE to the address provided by the MS (i.e.,
6 IIF), including as arguments the Service Centre Address, MSISDN and GSM SMS-SUBMIT PDU.
7 b. Upon receipt of the FORWARD SHORT MESSAGE, the IIF builds a negative acknowledgement
8 Forward Short Message and sends it to the SGSN.
9
10
17
Vmail
Delivery
a
“Message Waiting
Notification”
b
GPRS attach req
UPDATE GPRS c
LOCATION
d
REGNOT
e
regnot (MWNCOUNT,
MWNTYPE)
f
① INSERT_SUB_DATA
g
Insert_sub_data
h
update gprs location
i
GPRS Accept
j
FORW. SHORT
MESSAGE (MWN)
k
SMS Delivery (MWN)
l
SMS Delivery Ack
m
Forw. Short
Message
n
②
3 Figure 130: Indicator in ANSI-41 Registration Notification Return Result mapped to GSM SMS
4 a. The Voice Mail System (VMS) receives a voice mail for a specific subscriber.
5
6 b. The VMS send the “Message Waiting Notification” (MWN) to the ANSI-41 HLR of the voice mail
7 recipient. Note that the interface between the VMS and the ANSI-41 HLR is not standardized in
8 ANSI-41.D [1]. Note also that at that point in time, the subscriber is not registered in any serving
9 system, so the HLR just keeps the information that a voice mail was received.
10
11 c. The Mobile Station accesses a serving system and originates an update location request.
12
13 d. The Update Location is sent from the serving GSM MSC/VLR to the IIF, seen as the GSM HLR
14 for that subscriber.
15
16 e. The IIF sends a Registration Notification to the ANSI-41 HLR of the subscriber.
17
18 f. The ANSI-41 HLR replies with the Registration Notification Return Result containing the
19 “Message Waiting Notification” information that consists of two parameters:
20 MessageWaitingNotificationCount (MWNCOUNT) and MessageWaitingNotificationType
21 (MWNTYPE). For a description of these parameters, refer to the ANSI-41.D specifications,
22 sections 6.5.2.78 and 6.5.2.79 [1].
1
2 ➀At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification is to
3 be delivered to the Mobile Station.
4
5 g. The IIF sends Insert Subscriber Data to the serving GSM SGSN. Note that there could be more
6 than one Insert Subscriber Data message depending on the subscriber profile.
7
8 h. The serving GSM SGSN returns the Insert Subscriber Data result. Note that there could be more
9 than one such result message, one matching every Insert Subscriber Data message.
10
11 i. The IIF completes the location update by sending the Update Location result message to the
12 serving GSM SGSN.
13
14 j. The serving GSM SGSN confirms the update location to the mobile station.
15
16 k. Since the REGNOT return result from event f contained the Message Waiting Notification
17 information, this triggers the IIF to originate an SMS with MWN information by sending Forward
18 Short Message to the serving GSM SGSN. The IIF is then acting as a GSM SMS-GMSC. The IIF
19 is to encode the MWN information in the SMS with three methods, namely, UDH, DCS, and
20 CPHS. Refer to Volume 3 for the encoding details.
21
22 l. The serving GSM SGSN sends the short message with the MWN information to the mobile
23 station.
24
25 m. The mobile station acknowledges the delivery of the short message.
26
27 n. The serving GSM SGSN sends the result of the Forward Short Message to the IIF.
28
29 ➁At this point, the IIF clears the MWN flag. The reception of the Forward Short Message Result
30 without error indicates that the MWN information was delivered successfully to the Mobile Station.
31
32
1
2 4.13.5.2 ANSI-41 Qualification Directive mapped to GSM SMS
.............................................................
Vmail
Delivery
a
“Message Waiting
Notification”
b
QUALDIR(MWNCOUNT,
MWNTYPE)
c
qualdir
①
d
FORW. SHORT
MESSAGE (MWN) e
SMS Delivery (MWN)
f
SMS DeliveryAck g
Forw. Short
Message
h
②
1 f. The serving GSM SGSN sends the short message with the MWN information to the mobile
2 station.
3
4 g. The mobile station acknowledges the delivery of the short message.
5
6 h. The serving GSM SGSN sends the result of the Forward Short Message to the IIF.
7
8 ➁At this point, the IIF clears the MWN flag. The reception of the Forward Short Message Result
9 without error indicates that the MWN information was delivered successfully to the Mobile Station.
10 4.13.5.3 Handling at SMS delivery failure at the SGSN or at the Mobile Station
11 The IIF is to keep a Message Waiting Notification (MWN) flag for each subscriber in its database. In
12 the event of a failure to deliver a short message with MWN to the mobile station, the IIF is to keep the
13 MWN flag set. Another Forward Short Message with MWN information shall be sent, triggered by the
14 reception of a subsequent GSM Update Location message, a Ready for Short Message, or a Note
15 MS Present message. This is illustrated in the following diagram.
GSM
IIF SGSN MS
MWN “Information”
a
FORW. SHORT
① MSG (MWN) – V3 b
SMS Delivery (MWN)
c
SMS Delivery Error
d
Error, Abort,
Reject, timeout e
Time elapsed
f
UPDATE GPRS LOCATION
g
READY FOR SM
(AlertReason) – V3
h
“Acknowledgement”
i
FORW. SHORT
MSG (MWN) – V3 j
SMS Delivery (MWN)
k
SMS Delivery Ack
Forw. Short l
Message
m
②
n
16
17 Figure 132: Handling at SMS delivery failure at the SGSN or at the MS
1 a. The IIF receives Message Waiting Notification (MWN) information from a Qualification Directive
2 or a Registration Notification Return Result. This was described in Sections 4.13.5.1 and
3 4.13.5.2.
4
5 ➀At this point, the IIF sets the MWN flag. This is an indication that Message Waiting Notification
6 is to be delivered to the Mobile Station.
7
8 b. The IIF originates an SMS with MWN information by sending Forward Short Message using MAP
9 V2 to the serving GSM SGSN. The IIF is then acting as a GSM SMS-GMSC. The IIF is to encode
10 the MWN information in the SMS with three methods, namely, UDH, DCS, and CPHS. Refer to
11 Volume 3 for the encoding details.
12
13 c. The serving GSM SGSN may attempt to deliver the short message or may immediately find out
14 that there is an error and reply (step e below) to the IIF.
15
16 d. The Mobile Station returns an error message to the SMS delivery.
17
18 e. The serving GSM SGSN sends an Error, Abort or Reject message to the IIF, either resulting from
19 the reception of an error message from the MS or from an internal event such as an error or a
20 timeout. Note also, that a timeout may also occur in the IIF itself. Note that this may result in the
21 IIF setting the GSM 03.40 MNRF/MNRG/MCEF flag depending on the error cause received (see
22 section 4.13.3.1.3 “Unsuccessful Mobile Terminated Delivery (Failure at SGSN)”.
23
24 f. Time elapsed.
25
26 g. A new serving GSM SGSN sends an Update GPRS Location message to the IIF acting as a GSM
27 HLR for that subscriber. Note that the normal Update Location sequence is not shown in this
28 diagram. Or it could be a
29
30 h. Ready for Short Message (MAP V3)
31
32
33 i. The IIF shall reply with the corresponding acknowledgement message. Upon receipt of g, h, or i
34 above, the procedures in section 4.13.3.1.5 “Alerting for an ANSI-136 41 Subscriber for GPRS in
35 GSM Foreign Mode” apply (GSM 03.40 flags may be cleared and the SMSNOT may be sent to
36 the MC if appropriate).
37
38 j. Triggered by event g, h, or i above, the IIF originates a new Forward Short Message with MWN
39 information to the serving GSM SGSN. The IIF is to encode the MWN information in the SMS with
40 three methods, namely, UDH, DCS, and CPHS.
41
42 k. The serving GSM SGSN sends the short message with the MWN information to the mobile
43 station.
44
45 l. The mobile station acknowledges the delivery of the short message.
46
47 m. The serving GSM SGSN sends the result of the Forward Short Message to the IIF.
48
49
50 ➁At this point, the IIF clears the MWN flag. The reception of the Forward Short Message Result
51 without error indicates that the MWN information was delivered successfully to the Mobile Station.
52
53
5
6 4.13.6.1.1 Call Delivery to ANSI-136 41 Subscriber Roaming on a GSM/GPRS Network
GSM ANSI
a
Incoming call
LOCREQ
b
ROUTEREQ c
PRN d
prn e
routereq f
locreq g
1 e. The serving GSM MSC/VLR responds with a prn to the PRN operation providing a temporary
2 routing number.
3 f. The IIF forwards this number to the ANSI-41 HLR in the routereq.
4 g. The ANSI-41 HLR forwards a locreq to the O-MSC with the temporary routing number.
5 h. The O-MSC proceeds to contact the serving GSM MSC/VLR exchanging ISUP signaling for call
6 setup.
7 i. The serving GSM MSC/VLR realizes that the MS is actually attached to an SGSN. So the GSM
8 serving MSC/VLR sends a BSSAP+PAGING-REQUEST to the SGSN.
9 j. The SGSN executes a Paging procedure for circuit services.
10 k. The MS sends a SUSPEND REQ to the BSS that may be forwarded to the SGSN. At this point,
11 the MS can respond to the page via GSM cell sites to the serving GSM MSC/VLR.
12
3 The following scenario describes the case where a subscriber in GSM foreign mode is roaming in a
4 GPRS network. The MS is attached for GPRS-only services. The IIF has already registered itself (as
5 an ANSI-41 MSC) with the ANSI-41 HLR. Since the MS is attached for GPRS-only service, incoming
6 calls are not deliverable to the subscriber. This scenario attempts to describe what happens in the
7 case of an incoming call to an MS attached for GPRS services only.
GSM ANSI
Incoming call
a
LOCREQ b
ROUTEREQ c
routereq d
locreq e
FSM f
SMS Exchange
g
fsm
h
8
9 Figure 134: MS Notification of a “Missed” Call via SMS
10
11 a. The O-MSC receives an incoming call for the subscriber roaming in the GSM network
12 b. The O-MSC sends the HLR a LOCREQ
13 c. The HLR has the address of the IIF (acting as an ANSI-41 MSC) and sends a ROUTEREQ to the
14 IIF
15 d. The IIF recognizes that fact this is a GAIT subscriber roaming in a GSM network. The IIF, from
16 its dynamic data, sees that the subscriber is attached for GPRS-only services and hence, cannot
17 have call delivery. The IIF sends a routreq with the field “AccessDeniedReason” set to
18 “Unavailable” or “No Page Response”.
19 e. The HLR returns a locreq to the O-MSC. At this point, the calling party may receive secondary
20 treatment.
1 f. The IIF contains the functionality to act as an SMS-SC. In this case, the IIF has the calling party
2 DN available (from the ROUTEREQ message). The IIF proceeds to act as an SMS-SC and
3 sends an FSM to the SGSN requesting the SGSN to deliver an SMS message containing the
4 calling party’s DN to the MS.
5 g. The SGSN sends the MS the SMS message containing the DN of the calling party and the MS
6 acknowledges receipt of the SMS message.
7 h. The SGSN acknowledges the request and sends back an fsm.
8
2 The network requested PDP Context Activation procedure allows the GGSN to initiate the activation
3 of a PDP context when a data packet arrives for a particular PDP address and no PDP context has
4 been previously established.
5
PDP PDU
a
SRI for GPRS
b
SRI for GPRS Ack
c
PDU Notification Request
d
PDU Notification Response
e
Request PDP context Activation
f
Activate PDP context Request
g
Send Auth Info
h
Send Auth Info Ack
i
2 If the PDP context requested by the GGSN cannot be established, the IIF in conjunction with the
3 SGSN and GGSN may perform the Protection and Mobile User Activity Procedures as described in
4 GSM 03.60 [10]. The IIF acting as a GPRS HLR shall follow the same procedures as the GSM HLR.
11
1 Annex A (informative)
2 The following is an example of some of the timers defined in existing ANSI-41 and GSM
3 specifications.
4 As an example, the GSM timer controlling, the Update Location Request is defined to be in the range
5 15s to 30s whereas the equivalent ANSI-41 timer controlling the REGNOT is defined to be a default
6 value of 12s.
7
ANSI-41 GSM
HLR MSC/ MSC/
AC IIF VLR VLR
Location area update (IMSI)
a
SEND_AUTH_INFO (IMSI)
b
AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC)
c
AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC)
d
ART ART
Authreq (SSD, ESN) e
Authreq (SSD, ESN)
asreport[]
1
2 d) The HLR forwards the AUTHREQ to the AC.
3
4 e) The AC determines that the subscriber is roaming in a GSM system. The AC includes the SSD
5 parameter in the authreq sent to the HLR. The ESN parameter is set to the indicated MS’s ESN.
6
7 f) The HLR forwards the authreq to the IIF.
8
9 g) The IIF stores the received SSD and ESN. The IIF computes one or more groups of GSM triplets using
10 the subscriber’s SSD. The IIF sends a SEND_AUTHENTICATION_INFO ack to the GSM system and
11 includes the groups of triplets.
12
13 h) The GSM system issues a random challenge to the MS
14
15 i) The MS responds to the challenge with the computed response.
16
17 j) The GSM system compares the response received from the MS with the expected response. In this
18 scenario, the response is equal to the expected response. The GSM system sends a
19 UPDATE_LOCATION to the IIF. The IMSI is used to identify the MS.
20
21 k) The IIF sends an ASREPORT to the HLR associated with the MS. The UCHALRPT parameter is set
22 to indicate Unique Challenge successful.
23
24 l) The HLR forwards the ASREPORT to the AC.
25
26 m) The AC sends an asreport to the HLR.
27
28 n) The HLR forwards the asreport to the IIF.
29
30 o) The IIF sends a REGNOT to the HLR
31
32 p) The HLR sends a regnot to the IIF with the subscriber’s service profile
33
34 q) The IIF sends an INSERT_SUBSCRIBER_DATA to the GSM system.
35
36 r) The GSM systems sends an INSERT_SUBSCRIBER_DATA ack to the IIF.
37
38 s) The IIF sends an LOCATION_UPDATE ack to the GSM system.
39
40 t) The GSM system sends a location area update ack to the MS.
41
ANSI-41 GSM
HLR MSC/ MSC/
AC IIF VLR VLR
Location area update (IMSI)
a
SEND_AUTH_INFO (IMSI)
b
AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC)
c
AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC)
d
ART ART
Authreq (SSD, ESN) e
Authreq (SSD, ESN)
asreport[DENACC]
AUTHENTICATION_FAILURE
o
5
6 Figure 137 - Authentication Failure on Initial Access in GSM System
ANSI-41 GSM
HLR MSC/ MSC/
AC IIF VLR VLR
Location area update (IMSI)
a
SEND_AUTH_INFO (IMSI)
b
AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC)
c
AUTHREQ (MSCID, SYSCAP, MSID, ESN, SYSAC)
d
ART ART
Authreq (SSD, ESN) e
Authreq (SSD, ESN)
timer expiry k
ASREPORT (MSCID, MSID, UCHALRPT)
l
asreport[DENACC]
o
7
8 Figure 138 - Authentication Failure on Initial Access in GSM System – Authentication
9 Failure Message Not Supported
10
11 a-i. Same as Scenario 5.Y.1, Steps a-i.
12
13 j) The GSM system compares the response received from the MS with the expected response. In this
14 scenario, the response does equal to the expected response. The GSM system compares the response
15 received from the MS with the expected response. In this scenario, the response does equal to the
16 expected response. The GSM system sends a location area update reject to the MS.
17
18 k) An IIF timer expires when no message for the MS is received from the GSM system.
19
1 l) The IIF sends an ASREPORT to the HLR associated with the MS. The UCHALRPT parameter is set
2 to indicate Unique Challenge failed.
3
4 m) The HLR forwards the ASREPORT to the AC.
5
6 n) The AC includes the DENACC parameter and sends an asreport to the HLR.
7
8 o) The HLR forwards the asreport to the IIF. The IIF removes the SSD, ESN and other information stored
9 for the MS.
10
11
ANSI-41 GSM
HLR MSC/ MSC/
AC IIF VLR VLR
SEND_AUTHENTICATION_INFO (IMSI)
a
SEND_AUTH_INFO ack (AuthenticationSetList)
b
1 Abstract
2
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 interworking and
5 interoperability functionality of the services, information flows, and message mappings are
6 specified. This standard consists of four Volumes:
7
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 3.
14
i
N.S0028
ii
N.S0028
2 Contents
3
4 ABSTRACT .......................................................................................................................................I
6 CONTENTS .....................................................................................................................................III
9 FOREWORD................................................................................................................................ XXII
10 1 INTRODUCTION ........................................................................................................................1
11 1.1 General............................................................................................................................................... 1
12 1.2 Purpose............................................................................................................................................... 1
15 2 REFERENCES...........................................................................................................................3
19 4 MESSAGE MAPPINGS............................................................................................................10
iii
N.S0028
19 ANNEX A SHORT MESSAGE SERVICE PROCEDURES WITHIN AN ANSI-136 NETWORK ...... 186
34 ABSTRACT .......................................................................................................................................I
36 CONTENTS .....................................................................................................................................III
iv
N.S0028
2 FOREWORD................................................................................................................................. XIII
3 1 INTRODUCTION ........................................................................................................................1
6 1.3 Scope.....................................................................................................................................1
7 1.4 Organization..........................................................................................................................1
8 2 REFERENCES...........................................................................................................................3
12 4 MESSAGE MAPPINGS..............................................................................................................9
v
N.S0028
5 ANNEX A SHORT MESSAGE SERVICE PROCEDURES WITHIN AN ANSI-136 NETWORK ...... 181
20
vi
N.S0028
2 List of Tables
3
4 Table 1: Location Updating in GSM Foreign Mode Message Mapping........................................13
20 Table 16: Provide Roaming Number Response ↔ Routreq Return Result Parameter
21 Mapping ...................................................................................................................31
24 Table 18: Routreq Return Error to Provide Roaming Number Response Error Mapping
25 (GSM Foreign mode)................................................................................................32
29 Table 22: PRN response User Error to routreq Return Error Mapping .......................................38
vii
N.S0028
1 Table 23: PRN Response Provider Error to routereq Return Error Mapping................................38
2 Table 24: RoutingRequest Return Result to User Error in the PRN response Error Mapping ......39
3 Table 25: Routing Request Return Error to PRN User Error Mapping.........................................39
4 Table 26: ROUTEREQ Return Result to Provide Roaming Number Response parameter
5 mapping (Option 1)...................................................................................................41
6 Table 27: ROUTREQ Return Result to Provide Roaming Number Response Parameter
7 Mapping (Option 2)...................................................................................................42
8 Table 28: Return Error to User Error in the PRN response Error Mapping ..................................43
9 Table 29: Optimal Routing for Late Call Forwarding Message Mapping......................................46
23 Table 43: Supplementary Service Activation and Deactivation Message Mapping ......................56
viii
N.S0028
17 Table 60: Register SS Response ↔ Feature Request Return Result Parameter Mapping ..........74
25 Table 68: FeatureRequest Return Result to User Error in the Register SS Response
26 mapping ...................................................................................................................82
29 Table 71: Erase SS Response ↔ Feature Request Return Result parameter mapping ..............86
ix
N.S0028
6 Table 79: FeatureRequest Return Result to Register SS Response User Error ..........................93
12 Table 83: Routing Request ↔ Provide Roaming Number Request (Network Provided
13 number) Parmater Mapping......................................................................................99
14 Table 84: Routing Request ↔ Provide Roaming Number Request (User Provided number)
15 Parameter Mapping................................................................................................100
16 Table 85: Routing Request ↔ Provide Roaming Number Request (Two calling party
17 numbers) Parameter Mapping ................................................................................101
21 Table 88: Mapping of GSM MAP Messages ↔ ANSI MAP Messages (Subscriber Data
22 Modification)...........................................................................................................107
27 Table 93: Forwarding Information List to Calling Features Indicator Parameter Mapping ..........112
29 Table 95: Call Barring Information List to Origination Indicator Parameter Mapping ..................114
30 Table 96: SSData List to Calling Features Indicator Parameter Mapping ..................................117
x
N.S0028
1 Table 98: Operator Determined Barring HPLMN data to Origination Indicator Parameter
2 Mapping .................................................................................................................121
3 Table 99: Operator Determined Barring HPLMN data to Restriction digits Parameter
4 Mapping .................................................................................................................121
5 Table 100: Call Barring Information List to SMS Origination Restrictions Parameter
6 Mapping .................................................................................................................122
7 Table 101: Call Barring Information List to SMS Termination Restrictions Parameter
8 Mapping .................................................................................................................123
9 Table 102: Call Barring Information List to Termination Restriction Code Parameter
10 Mapping .................................................................................................................124
11 Table 103: SSData List to SMS Origination Restrictions Parameter Mapping ...........................125
16 If the response to FSM indicates a failure in the delivery of the short message, the IIF shall
17 map the cause value received to a corresponding SMS_CauseCode value in
18 the SMDPP Return Result, as described in.............................................................132
19 Table 107: Short Message Service in GSM Foreign Mode (for CMT) Message Mapping ..........134
20 Table 108: Short Message Service in ANSI-41 Foreign Mode (for CMT) Message Mapping ....134
21 Table 109: SMDPP to MT_Forward Short Message Parameter Mapping for GSM Foreign
22 Mode......................................................................................................................135
23 Table 110: MT_Forward Short Message to SMDPP Parameter Mapping for ANSI-41
24 Foreign Mode.........................................................................................................136
29 Table 113: SMS_Bearer Data in Mobile Terminating SMDPP Parameter Encoding for
30 ANSI-41 Foreign Mode...........................................................................................139
xi
N.S0028
2 If the User Error parameter is populated in the GSM_FSM_ACK, then map this value into
3 the SMS_CauseCode according to.........................................................................151
4 Next, it populates the stored originating SMSC address and transaction ID. If the User
5 Error parameter is populated in GSM_FSM_ACK, then this value is mapped into
6 the SMS_CauseCode according to.........................................................................153
7 Table 118: Short Message Service (for GHOST or WEMT) Message Mapping.........................153
8 Table 119: Alerting for an ANSI-41 Subscriber in GSM Foreign Mode Parameter Mapping.......154
9 Table 120: Alerting for a GSM Subscriber in ANSI-41 Foreign Mode Parameter Mapping ........155
12 Table 122: Forward Short Message to SMDPP for Mobile Terminated GHOST/WEMT
13 Teleservice Parameter Mapping in ANSI Foreign Mode ..........................................156
14 Table 123: Forward Short Message to SMDPP for Mobile Originated GHOST/WEMT in
15 GSM Foreign Mode Parameter Mapping.................................................................157
16 Table 124: SMDPP to Forward Short Message for Mobile Originated GHOST/WEMT
17 Teleservice Parameter Mapping in ANSI-41 Foreign Mode .....................................158
19 The IIF is responsible for mapping GSM MAP_FSM_ACK Return Errors to ANSI-41
20 SMS_CauseCodes according to.............................................................................159
22 Table 127: Message Waiting Notification in GSM Foreign Mode Message Mapping .................163
23 Table 128: Message Waiting Notification in ANSI-41 Foreign Mode Message Mapping ............163
24 Table 129: Regnot to Forward Short Message for Message Waiting Notification Parameter
25 Mapping .................................................................................................................164
26 Table 130: QUALDIR to Forward Short Message for Message Waiting Notification
27 Parameter Mapping................................................................................................164
28 Table 131: Forward Short Message to QUALDIR for Message Waiting Notification
29 Parameter Mapping................................................................................................165
30 Table 132: Forward Short Message to SMDPP for Message Waiting Notification Parameter
31 Mapping .................................................................................................................165
xii
N.S0028
4 Table 137: Location Updating GPRS in GSM Foreign Mode Message Mapping .......................171
11 If the response to FSM indicates a failure in the delivery of the short message, the IIF shall
12 map the cause value received to a corresponding SMS_CauseCode value in
13 the SMDPP Return Result, as described in.............................................................181
14 Table 142: Alerting for an ANSI-41 Subscriber for GPRS in GSM Foreign Mode Parameter
15 Mapping .................................................................................................................182
16 If the User Error parameter is populated in the GSM_FSM_ACK, then map this value into
17 the SMS_CauseCode according to.........................................................................183
24 Table 149: RP-ERROR Cause to R-Cause for Mobile Station Response to Mobile
25 Terminated Transfer Attempt. .................................................................................197
27 Table 151: ANSI-136 R-Cause Code to RP-ERROR Cause Mapping within the Mobile
28 Station ...................................................................................................................198
xiii
N.S0028
14 Table 16: Provide Roaming Number Response ↔ Routreq Return Result Parameter
15 Mapping ...................................................................................................................30
18 Table 18: Routreq Return Error to Provide Roaming Number Response Error Mapping
19 (GSM Foreign mode)................................................................................................30
23 Table 22: PRN response User Error to routreq Return Error Mapping .......................................36
24 Table 23: PRN Response Provider Error to routereq Return Error Mapping................................36
25 Table 24: RoutingRequest Return Result to User Error in the PRN response Error Mapping ......37
26 Table 25: Routing Request Return Error to PRN User Error Mapping.........................................37
27 Table 26: ROUTEREQ Return Result to Provide Roaming Number Response parameter
28 mapping (Option 1)...................................................................................................39
29 Table 27: ROUTREQ Return Result to Provide Roaming Number Response Parameter
30 Mapping (Option 2)...................................................................................................40
31 Table 28: Return Error to User Error in the PRN response Error Mapping ..................................41
xiv
N.S0028
1 Table 29: Optimal Routing for Late Call Forwarding Message Mapping......................................44
15 Table 43: Supplementary Service Activation and Deactivation Message Mapping ......................54
xv
N.S0028
9 Table 60: Register SS Response ↔ Feature Request Return Result Parameter Mapping ..........72
17 Table 68: FeatureRequest Return Result to User Error in the Register SS Response
18 mapping ...................................................................................................................80
21 Table 71: Erase SS Response ↔ Feature Request Return Result parameter mapping ..............84
29 Table 79: FeatureRequest Return Result to Register SS Response User Error ..........................91
xvi
N.S0028
5 Table 83: Routing Request ↔ Provide Roaming Number Request (Network Provided
6 number) Parmater Mapping......................................................................................97
7 Table 84: Routing Request ↔ Provide Roaming Number Request (User Provided number)
8 Parameter Mapping..................................................................................................98
9 Table 85: Routing Request ↔ Provide Roaming Number Request (Two calling party
10 numbers) Parameter Mapping ..................................................................................99
14 Table 88: Mapping of GSM MAP Messages ↔ ANSI MAP Messages (Subscriber Data
15 Modification)...........................................................................................................105
20 Table 93: Forwarding Information List to Calling Features Indicator Parameter Mapping ..........109
22 Table 95: Call Barring Information List to Origination Indicator Parameter Mapping ..................111
23 Table 96: SSData List to Calling Features Indicator Parameter Mapping ..................................114
26 Table 98: Operator Determined Barring HPLMN data to Origination Indicator Parameter
27 Mapping .................................................................................................................118
28 Table 99: Operator Determined Barring HPLMN data to Restriction digits Parameter
29 Mapping .................................................................................................................118
30 Table 100: Call Barring Information List to SMS Origination Restrictions Parameter
31 Mapping .................................................................................................................119
32 Table 101: Call Barring Information List to SMS Termination Restrictions Parameter
33 Mapping .................................................................................................................120
xvii
N.S0028
1 Table 102: Call Barring Information List to Termination Restriction Code Parameter
2 Mapping .................................................................................................................121
3 Table 103: SSData List to SMS Origination Restrictions Parameter Mapping ...........................122
8 If the response to FSM indicates a failure in the delivery of the short message, the IIF shall
9 map the cause value received to a corresponding SMS_CauseCode value in
10 the SMDPP Return Result, as described in.............................................................129
11 Table 107: Short Message Service in GSM Foreign Mode (for CMT) Message Mapping ..........131
12 Table 108: Short Message Service in ANSI-136 Foreign Mode (for CMT) Message
13 Mapping .................................................................................................................131
14 Table 109: SMDPP to MT_Forward Short Message Parameter Mapping for GSM Foreign
15 Mode......................................................................................................................132
16 Table 110: MT_Forward Short Message to SMDPP Parameter Mapping for ANSI-41
17 Foreign Mode.........................................................................................................133
22 Table 113: SMS_Bearer Data in Mobile Terminating SMDPP Parameter Encoding for
23 ANSI-41 Foreign Mode...........................................................................................135
31 If the User Error parameter is populated in the GSM_FSM_ACK, then map this value into
32 the SMS_CauseCode according to.........................................................................146
33 Next, it populates the stored originating SMSC address and transaction ID. If the User
34 Error parameter is populated in GSM_FSM_ACK, then this value is mapped into
35 the SMS_CauseCode according to.........................................................................148
36 Table 118: Short Message Service (for GHOST) Message Mapping ........................................148
xviii
N.S0028
1 Table 119: Alerting for an ANSI-136 Subscriber in GSM Foreign Mode Parameter Mapping.....149
2 Table 120: Alerting for a GSM Subscriber in ANSI-136 Foreign Mode Parameter Mapping.......150
3 Table 121: SMDPP to Forward Short Message for Mobile Terminated GHOST Teleservice
4 Parameter Mapping in GSM Foreign Mode.............................................................150
5 Table 122: Forward Short Message to SMDPP for Mobile Terminated GHOST Teleservice
6 Parameter Mapping in ANSI Foreign Mode.............................................................151
7 Table 123: Forward Short Message to SMDPP for Mobile Originated GHOST in GSM
8 Foreign Mode Parameter Mapping .........................................................................152
9 Table 124: SMDPP to Forward Short Message for Mobile Originated GHOST Teleservice
10 Parameter Mapping in ANSI-41 Foreign Mode........................................................153
12 The IIF is responsible for mapping GSM MAP_FSM_ACK Return Errors to ANSI-41
13 SMS_CauseCodes according to.............................................................................154
15 Table 127: Message Waiting Notification in GSM Foreign Mode Message Mapping .................158
16 Table 128: Message Waiting Notification in ANSI-136 Foreign Mode Message Mapping ..........158
17 Table 129: Regnot to Forward Short Message for Message Waiting Notification Parameter
18 Mapping .................................................................................................................159
19 Table 130: QUALDIR to Forward Short Message for Message Waiting Notification
20 Parameter Mapping................................................................................................159
21 Table 131: Forward Short Message to QUALDIR for Message Waiting Notification
22 Parameter Mapping................................................................................................160
23 Table 132: Forward Short Message to SMDPP for Message Waiting Notification Parameter
24 Mapping .................................................................................................................160
32 Table 137: Location Updating GPRS in GSM Foreign Mode Message Mapping .......................166
xix
N.S0028
5 Table 142: Alerting for an ANSI-136 Subscriber for GPRS in GSM Foreign Mode
6 Parameter Mapping................................................................................................177
13 Table 149: RP-ERROR Cause to R-Cause for Mobile Station Response to Mobile
14 Terminated Transfer Attempt. .................................................................................192
16 Table 151: ANSI-136 R-Cause Code to RP-ERROR Cause Mapping within the Mobile
17 Station ...................................................................................................................193
18
19
xx
N.S0028
2 List of Figures
3
4 There are no figures in this volume.
xxi
N.S0028
2 Foreword
3
4 This foreword is not part of this standard.
5 This standard addresses the interworking and interoperability between ANSI-41 MAP and GSM
6 based networks in the support of subscribers roaming between networks. The objective of the
7 standard is to achieve fully automatic, two-way interoperability between the heterogeneous
8 networks. Services supported by this standard are described along with the associated information
9 flows and message mappings. However, not all services and associated capabilities of ANSI-41
10 MAP and GSM MAP are supported by this standard. In general the attempt has been to focus on
11 the key subscriber services needed in the market.
12 The focus of this the first release of this standard is on common GSM and ANSI-136 TDMA
13 services and associated network signaling (i.e. ANSI-41 MAP and GSM MAP). A pre-requisite for
14 this interoperability is Multi-mode mobile stations with an enhanced SIM card for roaming between
15 ANSI-136, GSM, and AMPS networks.
16 The first release of the standard did not define or require changes to existing ANSI-41 MAP or GSM
17 MAP to achieve the described interworking and interoperability. However, due to differences
18 between the services and associated capabilities of the MAP protocols, complete and fully
19 transparent interoperability may not have been achieved for some services. Future releases of this
20 standard may require changes to ANSI-41 MAP, GSM MAP and the associated services to achieve
21 full transparency while roaming between the different networks.
22 Additional or alternate service descriptions, information flows, and message mappings may be
23 required to support other air interfaces supported by ANSI-41 MAP (e.g., IS-95, cdmaOne, and
24 cdma2000). This may be accomplished in future release of this standard.
25 Aspects of TIA/EIA-136 Revision C have been incorporated into this standard.
26 Revision A adds the capability of getting GPRS services when roaming in GSM Foreign Mode.
27 Revision B adds two way roaming between GSM and CDMA systems
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 inclusive).
30 The information contained herein may not be exported or re-exported to Cuba, Iran, Iraq, Libya, North Korea,
31 Sudan, or Syria. Contact the Telecommunications Industry Association, Arlington, VA or
32 http://ftp.tiaonline.org/tr-45/tr45ahag/public%20documents
33
34
35
36
37
38
39
40
xxii
N.S0028
1
2
3
4
5
6
7 (This page intentionally left blank.)
xxiii
N.S0028
1 1 Introduction
2
3 1.1 General
4
5 When a subscriber to one network type (e.g., ANSI-41) roams to a network of another type
6 (e.g., GSM), interworking and interoperability functions are required to support roaming and
7 enable service. This standard describes an Interworking and Interoperability Function (IIF) to
8 support this cross-technology roaming between ANSI-41 and GSM networks. The IIF supports
9 a multi-mode mobile station with a removable Subscriber Identity Module (SIM). The standard
10 also defines the required network message mappings between ANSI-41 MAP and GSM MAP to
11 support the mobile terminal and associated services.
12 This standard includes the support of cross-technology roaming from an ANSI-41 based
13 network to a GPRS network. The GPRS network may be coupled with a GSM network. This
14 feature requires enhancement to the Interworking and Interoperability Function (IIF) which
15 supports a multi-mode mobile station and Subscriber Identity Module (SIM) with GPRS
16 functionality.
17 Optionally, IIF may support one way-roaming only from CDMA to GSM network. In this case, all
18 the relevant mapping tables described are applicable only in GSM Foreign Mode and for this
19 scenario they applied as unidirectional only. (Annex C)
20
21 1.2 Purpose
22
23 The purpose for this standard is to define and describe the functions necessary for roaming
24 between ANSI-41 MAP and GSM MAP based networks in the support of roaming subscribers.
25 This includes a capability to allow a subscriber to an ANSI-41 based network (e.g., an ANSI-
26 136 41, TDMA or CDMA native subscriber) with a mobile terminal supporting GPRS service to
27 roam to a GPRS network in GSM Foreign Mode.
28 1.3 Scope
29
30 The scope of this standard are the services, information flows, and message mappings which
31 require interworking and interoperability functional specifications to support roaming between
32 ANSI-41 MAP [6] and GSM MAP [3] networks.
33 The scope of this volume is to describe the processing, messages and parameters for
34 GPRS/GSM and ANSI-41 network interoperability.
35 1.4 Organization
36
37 This standard is organized into the following volumes:
1
N.S0028
2
N.S0028
2 2 References
3
4 [1] GSM 03.18 Version 6.2.0 Release 1997 “ Digital cellular communication system (Phase
5 2+); Basic call handling; Technical realisation”, November 1998, ETSI.
6 [2] GSM 03.79 version 6.2.0 release 1997, “Digital cellular telecommunications system
7 (Phase 2+); Support of Optimal Routeing (SOR) Technical Realisation”.
8 [3] GSM 09.02 Version 6.2.0 Release 1997 “ Digital cellular communication system (Phase
9 2+); Mobile Application Part (MAP) specification”, August 1998, ETSI;
10 [4] GSM 02.60 version 6.3.1 Release 1997 “General Packet Radio Service (GPRS); Service
11 Description, Stage 1”
12 [5] GSM 03.60 version 6.8.0 Release 1997 “General Packet Radio Service (GPRS); Stage
13 2”
14
19 [8] TIA/EIA/IS 737A”IS-41 support for data services for digital terminals (TDMA and CDMA)”
20 [8] TIA/EIA/IS 735 “IS-41 support for IS-95-A (advanced CDMA)”
21 [9] TIA/EIA/TSB58-E “Administration of Parameter Value Assignments for TIA/EIA Spread
22 Spectrum Standards” , January 2002
23 [10] TIA/EIA-95-B - Mobile Station-Base Station Compatibility Standard for Dual-Mode Spread
24 Spectrum Systems; Published October 1998.
25
26 [11] "TIA/EIA-IS-2000-A, cdma2000 Series, March 2000, plus addenda"Mobile Station-Base
27 Station Compatibility Standard for Dual-Mode Spread Spectrum Systems;
28 [12] TIA/EIA-868 – ANSI-41-D Network Based Enhancements to support one-way roaming to
29 GSM, Published TBD. [12]"Enhanced Cryptographic Algorithms, Revision B," TR45AHAG, Published
30 TBD
31
32
33
3
N.S0028
4 3.1 Definitions
5
6 AMPS
7
8 Advanced Mobile Phone Service (AMPS) is the same as ANSI EIA/TIA-553, which is an analog
9 air interface protocol standard for mobile stations and their associated base stations. AMPS
10 networks use ANSI-41 for intersystem signaling.
11
12 ANSI-41
13
14 ANSI-41 is the same as ANSI TIA/EIA-41, which is a network protocol standard to support
15 intersystem operation of cellular networks, such as ANSI-136 networks. ANSI-41 is the North
16 American version of ITU defined MAP. Key intersystem support defined by ANSI-41 includes
17 automatic roaming, intersystem handoff, and intersystem operation, administration, and
18 maintenance. Among other things, ANSI-41 defines the interfaces between MSCs, between the
19 MSC/VLR and the HLR/AC, and between the MSC and the Short Message Service Center
20 (SMS-C) or Teleservice Server (TS).
21
22 ANSI-136
23
24 ANSI-136 is the same as ANSI TIA/EIA-136, which is a TDMA air interface protocol standard
25 for mobile stations and their associated base stations. ANSI-136 is a dual-mode standard that
26 includes digital (TDMA) operation at 800 MHz and 1900 MHz, and analog (AMPS) operation at
27 800 MHz. ANSI-136 networks use ANSI-41 for intersystem signaling.
28
29 ANSI-136 Mode
30
31 ANSI-136 mode indicates the condition or state of a mobile station accessing an ANSI-136
32 network.
33
34 ANSI-136 Foreign Mode
35
36 ANSI-136 foreign mode indicates the condition or state of a GSM native subscriber accessing
37 an ANSI-136 network.
38
39 ANSI-136 Native Mode
40
41 ANSI-136 native mode indicates the condition or state of an ANSI-136 native subscriber
42 accessing an ANSI-136 network.
43
44 ANSI-136 Native Subscriber
45
46 ANSI-136 native subscriber indicates an end user whose primary or home subscription resides
47 in an ANSI-136 network. These subscribers include both home subscribers from the ANSI-136
48 network, as well as roamers from other ANSI-136 networks.
49
50
4
N.S0028
5
N.S0028
1 Global System for Mobile Communications (GSM) defines both air interface and network
2 intersystem protocol standards for mobile stations (MS), base station systems (BSS), and
3 network switching systems (NSS).
4
5 GSM CS attached
6 GSM circuit-switched services attached means that the subscriber is attached to a GSM MSC.
7 This is also referred to as IMSI attached.
8 GSM CS detached
9 GSM circuit-switched services detached means that the subscriber is detached from a GSM
10 MSC. This is also referred to as IMSI detached.
11
12 GSM Mode
13
14 GSM mode indicates the condition or state of a mobile station accessing a GSM network.
15
16 GSM Foreign Mode
17
18 GSM foreign mode indicates the condition or state of an ANSI-136 41 native subscriber
19 accessing a GSM network.
20
21 GSM Native Mode
22
23 GSM native mode indicates the condition or state of a GSM native subscriber accessing a GSM
24 network.
25
26 GSM Native Subscriber
27
28 GSM native subscriber indicates an end user whose primary or home subscription resides in a
29 GSM network. These subscribers include both home subscribers from the GSM network, as
30 well as roamers from other GSM networks.
31
32 Mobile Station
33
34 The mobile equipment and the SIM together make up the mobile station, which is the wireless
35 radiotelephone used by the subscriber.
36
37 Subscriber Identity Module
38 A smart card that plugs into the mobile equipment and that contains the authentication
39 algorithms, and stores service-oriented subscription information.
40
41 3.2 Acronyms
42
43 AC Authentication center
44 ANSI American National Standards Institute
45 BAIC Barring of All Incoming Calls
46 BAOC Barring of All Outgoing Calls
6
N.S0028
7
N.S0028
8
N.S0028
9
N.S0028
2 4 Message Mappings
3
4 The IIF shall perform the translation of messages, parameters and parameter values in
5 accordance with the tables included in this volume of the standard. The following notation is
6 used in accordance with the definitions given in GSM 09.02 [3] and ANSI-41 [6], [7], 0.
7 Within the following tables, the parameters are identified as either being:
8 M Mandatory,
9 C Conditional
10 O Service Provider Optional
11 U Service User Optional
12 The following notation is used in this standard to identify parameters as being syntactically
13 optional but semantically required to be sent by the IIF in order to support interoperability:
14 R Required.
15 Refer to GSM 09.02 [3] and ANSI-41 [6], [7], 0 for a description of the messages, parameters
16 and parameter values.
17 When the IIF receives either a GSM MAP message or an ANSI MAP message, it shall apply
18 the following rules regarding the handling of parameters within those messages:
19 The IIF shall populate mandatory parameters in messages sent by the IIF, regardless
20 of whether mapping of parameters is possible.
21 The IIF may populate optional parameters in messages sent by the IIF, regardless of
22 whether mapping of parameters is possible.
23 All parameters shall be populated in accordance with GSM 09.02 [3] or ANSI-41 [6], [7], 0.
24 Where there is no direct mapping for parameters, a hyphen (‘-‘) has been entered in the
25 corresponding table.
26
10
N.S0028
1 The Location registration procedure is also used to cancel location information held in the
2 network.
11
N.S0028
1 information is different, the IIF shall update the corresponding subscriber record and send an
2 ANSI_MAP_REGCANC to the old VLR. If there is no previously stored location information in
3 the IIF, the corresponding subscriber record is updated. In either case, if the HLR is required to
4 be updated, then the IIF shall send a GSM MAP _UPDATE_LOCATION_REQUEST to the HLR
5 and await a response.
6 If the response indicates that the location updating procedure has been successful, then the IIF
7 shall update the corresponding subscriber record and send an ANSI_MAP_regnot to the
8 serving VLR. The ANSI_MAP_regnot contains a unique identifier, identifying the HLR.
9 If the response indicates that the location updating procedure has been unsuccessful, then the
10 IIF shall not update the corresponding subscriber record and shall send an ANSI_MAP_regnot
11 to the serving VLR indicating the reason for failure.
12 If the IIF receives a GSM MAP _MS_PURGE_REQUEST, it shall check the contents of the
13 message for errors. If errors exist, the IIF shall send a GSM MAP _MS_PURGE_RESPONSE
14 indicating the reason for failure and the MS purged flag shall not be set. If no errors exist, the
15 IIF shall check if the received VLR number matches the stored VLR number.
16 If the received VLR number and the stored VLR number match, the IIF shall set the MS purged
17 flag and shall send both a GSM MAP _MS_PURGE_RESPONSE to the VLR (including the
18 Freeze TMSI parameter) and an ANSI_MAP_MS_INACTIVE to the HLR and awaits a response
19 from the HLR.
20 If the received VLR number and the stored VLR number do not match, the IIF sends a GSM
21 MAP _PURGE_MS_RESPONSE containing an empty result to indicate successful outcome
22 and the MS purged flag is not set.
23 When the IIF receives a response from the HLR, it shall follow the VLR procedures outlined in
24 ANSI-41 [6].
25 If the IIF receives an ANSI_MAP_MS_INACTIVE, it shall check the contents of the message for
26 errors. If errors exist, the IIF shall send an ANSI_MAP_ms_inactive indicating the reason for
27 failure and shall not set the MS state to inactive. If no errors exist, the IIF shall set the MS state
28 to inactive and follow the HLR procedures described in ANSI-41 [6]. If the state of the MS
29 remains inactive for a period of time (time controlled by operator), the IIF may send a GSM
30 MAP _MS_PURGE_REQUEST to the HLR.
12
N.S0028
1 If the response indicates that the location cancellation procedure has been successful, then the
2 IIF shall send an ANSI_MAP_regcanc to the HLR.
3 If the response indicates that the location cancellation procedure has been unsuccessful, then
4 the IIF shall send an ANSI_MAP_regcanc to the HLR indicating successful deletion of
5 subscriber data (i.e., ignore the error). The IIF may retry to sending the
6 ANSI_MAP_REGCANC before responding to the HLR.
7 If the IIF receives an ANSI_MAP_REGCANC and the message cannot be processed, the
8 corresponding temporary subscriber data shall not be deleted and the IIF shall send an
9 ANSI_MAP_regcanc to the HLR indicating reason for failure.
13
N.S0028
1 Table 2 shows the mapping between GSM MAP messages and ANSI MAP messages related
2 to Location Registration in ANSI-41 Foreign Mode.
14
N.S0028
1
2 Table 5: UPDATE_LOCATION_REQUEST ↔ REGNOT Parameter Mapping (concluded)
15
N.S0028
1
2 Table 6 shows the mapping of parameters for GSM MAP
3 _INSERT_SUBSCRIBER_DATA_REQUEST to regnot.
16
N.S0028
17
N.S0028
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.
18
N.S0028
TerminalType mismatch
1
2 The ANSI-MAP-regnot may optionally, indicate:
Error Codes
MSID/HLRMismatch
ResourceShortage
OperationNotSupported
ParameterError
SystemFailure
8
9
19
N.S0028
1
2 Appropriate Error Codes in ANSI_MAP_regnot RETURN ERROR (concluded)
3
Error Codes
UnrecognizedParameterValue
MissingParameter
4
5 The IIF is therefore responsible for mapping any errors it receives from the HLR in the ANSI-
6 MAP-regnot to an equivalent error in the GSM-MAP-UPDATE-LOCATION RESPONSE towards
7 the serving GSM MSC/VLR.
8
9 The GSM-MAP-UPDATE-LOCATION RESPONSE may include one the following ‘user’ errors
10 as defined in GSM 09.02 [3]:
11 Appropriate User Errors
User Errors
unknown subscriber;
roaming not allowed;
system failure;
unexpected data
value.
12
13 The following ‘provider errors’ (protocol related errors) are also defined in GSM 09.02 [3]:
14 Appropriate Provider Errors
20
N.S0028
1 If the Location Updating procedure fails at a GSM HLR, it returns a GSM MAP
2 _UPDATE_LOCATION_RESPONSE to the IIF, indicating a ‘user error’ as indicated above.
3 The IIF is therefore responsible for mapping any errors it receives into a corresponding error in
4 the ANSI_MAP_regnot towards the serving ANSI MSC/VLR. For further description of these
5 errors and when they are used, refer to either GSM 09.02 [3] or ANSI-41 [6].
6 Table below provides the mapping of both user errors and provider errors to the equivalent
7 value in either the AUTHDEN parameter in the ANSI_MAP_regnot RETURN RESULT or the
8 RETURN ERROR for ANSI-41 Foreign Mode.
21
N.S0028
22
N.S0028
23
N.S0028
24
N.S0028
ResourceShortage
OperationNotSupported
SystemFailure
13
14 There are no error handling procedures defined in GSM09.02 [3] covering the case where Fault
15 Recovery procedures fail at a GSM VLR i.e. the GSM MAP _RESET service is a non-confirmed
16 service. As such, the IIF shall not map ANSI-41 error values to equivalent GSM error values.
17 If the Fault Recovery procedure fails at the IIF following the reception of an
18 ANSI_MAP_BULKDEREG, the IIF shall respond by sending an ANSI_MAP_bulkdereg in a
19 TCAP RETURN ERROR with one of the following error codes as defined in ANSI-41 [6]:
20
21 Appropriate Error Codes in ANSI_MAP_bulkdereg RETURN ERROR
22
Error Codes
ResourceShortage
OperationNotSupported
SystemFailure
UnrecognizedParameterValue
23
24
25
N.S0028
1
As an alternative, the MSISDN may also be retrieved directly from the Subscriber profile,
pre-provisioned in the IIF.
26
N.S0028
1 IIF shall populate the BillingID field with the value of the BillingID received in the
2 RoutingRequest Invoke message.
3 The IIF shall then populate the MSCID (Serving) field with its own ID and forward it to the ANSI-
4 41 HLR.
5 If the response is unsuccessful, the IIF shall map any error code it receives to either an
6 AccessDeniedReason value in the MAP_RoutingRequest Return Result or to an Error Code in
7 a Return Error message.
8 For the cases of failure at the IIF on reception of the MAP_RoutingRequest Invoke message
9 (e.g. missing expected parameter, unknown subscriber), the procedures described in ANSI-41
10 [6] are also applicable to the IIF.
11 For the cases of failure at the IIF on reception of the PROVIDE_ROAMING_NUMBER
12 response, the procedures described in GSM 09.02 [3] for retrieval of routing information are
13 also applicable to the IIF.
14
1
As an alternative, the MSISDN may also be retrieved directly from the Subscriber profile,
pre-provisioned in the IIF.
27
N.S0028
1 If the response is unsuccessful, the IIF may receive a RoutingRequest Return Result with the
2 field AccessReasonDenied present, or a ReturnError message with an Error Code value. The
3 IIF shall map any Access Reason Denied or Error Code it receives to a User or Provider Error
4 in the MAP_PROVIDE_ROAMING_NUMBER return error.
5 For the cases of failure at the IIF on reception of the MAP_PROVIDE_ROAMING_NUMBER
6 request, (e.g. missing expected parameter, unidentified subscriber), the procedure described in
7 GSM 09.02 [3] for retrieval of routing information are applicable to the IIF.
8 For the cases of failure at the IIF on reception of the MAP_RoutingRequest Invoke message
9 return Result, the procedure described in ANSI-41 [6] for automatic call delivery is applicable to
10 the IIF.
11
28
N.S0028
29
N.S0028
30
N.S0028
1
2 The following table shows the mapping of parameters between the Provide Roaming Number
3 Response and the Routing Request Return Result messages regardless of the mode of
4 operation (GSM Foreign Mode or ANSI-41 Foreign Mode).
5 Table 16: Provide Roaming Number Response ↔ Routreq Return Result Parameter
6 Mapping
Provide Roaming Number ack Status Routreq Return Result Status
Roaming Number* M Digits (Destination) R
- MSCID (Serving) M
User Error* R R
(Note AccessDeniedReason (Note
1) 2)
- BillingID (Anchor) R
- ConditionallyDeniedReason O
- MSCIdentificationNumber R
- PC_SSN (Serving MSC) O
GSM BearerServiceCode or GSM O CDMAServiceOption O
TeleService (Note 3)
7
8 * These parameters are mutually exclusive
9 Note 1: If the request is unsuccessful.
10 Note 2: If User Error is present in Provide Roaming Number ack.
11 -Note 3: Optional, if the network settings support data, a mapping may be performed as
12 described in Table 92
13
14 Or
31
N.S0028
1 Table 18: Routreq Return Error to Provide Roaming Number Response Error Mapping
2 (GSM Foreign mode)
Routing Request Return Error Status Provide Roaming Number Status
ack
Error Code O User Error C
32
N.S0028
33
N.S0028
1
2 Table 20 presents how the IIF shall populate the parameters of the Routing Request Return
3 Result message to be sent to the ANSI-41 HLR. These fields cannot be mapped from the
4 received Provide Roaming Number request message.
34
N.S0028
35
N.S0028
Absent Subscriber
No roaming Number available
Facility Not supported
System Failure
Data Missing
Unexpected Data Value
8
9 Appropriate Provider Error value:
Duplicated Invoke ID
Initiating Release
36
N.S0028
1
2
3 Appropriate Provider Error value (concluded):
AccessDeniedReason
Inactive
Busy
No page Response
Unavailable
10
11 Appropriate Error Code parameter value in the Return Error message:
UnrecognizedMIN
UnrecognizedESN
ResourceShortage
OperationNotSupported
ParameterError (Note 1)
UnrecognizedParameterValue
SystemFailure
MissingParameter
12
13 Note 1: The FaultyParameter field shall be present and populated with the appropriate Parameter
14 Identifier.
15
37
N.S0028
8 Table 22: PRN response User Error to routreq Return Error Mapping
User Error value received in PRN AccessDeniedReason in routreq or Error
response 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
11 Table 23: PRN Response Provider Error to routereq Return Error Mapping
Provider Error value received in PRN Error Code value in Return Error
Confirm.
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
38
N.S0028
8 Table 24: RoutingRequest Return Result to User Error in the PRN response Error
9 Mapping
AccessDeniedReason received in the User Error in the PRN response
RoutingRequest Return Result
Inactive Absent Subscriber
Busy Absent Subscriber
No page Response Absent Subscriber
Unavailable Absent Subscriber
10
11 Table 25: Routing Request Return Error to PRN User Error Mapping
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
39
N.S0028
10 4.2.2.1.1 Invocation of Call Forwarding before the call has been routed to the serving
11 MSC
12
13 The Call Forwarding procedure is invoked in the IIF when a terminating call attempt results in
14 an “unavailable” indication and the IIF is required to provide treatment for the “unavailable”
15 situation.
16 The following procedures are applicable at the IIF for Call Forwarding invocation:
17 If the IIF receives an ANSI_MAP_routreq indicating ‘access denied’, the IIF shall determine if
18 call forwarding is applicable for the call.
19 If call forwarding is applicable for the call, the IIF shall send a GSM MAP _PROVIDE
20 ROAMING_NUMBER_RESPONSE to the HLR.
21 The IIF shall process the forwarding request in one of the following two optional methods:
22 • Send the Forward_To_Number that corresponds to the access denied reason (stored
23 for the subscriber in the IIF). Refer to Table 26 or,
33 4.2.2.1.2 Invocation of Call Forwarding after the call has been routed to the serving
34 MSC
35
36 If the called party is either busy, not reachable or does not answer the call, the serving MSC
37 may redirect the call by sending REDREQ to the IIF, indicating the reason for failure.
38 If the IIF receives an ANSI_MAP_REDREQ, it shall determine if the message can be
39 processed:
40
N.S0028
1 If the message can be processed and optimal routing is supported, the IIF shall
2 follow the procedures outlined in 4.2.3 of this document for Optimal Routing for
3 late call forwarding.
4 If the message can be processed but optimal routing is not supported, the IIF
5 shall send an ANSI_MAP_redreq Reject message. On receipt of the Reject
6 message, the serving MSC may attempt to redirect the call by sending a
7 TRANUMREQ message to the IIF.
8 If the message cannot be processed, the IIF shall send an ANSI_MAP redreq
9 Return Reject message with the appropriate error code. On receipt of the Return
10 Reject message, the serving MSC may attempt to redirect the call by sending a
11 TRANUMREQ message to the IIF.
12 If the IIF receives an ANSI_MAP_TRANUMREQ, it shall determine if the
13 message can be processed.
14 If the message can be processed, the IIF shall send an ANSI_MAP_tranumreq
15 indicating the forwarded-to-number.
16 If the message cannot be processed, the IIF shall send an ANSI_MAP tranumreq indicating the
17 reason for failure.
18
31 Table 26: ROUTEREQ Return Result to Provide Roaming Number Response parameter
32 mapping (Option 1)
Routing Request Return Result Status Provide Roaming Number ack. Status
AccessDeniedReason = Busy, O Roaming Number C
Inactive, No Page Response or
Unavailable
33
34
41
N.S0028
1 Table 27: ROUTREQ Return Result to Provide Roaming Number Response Parameter
2 Mapping (Option 2)
Return Error Status Provide Roaming Number ack Status
AccessDeniedReason = Busy, O User Error = Absent Subscriber C
Inactive, No Page Response or
Unavailable
3
4 Default parameters value
5 N/A
Absent Subscriber
System Failure
Data Missing
Unexpected Data Value
11
12 Appropriate Provider Error value:
Provider Error value
Duplicated Invoke ID
Not supported service
Mistyped parameter
Resource limitation
Initiating Release
13
42
N.S0028
1 The following table presents the appropriate ANSI-41 MSC/VLR negative response to a
2 Routing Request Invoke message as described in in ANSI-41 [6].
3 Appropriate AccessDeniedReason parameter values in the RoutingRequest Return Result:
4
AccessDeniedReason
Inactive
Busy
No page Response
Unavailable
5
6 Appropriate Error Code parameter value in the Return Error message:
7
UnrecognizedESN
ResourceShortage
OperationNotSupported
ParameterError*
UnrecognizedParameterValue*
SystemFailure
MissingParameter*
8
9 Table 28: Return Error to User Error in the PRN response Error Mapping
Error Code value User Error
10
11
43
N.S0028
29 If successful ANSI-41 Routing Request response is received from VLR, it converts Temporary
30 Location Directory Number (TLDN) in to Mobile Subscriber Roaming Number (MSRN) and send
31 this information to HLR in GSM-Provide Roaming Number Acknowledge message.
32 Otherwise, the IIF sends a GSM-Provide Roaming Number negative response to HLR and
33 discards GMSC Address, Call Reference Number and OR Interrogation Indicator parameter
34 information if present.
35 If the IIF receives ANSI-41 Redirection Request message, it shall check GMSC Address.
44
N.S0028
45
N.S0028
5
6 Table 29 shows the translation between GSM MAP messages and ANSI-41 MAP messages
7 related to Optimal Routing Support for Late Call Forwarding procedure.
8 Table 29: Optimal Routing for Late Call Forwarding Message Mapping
GSM MAP Message ANSI-41 MAP Message
GSM-Provide Roaming Number Request ROUTEREQ
GSM- Provide Roaming Number routereq
Acknowledge
GSM-Resume Call Handling REDREQ
GSM-Resume Call Handling Acknowledge redreq
9
46
N.S0028
3
4
47
N.S0028
1
2 Table 30: GSM Provide_Roaming_Number ↔ ANSI-41 ROUTEREQ Parameter Mapping
3 (concluded)
- MobileDirectoryNumber O
- VMSPIN O
- VMBOX O
4
5 Note 1: Alternatively a provisioning number may be mapped to the MDN.
6 Note 2: The GMSC Address is used by the IIF to route information to the originating MSC.
48
N.S0028
49
N.S0028
16 4.2.3.2.4 Mapping Forwarding Reason to Redirection Reason for GSM Foreign Mode
17
50
N.S0028
32
33 For error mappings see Automatic Call Delivery, Error Handling, ANSI-136 41 Foreign Mode.
51
N.S0028
52
N.S0028
21 • Call Forwarding Unconditional (in both GSM and ANSI-136 41 foreign modes)
22 • Call Forwarding Busy (in both GSM and ANSI-136 41 foreign modes)
53
N.S0028
1 operation". Note that cases in which no "Basic service" parameter is included in the received
2 message are acceptable, since, by default, no "Basic service" parameter indicates that the
3 request applies to all services.
4
5 If the format and content of the message is correct, the IIF shall determine the location of the
6 subscriber’s HLR and send to it an ANSI-41 FeatureRequest INVOKE message populated as
7 described in Table 44 and Table 48. If a failure occurs at the IIF on reception of the GSM
8 MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS message (e.g. missing data), the procedures
9 described in GSM 09.02 [3] are applicable to the IIF.
10 If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF receives an ANSI-41
11 FeatureRequest Return Result message with a FeatureResult parameter set to successful, the
12 IIF shall send a GSM MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS Response message back
13 towards the serving system populated as described in Table 45.
14 If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF instead receives an ANSI-41
15 FeatureRequest Return Result message with a FeatureResult parameter set to unsuccessful,
16 the IIF shall send a GSM MAP_ACTIVATE_SS/MAP_DEACTIVATE_SS Response message
17 back towards the serving system populated as described in Table 45 and Table 53.
18 If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF instead receives an ANSI-41
19 FeatureRequest Return Error message, the IIF shall send a GSM MAP_ACTIVATE_SS/
20 MAP_DEACTIVATE_SS Response message back towards the serving system populated as
21 described in Table 54.
22 Note that successful supplementary service activation/deactivation cases in GSM foreign mode
23 may result in the subscriber's ANSI-41 HLR sending out an ANSI-41 QUALDIR message to the
24 serving system. For these cases, the IIF would need to map the message to a GSM MAP
25 Insert Subscriber Data message. The mapping of an ANSI-41 QUALDIR message to a GSM
26 MAP Insert Subscriber Data message is covered in the Subscriber Data Management.
27
54
N.S0028
55
N.S0028
9
10
1
2 Table 44: Activate/Deactivate SS Request ↔ FEATREQ Parameter Mapping (concluded)
57
N.S0028
58
N.S0028
59
N.S0028
1
2 Default parameter values
3 This table 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 Activate/Deactivate SS request message.
60
N.S0028
1
2 Default parameter values
3
4 This table describes the population of the parameters in the Activate/Deactivate SS Response
5 message for successful activation/deactivation cases (i.e. when the received Feature Request
6 Return Result contains a FeatureResult parameter set to “successful”).
61
N.S0028
62
N.S0028
1
2 Default parameter values
3 Table 52 presents how the IIF shall populate the parameters of the Feature Request Return
4 Result message to be sent to the ANSI-41 VLR for successful activation cases. Note that the
5 population of the message may differ for non-activation cases.
63
N.S0028
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
8 Appropriate Provider Error value:
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
64
N.S0028
1 The following table presents the appropriate ANSI-41 MSC/VLR negative response to a
2 Feature Request Invoke message as described in ANSI-41 [6].
3 Appropriate AccessDeniedReason parameter values in the FeatureRequest Return Result
4 (Note, however, that none of these values are applicable to the feature activation scenarios):
5
AccessDeniedReason
TerminationDenied
6
7
8 Appropriate Error Code parameter value in the Return Error message:
UnrecognizedMIN
UnrecognizedESN
MIN/HLRMismatch
OperationSequenceProblem
ResourceShortage
OperationNotSupported
ParameterError
SystemFailure
UnrecognizedParameterValue
9
10
65
N.S0028
11
66
N.S0028
67
N.S0028
68
N.S0028
69
N.S0028
4 4.3.2.1 Registration
5
12 • Call Forwarding Unconditional (in both GSM and ANSI-136 41 foreign modes)
13 • Call Forwarding Busy (in both GSM and ANSI-136 41 foreign modes)
70
N.S0028
1 If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF receives an ANSI-41
2 FeatureRequest Return Result message with a FeatureResult parameter set to successful, the
3 IIF shall send a GSM MAP_REGISTER_SS Response message back towards the serving
4 system populated as described in Table 60 and Table 64.
5 If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF instead receives an ANSI-41
6 FeatureRequest Return Result message with a FeatureResult parameter set to unsuccessful,
7 the IIF shall send a GSM MAP_REGISTER_SS Response message back towards the serving
8 system as described in 4.3.2.2.3 Error Handling.
9 If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF instead receives an ANSI-41
10 FeatureRequest Return Error message, the IIF shall send a GSM MAP_REGISTER_SS
11 Response message back towards the serving system as described in 4.3.2.2.3 Error Handling.
12 Note that successful supplementary service registration cases in GSM foreign mode may result
13 in the subscriber's ANSI-41 HLR sending out an ANSI-41 QUALDIR message to the serving
14 system. For these cases, the IIF would need to map the message to a GSM MAP Insert
15 Subscriber Data message. The mapping of an ANSI-41 QUALDIR message to a GSM MAP
16 Insert Subscriber Data message is covered in the Subscriber Data Management.
17
71
N.S0028
21
72
N.S0028
73
N.S0028
1 Table 60: Register SS Response ↔ Feature Request Return Result Parameter Mapping
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
3 Note 1: The FeatureResult parameter shall be mapped to an error value if a User Error is
4 received in the REGISTER SS RESPONSE, or the User Error shall be mapped to an
5 appropriate value if an Unsuccessful value is received in Feature Result. See Table 68.
6
7
8
74
N.S0028
75
N.S0028
76
N.S0028
1
2 Default parameter values
3
4 Table 63 presents how the IIF shall populate the parameters of the Feature Request Invoke
5 message to be sent to the ANSI-41 HLR. These fields cannot be mapped from the received
6 Register SS request message.
77
N.S0028
1 support. For those successful cases, the “Default parameter values” describes how the
2 corresponding GSM Register SS Response message shall be populated. For the unsuccessful
3 cases, refer to 4.3.2.2.3 Error Handling.
4
5 Default parameter values
6
7 Table 64 describes the population of the parameters in the Register SS Response message for
8 successful registration cases (i.e. when the received Feature Request Return Result contains a
9 FeatureResult parameter set to “successful”).
10
78
N.S0028
79
N.S0028
1
2 GSM Register SS Response to ANSI-41 Feature Request Return Result mapping
3
4 Mapping of parameter values
5 For the successful case (in which there’s no User error or Provider Error in the received GSM
6 Register SS Response message), there are no meaningful parameter mappings to support.
7 For those successful cases, the “Default parameter values” describes how the corresponding
8 ANSI-41 FeatureRequest Return Result shall be populated. For the unsuccessful cases, refer
9 to 4.3.2.2.3 Error Handling.
10
11 Default parameter values
12 Table 67 presents how the IIF shall populate the parameters of the Feature Request Return
13 Result message to be sent to the ANSI-41 VLR for successful supplementary service
14 registration cases. Note that the population of the message may differ for non-registration
15 cases.
80
N.S0028
1
2 Table 67: FeatureRequest Return Result default parameter (concluded)
81
N.S0028
11 Table 68: FeatureRequest Return Result to User Error in the Register SS Response
12 mapping
FeatureRequest Return Result User Error in the Register SS Response
FeatureResult ="unsuccessful" User Error = "SS subscription violation"
AnnouncementList="UnauthorizedFeature
Code"
FeatureResult ="unsuccessful" User Error="System Failure"
AnnouncementList not present
13
14 4.3.2.2 Erasure
15
24 • Call Forwarding Busy (in both GSM and ANSI-136 41 foreign modes)
82
N.S0028
1 While in GSM Foreign Mode, the principal role of the IIF, with respect to supplementary service
2 erasure is that of handling the GSM MAP_ERASE_SS as follows: If the IIF receives an GSM
3 MAP_ERASE_SS message from the GSM serving system, it shall verify the correct format and
4 content of the message as described in GSM 09.02 [3].
5
6 For cases in which the received message contains a "Basic service" parameter, the IIF shall
7 also verify that the request for erasure applies to (at least) speech. If the received request does
8 not include "speech" as one of the services to which the request applies, the IIF shall respond
9 with either a GSM MAP_ERASE_SS Response message that includes a "User error"
10 parameter with a value of "Illegal SS Operation". Note that cases in which no "Basic service"
11 parameter is included in the received message are acceptable, since, by default, no "Basic
12 service" parameter indicates that the request applies to all services.
13
14 If the format and content of the message is correct, the IIF shall determine the location of the
15 subscriber’s HLR and send to it an ANSI-41 FeatureRequest INVOKE message populated as
16 described in Table 70, Table 73 and Table 74. If a failure occurs at the IIF on reception of the
17 GSM MAP_ERASE_SS message (e.g. missing data), the procedures described in GSM 09.02
18 [3] are applicable to the IIF.
19
20 If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF receives an ANSI-41
21 FeatureRequest Return Result message with a FeatureResult parameter set to successful, the
22 IIF shall send a GSM MAP_ERASE_SS Response message back towards the serving system
23 populated as described in Table 71 and Table 75.
24
25 If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF instead receives an ANSI-41
26 FeatureRequest Return Result message with a FeatureResult parameter set to unsuccessful,
27 the IIF shall send a GSM MAP_ERASE_SS Response message back towards the serving
28 system as described in Table 71 and Table 79.
29 If, in response to the ANSI-41 FeatureRequest INVOKE, the IIF instead receives an ANSI-41
30 FeatureRequest Return Error message, the IIF shall send a GSM MAP_ERASE_SS Response
31 message back towards the serving system as described in 4.3.2.2.3 Error Handling.
32 Note that successful supplementary service erasure cases in GSM foreign mode may result in
33 the subscriber's ANSI-41 HLR sending out an ANSI-41 QUALDIR message to the serving
34 system. For these cases, the IIF would need to map the message to a GSM MAP Insert
35 Subscriber Data message. The mapping of an ANSI-41 QUALDIR message to a GSM MAP
36 Insert Subscriber Data message is covered in the Subscriber Data Management.
37
83
N.S0028
1 feature code corresponding to Call Forwarding No Answer, and if the IIF is configured to do so,
2 the IIF may send two MAP_ERASE_SS messages, one indicating Call Forwarding No Reply and
3 the other indicating Call Forwarding Not Reachable. These messages may be sent in parallel.
4 The mapping in Table 70,Table 75 and Table 77 would still be applicable.
5 For the cases of failure at the IIF on reception of the ANSI-41 FeatureRequest Return Result
6 message (e.g. parameter error, unrecognized subscriber), the procedures described in ANSI-41
7 [6] are applicable to the IIF.
8 If in response to the a GSM MAP_ERASE_SS Request message, the IIF receives a GSM
9 MAP_ERASE_SS Response message with neither a User Error nor Provider Error parameter,
10 the IIF shall send an ANSI-41 FeatureRequest Return Result message back towards the serving
11 system populated as described in Table 71. For those cases in which two requests had been
12 previously sent by the IIF, the IIF would wait until receiving the responses to both requests
13 before sending the FeatureRequest Return Result message. For cases in which both responses
14 indicate success, the mapping in Table 71 may be applied to either of the responses (as an IIF
15 implementation option). For cases in which one of the responses indicates success and the
16 other failure, the mapping in Table 71, Table 75 and Table 86 applies to the successful
17 response.
18 If, in response to the GSM MAP_ERASE_SS Request message, the IIF instead receives a
19 GSM MAP_ERASE_SS Response message with a User Error, the IIF shall send either an
20 ANSI-41 FeatureRequest Return Result or a Return Error as described in 4.3.2.2.3 Error
21 Handling If a Provider Error parameter is included in the received GSM MAP_ERASE_SS
22 Response message, the IIF shall send an ANSI-41 FeatureRequest Return Error message
23 populated with an Error Code. For cases in which two requests had been previously sent by the
24 IIF, and both responses indicate failure, the procedures described in 4.3.2.2.3 Error Handling
25 may be applied to either of the responses (as an IIF implementation option).
26
27 Note that successful supplementary service erasure cases in ANSI-136 41 foreign mode may
28 result in the subscriber's GSM HLR sending out a GSM MAP Insert Subscriber Data message
29 to the serving system. For these cases, the IIF would need to map the message to an ANSI-41
30 QUALDIR message. The mapping of GSM MAP Insert Subscriber Data message to an ANSI-
31 41 QUALDIR message is covered in the Subscriber Data Management.
32
84
N.S0028
1
2 Table 69 shows the mapping of messages for Supplementary Service Erasure.
85
N.S0028
1 Table 71: Erase SS Response ↔ Feature Request Return Result parameter mapping
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
3 Note 1: The FeatureResult parameter shall be mapped to an error value if a User Error is
4 received in the ERASE SS RESPONSE
5
6
86
N.S0028
87
N.S0028
88
N.S0028
1
2 Default parameter values
3
4 Table 74 presents how the IIF shall populate the parameters of the Feature Request Invoke
5 message to be sent to the ANSI-41 VLR. These fields cannot be mapped from the received
6 Erase SS request message.
89
N.S0028
1
2 Feature Request Return Result to Erase SS Response mapping
3
4 Mapping of parameter values
5
6 For the successful case (in which a FeatureRequest Return Result is received with the
7 FeatureResult parameter set to “successful”) there are no meaningful parameter mappings to
8 support. For those successful cases, the “Default parameter values” describes how the
9 corresponding GSM Erase SS Response message shall be populated. For the unsuccessful
10 cases, refer to 4.3.2.2.3 Error Handling
11
12 Default parameter values
13
14 Table 75 describes the population of the parameters in the Erase SS Response message for
15 successful erasure cases (i.e. when the received Feature Request Return Result contains a
16 FeatureResult parameter set to “successful”).
90
N.S0028
91
N.S0028
1
2 GSM Erase SS Response to ANSI-41 Feature Request Return Result mapping
3
4 Mapping of parameter values
5
6 For the successful case (in which there is no User error or Provider Error present in the
7 received GSM Erase SS Response message), there are no meaningful parameter mappings to
8 support. For those successful cases, the “Default parameter values” describes how the
9 corresponding ANSI-41 FeatureRequest Return Result shall be populated. For the
10 unsuccessful cases, refer to 4.3.2.2.3 Error Handling.
11
12 Default parameter values
13
14 This table presents how the IIF shall populate the parameters of the Feature Request Return
15 Result message to be sent to the ANSI-41 HLR for successful erasure cases. Note that the
16 population of the message may differ for non-erasure cases.
17
92
N.S0028
1
2 Table 78: FeatureRequest Return Result default parameter (concluded)
15
16
17
93
N.S0028
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.
94
N.S0028
1 (Supporting this case would be useful for accounting for the possibility of a network
2 administrator-initiated change of the forwarded-to DN(s)).
3 The IIF shall populate the TransferToNumberRequest Invoke message in a manner compliant
4 with ANSI-41 [6]. The IIF shall then send the TransferToNumberRequest Invoke message to
5 the ANSI-41 HLR, start the Transfer-To-Number Request Timer, and wait for a response.
6 If the response indicates that the retrieval of forwarded-to-number procedure has been
7 successful, the IIF shall map the forwarded-to-number information (along with any other
8 subscriber profile information received in either the QualificationDirective Invoke or
9 RegistrationNotification RETURN RESULT) into a MAP_Insert_Subscriber_Data Request
10 message. As shown in Table 81 and Table 82, the Forwarded-to-Number field of the
11 TransferToNumberRequest RETURN RESULT shall be mapped from the Digits (Destination)
12 field in the MAP_Insert_Subscriber_Data message. In addition, if the registration deals with Call
13 Forwarding No Answer, the No Reply Condition Time parameter in the
14 MAP_Insert_Subscriber_Data message should be populated with the content of the
15 NoAnswerTime field in the TransferToNumberRequest RETURN RESULT message.
16 In case of a failure, the IIF may receive either a TransferToNumberRequest RETURN RESULT
17 with the field AccessDeniedReason present, or a Return Error or Reject message with an Error
18 Code value. For those cases in which a failure occurs, the IIF shall continue to use a
19 previously obtained forwarded-to number, if available. If no previously obtained forwarded-to
20 number is available at the IIF, the IIF shall not populate the corresponding information (i.e., the
21 Forwarded-to-Number field within the Forwarding Information List parameter) in the
22 MAP_Insert_Subscriber_Data Request message.
95
N.S0028
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 O -
to CFB or CFNA)
GroupInformation O -
MobileDirectoryNumber O -
NoAnswerTime O No Reply Condition time (within C
Forwarding Information List)
RedirectingNumberDigits O -
RedirectingNumberString O -
RedirectingSubaddress O -
TerminationTriggers O -
CDMAServiceOption (Note 2) O -GSM BearerServiceCode or GSM O
TeleService
8
9 Note 1: When TerminationList parameter is present, the Digits (Destination) parameter is
10 ignored.
11 -Note 2: Optional, if the network settings support data, a mapping may be performed as
12 described in Table 92
13
96
N.S0028
1
2 TransferToNumberRequest Return Result to Insert Subscriber Data Request
3
4 Mapping of parameters value
5 Table 82 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
97
N.S0028
98
N.S0028
13 Table 83: Routing Request ↔ Provide Roaming Number Request (Network Provided
14 number) Parmater Mapping
Routing Request Status Provide Roaming Number Status
CallingPartyNumberString1 O AdditionalSignalInfo:- C
(Network Provided No):- CallingPartyNumber:-
Encoding:- IA5
-
Characters:- Digits
Line Identity: E164 address of
Calling Party
15
16
99
N.S0028
2 Table 84: Routing Request ↔ Provide Roaming Number Request (User Provided
3 number) Parameter Mapping
Route Request Status Provide Roaming Number Status
CallingPartyNumberString2 O AddititonalSignalInfo:- C
(User Provided No):- CallingPartyNumber:-
Nature of Number:-
National,Presentation Allowed, Screening Indicator: User
Provided, not screened
User Provided, not screened
Presentation Indicator:
Presentation Allowed
Numbering Plan:- Telephony
Numbering
-
Encoding:- IA5
-
Characters:- Digits
4
5
6
100
N.S0028
1 Table 85: Routing Request ↔ Provide Roaming Number Request (Two calling party
2 numbers) Parameter Mapping
Route Request Status Provide Roaming Number Status
CallingPartyNumberString1 O AdditionalSignalInfo:- C
(Network Provided No):- CallingPartyNumber:-
Encoding:-IA5
-
Characters:- Digits
Line Identity: E164 address of
Calling Party
Encoding:- IA5
-
Characters:- Digits
Line Identity: E164 address of
Calling Party
3
101
N.S0028
102
N.S0028
CallingPartyNumberString1 O AdditionallSignalInfo:- C
(Network Provided No):- CallingPartyNumber:-
Encoding:- IA5
-
Characters:-Digits
Line Identity: E164 address of
Calling Party
103
N.S0028
104
N.S0028
105
N.S0028
1 If the response indicates failure, the received subscriber data is stored by IIF even if there is a
2 failure reported from the visited (foreign mode) system and the IIF shall send the reason for
3 failure in a GSM MAP _INSERT_SUBSCRIBER_DATA_RESPONSE to the GSM HLR.
4
106
N.S0028
10 Table 88: Mapping of GSM MAP Messages ↔ ANSI MAP Messages (Subscriber Data
11 Modification)
GSM MAP Messages ANSI MAP Messages
INSERT_SUBSCRIBER_DATA_REQUEST QUALDIR
107
N.S0028
108
N.S0028
MSISDN C MobileDirectoryNumber O
Category C -
Subscriber Status C -
Bearer service List C -
Teleservice List C
1
Forwarding information List C CallingFeaturesIndicator O
- CarrierDigits O
- DMH_AccountCodeDigits O
- DMH_AlternateBillingDigits O
- DMH_BillingDigits O
Regional Subscription Data C -
- GeographicAuthorization O
- MessageWaitingNotificationCount O
- MessageWaitingNotificationType O
3 2
Call barring information List C OriginationIndicator O
4 4
VLR CAMEL Subscription Info C OriginationTriggers O
- PACAIndicator O
CUG information List C -
6
SS-Data List C CallingFeaturesIndicator1 O
EMLPP Subscription Data C -
Operator Determined Barring C OriginationIndicator2 O
General data
Operator Determined Barring C OriginationIndicator2 O
HPLMN data5
Operator Determined Barring C RestrictionDigits O
HPLMN data5
Roaming Restriction Due To C -
Unsupported Feature
- RoutingDigits O
3 7
Call barring information List C SMS_OriginationRestrictions O
3 8
Call barring information List C SMS_TerminationRestrictions O
- SPINIPIN O
- SPINITriggers O
3
4
109
N.S0028
1
2 Table 92: INSERT_SUBSCRIBER_DATA_REQUEST ↔ profile ‘macro’ Mapping
3 (concluded)
110
N.S0028
1 and/or subscription options may not be available when roaming in either a GSM or ANSI-41
2 PLMN.
3
4 The ASN.1 data type encoding is specified in GSM09.02 [3].
5
111
N.S0028
1 Table 93: Forwarding Information List to Calling Features Indicator Parameter Mapping
GSM_Forwarding Information List ANSI-41_Calling Features Indicator
SSCode FeatureActivityStatus
CFU CFU
CFB CFB
CFNRy CFNA1
CFNRc CFNA1
CD -
BasicService2 -
SSStatus FeatureActivityStatus
Q P R A3
112
N.S0028
1
2 Table 93: Forwarding Information List to Calling Features Indicator Parameter Mapping
3 (concluded)
1 1 0 04 -
4
1101 -
4
1110 -
1111 Authorized and activated
ForwardedToNumber -
E164 Address
ForwardedToSubaddress -
E164 Address
ForwardingOptions -
Forwarding reason
NoReplyConditionTime -
4
1
5 The ANSI-41 CFNA value maps to both GSM values CFNRc and CFNRy.
2
6 GSM allows call forwarding services to be operated on a per basic service group basis. ANSI-
7 41 on the other hand has no concept of basic service groups. Therefore, one or more GSM
8 basic services or basic service groups shall map to all basic services in ANSI-41.
3
9 The QPRA bits, refer to the Quiescent, Provisioned, Registered & Activation status of the
10 various call forwarding services e.g. QPRA = 0110 means that the status of that call forwarding
11 service is not quiescent, provisioned, registered, not active.
4
12 These combinations are not applicable to GSM Call Forwarding services.
13
14
113
N.S0028
ZoneCode GeographicAuthorization
See GSM 09.02 [1] for definition of zone Authorized for all MarketIDs served by the
code1 VLR
6 Table 95: Call Barring Information List to Origination Indicator Parameter Mapping
GSM_Call Barring Information List ANSI-41_Origination Indicator
114
N.S0028
1
2 Table 95: Call Barring Information List to Origination Indicator Parameter Mapping
3 (concluded)
International calls
-
Single Directory number or international
E.164 number
-
BarringOfIncomingCalls -
BAIC -
BIC-Roam -
BAOC
BasicService -
SSStatus -
QPRA
115
N.S0028
3
1 If the IIF receives the ANSI-41 allowed call type set to ‘origination denied’, this shall be
2 mapped as shown in Table 95.
4
3 If the IIF receives the ANSI-41 allowed call type set to ‘national long distance’, this shall be
4 mapped as shown in Table 95.
5
5 If the IIF receives the ANSI-41 allowed call type set to ‘local calls only’ this shall be mapped as
6 shown in Table 95.
6
7 If the IIF receives the ANSI-41 allowed call type as shown, this may be mapped to one or more
8 GSM SSCode values as shown in Table 95.
9
116
N.S0028
CW + CH CW
- CT
- VP
- CD
MPTY 3WC
CLIR CNIR
CLIP CNIP2
CLIP CNIP1
- PCW
COLP -
COLR -
CNAP -
ECT -
CCBS-A -
CCBS-B -
AoCI -
AoCC -
3
4
117
N.S0028
1
2 Table 96: SSData List to Calling Features Indicator Parameter Mapping (concluded)
PLMNSpecific -
1
BasicService -
QPRA
Not authorized
0000 -
0 0 0 12 -
0 0 1 02 -
0 0 1 12 Authorized but de-activated
0100 Authorized and activated
0101 -
0 1 1 02 Authorized and activated
0111 -
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
3
CLIRestrictionOption Feature Activity Status
Permanent -
TemporaryDefaultRestricted Authorized and activated
TemporaryDefaultAllowed Authorized and deactivated
4
OverrideCategory Feature Activity Status
OverrideEnabled Authorized and activated
OverrideDisabled Authorized and deactivated
3
118
N.S0028
1
2 Note (a): There is no equivalent GSM SSCode value for CNIROver. The override restriction
3 capability in GSM is a subscription option whose value is reflected by the OverrideCategory
4
1
5 GSM allows supplementary 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.
2
8 These combinations are not applicable to the GSM supplementary services defined by their
9 SSCode in Table 96
3
10 The CLIRestriction option is equivalent to the ANSI-41 Feature Activity Status, CNIR. If the
11 CLIRestriction is temporary default restricted, this equates to the value ‘Authorized and
12 activated’ in the CNIR feature activity status. If the CLIRestriction is temporary default allowed,
13 this equates to the value ‘Authorized but deactivated’ in the CNIR feature activity status. There
14 is no equivalent in ANSI-41 to permanently restricted.
4
15 The GSM override category is equivalent to the ANSI-41 Feature Activity Status, CNIROver.
16 If the Override Category is enabled, this equates to the value ‘Authorized and activated’ in the
17 CNIROver feature activity status. If the Override Category is disabled, this equates to the value
18 ‘Authorized but deactivated’ in the CNIROver feature activity status.
119
N.S0028
1
2 Table 97: Operator Determined Barring general data to Origination Indicator
3 Parameter Mapping (concluded)
SSAccessBarred
-
AllECTBarred
-
ChargeableECTBarred
-
InternationalECTBarred
-
InterzonalECTBarred
-
DoublyChargedECTBarred
-
MultipleECTBarred
4
5 Note: The mapping shown in Table 97 applies in one direction only i.e. from GSM to ANSI-41.
6 The corresponding ANSI-41 values received by the IIF in “profile” macro parameter, it shall be
7 mapped according to Table 95.
8
1
9 If the IIF receives any of these GSM ODB general data, they shall map to the same ANSI-41
10 allowed call type as shown in Table 97.
11
120
N.S0028
2 Table 98: Operator Determined Barring HPLMN data to Origination Indicator Parameter
3 Mapping
GSM_Operator determined barring ANSI-41_Origination Indicator
(HPLMN)
PLMN-SpecificBarringType1 -
5 Table 99: Operator Determined Barring HPLMN data to Restriction digits Parameter
6 Mapping
GSM_Operator determined barring ANSI-41_Restriction Digits
(HPLMN)
PLMN-SpecificBarringType1 -
7
8
121
N.S0028
1 Table 100: Call Barring Information List to SMS Origination Restrictions Parameter
2 Mapping
GSM_Call Barring Information List ANSI-41_SMS Origination Restrictions
SSCode Default
AllBarringSS -
BarringOfOutgoingCalls -
- Allow Specific
- Allow All
BOIC -
BOIC-exHC -
BAOC -
BarringOfIncomingCalls -
BAIC -
BIC-Roam -
- Direct
- Block Direct
- Allow Direct
- ForceMessageCenter
- Force Indirect
3
4
122
N.S0028
1
2 Table 100: Call Barring Information List to SMS Origination Restrictions Parameter
3 Mapping (concluded)
5 Table 101: Call Barring Information List to SMS Termination Restrictions Parameter
6 Mapping
GSM_Call Barring Information List ANSI-41_SMS Termination Restrictions
SSCode Default
AllBarringSS -
BarringOfOutgoingCalls -
BAOC Block All
- Allow Specific
- Allow All
BOIC -
BOIC-exHC -
BAOC -
BarringOfIncomingCalls -
BAIC -
BIC-Roam -
- Reserve Charges
- Block Direct
- Allow Direct
BasicService
See GSM 09.02[1] for Basic Service codes -
SSStatus
QPRA -
See GSM 09.02[1] for SSStatus values
7
8
123
N.S0028
1 Table 102: Call Barring Information List to Termination Restriction Code Parameter
2 Mapping
GSM_Call Barring Information List ANSI-41_Termination Restriction Code
SSCode Termination RC
AllBarringSS -
BarringOfOutgoingCalls -
BAOC -
BOIC -
BOIC-exHC -
BAOC -
BarringOfIncomingCalls -
BAIC Termination denied
BIC-Roam -
- Unrestricted
BasicService -
See GSM 09.02[1] for Basic Service codes
SSStatus -
QPRA
See GSM 09.02[1] for SSStatus values
3
4
124
N.S0028
SSCode -
See GSM 09.02 [1] for SS Codes
BasicService Default
See GSM 09.02 [1] for complete list of Block All1
Basic Services
SSStatus -
CLIRestrictionOption -
OverrideCategory -
2
1
3 In the case where the BasicService does not indicate that SMS is available, this shall be mapped to
4 ‘Block All’.
SSCode -
See GSM 09.02 [1] for SS Codes
BasicService Default
See GSM 09.02 [1] for complete list of Block All1
Basic Services
SSStatus -
CLIRestrictionOption -
OverrideCategory -
6
1
7 In the case where the BasicService does not indicate that SMS is available, this shall be mapped to
8 ‘Block All’.
9
125
N.S0028
CANDEN Value
Multiple access
Busy
13
14 The ANSI_MAP regcanc may optionally indicate:
15 • CallHistoryCount
16 • ControlChannelData
17 • ReceivedSignalQuality
18 • SMS_MessageWaitingIndicator
19 • SystemAccessData
20 as defined in ANSI-41 [6]
21 Or, an ANSI_MAP regcanc in a TCAP RETURN ERROR one of the following error codes as
22 defined in ANSI-41 [6]:
23 Appropriate Error Codes in ANSI_MAP_regcanc RETURN ERROR
Error Codes
UnrecognizedESN
OperationSequenceProblem
ResourceShortage
OperationNotSupported
ParameterError
SystemFailure
24
126
N.S0028
1 The IIF is therefore responsible for mapping any errors it receives from the ANSI-41 VLR in the
2 ANSI_MAP regcanc to an equivalent error in the GSM MAP
3 _CANCEL_LOCATION_RESPONSE towards the GSM HLR.
4
5 The GSM MAP _CANCEL_LOCATION_RESPONSE may include one the following ‘user’
6 errors as defined in GSM 09.02 [3]:
7 Appropriate User Errors
User Errors
unexpected data
value;
data missing;
8
9 The following ‘provider errors’ (protocol related errors) are also defined in GSM 09.02 [3]:
10 Appropriate Provider Errors
Provider Errors
11
12 If the Subscriber Deletion procedure fails at a GSM VLR, it returns a GSM MAP
13 _CANCEL_LOCATION_RESPONSE to the IIF, indicating an ‘user error’ as indicated above. The
14 IIF is therefore responsible for mapping any errors it receives into a corresponding error in the
15 ANSI_MAP regcanc towards the ANSI-41 HLR. For further description of these errors and when
16 they are used, refer to either GSM 09.02 [3] or ANSI-41 [6].
17 The « Location Registration » provides the mapping of both user errors and provider errors in
18 the GSM MAP _CANCEL_LOCATION_RESPONSE to the equivalent value in either the
19 CANDEN parameter in the ANSI_MAP regcanc RETURN RESULT or the RETURN ERROR.
20
21
127
N.S0028
1
2 Subscriber Data Modification
3 If the Subscriber Data Modification procedure fails at an ANSI-41 VLR, the VLR shall respond
4 by sending:-
5
6 An ANSI_MAP qualdir in a TCAP RETURN ERROR with one of the following reasons as
7 defined in ANSI-41 [6]:
8 Appropriate Provider Errors
Provider Errors
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;
9
10 The IIF is therefore responsible for mapping any errors it receives from the ANSI-41 VLR in the
11 ANSI_MAP qualdir to an equivalent error in the GSM MAP
12 _INSERT_SUBSCRIBER_DATA_RESPONSE or the GSM MAP
13 _DELETE_SUSBCRIBER_DATA_RESPONSE towards the GSM HLR.
14
15 The GSM MAP _INSERT_SUBSCRIBER_DATA_RESPONSE and the GSM
16 MAP_DELETE_SUBSCRIBER_DATA RESPONSE may include one the following ‘user’ errors
17 as defined in GSM 09.02 [3]:
18 Appropriate User Errors
User Errors
unidentified
subscriber;
data missing;
unexpected data
value.
19
128
N.S0028
1 The following ‘provider errors’ are also defined in GSM 09.02 [3]:
2
3 Appropriate Provider Errors
Provider Errors
129
N.S0028
130
N.S0028
131
N.S0028
1 If the response to FSM indicates a failure in the delivery of the short message, the IIF
2 shall map the cause value received to a corresponding SMS_CauseCode value in the
3 SMDPP Return Result, as described in
6
7 Table 116.
8
9 If the response to FSM indicates that the receiving entity does not support MAP V2, the GSM
10 MAP_FORWARD_SHORT_MESSAGE is formatted in MAP V1 and sent again to the serving
11 MSC/VLR.
12
132
N.S0028
133
N.S0028
12 Table 107: Short Message Service in GSM Foreign Mode (for CMT) Message Mapping
ANSI MAP Messages GSM MAP Messages
SMDPP FORWARD_SHORT_MESSAGE
13
14 Table 108: Short Message Service in ANSI-136 41 Foreign Mode (for CMT) Message
15 Mapping
GSM MAP Messages ANSI MAP Messages
FORWARD_SHORT_MESSAGE SMDPP
16
17
134
N.S0028
5 Table 109: SMDPP to MT_Forward Short Message Parameter Mapping for GSM Foreign
6 Mode
ANSI SMDPP Status GSM MT FSM Status
MSID O SM-RP-DA = IMSI M
Note 1
SMS_OriginalDestinationAddres O
s (= MSID) Note 1
SMS-Originating-Address (= MC O SM-RP-OA = IIF address in M
Address) international format. See 4.5.2.4
User Data Unit (in M SM-RP-UI M
SMS_Bearer_Data) See Table 111 and Table 112 for
details of encoding of this
parameter.
7
8 Note 1: MSID and SMS_Original_Destination_Address should be the same.
9 Note 2: This parameter is only valid for MAP V2.
10
135
N.S0028
2 Table 110: MT_Forward Short Message to SMDPP Parameter Mapping for ANSI-41
3 Foreign Mode
GSM MT FSM Status ANSI SMDPP Status
SM-RP-DA= IMSI M MSID R
ESN O
SM-RP-UI M SMS Bearer Data M
See Table 113 for encoding of
this parameter.
- SMS Teleservice Identifier set to M
value (= CMT)
4
5 The IIF shall support the mapping of parameters in Forward Short Message in both MAP V1
6 and MAP V2. Encoding of parameter SM-RP-UI is different depending on the MAP version
7 being encoded in the message. The two following tables describe the coding for each version
8 of MAP.
9
10 Table 111describes the setting of field values for parameter SM-RP-UI for MAP V2.
136
N.S0028
137
N.S0028
1
2 Table 111: SM-RP-UI in MT_FORWARD_SHORT_MESSAGE for MAP V2 Parameter Values
3 for GSM Foreign Mode (concluded)
FIELD VALUE
Data Coding Scheme - Set bit numbers 7654 to data coding (value 1111).
Set bit number 3 to 0.
138
N.S0028
2 Table 113: SMS_Bearer Data in Mobile Terminating SMDPP Parameter Encoding for
3 ANSI-41 Foreign Mode
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”
4
5
139
N.S0028
Note 1 MSID O
SMS Teleservice ID = CMT M
SMS_Original O
DestinationOriginating Address
Sub Address (not sent)
SM-RP-UI: TP-Destination M SMS_Original Destination R
address (B-MSISDN) Address
SMS_Original Originating O
Address Sub Address (not sent)
SMS_Charge Indicator (not sent) O
140
N.S0028
1
2 Table 114: Forward_Short_Message to ANSI-41_SMDPP Parameter Mapping for MO SMS
3 in GSM Foreign Mode (concluded)
4
5 Note 1: MSID and ESN are supplied based on MSISDN received in SM-RP-OA
6
ESN O -
MSID O -
SMS_Charge Indicator O -
SMS_Message Count O -
SMS_Notification Indicator O -
9
10
141
N.S0028
1
2 Table 115: ANSI-41 SMDPP to GSM Forward_Short_Message Parameter Mapping for MO
3 SMS in ANSI-41 Foreign Mode (continued)
SMS_Originating Address O -
SMS_Original Originating O SM-RP-OA: A-MSISDN M
Address (A-MSID)
SMS_Original Originating Sub O -
Address
- TP-Delivery-Ack-Request
(ignored)
4
5
142
N.S0028
1
2 Table 115: ANSI-41 SMDPP to GSM Forward_Short_Message Parameter Mapping for MO
3 SMS in ANSI-41 Foreign Mode (concluded)
143
N.S0028
144
N.S0028
13 • The received value is not a value of the type associated with the operation.
14 • Erroneous tag and length information.
145
N.S0028
1
2 Error Handling at the Reception of ANSI-41 SMDPP
3
4 1. If the subscriber is not connected in the IIF then a SMDPP RR with cause code “SMS
5 Termination Denied” is returned.
6 If the ESN received does not match stored ESN then a SMDPP RR with cause code
7 “SMS Termination Denied” or “Address Translation Failure” is returned.
8 When the SMSNotification Indicator: “Notify when available” is not set, and the MS is
9 inactive or the subscriber’s location is unknown, a SMDPP RR with one of the following
10 cause codes is returned:
11
12 • “SMS Termination Denied”
146
N.S0028
147
N.S0028
1
2 Table 116: Forward_Short_Message to SMS_CauseCode Values in SMDPP Return Result
3 Error Mapping (concluded)
148
N.S0028
1
2 Error Mapping from ANSI SMSDPP to GSM FSM to support Mobile Terminating SMS in
3 ANSI-41 Foreign Mode and Mobile Originated SMS in GSM Foreign Mode
149
N.S0028
15 Upon receipt of a READY_FOR_SM message, the IIF shall store the originating Visited MSC
16 (VMSC) address in the subscriber’s profile and Invoke ID. It shall map the
17 GSM_READY_FOR_SM message to the ANSI_SMSNOT INVOKE message as described in
18 Table 119.
19 It shall populate the SMS_Address parameter with the IIF address. All other parameters are
20 ignored.
21 The ANSI_SMSNOT INVOKE is then transmitted to the subscriber’s SMSC with local
22 Transaction ID. Finally, the IIF shall return a READY_FOR_SM_ACK message with no
23 arguments to the originating VMSC.
24
25 IIF Receiving a SMSNOT RETURN RESULT
26 Upon receipt of a SMSNOT RR message, the IIF shall associate the SMSNOT Transaction ID
27 with the Invoke ID.
28
32 Upon receipt of a SMSNOT message, the IIF shall store the originating VMSC address and
33 Transaction ID. The IIF shall map the ANSI_SMSNOT message to the
34 GSM_READY_FOR_SM. The parameters shall be mapped as described in Table 120.
35 The GSM_READY_FOR_SM is transmitted to the subscriber’s HLR with local Invoke ID.
36 Finally, the IIF shall return a SMSNOT RR to the originating VMSC.
37
150
N.S0028
2 Alternatively, the IIF may receive a REGNOT message indicating an update in location of the
3 MS. Upon receipt of the REGNOT message, the IIF shall determine if the SMS Delivery
4 Pending Flag is set. If the DPF is not set, the IIF follow normal procedures according to 4.1.1
5 Location Registration. If the DPF is set, the IIF shall store the originating VMSC address
6 and Transaction ID. The IIF shall create a GSM_READY_FOR_SM.
7 The content of the MSID is mapped to the equivalent IMSI and place in the IMSI parameter.
8 The Alert Reason parameter is populated with the value - MS Present. All other parameters
9 are ignored.
10 The GSM_READY_FOR_SM is transmitted to the subscriber’s HLR with local Invoke ID. .
11 Finally, the IIF shall return a REGNOT RR to the originating VMSC.
12
13 IIF Receiving a GSM_READY_FOR_SM_ACK
21 Upon receipt of an SMSDeliveryPointToPoint INVOKE message, the IIF shall store the
22 originating MC address and transaction ID. It shall map the ANSI_SMDPP message into a
23 GSM_FSM message and populate the subscriber’s known VMSC into the DPC. The mapping
24 of parameters is described in Table 121.
25 The IIF transmits the GSM_FSM message with local Invoke ID.
26
27 IIF Receiving FORWARD_SHORT_MESSAGE_ACK
28 Upon receipt of the FORWARD_SHORT_MESSAGE_ACK message, the IIF shall associate the
29 Invoke ID with SMDPP transaction ID and map the GSM_FSM_ACK message into an
30 ANSI_SMDPP RETURN RESULT.
31 Next, it populates the stored originating SMSC address into the DPC and populates the
32 transaction ID.
33 If the User Error parameter is populated in the GSM_FSM_ACK, then map this value into
34 the SMS_CauseCode according to
35
36
37
38 Table 116.
151
N.S0028
23 Upon receipt of a MO_FORWARD_SHORT_MESSAGE, the IIF shall store the address of the
24 originating VMSC and Invoke ID. It shall map the GSM_MO_FSM to ANSI_SMDPP INVOKE.
25 The address of the subscriber’s TSA (from the SM RP DA – Service Center Address) is
26 mapped according to 4.5.2.4 into the SMS_DestinationAddress. The mapping of parameters is
27 described in Table 123.
28 The IIF transmits the ANSI_SMDPP INVOKE message with local transaction ID.
29 IIF Receiving SMDPP RETURN RESULT
30 Upon receipt of a SMSDeliveryPointToPoint RR message, the IIF shall associate the SMDPP
31 transaction ID with Invoke ID and map the ANSI_SMDPP RR to the GSM_FSM_ACK.
32 Next, it populates the stored originating SMSC address and Invoke ID. If SMS_CauseCode
33 parameter is populated in the ANSI_SMDPP RR message, then map value into User error
34 parameter according to Table 117.
35 Finally, transmit the GSM_FSM_ACK to the originating VMSC.
36
152
N.S0028
2 Upon receipt of an SMSDeliveryPointToPoint INVOKE message, the IIF shall store the address
3 of the originating VMSC and Transaction ID and map the ANSI_SMDPP INVOKE to the
4 GSM_MO_FSM. The mapping of parameters is described in Table 124.
5 The IIF transmits the GSM_FSM message with local Invoke ID.
6
7 IIF Receiving FORWARD_SHORT_MESSAGE_ACK
8 Upon receipt of the FORWARD_SHORT_MESSAGE_ACK message, the IIF shall associate the
9 Invoke ID with SMDPP transaction ID. The GSM_FSM_ACK message is mapped into an
10 ANSI_SMDPP RETURN RESULT.
11 Next, it populates the stored originating SMSC address and transaction ID. If the User
12 Error parameter is populated in GSM_FSM_ACK, then this value is mapped into the
13 SMS_CauseCode according to
14
15
16
17 Table 116.
18 Finally, transmit the ANSI_SMDPP RR to the originating VMSC.
19
27 Table 118: Short Message Service (for GHOST or WEMT) Message Mapping
ANSI MAP Messages GSM MAP Messages
SMSNOT READY_FOR_SM
28
153
N.S0028
1 The mapping of the GSM MAP _READY_FOR_SM message to the ANSI_SMSNOT message
2 is per Table 119.
3 Table 119: Alerting for an ANSI-136 41 Subscriber in GSM Foreign Mode Parameter
4 Mapping
GSM MAP _READY_FOR_SM Status ANSI_SMSNOT Status
IMSI M ESN M
MSID M
Alert Reason (MS present or M -
Memory Available)
SMS_Address (IIF Address) R
5
6
154
N.S0028
1 The mapping of the ANSI_SMSNOT message to the GSM MAP _READY_FOR_SM message
2 is per Table 120.
3 Table 120: Alerting for a GSM Subscriber in ANSI-136 41 Foreign Mode Parameter
4 Mapping
ANSI_SMSNOT Status GSM MAP _READY_FOR_SM Status
ESN M IMSI R
MSID M
SMS_Address (Serving MSC) O -
Alert Reason (MS present) M
5
15 Table 121: SMDPP to Forward Short Message for Mobile Terminated GHOST/WEMT
16 Teleservice Parameter Mapping in GSM Foreign Mode
SMDPP Status MT FSM Status
SMS Bearer Data M SM-RP-UI M
SMS Teleservice ID =GHOST or M -
WEMT
ESN O -
MSID (Note 1) O SM-RP-DA = IMSI M
SMS_OriginalDestinationAddres O
s (= MSID) (Note 1)
SMS_ChargeIndicator O -
SMS_DestinationAddress O -
SMS_MessageCount O -
SMS_NotificationIndicator O -
SMS_OriginalDestinationSub O -
Address
SMS_Original Originating O -
Address
SMS_Original Originating O -
Address Sub Address
SMS_Originating Address (= MC O SM-RP-OA (set to IIF address) M
Address) See 4.5.2.4
17
155
N.S0028
11 Table 122: Forward Short Message to SMDPP for Mobile Terminated GHOST/WEMT
12 Teleservice Parameter Mapping in ANSI Foreign Mode
MT FSM Status SMDPP Status
SM-RP-DA = M MSID R
IMSI
SMS-Original_Destination- O
Address = MSID
SM-RP-OA = M SMS_Originating Address = IIF O
Service center address OA Address . See 4.5.2.4
SM-RP-UI M SMS_BearerData M
- SMS_Teleservice Identifier = M
GHOST or WEMT
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_OriginalDestinationAddres
s (Not used)
SMS_Original Destination Sub
Address (Not used)
13
14
156
N.S0028
1 When the IIF receives a MAP_FSM originated from a MS roaming in a GSM network, it stores
2 the VMSC address locally and replaces the VMSC address in the outgoing SMDPP message
3 by the E.164 address of the IIF (placed in the SCCP Calling Party Address). Upon receipt of an
4 SMDPP Return Result from the MC, the IIF converts it to a MAP_FSM_ACK and places the
5 previously stored VMSC address in the SCCP Called Party Address. See Table 123.
6 Table 123: Forward Short Message to SMDPP for Mobile Originated GHOST/WEMT in
7 GSM Foreign Mode Parameter Mapping
GSM MO FSM Status ANSI SMDPP Status
SM-RP-DA = M SMS_DestinationAddress= MC R
Service Center Address DA = IIF Address. See 4.5.2.4
Address
SM-RP-OA = M SMS_OriginalOriginating Address R
A-MSISDN Note 1 =A-MSID
SM-RP-UI M SMS_BearerData M
- SMS_Teleservice Identifier = M
GHOST or WEMT (Set by IIF)
- SMS_Originating Address (Set to O
IIF address)
- 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 Originating
Address Sub Address (Not used)
8
9 Note 1: MSID and ESN are mapped from MSISDN received in SM-RP-OA
10
157
N.S0028
1 to a SMDPP Return Result and places the previously stored VMSC address in the SCCP
2 Called Party Address. See Table 124.
3 Table 124: SMDPP to Forward Short Message for Mobile Originated GHOST/WEMT
4 Teleservice Parameter Mapping in ANSI-41 Foreign Mode
ANSI SMDPP Status GSM MO FSM Status
SMS Bearer Data M SM-RP-UI M
SMS Teleservice ID =GHOST or M -
WEMT
ESN O -
MSID O -
(Note 1)
SMS_Charge Indicator O -
SMS_Destination Address O SM-RP-DA: Service Center M
Address (retrieved from mapping
in IIF database). See 4.5.2.4
SMS_Message Count O -
SMS_Notification Indicator O -
SMS_Original Destination O -
Address
SMS_Original Destination Sub O -
Address
SMS_Original Originating O SM-RP-OA (A-MSISDN) M
Address
(A-MSID)
SMS_Original Originating O -
Address Sub Address
SMS_Originating Address O -
5 Note 1: If MSID is received it should be the same as the SMS_OriginalOriginating Address
6
7 GHOST shall use the HLPI shown below. TSAR may or may not be applied to the GHOST
8 teleservice.
158
N.S0028
3 4.5.2.3.1 Error handling at the reception of a Forward Short Message in the IIF
4
5 Refer to 4.5.1.3 Error Handling
13 The IIF is responsible for mapping GSM MAP_FSM_ACK Return Errors to ANSI-41
14 SMS_CauseCodes according to
15
16
17
18 Table 116.
19
20 4.5.2.4 Identification of the IIF SS7 Address for Mobile Originated Services
21
22 The following SS7 address mapping scheme is defined in order to resolve the ambiguity that
23 occurs when a roaming subscriber attempts to invoke mobile originated teleservices.
24 Specifically, instead of using only a single Teleservice Server Address (TSA) as the SS7 SCCP
25 Called Party Address, a pair of E.164 addresses are defined for each Teleservice Server
26 Address Center (e.g., MC or SMSC). This pair of addresses (native and foreign mode TSAs) is
27 used to enable the routing of incoming messages to the IIF from the serving foreign network,
28 while messages that originate in a network that uses the same technology as the home network
29 bypass the IIF and are routed directly to the MC. The native mode address can be translated
30 using global title translation to the actual SS7 address (DPC and SSN) of the MC while the
31 foreign mode address is a virtual address that points (via global title translation) to the IIF.
32 There is a one-to-one mapping in the IIF between the home and foreign mode addresses for
33 each MC, as shown in Table 126. Note that there is a many-to-one relationship between the
34 virtual addresses and the actual IIF address.
35 While roaming in foreign mode, the mobile station uses the foreign mode address in order to
36 ensure that messages are first routed to the IIF. The IIF performs message translation, and
37 inserts the native mode address, i.e., an E.164 number that is translatable by the network to the
38 actual MC destination SS7 address.
159
N.S0028
160
N.S0028
161
N.S0028
1 If the IIF receives a QUALDIR INVOKE message from the TDMA ANSI-41 HLR with
2 MWNCOUNT and MNWTYPE parameters set to valid values, it shall set the Message waiting
3 Notification flag and it shall send a GSM MAP FORWARD_SHORT_MESSAGE. Refer to Table
4 130 for the mapping of parameters between ANSI-QUALDIR and GSM-
5 _MAP_FORWARD_SHORT_MESSAGE.
6 If an error is detected in the QUALDIR INVOKE message, a Reject or Return Error message is
7 sent back to the sending node. No other processing is executed.
8 If a successful response is received for the FSM, the IF shall clear the Message Waiting
9 Notification flag.
10 If the error in the response to FSM indicates that the receiving node does not support MAP V2,
11 the GSM_FSM message shall be reformatted in MAP V1 and sent again.
12 If an error is received in the response to FSM, or if a time out occurs, the MWN information is
13 sent in a new GSM MAP _FORWARD_SHORT_MESSAGE when the IIF receives a new GSM
14 MAP _UPDATE_LOCATION, GSM MAP _READY_FOR_SHORT_MESSAGE or GSM MAP
15 _NOTE_MS_PRESENT message.
16
17 ANSI-136 41 Foreign Mode
18 Two methods of delivering Message Waiting Notification to a native GSM subscriber roaming in
19 ANSI-136 41 are supported.
20
162
N.S0028
29 Table 127: Message Waiting Notification in GSM Foreign Mode Message Mapping
ANSI MAP Messages GSM MAP Messages
Regnot FORWARD_SHORT_MESSAGE
QUALDIR FORWARD_SHORT_MESASGE
30
31 Table 128: Message Waiting Notification in ANSI-136 41 Foreign Mode Message Mapping
GSM MAP Messages ANSI MAP Messages
FORWARD_SHORT_MESSAGE QUALDIR
FORWARD_SHORT_MESSAGE SMDPP
32
163
N.S0028
1 When the IIF receives either a GSM MAP message or an ANSI MAP message, it shall apply
2 the following rules regarding the handling of parameters within those messages:
3 The IIF shall populate mandatory parameters in messages sent by the IIF, regardless of
4 whether mapping of parameters is possible.
5 The IIF may populate optional parameters in messages sent by the IIF, regardless of whether
6 mapping of parameters is possible.
7 All parameters shall be populated in accordance with either GSM 09.02 [3] or ANSI-41 [6], [7],
8 0.
9
10 Table 129 through Table 134 show the mapping of parameters, which the IIF shall perform
11 regardless of the mode of operation (GSM Foreign Mode or ANSI-136 41 Foreign Mode).
12 Where there is no direct mapping for parameters, a ‘-‘ has been entered in the corresponding
13 table.
14 Table 129: Regnot to Forward Short Message for Message Waiting Notification
15 Parameter Mapping
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 SM-RP-UI M
See Table 133 and Table 134 for
details of encoding of this
MWNType (from Profile) O parameter.
17 Table 130: QUALDIR to Forward Short Message for Message Waiting Notification
18 Parameter Mapping
ANSI-41 QUALDIR GSM MT FSM
MSID SM-RP-DA (M) = IMSI
SM-RP-OA (M) = IIF address
MWNCount (from Profile) SM-RP-UI (M)
MWNType (from Profile) See Table 133 and Table 134 for details of
encoding of this parameter.
_ More Messages to Send (M) = no
(Note 1)
19
20 Note 1: This parameter is only valid for MAP V2.
21
164
N.S0028
2 Table 131: Forward Short Message to QUALDIR for Message Waiting Notification
3 Parameter Mapping
GSM MT FSM Status ANSI QUALDIR Status
IMSI M MSID M
ESN M
_ QualificationInformationCode = M
Profile only
_ SystemMyTypeCode M
5 Table 132: Forward Short Message to SMDPP for Message Waiting Notification
6 Parameter Mapping
GSM MT FSM Status ANSI SMDPP Status
SM-RP-UI (M) M SMS_BearerData M
_ SMS_TeleserviceIdentifier = M
GHOST or WEMT
Originating Address M SMS-OriginalOriginatingAddress O
IMSI M ESN O
MSID R
7
8
165
N.S0028
4
5
166
N.S0028
1
2 Table 133: SM-RP-UI in Message FORWARD-SHORT-MESSAGE For MAP V2 Parameter
3 Encoding (concluded)
167
N.S0028
Data Coding Scheme - Set bit numbers 7654 to discard (value DCS
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).
4
5
168
N.S0028
11
15
16
169
N.S0028
19
20 The IIF contains location information (SGSN number) relating to the roaming subscriber.
21 Therefore, the IIF needs to be updated at each change in SGSN. The IIF shall translate GSM
22 MAP messages to ANSI-41 MAP messages and vice versa when the subscribers home ANSI-
23 41 HLR needs updating. The subscriber’s ANSI-41 HLR shall be updated in the following
24 cases:
30 • When the subscriber’s MS (accessing a GSM Network) registers in another SGSN within
31 the same GSM network. The IIF acts like a GPRS HLR/AuC in this case.
170
N.S0028
28 Table 137: Location Updating GPRS in GSM Foreign Mode Message Mapping
GSM MAP Messages ANSI MAP Messages
MAP_UPDATE_GPRS_LOCATION_REQUEST REGNOT
1
MAP_INSERT_SUBSCRIBER_DATA_REQUEST regnot
MAP_UPDATE_GPRS_LOCATION_RESPONSE regnot2
29
1
30 This procedure is used to download GPRS subscriber data to the SGSN.
2
31 This message can also contain error values if the location updating procedure is unsuccessful.
32 If the location updating procedure fails, the mapping is as shown in 4.1.1.3.
33 Table 3 shows the mapping between GSM MAP messages and ANSI MAP messages for MS
34 Purge operation. Table 4 shows the mapping between GSM MAP messages and ANSI MAP
35 messages related to Location Cancellation.
36
171
N.S0028
172
N.S0028
1
2 Table 139 shows the mapping of parameters for GSM MAP
3 _INSERT_SUBSCRIBER_DATA_REQUEST to Regnot when necessary.
173
N.S0028
174
N.S0028
- 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
3 2
Call barring information List C OriginationIndicator O
4 4
VLR CAMEL Subscription Info C OriginationTriggers O
- PACAIndicator O
CUG information List C -
6
SS-Data List C CallingFeaturesIndicator1 O
EMLPP Subscription Data C -
Operator Determined Barring C OriginationIndicator2 O
General data
Operator Determined Barring C OriginationIndicator2 O
HPLMN data5
Operator Determined Barring C RestrictionDigits O
5
HPLMN data
Roaming Restriction Due To C -
Unsupported Feature
- RoutingDigits O
3 7
Call barring information List C SMS_OriginationRestrictions O
3 8
Call barring information List C SMS_TerminationRestrictions O
- SPINIPIN O
- SPINITriggers O
175
N.S0028
1
2
3 Table 141: MAP_INSERT_SUBSCRIBER_DATA_REQUEST → macro profile Mapping
4 (concluded)
176
N.S0028
1 GPRS subscriber data the IIF shall include only the new and/or modified PDP contexts. When
2 the SGSN receives GPRS Subscription Data it shall check if the received data has to be
3 considered as the entire GPRS subscription data. If so, it shall replace the stored GPRS
4 Subscription Data with the received data set, otherwise it shall replace the data only for the
5 modified PDP contexts (if any) and add the new PDP contexts (if any) to the stored GPRS
6 Subscription Data. If GPRS Subscription Data is omitted in the Insert Subscriber Data operation
7 the SGSN shall keep the previously stored GPRS Subscription Data.If the SGSN detects that
8 there is overlapping in the information received within a dialogue, it shall send the error
9 Unexpected Data Value. This parameter is used only by the SGSN.
11
10 This parameter defines the access capabilities of a registered MS.
11 Error handling, Fault Recovery procedures and Error Code mapping are described in 4.1
12 Mobility Procedures.
177
N.S0028
CallingPartyNumberString2 O SM-RP-UI M
(Note 1)
CallingPartySubaddress O -
DestinationDigits O -
DMH_AccountCodeDigits O -
DMH_AlternateBillingDigits O -
DMH_BillingDigits O -
LegInformation O -
LocationAreaID O -
MobileDirectoryNumber O MSISDN R
(Note 2)
MSCIdentificationNumber R -
NoAnswerTime O -
OneTimeFeatureIndicator O -
PC_SSN (Originating MSC) R -
PilotBillingID O -
PilotNumber O -
RedirectingNumberString O -
2
3
4
5
6
178
N.S0028
- OR Interrogation C
- Alerting Pattern C
- CCBS Call C
2
3 Note 1: For encoding of those parameters, refer to “4.3.4 Calling Number/Line Identification
4 Presentation/Restriction”.
5 Note 2: May also be directly retrieved from the subscriber profile pre-provisioned in the IIF.
6
7 4.6.2.1.1.1 Error Code Mapping
8
9 Appropriate errors for an MS attached to both GPRS and non-GPRS services are described in
10 4.2.1.3
11
12 Appropriate AccessDeniedReason parameter values in the RoutingRequest Return Result for
13 the case of a call delivery attempt to an MS attached for GPRS-only services:
14
AccessDeniedReason
Unavailable
No page Response
15
179
N.S0028
180
N.S0028
1 If the response to FSM indicates a failure in the delivery of the short message, the IIF
2 shall map the cause value received to a corresponding SMS_CauseCode value in the
3 SMDPP Return Result, as described in
6
7 Table 116.
8
9 4.6.3.1.1.2 Alerting for GPRS in GSM Foreign Mode in either CMT or GHOST/WEMT
10 format
11
12 The SMS Alert procedure is used for alerting the SGSN when the MS is available for short
13 messaging after a short message transfer has failed because the mobile subscriber is not
14 reachable or when the MS has indicated that it has no memory capacity to accept a short
15 message.
16 Upon receipt of a READY_FOR_SM message, the IIF shall store the originating SGSN address
17 and Invoke ID in the subscriber’s profile. It shall map the GSM_READY_FOR_SM message to
18 the ANSI_SMSNOT INVOKE message as described in Table 119.
19 It shall populate the SMS_Address parameter with the IIF address. All other parameters are
20 ignored.
21 The ANSI_SMSNOT INVOKE is then transmitted to the subscriber’s SGSN with local
22 Transaction ID. Finally, the IIF shall return a READY_FOR_SM_ACK message with no
23 arguments to the originating SGSN.
24 Upon receipt of a SMSNOT RR message, the IIF shall associate the SMSNOT Transaction ID
25 with the Invoke ID.
26 If the IIF receives a GSM MAP _READY_FOR-SHORT_MESSAGE and the Delivery pending
27 flag is set for the subscriber, the IIF shall send an ANSI_MAP_SMS_NOTIFICATION message
28 to the home Message Center. The IIF shall clear the MNRG flag if Alert Reason is set to MS
29 present or The Memory Capacity Exceeded Flag (MCEF) flag if Alert Reason is set to Memory
30 Available and the flags were previously set. If the Alert Reason indicates the mobile present for
31 non GPRS situation, or when the update location procedure has been successfully completed
32 or Supplementary Service Control request is received, the MS not reachable flag (MNR) is
33 cleared and the service centre alert procedure is initiated. If the memory capacity exceeded flag
34 is set, the MS not reachable flag is cleared and stored reason for absence for non GPRS are
35 cleared but the alert procedure is not started. If the Alert Reason indicates the mobile present
36 for GPRS situation, or when the Update GPRS location procedure has been successfully
37 completed, the MS not reachable for GPRS (MNRG) flag is cleared and the service centre alert
38 procedure is initiated. The mapping of parameters is described in Table 142.
39 The ANSI-41 MC shall re-send message SMDPP to deliver the short message to the subscriber.
40
181
N.S0028
2 Table 142: Alerting for an ANSI-136 41 Subscriber for GPRS in GSM Foreign Mode
3 Parameter Mapping
GSM MAP _READY_FOR_SM Status ANSI_SMSNOT Status
IMSI M ESN M
MSID M
Alert Reason M -
1
Alert Reason Indicator C
SMS_Address (IIF Address) R
1
4 This parameter indicates that the alert reason is sent to the HLR due to GPRS activity.
5
182
N.S0028
13 4.6.4.1.1 SMS Delivery for an ANSI-136 41 Subscriber for GPRS in GSM Foreign
14 Mode
15
16 Upon receipt of an SMSDeliveryPointToPoint INVOKE message, the IIF shall store the
17 originating MC address and transaction ID. It shall map the ANSI_SMDPP message into a
18 GSM_FSM message and populate the subscriber’s known SGSN into the DPC. The IIF
19 transmits the GSM_FSM message with local Invoke ID.
20 The mapping of parameters is described in Table 121.
21 The IIF transmits the GSM_FSM message with local Invoke ID.
22 Upon receipt of the FORWARD_SHORT_MESSAGE_ACK message, the IIF shall associate the
23 Invoke ID with SMDPP transaction ID and map the GSM_FSM_ACK message into an
24 ANSI_SMDPP RETURN RESULT.
25 Next, it populates the stored originating SGSN address into the DPC and populates the
26 transaction ID.
27 If the User Error parameter is populated in the GSM_FSM_ACK, then map this value into
28 the SMS_CauseCode according to
29
30
31
32 Table 116.
33 Finally, the ANSI_SMDPP RR is transmitted to the originator.
183
N.S0028
2
3 Upon receipt of a MO_FORWARD_SHORT_MESSAGE, the IIF shall store the address of the
4 originating SGSN and Invoke ID. It shall map the GSM_MO_FSM to ANSI_SMDPP INVOKE.
5 The address of the subscriber’s TSA (from the SM RP DA – Service Center Address) is
6 mapped according to 4.5.2.4 into the SMS_DestinationAddress. The IIF transmits the
7 ANSI_SMDPP INVOKE message with local transaction ID. The mapping of parameters is
8 described in Table 123.
9 Upon receipt of a SMSDeliveryPointToPoint RR message, the IIF shall associate the SMDPP
10 transaction ID with Invoke ID and map the ANSI_SMDPP RR to the GSM_FSM_ACK.
11 Next, it populates the stored originating SGSN address and Invoke ID. If SMS_CauseCode
12 parameter is populated in the ANSI_SMDPP RR message, then map value into User error
13 parameter according to Table 117.
14 Finally, transmit the GSM_FSM_ACK to the originating SGSN.
184
N.S0028
1 If a successful response is received for the FSM, the IIF shall clear the Message Waiting
2 Notification flag.
3 If the response to FSM indicates an error condition, or if a time out occurs, the MWN
4 information is sent in a new GSM MAP _FORWARD_SHORT_MESSAGE when the IIF
5 receives a new GSM MAP _UPDATE_GPRS_LOCATION, GSM MAP
6 _READY_FOR_SHORT_MESSAGE or GSM MAP _NOTE_MS_PRESENT message.
7 When the IIF receives a QUALDIR INVOKE message from the ANSI-41 HLR with
8 MWNCOUNT and MNWTYPE parameters set to valid values, it shall set the Message waiting
9 Notification flag and the IIF shall send a GSM MAP FORWARD_SHORT_MESSAGE. Refer to
10 Table 130 for the mapping of parameters between ANSI-QUALDIR and GSM-
11 _MAP_FORWARD_SHORT_MESSAGE.
12 If an error is detected in the QUALDIR INVOKE message, a Reject or Return Error message is
13 sent back to the sending node. No other processing is executed.
14 If a successful response is received for the FSM, the IIF shall clear the Message Waiting
15 Notification flag.
16 If an error is received in the response to FSM, or if a time out occurs, the MWN information is
17 sent in a new GSM MAP _FORWARD_SHORT_MESSAGE when the IIF receives a new GSM
18 MAP _UPDATE_GPRS_LOCATION, GSM MAP _READY_FOR_SHORT_MESSAGE or GSM
19 MAP _NOTE_MS_PRESENT message.
185
N.S0028
1
2
186
N.S0028
1 GHOST value. In addition, the following parameter mapping related to ANSI-136-710 shall be
2 performed as indicated in Table 143.
3
4
187
N.S0028
2 Table 144 describes where the parameters in the MT GHOST message are derived from:
188
N.S0028
189
N.S0028
190
N.S0028
1
2 Table 146 describes where the parameters in the MT CMT message are derived from
191
N.S0028
Short message
transaction
completed
None sent. Positive 0000000 Short message received by
ACK. the SME
Not mapped. 0000001 Short message forwarded by
(future item for SMPP the SC to the SME but the SC
interworking) is unable to confirm delivery
192
N.S0028
1
2 Table 147: SMS_CauseCode to TP-STATUS Mapping (concluded)
SMS_CauseCode TP-STATUS
(ANSI-41) (GSM)
0010 0111 Other terminal 1000010 Connection rejected by SME
problem
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 1100000 Congestion
shortage
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
4 All other values mapped to Service Rejected (0110 0011).
5
193
N.S0028
194
N.S0028
195
N.S0028
196
N.S0028
10 Table 149: RP-ERROR Cause to R-Cause for Mobile Station Response to Mobile
11 Terminated Transfer Attempt.
GSM RP-ERROR Cause ANSI-136 R-Cause
Memory capacity exceeded (22) Memory capacity exceeded (22)
Invalid short message transfer reference Invalid short message transfer reference
value (81) value (81)
Semantically incorrect message(95) Invalid message, unspecified (95)
Invalid mandatory information (96) Mandatory information element error (96)
Message type nonexistent or not Message type non-existent or not
implemented (97) implemented (97)
Message not compatible with short Message not compatible with the short
message protocol state (98) message transfer state (101)
Information element nonexistent or not Information element non-existent or not
implemented (99) implemented (99)
Protocol error, unspecified (111) Protocol error, unspecified (111)
Interworking, unspecified (127) Interworking, unspecified (127)
All other values Protocol error, unspecified (111)
12
13 At the ANSI-136 MSC, the R-Cause code returned by a mobile station is mapped into a
14 corresponding ANSI-41 SMS_CauseCode for inclusion in an SMDPP Return Result message.
15 At the ANSI-136 MSC, the ANSI-41 SMS_CauseCodes are mapped to ANSI-136 R-DATA
16 REJECT R-Cause codes according to Table 150. The mobile station in turn maps the R-Cause
17 codes to RP-ERROR Causes according to Table 151.
18
197
N.S0028
4 Table 151: ANSI-136 R-Cause Code to RP-ERROR Cause Mapping within the Mobile
5 Station
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)
198
N.S0028
199
N.S0028
1
2
200