6 Procedures

24.5243GPPArchitecture, functional description and signallingHosted enterprise servicesRelease 17TS

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

6.1 Registration

Registration procedures comply with 3GPP TS 23.228 [5] or ETSI TS 182 012 [3] depending on the type of endpoint.

NOTE: Registration procedures for endpoints not connected directly to a 3GPP or TISPAN IP CAN are outside the scope of the present document.

The IMS public user identity used at registration is in the form of a SIP URI. This SIP URI can include a user name in the form of a telephone number with a user=phone parameter where the telephone number is either a public e.164 or a private number; if private numbers are used, the private numbering plan shall be uniquely identifiable by the NGN.

6.2 Originating session procedures

Originating communication setup procedures shall comply with 3GPP TS 23.228 [5] or ETSI TS 182 012 [3] depending on the type of endpoint.

In addition to the procedures specified in this subclause, the UE shall comply with the requirements identified in 3GPP TS 24.229 [15], subclause 4.1.

In addition to the procedures specified in the following subclauses, the AGCF shall comply with the procedures specified in ETSI TS 183 043 [16] appropriate to this entity.

In addition to the procedures specified in the following subclauses, each IMS functional entity shall comply with the procedures specified in the clauses of 3GPP TS 24.229 [15] and 3GPP TS 24.628 [17] appropriate to this entity.

An AS providing the logic of an originating HES may provide communication admission control in terms of number of simultaneous communications to/from this particular HES.

Support of private numbering is described in subclause 6.5.

Certain services require that the UE or an AGCF can be configured to insert a default session destination in the Request URI when a dialstring is not entered by the end user. In the case of the UE, the default session destination may be manually configured by the user or received from the CNGCF. This configured default session destination can either point to the terminating end point for the session or a value independent from the actual destination. In the latter case, the AS acting as the originating HES determines the actual session destination from local configuration data and/or the user profile and rewrites the Request URI.

The AS procedures for modification of the P-Asserted-Identity headers fields for originating requests typically depend on:

– operator and enterprise domain policies;

– privacy settings as specified in IETF RFC 3323 [9] and IETF RFC 3325 [10];

– whether the destination belongs to the same enterprise domain than the session initiator.

with the following restrictions:

– when the terminating endpoint is outside the HES’s domain (i.e. public domain or business trunking services see note) and no privacy restrictions apply, the identity in the P-Asserted-Identity representing the HES user shall be a globally routable SIP or tel URI.

NOTE: The originating side hosted enterprise services scenario can interoperate with any other terminating scenario.

As an example, an AS providing the logic of an originating HES, based on enterprise policies, can perform the following changes with regards to the identities it receives in INVITE messages:

– override the P-Asserted-Identity to an identity derived from the received value. This identity is in the form of a telephone number representing for example an attendant or in the form of a URI of type user@domain, where the user part represents the HES or a partition of this HES (e.g. site-based partitions) and the domain part represents the enterprise;

– override the URI part of the From header field with the value received in the P-Asserted-Id header field, with the exception that an anonymous value in the From header field must not be modified.

Depending on the type of changes made, the AS will act as a SIP Proxy as defined in 3GPP TS 24.229 [15], subclause 5.7.4, as a Routing B2BUA or an Initiating B2BUA, as defined in 3GPP TS 24.229 [15], subclause 5.7.5.

6.3 Terminating session procedures

Terminating communication setup procedures shall comply with 3GPP TS 23.228 [5] or ETSI TS 182 012 [3] depending on the type of endpoint.

In addition to the procedures specified in this subclause, the UE shall comply with the requirements identified in
3GPP TS 24.229 [15], subclause 4.1.

In addition to the procedures specified in the following clauses, the AGCF shall comply with the procedures specified in ETSI TS 183 043 [16] appropriate to this entity.

In addition to the procedures specified in the following clauses, each IMS functional entity shall comply with the procedures specified in the clauses of 3GPP TS 24.229 [15] and 3GPP TS 24.628 [17] appropriate to this entity. An AS providing the logic of an terminating HES may provide communication admission control in terms of number of simultaneous communications sent to/from this particular HES.

Terminating communications to a group is described in subclause 6.6.

6.4 Emergency communications

The AGCF procedures for emergency communication are specified in ETSI TS 183 043 [16].

Processing of emergency communications by other network entities shall conform to 3GPP TS 23.167 [6], except where the enterprise requires a special arrangement whereby emergency communications are delivered to a destination within the enterprise (hosted or supported by an NGCN). Such an arrangement may also involve enterprise specific emergency numbers.

NOTE: Procedures for supporting the above special arrangement are outside the scope of the present document.

6.5 Capabilities provided to an enterprise

6.5.1 General

Hosted enterprise services (HES) are deployed on one or more applications servers. HES may provide enterprise level capabilities. When such capabilities are offered to a specific enterprise the initial filter criteria of the service profile of a connected HES user needs to be configured so that the S-CSCF that serves the HES user invokes the AS that hosts the HES.

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

3GPP TS 22.519 [14] defines the enterprise capabilities that HES shall support, this subclause specifies protocol impact of the different applications.

6.5.2 Routeing capabilities

6.5.2.1 Overview

6.5.2.2 Break-in

No specific protocol action is required for a HES providing break-in.

6.5.2.3 Break-out

When break-out is enabled for a specific enterprise, a HES converts incoming 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
Private-Network-Indicator header field if present as specified in IETF RFC 7316 [24], from 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 HES logic offering this service will be inserted in the signalling path of sessions originating from and terminating to the served HES user.

6.5.3 Communication admission control

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

6.5.4 Anonymous communication rejection

When anonymous communication rejection is enabled a terminating HES serving a HES user providing this service shall implement the procedure as specified in 3GPP TS 24.611 [20], subclause 4.5.2.6.2.

To allow this service to be provided it needs to be ensured that the HES logic offering this service will be inserted in the signalling path of sessions terminating to the served HES user.

6.6 Private numbering

6.6.1 General

Sessions from endpoints served by a HES can be established using private numbering to any type of destination, including the PSTN, another endpoint served by the same or different HES, an endpoint served by an NGCN belonging to the same or a different enterprise as well as any other IMS user.

The following subclauses provide further details on the handling of private numbering by the UE and the network.

NOTE: In case of legacy endpoints the UE procedures required in support of private numbering are performed by the functional entity providing the UE role with regards to the IMS (i.e. AGCF or VGW).

6.6.2 UE behaviour

6.6.2.1 General

Private numbering information is sent in the Request-URI of the originating SIP requests, using one of the following formats:

1) A TEL URI, complying with IETF RFC 3966 [21], with a local number followed by a phone-context value.

2) A SIP URI, complying with IETF RFC 3261 [22], with the user =phone parameter.

3) A SIP URI, complying with IETF RFC 3261 [22] and IETF RFC 4967 [23], with the user=dialstring parameter.

NOTE: A UE can use a SIP URI complying with IETF RFC 3261 [22], where the user part contains a string of digits corresponding to a private number and the domain name is specific enough to enable the network to understand that the user part contains private numbering information and the context in which it has to be interpreted.

The actual value of the URI depends on whether the user equipment performs an analysis of the dial string input by the end user.

6.6.2.2 UE without dial string processing capabilities

In this case the UE does not perform any analysis of the dial string. This requires that the dialling plan be designed so as to enable the AS acting as an originating HES to differentiate private numbers from other numbers.

The dial string may be sent to the network, in the Request URI of SIP requests, using one of the following formats:

1) A TEL URI, syntactically complying with IETF RFC 3966 [21], with the dial string encoded as a local number followed by a pre-configured fixed phone-context value.

EXAMPLE: tel:<input dial string>;phone-context=unprocesseddialstring.example.com.

2) A SIP URI, syntactically complying with IETF RFC 3261 [22], with the user =phone parameter, embedding a TEL‑URI with a pre-configured fixed phone-context value.

EXAMPLE: sip:<input dial string>;
phone-context=unprocesseddialstringexample.com@operator.com;user=phone.

3) A SIP URI, complying with IETF RFC 3261 [22] and IETF RFC 4967 [23], with the user=dialstring parameter and a with a pre-configured fixed phone-context value in the user part.

EXAMPLE: sip:<input dial string>;
phone-context=unprocesseddialstringexample.com@operator.com;user=dialstring.

4) A SIP URI syntactically complying with IETF RFC 3261 [22], where the user part contains the dial string and the domain name is specific enough to enable to network to understand that the user part contains a dial string.

EXAMPLE: sip:<input dial string>@dialstrings.entreprise.com.

6.6.2.3 UE with dial string processing capabilities

In this case the UE performs sufficient dial string analysis (or receives an explicit indication from the user) to identify whether private numbering is used and processes the dial string accordingly before building the Request-URI.

If the UE detects that a public dialling plan or a private dialling plan is being used, where the terminal is able to identify a global telephone number, the procedures described in 3GPP TS 24.229 [15] apply after removing all dial string elements used for public numbering detection purposes (e.g. escape codes).

If the UE detects that a private dialling plan is being used, it may decide to send the dial string unchanged to the network or to alter it to comply with the private numbering plan (e.g. remove all dial string elements used for private numbering detection).

Annex A provides examples of UE processing options and of population rules for the Request-URI fields and parameters. As a general rule, recognition of special service numbers takes priority over other dialling plan issues. If the dial string equates to a pre-configured service URN (see IETF RFC 5031 [19]) then the service URN should be sent.

6.6.3 Network behaviour

The use of numbers in PNPs and in user specific dial plans shall be provided in the following manner:

1) The P-CSCF or AGCF routes the session towards the S-CSCF as per the session origination procedures.

Processing the Request URI (e.g. address analysis and potential modification such as translation into globally routable format) shall be performed by an AS providing the logic of an originating HES in the user’s Home Network. The S-CSCF routes the SIP request towards this AS based upon filter criteria.

The translation procedure relies on data stored in the AS or in an external database, separated from the AS using e.g. a LDAP interface. If user-specific dialling plans are supported, translation data may also be stored in the UPSF, in which case the AS accesses this data using the Sh reference point.

2) This AS passes the session request back to the S-CSCF with a Request URI that contains either a globally routable SIP URI or a Tel URI with a number in international format. The SIP request shall contain enough information to route to the terminating network and allow the terminating network to identify the intended end point.

3) After processing the Request URI the S-CSCF shall route the SIP request, via normal IMS routing principles, towards its destination.

6.7 Group Management

One or more IMS groups (as defined in 3GPP TS 23.228 [5]) may be associated with one or more HESs. Each group shall be addressable by a globally unique group identifier. The group identifier shall take the form of a Public Service Identifier.

6.8 Supplementary service control

It shall be possible to configure all services (e.g. communication forwarding conditions, selective communication filtering criteria, etc.) using the Ut reference point, a Web portal or using service code commands.

Users shall be able to control supplementary services using service code commands sent in session initiation requests. One possible syntax for such commands is defined in ETSI ETS 300 738 [4], in which case the actual values used in the different fields of the commands may differ from those specified in ETSI ETS 300 738 [4] ( and service code commands (excluding the START and FINISH fields) shall be encoded as a local-number using and appropriate "phone-context" value.