System Components

NOAMP Server

The system is comprised of several components:

The NOAMP (Network Operation, Administration, Maintenance, & Provisioning) servers provide OAM interface for UDR and hosts following applications:

• Subscriber Entity Configuration (SEC) Application and database
• Provisioning Front End Interface Application (one per interface type, e.g., REST or SOAP-XML)
• Provisioning Back End (BE) Application (maintains the Indexing System DB and modifies Entities based on Provisioning commands)
• UDR Application which manages Subscription Data Objects (SDOs) and Subscription Notification Objects (SNOs).
• Indexing System
• Subscriber Database

Subscriber Entity Configuration

Subscriber Entity Configuration (SEC) allows the operator to define, via the GUI, the names and characteristics of the data blobs that will be stored in the User Data Repository (UDR) as contents of a Subscription Data Object (SDO) register.

• Assign Names: e.g. Profile, PoolProfile, Quota, PoolQuota, State, etc.
• Assign basic attributes: e.g. opaque/transparent
• Assign transparent attributes: e.g. base-field-sets, field-sets, fields
• Add new fields and field-sets as a new version of an existing subscription entity.
• SEC determines which SDO register stores which subscription entity. (Register Map)
• SEC data is replicated from the active NOAMP to all OAMs and MPs.
• SEC also associates interface-specific message parameters with subscription entity managed objects. (Interface Entity Map)

Provisioning Front End (FE) Application(s)

The provisioning front ends are the processes interfacing to the provisioning clients (External provisioning systems are supplied and maintained by the network operator) and they run on the active NOAMP server.

Provisioning Clients will connect to Provisioning Front Ends to add, change, delete or retrieve subscriber/pool information in the ESPR database.

UDR Back End (UDRBE) Interface

The UDR Back End provides the back end application for the consolidated database for subscriber and profile data.

• Hosted on the active NOAMP
• Constitutes of ProvBe, Subscription, Notification Manager and UdrbeApp Tasks
• Processes Internal Requests from the Provisioning Front Ends.
• Subscription handling/Notification generation
• Receives Auto-enrollment requests from the UDR Application
• Modifies Subscriber data based on Provisioning commands (ProvBE)
• Modifies Subscriber data based on Sh Indications (SPRBE)

Indexing System

The Indexing system provides a means for the Provisioning Back End application on the NOAMP to manage Subscription Relationships and locate Subscription data that applies to a given request. The Indexing System stores User Identities, Identity Relationships, and Subscription Relationships. The Indexing System is updated (creates, deletes, changes) after a command is received on the Provisioning Front End Interface and forwarded to the Provisioning Back End. An Indexing System update applies to either one Individual Subscription or one Pool Subscription.

The Indexing System DB:

• is A-source data
• is replicated only to NOAMP Servers
• is synchronized to disk
• stores user identities, identity relationships and subscription relationships
• Normally maintained by provisioning or by network traffic (For example, auto enrollment in UDR)

The Indexing System provides provisioning and network clients the ability to:

• Lookup an individual subscription giving a user identity
• Lookup a pool subscription given a pool identity
• Lookup a pool subscription given an individual subscription
• Lookup members of a pool given a pool subscription

User Data Repository

The NOAMP Hosts the UDR, which stores Subscription Data Objects (SDOs) that contain the entities (XML Blobs) such as profile, state and quota associated with subscribers and pools. UDR stores Subscription Notification Objects (SNOs), which record application servers that need to be notified when an entity changes.

An Individual Subscription is all data associated with a particular network user that cannot be shared by multiple network users.

A Pool Subscription is all data associated with a particular group of network users and that is shared by all members of the group. Individual and Pool Subscription Data Objects (SDOs) contain entities (XML blobs such as profile, state and quota).

A Subscription Notification Object (SNO) contains a list of network clients that have requested to be notified when entity data for a subscriber is changed.

For UDR data:

• The data is A-source data.
• The active NOAMP masters the UDR DB and makes it durable by synchronizing the database to disk, and by replicating the database to the standby NOAMP and the active DR NOAMP.
• The active DR NOAMP replicates the UDR data to the standby DR NOAMP.
• The data is not replicated to the MPs or SOAMs.

The active NOAMP masters the database and makes it durable by synchronizing the database to disk and replicating the database to the standby NOAMP and to the spare-active DR NOAMP. The spare-active DR NOAM&P replicates this data to the spare-standby DR NOAMP. The data is not replicated to the MPs.

Disaster Recovery (DR) NOAMP

The Disaster Recovery (DR) Provisioning Site is another UDR Provisioning Site. It is recommended to use a geo-redundant DR Provisioning site; however, having a DR Provisioning Site is not required. The DR Provisioning Site is similar to the Primary Provisioning Site. The DR Provisioning Site has the same hardware configuration and network accessibility as the Primary Provisioning Site. The Primary and DR Provisioning Sites have a different VIP for their Active UDR Servers.

The DR Provisioning Site's databases are kept up to date through real-time replication of subscriber and application data from the Primary Provisioning Site's Active UDR Server. Under normal operating conditions, the DR Active UDR Server does not have an active provisioning front end, active provisioning backend and active UDR application backend. When the Primary Provisioning Site's Active and Standby UDR Server fails, the system automatically fails over from the Primary Provisioning Site's Active UDR Server to the Disaster Recovery Provisioning Site's Active UDR Server. After the Disaster Recovery Provisioning Site becomes active, it shall take over all the functions of the Primary Provisioning Site's Active UDR server including the provisioning/signaling connections and database replication to subtending SOAMs.

SOAM

The primary purpose of the SOAM (System Operation, Administration, and Maintenance server) is to become the single point of entry for the replication stream of subscriber entity configuration data into a UDR Signaling Site. The SOAM is the combination of an active and a standby server running the SOAM application and operating in a high availability configuration. The active SOAM Server receives subscriber entity configuration data replicated from the Primary Provisioning Site's Active UDR Server. In turn replicates the data to the Standby SOAM Server and to all subtending MPs located in the same site level. The user can configure/view Provisioning Options, Provisioning Connections, Subscribing Client permissions, Subscriber Entities, Transparent Entities, Interface Entity Map, Diameter information, alarms and measurements using a GUI connected to the SOAM's VIP address.

MP

MPs provide a scalable signaling interface. All MPs are active. The functions of MP are listed below:

• Hosts the Client-side of the Network Application (PNRs host the server side as well)
• Hosts the Network Stack. For example: Diameter, SOAP, LDAP, SIP, SS7
• Connects to the signaling network

MPs that provide the Diameter Sh application use the Diameter Plug-In (DPI), which is the same Diameter stack used by Diameter Signaling Router (DSR). The Sh Application integrates as part of the Diameter Application Layer (DAL).