6 Procedures

24.5253GPPArchitecture and functional descriptionBusiness trunkingRelease 17TS

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

6.1 Subscription based business trunking

6.1.1 Introduction

In addition to the procedures specified in the subclause 6.1, the NGCN site shall comply with the requirements identified in 3GPP TS 24.229 [18], subclause 4.1 for a UE, and specifically for a UE performing the functions of an external attached network.

In addition to the procedures specified in the subclause 6.1, all functional IMS entities shall support the procedures appropriate for these entities specified in 3GPP TS 24.229 [18] and in 3GPP TS 24.628 [10].

6.1.2 Identification

Each NGCN site is allocated a pair of private and public user identities. This public user identity is also known as the NGCN site identifier; this public user identity has to be a valid corporate network user identifier.

NGCN user identifiers are owned and managed by the enterprise. NGCN user identifiers are not stored in the HSS.

To be able to support routeing to NGCN users registered in an NGCN, through the connection with a specific NGCN site, an NGN shall support implicit registration of one or more wildcarded public user identities in addition to the implicit registration of one or more distinct public user identities. The implicitly registered identities associated with the registration of a particular NGCN site shall be determined by agreement between the NGCN and NGN.

NOTE: The wildcarded public user identity consists of a delimited regular expression located in the telephone-subscriber portion of a tel URI (e.g. tel: +3314529! [0-9]{4}!) or in the user portion of a SIP URI (e.g. sip:!.*!@example.com). The wildcarded public user identity is configured in the HSS as part of the implicit registration set of the subscription for a corporate network identifier.

A specific public user identifier is referred to as an NGCN user identifier if it matches a distinct public user identifier or a wildcarded public user identifier that is contained in the implicit registration set associated with an NGCN site identifier.

The NGN shall support implicit registration of NGCN user identifiers (specific or wildcarded) where the domain belongs to an enterprise.

For the purpose of processing incoming and outgoing calls the identity of each NGCN user behind an NGCN site is handled as a distinct public user identity possibly within a public user identity range or subdomain.

6.1.3 Registration

Registration of the NGCN site in the IMS is required. Registration shall rely on standard registration procedures for the IM CN subsystem, based on the pair of private user identity and public user identity representing the NGCN site as a whole.

NOTE 1: For NGCN sites that do not support IMS registration procedure, approaches like surrogate registration or configuration can be used as a fallback. The details of such approaches are out of scope of the present document.

Upon successful registration an implicit registration set conforming to the requirements of subclause 6.1.2, will be provided from the HSS to the S-CSCF, the P-CSCF and the UE representing the NGCN site.

As part of the successful registration a security association as required by the access security requirements in 3GPP TS 33.203 [16] will be established between the NGCN site and the P-CSCF that the NGCN site used for registration. This security association is used to secure the signalling between the P-CSCF and the NGCN site. Also as the security association is formed based on mutual authentication of the NGCN site and the NGN, requests that the P-CSCF receives over such a security association are known to come from that NGCN site and no other entity.

NOTE 2: Although the term "security association" is often used in relation with IP-sec, in the above paragraph this term is also assumed to apply to equivalent procedures in other security mechanisms as specified in the access security requirements of 3GPP TS 33.203 [16].

The NGN will need to be configured to understand the presence of an attached NGCN instead of a normal UE.

The NGN shall support provisioning of a special "loose route" indication in the user profile if the NGCN site requires loose routing procedures to be applied by the NGN. When available this indication is sent from the HSS to S-CSCF during registration as a result of performing the Cx Server Assignment procedure.

An NGCN site shall initiate initial registration when one of following events occurs:

– The NGCN site attachment point is powercycled.

– The NGCN site attachment point is allocated a new IP address.

– The IP address of the P-CSCF as reported by the DNS has changed and the NGCN site is registered through that P-CSCF.

NOTE 3: The above criteria are applicable for registration through a single P-CSCF and registration through multiple P-CSCFs.

– No response is received to a keep-alive request and the NGCN site is registered through a single P-CSCF.

– An initial request fails due to a transport failure of some sort (generally, due to fatal ICMP errors in UDP or connection failures in TCP), the transaction layer times out without ever having received any response, provisional or final (i.e. timer B or timer F in IETF RFC 3261 [21] fires) and the NGCN site is registered through a single P-CSCF.

NOTE 4: The case where the NGCN site has registered an AOR through multiple P-CSCF instances is addressed in subclause 6.1.5.

6.1.4 Requests originating from an NGCN user entering NGN

6.1.4.1 General

The procedures for handling of requests from an NGCN especially applying to identities are very different depending on whether or not the NGCN is part of the same trust domain for asserted identities as the NGN, and if not, whether the NGCN is considered as privileged sender or not. To highlight those differences, three separate clauses below describe the procedure for:

– an NGCN not considered as privileged sender and not trusted by NGN;

– an NGCN considered as privileged sender and trusted by NGN; and

– an NGCN considered as privileged sender and not trusted by NGN.

Trust domain for asserted identity is defined in IETF RFC 3324 [22]. To be meaningful in a particular domain it requires the definition of a Spec(T) that specifies the requirements that all entities in the trust domain need to comply with. The Spec(T) to be used should be covered in the SLA.

INVITE requests sent by an NGCN site may include a P-Early-Media header with the "supported" parameter.

In the event of the P-Early-Media header not being present in an 18x message and a media flow being received, such a media flow is not forwarded in most cases. However, under these circumstances, an NGCN site may, as an NGCN option, forward the received media flow to the end-user and disable any locally generated call progress tones.

NOTE: This behaviour enables managing the case when the NGCN site and/or the remote entity generating early media do not support the P-Early-Media header.

The To header field may contain any URI format. The Request-URI shall be in a format supported by the NGN for the request to be accepted. 3GPP TS 24.229 [18], subclause 5.1.2A.1.2 gives information on the format of the Request-URI.

In an outgoing request initiating a dialog or in a target refresh request the Contact header field contains the target URI within the NGCN (which can be different from the public user identities assigned to the NGCN site) for receiving subsequent mid-dialog requests. This URI may also be suitable for receiving future out-of-dialog requests.

As an NGCN site may comprise multiple SIP entities, the Record-Route header field may be populated by entities within the NGCN site in a dialog initiating request sent to the NGN.

When internally received by the NGCN attachment point, the Record-Route header field has to be passed on by the attachment point when sending a request to the NGN and the attachment point can also add its own Record-Route header field.

As an NGCN site may comprise multiple SIP entities, the Via header field may be populated by multiple entities within the NGCN site in an outgoing request to the NGN.

6.1.4.2 NGCN not considered as privileged sender and not trusted by NGN

For a request originated in an untrusted NGCN and entering the NGN over the Gm reference point, network policy or a setting in the IMS subscription for the NGCN site determines whether the procedures specified in 3GPP TS 24.229 [18] for a privileged sender apply or not.

When the request needs to be presented as originated from a particular NGCN user identified by an NGCN user identifier, the NGCN site can provide the NGCN user identifier in the P-Preferred-Identity header field.

NOTE 1: If the P-Preferred-Identity or P-Asserted-Identity header fields are not supplied by the NGCN site, the NGCN user identifier can be provided in the From header field.

As aliases are not managed by the NGN, it is up to the NGCN site to provide two P-Preferred-Identity header fields, one containing a SIP URI and the other containing a TEL URI, in order to provide alias identities for the calling party (see 3GPP TS 22.519 [1]).

If no identity is presented by the NGCN in a P-Preferred-Identity header field, then the P-CSCF will provide a default identity in the P-Asserted-Identity header field. This identity is the first on the list of URIs present in the P-Associated-URI header field received as part of the registration procedure. It shall exist in the HSS by agreement between the NGCN and NGN operator, and shall identify an NGCN user who operates with the authority of the NGCN operator (e.g. an attendant).

If the identity is provided in a P-Preferred-Identity header field the P-CSCF checks whether this identity is part of the implicit registration set and if so the P-Preferred-Identity header field will be removed and its value copied into the P-Asserted-Identity header field that will be used within the NGN. When this identity is not part of the implicit registration set, a present P-Preferred-Identity header field will be removed and the P-CSCF will provide a default identity in the P-Asserted-Identity header field and if the NGCN site is considered a privileged sender in the P-Served-User header field. The default identity is the first identity on the list of URIs present in the P-Associated-URI header field received as part of the registration procedure.

A P-Asserted-Identity header field will be discarded if received, as specified in 3GPP TS 24.229 [18], subclause 5.2.6.3.3.

When the S-CSCF receives the request it finds a match between the P-Asserted-Identity header field and the distinct or wildcarded public user identities as in the implicit registration set of the NGCN site’s profile. This allows the S-CSCF to perform its actions based on the service profile of the NGCN site; this includes the optional link in of an AS over ISC, for example to provide additional services to the enterprise.

NOTE 2: The above procedures do not preclude that the NGN may host a service on behalf of the NGCN that may perform further translations on the P-Asserted-Identity header field. For example in order to cope with NGCN sites that do not deliver the NGCN user identifier in a P-Preferred-Identity header field or a P-Asserted-Identity header field, an AS playing the role of a business trunking application on the originating side can decide to override the P-Asserted-Identity header field with the contents of the From header field, if consistent with the range of identities assigned to the NGCN or NGCN site and with the policy agreed between the NGN operator and the enterprise. If the From header field contained a SIP URI, the AS can also include a second P-Asserted-Identity header field with a TEL URI if possible. This enables the NGCN user identifier to be sent to the destination in the form of an asserted identity.

If the Privacy header field with value "id" is received in a request from the NGCN site, the P-CSCF retains the header field when passing on the request.

The NGCN site may receive a connected party identity that is not privacy-restricted in the P-Asserted-Identity header field in an 18x or 2xx final response depending on NGN policy.

6.1.4.3 NGCN considered as privileged sender and trusted by NGN

For a request originated in a trusted NGCN and entering the NGN over the Gm reference point, the procedures specified in 3GPP TS 24.229 [18] for a privileged sender apply.

When the request needs to be presented as originated from a particular NGCN user, the NGCN site can provide the NGCN user identifier in the P-Preferred-Identity header field or in the P-Asserted-Identity header field.

As aliases are not managed by the NGN, it is up to the NGCN site to provide two Asserted-Identity header fields, one containing a SIP URI and the other containing a TEL URI, in order to provide alias identities for the calling party (see 3GPP TS 22.519 [1]).

When a P-Preferred-Identity header field is received and is part of the implicit registration set, the P-Served-User header field is set to the P-Preferred-Identity header field.

When no P-Preferred-Identity header field is received or when a received P-Preferred-Identity header field is not part of the implicit registration set, the P-CSCF includes a P-Served-User header field set to the default identity received in the P-Associated-URI header field during registration.

If one or two P-Asserted-Identity header field(s) are received from the NGCN site, the P-CSCF passes them on unchanged.

If no P-Asserted-Identity header field is received the P-CSCF includes a P-Asserted-Identity header field with a value copied from the P-Served-User header field.

If the Privacy header field with value "id" is received in a request from the NGCN site, the P-CSCF retains the header field when passing on the request.

NOTE: The above procedures do not preclude that the NGN may host a service on behalf of the NGCN that may perform further translations on the P-Asserted-Identity header field. For example in order to cope with NGCN sites that do not deliver the NGCN user identifier in a P-Preferred-Identity header field or P-Asserted-Identity header field, an AS playing the role of a business trunking application on the originating side can decide to override the P-Asserted-Identity header field with the contents of the From header field, if consistent with the range of identities assigned to the NGCN or NGCN site and with the policy agreed between the NGN operator and the enterprise. If the From header field contained a SIP URI, the AS can also include a second
P-Asserted-Identity header field with a TEL URI if possible. This enables the NGCN user identifier to be sent to the destination in the form of an asserted identity.

The NGCN site may receive a connected party identity in the P-Asserted-Identity header field in an 18x or 2xx final response. The identity will be accompanied by a Privacy header field set to "id" if its presentation is restricted.

6.1.4.4 NGCN considered as privileged sender and not trusted by NGN

If the NGCN site is considered as privileged sender the procedures of subclause 6.1.4.3 for the handling of requests shall apply. This means that the P-CSCF will pass on a P-Asserted-Identity header field unchanged if received in a request from the NGCN site. The NGCN site profile shall contain appropriate filter criteria to ensure that the identity in the
P-Asserted-Identity header field will be verified by an Application Server.

The NGCN site may receive a connected party identity that is not privacy-restricted in the P-Asserted-Identity header field in an 18x or 2xx final response depending on NGN policy.

6.1.5 Requests terminating to an NGCN user leaving NGN

6.1.5.1 General

The procedures for handling of requests to and responses from an NGCN especially applying to identities are very different depending on whether the NGCN is part of the same trust domain for asserted identities as the NGN or not. To highlight those differences three separate clauses below describe the procedure for:

– an NGCN not considered as privileged sender and not trusted by NGN;

– an NGCN considered as privileged sender and trusted by NGN; and

– an NGCN considered as privileged sender and not trusted by NGN.

When an initial request for a new dialog or a request for a standalone transaction addressed to an NGCN site identifier or an NGCN user identifier in the Request-URI arrives at the I-CSCF, the I-CSCF performs a location request to HSS to locate the S-CSCF where to forward the request to. The HSS finds a match between the Request-URI and the registered NGCN site identifier or an implicitly registered distinct or wildcarded public user identity that belongs to the service profile of an NGCN site. The HSS returns information about a particular S-CSCF allocated to that specific NGCN site service profile.

When the S-CSCF receives the request it finds a match between the Request-URI and the NGCN site identifier or the distinct or wildcarded public user identity as in the implicit registration set of the NGCN site service profile. This allows the S-CSCF to perform its actions based on the service profile for the NGCN site. This includes the optional link of AS over ISC, for example to provide additional services to an enterprise. When the S-CSCF is ready to forward the request to the NGCN via the P-CSCF and a "loose-route" indication has been received from the HSS during registration (see subclause 6.1.3), it retains the received NGCN user identifier (including any URI parameters) in the Request-URI, then it adds to the Route header field the contents of the Path header field as stored during registration as well as the registered Contact address. This will ensure that the request is first routed to the P-CSCF assigned during registration and that the P-CSCF can forward the request over the Gm reference point towards the NGCN site. The NGCN site can then use the Request-URI to forward the request further in the NGCN or it can use it to select an extension to forward the call to.

The above procedure assumes specific population rules applicable when a special indication stored in the user profile is received from the HSS. In such cases, the S-CSCF retains the received target identity in the Request-URI and, if the NGCN site has not registered using IETF RFC 5626 [29], adds the Contact address (stripping out the Display name field if any) to the Route header field (as the last field value). If the NGCN site has not registered using IETF RFC 5626 [29], after removing its own address, the P-CSCF uses the topmost Route header field (which happens to be the Contact address) to identify the security association (or equivalent in case no security association was established) and route the request according to IETF RFC 3261 [21]. If the NGCN site has registered using IETF RFC 5626 [29] the P-CSCF will use the procedures defined in IETF RFC 5626 [29] to forward the request over the Gm reference point towards the NGCN site.

NGCN sites that have implicitly registered a TEL URI are required to accept a Request-URI in the form of a TEL URI when the loose route indicator is set in their network profile.

If no loose-route indicator is configured in the NGCN site profile the Request-URI of a SIP request received from the NGN will contain the registered contact of the NGCN site, and the public user identity of the actual destination inside the NGCN is conveyed in the P-Called-Party-ID header field.

NOTE 1: The non-loose-route procedure may not be adequate for NGCN URIs that are not within the range of identities assigned to the NGCN site, e.g. private GRUUs. This issue requires further study.

In a 2xx final response to an incoming dialog initiating or target refresh request the Contact header field contains the target URI within the NGCN (which can be different from the public user identities assigned to the NGCN site) for receiving subsequent mid-dialog requests. This URI may also be suitable for receiving future out-of-dialog requests.

As an NGCN site may comprise multiple SIP entities, the Max-Breadth header field can prevent loops by limiting forking within the NGCN site.

NOTE 2: The Max-Breadth header field may be passed on to the NGN, e.g. if the call is diverted back into the NGN. As an NGCN site may comprise multiple SIP entities, the Max-Forwards header field can prevent loops by limiting the number of nodes that can forward the request within the NGCN site.

As an NGCN site may comprise multiple SIP entities, the Record-Route header field may have been populated by entities within the NGCN site in a response to a dialog initiating request received from the NGN.

When received by the NGCN attachment point in a request from the NGN, the Record-Route header field has to be passed on by the attachment point and the attachment point can also add its own Record-Route header field.

As an NGCN site may comprise multiple SIP entities, the Route header field may contain additional URIs addressing nodes within the NGCN site in a request received from the NGN.

NOTE 3: The NGN may know the route set within the NGCN site from a Record-Route received earlier on the same dialog, through configuration, or from a Path header field received during registration.

6.1.5.2 NGCN not considered as privileged sender and not trusted by NGN

For a request terminated in an untrusted NGCN and leaving the NGN over the Gm reference point, network policy or a setting in the IMS Subscription for the NGCN site determines whether the procedures specified in 3GPP TS 24.229 [18] for a privileged sender apply or not.

The NGCN site may receive a calling party identity that is not privacy-restricted in the P-Asserted-Identity header field in a request from the NGN, depending on NGN policy.

If the Privacy header field with value "id" is received in a response, the P-CSCF retains it when passing on the response.

For a response originating in the NGCN the P-CSCF provides the saved public user identity from the P-Called-Party-ID header field that was received in the request, plus the display name if previously stored during registration for the NGCN site (see subclause 6.1.4.1) in the P-Asserted-Identity header field. The S-CSCF will add a second P-Asserted-Identity header field if possible.

6.1.5.3 NGCN considered as privileged sender and trusted by NGN

For a request terminated in a trusted NGCN and leaving the NGN over the Gm reference point, the procedures specified in 3GPP TS 24.229 [18] for a privileged sender apply.

The NGCN site may receive a calling party identity in the P-Asserted-Identity header field in a request from the NGN. The identity will be accompanied by a Privacy header field set to "id" if its presentation is restricted.

If a P-Asserted-Identity header field is present in the response from the NGCN, the P-CSCF shall retain this identity when passing on the response. As aliases are not managed by the NGN, it is up to the NGCN site to provide two P-Asserted-Identity header fields, one containing a SIP URI and the other containing a TEL URI, in order to provide alias identities for the calling party (see 3GPP TS 22.519 [1]).

NOTE: If there is no P-Asserted-Identity header field in the response, the P-CSCF will not add one.

If the Privacy header field with value "id" is received in a response, the P-CSCF retains it when passing on the response.

6.1.5.4 NGCN considered as privileged sender and not trusted by NGN

The NGCN site may receive a calling party identity that is not privacy-restricted in the P-Asserted-Identity header field in a request from the NGN, depending on NGN policy.

Subclause 6.1.5.3 for the handling of responses shall apply. This means that the P-CSCF will pass on a P-Asserted-Identity header field unchanged if received in a response from the NGCN site. The NGCN site profile shall contain appropriate filter criteria to ensure that an Application Server will be included in the path of a dialog initiating or stand-alone request in order to verify the identity in the P-Asserted-Identity header field in the response.

6.1.6 Business trunking applications

6.1.6.1 General

Business trunking applications are deployed on an AS. In case such services are offered to a specific enterprise the initial filter criteria of the service profile of a connected NGCN site needs to be configured so that the S-CSCF that serves the NGCN site invokes the AS that hosts the business trunking application.

The intent of this clause is not to specify the detail of the individual applications, but only to indicate some specific impacts on the protocol.

3GPP TS 22.519 [1] defines the business trunking application, this clause specifies protocol impact of the different applications.

6.1.6.2 Routeing capabilities

6.1.6.2.1 Overview

Not applicable.

6.1.6.2.2 Break-in

When break-in service is enabled for a specific NGCN site, a business trunking application converts incoming public network traffic to private network traffic if the conditions agreed between the enterprise and the NGN operator indicate this.

To convert public network traffic to private network traffic the break-in service shall insert a P-Private-Network-Indication header field as specified in IETF RFC 7316 [31] with a private network identifier as expressed in the SLA between the enterprise and the NGN operator, in the initial request for a dialog or standalone request for a transaction.

To allow this service to be provided it needs to be ensured that the business trunking application offering this service will be inserted in the signalling path of sessions originating from and terminating to the served NGCN site.

6.1.6.2.3 Break-out

When break-out is enabled for a specific NGCN site, a business trunking application converts outgoing private network traffic to public network traffic if the conditions agreed between the enterprise and the NGN operator indicate this.

To convert private network traffic to public network traffic the break-out service shall remove P-Private-Network-Indication header field as specified in IETF RFC 7316 [31], from the initial request for a dialog or standalone request for a transaction.

6.1.6.2.4 Bulk rerouting

When bulk rerouting is enabled for a specific NGCN site, a terminating business trunking application forwards incoming public or private network traffic to a specified destination if the conditions agreed between the enterprise and the NGN operator indicate this.

The NGN operator defines the set of rules or policies under which this should occur, and the NGCN operator should be able to configure the capability within those rules and policies.

To allow this service to be provided it needs to be ensured that the business trunking application offering this service will be inserted in the signalling path of sessions terminating to the served NGCN site.

6.1.6.3 Communication admission control

When communication admission control is enabled a business trunking application serving an NGCN site executes the NGN operator defined set of rules or policies under which communication admission control applies, and the NGCN operator should be able to configure the capability within those rules and policies.

6.1.6.4 Anonymous communication rejection

When anonymous communication rejection is enabled a terminating business trunking application serving an NGCN site providing this service shall implement the procedure as specified in 3GPP TS 24.611 [8], subclause 4.5.2.6.2.

6.1.6.5 Communication barring

When communication barring is enabled, a terminating business trunking application shall reject incoming calls when the evaluation of the NGCN site specific incoming communication barring rules indicates so. The definition of the communication barring rules is out of scope of the present document.

When the communication barring application rejects a communication, it shall do so by implementing the protocol procedure for rejecting a communication as specified in 3GPP TS 24.611 [8], subclause 4.5.2.6.1, excluding the communication barring rule aspect of that procedure.

6.1.7 Signalling transparency

For private network traffic, an NGN shall be capable of transparent exchange of signalling elements that an IETF RFC 3261 [21] SIP proxy is not allowed to add, remove or modify, subject to the exception listed below, and shall be capable of being tolerant of and passing on without modification any signalling extension that is not supported. The exception is any information that needs to be changed to accomplish NAT traversal, i.e. IP addresses and ports in SDP. In particular, an NGN shall be capable of passing on a request, part of which is cryptographically signed (e.g. using the Identity header field), without removing or invalidating that signature. Whether such transparency is provided and to what degree is a matter for agreement between the NGN operator(s) and enterprise(s) concerned. This applies to any functional entity on the signalling path, including P-CSCF, S-CSCF, IBCF and AS.

NOTE: This is not intended to prevent intervention by an AS when needed to carry out specific services as agreed between operators or as negotiated by signalling.

6.1.8 Involvement of functions on the media path

6.1.8.1 General

For private network traffic, entities on the signalling path shall be capable of avoiding the insertion of functions into the media path that intervene above the transport layer, unless explicitly required by contractual arrangement between the NGN operator and the NGCN operator, explicitly requested through signalling, or in order to meet regulatory requirements. Examples of intervention that is prohibited (when exceptions do not apply) include transcoding, language translation, recording, re-encrypting and re-signing.

6.1.8.2 DTMF

As specified in 3GPP TS 24.229 [18], an NGCN site shall include the MIME subtype "telephone-event" in the media description in the SDP for audio media flows that support both audio codec and DTMF payloads in RTP packets as described in IETF RFC 4733 [26].

If the MIME subtype "telephone-event" is not supported by the remote party, the NGCN site should be able to send and receive DTMF in the media flow using a suitable audio codec negotiated in the offer/answer exchange.

6.1.8.3 Codecs

ETSI TS 181 005 [27] specifies principles for the use of codecs in the NGN. Specifically ETSI TS 181 005 [27] mandates that the "NGN shall allow end to end negotiation of any codec between NGN entities (terminal, network elements)". Although no direct requirement is placed on entities within the NGCN; by merit of the fact that SIP is used as the protocol for the interconnect it is clear that the NGCN-NGN interconnection interface shall allow end to end negotiation of any codec between NGCN and NGCN/NGN entities.

If the NGCN supports narrow band voice services then, as specified in ETSI TS 181 005 [27], in order to enable interworking for narrow band voice services for public traffic, the NGCN shall be capable of sending and receiving ITU‑T Recommendation G.711 [28] coded speech with a packetization size of 20 ms.

6.1.9 Handling of the P-Access-Network-Info header field

When a request or response received using an xDSL-based access the P-CSCF inserts a P-Access-Network-Info header field into the forwarded request or response by setting the access-type field to one of the values specified in 3GPP TS 24.229 [18] for this type of access. The P-CSCF adds the "network-provided" parameter and the "dsl-location" parameter with the value received in the Location-Information header in the User-Data Answer command as specified in ETSI ES 283 035 [11] or with a provisioned value if a static IP address is used and no interface to the NASS exist.

When a request or response received using an LAN-based access the P-CSCF inserts a P-Access-Network-Info header field into the forwarded request or response by setting the access-type field to "ETH", adding the "network-provided" parameter and the "eth-location" parameter with the value received in the Location-Information header in the User-Data Answer command as specified in ETSI ES 283 035 [11] or with a provisioned value if a static IP address is used and no interface to the NASS exist.

6.1.10 Emergency calls

The NGCN site will normally identify an emergency call as an emergency call and ensure that it is received in the NGN with a Request-URI set to an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in IETF RFC 5031 [24]. An additional sub-service type can be added if information on the type of emergency service is known.

The P-CSCF will handle requests identified as emergency calls and which are public network traffic in the same fashion as calls from UEs not using business communication procedures.

For requests identified as private network traffic, the P-CSCF can handle such requests according to normal routeing procedures for requests, and not follow the procedures of clause 5.2.10 of 3GPP TS 24.229 [18], or handle the request as if it was public network traffic.

NOTE 1: Such emergency calls are handled within some other NGCN site, which can either provide the emergency service routeing proxy, or the emergency answer point. Further study is required for what policy applies in selecting the one of the above options, and whether this choice is applicable to all or some identification of emergency calls.

An NGCN site will normally provide a geolocation in conjunction with such calls, using the procedures of IETF RFC 6442 [30]. The P-CSCF can also provide location information in the P-Access-Network-Info header field. Which of these two information is used by the E-CSCF to select a PSAP depends on the policy of the NGN operator and the regulatory constraints in force.

NOTE 2: The location information available in the P-Access-Network-Info header field when provided by the NGN usually represents the location of the access point where the NGCN site is connected to the NGN, and not the terminal attached to the NGCN.

The presence of the private network indication can modify the emergency call handling at the P-CSCF. This is necessary if emergency calls relating to private network traffic are to be routed to a separate PSAP (a "private PSAP"), to the PSAP used for emergency calls relating to public network traffic.

6.1.11 Charging

The applicable charging procedures are defined in 3GPP TS 32.260 [6].

6.1.12 Advice of Charge

An NGCN site supporting advice of charge services shall support the INFO method and shall accept MIME bodies of type "application/vnd.etsi.aoc+xml" defined in 3GPP TS 24.647 [12].

If the agreement between the NGN and the NGCN specifies that an NGCN site shall received advice of charge information, the NGCN site profile in the HSS shall contain appropriate initial filter criteria ensuring that an Application Server supporting the procedures described in 3GPP TS 24.647 [12] is inserted in the signalling path of outgoing sessions.

When processing originating sessions, this application server shall be able to act as a Charging Generation Point (CGP) with regards to the NGCN site and may take into account charging information received from upstream in the format defined in 3GPP TS 29.658 [13], annex C.

6.1.13 NAT traversal

NOTE 1: 3GPP TS 24.229 [18], annexes F and K specify mechanisms for NAT traversal. The application of these mechanisms is not precluded, but detailed implications of their use in a business communication environment have not been studied.

Two solutions to keep a connection alive, depending on the NAT traversal mechanism (Latching-based as defined in 3GPP TS 24.229 [18], annex F or SIP Outbound-based as defined in 3GPP TS 24.229 [18]) used, are provided in 3GPP TS 24.229 [18].

When using the latching-based NAT traversal mechanism, as defined in 3GPP TS 24.229 [18], subclause F.4.2 provides two solutions for keeping the signalling connection alive:

– short registration timers (see note 1 in 3GPP TS 24.229 [18], subclause F.4.2); and

– SIP outbound keep-alive as a stand-alone mechanism (see note 2 in 3GPP TS 24.229 [18], subclause F.4.2).

When using SIP outbound, as specified in 3GPP TS 24.229 [18], the SIP-outbound keep-alive mechanism applies.

NOTE 2: Use of alternative mechanisms (e.g. OPTIONS method) is outside the scope of the present document.

6.1.14 Private network traffic

Private network traffic can be distinguished from public network traffic by the addition of a P-Private-Network-Indication header field as specified in IETF RFC 7316 [31].

NOTE: Procedures for use of the P-Private-Network-Indication header field within the NGN are specified in 3GPP TS 24.229 [18]. Where an explicit indication of private network traffic is required within the NGN, then the P-Private-Network-Indication header field is expected to be used.

The NGN will handle the P-Private-Network-Indication header field in accordance with its trust domain specification.

The NGCN site can include a P-Private-Network-Indication header field as specified in IETF RFC 7316 [31] in an initial request or standalone request, with a valid private network identification for its use.

The NGN can include a P-Private-Network-Indication header field as specified in IETF RFC 7316 [31] in an initial request or standalone request to the NGCN site, with a valid private network identification for its use.

For transactions relating to private network traffic, the NGCN site may include and receive tel URIs (and their SIP equivalents) specifying Private Numbering Plan (PNP) numbers in accordance with ETSI TR 102 634 [20].

6.1.15 P-CSCF and IP-CAN redundancy

3GPP TS 24.229 [18], clause 9 describes several methods enabling a UE to obtain a list of IP addresses or the SIP server domain name of the P-CSCF. The addressing material acquired through these methods should be used to build a SIP URI corresponding to the P-CSCF. Once the SIP URI of the P-CSCF is obtained, IETF RFC 3263 [25] procedures as specified in 3GPP TS 24.229 [18], subclause E.2.2.1 should be applied to obtain from the DNS the IP address of the P-CSCF, including backup addresses for use in case of failure of the preferred choice.

An NGCN site may decide to perform multiple registrations for the same Address of Records through different P-CSCFs or from different local network interfaces attached to different IP-CANs. In this case, as specified in 3GPP TS 24.229 [18], subclause 5.1.1.2.1, the following settings apply to the REGISTER request header fields:

1) the Contact header field shall include a "+sip.instance" header field parameter containing the instance ID associated to the NGCN site and a "reg-id" header field parameter as described in IETF RFC 5626 [29]; and

2) the "outbound" option-tag shall be included in the Supported header field.

As specified in 3GPP TS 24.229 [18], subclause 5.1.2A.1.1, the NGCN site shall then include an "ob" SIP URI parameter in the Contact header field of the initial request, except REGISTER.

A load distribution or a load balancing strategy can be applied when sending an initial request to the NGN. The load distribution strategy can use a round-robin algorithm. A load balancing strategy can make use of the actual load of the P-CSCFs if this information is made available by the DNS.

If for an AOR multiple registrations through different P-CSCF instances according to IETF RFC 5626 [29] are performed and an initial request except REGISTER, fails as specified in IETF RFC 3263 [25], subclause 4.3 or if the P-CSCF does not respond to keep alive messages, the NGCN site can attempt to send that request to another P-CSCF where it is registered.

NOTE: Load balancing or load distribution for terminating request across multiple P-CSCFs as specified in 3GPP TS 24.229 [18], subclause 6.1 can be achieved by applying appropriate policies at the S-CSCF when multiple registrations exist. These policies are implementation specific.

6.2 Peering-based business trunking

6.2.1 Introduction

The NGCN site shall appear to the NGN as if it were an IBCF complying with the requirements identified in 3GPP TS 24.229 [18], subclause 4.1 for this functional entity.

In addition to the procedures specified in the subclause 6.2, all functional IMS entities shall support the procedures appropriate for these entities specified in 3GPP TS 24.229 [18] and in 3GPP TS 24.628 [10].

6.2.2 Identification

Each NGCN site is responsible for a set of public user identities.

6.2.3 Registration

There is no registration of NGCN sites in the IMS.

NOTE: Terminating requests are routed over the final NGN entity to the NGCN site by using standard DNS techniques, which apply to the remainder of the routeing.

6.2.4 Requests originating from an NGCN user entering NGN

6.2.4.1 General

The procedures for handling of requests to or from an NGCN especially applying to identities are very different depending on whether the NGCN is part of the same trust domain for asserted identities as the NGN or not. To highlight those differences two separate clauses describe the procedure for:

– an NGCN not trusted by NGN; and

– an NGCN trusted by NGN.

A request will be identified in the IBCF as coming from an NGCN site relating to a particular enterprise by means of appropriate security associations required by the network domain security requirements specified in 3GPP TS 33.203 [16].

In case no business trunking applications are provided, the "intelligent routeing function" as defined in subclause 5.3.1 just offers originating transit functionality in the NGCN originating case (figure 5.1).

Depending on the agreements between NGN an NGCN, originating business trunking applications are to be provided to the NGCN (e.g. those specified in 3GPP TS 22.519 [1]). In this case an AS needs to be invoked by the intelligent routeing function to perform the originating business trunking application, which may be realised by the IBCF forcing the CSCF routeing capabilities to treat the NGCN originated request as an originating request, reacting on enterprise specific data of the originating NGCN in the HSS.

NOTE: 3GPP TS 23.228 [17] defines in subclause 14.4 the capability of an IBCF to indicate whether an incoming SIP request is to be handled as an originating request by subsequent nodes in the IMS (e.g. by inserting the "orig" parameter, defined in 3GPP TS 24.229 [18], subclause 7.2A.6 and intended to tell the S-CSCF that it has to perform the originating services instead of terminating services and to tell the I-CSCF that it has to perform originating procedures).

6.2.4.2 NGCN not trusted by NGN

For a request originated in an untrusted NGCN, when the request needs to be presented as originated from a particular NGCN user identified by an NGCN user identifier, any identity provided by the NGCN site in the P-Preferred-Identity header field or in the P-Asserted-Identity header field is removed.

The IBCF will provide a default identity in the P-Asserted-Identity header field. This identity is configured in the IBCF, and shall identify a NGCN user who operates with the authority of the NGCN operator (e.g. an attendant).

Depending on NGN policy, the IBCF may send to the NGCN site a connected party identity that is not privacy-restricted, included in the P-Asserted-Identity header field of a 18x or 2xx final response.

If the Privacy header field with value "id" is received in a request from or a response to the NGCN site, the IBCF retains it when passing on the request or response.

6.2.4.3 NGCN trusted by NGN

If according to SLA the NGN and the NGCN form part of the same trust domain, the NGCN delivers the P-Asserted‑Identity header field to the NGN. The NGN does not remove the P-Asserted-Identity header field in this case.

The IBCF may send to the NGCN site a connected party identity included in the P-Asserted-Identity header field of an 18x or 2xx final response.

If the Privacy header field with value "id" is received in a request from or a response to the NGCN site, the IBCF retains it when passing on the request.

6.2.5 Requests terminating to an NGCN user leaving NGN

6.2.5.1 General

– an NGCN not trusted by NGN; and

– an NGCN trusted by NGN.

In case no business trunking applications are provided, the "intelligent routeing function" as defined in subclause 5.3.1 just offers basic and transparent routeing functionality in the NGCN terminating case (figure 5.2).

Depending on the agreements between NGN an NGCN, terminating business trunking applications are to be provided to the NGCN (e.g. those specified in 3GPP TS 22.519 [1]). In this case an AS needs to be invoked by the intelligent routeing function to perform the terminating business trunking application, which may be realised by the I-CSCF on basis of NGCN-specific data retrieved from the HSS.

6.2.5.2 NGCN not trusted by NGN

For a response originated in an untrusted NGCN, when the response needs to be presented as coming from a particular NGCN user identified by a NGCN user identifier, any identity provided by the NGCN site in the P-Preferred-Identity header field or in the P-Asserted-Identity header field is removed. The IBCF will provide a default identity in the P-Asserted-Identity header field. This identity is configured in the IBCF, and shall identify a NGCN user who operates with the authority of the NGCN operator (e.g. an attendant).

If the Privacy header field with value "id" is received in a request to or a response from the NGCN site, the IBCF retains it when passing on the request or response.

6.2.5.3 NGCN trusted by NGN

For a response originating in a trusted NGCN, if a P-Asserted-Identity header field is present in a response from the NGCN, the IBCF shall not remove this identity when passing on the response.

If the Privacy header field with value "id" is received in a request to or response from the NGCN site, the IBCF retains it when passing on the request or response.

6.2.6 Business trunking application

6.2.6.1 General

The provision of the business trunking applications (e.g. those defined in 3GPP TS 22.519 [1], clause 4.4) is realized by an intelligent routeing function, which may involve an AS depending on the actual enterprise specific data.

In the case no business trunking applications are provided, the "intelligent routeing function" as defined in subclause 5.3.1 just offers originating transit functionality in the NGCN originating case (figure 5.1). This originating case then corresponds to the second scenario of 3GPP TS 23.228 [17], subclause 5.19. In the terminating case the "intelligent routing function" just forwards requests to the appropriate IBCF.

The intent of this clause is not to specify the detail of the individual services, but only to indicate some specific impacts on the protocol.

6.2.6.2 Routeing related business trunking applications

6.2.6.2.0 General

For Break-in, Break-out and bulk rerouteing see subclause 6.1.6.2.

6.2.6.2.1 Originating requests

If the business trunking application receives an originating request from a NGCN, the business trunking application shall, based on the P-Served-User header field, identify the NGCN.

If the request contains a P-Asserted-Identity header field and does not contain a P-Private-Network-Indication header field, the business trunking application shall verify the P-Asserted-Identity header field against the profile of the NGCN. If the verification fails or if the request does not contain a P-Asserted-Identity header field, the business trunking application shall insert a P-Asserted-Identity header field identifying the main enterprise user. If the request contains a P-Private-Network-Indication header field, the business trunking application shall, if present, forward the received P-Asserted-Identity header field unchanged.

NOTE 1: The profile of the NGCN is provisioned in the business trunking application or in the subscription profile in HSS if this application uses the HSS for subscription storage.

NOTE 2 The profile of the NGCN can also be provisioned in the P-CSCF. In this case, the above procedures are already executed by the P-CSCF and need thus not be executed by the business trunking application anymore.

6.2.6.2.2 Terminating responses to an originating request

When the business trunking application receives a terminating response to the above request, if this response contains a P-Asserted-Identity header field and does not contain a P-Private-Network-Indication header field, the business trunking application shall verify the P-Asserted-Identity header field against the profile of the NGCN. If the verification fails or if the response does not contain a P-Asserted-Identity header field, the business trunking application shall insert a P-Asserted-Identity header field identifying the main enterprise user. If this response contains a P-Private-Network-Indication header field, the business trunking application shall, if present, forward the received P-Asserted-Identity header field unchanged.

NOTE 1: The profile of the NGCN is provisioned in the business trunking application or in the subscription profile in HSS if this application uses the HSS for subscription storage.

NOTE 2 The profile of the NGCN can also be provisioned in the P-CSCF. In this case, the above procedures will be executed by the P-CSCF and need thus not be executed by the business trunking application.

6.2.6.2.3 Terminating requests

If the business trunking application receives a terminating request to an NGCN, the business trunking application shall identify the particular NGCN the enterprise user belongs to, and also the P-CSCF(s) or IBCF(s), respectively serving the NGCN, and shall forward the request towards the NGCN. Therefore, the business trunking application shall create a route to the NGCN by adding a SIP URI of the P-CSCF or IBCF, respectively serving the NGCN and the NGCN in a Route header field as bottommost entries.

NOTE 1: The profile of the NGCN is provisioned in the business trunking application or in the subscription profile in the HSS if this application uses the HSS for subscription storage.

NOTE 2: Inserting the SIP URI of the NGCN in a Route header field will suppress triggering any other AS after the business trunking application. Hence this AS has to be last in the chain of iFCs.

Editor’s note: [BusTI-CT, CR 0001] It is FFS whether in certain scenarios another AS needs to be the last AS to be triggered (e.g. the SCC AS) in order to allow all desired services.

6.2.6.3 Communication admission control

See subclause 6.1.6.3.

6.2.6.4 Anonymous communication rejection

See subclause 6.1.6.4.

6.2.6.5 Communication barring

See subclause 6.1.6.5.

6.2.7 Signalling transparency

6.2.8 Involvement of functions on the media path

6.2.9 Handling of the P-Access-Network-Info header field

The P-Access-Network-Info header field is not provided by an NGCN site in the peering-based approach to business trunking.

6.2.10 Emergency calls

The IBCF will handle requests identified as emergency calls and which are public network traffic by routeing them to an E-CSCF.

NOTE 1: The above constitutes an extension to the IMS architecture which still needs to be studied as to its inclusion in the main IMS architecture documents.

For requests identified as private network traffic, the IBCF handles such requests according to normal routeing procedures for requests, or handle the request as if it was public network traffic.

NOTE 2: Such emergency calls are handled within some other NGCN site, which can either provide the emergency service routeing proxy, or the emergency answer point. Further study is required for what policy applies in selecting the one of the above options, and whether this choice is applicable to all or some identification of emergency calls, or handle the request as if it was public network traffic.

An NGCN site will normally provide a geolocation in conjunction with such calls, using the procedures of IETF RFC 6442 [30].

The presence of the private network indication can modify the emergency call handling at the IBCF. This is necessary if emergency calls relating to private network traffic are to be routed to a separate PSAP (a "private PSAP"), to the PSAP used for emergency calls relating to public network traffic.

6.2.11 Charging

NOTE: Not covered in this release of the present document.

6.2.12 Advice of Charge

NOTE: Not covered in this release of the present document.

6.2.13 NAT traversal

NOTE: The application of NAT traversal mechanisms is not precluded, but detailed implications of their use in a business communication environment have not been studied.

6.2.14 Private network traffic

Private network traffic can be distinguished from public network traffic by the addition of a P-Private-Network-Indication header field as specified in IETF RFC 7316 [31].

The NGN will handle the P-Private-Network-Indication header field in accordance with its trust domain specification.

The NGCN site can include P-Private-Network-Indication header field as specified in IETF RFC 7316 [31] in an initial request or standalone request, with a valid private network identification for its use.

The NGN can include P-Private-Network-Indication header field as specified in IETF RFC 7316 [31] in an initial request or standalone request to the NGCN site, with a valid private network identification for its use.

For transactions relating to private network traffic, the NGCN site may include and receive tel URIs (and their SIP equivalents) specifying PNP numbers in accordance with ETSI TR 102 634 [20].

6.3 Session-level virtual leased line between NGCN sites

6.3.1 Introduction

Session level virtual leased line provides a mechanism for transfer of requests from one entry point to one exit point with the provision of no application. The requests are private network traffic only.

6.3.2 Identification

The procedures of subclause 6.2.2 apply.

6.3.3 Registration

The procedures of subclause 6.2.3 apply.

6.3.4 Session originating from a NGCN user entering NGN

6.3.4.1 General

The procedures of subclause 6.2.4.1 apply with the exception that:

a) None of the entities within the NGN supporting the session level leased line provide a trust domain boundary. While the NGCN site either side of the leased line can themselves be a trust domain boundary, the NGN provides only the procedures associated with an NGCN trusted by the NGN.

6.3.4.2 NGCN not trusted by NGN

Not applicable.

6.3.4.3 NGCN trusted by NGN

The procedures of subclause 6.2.4.3 apply.

6.3.5 Session terminating to an NGCN user leaving NGN

6.3.5.1 General

The procedures of subclause 6.2.5.1 apply with the following exceptions:

6.3.5.2 NGCN not trusted by NGN

Not applicable.

6.3.5.3 NGCN trusted by NGN

The procedures of clause 6.2.5.3 apply.

6.3.6 Business trunking applications

Not applicable.

6.3.7 Signalling transparency

The NGN shall be capable of transparent exchange of signalling elements that an IETF RFC 3261 [21] SIP proxy is not allowed to add, remove or modify, subject to the exception listed below, and shall be capable of being tolerant of and passing on without modification any signalling extension that is not supported. The exception is any information that needs to be changed to accomplish NAT traversal, i.e. IP addresses and ports in SDP. In particular, an NGN shall be capable of passing on a request, part of which is cryptographically signed (e.g. using the Identity header field), without removing or invalidating that signature. Whether such transparency is provided and to what degree is a matter for agreement between the NGN operator(s) and enterprise(s) concerned. This applies to any functional entity on the signalling path, including IBCF and routeing function.

6.3.8 Involvement of functions on the media path

The procedures of subclause 6.2.8 apply.

6.3.9 Handing of the P-Access-Network-Info header

The procedures of subclause 6.2.9 apply.

6.3.10 Emergency calls

No emergency call functionality is provided in this scenario.

NOTE: Any emergency call will be routed from entry point to exit point in the same manner as any other SIP request.

6.3.11 Charging

NOTE: Not covered in this release of the present document.

6.3.12 Advice of Charge

NOTE: Not covered in this release of the present document.

6.3.13 NAT traversal

NOTE: The application of NAT traversal mechanisms is not precluded, but detailed implications of their use in a business communication environment have not been studied.

6.3.14 Private network traffic

NOTE: In a virtual leased line scenario all traffic is private network traffic.

6.4 NGCN user roaming into NGN public network

6.4.1 Introduction

Void.

6.4.2 Identification

Not applicable.

6.4.3 Registration

An NGCN UE that supports roaming into NGN shall support IMS registration procedures as specified in 3GPP TS 24.229 [18], subclause 5.1 for an IMS UE.

NOTE: As a roaming UE cannot assume any security mechanisms, it therefore has to support IMS AKA. See also TS 133 203 [16].

A P-CSCF of a visited IMS shall support IMS registration procedures as specified in 3GPP TS 24.229 [18].

An IBCF acting as an exit point of the visited IMS shall support procedures as specified in 3GPP TS 24.229 [18], subclause 5.10.

An NGCN site that supports roaming of its users into NGN shall support registration procedures as if it were a home IMS, specified by concatenating the behaviour of the home IBCF acting as an entry point, home I-CSCF, home HSS and home S-CSCF, subclauses 5.10, 5.3 and 5.4 of 3GPP TS 24.229 [18].

6.4.4 Requests originating from an NGCN user roaming in NGN

An NGCN UE that supports roaming into NGN shall support IMS request origination procedures as specified in 3GPP TS 24.229 [18], subclause 5.1 for an IMS UE.

A P-CSCF of a visited IMS shall support IMS request origination procedures as specified in 3GPP TS 24.229 [18], subclause 5.2.

An IBCF acting as an exit point of the visited IMS shall support procedures as specified in 3GPP TS 24.229 [18], subclause 5.10.

An NGCN site that supports roaming of its users into NGN shall support request origination procedures as if it were a home IMS, specified by concatenating the behaviour of the home IBCF acting as an entry point, home I-CSCF, home HSS and home S-CSCF, subclauses 5.10, 5.3 and 5.4 of 3GPP TS 24.229 [18].

6.4.5 Requests terminating on an NGCN user roaming in NGN

An NGCN UE that supports roaming into NGN shall support IMS request termination procedures as specified in 3GPP TS 24.229 [18], subclause 5.1 for an IMS UE.

A P-CSCF of a visited IMS shall support IMS request termination procedures as specified in 3GPP TS 24.229 [18], subclause 5.2.

An IBCF acting as an entry point of the visited IMS shall support procedures as specified in 3GPP TS 24.229 [18], subclause 5.10.

An NGCN site that supports roaming of its users into NGN shall support request termination procedures as if it were a home IMS, specified by concatenating the behaviour of the home IBCF acting as an exit point, home HSS and home S-CSCF, subclauses 5.10 and 5.4 of 3GPP TS 24.229 [18].

6.4.6 Business trunking applications

Not applicable.

6.4.7 Signalling transparency

No additional requirements on the visited NGN are identified.

6.4.8 Involvement of functions on the media path

No additional requirements on the visited NGN are identified.

6.4.9 Handing of the P-Access-Network-Info header

No additional requirements on the visited NGN are identified.

6.4.10 Emergency calls

No additional requirements on the visited NGN are identified.

6.4.11 Charging

NOTE: Not covered in this release of the present document.

6.4.12 Advice of Charge

NOTE: Not covered in this release of the present document.

6.4.13 NAT traversal

NOTE: The application of NAT traversal mechanisms is not precluded, but detailed implications of their use in this scenario have not been studied.

6.4.14 Private network traffic

NOTE: The use of the P-Private-Network-Indication header field to distinguish private network traffic, if any, in this scenario is not covered in this release of the present document.