The Service Assurance feature allows an external system to access subscription version data from the LNP databases in the LSMS. This information is useful in verifying correct porting of data, and helps in troubleshooting problems. There is one LNP database for each of the NPACs associated with the LSMS.
The external system uses Service Assurance Manager (SAM) application software to initiate service assurance data requests and associations. Single or multiple SAMs may exist on the external computer system. The SAM communicates with the LSMS through the Service Assurance Agent (SAA) application software that resides in the LSMS. The SAM application software is not Oracle software and is only resident on the external system.
The SAA decodes the queries from the SAM and then accesses the LNP database. The SAA forms the subscription version data into a message and that message is sent to the SAM making the query.
Service Assurance works in conjunction with the Surveillance feature. The Surveillance feature issues the command to start the Service Assurance agent (part of the Service Assurance feature that is described in this document), and it monitors the status of the Service Assurance agent.
A maximum of eight SAM/SAA sessions are allowed at one time.
The architecture used to provide the access is a Connection Oriented Manager/Agent using Common Management Information Protocol (CMIP). CMIP provides an industry standard interface between Manager and Agent applications. This allows you to use standard products and tool kits to develop applications.
Service Assurance Terminology
The following terms are used to describe Service Assurance:
- Service Assurance Manager (SAM): Initiator of service assurance associations and data requests. This is not part of the LSMS application. A SAM application runs on a computer but is not the computer itself. Multiple SAMs can run on the same computer, or each SAM can run on a different computer.
- Service Assurance Agent (SAA): Software residing on the LSMS and considered part of the LSMS application. This software consists of one or more Linux processes and one or more Linux scripts.
- NPAC Database: This refers to the database stored on the NPAC.
- LNP Database: This refers to the database that contains subscriptionVersions, Service Provider Network, Service Provider LRN and Service Provider NPA-NXX objects. This database resides on the LSMS. Each NPAC has one LNP Database on the LSMS.
- Manager/Agent: This term describes the two peer processes that work together to implement the Service Assurance feature. The Manager is the customer’s application, which is used to initiate the association and send the query to the Agent process. The Agent process decodes the query message, then accesses the LNP Database.
The Agent extracts the data from the database, then builds and sends the reply to the Manager. This feature allows the Manager to send a single subscription TN or list of subscription TNs to query. The Agent extracts each instance that it can find from the LNP Database and returns a response to the Manager.
The architecture is connection oriented to restrict access to the LNP databases. This system is assumed to be within the customer’s private network, so no encryption security is included. The CMIP protocol defines the method for establishing and terminating associations. This application uses the access control and user data space in the association messages to restrict access to the system.
The SAM is restricted to querying subscription versions by the subscriptionTN field. Up to four SAMs can query the LSMS at the same time.
The Service Assurance feature interfaces to the LSMS by means of a 10 Mbps Ethernet interface. The Application WAN is also used as the interface for the X-terminals connected to the LSMS. The network connecting the Service Assurance systems to the LSMS is the responsibility of the customer.
Interface Implementation
The LSMS Service Assurance interface is implemented over a standard CMIP/CMISE-based OSI protocol stack (Q.3). RFC1006 is used for the transport layer.
This interface is limited to the retrieve capabilities of the local LSMS database. The object to be retrieved is the subscription Version defined in NPAC SMS Interoperable Interface Specification, NANC Version 1.5, September 1997.
Allowed Functions on the Interface
The LSMS responds to association (bind) requests, release (unbind) requests, aborts, and subscription query (m-get) messages. No other functions are allowed over this interface and will be rejected.
Support of OSI Addresses
The LSMS supports four OSI address connections for Service Assurance interfaces, which correspond to eight domains.
Each Service Assurance system needs to establish only the associations it requires, without regard to whether the LSMS is operating with the primary or secondary server. Upon switchover, the association is momentarily lost. The Service Assurance system tries to reestablish the association. When the active system finishes coming up, it then responds to the Service Assurance system association requests. The Service Assurance system does not know whether the primary or secondary system is running.
Association information is specified by Oracle. This information must be present in the bind request. This data in the association information, such as the system name, is used to verify the source of a bind request. Bind requests with invalid association information are rejected.
Establishment of association between the LSMS and the Service Assurance system is initiated by the Service Assurance Manager. This applies to initial association as well as to reestablishing the association after outages (regardless of the cause of the loss of association). When it does not have an association, the Service Assurance system periodically tries to establish the association until a successful response is received from the LSMS. The minimum retry interval is one minute.
The LSMS provides a response to the bind request to indicate:
- Successful connection
- Access control failure (authority violation - unknown address requesting association)
- LSMS data access failure
- Resource failure (maximum number of associations already established)
Number of Associations Per Service Assurance System
The LSMS supports one association per Service Assurance system.
If a Service Assurance agent within the LSMS is unable to establish a connection with the LSMS NPAC database, the association with the Service Assurance system is aborted.
Notification Upon Loss of Association
The LSMS provides a notification when the association with any of the Service Assurance Manager is lost or established.