(12) United States Patent
`Duan
`
`(10) Patent N0.:
`(45) Date of Patent:
`
`US 8,531,971 B2
`Sep. 10, 2013
`
`US008531971B2
`
`(54) METHOD FOR CONTROLLING CHARGING
`OF PACKET DATA SERVICE
`
`(75) Inventor: XiaOqiH Dllall, ShenZhen (CN)
`
`(73) Assignee: HuaWei Technologies Co., Ltd.,
`ShenZhen (CN)
`
`( * ) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U'S'C' 1546)) by 84 days‘
`
`(21) APP1- NO-I 13/277,506
`
`(22) Filed:
`
`Oct. 20, 2011
`
`(65)
`
`_
`_
`_
`Prior Publication Data
`US 2012/0033560 A1
`Feb. 9, 2012
`
`CN
`CN
`
`(58) Field of Classi?cation Search
`USPC ....... .. 370/252i259, 328*389; 455/4054122;
`709/2 1 9*229
`See application ?le for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`5,598,417 A
`l/ 1997 Crisler et al.
`2
`$331 et 3:51
`5,917,897 A
`6/1999 Johnson et a1.
`5,963,625 A 10/1999 Kawecki et al.
`6,023,499 A
`2/2000 Mansey et a1.
`
`,
`
`,
`
`ay or e
`
`.
`
`(Continued)
`
`FOREIGN PATENT DOCUMENTS
`1222017 A
`7/l999
`1444824 A
`9/2003
`(Continued)
`OTHER PUBLICATIONS
`
`Related US. Application Data
`_
`_
`_
`_
`(63) Cont1nuat1on of appl1cat1on No. 13(190,817, ?led'on
`Jul. 26, 2011, Wh1ch 1s a cont1nuat1on of appl1cat1on
`No. 11/502,921, ?led on Aug. 11, 2006, noW Pat. No.
`8,009,573, Which is a continuation of application No.
`PCT/CN2005/000388, ?led on Mar. 28, 2005.
`
`Foreign Application Priority Data
`(30)
`A r 1 200 4
`(CN)
`200 4 1 0030955
`Apr' 9’ 200 4
`(CN) """""""""""" " 200 4 1 0033721
`p '
`’
`"""""""""""" "
`(51) Int Cl
`H02”! 208
`H04L 12/56
`H04W 4/00
`G0 6 F 15/1 73
`(52) U 5 Cl
`
`(2006 01)
`(201 1'01)
`(200901)
`(200601)
`'
`
`Communication from the European Patent Of?ce in Application No.
`05 738 25904525 dated Jan‘ 16, 2008'
`_
`(Con?rmed)
`
`-
`Primal,
`y Examiner * Man Phan
`(74) Attorney] Agent] or Firm i Staas & Halsey LLP
`
`ABSTRACT
`(57)
`A method for controlling the charging of packet data service
`is disclosed, Which includes: monitoring a number of event
`triggers; and When one of the event triggers is met, a TPF
`requesting charging rules from a CRF. In this Way, the timing
`that the TPF requests charging rules from the CRF becomes
`controllable, and redundant information caused by the unnec
`essary charging rule from the TPF becomes avoidable, Which
`enables interaction between the TPF and the CRF more effec
`tive and the charging control of packet data service reasonable
`
`USPC ......... .. 370/241; 370/328; 370/395; 455/406;
`709/223
`
`and Perfect"
`
`11 Claims, 8 Drawing Sheets
`
`502
`
`601
`
`603
`
`dymizlrigguevnnpnimc, m)
`
`Sum 11:: dymin mg: ml“
`pain. 1111, 1mm durgillg n11:
`
`T-MOBILE EXHIBIT 1101
`
`

`

`US 8,531,971 B2
`Page 2
`
`(56)
`
`References Cited
`
`OTHER PUBLICATIONS
`
`U.S. PATENT DOCUMENTS
`6,434,380 B1
`8/2002 Andersson et al.
`6,985,567 B2
`1/2006 Vallinen et al.
`7,017,050 B2
`3/2006 Dalton, Jr. et al.
`7,203,301 B1
`4/2007 Mudd et al.
`7,260,193 B2
`8/2007 Zackrisson et a1.
`7,266,116 B2
`9/2007 Halpern
`7,391,854 B2
`6/2008 Salonen et al.
`7,689,203 B2
`3/2010 Zhang et al.
`7,831,247 B2 * 11/2010 Gabor et al. ............. .. 455/422.1
`
`
`
`
`
`7,843,860 B2 * 11/2010 Boman 7,889,650 B2 * 2/2011 Duan ........ ..
`
`5/2011 Hurtta et al.
`7,948,990 B2 *
`..
`7,957,719 B2* 6/2011 Wu ........ ..
`8,009,573 B2 *
`8/2011 Duan .......................... .. 370/252
`2002/0101858 A1
`8/2002 Stuart et al.
`2002/0129088 A1
`9/2002 Zhou et al.
`2002/0138331 A1
`9/2002 Hosea et al.
`2002/0152319 A1 10/2002 Amin
`2002/0174212 A1* 11/2002 Casati et al. ................ .. 709/223
`2002/0188562 A1 12/2002 Igarashi et al.
`2003/0014367 A1
`1/2003 Tubinis
`2003/0125013 A1
`7/2003 Mizell et al.
`2003/0152039 A1
`8/2003 Roberts
`2003/0153333 A1
`8/2003 Shirai et al.
`2003/0165222 A1
`9/2003 Syrjala et al.
`2003/0200313 A1 10/2003 Peterka et al.
`2004/0017905 A1
`1/2004 Warrier et al.
`2004/0125755 A1
`7/2004 Roberts
`2004/ 0127194 A1
`7/ 2004 Lippelt
`2004/0162054 A1 *
`8/2004 Thiebot ....................... .. 455/406
`2004/0255025 A1 12/2004 Ricagni
`2005/0135264 A1
`6/2005 Popoff et al.
`2006/0050711 A1
`3/2006 Lialiamou et al.
`2006/0234674 A1 10/2006 Koskinen et al.
`2007/0033274 A1* 2/2007 Duan .......................... .. 709/223
`2007/0115861 A1* 5/2007 Zhang et al. ................ .. 370/259
`2007/0124160 A1* 5/2007 Duan et al. ...................... .. 705/1
`2007/0165803 A1* 7/2007 Duan ..... ..
`
`ETSI TS 132 015 V3.12.0, “ETSI”, pp. 1-66, (Dec. 2003).
`Chinese Of?ce Action in Chinese Application No. 2004100337219
`mailed Oct. 21, 2005.
`International Search Report from the European Patent Of?ce in Inter
`national Application No. EP 05 73 8259 mailed Feb. 12, 2007.
`Extended Search Report from the European Patent Of?ce in Interna
`tional Application No. EP 11 16 0837 mailed May 10, 2011.
`Of?ce Action in US. Appl. No. 11/502,921 mailed Nov. 12, 2009.
`Second Of?ce Action in US. Appl. No. 11/502,921 mailed Jul. 13,
`2010.
`Third Of?ce Action in US. Appl. No. 11/502,921 mailed Dec. 8,
`2010.
`Fourth Of?ce Action in US. Appl. No. 11/502,921 mailed Feb. 24,
`201 1.
`Fifth Of?ce Action in US. Appl. No. 11/502,921 mailed Mar. 24,
`2010.
`Final Rejection for Japanese Patent Application No. 2007-503178
`dated Dec. 15, 2009.
`3GPP TS 21.125, “3” Generation Partnership Project; Technical
`Speci?cation Group Services and System Aspects; Overall High
`Level Functionally and Architecture Impacts of Flow Based Charg
`ing; Stage 2 (Release 6)”, V.6.0.0, pp. 1-30, (Mar. 2004).
`Notice of Allowance mailed Apr. 27, 2011, issued in related U.S.
`Appl. No. 11/502,921 (9 pages).
`EPO Extended Search Report mailed May 18, 2011, issued in related
`European Patent Application No. 111608378 (5 pages).
`EPO Supplemental European Search Report mailed Feb. 22, 2007,
`issued in related European Patent Application No. 057382590 (4
`pages).
`EPO Examination Report mailed May 11, 2007, issued in related
`European Patent Application No. 057382590 (3 pages).
`Preliminary Notice of Rejection With partial English translation
`dated Jul. 14, 2009, issued in related Japanese Application No. 2007
`503178 (3 pages).
`Notice of Final Rejection With partial English translation dated Dec.
`15, 2009, issued in related Japanese Application No. 2007-503178 (3
`pages).
`Preliminary Notice of Rejection With partial English translation
`dated Apr. 24, 2012, issued in related Japanese Application No.
`2010-091482 (3 pages).
`PCT International Search Report mailed Jun. 9, 2005, issued in
`related International Application No. PCT/CN2005/000388 (4
`pages).
`PCT Written Opinion of the International Searching Authority
`mailed Jun. 9, 2005, issued in related International Application No.
`PCT/CN2005/000388 (3 pages).
`Japanese Of?ce Action mailed Jan. 8, 2013 in corresponding Japa
`nese Patent Application No. 2010-091482.
`U.S. Appl. No. 13/190,187, ?led Jun. 26, 2011, Xiaoqin Duan,
`HuaWei Technologies Co., Ltd.
`Of?ce Action, dated Feb. 25, 2013, in corresponding U.S. Appl. No.
`13/190,817 (21 pp.).
`Of?ce Action (partial translation) from the Japanese Patent Of?ce
`relating to Application No. 2010-091482; mailed Apr. 24, 2012;
`(Japanese version enclosed) (3 pgs.).
`
`* cited by examiner
`
`
`
`
`
`
`
`2007/0185809 A1* 8/2007 Duan 2008/0320564 A1* 12/2008 Duan 2011/0103261 A1* 5/2011 Duan 2011/0207432 A1* 8/2011 Wu ........... ..
`
`2011/0251936 A1* 10/2011 Zhang et al. .................. .. 705/30
`2011/0280192 A1 11/2011 Duan
`
`FOREIGN PATENT DOCUMENTS
`1452333 A 10/2003
`CN
`1472920 A
`2/2004
`CN
`1303781 C
`3/2007
`CN
`10-136126
`5/1998
`JP
`10136125 A
`5/1998
`JP
`2003-152778
`5/2003
`JP
`2003-338829
`11/2003
`JP
`2003338829 A 11/2003
`JP
`WO 01/39483
`5/2001
`W0
`WO 01/67706
`9/2001
`W0
`WO 01/91446
`11/2001
`W0
`W0 02/093835
`11/2002
`W0
`W0 WO 2004/036890
`4/2004
`W0 WO 2006/075042 A1
`7/2006
`
`

`

`US. Patent
`
`Sep. 10, 2013
`
`Sheet 1 0f 8
`
`US 8,531,971 B2
`
`UE Activate PDP Context SGSN
`101
`Request
`
`GGSN
`
`PDN
`
`102 Security Check
`
`Create PDP Context
`ggglgsj
`7 103
`Create P P Context
`Activate PDP Context
`Response
`L4
`Accept
`Packet Flow
`Tranf?c
`
`I
`
`105
`
`106
`Deactivate PDP Context
`Fl_—Request____>
`108 Security Check
`
`109
`
`Deactivate PDP Context
`Accept
`
`11 1
`
`1 0
`
`Delete PDP Context
`Request
`Delete PDP Context
`Response
`
`L.
`
`203
`
`204
`
`Figure 1 (prior art)
`
`205
`
`Figure 2A (prior art)
`
`

`

`US. Patent
`
`Sep. 10, 2013
`
`Sheet 2 of8
`
`US 8,531,971 B2
`
`203
`
`204
`
`AF
`
`/
`RX
`
`205
`
`CRF
`
`—— Gx
`
`TPF
`‘
`
`207
`
`CGF
`
`CCF M G!
`
`Figure 23 (prior art)
`
`UE
`
`TPF
`
`CRF
`
`301 A Establish Bearer Service Request
`’ 302A Request Charging Rules’
`
`303 A Select Charging Rules
`Identify Charing Rules
`to Install
`
`304A Provision Charging Rules
`+
`
`305A
`Install / Remove Charing
`Rules
`306A Establish Bearer Service Accept
`47
`
`Figure 3A (prior art)
`
`

`

`US. Patent
`
`Sep. 10, 2013
`
`Sheet 3 of8
`
`US 8,531,971 B2
`
`UE
`
`TPF
`
`CRF
`
`301 B Modify Bearer Service Request>
`
`302B Request Charging Rules >
`
`303 B Select Charging Rules
`Identify Charging
`Rules to Apply
`4304B Provision Charging Rules
`
`3058
`Install / Remove Charing
`Rules
`4306B Modify Bearer Service Accept
`
`Figure 3B(prior art)
`
`

`

`US. Patent
`
`Sep. 10, 2013
`
`Sheet 4 of8
`
`US 8,531,971 B2
`
`UE
`
`TPF
`
`CRF
`
`301 C Remove Bearer Service Request’
`
`302 C Request Charging Rules
`(Indication of Bearer Termination)
`303C Select Charging Rule
`Identify Charging
`Rules to Apply
`
`4 304 C Provision Charging Rules
`
`305C
`Install / Remove Charing
`Rules
`4306C Remove Bearer Service Accept
`
`Figure 3C (prior art)
`
`CRF
`
`AP
`
`401 Send Application/Service Data
`Flow Charging Information
`
`402 Ack
`
`Figure 4 (prior art)
`
`

`

`US. Patent
`
`Sep. 10, 2013
`
`Sheet 5 of8
`
`US 8,531,971 B2
`
`TPF
`
`CRF
`
`501 Internal or External
`Trigger Event
`
`502 Identify Charing
`Rules to Apply
`
`4503 Provision Charging Rules( if required)
`
`504
`Install / Remove Charing
`Rules
`|
`
`Figure 5 (prior art)
`
`

`

`US. Patent
`
`Sep. 10, 2013
`
`Sheet 6 of8
`
`US 8,531,971 B2
`
`CRF
`
`>
`
`b
`
`TPF
`
`static trigger event point
`occurs
`
`4
`
`‘
`
`601 Request Charging Rule
`(bearer characteristics, Information related with the network,
`subscriber, UE and the static trigger event point)
`
`602 Request Dynamic Event Report
`(dynamic trigger event point A, dynamic trigger event point B,
`dynamic trigger event point C,
`)
`
`603 Provision Charging Rule
`(Charging Rule 1)
`
`604 Stores the dynamic trigger event
`point list, performs charging rule 1
`
`dynamic trigger event point A occurs
`
`605 Request Charging Rule
`Indicate occurrence of dynamic trigger event point A
`606 Provision Charging Rule
`(Charging Rule 2)
`
`‘
`607 performs charging rule %
`
`I dynamic trigger event point B occurs]
`
`608 Request Charging Rule
`Indicate occurrence of dynamic trigger event point B
`609 Provision Charging Rule
`(Charging Rule 3)
`
`4
`
`607 performs charging rule 3
`
`Figure 6
`
`

`

`US. Patent
`
`Sep. 10, 2013
`
`Sheet 7 0f 8
`
`US 8,531,971 B2
`
`@g
`
`701 Establish Bearer Service Request
`
`TPF
`
`CRF
`
`702 Request Charging Rules
`[ Static Even; Bearer Info-'1
`
`703
`Dynamic Events Con?g
`704 Request Dynamic Event Report
`‘
`[ Dynamic Events List]
`
`705
`Select a Chan'ng Rule
`706 Charging Rule Response
`[ Charging Rule ]
`
`707 Store Dynamic Events ,
`Install/ Remove Charing Rules
`
`‘ 708 Establish Bearer Service Accept
`
`709 Modify Bearer Service Request
`
`\ Dynamic trigger event point occurs ]
`710 Request Charging Rules
`[ Dynamic Event ]
`
`>
`
`711 Select a Charing Rule
`Identify Charing
`Rules to Install
`712 Charging Rules Response
`[ Charging Rule ]
`
`7 1 3
`Install/ Remove Charin
`Rules
`
`714 Modify Bearer Service Accept
`
`715 Remove Bearer Service Request
`
`IDynamic trigger event point occurs|
`716 Request Charging Rules
`[ Dynamic Event ]
`
`717 Select a Chan'ng Rule
`Identify Charing
`Rules to Install
`718 Charging Rules Respons :
`[ Charging Rule ]
`
`i
`
`720 Remove Bearer Service Accept
`
`7 1 9
`Install / Remove Charin
`Rules
`
`Figure 7
`
`

`

`US. Patent
`
`Sep. 10, 2013
`
`Sheet 8 of8
`
`US 8,531,971 B2
`
`TPF
`
`CRF
`
`801 Internal or External
`Trigger Event
`
`802
`Dynamic Events Con?g
`Select a Charing Rule
`
`803 Request Dynamic Event Report
`[Dynamic Events List]
`
`804 Charging Rule Response
`[ Charging Rule ]
`
`805 Store Dynamic Events
`
`lnstall / Remove Charing Rules
`
`Dynamic trigger Event point occurs ‘
`
`806 Request Charging Rules
`[ Dynamic Event]
`
`807 Select Charging Rules
`Identify Charing
`Rules to Install
`808 Charging Rules Response
`[ Charging Rule ]
`
`809
`Install/ Remove Charing
`Rules
`|
`
`Figure 8
`
`

`

`US 8,531,971 B2
`
`1
`METHOD FOR CONTROLLING CHARGING
`OF PACKET DATA SERVICE
`
`CROSS-REFERENCE TO RELATED
`APPLICATIONS
`
`This application is a continuation of US. patent applica
`tion Ser. No. 13/190,817, ?led on Jul. 26, 2011, which is a
`continuation of US. patent application Ser. No. 11/502,921,
`now US. Pat. No. 8,009,573, ?led on Aug. 11, 2006 and
`issued onAug. 30, 201 1, respectively. The US. Pat No. 8,009,
`573 is a continuation of International Application No. PCT/
`CN2005/000388, ?led on Mar. 28, 2005, which claims prior
`ity to Chinese Patent Application No. 2004100309558, ?led
`on Apr. 1, 2004 and 2004100337219, ?led on Apr. 9, 2004.
`The afore-mentioned patent and patent applications are
`hereby incorporated by reference in their entireties.
`
`FIELD OF THE TECHNOLOGY
`
`20
`
`The present invention relates to a method of charging, and
`more speci?cally to a method of charging control for packet
`data service.
`
`BACKGROUND OF THE INVENTION
`
`25
`
`With the wide application of packet data service, how to
`charge packet data service accurately and reasonably has
`become a common concern of operators.
`FIG. 1 is a ?owchart illustrating an activation, data trans
`mission and de-activation of a Packet Data Protocol Context
`(PDP Context). As shown in FIG. 1, in General Packet Radio
`Service (GPRS), an implementing procedure of PDP Context
`activation, data transmission and de-activation includes the
`following steps:
`Step 101: A User Equipment (UE) sends an Activate PDP
`Context Request to a Serving GPRS Support Node (SGSN),
`and this Activate PDP Context Request carries information of
`a Network Layer Service Access Point Identi?er (N SAPI),
`PDP type, an Access Point Name (APN), a plurality of Qual
`ity of Service (QoS) parameters, a Transaction Identi?er (TI)
`and so on, where NSAPI is used as a component of a Tunnel
`Identi?er (TEID) between the SGSN and a Gateway GPRS
`Support Node (GGSN) to identify the PDP Context. The PDP
`Type includes the Peer-Peer Protocol (PPP) type, Internet
`Protocol (IP) type, etc. The APN may be provided for the
`SGSN by the UE, by which the SGSN addresses a corre
`sponding GGSN and the GGSN determines the external net
`work to be accessed by the UE, or the UE may choose not to
`provide the APN for the SGSN, in that case, the SGSN selects
`the default APN according to the subscriber information of
`the UE. The QoS parameters represent the quality required by
`the packet data service speci?ed by the UE. The TI is used for
`the UE to identify a PDP context.
`Step 102: After receiving the Activate PDP Context
`Request, the SGSN performs a security check and encryption
`with the UE, and this step is optional.
`Step 103: the SGSN analyses GGSN address information
`according to the APN, if the SGSN ?nds the GGSN address
`information according to the APN, the TEID is created for the
`PDP Context. The TEID may be a combination of an Inter
`national Mobile Subscriber Identity (IMSI) and the NSAPI to
`uniquely identify a PDP Context between SGSN and GGSN.
`Then the SGSN sends a Create PDP Context Request to the
`GGSN and the Create PDP Context Request carries PDP
`type, PDP address, APN, QoS parameters, TEID, and a select
`mode. The PDP address is an IP address of the UE, which is
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`an optional parameter. When a Create PDP Context Request
`doesn’t carry a PDP address therein, the IP address may be
`allocated by the GGSN in the subsequent process, or by a
`Packet Data Network (PDN) that is ?nally connected with the
`UE. The select mode refers to an APN-selecting mode,
`namely whether the APN is selected by the UE or by the
`SGSN. If the GGSN address information is not accessed for
`the SGSN according to the APN, the SGSN rejects the Acti
`vate PDP Context Request from the UE.
`Step 104: After receiving the Create PDP Context Request,
`the GGSN determines an external PDN according to the APN,
`then allocates a Charging ID, starts charging, and confers on
`QoS. The GGSN sends a Create PDP Context Response back
`to the SGSN, when the service quality requirement is met.
`The Create PDP Context Response carries the information of
`TEID, PDP address, Backbone Bearer protocol, QoS param
`eters, and Charging ID. When the GGSN does not meet the
`service quality requirement of the QoS parameters, the
`GGSN rejects the Create PDP Context Request from the
`SGSN, and then the SGSN rejects the Activate PDP Context
`Request from the UE.
`Step 105: After receiving the Create PDP Context
`Response, the SGSN adds the NSAPI and the GGSN address
`information into the PDP Context in order to identify this
`PDP Context, selects wireless precedence according to QoS
`parameters, and then returns anActivate PDP Context Accept
`to the UE. The Activate PDP Context Accept carries the
`information of PDP type, PDP address, TI, QoS parameters,
`wireless precedence, and a number of PDP con?guration
`options. Moreover, the SGSN starts charging. The UE
`receives the Activate PDP Context Accept and establishes a
`route with the GGSN. By this time the transmission channel
`between the UE and the PDN is established and data trans
`mission is able to start.
`Step 106: The UE transmits data with the PDN through the
`SGSN and the GGSN.
`Step 107: On ?nishing the data transmission, the UE sends
`a Deactivate PDP Context Request to the SGSN and the
`Deactivate PDP Context Request carries the TI.
`Step 108: After receiving the Deactivate PDP Context
`Request, the SGSN performs security checks and encryption
`with the UE, and this step is optional.
`Step 109~Step 111: The SGSN sends a Delete PDP Con
`text Request carrying the TEID to the GGSN. After receiving
`the Delete PDP Context Request, the GGSN ends the charg
`ing of the UE, deletes the PDP Context corresponding to the
`TEID, and then sends a to the SGSN. The Delete PDP Context
`Response carries the TEID. After receiving the Delete PDP
`Context Response, the SGSN ends the charging of the UE,
`deletes the PDP Context corresponding to the TEID, and then
`sends a Deactivate PDP Context Response carrying the TI to
`UE. After receiving the Deactivate PDP Context Response,
`the UE deletes the PDP Context corresponding to TI.
`As shown in FIG. 1, in the present GRPS charging system,
`the charging starts when the PDP context is activated and
`comes to its end when the PDP context is de-activated, which
`means the present charging system can only charges accord
`ing to a transmitted data ?ow or an activate time duration of
`the PDP context. In practice, however, after establishing a
`transmission channel with the PDN, the UE performs a plu
`rality of services based on one activated PDP Context, i.e. if
`the PDN is able to provide a plurality of services, such as
`Send/Receive Email service, Wireless Application Protocol
`(WAP) based browse service, File Transfer Protocol (FTP)
`based ?le transfer service and so on, an activated PDP Con
`text is able to bear various services provided by the PDN after
`the UE establishes a transmission channel with this PDN.
`
`

`

`US 8,531,971 B2
`
`3
`Meanwhile operators or service providers may adopt differ
`ent charging approaches for different charging modes of vari
`ous services, for instance, Send/Receive Email service may
`be charged based on trigger times of Sending and Receiving
`events, WAP broWse service may be charged according to
`How, ?le transfer service may also be charged according to
`How, and yet, a charging rate of WAP broWse service is
`different from that of ?le transfer service. Thus, it is totally
`impossible to perform separate charging With the existing
`GPRS charging system for different services the same PDP
`Context bears.
`In vieW of the above, it is being discussed in the 3rd Gen
`eration Partnership Project (3 GPP) as to hoW to implement IP
`FloW Based Charging (FBC). As far as a packet data service
`is concerned, all the transmitted and received IP FloWs or IP
`Packets When a UE user uses the service may be called Ser
`vice Data FloW, i.e. the Service Data FloW is a set of a plurality
`of IP FloWs, therefore the IP FloW Based Charging can truly
`re?ect the resource occupation of a certain service. The IP
`FloW Based Charging can be described like this: IP FloWs of
`different services that the same PDP Context bears are sepa
`rately screened out through some ?lters similar to sieves, then
`the IP FloWs that are screened out by different ?lters are
`separately charged so as to reach the object of separately
`charging different Service Data FloWs. In this Way, a charging
`granularity based on IP FloWs is far less than that based on a
`PDP Context. The charging granularity may be regard as the
`siZe of a hole of a sieve, therefore the charging granularity
`based on one PDP Context Will be like a sieve hole deter
`mined by one PDP Context While the charging granularity
`based on IP FloW Will be like a sieve hole determined by one
`IP FloW, that is, there Will be more than one sieve holes
`contained in one PDP Context. Therefore, comparing With the
`charging based on one PDP Context, charging based on IP
`FloW can provide more charging approaches for operators or
`service providers.
`In 3GPP, aspects of FBC like system architectures, func
`tion requirement and How of interactive messages are
`described. The FBC system architecture supporting online
`charging is shoWn in FIG. 2A, in Which Online Charging
`System (OCS) 206 is composed of Service Control Point
`(SCP) 201 of Customized Application for Mobile NetWork
`Enhanced Logic (CAMEL) and a service data How based
`Credit Control Function (CCF) 202. CCF 202 is connected
`With service data How based Charging Rule Function (CRF)
`203 through an interface Ry. The CRF 203 is connected With
`an Application Function (AF) 204 through an interface Rx
`and With the Traf?c Plane Function (TPF) 205 through an
`interface Gx. The CCF 202 is connected With TPF 205
`through an interface Gy.
`The FBC system architecture supporting o?line charging is
`shoWn in FIG. 2B, in Which the CRF 203 is connected With the
`AF 204 through an interface Rx and With the TPF 205 through
`an interface Gx, and the TPF 205 is connected With a Charg
`ing GateWay Function (CGF) 207 and a Charging Collection
`Function (CCF) 208 respectively through GZ.
`According to the 3GPP provision for functions implement
`ing the FBC, the TPF 205 bears IP FloWs. During and the
`establishment of the IP FloW bearer, the TPF 205 sends a
`Charging Rule Request to the CRF 203 through the Gx inter
`face. The Charging Rule Request carries relevant information
`of subscriber and the UE, bearer characteristics, netWork
`information, and so on. The relevant information of sub
`scriber and the UE may be a Mobile Station ISDN
`(MSISDN), an International Mobile Subscriber Identity
`(IMSI) and etc. In addition, the bearer may be modi?ed dur
`ing the IP FloW transmission. For example, When QoS param
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`eters of the same service are different, charging rules may be
`different accordingly. For instance, the charging rate may be
`decrease as QoS parameters decrease. Therefore it is neces
`sary to re-confer on QoS parameters. In this case, during the
`modi?cation of the bearer, the TPF 205 resends a Charging
`Rule Request to the CRF 203 to request for neW charging
`rules. The CRF 203 selects a proper charging rule according
`to the said input information provided by the TPF 205 and
`then returns the selected charging rule to the TPF 205. The
`charging rule includes information of charging mechanism,
`charging type, charging key, Service Data FloW Filter, and
`charging rule precedence. The charging mechanism may be
`online charging or o?line charging. The charging type may be
`a type of time span based. The charging key is a parameter
`related With the charging rate, and the CRF 203 may provide
`only parameters related With the charging rate for the TPF
`205, rather than directly provide the charging rate for the TPF
`205. The Service Data FloW Filter is used to indicate the TPF
`205 Which IP FloWs are to be ?ltered, and then the TPF 205
`charges these ?ltered IP FloWs according to the charging
`rules. Service Data FloW Filter may include IP quintuple
`having such information as Source/Destination IP Address,
`Source/Destination Port Number, and Protocol ID. For
`instance, the CRF 203 indicates the TPF 205 to ?lter the IP
`FloW With the Source IP Address 10.0.0.1, Destination IP
`Address 10.0.0.2, Source/Destination Port Number 20 and
`the protocol type Transmission Control Protocol (TCP), and
`then charges the ?ltered IP FloW according to the charging
`rule. Finally, during the deletion of the bearer, the TPF 205
`may as Well send a Charging Rule Request to the CRF 203 to
`request a neW charging rule from the CRF. At this time, the
`CRF 203 may request the TPF 205 to delete the previously
`installed charging rule.
`In addition, the CRF 203 may determine the charging rule
`according to the input information of the AF 204 or OCS 20
`apart from the input information of the TPF 205. For example,
`the AF 204 may notify the CRF 203 of the current service type
`used by the user, and the CRF 203 may select the correspond
`ing charging rule according to this service type.
`For a GPRS netWork, the TPF 205 is the GGSN, the AF is
`a service gateWay or a service server in the PDN and the CRF
`203 is an added logical entity. The TPF 205 is the executing
`point of charging rules and the CRF 203 is the control point of
`charging rules.
`FIG. 3A is the How chart of issuing the charging rule When
`a bearer is established. As shoWn in FIG. 3A, the implement
`ing procedure of issuing the charging rule When a bearer is
`established includes the folloWing steps:
`Step 301A: The UE sends an Establish Bearer Service
`Request to the TPF While in a GPRS netWork the correspond
`ing process is that the GGSN receives a Create PDP Context
`Request.
`Step 302A: After receiving the Establish Bearer Service
`Request, the TPF sends a Charging Rule Request to the CRF,
`and the Charging Rule Request carries the input information
`for the CRF to determine the charging rule.
`Steps 303A~3 04A: After receiving the Charging Rule
`Request, the CRF selects a charging rule according to the
`input information carried by the Charging Rule Request, and
`then returns Provision Charging Rules. The Provision Charg
`ing Rules may carry the selected charging rule.
`Steps 305A~306A: After receiving Provision Charging
`Rules, the TPF installs a neW charging rule according to the
`charging rule selected by the CRF, or deletes the original
`charging rule, or installs a neW charging rule While deleting
`the original one. Then the TPF receives the Establish Bearer
`Service Request initiated by the UE, returns an Establish
`
`

`

`US 8,531,971 B2
`
`5
`Bearer Service Accept to the UE, and continues With the
`subsequent steps of the Establish Bearer process.
`FIG. 3B is the How chart of issuing the charging rule When
`a bearer is modi?ed. As shoWn in FIG. 3B, the implementing
`procedure of issuing the charging rule When a bearer is modi
`?ed includes the folloWing steps:
`Step 301B: The UE sends a Modify Bearer Service Request
`to the TPF While in a GPRS netWork the corresponding pro
`cess is that the GGSN receives an Update PDP Context
`Request.
`Step 302B: After receiving the Modify Bearer Service
`Request, the TPF sends a Charging Rule Request to the CRF,
`and the Charging Rule Request carries the input information
`for the CRF to determine the charging rule.
`Steps 303B~304B: After receiving the Charging Rule
`Request, the CRF selects a charging rule according to the
`input information carried by this Charging Rule Request, and
`then returns Provision Charging Rules carrying the selected
`charging rule.
`Steps 305B~306B: After receiving Provision Charging
`Rules, the TPF installs a neW charging rule according to the
`charging rule selected by the CRF, or deletes the original
`charging rule, or installs a neW charging rule While deleting
`the original one. Then the TPF receives the Modify Bearer
`Service Request initiated by UE, returns a Modify Bearer
`Service Accept to the UE, and continues With the subsequent
`steps of the Modify Bearer process.
`FIG. 3C is the How chart of issuing the charging rule When
`a bearer is deleted. As shoWn in FIG. 3B, the implementing
`procedure of issuing the charging rule When a bearer is
`deleted includes the folloWing steps:
`Step 301C: The UE sends a Remove Bearer Service
`Request to the TPF While in a GPRS netWork the correspond
`ing process is that the GGSN receives a Delete PDP Context
`Request.
`Step 302C: After receiving the Remove Bearer Service
`Request, the TPF sends a Charging Rule Request to the CRF,
`and the Charging Rule Request carries the input information
`for the CRF to determine the charging rule.
`Steps 303C~304C: After receiving the Charging Rule
`Request, the CRF selects a charging rule according to the
`input information carried by this Charging Rule Request, and
`then returns Provision Charging Rules carrying the selected
`charging rule.
`Steps 305C~306C: After receiving Provision Charging
`Rules, the TPF installs a neW charging rule according to the
`charging rule selected by the CRF, or deletes the original
`charging rule, or installs a neW charging rule While deleting
`the original one. Then the TPF returns a Remove Bearer
`ServiceAccept to the UE, accepts the Remove Bearer Service
`Request initiated by the UE and continues With the subse
`quent steps of the Remove Bearer process.
`Besides, the CRF may also voluntarily send a charging rule
`to the TPF. For instance, in the data transmission process
`betWeen the UE and the AF, after receiving the input infor
`mation relating to charging of the AF, the CRF selects a
`proper charging rule according to the input information pro
`vided by the AF, and then voluntarily issues the selected
`charging rule to the TPF. The speci?c implementing proce
`dure of theAF providing the input information of charging for
`the CRF is shoWn in FIG. 4:
`Step 401: The AF sends Application/Service Data FloW
`Charging Information to the CRF.
`Step 402: After receiving the Application/Service Data
`FloW Charging Information, the CRF returns an AcknoWl
`
`20
`
`25
`
`30
`
`35
`
`40
`
`50
`
`55
`
`65
`
`6
`edgement (Ack) to the AF to notify the AF of already receiv
`ing the Application/ Service Data FloW Charging Information
`sent by the AF.
`FIG. 5 is the How chart of the CRF voluntarily issuing the
`charging rule to the TPF. As shoWn in FIG. 5, the implement
`ing procedure of the CRF voluntarily issuing the charging
`rule to the TPF includes the folloWing steps:
`Step 501: The CRF receives a certain Internal or External
`Trigger Event and relevant information about this event, such
`as the event of the AF sending the input information of charg
`ing rule selection to the CRF.
`Step 502: The CRF selects the corresponding charging rule
`according to the acquired information. The acquired informa
`tion may be the charging-relevant input information provided
`by the AF. For instance, the user is using a certain service of
`AF, and the service has special charging requirement, e.g., the
`charging rate is different from that of other services, there
`fore, the AF provides relevant charging information of this
`service for the CRF. The acquired information may also be the
`charging-relevant input information provided by TPF.
`Step 503: The CRF sends the Provision Charging Rules to
`the TPF When needed, and the Provision Charging Rules may
`carry the selected charging rule.
`Step 504: After receiving Provision Charging Rules, the
`TPF installs a neW charging rule according to the charging
`rule selected by the CRF, or deletes the original charging rule,
`or installs a neW charging rule While deleting the original one.
`At present, the interactive mode concerning charging rule
`betWeen the TPF and the CRF is de?ned in 3GPP Speci?ca
`tion like this: The TPF sends a Charging Rule Request to the
`CRF When a certain trigger event is met. The trigger event
`may be an event of establishing, modifying or deleting the
`bearer. The CRF selects a proper charging rule according to