Enterprise Location Applications


The most commonly used example for location has been in emergency applications; however, it is also useful in a great many applications that have nothing to do with emergency services, such as asset tracking or staff location, for example. Both of these are useful applications in a variety of environments. In this section, we shall describe two main applications, staff location/asset tracking, and variants on the emergency application. In the latter case, specific emphasis is placed on voice-hosted services; a growing trend in campus enterprises to reduce the spiraling costs of telecommunications.

Staff-Locator/Asset Tracker Application

In large enterprise campuses that support mobility of staff and assets, it is often important that people and things can be located quickly. In these types of environments, the devices and people that are going to be located have consistent or unique names, but their logical network addresses may not be known. For example, Dr. Smith is known, but the fact that his PDA has a MAC address of Oxab12cd34ef56 is probably not known. Furthermore, what happens if Dr. Smith buys a new PDA? How is he identified so he can be located? This shows that people, and sometimes assets, have common names that generally don't change through the course of their lifetime, and it is useful to be able to identify and locate them using their common names. In this section, we shall describe two ways in which a staff-locator/asset tracker application can be built using the location determination and acquisition techniques we have described thus far. The first method will use a client-based application, and the second will be network-centric.

A Client-Based Locator Application

In this solution, a device will start a HELD client when it boots, the HELD client will discover the LIS, and will either periodically request refresh location information or it will obtain a location URI by creating a context on the LIS. Generally, a single HELD client will reside on the end-host and it will provide an API that will allow multiple applications to make use of its services.

In this case, a thin staff-locator client will request the location or location URI from the HELD client via the API and will publish the name of the person, the IP address of the device, and the location information to a server running the staff locator application (see Figure 5.18). Likewise, when the application is shut down, it will deregister its information with the application server.

image from book
Figure 5.18: A client-based locator sequence diagram.

The staff locator application server is able to provide location information about registered users to people needing access to this location information. Where the location is provided as a literal by the thin-client, the application server can provide an immediate response to the request. Where the location is provided as a reference by the thin-client, the application server will first need to retrieve the device's location from the LIS. The type of network and the type of device involved will govern whether a literal location or a location URI is the most appropriate form of location information.

A Network-Based Locator Application

In many cases, the device-based application described in the previous section will work fine, but in some instances, modifying the equipment to include a locator application, no matter how thin, may simply not be possible. In such circumstances, a network-based application may be more appropriate.

Most of us have used a PC at work at one time or another, and usually your PC will have a name. If so, you can create a public-read directory on your PC so that other people in your office can access data that you want to share. Thus, if you get your IP address dynamically allocated, for the previous solution to work the DHCP server needs to tell the DNS server that a particular host has been allocated a particular IP address (see Figure 5.19). The mechanisms to do this are described in Reference 12. When a host requests an IP address from a DHCP server, it specifies its name (using DHCP option 12 defined in Reference 13) to the DHCP server. Once the lease is established, the DHCP server can dynamically update the DNS server with the hostname and IP address.

image from book
Figure 5.19: A DNS dynamic update.

So, looking at our previous example of Dr. Smith, the DNS server knows the name and IP address of all hosts in the network, including Dr. Smith's. This is closer, for if I know the name of Dr. Smith's host, I can now ask the DNS server for his PDA's IP address and I can then ask the LIS to find the IP address. But what if I only know his name or phone extension? The answer is Lightweight Directory Access Protocol (LDAP).

LDAP is a directory service protocol that allows a directory client to query a directory server, and it is very commonly deployed in enterprises. Things that might be kept in an LDAP directory server are things such as Dr. Smith, his phone extension, his mobile number, his e-mail address, his login name, and also possibly the hostname of any host Dr. Smith is currently logged into, including his PDA. Providing that asset and staff data are maintained in the LDAP server, then the server can be queried and the data obtained as required.

At this point, we can use a LIS to determine the location of anything on our network that is active by using a unique identifier in the LDAP directory.

Through the use of a secure web application server, web applications that allow fast location of assets and staff are possible (see Figure 5.20). Client applications, such as those running on the Reception and Asset Monitor hosts, may be simple web browsers, allowing the complexity to reside solely in the server. Care must be taken with such systems to maintain security so that location information relating to personnel and staff is not available to people who are not authorized to obtain it. Authorization to this information within an enterprise will be subject to company policy and federal, state, and local government regulations.

image from book
Figure 5.20: Asset and staff tracking configuration.

An Emergency Application

One of the major imperatives for location in IP networks is to support the routing of emergency calls, since an IP address outside the context of a local network provides little or no indication as to the physical location of a Target. IP telephony requires location for emergency routing to ensure that the call is delivered to the PSAP in the correct geographical area to deal with the emergency. There are two options available, provide a literal location with the call, or provide a location reference with the call. A location reference may be provided explicitly in the form of a location URI, or implicitly as a SIP AOR or the extension number of the caller encoded as tel-uri (tel-uri's are defined in detail in Reference 14). Where DHCP or LLDP-MED are used for location acquisition, the options are more limited, the end-point must provide a literal location object in the body of the call signaling. In a network where the HELD protocol is employed, a range of additional hosted services are available.

Hosted Voice Service with a Literal Location

In this situation, the enterprise outsource their call service to an Internet call service provider to reduce cost, and provide the IP call-server with a literal location when an emergency call is placed. Using the NENA-i2 architecture as a model, let's walk through a call example.

  1. The phone on the right-hand side of Figure 5.21 makes an emergency call.

  2. The PABX detects the emergency call and requests a PIDF-LO from the enterprise LIS for the phone making the call. The PABX uses the phone's IP address as an identifier to the enterprise LIS, as described earlier in this chapter.

  3. The enterprise LIS determines the location of the phone.

    1. The enterprise LIS may simply return the PIDF-LO to the PABX.

    2. Or the enterprise LIS may request a signed PIDF-LO from the access provider before returning a PIDF-LO to the PABX. We will address this situation more in the next chapter.

  4. The PABX inserts the PIDF-LO into the body of the outbound SIP invite message.

     NOTE: The document cited in Reference 15 supports PIDF-LO conveyance in the body of a SIP invite message. The SIP specification does not support a proxy inserting items into the body of a SIP message, consequently the PABX is considered a Back-to-Back-UA (B2BUA) when used in this mode, not a proxy (see Reference 16).

  5. The call-server receives the invite message and identifies the call as an emergency call, requesting routing information from the VoIP Positioning Center (VPC). This may be over the webservices-V2 interface, or through the SIP V5 interface. The call-server passes the PIDF-LO to the VPC in the routing information request.

  6. The VPC determines the correct routing information based on the location provided in the PIDF-LO.

  7. The VPC returns the routing information to the call-server and the call-server routes the call.

  8. The PSAP may now request the location from the VPC. No location updates are possible.

image from book
Figure 5.21: Emergency routing with a literal location.

In the provided example, the call is routed based on a literal location that is provided in-band with the call setup information. This same location is then made available to the PSAP. This is okay for a standard desk phone, but if the device was a dual-mode WiFi phone, then the user can move over time, and the PSAP would not be able to get location updates.

Hosted Voice Services with a Location URI

In this situation, the enterprise outsources its call service to an Internet call service provider to reduce cost, and provide the IP call-server with an explicit location URI when an emergency call is placed. Using the NENA-i2 architecture as a model, let's walk through a call example.

Let's walk through the steps of the call flow assuming SIP signaling for the actual call at least once it leaves the PABX.

  1. The phone on the right side of Figure 5.22 makes an emergency call.

  2. The PABX detects the emergency call and requests a location URI from the LIS for the phone making the call. The PABX uses the phone's IP address as an identifier to the LIS as described earlier in this chapter. This creates an active context on the LIS.

  3. The LIS responds with a location URI to the PABX.

  4. The PABX inserts the location URI into the location header of the outbound SIP invite message. This functionality is supported in Reference 15.

  5. The call-server receives the invite message and identifies the call as an emergency call, requesting routing information from the VoIP Positioning Center (VPC). This may be over the webservices-V2 interface, or through the SIP V5 interface. The call-server passes the location URI to the VPC in the routing information request.

  6. The VPC uses the location URI to request location information from the enterprise LIS.

    1. The enterprise LIS may simply return location information to the VPC.

    2. Or the enterprise LIS may have been requested to provide a signed PIDF-LO that it may, in turn, need to request from the access provider before returning a PIDF-LO to the VPC. We will address this situation more in the next chapter.

  7. The VPC determines the correct routing information based on the location provided by the LIS.

  8. The VPC returns the routing information to the call-server and the call-server routes the call.

  9. The PSAP may now request the location from the VPC whenever it likes during the course of the call. In turn, the VPC can request location updates from the enterprise LIS.

  10. At the completion of the call, the PABX terminates the active location context on the LIS.

image from book
Figure 5.22: Emergency routing with an explicit location URI.

The preceding call-flow, like the flow from the earlier example, is strictly NENA-i2-compliant. The advantage of this flow over the previous flow is that it allows the PSAP to request updates on the location of the caller, making it more suitable in situations where the caller may be moving around the enterprise campus.

The problem with this model is what while the call-server has a direct relationship with the enterprise, the VPC may not, since VPCs typically operate at the national level. Not having this direct relationship requires the VPC to establish a secure session with the enterprise LIS each time it needs to request a location. While this is not a long process, it does add some delay, so care must be taken to ensure that the LIS has sufficient bandwidth and accessibility to the Internet for VPC communication.

Hosted Voice Services with an Implicit Location Reference

In this situation, the enterprise outsources its call service to an Internet call service provider to reduce cost, but does not provide the IP call-server with a literal location or an explicit location URI when an emergency call is placed. Instead, the call-server must glean other information from the call-setup messaging to obtain location information. Using the NENA-i2-architecture as a model, let's walk through a call example.

Let's walk through the steps of the call flow assuming SIP signaling for the actual call once it leaves the PABX.

  1. The phone on the right side of Figure 5.23 makes an emergency call.

  2. The PABX addresses the outbound SIP message with a from header set to the directory number of the phone, say tel:+1-201-555-0123.

  3. The call-server receives the invite message and identifies the call as an emergency call. The call-server extracts the "from header" from the SIP invite message and uses the tel-uri to determine which enterprise LIS to request the location from.

  4. The call-server uses a nailed-up connection, or establishes a connection to the enterprise LIS and requests the location for tel:+1-201-555-0123.

     NOTE: To make a location request in this fashion requires the HELD protocol device identifier extension specified in Appendix E.

  5. The enterprise LIS uses an LDAP server to determine who the extension belongs to and their host name (see the section on Staff locator application earlier in this chapter). Once the hostname is known, DNS can be used to obtain the corresponding IP address. The LIS then uses the IP address to determine the location.

  6. The LIS returns the location to the call-server.

  7. The call-server sends the location to the VPC.

  8. The VPC determines the correct routing information based on the location provided by the LIS.

  9. The VPC returns the routing information to the call-server, and the call-server routes the call.

image from book
Figure 5.23: Emergency routing with an implicit location reference.

The solution described in this section does not strictly follow the NENA-i2 architecture. It does, however, result in the PABX not needing to be location-capable, which generates potentially lower infrastructure costs. This solution makes use of the fact that there is a preexisting relationship between the call-server and the enterprise network. Having the preexisting relationship reduces session establishment time between the call-server and the LIS, making the response faster. This also allows the enterprise LIS to remain shielded from the general Internet and thus less vulnerable to outside attack. Note that in this solution, location updates to the emergency network are not supported.



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