Shaun – 5G Slicing – Hauling Legacy Fulfilment and Assurance

From Physical to Logical: Specifying a Robust ServCo-NetCo Interface for Fibre Network Management

Introduction

These notes aim to guide the specification, design, and building of an interface between NetCo and ServCo. A NetCo is primarily responsible for managing physical infrastructure, such as Fibre Optic cables. Consequently, the Physical Network Inventory (PNI) system and application must accurately represent physical network elements (which are mostly passive) both logically and spatially. THe SerCo on the other hand centres around customer services and product offerings, enabling mobile and Internet product and service access to end users.

A PNI application and system must integrate with GIS (Geographic Information System) Systems and with Production systems (in the TMForum ODA sense) that are part of the ServCo. While GIS systems gather, manage, and analyze spatial and geographic data, TMForum ODA Production systems are responsible for fulfilling Telecommunication Services.

A key challenge in fibre network management is the lack of open standards for inventory data exchange. This necessitates that Communication Service Providers (CSPs) and Digital Service Providers (DSPs) specify and develop custom integrations between the PNI system and the Production System, specifically the Logical Network Inventory (LNI) system and the Service Fulfillment system. Some level of decoupling between systems, particularly when provided by different vendors, can be achieved using a REST architecture or SOAP interface.

Constrains on specifying, designing and building the interface

The specification, design, and building of this interface are subject to specific constraints, particularly concerning communication, coordination, and consistency. These concepts, as covered in “Fundamentals of Software Architecture” by Mark Richards and Neal Ford, are critical to understanding the design choices made.

Communication: The chosen communication method had to be synchronous. Implementing and productionising queuing and messaging frameworks or mediations between existing systems was not feasible within the project’s scope.
Coordination: The LNI and Service Fulfillment components already orchestrate the provisioning of Resource Facing Services for various transport technologies (e.g., DWDM, MPLS) and enterprise services (e.g., Carrier Ethernet, SD-WAN). This existing orchestration relies on APIs for synchronous request-response interactions, rather than the choreography seen in Intent-Based Networking where autonomous systems communicate collaboratively to fulfill an order.
Consistency: Given the synchronous communication and the coordinated nature of orders between the two systems, it is important for transactions to operate atomically. This ensures near real-time consistency in the lifecycles and operational states of Optical Fibres and the services they transport.

Fulfillment and Orchestration Logic, wherever possible, requires automated decisions for path-finding in both the physical and logical networks, along with corresponding resource allocations in PNI and LNI. This highlights the complex handoffs between the NetCo and ServCo domains. Visualizing the flow within the interface contract is essential to surface the intricate dependencies for completing specific flows that consume dedicated API endpoints to achieve the above.

Data and Information Modelling

This section outlines the critical aspects of data and information modeling required for effective interface specification within the ServCo-NetCo domain. These elements are essential for enabling effective system interactions.

Physical and Resource Logical Relationship Mapping: This involves defining and mapping the relationships between physical network assets and their logical representations. A clear understanding of these relationships is fundamental for network planning, provisioning, and fault management.
Location and Cost Modeling for Path-Finding: Accurate location and cost models are vital for efficient path-finding algorithms. These models facilitate the identification of optimal routes for services, considering factors such as latency, bandwidth, and cost to route.
Data Master-ship: A clear definition of data master-ship is essential. This specifies which system is the authoritative source for each shared entity, preventing data inconsistencies and conflicts across the integrated environment.

Fulfilment and Orchestration Logic

Fulfillment and Orchestration Logic requires, where possible, automated decisions for path-finding in the physical network and correspondingly in the logical network, and related resource allocations in PNI and LNI.

Error and Fallout Handling

Designing comprehensive error handling strategies, including specific retries, circuit breaking, and backpressure expectations, is essential for managing unexpected failures.

1. Communication Errors: These can arise from network issues or misconfigured endpoints. Handling involves implementing retries, timeouts, and backoff strategies to manage transient failures.

2. Data Consistency Errors: Inconsistent data between systems can lead to incorrect operations. Ensuring atomic transactions and using techniques like idempotency can help maintain consistency.

3. Authorization and Authentication Errors: Incorrect handling of security tokens or permissions can prevent access. Implementing robust authentication mechanisms like OAuth2 and ensuring proper scope management can mitigate these issues.

4. Resource Allocation Errors: Failures in finding or reserving resources can occur. Implementing fallback mechanisms and pre-order planning can help manage resource-related errors.

5. Orchestration and Coordination Errors: Errors in the sequence of operations can disrupt service fulfillment. Using sequence diagrams and ensuring proper orchestration logic can help prevent these errors.

6 Observability and Operability: Implementing correlation IDs, audit events, and metrics can help in diagnosing and resolving errors quickly by providing insights into system operations.

Key Considerations for Robust Interface Design

Beyond the core logic, several other critical aspects contribute to a robust and maintainable interface:

Diverse Fibred Paths: This refers to having multiple routes for data to travel through the network. The idea is to ensure that if one path fails (due to damage or congestion), others are available to maintain communication. Paths can be physical, as in Optical Fibres, and logical, as in service circuits that carry Ethernet and IP traffic.
Security and Compliance: This includes defining authentication and authorization (e.g., OAuth2/bearer tokens), scopes, token handling, and considerations for Personally Identifiable Information (PII).
Observability and Operability: This covers correlation IDs, audit events, metrics, logs, and traces aligned to Service Level Indicators (SLIs) and Service Level Objectives (SLOs), along with documented dashboards and alerts.
Lifecycle and Governance: This encompasses change management and history, ensuring proper control and tracking of interface evolution.

In the end the integration option selected depends on multiple factors existing and emerging with clarifying and implementing requirements. Some points to consider when designing and building such an interface are provided here.

Intent-based networking – improving the operationalisation of network services

Intent-based networking enhances the operationalisation of network services by translating high-level business intents into dynamic network configurations.
Traditional networks enable services for customers through imperative commands. The service’s lifecycle follows a typical provisioning order workflow, where orders create, modify, or delete services. Each order is created and modified based on the necessary rework required for aspects of service provisioning parameters.

Intent-based networking provides services for customers through declarative commands that achieve the desired state of the network, supporting the intended use by customers. The service lifecycle is now supplanted by the lifecycle of the intent, which will last as long as the goals for the customer’s intended use of the network remain relevant to their objectives for the consuming service.

Expectations of an intent-based network

Intent-based network design augments automated networks to adapt rapidly to changing demands. Such a design assumes that some level of automation is already achieved in the networks and that the network demonstrates a level of elasticity to scale and accommodate fluctuating demands.

An intent-based network ensures that it consistently meets the desired service levels and quality of service (QoS) parameters defined by the intent. The QoS here would indicate how close the observed network state is to the desired state as defined by the intent.

Expectations of customers of intent-based services

As network functions shift to cloud-based services, more dynamic and flexible network provisioning must interwork with changing customer service demands. Customers demand faster and customised services with zero wait time to consume them. Additionally, the security of the network and services is maintained with every change occurring dynamically in the network.

Characteristics of an intent-based network

Intent-based networking uses Dynamic Network Resource Allocation (DNRA) to leverage such automation and AI to optimise network resource consumption based on high-level business intents.

At a high level, the following bounded contexts are required to design and implement an intent-based network, either as a layered architecture or a microservices / service-based architecture.

Analytics and Monitoring

Provides real-time insights into network performance.
Uses telemetry data to inform decision-making.

AI and Machine Lerning

Predicts network demands and optimises resource allocation.
Learns from historical data to improve future allocations.

Intent Engine and related Management and Orchestration

Interprets high-level intents and translates them into network policies.
Continuously monitors and updates policies based on feedback and analytics.

Automation

Automates configuration changes and resource adjustments.
Continuously monitors and updates policies based on feedback and analytics.

Network state reflects the configured behaviour for intent-based networking.

This topic is an in-depth topic for further updates in future posts.

Monitoring and security are maintained at all layers for intent-based networking.

This topic is an in-depth topic for further updates in future posts.

Use of Digital Twins

Digital twins are increasingly used in intent-based networking (IBN) to enhance network management and optimisation. More on this topic later

Defining and using Domain Specific Languages (DSLs) for Intent-based Networking

Domain-Specific Language (DSL) for IBN are specified to express intents in a human-readable and machine-executable way.

Key features include

High-Level Abstractions
Declarative Syntax
Policy Definition
Description of Network Topology and relationship between network elements (as in protected, diverse, etc)
Declarations for validating intents against the current network state and policies
Declarations for closing feedback loops that monitor network state and adjust configurations as needed.

Challenges with designing and maintaining Intent-based Networks.

Intent-based networking is not without its challenges.

Complexity with closed loops at multiple layers – Business, Service, Technology

Achieving closed-loop automation, a key goal of AN, relies on the network’s ability to translate intents into configuration actions, monitor the outcomes of those actions, and make necessary adjustments to ensure intent fulfilment. Such closed-loop automation requires advanced monitoring, analytics, and AI/ML capabilities at multiple layers to enable the network to learn and adapt to dynamic conditions.

Hidden side effects of closed loops – hidden commands and hidden states

Developing robust mechanisms for expressing intents unambiguously and enabling the network to interpret those intents accurately is essential for network stability and interoperability.

Advances in natural language processing, standardisation of intent models, and potentially domain-specific ontologies would benefit such defined expressions of intent and ensure shared understanding between users and the network.

Security and trust in intent-based systems

As network operations evolve towards greater autonomy, ensuring the security and trustworthiness of intent-based interactions should also grow in parallel. Security in intent-based networks includes protecting intent expressions from unauthorised modification, verifying the authenticity of intent sources, and implementing protections to prevent malicious or unintended consequences from automated actions.

Navigating Trading, Trunking, and Technology in International Voice Services – Challenges and Learnings

Introduction

International voice services are still relevant to telecommunications as they play a key role in connecting people and businesses across borders. Millions of calls are made daily as such services facilitate frictionless communication. The premise of such services are termination of voice calls to the correct destination in any part of the world that has telephony.

And as the margin for such services falls each year due to advances in technology, such as VoIP and 5G, among other factors, it is essential to have finely tuned business models and processes for these three Ts. While over-the-top (OTT) services continue to grow in terms of minutes of voice traffic, carrier services still handle significant numbers of voice traffic for business and social calls as they terminate large volumes of international voice traffic. So the challenge is offering such services with improved QoS and improved efficiencies in Trading, Trunking, and Technology. The following are some of my learnings on this topic.

Trunking in International Voice Services

Consumer Voice vs Wholesale Voice

Voice traffic is broadly classified as wholesale and retail. Wholesale voice traffic refers to large volumes of calls terminating at destinations in a carrier’s network. Retail voice is largely carrier-specific, and consumer voice traffic is routed directly by the service provider to the destination, usually bundled with some form of data service.

Voice Termination in Destination Networks

This is the final step in a carrier’s call processing and delivery ecosystem for international carrier voice. The high-level steps are as follows:

Call Origination: A call starts when initiated by a caller and is routed through the caller’s local telecom provider’s network.

International Transit: The call is transported across borders using physical transport technologies like submarine cables, satellite links, and protocols for VoIP like SIP and RTP.

Call Routing: The call is routed across borders by international carriers selecting paths based on efficiency, cost, and agreements, using interconnect solutions that include private and dedicated IP links, public IP networks, third-party private IP networks, and hubbing services.

Call Termination: The call reaches the recipient’s local carrier, ensuring delivery with quality and minimal latency.

Technology in International Voice Service

High-quality voice transmission is essential, requiring technologies to minimize latency, jitter, and packet loss. In addition to these network functions, the following section describes control plane functions involving decision-making and policy application, and data plane functions representing data generated from call activities.

Routing Technology

Least Cost Routing: This is as explained in detail on Wikipedia. Least-cost routing (LCR) in telecommunications is a method used by carriers to select the most cost-effective paths for outbound communication traffic. This process involves analyzing various routing options based on cost, quality, and capacity. LCR teams within telecom companies regularly evaluate and choose routes from multiple carriers, which can be done manually or automated through least-cost router software..

The LCR Process is also explained on Wikipedia. An example of the LCR team cycle in a carrier is as follows.

Buyers negotiate new price schedules with suppliers.

Prices are loaded into software for termination cost calculations and comparisons.

A route is selected, establishing a cost-for-pricing, and new prices are issued.

New routes are implemented on the switch; traffic volumes and margins are monitored via billing system reports.

Loss-making traffic and odd routing is investigated; billing data is corrected, or action taken on routing and pricing as needed.

Origin Based Routing: With origin-based routing, carriers include the originating country or originating network to determine the routing of calls. So, the routing of calls is based on the origin of the call. Origin-based routing should allow carriers to manage cost, QoS, and regulatory compliance more effectively using the following data sets.

Origin Sets: These are groups of area codes or country codes that define the origin of calls. These sets are used to categorize calls based on their geographical or network origin, allowing for differentiated routing strategies.
Routing Destinations: The endpoint to target location for call termination explained above. Routing destinations are also manifested as country codes or numbers allocated to specific network operators within a country. It is the destination that is used to determined what route a call can take to be terminated correctly.
Call Routing Labels: Routing rules and policies define the specific routes the call takes through the network. Each routing rule has an identifier or tag associated with it, and this mechanism enables the call to be routed according to the rule enforced by the tag, e.g., QoS, priority routes per tag(s), cost-based routing decisions per tag(s). In this way, call routing is aligned with business models and pricing models.
Routes: The specific path the call takes from call origination to call termination. Routes are determined based on various factors, including cost, quality, and regulatory compliance. Carriers use routing tables and algorithms to select the most appropriate route for each call, taking into account the origin set and routing destination.

The Role of Call Detail Records

This is defined as in Wikipedia. A Call Detail Record (CDR) is a data record produced by a telephone exchange or other telecommunications equipment that documents the details of a telephone call or other telecommunications transaction, such as a text message or data session. CDRs are used by telecommunications companies for billing, monitoring network usage, and analyzing network performance. Here are the key components typically found in a CDR:

1. Call Date and Time: The date and time when the call was initiated and terminated.

2. Call Duration: The length of the call, usually measured in seconds.

3. Calling Party Number: The phone number of the person who initiated the call.

4. Called Party Number: The phone number of the person who received the call.

5. Call Type: The type of call, such as local, long-distance, international, or roaming.

6. Call Status: Information about whether the call was completed, failed, or busy.

7. Unique Call Identifier: A unique identifier for the call, which helps in tracking and managing records.

8. Route Information: Details about the network path the call took, which can include information about the switches and trunks used.

9. Billing Information: Data used for billing purposes, such as the rate plan, cost of the call, and any applicable taxes or surcharges.

10. Service Provider Information: Details about the service provider handling the call.

11. Additional Features: Information about any additional services used during the call, such as call forwarding, conference calling, or voicemail.

Trading in International Voice Services

Termination fees in International Voice Services

Whenever a call is completed on a carriers network a termination fee is charged by that carrier. This fee forms the bases of the cost structure of international voice services, and it is the cost incurred by the carrier to connect the call to the called user. Each carrier involved with routing the call from the call origination to the call destination plays a role in call termination and hence is entitled to intercarrier compensation. These fees vary significantly depending on the destination country and the related carrier network in that country. This is explained in detail on Wikipedia

Cost Structures and Pricing Models for International Voice

In the international voice carrier wholesale market, carriers employ various pricing models to optimize revenue and maintain competitiveness. These models are designed to address the dynamic nature of the market, which is influenced by factors such as demand fluctuations, regulatory changes, and technological advancements. Here are some common pricing models used by carriers:

1. Cost-Plus Pricing: This model involves calculating the cost of providing the service and adding a markup to ensure profitability. It is straightforward but may not always reflect market conditions or competitive pricing.

2. Tiered Pricing: Carriers offer different pricing tiers based on volume commitments or quality of service. Higher volumes or better quality often come with lower per-minute rates, encouraging customers to commit to larger volumes.

3. Destination-Based Pricing: Prices are set based on the destination of the call. Rates can vary significantly depending on the country or region, reflecting the cost of termination and regulatory factors in those areas.

4. Time-of-Day Pricing: Rates vary depending on the time of day the call is made. This model helps manage network congestion and incentivizes off-peak usage.

5. Flat-Rate Pricing: A single rate is charged regardless of the destination or time of the call. This model simplifies billing and can be attractive to customers who prefer predictability.

6. Dynamic Pricing: Prices are adjusted in real-time based on demand and network capacity. This model requires sophisticated technology to implement but can maximize revenue by capturing higher rates during peak demand.

7. Bundled Pricing: Carriers offer packages that include a set number of minutes or a combination of services (e.g., voice, data, SMS) for a fixed price. This can increase customer loyalty and reduce churn.

8. Promotional Pricing: Temporary discounts or special offers are used to attract new customers or increase usage among existing customers. This can be effective for entering new markets or countering competitive threats.

9. Quality-Based Pricing: Different rates are offered based on the quality of service, such as premium routes with guaranteed quality versus standard routes. Customers can choose based on their quality requirements and budget.

10. Revenue Sharing: In some cases, carriers may enter into revenue-sharing agreements with partners, where revenue is split based on predefined terms. This can be beneficial for expanding reach without significant upfront investment.

Carriers often use a combination of these models to tailor their offerings to different customer segments and market conditions. The choice of pricing model can significantly impact a carrier’s competitiveness and profitability in the international voice carrier wholesale market.

Hubbing vs Bilateral Trading in Voice International Interconnections

Bilateral trading focuses on direct, high-quality connections between two carriers, while hubbing involves multiple carriers and offers more flexible routing options but can vary in quality depending on the interconnection topology used.

Bilateral Trading:Bilateral voice international IP interconnections involve two carriers directly interconnecting their networks to transport voice calls and services. This setup is typically used to interconnect retail networks, whether mobile or fixed. The combination of voice traffic to be carried through the international IP interconnection is determined through bilateral negotiations between carriers

Hubbing: The international voice hubbing service involves multiple international carriers to deliver voice services between end users. It allows the exchange of international voice calls with multiple networks via one voice over IP interconnection. Hubbing services can involve multiple transit hops as calls transit through several carriers towards their destinations, especially for lower quality levels. Hubbing allows for more flexible routing options and can be used to reach multiple destinations through a single interconnection point.

While the industry is mature, the challenge is in efficincies and optimization for these three Ts.

Key elements of a Well Behaved Network Service Orchestration Layer

With rapidly changing digital landscapes in IT and Telecoms, agile and efficient network services and provisioning of the same is of increasing importance. A well-behaved network service orchestration layer is essential for meeting these demands, particularly as technologies like Software-Defined Networking (SDN) and Network Functions Virtualization (NFV) continue to evolve. The following identifies key elements that constitute an effective orchestration layer, highlighting its role in facilitating seamless service delivery, to be explored further in future.

1 Model Driven Architecture

A robust orchestration layer should adopt a model-driven architecture. This approach utilizes service models to abstract service configurations from the specific implementations tied to vendor devices. The benefits of this abstraction include:

Simplified Service Design:

By decoupling service design from device specifics, operators can create and modify services more rapidly.

Standardisation:

Utilizing standards like YANG allows for a human and machine-readable format, making programmatic manipulation easier and more efficient.

2. Programmatic Configuration

Programmatic configuration is another enabler of a well-behaved orchestration layer. This involves:

Automation of Configuration Tasks:

By leveraging standards-based interfaces such as NETCONF and YANG, the orchestration layer can automate network element configurations.

Increased Accuracy and Consistency:

Automating these tasks reduces reliance on manual command-line interface (CLI) inputs, minimizing errors and enhancing service provisioning speed.

While the adoption of NETCONF and YANG is still progressing, supporting non-standard interfaces for devices lacking native support is important for comprehensive orchestration.

3. Integration with Operational Systems

A successful orchestration layer must seamlessly integrate with existing operational systems, including:

Business Support Systems (BSS) and Operational Support Systems (OSS):

This integration is facilitated through well-defined northbound APIs, enabling efficient information exchange and process coordination.

NFV Management and Orchestration (MANO):

Interaction with the NFV MANO stack is important for deploying and configuring virtual network functions (VNFs) based on specific service requirements.

4 Transactional Reliability

Transactionality and reliability maintains network integrity. A well-behaved orchestration layer should:

Enforce Atomic Operations:

Configuration changes should be applied as a single transaction, meaning either all changes succeed or none do. This prevents partial configurations that could lead to inconsistencies and errors.

Safeguard Nework Consitency:

By rolling back transactions in case of failures, the orchestration layer helps maintain a stable network environment.

5 Stateful Network Awareness

Maintaining stateful network awareness is essential for effective orchestration. This involves:

Real-Time Monitoring:

The orchestration layer should have a near-real-time view of the network’s configured state, including the status of all services and devices.

Informed Decision-Making:

This awareness supports reliable configuration decisions and enables quick rollbacks if issues arise.

Incorporating these key elements into a network service orchestration layer significantly enhances the agility, efficiency, and reliability of network operations. Market evolution along with complexity and diversity of Telecommunication Networks makes it challenging to standardize APIs. This could be one of the reasons why SDOs like TMForum and MEF APIs have a Service-Centric approach in the definition and standardisation of APIs. Additionally Network equipment vendors often have proprietary interface and APIs adding to integration challenges. To be explored further in future posts.

GenAI for telecom OSS

This post explores the use of GenAI in transforming service life cycles and service operations in Telecom OSS.

The use of AI starts with identifying and prioritising use cases to be defined that will result in the implementation of transformed service lifecycles and service operations that use AI or GenAI.

Identifying and prioritising use cases for OSS

One way of identifying use cases for ML, AI, and GenAI in Telecoms is by considering the sources of data available from CSPs.

These sources of data are available at the following layers

Data Collection and Data Flow Layers

This includes

Data collected from Network Elements, Network Element Management Systems per Technology Domain
Data collected from Customer Devices, and Physical and Virtual Customer Network elements
Data entering and leaving the network via Carrier Interconnect
Data traversing internally within the CSP Network (Access, Aggregation and Core)
Data leaving customer sites, traversing the access, aggregation and core networks, entering and leaving data centres and cloud.

Data Aggregation, Processing, Control/Routing Layers

This include

Data Aggregated across Technology Domains – Network Device and Connectivity data from related platforms and Cloud platform data
Control Data from Network Controllers that work across domains with respective Domain Controllers
Transactional Data from Network Automation used for network configuration, network provisioning, and service activation.

Service Orchestration, Service Assurance Layers

This includes

Monitoring and performance data from Network Services and Customer Facing Services
Service availability and uptime metrics
Performance metrics of automated processes
Success and failure rates of automated tasks

Selection and use of Pre-Trained models

General purpose LLMs are in most cases not suitable to drive improvements in the use cases identified using the above.
The inferences provided by such models mostly do not benefit the cost of using them. Telecom and OSS tasks are specific to multiple technology domains like DWDM, Carrier Ethernet, Wireless, and IP.
Hence pre-trained models on telecom data provide a head start toward the use of such models in the use cases described above, in the context of relevant business scenarios.

Identifying and selecting pre-trained models requires considerations of cost to obtain a license and cost to run, costs to customise and costs to fine-tune. Additional considerations include the type of model to use for the type of problem. e.g. Transformer type models used in LLMs or “simpler” models that use Decision Trees, Linear/Logistic Regression for supervised learning, K-NN for unsupervised learning or Feedforward Neural networks.

Additionally, as LLMs continue to evolve, the commercially available model could be updated by the vendor. So inferences made previously might change significantly and these outputs may be significantly different requiring altering of prompts previously used.

Fine Tuning Models for Telecommunications use

Generic models can be fine-tuned for telecom by training on telecom-specific Q&A types of texts or prompts. A final stage would use reinforcement learning from human feedback.

Other Challenges and Considerations

One of the challenges with using Gen AI is remaining non-biased and this requires vigilance when using data sets to avoid the use of skewed data sets.
Another challenge is understanding the training algorithms and training parameters, which means understanding how the models are trained to help prevent bias creep and misinterpreted results.
A third challenge is handling data privacy, especially with the use of customer data.
And a fourth challenge is keeping up with regulatory laws as they are updated.
Future posts to elaborate on the above.

Navigating the Complexities of TMF APIs in Modern Telecom and E-commerce

Overview of TMF APIs

The TMForum OpenAPIs are a set of RESTful APIs designed to support the telecommunications industry. The OpenAPIs can be grouped into categories such as Product & Service Management, Customer Management, Service Assurance, and Resource Management.

The current v5 API definitions use Open API v3. And the shared data model is based on TMF SID and published as a set of JSON schema definitions. The shared model is implemented across multiple TMF Open API specifications so any specific business model e.g. Customer domain requires model components (schema definitions) from other related Open API specs in order to maintain SID data model compliance.

While these APIs and models promote interoperability across service providers in a Telecom services domain, there are some challenges to be faced when working with business services in e-commerce like domains that have marketplaces for products that represent endpoint OTT services. These OTT services can use any of the underlying connectivity services provided by CSPs.

The API-first approach in these domains is different from TMF API-first built products and services in the BSS/OSS domain.

Navigating API and Schema Integration Challenges in Business Services

Marketplaces for business applications and/or business applications themselves have sets of API and related JSON schema definitions that rarely map one-to-one with TMF JSON schema definition sets used by TMF APIs.

The need for such mapping could arise when offering additional services to customers with existing telco services and subscriptions. This allows customer to also subscribe to these OTT services which can be delivered and billed with existing Telco services.

Given most of the interactions are B2B there is some challenge in building this adaptation for use cases related to ordering and fulfilling such services.

Evolving API Architecture for Interoperability and Consumer Focus

While there is a need for interoperability between service providers there is also a need for simplicity and interoperability between B2B2X providers and consumers. And API design ideally needs to be API consumer focussed. Consumer designs depend on the context. There are consumers of Telco services APIs and consumers of e-commerce business services APIs.

When using TMF APIs, REST resources are used to represent Collections, Tasks, and Individual Resources represented by REST APIs and related JSON schemas. And these resources are identified via an identity of an “Addressable” resource; they can be extended (using polymorphism) via an “Extensible” resource. The “Types” of resources have a type related meta-data. These can either be extended or modified to add attributes to the resource that the “Type” represents by way of characteristics.

When using e-commerce APIs however, in many cases the APIs are nested to maintain logical relationships between resources. This is for grouping related information in logical end points by association. This helps align with the bounded context of the solution. For example /users/:userId/orders/:orderId or /categories/:categoryId/products/:productId

Bridging the Gap: Integrating Diverse Models and Languages

This requires additional effort to integrate, such as the development of anti-corruption layers or translation layers to bridge the gap between different models and languages.

And this makes it challenging to implement all the mandatory aspects of the TMF APIs as described in the API specification. Especially when integrating with Non-TMF Compliant SaaS APIs which leads to complexity with data mapping and extensions of APIs.

Therefore, the scope of adoption and the extent of adoption of the TMF APIs have to carefully considerered in any architecture design for such scenarios.

Exploring Automation in Telecoms – opportunities and challenges -drivers of efficiencies.

Thinking about Telecom Automation for a local round table with CSPs in the country, a few topics surfaced that will be noted here as part of a series on this.

The first discuses the why of automation in the Telecom industry and Telco’s move from CSPs to DSPs.

One aspect of why is drivers for efficiency which includes the usual candidates; reducing costs, improving customer experience, and enhancing network performance.

A second aspect of why is the adoption of standards to leverage AI and ML for network optimisation and service operationalisation. (e.g. ETSI TS 129 520 from 3GPP TS 29.250). This allows for effectiveness and efficiency in managing the network, deploying Devices, Virtual Devices and Containerised Devices representing Network Functions to the network, and fine-tuning product and service offerings to each individual customer.

A third aspect of why is to enable integrations with Suppliers and Partners to allow entry to the Digital Services Markets offered by SaaS providers. Business capabilities are exchanged to provide E2E services. It is almost certain that some data transformation is required for integration.

Assume patterns of Domain Driven Design are used in such integrated bounded contexts and data model translation occurs in such contexts following best practice for effective and efficient designs with microservices. Then depending on how the SaaS service forms the bounded context relationship with the CSP, the definition and use of APIs for effective collaboration and communication changes. Additionaly any such translation can be stateful or stateless. Given such volatility in design the use of standards as provided by TMForums OpenAPI cannot adapt and increase complexity in integration in such contexts.

Operationalization of SD-WAN services

SD-WAN service orchestration and control allows managing the life-cycle of SD-WAN services as available with API, automation tools, and eco-systems from SD-WAN providers.

There is a need to operationalize SD-WAN services using existing IT systems in CSPs that have customer data.

The key capabilities of SD-WAN are as follows.

SD-WAN includes secure overlay connectivity that uses IP packet forwarding and routing based on policies for end-user applications and their traffic demand.

SD-WAN has multiple options for Transport underlay and is independent of it.

Service assurance is automated for each SD-WAN connection (as a virtual tunnel). SD-WAN Orchestrators and Controllers centralize management, orchestration and control of SD-WAN services.

Services are highly available; this helps automate deployments of specific SD-WAN offerings from SD-WAN vendors.

Operationalization via IT systems integration

Integration with these systems would depend on a few factors – at least three.

Whether the CSP SD-WAN solutions include multiple SD-WAN vendors
Whether the deployment is on a large scale, especially at the Telco Edge
How well any automation loop can be closed with the operational stack’s downward-facing service fulfilment and the operational stack’s upward-facing service assurance

All of these factors call for the introduction of a NaaS layer to allow IT systems to use the SD-WAN deployment systems.

Options for such a NaaS layer can be implemented

Using standards as described in TMForum NaaS
Using Hyperscalers
Using a Customized in-house adaptation of Vendor offering

Using TMForum NaaS

This is described in TMForum IG1224, and the application of NaaS to SD-WAN has my contribution to IG1224 with my SD-WAN PSR model (Product-Service-Resource) model as peer reviewed and approved in Appendix A.

Using Hyperscalers

Using compute, storage and network from hyperscalers increases the cost as management and orchestration endpoints at the edge increase. Large-scale edge deployments with virtualized CPEs may not scale cost-wise on hyper-scalers.

In-house

Using a customised in-house adaptation of Vendor offering depends on CSP’s existing system and capabilities.

Finally, for any SD-WAN service, aligning with the performance and capacity of the underlying transport layer is required for closed-loop automation.

The existing performance monitoring solution and its closed loop will ensure that SD-WAN services meet their SLAs.

SD-WAN Operating Models

Traditional Enterprise WAN connectivity requires L2/L3 (L2.5) type protocols like MPLS to guarantee bandwidth between sites. The speeds selected from product offers for MPLS were guaranteed by the network based on QoS settings in the network. A form of security is provided by the MPLS network in the sense that the network is separate from the Internet and forms a VPN between enterprise sites.

However, maintaining such networks is costly for Enterprise Business, and SD-WAN has emerged as a possible less costly alternative. With SD-WAN, the control and data plane are separated, with the routing decisions centralized in the controller and forwarding done at the edge.

SD-WAN has been described extensively by MEF, and the service components there have been identified as

SD-WAN Edge – SD-WAN provider to SD-WAN subscriber interface
SD-WAN Controller – For Service Management
Service Orchestrator – which I consider a Domain Orchestrator Orchestrator
SD-WAN Gateway – for interconnect of transport service
Subscriber – web Portal – for Service Management and Service Operations

While the service and service management models have been described extensively, the “operate” model that connects to IT systems has also to be considered.

In a similar vein as such operate models are being considered for 5G slicing, an “operate” model of SD-WAN is considered here. Additional details are in my contribution to TMForum IG1224 for NaaS.

The following figures are based on the MEF models and illustrate

A logical representation of the SD-WAN net,

And a logical representation of SD-WAN related circuits.

The “operate” model utilizes this by exposing SD-WAN services to the IT layer, which is the core commerce layer in TMForum’s open digital architecture.

Such a model is described in detail in my contribution to IG1224 Release 13 (currently in draft).

Further notes on 5G Service and 5G Slice Relationship

5G Slicing enables the partitioning of physical 5G core and RAN Networks into one or more logical networks.

Each network slice is isolated end-to-end and tailored to fulfil diverse requirements that a particular service requests. This technology allows multiple 5G services to use one or many 5G slices, and one 5G service can use multiple 5G slices, depending on the specific needs of the service.

In the era of 5G, diverse use cases and services have different requirements in terms of latency, reliability, bandwidth, security, and quality.

Network slicing allows the creation of dedicated network resources tailored to various business customers, paving the way for the provisioning of specialized services.

Example of 5G Service and 5G Slice Relationship

To illustrate the relationship between 5G services and 5G slices, let’s consider three main types of 5G services that use network slicing: Enhanced Mobile Broadband (eMBB), Massive Machine-Type Communications (mMTC), and Ultra-Reliable Low-Latency Communications (URLLC)

.eMBB: This service focuses on providing high data rates and improved broadband experiences for users. A network slice tailored for eMBB would prioritize high bandwidth and capacity to support data-intensive applications like video streaming and virtual reality.
mMTC: This service is designed to support a massive number of connected devices, such as IoT sensors and smart meters. A network slice for mMTC would prioritize the efficient handling of a large number of connections with lower data rates and power consumption.
URLLC: This service aims to deliver secure communications with ultra-low latency, high reliability, and minimal data packet loss. A network slice for URLLC would prioritize low latency and high reliability, making it suitable for applications like autonomous vehicles and remote surgery.

In this example, each 5G service has unique requirements, and network slicing allows the creation of dedicated network resources tailored to these needs. A single 5G service may use multiple slices to meet its requirements, or multiple 5G services may share a single slice if their requirements align. This flexibility in resource allocation enables efficient utilization of network resources and ensures that diverse services can coexist on the same physical network infrastructure.

One such example is the use of slicing to broadcast a sporting event like the Tour de France. The PSR (Product, Service, Resource) model for this is as follows.

How this PSR relates to the CFS/RFS model was presented logically in a previous post to be described further in the next post.