22.2783GPPService requirements for the Evolved Packet System (EPS)TS
6.1 Support of IP traffic
6.1.1 Support of increased IP traffic demand
The Evolved Packet System shall be able to provide guaranteed QoS for services and use the resources of the Evolved Packet System with high efficiency i.e. ensure that quality conditions for a particular communication are fulfilled without deterioration between the communicating end-points.
6.1.4 Support of basic IP connectivity
Following registration on the network, the Evolved Packet System shall maintain an IP connectivity with the UE. Following registration, it shall be possible for an UE to send and receive IP packets.
6.1.5 Support of IP multicast service
The Evolved Packet System shall support IP multicast service.
6.2 IP session control
The Evolved Packet System shall provide for session mobility and session adaptation to terminal capabilities, user preferences, subscriber priorities, network conditions and/or other operator-defined criteria. Session adaptation shall be under the control of the operator.
The Evolved Packet System shall support session control for multi-party sessions (e.g. user-to-group) and shall provide a scalable solution.
In order to support the efficient routing of IP traffic, local breakout (see Section 7.1.2) shall be supported.
The Evolved Packet System shall support a UE having simultaneously more than one active PDN connections exchanging traffic with more than one peer (external network or other UE), when the network policies and user subscription allow it.
If a UE is under the coverage of 3GPP access and one or more non-3GPP accesses, it shall be possible for the UE to communicate using multiple accesses simultaneously.
The Evolved Packet System shall provide the system operator with the means to control the number of simultaneously active PDN connections and combinations thereof to and from a UE.
A single application running on the UE shall not be required to send and receive traffic through multiple PDNs.
6.3 Quality of Service
The Evolved Packet System shall have the ability to provide a quality of service equal to or better than the QoS requirements specified for GSM and UMTS. Quality of Service from the customer’s perspective is to be considered in phases as specified in ETSI TS 102 250-1.
Figure 2: Phases of service use from customer’s point of view
Figure 2 shows the different phases (Quality of Service aspects) during service use from the customer’s point of view.
The meaning of these QoS aspects are:
1) Network Access: The network indication on the display of the mobile is a signal to the customer that he can use the service of this network operator (or any other means to indicate to the user that a network is available).
2) Service Access: If the customer wants to use a service, the network operator should provide him as fast as possible access to the service.
3) Service Integrity: This describes the Quality of Service during service use.
4) Service Retainability: Service Retainability describes the termination of services (in accordance with or against the will of the user).
In particular the Evolved Packet System shall provide for the following:
– There should be no perceptible deterioration of audio quality of a voice call during and following handover between dissimilar CS and PS access networks, and transitions between PS access networks supporting different IP protocol versions.
– There should be no loss of data, as a result of handovers between dissimilar fixed and mobile access systems, including those that support different versions of the IP protocol.
– There should be no discernable difference in perceived service quality for users receiving services via unicast and users receiving the same service via multicast.
– The Evolved Packet System shall support QoS differentiations for unicast bearers.
– The Evolved Packet System shall support QoS backwards compatibility to earlier 3GPP QoS releases.
– It shall be possible for the Evolved Packet System to maintain end-to-end QoS without modification when the terminal moves from one access system to a new access system, and the new access system supports the required QoS.
– It shall be possible for the Evolved Packet System to change QoS, when the terminal moves from one access system to a new access system and the new access system can not provide the same QoS as the old access system or the new access system can provide higher QoS.
– It shall be possible for the Evolved Packet System to support service continuity for a terminal changing access system and the new access system cannot provide the same QoS as the old one.
– The Evolved Packet System shall support transport QoS differentiations for multicast bearers.
– It shall be possible for the Evolved Packet System to maintain QoS within a multicast session without QoS changes for other members of the session when a terminal joins or leaves the multicast session or moves to a new access system.
– The Evolved Packet System network shall support a minimum of 8 levels of QoS in parallel.
– The Evolved Packet System network shall support a minimum of 4 parallel RT QoS levels with the appropriate QoS differentiation.
Note 1: The requirement for the number of simultaneously supported QoS levels is independent of any MBMS QoS levels.
– Multiple RT services, with similar QoS requirements, shall be served by the same RT QoS level and multiple NRT services, with similar QoS requirements, shall be served by the same NRT QoS level.
The maximum number of parallel RT and NRT services shall not be limited in the Evolved Packet System including the UE. Only the number of parallel RT and NRT QoS levels are limited to the upper value supported by the Evolved Packet System.
– Differentiated handling based on QoS is needed for different traffic types.
– The Evolved Packet System shall support parallel operation of RT and NRT services per user.
Note 2: The different QoS levels provided for RT and NRT services would be differentiated with regards to e.g. maximum end-to-end delay, packet size, packet drop percentage, etc. Bandwidth is not used to define a QoS level.
6.4 Support of Multicast and Broadcast Services
The Evolved Packet System shall be able to support Multicast and Broadcast Services which shall be enhanced especially from some aspects, e.g. optimized service provisioning procedures, better performance compared to current MBMS system, and support of multiple access systems.
6.5 Support of Emergency Calls
The Evolved Packet System shall support IMS emergency calls applicable to the PS domain, defined in TS 22.101 
6.6 Differentiated paging for voice over E-UTRAN terminations
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 EPS shall support a mechanism to apply a different paging policy to E-UTRAN access for voice services vs. other services using the IMS signaling bearer.
6.7 Support of streaming services
A 3GPP system shall support a mechanism to indicate to UEs that operator streaming services are available.
The 3GPP system shall be able to support UE caching for streaming services.
Based on operator policy, the 3GPP system shall support a mechanism that the subscribed UE is configured with the list of authorized content providers and data volume for UE caching of streaming services.
The 3GPP system shall be able to schedule delivery of a download-and-play service to UE to the off-peak hours.
The 3GPP system shall be able to support local connection to local streaming servers according to operator’s policy.
The 3GPP system shall be able to configure local streaming service area according to operator’s policy.
The 3GPP system shall be able to identify a user is in the specific local streaming service area.
The 3GPP system shall be able to identify a user is not in the specific local streaming service area and stop the local streaming service.
The 3GPP system shall be able to deliver streaming content via local service delivery immediately or postponed according to user’s preference.
According to the mobility of the users who do not always stay in one place, the 3GPP system should be able to adaptively change video server and the route to continue supply experience for streaming service, e.g. from a local streaming server to a non-local streaming server, vice versa.
According to operator’s policy, the 3GPP system shall be able to configure which context information is related with streaming route.
The 3GPP system shall be able to collect context information related to update streaming route according to operator’s policy.
According to agreement between application server and Operator, the 3GPP system shall support the operator or the 3rd party to configure which user profile information belonging to the application server should be shared with the 3GPP system.
According to operator’s policy, the 3GPP system shall support the SHE which is deployed in different local area (no matter belongs to operator or the 3rd party) to configure which radio environment information can be shared to the application layer which is hosted in the SHE.
According to operator’s policy, the 3GPP system shall support the SHE which is deployed in different local area (no matter belongs to operator or the 3rd party) to get radio environment information based on the configuration.
6.8 IoT resource efficiency
The 3GPP system shall support efficient transmission of IP data and non-IP data to/from a UE.
The 3GPP system shall support efficient transmission of small data to/from a UE.
The 3GPP system shall minimize control and user plane resource usage for stationary UEs (e.g., lower signalling to user data resources usage ratio).
The 3GPP system shall optimize the resource usage of the control plane and/or user plane for transfer of small data units.
The 3GPP system shall support methods to minimize the usage of battery resources at the UE.
6.9 Context aware network
The 3GPP system shall support network resource utilization efficiently and network optimization based on context information, including:
– network conditions, such as network load and congestion information;
– information on served UEs such as access information (e.g., 3GPP access, non-3GPP access), cell type (e.g., macro cell, small cell);
– information on prioritized communication such as user subscription profile and priority level, priority services (e.g., MPS, Emergency, and Public Safety), application used for priority communications (e.g., voice, video, and data) and traffic associated with priority communications (signalling and media).
6.10 Support of MUSIM UE
With the growing demand in the consumer market, some commercially deployed UEs support more than one USIM (typically two)-. For example, a user can use the MUSIM UE to install another USIM with local data service when traveling, or to have both a work related USIM and a personal USIM. With support of MUSIM UEs in the 3GPP system, the system performance and user experiences are expected to be improved.
The 3GPP system shall be able to support a MUSIM UE with multiple USIMs provided by the same or different Network Operators as described at clause 13.4 in .
The 3GPP system shall enable the end user to select the mobile terminated services that can take priority over ongoing communications associated with another USIM.
NOTE: Regulatory required services are not subject to this requirement.
The 3GPP system shall enable a MUSIM UE in coordination with the network to pause and continue an active communication for efficient use of resources.
The 3GPP system shall be able to effectively page MUSIM UEs in order to reduce missed paging.