5.1 CS domain charging principles

32.2503GPPCharging managementCircuit Switched (CS) domain chargingRelease 17Telecommunication managementTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1.0 General

The following high-level requirements summarize the more detailed requirements of TS 22.115 [101].

1. to provide a CDR for all charges incurred and requiring settlement between the different commercial roles;

2. to allow itemized billing for all services (including CAMEL) charged to each subscription, including voice and data calls, and services offered by home environments, taking into account:

– information provided by the user (including authentication parameters, etc.);

– information provided by the serving network (including Serving Network Id, timestamps, etc.);

– information provided by the service (including charged party, long calling, multimedia, etc.).

3. to allow fraud control by the Home Environment and the Serving network.

5.1.1 General aspects of Charging Data

Charging Data Record (CDR) generation and contents should be flexible and unnecessary redundancy in data should be avoided. Charging data are collected for successful and selected unsuccessful subscriber transactions. The subscriber transaction is seen as being successful in the MSC server (where the CDR is generated) either if a call is answered or if the Short Message Service Centre has confirmed the successful receipt of a mobile originated short message.

Unsuccessful call attempts are recorded in the case of partial record generation due to CAMEL FollowOnCalls. If in such a call constellation the answer state is reached at least once, subsequent unsuccessful set-up of a connection configuration is also recorded in order to provide a complete sequence of FIRST, INTERMEDIATE and LAST records.

At termination of the subscriber transaction these data are formatted into CDRs. These records are forwarded onto MSC server’s CGF which constitutes the source for further transportation of that data to the Billing Domain via the Bc reference point, see TS 32.297 [52]. For the purpose of the present document, the CDRs are considered to be collected, in near real-time, by the following network elements: the MSC servers, MGWs, and location registers (VLR/HLR).

The data collected by the network elements are sent to ("pushed"), or collected by ("pulled"), the Billing Domain for storage and further processing. The CDR transfer across the Bc reference point is specified in detail in TS 32.297 [52].

Similarly, the tariff data required by the network elements to provide on-line charging information are distributed by the appropriate management system. This function, however, is outside the scope of 3GPP standardization.

5.1.2 Charging information

5.1.2.0 Introduction

The MSC server and Gateway MSC server are responsible for the collection of all charging relevant information for each MS and PSTN connection and for the storage of this information in the form of CDRs.

Circuit switched calls can be charged in one MSC server (the anchor MSC server) where all relevant data is available. That is guaranteed by routing all signalling information though the anchor MSC server even if the traffic channel of a call is routed through another MSC server due to handover.

The Gateway MSC server acts as a gateway into other PLMNs or fixed networks. Within the PLMN, the GMSC server is responsible for the generation of CDRs for calls routed from or into other networks.

If subscribed CAMEL services apply to MS, the (G)MSC servers contain CAMEL subscription data providing the information required for invocation of the CAMEL dialogues for controlling the MS terminating and MS originating calls. Charging data record parameters resulting from the CAMEL treatment applying to MS calls is derived from the CAMEL subscription data.

In addition to user subscribed services, specific dialled CAMEL services might be invoked which also influence existing records or even trigger the generation of separate records steered by service logic.

Each CDR captures all charging information relevant to the call, or in case of partial CDRs (see clause 5.1.3.6), the portion of a call that the CDR covers. Depending on the type of CDR and the node producing it, this includes information on tele- and bearer services (which may include radio resource usage) and supplementary service invocation / termination. As far as tele- and bearer services are concerned, all service information is embedded in the appropriate CS CDR, i.e. there are no specific "service CDRs" in the CS domain. For Supplementary Services, the exact treatment is specified in clause 5.1.3.3.

In addition to the information collected from the network elements, network management functions are required for the administration of on-line charging data stored in the MSC servers. This data is employed to drive the charge display in the Mobile Station (MS) as required by the Advice of Charge (AoC) service and defined by TS 22.086 [204] and TS 22.024 [203].

In case of ICS will not all supplementary services handled also IMS-AS therefore the MSC server enhanced with ICS can not add the services information to CDR. (new phrase) MSC server will not cover the IMS invoked services

NOTE: Service centralization and continuity charging part is generated at IM subsystem side.

5.1.2.1 Subscriber billing

The charging data collected from the HPLMN, interrogating PLMN, and/or VPLMN network elements is employed to determine the network utilization charges for the basic and supplementary services utilized by the home subscribers of the PLMN. The charges calculated are then combined with the network access (subscription) charges and billed to those customers directly serviced by the PLMN.

For those subscribers handled by Service Providers, the billing information is employed for both wholesale (Network Operator to Service Provider) and retail (Service Provider to Subscriber) billing. Consequently, having been processed by the PLMN Billing System, the charging data collected from the network elements may also be sent to the Service Provider for further processing.

5.1.2.2 Settlements of charges

5.1.2.2.1 Inter-PLMN accounting

Inter-PLMN accounts for roaming traffic are determined in accordance with ITU-T principles (see ITU-T Recommendation D.93 [300]) and are settled by means of the GSM Association’s Transferred Account Procedure (TAP).

5.1.2.2.2 "Visitors" from other PLMNs

The CDRs collected from the network also include details of the services employed by visiting (roaming) subscribers. The charges for Mobile Originated Calls (MOCs) and for supplementary services used are calculated as for home subscribers, converted to an agreed accounting currency and included in the CDRs for the TAP. Even if Mobile Terminated Calls (MTCs) are zero-priced in the visited network (VPLMN), in the absence of "optimized routing" the MTC TAP records are still required by the home network (HPLMN) in order to determine the re-routing charges from the HPLMN to the VPLMN.

The TAP records generated are exchanged with each HPLMN on a regular basis. These TAP records form the basis of the invoice submitted by the VPLMN for the traffic carried.

For traditional CS call, the operator has received all the information from one CDR, MOC or TAP CDR.

After ICS/SRVCC the call is anchored in the home network, part of charging information will be from visited PLMN by TAP CDR and other part of information will be home PLMN directly by IMS CDR.

5.1.2.2.3 "Home" subscribers roaming in other PLMNs

The HPLMN receives TAP records from each VPLMN for services employed by home subscribers whilst roaming. These records are employed to verify the invoices from the VPLMN and to bill the home subscribers for the services used. The charges contained in the TAP records are converted from the accounting currency to the local currency and a handling surcharge (mark-up) is added if required. The TAP records are subsequently passed to the subscriber billing process described in clause 5.1.2.1.

5.1.2.2.4 Settlement with other networks

The settlement of accounts with the operators of other networks (fixed / mobile) for traffic carried, is generally performed on a bulk basis according to the principles outlined in the ITU-T Recommendations D-series.

The traffic accounted for in this manner may include:

– outgoing (Mobile to Mobile/Land) traffic;

– incoming (Land/Mobile to Mobile) traffic;

– transit traffic, carried by intermediate networks;

– signalling (MAP/SCCP, CAP/SCCP) traffic such as location updates.

Accounting information may also be required for the use of services provided by other operators such as short message service centres and other Value Added Service (VAS) providers.

The charges for the various traffic shares may be determined on the basis of the CDRs generated by the network elements or on the basis of bulk counters (accounting meter records) in the gateway MSC servers (GMSC servers). For the purpose of the present document, the management information required is assumed to be derived from CDRs. The management of accounting meters is outside the scope of the present document.

In GSM, the radio resources used for various connection types are roughly identical, hence no differentiation of the connection types is needed for the purpose of inter-network accounting. In UMTS, however, the radio bandwidth allocated to a connection may be much higher compared to GSM, even though the connection looks identical from the perspective of the gateway MSC server. Therefore it is necessary that the gateway CDRs capture the cases where "higher-than-normal" radio bandwidth is occupied. An example of a narrow band radio connection is the standard AMR voice call. An example of a wideband service, using the same landline channel but much more radio resources, is the use of BS30 for video telephony.

Given that – in contrast to the serving MSC server – the gateway MSC server cannot distinguish the cases described above, the serving MSC server is capable of returning information on the bearer capability back to the GMSC server so that this information can be added to the gateway CDR for incoming connections. For further details of this functionality, refer to TS 29.007 [213].

5.1.2.3 Service Information

The charging data collected from the network elements may be used to provide statistical information concerning the use of services, by both home and visiting subscribers, within the network. In addition, the introduction of new services and / or modifications to the tariffs of existing services may also require the distribution of the appropriate tariff information to the network elements for Advice of Charge purposes.

5.1.3 Special cases and considerations

5.1.3.0 General

The following clauses provide detailed consideration on CS domain specific items and topics.

5.1.3.1 AoC service

In addition to the information collected from these Network Elements, network management functions are required for the administration of on-line charging data stored in the MSC server. Two levels of AoC service are available: information level and charging level. The information level is used only to provide AoC information to the user. For the charging level, if no approval of the AoC information by the MS is received in the MSC server, the call is released immediately.

This data is employed to drive the charge display in the Mobile Station (MS) as required by the advice of charge (AoC) service and defined by TS 22.086 [64] and TS 22.024 [63]. Information used by the AoC service shall include a combination of the following:

– one or more basic services; and/or

– one or more supplementary services; and/or

– one or more network specific services; and/or

– one or more power capability classes (MS classmark); and/or

– the type of radio traffic channel used/ requested;

– the transparency mode of the basic service employed (transparent/non-transparent);

– the type of call or connection (e.g. MOC/MTC).

This list may also be extended to include additional network specific parameters.

Parameters sent to the mobile station during the operation of the AoC service are recorded in the appropriate CDRs.

5.1.3.2 CAMEL services

A CAMEL service can be activated for originating, forwarded and terminated calls and originating SMS. Several fields describing CAMEL subscription and free format data are recorded to appropriate CDR. For originating and forwarded calls two different CAMEL services can be active and part of stored information is different depending on the CAMEL call model and which triggers occur. CAMEL fields describing usage level of service, CAMEL modified parameters and CAMEL initiated call forwarding include information for one call leg including impacts on all CAMEL services.

5.1.3.3 Use of supplementary services

The recording of supplementary service usage permits the Billing Domain (BD) to specify the supplementary service actions (invocation, registration, etc.).

In addition to specifying the actions to be recorded, the BD may also determine how these events are to be recorded. Non-call related events, such as the administration of supplementary services by the subscriber via the MMI of the MS, shall result in the production of supplementary service action records. Call related events (e.g. invocation of supplementary services) shall be recorded "in-line" in the appropriate CDR and / or in a separate SS-action record depending on the configuration specified by the BD.

Where the use of a supplementary service results in the production of further connections (e.g. call forwarding, multi‑party service etc.) additional CDRs shall be produced to describe the relevant connections. The use of such services is described in more detail both in this clause and in the example scenarios.

5.1.3.4 Use of call forwarding

When one of the call forwarding services is used, the charging function of the MSC server that forwards the call, shall produce the MOC record for the forwarded part of the call.

For further information concerning the recording of call forwarding services see the example scenarios in clauses 5.2.1.6 and 5.2.1.7.

5.1.3.5 Use of call hold and multi-party services

The use of the call hold service shall be recorded either in-line in the appropriate CDR or in a separate supplementary service "invocation" record as described above. The duration for which the call is held, i.e. is inactive, is not recorded.

The use of the multi-party service requires a minimum of three (3) subscribers and the use of a conference circuit. For the purpose of the following description the subscriber invoking the service is referred to as the conference originator ("A") and the conference call is regarded as consisting of a number of individual "legs" between the conference originator and the other parties ("B", "C", etc.) in the call.

Normal MOC and MTC CDRs shall be generated for each party and each leg of the call. In addition, if common equipment records are enabled, a common equipment record shall be produced for the conference originator in order to record the use of a conference bridge and to record the total duration of the conference connection.

EXAMPLE: Subscriber "C" calls subscriber "A". Subscriber "A" places the call from "C" on hold and makes a second call to subscriber "B". Subscriber "A" then invokes the multi-party service in order to set‑up a conference call with "B" and "C".

Assuming that the appropriate types of record are enabled, the following CDRs shall be produced:

– An MOC record for subscriber "C" and the "C"->"A" leg of the call;

– An MTC record for subscriber "A" and the "C"->"A" leg of the call;

– An MOC record for subscriber "A" and the "A"->"B" leg of the call;

– An SS-Action record for the invocation of the call hold service by subscriber "A";

– An MTC record for subscriber "B" and the "A"->"B" leg of the call;

– An SS-Action record for the invocation of the multi-party service by subscriber "A";

– A common equipment record for the use of the conference bridge by subscriber "A".

Each of the MOC/MTC records for the conference originator ("A") shall include the supplementary service code for the multi-party service.

Any subsequent action affecting only one leg of the connection shall be recorded either in a separate supplementary service action record or in-line in the appropriate CDR. Any action affecting the conference as a whole e.g. the originator holding the conference shall be recorded either in a separate supplementary service action record or in the common equipment usage record.

For further information concerning the recording of multi-party services see the example scenario in clause 5.2.1.9.

5.1.3.6 Partial records

In order to increase the security of the recording process and to simplify post-processing, it may be desirable to generate a sequence of CDRs to describe a single connection or transaction.

In case of connections of extended duration, the loss of a single CDR may result in an unacceptable loss of revenue. If the connection is, for example, recorded in a number of consecutive partial records generated at say hourly intervals, then the maximum loss of revenue is the equivalent of a one hour continuous connection.

Most modern billing systems employ some form of cumulative credit-limit checking based on the stream of input CDRs. If however, a CDR is only produced at the end of the connection then a subscriber may avoid such credit checking by employing a connection for days, weeks or even months without a single CDR being produced.

All of the records defined in the present document are of variable length and some at least are potentially unlimited in size (SET OF, SEQUENCE OF, etc.). However, the storage capacity of the internal records within the network element is normally subject to strict size limitations. Under such conditions a partial record may be required in order to circumvent internal resource limitations. For example, if an internal MOC record can only support the use of four supplementary service invocations then the use of a fifth may result in the generation of a partial record.

Alternatively, for those manufacturers whose systems are based on fixed length records, partial records may be employed instead of the various lists contained within the present document definitions. In such cases a partial record will be produced each time one of the key fields alters during the connection.

Finally, in case of radio link failure and subsequent call re-establishment partial records shall be generated to record the duration of the call prior to the radio link failure and the subsequent duration of the call once the call has been re-established.

To summarize, the following events may result in the generation of a partial record:

– expiry of the partial record timer;

– change of basic service during a connection;

– change of location (MCC+MNC+ LAC or Cell Id. or the Service Access Code, for UMTS) during a connection;

– change of MS classmark during a connection;

– change of AoC Parameters during a call;

– change of Radio Channel Type (full/half rate) during a call;

– radio link failure and subsequent call re-establishment;

– change of HSCSD Parameters (for GSM only) during a call;

– change of CAMEL destination (CAMEL controlled/initiated) during a call;

– CAMEL CPH operations on call legs.

All partial records for the same connection shall contain the same call reference and shall be ordered via a running sequence number. The time stamps involved shall apply to the individual partial records rather than the connection as a whole i.e. the "end" time stamp (duration) of one record shall, in general, coincide with the "start" time stamp (answer time) of the next. Each time a new partial record is created the cause for termination field of the previous record shall contain the value "partial record". The cause for termination of the final partial record shall contain the true cause for termination of the connection.

It should be noted that the records produced in case of call re-establishment are not contiguous and that the value of the cause for term field in the record that is closed on radio link failure contains the value "partial record call re-establishment".

The partial records generated may repeat each of the non-varying fields contained in the original record. Alternatively, a form of reduced partial record may be generated which includes only those fields required to identify the original record together with the field(s) that actually change.

5.1.3.7 Use of circuit-switched data services

If data services are employed in conjunction with a Packet-Switched Public Data Network (PSPDN) then an MOC/MTC CDR may be produced in the originating/terminating MSC server and a gateway record in the gateway/interworking MSC server. If the packet volume is not available within the PLMN then this information may also be provided in the form of a CDR from the PSPDN. In such cases the Billing System is responsible for the correlation of the various records describing the connection. The definition of such PSPDN CDRs is outside the scope of the present document.

5.1.3.8 Inter-MSC server handover

In the case of an inter-MSC server handover the controlling MSC server, as defined by TS 23.009 [65], remains in control of the connection and shall therefore, produce the CDR. For the avoidance of doubt, it is not necessary to produce CDRs in the subsequent MSC server(s).

5.1.3.9 Call re-establishment

In case of radio link failure as described in TS 24.008 [68], the MS may attempt to re-establish the call using the procedures described in TS 24.008 [68].

For the time period between the detection of the radio link failure by the mobile station and the successful re‑establishment of the call, the advice of charge function in the MS is suspended as described in TS 24.086 [222]. In order to minimize the difference in charges between the on-line calculations performed by the MS and the off‑line processing on the basis of the CDRs, it is necessary to exclude the time taken for the re-establishment phase from the chargeable duration stored in the CDRs.

If the re-establishment attempt fails then an ordinary CDR (MOC/MTC) shall be produced with the cause for termination value "stable call abnormal termination". The chargeable duration stored in this record covers the time period from "Answer" to the detection of the radio link failure by the MSC server.

If, the attempt to re-establish the call succeeds then the current CDR shall be closed with the cause for termination value "partial record call re-establishment" and a new partial record shall be opened for the re-established call. The chargeable duration stored in the original record is once again the time period from "answer" to detection of the radio link failure by the MSC server. Both the "seizure" and "answer" times of the subsequent partial record correspond to the time at which the new traffic channel is allocated for the re-established call.

Further radio link failures during the re-established call may result in the generation of additional partial records as described above. All of the partial records belonging to the same connection are identified by the same call reference and a running sequence number.

NOTE: As the MS and MSC server may detect the radio link failure at different points in time, it is not possible to guarantee that the duration used for the AOC display corresponds to that recorded in the CDRs. The purpose of the above procedure is merely to minimize any discrepancies that may occur.

5.1.3.10 Restricted directory numbers

In addition to the information pertaining to the served mobile subscriber (IMSI, MSISDN, etc.), the CDRs defined in the present document also contain the directory numbers of other parties involved in the recorded connections or transactions. In order to comply with data protection legislation, it is necessary to distinguish between those numbers that may be passed on to third parties and those that needs to be handled confidentially. As a result, each of the number fields (e.g. calling/connected number) contains the presentation and screening information defined in both TS 24.008 [68] and ISUP signalling. If this information is supported by the network, then even restricted numbers may be included in the appropriate records and suppressed off-line by the administration or billing system. If this information is not supported then the entire directory number shall be suppressed by the MSC server/VLR.

5.1.3.11 IMEI Observation

In order to provide the data required by the mobile equipment management activities outlined in the previous clauses, the MSC server shall be capable of producing IMEI tickets for each of the following events:

– usage of a blocklisted IMEI;

– usage of a tracklisted IMEI;

– usage of an IMEI not found on the allow list.

An observed IMEI ticket is generated whenever tracklisted, blocklisted or non-allow listed mobile equipment is detected during an IMEI check. The purpose of the ticket is to link the mobile equipment under observation with its current user (IMSI). The ticket also includes information describing when and where the equipment was used to enable the tracking of such equipment. Finally, if the ticket was triggered by a call attempt, a call reference is provided in order to locate the corresponding CDR.

The IMEI tickets are generated by the MSC server performing the IMEI check.

5.1.3.12 Triggers for LCS-MT-CDR, LCS-MO-CDR and LCS-NI-CDR Charging Information Collection

The LCS CDRs (LCS-MT-CDR, LCS-MO-CDR and LCS-NI-CDR) are used to collect charging information related to the LCS features that the PLMN provides in the Packet-Switched domain.

These records include details such as Record Type, Served IMSI, Sequence Number etc. The LCS records are generated based on the following trigger conditions:

– the LCS-MO-CDR, when the MSC receives the RANAP "Location report" message from the RNC;

– the LCS-MT-CDR, when the MSC receives the RANAP "Location report" message from the RNC;

– the LCS-NI-CDR, when the MSC receives the RANAP "Location report" message from the RNC.

5.1.3.13 BS30 Accounting

BS30 is an example where the serving network may use a substantially higher radio bandwidth than for a standard voice call. While the invocation of this service, including the used radio resources, can be captured in the serving MSC server, this is not possible in the GMSC server. However, if the inter-network accounting is done based on GMSC CDRs, this information is needed by the GMSC server in order to provide the required CDR information. To that end, the serving MSC server can provide this information back to the GMSC server. See clause 5.1.2.2.4 for further details.

5.1.3.14 CAMEL Call Party Handling service

The following applies to MSCs that are capable of CAMEL Call Party Handling (CPH):

For calls where CAMEL CPH is involved, one separate record is generated per call segment. The CAMEL CPH service may be applied to originating, forwarded and terminated calls as well as SCP initiated calls.

For MO, MT and CF call attempts, the fields related to the incoming leg are recorded in the main body. The fields related to the outgoing legs of that call segment are recorded in the respective grouped field (CAMEL call leg information) per outgoing leg. User Interactions (UI) are recorded in a separate grouped field like outgoing legs.

Records for gsmSCF initiated call attempts differ to MO, MT and CF records in the following way: no leg information shall be recorded in the main body.

Where the use of CPH result in the creation of further call legs in one call segment, additional grouped fields shall be added to the respective CDR.

Where the use of CPH result in the creation of further call legs in a new call segment, a further CDR shall be generated.

A CDR is closed when the last leg of the call segment disappeared (moved out, disconnected, etc. ) from the call segment.

When a call leg is moved from one call segment to another, the grouped field for that call leg is closed in the respective CDR and a new grouped field is opened in the CDR of the call segment the call leg was moved to.

When the incoming leg (recorded in the main body), is moved from one call segment to another, the grouped field(s) for the outgoing call leg(s) is/are aligned to reflect the new call constellation.

User interactions (announcements etc.) are recorded in the CDR of the related call segment as a separate grouped field similar to call legs.

The leg specific fields listed below shall be recorded in the grouped field ‘CAMEL Call Leg Information’ instead of using the counterpart in the main body. The counterparts of those fields in the main body are maintained for compatibility reasons to earlier releases.

– CAMEL Destination Number

– Translated Number

– Connected Number

– Roaming Number

– Outgoing TKGP (in ‘CAMLEL Call Leg Information’ this item is called
MSC outgoing TKGP)

– Additional Chg. Info

– Default call handling 2

– GsmSCF address 2

– Service key 2

– Free format data 2 (in ‘CAMEL Call Leg Information’ this item is called
Free format data incoming 2)

– Free format data append indicator 2 (in ‘CAMEL Call Leg Information’ this item is called
Free format data append incoming 2)

Editor’s note: both parameters from the second FCI operation should be clarified, also in the CDR table

– Location Routing Number (LRN)

– LRN Source Indicator

– LRN Query Status Indicator

– JIP Parameter

– JIP Source Indicator

– JIP Query Status Indicator

5.1.3.15 Service Change and Fallback

Service Change and UDI/RDI Fallback (SCUDIF) provides the possibility of changing the transport bearer capabilities for circuit switched multimedia applications using 64 kbit/s UDI refer TS 23.172 [209].

It allows users to achieve successful call establishment when end to end circuit-switched (CS) multimedia is not possible (fallback to speech) or when signalling of the feature is not possible in the network (fallback to preferred service). Furthermore, it allows the users to swap between a multimedia service and basic speech during an established call.

SCUDIF functionality encloses two sub-functionalities:

– Service-Change: when two services (multimedia and speech) are available during the active call, users may request a Service-Change to switch between the two services.

– Fallback: when two services (multimedia and speech and visa versa) are proposed but only one of them is available or wanted, only the available service is selected, e.g. fallback from multimedia to speech.

Editor’s note: More details for the charging description are needed.

5.1.3.16 CS Fallback and SMS over SGs

CS Fallback is defined in TS 23.272 [214] and provides a mechanism to move a UE from EUTRAN PS only access to CS to deliver voice service i.e. over GSM or UMTS access. As a result, charging procedures for call handling are performed as per GSM and UMTS access.

Within SMS over SGs also defined in TS 23.272 [214], SMS is delivered in the EUTRAN NAS signalling via the SGs interface between the MME and the MSC/VLR.

5.1.3.17 Enhanced MSC server for SRVCC support

The standard MSC behaviour is enhanced for supporting Single Radio Voice Call Continuity (SRVCC) between E‑UTRAN access and UTRAN/GERAN accesses, between UTRAN (HSPA) access and UTRAN/GERAN accesses, for voice calls and emergency calls anchored in the IMS, as defined in TS 23.216 [215]. Charging is provided from the MSC server enhanced for SRVCC for successful calls/emergency calls transfer.

When session transfer procedure from IMS to CS is performed by MSC server enhanced for SRVCC interfacing IMS through a SIP interface, according to TS 23.237 [223], this MSC server enhanced for SRVCC behaves as an end-point of the IMS domain, and as such, generates an IMS Charging Identifier (ICID) in order to allow correlation. See TS 32.260 [20] for IMS Charging Identifier (ICID) definition.

The Network provided Location information (NetLoc) is described in the TS 23.228 [211] and for emergency service request using PCC-based solutions for the UE location in TS 23.167 [218].

Note: In case of SRVCC the “anchor MSC” is not aware of some relevant call information e.g duration of the whole call, real called_number, because the call previously started on PS side before the transfer to CS-side . Only the IMS Charging is aware of whole duration of the call.

5.1.3.18 Mobile Terminating Roaming Forwarding call after successful Retrieval of Routeing Information (MTRF)

Mobile Terminating Roaming Forwarding call after successful Retrieval of Routeing Information (MTRF) procedure is described in TS 23.018 [216] and provides a mechanism to reroute a terminating call while the called mobile is simultaneously moving from an old to a new MSC/VLR.

The charging procedures for call handling are performed as for a terminating call in the new MSC/VLR to which the call is rerouted. Dedicated charging is provided by the old MSC/VLR from which the call is rerouted as a result of MTRF procedure, in order to complete the set of CDRs produced along the path of the call and avoid charging duplication.

When the terminating call is rerouted towards a new MSC/VLR which is located in a different PLMN than the Old MSC/VLR, a roaming CDR is produced by the Old MSC/VLR, even when the new MSC/VLR resides in HPLMN.

The same charging behaviour applies for Roaming Forwarding for CS Fallback defined in TS 23.272 [214].

5.1.3.19 Enhanced MSC server for ICS support

The standard MSC behaviour is enhanced for supporting ICS for voice/video calls, as defined in TS 23.292 [219]. Charging is provided from the MSC server enhanced for ICS for voice/video call.

When session setup is performed by MSC server enhanced for ICS interfacing IMS through a SIP interface, according to TS 23.292 [219], this MSC server enhanced for ICS behaves as an end-point of the IMS domain, and as such, generates an IMS Charging Identifier (ICID) in order to allow correlation.

Terminating case the IMS Charging Identifier (ICID) may be generated by one IMS network element (e.g. the P-CSCF originating side) and forwarded to another IMS network elements. Enhanced MSC server for ICS receives the ICID by the INVITE from incoming side. The MSC server enhanced for ICS includes the ICID to CDRs for correlation purpose.

In register case the MSC server also generates the Inter Operator Identifier (IOI) for identifiying involved network in a REGISTER-transaction.

In addition to the standard MSC Server behaviour, an MSC Server that has been enhanced for ICS shall provide the User Location Information (e.g. CGI or SAI) and/or UE Time Zone for an identified ICS user as specified in
TS 23.292 [219].

The MSC server shall include the ICID as specified in TS 32.260 [20].