In wireless data & voice networks, many of the Mobile End Systems (M-ESs) may be unavailable at any given time. There are two main reasons for this:
Current methods for dealing with the transient nature of M-ESs involve periodic polling or repeated attempts to deliver a message to a recipient which might be unavailable, and these are costly in network traffic and delivery delays.
The occasionally connected nature of M-ESs introduces the challenge of delivering information to the devices in a timely and efficient manner. Existing solutions to this problem are generally inefficient. We attempt to address this problem in an efficient and timely manner by introducing the Loaction & Status Notification Service (LSNS), where the current status (active/inactive) and the general location of the M-ES is determined and communicated to those parties which should be provided access to such information.
LSNS allows the state and the general location of the intended recipient to be known, and for notification of changes of that status. This allows messages to be sent only when the recipient is available, and quick delivery of pending messages when an M-ES becomes available.
The status and general location of an M-ES is sensitive information subject to privacy restrictions which should be under the control of the M-ES owner. For this reason, control of access to this information is an integral part of this document.
Basic concept and capabilities of LSNS are relevant to networks which support mobility. Such mobile and wireless networks include CDPD, Mobile-IP and the cellular voice network.
In the traditional information exchange model the originator of information assumes that the recipient is ready and willing to accept the information. The introduction of occasionally-connected devices which are often disconnected from the network invalidates this assumption because the occasionally-connected devices are often not available for information exchange.
Attempting to communicate with an occasionally-connected device suffers from the inherent problems of efficient and timely notification of the availability and desire of the communicating parties. The originator needs to know whether or not the intended (occasionally-connected) recipient will be likely to successfully receive the data. Similarly the recipient needs to know about the originator's intent to transmit data to it.
Most networks supporting mobility have end systems which are only occasionally connected. The problem of end system status notification is particularly relevant in these networks.
In local area networks (LANs) and high bandwidth networks the problem of end system status notification is insignificant because a failed attempt to transmit data between end systems is inexpensive in terms of resource conception. However, in wide area networks (WAN) environments, a failed data transmission is much more costly in terms of resource consumption and thus the problem of status notification is quite significant.
Both device and network performance is greatly enhanced if the originator knows the current status (e.g., reachable or unreachable) of the occasionally-connected recipient and if the occasionally-connected recipient knows that the originator desires communication with it. This service provides a mechanism by which each of the communicating parties is efficiently notified about the status of its communications peer.
In the most general case, a corresponding end system (C-ES) communicates with an occasionally-connected end system (OC-ES) using information provided by the Location & Status Notification Service (LSNS). A corresponding end system may be any system other than the originating end system (O-ES). An example of a corresponding end system would be a mail server which is always available and which can communicate to OC-ES on behalf of the originating end system (i.e., sender of e-mail).
Traditional application layer (layer 7 of OSI Reference Model) associations are bi-lateral. To make communication with occasionally connected end systems more efficient, this system introduces a tri-lateral communication model. We introduce a Status Notification Service that facilitates communication with occasionally connected end systems. The status notification service can contain information regarding the status of OC-ES and can inform the C-ES as soon as the OC-ES becomes reachable. The status notification server can contain information regarding the C-ES's desire to communicate while the OC-ES was unreachable and can inform the OC-ES as soon as it becomes reachable.
The crux of the status notification problem, and of this service, lies in the communication between the C-ES and the OC-ES. If the C-ES is unaware of the availability, location and receptiveness of the OC-ES, it must either wait for a poll from the OC-ES or broadcast the fact that it desires to communicate with the OC-ES. Similarly, if the OC-ES is unaware of the C-ES's desire to communicate with it, it must either poll the C-ES or await a broadcast by the C-ES indicating a desire to communicate with the OC-ES.
However, if a Location & Status Notification Service (LSNS) is available which always knows the current state of the OC-ES, it could be used to enable efficient communication between the C-ES and the OC-ES. Two basic mechanisms to accomplish this are provided by this service. Both of these mechanisms involve the establishment of an association at the application layer between the C-ES and the LSNS. This association provides the means by which the LSNS informs the C-ES about the status of the OC-ES. It likewise provides the means by which the C-ES notifies the LSNS of its desire to communicate with the OC-ES.
Mechanism 1: Whenever the OC-ES changes state, the LSNS notifies the C-ES of this event. A state change could involve the availability of the OC-ES, the ability of the OC-ES to communicate (with the C-ES), etc. Based on its knowledge of the OC-ES (which it receives from the LSNS), the C-ES may initiate, terminate or continue an application layer association with the OC-ES. This mechanism is illustrated in Figure 1, Figure 2, and Figure 4.
Mechanism 2: Whenever the C-ES receives data destined for the OC-ES, it notifies the LSNS of its desire to communicate with the OC-ES. When the OC-ES becomes available, the LSNS notifies it of the C-ES's desire to communicate. The OC-ES then establishes an application layer association with the C-ES for communication. This mechanism is illustrated in Figure 3 and Figure 5.
The Status Notification Service includes the application layer association between the C-ES and the LSNS by which the C-ES is notified of the status of the OC-ES and the desire of the C-ES to communicate with the OC-ES. This service provides the means for efficient communication with occasionally-connected end systems.
Scenario 1: C-ES initiates association with OC-ES when the OC-ES becomes reachable. Figure 2 depicts the relationships between the LSNS, the C-ES and the OC-ES. The line connecting the LSNS and the C-ES represents application layer association between these entities. The dashed line connecting the LSNS and the OC-ES - going through the network which supports the OC-ES - represents communication between these entities. The line connecting the C-ES and the OC-ES represents the application layer association between these entities. It exists for the duration of the data transmission between these devices.
The following time sequence scenario is depicted in Figure 2.
Scenario 2: The OC-ES initiates the association. Refer to Figure 3 which, as in Figure 1.2, depicts the relationships between the LSNS, the C-ES and the OC-ES.
The following time sequence scenario is depicted in Figure 3.
The requirements which must be met by a Status Notification Service include:
Capabilities specifically not included in a Status Notification Service include:
The first mechanism supporting C-ES communication with the OC-ES can be applied to messaging (e.g., email) applications. The steps involved in sending an e-mail message from an originator to a recipient OC-ES via a message-delivery-system (C-ES), are identified in Figure 4.
The following time sequence scenario is depicted in Figure 4.
The second mechanism supporting communication between a C-ES and an OC-ES can also be applied to messaging applications. The steps involved in sending an e-mail message from an originator to a recipient OC-ES, via a mailbox (C-ES), are identified in Figure 5.
The following time sequence scenario is depicted in Figure 5.
Use of the LSNS service generally revolves around the following key concepts:
The specification outlined in this document defines the protocol between the Status Notification Service, the Corresponding End System, and the Occasionally Connected System. The protocol will be based on the Efficient Short Remote Operation Services (see [1]).
This chapter has presented an introduction to the main ideas of status notification. Chapter 2 provides an overview of the LSNS protocol.
Network specific aspects of the protocol are included as attachments to the document.