3GPP Release 13 Features and Study Items

0

3GPP study for release 13 introduced a number of features and study items. Here is the list of all new features and other study items coming to 3GPP release 13.

Release 13 Features

  • RAN Sharing Enhancements
  • Service Exposure and Enablement Support

Release 13 Studies

  • Study on Application specific Congestion control for Data Communication
  • Study on Resilient E-UTRAN Operation for Public Safety
  • Study on enhancements for Infrastructure based data Communication Between Devices
  • Study on need for Multiple Access Point Names
  • Study on Co-ordinated packet data network gateway (P-GW) change for SIPTO

lte-advanced_large_verge_medium_landscape
Here are the details of all the new features and study items.

RAN Sharing Enhancements

E-UTRA RAN Sharing Enhancements allows multiple Participating Operators to share the resources of a single E-UTRA RAN – the Hosting E-UTRAN – according to agreed allocation schemes. The Hosting E-UTRAN is provided by a Hosting E-UTRAN Operator who can coincide with one of the Participating Operators.

The following definitions are useful for this feature

  • Hosting E-UTRAN: E-UTRAN that is shared among a number of operators.
  • Hosting E-UTRAN Operator: The Operator that has operational control of a Hosting E-UTRAN.
  • Participating Operator: Authorized operator that is sharing E-UTRAN resources provided by a Hosting E-UTRAN Operator

All the following requirements shall be subject to Hosting E-UTRAN Operator configuration.

Specific E-UTRAN Sharing requirements

Allocation of Shared E-UTRAN resources

The Hosting E-UTRAN Operator shall be able to specify the allocation of E-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.
  • A Hosting RAN shall be capable of differentiating traffic associated with individual Participating Operators.
  • A Hosting RAN shall be able to conduct admission control based on the allocated E-UTRAN resources for each Participating Operator.
  • A Hosting RAN shall be able to control resource usage taking into account the allocated E-UTRAN resources for each Participating Operator.

OAM Access to the Hosting E-UTRAN

The Hosting E-UTRAN shall be able to provide and control access to selected OAM functions to each Participating Operator to perform OAM tasks supporting the Participating Operator’s use of the Hosting E-UTRAN. E.g. each Participating Operator can only get information about own customers.

This would allow the Participating Operator to do the following:

  • Backhaul link test in the base station,
  • to obtain fault reports
  • retrieve RAN resource usage information (non realtime)

Generation and retrieval of usage and accounting information

A Hosting E-UTRAN 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 Hosting E-UTRAN for a UE of the Participating Operator
  • End of service in the Hosting E-UTRAN for a UE of the Participating Operator

MDT Collection

When authorized by the Participating Operators the Hosting E-UTRAN Operator shall be able to collect MDT data of the Participating Operator’s UEs connected through its E-UTRAN.

Note: This functionality should also allow for the case where the Hosting E-UTRAN Operator that does not have an adjunct core network.

PWS support of Shared E-UTRAN

The Hosting E-UTRAN shall be able to broadcast PWS messages originated from the core networks of all Participating Operators.

Note: Rel-11 design requires a shared PWS core. However, some regulatory obligations require a solution in which no common PWS core network entity is involved.

Service Exposure and Enablement Support

This work item allows 3rd parties to interact with the 3GPP System to use 3GPP functions to provide 3rd party services to their customers. Since M2M services and other Application services often have the same or similar requirements on the 3GPP System these are addressed jointly in this work item.
The following service scenarios are considered in this work item:

M2M services:

Standardization work related to M2M service enablement is on-going in standardization organisations outside 3GPP (e.g. ETSI TC M2M and the oneM2M Global Initiative). These SDOs work under the assumption that M2M service enablement can be offered by a network operator but can also be provided by third parties that have business agreements with operators. In addition, these SDOs want to use 3GPP capabilities beyond pure IP based data transmission that can be offered by 3GPP networks.
On the other hand, 3GPP architecture work on MTC has started in Rel-10 and in Rel-12 SA2 is working on Small Data Transmissions and Low Power Consumption UEs. Some information (e.g. on transmission scheduling or indications for small data, device triggering…) may need to be provided by M2M service enablement.

In Rel-11, 3GPP defined an interface (Tsp) between the 3GPP Core Network and M2M service enablement platforms. . Additionally, 3GPP has defined other interfaces (Le, Rx, Mo, Mf, and Mh) between the 3GPP Core Network and application platforms; these interfaces may also be used by M2M service enablement platforms.

This work item extends the scope for this interworking.

Application services:

With the high penetration of smart phones with a variety of applications, it is a challenge for operators to develop a new business model to increase the Quality of Experience for diversity of service type and potentially monetize the network asset. Interworking with the service providers and exposing network services can help the operators to take on the challenge.

Some private deployments have allowed operators to provide to application providers some services (e.g. statistics, location). However in multi-vendor environments, this requires time consuming and costly adaptations, therefore standardized exposure of selected 3GPP functions to application providers is needed.

Study on Application specific Congestion control for Data Communication

In the recent UE trends, UEs which user can easily download applications from web site are rapidly increasing in the world and a wide variety of applications are constantly created and installed on the UEs. Specific applications can (intentionally or unintentionally) cause congestion over RAN/CN while network is congested. While network is congested, it is not preferred to allow these applications to access to network in order to protect the network resources. Several SDOs such as GSMA, 3GPP and OMA identified key issues related to network inefficiencies (e.g. ) caused by such UEs and by the variety of applications. Also there are application that can cause problem, e.g. the ones that disclose privacy information without user consent, and apps that encourage illegal activities that are not allowed by the local regulations. It is preferred to provide a mechanism such that the network can disallow those problematic applications accessing the network.

On the other hand, for example in Japan, after the severe earthquake on March 11th, 2011, the packet based communication applications to confirm the safety of their relatives are recognized as the important applications (ex. Disaster message board service, Disaster voice messaging service) when disaster occurs. Therefore, Japanese government strongly expects Japanese operators to provide the connectivity at least for such services even when the network is congested, while other services are barred to free up the resources for important services.

In the past, 3GPP studied a variety of access control mechanisms (ACB/SSAC/ACB for CSFB/EAB) to avoid RAN/CN congestion due to massive mobile origination requests from UEs. While RAN is congested, ACB and EAB restrict mobile origination requests for all services, SSAC restricts for MMTEL voice/video and ACB for CSFB restricts MO for CSFB. SSAC and ACB for CSFB can separately restricts mobile origination requests for voice services from other packet services. In UPCON, network provides U-plane congestion control mechanism while radio access network is congested.

But there is no mechanism on UE to allow/restrict particular applications defined by operator.

Examples

  • Disaster message board: People, who are in disaster area, can store messages on the Web server. The relatives and friends can confirm their safety to check the messages. Japanese operators provide the Web server for Disaster message board when disasters occur.
  • Disaster Voice message service: People, who are in disaster area, can record voice message on the UE and the UE sends the messages to the server when it can get access to the network, then the message is delivered to the relatives and friends. Japanese operators will provide Disaster voice message service when disasters occur.

The objective of this study item is to investigate the following aspects:

  • Identify the use cases and potential requirements to allow/restrict the communication initiation of particular applications defined by operator;
  • Gap analysis with existing access control mechanisms to enable network to instruct the UE to allow/restrict particular applications defined by operator
  • Consider backwards compatibility with existing access control mechanisms

Study on Resilient E-UTRAN Operation for Public Safety

Many national and international Public Safety organisations have endorsed or are considering LTE as the next generation technology either to augment their existing systems, or to provide a future migration path.

In many critical incident related scenarios, the benefit of ensuring the ability to communicate between Public Safety officers on the ground will be of the utmost importance, even though they may be moving in and out of LTE network coverage or following the loss of backhaul communications.

To provide voice, video, and data communication service for Public Safety officers who are out of LTE network coverage, the Public Safety authorities may deploy a mobile command post equipped with an eNB or set of eNBs to facilitate communications for nearby Public Safety UEs beyond what is provided by Proximity Services in UE-to-UE direct communication mode. The eNB within a mobile command post could be either a single autonomous eNB without a backhaul link to the core network or a set of eNBs without backhaul links but linked to each other.

Alternatively, where an unexpected incident interrupts the backhaul and/or the link(s) between the eNBs it is also important to ensure the ability of Public Safety officers to communicate. If such a situation arises the eNBs are expected to provide resilient operation with rapid dynamic reconfiguration of the system in support of mission critical operations.

In both of the above scenarios it is vital to support recoverable mission critical network operations regardless of the existence of the backhaul link. When the backhaul link to the core network is unavailable, Public Safety eNB(s) could either operate autonomously or coordinate with other nearby eNB(s) to provide locally routed communications for nearby Public Safety UEs within a region. For example, it is undesirable for a UE in a mission critical situation to have to re-establish communications following the loss/recovery of backhaul link(s) especially when the backhaul link(s) are intermittently available; handling the dynamics of this loss and resumption is important. Furthermore, ProSe and GCSE_LTE have defined requirements for public safety discovery and communications (including group communications) in the cases of no network coverage and of full (E-UTRAN and EPC) network coverage. The need for discovery and group communications have to be considered in the case that eNB(s) with no EPC connectivity is(are) supporting LTE network coverage for a collection of UEs deployed to a public safety incident.

The benefits of exploiting locally routed communications for Public Safety UEs include:

  1.   The communications range achievable between Public Safety UEs may be enhanced compared with direct communications using Proximity Services.
  2.   Public Safety eNB(s) permanently or temporarily without backhaul can act as a radio resource manager for ProSe communications between Public Safety UEs to reduce interference and increase system capacity.
  3.   E-UTRAN could offer additional benefits by extending the network architecture, e.g.:
    • With LIPA like features
    •   For an eNB that has temporarily lost its backhaul, re-routing of the backhaul traffic to an eNB that still has a backhaul.

The objective is to study use cases and identify potential requirements for resilient E-UTRAN operation in support of mission critical network operations. Initial scenarios (but not excluding scenarios arrived at during the study) would include:

  1. an eNB either permanently or temporarily without connection to the backhaul;
  2. a set of eNBs either permanently or temporarily without connection to the backhaul but with connection(s) to each other;
  3. a set of eNBs temporarily without connection to the backhaul and without connection to each other.

Study on enhancements for Infrastructure based data Communication Between Devices

More and more devices are becoming connected. Market research suggests that in 2020 the total number of connected devices will grow from 9 Billion today to 24 Billion, with half of these incorporating mobile technology [www.gsma.com/connectedliving/]. These connected devices can be M2M devices such as smart meters, but increasingly all kinds of consumer electronic devices (e.g. photo cameras, navigation devices, e-books, hifi equipment, TVs) are connected. It is of interest to the cellular industry to increase the portion of consumer electronic devices that are connected via mobile networks.

Where Machine-to-Machine (M2M) communication is generally client server based, many consumer electronic devices also communicate with other consumer electronic devices. For example a photo camera can communicate with a printer, or a media server can communicate with hi-fi equipment. There is clearly the need to support communications between connected devices, i.e. without the need for intermediate network servers.

Examples of a non-3GPP technology that support communication between consumer electronic devices are Digital Living Network Alliance (DLNA) http://www.dlna.org/ and Universal Plug and Play (UPnP) www.upnp.org. DLNA and UPnP enable the discovery of other devices of interest, after which IP level data communication is made possible between the devices. DLNA and UPnP however only work within the confines of a single WLAN/LAN. How DLNA and UPnP could be supported over a cellular network infrastructure is not clear.

Within 3GPP, Proximity-based Services (ProSe) provide discovery of devices and communication between devices in proximity. For certain use cases, discovery and communication should work the same, irrespective of where the two devices are located. It should be possible to support communication between devices, e.g. two game consoles, even when they are in different countries. In that case, the communication is handled via the 3GPP infrastructure.

Many of the use cases of direct communication via the 3GPP infrastructure would likely involve small cell deployments (e.g. Local IP Access (LIPA)) or would benefit from data offloading (e.g. Selected IP Traffic Offload (SIPTO)). The interaction of infrastructure based communication between devices with local IP access and offloading should be investigated.

Exchange of data between consumer devices can also be supported with cloud based Over-the-Top (OTT) applications. But these OTT applications are generally not interoperable. The idea of this study item is to investigate the possibility of a generic communication capability that can generate a new revenue source for mobile network operators.

The objective of this study item is to study:

  • Potential enhancements to support secure discovery of UEs of interest
  • Potential enhancements to support secure optimized end-to-end data communication between UEs via the 3GPP infrastructure
  • Potential enhancements derived from user requirements for identification in communication between UEs
  • Potential interactions of data communication between devices with LIPA and SIPTO

UEs may represent functions/capabilities provided by non-3GPP devices in order to support interworking. However, discovery of, or end-to-end data communication with, non-3GPP devices themselves is out of scope.

Potential enhancements will be studied through the definition of use cases. From these use cases, potential requirements are identified. For potential requirements identified, if any, it will be determined what is the best way to approach normative specification.

Study on need for Multiple Access Point Names

The GSMA Connected Living Programme sent an LS to 3GPP SA1 (S1-133134) about a potential issue during the delivery chain of UEs for Machine-To-Machine applications. The mobile equipment is often a very generic module whereas the Machine-To-Machine application(s) is usually very specific and can require the use of a specific APN to have data connectivity. The correct APN to be used depends on the specific USIM within the UE that identifies the MNO. The correct APN also depends on the particular application because different applications may require different APNs and also may require an appropriate mechanism to identify which APN for which application. The correct APN may also depend on other factors (such as roaming).

The study will identify what connectivity use-cases that are needed to be fulfilled and study if APN or other means are required. GSMA Connected Living Programme assumed the connectivity use-cases are solved by use and management of multiple APNs. The study will also analyse the impacts in scenarios where the service provider decides to change the MNO.

Study on Co-ordinated packet data network gateway (P-GW) change for SIPTO

Small cells (such as Home eNB) are gaining momentum in the marketplace. SIPTO is a key feature to enable local breakout of traffic from a small cell.

The Selective IP Traffic Offload (SIPTO) feature defined in 3GPP Rel-10 specifications allows the operator to streamline an established PDN connection by re-assigning a new P-GW that is geographically closer to the current UE location. P-GW relocation implies a change in IP address, which means that performing SIPTO may disrupt any ongoing services.

CR2584 (23.401 CR2584 in S2-132879) attempted to correct this issue by basically recommending that the SIPTO operation should not be performed for UEs in Connected mode (“It shall be possible to configure the MME to deactivate a PDN connection, for P-GW relocation due to SIPTO above RAN, only when UE is in ECM-IDLE mode or during a Tracking Area Update procedure without established RAB(s).”). While this CR is certainly an improvement compared to the previous situation of blindly performed SIPTO, it still does not address the real issue – namely – smooth P-GW relocation for UEs with long-lived and real-time IP flows (e.g. long conference call, large file transfers, etc.).

With the introduction of SIPTO at the Local Network (SIPTO@LN) feature, the P-GW (alias Local Gateway) is moved even further towards the network edge and in the extreme case can even be collocated with the eNodeB. While this leads to an extremely “flat” architecture, in the sense that IP traffic can be broken out as close to the network edge as possible, the frequency of service disruptions due to SIPTO is likely to increase because of the much smaller “coverage” of the Local Gateway.

Service disruption due to IP address change does not have the same effect on short-lived and long-lived/real-time flows:
for short-lived flows (e.g. web browsing) the user may not notice anything, or in the worst-case may have to briefly interact with the user interface (e.g. by clicking again on the web page link following a “network connection lost” error);
it is for long-lived and real time flows that the effect can be detrimental (e.g. the user, ejected from the conference, has to re-dial the bridge number, enter password, etc.; similar applies to VPN traffic).
The UE is in the best position to identify the presence of any long-lived and real-time flows and is therefore in the best position to advise the network whether SIPTO can be performed without much disruption or any disruption at all. Moreover, for supporting applications the UE may also be able to pro-actively move the long-lived and real-time flows on a new IP address (i.e. on a new PDN connection) before the previous IP address (i.e. old PDN connection) is removed. The MMTel set of applications shall be studied in this regard as well as the possibilities for other types of applications. An example of such application is the IMS that allows the change of media transport addresses for an ongoing session using the IMS Service Continuity mechanisms defined in TS 23.237.

Based on end-user preferences and to benefit from the UE knowledge of established IP flow type, the network could consider the end-user expectation regarding local P-GW change in case of SIPTO use.

Reference

3GPP description document – Overview of 3GPP Release 13

Leave a Reply

Your email address will not be published. Required fields are marked *