Application Based Charging

Rajeswari Chirravuri
PES,Aricent Technologies Limited Bangalore, India Raja chirravuri!aricent com

Content 1 Abstract........................................................................................................3 2 Introduction...................................................................................................4 2.1 Background...............................................................................................4 2.2 Operator Benefits......................................................................................4 3 Traditional Architecture.................................................................................5 4 Architecture require ents for 3!"" #elease 11..........................................$ 5 Application %etection and &nforce ent "rocedures using T%'...................( ) %eplo* ent +ethods..................................................................................1, ).1 -d Interface for A%. #ules.....................................................................1, ).2 -* &/tension for Online .harging and "olic* -tatus...............................1, ).3 0se .ases...............................................................................................1, $ #oad ap for oneti1ation.........................................................................11 2 .onclusion .................................................................................................12 ( #eferences ................................................................................................13

"

AB-T#A.T 3!"" has introduced a ne3 node4 T%' in #elease 11 in ".. architecture. This paper describes the traditional application based charging applications4 ho3 ne3 application de5elop ent can le5erage the T%' functionalities introduced in #elease 11 and operators can benefit for this architecture. Also4 e/tensions for -* interface identified6proposed in 3!"" release 12 are e5aluated.

I7T#O%0.TIO7 Background 8ith the increase of o5erall data 5olu es in 3! net3orks and re5enues incurred4 +obile operators are looking opti i1ing obile infrastructure costs. +ost a9or operators feel that properl* re:designing the obile net3ork infrastructure is i portant for anaging O"&;6.A"&; costs. Transfor ation is happening at ultiple la*ers of the infrastructure topolog*4 fro deplo*ing self:organi1ing <T& radio access net3orks4 e5ol5ing the packet core =&".>. Operators can benefit in ultiple 3.r.t ne3 business opportunities and re5enues if re:architecting is considered.

2.1

2.2

Operator Benefits After data path e5olution in 3!""4 3ith different ethods for content6data charging? current designs are cluttered thus causing the duplication of nodes and resulting in ore operational costs for operators 3hich is decreasing the re5enue. To architecture6rethinking on ho3 content charging is done4 operators need to? 1. Adapt to ne3 standards. 2. Transfor or o5e fro thinking of operator based odel to user dri5en charging and content based charging.

T#A%ITIO7A< A#.@IT&.T0#& .on5entionall*4 the "olic* and .harging .ontrol ="..> architecture includes a "olic* and .harging &nforce ent 'unction =".&'> in charge of traffic flo3 detection and enforce ent of applicable policies to user traffic flo3s4 a "olic* and .harging #ules 'unction =".#'> in charge of pro5iding net3ork control for the traffic flo3 detection b* holding policies and pro5iding ".. rules to the ".&' per user traffic flo3 basis for enforce ent of such policies. The old ".. used to rel* on the A' =Application 'unction> to gi5e application related infor ation to ".#' o5er #/ interface4 and then ".#' can create -%' and related ".. rules for these applications and install these rules in ".&' or BB&#' =of course these can also be preconfigured in ".&'6BB&#' 3ithout ".#' and A' interaction>. @o3e5er4 in the real 3orld an* applications or ser5ices donAt ha5e a standard A' in the picture and no application specific signalling is a5ailable o5er #/ interface. ItAs also i practical to pre:configure all the filters and ".. rules in the gate3a*s for so an* applications. -o under the old ".. arch4 the ".#'6".&'6BB&#' canAt reall* differentiate these applications and pro5ide different gating and Bo- controls.

-o4 3!"" introduced the ne3 T%' function. The ".#' is supposed to pro5ide T%' 3ith application detection characteristics4 and so the T%' can detect the defined applications fro the uplink6do3nlink traffic and report it to the ".#'4 then ".#' can ake "..6A%. rules and install the in ".&'6T%'. -o 3ith the ne3 T%' entit*4 the A' is out of the picture and 3!"" can resol5e the application a3areness proble b* itself. The T%' is a logical entit* and can be i ple ented 3ithin the ".&'. The 3!"" T- 23.2,3 511.,.1 introduces a Traffic %etection 'unction =T%'> as part of the 3!"" #elease 11 for "olic* and .harging .ontrol ="..> architecture. The ai of such functionalit* is to ake the net3ork be ser5ice a3are in order to enhance user e/perience.

This 3ill translate in the addition of a standardi1ed Traffic %etection 'unction =T%'> to the ".. reference architecture. The T%' 3ill be responsible for? 1. Application traffic detection 2. #eporting of solicited traffic classification =like "2"4 CoI"4 5ideo...> to the ".#' 3. 0sage +onitoring =5olu e> 4. "olic* control for the detected application trafficD 5. !ating E#estriction6BlockingF of application based traffic. ). #edirection of detected application traffic. $. Band3idth6Traffic shaping

A#.@IT&.T0#& #&B0I#&+&7T- 'O# 3!"" #&<&A-& 11

It shall be possible to appl* charging for net3ork usage per detected application in the s*ste 3hen T%' perfor s application detection4 according to rules recei5ed fro the ".#'. Both online and offline charging shall be supported. The application based charging shall support the follo3ing charging odels? : Colu e based charging? : Ti e based charging? : Colu e and ti e based charging? : &5ent based charging? : 7o charging. In case of &5ent based charging4 it shall be configured at T%'4 per each Application Identifier4 3hich e5ents to count. In case of Ti e or Colu e G ti e based charging4 the ti e shall be follo3ing the sa e principles as defined b* the T- 32.2(( E5F. easured

Application based charging shall be applicable 3hen the T%' applies enforce ent actions to the detected applicationHs trafficD gating4 band3idth li itation and redirection and the corresponding charging shall be pro5ided properl* e.g. gated traffic is not to be counted. 8hen the T%' perfor s these actions4 the architecture shall ensure that there is accurate charging for the net3ork usage b* an application =i.e. net3ork usage should not be charged as part of both a ser5ice data flo3 and as part of an application>.

It shall be possible to appl* different rates and charging odels per detected application 3hen a user is identified to be roa ing fro 3hen the user is in the ho e net3ork. 'urther ore4 it shall be possible to appl* different rates and charging odels based on the location of a user4 be*ond the granularit* of roa ing. It shall be possible to appl* a separate rate to the net3ork usage for a specific detected application4 e.g. allo3 the user to access an application dee ed b* the operator as no charge and another application 3ith a rate causing a charge. It shall be possible to change the rate per detected application based on the ti e of da*. It shall be possible to enforce per:detected application usage li its for the net3ork usage b* an application using online charging on a per user basis = a* appl* to prepaid and post:paid users>. It shall be possible for the online charging s*ste to set and send the thresholds =ti e and6or 5olu e based> for the a ount of re aining credit per detected application. In case it is detected that an* of the ti e based or 5olu e based credit falls belo3 the threshold4 a request for credit re:authori1ation to the O.3ith the re aining credit =ti e and6or 5olu e based> shall be sent. It shall be possible for the charging s*ste : @o e65isited net3ork? : Ti e of da*? : I":.A7 specific para eters. The charging s*ste aintains the tariff infor ation4 deter ining the rate based on the abo5e input. Thus the rate a* change e.g. as a result of I":.A7 session specific para eters change. The charging odel applicable to a detected application a* change as a result of e5ents identified b* the O.- =e.g. after ha5ing spent a certain a ount of ti e and6or 5olu e4 the user gets to use so e application for free>. The charging rate or charging odel applicable to a detected application a* change as a result of ha5ing used the application for a certain a ount of ti e and6or 5olu e. In the case of online charging4 it shall be possible to appl* an online charging action upon Application -tart6-top e5ents. It shall be possible to indicate that interactions 3ith the charging s*ste s are not required for a specific detected application4 i.e. to perfor neither accounting nor credit control for this application4 and then no offline charging infor ation is generated. to select the applicable rate based onD

&

A""<I.ATIO7 %&T&.TIO7 A7% &7'O#.&+&7T "#O.&%0#&- 0-I7! T%' T%' akes use of A%. #ules for notif*ing the ".#' of the beginning and end of application traffic. That is4 the A%. #ules can be used for identif*ing <a*er $ applications. In this respect4 A%. rules can be used b* %eep "acket Inspection =%"I> ethods for traffic identification and classification. On the other hand4 the ".. #ules are significantl* si pler than the A%. rules since the ".. rules deal 3ith a <a*er 3 'ilter or I" 5:tuple. 'or e/a ple4 an access to t3o different applications a* be identified 9ust b* one single ".. #ule4 3hile t3o A%. #ules 3ill be needed for identif*ing the application properl* =for instance4 distinguishing bet3een -k*pe and +-7 on top of @TT" traffic>. +oreo5er4 the A%. rules can be applied for all traffic in a 3hole I":.A7 session4 3hereas the ".. rules are associated 3ith one bearer each4 thus not likel* being applicable for the 3hole I":.A7 session. 'urther ore4 the '.. #ules also include para eters for ser5ice data flo3s4 for e/a ple !B#4 3hich are irrele5ant for ser5ice a3areness. 3!"" T- 23.2,3 511.,.1 describes t3o 3a*s for the T%' reporting to the ".#'D I0nsolicitedI4 3hereb* ser5ices to be detected b* the T%' are pre:configured in the T%' and are applicable for all users? and I-olicitedI4 3hereb* ser5ices to be detected are pro5isioned b* the ".#' on a per user and I":.A7 session basis through pro5isioning of so:called Application and %etection .ontrol =A%.> #ules to the T%'.

'

%&"<OJ+&7T +&T@O%Sd Interface for ADC Rules -d interface is used for fetching the A%. rules fro T%'.

6.1

6.2

Sy E tension for Online C!arging and "olicy Status In 3!"" #elease 124 5arious options for .harging -%' and 768 usage are considered and and e/tending -* interface for .redit anage ent also is one of the . -* interface can be enhanced so the ".#' can correlate the infor ation recei5ed for ".. and for A%. #ules and report to the O.- b* using -*. 8ith this enhance ent !* can be replaced b* -*.

6.#

$se Cases 0se cases that can i ple ent -d4 -* interfaces are? "roduct that charges for application usage and no charge for ser5ice data flo3. "roduct that charges for application usage and ser5ice data flo3 also. "roduct that charges onl* for ser5ice data flo3s.

#OA%+A" 'O# +O7&TIKATIO7 +ain benefits of using this ne3 architecture are? Increased customer engagement: Operators are looking for ne3er 3a*s to attract and retain users4 to i pro5e their brand positioning and to a/i i1e the benefits b* fuelling sales of data plans a ong the di5ersit* of usage patterns and needs. Operators can introduce features like? 0ser dri5en featuresD -elf:ser5ice for top:ups based on Bo-. "ro5ision for Calue added ser5ices like 0ser dri5en plans based on consu ption. 'riends G 'a il* packages Open B2B2C opportunities: B* e/posing polic* and charging assets to the Internet ecos*ste through the4 ne3 3a*s in 3hich operators can capitali1e on oneti1ation opportunities beco e possibleD Application-driven policy enforcement: Traffic anage ent and enforce ent is t*picall* applied fro a net3ork perspecti5e4 3here the operator decides for instance 3hen and ho3 5ideo opti i1ation is applied. -till end:users and e5en content o3ners are often in a better position to decide ho3 traffic should be best anaged b* the operator and 3hen to appl* band3idth or content opti i1ation techniques. Opening an interface to the Internet ecos*ste 3here content deli5er* capabilities like caching4 band3idth reser5ation4 opti i1ation4 charging can be selecti5el* enabled on specific flo3s 3ill e5entuall* enhance the content o3nersA applications and the end:user satisfaction 3hile respecting the operator needs and i perati5es. Application traffic subsidy: -er5ices or content can be charged through the Ldata charges bundled 3ithin the application conceptA. B* appl*ing application:dri5en charging rules =like selecti5e traffic 1ero:rating>4 the operator can enable a broad range of possibilities con5erting its charging fle/ibilit* capabilities into a po3erful business asset for 3rd parties. "ersonali1ed traffic and content pro otion bundles4 traffic subsidi1ed through sponsorship or ad5ertising4 enterprise4 public or go5ern ent funded ser5ices are so e e/a ples of ho3 intelligent charging can spur ser5ice and content consu ptions be*ond the classic odels.

.O7.<0-IO7 %espite a long histor* of obile data traffic anage ent4 the obile industr* is still figuring out ho3 to deplo* scalable4 cost:effecti5e and fle/ible data path architectures. One of the ain reasons is that operatorsA net3orks are supporting traffic that is not under their control. Internet pla*ers are the ones putting the constraints and pressure on operatorsA infrastructure and no one can foresee ho3 future inno5ations in the Internet 3ill further i pact the operatorsA infrastructures. .onsidering these ne3 trends4 it 3ill benefit operators if the* adapt to standardi1ed ethods b* 3!"" so that sea less integration 3ith ne3 technologies is achie5ed and reduced O"&; and .A"&; costs can be achie5ed 3ith lesser 768 nodes.

#&'&#&7.&+", $-PP TS #$ )../ 0Stud1 on Application Based Charging0