Content for TS 22.101 Word version: 19.1.0
30 Flexible Mobile Service Steering
30.1 Introduction
30.2 General Requirements
31 Control of traffic from UE-based applications toward associated server
31.1 Description
31.2 Requirements
31.2.1 Control requirements
31.2.2 Requirements on awareness of third-party server issue
32 3GPP enhancement for TV application support
32.1 Feature description
32.2 Requirements
32.2.1 General requirements
32.2.2 Requirement for transmission performance enhancement
32.2.3 Requirement for network flexibility
32.2.4 Requirement for TV application support
32.2.5 Requirement for RAN sharing
32.2.6 Requirement for wide area support
32.2.7 Requirement for capability exposure
32.2.8 Fixed reception for TV services
33 Usage over unlicensed access
33.1 Description
33.2 Requirements
35 Restricted local operator services
35.1 Description
35.2 Requirements
...
...
30 Flexible Mobile Service Steering |R13| p. 75
30.1 Introduction p. 75
The term (S)Gi-LAN used in the present document represents a system which is out of 3GPP scope. Corresponding term for the 5G network is N6-LAN.
For traffic steering to service functions in 5G network, enhancement beyond the service requirements below are defined in [59].
30.2 General Requirements p. 76
The following requirements apply:
- The 3GPP Core Network shall be able to define and modify traffic steering policies that are used to steer traffic in (S)Gi-LAN containing operator or 3rd party service functions e.g. to improve e.g. the user's QoE, apply the bandwidth limitation and provide valued added services.
- Traffic steering policy shall be able to distinguish between upstream and downstream traffic.
- The 3GPP Core Network shall be able to define different traffic steering policies for a user's traffic on a per session basis (e.g. for applying parental control, anti-malware, DDoS protection, video optimization).
-
The 3GPP Core Network defines traffic steering policies based on one or more pieces of information such as:
- network operator's policies
- user subscription (e.g. user's priority, the status of optional subscriber services from the subscription data, based on service provider used, subscribed QoS)
- user's current RAT
- the network (RAN and CN) load status
- application characteristics such as: application type (video, web browsing, IM, etc), application protocol ( HTTP, P2P, etc), target address name (URL) and application provider (My tube, etc)
- time
- UE location
- information (e.g. APN) of the destination network (i.e. a PDN or an internal IP network) of traffic flow
- In case of roaming, the HPLMN shall be able to apply traffic steering policies for home routed traffic.
31 Control of traffic from UE-based applications toward associated server |R14| p. 77
31.1 Description p. 77
This feature is a set of service features that allows operators to control traffic from UEs to an application on a third-party server or the third-party server itself. When an application on a third-party server or the third-party server itself becomes congested or fails the traffic towards that server need to be controlled to avoid/mitigate potential issues caused by resulting unproductive use of 3GPP network resource. This will also make it possible to allow 3GPP network to help third-party servers to handle overload and recover from failures. (see [11])
31.2 Requirements p. 77
31.2.1 Control requirements p. 77
The 3GPP network shall be able to control (i.e. block and/or prioritize) traffic from UEs to an application on a third-party server or the third-party server itself without affecting traffic to other applications on the third-party server or to other third-party servers.
For this purpose, the 3GPP network shall be able to identify the third-party server or the application on the third-party server, and the traffic towards it.
When congestion or failure of the application on the third-party server or the third-party server abates the 3GPP network shall be able to apply this feature in a phased manner to gradually restore traffic according to operator policy.
The 3GPP network shall be able to control traffic through this feature based on:
- the traffic load on the 3GPP network,
- the MNO policy,
- the MNO's service subscription profiles such as access class information, and
- third-party service subscription profiles
31.2.2 Requirements on awareness of third-party server issue p. 77
The 3GPP network shall be able to receive a status indication from the third-party server when an application on it is experiencing congestion or failure, and when normal operation resumes. Such a status indication may be sent periodically, and/or when the status of the application changes.
The 3GPP network shall be able to detect and monitor a third-party server's operational status e.g. congestion levels, failure and unavailability of the third-party server.
32 3GPP enhancement for TV application support |R14| p. 77
32.1 Feature description p. 77
3GPP enhancement for TV service support is a feature whereby 3GPP networks can provide unicast and broadcast transport, referred to as "TV transport services", to support distribution of TV programs. TV transport services can support the three types of TV services - Free-to-air (FTA), Free-to-view (FTV), and Subscribed services. Each type of TV service has different requirements in order to meet regulatory obligations and public service and commercial broadcaster's requirements regarding content distribution, hence many requirements captured below are optional to implement depending on the type of TV transport services an MNO chooses to offer.
32.2 Requirements p. 78
32.2.1 General requirements p. 78
The 3GPP network shall be able to support on-demand network capacity assignment for TV services.
The 3GPP system shall allow the MNO to implement a network supporting downlink only broadcasting based on a set of EPS functionalities and entities which are required to offer linear TV services.
The 3GPP network shall be able to support on-demand network broadcast service area coverage management for TV transport services.
The 3GPP network shall support content delivery up to UHD resolution.
The 3GPP network shall allow the MNO to authenticate a subscriber before providing TV transport services via unicast.
The 3GPP network shall allow the MNO to authenticate a subscriber before providing TV transport services via eMBMS broadcast.
The 3GPP network shall enable an MNO to allow a UE to receive TV transport services via eMBMS broadcast without authentication.
The 3GPP network shall be able to provide FTA TV services receivable by UEs subscribed to the MNO and roaming UEs of other MNOs. A UE supporting enhanced TV transport services and in limited service state shall be able to receive eMBMS broadcast TV transport services.
The 3GPP network shall provide the ability for an MNO to meet regulatory requirements for privacy and non-identification of a receiving user by entities outside of the MNO.
The 3GPP network shall provide mechanisms to restrict the reception of some or all Subscribed TV services to groups of subscribers (e.g. based on the recipients of the services are subscribers of the MNO, roaming subscribers of other MNOs, or not subscribed to any MNO).
The quality of experience of the TV service shall be independent from the size of the concurrent audience. While receiving TV services in normal service state, subscribers of the MNO and roaming subscribers shall be able to access other subscribed services such as voice, data or SMS.
The 3GPP network shall support combinations of SD, FHD and UHD resolution TV transport services.
The 3GPP network shall allow the MNO to provide a TV service in a resource efficient manner over a large area up to the size of a country.
The 3GPP network shall enable the quality of experience of the TV service to be ensured throughout the coverage area defined for the TV service.
32.2.2 Requirement for transmission performance enhancement p. 78
The 3GPP system shall be able to support 20Mbps over one logical broadcast channel.
The mechanisms in the 3GPP network shall be designed to support at least 10 high quality video channels of 12Mbps each simultaneously via broadcast.
The 3GPP network shall support flexible change between broadcast and unicast per traffic demand over the same carrier.
The 3GPP network shall be able to convert network unicast capacity to network broadcast capacity and vice versa so that each can range from 0% to 100% of the capacity.
The 3GPP network shall be able to support using one carrier for both unicast and broadcast distribution of TV services.
If allowed by the operator and a spare carrier is available, the 3GPP network shall be able to make use of spare carriers or free up carriers if not required anymore.
32.2.3 Requirement for network flexibility p. 79
The 3GPP network shall be able to support network broadcast capacity assignment according to operator policies to consider the following criteria:
- OTT provider request (including TV service information (e.g., codec information, media type information, etc))
- available network unicast/broadcast capacity of 3GPP network
- static allocation, i.e., pre-defined maximum percentage to be used for unicast and broadcast
- dynamic allocation, i.e., the pre-defined maximum percentage for both unicast and broadcast to be changed at a time-resolution of [one] minute over a period of [24] hours
- OTT provider request (including the potential coverage information of TV service information)
- available network unicast/broadcast capacity of 3GPP network
- number of users under broadcast network coverage
- The location information of UE
32.2.4 Requirement for TV application support p. 79
The eMBMS service layer should support audio and video formats typically supported by TV Content Providers for SD and HD TV transport services and UHD TV transport services.
The eMBMS service layer should support codecs typically supported by TV Content Providers for HD TV services and UHD TV services. The eMBMS service layer should support accessibility functions typically supported by TV Content Providers (e.g. subtitling, closed captioning, audio descriptions, anonymous reception, reporting to support ratings, reporting enforcement, etc.).
The eMBMS service layer should support regulatory mandates typically supported by TV Content Providers (blackouts, emergency alerts, etc.).
The eMBMS service layer should support interactivity functions typically supported by TV Content Providers (interactive services, second screen, personalization, etc.).
The eMBMS service layer should support ad insertion use cases typically supported by TV Content Providers (targeted ad insertion, ad replacement, etc.),
The eMBMS service layer should support encryption, security and conditional access functions typically supported by TV Content Providers.
The eMBMS service layer should support efficient concurrent delivery of multiple application components (TV service application signalling, statistical multiplexing, etc.).
The eMBMS service layer should support random access and channel change times comparable to existing HD TV services.
The eMBMS service layer should support TV service content delivery over broadcast only, unicast only and combinations of the two.
The eMBMS service layer should support delivery of real-time and non-real-time content.
The eMBMS service layer should enable extensibility and forward-compatibility to new requirements, formats, codecs and other functions to the extent possible.
An eMBMS transport layer should be able to transport TV streams formatted not compliant to 3GPP standards.
A UE should be able to access an eMBMS transport session with the support of only transport metadata.
An eMBMS system should be able to be initiated by a UE with sufficient metadata provided by a mechanism other than User Service Description for non 3GPP transport services.
32.2.5 Requirement for RAN sharing p. 80
A participating eMBMS-enabled RAN shall be capable of distributing the content including both free-to-air content and subscribed content in conjunction with other participating eMBMS-enabled RANs.
The hosting eMBMS-enabled RAN network provider shall be able to manage the shared eMBMS network to each of the participating MNOs.
Each RAN provider shall report events supporting the accounting of network resource usage separately for each Participating MNO. This includes:
- Start of service in the shared eMBMS network for a UE of the Participating MNO
- End of service in the shared eMBMS network for a UE of the Participating MNO
32.2.6 Requirement for wide area support p. 80
The eMBMS network shall be able to support designated coverage area, for example national, regional and local coverage areas.
32.2.7 Requirement for capability exposure p. 80
The 3GPP system shall be able to support an MNO offering on-demand broadcast availability to TV services.
Subject to MNO and 3rd OTT party agreement, to enable the MNO to evaluate the impact on distribution of data transfer in the network, the 3rd OTT party shall be able to indicate to the MNO the desired media format information: the volume of the data traffic expected to be broadcast in this geographic area, indication whether the streaming content can be accessed when the mobile users moves out/in of broadcast coverage area, indication whether the streaming content can be cached in the MNO network, association information among users i.e. user information, expected media content information, device information and group information of TV service and the timing relationship information of different media content.
The 3GPP network shall enable an MNO to inform a 3rd party of the result (e.g., selected media format information, mode of content delivery (broadcast only, broadcast/unicast fall-back support, consumption-based switching between unicast/broadcast), QoE of content delivery, cached content indication) of delivering a TV service to a user.
32.2.8 Fixed reception for TV services p. 80
The 3GPP network shall allow a UE to receive a broadcast TV content using existing TV antenna equipment.
The 3GPP network shall allow a UE to receive unicast TV content using existing TV antenna equipment, at least for the downlink
33 Usage over unlicensed access |R15| p. 81
33.1 Description p. 81
It is important to document usage over unlicensed access such that an operator has the facility to determine which type of access the traffic was transported over.
For example, LTE-WiFi Aggregation (LWA) and License Assisted Access (LAA) are two features whereby a UE is connected to two access technologies at the same time, i.e., a primary access and a secondary access, where the secondary access technology operates in unlicensed spectrum.
33.2 Requirements p. 81
The 3GPP network shall be able to identify traffic which was transported over unlicensed access.
34 Void
35 Restricted local operator services |R16| p. 81
35.1 Description p. 81
Access to restricted local operator services by unauthenticated UEs is based on FCC regulations in the U.S. related to manual roaming as noted in the Code of Federal Regulations (CFR) Title 47 Chapter 1 Subchapter B Part 20 Section 20.3 and the Code of Federal Regulations (CFR) Title 47 Chapter 1 Subchapter B Part 20 Section 20.12 (Resale and Roaming) Subparagraph c [60].
The restricted local operator services offered by an operator are out of scope of 3GPP. Allowing access to restricted local operator services is completely under the local operator's control. The local operator can restrict unauthenticated UEs to be able to access restricted local operator services exclusively.
Authenticated UEs in limited service state may also be able to use restricted local operator services.
35.2 Requirements p. 81
Based on operator policy and national regulations, the 3GPP system shall support a mechanism to indicate to UEs that restricted local operator services are available.
A UE shall be able to explicitly request access to a network offering restricted local operator services in order to access restricted local operator services.
A UE explicitly requesting access to a network offering restricted local operator services in order to receive restricted local operator services shall not be put into limited service state.
Based on operator policy and national regulations, the 3GPP system shall support mechanisms to allow access to restricted local operator services by unauthenticated UEs.
The network shall be able to isolate restricted local operator services and usage from the rest of the network (i.e., similar to security for unauthenticated CS or IMS emergency calls).
When a UE recognizes an origination attempt to a restricted local operator service and has not received an indication from the serving system that restricted local operator services are available, the UE shall block the origination attempt.
The UE shall include the restricted local operator service call type indicator when an origination attempt is made for a restricted local operator service.
