Content for TS 22.101 Word version: 19.1.0

1… 4… 5… 10… 11… 13… 21… 24… 26a… 28… 30… A… A.19… B…

28.1 General 28.2 Specific E-UTRAN and NG-RAN Sharing requirements 28.2.1 Allocation of Shared E-UTRAN and NG-RAN resources 28.2.2 OA&M Access to the Shared E-UTRAN/NG-RAN 28.2.3 Generation and retrieval of usage and accounting information 28.2.4 MDT Collection 28.2.5 PWS support of Shared E-UTRAN/NG-RAN 28.2.6 Support for load balancing 28.2.7 Dynamic capacity negotiation 28.3 Specific GERAN & UTRAN Sharing Requirements 28.3.1 Allocation of Shared GERAN or UTRAN Resources 28.3.2 OA&M Access to the Shared GERAN or UTRAN 28.3.3 Generation and retrieval of usage and accounting information 28.3.4 MDT Collection 28.3.5 PWS support of Shared GERAN or UTRAN 28.3.6 Support for load balancing 28.3.7 Dynamic capacity negotiation 29.1 General 29.2 Exposed Services and capabilities
...

28 RAN Sharing Enhancements |R13| p. 68

28.1 General p. 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 requirements p. 68

28.2.1 Allocation of Shared E-UTRAN and NG-RAN resources p. 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:

static allocation, i.e. guaranteeing a minimum allocation and limiting to a maximum allocation,
static allocation for a specified period of time and/or specific cells/sectors,
first UE come first UE served allocation.
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.

28.2.2 OA&M Access to the Shared E-UTRAN/NG-RAN p. 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.

28.2.3 Generation and retrieval of usage and accounting information p. 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.

28.2.4 MDT Collection p. 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.

28.2.5 PWS support of Shared E-UTRAN/NG-RAN p. 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 balancing p. 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.

28.2.7 Dynamic capacity negotiation p. 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.

28.3 Specific GERAN & UTRAN Sharing Requirements p. 70

28.3.1 Allocation of Shared GERAN or UTRAN Resources p. 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:

static allocation, i.e. guaranteeing a minimum allocation and limiting to a maximum allocation,
static allocation for a specified period of time and/or specific cells/sectors,
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.

28.3.2 OA&M Access to the Shared GERAN or UTRAN p. 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.

28.3.3 Generation and retrieval of usage and accounting information p. 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.

28.3.4 MDT Collection p. 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.

28.3.5 PWS support of Shared GERAN or UTRAN p. 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 balancing p. 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.

28.3.7 Dynamic capacity negotiation p. 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.

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

29.1 General p. 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.

NOTE 1:
This requirement can be implemented by the existing standardised API frameworks e.g. the OMA API framework.
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

29.2 Exposed Services and capabilities p. 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.
NOTE 1:
The 3GPP Network will attempt to deliver the trigger message to the UE until the validity period expires.
The 3GPP Core Network shall support the 3rd party service provider to recall or replace a trigger message that it has previously submitted.

NOTE 2:
The goal of device triggering is that the UE takes action based on the content of the trigger payload. This response can involve initiation of communication with an MTC Server of the 3rd party service provider. The UE can initiate communication immediately or later within the validity period.

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.
NOTE:
The area indicated by a 3rd party service provider can be mapped to the area used in the 3GPP network, i.e. a list of LAs/RAs/TAs/cells. The 3rd party service provider can define a geographical area as shapes (e.g. polygons, circles) or civic addresses (streets, districts…) as referenced by OMA Presence API [53] e.g. defined by shape areas of RFC 5491 or by civic addresses defined in RFC 5139.
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).