07 SCC TCP-IP submission

existencetubΔίκτυα και Επικοινωνίες

26 Οκτ 2013 (πριν από 4 χρόνια και 13 μέρες)

151 εμφανίσεις

TR45.2.AHES/2001.3.15_____


Copyright Statement:


The contributor grants a free, irrevocable license to the Telecommunications Industry Association (TIA) to incorporate text o
r other copyrightable
material contained in this contribution and any mod
ification thereof in the creation of a TIA standards publication; to copyright and sell in TIA’s
name any TIA standards publications even though it may include portions of this contribution; and at TIA’s sole discretion to

permit others to
reproduce in who
le or in part the resulting TIA standards publication. This contributor is also willing to grant licenses under such copyrig
hts to
third parties on reasonable non
-
discriminatory terms and conditions, if appropriate.

Telecommunication Industries Association


Subcommittee TR45.2




Title:

Using TCP/IP to transmit ESP protocol between the MPC and ESME for the E2 Interface.



Source:



SCC Communications Corp.

6285 Lookout Road

Boulder, CO 80301



Technical Contact:



Pe
ter Schmidt

Phone: (303) 581
-
5672

Fax: (303) 581
-
0900

Email: pschmidt@sccx.com



Abstract:


The overwhelming majority of Enhanced 9
-
1
-
1 Automatic Location Information (ALI) systems, or
ESMEs , are not SS
-
7 capable. This contribution proposes an implementa
tion methodology for
the J
-
STD
-
036 E2 ESP interface that is based on TCP/IP based interconnection between MPCs
and ESMEs using bit encoding as published.



Recommendation:


Inclusion of this methodology in some appropriate reference document to accompany J
-
STD
-
036
for use by organizations designing and implementing the ESP interface with the existing E9
-
1
-
1
ALI/ESME infrastructure.


TR45.2.AHES/2001.3.15_____


Page
2

of
18


Definitions and Acronyms


ALI


Automatic Location Identification. The automatic display at the PSAP of the caller’s telepho
ne
number, the address/location of the telephone and supplementary emergency services information. In
this document, the ALI database is equivalent to an ESME.


ALI Steering


The sharing of address and position data between different ALI database systems
.
When an ALI database receives a bid from a PSAP that it has been configured to retrieve from an
alternate ALI database, the PSAP serving ALI database will redirect or steer that bid to the alternate
ALI database to retrieve the appropriate call informat
ion.


ANI


Automatic Number Identification. Enhanced 9
-
1
-
1 service feature that provides calling party
TN to a 9
-
1
-
1 call taker when a 9
-
1
-
1 call is placed.


9
-
1
-
1 CPE


Customer Premises Equipment. Terminal equipment at a PSAP. The CPE is used to
disp
lay the 9
-
1
-
1 caller’s ANI and ALI information.


Dynamic Routing Protocol


A set of protocols to route messages through a network when there are
multiple paths available between the source and destination entities. Typically used in TCP/IP
networks.


Fra
me Relay


A telecommunication service designed for robust and cost
-
efficient wide area data
transmission between physically separated local area networks (LANs) or network nodes. This
technology puts data into variable
-
size units called frames for transmi
ssion. The frame relay layer
does not handle error detection, correction or retransmission management.



LAN


Local Area Network. A local area network (LAN) is a group of computers and associated
devices that share a common communications sphere and typ
ically share the resources of a single
processor or server within a small geographic area (for example, within an office building).


NAT


Network Address Translation. The translation of an Internet Protocol address used within one
network to a different
IP address known within another network.


PSAP


Public Safety Answering Point. A facility equipped and staffed to receive 9
-
1
-
1 calls.


Registered Address


An unique TCP/IP address that may be used in public networks without concern
of conflict. TCP/I
P addresses are typically registered with/by Network Solutions, Inc.


Socket


A method for communication between two applications in a network. The socket is defined
as “the endpoint in a connection.” Multiple sockets may be simultaneously used over the

same
physical and logical links.


TCP/IP


Transmission Control Protocol / Internet Protocol. A layered set of protocols used to
connect dissimilar computers together. The TCP part provides the transport service required by the
application layer. TCP l
ayers in host computers that are engaged in data interchange data will
communicate to each other to insure reliable data packet transport. The IP part provides the service to
deliver datagrams to the designated destination. This layer provides the routin
g through the data
network including error message generation as appropriate.



Unregistered TCP/IP Address


A TCP/IP address that is technically valid and usable only on a closed
private network. These may be duplicated between private networks and as s
uch, shared and public
networks typically do not allow unregistered addresses to appear to the network.




TR45.2.AHES/2001.3.15_____


Page
3

of
18



WAN


Wide Area Network. A WAN (wide area network) is a geographically dispersed
telecommunications network and the term distinguishes a broader te
lecommunication structure from a
local area network LAN.


Wireless Company ID


A Company ID in the ALI Database to determine where the ALI database can
query for updated position data about the wireless 9
-
1
-
1 call.


TR45.2.AHES/2001.3.15_____


Page
4

of
18


References


01
-
002
-

Master Glossary o
f 9
-
1
-
1 Terminology, March 1998, National Emergency Number
Association’s Web Site.

http://www.nena9
-
1
-
1.org/9
-
1
-
1_Standards_Development/nena_recommended_stand
ards.htm


02
-
010


Standards for Recommended Formats & Protocols For Data Exchange, May 1999, National
Emergency Number Association’s Web Site.

http://ww.nen
a9
-
1
-
1.org/9
-
1
-
1_Standards_Development/nena_recommended_standards.htm


TIA/EIA/IS
-
J
-
STD
-
036


Enhanced Wireless 9
-
1
-
1 Phase II, September 2000.


whatis.com


An IT
-
Specific Encyclopedia Web Site,
http://whatis.te
chtarget.com



TR45.2.AHES/2001.3.15_____


Page
5

of
18


Introduction


It is not specified in the J
-
STD
-
036 document how the Emergency Services Position Request and its
corresponding response should be transmitted between the Emergency Services Message Entity
(ESME or ALI system) and the Mobile
Position Center (MPC) via the E2 interface. While the
documented TCAP message format implies to some that SS
-
7 is the transport and interconnection
methodology, this does not appear to be viable (or what was intended by the 9
-
1
-
1 industry during the
stand
ards development) given that virtually none of the 9
-
1
-
1 ALI systems in place today are SS
-
7
capable.


While SS7 is in limited use today for routing E9
-
1
-
1 voice traffic, it is not in use for the purpose of
retrieving data from an ALI database to get ad
dress or position data about the 9
-
1
-
1 caller. Because of
this, the ALI systems have not had a need to support a message directly from the SS7 network and do
not incorporate the hardware or software to support SS7 messaging. Most of the ALI/ESME systems
in the field today do not have the capability of being upgraded to support SS
-
7 connectivity.


With many of hundreds of ALI databases in use today, the cost associated with putting an SS7 stack on
each of the ALI databases (or replacing them with systems
SS
-
7 capable), connecting them to the SS
-
7
network and acquiring an SS
-
7 point code for each of them is an expense that could not be covered
with the limited funding that is available for E9
-
1
-
1 services. In fact, E9
-
1
-
1 industry may not be able
to suppor
t this standard if the SS7 network is the expected transport medium for the E2 interface.


ALI hosts do, however, have redundant, fault tolerant TCP/IP connectivity available today in almost
all cases. TCP/IP connections are in use today for connectivity
to the PSAP, interconnection with peer
ALI hosts, remote monitoring, administration and provisioning.


Given this situation, it is our recommendation that the E2 interface connectivity be TCP/IP based and
not SS7 based, utilizing the TCAP message formats a
s currently published.



Assumptions


If a mated pair of MPCs are implemented, each MPC has knowledge of all of the calls that are in
progress as well as the current position data for each call.



TR45.2.AHES/2001.3.15_____


Page
6

of
18



ALI/ESME
-

MPC Data Exchange Issues



Overview


Even thou
gh the TCAP messaging standard from the J
-
STD
-
036 has been adopted by this
proposal, there remain a few issues that need to be addressed to assure interconnection and
operability. These issues are: TCP/IP Connection Establishment, TCP/IP Connection Shutdo
wn,
Application Layer Heartbeat and the need to include an ESRK with the test message.




TR45.2.AHES/2001.3.15_____


Page
7

of
18



TCP/IP Connection Establishment Protocol



The MPC should be the client and establish the connection to the ESME. Conversely, the ESME
is the server and is liste
ning for connect requests from the MPC. The MPC should use a well
-
known port to connect to the ALI database and the ALI database is listening for connect requests
on the same well
-
known TCP/IP port. The well
-
known port, which will be determined at a late
r
time, will be registered with Network Solutions to be used as the standard port number for MPCs
to ESME E2 connectivity.


For security purposes, every connect request received by the ESME is interrogated for the
connector’s IP address to determine who th
e connector is, and if the connector is a valid and
approved user of this service.


If the socket connection cannot be established or the socket connection is dropped, the MPC is
responsible for attempting reestablishment of the connection every 30 secon
ds.




TR45.2.AHES/2001.3.15_____


Page
8

of
18


TCP/IP Connection Shutdown Protocol


If the MPC or ALI/ESME is known to be going out of service, the entity going out of service
sends a Link Shutdown Host Status Message to the entity it is connected to and closes the TCP/IP
socket.


The side r
eceiving the Link Shutdown Host Status Message gracefully closes the TCP/IP socket.


NOTE: The Host Status Message is not included in the J
-
STD
-
036 document and will need to be
added as an optional message to enable this functionality.


Without the host

status message, the side that is not being shutdown would not have any indication
if there is a real problem or planned maintenance event and would go into an alarm condition
possibly unnecessarily. This new message gives the application the ability to g
racefully close the
link and not have it reported as a failure alarm condition.


The TCP/IP Connection Establishment Protocol is followed until the TCP/IP socket connection is
reestablished.




TR45.2.AHES/2001.3.15_____


Page
9

of
18


Application Layer Heartbeat Protocol


During periods of inac
tivity, an application layer “heartbeat” is sent from the ESME to the MPC.
The “heartbeat” message is the Emergency Services Position Request with the Position Request
Type being set to “test” to indicate this is a test message as it is specified in the E
mergency
Services Protocol of the J
-
STD
-
036 document. The Emergency Services Protocol message from
the J
-
STD
-
036 has been copied to Appendix A of this document.


The “acknowledgement” of the heartbeat that is sent by the MPC to the ESME is the Emergency
S
ervices Position Response with the Position Result field set to “test”. This is also compliant with
the Emergency Services Protocol of the J
-
STD
-
036 document.


If the MPC does not receive the heartbeat or the ESME does not receive the acknowledgement to
t
he heartbeat, after a configurable number of failures, the communication path between the MPC
and ESME is torn down by closing the TCP/IP socket and an alarm generated. To reestablish the
connectivity between the MPC and ESME, the MPC will follow the TCP/
IP Connection
Establishment Protocol detailed earlier.


This application level heartbeat is critical to monitoring application and link level welfare.



The heartbeat interval should be set such no periods of inactivity over the link at the application
lay
er extend beyond 45 seconds to prevent the TCP/IP socket session from timing out and being
closed automatically.


TR45.2.AHES/2001.3.15_____


Page
10

of
18


ESRK with Test Message


During initial system setup, and for ongoing end
-
to
-
end operation verification and
troubleshooting, the ability to i
nclude a test ESRK in the EPOSREQ Request from the ALI/ESME
to the MPC would allow integration testing of the overall system with data received from the
ALI/ESME and MPC.


The test ESRK is configured uniquely for each PSAP at the MPC, so that it does not

query the
PDE for the latitude/longitude data and instead returns a pre
-
defined and coordinated default
latitude /longitude data that will be displayed within the boundaries of the PSAP’s jurisdiction.


NOTE: The ability to include an ESRK with the ESPOS
REQ “test” message is not included in the
J
-
STD
-
036 document and would need to be added as an optional message to support this
functionality.


The data flow for this scenario is as follows:



The PSAP bids the ALI/ESME with the test ESRK. The ALI/ESME rec
eives the test ESRK from
the PSAP and sends the ESPOSREQ with the test ESRK and Position Request Type set to “test”
to the MPC. The MPC receives the ESPOSREQ request and recognizes the ESRK provided as a
test ESRK. The MPC retrieves the default latitude
and longitude for the test ESRK received. The
esposreq return result message is created with the position result set to “test” and the default
latitude and longitude populated in the POSINFO parameter. The esposreq return result message
is then sent to t
he ALI/ESME. The ALI/ESME sends the default latitude and longitude to the
PSAP and the latitude and longitude is then used by the 9
-
1
-
1 CPE for testing and verification of
overall system operation.





TR45.2.AHES/2001.3.15_____


Page
11

of
18


ALI/ESME to MPC Network Issues



Physical Connectiv
ity


The MPC and ALI/ESME database use TCP/IP routers and private networking transport to create
a secure and predictive network. These routers will make use of the IP protocol for node
addressing. The physical connectivity between the ALI/ESME and the M
PC is through either a
private packet
-
based network or a dedicated point
-
to
-
point environment. Because ESME/ALI
systems are always deployed in pairs, each MPC needs physical connectivity to both ESME/ALI
hosts.




TCP/IP Address Assignment


Each entity in

the network including the ALI/ESME and the MPC must be able to be referenced
by a unique TCP/IP address such that no TCP/IP address conflicts result in the network. This is
similar to assigning unique point codes within an SS7 network.


Given the numbe
r of systems and system nodes likely to be interconnected when supplying
wireless 9
-
1
-
1 service in a given area, it is recommended that only registered (therefore non
duplicated) addresses be used for WAN facing ports. Network Address Translation (NAT) co
uld
then be used to translate these registered addresses to non
-
registered addresses that may be used
within a given node location at the discretion of the operator.


For each set of E2 interconnections coordination between the MPC and ESME operator is req
uired
to assure that IP addresses are appropriately assigned to all inward and outward facing ports on
each node component.




Network Security


Connectivity between the MPC and ALI/ESME systems should be accomplished by private
network facilities. These
facilities may be dedicated point
-
to
-
point or packet based (such as frame
relay) so long as the implementation represents a closed private network. Currently Internet or

TR45.2.AHES/2001.3.15_____


Page
12

of
18

Internet based VPNs cannot be used to establish this connectivity because several sta
tes have
regulations that prohibit interconnection between the Internet and 9
-
1
-
1 systems.



Operators of the TCP/IP routers employed in the system should use standard IP packet filters on
the routers to allow messages through the router on the well
-
known
port as designated for the E2
interface. These filters should also be set such to prohibit traffic from one E2 interface being
visable to another E2 interface link.


It is generally thought that Dynamic Routing Protocol should not be used in this situati
on given
the multiple separate entities involved. This recommendation should not be taken to mean that
dynamic routing protocols cannot be used if the operators deem the situation to be appropriate for
use.


TR45.2.AHES/2001.3.15_____


Page
13

of
18


Appendix A: Emergency Services Protocol (ESP)


1 Introduction

This section specifies the Abstract Syntax for the Emergency 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 M
ACROs, defined 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:


a.

Figure 3
-
1 “Network Reference Model” interface: MPC to ESME (Reference Point
“E
2
”).

b.

Figure 5
-
1 “Network Reference Model for PCS1900” interface: GMLC to ES
ME
(Reference Point “E
2
”).


Parameter contents imported from other specifications (e.g. T1.114 and ANSI
-
41) are imported
without length and identifier octets.


1.1 Transaction Portion

The Emergency Services Protocol employs the Query with Permission and Re
sponse TCAP
Package Types defined in ANSI T1.114
-
1996.


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 excep
tions
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 Operati
on 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.


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

TR45.2.AHES/2001.3.15_____


Page
14

of
18

TCAP REJECT component with one of the following TCAP Problem
Specifiers shall be sent:

i.

Problem Type INVOKE: Duplicate Invoke I
D, Unrecognized
Operation Code or Incorrect Parameter.


i.

The Parameter Set Identifier is coded per ANSI T1.114 (national,
constructor with Identifier code 18).


2 Emergency Services Protocol Abstract Syntax


The Emergency Services Protocol is composed of on
e ASN.1 module dealing with operations,
errors and data types.


EmergencyServicesProtocol { iso (1) memberbody (2) usa (840) emergencyServicesProtocol (1) }

DEFINITIONS

::=

BEGIN


EXPORTS

Digits,

GeographicPosition,

InternationalMobileSubscriberIdentity,

M
obileIdentificationNumber,

PositionInformation,

PositionRequestType;


IMPORTS

ERROR,

OPERATION


FROM TCAPPackage { iso (1) memberbody (2) usa (840) T1.114 (10013) } ;


--

Operations Definitions

--

The Emergency Services Position Request operation is used t
o 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 Interim Standard.

EmergencyServicesPositionRequest ::= OPERATION
--

Timer ESPRT

PARA
METER

esprArg EmergencyServicesPositionRequestArgument

RESULT

esprRes EmergencyServicesPositionRequestResponse

ERRORS {

SystemFailure,

UnauthorizedRequest,

UnexpectedDataValue,

UnrecognizedKey }


--

Emergency Services Position Request operation code specif
ier

emergencyServicesPositionRequest EmergencyServicesPositionRequest ::= localValue 1


--

Emergency Services errors and error codes

SystemFailure ::= ERROR

systemFailure


SystemFailure ::= localValue 1


UnauthorizedRequest ::= ERROR

unauthorizedRequest

UnauthorizedRequest ::= localValue 2


TR45.2.AHES/2001.3.15_____


Page
15

of
18


UnexpectedDataValue ::= ERROR

UnexpectedDataValue

UnexpectedDataValue ::= localValue 3


UnrecognizedKey ::= ERROR

unrecognizedKey UnrecognizedKey ::= localValue 4


--

Emergency Services data types

EmergencyServicesPos
itionRequestArgument ::= SEQUENCE {

EsprSysId

[0] ESMEIdentification,

--

Identifies the system initiating the request (i.e., ESME).

EsprReqType

[1] PositionRequestType,

--

If set to “test”, then esprKey should be set to a zero
-
length
EmergencyServicesRouti
ngKey

esprKey


CHOICE {

[2] EmergencyServicesRoutingKey,

SEQUENCE {

[3] CallbackNumber,

[4] EmergencyServicesRoutingDigits OPTIONAL


Provide if
available

}

}

...

}


EmergencyServicesPositionRequestResponse ::= SEQUENCE {

esprPosRes


[0] PositionResult,

e
sprPosInfo


[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] EmergencyServicesRoutin
gDigits OPTIONAL,

--

Shall be provided, if available, when the initial position was

--

requested and the esprKey was the ESRK.

esprESRKTime


[4] GeneralizedTime OPTIONAL,

--

Time of ESRK assignment. Shall be provided, if available, when the

--

the esprKey

was the ESRK.

esprMIN


[5] MobileIdentificationNumber OPTIONAL,

esprIMSI


[6] InternationalMobileSubscriberIdentity OPTIONAL,

esprMCallStatus


[7] MobileCallStatus OPTIONAL,

esprCompID


[8] CompanyID OPTIONAL,

--

In the US and Canada it shall be provi
ded when available.



}

--

Emergency Services Parameter Definitions


--

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

--

Encoding = BCD

--

Numbering Plan = Telephony Numbering Plan (E.164)


--

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.


TR45.2.AHES/2001.3.15_____


Page
16

of
18

CompanyID ::= VisibleString (SIZE (1..15))


--

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 numb
ering plan).

Digits ::= OCTET STRING
--

See T1.114.5 Digits parameter for encoding


--

The EmergencyServicesRoutingDigits parameter uniquely identifies a base station, cell site or
sector.

EmergencyServicesRoutingDigits ::= Digits

--

Type of digits = Routi
ng Number

--

Nature of number = National/International, no presentation restrictions

--

Encoding = BCD

--

Numbering Plan = Telephony Numbering Plan (E.164)


--

The EmergencyServicesRoutingKey parameter uniquely identifies an ongoing Emergency
Services Call
.

EmergencyServicesRoutingKey ::= Digits

--

Type of digits = Routing Number


--

Nature of number = National/International, no presentation restrictions

--

Encoding = BCD

--

Numbering Plan = Telephony Numbering Plan (E.164)


--

The ESMEIdentification parame
ter uniquely identifies the ESME sending a particular message.

--

In the US and Canada the identifiers are managed and assigned by NENA

ESMEIdentification ::= VisibleString (SIZE (1..15))


--

GeneralizedTime is a UNIVERSAL type defined in X.680. This is al
ways specified in UTC.


--

The GeographicPosition parameter specifies a location in latitude and longitude

--

coordinates, reference WGS
-
84 data.

GeographicPosition ::= OCTET STRING
--

See Calling Geodetic Location in T1.628 for
encoding. At a minimum, in
order to provide the required fields, the Type of shape field values
recommended to be supported are Ellipsoid point and Ellipsoid point with uncertainty.


InternationalMobileSubscriberIdentity ::= Digits

--

The overall number of digits in IMSI shall not e
xceed 15 digits.

--

Type of digits = Not used

--

Nature of number = International, no presentation restrictions

--

Encoding = BCD

--

Numbering Plan = Land Mobile Numbering Plan (E.212)


--

The MobileCallStatus parameter indicates the validation status of t
he mobile in ANSI
-
41
systems.

MobileCallStatus ::= OCTET STRING
--

See
Chapter 8 from J
-
STD
-
036
for encoding


MobileIdentificationNumber ::= Digits

--

Type of digits = Not used

--

Nature of number = International, no presentation restrictions

--

Encoding =

BCD

--

Numbering Plan = Not applicable


--

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 {


TR45.2.AHES/2001.3.15_____


Page
17

of
18

PosTime



[0] GeneralizedTime,

--

Time of position determination.

GeoPos



[1] GeographicPosition,

PositionSource


[2] PositionSource OPTIONAL,



}


--

The PositionRe
questType 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



}

--

Exception handling: Undefined values are treated as value 1 (initial)


--

The PositionResult parameter indicates the type of position returned or the reason for

--

not providing position information.

PositionResult :
:= ENUMERATED {

initialPositionReturned (1),

updatedPositionReturned (2),

lastKnownPositionReturned (3),

--

The following codes indicate that position was not returned.

requestedPositionNotAvailable (4),

callerDisconnected (5),

--

No call in progress for c
aller 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.



}

--

Exception handling:

--

If undefined values are received they are treated as if value 4 (requestedPositionNotAv
ailable)

--

was received.


--

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

netw
orkAOA (2),

networkTOA (3),

networkTDOA (4),

networkRFFingerprinting (5),

networkCellSector (6),

networkCellSectorWithTiming (7),


TR45.2.AHES/2001.3.15_____


Page
18

of
18

--

Handset Position Sources

handsetUnspecified (16),

handsetGPS (17),

handsetAGPS (18),

handsetEOTD (19),

handsetAFLT (20)



}

--

Exception handling:

--

Undefined values in the range 1
-
15 are treated as if value 1 (networkUnspecified)

--

Undefined values in the range 16
-
31 are treated as if value 16 (handsetUnspecified)

--

Other undefined values are treated as if value 0 (unknown
)


END