Massive MIMO-Hit The Road- A Step forward to 5G

Courtsy ETT Telecom....

Verizon, Ericsson and Qualcomm Tech complete Massive MIMO advancement trial, makes progress towards 5G

US based telco Verizon, equipment manufacturer Ericsson and chipmaker Qualcomm's subsidiary, Qualcomm Technologies claim that they have completed the first ever FDD Massive Mimo trial with a fully compatible customer service which will build the momentum from the deployment of FDD (Frequency Division Duplexing) Massive MIMO (Multiple Input - Multiple Output) on Verizon’s wireless network in Irvine, California.

In this trial, the three companies used the latest Ericsson Massive MIMO software and hardware on Verizon’s network, along with a mobile test device powered by the Qualcomm Snapdragon 845 Mobile Platform with X20 LTE using TM9 (Transmission Mode 9), which is an enhancement for consumer devices that will make them fully compatible with Massive MIMO.


“Advanced Antenna Systems and Massive MIMO are key technology enablers for 5G, and 4G LTE service providers and end users will also benefit from the superior capacity and network performance these technologies enable. The latest trial is another important step in the collaboration we have with Verizon and Qualcomm Technologies to further evolve 4G and prepare the network for 5G,” said Niklas Heuveldop, Head of Market Area North America, Ericsson.

5G development moving fast than anticipated....

Recently 3GPP, the telecom industry standards body, has ratified the Non-Standalone (NSA) 5G New Radio (NR) specification, half a year earlier than expected. The specification for the non-standalone 5G NR (new radio) standard is now expected to form the basis of commercial 5G products by vendors like Ericsson, Huawei, Nokia, LG and Qualcomm among others.

TM9 Functionality

To realize the gains of Massive MIMO, both the networks and the devices need to support new TM9 functionality that leverages advanced beamforming schemes between the network equipment and the mobile device to raise network spectral efficiency and customer speeds.

3GPP TSG focus on next year 2018...as compiled from RAN78 meeting report.

I alwayes batted for complete CU and DU split .....since last 2-3 years...though not caring much about technical inquisitives but more for next gen network obectives and its perceptives, 3GPP RAN meeting conclusion here as putted by RAN chairman.....include this for consideration ....
Excerpts from the meeting report and 3GPP RAN Focus for next years as well as release 16.

3GPP’s proposal for the IMT-2020 call from the ITU-R is on schedule. TSG RAN is currently planning a workshop, for October 2018, which will provide an insight on our 5G technology and provide detailed self-evaluation results (including simulation assumptions and calibration) of the 3GPP 5G proposal.

Strong Focus as expected would be on 6GHz....in next years working items.

Future plan for Release 16.....

3GPP TSG going to have workshop next year october 2018.......

Deatail report is presented here ......

Ran78 summary from Saurabh Verma

LTE advance pro....and 5G intiative......

As NR is taken as official standards for 5G from 3GPP, it will be taken into NSA " Non stand alone architecture mode. Stand alone architecture mode is definitely going to take time.....


With this it is clear that LTE in advance and advance pro will be taking an anchering role for 5G initiatives......Technology like LAA and LWA has been in the formation stage for NSA initiatives,



Technology like LAA and LWA has been in the formation stage for NSA initiatives,




With that view .....we found a very good presentation from Qualcomm .....on LTE advance pro....and 5G intiative......

The essential role of Gigabit LTE and LTE Advanced Pro in the 5G World from Qualcomm Wireless Evolution

Media and Telecom in combination is the future of Entertainment Everywhere

En tv article_for_3gpp_web_site_v8 from Saurabh Verma

3GPP Mission Critical Services – Detailed List of Rel-13, Rel-14 and Rel-15 Functionalities

Rel-13 MCPTT (completed 2016)

• User authentication and service authorization
• Configuration
• Affiliation and de-affiliation
• Group calls on-network and off-network (within one system or multiple systems, pre-arranged or chat model, late entry, broadcast group calls, emergency group calls, imminent peril group calls, emergency alerts)
• Private calls on-network and off-network (automatic or manual commencement modes, emergency private calls)
• MCPTT security
• Encryption (media and control signalling)
• Simultaneous sessions for call
• Dynamic group management (group regrouping)
• Floor control in on-network (within one system or across systems) and in off-network
• Pre-established sessions
• Resource management (unicast, multicast, modification, shared priority)
• Multicast/Unicast bearer control, MBMS (Multimedia Broadcast/Multicast Service) bearers
• Location configuration, reporting and triggering
• Use of UE-to-network relays

Rel-14 MC Services (completed 2017)

MC Services Common Functionalities:

• User authentication and service authorization
• Service configuration
• Affiliation and de-affiliation
• Extended Location Features
• (Dynamic) Group Management
• Identity management
• MC Security framework
• Encryption (media and control signalling)

MCPTT Enhancements:

• First-to-answer call setup (with and without floor control)
• Floor control for audio cut-in enabled group
• Updating the selected MC Service user profile for an MC Service
• Ambient listening call
• MCPTT private call-back request
• Remote change of selected group

MCVideo, Common Functions plus:

• Group Call (including emergency group calls, imminent peril group calls, emergency alerts)
• Private Call (off-network)
• Transmission Control

MCData, Common Functions plus:

• Short Data Service (SDS)
• File Distribution (FD) (on-network)
• Transmission and Reception Control
• Handling of Disposition Notifications
• Communication Release

Rel-15 MC Services (in progress)

MC Services Common Functionalities Enhancements:

• Enhanced MCPTT group call setup procedure with MBMS bearer
• Enhanced Location management, information and triggers
• Interconnection between 3GPP defined MC systems
• Interworking with legacy systems

MCPTT Enhancements:

• Remotely initiated MCPTT call
• Enhanced handling of MCPTT Emergency Alerts
• Enhanced Broadcast group call
• Updating pre-selected MC Service user profile
• Temporary group call - user regroup
• Functional alias identity for user and equipment
• Multiple simultaneous users

MCVideo Additions:

• Video push
• Video pull
• Private call (on-network)
• Broadcast Group Call
• Ambient Viewing Call
• Capability information sharing
• Simultaneous Sessions
• Use of MBMS transmission
• Emergency and imminent peril private communications
• Primary and Partner MC system interactions for MCVideo communications
• Remote video parameters control capabilities

MCData Additions:

• MCData specific Location
• Enhanced Status
• Accessing list of deferred communications
• Usage of MBMS
• Emergency Alert
• Data streaming
• File Distribution (FD) (off-network)
• IP connectivity

MCPTT Conformance Tests (so far only for Rel-13 MCPTT)

Timeline for MC Services and 3GPP Releases

Release 13

• Mission Critical Push to Talk (MCPTT) completed in March 2016

Release 14

• MCPTT Improvements completion 09/2017
• MCData completion 09/2017
• MCVideo completion 09/2017

Release 15 and beyond

• MCPTT Improvements completion 06/2018
• MCData completion 06/2018
• MCVideo completion 06/2018
• Railways (FRMCS) study ongoing in SA6,normative work completion ~06/2018
• Interconnection between systems study completed,normative work completion ~06/2018
• Interworking with legacy systems study completed,normative work completion ~06/2018
• Maritime communications study ongoing in SA1
• Railways (FRMCS2) study and normative work ongoing in SA1
• MBMS APIs for MC Services study ongoing in SA6 

Further Reading:

3GPP Mission Critical Specifications (selected):

Stage 1 – Requirements

• TS 22.280 - MCS Common Requirements
• TS 22.179 - MCPTT over LTE requirements
• TS 22.281 - MCVideo over LTE requirements
• TS 22.282 - MCData over LTE requirements
• TS 22.289 – Mobile Communication Systems for Railways
• TR 22.819 - Study on Maritime Communication Services over 3GPP system

Stage 2 – Functional Architecture and Procedures

• TS 23.280 – MC Common Architecture
• TS 23.379 – MCPTT Architecture and Flows
• TS 23.281 – MCVideo Architecture and Flows
• TS 23.282 – MCData Architecture and Flows
• TS 33.180 – MC Services Security aspects
• TS 23.283 – MC Interworking between LTE-based systems and non-LTE-based systems
• TR 23.790 - Study on application architecture for the Future Railway Mobile Communication System (FRMCS)

Stage 3 – Protocols

• TS 24.379 – MCPTT Call Control
• TS 24.380 – MCPTT Media Plane
• TS 24.481 – MCS Group Management
• TS 24.482 – MCS Identity Management
• TS 24.483 – MCS Management Object (MO)
• TS 24.484 – MCS Configuration Management
• TS 24.281 – MCVideo signalling protocol
• TS 24.581 – MCVideo media plane control
• TS 24.282 – MCData signalling protocol
• TS 24.582 – MCData media plane control
• TR 24.980 - Minimum requirements for support of MCPTT over the Gm

Conformance Testing (so far only for Rel-13 MCPTT)

• TS 36.579-1 Mission Critical Push To Talk (MCPTT) over LTE; Part 1: Common test environment
• TS 36.579-2 Mission Critical Push To Talk (MCPTT) over LTE; Part 2: User Equipment (UE) Protocol conformance specification
• TS 36.579-3 Mission Critical Push To Talk (MCPTT) over LTE; Part 3: MCPTT Server Application conformance specification
• TS 36.579-4 Mission Critical Push To Talk (MCPTT) over LTE; Part 4: Test Applicability and Implementation Conformance Statement (ICS) proforma specification
• TS 36.579-5 Mission Critical Push To Talk (MCPTT) over LTE; Part 5: Abstract test suite (ATS)

3GPP Initiates Common API Framework - North Bound Service API

3GPP- North Bound Service API

For better harmonization and standardization of service provisioning and control, 3gpp has taken the much awaited step to work for north bound APIs. 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. 

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.

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

For the 5G

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.

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.

This is a good time to participate in SA6’s Common API Frameworks study. Above fig are from draft TR 23.722, 

CUPS – Set to be a key core network feature for many operators. 3GPP Release 14.

Control and User Plane Separation of EPC nodes (CUPS). 

CUPS being the 3GPP Relase 14 standards, but most fundamental aspect in evolution of Next Generation Networks Architecture, As we since last 3-4 years have been in continuous support of complete separation of control and user plan for bringing capability in network for required flexibility in terms of service creation and required scalability.

Though all IP paradigm shif since the inception of 4G has taken the first step towards it but recent advancement on virtualisation like of cloud and NFV has taken the troll ahead. 

in terms of 3GPP word..

CUPS stands for Control and User Plane Separation of EPC nodes and provides the architecture enhancements for the separation of functionality in the Evolved Packet Core’s SGW, PGW and TDF. This enables flexible network deployment and operation, by distributed or centralized deployment and the independent scaling between control plane and user plane functions - while not affecting the functionality of the existing nodes subject to this split.

CUPS allows for:

• Reducing Latency on application service, e.g. by selecting User plane nodes which are closer to the RAN or more appropriate for the intended UE usage type without increasing the number of control plane nodes.
• Supporting Increase of Data Traffic, by enabling to add user plane nodes without changing the number of SGW-C, PGW-C and TDF-C in the network.
• Locating and Scaling the CP and UP resources of the EPC nodes independently.
• Independent evolution of the CP and UP functions.
• Enabling Software Defined Networking to deliver user plane data more efficiently.

Architecture principles (Working Group SA2)

CUPS introduces 3 new interfaces, Sxa, Sxb and Sxc between the CP and UP functions of the SGW, PGW and TDF respectively. 

 

The following high-level principles were adopted:

• The CP function terminates the Control Plane protocols: GTP-C, Diameter (Gx, Gy, Gz).
• A CP function can interface multiple UP functions, and a UP function can be shared by multiple CP functions.
• An UE is served by a single SGW-CP but multiple SGW-UPs can be selected for different PDN connections. A user plane data packet may traverse multiple UP functions.
• The CP function controls the processing of the packets in the UP function by provisioning a set of rules in Sx sessions, i.e. Packet Detection Rules for packets inspection, Forwarding Action Rules for packets handling (e.g. forward, duplicate, buffer, drop), Qos Enforcement Rules to enforce QoS policing on the packets, Usage Reporting Rules for measuring the traffic usage.
• All the 3GPP features impacting the UP function (PCC, Charging, Lawful Interception, etc) are supported, while the UP function is designed as much as possible 3GPP agnostic. For example, the UPF is not aware of bearer concept.
• Charging and Usage Monitoring are supported by instructing the UP function to measure and report traffic usage, using Usage Reporting Rule(s). No impact is expected to OFCS, OCS and the PCRF.
• The CP or UP function is responsible for GTP-u F-TEID allocation.
• A legacy SGW, PGW and TDF can be replaced by a split node without effecting connected legacy nodes.

Protocol Design (Working Group CT4)

CT4 assessed candidate protocols such as OpenFlow, FoRCES, Diameter, IETF DMM FPC and 3GPP native protocol. The criteria identified for the selection process included;

• ease of implementation on simple forwarding devices,
• no transport Head-Of-Line blocking,
• low latency,
• capabilities to support all the existing 3GPP features
• ease to extend and maintain the protocols to support 3GPP features,
• backward compatibility across releases

Based on these criteria, CT4 decided to define a 3GPP native protocol with TLV encoded messages over UDP/IP, called Packet Forwarding Control Plane (PFCP) protocol, for the Sxa, Sxb and Sxc interfaces.

 

Details on the protocol on Sx

PFCP has the following main properties:

• One Sx Association shall be setup between a CP function and a UP function before being able to establish Sx sessions on the UP function. The Sx association may be established by the CP function (mandatory support) or by the UP function (optional support).
• An Sx session is established in the UP function to provision rules instructing the UP function how to process a certain traffic. An Sx Session may correspond to an individual PDN connection, TDF session or this can be a standalone session not tied to any PDN connection/TDF session, e.g. for forwarding DHCP/RADIUS/DIAMETER signalling between the PGW-C and PDN (SGi).
• Sx Node related procedures:
  - Sx Association Setup / Update / Release procedures;
  - Heartbeat procedure to check that a PFCP peer is alive;
  - Load Control and Overload Control procedures to balance the load across UP functions and reduce signalling towards UP function in overload;
  - Sx PFD Management procedure to provision PFDs (Packet Flow Descriptions) for one or more Application Identifiers in the UP function (SDCI).
• Sx Session related procedures:
  - Sx Session Establishment / Modification / Deletion procedures;
  - Sx Session Report procedure to report traffic usage or specific events (e.g. arrival of a DL data packet, start of an application).
• Data Forwarding between the CP and UP functions is supported by GTP-U encapsulation, e.g. for forwarding RS/RA/DHCP signalling between UE and PGW-C, or forwarding user plane data to the SGW-C when buffering of DL packets is done in the CP function. 
• PFCP supports reliable delivery of messages.
• New DNS procedures are defined for UP function selection. The CP function selects a UP function based on DNS or local configuration, the capabilities of the UP function and the overload control information provided by the UP function.

Restoration procedures

CT4 has analysed the possible error scenarios with split EPC nodes and defined corresponding restoration solutions in TS 23.007.

Further Reading:

Stage 2 – Functional Architecture and Procedures

• TS 23.214 Architecture enhancements for control and user plane separation of EPC nodes.

Stage 3 – Protocols

• TS 29.244 Interface between the Control Plane and the User Plane of EPC Nodes.
• TS 23.007 Restoration procedures
• TS 29.303 DNS procedures for UP function selection