Seamless OSS/BSS for IMS Services

White Paper

(Version 0.8)

June, 2008

Table of Contents
1. INTRODUCTION ...............................................................................................................................1 1.1 BACKGROUND......................................................................................................................................1 1.2 GENERAL OVERVIEW OF THIS DOCUMENT..................................................................................................2 2. BUSINESS SCENARIO......................................................................................................................3 3. SOLUTION..........................................................................................................................................7 3.1 SOLUTION OVERVIEW.............................................................................................................................7 3.2 SOLUTION IN DETAILS............................................................................................................................8 3.2.1 Business process .....................................................................................................................8 3.2.2 System function.......................................................................................................................14 3.2.3 Information model..................................................................................................................22 4. RELATED INTERFACES................................................................................................................26 4.1 INTERFACES OVERVIEW........................................................................................................................26 4.2 INTERFACES.......................................................................................................................................28 4.2.1 I1.............................................................................................................................................28 4.2.2 I2.............................................................................................................................................29 4.2.3 I3.............................................................................................................................................30 4.2.4 I4.............................................................................................................................................31 4.2.5 I5.............................................................................................................................................35 4.2.6 I6.............................................................................................................................................36 4.2.7 I7.............................................................................................................................................37 4.2.8 I8.............................................................................................................................................39 4.2.9 I9.............................................................................................................................................40 4.2.10 I10.........................................................................................................................................43 4.2.11 I11.........................................................................................................................................43 5. CONTRIBUTION TO INDUSTRY GROUPS................................................................................44 6. CONCLUSION..................................................................................................................................45 APPENDIX: DOCUMENT HISTORY................................................................................................46

1. INTRODUCTION
1.1 Background
Telecoms invest in their network infrastructure to increase revenues and hopefully profits, as well as to increase operational efficiency and hopefully reduce expenses, which addresses IP multimedia subsystems (IMS) and increasing revenues. IMS is a standard architecture being developed by almost all tier 1 telecom operators and their vendors. It provides a service creation and delivery platform for new session initiation protocol (SIP) based multimedia services independent of network access technology. IMS is an important architecture for the telecoms for three reasons. First, it monetizes the IP network, as it gives telecoms control over IP networks so they can offer and bill for usage, applications and QoS-based services. Second, the telecom can create new services and businessesfor example, seamless wired, wireless and IP networkingand more importantly it can segment customers from the network and introduce non-telecom products that have a telecom component. Third, IMS enables operational efficiency. IMS architecture can lead to removal of OSS/BSS stovepipes. The ideal result is that all future services will only need one OSS/BSS. Therefore, according to the development trends of fixed-mobile convergence in telecom industry, IMS is the most important technology for core network evolution. China Unicom started IMS trial from last half year of 2006, and finished it at the end of 2007, whose main mission is to test and verify the fundamental functions of IMS network elements. As is a fact, the current research and standardization for IMS in telecom industry is mainly focused on network and services, concerning less on OSS/BSS. OSS/BSS is a support system in the operating process of integration, the sharing of information resources for the telecommunication service providers, which is a comprehensive service operation and management platform. Almost every Billing World and OSS Today issue has covered OSS/BSS challenges of IMS architected networks. In order to save on OPEX in the long run and remove stovepipes, most of todays OSS/BSS must be replaced by IMS OSS/BSS. As the OSS/BSS of 2G existing systems cannot effectively support the IMS network operation, it is necessary to study the applicable OSS/BSS for IMS service. In order to promote this study, China Unicom has allied several operators, vendors and system integrators to do much work in this field. For example, China Unicom has pushed forward the catalyst project of TMF-- Seamless OSS/BSS for IMS services, and Seamless OSS/BSS for IMS Services (Phase I) has successfully demonstrated the
1

deployment, activation, charging and management of a full-duplex, video-telephony service of IMS in Dallas, 2007. The catalyst showcase presented a unique industry reference model for seamless OSS/BSS support for IMS offerings in a multi-vendor systems environment. However, it is just a first step to monetizing IMS services for telecom operators. Based on the achievements of the Seamless OSS/BSS for IMS Services (Phase I) catalyst project, we will provide an effective solution for IMS OSS/BSS. It will extend the subjects of IMS services lifecycle to service creation and service delivery by means of integrating SDP with AS. Furthermore, it also provides typical IMS several services with fixed and mobile IMS terminals, and realizes end-to-end convergence charging with OCS and Billing System, which is more close to the real commercial operation. Furthermore, we will verify this solution in the catalyst showcase -- Seamless OSS/BSS for IMS Services (Phase II). The purpose of this white paper is to explore a management framework for centralized IMS services. It aims to provide how to manage the creation, provisioning and charging of IMS services process using NGOSS framework, demonstrating IMS services lifecycle, OSS/BSS architecture and methodology. It provides a total solution of OSS/BSS for IMS services, which can be used as an industry reference model for operators, and bring plenty of benefits to service providers, system vendors, equipment vendors and systems integrators. Improve understanding to requirements of IMS from service providers. Presents an industry reference model for seamless OSS/BSS support for IMS offerings in a multi-vendor systems environment. Apply flexible charging policy to future IMS features, and realize online charging scenario for IMS. Reduce the difficulties and accelerate the pace of OSS/BSS implementation for IMS services. Select more candidate standard interfaces which are promoted by vendors, and reduce the integration cost of OSS/BSS for IMS services by reusing the standardized interfaces. Reduce development cost by reusing standard interfaces and SID (Shared Information/Data).

1.2 General overview of this document

The rest of this paper is organized as follows. Section 2 introduces business scenarios involved in this white paper. It will provide more rich IMS services and more access types of IMS terminals available for services, which is closer to the real commercial operation. Moreover, different charging requirements are also presented in this section. Section 3 discusses details of the solution. In this section, the solution of IMS OSS/BSS is introduces in general firstly. Then, based on the solution overview, the
2

work processes, functions and SID of the solution are explained in detailed. Section 4 presents the information of related interfaces of the solution. In this section, all the interfaces involved in the solution are introduced, and information about each interface is also provided. Section 5 introduces the solutions contribution to the industry. Section 6: conclusions.

2. BUSINESS SCENARIO
In this section, we will describe in detailed the business scenario in IMS network, which is very close to real commercial operation. Furthermore, about seven typical IMS services and three type IMS terminals are involved in the business scenario. We firstly introduce the IMS services used in the business scenario: (1) IM (Instant Messaging) Instant messaging can immediately exchange messages among participants. Through presence and group management, end users of instant messaging can know whether a certain friend is online and decide whether to send messages to the friend. (2) PS (Presence) Presence service allows users to timely obtain presence information such as user status, communication capability, and personal hobby and show it to other users in a certain communication mode and on the basis of certain access principles. Presence service helps you to know the status of a person you want to contact and also lets him know your status. In this way you can select an appropriate communication means or time period to communicate with each other. (3) VT (Video Telephony) Video telephony is full-duplex, real-time audio-visual communication between or among end users. (4) MRBT (Multimedia Ring Back Tone) Users can set the MRBT service so that other users calling them can hear music rather than ringing tone. (5) MMCI (Multi Media Colorful Identity) When one acts as a called party, the video and picture of the calling party will be displayed on his terminal. (6) DAB (Dynamic Address Book) Dynamic Address Book is a new value-added service, on the basis of the original telephone directory, with the function of presence, groups and virtual storage management. It makes mobile phones convert function as the center to a customercentric use. (7) PBR (Presence-based Routing) It allows incoming callers to reach an intended recipient, based on his or her presence status, increases probability of a successful call completion. The use case is
3

shown as following: (a) If target recipient is online, the call is routed to a desktop; (b) If target recipient is busy, incoming calls are routed directly voicemail; (c) If target recipient is away, then a Find Me Follow Me service is activated. In order to use the services of IMS mentioned above, three type IMS terminals will be employed in the business scenario. (1) Soft DA SoftDA (Software Digital Assistant) is a personal all-function assisting software that incorporates multiple services in one system, is rolled out by ZTE, oriented towards enterprises and high-end customers. The SoftDA client often acts as a system and user interface. Similar to MSN, QQ, and so on, its major function is to provide users with friendly service usage methods such as instant communication, click to dial, video conference, and telephone directory. It also has a function of setting personal information. The SoftDA client now can be installed in a PC, PDA, and mobile phone. On a PC, it is either a PC client or a Web client. In the catalyst project, SoftDA supports such IMS services as IM, PS, MRBT, MMCI, VT, and PBR. (2) E700 Wi-Fi mobile phone ZTE E700 is a stylish mobile handset for GSM 900/1800 MHz qual band and WiFi. ZTE E700 is a smart phone with Linux operating system. ZTE E700 has a singlescreen and bar form. The key highlights of the ZTE E700 are strong business functions and 2M auto focus sensor. In the catalyst project, E700 Wi-Fi mobile phone supports such IMS services as VoIP, IM, PS, MRBT, DAB, and PBR. (3) SIP hard phone - V300 ZXV10 V300 SIP Video Phone is a full-feature telephone which provides communication over the IP network that your computer use and focus on NGN/IMS services. This phone functions much like a traditional analog phone, allowing you to make and receive telephone calls. In additional, it provides high quality video conversation with QCIF or CIF format. It also supports features that you have come to expect from a telephone, such as speed dialing, redial, phone book, recent calls, recorder, alarming clock. In the catalyst project, SIP V300 hard phone supports such IMS services as MRBT, MMCI, VT, and PBR. In the business scenarios, different charging mode, such as event-, time-, and media component-based charging and monthly fee, and different charging mechanism, such as online charging and offline charging, are used to close to the real commercial operation. In the business scenarios, four roles are involved in, and we suppose that they are Bob, Sam, Mary and Junior respectively, and Sam is Bobs colleague, Junior is Marys boyfriend. The business scenarios are shown as following. Scenario 1:
4

Firstly, Bob subscribes his IMS services, such as PS, MRBT, MMCI, and VT. Ordinarily (for example, when they are in work), the calls between Bob and Sam are by means of SoftDA phones. Now, Bob calls Sam with SoftDA. However, at the current time, the status of Sam is appeared away in his SoftDA. So the PBR service that subscribed by Sam transfers this call to his E700 Wi-Fi mobile phone, and Bob experiences MRBT subscribed by Sam. As E700 Wi-Fi mobile phone doesnt support VT service, Then Bob talks with Sam by VoIP discussing some businesses of company. Finally, Sam hangs up the call when they end the discussion.
PS1: When condition is not allowed to set up a VT call, it will be downgraded to VoIP call automatically.

Figure 2.1: Business Scenario 1

Scenario 2: Firstly, Junior subscribes his IMS services, such as IM, PS, MRBT, MMCI, and VT. Now, Mary is on her way home, having E700 Wi-Fi phone with her, and she finds Juniors presence is online with DAB service. So she sends an IM to Junior and asks him call her 5 minutes later, when she arrived home. As a SIP V300 hard phone has been deployed in Marys home, so 5 minutes later, Junior dials the SIP V300 hard phone of Mary. Junior experiences MRBT subscribed by Mary, and Mary experiences MMCI subscribed by Junior. Then Mary talks with Junior by VT service. Finally, Junior hangs up the call in the end.

Figure 2.2: Business Scenario 2

In the business scenario, the charging rules, which are also close to real commercial situations, are shown as following. In scenario 1, Fees relating to company business are charged from Bobs company account. The services subscribed by Bob and Sam, such as PS, MRBT, MMCI and PBR, are charged with monthly fee from company postpaid account by the off line charging system. The VoIP call between Bob and Sam is charged with time-based mode from Bobs company prepaid account by the online charging system. In scenario 2, Fees relating to personal business are charged from Juniors personal account. All the services subscribed by Mary will be charged from Juniors personal account. The services subscribed by Mary, such as PS, MRBT and DAB, are charged with monthly fee from Juniors personal postpaid account by the off line charging system. The IM service of Mary will be charged with event-based mode from Juniors personal postpaid account by the off line charging system. The VT call between Junior and Mary is charged with media component-based mode from Juniors personal prepaid account by the online charging system. With the business scenario discussed above, we will give a total solution for IMS OSS/BSS to support it in the following paragraph.

3. SOLUTION
3.1 Solution overview
In order to meet the OSS/BSS requirements of the given scenarios in Section 2, we will propose a total solution to solve it, shown as figure 3.1, which gives the architecture of the total solution of OSS/BSS for IMS services.

Figure 3.1: Architecture of OSS/BSS for IMS

Besides the IMS network (HSS, AS, OCS, PCC are included), just as shown in the figure 3.1, there are mainly 4 function entities in the IMS OSS/BSS, which are respectively Product Management, CRM, Billing/Charging and Service Management. Product Management is the organizations approach to the process of developing, managing and marketing its products offerings to the customer. Product Management is about identifying what products to sell, what they are comprised of, who they are sold to, how they are sold, supported and serviced, how they perform in the market and how they are managed through to retirement. CRM encompasses the end to end lifecycle of the customer, from customer initiation/acquisition, sales, ordering and service activation, customer care and support, proactive campaigns, cross sell/up sell and retention/loyalty. Moreover, it needs make sure of the SLA of product provided to customers. Billing/Charging function in the IMS OSS/BSS plays an important role in the system. After customers subscribing and using the IMS services, it collects CDRs

from IMS core network, and disposes them. Then it charges the fees from accounts of the customers and provides the bills to the customers. Service Management is one of the most important functions in IMS OSS/BSS. Its focus is on service delivery and management as opposed to the management of the underlying network and information technology. Some of the functions involve shortterm service capacity planning; the application of a service design to specific customers or managing service improvement initiatives. These functions are closely connected with the day-to-day customer experience. Moreover, it is accountable to meet, targets set for IMS service quality, including process performance and customer satisfaction at a service level, as well as service cost. The work flow of this total solution is given in figure 3.2.

Figure 3.2: Work flow of OSS/BSS for IMS

3.2 Solution in details 3.2.1 Business process

A business flow is a complex Service Logic for a real business, for example, we will register a new user in system, so we need to check some conditions before store some information to our database, figure 3.3 is a diagram about create a user.

Figure 3.3: Work flow of creation

a user

Services in a distributed environment must often present different credentials to various applications (or services) that they want to use. For example, a Web service that operates inside your enterprise boundary may use functionality that is provided
9

by a service that is hosted by another company; to access an external service, your service usually presents secondary credentials. These secondary credentials are different from the credentials that your service uses inside your enterprise. Identity Manager uses Single Sign-on (SSO) to provide an encrypted store for secondary credentials that are used by your services. The SSO service enables you to store the various credentials that identify a user, and associate them with the various Web services that require these credentials. The CSF uses the username that is specified in the Persona as the key into this identity store, and retrieves the credentials for a specified service. For example, if a session, which has a Persona with a primary username of hss@bplatform.com.cn routes a message to the HSS service, the session can determine the credentials to apply to the message by examining the information in the identity store. The information for a specific user is referred to as a user map. This example is shown in the following figure:
Use na e r m P ssw a ord hss@bplatform.com.cn Pa$$w0rd

Se ice rv HSS Service PBR Service SoftDA Service ...

P a Use ID rim ry r hss@bplatform.com.cn pbr@bplatform .com .cn softda@bplatform.com.cn ...

Se conda Use ID ry r hss pbr softda ...

P ssw a ord Pa$$w0rd Pa$$w0rd Pa$$w0rd ...

Manager using Single Sign-on (SSO) Before using IMS services customers should subscribe IMS services from the CRM. Figure 3.5 shows the subscribing process of IMS customers.
PS: SDN (service dialing number)

Figure 3.4: Identity

10

Customer submits a service request

New Account

No

Account exists

Yes Get Offer/Product Catalog

SDN Selection

Automatic Assigned SDN

Assigned PUI and PVI

Customer Select the Related Product

Subscription Fee Collection

Return Receipt Printing

Order Submission

Figure 3.5: IMS New Connection flow

It is the general process of IMS new connection. We can take Scenario 2 as an example. For Scenario 2, according the special charging rules, some details are described as following.
11

1. The customer information and account information ( for example, Junior has two account, one is for prepaid, the other is for postpaid), Mary and Juniors company account (although not used in scenario 2) must be input into system. 2. Juniors new connection selects the prepaid account of him. 3. Marys new connection selects Juniors postpaid account as her default account. 4. Before starting of business scenario 2, we first recharge to Juniors prepaid account to make sure that it has enough money to start the VT call. The online charging flows of VT are shown as following charts. Online charging for VT service is session-based, including three flows, i.e., sessioninitial, session-update, session-termination. The following flow charts show how the messages transfer from IMS GWF to each modules of online charging respectively.

Figure 3.6: Session-Initial Flow

12

Figure 3.7: Session-Update Flow

13

Figure 3.8: Session-Termination Flow

3.2.2 System function

3.2.2.1 System Function Overview
In the Seamless OSS/BSS for IMS Services (Phase II), the functionality is extended to broader area, especially from the service delivery and real time charging perspective. Following paragraphs will describe the function in details.

14

Figure 3.9: System Function Diagram

1.

Business Supporting System

The following key BSS functionalities are provided in the project: Customer Creation Customer/Subscriber will be created from CRM or customer self service portal. Customer information will include customer name, gender, contact, email, etc basic information. Customer Relationship Creation Relationship between customer/subscribers will be setup at initiate and maintain at change level. In this scenario, Mary is girlfriend of Bob and Sam is colleague of Bob, these relationship are buildup by CSR or by subscriber self through self service portal. Product Management Product creation and product configuration are the functions we provide. We will not provide a full product life cycle management because it is out of scope. Customer can base on their needs to select preferred product or product offering. Order Management Accordingly the corresponding rating plan will be assigned to the customer, the order contract should be signed be both customer and operator then the order is placed and the provisioning process will be invoked. Real Time Charging Real time charging or called online charging will real time collect charging information for IMS switch through online charging gateway, the information will be passed to frond end system to let customer know how many balance they have and the billing system will real time knows the balance and outstanding
15

information for the specific customer and the service group. Convergent Billing The system will merge the post-paid and prepaid information together to specific customer or service group base on the service agreement. Charging can be transferred among different account also according the service agreement.
2.

Operation Supporting System

Service Activation Service activation is an end to end process. Available IMS services should be activated first at IMS switch. The services should be also activated in service delivery platform and SIP server as well. In CRM product catalog, there should be corresponding listed product for customer selection. In the phase, the services Instance Message (IM), Presence (PS), Video Telephony (VT), Multimedia Ring Back Tone (MRBT), Multimedia Colorful Identify (MMCI) and Dynamic Address Book (DAB) are activated at IMS switch, then the above services and Presence Based Routing (PBR) activated at SDP, and all services are listed as the selectable services in CRM. In billing, every service has a rating plan and billing rule, clear state which is postpaid service and which is prepaid service. Service Fulfillment Whenever a customer selects a service, the service should be fulfilled from end to end. First, in CRM, the customer will be connected to a specific service package (product plus rating plan), then in SDP, the service package should be dispatched to activated services, then billing system, billing account has the right rating plan assigned, and the IMS should fulfill the customer service when it get session information from SDP. For Scenario 1, Bob and Sam subscribe PS, MRBT, MMCI, PBR and VoIP services in CRM system, the service package includes billing information. Billing system will find the right billing and rating plan for them, the PS, MRBT, MMCI and PBR are assigned to Bob and Sams post paid account, VoIP is assigned to their prepaid account. Service Execution Service execution goes to another way than the service activation. The service execution will first go from a customer to IMS switch, the switch base on the business rule to route the service request to right destination, for example, the service is routed to corresponding IMS/AS and then route to SIP application server if needed, if the call can be proceeded, the billing system will be invoked to collect the detail CDR, if some services are real time charge, real time charge is also functioned. After all above checking and requests done, the real communication starts. Here below is the service execution process for scenario 1.

16

Figure 3.10: service execution process of Scenario 1

Service Change Management Whenever a customer changes his/her services, the system can make changes quickly according the requests. For example, add new services, cancel existing services and modify current services, can be fulfilled from multiple layers, from CRM, Billing, SDP and IMS switches at the synchronous manner.
3.

Service Delivery Platform

In this catalyst, the service delivery functions are mainly residing in the following areas: Session Management The Session Management plays an important role in SDP. All messages that are sent by using SDP pass through the Session Web service, which routes these messages to the appropriate destinations. In the catalyst, the Session control contains three Web services: Session, SessionAdmin, and SessionManagerAdmin. Each of these services has a specific role in managing the lifetime of a session and controlling message routing.
17

The position of Session control among other SDP function components is shown in below chart:

Figure 3.11: Session control among other SDP function components

Service logic Service Logic creates and defines the business rules that will be applied when processing requests in SDP applications. Service logic will define the inter-relationship and execution sequence among the defined services. A Service Logic can be a Web service that provides the business logic to drive a service application. The core Session Control, Identity Manager, Profile Manager, and Service Catalog provide a collaboration context through which Web services can be aggregated. A Service Logic can provide the rules and sequencing steps that define the interaction of Web services in a composite service application; it drives the application. In the SDP environment, the core functions provide a collaboration context, while the Service Logic provides orchestration for services that participate in the collaboration. The following diagram shows the role played by a Service Logic component in a service application running on the catalyst.

18

Figure 3.12: Service Logic component in a service application

Service Identity Management The Identity Management tracks user identities and provides single-sign on (SSO) management. Identity Management provides functionality that enables a service to create users, provision resources, and control access to those resources by using the underlying Active Directory service. Identity Manager also supports the Single Sign-On functionality of the Session component by providing an encrypted store for secondary credentials. Services that operate in SDP environment often manage one or more resources that they provide to users or other services. Such services must be able to provision the resource that they manage and ensure that only authorized entities can access it. The Identity Manager provides calls that enable a service to create users, groups, and organizational units in Access Directory and to grant privileges to users by adding them to the appropriate groups and organizational units. Service Catalog Service Catalog component is a Universal Description, Discovery, and Integration (UDDI) registry that contains a list of all the Web services available in a CSF distributed application. So that you can access this registry from your code, the Service Catalog exposes the Microsoft Windows Server 2003 Enterprise UDDI Services as a Web Services Enhancements 3.0 Web service. The Service Catalog stores information about the XML Web service participants that you have registered for your CSF distributed application. This includes all participant manifest properties, such as the Uniform Resource Identifiers (URI) of the Web service, its name, Web Service Definition Language URI, credential and authentication types, and the policy document to associate with the Web service, if
19

any. Additionally, the Service Catalog provides an authorization capability that enables you to secure access to the catalog to a specific set of developers. For example, you can allow access to core network Web services for developers within your organization and not allow developers outside of your organization to access those Web services. In most scenarios, you use the Service Catalog component to get a list of Web service URIs from a list of Universal Unique Identifiers that is mapped to those Web services. You should always store the physical URI of a specific Web service in the Service Catalog, and your application should read that URI from the Service Catalog before it calls the Web service. By designing your application in this way, if you change the URI for the Web service, you only change it in the Service Catalog and not in multiple locations. You can discover Service Catalog through all common Web service discovery mechanisms, including UDDI, WS-Discovery, WS-Inspection and DISCO. Following diagram shows how create and publish a Presence-based Service to Service Catalog:
Cre tePBR Se a rvice (Se rviceCre tion) a

DefinePBR Base Info

Se rviceCa log ta DefineBusinessFlow

Publish PBR Service

Figure 3.13 Service Creation Service Creation Steps: 1 Define PBR Service Provide some Meta data, for example, the Service name, URI, contact, t-Model, etc. 2 Define Business Flow Define a routing table or a Service Logic if we need a complex process 3 Publish PBR Service to Service Catalog Store such information to Service Catalog Service order Inventory We will collect all of order information from the CRM portal and store this information to a Service order Inventory;
20

Exe cutePBR Se rvice (Se iceExe rv cution )

Query Service

Se ice orde inv ntory rv r e Load Manifest

ExecuteRouting & Business Flow

Figure 3.14 Service execution These requests will be processed in order. 1 Query Service Query a Service from Service Catalog, e.g. Presence-based Routing Service 2 Load Manifest Load and generate a manifest and routing table for business flow. 3 Load/Execute Routing and Business Flow Execute a routing policy or a service logic for a real business request. Profile Management The Profile Manager tracks profile information for users and participants that connect to distributed application by using a Resource Definition Framework (RDF) database. Well Enabled Services A Well-enabled Service (WES) is a Web service that presents a contract to other Web services that is based on a set of standard interfaces that are recommended by this catalyst environment. The project provides an environment that enables rich levels of interaction between Web services. The WES specification defines interfaces and operations that enable a Web service to participate fully in this environment. A WES presents a uniform model for provisioning resources, exposing these resources to other Web services, metering resource usage, and monitoring the health of resources.

21

Figure 3.15: Well-enabled Service

3.2.3 Information model

3.2.3.1 SID Overview
To classify the data in a usable fashion, the SID is designed as a layered framework, which partitions the shared information and data into eight domains. At the top layer, each of the eight SID domains is aligned with the eTOM business process framework. Within each domain there is a high degree of cohesion between the business entities, and between the domains, there is a loose coupling. This arrangement enables segmentation of the total business problem into manageable pieces and allows resources to be focused on a particular area of interest. In other words, for a particular eTOM business process that you are automating, you can identify the shared information and data that is needed to support that process. Within each SID domain, multiple Aggregate Business Entities (ABEs) are defined. ABEs are the containers for a series of business entities related to their respective areas. Each business entity contains finer-grained business entities and their associated attributes. Using this layered approach, the large universe of information is packaged into understandable, usable pieces. The sources for the SID model include a variety of industry models, as well as those contributed by TM Forum member organizations. SID in Seamless OSS/BSS for IMS Services Catalyst Project is shown as following.

22

Product Management

Product Domain

Customer Relationship Management

Customer Domain

Service Management & Operations

Service Domain

Resource Management & Operations

Resource Domain

Figure 3.16: Key domains of SID

Figure 3.17: Business View of Catalyst

Product Bundles

Ultimate Product Bundle

Advanced Product Bundle

Products

Basic Product

MRBT Product

MMCI Product

Presence Product

More Products...

Services

Base Service

VoIP Service

MRBT Service

MMCI Service

Presence Service

More Services ...

Resource

HSS

PSS

UP10

More... IMS Network More...

IP Network

Figure 3.18: Inheritance Hierarchy of Catalyst information Model

In Seamless Catalyst Phase II, we have rebuilt our information model based on SID
23

again. They are faster, easy, and reusable than Phase I. We have used four domains to build up our system:
Product customer Service Resource

3.2.3.2 Product

Figure 3.19: Business View of Product (includes Product Bundle)

Ultimate Product Bundle

Advanced Product Bundle

Basic Product

MRBT Product

MMCI Product

Presence Product

More Products ...

Figure 3.20: Inheritance Hierarchy of Product

Business entities in the Product domain have a close relationship with business entities in the Service and Resource domains. While Product business entities represent what the market sees of a providers offerings, Service and Resource business entities represent the realization of the offerings from a providers perspective. For example, a Multimedia Ring Back Tone ProductOffering is realized by two CustomerFacingServices, one is a service registration to the PSS; the second is a service activation service to the UP10.

3.2.3.3 Customer Domain

Customer are the center of any enterprise. The Customer Domain includes all data and contract operations associated with individuals or organizations that obtain products from an enterprise, such as a service provider. It represents of all types of contact with the customer, the management of the relationship, and the administration of customer data. The Customer Domain also includes data and contract operations related to the customer bills for products, collection of payment, overdue accounts,

24

and the billing inquiries and adjustments made as a result of inquiries. In our solution, we propose referring to TMF GB922-2.

3.2.3.4 Service Domain

Figure 3.21: Business View of Service

Business entities in the Product domain represent what is offered to the market. This domain deals with such things as the development, promotion, pricing, and retirement of product offerings, as well as instances of offerings procured by customers and others. Business entities in the Service and Resource domain represent (among other concepts) how products offered to the market are implemented. Services are procured by the market, but their representation is via a ProductOffering. This gives rise to a fundamental difference between services that are Customer Facing and services that are Resource Facing. As we will see, there is a marked difference between services that are used internally by the enterprise offering a product versus services that are represented as product offerings. It is therefore very important to differentiate between these two different types of services (as well as their relationship with Products) in our Service model. From a definition perspective, a Product (Offering) is an externally facing representation of a Service and/or Resource procured by the market; for example, a rich content of a colorful identity. In this case, the Customer buys the Product, which may require dedicated hardware to run the Services that make up the Product. In this view, a Service is an intangible realization of a Product or something provided in support of a Product; for example, a data connection used to transport the rich content of colorful identity to a customers PDA, an activation service provided for enable this value-added service, or specific Quality of Service (QoS) settings that are required to provide an acceptable end-user experience watching the content of the colorful identity.

3.2.3.5 Resource Domain

25

Figure 3.22: Business View of Resource

HSS

PSS

UP10

More... IMS Network More...

IP Network

Figure 3.23: Inheritance Hierarchy of Resource

Business entities in the Product domain represent what is offered to the market. This domain deals with such things as the development, promotion, pricing, and retirement of product offerings, as well as instances of offerings procured by customer and others. A Resource is part of an enterprises infrastructure utilized by a Service or a good procured by the market in the form of a Product. Business entities in the Resource domain represent (among other concepts) how products offered to the market are implemented. Resources are used to support Services offered by the Product, both physically as well as logically. For example, a BOSS Application needs a interface machine to communicate with network element. The network element is a physical entity one can see it, touch it, and hold it. In contrast, protocols are logical entities one cannot see a packet being communicated between two entities. However, both of these are needed in order to process a business request.

4. RELATED INTERFACES
4.1 Interfaces overview
In this section, we will give the total high level interfaces involved in the OSS/BSS for IMS which is provided in this solution. The architecture OSS/BSS for IMS is described in the following figure, and almost all the related interfaces are described in the following figure.
26

Figure 4.1: Related interfaces in architecture of OSS/BSS for IMS

As shown in figure 4.1, there are totally 11 interfaces (reference points) relating to the seamless OSS/BSS for IMS. The I1 reference point resides between the Product Management and the CRM. This reference point enables transport of application level information from Product Management (CRM) to CRM (Product Management). The I2 reference point resides between the Billing/Charging and the CRM. This reference point enables transport of billing and charging level information from Billing/Charging (CRM) to CRM (Billing/Charging). The I3 reference point resides between the CRM and the Services Management. This reference point enables transport of application and service level information from CRM (Services Management) to Services Management (CRM). The I4 reference point resides between the Services Management and the IMS. This reference point enables transport of IMS services and control information from Services Management (IMS) to IMS (Services Management). The I5 reference point resides between the Services Management and the PBR AS. This reference point enables transport of Services Management level information from Services Management (PBR AS) to PBR AS (Services Management). The I6 reference point resides between the PBR AS and the IMS. This reference point enables transport of IMS services and control level information from IMS (PBR AS) to PBR AS (IMS). The I7 reference point resides between the IMS and the OCS. This reference point enables transport of charging level information from IMS (OCS) to OCS (IMS). The I8 reference point resides between the IMS and the Billing/Charging. This reference point enables transport of billing and charging level information from Billing/Charging (IMS) to IMS (Billing/Charging). The I9 reference point resides between the OCS and the Billing/Charging. This reference point enables transport of billing level information from OCS (Billing/Charging) to Billing/Charging (OCS). The I10 reference point resides between the Services Management and the Service Order Inventory. This
27

reference point enables transport of service order level information from Services Management (Service Order Inventory) to Service Order Inventory (Services Management). The I11 reference point resides between the Services Management and the Service Catalog. This reference point enables transport of services catalog level information from Services Management (Service Catalog) to Service Catalog (Services Management).

4.2 Interfaces 4.2.1 I1

[Definition] CRM get product/offer catalog from product management system when the customer want to subscribe a new one or change the product/offer. [Protocol] SOAP [Sending] Product Management [Receiving] CRM [Content] Get Offer Information
No. 1 2 3 4 5 6 Field name ID OfferName Comments
EffDate ExpDate ProdList

Description Offer ID Offer name The comments of the Offer The effective date The expire date The List of independent product ID

Data type
Long String String Date Date Long[ ]

length
1~6 1~60 1~4000

Memo

Get Independent Product Information

No. 1 2 Field name ID ProdSpecName Description Product ID Independent
28

Data type
Long

length
1~6 1~60

Memo

Product

String

3 4 5

Comments
EffDate ExpDate

name The comments of the product The effective date The expire date

String Date Date

1~4000

Get Dependent Product Information

No. 1 2 3 4 5 Field name ID ProdSpecName Comments
EffDate ExpDate

Description Product ID Dependent Product name The comments of the product The effective date The expire date

Data type
Long String String Date Date

length
1~6 1~60 1~4000

Memo

Get PricePlan Information

No. 1 2 3 4 5 Field name OfferID ProdID Comments
EffDate ExpDate

Description Offer ID Product ID The comments of the product The effective date The expire date

Data type
Long Long String Date Date

length
1~6 1~6 1~4000

Memo

4.2.2 I2
[Definition] CRM collects all the information about new connection and generate order and send order information to provisioning/service management system. When the provisioning finished, the CRM get the feedback from provisioning system. At the same time, CRM should synchronize the data to billing system. [Protocol] SOAP [Sending] CRM [Receiving] Billing [Content] New Connection
No.
1

Field name
MSISDN

Description
MSISDN number selected

Data type
String

length
1~60

Memo

29

by user. Support New connection in batch, with an & to compart starting MSISDN and ending MSISDN 2 3 4 5 OfferID ProdID PricePlanID CertType Offer ID Prod ID Price Plan ID Certificate type code, which can be obtained by querying customers certificate type interface Legal certificate number owned by a customer. According to CertType and CertNo, system will find existed customer at first, if there is no corresponding one, it will create new customer. Customer name using this service; new customer shall fill in this parameter when opening an account. Installation address: it must be filled when applying for cable netwok. Code number of paid account. The system will match the existing account according to the code; it will create a new account when there is no corresponding account Private Identify List of PUIs The order complete date Long Long Long String 1~6 1~6 1~6 1~3

CertNo

String

1~36

CustomerName

String

1~36

Address

String

1~120

AccountCode

String

1~60

10 11 12

PVI PUIList CompleteDate

String String Date

1~60 1~60

4.2.3 I3
[Definition] CRM collects all the information about new connection and generate order and send order information to service management system. [Protocol] SOAP [Sending] CRM [Receiving] Service management
30

[Content] New Connection

No.
1

Field name
MSISDN

Description
MSISDN number selected by user. Support New connection in batch, with an & to compart starting MSISDN and ending MSISDN Offer ID Prod ID Price Plan ID Certificate type code, which can be obtained by querying customers certificate type interface Legal certificate number owned by a customer. According to CertType and CertNo, system will find existed customer at first, if there is no corresponding one, it will create new customer. Customer name using this service; new customer shall fill in this parameter when opening an account. Installation address: it must be filled when applying for cable netwok. Code number of paid account. The system will match the existing account according to the code; it will create a new account when there is no corresponding account Private Identify List of PUIs The ID of the order

Data type
String

length
1~60

Memo

2 3 4 5

OfferID ProdID PricePlanID CertType

Long Long Long String

1~6 1~6 1~6 1~3

CertNo

String

1~36

CustomerName

String

1~36

Address

String

1~120

AccountCode

String

1~60

10 11 12

PVI PUIList OrderID

String String Long

1~60 1~60 1~12

4.2.4 I4
1 Provisioning [Definition] Provisioning is a set of foundation components of IMS network for service activation. All of communications are based on the man-machine language between
31

the BOSS Application and the Interface Machine. It contains two abstract blocks, one is Message Exchange module, and another is Business Logic Module. Message Exchange module is transporter for sending and receiving message between Interface Machine (It looks like a server-side application) and BOSS Application (It looks like a client-side application). Business Logic is an Operation Combiner for combines some complex workflows into a number of simple Actions and exposes them to high level application. [Protocol]
Man-machine language (MML)

[Sending]
A readable MML command from stream segment
`SC`01341.00ZXWN1000HLRAGENT00000006DLGCONFFFF00000001TXBE G FFFFAdd NewPVI:PVI=tianjunyutest5@aplatform.com.cn,IregFlag=1,PVIType=0,Ki=A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA,SecVer=30,AMF=0000,KeyID= 0,ConcealSQN=0,ReSynCSQN=0,PECFN=charge.zte.com.cn,PCCFN=charge .zte.com.cn,SECFN=charge.zte.com.cn,SCCFN=charge.zte.com.cn E0BCDBE0

You can get more and detailed information from a documentation provis.docx because some of MML-based stream are unreadable.

[Receiving]
For more information about MML-based command of Provisioning, see provis.docx

[Content]
For more information about MML-based command of Provisioning, see provis.docx

2 Activation [Definition] Caller can use it to open or close a base service and activate or deactivate some value-added services. Activation is a service-based interface. It is a part of provisioning and built on provisioning also. For more information about Provisioning, see Provisioning. [Protocol]
SOAP-based Web Services For more detailed information about Web Services, visit it at: <http://www.w3.org/2002/ws/> For more information about SOAP, visit it at: <http://www.w3.org/tr/soap/>

[Sending]
SOAP 1.1
POST /activationservice.asmx HTTP/1.1 Host: localhost

32

Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: "http://tempuri.org/Activate" <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <Activate xmlns="http://tempuri.org/"> <request /> </Activate> </soap:Body> </soap:Envelope>

SOAP 1.2
POST /activationservice.asmx HTTP/1.1 Host: localhost Content-Type: application/soap+xml; charset=utf-8 Content-Length: length <?xml version="1.0" encoding="utf-8"?> <soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"> <soap12:Body> <Activate xmlns="http://tempuri.org/"> <request /> </Activate> </soap12:Body> </soap12:Envelope>

[Receiving]
SOAP 1.1
HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: length <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

33

<soap:Body> <ActivateResponse xmlns="http://tempuri.org/"> <ActivateResult> <Succeeded>boolean</Succeeded> <StatusCode>int</StatusCode> <Status>string</Status> <Tag /> </ActivateResult> </ActivateResponse> </soap:Body> </soap:Envelope>

SOAP 1.2
HTTP/1.1 200 OK Content-Type: application/soap+xml; charset=utf-8 Content-Length: length <?xml version="1.0" encoding="utf-8"?> <soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"> <soap12:Body> <ActivateResponse xmlns="http://tempuri.org/"> <ActivateResult> <Succeeded>boolean</Succeeded> <StatusCode>int</StatusCode> <Status>string</Status> <Tag /> </ActivateResult> </ActivateResponse> </soap12:Body> </soap12:Envelope>

[Content]
Field table of Request No. Field name 1 ActivationMessage Description Message is an abstract type for all activation communications between client and server. A root object of Request Request is an Activation Message sent by client. A root object of Response
34

Data type Object

length

Memo

ActivationRequest

Object

ActivationResponse

Object

4 5 6 7 8 9

ServiceRequest BaseServiceRequest ExtendedServiceRequ est GenericServiceReques t* MrbtServiceRequest MmciServiceRequest

Response is an Activation Message sent from service/server. All businesses of service related are derived from it. Base Service

Object Object Object

Future reserved type Multimedia Ring Back Tone Service Multimedia Colorful Identity Service VoIP Service

Object Object Object Object Data type Boolean length Memo

10 VoipServiceRequest Field table of Response No. Field name Description 1 Succeeded Operation Result true/false 0/1 true, no error occurred false, an error occurred, see the StatusCode for more information 2 StatusCode 200: OK 400: Calling Error 500: Internal Server Error 600: Global Error 3 Status * Status description. Future reserved property 4 Tag * Tag an object as a context. Future reserved property

int bit)

(32

String (char *) Object (void *)

4.2.5 I5
[Definition] I5 reference point enables Service Management system to deliver PBR policies for various users to PBR AS which would route the calls based on those policies. [Protocol] SOAP [Sending] Service Management [Receiving] AS/PBR [Content]
35

No. 1

Field name Action

2 3 4 5 6 7 8

Name Uri conditions Timespan Start To Presence

9 10

forwarding uri

Description The action to indicate whether user has changed PBR policy setting or reset the setting Action name The SIP URI of call-in user Conditions Lifecycle of an Action Start date/time End date/time Presence status of current user Enumerable values: Online = 0x0002 Busy = 0x0003 Away = 0x004 Offline = 0x0001 Forwarding Forward URI

Data type XML Element

length

Memo

String (char *) String (char *) XML Element XML Element Date/Time String Date/Time String Enumeration (Integer)

XML Element String

4.2.6 I6
[Definition] When S-CSCF receives the incoming call, the user of which has subscribed PBR service, it then forwards the call to PBR AS via ISC interface. Furthermore, after PBR AS getting the request, it sends the query of caller status to PS server via SIMPLE interface. Finally, PBR AS will determine what destination the call will reach by resetting the request URI of the incoming request and return the request back to SCSCF. [Protocol] ISC & SIMPLE, which both are SIP extension. [Sending] ISC: INVITE SIMPLE: SUBSCRIBE [Receiving]

36

ISC: INVITE SIMPLE: NOTIFY [Content] The detail ISC and SIMPLE interface can be seen from following documents 3GPP TS 24.229 OMA-AD-IM_SIMPLE-V1_0_0-20060117-D

4.2.7 I7
[Definition] The I7 reference point resides between the IMS and the OCS. This reference point enables transport of charging level information from IMS (OCS) to OCS (IMS). CCR (Credit-Control Request) and CCA (Credit-Control Answer) are the main information transferred of I7. [Protocol] Diameter CC [Sending] IMS Gateway Function [Receiving] OCS [Content] CCR
No. 1 2 3 4 5 6 7 8 9 10 11 12 Field name Session-Id Origin-Host Origin-Realm Destination-Realm Auth-Application-Id Service-Context-Id CC-Request-Type CC-Request-Number Destination-Host Event-Timestamp Subscription-Id Subscription-Id-Type Description Session ID Origin Host For Identification Realm of the originator the realm the message is to be routed to Support for Authorization & Authentication unique identifier of the Diameter credit-control service contains the reason for sending the credit-control request message identifies this request within one session Destination Host Timestamp identify the end user's subscription which type of identifier is carried by the Subscription37

Data type string string string string int32 string int32 uint32 string uint32 group Int32

length

Memo

13 14

Subscription-Id-Data Multiple-ServicesIndicator Multiple-ServicesCredit-Control Used-Service-Unit CC-Time Rating-Group Service-Information IMS-Information Role-Of-Node Node-Functionality User-Session-ID Calling-Party-Address Called-Party-Address IMS-ChargingIdentifier

15

16 17 18 19 20 21 22 23 24 25 26

Id identify the end user indicates whether the Diameter credit-control client is capable of handling multiple services contains the AVPs related to the independent creditcontrol of multiple services feature amount of used units measured length of the requested, granted, or used time in seconds the identifier of a rating group Service Info IMS Info Role of the AS/CSCF The function of the node Session identifier A number B number IMS Charging Identifier

string int32

group

group uint32 uint32 group group int32 int32 string string string string

CCA
No. 1 2 3 4 5 6 7 8 9 10 Field name Session-Id Result-Code Origin-Host Origin-Realm Auth-Application-Id CC-Request-Type CC-RequestNumber Multiple-ServicesCredit-Control Granted-ServiceUnit Tariff-Time-Change Description Session ID Result Code Origin Host For Identification Realm of the originator Support for Authorization & Authentication contains the reason for sending the credit-control request message identifies this request within one session contains the AVPs related to the independent credit- control of multiple services feature the amount of units that the Diameter credit-control client can provide includes the time in seconds since January 1, 1900, 00:00 UTC, when the tariff of the service will be changed length of the requested, granted, or used time in seconds the number of service-specific
38

Data type string uint32 string string int32 int32 uint32 group group uint32

length

Memo

11 12

CC-Time CC-Service-

uint32 uint64

Specific-Units 13 14 15 16 17 18 19 20 21 Rating-Group Validity-Time Result-Code Cost-Information Unit-Value Value-Digits Exponent Currency-Code Cost-Unit

units (e.g., number of events, points) given in a selected service the identifier of a rating group the identifier of a rating group Result Code Cost Information specifies the units as decimal value the significant digits of the number contains the exponent value to be applied for the Value-Digit Currency Code Set to display a human readable string to the end user

uint32 uint32 uint32 group group int64 int32 uint32 string

4.2.8 I8
[Definition] The interface is between IMS core network and billing system, which mainly provides CDRs to billing system. [Protocol] FTP [Sending] CGF [Receiving] Billing system [Content]
In Scenario 2, a CDR of IM is shown as following. No. 1 3 4 5 6 7 8 9 10 11 Field name Operate Type Card NO Services Key Calling number Called number Start Time Stamp Stop Time Stamp Charging Flag Field 1 Field 2 Description 0deduction Account name Services Key INFO Calling number Called number Time stamp Time stamp 0 caller charging (send) 1called charging (receive) The number of sending IM The number of receiving IM Data type length Memo

39

4.2.9 I9
[Definition] The I9 reference point resides between the OCS and the Billing/Charging. This reference point enables transport of billing level information from OCS (Billing/Charging) to Billing/Charging (OCS). [Protocol] FTP [Sending] OCS [Receiving] Billing/Charging [Content]
No. 1 Field name Record Type Description Indicate this CDR is an AS CDR. The parameter is derived from the Node functionality parameter. Values: s-CSCFRecord (63), p-CSCFRecord (64), i-CSCFRecord (65), mRFCRecord (66), mGCFRecord (67), bGCFRecord (68), aSRecord (69). This parameter, when present, indicates that information from retransmitted Diameter ACR has been used in this CDR. Specifies the SIP-method for which the CDR is generated. Only available in session unrelated cases. Corresponding to the SIP-Event-Type AVP. Indicates the role of the AS. Corresponding to the Role-of-node AVP. The address of the node providing the information for the CDR. This may either be the IP address or the FQDN of the IMS node generating the accounting data. Corresponding to the Origin-Host AVP. The Session identification. For a SIP session the Session-ID contains the SIP Call ID (defined RFC 3261). Data type len gth Me mo

2 3

Retransmissio n SIP Method

4 5

Role of Node Node Address

Session ID

40

Corresponding to the User-Session-ID AVP. 7 Calling Party Address The address (Public User ID) of the party requesting a service or initiating a session. This field holds either the SIP URL (according to RFC 3261) or the TEL URL (according to RFC 2806) of the calling party. Corresponding to the Calling-Party-Address AVP. In the context of an end-to-end SIP transaction this field holds the address of the party (Public User ID) to whom the SIP transaction is posted. Corresponding to the Called-Party-Address AVP. The time stamp which indicates the time at which the service was requested. Corresponding to the SIP-Request-Timestamp AVP in the START/EVENT ACR. The time stamp which reflects either: successful session set-up, a session unrelated service, an unsuccessful session set-up and an unsuccessful session unrelated request. Corresponding to the SIP-Response-Timestamp AVP in the START/EVENT ACR. The time at which the service delivery was terminated. It is Present only in SIP session related case. Corresponding to the SIP-Request-Timestamp AVP in the STOP ACR. The time the CCF opened this record. Present only in SIP session related case. The time the CCF closed this record. The identification of the home network (originating and terminating) if exchanged via SIP signalling. Corresponding to the Inter-Operator-Identifier AVP. Corresponding to the Originating-IOI AVP Corresponding to the Terminating-IOI AVP A unique record number created by this node. The number is allocated sequentially for each partial CDR (or whole CDR) including all CDR types. The number is unique within the CCF. A sequence number employed to link the partial records generated by the CCF for a particular session. A reason for the close of the CDR.

Called Party Address

Service Request Time Stamp

10

Service Delivery Start Time Stamp

11

Service Delivery End Time Stamp

12 13 14

Record Opening Time Record Closure Time Inter Operator Identifiers

15 16 17

Originating IOI Terminating IOI Local Record Sequence Number Record Sequence Number Cause For Record Closing

18 19

41

20 21

Incomplete CDR Indication IMS Charging Identifier

Additional diagnostics when the CCF detects missing ACR. The ICID generated by the IMS node for the SIP session. Corresponding to the IMS-Charging-Identifier (ICID) AVP. The Session portion of the SDP data exchanged between the User Agents if available in the SIP transaction. Corresponding to the SDP-Session-Description AVP. A field comprising several sub-fields associated with one media component. It may occur several times in one CDR. Present only in a SIP session related case. The time of the SIP Request (usually a (Re) Invite). Corresponding to the SIP-Request-Timestamp AVP in the INTERIM ACR. The time of the response to the SIP Request (usually a 200 OK). Corresponding to the SIP-Response-Timestamp AVP in the INTERIM ACR. This is a field comprising several subfields associated with a media component. Since several media components may exit for a session in parallel, these subfields may occur several times. Corresponding to the SDP-Media-Component AVP. The name of the media available in the SDP data. Corresponding to the SDP-Media-Name. The attributes of the media available in the SDP data. Corresponding to the SDP-Media-Description. The GCID generated by the GGSN for a GPRS PDP context. Corresponding to the GPRS-Charging-Id. Indicates if the called party has requested the session modification and it is present only if the initiator was the called party. Authorised QoS (defined in TS 23.207 / TS 29.207). The control plane IP address of the GGSN that handles one or more media components of an IMS session. Corresponding to the GGSN-Address AVP. The reason for the failure case of the service request (the SIP error code from the SIP-Method AVP). Present only in unsuccessful cases. Service specific data. This field comprising several subfields describing
42

22

SDP Session Description

23

List of SDP Media Components SIP Request Timestamp

24

25

SIP Response Timestamp

26

SDP Media Components

27 28

SDP Media Name SDP Media Description GPRS Charging ID Media Initiator Flag Authorised QoS GGSN Address

29

30 31 32

33 34 35

Service Reason Return Code Service Specific Data List of

Message Bodies 36 37 Content-Type ContentDisposition

38 39

ContentLength Originator

the data that may be conveyed end-to-end in the body of a SIP message. Since several message bodies may be exchanged via SIP-signalling, this grouped field may occur several times. The subfield of Message Bodies. It holds the MIME type of the message body, such as application/zip, image/gif, audio/mpeg, etc. The subfield of Message Bodies. It holds the content disposition of the message body inside the SIP signalling, indicates that the body part should be displayed or otherwise rendered to the user. Values are: session, render, inline, icon, alert, attachment, etc. The subfield of Message Bodies. It holds the size of the data of a message body in bytes. The subfield of the "List of Message Bodies". It indicates the originating party of the message body.

4.2.10 I10
[Definition] The I10 reference point resides between the Services Management and the Service Order Inventory. This reference point enables transport of service order level information from Services Management (Service Order Inventory) to Service Order Inventory (Services Management). [Protocol] SOAP [Sending] Services Management (Service Order Inventory) [Receiving] Service Order Inventory (Services Management) [Content]
No. 1 2 3 4 Field name Order no. Status StartTimeStamp EndTimeStamp Description Order number Data type length Memo

4.2.11 I11
[Definition] The I11 reference point resides between the Services Management and the Service Catalog. This reference point enables transport of services catalog level information
43

from Services Management (Service Catalog) to Service Catalog (Services Management). [Protocol] SOAP [Sending] Management (Service Catalog) [Receiving] Service Catalog (Services Management). [Content]
No. 1 2 3 Field name Service URI Service name Type Description Web service URI Web service name Service Type Data type length Memo

5.

CONTRIBUTION GROUPS

TO

INDUSTRY

Based on experiences and observations obtained during the Seamless OSS/BSS for IMS Services catalyst project implementation, this white paper will provide valuable information about IMS OSS/BSS to the following industry groups. The information will be also documented using the IIS catalyst documentation as well as the receiving bodys feedback form. The standards within scope of this project include: ETSI TISPAN - WG8 NGN OSS Service Interface (NOSI). 3GPP/3GPP2: The definition of subscriber and user information in HSS The interface between HSS of 3GPP/3GPP2 and provisioning of TM Forum The interface between CGF/AAA of 3GPP/3GPP2 and UDR-collection of TM Forum The liaisons groups of 3GPP is TSG CT working group and TSG SA WG2&WG5, and the liaisons group of 3GPP2 is TSG-X WG3(MMD) working group and TSG-S WG1&WG5 working group OMA: Horizontal working groups, such as Architecture, Interoperability, and Requirements All enabler working groups that have mobile commerce or charging-related
44

requirements, for example but not limited to Messaging, Location, Presence and Availability

6. CONCLUSION
This white paper provides a total solution to OSS/BSS for IMS service, which covers almost all the subjects of IMS services lifecycle, which is very close to real commercial operation, from IMS service creation, delivering, to convergence charging, and different SIP terminals are involved. It can be used as an industry reference model for the process of IMS commercial deployment, which will promote the development and maturation of OSS/BSS for IMS.

45

APPENDIX: DOCUMENT HISTORY

It is mandatory to complete this section each time a modification is made.
Revision Version 0.1 Version 0.2 Version 0.3 Version 0.4 Version 0.5 Version 0.6 Version 0.7 Version 0.8 Date 19/03/2008 02/04/2008 06/04/2008 09/04/2008 14/04/2008 17/04/2008 24/04/2008 12/06/2008 Author Junke Wang Hongding Wang Hongding Wang Cheng Zuo ZTE Amdocs Erqiang Xiao Tianjun Yu Hongding Wang Description Drafted outline of this document Drafted Part 1, Part 2, Part 3.1, Part 4.1, Part 5 and Part 6. Drafted Part 4.2.6 Drafted Part 3.2.1, Part 4.2.1, Part 4.2.2, Part 4.2.3, Part 4.2.8 and Part 4.2.9 Drafted Part 4.2.7 Drafted Part 3.2.2 Drafted Part 3.2.1, Part 3.2.3, Part 4.2.4, Part 4.2.5, Part 4.2.10 and Part 4.2.11 Overall compilation for TMF

46