4 Main Requirements and High-Level Principles

22.1153GPPCharging and billingRelease 17Service aspectsTS

The main new requirements for 3GPP system charging and accounting are:

– to provide charging information for all charges incurred and requiring settlement between the different commercial roles;

– to allow fraud control by the Home Environment and the Serving network;

– to allow cost control by the charged party;

– to provide at the beginning of a chargeable event an indication to the charged party (if involved in the chargeable event) of the charges to be levied for this event;

– to allow itemised billing for all services charged to each subscription, including voice and data calls, and services offered by home environments;

– to enable the Home environment to provide a Prepay Service and to enable the serving network to support that Prepay Service for the Home environment’s subscribers;

– to allow interconnect (inter-operator) charging including mobile/fixed operator to mobile/fixed operator (circuit switched & IP), and mobile/fixed operator to IP network provider; and mobile/fixed operator to I-WLAN operator;

– to allow Network operator to 3^rd party supplier (e.g. Value-Added Service Provider) charging;

– to provide details required for Customer Care purposes;

– to support the shared network architecture so that end users can be appropriately charged for their usage of the shared network, and network sharing partners can be allocated their share of the costs of the shared network resources.

The high-level principles that will guide the charging requirements are summarised as follows:

– It shall be possible to charge separately for each type of medium used (e.g. voice, video, data) in a session and for each service used (e.g. voice call, streaming video, file download);

– It shall be possible to charge for different levels of QoS applied for and/or allocated during a session for each type of medium or service used;

– It shall be possible to charge each "leg" of a session separately. This includes the incoming and outgoing legs and any forwarded/redirected legs. (Note: The legs mentioned here are logical legs, i.e. not necessarily identical to actual signal and traffic flow. Even though tromboning may be avoided by optimal routing, the operator should still be able to charge for the ‘virtual legs’ of the call);

– It shall be possible to charge unsuccessful calls and sessions (e.g. for billing purposes, to provide the user a full documentation of his call attempts);

– The user can be charged according to the service used irrespective of the technology used to deliver it. (That is, the charge is not derived from whether 2G or 3G is used);

– The user can be charged according to the technology used to deliver a service. (That is, different charges can be applied on 2G and 3G);

– It shall be possible to charge a user according to the network resources used. For example, if a large bandwidth is required to use high quality video, the user could be charged accordingly. This is related to charging by QoS;

– It shall be possible to charge users flexibly for the use of extra resources (in at least the same network) for all legs of the call. For example, if a video component is added to a voice call the use of extra radio resource at both ends of the call could be paid for by each user in the call or totally by the initiating user;

– It shall be possible to suppress charging for certain types of connection e.g. when a customer receives tones or network announcements or during sessions such as automated pre-pay top-up;

– It shall be possible to apply different charging based on tariff information provided by a 3^rd party. This tariff information may change during the use of the service (e.g. based on menu selection in a voice response menu). In this case the requirement applies both for customer-charging and interconnect-charging;

– It shall be possible for the home network to charge its customers while roaming in the same ways as when they are at home. For example, if duration-based charging is used for charging for streaming music in the home network, then it shall be possible to apply the same principle when the user is roaming;

– It shall be possible for operators to have the option to apply charging mechanisms that are used in GSM/GPRS. For example, for duration of a voice call, for the amount of data transmitted (e.g. for streaming, file download, browsing) and for an event (one-off charge);

– It shall be possible for a network operator to charge its users for activities while roaming so that the home network will get the capability to raise service charges depending on the roamed to network, e.g. because of inter operator charges for the use of service capabilities within the visited network which will in general depend on the serving network. The ability to supply all the necessary information for all the charging options will depend on the capability of the visited network. For service capabilities which are provided by the home network, however, it is required that the charging information is collected to allow to identify the serving network of the served subscriber;

– It shall be possible for charging to be applied based on location, presence, push services etc.;

– The network may provide information to the UE so that the UE is able to notify and indicate to the user the LCZs it is in. This allows the user to decide whether to accept/originate the service depending on the LCZs they are in;

– It shall be possible to charge using pre-pay, post-pay, advice of charge, 3^rd party charging techniques;

– It shall be possible for the home network to apply different tariffs to national calls and short messages established/sent by their subscribers while roaming in their Home PLMN depending on whether or not the called subscriber’s Home PLMN equals the calling subscriber’s Home PLMN, rather than on the called subscriber’s MSISDN;

Note: This distinction is necessary only in the case, where the called subscriber’s MSISDN may have been ported by Mobile Number Portability.

– For circuit switched interconnection only a capability is required to collect information regarding user rate and user protocol at the interconnection point so that e.g. the identification of CS video telephony at the interconnection point for inter-network accounting purposes becomes possible.

These new requirements and principles will allow users more freedom to obtain service when roaming, whilst providing effective cost and credit control for the Home Environment and User.

4.1 Cross Phase Compatibility

Where possible (e.g. services already defined within earlier releases), the charging information collected shall be consistent with the information already provided

It is envisaged that 3GPP system will evolve beyond this Release with the addition of a number of new requirements for charging and billing, for example with the addition of a number of new requirements for charging and billing; these are noted in the appropriate sections below. The technical standards for each release should be developed in such a way that it is possible and practical to introduce these requirements, ideally in a backward compatible manner.

Note: When a change is introduced which affects the 3GPP technical standards, it is said to be ‘backward compatible’ if existing equipment can continue to operate and perform correctly with equipment that conforms to the new implementation.

4.2 Charging Entity Relationships

In the process of introduction of the all-IP technology there will be a mixture of different types of entities using different types of technology.

The diagram below shows the different entities involved in charging and their relationships.

The types of entities and the relevant type of charging as shown on the diagram are as follows:

• Users: retail charged by Mobile Network Operator or 3^rd Party Service Provider.
• 3^rd Party Service Providers: wholesale charged by Mobile Network Operator.
• Other telecommunications operators: interconnect charging between Mobile Network Operator and non-IP "circuit-switched" Network Operators for call traffic carried; usage charging between Mobile Network Operator and IP-based Network Operators for session traffic carried.
• Other mobile operators: roaming charging between these entities, this may require different mechanisms for IP-based types from the traditional "circuit-switched" types. Also, where mobile operators need to pass traffic to one another, there will be interconnect charging for non-IP "circuit switched" types; usage charging for IP-based types.
• I-WLAN operators: where I-WLAN operators need to pass traffic to mobile operators or mobile operators to I-WLAN operators, there may be roaming and usage charging.
• IP backbone carriers: conveyance charging Mobile Network Operators for traffic carried.
• 3^rd Party content & application suppliers: supplier charging between Mobile Network Operators and Value Added Service Providers for information exchanged.
• 3^rd Party Portals: access charging between Mobile Network Operators and this entity.
• Internet: charge for capacity of connection between Mobile Network Operator and Internet. An Operator pays a provider for a connection based on capacity, e.g. annual charge for a 2Mbit/s "pipe".

4.3 Charging guidelines for IP-Multimedia services

4.3.1 User Charging Requirements

This section describes the options required for the charging of end users. The network operator could charge users directly (retail charging) or charge a 3^rd party service provider (wholesale charging). These requirements can therefore apply to retail and wholesale charging. Note that the word "session" is used to describe the connection between a user and either another user or a service. This term is used for IP connections rather than the term "call" that is normally used for a connection over conventional (circuit switched) systems.

The various ways that users can establish sessions and the main components are described. Also, the required charging options are specified.

4.3.1.1 Session End Point Configurations

A variety of different connection configurations are possible for IP multi-media independently of the components of the session being used. It should be possible to charge for the following types of sessions with the options identified. These charging options should be applicable to each medium separately. Note that not all the charging options need to be used and that some of the options can be used only if the particular party is using the resources of IMS:

The table below lists some example session scenarios and describes some of the possible charging options for each scenario. The table does not list all possible session scenarios nor does it list all possible charging options for the scenarios. Rather, the intent of the table is to emphasize the numerous charging options that shall be supported by an IP Multimedia System due to the complexity of sessions possible. The charging options shall adequately account for all session resources used in order to enable the operators to apply flexible billing policies and to satisfy regional and/or national regulatory policies.

In general, any session shall allow for the following charging options:

• To apply the "Calling Party Pays" charging principle;
• A 3^rd party to be charged for all or part of the session;
• Split charging between any of the parties, including 3^rd parties;
• Session setup and session resources to have different charging rules. Different rules would be applied for example, in a scenario where A calls an advertising number, say B. B could be a web-based toy advertisement number, for example. In this scenario, A could pay for the initiation fee (session setup), and B could pay for the session resource.
• Any party can add another media to the current session in progress and any of the parties (not necessarily the one(s) being charged for the current session) can be charged for the additional media. For example, A calls B and A is paying for the audio; B adds a wireless video image to the call and pays for that portion. The individual resource set-up and usage should be separately identified. This supports the "Calling Party Pays" model;
• During an active session, media types can change (e.g. audio changed to data) and shall be charged for appropriately. It is thus necessary to be able to detect a change of media during a session so that different rating may be applied.

It should also be noted that during a multi-party session, normally if the charged party drops off the session, all components being charged to that party should drop. But it is foreseeable to support a service option that allows the charged party to continue to be charged even if they drop off the session. The charging rules should support this option.

No	CONNECTION	DESCRIPTION	CHARGING OPTIONS REQUIRED
1	A sets up a session to B	A simple connection between 2 subscribers or a subscriber and a service (eg voicemail)	A pays for the session set-up to B A pays for the session resource to B B pays for the session resource to A
2	A sets up a session to B	A simple connection where B is a "toll free" (800) type service	B pays for the session set-up B pays for the session resource A pays for part of the session resource (i.e. allowing split charging between A & B)
3	A requests session with B, B redirects to C	This is redirection. The connection path is not set up to B from A, instead A is told to set up a connection direct to C	A pays for the session set-up to B A pays for the session resource to C C pays for the session resource to A A pays for the session resource as though it were to B and B pays for the session resource to C as though it came from B
4	A requests session with B, B forwards to C	This is normal forwarding as in GSM. The connection path is A to B’s home network and B’s home network to C	A pays for the session set-up to B A pays for the session resource as though it were to B and B pays for the session resource to C.
5	A sets up sessions with multiple parties (Multi-party)	Connections to multiple parties are initiated by A	A pays for the set-up of each session A pays for each of the sessions resource to each of the called parties Each of the called parties pays for the session resource to A
6	A has a multi-party session where the individual parties set up the session to A	The multiple parties in the session initiate the session to A	Each party pays for the session set-up to A A pays for the session resource to the multiple parties The individual parties in the session each pay for the session resource to A
7	A is in a session with B, then puts B on hold to set up a session with C, then returns to B after dropping C	A still has a connection to B while also in a session with C. The session with B continues after the session with C is terminated	A pays for each of session set-ups to B and C A pays for the session resource to B & C B & C pay for the session resource to A
8	A is in a session with B then answers a session request from C while keeping B on hold	A still has a connection to B while also in a session with C. The session with B continues after the session with C is terminated	A pays for the session set-up to B C pays for the session set-up to A A pays for the session resource to B and C B & C pay for the session resource to A
9	A sets up a session with B who is roaming in another network	The connection is made from A to B’s home network and then forwarded to B in the visited network. (Normal GSM mechanism) Alternatively, A is redirected directly to B in the visited network	A pays for the session set-up to B A pays for the session resource as though it were to B in his home network and B pays for the session resource from his home network to the visited network A pays for the session resource to B in the visited network B pays for the session resource to A

4.3.1.2 Charging Principles For User Session Components

A number of different components can comprise a session. These components may be added or dropped from an ongoing session by any participating party. These components should be individually identifiable for charging purposes.

Generally, the party that adds a component should be responsible for the payment for the use of the component. However, it should also be possible to charge all users that need an increase in resource to handle the component. An example is 2 users in an audio session where one of the users upgrades the session to videophone session. Both users could be charged extra for the use of the video component as this requires extra resource at both ends.

Possible components are:

• Voice
• Audio (real time)
• Audio (streaming)
• Video (real-time)
• Video (streaming)
• Data (download/upload)
• Data interactive e.g. web browsing
• Messaging (SMS text type)
• E-mail
• Data stream (unspecified content) This is where the network operator acts as a "bit-pipe"

It shall be possible to charge for each of these components separately in a session with the options shown in the table below.

It shall be possible for operators to be able to charge for individual components of sessions even if there is no identificable service. For example, a proprietary codec may be used to set up an "end-to-end" speech session where the network operator acts as a "bit-pipe". In this case, it should be possible for the operator to charge for this differentially. This type of component is called "datastream" in the table below.

It might not be possible to apply some of the charging mechanism and type options described below depending on the capability of the networks used.

COMPONENT	CHARGING MECHANISM OPTIONS	CHARGING TYPE OPTIONS
Voice	Charging principles as described in section 4.3.1.1	Charging by duration of session Charging by QoS requested and/or delivered One-off set-up charge
Real time Audio and Video	Charging principles as described in section 4.3.1.1	Charging by duration of session Charging by QoS requested and/or delivered One-off set-up charge
Streaming Audio and Video	Charged to the initiator of the request Charged to the sender of the audio or video	Charging by duration of session Charging by volume of data, optionally QoS-differentiated One-off set-up charge
Data (upload or download)	Charged to the initiator of the request Charged to the sender of the data	Charging by duration of session Charging by volume of data, optionally QoS-differentiated One-off set-up charge
Interactive Data	Charged to the initiator of the session	Charging by duration of session Charging by volume of data, optionally QoS-differentiated One-off set-up charge
Messaging (SMS text type)	Charged to the initiator of the message Charged to the recipient of the message	Charging by event (e.g. like SMS) Charging by volume of data
Unspecified content (data stream)	Charged to the initiator of the session Charged to all parties involved	Charging by duration of session Charging by volume of data (sent & received), optionally QoS-differentiated One-off set-up charge

4.3.1.3 Other Charging Requirements

The user will also be charged for additional activities while in a session, for example downloaded applications or information. The table below shows some of these requirements and the priority. [This section will need to be further developed.]

CHARGING REQUIREMENT	DESCRIPTION
Downloaded items	User is charged for a specific item downloaded eg a music file, video clip, application
Location based services	User is charged for receiving information on his location (charging based on accuracy as an option). This could be a stand-alone location query or linked to another service
Content accessed or downloaded	User is charged according to the value of the information. E.g. weather information, share price or other financial information
M-Commerce	Electronic transactions to 3rd party suppliers of goods & services
Use of portal or other site	User is charged for any access to a portal or any other site. This could be a one-off charge or based on duration or data volume of the portal or site use
APN and associated content	User is charged for access to a specific APN and for the content associated. Requirements are for further study.
Actual duration of rendered service	User is charged (e.g. for premium rate services or hotline) based on the actual duration of the rendered service

4.3.2 Roaming Charging Requirements

It shall be possible for a network operator to charge its users for activities while roaming. It shall be possible for a network operator to charge its users while roaming using the same principles used while on the home network. The ability to supply all the necessary information for all the charging options will depend on the capability of the visited network.

In addition, the network operators have to charge each other for the use of their networks by roaming users. The methods of charging between operators may be different from the methods used to charge the user. For example, a user may be charged by duration for voice sessions made while roaming but the home network may pay the visited network by volume of data used. Based on preconfiguration or indication from the home network, the serving network may be aware that charging information per individual subscription is not needed. In that case the serving network may omit detailed collection of chargeable events per individual subscription and instead base roaming charging of the home network on optimised collection of chargeable events.

Mechanisms used in today’s networks may also be applied e.g. Inter-Operator Tariff (IOT).

The table below shows the types of charging principle that networks will require for roaming settlement and a priority for its provision.

ITEM	CHARGING METHOD DESCRIPTION
Charging for session use	Sessions made by users while roaming charged according to the principles described in section 4.3.1.1, above. This includes duration and volume charging
Downloaded items	Items downloaded by the user while roaming from providers associated with the visited network are charged back to the home network for onward charge to the user
Location based services	Location information provided by the visited network is charged back to the home network for possible onward charge to the user.
Content accessed or downloaded	Information that is accessed by the user while roaming from providers associated with the visited network is charged according to its value by the visited network back to the home network for onward charge to the user.
M-Commerce	Charging requirements between visited and home networks for M-Commerce transactions made by a roaming user are for further study.
Use of portal or other site	The visited network may charge the home network for any access by the roaming user to a local portal or any other local site. This could be a one-off charge and/or based on duration or data volume of the portal or site use
APN & associated content	Charge by visited network to home network for access to a specific APN and for the content associated. Requirements are for further study.

4.3.3 Interconnect Charging Requirements

This clause applies (but is not limited) to the following interconnection scenarios:

– Interworking between two IMS-based networks

– Interworking between IMS-based networks and PSTN/ISDN

– Interworking between IMS-based networks and TISPAN NGN supporting PES

– IMS transit scenario

The following charging requirements principles and guidelines shall apply for IMS when interconnected to other systems:

– Existing, legacy charging principles will need to be retained while there is a requirement to interwork with non-IP based "circuit switched" type of networks

– All the charging and accounting information shall be collected as closest as possible to the interconnection point (subject to network element performance capabilities).

– A session or a service instance shall be uniquely identified within a network domain to allow a correct accounting and charging.

– The identities of the originating network and of the destination network shall be unique and transported at signalling layer. This applies also to transit scenarios.

– The interconnecting provider(s) will be able to apply Inter Operator Tariff schemes both for offline and online charging.

– Charging information will be available for recording at both ends of interconnected parties. The charging information shall be sufficient to enable inter operator accounting correlation and inter operator dispute resolution. When per individual subscription charging information from the other operator is not needed, interconnect charging may be based on optimised collection of chargeable events.

– The real-time transfer of tariff information in interconnection scenarios shall be supported when the serving network supports it, in order to support value added services that are billed by the caller’s operator (e.g. Premium rate services 0900 or hotlines).

Note: Such services often appear as 3^rd party services where the tariff information resides in the called network and the caller’s operator does not have this information.

– This tariff information must be submitted by the external provider in real-time, so that the caller’s operator is capable of

– providing AoC (Advice of Charge) information to the caller.

– capturing the imported tariff information into charging records.

The service-hosting network shall provide appropriate charging information to the caller’s operator in a secure way, independently from the real-time transfer of charging information for AoC purposes.

Note: Where required to support offline charging for third party services where the tariff information resides in the called network and the caller’s operator needs to bill the end user for that service.

4.3.4 Conveyance & Usage charging requirements

It shall be possible for network operators (including mobile, fixed and IP backbone suppliers) to charge each other for the use of resources required to support user sessions. The items to be charged and the principles to be applied are described below.

The methods of charging between operators could be different from the methods used to charge the user. For example, a user may be charged by duration for voice sessions but the mobile network may pay the fixed network or 3^rd party carrier by volume of data used. When per individual subscription charging information from the other operator is not needed, conveyance and usage charging may be based on optimised collection of chargeable events.

Table 4.3.4-1: Conveyance & Usage charging requirements

ITEM	CHARGING METHOD DESCRIPTION
Session use	Charging according to the resources used by duration of session and/or by data volume
Quality of Service	Charging by QoS delivered to and from the other network

4.3.5 Charging 3^rd parties

It shall be possible for network operators and 3^rd parties to charge each other for the use of their resources. Third parties include content and application providers and portals.

When per individual subscription charging information is not needed, 3rd party charging may be based on on optimised collection of chargeable events.

The items that will be charged and the principles are described below:

Table 4.3.5-1: Charging 3^rd parties

ITEM	CHARGING METHOD DESCRIPTION
Content accessed	The 3rd party charges the end user (via the network operator) for content accessed/downloaded
Access to site	The 3rd party is charged by the network operator for each "hit" by its users
Location information	The 3rd party is charged by the network operator for information on the location of the user. Amount charged could depend on accuracy of location information.
Presence information	The 3rd party is charged by the network operator for presence information about the user.
Pushed information	The 3rd party is charged by the network operator for each message pushed to the user, e.g. advertisements

4.3.6 Advice of Charge (AoC)

The Advice of Charge (AOC) supplementary service allows the served user to be informed of MMTel session related charging information.

AoC information may occur as:

– Advice of Charge for Information purposes (AoCI): This supplementary service provides the information to produce an estimate of the cost of the service used. This means that the displayed value and the cost of the service used (e.g. corresponding bill item) may differ.

– Advice of Charge for Charging purposes (AoCC): This supplementary service provides the means by which the UE may indicate the charge that will be made for the use of MMTel service (i.e. the cost of the service used.)

AoC-information may be sent to the served user at the following phases of communication:

– Charging information at communication set-up time (AOC-S): When the AOC-S supplementary service is activated, the IMS shall provide the user with information about the charging rates at communication establishment. In addition, the IMS may inform the served user at the communication set-up time if a change in charging rates is to take place after the communication set-up.

– Charging information during the communication (AOC-D): After the AOC-D supplementary service is activated, the IMS shall provide the user with charging information for a communication during the active phase of this communication. The supplied charging information shall be provided as a rate of communication service (e.g. costs per minute) or as a cumulative charge incurred so far for the communication (i.e. charges recorded from the start of the communication and until the moment the charging information is sent to the served user), or as charging units. When the call is released, the network shall send the recorded charges for the communication to the served user.

– Charging information at the end of the communication (AOC-E): When the AOC-E supplementary service is activated, the network shall provide the served user with charging information indicating the recorded charges for a communication when this communication is released.

Compatibility with existing, legacy AoC principles from both fixed and mobile networks shall be taken into account. This comprises (but is not limited to) the following requirements for AoC as specified in TS 22.086 [5], ETS 300 178 [6], ETS 300 179 [7], ETS 300 180 [8], TS 183 047 [9] and TS 183 058 [10].

AoC shall be also supported for interconnection scenarios.

4.3.7 Service Aware Charging Requirements

Service Aware Charging provides the means to perform charging based on identified IMS communication service and the service in use.

To facilitate service aware charging, the system shall support the possibility to identify the IMS communication service and the service in use in the charging and accounting data collection.

To ensure that service aware charging can be provided when roaming, the home network shall have the possibility to provide the unequivocally identified IMS communication service to the visited network.

4.4 Additional Charging requirements for prepay services

A prepay service allows a subscriber to pay in advance for the use of specific services, the prepay account will be decreased each time the subscriber uses the services related to that account.

In a multi-service environment like 3GPP system, a subscriber can have different prepay accounts for different kinds of services (e.g. internet access, m-commerce, infotainment, location-based services etc.).

In order to guarantee the use of the prepay services, the following general requirements shall be fulfilled:

– The prepay service shall check a subscriber’s prepay account for coverage of the requested service charges prior to execution of that service.

– All charging information related to a specific prepay account shall be prevented to the user when the prepay credit of that account is exhausted or expired.

– All the ongoing charging information related to a specific prepay account shall be immediately (within a few seconds) interrupted as soon as the prepay credit of that account exhausts or expires.

– The prepay service shall decrease the prepay account each time the subscriber uses the services related to that account.

It should be possible to support more than one prepay account for a user if needed.

To guarantee a meaningful multi-prepay account concept, at least 2 different prepay accounts should be supported.

4.5 QoS and gating based on spending limit

– When the subscriber spending limit has reached a pre-set limit, the system shall be able to trigger a QoS downgrade and/or restrict access to one, several or all IP services based on operator pre-defined thresholds.

Note: A spending limit is the usage limit (e.g. monetary, volume, duration) that a subscriber is allowed to consume.

– When the subscriber spending limit (e.g. monetary, volume, duration) has been increased, the system shall be able to modify resources (e.g. QoS, Bandwidth, access) to services accordingly.

– The home network shall be able to enforce the subscriber spending limits for a roaming subscriber without having dedicated support of the feature in the visited network.

– Additional signalling load should be minimized.

4.6 ProSe Charging Requirements

This section describes the requirements for collecting charging data for ProSe [13]. The requirements also apply in the roaming case.

Online and offline charging shall be supported.

The EPS shall be able to collect charging data for the ability to discover ProSe-enabled UEs served by the E-UTRAN of a different PLMN.

The EPS shall be able to collect charging data for ProSe Discovery features including:

– the ability of a ProSe-enabled UE to be discoverable, including based on the range class;

– the ability to discover other ProSe-enabled UEs, including based on the range class;

– the event of discovering a ProSe-enabled UE, including based on the range class;

– the technology (e.g., E-UTRA or WLAN) that was used for ProSe Discovery.

When a ProSe-enabled UE uses ProSe Communication, or EPC Path established following ProSe Discovery, the 3GPP System shall be able to collect charging data for this communication including its:

– Activation/deactivation;

– Initiation/termination;

– Duration and amount of data transmitted / received;

– QoS, if via E-UTRAN (e.g. levels of availability, allocated resource);

– Inter-operator communication;

– Inter-operator signalling;

– Identification of UEs or groups involved.

Note: This requirement applies to any ProSe E-UTRA Communication between two ProSe-enabled UEs, ProSe Group Communication, ProSe Broadcast Communication and ProSe-assisted WLAN direct communication.

The EPS shall be able to collect charging data for use of ProSe Discovery, ProSe Communication and EPC Path established following ProSe Discovery by an application. This requirement applies to any ProSe E-UTRA Communication between two ProSe-enabled UEs, ProSe Group Communication, ProSe Broadcast Communication and ProSe-assisted WLAN direct communication.

4.7 Unlicensed access requirements

This section describes the requirements for collecting data for usage over unlicensed access. The requirements also apply in the roaming case.

Data collected on usage over unlicensed access shall contain sufficient information for operating purpose (e.g., accounting, charging and charging and network planning).

4.8 Charging Requirements for Indirect 3GPP Communication

This section describes the requirements to enable operator collection of charging data for an Evolved ProSe Remote UE and Relay UE using an Indirect 3GPP Communication. The requirements also apply in the roaming case.

Online and offline charging shall be supported whenever an Evolved ProSe Remote UE using a direct 3GPP communication or an Indirect 3GPP Communication.

The 3GPP core network shall be able to provide charging information for an Evolved ProSe Remote UE using a direct 3GPP communication or an Indirect 3GPP Communication independently of charging data of the other UEs, with following information:

– Initiation/termination;

– Duration and amount of data transmitted / received;

– QoS (e.g. levels of availability, allocated resource);

– Inter-operator communication;

– Inter-operator signalling;

– Identification of UEs involved;

– Identification of RAT involved;

– Timestamp when the connection mode changes.

The 3GPP core network shall be able to provide charging information for an Evolved ProSe Relay UE using a direct 3GPP communication or an Indirect 3GPP Communication independently of charging data of the other UEs, with following information:

– Identification of remote UEs involved;

– Initiation/termination;

– Duration and amount of data transmitted / received;

– QoS (e.g. levels of availability, allocated resource);

– Inter-operator communication;

– Inter-operator signalling;

– Identification of RAT involved;

– Timestamp when the connection mode changes.

The 3GPP core network shall be able to collect charging data for an Evolved ProSe Remote UE which accesses the 3GPP core network through an Indirect 3GPP Communication.

The 3GPP core network shall be able to identify the relayed traffic of an Evolved ProSe UE-to-network Relay, e.g. to be able to apply different rating.