Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 24.229  Word version:  18.4.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.5…   5…   5.1.1.4…   5.1.2…   5.1.4…   5.2…   5.2.3…   5.2.6…   5.2.7…   5.3…   5.4…   5.4.1.2.2…   5.4.1.3…   5.4.2   5.4.3…   5.4.3.3…   5.4.4…   5.5…   5.7…   5.7.2…   5.8…   5.11…   6…   6.6…   7…   7.2A…   7.2A.6…   7.3…   7.9A…   8…   A…   A.2…   A.2.1.4…   A.2.1.4.7…   A.2.1.4.8…   A.2.1.4.10A…   A.2.1.4.12…   A.2.2…   A.2.2.4…   A.2.2.4.7…   A.2.2.4.8…   A.2.2.4.10A…   A.2.2.4.12…   A.3…   A.3.3…   B…   C…   E…   F…   H…   I…   K…   L…   L.2A…   M…   N…   O…   Q…   R…   S…   U…   U.2A…   V…   W… 
7.2A Extensions to SIP header fields defined within the present document  7.2A.1 Extension to WWW-Authenticate header field  7.2A.2 Extension to Authorization header field  7.2A.3 Tokenized-by header field parameter definition (various header fields)  7.2A.4 P-Access-Network-Info header field  7.2A.5 P-Charging-Vector header field 
...

 

7.2A  Extensions to SIP header fields defined within the present document  p. 430

7.2A.1  Extension to WWW-Authenticate header field  p. 430

7.2A.1.1  Introduction  p. 430

This extension defines a new authentication parameter (auth-param) for the WWW-Authenticate header field used in a 401 (Unauthorized) response to the REGISTER request. For more information, see Section 11.3 of RFC 9110 and Appendix A of RFC 9110.

7.2A.1.2  Syntax  p. 430

The syntax for for auth-param is specified in Table 7.2A.1.

7.2A.1.3  Operation  p. 430

This authentication parameter will be used in a 401 (Unauthorized) response in the WWW-Authenticate header field during UE authentication procedure as specified in subclause 5.4.1.
The S-CSCF appends the integrity-key parameter (directive) to the WWW.-Authenticate header field in a 401 (Unauthorized) response. The P-CSCF stores the integrity-key value and removes the integrity-key parameter from the header field prior to forwarding the response to the UE.
The S-CSCF appends the cipher-key parameter (directive) to the WWW-Authenticate header field in a 401 (Unauthorized) response. The P-CSCF removes the cipher-key parameter from the header field prior to forwarding the response to the UE. In the case ciphering is used, the P-CSCF stores the cipher-key value.
Up

7.2A.2  Extension to Authorization header field  p. 430

7.2A.2.1  Introduction  p. 430

This extension defines new dig-resp parameters for the Authorization header field used in REGISTER requests. For more information, see Section 11.3 of RFC 9110 and Appendix A of RFC 9110.

7.2A.2.2  Syntax  p. 430

7.2A.2.2.1  integrity-protected |R12|  p. 430
The syntax of integrity-protected for the Authorization header field is specified in Table 7.2A.2.
Up

7.2A.2.3  Operation  p. 431

This authentication parameter is inserted in the Authorization header field of all the REGISTER requests. The value of the "integrity-protected" header field parameter in the auth-param parameter is set as specified in subclause 5.2.2. This information is used by S-CSCF to decide whether to challenge the REGISTER request or not, as specified in subclause 5.4.1.
The values in the "integrity-protected" header field field are defined as follows:
"yes":
indicates that a REGISTER request received in the P-CSCF is protected using an IPsec security association and IMS AKA is used as authentication scheme.
"no":
indicates that a REGISTER request received in the P-CSCF is not protected using an IPsec security association and IMS AKA is used as authentication scheme, i.e. this is an initial REGISTER request with the Authorization header field not containing a challenge response.
"tls-yes":
indicates that a REGISTER request is received in the P-CSCF protected over a TLS connection and the Session ID, IP address and port for the TLS connection are already bound to a private user identity. The S-CSCF will decide whether or not to challenge such a REGISTER request based on its policy. This is used in case of SIP digest with TLS.
"tls-pending":
indicates that a REGISTER request is received in the P-CSCF protected over a TLS connection and the Session ID, IP address and port for the TLS connection are not yet bound to a private user identity. The S-CSCF shall challenge such a REGISTER request if it does not contain an Authorization header field with a challenge response or if the verification of the challenge response fails. This is used in case of SIP digest with TLS.
"ip-assoc-yes":
indicates that a REGISTER request received in the P-CSCF does map to an existing IP association in case SIP digest without TLS is used.
"ip-assoc-pending":
indicates that a REGISTER request received in the P-CSCF does not map to an existing IP association, and does contain a challenge response in case SIP digest without TLS is used.
"auth-done":
indicates that a REGISTER request is sent from an entity that is trusted and has authenticated the identities used in the REGISTER request. An example for such an entity is the MSC server enhanced for IMS centralized services. The S-CSCF shall skip authentication.
"tls-connected":
indicates that a REGISTER request received in the eP-CSCF is issued by a UE over a TLS session established prior to the registration and IMS AKAv2 is used as authentication scheme. This integrity-protected flag value is used for example in case of WebRTC over IMS when the Authentication is IMS-AKA as defined in TS 24.371.
Up

7.2A.3  Tokenized-by header field parameter definition (various header fields)  p. 432

7.2A.3.1  Introduction  p. 432

The "tokenized-by" header field parameter is an extension parameter appended to encrypted entries in various SIP header fields as defined in subclause 5.10.4.

7.2A.3.2  Syntax  p. 432

The syntax for the "tokenized-by" header field parameter is specified in Table 7.2A.3:
The BNF for rr-param and via-params is taken from RFC 3261 and modified accordingly.
Up

7.2A.3.3  Operation  p. 432

The "tokenized-by" header field parameter is appended by IBCF (THIG) after all encrypted strings within SIP header fields when network configuration hiding is active. The value of the header field parameter is the domain name of the network which encrypts the information.

7.2A.4  P-Access-Network-Info header field  p. 432

7.2A.4.1  Introduction  p. 432

The P-Access-Network-Info header field is extended to include specific information relating to particular access technologies.

7.2A.4.2  Syntax  p. 432

The syntax of the P-Access-Network-Info header field is described in RFC 7315 and RFC 7913. There are additional coding rules for this header field depending on the type of IP-CAN, according to access technology specific descriptions.
Table 7.2A.4 describes the 3GPP-specific extended syntax of the P-Access-Network-Info header field defined in RFC 7315 and RFC 7913.
The daylight-saving-time and the UE-local-IP-address are instances of generic-param from the current extension-access-info component of the P-Access-Network-Info header field defined in RFC 7315 and RFC 7913.
The presence of the "network-provided" header field parameter defined in RFC 7315 indicates a P-Access-Network-Info header field is provided by the P-CSCF, S-CSCF, the AS, the MSC server enhanced for ICS, the MSC server enhanced for SRVCC using SIP interface, the MSC server enhanced for DRVCC using SIP interface or by the MGCF. The content can differ from a P-Access-Network-Info header field without this parameter which is provided by the UE.
The "network-provided" header field parameter can be used with both "access-type" and "access-class" constructs. The "access-class" construct is provided for use where the value is not known to be specific to a particular "access-type" value, e.g. in the case of some values delivered from the PCRF. The "access-class" field can be set only by the P-CSCF, the MSC server enhanced for ICS, the MSC server enhanced for SRVCC using SIP interface, the MSC server enhanced for DRVCC using SIP interface or by the AS. The "network-provided" header field parameter can be set only by the P-CSCF, S-CSCF, the AS, the MSC server enhanced for ICS, the MSC server enhanced for SRVCC using SIP interface, the MSC server enhanced for DRVCC using SIP interface or by the MGCF. The "local-time-zone" parameter, the "daylight-saving-time" parameter, the "gstn-location" parameter, the "GSTN" value of access-type field and the "untrusted-non-3GPP-VIRTUAL-EPC" value of access-class field shall not be inserted by the UE.
The "local-time-zone" parameter defined in RFC 7315 indicates the time difference between local time and UTC of day. For 3GPP accesses, the "local-time-zone" parameter represents the time zone allocated to the routing area or traffic area which the UE is currently using. As the edge of such areas may overlap, there can be some discrepancy with the actual time zone of the UE where the UE is in the near proximity to a time zone boundary.
The "daylight-saving-time" parameter indicates by how much the local time of the UE has been adjusted due to the use of daylight saving time. Providing the "daylight-saving-time" parameter is optional.
The "UE-local-IP-address" parameter indicates the UE local IP address.
The "UDP-source-port" parameter indicates that the IKEv2 messages exchanged between the UE and the ePDG are encapsulated in the UDP messages according to RFC 3948. The value of the "UDP-source-port" parameter is the UDP source port of the UDP messages:
  • received by the ePDG; and
  • encapsulating the IKEv2 messages.
The "TCP-source-port" parameter indicates that the IKEv2 messages exchanged between the UE and the ePDG are transported using the firewall traversal tunnel as described in TS 24.302. The value of the "TCP-source-port" parameter is the TCP source port of the TCP messages:
  • received by the ePDG; and
  • of the firewall traversal tunnel transporting the IKEv2 messages.
The "ePDG-IP-address" parameter indicates the ePDG IP address used as IKEv2 tunnel endpoint with the UE.
The "eps-fallback" header field parameter is used to indicate that the current access technology is used as a result of EPS fallback. The value "1" indicates that EPS fallback has occurred, the value "0" that EPS fallback has not occurred. The parameter can be set only by the P-CSCF.
Up

7.2A.4.3  Additional coding rules for P-Access-Network-Info header field  p. 433

The P-Access-Network-Info header field is populated with the following contents:
1)
the access-type field set to one of "3GPP-GERAN","3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD", "3GPP-E-UTRAN-FDD", "3GPP-E-UTRAN-TDD", "3GPP-E-UTRAN-ProSe-UNR", "3GPP-NR-FDD", "3GPP-NR-TDD", "3GPP-NR-U-FDD", "3GPP-NR-U-TDD", "3GPP-NR-SAT", "3GPP-NR-ProSe-L2UNR", "3GPP-NR-ProSe-L3UNR", "3GPP2-1X", "3GPP2-1X-HRPD", "3GPP2-UMB", "3GPP2-1X-Femto", "IEEE-802.11", "IEEE-802.11a", "IEEE-802.11b", "IEEE-802.11g", "IEEE-802.11n", "IEEE-802.11ac", "ADSL", "ADSL2", "ADSL2+", "RADSL", "SDSL", "HDSL", "HDSL2", "G.SHDSL", "VDSL", "IDSL", "xDSL", "DOCSIS", "IEEE-802.3", "IEEE-802.3a", "IEEE-802.3e", "IEEE-802.3i", "IEEE-802.3j", "IEEE-802.3u", "IEEE-802.3ab", "IEEE-802.3ae", "IEEE-802.3ah", "IEEE-802.3ak", "IEEE-802.3aq", "IEEE-802.3an", "IEEE-802.3y", "IEEE-802.3z", or "DVB-RCS2" as appropriate to the access technology in use.
1A)
the access-class field set to one of "3GPP-GERAN", "3GPP-UTRAN", "3GPP-E-UTRAN", "3GPP-NR", "3GPP-NR-U", "3GPP-NR-SAT", "3GPP-WLAN", "3GPP-GAN", "3GPP-HSPA", "3GPP2", "untrusted-non-3GPP-VIRTUAL-EPC", "VIRTUAL-no-PS", or "WLAN-no-PS" as appropriate to the technology in use. The access-class field set to "untrusted-non-3GPP-VIRTUAL-EPC" indicates the IP-CAN associated with an EPC based untrusted non-3GPP access with unknown radio access technology. The access-class field set to "VIRTUAL-no-PS" indicates an IP-CAN associated with an unknown radio access technology, such that the IP-CAN is not provided by the packet switched domain of the PLMN of the P-CSCF. The access-class field set to "WLAN-no-PS" indicates an IP-CAN associated with WLAN, such that the IP-CAN is not provided by the packet switched domain of the PLMN of the P-CSCF. The access-class field set to "3GPP-NR-SAT " indicates an IP-CAN associated with satellite NG-RAN.
2)
if the access-type field or the access-class field is set to "3GPP-GERAN", a cgi-3gpp parameter set to the Cell Global Identity obtained from lower layers of the UE. The Cell Global Identity is a concatenation of MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), LAC (4 hexadeciaml digits) and CI (as described in TS 23.003. The "cgi-3gpp" parameter is encoded in ASCII as defined in RFC 20;
3)
if the access-type field is equal to "3GPP-UTRAN-FDD", or "3GPP-UTRAN-TDD", and a UE provides the P-Acces-Network-Info header field, a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), LAC (4 hexadecimal digits) as described in TS 23.003 and the UMTS Cell Identity (7 hexadecimal digits) as described in TS 25.331), obtained from lower layers of the UE. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20;
3A)
if the access-type field is equal to "3GPP-UTRAN-FDD", or "3GPP-UTRAN-TDD", and an entitiy that can use the "network-provided" header field parameter provides the P-Access-Network-Info header field, if available a "utran-sai-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), LAC (4 hexadecimal digits) as described in TS 23.003 and SAC (4 hexadecimal digits) as described in TS 23.003. The "utran-sai-3gpp" parameter is encoded in ASCII as defined in RFC 20;
3B)
if the access-class field is equal to "3GPP-UTRAN", or "3GPP-HSPA", if available a "utran-sai-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), LAC (4 hexadecimal digits) as described in TS 23.003 and SAC (4 hexadecimal digits) as described in TS 23.003. The "utran-sai-3gpp" parameter is encoded in ASCII as defined in RFC 20;
4)
void
5)
if the access-type field is set to "3GPP2-1X", a ci-3gpp2 parameter set to the ASCII representation of the hexadecimal value of the string obtained by the concatenation of SID (16 bits), NID (16 bits), PZID (8 bits) and BASE_ID (16 bits) (see 3GPP2 C.S0005-D [85]) in the specified order. The length of the ci-3gpp2 parameter shall be 14 hexadecimal characters. The hexadecimal characters (A through F) shall be coded using the uppercase ASCII characters. If the UE does not know the values for any of the above parameters, the UE shall use the value of 0 for that parameter. For example, if the SID is unknown, the UE shall represent the SID as 0x0000;
EXAMPLE:
If SID = 0x1234, NID = 0x5678, PZID = 0x12, BASE_ID = 0xFFFF, the ci-3gpp2 value is set to the string "1234567812FFFF".
6)
if the access-type field is set to "3GPP2-1X-HRPD", a ci-3gpp2 parameter set to the ASCII representation of the hexadecimal value of the string obtained by the concatenation of Sector ID (128 bits) and Subnet length (8 bits) (see 3GPP2 C.S0024-B [86]) and Carrier-ID, if available, (see 3GPP2 X.S0060 [86B])in the specified order. The length of the ci-3gpp2 parameter shall be 34 or 40 hexadecimal characters depending on whether the Carrier-ID is included. The hexadecimal characters (A through F) shall be coded using the uppercase ASCII characters;
EXAMPLE:
If the Sector ID = 0x12341234123412341234123412341234, Subnet length = 0x11, and the Carrier-ID=0x555444, the ci-3gpp2 value is set to the string "1234123412341234123412341234123411555444".
7)
if the access-type field is set to "3GPP2-UMB" 3GPP2 C.S0084-000 [86A], a ci-3gpp2 parameter is set to the ASCII representation of the hexadecimal value of the Sector ID (128 bits) defined in 3GPP2 C.S0084-000 [86A]. The length of the ci-3gpp2 parameter shall be 32 hexadecimal characters. The hexadecimal characters (A through F) shall be coded using the uppercase ASCII characters;
EXAMPLE:
If the Sector ID = 0x12341234123412341234123412341234, the ci-3gpp2 value is set to the string "12341234123412341234123412341234".
8)
if the access-type field set to one of "IEEE-802.11", "IEEE-802.11a", "IEEE-802.11b", "IEEE-802.11g", "IEEE-802.11n", or "IEEE-802.11ac", an "i-wlan-node-id" parameter is set to the ASCII representation of the hexadecimal value of the AP's MAC address without any delimiting characters;
EXAMPLE:
If the AP's MAC address = 00-0C-F1-12-60-28, then i-wlan-node-id is set to the string "000cf1126028".
9)
if the access-type field is set to "3GPP2-1X-Femto", a ci-3gpp2-femto parameter set to the ASCII representation of the hexadecimal value of the string obtained by the concatenation of femto MSCID (24 bit), femto CellID (16 bit), FEID (64bit), macro MSCID (24 bits) and macro CellID (16 bits) (3GPP2 X.P0059-200 [86E]) in the specified order. The length of the ci-3gpp2-femto parameter is 36 hexadecimal characters. The hexadecimal characters (A through F) are coded using the uppercase ASCII characters.
10)
if the access-type field is set to one of "ADSL", "ADSL2", "ADSL2+", "RADSL", "SDSL", "HDSL", "HDSL2", "G.SHDSL", "VDSL", "IDSL", or "xDSL", the access-info field shall contain a dsl-location parameter obtained from the CLF (see NASS functional architecture);
11)
if the access-type field set to "DOCSIS", the access info parameter is not inserted. This release of this specification does not define values for use in this parameter;
12)
if the access-type field is equal to "3GPP-E-UTRAN-FDD" or "3GPP-E-UTRAN-TDD", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value) which should be obtained from the E-UTRAN Cell Global Identifier (ECGI), Tracking Area Code (4 hexadecimal digits when accessing to EPC and 6 hexadecimal digits when accessing to 5GCN) as described in TS 23.003 and the E-UTRAN Cell Identity (ECI) (7 hexadecimal digits) as described in TS 23.003. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20;
EXAMPLE: If MCC is 111, MNC is 22, TAC is 33C4 and ECI is 76B4321, then P-Access-Network-Info header field looks like follows: P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=1112233C476B4321;network-provided
12A)
if the access-class field is equal to "3GPP-E-UTRAN", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value) which should be obtained from the E-UTRAN Cell Global Identifier (ECGI), Tracking Area Code (4 hexadecimal digits when accessing to EPC and 6 hexadecimal digits when accessing to 5GCN) as described in TS 23.003 and the E-UTRAN Cell Identity (ECI) (7 hexadecimal digits) as described in TS 23.003. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20;
12B)
if the access-type field is equal to "3GPP-E-UTRAN-ProSe-UNR", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value) which should be obtained from the E-UTRAN Cell Global Identifier (ECGI) and the E-UTRAN Cell Identity (ECI) (7 hexadecimal digits) as described in TS 23.003 obtained from the ProSe-UE-to-network relay that the UE is connected to as specified in TS 24.334. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in in RFC 20;
EXAMPLE:
If MCC is 111, MNC is 22 and ECI is 76B4321, then P-Access-Network-Info header field looks like follows: P-Access-Network-Info: 3GPP-E-UTRAN-ProSe-UNR;utran-cell-id-3gpp=1112276B4321.
12C)
if the access-type field is equal to "3GPP-E-UTRAN-FDD" or "3GPP-E-UTRAN-TDD", an "eps-fallback" header field parameter set to an appropriate value;
12D)
if the access-class field is equal to "3GPP-E-UTRAN", an "eps-fallback" header field parameter set to an appropriate value;
13)
if the access-type field is set to one of "IEEE-802.3", "IEEE-802.3a", "IEEE-802.3e", "IEEE-802.3i", "IEEE-802.3j", "IEEE-802.3u", "IEEE-802.3ab", "IEEE-802.3ae", IEEE-802.3ak", IEEE-802.3aq", "IEEE-802.3an", "IEEE-802.3y" or "IEEE-802.3z" and NASS subsystem is used, the access-info field shall contain an eth-location parameter obtained from the CLF (see NASS functional architecture);
14)
if the access-type field is set to one of "GPON", "XGPON1" or "IEEE-802.3ah" and NASS is used, the access-info field shall contain an fiber-location parameter obtained from the CLF (see NASS functional architecture);
15)
if the access-type field is set to "GSTN", the access-info field may contain a gstn-location parameter if received from the GSTN;
16)
if the access-type field is set to "DVB-RCS2", the access-info field shall contain a "dvb-rcs2-node-id" parameter which consists of comma-separated list consisting of NCC_ID, satellite_ID, beam_ID, and SVN-MAC as specified in ETSI TS 101 545-2 [194], ETSI TS 101 545-3 [195]; the NCC_ID shall be represented as two digit hexadecimal value, the satellite_ID shall be represented as a two digit hexadecimal value, the beam_ID shall be respresented as a four digit hexadecimal value, and the SVN-MAC shall be represented as six digit hexadecimal value;
EXAMPLE:
If the (8 bit) NCC_ID = 0x3A, the (8 bit) satellite_ID = 0xF5, the (16 bit) beam_ID = 0xEA23, and the (24 bit) SVN-MAC = 0xE40AB9, then the "dvb-rcs2-node-id" is set to the string "3A,F5,EA23,E40AB9".
17)
the "local-time-zone" parameter in the access-info field is coded as a text string as follows:
UTC±[hh]:[mm]. [hh] is two digits, and [mm] is two digits from four values: "00", "15", "30" or "45", see ISO 8601 [203];
EXAMPLE:
"UTC+01:00" indicates that the time difference between local time and UTC of day is one hour.
18)
the "daylight-saving-time" parameter in the access-info field is coded as a text string as follows:
[hh]. [hh] is a two digits value from three values "00", "01" or "02" indicating the positive adjustment in hours;
19)
void;
20)
the operator-specific-GI in the access-info field is coded as a text string and conveys an operator-specifc geographical identifier;
21)
if
  1. the access-class field is set to "untrusted-non-3GPP-VIRTUAL-EPC"; or
  2. the access-class field is set to "3GPP-WLAN" and the WLAN is an untrusted WLAN;
then:
  1. if a UE local IP address is available, then a "UE-local-IP-address" parameter set to the UE local IP address;
  2. if the IKEv2 messages exchanged between the UE and the ePDG are encapsulated in the UDP messages according to RFC 3948 and the UDP source port of the UDP messages received by ePDG is available, then a "UDP-source-port" parameter set to the UDP source port of the UDP messages:
    • received by the ePDG; and
    • encapsulating the IKEv2 messages;
  3. if the IKEv2 messages exchanged between the UE and the ePDG are transported using the firewall traversal tunnel as described in TS 24.302 and the TCP source port of the TCP messages of the firewall traversal tunnel received by ePDG is available, then a "TCP-source-port" parameter set to the TCP source port of the TCP messages:
    • received by the ePDG; and
    • of the firewall traversal tunnel transporting the IKEv2 messages; and
  4. if an ePDG IP address used as IKEv2 tunnel endpoint with the UE is available, then an "ePDG-IP-address" parameter set to the ePDG IP address used as IKEv2 tunnel endpoint with the UE;
22)
if the access-type field is equal to "3GPP-NR-FDD" or "3GPP-NR-TDD", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), Tracking Area Code (6 hexadecimal digits) as described in TS 23.003, the NR Cell Identity (NCI) (9 hexadecimal digits) and optionally, the Network Identifier (NID) (11 hexadecimal digits) as specified in TS 23.003. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20; and
22A)
if the access-class field is equal to "3GPP-NR", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), Tracking Area Code (6 hexadecimal digits) as described in TS 23.003, the NR Cell Identity (NCI) (9 hexadecimal digits) and optionally, the NID (11 hexadecimal digits) as specified in TS 23.003. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20.
23)
if the access-type field is equal to "3GPP-NR-U-FDD" or "3GPP-NR-U-TDD", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), Tracking Area Code (6 hexadecimal digits) as described in TS 23.003, the NR Cell Identity (NCI) (9 hexadecimal digits) and optionally, the NID (11 hexadecimal digits) as specified in TS 23.003. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20;
23A)
if the access-class field is equal to "3GPP-NR-U", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), Tracking Area Code (6 hexadecimal digits) as described in TS 23.003, the NR Cell Identity (NCI) (9 hexadecimal digits) and optionally, the NID (11 hexadecimal digits) as specified in TS 23.003. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20;
24)
if the access-type field is equal to "3GPP-NR-SAT", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), Tracking Area Code (6 hexadecimal digits) as described in TS 23.003, the NR Cell Identity (NCI) (9 hexadecimal digits) and optionally, the NID (11 hexadecimal digits) as specified in TS 23.003. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20;
25)
if the access-class field is equal to "3GPP-NR-SAT", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), Tracking Area Code (6 hexadecimal digits) as described in TS 23.003, the NR Cell Identity (NCI) (9 hexadecimal digits) and optionally, the NID (11 hexadecimal digits) as specified in TS 23.003. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20; and
26)
if the access-type field is equal to "3GPP-NR-ProSe-L2UNR" or "3GPP-NR-ProSe-L3UNR", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), Tracking Area Code (6 hexadecimal digits) as described in TS 23.003, and the NR Cell Identity (NCI) (9 hexadecimal digits) obtained from the 5G ProSe UE-to-network relay UE that the UE is connected to as specified in TS 24.554. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20.
Up

7.2A.5  P-Charging-Vector header field  p. 438

7.2A.5.1  Introduction  p. 438

The P-Charging-Vector header field is extended to include specific charging correlation information needed for IM CN subsystem functional entities.

7.2A.5.2  Syntax  p. 438

7.2A.5.2.1  General |R6|  p. 438
The syntax of the P-Charging-Vector header field is described in RFC 7315. There may be additional coding rules for this header field depending on the type of IP-CAN, according to access technology specific descriptions.
Table 7.2A.5 describes 3GPP-specific extensions to the P-Charging-Vector header field defined in RFC 7315.
The access-network-charging-info parameter is an instance of generic-param from the current charge-params component of P-Charging-Vector header field.
The access-network-charging-info parameter includes alternative definitions for different types access networks. The description of these parameters are given in the subsequent subclauses.
The "access-network-charging-info" header field parameter is not included in the P-Charging-Vector for SIP signalling that is not associated with a session.
When the "access-network-charging-info" is included in the P-Charging-Vector and necessary information is not available from the IP-CAN (e.g. via Gx/Rx interface) reference points then null or zero values are included.
For type 1 and type 3 IOIs, the generating SIP entity shall express the "orig-ioi" and "term-ioi" header field parameters in the format of a quoted string as specified in RFC 7315.
If an IOI is a type 1 IOI, the content of the quoted string consists of the "Type 1" string prefix followed by the IOI value. The "Type 1" string prefix is the type-1-prefix value specified in the Table 7.2A.5A.
If an IOI is a type 3 IOI, the content of the quoted string consists of the "Type 3" string prefix followed by the IOI value. The "Type 3" string prefix is the type-3-prefix value specified in the Table 7.2A.5A.
If an IOI is a type 2 IOI, the value of the "orig-ioi" and "term-ioi" header field parameters is set to the IOI value. No string prefix is used.
The receiving SIP entity does not perform syntactic checking of the contents of the IOI parameter (the IOI parameter is passed unmodified to charging entities).
The "loopback" parameter is provided to the charging system of other entities in the signalling path to indicate that loopback has been applied and entities of the IM CN subsystem involved in the loopback, e.g. TRF, can have generated CDRs in their own right.
The "fe-identifier" header field parameter is an instance of generic-param from the current charge-params component of the P-Charging-Vector header field. This header field parameter contains one or more IM CN subsystem functional entity addresses ("fe-addr") and/or AS addresses ("as-addr") and application identifiers ("ap-id") where the IM CN subsystem functional entity does create charging information for the related CDR of this IM CN subsystem functional entity. For AS hosting several applications the AS address can appear several times, each accompanied with a different application identifier based on the application executed by the AS.
Up
7.2A.5.2.2  GPRS as IP-CAN |R6|  p. 440
GPRS is a supported access network (gprs-charging-info parameter). For GPRS there are the following components to track: GGSN address (ggsn parameter), media authorization token (auth token parameter), and a pdp-info parameter that contains the information for one or more PDP contexts. In this release the media authorization token is set to zero. The pdp-info contains one or more pdp-item values followed by a collection of parameters (pdp-sig, gcid, and flow-id). The value of the pdp-item is a unique number that identifies each of the PDP-related charging information within the P-Charging-Vector header field. Each PDP context has an indicator if it is an IM CN subsystem signalling PDP context (pdp-sig parameter), an associated GPRS Charging Identifier (gcid parameter), and a identifier (flow-id parameter). The flow-id parameter contains a sequence of curly bracket delimited flow identifier tuples that identify associated m-lines and relative order of port numbers in an m-line within the SDP from the SIP signalling to which the PDP context charging information applies. For a complete description of the semantics of the flow-id parameter see TS 29.214 Annex B. The gcid, ggsn address and flow-id parameters are transferred from the GGSN to the P-CSCF via the PCRF over the Rx interface (see TS 29.214 and Gx interface (see TS 29.212).
The gcid value is received in binary format at the P-CSCF (see TS 29.214). The P-CSCF shall encode it in hexadecimal format before include it into the gcid parameter. On receipt of this header field, a node receiving a gcid shall decode from hexadecimal into binary format.
The "access-network-charging-info" is not included in the P-Charging-Vector for SIP signalling that is not associated with a multimedia session. The access network charging information may be unavailable for sessions that use a general purpose PDP context (for both SIP signalling and media) or that do not require media authorisation.
Up
7.2A.5.2.3  Evolved Packet Core (EPC) via WLAN as IP-CAN |R6|  p. 440
The access-network-charging-info parameter is an instance of generic-param from the current charge-params component of P-Charging-Vector header field.
This version of the specification defines the use of "pdg" for inclusion in the P-Charging-Vector header field. No other extensions are defined for use in I-WLAN in this version of the specification.
Up
7.2A.5.2.4  xDSL as IP-CAN |R7|  p. 441
The access-network-charging-info parameter is an instance of generic-param from the current charge-params component of P-Charging-Vector header field. The access-network-charging-info parameter includes alternative definitions for different types of access networks. This subclause defines the components of the xDSL instance of the access-network-charging-info.
For xDSL, there are the following components to track: BRAS address (bras parameter), media authorization token (auth-token parameter), and a set of dsl-bearer-info parameters that contains the information for one or more xDSL bearers.
The dsl-bearer-info contains one or more dsl-bearer-item values followed by a collection of parameters (dsl-bearer-sig, dslcid, and flow-id). The value of the dsl-bearer-item is a unique number that identifies each of the dsl-bearer-related charging information within the P-Charging-Vector header field. Each dsl-bearer-info has an indicator if it is an IM CN subsystem signalling dsl-bearer (dsl-bearer-sig parameter), an associated DSL Charging Identifier (dslcid parameter), and a identifier (flow-id parameter). The flow-id parameter contains a sequence of curly bracket delimited flow identifier tuples that identify associated m-lines and relative order of port numbers in an m-line within the SDP from the SIP signalling to which the dsl-bearer charging information applies. For a complete description of the semantics of the flow-id parameter see TS 29.214.
The format of the dslcid parameter is identical to that of ggsn parameter. On receipt of this header field, a node receiving a dslcid shall decode from hexadecimal into binary format.
For a dedicated dsl-bearer for SIP signalling, i.e. no media stream requested for a session, then there is no authorisation activity or information exchange over the Rx and Gx interfaces. Since there are no dslcid, media authorization token or flow identifiers in this case, the dslcid and media authorization token are set to zero and no flow identifier parameters are constructed by the PCRF.
Up
7.2A.5.2.5  DOCSIS as IP-CAN |R7|  p. 441
The access-network-charging-info parameter is an instance of generic-param from the current charge-params component of P-Charging-Vector header field. The access-network-charging-info parameter includes alternative definitions for different types of access networks. This subclause defines the components of the cable instance of the access-network-charging-info. Cable access is based upon the architecture defined by Data Over Cable Service Interface Specification (DOCSIS).
The billing correlation identifier (bcid) uniquely identifies the PacketCable DOCSIS bearer resources associated with the session within the cable operator's network for the purposes of billing correlation. To facilitate the correlation of session and bearer accounting events, a correlation ID that uniquely identifies the resources associated with a session is needed. This is accomplished through the use of the bcid as generated by the PacketCable Multimedia network. This bcid is returned to the P-CSCF within the response to a successful resource request.
The bcid is specified in RFC 3603. This identifier is chosen to be globally unique within the system for a window of several months. Consistent with RFC 3603, the BCID must be encoded as a hexadecimal string of up to 48 characters. Leading zeroes may be suppressed.
If the bcid value is received in binary format by the P-CSCF from the IP-CAN, the P-CSCF shall encode it in hexadecimal format before including it into the bcid parameter. On receipt of this header field, a node using a bcid will normally decode from hexadecimal into binary format.
Up
7.2A.5.2.6  cdma2000® packet data subsystem as IP-CAN |R8|  p. 441
The specific extensions to the P-Charging-Vector header field defined in RFC 7315 when the access network is cdma2000® packet data subsystem are: the icn-charging-info parameter contains one icn-bcp child parameter and one or more child itid parameters. The icn-bcp parameter, identifies the point of attachment where UE has attached itself to the cdma2000® packet data subsystem. The icn-bcp parameter is conveyed to the P-CSCF by the cdma2000® packet data subsystem. Each itid child parameter within icn-charging-info corresponds to one IP-CAN bearer that was established by the cdma2000® packet data subsystem for the UE. Each itid parameter contains an indicator if it is an IP-CAN subsystem signalling IP-CAN bearer (itc-sig parameter), an associated IP-CAN charging identifier (itc-id parameter), and one or more flow identifiers (flow-id parameter) that identify associated m-lines within the SDP from the SIP signalling. These parameters are transferred from the cdma2000® packet data subsystem to the P-CSCF over the respective interface.
For an IP-CAN bearer that is only used for SIP signalling, i.e. no media stream requested for a session, then there is no authorisation activity or information exchange with the P-CSCF over the respective cdma2000® interfaces. Since there is no itc-id, or flow identifiers in this case, the itc-id is set to zero and no flow identifier parameters are constructed by the P-CSCF.
Up
7.2A.5.2.7  EPS as IP-CAN |R8|  p. 442
For EPS there are the following components to track: P-GW address (pdngw parameter), and a eps-info parameter that contains the information for one or more EPS bearers. The eps-info contains one or more eps-item values followed by a collection of parameters (eps-sig, ecid, and flow-id). The value of the eps-item is a unique number that identifies each of the EPS-bearer-related charging information within the P-Charging-Vector header field. Each EPS bearer context has an associated QCI indicating if it is an IM CN subsystem signalling EPs bearer context (eps-sig parameter), an associated EPS Charging Identifier (ecid parameter), and a identifier (flow-id parameter). The flow-id parameter contains a sequence of curly bracket delimited flow identifier tuples that identify associated m-lines and relative order of port numbers in an m-line within the SDP from the SIP signalling to which the EPS bearer charging information applies. For a complete description of the semantics of the flow-id parameter see TS 29.214 Annex B. The ecid, pdngw address and flow-id parameters are transferred from the P-GW to the P-CSCF via the PCRF over the Rx interface (see TS 29.214 and Gx interface (see TS 29.212).
The ecid value is received in binary format at the P-CSCF (see TS 29.214). The P-CSCF shall encode it in hexadecimal format before include it into the ecid parameter. On receipt of this header field, a node receiving a gcid shall decode from hexadecimal into binary format.
The "access-network-charging-info" header field parameter is not included in the P-Charging-Vector for SIP signalling that is not associated with a multimedia session. The access network charging information may be unavailable for sessions that use a general purpose EPS bearer context (for both SIP signalling and media).
Up
7.2A.5.2.8  Ethernet as IP-CAN |R8|  p. 442
The access-network-charging-info parameter is an instance of generic-param from the current charge-params component of P-Charging-Vector header field. For Ethernet accesses, the IP Edge Node address (ip-edge parameter) is tracked. The IP Edge Node is defined in ETSI ES 282 001 [138].
7.2A.5.2.9  Fiber as IP-CAN |R10|  p. 442
The access-network-charging-info parameter is an instance of generic-param from the current charge-params component of P-Charging-Vector header field. For Fiber accesses, the IP Edge Node address (ip-edge parameter) is tracked. The IP Edge Node is defined in ETSI ES 282 001 [138].
7.2A.5.2.10  5GS as IP-CAN |R15|  p. 442
For 5GS there are the following components to track: SMF address (SMF parameter) and a 5gs-info parameter that contains the information for one or more 5GS PDU sessions. The 5gs-info contains one or more 5gs-item values followed by a collection of parameters (5gscid and flow-id). The value of the 5gs-item is a unique number that identifies each of the 5GS PDU session charging information within the P-Charging-Vector header field.
Each 5GS PDU session has an associated 5GS Charging Identifier (5gscid parameter), and an additional information (flow-id parameter). The flow-id parameter contains a sequence of curly bracket delimited parameter tuples that identify associated m-lines and relative order of port numbers in an m-line within the SDP from the SIP signalling to which the 5GS PDU session charging information applies. For a complete description of the semantics of the flow-id parameter see TS 29.214. The smf address, 5gscid and flow-id parameters are transported to the P-CSCF via the PCRF over the Rx interface (see TS 29.214.
The 5gscid value is received in binary format at the P-CSCF (see TS 29.214). The P-CSCF shall encode it in hexadecimal format before include it into the 5gscid parameter. On receipt of this header field, a node receiving a 5gscid shall decode from hexadecimal into binary format.
The "access-network-charging-info" header field parameter is not included in the P-Charging-Vector for SIP signalling that is not associated with a multimedia session.
Up

7.2A.5.3  Operation  p. 443

The operation of this header field is described in subclause 5.2, subclause 5.3, subclause 5.4, subclause 5.5, subclause 5.6, subclause 5.7 and subclause 5.8.
Up

Up   Top   ToC