Page History

Add_workflow_for_techpubs

AUTH2
AUTH1
REV5
REV6
REV3
REV1

Panel

In this section:

Table of Contents

maxLevel	4

Info

icon	false

Overview

The

Spacevars

0	series4

supports P-Charging-Vector (PCV) headers as part of P-CSCF functionality. P-Charging-Vector is a collection of charging information, including a globally unique charging identifier (icid-value), that allows carriers to charge for access and services in a network by correlating charging records generated for an IMS by the various network entities involved in the session.

P-Charging-Vector flags:

createPChargingVector at IP Signaling Profile
storePChargingVector at IP Signaling Profile
pChargingVectorHeader transparency flag at IP Signaling Profile
interOperatorId flag at Trunk Group

Include Page

	Transparency_Profile_Note
	Transparency_Profile_Note

A P-CSCF does not transparently pass a P-Charging-Vector header received from UE in any request to IMS core. P-CSCF creates a new P-Charging-Vector header for each request (REGISTER, INVITE, and OOD non-INVITE) containing a unique "icid-value" and "icid-generated-at" parameters and insert the same in the outgoing request towards the core.

The

Spacevars

0	product

retains the same "icid-value" (which is generated during the first egressed INVITE) during the Crankback/Redirected (3xx) call in the P-Charging-Vector header in an egressed INVITE. When the flag storeICID is enabled, all the CDRs (ATTEMPT/START/STOP) contains the same ICID value for Crankback/Redirected call in protocol specific string as well as in the original call records.

This is achieved by:

Disabling pChargingVectorHeader transparency flag at the IP Signaling Profile attached with the TG, towards the IMS Core side.
Enabling createPChargingVector flag at the IP Signaling Profile attached with the TG, towards the IMS Core side.
Disabling storePChargingVector flag at the IP Signaling Profile attached with the TG, towards the UE.

In addition, P-CSCF includes orig-IOI parameter in the newly-created PCV for REGISTER and INVITE messages. The value for orig-IOI parameter is configurable through InterOperatorID parameter from sipTrunkGroup object.

The

Spacevars

0	product

acting as IBCF transparently passes the PCV received in any request from the P-CSCF to the IMS Core. Also, IBCF adds the stored PCV in the response to UE. This is achieved using the following configuration:

Enabling pChargingVectorHeader transparency flag in the IP Signaling Profile attached with the TG, towards the IMS Core side.
Disabling createPChargingVector flag in the IP Signaling Profile attached with the TG, towards the IMS Core side.
Enabling the storePChargingVector flag in the IP Signaling Profile attached with the TG, both towards the UE side and IMS Core side.

SBC Provisioning

When the P-Charging-Vector Header transparency option is selected in the IP Signaling Profile screen, the

Spacevars

0	product

copies the P-Charging-Vector header as-is from the ingress message to the egress message. P-Charging-Vector header transparency is supported in INVITE and REGISTER requests.

When the Create P-Charging-Vector option is selected in the IP Signaling Profile screen, the

Spacevars

0	product

creates a new P-Charging-Vector header in the outgoing message. Creating P-Charging-Vector headers is supported in INVITE, REGISTER, SUBSCRIBE, OPTIONS, NOTIFY, REFER, MESSAGE and PUBLISH messages.

CDR Processing

The

Spacevars

0	product

saves the P-Charging-Vector header with the "icid-value", "icid-generated-at values", and "access-network-charging-info" to the CDR in ingress and egress protocol specific variants fields. P-Charging-Vector headers received or created in INVITE messages are saved to the CDR; P-Charging-Vector header register requests are not saved to the CDR. This is controlled with the “storePChargingVector” flag provisioned from the IP Signaling Profile at ingress or egress side.

Note

If the

Spacevars

0	product

receives the PCV when the storePChargingVector flag is disabled, the

Spacevars

0	product

ignores the PCV and does not log the CDR.

The CLI syntax to enable/disable the createPChargingVector flag for P-CSCF and IBCF is shown below:

Code Block

language	none

% set profiles signaling ipSignalingProfile <profile name towards core> commonIpAttributes flags createPChargingVector <enable | disable>

For populating interOperatorID parameter, use:

Code Block

language	none

% set addressContext default zone defaultSigZone sipTrunkGroup <EGRESS_TG_NAME> signaling interOperatorID <interoperator ID for MGCF>

The CLI syntax to enable/disable pChargingVectorHeader transparency flag for IBCF is shown below:

Code Block

language	none

% set profiles signaling ipSignalingProfile <egress name> commonIpAttributes transparencyFlags pChargingVectorHeader <enable | disable>

The CLI syntax to enable/disable the storePChargingVector flag for P-CSCF and IBCF is shown below:

Code Block

language	none

% set profiles signaling ipSignalingProfile <profile name towards core> commonIpAttributes flags storePChargingVector <enable | disable>

Transit-IOI Handling

A P-Charging-Vector header is used to correlate the charging records generated by different entities on the path of the call. To include the information of the transit carriers for charging purposes, The P-Charging-Vector header can also carry a new parameter transit-IOI, if the transit carriers are involved in a call. The Transit Inter Operator Identifier (Transit-IOI) is shared between sending, transit and receiving networks, service providers, or content providers. The transit-IOI header field parameter is an indexed value that is incremented each time a value is added. If P-Charging-Vector transparency is enabled or create/store P-Charging-Vector is enabled, the

Spacevars

0	product

transparently passes through Transit-IOI values received in P-Charging-Vector header.

Based on local policy, the

Spacevars

0	product

acting as entry or exit IBCF can also be configured to add Transit-IOI in the P-Charging-Vector header in the outgoing requests or responses. To achieve this behavior, Transit-IOI must be configured on the Trunk Group facing the transit network. However, the

Spacevars

0	product

does not support an explicit configuration for the removal of Transit-IOI values in outgoing messages. This can be achieved by using an appropriate SMM rule.

Div

class	excerptdiv

Excerpt
Use the `transitIOI` parameter located under SIP Trunk Group's `signaling` object to populate the specified value in the P-Charging-Vector header. This parameter must be configured on the Trunk Group facing the transit network and the configured value is inserted on the other leg in case of an egress message.

For configuration details, refer to:

Caption

0	Figure
1	Transit-IOI Insertion in P-Charging-Vector Call Flow
3	Transit-IOI Insertion in P-Charging-Vector Call Flow

PCV Interworking Enhancement

The SBC Core includes a signaling profile, NNI Profile, in support of the Inter-IMS Network to Network Interface (II-NNI) and interworking of charging parameters for SIP to/from SIP-I/T/GWGW/ISUP calls. The NNI Profile is attached to a ingress SIP Trunk Group. The following sections describe how the SBC performs SIP to SIP-I and SIP-I to SIP interworking based on the NNI Profile.

Note
The II-NNI standard is commonly used in Japan telecom network.

Note
The maximum number of 32 NNI profiles are supported.

SIP to SIP-I Interworking (Originating Carrier info and Orig-CA Interworking)

The SBC supports the following functionality only when a SIP message containing the "P-Charging-Vector" header is received and processed by the SBC on the SIP side of a SIP to SIP-I/T or a SIP to SIP-GWGW-SIP-I/T/ISUP call.

The following call flows are supported when the call is originated from Mobile SIP side:

Mobile—“SIP”—SBC — “GWGW”—GSX —“ISUP”— PSTN
Mobile—“SIP"—SBC—“GWGW”—SBC—“SIP-I/T”—C5IMS
Mobile—“SIP”—SBC—“SIP-I/T”—C5IM
Mobile—“SIP”—SBC—“GWGW”—SBC—Other Carrier

When an NNI Profile is configured for a SIP Trunk Group and the SBC receives INVITE messages with P-Charging-Vector header (which contains ttc-charging-parameter) for this SIP Trunk Group, the SBC does not send these parameters as part of "P-Charging-Vector" header on the other side.

chargeAreaInformation (CAI)

If the received ttc-charging-parameter contains chargeAreaInformation (CAI) sub-parameter, the SBC includes the received CAI value in the policy request message towards PSX and also sends it in the ISUP IAM message body (as Message-Area-Information parameter - parameter code = 253) of SIP-I/T or over GW-GW message.

If the received ttc-charging-parameter does not contain CAI sub-parameter but configured it under NNI profile, the SBC includes the configured CAI value in the policy request message towards PSX and also sends it in the ISUP IAM message body (as Message-Area-Information parameter - parameter code = 253) of SIP-I/T or over GW-GW message.

carrierInformationTransfer (CARI)

If the received ttc-charging-parameter contains carrierInformationTransfer (CARI) sub-parameter with the category as "olec", the SBC includes the received CARI values in the policy request message towards PSX and also sends it in the ISUP IAM message body (as Carrier-Information-Transfer parameter - parameter code = 241) of SIP-I/T or over GW-GW message.

If the received ttc-charging-parameter does not contain (CARI) sub-parameter (or) received CARI value other than cat-olec and CARI value is configured in the NNI profile, SBC includes the configured CARI value in the policy request message towards PSX and also sends it in the ISUP IAM message body (as Carrier-Information-Transfer parameter - parameter code = 241) of SIP-I/T or over GW-GW message.

AdditionalPartyCategory (AUC)

If the received ttc-charging-parameter contains Additional Party category (AUC) values (additionalPartyCategoryFirst/Second), the SBC does not honor the received values. If additionalPartyCategoryFirst and additionalPartyCategorySecond values are configured under NNI Profile, the SBC sends it in the ISUP IAM message body (as ISUP Supplementary User Type parameter - parameter code = 243) of SIP-I/T or over GW-GW message.

ForwardCallIndicator (FCI)

If the received ttc-charging-parameter contains forwardCallIndicator (FCI)(both nationalCallIndicator and originatingIsdnIndicator values), the SBC includes the configured FCI values in the policy request message towards PSX and also sends it in the ISUP IAM message body (as part of ISUP Forward Call Indicator parameter) of SIP-I/T or over GW-GW message.

The SBC behavior when receiving "P-charging-vector" headers and carrierInformationTransfer parameters is explained in the following table.

Example

Code Block

ChargeAreaInformation:

P-Charging-Vector: icicd-value=ABC;icid-generated-at=DEF;orig-ioi=GHI;ttc-charging-params="cai=32000"

Carrier information transfer as:

P-Charging-Vector: icicd-value=ABC;icid-generated-at=DEF;orig-ioi=GHI;ttc-charging-params="cai=32000;cari=iecind-3,cat-olec,code-0901"

Additional party category as:

P-Charging-Vector: icicd-value=ABC;icid-generated-at=DEF;orig-ioi=GHI;ttc-charging-params="cai=32000;cari=iecind-3,cat-olec,code-0901;auc=mobile_2-3;auc=fixed-1-2"

Forward Call Indicators as:

P-Charging-Vector: icicd-value=ABC;icid-generated-at=DEF;orig-ioi=GHI;ttc-charging-params="cai=32000;cari=iecind-3,cat-olec,code-0901;auc=mobile_2-3;auc=fixed-1-2;fci=nii-nat,oa-isdn"

Caption

0	Table
1	SBC handling of P-charging-vector headers using NNI Profile
3	SBC handling of P-charging-vector headers using NNI Profile

Conditions Result

The SBC receives:
- P-charging-vector header
- carrierInformationTransfer parameters
The carrierInformationTransfer parameter contains "olec" category

The SBC takes the following actions:

Sets the value of carrierInformationTransfer as “iecind-3” (originating network).
Adds the parameters carrierCategory and carrierInfo and populates carrierInformationTransfer category as "olec". The SBC then sends carrierInformationTransfer to the PSX and in the ISUP IAM message body of SIP-I/T or over GW-GW message.
Populates carrierIdCode as follows:
- If received in a message (as part of "olec" category), populate using received value.
- If carrierIdCode is not received, the SBC populates it using the configured value from carrierCategoryAndInfo for olec data.
- If neither received nor configured on Trunk Group, the SBC terminates further processing and does not interwork with carrierInformationTransfer parameter.

The SBC receives:
- P-charging-vector header
The SBC does not receive carrierInformationTransfer parameters, or
carrierInformationTransfer parameter does not contain "olec" category

The SBC takes the following actions:

Sets the value of carrierInformationTransfer to “iecind-3” (originating network).
Adds the parameters carrierCategory and carrierInfo and populates carrierInformationTransfer category as "olec". The SBC then sends the carrierInformationTransfer to the PSX and in the ISUP IAM message body of SIP-I/T or over GW-GW message as per existing functionality.
Populates carrierIdCode as configured value.

`SIP-I to SIP Interworking (Terminating Carrier info and Term-CA Interworking)`

If the parameter chargeAreaInformation is received by the SBC from SIP-I/T side with either of ACM/CPG/ANM ISUP message body or over GW-GW message, the SBC uses it to populate the parameter chargeAreaInformation (of "P-Charging-Vector" header) and sends it in a SIP message as per existing functionality.

If the parameter carrierInformationTransfer is received by the SBC from SIP-I/T side with either of ACM/CPG ISUP message body or over GW-GW message and the parameter contains carrierCategory as "tlec", the SBC processes the parameter as follows:

Sets the value of Transit Carrier Indicator to “iecind-0” (terminating network).
Adds the parameters carrierCategory and carrierInfo, and populates carrierInformationTransfer category as "tlec". If the parameter carrierInformationTransfer does not contain "tlec", the carrierInformationTransfer of "P-Charging-Vector" header must not be set.
Sends the parameter carrierInformationTransfer in "P-Charging-Vector" header in a SIP message.

If the parameters additionalPartyCategoryFirst/Second are received by the SBC from SIP-I/T side with either ACM/CPG/ANM/CON ISUP message body or received over GW-GW message, the SBC uses them to populate additionalPartyCategoryFirst/Second parameters of "P-Charging-Vector" header and send them in a SIP message.

Pagebreak

Space shortcuts

Page tree

Versions Compared

Old Version 7

New Version 8

Key

Overview

SBC Provisioning

CDR Processing

Transit-IOI Handling

PCV Interworking Enhancement

SIP to SIP-I Interworking (Originating Carrier info and Orig-CA Interworking)

`SIP-I to SIP Interworking (Terminating Carrier info and Term-CA Interworking)`