This chapter discusses the basic tasks you can perform using Oracle Number Portability, and the distinct regions in the application. The chapter covers the following topics:
This chapter covers the following topics:
At the core of Oracle Number Portability is the Number Portability Center that provides Customer Care Administrators with instant access to number porting information. A number of tabs accessible from the Number Portability Center present information about porting orders and their status, and the network elements associated with orders. Buttons in the Number Portability Center allow you to view details about service providers or mediators, and to view notifications, if any, related to an order.
To access the Number Portability Center:
Log-in to Oracle Applications.
Select the NP Administrator responsibility. The NP System Administrator Navigator window appears.
Use the following navigation path to open the Number Portability Center window:
Functions > Operations > NP Center.
The Number Portability Center comprises a left Subscriptions list region, and a right tabs region. The Customer Care Administrator can view details pertaining to an order, using the different tabs in the Number Portability Center.
Related Topics
Tabs in the Number Portability Center
Buttons in the Number Portability Center
In the Number Portability Center, you can view both order information, and network element information associated with an order by choosing the corresponding tab on the left, under the subscription list region.
Orders tab allows you to view detailed information about an order that you select from the Subscriptions list.
Network tab allows you to view details of network elements associated with an order you select from the Subscriptions list.
The Number Portability center also includes the Filters tab.
Filters tab enables you to enter number filters for the service provider. A filter is the list of telephone number ranges in which a service provider is interested. You enter this information to create filters so that a Number Registration Center can broadcast your subscription version information selectively.
When you select the Orders tab to view order information, the Number Portability Center displays the following tabs:
| Tab | Description |
|---|---|
| Summary |
|
| Features | The Features tab is not available unless special features have been defined for this order. To enable features, set profile option ENABLE_FEATURES to Y (Yes). |
| Transaction Log |
|
| Work Items |
|
| Failed Downloads |
|
| Others |
|
When you select the Network tab to view network element details associated with an order, the Number Portability Center displays the following tabs:
| Tab | Description |
|---|---|
| Summary |
|
| Features | The Features tab will not be available unless special features have been defined for this order. To enable features, set profile option ENABLE_FEATURES to Y (Yes). |
| Work Items |
|
| Provisioning Map |
|
The following buttons are available in the Number Portability Center:
Notifications button launches the Notification Inbox, where you can view notification messages relating to an order. You can choose to view all messages, or only messages in the Open status.
Details button allows you to view details relating to the section in the Number Portability Center window to which the Details button belongs. For example, the Details button in the Recipient Service Provider section of the Summary Screen for Orders will open the Service Providers window, where you can view details about the service provider related to the order you selected from the Subscriptions list.
Number portability is a mechanism by which consumers can keep their telephone numbers when they switch between telecommunication service providers, move from one physical location to another, or change their services.
The concept is driven by regulatory authorities working to jump start competition, citing that consumers are more interested in moving between service providers when they can keep their telephone numbers. Number Portability is widely cited as a key driver for the explosive growth in the competitive long distance market. In order to nurture competition, legislative and regulatory bodies around the world have started to issue number portability mandates. Today, number portability is generally required for circuit switched products and services only and is implemented in the United States and a few other countries.
Number portability can be realized using several methods. The different methods fall into two main categories: Intelligent Network (IN) based, or Non-IN based number portability solutions. A well known IN based number portability solution is the Location Routing Number (LRN) solution adapted in the US. Several non-IN based solutions are available: Call Forwarding, Flexible Numbering Register (FNR) solution under consideration for adoption in Europe.
Location Routing Number is a ten digit number which uniquely identifies a switch in a service provider network. Before number portability was mandated, telephone number ranges were assigned to switches, which did not change, so having the telephone number was sufficient to route the call (except toll free numbers). With number portability, LRN is the new switch identifier that is needed to route the call.
The routing number is mapped to the new telecommunication switching system on the one end, and linked to the customer’s current dialing number on the other end. Each service provider allocates certain numbers as routing numbers for number portability. Every service provider using Oracle Number Portability has a routing number repository for this purpose. The numbers are located in the service provider’s local database for purposes of executing the porting, as well as in the central databases maintained by national or regional number centers. These are known as Number Registration Centers (NRC) in the United States, S-NPAC (Number Portability Administration Center) in Sweden, and CRDC in Belgium.
| Type | Description |
|---|---|
| Service Provider Portability | The ability of end users to retain the same telephone numbers as they change from one service provider to another. For example, Dr. Jon Smith moves local telephone service for his office from Euro Telecom to the new emerging carrier SuperTel. The physical location of Dr. Smith’s office has not changed. |
| Location Portability | The ability to retain existing telecommunication numbers without impairment of quality, reliability, or convenience when moving from one physical location to another. For example, Dr. Jon Smith moves his office from Brussels to Gothemburg and retains his existing telecommunications numbers with SuperTel. |
| Service Portability | The ability to retain existing telecommunication numbers without impairment of quality, reliability, or convenience when switching from one telecommunications service to another telecommunication service provided by the same service provider. For example, Dr. Jon Smith moves a subset of the telecommunications numbers for his office from wireline service to wireless service with SuperTel. When signing up for wireless service, he retains the existing telecommunications numbers with the same set of features that he had with wireline service. |
In order to provide number portability from one service provider to another, each of the service providers must be set up in Oracle Number Portability. This information is used by the Service Order Administrator and the Service Management System to create and activate service orders as they are received. The precise tasks that you perform for a service provider depends on the how you want to install Oracle Number Portability. The application usage types are as follows:
| Type | Description |
|---|---|
| Individual Service Provider | You must set up the following: Full information for yourself Basic information for all other service providers with whom you expect to interact |
| Number Registration Center | You must set up the following: Full information for yourself Information for all service providers in your region |
You can perform a number of order activities in Oracle Number Portability. The following are examples of order activity types you can perform using the Oracle Number Portability:
| Type | Description |
|---|---|
| Port In | A port in request is usually initiated at the recipient service provider side by a new customer requesting that you provide a port in capability. |
| Port Out | A port out request can occur in two ways: Triggered internally at the donor service provider side based on the same customer contact as at the recipient side A customer contacts the donor service provider directly in order to initiate a port out request to another service provider |
Note: The application provides standard activities for you to build business processes of each order type. These order types are not seeded in the application.
Oracle Number Portability contains four porting phases:
A customer calls the new service provider and inquires as to the feasibility of porting his/her number.
Note that it is possible for multiple porting inquiry requests to be placed for the same telephone number at the same time.
For example, Dr. John Smith may call three new service providers to ask what the rates would be if he ported his number.
A customer calls and requests service from a new service provider, and asks to port his/her telephone number from the old service provider. The porting phase changes to Ordering after the feasibility of porting the required number is established in the Inquiry phase. The donor service provider agrees with the recipient service provider on the number porting.
Only a single porting order request can be placed for a telephone number at any given time.
For example, Dr. John Smith can only select one service provider to port his number.
A customer’s telephone number is currently active in the network with the new service provider.
Note that the Active phase should not be confused with the Active flag. The Active flag is defined for each porting status to indicate whether the porting status is a valid value that can be used by the application.
A customer switches to another service provider, disconnects, or cancels the porting request. It is suggested that after a specified time period, porting requests in the Old phase should be archived or purged.
The service order phase in the number porting process most often (not always) determines the tasks that you perform against a service order.
For example:
You perform the tasks associated with entering orders in the Ordering phase of number porting.
You perform monitoring, number range maintenance, and their component tasks in any phase of a number porting process.
Porting statuses are used to track the progress of a porting request. A service order may have more than one status throughout its life cycle. You can define a new status through Oracle Number Portability for either of the following reasons:
To better reflect the terminology and business processes of your organization
To understand the progression of a porting request
After a status is defined, you can reference it in Workflow and process logic. This is where status manipulation occurs.
Key Components of a Porting Status Definition
In Oracle Number Portability, each porting status is user-definable. It must also be associated with one of the pre-defined phases of a porting request (see Porting Phases in Oracle Number Portability). User-defined porting statuses provide flexibility to users (for example, naming conventions are different for each country). Associating a porting status with a pre-defined porting phase allows applications to categorize porting statuses, adding to the manageability of porting requests.
In effect, porting statuses enable you to more closely map your business processes to the progress of a service order, than is possible with only the four phases.
Workflows in Oracle Number Portability are sub-processes which execute during the order fulfillment process. Workflows are used to automate the business processes necessary to fulfill the order. Work items perform the business and network functions necessary to fulfill a service order request. In the application, each work item typically maps to a single workflow, due to the complexity of the business process. This is why workflows are referred to as work items in Oracle Number Portability. Workflows are created using the Oracle Workflow Builder.
The Oracle Workflow Builder enables your organization to customize Oracle Number Portability to suit your business needs. Through workflow, you can route any type of information in an asynchronous manner, according to business rules.
Within the Oracle Workflow Builder, you can create, view, or modify a business process with simple drag and drop operations. In addition, you can create and modify all workflow objects, including activities, item types, processes and notifications.
At any time, you can perform the following operations on workflow objects:
Add
Remove
Modify
Set up new prerequisite relationships among the various item types
You can easily work with a summary-level model of your workflow, expanding activities within the workflow as needed, to greater levels of detail.
You configure an adapter to interact with the external system, and to route messages to and from the external system appropriately. You configure an adapter by specifying its attributes.
Oracle Number Portability comes with the file adapter defined. This adapter enables messages to be passed to local files, or sent to a remote location using the provided FTP client. For more information on adapters, refer to the Oracle Service Fulfillment Manager documentation.
Oracle Number Portability uses messages to communicate with external systems and initiate new orders in Oracle Service Fulfillment Manager. For example, Oracle Number Portability sends an outgoing message requesting a number port with the Central System. The Oracle Number Portability workflow then waits for an inbound message that confirms the request to port. This use of messaging integrates the use of workflows with external conditional elements. Messages can trigger a process, or set of processes in an application. Applications send and receive messages asynchronously using the Event Manager.
Messages are used to communicate between applications and systems. Oracle Service Fulfillment Manager messages are defined in the industry-standard XML format.
When a message is compiled, the following functions are created:
Send()
Publish()
Validate()
Process()
Default_Process()
Create_Msg()
These functions are used to communicate with the Number Registration Center and other service providers, as well as with any other external system or internal Operational Support Systems. Also, messages can trigger a set of processes internally within the system.
You define messages in either of the following ways:
You can select from a set of predefined and available messages that are preseeded in Oracle Number Portability.
You can build and define any required messages through the iMessage Studio.
A message comprises one or more message elements. A message element consists of a set of attributes:
Type
Name
Length
Datatype
For example, area may be a message element composed of length and width. The message element name is used as a tag within the XML message. Each message element has a data source which must be defined.
The iMessage Studio is a tool used for developing message-based Service Fulfillment applications. It enables you to perform the following functions:
Develop a message-based application, while generating the code to construct, publish, validate, and process application messages.
Compile and test these messages.
Share messages between applications, allowing for their re-use in various applications.
Prevent redefining the same message in various applications across the enterprise.
Generate procedures through its APIs and its run-time messages.
Customize pre-processing of outbound messages and the post-processing of incoming messages from the Event Manager to external subscribers.
Define a message set for a particular event during processing of an order within the application.
Construct timers (delayed messages) for use within the application.
Define messages in the XML industry-standard format.
Create a series of message processes to communicate with external systems, Service Providers, and internal Operational Support Systems.
Incoming messages and events are handled by the Event Manager in Oracle SDP Number Portability. There are four possible ways that a message can be processed by the application.
They are:
Default process logic
Validate logic
Incoming Message process logic
Outgoing Message process logic
Following is a brief description of each type.
Note: If the user does not provide any message processing logic, the default is a NULL package body.
If no application has registered for the message, the Event Manager automatically executes the default processing logic DEFAULT_PROCESS() for that message.
The following example shows how to provide an application hook using the DEFAULT_PROCESS() procedure. Consider a case in which a PORTING_CONCUR message comes in asynchronously.
The default processing logic for this message is:
DECLARE
l_telephone_num
VARCHAR2(10) ;
l_clli
VARCHAR2(20) ;
l_area_code
VARCHAR2(3)
;BEGIN
/* Reset error code and error message */
x_error_code := 0 ;
x_error_message := NULL ;
/*Retrieve the Telephone number message element from the XML message
*/
XNP_XML_UTILS.DECODE( p_msg_text,
’TELEPHONEí’,
l_telephone_num) ;
/*
Retrieve the central office or the CLLI on which it has to be provisioned
*/
XNP_XML_UTILS.DECODE( p_msg_text,
’CLLI’,
l_clli) ;
/*
Ensure that the right central office is used for provisioning
*/
l_area_code := SUBSTR(l_telephone_num,1,3 ) ;
IF ((l_area_code = ë415í) AND
(l_clli = ëSFOí)) THEN
/* Customized procedure to provision the number */
/* Not part of NP core functions */
PROVISION.ADD(l_telephone_num) ;
ELSE/*
Customized procedure to notify the customer care system. Not part of NP
core functions
*/
NOTIFY_CUSTOMER_CARE(l_tn,
x_error_code,
x_error_message) ;
END IF ;
END ;
The VALIDATE() procedure provides a hook to include business specific validation and is automatically executed by the Event Manager on newly arrived messages.
If no validation logic is specified, the procedure is created with a "NULL;" statement. The signature for this procedure is given in the following code.
Note: The Event Manager will not process and deliver the message in case an error is returned in X_ERROR_CODE or X_ ERROR_MESSAGE.
However the resulting error code and error message is logged into the system log messages.
VALIDATE( p_msg_header IN XNP_MESSAGE.MSG_HEADER_REC_TYPE, p_msg_text IN VARCHAR2, x_error_code OUT NUMBER, x_error_message OUT VARCHAR2, p_process_reference IN VARCHAR2 DEFAULT NULL ) ;
The following is an example of code that checks for a valid telephone number. (The use of XNP_XML_UTILS.DECODE works only in case of messages with no repeating elements.)
DECLARE
l_telephone_num VARCHAR2(10) ;
l_service_provider VARCHAR2(10) ;
BEGIN
/* Reset error code and error message */
x_error_code := 0 ;
x_error_message := NULL ;
/* Retrieve the telephone number */
XNP_XML_UTILS.DECODE( p_msg_text,
’TELEPHONE’ ,
l_telephone_num ) ;
/* Retrieve the service provider */
XNP_XML_UTILS.DECODE( p_msg_text,
’SERVICE_PROVIDER’ ,
l_service_provider ) ;
/*Custom procedure to check if the telephone number is in the service
providerís defined number range
*/
TN_RANGE.CHECK_SP_VALIDITY( l_telephone_num,
l_service_provider,
x_error_code,
x_error_message ) ;
END ;
The PROCESS() procedure also provides a hook to include the application logic and is executed by the Event manager before delivering the message to the callback procedure of the registered application.
The following example code stores the PORTING_ID from an NPR_ACK for the recipient.
DECLARE
l_REFERENCE_ID VARCHAR2(40) := NULL;
l_porting_id VARCHAR2(40);
BEGIN
x_ERROR_CODE := 0;
/* Get the OPP_REFERENCE_ID as in the received message which is the workitem instance id.
*/
XNP_XML_UTILS.DECODE
(p_msg_text
, ’OPP_REFERENCE_ID’
, l_REFERENCE_ID
) ;
-- Get the NPR PORTING_ID
XNP_XML_UTILS.DECODE
(p_msg_text
, ’PORTING_ID’
, l_porting_id
) ;
XDP_ENGINE.SET_WORKITEM_PARAM_VALUE
(to_number(l_REFERENCE_ID)
,’PORTING_ID’
,l_porting_id
,NULL);
/* Set the reference to communicate with Number Registration Center, is the
PORTING_ID
*/
XDP_ENGINE.SET_WORKITEM_PARAM_VALUE
(to_number(l_REFERENCE_ID)
,’OPP_REFERENCE_ID’
,l_porting_id
,NULL
);
END;
The out process logic is executed before enqueueing the message for delivery No procedure is generated but the defined code is executed as part of the SEND() procedure Logging an out going message can be a good use of this hook.
The following example code copies a message from the outbound to the inbound queue.
BEGIN DECLARE my_header XNP_MESSAGE.MSG_HEADER_REC_TYPE ; my_xml VARCHAR2(4000); BEGIN my_header := l_msg_header ; my_xml := l_msg_text ; XNP_MESSAGE.GET_SEQUENCE(my_header.message_id) ; my_header.direction_indr := ’I’ ; XNP_MESSAGE.PUSH(p_msg_header=>my_header, p_body_text => my_xml, p_queue_name=>XNP_EVENT.C_INBOUND_MSG_Q, p_correlation_id=>’MSG_SERVER’) ; END; END;
You use the iMessage Studio to create the following message-based items:
Messages
Events
Timers
The following are the message-based items with their descriptions:
Messages
A sequence of text characters that are used for communication between application systems. Messages fall into two categories:
Messages for internal applications
Internal applications can register a PL/SQL callback procedure via the Event Publisher, or through an API.
Messages for external applications
External applications do not register callback procedures, but have adapters running to relay the published event to the remote system.
External applications can register for an event using the default subscribers screen.
Oracle Number Portability explicitly supports only the XML format.
Events
Messages that are sent to external systems and that are received from external systems. Events are published to both external and internal applications.
Timers
Messages that have a time delay and a duration interval associated with them.
Within Oracle Number Portability, you can set applications to be default subscribers to messages. This is configured in the iMessage Subscribers utility. You can also associate default subscribers with events. For example, when a message occurs, the Event Manager ensures that an outbound message is automatically sent to the subscriber identified by a fulfillment element.
If desired, you can associate one or more responses with an event. A response is an acknowledgment to a message.
For example, valid message responses for the message "Is this an existing customer?" are:
"Yes, this is an existing customer."
"No, this is not an existing customer."
These responses are messages in themselves, and must be configured in the application before they can be linked as responses to a message.
A variety of APIs available in Oracle Service Fulfillment Manager facilitate custom subscription, de-subscription, enqueueing and dequeueing. Consult the Oracle Developing XML-based Message Based Applications Reference Guide for a detailed definition of the available API calls.
The Event Manager handles all messages entering the application system. Incoming messages are one of the following types:
Request messages
Responses to request messages
Event notifications from remote systems
Remote applications send request messages and register for response messages with the Event Manager. The remote applications use an Oracle Number Portability API to register for messages.
When a message arrives, the Event Manager delivers the message to all registered applications after executing the validation and processing logic defined for the message. If no application has registered for a message, the application’s default processing logic for that message is executed after message validation.
For more information on how the Event Manager processes messages, refer to the Oracle Service Fulfillment Manager documentation.
Timers in Oracle Service Fulfillment Manger, on which Oracle Number Portability depends, are used to handle events or processes that must occur at specified time intervals within the application.
In general, timers are used in either one of two ways:
To perform a task once, after a delay
To perform a task repeatedly, after a delay
For more information on timers in service fulfillment, refer to Oracle Service Fulfillment Manager documentation.
Note: Oracle Service Fulfillment Manager timers use the Oracle Advanced Queue to perform queue operations. See the Oracle Advanced Queue documentation set for more information.
After a timer expires, the message to which it is linked becomes visible in the Oracle Advanced Queue, and the message is published to its subscribers. This message can be used for a number of purposes, including the following:
To notify the appropriate personnel to take any necessary action to resolve the jeopardy condition
To initiate action within a workflow to manage the situation
You can configure these kinds of jeopardy management procedures.
Jeopardy notifications provide messages to Oracle Service Fulfillment Manager users if either of the following occurs:
A transaction becomes overdue
A transaction may miss its assigned completion date
For more information on jeopardy notifications and configuring a jeopardy timer, refer to Oracle Service Fulfillment Manager documentation.
Geographic areas are used in Oracle Number Portability for the following purposes:
To identify the areas covered by a Number Registration Center. The application uses this information to determine the Number Registration Center to which a message needs to be sent.
To identify the areas covered by a number range. The geographic area of a number range can be sent to the Number Registration Center whenever a port order is submitted.
To identify the areas that correspond to a routing number.
To identify the areas covered by a Service Provider.
You can create new geographic areas or modify an existing area to meet your business needs. Each geographic area contains the following items:
Area type Geographic area types are user-defined. You must define the area type before beginning to define the geographic area. The application comes with some types already pre-defined.
Code The code for a geographic area can be defined by a publicly available directory.
Name The name of the geographic area describes the physical area involved. For example, the name of a city or a region.
Note: In defining a geographic area, you can specify that other geographic areas are its children. Thus, if you want to create a hierarchy of geographic areas, then you do this by building the hierarchy from the top downwards starting with the largest geographic areas.
Subscription versions are used to maintain the status of porting requests across orders. Following are the two types of subscription versions:
Order Subscription Version: Typically created by the recipient service provider, donor service provider, and central system during the Service Order Administration phase of the porting process.
See Order Subscription Versions.
Network Subscription Versions: Typically created by the recipient service provider, donor service provider, and central system during the Service Management System phase of the porting process.
See Network Subscription Versions.
The key components of an Order Subscription Version differ from the key components of a Network Subscription Version.
| Component | Order Subscription | Network Subscription |
|---|---|---|
| Phase Indicator | Yes | No |
| Telephone Number | Yes | Yes |
| Routing Number | Yes | Yes |
| Status | Yes | No |
| Porting ID | Yes | Yes |
| Customer | Yes | No |
| Change Cause Code | Yes | No |
| Recipient Service Provider | Yes | No |
| Recipient Service Provider Due Date | Yes | No |
| Donor Service Provider | Yes | No |
| Donor Service Provider Due Date | Yes | No |
| Mediator Service Provider (example, Central System) | Yes | Yes |
| Provisioning Map and Provisioning Status | No | Yes |
Oracle Number Portability creates a subscription version for each telephone number. For example, if a range of telephone numbers is ported such as 1234567 through 1234569, the application creates three individual subscription versions, one for each ported number.
In general:
Participants typically do not have an Order Subscription Version for a given telephone number.
Donor and Recipient Service Providers typically have both an Order Subscription Version and a Network Subscription Version for a given telephone number.
Central Systems typically have only Order Subscription Versions.
An order subscription version is typically created by the recipient service provider, donor service provider, and central system during the Initiation phase of the porting process.
After a customer calls a new service provider to request service for his/her existing telephone number, the following events generally occur:
The recipient service provider creates an order with a porting request for the customer’s telephone number.
This order is passed from the ordering system to the Service Delivery Platform.
The Service Delivery Platform recognizes the porting request on a specific line item of the order and triggers Oracle SDP Number Portability.
ONP executes the customized business process for a port-in request and creates a porting order called an Order Subscription Version.
The recipient operator also sends an outgoing message to notify the central system about the porting request.
The Order Subscription Version is used by the recipient service provider to maintain status of the porting request throughout its life cycle.
When the central system receives an incoming message from the recipient operator for a new porting request, the following events generally occur:
The central system creates a porting order called an Order Subscription Version.
The central system also sends an outgoing message to notify the donor service provider about the porting request.
The Order Subscription Version is used by the central system to maintain status of the porting request throughout its life cycle.
When the donor service provider receives an incoming message from the central system for a port-out request for its existing telephone number(s), the donor service provider creates a porting order called an Order Subscription Version. The Order Subscription Version is used by the donor service provider to maintain status of the porting request throughout its life cycle.
The Order Subscription Version for the recipient operator, donor operator and central system is identified by a single porting identifier, the Porting ID number.
This Porting ID is typically assigned by the central system.
After assigning a Porting ID, the central system notifies both the recipient operator and the donor operator of the porting ID through messaging.
A porting ID can reference multiple Subscription Versions. The application does not require a unique porting ID for Subscription Versions.
A network subscription version is typically created by the recipient service provider, donor service provider and participant service providers during the Activation phase of the porting process.
After a porting request is received, the following events generally occur:
Prior to the due date of a porting request, the recipient operator must usually make changes to its network to activate service for the new customer.
At this time, the recipient operator creates a Network Subscription Version using the same Porting ID as the one used to create the Order Subscription Version.
The Network Subscription Version is now used to maintain details and status of each network element that has been updated and the number portability data used to update each network element.
After a porting request is received, the following events generally occur:
Prior to the due date of a porting request, the donor operator must also make changes to its network to de-activate service for the new customer, and transfer all incoming calls to the recipient service provider’s network.
At this time, the donor operator creates a Network Subscription Version using the same Porting ID as the one used to create the Order Subscription Version.
The Network Subscription Version is now used to maintain details and status of each network element that has been updated and the number portability data used to update each network element.
After a porting request is received, the following events generally occur:
On the due date or within a specified time period after the porting due date, the participant service providers epochally receives a broadcast from the central system.
The purpose of the broadcast is to notify all participant service providers that are affected by the customers port to make the necessary changes to their network elements so that all incoming calls to the customer are now delivered to the new service provider instead of the old service provider.
For example, this broadcast message can contain the Porting ID of the Order Subscription Version created by the central system during the Service Management System phase of the porting process.
At this time, the participant service providers create a Network Subscription Version using the Porting ID received in the broadcast.
The Network Subscription Version is now used to maintain details and status of each network element that has been updated and the number portability data used to update each network element.
The Network Subscription Version for the recipient operator, donor operator and participant service providers is uniquely identified by a single porting identifier.
This Porting ID is typically the same Porting ID that was assigned by the central system to uniquely identify the corresponding Order Subscription Version.