Method for configuring a communication system based on analyzing compliance with a set of reliability requirements for a service

Abstract

The present invention relates to a method (100) for configuring a communication system based on an analysis of compliance with a set of reliability requirements for a service, the method comprising the following steps performed by a service provider (10): - receiving (101) a service request from a service function (20), the service request specifying a set of reliability requirements for one or more quality of service parameters relative to the requested service; - analyzing (102) compliance with the set of reliability requirements for one or more quality of service parameters relative to the service request from the service function (20); - configuring (103) a communication system assigned to the service provider (10), wherein the configuration (103) is based on the analysis (102) of compliance with the information provided for the requested service.

Description

Technical Field

[0001] This invention relates to a method for configuring a communication system based on analysis of compliance with a set of reliability requirements for a service. Furthermore, this invention relates to computer programs, apparatus, and storage media for this purpose. Background Technology

[0002] Exchanging V2X messages via V2X communication typically allows vehicles and / or infrastructure components to exchange information, enabling improvements to existing safety-critical applications and the development of new ones to enhance traffic safety and efficiency, driver comfort, and the reliability of existing driver assistance and automated driving applications. Examples may include cooperative automated cruise control (C-ACC) or V2X-based collision warnings (e.g., due to traffic congestion ahead or pedestrians crossing the road).

[0003] In current driving functions supported by V2X data, the driver is still responsible for reacting to V2X information. For example, they can decide whether to react or gradually reduce speed based on a collision warning without a safety level. Due to the lack of safety features and performance guarantees in V2X communication, vehicles cannot directly use V2X data for safety-critical driving operations, such as triggering hard braking (Automatic Emergency Braking, AEB) or steering maneuvers. If V2X information can be trusted and taken as input from a safety perspective, then regardless of the AD level, an AD vehicle can automatically react based on V2X information, such as performing hard braking or other difficult maneuvers (such as swerving).

[0004] WO2022 / 122450 A1 describes the inclusion of a "safety section" in V2X messages to enable their use for safety-related driving functions. This safety section may include safety levels, failure rates, development process indications, effective timeframes, error models, and / or confidence levels of V2X data.

[0005] US20190051151 A1 describes a control device that uses statistical methods to determine the reliability of received V2X data.

[0006] US2021255617 AA describes a method for adapting remotely driven (ToD) controls to predictive Quality of Service (pQoS) values ​​to comply with functional safety.

[0007] Reliability is often another aspect of security, and it is associated with the concept of Quality of Service (QoS). QoS guarantees are typically provided only for areas controlled by the communication network. Therefore, if a security-critical application entity communicates end-to-end via multiple communication technologies, the QoS guarantees provided by a single network (such as a 5G network) only consider a subset of the end-to-end communication.

[0008] Therefore, end-to-end awareness and control mechanisms are still required at the application or communication service level. Typically, having a comprehensive (overarching) communication network control mechanism outside the system is impractical, especially for communication services provided in wide area networks. Therefore, security-critical applications primarily rely on their own end-to-end monitoring mechanisms.

[0009] Therefore, the object of the present invention is to at least partially overcome the above-mentioned disadvantages. In particular, the object of the present invention is to provide a method for enabling applications to achieve the reliability required to support safety-critical applications. Summary of the Invention

[0010] According to aspects of the invention, there is provided a method having the features of claim 1, a computer program having the features of claim 9, a data processing apparatus having the features of claim 10, and a computer-readable storage medium having the features of claim 11. Further features and details of the invention are disclosed in the corresponding dependent claims, the specification, and the drawings. The features and details described in the context of the method of the invention also correspond to the computer program of the invention, the data processing apparatus of the invention, and the computer-readable storage medium of the invention, and vice versa in each case.

[0011] According to an aspect of the invention, a method is provided for configuring a communication system based on analysis of compliance with a set of reliability requirements for a service, the method comprising the following steps implemented by a service provider: - Receive service requests from service functions, which specify a set of reliability requirements for one or more quality of service parameters relative to the requested service. - Analyze compliance with a set of reliability requirements relating to one or more quality of service parameters from a service request originating from a service function. - Configure the communication system assigned to the service provider, where the configuration is based on an analysis of compliance with the information provided for the requested service.

[0012] The service request function can be represented by an application, which preferably requests the service from the service provider with a specific reliability relative to one or more QoS parameters of the requested service. The service provider can be represented by another application adapted to provide one or more services and receive service requests from the service function. The service function and / or service provider can be embodied in a data processing apparatus, which may optionally consist of network elements (e.g., user equipment, base stations, access points, or core network elements) or a cloud computing system.

[0013] The advantage lies in enhancing the reliability and efficiency of communication networks, such as V2X communication networks, based on the methods of this invention. By explicitly defining service requirements and allowing for analysis, service providers or applications can dynamically adjust their needs based on available service capabilities or the capabilities of the service provider. This approach advantageously supports collaboration between providers or applications and improves efficient resource utilization within the network. Furthermore, its overall compatibility allows for seamless interoperability across different systems and vendors, thereby building a more robust and interconnected communication ecosystem.

[0014] It is also possible that the service provider receives service requests and / or any other messages and / or notifications via a dedicated interface of the communication network.

[0015] It is also possible that this dedicated interface could be designed as an air interface.

[0016] It is possible that the method also includes: - Receive a negotiation request from a service function based on a received rejection message, which requests relaxation of one or more reliability requirements from a set of reliability requirements to enable the service to be provided based on the service function’s capabilities and / or limitations; - Based on the received negotiation request, initiate a negotiation process with the service function regarding relaxing one or more reliability requirements of the requested service.

[0017] This allows for negotiation of reliability requirements specified by service functions, enabling service providers (such as applications) to dynamically adjust their systems based on these requirements. Furthermore, it facilitates collaboration between service providers and service functions(s) or applications(s). Additionally, it advantageously improves the efficient utilization of resources within the communication network. Moreover, the advantage lies in the ability of service providers to adapt their systems to the requirements of service functions.

[0018] It is also possible that, during the initiated negotiation process, the method may also include: - Receive additional information from the service function regarding its capabilities and / or limitations. - Analyze additional information and the initially specified set of reliability requirements relative to one or more service quality parameters to specifically determine a new set of reliability requirements. - Based on the analysis, identify one or more simplifiable reliability requirements.

[0019] The advantage of this approach is that service providers can adapt their capabilities to the requirements of the service function. This allows for a more flexible and dynamic negotiation process, leading to a higher likelihood of reaching a mutually satisfactory agreement. Analyzing information about limitations and reconfiguration options enables the service function to make informed decisions about which reliability requirements are most critical and which can be relaxed without compromising security and reliability. This iterative approach significantly enhances the efficiency and effectiveness of the negotiation process, ultimately resulting in a more successful outcome for both the service provider and the service function.

[0020] It is also possible that, once determined, the method may include: - Based on one or more simplifiable reliability requirements identified, send a new set of reliability requirements to be agreed upon to the service function.

[0021] This allows service providers to send an updated set of service quality requirements to service functions, reflecting agreed-upon relaxations. This allows for a final agreement on the parameters for providing the requested service, ensuring that the needs of both parties are met within the constraints of available resources and capabilities.

[0022] It is also possible that the method includes: - Receive confirmation messages from service functions for providing services based on the new set of reliability requirements. - When the analysis shows that the new set of reliability requirements can be met, the requested service is provided to the service function via the communication channel.

[0023] The advantage of this is that a successful agreement can be reached between the service provider and the service function. This agreement prompts the service provider to confirm its ability to provide the requested service based on a revised set of service quality requirements agreed upon during the negotiation process. The confirmation message indicates that the service provider can now meet the request with the adjusted parameters.

[0024] It is also possible that the service request further specifies the fault definition and / or the time window for providing the requested service.

[0025] The advantage of this is that service functions can specify various aspects related to the performance and availability of the service. This allows for finer-grained control over service requests, enabling service functions to clearly define their expectations regarding reliability, latency, bandwidth, and other key parameters. Furthermore, by specifying fault definitions, service functions can outline the acceptable level of error handling and recovery mechanisms within the service. Providing a defined time window for the service allows service functions to indicate to the service provider the specific time periods during which service is required, thus enabling the service provider to plan and allocate resources accordingly.

[0026] It is also possible that service requests are sent via unicast, multicast, or broadcast.

[0027] This allows for sending and receiving service requests using various transport methods, such as unicast communication for direct interaction between two entities (e.g., a service function and a service provider); multicast communication for sending messages to specific recipient groups (e.g., service provider groups); and broadcast communication for propagating information to all connected entities within the communication network (e.g., potential service providers). This flexibility allows service functions to select the most appropriate transport method based on the specific requirements of the service request and the intended recipient.

[0028] It is also possible that the method includes: - If the service function confirms that it will provide the requested service, send an acceptance message to the service function.

[0029] The advantage of this approach is that, upon successful negotiation and agreement regarding relaxed reliability requirements, the service provider sends a confirmation message to the service function. This message confirms acceptance of the adjusted service requirements and instructs that preparations be made for service provision. This step completes the negotiation process and allows the service provider to begin fulfilling the requested service based on mutually agreed terms.

[0030] In another aspect of the invention, a computer program, particularly a computer program product, can be provided, comprising instructions that, when executed by a computer, cause the computer to perform the method according to the invention. Thus, the computer program according to the invention can have the same advantages as those described in detail with reference to the method according to the invention.

[0031] In another aspect of the invention, an apparatus for data processing can be provided, configured to perform the method according to the invention. For example, the apparatus may be a computer configured or adapted to execute a computer program according to the invention. The computer may include at least one processor capable of executing the computer program. Furthermore, a non-volatile data memory may be provided in which the computer program can be stored, and which the computer program can be read from the memory by the processor for implementation.

[0032] According to another aspect of the invention, a computer-readable storage medium can be provided, comprising a computer program and / or instructions according to the invention, which, when executed by a computer, cause the computer to perform the steps of the method according to the invention. The storage medium can be formed as a data storage device, such as a hard disk and / or non-volatile memory and / or memory card and / or solid-state drive. For example, the storage medium can be integrated into a computer.

[0033] Furthermore, the method according to the invention can be implemented as a computer-based method. Alternatively or additionally, at least one of the disclosed method steps can be computer-implemented and / or automated. Attached Figure Description

[0034] Further advantages, features, and details of the invention will become apparent from the following description, in which embodiments of the invention will be described in detail with reference to the accompanying drawings. In this context, the features mentioned in the claims and specification may be essential to the invention individually or in any combination. As shown: Figure 1 The methods, computer programs, storage media, and apparatus according to embodiments of the present invention Figure 2 : A schematic diagram of an exemplary process according to an embodiment of the present invention. Detailed Implementation

[0035] In the following figures, the same reference numerals are used for the same technical features, even for different embodiment examples.

[0036] Figure 1 Methods, computer programs, storage media, and apparatus according to embodiments of the present invention are illustrated. In particular, Figure 1 A method 100 for analyzing compliance with a set of reliability requirements for a service is described. Method 100 includes the following steps implemented by a service provider 10: In step 101, a service request is received from a service function 20. The service request specifies a set of reliability requirements relative to one or more quality of service parameters of the requested service. In step 102, compliance with the set of reliability requirements relative to the service request from service function 20 is analyzed. Then, in step 103, a communication system is configured based on the analysis 102 regarding compliance with the information provided for the requested service.

[0037] also, Figure 1 The diagram also shows a data processing device 10 or service provider 10, a computer-readable storage medium 15, and a computer program 50.

[0038] Figure 2A schematic diagram of an exemplary process according to an embodiment of the present invention is shown. Figure 2 In the embodiment illustrated herein, service provider 10 includes, for example, application B, and service function 20 includes, for example, application A. Figure 2 The exemplary process illustrated shows a request from application A to application B for a specific reliability requirement relative to one or more Quality of Service (QoS) parameters to support, for example, a Vehicle-to-Everything (V2X) service.

[0039] Application A, acting as service function 20, sends a service request 201, relative to one or more Quality of Service (QoS) parameters, to a second application B, acting as service provider 10 (e.g., via a dedicated interface of a communication network). In other words, service provider 10 may receive the service request 201, which specifies a set of reliability requirements for one or more QoS parameters relative to the requested service. The transmission of the service request 201 can be performed by service function 20 as unicast communication. Alternatively, application A (service function 20) may also send 201 or transmit its service request 201 to multiple applications via broadcast communication. The service request may include information and / or message format further described below.

[0040] Application B, acting as service provider 10, can analyze the service request (202) and provide responses (203a, 203b) to application A. Upon acceptance, application B parameterizes (205) its communication system for the communication link or channel between application A and application B. This means that application B (service provider 10) is able to support the requested service and meet reliability requirements.

[0041] In other words, service provider 10 (application B) can respond to the service request 203a, 203b with respect to its ability to meet the reliability requirements. For example, regarding the requested time interval (step 203b), application B can respond that it can currently meet the reliability requirements without limitation (step 203a).

[0042] This also means that service provider 10 can send a response message 203b to service function 20 or application A, which includes information that it meets only a finite subset of reliability requirements or application requirements within a specific time interval. In the worst case, the subset may be zero, meaning that application B cannot meet the reliability requirements. Furthermore, when application B uses 5G-RAT (Radio Access Technology), application B can determine whether it can meet the reliability requirements by reserving Radio Access Network (RAN) resources. Moreover, as a service provider, application B can also determine whether it can meet the requirements based on observation 207 of the current channel conditions, especially when using unmanaged communication technologies.

[0043] If application B, as service function 20, responds to application A at 203a, then no further coordination or negotiation is required, and application B, as service provider 10, can operate 206 on the communication network as requested, meaning the requested service is provided. If application B responds according to step 203b, then application A, as service function 20, can initiate or begin a negotiation process to determine a set of alternative reliability requirements that conform to application B's current capabilities. Figure 2 (not shown).

[0044] During the negotiation process, application A, as service function 20, may relax, for example, its reliability parameters relative to one or more quality of service parameters and / or fault definitions and / or time windows, taking into account its internal security and reliability requirements and internal reconfiguration options. A fault can be understood as a point in time during which one or more requirements in the set of QoS parameters / functional requirements are not met. QoS parameters / functional requirements are themselves defined as predefined communication properties and thresholds (value + unit) that must be observed.

[0045] Furthermore, service provider 10 can exchange information that service function 20 can use to select the most promising reliability requirement relaxation. For example, if service provider 10 is already processing other service requests (e.g., within the next five seconds) but will subsequently be able to provide significant communication resources, simply shifting the requested time window might be a good relaxation option for application A, which is service function 20. The main reason why application B may not be able to provide the requested service and its corresponding QoS is due to other requesting applications competing for application B's communication capabilities and due to limited spectrum resources.

[0046] Furthermore, upon receiving a reliability request from application A, application B can transform the reliability requirements into a set of parameters specific to the communication technology, such as modulation and codec schemes (MCS), numerology, etc. Given the network-supported communication technology, application B can also reserve additional resources.

[0047] Then in step 204, application A can notify application B (service provider 10) of its acceptance or rejection of application B's response 203a, 203b.

[0048] like Figure 2 As illustrated, application B, as service provider 10, can configure its communication system to comply with the requirements of the protocol and can provide the requested services to application A.

[0049] In step 207, the service provider 10 can monitor the provision of services or data on the communication channel between the service provider 10 and the service function 20.

[0050] If the reliability requirements can no longer be met at a certain point in time, the service provider 10 may notify 208 (preferably in advance) the service function 20.

[0051] Reasons for failing to meet reliability requirements may include, for example, changes in the inter-antenna distance setting or another user in the shared medium (channel), or other requests from Application B for the same service or for another service. Furthermore, non-compliance may not be solely due to channel interference. However, Application B can detect whether it is unable to reserve appropriate resources or whether it can adapt its modulation and encoding / decoding scheme to channel conditions (e.g., path loss caused by inter-antenna distance).

[0052] Furthermore, examples of applications could be driving functions or automated valet parking functions. Examples of services could be Collective Perception Service (CPS), Collaborative Perception Service (CAS), Mobility Coordination Service (MCS), or any other service that includes exchanging messages via a communication interface.

[0053] Service requests may include the following information bundles: - List of Quality of Service (QoS) parameters - The "fault definition" for each QoS parameter, i.e., the time and magnitude deviations that are still considered acceptable from the perspective of a specific application, for example: Maximum target latency: 100ms • Fault definition: In the subsequent 5 transmissions (from application source to application sink), more than 1 transmission exceeds 100ms. • The reliability or quality of service requirement for each QoS parameter, i.e., a general reliability metric, represents the statistical probability that no failure will occur (according to the "definition of failure"), for example: MTTF>1000h; alternative metrics: failure occurrence rate (ROCOF), probability of failure on demand (POFOD). • The time window for each tuple (a tuple must include at least one QoS parameter + fault definition + reliability requirement), for example: the next 15 seconds or from date and time [start: 2023 / 05 / 21-09:05:20] to [end: 2023 / 05 / 21-09:05:35].

[0054] Here is a specific example of such information bundles: .

[0055] The first line should be understood as: In the next 30 seconds, the request includes "in the case of MTTF>1000h, the delay in more than one of the 5 transmissions shall not exceed 100ms".

[0056] By mapping QoS parameters to reliability requirements such as MTTF (Mean Time Before Failure), MTTR (Mean Time To Repair), MTBF (Mean Time Between Failures), availability, redundancy, failure rate, fault tolerance, error correction, and scalability, communication systems can be designed and evaluated to meet specific quality of service objectives.

[0057] Examples of communication characteristics or quality of service parameters may include the following: - Maximum latency - Maximum message reception interval (and / or transmission interval, or the time interval between two consecutive transmissions, or the transmission period (for periodic traffic)). - Maximum message loss within the time window - Maximum packet error rate - Maximum jitter, - Minimum bandwidth - Minimum range - Reliability (percentage of messages delivered). - Security parameters (integrity, etc.).

[0058] The above explanation of the embodiments describes the invention in the context of the examples. Of course, as long as it is technically reasonable, the various features of the embodiments can be freely combined with each other without departing from the scope of the invention.

Claims

1. A method (100) for configuring a communication system based on analysis of compliance with a set of reliability requirements for a service, comprising the following steps performed by a service provider (10): - Receive (101) a service request from service function (20), the service request specifying a set of reliability requirements for one or more quality of service parameters relative to the requested service. - Analyze (102) the compliance with the set of reliability requirements for one or more quality of service parameters relative to the service request from the service function (20). - configuring (103) a communication system assigned to the service provider (10), wherein Configuration (103) is based on analysis (102) of the conformity of the information used to provide the requested service.

2. The method according to claim 1, characterized in that, Method (100) further includes: - Receive a negotiation request from service function (20) based on the received rejection message, the negotiation request requesting relaxation of one or more reliability requirements from the set of reliability requirements to enable the service to be provided based on the capabilities and / or limitations of service function (20). - Based on the received negotiation request, initiate a negotiation process with the service function (20) regarding relaxing one or more reliability requirements of the requested service.

3. The method (100) according to claim 2, characterized in that, During the initiated negotiation process, method (100) further includes: - Receive additional information from the service function (20) regarding its capabilities and / or limitations. - Analyze additional information and the initially specified set of reliability requirements relative to one or more quality of service parameters. - Based on analysis, determine one or more simplifiable reliability requirements.

4. The method (100) according to claim 3, characterized in that, After determination, method (100) further includes: - Based on one or more simplifiable reliability requirements identified, send a new set of reliability requirements to be agreed upon to the service function (20).

5. The method (100) according to claim 4, characterized in that, Method (100) further includes: - Receive an acknowledgment message from service function (20) for providing services based on the new set of reliability requirements. - If the analysis shows that the new set of reliability requirements can be met, the requested service is provided to the service function (20) via the communication channel.

6. The method (100) according to any one of the preceding claims, characterized in that, The service request further specifies the fault definition and / or the time window for providing the requested service.

7. The method (100) according to any one of the preceding claims, characterized in that, The service request is sent (101) via unicast, multicast or broadcast.

8. The method (100) according to any one of the preceding claims, characterized in that, Method (100) further includes: - If the service function (20) confirms that the requested service is provided, send an acceptance message to the service function (20).

9. A computer program (50) comprising instructions that, when executed by a computer (10), cause the computer (10) to perform the method (100) as described in any of the preceding claims.

10. A data processing apparatus (10) comprising components for implementing the method (100) of any one of claims 1 to 8.

11. A computer-readable storage medium (15) comprising instructions that, when executed by a computer (10), cause the computer (10) to perform the steps of the method (100) of any one of claims 1 to 8.

Images