1.1. Charging Overview in MBMS
- MBMS shall collect charging information about the delivery of MBMS broadcast or multicast data that are provided by content or service providers (e.g. 3rd parties).
- MBMS shall collect charging information about the usage of MBMS multicast services by individual users/receivers.
- This charging information may include duration of service usage, volume of MBMS data, MBMS service area, time when joining or leaving a multicast group.
- For MBMS broadcast mode, it is expected that charging data for the end user will not be generated for this mode at MBMS Transport Service layer. Charging data related to security procedures for the end user at MBMS User Service layer may be generated.
- For MBMS Multicast mode, it is expected that charging data for the end user will be generated for this mode at MBMS Transport Service layer. Charging data related to security procedures for the end user at MBMS User Service layer may be generated.
- The MBMS User Service shall support standardized mechanisms to transfer charging related information. It shall be possible to charge for MBMS content the user receives while roaming in a VPLMN. It shall also be possible to collect charging information for MBMS services in visited networks.
The MBMS User Service shall support the following charging mechanisms:
- Charging on a subscription basis
- Charging for keys that that allow the user access to the data
Charging Data of MBMS
- The MBMS architecture shall support on-line and off-line charging.
- To enable billing of broadcast and multicast content providers, charging data shall be collected at the BM-SC.
- SGSN, GGSN and BM-SC generate charging data for the transmitted data, always under the assumption that the UEs are within the MBMS service area.
Bearer level charging for MBMS
- To provide bearer level charging for MBMS, mechanisms and functional elements described in TS 23.125 are used for MBMS Bearer Contexts.
- Flow Based Charging (FBC) may be used to collect charging data records for MBMS Bearer Contexts e.g. for the purpose to charge the service provider, cf. TS 23.125.
- Since multiple users share an MBMS bearer context FBC cannot be used for creating reports on a per user basis
Application level charging for MBMS
- In order to meet the MBMS charging requirements in TS 22.146 and TS 22.246, the following elements and functionalities are provided by the MBMS architecture.
- The MSISDN and IMSI are passed to the BM-SC. This provides the operator with the ability to associate GPRS location information (i.e. serving network identity) with a user.
- In order to permit differential roaming tariffs, the serving network identity is provided to the BM-SC. Charging information generated for application layer charging events should include the above information provided by the GPRS network to facilitate differential roaming tariffs.
- Charging for MBMS services is based on application layer mechanisms, since it is only at the application layer that security is provided which can restrict content to authorised users or confirm delivery of content to users.
- Charging information should include an indication of the point at which the user had access to the content (e.g. if and when decryption keys for encrypted content are sent to the UE.)
Generation of charging records in the VPLMN
- In order to permit the settlement of inter-operator roaming charges, the SGSN needs to raise CDRs.
Charging in BM-SC:
- The BM-SC shall collect charging information for mobile subscribers receiving services through MBMS and/or for content providers delivering content through MBMS. Transactions involving the content provider (or VASP) shall be possible.
The BM-SC collects charging related information, such as:
| | GPRS | LTE/EPS |
| Identification of the source of content. | YES | YES |
| Type of user service (streaming, download or carousel). | YES | YES |
| Type of bearer service used to deliver content | broadcast or multicast | broadcast or enhanced broadcast |
| Identification of subscribers receiving service. | YES | NO |
| Delivery notification from individual subscribers. | YES | NO |
The parties to be charged for the different MBMS bearer services
- The user service in below table shall be charged either by subscription or as a one time event charge (e.g. key management). Charging associated with the user service may be treated independently from charging associated with the transport of the user service.
| Service Aspects | MBMS Bearer Service used in GPRS | MBMS Bearer Service used in LTE/EPS | ||
| Multicast (one or more) | Broadcast (one or more) | Broadcast (one or more) | Enhanced Broadcast (one or more) | |
| User Service (Content) | Receiving subscriber | Receiving subscriber | Receiving subscriber | Receiving subscriber |
| Bearer Service (Transport) | Content provider and/or receiving subscriber | Content provider | Content provider | Content provider |
Charging for the bearer service may be based on the session information (e.g. QoS, media type, and service area) and one of the following, as described in 3GPP TS 22.146:
| | GPRS | LTE/EPS |
| Session duration (time from the MBMS Session Start procedure to MBMS Session Stop procedure as defined in 3GPP TS 23.246). | YES | YES |
| Volume of data of a session. | YES | YES |
| Duration of time whilst a subscriber is registered to receive a user service (or from Join to Leave). | YES | NO |
| Volume of data transferred whilst a subscriber is registered to receive a user service (from Join to Leave). | YES | NO |
| Service Aspects | Accounting Measurement in GPRS | Accounting Measurement in LTE/EPS | ||
| Multicast Service | Broadcast Service | Broadcast Service | Enhanced Broadcast Service | |
| Session Duration | Yes | Yes | Yes | Yes |
| Volume of data of a session | Yes | Yes | Yes | Yes |
| Duration of time whilst a subscriber is registered to receive a session | Yes | No | No | No |
| Volume of data transferred whilst a subscriber is registered to receive a session | Yes | No | No | No |
Triggers for generation of charging information
- Bearer service initiation/termination
- Key management
1.2. Charging in MBMS Broadcast Mode
It shall be possible to collect charging information for the transmission of broadcast services to enable billing of broadcast services providers e.g. billing 3rd parties for advertising.
Examples of the type of the charging information that could be collected include:
- usage duration (Session Duration)
- volume of contents (of a Session)
It shall be possible to collect subscriber charging information for the end user (including roaming situations) based on security procedures (e.g. key management) for the receipt of broadcast data on a per broadcast service basis.
Charging for Broadcast mode
- To enable billing of broadcast content providers, data shall be collected at the BM-SC.
- The data will be needed on the number of cells in the broadcast area.
- For the Broadcast Mode the BM-SC generates Charging Data Record (CDR) for the billing of the Content Provider.
Examples of the type of the charging information that may be collected at the BM-SC include:
- Service time and duration
- Volume of data
- MBMS broadcast area
- Number of cells in broadcast area
1.3. Charging in MBMS Multicast Mode
It shall be possible to collect charging information for the transmission of multicast services to enable billing of multicast services providers e.g. billing 3rd parties for advertising.
It shall be possible to collect subscriber charging information (including roaming) for the use of the multicast mode (e.g. to enable billing to multicast services providers), as well as for the receipt of multicast data (e.g. users), on a per multicast service basis. On-line charging for multicast services should be possible as well.
Examples of the type of the charging information that could be collected include:
- Multicast session duration
- Time when joining and leaving a multicast subscription group, duration of membership to a multicast subscription group
- Time when joining and leaving a multicast group, duration of membership to a multicast group
- Multicast session volume of contents
Content Provider Charging Mechanism
- To enable billing of multicast content providers, data shall be collected at the BM-SC.
- In addition content provider CDRs may be generated by the GGSN or by the SGSN. The consolidation of content provider CDRs from BM-SC, SGSN and GGSN may be performed in the Charging Gateway Function (CGF), in the Charging Collection Function (CCF) or in the Billing System (BS).
- The data will be needed on the number of cells in the multicast area.
Examples of the type of the charging information that should be collected at the BM-SC include:
- Service time and duration
- Volume of data
- Geographic area of multicast area
- Number of cells in multicast area
Subscriber Charging
On-line charging
- The architecture should enable the on-line charging of multicast services.
- To enable this, CAMEL functionality on the SGSN might need to be extended.
- In addition the CSE may need to interact with the BM-SC to obtain, e.g., rating information.
Off-line charging
- The Multicast service should enable the user to be charged for the services that they receive.
- This charging might be either on the volume of data received and/or just on the fact that the user activated the multicast PDP context.
The SGSN should be able to generate charging information that includes at least the following information:
- Service time and duration
- Volume of data
1.4. MBMS Offline Charging Architecture and Message Flow
- Figure below depicts the MBMS offline charging architecture.
http://docs.google.com/View?id=ddh56dhg_1338rjqw2gc
- As defined in 3GPP TS 32.240, the BM-SC contains an integrated CTF (Charging Trigger Function) that generates charging events that are passed to the CDF via the Rf reference point.
- Rf Interface: The Diameter client (BM-SC) uses ACR start, interim and stop in procedures related to both subscriber and content provider charging with CDF.
- Ga record transfer flows: For further details on the Ga protocol application refer to 3GPP TS 32.295
- Bmb CDR file transfer: The CGF transfers the CDR files to the BD. For further details on the Bmb protocol application refer to 3GPP TS 32.297
- Offline Charging information shall be generated for subscribers and/or for content providers.
- The BM-SC generates accounting information that can be transferred to the CDF.
- The MBMS Accounting application employs the Accounting-Request (ACR) and Accounting-Answer (ACA) messages from the Diameter base protocol.
- This reporting is achieved by sending Diameter Accounting Requests (ACR) [start, interim, stop and event] from the BM-SC to the CDF. The request can be of type start, stop, interim and event.
- The accounting request message includes all charging information and the answer is just an acknowledgement of the request message.
Offline Charging – Rf Diameter Messages:
| Command-Name | Abbreviation | Source | Destination |
| Accounting-Request | ACR | BM-SC | CDF |
| Accounting-Answer | ACA | CDF | BM-SC |
Table - Accounting Request messages for subscriber charging for GPRS (N/A)
Table - Accounting Request messages for content provider charging for GPRS (N/A)
Table - Accounting Request messages for content provider charging for LTE/EPS (N/A)
Table - Accounting-Request (ACR) Message Contents for Offline Charging (N/A)
Table - Accounting-Answer (ACA) Message Contents for Offline Charging (N/A)
Offline Charging Message Flow in MBMS Broadcast and Multicast Bearer / Service (32.273 – See Procedure and Call Flow Section)
CDRs related to MBMS subscribers: (S-BMSC-CDR)
Triggers for S-BMSC-CDR charging information collection in CDF
- A S-BMSC-CDR is used to collect charging information related to the MBMS Bearer Service information for a UE/MS in the BM-SC. A CDR is generated for each MBMS bearer service used and for each subscriber using the MBMS Bearer Service.
- A S-BMSC-CDR shall be opened at UE activation as triggered by an ACR (Start). The volume for the MBMS bearer context is counted in downlink direction.
Table - Triggers for S-BMSC-CDR addition (N/A)
Table - Triggers for S-BMSC-CDR closure (N/A)
Table - Subscriber BM-SC data (S-BMSC-CDR) (N/A)
CDRs related to MBMS content provider: (C-BMSC-CDR)
Triggers for C-BMSC-CDR charging information collection in CDF
- A C-BMSC-CDR is used to collect charging information related to the MBMS Bearer Service information for a content provider to the BM-SC. A C-BMSC-CDR is generated for each MBMS Bearer Service.
- A C-BMSC-CDR shall be opened at MBMS Session Start as triggered by an ACR (Start). The volume for the MBMS bearer context is counted in downlink direction.
- The subsequent clauses identify in detail the conditions for adding information to, and closing the C-BMSC-CDR for passing towards the CGF.
Table - Triggers for C-BMSC-CDR addition (N/A)
Table - Triggers for C-BMSC-CDR closure (N/A)
Table - Content Provider BM-SC data (C-BMSC-CDR) (N/A)
1.5. MBMS Online Charging Architecture and Message Flow
- Figure below depicts the MBMS online charging architecture.
http://docs.google.com/View?id=ddh56dhg_135ctkmckfb
- For online charging, the BM-SC utilizes the Ro interface and the protocol and application towards the OCS is as specified in 3GPP TS 32.299
- MBMS online charging uses the credit control application as specified in 3GPP TS 32.299
- Online charging of content providers is still not supported in R9 release.
- The type of online interaction used is dependent on the user service type, bearer type, and whether delivery notification is required.
- MBMS Online Charging Ro interface uses Credit-Control-Request (CCR) and Credit-Control-Answer (CCA) messages defined in 3GPP TS 32.299.
- The CCR triggers the rating of the MBMS service and reserves units on the user's account. The CCR for the
- The CCA is a response including any reserved units or an error code if the user is out of credit.
Online Charging – Ro Diameter Messages:
| Command-Name | Abbreviation | Source | Destination |
| Credit-Control-Request | CCR | BM-SC | OCS |
| Credit-Control-Answer | CCA | OCS | BM-SC |
Table - Online interaction dependency on MBMS service parameters (N/A)
Broadcast Service - User service charging
- A MBMS user service that is delivered using a broadcast bearer may be Event charged or Session charged.
- As there is no 3GPP specified signalling for a UE to activate or deactivate the broadcast service, it is MBMS user service dependent (e.g. key management) when the Accounting Request is triggered.
Online Charging Message Flow in MBMS Multicast Bearer / Service (32.273 – See Procedure and Call Flow Section)
Triggers for stopping for an MBMS service Credit Control session
In addition to message flows, a CCR [Terminate] is sent to OCS when:
- Session termination is indicated by the OCS (e.g. Credit Limit Reached);
- Abort-Session-Request is received from the OCS, this also results in the deactivation of the MBMS UE Context, if one exists for the session being terminated.
Triggers for providing interim information for a MBMS service Credit Control session
In addition to the message flows, a CCR [Update] is sent to OCS when:
- Granted quota runs out;
- Validity time for granted quota expires;
- Update is requested by the OCS;
- Change of charging conditions occur and according re-authorisation trigger re-authorisation is needed;
- Management intervention.
Table - Credit-Control-Request (CCR) Message Contents (N/A)
Table - Credit-Control-Answer (CCA) Message (N/A)
1.6. MBMS charging specific parameters
The components used for MBMS charging are provided in the Service-Information as described in table. (Table - N/A)
Definition of the MBMS Information (Table - N/A)
- MBMS specific charging information is provided within the MBMS Information. The detailed structure of the MBMS Information can be found in table
- MBMS charging information for CDRs: The detailed definitions, abstract syntax and encoding of the MBMS CDR parameters are specified in TS 32.298.
- MBMS charging information for charging events: The detailed charging event parameter definitions are specified in 3GPP TS 32.299.
1.7. Charging Diameter AVP in MBMS Service
1. Service-Information AVP
The Service-Information AVP (AVP code 873) is of type Grouped. Its purpose is to allow the transmission of additional 3GPP service specific information elements. It has the following ABNF grammar:
Service-Information :: = <>
- *[ Subscription-Id ]
- [ AoC-Information ]
- [ PS-Information ]
- [ WLAN-Information ]
- [ IMS-Information ]
- [ MMS-Information ]
- [ LCS-Information ]
- [ PoC-Information ]
- [ MBMS-Information ]
- [ SMS-Information ]
- [ MMTel-Information ]
- [ Service-Generic-Information ]
- [ IM-Information ]
- [ DCD-Information ]
2. MBMS-Information AVP
The MBMS-Information AVP (AVP code 880) is of type Grouped. Its purpose is to allow the transmission of additional MBMS service specific information elements. It has the following ABNF grammar:
MBMS-Information :: = <>
- [ TMGI ]
- [ MBMS-Service-Type ]
- [ MBMS-User-Service-Type ]
- [ File-Repair-Supported ]
- [ Required-MBMS-Bearer-Capabilities ]
- [ MBMS
- [ RAI ]
- *[ MBMS-Service-Area ]
- [ MBMS-Session-Identity ]
3. TMGI (Temporary Mobile Group Identity) AVP
The purpose of the TMGI element is for group paging in MBMS. The TMGI AVP (AVP code 900) is of type Octet String, and contains the Temporary Mobile Group Identity allocated to a particular MBMS bearer service. It is allocated by the BM-SC. The encoding of TMGI is specified in 3GPP TS 24.008. When allocating the TMGI, BM-SC shall always include the MCC and MNC in the TMGI.
The TMGI information element is a type 4 (
The content of the TMGI element is shown in 3GPP TS 24.008.
| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | |
| Temporary Mobile Group Identity IEI | Octet 1 | |||||||
| Length of Temporary Mobile Group Identity contents | Octet 2 | |||||||
| MBMS Service ID | Octet 3 Octet 4 | |||||||
| Octet 5 | ||||||||
| MCC digit 2 | MCC digit 1 | Octet 6* | ||||||
| MNC digit 3 | MCC digit 3 | Octet 7* | ||||||
| MNC digit 2 | MNC digit 1 | Octet 8* | ||||||
The MBMS-Service-Type AVP (AVP code 906) is of type Enumerated, and contains explicit information about the type of service that the BM-SC Start Procedure is about to start.
MULTICAST (0)
- The Start Procedure signalled by the BM-SC is for a Multicast Service.
BROADCAST (1)
- The Start Procedure signalled by the BM-SC is for a Broadcast Service.
The MBMS-User-Service-Type AVP (AVP code 1225) is of type Enumerated and indicates type of service the MBMS user service that is being delivered. The following values are supported:
DOWNLOAD (1)
- The MBMS user service of type: download.
STREAMING (2)
- The MBMS user service is of type: streaming.
6. File-Repair-Supported AVP
The File-Repair-Supported AVP (AVP code 1224) is of type Enumerated and indicates whether the MBMS user service supports point-to-point file repair. The following values are supported:
SUPPORTED (1)
- The MBMS user service does support point-to-point file repair.
NOT_SUPPORTED (2)
- The MBMS user service does not support point-to-point file repair.
7. Required-MBMS-Bearer-Capabilities AVP
The purpose of the MBMS bearer capabilities information element is to indicate the maximum bit rate for downlink supported by the MS for an MBMS context.
The Required-MBMS-Bearer-Capabilities AVP (AVP code 901) is of type UTF8String, and contains the minimum bearer capabilities the UE needs to support. The information contained in this AVP is UTF-8 encoded MBMS bearer capabilities as defined in 3GPP TS 24.008.
The MBMS bearer capabilities is a type 4 information element with a maximum length of 4 octets.
The MBMS bearer capabilities information element is coded as below
| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | |
| MBMS bearer capabilities IEI | Octet 1 | |||||||
| Length of MBMS bearer capabilities IE | Octet 2 | |||||||
| Maximum bit rate for downlink | Octet 3 | |||||||
| Maximum bit rate for downlink (extended) | Octet 4 | |||||||
8. MBMS
- The MBMS
The following values are supported:
- The MBMS bearer service shall only be delivered in
- The MBMS bearer service shall only be delivered in
- The MBMS bearer service shall be delivered both in
9. Routing area identification (RAI)
- The purpose of the routing area identification information element is to provide an unambiguous identification of routing areas within the GPRS coverage area.
- The RAI AVP (AVP Code 909) is of type UTF8 String, and contains the Routing Area Identity of the SGSN where the UE is registered.
- RAI use and structure is specified in 3GPP TS 23.003
- The routing area identification is a type 3 information element with 7 octets length.
- The routing area identification information element is coded as shown below
| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | |
| Routing Area Identification IEI | octet 1 | |||||||
| MCC digit 2 | MCC digit 1 | octet 2 | ||||||
| MNC digit 3 | MCC digit 3 | octet 3 | ||||||
| MNC digit 2 | MNC digit 1 | octet 4 | ||||||
| LAC | octet 5 | |||||||
| LAC cont'd | octet 6 | |||||||
| RAC | octet 7 | |||||||
10. MBMS-Service-Area AVP
- The MBMS-Service-Area AVP (AVP code 903) is of type Octet String, and indicates the area over which the MBMS bearer service has to be distributed.
- The AVP consists of the following parts:
| Octet | |
| 1 | Number N of MBMS service area codes coded as: 1 binary value is '00000000' ... ... 256 binary value is '11111111' |
| 2-(2N+1) | A consecutive list of |
- The MBMS service area code represents the coding for the MBMS Service Area Identity. It is assigned by BM-SC and mapped to one or more cells by the RNC/BSS.
- The length of an MBMS service area code is 2 octets.
- Each MBMS service area code shall only be present once in the list.
11. MBMS-Session-Identity AVP
- The MBMS-Session-Identity AVP (AVP code 908) is of type Octet String.
- Its length is one octet. It is allocated by the BM-SC.
- Together with TMGI it identifies a transmission of a specific MBMS session.
- The initial transmission and subsequent retransmissions of the MBMS session will use the same values of these parameters.
- This AVP is optional within the Gmb interface.
沒有留言:
張貼留言