Seamless OSS&BSS for IMS_White Paper (Ver0.8)

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.............................................................................................................................................40

4.2.9 I9.............................................................................................................................................40

4.2.10 I10.........................................................................................................................................44

4.2.11 I11.........................................................................................................................................45

5. CONTRIBUTION TO INDUSTRY GROUPS...............................................................................45

6. CONCLUSION..................................................................................................................................46

APPENDIX: DOCUMENT HISTORY...................................................................................................47

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 businesses—for example, seamless wired, wireless and IP networking—and 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 today’s 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 solution’s 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 customer-centric use. (7) PBR (Presence-based Routing)

It allows incoming callers to reach an intended recipient, based on his or her

3

presence status, increases probability of a successful call completion. The use case is 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 phoneZTE 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 single-screen 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 - V300ZXV10 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 Bob’s colleague, Junior is Mary’s boyfriend. The business scenarios are shown as following.

4

Scenario 1: 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 doesn’t 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 Junior’s 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 Mary’s 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.

5

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 Bob’s 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 Bob’s company prepaid account by the online charging system.

In scenario 2, Fees relating to personal business are charged from Junior’s personal account. All the services subscribed by Mary will be charged from Junior’s personal

account. The services subscribed by Mary, such as PS, MRBT and DAB, are charged

with monthly fee from Junior’s personal postpaid account by the off line charging system.

The IM service of Mary will be charged with event-based mode from Junior’s personal postpaid account by the off line charging system.

The VT call between Junior and Mary is charged with media component-based mode from Junior’s 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.

6

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 organization’s 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

7

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 short-term 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.

8

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 [email protected] 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:

Figure 3.4: Identity 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)

10

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 Junior’s company account (although not used in scenario 2) must be input into system.2. Junior’s new connection selects the prepaid account of him.3. Mary’s new connection selects Junior’s postpaid account as her default account.4. Before starting of business scenario 2, we first recharge to Junior’s 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.,

session-initial, 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 OverviewIn 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 SystemThe following key BSS functionalities are provided in the project:

Customer CreationCustomer/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 CreationRelationship 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 ManagementProduct 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 ManagementAccordingly 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 ChargingReal 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 FulfillmentWhenever 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 Sam’s post paid account, VoIP is assigned to their prepaid account.

Service ExecutionService 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 ManagementWhenever 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 PlatformIn this catalyst, the service delivery functions are mainly residing in the following areas:

Session ManagementThe 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 CatalogService 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:

Figure 3.13 Service Creation

Service Creation Steps:1 Define PBR ServiceProvide some Meta data, for example, the Service name, URI, contact, t-Model, etc.2 Define Business FlowDefine a routing table or a Service Logic if we need a complex process3 Publish PBR Service to Service CatalogStore such information to Service Catalog

Service order InventoryWe will collect all of order information from the CRM portal and store this information to a Service order Inventory;

20

Figure 3.14 Service executionThese requests will be processed in order.1 Query ServiceQuery a Service from Service Catalog, e.g. Presence-based Routing Service2 Load ManifestLoad and generate a manifest and routing table for business flow.3 Load/Execute Routing and Business FlowExecute a routing policy or a service logic for a real business request.

Profile ManagementThe Profile Manager tracks profile information for users and participants that connect to distributed application by using a Resource Definition Framework (RDF) database.

Well Enabled ServicesA 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 OverviewTo 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

Figure 3.16: Key domains of SID

Figure 3.17: Business View of Catalyst

IMS Network

HSS PSS UP10

IP Network

More...

More...

Base Service Presence ServiceMRBT Service MMCI ServiceVoIP Service

Basic Product

Advanced Product Bundle

Ultimate Product Bundle

More Services...

MRBT Product MMCI Product Presence Product More Products...

Resource

Services

Products

Product Bundles

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)

Basic Product

Advanced Product Bundle

Ultimate Product Bundle

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 provider’s offerings, Service and Resource business entities represent the realization of the offerings from a provider’s 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, 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

24

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 customer’s 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

IMS Network

HSS PSS UP10

IP Network

More...

More...

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 enterprise’s 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. Field name Description Data type length Memo

1 ID Offer ID Long 1~6

2 OfferName Offer name String 1~60

3 Comments The comments of the

Offer

String 1~4000

4 EffDate The effective date Date

5 ExpDate The expire date Date

6 ProdList The List of

independent product ID

Long[ ]

Get Independent Product Information


28

1 ID Product ID Long 1~6

2 ProdSpecName Independent Product

name

String 1~60


product

String 1~4000



Get Dependent Product InformationNo. Field name Description Data type length Memo

1 ID Product ID Long 1~6

2 ProdSpecName Dependent Product

name

String 1~60


product

String 1~4000



Get PricePlan Information


1 OfferID Offer ID Long 1~6

2 ProdID Product ID Long 1~6


product

String 1~4000



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

29

[Content] New Connection


1 MSISDN MSISDN number selected by user. Support New connection in batch, with an “&” to compart starting MSISDN and ending MSISDN

String 1~60


3 ProdID Prod ID Long 1~6

4 PricePlanID Price Plan ID Long 1~6

5 CertType Certificate type code, which can be obtained by querying customer’s certificate type interface

String 1~3

6 CertNo 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.

String 1~36

7 CustomerName Customer name using this service; new customer shall fill in this parameter when opening an account.

String 1~36

8 Address Installation address: it must be filled when applying for cable netwok.

String 1~120

9 AccountCode 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

String 1~60

10 PVI Private Identify String 1~60

11 PUIList List of PUIs String 1~60

12 CompleteDate The order complete date Date

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]

30

SOAP[Sending]

CRM[Receiving]

Service management[Content]

New Connection


1 MSISDN MSISDN number selected by user. Support New connection in batch, with an “&” to compart starting MSISDN and ending MSISDN

String 1~60


3 ProdID Prod ID Long 1~6

4 PricePlanID Price Plan ID Long 1~6

5 CertType Certificate type code, which can be obtained by querying customer’s certificate type interface

String 1~3

6 CertNo 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.

String 1~36

7 CustomerName Customer name using this service; new customer shall fill in this parameter when opening an account.

String 1~36

8 Address Installation address: it must be filled when applying for cable netwok.

String 1~120

9 AccountCode 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

String 1~60

10 PVI Private Identify String 1~60

11 PUIList List of PUIs String 1~60

12 OrderID The ID of the order Long 1~12

31

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 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.00ZXWN1000HLRAGENT00000006DLGCONFFFF00000001TXBEG

FFFFAdd

NewPVI:[email protected],IregFlag=1,PVIType=0

,Ki=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA,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”.

32

[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

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



<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]

33

http://www.w3.org/tr/soap/

http://www.w3.org/2002/ws/

SOAP 1.1

HTTP/1.1 200 OK

Content-Type: text/xml; charset=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>

<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



<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>

34

[Content]Field table of Request


1 ActivationMessage Message is an abstract

type for all activation

communications between

client and server.

Object

2 ActivationRequest A root object of Request

Request is an Activation

Message sent by client.

Object

3 ActivationResponse A root object of Response

Response is an Activation

Message sent from

service/server.

Object

4 ServiceRequest All businesses of service

related are derived from it.

Object

5 BaseServiceRequest Base Service Object

6 ExtendedServiceRequ

est

Object

7 GenericServiceReques

t *

Future reserved type Object

8 MrbtServiceRequest Multimedia Ring Back

Tone Service

Object

9 MmciServiceRequest Multimedia Colorful

Identity Service

Object

10 VoipServiceRequest VoIP Service Object

Field table of Response


1 Succeeded Operation Result

true/false

0/1

true, no error occurred

false, an error occurred, see

the StatusCode for more

information

Boolean

2 StatusCode 200: OK

400: Calling Error

500: Internal Server Error

600: Global Error

int (32

bit)

3 Status * Status description.

Future reserved property

String

(char *)

4 Tag * Tag an object as a context. Object

35

Future reserved property (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]


1 Action The action to indicate

whether user has

changed PBR policy

setting or reset the

setting

XML Element

2 Name Action name String (char *)

3 Uri The SIP URI of call-in

user

String (char *)

4 conditions Conditions XML Element

5 Timespan Lifecycle of an Action XML Element

6 Start Start date/time Date/Time String

7 To End date/time Date/Time String

8 Presence Presence status of

current user

Enumerable values:

Online = 0x0002

Busy = 0x0003

Away = 0x004

Offline = 0x0001

Enumeration

(Integer)

9 forwarding Forwarding XML Element

10 uri Forward URI String

36

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 S-CSCF.

[Protocol]

ISC & SIMPLE, which both are SIP extension.

[Sending]

ISC: INVITESIMPLE: SUBSCRIBE

[Receiving]

ISC: INVITESIMPLE: NOTIFY

[Content]The detail ISC and SIMPLE interface can be seen from following documents3GPP 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]

37

IMS Gateway Function[Receiving] OCS[Content] CCR

No. Field name Description Data

type

length Memo

1 Session-Id Session ID string

2 Origin-Host Origin Host For

Identification

string

3 Origin-Realm Realm of the originator string

4 Destination-Realm the realm the message is to

be routed to

string

5 Auth-Application-Id Support for Authorization &

Authentication

int32

6 Service-Context-Id unique identifier of the

Diameter credit-control

service

string

7 CC-Request-Type contains the reason for

sending the credit-control

request message

int32

8 CC-Request-Number identifies this request within

one session

uint32

9 Destination-Host Destination Host string

10 Event-Timestamp Timestamp uint32

11 Subscription-Id identify the end user's

subscription

group

12 Subscription-Id-Type which type of identifier is

carried by the Subscription-

Id

Int32

13 Subscription-Id-Data identify the end user string

14 Multiple-Services-

Indicator

indicates whether the

Diameter credit-control

client is capable of handling

multiple services

int32


Credit-Control

contains the AVPs related to

the independent credit-

control of multiple services

feature

group

16 Used-Service-Unit amount of used units

measured

group

17 CC-Time length of the requested, uint32

38

granted, or used time in

seconds

18 Rating-Group the identifier of a rating

group

uint32

19 Service-Information Service Info group

20 IMS-Information IMS Info group

21 Role-Of-Node Role of the AS/CSCF int32

22 Node-Functionality The function of the node int32

23 User-Session-ID Session identifier string

24 Calling-Party-Address A number string

25 Called-Party-Address B number string

26 IMS-Charging-

Identifier

IMS Charging Identifier string

CCA


type

length Memo

1 Session-Id Session ID string

2 Result-Code Result Code uint32

3 Origin-Host Origin Host For Identification string

4 Origin-Realm Realm of the originator string

5 Auth-Application-Id Support for Authorization &

Authentication

int32

6 CC-Request-Type contains the reason for sending

the credit-control request

message

int32

7 CC-Request-

Number

identifies this request within

one session

uint32


Credit-Control

contains the AVPs related to the

independent credit- control of

multiple services feature

group

9 Granted-Service-

Unit

the amount of units that the

Diameter credit-control client

can provide

group

10 Tariff-Time-Change includes the time in seconds

since January 1, 1900, 00:00

UTC, when the tariff of the

service will be changed

uint32

11 CC-Time length of the requested,

granted, or used time in

seconds

uint32

12 CC-Service- the number of service-specific uint64

39

Specific-Units units (e.g., number of events,

points) given in a selected

service

13 Rating-Group the identifier of a rating group uint32

14 Validity-Time the identifier of a rating group uint32

15 Result-Code Result Code uint32

16 Cost-Information Cost Information group

17 Unit-Value specifies the units as decimal

value

group

18 Value-Digits the significant digits of the

number

int64

19 Exponent contains the exponent value to

be applied for the Value-Digit

int32

20 Currency-Code Currency Code uint32

21 Cost-Unit Set to display a human readable

string to the end user

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.


1 Operate Type 0：deduction

3 Card NO Account name

4 Services Key Services Key INFO

5 Calling number Calling number

6 Called number Called number

7 Start Time

Stamp

Time stamp

8 Stop Time

Stamp

Time stamp

40

9 Charging Flag 0 ： caller charging (send)

1：called charging (receive)

10 Field 1 The number of sending IM

11 Field 2 The number of receiving IM

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]


type

len

gth

Me

mo

1 Record Type 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).

2 Retransmissio

n

This parameter, when present, indicates that

information from retransmitted Diameter ACR has

been used in this CDR.

3 SIP Method Specifies the SIP-method for which the CDR is

generated. Only available in session unrelated

cases.

Corresponding to the SIP-Event-Type AVP.

4 Role of Node Indicates the role of the AS.

Corresponding to the Role-of-node AVP.

5 Node Address The address of the node providing the information

for the CDR. This may either be the IP address or

41

the FQDN of the IMS node generating the

accounting data.

Corresponding to the Origin-Host AVP.

6 Session ID The Session identification. For a SIP session the

Session-ID contains the SIP Call ID (defined RFC

3261).

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.

8 Called Party

Address

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.

9 Service

Request Time

Stamp

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.

10 Service

Delivery Start

Time Stamp

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.

11 Service

Delivery End

Time Stamp

The time at which the service delivery was

terminated. It is Present only in SIP session related

case.


AVP in the STOP ACR.

12 Record

Opening Time

The time the CCF opened this record. Present only

in SIP session related case.

13 Record

Closure Time

The time the CCF closed this record.

14 Inter Operator

Identifiers

The identification of the home network

(originating and terminating) if exchanged via SIP

signalling.

Corresponding to the Inter-Operator-Identifier

AVP.

15 Originating

IOI

Corresponding to the Originating-IOI AVP

42

16 Terminating

IOI

Corresponding to the Terminating-IOI AVP

17 Local Record

Sequence

Number

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.

18 Record

Sequence

Number

A sequence number employed to link the partial

records generated by the CCF for a particular

session.

19 Cause For

Record

Closing

A reason for the close of the CDR.

20 Incomplete

CDR

Indication

Additional diagnostics when the CCF detects

missing ACR.

21 IMS Charging

Identifier

The ICID generated by the IMS node for the SIP

session.

Corresponding to the IMS-Charging-Identifier

(ICID) AVP.

22 SDP Session

Description

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.

23 List of SDP

Media

Components

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.

24 SIP Request

Timestamp

The time of the SIP Request (usually a (Re)

Invite).


AVP in the INTERIM ACR.

25 SIP Response

Timestamp

The time of the response to the SIP Request

(usually a 200 OK).

Corresponding to the SIP-Response-Timestamp

AVP in the INTERIM ACR.

26 SDP Media

Components

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.

27 SDP Media The name of the media available in the SDP data.

43

Name Corresponding to the SDP-Media-Name.

28 SDP Media

Description

The attributes of the media available in the SDP

data.

Corresponding to the SDP-Media-Description.

29 GPRS

Charging ID

The GCID generated by the GGSN for a GPRS

PDP context.

Corresponding to the GPRS-Charging-Id.

30 Media

Initiator Flag

Indicates if the called party has requested the

session modification and it is present only if the

initiator was the called party.

31 Authorised

QoS

Authorised QoS (defined in TS 23.207 / TS

29.207).

32 GGSN

Address

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.

33 Service

Reason

Return Code

The reason for the failure case of the service

request (the SIP error code from the SIP-Method

AVP). Present only in unsuccessful cases.

34 Service

Specific Data

Service specific data.

35 List of

Message

Bodies

This field comprising several subfields describing

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.

36 Content-Type The subfield of Message Bodies. It holds the

MIME type of the message body, such as

application/zip, image/gif, audio/mpeg, etc.

37 Content-

Disposition

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.

38 Content-

Length

The subfield of Message Bodies. It holds the size

of the data of a message body in bytes.

39 Originator The subfield of the "List of Message Bodies". It

indicates the originating party of the message

body.

44

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]


1 Order no. Order number

2 Status

3 StartTimeStamp

4 EndTimeStamp

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 from Services Management (Service Catalog) to Service Catalog (Services Management).[Protocol]SOAP[Sending]Management (Service Catalog)[Receiving]Service Catalog (Services Management).[Content]


1 Service URI Web service URI

2 Service name Web service name

45

3 Type Service Type

5. CONTRIBUTION TO INDUSTRY

GROUPS

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 body’s 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 HSSThe interface between HSS of 3GPP/3GPP2 and provisioning of TM ForumThe interface between CGF/AAA of 3GPP/3GPP2 and UDR-collection of TM

ForumThe 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 RequirementsAll enabler working groups that have mobile commerce or charging-related 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

46

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.

47

APPENDIX: DOCUMENT HISTORY

It is mandatory to complete this section each time a modification is made.

Revision Date Author Description

Version 0.1 19/03/2008 Junke Wang

Hongding Wang

Drafted outline of this document

Version 0.2 02/04/2008 Hongding Wang Drafted Part 1, Part 2, Part 3.1, Part 4.1, Part 5 and

Part 6.

Version 0.3 06/04/2008 Cheng Zuo Drafted Part 4.2.6

Version 0.4 09/04/2008 ZTE 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

Version 0.5 14/04/2008 Amdocs Drafted Part 4.2.7

Version 0.6 17/04/2008 Erqiang Xiao Drafted Part 3.2.2

Version 0.7 24/04/2008 Tianjun Yu 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

Version 0.8 12/06/2008 Hongding Wang Overall compilation for TMF

48

Documents

Seamless OSS&BSS for IMS_White Paper (Ver0.8)