Abstract

Connected vehicles depend on continuous, predictable network performance to support real-time functions such as remote driving, navigation updates, software downloads, and sensor data exchange. In practice, however, vehicles move through environments where network quality and capability change from private factory networks to public mobile broadband, and from uncongested cellular coverage areas to crowded ones. This proof of concept (PoC), developed by Ericsson, KDDI, and Toyota under the Automotive Edge Computing Consortium (AECC), examines whether applications can anticipate these changes and act on them before service quality degrades.

The PoC demonstrates two related capabilities. The first uses status of network density to adjust quality of service (QoS) dynamically when congestion is likely, rather than after it occurs. Dynamic QoS not only maintains the necessary level of service when needed without manual intervention, but allows bandwidth to be shared and enables more efficient utilization of bandwidth when demand is lower (or required for less important applications, like infotainment).

The second capability uses predictive signal information to switch between network providers using an embedded subscriber identity module (eSIM) that supports multi-carrier operation. This allows for seamless transitions and uninterrupted service at the right level for the type of vehicle software in use. Both capabilities rely on standardized application programming interfaces (APIs) from the CAMARA project and on the GSMA SGP.32 specification for eSIM profile management.

Together, these scenarios show how predictive, application-driven, and standards-based connectivity management can improve reliability for connected vehicles without requiring custom integrations between applications and mobile networks. The results suggest a practical and efficient path toward more adaptive connectivity in manufacturing, logistics, and other vehicle-centric operations — even when vehicles are placed in a variety of environments.

Figure 1: Overview of PoC architecture.

Business Strategy

Automotive connectivity now supports core operational functions, from factory logistics and quality inspection to remote operation and post-sale services. As vehicles become increasingly software-defined, connectivity interruptions create direct operational risk, added cost, and reduced efficiency.

Manufacturers have typically relied on a single carrier, but dependence on single carrier raises the risk that outages or loss of coverage will violate vehicle application requirements. Multiple SIMs in parallel can improve reliability by accessing several carriers, but they increase cost and are unnecessary when a single carrier is sufficient.

In practice, vehicles move through a mix of private 5G networks, public mobile broadband, and coverage transition zones. No single network is optimal everywhere. This PoC reframes that complexity as an advantage by treating connectivity as something applications can adjust dynamically, rather than a fixed configuration. The approach aligns with AECC’s architecture by using access network selection and on-demand provisioning to respond to changing conditions in real time.

The business impact is threefold:

1. Adaptive communication control improves service continuity and reduces manual intervention in controlled environments such as factories and parking facilities.
2. Proactive adjustments help prevent service degradation in safety-critical and time-sensitive use cases.
3. The use of open standards reduces integration effort while supporting interoperability across operators and vendors.

Together, these benefits compound at scale, creating measurable cost savings and lowering operational risk as deployments expand.

Proof of Concept Objective

The objective of the PoC was to validate whether standardized network insight and control mechanisms could support proactive connectivity decisions in real-world vehicle scenarios.

The first use case focuses on validating application-driven quality of service (QoS) adjustment using population density inputs. Building on prior CAMARA Quality on Demand (QoD) work, the PoC verifies that density data — refreshed at short intervals and derived from active cellular device counts — can be used as a reliable trigger for preemptive QoS changes.

The second use case focuses on validating automated network switching using a GSMA SGP.32-compliant embedded subscriber identity module (eSIM). Rather than reacting to connection failures, the PoC verifies that predictive signal quality trends can be used to trigger timely eSIM profile changes between networks.

In both cases, the goal was functional verification rather than performance benchmarking. The PoC aimed to confirm that the control loop — from data collection, to application decision, to network action — works as defined in the standards and AECC architecture.

Proof of Concept Scenario

The PoC scenario is based on vehicle factory operation. During production and staging, the vehicle is moved outside for transportation, etc.

Traditionally these movements were carried out by human drivers; replacing them with remote driving is expected to reduce the need for parking space and labor. However, remote driving requires stable network connectivity, and vehicles must continuously maintain the optimal network connection.

In this PoC scenario, local 5G is best for areas near and inside the factory, while public cellular is preferable for outdoor yard areas because certain networks may become congested due to personnel movement inside the factory. In such cases, SIM swaps or other configuration changes are required to switch networks, but traditionally these switches have required manual intervention on the vehicle.

Figure 2: Environment setup.

Figure 3: Environment architecture.

In the scenario, vehicles operate on a private local 5G network while indoors and transition to a public mobile broadband network when moved outdoors. The reverse transition also occurs. During these movements, network conditions vary due to coverage boundaries and user density. Both application-driven mechanisms tested in this scenario are designed to act before service degradation becomes visible at the application level.

Scenario Details for Use Case 1: Quality on Demand with Population Density Forecasting

In summary, the application monitors predicted population density (an estimate of how many users are present in a given cellular coverage area) in the serving cell. As the density increases, available radio resources per user decrease, increasing the risk of congestion. When density crosses predefined thresholds, the application requests a higher-priority QoS profile through the QoD API.

Figure 4: How use case 1 builds on the 2024 AECC PoC using CAMARA’s QoD API, and adds information from the population density API to test the stability and service quality of the IoT device and determine if the QoD threshold has been reached.

Taken step by step, the sequence of events is as follows:

1. IoT device establishes a baseline data session. The Internet of Things (IoT) device — mounted in or representing the vehicle — establishes a data session over the serving cellular network using a default quality of service (QoS), defined as the priority, latency, packet loss, and throughput characteristics assigned to a traffic flow.
2. Application server periodically requests contextual network data. An application server, acting as the decision-making entity, polls CAMARA Population Density Data API at a fixed interval (every five seconds in the PoC). Polling refers to the repeated, time-based request of data rather than event-based notifications.
3. Population Density Data API provides forecasted user density. The CAMARA Population Density Data API returns population density estimates, defined as the number of active or expected users per geographic grid cell within the radio coverage area of a base station.
4. Application maps density data to radio capacity constraints. The application correlates population density values with known radio access network capacity limits. This mapping determines how many concurrent users can be supported before congestion degrades service quality.
5. Threshold comparison logic is executed. The application evaluates population density against predefined thresholds (low, medium, high). These thresholds represent expected congestion risk levels based on calculated antenna throughput and traffic type.
6. Congestion risk is detected before service degradation occurs. When density reaches or approaches the HIGH threshold, the application determines that the risk of congestion is imminent, even if throughput degradation has not yet been observed.
7. Quality on Demand API is invoked. The application calls the CAMARA Quality on Demand (QoD) API, which allows an application to request a temporary modification to the QoS profile for a specific device, session, and duration
8. QoS profile is upgraded in the access network. The network enforces a higher-priority QoS profile (for example, changing from 5G QoS Identifier (5QI) 9 to 5QI 6). The 5QI is a standardized identifier that defines packet handling characteristics in 5G networks.
9. Traffic stability is maintained under congestion. With the upgraded QoS applied, application traffic (for example, video streaming or remote operation data) remains stable even as background traffic increases and congestion is artificially introduced.
10. QoD session expires and QoS reverts automatically. When the QoD session duration ends, the network automatically reverts the device’s QoS profile to the default state without further application intervention.

Figure 5: How the location change triggered the QoS change in use case 1. Note: iPerf is an open source tool used to generate traffic to test and measure the maximum achievable bandwidth on the network.

Scenario Details for Use Case 2: eSIM Profile Switching with Predictive Connectivity

Briefly, the application monitors predictive connectivity data, which estimates future signal quality along the vehicle’s path based on radio measurements. When the predicted signal quality of the current network falls below a defined level, the application triggers an eSIM profile switch. The eSIM uses the GSMA SGP.32 standard, which supports secure remote provisioning and switching between multiple operator profiles.

Figure 6: How the system used predictive signal strength data to determine a switch point.

Taken step by step, the sequence of events for this use case is as follows:

1. IoT device operates with an active eSIM profile. The vehicle or IoT device connects to the network using an embedded subscriber identity module (eSIM), defined as a remote manageable SIM that can store and switch between multiple operator profiles remotely.
2. Device initially connects to the preferred network. In the PoC, the device begins operation on a local private 5G network where signal strength and service quality are sufficient.
3. Application server polls predictive connectivity data. The application server periodically queries the CAMARA Predictive Connectivity Data API. This API provides forward-looking assessments of network quality along a defined route or geographic area.
4. Radio signal strength is mapped spatially. Signal strength measurements are aggregated and mapped into grid-based coverage data for both the private 5G network and the public mobile broadband network.
5.  Connectivity state classification is returned. The Predictive Connectivity Data API classifies expected connectivity using discrete states:
   1. Good connectivity (GC): service level requirements are expected to be met.
   2. Marginal connectivity (MC): service levels may not be met.
6. Application evaluates predicted connectivity transition. As the vehicle approaches an area where the private network signal weakens, the application detects a predicted transition from GC to MC for the current network.
7. Network switch decision point is reached. When the predicted connectivity for the active network falls below the acceptable threshold, the application determines that a network switch is required to preserve service quality before the network degrades.
8. SGP.32-based eSIM profile switch is triggered. The application initiates an eSIM profile switch using the GSMA SGP.32 standard, which defines secure procedures for remote eSIM profile management in IoT and automotive environments
9. Device transitions to the alternate network. The eSIM activates the alternate operator profile (for example, switching from local private 5G to public LTE or 5G mobile broadband). The transition occurs without requiring a device reboot.
10. Application traffic continues with minimal disruption. Because the switch is triggered proactively, application-layer services experience minimal interruption during the network transition.
11. Reverse switching occurs when conditions improve. When predictive connectivity data indicates that the vehicle is returning to an area with good private network coverage, the application triggers a reverse eSIM profile switch back to the local 5G network.

Figure 7: How the location change triggered the eSIM profile switch in use case 2.

Proof of Concept Results

Results of Use Case 1: Achievement of Predictive QoS Control

This use case confirmed that population density forecasts can be used as a reliable trigger for proactive quality of service (QoS) adjustments. By acting on predicted congestion rather than observed degradation, the application successfully maintained service stability during periods of simulated network load.

When density thresholds were reached, the application invoked the CAMARA Quality on Demand API to apply a higher-priority QoS profile. The network enforced the change as expected, and service quality remained stable throughout the congestion period. Once the on-demand QoS session ended, the network automatically reverted to the default profile.

These results matter because they validate a shift from reactive traffic management to predictive service assurance. Applications can preserve performance using standardized APIs, without continuous monitoring of throughput or packet loss and without permanent overprovisioning of network resources.

Figure 8: Screen grabs from the software showing that when the network wasn’t predicted to be congested, the eSIM was in a normal QoS state (5QI = 9). When network congestion was predicted, the eSIM switches the QoS state to a higher level (5QI=6).

Results of Use Case 2: Successful Predictive Network Switching

This use case demonstrated that predictive connectivity insights can support seamless, automated switching between networks using an eSIM. As the vehicle moved across coverage boundaries, predicted signal quality was sufficient to trigger network changes before service degradation occurred.

When the application detected that the active network would no longer meet service requirements, it initiated an eSIM profile switch using the GSMA SGP.32 standard. The transition between private and public networks completed smoothly, with minimal impact on application behavior. When favorable conditions returned, the device switched back automatically.

These results show that multi-carrier connectivity can be managed proactively and at scale, without manual configuration or application disruption. Predictive switching reduces service interruptions at coverage edges and enables vehicles to use the most appropriate network for each operating context.

Figure 9: Screen grabs from the software showing the initial use of a long term evolution (LTE) network in an area with poor quality local 5G. When the vehicle moved into an area with good quality local 5G, the eSIM switched to use local 5G.

Next Steps

This PoC lays the groundwork for predictive, application-driven connectivity management across the vehicle lifecycle. Next, the engineering team will consider applying these capabilities to other scenarios, such as location-based services, where dedicated connectivity is required in specific locations.

1. For example, a vehicle using a GSMA SGP.32-compliant eSIM could automatically switch to a local private 5G network at a maintenance center, enabling fast diagnostics, secure data exchange, and even preventive maintenance during a single visit.
2. Beyond service visits, vehicles could run daily self-checks and, if issues arise, book maintenance automatically. Connectivity along the route could be optimized in real time to ensure seamless data transfer.

These scenarios show how adaptive communication via Telco API and smart eSIM-based network selection can make vehicle operations more autonomous and efficient.