CN101925009B

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

Info

Publication number: CN101925009B
Application number: CN200910203679.3A
Authority: CN
Inventors: 郭文洁
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2009-06-15
Filing date: 2009-06-15
Publication date: 2015-03-25
Anticipated expiration: 2029-06-15
Also published as: CN101925009A

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, specifically, relate to the method and system of a kind of multimedia broadcast-multicast service (Multimedia Broadcast/Multicast Service, referred to as MBMS) 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 refer in existing cordless communication network, utilize multicast (Multicast) or broadcast (Broadcast) technology to set up the passage of business datum, thus complete the business model from a point-to-multipoint distribution.For the cordless communication network of 3GPP definition, the wireless access technology relevant with MBMS, eMBMS of its definition, up to the present, comprise universal land radio access web (the Universal TerrestrialRadio Access Network in GERAN, 3G period in 2G period, referred to as UTRAN) and the universal land radio access web (evolved Universal Terrestrial Radio Access Network, referred to as E-UTRAN) of evolution.

In MBMS, the network architecture of the multimedia broadcast-multicast service pattern of 3GPP definition as shown in Figure 1.Wherein broadcast multicast service center (Broadcast Multicast-Service Centre, referred to as BM-SC) be the cradle of business datum, GGSN (Gateway GPRS Support Node) is 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 then user face data issues via GGSN to business GRPS support node SGSN (Serving GPRS Support Node).For the wireless access technology UTRAN of 3G, if the IP multicast sender formula in user face is supported in BM-SC upgrading, then user face data can use IP multicast to send from GGSN bypass SGSN; Otherwise, if IP multicast sends and is not supported, will rollback (fall back) to point-to-point GTP-U (the User planeof GPRS Tunneling Protocol setting up GGSN and SGSN, GPRS Tunneling Protocol-User plane) tunnel style, be issued to corresponding descendant node again via SGSN.

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

The situation (MBMS improvement) that during consideration 2G/3G, MBMS strengthens, if BM-SC upgrading supports that IP multicast sends (IP Multicast Delivery) and MBMS head compression technology (MBMS-HC), these relevant information can be passed through related signaling (message such as MBMS session start, MBMS session stop) and be issued to GGSN.Information in these signalings can configure in BM-SC (or its network management system), GGSN also can configure and whether support that IP multicast sends (IPMulticast Delivery).BM-SC/GGSN, when sending conversation message, obtains these information, the parameter of composition 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 from BM-SC to other network nodes.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.MME and SGSN can be corresponded to according to the descendant node type that wireless side access technology is E-UTRAN or UTRAN, MBMS-GW.It is adopt IP's multicast sender formula (IP Multicastdelivery) that MBMS user face data sends.

But can not get rid of and not support that when networking (legacy) network architecture of the succession of IP multicast sender formula receives the situation of MBMS-GW, that is: the network of 2G/3G receives the situation of MBMS-GW by SGSN.At this moment, between SGSN and MBMS-GW also can rollback (fall back) to the point-to-point GTP-U tunnel 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, once consider complicated networking situation, support that the situation that IP multicast sends and the situation (return back to and set up point-to-point GTP-U tunnel, send user data via SGSN) not supporting IP multicast to send all likely exist.And current MBMS charging only considered charging when not supporting that IP multicast sends, in not considering to support that the situation of IP multicast transmission and a MBMS broadcast, support IP multicast to send and do not support that IP multicast sends the differentiation charging under two kinds of possibility Coexistence Situation, and both rates etc. may be different.

About the definition of session start and conversation end signaling, see Fig. 3 and Fig. 4.

All for the MBMS in 2G/3G period in Fig. 3 and Fig. 4, descriptive session starts the sending method of request message and conversation end request message.The transmission of the session start under eMBMS framework and conversation end request message and the process of Fig. 3 and Fig. 4 similar, as shown in Figure 5 and Figure 6, concrete steps repeat no more.

As shown in Figure 3, be MBMS session start request message (referred to as the session start request) flow process in existing 2G/3G period, comprise the steps:

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

Described MBMS session start request message can carry conversation class parameter: service quality (Qualityof Service, referred to as QoS), MBMS zone list (list of MBMS service Area), MBMS session identification (MBMS Session identifier), estimate the information such as session persistence (estimatedsession duration) and object network identity (MBMS xG indicator), and address class parameter: downstream node list (List of Downstream Nodes) etc., the address that downstream node list comprises downstream node and tunnel endpoint identifier (the TunnelEndpoint Identifier Data sent for user face data, be abbreviated as TEID, that is: TEID-U).

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

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

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

Step 305, wireless side returns the response message of session start request;

Step 306, when SGSN receives all after the response message of session start request from wireless side, sends to GGSN by session start response message (referred to as session start response);

Step 307, reserves Radio Resource and sets up down going channel, transmission data.

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

Step 401, BM-SC sends MBMS conversation end request message (referred to as conversation end request) to GGSN; Session identification and the information such as service identification and downstream node list is carried in message.GGSN replys conversation end response message to BM-SC, and discharges the information about this business of oneself preserving;

Step 402, GGSN transmitting MBMS conversation end request message gives the SGSN receiving session start request message before this, and SGSN returns response message, and discharges the information about this business of oneself preserving;

Step 403, this information is transmitted to wireless side by SGSN, and wireless side returns conversation end response message;

Step 404, wireless side resource discharges.

Prior art Problems existing is:

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

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

Summary of the invention

The technical problem to be solved in the present invention is to provide 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 charging.

In order to solve the 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) after capacity upgrade, support that IP multicast sends in this MBMS network architecture, the method comprises:

Supporting in the session start request process that the BM-SC that IP multicast sends initiates, support the GGSN distributing IP multicast address that IP multicast sends and source address and common user plane tunnel endpoint identifier (TEID-U) and be sent to downstream node, after described downstream node receives, notifying whether described GGSN accepts IP multicast and send;

Accept IP multicast if any downstream node to send, described GGSN is starting to carry in accounting request the IP multicast address and source address and public TEID-U that described downstream contact accepts, and charging data function records described IP multicast address and source address and public TEID-U in the charging data record (CDR) opened for described GGSN;

Do not accept IP multicast if any downstream node to send, described GGSN carries the downstream node list comprising these downstream nodes in beginning accounting request, and charging data function records described downstream node list in the CDR opened for described GGSN.

Further, said method also can have following characteristics:

BM-SC and/or GGSN carries the IP multicast transmission mark whether an expression supports IP multicast to send in the beginning accounting request sent to charging data function; Or BM-SC and/or GGSN, only when supporting IP multicast to send, just carrying an IP multicast and sending mark in the beginning accounting request sent to charging data function;

Charging data function arranges an IP multicast and sends mark in the CDR opened for BM-SC and/or GGSN, and the value that this IP multicast sends mark represents whether support that IP multicast sends.

Further, said method also can have following characteristics:

BM-SC and/or GGSN carries the MBMS head compression mark whether an expression supports MBMS head to compress in the beginning accounting request sent to charging data function; Or BM-SC and/or GGSN, only when supporting the compression of MBMS head, just carries a MBMS head compression mark in the beginning accounting request sent to charging data function;

Charging data function arranges a MBMS head compression mark in the CDR opened for BM-SC and/or GGSN, and the value of this MBMS head compression mark represents whether support that MBMS head compresses.

Further, said method also can have following characteristics:

The IP multicast address distributed and source address and public user face tunnel endpoint identifier (TEID-U) are sent to the SGSN in downstream by described GGSN by session start request;

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

After described UTRAN receives session start request, as IP multicast address as described in accepting and source address and public TEID-U, notify that described SGSN accepts IP multicast and sends by session start response, otherwise, notify that described SGSN does not accept IP multicast and sends by session start response;

By session start response message, described SGSN, when there being UTRAN to accept the transmission of IP multicast, notifies that described GGSN accepts IP multicast and sends; When there being UTRAN not accept the transmission of IP multicast, provide TEID-U by session start response message, and between GGSN, set up GTP tunnel transmission user face data;

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

In order to solve the problems of the technologies described above, present invention also offers 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 of evolution, the method comprises:

In the session start request process that BM-SC initiates, MBMS gateway (MBMS-GW) distributing IP multicast address and source address and public user face tunnel endpoint identifier (TEID-U) are also sent to downstream node, and described downstream node notifies whether described MBMS-GW accepts IP multicast and send;

Accept IP multicast if any downstream node to send, described MBMS-GW is starting to carry in accounting request the IP multicast address and source address and public TEID-U that described downstream contact accepts, and charging data function records described IP multicast address and source address and public TEID-U in the charging data record (CDR) opened for described MBMS-GW;

Do not accept IP multicast if any downstream node to send, described MBMS-GW carries the downstream node list comprising these downstream nodes in beginning accounting request, and charging data function records described downstream node list in the CDR opened for described MBMS-GW.

Further, said method also can have following characteristics:

BM-SC and/or MBMS-GW carries the MBMS head compression mark whether an expression supports MBMS head to compress in the beginning accounting request sent to charging data function; Or BM-SC and/or MBMS-GW, only when supporting the compression of MBMS head, just carries a MBMS head compression mark in the beginning accounting request sent to charging data function;

Charging data function arranges a MBMS head compression mark in the CDR opened for BM-SC and/or MBMS-GW, and the value of this MBMS head compression mark represents whether support that MBMS head compresses.

Further, said method also can have following characteristics:

Described downstream node comprises SGSN, and the IP multicast address of distribution and source address and public TEID-U are sent to the SGSN in downstream by described MBMS-GW by session start request;

By session start response message, described SGSN, when there being UTRAN to accept the transmission of IP multicast, notifies that described MBMS-GW accepts IP multicast and sends; Have downstream node do not accept IP multicast send time, described SGSN TEID-U is provided in session start response message and and return back to point-to-point GTP tunnel between GGSN and send the mode of user face data;

Described MBMS-GW, when there being SGSN to accept the transmission of IP multicast, initiating IP multicast and sends.

Further, said method also can have following characteristics:

If SGSN and MBMS-GW sets up GTP tunnel and sends user face data, downstream node list is comprised in the beginning accounting request that this SGSN sends, comprise the address not supporting the downstream node that IP multicast sends and TEID-U in this downstream node list, charging data function is also comprise described downstream node list in the CDR of 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 an a BM-SC and GGSN after capacity upgrade, support that IP multicast sends;

The GGSN supporting IP multicast to send is used for after receiving the session start request that the BM-SC that supports IP multicast to send sends, and distributing IP multicast address and source address and public user face tunnel endpoint identifier (TEID-U), be sent to downstream node; Accept IP multicast if any downstream node to send, starting to carry in accounting request the IP multicast address and source address and public TEID-U that described downstream contact accepts, do not accept IP multicast if any downstream node to send, in beginning accounting request, carry corresponding downstream node list;

Described charging data function is used for the described downstream node list will comprised in described beginning accounting request, or the described IP multicast address comprised and source address and public TEID-U, or the described downstream node list comprised, described IP multicast address and source address and public TEID-U are recorded in the charging data record (CDR) for described GGSN opens.

Further, said system also can have following characteristics:

Described BM-SC and/or GGSN carries the IP multicast transmission mark whether an expression supports IP multicast to send in the beginning accounting request sent to charging data function; Or described BM-SC and/or GGSN, only when supporting IP multicast to send, just carrying an IP multicast and sending mark in the beginning accounting request sent to charging data function;

Described charging data function arranges an IP multicast and sends mark in the CDR opened for BM-SC and/or GGSN, and the value that this IP multicast sends mark represents whether support that IP multicast sends.

Further, said system also can have following characteristics:

Described BM-SC and/or GGSN carries the MBMS head compression mark whether an expression supports MBMS head to compress in the beginning accounting request sent to charging data function; Or described BM-SC and/or GGSN, only when supporting the compression of MBMS head, just carries a MBMS head compression mark in the beginning accounting request sent to charging data function;

Described charging data function arranges a MBMS head compression mark in the CDR opened for BM-SC and/or GGSN, and the value of this MBMS head compression mark represents whether support that MBMS head compresses.

Correspondingly, present invention also offers a kind of system of distinguishing MBMS (Multimedia Broadcast Multicast Service) user surface data sending modes during charging, adopt 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 the session start request that BM-SC sends, and distributing IP multicast address and source address and public user face tunnel endpoint identifier (TEID-U) are also sent to downstream node; Accept IP multicast if any downstream node to send, starting to carry in accounting request the IP multicast address and source address and public TEID-U that described downstream contact accepts, do not accept IP multicast if any downstream node to send, in beginning accounting request, carry corresponding downstream node list;

Described charging data function is used for the described downstream node list will comprised in described beginning accounting request, or the described IP multicast address comprised and source address and public TEID-U, or the described downstream node list comprised, described IP multicast address and source address and public TEID-U are recorded in the charging data record (CDR) for described MBMS-GW opens.

Further, said system also can have following characteristics:

Described BM-SC and/or MBMS-GW carries the MBMS head compression mark whether an expression supports MBMS head to compress in the beginning accounting request sent to charging data function; Or described BM-SC and/or MBMS-GW, only when supporting the compression of MBMS head, just carries a MBMS head compression mark in the beginning accounting request sent to charging data function;

Described charging data function arranges a MBMS head compression mark in the CDR opened for BM-SC and/or MBMS-GW, and the value of this MBMS head compression mark represents whether support that MBMS head compresses.

Such scheme only considered the situation not supporting that IP multicast sends when overcoming current MBMS charging, in the situation not considering to support that IP multicast sends and a MBMS broadcast, supporting IP multicast to send and do not support that IP multicast sends two kinds may the problem of differentiation charging under Coexistence Situation; And during eMBMS charging, only considered the situation supporting that IP multicast sends, do not consider the problem of differentiation charging when the two kinds of situations supported and do not support IP multicast to send coexist.Achieve the concrete condition whether supporting IP multicast to send according to network node and carry out differentiation charging.

Accompanying drawing explanation

Accompanying drawing described herein is used to provide a further understanding of the present invention, and form a application's part, schematic description and description of the present invention, for explaining the present invention, does not form inappropriate limitation 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 start request process flow chart when Fig. 3 is 2G/3G;

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

Fig. 5 is eMBMS session start request process flow chart;

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

Fig. 7 is the flow chart comprising charging message that the eMBMS session start request process of the embodiment of the present invention exists that IP multicast sends relevant information;

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

There is the flow chart comprising charging message that IP multicast sends relevant information in MBMS session start request process when Fig. 9 is the 2G/3G of the embodiment of the present invention;

There is the flow chart comprising charging message that IP multicast sends relevant information in MBMS conversation end request process when Figure 10 is the 2G/3G of the embodiment of the present invention.

Embodiment

The MBMS scene supporting IP multicast to send period with regard to offline charging and the 2G/3G of the MBMS broadcast that uses IP multicast to send under eMBMS framework respectively below illustrates and sends to the MBMS user face data of content supplier the off-line accounting method recording whether IP multicast transmission under the broadcast mode of MBMS.

Embodiment one:

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

Because do not get rid of the network element that UTRAN is (legacy) inherited, do not accept IP multicast to send, now, the charging message that sends of MBMS-GW and CDF also will comprise the downstream node list information etc. sending user face data for point-to-point GTP-U tunnel in the MBMMS-GW-CDR that produces of MBMS-GW.

EMBMS session start request process is as shown in Figure 7:

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

This MBMS session start request disappears and carries QoS, MBMS zone list, the information such as MBMS session identification, expectation session persistence, object network identity and MBMS head compression mark (MBMS HCIndicator).In the present embodiment, MBMS head compression mark is for representing that whether retrieving head compresses respective nodes (being BM-SC), can be to support or do not support here.

Step 702:MBMS-GW replys session start request respectively and responds to BM-SC;

Step 702a:BM-SC sends and starts charging request message ACR [Start] to charging data function (CDF) after receiving first session start request response that any one MBMS-GW sends;

CDF is except time, data traffic list (only adding up down direction), content provider identification symbol, MBMS session identification, downstream node list information etc. in the ticket C-BMSC-CDR that opens of this BM-SC, can also comprise the information such as MBMS head compression mark, CDF returns charge response message to BM-SC.

MBMS session start request message process in subsequent step can occur with the beginning charging request message concurrent process of step 702a.

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

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

Because MME downstream node should support that IP multicast sends, below flow process only SGSN and downstream node thereof are described.

Step 704: each SGSN sends MBMS session start request message to the UTRAN being connected to this node;

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

Step 705: whether each UTRAN accepts IP multicast by session start response message notice SGSN sends;

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

Step 706: whether each SGSN accepts IP multicast by session start response message notifying MBMS-GW sends;

To certain SGSN, send if all downstream nodes accept IP multicast, this SGSN accepts IP multicast by session start response message notifying MBMS-GW and sends, and carries accepted IP multicast address and source address and public TEID-U in message; Send if all downstream nodes do not accept IP multicast, this SGSN does not accept IP multicast by session start response message notifying MBMS-GW and sends, carry the TEID-U sending user face data for point-to-point GTP tunnel in message, between SGSN and MBMS-GW, return to the mode that point-to-point GTP tunnel sends user face data; Do not accept IP multicast as there being part receiving portion in downstream node to send, this SGSN can accept IP multicast by session start response message notifying MBMS-GW and send, be provided for the TEID-U that GTP tunnel sends user face data simultaneously, serve as another part does not support the downstream node that IP multicast sends.

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

Step 706a:MBMS-GW receives the session start request response that any one SGSN/MME returns, when creating MBMS bearer context (MBMS bearer context), sending and starting charging request message ACR [Start] to charging data function;

If have between SGSN and MBMS-GW and return to point-to-point GTP tunnel transmission user face data, start should comprise downstream node list in charging request message, in list, comprise the downstream node not accepting IP multicast and send; If there be SGSN and/or MME to accept IP multicast when sending, start to comprise in charging message IP multicast address and source address and public TEID-U that SGSN and/or MME accept; This starts the information also comprising MBMS head compact token in charging request message.

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

The downstream node list that point-to-point GTP tunnel sends user face data is used for sending point-to-point GTP tunnel the charging of user face data, and the IP multicast address that IP multicast sends and source address and public TEID-U (explanation have adopt IP multicast to send) are for sending the charging of user face data to IP multicast.Like this when subsequent charging, just can distinguish the send mode difference charging of MBMS user face data.Whether MBMS head compact token makes can distinguish when charging has carried out head compression and has adopted different charging ways, and the use of this parameter is optional.

Step 707: wireless side is that necessary Radio Resource is set up in MBMS data transmission.

In addition, if by session start response message notifying MBMS-GW, SGSN supports that IP multicast sends, this SGSN can not produce charge information; If SGSN and MBMS-GW sets up GTP tunnel and sends user face data, downstream node list is comprised in the beginning accounting request that this SGSN sends, comprise the downstream node not accepting IP multicast and send in this downstream node list, charging data function is also comprise described downstream node list in the ticket of this SGSN generation.

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

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

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

It is ticket C-BMSC-CDR that this BM-SC opens that CDF closes, except fields such as time, data traffic list (only adding up down direction), content provider identification symbol, MBMS session identification, downstream node lists in ticket, also can comprise the information such as MBMS head compression mark, CDF returns charge response message to BM-SC.

MBMS conversation end request process in subsequent step can start charging request message concurrent process with the end of step 801a and occur,

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

Step 802a:MBMS-GW receives the response of the conversation end request that any one SGSN or MME returns, when MBMS bearer context stops (or any abnormal release), send and terminate to start charging request message ACR [Stop] to charging data function;

Corresponding with the information that beginning charging request message comprises, this terminates to start to comprise downstream node list in charging request message, and/or, IP multicast address and the information such as source address and public TEID-U.Head compression mark can also be comprised.

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

After step 804:MBMS data send and terminate, Release radio resource.

Embodiment two:

The present embodiment is based on MBMS framework, suppose in the MBMS of 2G/3G, the present embodiment supposition BM-SC capability improving supports IP multicast to send and head compression, MBMS broadcast is sent to GGSN from BM-SC, and wireless side technology is UTRAN, namely be sent to UTRAN via SGSN, then send to the UE in service area.

The present embodiment MBMS session start request process is as shown in Figure 9:

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

Comprise QoS in MBMS session start request message, MBMS zone list, session identification, estimate that session persistence, object network identity, IP multicast send the information such as mark and MBMS head compression mark.In the present embodiment, after capability improving, support that IP multicast transmission mark (IP Multiple delivery Indicator) that the respective nodes of the transmission of IP multicast and head compression is carried in session start request message and MBMS head compression mark express support for the transmission of IP multicast and the compression of MBMS head.Do not support that the respective nodes that IP multicast sends and head compresses can not send this mark, be defaulted as and do not support, do not get rid of transmission one and represent the mark do not supported, or send mark and get the situation that different values expresses support for respectively and do not support, here concrete definition mode is not construed as limiting yet.

Step 902: each GGSN replys session start request respectively and responds to BM-SC;

Step 902a:BM-SC sends and starts charging request message ACR [Start] to CDF after receiving first session start request response from any one GGSN;

CDF is except time, data traffic list (only adding up down direction), content provider identification symbol and the information such as MBMS session identification, downstream node list in the ticket C-BMSC-CDR that opens of this BM-SC.In the present embodiment, ticket C-BMSC-CDR also comprises IP multicast and sends mark and MBMS head compression mark, for representing whether BM-SC supports IP multicast to send and the compression of MBMS head.CDF returns charge response message to BM-SC.

Follow-up MBMS session start request message process can occur with the beginning charging request message concurrent process of step 902a,

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

This session start request message comprises session parameter: Temporary Mobile Group Identity, traffic identifier, QoS, MBMS region, session identification, estimates session persistence, the information such as broadcast/group broadcast and MBMS data transmitting time.When GGSN supports that IP multicast sends, also comprise the IP multicast address for backbone network distribution and source address and public TEID-U that GGSN distributes.When GGSN supports that MBMS head compresses, also comprising the MBMS head compression mark expressing support for the compression of MBMS head, as being defined as only when supporting MBMS head to compress, just occurring MBMS head compression mark.

Step 904: each SGSN sends MBMS session start request message to the UTRAN being connected to this SGSN;

The MBMS session start request message of this step comprises session parameter: Temporary Mobile Group Identity, QoS, MBMS region, session identification, estimates session persistence, the information such as broadcast/group broadcast and MBMS data transmitting time.Message is when sending to UTRAN by Iu pattern, comprises IP multicast address and source address and public TEID-U that GGSN distributes in this session start request message.When SGSN supports that MBMS head compresses, also comprising the MBMS head compression mark expressing support for the compression of MBMS head, as may be defined as only when supporting MBMS head to compress, just occurring MBMS head compression mark.

Step 905: whether each UTRAN accepts IP multicast by session start response message notice SGSN sends;

The IP multicast address and source address and public TEID-U that start GGSN distribution in request message if UTRAN accepts session, then notify that SGSN accepts IP multicast and sends, accept the instruction that IP multicast sends as brought in the session start response message being sent to SGSN, if do not comprise IP multicast address and source address and public TEID-U in the session start request message that UTRAN receives, or UTRAN does not accept session and starts IP multicast address in request message and source address, or do not accept public TEID-U, then notify that SGSN does not accept IP multicast, as in the session start response message being sent to SGSN without supporting the instruction that IP multicast sends, be defaulted as and do not support that IP multicast sends, also can be in session start response message, carry the attribute field whether supporting that IP multicast sends, represent when getting different values that accepting IP multicast sends and do not accept respectively.But the present invention does not limit concrete advice method.

Step 906: whether each SGSN accepts IP multicast by session start response message notice GGSN sends;

To certain SGSN, send if all downstream nodes accept IP multicast, this SGSN accepts IP multicast by session start response message notice GGSN and sends, accept the instruction that IP multicast sends as brought in session start response message, and carry accepted IP multicast address and source address and public TEID-U.Send if all downstream nodes do not accept IP multicast, SGSN does not accept IP multicast by session start response message notice GGSN and sends, in session start response message, be provided for the TEID-U that point-to-point GTP tunnel sends user face data, return to point-to-point GTP tunnel between SGSN and GGSN and send user face data mode.Do not accept IP multicast as there being part receiving portion in downstream node to send, this SGSN can accept IP multicast by session start response message notice GGSN and send, there is provided point-to-point GTP tunnel to send the TEID-U of user face data simultaneously, serve another part and do not support the downstream node that IP multicast sends.

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

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

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

CDF will comprise record type, the GGSN address of use, MBMS session identification, the information such as data traffic list (only adding up down direction) and time in the ticket G-MB-CDR that opens of GGSN.One or more information following starting to comprise in charging request message also add G-MB-CDR to: downstream node list, the IP multicast address sent for IP multicast and source address and public TEID-U.In addition, G-MB-CDR can also comprise and represents the GGSN MBMS head compact token of whether supporting MBMS head compress and/or represent that the IP multicast transmission whether GGSN supports IP multicast to send indicates.

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

Step 907:UTRAN is that necessary Radio Resource is set up in MBMS data transmission.

In addition, if by session start response message notice GGSN, SGSN supports that IP multicast sends, this SGSN can not produce charge information; If SGSN and GGSN sets up GTP tunnel and sends user face data, downstream node list should be comprised in the beginning accounting request that this SGSN sends, comprise the downstream node not supporting that IP multicast sends in this downstream node list, charging data function is also comprise described downstream node list in the ticket of 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 conversation end request and responds to BM-SC;

Step 1001a: after BM-SC receives conversation end request response from any one GGSN, sends and terminates to start charging request message ACR [Stop] to CDF.CDF closes the ticket C-BMSC-CDR opened, in ticket except the fields such as time, data traffic list (only adding up down direction), content provider identification symbol, MBMS session identification, address list List of Downstream Nodes information, in the present embodiment, also comprise head compression mark and IP multicast transmission mark; CDF returns charge response message to BM-SC.

Follow-up MBMS conversation end request process can start charging request message concurrent process with the end of step 1001a and occur.

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

Step 1002a:GGSN receives the response of the conversation end request that arbitrary SGSN returns, and when MBMS bearer context stops (or any abnormal release), sends and terminates to start charging request message ACR [Stop] to CDF;

The information that comprises of charging request message is corresponding with starting, and this terminates to comprise downstream node list in beginning charging request message, and/or IP multicast address and the information such as source address and public TEID-U.Can also comprise and represent that GGSN supports that the MBMS head compression mark of the compression of MBMS head and the transmission of IP multicast and IP multicast send mark.

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

After step 1004:MBMS data send and terminate, Release radio resource.

Once there is MBMS session updates (session update) process that the change etc. due to service area causes in MBMS broadcast transmission process, charging also correspondingly can produce Intermediate Charging ICH message ACR [interim] and partial CDR (Partial CDR), these Intermediate Charging ICH message send relevant information with the IP multicast that also can comprise in partial CDR in similar process above, repeat no more.

Consider that 2G/3G BM-SC in period can upgrade and support that IP multicast sends, also can not support and rollback (fall back) to GTP-U tunnel protocol mode, equally, in eMBMS framework, (legacy) UTRAN that compatible 2G/3G Web vector graphic is inherited accesses MBMS-GW also to be existed above-mentioned support and not to support that IP multicast sends two kinds of possibilities.Proposition of the present invention is for solving the differentiation billing issues under above-mentioned complicated networking scene.Pass through the above embodiment of the present invention, provide the MBMS load side off-line accounting method to content supplier under the broadcast mode of MBMS, make common carrier can in MBMS, content supplier is carried out according to whether supporting that IP multicast transmission MBMS user face data sets different rates and carries out charging, thus helps common carrier and content supplier to carry out expense sorting to developing MBMS service.

The foregoing is only the preferred embodiments of the present invention, be not limited to the present invention, for a person skilled in the art, the present invention can have various modifications and variations.Within the spirit and principles in the present invention all, any amendment done, equivalent 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 an a broadcast multicast service center BM-SC and Gateway GPRS Support Node GGSN after capacity upgrade, support that IP multicast sends in this MBMS network architecture, the method comprises:

Supporting in the session start request process that the BM-SC that IP multicast sends initiates, support the GGSN distributing IP multicast address that IP multicast sends and source address and common user plane tunnel endpoint identifier TEID-U and be sent to downstream node, after described downstream node receives, notifying whether described GGSN accepts IP multicast and send;

Accept IP multicast if any downstream node to send, described GGSN is starting to carry in accounting request the IP multicast address and source address and public TEID-U that described downstream node accepts, and charging data function records described IP multicast address and source address and public TEID-U in the charging data record CDR opened for described GGSN;

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

GGSN carries the IP multicast transmission mark whether an expression supports IP multicast to send in the beginning accounting request sent to charging data function; Or GGSN, only when supporting IP multicast to send, just carrying an IP multicast and sending mark in the beginning accounting request sent to charging data function;

Charging data function arranges an IP multicast and sends mark in the CDR opened for GGSN, and the value that this IP multicast sends mark represents whether support that IP multicast sends.

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

GGSN carries the MBMS head compression mark whether an expression supports MBMS head to compress in the beginning accounting request sent to charging data function; Or GGSN, only when supporting the compression of MBMS head, just carries a MBMS head compression mark in the beginning accounting request sent to charging data function;

Charging data function arranges a MBMS head compression mark in the CDR opened for GGSN, and the value of this MBMS head compression mark represents whether support that MBMS head compresses.

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

The IP multicast address of distribution and source address and public user face tunnel endpoint identifier TEID-U are sent to the SGSN in downstream by described GGSN by session start request;

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

By session start response, described SGSN, when there being UTRAN to accept the transmission of IP multicast, notifies that described GGSN accepts IP multicast and sends; When there being UTRAN not accept the transmission of IP multicast, provide TEID-U by session start response, and between GGSN, set up GTP tunnel transmission user face data;

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

In the session start request process that BM-SC initiates, MBMS gateway MBMS-GW distributing IP multicast address and source address and public user face tunnel endpoint identifier TEID-U are also sent to downstream node, and described downstream node notifies whether described MBMS-GW accepts IP multicast and send;

Accept IP multicast if any downstream node to send, described MBMS-GW is starting to carry in accounting request the IP multicast address and source address and public TEID-U that described downstream node accepts, and charging data function records described IP multicast address and source address and public TEID-U in the charging data record CDR opened for described MBMS-GW;

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

MBMS-GW carries the MBMS head compression mark whether an expression supports MBMS head to compress in the beginning accounting request sent to charging data function; Or MBMS-GW, only when supporting the compression of MBMS head, just carries a MBMS head compression mark in the beginning accounting request sent to charging data function;

Charging data function arranges a MBMS head compression mark in the CDR opened for MBMS-GW, and the value of this MBMS head compression mark represents whether support that MBMS head compresses.

7. the method as described in claim 5 or 6, is characterized in that;

By session start response, described SGSN, when there being UTRAN to accept the transmission of IP multicast, notifies that described MBMS-GW accepts IP multicast and sends; Have downstream node do not accept IP multicast send time, described SGSN in session start response, provide TEID-U and and return back to point-to-point GTP tunnel between GGSN and send the mode of user face data;

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

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

The GGSN supporting IP multicast to send is used for after receiving the session start request that the BM-SC that supports IP multicast to send sends, and distributing IP multicast address and source address and public user face tunnel endpoint identifier TEID-U, be sent to downstream node; Accept IP multicast if any downstream node to send, starting to carry in accounting request the IP multicast address and source address and public TEID-U that described downstream node accepts, do not accept IP multicast if any downstream node to send, in beginning accounting request, carry corresponding downstream node list;

Described charging data function is used for the described downstream node list will comprised in described beginning accounting request, or the described IP multicast address comprised and source address and public TEID-U, or the described downstream node list comprised, described IP multicast address and source address and public TEID-U are recorded in the charging data record CDR opened for described GGSN.

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

Described charging data function arranges an IP multicast and sends mark in the CDR opened for GGSN, and the value that this IP multicast sends mark represents whether support that IP multicast sends.

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

GGSN carries the MBMS head compression mark whether an expression supports MBMS head to compress in the beginning accounting request sent to charging data function; Or described GGSN, only when supporting the compression of MBMS head, just carries a MBMS head compression mark in the beginning accounting request sent to charging data function;

Described charging data function arranges a MBMS head compression mark in the CDR opened for GGSN, and the value of this MBMS head compression mark represents whether support that MBMS head compresses.

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

Described MBMS-GW is used for after receiving the session start request that BM-SC sends, and distributing IP multicast address and source address and public user face tunnel endpoint identifier TEID-U are also sent to downstream node; Accept IP multicast if any downstream node to send, starting to carry in accounting request the IP multicast address and source address and public TEID-U that described downstream node accepts, do not accept IP multicast if any downstream node to send, in beginning accounting request, carry corresponding downstream node list;

Described charging data function is used for the described downstream node list will comprised in described beginning accounting request, or the described IP multicast address comprised and source address and public TEID-U, or the described downstream node list comprised, described IP multicast address and source address and public TEID-U are recorded in the charging data record CDR opened for described MBMS-GW.

13. systems as claimed in claim 12, is characterized in that;

MBMS-GW carries the MBMS head compression mark whether an expression supports MBMS head to compress in the beginning accounting request sent to charging data function; Or described BM-SC and/or MBMS-GW, only when supporting the compression of MBMS head, just carries a MBMS head compression mark in the beginning accounting request sent to charging data function;

Described charging data function arranges a MBMS head compression mark in the CDR opened for MBMS-GW, and the value of this MBMS head compression mark represents whether support that MBMS head compresses.