Contents

1   Introduction

This section is an introduction to this document. It contains information about the prerequisites, purpose, scope, and target group for the document. This section also contains explanations of typographic conventions used in this document.

1.1   Purpose and Scope

This document gives a brief introduction to Charging system and Charging and Billing in One (CBiO) solution for customer management, provided by Ericsson™ Dynamic Activation (EDA).

1.2   Target Group

The target group for this document is as follows:

• Application Administrator
• Marketing
• Network Administrator
• System Administrator
• Network Supervision Administrator
• Application Designer

For more information regarding the different target groups, see Library Overview Reference [1].

1.3   Typographic Conventions

Typographic conventions are described in Library Overview Reference [1]. In addition to the writing conventions mentioned above, the following applies:

2   Charging System

2.1   Overview

Charging system is a mobile service that enables subscribers to make and receive calls, use of messaging and data services as long as the account limitations (such as the service fee period, supervision period, account value, and barring list) are not met.

Dynamic Activation also supports the direct provisioning towards Ericsson Charging System (CS) nodes. The supported Network Elements (NEs) are Account Information and Refill server (AIR) and Account Finder (AF).

Figure 1 shows the provisioning architecture of Charging System in Dynamic Activation.

The Northbound Interface for charging system is CAI3G. The southbound interface towards AIR is ACIP and UCIP over HTTP/XMLRPC. And the southbound interface towards AF is DNS.

2.2   AIR Provisioning

The AIR server handles messages from both traffic and administrative NE inside a Charging system. For detailed information about AIR provisioning, refer to Charging Provisioning over CAI3G, Reference [3].

The following table describes the supported AIR provisioning use cases.

Table 1    Supported AIR Provisioning Client Cases

MO	Operation	Supported Use Cases	AIR-IP Commands
Subscription	Create	Create a subscriber with relevant account and subscriber data.	InstallSubscriber
		Link a previously created subscriber to another subscriber account.	LinkSubordinateSubscriber
	Get	Retrieve subscriber account information.	GetAccountDetails
		Retrieve subscriber account balance data.	GetBalanceAndDate
		Retrieve promotion plans allocated to the subscribers account.	GetPromotionPlans
		Retrieve current accumulated values of promotion plans.	GetPromotionCounters
		Retrieve the service classes the subscriber is allowed to use.	GetAllowedServiceClasses
		Retrieve Family and Friends numbers list.	GetFaFList
		Retrieve the allowed refill options for a subscriber.	GetRefillOptions
		Retrieve the active usage counters and thresholds for a subscriber.	GetUsageThresholdsAndCounters
	Set	Update subscriber account information.	UpdateAccountDetails
		Adjust balances, start dates, and expiry dates on the main account and the dedicated accounts.	UpdateBalanceAndDate
		Add, set, or delete a promotion plan allocation to an account.	UpdatePromotionPlan
		Modify the counters used by promotion plans for a subscriber.	UpdatePromotionCounters
		Update the service class for a subscriber.	UpdateServiceClass
		Set or clear the temporary blocked status on a subscriber.	UpdateTemporaryBlocked
		Update the Family and Friends list for either the account or subscriber.	UpdateFaFList
		Update the list of communities which the account belongs to.	UpdateCommunityList
		Set or update the accountGroupID and serviceOffering parameters.	UpdateSubscriberSegmentation
		Bar or clear the subscriber when attempting refills.	UpdateRefillBarring
		Update the usage thresholds and counters for a subscriber.	UpdateUsageThresholdsAndCounters
		Remove a personal or common usage threshold from a subscriber.	DeleteUsageThresholds
		Add periodic account management data to a subscriber.	AddPeriodicAccountManagementData
		Delete periodic account management evaluation data for a subscriber.	DeletePeriodicAccountManagementData
		Change periodic account management data for a subscriber.	UpdatePeriodicAccountManagementData
		Adjust balances, start dates, and expiry dates on the sub dedicated accounts.	UpdateSubDedicatedAccounts
		Remove one or more dedicated accounts for a subscriber.	DeleteDedicatedAccounts
	Delete	Delete an exiting subscriber. When a master subscriber is deleted, its account and all the data connected to the account (dedicated accounts, accumulators, and so on) are deleted. When a subordinate subscriber is deleted, only the subscriber part and its related data are deleted.	DeleteSubscriber
Offer	Get	Retrieve the list of offers currently assigned to a subscriber account.	GetOffers
	Set	Assign a new offer or update an existing offer to a subscriber account.	UpdateOffer
	Delete	Disconnect an offer assigned to a subscriber account.	DeleteOffer
PredefinedOffer	Get	Retrieve the list of predefined offer values currently assigned to an account.	GetPredefinedOfferValues
	Set	Update the predefined offer values for an account.	UpdatePredefinedOfferValues
	Delete	Delete the predefined offer values assigned to an account.	DeletePredefinedOfferValues
CommunicationID	Set	Change the Communication ID for a subscriber. For example, MSISDN, NAI, IMSI, SIP-URI, and PRIVATE.	UpdateCommunicationID
Refill	Set	Apply refill for a subscriber account. It can be either a voucher refill or a voucherless refill.	Refill
Accumulators	Get	Retrieve accumulator values for a subscriber.	GetAccumulators
	Set	Adjust the counter values of the chosen accumulators for a subscriber.	UpdateAccumulators
	Delete	Remove one or more accumulators for a subscriber.	DeleteAccumulators
Capabilities	Get	Retrieve available capabilities of the AIR server.	GetCapabilites
RunPeriodicAccountManagement	Set	Execute an on-demand periodic account management evaluation.	RunPeriodicAccountManagement

2.2.1   Multiple AIR

Multiple AIR algorithm is used when more than one AIR in the system. For detailed information, refer to Function Specification Resource Activation, Reference [4].

2.3   AF Provisioning

AF is a network element that provides location information for subscriber accounts in the system, it acts as a DNS. It stores the SDP ID and the related IP address for each MSISDN in the network.

The following provisioning use cases are supported.

• Update Location Information
  • Add subscriber (MSISDN)
  • Remove subscriber (MSISDN)
  • Change subscriber (MSISDN)
• Retrieve Location information (and MSISDN)
• Update Identifiers Information:
  • Add identifier (NAI, SIP-URI, PRIVATE, IMSI)
  • Remove identifier (NAI, SIP-URI, PRIVATE, IMSI)
  • Change identifier (NAI, SIP-URI, PRIVATE, IMSI)

For detailed information about AF Provisioning, refer to Charging Provisioning over CAI3G, Reference [3].

2.4   Atomicity and Integrity Handling

Atomicity means ensuring that any operations performed on the system are either all completed successfully or all reversed successfully to keep the data consistency.

In the provisioning of Charging NEs, most MO operations (CSO) perform one network element provisioning command (NSO) only. They are not applicable for atomicity handling.

The following CSO can optionally perform more than one NSO. Atomicity is not enforced by Dynamic Activation. BSS resents the requests to complete the whole provisioning successfully.

• AIR setSubscription

  The execution terminates at the failed NSO, succeeding NSOs are not executed.

• AIR getSubscription

  Response is assembled by those NSO responses which are returned from AIR successfully.

3   Charging and Billing in One Solution Overview

Charging and Billing in One (CBiO) is an end-to-end real-time charging and billing solution for customer management. Dynamic Activation provides an Electronic Data Interchange for Administration, Commerce, and Transport (EDIFACT) framework for EDIFACT messages with the flexibility to provision any types of NEs in the CBiO solution.

Figure 2 shows the overall architecture of CBiO provisioning solution in Dynamic Activation.

The procedure of Dynamic Activation processes a request received from Business Support and Control System (BSCS) is as follows:

1. EDIFACT NBIA transforms the request received from BSCS to CAI3G request and sent to Asynchronous Request Handler.
2. Asynchronous Request Handler schedules the execution time for this CAI3G request and sends to Service Model when the request is ready for execution.
3. Service Model Engine executes the request according to the task execution pattern based on the parameter dependencies and task conditions. And data is sent to Java Data view (JDV) to execution.
4. When the request is completed, a notification is sent to the BSCS receiver by Asynchronous Request handler.

The definitions of the technical terms introduced in the workflow are list as follows:

• EDIFACT NBIA - Dynamic Activation provides EDIFACT as Northbound Interface for CBiO, which allows system integrators to develop Customer Adaptation (CA) according to the customer requirements for EDIFACT interface.

  For detailed information about EDIFACT interface, refer to Generic EDIFACT Interface Specification, Reference [2].

• Asynchronous Request Handler - A web service-based asynchronous interface meaning that the business system does not need to wait for the completion of the requests. Enables the operator to make a service available for end users at a certain time.
• Service Model Engine - Service model engine is a dedicated component in Dynamic Activation that executes the deployed service models.
• Designer Studio - The service model is to ease integration towards northbound systems. A service model consists of several task containers, each corresponding to one of the CRUD operations defined in the interface of the service. User can define the logic in Designer Studio which is a graphical configuration tool for designing services that reflects the business need of northbound systems.
• Java Data View (JDV) - The JDV layer contains the core of the Business Logic(BL). Java business logic is used to implemented support for Network Elements required complex logic to handle the activation activities. Dynamic Activation provides off-the-shelf node-level support for Ericsson Network Elements (For example, HLR, and AuC for wireless domain, and Ericsson Charging System). By using the Dynamic Activation Integrated Development Environment (IDE), the multi-vendor network element support can be developed easily in Dynamic Activation.

Reference List

Ericsson Documents
[1] Library Overview, 18/1553-CSH 109 628 Uen
[2] Generic EDIFACT Interface Specification, 3/155 19-CSH 109 628 Uen
[3] Charging Provisioning over CAI3G, 9/155 19-CSH 109 628 Uen
[4] Function Specification Resource Activation, 3/155 17-CSH 109 628 Uen