7 User service requirements

22.2283GPPRelease 16Service requirements for the Internet Protocol (IP) multimedia core network subsystem (IMS)Stage 1TS

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

IP multimedia sessions provide the ability for users to invoke IP multimedia applications to send and receive (where applicable) voice and data communications, even when roaming. This includes interworking with existing voice and data networks for both fixed (e.g. PSTN, ISDN, internet etc.) and mobile users.

The IM CN subsystem shall support interworking with existing fixed and mobile voice and IP data networks, including PSTN, ISDN, Mobile and Internet.

It shall be possible to have basic voice calls between IMS users and users in CS domain/PSTN-style networks. When an IM session originates or terminates in a CS telephony call, the experience of the CS telephony network user should not substantially differ from that of a call between two CS telephony network users in terms of aspects such as the delay to set-up communications and the total permissible delay in transporting speech between the end users. The IM CN subsystem does not necessarily have to support all services offered by the CS telephony network.

7.1 Identifying IP multimedia application subscriptions

There is no requirement to support standardised subscription mechanisms for IP multimedia applications.

IP multimedia applications may require to be provisioned and configured by users and operators. Since the source and variety of IP multimedia applications may not be standardised, the specific feature codes to provision, enable and configure IP multimedia applications may not be standardised either. .

Note: The standardised service capabilities, personalised Internet web pages and evolving IP mechanisms may be used to allow user (self) provisioning, configuration and enabling of IP multimedia applications.

7.2 Access to the IM CN subsystem

7.2.0 General

IMS, complying with the principle of access independence, supports IP multimedia applications via IP multimedia sessions over a multitude of IP Connectivity Access Networks. These include e.g. E-UTRAN, UTRAN, GERAN, fixed line, I-WLAN, DOCSIS^®, WiMAX^™, cdma2000^®, and DVB-RCS2 access.

7.2.1 Access control

The IM CN subsystem shall be able to verify at any time that the user is entitled to use the resources of the IM CN subsystem.

7.2.2 IMS Registration and De-registration

In order to be able to access services from the IM CN Subsystem a UE shall register on the IM CN Subsystem.

– A UE that supports IMS shall be able to register on the IM CN Subsystem.

– A UE may support automated IMS registration, e.g. when gaining access to the PS domain.

– For fixed line, the IM CN subsystem shall support control of UE registration based on network information which is related to UE location (e.g. IP address, DSLAM information, etc). The registration control shall be based on subscription information which indicates whether registration control applies and to which location registrations are to be restricted.

– A UE that supports IMS shall be able to de-register from the IM CN Subsystem.

– The network operator shall be able to de-register a UE from the IM CN Subsystem.

7.3 Capability negotiation

The IMS shall provide the capability for IP multimedia applications (whether it is an application of a user or the network) to negotiate their capabilities to identify and select the available media components, QoS etc. of IP multimedia sessions. It shall be possible for the capability negotiation to take place on invocation, acceptance and during an IP multimedia session (e.g. following a change in UE capabilities, change in media types etc.). Capability negotiation may be initiated by the user, operator or an application on behalf of them.

In order to support the user’s preferences for IP multimedia applications, the capability negotiation shall take into account the information in the user profile whenever applicable. This includes the capability to route the IP multimedia session to a specific UE, when multiple UEs share the same IMS service subscription. In the Telepresence case, this may also include the UE capability for handling media, e.g. UE profile (screen size, number of screens and cameras, etc.). The IMS shall provide the capability for IP multimedia applications to exchange information about negotiated media components so that a sending system, receiving system, or intermediate system can make decisions about transmitting, selecting, and rendering media streams (e.g., decide which video stream is to be displayed on the left screen or how audio stream is to be rendered on the loudspeaker to maintain the spatial effect if multiple media streams are exchanged).

7.4 Redirecting of IP Multimedia sessions

The IMS shall support the capability for the user, or the network on behalf of the user, to identify an alternative destination for an IP multimedia session or individual media of an IP multimedia session. Redirection to alternative destinations may be initiated by the sending party, receiving party or the network on their behalf. It shall be possible for redirection to be initiated at various stages of an IP Multimedia session. For example:

Prior to the set up of an IP Multimedia session
During the initial request for an IP Multimedia session
During the establishment of an IP Multimedia session
While the IP Multimedia session is ongoing

Redirection can be applied for all Multimedia sessions unconditionally or it can be caused by any of a set list of events or conditions. Typical causes could be:

Identity of the caller
Location or presence of the calling or called party
If the called party is already in a session
If the called party is unreachable or unavailable in some other way
If the called party does not respond
After a specified alerting interval
User’s preference on routing for specific IP Multimedia session based on the capabilities of multiple UEs sharing the same IMS service subscription.
Time of day.

There are other causes that could be applied that do not require standardisation.

7.5 Invoking an IP multimedia session

7.5.0 General

The user shall be able to invoke one or more IP multimedia sessions. The user shall also be able to activate concurrent IP multimedia applications within each IP multimedia session.

7.5.1 Identification and addressing

Subscribers within the IMS shall be identifiable in originating and terminating sessions by means of one or multiple Public User Identities. The Public User Identity shall:

– be able to be assigned to more than one Private User Identity;

– be administered by the network operator and not be changeable by the user; and

– be globally reachable.

The Private User Identity shall be able to be assigned to more than one Public User Identity.

Both telecommunication numbering and Internet addressing schemes shall be supported as Public User Identities.

The Public User Identity shall utilise either the SIP URI scheme (as defined in IETF RFC 3261 [9]) or the Tel URI scheme (as defined in IETF RFC 3966 [15]).

Both SIP URIs and Tel URIs can be used to convey E.164 [26] numbers;

– The network operator shall be able to use in the Public User Identity either the same E.164 [26] number used for CS speech telephony (TS11 [1]) or a different E.164 number.

Both telecom and internet numbering and addressing schemes shall be supported as public identities. IP multimedia communication establishment (both originating and terminating) depending on originator shall be able to be based on E.164/TELURI (e.g. tel:+4412345678) [15]or SIP URI (sip:my.name@company.org) [9]. It shall be possible to assign several public identities for one subscription.

Whilst not required for routing between terminals within the IMS, it should be possible for the IMS network to:

– recognise and treat URIs, containing ‘IM’ or ‘Pres’ prefixes, received from other networks supporting such prefixes; and

– insert an ‘IM’, ‘Pres’ or ‘mailto’ prefix to an outgoing URI to enable routing to the correct addressee in external networks supporting such prefixes.

It shall be possible for the network operator to guarantee the authenticity of a Public User Identity presented for an incoming session to a user where the communication is wholly across trusted networks.

Note 4: This is equivalent to the calling line presentation services CLIP [25] in the telephony networks.

A terminating IMS entity may receive the original destination identity provided by the originating entity.

Note 5: This enables the address originally input by the subscriber to be available at the destination even when it has been translated e.g. from a free phone or premium rate service identifier.

7.5.2 Negotiation at IM session invocation

It shall be possible for the capability negotiation to take place at the time of the IP multimedia session invocation. Refer to clause 7.3 for further details on capability negotiation on IP multimedia session invocation.

A UE should support negotiation of the user’s desired language(s) (as defined in IANA [29]) and modalities for spoken, signed and written languages.

The system should be able to negotiate the user’s desired language(s) and modalities, per media stream and/or session, in order of preference.

A service provider shall be able to pass language and modality information between the endpoints. With respect to the language and modality information, there are no other service provider actions required.

7.5.3 Emergency communications

The requirements for Emergency communications are contained in [5] for PLMN and non-public networks [36] specified by 3GPP and in [19] for NGN broadband accesses.

7.5.4 Information of a Called Party

A calling party (A) shall be able to request information regarding

– whether the called party (B) is a premium rate number or international number,

– the HPLMN of the called party (B).

Based on the information, the calling party (A) could exercise the option of either continuing or terminating the call.

The HPLMN of the calling party (A) shall be able to provide information to a calling party (A) regarding

– whether the called party (B) is a premium rate number or international number,

– the HPLMN of the called party (B). In case of INIPUI, the HPLMN of the calling party (A) shall be able to retrieve the information about the HPLMN of the called party (B).

Based on the information provided, the calling party (A) could exercise the option of either continuing or terminating the call.

7.5.5 IMS Network-Independent Public User Identities (INIPUI)

The following requirements apply for IMS Network-Independent Public User Identities:

– Multiple INIPUI Operators shall be able to associate SIP URIs of type "sip:user@domain" (also known as "alphanumeric SIP URIs") that share a single domain name.

– An INIPUI Operator shall be able to associate a SIP URI scheme for a domain name that has other URI schemes from different service providers.

Note 1: This allows customers who use an INIPUI Operator in one geographic region to use another INIPUI Operator in another region without affecting the domain name used (which may be part of a corporate branding), as well as choose a different service provider for different service offerings e.g. different IMS operator compared to their email provider.

Note 2: Provisioning of the INIPUI Registry for a particular Shared Domain Name is done by a single entity, the INIPUI Host. This ensures the uniqueness of the username, when assigned by different INIPUI operators, within a Shared Domain Name. The INIPUI Host also needs to ensure each INIPUI provisioned in the INIPUI Registry is authorised by the Domain Name Owner.

– The IMS shall support a mechanism for an INIPUI User to be globally reachable by any subscriber, regardless of whether the originating operator supports INIPUI. In addition, an IMS operator that is serving inbound roaming INIPUI Users shall not be required to support any additional configuration on top of what already exists.

– The IMS shall support the use of INIPUI as an IMS identity between the calling User and their INIPUI Operator.

– The use of INIPUI shall be transparent to the UE and therefore INIPUIs shall be usable by pre-Release 11 UEs, subject to the UE support of alphanumeric SIP URI.

– When the user enters the INIPUI of the called party, the UE shall display the INIPUI that was entered, subject to the UE display capability. In case of Terminating Identification Presentation (TIP), the INIPUI of the terminating party shall be displayed according to the requirements in TS 22.173 [20].

– The IMS shall support passing of an INIPUI of the originating user and the INIPUI shall be displayed as CLI to the called party, subject to the UE display capability.

– An originating operator shall be able to request an INIPUI address resolution to be performed by an intermediate network and to receive the result of the INIPUI address resolution from that intermediate network prior to routing the session.

– An intermediate network shall be able to service INIPUI address resolutions received from an originating operator by querying the INIPUI Registry. The intermediate network shall then be able to provide the resolved INIPUI address to the originating operator.

Note: The above two requirements allow the originating operator to decide how to route the session (e.g. itself or via an intermediate network).

– An entity accessing an INIPUI Registry to resolve an INIPUI shall provide the INIPUI Registry with the identity of the operator that is the source of the query in addition to its own identity. An entity accessing an INIPUI Registry for provisioning purposes shall provide the INIPUI Registry with its own identity.

The above may be subject to regulatory requirements.

7.5.6 Void

7.5.6 Restricted local operator services

Access to restricted local operator services shall only be supported over 3GPP access.

IMS registration for an RLOS access shall not apply to any other IMS registration used by the UE.

The description of restricted local operator services and additional requirements for access to restricted local operator services are contained in 3GPP TS 22.101 [5].

7.6 Handling of an incoming session (by the terminating entity)

7.6.1 Automatic re-routing

IMS shall provide the capability to handle communications rejected (e.g. due to unavailability of PSTN/ISDN resources) using re-routing.

7.6.2 Presentation of session originator identity

The IMS shall present the identity of the session originator (see 7.5.1). The network shall suppress the presentation of the identity when requested by the session originator.

Operator policies (e.g. requirements for support of emergency communications) may over-ride the user request for suppression.

The results of any spoofed call detection which is applied to the session originator identity by the terminating IMS, shall be presented to the user based on operator policies. This spoofed call detection results presentation may be independent of the suppression of session originator identity presentation.

7.6.3 Negotiation of an incoming session

Interaction with the user profile shall be supported, and additionally direct interaction with the user may be required. Refer to clause 7.3 for further details on capability negotiation on an incoming IP multimedia session.

7.6.4 Accepting or rejecting an incoming session

It shall be possible for the user to either accept, reject, ignore or re-direct an incoming IP multimedia session. Further, it shall also be possible for the user to accept only a subset of the offered media, not have any of the media offered to him at all etc.

7.6.5 Handling of an incoming session addressed to an unallocated identity

In case of an incoming session addressed to an identity administered by the operator but not allocated to a user or a service, the IMS shall be able to reject, re-route or trigger service logic to that incoming session.

7.6.6 Differentiated paging for voice over E-UTRAN termination attempts

More efficient radio resource usage can be achieved by using a more aggressive paging profile for voice over E-UTRAN services than for other services using the IMS signaling bearer, requiring a distinction to be made between voice over E-UTRAN and non-voice over E-UTRAN traffic.

As a network option, the IMS shall support a mechanism to enable a different paging policy for voice over E-UTRAN vs non-voice over E-UTRAN services in EPC access.

7.7 Handling of an ongoing session

7.7.1 User modification of media in an ongoing session

The user shall be able to negotiate the addition or deletion of media components of IP multimedia applications during an IP multimedia session. Refer to clause 7.3 for further details on capability negotiation during an IP multimedia session.

7.7.2 Suspending and resuming of an ongoing session

It shall be possible for the user to suspend an IP multimedia session, and resume that IP multimedia session at a later time.

7.7.3 Presentation of identity of connected-to party of a session

It shall be possible to present to the originator of a session the identity of the party to which she is connected (see 7.5.1).

However, the connected-to party shall be able to request that her identity is not revealed to the originator of the session.

Operator policies (e.g. requirements for support of emergency communications) may over-ride the user request for suppression.

7.8 Ending a session

The user shall be able to end an IP multimedia session at any time during the session. The network may end an IP multimedia session at any time during the session (e.g. in failure conditions).

7.9 Void

7.10 Handling of conferences

7.10.1 General

Conferences allow users participating in the conference to communicate with all other participants simultaneously. A conference has a "conference focus" that controls the conference.

Note: A user participating in the conference, depending on the conference policy, might be allowed to communicate with the focus e.g. to request invitation of another user into the conference.

7.10.2 User requirements

7.10.2.1 General

The following minimum user requirements for conferences exist:

– A user shall be able to request the creation of a conference.

– A user shall be able to request to join an existing conference.

– A user participating in the conference shall be able to request modification of the conference (e.g. add/remove media, manipulation of data streams, add/remove participants) depending on the conference policy.

– A user participating in the conference shall be able to request termination of the conference, depending on the conference policy.

– A user participating in the conference shall be able to receive information from the conference focus (e.g. participants in conference, participants joining or leaving the conference)

– A user participating in the conference shall be able to transfer the invited participants to other focus aware conference user(s) prior to leaving the conference if that user has invited participants to the conference.

– When a user attempts to join a conference the system shall be able to check that the user is authorized to attend.

7.10.2.2 Telepresence

In addition to the requirements in clause 7.10.2.1, the following apply for Telepresence:

– A user participating in a Telepresence session shall be able to indicate which source to receive from a list of sources (e.g. a user may want the media from camera x, or might want the source chosen by a Voice Activity Detection system). This may occur during session establishment, or at any time during the session.

– A user participating in a Telepresence session shall be able to choose the way received media is composed (e.g. a user may choose a specific camera from the far end, or may want the media to be shown as Picture in Picture).

– A user participating in a Telepresence session shall be able to communicate with others using different types of UEs in the same Telepresence session (e.g. mobile phone, laptop/pc, conference room with a different number of cameras and displays).

– A designated user participating in a Telepresence session shall be able to manage the Telepresence session (e.g. launch a session, manage floor control, etc).

– A user participating in a Telepresence session shall be able to engage in presenting (e.g. slide or media sharing) in real-time.

– A user shall be able to participate in a Telepresence session from a voice only device.

– A user participating in a Telepresence session shall be able to have the same experience whether the Telepresence session is in the same operator network or across networks belonging to different operators.

– A user on network operator A shall be able to participate in the Telepresence session initiated by a user on an enterprise network or a user on network operator B.

– A user on network operator A shall be able to initiate a Telepresence session with other participants from an enterprise network or network operator B.

7.10.2.3 VR Telepresence

In addition to the requirements in clause 7.10.2.2, the following apply for VR Telepresence:

– The IMS system shall be able to select media server(s) at appropriate location(s) involved in the session based on the VR capabilities and UE information (e.g. near to the location of user).

7.10.3 Network-based Conference Focus

For the case where the "conference focus" is based in the network, the following requirements apply:

– The home network shall be able to provide the "conference focus".

– The visited network shall be able to provide the "conference focus", controlled by the home network, and subject to roaming agreements.

7.11 Handling of multicast services

Multicast services allow IMS users and service providers to send multimedia to a group of IMS users simultaneously in an unidirectional way of communication. The underlying network may be able to support mechanisms that optimize the delivery of multimedia to the individual members of that group (e.g. MBMS [7])

Note: an example for applicability of multicast services could be the IMS based "Push to talk over Cellular" service, that is being standardised by OMA.

– An IMS application located on an application server in the network shall be able to request that multimedia is sent to a group of IMS users, which are specified by this request.

– Depending on the capabilities of the underlying network IMS shall be able to use optimized mechanisms of the network (e.g. multicast capabilities such as MBMS [7]) for the delivery of multimedia to the group of IMS users.

7.12 Support for Local Numbers in the IMS

A number or short code originating from a UE may correspond to a local number based on HPLMN/VPLMN’s numbering plan, a service number in the HPLMN/VPLMN, or a private numbering plan.

A number or short code may have a local context indicator (LCI) added to it. The value of an LCI helps the HPLMN to route the call and, if necessary, route the call to the country/VPLMN/private network of origin. The LCI may include:

– access specific information consist of e.g. country code plus network code, country code plus area code, or an identification of a private numbering plan;

– the home domain;

– an indication that UE does not support processing of the dialled string; or

– any other value entered by the user.

If the HPLMN cannot interpret the number or short code based on the included LCI, the HPLMN may apply policies to translate local numbers to globally routable identity and to route the call.

The HPLMN shall analyse the received number and route the call as follows:

– If the number or short code has an LCI, the HPLMN should interpret the short code to a globally routable URI or E.164 [26] number according to the value of the LCI, and then correctly route the call. If the HPLMN is unable to resolve or route the received number then an error message shall be returned to the originating UE.

7.13 User determined user busy

The network shall support the capability of a user to reject an incoming IMS session with an indication of "user busy". This indication may be used by the network as a trigger for certain services e.g. Call Forwarding on Busy. If the session rejection is propagated back to the originator, the "user busy" indication must be provided as the cause of the rejection.

The conditions for user determined "user busy" include:

the session is offered to a single contact that rejects with a "user busy" indication; or

the session is offered to multiple contacts with a single public identity, and one contact rejects with a "user busy" indication on behalf of the set of contacts; or

the session is offered to multiple contacts; and

none of the contacts progress the session; and

one or more of the contacts rejects with a "user busy" indication.

Note: A contact is e.g. a terminal, a UE, or some other kind of equipment in the user premises.

7.14 IMS Inter-UE Transfer

The IMS shall be able to provide IMS Inter-UE Transfer between:

– different UEs connected via the same IP-CAN,

– different UEs connected via different 3GPP IP-CANs,

– different UEs connected via a 3GPP IP-CAN and a non-3GPP IP-CAN (e.g. fixed line connectivity),

– different UEs connected via different non-3GPP IP-CANs.

In addition the IMS shall be able to provide IMS Inter-UE Transfer from UEs connected via an IP-CAN to ICS entities that provide interworking with UEs in the CS Domain.

Note 1: In this case it might not be possible to retrieve the session after it has been transferred.

Note 2: When interworking with the UEs in the CS domain, the available IUT features are limited by the UE’s capabilities.

The following requirements are applicable for IMS Inter-UE Transfer.

– The IMS shall support the capability to transfer/retrieve some or all of the media components to/from different IMS UEs belonging to the same or different user(s) while providing continuous service experience to these users. In order to provide continuous service experience to the user, the receiving IMS UE capabilities (e.g. display resolutions, codecs capabilities, and access network data rate, etc.) shall be taken into consideration and the transferred sessions adapted accordingly.

– It shall be possible to provide continuous service experience when the session is transferred between IMS UEs of different capabilities.

– It shall be possible to transfer some or all media components to the target IMS UE(s) belonging to the same or different user(s) that are subscribed to the same operator. This can be initiated either directly from the controlling IMS UE or on request from the IMS UE where the media will be transferred.

– It shall be possible to replicate some or all media components to the target IMS UE(s) belonging to the same or different user(s) that are subscribed to the same operator. This can be initiated either directly from the controlling IMS UE or on request from the IMS UE where the media will be replicated.

– Replication / transfer of some or all media components to target IMS UE(s), belonging to the same or to different user(s) that are subscribed to the same operator, shall not be performed when the remote end (e.g. the source of the media) of the session restricts such operation.

– It shall be possible to transfer service control related to all media components to the target IMS UE that belongs to the same user and has subscription with the same operator. This can be initiated either directly from the controlling IMS UE or on request from the IMS UE where the control will be transferred.

Note 3: Transfer of service control and transfer / replication of media components are independent of each other. This means the above requirements include the case where certain media components are transferred / replicated to the target IMS UE(s) whilst the related service control remains in the source IMS UE or is transferred to the target IMS UE, and the case where service control is transferred to the target IMS UE whilst the controlled media components remain in the source IMS UE.

– Inter-UE Transfer shall be subject to operator policy.

– It shall be possible to discover information on ongoing IMS sessions on different IMS UEs belonging to the IUT e.g. available IMS sessions, media components, controller/controllee capability.

IMS shall support the capability to add /delete media components across different UEs belonging to the same or different user(s) that are subscribed to the same operator, while providing continuous service experience to these users.

An IMS user shall be able to control media components of an IMS session between different UEs as following:

– Add new media components to different UEs at session setup and session modification.

– Remove media components of an ongoing multimedia session from different UEs.

IMS shall support the capability to share control of media components among multiple UEs belonging to one or more users that are subscribed to the same operator. Shared control of media components may be exclusive (i.e. only one UE has the control at a time) or simultaneous (i.e. more than one UE has the control at the same time).

It shall be possible for the network to authorise shared control of media components among multiple IMS users.

It shall be possible for the IMS user controlling the session to allow one or more IMS users in the session to share control of media components.

Note 4: Inter-UE transfer use case as defined by IETF can be found in [23].

7.15 Prevention of Unsolicited Communication in IMS (PUCI)

7.15.1 High level requirements

IMS should provide means to identify and act on unsolicited communication.

Solutions for prevention against unsolicited communication shall not have negative impact on the services provided by IMS.

PUCI should provide means for cooperation between operator’s networks.

IMS should provide means for a user to inform the network of an unsolicited communication.

7.15.2 Detection of Unsolicited Communication

Depending on Operator policies IMS should support capabilities that enable IMS to detect that an IMS session is unsolicited and classify as UC. These capabilities should apply to all IMS based services and apply to real-time (e.g. voice, video …) and to non-real-time (e.g. messaging …) IMS traffic.

IMS should support capabilities that enable a terminating party to report IMS sessions as UC.

The method of reporting UC may be dependent on the IMS service.

Reporting should be possible irrespective of whether an originating party has withheld its identity (e.g. by referring to the last call).

7.15.3 Prevention of Unsolicited Communication to the terminating party

Depending on Operator policies IMS should support capabilities to indicate to a terminating party that an IMS session has been classified UC.

Depending on Operator policies IMS should support capabilities to protect a terminating party from IMS sessions that have been classified UC.

7.15.4 Notification of UC to the originating party

Depending on Operator policies IMS should support capabilities that allow notifying an originiating party that a performed or attempted communication to the terminating party has been classified as UC.

7.15.5 Conveying information on UC to other networks

Depending on Operator policies IMS should support capabilities that enable the IMS of a network to convey information on detected UC in an IMS session to an other IMS on the path of that IMS session

7.16 Support for Push Notification Service in IMS

The IMS shall be able to support SIP based Push Notification Service as defined in [28].