Third Party Data Session Control in the Evolved Packet System

Third Party Data Session Control in the Evolved Packet System

EVELINA PENCHEVA

Faculty of Telecommunications

Technical University of Sofia

8 Kliment Ohridski blvd., 1000 Sofia

BULGARIA

[email protected]

Abstract: - The paper studies implementation issues of third party application control on packet data sessions in the Evolved Packet System (EPS). The research is based on the standardized functional architecture for Policy and Charging Control. Open Service Access (OSA) application programming interfaces for Data Session Control are considered and their deployment in all Internet Protocol based networks is described. A formal approach to functional verification of OSA application server is presented. The approach may be used to generate automatic tests for verification of OSA gateway behavior.

Key-Words: - Open Service Access, Policy and Charging Control, Finite State Machines, Formal functional verwitication

1. Introduction

Evolved Packet System (EPS) is standardized by the Third Generation Partnership Project (3GPP) as evolution of all Internet Protocol based packet networks that allows evolution of any deployed wireless or wired access technology. EPS provides mechanisms for quality of service and policies to control and manage services and to differentiate charging [1], [2]. The standard supports delivery of combinations of multimedia telephony and internet services hosted by the network operator or third party service provider [3], [4]. Opening the network interfaces for third party stimulates service provisioning and promotes the convergence between IT applications and public telecommunication services [5], [6], [7].

Open Service Access (OSA) is a technology which illustrates the convergence of IT and telecommunications. OSA allows third party applications to invoke communication functions in a public network using application programming interfaces. Network functions accessed by applications are called Service Capability Features (SCF) [8]. Application programming interfaces (APIs) are defined for each OSA SCF exposed toward the applications. The OSA Data Session Control SCF allows setting up, releasing, and managing packet data sessions [9]. The 3GPP standards define OSA Data Session Control

interfaces mapping in packet switched mobile intelligent networks [10]. Deployment of Data Session Control interfaces in EPS networks allows third party applications access to policy and charging functions and requires the respective interface to protocol mapping. Some publications concerning OSA SCF implementation, focus on aspects related to the APis, while other authors discuss evaluation of conformance of the session control mechanisms in the network out of the application context [11], [12], [13].

In this paper, some implementation issues of OSA Data Session Control APIs in EPS networks deploying dynamic policy and charging control are studied. In Section 2, functional architecture for third party control on packet data sessions is considered. Section 3 presents the suggested protocol view on the packet data session states and both state models as seen by the network and third party applications are formally described. In Section 4, an approach to formal verification of application server that supports Data Session Control interfaces and the policy and charging control protocol is presented.

2. Functional architecture for

deployment of third party control on

packet data sessions in EPS

3GPP standards define Policy and Charging Control (PCC) architecture aimed to provide means for authorization and control the usage of bearer resources intended for packet data traffic [14]. The overall operator control on Quality of Service (QoS), source/destination of data traffic and the start and stop of the packet data traffic is based on policies and allows flow based charging.

The functional architecture for third party control on packet data sessions in EPS networks is shown in Fig.1. The figure does not present all PCC functional entities but those that are related to the current research.

Fig.1 Functional architecture for 3rd party control on packet data sessions in PCC enabled networks The Policy and Charging Rule Function (PCRF) is responsible for making PCC decisions based on session and media related information obtained from the Application Function (AF). The PCRF generates charging rules and authorizes the bearer resources with the appropriate QoS for the packet flows. The AF extracts the session information from session related signaling during session establishment between two parties. The AF may provide initial session information not fully negotiated yet at an earlier stage in order to allow service authorization. The AF provides final session information based on negotiated session parameters between two parties. The AF may modify session information at any time (e.g. due to application requested increase of data rates). Depending on the application, in service information provision, the AF may instruct the PCRF

when the packet flows are to be enabled or disabled to pass through the access network and thus providing gating control. When the packet data session is terminated (e.g. due to the application request), the AF report this to the PCRF. The AF may subscribe to receive notifications about QoS events related to the packet data session. In case of available subscription, on occurrence of QoS events the PCRF notifies the AF. The signaling protocol used for PCC at the reference point between AF and PCRF is Diameter [14]. The AF may be Application Server (AS) that hosts application logic.

To enable party control on packet data sessions, the network operator needs to deploy a special type of AS that is OSA gateway. The OSA gateway exposes OSA interfaces towards exterior of the network and control protocols toward the interior of the network. The OSA gateway needs to perform functional mapping between OSA interface methods and Diameter messages.

3. Data session state models

The OSA gateway which supports Data Session Control interfaces toward the external applications and Diameter protocol towards the network needs to maintain two mutually synchronized models representing the data session states. The model representing the application view on data session states is defined in [9]. According to that model, the data session object can be in one of the following states. In Idle state, the data session object is not created. The Setup state is entered when the reportNotification method indicates that a data session, which the application is interested in, is setup. In Setup state, the application can request session establishment to the remote party by invoking connectReq method. In Established state, the application is notified that the session is established. In NetworkReleased state, the session is terminated and the application can gather session information. In ApplicationReleased state, the data session is terminated by the application. From data session control point of view, the Idle, Network released and Application released states are equivalent, as far as the data session is neither in establishing nor in active phase.

3GPP standards define the procedures at the reference point between the PCRF and the AF but do not provide a model that represents the AF view on packet data session in the context of PCC [15]. As

3rd party domain

AS

OSA interfaces Diameter Media gateway AF OSA gateway Diameter PCRF

mediation functionality between third party applications and PCC related functional entities, the OSA gateway needs also a model that represents the Diameter view on the packet data session states. This model has to reflect the states of the QoS resources authorized for the packet data session in order to provide the AF with means for QoS control and usage monitoring.

The suggested model representing the states of QoS resources authorized for a packet data session is shown in Fig.2.

Fig. 2 Model representing the states of QoS resources authorized for a packet data session

In Idle state, no QoS resources are authorized for the session. If the application receives notification about session setup signaled by Diameter command Re-Authorization Request (RARSS) the QoS resources state moves to AuthorizeServiceInfo. If the application receives notification about session establishment signaled by Diameter command RARSE the QoS resources state becomes AuthorizeSessionInfo. In Idle state, an application or service requiring dynamic PCC interacts with the AF which extracts session information from application signaling and provides this to the PCRF by sending a Diameter command for initial session establishment

(AARISE). This results in transition to

AuthorizeServiceInfo state. It is possible for the AF to subscribe to QoS events by Diameter command Authentication-Authorization Request (AARSE). In

AuthorizeServiceInfo state, the early authorization check of the service information is performed. When final session parameters are negotiated, the AF sends a Diameter command to the PCRF for final session information (AARFSE). This results in transition to AuthorizeSessionInfo state. In AuthorizeSessionInfo state, on behalf of application, the AF may request media component removal (AARMCR), provide gating control (AARGC), subscribe for QoS event notification (AARSE) and be notified about QoS events (RAREN). The AF may send initial session modification information (AARISM) and final session modification information (AARFSM) to the PCRF in order to authorize the session modification. In AuthorizeServiceInfo state and AuthorizeSessionInfo state, if all bearers assigned to the session are lost, the PCRF requests the AF session abort by sending a Diameter command Abort Session Request (ASRABR). The AF also may initiate session termination by sending a Diameter Session Termination Request (STRST). These result in transition to Idle state.

The formal specification of packet data session state models as Labeled Transition Systems allows usage of formal means to prove the synchronized behavior of both models in the OSA gateway. This may be used for automatic generation of test cases during the functional verification of OSA gateway.

To prove behavioral equivalence between state machines formally, the notion of Labeled Transition Systems is used [16].

Definition 1: A Labeled Transition System (LTS) is a quadruple (S, Аct, →, s0), where S is a countable set of states, Act is a countable set of elementary actions,

→⊆S × Act × S is a set of transitions, and s0 ∈S is a set of initial states.

By TDiameter=(SDiameter, ActDiameter, →Diameter, s0) it is denoted an LTS which represents a simplified QoS resources state model reflecting the third party application view where:

- SDiameter = {Idle, AuthorizeServiceInfo, AuthorizeSessionInfo},

- ActDiameter = {AARISE, AARFSE, AARISM, AARFSM,

AARMCR, AARGC, AARSE, RAREN, RARSS, RARSE,

STRST, ASRABR},

- →Diameter = {Idle AARISE AuthorizeServiceInfo,

Idle RARSE AuthorizeSessionInfo,

Idle RARSS AuthorizeServiceInfo,

AuthorizeServiceInfo AARSE AuthorizeServiceInfo,

AuthorizeServiceInfo AARFSE AuthorizeSessionInfo,

AuthorizeServiceInfo RARSE AuthorizeSessionInfo,

AuthorizeServiceInfo STRST Idle, Idle Authorize ServiceInfo Authorize SessionInfo AARISE AARFSE STRST ASRABR AARSE RARSE RARSS RARSE AARMCR,RAREN, AARISM, AARFSM, AARSE, AARGC

AuthorizeServiceInfo ASRABR Idle,

AuthorizeSessionInfo AARIMS AuthorizeSessionInfo,

AuthorizeSessionInfo AARFSM AuthorizeSessionInfo,

AuthorizeSessionInfo AARGC AuthorizeSessionInfo,

AuthorizeSessionInfo AARMCR AuthorizeSessionInfo,

AuthorizeSessionInfo AARSE AuthorizeSessionInfo,

AuthorizeSessionInfo RAREN AuthorizeSessionInfo,

AuthorizeSessionInfo STRST Idle,

AuthorizeSessionInfo ASRABR Idle},

- s0= {Idle}.

By ТDSC = (SDSC, АctDSC, →DSC, s0’) it is denoted an LTS, representing the OSA application view on data session state where:

-SDSC = {IdleDSC, SetupDSC, EstablishedDSC}; - ActDSC = {dataSessionSetup,

dataSessionEstablished, connectReq, release, dataSessionDisconnected,

dataSessionSupervisionEvent},

-→DSC = {IdleDSC dataSessionSetup SetupDSC,

SetupDSC connectReq SetupDSC

SetupDSC dataSessionEstablished EstablishedDSC,

IdleDSC dataSessionEstablished EstablishedDSC,

SetupDSC dataSessionDisconnected IdleDSC,

SetupDSC release IdleDSC,

EstablishedDSC dataSessionDisconnected IdleDSC,

EstablishedDSC release IdleDSC

EstablishedDSC dataSessionSupervisionEvent

EstablishedDSC}; - s0’= {IdleDSC }.

Having the formal descriptions of data session state model and QoS resources state model by LTSs, we use the concept of weak bisimulation to prove that both LTSs expose equivalent behavior.

4. An approach to formal verification

of functional behavior of OSA gateway

The following notations are used:

- s→а s’ stands for the transition (s, a, s’); - s а

→

means that ∃ s’: s а

→

s’; - s µ

⇒

sn , where µ = а1, а2, ..., аn : ∃s1, s2, …, sn, such that s 1 а →s1 ... n а

→

sn; - s µ

⇒

means that ∃s’, such as s

µ

⇒

s’; -

_⇒

µˆ means ⇒ if μ ≡ τ or

µ

⇒

otherwise, where τ is one or more internal (invisible) actions.

The concept of bisimulation is used to prove that two LTSs expose equivalent behavior [16]. The strong bisimulation possesses strong conditions for equivalence which are not always required. For example, there may be internal activities that are not observable. The weak bisimulation ignores the internal transitions.

Definition 2: Two Labeled Transition Systems T = (S, A, →, s0 ) and T’ = (S’, A, →’, s0’) are weakly

bisimilar if there is a binary relation U⊆ S×S’ such that if s1U t1: s1 ⊆S and t1 ⊆S’ then ∀a ∈Act:

- s1

⇒

a s2 implies ∃t2: t1

⇒′

aˆ t2 and s2U t2;

- t1

⇒′

a

t2 implies ∃s2: s1

⇒

aˆ s2 and s2U t2. In order to prove that both models as seen by a third party application and by the network running at the OSA gateway are synchronized, it has to be proved that both LTSs, that formally describe the models, expose equivalent behavior. The behavioral equivalence is proved using the concept of weak bisimilation.

Proposition: The LTSs ТDSC and ТDiameter are

weakly bisimilar.

Proof: To prove the bisimulation relation between LTSs, it has to be proved that there is a bisimulation relation between their states. First, homomorphism between the АctDSC and ActDiameter is identified in Table 1.

Table 1 Homomorphism between ActDSCand

ActDiameter

ActDSC ActDiameter

dataSessionSetup AARISE, RARSS

connectReq AARFSE, RARSE

dataSessionEstablished RARSE

release STRST

dataSessionDisconnected ASRABR

dataSessionSupervisionEvent AARMCR,RAREN,

AARISM,

AARFSM, AARSE,

AARGC

superviseDataSessionReq AARSE

By U it is denoted a relation between the states of

ТDSC and ТDiameter where U = {( IdleDSC, Idle),

(SetupDSC, AuthorizeServiceInfo), (

relation between the states of ТDSCand ТDiameterwhich

satisfies the Definition 2.Based on the bisimulation relation between the states of ТDSC Sand ТDiameter it can

be concluded that ТDSCand ТDiameterexpose equivalent

behavior.

Table 2 Bisimulation relation between TDSCand

ТDiameter s1

⇒

a s2 | s1, s2 ∈ SDSC t1

⇒′

aˆ t2 | t1, t2 ∈ SDiameter IdleDSC dataSessionSetup SetupDSC

Idle AARISE

AuthorizeServiceInfo SetupDSC dataSessionEstablished EstablishedDSC AuthorizeServiceInfo AARFSE AuthorizeSessionInfo EstablishedDSC dataSessionSupervision-Event EstablishedDSC AuthorizeSessionInfo AARMCR AuthorizeSessionInfo, AuthorizeSessionInfo AARGC AuthorizeSessionInfo, AuthorizeSessionInfo RAREN AuthorizeSessionInfo, AuthorizeSessionInfo AARISM AuthorizeSessionInfo, AuthorizeSessionInfo AARFSM AuthorizeSessionInfo EstablishedDSC release IdleDSC AuthorizeSessionInfo STRST Idle EstablishedDSC dataSessionDisconnected IdleDSC AuthorizeSessionInfo ASRABR Idle

SetupDSC release IdleDSC AuthorizeServiceInfo

STRST Idle

SetupDSC

dataSessionDisconnected IdleDSC

AuthorizeServiceInfo ASRABR Idle

SetupDSC dataSessionEstablished EstablishedDSC, AuthorizeServiceInfo RARSE AuthorizeSessionInfo IdleDSC dataSessionEstablished EstablishedDSC, Idle RARSE AuthorizeSessionInfo

The detailed formal description of both models representing the packet data session states as view by

the application and by the network, including behavior in case of errors makes possible to automate the process of generation of test sequences to verify the functional behavior of the OSA gateway.

5. Conclusion

The deployment of third party control on packet data sessions in the EPS requires provisioning of open access to network functions related to policy and charging control. External applications access .the policy and charging functions using OSA Data Session Control interfaces instead of network control protocols. A key role in this context plays the OSA gateway which needs to perform interoperability functions mediating between applications and network entities. The suggested formal approach to functional verification of OSA gateway may facilitate its implementation and shorten the time to market for differentiated services.

Acknowledgement:

The research is in the frame of Project DDBY02/13/17.02.2010 funded by National Science Fund, Bulgarian Ministry of Youth, Education and Science.

References:

[1] J. Balbas,, S. Rommer, J. Stenfelt, Policy and charging control in the evolved packet system,

IEEE Communications Magazine, 2009, vol.47, issue 2, pp.68-74.

[2] S. Quellette, L. Marchad, Pierre, Samuel, A potential evolution of the policy and charging control/QoS architecture for the 3GPP

IETF-based evolved packet core, IEEE

Communications Magazine, 2011, vol.49, issue 5, pp.231-239.

[3] L. Baleh, L. Suciu, J. Bonnin, Enriched connectivity-as-a-service for dynamic

Mobile-Cloud, Proc. of IEEE Consumer

Communications and Networking Conference CCNC’2012, pp.655-660.

[4] R. Copeland, N. Crespi, Policies to Enable Serving Untrusted Services on Alternative (Non-3GPP) and Untrusted Access Networks in EPS,

Proc. of IEEE Computer Software and Applications Conference Workshops COMPSACW’2011, pp.48-53.

[5] B. Odadzic, M. Jankovic, Open service access (OSA) business models and service level agreement aspects, Proc. of IEEE International Conference on Telecommunications in Modern Satellite, Cable and Broadcasting Service TELSIKS’2003, vol.1, pp.22-25.

[6] J. Yang, H. Park, A Design of Open Service Access Gateway for Converged Web Service,

Proc. of International Conference on Advanced Communication Technology, ICACT’2008,

pp.1807-1810.

[7] M. Adeyeye, Future directions of converged services in the Web session mobility scenarios,

Proc. of International Conference AFRICON’2011, pp.1-5.

[8] H. Hanrahan, Network Convergence, Services, Applications, Transport and Operations Support, Wiley, 2007.

[9] 3GPP TS 29.198-08 Open Service Access (OSA); Application Programming Interface (API) Part 8: Data Session Call Control Service Capability Feature; Release 9, 2009, v9.0.0. [10]3GPP TR 29.998-04-1 Open Service Access

(OSA); Mapping for Open Service Access; Part 4, Call Control Service Mapping; Subpart 2: API to CAP mapping, Release 9, 2009, v9.0.0..

[11]I. Chlamtac, H. Lee, Y Lin, M Tsai, An OSA service capability server for mobile services,

International Journal of Pervasive Computing and Communications, 2008, vol. 4, issue 3, pp. 268-278.

[12]T.Magedanz, D. Witaszek, K. Knüttel, Service Delivery Platform Options for Next Generation Networks, approved within the national German 3G Beyond Testbed, 2004, Retrieved from http://home.intekom.com/satnac/proceedings/20 04/Plenary/Magedanz.pdf

[13]S. Walker, Providing IMS Services to Legacy Network Endpoints, 2009, Retrieved from http://www.iec.org/newsletter/august07_1/analy st_corner.pdf.

[14]3GPP TS 23.203 Policy and charging control architecture, Release 12, v12.0.0, 2013.

[15]3GPP TS 29.213 Policy and Charging Control signaling flows and Quality of S ervice (QoS) parameter mapping, Release 11, v11.6.0, 2013. [16] P. Panangaden, Notes on Labeled Transition

Systems and Bisimulation, 2009, Retrieved from http://www.cs.mcgill.ca/~prakash/Courses/comp 330/Notes/lts09.pdf.