Differentiated connectivity: Unleashing the full potential of 5G

Network traffic consists of an abundance of different data streams, all with unique characteristics and needs. By differentiating the network’s performance and making it deterministic* with regards to a set of performance characteristics such as latency and throughput, it can be offered as specialized connectivity services with reliable performance, to meet the distinct and varied needs of each application and even each application data stream. Differentiated connectivity covers the full spectrum, including application behavior in client and server, as well as networking technologies such as radio scheduler algorithms, software-defined networking (SDN), diverse 5G Core network capabilities (including UE route selection policy (URSP) and APIs exposure), operations support systems (OSS)/business support systems (BSS) capabilities (such as orchestration and assurance), and network slicing. These technologies facilitate dynamic, flexible network configuration and management to drive a differentiated user experience.

For developers, differentiated connectivity is not only of value because of a low latency or high throughput, but also because it is deterministic and reliable. When developers can trust that the performance, such as the bit rate and latency, will not drop below a specified threshold, then such connectivity services have a monetizable value. An application can then be designed with specific connectivity requirements that it is known can be fulfilled. This is illustrated in Figure 1. To ensure the required level of trust, differentiated connectivity services will be provided with the likes of: monitoring tools, monthly performance reports, and Service Level Agreements (SLAs) to business customers, guaranteeing the high availability that they are used to with other services that their applications are dependent on.

Differentiated connectivity will address the full potential of digitalization, spurring innovation and competition and making performance an important differentiator in future networks. Even today, CSPs are taking steps toward this future with premium QoS plans at a price premium, including: AT&T US (turbo plan [4]), Singtel (5G express pass [5]), Telstra (speed and latency optimizer [6]), AIS Thailand (5G boosts [7]) and 3 Hong Kong (5G Live Connect plan for live streaming [8]).

Enhancing app experience will bring app developers a wider reach, lower churn, premium payments, and the possibility of creating new applications that cannot work in the best-effort paradigm. Instead of needing to develop for the lowest user connectivity performance scenario, developers will be empowered to develop for a defined and guaranteed performance across cells in a network and across networks globally. In this new paradigm, performance will be the differentiator for user experience, and coverage of high-performance network capabilities will be a competitive advantage bringing new revenues to CSPs and a return on further network investments. In this market dynamic, CSPs who invest in network quality will be rewarded by end users and application developers, creating a virtuous circle of network investments.

A broad range of applications benefit from deterministic differentiated connectivity
Differentiated connectivity will bring value to both consumers and enterprises, in different user segments with different device types. We have defined three device/user segments to explain how differentiated connectivity can be implemented.

• Platform devices: These are consumer smartphones that feature applications distributed via an app store. An application such as outdoor mobile AR gaming would greatly benefit from differentiated connectivity to ensure the stable low latency and high throughput required for the real-time integration of high-resolution digital elements in the physical environment, assuring game developers that their users will have a great experience without delays or bad resolution.
• User-managed devices: These are typically smartphones, or, for example, a 5G router that has applications downloaded and managed through a company’s application store and IT department. Business communications applications already generate multiple data streams with different needs today, and with current hybrid working environments, the need for stable and guaranteed connections is critical for productivity and employee satisfaction.
• Full-stack systems: These include devices with built-in connectivity, that feature apps controlled and installed by the manufacturer/integrator of the device or system. This could be, for example, a car or a TV-camera for broadcasting, requiring a trusted uplink capacity to ensure that they can reach their viewers with live coverage.

Bringing differentiated connectivity to the market
Differentiated connectivity can be sold either directly from CSPs to consumers or enterprise customers, or indirectly through integration with an application. In the indirect model, revenue would be realized from an end user perspective either as in-app purchases, or as part of a monthly app subscription fee. For platform devices, the most common model will most likely be integration with the application layer as this enables the required scale. Toward enterprises with user-managed devices, there will likely be both models where enterprises buy their IT applications integrated with differentiated connectivity (likely for off-the-shelf applications), or in a direct CSP sales model (likely for in-house applications). Full-stack integrators will also use both direct and indirect models and will likely be the user/device group with the highest share of direct CSP sales.

The indirect sales model of selling connectivity through the application allows applications with specific connectivity needs to include the cost of connectivity in the service fee to their customers. In the examples given above, this could be included as an app subscription fee, an in-app multi-player pass for the AR game, or as part of the monthly volume licensing fee that a business pays for the communications application. Other examples could be a telehealth provider including guaranteed connectivity in their application within the fee to ensure that patients will always have uninterrupted high-quality calls with their doctor, or a stock-trading app that includes deterministic connectivity services to ensure all orders are sent at exactly the right time, paid as part of the stock transaction fee.

Transforming the value chain for delivering differentiated connectivity
Integration of differentiated connectivity with applications would require developers to sign individual contracts with CSPs around the world. This could be the right approach for certain cases (such as large enterprises with user-managed devices, or with full-stack devices). However, to reach the mass market of developers and end users, a scalable, easy way to expose advanced network capabilities is needed. This is enabled by the introduction of an aggregator as an intermediary [9]. Figure 2 illustrates how this indirect sales model would be structured.

In the indirect model, the value chain changes for delivering applications and connectivity to end users. From a model where the CSPs and the application service providers independently deliver parts of the experience to the consumer, the future will see these players jointly delivering an application experience. The future delivery model will not replace the current one; they will coexist.

In the new differentiated world, revenue models for connectivity will change. The regular MBB subscriptions will remain, but they need to be complemented with new models that better meet the dynamic nature of differentiated connectivity. Therefore, pay-per-use models will dominate upstream in the value chain where the CSP charges the aggregator for the differentiated connectivity usage per consumption unit, such as time unit (hour) or data unit (megabyte). In turn, the aggregator packages connectivity from several CSPs into global APIs and provides these to the developer platforms at a margin. These platforms then package the global APIs into developer services and sell them to global app developers.

Key technical concepts are needed to realize differentiated connectivity. Most of these concepts either already exist in today’s networks and devices, or are on the way to being released in standards and products.

Figure 4 illustrates the high-level functional architecture of ecosystem entities involved in creating, setting up and managing differentiated connectivity service offerings. To enable differentiated handling of flows through the network, especially in RAN, traffic classification functionality that maps different applications and application flows for a specific UE to different network resources (network slices, Packet Data Unit (PDU) sessions, QoS flows and Radio Bearers) in both uplink (UL) and downlink (DL) is key. Traffic classification based on Network-Initiated Quality of Service (NI-QoS) has been standardized in 3GPP since Release 7 [12] and is used in commercial operations mainly for Voice Over LTE (VoLTE)/IP Multimedia Subsystem (IMS). It can be an excellent basis for network APIs, especially for full-stack systems as it is designed based on traffic classification that is dynamic and finely granular. Wider adoption for platform devices and user-managed devices is hindered primarily by initiatives to encrypt traffic end-to-end over mobile networks [13]. For such devices, URSP offers a standardized approach [14] to enable CSPs to influence the mapping of application traffic to network resources. Such policies provide the device QoS functionality with traffic steering rules (see examples [15,16]), or in other words, which PDU session a certain traffic type is to use. As separate PDU sessions may have different QoS treatments, these rules can then control the QoS treatment as well.

The process of creating and launching a new differentiated connectivity offering can be broken down into seven steps. The following sections detail these steps one by one, including the interactions with the corresponding processes run by the application providers and aggregators consuming the differentiated connectivity offerings.

1. Service offering development
The first step in creating a differentiated connectivity service offering is to define and detail it, build a marketing plan, and then create a business case considering all the use cases and use places that can benefit from the new connectivity service. As described in the previous chapter, the performance level first needs to be complemented with service targets, such as coverage, on top of the performance level objectives such as throughput and latency, as illustrated in Figure 3. The CSP should also understand the target customers for the product with an understanding of how the specific offering would appeal to them. Testing the offering with the intended target market is a good way to validate service value at this stage.

The marketing plan will contain guidance on how the product should be positioned, priced and promoted to reach the target customers. Considerations about the revenue model should also be part of this planning stage. The CSP also needs to consider how to best take the service to their intended customers, either in a direct or indirect sales model as described in earlier chapters. This will also serve as input for compiling the service business case, which should include a sales forecast and projections on revenue and costs of developing and launching the differentiated connectivity service offering.

To understand the business case, it is important to align the potential offering with the current network realities by assessing the network’s ability to deliver the service and the production cost of the service. As input for the next step (network design), the detailed offering needs to include forecasts on service uptake for network dimensioning, and business guidance on network resource allocation. This is needed to guide the network organization on the business value of fulfilling or exceeding the service performance objectives.

2. Network upgrade/design/provisioning
The next step is to carry out the necessary network design to support the required specifications and prepare the network for the introduction of performance levels.

As illustrated in Figure 5, the ability to provide the service depends both on CSP-deployed infrastructure in terms of spectrum, sites and hardware, but also on the software features implemented in the network, how the network is configured, and the user density and traffic load.

If a CSP wants to provide the new service in areas where the resources of the deployed infrastructure are insufficient, additional network resources need to be installed. This can involve, for example, upgrading to more capable radios, deployment of new spectrum and radios on existing sites as well as deployment on new sites.

Once the deployed infrastructure is sufficient, the right software features and configurations need to be established across the RAN, transport, Core and management domains. This includes specifying the end-to-end realization outlined in Figure 4 in detail, including software features and configurations to secure the desired performance considering both capacity and coverage for both DL and UL, network identifiers such as 5QI(s), Single-Network Slice Selection Assistance Information (S-NSSAIs), URSP rule templates, if applicable, and NI-QoS related packet filters such as for Low Latency, Low Loss and Scalable Throughput (L4S) [17] and/or IP 5 tuples. It also includes defining resource policies and QoS configurations throughout RAN, transport and Core, including offering this service and others in parallel to achieve the desired network behavior in case of congestion (where all KPI targets of all connections cannot be fulfilled). This will be familiar for CSPs already offering multiple connectivity services, such as MBB and Fixed Wireless Access (FWA).

The network design also needs to factor in BSS impacts, to ensure the new service can be purchased, activated, assured and billed. The design also needs to reckon with the network API exposure infrastructure impacts to make the offering available via APIs toward aggregators and application service providers. These system impacts will differ depending on whether the service is sold directly to an enterprise, which could be customer-tailored, or in an indirect sales channel, which leaves little room for unique solutions.

We foresee that an evolution toward intent-driven networks, with intents as a new management paradigm to guide and automate the network behavior, is essential to manage complexity and the network production cost, both in the provisioning and assurance of the new service [18]. Getting the end-to-end realization in place while meeting all the service targets and constraints and balancing between all the other services supported by the network can be done with traditional manual configuration methods as long as the number of services is moderate. In the mid term, once differentiated connectivity has taken off at scale with a multitude of service offerings, programmability and intent-driven automation will be key.

The network design typically needs to be iterated with the service offering responsible in order to strike a balance between cost of implementation and revenue potential. Once the design has been agreed, it can be implemented and provisioned in the network to support the new offering.

3. Service offering launch
Once implemented in the network, the service can be launched and promoted to the target customers according to the plan outlined in step 1. As part of the launch, the CSP also needs to launch any supporting services that help their customers use the service. This could be, for example, technical documentation, training material, and customer support channels. These need to be in place regardless of how the service is brought to the market.

The right agreements must also be in place for the launch. In the current business landscape, developer platforms assume no responsibility for the availability of underlying services in telecommunications networks. This is expected to change with the introduction of APIs for differentiated connectivity. CSPs should therefore provide the services with SLAs on service availability so that all tiers of the delivery chain can, in turn, issue their own SLAs on that underlying service availability. For application service provider customers, one SLA with a developer platform could then cover service availability in multiple networks.

4. Applications: Preparatory steps
The shift to deterministic connectivity with pre-defined performance levels means that applications can be designed to deliver a predictable service experience, enabling new application “modes” beyond those used for best-effort connectivity. Application service providers need to discover and realize the value of a differentiated connectivity offering sold via developer platforms or the CSPs directly.

Application service providers need to first plan what the service offering, which includes predictable connectivity, would look like. This will include designing user experience journeys by considering how to involve end users in the sign-up, activation and accounting of new connectivity offerings.

Applications also need to implement support for traffic classification, which for example could be based on 5G network slicing with URSP including device and network API integration, the ability to set up multiple PDU sessions, and the ability to send the right traffic on the right PDU session as illustrated in Figure 4.

5. ‘Subscriber’ sign-up step
Once networks and applications are prepared and the offerings have been launched, subscribers can sign up for the service. For direct business-to-everyone sales of premium connectivity, where the premium connectivity service is provided as an extension of an existing subscription or as an additional subscription, the activation results in user provisioning of the necessary subscription data and in case of URSP, device provisioning of updated URSP rules. For business-to-business sales, an enterprise IT administrator can define how the enterprise applications are mapped to the CSP-provided connectivity services in the device via a Mobile Device Management solution.

For sales via network APIs, the premium connectivity is not directly visible to the CSP’s subscribers, so there is no specific sign-up toward the CSP. Instead, subscribers, who are also users of the application service provider’s applications, will sign-up for a service from the application service provider that will utilize premium connectivity.

6. Session runtime: Initiation of premium connectivity
When using network APIs to initiate the premium connectivity service, as illustrated in Figure 4, a key part of the process is to ensure that the appropriate RAN and Core network configurations for the service that the application initiates can be identified. Additionally, it must be ensured that the traffic classification in both UE and the CSP’s network is set up consistently to map the traffic to the correct network resources down to the radio bearer. The application requests the premium connectivity to be activated either via a CSP network API, or an aggregated API via an aggregator. In case of an aggregated API, the aggregator resolves which CSP the device is served by and requests the service from that CSP. The request needs to uniquely identify which level(s) the application intends to use, as well as any applicable device information, to enable the CSP to set up the traffic classification correctly and identify the corresponding S-NSSAI, data network name (DNN) and 5QI to use in communication between RAN, Core and UE. In the CSP’s network, the correct subscriber data is provisioned in the Core network to entitle the use of the service and in case of URSP triggers, the appropriate URSP rules are provisioned to the device.

Once this is done, the application can establish the premium connectivity service via the device QoS functionality. To enable this, it is key that the service that the application requests via the device QoS functionality can be derived deterministically from the service that the application requests via the network API. In case of URSP, the device QoS functionality then ensures a PDU session is established with the correct S-NSSAI and DNN as provisioned in the URSP rules, while the Core network, in turn, can provide the S-NSSAI and 5QI to RAN to close the loop.

7. Service assurance
The final key step in launching a differentiated connectivity offering is the service assurance [19]. As CSP, it is essential to ensure that the target KPIs of all connectivity services are fulfilled and to take remedial action if performance falls below acceptable levels.

Introduction of multiple differentiated connectivity services will make operations of a mobile network in the traditional way increasingly more complex, which needs to be addressed by a higher degree of automation, making the mobile networks more autonomous. While multiple levels of closed loop automation constitute the heart of an automation solution, these closed loops need to be able to translate the business objectives defined in step 1 into the correct automated actions. One way to realize this automation is through an intent-driven automation architecture, where the network resource allocation policy will serve as guidance to automation in the form of intents.

With intents as an input, Intent Management Functions (IMFs) will be responsible for the service assurance with the objective to fulfill the intents in an optimal way given the deployed resources through closed loop actions. IMFs will be deployed at different levels, working with different scopes and to different time scales. An IMF in the radio node will only be responsible for the resources within that radio node, but will be able to take actions related to things such as beamforming, scheduling and handover at the ms level. An IMF in the RAN management level will, on the other hand, orchestrate multiple radio nodes over an area and will therefore have the overall responsibility to assure the RAN service over a larger RAN area. Finally, an end-to-end IMF will take care of the highest level intent, ensuring that all parts of the network (RAN, transport network, Core network) contribute to the overall intents, assuring the end-to-end network connectivity service performance.

CSPs also need to provide service support by having an incident management function. Depending on the go-to-market model, they need to prepare for providing tier-1, tier-2, and/or tier-3 support. Typical incident management functions must include incident logging and verification, incident categorization and prioritization and incident resolution.

The telecom industry is in urgent need of a transformation to realize the true value of wireless connectivity. This is what will turn connectivity into a platform providing deterministic performance that supports application service providers in making further innovations, in combination with other innovation enablers such as AI and cloud-based computing.

The performance levels introduced in this whitepaper are intended to make it easier for application service providers and developers to leverage the 5G standalone network capabilities and drive adoption of differentiated connectivity services. For that to happen, an industry aligned on the specifications needed to expose the wireless connection characteristics is required. This will foster services innovation and enable CSPs to offer such services more widely and with greater variety of differentiation. It will also be pivotal for the telco industry to move into performance-based business models for connectivity.

There are already clear indications in the industry that differentiated connectivity is needed, and many CSPs around the world are already trying to explore its potential. This paper introduces the steps a CSP should take to create differentiated connectivity services.

To trigger and accelerate the industry transformation, key players in the industry need to start acting now, including jointly testing value creation through the new performance levels and the new business models, and aligning on the implementation through APIs and standardization to achieve global scale.