4 Capabilities for the support of IP multimedia services

22.5193GPPBusiness communication requirementsTS

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

4.1 General

4.1.1 Types of traffic

The traffic generated or received on behalf of an NGCN can be either:

traffic sent to the NGN for processing according to normal rules of the NGN. This type of traffic is known as public network traffic;
traffic sent to the NGN for processing according to an agreed set of rules specific to an enterprise. This type of traffic is known as private network traffic. Private network traffic is normally within a single enterprise, but private network traffic can also exist between two different enterprises if not precluded for regulatory reasons.

NOTE: An enterprise network may separately distinguish private network calls that originate in the NGN from private network calls that originate in the enterprise; this does not form part of the present document.

The NGN shall distinguish public network traffic from private network traffic. The NGN shall distinguish private network traffic belonging to one enterprise from that belonging to another enterprise.

Private network traffic may require different handling in the NGN compared to public network traffic, see for example clause 4.1.7 on regulatory requirements.

Except between closely-related enterprises where regulations permit, the NGN shall treat traffic between enterprises as public network traffic. In such cases, as part of the capabilities provided to the enterprise, the NGN can provide break-out and/or break-in capabilities on behalf of each enterprise.

For private network traffic the NGN shall be transparent to any extensions of the chosen signalling protocol, except where there is a specific need for NGN intervention required to deliver the service requested by the enterprise customer.

4.1.2 Business communication capabilities

The NGN can provide the following capabilities to an enterprise:

virtual leased line, where NGCN sites are interconnected through the NGN. No additional capabilities are provided by the NGN;
business trunking application, where the NGN hosts transit capabilities between NGCNs, break-in capabilities from NGN to NGCN and break-out capabilities from NGCN to NGN. A business trunking application may also host additional capabilities beyond basic break-in, break-out and transit capabilities to the NGCN. Typically there is no corporate network terminal equipment connected directly to an NGN. The capabilities provided are defined in clause 4.4;
hosted enterprise services, where an NGN hosts originating and/or terminating business communication capabilities for business communication users that are directly attached to an NGN and have an IMS service subscription for this application in this NGN. This is known commonly as IP-Centrex. The capabilities provided are defined in clause 4.3.

NOTE: NGCNs will not necessarily use IMS in their support of session-based capabilities.

4.1.3 Business models

Additionally to the business domain relationships as specified in 3GPP TS 22.228 [6] the NGN shall support the following business domain relationships:

NGCN to IMS relationship: NGCN is attached to an Access network that is connected to the NGN IMS with which the NGCN has a service agreement as shown in figure 4.1, the relationship is with the home IMS.

Figure 4.1

NGCN to Access network relationship: NGCN is connected to an Access Network as shown in figure 4.2. The relationships given in 3GPP TS 22.228 [6] would normally be sufficient to enable connectivity with the NGN, providing there is a relationship between the NGCN and the IMS. Relationship b may be required in some cases.

Figure 4.2

NOTE: The Access Networks to which the various NGCN sites are connected may belong to different operators.

The following business model relationship is shown as it plays a role in some scenarios. The present document assumes the business relationships described in item a) and b) and those as assumed from 3GPP TS 22.228 [6] in order to create communications in support of this relationship:

NGCN to NGCN relationship: The relationship between two NGCNs is shown in figure 4.3.

Figure 4.3

NOTE: Both NGCN 1 and NGCN 2 have their own relationship with an NGN. NGCN 1 and NGCN 2 may also represent parts of the same NGCN. Additionally NGCN 1 and NGCN 2 may have relationships with different NGNs, which may belong to the same or different operators.

Where the figures and text identify "IMS" forming the business relationship; this can apply also to the usage of other subsystems in the NGN architecture.

Additionally to the interconnect models as specified in 3GPP TS 22.228 [6], the NGN shall support:

– an interconnect model where bi-lateral Service Level Agreements are established between an NGCN and an NGN.

Business trunking applications are normally provided by the home IMS and relationship a) is used to establish these capabilities, which in turn uses relationships given in 3GPP TS 22.228 [6] for the access network related relationship. Hosted enterprise services are normally provided by the home IMS, the existing business relationships as specified in 3GPP TS 22.228 [6] being sufficient to establish such capabilities.

Virtual leased line services can be supported directly using relationship b, or it can be supported using relationship a) with the IMS which in turn uses relationships given in 3GPP TS 22.228 [6] for the access network related relationship.

Roaming of NGCN users is supported by either:

– a combination of business model relationship a) with relationships in 3GPP TS 22.228 [6] relationship with the visited IMS. No relationship is required between the home NGCN and the visited NGN or access network.

Roaming of NGN users to NGCN is supported by:

– a combination of business model relationship a) with relationships in 3GPP TS 22.228 [6] relationship with the home IMS. No relationship is required between the home IMS and the visited NGCN.

The service offering to an NGCN may be restricted by the capabilities of the access network, the business agreement between the access network operator and the NGN operator and the business agreement between the NGCN and NGN operators.

4.1.4 Number, naming and addressing

3GPP TS 22.228 [6] provides requirements for the support of numbering to end users of the NGN which apply equally for public network traffic generated by, or received by a business communication capability.

For private network traffic generated by, or received by, a business communication capability, the requirements of 3GPP TS 22.228 [6] apply along with the following additional requirements:

1) the NGN shall support tel-URIs that encode a PNP number, the PNP used by the enterprise shall be uniquely identified in this tel URI.

NOTE: Ensuring the uniqueness of the PNP identifier can be achieved by using a domain name associated with the enterprise, that the PNP belongs to.

For public and private network traffic generated by, or received by, a business communication capability, the requirements of 3GPP TS 22.228 [6] apply along with the following additional requirements:

the NGN shall support usage of SIP URIs with a domain belonging to an enterprise, and any usage of SIP URIs with a domain hosted by the enterprise; and
the NGN shall support usage of SIP URIs where more than one domain belong to the same enterprise, and any usage of SIP URIs where more than one domain is hosted by the same enterprise;
the NGN shall support usage of SIP URIs where a domain belonging to an enterprise, is partly hosted in NGCN and partly hosted in NGN.

URIs prefixed with "IM" and "Pres" are supported as specified in 3GPP TS 22.228 [6].

4.1.5 Identification of session originator and terminator

As defined in 3GPP TS 33.203 [3] a trust domain is used for the management of identities within enterprise network interconnection.

For identification, the requirements described in 3GPP TS 22.228 [6] are supported to NGN users and users of business communications capabilities as follows:

1) when the business communication capability is outside the trust domain, the NGN asserts an identity that the NGN associates (by means of subscription data) with the enterprise, in addition to delivering the identity of the enterprise user as provided by the NGCN and which is not asserted by the NGN;

2) when the business communication capability is inside the trust domain, the NGN presents the identity of the enterprise user as the asserted identity. The NGN shall accept the asserted identity received from the NGCN; and

3) in order to support interworking with the PSTN/ISDN, and for other purposes, an alias identity of the enterprise user can be needed. An alias set for an enterprise user consists of:

a) a SIP URI not in the form of a public telecommunication number; and

b) one of either:

– a public telecommunications number that reaches the same enterprise user; or

– a private network number that reaches the same enterprise user.

For enterprise users, it is the responsibility of the enterprise to provide the alias set. The NGN shall be able to receive alias sets from the NGCN.

NGNs shall be able to deliver alias sets (of any user) to the NGCN.

The above requirements apply to the identities of both session originator and session terminator.

4.1.6 Charging and accounting requirements

An enterprise can account for traffic in its business communication capabilities whether hosted in an NGCN or NGN.

For public network traffic, the requirements of 3GPP TS 22.115 [8] apply.

For public network traffic, the enterprise and the NGN operator shall be able to identify each other across any interconnection interface, including intra-NGN interfaces to hosted business communication capabilities. For private network traffic, any involved enterprise shall be able to identify each other across any interconnection interface between its business communication capabilities.

Any business communication capability hosted in an NGN shall be able to account for private network traffic to the enterprise in the same manner as exists for an NGN operator to account for their own traffic.

Additionally, for private network traffic, the enterprise and the NGN operator shall be able to identify each other across any interconnection interface.

4.1.7 Regulatory requirements

4.1.7.1 Lawful intercept

Lawful Intercept should be handled according to TS 33.106 [9].

4.1.7.2 Emergency service

Both public network traffic and private network traffic may carry emergency calls.

An emergency call identified as public network traffic shall be handled in accordance with the emergency call requirements of the NGN, i.e. in accordance with the requirements of 3GPP TS 22.228 [6].

In case of a public network traffic emergency call, an NGN shall forward geographical location information received from an NGCN and possibly use it for routing to an appropriate PSAP. This can be subject to both privacy and regulatory requirements.

Routeing of calls identified as emergency calls in private network traffic is outside the scope of NGN documents. The NGN shall not handle such calls as specified in 3GPP TS 22.228 [6]. This also applies to a hosted NGCN capability.

NOTE 1: Many enterprises will require the call to be routed to a private PSAP.

NOTE 2: Private numbering plans or dialling plans used within an enterprise can reuse national emergency numbers (e.g. 112 in Europe) for other purposes and can use a different number to denote an emergency call.

NOTE 3: Where an enterprise operates a private PSAP, it can require that calls be routed to the private PSAP (or to one of several private PSAPs) or to a public PSAP depending on circumstances. For example, for a caller physically located within a particular enterprise site, routing to the private PSAP for that site can be required, whereas for callers physically located elsewhere routing to the public PSAP could be required.

4.1.7.3 Identifying malicious communications

A call identified as public network traffic shall be handled in accordance with the malicious call identification requirements of the NGN, i.e. in accordance with the requirements of 3GPP TS 22.228 [6].

Identification of malicious calls in private network traffic is outside the scope of NGN documents. The NGN shall not handle such calls as specified in TS 181 005 [2]. This also applies to a hosted NGCN capability.

NOTE: Separate regulatory requirements can apply for private network traffic, or there is the possibility of no regulatory requirements at all.

4.1.7.4 Anonymous communications rejection

A call identified as public network traffic shall be handled in accordance with the anonymous call rejection requirements of the NGN, i.e. in accordance with the requirements of 3GPP TS 22.228 [6].

Requirements for handling of anonymous calls in private network traffic are outside the scope of NGN documents. The NGN shall not handle such calls as specified in 3GPP TS 22.228 [6]. This also applies to a hosted NGCN capability.

NOTE: Separate regulatory requirements can apply for private network traffic, or there is the possibility of no regulatory requirements at all.

4.1.8 Mobility

4.1.8.1 Roaming

The business models as expressed in 3GPP TS 22.228 [6] and clause 4.1.3 of the present document allow several roaming scenarios. Important roaming scenarios in the context of business communication are highlighted in this clause. These scenarios apply whether the NGCN functionality is external to the NGN, or hosted in the NGN.

For all scenarios both terminal mobility and personal mobility should be supported as defined in 3GPP TS 22.228 [6].

An NGCN user should be able to register and receive service from their NGCN while roaming to:

a) another NGCN site of the same NGCN and interconnected by the NGN; or

b) the NGN to which the NGCN is directly connected; or

c) the NGN to which the NGCN is indirectly connected via another NGN.

Over and above the roaming capabilities provided in 3GPP TS 22.228 [6], an NGN user should be able to register and receive service from their NGN while roaming to:

a) an NGCN connected to the NGN; or

b) an NGCN indirectly connected to the NGN;

subject to agreement with the NGCN.

4.1.9 Routing requirements

4.1.9.1 Routing to a NGCN user

The NGN shall support routing to NGCN users that do not have an IMS service subscription in the NGN, but can be reached through an NGCN site that has a business trunking arrangement with an NGN.

NOTE: In this case an NGCN site has an IMS subscription, the corporate network users in a NGCN do not need their own IMS service subscription, since they are owned and managed by the NGCN. What this requirement achieves is that these corporate network users can be reached from the public part of the NGN by addressing them directly using a public address.

4.1.9.2 number range based routing

The NGN shall support routing based on Recommendation ITU-T E.164 [1] number ranges.

NOTE: To be able to route to corporate network users in an NGCN, it should be possible to route only on a specific number range that is assigned to such an NGCN.

4.1.10 Communication admission control

The NGN shall support Communication Admission Control on a per NGCN site basis. 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. It shall be possible to set the following thresholds on a per direction basis (i.e. incoming and outgoing communications):

– maximum number of simultaneous session-oriented communications;

– maximum number of simultaneous streams per communication;

– maximum number of immediate messages.

Communications coming in excess to the allowed threshold may be accepted or rejected.

NOTE: The enterprise may select values for communication admission control that correspond to the Service Level Agreement (SLA) between the enterprise and the operator. If this occurs, then communications coming in excess of the allowed threshold which are accepted may be subject to specific charging rules.

4.1.11 Geographical location

An NGN shall be able to provide to an NGCN the geographical location information of an NGCN user. This can be subject to privacy requirements.

NOTE 1: An NGCN can use the geographical location information for example to provide location based services to the NGCN user.

NOTE 2: The source of geographical location information may be an NGN or an NGCN UE.

4.2 NGN/NGCN interconnection requirements

4.2.1 NGCN site identifier

NGN shall support identification of an NGCN site, for authentication and authorization purposes.

NOTE 1: The NGCN site identification is needed to be able to let the NGN determine which NGCN site a communication is originating from.

NOTE 2 An NGCN may have more than one NGCN site and hence more than one NGCN site identifier associated.

4.2.2 Corporate network user identifier

In addition to the Naming, Numbering and Addressing requirements expressed in 3GPP TS 22.228 [6]and in clause 4.1.4 of the present document the NGN shall provide the capability to uniquely identify NGCN users. NGCN user identities are assigned by an NGCN operator.

NOTE 1: This does not exclude scenarios where one organization acting as an NGN operator also in another role administers the NGCN of an enterprise on behalf of that enterprise.

NOTE 2: The above requirement ensures that for communications from an NGCN user to an NGN user the NGN user’s OIP service can present the correct identity of the calling NGCN user.

NOTE 3: The above requirement ensures that for communications from an NGN user to an NGCN user the NGN user’s TIP service can present the correct identity of the called NGCN user.

NOTE 4: The above requirement ensures that NGN users can call NGCN users that have identities within the set of identities that are available to that NGCN under the business trunking arrangement for that NGCN.

4.2.3 Authentication and security requirements

Authentication and Security with regard to connection of an NGCN to the NGN shall comply with security requirements specified in 3GPP TS 33.203 [3] and 3GPP TS 33.210 [4].

4.3 Specific requirements for hosted enterprise services

4.3.1 Security requirements for hosted enterprise services

When HES are being provided, a UE which is directly attached to or roams into an IMS network (via UNI) shall comply to the IMS access security requirements as specified in 3GPP TS 33.203 [3].

4.3.2 Capabilities provided to a HES user

The capabilities provided by such hosting towards HES users are not specified further by the present document, except that such hosting can form an integral part of any business communication support.

4.3.3 Capabilities provided to the enterprise

4.3.3.1 Break-in

HES can provide break-in. Break-in is where public network traffic is accepted from the public network and delivered to the HES user.

4.3.3.2 Break-out

HES can provide break-out. Break-out is where private network traffic is routed in the NGCN, or other business communication capability, to a point where it can enter an NGN on terms advantageous to the NGCN operator. An HES providing break-out therefore converts private network traffic to become public network traffic. The purpose of this capability is to allow a call from within the NGCN, or other business communication capability, to reach a user outside the enterprise (e.g. in the NGN). 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. As an example, these rules and policies may be selected for tariff reasons, and the point where the capability is applied may be dependent on both geographic location and the NGN operator involved.

When break-out is provided, the HES shall convert any identities provided as private network numbers to valid public telecommunication numbers.

4.4 Specific requirements for business trunking application

4.4.1 Routeing capabilities

4.4.1.1 Overview

The business trunking application can provide a number of special routeing capabilities. Examples of these are as follows:

– Break-in.

– Break-out.

– Bulk rerouting.

4.4.1.2 Break-in

A business trunking application can provide break-in. Break-in is where public network traffic is routed in the NGN to a point where it can enter an NGCN, or other business communication capability, on terms advantageous to the NGCN operator. A business trunking application providing break-in therefore converts public network traffic to become private network traffic. The purpose of this capability is to allow a call from outside the NGCN to reach a user within the enterprise. 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. As an example, these rules and policies may be selected for tariff reasons (for example such that the NGCN operator can reduce the tariff to the calling user), and the point where the capability is applied may be dependent on both geographic location and the NGN operator involved.

4.4.1.3 Break-out

A business trunking application can provide break-out. Break-out is where private network traffic is routed in the NGCN, or other business communication capability, to a point where it can enter an NGN on terms advantageous to the NGCN operator. A business trunking application providing break-out therefore converts private network traffic to become public network traffic. The purpose of this capability is to allow a call from within the NGCN, or other business communication capability, to reach a user outside the enterprise (e.g. in the NGN). 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. As an example, these rules and policies may be selected for tariff reasons, and the point where the capability is applied may be dependent on both geographic location and the NGN operator involved.

When break-out is provided, the business trunking application shall convert any identities provided as private network numbers to valid public telecommunication numbers.

4.4.1.4 Bulk rerouting

A business trunking application can provide bulk rerouting. Bulk rerouting is where private network traffic (possibly after break-in) destined for a terminating NGCN site is routed to an alternative NGCN site or answer point. This allows the NGCN site to be removed from service, e.g. overnight when it is not attended, or under fault conditions. 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. These can include:

a) not reachable (e.g. all calls to a particular NGCN site are diverted to a configured destination in case IP connectivity is lost between the network and this NGCN site);

b) congestion; and

c) time and date (e.g. all calls to a particular NGCN site are rerouted to a configured destination during closed hours).

4.4.2 Communication barring

Communication barring enables network rejection of incoming communications that fulfil certain globally provisioned or configured conditions for a particular NGCN site. 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. The decision to reject a communication shall be independent of the actual communication target (i.e. which line behind the NGCN site is being targeted by the session).