Managing quality of service in a telematics control unit using machine learning

Abstract

To provide a system and method for quality of service (QoS) management of a telematics control unit (TCU) of a vehicle.SOLUTION: The QoS system 600 includes a classification machine learning (ML) model adapted to receive the TCU behavior parameters and the environment parameters and output a usage scenario and a QoS level according to the TCU behavior parameters and the environment parameters, and a reinforcement learning agent adapted to update a control parameter policy according to the TCU usage scenario and the QoS level, to adapt to passenger preferences and behaviors and environmental and traffic conditions, and to provide a context-aware in-vehicle user experience using artificial intelligence and machine learning.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] This specification relates generally to managing quality of service for connections of automotive telematics control units using machine learning. [Background technology]

[0002] In-cabin connectivity in automobiles enables a variety of devices and services to enhance the user experience of vehicle occupants. Providing high-quality connectivity in complex dynamic environments involves multiple factors, including the number and type of devices and services, occupant preferences and behavior, environmental and traffic conditions, and available connection resources. For example, connection quality may vary depending on the vehicle's location, speed, and direction, network coverage and congestion, and interference from other sources. Furthermore, connectivity demands may differ for different use cases, such as entertainment, navigation, communications, and safety, making providing high-quality connectivity context-dependent.

[0003] Therefore, disclosed herein are embodiments that address at least some of the above problems with a system including a classification machine learning model adapted to receive TCU behavior parameters and environmental parameters and output a TCU usage scenario and a quality of service (QoS) level according to the TCU behavior parameters and environmental parameters. In some examples, the system further includes a reinforcement learning agent adapted to update a control parameter policy according to the TCU usage scenario and the QoS level. In this manner, the QoS management system disclosed herein can adapt to occupant preferences and behavior, as well as environmental and traffic conditions, and provide a context-aware in-vehicle user experience using artificial intelligence and machine learning. Context awareness can improve the quality of connected services compared to other systems or connection methods. Furthermore, bandwidth consumption can be reduced by the QoS management system optimizing bandwidth allocation and utilization of in-vehicle devices and services to avoid unnecessary or excessive consumption. For example, the QoS management system can reduce bandwidth consumption for low-priority or background services, such as software updates or data synchronization, when bandwidth is scarce or expensive. Furthermore, the QoS management system may ensure connection quality for safety-related devices and services, such as collision avoidance, emergency calls, or remote diagnostics, to prevent or mitigate potential accidents or malfunctions. For example, the QoS management system may prioritize connections for such devices and services and protect data transmissions using encryption and authentication techniques.

[0004] It should be understood that the foregoing summary is provided to introduce a selection of concepts in a simplified form that are further described in the detailed description. It is not intended to identify key or essential features of the claimed subject matter, the scope of which is defined uniquely by the claims that follow the detailed description. Moreover, the claimed subject matter is not limited to implementations that solve the disadvantages discussed above or in any portion of this disclosure. The present invention provides, for example, the following. (Item 1) A quality of service (QoS) management system for a telematics control unit (TCU) of a vehicle, comprising: the QoS management system including a classification machine learning model adapted to receive TCU behavior parameters and environmental parameters, and to output a usage scenario and a QoS level according to the TCU behavior parameters and the environmental parameters. (Item 2) The QoS management system described in the preceding item further comprises a reinforcement learning agent adapted to update a control parameter policy according to the usage scenario and the QoS level. (Item 3) Item 10. The QoS management system of any one of the preceding items, wherein the control parameter policy is a set of rules for adjusting control parameters according to the usage scenario and the QoS level. (Item 4) QoS management system according to any one of the preceding items, wherein the environmental parameters include at least some of the following: location, weather, time, and signal coverage map. (Item 5) QoS management system according to any one of the preceding items, wherein the usage scenario describes the vehicle's position and trajectory, surroundings, and network traffic. (Item 6) The QoS management system according to any one of the preceding items, wherein the TCU behavior parameters include signal quality and latency. (Item 7) The QoS management system according to any one of the preceding items, wherein the TCU behavior parameters and the environmental parameters are received from sensors in the vehicle and other vehicles. (Item 8) 1. A method for quality of service (QoS) management of a vehicle, comprising: receiving telematics control unit (TCU) behavior parameters and environmental parameters; determining a usage scenario and a Quality of Service (QoS) level from the TCU behavior parameters and the environmental parameters using a usage scenario classifier, a Quality of Service (QoS) classifier, and expert rules; and modifying the control parameters according to the control parameter policy. (Item 9) Item 11. The method of claim 1, wherein the control parameter policy is a set of static predefined rules for modifying the control parameters according to the usage scenario and the QoS level. (Item 10) 10. The method of claim 1, further comprising providing the usage scenario and the QoS level to a reinforcement learning agent. (Item 11) 10. The method of claim 1, further comprising using the output of the reinforcement learning agent to modify a control parameter policy. (Item 12) 10. The method of claim 1, wherein the control parameter policy is a dynamic rule set for varying the control parameters based on the usage scenario, and the control parameter policy is converged by the reinforcement learning agent. (Item 13) 10. The method of claim 1, wherein the usage scenario classifier and the QoS classifier are classification-based machine learning models that classify the usage scenarios and the QoS levels. (Item 14) The method according to any one of the preceding items, wherein the control parameters include a frequency band, a radio access technology, and an APN. (Item 15) 3. The method according to any one of the preceding items, wherein the control parameters include frequency, channel, and width. (Item 16) The method of any one of the preceding items, wherein receiving the TCU behavior parameters and the environmental parameters includes sensors of the vehicle and sensors of other vehicles, and includes various sensors that monitor the TCU behavior parameters and the environmental parameters. (Item 17) 1. A method for quality of service (QoS) management of a telematics unit, comprising: Establishing a data connection; and Determining whether Wi-Fi offload is supported; and If Wi-Fi offloading is supported, performing Wi-Fi offloading and monitoring the data connection; If Wi-Fi offload is not supported, determining whether network slicing is supported; and If network slicing is supported, performing network slicing and monitoring the data connection; and adjusting an access point name (APN) if network slicing is not supported. (Item 18) Adjusting the APN measuring signal quality of a serving cellular tower and signal quality of adjacent cellular towers; determining whether the signal quality of the serving cellular tower exceeds a threshold; If the signal quality of the serving cellular tower does not exceed the threshold, determining whether the signal quality of the neighboring cellular tower exceeds the threshold; changing frequency bands when the signal quality of the neighboring cellular tower exceeds the threshold; and changing radio access technology (RAT) if the signal quality of the neighboring cellular tower is below the threshold. (Item 19) Adjusting the APN determining whether the latency exceeds a latency threshold and whether the cost exceeds a cost threshold; 4. The method of claim 1, further comprising: modifying a traffic template if the latency exceeds the latency threshold or if the cost exceeds the cost threshold. (Item 20) 7. The method of claim 1, wherein determining whether Wi-Fi offload is supported includes comparing the QoS level to a QoS threshold for one or more priorities and scanning for available Wi-Fi networks. [Brief explanation of the drawings]

[0005] [Figure 1] 1 shows a schematic diagram depicting an exemplary operating environment for implementing a quality of service (QoS) management system and method in accordance with one or more embodiments of the present disclosure.

[0006] [Figure 2] 1 illustrates a schematic diagram of measuring and connecting parameters used in a QoS management system, in accordance with one or more embodiments of the present disclosure.

[0007] [Figure 3] 1 illustrates a flowchart of a QoS management method in accordance with one or more embodiments of the present disclosure.

[0008] [Figure 4] 1 illustrates a flowchart of a QoS management method in accordance with one or more embodiments of the present disclosure.

[0009] [Figure 5] 1 illustrates a schematic diagram of a QoS management system in accordance with one or more embodiments of the present disclosure.

[0010] [Figure 6] 1 illustrates a schematic diagram of a QoS management system in accordance with one or more embodiments of the present disclosure.

[0011] [Figure 7] 1 illustrates a schematic diagram of an example software architecture for a QoS management system, in accordance with one or more embodiments of the present disclosure.

[0012] [Figure 8] 1 illustrates a flowchart of a method for implementing a QoS management system in accordance with one or more embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0013] The following description relates to systems and methods for managing quality of service (QoS) of a vehicle's telematics control unit (TCU) using machine learning (ML). FIG. 1 illustrates an example operating environment for a vehicle connectivity system including one or more telematics-equipped vehicles using a QoS management system in accordance with one or more embodiments of the present disclosure. The QoS management system may manage QoS based on environmental and telematics unit-related parameters to improve the quality of cellular and Wi-Fi network connections. The QoS management system may use measurement parameters to determine corresponding adjustments to control parameters. Examples of measurement and control parameters are presented in the organizational diagram of FIG. 2. The QoS management system may utilize various methods to improve connection quality, including Wi-Fi or edge network offloading, network slicing, and access point name (APN) modification. FIGS. 3 and 4 illustrate flowcharts of methods for Wi-Fi or edge network offloading, network slicing, and APN modification. FIGS. 5 and 6 illustrate example schematic diagrams of a QoS management system in accordance with one or more embodiments of the present disclosure. 7 shows an example schematic diagram of a software system for implementing a QoS management system according to one or more embodiments of the present disclosure. FIG. 8 shows a flowchart of an example method for implementing a QoS management system.

[0014] It should be understood that the specific assemblies and systems illustrated in the accompanying drawings, and described in the following specification, are exemplary embodiments of the inventive concepts defined herein. For purposes of explanation, the drawings are described collectively. Accordingly, like elements may generally be referred to herein by like reference numerals and may not be reintroduced.

[0015] 1, an exemplary operating environment 100 is shown comprising a vehicle-to-vehicle communication system 10 including one or more telematics-equipped vehicles 12. The following paragraphs provide a brief overview of one possible configuration for providing wireless communication between each vehicle 12 and between the vehicle 12 and a cellular tower 16. It should be understood that other systems not shown here may include the antenna assemblies disclosed herein.

[0016] In the illustrated embodiment, the vehicle 12 is depicted as a passenger car, however, it should be understood that any other vehicle may also be used, including a motorcycle, truck, sport utility vehicle (SUV), recreational vehicle (RV), boat, aircraft, etc.

[0017] The telematics unit 30 may be an OEM or aftermarket device that enables the vehicle 12 to receive and / or transmit wireless signals corresponding to voice, text, and / or other data. The telematics unit 30 may also be referred to herein as a telematics control unit (TCU). Accordingly, the telematics unit 30 may transmit and / or receive wireless signals (e.g., electromagnetic waves). Accordingly, the telematics unit 30 may also be referred to as a transceiver 30 because it may be capable of both transmitting and receiving wireless signals. The wireless signals generated by the telematics unit 30 of the vehicle 12 may be transmitted to one or more of the vehicle 12 and the cellular tower 16 and may be received by one or more of the vehicle 12 and the cellular tower 16. Accordingly, each of the vehicles 12 may wirelessly communicate with each other to transmit and / or receive information between the vehicles via the telematics unit 30. Additionally, each of the vehicles 12 may wirelessly communicate with the cellular tower 16 to transmit and / or receive information between the vehicles.

[0018] Thus, each of the vehicles 12 may communicate with one or more of the cellular towers 16, other telematics-equipped vehicles 12, or any other entity or device capable of transmitting and / or receiving wireless signals. The telematics units 30 may enable the vehicles to provide a number of different services, including those related to messaging, navigation, telephone calls, emergency assistance, diagnostics, infotainment, etc. Wireless networking between the vehicles 12 and other network devices may also be implemented using the telematics units 30. To this end, the telematics units 30 may be configured to communicate wirelessly according to one or more wireless protocols.

[0019] The telematics unit 30 may be used to provide a variety of vehicle services involving wireless communication with the vehicle 12. Such services may include remote control of certain vehicle functions, turn-by-turn route guidance and other navigation-related services, airbag deployment notification and other emergency or roadside assistance-related services provided in association with one or more crash sensor interface modules, such as a body control module (not shown), diagnostic reports using one or more diagnostic modules, and infotainment-related services in which music, web pages, movies, television programs, video games, and / or other information is downloaded by an infotainment module (not shown) and stored for current or later playback. Additionally, each telematics unit 30 in the vehicle 12 may enable the sending and / or receiving of SMS messages and phone calls via the cellular network provided by the cellular tower 16. Accordingly, the telematics unit 30 may include a cellular chipset for voice communications, such as hands-free calling, by utilizing cellular communications. The above services are by no means an exhaustive list of all the capabilities of the telematics unit 30, but merely a list of some of the services an exemplary telematics unit may provide. Furthermore, while several possibilities are listed, it should be understood that at least some of the above-described modules may be implemented in the form of software instructions stored inside or outside the telematics unit 30, may be hardware components located inside or outside the telematics unit 30, or may be integrated with and / or shared by other systems located throughout the vehicle 12.

[0020] A vehicle's connection quality (e.g., signal quality, latency, etc.) may depend on various factors. For example, connection quality may be affected by parameters including the vehicle's 12 route 108 and the surroundings 102, including natural environments such as buildings and weather 110. Vehicle conditions, such as the number of users, the type of service as described above, and the vehicle's 12 speed and location, may also affect the vehicle's connection quality. Additionally, the number, location, and traffic conditions of cellular towers 16 may also affect connection quality.

[0021] Quality of Service (QoS) management may improve the quality of a vehicle's connectivity by controlling network traffic and optimizing and prioritizing signals. The telematics unit 30 may utilize one or more machine learning models 104 to manage the QoS of vehicle connectivity. For example, a first machine learning model may classify usage scenarios according to vehicle conditions and environmental conditions. A second machine learning model may classify QoS levels according to signal quality, latency, etc. In this manner, QoS may be optimized for various conditions. In some examples, a third machine learning model may adjust rules by which operation is adjusted to increase QoS levels. In this manner, rules may evolve during operation to further increase QoS levels. The machine learning models 104 may be implemented directly in the telematics unit 30, other in-vehicle infotainment (IVI)-related devices of the vehicle 12, or remotely in a cloud server 106.

[0022] The machine learning algorithms used by the telematics unit 30 may calculate measurement and control parameters related to the wireless connection. Measurement parameters are parameters that can be measured or managed, such as parameters related to network identification, device identification, signal frequency and power, bandwidth, signal quality, signal travel time, etc. Control parameters are parameters that can be adjusted (e.g., by an end user). For example, the control parameters can be manipulated according to the classification of the ML model of the measurement parameters. The measurement and control parameters can be different for Wi-Fi and cellular connections. The measurement and control parameters can be parameters of a modem in a network access device (NAD), such as the telematics unit 30 of FIG. 1. The measurement and control parameters can be provided by the NAD to application software (e.g., the software architecture 700 of FIG. 7) as a reference interface or application programming interface (API).

[0023] 2 shows an organization of TCU behavior parameters 200, partitioned into cellular parameters 202 related to cellular connectivity (e.g., between vehicle 12 and cellular tower 16 of FIG. 1 ) and Wi-Fi parameters 214 related to Wi-Fi network or edge network connectivity, among other subgroups. FIG. 2 further shows environmental parameters 230, including location 232, weather 234, time 236, and signal coverage map 238. Environmental parameters 230 may be detected by sensors, timers, etc. Such sensors may be on the vehicle, on adjacent vehicles communicating with the vehicle, or at other locations that can provide information to the vehicle's TCU. Thus, environmental parameters 230 may also be considered measured parameters.

[0024] The cellular parameters 202 may include measurement parameters 204 and control parameters 212. The measurement parameters 204 may include signal quality 206, network latency 208, and data connection cost 210. The signal quality 206 may depend on the public land mobile network (PLMN), calling identity (CID), radio technology (e.g., generation of technology), absolute radio frequency channel number (ARFCN), reference signal received power (RSRP), reference signal received quality (RSRQ), signal-to-interference-and-noise ratio (SNR), channel quality indicator (CQI), timing advance, call control (CC), and physical cell identity (PCI). The network latency 208 may be determined based on byte rates for receive (Rx) and transmit (Tx) signals and round trip time (RRT) of Internet Protocol (IP) packages. The data connection cost 210 may depend on traffic template and roaming. The control parameters 212 may include a frequency band, a PLMN, a radio technology, and an access point name (APN).

[0025] The Wi-Fi parameters 214 may include measurement parameters 216 and control parameters 224. The measurement parameters 216 may include signal quality 218, network latency 220, and data connection cost 222. The signal quality 218 may depend on frequency, SNR, channel, width, standard, maximum bit rate, modulation coding scheme (MCS), retry rate, and security. The network latency 220 may be determined based on Rx and Tx byte rates and RTT of IP packages. The data connection cost 222 may depend on whether the connection is metered or non-metered. The control parameters 224 may include frequency, channel, width, standard, MCS, security, and whether the connection is metered or non-metered.

[0026] The environmental parameters 230 include location 232, weather 234, time 236, and signal coverage map 238. Location 232 may include traffic density (e.g., vehicles in an area), vehicle movement (e.g., stopped, moving, speed, trajectory, etc.), geographic location (e.g., urban, suburban, or rural), and surroundings (e.g., commercial area, building, etc.). Weather 234 may monitor whether it is raining, sunny, cloudy, snowing, etc. Time 236 may include categorizing time as daytime or nighttime and / or high-traffic versus low-traffic times. Signal coverage map 238 may indicate the average up / down speed and latency of network signals in a given area.

[0027] Environmental parameters 230 can affect measured parameters 204 and measured parameters 216. Thus, a machine learning model (e.g., ML model 502 in FIG. 5 ) that can classify environmental conditions and associate usage scenarios (e.g., sets of environmental and TCU behavior parameters) with QoS may be able to manage QoS more effectively than a system that does not consider environmental parameters, thereby improving the in-vehicle user experience. Additional parameters beyond those shown in FIG. 2 and listed above may also be evaluated and adjusted in the QoS management system without departing from the scope of this disclosure.

[0028] QoS management systems and methods according to one or more embodiments of the present disclosure using the above parameters can be implemented for a variety of applications, and in at least some examples, the applications can each be classified into one of four categories: (1) autonomous driving, (2) advanced driver assistance systems (ADAS) and safety, (3) infotainment and navigation, and (4) convenience. For example, telematics features related to autonomous driving may include forward collision warning (FCW), blind spot warning (BSW), vulnerable road users (VRU), intersection maneuver assistance (IMA), etc. For example, telematics features related to ADAS and safety may include eCall, traffic light information (TLI), situational awareness, cluster information, driver monitoring systems (DMS), occupant monitoring systems (OMS), etc. For example, telematics features related to infotainment and navigation may include high-definition (HD) maps, head-up displays (HUD), in-vehicle infotainment (IVI), passenger display information, rear-seat entertainment (RSE) streaming, games, etc. For example, convenience-related telematics features may include access points, heating, ventilation, and air conditioning (HVAC) controls, vehicle settings, and the like.

[0029] Priorities may be assigned according to the category to which the telematics function belongs, such as the four categories mentioned above. Corresponding QoS thresholds may be assigned to each priority. For example, autonomous driving may be a higher priority than ADAS and safety. ADAS and safety may be a higher priority than infotainment and navigation. Infotainment and navigation may be a higher priority than convenience. Thus, the QoS threshold for autonomous driving may be higher than the QoS thresholds for ADAS and safety, infotainment and navigation, and convenience. The QoS threshold for ADAS safety may be higher than the QoS thresholds for infotainment and navigation and convenience. The QoS threshold for infotainment and navigation may be higher than the QoS threshold for convenience. In this way, individual QoS thresholds may be assigned for each category according to the category priority. Thus, signals may be prioritized according to priority to conserve bandwidth and improve QoS.

[0030] To ensure that the QoS does not exceed a requested level, QoS management may be required. For example, QoS management may include performing one or more of Wi-Fi or edge network offloading, network slicing, and APN adjustment.

[0031] Wi-Fi or edge network offloading, also referred to more simply herein as offloading, may generally be more cost-effective than network slicing and APN adjustments. For example, Wi-Fi networks may offer unmetered connections, as opposed to cellular connections. Thus, in at least some examples, offloading may be checked for feasibility before other QoS management methods. Offloading may include reselecting from a non-Wi-Fi network to a Wi-Fi network, e.g., switching between a Third Generation Partnership Project (3GPP®) network and a non-3GPP® network. Non-3GPP® networks may include untrusted non-3GPP® networks and trusted non-3GPP® networks. Offloading may also be implemented in examples related to technologies of other generations besides third generation. Benefits of Wi-Fi offloading to user equipment (UE) users may include high-bandwidth and low-cost data connectivity within the device. The benefits of Wi-Fi offload for network operators may include reducing and balancing the load on 3GPP networks and addressing indoor coverage challenges with higher frequency bands.

[0032] Offloading may be triggered by the UE user, at least in some examples. For example, a user device may periodically perform wireless local area network (WLAN) scans. If a known or open Wi-Fi network is found during the WLAN scan, the offload procedure may be initiated. The offload procedure may include prompting the user to select a network. In some examples, an interworking wireless local area network (IWLAN) may achieve authentication without manual user interaction, such as entering a username and password, as is common in many Wi-Fi networks. For example, the authentication protocol may be based on the use of a SIM card that may already be provisioned in a 3GPP® handset or other device. Mobility management may be used in the offload procedure to provide seamless mobility between a cellular radio access network (RAN) and a Wi-Fi RAN, and from an inter-operator Wi-Fi RAN to the user. The mobility procedure may be based on an IP-level mobility management protocol implemented to enable handovers, for example, from 3GPP® access to a WLAN access or vice versa.

[0033] Wi-Fi offloading can be performed in several different ways. In some examples, Wi-Fi and cellular networks may be combined. Some devices, such as personal radios, may select and connect to a Wi-Fi network based on explicit user preferences or pre-configured preferences already stored in the UE. Additionally or alternatively, the device may be configured to automatically switch to a known Wi-Fi network upon detection by routing IP traffic through a Wi-Fi IP connection. Such automatic connection methods may not require combining cellular and Wi-Fi networks. Wi-Fi offloading can be useful in high-download use cases, such as diagnostics, log transfer, software updates, and remote services.

[0034] In addition to offloading, another aspect of QoS management according to one or more embodiments of the present disclosure includes network slicing. Network slicing may improve QoS control. However, network slicing may increase resource demands and require contracts with mobile network operators (MNOs). Network slicing may enable multiplexing of independent virtualized logical networks over the same physical network infrastructure. Each network slice may be an isolated end-to-end network adapted to meet the diverse requirements of a specific application, such as a dedicated network for autonomous mobility with high availability and safety for vehicles.

[0035] Network slicing can therefore support networks designed to efficiently encompass multiple services with different service level requirements (SLRs), enabling the implementation of flexible and scalable network slices on a common network infrastructure. Each network slice can be managed by a mobile virtual network operator (MVNO). An infrastructure provider (e.g., a communications infrastructure owner) rents its physical resources to MVNOs that share the underlying physical network. Depending on the availability of allocated resources, an MVNO can autonomously deploy multiple network slices customized for the various applications offered to its own users. There can be various ways to slice a network.

[0036] In addition to offloading and network slicing, APN coordination may be used in managing QoS according to one or more embodiments of the present disclosure. Similar to network slicing, access to enterprise APNs may require an MNO contract. Standard APNs may be available without an MNO contract. Managing QoS through APN selection may be more cost-effective than network slicing.

[0037] When a UE first connects to a network, a default bearer may be assigned that remains as long as the UE is connected to the network. Each default bearer is associated with an IP address. A default bearer may be a non-guaranteed bit rate (GBR). A dedicated bearer may provide a dedicated tunnel for one or more specific traffic (e.g., VoIP, video, etc.). A dedicated bearer may function as an additional bearer in addition to the default bearer. Thus, a dedicated bearer may not have a separate IP address because it is linked to one of the previously established default bearers. A dedicated bearer may include GBR or non-GBR. For some services, a dedicated bearer may provide a higher user experience quality. For example, a dedicated bearer may use a traffic flow template (TFT) to prioritize specific services.

[0038] A model of QoS management according to one or more embodiments of the present disclosure may include a first level and a second level, where the first level modifies the radio frequency (RF) layer and the second level modifies the internet protocol (IP) layer. For example, modifications to the RF layer may include Wi-Fi offload and / or network slicing. Modifications to the IP layer may include adjusting the APN by changing frequency bands, traffic templates, and / or radio access technologies (RATs). The first level is described with reference to method 300 of FIG. 3. The second level is described with reference to method 400 of FIG. 4.

[0039] QoS thresholds may be determined for each priority in some examples, including the four categories listed above: (1) autonomous driving, (2) ADAS and safety, (3) infotainment and navigation, and (4) convenience. Parameters, such as the measurement parameters described with respect to Figure 2, may be weighted and summed into a QoS value. The QoS value may be used for comparison with the QoS thresholds in methods 300 and 400 of Figures 3 and 4.

[0040] Referring to Figure 3, a first level method 300 of QoS management is shown in accordance with one or more embodiments of the present disclosure. Method 300 may be performed continuously to update wireless connections in real time or near real time according to parameters such as those described with respect to Figure 2. For example, method 300 may be performed by a TCU of a vehicle, such as telematics unit 30 of vehicle 12 of Figure 1, to change the RF layer to raise the QoS level above the QoS threshold as described above.

[0041] The method 300 begins at 302 with the establishment of a connection. For example, a wireless connection may be formed between the TCU and a cellular network.

[0042] Method 300 proceeds to 304 to determine whether Wi-Fi (or edge network) offload is supported. For example, if the QoS value is greater than the QoS threshold, it may be determined that Wi-Fi offload is not supported. Alternatively, if the QoS value is less than the QoS threshold for each priority, a scan for available Wi-Fi networks may occur. If a Wi-Fi network is found during the scan, it may be determined that offload is supported. Thus, determining whether Wi-Fi offload is supported may include comparing the QoS level with a QoS threshold for one or more priorities and scanning for available Wi-Fi networks.

[0043] If it is determined that offloading is supported (“Yes” at 304), the method 300 proceeds to 306 where the offloading occurs.

[0044] The 306 includes the 308 and enables Wi-Fi offload.

[0045] 306 also includes 310, where the routing policy is applied. Applying the routing policy may include selecting an appropriate routing policy and implementing the routing policy.

[0046] 306 also includes 312, where a data connection is enabled. Enabling a data connection may include connecting to a Wi-Fi or edge network.

[0047] The method 300 proceeds from 306 to 314, where the data connection is monitored. Monitoring the data connection may include monitoring connectivity to detect whether the data connection is online (e.g., connected) or offline (e.g., disconnected).

[0048] The method 300 proceeds to 316 and determines whether the data connection is online.

[0049] If the data connection is online (YES at 316), the method 300 returns to 314 where the data connection is monitored. Monitoring the data connection may continue until the connection goes offline.

[0050] If the data connection is offline (“No” at 316), the method 300 returns to 304 to determine whether Wi-Fi offload is supported, as described above.

[0051] Alternatively, if Wi-Fi offload is not feasible due to a lack of available networks or due to QoS values ​​exceeding QoS thresholds for one or more priorities, an alternative method such as network slicing may be used. Thus, if it is determined that offload is not supported (“No” at 304), the method proceeds to 318 to determine whether network slicing is supported.

[0052] If network slicing is supported (“Yes” at 318), the method 300 proceeds to 320, where network slicing occurs. Network slicing may include adjusting Universal Software Radio Peripheral (USRP) rules.

[0053] 320 includes 322 and is subject to USRP rules.

[0054] 320 also includes 324, where the routing policy is applied. Applying the routing policy may include selecting an appropriate routing policy, similar to step 310, and implementing the policy.

[0055] Method 300 proceeds from 320 to 326 where the data connection is monitored. Monitoring the data connection may include periodically or continuously checking whether the connection is online or offline, similar to 316.

[0056] The method 300 proceeds to 328 and determines whether the data connection is online.

[0057] If the data connection is online (YES at 328), the method returns to 326. Monitoring of the data connection may continue until it is determined that the connection is offline.

[0058] If the data connection is offline (“No” at 328), the method 300 returns to 318 to determine whether network slicing is supported, as described above.

[0059] If network slicing is not supported (“No” at 318), method 300 proceeds to 330, where the APN is set to the second level. For example, method 400 of FIG. 4 may be performed.

[0060] Method 300 is exemplary and non-limiting with respect to the steps or order of steps of a method according to the present disclosure for managing QoS by adjusting the RF layer. For example, some steps of method 300 may be performed simultaneously or in a different order than that shown.

[0061] IP layer modifications, such as setting an APN to improve QoS, may be implemented at a second level of the model. Referring to FIG. 4, a second level method 400 for QoS management is shown, in accordance with one or more embodiments of the present disclosure. Method 400 may be part of method 300 of FIG. 3. Thus, method 400 may be performed by a TCU of a vehicle, such as the telematics unit of FIG. 1, to improve QoS by modifying the IP layer.

[0062] Method 400 begins at 402, where the signal quality, network latency, and data connection cost of a serving cellular tower and a neighboring cellular tower are measured. Serving signal quality may be the quality of a signal from a serving cellular tower that provides a cellular connection to the vehicle. Similarly, neighboring cellular tower signal quality may be the quality of a signal from a neighboring cellular tower that is not the serving cellular tower. In other words, a neighboring cellular tower may be a cellular tower that is within range but does not provide a connection to the TCU. Measuring may include monitoring and receiving data from various sensors, including TCU sensors, vehicle sensors, etc.

[0063] The method 400 proceeds to 404 and determines whether the quality of the serving cell exceeds a threshold, above which may be considered good quality and below which may be considered poor quality.

[0064] If the signal quality of the serving cellular tower does not exceed the threshold (“No” at 404), the method 400 proceeds to 406 to determine whether the signal quality of a neighboring cellular tower exceeds the threshold.

[0065] If the signal quality of the neighboring cellular tower does not exceed the threshold (“NO” at 406), the method proceeds to 408, where the radio access technology (RAT) is changed. Changing the RAT may include, for example, switching between Bluetooth, Wi-Fi, and Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), Fifth Generation New Radio (5G NR), etc., depending on which RAT is supported. The RAT may be changed according to which RAT may provide a higher QoS level, depending on the vehicle's location and other environmental parameters. Accordingly, the QoS management system of the present disclosure may incorporate environmental parameters as inputs to machine learning (ML) models to optimize QoS, as described further below.

[0066] Alternatively, if the signal quality of the neighboring cellular tower exceeds the threshold ("Yes" at 406), method 400 proceeds to 410, where the frequency band is changed. Changing the frequency band to one that can provide higher QoS may similarly depend on environmental factors, such as the magnitude of network traffic on the frequency band. Example QoS management systems of the present disclosure may use such environmental factors in their decision-making (e.g., classification and adjustment), as further described below, and therefore may more effectively improve QoS.

[0067] If the signal quality of the serving cellular tower exceeds a threshold (“YES” at 404), the method proceeds to 412 to determine whether the latency exceeds a threshold. Latency above the latency threshold may be considered high latency, i.e., a slow communication over the network connection. Latency below the latency threshold may be considered low latency, i.e., a fast communication over the network connection. Therefore, low latency may be desired to improve QoS.

[0068] If the latency exceeds the latency threshold (YES at 412), the method proceeds to 414, where the traffic template is changed. The traffic template may define a priority group, such as the four priority categories described above. Changing the traffic template may improve the QoS depending on the network traffic. For example, the new traffic template may reduce latency under some conditions.

[0069] Alternatively, if the latency does not exceed the latency threshold ("NO" at 412), method 400 proceeds to 416 to determine whether the cost exceeds a cost threshold. The cost of a network connection may depend on the type of connection (e.g., cellular or Wi-Fi) and the available networks. For cellular and some Wi-Fi connections, the cost of data may be proportional to the amount of data used. Unmetered Wi-Fi connections may not have an associated cost.

[0070] If the cost exceeds the cost threshold (YES at 416), method 400 proceeds to 414, where the traffic template is modified, as described above. Modifying the traffic template may reduce costs by more efficiently prioritizing current network traffic.

[0071] If the cost does not exceed the cost threshold (“NO” at 416), method 400 proceeds to 418, where the APN is maintained. Maintaining the APN may include maintaining the current RAT, frequency band, and traffic template. Method 400 ends after 418, 408, or 410. Method 400 may be repeated continuously or periodically to update the APN to increase QoS levels. In other examples, some steps of method 400 may be performed simultaneously or in a different order than illustrated.

[0072] As described above, machine learning models may be implemented in QoS management methods according to the present disclosure to adjust QoS according to various parameters (e.g., by selecting offloading, network slicing, or APNs as described with respect to Figures 3 and 4), such as those of Figure 2. The machine learning models may utilize data statistics and inherent correlations between environmental and telematics conditions to make predictions of expected end-user experience in order to enhance QoS levels.

[0073] Inputs to the machine learning model may include TCU behavior parameters (e.g., TCU behavior parameters 200 in FIG. 2 ), environmental information (e.g., environmental parameters 230 in FIG. 2 ), and crowdsourced vehicle information. For example, TCU behavior parameters may include hardware temperature, average uptime and downtime (e.g., latency), central processing unit (CPU) behavior, TCU location, memory usage, etc. Environmental information may include weather, such as sun, clouds, wind, and rain. Environmental information may also include time, cellular service coverage map information, road traffic (e.g., vehicle density in an area of ​​interest), vehicle trajectory or heading and speed, vehicle location topography, etc. Crowdsourced vehicle information may be vehicle-to-vehicle (V2V) information of TCU behavior shared between vehicles in a connected vehicle network, such as network 10 in FIG. 1 .

[0074] User experience metrics to which QoS correlates may include throughput (e.g., amount of data transmitted), jitter (e.g., latency variation), delay (e.g., latency increase), etc. Using an ML model according to the present disclosure may improve user experience satisfaction according to such metrics compared to QoS management without knowledge of the context more holistically captured by the above parameters. For example, throughput may be increased, and jitter and delay may be decreased. Thus, the ML model may be trained with data representing all potential conditions (e.g., combinations of input parameters) that a vehicle and its TCU may experience. In this way, a QoS management system according to the present disclosure provides a holistic approach to tuning vehicle connections using ML and may further improve QoS beyond what other QoS management systems achieve by considering fewer parameters (e.g., not considering environmental parameters).

[0075] A first ML model (e.g., ML model 104 of FIG. 1 ) may classify usage scenarios and QoS conditions. For example, referring to FIG. 5 , a system 500 is shown that uses a classification ML model 502 for such classification. An ensemble classifier 526 may include the classification ML model 502 and its output 506. The ensemble classifier 526 may be implemented in an in-vehicle infotainment (IVI) system, a TCU (e.g., telematics unit 30 of FIG. 1 ), an edge-based software application platform, and / or the cloud (e.g., cloud 106 of FIG. 1 ).

[0076] Inputs 504 to the ML model 502 may include TCU behavior parameters 508 and environmental parameters 510. As described above, the TCU behavior parameters 508 may include hardware conditions (e.g., temperature), throughput, latency, memory usage, etc. The TCU behavior parameters 508 may be obtained from TCU sensors. The environmental parameters 510 may include weather, trajectory, time, road traffic, network coverage, etc. The environmental parameters 510 may be provided by external data sources such as vehicle sensors, other vehicles, personal radios, etc. In this manner, sensor data and environmental factors may be integrated to predict QoS levels.

[0077] The ML model 502 may include a usage scenario classifier 512 and a QoS classifier 514. The ML model 502 may be any classification-based algorithm that can take input parameters (e.g., inputs 504) and generate one or more classifications (e.g., outputs 506) according to the input parameters.

[0078] The ML model 502 and expert rules 516 may result in an output 506. The expert rules 516 may be rules associated with a given condition or usage scenario that involves a QoS level.

[0079] The output 506 may include usage scenarios 518 and QoS levels 520 generated by the usage scenario classifier 512, the QoS classifier 514, and the expert rules 516. The QoS levels may be classified as good, normal, or poor. For example, a first threshold and a second threshold may define three categories: poor below the first threshold, normal between the first and second thresholds, and good above the second threshold. The usage scenarios 518 may represent conditions in which the TCU is operating. For example, the usage scenarios 518 may depend on environmental parameters and TCU behavior parameters. For example, the usage scenarios may describe the vehicle's position and trajectory, surroundings, and network traffic.

[0080] The output 506 may be used to generate a signal to modify the control parameters 522. For example, the control parameters may be modified according to the usage scenario 518, the QoS level 520, and the expert rules 516. If the QoS level is good, the control parameters may not need to be adjusted. However, if the QoS level is normal or poor, the control parameters may be adjusted to increase the QoS level.

[0081] A signal to change the control parameters 522 may be sent to the TCU's control parameter policy 524. Upon receiving the signal to change the control parameters 522, the control parameter policy 522 may change the control parameters according to a predetermined policy stored in the TCU's memory. In the system 500, the control parameter policy 524 may be a set of static, predetermined rules for changing the control parameters according to the usage scenario and the QoS level. For example, the control parameters (e.g., the control parameters 212 and 224 in FIG. 2) may be adjusted according to the usage scenario 518. Thus, the control parameter policy 524 may elicit different responses to different combinations of weather, location, traffic, latency, etc. In this manner, the system 500 may improve QoS using a combination of static rules and dynamic scenario identification. Thus, by taking more parameters into account when managing QoS, the system 500 may further improve QoS over other systems that only include static rule-based management.

[0082] The use of classification ML model 502 may improve the ability to detect QoS degradation early and proactively adjust QoS policies, minimizing disruptions to connection quality of service. For example, ML model 502 may translate decision boundaries into usage scenarios rather than purely static rules. Thus, model 502 may enable continuous refinement of QoS according to operating conditions, including parameters from on-board sensors, network, and / or environmental factors. In this way, system 500 may provide improved user experience metrics, such as increased throughput and reduced jitter and latency, compared to other QoS management systems.

[0083] 6, another example of a system 600 is shown that includes ML model 502 and a second ML model, a reinforcement learning agent 602. Similar to system 500, system 600 may be incorporated into a vehicle telematics system, such as vehicle 12 and telematics unit 30 of FIG.

[0084] The ML model 502 may receive the input 504 and, in response, produce an output 506, as described above. The reinforcement learning agent 602 may receive the output 506 as an input. The reinforcement learning agent 602 may be any ML model capable of decision-making and optimization, such as a deep Q-learning algorithm. A Q-learning table may be stored in the TCU's memory to select an action under certain circumstances according to the usage scenario 518. For example, such an action may include changing the APN or bandwidth, as described above. The control parameter policy 524 may be modified (e.g., updated) using the output of the reinforcement learning agent 602. The reinforcement learning agent 602 may function as a QoS policy. Thus, the reinforcement learning agent 602 may be trained without a policy until it converges on a stable policy that produces an optimized reward. Such rewards may include changes in key performance metrics, such as increased throughput, reduced jitter, or reduced latency in data transmission. In the system 600, the control parameter policy 524 may be a dynamic rule set for changing the control parameters based on the usage scenario 518 converged upon by the reinforcement learning agent 602.

[0085] The cumulative rewards received by the reinforcement agent over a period or number of episodes may be used to quantify performance metrics of the reinforcement learning agent 602. Additionally, convergence time, or the amount of time it takes the reinforcement learning agent 602 to converge to a stable policy, and the stability of the learned policy may also be calculated to assess the ability of the reinforcement learning agent 602 to make informed decisions that optimize QoS. Additionally, certain network performance indicators, such as latency, throughput, or packet loss rate, may be used to measure the impact of the reinforcement learning agent 602's decisions on network performance.

[0086] In this way, system 600 uses sensor data and information about the surrounding environment to adaptively optimize QoS policies in addition to classifying scenarios. The reinforcement learning agent can learn to balance different actions based on the rewards and penalties it receives, resulting in a self-optimizing system that can continuously improve performance over time. Such a system can increase adaptability in dynamic network environments, thereby increasing QoS levels in a wider variety of scenarios.

[0087] 7, an exemplary software architecture 700 is shown schematically. The software may be installed in a TCU 702 of a vehicle, such as the telematics unit 30 of the vehicle 12 shown in FIG. 1. The TCU 702 may include an application processor 704, an Ethernet physical layer (PHY) 706, a modem processor 708, and a Wi-Fi module 710.

[0088] The Ethernet PHY 706 may be a transceiver. One or more virtual local area networks (VLANs) may communicatively connect the Ethernet PHY 706 to a network stack 726 of the application processor 704. One or more PDN connections may be established between the network stack 726 and the modem processor 708. The Wi-Fi module 710, in conjunction with a Wi-Fi driver 728 of the application processor 704, may enable the TCU 702 to connect to a Wi-Fi network, for example, when Wi-Fi offload is desired. The application processor 704 may also include a radio interface layer (RIL) 730 and a quality monitoring interface (QMI) 732.

[0089] QoS control 712 may be part of application processor 704. QoS control 712 may implement method 800 of FIG. 8 to manage QoS for TCU 702. For example, QoS control 712 may communicate with traffic control 714, IP performance measurement 716, RF performance measurement 718, routing 720, radio control 722, and packet data network (PDN) control 724. PDN control 724 may control APN and GBR.

[0090] Referring to FIG. 8, a flowchart of a method 800 for implementing a QoS management system in a vehicle's telematics unit is shown, in accordance with one or more embodiments of the present disclosure. Method 800 may be completed upon execution of instructions stored in memory on the telematics unit and / or remotely, such as in the cloud. Method 800 may be performed by a QoS management system that includes a classification-based ML model, such as system 500 of FIG. 5. Method 800 may also be applicable to a QoS management system that includes both a classification-based ML model and a reinforcement learning agent, such as system 600 of FIG. 6.

[0091] Method 800 begins at 802, where TCU behavior parameters and environmental parameters are received. For example, the TCU behavior parameters and environmental parameters may be TCU behavior parameters 508 and environmental parameters 510 of FIGS. 5 and 6, respectively. Accordingly, the TCU behavior parameters and environmental parameters may include measurement parameters, such as measurement parameters 204 and measurement parameters 216 of FIG. 2. For example, the TCU behavior parameters may include signal quality and latency. The environmental parameters may include weather, surroundings, vehicle trajectory, cellular telephone location, and traffic conditions. The TCU behavior parameters may be received from the TCU, such as from sensors located on the TCU. The environmental parameters may be received from other vehicle sensors and vehicle-to-vehicle communications. Receiving the parameters may include, for example, receiving the parameters at a vehicle CPU and / or TCU. Receiving the TCU behavior parameters and environmental parameters may include various sensors, including vehicle sensors and other vehicle sensors, that monitor the TCU behavior parameters and environmental parameters.

[0092] Method 800 proceeds at 804 to determine a usage scenario and a QoS level from the TCU behavior parameters and the environmental parameters using a usage scenario classifier, a QoS classifier, and expert rules. The usage scenario classifier and the QoS classifier may be classification-based machine learning models that classify the usage scenario and the QoS level. The TCU behavior parameters and the environmental parameters may be input to a classification ML model that includes the usage scenario classifier and the QoS classifier as inputs, as described with respect to FIGS. 5 and 6. The usage scenario classifier, the QoS classifier, and the expert rules may generate the usage scenario and the QoS level based on both the predetermined rules and the learned classifications. The usage scenario may encompass various factors, including, for example, whether the vehicle is stationary or moving based on vehicle sensors, whether the vehicle is in an urban or rural area according to traffic levels and geographic location or navigation-based information, and so on. The QoS classifier may classify the QoS level into one of two or more categories. For example, the QoS classifier may identify whether the QoS value is above or below one or more thresholds, as described above with respect to FIG. 3. In one example, the QoS levels may be classified as good, normal, or poor. For example, a first threshold and a second threshold may define three categories: poor below the first threshold, normal between the first and second thresholds, and good above the second threshold. In other examples, there may be additional categories with different thresholds.

[0093] Method 800 proceeds to 806, where the control parameters are modified according to a control parameter policy. The control parameter policy may select a control parameter adjustment using the usage scenario and QoS level determined at 804. For example, the control parameters may include control parameters 212 and control parameters 224 of FIG. 2. For example, a new APN may be selected.

[0094] Method 800 proceeds to 808, where the usage scenario and QoS level are optionally provided to a reinforcement learning agent. 808 may be completed if the QoS management system includes a reinforcement learning agent, such as reinforcement learning agent 602 in Figure 6. If the QoS management system does not include a reinforcement learning agent, 808 is not included.

[0095] Method 800 proceeds to 810, where the control parameter policy is optionally updated. For example, the control parameter policy may be updated by a reinforcement learning agent in examples where a reinforcement learning agent is included. The reinforcement learning agent may continuously learn from the rewards and penalties by adjusting the control parameter policy during operation of the QoS management system. In this manner, control of the network connection is optimized during use, and the connection parameters may be further adjusted to suit the use case to improve QoS. Method 800 then ends.

[0096] A technical effect of the QoS management system and method disclosed herein is to improve the QoS of vehicular connections using machine learning to provide context-based adjustments to the RF and IP layers. The QoS management system and method of the present disclosure may be sensitive to changes in the environment and telematics unit behavior to adapt the connection to different scenarios classified by the ML model. Policies may then direct responses (e.g., adjustments to control parameters) according to the classified scenario. Furthermore, in at least some examples, a reinforcement learning agent may update policies to optimize QoS during operation. In this manner, throughput may be increased and jitter and latency may be reduced.

[0097] 1 and 5-7 show schematic diagrams of example configurations with the relative positions of various components. As used herein, the term "approximately" is to be interpreted as meaning a range of plus or minus 5 percent unless otherwise specified.

[0098] It will be understood that the configurations and routines disclosed herein are exemplary in nature, and that these specific embodiments are not to be considered in a limiting sense, as many variations are possible. Moreover, unless expressly stated to the contrary, terms such as "first," "second," and "third" are not intended to denote any order, position, quantity, or importance, but are merely used as labels to distinguish one element from another. The subject matter of the present disclosure includes all novel and non-obvious combinations and subcombinations of the various systems and configurations, and other features, functions, and / or properties disclosed herein.

[0099] The following claims particularly point out certain combinations and subcombinations that are deemed novel and non-obvious. These claims may refer to "an" element or "first" element or their equivalents. Such claims should be understood to include the incorporation of one or more such elements, without requiring or excluding two or more such elements. Other combinations and subcombinations of the disclosed features, functions, elements, and / or properties may be claimed through amendment of the claims or through the presentation of new claims in this or a related application. Such claims, whether broader, narrower, equal, or different in scope than the original claims, are also considered to be within the subject matter of the present disclosure.

Claims

1. A quality of service (QoS) management system (500, 600) for a telematics control unit (TCU) (702) of a vehicle (12), comprising: The QoS management system (500, 600) includes a classification machine learning model (502) adapted to receive TCU behavior parameters (200) and environmental parameters (230) and output a usage scenario (518) and a QoS level (520) according to the TCU behavior parameters and the environmental parameters.

2. The QoS management system (500, 600) of claim 1, further comprising a reinforcement learning agent (602) adapted to update a control parameter policy according to the usage scenario (518) and the QoS level (520).

3. 3. The QoS management system (500, 600) of claim 2, wherein the control parameter policy is a set of rules for adjusting control parameters (212, 224) according to the usage scenario (518) and the QoS level (520).

4. The QoS management system (500, 600) of claim 1, wherein the environmental parameters include at least some of the following: location, weather, time, and signal coverage map.

5. The QoS management system (500, 600) of claim 1, wherein the usage scenario (518) describes the vehicle's location and trajectory, surroundings, and network traffic.

6. The QoS management system (500, 600) of claim 1, wherein the TCU behavior parameters include signal quality and latency.

7. The QoS management system (500, 600) of claim 1, wherein the TCU behavior parameters and the environmental parameters are received from sensors in the vehicle and other vehicles.

8. A method (800, 400, 300) for quality of service (QoS) management in a vehicle (12), comprising: A telematics control unit (TCU) (702) receives behavioral parameters (200) and environmental parameters (230); determining a usage scenario (518) and a Quality of Service (QoS) level (520) from the TCU behavior parameters and the environmental parameters using a usage scenario classifier (512), a Quality of Service (QoS) classifier, and expert rules (516); and modifying the control parameters according to the control parameter policy.

9. 10. The method (800, 400, 300) of claim 8, wherein the control parameter policy is a set of static predefined rules for modifying the control parameters according to the usage scenario (518) and the QoS level (520).

10. 10. The method of claim 8, further comprising providing the usage scenario and the QoS level to a reinforcement learning agent.

11. The method of claim 10, further comprising modifying a control parameter policy using the output of the reinforcement learning agent.

12. 12. The method of claim 11, wherein the control parameter policy is a dynamic rule set for varying the control parameters based on the usage scenario, and wherein the control parameter policy is converged upon by the reinforcement learning agent.

13. 10. The method of claim 8, wherein the usage scenario classifier and the QoS classifier are classification-based machine learning models that classify the usage scenarios and the QoS levels.

14. The method (800, 400, 300) of claim 8, wherein the control parameters include a frequency band, a radio access technology, and an APN.

15. The method (800, 400, 300) of claim 8, wherein the control parameters include frequency, channel, and width.

Images