• 沒有找到結果。

行動通信網路之高效能即時計費機制設計

N/A
N/A
Protected

Academic year: 2021

Share "行動通信網路之高效能即時計費機制設計"

Copied!
105
0
0

加載中.... (立即查看全文)

全文

(1)

國 立 交 通 大 學

資訊工程學系

博 士 論 文

行動通信網路之高效能

即時計費機制設計

A Design of Efficient Online Charging

Mechanisms for Mobile Telecommunications

研究生:蘇 淑 茵

指導教授:林 一 平 博士

(2)

本論文係接受

聯發科技獎學金贊助

This work was supported by

the Media Tek Fellowship

(3)

國 立 交 通 大 學

資訊工程學系

博 士 論 文

行動通信網路之高效能

即時計費機制設計

A Design of Efficient Online Charging

Mechanisms for Mobile Telecommunications

研究生:蘇 淑 茵

指導教授:林 一 平 博士

(4)

行動通信網路之高效能

即時計費機制設計

A Design of Efficient Online Charging

Mechanisms for Mobile Telecommunication

研 究 生:蘇淑茵 Student:Sok-Ian Sou

指導教授:林一平 Advisor:Yi-Bing Lin

國 立 交 通 大 學

資 訊 工 程 系

博 士 論 文

A Dissertation

Submitted to Department of Computer Science College of Computer Science

National Chiao Tung University in partial Fulfillment of the Requirements

for the Degree of Doctor of Philosophy

in

Computer Science

Jan 2008

Hsinchu, Taiwan, Republic of China

(5)

行動通信網路之高效能

即時計費機制設計

研究生:蘇淑茵

指導教授:林一平博士

國 立 交 通 大 學

資 訊 工 程 學 系

摘 要

隨著網際網路的蓬勃發展及通信技術的急速演進,利用網際網路提供高質素 的多媒體服務已成為行動市場之主流趨勢。為了在行動通信系統上整合網際網路 技術,第三代行動通訊規格組織(3GPP)制定了全球移動通信系統(UMTS)完全 IP(All-IP)架構的規格。其中,3GPP 第五版提出了一個處理網際網路多媒體 服務的核心網路子系統(IMS)。透過 IMS 平台,行動業者能夠有效率地開發及整 合包括語音、視訊與數據等組合的多媒體服務。然而,在 IMS 服務正式上市並獲 取利潤前,行動業者必須先處理關於收費系統的各項議題。 若要成功地向用戶推廣 IMS 多媒體服務,行動電信業者必須能正確及合理地 針對服務內容的價值收費。為了能夠有效率地開發及建置 IMS 服務, 3GPP 第五 版與第六版提出了一個具有開放性和通用性的即時計費系統(OCS)。透過即時計 費的管理機制,業者可以更彈性地即時處理網路資源授權、客戶帳戶餘額以及線 上批價等等。 行動服務的即時收費受許多因素影響,其中包括使用者的收費模式,服務類 型,資源分配與服務品質等等。因此,即時計費系統的設計必須要達到兩項要求。 第一,增加系統處理計費事項的準確性;第二,盡量減低控制訊息的交換。在這

(6)

篇論文的第一部份,我們首先提出一個能在 IMS 架構上整合預付式網際網路服務 的伺服器。當預付式語音服務與訊息服務同時提供時,其中一項重要議題是要在 不中斷進行中的語音服務下,提供即時訊息的傳送服務。在本論文中,我們提出 一項控制即時訊息傳送的策略,並分析其對整個系統之效能影響。 在本論文的第二部份,我們研發出能在即時收費系統上提供高效能、低成本 的餘額分配管理機制。我們探討兩個重要的即時收費程序:餘額保留機制與餘額 重新授權機制。我們首先針對預付式使用者,解決了當餘額不足時之處理程序。 在這個機制中,當使用者之可用餘額低於系統預設的臨界值時,即時計費系統會 向使用者發出餘額過低的警示訊息,以便提醒使用者盡快補充其預付帳戶內之金 額。業者在使用這個機制時,必須謹慎地設定這個臨界值參數。一方面要避免因 餘額不足而被迫中斷使用中的服務的機率,另一方面要降低警示訊息之發送頻 率。我們探討了這個臨界值的設置對即時收費系統之各種影響,並向業者提供適 當之參數設定建議。為了進一步提高即時收費系統的效能,我們研究由服務品質 改變而引起之餘額重新授權程序。本論文以一個動態改變的臨界值機制,有效地 降低餘額重新授權程序中所交換的控制訊息數目。 針對以上三個研究題目,我們分別發展出數學模型及模擬實驗,以準確分析 影響系統效能之各項指標。根據本論文的研究結果,我們為行動業者提供各項即 時收費機制之參數建議。實驗結果證實了我們提出的方法能夠提高整個即時收費 系統之效率。 關鍵字: 第三代行動通訊規格組織,IP 多媒體子系統, 行動通訊網路, 即時計 費, 預付式服務

(7)

A Design of Efficient Online Charging

Mechanisms for Mobile Telecommunications

Student:

Sok-Ian

Sou

Advisor:

Dr.

Yi-Bing

Lin

Institute of Computer Science and Engineering

National Chiao Tung University

ABSTRACT

Introduction of the 3G mobile system has driven the Internet into new markets to support mobile users. To integrate IP with wireless technologies with the right business model, the 3rd Generation Partnership Project (3GPP) proposed UMTS all-IP architecture that evolved from Global System for Mobile Communications (GSM) and General Packet Radio Service (GPRS). 3GPP Release 5 introduces the IP

Multimedia Core Network Subsystem (IMS) on top of the PS service domain to

provide multimedia services. Before the benefits of IMS and all-IP can be realized, a fundamental issue must be addressed is charging/billing, which is one of the most important activities in telecommunications.

In order to successfully promote IMS services, how to charge packet data service accurately and reasonably has become a major concern of operators. The deployment of the IP multimedia services requires effective charging management system and efficient service delivery mechanism. Therefore, 3GPP Releases 5 and 6 propose the convergent and flexible IP-based Online Charging System (OCS) to incorporate data applications with real-time control and management. Through online charging, the operator can ensure that credit limits are enforced and resources are authorized on a per-transaction basis.

In mobile data services, there are many factors that affect charging, for example, the service type, the amount of usage and the provisioned QoS. The design of online

(8)

charging system needs to reduce the signaling overhead and improve the system performance. In the first part of the dissertation, we first study how to develop an IMS application server to integrate existing IP-based prepaid services in the UMTS environment. When both voice and messaging are simultaneously offered, a potential problem is that the delivery of a prepaid message during a call may result in force-termination of that call due to credit depletion. To address this issue, we describe a strategy to determine if a prepaid message can be sent out during a call session.

In the second part of the dissertation, we investigate how to provide efficient credit quota management with lower signaling overhead and higher accuracy in the OCS. Specifically, we study the credit reservation and credit re-authorization mechanisms in the OCS, which are two most essential procedures in online charging management. First, we study the online credit reservation procedure for prepaid users in the UMTS online charging system. When the remaining amount of prepaid credit is below a threshold, the OCS should remind the user to refill the prepaid account. It is essential to choose an appropriate recharge threshold not only to avoid forced termination for the in-progress service sessions but also to decrease the recharge signaling overhead. Then we focus on the online credit re-authorization procedure of the OCS. The main objective is to reduce the traffic signaling overhead for credit re-authorization due to frequency QoS changes. We propose a threshold-based scheme that can significantly reduce the number of re-authorization message exchanges during a session.

We also develop analytic models and simulations experiments to evaluate the performance of the proposed schemes. Based on our study, the mobile operator can achieve high performance in the online charging management by configuring appropriate parameters.

Keywords: The 3rd Generation Partnership Project (3GPP), IP Multimedia Subsystem (IMS), mobile communication network, online charging, prepaid services

(9)

Acknowledgements

I would like to express my sincere gratitude to the following people who made this dissertation possible.

First of all, I am deeply indebted to my advisor Prof. Yi-Bing Lin for his help and full support throughout my research. In the course of my study, he has given me encour-agement and guided me to the right research direction. I wish there were enough words for me to thank him. Without his supervision and perspicacious advice, I would not have completed this dissertation.

Next, I would like to gratefully and sincerely thank my committee members, Prof. Gin-Lian Chen, Prof. Chu-Sing Yang, Prof. Wanjiun Liao, Prof. Yao-Nan Lien, Prof. Ming-Feng Chang and Prof. Wen-Nung Tsai for their valuable and insightful comments. I would also like to express my thanks to Prof. Hui-Nien Hung, Prof. Yu-Chee Tseng, Prof. Rong-Jaye Chen, Prof. Quincy Wu, Dr. Jeu-Yih Jeng, Prof. Phone Lin, Prof. Ai-Chun Pang, Dr. Yan-Kai Chen, Prof. Shun-Ren Yang, Prof. Pei-Chun Lee and Dr. Lin-Yi Wu for their endless help. I would like to extend my heartfelt gratitude to all my teachers, friends and labmates met in NCTU. Special thanks to my best friends Chang, Karen, Cynthia and Miranda. I have been blessed with friendships that serves as a pre-cious source of support, enjoyment and encouragement especially in times of difficulty and frustration.

Last but not the least, I wish to give my special thanks to my dear parents, my elder sister Bonny, my younger sister Sofia and my love Yinman for their patient love enabled me to complete this work. Their unlimited love is the best impetus and encouragement in my life.

This work was supported by the MediaTek Fellowship.

Sok-Ian (Ines) Sou 2008

(10)

Contents

Chinese Abstract i

English Abstract iii

Acknowledgements v Contents v List of Tables ix List of Figures x 1 Introduction 1 1.1 Motivation . . . 2

1.2 IP Multimedia Core Network Subsystem Architecture . . . 3

1.3 IP-based Online Charging System (OCS) . . . 5

1.4 IP-based Online Charging Protocol . . . 7

1.4.1 Diameter Credit Control Message . . . 8

1.4.2 Diameter Message Flow . . . 10

1.5 Online Charging Scenarios . . . 11

1.5.1 Immediate Event Charging . . . 12

1.5.2 Event Charging with Unit Reservation . . . 13

1.5.3 Session Charging with Unit Reservation . . . 14

1.6 Dissertation Organization . . . 16

2 Design of IMS Prepaid Application Server for SIP-based Services 18 2.1 Prepaid Application Server of SIP-based Services . . . 19

2.2 Integrating Charging for Prepaid Calls and Instant Messaging . . . 21

(11)

2.2.2 Prepaid Instant Messaging Delivery . . . 24

2.3 Analytic Modeling for Prepaid Application Server . . . 25

2.3.1 Derivation for the Remaining Credit Density Function . . . 26

2.3.2 Derivation for the Unnecessary Force-termination Probability . . . 29

2.3.3 Derivation for the Unnecessary Delay . . . 29

2.4 Simulation Validation . . . 30

2.5 Numerical Examples . . . 33

2.6 Summary . . . 37

2.7 Notation . . . 37

3 Modeling Online Credit Reservation Procedure 39 3.1 Recharge Threshold-based Credit Reservation (RTCR) . . . 40

3.2 Analytic Modeling for RTCR Mechanism . . . 41

3.2.1 Derivation for the Number of RU Operations . . . 41

3.3 Exact Analytic Model for Single-type Service . . . 42

3.3.1 Derivation for the Force-termination Probability . . . 43

3.3.2 Derivation for the Unused Credit Units . . . 46

3.4 Approximate Analytic Model for Multiple-type Services . . . 46

3.4.1 Derivation for the Force-termination Probability . . . 46

3.4.2 Derivation for the Unused Credit Units . . . 48

3.5 Simulation Validation . . . 49

3.6 Numerical Examples . . . 50

3.7 Summary . . . 54

3.8 Notation . . . 54

4 Reducing Credit Re-authorization Cost 56 4.1 Online Charging System for GPRS Sessions . . . 56

4.1.1 Credit Re-authorization Procedure . . . 57

4.1.2 Threshold-based Scheme for Credit Re-authorization . . . 60

4.2 Analytic Modeling for the Basic Scheme . . . 61

4.2.1 Derivation for the Number of ABMF message Exchanges . . . 62

(12)

4.3 Analytic Modeling for the Threshold-based

Scheme . . . 63

4.3.1 Derivation for the Number of ABMF message Exchanges . . . 64

4.3.2 Derivation for the Inaccuracy of Credit Information . . . 68

4.4 Simulation Validation . . . 73

4.5 Numerical Examples . . . 74

4.6 Summary . . . 76

4.7 Notation . . . 77

5 Conclusions and Future Work 80 5.1 Concluding Remarks . . . 80

5.2 Future Work . . . 81

Bibliography 83

(13)

List of Tables

2.1 Comparison of the Analytic and Simulation Results (Xc > 0, Tm = 5 CU,

X = 20Tm, 1/λc = 50 TU) . . . 32

3.1 Comparison of the Analytic and Simulation Results (n = 1) . . . 49 3.2 Comparison of the Analytic and Simulation Results (n = 2) . . . 50 4.1 Comparison of the Analytic and Simulation Results (δ = 0, N = 2 and

ˆ

(14)

List of Figures

1.1 The IMS Network Architecture. . . 4

1.2 The Online Charging System Architecture. . . 6

1.3 Diameter Message Flow for Online Session. . . 10

1.4 IMS Message Flow for Immediate Event Charging. . . 12

1.5 IMS Message Flow for Event Charging with Unit Reservation. . . 13

1.6 IMS Session with Online Charging. . . 14

1.7 IMS Message Flow for Session Charging with Unit Reservation. . . 15

2.1 IMS Environment for SIP-based Prepaid Services. . . 20

2.2 Message Flow for Prepaid IMS-to-PSTN Call Setup and Release. . . 22

2.3 Message Flow for Prepaid Messaging Delivery. . . 24

2.4 Timing Diagram for Prepaid Calls and Messaging Deliveries. . . 26

2.5 Simulation Flow Chart. . . 31

2.6 Effects of E[tc] on PU F T and E[td] (X = 50E[tc] and λm = 5λc) . . . 34

2.7 Effects of Vc on PU F T and E[td] (X = 25E[tc] and 1/λm= 0.5E[tc]) . . . . 35

2.8 Effects of 1/λm on PU F T and E[td] (X = 25E[tc]) . . . 35

2.9 Effects of X on PU F T and E[td] (1/λm = 0.5E[tc]) . . . 36

3.1 Timing Diagram for the RTCR mechanism. . . 42

3.2 Timing Diagram for Deriving ˜θ. . . 44

3.3 Effects of θi on E[Nr,i]. . . 51

3.4 Effects of θi and Cmin (n = 2, λ1 = µ1 and λ2 = µ2 = 2µ1) . . . 52

3.5 Effects of Vh,i (n = 2, θi = 2.5µi, λ1 = µ1 and λ2 = µ2 = 2µ1) . . . 53

3.6 Effects of n (Cmin = 6c, λi = iµ1 and µi = iµ1) . . . 53

4.1 Message Flow for Credit Re-authorization Procedure. . . 58

4.2 Timing Diagram for the Basic Scheme. . . 62

(15)

4.4 Probability Transition Diagram (N = 2). . . 66

4.5 Timing Diagram for Deriving CT. . . 68

4.6 Effects of τg (N = 2, α2 = 2α1 and p0 = 0.01) . . . 74

4.7 Effects of δ (N = 2, α2 = 2α1 and p0 = 0.01) . . . 75

4.8 Effects of δ and p0 (N = 2, α2 = 2α1 and τg = 1/λ) . . . 76

(16)

Chapter 1

Introduction

By providing ubiquitous connectivity for data communications, the Internet has become the most important vehicle for global information delivery. Introduction of the 3G mobile system has further driven the Internet into new markets to support mobile users. Specif-ically, the Internet Protocol (IP) has played a major role in UMTS in providing a wide range of connectionless services to mobile users [37].

Internet environment encourages global usage with flat-rate tariffs and low entry costs. A major problem of the “flat-rate” tariffs is that such business model cannot justify the expensive equipment/operation investments of mobile services. Mobile telecom opera-tors have to move from a bit-pipe model to a revenue-generating services model. To integrate IP with wireless technologies with the “right” business model, the 3rd

Genera-tion Partnership Project (3GPP) proposed UMTS all-IP architecture to enable Web-like

services and new billing paradigm in the telephony world. This architecture has evolved from Global System for Mobile Communications (GSM) and General Packet Radio Service (GPRS) [1, 12]. 3GPP Release 5 introduces the IP Multimedia Core Network Subsystem (IMS) on top of the PS service domain to provides multimedia services [18]. This evolution requires new mechanisms to collect information about chargeable events and to impose flexible mobile billing schemes (such as time-based, volume-based, or content-based). By creating hybrid online/offline billing models, 3GPP Releases 5 and 6 propose the IP-based

Online Charging System (OCS) [10] to allow both prepaid and postpaid subscribers to be

charged in real-time. Through online charging, the operator can ensure that credit limits are enforced and resources are authorized on a per-transaction basis. From a subscriber’s perspective, knowing the charges in advance and having self-imposed credit limits can make the cost of services more transparent. In other words, real-time rating/charging functions help subscribers to control their budget, and telecom operators to reduce bad

(17)

debt.

Online charging requires a single set of management processes, such as service devel-opment, production support and pricing, which reduces operational costs and enhances flexibility on billing and product diversification. The OCS approach is estimated to re-duce 25% of the product launch costs [28]. This real-time solution provides two-way communications between network nodes and the charging/billing system, which transfer information about rating, billing and accounting. When the OCS receives a service re-quest, it queries other relevant components, then determines and returns a response to the network node. In contrast, in an offline environment, all usage records typically flow through the billing system in one direction after the service has been delivered.

This introductory chapter first describes the motivation of our work on the mobile online charging mechanism. We briefly introduce the UMTS/IMS architecture and its IP-based online charging system. Then we present the mobile charging protocol that used to control online IMS services in real-time. Finally, we discuss the performance analysis issues on the mobile online charging system and the organization of this dissertation.

1.1

Motivation

Traditional voice and basic data services such as Short Message Service (SMS) and

Mul-timedia Messaging Service (MMS) deliveries are the principal sources of revenue for most

mobile operators. The deployment of IMS will bring more competition for more special-ized services and content. However, before the benefits of IMS and all-IP can be realspecial-ized, a fundamental issue must be addressed is charging/billing, which is one of the most important activities in telecommunications. The IP-based services for GPRS and IMS specify more critical charging requirements that impose flexible mobile billing schemes (e.g., time-based, volume-based, content-based) [20, 29, 56].

With the wide application of packet data service, how to charge packet data service accurately and reasonably has become a common concern of operators. Creating a killer environment has now become a key point in terms of competition. The deployment of the IP multimedia services requires effective charging management system and efficient service delivery mechanism. Therefore, advanced mobile telecom requires a convergent and flexible online charging system to incorporate data applications with real-time control and management. Such convergence is essential to mitigate fraud and credit risks and provide more personalized advice to users about charges and credit limit controls.

(18)

In mobile data services, there are many factors that affect charging, for example, the content type, the radio access technology, the location information, the amount of usage, the provisioned QoS and so on [4, 5, 7, 9, 11, 16]. The design of online charging system needs to reduce the signaling overhead and improve the system performance. In this dis-sertation, we first study how to develop an IMS application server to integrate existing IP-based prepaid services in the UMTS environment. Then we investigate how to provide efficient credit quota management with lower signaling overhead and higher accuracy in the OCS. Specifically, we study the credit reservation and credit re-authorization mecha-nism in the OCS, which are two most essential procedures in online charging management.

1.2

IP Multimedia Core Network Subsystem

Archi-tecture

To effectively integrate mobile technology with the Internet, 3GPP Release 5 introduces the IMS architecture that effectively provides multimedia services [6, 8, 18, 47]. The IMS protocols allow the telecom operators to bring attractive new services to their customers. Such protocols are namely Session Initiation Protocol (SIP) for signaling and Diameter for Authentication, Authorization and Accounting (AAA). This section introduces the UMTS/IMS architecture.

As illustrated in Fig. 1.1, the IMS connects the Gateway GPRS Support Node (GGSN; Fig. 1.1 (a)) with the external Packet Data Network (PDN; Fig. 1.1 (b)) and the Public

Switched Telephone Network (PSTN; Fig. 1.1 (i)). In this figure, the dashed lines represent

signaling links and the solid lines represent data and signaling links. The IMS nodes are similar to those in a SIP-based Voice over IP (VoIP) network [27, 49]. Details are described as follows:

• The Call Session Control Functions (CSCFs; Fig. 1.1 (c), (d), and (e)) are SIP

servers, which are in charge of call control and communications with the Home

Sub-scriber Server (HSS; see Fig. 1.1 (m)) regarding location information. Specifically,

IMS signaling is carried out by the Proxy CSCF (P-CSCF; Fig. 1.1 (c)), the

Interro-gating CSCF (I-CSCF; Fig. 1.1 (d)) and the Serving CSCF (S-CSCF; Fig. 1.1 (e)).

When a User Equipment (UE) attaches to the GPRS/IMS network and performs

Packet Data Context (PDP) context activation, a P-CSCF is assigned to the UE.

(19)

IP Multimedia Subsystem (IMS) UE PDN c P-CSCF GPRS Core Network Radio Access Network HSS a f GGSN

BGCF: Breakout Gateway Conrol Function CSCF: Call Session Control Function GGSN: Gateway GPRS Support Node HSS: Home Subscriber Server

I-CSCF: Interrogating CSCF MGCF: Media Gateway Control Function MGW: Media Gateway MRF: Media Resource Function

OCS: Online Charging System PDN: Packet Data Network

P-CSCF: Proxy CSCF PSTN: Public Switched Telephone Network S-CSCF: Serving CSCF T-SGW: Transport Signaling Gateway UE: User Equipment

OCS MGCF PSTN S-CSCF I-CSCF BGCF T-SGW MRF MGW Application Server h i k b l n signaling

signaling and data

g m

j d

e

(20)

to the I-CSCF. The I-CSCF selects an S-CSCF to serve the UE during the IMS registration procedure. This S-CSCF supports the signaling for call setup and sup-plementary services control. All incoming calls are routed to the destination UE through the S-CSCF.

• The Media Gateway (MGW; Fig. 1.1 (f)) transports the IMS user data traffic. The

MGW provides user data transport between the UMTS core network and the PSTN (including media conversion bearer control and payload processing).

• The Media Gateway Control Function (MGCF; Fig. 1.1 (g)) controls the media

channels in an MGW.

• The Breakout Gateway Control Function (BGCF; Fig. 1.1 (h)) selects the network

in which the PSTN (or circuit switched domain) breakout is to occur. If the BGCF determines that a breakout is to occur in the same network, it selects an MGCF that is responsible for interworking with the PSTN. If the breakout occurs in another IMS network, the BGCF forwards the SIP request to another BGCF or an MGCF in the selected IMS network.

• The Transport Signaling Gateway (T-SGW; Fig. 1.1 (j)) serves as the PSTN

sig-naling termination point and provides the PSTN/legacy mobile network with IP transport level address mapping. Specifically, it maps call-related signaling between the MGCF and the PSTN.

• The Media Resource Function (MRF; Fig. 1.1 (k)) performs functions such as

mul-tiparty call, multimedia conferencing, and tone and announcement.

In Fig. 1.1, an application server (Fig. 1.1 (l)) provides value added IP multimedia services which reside either in the user’s home IMS or in a third party location. In Chapter 2, we will design an IMS prepaid application server to integrate online prepaid call and messaging services. The OCS (Fig. 1.1 (n)) performs online charging and collects the billing information with the CSCFs. Details of the OCS functionalities are described in the next section.

1.3

IP-based Online Charging System (OCS)

This section introduces the UMTS online charging system. In online charging, network resource usage is granted by the OCS based on the price or the tariff of the requested

(21)

Session Based Charging Function (SBCF) Event Based Charging Function (EBCF) Account Balance Management Function (ABMF) Rating Function (RF) Charging Gateway Function (CGF) Recharge Server Billing System

Online Charging System

a

b

c

d

e

f

Rc Ga Re Bo Rr Account Database

g

Tariffs Database

Figure 1.2: The Online Charging System Architecture.

service and the balance in the subscriber’s account. Fig. 1.2 shows the OCS architecture defined in 3GPP 32.296 [10]. The OCS supports two types of Online Charging

Func-tions (OCFs), namely the Session Based Charging Function (SBCF) and the Event Based Charging Function (EBCF). The SBCF (Fig. 1.2 (a)) is responsible for network bearer

and session-based services such as voice calls, GPRS sessions or IMS sessions. The EBCF (Fig. 1.2 (b)) is responsible for event-based services, such as SMS/MMS delivery, and content (e.g., music or ring tones) downloading.

The Account Balance Management Function (ABMF; Fig. 1.2 (c)) maintains user balances and other account data. When a user’s credit depletes, the ABMF connects the

Recharge Server (Fig. 1.2 (f)) to trigger the recharge account function. The SBCF/EBCF

interacts with the ABMF to query and update the user’s account. The CDRs generated by the charging functions are transferred to the Charging Gateway Function (CGF; Fig. 1.2 (d)) in real-time [32]. The CGF acts as a gateway between the IMS/UMTS network and the Billing System (Fig. 1.2 (g)).

In this architecture, the Rating Function (RF; Fig. 1.2 (e)) determines the price/tariff of the requested network resource usage. The RF handles a wide variety of ratable

(22)

in-stances, including data volume, session/connection time, or service events. In addition, different charging rates can be adopted for different time segments (e.g., peak hours and off-peak hours). The OCF interacts with the RF to determine the price/tariff of the requested service through the Re interface. The details of the message exchanges are described as follows:

• The Price Request/Response message pair determines the price for an event-based

service (e.g., SMS). This message exchange can be executed before the service deliv-ery (e.g., for advice of charge and prepaid service) or after service delivdeliv-ery (e.g., for postpaid service). Based on the price information, the EBCF calculates the amount of credit granted to the network nodes.

• The Tariff Request/Response message pair determines the tariff information for

a session-based service (e.g., voice calls). Based on the tariff information, the SBCF calculates the amount of credit granted to the network nodes.

1.4

IP-based Online Charging Protocol

This section presents the mobile charging protocol that used for credit control of online IMS services. The Diameter protocol was derived from Remote Access Dial In User Service (RADIUS) protocol with more flexibility, and is generally believed to be the next genera-tion Authenticagenera-tion, Authorizagenera-tion, and Accounting (AAA) protocol [21, 45, 46]. Diameter is an extensible protocol enabling AAA within and across IP multimedia networks that relies on secure and reliable transports. Its modular architecture offers a flexible base protocol which allows application-specific extensions. Diameter has proven successful in overcoming the limitations of RADIUS. Development of new IP- and telephony-based ser-vices is gaining momentum, and every service requires charging. Therefore, rapid growth in the usage of Diameter-based charging can be expected. The 3GPP has chosen the Diameter protocol to enable IMS network AAA capabilities [18, 39, 42].

Like RADIUS, Diameter follows the client-server architecture, where a client and a server interact through the Diameter request and answer message exchange. Several Diameter applications defined by Internet Engineering Task Force (IETF) are utilized in IMS, including the Diameter Credit Control (DCC) application for IP-based online charging control [30]. All-IP mobile network utilizes the DCC application to communicate with the OCS [10, 15]. In IMS online charging, the IMS network node (e.g., CSCF) acts

(23)

as a DCC client and the OCS acts as a DCC server. In this section, we describe the Diameter credit control messages and the Diameter message flow.

1.4.1

Diameter Credit Control Message

The DCC messages are described as follows: The Credit Control Request (CCR) message is sent from the DCC client to the DCC server to request an amount of credit for an online service. The CCR message contains the following Attribute Value Pairs (AVPs) [15, 30]:

• The Session-Id AVP identifies the credit control session.

• The Origin-Host and the Origin-Realm AVPs contain the address and the realm of

the DCC client.

• The Destination-Host and the Destination-Realm AVPs contain the address and the

realm of the DCC server.

• The Auth-Application-Id AVP contains value 4 as defined in RFC 4006 [30]. This

value indicates the Diameter Credit Control Application.

• The Service-Context-Id AVP contains the identifier allocated by the service provider

or by the standardization body.

• The CC-Request-Type AVP indicates the credit control request type for the

on-line service. It can be one of the following types: INITIAL REQUEST (value 1) initiates a credit control session. UPDATE REQUEST (value 2) contains update credit control information for an in-progress session. This request is sent when the credit units currently allocated for the session are completely consumed. TER-MINATION REQUEST (value 3) terminates an in-progress credit control session. EVENT REQUEST (value 4) is used in one-time credit control for event-based service.

• The CC-Request-Number AVP contains the sequence number of the message. • The Subscription-Id AVP contains the identification of the user, which can be a

SIP Uniform Resource Identifier (URI), an International Mobile Subscriber Identity (IMSI) or a Mobile Station ISDN Number (MSISDN).

(24)

• The Termination-Cause AVP is presented if the CC-Request-Type is set to

TERMI-NATION REQUEST. This AVP provides the reason why the credit control session is terminated. For example, DIAMETER LOGOUT (value 1) indicates that the user terminates the credit control session.

• The Requested-Action AVP is only presented in the EVENT REQUEST message.

This AVP specifies the action for the event, such as DIRECT DEBITING, RE-FUND ACCOUNT, CHECK BALANCE or PRICE ENQUIRY.

• The Multiple-Services-Credit-Control AVP contains the parameters for quota

man-agement, including the amount of request credit, the amount of used credit, the reporting reason, the identity of the used service, and the identifier of the rating group.

• The User-Name AVP contains the user name in the Network Access Identifier (NAI)

format according to RFC 3588 [21].

• The Event-Timestamp AVP specifies the time when the accounting message is

cre-ated.

• The Service-Information AVP contains the service specific parameters.

The Credit Control Answer (CCA) message is sent from the DCC server to the DCC client to grant an amount of credit for the online service. The CCA message contains the following AVPs:

• The Result-Code AVP contains the result of the credit control request.

• The CC-Session Failover AVP contains an indication to the DCC client whether or

not a failover handling is used.

• The Credit-Control-Failure-Handling AVP determines the action in the Diameter

client when the Diameter server is temporarily prevented, e.g., because of network failure. The action may be TERMINATE (with value 0), CONTINUE (with value 1) and RETRY AND TERMINATE (with value 2).

• The Multiple-Services-Credit-Control AVP contains the parameters for the quota

management, including the amount of granted credit, the identifier of the requested service, the identifier for the rating group, the validity time for the usage of granted

(25)

1. CCR (INITIAL_REQUEST) 2. CCA (INITIAL_REQUEST) 3. CCR (UPDATE_REQUEST) 4. CCA (UPDATE_REQUEST) 5. CCR (TERMINATE_REQUEST) 6. CCA (TERMINATE_REQUEST) Reserve Units Operation

Reserve Units and Debit Units Operation

Debit Units Operation

Performs charging control Performs charging control Performs charging control OCS (DCC Server) Network Node (DCC Client)

Figure 1.3: Diameter Message Flow for Online Session.

credit units (i.e., the time when the DCC client should perform another credit control request), and the events (such as QoS changes or SGSN changes) that will trigger credit re-authorization procedure.

• The Cost-Information AVP contains the cost information of the requested service. • The Session-Id, the Origin-Host, the Origin-Realm, the Auth-Application-Id, the

CC-Request-Type, the CC-Request-Number, the Service-Information AVPs are

sim-ilar to those in the CCR message.

1.4.2

Diameter Message Flow

The Diameter message flow for session-based online charging includes three types of credit control operations: Reserve Units operation (Steps 1 and 2 in Fig. 1.3), Reserve Units and Debit Units operation (Steps 3 and 4 in Fig. 1.3) and Debit Units operation (Steps 5 and 6 in Fig. 1.3). The following operations are executed for session-based service.

(26)

net-work node (e.g., GGSN or S-CSCF) sends the CCR message with CC-Request-Type “INITIAL REQUEST” to the OCS. This message indicates the amount of requested credit.

Step 2. [Reserve Units (answer)] Upon receipt of the CCR message, the OCS determines

the tariff of the requested service and then reserves an equivalent amount of credit. After the reservation is performed, the OCS acknowledges the network node with the CCA message including credit reservation information.

Step 3. [Reserve Units and Debit Units (request)] During the service session, the granted

credit units may be depleted. If so, the network node sends a CCR message with

CC-Request-Type “UPDATE REQUEST” to the OCS. The network node reports

the amount of used credit, and requests for additional credit units.

Step 4. [Reserve Units and Debit Units (answer)] When the OCS receives the CCR

mes-sage, it debits the amount of consumed credit and reserves extra credit units for the service session. The OCS acknowledges the network node with the CCA message with the Result-Code “DIAMETER SUCCESS” and the amount of the reserved credit. Note that the Reserve Units and Debit Units operation (i.e., Steps 3 and 4) may repeat many times before the service session is complete.

Step 5. [Debit Units (request)] When the service session is complete, the network node

sends the CCR message with CC-Request-Type “TERMINATE REQUEST” to the OCS. This action terminates the session and reports the amount of the consumed credit.

Step 6. [Debit Units (answer)] The OCS debits the consumed credit units and releases

the unused reserved credit units. The OCS acknowledges the network node with the CCA message. This message may contain the total cost of the service.

1.5

Online Charging Scenarios

In this section, we elaborate more on how the IMS node and the OCS can manage online credit for the service delivery in real-time. 3GPP Release 6 defines three kinds of online charging: immediate event charging, event charging with unit reservation and session charging with unit reservation. The message flows for these online charging scenarios are explained in the following subsections.

(27)

EBCF Messaging Application Server 2. CCR (EVENT_REQUEST) 4. CCA (EVENT_REQUEST) RF Online Charging System

3. Price Request 3. Price Response UE1 P-CSCF S-CSCF 1. MESSAGE 1. MESSAGE 1. MESSAGE 5. 200 OK 5. 200 OK 5. 200 OK Message Delivery

Figure 1.4: IMS Message Flow for Immediate Event Charging.

1.5.1

Immediate Event Charging

In immediate event charging, credit allocation to an IMS node is performed in a single operation, and the credit units are deducted immediately from the subscriber’s account. Assume that UE1 subscribes to the messaging service with online charging. The message flow for IMS event-based messaging service (offered by an IMS messaging application server) is described below (see Fig. 1.4).

Step 1. Subscriber UE1 sends a SIP MESSAGE request to the IMS messaging application

server through the P-CSCF and the S-CSCF.

Step 2. The application server sends a CCR message with CC-Request-Type “EVENT

REQUEST” and Requested-Action “DIRECT DEBITING” to the EBCF in the OCS.

Step 3. Upon receipt of the credit control request, the EBCF requests account

infor-mation for the subscriber (such as billing plan and subscription profile) from the ABMF. Then the EBCF sends a Price Request message to the RF. The RF de-termines the price of the service based on the subscriber’s billing plan. Specifically, the RF calculates the price for the given service according to the service and sub-scriber information specified in the request. The calculated price and the billing information is returned to the EBCF through the Price Response message.

(28)

EBCF Messaging Application Server 2. CCR (INITIAL_REQUEST) 4. CCA (INITIAL_REQUEST) RF Online Charging System

3. Price Request 3. Price Response UE1 P-CSCF S-CSCF 1. MESSAGE 1. MESSAGE 1. MESSAGE 5. 200 OK 5. 200 OK 5. 200 OK Message Delivery 6. CCR (TERMINATE_REQUEST) 6. CCA (TERMINATE_REQUEST)

Figure 1.5: IMS Message Flow for Event Charging with Unit Reservation.

Step 4. The EBCF performs credit unit deduction through the ABMF. When the

deduc-tion is complete, the EBCF replies to the applicadeduc-tion server with the CCR message.

Step 5. After the application server has obtained the credit indicated in the CCR message,

it delivers the messaging service to UE1. If the service is delivered successfully, the application server sends a SIP 200 OK message to UE1 through the S-CSCF and the P-CSCF. If the credit control fails, an appropriate SIP error message (e.g. 401 Unauthorized or 402 Payment Required) is sent to UE1.

1.5.2

Event Charging with Unit Reservation

Event charging with unit reservation conducts reserving and returning unused credit units for an event-based service. The message flow in Fig. 1.5 is described as follows:

Step 1. Subscriber UE1 sends a SIP MESSAGE request to the IMS messaging application

server through the P-CSCF and the S-CSCF.

Step 2. The application server sends a CCR message with CC-Request-Type “INITIAL

REQUEST” to the EBCF of the OCS.

Step 3. Upon receipt of the CCR message, the EBCF requests account information for

(29)

S-CSCF1 P-CSCF1 P-CSCF2 S-CSCF2

Originating

Network

GPRS

GPRS

UE1 UE2 SBCF RF ABMF OCS

Terminating Network

IMS Signaling IMS Data

Figure 1.6: IMS Session with Online Charging.

the RF. This message includes the subscription identity and the service information. The RF then determines the price of the messaging service. Through the Price Response message, the calculated price and the billing information is returned to the EBCF.

Step 4. The EBCF performs credit unit reservation with the ABMF. Then it replies to

the application server with the CCR message indicating the amount of granted credit.

Step 5. After the application server has obtained the credit, the messaging service is

delivered to UE1, and then a SIP 200 OK message is sent to UE1 through the S-CSCF and the P-S-CSCF. If the credit control fails, an appropriate SIP error message (e.g., 401 Unauthorized or 402 Payment Required) is sent to UE1. Assume that the credit control succeeds, Step 6 is executed.

Step 6. After the message is successfully delivered, the application server sends the

CCR message with CC-Request-Type “TERMINATE REQUEST” to the EBCF. The EBCF debits the consumed credit from the subscriber’s account. Then the OCS replies to the application server with the CCA message.

1.5.3

Session Charging with Unit Reservation

Session charging with unit reservation is performed in credit control for session-based services. Consider an online charging scenario in Fig. 1.6, where UE1 makes an IMS call

(30)

SBCF

2. CCR (INITIAL_REQUEST)

4. CCA (INITIAL_REQUEST)

RF Online Charging System

3. Tariff Request 3. Tariff Response UE1 P-CSCF1 S-CSCF1 1. INVITE 5. 200 OK 5. 200 OK

IMS call connection to UE2

6. CCR (UPDATE_REQUEST) 6. CCA (UPDATE_REQUEST) 1. INVITE

7. CCR (TERMINATE_REQUEST) 7. CCA (TERMINATE_REQUEST) IMS signaling for call

establishment with UE2

IMS call release

Figure 1.7: IMS Message Flow for Session Charging with Unit Reservation.

to UE2. We assume that the tariff information for this service is not changed during the session. In Chapter 4, we will consider the scenario where the tariff information is expired during a service session for reasons such as QoS change. The IMS message flow for session charging with unit reservation (see Fig. 1.7) is described as follows:

Step 1. Subscriber UE1 sends a SIP INVITE request to S-CSCF1 through P-CSCF1. Step 2. S-CSCF1 sends a CCR message with CC-Request-Type “INITIAL REQUEST” to

the SBCF of the OCS. The Service-Information AVP contains the service parameters for the IMS sessions and the Session Description Protocol (SDP) parameters for the voice packets [6, 31].

(31)

and the subscribed profile from the ABMF. Then the SBCF sends a Tariff Request message to the RF to determine the tariff of the IMS call. Based on the subscriber information, the RF replies the Tariff Response message to the SBCF. This mes-sage includes the billing plan and the tariff information for the IMS service.

Step 4. When the tariff information is received, the SBCF performs credit unit

reserva-tion with the ABMF. Then it replies to S-CSCF1 with the CCA message containing the granted credit (e.g., the number of minutes or bytes allowed). In this example, the request is successfully processed with Result-Code “DIAMETER SUCCESS”.

Step 5. After S-CSCF1 has obtained the granted credit units, it continues the call setup

to UE2 (through P-CSCF2 and S-CSCF2). When UE2 accepts the call, a SIP 200 OK message is sent to UE1 through S-CSCF1 and P-CSCF1. At this point, the IMS session starts.

Step 6. During the service session, S-CSCF1 supervises the network resource

consump-tion by deducting the granted credit units. If the granted credit is depleted, the S-CSCF1 sends another CCR message with CC-Request-Type “UPDATE REQUEST” to the SBCF. Through this message, S-CSCF1 also reports the amount of used credit, and requests additional credit for the remaining session. The SBCF deducts the consumed credit and reserves extra credit from the ABMF. Then the SBCF acknowledges S-CSCF1 with the CCA message including the amount of the next re-served credit. Note that this step may repeat several times before a service session is complete.

Step 7. When the service session is complete, S-CSCF1 sends another CCR message with

CC-Request-Type “TERMINATE REQUEST” to the SBCF. The SBCF debits the

consumed credit units from the subscriber’s account with the ABMF. Then the SBCF sends the CCA message to S-CSCF1.

1.6

Dissertation Organization

Based on the above discussion, we present the performance analysis issues of the mobile online charging system and the dissertation organization. This dissertation contains five chapters in addition to this introductory chapter. Details for each chapter are described below.

(32)

In Chapter 2, we develop an IMS prepaid application server to handle both the prepaid calls and messaging services in UMTS/IMS environment. When both voice and messaging are simultaneously offered, a potential problem is that the delivery of a prepaid message during a call may result in force-termination of that call due to credit depletion. To address this issue, we describe a strategy to determine if a prepaid message can be sent out during a call session. We propose an analytic model to investigate the performance of this strategy.

In Chapter 3, we study the online credit reservation procedure for prepaid users in the UMTS online charging system. When the remaining amount of prepaid credit is below a threshold, the OCS should remind the user to refill the prepaid account. It is essential to choose an appropriate recharge threshold not only to avoid forced termination for the in-progress service sessions but also to decrease the recharge signaling overhead. An analytic model is developed to investigate the performance of this threshold-based recharge mechanism.

Chapter 4 focuses on the online credit re-authorization procedure of the OCS. The main objective is to reduce the traffic signaling overhead for credit re-authorization due to frequency QoS changes. In the OCS architecture described in Section 1.3, the ABMF and the SBCF may physically reside at different (and possibly remote) locations. There-fore, the message exchanges in the credit re-authorization may be expensive, and it is desirable to reduce the signaling overhead. We propose a threshold-based scheme that can significantly reduce the number of ABMF message exchanges during a session. An analytic model is developed to investigate the performance of this scheme.

We also conduct simulation experiments to validate the analytic models proposed in Chapters 2-4. Finally, Chapter 5 concludes this dissertation and gives the future directions of this work.

(33)

Chapter 2

Design of IMS Prepaid Application

Server for SIP-based Services

The Short Message Service (SMS), which allows mobile users to send and receive simple text messages up to 140 bytes, is a mature wireless communication service. Most modern digital cellular phone systems offer SMS, which is considered a profitable value-added service [14, 41, 43]. In UMTS, Multimedia Messaging Service (MMS) is introduced to deliver messages that range in size from 30K bytes to 100K bytes [2, 13]. Formats that can be embedded within MMS include text (formatted with fonts, colors, and other style elements), images (in JPEG or GIF formats), audio (in MP3 or MIDI formats) and video (in MPEG format). With the growing demand of instant messaging services, RFC 3428 [22] proposes the MESSAGE method, a SIP extension that allows transfer of instant messages over the Internet. With this extension, Internet services (such as mail and instant messaging [44]) can be integrated with SMS/MMS through the IMS.

Billing mechanisms for messaging (including both SMS and MMS) and VoIP (espe-cially for IMS calls toward the PSTN) are typically deployed for postpaid services. On the contrary, the prepaid billing mechanisms for combining these services are seldom studied in the literature. This chapter proposes a prepaid application server approach that can simultaneously process prepaid charging for SMS/MMS message deliveries and IMS calls. When both voice and messaging are simultaneously offered in the prepaid application server, a potential problem is that the delivery of a message during a call may result in force-termination of that call due to credit depletion. To address this issue, we describe a strategy to determine if a prepaid message can be sent out during a call session. An analytic model is derived to investigate the performance of this strategy. Based on our study [53], we provide guidelines to select appropriate input parameters for the prepaid

(34)

application server. The notation used in this chapter is listed in Section 2.7.

2.1

Prepaid Application Server of SIP-based Services

In the IMS architecture described in Section 1.2, the CSCF is basically a SIP server responsible for call control. Other IMS nodes for VoIP include the MGCF, the MGW and the T-SGW. These IMS nodes interact with each other through SIP [47, 18] signaling. SIP-based prepaid services in the Internet have been recently investigated (see [54, 55] and the references therein). In 3GPP Release 6, the Online Charging System (OCS) supports prepaid services for IMS. However, how to manage and allocates credit for the SIP-based prepaid services is not mentioned in the 3GPP specifications. Therefore a network entity is required to provide these functionalities without modifying the existing network entities such as the OCS and the CSCF. This section proposes a Prepaid Application Server (PAS) to manage credit allocation for both the prepaid SIP calls and messaging services in IMS. In Chapters 3 and 4, we will also consider credit reservation in various scenarios.

Fig. 2.1 illustrates the PAS that interacts with several network nodes in the IMS network: The CSCF (Fig. 2.1 (a)) utilizes SIP to provide control signaling for IP-based multimedia services. The MGCF, the MGW and the T-SGW (Fig. 2.1 (b)) interwork the IMS with the PSTN. The User Equipment (UE; Fig. 2.1 (c)) includes the SIP user agent to support IMS calls and SIP-based instant messaging services. The IP-Message Gateway (Fig. 2.1 (d)) translates the SIP-based instant messages into short/multimedia messages. The Short Message Service - Interworking Mobile Switching Center (SMS-IWMSC; see Fig. 2.1 (e)) sends/receives SMS to/from the IP-Message Gateway using standard SS7

Mobile Application Part (MAP) signaling [14], while the MMS Relay/Server (see Fig. 2.1

(f)) sends/receives MMS to/from the IP-Message Gateway. By exchanging Diameter

Credit Control Request (CCR) and Credit Control Answer (CCA) messages, the PAS (Fig. 2.1

(g)) interacts with the OCS (Fig. Fig. 2.1 (h)) to reserve the amount of prepaid credit and process the online charging information. The PAS sets up prepaid IMS-to-PSTN calls through the MGCF, the MGW and the T-SGW, and supports prepaid SMS/MMS services through interaction with the IP-Message Gateway.

The prepaid call function in PAS works as follows: By utilizing the Back-to-Back User

Agent (B2BUA) technique [55], the prepaid charging mechanism is inserted into a SIP

connection session by breaking it into two sub-sessions. In this way, the PAS can monitor and terminate the call session when the prepaid credit is depleted. To set up an

(35)

IMS-to-PSTN Terminating Switch SMS-IWMSC MMS Relay Server UE1 CSCF PAS MGCF MGW OCS

CSCF: Call Session Control Function GPRS: General Packet Radio Service IWMSC: Interworking Mobile Switching Center MGW: Media Gateway

MGCF: Media Gateway Control Function MMS: Multimedia Messaging Service

OCS: Online Charging System PAS: Prepaid Application Server

PSTN: Public Switched Telephone Network SMS: Short Message Service

T-SGW: Transport Signaling Gateway UE: User Equipment

UTRAN: UMTS Terrestrial Radio Access Network

b

a

c

e

f

Phone2

h

IP-Message Gateway

i

T-SGW UTRAN GPRS

g

d

(36)

PSTN call for an IMS user UE1, the signaling message is first routed from UE1 (Fig. 2.1 (c)) to the CSCF (Fig. 2.1 (a)). The CSCF identifies the charging type of the service (i.e., prepaid or postpaid). For a postpaid SIP request, the call is set up by standard IMS procedures. For a prepaid SIP request, the CSCF forwards the request to the PAS (Fig. 2.1 (g)) for further authorization and call session control. The details are given in the next section.

2.2

Integrating Charging for Prepaid Calls and

In-stant Messaging

This section first describes prepaid IMS-to-PSTN call setup and release. Then we describe instant message delivery through the prepaid mechanism. Finally, we describe the PAS charging policy for integrating IMS-to-PSTN calls and instant messages.

2.2.1

Prepaid IMS-to-PSTN Call Setup and Release

Consider the scenario where an IMS user (UE1; Fig. 2.1 (c)) makes a VoIP call to a PSTN user (Phone2 in Fig. 2.1 (i)). In this case, the PAS (i.e., the prepaid B2BUA) breaks the SIP session between UE1 and the MGCF into one subsession (subsession 1) between UE1 and the PAS (Fig. 2.1 (g)) and another subsession (subsession 2) between the PAS and the MGCF (Fig. 2.1 (b)).

In Fig. 2.1, the SIP INVITE request from UE1 (a prepaid user) is first routed to the PAS through the CSCF (path (1)→(2)→(3)→(4)) to establish subsession 1. Then the PAS interacts with the OCS to reserve the subscriber’s credit (path (5)). When the user’s authorized time (i.e., the prepaid credit) is granted, the PAS generates a new INVITE message for subsession 2, and then sends it to the MGCF through path (6). The MGCF instructs the T-SGW to deliver the call setup request to Phone2 via path (7). When the called party answers, the answer message is sent to the PAS through path (7)→(6). Then the PAS responds SIP 200 OK to UE1 through path (4)→(3)→(2)→(1). Finally, the PAS starts an authorized session timer with the value (the available prepaid credit) granted from the OCS. UE1 then sends the ACK message (for subsession 1) to the PAS through path (1)→(2)→(8); note that the ACK message need not be routed through the CSCF. The PAS sends the ACK message (for subsession 2) to the MGCF through path (6). At this point, the MGW opens a Real-time Transport Protocol (RTP) [50] connection so that UE1 can communicate with Phone2 through the MGW. The media path for the prepaid

(37)

UE1 CSCF PAS OCS MGCF/ MGW 1. INVITE (subsession 1) 2. CCR (INITIAL_REQUEST) 2. CCA (INITIAL_REQUEST) 3. INVITE (subsession 2) T-SGW 5. 200 OK (subsession 2) 1. INVITE (subsession 1) 6. 200 OK (subsession 1) 6. 200 OK (subsession 1)

7. ACK (subsession 1) 7. ACK (subsession 2)

RTP

8. BYE (subsession 1) 8. BYE (subsession 2)

10. REL 10. RLC 9. 200 OK (subsession 1) 9. 200 OK (subsession 2) 11. CCR (TERMINATE_REQUEST) 11. CCA (TERMINATE_REQUEST) 10. IP REL 10. IP RLC 4. IAM 4. ANM 4. IP IAM 4. IP ANM Terminating Switch / Phone2

Figure 2.2: Message Flow for Prepaid IMS-to-PSTN Call Setup and Release.

call is (1)→(2)→(9)→(10). If the prepaid credit is exhausted (i.e., the authorized session timer expires) before the conversation is complete, the call is forced to terminate by the PAS. When the authorized session timer expires, the PAS sends the BYE messages to both UE1 (path (8)→(2)→(1)) and Phone2 through the MGCF (path (6)). Specifically, the MGCF instructs the MGW to release the RTP connection, and the subsequent voice packets delivered between UE1 and Phone2 are not allowed to pass through the MGW. The MGCF instructs the T-SGW to ask Phone2 to release the call via path (7). Finally, the PAS triggers the OCS to debit the user account through path (5). The message flow for the prepaid call setup and force-termination is described below (see Fig. 2.2).

(38)

Step 2. The PAS sends a CCR message with CC-Request-Type “INITIAL REQUEST” to

the OCS to reserve the subscriber’s credit. The OCS replies to the PAS with the CCA message containing the credit information (i.e., the user’s authorized time).

Step 3. When the user’s authorized time quota is granted, the PAS generates a new

INVITE message for subsession 2, and then forwards it to the MGCF.

Step 4. The MGCF instructs the T-SGW to deliver the SS7 ISUP Initial Address

Message (IAM; the SS7 call setup message [36]) to the terminating switch of Phone2. When the called party answers, the SS7 ISUP Answer Message (ANM) is sent to the T-SGW. Then the T-SGW sends an IP-based ANM message to the MGCF.

Steps 5 and 6. The MGCF sends a final response 200 OK to the PAS; the PAS sends a

final response 200 OK to UE1.

Step 7. UE1 sends the ACK message (for subsession 1) to the PAS; the PAS sends the

ACK message (for subsession 2) to the MGCF. At this point, the MGW opens a RTP connection so that UE1 and Phone 2 can deliver voice packets through the MGW. Finally, the PAS starts an authorized session timer with the value (the available prepaid credit) granted from the OCS.

Step 8. If the prepaid credit is exhausted before the conversation is complete (i.e., the

authorized session timer expires), the call is forced to terminate by the PAS. The PAS will send the BYE messages to both UE1 and the MGCF. Then the MGCF instructs the MGW to release the RTP connection, and the subsequent voice packets delivered between UE1 and Phone2 are not allowed to pass through the MGW.

Step 9. UE1 and the MGCF reply to the PAS with 200 OK messages.

Step 10. The MGCF instructs the T-SGW to send the SS7 ISUP Release Message

(REL) to the terminating switch of Phone2. The terminating switch replies to the T-SGW with the SS7 ISUP Release Complete (RLC). Then the T-SGW sends an IP-based RLC message to the MGCF.

Step 11. Finally, the PAS sends a CCR message to the OCS. The CC-Request-Type of

the message is “TERMINATE REQUEST”. The OCS debits the user account, and then replies the PAS with a CCA message.

(39)

5. 200 OK

5. 200 OK

4. SMS

(short message)

5. 200 OK

Assuming the prepaid credit is enough to cover the charge for the messaging service

1. MESSAGE 1. MESSAGE

3. MESSAGE

IP-Message Gateway

UE1 CSCF PAS OCS UE2

2. CCR (EVENT_REQUEST)

2. CCA (EVENT_REQUEST)

Figure 2.3: Message Flow for Prepaid Messaging Delivery.

2.2.2

Prepaid Instant Messaging Delivery

The message flow for prepaid instant messaging service is shown in Fig. 2.3, and is de-scribed in the following steps:

Step 1. A prepaid user UE1 sends the SIP MESSAGE request to the PAS through the

CSCF (including P-CSCF and S-CSCF). The instant message to be delivered is attached in this SIP request.

Step 2. The PAS sends a CCR message to the OCS. The CC-Request-Type is “EVENT

REQUEST”. The OCS debits the subscriber’s prepaid account, and then replies to the PAS with the CCA message containing the cost information (i.e., the amount of credit charged for this service).

Step 3. If the amount of prepaid credit in UE1’s account is large enough to cover the

charge for the messaging service, the PAS forwards the MESSAGE request to the IP-Message Gateway.

Step 4. The IP-Message Gateway retrieves the instant message content from the MESSAGE

(40)

Step 5. The IP-Message Gateway sends the SIP 200 OK message to UE1 through the

PAS and the CSCF.

2.3

Analytic Modeling for Prepaid Application Server

The PAS for pure voice services or pure message services can be easily implemented as described in Section 2.2. However, when both voice and messaging are simultaneously offered, an important issue must be resolved for the PAS. That is, during a prepaid IMS-to-PSTN call, the user may attempt to send messages. Deduction of prepaid credit for sending out this message may result in insufficient credit left for the in-progress prepaid call. (Note that a message can be a short text or a huge multimedia data file which causes large deduction.) In this case, the IMS-to-PSTN call is forced to terminate. Therefore, a strategy is required to determine if the prepaid message can be sent out without causing force-termination of an on-going call. To avoid unnecessary force-termination, we set a threshold amount XT of credit units to protect the in-progress IMS-to-PSTN call.

Con-sider the timing diagram in Fig. 2.4. A prepaid call arrives at t1 and completes at t3. Without loss of generality, we assume that each time unit (TU) of the call is charged for 1 credit unit (CU). A prepaid authorized timer for this call starts at t1 and expires at t4. That is, the amount of the prepaid credit is t4− t1. Upon receipt of the prepaid message request at t2, where t1 < t2 < t3, the PAS estimates if the remaining credit x∗ = t4 − t2 suffices to support both the remaining call and the message service. Assume that the prepaid message service is charged for a fixed amount of Tm credit units. The strategy

used in our PAS is described as follows:

• If the remaining prepaid credit x∗ ≥ X

T + Tm, the message is sent immediately and

the amount of remaining prepaid credits is reduced to x∗− Tm.

• If not, the message is stored and will be processed after the IMS-to-PSTN call is

completed.

If XT is set too large, the PAS may reserve too many prepaid credit units, and

there-fore message deliveries are unnecessarily delayed. If XT is set too small, the PAS may

reserve too few prepaid credit units for the remaining prepaid call, and therefore results in unnecessary force-terminated (UFT) calls. We present an analytic model to derive the UFT (unnecessary force-termination) probability PU F T and the expected unnecessary

(41)

The i+1-st prepaid call completes

t

c

The i+1-st prepaid call

arrives and the authorized timer starts

Time A prepaid message arrives x* Prepaid authorized timer expires

t

d

t

1

t

2

t

3

t

4

t

0 i

The i-th prepaid

call completes

x

Figure 2.4: Timing Diagram for Prepaid Calls and Messaging Deliveries.

1. Let X be the amount of the initial prepaid credit.

2. The prepaid message arrivals are a Poisson stream with rate λm. Let N(t) be the

number of prepaid messages occurring in period t. The probability mass function of N(t) is Pr[N(t) = n] =  (λmt)n n!  e−λmt (2.1)

3. Let τi be the interval between when the i-th prepaid call completes and when the

i + 1-st prepaid call starts (i > 0). In Fig. 2.4, τi = t1 − t0. We define τ0 as

the interval between when the prepaid account is first activated and when the first prepaid call arrives. Let τi be Exponentially distributed with the mean 1/λc.

4. The prepaid call holding time tc (in Fig. 2.4, tc = t3−t1) is Exponentially distributed

with the density function

fc(tc) = µe−µtc (2.2)

2.3.1

Derivation for the Remaining Credit Density Function

Consider the timing diagram in Fig. 2.4, where a prepaid call arrives at t1 and the re-maining credit left is x = t4− t1. To derive PU F T and E[td], we first derive the density

function fx(x) of x. Let Nc be the number of prepaid calls completed during [0, t1]. Let

Xc be the amount of credit units that are consumed by the prepaid calls arrived before t1.

Since we assume that 1 TU of the call is charged for 1 CU, the amount of the consumed prepaid credit (i.e., the accumulated call holding times) for these Nc prepaid calls is Xc.

(42)

For Nc > 0, Xc has the Erlang distribution with the mean Nc/µ and the shape parameter

Nc. The conditional probability mass function of Nc given that Xc = xc can be expressed

as Pr[Nc = nc|Xc = xc]=  (µxc)nc−1 (nc−1)!  µe−µxc  i=1  (µxc)i−1 (i−1)!  µe−µxc = e −µxc(µx c)nc−1 (nc− 1)! (2.3) Let Ti = Nc

i=0τi. Since τihas the Exponential distribution with the mean 1/λc, Tihas the

Erlang distribution with the mean (Nc+ 1)/λc and the shape parameter Nc+ 1. Therefore

the density function fT(Ti) of Ti is

fT(Ti) =  λc(λcTi)Nc Nc!  e−λcTi (2.4)

Let Nm be the number of prepaid messages arrived before t1. In other words, there are

Nm prepaid messages occurring in period Xc+ Ti. Then Nm is a Poisson random variable

with the mean λm(Xc + Ti). From (2.1), the probability mass function of Nm can be

expressed as Pr[Nm = nm] = Pr[N(Xc + Ti) = nm] =  [λm(Xc+ Ti)]nm nm!  e−λm(Xc+Ti) (2.5)

Note that N(t) (see Eq. (2.1)) represents the number of prepaid messages occurring in any arbitrary period t. Therefore Nm = N(Xc+ Ti) (see Eq. (2.5)) represents the number

of prepaid messages occurring before the prepaid call arriving at t1. From (2.3)-(2.5), the conditional probability mass function of Nm given that Xc = xc is derived as

Pr[Nm = nm|Xc = xc] =  nc=1 Pr[Nc = nc|Xc = xc] ti=0 Pr[Nm = nm|Xc = xc, Nc = nc, Ti = ti]fT(ti)dti =  nc=1 e−µxc(µx c)nc−1 (nc− 1)! ti=0  [λm(xc+ ti)]nme−λm(xc+ti) nm!   (λcti)ncλce−λcti nc!  dti =  λcλmnme−(µ+λm)xc µ  ti=0 e−(λc+λm)ti nm  k=0 tkixcnm−k−1 k!(nm− k)!  nc=1 (µλcxcti)nc (nc− 1)!nc!dt i =  λcλmnme−(µ+λm)xc µ nm k=0  nc=1  (nc+ k)! (λc+ λm)nc+k+1   xcnm−k−1 k!(nm− k)!   (µλcxc)nc (nc− 1)!nc!  =  λcλmnme−(µ+λm)xc µ nm k=0  xcnm−k−1 (λc+ λm)k+1k!(nm− k)!  nc=1 µλcxc λc+ λm nc ×  (nc+ k)...(nc+ 1) (nc− 1)!  (2.6)

數據

Figure 1.1: The IMS Network Architecture.
Figure 1.2: The Online Charging System Architecture.
Figure 1.3: Diameter Message Flow for Online Session.
Figure 1.4: IMS Message Flow for Immediate Event Charging.
+7

參考文獻

相關文件

好了既然 Z[x] 中的 ideal 不一定是 principle ideal 那麼我們就不能學 Proposition 7.2.11 的方法得到 Z[x] 中的 irreducible element 就是 prime element 了..

volume suppressed mass: (TeV) 2 /M P ∼ 10 −4 eV → mm range can be experimentally tested for any number of extra dimensions - Light U(1) gauge bosons: no derivative couplings. =&gt;

We explicitly saw the dimensional reason for the occurrence of the magnetic catalysis on the basis of the scaling argument. However, the precise form of gap depends

For pedagogical purposes, let us start consideration from a simple one-dimensional (1D) system, where electrons are confined to a chain parallel to the x axis. As it is well known

The observed small neutrino masses strongly suggest the presence of super heavy Majorana neutrinos N. Out-of-thermal equilibrium processes may be easily realized around the

incapable to extract any quantities from QCD, nor to tackle the most interesting physics, namely, the spontaneously chiral symmetry breaking and the color confinement.. 

(1) Determine a hypersurface on which matching condition is given.. (2) Determine a

• Formation of massive primordial stars as origin of objects in the early universe. • Supernova explosions might be visible to the most