A Generic Architecture


The section on location determination in cellular networks earlier in this chapter described how an end-to-end network location service could be divided into three critical functions. While this functional decomposition was observed with respect to the cellular location services architecture, it can be equally applied to one dealing with the location of arbitrary IP devices. These functions are as follows.

  • Location measurement

  • Location determination

  • Location acquisition

Before elaborating further, it should be noted from here on that "IP device" is used to refer to the IP network entity whose location is being determined. It is the subject of any location requests that are occurring and it can also be referred to as the "target" of the location request. An IP device may be any piece of network-connected equipment, such as a personal computer, a PDA, or a soft drink vending machine. The only requirement is that it be connected and have an IP address associated with it.

Figure 1.13 shows how the entities in a network-based location architecture participate in each of these functions. The LIS is shown as the element which collects measurements. These measurements may be obtained from

  • Network fabric components (for example, switches, wireless access points, and circuit aggregators)

  • Overlay network elements (for instance, location measurement units and network monitoring devices)

  • The IP device itself (such as a device taking GPS measurements, RFID beacon readings, or LLDP type measurements)

image from book
Figure 1.13: Location architecture functional layers.

There is an additional function associated with the location services architecture, and that is the actual transporting of location information between one network entity and another. Note that this is distinct from "location delivery" because that term specifically refers to one network element providing an answer to an explicit request for location information. The transporting of location information occurs whenever one piece of application client or server code is communicating with another, and where one of the parameters of that communication is some piece of location information. For example, a VoIP device communicating with an SIP server may initiate a call by sending an INVITE message, and this message may include an optional parameter that would be interpreted as the location of the caller and may be used to route the call depending on what that location is-for example, to a pizza franchise which services the caller's location. Or, as another example, a web-based navigation application may require the desired destination to be provided as a specific XML form of location and be sent on HTTP.

This function is termed "location conveyance" in this text. An example of a location conveyance interface is also shown in Figure 1.13 where the IP device may send location information directly to an application using some application-specific protocol. The manner in which location conveyance is done is highly application-dependent. While there is good reason to identify a universally consistent method for performing location delivery in IP networks, location conveyance can be expected to take many forms depending on the nature of the applications, devices, and applicable protocols. This is the case whether the location information is delivered in a literal form or by reference. The difference being that, in the case of the latter, a recipient network entity such as an application server may need to also be able to invoke the location delivery protocol toward the LIS.

Revisiting Figure 1.13, it can be seen that the LIS has two key functional protocols that it should support. These are as follows

  • A measurement protocol for obtaining relevant measurement information

  • An acquisition protocol for service requests for location information

From the perspective of the LIS, these protocols are applicable to the following interfaces

  • Measurement-LIS to Network and LIS to IP device

  • Acquisition-LIS to IP device and LIS to applications

There is one more important characteristic relevant to the process of "measurement" that needs to be discussed before we go on to look at the details of the measurement and delivery protocols. This has to do with the relationship that should be assumed between the LIS and the network, and the LIS and IP devices. The relationship with the network can be termed "static," and the relationship with the IP devices can be termed "dynamic." This is explained as follows.

A LIS is assumed to be strongly associated with a particular access network. For example, it may provide the LIS function for a switched Ethernet network servicing a range of subnets in a commercial office space. Alternatively, it may be associated with an ADSL network servicing subscribers in a particular market region. In any case, the LIS will have contextual information applicable to the access network that it can use to determine location. In the first of the previous examples, the LIS may have information about the building and room number that each Ethernet switch port terminates to. Or, in the case of the ADSL example, it may have information that relates a particular ATM circuit in the ADSL aggregation network to a specific DSLAM termination that in turn relates to a particular copper loop terminating at a specific subscriber residential address. These pieces of information are stored in the LIS and are known by it prior to any location requests occurring. By the same token, it is necessary for the LIS to be aware of the network measurements that are relevant to it and where it will obtain those measurements. This information is also kept by the LIS and, while it may be subject to modification over time, it is static in the sense that it applies regardless of when or where a particular location request may originate. The LIS is, therefore, in a position to establish a session with the important points in an access network, and to maintain those sessions over time, in anticipation of obtaining location measurements.

IP devices, on the other hand, will arbitrarily come and go within the access network without any foreknowledge on the part of the LIS. The first indication that an LIS may have of the presence of an IP device may be at the moment that the device presents a request for location acquisition to occur. In this sense, the relationship of the LIS with IP devices is dynamic. Also, since IP devices attach themselves to the network for reasons outside the scope of influence of the LIS, there is no forward indication of what sort of measurements an IP device may be capable of providing-that's if it can provide any at all. Compared to the access network, where the LIS is preconditioned to understand what measurements it can obtain from the network, there has to be a more dynamic interchange to understand what measurements can be obtained from the IP device. There is also a dependency on the LIS to be able to cope with the types of measurement provided by the device or, alternatively, be able to "gracefully ignore" the measurements without compromising the quality of the location determination.

These qualitative differences in terms of whether the relationship is static or dynamic influence the specific details of the protocols associated with obtaining measurements from the network versus obtaining them from the IP device. This will be seen later in the text, and the description that follows explains why these differences will be seen.

Figure 1.14 recasts Figure 1.13 with the LIS as the hub of the architecture, simultaneously obtaining location measurements from the access network and servicing requests for location delivery from IP devices and applications. In terms of obtaining measurements from the access network, a new subentity is identified in the referenced figure. This is the access location entity (ALE). The role of the ALE is to make available the measurements that are required by the LIS. It is expected that a single instance of an LIS may service an arbitrarily large area of coverage by one or more access technology types. Further, it is assumed that this area of coverage may include an arbitrary number of IP networks of different routing domains. From this perspective, there needs to be some entity, whether physical or logical, which is capable of collecting the localized network measurements and, as a signaling peer to the LIS for the measurement protocol, provide those measurements to the LIS. This signaling peer is identified as the ALE for that localized network.

image from book
Figure 1.14: The LIS centralized architecture.

The protocols that are defined in detail in the rest of this text are as follows.

  • Network location measurement protocol-Flexible LIS-ALE Protocol (FLAP)

  • IP Device and application location delivery protocol-HTTP Enabled Location Delivery (HELD)

These protocols have been defined to ensure that the LIS can fulfill the requirements listed earlier in this chapter. An LIS that supports HELD and the FLAP provided measurements applicable to the network it covers will be able to service location acquisition requests from any HELD-capable device or application. The one function that hasn't been described so far is how an IP device knows, or how it "discovers," the identity of the LIS servicing the network to which it has attached and that it should send location delivery requests to. This area of "LIS discovery" will also be described in detail further in the text.



IP Location
IP Location
ISBN: 0072263776
EAN: 2147483647
Year: 2004
Pages: 129

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net