GA

GA-C

Translate

Saturday, 24 February 2018

Industry specific verticalization through standards - 3GPP

Tow important aspects of eMBMS setting a paradigm of verticalization in concept.

xMB interface: To simplify the access to eMBMS system functionalities content providers and broadcasters can now establish the TV service through the standardized xMB (broadcasting application programming) interface, which has two aspects: xMB-C for control, and xMB-U for delivery of media content to the BM-SC. See 3GPP TS 29.116 xMB Interface and TS 33.246 Security of Multimedia Broadcast/Multicast Service (MBMS) for details.3GPP allows the inclusion of unicast distribution as a mobile system service, for example using eMBMS-operation-on-Demand (MooD) or unicast fallback (see TS 26.346 MBMS User Service Protocols and Codecs since Rel-12).

API: A new eMBMS Application Programming Interface (MBMS-API) was introduced primarily for developers of web and user applications to simplify access to complex eMBMS procedures. The API exists in the UE (the mobile system user equipment) from the eMBMS client to the Content Receiver application and is fed through xMB with relevant information to expose services to Applications (see Table 1.) This does not preclude typical mobile applications and OTT (over the top) service approaches, in which the content provider establishes a direct connection apart from any eMBMS/broadcast distribution, e.g. for service configuration and updates. Furthermore, to simplify access to the service by 3rd party applications, an MBMS URL scheme has been defined to serve as the entry point to trigger reception of an MBMS service. See 3GPP TS 26.347 MBMS APIs and URL for details.
 

Thursday, 22 February 2018

MEC deployment challenges in 4G scenarios and build up for 5G.


ETSI has come up with its new whitepaper on MEC, a much curated technology for making 5G a true application defined network. MEC will be a consultative driven approach for selecting the right kind of scenarios and application deploment as looking obvious here below recommendations.

As per the GS MEC 011 [2] specification, a key baseline functionality of the MEC platform is to route IP packets to MEC applications which are meant to handle the traffic in the following different ways:
 In Breakout mode, the session connection is redirected to a MEC application which is either hosted locally on the MEC platform or on a remote server. Typical breakout applications include local CDN, gaming and media content services, and enterprise LAN.
 In In-line mode, the session connectivity is maintained with the original (Internet) server, while all traffic traverses the MEC application. In-line MEC applications include transparent content caching and security applications.  In Tap mode, specified traffic is duplicated and forwarded to the tap MEC application, for example, when deploying virtual network probes or security applications.
 In Independent mode, no traffic offloading function is needed, but still the MEC application is registered in the MEC platform and will receive other MEC services, such as DNS, Radio Network Information Service (RNIS), etc. Steering traffic to/from MEC applications is achieved by configuring the MEC’s local DNS and the MEC host’s data plane accordingly.



From the list above, it appears straightforward that the implementationspecific details of the data plane within the MEC host (as per the MEC architecture in GS MEC 003 [3]) and the MEC platform, which is meant to program the data plane through Mp2 interface, are impacted by the point where the MEC host is installed in the 4G architecture. Many choices are possible, but all in all they can be condensed down into some base scenarios.

Also going for 5G.


The common feature set of providing much-improved capabilities at the edge of the network, improved intelligence about resources needed at the edge, and the ability to charge for service delivered by cycles, memory, storage and bandwidth delivered, makes it very attractive to start the deployment now in early test sites, roll out to sites that show promise and need for MEC based applications, and then roll out as part of the 5G transition without losing any upfront investment from the earlier test deployments. Taking into account the above considerations, in the next sections we illustrate how MEC compatibility towards 5G networks may involve:
 Integrating the MEC data plane with the 5G system’s one for routing traffic to the local data network and steering to an application;
 An Application Function (AF) interacting with 5G control plane functions to influence traffic routing and steering, acquire 5G network capability information, and support application instance mobility;
 The possibility of reusing the edge computing resources and managing/orchestrating applications and/or 5G network functions, while MEC still orchestrates the application services (chaining). Go through Complete whitepaper of ETSI here below.
 

Monday, 12 February 2018

Verizon, 5G industry milestone : Nokia and Qualcomm complete first call using 3GPP-compliant 5G New Radio technology

John O'Malley
T. 585.261.5899
verizon media contact.


Successful over-the-air test completed on Verizon's millimeter wave spectrum

NEW YORK – Verizon is the first network provider to conduct an over-the-air call on a 3GPP-compliant 5G New Radio (NR) system using licensed spectrum. This successful test on Verizon's millimeter wave spectrum – using Nokia 5G network technology on a 5G NR prototype device provided by Qualcomm Technologies, Inc., a subsidiary of Qualcomm Incorporated – was an important milestone on the road to preparing Verizon's network for widespread implementation of commercial 5G mobile services for consumers and enterprises. The test was conducted this month at Nokia's facility in Murray Hill, NJ and follows prior interoperability testing between Nokia and Qualcomm Technologies. The 5G NR standard was approved by the 3GPP in December 2017.
 
"With this first 3GPP NR standards-based connection, Verizon continues to lead the development of 5G technology," said Ed Chan, senior vice president and chief technology architect, Corporate Network & Technology, Verizon. "By partnering with Nokia and Qualcomm to combine 5G technology with our deep millimeter wave spectrum, we're well on the way to being the first to usher in the next era of wireless communications for customers."
 
The test was completed over Nokia's CloudRAN solution, which is comprised of the Nokia AirScale baseband and radio, AirFrame server, and AirScale Cloud RAN running 5G NR 3GPP-compliant software. 
 
"Nokia's 3GPP-compliant high-capacity 5G solution supports pioneering operators like Verizon in leveraging their assets to make a true difference with 5G for their customers," said Marc Rouanne, president of Mobile Networks, Nokia. "Using the successful interoperability testing we conducted with Qualcomm as a basis, we're now applying our standard-compliant 5G technology in this trial with Verizon to push the commercialization of 5G."
 
The test utilized Qualcomm Technologies' cutting-edge 5G NR millimeter wave prototype device, which includes an optimized millimeter wave RF front-end design in a smartphone form factor. 
 
"Qualcomm Technologies is committed to supporting the launch of standard-based commercial 5G networks and products beginning in 2019," said Joe Glynn, vice president of business development, Qualcomm Technologies, Inc. "The successful completion of standard-compliant 5G NR millimeter wave testing with leading mobile industry innovators such as Nokia and Verizon prove that we are well on the path to making this a reality."
 
Verizon's deployment of 5G technology over millimeter wave spectrum – beginning in 2018 – will provide massive bandwidth, ultra-high speed and single digit latency for emerging fixed and mobile use cases. As 5G continues to evolve, and as new use cases are developed and deployed, Verizon will be well positioned to deliver the capabilities those use cases call for to become a commercially viable solution.
 

3GPP - System architecture milestone of 5G Phase 1 is achieved

December 21, 2017

By Frank Mademann, 3GPP SA2 Chairman

The past two years have seen the 3GPP 5G architecture work progressing from the study period in 2016 to the delivery of a complete set of stage 2 level specifications. By achieving this milestone in 3GPP Release 15 the 5G system architecture has been defined - providing the set of features and functionality needed for deploying a commercially operational 5G system.

SA2, the 3GPP architecture working group, has now specified the overall 5G system architecture; detailing features, functionality and services including dynamic behavior defined by information flows.

This article offers a brief introduction to the 5G system architecture, highlighting some of its main characteristics. The complete description is provided by the delivered specifications TS 23.501, TS 23.502 and TS 23.503.

The 5G stage 2 level specifications include the overall architecture model and principles, eMBB data services, subscriber authentication and service usage authorization, application support in general, but also specifically for applications closer to the radio as with edge computing. Its support for IMS includes also emergency and regulatory services specifics. Further, the 5G system architecture model uniformly enables user services with different access systems, like fixed network access or WLAN, from the onset. The system architecture provides interworking with and migration from 4G, network capability exposure and numerous other functionalities.

Service Based Architecture

Compared to previous generations the 3GPP 5G system architecture is service based. That means wherever suitable the architecture elements are defined as network functions that offer their services via interfaces of a common framework to any network functions that are permitted to make use of these provided services. Network repository functions (NRF) allow every network function to discover the services offered by other network functions. This architecture model, which further adopts principles like modularity, reusability and self-containment of network functions, is chosen to enable deployments to take advantage of the latest virtualization and software technologies. The related service based architecture figures depict those service based principles by showing the network functions, primarily Core Network functions, with a single interconnect to the rest of the system. Reference point based architecture figures are also provided by the stage 2 specifications, which represent more specifically the interactions between network functions for providing system level functionality and to show inter-PLMN interconnection across various network functions. The various architecture diagrams can be found in [1].

The figure below shows one of the service based architecture figures, which is for a roaming scenario with local breakout, i.e. the roaming UE interfaces the Data Network (DN) in the visited network (VPLMN) and the home network (HPLMN) enables it with subscription information (UDM), subscriber authentication (AUSF) and UE specific policies (PCF). Network slice selection (NSSF), network access control and mobility management (AMF), data service management (SMF) and application functions (AF) are provided by the VPLMN. The user plane (UPF) is managed following a model of control and user plane separation similar to what was already introduced in the latest 3GPP 4G release. Security proxies (SEPP) protect the interactions between PLMNs. For more details and other scenarios see [1].

In the local breakout scenarios a UE receives the services of a PLMN typically completely from the serving operator's administrative domain. Home-routed data services are the alternative for roaming scenarios, which have also network functions from the home operator's administrative domain involved and the UE interfaces the DN in the HPLMN.

architecture image01v3b

Service based principles apply between the control plane network functions of the Core Network. Further, the 5G system architecture allows network functions to store their contexts in Data Storage Functions (DSF). Functionality for releasing the UE specific Access Network – Core Network transport associations from one AMF and re-binding with another AMF enables separating such data storage also for the AMF. Earlier system architectures had more persistent UE specific transport associations, which made it more complex to change the UE's serving node that compares to an AMF.  The new functionality simplifies changing the AMF instance that serves a UE. It also supports increasing AMF resilience and load balancing as every AMF from a set of AMFs deployed for the same network slice can handle procedures of any UE served by the set of AMFs.

Common Core Network

The generalised design of the functionalities and a forward compatible Access Network – Core Network interface enable the 5G common Core Network to operate with different Access Networks. In 3GPP Release 15 these are the 3GPP defined NG-RAN and the 3GPP defined untrusted WLAN access. Studies on other access systems that may be used in future releases started already. The 5G system architecture allows for serving both Access Networks by the same AMF and thereby also for seamless mobility between those 3GPP and non-3GPP accesses. The separated authentication function together with a unified authentication framework allow to customize the user authentication according to the needs of the different usage scenarios, e.g. different per network slice. Most of the other 5G system architecture functionality introduced by this article is common for different Access Networks. Some functionality provides variants that are more suitable for specific Access Networks, like certain QoS functionality described later.

Network Slicing

A distinct key feature of the 5G system architecture is network slicing. The previous generation supported certain aspects of this with the functionality for dedicated Core Networks. Compared to this 5G network slicing is a more powerful concept and includes the whole PLMN. Within the scope of the 3GPP 5G system architecture a network slice refers to the set of 3GPP defined features and functionalities that together form a complete PLMN for providing services to UEs. Network slicing allows for controlled composition of a PLMN from the specified network functions with their specifics and provided services that are required for a specific usage scenario.

Earlier system architectures enabled what was typically a single deployment of a PLMN to provide all features, capabilities and services required for all wanted usage scenarios. Much of the capabilities and features provided by the single, common deployment was in fact required for only a subset of the PLMN's users/UEs. Network slicing enables the network operator to deploy multiple, independent PLMNs where each is customized by instantiating only the features, capabilities and services required to satisfy the subset of the served users/UEs or a related business customer needs.

The very abstract representation below shows an example of a PLMN deploying four network slices. Each includes all what is necessary to form a complete PLMN. The two network slices for smart phones demonstrate that an operator may deploy multiple network slices with exactly the same system features, capabilities and services, but dedicated to different business segments and therefore each possibly providing different capacity for number of UEs and data traffic. The other slices present that there can be differentiation between network slices also by the provided system features, capabilities and services. The M2M network slice could, for example, offer UE battery power saving features unsuitable for smartphone slices, as those features imply latencies not acceptable for typical smart phone usages.

architecture image02 copy 

The service based architecture together with softwarization and virtualization provides the agility enabling an operator to respond to customer needs quickly. Dedicated and customized network slices can be deployed with the functions, features, availability and capacity as needed. Typically, such deployments will be based on a service level agreement. Further, an operator may benefit by applying virtualization, platforms and management infrastructure commonly for 3GPP-specific and for other network capabilities not defined by 3GPP, but that a network operator may need or want to deploy in his network or administrative domain. This allows for a flexible assignment of the same resources as needs and priorities change over time.

Deployments of both the smaller scope of the 3GPP defined functionality but also those of the larger scope of all that is deployed within an operator's administrative domain are both commonly termed a "network". Because of this ambiguity and as the term "slicing" is used in industry and academia for slicing of virtually any kind of (network) resources, it is important to emphasize that the 3GPP system architecture specifications defines network slicing only within the scope of 3GPP specified resources, i.e. that what specifically composes a PLMN. This doesn't hinder a PLMN network slice deployment from using e.g. sliced transport network resources. Please note, however, that the latter is fully independent of the scope of the 3GPP system architecture description. Pursuing the example further, PLMN slices can be deployed with as well as without sliced transport network resources.

The next figure presents more specifics of 3GPP network slicing. In that figure, network slice #3 is a straightforward deployment where all network functions serve a single network slice only. The figure also shows how a UE receives service from multiple network slices, #1 and #2. In such deployments there are network functions in common for a set of slices, including the AMF and the related policy control (PCF) and network function services repository (NRF). This is because there is a single access control and mobility management instance per UE that is responsible for all services of a UE. The user plane services, specifically the data services, can be obtained via multiple, separate network slices. In the figure, slice #1 provides the UE with data services for Data Network #1, and slice #2 for Data Network #2. Those slices and the data services are independent of each other apart from interaction with common access and mobility control that applies for all services of the user/UE. This makes it possible to tailor each slice for e.g. different QoS data services or different application functions, all determined by means of the policy control framework.

architecture image03

Application support

The basis of the application support are the data services, which offer considerably more flexibility for customization compared to earlier generations. A main part of this is the new QoS model of the 3GPP 5G system architecture, shown in the figure below, that that enables differentiated data services to support diverse application requirements while using radio resources efficiently. Further, it is designed to support different Access Networks, including fixed accesses where QoS without extra signaling may be desirable. Standardized packet marking informs QoS enforcement functions what QoS to provide without any QoS signaling. While the option with QoS signaling offers more flexibility and QoS granularity. Furthermore, symmetric QoS differentiation over downlink and uplink is supported with minimal control plane signaling by the newly introduced Reflective QoS.

architecture image04

 A large part of the functionality providing data connectivity is for supporting flexible deployment of application functions in the network topology as needed for edge computing, which is supported, for example, via three different Session and Service Continuity (SSC) modes or via the functionality of Uplink Classifiers and Branching Points.

The SSC modes include the more traditional mode (SSC 1), where the IP anchor remains stable to provide continual support of applications and maintenance of the path towards the UE as its location is updated. The new modes allow for relocating the IP anchor. There are two options, make-before-break (SSC mode 3) and break-before-make (SSC mode 2). The architecture enables applications to influence selection of suitable data service characteristics and SSC mode.

architecture image05a

As 5G network deployments are expected to serve huge amounts of mobile data traffic, an efficient user plane path management is essential. The system architecture defines in addition to the SSC modes the functionality of Uplink Classifiers and Branching Points to allow for breaking out and injecting traffic selectively to and from application functions on the user plane path before the IP anchor. Also, as permitted by policies, application functions may coordinate with the network by providing information relevant for optimizing the traffic route or may subscribe to 5G system events that may be relevant for applications.

Continuation of the work

The delivered stage 2 level specifications define the 3GPP 5G system from an overall, architectural perspective. The related work in the RAN, security, OAM and CT working groups continues with some specific stage 2 level aspects and with delivering stage 3 level specifications until June 2018.

This article has highlighted some of the most important advances of the 3GPP system architecture introduced with Phase 1 of 5G. Further advances and enhancements will be introduced in coming releases. Studies concerning Phase 2 of 5G will begin in first quarter of 2018.

References & specifications

[1] TS 23.501 – System Architecture for the 5G System; Stage 2
     TS 23.502 – Procedures for the 5G System; Stage 2
     TS 23.503 – Policy and Charging Control Framework for the 5G System; Stage 2

 

SA2 5G photo 
 Congratulations to SA2 on achieving this significant milestone.



3GPP North Bound Common API Framework Initiatives


 
By Erik Guttman, 3GPP TSG SA Chairman
 
As we seek to provide standards for integration with a growing range of 'vertical' business sectors, 3GPP has initiated a new area of API specification work. 
 
At our March 2017 Plenary meeting (SA#75) a new Study on Common API Framework for 3GPP Northbound APIs was approved and now the SA6 Working Group – responsible for application layer functional elements and interfaces - has started investigating the topic. 

API image03

 

In order to provide mobile end-to-end services, 3GPP interfaces exist throughout the system:

  • Between the mobile device and the Radio Network; 
  • Between the Radio Network and the packet core network; 
  • Within the core network; 
  • To external networks; 
  • For management and orchestration, etc.

These interfaces have facilitated the development of a range of diverse equipment, providing a broad range of functionality and services. 

Going North

Providing a broader range of standardized services with a wide range of partners has been a goal from the earliest days of 3GPP.

An area where 3GPP has not actively developed standards to achieve this goal is at the 'Northbound Application Programmer Interface' level, since the transfer of the Open Service Architecture (OSA) API work to the Open Mobile Alliance (OMA), in 2008. 

API image01a

A Northbound API is an interface between an Application Server (either in a mobile operator's network or external to it - operated by a third party) and the 3GPP system via specified Functions in a mobile operator's network. 

The new SA6 Study on Common API Framework for 3GPP Northbound APIs will consider their development, specifying common capabilities so that all Northbound APIs function similarly. The figure below, from draft TR 23.722, proposes how this may be achieved. 

To realize standardized integration of services with diverse service providers, northbound APIs provide for interaction at the application layer. This makes it possible for mobile network operators to offer a wide range of services beyond prevalent teleservices - voice calls, SMS and data service. Those services can be exposed within the operator network or to third parties in other networks. The figure below is a simple model to illustrate how the Common Framework will develop as the study progresses. The blue lines are defined by for all services accessed by northbound APIs – a common framework. The red lines are specific interfaces to deliver a particular service.

 
API image02a
 

The Opportunity

3GPP has actively worked over the past decade to provide additional services in the area of 'machine type communication' (MTC) which delivers the mobile communications part of some important new sectors, including;

  • The 'Internet of Things',
  • Media Broadcast,
  • Vehicle to Everything (including Vehicle to Vehicle, and other use cases)
  • Critical communications

These activities, particularly those related to Broadcast and IoT , have increased interest in standardization of northbound APIs. In Release 14, the "eMBMS Delivery of Media and TV Services" feature provide broadcasters with the ability to directly integrate their services with mobile network operators over standardized interfaces to the 3GPP system. In Release 15, to correspond with OneM2M release 2, 3GPP will include functionality to directly expose Cellular IoT and MTC capabilities via northbound APIs.

This expanding activity across 3GPP has provided the impetus for this new Study on Common API Framework (FS_CAPIF), which has begun to consider common aspects of northbound APIs. The study will focus on architectural aspects such as registration, discovery and identity management that generally apply to all services. Common API Framework Functions could be achieved uniformly for such capabilities as Service API discovery, monitoring and charging.

FS_CAPIF takes into account both the work ongoing within 3GPP as well as frameworks defined by other organizations. It aims to provide recommendations for specific architectural solutions that can subsequently be standardized. At this stage, requirements and issues have been identified and a gap analysis of existing solutions has begun.

While the scope of the study is general to all northbound APIs it is important to support the specific needs of individual vertical service offerings as well. For example, work on Broadcast interfaces has benefited from the participation of 3GPP member organizations actively providing broadcasting services. Similarly, MTC –related service exposure is coordinated directly with OneM2M and involves a wide range of other participants.

Looking to 5G

3GPP currently focusses significant resources on developing 5G standards. 5G aims to provide distinctive performance and capabilities to meet the needs of specific services. This will intensify the existing focus on integration with service providers in different service domains (often called 'vertical industries.') One aspect of this may be a broadening range of northbound APIs designed to expose the capabilities and resources of 3GPP operator's networks and the broad range of devices communicating over them.