111111
`
`1111111111111111111111111111111111111111111111111111111111111
`US008531971B2
`
`c12) United States Patent
`Duan
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 8,531,971 B2
`Sep.10,2013
`
`(54) METHOD FOR CONTROLLING CHARGING
`OF PACKET DATA SERVICE
`
`(75)
`
`Inventor: Xiaoqin Duan, 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. 154(b) by 84 days.
`
`(21) Appl. No.: 13/277,506
`
`(22) Filed:
`
`Oct. 20, 2011
`
`(65)
`
`Prior Publication Data
`
`US 2012/0033560Al
`
`Feb. 9, 2012
`
`CN
`CN
`
`(58) Field of Classification Search
`USPC ......... 370/252-259, 328-389; 455/405-422;
`709/219-229
`See application file for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`5,598,417 A
`111997 Crisler eta!.
`511998 Kay et a!.
`5,757,894 A
`8/1998 Taylor et al.
`5,790,642 A
`6/1999 Johnson et al.
`5,917,897 A
`10/1999 Kawecki et a!.
`5,963,625 A
`6,023,499 A
`212000 Mansey eta!.
`(Continued)
`
`FOREIGN PATENT DOCUMENTS
`1222017 A
`7/1999
`9/2003
`1444824 A
`(Continued)
`OTHER PUBLICATIONS
`
`Related U.S. Application Data
`
`(63) Continuation of application No. 13/190,817, filed on
`Jul. 26, 2011, which is a continuation of application
`No. 11/502,921, filed on Aug. 11, 2006, now Pat. No.
`8,009,573, which is a continuation of application No.
`PCT/CN2005/000388, filed on Mar. 28, 2005.
`
`(30)
`
`Foreign Application Priority Data
`
`Apr. 1, 2004
`Apr. 9, 2004
`
`(CN)
`(CN)
`
`2004 1 0030955
`2004 1 0033721
`
`(51)
`
`Int. Cl.
`H04L 12128
`H04L 12156
`H04W4100
`G06F 151173
`(52) U.S. Cl.
`USPC ........... 370/241; 370/328; 370/395; 455/406;
`709/223
`
`(2006.01)
`(2011.01)
`(2009.01)
`(2006.01)
`
`Connnunication from the European Patent Office in Application No.
`05 738 259.0-1525 dated Jan. 16, 2008.
`
`(Continued)
`
`Primary Examiner- Man Pharr
`(74) Attorney, Agent, or Firm- 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(cid:173)
`essary charging rule from the TPF becomes avoidable, which
`enables interaction between the TPF and the CRF more effec(cid:173)
`tive and the charging control of packet data service reasonable
`and perfect.
`
`11 Claims, 8 Drawing Sheets
`
`CRF
`
`601Reques!ChargingRule
`(bmrclwacteristics,infonD!iiontelatedwilbthenetwork,
`subscriber,UEaOOthestalictriggereventpnnt)
`
`602 RequestDynamicEvemRepm
`(dynamictriggerevtlipoiotA,dyoamiclriggerevcntp.~intB,
`dy!miclriggereventpoiotC, ... )
`
`603ProvisionChargingRule
`(CbargingRnlel)
`
`dynamictriggerevetrt)XIintAOCClllS
`
`605RequestChargiogRule
`lndieatc:occurrelll:eofd)'IIWiliclriggerevcat?JintA
`606ProvisiooChargingRule
`(ChargingRule2)
`
`607perfurmscllargingTille~
`
`dyoamiclrigger' entpoin1Boccurs
`
`60SRequestCiwgingRule
`lndic:ateocrurenceofdynamictriggere\'elllpoiltB
`609ProvisionCbargingRuk
`(ChargingRule3)
`
`fiJ7):Cri'oomscbargingrule3
`
`Cisco 1001
`U.S. Pat. 8,531,971
`
`

`

`US 8,531,971 B2
`Page 2
`
`(56)
`
`References Cited
`
`OTHER PUBLICATIONS
`
`U.S. PATENT DOCUMENTS
`6,434,380 B1
`8/2002 Andersson et a!.
`6,985,567 B2
`112006 Vallinen et al.
`7,017,050 B2
`3/2006 Dalton, Jr. eta!.
`7,203,301 B1
`4/2007 Mudd eta!.
`7,260,193 B2
`8/2007 Zackrisson et al.
`7,266,116 B2
`9/2007 Halpern
`7,391,854 B2
`6/2008 Salonen et a!.
`7,689,203 B2
`3/2010 Zhang et al.
`7,831,247 B2 * 1112010 Gabor eta!. ............... 455/422.1
`7,843,860 B2 * 1112010 Boman ......................... 370/310
`7,889,650 B2 * 212011 Duan ............................ 370/230
`7,948,990 B2 * 5/2011 Hurtta et al. ............... 370/395.2
`7,957,719 B2 * 6/2011 Wu ............................... 455/406
`8,009,573 B2 * 8/2011 Duan ............................ 370/252
`2002/0101858 A1
`8/2002 Stuart eta!.
`2002/0129088 A1
`9/2002 Zhou eta!.
`2002/0138331 A1
`9/2002 Hosea eta!.
`2002/0152319 A1
`10/2002 Amin
`2002/0174212 A1 * 1112002 Casati eta!. .................. 709/223
`2002/0188562 A1
`12/2002 Igarashi et al.
`2003/0014367 A1
`112003 Tubinis
`2003/0125013 A1
`7/2003 Mizell et al.
`2003/0152039 A1
`8/2003 Roberts
`2003/0153333 A1
`8/2003 Shirai eta!.
`2003/0165222 A1
`9/2003 Syrj ala et a!.
`2003/0200313 A1
`10/2003 Peterka et a!.
`2004/0017905 A1
`112004 Warrier eta!.
`2004/0125755 A1
`7/2004 Roberts
`7/2004 Lippe it
`2004/0127194 A1
`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 Lialiarnou et a!.
`2006/0234674 A1
`10/2006 Koskinen eta!.
`2007/0033274 A1 * 2/2007 Duan ............................ 709/223
`2007/0115861 A1 * 5/2007 Zhang et al. .................. 370/259
`2007/0124160 A1 * 5/2007 Duan eta!. ........................ 705/1
`2007/0165803 A1 * 7/2007 Duan ....................... 379/114.03
`2007/0185809 A1 * 8/2007 Duan .............................. 705/39
`2008/0320564 A1 * 12/2008 Duan ................................ 726/4
`201110103261 A1 * 5/2011 Duan ............................ 370/254
`201110207432 A1 * 8/2011 Wu ............................... 455/406
`201110251936 A1 * 10/2011 Zhang et al. .................... 705/30
`1112011 Duan
`201110280192 A1
`
`FOREIGN PATENT DOCUMENTS
`1452333 A
`10/2003
`1472920 A
`2/2004
`1303781 c
`3/2007
`10-136126
`5/1998
`10136125 A
`5/1998
`2003-152778
`5/2003
`2003-338829
`1112003
`2003338829 A
`1112003
`wo 01139483
`5/2001
`wo 01167706
`9/2001
`wo 01191446
`1112001
`wo 02/093835
`1112002
`wo 2004/036890
`4/2004
`WO 2006/075042 A1
`7/2006
`
`CN
`CN
`CN
`JP
`JP
`JP
`JP
`JP
`wo
`wo
`wo
`wo
`wo
`wo
`
`ETSI TS 132 015 V3.12.0, "ETSI", pp. 1-66, (Dec. 2003).
`Chinese Office Action in Chinese Application No. 2004100337219
`mailed Oct. 21, 2005.
`International Search Report from the European Patent Office in Inter(cid:173)
`national Application No. EP 05 73 8259 mailed Feb. 12, 2007.
`Extended Search Report from the European Patent Office in Interna(cid:173)
`tional Application No. EP 11 16 0837 mailed May 10, 2011.
`Office Action in U.S. Appl. No. 111502,921 mailed Nov. 12, 2009.
`Second Office Action in U.S. Appl. No. 111502,921 mailed Jul. 13,
`2010.
`Third Office Action in U.S. Appl. No. 111502,921 mailed Dec. 8,
`2010 .
`Fourth Office Action in U.S. Appl. No. 111502,921 mailed Feb. 24,
`2011.
`Fifth Office Action in U.S. Appl. No. 111502,921 mailed Mar. 24,
`2010.
`Final Rejection for Japanese Patent Application No. 2007-503178
`dated Dec. 15, 2009.
`3GPP TS 21.125, "3m Generation Partnership Project; Technical
`Specification Group Services and System Aspects; Overall High
`Level Functionally and Architecture Impacts of Flow Based Charg(cid:173)
`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. 111502,921 (9 pages).
`EPO Extended Search Report mailed May 18, 2011, issued in related
`European Patent Application No. 11160837.8 (5 pages).
`EPO Supplemental European Search Report mailed Feb. 22, 2007,
`issued in related European Patent Application No. 05738259.0 (4
`pages).
`EPO Examination Report mailed May 11, 2007, issued in related
`European Patent Application No. 05738259.0 (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 Office Action mailed Jan. 8, 2013 in corresponding Japa(cid:173)
`nese Patent Application No. 2010-091482.
`U.S. Appl. No. 13/190,187, filed Jun. 26, 2011, Xiaoqin Duan,
`Huawei Technologies Co., Ltd.
`Office Action, dated Feb. 25, 2013, in corresponding U.S. Appl. No.
`13/190,817 (21 pp.).
`Office Action (partial translation) from the Japanese Patent Office
`relating to Application No. 2010-091482; mailed Apr. 24, 2012;
`(Japanese version enclosed) (3 pgs.).
`* cited by examiner
`
`

`

`U.S. Patent
`
`Sep.10,2013
`
`Sheet 1 of8
`
`US 8,531,971 B2
`
`UE Activate PDP ContextL__----.-----'
`101
`Request
`
`102 Securi Check
`
`Create PDP Context
`
`Activate PDP Context
`Accept
`
`105
`
`106
`Deactivate PDP Context
`
`107
`
`Packet Flow
`
`108 Securi Check
`
`Delete PDP Context
`
`109
`
`Deactivate PDP Context 1 0
`Res onse
`Acce t
`~=-----_.__-----t
`
`11
`
`Figure 1 (prior art)
`
`:-o-cs ___ 2ol ____________ io2-: 206
`
`203
`
`204
`
`CRF
`
`Rx
`
`AF
`
`I
`f-+----+----1
`I Ry
`:
`
`:0 ;r-
`
`1
`
`I
`
`CCF
`---------
`SCP
`:
`~--------------------
`
`Figure 2A (prior art)
`
`

`

`U.S. Patent
`
`Sep.10,2013
`
`Sheet 2 of8
`
`US 8,531,971 B2
`
`CGF
`
`CCF
`
`Figure 2B (prior art)
`
`~
`
`'301A Establish Bearer Service Reques!
`
`I~
`
`I~
`
`302A Request Charging Rules ...
`
`I"
`
`303 A Select Charging Rules
`Identify Charing Rules
`to Install
`
`104 A Provision Charging Rules
`.....
`
`305A
`Install I Remove Charing
`Rules
`]06A Establish Bearer Service Accept
`""
`
`Figure 3A (prior art)
`
`

`

`U.S. Patent
`
`Sep.10,2013
`
`Sheet 3 of8
`
`US 8,531,971 B2
`
`UE
`
`TPF
`
`30 I B Modify Bearer Service Request
`... 302B Request Charging Rules
`
`CRF
`
`... ...
`
`303 B Select Charging Rules
`Identify Charging
`Rules to Apply
`J04 B Provision Charging Rules
`....
`
`305B
`Install I Remove Charin~
`Rules
`)06B Modify Bearer Service Accept
`....
`
`Figure 3B(prior art)
`
`

`

`U.S. Patent
`
`Sep.10,2013
`
`Sheet 4 of8
`
`US 8,531,971 B2
`
`UE
`
`301 C Remove Bearer Service Reque~ ...
`
`..
`
`302C Request Charging Rules
`(Indication of Bearer Termination)
`303C Select Charging Rules
`Identify Charging
`Rules to Apply
`
`, - - - - - - - - ' - - - - - - - ,
`
`304C Provision Charging Rules
`
`305C
`Install I Remove Charing
`Rules
`. ..306 C Remove Bearer Service Accept
`
`~
`
`Figure 3C (prior art)
`
`401 Send Application/Service Data
`Flow Charging Information
`
`....
`
`402 Ack
`
`Figure 4 (prior art)
`
`... ..
`
`

`

`U.S. Patent
`
`Sep.10,2013
`
`Sheet 5 of8
`
`US 8,531,971 B2
`
`I TPFI
`
`501 Internal or External
`...
`Trigger Event
`
`~
`
`502 Identify Charing
`Rules to Apply
`
`203 Provision Charging Rules( if required)
`.....
`
`504
`Install I Remove Charing
`Rules
`I
`
`Figure 5 (prior art)
`
`

`

`U.S. Patent
`
`Sep.10,2013
`
`Sheet 6 of8
`
`US 8,531,971 B2
`
`CRF
`
`..
`
`static trigger event point
`occurs
`
`...
`
`...
`
`601 Request Charging Ru1e
`(bearer characteristics, lnfonnation 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 l)
`
`604 Stores the dynamic trigger event
`point lis~ perfonns charging rule I
`
`I dynamic trigger event point A occurs I
`
`605 Request Charging Rule
`Indicate occurrence of dynamic trigger event point A
`606 Provision Charging Rule
`(Charging Rule 2)
`
`...
`
`I 607 perfonns charging rule~
`I I
`I dynamic trigger €~ent point B occurs I
`
`I
`
`608 Request Charging Ru1e
`Indicate occurrence of dynamic trigger event point B
`609 Provision Charging Ru1e
`(ChargingRu1e 3)
`
`I 607 perfonns charging rule 31
`I I i
`
`Figure 6
`
`

`

`U.S. Patent
`
`Sep.10,2013
`
`Sheet 7 of8
`
`US 8,531,971 B2
`
`UE
`
`TPF
`
`CRF
`
`701 Establish Bearer Service Request
`
`702 Request Charging Rules
`[ Static Event Bearer InfO'··]
`
`703
`Dynamic Events Config
`
`I
`704 Request Dynamic Event R port
`[ Dynamic Events List]
`
`705
`I
`Select a Charing Rule
`706 Charging Rule Response
`[ Charging Rule ]
`
`I
`
`I
`
`707 Store Dynamic Events,
`Install I Remove Charing Rules
`
`708 Establish Bearer Service Accept
`
`709 ModifY Bearer Service Request
`
`I Dynamic trigger event point occurs I
`710 Request Charging Rules
`[ Dynamic Event ]
`
`1711 Select a Charing Ru11
`IdentifY Charing
`Rules to Install
`712 Charging Rules Respons
`[ Charging Rule ]
`
`I
`714 ModifY Bearer Service Accept
`
`713
`Install I Remove Charin
`Rules
`
`14
`
`715 Remove Bearer Service Request
`
`!Dynamic trigger event point occurs!
`716 Request Chargin_g_ Rules
`[ Dynamic Event ]
`
`l717 Select a Charing Rule'
`IdentifY Charing
`Rules to Install
`718 Charging Rules Respons
`[ Charging Rule ]
`
`I
`720 Remove Bearer Service Accept
`
`719
`Install /Remove Charin
`Rules
`
`11
`
`I
`Figure 7
`
`

`

`U.S. Patent
`
`Sep.10,2013
`
`Sheet 8 of8
`
`US 8,531,971 B2
`
`I TPFI
`
`l CRFI
`
`80 I Internal or External
`Trigger Event
`
`802
`Dynamic Events Config
`Select a Charing Rule
`
`.. 803 Request Dynamic Event Report
`
`- [ Dynamic Events List]
`...
`
`804 Charging Rule Response
`[ Charging Rule ]
`
`805 Store Dynamic Events
`
`Install I Remove Charing Rules
`
`I
`
`I Dynamic trigger Event point occursj
`
`806 Request Charging Rules
`[ Dynamic Event]
`
`807 Select Charging Rules
`IdentifY Charing
`Rules to Install
`
`808 Charging Rules Response
`[ Charging Rule ]
`
`809
`Install I Remove Charing
`Rules
`
`I
`
`Figure 8
`
`

`

`US 8,531,971 B2
`
`1
`METHOD FOR CONTROLLING CHARGING
`OF PACKET DATA SERVICE
`
`CROSS-REFERENCE TO RELATED
`APPLICATIONS
`
`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 finally connected with the
`5 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 theAPN,
`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.
`15 The Create PDP Context Response carries the information of
`TEID, PDP address, Backbone Bearer protocol, QoS param(cid:173)
`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
`20 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
`25 PDP Context, selects wireless precedence according to QoS
`parameters, and then returns an Activate 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 configuration
`30 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(cid:173)
`mission is able to start.
`Step 106: The UE transmits data with the PDN through the
`SGSN and the GGSN.
`Step 107: On finishing 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(cid:173)
`text Request carrying the TEID to the GGSN. After receiving
`the Delete PDP Context Request, the GGSN ends the charg(cid:173)
`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(cid:173)
`ing to a transmitted data flow 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(cid:173)
`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 file transfer service and so on, an activated PDP Con(cid:173)
`text is able to bear various services provided by the PDN after
`the UE establishes a transmission channel with this PDN.
`
`This application is a continuation of U.S. patent applica(cid:173)
`tion Ser. No. 13/190,817, filed on Jul. 26, 2011, which is a
`continuation of U.S. patent application Ser. No. 11/502,921,
`now U.S. Pat. No. 8,009,573, filed on Aug. 11, 2006 and 10
`issuedonAug. 30,2011, respectively. The U.S. Pat No. 8,009,
`573 is a continuation oflntemational Application No. PCT/
`CN2005/000388, filed on Mar. 28, 2005, which claims prior-
`ity to Chinese Patent Application No. 200410030955.8, filed
`on Apr. 1, 2004 and 200410033721.9, filed on Apr. 9, 2004.
`The afore-mentioned patent and patent applications are
`hereby incorporated by reference in their entireties.
`
`FIELD OF THE TECHNOLOGY
`
`The present invention relates to a method of charging, and
`more specifically to a method of charging control for packet
`data service.
`
`BACKGROUND OF THE INVENTION
`
`35
`
`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 flowchart illustrating an activation, data trans(cid:173)
`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 Identifier (NSAPI),
`PDP type, an Access Point Name (APN), a plurality of Qual- 40
`ity of Service (QoS) parameters, a Transaction Identifier (TI)
`and so on, where NSAPI is used as a component of a Tunnel
`Identifier (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 45
`Protocol (IP) type, etc. The APN may be provided for the
`SGSN by the UE, by which the SGSN addresses a corre(cid:173)
`sponding GGSN and the GGSN determines the external net(cid:173)
`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 50
`the default APN according to the subscriber information of
`the UE. The QoS parameters represent the quality required by
`the packet data service specified by the UE. The TI is used for
`the UE to identify a PDP context.
`Step 102: After receiving the Activate PDP Context 55
`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 finds the GGSN address
`information according to the APN, the TEID is created for the 60
`PDP Context. The TEID may be a combination of an Inter(cid:173)
`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 65
`type, PDP address, APN, QoS parameters, TEID, and a select
`mode. The PDP address is an IP address of the UE, which is
`
`

`

`US 8,531,971 B2
`
`3
`Meanwhile operators or service providers may adopt differ(cid:173)
`ent charging approaches for different charging modes of vari(cid:173)
`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 5
`flow, file transfer service may also be charged according to
`flow, and yet, a charging rate of WAP browse service is
`different from that of file transfer service. Thus, it is totally
`impossible to perform separate charging with the existing
`GPRS charging system for different services the same PDP 10
`Context bears.
`In view of the above, it is being discussed in the 3rd Gen(cid:173)
`eration Partnership Project (3GPP) 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(cid:173)
`vice Data Flow, i.e. the Service Data Flow is a set of a plurality
`ofiP Flows, therefore the IP Flow Based Charging can truly
`reflect 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(cid:173)
`rately screened out through some filters similar to sieves, then
`the IP Flows that are screened out by different filters 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(cid:173)
`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(cid:173)
`tion requirement and flow of interactive messages are
`described. The FBC system architecture supporting online
`charging is shown in FIG. 2A, in which Online Charging 40
`System (OCS) 206 is composed of Service Control Point
`(SCP) 201 of Customized Application for Mobile Network
`Enhanced Logic (CAMEL) and a service data flow based
`Credit Control Function (CCF) 202. CCF 202 is connected
`with service data flow based Charging Rule Function (CRF) 45
`203 through an interface Ry. The CRF 203 is connected with
`an Application Function (AF) 204 through an interface Rx
`and with the Traffic 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 offline 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(cid:173)
`ing Gateway Function (CGF) 207 and a Charging Collection
`Function (CCF) 208 respectively through Gz.
`According to the 3GPP provision for functions implement(cid:173)
`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(cid:173)
`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(cid:173)
`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 modified dur(cid:173)
`ing the IP Flow transmission. For example, when QoS param-
`
`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 tore-confer on QoS parameters. In this case, during the
`modification 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 offline charging. The charging type may be
`a type of time span based. The charging key is a parameter
`15 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 filtered, and then the TPF 205
`20 charges these filtered 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 filter the IP
`25 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 filtered IP Flow according to the charging
`rule. Finally, during the deletion of the bearer, the TPF 205
`30 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
`35 according to the input information of the AF 204 or OCS 20
`apart from the input information of the TPF 205. For example,
`theAF 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 flow chart of issuing the charging rule when
`a bearer is established. As shown in FIG. 3A, the implement(cid:173)
`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
`50 Request to the TPF while in a GPRS network the correspond(cid:173)
`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,
`55 and the Charging Rule Request carries the input information
`for the CRF to determine the charging rule.
`Steps 303A-304A: After receiving the Charging Rule
`Request, the CRF selects a charging rule according to the
`input information carried by the Charging Rule Request, and
`60 then returns Provision Charging Rules. The Provision Charg(cid:173)
`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
`65 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
`
`10
`
`6
`edgement (Ack) to theAF to notify theAF of already receiv(cid:173)
`ing the Application/Service Data Flow Charging Information
`sent by the AF.
`FIG. 5 is the flow chart of the CRF voluntarily issuing the
`charging rule to the TPF. As shown in FIG. 5, the implement(cid:173)
`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 oftheAF sending the input information of charg(cid:173)
`ing rule selection to the CRF.
`Step 502: The CRF selects the corresponding charging rule
`according to the acquired information. The acquired informa-
`15 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(cid:173)
`fore, the AF provides relevant charging information of this
`20 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 defined in 3GPP Specifica(cid:173)
`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
`the information carried in the Charging Rule Request and
`sends the selected charging rule to the TPF. In this way, the
`event trigger of the Charging Rule Request is controlled by
`the TPF. The event trigger of the Charging Rule Request shall
`be set in the TPF in advance. Whenever the event of estab(cid:173)
`lishing, modifYing or deleting the bearer is met, the TPF sends
`the Charging Rule Request to the CRF. However, for some
`cases, the QoS parameters modified have little differences
`compared with original QoS parameters when the QoS
`parameters are modified during the modification of the
`bearer, and it is not necessary to modifY the charging rules. In
`these cases, the CRF may select a charging rule similar to an
`original one to send to the TPF when the TPF sends the
`Charging Rule Request, thereby creating a great of redundant
`information.
`
`5
`Bearer Service Accept to the UE, and continues with the
`subsequent steps of the Establish Bearer process.
`FIG. 3B is the flow chart of issuing the charging rule when
`a bearer is modified. As shown in FIG. 3B, the implementing
`procedure of issuing the charging rule when a bearer is modi-
`fied 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(cid:173)
`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 25