Constructing a Telecommunications Smart Space

Recall that in a smart space, one world senses and controls the other one. The UA running on the Internet interfaces with the PSTN to subscribe to a set of events that it is interested in. The EM saves this subscription in persistent store. When such an event is published in the PSTN, the EM runs the selection process using the published event and the policies stored for the consumer. If the selection process results in a match, the consumer's UA is notified. The UA thus senses and controls the events in the PSTN. We now present a set of five services that demonstrate the telecommunications smart space. The overall flow of the service is similar to that depicted in Figure 6.9.

The five services demonstrate the example scenario we opened the chapter with — the interaction of the consumer, Bob, with the events in the PSTN of various principals that he is interested in. The examples below employ many phone numbers that represent the event sources in the PSTN. Table 7.1 correlates a phone number (the event source) to the principal it represents.

In our implementation, encryption and authentication were provided by OpenSSL v0.9.7b. OpenSSL is an open-source library (freely available at that implements the Transport Layer Security (TLS) specification [DIE99]. Using OpenSSL, a secure socket is created between two communicating entities such that all information flowing through that socket is encrypted and the identities of the communicating endpoints authenticated. We acted as a self-signed CA and issued certificates for the PSTN service provider and all the user agents in the system.

Table 7.1 Correlation of an Event Source to a Principal

Event Source Principal

718-555-1212 Bob's manager

425-555-1212 Bob's brother

815-555-1212 Bob's home line

630-555-1212 Bob's cellular phone

847-555-1212 Bob's desk phone

718-555-1212 425-555-1212 815-555-1212 630-555-1212 847-555-1212

Policy tuples were stored in a SQlite v3.0.7 database. We loaded the database with 1 million (1M) policy tuples. SQlite is a public-domain small C library (< 250 KByte code space) that implements a self-contained, easy-to-embed-in-applications, zero-configuration Structure Query Language (SQL) database engine. It is freely available at

Our laboratory consisted of wireline switches and phones connected to them, other wireless switches, simulated cells, base stations, and cellular endpoints that received signals from the base stations. Using simulation tools, we are able to simulate the signal attenuation that reproduces the movement of cellular subscribers between cells. Figure 7.2 depicts the laboratory setup.

Database Certificate List

Wireless Access Point

Event Manager





Wireline Switch

Wireless Switch

Base Stations, Cells and Signaling Attenuator

Wireline Switch

Wireless Switch

SMS Simulator

Base Stations, Cells and Signaling Attenuator

Figure 7.2 Laboratory setup.

There were a number of wireline phones connected to the wireline switch. Each such phone published events when the principal it belonged to interacted with it. These events were published to the EM, which analyzed them for a pending subscription. Likewise, the wireless switch had a number of wireless phones connected to it through a bank of equipment that simulated base stations and cells. A principal interacting with the cellular phone would publish events that made their way to the EM for mediation. The bank of equipment that simulated cells and base stations also came with software that allowed us to attenuate the signal strength monitored by the cellular phones. We could thus simulate movement of the principal by calming the signal strength in one cell and intensifying it in the adjoining cell. The cellular phone would sense the intensity of the new signal and use it instead. We also had access to an SMS simulator, which would send an SMS message destined to a particular phone to the wireless switch. The recipient phone would be turned off, causing the wireless switch's attempt to page it to fail (in cellular networks, the wireless switch pages the cellular phones in an area to locate them). The failure event, in association with sending an SMS, was trapped and published to the EM. The net result of this would be to simulate a principal's cellular phone being turned off and thus incapable of receiving SMS messages.

In our prototyping, we detected and published all events from the switches for both the wireline and wireless PSTN. This was done out of necessity because it was not always possible to get a configured Service Control Point (SCP), home location register (HLR), or visitor location register (VLR). However, this step in no way compromised the integrity of our architecture or prototype because the EM really does not care from where the event was published. The events published from the switches to the EM arrived over a Transmission Control Protocol (TCP) connection. The Presence Service

In Chapter 6, we argued that the presence service, popular on the Internet, is just as applicable to the PSTN. Whereas on the Internet the presence service is triggered by the principal using a device — a computer — to actively log into the presence system (Yahoo! Messenger, for instance), on the PSTN presence can be deduced from the interaction of the principal with another device — the phone.

Our opening scenario in this chapter demonstrated the need for such a service for our consumer, Bob.

Bob's manager is flying in to meet him and Bob would like to be notified of her presence as soon as the manager arrives at Chicago airport and turns on her cellular phone.

SUBSCRIBE sips:[email protected] SIP/2.0 Event: spirits-user-prof

Allow-Events: spirits-user-prof, spirits-INDPs Accept: application/spirits-event+xml, application/pidf+xml Content-Type: application/spirits-event+xml Content-Length:...

<?xml version="1.0" encoding="UTF-8"?>

<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0"> <Event type""userprof" name="REG">

<CalledPartyNumber>7185551212</CalledPartyNumber> </Event> </spirits-event>

Figure 7.3 Presence subscription for principal.

Accordingly, Bob runs his UA, which sends the subscription shown in Figure 7.3 to the EM.

There are a few items of interest in Figure 7.3. First, Bob's UA is informing the EM of all the event types it can handle through the Allow-Events header (spirits-user-prof and spirits-INDPs, which correspond to the extensions we propose in Chapter 6). This subscription itself corresponds to the spirits-user-prof event package, which transports non-call-related events between the networks.

The second item of interest is the Accept header. The Accept header in Internet protocols such as Hypertext Transfer Protocol (HTTP) and SIP serves to inform the recipient of the Multipurpose Internet Mail Extension (MIME) types the sender can accept and interpret. In Figure 7.3, Bob's UA is able to interpret two MIME types: application/spirits-event+xml and application/pidf+xml. The former MIME type corresponds to SPIRITS XML documents, and the latter corresponds to XML documents that transport presence-related information. The Presence Information Document Format (PIDF) [SUG04] is an IETF standard that describes the format of an XML document conveying the presence state of a principal. We will provide more information on a PIDF XML document later in this section.

The final item of interest is the Content-Type header; this header contains the MIME type — application/spirits-event+xml — corresponding to a SPIRITS XML document. In the XML document, Bob's UA is issuing a subscribe for the REG (registration) event of the principal's cellular phone, identified by the number 7185551212.

Assuming the subscription sent by Bob's UA was accepted by the EM, Bob's UA will update its visual interface (see Figure 7.4). Notice the last row — 7185551212 — is set to "Unavailable;" i.e., the system does not have

§ SPIRITS Presence User Agent

-loi xl|




Vijay (A way) ^^ Prof. Sun (Unavailable) 8155551212 (Available) Tom (OK to lunch) Sudha (Available) ^^ 11 «5661212 (Unavailable)

PSTN Buddy (Online)

Figure 7.4 Depicting presence.

any information about the principal at this time. At a certain point in time after the subscription has been accepted, and while it is still fresh, the principal (Bob's manager) lands at O'Hare Airport. She turns on her cellular phone, which registers with the cellular network and sets in motion further processing of Bob's pending subscription. As soon as the cellular phone registered, the cellular switch published that event to the EM. The EM executed the selection process to determine if any consumer was subscribed to events published by the principal. The selection process returned true for Bob's pending subscription. Subsequently, the EM collects all the relevant information from the database regarding where to send the notification (Bob's UA had imparted this information, which was saved in the database during the subscription phase), creates a notification, and sends it. Figure 7.5 depicts such a notification.

As before, there are a number of items of interest in the notification. First, note the SPIRITS XML document in the payload. This document contains the event that was published (REG) along with the Cell-ID parameter, which is mandatory in the notification according to the rules specified in Table 6.3.

Event: Spirits-user-prof

Allow-Events: Spirits-user-prof, spirits-INDPs Content-Type: Application/spirits-events+xml Content-Length: ...


Namespace for SPIRITS

<?xml version="1.0" encoding="UTF-8"?> <Spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0"

xmlns:pidf="urn:ietf:params:xml:ns:pidf"> <Event type="userprof" name="REG"> <CalledPartyNumber>7185551212</CalledPartyNumber> <Cell-ID>98123-1</Cell-ID> </Event>

<pidf:presence entity="pres:[email protected]"> <pidf:tuple id="sg891"> <pidf:status>

<pidf:basic>open</pidf:basic> </pidf:status> </pidf:tuple> </pidf:presence> </spirits-event>



PIDF >XML Document

Figure 7.5 Notification containing multiple XML documents.

The second item of interest is the MIME-type negotiation occurring between the consumer (Bob's UA) and the notifier (EM). In Figure 7.3, the consumer indicated the capability to support an additional MIME type, namely, the one corresponding to PIDF documents (application/pidf+xml). Thus, when the notification is sent, a portion of the payload contains a PIDF XML document. A PIDF document contains a number of attributes; we provide enough information to interpret Figure 7.5. Interested readers are urged to consult [SUG04] for an in-depth treatment of PIDF.

A PIDF document is published on behalf of a URI identified in the "entity" attribute of the <pidf:presence> element. In our example, this is a device corresponding to Bob's manager. The <presence> element may contain multiple <tuple> elements, each segmenting a specific device that is contributing to the overall presence of the principal.

Each <tuple> element contains a <basic> element that can have a valid value of either "open" or "closed," corresponding, respectively, to whether the principal is available for communication (i.e., present) or not (i.e., absent).

The last item of interest is the use of namespaces in the XML document. The notification is carrying a payload in the form of a SPIRITS XML document (identified by the Content-Type header). Recall that the SPIRITS schema, as outlined in Appendix A, is extensible through the use of other namespaces; thus, the SPIRITS XML document in Figure 7.5 includes a namespace extension such that elements from a PIDF XML schema can be included in

■& SPIRITS Presence User Agent






Prof. Sun (Unavailable) ^ 8155551212 (Available)

Tom (Out to lunch) ^ Sudlia (Available)

7l8i>i»i>l2l2 (Available)

PSTN Buddy (Online)

Figure 7.6 Updated presence information.

the SPIRITS XML document. XML's namespace extension mechanism provides a powerful way to represent complex states of an event source.

When Bob's UA receives this notification, it extracts the PIDF information to set the presence state of the device belonging to Bob's manager to "Available" (see Figure 7.6). In this manner, Bob knows in real time when his manager has arrived at the airport. He is thus able to make the best use of his time to prepare for the subsequent meeting. Note that the notification also contained a Cell-ID, which provides rough information on where the manager currently is. We will revisit location-based services in Section Availability

When Bob arrived to work in the morning, he discovered that he has to attend an all-day meeting scheduled at the last minute. He calls his wife to tell her about his plans only to find that his home phone is busy.

Clearly, Bob would like the telephone network to inform him when his home phone becomes available again, so he can call his spouse. The alternative is to keep on trying or have his wife reach him while he is in the meeting. Thus, availability as a service can be applied equally as well to PSTN endpoints. Traditionally, the PSTN knows of the state of devices representing principals, but it has not been able to leverage this information to provide an availability axis to the presence dimension.

To compose the availability status of his home phone line, Bob's UA sends a subscription to the EM that contains the following events drawn from Table 6.1: OAA, OD, TA, and TD. The first two events correspond to the case where Bob's wife was the caller; i.e., she picked up the phone to make a call (OAA) and subsequently disconnected after the call was over (OD). The last two events cover the case if Bob's wife were the target of someone else's call; i.e., she answered the phone (TA) and subsequently disconnected after the call was over (TD).

Because the subscription from Bob's UA reaches the EM while the conversation was already in progress, the EM is unable to create an availability composition; thus, it sets the state of the principal to "Unavailable" as a default (see the last row of Figure 7.7a). For scalability, the EM is stateless, i.e., it does not correlate previous events with future ones. Thus, when the event that rendered to Bob's home line to be busy was published, there was not any pending subscription against it. Thus, it was simply dropped. The statelessness of the EM is explored further in Section 7.4.

Following the acceptance of the subscription from Bob's UA, whenever a OD or TD event is published to the EM, it sends out a notification that

Figure 7.7 Depicting availability.

causes Bob's home line to become "Available," as depicted in Figure 7.7b. Bob can now break out of his meeting to talk to his wife based on the latest availability information imparted to him on an Internet device by the telephone network.

Besides composing simple availability, as shown in Figure 7.7, our system can be used to impart a temporal component to availability as well. For this to occur, the subscription from Bob's UA must reach the EM while there is not already a call in progress on a principal's line. If this is indeed the case, then when the principal picks up the phone to make a call (or receives a call), the EM composes an availability document with temporal information in it. Figure 7.8 shows the result of such an availability composition. Notice the last row: it contains the time since the phone line has been engaged in a conversation.

From a protocol perspective, the information for temporal availability is carried in a PIDF element called <note>. This element, in a PIDF document, contains a string value, which is usually used for a human-readable comment. Figure 7.9 reproduces the XML document that shows that Bob's home line received a call (the published event is TA, which signifies that the terminating party picked up the phone). Also note the

t SPIRITS Presence User Agent




Vtjay (Away)

Vtjay (Away)

^ Prof. Sun (Unavailable) 7185551212 (Available) Tom (Out to lunch) Sudha (Available) 8155551212 (In a call since Tue Oct 1214:46:03 2004)

PSTN Buddy (Online)

Figure 7.8 Depicting temporal availability.

<?xml version="1.0" encoding="UTF-8"?>

<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0" xmlns:pidf="urn:ietf:params:xml:ns:pidf"> <Event type="INDPs" name="TA">

<CalledPartyNumber>8155551212</CalledPartyNumber> <CallingPartyNumber>2 015551212</CallingPartyNumber> </Event>

<pidf:presence entity="pres:[email protected]"> <pidf:tuple id="sg891"> <pidf:status>

<pidf:basic>open</pidf:basic> </pidf:status> </pidf:tuple>

<pidf:note>In a call since Tue Oct 12 14:46:03 2004</pidf:note> </pidf:presence> </spirits-event>

Figure 7.9 XML document transporting temporal availability.

PIDF <note> element. When Bob's UA receives such a document, it extracts the value of the <note> element and displays it in the user interface of Figure 7.8.

Figure 7.9 also contains other related information in the form of the calling party's identity (2015551212), which is available to Bob's UA to display to Bob, should it so desire. An IM from the Telephone Network

Bob is expecting an important call from his brother, which he will likely miss while he is in the meeting. When his brother calls Bob's cellular or office phone, Bob would like the PSTN to inform him through an unobtrusive IM on his PDA.

To do so, Bob runs a UA on his PDA that he will be taking with him to the meeting. His UA asks him for phone numbers to monitor (see Figure 7.10). Bob enters two phone numbers, corresponding to the numbers of his cellular phone and his desk phone. Bob is interested in getting a notification as soon as someone calls him at either of the numbers. Bob's UA sends out a subscription with the filter containing events for the two phones Bob uses; Figure 7.11 shows such a subscription. There is one salient point in Figure 7.11. Note the Accept header. This header contains three SIP requests that Bob's UA can accept: SUBSCRIBE, NOTIFY, and MESSAGE. Of interest to us is the last request, MESSAGE. This is a SIP extension, defined in [CAM02a], which transmits discrete text messages

Figure 7.10 User interface for the IM user agent.

SUBSCRIBE sips:[email protected] SIP/2.0

Allow: SUBSCRIBE, NOTIFY, MESSAGE Allow-Events: spirits-user-prof, spirits-INDPs Event: spirits-INDPs

Accept: application/spirits-event+xml, text/plain Content-Type: application/spirits-event+xml Content-Length:...

<?xml version="1.0" encoding="UTF-8"?>

<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0"> <Event type="INDPs" name="TAA" Mode="N">

<CalledPartyNumber>63 05551212</CalledPartyNumber> </Event>

<Event type="INDPs" name="TAA" Mode="N">

<CalledPartyNumber>847 5551212</CalledPartyNumber> </Event> </spirits-event>

Figure 7.11 Subscription for an instant message.

using SIP as the transport protocol. The body of such text messages is defined by the MIME-type text/plain, which is included as an accepted payload in the Accept header of the request.

The payload of the SIP SUBSCRIBE request shown in Figure 7.11 is a SPIRITS XML document. The filter represented by the XML document, in essence, informs the PSTN that a notifier is willing to receive notifications when the TAA event is published for two phone numbers (6305551212 and 8475551212, corresponding to Bob's cellular phone and Bob's desk phone, respectively).

At some later point in time, Bob's brother calls Bob's desk phone. This causes the selection process in the EM to execute the filter installed in Figure 7.11. The result of this will be the publication and dissemination of the TAA event to Bob's UA. When Bob's UA receives the notification, it displays an IM in the user interface, as depicted in Figure 7.12. The IM discreetly informs Bob that his brother attempted to reach him by calling Bob's desk phone at a certain time.

There is a subtle protocol interplay occurring behind the scenes to fulfill this service. Note that when Bob's UA issued a subscription, it indicated support for transporting IM messages in SIP through its acceptance of the MESSAGE request. The EM thus has a choice in informing Bob's UA of the event. It can choose one of three choices: First, it can send a NOTIFY message, followed by a MESSAGE request. The former informs Bob's UA of the event that occurred, and the latter contains the IM. Second, it can send one notification message that contains a multipart MIME payload. Multipart MIME is an IETF standard [FRE96b] that allows multiple objects, each corresponding to a specific MIME type, to coexist in a single payload. Thus, the single payload will contain two parts: (1) the SPIRITS XML document carrying the event that occurred and (2) a plain text message containing the IM. The third choice the EM has is to simply send a NOTIFY message containing a

Figure 7.12 Incoming call notification as an instant message.

SPIRITS XML document and depend on Bob's UA to construct an IM from the contents of the SPIRITS document and display it to Bob.

In our implementation, we chose the second option, i.e., a NOTIFY followed by a MESSAGE. Figure 7.13 contains portions of a MESSAGE request, and Figure 7.14 contains a flow of the messages between the communicating entities.

Finally, a feature of our implementation is the support of a pseudoprincipal called the PSTN Buddy. Figure 7.6 to Figure 7.8 depict this pseudoprincipal, which is always present (see lower right-hand side of the user interface in these figures). This pseudo-principal is used by the telephone network to originate instant messages; such messages arriving at a UA are shown to be from the PSTN Buddy (see the IM in Figure 7.12 for an example).

MESSAGE sips:[email protected] SIP/2.0

Content-Type: text/plain Content-Length:...

From PSTN buddy: Phone call from 4445551212 to 8475551212 at Thu Oct 14 11:19:47 2004

Figure 7.13 MESSAGE request.

Bob's UA (Consumer)

EM (Producer)


200 OK


Subscription Accepted

200 OK


200 OK

Incoming Phone call to 847-555-1212

Cellular Switch

Wireline Switch

Figure 7.14 Message flow. Transforming an SMS to an IM

Bob keeps in touch with his colleagues at other locations through the cellular SMS. This morning, Bob did not bring his cell phone to work, so he will miss all SMS messages destined to his cell phone. Bob would like the PSTN to intercept the SMS messages destined for his phone and transform them to IMs to be delivered to another of Bob's devices connected to the Internet.

This is a good example of an application-specific service. To realize such a service, an event filter must be created that contains an event pertinent to the operation of an SMS, especially an event that is published when the cellular network attempts to determine Bob's location so it can send him the SMS. Of all the events we have cataloged thus far, none of them is amenable to use in the SMS application. Yet, clearly, the cellular network knows if the recipient of an SMS is unavailable because it queues the SMS for later delivery. The challenge is getting access to this trigger and representing the event filter in a schema pertinent to SMS.

We propose an SMS XML schema, provided in Appendix C, to solve the problem of representing SMS-specific events. Regarding access to a trigger that is appropriate for publishing the SMS arrival event, we have two choices. First, we can detect this trigger in a specialized server called a message center (MC) [GAL97]. The MC provides a store-and-forward function for SMS messages. An MC can serve as a good event source of SMS-related messages.

Another equally good event source could be the mobile switching center (MSC) itself. The MSC is involved with all aspects of signaling in the cellular network. For instance, it knows whether the recipient of the SMS message is registered with the network. If the recipient is not registered, the MSC can take appropriate action by acting as an event source for SMS-related triggers.

In our implementation, we used the latter approach. When the MSC determined that the recipient was not responding to a paging message, the MSC, acting as an event source, sent an SMS-related event to the EM. The contents of the message included the sender's tel URI and the SMS message itself. The SMS message was transmitted to the MSC using the SMS simulator in the laboratory.

Figure 7.15 contains an XML filter that Bob's UA may use to subscribe to the arrival of an SMS message. This document identifies the principal (Bob) through his cellular phone number (6305551212). The filter establishes two constraints identified by the <DeliveryType> element. The first constraint (Failure) signifies failure to locate Bob; i.e., the cellular network could not locate Bob, possibly because Bob's cellular phone is turned off. In such a case, the SMS should be transformed to an IM message and sent to the URI provided in the <IM> element.

The second constraint (In-addition-to) specifies that even if Bob is successfully located, the cellular network is to send the SMS to his device and, in addition to that, transform the SMS into an IM and deliver it to the URI provided in the <IM> element.

The URI in the <IM> element has a parameter (method=MESSAGE), which in SIP signifies the name of the SIP request that should be used to contact the URI. That is, the cellular network will use the SIP MESSAGE extension to transport the IM.

Figure 7.16 contains a screen shot of our integrated user interface that depicts three smart-space services: the left-most panel contains a presence and availability service (already discussed in Sections and,

<?xml version="1.0" encoding="UTF-8"?> <sms xmlns=""

xmlns:xsi=" 001/XMLSchema-instance" xsi:schemaLocation=" SMS.xsd" Principal="tel:6305551212">



<IM>sips:[email protected];method="MESSAGE"</IM>

Figure 7.15 An XML document with a filter for converting SMS to an IM.

Figure 7.15 An XML document with a filter for converting SMS to an IM.

847 555 1212

Figure 7.16 An integrated user interface.

respectively), the center panel contains geolocation-based services (discussed in the next section), and the right-most panel contains a text area that displays the incoming IM equivalent of an inbound SMS message destined to the recipient's cellular phone. In the SMS panel of Figure 7.16, Bob's brother, identified by his device (4255551212), has sent an SMS message to Bob's cellular phone. When the MSC receives the SMS message, it acts as an event source and sends the message to the EM. The EM extracts the SMS text from the message, creates a SIP MESSAGE request with the Request-Uniform Resource Identifier (R-URI) set to sips:[email protected], and transmits the message securely to Bob's UA.

Our architecture and methodology also enable multimedia messages (MMSs) [3RD02] to be delivered to a principal using only a 2.5G phone. The principal would install a filter with the MMS center such that MMSs are shunted to his Internet UA, while normal SMS messages go to his 2.5G phone (or his Internet UA). MMS is a technology that extends SMS into the space of multimedia. Instead of simply sending text messages, MMS allows its users to send messages in the form of images, audio, video, text, and combinations of these. Location-Based Services

Bob would like to track the location of his manager as she makes her way to Bob's office from the airport. This will allow Bob to better prepare for the meeting by taking advantage of any extra time afforded to him if the manager gets delayed by traffic.

When Bob's manager arrived at the airport, Bob knew of this because he had subscribed to the presence state of his manager through the manager's device. Because Bob would like additional, real-time information on the progress of his manager as she drives over, Bob instructs his UA to install a new subscription filter with the cellular network. This subscription filter, depicted in Figure 7.17, requests notification for two events associated with the manager's device: LU7SV and LUDV (i.e., location updates in the same area and a different area).

As Bob's manager travels, she crosses from one cell area to the next. The cellular system thus keeps track of her progress. Whenever her location changes in this manner, the MSC receives a location update message. Technically speaking, the detection of a principal in a new serving system is an example of a registration event [GAL97, pp. 162-163].

Registration always occurs when the cellular phone is turned on. Timer-based or autonomous registration occurs at periodic intervals — ranging

SUBSCRIBE sips:[email protected] SIP/2.0 Event: spirits-user-prof

Content-Type: application/spirits-event+xml Content-Length:...

<?xml version="1.0" encoding="UTF-8"?>

<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0"> <Event type="userprof" name="LUSV" mode="N">

<CalledPartyNumber>7185551212</CalledPartyNumber> </Event>

<Event type="userprof" name="LUDV" mode="N">

<CalledPartyNumber>7185551212</CalledPartyNumber> </Event> </spirits-event>

Figure 7.17 An XML document with a location filter.

from ten minutes to one hour — while the cellular phone is turned on. The granularity of autonomous registrations is typically transmitted to the cellular phone by the serving MSC. And finally, if a principal of the cellular phone is engaged in a conversation, the system tracks the location of the principal for handoffs (a handoff is the seamless transfer of an ongoing call from one base station to another). The end result of the registration and handoff process is that the MSC is aware of the location implications of the cellular phone.

In our laboratory setup, we employed the signal attenuator to depress the signal strength in one cell area and increase the intensity in an adjoining cell area. The cellular phone would then register with the system in the new cell area, thus simulating mobility. When the MSC received a message from the cellular phone that involved such movements, it, in turn, published an event to the EM containing this information.

The EM executed the selection process to send out the event to an Internet UA. In the notification, the EM included a Cell-ID parameter (as required by Table 6.3). We programmed the UA to use the Cell-ID as an index into an associative array of images; each image corresponded to the geographical area covered by that cell. The Internet UA extracted the Cell-ID parameter from the notification and used it to retrieve a map image that was rendered on the user interface (see center panel of Figure 7.16).

Tracking the location of a principal in this manner is useful, but probably not very optimal. For one, cellular boundaries may change, requiring updated image maps to be downloaded. Furthermore, the granularity of the autonomous registrations may be fairly large, which makes such tracking inadequate. And finally, the geographic area encompassed by a cell may vary; in dense urban canyons, a cell may be fairly limited in diameter, but in sparsely populated rural areas, a cell may be defined by a larger boundary. However, despite these shortcomings, location tracking in the manner we describe is useful for a variety of operations. Consider, for example, fleet tracking. A taxi dispatcher needs to know the approximate location of a taxi nearest to the customer when a call arrives at the dispatcher. Or, as a further example, parents may consider using this technology to know the approximate whereabouts of their children. Some other examples include targeted advertising, wherein a business solicits customers that are in the vicinity through an SMS message (or an IM, if the customer's phone is connected to the Internet), and a friend finder, where two friends in the same geographic area (a mall, for instance) are notified of each other's proximity. In all of these examples, an approximate location instead of an exact location suffices, and the cellular network already has this information.

Exact locations can be provided by the geographical positioning system (GPS). However, this technology has its drawbacks, primary among them that it does not always work indoors. A cellular signal, on the other hand, does not suffer from this drawback.

0 0

Post a comment