CN101925009A

CN101925009A - Method and system for distinguishing MBMS (Multimedia Broadcast Multicast Service) user surface data sending modes during charging

Info

Publication number: CN101925009A
Application number: CN2009102036793A
Authority: CN
Inventors: 郭文洁
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2009-06-15
Filing date: 2009-06-15
Publication date: 2010-12-22
Anticipated expiration: 2029-06-15
Also published as: CN101925009B

Abstract

The invention relates to a method and a system for distinguishing MBMS (Multimedia Broadcast Multicast Service) user surface data sending modes during charging, which are applied to MBMS and E-MBMS (Enhanced Multimedia Broadcast Multicast Service) network architectures. During the request process for initiating a conversation, a GGSN (Gateway GPRS Support Node)/MBMS-GW (Gateway) allocates IP multicast addresses and source addresses and public TEID-U (Tunnel Endpoint Identifier-User) to downstream nodes; if the downstream nodes receive the IP multicast sending, the GGSN/MBMS-GW carries the IP multicast addresses and the source addresses and the public TEID-U received by the downstream nodes in a charging initiating request and records in a CDR with the charging data function of opened GGSN/MBMS-GW; and if the downstream nodes do not receive the IP multicast sending, the GGSN/MBMS-GW carries a list of the downstream nodes in the charging initiating request and records in the CDR with the charging data function of opened GGSN/MBMS-GW.

Description

The method and system of distinguishing MBMS (Multimedia Broadcast Multicast Service) user surface data sending modes during charging

Technical field

The present invention relates to the communications field, in particular to the method and system of a kind of multimedia broadcast-multicast service (Multimedia Broadcast/Multicast Service abbreviates MBMS as) distinguishing MBMS (Multimedia Broadcast Multicast Service) user surface data sending modes during charging.

Background technology

The MBMS of definition and multimedia broadcast-multicast service (the evolved MBMS of evolution in current 3GPP wireless communication standard tissue, be called for short eMBMS), all be meant in existing cordless communication network, utilize multicast (Multicast) or broadcasting (Broadcast) technology to set up the passage of business datum, thereby finish the business model of distribution from any to multiple spot.Cordless communication network at the 3GPP definition, the wireless access technology relevant of its definition with MBMS, eMBMS, up to the present, comprise the 2G GERAN in period, 3G universal land radio access web (the Universal TerrestrialRadio Access Network in period, abbreviate UTRAN as) and the universal land radio access web (evolved Universal Terrestrial Radio Access Network abbreviates E-UTRAN as) of evolution.

In MBMS, the network architecture of the multimedia broadcast-multicast service pattern of 3GPP definition as shown in Figure 1.Broadcast multicast service center (Broadcast Multicast-Service Centre wherein, abbreviate BM-SC as) be the cradle of business datum, GGSN (Gateway GPRS Support Node) is a Gateway GPRS Support Node, be responsible for the reception of all MBMS data of sending from business network element, and and then be forwarded to follow-up network node, according to the upper-lower position of network diagram, be called and be forwarded to downstream node (also can be described as descendant node).MBMS network support GPRS Tunnel Protocol (GTP) during 2G/3G sends user face data, and user face data issues to professional GRPS support node SGSN (Serving GPRS Support Node) then via GGSN.For the wireless access technology UTRAN of 3G, if the IP multicast sender formula of user's face is supported in the BM-SC upgrading, then user face data can use the IP multicast to send from GGSN bypass SGSN; Otherwise, if the IP multicast sends and is not supported, will rollback (fall back) to the point-to-point GTP-U that sets up GGSN and SGSN (User planeof GPRS Tunneling Protocol, GPRS Tunneling Protocol-User plane) tunnel style is issued to corresponding descendant node again via SGSN.

In order to set up the passage of whole service, send the eve in data, need send relevant signaling each node from service source to down going channel, with the session identification of informing that each node should business, identify this professional multicast address information, the address of each descendant node, QoS, initiation time and service area or the like information.This signaling is defined as the MBMS session at present and begins signaling.Signaling during service ending is a MBMS conversation end signaling, with release channel.

The situation (MBMS improvement) that MBMS strengthens when considering 2G/3G, if the BM-SC upgrading supports the IP multicast to send (IP Multicast Delivery) and MBMS head compression technology (MBMS-HC), these relevant information can be issued to GGSN by relevant signaling (message such as MBMS session start, MBMS session stop).Whether the information in these signalings can dispose in BM-SC (or its network management system), also can dispose on the GGSN and support the IP multicast to send (IPMulticast Delivery).BM-SC/GGSN obtains these information when sending conversation message, form the parameter of conversation message.

In eMBMS, the network architecture of the multimedia broadcast-multicast service pattern of 3GPP definition as shown in Figure 2.Wherein BM-SC is the cradle of business datum, and all data send to other network nodes from BM-SC.MBMS-GW is the gateway of the business datum of mobile communication core net, is responsible for the reception of all MBMS data of sending from business network element, and and then be forwarded to follow-up network node, be called according to the upper-lower position of network diagram and be forwarded to descendant node.According to the wireless side access technology is E-UTRAN or UTRAN, and the descendant node type of MBMS-GW can correspond to MME and SGSN.It is to adopt IP multicast sender formula (IP Multicastdelivery) that the MBMS user face data sends.

But (legacy) network architecture that can not get rid of the succession of not supporting IP multicast sender formula when networking is received the situation of MBMS-GW, that is: the network of 2G/3G is received the situation of MBMS-GW by SGSN.At this moment, also can rollback (fall back) between SGSN and the MBMS-GW to the point-to-point GTP-U tunnel of setting up MBMS-GW and SGSN, user data is issued to corresponding descendant node again via SGSN.

No matter be the MBMS framework of Fig. 1 or the eMBMS framework of Fig. 2, in case consider complicated networking situation, the situation (return back to and set up point-to-point GTP-U tunnel, send user data via SGSN) of supporting the situation that the IP multicast sends and not supporting the IP multicast to send is all might exist.And present MBMS charges and only to have considered not support charging under the situation that the IP multicast sends, consider to support in the situation and a MBMS broadcasting of IP multicast transmission, support the IP multicast to send and do not support the IP multicast to send two kinds of differentiations under may the coexistence situation and charge, and both rates etc. may be different.

Begin definition with the conversation end signaling about session, referring to Fig. 3 and Fig. 4.

Among Fig. 3 and Fig. 4 all the MBMS with 2G/3G period be example, descriptive session begins the sending method of request message and conversation end request message.Session under the eMBMS framework begins with the process of the transmission of conversation end request message and Fig. 3 and Fig. 4 similar, and as shown in Figure 5 and Figure 6, concrete steps repeat no more.

As shown in Figure 3, for the MBMS session in existing 2G/3G period begins request message (abbreviate session as and begin request) flow process, comprise the steps:

Step 301, BM-SC sends MBMS session beginning request message to each GGSN;

Described MBMS session begins request message can carry the conversation class parameter: service quality (Qualityof Service, abbreviate QoS as), MBMS service area tabulation (list of MBMS service Area), MBMS session identification (MBMS Session identifier), estimate session persistence (estimatedsession duration) and purpose network identity information such as (MBMS xG indicator), and address class parameter: downstream node tabulation (List of DownstreamNodes) etc., comprise the address of downstream node in the downstream node tabulation and be used for tunnel endpoint identifier (the TunnelEndpoint Identifier Data that user face data sends, be abbreviated as TEID, that is: TEID-U).

Step 302, GGSN preserves the parameter information in the message, and the answer session begins request response to BM-SC;

Step 303, GGSN sends MBMS session beginning request message to SGSN;

Step 304, SGSN preserves the information in the message, and session is begun request message sends to wireless side;

Step 305, wireless side are returned session and are begun request responding message;

Step 306 after SGSN receives that from wireless side all begin request responding message to session, begins response message (abbreviate session as and begin response) with session and sends to GGSN;

Step 307 is reserved Radio Resource and is set up down going channel, the transmission data.

As shown in Figure 4, for the existing 2G/3G MBMS conversation end flow process in period, comprise the steps:

Step 401, BM-SC sends MBMS conversation end request message (abbreviating the conversation end request as) and gives GGSN; Carry information such as session identification and service identification and downstream node tabulation in the message.GGSN replys the conversation end response message and gives BM-SC, and discharge own preservation about this professional information;

Step 402, GGSN transmitting MBMS conversation end request message are given and to be received that session begins the SGSN of request message before this, and SGSN returns response message, and discharge own preservation about this professional information;

Step 403, SGSN is transmitted to wireless side with this information, and wireless side is returned the conversation end response message;

Step 404, the wireless side resource discharges.

The problem that prior art exists is:

1) shown in the MBMS framework of Fig. 1,2G/3G BM-SC in period, network elements such as GGSN, UTRAN can be upgraded and be supported the IP multicast to send and/or the compression of MBMS head, also can not support the IP multicast to send it back and fall back on point-to-point GTP-U tunnel style.Prior art has only defined the charging of not supporting the IP multicast to send situation, supports situation and differentiation in both cases that the IP multicast sends to charge after not considering upgrading BM-SC.

2) shown in the eMBMS framework of Fig. 2, in the eMBMS framework, definition now is the S4 interface between MBMS-GW and the SGSN, therefore must be to support the IP multicast to send.; in the time of can not getting rid of actual networking; the wireless side of the compatible 2G/3G of eMBMS framework inserts the possibility that MBMS-GW only supports the pattern of GTP tunnel agreement, as only supporting the GTP tunnel agreement between MBMS-GW and the SGSN, allows the access tributary of original 2G/3G directly receive situation on the MBMS-GW.Whether prior art is not considered at this moment at supporting two kinds of situations of IP multicast transmission need distinguish charging.

Summary of the invention

The technical problem to be solved in the present invention provides a kind of method and system of distinguishing MBMS (Multimedia Broadcast Multicast Service) user surface data sending modes during charging, can know the send mode of MBMS user face data when chargeing.

In order to address the above problem, the invention provides a kind of method of distinguishing MBMS (Multimedia Broadcast Multicast Service) user surface data sending modes during charging, be applied to the MBMS network architecture, have at least a broadcast multicast service center (BM-SC) and a Gateway GPRS Support Node (GGSN) to support the IP multicast to send after capacity upgrade in this MBMS network architecture, this method comprises:

Begin in the request process in the session of supporting the BM-SC initiation that the IP multicast sends, support GGSN distributing IP multicast address and source address and the common user plane tunnel endpoint identifier (TEID-U) that the IP multicast sends and send to downstream node, notify described GGSN whether to accept the IP multicast after described downstream node is received and send;

Accepting the IP multicast if any downstream node sends, described GGSN carries IP multicast address and source address and the public TEID-U that described downstream contact is accepted in beginning the request of chargeing, charging data function writes down described IP multicast address and source address and public TEID-U in the charging data record of opening for described GGSN (CDR);

Do not accept the IP multicast if any downstream node and send, described GGSN carries the downstream node tabulation that comprises these downstream nodes in beginning the request of chargeing, and charging data function writes down described downstream node tabulation in the CDR that opens for described GGSN.

Further, said method also can have following characteristics:

BM-SC and/or GGSN carry the IP multicast whether an expression support the IP multicast to send beginning of sending to charging data function and send sign in the request of chargeing; Perhaps, BM-SC and/or GGSN just carry an IP multicast beginning of sending to charging data function and send sign only when supporting that the IP multicast sends in the request of chargeing;

Charging data function is provided with an IP multicast and sends sign in the CDR that opens for BM-SC and/or GGSN, whether this IP multicast sends the value of sign and represent to support the IP multicast to send.

Further, said method also can have following characteristics:

BM-SC and/or GGSN carry the MBMS head compression sign whether an expression supports the compression of MBMS head beginning of sending to charging data function in the request of chargeing; Perhaps, BM-SC and/or GGSN just carry MBMS head compression sign beginning of sending to charging data function only when supporting the compression of MBMS head in the request of chargeing;

Charging data function is provided with MBMS head compression sign in the CDR that opens for BM-SC and/or GGSN, the value of this MBMS head compression sign represents whether to support the compression of MBMS head.

Further, said method also can have following characteristics:

Described GGSN begins to ask the IP multicast address that will distribute and source address and public user's face tunnel endpoint identifier (TEID-U) to send to the SGSN in downstream by session;

After described SGSN receives that session begins request, send session to universal land radio access web (UTRAN) and begin request, carry described IP multicast address and source address and public TEID-U;

After described UTRAN receives that session begins request, as IP multicast address and source address and public TEID-U as described in accepting, begin response by session and notify described SGSN to accept the transmission of IP multicast, otherwise, begin response by session and notify described SGSN not accept the transmission of IP multicast;

Described SGSN begins response message by session and notifies described GGSN to accept the transmission of IP multicast when having UTRAN to accept the transmission of IP multicast; When having UTRAN not accept the transmission of IP multicast, beginning response message by session provides TEID-U, and sets up GTP tunnel transmission user face data between the GGSN;

When having SGSN to accept the transmission of IP multicast, described GGSN initiates the IP multicast and sends.

In order to solve the problems of the technologies described above, the present invention also provides a kind of method of distinguishing MBMS (Multimedia Broadcast Multicast Service) user surface data sending modes during charging, is applied to the MBMS network architecture of evolution, and this method comprises:

The session of initiating at BM-SC begins in the request process, MBMS gateway (MBMS-GW) distributing IP multicast address and source address and public user's face tunnel endpoint identifier (TEID-U) also send to downstream node, and described downstream node is notified described MBMS-GW whether to accept the IP multicast and sent;

Accepting the IP multicast if any downstream node sends, described MBMS-GW carries IP multicast address and source address and the public TEID-U that described downstream contact is accepted in beginning the request of chargeing, charging data function writes down described IP multicast address and source address and public TEID-U in the charging data record of opening for described MBMS-GW (CDR);

Do not accept the IP multicast if any downstream node and send, described MBMS-GW carries the downstream node tabulation that comprises these downstream nodes in beginning the request of chargeing, and charging data function writes down described downstream node tabulation in the CDR that opens for described MBMS-GW.

Further, said method also can have following characteristics:

BM-SC and/or MBMS-GW carry the MBMS head compression sign whether an expression supports the compression of MBMS head beginning of sending to charging data function in the request of chargeing; Perhaps, BM-SC and/or MBMS-GW just carry MBMS head compression sign beginning of sending to charging data function only when supporting the compression of MBMS head in the request of chargeing;

Charging data function is provided with MBMS head compression sign in the CDR that opens for BM-SC and/or MBMS-GW, the value of this MBMS head compression sign represents whether to support the compression of MBMS head.

Further, said method also can have following characteristics:

Described downstream node comprises SGSN, and described MBMS-GW begins to ask the IP multicast address that will distribute and source address and public TEID-U to send to the SGSN in downstream by session;

Described SGSN begins response message by session and notifies described MBMS-GW to accept the transmission of IP multicast when having UTRAN to accept the transmission of IP multicast; When having downstream node not accept the IP multicast to send, described SGSN session begin to provide in the response message TEID-U and and GGSN between return back to the mode that point-to-point GTP tunnel sends user face data;

Described MBMS-GW initiates the IP multicast and sends when having SGSN to accept the transmission of IP multicast.

Further, said method also can have following characteristics:

If SGSN and MBMS-GW set up GTP tunnel and send user face data, this SGSN sends begins to comprise the downstream node tabulation in the request of chargeing, the address and the TEID-U that comprise the downstream node of not supporting that the IP multicast sends in this downstream node tabulation also comprise described downstream node tabulation among the CDR of charging data function for this SGSN generation.

Correspondingly, the invention provides a kind of system of distinguishing MBMS (Multimedia Broadcast Multicast Service) user surface data sending modes during charging, adopt the MBMS network architecture, broadcast multicast service center (BM-SC), Gateway GPRS Support Node (GGSN) and charging data function, wherein:

Have at least a BM-SC and a GGSN after capacity upgrade, to support the IP multicast to send;

The GGSN that supports the IP multicast to send is used for after the session of receiving the BM-SC transmission of supporting that the IP multicast sends begins request, and distributing IP multicast address and source address and public user's face tunnel endpoint identifier (TEID-U) send to downstream node; Accepting the IP multicast if any downstream node sends, in beginning the request of chargeing, carry IP multicast address and source address and public TEID-U that described downstream contact is accepted, do not accept the IP multicast if any downstream node and send, in beginning the request of chargeing, carry corresponding downstream node tabulation;

Described charging data function is used for the described described downstream node of asking to comprise that begins to charge is tabulated, described IP multicast address that perhaps comprises and source address and public TEID-U, the described downstream node tabulation that perhaps comprises, described IP multicast address and source address and public TEID-U are recorded in in the charging data record (CDR) that described GGSN opens.

Further, said system also can have following characteristics:

Described BM-SC and/or GGSN carry the IP multicast whether an expression support the IP multicast to send beginning of sending to charging data function and send sign in the request of chargeing; Perhaps, described BM-SC and/or GGSN just carry an IP multicast beginning of sending to charging data function and send sign only when supporting that the IP multicast sends in the request of chargeing;

Described charging data function is provided with an IP multicast and sends sign in the CDR that opens for BM-SC and/or GGSN, whether this IP multicast sends the value of sign and represent to support the IP multicast to send.

Further, said system also can have following characteristics:

Described BM-SC and/or GGSN carry the MBMS head compression sign whether an expression supports the compression of MBMS head beginning of sending to charging data function in the request of chargeing; Perhaps, described BM-SC and/or GGSN just carry MBMS head compression sign beginning of sending to charging data function only when supporting the compression of MBMS head in the request of chargeing;

Described charging data function is provided with MBMS head compression sign in the CDR that opens for BM-SC and/or GGSN, the value of this MBMS head compression sign represents whether to support the compression of MBMS head.

Correspondingly, the present invention also provides a kind of system of distinguishing MBMS (Multimedia Broadcast Multicast Service) user surface data sending modes during charging, adopts the MBMS network architecture of evolution, broadcast multicast service center (BM-SC), MBMS gateway (MBMS-GW) and charging data function, wherein:

Described MBMS-GW is used for after receiving that session that BM-SC sends begins request, and distributing IP multicast address and source address and public user's face tunnel endpoint identifier (TEID-U) also send to downstream node; Accepting the IP multicast if any downstream node sends, in beginning the request of chargeing, carry IP multicast address and source address and public TEID-U that described downstream contact is accepted, do not accept the IP multicast if any downstream node and send, in beginning the request of chargeing, carry corresponding downstream node tabulation;

Described charging data function is used for the described described downstream node of asking to comprise that begins to charge is tabulated, described IP multicast address that perhaps comprises and source address and public TEID-U, the described downstream node tabulation that perhaps comprises, described IP multicast address and source address and public TEID-U are recorded in in the charging data record (CDR) that described MBMS-GW opens.

Further, said system also can have following characteristics:

Described BM-SC and/or MBMS-GW carry the MBMS head compression sign whether an expression supports the compression of MBMS head beginning of sending to charging data function in the request of chargeing; Perhaps, described BM-SC and/or MBMS-GW just carry MBMS head compression sign beginning of sending to charging data function only when supporting the compression of MBMS head in the request of chargeing;

Described charging data function is provided with MBMS head compression sign in the CDR that opens for BM-SC and/or MBMS-GW, the value of this MBMS head compression sign represents whether to support the compression of MBMS head.

Such scheme has overcome the situation of only having considered not support the transmission of IP multicast when present MBMS charges, consider to support in the situation and a MBMS broadcasting that the IP multicast sends, support the IP multicast to send and do not support the IP multicast to send the problem that two kinds of differentiations under may the coexistence situation are chargeed; And eMBMS only considered to support the situation that the IP multicast sends when chargeing, and do not consider the problem that the differentiation when supporting and not supporting two kinds of situations coexistences that the IP multicast sends is chargeed.Realized distinguishing charging according to the concrete condition whether network node supports the IP multicast to send.

Description of drawings

Accompanying drawing described herein is used to provide further understanding of the present invention, constitutes the application's a part, and illustrative examples of the present invention and explanation thereof are used to explain the present invention, do not constitute improper qualification of the present invention.In the accompanying drawings:

The network architecture schematic diagram of multimedia broadcast-multicast service pattern when Fig. 1 is 2G/3G;

Fig. 2 is the network architecture schematic diagram of the multimedia broadcast-multicast service pattern of evolution;

MBMS session when Fig. 3 is 2G/3G begins the request process flow chart;

MBMS conversation end request process flow chart when Fig. 4 is 2G/3G;

Fig. 5 is that the eMBMS session begins the request process flow chart;

Fig. 6 is an eMBMS conversation end request process flow chart;

Fig. 7 is that the eMBMS session of the embodiment of the invention begins the flow chart that comprises charging message that there is IP multicast transmission relevant information in request process;

Fig. 8 is that the eMBMS conversation end request process of the embodiment of the invention exists the IP multicast to send the flow chart that comprises charging message of relevant information;

MBMS session when Fig. 9 is the 2G/3G of the embodiment of the invention begins request process and exists the IP multicast to send the flow chart that comprises charging message of relevant information;

MBMS conversation end request process when Figure 10 is the 2G/3G of the embodiment of the invention exists the IP multicast to send the flow chart that comprises charging message of relevant information.

Embodiment

Use down under the offline charging of the MBMS broadcasting that the IP multicast sends and the broadcast mode that 2G/3G supports the MBMS business scenario explanation MBMS that the IP multicast sends period MBMS user face data to content supplier to send with regard to the eMBMS framework respectively below and write down the off-line accounting method whether the IP multicast sends.

Embodiment one:

Present embodiment is based on the eMBMS framework, and eMBMS framework default situations is to support what the IP multicast sent.Assumed wireless side technology is E-UTRAN and UTRAN, UTRAN for E-UTRAN and the transmission of support IP multicast, the basic charge unit MBMS-GW-CDR that charging message that MBMS-GW sends and charging data function (CDF:Charging Data Function) produce for MBMS-GW, CDR wherein is writing a Chinese character in simplified form of charging data record (Charging Data Record), to comprise IP multicast address and source address (IP Multicast andSource addresses) (in the literary composition, IP multicast address and source address should be considered as a parameter) and public user's face tunnel endpoint identifier (TEID-U) among the MBMS-GW-CDR.

Because do not get rid of the network element of UTRAN for (legacy) of succession, not accepting the IP multicast sends, at this moment, the charging message that sends of MBMS-GW and CDF also will comprise among the MBMMS-GW-CDR that produces of MBMS-GW to be used for the downstream node list information etc. that point-to-point GTP-U tunnel sends user face data.

The eMBMS session begins request process as shown in Figure 7:

Step 701:BM-SC sends MBMS session beginning request message to MBMS-GW;

This MBMS session begins request and disappears and carry the tabulation of QoS, MBMS service area, the MBMS session identification, estimate session persistence, purpose network identity and MBMS head compression sign information such as (MBMS HCIndicator).In the present embodiment, MBMS head compression sign is used to represent whether retrieving head compresses respective nodes (being BM-SC), can be to support or do not support here.

Step 702:MBMS-GW replys session respectively and begins the request response to BM-SC;

After step 702a:BM-SC receives that first session that any one MBMS-GW sends begins the request response, send beginning charging request message ACR[Start] give charging data function (CDF);

Among the ticket C-BMSC-CDR that CDF opens for this BM-SC except time, data traffic tabulation (only adding up down direction), content supplier's identifier, MBMS session identification, downstream node list information etc., can also comprise information such as MBMS head compression sign, CDF returns charge response message and gives BM-SC.

MBMS session in the subsequent step begins the request message process and can occur with the beginning charging request message process of step 702a is parallel.

Step 703: each MBMS-GW divides IP multicast address and source address and the public TEID-U that is used in the transmission of IP multicast, and the MBMS of SGSN that enumerates in the list parameter and/or MME transmission to downstream node session begins request message;

The MBMS session begins request message and comprises session parameter: Temporary Mobile Group Identity (TMGI), traffic identifier (Flow Identifier (Broadcast only)), QoS, MBMS service area (MBMSservice Area), session identification (Session identifier), estimate session persistence, broadcast/group broadcast (broadcast/multicast), MBMS data transmitting time (time to MBMS data transfer), the IP multicast address and the source address that are used for the backbone network distribution, public TEID-U, MBMS head compression sign etc.

Because the MME downstream node should support the IP multicast to send, below flow process only SGSN and downstream node thereof are described.

Step 704: each SGSN sends MBMS session beginning request message to the UTRAN that is connected to this node;

This MBMS session begins request message and comprises session parameter: Temporary Mobile Group Identity, and QoS, the MBMS service area, session identification is estimated session persistence, broadcast/group broadcast, information and MBMS head compression signs such as MBMS data transmitting time.Also should comprise IP multicast address and source address and public TEID-U that MBMS-GW distributes.

Step 705: each UTRAN begins response message notice SGSN by session and whether accepts the transmission of IP multicast;

MBMS-GW distributes in the beginning request message if UTRAN accepts session IP multicast address and source address and public TEID-U, then begin response message notice SGSN and accept the transmission of IP multicast by session, MBMS-GW distributes in the beginning request message if UTRAN does not accept session IP multicast address and source address or public TEID-U, then UTRAN begins response message notice SGSN by session and does not accept the IP multicast and send, during notice, as can being when accepting the IP multicast and send, to begin to carry in the response message to accept the indication information that the IP multicast sends in session, do not carry this indication information when not accepting, promptly be defaulted as and do not accept, also can be to begin to carry in the response message attribute field of whether supporting that the IP multicast sends, represent to accept the transmission of IP multicast when getting different values respectively and do not accept in session.But the present invention does not do qualification to concrete advice method.

Step 706: each SGSN begins response message notifying MBMS-GW by session and whether accepts the transmission of IP multicast;

To certain SGSN, if accepting the IP multicast, all downstream nodes send, this SGSN begins response message notifying MBMS-GW by session and accepts the transmission of IP multicast, carries the IP multicast address and source address and the public TEID-U that are accepted in the message; If not accepting the IP multicast, all downstream nodes do not send, this SGSN begins response message notifying MBMS-GW by session and does not accept the transmission of IP multicast, carry the TEID-U that is used for point-to-point GTP tunnel transmission user face data in the message, return to the mode that point-to-point GTP tunnel sends user face data between SGSN and the MBMS-GW; Do not accept the transmission of IP multicast as there being part to accept part in the node of downstream, this SGSN can begin response message notifying MBMS-GW by session and accept the transmission of IP multicast, be provided for the TEID-U that GTP tunnel sends user face data simultaneously, serve the downstream node of not supporting the transmission of IP multicast for another part.

When the SGSN indication had part or all of downstream node to accept the transmission of IP multicast, MBMS-GW should initiate the IP multicast and send.

Step 706a:MBMS-GW receives that the session that any SGSN/MME returns begins to ask response, when creating MBMS bearer context (MBMS bearer context), sends beginning charging request message ACR[Start] to charging data function;

Return to point-to-point GTP tunnel transmission user face data between SGSN and the MBMS-GW if having, should comprise the downstream node tabulation in the beginning charging request message, comprise in the tabulation and do not accept the downstream node that the IP multicast sends; If when having SGSN and/or MME to accept the transmission of IP multicast, comprise IP multicast address and source address and the public TEID-U that SGSN and/or MME accept in the beginning charging message; This begins also to comprise in the charging request message information of MBMS compact token.

CDF comprises information such as record type (Record Type), the MBMS-GW address (MBMS-GW Address used) of using, MBMS session identification, data traffic tabulation (List of Traffic Data Volumes) (only adding up down direction) and time among the ticket MBMS-GW-CDR that opens of MBMS-GW.Following one or more information that comprise in the beginning charging request message are also added among the MBMS-GW-CDR: the downstream node tabulation is used for IP multicast address and source address and public TEID-U that the IP multicast sends, MBMS compact token.

The downstream node tabulation of point-to-point GTP tunnel transmission user face data is used for point-to-point GTP tunnel is sent the charging of user face data, and IP multicast address that the IP multicast sends and source address and public TEID-U (explanation has the transmission of employing IP multicast) are used for the IP multicast is sent the charging of user face data.When subsequent charging, the send mode that just can distinguish the MBMS user face data has chargeed respectively like this.MBMS compact token makes can distinguish when chargeing whether to have carried out the head compression and adopted different charging ways, the use of this parameter be optional.

Step 707: wireless side is set up necessary Radio Resource for the MBMS data send.

In addition, support the IP multicast to send if SGSN begins response message notifying MBMS-GW by session, this SGSN can not produce charge information; If SGSN and MBMS-GW set up GTP tunnel and send user face data, this SGSN sends begins to comprise the downstream node tabulation in the request of chargeing, comprise in this downstream node tabulation and do not accept the downstream node that the IP multicast sends, also comprise described downstream node tabulation in the ticket of charging data function for this SGSN generation.

Flow process when the eMBMS conversation end is as shown in Figure 8:

Step 801:BM-SC sends MBMS conversation end request message to MBMS-GW, and MBMS-GW replys the conversation end request and responds to BM-SC;

Step 801a: after BM-SC receives the conversation end request response that any one MBMS-GW sends, send and finish beginning charging request message ACR[Stop] give charging data function (CDF);

CDF closes the ticket C-BMSC-CDR that has opened for this BM-SC, in the ticket except fields such as the tabulation of time, data traffic (only adding up down direction), content supplier's identifier, MBMS session identification, downstream node tabulations, also can comprise information such as MBMS head compression sign, CDF returns charge response message and gives BM-SC.

MBMS conversation end request process in the subsequent step can begin the parallel appearance of charging request message process with the end of step 801a,

Step 802:MBMS-GW sends MBMS conversation end message to SGSN and/or MME;

Step 802a:MBMS-GW receives the conversation end request responding that any SGSN or MME return, and when the MBMS bearer context stops (perhaps any unusual release), sends and finishes beginning charging request message ACR[Stop] to charging data function;

Corresponding with the information that the beginning charging request message comprises, comprise the downstream node tabulation in this end beginning charging request message, and/or, information such as IP multicast address and source address and public TEID-U.Can also comprise head compression sign.

CDF closes the ticket MBMS-GW-CDR that has opened for MBMS-GW, will comprise MBMS-GW address, MBMS session identification, data traffic tabulation (only adding up down direction) and the temporal information etc. of record type, use in this ticket.Also comprise in the following information one or more: the downstream node tabulation is used for IP multicast address and source address and public TEID-U that the IP multicast sends, MBMS head compression sign.

After step 804:MBMS data sent and finish, Radio Resource discharged.

Embodiment two:

Present embodiment is based on the MBMS framework, suppose in the MBMS business of 2G/3G, present embodiment supposition BM-SC capability improving supports the IP multicast to send and the head compression, MBMS broadcasting sends to GGSN from BM-SC, and the wireless side technology is UTRAN, promptly send to UTRAN, send to the UE in the service area again via SGSN.

Present embodiment MBMS session beginning request process is as shown in Figure 9:

Step 901:BM-SC sends MBMS session beginning request message to GGSN;

The MBMS session begins to comprise in the request message QoS, MBMS service area tabulation, and session identification is estimated session persistence, purpose network identity, IP multicast send information such as sign and MBMS head compression sign.In the present embodiment, the IP multicast that the respective nodes of supporting transmission of IP multicast and head to compress after the capability improving begins to carry in the request message in session sends and indicates that (IP Multiple delivery Indicator) and MBMS head compression sign express support for transmission of IP multicast and the compression of MBMS head.Do not support the respective nodes that the IP multicast sends and head compresses not send this sign, be defaulted as and do not support, do not get rid of yet and send a unsupported sign of expression, perhaps send a sign and get different values and express support for respectively and unsupported situation, here concrete definition mode is not limited.

Step 902: each GGSN replys session respectively and begins the request response to BM-SC;

Step 902a:BM-SC sends beginning charging request message ACR[Start after receiving that from any one GGSN first session begins the request response] to CDF;

Among the ticket C-BMSC-CDR that CDF opens for this BM-SC except time, data traffic tabulation (only adding up down direction), content supplier's identifier and information such as MBMS session identification, downstream node tabulation.In the present embodiment, ticket C-BMSC-CDR comprises that also the IP multicast sends sign and MBMS head compression sign, is used to represent whether BM-SC supports the IP multicast to send and the compression of MBMS head.CDF returns charge response message and gives BM-SC.

Follow-up MBMS session begins the request message process and can occur with the beginning charging request message process of step 902a is parallel,

Step 903: support GGSN distributing IP multicast address and source address and public TEID-U that the IP multicast sends, session is begun request message send to the SGSN that enumerates in the downstream node list parameter;

This session begins request message and comprises session parameter: Temporary Mobile Group Identity, and traffic identifier, QoS, the MBMS service area, session identification is estimated session persistence, information such as broadcast/group broadcast and MBMS data transmitting time.When GGSN supports that the IP multicast sends, also comprise the IP multicast address and source address and the public TEID-U that are used for the backbone network distribution that GGSN distributes.When GGSN supports the compression of MBMS head, also comprise the MBMS head compression sign that expresses support for the compression of MBMS head, as only be defined as when supporting the compression of MBMS head, the MBMS head just occurs and compress and indicate.

Step 904: each SGSN sends the MBMS session to the UTRAN that is connected to this SGSN and begins request message;

The MBMS session in this step begins request message and comprises session parameter: Temporary Mobile Group Identity, and QoS, the MBMS service area, session identification is estimated session persistence, information such as broadcast/group broadcast and MBMS data transmitting time.Message is when sending to UTRAN by the Iu pattern, begins the IP multicast address and source address and the public TEID-U that comprise in the request message that GGSN distributes in this session.When SGSN supports the compression of MBMS head, also comprise the MBMS head compression sign that expresses support for the compression of MBMS head, as only may be defined as when supporting the compression of MBMS head, the MBMS head just occurs and compress and indicate.

Step 905: each UTRAN begins response message notice SGSN by session and whether accepts the transmission of IP multicast;

GGSN distributes in the beginning request message if UTRAN accepts session IP multicast address and source address and public TEID-U, then notify SGSN to accept the IP multicast and send, as begin in the session that sends to SGSN the response message can with on accept the indication that the IP multicast sends; If the session that UTRAN receives begins not comprise in the request message IP multicast address and source address and public TEID-U, perhaps UTRAN IP multicast address and the source address of beginning in the request message that do not accept session, or do not accept public TEID-U, then notify SGSN not accept the IP multicast, do not have the indication of supporting that the IP multicast sends in the response message as beginning in the session that sends to SGSN, be defaulted as and do not support the IP multicast to send, also can be to begin to carry in the response message attribute field of whether supporting that the IP multicast sends, represent to accept the transmission of IP multicast when getting different values respectively and do not accept in session.But the present invention does not do qualification to concrete advice method.

Step 906: each SGSN begins response message notice GGSN by session and whether accepts the transmission of IP multicast;

To certain SGSN, if accepting the IP multicast, all downstream nodes send, this SGSN begins response message notice GGSN by session and accepts the transmission of IP multicast, as begin in session the response message with on accept the indication that the IP multicast sends, and carry IP multicast address and source address and the public TEID-U that is accepted.If not accepting the IP multicast, all downstream nodes do not send, SGSN begins response message notice GGSN by session and does not accept the transmission of IP multicast, begin to be provided for the TEID-U that point-to-point GTP tunnel sends user face data in the response message in session, return to point-to-point GTP tunnel between SGSN and GGSN and send the user face data mode.Do not accept the transmission of IP multicast as there being part to accept part in the node of downstream, this SGSN can begin response message notice GGSN by session and accept the transmission of IP multicast, the TEID-U that provides point-to-point GTP tunnel to send user face data simultaneously serves the downstream node that another part does not support that the IP multicast sends.

As long as when having downstream node a: SGSN to accept the transmission of IP multicast, GGSN should initiate the IP multicast and send.

Step 906a:GGSN receives that the session that arbitrary SGSN sends begins to ask response, when creating the MBMS bearer context, sends beginning charging request message ACR[Start] to CDF;

Except that charge informations such as record type, if have and return to point-to-point GTP tunnel transmission user face data mode between SGSN and the MBMS-GW, beginning should comprise the downstream node tabulation in the charging request message, comprises the downstream node not accepting the IP multicast and send (address and TEID-U) in this downstream node tabulation; If when having SGSN to accept the transmission of IP multicast, comprise IP multicast address and source address and the public TEID-U that SGSN accepts in the beginning charging message; As the GGSN capability improving, also can comprise expression GGSN in the beginning charging request message and support MBMS compact token of MBMS head compression and/or represent that the IP multicast that GGSN supports the IP multicast to send sends sign.

CDF is the information such as GGSN address, MBMS session identification, data traffic tabulation (only adding up down direction) and time that will comprise record type, use among the ticket G-MB-CDR that opens of GGSN.Following one or more information that comprise in the beginning charging request message are also added G-MB-CDR to: the downstream node tabulation is used for IP multicast address and source address and public TEID-U that the IP multicast sends.In addition, G-MB-CDR can also comprise and represent whether GGSN supports MBMS compact token of MBMS head compression and/or represent that the IP multicast transmission whether GGSN supports the IP multicast to send indicates.

Similarly, the downstream node tabulation that point-to-point GTP tunnel sends user face data is used for not supporting that the IP multicast sends the charging of user face data, and IP multicast address that the IP multicast sends and source address and public TEID-U are used to support that the IP multicast sends the charging of user face data.Like this when subsequent charging, just can distinguish MBMS user face data send mode and chargeed respectively.MBMS compact token makes can distinguish whether carried out a compression and adopted different charging ways, be optional when chargeing.

Step 907:UTRAN sets up necessary Radio Resource for the MBMS data send.

In addition, support the IP multicast to send if SGSN begins response message notice GGSN by session, this SGSN can not produce charge information; If SGSN and GGSN set up GTP tunnel and send user face data, this SGSN sends begins to comprise the downstream node tabulation in the request of chargeing, comprise the downstream node of not supporting that the IP multicast sends in this downstream node tabulation, also comprise described downstream node tabulation in the ticket of charging data function for this SGSN generation.

MBMS conversation end request flow process is as shown in figure 10:

Step 1001:BM-SC sends MBMS conversation end request message to each GGSN, and each GGSN replys the conversation end request and responds to BM-SC;

Step 1001a: BM-SC receives conversation end request response from any one GGSN after, send and finish beginning charging request message ACR[Stop] to CDF.CDF closes the ticket C-BMSC-CDR that has opened, in the ticket except fields such as the tabulation of time, data traffic (only adding up down direction), content supplier's identifier, MBMS session identification, address list List of Downstream Nodes information, in the present embodiment, also comprise head compression sign and IP multicast and send sign; CDF returns charge response message and gives BM-SC.

Follow-up MBMS conversation end request process can begin the parallel appearance of charging request message process with the end of step 1001a.

Step 1002: each GGSN sends MBMS conversation end message to SGSN;

Step 1002a:GGSN receives the conversation end request responding that arbitrary SGSN returns, and when the MBMS bearer context stops (perhaps any unusual release), sends and finishes beginning charging request message ACR[Stop] to CDF;

Corresponding with the information that the beginning charging request message comprises, comprise the downstream node tabulation in this end beginning charging request message, and/or information such as IP multicast address and source address and public TEID-U.Can also comprise expression GGSN supports the MBMS head compression sign and the IP multicast of compression of MBMS head and the transmission of IP multicast to send sign.

CDF closes the ticket G-MB-CDR that has opened for GGSN, will comprise MBMS-GW address, MBMS session identification, data traffic tabulation (only adding up down direction) and the temporal information etc. of record type, use in this ticket.Also comprise in the following information one or more: the downstream node tabulation, be used for IP multicast address and source address and public TEID-U that the IP multicast sends, MBMS head compression sign, the IP multicast sends sign.

After step 1004:MBMS data sent and finish, Radio Resource discharged.

In case exist in the MBMS broadcast transmission process because MBMS session updates (session update) process that the variation of service area etc. cause, charge and also can correspondingly produce Intermediate Charging ICH message ACR[interim] and partial CDR (Partial CDR), the IP multicast that also can comprise in these Intermediate Charging ICH message and the partial CDR in the similar above process sends relevant information, repeats no more.

Consider that 2G/3G BM-SC in period can upgrade and support the IP multicast to send, also can not support and rollback (fall back) to GTP-U tunnel protocol mode, equally, in the eMBMS framework, compatible 2G/3G network uses (legacy) UTRAN access MBMS-GW that inherits also to have above-mentioned support and do not support the IP multicast to send two kinds of possibilities.Proposition of the present invention is used to solve the differentiation charging problem under the above-mentioned complicated networking scene.Pass through the above embodiment of the present invention, MBMS load side off-line accounting method to content supplier is provided under the broadcast mode of MBMS, make that common carrier can be in the MBMS business, content supplier is carried out basis whether support the different rate of IP multicast transmission MBMS user face data setting to charge, thereby help common carrier and content supplier that developing MBMS service is carried out the expense sorting.

The above is the preferred embodiments of the present invention only, is not limited to the present invention, and for a person skilled in the art, the present invention can have various changes and variation.Within the spirit and principles in the present invention all, any modification of being done, be equal to replacement, improvement etc., all should be included within protection scope of the present invention.

Claims

1. the method for a distinguishing MBMS (Multimedia Broadcast Multicast Service) user surface data sending modes during charging, be applied to the MBMS network architecture, have at least a broadcast multicast service center (BM-SC) and a Gateway GPRS Support Node (GGSN) to support the IP multicast to send after capacity upgrade in this MBMS network architecture, this method comprises:

2. the method for claim 1 is characterized in that;

3. method as claimed in claim 1 or 2 is characterized in that;

4. method as claimed in claim 1 or 2 is characterized in that;

Described SGSN begins response by session and notifies described GGSN to accept the transmission of IP multicast when having UTRAN to accept the transmission of IP multicast; When having UTRAN not accept the transmission of IP multicast, beginning response by session provides TEID-U, and sets up GTP tunnel transmission user face data between the GGSN;

5. the method for a distinguishing MBMS (Multimedia Broadcast Multicast Service) user surface data sending modes during charging is applied to the MBMS network architecture of evolution, and this method comprises:

6. method as claimed in claim 5 is characterized in that;

7. as claim 5 or 6 described methods, it is characterized in that;

Described SGSN begins response by session and notifies described MBMS-GW to accept the transmission of IP multicast when having UTRAN to accept the transmission of IP multicast; When having downstream node not accept the IP multicast to send, described SGSN in session begins to respond, provide TEID-U and and GGSN between return back to the mode that point-to-point GTP tunnel sends user face data;

8. method as claimed in claim 7 is characterized in that;

9. the system of a distinguishing MBMS (Multimedia Broadcast Multicast Service) user surface data sending modes during charging adopts the MBMS network architecture, and broadcast multicast service center (BM-SC), Gateway GPRS Support Node (GGSN) and charging data function is characterized in that:

10. system as claimed in claim 9 is characterized in that;

11., it is characterized in that as claim 9 or 10 described systems;

12. the system of a distinguishing MBMS (Multimedia Broadcast Multicast Service) user surface data sending modes during charging, the MBMS network architecture of employing evolution, broadcast multicast service center (BM-SC), MBMS gateway (MBMS-GW) and charging data function is characterized in that:

13. system as claimed in claim 12 is characterized in that;