Tech-invite3GPPspaceIETF RFCsSIP
index21222324252627282931323334353637384‑5x

Content for  TS 22.101  Word version:  18.4.0

Top   Top   Up   Prev   Next
1…   4…   5…   10…   11…   13…   21…   26a…   A…

 

26a  User Identity |R16|p. 64

26a.1  Introductionp. 64

Identifying distinguished user identities of the user (provided by some external party or by the operator) in the operator network enables an operator to provide an enhanced user experience and optimized performance as well as to offer services to devices that are not part of a 3GPP network. The user to be identified could be an individual human user, using a UE with a certain subscription, or an application running on or connecting via a UE, or a device ("thing") behind a gateway UE.
Network settings can be adapted and services offered to users according to their needs, independent of the subscription that is used to establish the connection. By acting as an identity provider, the operator can take additional information from the network into account to provide a higher level of security for the authentication of a user.
Up

26a.2  Requirementsp. 64

26a.2.1  User Identifiers and user authenticationp. 64

The 3GPP system shall be able to provide User Identities with related User Identifiers for a user.
The User Identifier shall be independent of existing identifiers relating to subscription or device (e.g. IMSI, MSISDN, IMPI, IMPU, SUPI, GPSI, IMEI) and of other User Identifiers.
The User Identifier may be provided by some entity within the operator's network or by a 3rd party.
The 3GPP system shall support to interwork with a 3rd party network entity for authentication of the User Identity.
The 3GPP system shall support to perform authentication of a User Identity regardless of the user's access, the user's UE and its HPLMN as well as the provider of the User Identifier.
The 3GPP network shall be able to provide a User Identifier for a non-3GPP device that is connected to the network via a UE that acts as a gateway.
The 3GPP network shall support to perform authentication of a User Identity used by devices that are connected via a UE that acts as a gateway.
The 3GPP system shall be able to take User Identity specific service settings and parameters into account when delivering a service.
A subscriber shall be able to link and unlink one or more user Identities with his 3GPP subscription.
The 3GPP system shall support user authentication with User Identifiers from devices that connect via the internet; the 3GPP system shall support secure provisioning of credentials to those devices to enable them to access the network and its services according to the 3GPP subscription that has been linked with the User Identity.
The 3GPP system shall support secure provisioning of credentials to a non-3GPP device connected via a gateway UE, whose User Identifier has been linked with the 3GPP subscription of the gateway UE, to enable the non-3GPP device to access the network and its services according to the linked 3GPP subscription when connected via non-3GPP access.
The 3GPP system shall be able to assess the level of confidence in the User Identity by taking into account information regarding the used mechanism for obtaining that User Identity (e.g. algorithms, key-length, time since last authentication), information from the network (e.g. UE or device in use, access technology, location).
The operator and the subscriber shall be able to restrict the number of simultaneously active User Identifiers per UE.
Up

26a.2.2  Access to servicesp. 65

The 3GPP System shall support to authenticate a User Identity to a service with a User Identifier.
The 3GPP system shall be able to provide information to services concerning the level of confidence of the User Identity and authentication process.
A service shall be able to request the 3GPP network to only authenticate users to the service for which the association of the user with a User Identifier has been established according to specified authentication policies of the service.
When a user requests to access a service the 3GPP System shall support authentication of the User Identity with a User Identifier towards the service if the level of confidence for the correct association of a User Identity with a User Identifier complies to specified policies of the service.
The 3GPP network shall be able to take the User Profile into account when assigning a UE to a network slice, moving a UE from one network slice to another, and removing a UE from a network slice.
The 3GPP system shall support to allow a UE access to a slice based on successful User Identity authentication.
The 3GPP system shall support to deny a UE access to a slice based on unsuccessful User Identity authentication.
Up

26a.2.3  User Identity Profile and its User Identities |R18|p. 65

The 3GPP system shall be able to store and update a User Profile for a user.
The User Profile shall include a User Identifier.
The User Profile may include one or more pieces of the following information:
  • additional User Identifiers of the user's User Identities and potentially linked 3GPP subscriptions,
  • used UEs (identified by their subscription and device identifiers),
  • capabilities the used UEs support for authentication,
  • information regarding authentication policies required by different services and slices to authenticate a user for access to these services or slices.
  • User Identity specific service settings and parameters.
    Those shall include network parameters (e.g. QoS parameters), IMS service (e.g. MMTEL supplementary services) and operator deployed service chain settings.
  • User Identity specific network resources (e.g., network slice).
The user shall be able to activate, deactivate and suspend, i.e. temporarily deactivate, the use of the User Identifiers per device or UE and the associated settings in its user profile.
Subject to operator policy the 3GPP system shall be able to update User Profile related to a User Identifier, according to the information shared by a trusted 3rd party.
Up

26a.2.4  Operator requirementsp. 65

The operator shall be able to enable or disable the use of a User Identifier in his network.
The 3GPP System shall support operators to act as User Identity provider and to authenticate users for accessing operator and non-operator deployed (i.e. external non-3GPP) services
The operator shall be able to set the boundaries within which the user specific settings are taken into account in his network. The operator shall be able to restrict the feature depending of the provider of the User Identifier, the roaming status of the UE, the service and its specific parameters.
The operator shall be able to set restrictions for devices accessing the network and its services via non-3GPP access with their User Identity linked to a 3GPP subscription. The 3GPP system shall support restrictions based on the User Identity provider, the roaming status of the linked 3GPP subscription, and the network service that is accessed.
The 3GPP system shall be able to support automatically suspending an active User Identity after a certain period of time of user inactivity, e.g. up to one hour, as configured by the operator.
The 3GPP system shall be able to support a fast re-activation for a suspended User Identity, based on MNOs' configuration.
The 3GPP system shall enable a user to configure, within the boundaries set by the network operator, which services shall be available on a device where a user logs in. These services include voice, video, and messaging.
Up

26a.2.5  Privacy requirementsp. 66

The 3GPP system shall protect the privacy of the user by transferring to a service only User Identity information that is necessary to provide the service and for which the user has consented to when registering for the service.

27  User plane congestion management |R13|p. 67

27.1  Introductionp. 67

RAN user plane congestion, in the context of this clause, is considered to be downlink congestion that affects the user plane, which may last for a few seconds, a few minutes, or a few hours due to arrival of new active users, increase of communication intensity of existing users, the radio environment changing, the mobile user changing location, and other reasons, thus causing the capacity of RAN resources to transfer user data to be exceeded. A short-duration burst of user plane traffic should not be identified as RAN congestion.
Up

27.2  Generalp. 67

  1. The network shall be able to detect RAN user plane congestion onset and abatement. Mechanisms to cope with RAN user plane congestions should be resilient to rapid changes in the level of congestion.
  2. The network shall be able to identify whether or not an active UE is in a RAN user plane congested cell.
  3. The network operator shall be able to configure or provision and enforce policy rules to best deal with RAN user plane congestion.
  4. The system should react in a timely manner to manage a RAN user plane congestion situation, i.e. that the measures taken become effective to promptly help resolve the RAN user plane congestion.
  5. The signalling overhead caused by RAN user plane congestion management solutions in the system shall be minimized.
  6. The network shall be able to take into consideration the RAN user plane congestion status and the subscriber's profile when coping with traffic congestion.
Up

27.3  Prioritizing trafficp. 67

  1. According to operator policy, during RAN user plane congestion the operator shall be able to select the communications which require preferential treatment and allocate sufficient resources for such communications in order to provide these services with appropriate service quality.
  2. According to operator policy, the network shall be able to select specific users (e.g. heavy users, roaming users, etc.) and adjust the QoS of existing connections/flows and apply relevant policies to new connections/flows depending on the RAN user plane congestion status and the subscriber's profile.
Up

27.4  Reducing trafficp. 67

  1. Based on RAN congestion status and according to operator policy, the network shall be able to reduce the user plane traffic load (e.g. by compressing images or by adaptation for streaming applications) taking into account UE related information (e.g. UE capabilities, subscription).
  2. The system shall be able to adjust the communication media parameters of real-time communications so that they consume less bandwidth.

27.5Void

28  RAN Sharing Enhancements |R13|p. 68

28.1  Generalp. 68

RAN Sharing Enhancements allow multiple Participating Operators to share the resources of a single RAN according to agreed allocation schemes. The Shared RAN is provided by a Hosting RAN Operator which can be one of the Participating Operators.
The Shared RAN can be GERAN, UTRAN, E-UTRAN or NG-RAN as described below.
All the following requirements shall be subject to Hosting RAN Operator configuration.

28.2  Specific E-UTRAN and NG-RAN Sharing requirementsp. 68

28.2.1  Allocation of Shared E-UTRAN and NG-RAN resourcesp. 68

When E-UTRAN and NG-RAN resources are shared they can be allocated unequally to the Participating Operators, depending on the planned or current needs of these operators and based on service agreements with the Hosting E-UTRAN/NG-RAN Operator.
The following requirements apply:
The Hosting E-UTRAN/NG-RAN Operator shall be able to specify the allocation of E-UTRAN/NG-RAN resources to each of the Participating Operators by the following:
  1. static allocation, i.e. guaranteeing a minimum allocation and limiting to a maximum allocation,
  2. static allocation for a specified period of time and/or specific cells/sectors,
  3. first UE come first UE served allocation.
  4. the type and number of 5G slices
Resources include both user plane and signalling plane. The Hosting E-UTRAN/NG-RAN Operator needs to be able to manage the sharing of the signalling traffic independently from that of the user traffic because signalling traffic and user traffic are not always directly related. For example for MTC devices, the signalling traffic volume can be high and the user traffic volume low whereas for downloading video, the signalling traffic is low and the user traffic is high.
The following requirements apply:
The management and allocation of resources of signalling traffic over the Shared E-UTRAN/NG-RAN shall be independent from the management and allocation of resources of the user traffic over the Shared E-UTRAN.
A Shared E-UTRAN/NG-RAN shall be capable of differentiating traffic associated with individual Participating Operators.
A Shared E-UTRAN/NG-RAN shall be able to conduct admission control based on the allocated E-UTRAN/NG-RAN resources for each Participating Operator.
A Hosting E-UTRAN/NG-RAN Operator shall be able to control resource usage taking into account the allocated E-UTRAN/NG-RAN resources for each Participating Operator. A means of monitoring the usage of resources shall be provided.
All shared E-UTRAN/NG-RAN capabilities offered by the Hosting E-UTRAN/NG-RAN Operator shall be individually available for use by each Participating Operator where this is possible.
The 3GPP System shall support a Shared RAN (E-UTRAN or NG-RAN) to cover a specific coverage area (e.g. from a complete network to a single cell, both outdoor and indoor).
The 3GPP System shall support service continuity for UEs that are moving between different Shared RANs or between a Shared RAN and a non-shared RAN.
Up

28.2.2  OA&M Access to the Shared E-UTRAN/NG-RANp. 69

Each Participating Operator can have their own OA&M capabilities, which are used for monitoring and for selected operations in a shared E-UTRAN/NG-RAN. Information exchange involved in those operations need to be controlled by the Hosting E-UTRAN/NG-RAN Operator as to prevent disclosing them to other Participating Operators, be it for business, operational, or technical reasons.
The following requirements apply:
Selected OA&M capabilities for the Shared E-UTRAN/NG-RAN, under the control of the Hosting E- UTRAN Operator, shall be accessible by the Participating Operator's OA&M functions
This would allow, for example, the Participating Operator to do the following:
  • test of communication path between the Participating Operator's network elements and the Shared E-UTRAN/NG-RAN,
  • obtain fault reports,
  • retrieve RAN resource usage information.
Up

28.2.3  Generation and retrieval of usage and accounting informationp. 69

To facilitate interoperator accounting between Hosting E-UTRAN/NG-RAN Operator and Participating Operator the Hosting E-UTRAN/NG-RAN Operator needs to record E-UTRAN/NG-RAN resource usage by UEs of the Participating Operator.
The following requirements apply:
A Hosting E-UTRAN/NG-RAN Operator shall be able to collect events supporting the accounting of network resource usage separately for each Participating Operator. Collected events may be delivered to the subscriber's Participating Operator. This includes:
  • start of service in the Shared E-UTRAN/NG-RAN for a UE of the Participating Operator,
  • end of service in the Shared E-UTRAN/NG-RAN for a UE of the Participating Operator.
Up

28.2.4  MDT Collectionp. 69

MDT data from a Participating Operator's customer UEs allow the Hosting E-UTRAN/NG-RAN Operator to be provided with performance measurements on his Shared E-UTRAN/NG-RAN. The Participating Operator is responsible for obtaining and retaining any required user consent related to privacy.
The following requirements apply:
When authorized by the Participating Operators, the Hosting E-UTRAN/NG-RAN Operator shall be able to collect MDT data of the Participating Operator's UEs connected through its E-UTRAN/NG-RAN.
Up

28.2.5  PWS support of Shared E-UTRAN/NG-RANp. 69

A Participating Operator potentially has regulatory obligations to initiate the broadcast of PWS messages regardless of E-UTRAN/NG-RAN Sharing.
The following requirements apply:
The Shared E-UTRAN/NG-RAN shall be able to broadcast PWS messages originated from the core networks of all Participating Operators.

28.2.6  Support for load balancingp. 70

Hosting E-UTRAN/NG-RAN Operators have the need to optimize E-UTRAN/NG-RAN resource usage within the shared E-UTRAN/NG-RAN for a particular coverage area. At the same time, the agreed shares of E-UTRAN/NG-RAN resources based on a single cell and sector for each Participating Operator need to be respected. Likewise, Participating Operators have the need to optimize their E-UTRAN/NG-RAN resource usage among shared and unshared E-UTRAN/NG-RAN for a particular coverage area.
The capability to perform load balancing on an individual Participating Operator's traffic basis within a shared E-UTRAN/NG-RAN shall be supported.
The capability to perform load balancing on the combined traffic of all the Participating Operators within a shared E-UTRAN/NG-RAN shall be supported.
The capability to perform load balancing between an individual Participating Operator's traffic within a shared E-UTRAN/NG-RAN and traffic in that Participating Operator's unshared E-UTRAN/NG-RAN where the shared and unshared E-UTRAN/NG-RAN coverage overlaps shall be supported.
If load balancing in a Shared E-UTRAN/NG-RAN is supported and if a Participating Operator's EPC indicates overload to the Shared E-UTRAN/NG-RAN in order to mitigate the overload situation then overload mitigation measures shall have minimal impact on the communication between the Shared E-UTRAN/NG-RAN and other Participating Operators EPCs.
Up

28.2.7  Dynamic capacity negotiationp. 70

In situations where a need for additional, unplanned, E-UTRAN/NG-RAN capacity by a Participating Operator arises (e.g. in the case of big mass-events) the Shared E-UTRAN/NG-RAN can provide means to allocate available spare capacity to the Participating Operator. Based on service level agreement between the Hosting and Participating operator such allocation can be automated without human intervention.
The following requirements apply:
The Participating Operator shall be able to query and request spare capacity of the Shared E-UTRAN/NG-RAN, based on policies and without human intervention.
The Shared E-UTRAN/NG-RAN shall be able to allocate spare capacity to Participating Operator, based on policies and without human intervention.
Up

28.3  Specific GERAN & UTRAN Sharing Requirementsp. 70

28.3.1  Allocation of Shared GERAN or UTRAN Resourcesp. 70

When GERAN or UTRAN resources are shared they can be allocated unequally to the Participating Operators, depending on the planned or current needs of these operators and based on service agreements with the Hosting RAN Operator.
The following requirements apply:
The Hosting RAN Operator shall be able to specify the allocation of GERAN or UTRAN resources to each of the Participating Operators by the following:
  1. static allocation, i.e. guaranteeing a minimum allocation and limiting to a maximum allocation,
  2. static allocation for a specified period of time and/or specific cells/sectors,
  3. first UE come first UE served allocation.
The management and allocation of resources of signalling traffic over the Shared GERAN or UTRAN shall be independent from the management and allocation of resources of the user traffic over the Shared GERAN or UTRAN.
A Shared GERAN or UTRAN shall be capable of differentiating traffic associated with individual Participating Operators and shall be able to limit QoS available for traffic of the UEs of a Participating Operator (e.g. "best effort" if not enough resources are available).
A Shared GERAN or UTRAN shall be able to conduct admission control based on the allocated GERAN or UTRAN resources for each Participating Operator with a margin of tolerance.
A Hosting RAN Operator shall be able to control resource usage taking into account the allocated GERAN or UTRAN resources for each Participating Operator. A means of monitoring the usage of resources shall be provided.
All Shared GERAN or UTRAN capabilities offered by the Hosting RAN Operator shall be individually available for use by each Participating Operator where this is possible.
A Hosting RAN shall be able to provide an indication to each Participating Operator of how much capacity they are allocated at any one time. Signalling and User traffic shall be separately identified.
The ability to allow a single RAN (GERAN or UTRAN) to be fully shared by a number of Participating Operators shall be provided.
Up

28.3.2  OA&M Access to the Shared GERAN or UTRANp. 71

Each Participating Operator can have their own OA&M capabilities, which are used for monitoring and for selected operations in a Shared GERAN or UTRAN. Information exchange involved in those operations need to be controlled by the Hosting RAN Operator so as to prevent disclosing them to other Participating Operators, be it for business, operational, or technical reasons.
The following requirements apply:
Selected OA&M capabilities for the Shared GERAN or UTRAN, under the control of the Hosting RAN Operator, shall be accessible by the Participating Operator's OA&M functions
This would allow, for example, the Participating Operator to do the following:
  • test of communication path between the Participating Operator's network elements and the Shared GERAN or UTRAN,
  • obtain fault reports,
  • retrieve GERAN or UTRAN resource usage information.
Up

28.3.3  Generation and retrieval of usage and accounting informationp. 71

To facilitate inter-operator accounting between the Hosting RAN Operator and the Participating Operator, the Hosting RAN Operator needs to record GERAN or UTRAN resource usage by UEs of the Participating Operator.
The following requirements apply:
A Hosting RAN Operator shall be able to collect events supporting the accounting of network resource usage separately for each Participating Operator. Collected events may be delivered to the subscriber's Participating Operator. This includes:
  • start of service in the Shared GERAN or UTRAN for a UE of the Participating Operator,
  • end of service in the Shared GERAN or UTRAN for a UE of the Participating Operator.
Up

28.3.4  MDT Collectionp. 72

MDT data from a Participating Operator's customer UEs allow the Hosting RAN Operator to be provided with performance measurements on his Shared GERAN or UTRAN. The Participating Operator is responsible for obtaining and retaining any required user consent related to privacy.
The following requirements apply:
When authorized by the Participating Operators, the Hosting RAN Operator shall be able to collect MDT data of the Participating Operator's UEs connected through its GERAN or UTRAN.
The Participating Operators shall be able to retrieve this data for their own subscribers from the Hosting RAN Operator.
Up

28.3.5  PWS support of Shared GERAN or UTRANp. 72

A Participating Operator potentially has regulatory obligations to initiate the broadcast of PWS messages regardless of GERAN or UTRAN Sharing.
The following requirements apply:
The Shared GERAN or UTRAN shall be able to broadcast PWS.

28.3.6  Support for load balancingp. 72

Hosting RAN Operators need to optimise GERAN or UTRAN resource usage within the Shared GERAN or UTRAN for a particular coverage area while respecting the agreed resource shares for each Participating Operator. Similarly, Participating Operators need to optimise their GERAN or UTRAN resource usage between Shared and unshared GERAN or UTRAN for a particular coverage area.
The Hosting RAN Operator shall have the capability to balance the Signalling and User Traffic load individually for each Participating Operator within a Shared GERAN or UTRAN.
The capability to perform load balancing on the combined traffic of all the Participating Operators within a Shared GERAN or UTRAN shall be provided. The agreed shares of GERAN or UTRAN resources shall be maintained. Signalling and User traffic shall be managed independently.
The capability to perform load balancing between an individual Participating Operator's traffic within a Shared GERAN or UTRAN and traffic in that Participating Operator's unshared GERAN or UTRAN where the Shared and unshared GERAN or UTRAN coverage overlaps shall be supported.
The Hosting RAN Operator shall be able to balance the load across all Participating Operators.
Up

28.3.7  Dynamic capacity negotiationp. 72

The Participating Operator shall be able to request on-demand spare capacity of the Shared GERAN or UTRAN based on policies and without human intervention.
The Hosting RAN Operator shall be able to allocate spare on-demand capacity on the Shared GERAN or UTRAN to a Participating Operator, based on policies and without human intervention.
The Participating Operator shall be able to request the cancellation of granted on-demand capacity requests.
The Hosting RAN Operator shall be able to cancel a granted request based on a Participating Operator's request or based on agreed policy.
The Hosting RAN Operator shall be able to change the amount shared by each Participating Operator based on traffic demand. A minimum capacity (that can be set) of the Hosting RAN shall be reserved for each Participating Operator that cannot be allocated to other Participating Operators.
Up

29  Service exposure with 3rd party service providers |R13|p. 73

29.1  Generalp. 73

The intention of service exposure is that, under the assumption of a service agreement between MNO and a 3rd party, the 3GPP Network allows a 3rd party service provider to benefit from network provided services and capabilities that are exposed by the PLMN. For example the 3GPP Core Network can exchange information with the 3rd party to optimize usage and management of 3GPP resources. A standardized exposure of network services/capabilities reduces the complexity of different 3rd parties to access different 3GPP network services and capabilities.
General requirements for service exposure with 3rd party service providers:
  • The operator shall be able to provide to a 3rd party service provider secure and chargeable access to the exposed services/capabilities i.e. to authenticate, authorize and charge the 3rd party entities.
  • It shall be ensured that the 3GPP services/capabilities are not disclosed to unauthorised parties and that user privacy (avoid e.g. trackable and traceable identity information of the concerned UE) is maintained subject to user agreement, operator policy, service agreement between operator and 3rd party and regulation constraints.
  • The network service/capability exposure should be generic enough to support different application needs. Exposed 3GPP services/capabilities may use functionalities from different network entities and different 3GPP interfaces
Up

29.2  Exposed Services and capabilitiesp. 73

The 3GPP Core Network shall be able provide a standardized interface to enable exposure of the following services and capabilities to 3rd party service providers:
Support of 3rd party requested MTC Device triggering
  • The 3GPP Core Network shall support a 3rd party service provider request to trigger a UE that is served by the 3rd party service provider, the request shall include:
    • a trigger payload, to provide information to the application on the UE to e.g. trigger application related actions,
    • a validity period.
  • The 3GPP Core Network shall support the 3rd party service provider to recall or replace a trigger message that it has previously submitted.
Support of 3rd party interaction for 3GPP resource management for background data transfer:
  • The 3GPP Core Network shall support a 3rd party service provider request for background data transfer for a set of UEs that are served by the 3rd party service provider, indicating:
    • the desired time window for the data transfer,
    • the volume of the data expected to be transferred in a geographic area TS 23.032.
  • Additionally, the 3rd party application server shall be able to indicate to the 3GPP System when the background data transfer (a) exceeds the agreed maximum data volume or (b) continues beyond the agreed time window or (c) happens outside the agreed areas - e.g. due to movement of individual UEs, whether this background data transfer:
    • shall be stopped by the 3GPP Sytem or
    • shall continue, possibly under a different charging regime.
  • The 3GPP Core Network shall be able to inform the 3rd party service provider in one coordinated response, based on locally available information (e.g. congestion level) over the geographic area, about:
    • one or more recommended time windows for the data transfer and
    • for each time window the maximum aggregated bitrate for the set of UEs in the geographical area indicated by the 3rd party service provider.
  • Additionally, the 3GPP Core Network shall be able to inform the 3rd party service provider about the charging policy that will be applied to the 3rd party service provider if the data are transferred within the recommended time window and if transmission rates stay below the limits of the respective maximum aggregated bitrate.
  • The goal of providing the time window is to favour transfer of more traffic during non-busy hours and reason for providing the maximum aggregate bitrate is to spread out traffic during that time. The goal of multiple time windows is to allow the 3rd party provider to choose one appropriate time window based on its preference like the expected charging regime and bitrate.
Support of 3rd party interaction on information for predictable communication patterns of a UE:
  • The 3GPP Core Network shall enable a 3rd party service provider to provide information about predictable communication patterns of individual UEs or groups of UEs that are served by this 3rd party service provider.
    Such communication patterns may include:
    • Time and traffic volume related patterns (e.g. repeating communication initiation intervals, desired 'keep alive' time of data sessions, average/maximum volume per data transmission, etc.).
    • Location and Mobility related patterns (e.g. indication of stationary UEs, predictable trajectories of UEs, etc.).
  • This information may be used by the 3GPP system to optimize resource usage.
Support of 3rd party requested session QoS and priority
  • The 3GPP Core Network shall enable a 3rd party service provider to request setting up data sessions with specified QoS (e.g. low latency or jitter) and priority handling to a UE that is served by the 3rd party service provider.
Support of 3rd party requested broadcast
  • The 3GPP Core Network shall enable a 3rd party service provider to request sending a broadcast message in a specified geographic area (as specified in TS 22.368) expecting to reach a group of devices that are served by the 3rd party service provider.
Informing the 3rd party about potential network issues
  • The 3GPP Core Network shall be able to indicate to a 3rd party service provider when data transmissions have a risk of incapability to provide expected throughput and/or QoS in a specific area (e.g. due to forecasted high traffic load in that area). Additionally, an estimate may be given when the high traffic load is expected to be mitigated.
Informing the 3rd party about UE status
  • The 3GPP Core Network shall be able to provide the following information about a UE that is served by the 3rd party service provider:
    • Indication of the of the roaming status (i.e. Roaming and No Roaming) and the serving network, when the UE starts/stops roaming,
    • Loss of connectivity of the UE,
    • Change or loss of the association between the ME and the USIM,
    • Communication failure events of the UE visible to the network (e.g. for troubleshooting).
    • Reporting when the UE moves in/out of a geographic area that is indicated by the 3rd party,
    • Reporting when the UE changes Routing Area / Tracking Area / Location Area / Cell.
    • Reporting when the UE changes the status of 3GPP PS Data Off.
  • The 3rd party service provider shall be able to request a one time reporting or reporting at defined times (e.g. regular intervals, certain pre-defined time points) on the number of UEs present in a certain area and the location of each UE as for a Location Based Service.
  • Subject to user consent, operator policy and regulatory constraints, the user privacy shall be maintained when passing location information to a 3rd party service provider.
Informing the 3rd party about a UE's connection properties
  • The 3GPP Core Network shall be able to inform a 3rd party about a UE's connection properties.
Support for non-IP small data transfer with a 3rd party
  • The 3GPP Core Network shall support a 3rd party for submiting a small amount of non-IP data for delivery to a UE.
  • The 3GPP Core Network shall support a 3rd party application server for receiving a small amount of non-IP data delivered from a UE.
  • The 3GPP Core Network shall support a 3rd party to configuring non-IP data delivery for a particular UE (e.g. destination address, maximum number of messages, duration for which configuration applies).
Up

30  Flexible Mobile Service Steering |R13|p. 75

30.1  Introductionp. 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 Requirementsp. 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.
Up

31  Control of traffic from UE-based applications toward associated server |R14|p. 77

31.1  Descriptionp. 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])
Up

31.2  Requirementsp. 77

31.2.1  Control requirementsp. 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:
  1. the traffic load on the 3GPP network,
  2. the MNO policy,
  3. the MNO's service subscription profiles such as access class information, and
  4. third-party service subscription profiles
without impacting the traffic to other applications on the third-party server or other third-party servers.
Up

31.2.2  Requirements on awareness of third-party server issuep. 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 descriptionp. 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.
Up

32.2  Requirementsp. 78

32.2.1  General requirementsp. 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.
Up

32.2.2  Requirement for transmission performance enhancementp. 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.
Up

32.2.3  Requirement for network flexibilityp. 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
Within the radio resources dedicated to TV services in a geographic area the 3GPP network shall allow the MNO to specify the allocation of radio resource by the following:
  • 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
The 3GPP network shall be able to support network broadcast geographic area coverage management considering following criteria:
  • 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
The 3GPP network shall be able to deliver media content via unicast and broadcast in an efficient manner. The 3GPP system shall be capable of ensuring the timing sequence of different media content received by different UEs at the same location, even via different transport path, aligning with the timing sequence of TV service of the OTT provider in order to maintain synchronism.
A UE shall be able to receive eMBMS from one cell site while receiving other services from the same cell site or another possibly cell site.
The 3GPP network shall allow an MNO to service all UEs in an area with eMBMS independent of which MNO network(s) they have subscription to.
Up

32.2.4  Requirement for TV application supportp. 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.
Up

32.2.5  Requirement for RAN sharingp. 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
Up

32.2.6  Requirement for wide area supportp. 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 exposurep. 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.
Up

32.2.8  Fixed reception for TV servicesp. 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
Up

33  Usage over unlicensed access |R15|p. 81

33.1  Descriptionp. 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  Requirementsp. 81

The 3GPP network shall be able to identify traffic which was transported over unlicensed access.

34Void

35  Restricted local operator services |R16|p. 81

35.1  Descriptionp. 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.
Up

35.2  Requirementsp. 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.
Up

Up   Top   ToC