6 Location acquisition protocols - ATIS by wuyunyi

VIEWS: 1 PAGES: 16

									                                                                                                                                                     NGES-xxx




 1
 2
 3   Document Type: Technical Report
 4   TITLE: Location Acquisition and Location Parameter Conveyance for Internet Aaccess
 5   Nnetworks in Ssupport of Eemergency Sservices
 6   DOCUMENT NUMBER: ATIS-XXXXXX.
 7   SOURCE: Emergency Services Interconnection Forum
 8   CONTACT: Martin Dawson, Andrew Corporation, +61 2 42212992,
 9   martin.dawson@andrew.com, Anand Akundi, Telcordia, (732) 699-6031,
10   aakundi@telcordia.com, Christian Militeau, Intrado, (720) 864-5245,
11   Christian.Militeau@intrado.com
12

13 1.1       Abstract
14           This document describes the specific areas of location acquisition and location parameter
15           conveyance in Internet access networks, particularly as they focus on emergency services.
16           It concerns itself with both the architectures and protocols for supporting these functions. In
17           brief, this is about the manner in which IP devices such as VoIP clients request location
18           information from a Location Information Server (LIS) function in any access network
19           (termed– location acquisition). It is also about the manner in which the LIS function obtains
20           the value of parameters from access networks pertinent to the IP address of the requesting
21           IP device in order that it can actually calculate the device’s location.
22           The LIS function is identified as an essential component of the NENA-defined i2 architecture
23           for VoIP emergency services and continues to be required in the i3 architecture currently
24           under definition. This document starts with the LIS requirements specified by NENA in terms
25           of those architectures. It examines candidate protocols for location acquisition – HTTP-
26           Enabled Location Delivery (HELD), Dyanmic Host Configuraton Protocol (DHCP), Link Layer
27           Discovery Protocol – Media Endpoint Devices (LLDP-MED) – and provides a gap analysis.
28           The concepts of location parameter conveyance are described and a specific architecture –
29           the LIS-Access Location Element (ALE) architecture – is elaborated on. A Fflexible LIS-ALE
30           Pprotocol (FLAP) is described – FLAP – and examples are provided of its application in
31           some common forms of broadband access networks.
32           This Ttechnical Rreport is intended to be used as input to further decision-making processes
33           leading to any necessary policy and/or American National Standards formulation. It will be
34           used as a vehicle for communicating concepts in liaisons with other relevant Standard
35           Developent Organizations (SDOs).
36
37
38   1.2Notice                                                                                                                                              Formatted: Normal, Indent: Left: 0"
39   This is a draft document and thus, is dynamic in nature. It does not reflect a consensus of ESIF members and it may be changed or modified. Neither
                                                                                                                                                            Formatted: Bullets and Numbering
40   ATIS nor ESIF makes any representation or warranty, express of implied, with respect to the sufficiency, accuracy or utility of the information or
41   opinion contained or reflected in the material utilized. ATIS and ESIF further expressly advise that any use of or reliance upon the material in
                                                                     ATIS-XXXXXXX


 1   question is at your risk and neither ATIS nor ESIF shall be liable for any damage or injury, of whatever nature, incurred by any person arising out of
 2   any utilization of the material. It is possible that this material will at some future date be included in a copyrighted work by ATIS.
 3
 4
 5                                          Document ATIS-XXXXXX.                                                                                             Comment [r1]: Editors note: we may want to
                                                                                                                                                              shorten the first abstract so this fits of the first
 6                                                  Prepared by                                                                                               page.
 7                                    Emergency Services Interconnection Forum
 8                                                Working Group
 9                       Next Generation Emergency Services Subcommittee (NGES) (Issue 50)
10




                                                                                                                                                         2
 1
 2                                                                                 ATIS-XXXXXX
 3
 4
 5              Alliance for Telecommunications Industry Solutions Technical Report                      Formatted: Font: 12 pt
 6                                                                                                       Formatted: Centered
 7                    Location Acquisition and Location Parameter Conveyance for                         Formatted: Font: 11 pt
 8                    Internet Aaccess Networks in Support of Emergency Services
 9
                                                                                                         Formatted: Heading 2

10   1.2   Abstract                                                                                      Formatted: Bullets and Numbering

11         This document describes the specific areas of location acquisition and location parameter
12         conveyance in Internet access networks, particularly as they focus on emergency
13         services. It concerns itself with both the architectures and protocols for supporting these
14         functions. In brief, this is about the manner in which IP devices such as VoIP clients
15         request location information from a LIS function in any access network – location
16         acquisition. It is also about the manner in which the LIS function obtains the value of
17         parameters from access networks pertinent to the IP address of the requesting IP device
18         in order that it can actually calculate the device’s location.
19         The LIS function is identified as an essential component of the NENA-defined i2
20         architecture for VoIP emergency services and continues to be required in the i3
21         architecture currently under definition. This document starts with the LIS requirements
22         specified by NENA in terms of those architectures. It examines candidate protocols for
23         location acquisition – HELD, DHCP, LLDP-MED – and provides a gap analysis.
24         The concepts of location parameter conveyance are described and a specific architecture
25         – the LIS-ALE architecture – is elaborated on. A Fflexible LIS-ALE Pprotocol is described
26         – FLAP – and examples are provided of its application in some common forms of
27         broadband access networks.
28         This Ttechnical Rreport is intended to be used as input to further decision-making
29         processes leading to any necessary policy and/or American National Standards
30         formulation. It will be used as a vehicle for communicating concepts in liaisons with other
31         relevant SDOs.
32
33
34
 1   1.3   Foreword
 2         The rapid rise of Voice over IP telephony services was anticipated by the National
 3         Emergency Number Association (NENA). In 2003, it established working groups to define
 4         a “migratory” architecture (i2) and an “end game” architecture (i3) to provide the ability to
 5         reliably deliver and process emergency calls originated by Internet-based VoIP telephony
 6         users. Both the i2 and i3 architectures depend on the ability to determine and
 7         communicate the location of the caller so that a) the call can be routed to the correct
 8         PSAP and b) the location can be delivered to the PSAP operator for dispatch and other
 9         procedural purposes. The network element identified to perform this function is associated
10         with the access network used by the VoIP caller and is called the Location Information
11         Server (LIS). NENA documents prescribe the requirements on the LIS and the form of
12         location information provided by it. They do not provide the detailed protocol specifications
13         associated with LIS functionality.
14         In practice, the role of the LIS can be split into at least two key functions:
15               Location acquisition – the protocol and associated semantics by which IP devices
16                and applications request location information from the LIS.
17               Location measurement and determination – the function and any associated
18                protocols associated with obtaining and evaluating network and other parameters
19                that are associated with the device in order to calculate the device’s location.
20                Getting these relevant parameters delivered from the network may be termed
21                “location parameter conveyance”.
22         In order to provide global consistency for devices such that location information can be
23         retrieved in the same way regardless of the kind of network they are currently attached to,
24         it is important that Location Acquisition is done in the same way independent of the
25         technology underpinning that access network. On the other hand, the parameters
26         important to location determination, the manner in which location is calculated, and the
27         form of location (e.g. civic and/or geodetic) will vary significantly depending on the nature
28         of the access technology. That is, the parameters and algorithms associated with
29         determining location in an Asynchronous Digital Subscriber Loop (ADSL) network will be
30         significantly different than doing the same in a Worldwide Interoperability for Microwave
31         Access (WiMAX) network. By definition, then, location acquisition is ideally network
32         technology independent while location parameter conveyance and determination is
33         network technology dependent.

34   1.4   Revision History
       Revision              Date                                          Remarks
     .01             July 5 2006July 19,     Version .01 skeleton document for group discussioninitial baseline
                     2006                    document
     .02             July 19 2006            Added NENA acquisition protocol requirements matrix




35
                                                                         ATIS-XXXXXXX


 1                                                                   Table of Contents
 2       1.1    Abstract ............................................................................................................................................ 1
 3       1.2    Abstract ............................................................................................................................................ 1
 4       1.3    Foreword .......................................................................................................................................... 1
 5       1.4    Revision History ............................................................................................................................... 1
 6   2     Introduction/Executive Summary .......................................................................................................... 4
 7       2.1    Target Audience ............................................................................................................................... 5
 8   3     NENA i2 and i2 architecture .................................................................................................................. 5
 9       3.1    Summary of LIS functions in the NENA architecture ....................................................................... 6
10       3.2    LIS requirements prescribed by NENA ............................................................................................ 6
11   4     Location determination in Internet access networks.............................................................................. 7
12       4.1    Example ADSL network ................................................................................................................... 7
13       4.2    Example cable network .................................................................................................................... 8
14       4.3    Example WiMAX network................................................................................................................. 8
15       4.4    Example 3G cellular network ........................................................................................................... 8
16       4.5    Example enterprise (Ethernet switch/WiFi) network ........................................................................ 8
17   5     LIS Operational considerations .............................................................................................................. 8
18       5.1    Types of LIS and LIS Operators ...................................................................................................... 8
19       5.2    OSS integration considerations ....................................................................................................... 8
20       5.3    Certificate security and management .............................................................................................. 8
21   6     Location acquisition protocols ................................................................................................................ 8
22       6.1    HELD, DHCP, and LLDP-MED introduced ...................................................................................... 8
23       6.2    HELD, DHCP, and LLDP-MED gap analysis against NENA requirements ..................................... 8
24       6.3    Findings .......................................................................................................................................... 10
25       6.4    HELD status ................................................................................................................................... 11
26   7     Location parameter conveyance using FLAP ...................................................................................... 11
27       7.1    LIS-ALE architecture ...................................................................................................................... 11
28       7.2    FLAP protocol ................................................................................................................................ 11
29       7.3    FLAP examples .............................................................................................................................. 11
30       7.4    Benefits of FLAP versus “technology point solutions” ................................................................... 11
31       7.5    Status of FLAP ............................................................................................................................... 11
32   8     References ........................................................................................................................................... 11
33   9     Definitions ............................................................................................................................................ 12
34
35
36                                                                    Table of Figures
37


                                                                                                                                                                     2
                                                                    ATIS-XXXXXXX


1   Figure 3-1 NENA i2 architecture ................................................................................................................... 5

2
3




                                                                                                                                                       3
                                          ATIS-XXXXXXX


 1
                                                                                                      Comment [r2]: Not baselined



 2   2   Introduction/Executive Summary
 3           NENA i2 architecture described with focus on LIS functionality
 4               o   Significance to global interoperability is emphasized
 5               o   Continued relevance of LIS function to i3 is highlighted
 6               o   Description of incremental LIS deployment model – with user-provided
 7                   location as fallback
 8               o   NENA requirements summarized
 9           Location determination in different access networks is described
10               o   Example ADSL network
11               o   Example cable network
12               o   Example WiMAX network
13               o   Example 3G cellular network
14               o   Example enterprise (Ethernet switch/WiFi) network
15           Significance to LIS operators is described
16               o   Types of LIS and LIS operators described
17               o   OSS system integration – highlighting types of data to be groomed and
18                   operations needing to be supported
19               o   Certificate security and management
20           Location acquisition protocols exist and have been defined within certain domains
21               o   HELD, LLDP-MED, and DHCP are looked at in comparison to NENA
22                   requirements
23               o   HELD is shown to meet the requirements most completely
24               o   Current status of HELD described
25           Location parameter conveyance using FLAP
26               o   LIS-ALE architecture elaborated on
27               o   FLAP protocol described
28               o   Applicability to previously described location determination examples
29                   described
30               o   Assessment of the value of FLAP
31               o   Current status of FLAP described




                                                                                                  4
                                                      ATIS-XXXXXXX


 1   2.1   Target Audience
 2         This document is directed to the members of the NGES subcommittee dealing with Issue
 3         50 and tasked with progressing recommendations around policy and standard formulation.
 4         It provides a technical overview of the scope of issue and specific terms of reference
 5         currently viewed as significant to progress. It is also directed towards those members of
 6         third party SDOs who may be in receipt of liaisons from this subcommittee requesting
 7         input in the form of opinion, information, or decisions pertinent to the subcommittee’s
 8         ability to progress the work associated with the issue.
                                                                                                                      Comment [r3]: Section 3.0 not baselined


 9   3     NENA i2 and i2 architecture
10         Overview description
11         The NENA i2 Figure 3-1Error! Reference source not found. initiative was proposed with
12         the intent of addressing the immediate need of providing standard emergency services
13         support to next generation VoIP phone users. A strong requirement of i2 from the onset
14         was to make little or no change to the existing emergency infrastructure, in particular any
15         solution was to impose no change to PSAPs. The problems surrounding IP location when
16         investigated further were found to be remarkably similar to those affecting wireless cellular
17         networks. The resulting architecture for i2 therefore closely resembles the architecture
18         created to address the wireless phase II emergency requirements.
19
                              Access               Carrier                            Emergency
                              Network              Network                             Network
                                             Call-Server/ Proxy

                                                                        ISUP                       CAMA
                                        V1
                                                             V4

                                                          ESGW                 Selective Router

                                   V0
                             VEP               IP                                                 PAM
                                                     V2/V5                          ALI
                                             Network
                                    LIS                                             Local
                                                                                                           PSAP
                                                                        E2+                       PAM
                                                 V3               VPC   ESP
                                                                                    ALI
                                                                                   National
                                                                          V8                            ERDB

                                                                  V7                               VDB
20
21                                       Figure 3-1 NENA i2 architecture
22         The NENA i2 architecture identified 5 new network elements, 9 new interfaces, and made
23         minor changes to the E2+ to support VoIP class of service indicators between the new
24         VoIP Positioning Centre (VPC) and the existing ALI infrastructure. While the detailed
25         functions of each of the new 5 network elements is defined in the i2 specification, not all of
26         the interfaces between nodes are specified. Specifically, the V0 and V1 interfaces were
27         deemed out of scope for i2.
28
29         Pertinence to global interoperability described.


                                                                                                                  5
                                                     ATIS-XXXXXXX


 1         LIS relevance through i2/3
 2         Location integrity – signed location
 3         Role of certificate authorities in i2/3
 4         Network evolution – incremental LIS deployment with mixture of LIS-provided, user-
 5         defined, and no location availability

 6   3.1   Summary of LIS functions in the NENA architecture

 7   3.2   LIS requirements prescribed by NENA
 8         The following requirements come from the NENA Requirements for the location
 9         information to support emergency services [18].
10         DA1– The access network shall provide a mechanism for determination and acquisition of
11         location information, and support queries for location.
12         DA2 – The location estimate used shall be that associated with the physically (wire, fiber,
13         air) connected network.
14         DA3 – Location may be requested at any time. Location information must be associated
15         with the device at the time the location is requested.
16         DA4 – Location acquisition should be provided by a consistent method across all network
17         configurations.
18         DA5 – Location determination and acquisition mechanisms should be applicable to
19         emergency calling; they may also be applicable to a wide range of value-added location-
20         based services.
21         DA6 – Location determination and acquisition techniques shall support both NENA i2 and
22         i3 network architectures.
23         DA7 – When measurement-based location determination mechanisms fail, the most
24         accurate location information available should be provided. Examples include: For mobile,
25         the Wireless Service Provider might provide tower/Access Point location, last known fix,
26         etc. For wireline, a LIS might provide a civic location that defines the serving area of an
27         access point, e.g., the State of Texas.
28         DA8 – Location determination and acquisition must have minimal impact on call setup
29         time in the event that location is not known ahead of time.
30         DA9       – Where a device is not location aware, the network should have the ability to
31         assert a location estimate on behalf of the device.
32         DA10 – Location acquisition methods should not require modification of
33         hardware/firmware in home-routers/modems.
34         DA11 – A location determination method must exist that does not require network
35         hardware replacement in the core network.
36         Rep1– Location information may be provided by-value or by-reference; the form is subject
37         to the nature of the request.
38         Rep2 – Location determination and acquisition mechanisms must support all location
39         information fields defined within a PIDF-LO.



                                                                                                         6
                                                 ATIS-XXXXXXX


 1         Rep3 – Location acquisition mechanisms must allow for easy backwards compatibility as
 2         the representation of location information evolves.
 3         Rep4 – All representations of location shall include the ability to carry altitude and/or floor
 4         designation. This requirement does not imply altitude and/or floor designation is always
 5         used or supplied.
 6         LocSec1– Location information shall only be provided to authenticated and authorized
 7         network devices. The degree of authentication and authorization required may vary
 8         depending on the network.
 9         LocSec2 – Location determination and acquisition methods should preserve privacy of
10         location information, subject to local laws and regulations applicable to the endpoint’s
11         geographic location.
12         LocSec 3 – The location or location estimate of a caller should be dependable.
13         LocSec4 – The location acquisition protocol must support authentication of the Location
14         Information Server, integrity protection of the Location Information, and protection against
15         replay.
16         LocSec5 – The location source shall be identified and should be authenticated. This
17         includes manually entered locations.
18         LocSec6 – Where a location is acquired and cached prior to an emergency call, it
19         SHOULD be refreshed at regular intervals to ensure that it is as current as possible in the
20         event location information cannot be obtained in real time.
21         LocSec 7 – Where location by-reference is used, the appropriate privacy policies MUST
22         be implemented and enforced by the LIS operator.
23


24   4     Location determination in Internet access networks
25         This section describes a range of access technologies and provides examples of how
26         location determination is possible, and the key parameters that need to be captured in
27         order to permit location determination in the general case.
                                                                                                                 Comment [r4]: Not baselined
28   4.1   Example ADSL network
29         Asymmetric Digital Subscriber Line (ADSL) is the fastest growing technology used to
30         deliver residential broadband service in the world and boast about 140 million lines world-
31         wide. Recommendations on DSL network configurations and protocols are provided by the
32         DSL forum and these are documented in Technical Reports (TRs) that are freely available
33         from the DSL forum website (www.dslforum.org).
34         The main DSL network configuration architectures are documented in TR-025 [15] and
35         TR-101 [16] and the two example networks described in this section will come from the
36         architectures recommended in these TRs.
37




                                                                                                             7
                                          ATIS-XXXXXXX


 1   4.2    Example cable network

 2   4.3    Example WiMAX network

 3   4.4    Example 3G cellular network

 4   4.5    Example enterprise (Ethernet switch/WiFi) network


 5   5 LIS Operational considerations

 6   5.1    Types of LIS and LIS Operators

 7   5.2    OSS integration considerations

 8   5.3    Certificate security and management


 9   6 Location acquisition protocols

10   6.1    HELD, DHCP, and LLDP-MED introduced

11   6.2    HELD, DHCP, and LLDP-MED gap analysis against NENA requirements

        NENA                HELD                    DHCP                      LLDP-MED
     Requirement

     DA-1           HELD provides         Yes                           Yes
                    acquisition/ FLAP
                    provides
                    measurements for
                    determination

     DA-2           Yes                   Yes                           Yes

     DA-3           Yes                   Yes                           Yes

     DA-4           Yes                   No                            No
                                          Since DHCP is not             Since LLDP-MED is not
                                          applicable in all network     applicable in all network
                                          technologies therefore this   technologies therefore
                                          acquisition mechanism         this acquisition
                                          cannot apply to all access    mechanism cannot
                                          networks.                     apply to all access



                                                                                                8
                                    ATIS-XXXXXXX


                                                                  networks.

DA-5       Yes                      The DHCP geodetic             The LLDP-MED
                                    encoding option is not        geodetic encoding
                                    suitable for encoding an      option is the same as
                                    emergency location See        that used for DHCP and
                                    [13]                          is not suitable for
                                                                  encoding an emergency
                                                                  location See [13]              Comment [r5]: T baselined


DA-6       Yes                      Yes                           Yes

DA-7       Yes                      No Possible (Assuming         No Possible (Assuming
                                    location not hard coded in    Llocation is not statically
                                    DHCP server)                  configured in switch
                                                                  entities)

DA-8       Yes                      Yes                           Yes

DA-9       Yes (using third party   No                            No
           terminal address value
           – On Behalf Of type
           request)

DA-10      Yes                      No                            No

DA-11      Yes                      No                            No

Rep-1      Yes                      Partial, DHCP does not        Partial, LLDP-MED does
                                    support by-reference          not support by-reference

Rep-2      Yes                      No                            No
                                    Method, presentity, rules,    Method, presentity,
                                    provided-by are not           rules, provided-by are
                                    supported.                    not supported.

Rep-3      Yes (PIDF-LO             Can only support change       Can only support
           definition evolves       through BIS ofrevision of     change through BIS
           independently of HELD    an option or a new option     revision of an option or
           acquisition protocol)                                  a new option

Rep-4      Yes                      Yes                           Yes

LocSec-1   Yes                      Yes                           Yes
                                    Can only provide location     Can only provide
                                    to the end-point              location to the end-point

LocSec-2   Yes                      Yes (except in                Yes (except in
                                    transmission since location   transmission since
                                    can only be transferred by-   location can only be


                                                                                             9
                                               ATIS-XXXXXXX


                                               value and not by-             transferred by-value and
                                               reference)                    not by-reference)

     LocSec-3        Yes (through signed       No                            No
                     location request
                                               No dependability              No dependability
                     mechanism)
                                               mechanism exists for a        mechanism exists for a
                                               PIDF-LO crafted by the        PIDF-LO crafted by the
                                               end-point                     end-point

     LocSec-4        Yes (through              Partial                       No
                     encryption of
                                               DHCP can provide integrity
                     appropriate attributes
                                               through [19], but not
                     in creation of location
                                               secrecy
                     signatures)

     LocSec-5        Yes (credentials          No                            No
                     associated with signed
                     location indicate the
                     source of the location.
                     A user provided
                     location may be
                     “asserted” and
                     subsequently signed
                     by the LIS)

     LocSec-6        Yes                       Yes                           Yes

     LocSec-7        Yes                       Not applicableNo              Not applicableNo
                                               DHCP does not support         LLDP-MED does not
                                               location by-reference         support location by-
                                                                             reference
                                                                                                          Formatted: Caption, Centered
 1                                  Table 1 Protocol Comparison Table
                                                                                                          Comment [r6]: Not baselined
 2   6.3   Findings
 3         22 NENA provided requirements on location acquisition and determination.
 4         HELD provides support for all 22.
 5         DHCP provides full support for 9 and partial support for 2, but cannot support the
 6         remaining 11.
 7         LLDP-MED provides full support for 9 and partial support for 1, but cannot support the
 8         remaining 12.
 9         In addition, to support mobile devices requiring a mid-call location update, a location
10         reference is the only practical solution and this mechanism is not supported by DHCP or
11         LLDP-MED.
12



                                                                                                     10
                                              ATIS-XXXXXXX


 1   6.4   HELD status


 2   7 Location parameter conveyance using FLAP

 3   7.1   LIS-ALE architecture

 4   7.2   FLAP protocol

 5   7.3   FLAP examples

 6   7.4   Benefits of FLAP versus “technology point solutions”

 7   7.5   Status of FLAP
 8


 9   8 References
10         [1]    NENA VoIP-Packet Technical Committee, “Interim VoIP Architecture for
11                Enhanced 9-1-1 Services (i2),” NENA 08-001, Dec 2005.
12         [2]    NENA Technical Committee Chairs, “Implementation of the Wireless Emergency
13                Service Protocol E2 Interface,” NENA 05-001, Dec 2003.
14         [3]    TIA-1057 TIA, “Link Layer Discovery Protocol for Media Endpoint Devices (LLDP-
15                MED),” TR 41.4
16         [4]    Winterbottom, J., Thomson, M., and B. Stark, “HTTP Enabled Location Delivery
17                (HELD),” draft-winterbottom-http-location-delivery-03 (work in progress),
18                May 2006.
19         [5]    Polk, J. and B. Rosen, “Session Initiation Protocol Location Conveyance,” draft-
20                ietf-sip-location-conveyance-02 (work in progress), March 2006.
21         [6]    Droms, R., “Dynamic Host Configuration Protocol,” RFC 2131, March 1997 (TXT,
22                HTML, XML).
23         [7]    Patrick, M., “DHCP Relay Agent Information Option,” RFC 3046, January 2001.
24         [8]    Polk, J., Schnizlein, J., and M. Linsner, “Dynamic Host Configuration Protocol
25                Option for Coordinate-based Location Configuration Information,” RFC 3825,
26                July 2004.
27         [9]    Peterson, J., “A Presence-based GEOPRIV Location Object Format,” RFC 4119,
28                December 2005.
29         [10]   Thomson, M. and J. Winterbottom, “Revised Civic Location Format for PIDF-LO,”
30                draft-ietf-geopriv-revised-civic-lo-02 (work in progress), April 2006.
31         [11]   Thomson, M., “Geodetic Shapes for the Representation of Uncertainty in PIDF-
32                LO,” draft-thomson-geopriv-geo-shape-02 (work in progress), May 2006.
33         [12]   Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6)
34                Option for Civic Addresses Configuration Information,” draft-ietf-geopriv-dhcp-
35                civil-09 (work in progress), January 2006.


                                                                                                   11
                                                 ATIS-XXXXXXX


 1          [13]   Winterbottom, J., Tschofenig, H., and M. Thomson, “GEOPRIV PIDF-LO Usage
 2                 Clarification, Considerations and Recommendations,” draft-ietf-geopriv-pdif-lo-
 3                 profile-04 (work in progress), May 2006.
 4          [14]   Winterbottom, J., Peterson, J., and M. Thomson, “Rationale for Location by
 5                 Reference,” draft-winterbottom-location-uri-01 (work in progress),
 6                 January 2006.
 7          [15]   DSL Forum, “Core Network Architecture Recommendations for Access to Legacy
 8                 Data Networks over ADSL,” Technical Report 025.
 9          [16]   DSL Forum, “Migration to Ethernet-Based DSL Aggregation,” Technical
10                 Report 101.
11          [17]   Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, “Geopriv
12                 Requirements,” RFC 3693, February 2004.
13          [18]   NENA Requirements for Location Information to Support Emergency Services,
14                 Draft 30 May 2006.
15          [19]   Droms, R. and W. Arbaugh, “Authentication for DHCP Messages,” RFC 3118,
16                 June 2001.
                                                                                                      Formatted: Heading 1
                                                                                                      Formatted: Bullets and Numbering
17   9 Definitions
                                                                                                      Formatted Table
     ASDL                    Asynchronous Digital Subscriber Loop

     ALE                     Access Location Element

     ALI                     Automatic Location Identification

     DHCP                    Dynamic Host Configuration Protocol

     FLAP                    Flexible LIS-ALE Protocol

     HELD                    HTTP-Enabled Location Delivery

     IP                      Internet Protocol

     LIS                     Location Information Server

     LLDP-MED                Link Layer Discovery Protocol – Media Endpoint Devices

     NENA                    National Emergency Number Association

     NGES                    Next Generation Emergency Services

     PIDF-LO                 Presence Indicator Data Format – Location Object

     PSAP                    Public Safety Answering Point

     SDO                     Standards Development Organization

     VoIP                    Voice over Internet Protocol


                                                                                                 12
                             ATIS-XXXXXXX



    WiMax   Worldwide Interoperability for Microwave Access

1




                                                              13

								
To top