5 High level requirements
22.2283GPPRelease 16Service requirements for the Internet Protocol (IP) multimedia core network subsystem (IMS)Stage 1TS
Support for IP multimedia sessions shall be provided in a flexible manner to allow operators to differentiate their services in the market place as well customise them to meet specific user needs. This shall be provided by the use of service capabilities in both networks and terminals, including both Personal Mobility and Terminal Mobility, for the creation and support of IP multimedia applications.
The following high level requirements shall be supported for IP multimedia applications:
– Negotiable QoS for IP multimedia sessions both at the time of a session establishment as well as during the session by the operator and the user
– Negotiable QoS for individual media components in an IP multimedia session both at the time of establishing a media component as well as when the media component is active by the operator and the user
– End to end QoS for voice at least as good as that achieved by the circuit-switched wireless systems shall be enabled
– Support of roaming, negotiation between operators for QoS and for Service Capabilities is required. Such negotiation should be automated rather than manual, e.g., when another operator adds new service capabilities.
– Support of roaming and interconnection shall include the capability for media to be routed optimally between IMS operators, i.e. according to criteria set by the operators.
– Possibility for a network operator to implement IP Policy Control for IP multimedia applications.
– IP multimedia sessions shall be able to support a variety of different media types. A set of media types shall be identified to ensure interoperability (e.g. default codec selection and header compression).
– Within each IP multimedia session, one or more IP multimedia applications shall be supported. It shall be possible to support multiple IP multimedia applications to efficiently provide a coherent and consistent IP multimedia service experience. Such support involves identifying which applications are invoked per subscriber, understanding the appropriate order of the set of applications, and resolving application interactions during the session.
– The possibility for IP multimedia applications to be provided without a reduction in privacy, security, or authentication compared to corresponding packet switched and circuit switched services.
– IMS shall be capable to provide transcoding (at least for voice sessions) where needed when two UEs do not support a common codec.
– Interconnection between two IMS domains shall be supported.
Note: see also Section 10
– Roaming shall be supported enabling users to access IP multimedia services provisioned by the:
– Home Environment
– Serving Network
– The principle of access independence shall be supported. It is desirable that an operator should be able to offer services to their subscribers regardless of how they obtain an IP connection (e.g. E-UTRAN, UTRAN, GERAN, fixed lines, LAN, DOCSIS®, WiMAX™ and cdma2000® access).
Note: Access independence principle can only be ensured by 3GPP for the access technologies 3GPP has defined or has defined specific interworking.
– It shall be possible for the users to access IM CN via an IP connection (e.g. GPRS, fixed lines, LAN) with Network Address Translation (NAT) deployed.
– IM CN should provide support for the users to access IM CN through a Firewall (FW) with configuration restrictions (e.g. only HTTP allowed, port range limitation) deployed outside operators’ domain.
– It shall be possible to support session-related internet applications that have been developed outside the 3GPP community.
– It shall be possible to limit the view of an operator’s network topology to authorised entities.
– It shall be possible to support the multiple UEs associated with a single IMS service subscription. It shall be possible to share one Public User Identity between multiple UEs. It shall also be possible to identify the individual UEs with separate Public User Identities. IMS shall be able to route sessions towards the identified UE(s), e.g. based on UE capability, User preference and/or Network preferences.
– It shall be possible for a service to identify and interact with a specific UE even when multiple UEs share the same single Public User Identity. A UE shall be capable to identify and interact with a specific UE even when multiple UEs share the same single Public User Identity, except when the UE supports only limited capabilities and thus is unable to become engaged in a service that requires such functionality. Examples include a telemetry-only capable UE that only supports the capabilities for point-to-point communication.
– The IMS shall support a mechanism to provide configuration parameters and obtain operational status of the UE. This includes the ability to provide software upgrade, service configuration, and collect operational status. According to operator policies this information may be provided to applications.
– The IMS shall be capable to access user location information, whether the user is roaming or not. According to operator policies this information may be provided to applications.
– Where required (e.g. by regulation) the IMS shall provide the capability for the user to indicate to the network that a communication is malicious.
Note: see also MCID in [20].
– Where required (e.g. by regulation) the IMS shall provide the capability for the network, on behalf of the user, to reject incoming communications from users who have restricted the presentation of their originating identity.
Note: see also ACR in [20].- The IMS shall be able to support a Group Communication with end-to-end setup time defined in TS 22.468, clause 5.1.2 [35].
NOTE: Roaming case is out of scope.
– The IMS shall support the capability of enabling early media for an IMS multimedia session. The capability for such early media shall be applied towards both calling and called user.
Note: Early media refers to media (e.g., audio and video) that is exchanged before a particular session is accepted by the called user.
– The IMS shall have mechanisms available to control overload that:
1) automatically maximize effective throughput (i.e. admitted service requests/sec) at an overloaded resource.
2) achieve this throughout the duration of an overload event, and irrespective of the overloaded resource’s capacity or of the number of sources of overload;
3) are configurable by the service provider so that, under processing overload, a high proportion of response times at overloaded resources are low enough so as not to cause customers to prematurely abandon service requests;
4) should be possible to be applied within a service provider’s IMS, and between different service providers’ IMSs;
5) should be possible to be applied within an IMS subsystem and between different IMS subsystems.
NOTE: As a general rule, an IMS’s call, session and command processing resources can experience prolonged processing overload under the appropriate circumstances (e.g. partial, or full, server failure, high rates of incoming service requests). Consequently, it needs to be equipped with some form of overload detection and control (including expansive controls such as load balancing and resource replication), in order to keep response times just low enough under such processing overload to preclude customers abandoning their service requests prematurely.
– 5G system shall be able to support IMS in non-public networks [36].