Contents
1 Introduction
The purpose of this document is to give an overview of Ericsson Dynamic Activation (EDA) product and its features. The purpose is also to provide the entry to the further Customer Product Information (CPI) on each particular feature and function.
1.1 Target Group
The target group for this document is all users of the Dynamic Activation.
For more information about different target groups, refer to Library Overview, Reference [1].
1.2 Typographic Conventions
Typographic conventions are described in the document Library Overview, Reference [1].
For information about abbreviations and terms used throughout this document, refer to Glossary of Terms and Acronyms, Reference [2].
2 Dynamic Activation Overview
Dynamic Activation is the central link between the Business Support System (BSS)7Operations Support System (OSS) layer and network of wireless and wireline. The product gives operators a competitive edge by enabling rapid launch and activation of new end-user services and enterprise services regardless of technology or vendors.
The term Resource Activation refers to the activation of subscribers for services, such as 2G/3G voice & data, LTE, IMS/VoLTE, IPTV, and other applications.
The term Resource Configuration refers to the configuration of wireline services, such as residential broadband, optical network.
Dynamic Activation functionality covers various provisioning implementations horizontal including design, execution, and assurance and E2E solution verticals stretching from user experience to technical implementations.
Dynamic Activation is modulated in different dimensions, which make it possible to tailor a solution based on specific provisioning needs.
The key provisioning strategies within Dynamic Activation are described in the coming sections.
2.1 Mediation
Dynamic Activation provides the following mediation functions in the provisioning process.
2.1.1 Handling of Customer Service Orders
A common function of Dynamic Activation is to handle Customer Service Orders (CSOs) throughout the provisioning process. The following functions are supported:
- Provide a single point of entry for provisioning towards wireless and wireline network and applications and database.
- Manage CSOs, and break them down to internal tasks and external Network Service Orders (NSOs).
- Routing of NSOs to network elements or other Dynamic Activation systems (distributed deployment).
- Manage execution, retry, and rollback of CSOs.
- Provide traceability and possibility for troubleshooting.
2.1.2 Data Integrity Assurance
The strategy of Dynamic Activation is to ensure data provisioned is consistent and accurate. All business logics perform syntactic validation to verify request format, data type, and data value validity against predefined value range. Semantic validation with regards to application or service logic and customer context is performed when necessary. If needed, Dynamic Activation incorporates external validation functions into the provisioning process.
2.1.3 External Connectivity Robustness
This is implemented in different layers. Depending on the external system and the operator's IP network infrastructure, one of the following can take effect to continue the operation in different error scenarios.
- Multiple links
- Virtual IP
- Round-robin network element groups
- Fail over network element groups
- Retry
2.1.4 Resilient Activation
When using model driven asynchronous engine, Dynamic Activation product supports resilient activation for complex provisioning tasks and network setups.
The provisioning strategy is:
- To enable successful execution as much as possible through the Model Driven Asynchronous Activation Engine that supports configurable automatic retry.
- To reduce impact on northbound system by allowing to manually resend or cancel expired sub-requests in GUI.
- To provide rollback capability in case of partial executed request, which can be combined with retry functionality.
- To enable resend with loose error handling.
For information on implemented features, see Section 4.1.3.
2.2 Ease of BSS/OSS Integration
BSS is complex and at time costly to introduce changes. Dynamic Activation strives to reduce impact on BSS/OSS when introducing the product for the first time and when introducing new application and services. For more information, refer to OSS/BSS Integration Guide, Reference [29].
2.2.1 Single Point of Entry
Dynamic Activation is the single point of entry for provisioning of core network and services regardless of technology and vendor. Access to the provisioning services can be performed through one or more provisioning protocols, as follows:
- CAI3G
Customer Administration Interface Third Generation provides Web Service for Simple Object Access Protocol (SOAP) over HTTP/HTTPS.
CAI3G is available for both synchronous and asynchronous communication.
- CLI
Command-Line Interface is used for long lasting asynchronous provisioning activities such as massive update and location procedure. CLI is also used for multi destination provisioning activities such as updating service associated data in all HLR Front Ends. The CLI is accessed by using Telnet clients or direct socket connections.
- EDIFACT
Electronic Data Interchange For Administration, Commerce, and Transport (EDIFACT) message interface. This interface is provided by Business Support and Control System (BSCS)/Generic-Mediation-Device (GMD) to communicate with Dynamic Activation.
Dynamic Activation provides Northbound Interface Adaptation capability. A step-by-step guideline is provided for system integration to develop support for customer-specific Northbound Interface.
New protocol can be supported as integration service by producing a new Northbound Interface adapter.
2.2.2 Decoupling of Network Data Model
Decoupling of network data model enables the BSS/OSS to focus on business instead of network technology.
As shown in Figure 1, any entity that has provisioning needs could be a provisioning client, for example, BSS/OSS system, an end-user self-care system, or a network element. The provisioning data receiver can be a network element in the telecom network, but can also be a data source in the BSS/OSS domain.
Dynamic Activation presents the provisioning need of a client in the form of a Managed Object (MO). An MO can:
- Represent the complete information for a network element, for example Number Portability.
- Reflect only a subset of the information for an application, for example Closed User Group of the Home Location Register (HLR).
- Reflect data from various network element types. For example, Home Subscriber Server (HSS) and Domain Name System (DNS) server included in IP Multimedia Subsystem (IMS) core solution.
The physical implementation of the networks, protocols, and interactions towards network elements are hidden by the MO.
Four basic operations are provided to manage an MO. They are Create, Set, Get, and Delete.
A request coming from a provisioning client that operates on an MO is called a Customer Service Order (CSO). Each CSO is provided with a status upon completion indicating the result of the execution. A response is sent back to the client immediately for the synchronous communication or stored in a file for the asynchronous communication. During this process, the provisioning client is not aware of the data receiver.
Dynamic Activation communicates with network elements in the form of Network Service Orders (NSOs), that are network element specific.
A CSO can be transformed into several NSOs towards one or more network elements or types.
2.2.3 Decoupling of Network Topology and Provisioning Needs
Network Topology and Provisioning Needs are decoupled. This enables operators to expand network element capacity without affecting the BSS/OSS.
Dynamic Activation provides sophisticated routing solution that hides the network topology from the BSS/OSS, such as:
- Adding an instance of a network element.
- Relocating subscriber data between the existing network elements.
- Building redundant repositories of the same data
All above are handled as routing configuration in Dynamic Activation, and the BSS/OSS is not affected.
2.2.4 Decoupling of Network Element Implementation and Network Element Service
Network element implementation and the services provided by the network element are decoupled. This reduces the impact on the BSS/OSS domain when network element evolves in terms of internal architecture.
Dynamic Activation provides one provisioning interface for a network element regardless if the network element is in a monolithic architecture or data layered architecture.
2.2.5 Provisioning Orchestration and Abstraction
To ease integration with northbound systems, operators can construct resource facing service based on available provisioning logic. Resource facing service reflects the operator business need. The information model for a resource facing service differs from the information model of the network services. The information model for a resource facing service can aggregate or segment the network services. Tailored execution plan can be defined in resource facing service. To secure atomicity of the business use case, rollback can be implemented in the resource facing service.
Designer Studio is the graphical tool for configuration of resource facing service for Dynamic Activation.
2.2.6 Bulk Provisioning
Provisioning of large number of subscribers is called bulk provisioning. Such provisioning activity generates high provisioning traffic in bursts. For example:
- Pre-provisioning of pre-paid SIM cards in the network.
- A campaign that needs update existing subscribers who match a certain criteria.
- Bar postpaid subscribers that fail to pay the bill.
To support bulk provisioning, Dynamic Activation provides Batch Handler function and massive CLI interface to certain network elements which provide massive operation interfaces.
2.3 Model Driven Configuration
Traditionally, provisioning solutions are implemented by programming. To reduce time to market and cost for operators in the service process, Dynamic Activation introduces a model driven configuration approach to replace the programming approach. This approach separates the processing logic and the information needs to be processed. The processing logic comes with the Dynamic Activation execution environment while the models are to be configured for each deployment and use case. This simplifies the integration effort and eliminates the need for programming skills. Essentially, the domain experts are able to implement the solution by configuration.
The features built upon model driven configuration concept are resource configuration and Designer Studio.
For more information on Designer Studio, refer to User Guide for Designer Studio, Reference [15].
2.4 Off-the-Shelf Support
Dynamic Activation comes with pre-verified provisioning logic for major Ericsson network elements and solutions. The Dynamic Activation release plan is aligned with that of the core network. This ensures high-quality solution, timely availability of provisioning solution, and the shortest time for the operator to turn services delivered from Ericsson to revenue.
2.5 Adaptability
Dynamic Activation product has a large install base with operators in the world. To satisfy customer unique requirements for each deployment, Dynamic Activation is highly adaptable in various ways.
- The product feature sets are packaged commercially into value packages. For each deployment, it is possible to select only the needed value packages.
- Dynamic Activation can be deployed on virtual or cloud environment and native environment.
- Configurations are used for creating customer-specific
solutions:
- Configuration on the system, settings of the execution environment and business logic, provides customer specific wanted behavior in runtime. For details, refer to Function Specification Dynamic Activation Execution Environment, Reference [21].
- Configuration of Service Models, using Designer Studio, exposes business-oriented services to the northbound systems. For details, refer to User Guide for Designer Studio, Reference [15].
- Integration of new devices in runtime by configuration using the Resource Configuration feature. For details, refer to User Guide for Resource Configuration, Reference [18].
- Customer adaptation implemented by Ericsson service organization, by the operator, or by an independent integrator offers customer-specific solutions. For details, refer to Customer Adaptation Development Guide for Resource Activation, Reference [13].
- Product customization can be used for creating customer-specific solutions. This requires involvement of the product development unit. A typical example of product customization is enhancement in the Dynamic Activation execution environment. For details, contact your local Ericsson representative.
2.6 Visibility of System Status
Dynamic Activation strives to provide system insight so that users are always well informed and in control, which includes:
- At-a-glance information of all vital activities of the system, which can help user to spot problems quickly. For example, Dashboard for provisioning performance, Request Management, Processing Queue Management GUIs.
- Detail views such as execution progress of provisioning requests available in the Request Management GUI, and log management in the Log Management GUI.
3 Execution Environment
Features in Dynamic Activation are hosted by different execution environments based on the nature of the feature.
3.1 Dynamic Activation Execution Environment
Dynamic Activation execution environment provides the following common functions to operate and maintain the different features deployed upon it:
- Inbound and outbound connectivity
- Authentication and Authorization
- Licensing Management
- Event service
- Logging service
- GUI
3.2 Open Execution Environments
Some features of Dynamic Activation are deployed on open execution environments:
- The IDE depends on Eclipse.
- The Consistency Checker is a JEE 7 compliant software application. It depends on JEE 7 compliant Application Server.
- The Designer Studio depends on Java 8.
4 Features Deployed on Dynamic Activation Execution Environment
The following subsections contain descriptions of the various features that can be deployed in Dynamic Activation execution environment.
4.1 Common Features
This section describes common features of both Resource Activation and Resource Configuration.
4.1.1 NBIA
The Northbound Interface Adapter (NBIA) feature provides a list of service APIs, for example, Alarm service, Authentication service, and ProcLog Service. This makes all necessary platform functions ready for NBIA to use. IDE provides a Northbound Interface Wizard which can help to generate the code skeleton. An NBIA Development Step-by-Step Guide is provided as a tutorial to guide Solution Integrators about how to develop, deploy, and verify NBIA on Dynamic Activation.
For more information, refer to Northbound Interface Adapter Customization Development Guide for HTTP-Based Protocol, Reference [16].
4.1.2 Asynchronous Request Handler and Scheduling
Asynchronous Request Handler and Scheduling feature provides Dynamic Activation with a web service-based asynchronous interface. This means that the business system does not need to wait for the completion of the requests. Storing CSO for later execution enables the operator to make a service available for end users at a certain time.
This feature preserves the order of execution if the queue contains several CSOs related to the same subscriber, meaning inconsistency is avoided.
For more information, refer to Function Specification Dynamic Activation Execution Environment, Reference [21].
4.1.3 Model Driven Asynchronous Activation Engine
The Model Driven Asynchronous Activation Engine implements several features to secure resilience for service orders with multiple network element destinations.
- Asynchronous Northbound Interface with prioritization
capability
- Support for priority tagging on specific request content.
- Support for intermediate notifications as progress indicator for complex provisioning tasks.
- Model driven asynchronous activation engine with stateful execution capability
- Configurable automatic retry handling for network element
and loose error handling:
- Support for individual retry rule configuration per network element.
- Support for matching error code and error message response per request.
- Support for rescheduling of request upon error response.
- Request management using northbound and southbound requests
queues:
- Support for (re)send and cancellation of requests.
- Support for expiry of requests which provides the option to resend requests manually once the network problem is resolved.
- Support for transparent network outage and maintenance operations.
- Support for prioritization of requests.
- Status monitoring of request queues and ongoing requests
- Note:
- The provisioning requests toward southbound system are still sent through synchronous southbound interfaces.
For more information, refer to Function Specification Dynamic Activation Execution Environment, Reference [21].
These features are supported for Service Models that are created in Designer Studio. For more information, refer to User Guide for Designer Studio, Reference [15].
4.1.4 Batch Handler
Batch Handler is a GUI-based feature to manage and execute batch jobs. This can be used to automate handling many subscriptions. For example, to connect a range of new subscribers, or to change a group of existing subscriptions. The batch handler can be used upon the existing activation northbound that supports CAI or synchronous CAI3G. A batch job can be created and executed on demand, for example, when the network traffic is low.
For more information, refer to Function Specification Dynamic Activation Execution Environment, Reference [21].
4.2 Resource Activation Specific Features
This section describes features that are specific for Resource Activation.
4.2.1 Multi-Vendor Network Element Support
Dynamic Activation is a multi-vendor activation platform. This platform provides single point of access for all provisioning activities, regardless of the vendor of the network elements that require provisioning. This reduces the integration complexity for the BSS/OSS when introducing new network element vendors.
This feature provides the possibility to deploy provisioning logic for non-off-the-shelf network elements in the Dynamic Activation environment.
For more information, refer to Customization - Architectural Overview, Reference [3], and Customer Adaptation Development Guide for Resource Activation, Reference [13].
4.2.2 Replayer
The Replayer feature is a tool for resending provisioning requests towards to CUDB solution, to secure user data in network.
4.2.3 GSM/UMTS
GSM/UMTS feature provides activation interfaces for provisioning of 2G/3G core network in data layered architecture through the MML, CLI, CAI3G, and CAI interfaces.
GSM/UMTS feature provides method for administration of subscriber data and CAMEL/GPRS/gsmSCF profiles in the Centralized User Database (CUDB). Operations on individual subscriber and massive operations are supported. Updates of subscriber profiles and service associated data in the HLR front ends are also included in this feature.
For more information, refer to Function Specification Layered HLR, Reference [6].
4.2.3.1 Administration of Multi Regions
Administration of Multi Regions feature allows each region to administer its own HLR subscribers. Other subscribers served by the same network infrastructure are not accessible. A subscriber can only have access to HLR services provided within its region, regardless of the actual network capability. The feature supports administration of maximum 32 regions.
Each subscriber is given a Region ID (RID). An Administration Domain is specified by the RID, the IMSIs, and the MSISDNs. Optionally, restriction rules on other attributes can be defined per Administration Domain base.
When a provisioning request is received, it is evaluated towards the restriction rules defined in the administration domain. Provisioning requests that violate the restriction rules are rejected.
For more information, refer to Function Specification Administration of Multi Regions and BSS Capacity, Reference [4].
4.2.3.2 Administration of BSS Capacity
Administration of BSS Capacity feature prevents uneven HLR provisioning infrastructure consumption between regions, countries, and service providers. It enables the possibility to regulate the provisioning capacity which a user is entitled to use.
This feature allows configuration on maximum allowed parallel logons on the provisioning interfaces. When the configured limit on a given interface is exceeded, new logon attempts are rejected with an error message.
Administration of BSS Capacity also allows configuration on HLR sustainable throughput that regulates maximum allowed Customer Service Orders (CSOs) per second per domain during saturated traffic condition.
For more information, refer to Function Specification Administration of Multi Regions and BSS Capacity, Reference [4].
4.2.4 MNP
Mobile Number Portability (MNP) feature provides activation interfaces for provisioning of MNP application in data layered architecture. The interfaces are MML, CAI3G, and CAI.
MNP feature provides method for administration of MNP data in CUDB.
The MNP feature allows operators to administer relationships between MSISDNs and addresses of nodes in an HLR system.
For more information, refer to Function Specification Layered HLR, Reference [6].
4.2.5 VoLTE Auto Provisioning
Dynamic Activation can receive the notification from Core Network, such as the CUDB notification triggered through HSS. Dynamic Activation decides whether to provision the attached end user. If the decision is positive, Dynamic Activation provisions the user with the default VoLTE service profiles and notify BSS of the result.
For more information, refer to Solution Description VoLTE, Reference [26].
4.2.6 LTE EPC
Long-Term Evolution / System Architecture Evolution (4G) (LTE/SAE (4G)) feature provides activation interfaces for provisioning of 4G services in data layered architecture. The provisioning interfaces are CAI3G and CLI.
LTE/SAE (4G) feature provides method for administration of EPC subscriber data in CUDB.
Dynamic Activation also supports the Dedicated Core Networks feature in EPC subscriber data administration. However, this feature requires the additional value package EDA Shared Networks.
For more information, refer to Function Specification Layered LTE EPC, Reference [8].
4.2.7 M2M
The Machine to Machine (M2M) communication feature provides an effective provisioning solution.
The provisioning interfaces are CAI3G and CLI.
Provisioning support is provided for:
For more information, refer to Function Specification Layered Machine to Machine, Reference [9].
4.2.8 IMS Core
IP Multimedia Subsystem (IMS) Core feature provides activation interfaces for provisioning of IMS subscriber data in the data layered architecture through CAI3G interface.
IMS feature provides method for administration of IMS subscriber data in CUDB.
For more information, refer to Function Specification Layered IMS, Reference [7].
4.2.9 Ericsson SAPC
Service-Aware Policy Controller (SAPC) feature provides activation interfaces for provisioning of SAPC in data layered architecture and monolithic architecture. The provisioning interface is CAI3G.
For more information, refer to Function Specification SAPC, Reference [11].
4.2.10 Multimedia Telephony
Multimedia Telephony (MMtel) feature provides activation interfaces for provisioning of MMTel service data in Multimedia Telephony Application Server (MTAS) through CAI3G interface.
For more information, refer to Function Specification MTAS, Reference [5].
Enterprise segment feature provides activation interfaces for provisioning of conferencing services, company group services, Enterprise Value-Added Services (EVAS), and corporate directory services in Business Communication Enabler (BCE). This provisioning interface is CAI3G.
For more information, refer to Function Specification BCE, Reference [23].
Dynamic Activation supports presence and resource list-related service in Presence, Group and Data Management (PGM) through CAI3G interface. This makes the communication services more relevant, visible, and easily accessible for the end-user community.
For more information, refer to Function Specification PGM, Reference [24]
4.2.11 Ericsson Equipment Identity Register
Equipment Identity Register (EIR) feature provides activation interfaces for provisioning of EIR in data layered architecture. The provisioning interfaces are CAI3G and CLI.
For more information, refer to Function Specification Layered EIR, Reference [10].
4.2.12 IPWorks/AAA
IPWorks/Authentication, Authorization, and Accounting (AAA) feature provides activation interfaces for provisioning of IPWorks/AAA in data layered architecture. The provisioning interfaces are CAI3G and CLI.
IPWorks/AAA feature provides method for administration of IPWorks/AAA data in CUDB.
For more information, refer to Function Specification Layered IPWorks/AAA, Reference [12].
4.2.13 IPWorks/ENUM
IPWorks/Telephone E.164 Number Mapping (ENUM) feature provides activation interfaces for:
- Provisioning of ENUM records in layered and monolithic IPWorks.
- Provisioning of DNS domain in monolithic IPWorks.
For more information, refer to Function Specification IPWorks/ENUM, Reference [19].
4.2.14 DSC/ILF
Diameter Signaling Controller (DSC) / Individual Locator Function (ILF) provides activation interface for provisioning of ILF records. The provisioning interface is also backward compatible for that for Subscriber Location Function (SLF) of Multi Activation 7.2 and later PG Classic releases. For more information, refer to Function Specification DSC/ILF, Reference [20].
4.2.15 Charging and CBiO
Charging System (CS) feature provides provisioning support towards Account Information and Refill server (AIR) and Account Finder (AF) for online charging.
Charging and Billing in One (CBiO) is an end-to-end charging and billing solution for customer management.
In CBiO solution, Dynamic Activation utilizes the Designer Studio service modeling flexibility to support the orchestration of any types of EDIFACT operations.
For more information, refer to Solution Description Charging and CBiO, Reference [25].
4.2.16 Wi-Fi Calling for Multi-Device
Ericsson Wi-Fi Calling for multi-device provides a simple and cost efficient way to extend operator coverages to multiple Wi-Fi capable devices of user. With this new capability, Wi-Fi Calling is offered for devices without a SIM-card device, which is called Non-SIM device, over Wi-Fi network.
The following provisioning functions are provided in the solution:
- Voice over Wi-Fi subscription
- Monolithic HSS and ECAS subscription
- Monolithic or Layered IPWorks AAA-FE NSD (NonSIM Device) subscription
- Monolithic IPWorks AAA Geographic Redundancy provisioning over two sites
For more detail information, refer to Solution Description Wi-Fi Calling, Reference [30].
4.3 Resource Configuration Specific Features
Resource Configuration provides a model driven solution for configuration of devices through the following protocols:
- Simple Network Management Protocol (SNMP)
- Hypertext Transfer Protocol (HTTP)
- HTTP Secure (HTTPS)
- Telnet
- Secure Shell (SSH) using CLI or NETCONF
Resource Configuration enables integration of network elements during runtime without programming. The following subsections describe main components that the solution is based.
4.3.1 Service Visualization
The Service Visualization provides an overview of service instances, and visualizes how the service depends on devices and features.
4.3.2 Model Catalog with Feature Models
The feature model is a logical representation of a network functionality, for example a BGP configuration in a router. This feature model is exposed as a Managed Object (MO) in the northbound CAI3G interface. The feature model provides a uniform way of managing this feature, regardless of what vendor and interface is used to communicate with the actual network southbound. The feature model is defined as an XML schema or as a YANG model.
4.3.3 Vendor Templates
The vendor template is a configuration file that describes how to set up one or several features in a specific type of device. For example, how to configure the Loopback interfaces feature in Juniper routers.
There are two types of templates:
- XML Vendor Template
The XML template describes the following:
- The command sequence to set up a feature in a device.
- How to map the data from the Northbound Interface to those southbound commands
Resource Configuration provides several GUIs to simplify the work with the XML templates.
- YANG Template
The generic YANG engine simplifies the integration of all devices that exposes a YANG/NETCONF interface. A GUI is used to map the data in the feature model with the device-specific data model based on constraints given by the YANG file. The corresponding NETCONF commands are automatically generated.
4.3.4 Device Repository
The Device Repository tracks all the devices that can be managed in the Resource Configuration solution. It stores information like logon credentials, device type, and information about the actual device configuration. It also stores historical information about previous configurations. This makes it possible to visualize configuration changes and revert to the configuration at any point in time. It is also possible to manage the current device configuration directly from the GUI.
5 Features Deployed on Open Execution Environment
5.1 Designer Studio
Designer Studio is a graphical tool for designing customer specified resource facing services. A resource facing service is described in a service model.
A service model is built upon available services, including:
- Standard features, such as core network, IP networking, and service layer applications.
- Customizations, such as multi-vendor network elements and solutions, feature models, and existing subscriber views.
Using Designer Studio does not require programming skills. This means that the same person can do both solution design and implementation.
Designer Studio provides visual display of the tasks and their dependencies within the service model.
Service models configured using Designer Studio are deployed directly to Dynamic Activation without the need for compilation. The service models are executed by a dedicated engine. The service model engine also has built-in rollback capability.
Service models created in the Designer Studio require an SW Advanced license to run on the Dynamic Activation.
For more information about Designer Studio, refer to User Guide for Designer Studio, Reference [15].
5.2 Consistency Checker
The Consistency Checker is a generic data comparison tool for telecom operators.
The Consistency Checker is targeted for exploring data consistency status for telecom operators. The Consistency Checker compares arbitrary data from arbitrary data sources and presents the result in the form of report and output files.
The most common use cases for the Consistency Checker are the following:
- Redundant data source inconsistency analysis
Audit whether entries in the two data sources are identical. An example is to compare a pair of HLRs in redundant configuration.
- User provisioning inconsistency analysis
Audit whether a user is provisioned in the data sources. An example is to check whether a user in BSS/OSS also exists in the HLR.
- Service provisioning inconsistency analysis
Audit whether a user is provisioned with consistent services in the network. An example is to check whether the call restriction settings in the HLR are the same as that in the BSS/OSS.
By understanding the consistency status in the network, the operator can make further decision to eliminate data inconsistency by either of following:
- Correcting the inconsistent data.
- Adjusting operational process and procedures.
The Consistency Checker is hardware and operating system independent, that is, it can be deployed on any JEE v7 compliant Application Server.
For more information about Consistency Checker, refer to Function Specification Consistency Checker, Reference [14].
6 Solution Scenarios
Each operator has unique provisioning requirements, thus a deployed Dynamic Activation instance varies from one to another. One operator can have more than one deployed Dynamic Activation instances, each aiming for a specific task. Some typical solution scenarios are described in the coming sections.
6.1 Resource Activation Provisioning Solution
Figure 2 shows a resource activation example. This operator has a mature 2G/3G/4G core network and is offering VoLTE service. Service layer applications are from other vendors.
The operator uses Dynamic Activation as common provisioning mediation.
- The Dynamic Activation system deploys several off-the-shelf provisionings features such as 2G/3G and IMS core.
- The Ericsson Service Integration organization produced the provisioning logic for all multi vendor network elements. This logic is also deployed on the Dynamic Activation system.
- To ease integration towards their BSS/OSS. The operator can use Designer Studio to configure their own service models, for example for VoLTE subscription. Such service models can also benefit from the Resilient Activation function.
- The Batch Handler is used to manage pre-creation of subscribers.
- For the UDC solution, the operator uses the Replayer feature to ensure data consistency when CUDB mastership change takes place.
6.2 VoLTE
Figure 3 shows a VoLTE normal provisioning example, and Figure 4 shows a VoLTE auto provisioning example.
End-to-end VoLTE provisioning solution helps customer get the VoLTE service quickly and cost efficiently. For more information, refer to Solution Description VoLTE, Reference [26].
6.3 Revenue Management
Figure 5 shows the use cases supported by Revenue Management provisioning solutions.
This solution uses the following functions:
- Charging System Provisioning
Dynamic Activation supports the direct provisioning towards Ericsson Charging System (CS) nodes. Supported Network Elements (NEs) are Account Information and Refill server (AIR) and Account Finder (AF).
- CBiO Provisioning
Charging and Billing in One (CBiO) is an end-to-end real-time charging and billing solution for customer management. In CBiO solution, Dynamic Activation provides a framework for Electronic Data Interchange for Administration, Commerce, and Transport (EDIFACT) messages with the flexibility to provisioning any NE types.
6.4 Residential Broadband
Figure 6 shows a resource configuration example of the residential broadband solution, which is a wireline operator that offers FTTH service to their customers. The operator uses Dynamic Activation to manage the FTTH configurations.
Optional features that can be used with the solution are:
- Asynchronous Request Handler and Scheduling
- Northbound Interface Adapter
6.5 Quadruple Play
Figure 7 shows a quadruple play example. This is a wireline and wireless operator that offers Quadruple Play service to their customers. The operator uses Dynamic Activation to manage both wireline/wireless configurations and subscribers.
The solution uses the same provisioning functions as the FTTH example shown in Section 6.4, and combines them with the following Resource Activation functions:
- The Dynamic Activation system deploys several off-the-shelf provisionings features such as VoIP, Broadband, 2G/3G, and IMS core.
- The Ericsson Service Integration organization produced the provisioning logic for all multi vendor network elements. This logic is also deployed on the Dynamic Activation system.
The Designer Studio feature is used to combine the Resource Configuring Model and the Resource Activation Model, into a new Quadruple Play service.
7 Deployment
Dynamic Activation can be deployed on native, virtual, and cloud environments.
- For UDC solution, native deployment can be used, and cloud deployment is a beneficial alternative.
- For non-UDC solutions, virtualized and cloud deployment is recommended.
For the supported deployment configurations installation instructions and procedures, system operation and maintenance procedures are provided. This reduces system rollout lead time and minimizes competence building effort for O&M personnel.
7.1 Virtualized and Cloud Deployment
Dynamic Activation supports virtualized and cloud deployment. This provides better hardware use, enables co-deployment with other virtualized or cloud products and the flexibility to deploy the product on any compatible hypervisor.
- Note:
- Resource Configuration is only deployed on virtualized and cloud deployment.
Dynamic Activation on a virtual or cloud environment can be deployed in scalable high-availability configuration with minimum three VMs running on at least three separate hosts.
Dynamic Activation can also be deployed with three or four VMs running on one host alternative for non-commercial deployment.
For virtualized deployment, the following hypervisors are supported:
- Kernel-based Virtual Machine (KVM), which is a system verified hypervisor.
- VMware ESXi
For cloud deployment, the following is supported:
- Cloud Execution Environment (CEE)
- OpenStack (Newton or later)
Both virtualized and cloud Dynamic Activation uses Red Hat Enterprise Linux (RHEL) as guest operating system.
For more information, refer to Function Specification Dynamic Activation Execution Environment, Reference [21].
Deployments of Dynamic Activation on non-standard hypervisors and cloud are handled as services. For more information, contact the local Ericsson office.
7.2 Native Deployment
For native environment, the system is by default in High Availability configuration with minimum configuration of four servers.
For more information about the hardware configurations in Dynamic Activation 1, refer to BSP 8100 documentation. For details, see document ECP Guideline for Ordering BSP8100 in Dynamic Activation 1, in http://prodcat.internal.ericsson.com.
For more information about the operating system in Dynamic Activation 1, refer to Function Specification Dynamic Activation Execution Environment, Reference [21].
Deployment of Dynamic Activation on other hardware is handled as services. For more information, contact the local Ericsson office.
8 Migration from Classic Multi Activation to Dynamic Activation
Multi Activation Classic customers are able to migrate to Dynamic Activation with extensive migration tool and methods.
Dynamic Activation is able to adapt to new business and technology requirements quickly. Dynamic Activation also allows you to take a larger ownership, being able to manage minor adaptations on your own.
Dynamic Activation enables you to consolidate your activation, supporting new and legacy network technologies, physical and virtualized, wireline and wireless. This is achieved by providing agile tools for development and configuration, focusing on keeping down lead time and cost.
As a part of the Ericsson OSS solution, Dynamic Activation simplifies operation by using the same Way of Working (WoW) and 3PP. Virtualization / cloud based deployment are other essential characteristics to achieve agility and use of Commercial Off The Shelf (COTS) hardware.
So how does Dynamic Activation responds to this and how does the operator benefit when upgrading from Classic to the new deployment?
- Supporting the operators WoW by allowing operators to:
- Define how to expose network assets towards BSS/OSS (RFS)
- Provide better insights through Graphical configuration.
For more information, refer to User Guide for Designer Studio, Reference [15].
- Support for new vendor equipment through GUI and configuration.
For more information, refer to User Guide for Resource Configuration, Reference [18].
- Deployment in operators server farm, cloud, or hosted environment.
- Dashboard
- Simplified operation and lower OPEX through support of:
- Providing an agile architecture through
Reference List
| [1] Library Overview, 18/1553-CSH 109 628 Uen |
| [2] Glossary of Terms and Acronyms, 0033-CSH 109 628 Uen |
| [3] Customization - Architectural Overview, 20/1553-CSH 109 628 Uen |
| [4] Function Specification Administration of Multi Regions and BSS Capacity, 10/155 17-CSH 109 628 Uen |
| [5] Function Specification MTAS, 16/155 17-CSH 109 628 Uen |
| [6] Function Specification Layered HLR, 4/155 17-CSH 109 628 Uen |
| [7] Function Specification Layered IMS, 18/155 17-CSH 109 628 Uen |
| [8] Function Specification Layered LTE EPC, 5/155 17-CSH 109 628 Uen |
| [9] Function Specification Layered Machine to Machine, 15/155 17-CSH 109 628 Uen |
| [10] Function Specification Layered EIR, 7/155 17-CSH 109 628 Uen |
| [11] Function Specification SAPC, 9/155 17-CSH 109 628 Uen |
| [12] Function Specification Layered IPWorks/AAA, 8/155 17-CSH 109 628 Uen |
| [13] Customer Adaptation Development Guide for Subscriber Activation, 5/1553-CSH 109 628 Uen |
| [14] Function Specification Consistency Checker, 21/155 17-CSH 109 62 Uen |
| [15] User Guide for Designer Studio, 10/1553-CSH 109 628 Uen |
| [16] Northbound Interface Adapter Customization Development Guide for HTTP-Based Protocol, 7/1553-CSH 109 628 Uen |
| [17] DUP Customer Adaptation Migration Guide, 19/1553-CSH 109 628 Uen |
| [18] User Guide for Resource Configuration, 11/1553-CSH 109 628 Uen |
| [19] Function Specification IPWorks/ENUM, 20/155 17-CSH 109 628 Uen |
| [20] Function Specification DSC/ILF, 12/155 17-CSH 109 628 Uen |
| [21] Function Specification Dynamic Activation Execution Environment, 6/155 17-CSH 109 628 Uen |
| [22] Function Specification Resource Activation, 3/155 17-CSH 109 628 Uen |
| [23] Function Specification BCE, 17/155 17-CSH 109 628 Uen |
| [24] Function Specification PGM, 11/155 17-CSH 109 628 Uen |
| [25] Solution Description Charging and CBiO, 1/221 02-CSH 109 628 Uen |
| [26] Solution Description VoLTE, 2/221 02-CSH 109 628 |
| [27] System Administrators Guide for Native Deployment, 1/1543-CSH 109 628 Uen |
| [28] System Administrators Guide for Virtual and Cloud Deployment, 3/1543-CSH 109 628 Uen |
| [29] OSS/BSS Integration Guide, 3/1551-CSH 109 628 Uen |
| [30] Solution Description Wi-Fi Calling, 4/221 02-CSH 109 628 Uen |