Join & Subscribe xgnlab for our niche blogs


Saturday, 10 March 2018

Open vRAN initiatives.

Vodafone has been working on software-defined RAN for the past year, and it's now contributing the project to TIP. Vodafone and Intel will lead the openRAN group, which will develop RAN technologies based on General Purpose Processing Platforms (GPPP) and disaggregated software.
"This is the opening of a system that runs radio as a software on top of general purpose processes and interworks with independent radio," said Santiago Tenorio, head of networks at Vodafone Group. The project will work to reduce the costs associated with building mobile networks and make it easier for smaller vendors to enter the market.
Also  open RAN groups such as the xRAN Foundation, a consortium formed in 2016 to develop and promote the virtualization of the RAN and the use of open standards. 

And now with all above being there Cisco announced at MWC 2018 that it is to lead Open vRAN initiatives.

The new Cisco group has some of the same members as xRAN and OpenRAN, including Intel and Mavenir. Other vendors involved in Cisco's Open vRAN initiative include AltiostarAricent, Phazr, Red Hat, and Tech Mahindra. 

Interesting to note here that  India's Reliance Jio has also joined Open vRAN group.  While many functions of a mobile network are being virtualized, the radio access network is "one area that has been completely neglected," said Reliance Jio's Tareq Amin, SVP, technology development and automation. 

Also when asked if any U.S. telecom operators are expected to join, Jonathan Davidson, SVP and GM of service provider networking at Cisco said, "I think they are very open to the disaggregated approach and moving to more cloud native ecosystems. I imagine they will get behind it."
The goal of Open vRAN is to assemble an open and modular RAN architecture, based on General Purpose Processing Platforms (GPPP) and disaggregated software, that will support different use cases. It will develop this new architecture over the next few months.

Friday, 9 March 2018

Strategy : Operator's and Service Provider's interests on vendor space through open communities is remarkable

As the open communities are flourishing around, whether it be hardware or software solutions or platforms or much buzzing term framework. a much needed for the service providers or operators to cope with the disruptive environments for technological advance and selection. 

As you can find the flooded memberships and active involvement of service providers and operators on these opensource communities. Recently verizon joined the Linux foundation ONAP and almost made it universally accepted platform for future network management and orchestration, Reliance jio and many others including, no doubt, the ECOMP founder AT&T is already there. Same is true with many other such communities like ONF, TIP . Recently, as per the news from MWC 2018 Cisco issued a major announcement at MWC - Open vRAN, which brings together innovators including Reliance Jio, Intel, Redhat and Mavenir. Open vRAN refers to a shift in base station architecture away from proprietary functions running on vendor-specific base station hardware to open tech for the mobile radio access network.  

Remarkably looking Reliance jio's active interest on open communities and technological insight exploration is unveiling the operators interest into vendor space. As this could be, if not yet, may be in future, but a much needed strategy for them to cope with the disruptive trends in technological advancements. 

It will help the operators or service providers to better decide their road map and relevantly impact the technological horizon as per their need and requirements. 

Open communities also provide a low cost involvement into technology development with required pace and much required coordination too. Also there is much scope to get hands on and thoroughly decide and coordinates on issues like for interoperability and compliance's.

Saurabh Verma
Consultant & Founder
Fundarc Communication (xgnlab)
Noida, India - 201301

Saturday, 24 February 2018

MEC Deployment challenges & scenarios - ETSI Whitepaper

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.

Industry specific verticalization through standards - 3GPP

Two important aspect of eMBMS services, setting the 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.

Sunday, 18 February 2018

3GPP IOT standards

Nice summary of eMTC, NB-IOT and EC-GSM-IOT in respective of their objectives , changes in 3GPP Release 13 and 14.