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).
