Radio quality of service management
By negotiating service quality requirement sets and alternative proposals between devices and network equipment, the problem of the inability to effectively manage the reliability and availability of end-to-end communication services in existing technologies is solved. In safety-critical applications, the network can provide reliable QoS guarantees within variable time intervals, thereby improving communication efficiency and reliability.
Patent Information
- Application Number
- CN202510289377.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2024-03-14
- Filing Date
- 2025-03-12
- Publication Date
- 2025-09-16
AI Technical Summary
Existing 3GPP standards cannot effectively manage the reliability and availability of end-to-end communication services in wireless communications. Especially in safety-critical applications, the network cannot provide reliable QoS guarantees according to the application's requirements, resulting in unnecessary exchange of request and response cycles between applications and the network, and the existing interfaces lack clear reliability metrics.
By exchanging quality of service requirement sets and alternative proposals between devices and network devices, application functions and network devices negotiate QoS and reliability requirements. Network devices generate alternative quality of service requirement sets to meet the minimum achievable requirements of applications and extend existing QoS interfaces with clear reliability metrics to ensure that the network can provide reliable QoS guarantees within variable time intervals.
It provides a set of security requirements for the network while taking application functions into consideration, avoids infinite request exchanges, ensures that the network can meet the QoS and reliability requirements of applications within variable time intervals, and improves the reliability and efficiency of end-to-end communications.
Smart Images

Figure CN120659104A_ABST
Abstract
Description
Technical Field
[0001] Aspects of the present specification relate to computer-implemented methods for operating devices, computer-implemented methods for operating network devices, and associated apparatus, system, and computer program elements. Background Art
[0002] Safety-critical applications that communicate between two distinct entities have strong requirements for end-to-end communication service availability and reliability. At the application layer, security mechanisms are typically implemented to monitor the fulfillment of these communication requirements, triggering specific actions if they are violated. At the network layer, specific communication mechanisms are configured to provide the required availability and reliability according to the agreed service-level agreements.
[0003] In wireless communications, different mechanisms are available that enable applications to request communication services with a given quality of service. 3GPP 5G-NR (Release 16) specifies that an application can request the 5G network to establish a QoS flow that supports a packet error rate and / or a maximum flow bit rate, as specified in 3GPP TS 23.434. According to this scheme, the network evaluates the QoS flow request against the current network conditions and decides either to provide the requested QoS flow if it is possible to provide it, or to provide an alternative QoS flow with lower guarantees if the original QoS flow cannot be provided, or to reject the request if no guarantees can be provided. However, the provision of QoS guarantees to applications in wireless networks can be further improved. Summary of the Invention
[0004] The present disclosure relates to a computer-implemented method for operating a device as defined in claim 1, a computer-implemented method for operating a network device as defined in claim 6, a device as defined in claim 11, a network device as defined in claim 12, a communication system as defined in claim 13, and a computer program as defined in claim 15. The dependent claims describe preferred embodiments of the computer-implemented method and system.
[0005] According to a first aspect, there is provided a computer-implemented method for operating a device, comprising:
[0006] - obtaining, from at least one application function hosted by the device, one or more quality of service requirement sets for the at least one application function, wherein each quality of service requirement set defines at least one quality of service parameter requirement of a communication network communicatively coupling the device to a network device;
[0007] - transmitting a request message to the network device, wherein the request message includes the one or more quality of service requirement sets;
[0008] - receiving, from the network device, at least one response message comprising at least one response to the request message, wherein the at least one response message comprises (i) approval of the one or more quality of service requirement sets; and / or (ii) at least one alternative proposal to the quality of service requirement sets;
[0009] - selecting at least one quality of service requirement set and / or at least one alternative proposal to the quality of service requirement set based on one or more requirements of the application function; and
[0010] - transmitting a decision message to the network device, wherein the decision message comprises instructions for the network device to configure resources based on at least one of the selected quality of service requirement set and / or at least one alternative proposal to the quality of service requirement set.
[0011] When an application function provides some security requirements, and the network responds with requirements that it can implement (which may be a subset of the requirements provided by the application), the application can accept the provided subset or make another request with relaxed requirements. If there is no convergence between the application's requirements and the network's capabilities, this can potentially lead to an infinite exchange of requirements.
[0012] The effect of the computer-implemented method according to the first aspect is that it provides a mechanism for the network to provide a set of security requirements that the network can implement, taking into account the application capabilities. Previously, the network only provided a method for requesting a QoS level, but not a reliability level. According to the present specification, if the network cannot meet the QoS reliability requirements, the network responds with a proposal for requirements that are a subset of the requested requirements. For example, the network can respond with a proposal to reduce the time window, relax the time requirements, or remove a QoS indicator from a set of QoS indicators. The technology according to this specification also solves the problem of looping ("ping-pong") of requests and responses until consensus is reached by allowing the network to include multiple requirements that it can meet, rather than leaving the application to guess the requirements that the network can meet, as sometimes happens when the application relaxes its requirements without knowing the network's capabilities.
[0013] According to a second aspect, there is provided a computer-implemented method for operating a network device, comprising:
[0014] receiving, from a device, a request message including one or more quality of service requirement sets, wherein each quality of service requirement set defines at least one quality of service parameter requirement of a communication network that communicatively couples the device to the network device;
[0015] determining whether the communication network can satisfy all quality of service parameter requirements of the device included in each quality of service requirement set;
[0016] If, for at least one of the quality of service requirement sets or a subset of the quality of service requirement sets, the communication network is unable to meet all of their respective quality of service parameter requirements:
[0017] then generating at least one alternative quality of service requirement set for at least one of the quality of service requirement sets or a subset of the quality of service requirement sets for which the communication network cannot meet all quality of service parameter requirements; and
[0018] At least one response message is transmitted to the device, wherein the message includes the at least one alternative quality of service requirement set.
[0019] According to a third aspect, a device is provided. The device includes a radio interface, a processor, and a memory. The processor is configured to use at least one application function hosted by the processor to obtain one or more quality of service requirement sets of the at least one application function, wherein each quality of service requirement set defines at least one quality of service parameter requirement of a communication network that communicatively couples the device to a network device; wherein the processor is configured to transmit a request message to the network device via the radio interface, wherein the request message includes the one or more quality of service requirement sets; wherein the radio interface is configured to receive at least one response message from the network device including at least one response to the request message, wherein the at least one response message includes (i) approval of the one or more quality of service requirement sets; and / or (ii) at least one alternative proposal to the quality of service requirement set; wherein the processor is configured to select at least one quality of service requirement set and / or at least one alternative proposal to the quality of service requirement set based on the requirements of the application function; and wherein the processor is configured to transmit a decision message to the network device via the radio interface, wherein the decision message includes instructions for the network device to configure resources based on at least one of the selected quality of service requirement set and / or at least one alternative proposal to the quality of service requirement set.
[0020] According to a fourth aspect, a network device is provided, comprising a radio interface, a processor, and a memory. The processor is configured to receive a request message from a device comprising one or more quality of service requirement sets, wherein each quality of service requirement set defines at least one quality of service parameter requirement of a communication network that communicatively couples the device to the network device. The processor is configured to determine whether the communication network can satisfy all quality of service parameter requirements of the device included in each quality of service requirement set.
[0021] If the communication network is unable to meet all of the respective quality of service parameter requirements for at least one of the quality of service requirement sets or a subset of the quality of service requirement sets, the processor is configured to generate at least one alternative quality of service requirement set for at least one of the quality of service requirement sets or a subset of the quality of service requirement sets for which the communication network is unable to meet all of the quality of service parameter requirements, and the processor is configured to transmit at least one response message to the device via the radio interface, wherein the message includes the at least one alternative quality of service requirement set.
[0022] According to a fifth aspect, a communication system is provided, comprising the device according to the second aspect, the network device according to the fourth aspect, and a communication network configured to communicatively couple the device to the network device.
[0023] According to a sixth aspect, there is provided a computer program comprising computer readable instructions which, when executed on a processor, are configured to cause the processor to perform the first aspect or embodiments thereof discussed herein.
[0024] According to a seventh aspect, there is provided a computer program comprising computer readable instructions which, when executed on a processor, are configured to cause the processor to perform the third aspect or embodiments thereof discussed herein. BRIEF DESCRIPTION OF THE DRAWINGS
[0025] An exemplary embodiment, which should not be interpreted as limiting the claims, is depicted in the drawings and is explained in more detail below. Wherever possible, the same reference numerals represent similar or analogous features in different drawings.
[0026] Figure 1 The computer-implemented method according to the first aspect is schematically illustrated.
[0027] Figure 2 The computer-implemented method according to the second aspect is schematically illustrated.
[0028] Figure 3 A system is schematically illustrated.
[0029] Figure 4 Schematically illustrates signaling in a system according to embodiments discussed herein.
[0030] Figure 5 The device according to the second aspect is schematically illustrated.
[0031] Figure 6 A system according to the fifth aspect is schematically illustrated. DETAILED DESCRIPTION
[0032] As mentioned in the background section, in the current 3GPP standard (TS23.434), the network evaluates the QoS flow request against the current network conditions and policies, and decides (1) to provide the requested QoS flow if provisioning of the requested QoS flow is possible, (2) to supply an alternative QoS flow with lower guarantees if support cannot provide the original QoS flow in this function, or (3) to reject the request if no QoS guarantees can be provided.
[0033] If network conditions change and a QoS flow cannot be guaranteed, the network currently notifies the application after changing or rejecting the QoS flow. For safety-critical applications, taking reactive measures after being notified of a QoS flow degradation may not be sufficient. Furthermore, application requests and 5G network responses during QoS flow provisioning do not consider the duration of the QoS flow. This information is beneficial to both safety-critical applications and the network. Applications can establish safety measures based on QoS flow guarantees and duration, and the network can more efficiently utilize limited network resources by provisioning them only for the necessary time.
[0034] QoS guarantees are usually only provided for domains controlled by the communication network, so if safety-critical application entities communicate end-to-end via multiple communication technologies, the QoS guarantees provided by a single network only consider a subset of the end-to-end communications. In this case, from the perspective of the application or communication service, an end-to-end aware control mechanism is needed. Generally, it is not practical to have a dominant communication network control mechanism outside the system, especially for communication services provided in a wide area network. Therefore, safety-critical applications mainly rely on end-to-end monitoring mechanisms. The implementation of a campus network (where communication services are restricted to a specific geographical area) is a promising and practical scenario for providing safety-critical applications through multiple communication technologies and security support from the campus network.
[0035] In 3GPP, functional safety requirements are addressed in TS 22.104, and further specifications for communication service availability, other QoS metrics used to assess "black channel" quality, and their relationships are specified in TS 22.185 (e.g., end-to-end delay, lifetime, burst, and transmission interval definitions, and their relationships). In the 3GPP architecture specifications, end-to-end delay, lifetime, burst, and transmission interval are defined in TS 22.261. Release 16's TS 23.501 considers enabling mechanisms for such time-sensitive communication (TSC) applications, which are related to and enable the functional safety requirements in TS 22.185. The 5G System (5GS) introduces features that can be used for time-sensitive communication, represented in the TSC Assistance Information (TSCAI) field. This field describes the TSC data flows and traffic that can be provided by the gNB, allowing for more efficient scheduling of radio resources for PDU sessions.
[0036] Knowledge of TSC traffic patterns is useful for 5G access networks (5G-ANs) because it allows for more efficient scheduling of QoS flows with periodic, deterministic traffic characteristics. Scheduling can be performed via configured grants, semi-persistent scheduling, or utilizing dynamic grants (all types of grants available in 5G networks for downlink and uplink). TSCAI and its associated TSC Assistance Container (TSCAC) include the following:
[0037]
[0038] Table 1. TSC auxiliary container format
[0039] * For example, proactive RAN feedback for adapting burst arrival time and period (RAN provides burst arrival time offset and adjusted period as part of QoS flow adjustment).
[0040] **For TSCAI enablers, network rules may include the performance of jitter measurements by taking into account monitoring and periodically reporting jitter information associated with transmission periods (if occurring). In the event of jitter indication, the measured values should be fed back to the RAN to be addressed (e.g., greater robustness, enhanced resource allocation, etc.).
[0041] Release 18 introduces additional QoS parameters, or updated mappings between security-related requirements and quality of service, such as the following: maximum packets per interval, minimum packets per interval, maximum payload size, minimum payload size, maximum consecutive loss tolerance, maximum latency variation, maximum out-of-orderness, and next-hop information. All of these parameters can be considered in addition to previous QoS flow requirements such as minimum bandwidth, maximum latency (packet delay budget), and maximum loss (packet error rate).
[0042] Therefore, this specification proposes a mechanism for applications to exchange QoS assistance information with a communication network, which can utilize the Figure 3 The network overview shown in Figure 1 is explicitly negotiated to fulfill the reliability metric. Current interfaces and protocols only allow for the sharing of QoS information, without explicit guarantees about how reliably the network will fulfill the QoS parameters. By extending the existing QoS interfaces with explicit reliability metrics, applications with high reliability requirements (such as safety-critical applications like remote-controlled driving) can determine whether the network will meet their requirements in terms of QoS functionality and also in terms of reliability. Furthermore, the extension includes the definition of a variable time interval within which the corresponding QoS requirement needs to be fulfilled with the requested level of reliability.
[0043] Furthermore, if an application's initial request cannot be matched by the network, this specification discusses a protocol that negotiates a feasible set of QoS and reliability requirements to fit the current network capabilities to at least a minimum feasible set of application requirements.
[0044] Figure 1 The computer-implemented method according to the first aspect is schematically illustrated.
[0045] According to a first aspect, there is provided a computer-implemented method (10) for operating a device 50A, comprising:
[0046] - obtaining 11 one or more quality of service requirement sets of at least one application function hosted by the device, wherein each quality of service requirement set defines at least one quality of service parameter requirement of a communication network communicatively coupling the device to a network device;
[0047] - transmitting 12 a request message 48 to the network device, wherein the request message includes one or more quality of service requirement sets;
[0048] - receiving 13 from the network device at least one response message 50 comprising at least one response to the request message, wherein the at least one response message comprises (i) approval of one or more quality of service requirement sets; and / or (ii) at least one alternative proposal to the quality of service requirement set;
[0049] - based on one or more requirements of the application function, selecting 14 at least one quality of service requirement set and / or at least one alternative proposal for the quality of service requirement set; and
[0050] - transmitting 15 a decision message to the network device, wherein the decision message comprises instructions for the network device to configure resources based on the selected quality of service requirement set and / or at least one alternative proposal to the quality of service requirement set.
[0051] For example, the quality of service requirement set may include one or any combination of the quality of service parameters defined in the following list: latency, packet error rate, jitter, mean time to failure (MTTF), period, burst arrival time, lifetime, burst arrival time window, ability to adapt to burst arrival time, N6 jitter information, period range, and / or minimum or maximum time window for quality of service authorization. However, those skilled in the art will appreciate that other parameters that affect the quality of service of applications running on the network and are not included in this list may also be included in the definition of quality of service parameters.
[0052] According to one embodiment, each quality of service requirement set further includes a fault definition for each quality of service requirement parameter, wherein the fault definition defines a domain within which the quality of service requirement parameter is met and outside of which the quality of service requirement parameter is not met.
[0053] For example, each QoS parameter includes a fault definition. An example of a fault definition is a time limit for which a particular application still considers the failure acceptable (and not a failure). In one example, the fault definition is a binary field (in other words, before a given time limit, there is no failure, and after a given time limit, there is a failure). In another example, the fault definition is a continuous or multi-step score. In other words, as the given time limit approaches, the value of the fault definition increases in a stepwise or incremental manner.
[0054] In one specific example, for the QoS parameter "maximum target latency", the failure definition is "greater than 100ms in more than one subsequent transmission out of five subsequent transmissions from the application source to the application sink".
[0055] According to one embodiment, each quality of service requirement set further comprises a reliability requirement for each quality of service requirement parameter; comprising a statistical measure of the non-occurrence of a failure according to the failure definition.
[0056] A reliability requirement for a QoS parameter is a general reliability metric that represents the statistical probability that a failure (according to a "failure definition") will not occur. An example of a reliability requirement that can be assigned to one or more QoS parameters is mean time to failure (MTTF). In one embodiment, at least one QoS requirement in a QoS requirement set includes a reliability requirement defined by mean time to failure. In one example, the mean time to failure of a QoS requirement in a QoS requirement set is, for example, that the mean time to failure should be greater than 1000 hours.
[0057] According to one example, the reliability metric is a rate of occurrence of failure (ROCOF). According to one example, the reliability metric is a probability of failure on demand (POFOD). According to one example, a first quality of service requirement included in the quality of service requirement set includes a first reliability requirement, and a second quality of service requirement parameter included in the quality of service requirement set includes a second reliability requirement, wherein the first reliability requirement and the second reliability requirement are different.
[0058] According to one embodiment, the quality of service requirement set further includes a time window for each tuple of quality of service requirement parameters, fault definitions, and reliability requirements, wherein the time window defines a time period during which the network must provide quality of service guarantees for each quality of service requirement set.
[0059] For example, a tuple is at least a quality of service parameter plus a fault definition plus a reliability requirement.
[0060] Thus, a specific example of a time window for each tuple is: "For the next 15 seconds, for the specified QoS parameters, the given failure definition and the given reliability requirement should be met". Another specific example of a time window for each tuple is "For the specified QoS parameters, from date-time [start: 2023 / 05 / 21-09:05:21] to [end: 2023 / 05 / 21-09:05:30] the given failure definition and the given reliability requirement should be met". Table 2 below gives a specific example of an abundance of information that is considered to be "application requirements" or "network capabilities".
[0061]
[0062] Table 2: Batch application requirements
[0063] According to the exemplary and general description of the techniques of this specification, an application communicates its application requirements to the network. The network responds with its ability to perform the following: (1) fulfill these requirements within the requested time interval, in other words, the network can currently fulfill the application requirements without restriction, or (2) the network responds such that it can only fulfill a limited subset of the application requirements within a certain time interval; in the worst case, the subset can be zero, for example, the network cannot fulfill the application. The application can then accept one or more offers, or abort the process.
[0064] According to an embodiment of the first aspect, there is provided a method of obtaining one or more or an earliest processing deadline and a latest processing deadline from at least one application function. The earliest processing deadline is a time when a response from a network device can be received at the device relative to a time when a request message is transmitted from the device; and / or the latest processing deadline is a time when a latest response message from the network device can be received at the device relative to a time when the request message is transmitted from the device.
[0065] According to one embodiment, the method includes mapping at least one alternative proposal for the quality of service requirement set to a corresponding nearest entry of a quality of service index; and wherein transmitting the at least one alternative proposal for the quality of service requirement set in a decision message includes transmitting the corresponding nearest entry to the network device.
[0066] According to one embodiment, at least one quality of service parameter requirement is one or any combination of the following: time-sensitive communication assistance information TSCAI, maximum packets per interval, minimum packets per interval, maximum payload size, minimum payload size, maximum conservative loss tolerance, maximum latency variation, maximum out-of-orderness, next hop information, minimum bandwidth, maximum latency, maximum loss.
[0067] According to one example, if the proposed quality of service requirements are unacceptable to the application, the process of negotiating QoS authorization is aborted.
[0068] According to one embodiment, the device is included within a vehicle, an automated guided vehicle, an Internet of Things device, or an unmanned aerial vehicle.
[0069] Figure 2 The computer-implemented method according to the second aspect is schematically illustrated.
[0070] According to a second aspect, a computer-implemented method 20 for operating a network device comprises:
[0071] - receiving 21 from a device a request message 48 comprising one or more quality of service requirement sets, wherein each quality of service requirement set defines at least one quality of service parameter requirement of a communication network communicatively coupling the device to the network device;
[0072] - determining 22 whether the communication network is able to satisfy all quality of service parameter requirements of the device included in each quality of service requirement set;
[0073] If 23 for at least one of the quality of service requirement sets or a subset of the quality of service requirement sets, the communications network is unable to meet all of their respective quality of service parameter requirements:
[0074] then generating 24 at least one alternative quality of service requirement set for at least one of the quality of service requirement sets for which the communication network cannot meet all quality of service parameter requirements; and
[0075] At least one response message 50 is transmitted 25 to the device, wherein the message comprises the at least one alternative quality of service requirement set.
[0076] This specification focuses on situations where the network cannot fulfill a request. In this case, the network assesses its capabilities and presents the application with a set of options. These options are combinations of relaxed requirements that it can meet. These combinations are generated in the following manner: First, each value is changed to produce a vector of values. Second, the network then evaluates the feasibility of these value combinations. Third, infeasible combinations are discarded.
[0077] According to an embodiment of the second aspect, generating at least one candidate quality of service requirement set includes:
[0078] For each quality of service requirement parameter in the corresponding quality of service requirement set that does not meet all quality of service parameter requirements:
[0079] converting each quality of service requirement parameter into a quality of service requirement vector comprising a predefined number of entries;
[0080] evaluating feasibility of providing quality of service authorization in the network based on values defined by a plurality of combinations obtained from the corresponding quality of service requirement vectors; and
[0081] Infeasible combinations are removed from the corresponding quality of service requirement vector.
[0082] According to an embodiment of the second aspect, generating at least one candidate quality of service requirement set further comprises:
[0083] For at least one corresponding QoS requirement set that does not meet all QoS parameter requirements:
[0084] At least one quality of service requirement parameter is removed from at least one corresponding quality of service requirement set; and / or at least one quality of service requirement parameter is added to at least one corresponding quality of service requirement set.
[0085] For example, demonstrating the generation of a subset of application requirements for a certain time interval with coarse-grained parameters, a first step creates a QoS value from a request received from the application. The request received from the application corresponds to the signaling defined by the first aspect above or its embodiments.
[0086]
[0087] Table 3: Two QoS requirements for a batch
[0088] In a first step, for each QoS parameter in the batch, a single value corresponding to, for example, a failure definition, a reliability requirement and / or a time window is each expanded into a vector of values corresponding to different options or constraints for the QoS requirements.
[0089] Waiting time value vector:
[0090] 100=>[50,100,150];
[0091] MTTF=>[100,1000,10000]
[0092] Time window => [20, 30, 40]
[0093] PER value vector:
[0094] 0.01=>[0.1,0.01,0.001]
[0095] MTTF=>[1000,10000,100000]
[0096] Time window 15 => [5, 15, 20]
[0097] In a second step, the value vector is evaluated using all reasonable permutations or combinations of the relevant QoS parameters with the reliability requirements. In one embodiment, the value vector is evaluated using a sampling of the relevant QoS parameters with the reliability requirements. According to one example, the combinations of the value vectors are sampled using a Monte Carlo method.
[0098] Some parameters and requirements are interdependent. For example, MTTF and time window are coupled. If additional resources, such as redundant channels or proactive fault compensation, are not included in the assessment, then as one of these increases, the other typically decreases. According to one example, the combination algorithm can optionally use a parameter coupling model to identify theoretically feasible combinations of values.
[0099] In a third step, combinations of the value vectors are filtered based on the capabilities of the network. For example, known latency values that the network cannot achieve can be removed from the set of combinations.
[0100] In another example, options that cannot be implemented by the network through self-reconfiguration for the requested time window are filtered out from the set of theoretically feasible options. The remaining results (e.g., feasible combinations that the network can provide) are returned to the application. In one example, the determination of whether the network can provide certain combinations is provided based on a priori test data, monitoring logs of previous successful or unsuccessful combinations, or simulation of the network.
[0101] Counterintuitively, the network may evaluate a value that is more stringent than the request from the application. In one example, when combined with relaxed requirements (such as lower latency with a higher packet error rate than requested), the value evaluated by the network may be achievable by the network. When all requirements are more stringent than the request (which the network cannot achieve), the resulting option may be discarded without evaluation.
[0102] The reader is referred to the table at the end of this written description which includes, for example, Example 1 of an application's request and the network's response, illustrating how specific values vary based on the capabilities of the network.
[0103] In Example 1, the network cannot provide the requirements requested by the application. Subsequently, the network provides multiple options based on the application's request. In Example 1, five options are provided. In the first option, the MTTF for jitter is reduced to 100 hours. In the second option, the time window for the latency requirement is reduced to 15 seconds. In the third option, the time window for the latency requirement is increased to 50 seconds, but the MTTF is reduced to 100 hours. In the fourth option, the MTTF and time window remain unchanged, but the latency is increased to 90 ms. Finally, in the fifth option of Example 1, the PER requirement is relaxed.
[0104] According to one example, a bandwidth-limited handshake is implemented between the application and the network. To reduce the complexity and bandwidth required for the previously discussed exchange, the network is configured to send a predetermined number of options to the device hosting the application. The predetermined number of options depends on the implementation and is configurable. According to one embodiment, the predetermined number of options can vary as a function of detected network conditions.
[0105] According to one example, a predefined parameter granularity is provided. The granularity can be defined as a rounded unit. In an embodiment, for a latency granularity of 5 ms, possible values can be ≥0 ms, ≥5 ms, ≥10 ms, ≥15 ms, and so on. For example, to reduce the complexity and bandwidth used for this exchange, the parameter granularity is set a priori.
[0106] parameter granularity Waiting time 5ms PER Order of magnitude Jitter 0.5ms MTTF Order of magnitude Time window Second
[0107] Table 4: Predefined parameter granularity
[0108] According to one embodiment, a cost distribution can be calculated for each combination or option. For example, the network can provide the application function with the cost of using each option offered by the network (in terms of money to use the network option, or quality of service usage tokens, etc.). Even when the network can fulfill the requirements required by the application, it can provide other alternatives so that the application can consider the cost when using the option.
[0109] According to another embodiment, a catalog index is provided based on a handshake negotiation. For example, a catalog of quality of service values is provided to both the network and the device hosting the application, as previously standardized between the network and the device hosting the application. In this case, the network can communicate one or more potential values acceptable to a particular application by transmitting a short identifier that references the standardized catalog of quality of service values.
[0110] Figure 3 The system 30 is illustrated schematically.
[0111] For example, system 30 may be a campus network. Specifically, application source 32 is configured to attempt to communicate with application aggregation point 34. The network is composed of a plurality of network nodes R1-R7. A first link A is defined in system 30 as being between application source 32 and application aggregation point 34 via network nodes R1, R5, R6, and R7. Link A is associated with a cost A. A second link B is defined as being between application source 32 and application aggregation point 34 via nodes R1, R2, R4, and R7. Second link B is associated with a cost B. Those skilled in the art will appreciate that Figure 3 The system topology shown is exemplary, and actual systems may have more or fewer nodes arranged in a different topology.
[0112] According to an embodiment of the second aspect, there is provided receiving a decision message 52 from a device, the decision message 52 comprising instructions for the network device to configure resources based on a quality of service requirement set selected at the device and / or at least one of at least one alternative proposal to the quality of service requirement set.
[0113] According to an embodiment of the second aspect, at least one alternative proposal for the quality of service requirement set is mapped to a corresponding nearest entry of the quality of service index; and wherein the at least one alternative proposal for the quality of service requirement set transmitted in the response message comprises transmitting the corresponding nearest entry to the device.
[0114] Figure 4 Schematically illustrates signaling in a system according to embodiments discussed herein.
[0115] exist Figure 4 , element 42 represents an application, element 44 represents a lower layer, and element 46 represents a network.
[0116] According to one embodiment, QoS or reliability requirement requests 48, 49 are transmitted to the network. Optionally, the lower layers transmit measurement reports M1 to the network on a continuous or sampled basis. The network calculates one or more positive responses and proposed adaptations, which are transmitted to the lower layers using signal 51. Time TNN may represent the negotiation time required between the network 46 receiving the transmitted measurement report M1 and the transmission of signal 51 back to the lower layers 44.
[0117] The lower layer 44 communicates the proposed positive response and the proposed network adaptation 51 to the application as a QoS reliability requirement response at signal 50. The time TNA between the initial transmission of the QoS reliability requirement request 48 and the receipt of the QoS reliability requirement response 50 is the negotiation time.
[0118] The application determines the set of values proposed by the network that form the QoS guarantees. The application communicates the decision or selected option to lower layers 44 using message 52. Time TD represents the time required for application 42 to determine the selected option. After transmitting the selected option, application 42 assumes that network 46 will configure itself according to the application's selected option. According to one embodiment, application 42 may wait to receive confirmation that the configuration has occurred (not shown). The application then transmits data in accordance with the negotiated quality assurance using message 53. Message 53 may then be provided by lower layer(s) 44 to network 46 and sent through network 46.
[0119] During the period TM, periodic or on-demand network measurements that monitor reliability requirements may be provided by the lower layers 44 to the network 46 in, for example, messages M2, M3, M4.
[0120] Figure 5 An apparatus according to the third aspect is schematically illustrated.
[0121] According to a third aspect, a device is provided. The device comprises a radio interface 52, a processor 54 and a memory 56.
[0122] The processor 54 is configured to use at least one application function hosted by the processor to obtain one or more quality of service requirement sets for at least one application function, wherein each quality of service requirement set defines at least one quality of service parameter requirement for a communication network that communicatively couples the device to the network device; wherein the processor is configured to transmit a request message to the network device via a radio interface, wherein the request message includes the one or more quality of service requirement sets; wherein the radio interface is configured to receive at least one response message from the network device including at least one response to the request message, wherein the at least one response message includes (i) approval of the one or more quality of service requirement sets; and / or (ii) at least one alternative proposal for the quality of service requirement set; wherein the processor is configured to select at least one quality of service requirement set and / or at least one alternative proposal for the quality of service requirement set based on the one or more requirements of the application function; and wherein the processor is configured to transmit a decision message to the network device via the radio interface, wherein the decision message includes instructions for causing the network device to configure resources based on at least one of the selected quality of service requirement set and / or at least one alternative proposal for the quality of service requirement set.
[0123] According to one example, the device is a user device.
[0124] According to a fourth aspect, there is provided a network device comprising a radio interface, a processor and a memory.
[0125] The processor is configured to receive a request message from a device including one or more quality of service requirement sets, wherein each quality of service requirement set defines at least one quality of service parameter requirement of a communication network that communicatively couples the device to a network device. The processor is configured to determine whether the communication network can meet all quality of service parameter requirements of the device included in each quality of service requirement set. If the communication network cannot meet all of their respective quality of service parameter requirements for at least one of the quality of service requirement sets or a subset of the quality of service requirement sets, the processor is configured to generate at least one alternative quality of service requirement set for at least one of the quality of service requirement sets (or a subset) for which the communication network cannot meet all of the quality of service parameter requirements. The processor is configured to transmit at least one response message to the device via a radio interface, wherein the message includes the at least one alternative quality of service requirement set.
[0126] The radio interface may include a modem, a front end, and an antenna circuit for accessing one or more of a fifth generation system, a long term evolution system (LTE), an advanced LTE system, a high speed packet access system, a universal mobile telecommunications system, an evolved UTRAN, a global system for mobile communications (GSM), an EDGE system, an IEEE 802.11 system, and the like. According to some embodiments, the mobile communication system may be a V2N network or a C-V2X system. The mobile communication system may support at least two communication modes, such as PC5 used between vehicles and Uu used between a vehicle and a base station.
[0127] Figure 6 A system according to the fifth aspect is schematically illustrated.
[0128] According to a fifth aspect, there is provided a system comprising the device according to the first aspect and the network device according to the second aspect, wherein the communication network is configured to communicatively couple the device to the network device. According to one embodiment, the system is a campus communication network.
[0129] According to an embodiment of the fifth aspect, the device is included in a vehicle, an automated guided vehicle, an Internet of Things device, or an unmanned aerial vehicle.
[0130] According to a sixth aspect, there is provided a computer program comprising computer readable instructions which, when executed on a processor, are configured to cause the processor to perform the first aspect or an embodiment thereof.
[0131] According to a seventh aspect, there is provided a computer program comprising computer readable instructions which, when executed on a processor, are configured to cause the processor to perform the second aspect or an embodiment thereof.
[0132] The examples provided in the drawings and described in the preceding written description are intended to provide an understanding of the principles of this specification. They are not intended to limit the scope of the appended claims. This specification describes variations and modifications to the illustrated examples. Only preferred examples are presented, and all changes, modifications, and further applications of these examples within the scope of this specification are intended to be protected.
[0133] Example 1
[0134] Application Request
[0135]
[0136] The network's response: (specific values that changed are circled)
[0137]
[0138]
Claims
1. A computer-implemented method (10) for operating a device (50A), comprising: - obtaining (11) from at least one application function hosted by the device one or more quality of service requirement sets of the at least one application function, wherein each quality of service requirement set defines at least one quality of service parameter requirement of a communication network communicatively coupling the device to a network device; - transmitting (12) a request message (48) to the network device, wherein the request message includes the one or more quality of service requirement sets; - receiving (13) at least one response message (50) from the network device comprising at least one response to the request message, wherein the at least one response message comprises (i) approval of the one or more quality of service requirement sets; and / or (ii) at least one alternative proposal to the quality of service requirement sets; - based on one or more requirements of the application function, selecting (14) at least one quality of service requirement set and / or at least one alternative proposal to the quality of service requirement set; and - transmitting (15) a decision message (52) to the network device, wherein the decision message comprises instructions for the network device to configure resources based on the selected quality of service requirement set and / or at least one alternative proposal to the quality of service requirement set.
2. The computer-implemented method (10) of claim 1, further comprising: - mapping at least one alternative proposal for the set of quality of service requirements to a corresponding nearest entry of a quality of service index; And wherein the at least one alternative proposal to the quality of service requirement set transmitted in the decision message includes transmitting a corresponding most recent entry to the network device.
3. The computer-implemented method (10) according to one of the preceding claims, in, The at least one quality of service parameter requirement is one or any combination of: latency, packet error rate, jitter, mean time to failure (MTTF), period, burst arrival time, time to live, burst arrival time window, capability to adapt to burst arrival time, N6 jitter information, period range and / or minimum or maximum time window for quality of service authorization; and / or The at least one quality of service parameter requirement is one or any combination of the following: time-sensitive communication assistance information (TSCAI), maximum packets per interval, minimum packets per interval, maximum payload size, minimum payload size, maximum conservative loss tolerance, maximum latency variation, maximum out-of-order, next hop information, minimum bandwidth, maximum latency, and maximum loss.
4. The computer-implemented method (10) according to one of the preceding claims, in, Each quality of service requirement set further includes at least one of the following: a fault definition for each quality of service requirement parameter, wherein the fault definition defines a domain within which the quality of service requirement parameter is met and outside of which the quality of service requirement parameter is not met; a reliability requirement for each quality of service requirement parameter; including a statistical measure that a failure according to the failure definition will not occur; and / or a time window for each tuple of a quality of service requirement parameter, a failure definition, and a reliability requirement, wherein the time window defines a time period during which the network must provide a quality of service guarantee for each quality of service requirement set.
5. The computer-implemented method (10) according to one of the preceding claims, in, The device is included in a vehicle, an automated guided vehicle, an Internet of Things device, or an unmanned aerial vehicle.
6. A computer-implemented method (20) for operating a network device, comprising: receiving (21) from a device a request message (48) including one or more quality of service requirement sets, wherein each quality of service requirement set defines at least one quality of service parameter requirement of a communication network that communicatively couples the device to the network device; determining (22) whether the communication network can satisfy all quality of service parameter requirements of the device included in each quality of service requirement set; If (23) for at least one of the quality of service requirement sets or a subset of the quality of service requirement sets, the communication network is unable to meet all of their respective quality of service parameter requirements: then generating (24) at least one alternative quality of service requirement set for at least one of the quality of service requirement sets or a subset of the quality of service requirement sets for which the communication network cannot meet all quality of service parameter requirements; and At least one response message (50) is transmitted (25) to the device, wherein the message includes the at least one alternative quality of service requirement set.
7. The computer-implemented method (20) of claim 6, further comprising: A decision message (52) is received from the device, the decision message (52) including instructions for the network device to configure resources based on at least one of a quality of service requirement set selected at the device and / or at least one alternative proposal to the quality of service requirement set.
8. The computer-implemented method (20) according to one of claims 6 or 7, in, Generating at least one candidate quality of service requirement set includes: For each quality of service requirement parameter in the corresponding quality of service requirement set for which the communication network does not meet all quality of service parameter requirements: converting each quality of service requirement parameter into a quality of service requirement vector comprising a predefined number of entries; evaluating the feasibility of providing quality of service authorization in the network based on values defined by a plurality of combinations obtained from the corresponding quality of service requirement vectors; and Infeasible combinations are removed from the corresponding quality of service requirement vector.
9. The computer-implemented method (20) according to one of claims 6 to 8, in, Generating at least one candidate quality of service requirement set further comprises: For at least one corresponding quality of service requirement set where the communication network does not meet all quality of service parameter requirements: At least one quality of service requirement parameter is removed from the at least one corresponding quality of service requirement set; and / or at least one quality of service requirement parameter is added to the at least one corresponding quality of service requirement set.
10. The computer-implemented method (20) according to one of claims 6 to 9, further comprising: mapping at least one candidate proposal for the set of quality of service requirements to a corresponding nearest entry of a quality of service index; And wherein the at least one alternative proposal to the quality of service requirement set transmitted in the response message includes transmitting a corresponding most recent entry to the network device.
11. A device (50) comprising: - radio interface (52); - a processor (54); as well as - memory (56); wherein the processor (54) is configured to use at least one application function hosted by the processor to obtain one or more quality of service requirement sets of the at least one application function, wherein each quality of service requirement set defines at least one quality of service parameter requirement of a communication network that communicatively couples the device to a network device; wherein the processor is configured to transmit a request message to the network device via the radio interface, wherein the request message includes the one or more quality of service requirement sets; wherein the radio interface is configured to receive at least one response message from the network device including at least one response to the request message, wherein the At least one response message includes (i) approval of one or more quality of service requirement sets; and / or (ii) at least one alternative proposal to the quality of service requirement set; wherein the processor is configured to select at least one quality of service requirement set and / or at least one alternative proposal to the quality of service requirement set based on one or more requirements of the application function; and wherein the processor is configured to transmit a decision message to the network device via the radio interface, wherein the decision message includes instructions for the network device to configure resources based on at least one of the selected quality of service requirement set and / or at least one alternative proposal to the quality of service requirement set.
12. Network equipment, including: - Radio interface; as well as -processor; wherein the processor is configured to receive, from a device, a request message comprising one or more quality of service requirement sets, wherein each quality of service requirement set defines at least one quality of service parameter requirement of a communication network that communicatively couples the device to the network device; wherein the processor is configured to determine whether the communication network can meet all quality of service parameter requirements of the device included in each quality of service requirement set; Wherein, if for at least one of the quality of service requirement sets or a subset of the quality of service requirement sets, the communication network cannot meet all of their respective quality of service parameter requirements: The processor is configured to generate at least one alternative quality of service requirement set for at least one of the quality of service requirement sets or a subset of the quality of service requirement sets for which the communication network cannot meet all quality of service parameter requirements; and - wherein the processor is configured to transmit at least one response message to the device via the radio interface, wherein the message comprises the at least one alternative quality of service requirement set.
13. A communication system (60), comprising: - an apparatus (50A) as defined in claim 11; - a network device (BS) as defined in claim 12; - a communication network configured to communicatively couple the device to the network device.
14. The system (60) according to claim 13, in, The device is included in a vehicle, an automated guided vehicle, an Internet of Things device, or an unmanned aerial vehicle.
15. A computer program comprising computer readable instructions which, when executed on a processor, are configured to cause the processor to perform one of claims 1 to 5 or one of claims 6 to 10.