Method and device for managing communication between base station and at least one mobile communication partner, computer program and vehicle
A technology of mobile communication, cellular mobile communication, applied in the field of devices, computer programs and vehicles for managing communication between a base station and at least one mobile communication partner, capable of solving problems such as application failure, violation, etc.
Pending Publication Date: 2021-11-12
12 Cites 0 Cited by
AI-Extracted Technical Summary
Problems solved by technology
Applying this threshold to the predicted QoS profile, it can be easily seen th...
The invention relates to a method for managing communication between a base station (210) of a cellular mobile communication system and at least one first mobile communication partner (V1). The method comprises: collecting quality of service report messages from a plurality of mobile communication partners (V1-V3) registered in a communication cell managed by the base station (210), wherein collecting quality of service report messages comprises collecting quality of service report messages for direct communication between two (V3, V1) of the plurality of mobile communication partners, and further comprising generating a link-based quality of service map for communication between the base station (210) and the mobile communication partners (V1-V3), and for direct communication between two of the mobile communication partners (V3, V1). The method further comprises predicting a quality of service of communication between the base station (210) and at least one mobile communication partner (V1) based on the generated link-based quality of service map (QoS).
Network traffic/resource managementParticular environment based services +6
Quality of serviceSystems engineering +2
- Experimental program(1)
 This description illustrates the principles of the present disclosure. It should therefore be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the present disclosure.
 All examples and conditional language described herein are intended for educational purposes to assist the reader in understanding the principles of the present disclosure and the concepts contributed by the inventors to advance the art, and should be construed as not limited to such specifically recited examples and conditions.
 Thus, for example, those skilled in the art will appreciate that the illustrations presented herein represent conceptual diagrams of illustrative circuitry embodying the principles of the present disclosure.
 The functions of the various elements shown in the figures may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When functions are provided by a processor, those functions may be provided by a single dedicated processor, by a single shared processor, or by multiple separate processors (some of which may be shared). Furthermore, explicit use of the terms "processor" or "controller" should not be construed to refer exclusively to hardware capable of executing software, but may implicitly include, but is not limited to, digital signal processor (DSP) hardware, Read only memory (ROM), random access memory (RAM), and nonvolatile storage devices for storing software.
 Other conventional and/or custom hardware may also be included. Similarly, any switches shown in the figures are conceptual only. Their functionality may be implemented through the operation of program logic, through dedicated logic, through the interaction of program control and dedicated logic, or even manually, the particular technique being selected by the implementer as more specifically understood from the context.
 In the claims herein, any element described as a means for performing the specified function is intended to encompass any manner of performing the function, including, for example: a) a combination of circuit elements that perform the function; or b) any form software, thus including firmware, microcode, etc., in combination with appropriate circuitry for executing the software to perform the function. The disclosure as defined by such claims resides in the fact that the functionalities provided by the various recited means are combined and brought together in the manner which the claims call for. Accordingly, any components capable of providing those functions are considered equivalent to those shown herein.
 figure 1 The proposed system architecture is shown. Reference numeral 10 denotes user equipment. The depicted user equipment is exemplified as a vehicle, and more specifically, a car. In other examples, it may be instantiated differently, such as a smart phone, smart watch, tablet, notebook or laptop, and the like. Shown is a passenger car. If exemplified by a vehicle, it could be any type of vehicle. Examples of other types of vehicles are: buses, motorcycles, commercial vehicles, especially trucks, agricultural machinery, construction machinery, rail vehicles, etc. The use of the present invention will generally be possible in land vehicles, rail vehicles, water vehicles and aircraft. The vehicle 10 is equipped with an onboard connectivity module 160 that includes a corresponding antenna so that the vehicle 10 can participate in any form of mobile communication service. figure 1 It is illustrated that the vehicle 10 can transmit and receive signals to and from the base station 210 of the mobile communication service provider.
 Such a base station 210 may be, for example, an eNodeB base station of an LTE (Long Term Evolution) or 5G mobile communication service provider. The base station 210 and corresponding devices are part of a mobile communication network having a plurality of network cells, each of which is served by a base station 210 .
 figure 1 The base stations 210 in the are positioned close to the road or roads on which the vehicle 10 is driving. Of course, other vehicles can also drive on this road. In the terminology of LTE, a mobile terminal corresponds to a UE that allows a user to access network services in order to connect to the UTRAN or Evolved UTRAN via a radio interface. Typically, such a UE corresponds to a smartphone. Of course, mobile terminals are also used in the vehicle 10 . The car 10 is equipped with the on-board connectivity module OCU 160 . The OCU corresponds to an LTE or 5G communication module with which the vehicle 10 can receive movement data in the downstream direction and can transmit such data in the upstream direction.
 As far as the LTE mobile communication system is concerned, the E-UTRAN, an evolved UMTS terrestrial radio access network for LTE, consists of multiple eNodeBs to provide the UE with E-UTRA user plane (PDCP/RLC/MAC/PHY) and control plane (RRC) protocol terminal. The eNodeBs are interconnected with each other by means of the so-called X2 interface. The eNodeB is also connected to the EPC (Evolved Packet Core) 200 by means of the so-called S1 interface, more specifically to the MME (Mobility Management Entity) by means of the S1-MME, and to the Serving Gateway (S1-U interface) -GW).
 According to this general architecture, figure 1 The eNodeB 210 is shown connected to the EPC 200 via the S1 interface, and the EPC 200 is connected to the Internet 300. The backend server 320 to which the vehicle 10 can send and receive messages is also connected to the Internet 300 . In the field of collaborative and autonomous driving, the backend server 320 is typically located in a control center (CC). This also includes applications for remote-operated driving. In this context, "tele-operated driving" means that an external operator controls the vehicle remotely. External operators are located in the control center. There may be a large distance between the control center and the vehicle. The control center and the vehicles are connected via a radio communication system and their backhaul. First, the radio communication system is part of a public mobile communication system such as LTE or 5G. Tele-operated driving is a safety-relevant, time-critical application, and the requirements for information exchange are low latency, high data rates, and high reliability. ToD is seen as an enabler for automated driving because it will resolve deadlock situations where automated vehicles get caught.
 Finally, infrastructure network components are also shown. It may be exemplified by RSU 310 . For ease of implementation, it is considered that all components have been assigned Internet addresses, usually in the form of IPv6 addresses, so that packets transmitting messages between components can be routed accordingly.
 Various interfaces of the LTE or 5G network architecture are standardized. In particular, various LTE and 5G specifications are concerned, which are publicly available in order to fully disclose further implementation details.
 figure 2 An example scenario of a ToD session for one vehicle in a mobile communication cell of base station 210 is shown. figure 2 A suburban scene is depicted where multiple streets have intersections and buildings between them. Here are three vehicles, which are depicted driving on the street. The three vehicles are marked V1 to V3. Vehicle V1 has encountered a jam situation, which does not allow the automated driving functions inside vehicle V1 to continue to move. The reason for this is that the truck 12 is parked on the road in order to unload the cargo. The street is so narrow that there is not enough width left for the vehicle V1 to go over the truck. The autonomous driving function in the vehicle V1 does not permit the vehicle to be driven on the pavement to pass narrow spots. Therefore, this is a deadlock situation for vehicle V1. This requires the ToD segment required by vehicle V1. Its future path is marked with reference numeral 15 . All vehicles V1 to V3 are registered at base station 210 . The base station 210 is notified of all paths (dashed lines) from the three vehicles V1 to V3. This information is exchanged consistently among the ego vehicle and base station 210 . This also includes the exchange of position information, heading information and acceleration information, as will be explained in more detail later.
 image 3 The direct communication links Uu1 to Uu3 for communication between the base station 210 of the communication cell and the three vehicles V1 to V3 and between the vehicles V1 to V3 for acting as relay nodes towards the first vehicle V1 are illustrated The two side links of the communication link PC5.
 Figure 4 A block diagram of the on-board electronics system of the vehicle 10 is schematically shown. Part of the board electronics system is the infotainment system, which includes a touch-sensitive display unit 20 , a computing device 40 , an input unit 50 and a memory 60 . The display unit 20 includes a display area for displaying variable graphic information, and an operator interface (touch-sensitive layer) arranged above the display area for inputting commands by a user.
 The memory device 60 is connected to the computing device 40 via a further data line 80 . In the memory 60 a pictogram directory and/or a symbol directory is stored together with the pictograms and/or symbols for possible overlay of additional information.
 Other parts of the infotainment system, such as camera 150 , radio 140 , navigation device 130 , phone 120 , and instrument cluster 110 are connected to computing device 40 via data bus 100 . The data bus 100 is a high-speed variant of the CAN bus according to the considered ISO standard 11898-2. Alternatively, for example, the use of an Ethernet-based bus system such as IEEE802.03cg is another example. Also available are bus systems in which data transmission takes place via optical fibers. Examples are the MOST bus (Media Oriented System Transport) or the D2B bus (Digital Home Bus). For inbound and outbound wireless communication, the vehicle 10 is equipped with an onboard communication module 160 . The communication module 160 is commonly referred to as an on-board unit (OBU). It can be used for mobile communication, for example according to the LTE standard or the 5G standard.
 Reference numeral 172 denotes an engine control unit. Reference numeral 174 corresponds to an ESC control unit corresponding to electronic stability control, and reference numeral 176 denotes a transmission control unit. The networking of such control units usually takes place using a CAN bus system (controller area network) 104 , all these control units are assigned to the category of the drivetrain. Since various sensors are installed in motor vehicles and these sensors are no longer just connected to individual control units, such sensor data is also distributed to individual control devices via the bus system 104 .
 However, modern motor vehicles may also have additional components, such as additional surroundings scanning sensors, such as lidar (light detection and ranging) sensors 186 or radar (radio detection and ranging) sensors 182, and more video cameras , for example as a front-facing camera, rear-facing camera, or side-facing camera. Such sensors are increasingly being used in vehicles for observation of the surrounding environment. Additional control devices may be provided in the motor vehicle, such as the automatic driving control unit ADC184 or the like. Radar sensor 182 and lidar sensor 186 can be used to scan a range of up to 250 meters or 150 meters, and cameras cover a range from 30 to 120 meters. Components 182 to 186 are connected to another communication bus 102 . The Ethernet bus is the communication bus 102 of choice due to its higher data transmission bandwidth. An Ethernet bus adapted to the special needs of automotive communications is standardized in the IEEE 802.1Q specification. Furthermore, a large amount of information for surrounding environment observations can be received from other road participants via V2V communication. Especially for those road participants who are not within the line-of-sight LOS of the observing vehicle, it is very advantageous to receive information about their position and movement via V2V communication.
 Reference numeral 190 denotes an on-board diagnostic interface.
 Gateway 30 is provided for the purpose of transmitting vehicle-related sensor data to another vehicle or central computer 320 via communication module 160 . It is connected to different bus systems 100 , 102 , 104 and 106 . The gateway 30 is adapted to convert the data it receives via one bus into the transport format of the other bus so that it can be distributed in packets designated there. In order to forward this data to the outside, ie to another motor vehicle or to the control center computer 320, the onboard unit 160 is equipped with a communication interface to receive these data packets and thus convert them into transmission for the correspondingly used mobile radio standard Format. If data is to be exchanged between different bus systems, the gateway 30 takes all necessary format conversions, if necessary.
 In the considered collaborative or autonomous driving scenario, the vehicles periodically broadcast so-called collaborative awareness messages CAM, collective awareness messages CPM, and decentralized environment notification messages DENM to make them aware of what other vehicles are nearby. Collaborative awareness messages contain important status information from the vehicle making the transmission, such as position, speed, heading, acceleration data, and the like. Since CAM messages are standardized, more detailed information about CAM messages is provided in the ETSI standard ETSI EN 302 637-2. CAM information provides information about traffic flow. They are compressed and transmitted to the traffic control center 320 . Also, the planned travel route or portions of the planned travel route may be delivered to the control center in one or more CAM messages. By aggregating this data, the average number of stops or speeds can be calculated. In one example application, traffic lights may be controlled depending on traffic. CPM messages are specified in ETSI TS 103 324, see also ETSI TR 103 562 V2.1.1 (2019-12). In CPM messages, V2X vehicles equipped with local perception sensors broadcast locally perceived objects in the surrounding environment that they derive from analysis of sensor data. Since environmental sensors deliver picture setting information, typical analysis algorithms correspond to image processing algorithms, such as object recognition algorithms.
 DENM messages are therefore specified in ETSI EN 302 637-3. Such messages contain eg standardized warning messages, eg detailed information about dangerous points or traffic situations in the context of V2X communication.
 The base station 210 computer can populate the database with all this information from multiple vehicles. The base station 210 computer may further predict the QoS of Uu link communications to certain vehicles for portions of their travel routes.
 In the following, in Figure 5 The process of data aggregation and QoS prediction on the base station 210 side is explained in more detail with the help of the flow chart of . The start of the computer program is marked with the reference symbol S1. In order for the base station 210 to do this, it needs to have channel quality report messages (such as CQI/PMI/RI reports) that are periodically transmitted at certain intervals from subscribers registered in the mobile communication cell. Here, CQI means channel quality index, PMI means precoding matrix index, and RI means rank index. Using the CQI, the subscriber reports the modulation scheme and coding scheme to the base station 210 . To predict downlink channel conditions, CQI report feedback from the UE is input. CQI reporting can be based on PMI and RI messages. The higher the CQI value (from 0 to 15) reported by the UE, the higher the modulation scheme (from QPSK to 64QAM), and the higher the coding rate the base station will use to achieve higher efficiency.
 Using the PMI report, the UE indicates to the base station 210 which precoding matrix should be used for the downlink transmission determined by the RI report.
 In the RI report, the UE indicates to the base station the number of layers that should be used for downlink transmission to the UE.
 Furthermore, in addition to the conventional LTE and 5G reporting messages described above, the vehicles V1 to V3 also transmit channel quality reporting messages regarding side-link transmissions (ie, transmissions via the PC5 link). So far, these report messages have been related to traditional network metrics such as Packet Delivery Rate (PDR) and Received Signal Strength Indication (RSSI), which are often used for this purpose. Additionally, a message with information on the maximum allowable delay requirement may be reported to the base station 210 . It defines the maximum allowable duration between when information is available (by the sender) to transmit and when it is received by the receiver, eg 100 ms is its typical value.
 All of these messages are received by the base station computer 212. In step S2, multiple messages will be aggregated. In step S3, the aggregated messages will be evaluated in order to update the database 214 owned by the base station.
 An example of such a database corresponds to an overlay that informs certain QoS parameters, such as received signal strength, signal-to-noise ratio, etc., for different Uu links or PC5 links.
 An example of an overlay used for this purpose is described in the reference "Nonparametric Radio Maps Reconstruction via Elastic NetRegularization with Multi-Kernels" by M. Gutierrez-Estevez, R. Cavalcante and S. Stanczak (2018 IEEE 19th Wireless Communications International Symposium on Advances in Signal Processing (SPAWC)). This article describes the computation of the coverage map of the QoS parameter NMSE for the signal-to-noise ratio SNR, where NMSE means normalized mean squared error.
 The coverage maps described in this article can be computed based on link layer information. An example of a higher layer based QoS parameter is the PIR time, with which the coverage map can also be calculated. PIR time is defined as the elapsed time interval between two successful beacon receptions, and has been generalized in the literature as a measure that more accurately describes the level of "situation awareness" achieved on a vehicle than other parameters measure. Using the coverage map determined in step S3, the base station computer calculates in step S4 predicted QoS parameters for the different Uu and PC5 links in its cell. For this purpose, planning trajectories that have also been delivered to the base station 210 during the data aggregation phase need to be used. The pQoS parameters can be predicted separately for the uplink and downlink directions. Note that different frequency ranges may be used for uplink and downlink directions, as well as different modulation schemes, etc.
 It is to be noted that technicians often distinguish between future path information, eg in the form of a navigation route, and trajectory information. Here, trajectory information is considered to be a very accurate description of where the object will be in the future, both in time and space. In the field of vehicle driving maneuvers, the trajectory is usually valid for the next 10 seconds.
 A future path like a GPS track is not as accurate in space and time, but lasts longer, i.e. it can have a validity of minutes or hours.
 Therefore, for the prediction of QoS parameters, whether trajectory information or future path information is used makes a difference in accuracy.
 about figure 2 In the scenario described in, in step S4, the base station computer 212 predicts the coverage that the vehicle V1 will experience on the planned trajectory 15, and it does the same for the vehicles V2 and V3. Figure 6a The pQoS profile of the Uu1 link is shown. Figure 6b The pQoS profile of the Uu3 link is shown. Figure 6c The pQoS profile of the PC5 link for direct communication between vehicles V3 and V1 is shown. The pQoS parameter marked along the ordinate is the received signal power. However, it should be noted that different QoS parameters, such as Doppler compensation information, delay information, data rate information, throughput information, packet error rate information, signal-to-noise ratio, and packet reception interval ( PIR). Along the abscissa, time information is marked.
 In step S5, it is checked whether a request for support by the ToD link has been received from any of the vehicles V1 to V3 registered at the base station 210 . If not, the procedure ends in step S11. If so, if the pQoS profile is above the threshold Th, then the vehicles requiring the ToD session will be checked. exist figure 2 In the scenario of , the vehicle V1 will send the request for the ToD link as explained above. Here, ToD applications require minimum received signal power or minimum requirements for different pQoS parameters such as PIR time, etc. If this threshold is likely to be violated based on the pQoS profile, the base station 210 evaluates whether it can establish relay support via other nodes (vehicles, roadside units 310, traffic lights, etc.) to increase received power. exist Figure 6a It can be seen that the pQoS profile of the Uu1 link violates the minimum requirement. The curve of the pQoS profile falls below the threshold Th for a certain time interval, increases again and remains above the threshold Th for another time period, and falls below the threshold for the remainder of the pQoS profile. Figure 6b The Uu3 link pQoS profile is depicted. Since vehicle V3 has the largest distance to base station 210, this pQoS profile does not meet the minimum requirements at the beginning, but is good enough for the rest of the time because vehicle V3 is approaching base station 210 according to planned trajectory 15. Figure 6c The pQoS profile for side link communication from vehicle V3 to V1 is shown. It shows a similar pattern, where it drops at the beginning and then increases to sufficient QoS because the two vehicles are approaching. Of course, the environment of the approaching vehicle also plays a role. However, this can also be considered for QoS prediction based on the information in the above CPM and DENM messages.
 The checking of the Uu link pQoS profile of the requesting vehicle takes place in step S6. If the Uu link profile meets this requirement, then a decision will be made to use the Uu link for the requested ToD link. In step S10, the corresponding entry will be set in the register memory. At the same step, a corresponding message is sent to the requesting vehicle V1 informing it of the selection. If it has been found in step S6 that the pQoS profile does not meet the minimum requirements, it follows in step S7: testing the possibility of using relays to meet the minimum requirements of the requested ToD session. The base station 210 needs to know if the side link communication between V1 and another vehicle can be used to guarantee the minimum requirements of the ToD link. This is not always possible. In particular, since in the case of relaying, some more delay will be added to the communication process, relaying may not be an option even if the received signal power is good enough. This is why the higher-level metric "packet reception interval" is a better choice for determining the pQoS profile. Preferably, step S7 includes the step of: calculating a combined pQoS profile from the profiles of the Uu3 and PC5 (V3, V1) links. Figure 6d The resulting pQoS profiles for the combination of Uu3 and PC5 (V3, V1) links are shown. like Figure 6a As seen in and 6d, when the Uu1 link profile falls below the threshold Th, the combined profile exceeds the threshold Th. This shows that relaying can help maintain the ToD session for the portion of trajectory 15 for which vehicle V1 has requested ToD support. In step S8, it is checked whether the combined profile for the relay is likely to be used at the part of the trajectory where the Uu1 pQoS profile falls below the threshold Th. If not, the procedure ends in step S11. If the result in query S8 is that the two profiles are complementary to each other, it follows in step S9 the following operations: setting the corresponding entry in said register memory and sending a message to the requesting vehicle V1. The ToD session will be invoked by the vehicle V1 by sending a ToD session request message to the backend server 320 in the control center.
 Figure 7 The exchange of messages between the control center with the backend server 320, the base station, and the involved vehicles V1 and V3 is shown. First, the vehicle V1 requiring ToD support sends a request to the base station 210 for a predicted QoS profile. If the pQoS profile is good enough, the base station 210 replies with a message using the Uu link for ToD link communication, or if it is not good enough, the base station 210 replies with a message using relay support. After this, the vehicle V1 invokes the ToD session by sending a message to the backend server 320 in the control center. The backend server 320 starts sending ToD messages to the base station 210 . Base station 210 uses Uu link or relay support for exchanging ToD messages with vehicle V1.
 It should be understood that the presented methods and apparatus may be implemented in various forms of hardware, software, firmware, special purpose processors, or combinations thereof. Special purpose processors may include application specific integrated circuits (ASICs), reduced instruction set computers (RISCs), and/or field programmable gate arrays (FPGAs). Preferably, the proposed method and apparatus are implemented as a combination of hardware and software. Furthermore, the software is preferably implemented as an application program tangibly embodied on a program storage device. The application can be uploaded to and executed by a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (CPUs), random access memory (RAM), and input/output (I/ O) Interface. The computer platform also includes an operating system and microinstruction code. The various processes and functions described herein may be part of the microinstruction code or part of the application program (or a combination thereof) executed via the operating system. Additionally, various other peripheral devices may be connected to the computer platform, such as additional data storage devices and printing devices.
 It should be understood that the elements shown in the figures may be implemented in various forms of hardware, software, or combinations thereof. Preferably, these elements are implemented in a combination of hardware and software on one or more suitably programmed general purpose devices, which may include a processor, memory and input/output interfaces. As used herein, the phrase "coupled" is defined to mean directly connected to, or indirectly connected through one or more intermediate components. Such intermediate components may include hardware and software based components.
 It will be further appreciated that since some of the constituent system components and method steps depicted in the figures are preferably implemented in software, the actual connections between system components (or process steps) may be programmed depending on the proposed method and apparatus different ways. Given the teachings herein, one of ordinary skill in the relevant art will be able to contemplate these and similar implementations or configurations of the presented methods and apparatus.
 List of reference symbols
 10 vehicles
 12 trucks
 15 Planning track
 20 touch screen
 30 Gateway
 40 Computing Devices
 50 Operating element unit
 60 memory cells
 70 Data cable to display unit
 80 Data lines to memory cells
 90 Data line to operating element unit
 100 First communication bus
 102 Second communication bus
 104 Third communication bus
 106 Fourth communication bus
 110 Multifunction Display
 120 Phone
 130 Navigation system
 140 Radio equipment
 150 cameras
 160 Onboard Communication Unit
 172 Engine Control Unit
 174 Electronic Stability Control Unit
 176 Transmission control unit
 182 Radar sensors
 184 Autopilot control unit
 186 Lidar Sensors
 190 Onboard Diagnostic Unit
 200 Evolved Packet Core
 210 base station
 212 Base Station Computer
 300 Internet
 310 Roadside Unit
 320 backend server
 PC5 (V2, V1) First PC5 communication link
 PC5 (V3, V1) Second PC5 communication link
 Uu1-Uu3 Uu communication link
 V1-V3 Vehicles
 S1-S11 Various method steps of a computer program.
Description & Claims & Application Information
We can also present the details of the Description, Claims and Application information to help users get a comprehensive understanding of the technical details of the patent, such as background art, summary of invention, brief description of drawings, description of embodiments, and other original content. On the other hand, users can also determine the specific scope of protection of the technology through the list of claims; as well as understand the changes in the life cycle of the technology with the presentation of the patent timeline. Login to view more.