GA

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.

Thursday, 15 February 2018

commercials