Global Community of People and Entities Contributing for Next Generation Networks Ecosystems - 4G/5G. Any Member, individual or a company, here has no liability to others and even to xgnlab, vice a versa, it's a platform to showcase or share their work and knowledge only.
GA
Translate
Recent Most Popular
-
Akraino Edge Stack , a Linux Foundation project initiated by AT&T and Intel, intends to develop a fully integrated edge infrastructur...
-
WiFi_in right perpectives_2018 from Saurabh Verma
-
White paper vindictively stress on convergence for 5G step wise growth and strategical adoption. Convergence, not only aggregation at acce...
-
"Next generation" capabilities have been achieved by all products in the enterprise network firewall market, and v...
-
This tutorial guides you how firewall works in Linux Operating system and what is IPTables in Linux? Firewall decides fate of packets ...
-
mail from mojo below...... Dear Mojo customers and partners, I have some exciting news that I am pleased to share with you. Arista Net...
-
Hypervisors are a way to manage virtual machines (VMs) on processors that support the virtual replication of hardware. Not all processo...
Tuesday, 13 February 2018
Monday, 12 February 2018
Verizon, 5G industry milestone : Nokia and Qualcomm complete first call using 3GPP-compliant 5G New Radio technology
Successful over-the-air test completed on Verizon's millimeter wave spectrum
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.
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.
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.
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.
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.
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
| Congratulations to SA2 on achieving this significant milestone. |
3GPP North Bound Common API Framework Initiatives
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.
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.
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.
Tuesday, 30 January 2018
Smart Lighting with LiFi - by saurabh verma from fundarc-comm (xgnlab)
For technical write ups and for publication of your's here .
write to us "contact@xgnlab.com"



