Status Notification Service Overview

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:

a.

Registration Reporting Protocol (RRP). This could be an Application Programming Interface (API) or a protocol.

b.

Mobile Status Notification Protocol (MSNP). This is an operation oriented protocol which will be connection-less. It can also be used to ask the Status Notification Service to notify the Mobile System about the need to poll the Message Center.

c.

API to provide access to MSNP.

d.

Application Information Notification to the Mobile Protocol (AINMP).

e.

API for (4).

f.

Mobile Network Registration Protocol (MNRP).

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.

  

Figure 6: LSNS Interfaces and Protocols - (b) and (d) are of our interest.

2#2

Elements

Primary elements of the LSNS system are those highlighted in Figure 6. These comprise:

• An Occasionally-Connected End System - also called a Mobile End Systems (M-ES).

• The Network Agent for Location and Status (NALS) , which is the M-ES's anchor in the network and is always aware of M-ES's status. The Status Notification Agent may be realized as a function within the Network Agent for Location and Status real system.
• The Corresponding End System (C-ES), which is a real system capable of supporting Status Notification Service.

Use of ASN.1

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.

LSNS Basic Subprofile

This section defines the "LSNS Basic Subprofile" which is a building block for implementation of Messaging systems that support protocols specified in this specification.

Encoding Rules

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:

1.

PDUs shall be encoded in the fewest number of octets possible, regardless of the encoding rules in use.

2.

Specifically, when ASN.1 Basic Encoding Rules are being used:

3.

Only the "Definite" form of Length encoding shall be used,

4.

The "Short" form of Length encoding shall be used whenever possible (i.e. when the Length is less than 128), and

5.

OCTET STRING and BIT STRING values, and any other native ASN.1 types which may be encoded as either "Primitive" or "Constructed", shall always be encoded as "Primitive" and shall never be "Constructed".

Use of ESROS

Efficient Short Remote Operation (ESRO) Service Access Point Selectors 6, 7, 8, and 9 shall be used by the EMSD-SDP. See [1].

Use of UDP

Port Number 2002 shall be used by the ESRO Protocol.