This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
This document is being prepared by Neda Communications, Inc. for Xypoint Corporation based on matterial previously prepared by Neda.
This document is mostly complete and is subject to review and criticism.
Features which have not been fully developed and described in this revision of the document include:
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.
An overview of the Status Notification Service for a Wireless Data & Voice network, and the various interface protocols (which make use of ASN.1 and Basic Encoding Rules) are shown in Figure 6. The annotations for Figure 6 are:
This document will focus on the global protocols between the LSNS and the Corresponding and Occasionally Connected End Systems, i.e., protocols (b) and (d) in Figure 6. These protocols will make use of the Efficient Short Remote Operation Services as outlined in [1]. Interfaces (a), (c), and (e), are internal to the LSNS, C-ES, and OC-ES and beyond the scope of the specifications in this document.
Primary elements of the LSNS system are those highlighted in Figure 6. These comprise:
Basic Encoding Rules (BER) [3] provides an encoding mechanism to enable transfer of information expressed in ASN.1. BER uses the Type-Length-Value (TLV) concept for its encoding,
The Packed Encoding Rules (PER) of ASN.1 [X.691] [4] is a recent International Standard. PER is a much more compact set of encoding rules than BER, but the amount of compaction varies based upon the subtype notation. It does simple things such as omitting transmitting tags or transmitting lengths when the length is known not to vary, but it also relies heavily on the subtype notation to achieve maximum compaction. The document number is ITU-T Rec. X.691 | ISO/IEC 8825-2.
ASN.1 is designed to be independent of the specific encoding rules that are in use. A properly designed service which uses BER today can easily convert to using PER in the future without much engineering effort. LSNS protocols which use ASN.1 will initially use Basic Encoding Rules.
This section defines the "LSNS Basic Subprofile" which is a building block for implementation of Messaging systems that support protocols specified in this specification.
Use of Basic Encoding Rules is mandatory for both Format Standards and Submission and Delivery Protocol.
In order to enable the smallest amount of data transfer, the following restrictions shall be maintained in the formatting of PDUs:
Efficient Short Remote Operation (ESRO) Service Access Point Selectors 6, 7, 8, and 9 shall be used by the EMSD-SDP. See [1].
Port Number 2002 shall be used by the ESRO Protocol.
There are two basic categories of users: Corresponding End Systems (C-ESs) and Mobile End Systems (M-ESs).
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 M-ES on behalf of the originating end system (i.e., sender of e-mail). A Corresponding End System uses the LSNS through the protocols specified in [SNS-P]. It invokes the following operations:
and performs the following:
This is an end system that is only occasionally connected. Example is a system that may be down during specified hours, or not have access to the network for any other reason, for instance while being in an airplane (unavailability of service). A Mobile End System uses the LSNS through the protocols specified in [SNS-P], and performs the following operation:
The general aspects of he LSNS Protocols are specified in this section.
Network specific aspects are included as attachments to this specification.
This Specification defines the following services that comprise the Status Notification Service.
A summary of the operations invoked and/or performed by the various entities (C-ES, M-ES, and LSNS), is given in Table 1. This specification expresses information objects using ASN.1 [2] and expresses Remote Operations based on the model of ESROS as specified in [1].
Definition and details of the operations that are invoked by the C-ES are presented below.
The Status Query Operation enables a C-ES to invoke a request to LSNS to inquire about the status of one or more M-ESs.
The successful completion of this operation results in the delivery of status information on one or more M-ESs to the C-ES by the LSNS.
Click here to see the complete codes.
Click here to see the complete codes.
Click here to see the complete codes.
Click here to see the complete codes.
Click here to see the complete codes.
Click here to see the complete codes.
securityError ERROR PARAMETER security-problem SecurityProblem ::= 4; accessControlViolated ERROR PARAMETER NULL ::= 5; insufficientResources ERROR PARAMETER NULL ::= 6; unwillingToPerform ERROR PARAMETER NULL ::= 7; genericError ERROR PARAMETER NULL ::= 8; SecurityProblem ::= INTEGER (0..127);
-- DateTime is a Julian date, expressed as the number of -- seconds since 00:00:00 UTC, January 1, 1970. DateTime ::= INTEGER;
Iso8859String ::= OCTET STRING;
ub-subjects INTEGER ::= 256; ub-durations INTEGER ::= 127; ub-apps INTEGER ::= 16; ub-password-length INTEGER ::= 16
An overview of LSNS is given in Figure 7, which we
will refer to below. Figure 8 presents the
details of this Wireless Data & Voice network and is essentially a more detailed and
less abstract version of Figure 8 (Chapter
![[*]](/latex2html-98.1p1/icons.gif/cross_ref_motif.gif){kind=icon}
). The shaded areas are the focus of this document.
The following functional breakdowns and their respective requirements from Figure 7 are:
The functions of the Network Agent for Location and Status are carried out via a Location Directory. The Location Directory maintains an information base of the current forwarding address for each M-ES in its home area.
A necessary enhancement to the Network Agent for Location and Status is a Notification Request Directory that keeps track of which M-ESs the C-ES seeks information. They can be implemented as an extension to the location directory.
Overall, the Network Agent for Location and Status must be capable of:
The LSNS needs to interact with the Network Agent for Location and Status , C-ESs, M-ESs, and the System Management. With the Network Agent for Location and Status , the LSNS should be able of determining the current location of an M-ES, as well as the list of C-ESs wishing to communicate with an M-ES. With System Management, interaction is as specified above. With the C-ES, the LSNS needs to be capable of providing it with a Status Notification Report on one or more M-ESs. With the M-ES the LSNS needs to be able to relay the desire to communicate of a C-ES to it.
At any given point in time, system management must be aware of, capable of performing, and/or regulating a number of system parameters. These could be the capability of:
System management must interact continuously with the LSNS to furthermore determine
In the specification described in this document, only the Cellular Digital Packet Data (CDPD) network is considered. The Status Notification Service can be easily applied to most other networks that support mobility. The CDPD network supports communication with mobile devices which are only occasionally connected to the network. Referring to Figure 6 the chosen network comprises:
Figure 8 presents the details of this CDPD network and is essentially a more detailed and less abstract version of Figure 6. The interface between the M-ES and Serving MD-IS (A-Interface) is fully specified in the CDPD Specification and requires no modifications to support the Status Notification Service.The interface between the Serving MD-IS and the Network Agent for Location and Status (B-Interface) is also fully defined in the CDPD specification and requires no modifications. The shaded areas and the C- interface are the focus of this document.
Modifications needed by the involved entities are indicated by the shaded areas in Figure 9. A number of new functions need to be added to the Network Agent for Location and Status . They include the "Status Reporting Registration Function", the "Status Notification Function" and the "Status Report Query Function". Several of the existing functions of the Network Agent for Location and Status need to be modified to support the Status Notification Service. In particular, the "Record Location Function" and the "Flush Location Function" need to be enhanced to interact with the new status notification related functions of the Network Agent for Location and Status .
In addition to the functions mentioned above, a new information base which stores requests for status notification need to be added to the Network Agent for Location and Status . This information base is illustrated as the "Notification Request Directory" in Figure 8. Further, the Network Agent for Location and Status's "Location Directory" is used by the Status Notification Service. It is possible to implement the "Notification Request Directory" as an extension of the "Location Directory".
The shaded areas in Figure 9 indicate where software modifications are required for an LSNS implementation. As illustrated in Figure 9 there are no modifications required to the M-ES for a basic implementation of LSNS.
Some M-ESs may implement a system which would require the M-ES to poll a Messaging Server for messages (e.g. IMAP, POP). For these implementations the desireToCommunicate services are included. The shaded areas in Figure 10 illustrate where modifications will be required for an LSNS implementation which includes the desireToCommunicate services.
We provide examples here of the use of statusNotificationRequest and statusNotificationReport operations.
In this example the C-ES is responsible for delivery of messages (e.g., email) to the M-ES as soon as possible and as efficiently as possible. Referring to Figure 11, after accepting responsibility for the delivery of the message (01), the recipient's email address is translated into the M-ES NEI of the recipient (02). If the C-ES has seen recent indications of the M-ES being active (03), then C-ES attempts to deliver the email (04).
If the M-ES is not active (the message delivery was not successful), then the C-ES invokes the "Status Notification Request" remote operation on the Network Agent for Location and Status . This results into the "Status Notification Request Procedure" of the Network Agent for Location and Status performing the procedures described in Figure 12.
Referring to Figure 3.3, the status report registration process inside of the Network Agent for Location and Status appears generally as depicted by reference number 00. To begin the Network Agent for Location and Status accepts the request from the C-ES. (01). Next, the "Notification Registration Directory" is searched for the M-ES's NEI which is the subject of the request (02). If the search is not successful, then an entry is created (03). Then the Corresponding-ES's address is added to the "Requesting System List" of the Notification Registration Directory(04). If the M-ES NEI is in the Network Agent for Location and Status 's Location Directory which means the M-ES is active, then the C-ES is notified of the M-ES's active status. This results into the "Status Notification Report Procedure" of the C-ES performing the procedures described in Figure 15.
When an M-ES becomes active or inactive, the Network Agent for Location and Status may notify the C-ES of those events. The trigger for the "active status" notification process is the "Record Location Function" of the Network Agent for Location and Status which is a result of the Serving MD-IS's "Report Location Function" which follows the M-ES becoming active. The trigger for the "inactive status" notification process is the "Flush Location Function" of the Home MD-IS which is a result of the Serving MD-IS's "Flush Location Function" which follows the M-ES becoming inactive.
Referring to Figure 13, the active status notification process inside of the Network Agent for Location and Status appears generally as depicted by reference number 00. This process is triggered by receiving an RDR-PDU from the Serving MD-IS. First, the ordinary "Record Location Function" of the Network Agent for Location and Status is performed (01). Next, the "Notification Request Directory" is searched for the M-ES's NEI (02). If the search is successful, then the list of C-ESs to notify is obtained (03). Each of the C-ESs are notified (04), (05). This results into the "Status Notification Function" of the C-ES performing the procedures described in Figure 3.6.
Referring to Figure 14, the active status notification process inside of the HOME-MDIS appears generally as depicted by reference number 00. This process is triggered by receiving the RDE-PDU from the Serving MDIS. First, the ordinary "Flush Location Function" of the HOME-MDIS is performed(01). Next, the "Notification Registration Directory" is searched for the M-ES's NEI (02). If the search is successful, then the list of C-ESs to notify is obtained (03). Each of the C-ESs are notified (04), (05).
Referring to Figure 15, the C-ES translates the M-ES NEI into a list of messages that are pending for that M-ES (02). Then it attempts to deliver the messages to the M-ES. Since the M-ES is active, the delivery is likely to be successful. In case of failure, this M-ES's messages get subject to C-ES's retransmission policy (05).
This Section To Be Supplied By Xypoint.
| BER | Basic Encoding Rules |
| C-ES | Corresponding End System |
| CDPD | Cellular Digital Packet Data |
| ESRO | Efficient Short Remote Operation |
| ESROS | Efficient Short Remote Operation Services |
| LAN | Local Area Network |
| LSNS | Location & Status Notification Services |
| M-ES | Mobile End System |
| NALS | Network Agent for Location & Status |
| OC-ES | Occasionally Connected End System |
| PER | Packed Encoding Rules |
| SNS | Status Notification Services |
| TLV | Type-Length-Value |
| WAN | Wide Area Network |