Ansi J STD 036 B

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
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
(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
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
(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

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

Mobile radio interface layer 3 specication. 1998.
GSM 04.31

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

Mobile radio interface layer 3 location services specication; Formats and coding. 1998.
4
5
6
7
GSM 08.08

Mobile Switching Centre - Base Station System (MSC BSS) interface; Layer 3 specication. 1998.
8
9
10
11
GSM 09.02

Mobile Application Part (MAP) specication. 1998.
12
13
14
15
GSM 09.08

Application of the Base Station System Application Part
(BSSAP) on the E-interface. 1998.
16
17
18
19
GSM 09.31

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
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
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
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
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
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
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
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
26
27
28
29
30
E11
CRDB - MPC
LSP
PositionRouteRequest
E12
MSC-PDE
ANSI-41
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 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

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
22
23
ORT
POST
orreq [GEOPOS]
24
25
26
27
28
Figure 4-2:

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
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
14
15
16
ORT
17

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

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.
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
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

ORT
19
orreq
20
21
POST
c
22
23
Call Setup [Callback#, ESRD]
27
28
ESPOSREQ [Callback#, ESRD, POSREQTYPE(initial)]

f

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
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.
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
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

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
20
21
ORT
22
POST
orreq
23
24
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:
39
40
41
42
43
44
45
46
47
48
49

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

GPRT
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
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

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
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
30
GPRT IPRT
IPFT
isposreq [POSINFO, POSRSULT(updated)]
IPRT
32
33
34
POST
ORT
31
35
36
37
isposreqfwd [POSINFO, POSRSULT(updated)]

k
38
39

l
40
41
42
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.
i. In this case, the PDE has not previously acquired the initial position of the MS. The PDE
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
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 [Digits]
PRRT
17
18
ORT
16
POST
19
20
21
22
23
24
25
Call Setup [ESRK or (Callback # + ESRD)]

f
26
27
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

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.
h. In this case, the PDE has not previously acquired the initial position of the MS. The PDE
13
14
15
i. ...some time later...

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.
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
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
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
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
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
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
c. The MPC acknowledges by sending a calltermrep.
d. Optionally, the MPC may notifiy the PDE, by sending a CALLTERMREP, that resources
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
ORT
14

GPRT
Call Release
15
16
17
18
POST
19
20
21
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

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.
GPOSREQ.
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
f. The MPC acknowledges by sending a calltermrep.
g. Optionally, the MPC may notify the PDE, by sending a CALLTERMREP, that resources
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
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
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

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

1
2
3
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:

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
13
14
15
16
SMT
17
18
19
21
23
Databurst [Bearer]
20
22
GPRT
Databurst [Bearer]
e
24
25
26
27
28
29
Databurst [Bearer]
30
31
32
33
34
35
SMT
36
37
smdpp [ ]
38
39
smdpp [ ]
40
41
42
gposreq[POSINFO]
43
44
45
Figure 4-20:
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
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
17
18
19
20
21
22
23
24
25
m. The PDE uses the received information to determine the MSs position and sends the
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
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
15
16
17
18
19
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
32
33
34
35
h
i
36
37
Databurst [Bearer]
38
39
SMDBACK [ServiceIndicator, SMS_BearerData]

k
40
41
42
43
SBT
44
SMT

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
60
4-32
2.1.3 Position Determination after Handoff
ANSI/J-STD-036-B
position capabilities.
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
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
q. The PDE uses the received information to determine the MSs position and sends the
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
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:

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
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
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:
50
51
52
53
54
55
56
57
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).
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
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
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
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
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
20
21
SMT
22
23
24
25
26
data burst (IS-801)

i
27
28
POST
ORT
data burst (IS-801)
29
30
31
32
33

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:

(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
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
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
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

g
24
25
26
27
28
SMT
SMT
i
29
30
31
32
data burst (IS-801)
33
34
35
data burst (IS-801)
36
37
38
39
40
41
42

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
56
ESPRT
t
57
58
59
Figure 4-26:

(POST Timer Expiry)
60
4-44

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
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

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

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
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
14
15
FRT
16
17
flashreq
18
ORREQ [Callback#, ESRD, Digits(dialed)]
19
20
21
22
ORT
23
SMDBACK[SMS_TeleserviceID, SMS_BearerData, MSID]
24
25
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
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
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.
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
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
43
44
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
19
20
21
22
23
GPOSDIR[POSINFO]
24
25
GPDT
26
gposdir
27
28
ORT
29
POST
f
30
PRRT
31
posroutreq [Digits]
32
33
orreq [ESRK or ESRD]
34
35
GPRT
36
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:
48
49
50
51
52
53
54
55
56
57
58

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.
GPOSREQ. The MPC requests initial position.
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.
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
16
17
18
19
20
GPOSDIR[POSINFO]
21
c
d
GPDT
22
gposdir
23
POST
24
ORT
25
f
26
27
PRRT
28
posroutreq [Digits]
29
30
31
GPRT
32
33
34
35
36
37
38
ESPRT
39
esposreq [POSINFO]
40
41
42
43
Figure 4-30:
44
45
46
47
48
49
50
51
52
53
54

55
56
57
58
59
from the GPOSREQ).
60
4-52
4 Interim Position
ANSI/J-STD-036-B
1
2
3
4
5
6
7
8
9
with a posroutreq.
10
11
orreq.
12
ESRD.
17

k. The MPC GPRT timer expires without receiving a gposreq from the PDE.
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
16
17
18
19
20
GPOSDIR[POSINFO]
21
c
d
GPDT
22
gposdir
23
POST
24
ORT
25
f
26
27
PRRT
28
posroutreq [Digits]
29
30
31
GPRT
32
33
34
35
36
37
gposreq [POSRESULT]
38
ESPRT
39
esposreq [POSINFO]
40
41
42
43
Figure 4-31:
44
45
46
47
48
49
50
51
52
53
54

55
56
57
58
59
from the GPOSREQ).
60
4-54
4 Interim Position
ANSI/J-STD-036-B
1
2
3
4
5
6
7
8
9
with a posroutreq.
10
11
orreq.
12
ESRD.
17

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.
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

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

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

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

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

included.
Indicates a positioning method used in UMTS to calculate the
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

GSM/UMTS
5-9
ANSI/J-STD-036-B
1
2
3
4
5

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

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

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
23
24
25
26
27
28
POST Call Setup IAM [CgPN=callback#, GDP=ESRD]
29
30
31
32
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
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
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
30
POST
31
32
33
34
35
36
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
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
and TS 43.059.
60
6-5
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
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
27
28
29
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
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

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
19
20
21
22
23
24
25
INITREQT
26
27
28
f
29
30
31
esposreq [initial lat/long]
32
33
34
Call Release
35
36
37
38
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
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

NCAS Pull
ANSI/J-STD-036-B
f. The ESME requests the initial position of the emergency caller. The request contains either
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.
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

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
20
21
22
23
24
d
25
26
INITREQT
27
28
29
30
31
esposreq [Position Failure]
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
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
TS 25.305 and TS 43.059.
e. The ESME requests the initial position of the emergency caller. The request contains either
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

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
21
22
23
24
25
Perform Location Error [cause]
26
27
28
e
29
30
31
32
33
34
35
36
Call Release
37
38
39
j
40
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
TS 25.305 and TS 43.059.
60
6-13

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
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
19
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

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
23
24
25
26
27
28
29
d
e
MAP Subscriber Location Report [MSISDN, IMSI, MSC address, ESRD, ESRK, lat/long, CALL ORIGINATION]
30
31
32
33
ESPOSREQ [callback# or ESRK, UPDATED]
34
35
MAP Provide Subscriber Location [IMSI or MSISDN, QoS, UPDATED]
36
37
38
39
40
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:
(Initial Position Information Already Available in the GMLC)
52
53
54
55
56
57
58
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
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
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
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

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
23
24
25
26
27
28
INITREQT
29
30
31
MAP Subscriber Location Report [MSISDN, IMSI, MSC address, ESRD, ESRK, lat/long, CALL ORIGINATION]
32
33
34
35
36
37
38
39
40
41
42
43
44
MAP Provide Subscriber Location ack. [updated lat/long]
45
46
47
48
49
50
51
Figure 6-9:
(Initial Position Information not Already Available in the GMLC)
52
53
54
55
56
57
58
59
60
6-17

Position Information not already Available in
ANSI/J-STD-036-B
emergency call and the current Cell ID and possibly other measurement information.
1
2
3
4
5
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
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
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
k. The SMLC instigates a suitable position method. The messages for the specific positioning
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
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

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
24
d
25
e
INITREQT
26
27
28
29
30
31
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
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

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
24
25
26
27
28
29
30
31
32
33
34
MAP Provide Subscriber Location Ack. [updated lat/long]
35
36
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.
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

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
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
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
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

Position following MSC-MSC Handover of an
Emergency Call
6-22
ANSI/J-STD-036-B
1
2
2.1.9

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
20
21
22
23
24
25
26
27
28
29
30
MAP Provide Subscriber Location Return Error [Cause]
31
32
33
34
35
36
Figure 6-12:
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
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
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
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

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
1
2
3
4
5
6
7
8
9
g. The SMLC initiates a suitable position method. The messages for the specific positioning
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

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
22
23
24
25
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
35
36
37
38
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
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
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
response time), an indication that the updated or, if not available, the last known MS
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
22
j. The SMLC initiates a suitable position method. The messages for the specific positioning
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

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
22
23
24
25
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
35
36
37
38
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
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

Unavailable and Last Known Position not Available
ANSI/J-STD-036-B
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
response time), an indication that the updated or, if not available, the last known MS
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
22
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

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

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
16
ECDT
17
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. [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
32
ESPOSREQ [callback# or GMLC-ESRK, INITIAL]
33
34
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

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

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
the VMSC waits for the position result and omits the remainder of this step and step k.
23
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

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
13
14
15
16
ECDT
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
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.
p. The MSC sends a request to perform location to the SMLC associated with the MSs
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.
58
59
60
6-33
3.3 Interim Position Used as Final Position Due to

INITREQT Timeout
ANSI/J-STD-036-B
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
Location Report response.
u. The MSC extends the call to the ESNE associated with the ESRK or ESRD received from
5
6
7
8
9
10
11
v. The GMLC sends a MAP Provide Subscriber Location message to the same MSC that sent
12
13
14
15
16
w. The visited MSC identifies the emergency call and its associated MS using the IMSI or
17
x. The SMLC initiates a suitable position method. The messages for the specific positioning
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

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
16
17
18
19
ECDT
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
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
49
50
51
52
53
54
55
56
57
58
information.
TS 25.305 and TS 43.059.
59
60
6-35

Phase II Positioning Failure
ANSI/J-STD-036-B
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
Location Report response.
allocated) ESRK or ESRD .
9
10
11
12
13
14
15
16
17
18
19
20
21
and TS 43.059.
30
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

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
13
14
15
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
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
MAP Provide Subscriber Location ack [lat/long]
37
38
39
40
41
42
43
Figure 6-19:
GMLC Fallback to Routing on Cell on Interim Positioning Failure
44
45
46
47
48
49
50
51
52
53
54
information.
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
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.
9
10
11
12
13
14
15
16
17
18
19
20
21
and TS 43.059.
30
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),
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
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
20
21
22
23
24
25
26
27
28
29
30
MAP Provide Subscriber Location ack [lat/long]
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
Figure 6-20:
GMLC Routing on Cell without Interim Positioning

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
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
1
2
3
4
5
6
7
8
9
g. The SMLC initiates a suitable position method. The messages for the specific positioning
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),
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
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
19
20
21
22
ECDT
23
24
Timer Expiry
25
26
27
28
MAP Subscriber Location Report [CALL ORIGINATION, MSISDN, IMSI, MSC address, cellIdOrSai, ESRD]
29
MAP Subscriber Location Report Ack. [ ]
30
31
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
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
12
13
ECDT
11
14
15
16
17
d
18
19
20
21
Failure
Timer Expiry
22
23
24
25
26
Figure 6-22:
MSC times out waiting for GMLC response prior to call setup
27
28
29
32
30
31
33
34
35
36
37
38

TS 25.305 and TS 43.059.
39
41
40
42
(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
13
14
15
16
17
18
19
20
21
MAP Subscriber Location Report Ack. [ ]
22
23
24
25
26
27
Figure 6-23:
MSC Fallback when GMLC unable to allocate ESRK
28
29
30
31
32
33
34
35
36
information.
37
38
39
40

TS 25.305 and TS 43.059.
41
42
43
44
45
46
47
48
49
50
51
52
53
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
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
31
32
33
34
35
36
-- Encoding = BCD
37
38
39
40
-- The EmergencyServicesRoutingKey parameter uniquely identifies an ongoing Emergency Services Call.

EmergencyServicesRoutingKey ::= Digits
-- Type of digits = Routing Number
41
42
43
44
45
46
-- Encoding = BCD
47
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
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
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
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
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
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
0 1 0 1 1 1 0 0
92
0 1 0 1 1 1 0 1
93
GeoPositionRequest
0 1 0 1 1 1 1 0
94
0 1 0 1 1 1 1 1
95
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
2.2.1.3
2.2.1.4
GeoPositionRequest
2.2.1.5
2.2.1.6
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
8-3
ANSI/J-STD-036-B
2.2.1.3
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
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
8-5
ANSI/J-STD-036-B
2.2.1.4
The GeoPositionDirective (GPOSDIR) operation is used to push an MSs position from the PDE to
the MPC.
3
4
5
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
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
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
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
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
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
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
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).
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
ANSI/J-STD-036-B
2.2.1.6
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
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
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
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
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
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
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
ANSI/J-STD-036-B
The InterSystemPositionRequest operation success is reported with a TCAP RETURN RESULT

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
6.5.2.fm
6.5.2.fn
c,e
6.5.2.fo
b,e
6.5.2.fp
g,e
20
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
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.
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
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
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
6.5.1.1
49
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
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
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
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-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
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
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
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
6.5.2.80
b, g
55
56
59
60
8-14
ANSI/J-STD-036-B
6.5.2.fm
6.5.2.fn
i, p, l
6.5.2.fo
j, p, l
6.5.2.fq
k, p, l
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
8-15
ANSI/J-STD-036-B
The OriginationRequest operation success is reported with a TCAP RETURN RESULT (LAST).
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
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
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
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
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
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

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
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
43
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
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
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
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
6.5.2.127
6.5.2.131
6.5.2.132
6.5.2.133
6.5.2.134
6.5.2.135
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
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
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).
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
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
8-21
ANSI/J-STD-036-B
2.2.1.11
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
6.5.2.gd
56
57
58
59
60
8-22
ANSI/J-STD-036-B
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
6.5.2.127
SMS_MessageCount
6.5.2.128
SMS_NotificationIndicator
6.5.2.130
6.5.2.131
6.5.2.132
6.5.2.133
22
6.5.2.134
23
6.5.2.135
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
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

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
6.5.2.gd
39
DenyAccess
6.5.2.54
41
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
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
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
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-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
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
1
2
The CDMAMobileCapabilities (CDMAMC) parameter identifies the general capabilities of a

CDMA mobile.
3
4
5
Table 8-32:
6
7
Field
Value
Identifier
Length
Type
Reference
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
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
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
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
8-31
ANSI/J-STD-036-B
2.3.2.5
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
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
ANSI/J-STD-036-B
2.3.2.6
CDMATargetMAHOInformation
1
2
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
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
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
22
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
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
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).
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
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
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.

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-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
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
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
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
8-39
ANSI/J-STD-036-B
2.3.2.13
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
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
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
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
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
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
6.5.2.xx
CDMAPrivateLongCodeMask
6.5.2.36
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
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-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
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
6.5.2.106
12
13
14
15
16
17
18
19
Notes
Contents
20
21
22
23
Notes:
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
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
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
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
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
8-45
ANSI/J-STD-036-B
2.3.2.18
NetworkTMSI
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
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
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
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
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
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
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
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
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
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
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
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
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
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
6.5.2.80
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
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
ANSI/J-STD-036-B
2.3.2.24
ServiceIndicator
1
2
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
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:
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
8-55
ANSI/J-STD-036-B
2.3.2.25
SMS_TeleserviceIdentifier
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
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
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
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
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
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
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
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
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
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
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
ANSI/J-STD-036-B
2.3.2.30
1
2
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
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

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
8-63
ANSI/J-STD-036-B
2.3.2.31
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
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
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
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
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
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
to 1.
22
23
ELSE:
24
25
3-1
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
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
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
39
40
41
42
43
3-1-4-2-4-1
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
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
ANSI/J-STD-036-B
3-1-4-2-4-4-1
3-1-4-2-4-4-2
Exit this task.
3-1-4-2-4-5
ELSE:
3-1-4-2-4-5-2
Exit this task.
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
3-1-7
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
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
3-1-7-3-2
Exit this task.
32
33
34
35
36
37
ELSE:
38
3-1-7-4-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
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
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
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
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
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

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
59
60
8-72
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
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.

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
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
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
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.
53
54
55
56
57
58
59
60
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
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
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
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
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
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
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
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
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
1-2-6-2-1
Relay all received parameters.
1-2-6-2-2
1-2-6-3
1-2-6-3-1
1-2-6-4
1-2-7

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
1-2-7-2
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
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.
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 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
39
40
41
42
43
44
45
48
49
50
51
1-1-6-1
1-1-6-2
52
1-1-6-2-1
53
1-1-6-3
Relay the received parameters.

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
ANSI/J-STD-036-B
1-1-6-3-1
1-1-6-4
ENDIF.
1-1-7
1-1-7-1
1-1-7-2
1-1-8
WHEN the timer (IPFT) expires:
1-1-8-1
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
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
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
24
1-2-11-1
Stop the timer (IPRT).
1-2-11-2
1-2-11-2-1
1-2-11-2-2
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
1-2-11-3
1-2-11-3-1
1-2-11-4
1-2-12
ENDIF.
Stop the timer (IPRT).
1-2-12-2

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

ENDWAIT.
49
50
51
52
53
54
55
56
57
58
ELSE:
59
60
8-83
ANSI/J-STD-036-B
1
2
1-3-1
1-4
5
6
2-1

ENDIF.
ELSE (received message cannot be processed):

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
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:
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
22
23
7
7-1
WHEN the timer (CTRT) expires:

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 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:
failure.
WHEN the Data Burst that carries the Position Determination Data Message is
rejected by the MS:
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):

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

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 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):
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

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
INVOKE is sent
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
INVOKE is sent.
IntersystemPositionRequestForward RETURN
RESULT or RETURN
ERROR is received.
see MSC
Receiving an InterSystemPositionRequestForward
INVOKE and see
MSC Receiving an
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
unrecognizedKey
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,
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
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,
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
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
9-5
ANSI/J-STD-036-B
1
2
3
4
5
6
7
8
SystemFailure,
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
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,
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
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
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
isprServingCellID
[4] ServingCellID,
positionInformation [5] PositionInformation OPTIONAL
}
47
48
49
50
51
52
53
54
55
56
57
58
59
60
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
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,
[4] ReceivedSignalQuality OPTIONAL
},
mobInfo_TDMA [3] SEQUENCE {
[1] TDMAChannelData,
[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
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
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
[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
[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
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)
POST
34
35
36
37
38
39
40
41
42
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

j
16
17
19
20
21
22
23

IPRT
15
18
ISPOSREQ [Callback# or MSID, POSREQTYPE (initial)]

ISPOSREQFWD [MSID, POSREQTYPE(initial),MPCAP]
14
24
25
26
27
28
ORT
SMT
IPRFT
POST
IPRT
l
m
n
isposreq[POSINFO]
o
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

ORT
24
25
23
29
30
POST
31
32
33
SMT
POST Expires
34
35
orreq
Call in Progress
37
38
39
40
41
42
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]
13
b
c
d
ESPRT
SMT
12
14
15
16
17
18
e
f

g
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
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
17
18
19
20
21
22
23
24

ESPRT
IPRT
IPRFT
IPRT
SMT
i
25
26
isposreq[POSINFO]
27
28
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
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
12

c
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
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

(see Note 3)
MDN or the non-dialable callback

number

number
11
12
13
14
15
DMH_BillingDigits
GenericDigits
16
17
18

(see Note 2)
ESRD
GeographicPosition
n/a
21
n/a
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

(see Note 3)

number
DMH_BillingDigits

number
GenericDigits

(see Note 2)
ESRD
GeographicPosition
geographic position
n/a
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

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
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
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

Message Parameter Contents for Wireline
Compatibility Mode (ESRK)
ESRK
18
19
20
21
3
4
Feature
Group D
E-MF/
ISDN

Message Parameter Contents for NCAS
Callback Number and ESRD
SS7 ISUP
E-MF/
ISDN

Message Parameter Contents for NCAS
Callback Number and ESRD
22
23
24
25
26
SS7 ISUP
ISDN

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
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

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
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

IPRT
IPRT
GPRT
ORT
IPFT
31
32
33
POST
34
35
36
37
isposreqfwd [POSINFO, POSRSULT(updated)]
38
39
40
41
42
orreq [GEOPOS]
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
FLASHREQ.
53

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.
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.
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
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
14
FRT
15
16
flashreq
17
18
ORREQ [MSID, Callback#, ESRD, Digits(dialed)]
19
ORT
22
23
SMDBACK[SMS_TeleserviceID, SMS_BearerData, MSID]

f
24
25
26
27
28
SMT
SBT
20
21
smdpp[ ]
29
30
31
smdback[ ]
POST
R-DATA ACCEPT[ ]
32
33
34
35
GPOSDIR[MSID, POSINFO]
36
GPDT
37
38
gposdir[ ]
l
39
40
41
PRRT
posroutreq [Digits]
42
43
44
45
46
47
48

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
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
44
45
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
20
21
22
ISPOSREQ [MSID,MOBINFO,POSREQTYPE(initial),MPCAP,SCELLID]
23
24
25
26
27
28

h
GPRT IPRT
IPFT
29
30
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
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
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
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
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
21
22
23
24
ISPOSREQ [MSID,MOBINFO,POSREQTYPE(initial),MPCAP,SCELLID]
g
25
26

h
27
28
29
30
31
GPRT IPRT
IPFT
ORT
POST
IPRT
i
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.
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
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

Ansi J STD 036 B

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Ansi J STD 036 B

Загружено:

Авторское право:

Доступные форматы

ANSI/J-STD-036-B

Enhanced Wireless 9-1-1 Phase II

Copyright Telecommunications Industry Association 2006.

Enhanced Wireless 9-1-1 Phase II

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

Chapter 2: Stage 1 Emergency Services Service Descriptions

Chapter 3: Functional Overview, ANSI-41

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Chapter 5: Functional Overview, GSM/UMTS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Chapter 9: Location Services Protocol (LSP)

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

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

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

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

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

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

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

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

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