INTRODUCTION
Following both my current involvement, in the transformation of Satellite/Mobile Networks and the SD-WAN over Satellite Networks that I led on behalf of Kontron for MEF19. Some of my LinkedIn connections asked me to share some views about the perspectives I foresaw for the future of Satellite Networks and how it could benefit from any SDN/NFV related capabilities.
Indeed, new generation of market innovations such as LEO (Low-Earth Orbit) satellites constellation as well as 5G Mobile Network Transformation, innovative OTT Broadcast solutions, Containerized CDN solutions are great incentives that are accelerating both the needs for Satellite Networks to evolve/change to improve them towards more agility, flexibility, cost-efficiency and market attractiveness towards end customers and Service Provider partners.
The SD-WAN over Satellite POC, please check the great presentation from Janine Rebelo (Executive Director of GDX Networks), delivered by several telecom industry players was well received and awarded at the MEF19 event the “Best 2019 Service Implementation”. It represents a different approach in seeing and addressing services and how valuable market collaboration might be for any Service Providers including Satellite players. Indeed, It integrates market industry players from different walks of business life in service collaboration : GDX Networks : SDN/NFV Service Integrator & MEF Enthusiast / CMC Networks : Pan-African Wholesale Service Provider / IntelSAT : Satellite Network Operator / Nuage Networks & 128 Technology : SD-WAN software vendors / Kontron : Whitebox hardware vendor / Infovista : Service Assurance software vendor / Cloudify : Orchestration service software vendor.
With this article, I would like to share my personal views of how Satellite Networks can evolve and benefit from the latest technology innovations to address innovative use cases that were difficult to tackle until now. Following recent advices or critics about my past articles I will divide this article in three distinct parts:
In Part 1 (today), I’ll address the perspectives for Satellite Network Operators for selecting either Virtualization or Containerization? Can Satellite Networks only leverage virtualization and cloud functions for services and Multi-Tenancy? Or will a distributed approach combining both VNF and CNF would make better sense?
In Part 2, I’ll attempt to provide about GEO/MEO and LEO perspectives and their impacts on the Core Satellite Service functions. Address the question of legacy technologies at Satellite Teleports and how terrestrial Service Provider partners can interconnect with SNO (Satellite Network Operators) and SVNO (Satellite Virtual Network Operators). Obviously, I will bring some views about Edge Service aspects.
For Part 3, I’ll share my views about Value-Added, Managed Services delivered through a Satellite Service Infrastructure, the different use cases of interests and finally some views about LEO Satellite constellation requirements where NaaS (Network as a Service) could play a significant but positive role.
--------------------------------------------------------------
Part 1
SDN/NFV-ENABLED SATELLITE SERVICE INFRASTRUCTURE, NFVi or CNFi-BASED?
Intense fiber and copper penetration have been great incentives for Service Providers and Mobile Network Operators to develop attractive solutions and services and increasing vastly the bandwidth available on per user ratio. However, Satellite Network Operators have been tremendously important to bring connectivity where typical means were not applicable.
However, Satellite infrastructure are facing with inherent limitations to address the shift towards the virtualization/containerization of their service components. Simply due to dedicated and resource demanding based hardware components meant to deliver robust network technologies such PEP (Performance Enhanced Proxy) to improve TCP performance, Routing / QoS capabilities and Network Management. This approach had seriously impacted both the delays and costs for Satellite Networks to introduce and launch of new technologies and services paradigm associated with SDN/NFV-based services and functions.
In order to tame these limitations, future Satellite Networks shall adopt some recipes that were already adopted by Fixed-line Service Providers, Mobile Network Operators and even by Wholesale Service Providers. It means a rapid adoption of the notion of heterogenous Service Infrastructure whereby PNF (Physical Network Functions) would be complimentary with VNF (Virtual Network Functions) and to CNF (Containerized Network Functions). This is where the guidelines provided by ETSI MANO could be used in combinations with other important SDOs such as MEF (Metro Ethernet Forum).
In all discussions I am having with peers of the industry or customers, naturally come the question NFVi (Network Functions Virtualization Infrastructure) often linked to solutions based upon OpenStack / VMWARE. Versus CNFi (Containerized Network Function Infrastructure) often associated to solutions based upon Kubernetes for the Managed Infrastructure and Docker or Ansible to create and maintain containers. But I’d like to add that Microsoft is able to support both VMs (Virtual Machines) and Containers.
While targeting and supporting, possibly, similar applications or functions, NFVi (VMs) are way heavier and request a larger footprint of CPU and storage space but also are providing a better segregation between VMs. On the other side, containers are almost ten times lighter than VMs, but they are based upon the OS Kernel therefore creating a security risk vacuum to expose all instantiated containers if the OS Kernel is breached.
Therefore, the interests of using both NFVi (VMs) and CNFi (Containers) reside in using each solution for different purposes. Indeed, VNFi is mostly thought and used in Cloud-based services where multi-tenancy is important where each customer environments can be segregated from each other. Cloud services is by de-facto centralized therefore require a larger footprint to ensure both scalability and density to support as much as customers as possible simultaneously. On the other side, CNFi is mostly thought and used towards Edge-based services where applications and contents (Video, Gaming, VR/AR, UCaaS, CPaaS, etc..) are moved closer to the end users to ensure an improved Quality of Experience.
Part 2 (17th December 2019)
MOVING FROM GEO/MEO TOWARDS LEO, WHICH IMPACTS ON CORE SATELLITE SERVICE FUNCTIONS?
What are the main satellite technologies ?
The evolution of Satellite technology can easily get confusing but leads unavoidably to LEO (Low-Earth Orbit) which is somewhat different from what GEO (Geosynchronous Equatorial Orbit) or even with MEO (Middle-Earth Orbit).
Indeed, GEO satellites revolve around the earth at about 36.000 kms above our planet’s surface therefore ensuring a path parallel to Earth’s rotation and providing a global coverage and an almost continuous service. However, this impacts the quality of experience as the farthest distance induces far longer time delays and weaker signals than MEO-based Satellites. Although, MEO supporting satellites are situated between 2.000 kms to 36.000 kms above our surface. Therefore, MEO satellites are visible for longer orbital time periods between 2 and 8 hours.
The Low-Earth Orbit satellite brings connectivity services to a closer proximity to the earth’s surface by orbiting to an altitude of between 160 kms and 2.000 kms so only providing about 128 minutes or less of visibility per day due to a more elliptical orbit. Thanks to a closer proximity to earth, LEO Satellites provide much higher bandwidth, tighter time delays. Because of inherent orbital movement, LEO Satellite are deployed as a hive to provide a global coverage therefore they need to interconnect themselves then creating a space-based Data-Connection oriented mesh network where data need to be routed between basically from satellite to satellite to ensure a continuous connectivity services to any users. The overlay connectivity in-between LEO Satellites was originally thought to be addressed with a legacy technology such as MPLS but now could be based on NaaS (Network as a Service) based but I will address these options in Part 3.
What’s coming for Satellite and the LEO promises ?
Coming with this new approach in satellite connectivity, new options of use cases were considered achievable such as : Advanced connectivity and Cloud/Edge-oriented services, 5G Backhauling services, Overlay connectivity over LEO for uCPE and Managed Services, OTT Broadcast services with 4K/8K resolution quality, Unified Comms with UCaaS/CPaaS, Content Delivery Networks with various options such as gaming, AR-VR but also IoT. We’ll address these use cases in Part 3. However, before addressing these use cases, satellite networks need to increase both the density and scalability of their core functionss. Today, the obvious best way of achieving this is not by cascading or multiplying dedicated hardware platforms but by tackling important aspects:
Instantiating a NFVi/ViM solution (OpenStack / VMWARE / AZURE) or CNFi (Kubernetes & Docker)
Virtualizing core satellite functions such vPEP, vNMS and vQoS/CoS
It may sound trivial to explain, but, virtualization/containerization not only achieve to encompass the inherent limitations of dedicated hardware to scale at will the number of customer profiles supported. It will also fundamentally decrease the operational costs of the running service infrastructure with less power and space required to support similar or higher number of customers if it were based on dedicated hardware platforms.
SATELLITE TELEPORTS AND TERRESTRIAL NETWORK PARTNERS, HOW TO ADDRESS IT?
What is a Satellite Teleport and what is it based upon?
In Satellite services, often overlooked are the Satellite ground stations aka Teleports. The Satellite teleports are providing the ground segment of a Satellite service, equipped with large Satellite dishes, high power amplifiers and provide different ways to backhaul and groom traffics towards terrestrial Service Provider or enterprises of any kinds through connections called ENNIs (External Network-to-Network Interfaces).
Which technologies does it rely on?
Satellite Teleport operators are often used as a mean for collaboration with wholesale or in-countries service providers either to extend SNOs reach or extend theirs. To connect with Service Provider partners and extended reach, it requires an ENNI in place and a technology to monitor the physical and the connectivity provided on an end-to-end basis. Carrier-Ethernet is naturally intensively used for multiple reasons including monitoring:
UNI connectivity for the extended reach of services
ENNI for interconnecting SNOs to Wholesale or/and in-countries Service Providers
IEEE 802.3ah for Link OAM – Monitoring the physical connectivity of UNIs and NNIs
IEEE 802.1ag for CFM OAM & Y.1731 for Performance monitoring (delay, jitter, loss measurement and even availability)
Ethernet Protection mechanisms (if applicable) with G.8031 (Linear Protection) or G.8032 (Ring Applications) where the protections would be triggered by OAM ethernet frames exchange between UNIs or NNIs
RFC 2544/Y.1564 for Service Activation testing
Ethernet Private Line (Port-based) & Ethernet Virtual Private Line services (VLAN-based), which are simple (P2P aka Point-to-Point) services
Carrier-Ethernet brings some advanced connectivity features and service assurance concepts that are globally recognized through the work that MEF (Metro Ethernet Forum) has done, often in collaboration, with other bodies such as IEEE, ITU and even IETF for its great work on Ethernet & IP-based technologies. As a matter of fact, IETF specifications and IP-based technologies have been widely used, notably:
MPLS-TE based services to ensure Layer-3 connectivity
Hierarchical QoS (Quality of Service) and CoS (Classes of Services)
RFC2544/Y.1564 often used for both Carrier-Ethernet and IP-based services also called IP SLAs or EtherSAM in the Telecom World
Which Services are actually delivered from these technologies ?
Carrier-Ethernet is globally recognized as the best technology to ensure a smooth transition of services between Service Providers of any kinds. In this particular case, we are talking about SNOs collaborating and interconnecting either directly at the Teleport or at the closest PoP (Point of Presence) where the two operators hold a physical presence (equipments) there. In MEF terms, this situation is called an ENNI (External Network-to-Network Interface) dedicated to allow the interconnexion of two service providers. Therefore, it would be delivering different possible service scenarios :
EPL (Ethernet Private Line aka E-LINE) for Transparent services – connecting customer domains to Satellite service domain through Partner Carrier
EVPL (Ethernet Virtual Private Line) for VLAN-based services - connecting customer domains to Satellite service domain through Partner Carrier
E-Access allowing two operators to exchange ethernet frames via an EVC (Ethernet Virtual Circuit) established through an ENNI. This EVC now becomes an OVC (Operator Virtual Circuit)
E-Transit allowing multiple operators to exchange ethernet frames via an EVC (Ethernet Virtual Circuit) established through an ENNI. This EVC now becomes an OVC (Operator Virtual Circuit)
Carrier-Ethernet is a mature technology with great features but it doesn’t remove the importance of IP-based services where most of legacy applications (Security, Voice, UC, ERP, CRM, etc…) and new generation of technologies such as IaaS, PaaS, SaaS, UCaaS, CPaaS and even CDNs (Content Delivery Networks) are strongly rely on higher layer technologies to receive encapsulated Ethernet based services from customer domains and service provider partner domains. Basically, MPLS would be used to aggregate then groom customer traffic between PoPs or/and across the Satellite Service domains or to send them across Cloud-based partners using MPLS. Typically :
MPLS based 2547bis or 4364 where multiple features where added to facilitate the management of VPNs, support different routing protocols for VPN members and overlapping VPNs
Single CoS or Multiple CoS per MPLS tunnel aka L-LSP vs E-LSP
Carrier-Ethernet working in conjunction with IP-based OAM support with AIS for enhanced capability leveraging IP OAM tools such as BFD (Bidirectional Forwarding Detection).
IP-based OAM tools such as IP Ping, IP Traceroute, ECM and BFD
In today’s market, any enterprises in all verticals are now leveraging cloud technologies and cloud providers are even extending and accelerating their services towards Edge possibilities. Cloud Providers such as Google, Amazon, AWS, IBM and others are providing SLAs that ensuring KPIs for their service platforms availability which never include the means to access to them. As a result, all services providers are now positioning themselves as Cloud Service intermediaries providing connectivity accesses (Fiber, Copper, Wireless and why not Satellite) to any of the market Cloud Providers. Also, some of the traditional Service Providers are now also welcoming Cloud Service Providers to develop co-funded PoPs where both brands could be represented equally and in a collaborative fashion. Each one providing what they know best, therefore, why SNOs would approach any differently?
Evolving towards Cloud in-house capabilities seems to be a natural trend for SNOs, which have been traditionally the ideal connectivity platforms for TV contents to be distributed to the largest audience due to their global reach. With today’s evolution of OTT Broadcast, CDNs and other associated services such as Gaming, AR/VR and enhanced quality of contents is now impacting on how Satellite shall adapt themselves to rapidly changing market conditions and new service requirements.
Which market innovations Satellite Network Operators could potentially leverage?
Satellite Network Operators as we call them are subjects to the same challenges that were shaking out typical Service Providers. How can they evolve/redefine themselves to move towards of becoming Satellite Virtual Network Operators without disrupting what was making them successful and profitable until now?
I often reiterate and argue to my customers or industry peers that technologies should be perceived differently than just hurdles but keys to unlock different paths for new ways to new services monetization and growth but not without taking in consideration that it takes time, efforts and diligence to achieve these goals.
Connectivity
No doubt in my mind that Carrier-Ethernet is there to stay and will be a key aspect of further developments notably for key use cases that will ensure growth and monetization perspectives. The key use cases, I have in mind, alongside are naturally 5G Mobile service and content X-hauling possibilities as we know that Backhaul, Midhaul and Fronthaul are meeting different level of latency, jitter and bandwidth requirements as Mobile infrastructure get virtualized/containerized and highly distributed with the separation of key Mobile functions : RU & DU split, Remote Cell-Site, then Cloud-RAN leading to full 5G. I obviously take in consideration how important Satellite Virtual Service Infrastructure could be to accelerate the monetization all the steps leading to 5G then to invite MNOs to collaborate with each other while invite MVNOs to resell their own service definitions.
Another important factor is that, under the MEF impulsion and great contribution from people from all the corners of our industry, Carrier-Ethernet is now transforming and blooming into something that is now transcending the notions of separation seen and appreciated with the OSI layers. Indeed, innovation such as MEF 55 LSO (LifeCycle Service Orchestration) has considerably helped to better shape our industry to bring more consensus on how the various layers of Software-Defined Service Infrastructure shall interwork together and how consistent APIs need to be. As a result, important Service Organizations such as Linux Foundation (LF) and their famous ONAP project but also Telecom Infra Project (TIP) and their Disaggregated Cell Site Gateways (DCSG). Both organizations have now converged on the necessity to fall behind a consistent approach for APIs nomenclature and structure that will be supported by both the Service Provider and the SW/HW vendors communities.
IP-Based Connectivity and Overlay capabilities
MPLS is THE packet transport technology that has accelerated drastically our market to bring CO-PS (Connection-Oriented Packet Switching) capabilities to the light. With TE extensions, it went further ahead to bring both VPN and CoS features, MPLS-TE was then propelled as the number one transport technology and became the predominant technology in the market. Over time, IETF and other SDOs like ITU-T brought either variants of MPLS such as T-MPLS, VPLS, GMPLS and PWE3 to carry non-IP packets over MPLS or additions to MPLS such as E-LSP (multiple CoS per LSP) vs L-LSP (Single CoS per LMSP), OAM features, protections mechanisms and many others.
In 2008, both IETF and ITU, joined forces together to create another variant of MPLS with MPLS-TP (MPLS-Transport Profile). ITU-T network experts continued the work started with T-MPLS and removing but also adding new features to make MPLS a more relevant transport technology as an ideal alternative to SDH, SONET or OTN (Optical Transport Network). As a result, MPLS-TP supports all the advantages from MPLS-TE such as QoS/CoS, Carrier-Ethernet OAM, Protection switching capabilities but bidirectional LSPs and some others.
Having said that, MPLS brings some severe inherent requirements that are impacting its scalability. Indeed, MPLS is generally supported over dedicated hardware platforms because of its severe hardware requirements to support high numbers of CoS streams, MPLS tunnels (LSPs), VRF (Virtual Routing and Forwarding) Instances, VPN numbers, talkative routing IGP schemes such as OSPF but also limited OAM features if compared to Carrier-Ethernet. Hence, all these combined elements don’t play in favor in the direction of the virtualization/containerization of the core functions of any SNO players.
Following the recent Intra-Carrier SDWAN over Satellite PoC at MEF 19, into which I contributed with Kontron, brings the question of overlay IP-based connectivity. Would it benefit a SNO or SVNO to use an applications-aware overlay connection-oriented technology? I strongly advocate for it, as it could serve as a natural conduit for any IP-based applications and even to transport Carrier-Ethernet frames end-to-end, in order to maintain OAM MEG over E-Access or E-Transit scenarios and to facilitate the notion of application-aware overlay connectivity from customer branch to customer branch.
But, supporting SD-WAN over Satellite might generate different concerns. Indeed, moving from SNO with dedicated HW platforms to SVNO with virtualization/containerization might introduce different aspects of delays and inter-packet delays due to several layers to traverse, especially when VNFs are concerned, even though technologies like DPDK or/and SR-IOV provide some answers. More important concerns are the targeted use cases: Satellite naturally introduces delays during the transmission of packets over the wireless segment therefore in order to serve use cases such Edge-associated applications or Mobile Backhauling scenarios. To mitigate with such issues, the selected SD-WAN SW vendors must be as close as possible to the following requirements :
Simple: No tunnels or VPN overlays and no HW dedicated HW
Agile: Faster deployment, already onboarded with Orchestration and NFVi platforms, dynamically optimized with AI analysis models
Secure: Zero Trust model, Authentication + Encryption + Segmentation
Performance: No VPNs ensure better throughput and can decrease up to 30% CAPex and OPex
Flexible: Can be virtualized/containerized or barebone installed
SD-WAN instance as low as supported on 2C/4C CPU-based devices
With the release of MEF 70 as a SD-WAN service definition that is now formalizing a tangible approach of how to merge multiple concepts for a converging Service Infrastructure, such as:
SD-WAN at customer premises and at the Edge
Baremetal or virtual/containerized
SD-WAN controllers with centralized management over SD-WAN router softwares & Gateways
MEF 55 Lifecycle Service Orchestration support
Integration under the Services umbrella from an Orchestration/Automation Service Platform and web portal
Decreasing market confusion
Simplifying the concepts of SD-WAN over any transport technologies
SD-WAN services certification to accelerate market consensus
Network Disaggregation & PNF / Multi-Cloud Orchestration & Automation / API Consistency over Layers
The term disaggregation hit the market very recently alongside with the Edge distributed services concept. The approach seems very logical as per moving away from the situation where all applications and services would be centralized in the cloud. Improving the QoE (Quality of Experience) to users about these apps/services, then, they would simply be moved at the edge, (i.e. closer to the end users) of the network infrastructure leveraging PoPs (Point of Presences). To a certain extent, a router IOS (Internetwork Operating System) or NOS (Network Operating Software) is just an application supporting networking, security and QoS features. Could it be moved away from a dedicated hardware platform and even disaggregated?
Players such as IP Infusion, ADVA or Metaswitch have released NOS solutions that could be disaggregated meaning located anywhere and orchestrated by any Orchestration Service Layer platforms available and compatible on the market. These NOS solutions have been evaluated as part of RFI initiated by Facebook’s TIP DCSG iniative. It would suggest the possibility that a NOS could be Software-Defined by any orchestration plaforms:
Proprietary orchestration solutions such as Cisco, Ciena, Juniper, ADVA
Open Source (MANO) oriented such as Cloudify, RIFT.IO
Fully Open Source such as ONAP from Linux Foundation where Aarna Networks led by Amar Kapadia packaged a workable version of ONAP.
A NOS solution would support almost the same depth of features supported by any proprietary IOS software platform from Routing, Security, QoS & CoS, MPLS, EVPN, VXLAN & VTP, OTN, OAM but also Clock distribution and Synchronization, ZTP(Zero Touch Configuration) and ZTC (Zero Touch Configuration) capabilities. More importantly, NOS solutions would be compatible with hardware switch vendors like Broadcom and others. But, it would also bring a workable Netconf and Yang models to allow orchestration and SDN functions to tap into the NOS software features.
All layers a Software-Defined Service infrastructure will have their model of communication defined through API (Application Programming Interface). Typically, Northbound & Southbound would drive the way Service Infrastructure layers interwork but EastBound & WestBound APIs would structure how two Service Provider Service Infrastructure collaborate and share relevant information for OSS/BSSS but also orchestration and SDN decision making processes. API is now the most important subject for Software Defined Infrastructure therefore consistency and stability would be the best adjectives to define how API evolve. MEF 55 with LSO, moves us closer to a consensus to this major issue and has been driving a lot enthusiasm and convergence in our industry where respectable Service Organizations such as Facebook’s TIP initiative and even Linux Foundation have started to move closely to it.
The question of residual PNF (Physical Networking Function) basically dedicated hardware will have to naturally fit into an evolving/changing Service Infrastructure. It would require a close collaboration with hardware vendors to make sure that their IOS software and associated Netconf/RestConf and Yang models be compatible with the Service Orchestration Layer to ensure that both dedicated hardware and incoming VNFs and CNFs would be both able to collaborate seamlessly. Because, not all services/functions can be virtualized or containerized, Service Infrastructure will always be places of hybrid composition.
All relevant aspects mentioned above: NOS disaggregation / API consistency and PNF orchestration point towards to a Multi-Cloud and Multi-Services Orchestration platform. The Multi-Cloud consists indeed for an Orchestration Service platform software to support and manage different kind of NFVi (VNFs) platforms but also to support CNFi (Containers) platforms simultaneously to make sure that they all fall under a common services umbrella. The Multi-Services concept will certainly allow to address different requirements under a unique Service Infrastructure umbrella instead of multiple. It sounds obvious but, yes Cloud and Edge requirements will differ and will present different challenges that wouldn’t addressed with an unique virtualized or containerized solution. Equally important is the NOS, which will bring the potentially the missing link of adding software-defined networking and instantiating/tearing dynamically routes/segments and tunnels through Segment Routing, PCEP, VXLAN, VTEP, EVPN or even BGP-LS. Obviously, the ultimate goal would be to bring gradually all these capabilities under the belt of a single Multi-Services Domain Orchestration platform.
Centralized Cloud or Edge-distributed services, what’s the best approach for SVNOs?
It looks obvious that neither the centralized cloud approach or the Edge distributed approach taken separately can deliver the expected changes needed to address all the new challenges facing all Service Providers. I truly believe that both approaches bring advantages and benefit together for transforming a service infrastructure to become more flexible and highly adaptable but also at introducing new generation of services more quickly and efficiently.
Due to recent experiences and exposure to Cloud-based Infrastructure, we all know that multiple solutions exist out there in the market such as OpenStack/CloudStack, VMWARE, Azure where VNFs (VMs) are the most likely format used. We shouldn’t be taking lightly how important Container-based technologies have been for Edge-based solutions development such as Kubernetes has been and influencing market players such as WindRiver Cloud & Edge Platform, Juniper Juke and Red Hat OpenShift. Therefore, it is important to highlight how positive the Open Source community has been to change the monolithic, slow and lock-in approach that was maintaining the Telecom Industry under. Having said that, there is a tendency to associate a nature of a service to a service location that I now find very dangerous whereby VNF means Cloud and Containers means Edge.
I generally don’t push forward any personal views about vendors, which I find a bit inappropriate but I’d like to focus a bit on Wind River. Wind River has released recently a nice approach that I’d like to share it. Wind River is clearly known as being time-sensitive and to provide a very low-footprint for NFVi solutions with their Titanium offerings and they have released now their Edge-based Kubernetes capable counterpart dedicated for Edge. But, what I found very interesting that Wind River didn’t restrict VNF to Cloud or Containers to Edge. Indeed, their Cloud solutions can accommodate containers over VMs and their Edge solution can naturally accommodate VNFs (VMs) alongside containers. Sometimes, we almost forget that the main interests of containers is their lightness that allows them to be moved or duplicated in multiple locations very quickly but why would VNFs be any different? An important factor is that Wind River has now adopted and integrated StarlingX to facilite Host, Fault, Service and Software management which would be extremely important for Edge and IoT distributed deployments, which could be useful for customer premises as you know that I consider uCPE as part of Edge scenarios.
SNOs or SVNOs to be, have historically a short number of deployed PoPS because they tend to leverage their Satellite partners or their own Satellite infrastructure to provide and backhaul services. Thus, the definition of Edge for a Satellite Network Operators would be then hybrid by being based upon their own PoPs and of their partners. Indeed, one natural way to extend both services and applications is always to use the existing infrastructure from others than building their own. Distributing services to the Edge such as Video distribution (OTT or CDN), Mission-Critical cloud apps, Gaming and other key contents such as VR/AR finally extending business critical services to enterprises such as security, UCaaS, CPaaS and others I might have not listed.
Part 3 : HOW TO INTRODUCE VALUE-ADDED MANAGED SERVICES INTO A SATELLITE INFRASTRUCTURE?
What is qualified as Value-Added & Managed Services in today’s market?
Like any other Service Provider, a SNO (Satellite Network Operator) or a SVNO (Satellite Virtual Network Operator) like any Service Provider is amortizing its service infrastructure based on two most basic principles: Selling bandwidth and either hosted or access to services of any sorts. Naturally, we must appreciate that services have a direct impact on the bandwidth consumption/utilization.
Indeed, more relevant the services proposed are and more important the bandwidth utilization/consumption will be. Therefore, the marketed/proposed services must be aligned with both the market trends and customer requirements. Failing to achieve these targets, will likely open the doors for competitors or service alternatives.
Now, the question what are these game changing services?
Monetizing Software-Defined Networking capabilities
The main components of a service infrastructure and architecture are based on three main principles: Network (Core/Edge/Access), Intra-Carrier Network and Customer Domain services.
Any networks is based fundamentally on equipment, which were dedicated to specific tasks until now where basically a PNF hardware-based platform were delivery a single function (with many features) although in today’s predicaments a Whitebox or open hardware that would result in supporting cascaded Virtualized or containerized functions including advanced networking functions.
The most recent innovation and trend associated with disaggregated NoS (Network Operating Software) is proving there extremely relevant based on the principles that any important networking technologies (MPLS / Carrier-Ethernet / EVPN /VXLAN, etc…) could be see packet-based service tunnels set-up upon demands such as orchestration, automation or Intent-based Networking (AI-driven methodologies) when and if associated with right set of technologies notably with structured YANG & NetConf modelling that could be leveraged with Open Source OpenDaylight or with either other open source or proprietary equivalent alternatives.
The concept of disaggregated networks takes its entire place in new concepts of networks where slices of networks are addressed separately from one another and serving different purposes. This is notably true in 5G Mobile Network Transformation where service functions get gradually separated from each other notably with RU & DU functions are co-located initially then separated and DU functions gets collocated at the edge with the CU-based functions and 5G Core functions. Therefore, it highlights the importance for all service infrastructure or networking slices where services are distributed across the centralized core infrastructure, the distributed Edge and the stable Customer domain services.
How Network can be structured to address business and services requirements?
Any Satellite Network Operator (SNO) also with virtual capabilities (SVNO) is profoundly relying on its network architecture notably with:
· Carrier-Ethernet to deliver end-to-end customer-services but also meant deliver better latency and monitored transports of traffics
· MPLS at Satellite Teleport to groom Carrier-Ethernet based traffic through their backbone networks but also often used to ensure interconnexions with terrestrial Service Providers.
Therefore, it is obvious that one of the immediate responses will come from the disaggregation of the network capabilities, whereby, all aspects of instantiation / tear-down / Scaling up or down of a service or feature could be control and organized by a Software-Defined infrastructure where :
· NoS and PNF (Physical Networking Functions) SDN capabilities would be supported under SDN capabilities such as OpenDaylight, OpenFlow or proprietary mechanisms
· Virtualization (VNFs) with OpenStack or alternatives & Containerization (CNFs) instantiation capabilities with Kubernetes/Docker could be leveraged seamlessly at Edge and at Cloud locations
· As explained in earlier chapters, SNO PoPs transformation would be done to facilitate Edge services introduction or/and by leveraging virtual and edge options brought by Service Provider partners
All service capabilities described in the above bullet points would naturally be structured under an Orchestration/Automation Service Platform flexible enough to introduce gradually Cloud – PNFs – Edge concepts alongside a consistent API structure.
Without these elements taken in consideration, expanding service options towards Customer Domains would reveal rather complex and static instead of being flexible and agile.
Monetizing Customer Domain services
Any Service Provider is building its service infrastructure to expand its array of possible services that could be marketed towards different verticals: Enterprise, Education, Governmental and even to other Service Providers in a wholesale fashion.
As far as Telecom evolved to become a business, Managed Services have been used to extend the service possibilities to customer domains. In order to separate the Service Provider to the Customer Service domains, points of service demarcation have been used to clearly separate responsibilities via CPE (Customer Premises Equipment). In recent years, physical CPE has been logically replaced by virtual and now Universal CPEs that could be leveraging multi-services over an open service platform called Whitebox and even Greybox to mitigate between proprietary and Open Source functions or services.
How then a SNO or SVNO can leverage its Service Infrastructure transformation towards their existing or seduce new customers? And, does Edge has anything to do with customer domain services?
What could be the structure of vCPE or uCPE service?
It should be based upon the right selection of either a vCPE or uCPE Whitebox hardware platforms that will be leveraged to sustain either a short or an extended range of services. I wouldn’t dive too much within the fundamental differences between vCPE and uCPE as I addressed in a previous article and some of my market peers have addressed this subject such as my friend Faisal Khan.
A Service Infrastructure should be constructed under the considerations of expanding the nature of the choices made for a cloud-based approach. Indeed, as virtualization and certainly containerization grow in importance, extending the choices made for cloud should be reused for Customer Service Domain and Edge considerations. Indeed, let’s kill the mystery right now, the Customer Domain is an integral part of the Edge and shall be considered as such.
Let's look at the main components of xCPE service: * NFVi/CNFi
* VNFs (Virtual Networking Functions) / CNFs (Cloud Native Functions)
* Orchestration / Automation
* What Edge has to do with it ?
NFVi (Network Functions Virtualization Infrastructure) / CNFi (Cloud-Native Functions Infrastructure)
When Cloud-based NFVi (Network Functions Virtual infrastructure) or CNFi (Cloud-Native Functions Infrastructure) are selected, any Service Providers (even SNOs or SVNOs) should foresee the impacts and the effects of these solutions once instantiated into more constrained environments where power, space and CPUs aren’t abundant.
Lightweight, CPU hyperthreaded capable, Embedded VIM (Virtualized Infrastructure Manager) or even with NFV/CNF Manager shall be prioritized in order to ensure that scalability be envisaged and even considered without disrupting any financial balance. The notion of the embedded VIM & NFV/CNF Manager are often disregarded however they often make a significant difference between a scalable working and competitive environment and a static and hardware dependent environment.
Indeed, VIM ensure the smooth relation between the Orchestration Service Layer (Orchestrator/Automation) and the Virtual or Containerized Infrastructure for the SFC (Service Function Chaining). The NFV/CNF Manager also plays a significant role in managing the lifecycle of VNFs or CNFs for creation, sizing, pausing and tearing them down.
VNFs or CNFs
Nowadays, virtualization is often considered in a more static and stable way where multi-tenancy capabilities are often associated to. Containerization on the other hand, brings a more dynamic approach where services could be spawned rapidly and terminated in the same way but also CNFs are often estimated to be ten times the size of a VNFs, making them extremely well positioned for Disaster Recovery scenarios or rapid customer cascaded services.
Tomorrow’s and certainly day after tomorrow’s Service Infrastructure would be hybrid by nature, mixing both VNFs and CNFs, to meet stability and mobility of services/applications across the entire infrastructure from Cloud/DC to Edge/PoPs and finally to Customer Premises.
Orchestration / Automation
By essence, an Orchestration Service Layer should be as open as broad in the type of services it will be supporting. Indeed, recent trends such as Multi-Cloud Orchestration, Edge and disaggregated services have massively increased the market expectations towards Orchestration SW vendors. Faster track to revenues has been the ultimate message for any players on the market, but is it a just a telecom fable or a reality?
I fundamentally believe it is possible if the selection criteria of Orchestration Service platform are clearly inclined towards broad capabilities that should be considered equally important:
· Large choice of NFVi/VIM of supported solution platforms
· xNF already onboarded possibilities from xCPE, vSecurity, SD-WAN, vRouter, UCaaS, Mobile Functions, etc…
· NoS and iOS disaggregation capabilities to mix both proprietary and Open-based services
· Natural evolution towards Machine Learning, AI, Intent-based Networking and Closed-Loop automation
· Avoiding proprietary Orchestration Service platforms re-interpreting Open Source notions
· API Consistent approach across the market with a consensus approach. I have been already very adamant about the relevance of MEF 55 Lifecycle Service Orchestration concept to address Northbound, Southbound but also East/West bounds API for inter-domains collaboration
· ONAP is clearly a fantastic approach but not the ultimate response for everyone and everything (even though I love it)
What Edge has to do with it?
Well, it has everything to do with it and here's why...
The concept of Edge is nothing else than just a view that services shouldn’t centralized but distributed across the Network Architecture. Therefore, leveraging Service Provider POPs (Point-of-Presences) or those of partners. Naturally, Edge would provide a replication of the Cloud services in order to deliver a continuous view of services from Cloud to Edge and a seamless quality of experience across the board.
Now, if we consider the Customer Domain, it would be then approach similarly as an extension of services provided from the Cloud perspectives but with an obvious proximity with Edge located devices or services, which can either some advantages or not.
CPE or customer services demarcation comes from the idea that Managed Services is often composed of multiple functions whereby one function equals to one physical device. With new service concept such as uCPE, multiple functions could be then managed over a single physical device where hardware resources (CPU cores / Memory / Storage) would be then split logically to allow multiple functions (VNFs or CNFs) to reside in it.
Market experience proves us that Managed Services usually doesn’t restrict itself to just one or two functions but can extend quickly. However, some core services require to be located at customer premises because being real-time sensitive but also highly facilitating the life of users such as security (vFW & vDDoS protection), vRouter or SD-WAN, vSBC (Session Border Controller) and Carrier-Ethernet capabilities. However, uCPE service platforms don’t provide infinite hardware resources and nowadays applications require a growing requirement of CPU cores, memory and storage, thus, making the balance exercise extremely complex. But, as technology evolves customer demands and expectations grow, without considering all the limiting aspects that technology while evolving cannot overcome this easily.
Thus, another way to look at it would simply be to fully accept that both PoPs and Customer Premise locations would represent Edge locations and should be considered as complimentary rather than opposed. For example, in rather uCPE distributed approach, uCPE would see only core connectivity functions as SD-WAN or vRouter and Carrier-Ethernet UNI to be hosted within the uCPE service platform in the customer while the rest of the applications would reside at Edge to provide a Multi-Tenant access to other key applications such as vFW/vDDoS protection, vCDN and OTT Broadcast, SBC/vPBX/UCaaS, vMPLS PE functions and others I might have forgotten…
In a more interesting approach and hybrid methodology, uCPE and PoP location would simply see core customer functions (vFW / vRouter or SD-WAN / SBC / Carrier-Ethernet UNI) located in the uCPE service platform while other key but processing and bandwidth hungry functions or services would be collocated at the nearest PoP.
The two examples show how complimentary Edge locations and Customer Domain locations can be. This also illustrates that such applications of distributing functions/services would adequately impacts the economics and the CAPex costs required at customer locations but also improving the scalability and flexibility to extend the number of services to be supported over time.
HOW LEO SATELLITE CONSTELLATION MIGHT BENEFIT FROM NaaS INNOVATION?
New generation of satellite-based services will be structured around LEO (Low-Earth Orbit) satellites, as explained before, should bring Satellite connectivity to a whole new level of low-latency and high-bandwidth connectivity. However, LEO satellites are often deployed in constellation since many LEO satellites are required to maintain a continuous coverage over terrestrial areas. This direct contrasts with GEO or MEO satellites, which provide a more permanent coverage over larger territory parcels.
Typical satellite constellation-based services are very popular such as GPS, Galileo for GNSS services often used for ToD (Time of Day) distribution for Mobile services and Teledesic dedicated in providing broadband Internet services.
Satellite terrestrial services provided at Teleports, are often based upon MPLS services to maintain a flexible and adaptable VPN services logically segregating customers. All Service Providers are creature of habits trying to use and reuse what they know best but also what their engineering team are trained for. Therefore, LEO satellites are anticipated to be using MPLS-based technologies, quite possibly either VPLS or Ethernet over MPLS.
NaaS (Network as a Service) approaches such as SD-WAN can provide a solid alternative to provide underlay (means of connectivity) but great overlay capabilities (Application-aware and policy-based monitoring capabilities over any media). As a NaaS-based technology, SD-WAN when based on Open-Source principles such as REST-based and YANG software modeling provides the right elements to integrate SD-WAN router software to be onboarded in both NFVi (OpenStack or alternatives) / CNFi (Kubernetes & Docker) and to have SD-WAN controllers to be also onboarded into orchestrators.
Clearly MPLS doesn’t do the job anymore by taking way too much delays to implement new locations and to even change tunnels and service parameters. On the other hand, SD-WAN uses policy-based decision routing processes, notably controlled through SD-WAN controllers to establish smart routing sessions that could be monitored, and parameters altered in a rapid fashion.
Recent release of the MEF 70 specifications, also, aligns to existing SNOs technologies usage where both IP and Carrier-Ethernet services and features play a significant role. Indeed, MEF 70 (SD-WAN Service Specifications) highlights that SD-WAN service attributes could either be L2 or IPv4 or IPv6, which encompasses today’s and tomorrow’s service requirements.
WHICH USE CASES MIGHT BE CONSIDERED WITH A NEW GENERATION OF SATELLITE SERVICE INFRASTRUCTURE?
Here are a couple of paragraphs of Satellite oriented use cases to provide some overview about the possibilities and service options that LEO will open-up for our industry.
LEO and 5G Backhaul
Fiber penetration will be one of the most important challenge to ensure 5G coverage as extended as possible. Indeed, with Mobile Networking and 5G Core functions being virtualized or containerized but also distributed across the Network architecture such as eNodeB sites, Edge or DC locations notably to facilitate network slicing.
Lack of fiber availability could seriously negate any efforts to ensure that x-Haul (Backhaul / Midhaul / Fronthaul) capabilities are provided to ensure that customers access to expected services and applications located in various network/service slices.
Due to a much lower orbit than usual satellites (GEO & MEO), LEO satellite constellations would provide a much stronger guarantee of low-latency connectivity with a theoretical ground to satellite latency of about 1-4 milliseconds compared to 125 milliseconds with today’s satellite technologies. This making LEO Satellite, a viable alternative for advanced Quality of Experience (QoE) and to tap into new generation of services such as 4K Video capabilities at Edge, Connected cars, faster cloud solutions and larger number of business verticals.
LEO and IoT
5G and Mobile connectivity is not the ultimate panacea for all services because its exploitation will be extremely costly in time and resources to build the physical and the logical infrastructure to ensure the correct foundations of a viable and future-proof service.
LEO Satellites can provide a complimentary connectivity methodology for rural or isolated locations where typical connectivity are not available. IoT-based Satellite communications could be the next big thing, whereby, terrestrial communications are only covering about a quarter of the earth planet surface while LEO Satellite constellations might cover the entire surface of the globe.
LEO satellites require less energy for placement and transmissions than other satellite technologies, they also provide a much higher bandwidth and reduced latency. Because of their orbital movement, LEO satellite can provide a space-based packet-based network where packets/frames can be routed/switched from satellite to satellite leveraging SD-WAN---- as explained earlier. Recent tests have been conducted to evolve LoRa enabling satellite-based communications between LoRa devices using the LoRaWAN protocol.
This will open-up avenue of opportunities towards sensor-based communications for agriculture, retail, automotive, transportation, maritime comms but also other strategic verticals in oil and gas.
LEO and Video CDN & OTT Broadcast
Satellite has seen its market rise and unavoidable place via the distribution of linear TV but with the market unstoppable march towards CDN and OTT video content distribution has fundamentally shaken and alerted Satellite companies.
The move towards LEO satellite constellations was an obvious response to allow Satellite Network Operators to remain relevant and to adapt their service offerings to OTT and CDN-based approaches. Simultaneously, several regions of growth for digital TV in emerging markets (Latin America, India and Africa). HD and certainly 4K resolution-based content have seen a slow penetration due to infrastructure challenges and limitations of core networks to absorb the anticipated bandwidth consumption growth.
CDN, Contents of any kinds on demand, OTT solutions and interactive solutions will certainly revolve around these new ways to bring contents addiction to a growing customer base where emerging markets will bring a major contribution. Despite of LEO satellite technologies being a credible alternative, the business case is still making Satellite actors unsure of LEO being the adequate balance of investments vs fast access to revenues. Another consideration is growth impacts that such a transformation would also have over Teleport capacity and existing services. In the meantime, emerging markets are now gradually in technology maturity and evolving towards broadband wireline/wireless possibilities that would install another local competition.
Satellite Meshed Services
Some major satellite market actors consider possible, through tremendous investments, to develop massive scale LEO satellite constellations and to provide a lower-cost service than GEO and even MEO satellites. By tweaking certain technology aspects such as customer terminals able to fine tracking satellite motion, therefore compensating against the Doppler effect of a moving object aka satellite, this would significantly improve both the quality and low-latency capacity.
Indeed, supported by a global constellation of LEO satellites will ensure an almost constant and viable high-throughput and low-latency satellite connectivity. Combined with the latest applications or media aware overlay technology such as SD-WAN, this could provide an entire meshed satellite network opening-up endless possibilities such as : Meshed customer SD-WAN connectivity but also to address governmental, corporate networks, isolated and remote places connectivity but also pushing it towards backhaul for wireline and wireless service providers, IoT backhaul, Connected and driverless cars. Well, I guess you all get the picture…
SUMMARY
I hope this wasn't a boring read but...
Evolution of communication technologies (Telecom) has been an endless quest for human beings since we started to knock on trees and used smoke signals to communicate over long distances with other peers. Recent innovations such as VNF, CNF, Orchestration/automation, Multi-Cloud concepts have accelerated since the inception of ONAP and now network disaggregation with iOS/NoS is also showing-up as new options.
Satellite technologies, as described, in this multi-parts article has explained how important and valuable latest innovations in the IT/Telecom field would be to improve options and possibilities. The interests for Satellite are not there to supersede other communications means but offer complimentary options to existing wireline or wireless connectivity options.
Complimentary technologies naturally imply that partners’ service infrastructure could ensure a two-way collaboration where consistency in technology layers would unavoidable for hardware, NFVi/CNFi, Software-Defined underlay & overlay services, Orchestration Service Layer, OSS/BSS and above all API consistency. Some say that these are pious vows but collaboration over competition would do wonders.
Written by Luc-Yves Pagal Vinette