You are on page 1of 301

ANSI/J-STD-036-B

Enhanced Wireless 9-1-1 Phase II


Revision History
Revision
Rev. 0
Rev. 0 Addendum 1
Rev. A
Rev. A Addendum 1
Rev. B
Erratum
ANSI/J-STD-036-B

Date
August 2000
December 2000
March 2002
March 2003
April 2005
December 2005

Remarks
Initial publication
First addendum
Publication of Revision A
Addendum to Revision A
Revision B
An erratum was published to correct the omission of the MEID parameter from several operations.
November 2006 Initial ANSI publication

Copyright Telecommunications Industry Association 2006.


All rights reserved.
This document is subject to change.

Foreword
This foreword is not part of this standard.
This Standard was prepared jointly by TIA TR-45.2 and ATIS WTSC.
Major changes in Revision B include support for GSM/UMTS interim position, a Heartbeat
message from MPC to PDE, support for UMTS, the Location Description on the ESP interface,
hybrid position sources and support for MEID.
An erratum to Revision B replaced MEID-related text that had been inadvertently removed
during editing of the Revision B publication document.
ANSI/J-STD-036-B contains changes made for readability, involving the removing of coloration indicating text added or modified before Revision B, and removing the cross-hatching
indicating the modification of certain tables.
This Standard contains 8 annexes of which Annex C and Annex D are considered normative and
part of this Standard. The remaining annexes are considered informative and not part of this
Standard.

ANSI/J-STD-036-B

Enhanced Wireless 9-1-1 Phase II


Contents
Chapter 1: Overview
1

Introduction .....................................................................................................................1-1
1.1 Objective ....................................................................................................................1-1
1.2 Scope..........................................................................................................................1-1
1.3 Normative References................................................................................................1-1

Definitions and Acronyms ...............................................................................................1-5

Chapter 2: Stage 1 Emergency Services Service Descriptions


1

Introduction .....................................................................................................................2-1
1.1 Emergency Location Information Delivery (ELID) ..................................................2-1

Assumptions .....................................................................................................................2-1
2.1 Common Assumptions...............................................................................................2-1
2.2 ANSI-41 Assumptions .................................................................................................2-2
2.3 GSM/UMTS Assumptions........................................................................................2-3

Chapter 3: Functional Overview, ANSI-41


1

Introduction ......................................................................................................................3-1

Methodology ....................................................................................................................3-2

Network Reference Model ...............................................................................................3-2

Network Entities ..............................................................................................................3-3


4.1 Coordinate Routing Database (CRDB)......................................................................3-3
4.2 Emergency Services Message Entity (ESME)...........................................................3-3
4.3 Emergency Services Network Entity (ESNE) ...........................................................3-3
4.4 Mobile Position Center (MPC) ..................................................................................3-3
4.5 Mobile Switching Center (MSC) ...............................................................................3-3
4.6 Position Determining Entity (PDE) ...........................................................................3-3
4.7 Public Safety Answering Point (PSAP) .....................................................................3-3

Messages Across Network Interfaces...............................................................................3-4

Network Entity Relationships ..........................................................................................3-5

Chapter 4: Stage 2 Emergency Services Network Description, ANSI-41.3xx


1

Emergency Location Information Delivery (ELID) Scenarios .......................................4-2


i

ANSI/J-STD-036-B

1.1 ELID Using CAS Push .............................................................................................. 4-2


1.1.1
1.1.2
1.1.3
1.1.4

PDE Queried for Position ............................................................................................ 4-2


PDE Autonomous Delivery of Position ...................................................................... 4-3
Timeout Waiting for Position ..................................................................................... 4-4
Three-Way Call to PSAP After Intersystem Handoff ................................................ 4-5

1.2 ELID Using NCAS Pull ........................................................................................... 4-7


1.2.1 PDE Queried For Position ........................................................................................... 4-7
1.2.2 PDE Autonomous Delivery of Position ...................................................................... 4-8

1.3 Emergency Services Call Routing and ELID ........................................................... 4-9


1.3.1 Routing Based on Position........................................................................................... 4-9
1.3.2 Inter-MSC Routing Based on Position ..................................................................... 4-11
1.3.3 Routing Based on Cell/Sector ................................................................................... 4-13

1.4 Position Update Using NCAS Pull ......................................................................... 4-15


1.4.1 ESME Request for Position Update........................................................................... 4-15
1.4.2 Inter-MSC Request for Updated Position ................................................................. 4-16
1.4.3 Failed Position Update Due to Unavailable MS ....................................................... 4-18

1.5 Failure Cases .......................................................................................................... 4-19


1.5.1 MPC Failure on Call Origination .............................................................................. 4-19

1.6 Call Termination ..................................................................................................... 4-20


1.6.1 Call Termination Reporting ....................................................................................... 4-20
1.6.2 Call Disconnect During Positioning .......................................................................... 4-21

1.7 PDE Use of Network Data ..................................................................................... 4-23


1.7.1 PDE Request for CDMA Pilot Strength Measurements............................................ 4-23
1.7.2 TDMA MAHO Obtained After Call Setup ............................................................... 4-24
1.7.3 TDMA MAHO obtained after Inter-System Handoff .............................................. 4-26

PDE to MS Scenarios for Handset-Based PDE ............................................................ 4-28


2.1 CDMA ..................................................................................................................... 4-28
2.1.1 PDE to MS Communication via E12 Interface........................................................... 4-28
2.1.2 Communication via E5 and E3 Interfaces ................................................................. 4-30
2.1.3 Position Determination after Handoff ....................................................................... 4-32

2.2 TDMA SAMPS ...................................................................................................... 4-34


2.2.1 PDE to MS Communication via E12 Interface........................................................... 4-34
2.2.2 Communication via E5 and E3 Interfaces ................................................................. 4-36
2.2.3 Position Update after Handoff .................................................................................. 4-38

Mobile Initiated Positioning .......................................................................................... 4-40


3.1 MS Originated Position Determination for Emergency Services
Call (Successful CAS Push - E5/E3 Interfaces)....................................................... 4-40
3.2 MS Originated Position Determination for Emergency Services
Call (POST Timer Expiry) ..................................................................................... 4-43
3.3 TDMA SAMPS Emergency Position Report ......................................................... 4-46
3.4 TDMA Inter-MSC Three-Way Call to PSAP using SAMPS ................................. 4-48

Interim Position ............................................................................................................. 4-50


4.1 Successful Routing Based on Interim Position ....................................................... 4-50
4.2 Interim Position Used as Final Position Due to Timeout ........................................ 4-52
4.3 Interim Position Used as Final Position Due to PDE Error..................................... 4-54

Interface Testing ........................................................................................................... 4-56


5.1 Test Message Initiated by ESME ............................................................................ 4-56
ii

ANSI/J-STD-036-B

5.2 Heartbeat Mechanism Initiated by MPC..................................................................4-56

Chapter 5: Functional Overview, GSM/UMTS


1

Introduction ......................................................................................................................5-1

Methodology.....................................................................................................................5-1

Condensed GSM/UMTS Network Reference Model......................................................5-1

Network Entities ...............................................................................................................5-2


4.1 Base Station System (BSS) ........................................................................................5-2
4.2 Emergency Services Message Entity (ESME)...........................................................5-2
4.3 Emergency Services Network Entity (ESNE) ...........................................................5-2
4.4 Gateway Mobile Location Center (GMLC)...............................................................5-2
4.5 Location Measurement Unit (LMU) ..........................................................................5-2
4.6 Mobile Station (MS) ..................................................................................................5-2
4.7 Mobile services Switching Center (MSC) .................................................................5-2
4.8 Serving Mobile Location Center (SMLC) .................................................................5-3
4.9 Radio Network Subsystem (RNC).............................................................................5-3

GSM/UMTS Network Interfaces and Reference Points ..................................................5-3


5.1 A Interface ................................................................................................................5-3
5.2 Ai Reference Point ....................................................................................................5-3
5.3 Di Reference Point ....................................................................................................5-3
5.4 E Interface ..................................................................................................................5-3
5.5 E2 Reference Point ....................................................................................................5-3
5.6 Lg Interface ................................................................................................................5-4
5.7 Ls Interface ................................................................................................................5-4
5.8 Lb Interface ................................................................................................................5-4
5.9 Um Interface ..............................................................................................................5-4
5.10Iu Interface.................................................................................................................5-4
5.11Uu Interface ...............................................................................................................5-4

Emergency Services Messages Applicable to GSM/UMTS ..........................................5-5


6.1 Messages between a GSM/UMTS GMLC and ESME E2 Reference Point ..........5-5
6.1.1 EmergencyServicesPositionRequest ........................................................................... 5-5

6.2 Messages between a GSM/UMTS GMLC and MSC Lg Interface........................5-5


6.2.1 MAP Subscriber Location Report ............................................................................... 5-5
6.2.2 MAP Provide Subscriber Location.............................................................................. 5-8

Chapter 6: Stage 2 Emergency Services Network Description, GSM/UMTS


1

Emergency Location Information Delivery (ELID) Scenarios .......................................6-2


1.1 ELID Using CAS Push ..............................................................................................6-2
1.1.1 ELID with Successful CAS Push ................................................................................ 6-2
1.1.2 ELID with Timed-Out CAS Push ............................................................................... 6-4
iii

ANSI/J-STD-036-B

1.1.3 ELID with Successful CAS Push with MSC-MSC Handover .................................... 6-5

Emergency Location Information Delivery Using NCAS Pull ...................................... 6-7


2.1 ELID using NCAS Pull ............................................................................................. 6-7
2.1.1 Successful ELID NCAS Pull of Initial Position During an Emergency Call (Initial Position already Available in GMLC)................................................................................ 6-7
2.1.2 Successful ELID NCAS Pull of Initial Position During an Emergency Call (Initial Position not already Available in GMLC).......................................................................... 6-9
2.1.3 Failed ELID NCAS Pull of Initial Position During an Emergency Call (Initial Position
Information not Available in GMLC) ....................................................................... 6-11
2.1.4 Failed ELID NCAS Pull of Initial Position During an Emergency Call due to Position
Failure ....................................................................................................................... 6-13
2.1.5 Successful ELID NCAS Pull of Updated Position during an Emergency Services Call
(Initial Position Information already Available in GMLC) ...................................... 6-15
2.1.6 Successful ELID NCAS Pull of Updated Position during an Emergency Services Call
(Initial Position Information not already Available in GMLC) ................................ 6-17
2.1.7 Failed ELID NCAS Pull of Updated Position during an Emergency Call (Initial Position
Information not Available in GMLC) ....................................................................... 6-19
2.1.8 Successful ELID NCAS Pull of Updated Position following MSC-MSC Handover of an
Emergency Call ......................................................................................................... 6-21
2.1.9 Failed ELID NCAS Pull of Updated Position during an Emergency Call ............... 6-23
2.1.10 ELID NCAS Pull of Last Known Position during an Emergency Call (Updated Position
Unavailable and Last Known Position Available in VMSC) ................................... 6-25
2.1.11 ELID NCAS Pull of Last Known Position during an Emergency Call (Updated Position
Unavailable and Last Known Position not Available in VMSC) ............................. 6-27
2.1.12 Test Message between the ESME and GMLC ......................................................... 6-29

Routing by GMLC of Emergency Calls, including Routing based on Geographical Coordinates .............................................................................................................................. 6-30
3.1 Timers...................................................................................................................... 6-30
3.2 Successful Routing by GMLC Based on Interim Position ..................................... 6-31
3.3 Interim Position Used as Final Position Due to INITREQT Timeout .................... 6-33
3.4 Interim Position Used as Final Position Due to Phase II Positioning Failure ........ 6-35
3.5 GMLC Fallback to Routing on Cell on Interim Positioning Failure ...................... 6-37
3.6 GMLC Routing on Cell without Interim Positioning ............................................. 6-39
3.7 MSC times out waiting for SMLC response prior to call setup ............................. 6-41
3.8 MSC times out waiting for GMLC response prior to call setup ............................. 6-42
3.9 MSC Fallback when GMLC unable to allocate ESRK .......................................... 6-43

Chapter 7: Stage 3 Implementation Perspective: Emergency Services Protocol (ESP)


1

Introduction ..................................................................................................................... 7-1


1.1 Transaction Portion ................................................................................................... 7-1
1.2 Component Portion ................................................................................................... 7-2

Emergency Services Protocol Abstract Syntax ............................................................... 7-3

Chapter 8: Stage 3 Implementation Perspective: ANSI-41.5xx Enhancements


1

Introduction ...................................................................................................................... 8-1


iv

ANSI/J-STD-036-B

Operations and Parameter Definitions .............................................................................8-2


2.1 DATA TRANSFER SERVICES ...............................................................................8-2
2.1.1 SS-7 BASED DATA TRANSFER SERVICES.......................................................... 8-2
2.1.1.1 Message Transfer Part ....................................................................................... 8-2

2.2 MAP Operations (ANSI-41.540) ...............................................................................8-2


2.2.1 General......................................................................................................................... 8-2
2.2.1.1 Operation Specifiers .......................................................................................... 8-2
2.2.1.2 Operation Definitions .................................................................................... 8-3
2.2.1.3 CallTerminationReport .................................................................................. 8-4
2.2.1.4 GeoPositionDirective ..................................................................................... 8-6
2.2.1.5 GeoPositionRequest ....................................................................................... 8-7
2.2.1.6 InterSystemPositionRequest .......................................................................... 8-9
2.2.1.7 InterSystemPositionRequestForward .......................................................... 8-12
2.2.1.8 OriginationRequest ...................................................................................... 8-14
2.2.1.9 SMSDeliveryBackward ............................................................................... 8-18
2.2.1.10 SMSDeliveryForward .................................................................................. 8-20
2.2.1.11 SMSDeliveryPointToPoint .......................................................................... 8-22

2.3 MAP Parameters (ANSI-41.550) ............................................................................8-26


2.3.1 General....................................................................................................................... 8-26
2.3.1.1 Parameter Format ............................................................................................ 8-26
2.3.1.2 Parameter Identifiers ....................................................................................... 8-26
2.3.2 Parameter Definitions ............................................................................................... 8-28
2.3.2.1 ActionCode...................................................................................................... 8-28
2.3.2.2 CDMAMobileCapabilities ........................................................................... 8-29
2.3.2.3 CDMAPSMMCount (CPSMC) ................................................................... 8-30
2.3.2.4 CDMAPSMMList (CPSML) ....................................................................... 8-31
2.3.2.5 CDMAServingOneWayDelay2 ................................................................... 8-32
2.3.2.6 CDMATargetMAHOInformation ............................................................... 8-33
2.3.2.7 DTXIndication ............................................................................................. 8-34
2.3.2.8 GeneralizedTime ......................................................................................... 8-35
2.3.2.9 GenericDigits ............................................................................................... 8-36
2.3.2.10 GeographicPosition ..................................................................................... 8-37
2.3.2.11 LCS_Client_ID ............................................................................................ 8-38
2.3.2.12 MobileCallStatus ......................................................................................... 8-39
2.3.2.13 MobilePositionCapability ............................................................................ 8-40
2.3.2.14 MobInfo_AMPS .......................................................................................... 8-42
2.3.2.15 MobInfo_CDMA ......................................................................................... 8-43
2.3.2.16 MobInfo_NAMPS ....................................................................................... 8-44
2.3.2.17 MobInfo_TDMA ......................................................................................... 8-45
2.3.2.18 NetworkTMSI .............................................................................................. 8-46
2.3.2.19 PositionInformation ..................................................................................... 8-47
2.3.2.20 PositionRequestType ................................................................................... 8-48
2.3.2.21 PositionResult .............................................................................................. 8-49
2.3.2.22 PositionSource ............................................................................................. 8-51
2.3.2.23 Profile .......................................................................................................... 8-53
2.3.2.24 ServiceIndicator ........................................................................................... 8-55
2.3.2.25 SMS_TeleserviceIdentifier .......................................................................... 8-56
2.3.2.26 TDMA_MAHO_CELLID ........................................................................... 8-57
2.3.2.27 TDMA_MAHO_CHANNEL ...................................................................... 8-59
2.3.2.28 TDMA_MAHORequest .............................................................................. 8-61
2.3.2.29 TDMA_TimeAlignment parameter ............................................................. 8-62
2.3.2.30 Teleservice_Priority ..................................................................................... 8-63
2.3.2.31 TransactionCapability .................................................................................. 8-64
v

ANSI/J-STD-036-B

2.3.3 Parameter Type Definitions ...................................................................................... 8-67


2.3.3.1 Digits Type ...................................................................................................... 8-67

ANSI-41 Procedures ..................................................................................................... 8-68


3.1 Modification of existing procedures........................................................................ 8-68
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.1.7
3.1.8
3.1.9

MSC Analyze MS Dialed Number (ANSI-41.6-D 3.2.3, page 6-15)......................... 8-68


Idle MS Origination (ANSI-41.6-D 3.2.1, page 6-12 and IS-778)............................ 8-69
In Call MS Flash Attempt (ANSI-41.6-D 3.2.2, page 6-14) ..................................... 8-72
Serving MSC Initiating a Flash Request (ANSI-41.6-D 4.15.1, page 6-138) ........... 8-73
Anchor MSC Receiving a FlashRequest INVOKE
(ANSI-41.6-D 4.15.2, page 6-139) ............................................................................ 8-74
MSC Receiving an SMSDeliveryPointToPoint INVOKE
(ANSI-41.6-D 4.46.4, page 6-273) ............................................................................ 8-74
Anchor MSC Initiating SMS Delivery Point-To-Point
(ANSI-41.6-D 4.46.5, page 6-277) ............................................................................ 8-75
MSC Receiving an SMSDeliveryForward INVOKE
(ANSI-41.6-D 4.45.2, page 6-266) ............................................................................ 8-76
Serving MSC Receiving an SMD-REQUEST (ANSI-41.6-D D.5, page 6-416) ...... 8-76

3.2 (NEW) Origination Request Procedures ................................................................ 8-79


3.2.1 MSC Initiating an OriginationRequest for an Emergency Services Call .................. 8-79

3.3 (NEW) InterSystem Position Request .................................................................... 8-81


3.3.1 MSC Receiving an InterSystemPositionRequest INVOKE ...................................... 8-81

3.4 (NEW) Intersystem Position Request Forward ....................................................... 8-82


3.4.1 MSC Receiving an InterSystemPositionRequestForward INVOKE......................... 8-82

3.5 (NEW) Call Termination Report ............................................................................ 8-85


3.5.1 MSC Initiating a CallTerminationReport INVOKE.................................................. 8-85

3.6 (NEW) SMDPP for Position Determination Data Message Exchange .................. 8-86
3.6.1 MSC Receiving SMDPP INVOKE for Position Determination Data
Message Exchange..................................................................................................... 8-86

3.7 (NEW) SMDFWD for Position Determination Data Message Exchange .............. 8-88
3.7.1 MSC Receiving SMDFWD INVOKE for Position Determination Data
Message Exchange..................................................................................................... 8-88

Operation Timer Values ................................................................................................ 8-89

Chapter 9: Location Services Protocol (LSP)


1

Introduction ..................................................................................................................... 9-1


1.1 Transaction Portion .................................................................................................. 9-2
1.2 Component Portion.................................................................................................... 9-2

Location Services Protocol Abstract Syntax ................................................................... 9-3

Annex A: Analysis of the Network Reference Model..................................................................... A-1


A.1 Possible Emergency Services Network Configurations......................................................... A-1
A.2 Possible Configurations of ESNEs ........................................................................................ A-5
A.3 Possible Configurations of ESMEs ....................................................................................... A-7

Annex B:

Local Positioning Determining Entity ........................................................................... B-1


B.1 PDE Network Configuration ................................................................................................. B-1
B.2 LPDE Position Scenarios ...................................................................................................... B-2
vi

ANSI/J-STD-036-B

B.2.1
B.2.2
B.2.3
B.2.4
B.2.5
B.2.6
B.2.7

Annex C:

ELID With Successful CAS Push.............................................................................B-2


ELID with Successful CAS Push with Anchor MPC Interaction After Handoff ....B-4
ELID with Timed-Out CAS Push and NCAS Pull ..................................................B-6
ELID With NCAS Pull of Position ..........................................................................B-8
Successful ELID Position Request After Handoff ..................................................B-9
Autonomous PDE Push and ELID NCAS Pull .....................................................B-10
MPC Request for CDMA Pilot Strength Measurements .......................................B-11

Non-dialable Callback Numbers (Normative).................................................................C-1

Annex D: Parameter Mapping for Interconnection (Normative) .....................................................D-1


D.1 ISUP Initial Address Message (IAM) .................................................................................... D-1
D.1.1 ISUP Initial Address Message Parameter Contents for
Wireline Compatibility Mode (ESRK).................................................................... D-1
D.1.2 ISUP Initial Address Message Parameter Contents for NCAS .............................. D-2
D.1.3 ISUP Initial Address Message Parameter Contents for CAS ................................. D-3
D.2 Feature Group D (FGD) MF Signaling ................................................................................. D-4
D.3 CAMA MF signaling ............................................................................................................ D-5
D.4 Functionality of Parameters for ESME and ESN .................................................................. D-6

Annex E:

Mapping Between ANSI-41 and ISUP Digit Parameters................................................ E-1

Annex F:

MSC to Selective Router/PSAP Interconnection Scenarios............................................ F-1

Annex G: Transport Protocols for Reference Point E2....................................................................G-1


G.1 TCP/IP Protocol Stack .......................................................................................................... G-2
G.1.1 Network Architecture ............................................................................................. G-3
G.1.2 Session Establishment ............................................................................................. G-4
G.1.3 Emergency Service Protocol (ESP) Messages ........................................................ G-4

Annex H: Use of ESRD in E911 Call Setup as 3-Way Call Following Inter-MSC Handoff ..........H-1
H.1
H.2
H.3
H.4

Inter-MSC Three-Way Call to PSAP .................................................................................... H-2


Inter-MSC Three-Way Call to PSAP using SAMPS ............................................................ H-4
Inter-MSC Routing Based on Position Using Substitute ESRD for NCAS ESNE .............. H-6
Inter-MSC Routing Based on Cellsite/Sector for NCAS when Serving and Anchor MPC are the
same. ................................................................................................................................... H-10

vii

ANSI/J-STD-036-B

List of Tables
Chapter 1 Overview
Chapter 2 Stage 1 Emergency Services Service Descriptions
Chapter 3 Functional Overview, ANSI-41
Chapter 4 Stage 2 Emergency Services Network Description, ANSI-41.3xx
Chapter 5 Functional Overview, GSM/UMTS
Table 5-1:
Table 5-2:
Table 5-3:
Table 5-4:
Table 5-5:
Table 5-6:

MAP Subscriber Location Report Invoke parameters ................................................. 5-5


MAP Subscriber Location Report Return Result parameters ...................................... 5-6
MAP Subscriber Location Report Return Error parameters ........................................ 5-7
MAP Provide Subscriber Location Invoke parameters................................................ 5-8
MAP Provide Subscriber Location Return Result parameters..................................... 5-9
MAP Provide Subscriber Location Return Error parameters....................................... 5-9

Chapter 6 Stage 2 Emergency Services Network Description, GSM/UMTS


Chapter 7 Stage 3 Implementation Perspective: Emergency Services Protocol (ESP)
Chapter 8 Stage 3 Implementation Perspective: ANSI-41.5xx Enhancements
Table 8-1:
Table 8-2:
Table 8-3:
Table 8-4:
Table 8-5:
Table 8-6:
Table 8-7:
Table 8-8:
Table 8-9:
Table 8-10:
Table 8-11:
Table 8-12:
Table 8-13:
Table 8-14:
Table 8-15:
Table 8-16:
Table 8-17:
Table 8-18:
Table 8-19:
Table 8-20:
Table 8-21:
Table 8-22:
Table 8-23:
Table 8-24:
Table 8-25:
Table 8-26:
Table 8-27:
Table 8-28:
Table 8-29:
Table 8-30:

MTP Message Priority Values for ANSI-41 Operations .............................................. 8-2


ANSI-41 MAP Operation Specifiers ............................................................................ 8-2
Summary of MAP Operations...................................................................................... 8-3
FE Combinations for CTRPT....................................................................................... 8-4
CallTerminationReport INVOKE Parameters ............................................................. 8-4
CallTerminationReport RETURN RESULT Parameters............................................. 8-5
FE Combinations for GPOSDIR .................................................................................. 8-6
GeoPositionDirective INVOKE Parameters ................................................................ 8-6
GeoPositionDirective RETURN RESULT Parameters ............................................... 8-6
FE Combinations for GPOSREQ ................................................................................. 8-7
GeoPositionRequest INVOKE Parameters .................................................................. 8-7
GeoPositionRequest RETURN RESULT Parameters ................................................. 8-8
FE Combinations for ISPOSREQ ................................................................................ 8-9
InterSystemPositionRequest INVOKE Parameters ................................................... 8-10
InterSystemPositionRequest RETURN RESULT Parameters................................... 8-11
FE Combinations for ISPOSREQFWD ..................................................................... 8-12
InterSystemPositionRequestForward INVOKE Parameters ...................................... 8-12
InterSystemPositionRequestForward RETURN RESULT Parameters ..................... 8-13
FE Combinations for ORREQ.................................................................................... 8-14
OriginationRequest INVOKE Parameters ................................................................. 8-14
OriginationRequest RETURN RESULT Parameters................................................. 8-16
SMSDeliveryBackward INVOKE Parameters........................................................... 8-18
SMSDeliveryBackward RETURN RESULT Parameters.......................................... 8-19
SMSDeliveryForward INVOKE Parameters ............................................................. 8-20
SMSDeliveryForward RETURN RESULT Parameters ............................................ 8-21
FE Combinations for SMDPP . .................................................................................. 8-22
SMSDeliveryPointToPoint INVOKE Parameters ..................................................... 8-22
SMSDeliveryPointToPoint RETURN RESULT Parameters..................................... 8-24
ANSI-41 MAP Parameter Identifiers (continued) ...................................................... 8-26
ActionCode parameter................................................................................................ 8-28
viii

ANSI/J-STD-036-B

Table 8-31:
Table 8-32:
Table 8-33:
Table 8-34:
Table 8-35:
Table 8-36:
Table 8-37:
Table 8-38:
Table 8-39:
Table 8-40:
Table 8-41:
Table 8-42:
Table 8-43:
Table 8-44:
Table 8-45:
Table 8-46:
Table 8-47:
Table 8-48:
Table 8-49:
Table 8-50:
Table 8-51:
Table 8-52:
Table 8-53:
Table 8-54:
Table 8-55:
Table 8-56:
Table 8-57:
Table 8-58:
Table 8-59:
Table 8-60:
Table 8-61:
Table 8-62:
Table 8-63:
Table 8-64:
Table 8-65:
Table 8-66:
Table 8-67:
Table 8-68:
Table 8-69:
Table 8-70:
Table 8-71:
Table 8-72:
Table 8-73:

ActionCode value ....................................................................................................... 8-28


CDMAMobileCapabilities ......................................................................................... 8-29
CDMAMobileCapabilities value................................................................................ 8-29
CDMAPSMMCount parameter.................................................................................. 8-30
CDMAPSMMList parameter ..................................................................................... 8-31
CDMAServingOneWayDelay2 parameter ................................................................. 8-32
CDMATargetMAHOInformation parameter ............................................................. 8-33
DTXIndication parameter........................................................................................... 8-34
DTXIndication value .................................................................................................. 8-34
GeneralizedTime parameter ....................................................................................... 8-35
GeneralizedTime value............................................................................................... 8-35
GenericDigits parameter............................................................................................. 8-36
Geographic Position parameter .................................................................................. 8-37
LCS_Client_ID Parameter.......................................................................................... 8-38
MobileCallStatus parameter ....................................................................................... 8-39
MobileCallStatus value .............................................................................................. 8-39
MobilePositionCapability parameter.......................................................................... 8-40
MobilePositionCapability value ................................................................................. 8-40
MobInfo_AMPS Macro.............................................................................................. 8-42
MobInfo_CDMA Macro ............................................................................................ 8-43
MobInfo_NAMPS Macro........................................................................................... 8-44
MobInfo_TDMA Macro............................................................................................. 8-45
NetworkTMSI parameter............................................................................................ 8-46
NetworkTMSI value................................................................................................... 8-46
PositionInformation.................................................................................................... 8-47
PositionRequestType parameter................................................................................. 8-48
PositionRequestType value ........................................................................................ 8-48
PositionResult parameter............................................................................................ 8-49
PositionResult value ................................................................................................... 8-49
PositionSource parameter........................................................................................... 8-51
PositionSource value ................................................................................................. 8-51
Profile Macro.............................................................................................................. 8-53
ServiceIndicator parameter......................................................................................... 8-55
ServiceIndicator value ................................................................................................ 8-55
SMS_TeleserviceIdentifier values.............................................................................. 8-56
TDMA_MAHO_CELLID parameter ......................................................................... 8-57
TDMA_MAHO_CHANNEL parameter .................................................................... 8-59
MAHO Request value ................................................................................................ 8-61
TDMA_TimeAlignment parameter............................................................................ 8-62
Teleservice_Priority parameter .................................................................................. 8-63
Teleservice_Priority value.......................................................................................... 8-63
Digits Type value ....................................................................................................... 8-67
Operation Timer Values (continued).......................................................................... 8-89

Chapter 9 Location Services Protocol (LSP)


Annex A: Analysis of the Network Reference Model
Annex B: Local Positioning Determining Entity
Annex C: Non-dialable Callback Numbers (Normative)
Annex D: Parameter Mapping for Interconnection (Normative)
Table D-1:

Feature Group D Parameter Contents for NCAS Signaling .................................... D-4


ix

ANSI/J-STD-036-B

Table D-2:

CAMA Parameter Contents for NCAS Wireline Compatibility (see Note 1)......... D-5

Annex E: Mapping Between ANSI-41 and ISUP Digit Parameters


Annex F: MSC to Selective Router/PSAP Interconnection Scenarios
Annex G: Transport Protocols for Reference Point E2
Annex H: Use of ESRD in E911 Call Setup as 3-Way Call Following Inter-MSC Handoff

ANSI/J-STD-036-B

List of Figures
Chapter 1: Overview
Chapter 2: Stage 1 Emergency Services Service Descriptions
Chapter 3: Functional Overview, ANSI-41
Figure 3-1:
Figure 3-2:

Network Reference Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2


Entity Relationship Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5

Chapter 4: Stage 2 Emergency Services Network Description, ANSI-41.3xx


Figure 4-1:
Figure 4-2:
Figure 4-3:
Figure 4-4:
Figure 4-5:
Figure 4-6:
Figure 4-7:
Figure 4-8:
Figure 4-9:
Figure 4-10:
Figure 4-11:
Figure 4-12:
Figure 4-13:
Figure 4-14:
Figure 4-15:
Figure 4-16:
Figure 4-17:
Figure 4-18:
Figure 4-19:
Figure 4-20:
Figure 4-21:
Figure 4-22:
Figure 4-23:
Figure 4-24:
Figure 4-25:
Figure 4-26:
Figure 4-27:
Figure 4-28:
Figure 4-29:
Figure 4-30:
Figure 4-31:
Figure 4-32:
Figure 4-33:

PDE Queried for Position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2


PDE Autonomous Delivery of Position. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Timeout Waiting for Position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Three-Way Call to PSAP After Intersystem Handoff . . . . . . . . . . . . . . . . . . . . . . . 4-5
PDE Queried For Position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
PDE Autonomous Delivery of Position. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Routing Based on Position. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
Inter-MSC Routing Based on Position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
Routing Based on Cell/Sector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
ESME Request for Position Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15
Inter-MSC Request for Updated Position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
Failed Position Update Due to Unavailable MS . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18
MPC Failure on Call Origination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19
Call Termination Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20
Call Disconnect During Positioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21
PDE Request for CDMA Pilot Strength Measurements . . . . . . . . . . . . . . . . . . . . 4-23
TDMA MAHO Obtained After Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
TDMA MAHO obtained after Inter-System Handoff . . . . . . . . . . . . . . . . . . . . . . 4-26
PDE to MS Communication via E12 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28
Communication via E5 and E3 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30
Position Determination after Handoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32
PDE to MS Communication via E12 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34
Communication via E5 and E3 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-36
Position Update after Handoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-38
MS Originated Position Determination for Emergency Services Call
(Successful CAS Push - E5/E3 Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-41
MS Originated Position Determination for Emergency Services Call
(POST Timer Expiry) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-44
TDMA SAMPS Emergency Position Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-46
TDMA Inter-MSC Three-Way Call to PSAP using SAMPS . . . . . . . . . . . . . . . . 4-48
Successful Routing Based on Interim Position . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-50
Successful Routing Based on Interim Position . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-52
Successful Routing Based on Interim Position . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-54
Test Message Initiated by ESME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-56
Heartbeat Mechanism Initiated by MPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-56

Chapter 5: Functional Overview, GSM/UMTS


Figure 5-1:

Condensed GSM/UMTS Network Reference Model . . . . . . . . . . . . . . . . . . . . . . . 5-1

xi

ANSI/J-STD-036-B

Chapter 6: Stage 2 Emergency Services Network Description, GSM/UMTS


Figure 6-1:
Figure 6-2:
Figure 6-3:
Figure 6-4:
Figure 6-5:
Figure 6-6:
Figure 6-7:
Figure 6-8:
Figure 6-9:
Figure 6-10:
Figure 6-11:
Figure 6-12:
Figure 6-13:
Figure 6-14:
Figure 6-15:
Figure 6-16:
Figure 6-17:
Figure 6-18:
Figure 6-19:
Figure 6-20:
Figure 6-21:
Figure 6-22:
Figure 6-23:

ELID with Successful CAS Push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2


ELID with Timed-Out CAS Push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
ELID with Successful CAS Push with MSC-MSC Handover . . . . . . . . . . . . . . . . . 6-5
Successful ELID NCAS Pull of Initial Position During an Emergency Call (Initial Position already Available in GMLC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
Successful ELID NCAS Pull of Initial Position During an Emergency Call (Initial Position not already Available in GMLC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
Failed ELID NCAS Pull of Initial Position During an Emergency Call (Initial Position
Information not Available in GMLC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
Failed ELID NCAS Pull of Initial Position During an Emergency Call due to Position
Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13
Successful ELID NCAS Pull of Updated Position during an Emergency Services Call
(Initial Position Information Already Available in the GMLC) . . . . . . . . . . . . . . . 6-15
Successful ELID NCAS Pull of Updated Position during an Emergency Services Call
(Initial Position Information not Already Available in the GMLC) . . . . . . . . . . . . 6-17
Failed ELID NCAS Pull of Updated Position during an Emergency Call (Initial Position Information not Available in GMLC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19
Successful ELID NCAS Pull of Updated Position following MSC-MSC Handover of
an Emergency Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-21
Failed ELID NCAS Pull of Updated Position during an Emergency Call . . . . . . . 6-23
ELID NCAS Pull of Last Known Position during an Emergency Call (Updated Position Unavailable and Last Known Position Available in VMSC) . . . . . . . . . . . . . 6-25
ELID NCAS Pull of Last Known Position during an Emergency Call (Updated Position Unavailable and Last Known Position not Available in VMSC) . . . . . . . . . . 6-27
Test Message between the ESME and GMLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29
Successful Routing by GMLC Based on Interim Position . . . . . . . . . . . . . . . . . . . 6-31
Interim Position Used as Final Position Due to INITREQT Timeout . . . . . . . . . . 6-33
Interim Position Used as Final Position Due to Phase II Positioning Failure . . . . 6-35
GMLC Fallback to Routing on Cell on Interim Positioning Failure . . . . . . . . . . . 6-37
GMLC Routing on Cell without Interim Positioning . . . . . . . . . . . . . . . . . . . . . . . 6-39
MSC times out waiting for SMLC response prior to call setup . . . . . . . . . . . . . . . 6-41
MSC times out waiting for GMLC response prior to call setup . . . . . . . . . . . . . . . 6-42
MSC Fallback when GMLC unable to allocate ESRK. . . . . . . . . . . . . . . . . . . . . . 6-43

Chapter 7: Stage 3 Implementation Perspective: Emergency Services Protocol (ESP)


Chapter 8: Stage 3 Implementation Perspective: ANSI-41.5xx Enhancements
Chapter 9: Location Services Protocol (LSP)
Annex A: Analysis of the Network Reference Model
Figure A-1:
Figure A-2:
Figure A-3:
Figure A-4:
Figure A-5:
Figure A-6:
Figure A-7:
Figure A-8:
Figure A-9:

Basic Emergency Services Network Topology ....................................................... A-1


A World Without Selective Routers ........................................................................ A-2
Network Reference Model for Wireless Networks.................................................. A-3
Emergency Services Network Topology with S/R as ESNE................................... A-5
Emergency Services Network Topology with ESNE co-located with PSAP.......... A-5
Emergency Services Network Topology with AT as ESNE ................................... A-6
Emergency Services Network Topology with an interworking device as ESNE.... A-6
Emergency Services Network Topology with ALI as ESME ................................. A-7
Emergency Services Network Topology with Separated ALI as ESME................. A-8
xii

ANSI/J-STD-036-B

Figure A-10: Emergency Services Network Topology with Separated ALI as ESME ................ A-9
Figure A-11: Emergency Services Network Topology with interworking device as a ESME ... A-10
Figure A-12: Emergency Services Network Topology with a message router as the ESME ..... A-11
Figure A-13: Emergency Services Network Topology with the MPC-ALI combination as
the ESME............................................................................................................... A-12
Figure A-14: Emergency Services Network Topology with an SCP application as the ESME . A-13
Figure A-15: Emergency Services Network Topology with an SCP application as the ESME . A-14

Annex B: Local Positioning Determining Entity


Figure B-1:
Figure B-2:
Figure B-3:
Figure B-4:
Figure B-5:
Figure B-6:
Figure B-7:
Figure B-8:

Local PDE Network Topology .................................................................................B-1


ELID With Successful CAS Push.............................................................................B-2
ELID with Successful CAS Push with Anchor MPC Interaction After Handoff.....B-4
ELID with Timed-Out CAS Push and NCAS Pull...................................................B-6
ELID With NCAS Pull of Position...........................................................................B-8
Successful ELID Position Request After Handoff ...................................................B-9
Autonomous PDE Push and ELID NCAS Pull ......................................................B-10
MPC Request for CDMA Pilot Strength Measurements........................................B-11

Annex C: Non-dialable Callback Numbers (Normative)


Annex D: Parameter Mapping for Interconnection (Normative)
Figure D-1: Wireless Network Origination (Direct Connection) MF Signaling Scenario over TIA/
EIA-93 POI-T8 Interface......................................................................................... D-4
Figure D-2: Wireless Network Origination using CAMA Signaling.......................................... D-5

Annex E: Mapping Between ANSI-41 and ISUP Digit Parameters


Annex F: MSC to Selective Router/PSAP Interconnection Scenarios
Annex G: Transport Protocols for Reference Point E2
Figure G-1: Protocol Stacks for Reference Point E2................................................................... G-1
Figure G-2: TCP/IP Protocol Stack for E2 Interface................................................................... G-2
Figure G-3: Wireless E911 Entity Relationship Diagram........................................................... G-3

Annex H: Use of ESRD in E911 Call Setup as 3-Way Call Following Inter-MSC Handoff
Figure H-1:
Figure H-2:
Figure H-3:
Figure H-4:

Inter-MSC Three-Way Call to PSAP ...................................................................... H-2


Inter-MSC Three-Way Call to PSAP using SAMPS............................................... H-4
Inter-MSC Routing Based on Position Using Substitute ESRD for NCAS ESNE . H-7
Inter-MSC Routing Based on Cellsite/Sector for NCAS when Serving and Anchor
MPC are the same.................................................................................................. H-11

xiii

ANSI/J-STD-036-B

Chapter 1: Overview

1
2
3
4
5
6
7
8
9
10
11
12
13

Introduction

14
15
16

1.1

17

Objective

18

This Standard defines the messaging required to support information transfer to identify and locate wireless
emergency services callers.

19
20
21
22

1.2

23

Scope

24
25

This Standard provides a solution for the handling of Wireless Enhanced Emergency Calls for the FCC E911
Phase II mandate.
Carrier position reporting to emergency services systems, as mandated by the Federal Communication
Commission (FCC) under docket 94-102 (including orders 96-264, 99-96 and 99-245) has been addressed by
this Interim Standard without considering position reporting privacy restrictions that may be desirable for
other position reporting services. For this reason, this Standard does not preclude these other service restrictions. Position reporting privacy restrictions are beyond the scope of this Standard, and are not addressed here.

26
27
28
29
30
31
32
33
34

1.3

35

Normative References

36

The following standards contain provisions which, through reference in this text, constitute provisions of this
Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision,
and parties to agreements based on this Standard are encouraged to investigate the possibility of applying the
most recent editions of the standards indicated below. ANSI and TIA maintain registers of currently valid
national standards published by them.

37
38
39
40
41
42
43

American National Standards Institute (ANSI) standards:


ANSI T1.113

Signalling System No. 7, ISDN User Part.

ANSI T1.114

Signalling System No. 7 (SS7), Transaction Capabilities


Application Part (TCAP).

44
45
46
47
48
49
50

CDMA

TIA/EIA/IS-2000.5-A: Upper Layer (Layer 3) Signaling


Standard for cdma2000 Spread Spectrum Systems, 2000.

51
52
53

IS-801

TIA/EIA/IS-801-1: Position Determination Service


Standard for Dual-Mode Spread Spectrum Systems, 2000.

54
55
56

J-STD-034

TIA/EIA J-STD-034: Wireless Enhanced Emergency


Services; 1997.

57
58
59
60

1 Introduction

1-1

ANSI/J-STD-036-B

SAMPS

TDMA ANSI/TIA/EIA-136-740 TDMA Cellular/PCS


System Assisted Mobile Positioning through Satellite
(SAMPS), 2000.

T1.628

ANSI T1.628-2000; American National Standard for


Telecommunications, Routing, Bridging and Transfer of
Emergency Services Calls; Alliance for Telecommunications Industry Solutions Committee T1.

ANSI-41

TIA-41-E: Wireless Radiotelecommunications Intersystem


Operations, 2006.

2
3
4
5
6
7
8
9
10
11
12

TIA/EIA-41-D: Cellular Radiotelecommunications Intersystem Operations, 1997.

13
14
15
16
17

World Geodetic System 1984 (WGS-84) standardizes latitude and longitude. WGS-84 is the
standard for conversion between local systems, in this case national geodetics, and projection maps.

18
19

WGS-84

20

World Geodetic System, WGS-84. United States


Department of Defense, MIL-STD-2401, 1984.

21
22
23
24

DMA TR 8350.2 Department of Defense - World Geodetic System 1984


Technical Report (and supplements); Defense Mapping
Agency, DMA TR 8350.2 Second Edition, 1991.

25
26
27
28

Abstract Syntax Notation one (ASN.1) specifications:


X.680

Abstract Syntax Notation One (ASN.1): Specification of


Basic Notation (07/94).

X.680.1

X.680 Amendment 1. Abstract Syntax Notation One


(ASN.1): Specification of Basic Notation, Amendment 1:
Rules of Extensibility (04/95).

X.690

ASN.1 Encoding Rules: Specification of Basic Encoding


Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) (07/94).

29
30
31
32
33
34
35
36
37
38
39
40
41
42

National Emergency Number Association (NENA) Recommended Standards:


NENA-02-010

NENA Recommended Formats & Protocols for Data


Exchange, May 1999.

43
44
45
46
47

European Telecommunications Standards Institute (ETSI) standards:


GSM 02.71

Digital cellular telecommunications system (Phase 2+);


Location Services (LCS); Service description; Stage 1.
1998.

GSM 03.71

Digital cellular telecommunications system (Phase 2+);


Location Services (LCS); Functional Description; Stage 2.
1998.

GSM 04.08

Digital cellular telecommunications system (Phase 2+);


Mobile radio interface layer 3 specication. 1998.

GSM 04.31

Digital cellular telecommunications system (Phase 2+);


Location service (LCS); Mobile Station (MS) Serving

48
49
50
51
52
53
54
55
56
57
58
59
60

1-2

1 Introduction

ANSI/J-STD-036-B

Mobile Location Center (SMLC); Radio Resource LCS


Protocol (RRLP). 1998.

1
2
3

GSM 04.71

Digital cellular telecommunications system (Phase 2+);


Mobile radio interface layer 3 location services specication; Formats and coding. 1998.

4
5
6
7

GSM 08.08

Digital cellular telecommunications system (Phase 2+);


Mobile Switching Centre - Base Station System (MSC BSS) interface; Layer 3 specication. 1998.

8
9
10
11

GSM 09.02

Digital cellular telecommunications system (Phase 2+);


Mobile Application Part (MAP) specication. 1998.

12
13
14
15

GSM 09.08

Digital cellular telecommunications system (Phase 2+);


Application of the Base Station System Application Part
(BSSAP) on the E-interface. 1998.

16
17
18
19

GSM 09.31

Digital cellular telecommunications system (Phase 2+);


Location Services (LCS); Base Station System Application
Part LCS Extension (BSSAP-LE). 1998.

20
21
22
23

3GPP Specifications:

24
25

TS 22.071

Location Services (LCS); Service description;Stage 1.


3GPP. 2003

26
27
28

TS 23.271

Functional Stage 2 Description of LCS. 3GPP. 2003.

29
30

TS 24.008

Mobile radio interface layer 3 specification; Core Network


Protocols - Stage 3 3GPP. 2003

31
32
33

TS 25.305

Stage 2 functional specification of User Equipment (UE)


positioning in UTRAN, 3GPP, 2004.

34
35
36
37

TS 25.331

Radio Resource Control (RRC) protocol specification,


3GPP, 2004.

38
39
40

TS 25.413

UTRAN Iu interface RANAP signalling, 3GPP, 2004.

41
42

TS 25.453

UTRAN Iupc interface Positioning Calculation Application Part (PCAP) signaling, 3GPP, 2004.

43
44
45

TS 43.059

Functional stage 2 description of Location Services (LCS)


in GERAN, 3GPP, 2004.

46
47
48

TS 44.018

Mobile radio interface layer 3 specification; Radio


Resource Control (RRC) protocol, 3GPP, 2004.

49
50
51
52

TS 29.002

Mobile Application Part (MAP) Specification. 3GPP. 2003.

TS 44.031

Mobile Station (MS) - Serving Mobile Location Centre


(SMLC) Radio Resource LCS Protocol (RRLP). 3GPP.
2003.

53
54
55
56
57
58

TS 44.071

Location Services (LCS); Mobile radio interface layer 3

59
60

1 Introduction

1-3

ANSI/J-STD-036-B

Location Services (LCS) specification. 3GPP. 2003

1
2
3
4

TS 48.008

Mobile-services Switching Centre - Base Station System


(MSC - BSS) interface; Layer 3 specification. 3GPP. 2003

TS 49.008

Application of the Base Station System Application Part


(BSSAP) on the E-interface. 3GPP. 2003

TS 49.031

Location Services (LCS); Base Station System Application


Part LCS Extension (BSSAP-LE). 3GPP. 2003

5
6
7
8
9
10
11
12
13

International Telecommunication Union Telecommunication Standardization Sector (ITU-T):

14
15

Q.762

ITU-T Recommendation Q.762, Signalling System No. 7 ISDN user part general functions of messages and signals,
2000.

Q.763

ITU-T Recommendation Q.763, Signalling System No. 7 ISDN user part formats and codes, 2000.

16
17
18
19
20
21
22

US Federal Communications Commission:

23
24

R&O-1

Revision of the Commissions Rules to Ensure Compatibility with Enhanced 911 Emergency Calling Systems:
Report and Order and Notice of Further Rulemaking, FCC,
1996.

R&O-3

Revision of the Commissions Rules to Ensure Compatibility with Enhanced 911 Emergency Calling Systems:
Third Report and Order, FCC, 1999.

FCC 03-262

FCC 03-262, CC Docket No. 94-102, RM-8143,


Memorandum and Order, Revision of the Commissions
Rules to Ensure Compatibility with Enhanced 911
Emergency Calling Systems, Non-Initialized Phones,
October 21, 2003.

SCTP

RFC 2960: Stream Control Transmission Protocol, IETF,


October 2000.

TCP

RFC 793: Transmission Control Protocol, IETF,


September 1981.

IP

RFC 791: Internet Protocol, IETF, September 1981.

M3UA

RFC 3332: Signaling System 7 (SS7) Message Transfer


Part 3 (MTP3) User Adaptation Layer (M3UA), IETF,
September 2002.

25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

IETF:

40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

National Institute of Standards and Technology:


SHA-1

FIPS 180-1, Secure Hash Algorithm, 1995.

56
57
58
59
60

1-4

1 Introduction

ANSI/J-STD-036-B

Definitions and Acronyms


AOA: Angle of Arrival
AFLT: Advanced Forward Link Trilateration.
AGPS: Assisted GPS.

1
2
3
4
5
6
7
8

ALI: Automatic Location Identification.

9
10

ANI: Automatic Number Identification.

11
12

BSC: Base Station Controller.


BSS: Base Station Subsystem.

13
14
15

BSSMAP: Base Station System Management Application Part.

16

BTS: Base Transceiver Station.

18

17

19

Callback#: An emergency services callback number.

20
21

CAMA: Centralized Automatic Message Accounting.


CAS: Call Associated Signaling.
CGL: Calling Geodetic Location.
CgPN: Calling Party Number.

22
23
24
25
26
27
28

CM: Connection Management.

29
30

CPE: Customer Premises Equipment.

31
32

CPSMC: CDMAPSMMCount Parameter.


CPSML: CDMAPSMMList Parameter.

33
34
35

CRDB: Coordinate Routing Database.

36

CTRPT: CallTerminationReport INVOKE.

38

37

39

ctrpt: CallTerminationReport RETURN RESULT.

40
41

CTRT: Call Termination Report Timer.


EFLT: Enhanced Forward Link Trilateration.
EACC: Emergency Area Congestion Control
ECAR: Emergency Call Attempt Reporting

42
43
44
45
46
47
48

ELID: Emergency Location Information Delivery.

49
50

E-MF: Enhanced MF (20 digit signaling).

51
52

ESID: Emergency Subscriber Information Delivery


Emergency Services Call (ESC): A call requiring connection to a Public Safety Answering Point (PSAP). The digits 9-1-1 require this treatment
in the United States.

53
54
55
56
57
58
59
60

2 Denitions and Acronyms

1-5

ANSI/J-STD-036-B

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

Emergency Services Message Entity (ESME): The point of interface in an


emergency services network to a wireless network for out-of-band
messages related to emergency calls.
Emergency Services Network Entity (ESNE): An entity in the emergency services network which serves as the point of interface to an MSC for
voice or Telecommunications Device for the Deaf (TDD)/Teletypewriter (TTY) services.
Emergency Services Routing Digits (ESRD): A digit string that uniquely
identifies a base station, cell site, or sector that may be used to route
emergency calls through the network.
Emergency Services Routing Key (ESRK): A digit string that uniquely identifies an ongoing Emergency Services Call and it is used to correlate
the Emergency Services Call with the associated data messages. It
may also identify an Emergency Services Zone and it may be used
to route the call through the network.
E-OTD: Enhanced Observed Time Difference.
ESC: Emergency Services Call.

23
24

ESME: Emergency Services Message Entity.

25
26

ESN: Electronic Serial Number.

27
28
29
30
31
32
33

ESNE: Emergency Services Network Entity.


ESP: Emergency Services Protocol.
ESPOSREQ: EmergencyServicesPositionRequest INVOKE.
esposreq: EmergencyServicesPositionRequest RETURN RESULT.

34
35

ESPRT: Emergency Services Position Request Timer.

36
37
38
39
40
41
42

ESRD: Emergency Services Routing Digits.


ESRK: Emergency Services Routing Key.
ESZ: Emergency Services Zone.
ETSI: European Telecommunications Standards Institute.

43
44

FCC: US Federal Communications Commission.

45
46

FLASHREQ: FlashRequest INVOKE.

47
48
49
50
51
52
53

flashreq: FlashRequest RETURN RESULT.


FR: Full Rate.
FRT: Flash Request Timer.
GDP: Generic Digits Parameter.

54
55

GMLC: Gateway Mobile Location Center.

56
57
58
59

GPDT: Geo Position Directive Timer.


GPOSDIR: GeoPositionDirective INVOKE.

60

1-6

2 Denitions and Acronyms

ANSI/J-STD-036-B

gposdir: GeoPositionDirective RETURN RESULT.

1
2

GPOSREQ: GeoPositionRequest INVOKE.

3
4

gposreq: GeoPositionRequest RETURN RESULT.


GPRT: Geo Position Request Timer.
GPS: Global Positioning System.
GSM: Global System for Mobile communications.

5
6
7
8
9
10
11

HR: Half Rate.

12
13

IAM: Initial Address Message.

14
15

IMEI: International Mobile Station Equipment Identity.


IMSI: International Mobile Subscriber Identity.

16
17
18

Initial Position: The position result obtained at the beginning of an emergency


services call.

19

INITREQT: Initial Request Timer.

22

20
21

23

Interim Position: Position that is obtained in time for use in routing an ESC.
It may be of lower accuracy than the initial position. It is not included in CAS signaling to the PSAP.

24
25
26
27

IP: Internet Protocol.

28
29

IPFT: Intersystem Position Request Forward Timer.


IPRT: Intersystem Position Request Timer.

30
31
32

ISPOSREQ: IntersystemPositionRequest INVOKE.

33

isposreq: IntersystemPositionRequest RETURN RESULT.

35

34

36

ISPOSREQFWD: IntersystemPositionRequestForward INVOKE.

37
38

isposreqfwd: IntersystemPositionRequestForward RETURN RESULT.


ISUP: Integrated Services digital network User Part.
LCS: Location Service.
LCSCID: LCS_Client_ID parameter.

39
40
41
42
43
44
45

LMSI: Local Mobile Subscriber Identity.

46
47

LMU: Location Measurement Unit.

48
49

LPDE: Local Position Determining Entity.


LSB: Least Significant Bit.

50
51
52

LSP: Location Services Protocol.

53

M: Mandatory.

55

54

56

M3UA: MTP3 User Adaptation Layer.

57
58

MAP: Mobile Application Part.

59
60

2 Denitions and Acronyms

1-7

ANSI/J-STD-036-B

MDN: Mobile Directory Number.

2
3

ME: Mobile Equipment.

4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

MEID: Mobile Equipment Identifier.


MSSTAT: Mobile Station Status.
MIN: Mobile Identification Number.
Mobile Equipment Identifier: A 14 hexadecimal digit equipment identifier. It
is a superset of the IMEI, allocated from a distinct portion of the total
numbering space.
Mobile Position Center (MPC): The MPC serves as the point of interface to
the wireless network for the location network. The MPC serves as
the entity which retrieves, forwards, stores and controls position
data within the location network. It can select the PDE(s) to use in
position determination and forwards the position to the requesting
entity or stores it for subsequent retrieval. In the case of a PDE with
autonomous determination capability, the MPC receives and stores
the position estimation for subsequent retrieval. The MPC may restrict access to position information (e.g., require that the MS be engaged in an emergency services call or only release position
information to authorized nodes).

26
27
28

MOBINFO: Information regarding the MS radio access - MobInfo_AMPS,


MobInfo_CDMA, MobInfo_NAMPS or MobInfo_TDMA.

29
30

MPC: Mobile Position Center.

31
32
33
34
35
36
37
38
39
40
41
42

MPCAP: Mobile Position Capability.


MS: Mobile Station.
MS-Assisted Positioning: The network requires positioning assistance information from the MS in order to calculate position information.
MS-Based Positioning: The MS is capable of detecting a navigation signal
without any help from the base station. The mobile station is capable
of autonomously calculating its own position.
MSB: Most Significant Bit.

43
44

MSC: Mobile Switching Center.

45
46

MSEIA: Mobile Station Emergency Information Assistance

47
48
49
50
51
52
53

MSID: Mobile Station Identifier (e.g., MIN or IMSI).


MSISDN: Mobile Station International ISDN Number.
MTP1: MTP Layer 1.
MTP2: MTP Layer 2.

54
55

MTP3: MTP Layer 3.

56
57

NCAS: Non Call Associated Signaling.

58
59
60

1-8

2 Denitions and Acronyms

ANSI/J-STD-036-B

Network-Assisted Positioning: The MS requires positioning assistance information from the network in order to calculate position information.

1
2
3

Network-Based Positioning: The Network is capable of determining position


of the MS based on normal RF emissions without any additional
navigational information from the MS.

4
5
6
7

O: Optional.

8
9

ORREQ: OriginationRequest INVOKE.

10
11

orreq: OriginationRequest RETURN RESULT.


PCS: Personal Communications Services.

12
13
14

PDE: Position Determining Entity.

15

Phase I Location: The cellsite or sector currently serving a mobile.

17

16

18

Phase II Position Information: Position available for the mobile in accordance


with the US FCC mandate.

19
20
21

PLMN: Public Land Mobile Network.

22
23

POI: Point of Interface.


PosFailure: Information regarding a failed position request.

24
25
26

PosInfo: Information regarding an MSs precise position.

27

Position Determining Entity (PDE): The PDE determines the precise position
or geographic location of a wireless terminal when the MS starts a
call or while the MS is engaged in a call. Each PDE supports one or
more position determining technologies. Multiple PDEs may serve
the coverage area of an MPC and multiple PDEs may serve the same
coverage area of an MPC utilizing different position determining
technologies.

29

POSROUTREQ: PositionRouteRequest INVOKE.

28

30
31
32
33
34
35
36
37
38

posroutreq: PositionRouteRequest RETURN RESULT.

39

POST: Position Timer.

41

40

42

PRRT: Position Route Request Timer.

43
44

PSAP: Public Safety Answering Point.


Pseudo-ESN: A 32-bit ESN with the first 8 bits set to decimal 128 and the remaining 24 set to a SHA-1 hash of the MEID.
PSMM: PilotStrengthMeasurement Message

45
46
47
48
49
50

PSTN: Public Switched Telephone Network.

51

public safety answering point: A PSAP is an emergency services network element that is responsible for answering emergency calls.

53

52

54
55

pull: Request of information from an emergency service network.

56
57

push: The autonomous sending of information toward the emergency service


network.

58
59
60

2 Denitions and Acronyms

1-9

ANSI/J-STD-036-B

QoS: Quality of Service.

2
3

R: Required.

4
5
6
7
8
9
10

RFC: Request for Comment (IETF Standard).


RNS: Radio Network Subsystem (for UMTS).
SAMPS: System Assisted Mobile Positioning through Satellite.
SCCP: Signaling Connection Control Part.

11
12

SDCCH: Standalone Dedicated Control Channel.

13
14
15
16
17
18
19
20
21

selective router: A Selective Router is an emergency services network element that is responsible for routing incoming emergency calls to the
appropriate PSAP, and may be responsible for other functions, such
as redirecting calls from a primary PSAP to a secondary PSAP. The
specification of Selective Router functionality is outside the scope
of this document.
SMDPP: SMSDeliveryPointToPoint INVOKE.

22
23

smdpp: SMSDeliveryPointToPoint RETURN RESULT.

24
25
26
27
28
29
30

SMLC: Serving Mobile Location Center.


SMT: Short Message Delivery Timer.
SHH: SpecialHandling parameter
SME: Short Message Entity

31
32

SMD-ACK: Air interface Short Message Delivery Acknowledge message

33
34

SMDPP: Short Message Delivery Point-to-Point INVOKE

35
36
37
38
39
40
41

smdpp: Short Message Delivery Point-to-Point RETURN RESULT


SMD-REQ: air interface Short Message Delivery Request message
SMT: Short Message Delivery Point-to-Point timer
S/R: Selective Router.

42
43

TA: Timing Advance.

44
45
46

tandem: An intermediate switch (e.g., Access Tandem) that has normal PSTN
routing capabilities, but does not have selective routing capability.

47
48
49
50
51
52
53

TCAP: Transaction Capabilities Application Part.


TCH-FR: Traffic Channel - Full Rate.
TCH-HR: Traffic Channel - Half Rate.
TCP: Transmission Control Protocol.

54
55

TDOA: Time Difference of Arrival.

56
57
58
59

TMSI: Temporary Mobile Subscriber Identity.


TPRIO: Teleservice_Priority Parameter.

60

1-10

2 Denitions and Acronyms

ANSI/J-STD-036-B

TOA: Time of Arrival.

1
2

UIMID: A User Identification Module Identifier, identical to ESN in format,


but assigned from a distinct portion of the numbering space.

3
4
5

UMTS: Universal Mobile Telecommunications System.

6
7

UTC: Coordinated Universal Time.


VLR: Visitor Location Register.

8
9
10

VMSC: Visited MSC.

11

WGS-84: World Geodetic System 1984.

13

12

14

WZ1: World Zone 1.

15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2 Denitions and Acronyms

1-11

ANSI/J-STD-036-B

1
2
3
4
5

Chapter 2: Stage 1 Emergency Services


Service Descriptions

6
7
8
9
10
11
12
13
14
15
16
17

Introduction

18

This chapter describes emergency services from the perspective of a user. Normally the MS subscriber is the
user, but for the most part the emergency services are provided transparently to the subscriber. Most of the
services are network services that deliver information about an emergency call or caller. The user of these
services is normally some device, although the ultimate user is the PSAP call taker. This description focuses
on the network services apart from the devices and the humans that use them.

19
20
21
22
23
24

Wireless as used in this Standard refers to cellular, Personal Communication Services, satellite and other
commercial mobile radio services. Wireless does not apply to cordless telephones or to private radio
systems.

25
26
27
28
29
30

1.1

Emergency Location Information Delivery (ELID)

31

Emergency Location Information Delivery (ELID) delivers the position (e.g., latitude and longitude) of an
emergency services caller to the Emergency Services Provider. The position is delivered in addition to the
identification of the callers base station, cell site, or sector.

32
33
34
35

ELID may optionally deliver position after an emergency services provider request during an emergency
services call (ESC).

36
37
38
39
40
41

Assumptions

2.1

Common Assumptions

42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

The following are common assumptions that are applicable both for ANSI-41 and GSM/UMTS systems:
a. Phase II position information can be delivered to the Emergency Services Provider by two
methods:
i. Initial position may be reported during call setup signaling using Call Associated
Signaling (CAS) if:
1. ISUP signaling is being used, and
2. Position information is available in time.
ii. Initial or updated position may be obtained during an Emergency Services Call
(ESC) using non-call associated signaling (NCAS):
1. by the Emergency Services Provider pulling the information as it is
required.

60

2-1

1 Introduction

ANSI/J-STD-036-B

b. The maximum period of time that an ESC can be delayed while position information is
being obtained is a local configuration option.

1
2
3

c. This Standard will support providing updated mobile position upon request from an
emergency services network.
d. An ESNE is closely associated with an ESME. If an ESNE requires additional information
it can get that information from its associated ESME. The interface between an ESNE and
ESME is outside the scope of this Standard, but is necessary for the ESNE to act upon information in the ESME.

4
5
6
7
8
9
10

e. The mapping of ESNE and ESME onto the physical elements of a network is outside the
scope of this Standard.

11
12

f. ESRD or ESRK shall be used to route a call to an ESNE.

13

g. The method defined in this document for conveying position information to the Emergency
Services Provider is intended to support all positioning technologies.

15

h. ESCs and data are correlated using either a callback number or a ESRK.
i. MSID translation to TMSI may have to be in the VLR/MSC.
j. NCAS Pull of updated or last known position after call release is not a requirement.
k. For NCAS Pull, the ESME routes the position request to the correct MPC/GMLC based on
the ESRK or ESRD provided by the wireless network during the emergency call setup.
l. NCAS Pull may be supported to enable an emergency services provider to request the
initial, the updated or the last known position of an MS that has originated an emergency
services call.
m. Pull of position between an MPC or GMLC and the ESME is supported.

14

16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

2.2

ANSI-41 Assumptions

31
32

The following items are basic understandings used during the development of these recommendations:
a. Both push and pull are supported between Position Determining Entity (PDE) and Mobile
Position Center (MPC).
b. Interconnections to the PDE other than the MPC or MSC are beyond the scope of this
Standard.
c. MDN to MSID translation may have to be in the HLR. It may be done in the MSC for
currently registered MSs. It may be done in the MPC for currently cached records.
d. The MPC caches information associated with an emergency services call (ESC). The information can be associated using the ESRK, Callback number or BillingID as a key.

33
34
35
36
37
38
39
40
41
42
43
44

e. PDEs may determine the position of an ESC caller autonomously and forward that information with associated mobile information to the MPC.
f. The ESRK is a unique identifier for ongoing emergency services calls and has the
following requirements:

45
46
47
48
49

i. Each ESRK is unique within each MPC.


ii. Each ESRK identifies an MPC at a minimum resolution within a wireless network
(although it may identify a cell site, base station, or cell or portion thereof).
iii. Each ESRK may identify a PSAP, an Emergency Services Zone (ESZ), or both.
g. Selection of an Emergency Services Zone based on Phase II geographic position information is optional. Therefore, Emergency Services Call Routing using CRDB is optional.
If used, the CRDB database may reside in the wireless network or in the emergency
services network.

50
51
52
53
54
55
56
57
58
59
60

1 Introduction

2-2

ANSI/J-STD-036-B

h. The MSC is responsible for providing current mobile information (i.e., MobInfo), not
initial.

1
2
3

i. The ANSI-41 Sections of this Standard only show solutions involving a centralized or
network based PDE. However, as an alternative the PDE may be co-located with the
Serving BS. In this case the MPC communicates with the LPDE based on the call flows
outlined in informative Annex B.

4
5
6
7
8

j. The MPC can determine the context of the GPOSREQ and will determine whether to use
the interim position or wait for the final position from the PDE.

9
10

k. Through provisioning, the MPC can determine whether the PDE supports interim position
or not.

11
12
13

l. A PDE that supports interim position must be able to interact with an MPC that has not been
upgraded to support interim position.

14
15
16
17
18
19
20
21
22
23
24

2.3

GSM/UMTS Assumptions
a. The GMLC interface to an ESME may be provided from a different GSM/UMTS network
than the one in which a particular emergency call has originated. This depends on the
existence of a suitable agreement between the PSAP and the operators of the two GSM/
UMTS networks. The availability of such an arrangement provides additional interconnection flexibility to both GSM/UMTS network operators and emergency services
providers.

25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

b. The details of positioning methods used in GSM/UMTS networks are outside the scope of
this Standard.
c. The detailed content and encoding of signaling messages used inside a GSM/UMTS
network to obtain the position of an MS and convey this to an emergency services provider
are defined in the specific 3GPP standards referenced in this Standard. The detailed content
and encoding of the signaling messages exchanged between a GSM/UMTS network and
an emergency services provider (or its surrogate) to convey location and related information are defined in this Standard.
d. For NCAS only solutions (i.e., CAS push is not used or attempted), a GSM/UMTS network
shall support conveying an ESRK to an ESNE in order to support CAMA trunk signaling
to the S/R and/or to the PSAP. Any ESRK so provided has the following properties:

41
42
43

44
45
46

47
48

The ESRK is unique to the specific GSM/UMTS network.


The ESRK may be assigned by either the visited MSC from which the Emergency Services Call originated or by the GMLC connected to the visited MSC
from which the Emergency Services Call originated.
The ESRK uniquely identifies the emergency services call and its associated
MS within the GSM/UMTS network for at least the duration of the call.
The ESRK shall identify the GMLC used by the network for communicating
with the ESME.
The ESRK may identify an Emergency Services Zone (ESZ).

49
50
51
52
53
54
55
56
57
58
59

e. In a GSM/UMTS network, the callback number sent to the ESNE is normally the MSISDN
of the ESC calling MS. However, a GSM/UMTS network may substitute a non-dialable
callback number (as described in normative Annex C) for an MSISDN if the MSISDN is
not available (e.g., unregistered MS) or cannot be passed to the ESNE in the call setup (e.g.,
MSISDN not in WZ1). The non-dialable callback number shall identify the calling ME and
is derived from the IMEI.
f. In order to support the option of latitude/longitude based routing to both the correct ESNE
and the correct ESME serving an ESC calling MSs initial geographic location, a unique
ESRD for each ESZ within a cell site may be assigned at the Serving MSC. A serving MSC

60

2-3

1 Introduction

ANSI/J-STD-036-B

will thus possess a set of unique ESRDs identifying all ESZs to which an ESC in its serving
geographical area could be directed. Latitude/longitude based routing can then be
supported by assigning the ESRD belonging to the serving MSC that identifies the serving
cell and the ESZ associated with the initial position of an ESC calling MS. Note: this
assumption implies that there may be more than one ESRD per cell.

1
2
3
4
5
6

g. For NCAS scenarios, the VMSC may push the initial MS position data to the GMLC when
it becomes known. The GMLC shall store the initial position along with other call related
information. The VMSC shall then notify the GMLC when the emergency services call has
ended.
h. For NCAS scenarios, the VMSC may instead push the interim MS position data to the
GMLC when it becomes known. The GMLC will return an ESRK or ESRD to the VMSC
for the purposes of routing the ES call. At some point later the initial position will be
returned to the GMLC from the VMSC and made available for pull by the ESME. The
VMSC shall notify the GMLC when the emergency services call has ended.

7
8
9
10
11
12
13
14
15
16

i. For CAS scenarios, where subsequent requests for MS position are not allowed, the procedures in assumptions g and h are optional.
j. When NCAS Pull is supported during an emergency services call, a GMLC identifies the
VMSC for the emergency services call by the MSC address previously stored for that call
in the GMLC. For NCAS Pull, the ESME will route to the correct GMLC based on the
ESRK or ESRD and Callback Number provided by the GSM/UMTS network.
k. For NCAS scenarios, the authentication of the GMLC or ESME need not be supported.
l. The maximum period of time that a GMLC waits for initial position information after
reception of an NCAS Pull request is a local configuration option (INITREQT).
m. An MSC may be connected to more than one ESNE and the mechanism used to provide the
emergency callers initial position (i.e., CAS Push, NCAS Pull or both) may be the same
or different for each ESNE. For each emergency call, the MSC needs to determine which
ESNE is to be contacted and which mechanism is to be used to provide the emergency
callers initial position.
n. An ESRD for each cell may be provisioned at the VMSC when routing of Emergency Calls
by a GMLC, including routing based on geographical coordinates, is supported.

17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

1 Introduction

2-4

ANSI/J-STD-036-B

1
2

Chapter 3: Functional Overview, ANSI-41

3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

Introduction
This chapter describes emergency services from a network perspective. A network reference model is
developed to define a set of network entities and interfaces between them. A set of messages is defined to
transfer information and requests between the network entities.
For this document, position means a point on earth that can be described by coordinates, such as latitude and
longitude. Location in this document is an area. Location may be the area served by a VLR, the area served
by an MSC, a paging or location area, the area covered by a given cell site or sector, the area served by a
particular emergency services agency, or the area associated with a particular street address. This definition
may be at odds with other forum, but it is consistent with the usage of terms used in wireless mobility
management protocols such as ANSI-41 and GSM.
Phase I emergency services requires the passing of the location of base station, cell site or sector serving an
emergency services caller. This information was passed as Emergency Services Routing Digits (ESRD)
during call setup as the called number, as an ISUP Generic Digits Parameter, or both.
Position may be used in emergency services networks for two basic purposes: to route the Emergency
Services Call (ESC) for proper handling and to aid in resolving the emergency situation. How emergency
services use the position information is beyond the scope of this Standard, however some basic understanding
is useful.
ESC routing can select a Selective Router (S/R) or a particular PSAP. In general, a geographic area is divided
into Emergency Services Zones (ESZs). Each zone has assigned to it a primary PSAP, a secondary PSAP,
and a set of emergency response agencies (e.g., fire, police, ambulance). The ESZs are non-overlapping and
every point in the emergency services area is within one ESZ.
In resolving an emergency, the position information may be used by the emergency services network in a
variety of ways. For example, it may be used to plot a point on a map, to provide the nearest known street
address, or as input to navigation equipment in the emergency response vehicle (e.g., helicopter ambulance).

43
44
45
46
47
48
49
50
51
52
53
54
55
56

The position information may be delivered to the emergency services network in two basic ways: with the
call as part of the call setup information or through a separate data service. The former is known as Call
Associated Signaling (CAS) since the position information is delivered in the call signaling. The latter is Non
Call Associated Signaling (NCAS) and the messages delivered by the data service must be correlated with
the call by parameters carried in the message.
With CAS, the wireless network pushes the position information to an Emergency Services Network Entity
(ESNE). With NCAS, an Emergency Services Message Entity (ESME) pulls the position information from
the wireless network.
Call setup may be delayed while position information is being determined if it will be sent in a CAS push
or used for routing. The maximum period of time that a call will be held up is provisionable on a per system
basis.

57
58
59
60

3-1

ANSI/J-STD-036-B

Methodology

1
2

Stage 2 describes the emergency call support services from the network perspective. Basically this involves
moving information from one system to another. Information is generated, stored, or processed on one
system, but the data is used by another system to perform some function.

3
4
5
6

A network reference model is developed to describe the functional partitioning of a system. The functions are
divided among several functional entities. This division is based on traditional functional separations plus
some separation to allow the services to be built and deployed in a variety of configurations. Communication
paths or reference points between the network entities are also defined to indicate where information can be
exchanged. These network reference points allow specific interfaces to be discussed and defined.

Once the network reference model is developed, the next step is to define the information that must be passed
from one network entity to another. Information that can be passed at the same time is collected together to
form messages. This Standard has messaging that occurs between wireless network entities; between wireless
network entities and emergency services network entities; and between MSs and wireless network entities.

13

8
9
10
11
12

14
15
16
17
18
19

Network Reference Model

20
21

A network reference model for emergency services for wireless subscribers is shown in Figure 3-1.

22
23
24
25
26
27
28
29
30

MSC

MSC
Ai

Di

31

Emergency Services
Network

32
33
34

Emergency
Services
Network
Entity
E12

E3
CRDB

These interfaces
are beyond the
scope of this
document

35
36
37
38
39

PSAP

40
41
42
43

E11

PDE

E5

MPC

E2

Emergency
Services
Message
Entity

44
45
46
47
48
49
50
51
52
53
54
55
56

Figure 3-1:

57

Network Reference Model

58
59
60

2 Methodology

3-2

ANSI/J-STD-036-B

1
2

Network Entities
This section describes the functionality of the network entities of the network reference model. Message
routing and transmission facilities are considered to be outside of the network reference model, even though
they provide essential services.

4
5
6
7
8
9

4.1

Coordinate Routing Database (CRDB)

10

The CRDB provides a translation between a given position expressed as a latitude and longitude and a string
of digits identifying an Emergency Services Zone (ESZ).

11
12
13
14
15

4.2

Emergency Services Message Entity (ESME)

16

The ESME routes and processes the out-of-band messages related to emergency calls. This may be incorporated into selective routers (also known as Routing, Bridging and Transfer switches) and Automatic Location
Information (ALI) database engines. The structure of the Emergency Services Network is beyond the scope
of this Standard, although some insight may be gained from informative Annex A.

17
18
19
20
21
22
23
24

4.3

Emergency Services Network Entity (ESNE)


The ESNE routes and processes the voice band portion of the emergency call. This is composed of selective
routers (also known as Routing, Bridging and Transfer switches). The structure of the Emergency Services
Network is beyond the scope of this Standard, although some insight may be gained from
informative Annex A.

25
26
27
28
29
30
31
32

4.4

33

Mobile Position Center (MPC)


The MPC selects a PDE to determine the position of a MS. The MPC may restrict access to position information (e.g., require that the MS be engaged in an emergency services call or only release position information to authorized nodes).

34
35
36
37
38
39

4.5

40

Mobile Switching Center (MSC)


The MSC provides radio contact with MSs making emergency calls. The MSC may hand off the radio control
to another MSC, but the emergency call remains anchored with the MSC establishing the first radio contact.

41
42
43
44
45

4.6

Position Determining Entity (PDE)

46

The PDE determines the position of a wireless terminal when the MS starts a call or while the MS is engaged
in a call. Each PDE supports one or more position determining technologies. Multiple PDEs using the same
technology may serve the coverage area of an MPC and multiple PDEs each using a different technology may
serve the same coverage area of an MPC.

47
48
49
50
51
52
53

4.7

Public Safety Answering Point (PSAP)

54
55
56

A PSAP is the terminating end-point in an emergency services network responsible for answering emergency
services calls.

57
58
59
60

3-3

4 Network Entities

ANSI/J-STD-036-B

Messages Across Network Interfaces


This section describes the protocols and messages used on the network interfaces for Emergency Location
Information Delivery.

1
2
3
4
5
6

Interface
Ai Di

Functional Entities
MSC - ESNE

MSC - MSC

Protocol
ISUP or MF

Message (s)
IAM. See normative Annex D

ANSI-41

InterSystemPositionRequestForward

7
8
9
10

FlashRequest

11
12

SMSDeliveryForward

13
14

E2

MPC - ESME

ESP

SMSDeliveryBackward
EmergencyServicesPositionRequest

E3

MSC - MPC

ANSI-41

InterSystemPositionRequest

15
16
17
18

OriginationRequest

19
20

CallTerminationReport

21
22

E5

PDE - MPC

SMSDeliveryPointToPoint
LSP or ANSI-41 GeoPositionRequest

23
24
25

GeoPositionDirective
InterSystemPositionRequest
SMSDeliveryPointToPoint

26
27
28
29
30

E11

CRDB - MPC

LSP

CallTerminationReport
PositionRouteRequest

E12

MSC-PDE

ANSI-41

SMSDeliveryPointToPoint

31
32
33

InterSystemPositionRequest

34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

4 Network Entities

3-4

ANSI/J-STD-036-B

1
2
3
4
5

Network Entity Relationships


Each MSC is associated with only one MPC, but each MPC may be associated with multiple MSCs. PDEs
are associated with only one MPC, but each MPC may have multiple PDEs associated with it.

6
7
8
9

MSC

10
11

MPC

12

CRDB

13
14

Key

15
16
17
18

PDE

19

Many

One

Many

Many

20
21
22
23

Figure 3-2:

Entity Relationship Diagram

24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

3-5

6 Network Entity Relationships

ANSI/J-STD-036-B

Chapter 4: Stage 2 Emergency Services


Network Description, ANSI-41.3xx

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

The scenarios in this chapter show only the parameters that are relevant to a particular scenario and do not
show all of the parameters that are needed for the transaction. Consult Stage 3 documentation for specific
parameter requirements.

16

For PDEs using network based location technology, the SMDPP operations are not necessary. These PDEs
are not required to support SMS capabilities or the E12 (MSC-PDE) interface.

20

For PDEs supporting handset based or handset assisted position determination, SMDPP operations are used
to communicate between the PDE and MS. This communication may occur after the MPC originated
GPOSREQ and prior to the PDE gposreq. This applies to each scenario that includes an MPC originated
GPOSREQ to the PDE. See Section 2 PDE to MS Scenarios for Handset-Based PDE on page 4-28.
This section includes new information flows for ANSI-41.

17
18
19

21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

4-1

ANSI/J-STD-036-B

1
2

Emergency Location Information Delivery (ELID)


Scenarios

1.1

ELID Using CAS Push

3
4
5
6
7
8
9
10

1.1.1

PDE Queried for Position


This scenario shows a position request and delivery of position information with a CAS push during
call setup.

11
12
13
14
15
16
17
18

MS

MSC

PDE

MPC

ESNE

19
20
21
22

ESC Invocation

23

ORREQ [MOBINFO, MPCAP]

24

25
26

GPOSREQ [MOBINFO, POSREQTYPE(initial), MPCAP]

27

ORT
GPRT
gposreq [POSINFO,POSRSULT(updated)]

28
29

30
31

orreq [GEOPOS]

32

POST

33

Call Setup IAM [GDP(ESRD), CgPN(Callback #), CGL(position)]

34

35
36
37

Figure 4-1:

PDE Queried for Position

38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

a. The MS invokes an Emergency Services Call.


b. The MSC requests the position of the MS with an ORREQ. The MPC starts the POST
timer.
c. The MPC relays the position request to the appropriate PDE with a GPOSREQ.
Optionally, a handset-based solution may have PDE to MS communication. See Section 2
PDE to MS Scenarios for Handset-Based PDE on page 4-28.
d. In this case, the PDE has not previously acquired the initial position of the MS. The PDE
determines the current position of the MS and returns the position information in a gposreq
with the PositionResult parameter set to Updated Position Returned.
e. The MPC cancels the POST timer and acknowledges the request in an orreq.
f. The MSC sets the call up toward the ESNE using an IAM including the received
geographic position.

55
56
57
58
59
60

4-2

1 Emergency Location Information Delivery (ELID)


Scenarios

ANSI/J-STD-036-B

1.1.2

PDE Autonomous Delivery of Position

This scenario shows the case where the PDE autonomously detects an Emergency Services Call and
pushes that information to the MPC to speed delivery of data for CAS delivery.

4
5
6
7

MS

MSC

PDE

MPC

ESNE

9
10
11

ESC Invocation

12
13
14

EmergencyCallDetected

15
16

GPOSDIR [POSINFO]
c

17
18

GPDT

19

gposdir [ ]

20
21

ORREQ [MOBINFO, MPCAP]

22
23

ORT

POST

orreq [GEOPOS]

24

25
26

Call Setup IAM [GDP(ESRD), CgPN(Callback #), CGL(position)]

27
28

Figure 4-2:

PDE Autonomous Delivery of Position


a. The MS invokes an Emergency Services Call.
b. The PDE autonomously determines an Emergency Services Call has originated and
computes the position of the handset.
c. The PDE forwards the position to the MPC using a GPOSDIR.
d. The MPC acknowledges receipt of the pushed position using a gposdir.

29
30
31
32
33
34
35
36
37
38

e. The MSC requests the position of the MS with an ORREQ.


f. The MPC replies to the position request in an orreq containing the cached position.

39
40
41

g. The MSC sets the call up toward the ESNE using an IAM including the received
geographic position.

42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

1.1.2 PDE Autonomous Delivery of Position

4-3

ANSI/J-STD-036-B

1
2

1.1.3

Timeout Waiting for Position


This scenario shows a position request that does not complete in time for delivery of position information with a CAS push during call setup.

3
4
5
6
7
8

MS

MSC

PDE

MPC

ESNE

10
11
12

ESC Invocation

13

ORREQ [MOBINFO, MPCAP]

14

15
16

ORT

17

GPOSREQ [MOBINFO, POSREQTYPE(initial), MPCAP]


POST

GPRT

18
19

orreq

20
21

Call Setup IAM [GDP(ESRD), CgPN(Callback #)]

22

23

gposreq [POSINFO, POSRSULT(updated)]

24

25
26
27

Figure 4-3:

Timeout Waiting for Position

28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

a. The MS invokes an Emergency Services Call.


b. The MSC requests the position of the MS with an ORREQ. Upon receipt of the ORREQ,
the MPC starts the POST timer.
c. The MPC relays the position request to the appropriate PDE with a GPOSREQ.
Optionally, a handset-based solution may have PDE to MS communication. See Section 2
PDE to MS Scenarios for Handset-Based PDE on page 4-28.
d. When the POST timer expires, the MPC returns the orreq.
e. The MSC sets the call up to the ESNE using an IAM, without the geographic position.
f. In this case, the PDE has not previously acquired the initial position of the MS. The PDE
determines the current position of the MS and returns the position information in a gposreq
with the PositionResult parameter set to Updated Position Returned where it is cached as
initial position by the MPC.

45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

4-4

1.1.3 Timeout Waiting for Position

ANSI/J-STD-036-B

1.1.4

Three-Way Call to PSAP After Intersystem Handoff

This scenario illustrates a a CAS push of position for a three-way emergency services call initiated
after intersystem handoff.

4
5

Serving

Anchor

MS

PDE

MPC

MSC

MSC

MPC

ESNE

9
10
11

ESC Invocation

12
13

FLASHREQ [MSID, DGTSDIAL, ESRD]


FRT

14
15

flashreq

ORREQ [MSID, ESRD, MPCAP]

16
17
18

ISPOSREQ [ POSREQTYPE (initial)]

20

21
22

ISPOSREQFWD [MPCAP, POSREQTYPE (initial)]


f
ISPOSREQ [MOBINFO, MPCAP, POSREQTYPE (initial)]

19

23
24

25
26

GPOSREQ [MOBINFO, MPCAP, POSREQTYPE (initial)]


GPRT
IPRT
gposreq [POSINFO, POSRSULT (updated)]

IPFT

ORT

IPRT

h
POST

28
29
30

31
32

isposreq [POSINFO, POSRSULT (updated)]

j
k

isposreq [POSINFO, POSRSULT (updated), MSCID (Serving), SCELLID]

35
36

37
38

orreq [DGTSDIAL, GEOPOS, GDP]


m
Call Setup IAM [GDP, CgPN (Callback #), CGL (position)]

33
34

isposreqfwd [POSINFO, POSRSULT (updated), MSCID (Serving), SCELLID]

Figure 4-4:

27

Three-Way Call to PSAP After Intersystem Handoff

39
40
41
42
43
44
45

a.

The MS originates an Emergency Services Call via 3-way calling while another call is in
progress.

b.

The Serving MSC sends a FLASHREQ toward the Anchor MSC.

c.

The Anchor MSC acknowledges the event with a flashreq.

d.

The Anchor MSC sends an ORREQ to the MPC associated with the Anchor MSC, the Anchor
MPC, and relays the ESRD parameter value received from the Serving MSC. The MPCAP
parameter is set to indicate the positioning capability of the MS.

46
47
48
49
50
51

e.
f.

The Anchor MPC sends an ISPOSREQ to the Anchor MSC to request MS position
information.
The Anchor MSC sends an ISPOSREQFWD toward the Serving MSC.

52
53
54
55
56
57
58
59
60

1.1.4 Three-Way Call to PSAP After Intersystem


Handoff

4-5

ANSI/J-STD-036-B

g.

The Serving MSC sends an ISPOSREQ to the MPC associated with the Serving MSC, the
Serving MPC. The MobInfo information is set appropriately for the served MS.

h.

In this scenario, there is no current position information available for the MS (e.g., GPOSDIR
was not received). The Serving MPC sends a GPOSREQ to the PDE selected for position
determination and includes the MS information received from the Serving MSC.

i.

In this scenario, the PDE determines the current MS position and returns the position
information to the Serving MPC in the gposreq. The POSRSULT parameter is set to
indicate Updated position returned.

2
3
4
5
6
7
8
9
10
11

Optionally, handset based geoposition determination may have PDE to MS communications.


See Section 3, PDE to MS Scenarios for Handset Based PDE.

12
13
14

j.

The Serving MPC sends an isposreq to the Serving MSC and relays the POSINFO and
POSRSULT parameters received from the PDE.

k.

The Serving MSC sends and isposreqfwd toward the Anchor MSC and relays the
POSINFO and POSRSULT parameters received from the Serving MPC.

l.

The Anchor MSC sends an isposreq to the Anchor MPC and relays the POSINFO and
POSRSULT parameters received from the Anchor MPC.

m.

The Anchor MPC stores the received position information and sends an orreq to the Anchor
MSC. The DGTSDIAL parameter is set to digits to route the call to the PSAP. In determining
the parameter values for the orreq, the MPC uses information received in the isposreq.

n.

The Anchor MSC sets the call up toward the ESNE. The IAM includes the GDP and position
information received from the Anchor MPC. This may result in routing to a PSAP not
associated to the geographical area of the cell/sector in which the call originated.

15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

4-6

1.1.4 Three-Way Call to PSAP After Intersystem


Handoff

ANSI/J-STD-036-B

1.2

ELID Using NCAS Pull

1
2
3

1.2.1

PDE Queried For Position

4
5

This scenario shows how the ESME retrieves a position from a wireless system. The MPC is
configured to immediately respond to the ORREQ. It is irrelevant whether the MS has subsequently
handed off or not since the responsibility for retrieving the position remains in the anchor system for
Emergency Services Calls originated in the anchor system.

6
7
8
9
10
11
12

MS

MSC

PDE

MPC

ESME

13

ESNE

14
15
16

ESC Invocation

17
18

ORREQ [MOBINFO, MPCAP]


ORT

19

orreq

20
21

POST
c

22
23

Call Setup [Callback#, ESRD]

GPOSREQ [MOBINFO, POSREQTYPE(initial), MPCAP]

27
28

ESPOSREQ [Callback#, ESRD, POSREQTYPE(initial)]


f

gposreq [POSINFO, POSRSULT(updated)]


ESPRT

25
26

GPRT

24

29
30
31

32
33

esposreq [POSINFO, POSRSULT(initial)]

34
35

Figure 4-5:

36

PDE Queried For Position

37

a. The MS invokes an Emergency Services Call.

38

b. The MSC initiates an ORREQ providing Mobile Information and MSID to the MPC.

40

c. The MPC returns a response immediately, but stores the MSID/Mobile Information.
d. The MSC routes the call toward the ESNE selected by the ESRD. See normative Annex D
for call setup signaling formats.
e. The MPC uses the information received in the ORREQ to request the PDE for initial
position of the MS.
Optionally, a handset-based solution may have PDE to MS communication. See Section 2
PDE to MS Scenarios for Handset-Based PDE on page 4-28.

39

41
42
43
44
45
46
47
48
49
50

f. The ESME autonomously requests the position of an MS with an ESPOSREQ toward the
MPC determined from the incoming trunk group, the known ESRD, or other means. This
request is asynchronous and due to the arrival of the Emergency Services Call at the ESNE.
g. In this case, the PDE has not previously acquired the initial position of the MS. The PDE
determines the current position of the MS and returns the position information in a gposreq
with the PositionResult parameter set to Updated Position Returned.
h. The MPC caches the position as initial position and returns the position in an esposreq to
the ESME.

51
52
53
54
55
56
57
58
59
60

1.2 ELID Using NCAS Pull

4-7

ANSI/J-STD-036-B

1
2

1.2.2

PDE Autonomous Delivery of Position


This scenario shows the case where the PDE autonomously detects an Emergency Services Call and
pushes the information to the MPC to be later retrieved by the ESME. The MPC is configured to
immediately respond to the ORREQ. It is irrelevant whether the MS has subsequently handed off or
not since the responsibility for retrieving the position remains in the anchor system for Emergency
Services Calls originated in the anchor system.

3
4
5
6
7
8
9
10
11
12

MS

MSC

PDE

MPC

ESME

ESNE

13
14
15

ESC Invocation

16
17
18

EmergencyCallDetected

19

ORREQ [MOBINFO, MPCAP]

20
21

ORT

22

POST

orreq

23
24

Call Setup [Callback#, ESRD]

25

26

GPOSDIR [MSID or TMSI, POSINFO]

27
28

GPDT
gposdir [ ]

29
30

31

ESPOSREQ [POSREQTYPE (initial), Callback#, ESRD]

32

33

ESPRT
esposreq [POSINFO, POSRSULT(initial)]

34
35

36
37
38

Figure 4-6:

PDE Autonomous Delivery of Position

39
40
41
42
43
44
45
46
47
48
49

a. The MS invokes an Emergency Services Call.


b. The PDE autonomously determines an Emergency Services Call has originated and
computes the position of the handset.
c. The MSC initiates an ORREQ to providing Mobile Information and MSID to the MPC.
d. The MPC returns a response immediately, but stores the MSID/Mobile Information for
future use.
e. The MSC routes the Emergency Services Call toward the ESNE selected by the ESRD. See
normative Annex D for call setup signaling formats.

50
51
52
53

f. The PDE has been autonomously collecting position for the mobile, and now provides it in
a GPOSDIR.
g. The MPC stores position as initial position and acknowledges this message.

54
55
56
57
58

h. The ESME requests the position information for an MS identified by its callback number
in an ESPOSREQ.
i. The MPC returns the position in the esposreq.

59
60

4-8

1.2.2 PDE Autonomous Delivery of Position

ANSI/J-STD-036-B

1.3

Emergency Services Call Routing and ELID

1
2
3

1.3.1

Routing Based on Position

4
5

This scenario shows the MPC, and optionally, the CRDB using position information from the PDE
to determine appropriate routing to the ESNE.

6
7
8
9
10

MS

CRDB

MSC

PDE

MPC

ESME

11

ESNE

12
13
14

ESC Invocation
a

15
16

ORREQ [MDN, BillingID, MPCAP, MOBINFO]

17

GPOSREQ [MOBINFO, POSREQTYPE(initial), MPCAP]


GPRT
gposreq [POSINFO, POSRSULT(updated)]

19

POST

22
23
24

PRRT

20
21

POSROUTREQ [Position]
ORT

18

25
26

posroutreq [Digits]

27
28
29

orreq [Digits(Dialed)(ESRK or ESRD)]

30
31

Call Setup [ESRK or (Callback# + ESRD)]

32
33
34

35
36

ESPOSREQ [ESRK or (Callback#+ESRD) POSREQTYPE(initial)]


esposreq [POSINFO]

37
38

ESPRT

39

40
41

42
43
44

Call Release

45
46

CALLTERMREP [MSID, BillingID]


CTRT

calltermrep [ ]

48

CALLTERMREP [MSID]
calltermrep [ ]

47

49
50
51

CTRT
q

52
53
54

Figure 4-7:

Routing Based on Position

55
56
57
58
59
60

1.3 Emergency Services Call Routing and ELID

4-9

ANSI/J-STD-036-B

a. The MS invokes an Emergency Services Call.

2
3
4
5
6
7

b. The MSC analyzes the digits dialed by the MS and sends an ORREQ to the MPC. MDN is
provided to include a callback number. The BillingID is provided to uniquely identify the
call.
c. Since the MPC has mobile information, it can query the proper PDE directly with a
GPOSREQ.

8
9
10

Optionally, a handset-based solution may have PDE to MS communication. See Section 2


PDE to MS Scenarios for Handset-Based PDE on page 4-28.

11
12
13
14
15
16
17
18

d. In this case, the PDE has not previously acquired the initial position of the MS. The PDE
determines the current position of the MS and returns the position information in a gposreq
with the PositionResult parameter set to Updated Position Returned where it is cached as
initial position by the MPC.
e. Optionally, the MPC may decide that the route must be determined from the MSs current
latitude-longitude position. The MPC uses the position to request a routing translation for
an emergency services zone from the CRDB with a POSROUTREQ.

19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

f. The CRDB returns the digits representing an emergency services zone (ESZ) to the MPC
with a posroutreq.
g. The MPC selects a PSAP based on the emergency services zone from the CRDB or from
the latitude and longitude of the mobile based on local procedures. The MPC then assigns
and returns a unique routable call identifier (ESRK) for the particular PSAP selected or an
ESRD in the orreq. See Chapter 8 and normative Annex D for the population of signaling
parameters.
h. The MSC routes the Emergency Services Call toward the PSAP selected by the ESRK or
ESRD. See normative Annex D for call setup signaling formats.
i. some time later
j. The ESME requests initial position.
k. The MPC returns the cached position.
l. some time later
m. The call is released.
n. The MSC notifies the MPC that resources assigned to the call (such as an ESRK) can be
released, by sending a CALLTERMREP.

40
41
42
43

o. The MPC acknowledges by sending a calltermrep.


p. Optionally, the MPC may notify the PDE, by sending a CALLTERMREP , that resources
assigned to the call can be released.

44
45

q. The PDE acknowledges by sending a calltermrep.

46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

4-10

1.3 Emergency Services Call Routing and ELID

ANSI/J-STD-036-B

1.3.2

Inter-MSC Routing Based on Position

1
2

This scenario shows how an Emergency Services Call originated as the second leg of a 3-way call after a
handoff obtains instructions for routing the call to the appropiate ESNE. An ESRK is assigned by the MPC
that is associated with the Anchor MSC.

4
5
6

Anchor

Serving

7
8

MS

PDE

MPC

MSC

MSC

MPC

CRDB

ESME

ESNE

10
11
12

ESC Invocation

FLASHREQ [Digits(dialed), ESRD]

13
14
15

FRT
flashreq

16
17

18
19

ORREQ [MSID, Callback#, ESRD, Digits(dialed)]

20

21
22

ISPOSREQ [POSREQTYPE(initial)]

23
24

ISPOSREQFWD [POSREQTYPE(initial), MPCAP]

25

26
27

ISPOSREQ [MOBINFO, POSREQTYPE(initial), MPCAP]


g

28
29

GPOSREQ [MOBINFO, POSREQTYPE(initial), MPCAP]

30

GPRT IPRT
IPFT
gposreq [POSINFO, POSRSULT(updated)]
isposreq [POSINFO, POSRSULT(updated)]

IPRT

32

33
34

POST

ORT

31

35
36
37

isposreqfwd [POSINFO, POSRSULT(updated)]


k

38
39

isposreq [POSINFO, POSRSULT(updated)]


l

40
41
42

POSROUTREQ [Position]

PRRT
posroutreq [Digits]

43
44

45
46

orreq [Digits(Dialed)(ESRK)]

47

48
49

Call Setup [ESRK]


p

50
51

Inter-MSC Routing Based on Position

55
56

ESPRT

57

Figure 4-8:

53
54

ESPOSREQ [ESRK, POSREQTYPE(initial)]


esposreq[ESRD, Callback #, POSINFO]

52

58
59
60

1.3.2 Inter-MSC Routing Based on Position

4-11

ANSI/J-STD-036-B

1
2

a. A call that has been handed-off from the Anchor MSC to the Serving MSC is in progress.
The MS invokes an Emergency Services Call.

3
4
5

b. The Serving MSC notifies the Anchor MSC of the event with a FLASHREQ.
c. The Anchor MSC acknowledges the event with a flashreq.

6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

d. The MSC analyzes the digits dialed by the MS and sends an ORREQ to the MPC.
e. The Anchor MPC, having not received the mobile information in the ORREQ, requests
position or mobile identification from the Anchor MSC with an ISPOSREQ.
f. The Anchor MSC, determining that the MS is handed off, forwards the request in an
ISPOSREQFWD.
g. The Serving MSC forwards the request for position to its MPC with an ISPOSREQ
including the mobile information.
h. Since the MPC has mobile information, it can query the proper PDE directly with a
GPOSREQ.
Optionally, a handset-based solution may have PDE to MS communication. See Section 2
PDE to MS Scenarios for Handset-Based PDE on page 4-28.
i. In this case, the PDE has not previously acquired the initial position of the MS. The PDE
determines the current position of the MS and returns the position information in a gposreq
with the PositionResult parameter set to Updated Position Returned.
j. The Serving MPC returns the position for the MS with an isposreq.
k. The Serving MSC returns the position with an isposreqfwd.
l. The Anchor MSC returns the position with an isposreq, which is cached by the MPC as
initial position.
m. Optionally, the MPC may use the MSs current position to request a routing translation for
an emergency services zone from the CRDB with a POSROUTREQ.
n. The CRDB returns the digits representing an emergency services zone (ESZ) to the MPC
with a posroutreq.

35
36
37
38
39
40
41

o. The MPC selects a PSAP based on the emergency services zone from the CRDB or from
the latitude and longitude of the mobile based on local procedures. The MPC then assigns
and returns a unique routable call identifier (ESRK) for the particular PSAP selected in the
orreq. See Chapter 8 and normative Annex D for the population of signaling parameters.
p. The MSC routes the Emergency Services Call toward the PSAP selected by the ESRK. See
normative Annex D for call setup signaling formats.

42
43
44
45
46

q. Some time later


r. The ESME requests the initial position.
s. The MPC returns the cached position.

47
48
49
50
51
52
53
54
55
56
57
58
59
60

4-12

1.3.2 Inter-MSC Routing Based on Position

ANSI/J-STD-036-B

1.3.3

Routing Based on Cell/Sector

This scenario shows call routing based on cell/sector information, with acquisition of more accurate
location information occurring after call routing.

4
5
6
7
8
9

MS

CRDB

MSC

PDE

MPC

ESME

10

ESNE

11
12
13

ESC Invocation
a

14
15

ORREQ [MSCID, SCELLID, MOBINFO, MPCAP]


b

POSROUTREQ [Position]
posroutreq [Digits]

PRRT

17
18

ORT

16

POST

19
20

21
22

orreq [Digits(Dialed)(ESRK or ESRD)]

23

24
25

Call Setup [ESRK or (Callback # + ESRD)]


f

26
27

GPOSREQ [MOBINFO, POSREQTYPE(initial), MPCAP]

28

gposreq [PosInfo, POSRSULT(updated)] GPRT

29
30

31
32
33

ESPOSREQ [ESRK or (Callback# + ESRD), POSREQTYPE(initial)]

34
35

36
37

esposreq [POSINFO] ESPRT


k

38
39
40
41

Figure 4-9:

42

Routing Based on Cell/Sector

43
44
45

a. The MS invokes an Emergency Services Call.


b. The MSC analyzes the digits dialed by the MS and sends an ORREQ to the MPC. The
identification of the serving MSC and cellsite is provided.
c. The MPC determines that a routing decision can be made using the default latitude and
longitude for the cell and sector based on local procedures. Optionally, when the MPC
requires to translate the latitude-longitude of the cellsite to an emergency services zone
(ESZ), it sends a POSROUTREQ to the CRDB.
d. The CRDB returns the digits representing an ESZ to the MPC with a posroutreq.
e. The MPC includes either an ESRD or an unique routable call identifier (ESRK), determined from the latitude-longitude of the cellsite or from the ESZ returned by the CRDB, in
the orreq. See Chapter 8, OriginationRequest RETURN RESULT, and normative Annex D
for additional information.

46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

1.3.3 Routing Based on Cell/Sector

4-13

ANSI/J-STD-036-B

1
2

f. The MSC routes the Emergency Services Call toward the PSAP selected by the ESRK or
ESRD. See normative Annex D for call setup signaling formats.

3
4
5
6
7
8
9
10
11
12

g. Since the MPC has mobile information, it can query the proper PDE directly with a
GPOSREQ.
Optionally, a handset-based solution may have PDE to MS communication. See Section 2
PDE to MS Scenarios for Handset-Based PDE on page 4-28.
h. In this case, the PDE has not previously acquired the initial position of the MS. The PDE
determines the current position of the MS and returns the position information in a gposreq
with the PositionResult parameter set to Updated Position Returned where it is cached as
initial position by the MPC.

13
14
15

i. ...some time later...


j. The ESME requests initial position.

16
17

k. The MPC returns the cached initial position.

18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

4-14

1.3.3 Routing Based on Cell/Sector

ANSI/J-STD-036-B

1.4

Position Update Using NCAS Pull

1
2
3

1.4.1

ESME Request for Position Update

4
5

This scenario shows an ESME requesting updated position for an Emergency Services Call.

6
7
8
9
10
11

MSC

PDE

MPC

ESME

12
13
14
15
16

ESPOSREQ [ESRK or (Callback# + ESRD), POSREQTYPE(updated)]

17

18
19

ISPOSREQ [POSREQTYPE (updated), MDN (Callback#)]

20

IPRT

ESPRT

isposreq [POSRSULT, MOBINFO, SCELLID, MPCAP]

21
22

23
24

GPOSREQ [MOBINFO,POSREQTYPE(updated), MPCAP]


d

gposreq [POSINFO]

GPRT

25
26
27

28
29

esposreq [POSINFO]

30
31
32

Figure 4-10:

ESME Request for Position Update

33
34

This scenario begins after the successful establishment of an Emergency Services Call:

35
36
37

a. The ESME requests updated position from the MPC with an ESPOSREQ.
b. The MPC queries the MSC for updated position with an ISPOSREQ.

38
39
40

c. The MSC, determining that the MS is not handed off, returns the mobile information with
an isposreq.
d. The MPC queries the proper PDE for the updated MS position with a GPOSREQ.
Optionally, a handset-based solution may have PDE to MS communication. See Section 2
PDE to MS Scenarios for Handset-Based PDE on page 4-28.

41
42
43
44
45
46
47

e. The PDE returns the requested updated MS position with a gposreq.


f. The MPC returns the requested information to the ESME with an esposreq.

48
49
50
51
52
53
54
55
56
57
58
59
60

1.4 Position Update Using NCAS Pull

4-15

ANSI/J-STD-036-B

1
2

1.4.2

Inter-MSC Request for Updated Position


This scenario shows an NCAS pull of position after a handoff has occurred.

3
4
5

Serving

Anchor

7
8
9

PDE

MPC

MSC

MSC

MPC

ESME

10
11
12

ESPOSREQ [ESRK or (Callback# + ESRD), POSREQTYPE(updated)]

13
14

ISPOSREQ [POSREQTYPE(updated), MDN (Callback#), ESRD]

15

16
17

ISPOSREQFWD [POSREQTYPE(updated), MPCAP]

18

19

ISPOSREQ [POSREQTYPE(updated), MOBINFO, MPCAP]

20

21
22
23
24
25

GPOSREQ [MOBINFO, POSREQTYPE(updated), MPCAP]


GPRT
gposreq [POSINFO]

IPRT

IPFT

IPRT

ESPRT
f

26

isposreq [POSINFO]

27

28
29

isposreqfwd [POSINFO]

30

31

isposreq [POSINFO]

32

33
34

esposreq [POSINFO]
j

35
36
37

Figure 4-11:

Inter-MSC Request for Updated Position

38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

a. The ESME, using the ESPOSREQ, requests the updated position of the MS, using either
the ESRK or the callback number. The ESME may use the incoming trunk group, ESRD,
ESRK or other means to determine the appropriate MPC.
b. The MPC, not knowing the location of the MS, requests position from the MSC with an
ISPOSREQ.
c. The Anchor MSC, determining that the MS has handed off, forwards the request in an
ISPOSREQFWD.
d. The Serving MSC, determining that a position has been requested, requests the position
with an ISPOSREQ including the mobile information.
e. The Serving MPC forwards the request to the appropriate PDE with a GPOSREQ.
Optionally, a handset-based solution may have PDE to MSC communication. See Section
2 PDE to MS Scenarios for Handset-Based PDE on page 4-28.

54
55
56
57
58

f. The Serving PDE returns the position in the gposreq.


g. The Serving MPC returns the position for the MS with an isposreq.
h. The Serving MSC returns the position with an isposreqfwd.

59
60

4-16

1.4.2 Inter-MSC Request for Updated Position

ANSI/J-STD-036-B

i. The Anchor MSC returns the position with an isposreq.

1
2

j. The Anchor MPC returns the position with an esposreq.

3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

1.4.2 Inter-MSC Request for Updated Position

4-17

ANSI/J-STD-036-B

1
2

1.4.3

Failed Position Update Due to Unavailable MS


This scenario depicts a failed fetching of updated position information using an NCAS pull after the
call is delivered to the ESNE.

3
4
5
6
7
8

MS

MSC

PDE

MPC

ESME

ESNE

9
10
11

ESPOSREQ [ESRK or (Callback# + ESRD), POSREQTYPE(updated)]

12

13

ESPRT
ISPOSREQ [POSREQTYPE (updated), MDN (Callback#)]

14
15
16

isposreq [POSRSULT]

17

IPRT
c

18

esposreq [POSRSULT]

19
20

21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

Figure 4-12:

Failed Position Update Due to Unavailable MS


This scenario begins after the successful establishment of an Emergency Services Call.
a. The ESME requests the updated position for an MS identified by its ESRK or callback
number in an ESPOSREQ toward the MPC determined from the incoming trunk group, the
known ESRD, or other means.
b. The MPC, not knowing the location of the MS, requests updated position from the MSC
with an ISPOSREQ.
c. The MSC, determining that that it cannot honor the request (e.g., the MS has handed off to
a system that does not support positioning), returns a failure indication with an isposreq.
d. The MPC returns the position failure indication with an esposreq.

36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

4-18

1.4.3 Failed Position Update Due to Unavailable


MS

ANSI/J-STD-036-B

1.5

Failure Cases

1
2
3

1.5.1

MPC Failure on Call Origination

4
5

This scenario shows a failed query to an MPC.

6
7
8
9
10
11

MS

MSC

MPC

ESNE

12
13
14

ESC Invocation

15

16
17

ORREQ [MPCAP, MOBINFO]


b

18
19
20

ORT

Failure

21
22

Timer Expiry

24

Call Setup [ESRD, Callback#]

Figure 4-13:

23

25

26
27

MPC Failure on Call Origination

28
29

a. The MS invokes an Emergency Services Call.

30

b. The MSC analyzes the digits dialed by the MS and sends an ORREQ to the MPC.

31

c. An error occurs in the communication with the MPC or in the MPC processing.

33

32

34

d. The ORT timer expires.

35

e. The MSC routes the Emergency Services Call toward the PSAP selected by the ESRD. See
normative Annex D for call setup signaling formats.

36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

1.5 Failure Cases

4-19

ANSI/J-STD-036-B

1
2

1.6

Call Termination

3
4

1.6.1

Call Termination Reporting

When an Emergency Services Call (ESC) is released, the call termination event is reported by the
anchor MSC to the MPC. Regardless of the reason for the call release, the event is reported.

6
7
8
9
10
11
12

MSC

13

PDE

MPC

ESNE

14
15

Call Release

16

17
18

CALLTERMREP [MSID, BillingID]

19
20

CTRT

21

calltermrep [ ]

22
23

CALLTERMREP [MSID]

24

25

calltermrep [ ]

26

CTRT
e

27
28
29

Figure 4-14:

Call Termination Reporting

30
31
32
33
34
35
36
37
38
39

a. An Emergency Services Call is released.


b. The MSC notifies the MPC that resources assigned to the call (such as an ESRK) can be
released, by sending a CALLTERMREP.
c. The MPC acknowledges by sending a calltermrep.
d. Optionally, the MPC may notifiy the PDE, by sending a CALLTERMREP, that resources
assigned to the call can be released.
e. The PDE acknowledges by sending a calltermrep.

40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

4-20

1.6 Call Termination

ANSI/J-STD-036-B

1.6.2

Call Disconnect During Positioning

This scenario shows a call being disconnected while a PDE is in the process of obtaining position
information.

4
5
6
7

MS

MSC

PDE

MPC

ESNE

9
10
11

ESC Invocation
a

12
13

ORREQ [MDN, BillingID, MPCAP, MOBINFO]

ORT

14

GPOSREQ [MOBINFO, POSREQTYPE(initial), MPCAP]


GPRT

Call Release

15
16

17
18

POST

19

20
21

CALLTERMREP [MSID, BillingID]

22
23

CTRT

calltermrep [ ]
CALLTERMREP [MSID]
CTRT
calltermrep [ ]

24

25
26

27
28

gposreq [POSINFO]

29
30
31

32
33

orreq [GEOPOS]

34
35
36

Figure 4-15:

Call Disconnect During Positioning

37
38

a. The MS invokes an Emergency Services Call.


b. The MSC analyzes the digits dialed by the MS and sends an ORREQ to the MPC. MDN is
provided to include a callback number. The BillingID is provided to uniquely identify the
call.
c. Since the MPC has mobile information, it can query the proper PDE directly with a
GPOSREQ.
Optionally, a handset-based solution may have PDE to MS communication. See Section 2
PDE to MS Scenarios for Handset-Based PDE on page 4-28.
d. The call is released while positioning is still underway.
e. The MSC notifies the MPC that resources assigned to the call (such as an ESRK) can be
released, by sending a CALLTERMREP.
f. The MPC acknowledges by sending a calltermrep.
g. Optionally, the MPC may notify the PDE, by sending a CALLTERMREP, that resources
assigned to the call can be released.
h. The PDE acknowledges by sending a calltermrep.

39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

1.6 Call Termination

4-21

ANSI/J-STD-036-B

1
2
3

i. The PDE returns any position information that it might currently have in a gposreq. Alternatively, it might return a PositionResult indicating that position information was not
available.

4
5
6

j. The MPC responds back to the MSC with an orreq containing any position information that
is available.

7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

4-22

1.6 Call Termination

ANSI/J-STD-036-B

1.7

PDE Use of Network Data

1
2
3

1.7.1

PDE Request for CDMA Pilot Strength Measurements

4
5

The PDE receives a position request (GPOSREQ) from the MPC and determines additional network
data must be obtained from the MSC. The PDE initiates a request towards the MSC requesting
CDMA Pilot Strength Measurement Message (PSMM) data. The PDE uses the newly received
information to determine the position of the MS and returns the response to the MPC (gposreq).
Alternatively, any PDE to MSC communications could be via the MPC (i.e., E3/E5 interfaces).

6
7
8
9
10
11
12
13
14

MS

MSC

PDE

15

MPC

16
17

GPOSREQ [MOBINFO, MPCAP]


a

ISPOSREQ [POSREQTYPE, CPSMC]

18
19
20

21
22

PSMM_Request
c

PSMM_Response

IPRT

GPRT

23
24
25

26
27

isposreq[POSRSULT,MOBINFO,SCELLID]

28
29

gposreq[POSINFO]

30

31
32

Figure 4-16:

PDE Request for CDMA Pilot Strength Measurements

33
34

a. The PDE receives a position request (GPOSREQ) from the MPC. Either the request did not
include the mobile position capabilities (MPCAP) or the mobile position capabilities
indicated the mobile did not have any position capabilities, therefore the PDE will need the
MSC to collect additional mobile data.
b. The PDE sends the ISPOSREQ to the MSC with the count of PSMMs to collect.
c. The MSC sends a CDMA Pilot Strength Measurement Message (PSMM) request to the
MS.
d. The MS returns the PSMM response to the MSC.
Note: Steps c and d may be repeated over the air interface up to CDMAPSMMcount times.

35
36
37
38
39
40
41
42
43
44
45
46

e. The MSC sends the newly collected Pilot Strength Measurement results in the
CDMAPSMMList of MOBINFO.

47
48

Note: Steps b-e may be repeated if the PDE needs to request additional information.

49

f. The PDE uses the received information, along with the initial MOBINFO from step a, to
determine the position of the MS and sends the response to the MPC (gposreq).

51

50

52
53
54
55
56
57
58
59
60

1.7 PDE Use of Network Data

4-23

ANSI/J-STD-036-B

1
2
3

1.7.2

TDMA MAHO Obtained After Call Setup


This scenario shows an emergency call setup with MAHO information obtained after initial call setup.

4
5
6
7
8
9

MS

MSC

PDE

MPC

ESME

ESNE

10
11
12

ESC Invocation

13
14

ORREQ [TRANSCAP[MAHO]]

15

16

ORT

17

orreq

POST
c

18
19

Call Setup [(Callback#, ESRD) or ESRK]

20

21
22

ISPOSREQ [MAHOREQ]

23
24
25

MAHO Request

IPRT

26

isposreq [MOBINFO(MAHO), POSRSULT(MAHO),ServingCellID]]

27

28
29

GPOSREQ [MOBINFO(MAHO), POSREQTYPE(initial)]

30

GPRT
gposreq [POSINFO,POSRSULT(updated)]

31
32
33

ESPOSREQ [Callback#, ESRD, POSREQTYPE(initial)]

34

35
36

ESPRT
esposreq

37
38

39
40

Figure 4-17:

TDMA MAHO Obtained After Call Setup

41
42
43
44
45
46
47

a. The MS invokes an Emergency Services Call.


b. The MSC requests the position of the MS with an ORREQ, indicating that MAHO information is available upon request (in the TRANSCAP parameter). The MPC starts the POST
timer.
c. The MPC cancels the POST timer and acknowledges the request in an orreq.

48
49
50

d. The MSC sets the call up toward the ESNE.


e. The MPC requests MAHO information from the MSC.

51
52
53
54
55
56

f. The MSC, recognizing that it is the Serving MSC, requests MAHO information from the
MS.
g. The MSC replies to the MPC with isposreq containing MOBINFO, including the
MAHO information and the ServingCellID (in case an intra-MSC handoff has occurred
since the initation of the call).

57
58
59

h. The MPC relays the position request to the appropriate PDE with a GPOSREQ, including
the MAHO information.

60

4-24

1.7.2 TDMA MAHO Obtained After Call Setup

ANSI/J-STD-036-B

Optionally, a handset-based solution may have PDE to MS communication. See Section 2


PDE to MS Scenarios for Handset-Based PDE on page 4-28.

1
2
3

i. In this case, the PDE has not previously acquired the initial position of the MS. The PDE
determines the current position of the MS and returns the position information in a gposreq
with the PositionResult parameter set to Updated Position Returned.

4
5
6
7

j. The ESME autonomously requests the position of an MS with an ESPOSREQ toward the
MPC determined from the incoming trunk group, the known ESRD, or other means. This
request is asynchronous and is due to the arrival of the Emergency Services Call at the
ESNE.
k. The MPC returns the cached position in an esposreq to the ESME.

8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

1.7.2 TDMA MAHO Obtained After Call Setup

4-25

ANSI/J-STD-036-B

1
2

1.7.3

TDMA MAHO obtained after Inter-System Handoff


This scenario shows an emergency call with MAHO information obtained after an intersystem
handoff has occurred.

3
4
5
6

Anchor

Serving

8
9

MS

MSC

MPC

MSC

MPC

PDE

ESME

10
11
12

Emergency Call in progress, Handoff has occurred

13

14

ESPOSREQ[(Callback#,ESRD) or ESRK,PosReqType(Initial)]

15

16

ISPOSREQ[MAHOREQ,MDN]

17
18

19

ISPOSREQFWD[MAHOREQ,MPCAP]

20

21

ESPRT

MAHO request

22
23

24

ISPOSREQ[PosReqType,MobInfo(MAHO),MPCAP]

25

26
27

GPOSREQ[MobInfo(MAHO),PosReqType]

IPRT IPFT

28
29

IPRT

30

GPRT
gposreq[PosInfo,PosResult(Updated)]

g
h

31

isposreq[PosInfo]

32

33
34

isposreqfwd[PosInfo]

35

36

isposreq[PosInfo]

37

38
39

esposreq[PosInfo]

40

41
42
43
44
45
46
47
48

Figure 4-18:

TDMA MAHO obtained after Inter-System Handoff


a. An MS has been handed off while engaged in an emergency call.
b. The ESME autonomously requests the anchor MPC for the position of an MS with a
ESPOSREQ. This request is triggered in the arrival of the emergency service call at the
ESNE.

49
50
51
52

c. The Anchor MPC requests MAHO information from the Anchor MSC using ISPOSREQ.
d. The Anchor MSC,determining that the MS has been handed off, forwards the request to the
Serving MSC using an ISPOSREQFWD.

53
54
55
56
57
58

e. Optionally, the MSC, recognizing that it is the Serving MSC, may elect, based on internal
algorithms, to request MAHO information from the MS.
The MSC may also elect not to collect MAHO information at this point, and wait until a
specific indication is received from its associated MPC (i.e., Serving MPC) to do so.

59
60

4-26

1.7.3 TDMA MAHO obtained after Inter-System


Handoff

ANSI/J-STD-036-B

f. If the Serving MSC was able to collect MAHO information (i.e., it is MAHO-Capable), it
relays the MAHO information to the Serving MPC, including it in MOBINFO, and sending
an ISPOSREQ. Otherwise, the Serving MSC will send the ISPOSREQ with the received
PositionRequestType parameter.

1
2
3
4
5

g. The Serving MPC relays the request to the appropriate PDE with a GPOSREQ, including
the MAHO information, if it is received in the ISPOSREQ from the Serving MSC.
Optionally, a handset-based solution may have PDE to MS communication. See See
Section 2 PDE to MS Scenarios for Handset-Based PDE on page 4-28.
h. In this case, the PDE has not previously acquired the initial position of the MS. The PDE
determines the current position of the MS and returns the position information in the
gposreq with the PositionResult parameter set to UpdatedPositionReturned.

6
7
8
9
10
11
12
13
14

i. The Serving MPC relays the position information to the Serving MSC with an isposreq.
j. The Serving MSC relays the position information to the Anchor MSC with an isposreqfwd.

15
16
17

k. The Anchor MSC relays the position information to the Anchor MPC with an isposreq.
l. The MPC returns the cached position information to the ESME in an esposreq.

18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

1.7.3 TDMA MAHO obtained after Inter-System


Handoff

4-27

ANSI/J-STD-036-B

1
2

PDE to MS Scenarios for Handset-Based PDE


Scenarios highlighting the PDE to MS communication for PDEs supporting handset based position assistance
are within this section. One of these scenarios applies to each ELID scenario in Emergency Location Information Delivery (ELID) Scenarios where a GPOSREQ is sent from the MPC to the PDE. Databursts (i.e.,
SMDPP) that are sent directly PDE MSC are over the E12 interface. Bearer data sent via PDE MPC
MSC uses the E5 and E3 interfaces.

4
5
6
7
8
9
10
11
12

2.1

CDMA

13
14

2.1.1

15

PDE to MS Communication via E12 Interface


This scenario shows a request for position information from the MPC to the PDE followed by the
SMDPP and Databurst message exchanges. The PDE initiates an SMDPP to the MSC based on the
parameters contained in the GPOSREQ (i.e., MPCAP) and the procedures defined in IS-801.

16
17
18
19
20
21
22

MS

23

MSC

PDE

MPC

24
25

GPOSREQ [MOBINFO, POSREQTYPE, MPCAP]

26

27

SMDPP [ServiceIndicator, ACTCODE, SMS_BearerData]

28

29
30

DATABURST [Bearer]

31

32
33

DATABURST [Bearer]

SMT

34
35

smdpp [SMS_BearerData]

36

GPRT

37
38

DATABURST [Bearer]

39
40

SMDPP [ServiceIndicator, SMS_BearerData]

41
42

SMT

43

smdpp[ ]

44
45

gposreq [POSINFO]

46

47
48
49
50
51
52
53
54
55
56
57

Figure 4-19:

PDE to MS Communication via E12 Interface


a. The PDE receives a position request (GPOSREQ) from the MPC indicating the MS's
position capabilities. (Shown only for clarity.)
b. The PDE must obtain/provide positioning information and initiates an SMDPP, encapsulating in the SMS_BearerData parameter an action according to the value of the MPCAP
parameter and the procedures defined in IS-801. The ServiceIndicator parameter identifies
this as handset assisted position information. The length of the TeleserviceId parameter is
set to 0.

58
59
60

4-28

2 PDE to MS Scenarios for Handset-Based PDE

ANSI/J-STD-036-B

Note: If the ACTCODE is set to Do Not Wait for MS User Level Response, the MSC should
return an smdpp immediately.

1
2
3

c. The MSC sends a databurst message to the MS containing the bearer data from the SMDPP
containing the positioning related information.
d. The MS returns a response containing the positioning related information (e.g., IS-801) in
a databurst message to the MSC.
e. The MSC sends the MS-provided positioning related information in an smdpp to the PDE.
Note: Steps b - e may be repeated if the PDE must obtain or provide additional positioning
related information.
f. In this case, the MS initiates the exchange of positioning related information. A databurst
message is sent to the MSC containing this information.

4
5
6
7
8
9
10
11
12
13
14
15

g. The MSC forwards the information to the PDE in an SMDPP.


h. The PDE acknowledges the received information in an smdpp.
Note: Steps f - h may be repeated if the MS needs to obtain or provide additional
positioning related information.
i. The PDE uses the received information to determine the MS's position and sends the
response to the MPC (gposreq). In the case where the MS computes its position the PDE
relays the position to the MPC. (Shown only for clarity.)

16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2 PDE to MS Scenarios for Handset-Based PDE

4-29

ANSI/J-STD-036-B

1
2

2.1.2

Communication via E5 and E3 Interfaces

This scenario shows a request for position information from the MPC to the PDE followed by the
SMDPP and Databurst message exchanges. The PDE initiates an SMDPP to the MPC/MSC based
on the parameters contained in the GPOSREQ (i.e., MPCAP) and the procedures defined in IS-801.

4
5
6
7
8
9

MS

10

MSC

PDE

MPC

11
12

GPOSREQ [MOBINFO, POSREQTYPE, MPCAP]

13
14
15

SMDPP [ServiceIndicator, ACTCODE, SMS_BearerData]

16

SMT

17

SMDPP [ServiceIndicator, ACTCODE, SMS_BearerData]

18
19

21

23

Databurst [Bearer]

20

22

GPRT
Databurst [Bearer]
e

24
25

smdpp [SMS_BearerData]

26
27

smdpp [SMS_BearerData]

28

29

Databurst [Bearer]

30

31
32

SMDPP [ServiceIndicator, SMS_BearerData]

33

34

SMDPP [ServiceIndicator, SMS_BearerData]

35

SMT

36
37

smdpp [ ]

38

39

smdpp [ ]

40

41
42

gposreq[POSINFO]

43
44
45

Figure 4-20:

Communication via E5 and E3 Interfaces

46
47
48
49
50
51
52
53
54
55
56
57
58

a. The PDE receives a position request (GPOSREQ) from the MPC indicating the MSs
position capabilities. (Shown only for clarity.)
b. The PDE must obtain or provide positioning related information and initiates an SMDPP
via the MPC, encapsulating in the SMS_BearerData parameter an action according to the
value of the MPCAP parameter and the procedures defined in IS-801. The ServiceIndicator
parameter identifies this as handset assisted position information. The length of the TeleserviceId parameter is set to 0.
c. The MPC forwards the SMDPP to the MSC.
d. The MSC sends a databurst message to the MS containing the bearer data from the SMDPP
containing the positioning related information.

59
60

4-30

2.1.2 Communication via E5 and E3 Interfaces

ANSI/J-STD-036-B

Note: If the ACTCODE is set to Do Not Wait for MS User Level Response, the MSC should
return an smdpp immediately.

1
2
3

e. The MS returns a response containing the positioning related information (e.g., IS-801) in
a databurst message to the MSC.
f. The MSC sends the MS-provided positioning related information in an smdpp to the PDE
via the MPC.
g. The MPC forwards the smdpp containing the positioning related information to the PDE.
Note: Steps b - g may be repeated if the PDE must obtain or provide additional positioning
related information.
h. Optionally, the MS may require additional exchanges of positioning information with the
PDE. In this case the MS initiates the exchange of positioning related information in a
databurst message sent to the MSC.

4
5
6
7
8
9
10
11
12
13
14
15
16

i. The MSC sends the information to the MPC with an SMDPP.


j. The MPC forwards the SMDPP to the PDE.
k. The PDE provides an smdpp to the MSC via the MPC.
l. The MPC forwards the smdpp to the MSC.
Note: Steps h - l may be repeated if the MS needs to obtain or provide additional positioning
related information.

17
18
19
20
21
22
23
24
25

m. The PDE uses the received information to determine the MSs position and sends the
response to the MPC (gposreq). In the case where the MS computes its position the PDE
relays the position to the MPC. (Shown only for clarity.)

26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.1.2 Communication via E5 and E3 Interfaces

4-31

ANSI/J-STD-036-B

1
2

2.1.3

Position Determination after Handoff


This scenario describes position determination of an Emergency Services call that has been handed
off to another system using handset based PDE. Alternatively, any PDE to MSC communications
could be direct using the E12 interface.

3
4
5
6
7
8
9

Serving

Anchor

MSC

MSC

10
11

MS

PDE

MPC

12
13
14

GPOSREQ [MOBINFO, POSREQTYPE, MPCAP]

15

16

SMDPP [ServiceIndicator, ACTCODE, SMS_BearerData]

17

18
19

SMDPP [ServiceIndicator, ACTCODE, SMS_BearerData]

20

21

SMDFWD [ServiceIndicator, ACTCODE, SMS_BearerData]

22

23
24

Databurst [Bearer]

GPRT

25
26
27

SFT

Databurst [Bearer]

SMT
f

28
29

smdfwd [SMS_BearerData]

30
31

smdpp [SMS_BearerData]

32
33
34

smdpp [SMS_BearerData]

35

h
i

36
37

Databurst [Bearer]

38
39

SMDBACK [ServiceIndicator, SMS_BearerData]


k

40
41

SMDPP [ServiceIndicator, SMS_BearerData]

42
43

SBT

44

SMT

SMDPP [ServiceIndicator, SMS_BearerData]


m

45
46

smdpp [ ]

47

48

smdpp [ ]

49

50
51

smdback [ ]

52

53

gposreq [POSINFO]

54

55
56
57

Figure 4-21:

Position Determination after Handoff

58
59

a. The PDE receives a position request (GPOSREQ) from the MPC indicating the MSs

60

4-32

2.1.3 Position Determination after Handoff

ANSI/J-STD-036-B

position capabilities.

b. The PDE must obtain or provide positioning related information and initiates an SMDPP
via the MPC, encapsulating in the SMS_BearerData parameter an action according to the
value of the MPCAP parameter and the procedures defined in IS-801. The ServiceIndicator
parameter identifies this as handset assisted position information. The length of the TeleserviceId parameter is set to 0.
c. The MPC forwards the SMDPP to the Anchor MSC.

3
4
5
6
7
8
9

d. Since the MS has been handed off the Anchor MSC sends an SMDFWD to the Serving
MSC.
e. The Serving MSC sends a databurst message to the MS containing the bearer data from the
SMDPP containing the positioning related information.
Note: If the ACTCODE is set to Do Not Wait for MS User Level Response, the Serving
MSC should return an smdpp immediately.
f. The MS returns a response containing the positioning related information (e.g., IS-801) in
a databurst message to the Serving MSC.
g. The Serving MSC sends the smdfwd containing the positioning related information to the
Anchor MSC.

10
11
12
13
14
15
16
17
18
19
20
21
22

h. The Anchor MSC sends the MS-provided positioning related information in an smdpp to
the PDE via the MPC.

23

i. The MPC forwards the smdpp containing the positioning related information to the PDE.

25

24

26

Note: Steps b - i may be repeated if the PDE must obtain or provide additional positioning
related information.
j. Optionally, the MS may require additional exchanges of positioning information with the
PDE. In this case the MS initiates the exchange of positioning related information in a
databurst message sent to the Serving MSC.
k. The Serving MSC sends the SMDBACK containing the positioning related information to
the Anchor MSC.
l. The Anchor MSC sends the information to the MPC with an SMDPP.
m. The MPC forwards the SMDPP to the PDE.

27
28
29
30
31
32
33
34
35
36
37
38

n. The PDE provides an smdpp to the Anchor MSC via the MPC.
o. The MPC forwards the smdpp to the Anchor MSC.

39
40
41

p. The Anchor MSC sends an smdback to the Serving MSC.


Note: Steps j - p may be repeated if the MS needs to obtain or provide additional positioning
related information.
q. The PDE uses the received information to determine the MSs position and sends the
response to the MPC (gposreq). In the case where the MS computes its position the PDE
relays the position to the MPC.

42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.1.3 Position Determination after Handoff

4-33

ANSI/J-STD-036-B

1
2

2.2

TDMA SAMPS

3
4

2.2.1

PDE to MS Communication via E12 Interface

This scenario shows the call ows associated with the E12 interface. The scenario shows a request
for position information from the MPC to the PDE followed by the SMDPP/R-DATA message
exchanges. The PDE initiates an SMDPP to the MSC based on the parameters contained in the
GPOSREQ (i.e., MPCAP) and the procedures as dened in SAMPS.

6
7
8
9
10
11
12
13
14

MS

MSC

PDE

MPC

15
16

GPOSREQ [MobInfo, POSREQTYPE, MPCAP, LCSCID]

17

18

SMDPP [SMS_TeleserviceID, SMS_BearerData,TPRIO]

19

20
21
22

R-DATA [ R-Data Unit]

PRT

23
24

SMT
R-DATA ACCEPT [ ]

25
26

smdpp [ ]

27

28
29

R-DATA[R-DATA Unit]
f

30
31

SMDPP [SMS_TeleserviceID, SMS_BearerData ]

32

33

SMT

34

smdpp [ ]

35
36

R-DATA ACCEPT [ ]

37

38

gposreq [GEOPOS]

39

40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

Figure 4-22:

PDE to MS Communication via E12 Interface


a. The PDE receives a position request (GPOSREQ) from the MPC indicating the MSs
capabilities. The MPC, based on the fact that it received an ORREQ indicating an
Emergency Call, includes the LCS Client ID (This step is shown only for clarity).
b. The PDE must obtain or provide positioning related information and initiates an SMDPP,
encapsulating in the SMS_BearerData parameter the LCS Client ID information, and an
action according to the value of the MPCAP parameter and the procedures defined in
SAMPS. The TeleserviceID is set to SAMPS to indicate this is an Emergency Services Call
utilizing System Assisted Mobile Positioning (SAMPS) through Satellite. The
Teleservice_Priority parameter is set to Emergency.
c. The MSC sends an R-DATA message to the MS containing the bearer data from the
SMDPP.
d. The MS returns an R-DATA ACCEPT to the MSC indicating the MS has accepted the
request.

60

4-34

2.2 TDMA SAMPS

ANSI/J-STD-036-B

e. The MSC returns an smdpp to the PDE.

1
2

Note: Sequence in steps b through e can be repeated several times.


f. The MS initiates an R-DATA to the MSC. This message is used to provide or obtain
positioning related information.
g. The MSC forwards the information received from the MS in an SMDPP to the PDE.
h. The PDE acknowledges with an smdpp to the MSC.
i. The MSC responds with an R-DATA ACCEPT to the MS.
Note: If the R-DATA in step f was a request to obtain or provide positioning related data,
steps f through i are repeated.
j. The PDE sends the position information to the MPC in gposreq.

3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.2 TDMA SAMPS

4-35

ANSI/J-STD-036-B

1
2

2.2.2

Communication via E5 and E3 Interfaces

This scenario shows the call flows associated with the E5/E3 interface. The scenario shows a request
for position information from the MPC to the PDE followed by the SMDPP/R-DATA UNIT
message exchanges. The PDE initiates an SMDPP to the MSC through the MPC based on the
parameters contained in the GPOSREQ (i.e., MPCAP) and the procedures defined in SAMPS.

4
5
6
7
8
9
10
11

MS

MSC

PDE

MPC

12
13

GPOSREQ [MobInfo, POSREQTYPE, MPCAP, LCSCID]

14

15
16

SMDPP [SMS_TeleserviceID, SMS_BearerData, TPRIO]

17

18

SMDPP [SMS_TeleserviceID, SMS_BearerData, TPRIO]

19

20
21

R-DATA[ R-Data Unit]

PRT

22
23
24

SMT

SMT

R-DATA ACCEPT[ ]

25
26

smdpp [ ]

27

28

smdpp [ ]

29

30

R-DATA [R-DATA Unit]

31

32
33

SMDPP [SMS_TeleserviceID, SMS_BearerData]

34

35

SMDPP [SMS_TeleserviceID, SMS_BearerData]

36
37

SMT

38

smdpp [ ]

39

SMT
k

40

smdpp [ ]

41

42
43

R-DATA ACCEPT[ ]

44

45

gposreq [GEOPOS]

46

47
48
49

Figure 4-23:

Communication via E5 and E3 Interfaces

50
51
52
53
54
55
56
57

a. The PDE receives a position request (GPOSREQ) from the MPC indicating the MSs
capabilities. The MPC, based on the fact that it received an ORREQ indicating an
Emergency Call, includes the LCS Client ID. (Shown only for clarity).
b. The PDE must obtain or provide positioning related information and initiates an SMDPP
to the MSC through the MPC, encapsulating in the SMS_BearerData parameter the LCS
Client ID information, and an action according to the value of the MPCAP parameter and

58
59
60

4-36

2.2.2 Communication via E5 and E3 Interfaces

ANSI/J-STD-036-B

the procedures dened in SAMPS. The TeleserviceID is set to SAMPS to indicate this is an
Emergency Services Call utilizing System Assisted Mobile Positioning (SAMPS) through
Satellite. The Teleservice_Priority parameter is set to Emergency.

1
2
3
4

c. The MPC forwards the received information to the MSC in an SMDPP.


d. The MSC sends an R-DATA message to the MS containing the bearer data from the
SMDPP.

5
6
7
8

e. The MS returns an R-DATA ACCEPT to the MSC indicating the MS has accepted the
request.

9
10

f. The MSC returns an smdpp to the PDE.

11

g. The MPC forwards the smdpp to the PDE.

13

Note: Sequence from step b to g can be repeated several times.


h. The MS initiates an R-DATA to the MSC. This message is used to request or to provide
positioning related information.

12

14
15
16
17
18

i. The MSC initiates an SMDPP to the MPC including the Bearer Data received from the MS.
j. The MPC forwards the information received to the PDE in an SMDPP.

19
20
21

k. The PDE returns an smdpp to the MPC.


l. The MPC sends an smdpp to the MSC.
m. The MSC sends an R-DATA ACCEPT to the MS.
Note: Sequence from step h to step m can be repeated several times.
n. The PDE sends the position information to the MPC in gposreq.

22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.2.2 Communication via E5 and E3 Interfaces

4-37

ANSI/J-STD-036-B

1
2

2.2.3

Position Update after Handoff


This scenario describes an Emergency Services call that has been handed off to another system and
the call taker has sent a position update request.

3
4
5
6
7

Serving

Anchor

MSC

MSC

8
9
10

MS

PDE

MPC

ESME

11
12

ESPOSREQ [ESRK or (Callback Number+ESRD), POSREQTYPE(update)]

13

14
15

GPOSREQ [MOBINFO, POSREQTYPE(initial), MPCAP]

16

17
18

SMDPP[SMS_TeleserviceID, SMS_BearerData(request for position)]

19
20
21

SMDFWD[SMS_TeleserviceID, SMS_BearerData(request for position)]


d

22
23

R-DATA [SAMPS Measure Position Request]


e

24
25
26

SFT

R-DATA ACCEPT[ ]

ESPRT

SMT
GPRT

27

smdfwd[ ]

28

29
30

smdpp[ ]

31

32
33

R-DATA[SAMPS Measure Position Response]

34
35

SMDBACK[SMS_TeleserviceID, SMS_BearerData(position information)]

36

37

SMDPP[SMS_TeleserviceID, SMS_BearerData(position information)]

38

39

SBT

40

SMT

41

smdpp[ ]

42

smdback[ ]

43

44
45

R-DATA ACCEPT[ ]
n

46
47

gposreq [POSINFO]

48

49

esposreq [POSINFO]

50

p
q

51
52

Figure 4-24:

Position Update after Handoff

53
54
55
56
57
58

a. The Emergency Services Call Taker requests a position update. The ESME sends an
ESPOSREQ to the MPC of the Anchor System.
b. Based on MPCAP indicating that the MS has GPS capability, the MPC sends the
GPOSREQ to the PDE requesting a position update.

59
60

4-38

2.2.3 Position Update after Handoff

ANSI/J-STD-036-B

c. The PDE, based on the MPCAP, sends an SMDPP to the Anchor MSC requesting a
position.

1
2
3

d. Since the MS has been handed off the Anchor MSC sends an SMDFWD to the Serving
MSC.

e. The Serving System sends an R-DATA to the MS requesting a position.

f. The MS acknowledges the request by sending an R-DATA Accept to the Serving MSC.

g. The Serving MSC sends the smdfwd to the Anchor MSC.

h. The Anchor MSC sends the smdpp to the Anchor PDE.

11

Note: Should the mobile require assistance data a SAMPS Positioning Assistance Request
message may be sent to the PDE (Designated SAMPS Teleservice Address).
i. The MS determines its position and sends an R-DATA with the position information to the
Serving MSC.

10

12
13
14
15
16
17

j. The Serving MSC sends an SMDBACK to the Anchor MSC with the information.
k. The Anchor MSC sends an SMDPP to the Anchor PDE with the position information.

18
19
20

l. The PDE sends an smdpp to the Anchor MSC.

21

m. The Anchor MSC sends an smdback to the Serving MSC.

22

n. The Serving MSC sends the R-DATA Accept to the MS.

24

o. The PDE sends a gposreq with the position information to the MPC.
p. The MPC sends the esposreq with the position information to the ESME.

23

25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.2.3 Position Update after Handoff

4-39

ANSI/J-STD-036-B

1
2

Mobile Initiated Positioning

3.1

MS Originated Position Determination for Emergency Services


Call (Successful CAS Push - E5/E3 Interfaces)

3
4
5
6
7
8
9
10
11
12
13

This scenario illustrates MS originated position determination for an emergency services call. When
the Serving System indicates that this is supported, the MS initiates an IS-801 data burst to obtain
position related information from the PDE when the MS is assigned to a traffic channel.
Communication between the Serving MSC and the MPC-selected PDE takes place over the E5/E3
interfaces.

14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

4-40

3 Mobile Initiated Positioning

ANSI/J-STD-036-B

1
2
3

Serving System

MPC

PDE

MSC

MS

6
7

MIPLSI=1

call origination (9-1-1, MIPLI=1)

data burst (IS-801)

9
10

b
ORREQ [MSCID, BILLID, DGTSDIAL, SCELLID, MOBINFO, MPCAP]

11
12
13
14

15
16

SMDPP [SRVIND, SMS_BearerData]

17
18
19

SMDPP [SRVIND, SMS_BearerData]

20
21

SMT

smdpp [SMS_BearerData]

22
23
24

smdpp [SMS_BearerData]

25
26

data burst (IS-801)


i

27
28

POST

ORT

data burst (IS-801)

SMDPP [SRVIND, SMS_BearerData]

29

30
31

32
33

SMDPP [SRVIND, SMS_BearerData]


SMT

34
35
36

smdpp [ ]

37
38

smdpp [ ]

GPOSDIR [POSINFO]

40
41

o
gposdir [ ]

39

42
43

GPDT
p

44
45
46

orreq [GEOPOS]

Call Setup IAM [CgPN (Callback#), GDP (ESRD), CGL (position)]

47
48

49
50

Figure 4-25:

MS Originated Position Determination for Emergency Services Call


(Successful CAS Push - E5/E3 Interfaces)
a. The BS indicates support of MS originated position determination.
b. The MS originates an Emergency Services call indicating it will initiate position determination (MS_INIT_POS_LOC_IND=1).

51
52
53
54
55
56
57
58
59
60

3 Mobile Initiated Positioning

4-41

ANSI/J-STD-036-B

1
2
3

c. The Serving MSC sends an ORREQ to the Serving MPC. The MOBINFO parameter
includes the MIPLI set to indicate MS originated position determination. The MPC starts
the POST timer and waits for a GPOSDIR instead of initiating a GPOSREQ.

4
5
6
7
8
9
10

d. The MS sends an IS-95 Data Burst message (Type = PLD) containing an encapsulated
IS-801 message in order to provide or obtain positioning related information from the PDE.
Note that step d. may occur as soon as the MS is placed on a traffic channel.
e. Upon receipt of the Data Burst message for MS originated position determination, the MSC
encapsulates the application layer content (IS-801) in an SMDPP and sends the SMDPP to
the Serving MPC.

11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

f. The MPC relays the received SMDPP to an appropriate PDE. Note: PDE selection by the
MPC may be determined by Session Tags contained in the SMS_BearerData. The
mechanism used by the MPC for routing SMDPP messages is beyond the scope of this
Standard.
g. The PDE examines the contents of the IS-801 message encapsulated in the SMDPP, and
encapsulates the appropriate IS-801 response to the MS in an smdpp. The PDE sends the
smdpp to the MPC; the smdpp in this scenario contains bearer data intended for transmission to the MS. This scenario shows a single variant of IS-801 message exchange. The
2-way exchange of IS-801 information between the PDE and MS may occur in various
iterations of SMS transport INVOKEs and responses.
h. The MPC relays the smdpp to the MSC.
i.-j. Same as section 3.1.1, steps c-d.
k.-n. Same as steps e-h., except that the smdpp sent by the PDE contains no bearer data. By step
n., the PDE has received adequate information to determine the MS position.

28
29
30
31
32

o. The PDE uses the received information to determine the MSs position. The PDE sends the
POSINFO to the MPC in the GPOSDIR.
p. The MPC cancels the POST timer and acknowledges receipt of the GPOSDIR with
gposdir sent to the PDE.

33
34
35
36
37

q. The MPC cancels the POST timer and sends the GEOPOS in the orreq to the MSC.
r. The MSC sets the call up toward the ESNE; the call setup signaling includes the received
geographic position.

38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

4-42

3 Mobile Initiated Positioning

ANSI/J-STD-036-B

3.2

MS Originated Position Determination for Emergency Services


Call (POST Timer Expiry)
This scenario illustrates MS originated position determination for an emergency services call. When
the Serving System indicates that this is supported, the MS initiates an IS-801 data burst to obtain
position related information from the PDE when the MS is assigned to a traffic channel. In this
scenario the MPC times out awaiting the arrival of the GPOSDIR (POST timer expiry) and sends an
orreq without the geoposition of the MS. The PDE is later able to compute the geoposition of the
MS and pushes the information to the MPC to be later retrieved by the ESME.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

3.2 MS Originated Position Determination for


Emergency Services Call (POST Timer Expiry)

4-43

ANSI/J-STD-036-B

1
2
3

Serving System

4
5
6

MPC

PDE

MSC

MS

ESME

7
8

MIPLSI=1

10

call origination (9-1-1, MIPLI=1)

11

12
13

ORREQ [MSCID, BILLID, DGTSDIAL, SCELLID, MOBINFO, MPCAP]

14
15

POST

orreq

16

ORT
d

17

Call setup [Callback#, ESRD]

18

19
20

data burst (IS-801)

21

22
23

SMDPP [SRVIND, SMS_BearerData]


g

24
25
26

SMDPP [SRVIND, SMS_BearerData]

27
28

SMT

smdpp [SMS_BearerData]

SMT
i

29
30

smdpp [SMS_BearerData]

31

32

data burst (IS-801)

33

34
35

data burst (IS-801)

36

37

SMDPP [SRVIND, SMS_BearerData]

38

39
40
41
42

SMDPP [SRVIND, SMS_BearerData]


SMT

smdpp []

43

n
SMT
o

44
45

smdpp []

46

47

GPOSDIR [POSINFO]

48

49
50
51

gposdir [ ]

GPDT
r

52
53

ESPOSREQ [POSREQTYPE(initial),Callback #, ESRD]

54
55

esposreq[ESRD, Callback #, POSINFO]

56

ESPRT
t

57
58
59

Figure 4-26:

MS Originated Position Determination for Emergency Services Call


(POST Timer Expiry)

60

4-44

3.2 MS Originated Position Determination for


Emergency Services Call (POST Timer Expiry)

ANSI/J-STD-036-B

a. The BS indicates support of MS originated position determination.

1
2

b. The MS originates an Emergency Services call indicating it will initiate position determination (MS_INIT_POS_LOC_IND=1).
c. The Serving MSC sends an ORREQ to the Serving MPC. The MOBINFO parameter
includes the MIPLI set to indicate MS originated position determination. The MPC starts
the POST timer and waits for a GPOSDIR instead of initiating a GPOSREQ.

3
4
5
6
7
8

d. The POST Timer expires before a GPOSDIR for this MS is received from a PDE. The
MPC sends an orreq without the geoposition of the MS and stores the MSID and mobile
information for future use.
e. The MSC routes the Emergency Services Call toward the ESNE selected by the ESRD. See
normative Annex D for call setup signaling formats.
f.-r. Same as section 3.1, steps d.-p.
s.-t. Same as section 2.2.2, steps h.-i.

9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

3.2 MS Originated Position Determination for


Emergency Services Call (POST Timer Expiry)

4-45

ANSI/J-STD-036-B

1
2

3.3

TDMA SAMPS Emergency Position Report

This scenario shows the delivery of Position Information or GPS Measurement Data using the
SAMPS Emergency Position Report procedure following an ESC invocation.

4
5
6
7
8
9

MS

MSC

PDE

MPC

CRDB

ESNE

10
11
12

ESC Invocation

13
14

ORREQ[BillingID, MPCAP]

15
16
17

R-DATA [SAMPS Emergency Position Report]

18
19

SMDPP[SMS_TeleserviceID, SMS_BearerData, MSID]

20
21

SMT

22

POST

smdpp [ ]

23
24

R-DATA ACCEPT [ ]

ORT
f

25
26

GPOSDIR[POSINFO]

27
28

GPDT

29

gposdir [ ]

30
31

POSROUTREQ[Position]

32
33

PRRT

34

posroutreq[Digits]

35

i
j

36

orreq[ESRK or ESRD]

37

38

Emergency Call Setup

39

40
41
42

Figure 4-27:

TDMA SAMPS Emergency Position Report

43
44
45
46
47
48
49

a. The MS invokes an Emergency Services Call.


b. The MSC initiates the ORREQ procedure indicating in the MPCAP parameter the type of
handset positioning that is supported.
Note: Should the mobile require assistance data a SAMPS Positioning Assistance Request
message may be sent to the PDE (Designated SAMPS Teleservice Address).

50
51
52
53
54
55
56
57
58

c. The MS sends an R-DATA message containing a SAMPS Emergency Position Report


message on the Digital Traffic Channel to the PDE.
d. The MSC forwards the information received from the MS in the SMDPP to the PDE.
e. The PDE acknowledges the request with an smdpp.
f. The MSC acknowledges the request with an R-DATA Accept.
g. The PDE sends a GPOSDIR containing the position information to the MPC.

59
60

4-46

3.3 TDMA SAMPS Emergency Position Report

ANSI/J-STD-036-B

h. The MPC acknowledges the request with a gposdir.

1
2

i. Optionally, the MPC may decide that the route must be determined from the MSs current
latitude and longitude. The MPC uses the position to request a routing translation for an
emergency services zone from the CRDB with the POSROUTREQ.
j. The CRDB returns the digits representing an emergency service zone (ESZ) to the MPC
with a posroutreq.

3
4
5
6
7
8

k. The MPC selects a PSAP based on the emergency service zone from the CRDB or from the
latitude and longitude of the mobile based on local procedures. The MPC then assigns and
returns a unique routable call identifier (ESRK) for the particular PSAP selected or an
ESRD in the orreq. See Chapter 8 and normative Annex D for the population of the
signaling parameters.
l. The MSC routes the Emergency Services Call toward the PSAP selected by the ESRK or
ESRD. See normative Annex D for the call setup signaling formats.

9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

3.3 TDMA SAMPS Emergency Position Report

4-47

ANSI/J-STD-036-B

1
2

3.4

TDMA Inter-MSC Three-Way Call to PSAP using SAMPS

This scenario shows the delivery of Position Information to the PSAP after an inter-MSC call has been handed
off. The ESRK method is used for routing to the PSAP and for identification of the ESC.

4
5

Serving

Anchor

7
8

MS

MSC

MSC

PDE

MPC

CRDB

ESME

ESNE

9
10
11
12

ESC Invocation
a

13

FLASHREQ [Digits(dialed), ESRD]

14

15

FRT

16
17

flashreq

18

ORREQ [Callback#, ESRD, Digits(dialed)]

19

20
21

R-DATA [SAMPS Emergency Position Report]

22

ORT

23

SMDBACK[SMS_TeleserviceID, SMS_BearerData, MSID]

24

25

SMDPP[SMS_TeleserviceID, SMS_BearerData(position information)]

26

27
28

SMT

SBT

29

smdpp[ ]

30
31

POST

smdback[ ]

32
33
34

R-DATA ACCEPT[ ]
j

35

GPOSDIR[MSID, POSINFO]

36

37

GPDT

38
39

gposdir [ ]
l

40

POSROUTREQ [Position]

41

42

PRRT
posroutreq [Digits]

43
44

45

orreq [Digits(Dialed)(ESRK)]

46

47
48

Call Setup [ESRK]

49

50
51

52

ESPOSREQ [ESRK, POSREQTYPE(initial)]

53

54
55

esposreq[ESRD, Callback #, POSINFO]

56

ESPRT
s

57
58
59

Figure 4-28:

TDMA Inter-MSC Three-Way Call to PSAP using SAMPS

60

4-48

3.4 TDMA Inter-MSC Three-Way Call to PSAP


using SAMPS

ANSI/J-STD-036-B

a. The MS invokes an Emergency Service Call via 3-way calling while another call is in
progress.

1
2
3

b. The Serving MSC notifies the next switch in the handoff chain of the event with a
FLASHREQ.

c. The Anchor MSC acknowledges the event with a flashreq.

d. The Anchor MSC initiates the ORREQ procedure indicating in the MPCAP parameter the
type of handset positioning that is supported.
e. The MS sends an Emergency Position Report message on the Digital Traffic Channel.
Note: Should the mobile require assistance data a SAMPS Position Assistance Request
message may be sent to the PDE (Designated SAMPS Teleservice Address).
f. The Serving MSC sends an SMDBACK to the Anchor MSC containing the position information.
g. The Anchor MSC sends an SMDPP to the Anchor PDE with the position information.

8
9
10
11
12
13
14
15
16
17
18

h. The Anchor PDE sends an smdpp to the Anchor MSC.


i. The Anchor MSC sends an smdback to the Serving MSC.

19
20
21

j. The Serving MSC sends the R-DATA Accept to the MS.


k. The Anchor PDE sends a GPOSDIR containing the position information to the Anchor
MPC.
l. The Anchor MPC sends a gposdir to the Anchor PDE.
m. Optionally, the Anchor MPC may decide that the route must be determined from the MSs
current latitude and longitude. The MPC uses the position to request routing translations
for an emergency service zone from the CRDB with the POSROUTEREQ.
n. The CRDB returns the digits representing an emergency service zone (ESZ) to the MPC
with a posroutreq.
o. The Anchor MPC selects a PSAP based on the emergency service zone from the CRDB or
from the latitude and longitude of the mobile based on local procedures. The Anchor MPC
then assigns and returns a unique routable call identifier (ESRK) for the particular PSAP
selected or an ESRD in the orreq. See Chapter 8 and normative Annex D for the population
of the signaling parameters.
p. The Anchor MSC routes the Emergency Service Call toward the PSAP selected by the
ESRK or ESRD. See normative Annex D for call setup signaling formats.

22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

q. Some time later

42

r. The ESME requests the initial position.

43
44

s. The MPC returns the cached position.

45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

3.4 TDMA Inter-MSC Three-Way Call to PSAP


using SAMPS

4-49

ANSI/J-STD-036-B

1
2

Interim Position

4.1

Successful Routing Based on Interim Position

3
4
5
6

This scenario shows the MPC, and optionally, the CRDB using low latency position information
from the PDE to determine appropriate routing to the ESNE. The completion of the GeoPositionRequest transaction completes accurate location estimation for NCAS delivery.

7
8
9
10
11
12
13

MS

CRDB

MSC

PDE

MPC

ESME

ESNE

14
15
16
17

ESC Invocation
a

18

ORREQ [MDN, BillingID, MPCAP, MOBINFO]

19

20
21

GPOSREQ [MOBINFO, POSREQTYPE(initial), MPCAP]

22

23

GPOSDIR[POSINFO]

24
25

GPDT

26

gposdir

27
28

ORT

29

POST

POSROUTREQ [Position]
f

30

PRRT

31

posroutreq [Digits]

32
33

orreq [ESRK or ESRD]

34

35

GPRT

36

Call Setup [ESRK or (Callback# + ESRD)]

37
38

ESPOSREQ [ESRK/ESRD, POSREQTYPE(initial)]

39

40
41

gposreq [POSINFO]

42
43

ESPRT

esposreq [POSINFO]

44

k
l

45
46
47

Figure 4-29:

Successful Routing Based on Interim Position

48
49
50
51
52
53
54
55
56
57
58

a. The MS invokes an Emergency Services Call.


b. The MSC analyzes the digits dialed by the MS and requests routing instructions based on
position using an ORREQ to the MPC. MDN is provided as a callback number. The
BillingID is provided to uniquely identify the call.
c. Since the MPC has mobile information, it can query the proper PDE directly with a
GPOSREQ. The MPC requests initial position.
Optionally, a handset-based solution may have PDE to MS communication. See Section 2
PDE to MS Scenarios for Handset-Based PDE on page 4-28.

59
60

4-50

4 Interim Position

ANSI/J-STD-036-B

d. The PDE calculates a position and returns it in a GPOSDIR (in a separate TCAP transaction
from the GPOSREQ).

1
2
3

e. The MPC confirms the receipt of the low latency position estimate with a gposdir.
Optionally, the PDE may continue to update the MPC with more accurate location estimations or location estimations produced by an alternate location technology. Such updates
would result in repeating Steps d and e until a final location estimate is provided by the PDE
in a gposreq (as in Step k).

4
5
6
7
8
9

f. Optionally, the MPC may decide that the route must be determined from a given latitude/
longitude position, the MPC uses the position to request a routing translation for an
emergency services zone from the CRDB with a POSROUTREQ.

10

g. The CRDB returns the digits representing an emergency services zone (ESZ) to the MPC
with a posroutreq.

14

h. The MPC selects a PSAP based on the emergency services zone from the CRDB or from
the latitude and longitude of the mobile based on local procedures. The MPC then generates
a unique routable call identifier (ESRK) for the particular PSAP selected or an ESRD in the
orreq.
i. The MSC routes the Emergency Services Call toward the PSAP selected by the ESRK or
ESRD.
j. The ESME requests initial position.
k. At some point (possibly before the ESME requests initial position, or after, as shown here)
the PDE produces a final, highest accuracy location which it delivers to the MPC via the
gposreq.
l. The MPC returns the highest accuracy position available.

11
12
13

15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

4 Interim Position

4-51

ANSI/J-STD-036-B

1
2

4.2

Interim Position Used as Final Position Due to Timeout

This scenario shows the MPC and optionally the CRDB using interim position information from the
PDE to determine appropriate routing to the ESNE and then uses the low latency position as the final
position when the PDE fails to respond with an accurate, final position.

4
5
6
7
8
9
10

MS

CRDB

MSC

PDE

MPC

ESME

ESNE

11
12
13

ESC Invocation
a

14
15

ORREQ [MDN, BillingID, MPCAP, MOBINFO]

16

17

GPOSREQ [MOBINFO, POSREQTYPE(initial), MPCAP]

18
19
20

GPOSDIR[POSINFO]

21

c
d

GPDT

22

gposdir

23

POST

24

ORT

25

POSROUTREQ [Position]
f

26
27

PRRT

28

posroutreq [Digits]

29
30

orreq [ESRK or ESRD]

31

GPRT

32

Call Setup [ESRK or (Callback# + ESRD)]

33

34
35

ESPOSREQ [ESRK/ESRD, POSREQTYPE(initial)]

36
37
38

ESPRT

39

esposreq [POSINFO]

40

41
42
43

Figure 4-30:

Successful Routing Based on Interim Position

44
45
46
47
48
49
50
51
52
53
54

a. The MS invokes an Emergency Services Call.


b. The MSC analyzes the digits dialed by the MS and requests routing instructions based on
position using an ORREQ to the MPC. MDN is provided as a callback number. The
BillingID is provided to uniquely identify the call.
c. Since the MPC has mobile information, it can query the proper PDE directly with a
GPOSREQ. The MPC requests initial position.
Optionally, a handset-based solution may have PDE to MS communication. See Section 2
PDE to MS Scenarios for Handset-Based PDE on page 4-28.

55
56
57
58
59

d. The PDE calculates a position and returns it in a GPOSDIR (in a separate TCAP transaction
from the GPOSREQ).
e. The MPC confirms the receipt of the low latency position estimate with a gposdir.

60

4-52

4 Interim Position

ANSI/J-STD-036-B

Optionally, the PDE may continue to update the MPC with more accurate location estimations or location estimations produced by an alternate location technology. Such updates
would result in repeating Steps d and e until a final location estimate is provided by the PDE
in a gposreq (as in Step k).
f. Optionally, the MPC may decide that the route must be determined from a given latitude/
longitude position, the MPC uses the position to request a routing translation for an
emergency services zone from the CRDB with a POSROUTREQ.

1
2
3
4
5
6
7
8
9

g. The CRDB returns the digits representing an emergency services zone (ESZ) to the MPC
with a posroutreq.

10
11

h. The MPC selects a PSAP based on the emergency services zone from the CRDB or from
the latitude and longitude of the mobile based on local procedures. The MPC then generates
a unique routable call identifier (ESRK) for the particular PSAP selected or an ESRD in the
orreq.

12

i. The MSC routes the Emergency Services Call toward the PSAP selected by the ESRK or
ESRD.

17

j. The ESME requests initial position.


k. The MPC GPRT timer expires without receiving a gposreq from the PDE.
l. The MPC returns the highest accuracy position available.

13
14
15
16

18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

4 Interim Position

4-53

ANSI/J-STD-036-B

1
2

4.3

Interim Position Used as Final Position Due to PDE Error

This scenario shows the MPC, and optionally the CRDB, using interim position information from
the PDE to determine appropriate routing to the ESNE and then uses the low latency position as the
final position when the PDE reports a failure to obtain an accurate, final position.

4
5
6
7
8
9
10

MS

CRDB

MSC

PDE

MPC

ESME

ESNE

11
12
13

ESC Invocation
a

14
15

ORREQ [MDN, BillingID, MPCAP, MOBINFO]

16

17

GPOSREQ [MOBINFO, POSREQTYPE(initial), MPCAP]

18
19
20

GPOSDIR[POSINFO]

21

c
d

GPDT

22

gposdir

23

POST

24

ORT

25

POSROUTREQ [Position]
f

26
27

PRRT

28

posroutreq [Digits]

29
30

orreq [ESRK or ESRD]

31

GPRT

32

Call Setup [ESRK or (Callback# + ESRD)]

33

34
35

ESPOSREQ [ESRK/ESRD, POSREQTYPE(initial)]

36
37

gposreq [POSRESULT]

38

ESPRT

39

esposreq [POSINFO]

40

41
42
43

Figure 4-31:

Successful Routing Based on Interim Position

44
45
46
47
48
49
50
51
52
53
54

a. The MS invokes an Emergency Services Call.


b. The MSC analyzes the digits dialed by the MS and requests routing instructions based on
position using an ORREQ to the MPC. MDN is provided as a callback number. The
BillingID is provided to uniquely identify the call.
c. Since the MPC has mobile information, it can query the proper PDE directly with a
GPOSREQ. The MPC requests initial position.
Optionally, a handset-based solution may have PDE to MS communication. See Section 2
PDE to MS Scenarios for Handset-Based PDE on page 4-28.

55
56
57
58
59

d. The PDE calculates a position and returns it in a GPOSDIR (in a separate TCAP transaction
from the GPOSREQ).
e. The MPC confirms the receipt of the low latency position estimate with a gposdir.

60

4-54

4 Interim Position

ANSI/J-STD-036-B

Optionally, the PDE may continue to update the MPC with more accurate location estimations or location estimations produced by an alternate location technology. Such updates
would result in repeating Steps d and e until a final location estimate is provided by the PDE
in a gposreq (as in Step k).
f. Optionally, the MPC may decide that the route must be determined from a given latitude/
longitude position, the MPC uses the position to request a routing translation for an
emergency services zone from the CRDB with a POSROUTREQ.

1
2
3
4
5
6
7
8
9

g. The CRDB returns the digits representing an emergency services zone (ESZ) to the MPC
with a posroutreq.

10
11

h. The MPC selects a PSAP based on the emergency services zone from the CRDB or from
the latitude and longitude of the mobile based on local procedures. The MPC then generates
a unique routable call identifier (ESRK) for the particular PSAP selected or an ESRD in the
orreq.

12

i. The MSC routes the Emergency Services Call toward the PSAP selected by the ESRK or
ESRD.

17

j. The ESME requests initial position.


k. At some time the PDE fails to complete a location and returns a POSRESULT indicating
the error in the gposreq instead of a position.
l. The MPC returns the highest accuracy position available.

13
14
15
16

18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

4 Interim Position

4-55

ANSI/J-STD-036-B

1
2

Interface Testing

5.1

Test Message Initiated by ESME

3
4
5
6

This scenario shows the sending of ESPOSREQ with a type test as a mechanism for the Emergency
Services Network to check that the ESME and MPC applications are communicating.

7
8
9
10
11
12

MPC

ESME

13
14

ESPOSREQ [POSREQTYPE(test)]

15
16

ESPRT

17

esposreq [POSRSULT (test)]

18

19
20
21

Figure 4-32:

Test Message Initiated by ESME

22

a. The ESME sends an ESPOSREQ indicating test purposes.

23
24

b. The MPC responds immediately with a successful test response. No further processing is
required by the MPC.

25
26
27
28
29
30
31
32

5.2

Heartbeat Mechanism Initiated by MPC


This scenario shows the sending of GPOSREQ with a type heartbeat as a mechanism for the Location
Network to check that the MPC and PDE applications are communicating.

33
34
35

PDE

36

MPC

37
38

GPOSREQ [POSREQTYPE(heartbeat)]

39

40

GPRT
gposreq [POSRSULT (ReqAck)]

41
42

43
44
45

Figure 4-33:

Heartbeat Mechanism Initiated by MPC

46
47
48
49
50

a. The MPC sends a GPOSREQ indicating heartbeat purposes.


b. The PDE responds immediately with a Request Acknowledgement. No further processing
is required by the PDE.

51
52
53
54
55
56
57
58
59
60

4-56

5 Interface Testing

ANSI/J-STD-036-B

Chapter 5: Functional Overview, GSM/


UMTS

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

16

Introduction

17
18

See Chapter 3: Functional Overview, ANSI-41 Section 1.

19
20
21

22

Methodology

23
24

See Chapter 3: Functional Overview, ANSI-41, Section 2.

25
26
27
28

Condensed GSM/UMTS Network Reference Model


The network reference model applicable to support of Emergency Services calls by GSM/UMTS networks
is shown in Figure 5-1.

29
30
31
32
33
34

I.

35
36

LMU
Serving
MLC

Lb

Um

37

scope of this
document

Ls

38
39
40

Lg

E
Serving
MSC

BSS

Visited
MSC

41

Gateway
MLC

Ai Di

E2

Um
Iu

Emergency
Service
Network
Entity

MS
Uu

RNS

These interfaces
are beyond the
scope of this
document

42
43
44
45
46

Emergency
Service
Message
Entity

47
48
49
50

Emergency Services Network

51
52

Uu

53

PSAP

54
55

LMU

56
57

Figure 5-1:

Condensed GSM/UMTS Network Reference Model

58
59
60

5-1

ANSI/J-STD-036-B

1
2

Network Entities

4.1

Base Station System (BSS)

3
4
5
6

The Base Station Subsystem (BSS) receives the emergency call from the MS when the call is made using
GSM and notifies the VMSC. The BSS is also involved in the handling of certain positioning procedures. As
a generic handling procedure, the BSS provides Cell-id and Timing Advance (TA) to the anchor MSC to
assist in obtaining a position estimate. Specific BSS functionality in positioning procedures is specified in
TS 43.059.

7
8
9
10
11
12
13
14

4.2

Emergency Services Message Entity (ESME)

15

The ESME routes and processes the out-of-band messages related to emergency calls. This may be incorporated into selective routers (also known as Routing, Bridging and Transfer switches) and Automatic Location
Information (ALI) database engines. The structure of the Emergency Services Network is beyond the scope
of the Interim Standard, although some insight may be gained from informative Annex A.

16
17
18
19
20
21
22

4.3

23

Emergency Services Network Entity (ESNE)


The ESNE routes and processes the voice band portion of the emergency call. This is composed of selective
routers (also known as Routing, Bridging and Transfer switches). The structure of the Emergency Servieces
Network is beyond the scope of thie Interim Standard, although some insight may be gained from
informative Annex A.

24
25
26
27
28
29
30

4.4

Gateway Mobile Location Center (GMLC)


The Gateway Mobile Location Center (GMLC) contains functionality required to support delivery of a
mobiles position to the ESME and may provide call routing information to the MSC. The GMLC handles
requests for a mobiles initial, updated (current), or last known position from the ESME. In one PLMN, there
may be more than one GMLC.

31
32
33
34
35

The GMLC sends positioning requests to and receives final position estimates from the visited MSC via the
Lg interface. The GMLC stores the initial position estimate to support NCAS Pull.

36
37
38
39
40

4.5

Location Measurement Unit (LMU)


A Location Measurement Unit (LMU) makes radio measurements to support the determination of a mobiles
position. All position and assistance measurements obtained by an LMU are supplied to a particular SMLC
associated with the LMU. Signaling to an LMU may be performed over the GSM/UMTS air interface (Um
interface).

41
42
43
44
45
46
47

4.6

48

Mobile Station (MS)


The Mobile Station (MS) initiates the emergency call and may be involved in determining its position.

49
50
51

4.7

Mobile services Switching Center (MSC)

52
53
54
55
56
57
58
59

For emergency call origination, a GSM/UMTS MS interacts with a local serving MSC and, in some cases,
with a separate visited (anchor) MSC. Only a single MSC is involved (visited and serving MSC) for an
emergency call that is not in MSC-MSC handover state. Two separate MSCs are involved, serving MSC and
visited (or anchor) MSC, for an emergency call in MSC-MSC handover state.
The Visited (Anchor) Mobile Switching Center (VMSC) sets up the emergency call to the emergency service
network and initiates requests to the SMLC for a mobiles position.

60

5-2

ANSI/J-STD-036-B

If NCAS is supported, the VMSC (based on cell/sector identity) pushes the mobiles initial position to the
GMLC when it becomes known. The VMSC, if NCAS is supported, may obtain ESC routing information
from the GMLC.
The serving MSC, when this is distinct, relays all emergency call signaling messages between the BSS and
visited MSC using the GSM/UMTS E interface.

1
2
3
4
5
6
7

4.8

Serving Mobile Location Center (SMLC)


The Serving Mobile Location Center (SMLC) manages may manage the overall coordination and scheduling
of resources required to determine a mobiles position. For some position methods, it also calculates the final
position estimate and accuracy. In one PLMN, there may be more than one SMLC. For GSM, the SMLC is
considered to be external to the core network and BSS. For UMTS, the SMLC is considered to be part of the
RNS. Specific SMLC functionality for GSM is defined in TS 43.059. Specific SMLC functionality for UMTS
is defined in TS 25.305.

8
9
10
11
12
13
14
15
16
17

4.9

Radio Network Subsystem (RNC)

18

The Radio Network Subsystem (RNS) receives the emergency call from the MS, when the call is made using
UMTS, and notifies the VMSC. The RNS also handles the positioning of the MS using an SMLC contained
in the RNS. Specific RNS support of positioning is defined in TS 25.305. Specific interaction within the RNS
applicable to a standalone SMLC is defined in TS 25.453.

20

19

21
22
23
24
25
26

GSM/UMTS Network Interfaces and Reference


Points

27
28
29
30
31

5.1

A Interface

32

The A interface is between the BSS and serving MSC and is applicable to an MS making an ESC using GSM.
Aspects relevant to supporting Emergency Services calls are defined in TS 48.008 and TS 49.031.

33
34
35
36

5.2

37

Ai Reference Point

38

The Ai Reference Point is between the visited MSC and a selective router, PSTN tandem or, as shown in
Figure 5-1, the ESNE. It supports analog (e.g., MF) signaling.

39
40
41
42

5.3

Di Reference Point

43
44

The Di Reference Point is between the visited MSC and a selective router, PSTN tandem or, as shown in
Figure 5-1, the ESNE. It supports a digital interface and is based on ANSI T1.113 when SS7 ISUP signaling
is used.

45
46
47
48
49

5.4

E Interface

50

The E interface exists between a serving MSC and visited MSC for an MS with an established call in a state
of MSC-MSC handover. It is defined in TS 29.002 and TS 29.008.

51
52
53
54

5.5

E2 Reference Point

55

The E2 Reference Point exists between the GMLC and ESME.

57

56

58
59
60

5-3

ANSI/J-STD-036-B

1
2

5.6

Lg Interface
The Lg Interface exists between the GMLC and visited MSC. The protocol to be used on this interface is
defined in TS 23.271 and TS 29.002.

3
4
5
6
7

5.7

Ls Interface
The Ls interface exists between the SMLC and visited MSC. It is defined in TS 43.059 and TS 49.031.

8
9
10
11

5.8

12

Lb Interface
The Lb interface exists between the SMLC and serving BSS. It is defined in TS 43.059 and TS 49.031.

13
14
15

5.9

Um Interface

16
17
18
19

The Um interface exists between the BSS and LMU and between the BSS and MS and is applicable to an MS
making an ESC using GSM. It is defined in TS 23.271, TS 24.008, TS 43.059, TS 44.018, TS 44.031 and
TS 44.071.

20
21
22

5.10 Iu Interface

23
24
25

The Iu interface exists between the RNS and serving MSC and is applicable to an MS making an ESC using
UMTS. Aspects applicable to supporting Emergency Services calls are defined in TS 25.413.

26
27
28

5.11 Uu Interface

29
30
31

The Uu interface exists between the RNS and LMU and between the RNS and MS and is applicable to an
MS making an ESC using UMTS. It is defined in TS 25.331, TS 25.305, and TS 24.008.

32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

5-4

ANSI/J-STD-036-B

Emergency Services Messages Applicable to GSM/UMTS

The messages used between GSM/UMTS network entities and between GSM/UMTS network entities and
emergency services network entities to support provision of geographic position include the following:

EmergencyServicesPositionRequest (ESPOSREQ, esposreq)


MAP Subscriber Location Report (ETSI GSM MAP)
MAP Provide Subscriber Location (ETSI GSM MAP)

4
5
6
7
8
9
10

6.1

Messages between a GSM/UMTS GMLC and ESME E2


Reference Point

11
12
13
14

6.1.1

EmergencyServicesPositionRequest

15
16

The EmergencyServicesPositionRequest message is used to request the initial, updated or last


known position of an MS. It is sent over the E2 Reference Point from an ESME to a GMLC to
support NCAS Pull.

17
18
19
20

The EmergencyServicesPositionRequest message may be triggered from an emergency service


provider when:

21
22
23

The position of an MS engaged in an Emergency Services call is required.

24
25
26

6.2

Messages between a GSM/UMTS GMLC and MSC Lg Interface

27
28

6.2.1

MAP Subscriber Location Report


The MAP Subscriber Location Report message is used by a VMSC to provide the position of an MS
to a GMLC over the Lg interface. This message is used to send the mobiles initial position or
location estimate to the GMLC and to notify the GMLC when the emergency services call is ended.
The MAP Subscriber Location Report message may be triggered when:

The initial position for an emergency call becomes available


A location estimate (interim position) for an emergency call becomes available
An emergency call is released

29
30
31
32
33
34
35
36
37
38
39
40

The MAP Subscriber Location Report message and its acknowledgment, for the Emergency
Services Application, contain the parameters shown in the following tables. The detailed content and
encoding of these parameters are defined in TS 29.002. In case of inconsistency, the definition in
TS 29.002 has precedence over the definition here.

41
42
43
44
45

Table 5-1:

MAP Subscriber Location Report Invoke parameters

46
47
48

Parameter

MOC

Usage

LCS Event

This parameter indicates the event that triggered the MAP


subscriber location report. For an emergency services call, this
parameter indicates either an emergency call origination or
emergency call release.

50

This parameter provides information to identify the type and the


identity of the LCS client to which the position information should
be forwarded. For emergency services, only the client type is
identified.

54

49

LCS Client ID

51
52
53

55
56
57
58

MSC Number

Gives the E.164 address of the VMSC.

59
60

6 Emergency Services Messages Applicable to


GSM/UMTS

5-5

ANSI/J-STD-036-B

Table 5-1:

MAP Subscriber Location Report Invoke parameters

2
3

Parameter

MOC

Usage

IMSI

Identifies a mobile subscriber. To be included if available.

MSISDN

Provides a dialable or non-dialable callback number identifying a


mobile subscriber. To be included if available.

ESRD

Normally, identifies the initial base station, cell site or sector of an


emergency services call and it may also identify the ESZ corresponding to the initial geographic position of the ESC calling MS.
To be included if available.

ESRK

Identifies both an ongoing Emergency Services call and its


associated MS in a particular system and the GMLC used for
communicating with the ESME. The ESRK may optionally identify
the visited MSC at which the call originated. The ESRK shall be
provided when it is included in the emergency services call setup.

na-ESRKRequest

The na-ESRK-Request parameter is used to indicate that an MSC


will accept an ESRK OR ESRD from the GMLC.

IMEI

Identifies the mobile equipment used to originate an Emergency


Services call. This parameter need not be supported.

Location
Estimate

Identifies the caller s geographic position and the accuracy of this


position. To be included if available. If not included, positioning
failure is implied if the LCS event indicates ESC origination.

Age of
Location
Estimate

Indicates how long ago the location estimate was obtained. To be


included if a location estimate is included.

LMSI

A local identifier for the target MS in the VLR.

cellIdOrSai

This parameter indicates the Global Cell Identifier or the Service


Area Identifier that the served subscriber is currently attached to.

geranPositioningData

Indicates a positioning method used in GSM to calculate the


location estimate. May be included if a location estimate is
included.

utranPositioningData

Indicates a positioning method used in UMTS to calculate the


location estimate. May be included if a location estimate is
included.

4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

Table 5-2:

MAP Subscriber Location Report Return Result parameters

45
46

Parameter

MOC

Usage

ESRK

Provides the ESRK when the na-ESRK-Request parameter was


included in the MAP Subscriber Location Report Invoke. ESRK
and ESRD are mutually Exclusive.

ESRD

Provides the ESRD when the na-ESRK-Request parameter was


included in the MAP Subscriber Location Report Invoke. ESRK
and ESRD are mutually Exclusive.

47
48
49
50
51
52
53
54
55
56
57
58
59
60

5-6

6 Emergency Services Messages Applicable to


GSM/UMTS

ANSI/J-STD-036-B

Table 5-3:

MAP Subscriber Location Report Return Error parameters

1
2

Parameter

MOC

Usage

User Error

Indicates some error in the Invoke message or in the GMLC that


prevents the location related information from being accepted.
The following error types are allowed:

3
4

System Failure
Data Missing
Unexpected Data Value
Resource Limitation
Unknown Subscriber
Unauthorized Requesting network
Unknown or Unreachable LCS Client

5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

6 Emergency Services Messages Applicable to


GSM/UMTS

5-7

ANSI/J-STD-036-B

1
2

6.2.2

MAP Provide Subscriber Location


The MAP Provide Subscriber Location message is used by a GMLC to request the position of a
target MS from the visited MSC over the Lg interface. This message is used to support NCAS Pull
of the initial, updated or last known position. The MAP Provide Subscriber Location message may
be triggered when:

3
4
5
6
7

8
9
10

11
12

The MAP Provide Subscriber Location message and its response, for the Emergency Services Application, contain the parameters shown in the following tables. The detailed content and encoding of
these parameters are defined in TS 29.002. In case of inconsistency, the definition in TS 29.002 has
precedence over the definition here.

13
14
15
16
17
18
19
20
21
22

The initial position of an MS is requested by a GMLC (typically following the receipt


of a location estimate for this MS).
The updated or last known position of an MS is requested from a GMLC by an ESME

Table 5-4:

MAP Provide Subscriber Location Invoke parameters


Parameter

MOC

Usage

Location Type

Identifies the type of location requested from among the following


alternatives:

23

24
25
26
27
28

MLC Number

Provides the E.164 address of the requesting GMLC

LCS Client ID

Provides information identifying the client (e.g., ESME)


requesting location. For emergency service requests, this parameter shall indicate a location request from an emergency services
provider. Additional client identification information (e.g., client
address or name) is not required.

Privacy
Override

This parameter indicates if MS privacy is overridden by the client


requesting location. For emergency service requests, this parameter shall not be included.

IMSI

Identifies the target MS. Either IMSI or MSISDN shall be provided.

MSISDN

Contains a dialable or non-dialable callback number that identifies


the target MS. Either IMSI or MSISDN shall be provided.

LMSI

A local identifier for the target MS in the VLR. To be included if


available and if the IMSI is included.

LCS Priority

Indicates the priority of the location request. For emergency


service related requests, the highest priority shall be requested.

LCS QoS

Indicates the required Quality of Service in terms of accuracy and


response time. For emergency service related requests, the
accuracy shall be consistent with prevailing local and national
regulatory requirements. Response time shall be set according to
agreements with the requesting emergency service provider to
indicate one of:
low delay (minimizing delay takes precedence over accuracy)
delay tolerant (accuracy takes precedence over minimizing delay)

IMEI

Identifies the mobile equipment used to originate an Emergency


Services call. This parameter need not be supported.

29
30
31
32
33
34

updated location
updated or last known location

35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

5-8

6 Emergency Services Messages Applicable to


GSM/UMTS

ANSI/J-STD-036-B

Table 5-5:

MAP Provide Subscriber Location Return Result parameters

1
2

Parameter

MOC

Usage

Location
Estimate

Identifies the caller s geographic position and the accuracy of this


position. This parameter is mandatory: if not available, a Return
Error response rather than Return Result shall be sent.

3
4

Age of
Location
Estimate

cellIdOrSai

Indicates how long ago the location estimate was obtained.

5
6
7
8
9
10
11

This parameter indicates the Global Cell Identifier or the Service


Area Identifier that the served subscriber is currently attached to.

12
13
14

geranPositioningData

utranPositioningData

Indicates a positioning method used in GSM to calculate the


location estimate. May be included if a location estimate is
included.
Indicates a positioning method used in UMTS to calculate the
location estimate. May be included if a location estimate is
included.

15
16
17
18
19
20
21

Table 5-6:

MAP Provide Subscriber Location Return Error parameters


Parameter

MOC

22
23
24

Usage

25

User Error

Indicates some error in the Invoke message or in the serving


network that prevents a location estimate being returned. The
following error types are allowed:

System Failure
Data Missing
Unexpected Data Value
Facility Not Supported
Unidentified Subscriber
Illegal Subscriber
Illegal Equipment
Absent Subscriber (diagnostic information may also be provided)
Unauthorized requesting network
Unauthorized LCS Client with detailed
reason
Position method failure with detailed
reason

26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

6 Emergency Services Messages Applicable to


GSM/UMTS

5-9

ANSI/J-STD-036-B

1
2
3
4
5

Chapter 6: Stage 2 Emergency Services


Network Description, GSM/UMTS

6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

The following scenarios show several methods for delivering the position of a mobile that originates an
emergency call to the emergency service network. These methods include the following:
Call Associated Signalling (CAS) Push
Non-Call Associated Signalling (NCAS) Pull
Scenarios are also shown to cover handovers and position determination failures. Emergency call routing by
the VMSC to the PSAP using a mobiles initial position is also supported in some of the scenarios.
In all scenarios, the visited MSC is shown to obtain a position estimate via a direct request to an SMLC. This
is valid for an ESC in GSM with an SMLC accessible over the Ls (MSC to SMLC) interface. For an ESC in
GSM with an SMLC accessible over the Lb (BSS to SMLC) interface, the position request from the visited
MSC is sent instead (via the serving MSC in the case of MSC to MSC handover) to the BSC serving the MS
being positioned. The BSC then determines the SMLC and forwards to it the position request; the position
response from the SMLC is likewise returned to the visited MSC via the BSC (and via the serving MSC in
the case of MSC to MSC handover).
The scenarios shown in this chapter apply only to an ESC in GSM. For an ESC in UMTS, the BSS in each
scenario would be replaced by an RNS and the SMLC (shown as a separate entity in the scenarios) would be
internal to the RNS. ESC invocation from the MS to the RNS and from the RNS to the serving MSC would
use different signaling and procedures as defined in TS 25.331 and TS 25.413, respectively. ESC invocation
messages from the MS to the serving and visited MSCs (e.g., DTAP CM Service Request and EMERGENCY
SETUP) are the same as those shown in the scenarios here for GSM. For an ESC in UMTS, the position
request from the visited MSC is sent to the RNS serving the MS being positioned (and via the serving MSC
in the case of MSC to MSC handover). The RNS then performs the positioning, making use of an SMLC
internal to the RNS, and returns the position response to the visited MSC (and via the serving MSC in the case
of MSC to MSC handover). Details of the transfer of the positioning request and positioning response can be
found in TS 23.271 and TS 25.413. Details of the positioning procedure within the RNS can be found in TS
25.305 and TS 25.453. Other aspects of the scenarios shown in this chapter for GSM involving signaling and
procedures for the serving MSC, visited MSC, GMLC, ESNE and ESME apply without change to UMTS.
Note that these scenarios show only the parameters that are relevant to a particular scenario and do not show
all of the parameters that are needed for the transaction. Refer to Stage 3 documentation for specific
parameter requirements.

44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

6-1

ANSI/J-STD-036-B

Emergency Location Information Delivery (ELID) Scenarios

CAS and NCAS solutions are not mutually exclusive (i.e., both solutions may be supported).

4
5

1.1

ELID Using CAS Push

The ELID CAS push scenarios provide the initial position of the emergency caller at call setup. Provision of
the emergency callers initial position once the emergency services call is setup is not supported with a CAS
push mechanism. Provision of the emergency callers updated position during the emergency services call is
not supported with a CAS push mechanism.
For the ELID CAS push scenarios, routing based on the initial lat/long information may be performed by the
VMSC.
In The CAS push scenarios described here may be followed by an NCAS Pull as described in section 2.
In each of the CAS push scenarios shown here, the emergency calling MS sends an EMERGENCY SETUP
message (as defined in TS 24.008) after the CM Service Request. This message is not shown here and does
not affect the positioning procedure for the MS, which may start before or after the message is received by
the visited MSC.

7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

1.1.1

ELID with Successful CAS Push

22
23

This scenario shows delivery of position information (i.e., initial lat/long) with CAS push during call setup.

24
25
26
27

Anchor/Serving

28
29
30

MS

BSS

MSC

SMLC

31

ESNE

32
33
34

CM Service Request

35
36
37

BSSMAP Complete Layer 3 [CM Service Request]

38
39
40

Perform Location Request [QoS]

41
42
43

Messages for Specific Positioning Method

POST

44

45
46
47

Perform Location Response [lat/long]

48
49
50

Call Setup IAM [CgPN=callback#, GDP=ESRD, CGL=lat/long]

51
52

Figure 6-1:

53

ELID with Successful CAS Push

54
55

a. An initially idle MS requests an SDCCH and sends a DTAP CM Service Request indicating
a request for an Emergency Services call to the BSS. The MS may identify itself using a
TMSI, IMSI or IMEI.

56
57
58
59
60

1 Emergency Location Information Delivery (ELID)


Scenarios

6-2

ANSI/J-STD-036-B

1
2
3

b. The BSS includes the current cell ID and possibly other measurement information within
the BSSMAP Complete Layer 3 Information message used to convey the CM service
request across the A-interface to the visited MSC.

4
5
6
7
8
9
10
11
12

c. The visited MSC starts a POST timer and sends a request to perform location to the SMLC
associated with the MSs current cell location. This request includes the MSs location
capabilities and currently assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the
QoS required for an emergency call and the current Cell ID and possibly other
measurement information.
d. The SMLC initiates a suitable position method. The messages for the specific positioning
method are internal to the GSM/UMTS network and are described in TS 03.71, TS 25.305
and TS 43.059.

13
14
15
16
17
18
19
20
21
22

e. The SMLC returns the MS position estimate to the VMSC.


f. The VMSC may use an internal Coordinate Routing Database (CRDB) to determine the
ESZ corresponding to the MSs initial position. The VMSC can then select an ESRD that
identifies the serving cell and the ESZ serving the MSs initial position. The MSC extends
the call to the ESNE associated with either the ESRD selected based on the ESZ or the
default ESRD for the originating cell. The IAM CgPN contains a dialable callback number
(i.e., MSISDN) or a non-dialable callback number derived from the IMEI. The IAM
includes the MS position estimate (lat/long) and the Cell ID (ESRD).

23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

6-3

1 Emergency Location Information Delivery (ELID)


Scenarios

ANSI/J-STD-036-B

1.1.2

ELID with Timed-Out CAS Push

1
2

This scenario shows the handling of the Emergency Services call when the initial lat/long information is not
obtained in time for delivery with the call setup (i.e., the E911 positioning timer value is set to zero or the
timer expires before the lat/long information is obtained). While a position estimate is not then provided to
the ESNE, the identity of the cell ID and MSISDN for the originating MS may be provided.

3
4
5
6
7
8
9
10

Anchor/Serving

11
12
13

MS

BSS

MSC

SMLC

ESNE

14
15
16

CM Service Request

17
18
19

BSSMAP Complete Layer 3 [CM Service Request]

20
21
22

Perform Location Request [QoS]

23

24
25
26

Messages for Specific Positioning Method

27
28

POST Call Setup IAM [CgPN=callback#, GDP=ESRD]

29

30
31
32

Perform Location Response [lat/long]

33

34
35

Figure 6-2:

36

ELID with Timed-Out CAS Push

37
38

a. An initially idle MS requests an SDCCH and sends a DTAP CM Service Request indicating
a request for an Emergency Services call to the BSS. The MS may identify itself using a
TMSI, IMSI or IMEI.
b. The BSS includes the current cell ID and possibly other measurement information within
the BSSMAP Complete Layer 3 Information message used to convey the CM service
request across the A-interface to the visited MSC.

39
40
41
42
43
44
45

c. The visited MSC starts a POST timer and sends a request to perform location to the SMLC
associated with the MSs current cell location. This request includes the MSs location
capabilities and currently assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the
QoS required for an emergency call and the current Cell ID and possibly other
measurement information.

46
47
48
49
50

d. The SMLC initiates a suitable position method. The messages for the specific positioning
method are internal to the GSM/UMTS network and are described in TS 03.71, TS 25.305
and TS 43.059.

51

e. When the POST timer expires, the VMSC sets up the call by sending an Initial Address
Message (IAM) to the ESNE. The IAM CgPN contains a dialable callback number
(i.e., MSISDN) or a non-dialable callback number derived from the IMEI. The IAM
includes the Cell ID (ESRD).

55

52
53
54

56
57
58
59
60

1.1.2 ELID with Timed-Out CAS Push

6-4

ANSI/J-STD-036-B

f. The SMLC returns the MS position estimate to the VMSC. The VMSC may then push the
position estimate to a GMLC to support NCAS Pull of the initial position (see section on
NCAS).

1
2
3
4
5
6
7
8
9
10

1.1.3

ELID with Successful CAS Push with MSC-MSC Handover


This scenario shows delivery of position information (i.e., initial lat/long) with CAS push during call setup
for an emergency call that originated after handoff (e.g., original call is in handoff state and the subscriber
puts the call on hold and initiates an Emergency Services call).

11
12
13

Serving

14

Anchor

15
16
17

MS

BSS

MSC

SMLC

MSC

ESNE

18
19
20

CM Service Request

21
22
23

DTAP CM Service Request

24
25
26

MAP Process Access Signaling [DTAP CM Service Request]

27

28
29

Perform Location Request [QoS]

30

POST

31

32
33

Messages for Specific Positioning Method

34

35
36

Perform Location Response [lat/long]

37
38
39

Call Setup IAM [CgPN=callback#, GDP=ESRD, CGL=lat/long]

40

41
42
43

Figure 6-3:

ELID with Successful CAS Push with MSC-MSC Handover

44
45
46

a. An MS places an existing call on hold and sends a DTAP CM Service Request indicating
a request for an Emergency Services call to the BSC.

47
48
49
50

b. The BSC sends on the DTAP CM Service Request to the serving MSC.
c. The serving MSC forwards the CM service request to the visited (anchor) MSC inside a
MAP Process Access Signaling message.

51
52
53
54
55
56
57
58
59

d. The visited MSC starts a POST timer and sends a request to perform location to the SMLC
associated with the MSs current cell location. This request includes the MSs location
capabilities and currently assigned radio channel type (TCH-FR or TCH-HR), the QoS
required for an emergency call and the current Cell ID.
e. The SMLC initiates a suitable position method. The messages for the specific positioning
method are internal to the GSM/UMTS network and are described in TS 03.71, TS 25.305
and TS 43.059.

60

6-5

1.1.2 ELID with Timed-Out CAS Push

ANSI/J-STD-036-B

f. The SMLC returns the MS position estimate to the VMSC.

1
2

g. The VMSC sets up the call by sending an Initial Address Message (IAM) to the ESNE. The
IAM CgPN contains a dialable callback number (i.e., MSISDN) or a non-dialable callback
number derived from the IMEI. The IAM includes the MS position estimate (latitude/
longitude) and an ESRD that identifies the VMSC and, if NCAS is supported for this ESC,
the GMLC.

3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

1.1.2 ELID with Timed-Out CAS Push

6-6

ANSI/J-STD-036-B

1
2

Emergency Location Information Delivery Using NCAS Pull

2.1

ELID using NCAS Pull

3
4
5

For the ELID NCAS pull scenarios, routing based on the initial lat/long information may be performed by
the VMSC before call setup.

6
7
8
9

2.1.1

Successful ELID NCAS Pull of Initial Position During an Emergency


Call (Initial Position already Available in GMLC)

10
11

This scenario shows delivery of the initial position information (i.e., initial lat/long) with NCAS Pull
when the initial position is already available in the GMLC at the time of the request.

12
13
14
15

Anchor/Serving

16
17
18
19
20

BSS

MS

MSC

SMLC

GMLC

ESME

ESNE

21
22

ESC Invocation

23
24

Call Setup

25

26

Perform Location Request [QoS]

27

28
29

Messages for Specific Positioning Method

30

Perform Location Response. [lat/long]

31

32
33

MAP Subscriber Location Report [MSISDN, IMSI, MSC address, ESRD, ESRK, initial lat/long, CALL ORIGINATION]

34
35

MAP Subscriber Location Report Ack.

36

37

ESPOSREQ [callback# or ESRK, INITIAL]

38

39

esposreq [initial lat/long]

40

41

Call Release

42

43
44

MAP Subscriber Location Report [MSISDN, IMSI, MSC address, ESRD, ESRK, CALL RELEASE]

45
46

MAP Subscriber Location Report Ack.

47
48
49
50
51

Figure 6-4:

Successful ELID NCAS Pull of Initial Position During an Emergency Call (Initial
Position already Available in GMLC)

52
53
54
55
56
57
58

a. The MS invokes an Emergency Services call for details, refer to the scenarios for CAS.
The MS may identify itself using a TMSI, IMSI or IMEI.
b. The MSC extends the call to the ESNE associated with the MSs current cell location
without further delay. The call setup should include at a minimum either a callback number
(dialable or non-dialable) plus the ESRD or an ESRK.

59
60

6-7

2 Emergency Location Information Delivery Using


NCAS Pull

ANSI/J-STD-036-B

c. The MSC sends a request to perform location to the SMLC associated with the MSs
current cell location. This request includes the MSs location capabilities and currently
assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the requested QoS and the
current cell ID and possibly other measurement information.

1
2
3
4
5

d. Messages for individual positioning methods are transferred as described in TS 03.71,


TS 25.305 and TS 43.059.

e. The SMLC returns the position estimate to the MSC.

f. The MSC sends a MAP Subscriber Location Report to the GMLC associated with the
ESNE chosen in step b. The message includes the MSISDN (or non-dialable callback
number), IMSI, MSC address, ESRD, ESRK (if assigned) and the position estimate. The
GMLC stores the initial position information and other relevant information about the E911
call in order to support an NCAS Pull request from the ESME.

10
11
12
13
14

g. The GMLC acknowledges receipt of the location information.

15

h. The ESME requests the initial position of the emergency caller. The request contains either
the callback number and ESRD or the ESRK. The ESME determines which GMLC to
contact based on the ESRK or ESRD provided during call setup (translation from ESRK or
ESRD to GMLC address).

17

i. The GMLC provides the initial position estimate to the ESME.


j. Some time later, the emergency call is released.
k. The MSC sends a MAP Subscriber Location Report to the GMLC associated with the
ESNE chosen in step b. The message includes the MSISDN, IMSI, ESRK (if assigned), an
indication of call release, the MSC address and the ESRD.
l. The GMLC acknowledges receipt of the location related information and may release any
call information previously stored.

16

18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2 Emergency Location Information Delivery Using


NCAS Pull

6-8

ANSI/J-STD-036-B

1
2

2.1.2

Successful ELID NCAS Pull of Initial Position During an Emergency


Call (Initial Position not already Available in GMLC)

3
4

This scenario shows delivery of the initial position information (i.e., initial lat/long) with NCAS Pull
when the initial position is not already available in the GMLC at the time of the request.

5
6
7
8

Anchor/Serving

9
10
11
12

BSS

MS

MSC

SMLC

GMLC

ESME

ESNE

13
14
15

ESC Invocation

16

Call Setup

17

18

Perform Location Request [QoS]

19

20
21
22

Messages for Specific Positioning Method

23

Perform Location Response [lat/long]

24
25

INITREQT

26
27
28

ESPOSREQ [callback# or ESRK, INITIAL]

f
MAP Subscriber Location Report [MSISDN, IMSI, MSC address, ESRD, ESRK, initial lat/long, CALL ORIGINATION]

29

MAP Subscriber Location Report Ack.

30

31

esposreq [initial lat/long]

32

33
34

Call Release

35
36

MAP Subscriber Location Report [MSISDN, IMSI, MSC address, ESRD, ESRK, CALL RELEASE]

37

38

MAP Subscriber Location Report Ack.

39

40
41
42
43

Figure 6-5:

Successful ELID NCAS Pull of Initial Position During an Emergency Call (Initial
Position not already Available in GMLC)

44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

a. The MS invokes an Emergency Services call for details, refer to the scenarios for CAS.
The MS may identify itself using a TMSI, IMSI or IMEI.
b. The MSC extends the call to the ESNE associated with the MSs current cell location
without further delay. The call setup should include at a minimum either a callback number
(dialable or non-dialable) plus the ESRD or an ESRK.
c. The MSC sends a request to perform location to the SMLC associated with the MSs
current cell location. This request includes the MSs location capabilities and currently
assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the requested QoS and the
current cell ID and possibly other measurement information.
d. Messages for individual positioning methods are transferred as described in TS 03.71,
TS 25.305 and TS 43.059.
e. Sometime before step g and possibly after step f, the SMLC returns the position estimate
to the MSC.

60

6-9

2 Emergency Location Information Delivery Using


NCAS Pull

ANSI/J-STD-036-B

f. The ESME requests the initial position of the emergency caller. The request contains either
the callback number and ESRD or the ESRK. The ESME determines which GMLC to
contact based on the ESRK or ESRD provided during call setup (translation from ESRK or
ESRD to GMLC address). If a valid ESRD or ESRK is not provided, the GMLC returns the
error 'Unrecognized Key' to the ESME Otherwise, since the GMLC has no record for the
emergency call, the GMLC starts an INITREQT timer for the pending initial position
request.

1
2
3
4
5
6
7
8

g. The MSC sends a MAP Subscriber Location Report to the GMLC associated with the
ESNE chosen in step b. The message includes the MSISDN (or non-dialable callback
number), IMSI, MSC address, ESRD, ESRK (if assigned) and the position estimate. The
GMLC stops the INITREQT timer and stores the initial position information and other
relevant information about the E911 call in order to support a subsequent NCAS Pull
request from the ESME.
h. The GMLC acknowledges receipt of the location information.

9
10
11
12
13
14
15
16

i. The GMLC then provides the initial position estimate to the ESME.
j. Some time later, the emergency call is released.
k. The MSC sends a MAP Subscriber Location Report to the GMLC associated with the
ESNE chosen in step b. The message includes the MSISDN, IMSI, ESRK (if assigned), an
indication of call release, the MSC address and the ESRD.
l. The GMLC acknowledges receipt of the location related information and may release any
call information previously stored

17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2 Emergency Location Information Delivery Using


NCAS Pull

6-10

ANSI/J-STD-036-B

1
2

2.1.3

Failed ELID NCAS Pull of Initial Position During an Emergency Call


(Initial Position Information not Available in GMLC)

3
4

This scenario shows the handling of an initial position request when initial position information is
not available in the GMLC at the time of the request and the information is not received in the
allotted time (i.e., the initial position request timer expires).

5
6
7
8
9

Anchor/Serving

10
11
12
13

MS

BSS

MSC

SMLC

GMLC

ESME

ESNE

14
15
16

ESC Invocation

17

Call Setup

18

19

Perform Location Request [QoS]

20

21
22

Messages for Specific Positioning Method

23
24

d
ESPOSREQ [callback# or ESRK, INITIAL]

25

26

INITREQT

27

28

Perform Location Response [lat/long]

29

30
31

esposreq [Position Failure]

MAP Subscriber Location Report [MSISDN, IMSI, MSC address, ESRD, ESRK, initial lat/long, CALL ORIGINATION]

32
33
34
35
36

Figure 6-6:

Failed ELID NCAS Pull of Initial Position During an Emergency Call (Initial Position
Information not Available in GMLC)

37
38
39

a. The MS invokes an Emergency Services call for details, refer to the scenarios for CAS.
The MS may identify itself using a TMSI, IMSI or IMEI.

40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

b. The MSC extends the call to the ESNE associated with the MSs current cell location
without further delay. The call setup should include at a minimum either a callback number
(dialable or non-dialable) plus the ESRD or an ESRK.
c. The MSC sends a request to perform location to the SMLC associated with the MSs
current cell location. This request includes the MSs location capabilities and currently
assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the requested QoS and the
current cell ID and possibly other measurement information.
d. Messages for individual positioning methods are transferred as described in TS 03.71,
TS 25.305 and TS 43.059.
e. The ESME requests the initial position of the emergency caller. The request contains either
the callback number and ESRD or the ESRK. The ESME determines which GMLC to
contact based on the ESRK or ESRD provided during call setup (translation from ESRK or
ESRD to GMLC address). If a valid ESRD or ESRK is not provided, the GMLC returns the
error 'Unrecognized Key' to the ESME. Otherwise, since the GMLC has no record for the
emergency call, the GMLC starts an INITREQT timer for the pending initial position
request.

59
60

6-11

2.1.3 Failed ELID NCAS Pull of Initial Position


During an Emergency Call (Initial Position Information not Available in GMLC)

ANSI/J-STD-036-B

f. When the INITREQT timer expires, the GMLC returns the position failure result
'Requested Position Not Available' to the ESME in an Emergency Services Position
Request Result.

1
2
3
4

g. The SMLC may return either a successful initial position estimate or a position failure
indication to the MSC.
h. The MSC forwards any information received in step g to the GMLC for storage and
possible delivery to the ESME via a subsequent NCAS Pull. But in this scenario, the information arrives too late to be sent to the GMLC before step f.

5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.1.3 Failed ELID NCAS Pull of Initial Position


During an Emergency Call (Initial Position Information not Available in GMLC)

6-12

ANSI/J-STD-036-B

1
2

2.1.4

Failed ELID NCAS Pull of Initial Position During an Emergency Call


due to Position Failure

3
4

This scenario shows a request by an ESME for the initial position of an MS engaged in an emergency
services call when positioning fails. It is assumed that the GMLC stores the emergency call information sent by the ESME including the failure to obtain an initial position. This enables the GMLC
to respond to a subsequent NCAS Pull request from the ESME.

5
6
7
8
9
10

Anchor/Serving

11
12
13
14

BSS

MS

MSC

SMLC

GMLC

ESME

ESNE

15
16
17

ESC Invocation

18
19

Call Setup

20

Perform Location Request [QoS]

21

22
23
24

Messages for Specific Positioning Method

25

Perform Location Error [cause]

26
27
28

e
MAP Subscriber Location Report [MSISDN, IMSI, MSC address, ESRD, ESRK, initial lat/long, CALL ORIGINATION]

29

MAP Subscriber Location Report Ack.

30

31

ESPOSREQ [callback# or ESRK, INITIAL]

32

33
34

esposreq [Position Failure]

35
36

Call Release

37
38
39

j
MAP Subscriber Location Report [MSISDN, IMSI, MSC address, ESRD, ESRK, CALL RELEASE]

40

MAP Subscriber Location Report Ack.

41

42
43
44
45

Figure 6-7:

Failed ELID NCAS Pull of Initial Position During an Emergency Call due to Position
Failure

46
47
48
49
50
51
52
53
54
55
56
57
58
59

a. The MS invokes an Emergency Services call for details, refer to the scenarios for CAS.
The MS may identify itself using a TMSI, IMSI or IMEI.
b. The MSC extends the call to the ESNE associated with the MSs current cell location
without further delay. The call setup should include at a minimum either a callback number
(dialable or non-dialable) plus the ESRD or an ESRK.
c. The MSC sends a request to perform location to the SMLC associated with the MSs
current cell location. This request includes the MSs location capabilities and currently
assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the requested QoS and the
current cell ID and possibly other measurement information.
d. Messages for individual positioning methods are transferred as described in TS 03.71,
TS 25.305 and TS 43.059.

60

6-13

2.1.4 Failed ELID NCAS Pull of Initial Position


During an Emergency Call due to Position Failure

ANSI/J-STD-036-B

e. The SMLC returns an indication that the positioning attempt failed and includes the cause.

1
2

f. The visited MSC sends a MAP Subscriber Location report to a GMLC associated with the
ESNE to which the emergency call was sent. This message contains a callback number
(e.g., MSISDN), IMSI, the MSC address, the ESRK (if assigned) and the cell Id (ESRD).
The absence of a position estimate in this message implies failure to perform positioning.
The GMLC stores the emergency call information including the failure to obtain an initial
position.
g. The GMLC acknowledges receipt of the location information.

3
4
5
6
7
8
9
10

h. The ESME requests the initial position of the emergency caller. The request contains either
the callback number and ESRD or the ESRK. The ESME determines which GMLC to
contact based on the ESRK or ESRD provided during call setup (translation from ESRK or
ESRD to GMLC address).

11
12
13
14

i. Because the GMLC has stored information on the initial position failure, the GMLC returns
the position failure result 'Requested Position Not Available' to the ESME in a Emergency
Services Position Request Return Result.

15

j. Some time later, the emergency call is released.

19

k. The MSC sends a MAP Subscriber Location Report to the GMLC associated with the
ESNE chosen in step b. The message includes the MSISDN, IMSI, ESRK (if assigned), an
indication of call release, the MSC address and the ESRD.
l. The GMLC acknowledges receipt of the location related information and may release any
call information previously stored.

16
17
18

20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.1.4 Failed ELID NCAS Pull of Initial Position


During an Emergency Call due to Position Failure

6-14

ANSI/J-STD-036-B

1
2

2.1.5

Successful ELID NCAS Pull of Updated Position during an Emergency


Services Call (Initial Position Information already Available in GMLC)

3
4

This scenario shows how the ESME can retrieve the updated position of an Emergency Services
calling MS by identifying the MS to a GMLC using the callback number (dialable or non-dialable)
or ESRK. The GMLC identifies the VMSC for the emergency services call by the MSC address
previously stored for that call in the GMLC. It is assumed in this scenario that initial position information is already available in the GMLC when the NCAS Pull request is received.

5
6
7
8
9
10
11

Anchor/Serving

12
13
14
15

BSS

MS

MSC

SMLC

GMLC

ESME

ESNE

16
17
18

ESC Invocation

19
20

Call Setup

21
22

Perform Location Request [QoS]

23
24
25

Messages for Specific Positioning Method

26

Perform Location Response [lat/long]

27
28
29

d
e

MAP Subscriber Location Report [MSISDN, IMSI, MSC address, ESRD, ESRK, lat/long, CALL ORIGINATION]

30

MAP Subscriber Location Report Ack.

31

32
33

ESPOSREQ [callback# or ESRK, UPDATED]

34
35

MAP Provide Subscriber Location [IMSI or MSISDN, QoS, UPDATED]

36
37

Perform Location Request [QoS]

38

39
40

Messages for Specific Positioning Method

41

Perform Location Response [updated lat/long]

42

43

MAP Provide Subscriber Location ack. [updated lat/long]

44

45
46

esposreq [updated lat/long]

47
48
49
50
51

Figure 6-8:

Successful ELID NCAS Pull of Updated Position during an Emergency Services Call
(Initial Position Information Already Available in the GMLC)

52
53
54
55
56
57
58

a. The MS invokes an Emergency Services call for details, refer to the scenarios for CAS.
The MS may identify itself using a TMSI, IMSI or IMEI.
b. The MSC extends the call to the ESNE associated with the MSs current cell location. The
call setup should include at a minimum either a callback number (dialable or non-dialable)
plus the ESRD or an ESRK.

59
60

6-15

2.1.5 Successful ELID NCAS Pull of Updated


Position during an Emergency Services Call (Initial
Position Information already Available in GMLC)

ANSI/J-STD-036-B

c. The visited MSC sends a request to perform location to the SMLC associated with the MSs
current cell location. This request includes the MSs location capabilities and currently
assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the QoS required for an
emergency call and the current Cell ID and possibly other measurement information.

1
2
3
4
5

d. The SMLC initiates a suitable position method. The messages for the specific positioning
method are internal to the GSM/UMTS network and are described in TS 03.71, TS 25.305
and TS 43.059.
e. The SMLC returns the MS position estimate to the VMSC.

6
7
8
9
10

f. The MSC sends a MAP Subscriber Location report to a GMLC associated with the
emergency services provider to which the emergency call was sent. This message contains
the MS position estimate, the MSISDN (or non-dialable callback number), IMSI, the cell
Id (ESRD), the MSC address and (if available) ESRK.

11
12
13
14

g. The GMLC acknowledges receipt of the location information sent in step f. The GMLC
then stores the initial position information and other relevant information about the E911
call in order to support a later NCAS pull request from the ESME.

15

h. At some later time (e.g., after delivery of the initial position to the ESME via NCAS Pull),
the ESME requests the updated position of the MS, identified by its callback number
(dialable or non-dialable) or ESRK, in a Position Request Invoke sent to the GMLC. The
ESME determines which GMLC to contact based on the ESRK or ESRD provided during
call setup (translation from ESRK or ESRD to GMLC address).

19

i. The GMLC identifies the VMSC from the call information stored in step g. The GMLC
sends a MAP Provide Subscriber Location message to the VMSC. This message contains
the IMSI or MSISDN (dialable or non-dialable callback number), the LCS QoS information (e.g., accuracy, response time), an indication that an updated emergency call
position is required and an indication of a location request from an emergency services
provider.
j. The visited MSC identifies the emergency call and its associated MS using the IMSI or
MSISDN. The MSC verifies that MS privacy for the updated MS position is overridden by
the emergency services provider. If a location attempt is already ongoing for the same MS,
the VMSC waits for the position result in step l and omits the remainder of this step and
step k. Otherwise, the MSC sends a request to perform location to the SMLC associated
with the MSs current cell location. This request includes the MSs location capabilities and
currently assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the QoS received
from the GMLC and the current Cell ID.
k. The SMLC instigates a suitable position method. The messages for the specific positioning
method are internal to the GSM/UMTS network and are described in TS 03.71, TS 25.305
and TS 43.059.
l. The SMLC returns the updated MS position estimate to the MSC.
m. The MSC returns the updated position estimate for the MS to the GMLC
n. The GMLC returns the updated position estimate to the ESME in an Emergency Services
Position Request Return Result.

16
17
18

20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.1.5 Successful ELID NCAS Pull of Updated


Position during an Emergency Services Call (Initial
Position Information already Available in GMLC)

6-16

ANSI/J-STD-036-B

1
2

2.1.6

Successful ELID NCAS Pull of Updated Position during an Emergency


Services Call (Initial Position Information not already Available in
GMLC)

3
4
5

This scenario shows how the ESME can retrieve the updated position of an Emergency Services
calling MS by identifying the MS to a GMLC using the callback number (dialable or non-dialable)
or ESRK. It is assumed in this scenario that initial position information is not available in the GMLC
at the time that the NCAS Pull request is first received.

6
7
8
9
10
11

Anchor/Serving

12
13
14
15

BSS

MS

MSC

SMLC

GMLC

ESME

ESNE

16
17
18

ESC Invocation

19
20

Call Setup

21
22

Perform Location Request [QoS]

23
24
25

Messages for Specific Positioning Method

26

Perform Location Response [lat/long]

27

28

INITREQT

29

ESPOSREQ [callback# or ESRK, UPDATED]

30
31

MAP Subscriber Location Report [MSISDN, IMSI, MSC address, ESRD, ESRK, lat/long, CALL ORIGINATION]

32
33

MAP Subscriber Location Report Ack.

34
35

MAP Provide Subscriber Location [IMSI or MSISDN, QoS, UPDATED]

36

37

Perform Location Request [QoS]

38

39
40

Messages for Specific Positioning Method

41

Perform Location Response [updated lat/long]

42

43
44

MAP Provide Subscriber Location ack. [updated lat/long]

45
46

esposreq [updated lat/long]

47
48
49
50
51

Figure 6-9:

Successful ELID NCAS Pull of Updated Position during an Emergency Services Call
(Initial Position Information not Already Available in the GMLC)

52
53
54
55
56
57
58

a. The MS invokes an Emergency Services call for details, refer to the scenarios for CAS.
The MS may identify itself using a TMSI, IMSI or IMEI.
b. The MSC extends the call to the ESNE associated with the MSs current cell location. The
call setup should include at a minimum either a callback number (dialable or non-dialable)
plus the ESRD or an ESRK.

59
60

6-17

2.1.6 Successful ELID NCAS Pull of Updated


Position during an Emergency Services Call (Initial
Position Information not already Available in

ANSI/J-STD-036-B

c. The visited MSC sends a request to perform location to the SMLC associated with the MSs
current cell location. This request includes the MSs location capabilities and currently
assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the QoS required for an
emergency call and the current Cell ID and possibly other measurement information.

1
2
3
4
5

d. The SMLC initiates a suitable position method. The messages for the specific positioning
method are internal to the GSM/UMTS network and are described in TS 03.71, TS 25.305
and TS 43.059.
e. Sometime before step g and possibly after step f, the SMLC returns the position estimate
to the MSC.

6
7
8
9
10
11

f. The ESME requests the updated position of the MS, identified by its callback number
(dialable or non-dialable) or ESRK, in a Position Request Invoke sent to the GMLC. The
ESME determines which GMLC to contact based on the ESRK or ESRD provided during
call setup (translation from ESRK or ESRD to GMLC address). If a valid ESRD or ESRK
is not provided, the GMLC returns the error 'Unrecognized Key' to the ESME. Otherwise,
since the GMLC has no record for the emergency call, the GMLC starts an INITREQT
timer for the pending updated position request.

12
13
14
15
16
17
18

g. The MSC sends a MAP Subscriber Location report to the GMLC associated with the
emergency services provider to which the emergency call was sent. This message contains
the MS position estimate, the MSISDN (or non-dialable callback number), IMSI, the cell
Id (ESRD), the MSC address and (if available) ESRK.

19

h. The GMLC acknowledges receipt of the location information sent in step g. The GMLC
stops the INITREQT timer and stores the initial position information and other relevant
information about the E911 call in order to support a subsequent NCAS Pull request from
the ESME. The GMLC may either omit steps i to m and use the initial position estimate as
the updated position in step n or perform steps i to m to obtain a more recent position
estimate.

24

i. The GMLC identifies the VMSC for the pending request for the updated position in step f
from the call information stored in step g. The GMLC sends a MAP Provide Subscriber
Location message to the VMSC. This message contains the IMSI or MSISDN (dialable or
non-dialable callback number), the LCS QoS information (e.g., accuracy, response time),
an indication that an updated emergency call position is required and an indication of a
location request from an emergency services provider.
j. The visited MSC identifies the emergency call and its associated MS using the IMSI or
MSISDN. The MSC verifies that MS privacy for the updated MS position is overridden by
the emergency services provider. If a location attempt is already ongoing for the same MS,
the VMSC waits for the position result in step l and omits the remainder of this step and
step k. Otherwise, the MSC sends a request to perform location to the SMLC associated
with the MSs current cell location. This request includes the MSs location capabilities and
currently assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the QoS received
from the GMLC and the current Cell ID.
k. The SMLC instigates a suitable position method. The messages for the specific positioning
method are internal to the GSM/UMTS network and are described in TS 03.71, TS 25.305
and TS 43.059.
l. The SMLC returns the updated MS position estimate to the MSC.
m. The MSC returns the updated position estimate for the MS to the GMLC
n. The GMLC returns the updated position estimate to the ESME in an Emergency Services
Position Request Return Result.

20
21
22
23

25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.1.6 Successful ELID NCAS Pull of Updated


Position during an Emergency Services Call (Initial
Position Information not already Available in

6-18

ANSI/J-STD-036-B

1
2

2.1.7

Failed ELID NCAS Pull of Updated Position during an Emergency Call


(Initial Position Information not Available in GMLC)

3
4

This scenario shows the handling of a request for the updated position when initial position information is not available in the GMLC at the time of the request and the information is not received
in the allotted time (i.e., the initial position request timer expires).

5
6
7
8
9

Anchor/Serving

10
11
12
13

BSS

MS

MSC

SMLC

GMLC

ESME

ESNE

14
15
16

ESC Invocation

17

Call Setup

18

19

Perform Location Request[QoS]

20

21
22
23

Messages for Specific Positioning Method

24

d
ESPOSREQ [callback# or ESRK, UPDATED]

25

e
INITREQT

26
27

28

Perform Location Response [lat/long]

29

30
31

esposreq [Position Failure]

MAP Subscriber Location Report [MSISDN, IMSI, MSC address, ESRD, ESRK, initial lat/long, CALL ORIGINATION]

32
33
34
35

Figure 6-10:

Failed ELID NCAS Pull of Updated Position during an Emergency Call (Initial
Position Information not Available in GMLC)

36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

a. The MS invokes an Emergency Services call for details, refer to the scenarios for CAS.
The MS may identify itself using a TMSI, IMSI or IMEI.
b. The MSC extends the call to the ESNE associated with the MSs current cell location
without further delay. The call setup should include at a minimum either a callback number
(dialable or non-dialable) plus the ESRD or an ESRK.
c. The MSC sends a request to perform location to the SMLC associated with the MSs
current cell location. This request includes the MSs location capabilities and currently
assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the requested QoS and the
current cell ID and possibly other measurement information.
d. Messages for individual positioning methods are transferred as described in TS 03.71,
TS 25.305 and TS 43.059.
e. The ESME requests the updated position of the emergency caller. The request contains
either the callback number and ESRD or the ESRK. The ESME determines which GMLC
to contact based on the ESRK or ESRD provided during call setup (translation from ESRK
or ESRD to GMLC address). If a valid ESRD or ESRK is not provided, the GMLC returns
the error 'Unrecognized Key' to the ESME Otherwise, since the GMLC has no record for
the emergency call, the GMLC starts an INITREQT timer for the pending initial position
request.

58
59
60

6-19

2.1.7 Failed ELID NCAS Pull of Updated Position


during an Emergency Call (Initial Position Information not Available in GMLC)

ANSI/J-STD-036-B

f. When the INITREQT timer expires, the GMLC returns the position failure result
'Requested Position Not Available' to the ESME in an Emergency Services Position
Request Result.

1
2
3
4

g. The SMLC may return either a successful initial position estimate or a position failure
indication to the MSC.
h. The MSC forwards any information received in step g to the GMLC for storage and
possible delivery to the ESME via a subsequent NCAS Pull. But in this scenario, the information arrives too late to be sent to the GMLC before step f.

5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.1.7 Failed ELID NCAS Pull of Updated Position


during an Emergency Call (Initial Position Information not Available in GMLC)

6-20

ANSI/J-STD-036-B

1
2

2.1.8

Successful ELID NCAS Pull of Updated Position following MSC-MSC


Handover of an Emergency Call

3
4

This scenario shows successful NCAS Pull for the updated position of an MS engaged in an
Emergency Services call following MSC-MSC handover of an emergency call.

5
6
7
8

Serving

Anchor

9
10
11
12

BSS

MS

MSC

SMLC

MSC

GMLC

ESME

ESNE

13
14
15

ESC Invocation

16

Call Setup

17

18
19

Messages specific to obtaining the initial position and transfer to the GMLC and ESME

20

21

Messages specific to MSC-MSC Handover

22
23

d
ESPOSREQ [callback# or ESRK, UPDATED]

24
25

MAP Provide Subscriber Location [IMSI or MSISDN, QoS, UPDATED]

26

27

Perform Location Request [QoS]

28

29
30

Messages for Specific Positioning Method

31

Perform Location Response [updated lat/long]

32

33
34

MAP Provide Subscriber Location Ack. [updated lat/long]

35
36

esposreq [updated lat/long]

37

38
39
40

Figure 6-11:

Successful ELID NCAS Pull of Updated Position following MSC-MSC Handover of an


Emergency Call

41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

a. An initially idle MS invokes an Emergency Services call at the visited MSC for details,
refer to the scenarios for CAS. The MS may identify itself using a TMSI, IMSI or IMEI.
b. The MSC extends the call to the ESNE associated with the MSs current cell location. The
call setup should include at a minimum either a callback number (dialable or non-dialable)
plus an ESRD, that identifies the VMSC and GMLC, or an ESRK.
c. The VMSC initiates procedures to obtain the initial position of the MS and sends the initial
position to the GMLC for storage and possible delivery to the ESME via NCAS Pull.
d. The emergency call is handed over to a new serving MSC (for details, refer to TS 24.008,
TS 48.008 and TS 29.002).
e. The ESME requests the updated position of the MS, identified by the callback number
(dialable or non-dialable) or ESRK, in an Emergency Services Position Request Invoke
sent to the GMLC. The ESME determines which GMLC to contact based on the ESRK or
ESRD provided during call setup (translation from ESRK or ESRD to GMLC address).

58
59
60

6-21

2.1.8 Successful ELID NCAS Pull of Updated


Position following MSC-MSC Handover of an
Emergency Call

ANSI/J-STD-036-B

f. The GMLC identifies the visited MSC from the call information previously stored for the
emergency services call in step c. The GMLC sends a MAP Provide Subscriber Location
message to the VMSC. This message contains the MS subscribers IMSI or MSISDN
(dialable or non-dialable callback number), the LCS QoS information (e.g., accuracy,
response time), an indication that the updated MS position is required and an indication of
a location request from an emergency services provider.

1
2
3
4
5
6
7

g. The visited MSC identifies the target MS using the IMSI or MSISDN. The visited MSC
verifies that MS privacy for the updated MS position is overridden by the emergency
services provider. If a location attempt is already ongoing for the same MS, the VMSC
waits for the position result in step i and omits the remainder of this step and step h.
Otherwise, the visited MSC sends a request to perform location to the SMLC associated
with the MSs current cell location. This request includes the MSs location capabilities and
currently assigned radio channel type (TCH-FR or TCH-HR), the QoS received from the
GMLC and the current Cell ID.
h. The SMLC initiates a suitable position method. The messages for the specific positioning
method are internal to the GSM/UMTS network and are described in TS 03.71, TS 25.305
and TS 43.059.

8
9
10
11
12
13
14
15
16
17
18
19

i. The SMLC returns the updated MS position estimate to the MSC.


j. The MSC returns the updated position estimate for the MS to the GMLC.
k. The GMLC returns the updated position estimate to the ESME in an Emergency Services
Position Request Return Result.

20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.1.8 Successful ELID NCAS Pull of Updated


Position following MSC-MSC Handover of an
Emergency Call

6-22

ANSI/J-STD-036-B

1
2

2.1.9

Failed ELID NCAS Pull of Updated Position during an Emergency Call


This scenario shows a request by an ESME for the updated position of an MS engaged in an
emergency services call when positioning fails.

3
4
5
6

Anchor/Serving

7
8
9
10
11

BSS

MS

MSC

SMLC

GMLC

ESME

ESNE

12
13
14

ESC Invocation

15

Call Setup

16

17
18

Messages specific to obtaining the initial position and transfer to the GMLC and ESME

19

ESPOSREQ [callback# or ESRK, UPDATED]

20

21

MAP Provide Subscriber Location [IMSI or MSISDN, QoS, UPDATED]

22

23
24

Perform Location Request [QoS]

25
26
27

Messages for Specific Positioning Method

28

Perform Location Error [cause]

29

30

MAP Provide Subscriber Location Return Error [Cause]

31

32

esposreq [Position Failure]

33

34
35
36

Figure 6-12:

Failed ELID NCAS Pull of Updated Position during an Emergency Call

37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

a. The MS invokes an Emergency Services call for details, refer to the scenarios for CAS.
The MS may identify itself using a TMSI, IMSI or IMEI.
b. The MSC extends the call to the ESNE associated with the MSs current cell location. The
call setup should include at a minimum either a callback number (dialable or non-dialable)
plus the ESRD or an ESRK.
c. The VMSC initiates procedures to obtain the initial position of the MS and sends the initial
position to the GMLC for storage and possible delivery to the ESME via NCAS Pull.
d. The ESME requests the updated position of the MS, identified by the callback number
(dialable or non-dialable) or ESRK, in a Position Request Invoke sent to the GMLC. The
ESME determines which GMLC to contact based on the ESRK or ESRD provided during
call setup (translation from ESRK or ESRD to GMLC address).
e. The GMLC identifies the visited MSC from the call information previously stored for the
emergency services call in step c. The GMLC sends a MAP Provide Subscriber Location
message to the VMSC. This message contains the MS subscribers IMSI or MSISDN
(dialable or non-dialable callback number), the LCS QoS information (e.g., accuracy,
response time), an indication that the updated MS position is required and an indication of
a location request from an emergency services provider.

57
58
59
60

6-23

2.1.9 Failed ELID NCAS Pull of Updated Position


during an Emergency Call

ANSI/J-STD-036-B

f. The visited MSC identifies the target MS using the IMSI or MSISDN.. The visited MSC
verifies that MS privacy for the updated MS position is overridden by the emergency
services provider. If a location attempt is already ongoing for the same MS, the VMSC
waits for the position result in step h and omits the remainder of this step and step g.
Otherwise, the MSC sends a request to perform location to the SMLC associated with the
MSs current cell location. This request includes the MSs location capabilities and
currently assigned radio channel type (TCH-FR or TCH-HR), the QoS provided by the
GMLC and the current Cell ID.

1
2
3
4
5
6
7
8
9

g. The SMLC initiates a suitable position method. The messages for the specific positioning
method are internal to the GSM/UMTS network and are described in TS 03.71, TS 25.305
and TS 43.059.
h. The SMLC returns an indication that the positioning attempt failed and includes the cause.

10
11
12
13
14

i. The MSC returns a MAP Provide Subscriber Location Return Error to the GMLC with the
cause of the location attempt failure.
j. The GMLC returns the position failure indication 'Requested Position Not Available' to the
ESME in an Emergency Services Position Request Return Result.

15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.1.9 Failed ELID NCAS Pull of Updated Position


during an Emergency Call

6-24

ANSI/J-STD-036-B

1
2

2.1.10

ELID NCAS Pull of Last Known Position during an Emergency Call


(Updated Position Unavailable and Last Known Position Available in
VMSC)

3
4
5

This scenario shows how the ESME can retrieve the last known position of an Emergency Services
calling MS in the event that the updated position is not available but the last known position is
available in the VMSC.

6
7
8
9
10

Anchor/Serving

11
12
13
14

BSS

MS

MSC

SMLC

GMLC

ESME

ESNE

15
16
17

ESC Invocation

18

Call Setup

19

20
21

Perform Location Request [QoS]

22
23
24

Messages for Specific Positioning Method

25

Perform Location Response [lat/long]

26

27
28

Messages for delivery of the initial position to the GMLC and ESME

29

ESPOSREQ [callback# or ESRK, UPDATED/LAST KNOWN]

30

31

MAP Provide Subscriber Location [IMSI or MSISDN, QoS, UPDATED/LAST KNOWN]

32

33
34

Perform Location Request [QoS]

35
36
37

Messages for Specific Positioning Method

38

Perform Location Error [cause]

39

40

MAP Provide Subscriber Location Ack. [last known lat/long]

41

42

esposreq [last known lat/long]

43

44
45
46
47

Figure 6-13:

ELID NCAS Pull of Last Known Position during an Emergency Call (Updated Position
Unavailable and Last Known Position Available in VMSC)

48
49
50
51
52
53
54
55
56
57
58

a. The MS invokes an Emergency Services call for details, refer to the scenarios for CAS.
The MS may identify itself using a TMSI, IMSI or IMEI.
b. The MSC extends the call to the ESNE associated with the MSs current cell location. The
call setup should include at a minimum either a callback number (dialable or non-dialable)
plus the ESRD or an ESRK.
c. The visited MSC sends a request to perform location to the SMLC associated with the MSs
current cell location. This request includes the MSs location capabilities and currently
assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the QoS required for an
emergency call and the current Cell ID.

59
60

6-25

2.1.10 ELID NCAS Pull of Last Known Position


during an Emergency Call (Updated Position
Unavailable and Last Known Position Available in

ANSI/J-STD-036-B

d. The SMLC initiates a suitable position method. The messages for the specific positioning
method are internal to the GSM/UMTS network and are described in TS 03.71, TS 25.305
and TS 43.059.

1
2
3
4

e. The SMLC returns the MS position estimate to the MSC.


f. The VMSC sends the initial position to the GMLC for storage and possible delivery to the
ESME via NCAS Pull.

5
6
7
8

g. The ESME requests the updated or, if not available, the last known position of the MS,
identified by the callback number (dialable or non-dialable) or ESRK, in a Position Request
Invoke sent to the GMLC. The ESME determines which GMLC to contact based on the
ESRD or ESRK provided during call setup (translation from ESRD or ESRK to GMLC
address).

9
10
11
12
13

h. The GMLC identifies the visited MSC from the call information previously stored for the
emergency services call in step f. The GMLC sends a MAP Provide Subscriber Location
message to the VMSC. This message contains the MS subscribers IMSI or MSISDN
(dialable or non-dialable callback number), the LCS QoS information (e.g., accuracy,
response time), an indication that the updated or, if not available, the last known MS
position is required and an indication of a location request from an emergency services
provider.

14

i. The visited MSC identifies the target MS using the IMSI or MSISDN. The visited MSC
verifies that MS privacy for the updated or last known position is overridden by the
Emergency Services provider. If a location attempt is already ongoing for the same MS, the
VMSC waits for the position result in step k and omits the remainder of this step and step
j. Otherwise, the MSC sends a request to perform location to the SMLC associated with the
MSs current cell location. This request includes the MSs location capabilities and
currently assigned radio channel type (TCH-FR or TCH-HR), the QoS provided by the
GMLC and the current Cell ID.

22

j. The SMLC initiates a suitable position method. The messages for the specific positioning
method are internal to the GSM/UMTS network and are described in TS 03.71, TS 25.305
and TS 43.059.
k. The SMLC returns an indication that the positioning attempt failed and includes the cause.
l. Because the GMLC requested the last known position if the updated position was not
available, the MSC returns a MAP Provide Subscriber Location response to the GMLC
containing the last known position estimate stored in the VMSC and the age of this location
estimate.
m. The GMLC returns this position estimate to the ESME.

15
16
17
18
19
20
21

23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.1.10 ELID NCAS Pull of Last Known Position


during an Emergency Call (Updated Position
Unavailable and Last Known Position Available in

6-26

ANSI/J-STD-036-B

1
2

2.1.11

ELID NCAS Pull of Last Known Position during an Emergency Call


(Updated Position Unavailable and Last Known Position not Available
in VMSC)

3
4
5

This scenario shows how the ESME can retrieve the last known position of an Emergency Services
calling MS in the event that the updated position is not available and the last known position is not
available in the VMSC.

6
7
8
9
10

Anchor/Serving

11
12
13
14

BSS

MS

MSC

SMLC

GMLC

ESME

ESNE

15
16
17

ESC Invocation

18

Call Setup

19

20
21

Perform Location Request [QoS]

22
23
24

Messages for Specific Positioning Method

25

Perform Location Response [lat/long]

26

27
28

Messages for delivery of the initial position to the GMLC and ESME

29

ESPOSREQ [callback# or ESRK, UPDATED/LAST KNOWN]

30

31

MAP Provide Subscriber Location [IMSI or MSISDN, QoS, UPDATED/LAST KNOWN]

32

33
34

Perform Location Request [QoS]

35
36
37

Messages for Specific Positioning Method

38

Perform Location Error [cause]

39

40

MAP Provide Subscriber Location Ack. [cause]

41

42

esposreq [Initial lat/long]

43

44
45
46
47

Figure 6-14:

ELID NCAS Pull of Last Known Position during an Emergency Call (Updated Position
Unavailable and Last Known Position not Available in VMSC)

48
49
50
51
52
53
54
55
56
57
58

a. The MS invokes an Emergency Services call for details, refer to the scenarios for CAS.
The MS may identify itself using a TMSI, IMSI or IMEI.
b. The MSC extends the call to the ESNE associated with the MSs current cell location. The
call setup should include at a minimum either a callback number (dialable or non-dialable)
plus the ESRD or an ESRK.
c. Either when the call is originated or some time later, the visited MSC sends a request to
perform location to the SMLC associated with the MSs current cell location. This request
includes the MSs location capabilities and currently assigned radio channel type (SDCCH,
TCH-FR or TCH-HR), the QoS required for an emergency call and the current Cell ID.

59
60

6-27

2.1.11 ELID NCAS Pull of Last Known Position


during an Emergency Call (Updated Position
Unavailable and Last Known Position not Available

ANSI/J-STD-036-B

d. The SMLC initiates a suitable position method. The messages for the specific positioning
method are internal to the GSM/UMTS network and are described in TS 03.71, TS 25.305
and TS 43.059.

1
2
3
4

e. The SMLC returns the MS position estimate to the MSC.


f. The VMSC sends the initial position to the GMLC for storage and possible delivery to the
ESME via NCAS Pull.

5
6
7
8

g. The ESME requests the updated or, if not available, the last known position of the MS,
identified by the callback number (dialable or non-dialable) or ESRK, in a Position Request
Invoke sent to the GMLC. The ESME determines which GMLC to contact based on the
ESRD or ESRK provided during call setup (translation from ESRD or ESRK to GMLC
address).

9
10
11
12
13

h. The GMLC identifies the visited MSC from the call information previously stored for the
emergency services call in step f. The GMLC sends a MAP Provide Subscriber Location
message to the VMSC. This message contains the MS subscribers IMSI or MSISDN
(dialable or non-dialable callback number), the LCS QoS information (e.g., accuracy,
response time), an indication that the updated or, if not available, the last known MS
position is required and an indication of a location request from an emergency services
provider.

14

i. The visited MSC identifies the target MS using the IMSI or MSISDN. The visited MSC
verifies that MS privacy for the updated or last known position is overridden by the
Emergency Services provider. If a location attempt is already ongoing for the same MS, the
VMSC waits for the position result in step k and omits the remainder of this step and step
j. Otherwise, the MSC sends a request to perform location to the SMLC associated with the
MSs current cell location. This request includes the MSs location capabilities and
currently assigned radio channel type (TCH-FR or TCH-HR), the QoS provided by the
GMLC and the current Cell ID.

22

j. The SMLC initiates a suitable position method. The messages for the specific positioning
method are internal to the GSM/UMTS network and are described in TS 03.71, TS 25.305
and TS 43.059.
k. The SMLC returns an indication that the positioning attempt failed and includes the cause.
l. Since the VMSC has neither an updated nor last known position for the MS, the VMSC
returns a MAP Provide Subscriber Location Return Error to the GMLC with the cause of
the location attempt failure.
m. Since the GMLC has the initial position in this scenario, the GMLC returns this initial
position estimate to the ESME. If positioning had instead failed in step d, the GMLC call
record in step f would not contain an initial position estimate: in that case, the GMLC would
return the positioning failure indication 'Requested Position Not Available' to the ESME.

15
16
17
18
19
20
21

23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.1.11 ELID NCAS Pull of Last Known Position


during an Emergency Call (Updated Position
Unavailable and Last Known Position not Available

6-28

ANSI/J-STD-036-B

1
2

2.1.12

Test Message between the ESME and GMLC


This scenario shows the mechanism used by the Emergency Services Network to test the communication between the ESME application and the GMLC application.

3
4
5
6
7
8

GMLC

ESME

10
11

ESPOSREQ[TEST]

12

13
14

esposreq[PositionResult(test)]

15

16
17
18
19

Figure 6-15:

Test Message between the ESME and GMLC

20
21

a. The ESME sends a test request.

22
23
24

b. The GMLC responds immediately with a successful test response. No further processing is
required by the GMLC.

25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

6-29

2.1.12 Test Message between the ESME and


GMLC

ANSI/J-STD-036-B

Routing by GMLC of Emergency Calls, including


Routing based on Geographical Coordinates
When it is desirable to route calls to the PSAP based upon the geographical coordinates of the MS,
the VMSC (based on cell/sector identity) may be configured to allow the GMLC to assign routing
information to the VMSC for the ESC, to enable routing on interim position. For GSM/UMTS
networks, the procedure is described in the TS 23.271 under the sub clause titled:
NI-LR using Location Based Routing applicable to North American Emergency Calls
only.
In addition, the option for Emergency Call routing by the GMLC without geographic coordinates is
described.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

3.1

17

Timers

18

The following timers have been illustrated in the following call flows:

19
20

Timer Name

Entity

Timer Function

21

ECDT

MSC

Limits the length of time that an Emergency Call may be delayed


while waiting for SMLC and/or GMLC interaction to complete.
Parallel is with the ANSI-41 ORT timer.

23

22

24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

3 Routing by GMLC of Emergency Calls, including


Routing based on Geographical Coordinates

6-30

ANSI/J-STD-036-B

1
2

3.2

Successful Routing by GMLC Based on Interim Position

3
4

Anchor/Serving

5
6
7
8

BSS

MS

MSC

SMLC

GMLC

ESME

ESNE

9
10
11

ESC Invocation

12

Perform Location Request [QoS=Low Delay]

13

14
15

Messages for Specific Positioning Method

16

ECDT

17
18
19

Perform Location Response [lat/long]

MAP Subscriber Location Report [CALL ORIGINATION, na-ESRK-Request, lat/long, MSISDN, IMSI, MSC address, cellIdOrSai, ESRD]

20

21

MAP Subscriber Location Report Ack. [GMLC-ESRK or GMLC-ESRD]

22

23

Call Setup using GMLC-ESRK or GMLC-ESRD

24

25

MAP Provide Subscriber Location [IMSI, MSISDN, QoS=Delay Tolerant]

26

27
28

Perform Location Request [QoS=Delay Tolerant]

29
30
31

Messages for Specific Positioning Method

32

ESPOSREQ [callback# or GMLC-ESRK, INITIAL]

33

34

Perform Location Response [lat/long]

35

36

MAP Provide Subscriber Location Ack. [lat/long]

37

38

esposreq [Initial lat/long=PSL ack lat/long]

39

40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

Figure 6-16:

Successful Routing by GMLC Based on Interim Position


a. The MS invokes an Emergency Services call for details, refer to the scenarios for CAS.
The MS may identify itself using a TMSI, IMSI or IMEI.
b. The MSC sends a request to perform location to the SMLC associated with the MSs
current cell location. The QoS is set to indicate a request for a Low Delay position. This
request may include the MSs location capabilities and currently assigned radio channel
type (SDCCH, TCH-FR or TCH-HR), the current cell ID and possibly other measurement
information. The ECDT timer is used to limit the delay to call setup, and is started when
the SMLC request is sent.
c. Messages for individual positioning methods are transferred as described in TS 03.71,
TS 25.305 and TS 43.059.
d. The SMLC returns the position estimate to the MSC.

58
59
60

6-31

3 Routing by GMLC of Emergency Calls, including


Routing based on Geographical Coordinates

ANSI/J-STD-036-B

e. The MSC sends a MAP Subscriber Location Report to the GMLC identified for the call.
The message includes the na-ESRK-Request parameter to indicate that the MSC will
accept an ESRK or ESRD from the GMLC. The message also includes the MSISDN (or
non-dialable callback number), IMSI, MSC address, ESRD (if available), cellIdOrSai
(optional, but required if ESRD is not available), and the position estimate. The GMLC
stores the initial position information and other relevant information about the E911 call in
order to support a subsequent NCAS Pull request from the ESME. If the GMLC is capable
of determining that the position estimate satisfies the accuracy requirements for an
emergency call, then the GMLC may not need to request a higher accuracy position.

1
2
3
4
5
6
7
8
9
10

f. Using the Position Estimate received at step e., the GMLC assigns an ESRK or ESRD for
the call to route to an appropriate ESNE, and returns it to the MSC in the MAP Subscriber
Location Report response. The MSC stops the ECDT timer.
g. The MSC extends the call to the ESNE associated with the ESRK or ESRD received from
the GMLC at step f. without further delay. The call setup should include this (GMLC
allocated) ESRK or ESRD.

11
12
13
14
15
16
17

h. The GMLC sends a MAP Provide Subscriber Location message to the same MSC that sent
the MAP Subscriber Location Report. This message contains the IMSI or MSISDN
(dialable or non-dialable callback number), the LCS QoS information set to indicate a
request for a Delay Tolerant Position, an indication that an updated emergency call position
is required and an indication of a location request from an emergency services provider.

18
19
20
21
22

i. The visited MSC identifies the emergency call and its associated MS using the IMSI or
MSISDN. The MSC verifies that MS privacy for the updated MS position is overridden by
the emergency services provider. If a location attempt is already ongoing for the same MS,
the VMSC waits for the position result and omits the remainder of this step and step k.
Otherwise, the MSC sends a request to perform location to the SMLC associated with the
MSs current cell location. This request includes the MSs location capabilities and
currently assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the QoS received
from the GMLC and the current Cell ID.

23

j. The SMLC initiates a suitable position method. The messages for the specific positioning
method are internal to the GSM/UMTS network and are described in TS 03.71, TS 25.305
and TS 43.059.

32

k. At some point after call setup at step g., the ESME requests the initial position of the
emergency caller. The request contains the ESRK if the GMLC returned an ESRK in step f,
otherwise it contains the callback number. The ESME determines which GMLC to contact
based on the ESRK or ESRD provided during call setup.
l. At some point (possibly before the ESME requests initial position, or after, as shown here),
the SMLC returns the Delay Tolerant position estimate to the MSC.
m. The MSC returns the Delay Tolerant position to the GMLC in a MAP Provide Subscriber
Location response.
n. The GMLC then uses the position received in the MAP Provide Subscriber Location
response to provide the initial position estimate to the ESME.

24
25
26
27
28
29
30
31

33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

3 Routing by GMLC of Emergency Calls, including


Routing based on Geographical Coordinates

6-32

ANSI/J-STD-036-B

1
2

3.3

Interim Position Used as Final Position Due to INITREQT Timeout

3
4

Anchor/Serving

5
6
7
8

BSS

MS

MSC

SMLC

GMLC

ESME

ESNE

9
10
11

ESC Invocation

12

Perform Location Request [QoS=Low Delay]

13

14
15

Messages for Specific Positioning Method

16

ECDT

17
18
19

Perform Location Response [lat/long]

MAP Subscriber Location Report [CALL ORIGINATION, na-ESRK-Request, lat/long, MSISDN, IMSI, MSC address, cellIdOrSai, ESRD]

20

21

MAP Subscriber Location Report Ack. [GMLC-ESRK or GMLC-ESRD]

22

23

Call Setup using GMLC-ESRK or GMLC-ESRD

24

25

MAP Provide Subscriber Location [IMSI, MSISDN, QoS=Delay Tolerant]

26

27
28

Perform Location Request [QoS=Delay Tolerant]

29
30
31

Messages for Specific Positioning Method

32

ESPOSREQ [callback# or GMLC-ESRK, INITIAL]

33

34

INITREQT

35

Timer Expiry

36

esposreq [Initial lat/long=SLR lat/long]

37

38
39
40

Figure 6-17:

Interim Position Used as Final Position Due to INITREQT Timeout

41
42
43
44
45
46
47
48
49
50
51

o. The MS invokes an Emergency Services call for details, refer to the scenarios for CAS.
The MS may identify itself using a TMSI, IMSI or IMEI.
p. The MSC sends a request to perform location to the SMLC associated with the MSs
current cell location. The QoS is set to indicate a request for a Low Delay position. This
request may include the MSs location capabilities and currently assigned radio channel
type (SDCCH, TCH-FR or TCH-HR), the current cell ID and possibly other measurement
information.
q. Messages for individual positioning methods are transferred as described in TS 03.71,
TS 25.305 and TS 43.059.

52
53
54
55
56
57

r. The SMLC returns the position estimate to the MSC.


s. The MSC sends a MAP Subscriber Location Report to the GMLC identified for the call.
The message includes the na-ESRK-Request parameter to indicate that the MSC will
accept an ESRK or ESRD from the GMLC. The message also includes the MSISDN (or
non-dialable callback number), IMSI, MSC address, ESRD (if available), cellIdOrSai

58
59
60

6-33

3.3 Interim Position Used as Final Position Due to


INITREQT Timeout

ANSI/J-STD-036-B

(optional, but required if ESRD is not available), and the position estimate. The GMLC
stores the initial position information and other relevant information about the E911 call in
order to support a subsequent NCAS Pull request from the ESME.

1
2
3
4

t. Using the Position Estimate received at step e., the GMLC assigns an ESRK or ESRD for
the call to route to an appropriate ESNE, and returns it to the MSC in the MAP Subscriber
Location Report response.
u. The MSC extends the call to the ESNE associated with the ESRK or ESRD received from
the GMLC at step f. without further delay. The call setup should include this (GMLC
allocated) ESRK or ESRD.

5
6
7
8
9
10
11

v. The GMLC sends a MAP Provide Subscriber Location message to the same MSC that sent
the MAP Subscriber Location Report. This message contains the IMSI or MSISDN
(dialable or non-dialable callback number), the LCS QoS information set to indicate a
request for a Delay Tolerant Position, an indication that an updated emergency call position
is required and an indication of a location request from an emergency services provider.

12
13
14
15
16

w. The visited MSC identifies the emergency call and its associated MS using the IMSI or
MSISDN. The MSC verifies that MS privacy for the updated MS position is overridden by
the emergency services provider. If a location attempt is already ongoing for the same MS,
the VMSC waits for the position result and omits the remainder of this step and step k.
Otherwise, the MSC sends a request to perform location to the SMLC associated with the
MSs current cell location. This request includes the MSs location capabilities and
currently assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the QoS received
from the GMLC and the current Cell ID.

17

x. The SMLC initiates a suitable position method. The messages for the specific positioning
method are internal to the GSM/UMTS network and are described in TS 03.71, TS 25.305
and TS 43.059.

26

y. At some point after call setup at step g., the ESME requests the initial position of the
emergency caller. The request contains the ESRK, if the GMLC returned an ESRK in step
f; otherwise it contains the cacllback number. The ESME determines which GMLC to
contact based on the ESRK or ESRD provided during call setup. The GMLC receiving the
position request is currently waiting for a position update, and therefore starts the INITEQT
timer.
z. The GMLC INITREQT timer expires waiting for a Delay Tolerant position in the MAP
Provide Subscriber Location Response from the MSC
aa. The GMLC uses the position received in the MAP Subscriber Location Report to provide
the initial position estimate to the ESME.

18
19
20
21
22
23
24
25

27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

3.3 Interim Position Used as Final Position Due to


INITREQT Timeout

6-34

ANSI/J-STD-036-B

1
2

3.4

Interim Position Used as Final Position Due to Phase II


Positioning Failure

3
4
5
6

Anchor/Serving

7
8
9
10
11

BSS

MS

MSC

SMLC

GMLC

ESME

ESNE

12
13

ESC Invocation

14
15

Perform Location Request [QoS=Low Delay]

16
17
18

Messages for Specific Positioning Method

19

ECDT

20

Perform Location Response [lat/long]

21
22

MAP Subscriber Location Report [CALL ORIGINATION, na-ESRK-Request, lat/long, MSISDN, IMSI, MSC address, cellIdOrSai, ESRD]

23

MAP Subscriber Location Report Ack. [GMLC-ESRK or GMLC-ESRD]

24

25
26

Call Setup using GMLC-ESRK or GMLC-ESRD

27
28

MAP Provide Subscriber Location [IMSI, MSISDN, QoS=Delay Tolerant]

29

30

Perform Location Request [QoS=Delay Tolerant]

31

32
33

Messages for Specific Positioning Method

34

ESPOSREQ [callback# or GMLC-ESRK, INITIAL]

35

36
37

Perform Location Response [Posn Failure]

38
39

MAP Provide Subscriber Location ack [Position Failure]

40
41

esposreq [Initial lat/long=SLR lat/long]

42

43
44
45

Figure 6-18:

Interim Position Used as Final Position Due to Phase II Positioning Failure

46
47
48

a. The MS invokes an Emergency Services call for details, refer to the scenarios for CAS.
The MS may identify itself using a TMSI, IMSI or IMEI.

49
50
51
52
53
54
55
56
57
58

b. The MSC sends a request to perform location to the SMLC associated with the MSs
current cell location. The QoS is set to indicate a request for a Low Delay position. This
request may include the MSs location capabilities and currently assigned radio channel
type (SDCCH, TCH-FR or TCH-HR), the current cell ID and possibly other measurement
information.
c. Messages for individual positioning methods are transferred as described in TS 03.71,
TS 25.305 and TS 43.059.
d. The SMLC returns the position estimate to the MSC.

59
60

6-35

3.4 Interim Position Used as Final Position Due to


Phase II Positioning Failure

ANSI/J-STD-036-B

e. The MSC sends a MAP Subscriber Location Report to the GMLC identified for the call.
The message includes the na-ESRK-Request parameter to indicate that the MSC will
accept an ESRK or ESRD from the GMLC. The message also includes the MSISDN (or
non-dialable callback number), IMSI, MSC address, ESRD (if available), cellIdOrSai
(optional, but required if ESRD is not available), and the position estimate. The GMLC
stores the initial position information and other relevant information about the E911 call in
order to support a subsequent NCAS Pull request from the ESME.

1
2
3
4
5
6
7
8

f. Using the Position Estimate received at step e., the GMLC assigns an ESRK or ESRD for
the call to route to an appropriate ESNE, and returns it to the MSC in the MAP Subscriber
Location Report response.
g. The MSC extends the call to the ESNE associated with the ESRK or ESRD received from
the GMLC at step f. without further delay. The call setup should include this (GMLC
allocated) ESRK or ESRD .

9
10
11
12
13
14
15

h. The GMLC sends a MAP Provide Subscriber Location message to the same MSC that sent
the MAP Subscriber Location Report. This message contains the IMSI or MSISDN
(dialable or non-dialable callback number), the LCS QoS information set to indicate a
request for a Delay Tolerant Position, an indication that an updated emergency call position
is required and an indication of a location request from an emergency services provider.

16
17
18
19
20

i. The visited MSC identifies the emergency call and its associated MS using the IMSI or
MSISDN. The MSC verifies that MS privacy for the updated MS position is overridden by
the emergency services provider. If a location attempt is already ongoing for the same MS,
the VMSC waits for the position result and omits the remainder of this step and step k.
Otherwise, the MSC sends a request to perform location to the SMLC associated with the
MSs current cell location. This request includes the MSs location capabilities and
currently assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the QoS received
from the GMLC and the current Cell ID.

21

j. The SMLC initiates a suitable position method. The messages for the specific positioning
method are internal to the GSM/UMTS network and are described in TS 03.71, TS 25.305
and TS 43.059.

30

k. At some point after call setup at step g., the ESME requests the initial position of the
emergency caller. The request contains the ESRK if the GMLC returned an ESRK in step
f; otherwise, it contains the callback number. The ESME determines which GMLC to
contact based on the ESRK or ESRD provided during call setup.
l. The SMLC fails to generate a Delay Tolerant position, and indicates the failure back to the
MSC
m. The Position Failure is reported to the GMLC by the MSC in the MAP Provide Subscriber
Location message response
n. The GMLC uses the position received in the MAP Subscriber Location Report to provide
the initial position estimate to the ESME.

22
23
24
25
26
27
28
29

31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

3.4 Interim Position Used as Final Position Due to


Phase II Positioning Failure

6-36

ANSI/J-STD-036-B

1
2

3.5

GMLC Fallback to Routing on Cell on Interim Positioning Failure

3
4

Anchor/Serving

5
6
7
8

BSS

MS

MSC

SMLC

GMLC

ESME

ESNE

9
10
11

ESC Invocation

12

Perform Location Request [QoS=Low Delay]

13

14
15

Messages for Specific Positioning Method

16
17

Perform Location Response [Posn Failure]

18
19

MAP Subscriber Location Report [CALL ORIGINATION, na-ESRK-Request, MSISDN, IMSI, MSC address, cellIdOrSai, ESRD]

20

21

MAP Subscriber Location Report Ack. [GMLC-ESRK or GMLC-ESRD]

22

23

Call Setup using GMLC-ESRK or GMLC-ESRD

24

25

MAP Provide Subscriber Location [IMSI, MSISDN, QoS=Delay Tolerant]

26

27
28

Perform Location Request [QoS=Delay Tolerant]

29
30
31

Messages for Specific Positioning Method

32

ESPOSREQ [callback# or GMLC-ESRK, INITIAL]

33

34

Perform Location Response [lat/long]

35

36

MAP Provide Subscriber Location ack [lat/long]

37

38

esposreq [Initial lat/long=PSL ack lat/long]

39

40
41
42
43

Figure 6-19:

GMLC Fallback to Routing on Cell on Interim Positioning Failure

44
45
46

a. The MS invokes an Emergency Services call for details, refer to the scenarios for CAS.
The MS may identify itself using a TMSI, IMSI or IMEI.

47
48
49
50
51
52
53
54

b. The MSC sends a request to perform location to the SMLC associated with the MSs
current cell location. The QoS is set to indicate a request for a Low Delay position. This
request may include the MSs location capabilities and currently assigned radio channel
type (SDCCH, TCH-FR or TCH-HR), the current cell ID and possibly other measurement
information.
c. Messages for individual positioning methods are transferred as described in TS 03.71,
TS 25.305 and TS 43.059.

55
56
57

d. The SMLC fails to generate a Low Delay position, and indicates the failure back to the
MSC.

58
59
60

6-37

3.5 GMLC Fallback to Routing on Cell on Interim


Positioning Failure

ANSI/J-STD-036-B

e. The MSC sends a MAP Subscriber Location Report to the GMLC identified for the call.
The message includes the na-ESRK-Request parameter to indicate that the MSC will
accept an ESRK or ESRD from the GMLC. The message also includes the MSISDN (or
non-dialable callback number), IMSI, MSC address, ESRD (if available), and cellIdOrSai
(optional, but required if ESRD is not available). The GMLC stores the relevant information about the E911 call in order to support a subsequent NCAS Pull request from the
ESME.

1
2
3
4
5
6
7
8

f. Using the cell based data received at step e (e.g., cellIdOrSai, or ESRD), the GMLC assigns
an ESRK or ESRD for the call to route to an appropriate ESNE, and returns it to the MSC
in the MAP Subscriber Location Report response.
g. The MSC extends the call to the ESNE associated with the ESRK or ESRD received from
the GMLC at step f. without further delay. The call setup should include this (GMLC
allocated) ESRK or ESRD.

9
10
11
12
13
14
15

h. The GMLC sends a MAP Provide Subscriber Location message to the same MSC that sent
the MAP Subscriber Location Report. This message contains the IMSI or MSISDN
(dialable or non-dialable callback number), the LCS QoS information set to indicate a
request for a Delay Tolerant Position, an indication that an updated emergency call position
is required and an indication of a location request from an emergency services provider.

16
17
18
19
20

i. The visited MSC identifies the emergency call and its associated MS using the IMSI or
MSISDN. The MSC verifies that MS privacy for the updated MS position is overridden by
the emergency services provider. If a location attempt is already ongoing for the same MS,
the VMSC waits for the position result and omits the remainder of this step and step k.
Otherwise, the MSC sends a request to perform location to the SMLC associated with the
MSs current cell location. This request includes the MSs location capabilities and
currently assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the QoS received
from the GMLC and the current Cell ID.

21

j. The SMLC initiates a suitable position method. The messages for the specific positioning
method are internal to the GSM/UMTS network and are described in TS 03.71, TS 25.305
and TS 43.059.

30

k. At some point after call setup at step g., the ESME requests the initial position of the
emergency caller. The request contains the ESRK if the GMLC returned an ESRK in step f,
otherwise it contains the callback number. The ESME determines which GMLC to contact
based on the ESRK or ESRD provided during call setup.
l. At some point (possibly before the ESME requests initial position, or after, as shown here),
the SMLC returns the Delay Tolerant position estimate to the MSC.
m. The MSC returns the Delay Tolerant position to the GMLC in a MAP Provide Subscriber
Location response.
n. The GMLC then uses the position received in the MAP Provide Subscriber Location
response to provide the initial position estimate to the ESME.

22
23
24
25
26
27
28
29

31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

3.5 GMLC Fallback to Routing on Cell on Interim


Positioning Failure

6-38

ANSI/J-STD-036-B

1
2

3.6

GMLC Routing on Cell without Interim Positioning

3
4

Anchor/Serving

5
6
7
8

BSS

MS

MSC

SMLC

GMLC

ESME

ESNE

9
10
11

ESC Invocation

12
13

MAP Subscriber Location Report [CALL ORIGINATION, na-ESRK-Request, MSISDN, IMSI, MSC address, cellIdOrSai, ESRD]

14

MAP Subscriber Location Report Ack. [GMLC-ESRK]

15

16
17

Call Setup using GMLC-ESRK

18
19

MAP Provide Subscriber Location [IMSI, MSISDN, QoS=Delay Tolerant]

20

21

Perform Location Request [QoS=Delay Tolerant]

22

23
24

Messages for Specific Positioning Method

25

ESPOSREQ [callback# or GMLC-ESRK, INITIAL]

26

27
28

Perform Location Response [lat/long]

29
30

MAP Provide Subscriber Location ack [lat/long]

31

32

esposreq [Initial lat/long=PSL ack lat/long]

33

34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

Figure 6-20:

GMLC Routing on Cell without Interim Positioning


a. The MS invokes an Emergency Services call for details, refer to the scenarios for CAS.
The MS may identify itself using a TMSI, IMSI or IMEI.
b. The MSC is configured to send a MAP Subscriber Location Report to the GMLC identified
for the call without an Interim Position attempt. The message includes the na-ESRKRequest parameter to indicate that the MSC will accept an ESRK from the GMLC. The
message also includes the MSISDN (or non-dialable callback number), IMSI, MSC
address, ESRD, and cellIdOrSai (optional, but required if ESRD is not available). The
GMLC stores the relevant information about the E911 call in order to support a subsequent
NCAS Pull request from the ESME.
c. Using the cell based data received at step e (e.g., cellIdOrSai, or ESRD), the GMLC assigns
an ESRK for the call to route to an appropriate ESNE, and returns it to the MSC in the MAP
Subscriber Location Report response.
d. The MSC extends the call to the ESNE associated with the ESRK received from the GMLC
at step c without further delay. The call setup should include this (GMLC allocated) ESRK.
e. The GMLC sends a MAP Provide Subscriber Location message to the same MSC that sent
the MAP Subscriber Location Report. This message contains the IMSI or MSISDN
(dialable or non-dialable callback number), the LCS QoS information set to indicate a
request for a Delay Tolerant Position, an indication that an updated emergency call position
is required and an indication of a location request from an emergency services provider.

59
60

6-39

3.6 GMLC Routing on Cell without Interim


Positioning

ANSI/J-STD-036-B

f. The visited MSC identifies the emergency call and its associated MS using the IMSI or
MSISDN. The MSC verifies that MS privacy for the updated MS position is overridden by
the emergency services provider. If a location attempt is already ongoing for the same MS,
the VMSC waits for the position result and omits the remainder of this step and step k.
Otherwise, the MSC sends a request to perform location to the SMLC associated with the
MSs current cell location. This request includes the MSs location capabilities and
currently assigned radio channel type (SDCCH, TCH-FR or TCH-HR), the QoS received
from the GMLC and the current Cell ID.

1
2
3
4
5
6
7
8
9

g. The SMLC initiates a suitable position method. The messages for the specific positioning
method are internal to the GSM/UMTS network and are described in TS 03.71, TS 25.305
and TS 43.059.
h. At some point after call setup at step g., the ESME requests the initial position of the
emergency caller. The request contains the ESRK. The ESME determines which GMLC to
contact based on the ESRK provided during call setup.

10
11
12
13
14
15
16

i. At some point (possibly before the ESME requests initial position, or after, as shown here),
the SMLC returns the Delay Tolerant position estimate to the MSC.
j. The MSC returns the Delay Tolerant position to the GMLC in a MAP Provide Subscriber
Location response.
k. The GMLC then uses the position received in the MAP Provide Subscriber Location
response to provide the initial position estimate to the ESME.

17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

3.6 GMLC Routing on Cell without Interim


Positioning

6-40

ANSI/J-STD-036-B

1
2

3.7

MSC times out waiting for SMLC response prior to call setup

The following scenario applies when the MSC uses a single ECDT timer to limit the duration of both the
interim position request and the request for an ESRK or ESRD from the GMLC. If the MSC uses a separate
smaller timer than the ECDT timer to limit the duration of the interim position request, then if this timer
expires before an interim position estimate is obtained, the MSC may still request an ESRK or ESRD from
the GMLC using the ESRD or cell ID or SAI similar to that described in section 3.6.

4
5
6
7
8
9
10

Anchor/Serving

11
12
13
14

BSS

MS

MSC

SMLC

GMLC

ESME

ESNE

15
16
17

ESC Invocation

18

Perform Location Request [QoS=Low Delay]

19
20
21
22

ECDT
Messages for Specific Positioning Method

23
24

Timer Expiry
Call Setup [ESRD, Callback#]

25
26

27
28

MAP Subscriber Location Report [CALL ORIGINATION, MSISDN, IMSI, MSC address, cellIdOrSai, ESRD]

29

MAP Subscriber Location Report Ack. [ ]

30

31

Perform Location Response [lat/long]

32

33
34

Figure 6-21:

MSC times out waiting for SMLC response prior to call setup

35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

a. The MS invokes an Emergency Services call for details, refer to the scenarios for CAS.
The MS may identify itself using a TMSI, IMSI or IMEI.
b. The MSC sends a request to perform location to the SMLC associated with the MSs
current cell location. The QoS is set to indicate a request for a Low Delay position. This
request may include the MSs location capabilities and currently assigned radio channel
type (SDCCH, TCH-FR or TCH-HR), the current cell ID and possibly other measurement
information. The ECDT timer is used to limit the delay to call setup, and is started when
the SMLC request is sent.
c. Messages for individual positioning methods are transferred as described in TS 03.71,
TS 25.305 and TS 43.059.
d. The MSC ECDT timer expires while waiting for an SMLC response.
e. To prevent additional delay to call setup, the call is routed by the MSC toward the PSAP
selected by the ESRD without reference to the GMLC. See normative Annex D for call
setup signaling formats.
f. The MSC sends a MAP Subscriber Location Report to the GMLC identified for the call.
The call has already been routed, and therefore no na-ESRK-Request parameter is present.
No position estimate is available for the message at this time.
g. The GMLC acknowledges receipt of the MAP Subscriber Location Report message.
h. An SMLC response after the call has been routed is discarded by the MSC.

60

6-41

3.7 MSC times out waiting for SMLC response


prior to call setup

ANSI/J-STD-036-B

3.8

MSC times out waiting for GMLC response prior to call setup

1
2
3
4

Anchor/Serving

5
6
7

BSS

MS

MSC

SMLC

GMLC

ESME

ESNE

8
9
10

ESC Invocation

a
Perform Location Request [QoS=Low Delay]

12
13

ECDT

11

14
15

Messages for Specific Positioning Method

16
17

Perform Location Response [lat/long]

d
MAP Subscriber Location Report [CALL ORIGINATION, na-ESRK-Request, lat/long, MSISDN, IMSI, MSC address, cellIdOrSai, ESRD]

18
19
20
21

Failure
Timer Expiry

Call Setup [ESRD, Callback#]

22
23
24

25
26

Figure 6-22:

MSC times out waiting for GMLC response prior to call setup

27
28

a. The MS invokes an Emergency Services call for details, refer to the scenarios for CAS.
The MS may identify itself using a TMSI, IMSI or IMEI.

29

b. The MSC sends a request to perform location to the SMLC associated with the MSs
current cell location. The QoS is set to indicate a request for a Low Delay position. This
request may include the MSs location capabilities and currently assigned radio channel
type (SDCCH, TCH-FR or TCH-HR), the current cell ID and possibly other measurement
information. The ECDT timer is used to limit the delay to call setup, and is started when
the SMLC request is sent.

32

30
31

33
34
35
36
37
38

c. Messages for individual positioning methods are transferred as described in TS 03.71,


TS 25.305 and TS 43.059.

39

d. The SMLC returns the position estimate to the MSC.

41

40

42

e. The MSC sends a MAP Subscriber Location Report to the GMLC identified for the call.
The message includes the na-ESRK-Request parameter to indicate that the MSC will
accept an ESRK or ESRD from the GMLC. The message also includes the MSISDN (or
non-dialable callback number), IMSI, MSC address, ESRD (if available), cellIdOrSai
(optional, but required if ESRD is not available), and the position estimate.

43
44
45
46
47

f. An error occurs in the communication with the GMLC, or in the GMLC processing.

48

g. The MSC ECDT expires while waiting for a GMLC response. The call is routed toward the
PSAP selected by the ESRD if available or, if not available, by some other number
associated with the PSAP. See normative Annex D for call setup signaling formats.

50

49

51
52
53
54
55
56
57
58
59
60

3.8 MSC times out waiting for GMLC response


prior to call setup

6-42

ANSI/J-STD-036-B

1
2

3.9

MSC Fallback when GMLC unable to allocate ESRK

3
4

Anchor/Serving

5
6
7
8

BSS

MS

MSC

SMLC

GMLC

ESME

ESNE

9
10
11

ESC Invocation

12

Perform Location Request [QoS=Low Delay]

13

14
15

Messages for Specific Positioning Method

16
17

Perform Location Response [lat/long]

18
19

MAP Subscriber Location Report [CALL ORIGINATION, na-ESRK-Request, lat/long, MSISDN, IMSI, MSC address, cellIdOrSai, ESRD]

20

21

MAP Subscriber Location Report Ack. [ ]

22

23

Call Setup [ESRD, Callback#]

24

25
26
27

Figure 6-23:

MSC Fallback when GMLC unable to allocate ESRK

28
29
30
31
32
33
34
35
36

a. The MS invokes an Emergency Services call for details, refer to the scenarios for CAS.
The MS may identify itself using a TMSI, IMSI or IMEI.
b. The MSC sends a request to perform location to the SMLC associated with the MSs
current cell location. The QoS is set to indicate a request for a Low Delay position. This
request may include the MSs location capabilities and currently assigned radio channel
type (SDCCH, TCH-FR or TCH-HR), the current cell ID and possibly other measurement
information.

37
38
39
40

c. Messages for individual positioning methods are transferred as described in TS 03.71,


TS 25.305 and TS 43.059.
d. The SMLC returns the position estimate to the MSC.

41
42
43
44
45
46
47
48
49
50
51
52
53

e. The MSC sends a MAP Subscriber Location Report to the GMLC identified for the call.
The message includes the na-ESRK-Request parameter to indicate that the MSC will
accept an ESRK from the GMLC. The message also includes the MSISDN (or non-dialable
callback number), IMSI, MSC address, ESRD, cellIdOrSai (optional, but required if ESRD
is not available), and the position estimate. The GMLC stores the initial position information and other relevant information about the E911 call in order to support a subsequent
NCAS Pull request from the ESME.
f. If the GMLC cannot assign an ESRK for the call, no ESRK is indicated in the MAP
Subscriber Location Report acknowledgement.
g. The call is be routed toward the PSAP selected by the ESRD. See normative Annex D for
call setup signaling formats.

54
55
56
57
58
59
60

6-43

3.9 MSC Fallback when GMLC unable to allocate


ESRK

ANSI/J-STD-036-B

Chapter 7: Stage 3 Implementation


Perspective: Emergency Services
Protocol (ESP)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

18

Introduction

19
20

This section species the Abstract Syntax for the Emergency Services Protocol using the Abstract Syntax
Notation One (ASN.1), dened in ITU-T Recommendations X.680 (1994) and X.680 Amendment 1 (1995)
and the OPERATION and ERROR external MACROs, dened in ANSI T1.114-1996.
The encoding rules applicable to the defined Abstract Syntax are the ASN.1 Basic Encoding Rules defined
in ITU-T Recommendation X.690 (1994). Implicit tagging is used for all context specific parameters.
The Emergency Services Protocol (ESP) supports the following interfaces via the EmergencyServicesPositionRequest:

21
22
23
24
25
26
27
28
29

a. Figure 3-1 Network Reference Model interface: MPC to ESME (Reference Point E2).
b. Figure 5-1 Network Reference Model for GSM/UMTS interface: GMLC to ESME
(Reference Point E2).
Parameter contents imported from other specifications (e.g., T1.114 and ANSI-41) are imported without
length and identifier octets.

30
31
32
33
34
35
36
37

1.1

Transaction Portion

38

The Emergency Services Protocol employs the Query with Permission and Response TCAP Package Types
defined in ANSI T1.114-1996.

40

39

41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

1 Introduction

7-1

ANSI/J-STD-036-B

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

1.2

Component Portion
The Emergency Services Protocol employs the Invoke (Last), Return Result (Last), Return Error and Reject
TCAP Component Types defined in ANSI T1.114-1996 with the following exceptions and limitations:
a. The Operation Code Identifier is coded as Private TCAP.
b. The Operation Code is partitioned into an Operation Family followed by a Specifier
associated with each Operation Family member. For the Emergency Services Protocol, the
Operation Family is coded as decimal 1. Bit H of the Operation Family is always coded
as 0.
c. A TCAP INVOKE component shall contain a Component ID Length greater than zero.
d. A TCAP RETURN RESULT component shall only be transmitted in response to an
INVOKE Component.
e. A TCAP RETURN ERROR component shall only be sent in response to an INVOKE
component, not a RETURN RESULT component.
f. The Error Code Identifier is coded as Private TCAP.
g. If a problem is detected by TCAP (i.e., the received message does not conform to ANSI
T1.114.3), a TCAP REJECT component with one of the following Problem Specifiers shall
be sent:
i. Problem Type General: all defined Problem Specifiers are applicable.
ii. Problem Type Transaction Portion: all defined Problem Specifiers are applicable.

26
27
28
29
30
31

h. If a problem is detected by the Emergency Services TC-user (i.e., the received message
does not conform to the Emergency Services Protocol), a TCAP REJECT component with
one of the following TCAP Problem Specifiers shall be sent:
i. Problem Type INVOKE: Duplicate Invoke ID, Unrecognized Operation Code or
Incorrect Parameter.

32
33
34

i. The Parameter Set Identifier is coded per ANSI T1.114 (national, constructor with
Identifier code 18).

35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

7-2

1.2 Component Portion

ANSI/J-STD-036-B

Emergency Services Protocol Abstract Syntax

The Emergency Services Protocol is composed of one ASN.1 module dealing with operations, errors and data types.

1
2
3
4
5

EmergencyServicesProtocol { iso (1) memberbody (2) usa (840) emergencyServicesProtocol (1) }


DEFINITIONS

6
7
8
9

::=

10
11
12

BEGIN

13
14
15

EXPORTS

16

Digits,
GeographicPosition,
IMSI,
MobileIdentificationNumber,
PositionInformation,
PositionRequestType;

17
18
19
20
21
22
23
24
25

IMPORTS
ERROR,
OPERATION
FROM TCAPPackage { iso (1) memberbody (2) usa (840) T1.114 (10013) } ;

26
27
28
29
30
31

-- Operations Definitions

32
33
34

-- The Emergency Services Position Request operation is used to request the initial,
-- updated or last known position of an MS. The default value of the Emergency Services Position Request
-- Timer (ESPRT) is beyond the scope of this Standard.
EmergencyServicesPositionRequest ::= OPERATION -- Timer ESPRT
PARAMETER
esprArg
EmergencyServicesPositionRequestArgument
RESULT
esprRes
EmergencyServicesPositionRequestResponse
ERRORS {
SystemFailure,
UnauthorizedRequest,
UnexpectedDataValue,
UnrecognizedKey }

35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

-- Emergency Services Position Request operation code family and specifier


emergencyServicesPositionRequest EmergencyServicesPositionRequest ::= localValue {1, 1}

52
53
54
55
56
57
58
59
60

2 Emergency Services Protocol Abstract Syntax

7-3

ANSI/J-STD-036-B

1
2
3
4

-- Emergency Services errors and error codes


SystemFailure ::= ERROR
systemFailure
SystemFailure ::= localValue 1

5
6
7
8

UnauthorizedRequest ::= ERROR


unauthorizedRequest
UnauthorizedRequest ::= localValue 2

9
10
11

UnexpectedDataValue ::= ERROR


unexpectedDataValue
UnexpectedDataValue ::= localValue 3

12
13
14
15

UnrecognizedKey ::= ERROR


unrecognizedKey
UnrecognizedKey ::= localValue 4

16
17
18
19
20
21
22
23
24

-- Emergency Services data types


EmergencyServicesPositionRequestArgument ::= SEQUENCE {
esprSysId
[0] ESMEIdentification,
-- Identifies the system initiating the request (i.e., ESME).
esprReqType

25
26

-- for a heartbeat or keep-alive message, or test digits EmergencyServicesRoutingKey for a test

27
28

-- position request.

29
30

esprKey

31
32
33
34
35
36
37
38
39

[1] PositionRequestType,
-- If set to test , then esprKey should be set to a zero-length EmergencyServicesRoutingKey

CHOICE {
[2] EmergencyServicesRoutingKey,
SEQUENCE {
[3] CallbackNumber,
[4] EmergencyServicesRoutingDigits
}
}

...
}

40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

EmergencyServicesPositionRequestResponse ::= SEQUENCE {


esprPosRes
[0] PositionResult,
esprPosInfo
[1] PositionInformation OPTIONAL,
-- Shall be present as indicated in the esprPosRes parameter.
esprCallback
[2] CallbackNumber OPTIONAL,
-- Shall be provided, if available, if the esprKey was the ESRK.
esprESRD
[3] EmergencyServicesRoutingDigits OPTIONAL,
-- Shall be provided, if available, if the initial position was requested
esprESRKTime
[4] GeneralizedTime OPTIONAL,
-- Time of ESRK assignment. Shall be provided, if available, when the
-- the esprKey was the ESRK.
esprMIN
[5] MobileIdenticationNumber OPTIONAL,
esprIMSI
[6] IMSI OPTIONAL,
esprMCallStatus
[7] MobileCallStatus OPTIONAL,
esprCompID
[8] CompanyID OPTIONAL,
-- In the US and Canada it shall be provided when available.

60

7-4

2 Emergency Services Protocol Abstract Syntax

ANSI/J-STD-036-B

esprLocDesc

[14] LocationDescription OPTIONAL ,

1
2
3
4
5
6

-- Emergency Services Parameter Definitions

7
8

-- The MDN, MSISDN or non-dialable callback number that identifies the emergency services caller.
CallbackNumber ::= Digits
-- Type of digits = Calling Party Number
-- Nature of number = National/International, no presentation restrictions

9
10
11
12
13
14

-- Encoding = BCD

15

-- Numbering Plan = Telephony Numbering Plan (E.164)

16
17
18

-- The CompanyID parameter carries a unique identifier for the wireless service
-- provider. In the US and Canada the identifiers are managed and assigned by NENA.
-- Restricted to characters in PrintableString type (except the space character)
CompanyID ::= VisibleString (SIZE (1..15))

19
20
21
22
23
24
25

-- The Digits parameter is a generic parameter that carries digits and provides additional
-- information related to those digits (i.e., type of digits, nature of number, and numbering plan).
Digits ::= OCTET STRING -- See T1.114.5 Digits parameter for encoding

26
27
28
29
30

-- The EmergencyServicesRoutingDigits parameter uniquely identifies a base station, cell site or sector.
EmergencyServicesRoutingDigits ::= Digits
-- Type of digits = Routing Number
-- Nature of number = National/International, no presentation restrictions

31
32
33
34
35
36

-- Encoding = BCD

37

-- Numbering Plan = Telephony Numbering Plan (E.164)

38
39
40

-- The EmergencyServicesRoutingKey parameter uniquely identifies an ongoing Emergency Services Call.


EmergencyServicesRoutingKey ::= Digits
-- Type of digits = Routing Number
-- Nature of number = National/International, no presentation restrictions

41
42
43
44
45
46

-- Encoding = BCD

47

-- Numbering Plan = Telephony Numbering Plan (E.164)

48
49
50

-- The ESMEIdentification parameter uniquely identifies the ESME sending a particular message.
-- In the US and Canada the identifiers are managed and assigned by NENA
-- Restricted to characters in PrintableString type (except the space character)
ESMEIdentication ::= VisibleString (SIZE (1..15))

51
52
53
54
55
56
57
58
59
60

2 Emergency Services Protocol Abstract Syntax

7-5

ANSI/J-STD-036-B

-- GeneralizedTime is a UNIVERSAL type defined in X.680. This is always specified in UTC.

2
3
4
5
6
7
8
9

-- The GeographicPosition parameter specifies a location in latitude and longitude


-- coordinates, reference WGS-84 data.
GeographicPosition ::= OCTET STRING -- See CallingGeodeticLocation in T1.628 for encoding. At a minimum, in
order to provide the required elds, the Type of shape eld values recommended to be supported are Ellipsoid point
and Ellipsoid point with uncertainty.

10
11
12
13
14
15
16
17
18

IMSI ::= Digits


-- The overall number of digits in IMSI shall not exceed 15 digits.
-- Type of digits = Not used
-- Nature of number = International, no presentation restrictions
-- Encoding = BCD
-- Numbering Plan = Land Mobile Numbering Plan (E.212)

19
20
21
22
23
24
25

-- The LocationDescription parameter carries specific textual information that may provide Phase I or
-- Phase II-to-Phase I fallback information that may be used to aid in locating the caller. When included,
-- the contents of this field may augment the location information.
LocationDescription ::= PrintableString(SIZE(1..512))

26
27
28
29
30

-- The MobileCallStatus parameter indicates the validation status of the mobile in ANSI-41 systems.
MobileCallStatus ::= OCTET STRING -- See Chapter 8 for encoding

31
32
33

MobileIdenticationNumber ::= Digits


-- Type of digits = Not used

34
35

-- Nature of number = International, no presentation restrictions

36

-- Encoding = BCD

37
38

-- Numbering Plan = Not applicable

39
40
41
42
43
44
45
46
47
48
49
50

-- The PositionInformation parameter contains the geographic position estimate of the


-- mobile and the time of the position determination. The PositionInformation parameter
-- may also contain information regarding the method used to obtain the geographic
-- position.
PositionInformation ::= SEQUENCE {
posTime
[0] GeneralizedTime, -- Time of position determination.
geoPos
[1] GeographicPosition,
positionSource
[2] PositionSource OPTIONAL, -- Shall be included, if available.

51
52
53
54
55
56
57
58
59
60

7-6

2 Emergency Services Protocol Abstract Syntax

ANSI/J-STD-036-B

-- The PositionRequestType parameter indicates the type of position requested.


PositionRequestType ::= ENUMERATED {
initial
(1),
-- In LSP, return updated position only if
-- initial position is unavailable
updated
(2),
updatedorLastKnown
(3),
test
(4)
-- This value is only applicable for ESP

1
2
3
4
5
6
7
8
9
10

}
-- Exception handling: Undefined values are treated as value 1 (initial)

11
12
13
14

-- The PositionResult parameter indicates the type of position returned or the reason for
-- not providing position information. The syntax for PositionResult described in this page is applicable to Emergency Services Protocol exclusively.
PositionResult ::= ENUMERATED {
initialPositionReturned
(1),
updatedPositionReturned
(2),
lastKnownPositionReturned (3),

15
16
17
18
19
20
21
22
23

-- The following codes indicate that position was not returned.


requestedPositionNotAvailable (4),
callerDisconnected
(5),
-- No call in progress for caller identified.
callerHandedOff
(6),
-- Caller has handed-off (e.g., to a position incapable system).
inactive
(7),
-- Identified mobile is inactive or has roamed to another system.
unresponsive
(8),
-- Identified mobile is active, but does not respond to position request.
refused
(9),
-- Identified mobile is responsive, but refused position request.
test
(10),
-- Indicates successful test.

24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

}
-- Exception handling:
-- If undened values are received they are treated as if value 4 (requestedPositionNotAvailable)
-- was received.

40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2 Emergency Services Protocol Abstract Syntax

7-7

ANSI/J-STD-036-B

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

-- The PositionSource parameter specifies how a particular position information was


-- obtained to help assess its credibility.
PositionSource ::= ENUMERATED {
unknown (0),
-- Network Position Sources
networkUnspecified (1),
networkAOA (2),
networkTOA (3),
networkTDOA (4),
networkRFFingerprinting (5),
networkCellSector (6),
networkCellSectorWithTiming (7),

16
17
18
19
20
21
22
23
24
25
26

-- Handset Position Sources


handsetUnspecified (16),
handsetGPS (17),
handsetAGPS (18),
handsetEOTD (19),
handsetAFLT (20),
handsetEFLT (21),

27
28
29
30
31
32
33
34
35
36

-- Hybrid Position Sources


hybridUnspecified (32),
hybridAGPS_AFLT (33),
hybridCellSector_AGPS (34),
hybridNetworkTDOA_AOA (35),
hybridNetworkTDOA_AGPS (36),
hybridTDOA_AGPS_AOA (37),

37
38
39
40
41
42
43

-- Class of Service Position Sources


cosUnspecified (48),
cosWRLS (49), -- E911 Phase I only deployment. No positioning fix available.
cosWPH1 (50), -- E911 Phase I fallback for Phase II deployment.
cosWPH2 (51) -- E911 Phase II with caller s location.

44
45
46
47
48
49
50
51
52
53
54
55
56

}
-- Exception handling:
-- Undefined values in the range 1-15 are treated as value 1 (networkUnspecified)
-- Undefined values in the range 16-31 are treated as value 16 (handsetUnspecified)
-- Undefined values in the range 32-47 are treated as value 32 (hybridUnspecified)
-- Undefined values in the range 48-63 are treated as value 48 (cosUnspecified)
-- Other undefined values are treated as if value 0 (unknown)
END

57
58
59
60

7-8

2 Emergency Services Protocol Abstract Syntax

ANSI/J-STD-036-B

Chapter 8: Stage 3 Implementation


Perspective: ANSI-41.5xx Enhancements

1
2
3
4
5
6
7
8
9

10

Introduction

11
12

The ANSI-41 protocol enhancements support Figure 3-1 Network Reference Model interfaces:
a. MSC MSC (Reference Point E) via operations:

13
14
15

i. IntersystemPositionRequestForward

16
17

ii. FlashRequest

18

iii. SMSDeliveryBackward
iv. SMSDeliveryForward
b. MSC MPC (Reference Point E3) via operations:
i. CallTerminationReport
ii. IntersystemPositionRequest

19
20
21
22
23
24
25
26

iii. OriginationRequest

27

iv. SMSDeliveryPointToPoint

28
29

c. PDE MPC (Reference Point E5) via operations:


i. CallTerminationReport
ii. GeoPositionRequest

30
31
32
33

iii. GeoPositionDirective
iv. InterSystemPositionRequest

34
35
36
37

v. SMSDeliveryPointToPoint
d. MSC PDE (Reference Point E12) via operation:
i. SMSDeliveryPointToPoint
ii. IntersystemPositionRequest

38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-1

ANSI/J-STD-036-B

1
2

Operations and Parameter Definitions

2.1

DATA TRANSFER SERVICES

3
4
5
6
7
8

2.1.1

SS-7 BASED DATA TRANSFER SERVICES

2.1.1.1

Message Transfer Part

Table 8-1:

MTP Message Priority Values for ANSI-41 Operations

9
10
11
12
13
14

ANSI-41 Operation

Priority

15
16

CallTerminationReport

GeoPositionDirective

GeoPositionRequest

IntersystemPositionRequest

IntersystemPositionRequestForward

17
18
19
20
21
22
23
24
25
26
27
28
29

2.2

MAP Operations (ANSI-41.540)

30
31

2.2.1

General

2.2.1.1

Operation Specifiers

32
33
34

The following table lists the ANSI-41 MAP Operation Specifiers.

35
36
37

Table 8-2:

ANSI-41 MAP Operation Specifiers

38
39
40

Operation Name

Operation Specifier
H G F E D C B A

Decimal

CallTerminationReport

0 1 0 1 1 1 0 0

92

GeoPositionDirective

0 1 0 1 1 1 0 1

93

GeoPositionRequest

0 1 0 1 1 1 1 0

94

IntersystemPositionRequest

0 1 0 1 1 1 1 1

95

IntersystemPositionRequestForward

0 1 1 0 0 0 0 0

96

41
42
43
44
45
46
47
48
49

50
51
52
53
54
55
56
57
58
59
60

8-2

2 Operations and Parameter Denitions

ANSI/J-STD-036-B

2.2.1.2

Operation Definitions

1
2

The following table summarizes the operations defined for the ANSI-41 MAP:

3
4

Table 8-3:

Summary of MAP Operations

5
6

Operation

Reference

7
8
9
10

CallTerminationReport

2.2.1.3

GeoPositionDirective

2.2.1.4

GeoPositionRequest

2.2.1.5

IntersystemPositionRequest

2.2.1.6

IntersystemPositionRequestForward

2.2.1.7

11
12
13
14
15
16
17
18
19
20

21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2 Operations and Parameter Denitions

8-3

ANSI/J-STD-036-B

2.2.1.3

CallTerminationReport

The CallTerminationReport (CTRPT) operation is used by an MSC to report to an MPC that a call
has been released and all resources (e.g., ESRK) assigned to the call may be released. The MPC
upon receiving this message from the MSC may use it to inform the PDE that a call has been
released.

3
4
5
6
7

The following table lists the possible combinations of invoking and responding FEs.

8
9
10

Table 8-4:

FE Combinations for CTRPT

11

INVOKING FE

RESPONDING FE

INTERFACE

Case 1

MSC

MPC

E3

Case 2

MPC

PDE

E5

12
13
14
15
16
17

The CallTerminationReport operation is initiated with a TCAP INVOKE (LAST). This is carried by
a TCAP QUERY WITH PERMISSION package. The Parameter Set is encoded as follows:

18
19
20
21

Table 8-5:

CallTerminationReport INVOKE Parameters

22
23

CallTerminationReport INVOKE Parameters

Timer: CTRT

24
25

Field

Value

26

Type

Reference

Identifier

28

Length

29

Contents

Notes

SET [NATIONAL 18]

6.3.2.1

variable octets

6.3.2.1

BillingID

6.5.2.16

32

ElectronicSerialNumber

6.5.2.63

33

MSID

6.5.2.bv

NetworkTMSI

6.5.2.117

27

30
31

34
35
36
37
38
39
40
41
42
43
44

Notes:
a. Include to identify the call.
b. Include the identifier with which the MS last accessed the system, unless that identifier was
a MIN-based IMSI, in which case the MobileIdentificationNumber (populated with the
MIN derived from that IMSI) should be included.
c. Include if applicable.

45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-4

2 Operations and Parameter Denitions

ANSI/J-STD-036-B

Table 8-6:

The CallTerminationReport operation success is reported with a TCAP RETURN RESULT


(LAST). This is carried by a TCAP RESPONSE package. The Parameter Set is encoded as follows:

CallTerminationReport RETURN RESULT Parameters

2
3

5
6

CallTerminationReport RETURN RESULT Parameters

Notes

Field

Value

Type

Reference

Identifier

SET [NATIONAL 18]

6.3.2.2

10

Length

zero octets

6.3.2.2

11

12

Contents

13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2 Operations and Parameter Denitions

8-5

ANSI/J-STD-036-B

2.2.1.4

GeoPositionDirective

The GeoPositionDirective (GPOSDIR) operation is used to push an MSs position from the PDE to
the MPC.

3
4
5

The following table lists the possible combinations of invoking and responding FEs.

6
7
8

Table 8-7:

FE Combinations for GPOSDIR

9
10

INVOKING FE

RESPONDING FE

INTERFACE

PDE

MPC

E5

11

Case 1

12
13

The GeoPositionDirective operation is initiated with a TCAP INVOKE (LAST). This is carried by
a TCAP QUERY WITH PERMISSION package. The Parameter Set is encoded as follows:

14
15
16
17

Table 8-8:

GeoPositionDirective INVOKE Parameters

18

GeoPositionDirective INVOKE Parameters

19
20

Field

21

Value

Timer: GPDT
Type

Reference

Notes

Identifier

SET [NATIONAL 18]

6.3.2.1

Length

variable octets

6.3.2.1

PositionInformation

6.5.2.fr

28

IMSI

6.5.2.bu

29

ElectronicSerialNumber

6.5.2.63

31

MobileIdentificationNumber

6.5.2.81

32

MEID

6.5.2.hv

NetworkTMSI

6.5.2.bl

22
23
24

Contents

25
26
27

30

33
34
35

Notes:

36
37

a. Include if known.

38

The GeoPositionDirective operation success is reported with a TCAP RETURN RESULT (LAST).
This is carried by a TCAP RESPONSE package. The Parameter Set is encoded as follows:

39
40
41
42

Table 8-9:

GeoPositionDirective RETURN RESULT Parameters

43
44

GeoPositionDirective RETURN RESULT Parameters

45

Field

46
47
48
49
50

Value

Type

Reference

Identifier

SET [NATIONAL 18]

6.3.2.2

Length

variable octets

6.3.2.2

6.5.2.16

Notes

Contents

51
52

BillingID

53
54

a. Include if applicable, to allow correlation.

55
56
57
58
59
60

8-6

2 Operations and Parameter Denitions

ANSI/J-STD-036-B

2.2.1.5

GeoPositionRequest

1
2

The GeoPositionRequest (GPOSREQ) operation is used to request the MS position from the PDE.

3
4

The following table lists the possible combinations of invoking and responding FEs.
Table 8-10:

5
6

FE Combinations for GPOSREQ

INVOKING FE

RESPONDING FE

INTERFACE

MPC

PDE

E5

Case 1

8
9
10
11
12

There are several possible results returned, as:

13
14

a. Requested position information.

15

b. Reason for the requested information not being returned.

16

The GeoPositionRequest operation is initiated with a TCAP INVOKE (LAST). This is carried by a
TCAP QUERY WITH PERMISSION package. The Parameter Set is encoded as follows:
Table 8-11:

19

21

GeoPositionRequest INVOKE Parameters


Value

18

20

GeoPositionRequest INVOKE Parameters

Field

17

Timer: GPRT
Notes

22
23
24

Type

Reference

SET [NATIONAL 18]

6.3.2.1

26

variable octets

6.3.2.1

27

25

Identifier
Length

28

Contents

29

PositionRequestType

6.5.2.fs

BillingID
ElectronicSerialNumber

O
O

6.5.2.16
6.5.2.63

h
b

IMSI

6.5.2.bu

LCS_Client_ID

2.3.2.11

36

MEID

6.5.2.hv

37

MobileIdentificationNumber

6.5.2.81

39

MobilePositionCapability

6.5.2.fm

40

Mobinfo_AMPS **Macro**

6.5.2.fp

Mobinfo_CDMA **Macro**

6.5.2.fq

Mobinfo_NAMPS **Macro**

6.5.2.fo

Mobinfo_TDMA**Macro**

6.5.2.fn

46

MSCID (Serving)

6.5.2.82

47

NetworkTMSI

6.5.2.bl

ServingCellID

6.5.2.117

Teleservice_Priority

6.5.2.dt

30
31
32
33
34
35

38

41
42
43
44
45

48
49
50
51
52
53

Notes:

54

a. Include if known, to identify the MSs position capabilities.


b. Include if known.

55
56
57
58
59
60

2 Operations and Parameter Denitions

8-7

ANSI/J-STD-036-B

c. If TDMA, include to specify priority for message processing. In the absence of this
parameter, treat as the lowest priority.

1
2
3

d. Include if a TDMA channel is in use.

4
5

e. Include if an NAMPS channel is in use.

f. Include if an AMPS channel is in use.

7
8

g. Include if a CDMA channel is in use.

h. Include if applicable.

10
11

The GeoPositionRequest operation success is reported with a TCAP RETURN RESULT (LAST).
This is carried by a TCAP RESPONSE package. The Parameter Set is encoded as follows:

12
13
14
15

Table 8-12:

GeoPositionRequest RETURN RESULT Parameters

16
17

GeoPositionRequest RETURN RESULT Parameters

18

Field

Value

Type

Reference

Notes

19
20
21

Identifier

SET [NATIONAL 18]

6.3.2.2

Length

variable octets

6.3.2.2

PositionInformation

6.5.2.fr

PositionResult

6.5.2.ft

22
23
24

Contents

25
26
27
28
29
30
31

Notes:
a. Include to identify the position results.
b. Include if position information was obtained.

32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-8

2 Operations and Parameter Denitions

ANSI/J-STD-036-B

2.2.1.6

InterSystemPositionRequest

1
2

The InterSystemPositionRequest (ISPOSREQ) operation is used to request MS position information


between network elements. This message may also be used to ascertain an MSs cell, sector, channel
and TMSI information.

3
4
5
6

The following table lists the possible combinations of invoking and responding FEs.

7
8
9

Table 8-13:

FE Combinations for ISPOSREQ

10
11

INVOKING FE

RESPONDING FE

INTERFACE

12
13

Case 1

MPC

MSC

E3

Case 2

MSC

MPC

E3

14
15
16
17

Case 3

PDE

MSC

E12

Case 4

PDE

MPC

E5

18
19

There are several possible results returned, as:

20
21
22
23

a. Requested position information (e.g., initial, current, last).

24

b. Mobile channel information is returned, when the responding MSC is serving the MS.

26

c. Reason for the requested information not being returned.

25

27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2 Operations and Parameter Denitions

8-9

ANSI/J-STD-036-B

The InterSystemPositionRequest operation is initiated with a TCAP INVOKE (LAST). This is


carried by a TCAP QUERY WITH PERMISSION package. The Parameter Set is encoded as
follows:

1
2
3
4
5
6
7
8

Table 8-14:

InterSystemPositionRequest INVOKE Parameters


InterSystemPositionRequest INVOKE Parameters

Field

Value

Timer: IPRT
Type

Reference

Notes

10
11

Identifier

SET [NATIONAL 18]

6.3.2.1

12

Length

variable octets

6.3.2.1

13
14

Contents

15

PositionRequestType

6.5.2.fs

16

CDMAPSMMCount

6.5.2.gb

18

ElectronicSerialNumber

6.5.2.63

19

EmergencyServicesRoutingDigits

6.5.2.bs

d, f

IMSI

6.5.2.bu

22

LCS_Client_ID

2.3.2.11

23

MEID

6.5.2.hv

MobileDirectoryNumber

6.5.2.80

26

MobileIdentificationNumber

6.5.2.81

27

MobInfo_AMPS **Macro**

6.5.2.fn

b, f

17

20
21

24
25

28

MobInfo_CDMA **Macro**

6.5.2.fo

a, f

30

MobInfo_NAMPS **Macro**

6.5.2.fp

c, f

31

MobInfo_TDMA **Macro**

6.5.2.fq

g, f

33

MobilePositionCapability

6.5.2.fm

e, f

34

MSCID (Serving)

6.5.2.82

35

NetworkTMSI

6.5.2.bl

37

ServingCellID

6.5.2.117

38

TDMA_MAHORequest

2.3.2.28

29

32

36

39
40

Notes:

41
42
43
44
45
46
47
48
49
50
51
52
53
54

a. Include if an CDMA channel is in use.


b. Include if an AMPS channel is in use.
c. Include if an NAMPS channel is in use.
d. Include if known.
e. Include if known, to identify the MSs position capabilities.
f. Only include when initiating entity is an MSC.
g. Include if a TDMA channel is in use.
h. Include if the MSC should collect Pilot Strength Measurements from the MS.
i. Include if the MSC should collect MAHO Measurements from the MS.

55
56
57
58
59
60

8-10

2 Operations and Parameter Denitions

ANSI/J-STD-036-B

The InterSystemPositionRequest operation success is reported with a TCAP RETURN RESULT


(LAST). This is carried by a TCAP RESPONSE package. The Parameter Set is encoded as follows:

1
2
3

Table 8-15:

InterSystemPositionRequest RETURN RESULT Parameters

5
6

InterSystemPositionRequest RETURN RESULT Parameters

Field

Value

Type

Reference

Identifier

SET [NATIONAL 18]

6.3.2.2

Length

variable octets

6.3.2.2

Notes

8
9
10
11
12

Contents

13

PositionResult

6.5.2.ft

MobilePositionCapability

6.5.2.fm

MobInfo_AMPS **Macro**

6.5.2.fn

c,e

MobInfo_CDMA **Macro**

6.5.2.fo

b,e

MobInfo_NAMPS **Macro**

6.5.2.fp

g,e

20

MobInfo_TDMA **Macro**

6.5.2.fq

a,e

21

MSCID (Serving)

6.5.2.82

23

PositionInformation

6.5.2.fr

24

ServingCellID

6.5.2.117

14
15
16
17
18
19

22

25
26
27

Notes:

28

a. Include if a TDMA channel is in use.

29
30

b. Include if a CDMA channel is in use.

31

c. Include if an AMPS channel is in use.

32

d. Include if known when the responding entity is an MSC.

34

e. Include when the responding entity is the Serving MSC.


f. Include to identify the Serving MSC.
g. Include if an NAMPS channel is in use.
h. Include if known.

33

35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2 Operations and Parameter Denitions

8-11

ANSI/J-STD-036-B

2.2.1.7

InterSystemPositionRequestForward

2
3
4

The IntersystemPositionRequestForward (ISPOSREQFWD) operation is used from the Anchor MSC toward
the Serving MSC to request MS position information.

The following table lists the possible combinations of invoking and responding FEs.

6
7

Table 8-16:

FE Combinations for ISPOSREQFWD

8
9

INVOKING FE

RESPONDING FE

INTERFACE

Case 1

Anchor MSC

Serving MSC

Case 2

Anchor MSC

Tandem MSC

Case 3

Tandem MSC

Tandem MSC

Case 4

Tandem MSC

Serving MSC

10
11
12
13
14
15
16
17
18
19

There are several possible results returned, as:

20
21

a. Requested position information (e.g., initial, current, last).

22

b. Reason for the requested information not being returned.

23
24

The IntersystemPositionRequestForward operation is initiated with a TCAP INVOKE (LAST). This


is carried by a TCAP QUERY WITH PERMISSION package. The Parameter Set is encoded as
follows:

25
26
27
28
29

Table 8-17:

InterSystemPositionRequestForward INVOKE Parameters

30
31

InterSystemPositionRequestForward INVOKE Parameters

Timer: IPFT

32

Field

33
34

Value

Type

Reference

Notes

Identifier

SET [NATIONAL 18]

6.3.2.1

36

Length

variable octets

6.3.2.1

37

Contents
ElectronicSerialNumber

6.5.2.63

InterMSCCircuitID

6.5.2.72

PositionRequestType

6.5.2.fs

43

IMSI

6.5.2.bu

44

LCS_Client_ID

2.3.2.11

46

MEID

6.5.2.hv

47

MobileIdentificationNumber

6.5.1.1

49

MobilePositionCapability

6.5.2.fm

50

TDMA_MAHORequest

2.3.2.28

35

38
39
40
41
42

45

48

51
52

Notes:

53
54
55
56
57

a. Include if known.
b. Include if known, to identify the MSs position capabilities.
c. Include if the MSC should collect MAHO Measurements from the MS.

58
59
60

8-12

2 Operations and Parameter Denitions

ANSI/J-STD-036-B

Table 8-18:

The InterSystemPositionRequestForward operation success is reported with a TCAP RETURN


RESULT (LAST). This is carried by a TCAP RESPONSE package. The Parameter Set is encoded
as follows:

InterSystemPositionRequestForward RETURN RESULT Parameters

Value

Type

Reference

Identifier

SET [NATIONAL 18]

6.3.2.2

Length

variable octets

6.3.2.2

3
4

6
7

InterSystemPositionRequestForward RETURN RESULT Parameters


Field

Notes

9
10
11
12
13

Contents

14
15

MSCID (Serving)

6.5.2.82

PositionResult

6.5.2.ft

PositionInformation

6.5.2.fr

ServingCellID

6.5.2.117

16
17
18
19
20
21

Notes:

22
23

a. Include if known.

24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2 Operations and Parameter Denitions

8-13

ANSI/J-STD-036-B

2.2.1.8

OriginationRequest

The OriginationRequest operation is used to request call origination treatment on behalf of a registered MS. The ORREQ operation is also used to request the position or emergency services call
routing information for an MS from the MPC, when an emergency services call is initiated by the
MS.

3
4
5
6
7

The following table lists the possible combinations of invoking and responding FEs.

8
9
10
11

Table 8-19:

FE Combinations for ORREQ

12

INVOKING FE

RESPONDING FE

INTERFACE

Case 1

Serving MSC

HLR

Case 2

MSC

MPC

E3

13
14
15
16
17
18
19

There are several possible results returned, as:

20

a. Notification that the origination request was successful with routing instructions.

21
22

b. Notification that the origination request was unsuccessful with an (optional) indication of
the treatment to provide the served MS.

23
24

c. Return of position or routing information for an emergency services call.

25
26

The OriginationRequest operation is initiated with a TCAP INVOKE (LAST). This is carried by a
TCAP QUERY WITH PERMISSION package. The Parameter Set is encoded as follows:

27
28
29
30

Table 8-20:

OriginationRequest INVOKE Parameters

31
32

OriginationRequest INVOKE Parameters

Timer: ORT

33

Field

34
35

Value

Type

Reference

Identifier

SET [NATIONAL 18]

6.3.2.1

Length

variable octets

6.3.2.1

Notes

36
37
38
39

Contents

40

BillingID (originating)

6.5.2.16

41

Digits (Dialed)

6.5.2.58

ElectronicSerialNumber

6.5.2.63

MSID

6.5.2.bv

MSCID

6.5.2.82

47

OriginationTriggers

6.5.2.90

48

TransactionCapability

6.5.2.160

50

CallingPartyNumberDigits1

6.5.2.21

51

CallingPartyNumberDigits2

6.5.2.22

CallingPartySubaddress

6.5.2.25

EmergencyServicesRoutingDigits

6.5.2.bs
6.5.2.hv

l
s

42
43
44
45
46

49

h, q, r

52
53
54

MEID

O
O

57

MobileCallStatus

6.5.2.fl

58

MobileDirectoryNumber

6.5.2.80

b, g

55
56

59
60

8-14

2 Operations and Parameter Denitions

ANSI/J-STD-036-B

MobilePositionCapability

6.5.2.fm

MobInfo_AMPS **Macro**

6.5.2.fn

i, p, l

MobInfo_CDMA **Macro**

6.5.2.fo

j, p, l

MobInfo_NAMPS **Macro**

6.5.2.fq

k, p, l

MobInfo_TDMA **Macro**

6.5.2.fp

n, p, l

MSCIdentificationNumber

6.5.2.83

NetworkTMSI

6.5.2.bl

10

OneTimeFeatureIndicator

6.5.2.88

OriginationIndicator

6.5.2.89

PC_SSN (Originating MSC)

6.5.2.93

SenderIdentificationNumber

6.5.2.116

16

ServingCellID

6.5.2.117

17

TerminationRestrictionCode

6.5.2.157

2
3
4
5

11
12
13
14
15

18
19
20

Notes:

21
22

a. Include if applicable.

23

b. Include if available for recording purposes (see DMH).


c. Include to identify the MSC initiating the message.
d. Include if any OneTimeFeatureIndicator status bits are set (i.e., have value of 1).
e. Include if SS7 may be used for subsequent call redirection.
f. Include to identify intermediate message sender if different from the MSCIdentificationNumber.

24
25
26
27
28
29
30
31
32

g. For an emergency services call, include as the callback number or the non-dialable callback
number as defined in normative Annex C.
h. Include the identifier with which the MS last accessed the system, unless that identifier was
a MIN-based IMSI, in which case the MobileIdentificationNumber (populated with the
MIN derived from that IMSI) should be included.

33
34
35
36
37
38

i. Include if an AMPS channel is in use.

39

j. Include if a CDMA channel is in use.

40

k. Include if a NAMPS channel is in use.

42

l. Include if applicable for an Emergency Services call.


m. Include if known, if applicable.
n. Include if a TDMA channel is in use.
o. Include if known, to identify the MSs position capabilities. Value from the MS takes
precedence over the value from the profile, if both are available.
p. Include when the invoking entity is the Serving MSC.
q. For an emergency services call, include an all-zeroes MIN or IMSI of length 0 as MSID if
the MS does not have a valid MSID.

41

43
44
45
46
47
48
49
50
51
52
53
54

r. If the MS has used TMSI each time it has accessed the system, use the MIN form of the
MSID, if known.

55

s. Include for Case 2, if known.

57

56

58
59
60

2 Operations and Parameter Denitions

8-15

ANSI/J-STD-036-B

The OriginationRequest operation success is reported with a TCAP RETURN RESULT (LAST).
This is carried by a TCAP RESPONSE package. The Parameter Set is encoded as follows:

1
2
3
4

Table 8-21:

OriginationRequest RETURN RESULT Parameters

5
6

OriginationRequest RETURN RESULT Parameters

Field

8
9

Value

Type

Reference

Notes

Identier

SET [NATIONAL 18]

6.3.2.2

11

Length

variable octets

6.3.2.2

12

Contents
AccessDeniedReason

6.5.2.1

ActionCode

6.5.2.2

17

AnnouncementList

6.5.2.6

18

CallingPartyNumberString1

6.5.2.23

d, e

CallingPartyNumberString2

6.5.2.24

d, e

CallingPartySubaddress

6.5.2.25

d, e, f

CarrierDigits

6.5.2.28

24

Digits (Dialed)

6.5.2.58

h, x

25

DMH_AccountCodeDigits

6.5.2.59

27

DMH_AlternateBillingDigits

6.5.2.60

28

DMH_BillingDigits

6.5.2.61

i, v

DMH_RedirectionIndicator

6.5.2.62

i, j

GenericDigits

6.5.2.fj

33

GeographicPosition

6.5.2.fk

34

GroupInformation

6.5.2.69

MobileDirectoryNumber

6.5.2.80

i, u

NoAnswerTime

6.5.2.87

OneTimeFeatureIndicator

6.5.2.88

40

PilotNumber

6.5.2.95

41

RedirectingNumberDigits

6.5.2.107

43

RedirectingNumberString

6.5.2.108

44

RedirectingSubaddress

6.5.2.109

d, e

RoutingDigits

6.5.2.114

TerminationList

6.5.2.156

n, x

TerminationTriggers

6.5.2.57

10

13
14
15
16

19
20
21
22
23

26

29
30
31
32

35
36
37
38
39

42

45
46
47
48
49
50
51
52
53
54
55
56
57
58

Notes:
a. Include if access is denied. If included, no other optional parameters shall be included (with
the exception of the AnnouncementList parameter).
b. Include if action to be performed is not implied through presence of other parameters.
c. Include if one or more tones or announcements are to be applied to the MS.
d. Include if a LocalTermination parameter is included in the TerminationList parameter.

59
60

8-16

2 Operations and Parameter Denitions

ANSI/J-STD-036-B

e. Include if the related feature is active.

1
2

f. Include if a PSTNTermination parameter or an IntersystemTermination parameter is


included within the TerminationList parameter.

g. Include if applicable.

h. Include if digits remain to be translated by the MSC.

i. Include if available for recording purposes (see DMH).

j. Include if redirection may apply.

10

11

k. Include for multileg calls.

12

l. Include to request an override of the Serving MSCs default No Answer Time value.
m. Include if modification to normal feature processing is required for the call in progress.
n. Include if call routing is required.
o. Include to indicate processing in the Originating MSC for failed call attempts.
Note: the omitted text is retained without modification.

13
14
15
16
17
18
19
20

t. Include if the Generic Digits parameter in an outgoing ISUP IAM message should be
populated by this value with the Type of Digits set to Location Identification Number.
u. Include if the Calling Party Number parameter in an outgoing ISUP IAM message should
be populated by this value.
v. Include if the Charge Number parameter in an outgoing ISUP IAM message or the ANI in
an outgoing MF trunk should be populated by this value.
w. Include if geographic position information should be included in an outgoing ISUP IAM
message.
x. This parameter may contain an ESRK or ESRD for Emergency Services Calls. See
normative Annex D.

21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2 Operations and Parameter Denitions

8-17

ANSI/J-STD-036-B

2.2.1.9

SMSDeliveryBackward

The SMSDeliveryBackward operation is a general purpose operation that is used to convey an MSoriginated short message or in general any other information or encapsulated data to the Anchor
MSC after handoff.

3
4
5
6

The SMSDeliveryBackward operation is initiated with a TCAP INVOKE (LAST). This is carried
by a TCAP QUERY WITH PERMISSION package. The Parameter Set is encoded as follows:

7
8
9
10
11
12

Table 8-22:

SMSDeliveryBackward INVOKE Parameters


SMSDeliveryBackward INVOKE Parameters

13

Field

14
15

Value

Timer: SBT
Type

Reference

Notes

Identier

SET [NATIONAL 18]

6.3.2.1

Length

variable octets

6.3.2.1

InterMSCCircuitID

6.5.2.72

MSID

6.5.2.bv

SMS_BearerData

6.5.2.124

SMS_TeleserviceIdentier

6.5.2.137

CDMAServingOneWayDelay2

6.5.2.gd

ElectronicSerialNumber

6.5.2.63

MSCID (Serving)

6.5.2.82

ServiceIndicator

6.5.2.bz

ServingCellID

6.5.2.117

SMS_ChargeIndicator

6.5.2.126

SMS_DestinationAddress

6.5.2.127

SMS_OriginalDestinationAddress

6.5.2.131

SMS_OriginalDestinationSubaddress

6.5.2.132

SMS_OriginalOriginatingAddress

6.5.2.133

SMS_OriginalOriginatingSubaddress

6.5.2.134

SMS_OriginatingAddress

6.5.2.135

SMS_TransactionID

6.5.2.ee

16
17
18
19

Contents

20
21
22
23
24
25
26

a, k

27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

Notes:
a. Include to identify the originating MS.
b. Include if applicable.

56
57

c. Include if applicable. If not received, charge message originator.

58
59
60

8-18

2 Operations and Parameter Denitions

ANSI/J-STD-036-B

d. Include if not carried by the underlying data transport. May require an interconnection
agreement to facilitate interworking between network types.

1
2
3

e. Include if different than the destination address (SMS_DestinationAddress or underlying


data transport destination address).
f. Include if different than the originating address (SMS_OriginatingAddress or underlying
data transport originating address).

4
5
6
7
8

g. Include if different than the MobileIdentificationNumber, or if not carried by the underlying data transport. May require an interconnection agreement to facilitate interworking
between network types.

9
10
11
12

h. Include for TDMA to identify an MS-based SMS originating SME.

13

i. Include for CDMA Position Determination, if required for the position technology.
j. Include for CDMA or AMPS Position Determination. When ServiceIndicator is included,
the length of the SMS_TeleserviceIdentifier is set to 0.
k. When used to support position determination for an emergency services call, include an allzeroes MIN or IMSI of length 0 as MSID if the MS does not have an MSID.

14
15
16
17
18
19
20

The SMSDeliveryBackward operation success is reported with a TCAP RETURN RESULT


(LAST). This is carried by a TCAP RESPONSE package. The Parameter Set is encoded as follows:

21
22
23

Table 8-23:

SMSDeliveryBackward RETURN RESULT Parameters

24
25

SMSDeliveryBackward RETURN RESULT Parameters


Field

Value

26

Type

Reference

Identier

SET [NATIONAL 18]

6.3.2.1

Length

variable octets

6.3.2.1

Notes

27
28
29
30
31
32

Contents

33
34

SMS_BearerData

6.5.2.124

SMS_CauseCode

6.5.2.125

Teleservice_Priority

6.5.2.dt

35
36
37
38
39
40

Notes:

41

a. Include for positive acknowledgments, when applicable.

42

b. Include for all negative acknowledgments.

44

c. If TDMA, include to specify priority for message processing. In the absence of this
parameter, treat as the lowest priority.

43

45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2 Operations and Parameter Denitions

8-19

ANSI/J-STD-036-B

2.2.1.10

SMSDeliveryForward

The SMSDeliveryForward operation is a general purpose operation that is used to convey an MSterminated short message or in general any other information or encapsulated data to the Serving
MSC after handoff.

3
4
5
6

The SMSDeliveryForward operation is initiated with a TCAP INVOKE (LAST). This is carried by
a TCAP QUERY WITH PERMISSION package. The Parameter Set is encoded as follows:

7
8
9
10
11
12

Table 8-24:

SMSDeliveryForward INVOKE Parameters


SMSDeliveryForward INVOKE Parameters

13

Field

14
15

Value

Timer: SFT
Type

Reference

Notes

Identier

SET [NATIONAL 18]

6.3.2.1

Length

variable octets

6.3.2.1

InterMSCCircuitID

6.5.2.72

SMS_BearerData

6.5.2.124

SMS_TeleserviceIdentier

6.5.2.137

ActionCode

6.5.2.2

ElectronicSerialNumber

6.5.2.63

IMSI

6.5.2.bu

MobileIdenticationNumber

6.5.2.81

ServiceIndicator

6.5.2.bz

SMS_ChargeIndicator

6.5.2.126

SMS_DestinationAddress

6.5.2.127

SMS_OriginalDestinationAddress

6.5.2.131

SMS_OriginalDestinationSubaddress

6.5.2.132

SMS_OriginalOriginatingAddress

6.5.2.133

SMS_OriginalOriginatingSubaddress

6.5.2.134

SMS_OriginatingAddress

6.5.2.135

Teleservice_Priority

6.5.2.dt

16
17
18
19

Contents

20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

Notes:
a.

Deleted.

b.

Include if applicable.

c.

Include if applicable. If not received, charge message originator.

d.

Include if different than the destination address (MobileIdenticationNumber or underlying data transport destination address). May require an interconnection agreement to facil-

56
57
58
59
60

8-20

2 Operations and Parameter Denitions

ANSI/J-STD-036-B

itate interworking between network types.

e.
f.
g.

h.

Include if different than the destination address (MobileIdenticationNumber,


SMS_DestinationAddress, or underlying data transport destination address).
Include if different than the originating address (SMS_OriginatingAddress or underlying
data transport originating address).

3
4
5
6
7

Include if different than the MobileIdenticationNumber, or if not carried by the underlying data transport. May require an interconnection agreement to facilitate interworking
between network types.

Include if available. At least one of these parameters should be present.

12

9
10
11

13

i. Include for CDMA or AMPS Position Determination. When ServiceIndicator is included,


the length of the SMS_TeleserviceIdentifier is set to 0.
j. If TDMA, include to specify priority for message processing. In the absence of this
parameter, treat as the lowest priority.

14
15
16
17
18
19

k. Include for Position Determination, if required for the position technology.

20

The SMSDeliveryForward operation success is reported with a TCAP RETURN RESULT (LAST).
This is carried by a TCAP RESPONSE package. The Parameter Set is encoded as follows:

21
22
23

Table 8-25:

SMSDeliveryForward RETURN RESULT Parameters

24
25

SMSDeliveryForward RETURN RESULT Parameters

26
27

Field

Value

Type

Reference

Identier

SET [NATIONAL 18]

6.3.2.2

Length

variable octets

6.3.2.2

Notes

28
29
30
31
32
33

Contents

34

CDMAServingOneWayDelay2

6.5.2.gd

MSCID (Serving)

6.5.2.82

ServingCellID

6.5.2.117

SMS_BearerData

6.5.2.124

SMS_CauseCode

6.5.2.125

35
36
37
38
39
40
41
42
43
44

Notes:

45

a.

Include for positive acknowledgments, when applicable.

b.

Include for all negative acknowledgments.

46
47

c. Include for CDMA Position Determination if required for the position technology.

48
49
50
51
52
53
54
55
56
57
58
59
60

2 Operations and Parameter Denitions

8-21

ANSI/J-STD-036-B

2.2.1.11

SMSDeliveryPointToPoint

The SMSDeliveryPointToPoint (SMDPP) operation is a general purpose operation that is used to


convey a short message or in general any other information or encapsulated data from one point to
another point and report on the success or failure of that transfer (for example, as used in SMS,
CDMA OTASP, or Position Determination).

3
4
5
6
7
8
9

Table 8-26:

FE Combinations for SMDPP .

10

INVOKING FE

RESPONDING FE

Case 1

SME

MC

Case 2

MC

MC

Case 3

MC

SME

Case 4

SME

SME

Case 5
(Note 1)

SME

OTAF

Case 6
(Note 1)

OTAF

SME

Case 7
(Note 2)

OTAF

MSC

Case 8

MSC

MPC

Case 9

MPC

PDE

Case 10

MSC

PDE

Case 11

PDE

MSC

Case 12

PDE

MPC

Case 13

MPC

MSC

11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

Notes:

36
37

1. Cases 5 and 6 are only applicable to TDMA OTA.

38
39

2. Case 7 is only applicable to CDMA OTA.

40

The SMSDeliveryPointToPoint operation is initiated with a TCAP INVOKE (LAST). This is carried
by a TCAP QUERY WITH PERMISSION package. The Parameter Set is encoded as follows:

41
42
43
44

Table 8-27:

SMSDeliveryPointToPoint INVOKE Parameters

45
46

SMSDeliveryPointToPoint INVOKE Parameters

Timer: SMT

47

Type

Reference

Identifier

Field

SET [NATIONAL 18]

6.3.2.1

51

Length

variable octets

6.3.2.1

52

Contents

48
49

Value

50

Notes

53
54

SMS_BearerData

6.5.2.124

55

SMS_TeleserviceIdentifier

6.5.2.137

ActionCode

6.5.2.2

CDMAServingOneWayDelay2

6.5.2.gd

56
57
58
59
60

8-22

2 Operations and Parameter Denitions

ANSI/J-STD-036-B

ElectronicSerialNumber

MEID

O
O

6.5.2.63
6.5.2.hv

a
a

MSCID (Serving)

6.5.2.82

MSID

6.5.2.bv

a, m, p, q

NewlyAssignedIMSI

6.5.2.dq

NewlyAssignedMIN

6.5.2.r

ServiceIndicator

6.5.2.bz

10

ServingCellID

6.5.2.117

SMS_ChargeIndicator

6.5.2.126

SMS_DestinationAddress

6.5.2.127

SMS_MessageCount

6.5.2.128

SMS_NotificationIndicator

6.5.2.130

SMS_OriginalDestinationAddress

6.5.2.131

SMS_OriginalDestinationSubaddress

6.5.2.132

SMS_OriginalOriginatingAddress

6.5.2.133

22

SMS_OriginalOriginatingSubaddress

6.5.2.134

23

SMS_OriginatingAddress

6.5.2.135

Teleservice_Priority

6.5.2.dt

r,s

TemporaryReferenceNumber

6.5.2.y

2
3
4
5

11
12
13
14
15
16
17
18
19
20
21

24
25
26
27
28
29

Notes:

30

a. Include if known and either the destination is an MS-based SME or the operation is used
for CDMA OTASP or CDMA OTAPA or MS-based Position Determination.

31
32
33

b. Include if applicable. If not received, charge the message originator.

34

c. May be included if not carried by the underlying data transport. May require an interconnection agreement to facilitate interworking between network types.

35
36
37

d. Include if applicable. If not received, assume value 0.

38

e. Include if no notification is necessary. If not received, assume notification is requested.

39

f. Include if different than the destination address (SMS_DestinationAddress, MobileIdentificationNumber, or the underlying data transport destination).

41

40

42
43

g. Include if applicable.

44

h. Include if not the same as the originating address (SMS_OriginatingAddress or the underlying data transport originating address).

j. Include for CDMA OTASP or CDMA OTAPA in requests to initiate MSC


a value has been assigned for the MS during the current OTASP or OTAPA session.

46
47

i. Include for Position Determination, CDMA OTASP or CDMA OTAPA if action to be


performed is not implied through presence of other parameters.
procedures1

45

48
49

if

50
51
52

k. Include for CDMA or AMPS Position Determination, CDMA OTASP or CDMA OTAPA.
When ServiceIndicator is included, the length of the SMS_TeleserviceIdentifier is set to 0.

53
54
55
56
57

1. The MSC procedures are Registration Following Successful OTASP or OTAPA and Notication of
Newly Assigned MIN MSID Following Successful OTASP or OTAPA in Section 7 C.

58
59
60

2 Operations and Parameter Denitions

8-23

ANSI/J-STD-036-B

l. Include for CDMA OTASP when requesting MSC attachment to the OTAF to provide a
correlation between the OTASP voice and data connections.

1
2
3

m. For CDMA OTASP, contains the Activation_MIN. For CDMA OTAPA, contains the
MSs MSID at the start of the OTAPA session. When the MS has both the MIN & the IMSI
at the start of the OTAPA session then the MIN form of the MSID is used.

4
5
6
7

n. Include for CDMA Position Determination, if required for the position technology, when
a) the invoking entity is the MSC; or b) when the message is being relayed (i.e., Case 9 or
13).

8
9
10

o. Include for Position Determination, if required for the position technology, when a) the
invoking entity is the MSC; or b) when the message is being relayed (i.e., Case 9 or 13).

11
12
13

p. If the MS has used TMSI each time it has accessed the system, use the MIN form of the
MSID, if known.

14
15

q. When used to support position determination for an emergency services call, include an allzeroes MIN or IMSI of length 0 as MSID if the MS does not have an MSID.

16
17
18

r. Include for TDMA to specify the priority for message processing. If not received, assume
value 0.

19
20

s. Include if the MS has initiated CDMA position determination for an emergency services
call.

21
22
23

The SMSDeliveryPointToPoint operation success is reported with a TCAP RETURN RESULT


(LAST). This is carried by a TCAP RESPONSE package. The Parameter Set is encoded as follows:

24
25
26
27

Table 8-28:

SMSDeliveryPointToPoint RETURN RESULT Parameters

28
29

SMSDeliveryPointToPoint RETURN RESULT Parameters

30

Field

31

Value

Type

Reference

Notes

Identifier

SET [NATIONAL 18]

6.3.2.2

Length

variable octets

6.3.2.2

AuthorizationDenied

6.5.2.13

38

CDMAServingOneWayDelay2

6.5.2.gd

39

DenyAccess

6.5.2.54

41

ElectronicSerialNumber

6.5.2.63

42

MEID

6.5.2.hv

44

MobileStationMSID

6.5.2.ad

45

MSCID

6.5.2.82

ServingCellID

6.5.2.117

SMS_BearerData

6.5.2.124

50

SMS_CauseCode

6.5.2.125

51

SystemCapabilities

6.5.2.146

32
33
34
35
36
37

40

Contents

43

46
47
48
49

52
53

Notes:

54
55
56
57
58
59

a. Include for positive acknowledgments, when applicable.


b. Include for all negative acknowledgments.
c. Include for CDMA OTASP in the response to an attachment request if the AC has denied
service to this MS.

60

8-24

2 Operations and Parameter Denitions

ANSI/J-STD-036-B

d. Include in response to an attachment request, for CDMA OTASP.

1
2

e. Include for CDMA OTASP in the response to an attachment request to indicate the MIN or
IMSI value currently in the MSs permanent memory.
f. Include for CDMA OTASP in the response to an attachment request to identify the Serving
System. Include for CDMA Position Determination, if required for the position technology
employed.

3
4
5
6
7
8

g. Include for CDMA OTASP in the response to an attachment request to identify the serving
systems authentication capabilities.
h. Include for CDMA OTASP in the response to an attachment request if the HLR had previously denied authorization to this MS or the registration attempt was unsuccessful.
i. Include for CDMA Position Determination, if required for the position technology
employed, when a) the responding entity is the MSC; or b) when the message is being
relayed (i.e., Case 9 or 13).
j. Include for Position Determination, if required for the position technology employed, when
a) the responding entity is the MSC; or b) when the message is being relayed (i.e., Case 9
or 13).
k. Include if available, in response to an attachment request, for CDMA OTASP.

9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2 Operations and Parameter Denitions

8-25

ANSI/J-STD-036-B

1
2

2.3

MAP Parameters (ANSI-41.550)

3
4

2.3.1

General

2.3.1.1

Parameter Format

5
6
7
8

ANSI-41 MAP uses the TCAP parameter format defined in ANSI T1.114.

All parameters are encoded in binary, with the rightmost bit of the last octet (or portion thereof) as
the LSB, and the leftmost bit of the first octet (or portion thereof) as the MSB, unless otherwise
specified.

10
11
12
13
14
15

2.3.1.2

16

The following table lists the ANSI-41 MAP Parameter Identifiers.

17
18
19

Parameter Identifiers

Table 8-29:

ANSI-41 MAP Parameter Identifiers (continued)

20
21

Parameter Identifier Name

22

Parameter Identifier Code


H G F E D C B A

Reference

23

1 0 0 1 1 1 1 1
1 0 0 0 0 0 1 0
0 0 1 0 0 0 1 0

2.3.2.30

1 0 0 1 1 1 1 1
1 0 0 0 0 0 1 0
0 1 0 0 1 0 0 1

2.3.2.7

DTXIndication

1 0 0 1 1 1 1 1
1 0 0 0 0 0 1 0
0 1 0 0 1 0 1 0

2.3.2.2

CDMAMobileCapabilities

1 0 0 1 1 1 1 1
1 0 0 0 0 0 1 0
0 1 0 0 1 0 1 1

2.3.2.8

GeneralizedTime

1 0 0 1 1 1 1 1
1 0 0 0 0 0 1 0
0 1 0 0 1 1 0 0

2.3.2.9

GenericDigits

1 0 0 1 1 1 1 1
1 0 0 0 0 0 1 0
0 1 0 0 1 1 0 1

2.3.2.10

GeographicPosition

1 0 0 1 1 1 1 1
1 0 0 0 0 0 1 0
0 1 0 0 1 1 1 0

2.3.2.12

MobileCallStatus

1 0 0 1 1 1 1 1
1 0 0 0 0 0 1 0
0 1 0 0 1 1 1 1

2.3.2.13

MobilePositionCapability

24
25

Teleservice_Priority

26
27

28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-26

2.3 MAP Parameters (ANSI-41.550)

ANSI/J-STD-036-B

Table 8-29:

ANSI-41 MAP Parameter Identifiers (continued)

1
2

1 0 1 1 1 1 1 1
1 0 0 0 0 0 1 0
0 1 0 1 0 0 0 0

PositionInformation

2.3.2.19

3
4
5
6

PositionRequestType

1 0 0 1 1 1 1 1
1 0 0 0 0 0 1 0
0 1 0 1 0 0 0 1

2.3.2.20

1 0 0 1 1 1 1 1
1 0 0 0 0 0 1 0
0 1 0 1 0 0 1 0

2.3.2.20

1 0 0 1 1 1 1 1
1 0 0 0 0 0 1 0
0 1 0 1 0 0 1 1

2.3.2.22

1 0 0 1 1 1 1 1
1 0 0 0 0 0 1 0
0 1 0 1 1 0 0 1

2.3.2.3

1 0 1 1 1 1 1 1
1 0 0 0 0 0 1 0
0 1 0 1 1 0 1 0

2.3.2.4

1 0 0 1 1 1 1 1
1 0 0 0 0 0 1 0
0 1 0 1 1 0 1 1

2.3.2.5

1 0 0 1 1 1 1 1
1 0 0 0 0 0 1 0
0 1 1 0 0 1 1 0

2.3.2.11

1 0 0 1 1 1 1 1
1 0 0 0 0 0 1 0
0 1 1 0 0 1 1 1

2.3.2.26

1 0 0 1 1 1 1 1
1 0 0 0 0 0 1 0
0 1 1 0 1 0 0 0

2.3.2.27

1 0 0 1 1 1 1 1
1 0 0 0 0 0 1 0
0 1 1 0 1 0 1 0

2.3.2.29

7
8
9
10

PositionResult

11
12
13
14

PositionSource

15
16
17
18

CDMAPSMMCount

19
20
21
22

CDMAPSMMList

23
24
25
26

CDMAServingOneWayDelay2

LCS_CLIENT_ID

TDMA_MAHO_CELLID

TDMA_MAHO_CHANNEL

TDMA_TimeAlignment

27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

1 0 0 1 1 1 1 1
1 0 0 0 0 0 1 0
0 1 1 0 1 1 0 0

TDMA_MAHORequest

2.3.2.28

46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.3 MAP Parameters (ANSI-41.550)

8-27

ANSI/J-STD-036-B

1
2

2.3.2

Parameter Definitions

2.3.2.1

ActionCode

3
4
5

This parameter is defined in ANSI-41.

6
7

The ActionCode (ACTCODE) parameter specifies the nature of the action (e.g., disconnect the call)
to be performed by the designated functional entity.

8
9
10
11

Table 8-30:

ActionCode parameter

12

Field

Value

Type

Reference

Notes

13
14

Identifier

ActionCode
IMPLICIT OCTET STRING

6.5.1.2

Length

variable octets

6.5.1.1

15
16
17

Contents

18

19

20
21
22

octet

Action

Notes

23

Notes:

24
25

a. Ignore extra octets, if received. Send only defined (or significant) octets.

26
27
28
29
30

Table 8-31:

ActionCode value
Action (octet 1)

31

Decimal value

32

33
34
35

21

Meaning

Do Not Wait For MS User Level Response.

36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-28

2.3.2 Parameter Denitions

ANSI/J-STD-036-B

2.3.2.2

CDMAMobileCapabilities

1
2

The CDMAMobileCapabilities (CDMAMC) parameter identifies the general capabilities of a


CDMA mobile.

3
4
5

Table 8-32:

CDMAMobileCapabilities

6
7

Field

Value

Identifier
Length

Type

Reference

CDMAMobileCapabilities
IMPLICIT OCTET STRING

6.5.1.2

variable octets

6.5.1.1

Notes

9
10
11
12

Contents
H

13

Reserved

octet

Notes

MIPLI

14
15
16
17
18
19

Notes:

20

a. Reserved bits shall be ignored on receipt and set to zero on sending.


b. Ignore extra octets, if received. Send only defined (or significant) octets.
Table 8-33:

21
22
23
24

CDMAMobileCapabilities value

25

Mobile Initiated Position Location Indicator (MIPLI) (octet 1, bit A)

26
27

Decimal value

Meaning

28

No MS-initiated position determination.

29

MS-initiated position determination.

30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.3.2 Parameter Denitions

8-29

ANSI/J-STD-036-B

2.3.2.3

CDMAPSMMCount (CPSMC)

The CDMAPSMMCount parameter indicates how many CDMA Pilot Strength Measurements to
collect.

3
4
5
6

Table 8-34:

CDMAPSMMCount parameter

Field

8
9

Value

12
13
14
15
16

Reference

Identifier

CDMAPSMMCount
IMPLICIT INTEGER

6.5.1.2

Length

1 octet

6.5.1.1

10
11

Type

Notes

Contents
H

PSMMCount

octet

Notes

17
18
19
20

Notes:
a. Include the number of CDMA Pilot Strength Measurements to return.

21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-30

2.3.2 Parameter Denitions

ANSI/J-STD-036-B

2.3.2.4

CDMAPSMMList (CPSML)

1
2

The CDMAPSMMList parameter contains a list of pilot strength measurements.

3
4

Table 8-35:

CDMAPSMMList parameter

5
6

Field
Identifier
Length

Value

Type

Reference

CDMAPSMMList
IMPLICIT SET OF

6.5.1.2

variable octets

6.5.1.1

Notes

7
8
9
10
11

Contents

12

CDMAServingOneWayDelay2

6.5.2.gd

CDMATargetMAHOList

6.5.2.43

CDMATargetMAHOList

6.5.2.43

13
14
15

16
17

18
19

Notes:
a. Optionally include additional CDMATargetMAHOList parameters, in order of arrival.

20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.3.2 Parameter Denitions

8-31

ANSI/J-STD-036-B

2.3.2.5

CDMAServingOneWayDelay2

The CDMAServingOneWayDelay2 (CDMASOWD2) parameter specifies the estimated one-way


delay from the MS to a serving base station. The estimated delay can be converted to the estimated
distance. The estimate can be used to minimize the search and acquisition times for the MS or for
other positioning applications. The estimated one way delay between the MS and the associated base
station is specified in units of 100 ns unless otherwise specified by the Resolution field. The valid
values for CDMA Serving One Way Delay field are 0 through 65535.

3
4
5
6
7
8
9

The One Way Delay Time Stamp is a 16-bit binary number derived from the serving base stations
64-bit System Time at the time that the One Way Delay was measured. The time stamp is expressed
in units of 80ms.

10
11
12
13
14
15
16
17
18
19

Table 8-36:

CDMAServingOneWayDelay2 parameter
Field

Value

Reference

Identifier

CDMAServingOneWayDelay2
IMPLICIT OCTET STRING

6.5.1.2

Length

variable octets

6.5.1.1

20
21

Type

Notes

22
23

Contents

24
25
26
27

octet

MSB

Notes

1
CDMA Serving One Way Delay

28

LSB

29

Reserved

30

Resolution

b, c

31
32

MSB

4
ServingOneWayDelayTimeStamp

33

d
LSB

34

35

5
n

36
37

Notes:

38
39
40
41
42
43
44
45

a. The minimum length is two octets.


b. Reserved bits shall be ignored on receipt and set to zero on sending.
c. Include for positioning applications (e.g., J-STD-036).
d. Include if required for the position technology.
e. Ignore extra octets, if received. Send only defined (or significant) octets.

46
47

Resolution (octet 3, bits A-B)

48

Decimal Value

Meaning

49
50
51
52
53
54
55
56

100 nsec.

50 nsec.

1/ CDMA PN Chip.
16

Reserved.

57
58
59
60

8-32

2.3.2 Parameter Denitions

ANSI/J-STD-036-B

2.3.2.6

CDMATargetMAHOInformation

1
2

This parameter is defined in ANSI-41.

3
4

The CDMATargetMAHOInformation (CDMAMAHO) parameter specifies CDMA target cell


information which is used in the handoff process. This parameter is also used for position determination to report the pilot measurements visible to the MS.

5
6
7
8

Table 8-37:

CDMATargetMAHOInformation parameter

9
10

Field

Value

Identifier
Length

Type

Reference

CDMATargetMAHOInformation
IMPLICIT SEQUENCE

6.5.1.2

variable octets

6.5.1.1

Notes

11
12
13
14
15

Contents

16
17

TargetCellID

6.5.2.148

CDMAPilotStrength

6.5.2.35

19

CDMATargetOneWayDelay

6.5.2.46

20

MSCID(Target)

6.5.2.82

18

21

22

23
24

Notes:
a. For position determination, include if target cell is not in serving MSC.
b. Ignore unexpected parameters, if received.

25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.3.2 Parameter Denitions

8-33

ANSI/J-STD-036-B

2.3.2.7

DTXIndication

The DTXIndication (DTXIND) parameter specifies if an MS is currently operating in the discontinuous transmission (DTX) mode.

3
4
5
6

Table 8-38:

DTXIndication parameter

7
8
9

Field

Value

Identifier
Length

10
11
12

Type

Reference

DTXIndication
IMPLICIT OCTET STRING

6.5.1.2

variable octets

6.5.1.1

Notes

Contents

13
14

15

Reserved

16
17

octet

Notes

DTX

18
19

Notes:

20
21

a. Reserved bits shall be ignored on receipt and set to zero on sending.

22

b. Ignore extra octets, if received. Send only defined (or significant) octets.

23
24
25
26
27

Table 8-39:

DTXIndication value
Discontinuous Transmission (DTX) (octet 1, bit A)

28

Decimal value

Meaning

29

Discontinuous Transmission mode is not active

Discontinuous Transmission mode is active

30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-34

2.3.2 Parameter Denitions

ANSI/J-STD-036-B

2.3.2.8

GeneralizedTime

1
2

The GeneralizedTime (GTIME) parameter specifies a time-of-day, day-of-month, month and year
for identification purposes. It is always specified in UTC (Coordinated Universal Time).

3
4
5

Table 8-40:

GeneralizedTime parameter

6
7

Field

Value

Identifier
Length

Type

Reference

GeneralizedTime
IMPLICIT OCTET STRING

6.5.1.2

variable octets

Notes

9
10
11

6.5.1.1

12

Contents
H

13

octet

Notes

14
15

Year-2000

Month

Day of Month

19

20

MSB
Time of Day

5
LSB

16
17
18

21

22
23

24

25
26

Notes:

27

a. The Time of Day field specifies time as a number of tenths of seconds past midnight
Coordinated Universal Time (UTC). The range of this field is 0 to 863,999 (24 hours times
60 minutes per hour times 60 seconds per minute times 10 tenths per second minus 1).
b. Ignore extra octets, if received. Send only defined (or significant) octets.

28
29
30
31
32
33

Table 8-41:

GeneralizedTime value

34
35

Year (octet 1)

36
37

Decimal value

Meaning

0 through 255

Year-2000 Calculated as (current year - 2000) modulus 256


(e.g., year 2002 will be represented as (2002-2000) mod 256 =
2 and year 2260 as 4).

38
39
40
41

Month (octet 2)

42
43

Decimal value

Meaning

1 through 12

Month (e.g., January = 1; December = 12).

44
45
46

Day of Month (octet 3)

47

Decimal value

Meaning

1 through 31

Day of Month (e.g.,1st day of month = 1).

48
49
50

Time of Day (octets 4 through 6)

51

Decimal value

Meaning

52

0 through 863,999

Time of Day (time expressed in tenths of seconds minus 1).

53
54
55
56
57
58
59
60

2.3.2 Parameter Denitions

8-35

ANSI/J-STD-036-B

2.3.2.9

GenericDigits

The GenericDigits (GDP) carries routing digits to be included into the Generic Digits parameter of
the outgoing trunk.

3
4
5
6

Table 8-42:

GenericDigits parameter

7
8
9

Field

Value

Identifier
Length

10
11
12
13
14
15

Type

Reference

Notes

GenericDigits
IMPLICIT DigitsType

6.5.1.2

variable octets

6.5.1.1

Contents
H

octet

Notes

16

Type of Digits

17

Nature of Number

d, e

18

Numbering Plan

19

Encoding

Number of Digits

20
21
22
23

2nd BCD Digit

1st BCD Digit

4th BCD Digit

3rd BCD Digit

24

25

nth

26

n-1st

BCD Digit

BCD Digit

27
28
29
30
31
32
33
34
35
36

Notes:
a. Refer to the DigitsType parameter type (see 6.5.3.2) for notes and field encoding.
b. The Type of Digits field is set as applicable.
c. The Nature of Number field is set as applicable.
d. The Numbering Plan field is set to Telephony Numbering.
e. The Encoding field is set to BCD.

37
38

f. The Number of Digits is between 0 and at least 15.

39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-36

2.3.2 Parameter Denitions

ANSI/J-STD-036-B

2.3.2.10

GeographicPosition

1
2

The GeographicPosition (GEOPOS) parameter specifies position in latitude and longitude coordinates (e.g., reference WGS-84).

3
4
5

The FCC mandate (Docket 94-102) requires the MS latitude and longitude. In addition, confidence
level (including uncertainty) of the geodetic position is required per agreement with Public Safety.
At a minimum, in order to provide the required fields the Type of shape field values recommended
to be supported are:

6
7
8
9
10

a. Ellipsoid point: meets minimum requirement of FCC Docket 94-102.

11

b. Ellipsoid point with uncertainty: meets minimum requirement of FCC Docket 94-102, plus
the minimum requirement of the Public Safety confidence agreement.
Table 8-43:

Value

Identifier
Length

13
14
15

Geographic Position parameter


Field

12

16

Type

Reference

GeographicPosition IMPLICIT
OCTET STRING

6.5.1.2

variable octets

6.5.1.1

Notes

17
18
19
20
21
22

Contents

23

Calling Geodetic Location (CGL)

octet

Notes

24
25
26
27

28
29
30

Notes:

31

a. See T1.628 CallingGeodeticLocation TCAP parameter for encoding.


b. Ignore extra octets, if received. Send only defined (or significant) octets.

32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.3.2 Parameter Denitions

8-37

ANSI/J-STD-036-B

2.3.2.11

LCS_Client_ID

The LCS_Client_ID (LCSCID) identifies an LCS Client. The following variant is used for SAMPS.

3
4
5

Table 8-44:

LCS_Client_ID Parameter

6
7
8

Field

Value

Identifier
Length

9
10
11
12
13

Type

Reference

Notes

LCS_Client_ID IMPLICT Digits


Type

6.5.1.2

Variable Octets

6.5.1.1

Contents
H

14
15
16
17

octet

Notes

Type of Digits

a,b

Nature of Number

Numbering Plan

d,e

Number of Digits

Encoding

1st IA5 Character

22

2nd IA5 Character

23

Last IA5 Character

18
19
20
21

24
25
26
27

Notes:

28
29

a. See the DigitsType parameter Type (see 6.5.3.2) for notes and field encoding.

30
31
32

b. Type of Digits is ignored on receipt


c. The Nature of Number field may be National or International.

33
34
35
36
37
38
39

d. Numbering Plan shall be not applicable for this parameter variant (i.e., SAMPS).
e. The encoding field is set to IA5 for this parameter variant (i.e., SAMPS).
f. The Number of Digits ranges from 0 to 129.
g. A PSAP LCS Client ID shall always start with the characters E911

40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-38

2.3.2 Parameter Denitions

ANSI/J-STD-036-B

2.3.2.12

MobileCallStatus

1
2

The MobileCallStatus (MCALSTAT) parameter identifies the validation status of the MSs
subscription or the access status of an MS for a particular call origination.

3
4
5

Table 8-45:

MobileCallStatus parameter

6
7

Field

Value

Identifier
Length

Type

Reference

MobileCallStatus
IMPLICIT OCTET STRING

6.5.1.2

variable octets

Notes

9
10
11

6.5.1.1

12

Contents
H

13

Authorization

Authentication

octet

Notes

1
n

14
15
16

17
18
19

Notes:

20

a. Ignore extra octets, if received. Send only defined (or significant) octets.

21
22

Table 8-46:

23

MobileCallStatus value

24

Authentication (octet 1, bits A-D)

25

Decimal Value

Meaning

26

Authentication not performed. Authentication has not yet


occurred or the MS is not capable of authentication.

27

Authentication successful. Authentication has successfully


occurred on the MS.

Authentication failure. An authentication failure has occurred


on the MS.

3 through 15

Reserved. Treat the same as value 0, Authentication not


performed.

28
29
30
31
32
33
34
35
36
37

Authorization (octet 1, bits E-H)

38

Decimal Value

Meaning

39

Authorization not performed.

40

Authorization successful.

Invalid Electronic Serial Number (ESN).

Unassigned Directory Number (DN).

Duplicate Unit.

Delinquent Account.

Stolen Unit.

49

Not authorized for MSC.

51

Unspecified. If any other value of AuthorizationDenied is


received.

9 through 15

Reserved. Treat the same as value 0, Authorization not


performed.

41
42
43
44
45
46
47
48

50

52
53
54
55
56
57
58
59
60

2.3.2 Parameter Denitions

8-39

ANSI/J-STD-036-B

2.3.2.13

MobilePositionCapability

The MobilePositionCapability (MPCAP) parameter indicates the type of geographic position information the MS can provide to the network.

3
4
5
6

Table 8-47:

MobilePositionCapability parameter

Field

Value

Type

Reference

Identifier

MobilePositionCapability IMPLICIT
OCTET STRING

6.5.1.2

Length

variable octets

6.5.1.1

8
9
10
11
12

Notes

Contents

13
14

octet

Notes

15
16
17

Mobile Position Capability

Mobile Position Capability

18
19
20

Notes:

21
22

a. Include additional Mobile Position Capability values when a complete set of positioning
capabilities is required to be specified.

23
24

b. Ignore extra octets, if received. Send only defined (or significant) octets.

25
26
27
28

Table 8-48:

MobilePositionCapability value

29

Mobile Position Capability (octet 1)

30

Decimal value

Meaning

Undefined Mobile Position Capabilities.

CDMA None.

CDMA Pilot Phase + GPS. MS shall be capable of supporting A-FLT


and GPS for position determination.

CDMA Pilot Phase Only. MS shall be capable of supporting A-FLT only


for position determination.

CDMA GPS Only. MS shall be capable of supporting GPS only for


position determination.

5 through 50

Reserved for CDMA. Treat the same as value 1, CDMA None.

51

TDMA None. See TIA/EIA-136-740.

52

TDMA MS-Based with Network Assistance SAMPS Supported. See


TIA/EIA-136-740.

53

TDMA MS-Assisted SAMPS Supported. See TIA/EIA-136-740.

54

TDMA SAMPS Time Measurement Capability Supported. See TIA/


EIA-136-740.

55

TDMA MS-Based Stand-alone SAMPS Supported. See TIA/EIA-136740.

unassigned values
through 100

Reserved for TDMA. Treat the same as value 51, TDMA None.

101

AMPS None.

102

AMPS MS-based. MS shall be capable of autonomously determining


the position without assistance from the network.

31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-40

2.3.2 Parameter Denitions

ANSI/J-STD-036-B

Table 8-48:

MobilePositionCapability value (Continued)

1
2

Mobile Position Capability (octet 1)

103

AMPS assisted GPS. MS shall be capable of utilizing network assistance in providing GPS satellite measurements for position determination in the network or of utilizing network assistance in position
determination in the MS.

104 through 150

Reserved for AMPS. Treat the same as value 101, AMPS None.

151 through 223

Reserved. Treat the same as value 0, Undefined.

10

224 through 255

Reserved for ANSI-41 protocol extension. If unknown, treat the same as


value 0, Undefined.

5
6
7

11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.3.2 Parameter Denitions

8-41

ANSI/J-STD-036-B

2.3.2.14

MobInfo_AMPS

The MobInfo_AMPS (AMPS Analog Mobile Information) is a collection of information needed to


determine the position of an MS that is currently operating in the AMPS analog mode. The
MobInfo_AMPS macro has been defined solely for editorial convenience, and does not affect the
encoding in any way.

3
4
5
6
7
8

Table 8-49:

MobInfo_AMPS Macro

9
10

MobInfo_AMPS

11

Type

Reference

ChannelData (Serving)

6.5.2.47

DTXIndication

6.5.2.fg

ReceivedSignalQuality

6.5.2.106

12
13

Contents

14
15
16
17
18
19
20
21

Notes

Notes:
a. Include if known and applicable.

22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-42

2.3.2 Parameter Denitions

ANSI/J-STD-036-B

2.3.2.15

MobInfo_CDMA

1
2

The MobInfo_CDMA (CDMA Mobile Information) is a collection of information needed to


determine the position of an MS that is currently operating in the CDMA mode. The
MobInfo_CDMA macro has been defined solely for editorial convenience, and does not affect the
encoding in any way.

3
4
5
6
7

Table 8-50:

MobInfo_CDMA Macro

8
9

MobInfo_CDMA

10

Type

Reference

Notes

Contents

11
12
13
14

CDMAChannelData (Serving)

6.5.2.30

CDMACodeChannel

6.5.2.31

CDMAMobileCapabilities

6.5.2.xx

CDMAPrivateLongCodeMask

6.5.2.36

CDMAServingOneWayDelay2

6.5.2.gd

CDMAServiceOption

6.5.2.f

22

CDMATargetMAHOList

6.5.2.43

23

CDMAPSMMList

6.5.2.gc

15
16
17
18
19
20
21

24
25
26

Notes:

27

a. Include if known and applicable.

28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.3.2 Parameter Denitions

8-43

ANSI/J-STD-036-B

2.3.2.16

MobInfo_NAMPS

The MobInfo_NAMPS (NAMPS Mobile Information) is a collection of information needed to


determine the position of an MS that is currently operating in the NAMPS mode. The
MobInfo_NAMPS macro has been defined solely for editorial convenience, and does not affect the
encoding in any way.

3
4
5
6
7
8

Table 8-51:

MobInfo_NAMPS Macro

9
10

MobInfo_NAMPS

11

Type

Reference

ChannelData (Serving)

6.5.2.47

NAMPSChannelData (Serving)

6.5.2.86

DTXIndication

6.5.2.fg

ReceivedSignalQuality

6.5.2.106

12
13
14
15
16
17
18
19

Notes

Contents

20
21
22
23

Notes:
a. Include if known and applicable.

24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-44

2.3.2 Parameter Denitions

ANSI/J-STD-036-B

2.3.2.17

MobInfo_TDMA

1
2

The MobInfo_TDMA (TDMA Mobile Information) is a collection of information needed to


determine the position of an MS that is currently operating in the TDMA mode. The
MobInfo_TDMA macro has been defined solely for editorial convenience, and does not affect the
encoding in any way.

3
4
5
6
7

Table 8-52:

MobInfo_TDMA Macro

8
9

MobInfo_TDMA

10

Type

Reference

Notes

Contents

11
12
13
14

TDMAChannelData

6.5.2.153

DTXIndication

6.5.2.fg

ReceivedSignalQuality

6.5.2.106

TargetMeasurementList

6.5.2.150

TDMA_MAHO_CELLID

2.3.2.26

TDMA_MAHO_CHANNEL

2.3.2.27

22

TDMA_TimeAlignment

2.3.2.29

23

VoicePrivacyMask

6.5.2.166

15
16
17
18
19
20
21

24
25
26

Notes:

27

a. Include if known and applicable.

28
29

b. Include if MAHO measurements identified by cell id will be used to assist with mobile
positioning.
c. Include if MAHO measurements identified by channel number will be used to assist with
mobile positioning.
d. This parameter will be included as a result of a preceding MAHO information request.

30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.3.2 Parameter Denitions

8-45

ANSI/J-STD-036-B

2.3.2.18

NetworkTMSI

This parameter is defined in ANSI-41.

3
4

The NetworkTMSI (NETMSI) consists of the TMSI_CODE and the TMSI_ZONE fields.
TMSI_CODE defines a 32-bit MS temporary identification in one TMSI Zone. The TMSI_ZONE
is associated with a group of cell sites (e.g., cell sites associated with a single MSC) such that all
TMSI_CODEs assigned to MSs within the TMSI_ZONE are unique. TMSI_CODEs may be re-used
in different TMSI zones.

5
6
7
8
9
10

The minimum length of this parameter is 4 octets.

11
12
13

Table 8-53:

NetworkTMSI parameter

14
15
16

Field

Value

Identifier
Length

17
18
19

Type

Reference

NetworkTMSI
IMPLICIT OCTET STRING

6.5.1.2

variable octets

6.5.1.1

Notes

Contents

20
21

22

MSB

23

octet

Notes

24

TMSI_CODE

25

26
27

LSB

28

29

1st Digit of TMSI_ZONE

Type of Addressing

30

3rd Digit of TMSI_ZONE

2nd Digit of TMSI_ZONE

5th Digit of TMSI_ZONE

4th Digit of TMSI_ZONE

nth Digit of TMSI_ZONE

nth-1 Digit of TMSI_ZONE

b, c

31
32
33
34
35
36

Notes:

37
38

a. See CDMA and TDMA for the encoding details of this field.

39

b. The encoding scheme of the address digits is BCD encoding.

40
41

c. Where there is an odd number of digits, the nth digit is set to filler.

42
43
44
45
46

Table 8-54:

NetworkTMSI value
Type of Addressing (octet 5, bits A-D)

47

Decimal value

Meaning

48

Not used

E.212 based routing.

20-bit TDMA TMSI. TMSI_ZONE contains a single digit 0.


Most significant 12 bits of TMSI_CODE are set to zero.

24-bit TDMA TMSI. TMSI_ZONE contains a single digit 0.


Most significant 8 bits of TMSI_CODE are set to zero.

4 through 15

Reserved for ANSI-41 protocol extension. If unknown, treat the


same as value 0, Not used.

49
50
51
52
53
54
55
56
57
58
59
60

8-46

2.3.2 Parameter Denitions

ANSI/J-STD-036-B

2.3.2.19

PositionInformation

1
2

The PositionInformation (POSINFO) parameter is used to carry the timeposition pair used to locate
an MS.

3
4
5

Table 8-55:

PositionInformation

6
7

Field

Value

Identifier
Length

Type

Reference

PositionInformation
IMPLICIT SET

6.5.1.2

variable

Notes

8
9
10
11

6.5.1.1

12

Contents

13

GeneralizedTime

6.5.2.fi

14

GeographicPosition

6.5.2.fk

16

PositionSource

6.5.2.fu

15

17

a
b

18
19
20

Notes:
a. Shall be included, if known.
b. Ignore unexpected parameters, if received.

21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.3.2 Parameter Denitions

8-47

ANSI/J-STD-036-B

2.3.2.20

PositionRequestType

The PositionRequestType (POSREQTYPE) parameter indicates whether the initial or recent


position information for the MS is being requested.

3
4
5
6

Table 8-56:

PositionRequestType parameter

7
8
9

Field

Value

Identifier
Length

10
11
12

Type

Reference

PositionRequestType
IMPLICIT OCTET STRING

6.5.1.2

variable octets

6.5.1.1

Notes

Contents

13
14

15

16

octet

Position Request Type

17
18
19

Notes

Notes:

20
21

a. Ignore extra octets, if received. Send only defined (or significant) octets.

22
23

Table 8-57:

PositionRequestType value

24
25

Position Request Type (octet 1, bits A through H)

26

Decimal Value

Meaning

Not used.

Initial position. Return position of the calling MS at the time of


emergency services call initiation. Return updated position
only if initial position is unavailable. Interim position may also
be returned if initial position is not available in time for routing.

Return the updated position.

Return the updated or last known position.

Reserved for ESP interface. Treat the same as value 0, Not


used.

Initial position only. Return position of the calling MS at the


time of emergency services call initiation. Return updated
position only if initial position is unavailable. Do not return
interim position.

values through 95

Reserved. Treat the same as value 1, Initial position.

96 through 255

Reserved for ANSI-41 protocol extension. If unknown, treat the


same as value 1, Initial position.

27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-48

2.3.2 Parameter Denitions

ANSI/J-STD-036-B

2.3.2.21

PositionResult

1
2

The PositionResult (POSRSULT) parameter indicates the results (e.g., type of success or failure) of
an associated position request.

3
4
5

Table 8-58:

PositionResult parameter

6
7

Field

Value

Identifier
Length

Type

Reference

PositionResult
IMPLICIT OCTET STRING

6.5.1.2

variable octets

Notes

9
10
11

6.5.1.1

12

Contents
H

13

octet

Position Result

Notes

14
15
16

17
18
19

Notes:

20

a. Ignore extra octets, if received. Send only defined (or significant) octets.

21
22

Table 8-59:

23

PositionResult value

24

Position Result (octet 1)

25

Decimal Value

Meaning

26

Not used.

Initial position returned.

29

Updated position returned.

31

Last known position returned.

Requested position is not available.

Caller disconnected. No call in progress for caller identified.

Caller has handed-off. Position is unavailable due to a hand-off


(e.g., handoff to a position incapable system).

27
28

30

32
33
34
35
36
37
38
39

Identified MS is inactive or has roamed to another system.

Unresponsive.

Identified MS is responsive, but refused position request.

10

System Failure.

11

MSID is not known.

12

Callback number is not known.

13

Improper request (e.g., invalid channel information, invalid ESN).

14

Mobile channel information returned.

15

Signal not detected.

16

PDE Timeout.

53

17

Position pending.

55

18

TDMA MAHO Information Returned.

19

TDMA MAHO Information is not available.

40
41
42
43
44
45
46
47
48
49
50
51
52

54

56
57
58
59
60

2.3.2 Parameter Denitions

8-49

ANSI/J-STD-036-B

Table 8-59:

PositionResult value (Continued)

2
3
4
5

Position Result (octet 1)


values through
223

Reserved. Treat the same as value 0, Not used.

6
7
8

224 through 255 Reserved for ANSI-41 protocol extension. If unknown, treat the same as
value 0, Not used.

9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-50

2.3.2 Parameter Denitions

ANSI/J-STD-036-B

2.3.2.22

PositionSource

1
2

The PositionSource (POSOUR) parameter specifies how the geographic position information was
obtained.

3
4
5

Table 8-60:

PositionSource parameter

6
7

Field

Value

Identifier
Length

Type

Reference

PositionSource
IMPLICIT OCTET STRING

6.5.1.2

variable octets

Notes

9
10
11

6.5.1.1

12

Contents
H

13

Position Source

octet

Notes

14
15
16
17
18
19

Table 8-61:

PositionSource value

20
21

Position Source (octet 1)

22
23

Decimal value

Meaning

Not used

Network Unspecified

Network AOA (Angle of Arrival)

Network TOA (Time of Arrival)

29

Network TDOA (Time Difference of Arrival)

31

Network RF Fingerprinting

Network Cell/Sector

Network Cell/Sector with Timing

values up to 15

Undefined. Treat as value 1 (Network Unspecified)

16

Handset Unspecified

17

Handset GPS

18

Handset AGPS (Assisted GPS)

19

Handset EOTD (Enhanced Observed Time Difference)

20

Handset AFLT (Advanced Forward Link Trilateration)

21

Handset EFLT (Enhanced Forward Link Trilateration)

46

values up to 31

Undefined. Treat as value 16 (Handset Unspecified)

48

32

Hybrid Unspecified.

49

33

Hybrid AGPS/AFLT. Positioning based on the combination of


AFLT and AGPS measurements.

51

34

Hybrid AFLT/Cell-Sector. Positioning based on combining


information from multiple cells or sectors.

53

35

Hybrid Network TDOA/AOA. Positioning based on the


combination of TDOA and AOA measurements.

55

36

Hybrid Network TDOA/A-GPS. Positioning based on the


combination of TDOA and Assisted GPS measurements.

24
25
26
27
28

30

32
33
34
35
36
37
38
39
40
41
42
43
44
45

47

50

52

54

56
57
58
59
60

2.3.2 Parameter Denitions

8-51

ANSI/J-STD-036-B

Table 8-61:

PositionSource value (Continued)

2
3
4
5
6
7
8

Position Source (octet 1)


37

Hybrid Network TDOA/A-GPS/AOA. Positioning based on


the combination of TDOA, AGPS and AOA measurements.

values up to 47

Undefined. Treat as value 32 (Hybrid Unspecified)

48 (See Note-a)

Class of Service Unspecified

49 (See Note-a)

Class of Service WRLS. E911 Phase I only deployment. No


positioning fix available.

50 (See Note-a)

Class of Service WPH1. E911 Phase I fallback for Phase II


deployment.

51 (See Note-a)

Class of Service WPH2. E911 Phase II with callers location.

values up to 63 (See
Note-a)

Undefined. Treat as value 48 (Class of Service Unspecified)

Other values

Treat as value 0 (Not used)

9
10
11
12
13
14
15
16
17
18
19
20

Notes:

21
22

a. These values are only applicable to the E2 interface.

23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-52

2.3.2 Parameter Denitions

ANSI/J-STD-036-B

2.3.2.23

Profile

1
2

This macro is defined in ANSI-41.

3
4

The Profile is a collection of the subscribers calling profile information. This information is a list
of optional parameters. The Profile macro has been defined solely for editorial convenience, and
does not affect the encoding in any way.

5
6
7
8

Table 8-62:

Profile Macro

9
10

PROFILE

11

Type

Reference

Notes

12
13

Contents

14

AuthenticationCapability

6.5.2.8

CallingFeaturesIndicator

6.5.2.20

CarrierDigits

6.5.2.28

DMH_AccountCodeDigits

6.5.2.59

DMH_AlternateBillingDigits

6.5.2.60

21

DMH_BillingDigits

6.5.2.61

22

GeographicAuthorization

6.5.2.68

24

MessageWaitingNoticationCount

6.5.2.78

25

MessageWaitingNoticationType

6.5.2.79

MobileDirectoryNumber

6.5.2.80

MobilePositionCapability

6.5.2.fm

OriginationIndicator

6.5.2.89

OriginationTriggers

6.5.2.90

PACAIndicator

6.5.2.91

PreferredLanguageIndicator

6.5.2.96

RestrictionDigits

6.5.2.113

37

RoutingDigits

6.5.2.114

38

SMS_OriginationRestrictions

6.5.2.136

40

SMS_TerminationRestrictions

6.5.2.138

41

SPINIPIN

6.5.2.139

SPINITriggers

6.5.2.140

TerminationRestrictionCode

6.5.2.157

TerminationTriggers

6.5.2.159

15
16
17
18
19
20

23

26
27
28
29
30
31
32
33
34
35
36

39

42
43
44
45
46
47
48
49

Notes:

50

a. Include on IS-41-C or later.

51

b. Include to identify feature authorization and activity.


c. Include if preferred carrier is applicable and TransactionCapability supported.
d. Include if available for recording purposes (see DMH).
e. Include if available for certain authorization restricted areas.

52
53
54
55
56
57
58
59
60

2.3.2 Parameter Denitions

8-53

ANSI/J-STD-036-B

1
2

f. Include if MessageWaitingNotificationType is MessageWaitingNotificationType:


Message Waiting Indication and number of messages waiting is authorized.

3
4
5

g. Include if Message Waiting Notification feature is active and a message is waiting.


h. Include to indicate the type of calls allowed for origination service.

6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

i. Include to indicate OriginationRequest triggers.


j. Include to identify the PACA feature.
k. Include to identify the Preferred Language feature.
l. Include if originations are restricted to NPA-NXX or NPA-NXX-XXXX and TransactionCapability supported.
m. Include for special routing information.
n. Include for MS originated Short Message Service.
o. Include for MS terminated Short Message Service.
p. Include if local SPINI operation supported.
q. Include to indicate Subscriber PIN Intercept triggers.

21
22
23

r. Include to indicate the type of call termination service.


s. Include to indicate the RedirectionRequest or TransferToNumberRequest triggers.

24
25

t. Include to identify MS position capabilities, if applicable.

26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-54

2.3.2 Parameter Denitions

ANSI/J-STD-036-B

2.3.2.24

ServiceIndicator

1
2

This parameter is defined in ANSI-41.

3
4

The ServiceIndicator (SRVIND) parameter indicates a type of service.

5
6

Table 8-63:

ServiceIndicator parameter
Field

Value

Identifier
Length

Type

Reference

ServiceIndicator
IMPLICIT OCTET STRING

6.5.1.2

variable octets

Notes

9
10
11
12

6.5.1.1

13

Contents
H

14

octet

Notes

15
16

Service

17

18
19

Notes:
a. Ignore extra octets, if received. Send only defined (or significant) octets.
Table 8-64:

20
21
22
23

ServiceIndicator value

24
25

Service (octet 1)

26

Decimal value

Meaning

27

Undefined Service.

28

CDMA OTASP Service.

TDMA OTASP Service.

CDMA OTAPA Service.

CDMA Position Determination Service.

AMPS Position Determination Service.

36

6 through 223

Reserved. Treat the same as value 0, Undefined Service.

37

224 through 255

Reserved for IS-41 protocol extension. If unknown, treat the


same as value 0, Undefined Service.

39

29
30
31
32
33
34
35

38

40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.3.2 Parameter Denitions

8-55

ANSI/J-STD-036-B

2.3.2.25

SMS_TeleserviceIdentifier

This parameter is defined in ANSI-41.

3
4
5
6

Table 8-65:

SMS_TeleserviceIdentifier values

SMS_TeleserviceIdentier (octets 1 and 2)

Decimal value

Meaning

32520

TDMA System Assisted Mobile Positioning through Satellite


(SAMPS).

32584

TDMA Segmented System Assisted Mobile Positioning


Service.

9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-56

2.3.2 Parameter Denitions

ANSI/J-STD-036-B

2.3.2.26

TDMA_MAHO_CELLID

1
2

Provides a list of TDMA MAHO measurements with each identified by the MSC and Cell from
which it was obtained.

3
4
5

Table 8-66:

TDMA_MAHO_CELLID parameter

6
7

Field

Value

Identifier
Length

Type

Reference

TDMA_MAHO_CELLID
IMPLICIT OCTET STRING

6.5.1.2

variable octets

6.5.1.1

Notes

9
10
11
12

Contents
H

13

Serving Cell
HYPER

RSVD

Serving Cell RSSI

octet

Notes

a,b,c

14
15
16
17

Number of RSSI
HYPER

RSVD

RSSI

b,c,

4
MEASURED CELLID

18
19
20
21

22
23

Number of MSCs

x+1

24
25
26

x+2
x+3

MSCID

27

28
29

x+4
Number of RSSI
HYPER

RSVD

RSSI

30

x+5

x+6

b,c

32

x+7
MEASURED CELLID

x+8

31

33
34

35
36

37
38
39
40

Notes:

41

a. RSSI information on octet 1 corresponds to the Serving Cell, as measured in the Digital
Traffic Channel
b. RSSI is the signal strength value, encoded as for TDMA (TIA/EIA-136-133).

42
43
44
45
46

c. HYPER identifies the hyperband (00 for 800 MHz, 01 for 1900 MHz, other values
reserved).

47

d. The number of RSSI measurements included for the Serving MSC

49

48

50

e. Encoded in the same way as the value of the ANSI-41 Target CellID and ServingCellID
parameters.
f. Octets 3 through 5, inclusive, may be repeated as many times as necessary to convey the
number of TDMA MAHO measurements from the serving MSC, identified by octet 2. The
value of x will be equal to 2 plus (3 times value of octet 2). Octets 6 through x are only
present if the value of octet 2 is greater than one.

51
52
53
54
55
56
57

g. The number of MSCs from which RSSI information was obtained.

58
59
60

2.3.2 Parameter Denitions

8-57

ANSI/J-STD-036-B

h. Encoded in the same way as the value of the ANSI-41 MSCID parameter.

2
3
4
5
6
7
8

i. The number of RSSI measurements included for this MSCID.


j. Octets x+6 through x+8, inclusive, may be repeated as many times as necessary to convey
the number of TDMA MAHO measurements identified in octet x+5, all from the same
MSC identified by octets x+2 through x+4. The value of y will be equal to x+5 plus (3 times
the value of octet x+5). Octets x+9 through y are only present if the value of octet x+5 is
greater than one.

9
10
11
12

k. Octets x+2 through y, inclusive, may be repeated as many times as necessary to convey
distinct sets of TDMA MAHO measurements from the number of MSCID s identified by
octet x+1.

13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-58

2.3.2 Parameter Denitions

ANSI/J-STD-036-B

2.3.2.27

TDMA_MAHO_CHANNEL

1
2

Provides a list of TDMA MAHO measurements with each identified by the MSC and Channel
Number from which it was obtained.

3
4
5

Table 8-67:

TDMA_MAHO_CHANNEL parameter

6
7

Field

Value

Identifier
Length

Type

Reference

TDMA_MAHO_CHANNEL
IMPLICIT OCTET STRING

6.5.1.2

variable octets

6.5.1.1

Notes

9
10
11
12

Contents
H

13

Serving Cell
HYPER

RSVD

Serving Cell RSSI

octet

Notes

a,b,c

15
16
17

RSSI

b,c,

MEASURED CHANNEL

RSVD

Number of RSSI

14

18
19

HYPER

RSVD

MSB

LSB

21

Number of MSCID

n+1

n+2
n+3

24
25
26
27

n+4

28
29
30

n+5

RSSI

n+6

b,c

MEASURED CHANNEL

n+7

RSVD

n+8

Number of RSSI

22
23

MSCID

20

31
32

HYPER

RSVD

MSB

LSB

33
34

35
36

37
38
39
40

Notes:

41

a. RSSI information in octet 1 corresponds to that for the serving Channel


b. RSSI is the signal strength value, encoded as for TDMA (TIA/EIA-136-133)
c. HYPER identifies the hyperband (00 for 800 MHz, 01 for 1900 MHz, other values
reserved)
d. The number of RSSI measurements included for the Serving MSC.
e. Channel number encoding defined by TDMA
f. Octets 3 through 5, inclusive, may be repeated as many times as necessary to convey the
number of TDMA MAHO measurements from the Serving MSC.

42
43
44
45
46
47
48
49
50
51
52
53

g. The number of MSCs from which RSSI information was obtained.


h. Encoded in the same way as the value of the ANSI-41 MSCID parameter.

54
55
56

i. The number of RSSI measurements included for this MSCID.

57
58
59
60

2.3.2 Parameter Denitions

8-59

ANSI/J-STD-036-B

1
2

j. Octets n+6 through n+8, inclusive, may be repeated as many times as necessary to convey
the number of TDMA MAHO measurements from the same MSC identified by octet n+5.

3
4
5
6

k. Octets n+2 through o, inclusive, may be repeated as many times as necessary to convey
distinct sets of TDMA MAHO measurements from the number of MSCID s identified by
octet 1.

7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-60

2.3.2 Parameter Denitions

ANSI/J-STD-036-B

2.3.2.28

TDMA_MAHORequest

1
2

This parameter (MAHOREQ) is used by an MPC to indicate its request of TDMA MAHO information to an MSC.

3
4
5

Field

Value

Identifier

MAHORequest
IMPLICIT OCTET STRING

1 octet

Length

Type

Reference

Notes

6
7
8

6.5.1.2

9
10
11

6.5.1.1

12

Contents

13
14

octet

Notes

15
16

MAHO Request

17
18
19

Table 8-68:

MAHO Request value

20
21
22

MAHO Request (octet 1)

23

Decimal Value

Meaning

No MAHO information requested.

MAHO information requested.

2 through 255

Reserved. Treat the same as value 0, No MAHO information requested.

24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.3.2 Parameter Denitions

8-61

ANSI/J-STD-036-B

2.3.2.29

TDMA_TimeAlignment parameter

This parameter represents the time advance/retard needed to synchronize the time slot burst transmission of a mobile, based on its distance from the base station.

3
4
5
6

Table 8-69:

TDMA_TimeAlignment parameter

7
8
9

Field

Value

Identifier
Length

10
11
12
13
14
15

Type

Reference

TDMA_TimeAlignment
IMPLICIT OCTET STRING

6.5.1.2

variable octets

6.5.1.1

Notes

Contents
H

G
Reserved

16

Time Alignment Offset (TA)

octet

Notes

a,b

17
18

Notes:

19
20
21
22
23
24

a. The parameter is returned together with either TDMA_MAHO_CHANNEL or


TDMA_MAHO_CELLID
b. See TDMA for encoding of the Time Alignment Offset field. Note: value 11111 should
not be used.

25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-62

2.3.2 Parameter Denitions

ANSI/J-STD-036-B

2.3.2.30

Teleservice_Priority

1
2

This parameter is defined in ANSI-41.

3
4

The Teleservice_Priority (TPRIO) parameter provides an indication of the level of priority of the
teleservice message. The values are given in an increasing order of priority.

5
6
7

Table 8-70:

Teleservice_Priority parameter
Field

Value

Identifier
Length

8
9

Type

Reference

Teleservice_Priority
IMPLICIT OCTET STRING

6.5.1.2

variable octets

Notes

10
11
12
13

6.5.1.1

14

Contents
H

15

Reserved

T_PRIO

octet

Notes

17
18
19
20
21

Notes:

22

a. Reserved bits shall be ignored on receipt and set to zero on sending.


b. Ignore extra octets, if received. Send only defined (or significant) octets.
Table 8-71:

16

23
24
25
26

Teleservice_Priority value

27
28

T_PRIO (octet 1, bits A and B)

29

Decimal value

Meaning

30

Normal (lower priority)

31

Interactive

Urgent

Emergency (higher priority, e.g., E-911)

32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.3.2 Parameter Denitions

8-63

ANSI/J-STD-036-B

2.3.2.31

TransactionCapability

2
3

This parameter is defined in ANSI-41-D.

4
5
6

The TransactionCapability (TRANSCAP) parameter indicates a system s transaction capability at


the current time (i.e., this capability may change over time).

7
8
9
10

Field

Value

Identifier

TransactionCapability
IMPLICIT OCTET STRING

Length

variable octets

11
12

Type

Reference

Notes

6.5.1.2
6.5.1.1

13
14
15
16
17
18

Contents
H

octet

Notes

NAMI

NDSS

UZCI

SPINI

RUI

ANN

BUSY

PROF

OTAPA

S&R

WADDR

TL

a, b

19

Multiple Terminations

Reserved

MAHO

20

Reserved

21
22
23
24

Notes:
a. Reserved bits shall be ignored on receipt and set to 0 on sending.

25
26

b. Ignore extra octets, if received. Send only defined (or significant) octets.

27
28
29

Profile (PROF) (octet 1, bit A)


Value

Meaning

30
31

The system is not capable of supporting the IS-41-C


profile parameters.

The system is capable of supporting the IS-41-C


profile parameters.

32
33
34
35
36
37

Busy Detection (BUSY) (octet 1, bit B)


Value

Meaning

38
39

The system is not capable of detecting a busy


condition at the current time.

The system is capable of detecting a busy condition at


the current time.

40
41
42
43
44
45

Announcements (ANN) (octet 1, bit C)


Value

Meaning

46
47

The system is not capable of honoring the AnnouncementList parameter at the current time.

The system is capable of honoring the AnnouncementList parameter at the current time.

48
49
50
51
52
53
54
55
56

Remote User Interaction (RUI) (octet 1, bit D)


Value

Meaning

The system is not capable of interacting with the user.

The system is capable of interacting with the user.

57
58
59
60

8-64

2.3.2 Parameter Denitions

ANSI/J-STD-036-B

Subscriber PIN Intercept (SPINI) (octet 1, bit E)

2
3

Meaning

Value

0
1

The system is not capable of supporting local SPINI


operation at the current time.
The system is capable of supporting local SPINI
operation.

5
6
7
8
9

UZCapabilityIndicator (UZCI) (octet 1, bit F)


Value
0
1

10

Meaning

11

The system is not capable of supporting the TerminationList parameter at the current time.

13

12

The system is capable of supporting the TerminationList parameter at the current time.

14
15
16
17

NDSS Capability (NDSS) (octet 1 bit G)


Value

18
19

Meaning

20

Serving System is not NDSS capable.

Serving System is NDSS capable.

NAME Capability Indicator (NAMI) (octet 1 bit H)


Value

21
22
23
24
25

Meaning

26

The system is not CNAP/CNAR capable.

The system is CNAP/CNAR capable.

27
28

Multiple Terminations (octet 2, bits A-D)

29
30
31

Value
0

Meaning

32

The system cannot accept a termination at this time


(i.e., cannot accept routing information).

33
34
35

1 through 15

The system supports the number of call legs indicated.

37

TerminationList (TL) (octet 2, bit E)


Value

36

38

Meaning

39

The system is not capable of supporting the TerminationList parameter at the current time.

The system is capable of supporting the TerminationList parameter at the current time.

40
41
42

WIN Addressing (WADDR) (octet 2, bit F)

43
44
45
46

Value

Meaning

47

The system is not capable of supporting the


TriggerAddressList parameter.

The system is capable of supporting the TriggerAddressList parameter.

48
49
50
51
52
53
54
55
56
57
58
59
60

2.3.2 Parameter Denitions

8-65

ANSI/J-STD-036-B

1
2
3

MAHO (octet 3, bit C)


Value

Meaning

4
5

The system is not capable of supporting external


MAHO requests.

The system is capable of supporting external MAHO


requests (e.g., for positioning).

6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-66

2.3.2 Parameter Denitions

ANSI/J-STD-036-B

2.3.3

Parameter Type Definitions

2.3.3.1

Digits Type

1
2
3
4

This parameter type is defined in ANSI-41-D.

5
6
7

Omitted text not changed.

Table 8-72:

Digits Type value

10

Type of Digits (octet 1, bits A-H)

11

Decimal value

Meaning

12

Not Used.

Dialed Number or Called Party Number.

15

Calling Party Number.

17

Caller Interaction.

Routing Number.

Billing Number.

Destination Number.

LATA.

Carrier.

13

ESRD.

all other values

Reserved.

13
14

16

18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2.3.3 Parameter Type Denitions

8-67

ANSI/J-STD-036-B

1
2

ANSI-41 Procedures

3.1

Modification of existing procedures

3
4
5
6

All changes made to the existing ANSI-41 procedures are identified by change bars, additions are underlined
and deletions are struck-through.

7
8
9
10
11
12
13
14

3.1.1

MSC Analyze MS Dialed Number (ANSI-41.6-D 3.2.3, page 6-15)


Upon demand the Anchor MSC shall do the following:
1

15

IF flash privileges are suspended (by the Flash Privileges in the OneTimeFeatureIndicator
parameter e.g., Call Transfer, Call Waiting, Three-Way Calling):

16
17

1-1

Include the TransactionCapability parameter with the number of multiple terminations set
to 0.

18
19

ELSEIF Call Transfer, Three-Way Calling or similar feature is being invoked:

20
21

2-1

Include the TransactionCapability parameter with the number of multiple terminations set
to 1.

22
23

ELSE:

24
25

3-1

Include the TransactionCapability parameter with the number of multiple terminations set
appropriately.

26
27

ENDIF.

IF the call is an Emergency Services call (e.g., 9-1-1 or air interface indication):

28
29
30

5-1

Execute the MSC Initiating an OriginationRequest for an Emergency Services Call task
(see 3.2.1).

31
32
33
34
35
36

ENDIF.

IF the TerminationList parameter was received:

7-1

Process the DestinationDigits of the TerminationList parameter locally, routing the call
with the PSTNTermination as PointOfReturn..

37
38

39

ELSEIF the MS dialed a locally allowed number (e.g., 9-1-1, *-9-1-1, N11, *N11) OR the MSC
received an air interface indication of an Emergency Services Call emergency call:

40
41

8-1

IF the MS dialed number is only routed locally, for instance, for numbers used for access
to local emergency service providers:

42
43

8-1-1

44
45
46

8-2

47

8-2-1

ELSEIF the OriginationTriggers matches the *, # or the count of the dialed number digits:

48
49
50

8-3

51

8-3-1

52
53
54

8-4

55

Process the dialed number locally routing the call with the PreferredLanguageIndicator
to set the PointOfReturn.
Execute the MSC Initiating an Origination Request task (see 4.31.1) to set the
PointOfReturn.
ELSE:
Process the dialed Service Code locally routing the call with the PreferredLanguageIndicator to set the PointOfReturn.
ENDIF.

ELSEIF the OriginationTriggers All trigger is on:

56
57
58

9-1

Execute the MSC Initiating an Origination Request task (see 4.31.1) to set the PointOfReturn.

59
60

8-68

3 ANSI-41 Procedures

ANSI/J-STD-036-B

9-2

IF a Digits (Dialed) parameter is received:

9-2-1

IF the type of the Digits is unknown.

9-2-1-1

Process the dialed number locally to set the PointOfReturn.

9-2-2
9-3

1
2
3
4
5

ENDIF.

ENDIF.

7
8

The remainder of this procedure remains unchanged

9
10

3.1.2

Idle MS Origination (ANSI-41.6-D 3.2.1, page 6-12 and IS-778)

11

When the MS attempts to originate a call, the Serving MSC shall do the following:

13

12

14

IF an appropriate idle voice or traffic channel is available for the identified air interface control
channel, the MSC may pre-seize the channel by:

1-1

Reserve the available voice or traffic channel.

1-2

Order the MS to acquire the reserved voice or traffic channel.

1-3

Verify the MS has properly tuned to this voice or traffic channel.

ENDIF.

IF the MS is not authenticated and authentication is active:

3-1

15
16
17
18
19
20
21
22

IF the MS has authentication capabilities and the MSs AuthenticationCapability indicates


that the MS shall be authenticated1:

23
24
25
26
27

3-1-1

Include the SystemAccessType parameter set to Call origination.

3-1-2

IF the MS is not registered OR the location of the MS has changed since the last registration (i.e., the MS has left the location for which it is geographically authorized):

28
29
30
31

3-1-2-1

Set a pending registration flag for the MS.

3-1-3

ENDIF.

3-1-4

IF a pending registration flag is set for the MS OR the MSC requires the MSs profile
(e.g., per call authorization required or the profile is not present):

3-1-4-1

32
33

IF the MSC requests qualification and authentication in parallel when a system


access is received from an MS for which it does not have a valid service profile:

34
35
36
37
38
39

3-1-4-1-1
3-1-4-1-2

Execute the MSC Initiating an Authentication Request task (see 4.4.1) and
the MSC Initiating Qualification Request task (see 4.33.1) in parallel.

40

IF authentication fails:

42

41

43

3-1-4-1-2-1

Clear the pending registration flag for the MS.

44
45
46
47
48
49
50
51
52
53
54
55
56
57

1. In addition the MSC shall initiate authentication procedures if the MS has authentication capabilities and there is no
AuthenticationCapability information for the MS.

58
59
60

3 ANSI-41 Procedures

8-69

ANSI/J-STD-036-B

3-1-4-1-2-2

IF the call is an Emergency Services call (e.g., 9-1-1 or air interface


indication):

2
3
4

3-1-4-1-2-2-1

Execute the MSC Initiating an OriginationRequest for an


Emergency Services Call task (see 3.2.1).

3-1-4-1-2-2-2

IF the TerminationList parameter was received:

5
6
7
8

3-1-4-1-2-2-2-1

Process the PSTNTermination (DestinationDigits) of the


TerminationList parameter locally to route the call.

3-1-4-1-2-2-2-2

Exit this task.

9
10
11
12
13
14
15

3-1-4-1-2-2-3

ENDIF

3-1-4-1-2-3

ENDIF.

3-1-4-1-2-4

IF the MS dialed a locally allowed number (e.g., 9-1-1, *-9-1-1, N11,


*N11) OR the MSC received an air interface indication of an emergency
call:

16
17
18

3-1-4-1-2-4-1

Process the dialed number locally and route the call.

3-1-4-1-2-4-2

Exit this task.

19
20
21
22

3-1-4-1-2-5

ELSE:

23

3-1-4-1-2-5-1

Execute Local Recovery Procedures task (see 3.5.1).

24

3-1-4-1-2-5-2

Exit this task.

25
26

3-1-4-1-2-6

27

3-1-4-1-3

28

3-1-4-1-3-1

29
30
31
32

3-1-4-1-4
3-1-4-2

ENDIF.
ELSE (authentication successful):
GOTO Pre-screening completed.
ENDIF.
ELSE:

33

3-1-4-2-1

Execute the MSC Initiating Qualification Request task (see 4.33.1).

34

3-1-4-2-2

IF the MSs AuthenticationCapability indicates that the MS shall be authenticated:

35
36
37

3-1-4-2-2-1

38

Execute the MSC Initiating an Authentication Request task (see 4.4.1).

3-1-4-2-3

ENDIF.

3-1-4-2-4

IF authentication fails:

39
40
41
42
43

3-1-4-2-4-1

Clear the pending registration flag for the MS.

3-1-4-2-4-2

IF the call is an Emergency Services call (e.g., 9-1-1 or air interface


indication):

44
45

3-1-4-2-4-2-1

Execute the MSC Initiating an OriginationRequest for an


Emergency Services Call task (see 3.2.1).

3-1-4-2-4-2-2

IF the TerminationList parameter was received:

46
47
48
49

3-1-4-2-4-2-2-1

Process the PSTNTermination (DestinationDigits) of the


TerminationList parameter locally to route the call.

3-1-4-2-4-2-2-2

Exit this task.

50
51
52
53
54

3-1-4-2-4-2-3

ENDIF

55

3-1-4-2-4-3

ENDIF.

56

3-1-4-2-4-4

IF the MS dialed a locally allowed number (e.g., 9-1-1, *-9-1-1, N11,


*N11) OR the MSC received an air interface indication of an emergency
call:

57
58
59
60

8-70

3 ANSI-41 Procedures

ANSI/J-STD-036-B

3-1-4-2-4-4-1

Process the dialed number locally and route the call.

3-1-4-2-4-4-2

Exit this task.

3-1-4-2-4-5

ELSE:
Execute Local Recovery Procedures task (see 3.5.1).

3-1-4-2-4-5-2

Exit this task.

GOTO Pre-screening completed.

3-1-4-2-6

ENDIF.

3-1-4-3

5
6
7

ELSE (authentication successful):

3-1-4-2-5-1

ENDIF.

3-1-4-2-5

3-1-4-2-4-5-1
3-1-4-2-4-6

10
11
12
13
14

ENDIF.

15

3-1-5

ENDIF.

3-1-6

Execute the MSC Initiating an Authentication Request task (see 4.4.1).

3-1-7

IF authentication fails:

16

18
19

IF the call is an Emergency Services call (e.g., 9-1-1 or air interface indication):

3-1-7-1
3-1-7-1-1

Execute the MSC Initiating an OriginationRequest for an Emergency


Services Call task (see 3.2.1).

3-1-7-1-2

IF the TerminationList parameter was received:

3-1-7-1-2-1

Process the PSTNTermination (DestinationDigits) of the TerminationList parameter locally to route the call.

3-1-7-1-2-2

Exit this task.

3-1-7-1-3

21
22
23
24
25
26
27
28

30

3-1-7-2

ENDIF.

3-1-7-3

IF the MS dialed a locally allowed number (e.g., 9-1-1, *-9-1-1, N11, *N11) OR
the MSC received an air interface indication of an emergency call:

31

3-1-7-3-1

Process the dialed number locally and route the call.

3-1-7-3-2

Exit this task.

32
33
34
35
36
37

ELSE:

38

3-1-7-4-1

Execute Local Recovery Procedures task (see 3.5.1).

3-1-7-4-2

Exit this task.

3-1-7-5

20

29

ENDIF

3-1-7-4

17

39
40
41
42

ENDIF.

43

3-1-8

ENDIF.

3-1-9

GOTO Pre-screening completed.

3-2

44

46

ENDIF.

47

ENDIF.

IF the MS is not registered OR IF the location of the MS has changed since the last registration:

5-1
6

48

Execute the MSC Initiating MS Registration task (see 4.38.1).


ELSEIF the MSC requires the MSs service profile (e.g., per call authorization required or the
service profile is not present):

6-1

Execute the MSC Initiating Qualification Request task (see 4.33.1).

49
50
51
52
53
54
55
56

ENDIF.

7-1

45

57

Pre-screening completed:

58
59
60

3 ANSI-41 Procedures

8-71

ANSI/J-STD-036-B

Execute Initialize the OneTimeFeatureIndicator Parameter task (see 3.2.8).

IF a pending registration flag is set for the MS:

9-1

Clear the pending registration flag for the MS.

9-2

Execute the MSC Analyze MS Dialed Number task (see 3.2.3) and spawn the MSC
Initiating MS Registration task (see 4.38.1) in parallel.

1
2

5
6
7

10 ELSE:

8
9

10-1

10

Execute the MSC Analyze MS Dialed Number task (see 3.2.3).

11

11 ENDIF.

12

12 IF the PointOfReturn is ToneTermination:

13
14
15
16

12-1

Execute Apply Access Denial Treatment task (see 3.4.5).

12-2

Exit this task.

17

13 ENDIF.

18

14 IF the MS is not authorized:

19
20
21
22

14-1

Execute Apply Access Denial Treatment task (see 3.4.5).

14-2

Exit this task.

23

15 ENDIF.

24

16 Execute the MSC PACA Call Origination Invocation task (see 5.17.2).

25

17 IF unsuccessful:

26
27

17-1

28

18 ELSE (seize the channel by):

29

Execute Apply Access Denial Treatment task (see 3.4.5).

18-1

Reserve the available voice or traffic channel.

18-2

Order the MS to acquire the reserved voice or traffic channel.

33

18-3

Verify the MS has properly tuned to this voice or traffic channel.

34

18-4

IF unsuccessful:

30
31
32

35

18-4-1

36

18-5

37
38

Execute Apply Access Denial Treatment task (see 3.4.5).


ENDIF.

39

19 ENDIF.

40

20 Execute the MSC MWN Call Origination Invocation task (see 5.13.7).

41

21 ENDIF.

42
43

22 IF the AnnouncementList parameter is received:

44

22-1

45

Execute the Play All Announcements in the AnnouncementList task (see 3.2.5).

23 ENDIF.

46
47

24 Execute the MSC Routing Points Of Return task (see 3.2.6).

48

25 Exit this task.

49
50
51
52
53

3.1.3

In Call MS Flash Attempt (ANSI-41.6-D 3.2.2, page 6-14)


When the MS attempts to signal during a call by pressing the (SEND) key, the Anchor MSC shall:

54
55
56

IF it is required to authenticate flash requests (e.g., signaling encryption is not supported):

57

1-1

Include the SystemAccessType parameter set to Flash request.

58

1-2

Execute the MSC Initiating an Authentication Request task (see 4.4.1).

59
60

8-72

3 ANSI-41 Procedures

ANSI/J-STD-036-B

1-3

IF authentication fails AND the feature request received was not a request to establish an
emergency services call:

1
2
3

1-3-1

Execute Local Recovery Procedures task (see 3.5.1).

1-3-2

Exit this task.

1-4

5
6

ENDIF.

ENDIF.

IF FlashPrivileges are allowed by the OneTimeFeatureIndicator parameter:

3-1

IF CW has been invoked:

3-1-1

9
10
11

Put the current party on hold.


The remainder of this procedure remains unchanged

12
13
14
15

3.1.4

Serving MSC Initiating a Flash Request


(ANSI-41.6-D 4.15.1, page 6-138)
When the Serving MSC receives a flash from an MS engaged in a voice call, it shall perform the
following:

16
17
18
19
20
21
22

Include the InterMSCCircuitID parameter set to the trunk for this call.

Include the MobileIdentificationNumber parameter set to the requesting MSs MIN.

24

Include the ElectronicSerialNumber parameter set to the requesting MSs ESN.

25

Include the Digits: (Dialed) parameter set to the digits (non-encrypted) received from the MS.

27

Include the EmergencyServicesRoutingDigits (ESRD) parameter set to the appropriate value.

28

IF the SignalingMessageEncryptionKey (SMEKEY) parameter was provided for the MS:

23

26

29

6-1

Include the ConfidentialityModes: (CMODES-actual) parameter set to the current


Signaling Message Encryption mode and Voice Privacy mode of the requesting MS.

30
31
32
33

ENDIF.

If the MS is equipped with an MEID:

8-1
9

34

Include the MEID parameter set to the requesting MSs MEID.


ENDIF.

35
36
37
38

10 Send a FlashRequest INVOKE toward the Anchor MSC for this call.
11 Start the Flash Request Timer (FRT).
12 WAIT for a Flash Request response.

39
40
41
42
43

13 WHEN a RETURN RESULT is received:

44

13-1

Stop timer (FRT).

45

13-2

Exit this task.

46
47

14 WHEN a RETURN ERROR or REJECT is received:

48
49

14-1

Stop timer (FRT).

14-2

Execute the Local Recovery Procedures task (see 3.5.1).

14-3

Exit this task.

50

52
53

15 WHEN the timer (FRT) expires:


15-1

51

54

Execute the Local Recovery Procedures task (see 3.5.1).

16 ENDWAIT.

55
56
57
58

17 Exit this task.

59
60

3 ANSI-41 Procedures

8-73

ANSI/J-STD-036-B

1
2

3.1.5

3
4

Anchor MSC Receiving a FlashRequest INVOKE


(ANSI-41.6-D 4.15.2, page 6-139)
When the Anchor MSC receives a FlashRequest INVOKE, it may perform the following:

6
7

IF the received message can be processed:

1-1

Send a RETURN RESULT toward the Serving MSC.

1-2

IF the requesting MSs AuthenticationCapability status information indicates that authentication is required:

10
11
12

1-2-1

Include the SystemAccessType parameter set to indicate Flash request.

13

1-2-2

Include the Digits (Dialed) parameter set equal to the Digits in the received FlashRequest INVOKE message.

1-2-3

Include the ConfidentialityModes (CMODES-actual) parameter (if it was received in


the FlashRequest INVOKE message).

1-2-4

Execute the MSC Initiating an AuthenticationRequest task (see 4.4.1).

1-2-5

IF authentication is successful OR the feature control request received was a request


to establish an emergency call leg:

14
15
16
17
18
19
20
21

1-2-5-1

22

IF the feature control request received was a request to establish an emergency call
leg:

23
24

1-2-5-1-1

25

Execute the MSC Initiating an OriginationRequest for an Emergency


Services Call task (see 3.2.1).

26
27

1-2-5-2

ENDIF.

1-2-5-3

Effect the feature control requested by the MS flash (if applicable).

28
29

1-2-6

30
31
32

1-2-6-1

33

1-2-7

34

1-3

35

Execute recovery procedures according to the MSCs internal algorithm.


ENDIF.
ELSE (the requesting MS is not capable of being authenticated):

36

1-3-1

37

1-3-1-1

38

ELSE:

IF the feature control request received was a request to establish an emergency call leg:
Execute the MSC Initiating an OriginationRequest for an Emergency Services
Call task (see 3.2.1).

39
40

1-3-2

ENDIF.

41

1-3-3

Effect the feature control requested by the MS flash (if applicable).

42

1-4

43
44

45

2-1

46
47
48
49
50

ENDIF.
ELSE (the message cannot be processed):
Send a RETURN ERROR with the proper Error Code value (see the following table)
toward the Serving MSC.

ENDIF.

Exit this task.

51
52
53
54
55
56
57
58
59

3.1.6

MSC Receiving an SMSDeliveryPointToPoint INVOKE


(ANSI-41.6-D 4.46.4, page 6-273)
Upon receipt of an SMSDeliveryPointToPoint INVOKE for an intended MS, the receiving MSC
shall do the following:
1

IF the message can be processed:

60

8-74

3 ANSI-41 Procedures

ANSI/J-STD-036-B

1-1

IF the ServiceIndicator parameter is set to CDMA Position Determination Service or


AMPS Position Determination Service:

1
2
3

1-1-1

IF the SMS_BearerData parameter has a non-zero length:

1-1-1-1

Execute the MSC Receiving an SMDPP INVOKE for Position Determination


Data Message Exchange task (see 3.6.1).

4
5
6
7

1-1-2

ELSE:

1-1-2-1

Include the SMS_CauseCode parameter set appropriately.

1-1-2-2

Send a RETURN RESULT.

1-1-3

ENDIF.

1-1-4

Exit this task.

9
10
11
12
13
14

1-2

ENDIF

1-3

IF the SMS_DestinationAddress parameter is received:

15

The remainder of this procedure remains unchanged

16
17
18
19

3.1.7

Anchor MSC Initiating SMS Delivery Point-To-Point


(ANSI-41.6-D 4.46.5, page 6-277)
This task assumes that it is called by a higher function capable of acting upon returned
SMS_CauseCode appropriately. Upon request, the Anchor MSC shall do the following:
1

1-2

Set the destination address to the network address of that network entity.
ELSEIF the ServiceIndicator parameter is present and has the value CDMA Position Determination Service (i.e., MS has initiated CDMA position determination for an emergency
services call):

1-2-1

Set the destination address to the network address of the local MPC for this MSC.

1-2-2

Include the Teleservice_Priority parameter set to indicate Emergency.

1-3

1-3-1-1

23
24
25

28
29
30
31
32
33
34
35
36
37

ELSE:

1-3-1

22

27

IF routing to the network entity that initiated position determination is required:

1-1-1

21

26

IF the request can be processed:

1-1

20

38

IF indirect routing is required by the SMS_OriginationRestrictions set to Force


Message Center:
Include the SMS_DestinationAddress parameter set to the
SMS_OriginalOriginatingAddress.

1-3-2

ENDIF.

1-3-3

CASE SMS_OriginationRestrictions OF:

1-3-4

Block All:

39
40
41
42
43
44
45
46
47

1-3-4-1

Include the SMS_CauseCode parameter indicating SMS Origination Restriction.

1-3-4-2

Return to the calling task indicating denied.

48
49

1-3-5

Allow Specific:

50
51
52

1-3-5-1
1-3-5-1-1
1-3-5-1-1-1
1-3-5-1-1-2

IF the MS is not allowed to originate using direct addresses:


IF the SMS_DestinationAddress parameter is not equal to the
SMS_OriginalOriginatingAddress (direct routing requested):
Include the SMS_CauseCode parameter indicating SMS Origination
Restriction.
Return to the calling task indicating denied.

53
54
55
56
57
58
59
60

3 ANSI-41 Procedures

8-75

ANSI/J-STD-036-B

1-3-5-1-2

ENDIF.

2
3

1-3-5-2

1-3-6

ENDIF.
DEFAULT:

1-3-6-1

(Just allow it.)

1-3-7

7
8

ENDCASE.

1-4

ENDIF.

1-5

Relay all included parameters.

1-6

Execute the Initiating SMS Delivery Point-To-Point task (see 4.46.2).

13

1-7

Return to the calling task with the received parameters and the returned indication.

14

9
10
11
12

ELSE (request cannot be processed):

15
16

2-1

Include the SMS_CauseCode parameter indicating the appropriate value.

17

2-2

Return to the calling task indicating denied.

18
19

ENDIF.

20

Exit this task.

21
22
23

3.1.8

24

MSC Receiving an SMSDeliveryForward INVOKE


(ANSI-41.6-D 4.45.2, page 6-266)

25

Upon receipt of an SMSDeliveryForward INVOKE, the MSC shall do the following:

26
27

28

IF the received message can be processed:

1-1

29

IF the ServiceIndicator parameter is set to CDMA Position Determination Service or


AMPS Position Determination Service:

30
31

1-1-1

32

IF the SMS_BearerData parameter has a non-zero length:

1-1-1-1

33

Execute Section 3.6.1 MSC Receiving SMDPP INVOKE for Position Determination Data Message Exchange on page 8-86.

34
35

1-1-2

ENDIF.

37

1-1-3

Exit this task.

38

1-2

ENDIF.

1-3

IF the SMS_DestinationAddress parameter is received:

36

39
40
41

The remainder of this procedure remains unchanged Editors note: 1

42
43
44
45
46
47
48

3.1.9

Serving MSC Receiving an SMD-REQUEST (ANSI-41.6-D D.5, page 6416)


Upon receipt of an air interface SMD-REQUEST from an MS-based SME, the Serving MSC shall
do the following:

49
50
51
52
53
54
55

1
1-1
2
2-1

IF the DestinationAddress parameter is received:


Set the destination address with the address in the received DestinationAddress parameter.
ELSE:
Set the destination address to the address of the Anchor MSC.

56

ENDIF.

57

IF the OriginalDestinationAddress parameter is received:

58
59
60

8-76

3 ANSI-41 Procedures

ANSI/J-STD-036-B

4-1

Set the original destination address with the address in the received OriginalDestinationAddress parameter.

1
2
3

ELSE:

5-1

Set the original destination address with the destination address.

5
6

ENDIF.

Set the originating address to the originating MIN.

IF the OriginalOriginatingAddress parameter is received:

8-1
9

Set the original originating address with the address in the received OriginalOriginatingAddress parameter.

11
12

14

Set the original originating address with the originating address.

15
16

10 ENDIF.

17

11 IF the OriginalDestinationSubaddress parameter is received:


11-1

10

13

ELSE:

9-1

Set the original destination subaddress to the OriginalDestinationSubaddress parameter.

18
19
20

12 ENDIF.

21

13 IF the OriginalOriginationSubaddress parameter is supplied:

22
23

13-1

Set the original origination subaddress to the OriginalOriginationSubaddress parameter.

15 IF the SMD-REQUEST is a Data Burst message of type PLD:


15-1

Include the ServiceIndicator parameter set to value CDMA Position Determination Service.

Execute the Anchor MSC Initiating SMS Delivery Point-To-Point task (see 4.46.5).

18 ELSE (the MSC is the Serving MSC):


18-1

Set the underlying data transport destination address to the Anchor MSC or the next MSC
in the handoff chain.

18-2

Include the InterMSCCircuitID parameter set to the trunk used in the direction toward the
Anchor MSC.
Execute the MSC Initiating SMS Delivery Backward task (see 4.44.1).

19 ENDIF.

28

31
32
33
34
35
36
37
38
39
40
41
42

(Get here after the message has been relayed and responded to.)
20 IF the MS is still being served:
20-1

27

30

17 IF the MSC is the Anchor MSC for the indicated MS:

18-3

26

29

16 ENDIF.
17-1

24
25

14 ENDIF.

43
44
45
46

IF the request was accepted:

47

20-1-1

Relay the indicated SMS_BearerData.

48

20-1-2

Send an SMD-ACK to the MS based SME.

49

20-2

ELSE (the request was denied):

20-2-1

Relay the indicated SMS_CauseCode.

20-2-2

Send an SMD-NAK to the MS based SME.

20-3

ENDIF.

51
52
53
54
55

21 ELSE (the MS is no longer being served):


21-1

50

Discard the message.

56
57
58
59
60

3 ANSI-41 Procedures

8-77

ANSI/J-STD-036-B

22 ENDIF.

2
3

23 Return to calling task .

4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-78

3 ANSI-41 Procedures

ANSI/J-STD-036-B

3.2

(NEW) Origination Request Procedures

1
2
3

3.2.1

MSC Initiating an OriginationRequest for an Emergency Services Call

4
5

When the MSC determines that it requires information from the MPC for an emergency service call,
it shall perform the following:

6
7
8

Include the OriginationTriggers parameter with length zero.

IF the Mobile Station Identity (MSID) is available:

10
11

2-1
3

Include the MSID parameter set to identify the originating MS.

3-1

Include the InternationalMobileSubscriberIdentity identifier type of MSID of length zero.

ENDIF.

IF the Mobile Directory Number (MDN) of the MS is available AND IF (authentication was
successful OR the MSs AuthenticationCapability indicates no authentication required):

5-1
6

14
15
16

Include the MobileDirectoryNumber parameter set to the MDN of the MS.

17
18
19
20
21

ELSE (MDN unavailable):

6-1

12
13

ELSE (MSID unavailable):

22

Include the MobileDirectoryNumber parameter set to the pseudo-callback number.

23
24

ENDIF.

Include the TransactionCapability parameter set to identify the current capabilities.

26

Include the MobileCallStatus parameter set appropriately, if applicable.

27

25

10 Include the OriginationIndicator parameter set to identify the types of call the MS can originate,
if applicable.

28
29
30

11 Include the TerminationRestrictionCode parameter set to identify the types of calls the MS is
allowed to terminate, if applicable.

31

12 IF the MSC is currently serving the MS:

34

12-1

Include the applicable parameters defined in the technology-specific MobInfo macros (see
2.3.2.14, and following).

35

12-2

Include the ServingCellID parameter set to the cell currently serving the MS.

38

32
33

36
37

39

13 ENDIF.

40

14 IF known:

41

14-1

42

Include the MobilePositionCapability parameter set to identify the position determination


capability of the MS.

43
44

15 ENDIF.

45

16 Send an OriginationRequest INVOKE to the MPC associated with the MSC.

46
47

17 Start the Origination Request Timer (ORT).


19 WAIT for Origination Request response:
20 WHEN a RETURN RESULT is received:
20-1

OriginationRequest RETURN RESULT received:

20-2

Stop timer (ORT).

20-3

IF the message can be processed:

20-3-1

48
49

18 Await Result:

50
51
52
53
54
55

IF the GeographicPosition parameter is received:

56
57
58
59
60

3.2 (NEW) Origination Request Procedures

8-79

ANSI/J-STD-036-B

20-3-1-1

Relay the contents of the GeographicPosition parameter for use as the ISUP
Calling Geodetic Location parameter for the call to the calling task.

2
3
4
5
6
7

20-3-2

ENDIF.

20-3-3

IF the DMH_BillingDigits parameter is received:

20-3-3-1

Relay the contents of the DMH_BillingDigits parameter for use as the ISUP
Charge Number parameter or as MF ANI information to the calling task.

20-3-4

ENDIF.

11

20-3-5

IF the MobileDirectoryNumber parameter is received:

12

20-3-5-1

9
10

Relay the contents of the MobileDirectoryNumber parameter for use as the ISUP
Calling Party Number parameter to the calling task.

13
14
15

20-3-6

ENDIF.

16

20-3-7

IF the GenericDigits parameter is received:

17
18

20-3-7-1

Relay the contents of the GenericDigits parameter for use as the ISUP Generic
Digits Parameter to the calling task.

19
20
21
22

20-3-8

ENDIF.

20-3-9

Return to the Calling Task.

23

20-4

24

20-4-1

25
26
27
28

20-5

ELSE (message cannot be processed):


Return to calling task with a Unsuccessful indication.
ENDIF.

21 WHEN an InterSystemPositionRequest INVOKE is received:

29

21-1

Execute the MSC Receiving an InterSystemPositionRequest INVOKE task (see 3.3.1).

30

21-2

GOTO Await Result.

31
32

22 WHEN a RemoteUserInteractionDirective INVOKE is received:


22-1

Send a RETURN ERROR with Error Code set to indicate OperationSequenceProblem.

35

22-2

GOTO Await Result.

36

23 WHEN the MS disconnects:

33
34

37

23-1

Stop timer (ORT).

39

23-2

Return to the calling task with a Call Abandoned indication.

40

24 WHEN a RETURN ERROR or REJECT is received:

38

41
42
43
44
45
46
47

24-1

Stop timer (ORT).

24-2

Return to the calling task with a Unsuccessful indication.

25 WHEN timer (ORT) expires1:


25-1

Return to the calling task with a Unsuccessful indication.

48

26 ENDWAIT.

49

27 Return to calling task.

50
51
52
53
54
55
56
57
58
59

1. This will not normally occur since the MPC will send a response when a timer (POST) in the MPC
which is shorter than ORT expires.

60

8-80

3.2 (NEW) Origination Request Procedures

ANSI/J-STD-036-B

3.3

(NEW) InterSystem Position Request


(See InterSystemPositionRequest, section 2.2.1.6)

1
2
3
4
5

3.3.1

MSC Receiving an InterSystemPositionRequest INVOKE

6
7

When an MSC receives an InterSystemPositionRequest INVOKE, it shall perform the following:


1

IF the received message can be processed:

1-1

IF the MSC is currently serving the MS AND the MS is assigned to a traffic channel AND
IF the MSC is not a Serving MSC at the end of a handoff chain:

1-1-1

Include the PositionResult parameter set to indicate Mobile channel information


returned.

1-1-2

IF the CDMAPSMMCount parameter is received AND the MS is operating in CDMA


mode:

1-1-2-1

Order the MS to receive pilot signal strength per the PSMMCount value.

1-1-2-2

Include the results in the CDMAPSMMList parameter or GeographicPosition


parameter as appropriate.

9
10
11
12
13
14
15
16
17
18
19
20
21
22

1-1-3

ENDIF

1-1-4

IF the TDMA_MAHORequest is set to Return TDMA MAHO information AND the


MS is operating in TDMA mode:

23

1-1-4-1

Order the MS to return MAHO information (signal strengths of the adjacent cells).

1-1-4-2

Include the results in the Mobinfo_TDMA macro.

24
25
26
27
28
29

1-1-5

ENDIF

1-1-6

Include the ServingCellID parameter set to the serving cell identity.

1-1-7

Include the applicable parameters defined in the technology-specific MobInfo macros


(see 2.3.2.14, and following).

1-1-8

Include all appropriate parameters (see 2.2.1.6).

1-2

30

ELSEIF the MSC recognizes that it is an Anchor for a call involving the MS:

31
32
33
34
35
36
37

1-2-1

Relay the PositionRequestType parameter.

38

1-2-2

Include all appropriate parameters (see 2.2.1.6).

39

1-2-3

Send an InterSystemPositionRequestForward INVOKE to the next MSC in the


handoff chain toward the Serving MSC.

40
41
42
43

1-2-4

Start Intersystem Position Request Forward Timer (IPFT).

1-2-5

WAIT for InterSystemPositionRequestForward response:

45

1-2-6

WHEN a RETURN RESULT is received:

46

44

47

1-2-6-1

Stop the timer (IPFT).

1-2-6-2

IF the message can be processed:

1-2-6-2-1

Relay all received parameters.

1-2-6-2-2

Include all appropriate parameters (see 2.2.1.6).

1-2-6-3
1-2-6-3-1
1-2-6-4
1-2-7

ELSE (message cannot be processed):


Include the PositionResult parameter set to indicate System failure.

48
49
50
51
52
53
54
55
56

ENDIF.

57

WHEN a REJECT or RETURN ERROR is received:

58
59
60

3.3 (NEW) InterSystem Position Request

8-81

ANSI/J-STD-036-B

1-2-7-1

Stop the timer (IPFT).

1-2-7-2

Include the PositionResult parameter set to indicate System failure.

1-2-8

1
2

WHEN the timer (IPFT) expires:

1-2-8-1

6
7

1-2-9

1-3

ENDWAIT.
ELSEIF the MSC is a Tandem MSC or a Serving MSC at the end of a handoff chain for the
MS1:

10
11

Include the PositionResult parameter set to indicate System failure.

1-3-1

Include the PositionResult parameter set to indicate Access Denied.

12

1-4

13

ELSE:

1-4-1

14
15
16

1-5

17

18

ENDIF.
ELSE (the received message cannot be processed):

2-1

19

Include the PositionResult parameter set to identify the error appropriately.

Include the PositionResult parameter set to identify the error appropriately.

20

ENDIF.

21

Send an InterSystemPositionRequest RETURN RESULT.

Exit this task.

22
23
24
25
26

3.4

(NEW) Intersystem Position Request Forward

27
28
29

3.4.1

MSC Receiving an InterSystemPositionRequestForward INVOKE

30

(see InterSystemPositionRequestForward, section 2.2.1.7)

31
32
33
34

When an MSC receives an InterSystemPositionRequestForward INVOKE, it shall perform the


following:

35
36

37

1-1

38

IF the received message can be processed:


IF the MSC is a Tandem for a call involving the MS:

1-1-1

Replace the received InterMSCCircuitID parameter value with the ID of the trunk used
in the direction toward the Serving MSC for the call.

1-1-2

Relay the other received parameters.

1-1-3

Send an InterSystemPositionRequestForward INVOKE toward the Serving MSC.

1-1-4

Start the Intersystem Position Request Forward Timer (IPFT).

46

1-1-5

WAIT for InterSystemPositionRequestForward response:

47

1-1-6

WHEN a RETURN RESULT is received:

39
40
41
42
43
44
45

48
49
50
51

1-1-6-1

Stop the timer (IPFT).

1-1-6-2

IF the message can be processed:

52

1-1-6-2-1

53

1-1-6-3

Relay the received parameters.


ELSE (message cannot be processed):

54
55
56
57
58
59

1. In some (rare) cases, a Tandem MSC or the Serving MSC at the end of a handoff chain may have the
MSs prole (e.g., if an MS registered to one MSC initiates an Emergency Services Call in a neighboring
MSC whose roamer database has no HLR address for the MSs MSID and if one or more handoffs occur
during that call).

60

8-82

3.3 (NEW) InterSystem Position Request

ANSI/J-STD-036-B

1-1-6-3-1

Include the PositionResult parameter set to indicate System failure.

1-1-6-4

ENDIF.

1-1-7

WHEN a REJECT or RETURN ERROR is received:

1-1-7-1

Stop the timer (IPFT).

1-1-7-2

Include the PositionResult parameter set to indicate System failure.

1-1-8

WHEN the timer (IPFT) expires:

1-1-8-1

Include the PositionResult parameter set to indicate System failure.

1-1-9
1-2

IF TDMA MAHO Information is requested by the Anchor System AND the MS is


operating in TDMA mode:
IF the Serving MSC is capable of providing MAHO data:

1-2-1-1-1

Order the MS to return MAHO information (signal strengths of the adjacent


cells).

1-2-1-1-2

Include the results in the Mobinfo TDMA macro.

1-2-1-2

5
6
7
8
9
10

12

ELSEIF the MSC is currently serving the MS AND the MS is assigned to a traffic channel:

1-2-1-1

11

ENDWAIT.

1-2-1

13
14
15
16
17
18
19
20
21
22

ENDIF

23

1-2-2

ENDIF

1-2-3

Relay the received parameters.

1-2-4

Include the MSCID parameter set to the Serving MSC identity.

1-2-5

Include the ServingCellID parameter set to the serving cell identity.

1-2-6

Include the applicable parameters defined in the technology-specific MobInfo macros


(see 2.3.2.14, and following).

1-2-7

Include all appropriate parameters (see 2.2.1.6).

1-2-8

Send an InterSystemPositionRequest INVOKE to the MPC associated with the MSC.

1-2-9

Start the Intersystem Position Request Timer (IPRT).

1-2-10

WAIT for InterSystemPositionRequest response:

1-2-11

WHEN a RETURN RESULT is received:

24

1-2-11-1

Stop the timer (IPRT).

1-2-11-2

IF the message can be processed:

1-2-11-2-1

Relay the received parameters.

1-2-11-2-2

Include all appropriate parameters (see 2.2.1.7).

25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

1-2-11-3

ELSE (message cannot be processed):

1-2-11-3-1

Include the PositionResult parameter set to indicate System failure.

1-2-11-4
1-2-12

ENDIF.
WHEN a REJECT or RETURN ERROR is received:
Stop the timer (IPRT).

1-2-12-2

Include the PositionResult parameter set to indicate System failure.


WHEN the timer (IPRT) expires:

1-2-13-1
1-2-14
1-3

45
46
47
48

1-2-12-1
1-2-13

44

Include the PositionResult parameter set to indicate System failure.


ENDWAIT.

49
50
51
52
53
54
55
56
57
58

ELSE:

59
60

3.3 (NEW) InterSystem Position Request

8-83

ANSI/J-STD-036-B

1
2

1-3-1

1-4

5
6

2-1

Include the PositionResult parameter set to identify the error appropriately.


ENDIF.

ELSE (received message cannot be processed):


Include the PositionResult parameter set to identify the error appropriately.

ENDIF.

Send an InterSystemPositionRequestForward RETURN RESULT toward the Anchor MSC.

Exit this task.

9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-84

3.3 (NEW) InterSystem Position Request

ANSI/J-STD-036-B

3.5

(NEW) Call Termination Report

1
2

(See CallTerminationReport, section 2.2.1.3)

3
4
5

3.5.1

MSC Initiating a CallTerminationReport INVOKE

6
7

When an MSC determines that an emergency services call has been released it will initiate a call
termination report to the MPC by doing the following:
1

Include all appropriate parameters (see 2.2.1.3)

Send a CallTerminationReport INVOKE to the MPC

Start the Call Termination Report Timer (CTRT).

WAIT for CallTerminationReport response:

WHEN a RETURN RESULT is received:

5-1
6

Stop the timer (CTRT).

8
9
10
11
12
13
14
15
16
17
18

WHEN a RETURN ERROR or REJECT is received:

19
20

6-1

Stop the timer (CTRT).

21

6-2

Execute Local Recovery Procedures task (see 3.5.1).

22
23

7
7-1

WHEN the timer (CTRT) expires:


Execute Local Recovery Procedures task (see 3.5.1).

ENDWAIT.

Exit this task.

24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

3.5 (NEW) Call Termination Report

8-85

ANSI/J-STD-036-B

1
2

3.6

(NEW) SMDPP for Position Determination Data Message


Exchange

4
5
6
7

3.6.1

MSC Receiving SMDPP INVOKE for Position Determination Data


Message Exchange

(See SMSDeliveryPointToPoint, section 2.2.1.11)

9
10
11

12

1-1

13
14
15
16

IF the received message can be processed:


IF the MS is operating in an unsupported mode for the indicated service:

1-1-1
1-2

17

1-2-1

18

1-3

19
20
21

1-3-1

22

1-4

Include the SMS_CauseCode parameter set to Radio interface incompatibility.


ELSE IF the MS has performed an intersystem handoff forward:
Execute the MSC Initiating SMSDeliveryForward INVOKE task (4.45.1)
ELSEIF the ActionCode parameter is not received OR IF the target MS is not assigned to
a traffic channel for a voice call:
Include the SMS_CauseCode parameter set to an appropriate value.
ELSE:

23
24

1-4-1

Extract the Position Determination Data Message from the SMS_BearerData


parameter.

1-4-2

Send the Position Determination Data Message to the MS.

1-4-3

IF the Position Determination Data Message could not be sent:

25
26
27
28
29
30
31

1-4-3-1
1-4-4

32

Include the SMS_CauseCode parameter set to Network failure.


ELSEIF the received ActionCode parameter is not set to indicate Do Not Wait for MS
User Level Response:

1-4-4-1

WAIT for response from the MS:

35

1-4-4-2

WHEN an Position Determination Data Message response is received:

36

1-4-4-2-1

33
34

37
38
39

1-4-4-2-1-1

40

1-4-4-2-2

41
42

1-4-4-2-2-1

43
44
45
46
47

1-4-4-2-3
1-4-4-3
1-4-4-3-1

48
49
50

1-4-4-4

51
52

1-4-4-4-1

53
54
55

1-4-4-5

56
57
58

1-4-4-5-1

IF the Position Determination Data Message exceeds IS-41 message


transport size limitations:
Include the SMS_CauseCode parameter set to Encoding problem.
ELSE:
Include the SMS_BearerData parameter set to the Position Determination Data Message.
ENDIF.
WHEN traffic channel release occurs (e.g., due to MS release):
Include the SMS_CauseCode parameter set appropriately to indicate the
failure.
WHEN loss of radio contact is detected OR the MS hands off to an unsupported
mode:
Include the SMS_CauseCode parameter set appropriately to indicate the
failure.
WHEN the Data Burst that carries the Position Determination Data Message is
rejected by the MS:
Include the SMS_CauseCode parameter set appropriately to indicate the
failure.

59
60

8-86

3.6 (NEW) SMDPP for Position Determination


Data Message Exchange

ANSI/J-STD-036-B

1-4-4-6
1-4-5
1-5
2
2-1

ENDWAIT.

ENDIF.

ENDIF.

ELSE (message can not be processed):


Include the SMS_CauseCode parameter set to an appropriate value.

5
6
7
8

ENDIF.

Include all appropriate parameters (see 2.2.1.11)

10

Send an SMDPP RETURN RESULT to the requesting entity.

11

Exit this task.

12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

3.6 (NEW) SMDPP for Position Determination


Data Message Exchange

8-87

ANSI/J-STD-036-B

1
2

3.7

(NEW) SMDFWD for Position Determination Data Message


Exchange

4
5
6
7

3.7.1

MSC Receiving SMDFWD INVOKE for Position Determination Data


Message Exchange

(See SMSDeliveryForward, section 2.2.1.10)

9
10
11

12

1-1

13
14

IF the received message can be processed:


IF the MSC is the serving MSC:

1-1-1

Extract the Position Determination Data Message from the SMS_BearerData


parameter.

1-1-2

Send the Position Determination Data Message to the MS.

1-1-3

IF the Position Determination Data Message could not be sent:

15
16
17
18
19
20
21

1-1-3-1

Include the SMS_CauseCode parameter set to Network failure.

1-1-4

ELSEIF the ActionCode parameter is not received OR IF the received ActionCode


parameter is not set to indicate Do Not Wait for MS User Level Response:

22
23

1-1-4-1

WAIT for response from the MS:

25

1-1-4-2

WHEN an Position Determination Data Message response is received:

26

1-1-4-2-1

24

IF the Position Determination Data Message exceeds IS-41 message


transport size limitations:

27
28
29

1-1-4-2-1-1

30

1-1-4-2-2

Include the SMS_CauseCode parameter set to Encoding problem.


ELSE:

31
32

1-1-4-2-2-1

Include the SMS_BearerData parameter set to the Position Determination Data Message.

33
34

1-1-4-2-3

ENDIF.

35
36
37
38

1-1-4-3

ENDWAIT.

1-1-5

ENDIF.

39

1-2

40

1-2-1

Discard the InterMSCCircuitID parameter.

1-2-2

Relay all other received parameters.

1-2-3

Execute the MSC Initiating SMSDeliveryForward task (4.45.1) toward the serving
MSC in the call.

41
42
43

ELSE (this is a Tandem MSC):

44
45
46

1-3

47

48

2-1

49
50
51
52
53

ENDIF.
ELSE (message can not be processed):
Include the SMS_CauseCode parameter set to an appropriate value.

ENDIF.

Send an SMDFWD RETURN RESULT to the requesting entity.

Exit this task.

54
55
56
57
58
59
60

8-88

3.7 (NEW) SMDFWD for Position Determination


Data Message Exchange

ANSI/J-STD-036-B

Operation Timer Values

1
2
3

Table 8-73:

Operation Timer Values (continued)

4
5

Timer

Default
(sec.)

Started when

Normally stopped when

Action when timer


expires

CTRT

CallTermination
Report INVOKE is
sent.

CallTermination
Report RETURN RESULT
or RETURN ERROR is
received.

Execute recovery
procedures.

6
7
8
9
10

Call Termination
Report Timer

11
12
13
14

15

GPDT

GeoPositionDirective
INVOKE is sent

GeoPositionDirective
RETURN RESULT or
RETURN ERROR is
received

Execute recovery
procedures.

17

GeoPositionRequest
RETURN RESULT or
RETURN ERROR is
received

Execute recovery
procedures.

16

18
19
20
21

GPRT

not
specified
by this
Standard

GeoPositionRequest
INVOKE is sent

22
23
24
25

IPFT

60

IntersystemPositionRequestForward
INVOKE is sent.

IntersystemPositionRequestForward RETURN
RESULT or RETURN
ERROR is received.

see MSC
Receiving an InterSystemPositionRequestForward
INVOKE and see
MSC Receiving an
InterSystemPositionRequest
INVOKE .

26
27

Intersystem
Position Request
Forward Timer

IPRT

55

InterSystemPositionRequest INVOKE is
sent.

InterSystemPositionRequest RETURN RESULT


or RETURN ERROR is
received.

see MSC
Receiving an InterSystemPositionRequestForward
INVOKE

Intersystem
Position Request
Timer

28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

ORT

16 (see
note a.)

OriginationRequest
INVOKE (or a subsequent RemoteUserInteractiveDirective
INVOKE) is sent.

OriginationRequest
RETURN RESULT,
RETURN ERROR or a
RemoteUserInteractionDirective INVOKE is
received.

Execute recovery
procedures (see
note b.)

44
45

Origination
Request Timer

46
47
48
49
50
51

POST

3 to 5

MPC Receives an
OriginationRequest
INVOKE.

MPC initiates an OriginationRequest RETURN


RESULT.

MPC initiates an
OriginationRequest RETURN
RESULT.

52
53

Position Timer

54
55
56
57

58
59
60

4 Operation Timer Values

8-89

ANSI/J-STD-036-B

Notes:

2
3
4
5
6

a. In the case of an emergency services call, the ORT timer can be less than 16 seconds but
should be more than the POST timer.
b. In the case of an emergency services call, the call will be extended to the ESNE.

7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

8-90

4 Operation Timer Values

ANSI/J-STD-036-B

Chapter 9: Location Services Protocol


(LSP)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

16

Introduction

17
18

This section specifies the Abstract Syntax for the Location Services Protocol using the Abstract Syntax
Notation One (ASN.1), defined in ITU-T Recommendations X.680 (1994) and X.680 Amendment 1 (1995)
and the OPERATION and ERROR external MACROs, defined in ANSI T1.114-1996.

19
20
21

The encoding rules applicable to the defined Abstract Syntax are the ASN.1 Basic Encoding Rules defined
in ITU-T Recommendation X.690 (1994). Implicit tagging is used for all context specific parameters.

22

The Location Services Protocol (LSP) consists of operations used on the MPC-PDE interface (E5) and on the
MPC-CRDB interface (E11) and is applicable to AMPS, NAMPS, TDMA and CDMA air interface locations.
LSP is based on TCAP, but the physical, transport and network layers are specifically undefined. As an alternative, some message and parameters have been defined for transport over ANSI-41 MAP.

25

The following operations are defined for the MPC-PDE interface:

30

23
24

26
27
28
29

CallTerminationReport (CTRPT)
This operation may be used to by the MPC to inform the PDE that an emergency services call has
been disconnected.

31

GeoPositionDirective (GPOSDIR)
This operation is used to push an MS position from the PDE to the MPC.

35

32
33
34

36
37

GeoPositionRequest (GPOSREQ)
This operation is used to request the PDE for the initial, updated or last known position of an MS.

38
39

SMSDeliveryPointToPoint (SMDPP)
This operation is for conveying encapsulated data from one point to another point and reports the
success or failure of that transfer.

40

InterSystemPositionRequest (ISPOSREQ)
This operation is used to request the PSMM results from the PDE to the MS.

44

41
42
43

45
46

The following operation is defined for the MPC-CRDB interface:

47

PositionRouteRequest (POSROUTREQ)
This operation is used to request a translation from a position expressed as latitude and longitude to
a string of digits.

48

Parameter contents imported from other specifications (e.g., T1.114 and ANSI-41) are imported without
length and identifier octets.

52

49
50
51

53
54
55
56
57
58
59
60

1 Introduction

9-1

ANSI/J-STD-036-B

1
2

1.1

Transaction Portion
The Location Services Protocol employs the Query with Permission and Response TCAP Package Types
defined in ANSI T1.114-1996.

4
5
6
7
8
9
10
11
12
13

1.2

Component Portion
The Location Services Protocol employs the Invoke (Last), Return Result (Last), Return Error and Reject
TCAP Component Types defined in ANSI T1.114-1996 with the following exceptions and limitations:

14
15
16
17
18
19

20
21
22

23
24
25

26
27
28
29
30
31

32
33
34
35

36
37
38

39
40
41

The Operation Code Identifier is coded as Private TCAP.


The Operation Code is partitioned into an Operation Family followed by a Specifier
associated with each Operation Family member. For the Location Services Protocol,
the Operation Family is coded as decimal 2. Bit H of the Operation Family is always
coded as 0.
A TCAP INVOKE component shall contain a Component ID Length greater than zero.
A TCAP RETURN RESULT component shall only be transmitted in response to an
INVOKE Component.
A TCAP RETURN ERROR component shall only be sent in response to an INVOKE
component, not a RETURN RESULT component.
The Error Code Identifier is coded as Private TCAP.
If a problem is detected by TCAP (i.e., the received message does not conform to
ANSI T1.114.3), a TCAP REJECT component with one of the following Problem
Specifiers shall be sent:
a. Problem Type General: all defined Problem Specifiers are applicable.
b. Problem Type Transaction Portion: all defined Problem Specifiers are applicable.
If a problem is detected by the Location Services TC-user (i.e., the received message
does not conform to the Location Services Protocol), a TCAP REJECT component
with one of the following TCAP Problem Specifiers shall be sent: : Duplicate Invoke
ID, Unrecognized Operation Code or Incorrect Parameter.
The Parameter SET Identifier is coded per ANSI T1.114 (national, constructor with
Identifier code 18).
The Parameter SEQUENCE Identifier is coded per ANSI T1.114 (universal, constructor with Identifier code 16).
Generalized Time is included by reference to Chapter 7. The definition from X.680
that is referenced from Chapter 7 should be used, and not the definition from ANSI-41.

42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

9-2

1.1 Transaction Portion

ANSI/J-STD-036-B

Location Services Protocol Abstract Syntax


The Location Services Protocol is composed of an ASN.1 module dealing with operations, errors and data
types.

1
2
3
4
5
6

LocationServicesProtocol { joint-iso-ccitt (4) memberbody (2) usa (840) LocationServicesProtocol (2) }


DEFINITIONS

7
8
9
10
11

::=

12
13

BEGIN

14
15
16

EXPORTS
IMPORTS

17
18

ERROR,
OPERATION
FROM TCAPPackage { iso (1) memberbody (2) usa (840) T1.114 (10013) } ;

19
20
21
22
23

Digits,
GeographicPosition,
IMSI,
MobileIdentificationNumber,
PositionInformation,
PositionResult

24
25
26
27
28
29
30
31
32

FROM EmergencyServicesProtocol { iso (1) memberbody (2) usa (840) emergencyServicesProtocol (1) }
;
-- Location Services errors and error codes
-- FaultyParameter parameter id is 1
-- The following text defines the values of error codes (local values 1 through 4).
systemFailure
ERROR ::= localValue 1
unauthorizedRequest
ERROR PARAMETER FaultyParameter ::= localValue 2
unexpectedDataValue
ERROR PARAMETER FaultyParameter ::= localValue 3
unrecognizedKey
ERROR PARAMETER FaultyParameter ::= localValue 4

33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

-- Operations Definitions

50
51

-- The CallTerminationReport operation may be used by the MPC to inform the PDE that an
-- emergency services call has been disconnected.
-- The MPC-based timer CTRT has a default value of 6 seconds.
CallTerminationReport ::= OPERATION -- Timer CTRT
PARAMETER
ctrArg
CallTerminationReportArgument

52
53
54
55
56
57
58
59
60

2 Location Services Protocol Abstract Syntax

9-3

ANSI/J-STD-036-B

1
2
3
4
5
6

RESULT
ctrRes
ERRORS{

CallTerminationReportResponse

}
CallTerminationReport ::= localValue {2, 6}

7
8
9
10
11
12
13
14
15
16
17
18

CallTerminationReportArgument ::= SEQUENCE {


ctBILLID
[1] BillingID OPTIONAL -- Include if known
ctESN
[2] ESN OPTIONAL, -- Include if known
ctIMSI
[3] IMSI OPTIONAL, -- Include if known
ctMIN
[4] MobileIdentificationNumber OPTIONAL, -- Include if known
ctTMSI
[5] NetworkTMSI OPTIONAL, -- Include if known
}

CallTerminationReportResponse ::= SEQUENCE {


}

19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

-- The GeoPositionDirective operation is used to deliver the position of a specific MS.


-- The PDE-based timer GPDT has a default value of 6 seconds.
GeoPositionDirective ::= OPERATION -- Timer GPDT
PARAMETER
lspdArg
PositionDirectiveArgument
RESULT
lspdRes
PositionDirectiveResponse
ERRORS{
SystemFailure,
UnauthorizedRequest,
UnexpectedDataValue,
UnrecognizedKey
}
GeoPositionDirective ::= localValue {2, 2 }

40
41
42
43
44
45
46
47
48
49
50
51

PositionDirectiveArgument ::= SEQUENCE {


pdKey
CHOICE {
[1] MobileIdentificationNumber,
[2] IMSI,
[3] NetworkTMSI
},
pdgeon
[4] PositionInformation,
pdesn
[5] ElectronicSerialNumber OPTIONAL -- Include if known
}

52
53
54
55
56

PositionDirectiveResponse ::= SEQUENCE {


pdBILLID
[1] BillingID OPTIONAL -- Include if applicable
}

57
58
59
60

9-4

2 Location Services Protocol Abstract Syntax

ANSI/J-STD-036-B

-- The GeoPositionRequest operation is used to request the


-- position of a specific MS. The MPC based timer GPRT has a default value which is a local
-- configuration option dependent on the PDE technology used.
GeoPositionRequest ::= OPERATION
-- Timer GPRT
PARAMETER
lsprArg
PositionRequestArgument
RESULT
lsprRes
PositionRequestResponse
ERRORS {
SystemFailure,
UnauthorizedRequest,
UnexpectedDataValue,
UnrecognizedKey
}
GeoPositionRequest ::= localValue {2, 1 }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

PositionRequestArgument ::= SEQUENCE {


prReqType
[0] PositionRequestType,
prKey
CHOICE {
[1] MobileIdentificationNumber,
[2] IMSI,
[3] NetworkTMSI
},
presn
[4] ElectronicSerialNumber OPTIONAL,
-- Include if known.
prMobInfo
[5] MobileInformation OPTIONAL,
prMPCap
[6] MobilePositionCapability OPTIONAL,
-- Mobile unit geo-position assistance capabilities.
prMSCID
[7] MSCID OPTIONAL, -- Serving MSC Id.
prServingCellID [8]ServingCellID OPTIONAL,
prPriority
[9] Teleservice_Priority OPTIONAL,
prBILLID
[10] BillingID OPTIONAL -- Include if known
}

22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

PositionRequestResponse ::= SEQUENCE {


[0] PositionInformation OPTIONAL,
[1] PositionResult
}

43
44
45
46
47
48

-- The PositionRouteRequest operation is used to request


-- routing information based on the latitude and longitude of the MS.
-- The MPC-based timer PRRT has a default value of 2 seconds.
PositionRouteRequest ::= OPERATION -- Timer PRRT
PARAMETER
lsprreqArg
PositionRouteRequestArgument
RESULT
lsprreqRes
PositionRouteRequestResponse
ERRORS{

49
50
51
52
53
54
55
56
57
58
59
60

2 Location Services Protocol Abstract Syntax

9-5

ANSI/J-STD-036-B

1
2
3
4
5
6
7
8

SystemFailure,
UnauthorizedRequest,
UnexpectedDataValue,
UnrecognizedKey
}
PositionRouteRequest ::= localValue {2, 3 }

9
10
11
12
13

PositionRouteRequestArgument ::= SEQUENCE {


prRouteReqPosition
[0] GeographicPosition
}

14
15
16
17
18

PositionRouteRequestResponse ::= SEQUENCE {


prRouteReqDigits
[0] DestinationDigits OPTIONAL
}

19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

-- The SMSDeliveryPointToPoint operation is used for conveying encapsulated data from


-- one point to another point and reports the success or failure of that transfer. This
-- operation is only used on the E5 Interface.
SMSDeliveryPointToPoint ::= OPERATION
PARAMETER
smdppArg
SMSDeliveryPointToPointArgument
RESULT
smdppRes
SMSDeliveryPointToPointResponse
-- Errors are reported as SMS_CauseCode values
SMSDeliveryPointToPoint ::= localValue {2, 4 }

35
36
37
38
39
40
41
42
43
44
45
46
47

SMSDeliveryPointToPointArgument ::= SEQUENCE {


msid
CHOICE {
[0] MobileIndentificationNumber,
[1] IMSI
},
smdppSrvcIndctr
[2] ServiceIndicator OPTIONAL,
smdppActCode
[3] ActionCode OPTIONAL,
smdppBearerData
[4] SMS_BearerData OPTIONAL,
smdppSOWD2
[5] CDMAServingOneWayDelay2 OPTIONAL,
-- Include for CDMA when MPC is invoking entity

48
49
50
51
52
53
54
55

smdppServingCellID [6] ServingCellID OPTIONAL,


-- Include when MPC is invoking entity
smdppTeleserviceId [7] SMS_TeleserviceIdentifier OPTIONAL,
smdppPriority
[8] Teleservice_Priority OPTIONAL,
smdppESN
[9] ElectronicSerialNumber OPTIONAL
}

56
57
58
59

SMSDeliveryPointToPointResponse ::= SEQUENCE {


smdppCauseCode
[0] SMS_CauseCode OPTIONAL,

60

9-6

2 Location Services Protocol Abstract Syntax

ANSI/J-STD-036-B

smdppBearerData
[1] SMS_BearerData OPTIONAL,
smdppSOWD2
[2] CDMAServingOneWayDelay2 OPTIONAL,
-- Include for CDMA when MPC is responding entity

smdppServingCellID [3] ServingCellID OPTIONAL,


-- Include when MPC is responding entity

2
3
4

6
7

-- The InterSystemPositionRequest operation is used to request the


-- PSMM results measured at a specific MS. The MPC based timer IPRT has a default value of 30 seconds.
InterSystemPositionRequest ::= OPERATION
-- Timer IPRT
PARAMETER
isprArg
InterSystemPositionRequestArgument
RESULT
isprRes
InterSystemPositionRequestResponse
ERRORS {
SystemFailure,
UnauthorizedRequest,
UnexpectedDataValue,
UnrecognizedKey
}
InterSystemPositionRequest ::= localValue {2, 5 }

10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

InterSystemPositionRequestArgument ::= SEQUENCE {


isprReqType
[0] PositionRequestType,
mobileIdentificationNumber [1] MobileIdentificationNumber OPTIONAL,
iMSI
[2] IMSI OPTIONAL,
networkTMSI
[3] NetworkTMSI OPTIONAL,
-- Include at least one of MIN, IMSI, and NetworkTMSI
ispresn
[4] ElectronicSerialNumber OPTIONAL,
-- Include if known.
isprMSCID
[5] MSCID OPTIONAL, -- Serving MSC Id.
IsprCDMAPSMMCnt [6] CDMAPSMMCount,
isprServingCellID
[7] ServingCellID OPTIONAL,
isprMAHORequest [8] TDMA_MAHORequest OPTIONAL
}

29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

InterSystemPositionRequestResponse ::= SEQUENCE {


isprPosResult
[0] PositionResult OPTIONAL,
isprMPCap
[1] MobilePositionCapability OPTIONAL,
-- Mobile unit geo-position assistance capabilities.
isprMobInfo
[2] MobileInformation ,
isprMSCID
[3] MSCID OPTIONAL, -- Serving MSC Id.
isprServingCellID
[4] ServingCellID,
positionInformation [5] PositionInformation OPTIONAL
}

47
48
49
50
51
52
53
54
55
56
57
58
59
60

2 Location Services Protocol Abstract Syntax

9-7

ANSI/J-STD-036-B

-- Location Services Parameter Definitions

2
3
4

ActionCode ::= OCTET STRING -- See Chapter 8, Section 2.3.2.1 for encoding

5
6

BillingID ::= OCTET STRING -- See ANSI-41-D, Section 6.5.2.16 for encoding

7
8
9

CDMAChannelData ::= OCTET STRING -- See ANSI-41-D, Section 6.5.2.30 for encoding

10
11
12

CDMACodeChannel ::= OCTET STRING -- See ANSI-41-D, Section 6.5.2.31 for encoding

13
14

CDMAMobileCapabilities ::= OCTET STRING -- See Chapter 8, Section 2.3.2.2 for encoding

15
16
17

CDMAPilotStrength ::= OCTET STRING -- See ANSI-41-D, Section 6.5.2.35 for encoding

18
19

CDMAPrivateLongCodeMask ::= OCTET STRING -- See ANSI-41-D, Section 6.5.2.36 for encoding.

20
21
22

CDMAPSMMCount ::= OCTET STRING -- See Chapter 8, Section 2.3.2.3 for encoding.

23
24
25
26
27
28

CDMAPSMMList ::= SET {


cdmaSOWD2
[0] CDMAServingOneWayDelay2,
cdmatlist1
[1] SEQUENCE OF CDMATargetMAHOList -- at least one must be included
}

29
30
31

CDMAServiceOption ::= OCTET STRING -- See IS-737, Section 6.5.2f for encoding.

32
33

CDMAServingOneWayDelay2 ::= OCTET STRING -- See Chapter 8, Section 2.3.2.5 for encoding.

34
35
36
37
38
39
40
41
42

CDMATargetMAHOInformation ::= SET {


tcellid
[0] TargetCellID,
cps
[1] CDMAPilotStrength,
ctowd
[2] CDMATargetOneWayDelay,
mscid
[3] MSCID OPTIONAL -- Target MSCID
}

43
44
45

CDMATargetMAHOList ::= SEQUENCE OF CDMATargetMAHOInformation -- at least one must be included

46
47

CDMATargetOneWayDelay ::= OCTET STRING -- See ANSI-41-D, Section 6.5.2.46 for encoding.

48
49
50

ChannelData ::= OCTET STRING -- See ANSI-41-D, Section 6.5.2.47 for encoding.

51
52

DestinationDigits ::= OCTET STRING -- See ANSI-41-D, Section 6.5.2.56 for encoding

53
54
55

DTXIndication ::= OCTET STRING

-- See Chapter 8, Section 2.3.2.7 for encoding.

ElectronicSerialNumber ::= OCTET STRING

-- See ANSI-41-D, Section 6.5.2.53 for encoding.

56
57
58
59
60

9-8

2 Location Services Protocol Abstract Syntax

ANSI/J-STD-036-B

FaultyParameter ::= OCTET STRING

-- See ANSI-41-D, Section 6.5.2.66 for encoding

1
2
3

Hyperband ::= INTEGER

-- 0 = 800 MHz, 1 = 1900 MHz

4
5

MeasuredCellID ::= OCTET STRING

-- See ANSI-41-D, Section 6.5.242 for encoding.

6
7
8

MeasuredChannel ::= OCTET STRING

-- See TDMA for encoding of channel number

9
10

MobileInformation ::= CHOICE {


mobInfo_AMPS [0] SEQUENCE {
[1] ChannelData,
[2] DTXIndication OPTIONAL,
[3] ReceivedSignalQuality OPTIONAL
},
mobInfo_CDMA [1] SEQUENCE {
[1] CDMAChannelData,
[2] CDMACodeChannel OPTIONAL,
[3] CDMATargetMAHOList OPTIONAL,
[4] CDMAPrivateLongCodeMask OPTIONAL,
[5] CDMAServingOneWayDelay2 OPTIONAL
[6] CDMAPSMMList OPTIONAL,
[7] CDMAMobileCapabilities OPTIONAL,
[8] CDMASO OPTIONAL
},
mobInfo_NAMPS [2] SEQUENCE {
[1] ChannelData,
[2] NAMPSChannelData,
[3] DTXIndication OPTIONAL,
[4] ReceivedSignalQuality OPTIONAL
},
mobInfo_TDMA [3] SEQUENCE {
[1] TDMAChannelData,
[2] DTXIndication OPTIONAL,
[3] TargetMeasurementList OPTIONAL,
[4] ReceivedSignalQuality OPTIONAL,
[5] VoicePrivacyMask OPTIONAL
[6] TDMA_MAHO_CELLID OPTIONAL,
-- Include if MAHO information was requested and
-- cells can be identified
[7] TDMA_MAHO_CHANNEL OPTIONAL,
-- Include if MAHO information was requested and
-- cells cannot be identified.
[8] TDMA_TimeAlignment OPTIONAL,
[9] TDMAVoiceMode OPTIONAL -- Include if known
}
}

11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2 Location Services Protocol Abstract Syntax

9-9

ANSI/J-STD-036-B

1
2
3

MobilePositionCapability ::= OCTET STRING

-- See Chapter 8, Section 2.3.2.13 for encoding.

4
5

MSCID ::= OCTET STRING -- See ANSI-41-D, Section 6.5.2.82 for encoding.

6
7
8

NAMPSChannelData ::= OCTET STRING -- See ANSI-41-D, Section 6.5.2.86 for encoding.

9
10

NetworkTMSI ::= OCTET STRING -- See Chapter 8, Section 2.3.2.18 for encoding.

11
12
13

PositionInformation ::= OCTET STRING -- See Chapter 8, Section 2.3.2.19 for encoding.

14
15
16

PositionRequestType ::= OCTET STRING -- See Chapter 8, Section 2.3.2.20 for encoding.

17
18

PositionResult ::= OCTET STRING -- See Chapter 8, Section 2.3.2.21 for encoding.

19
20
21

ReceivedSignalQuality ::= OCTET STRING -- See ANSI-41-D, Section 6.5.2.106 for encoding.

22
23

ServiceIndicator ::= OCTET STRING -- See Chapter 8, Section 2.3.2.24 for encoding

24
25
26

ServingCellID ::= OCTET STRING -- See ANSI-41-D, Section 6.5.2.117 for encoding.

27
28

SMS_BearerData ::= OCTET STRING -- See ANSI-41-D, Section 6.5.2.124 for encoding

29
30
31

SMS_CauseCode ::= OCTET STRING -- See ANSI-41-D, Section 6.5.2.125 for encoding

32
33

SMS_TeleserviceIdentifier ::= OCTET STRING -- See Chapter 8, Section 2.3.2.25 for encoding

34
35
36

TargetCellID ::= OCTET STRING -- See ANSI-41-D, Section 6.5.242 for encoding.

37
38

TargetMeasurementList ::= OCTET STRING -- See ANSI-41-D, Section 6.5.2.150 for encoding.

39
40
41

TDMAChannelData ::= OCTET STRING -- See ANSI-41-D, Section 6.5.2.153 for encoding.

42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

TDMA_MAHO_CELLID ::= SEQUENCE {


[1] ReceivedSignalQuality, -- Obtained signal strength measurement from Serving Cell
[2] Hyperband OPTIONAL, -- Default = 0 (800 MHz)
INTEGER NRSSI,
-- Number of RSSI measurements included from the serving MSC
-- (other than the Serving Cell, above)
SET OF SEQUENCE{ --Repeat SEQUENCE NRSSI times
[1] ReceivedSignalQuality, -- Obtained signal strength measurement
[2] Hyperband OPTIONAL, -- Default = 0 (800 MHz)
[3] MeasuredCellID
-- Cell from which measurement was obtained
}
INTEGER NMSC, -- Number of MSC s from which RSSI information was obtained

57
58
59
60

9-10

2 Location Services Protocol Abstract Syntax

ANSI/J-STD-036-B

SET OF SEQUENCE{-- Repeat SEQUENCE NMSCID times


[1] MSCID,
-- MSC from which measurements were obtained
INTEGER NRSSI,
-- Number of RSSI measurements included from this MSC
SET OF SEQUENCE{
-- Repeat SEQUENCE NRSSI times
[2] ReceivedSignalQuality, -- Obtained signal strength measurement
[3] Hyperband OPTIONAL,-- Default = 0 (800 MHz)
[4] MeasuredCellID -- Cell from which measurement was obtained
}
}

1
2
3
4
5
6
7
8
9
10
11

12
13

TDMA_MAHO_CHANNEL ::= SEQUENCE {


INTEGER NMSC, -- Number of MSC s from which RSSI information was obtained
SET OF SEQUENCE{-- Repeat SEQUENCE NMSCID times
[1] MSCID,
-- MSC from which measurements were obtained
INTEGER NRSSI,
-- Number of RSSI measurements included from this MSC
SET OF SEQUENCE{
-- Repeat SEQUENCE NRSSI times
[2] ReceivedSignalQuality, -- Obtained signal strength measurement
[3] Hyperband,
-- Default = 0 (800 MHz)
[4] MeasuredChannel -- Cell from which measurement was obtained
}
}
}

14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

TDMA_MAHORequest ::= OCTET STRING

-- See See Chapter 8, Section 2.3.2.28 for encoding

29
30
31

TDMA_TimeAlignment ::= OCTET STRING -- See Chapter 8, Section 2.3.2.29 for encoding.

32
33

TDMAVoiceMode ::= OCTET STRING -- See ANSI-41 for encoding

34
35
36

Teleservice_Priority ::= OCTET STRING -- See Chapter 8, Section 2.3.2.30 for encoding.

37
38
39

VoicePrivacymask ::= OCTET STRING -- See ANSI-41-D, Section 6.5.2.166 for encoding.

40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

2 Location Services Protocol Abstract Syntax

9-11

ANSI/J-STD-036-B

1
2

Annex A:

Analysis of the Network Reference Model

This annex is informative and is not considered part of this Standard.

This section analyzes the network reference model by applying it to possible real world configurations

6
7
8

A.1

Possible Emergency Services Network Configurations

9
10
11
12
13

Serving
System

14
15
16

Access
Tandem
or
PSTN

17
18
19
20
21
22
23
24

Selective
Router

PSAP

Selective
Routing
Database

ALI

25
26
27
28
29
30
31
32
33
34
35
36

Figure A-1:

Basic Emergency Services Network Topology

37
38
39
40
41
42
43
44
45

Interconnection through an Access Tandem or the PSTN is not recommended, but it is still possible for
systems covering large geographic areas like satellites and maybe some PCS providers.
The ALI and Selective Routing Database may be physically collocated, but are shown as separate functions
because the queries to them are quite different. The selective routing database converts a telephone number
into an emergency services number representing an emergency services zone. Each zone is served by a
primary and alternate PSAP and by a predetermined set of emergency response agencies, one for each type
of emergency response required (e.g., fire, police, medical, poison control).

46
47
48
49
50
51
52
53
54
55
56
57
58

This network topology has served the wireline industry well for the last thirty years, but it is inadequate to
meet the demands of the calltakers as expressed in two joint experts meetings in 1994. Crucial to these
requirements was the ability to move location information between the serving system and the PSAP. This
could be performed with either call associated signaling or with non-call associated signaling. With call
associated signaling information is passed with the same messages used to setup and control a call. In noncall associated signaling, the messages containing information are passed separate from the call and the
association between the message and the call must be established upon receipt. On short inspection, call
associated signal appears to be easier to use since correlation of information and a call is so much easier. The
down side is that 1) call associated signaling requires upgrades of all switches that handle the call between
the serving system and the PSAP, and 2) PSAP to PSAP transfers will have to work out something else to
avoid routing the call to the same primary PSAP.

59
60

A-1

ANSI/J-STD-036-B

1
2
3

Access
Tandem
or
PSTN

Serving
System

4
5
6
7
8
9
10
11
12
13
14

PSAP

15
16
17
18

Figure A-2:

A World Without Selective Routers

In a radical simplification of the emergency services network, the serving system can take over the routing
functions of the selective router and selective routing database and route the call directly to a PSAP over the
PSTN. The PSAP obtains information about the emergency calls from the serving system. If calls are to be
re-routed to another PSAP or an emergency services agency, the call transfer feature provided by the switch
serving the PSAP is used (although in some switches the feature may need to be modified to allow the PSAP
to bridge the call before completing the transfer).
In such a network topology, the problems of call associated signaling are accentuated, because nearly every
switch and STP in the country would have to be able to handle the special signaling for emergency services
calls.

19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

A-2

ANSI/J-STD-036-B

1
2
3
4
5

In defining the network reference models for the wireless network, it was noted that there need to be at least
four functional entities. The MSC (Mobile Switching Center) is the basic switching entity in a wireless
network and it provides a single point of interconnection for the wireless system side of emergency services
calls.

6
7

Emergency Services
Network

8
9
10
11

MSC

12

MSC

Ai Di

13
14
15
16
17

E12

18

E3

Emergency
Services
Network
Entity
These interfaces
are beyond the
scope of this
document

PSAP

19
20

PDE

21

E5

MPC

Emergency
Services
Message
Entity

E2

22
23
24
25
26
27
28
29
30
31
32
33

Figure A-3:

Network Reference Model for Wireless Networks

34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

The MPC (Mobile Position Center) provides a single point of interconnection for users of positioning information. It is envisioned that there will be many applications that can use position information, although the
current standard is limiting its scope to just one such application for emergency services. Even within
emergency services, there are two uses for position and these may use separate applications. The first use is
routing the call to the appropriate PSAP. The second application is to aid the call taker and dispatcher in
locating the caller geographically and sending assistance to the caller. This may be as simple as returning the
nearest known street address to a given latitude and longitude or it may be plotting the callers position on a
map with other information like building names, business names, landmarks, etc.
The MPC also interconnects a set of PDE (Position Determining Entities) that cover a geographic area. It may
require more than one PDE of a given technology to cover an area. A given area may elect to use PDEs of
more than one technology (e.g., use a general network based solution for all phones while offering an
enhanced mobile-based or mobile-assisted premium service to some subscribers). The MPC will have to
query the HLR, VLR, and MSC to select the proper PDE and to provide the PDE with information regarding
the particular mobile station in question.
The traditional ALI had two basic types of information: location information that provided a street address
for a telephone number and subscriber information that provided a name and other information about a
subscriber. In a wireless system, location information is within the domain of the serving system and
subscriber information is in the domain of the home system. Since these are conceptually separate systems,
the information is viewed as coming from separate functions with the MPC providing the raw position information that can be converted into location and the WSI (Wireless Subscriber Information) providing

58
59
60

A-3

ANSI/J-STD-036-B

subscriber information. Further since the WSI is outside of the scope of the FCC Report and Order, its implementation is entirely optional at the discretion of the wireless service provider and the PSAP community that
it serves.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

A-4

ANSI/J-STD-036-B

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

A.2

Possible Configurations of ESNEs


In the development of the network reference model it was clear that in an emergency services network, the
entity that processed calls was not necessarily the same thing that processed the non-call associated messages,
although there has to be communication between the two. For instance the entity processing the calls, an
ESNE or emergency services network entity, may be a selective router, a direct interconnection, an access
tandem, or an interworking device. The selective router will probably be the most common initial interconnection point on an emergency services network. Calls to PSAPs may be routed to over a PSTN when the
wireless carrier is able to select the proper PSAP before the call leaves its switches. This connection directly
to a PSAP is more likely to be a logical relationship than a physical relationship as it is unlikely that a wireless
service provider will have direct physical interconnection to a PSAP. A more common physical interconnection to PSAPs will be through an intervening access tandem or local end office. Interworking devices may
be used to convert enhanced MF signaling or MF to CAMA signaling commonly used by the installed base
of selective router and PSAP equipment.

16
17
18

ESNE

19
20
21
22

MSC

23

Selective
Router

PSAP

Selective
Routing
Database

ALI

24
25
26
27
28
29
30
31
32
33
34
35

Figure A-4:

Emergency Services Network Topology with S/R as ESNE

36
37
38

ESNE

39
40
41
42

PSAP

MSC

43
44
45
46
47
48
49
50
51

ALI

52
53
54
55

Figure A-5:

Emergency Services Network Topology with ESNE co-located with PSAP

56
57
58
59
60

A-5

ANSI/J-STD-036-B

1
2

ESNE

3
4

Access
Tandem
or
PSTN

MSC

5
6
7
8
9
10
11
12
13
14

Selective
Router

PSAP

15
16
17
18
19
20
21
22

Selective
Routing
Database

23

ALI

24
25
26

Figure A-6:

27

Emergency Services Network Topology with AT as ESNE

28
29
30

MSC

Access
Tandem
or
PSTN

31
32
33
34
35
36
37
38

ESNE

39
40

Interworking
Device

Selective
Router

PSAP

41
42
43
44
45
46
47
48

Selective
Routing
Database

49

ALI

50
51
52
53
54

Figure A-7:

Emergency Services Network Topology with an interworking device as ESNE

55
56
57
58
59
60

A-6

ANSI/J-STD-036-B

1
2
3
4
5
6
7
8
9
10

A.3

Possible Configurations of ESMEs


The emergency services user of messaging, an ESME or Emergency Services Message Entity, is less clear.
It could be simply a feed into a traditional ALI, although that is fraught with problems. There is a liability
issue for the accuracy of any information in the database if several different entities are allowed to insert data,
even if only on a temporary basis. Since wireless calls would only need data in the database for a duration of
an emergency call, there would have to be a mechanism to clean out the database of these temporary records.
The records would use the range of all area codes to support roaming wireless subscriber, and that would
require better access methods than some ALIs currently support.

11
12
13
14

MSC

Access
Tandem
or
PSTN

MPC

Selective
Router

15
16
17
18
19
20
21
22
23
24

PSAP

25
26
27
28

ESME

29
30
31

Selective
Routing
Database

32
33

ALI

34
35
36
37
38

Figure A-8:

Emergency Services Network Topology with ALI as ESME

39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

A-7

ANSI/J-STD-036-B

The ESME could be a separate ALI when ALI steering is used between the PSAP and the ALI. The steering
could recognize mobile directory numbers and route those queries to obtain the requested information. This
separate ALI could preform the management of the temporary records, accommodate data pushes from the
wireless carrier and formulate pull requests to the wireless carrier.

1
2
3
4
5
6
7

Access
Tandem
or
PSTN

MSC

8
9
10
11
12
13
14
15
16
17

Selective
Router

MPC

PSAP

18
19
20
21
22
23
24
25

Selective
Routing
Database

ALI
Steering

26
27
28
29
30
31

ESME

32
33
34

ALI

ALI

35
36
37
38

Figure A-9:

Emergency Services Network Topology with Separated ALI as ESME

39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

A-8

ANSI/J-STD-036-B

1
2
3
4

The ESME could be the ALI steering device that routes ALI queries using the ESRD associated with the
wireless emergency services call to select the proper MPC and within the MPC the callback number can select
the proper caller.

5
6

MSC

Access
Tandem
or
PSTN

MPC

Selective
Router

7
8
9
10
11
12
13
14
15
16
17
18

PSAP

19
20
21
22
23

ESME

Selective
Routing
Database

24
25

ALI
Steering

26
27
28
29
30
31
32
33

ALI

34
35
36
37
38

Figure A-10:

Emergency Services Network Topology with Separated ALI as ESME

39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

A-9

ANSI/J-STD-036-B

The ESME could be an interworking device so that each emergency services call could be associated with a
special pseudo ANI. This pseudo ANI can then be used with existing equipment to query either selective
routing databases or ALIs for the call routing, location, or subscriber information.

1
2
3
4
5
6
7

MSC

8
9
10
11
12
13

ESME

14
15

MPC

Interworking
Device

16

Selective
Router

PSAP

17
18
19
20
21
22
23

Selective
Routing
Database

24

ALI

25
26
27
28
29

Figure A-11:

Emergency Services Network Topology with interworking device as a ESME

30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

A-10

ANSI/J-STD-036-B

1
2
3
4
5

The ESME could be a message routing function that routes messages using the same alghoritms used to route
the emergency services calls to ensure that the messages are routed to the same place as the emergency
services calls. The message routing function could simply broadcast messages to all interconnected PSAPs
which would retain all messages and be able to associate incoming calls with the received messages.

6
7
8
9

MSC

10
11
12
13
14
15
16
17
18

MPC

19

Selective
Router

PSAP

20
21
22
23
24
25
26
27

ESME

28

Selective
Routing
Database

29
30

Message
Router

31
32
33
34
35
36

Figure A-12:

Emergency Services Network Topology with a message router as the ESME

37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

A-11

ANSI/J-STD-036-B

The PSAP could query other databases to convert the position information into the nearest known street
address or the current emergency services zone for the list of selective transfer numbers. The ESME may be
a geographic information system within the PSAP that requests position information about an emergency
services call so that the position of a caller can be plotted on a map in relation to streets, businesses, buildings,
landmarks, etc.

1
2
3
4
5
6
7
8
9
10

MSC

11
12
13
14
15
16

ESME

17
18

MPC

Selective
Router

PSAP

19
20
21
22
23
24

ALI

ALI
Steering
Coordinate
Coordinate
Routing
Database

25
26
27
28
29
30
31
32

ALI

33
34
35
36

Figure A-13:

Emergency Services Network Topology with the MPC-ALI combination as


the ESME

37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

A-12

ANSI/J-STD-036-B

1
2
3
4
5

The ESME could be an SCP application that is queried by the MSC to obtain instructions on how to route an
emergency services call. The application would have or be able to get the position information associated with
a call and be able to convert that position into a location such an emergency services zone and its associated
routing and selective transfer information.

6
7
8
9

MSC

PSAP

10
11
12

SS7 TCAP

13
14

ESME

15
16
17
18

MPC

19
20

Emergency
Services
Routing
Application

21
22
23
24

Coordinate
Coordinate
Routing
Database

25
26
27
28
29
30
31

Figure A-14:

Emergency Services Network Topology with an SCP application as the ESME

32
33
34
35
36

To show this example in a more physical realm (but still ignoring the required intervening networks and
switching equipment), the following figure shows 1) a centralized coordinate routing database run by the
9-1-1 authority, 2) several service providers, 3) several PSAPs, 4) location applications used by a single
service provider, and 5) location applications used by multiple several providers.

37
38
39
40

In reality the ESME is likely to be a combination of one or more of the above configurations or something
else that hasnt been thought of yet. The point is, it doesnt matter. All that really matters is that there be a
mechanism defined for moving information between two points.

41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

A-13

ANSI/J-STD-036-B

Provider A

Location
Application

MSC

PSAP

3
4
5

Location
Application

MPC

PSAP

6
7
8
9

Location
Application

PSAP

10
11

Provider B

12

PSAP

MSC

13
14
15

Location
Application

PSAP

MPC

16
17
18
19

PSAP
Location
Application

20
21

MSC

22

Provider C

23

Location
Application

24

MPC
ESME

25
26
27

Location
Application

Emergency
Services
Routing
Application

Location
Application

28
29
30
31
32
33

Provider D

34
35

MSC

Coordinate
Coordinate
Routing
Database

MPC

36
37
38
39
40

Provider E

41

Location
Application

42

MSC

43
44
45

Location
Application

46

MPC

47
48

Figure A-15:

Emergency Services Network Topology with an SCP application as the ESME

49
50
51
52
53
54
55
56
57
58
59
60

A-14

ANSI/J-STD-036-B

1
2

Annex B:

Local Positioning Determining Entity

This annex is informative and not considered part of this Standard.

4
5

This section describes the LPDE variant of the PDE including its relation to the MPC and BS within
the E-911 Network Reference Model. Call flow scenarios show how the LPDE variant supports
emergency services.

6
7
8
9
10
11

B.1

PDE Network Configuration

12
13
14

PDE

15
16

E3

17

MSC

18

MPC

19
20
21
22

23
24
25
26
27

BS

28

LPDE
This interface is
beyond the scope
of this document

29
30
31
32

Um

33
34
35
36
37

MS

38
39
40
41
42
43
44
45
46
47
48
49
50
51

Figure B-1:

Local PDE Network Topology


Figure B-1 shows a logical grouping of separate functional entities that define a composite NE
(i.e., PDE). The Local PDE is physically connected (or integrated) with the BS. Its primary function
is to calculate precise geographic position of the MS. Position calculation will be done while the
MS is on the traffic channel. The LPDE uses special algorithms to calculate the mobile position
based on signal measurements in the infrastructure, the MS, or both.

52
53
54
55
56
57
58
59
60

B-1

ANSI/J-STD-036-B

B.2

LPDE Position Scenarios

The following scenarios show MS positioning end-to-end call flows across the Um and A interfaces as well
as those specified in this standard.

4
5
6

B.2.1

ELID With Successful CAS Push

7
8

This scenario shows a simple position request and delivery of position information with a CAS push
during call setup.

9
10
11
12

BS/
LPDE

MS

MSC

MPC

ESME

ESNE

13
14
15

call origination (E911)

CM Service Request
T303

16
17

Assignment Request

Channel Assignment

18
19
20

BS ACK Order

T10

MS ACK Order

21
22
23
24
25

Service Connect

Service Connect Completion

26
27

Assignment Complete
ORREQ [MSID, MOBINFO, MPCAP]

SMDPP[ServiceIndicator,ActionCode,SMS_BearerData]

j
k
l

Data Burst (MS Measurement Request)

Data Burst (MS Measurement Response)

SMT
ORT

28
29
30
31
32
33

ADDS (Position Location Data)

Data Burst (MS Measurement Request)

POST

34
35
36
37
38

39
40

Data Burst (MS Measurement Response)

41
42

ADDS (Position Location Data)

smdpp[SMS_BearerData]

43
44

orreq [GEOPOS]

45
46

Call Setup IAM [ESRD, Callback#, GEOPOS]

47
48

49
50

Figure B-2:

51

ELID With Successful CAS Push

52

a. The MS originates an Emergency Services call across the air interface.

53

b. The BS sends the CM Service Request message to the MSC.

55

c. The MSC sends an Assignment Request message to the BS to request assignment of radio
resources.

54

56
57
58
59
60

B-2

ANSI/J-STD-036-B

1
2

d. The BS sends a Channel Assignment message over the paging channel of the radio interface
to initiate the establishment of a radio traffic channel.

3
4
5
6

e. Once the BS acquires the reverse traffic channel it sends the BS acknowledgment order.
f. The MS acknowledges the reception of the BS order by sending the MS acknowledgment
order.

7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

g. The BS sends the Service Connect Message to the MS specifying the service configuration
for the call.
h. The MS sends the Service Connection Complete Message to the BS acknowledging the
service configuration for the call.
i. The BS sends the Assignment Complete message to the MSC after the radio traffic channel
and terrestrial circuit have been fully interconnected.
j. The MSC requests the position of the MS by sending an OrignationRequest INVOKE to
the MPC.
k. The MPC sends an SMSDeliveryPointToPoint INVOKE with the IS-801 message encapsulated towards the appropriate PDE (in this case a LPDE connected to the BS).
l. The MSC sends the ADDS message encapsulating the Position Location Data to the BS/
LPDE.
m. The BS/LPDE places the MS Measurement Request in a Data Burst Message and sends it
to the MS.
n. The MS returns the MS Measurement Response message containing the MS's current information of its location in the Data Burst Message to the BS.
o-p Same as Step m-n if the LPDE requires additional information from the mobile. Note:
Although only shown in Figure B2, Steps o.-p. may occur in other scenarios as well.

30
31
32
33
34
35
36
37
38
39
40
41

q. The BS/LPDE calculates the position of the MS based on MS Measurement information


and the LPDE's measurement. The BS/LPDE sends the ADDS message encapsulating the
Position Location Data to the MSC.
r. The MSC sends an SMSDeliveryPointToPoint RETURN RESULT to the MPC containing
the positioning information (e.g., latitude/longitude) received from the BS/LPDE via the
encapsulated IS-801 message. Note: In some cases (e.g., Request for MS Capabilities)
Steps k.-r. could be repeated.
s. The MPC sends an OriginationRequest RETURN RESULT to the MSC.
t. The MSC extends the call to the ESNE without delay.

42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

B-3

ANSI/J-STD-036-B

B.2.2

ELID with Successful CAS Push with Anchor MPC Interaction After
Handoff

1
2
3

This scenario shows a position request and delivery of position information with a CAS push during
call setup. The position is requested from the Serving MPC.
Serving System

Anchor System

4
5
6
7
8

MS

BS/
LPDE

MSC

MPC

MSC

MPC

ESNE

10
11

Call In Progress

12
13

ESC call invocation

FLASHREQ [911, ESRD]


FRT

flashreq

ORREQ [MPCAP]

f
g

ISPOSREQ [MOBINFO,POSREQTYPE(initial),MPCAP]
SMDPP[ServiceIndicator, ActionCode, SMS_BearerData]
i

ADDS (Position Location Data)


j

ADDS (Position Location Data)

16
17

19
20
21
22
23

Data Burst (MS Measurement Request)


IPRT
Data Burst (MS Measurement Response)

15

18

ISPOSREQ [Callback# or MSID, POSREQTYPE (initial)]


ISPOSREQFWD [MSID, POSREQTYPE(initial),MPCAP]

14

24
25
26
27
28

ORT

SMT

IPRFT

POST

IPRT

smdpp[SMS_BearerData]

l
m
n

isposreq[POSINFO]
o

isposreqfwd [POSINFO]
isposreq [POSINFO]

31
32
33
34
35

37
38

Call Setup [Callback#, ESRD, GEOPOS]

30

36

orreq [GEOPOS]

29

39
40
41

42
43
44

Figure B-3:

ELID with Successful CAS Push with Anchor MPC Interaction After Handoff
a. A non-Emergency Services call is in progress between the MS and MSC(s).
b. The MS invokes an Emergency Services call origination via a Flash.
c. The Serving MSC notifies the next switch in the handoff chain of the event with a FlashRequest INVOKE.
d. The Anchor MSC acknowledges the event with a FlashRequest RETURN RESULT.

45
46
47
48
49
50
51
52
53
54

e. Same as Section B.2.1, Step j.


f. The MPC determines that the MS identified by the callback number has handed off to a
different system and sends an IntersystemPositionRequest INVOKE to the Anchor MSC.

55
56
57
58
59
60

B-4

ANSI/J-STD-036-B

1
2
3

g. The Anchor MSC, determining that that the MS identified by the callback number is
handed off, forwards the position request in an IntersystemPositionRequestForward
INVOKE.

4
5
6
7

h. The Serving MSC, determining that that a position has been requested, sends an IntersystemPositionRequest INVOKE to the Serving MPC including the mobile information.
i.-n. Same as Section B.2.1, Steps k-n and q-r.

8
9
10
11
12
13
14
15
16
17

o. The Serving MPC sends the position information in IntersystemPositionRequest RETURN


RESULT to the Serving MSC.
p. The Serving MSC sends the position information in IntersystemPositionRequestForward
RETURN RESULT to the Anchor MSC.
q. The Anchor MSC sends the position information in IntersystemPositionRequest RETURN
RESULT to the Anchor MPC.
r-s Same as Section B.2.1, Steps s.-t.

18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

B-5

ANSI/J-STD-036-B

B.2.3

ELID with Timed-Out CAS Push and NCAS Pull

1
2

This scenario shows a position request and delivery of position information using NCAS pull.

3
4

Serving System

5
6
7

BS/
LPDE

MS

MSC

MPC

ESME

ESNE

8
9
10

call origination (E911)

T303

Assignment Request

Channel Assignment
d

BS ACK Order

T10

MS ACK Order

11
12

CM Service Request

13
14
15
16
17
18
19
20

Service Connect

Service Connect Completion

21
22

Assignment Complete

ORREQ [MSID, MOBINFO, MPCAP]

26

27
28

ADDS (Position Location Data)


ORT

24
25

SMDPP[ServiceIndicator, ActionCode, SMS_BearerData]

Data Burst (MS Measurement Request)

23

29
30

POST

Data Burst (MS Measurement Response)

31
32
33

SMT

POST Expires

34
35

orreq

Call Setup [Callback#, ESRD]

Call in Progress

37
38
39

ADDS (Position Location Data)

40
41
42

smdpp[SMS_BearerData]

ESPOSREQ [Callback#, POSREQTYPE(initial)]


esposreq [POSINFO]

36

ESPRT

43
44

45
46

47
48

Figure B-4:

ELID with Timed-Out CAS Push and NCAS Pull


a.-n. Same as Section B.2.1, Steps a.-n.
o. When the POST timer expires, the MPC sends the OriginationRequest RETURN RESULT
to the MSC without the position information.

49
50
51
52
53
54
55

p. The MSC extends the call to the ESNE without further delay.
q. The Emergency Services call between the MS and the ESNE is in progress.
r-s Same as Section B.2.1, Steps q-r.

56
57
58
59
60

B-6

ANSI/J-STD-036-B

1
2

t. The ESME determines that updated positioning information on the MS is required and
sends an EmergencyServicesPositionRequest INVOKE to the MPC.

3
4
5

u. The MPC sends the MS position in the EmergencyServicesPositionRequest RETURN


RESULT.

6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

B-7

ANSI/J-STD-036-B

B.2.4

ELID With NCAS Pull of Position

1
2

This scenario shows the request of updated position information using an NCAS pull after the call
has been delivered to the ESNE.

3
4
5

Serving System

6
7
8

MS

BS/
LPDE

MSC

MPC

ESME

ESNE

10
11

Call in Progress

ESPOSREQ [Callback#, POSREQTYPE(update)]


SMDPP[ServiceIndicator,ActionCode,SMS_Bearerdata]
ADDS (Position Location Data)
Data Burst (MS Measurement Request)
Data Burst (MS Measurement Response)

13

b
c
d

ESPRT
SMT

12

14
15
16
17
18

e
f

ADDS (Position Location Data)


g

smdpp[SMS_BearerData]

19
20
21
22
23

esposreq [POSINFO]
i

24
25
26
27

Figure B-5:

28

ELID With NCAS Pull of Position

29

a. An Emergency Services call is in progress between the MS and ESNE.

30

b. The ESME determines that updated positioning information on the MS is required and
sends an EmergencyServicesPositionRequest INVOKE to the MPC.

32

c. The MPC requests the position of the MS by sending an SMSDeliveryPointToPoint


INVOKE to the MSC.
d-g Same as Section B.2.1, Steps ln and q.

31

33
34
35
36
37
38

h. The MSC sends the MS position in an SMSDeliveryPointToPoint RETURN RESULT to


the MPC.
i. The MPC acknowledges the message with an EmergencyServicesPositionRequest
RETURN RESULT.

39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

B-8

ANSI/J-STD-036-B

1
2

B.2.5

Successful ELID Position Request After Handoff


This scenario shows the request of updated position information using an NCAS pull after the call
has been delivered to the ESNE.

3
4
5

Serving System

Anchor System

6
7
8

MS

BS/
LPDE

MSC

MPC

MSC

MPC

ESME

9
10

ESPOSREQ[Callback#, POSREQTYPE(update)]

11

ISPOSREQ [Callback#, POSREQTYPE (update)]

12
13

ISPOSREQFWD [MSID, POSREQTYPE(update),MPCAP]

14

15

ISPOSREQ [MOBINFO,POSREQTYPE(update),MPCAP]

16

SMDPP[ServiceIndicator, ActionCode, SMS_BearerData]

17

18

ADDS (Position Location Data)

19
20
21
22
23
24

Data Burst (MS Measurement Request)


Data Burst (MS Measurement Response)
ADDS (Position Location Data)

ESPRT

IPRT
IPRFT

IPRT

SMT
i

25

smdpp[SMS_BearerData]

26

isposreq[POSINFO]

27

28

isposreqfwd [POSINFO]

29

isposreq [POSINFO]

30
31

esposreq[POSINFO]

32

m
n

33
34
35

Figure B-6:

Successful ELID Position Request After Handoff

36
37
38
39
40
41
42

a. The ESME determines that updated positioning information on the MS is required and
sends an EmergencyServicesPositionRequest INVOKE to the MPC.
b. The MPC requests the position of the MS by sending an IntersystemPositionRequest
INVOKE to the MSC.
c-m. Same as Section B.2.2, Steps g.-q.

43
44
45

n. The MPC acknowledges the message with an EmergencyServicesPositionRequest


RETURN RESULT.

46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

B-9

ANSI/J-STD-036-B

B.2.6

Autonomous PDE Push and ELID NCAS Pull

1
2
3

This scenario describes the ability of the LPDE to push position information to the MPC.

Serving System

5
6
7

BS/
LPDE

MS

MSC

MPC

ESME

ESNE

8
9
10

Call in Progress

Data Burst (MS Measurement Request)

12

Data Burst (MS Measurement Response)


c

ADDS (Position Location Data)

SMDPP[SMS_BearerData]
SMT

11

smdpp[ ]

ESPOSREQ [Callback#, ESRD, POSREQTYPE(update)]

14
15
16
17
18
19
20

esposreq [POSINFO]

13

ESPRT

21
22

23
24

Figure B-7:

Autonomous PDE Push and ELID NCAS Pull

25
26

a. An Emergency Services call is in progress between the MS and ESNE.

27
28

b. At some point in time during the call, the BS/LPDE sends the Data Burst message encapsulating the MS Measurement Request to the MS.
c.-d.

Same as Section B.2.1, Steps n and q.

29
30
31
32

e. The MSC relays the updated position information by sending an SMSDeliveryPointToPoint INVOKE to the MPC.
f. The MPC acknowledges the receipt of the position information by sending an SMSDeliveryPointToPoint RETURN RESULT.
g. The ESME determines that updated positioning information on the MS is required and
sends an EmergencyServicesPositionRequest INVOKE to the MPC.
h. The MPC sends the MS position in the EmergencyServicesPosition-Request RETURN
RESULT.

33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

B-10

ANSI/J-STD-036-B

1
2

B.2.7

MPC Request for CDMA Pilot Strength Measurements


This scenario shows a position request and delivery of position information using the PSMM
method. This could occur during an ELID CAS push during call setup, or an NCAS pull when the
MS is on the traffic channel. For this reason the scenario begins with a position request
(i.e., ISPOSREQ) which would follow an ORREQ (for CAS push) or an ESPOSREQ (for NCAS
pull).

3
4
5
6
7
8
9
10
11

MS

12

BS/
LPDE

MSC

MPC

13

ISPOSREQ[MSID, POSREQTYPE, CDMAPSMMCount=0]

14

15

RMP Request(PSMMCount=0)

16

PSM Request Order

17
18

IPRT

PSMM

19

c
d

20

RMP Response (GEOLOC)

21

isposreq[POSRSULT, POSINFO]

22

23
24
25

Figure B-8:

MPC Request for CDMA Pilot Strength Measurements

26
27
28
29
30
31
32
33
34
35
36

a. The MPC examines the MPCAP parameter (previously received in the ORREQ or
isposreq) and determines that the MS supports PSMM (e.g., MPCAP = 0 Unknown) and
that the PDE is co-located at the BS (i.e., LPDE). The MPC sends an InterSystemPositionRequest INVOKE with the CDMAPSMMCount parameter set to 0 indicating that the
PDE located at the BS will determine the count of PSMMs to collect from the MS.
b. The MSC sends a Radio Measurement Position Request message relaying the PSMMCount
to the BS/LPDE.
c. The BS/LPDE determines the number of PSMMs required to calculate the MSs position
and sends the initial Pilot Strength Measurement Request Order to the MS.

37
38
39
40
41

d. The MS responds with a Pilot Strength Measurement message including pilots from the
Active and Candidate Lists.
Note: Steps c and d are repeated over the air interface based on the PSMMCount value
received from the LPDE.

42
43
44
45
46
47
48
49
50
51

e. The BS sends a Radio Measurement Position Response message to the MSC with the
Geographic Location information element containing the MSs position. For the failure
case, the Cause information element is sent instead of the Geographic Location information
element.
f. The MSC relays the contents of the Radio Measurement Position Response message to the
MPC in the InterSystemPositionRequest RETURN RESULT. The Geographic Position is
contained in the PositionInformation parameter for the successful case the Cause information is contained in the PositionResult parameter for the failure case.

52
53
54
55
56
57
58
59
60

B-11

ANSI/J-STD-036-B

Annex C:

Non-dialable Callback Numbers


(Normative)

1
2
3
4

This annex is normative and is considered part of this Standard.

There are several situations when a mobile station does not have a valid callback number. Examples
of these situations include, but are not limited to non-initialized mobiles, mobile phones whose
subscription has expired, mobile phones that fail authentication, mobile phones without a subscriber
identity module inserted, mobile phones from certain other countries, mobile phones from a service
provider that does not have a roaming agreement with the current serving service provider, mobile
phones donated to charitable organizations with the sole purpose of 9-1-1 access and other mobile
stations referred to as 9-1-1 Only devices. If the MS does not have a valid callback number, a nondialable callback number derived from the ESN, pseudo-ESN (derived from the MEID) or IMEI
shall be used to identify the emergency services caller.

8
9
10
11
12
13
14
15
16
17

ESN
known

IMEI
known

Non-dialable Callback number format

18

The digits 911 followed by the 7 least significant digits of the decimal representation
of the ESN. These 7 digits are determined byconverting the 24 least significant bits
of the ESN (treated as an unsigned binary integer) to decimal. The result of this
conversion is padded on the left with zeroes, if necessary, to obtain 7 decimal digits.
In the case of mobile stations with an MEID, the pseudo-ESN (derived from the
MEID) should be used in place of ESN, as described above.
In the case of mobile stations which transmitted a UIMID (from an inserted
R-UIM), the UIMID should be used as described above, instead of the pseudo-ESN,
if both are received.

20

911 + last 7 digits of IMEI expressed as a decimal number

28

19

21
22
23
24
25
26
27

29
30

These will be inserted into the MobileDirectoryNumber field or the MSISDN field by the MSC as
appropriate. The MPC or GMLC will then populate the non-dialable callback number into the
callbacknumber field sent in the esposreq to the ESME.
The non-dialable callback number described in the table above for mobiles with an IMEI should be
used when the MS identifies itself with IMEI in the connection management service request, or
when the MS identifies itself with TMSI or IMSI in the connection management service request, but
the network fails to verify the subscribers subscription or roaming agreement.

31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

C-1

ANSI/J-STD-036-B

1
2

Annex D:

3
4
5

Parameter Mapping for Interconnection


(Normative)

This annex is normative and is considered part of this Standard.

It provides information for population of ISUP and MF signaling parameters depending on the various modes
used to convey information to the PSAP.

7
8
9
10
11

D.1

ISUP Initial Address Message (IAM)

12

This section provides information for population of ISUP IAM signaling parameters.

13
14
15
16
17
18
19

D.1.1

ISUP Initial Address Message Parameter Contents for


Wireline Compatibility Mode (ESRK)
In this mode only the ESRK is sent as the ANI over dedicated trunks to the Selective Router because the trunk
between the Selective Router and the PSAP supports transport of only one 7/10 digit number.

20
21

orreq Parameters

ISUP Parameters

Value

n/a

Called party number

911, 11, or 1

Digits (Dialed)

n/a

See Note 1

TerminationList

n/a

See Note 3

MDN

Calling party number


(see Note 2)

ESRK

DMH_BillingDigits

Charge Number (see Note 2)

ESRK

GenericDigits

Generic digits parameter

n/a

GeographicPosition

Calling geodetic location

n/a

n/a

Originating Line Information (OLI)

If included, use value 00 (POTS)

22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

Notes:
1. For an ESC, the orreq Digits (Dialed) parameter may contain either the digits 911, 11, 1, the
ESRD or the assigned ESRK for the call.
2. The Charge Number, Calling Party Number or both may be included in the IAM message.
3. For an ESC, the orreq TerminationList parameter, if present, may contain either the ESRD or
the assigned ESRK for MSC routing as PSTNTermination(DestinationDigits).

48
49
50
51
52
53
54
55
56
57
58
59
60

D-1

ANSI/J-STD-036-B

D.1.2

ISUP Initial Address Message Parameter Contents for NCAS


In this mode both an ESRD and the MDN are sent in the IAM, assuming that the trunk between the
Selective Router and the PSAP supports transport of at least two 7/10 digit numbers.

1
2
3
4
5
6

orreq Parameters

ISUP Parameters

Value

Digits(Dialed)

Called party number

(911, 11, 1) or PSAP DN or


ESRD (see Note 1)

7
8
9
10

TerminationList

n/a

See Note 4

MDN

Calling party number


(see Note 3)

MDN or the non-dialable callback


number

Charge Number (see Note 3)

MDN or the non-dialable callback


number

11
12
13
14
15

DMH_BillingDigits
GenericDigits

16
17
18

Generic digits parameter


(see Note 2)

ESRD

GeographicPosition

Calling geodetic location

n/a

21

n/a

Originating Line Information (OLI)

If included, use value 61 (cellular/


wireless PCS type 1) or 62
(cellular/wireless PCS type 2)

23

19
20

22

24
25
26
27

Notes:

28

1. 911, 11, 1 is used as the Called party number if the MSC uses dedicated trunks to the
Emergency Services Network Entity (ESNE) to route the Emergency Services Call
(ESC). The directory number of the PSAP is used as the called party number if the MSC
uses a shared trunk to route the ESC to the ESNE. The ESRD may be used on dedicated
trunks that do not support the ISUP Generic Digits parameter.

29
30
31
32
33
34

2. The Type of Digits field within the Generic Digits Parameter should be set to indicate
Location Identification Number.
3. The Charge Number, Calling Party Number or both may be included in the IAM
message.

35
36
37
38
39

4. For an ESC, the orreq TerminationList parameter, if present, may contain either the
ESRD (routed on a dedicated trunk group) or the PSAP DN (routed on a shared trunk
group) as PSTNTermination(DestinationDigits).

40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

D-2

ANSI/J-STD-036-B

1
2
3

D.1.3

ISUP Initial Address Message Parameter Contents for CAS


In this mode the initial position of the mobile is also sent in the IAM.

4
5
6
7
8

orreq Parameters

ISUP Parameters

Value

Digits(Dialed)

Called party number

(911, 11, 1) or PSAP DN or


ESRD (see Note 1)

TerminationList

n/a

See Note 4

MDN

Calling party number


(see Note 3)

MDN or the non-dialable callback


number

DMH_BillingDigits

Charge Number (see Note 3)

MDN or the non-dialable callback


number

GenericDigits

Generic digits parameter


(see Note 2)

ESRD

GeographicPosition

Calling geodetic location

geographic position

n/a

Originating Line Information (OLI)

If included, use values 61 or 62

9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

Notes:
1. 911, 11, 1 is used as the Called party number if the MSC uses dedicated trunks to the
Emergency Services Network Entity (ESNE) to route the Emergency Services Call (ESC).
The directory number of the PSAP is used as the called party number if the MSC uses a shared
trunk to route the ESC to the ESNE. The ESRD may be used on dedicated trunks that do not
support the ISUP Generic Digits parameter.
2. The Type of Digits field within the Generic Digits Parameter should be set to indicate
Location Identification Number.
3. The Charge Number, Calling Party Number or both may be included in the IAM message.
4. For an ESC, the orreq TerminationList parameter, if present, may contain either the ESRD
(routed on a dedicated trunk group) or the PSAP DN (routed on a shared trunk group) as
PSTNTermination(DestinationDigits).

39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

D-3

ANSI/J-STD-036-B

D.2

Feature Group D (FGD) MF Signaling

This section provides information for population of FGD MF signaling parameters.

4
5

POI-T8
Wireless
Network
Element

6
7

ESNE

8
9
10
11

OFF-HOOK

Seize

12
13
14

WINK

Outpulse Control

16
17

KP + (II + ANI) + ST + KP + 7/10D + ST


see Table D-1: for population of the ANI & 7/10D

1st Stage
Address Field

15

18
19
20
21

WINK

Acknowledge
(Optional)

22
23
24

Audible Tones and Announcements

Call Progress
Signals

25
26
27

OFF-HOOK

Answer

28
29
30
31

Conversation

32
33

Disconnect *

ON-HOOK

34
35
36
37

Disconnect *

ON-HOOK

38
39
40

* The direction of these signals is interchangeable

41
42
43

Figure D-1:

Wireless Network Origination (Direct Connection) MF Signaling Scenario over TIA/


EIA-93 POI-T8 Interface

44
45
46

Table D-1:

Feature Group D Parameter Contents for NCAS Signaling

47
48

orreq Parameters

MF Parameters

Value

MDN or DMH_BillingDigits or
both

ANI

MDN or the non-dialable callback


number

Digits(Dialed)

7/10 Digits

49
50
51
52
53

ESRD

54
55
56
57
58
59
60

D-4

ANSI/J-STD-036-B

1
2

D.3

CAMA MF signaling

3
4
5

Wireless
Network
Element

6
7
8

ESNE

9
10
11

OFF-HOOK

Seize

12
13
14

WINK

15
16

KP + Digits + ST
see Table D-2: for population of the Digits

17
18
19
20

STEADY OFF-HOOK

21
22
23

KP + X + 7 Digit ANI + ST
see Table D-2: for population of the Digits

24
25
26
27

ON-HOOK

Disconnect

28
29
30

ON-HOOK

Disconnect

31
32
33

* The direction of these signals is interchangeable

34
35
36
37

Figure D-2:

Wireless Network Origination using CAMA Signaling

Table D-2:

CAMA Parameter Contents for NCAS Wireline Compatibility (see Note 1)

38
39
40
41
42
43
44

orreq Parameters

CAMA Parameters

Value

MDN or DMH_BillingDigits or
both

ANI

ESRK

Digits(Dialed)

Digits

911,1,11

45
46
47
48
49
50
51

Notes:
1. A mode in which only the ESRK is sent as the ANI to the Selective Router because the trunk
between the Selective Router and the PSAP supports transport of only one 7/10 digit number.

52
53
54
55
56
57
58
59
60

D-5

ANSI/J-STD-036-B

D.4

Functionality of Parameters for ESME and ESN

1
2
3

Parameter used by
ESNE for routing

NCAS Wireline
Compatibility
(see Note 1)

NCAS

ESRK

ESRD

CAS

4
5
6

Position or ESRD

7
8
9

Parameter used by
ESME for NCAS pull

ESRK

MDN or (non-dialable
callback number plus
ESRD)

MDN or non-dialable
callback number

ESRD

ESRD

10
11
12
13

Parameter used by
ESME to choose MPC

ESRK

14
15
16

Notes:

17
18

1. A mode in which only the ESRK is sent as the ANI to the Selective Router because the trunk
between the Selective Router and the PSAP supports transport of only one 7/10 digit number.

19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

D-6

ANSI/J-STD-036-B

1
2

Annex E:

Mapping Between ANSI-41 and ISUP Digit


Parameters

3
4
5
6
7

This annex is informative and is not considered part of this this Standard.
The following table shows the suggested mapping between the digit parameters in ANSI-41 and ISUP.

8
9

ANSI-41

ISUP

10
11

Sub-field

Name

Value

Sub-field

Name

Value

12
13
14

Nature of
Number

National
International

xxxxxxx0 Nature of
Address
xxxxxxx1

15
16

xxxxxx0x Address
presentation
Presentation Restricted xxxxxx1x restricted
indicator
Presentation allowed

17
18
19
20
21

Unique national number

0000011

Unique International
Number

0000100

Presentation allowed

00

Presentation restricted

01

User provided, not


screened

xx00xxxx Screening
Indicator

user provided, not


screened

00

User provided,
screening passed

xx01xxxx

user provided,
screening passed

01

User provided,
screening failed

xx10xxxx

user provided,
screening failed

10

Network provided

xx11xxxx

Network provided

11

22
23
24
25
26
27
28
29
30
31

Encoding

BCD

Numbering Plan Unknown

1 n/a

n/a

n/a

0000 Numbering Plan unknown

000

Telephony (E.164)

0010

ISDN Telephony
(E.164)

001

Data Numbering

0011

Data numbering

011

Telex Numbering

0100

Telex Numbering

100

Private

0111

Private

101

Digits

All

xxxx Address signal

ALL

Type of Digits

ESRD

32
33
34
35
36
37
38
39

xxxx

40
41

13 Type of Digits

42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

E-1

Location Identification
Number (LIN)

01101

ANSI/J-STD-036-B

Annex F:

MSC to Selective Router/PSAP


Interconnection Scenarios

This annex is informative and is not considered part of this this Standard.
The following table shows an example for the mappings between MSC to Selective Router interfaces and
Selective Router to PSAP interfaces.

1
2
3
4
5
6
7
8
9

MSC to
Selective
Router
Interface

Selective
Router to
PSAP
Interface

Scenario

Key Information Sent by the


Selective Router to the PSAP
(with call setup signaling)

CAMA

CAMA

Section D.1.1 ISUP Initial Address


Message Parameter Contents for Wireline
Compatibility Mode (ESRK)

10
11
12
13
14

ESRK

15
16
17

SS7 ISUP

CAMA

Section D.1.1 ISUP Initial Address


Message Parameter Contents for Wireline
Compatibility Mode (ESRK)

ESRK

18
19
20
21

3
4

Feature
Group D

E-MF/
ISDN

Section D.1.2 ISUP Initial Address


Message Parameter Contents for NCAS

Callback Number and ESRD

SS7 ISUP

E-MF/
ISDN

Section D.1.2 ISUP Initial Address


Message Parameter Contents for NCAS

Callback Number and ESRD

22
23
24
25
26

SS7 ISUP

ISDN

Section D.1.3 ISUP Initial Address


Message Parameter Contents for CAS

Callback Number, ESRD and


Latitude/Longitude

27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

F-1

ANSI/J-STD-036-B

1
2

Annex G:

Transport Protocols for Reference Point E2

This annex is informative and is not considered part of this Standard.

4
5

It provides information on transport protocols that may be used for reference point E2. The protocol
stacks that may be used for reference point E2 at shown in Figure G-1. Each protocol stack in Figure
G-1 provides different capabilities in terms of performance and reliability.

6
7
8
9
10
11
12

J-STD-036

J-STD-036

J-STD-036

J-STD-036

J-STD-036

TCAP

TCAP

TCAP

TCAP

TCAP

SCCP

SUA

SCCP

13
14
15
16
17
18
19
20

M3UA

MTP3

TCP
Transport
Adaptation
Layer

21
22

SCTP

SCTP

TCP

IP

IP

MTP2

IP

IP

Physical

Physical

MTP1

Physical

Physical

23
24
25
26
27
28
29
30
31

32
33
34

Figure G-1:

Protocol Stacks for Reference Point E2

35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

G-1

ANSI/J-STD-036-B

G.1 TCP/IP Protocol Stack

1
2

The protocol stack used for the E2 interface is shown in figure G-2. The TCAP ASN.1 encoded
message structure is directly encapsulated within TCP/IP packets without additional layers of
encoding. IP provides the capability to route the message, which replaces the need for the
Signalling Connection Control Part (SCCP) portion of the standard SS7 message. The intervening network elements (e.g., routers and firewalls) need only use IP to correctly route the
session set up message and subsequent packets.

3
4
5
6
7
8
9
10
11
12

ESME

Router

Router

MPC

13
14
15
16
17
18

TCAP

TCAP

TCP

TCP

19
20
21
22

IP

IP

IP

IP

Physical

Physical

Physical

Physical

23
24
25
26

Figure G-2:

TCP/IP Protocol Stack for E2 Interface

27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

G-2

ANSI/J-STD-036-B

1
2

G.1.1

Network Architecture
Figure G-3 represents the data network architecture between the wireless network and the wireline
network to allow the caller's location to be returned to the PSAP. Each PSAP has links to both of the
mated, geographically distributed ESMEs. For the interconnection between the MPC and ESME,
three different configurations are anticipated. The first is where the ESME connects to a MPC that
is a Simplex Node (Links A, C). In this case a high availability MPC will be deployed in the wireless
network. Both ESMEs will steer queries to this MPC. The second is a Redundant Node configuration. In this configuration each ESME will have a companion MPC with which it communicates
(Links A, D). Each ESME will steer queries to its companion MPC. The third configuration is where
the ESME complex and the MPC complex are fully connected. Therefore, each ESME has a logical
TCP/IP connection to both MPCs. The network connection between the Emergency Service
Provider and the Wireless Carrier is not expected to be a public network (e.g., the network may be
a private packet-based network or dedicated point-to-point environment).

3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Redundant side

19

Redundant side

20
21
22

ALI/ESME

23

MPC

MSC

24
25
26
27

Redundant
side

28
29
30

PSAP

31

PDE

32
33
34
35
36

Key
Many

One

Many

Many

37
38
39
40

One

Zero or one

41
42

Figure G-3:

Wireless E911 Entity Relationship Diagram

43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

G-3

ANSI/J-STD-036-B

G.1.2

Session Establishment

1
2

In this configuration, the TCP/IP address and port are agreed upon between the owners of the ESME
and the MPC. By convention, the ESME is the TCP/IP server and the MPC is the TCP/IP client. The
sessions are established via sockets where the MPC establishes the connection to the ESME. Upon
system start up, the ESME will listen to the designated port and the MPC will initiate session set up
to the designated TCP/IP address and port. Once the socket session is established, the application
may begin the query and response handshake.

3
4
5
6
7
8
9
10

G.1.3

Emergency Service Protocol (ESP) Messages

11
12

The ESP query has two formats, identified here as Format A and Format B. For Format A, the
Emergency Service Routing Key (ESRK) is passed in the query. For a Format B message the
Callback Number (CBN) and, optionally, the Emergency Service Routing Digits (ESRD) are passed.
Parameters of ESME Identification and Position Request Type are sent for both formats of
messages. For the ESP response, the salient parameters are the CBN, Latitude, and Longitude. Once
the ESME receives these, it will format them with a local ALI record associated with the ESRK/
ESRD and return the information to the PSAP.

13

In addition to query and response, there will be heartbeat messages between the ESME and the MPC
to verify the integrity of the links. These will be initiated by the ESME and responded to by the MPC.
The ESME will query with the PositionRequestType=4 (Test) and the EmergencyServiceRoutingKey=0. The MPC should respond with the PositionResult=10 (Test). These messages only will
be sent during periods of inactivity of 60 seconds (a configurable parameter) on a link to verify the
integrity of the application and socket connection.

21

14
15
16
17
18
19
20

22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

G-4

ANSI/J-STD-036-B

1
2
3
4
5
6
7
8
9
10
11

Annex H:

Use of ESRD in E911 Call Setup as 3-Way


Call Following Inter-MSC Handoff

This annex is informative and is not considered part of this Standard.


It shows various methods for using an ESRD solution for an E911 call setup as a 3-Way call
following inter-MSC handoff. The fundamental problem is that the ESRD supplied by the Serving
MSC in a ANSI-41 FlashRequest INVOKE identifies the cellsite/sector correctly, but will lead the
PSAP to query an MPC associated with the Serving MSC, instead of the Anchor MSC.

12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

H-1

ANSI/J-STD-036-B

H.1

Inter-MSC Three-Way Call to PSAP

1
2

This scenario shows a CAS push of position after a handoff has occurred. This scenario applies
to a call that handed off to another MSC and then initiated a 3-way call to the PSAP.

3
4
5
6

Anchor

Serving

7
8
9

MS

PDE

MPC

MSC

MSC

MPC

10

ESNE

11
12
13

ESC Invocation

14
15

FLASHREQ [Digits(dialed), ESRD]

16

FRT

17
18

flashreq

19
20

ORREQ [MPCAP]

21
22
23

ISPOSREQ [MPCAP, POSREQTYPE(initial)]


e

24
25

ISPOSREQFWD [MSID, POSREQTYPE(initial), MPCAP]


f

ISPOSREQ [MOBINFO, POSREQTYPE(initial), MPCAP]

26
27
28

29
30

GPOSREQ [MOBINFO, POSREQTYPE(initial), MPCAP]


IPRT
IPRT
GPRT
ORT
gposreq [POSINFO, POSRSULT(updated)]
IPFT

31
32
33

POST

isposreq [POSINFO, POSRSULT(updated)]

34
35

36
37

isposreqfwd [POSINFO, POSRSULT(updated)]

38

isposreq [POSINFO, POSRSULT(updated)]

39
40

41
42

orreq [GEOPOS]
Call Setup IAM [GDP(ESRD), CgPN(Callback #), CGL(position)]

43

44
45

46
47

Figure H-1:

Inter-MSC Three-Way Call to PSAP

48
49

a. The MS invokes an Emergency Services Call via 3-way calling while another call is in
progress.

50

b. The Serving MSC notifies the next switch in the handoff chain of the event with a
FLASHREQ.

53

c. The Anchor MSC acknowledges the event with a flashreq.


d. The Anchor MSC, determining that anchor MPC interaction is required, requests
position with an ORREQ to its MPC.

51
52

54
55
56
57
58
59
60

H-2

ANSI/J-STD-036-B

e. The Anchor MPC, requests position from the Anchor MSC with an ISPOSREQ.

2
3
4
5
6

f. The Anchor MSC,determining that the MS identified by the MSID has handed off,
forwards the request in an ISPOSREQFWD.
g. The Serving MSC forwards the request for position to its MPC with an ISPOSREQ
including the mobile information.

7
8
9
10
11
12
13
14
15
16

h. Since there is no cached position information (i.e., GPOSDIR not received), the MPC
forwards the request for position to the appropriate PDE with a GPOSREQ including the
mobile information.
Optionally, a handset-based solution may have PDE to MS communication. See Section 2
PDE to MS Scenarios for Handset-Based PDE on page 4-28.
i. In this case, the PDE has not previously acquired the initial position of the MS. The PDE
determines the current position of the MS and returns the position information in a gposreq
with the PositionResult parameter set to Updated Position Returned.

17
18
19
20
21
22
23
24
25
26
27
28

j. The Serving MPC returns the position for the MS with an isposreq. Since the Serving MPC
did not receive an ORREQ or GPOSDIR, the returned Position Result is set to Updated
Position Returned.
k. The Serving MSC returns the position with an isposreqfwd.
l. The Anchor MSC returns the position with an isposreq.
m. The Anchor MPC returns the position with an orreq. The MPC caches the position received
as an initial position.
n. The MSC sets the call up toward the ESNE using an IAM including the received
geographic position.

29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

H-3

ANSI/J-STD-036-B

H.2

Inter-MSC Three-Way Call to PSAP using SAMPS

This scenario shows the delivery of Position Information to the PSAP after an inter-MSC call has been handed
off.

Serving

Anchor

4
5
6
7

MS

MSC

MSC

PDE

MPC

CRDB

ESME

ESNE

9
10
11

ESC Invocation
a

12
13

FLASHREQ [Digits(dialed), ESRD]

14

FRT

15
16

flashreq

17
18

ORREQ [MSID, Callback#, ESRD, Digits(dialed)]

19

ORT

22
23

SMDBACK[SMS_TeleserviceID, SMS_BearerData, MSID]


f

SMDPP[SMS_TeleserviceID, SMS_BearerData(position information)]

24
25
26

27
28

SMT

SBT

20
21

R-DATA [SAMPS Emergency Position Report]

smdpp[ ]

29
30
31

smdback[ ]

POST

R-DATA ACCEPT[ ]

32
33

34
35

GPOSDIR[MSID, POSINFO]

36

GPDT

37
38

gposdir[ ]
l

39
40

POSROUTREQ [Position]

41

PRRT
posroutreq [Digits]

42
43

44
45

orreq [Digits(Dialed)(ESRK or ESRD)]

46

47
48

Call Setup [ESRK or (Callback# + ESRD)]


p

49
50

51
52

ESPOSREQ [ESRK or Callback#, POSREQTYPE(initial)]

53

54
55

esposreq[ESRD, Callback #, POSINFO] ESPRT


s

56
57
58

Figure H-2:

Inter-MSC Three-Way Call to PSAP using SAMPS

59
60

H-4

ANSI/J-STD-036-B

1
2

a. The MS invokes an Emergency Service Call via 3-way calling while another call is in
progress.

3
4
5
6

b. The Serving MSC notifies the next switch in the handoff chain of the event with a
FLASHREQ.
c. The Anchor MSC acknowledges the event with a flashreq.

7
8
9
10
11
12
13
14
15
16
17

d. The Anchor MSC initiates the ORREQ procedure indicating in the MPCAP parameter the
type of handset positioning that is supported.
e. The MS sends an Emergency Position Report message on the Digital Traffic Channel.
Note: Should the mobile require assistance data a SAMPS Position Assistance Request
message may be sent to the PDE (Designated SAMPS TS Address).
f. The Serving MSC sends an SMDBACK to the Anchor MSC containing the position information.
g. The Anchor MSC sends an SMDPP to the Anchor PDE with the position information.

18
19
20

h. The Anchor PDE sends an smdpp to the Anchor MSC.


i. The Anchor MSC sends an smdback to the Serving MSC.

21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

j. The Serving MSC sends the R-DATA Accept to the MS.


k. The Anchor PDE sends a GPOSDIR containing the position information to the Anchor
MPC.
l. The Anchor MPC sends a gposdir to the Anchor PDE.
m. Optionally, the Anchor MPC may decide that the route must be determined from the MSs
current latitude and longitude. The MPC uses the position to request routing translations
for an emergency service zone from the CRDB with the POSROUTEREQ.
n. The CRDB returns the digits representing an emergency service zone (ESZ) to the MPC
with a posroutreq.
o. The Anchor MPC selects a PSAP based on the emergency service zone from the CRDB or
from the latitude and longitude of the mobile based on local procedures. The Anchor MPC
then assigns and returns a unique routable call identifier (ESRK) for the particular PSAP
selected or an ESRD in the orreq. See Chapter 8 and normative Annex D for the population
of the signaling parameters.
p. The Anchor MSC routes the Emergency Service Call toward the PSAP selected by the
ESRK or ESRD. See normative Annex D for call setup signaling formats.
q. Some time later
r. The ESME requests the initial position.

44
45

s. The MPC returns the cached position.

46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

H-5

ANSI/J-STD-036-B

H.3

Inter-MSC Routing Based on Position Using Substitute ESRD for


NCAS ESNE
This scenario shows an Emergency Services Call (ESC) originated as the second leg of a 3-way call after
intersystem handoff. The MPC uses the mobiles current position to determine the appropriate ESNE. In this
example, the selected ESNE requires NCAS as shown in normative Annex D.1.2 . Sometimes Routing Based
on Position (e.g., latitude and longitude) leads to an ESNE that is not the same as that which a callers serving
cellsite/sectors ESRD (ESRD(SS)) would indicate to a selective router. When this happens and the ESNE
requires NCAS, the MPC may optionally select an ESRD that is appropriate for this ESNE (ESRD (AS)), so
that the selective router will select it, rather than the ESNE related to the ESRD(SS) that is related to the
callers serving cellsite/sector. Another problem that may arise is that the ESRD(SS) may route queries to the
Serving Systems MPC, rather than the MPC associated with the Anchor System.
Later, when an ESME requests initial position on an E2 data link, the MPC may optionally include the
ESRD(SS) as well as the position information in the esposreq return result, similar to the information flow
for wireline compatibility mode in the example shown for Routing Based on Position as in Chapter 4,
Section 1.3.2.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

H-6

ANSI/J-STD-036-B

Anchor

Serving

2
3
4
5

MS

PDE

MPC

MSC

MSC

MPC

CRDB

ESME

ESNE

6
7
8

ESC Invocation

FLASHREQ [Digits(dialed), ESRD(SS)]

10

11

FRT
flashreq

12
13

14

ORREQ [MSID, Callback#, ESRD(SS), Digits(dialed)]

15

16
17

ISPOSREQ [MSID,POSREQTYPE(initial)]

18

19

ISPOSREQFWD [MSID, POSREQTYPE(initial), MPCAP]

20

21
22

ISPOSREQ [MSID,MOBINFO,POSREQTYPE(initial),MPCAP,SCELLID]

23

24
25
26
27
28

GPOSREQ [MOBINFO, POSREQTYPE(initial), MPCAP]


h

GPRT IPRT
IPFT
gposreq [POSINFO, POSRSULT(updated)]

29
30

isposreq [POSINFO, POSRSULT(updated)]

IPRT
i

ORT

POST
j

31
32

isposreqfwd [POSINFO, POSRSULT(updated),MSCID(serving)]


k

33
34

isposreq [POSINFO, POSRSULT(updated),MSCID(serving)]

35

36
37

POSROUTREQ [Position]

38

PRRT
posroutreq [Digits]

39
40

41
42

orreq [Digits(Dialed),GD=ESRD(AS),MDN(Callback#)]

43
44

Call Setup [CdPN,CgPN=MDN,GDP=ESRD(AS)]

45

46
47

48
49

ESPOSREQ [Callback#(MDN),ESRD(AS), POSREQTYPE(initial)]

50

51

esposreq[POSINFO,ESRD(SS)]

52

53
54
55
56
57
58
59

ESPRT

Figure H-3:

Inter-MSC Routing Based on Position Using Substitute ESRD for NCAS ESNE
a. A call that has been handed-off from the Anchor MSC to the Serving MSC is in progress.
The MS invokes an Emergency Services Call.
b. The Serving MSC notifies the Anchor MSC of the event with a FLASHREQ. The digits
dialed and ESRD(SS) are included.

60

H-7

ANSI/J-STD-036-B

c. The Anchor MSC acknowledges the event with a flashreq.

1
2

d. The MSC analyses the digits dialed by the MS and sends an ORREQ to the Anchor MPC.
The ORREQ includes the ESRD(SS) from the FLASHREQ, the MSID in the MIN or IMSI
parameter and the MDN parameter. Since the MSs current radio information is unknown
to the anchor MSC, the ORREQ does not include MOB_INFO.
e. The Anchor MPC examines the ESRD(SS) received in the ORREQ and conditionally
determines that it is known to be associated with an ESZ that is marked as Routing Based
on Position . Since the ORREQ s MPCAP parameter does not indicate TDMA-SAMPS
(see Inter-MSC Three-Way Call to PSAP using SAMPS in this Annex) and since the
anchor MPC lacks the mobile s current radio information, the Anchor MPC sends an
ISPOSREQ to the Anchor MSC.

3
4
5
6
7
8
9
10
11
12
13

f. The Anchor MSC, determining that the MS identified by the MSID is handed off, forwards
the request in an ISPOSREQFWD.

14
15

g. The Serving MSC forwards the request for position to its MPC with an ISPOSREQ
including the MSs current radio information.

16

h. Since there is no cached position information at the serving system MPC (i.e., GPOSDIR
has not recently been received) and since the Serving MPC has the MSs current radio
information, the Serving MPC forwards the request for position to the appropriate PDE
with a GPOSREQ that includes the MSs radio information. Optionally, a handset-based
solution may have PDE to MS communication. See See Section 2 PDE to MS Scenarios
for Handset-Based PDE on page 4-28.

19

i. In this scenario, the PDE has not previously acquired the initial position of the MS. The
PDE determines the current position and returns the position information in a gposreq with
the PositionResult parameter set to Updated Position Returned.
j. The Serving MPC returns the position for the MS with an isposreq. Since the Serving MPC
did not receive an ORREQ or GPOSDIR, the returned Position Result is set to Updated
Position Returned. The Serving MPC does not cache the position information since only
the Anchor MPC will be able to reliably locate the mobile for subsequent location update
requests, regardless of where the mobile travels during the 3-way E911 call.
k. The Serving MSC returns the position information with an isposreqfwd and includes
MSCID(Serving).
l. The Anchor MSC returns the position information with an isposreq that includes the
optional parameter MSCID(Serving), which is cached by the Anchor MPC as initial
position.
m. Optionally, the MPC may use the MSs current position to request a routing translation for
an emergency services zone (ESZ) from the CRDB with a POSROUTREQ, i.e., Routing
Based on Position.
n. The CRDB returns the digits representing an emergency services zone (ESZ) to the MPC
with a posroutreq.

17
18

20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

o. The Anchor MPC selects an ESNE based on the ESZ from the CRDB or from the latitude
and longitude of the mobile based on local procedures. In this example, the Anchor MSC
is able to route to the selected PSAP that requires NCAS call setup and further, this ESNE
is not associated with the ESRD(SS) that was passed to the MPC via the FLASHREQ sent
to the MSC. This means the MPC must assign a routable address, e.g., ESRD(AS). The
MPC returns ESRD(AS), which a selective router may use to select the MPC-intended
PSAP, to the Anchor MSC in the orreq GenericDigits parameter. The selected ESME may
use the ESRD(AS) received from call setup to route its subsequent ESPOSREQ back to the
Anchor MPC that holds all the information about the ESC: the original ESRD(SS) that
represents the MSs serving cellsite/sector information and the MSs initial position information.

47
48
49
50
51
52
53
54
55
56
57
58
59
60

H-8

ANSI/J-STD-036-B

1
2

p. The Anchor MSC routes the Emergency Services Call (ESC) towards the ESNE selected
by the ESRD(AS).

3
4
5
6
7
8
9
10

q. Some time later


r. The Anchor MPC receives an ESPOSREQ including the MSs callback number (MDN)
because ESRD(AS) is associated with the Anchor MPCs E2 interface. This is a request for
initial position.
s. The Anchor MPC returns the position information and the callers serving cellsite/sector
information.

11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

H-9

ANSI/J-STD-036-B

H.4

Inter-MSC Routing Based on Cellsite/Sector for NCAS when


Serving and Anchor MPC are the same.
This scenario shows an Emergency Services Call (ESC) originated as the second leg of a 3-way call after
intersystem handoff. The MPC uses ESRD(SS) to select the appropriate ESNE. In this example, the selected
ESNE requires NCAS for call setup using ESRD(SS) and the ESRD is also associated with the MPC that
serves the Anchor MSC.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

H-10

ANSI/J-STD-036-B

1
2

Anchor

Serving

3
4
5
6

MS

PDE

MSC

MPC

MSC

CRDB

ESME

ESNE

7
8
9

ESC Invocation

10
11

FLASHREQ [Digits(dialed), ESRD(SS)]

12

FRT
flashreq

13
14

15
16

ORREQ [MSID, Callback#, ESRD(SS), Digits(dialed)]


d

17
18

ISPOSREQ [MSID,POSREQTYPE(initial)]

19

20

ISPOSREQFWD [MSID, POSREQTYPE(initial), MPCAP]

21

22
23
24

ISPOSREQ [MSID,MOBINFO,POSREQTYPE(initial),MPCAP,SCELLID]
g

25
26

GPOSREQ [MOBINFO, POSREQTYPE(initial), MPCAP]


h

27
28
29
30
31

GPRT IPRT
IPFT
gposreq [POSINFO, POSRSULT(updated)]
ORT
POST

IPRT
i

isposreq [POSINFO, POSRSULT(updated)]

32
33
34

isposreqfwd [POSINFO, POSRSULT(updated),MSCID(serving)]


k

35

isposreq [POSINFO, POSRSULT(updated),MSCID(serving)]

36

37
38

orreq [Digits(Dialed),GD=ESRD(SS),MDN(Callback#)]

39

40

Call Setup [CdPN,CgPN=MDN,GDP=ESRD(SS)]

41

42
43
44

45

ESPOSREQ [Callback#(MDN),ESRD(SS), POSREQTYPE(initial)]

46

47

esposreq[POSINFO]

48
49

ESPRT
q

50
51
52
53
54
55
56
57
58

Figure H-4:

Inter-MSC Routing Based on Cellsite/Sector for NCAS when Serving and Anchor
MPC are the same.
a. A call that has been handed-off from the Anchor MSC to the Serving MSC is in progress.
The MS invokes an Emergency Services Call.
b. The Serving MSC notifies the Anchor MSC of the event with a FLASHREQ. The digits
dialed and ESRD(SS) are included.The ESRD(SS) is associated with an MPC that is
associated with both the Serving and Anchor MSC s.

59
60

H-11

ANSI/J-STD-036-B

c. The Anchor MSC acknowledges the event with a flashreq.

1
2

d. The MSC analyses the digits dialed by the MS and sends an ORREQ to the Anchor MPC.
The ORREQ includes the ESRD(SS) from the FLASHREQ, the MSID in the MIN or IMSI
parameter and the MDN parameter. Since the MSs current radio information is unknown
to the anchor MSC, the ORREQ does not include MOB_INFO.
e. The Anchor MPC examines the ESRD received in the ORREQ and conditionally determines that ESRD(SS) is known to be associated with an ESZ that is marked as Routing
Based on Serving Cellsite/Sector . To unconditionally determine the correct ESZ, the
Anchor MPC sends an ISPOSREQ to the Anchor MSC in order to obtain the
MSCID(serving) since ESRDs are known to not be unique within North America, yet
ESRDs are known to be unique within an MSC.

3
4
5
6
7
8
9
10
11
12
13

f to k.

are the same as steps f through k in Section H.3 Inter-MSC Routing Based on Position
Using Substitute ESRD for NCAS ESNE on page -6.

l. The Anchor MSC returns the position information with an isposreq that includes the
optional parameter MSCID(Serving), which is cached by the Anchor MPC as initial
position.
m. The Anchor MPC selects an ESNE based on the callers serving cellsite/sector represented
by the ESRD(SS) passed in the FLASHREQ. In this example, the selected ESNE requires
NCAS call setup and further, the Anchor MSC is able to route to the selected PSAP. This
means the MPC must use a routable address, e.g., the ESRD(SS), and returns this information to the Anchor MSC in an orreq GenericDigits parameter. The selective router may
use ESRD(SS) to select the MPC-intended PSAP. Later the ESME will use this same
ESRD(SS) to route any of the ESMEs subsequent ESPOSREQ messages back to the MPC
that holds the MSs initial position information and to request location updates when initial
position has been either pushed or pulled. Since the Anchor MPC is the same MPC as the
Serving MPC, ESRD(SS) can be used for call setup. The MPC may include other optional
parameters in the orreq: see normative Annex D.1.2 and D.1.3 for specific recommendations.

14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

n. The Anchor MSC routes the Emergency Services Call (ESC) towards the ESNE selected
by the ESRD(SS).

33

o. Some time later

35

34

36

p. The Anchor MPC receives an ESPOSREQ including the MSs callback number (MDN)
because ESRD(SS) is associated with the Anchor MPCs E2 interface (as well as the
Serving MPC). This is a request for initial position.
q. The MPC need only include the position information.

37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

H-12