NANC 252

Improved Notification Process for LTI Users

Origination Date :12/23/1998

Originator:MetroNet

Description:

The current notification process for LTI users in the NPAC SMS has three significant shortcomings, two of which preclude the LTI’s usefulness in a Service Provider’s environment.  These are as follows:

  1. the same notification may be returned over several pollings, and there is no easy way of recognizing notifications that have already been read;
  2. there is an arbitrary and rather low limit (currently 100) to the number of notifications that the NPAC SMS provides to the LTI server during a polling interval, and any additional notifications during the interval are lost;
  3. polling by the NPAC SMS is carried out on a scheduled rather than a demand basis, and is done whether it is required or not.

The first two shortcomings undermine the viability of the LTI as a production environment tool.  The third shortcoming wastes NPAC SMS resources. 

Final Resolution:

Pure Backwards Compatible:  YES

 

It is proposed that regularly scheduled polling of notifications by the NPAC SMS, for all SPIDs, whether required or not, be abandoned.  In place of this it is proposed that LTI users be able to query the notification data in the NPAC SMS directly, on demand.

 

The new functionality would provide LTI users with a query screen.  This screen would allow users to query for notifications addressed to their SPID.  Time range and number of records tunables would be required to manage the volume of data returned, as well as the impact on NPAC SMS resources.  The screen would contain an active button, labeled “more”, if one or more unread notifications remained beyond the limits set by the tunables.

 

Once the results of the query had been presented to the user, the user would have the ability to mark the notifications as “read”.  Conversely, the user would have the ability to leave the notifications as “unread”, and this would be the default state.

In responding to a query, notifications marked “read” would not be returned by the NPAC SMS.  This would eliminate the need to generate and send useless data, as is currently the case.

 

Jan LNPAWG (Atlanta), group O.K. with this change order.  Move to accepted list.  Will flush out specific requirements when this change order gets placed into a specific NPAC release.

Related Release:

2.0.2

Status: Implemented