WO2004036843A1

WO2004036843A1 - Charging method for a ue in mbms

Info

Publication number: WO2004036843A1
Application number: PCT/KR2003/002132
Authority: WO
Inventors: Sung-Ho Choi; Kook-Heui Lee; Fei Guo; Hong Wang; Jiandang Li; Detao Li
Original assignee: Samsung Electronics Co., Ltd.; Beijing Samsung Telecom R & D Center
Priority date: 2002-10-14
Filing date: 2003-10-14
Publication date: 2004-04-29
Also published as: CN1490960A

Abstract

A volume-based charging method for single UE in MBMS services of WCDMA mobile communication system is proposed, which includes following steps: when UE starts to receive MBMS service data, UE itself collecting accounting the data volume it has successfully received and sending the report message to the RNC it belongs to periodically. RNC saving the data volume successfully received by each UE and updating the data volumes constantly with the periodical data volume reports of UE; when SGSN closes or queries the CDR of an UE, it voluntarily sending a request to the RNC; after RNC receives the request, it feedbacks the data volume saved to SGSN via a response message. SGSN creates a complete billing data record for Billing System. This invention solves the statistic problem for a single UE in common data service and effectively alleviates the problem of uplink signaling congestion.

Description

Vόlume-b ased Charging Method for Single UE in Multimedia Multicast/Broadcast Service

BACKGROUND OF THE INVENTION

1. Field of the invention

This invention relates to a charging method for Multimedia Broadcast/Multicast Service in a WCDMA system, particularly to a volume-based charging method for single UE.

2.Description of the Prior Art

MBMS is a new service under standardization by 3^rd Generation Partnership Project (hereinafter referred to 3GPP). The corresponding standard is TR23.846 and the latest version is 1.1.0. MBMS service is a unidirectional point-to-multipoint (p-t-m) service, hi this service, the same packet of data can be sent to multiple UEs from a data source entity. This technology is mainly realized through using common channel for service data transmission, which can make use of radio resources and network resources efficient. MBMS service has two kinds of modes, i.e. Broadcast mode and Multicast mode.

Figure 1 is a diagram describing the system structure of MBMS, which is based on the core network of General Packet Radio Service (hereinafter referred to GPRS).

In Figure 1, UE105 is a user of MBMS service. It can receive MBMS data via WCDMA air interface Uul07. UTRAN104 is responsible for radio access and radio resource allocation in MBMS. SGSN103 provides some functions of MBMS access control. The detailed information of each UE exists in SGSN, i.e. SGSN can control UE directly. Therefore, the charging data of a single UE are collected by SGSN. GGSN102 is a gateway for MBMS data source, whose function is to set MBMS data to target SGSN. BM_SC101 is the data source of MBMS service, which shall collects charging information of content providers. HLR106 is related to SGSN and its function is to authenticate and authorize User Equipment (UE) of MBMS.

In GPRS service field, charging mechanism needs to collect the data volume information of every UE, through which the details of network resources used by an UE in one service session can be made out, which provides detailed data of volume-based charging for Billing System.

Figure 2 is a diagram describing an accounting method for downlink data traffic of each UE in a service session of existing GPRS service.

After UE201 setup a GPRS session, SGSN can monitor the data volume sent to this UE when data pass by SGSN203. The data volume is called Voll (205) here. RNC202 can calculate the data volume that hasn't been sent to this UE through lower-layer related mechanism, which includes the data volume that hasn't been successfully sent out and that hasn't been sent but kept in RNC buffer. This data volume is called Vol2 (in 204). Thus, when a service session ends, the downlink data volume that the UE has received from this data service session is called Vol3 (in 206), which can be calculated from Voll and Vol2, i.e. Vol3 = Voll - Vol2. In this charging mechanism, as it is for point-to-point service type, all downlink data in service session are sent to one UE, thereby the data volume actually received by the UE successfully can also be obtained from the network side without the direct participation of UE. For the details of this charging mechanism, refer to the reference of 3GPP standard TS32.200 (the latest version 4.1.0) and the documentation of 3GPP standard TS32.215 (the latest version

4.2.1).

However, in 3GPP specifications, there isn't yet a volume-based charging mechanism aiming at a single UE that can be well applied to point-to-multipoint service. (Now that the broadcast mode of MBMS service is free for UEs, which means, it is unnecessary to obtain data volume information for a single UE, this invention is applicable to the multicast mode of MBMS service). There mainly exist following problems or aspects that need improvement when applying existing technology to MBMS:

1. In GPRS service, RNC makes use of lower-layer related mechanism (e.g. ACK and retransmission mechanism) to guarantee obtaining data volume sent unsuccessfully and that kept in buffer unsent. But, in MBMS service, service data are common to all UEs but not for a certain UE. Even ACK and retransmission mechanism is not suggested to be used in MBMS service. So if MBMS data are sent via common channel, it is impossible for RNC to obtain the data volume that each UE successfully receives eventually. Thus, the volume-based charging mechanism used in existing GPRS services is not applicable to MBMS.

2. Another existing method is UE directly reports the data volume it has successfully received to SGSN periodically by using uplink signaling. The data volume reported through uplink is then used for volume-based charging of each UE, which still has two obvious drawbacks: a) Serious congestion problem exists in UTAN and on lu interface. In MBMS service, as there is possibility that a large number of UEs use the service simultaneously, each SGSN manages a large number of UEs. And each UE report data volume it has successfully received by using the uplink signaling and RNC forwards the uplink signaling to SGSN. As so many UEs need to report the data volume they have successfully received, there exists possibility of UE uplink report happening simultaneously, which will result in the signaling congestion in UTRAN and on lu interface without any doubt. b) Add the signaling processing load of SGSN. In a short period of time, a large number of UEs will interact with SGSN via uplink report signaling that must be dealt with right away, which will bring huge signaling processing load to SGSN inevitably and result in unsatisfactory processing for other kind of concurrent services.

SUMMARY OF THE INVENTION

It is an object of this invention to provide a volume-based charging mechanism aiming at a single UE for MBMS service, to collect the data volume information of a single UE in a MBMS service session and to generate charging information needed by Billing System.

In view of the feature that volume-based charging mechanism in GPRS service model cannot meet with MBMS point-to-multipoint mode, we adopt the method that the UE itself collects accounting of MBMS service data volume it has successfully received and periodically report it upward till finally arriving at SGSN via uplink signaling. But due to the two drawbacks of this method described previously, this invention proposes a two-stage data volume statistic method. This method divides the process of periodical data volume report of UE upward into two stages. In the first stage, UE reports the data volume successfully received to the RND it belongs to and the RNC keeps the data. In the second stage, SGSN voluntarily asks RNC for the data if necessary. It thus effectively reduces the congestion of uplink signaling and signaling processing load of SGSN.

In order to apply the two-stage data volume statistic method to the system structure of MBMS, this invention also gives some necessary and auxiliary components to support this method. In addition, this invention also gives the detailed processes, through which the two-stage data volume statistic method can be well applied to MBMS service.

To achieve feature of above object of this invention, a volume-based charging method for a UE in MBMS service system comprising following steps:

(1) when the UE starts to receive MBMS service data, the UE counting the data volume it has successfully received and sending a report message including the data volume to the Radio Network Controller (RNC) it belongs to, after the RNC receives the message of the data volume from the UE, the RNC saving the data volume successfully received by the UE and updating the data volume during the MBMS service is going on; (2) when SGSN needs to close the service or query a billing data record

(MBMS-CDR) of the UE, the SGSN voluntarily sending a message for requesting a data volume (data volume request message) to the RNC that saves the most recent data volume of the UE, and the RNC sending the most recent data volume response message after receiving the data volume request message, and feed backing the most recent data volume of the UE on the data volume response message to SGSN;

(3) creating a charging data record (MBMS-CDR) for billing according to the most recent data volume message.

The charging method of the system, the UE can send the data volume when the RNC request the data. The charging method of the system, the UE can periodically send the data volume.

To achieve another feature above object of this invention, a volume-based charging method for a UE in MBMS services according to the invention comprise following steps: (1) when UE starts to receive MBMS service data, UE itself collecting accounting the data volume it has successfully received and sending the report message to the RNC (305, 306) it belongs to periodically, after RNC receives messages on data volume reports of each its subsidiary UE, it saving the data volume successfully received by each UE and updating the described data volume constantly with the periodical data volume reports of UE;

(2) when SGSN needs to close or query a charging data record (MBMS-CDR) of an UE, SGSN voluntarily sending a data volume request message to the RNC that saves the data volume of the UE described, and RNC sending a data volume response message after receiving the described data volume request message, and feed backing the data volume of the described UE via data volume response information to SGSN,

SGSN creating a complete charging data record MBMS-CDR for Billing System according to the data volume information of the UE received.

In step (2) described above, if SGSN has MBMS-CDR that can close multiple UEs simultaneously, i.e. when the service initiated by the core network is terminated, one request signaling sent by SGSN can request to obtain the data volume information of multiple UEs.

RNC sets MBMS Context for each UE, which includes a Data Volume field used to store the data volume value of the UE. Every time when RAN receives the data volume report signaling of an UE, it then fetches relevant data from the received signaling, finds MBMS Context of the UE and updates the Data Volume field with the data in the report signaling. When RAN receives a signaling message of data volume request from SGSN, it fetches the data volume value from the Data Volume field of MBMSH Context of the UE, and feed-backs the saved data volume of the UE to SGSN via the response message for the signaling message of data volume request.

MBMS-CDR includes: Record Type field, through which Charging Gateway Function (CGF) can distinguish which kind of service each Charging Data Record (CDR) belongs to; Charging ID field, which is the identifier for CDR and can be used together with GGSN address to uniquely identify all CDRs created by SGSN and related to a certain MBMS Context. The described Charging ID includes two parts: the first part (401) is a value given by GGSN to the SGSN when the first UE in a SGSN activates MBMS service, which is unique in one GGSN domain and is the same as the first part of Charging ID obtained by all UEs activating the same MBMS service in a SGSN, the second part (402) is created by SGSN. In a SGSN, the creation of the second part only requires the uniqueness in the range of the same first part value.

The Charging ID obtained from the combination of the first part and the second part is unique in the networks of all packet switching domains within a considerably long period of time. Charging Gateway Function (CGF) and Billing System make use of GGSN address and the described Charging ID together to check the uniqueness of Charging ED. If uncertainty exists, the timestamp opened by Charging Data Record described is added.

hi mobility management, when MBMS Context of an UE is moved from the old SGSN to a new SGSN, the Charging ID that MBMS Context corresponds to will be moved to the new SGSN also.

The time interval, which UE reports the data volume that has successfully received to RNC periodically, is created by the first clock in UE.

The data volume reported is a cumulative value. The second clock of each UE set by RNC is used to monitor the data volume report message of UE. Each time when RNC receives a data volume report message from a certain UE, the second clock monitoring the UE is reset; when the data volume report message of UE is lost, the second clock monitoring the data volume report message of the UE expires after a period of time and RNC judges that the UE is in abnormal status. On accounting of charging, RNC will notify SGSN to terminate the MBMS service of the UE; if one data volume report message of a certain UE is lost and RNC receives the next data volume report message of the UE before the second clock expires, the lost report message can be negligent and the data volume value collected by UE is synchronized with that saved by RNC. Then RNC won't notify SGSN to terminate the MBMS service of the UE.

The data volume report message includes: UE ID, which is used to indicate the UE sent this message; MBMS service ED, which is used to indicate the MBMS service that the message concerns with; and Data Volume that UE has successfully received when the data volume report message is been sending.

The Data Volume Request message is sent from SGSN to RNC to obtain the data volume values of one or more UEs. The Data Volume Request message includes: UE ID List, which includes one or more UE EDs that indicate the data volumes of which UEs are wanted by the data volume request message; Request Reason, which indicates the reason why the data volume request message is sent; and MBMS Service ED, which indicates the MBMS service used.

The Data Volume Response message includes MBMS Service ED and Data Volume List. MBMS Service ID is used to indicate the MBMS service that the message concerns with; Data Volume List indicates the data volume set of the UEs included by the Data Volume Response message and includes UE ED and the corresponding data volume of the UE.

In addition, if the request reason in the Data Volume Request message is not MBMS Service Termination, RNC will send a Data Volume Reset message to the specified UE to notify UE of resetting the cumulative data volume value to zero. When

UE receives this message, it restarts to collect the data volume it successfully received. The described Data Volume Reset includes UE ID and MBMS Service ED. UE ED is used to indicate the UE that the described Data Volume Reset message is sent to, and MBMS Service ED is used to indicate the MBMS service that the described Data Volume Reset message concerns with.

When an UE activate the MBMS service selected, an MBMS Context will be created for the UE in SGSN, and at the same time, MBMS-CDR accompanying the MBMS Context will be created by SGSN according to Charging Characteristics Profile.

In addition, if any of the following four situations happens, the MBMS Context of an UE will be deleted from a SGSN:

The MBMS service initiated by UE is terminated;

The MBMS service initiated by the core network is terminated. SGSN can obtain data volume values of multiple UEs simultaneously from one Data Volume Request message;

The second clock that monitors the UE Data Volume Report message in RNC detects that UE stays in abnormal status;

UE hands over between SGSNs due to moving. Before the MBMS Context of an UE is going to be deleted in SGSN, SGSN sends a Data Volume Request message to obtain the data volume value of the UE (or other UEs at the same time) and SGSN closes the MBMS-CDR related to the MBMS

Context.

The moving of UE between SGSNs includes two situations. The first situation is

Routing Area Update of UE. The MBMS-CDR of the UE in old SGSN is closed and the new SGSN will send a SGSN Context Request message to the old SGSN. In the SGSN Context Response message, the MBMS Context and Charging ED corresponding to the moving UE will be transferred from the old SGSN to the new SGSN without changing the Charging ED. The MBMS-CDR corresponding to the MBMS Context of the moving

UE is created in the new SGSN and the data volume accounting of the moving UE will restart from the zero. The second situation is that the moving of the UE between SGSNs includes UE relocation. The MBMS-CDR corresponding to the moving UE is closed in the old SGSN and the old SGSN will send a Forward Relocation Request message to the new SGSN, through which MBMS Context and Charging ED are transferred from the old SGSN to the new SGSN without changing the Charging ED. A new MBMS-CDR corresponding to the MBMS Context of the moving UE is created in the new SGSN and the moved data volume accounting restarts from zero.

SGSN Context Request message includes the old P-TMSI, the old RAI and the old

P-TMSI signature. SGSN Context Response message includes MM Context, PDP Context, and MBMS Context.

Forward Relocation Request message includes EMSI, Tunnel Terminator ED signaling, MM Context, PDP Context, Destination ED, UTRAN Transparent Container,

RANAP Reason, and MBMS Context.

The advantages of the invention are as follows:

1. With the two-stage data volume statistic and charging method proposed in this invention, data volume value actually received by each UE in a MBMS service session can be obtained, which solves the problem of charging fairness in point-to-multipoint services.

2. The charging mechanism in this invention is flexible. Through adjusting the clock in UE for periodical data volume transfer and the clock value in RNC that is used to monitor periodical data volume report of each UE, different charging granularity can be obtained to meet with different charging requirements of operators.

3. The charging mechanism in this invention can effectively alleviate uplink signaling congestion on the lu interface. En this mechanism, lu interface part doesn't have direct uplink Data Volume Report signaling. 4. The charging mechanism in this invention can effectively alleviate the signaling processing load of SGSN. En this mechanism, SGSN is proactive. When needing data volume information of each UE, it will send a message to acquire but not depend on the periodical report made by UE. In addition, one SGSN request signaling can obtain data volume values of several UEs, which also alleviates the signaling processing load of SGSN.

5. The charging mechanism of this invention can be integrated into several kinds of existing MBMS service architecture conveniently.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other features and advantages of the present invention will be more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which identical components are indicated by identical reference numbers and symbols throughout the several views:

Figure 1 is a diagram of MBMS system structure according to the invention; Figure 2 is a diagram describing the data volume statistic method for each UE session in GPRS service according to the invention;

Figure 3 is a diagram describing the two-stage data volume statistic mechanism according to the invention;

Figure 4 is a chart describing the Charging ED in MBMS service of the invention; Figure 5 is a diagram describing the process of periodical Data Volume Report according to the invention;

Figure 6 is a diagram describing the creation process of MBMS-CDR according to the invention;

Figure 7 is a diagram describing the starting process of data volume accounting according to the invention;

Figure 8 is a diagram describing Termination of data volume accounting on UE in a SGSN according to the invention; Figure 9 is a diagram describing the process for checking if UE stays in abnormal status according to the invention.

DETAILED DESCRIPTION OF THE PREFERRED

EMBODIMENTS

In order to overcome the defect of existing charging mechanism, i.e. inapplicable to point-to-multipoint services, and to improve the efficiency of uplink Data Volume Report, this invention designs a charging mechanism used for MBMS service, which specifically comprises: ( 1 ) accounting method of two-stage data volume

Figure 3 is a diagram describing the two-stage data volume accounting method in this invention.

In this method, the report process of data volume that UE has successfully received is divided into two stages:

In the first stage 309, when UE (301, 302, 303, 304) starts to receive MBMS service data, each UE itself collects the data volume that it has successfully received and reports this volume periodically to the RNC (305, 306) it belongs to but not directly report to the SGSN in 307 that it belongs to. RNC is responsible to store the data value successfully received by each of its subsidiary UEs and able to update the data value constantly according to the periodical volume report of UEs, which can guarantee the synchronization between the data volume saved by RNC for each UE and that successfully received by each UE actually. In addition, RNC is also responsible to response in time to abnormal status of UE and to process accordingly.

hi the second stage 310, before each Charging Data Record (Hereinafter referred to MBMS-CDR) of a certain UE is closed, SGSN needs to create a complete MBMS-CDR for Billing System according to the data volume information of the UE saved in the first stage. At this time, SGSN voluntarily sends a request to the RNC that saves the data volume information of the UE; After RNC receives the request signaling, it feedbacks the data volume information of the UE needed to SGSN, which reduces the congestion of lu interface and the signaling processing load of SGSN. In addition, if the MBMS-CDRs of several UE will be closed simultaneously (e.g.: when the service initiated by the core network is terminated), one request signaling sent by SGSN can request to obtain data volume information of several UEs, which can further alleviate - li ¬

the congestion on lu interface and the signaling processing load in SGSN.

(2) MBMS Context saved in RNC for each UE

Now that all RNC subsidiary UEs need to send the Data Volume Report that they successfully received respectively to the RNC, this invention insists that an MBMS

Context related with each UE should be included in RNC so that the data volume can be saved, in which a "Data Volume" field is needed to store the data volume that an UE has successfully received. This invention won't define other fields. Each time when RNC receives a Data Volume Report signaling from UE, it fetches related data from this signaling, finds the MBMS Context of the UE and then updates the "Data Volume" field with the data volume value in the report signaling.

In the second stage described above, when SGSN queries the data volume of an UE,

SGSN sends a Data Volume Request message to the RNC that the UE belongs to. The RNC then fetches the data volume value from the "Data Volume" field of MBMS

Context of the UE, and feedbacks to SGSN in the response message corresponding to the Data Volume Request signaling message.

(3) Two kinds of clocks used for periodical Data Volume Report In this invention, in order to realize the periodical Data Volume Report, two kinds of clocks are needed.

In UE, UE reports its data volume that it has successfully received to RNC periodically, which uses the first kind of clock. When the charging mechanism starts to work, signaling message sets the parameter of this clock and starts up it, which then can trigger a Data Volume Report message periodically.

The data volume value that UE periodically reports is a cumulative value, which cumulates the data volume that UE has successfully received. When each MBMS-CDR of the UE is closed and a new MBMS-CDR is created, signaling message will notify

UE to re-cumulate the data volume value from zero.

hi RNC, another kind of clock is set for each UE. This clock is used to monitor the Data Volume Report message of UE. Each tune when RNC receives a data volume report message from a certain UE, this clock monitoring the UE is reset; When the data volume report message of UE is lost (e.g. UE stays in abnormal status), the monitor clock for the data volume report message of the UE expires after a period of time and RNC judges that the UE is in abnormal status. On accounting of charging, RNC can notify SGSN to terminate the MBMS service of the UE. If one data volume report message of UE is lost and RNC receives the next data volume report message of the UE before the monitor clock expires, the lost report message can be negligent as the data volume value in the report message is a cumulative value. This won't affect the synchronization between the data volume value collected by UE and that saved by RNC. This is the reason that this invention adopts cumulative value for report.

When an UE transits from normal status to abnormal status, the data volume value after the report of the last time won't be reported to RNC, which will result in inaccurate of the charging. Thus, the smaller that the granularity of the two clocks is set, the more accurate the obtained data volume value will be. But too small clock setting will induce frequent signaling happening and processing, which results in operation load of the network. Therefore, operators can set the values of these two kinds of clocks according to different charging precision to enhance the flexibility of the charging.

The value of the clock used in RNC to monitor Data Volume Report shall be larger than that for Data Volume Report message triggering.

(4) Contents of MBMS-CDR

In this invention, most of MBMS-CDR contents are the same as those of S-CDR in GPRS services except for following two items: a) Record Type:

This field can identify the type of Charging Data Record (CDR), through which Charging Gateway Function (CGF) can distinguish which kind of service each Charging Data Record (CDR) belongs to. Thus, the value of the item shall be MBMS-CDR here, which indicates that the CDR is created for MBSM service. b) Charging ED:

This field is the ID for CDR. It can be used together with GGSN address to uniquely identify all CDRs created by SGSN and related to some MBMS Context (for a single UE). In the charging mechanism of GPRS service, Charging ED is created by

GGSN during PDP context activation (service activation), and then delivered to SGSN as the ED of CDR related to PDP Context, which can guarantee its uniqueness in the GGSN domain. But in MBMS service, only the first UE in a SGSN that activates the service can interact with GGSN and UEs joins in the service sequentially won't interact with GGSN. Thus, in this invention, the task of creating Charging ID is undertaken by SGSN, which needs an algorithm to guarantee that the Charging ED created by SGSN is unique in the whole GGSN domain. A mechanism given in this invention can guarantee the Charging ED created by SGSN is unique in one GGSN domain. As shown in Figure 4, this Charging ED includes two parts.

At 401, the first part is a value given by GGSN to SGSN when the first UE in the SGSN activates MBMS service, which is unique in one GGSN domain and is the same as the first part of Charging ID obtained by all UEs activating the same

MBMS service in a SGSN. That is, GGSN assigns a group of numbers to a SGSN using as the Charging ID of a MBMS service in the SGSN.

At 402, the second part is created by SGSN. The second part depends on the first part. Then, in a SGSN, the creation of the second part only requires the uniqueness in the range of the same first part value, i.e. in a SGSN, for values with the different first part (i.e.: different services), the second part can be the same, which can efficiently make use of the value of the second part. And in a service, if an UE activates and releases service in the same SGSN, the second part used by it in this service can be reused with respect to the first part value it uses. The Charging ED obtained from the combination of the whole first part and the second part is unique in the networks of the packet switching domain within a considerably long period of time. And in mobility management, when MBMS Context of an UE is moved from the old SGSN to a new SGSN, the Charging ED that MBMS Context corresponds to will be moved to the new

SGSN also. Charging Gateway Function (CGF) and Billing System make use of GGSN address and Charging ED together to check the uniqueness of Charging ED (See reference 2). If uncertainty exists, the timestamp opened by Charging Data Record described is added.

(5) The process of periodical Data Volume Report

Figure 5 is a diagram describing the process of periodical Data Volume Report in the two-stage Data Volume Report mechanism according to the invention.

The reference sign 510 indicates the first stage of the two-stage Data Volume Report mechanism.

At 501, when UE starts to collect data volume for a fixed period of time (UE triggers the clock value of Data Volume Report message), it shall initiate a Data Volume Report. At 502, UE sends a Data Volume Report message (UE ED, MBMS Service ED and data volume) to RNC.

This message is sent by UE to the RNC that the UE belongs to, to periodically report the data volume value that it has successfully received. Through this message, a cumulated data volume value is sent to RNC. Each time when RNC receives this message, it then updates the data volume value of the UE saved in it with the data volume value in the message. UE id is used to indicate the UE that sends this message. MBMS Service ID is used to indicate the MBMS service that the message concerns with. And Data Volume is that has been successfully received when sending this message.

At 503, after receiving this Data Volume Report message, RNC updates the Data Volume field of MBMS Context of the UE in the RNC with the new Data Volume value in the message.

At 504, RNC resets the clock that monitors the Data Volume Report message of the UE.

At 505, steps from 501 to 504 are repeated periodically.

The reference sign 511 indicates the second stage of the two-stage Data Volume Report mechanism.

At 506, when SGSN detects that the MBMS-CDR of the UE (also maybe other UEs simultaneously) is going to be closed, it is time for SGSN to collect the Data

Volume value of the UE (also maybe other UEs simultaneously).

At 507, SGSN sends a Data Volume Request message (UE ED List, Request reason, MBMS Service ED) to the RNC that the UE belongs to, to acquire the data volume value. This message is sent by SGSN to RNC to acquire data volume values of one or more UEs. This message happens before the MBMS-CDRs of one or more UEs are going to be closed in SGSN. The UEs that the message concerns with are those identified by UE EDs in the UE List of the message. The parameter of UE id List includes one or more UE EDs, the data volumes of which are indicated to be wanted. The parameter of MBMS Service id indicates the MBMS service used. And the parameter of Request Reason indicates the reason that the message is sent, i.e. the reason that the MBMS-CDR of the UE is closed (MBMS service termination or other reason for closure).

At 508, after RNC receives the Data Volume Request message from SGSN, it sends a Data Volume Response message (MBMS Service ED, Data Volume List) to the requesting SGSN.

This message is a response to Data Volume Request message and is sent to SGSN by RNC. Through this message, RNC can send the data volume value of the requested UE (one or more) to the SGSN that initiates the Data Volume Request message. In which, the parameter of Data Volume List indicates the Data Volume set of UE included in the message. The list includes UE ID and the corresponding Data volume of the UE. The parameter of MBMS Service ED is used to indicate the MBMS service that the message concerns with.

At 509, if the request reason of Data Volume Request message at step 507 is not MBMS service termination, RNC will send a Data Volume Reset message (UE ID,

MBMS Service ED) to the specified UE.

This message is sent from RNC to UE to notify UE of resetting the cumulative data volume value to zero. When UE receives this message, it restarts to collect the data volume it successfully receives. En which, UE ED is used to indicate the UE that the message is sent to and MBMS Service ED is used to indicate the MBMS service that the message concerns with.

(6) The creation process of MBMS-CDR h order to provide the charging information for a single UE in an MBMS service session, SGSN shall provide a Charging Data Record (CDR), which includes the charging information that SGSN has obtained. In this invention, this Charging Data

Record is named as MBMS-CDR. Figure 6 describes the creation process of

MBMS-CDR.

The reference sign 601 indicates an example for the process of an UE activating MBMS service, but this invention is not restricted to this specified MBMS Service

Activation Process. Any MBMS Service Activation Process is applicable to this invention.

At 602, when an UE activate the MBMS service selected, an MBMS Context will be created for the UE in SGSN, and at the same time, MBMS-CDR accompanying the MBMS Context will be created by SGSN. The creation of MBMS-CDR is referred to the data in Charging Characteristics Profile.

(7) The start of data volume statistic

Figure 7 describes the starting time and process of a data volume statistic of UE. 701, 702, 703 and 704 are the whole process of service data incoming, UE notification, and RAB and RB setup after obtaining a service request from UE. This invention is not restricted to specified RAB and RB setup process.

At 705, after the setup of RAB and RB, each UE starts to com ect the data volume value that it has successfully received and set the clock for periodical data volume value report. At the same time, RNC sets a clock for each UE, which starts to monitor the

Data Volume Report message of the subsidiary UE. At 706, MBMS service data are sent to UE

(8) The termination of data volume accounting in a SGSN Before the MBMS Context of an UE is going to be deleted in SGSN, SGSN shall close the MBMS-CDR related to the MBMS Context. Thus, SGSN sends Data Volume Request message to collect the data volume value received by the UE. The RNC that the UE belongs to, then responses to the SGSN. The response message includes the data volume value of the UE. There are four situations that can result in the deletion of MBMS Context of an UE in a SGSN (Figure 8), e.g.

At 801, the service initiated by UE is terminated.

At 802, the MBMS service initiated by the core network is terminated. In this situation, SGSN can obtain data volume values of several UEs simultaneously from one Data Volume Request message. At 803, UE is in abnormal status, which can be detected by the clock in RNC that monitors the Data Volume Report message of UE.

At 804, UE hands over between SGSNs due to moving.

If any one of above situations (801, 802, 803, 804) happens, following two processes will be executed: At 805, SGSN sends a Data Volume Request message to acquire the data volume value of the UE (or other UEs at the same time).

At 806, one MBMS-CDR of the UE is closed in the SGSN.

(9) UE moves between SGSNs. hi this invention, there are two kinds of situations of UE moving between SGSNs that are related with charging:

* UE is in the process of Routing Area Update. The MBMS-CDR corresponding to the UE is closed in the old SGSN and the new SGSN will send a SGSN Context Request (the old P-TMSI, the old RAI, the old P-TMSI signature) message to the old SGSN. In the SGSN Context Response message (MM context, PDP Context, MBMS

Context), the corresponding MBMS Context and Charging ED of the UE are transferred from the old SGSN to the new SGSN without changing the Charging ID. A new MBMS-CDR corresponding to the MBMS Context of the UE is created in the new SGSN and the data volume accounting of the UE restarts from zero. * UE is in the process of relocation. The MBMS-CDR corresponding to the UE is closed in the old SGSN and the old SGSN will send a Forward Relocation Request message (EMSI, Tunnel Terminator ED signaling, MM Context, PDP Context, Destination ED, UTRAN Transparent Container, RANAP Reason, and MBMS Context) message to the new SGSN, through which MBMS Context and Charging ED are transferred from the old SGSN to the new SGSN without changing the Charging ID. A new MBMS-CDR corresponding to the MBMS Context of the UE is created in the new SGSN and the data volume accounting of the UE restarts from zero.

(10) Detection and processing of UE in abnormal status When an UE appears abnormal and enters the abnormal status, RNC can't receive the periodical Data Volume Report message from the UE. On accounting of charging, the MBMS service of the UE shall be terminated. Figure 9 describes the process of detecting UE in abnormal status.

At 901, when UE is in abnormal status, the periodical Data Volume Report message of the UE can't arrive at the RNC that the UE belongs to.

At 902, the clock used to detect the periodical Data Volume Report of the UE expires after a period of time. RNC then judges that exceptions happen with the UE.

At 903, RNC then sends a Deactivate MBMS Context Request message to SGSN to terminate the MBMS service of the UE. At 904, after the SGSN receives the Deactivate MBMS Context Request message, it executes according process to terminate the MBMS service of the UE. The process of SGSN terminating MBMS service of a certain UE doesn't belong to this invention.

While the invention has been shown and described with reference to certain preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.

Claims

WHAT IS CLAIMED IS :

1. A volume-based charging method for a UE in MBMS service comprising following steps: (1) when the UE starts to receive MBMS service data, the UE counting the data volume it has successfully received and sending a report message including the data volume to the Radio Network Controller (RNC) it belongs to, after the RNC receives the message of the data volume from the UE, the RNC saving the data volume successfully received by the UE and updating the data volume during the MBMS service is going on;

(2) when SGSN needs to close the service or query a billing data record (MBMS-CDR) of the UE, the SGSN voluntarily sending a message for requesting a data volume (data volume request message) to the RNC that saves the most recent data volume of the UE, and the RNC sending the most recent data volume response message after receiving the data volume request message, and feed backing the most recent data volume of the UE on the data volume response message to SGSN;

(2) creating a charging data record (MBMS-CDR) for billing according to the most recent data volume message.

2. The charging method as claimed in claim 1, the data volume reported is a cumulative value.

3. The charging method as claimed in clam 1, the UE periodically send the data volume to the RNC or the UE send the data volume when the RNC request the data.

4. The charging method as claimed in claim 1, in the steps, if SGSN has a request to close MBMS-CDRs of multiple UEs simultaneously, then only one data volume request message is sent by SGSN to the RNC to obtain the data volume of multiple

UEs.

5. The charging method as claimed in claim 3, the Radio Network Controller (RNC) sets MBMS Context for each UE, which includes a Data Volume field used to store the data volume value of the UE, every time when RAN receives the data volume report message of an UE, it then fetching relevant data from the received message, finding MBMS Context of the UE and updating the Data Volume field with the data in the report message, when the RAN receives a message of data volume request from SGSN, it fetching the data volume value from the Data Volume field of MBMS Context of the UE, and feed backing the up-dated data volume of the UE to SGSN via a response message corresponding to the Data Volume Request signaling message.

6. The charging method claimed in claim 4, the Charging Data Record (MBMS-CDR) including:

Record Type field, through which Charging Gateway Function (CGF) can distinguish which kind of service each Charging Data Record (CDR) belongs to; Charging ID field, which is an identifier for CDR and can be used together with

GGSN address to uniquely identify all CDRs created by SGSN and related to a certain MBMS Context, the Charging ID including two parts: the first part (401) is a value given by GGSN to the SGSN when the first UE in a SGSN activates MBMS service, which is unique in one GGSN domain and is the same as the first part of Charging ID obtained by all UEs activating the same MBMS service in a SGSN; the second part

(402) is created by SGSN, in a SGSN, the creation of the second part only requires the uniqueness in the range of the same first part value,

The Charging ID, which combines the first part and the second part, is unique in the networks of the packet switching domain within a considerably long period of time.

7. The charging method as claimed in claim 5 Charging Gateway Function (CGF) and Billing System making use of GGSN address and the Charging ED together to check the uniqueness of Charging ID, if uncertainty exists, the timestamp opened by the Charging Data Record should be added.

8. The charging method as claimed in claim 6, in mobility management, when MBMS Context of an UE is moved from an old SGSN to a new SGSN, the Charging ID that MBMS Context correspondly moves to the new SGSN also.

9. The charging method as claimed in claim 1, the time interval with which UE reports the data volume it has successfully received to RNC periodically is generated by the first clock in UE.

10. The charging method as claimed in claim 8, the second clock set by RNC for each UE is used to monitor the data volume report message of UE, each time when RNC receives a data volume report message from a certain UE, the second clock monitoring the UE is reset, when the data volume report message of UE is lost, the second clock monitoring the data volume report message of the UE expires after a period of time and RNC judges that the UE is in abnormal status, on accounting of charging, RNC notify SGSN to terminate the MBMS service of the UE; if one data volume report message of a certain UE is lost and RNC receives the next data volume report message of the UE before the second clock expires, the lost report message is negligent and the data volume value collected by UE is synchronized with that saved by RNC, then RNC won't notify SGSN to terminate the MBMS service of the UE.

11. The charging method as claimed in claim 2 or 9, the data volume report message including: UE ID, which is used to indicate the UE sent this message; MBMS service ID, which is used to indicate the MBMS service that the message concerns with; Data Volume that UE has successfully received when the data volume report message is been sending.

12. The charging method as claimed in claim 2 or 9, the Data Volume Request message sent from SGSN to RNC is used to obtain the data volume values of one or more UEs, the Data Volume Request message including: UE ID List, which includes one or more UE EDs that indicate the data volumes of which UEs are interested by the data volume request message; Request Reason, which indicates the reason why the data volume request message is sent; MBMS Service ID, which indicates the MBMS used.

13. The charging method as claimed in claim 2 or 9, the Data Volume Response message including MBMS Service ID and Data Volume List, and MBMS Service ED being used to indicate the MBMS service that the Data Volume Response message concerns with; Data Volume List indicating the data volume set of the UEs included in the Data Volume Response message and including UE ED and the corresponding data volume of the UE.

14. The charging method as claimed in claim 2 or 9, if the request reason in the Data Volume Request message is not Multimedia Broadcast/Multicast Service Temiination, Radio Network Controller (RNC) sending a Data Volume Reset message to the specified User Equipment (UE) to notify User Equipment (UE) of resetting the cumulative data volume value to zero, when User Equipment (UE) receives this message, it restarting to collect the data volume it successfully receives, the Data Volume Reset including User Equipment (UE) ID and Multimedia Broadcast/Multicast Service ED, and the User Equipment (UE) ED being used to indicate the UE that the Data Volume Reset message is sent to, and Multimedia Broadcast/Multicast Service ED being used to indicate the MBMS service that the Data Volume Reset message concerns with.

15. The charging method as claimed in claim 4, when a User Equipment (UE) activate the Multimedia Broadcast/Multicast Service (MBMS) selected, an MBMS Context being created for the User Equipment (UE) in Service GPRS Supporting Node (SGSN), and at the same time, a Multimedia Broadcast/Multicast Service-Context Data

Record (MBMS-CDR) accompanying the MBMS Context being created by Service GPRS Supporting Node (SGSN) according to Charging Characteristics Profile.

16. The charging method as claimed in claim 9, when a User Equipment (UE) activate the Multicast Broadcast/Multinie Service (MBMS) selected, an MBMS Context being created for the User Equipment (UE) in Service GPRS Supporting Node (SGSN), and at the same time, a Multimedia Broadcast/Multicast Service-Context Data Record (MBMS-CDR) accompanying the MBMS Context being created by Service GPRS Supporting Node (SGSN) according to Charging Characteristics Profile.

17. The charging method as claimed in claim 14 or 15, if any of the following four situations happens, the MBMS Context of a User Equipment (UE) being deleted from a Service GPRS Supporting Node (SGSN):

Multimedia Broadcast/Multicast Service (MBMS) termination is initiated by User Equipment (UE) ;

Multimedia Broadcast/Multicast Service (MBMS) termination is initiated from the core network, Service GPRS Supporting Node (SGSN) can obtain data volume values of User Equipment (UE) via one Data Volume Request message;

User Equipment (UE) hands over between Service GPRS Supporting Nodes (SGSN) due to moving.

18. The charging method as claimed in claim 16, before the MBMS Context of an UE is going to be deleted in SGSN, SGSN sending a Data Volume Request message to obtain the data volume value of the UE or other UEs at the same time and SGSN closing the MBMS-CDR related to the MBMS Context.

19. The charging method as claimed in claim 16, the moving of User Equipment (UE) between Service GPRS Supporting Nodes (SGSN) including Routing Area

Update of User Equipment (UE), the Charging Data Record (MBMS-CDR) of the User Equipment (UE) being closed in the old Service GPRS Supporting Node (SGSN), and the new Service GPRS Supporting Node (SGSN) sending a SGSN Context Request message to the old Service GPRS Supporting Node (SGSN), in the SGSN Context Response message, the corresponding MBMS Context and User Equipment (UE) ED are transferred from the old Service GPRS Supporting Node (SGSN) to the new Service GPRS Supporting Node (SGSN) without changing the Charging ED, a new MBMS-CDR corresponding to the MBMS Context of the moving User Equipment (UE) being created in the new Service GPRS Supporting Node (SGSN) and the data volume accounting of the moving UE restarting from zero.

20. The charging method as claimed in claim 16, the moving of the UE between Service GPRS Supporting Nodes (SGSN) including User Equipment (UE) relocation, the MBMS-CDR corresponding to the moving User Equipment (UE) being closed in the old Service GPRS Supporting Node (SGSN) and the old Service GPRS Supporting

Node (SGSN) sending a Forward Relocation Request message to the new Service GPRS Supporting Node (SGSN), through which MBMS Context and Charging ID are transferred from the old Service GPRS Supporting Node (SGSN) to the new Service GPRS Supporting Node (SGSN) without changing the Charging ID, a new MBMS-CDR corresponding to the MBMS Context of the moving User Equipment (UE) being created in the new Service GPRS Supporting Node (SGSN) and the data volume accounting restarting from zero.

21. The charging method as claimed in claim 18, SGSN Context Request message including the old P-TMSI, the old RAI and the old P-TMSI signature; SGSN Context

Response message including MM Context, PDP Context, and MBMS Context.

22. The charging method as claimed in claim 18, Forward Relocation Request message mcluding EMSI, Tunnel Terminator ED signaling, MM Context, PDP Context, Destination ED, UTRAN Transparent Container, RANAP Reason, and MBMS Context.