The user's user equipment that is incurring the charge shall provide the following information to the serving network:

• User identity used for authentication;
• Home environment identity;
• Terminal Identity and Terminal Class;
• Destination endpoint identifier for service requested (e.g. B number);
• Resource requested (e.g. bandwidth, connectionless);
• QoS parameters (e.g. maximum delay);
• IP Multimedia capability requested (e.g. media components).

The network serving the user shall provide the following information to the home environment:

• All of the information listed in section above (Information provided by the user);
• Serving network identity;
• Recording network element identity;
• Universal Time (UT) at which the service request was initiated;
• Universal Time (UT) at which resources were provided for the service;
• Universal Time (UT) at which the service execution was successfully completed;
• Universal Time (UT) at which the service execution was unsuccessfully completed;
• Local time of the serving cell when the service request was initiated for the originating or terminating UE. This could either be explicitly reported, or implicitly reported by providing three pieces of information: the UTC, the time zone offset from UTC, and an indication of daylight savings time;
• Cause for unsuccessful completion of the service execution. At least the following causes shall be included:
  • the terminating party does not respond;
  • communication rejected by the terminating party;
  • network determined terminating party busy;
  • network congestion;
  • terminating party non reachable (out of coverage, switched-off);
  • destination non reachable (non active address, non-existing address).
• Resource allocated to the user;
• Quantity of data transferred both to and from the user;
• QoS provided to the user;
• Location of the user in the standard format used for 3GPP location-based services (e.g. geographical
  co-ordinates, Cell ID);
• Network determined PLMN ID and Cell ID;
• whether GSM Optimal Routing was applied;
• If IN or CAMEL services were applied, the service parameters and the actually used destination number and calling party number identification;
• Time duration covered by this charging information to an accuracy of at least 1 second;
• Unique identity of the chargeable event which allows the billing system to correlate all charging information belonging to the same chargeable event;
• Unique charging information identity (unique per network element in a period of about 100 days);
• IP Multimedia capability provided to the user;
• VAS information;
• Identifier of third party accessed by the user;
• Presence Information;
• Service Identification (e.g. voice call, video call, data download etc);
• Supplementary Services used;
• Prepay account identifier and related information.

For subscription related chargeable events the charging information shall indicate the charged party, i.e. normally the calling party. As alternative it should be possible to apply reverse charging or to charge the event to a party not involved in the event itself (e.g. a company as VPN subscriber). It should be possible for multiple leg calls (e.g. forwarded, conference or roamed) to be charged to each party as if each leg was separately initiated. However, in certain types of call, the originating party may wish/be obliged to pay for other legs (e.g. SMS MO may also pay for the MT leg.). It shall be possible to change the chargeable party at the session set-up or during the session. The 3GPP Packet Core network shall allow the 3rd party service provider to request which of the subscriber or the 3rd party service provider (e.g. the sponsor) has to be charged for an ongoing traffic flow in order to allow:

• The subscriber to be charged for the traffic flow,
• The 3rd party service provider to be charged for the traffic flow.

In case of inter-network chargeable events, the charging information usually does not contain the charged party, but it can be derived from network configuration information contained in the charging event data. For each party to be charged for a chargeable event or parts of it charging information shall be collected.

Supply of Value-Added Services, especially in IP based environment, is often made with the aid of third parties typically represented by portals and content/application providers. To execute an effective charging of these services, the following charging information should be provided by the third party:

• Third party identity;
• Type of service (information, entertainment, gaming, public utility);
• Change in the type of service provided to the user;
• Type of content (picture, videoclip, mp3 file, java file);
• Universal Time (UT) at which the service request was initiated;
• If a service change happens, Universal Time (UT) at which the service provision was initiated;
• Universal Time (UT) at which the service execution was successfully completed;
• Universal Time (UT) at which the service execution was unsuccessfully completed;
• Cause for unsuccessful completion of the service execution. At least the following causes shall be included:
  • the terminating party does not respond;
  • communication rejected by the terminating party;
  • network determined terminating party busy;
  • network congestion;
  • terminating party non reachable (out of coverage, switched-off);
  • destination non reachable (non active address, non-existing address).
• Cause for Abnormal reject of the service;
• Universal Time (UT) for abnormal reject of the service

The advent of packet data services, which can extend for very long periods of time (days, weeks etc), although at low cost because charges are based on data throughput, may mean that charging information are only output at the end of very long periods. For this reason, the serving network shall support the transmission of charging information also during the life of the packet data session, either when some charge value is reached or some duration or some data volume or all three, to allow for both charging settlement and cost control.

During one call the user may invoke different services like speech, data transmission, video and audio, which may lead to a separate collection of charging information for each service in different network components. In this case, the billing system shall be able to correlate this charging information and to indicate to the user that they belonged to one call.

Sufficient information about a service change using SCUDIF changing a voice call to a CS multimedia call, or vice versa, shall be collected to enable operators to apply maximum flexibility in charging. This information is collected on top of the data that is already available for the underlying call now subject for the service change. On a service change using SCUDIF the following information shall be collected on both sides of the call:

1. Initiator of the service change (A side or B side)
2. Type of the service change (To speech or to multimedia)
3. For a service change to multimedia: nature of the service change (User or network-initiated service change)

The 3GPP system may be used to trade soft goods (e.g. information, video, audio), or hard goods (e.g. books) of high or low value per item between the user and a merchant. It shall be possible for such merchants to charge users directly for services they provide. Electronic payment mechanisms are or shall be made available through other standards (micropayment, credit card payment, etc), and therefore are outside the scope of this specification 3GPP shall not prohibit the use of these mechanisms, and, where possible, shall provide the basic communications transport to allow them to be used effectively. However, if the serving network acts as merchant of soft goods, it may charge the user directly, collecting the related charging information as described above or using micropayment mechanisms.

It shall be possible to charge for the total volume of data/packets sent and received by the user.

It shall be possible to charge the user for Value Added Services offered by the network in terms of access, surfing, queries etc. irrespectively of the volume of data sent or received by the user.

It shall be possible to charge the usage of IP multimedia service independently of the volume of data sent or received by the user. Information on the IP Multimedia capability provided to the user (e.g. voice, mixture of voice and video component, numbers of parties) should be available in the charging information.

I-WLAN charging issues are captured in TS 22.234.

It shall be possible to charge a service change in case of VAS that foresee different service phases at different tariffs. This applies both at the interconnection between IMS network operators and at the interconnection between IMS network operators and service providers. This information is collected on top of the data that is already available for the underlying communication now subject for the service change.

Detailed requirements for CSG access may be found in TS 22.220. Charging related requirements:

• It shall be possible to charge subscribers for consuming network services via a CSG cell based on the following information:
  • CSG identity of the CSG cell
  • subscriber membership of the CSG
  • type of service consumed by the subscriber
  • addition to and deletion from a CSG
• An operator shall be able to provide applicable tariffing information when a subscriber is added to a CSG.
• The network operator shall be able to charge both on-line and off-line for subscribers consuming network services via a CSG cell.

It shall be possible to charge for Inter-UE Transfer (i.e. transfer/replication/sharing) of media components across multiple IMS UEs.

The network shall be able to apply volume-base charging to a subscriber regardless of whether the subscriber's traffic has been offloaded from the mobile operator's network as described in TS 22.101. For subscribers' traffic offloaded from the mobile operator network, the network shall be able to apply either online or offline charging.

Requirements for IoT resource efficiency for small data transmission can be found in TS 22.278. The 3GPP system shall be able to record charging data for both IP data and non-IP data to/from a UE. The 3GPP system shall be able to record charging data for user plane transfer of small data messages. The 3GPP system shall be able to record charging data for offline charging for control plane transfer of small data messages. At least the following data shall be recorded:

• Non-IP data delivery submission requests in mobile originated and mobile terminated direction;
• Data volume per submission request
• Destination and source information

The 3GPP network shall be able to generate accounting data for TV transport service.

The 3GPP core network shall be able to generate charging information to support accounting between operator and the third party service provider when operators use traffic steering policies to steer traffic to appropriate enablers which are deployed by the third party service provider in (S)Gi-LAN as described in TS 22.101. For service functions which are provided by the operator and the chain of service functions as requested by the third-party service providers, the enhancement of charging aspects is indicated in TS 22.261.

The description of restricted local operator services is contained in TS 22.101. The 3GPP network shall be able to collect charging information regarding the use of restricted local operator services, when available.

Charging information shall identify whether the streaming service as defined in [13] was provided in real time or using delay tolerant delivery. The 3GPP system shall be able to generate and collect the charging data (e.g. the duration of streaming service, the amount of data transferred) for local streaming service. In case of caching of content on a UE, charging information shall be generated when the cached content is consumed by the user.