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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

The eMBMS network shall be able to support designated coverage area, for example national, regional and local coverage areas.

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.

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