Electronic equipment, communication method and storage medium

Abstract

The invention relates to electronic equipment, a communication method and a storage medium. An electronic device for a vulnerable traffic participant (VRU), comprising processing circuitry configured to: in response to a trigger event, generate a service request message comprising an identifier uniquely identifying a terminal device of the VRU and service preference information; sending the service request message to network side equipment; and receiving the service configuration determined based on the service preference information from the network side equipment.

Description

Electronic device, communication method, and storage medium Technical Field

[0001] The present disclosure generally relates to the field of wireless communication technology. More specifically, the present disclosure relates to providing electronic devices, communication methods, and storage media suitable for communication in vulnerable road user scenarios. Background Art

[0002] The enhanced vehicle-to-everything (V2X) service application architecture, outlined in the current enhanced application layer interaction requirements, already includes vulnerable traffic users (VRUs). VRUs are users who are vulnerable in the event of a traffic accident, such as pedestrians, cyclists, and motorcyclists. In scenarios like autonomous driving and vehicle-infrastructure collaboration, VRUs need to be protected.

[0003] The European Telecommunications Standards Institute (ETSI) categorizes services and communications between VRUs, vehicles, roadside equipment (RSE), and the network into six categories. The most innovative of these are interactions between VRUs and between VRUs and RSE. However, ETSI's primary focus is pedestrian protection, so VRU protection still relies heavily on measures taken by the vehicle, roadside, or network.

[0004] The 5G Automotive Association (5GAA), a group of telecommunications and automotive companies, conducts research in various areas related to the Internet of Vehicles. Currently known research on VRUs focuses primarily on high-risk VRU areas (such as school entrances), interactions between VRUs and vehicles (such as mutual avoidance), and VRU-related information and algorithms. However, 5GAA's VRU research is primarily focused on the overall design and does not define the interactions between devices.

[0005] Currently, domestic standards cover only one VRU application scenario: VRU identification. VRU identification aims to enhance VRU awareness and avoid traffic accidents such as collisions with VRUs. This allows the system to identify slow-moving VRUs and issue vehicle warnings.

[0006] However, existing VRU-related standards, both domestically and internationally, do not consider VRUs as the active actors subject to early warnings. Therefore, there is a need to improve the communication interaction process involving VRUs. Furthermore, VRU terminal devices are sensitive to power consumption, have low positioning accuracy, and have low transmit and receive power. These factors must be considered when designing communications suitable for VRU scenarios.

[0007] Summary of the Invention

[0008] By applying one or more aspects of the present disclosure, the above needs are met.

[0009] This section provides a brief overview of the present disclosure in order to provide a basic understanding of some aspects of the present disclosure. However, it should be understood that this overview is not an exhaustive overview of the present disclosure. It is not intended to identify key or important parts of the present disclosure, nor is it intended to limit the scope of the present disclosure. Its purpose is simply to provide some concepts of the present disclosure in a simplified form as a prelude to the more detailed description that will be given later.

[0010] According to one aspect of the present disclosure, an electronic device for a vulnerable traffic user (VRU) is provided, comprising: a processing circuit configured to: generate a service request message in response to a trigger event, the service request message including an identifier uniquely identifying a terminal device of the VRU and service preference information; send the service request message to a network-side device; and receive a service configuration determined based on the service preference information from the network-side device.

[0011] According to one aspect of the present disclosure, an electronic device for a network-side device is provided, comprising: a processing circuit configured to: receive a service request message from a terminal device of a vulnerable traffic user (VRU), wherein the service request message is generated in response to a triggering event and includes an identifier uniquely identifying the terminal device of the VRU and service preference information; determine a service configuration for the VRU based on the service preference information; and send the service configuration to the terminal device of the VRU.

[0012] According to one aspect of the present disclosure, an electronic device for a vehicle is provided, comprising: a processing circuit configured to: receive a V2X warning about a vulnerable road user (VRU) from a road test unit (RSU); compare the difference between the V2X warning and a real-world scenario; and adjust the priority of the V2X warning based on the comparison result.

[0013] According to one aspect of the present disclosure, a communication method is provided, including operations performed by a processing circuit of any of the above electronic devices.

[0014] According to one aspect of the present disclosure, a non-transitory computer-readable storage medium storing executable instructions is provided. When the executable instructions are executed, the above-mentioned communication method is implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The present disclosure may be better understood by referring to the detailed description given below in conjunction with the accompanying drawings, wherein the same or similar reference numerals are used throughout the drawings to represent the same or similar elements. All drawings, together with the following detailed description, are incorporated into and form a part of this specification and are used to further illustrate the embodiments of the present disclosure and to explain the principles and advantages of the present disclosure. Among them:

[0016] FIG1 shows an exemplary system structure involving a VRU according to an embodiment of the present disclosure;

[0017] FIG2 shows an exemplary interaction process of a VRU UE access service according to an embodiment of the present disclosure;

[0018] FIG3 shows a VRU UE autonomous group management process according to an embodiment of the present disclosure;

[0019] FIG4 shows an exemplary interaction process of a VRU UE access service according to an embodiment of the present disclosure;

[0020] FIG5 shows a safety auxiliary service process based on the PC5 interface according to an embodiment of the present disclosure;

[0021] FIG6 shows a safety auxiliary service process based on the Uu interface according to an embodiment of the present disclosure;

[0022] 7A and 7B respectively illustrate an electronic device for a VRU and a communication method thereof according to an embodiment of the present disclosure;

[0023] 8A and 8B respectively illustrate an electronic device for a network-side device and a communication method thereof according to an embodiment of the present disclosure;

[0024] FIG9 shows an example block diagram of a computer that can be implemented as a terminal device or a control device according to an embodiment of the present disclosure.

[0025] FIG10 illustrates a first example of a schematic configuration of a base station according to the present disclosure;

[0026] FIG11 illustrates a second example of a schematic configuration of a base station according to the present disclosure;

[0027] FIG12 illustrates a schematic configuration example of a smartphone according to the present disclosure;

[0028] FIG. 13 illustrates a schematic configuration example of a car navigation device according to the present disclosure.

[0029] The features and aspects of the present disclosure will be clearly understood by reading the following detailed description with reference to the accompanying drawings. DETAILED DESCRIPTION

[0030] Various exemplary embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. For the sake of clarity and conciseness, not all implementations of the embodiments are described in this specification. However, it should be noted that when implementing the embodiments of the present disclosure, many implementation-specific settings can be made according to specific needs in order to achieve the developer's specific goals. In addition, it should be understood that although the development work may be complex and laborious, for those skilled in the art who benefit from the content of this disclosure, such development and disclosure are merely routine tasks.

[0031] In addition, it should be noted that in order to avoid obscuring the present disclosure with unnecessary details, only the processing steps and / or device structures closely related to the technical solutions of the present disclosure are shown in the accompanying drawings. The following description of the exemplary embodiments is merely illustrative and is not intended to limit the present disclosure and its applications.

[0032] For ease of illustration only, one or more aspects of the present disclosure may be described below in conjunction with V2X. However, it should be noted that this does not limit the scope of application of the present disclosure, and one or more aspects of the present disclosure may also be applied to various application architectures that are already in common use or will be developed in the future.

[0033] Traditional V2X scenarios typically use vehicles as the active actors. Vehicles provide information through onboard sensors, onboard terminals, and electronic tags. Multiple communication methods, including sidelinks, enable interoperability between vehicles (V2V), vehicles and pedestrians (V2P), vehicles and infrastructure (V2I), and vehicles and networks (V2N).

[0034] VRUs protecting non-pedestrians, such as pedestrians and cyclists, often act passively. However, some VRUs may possess reliable mobility capabilities, creating a need for VRU-centric communication services. Given that VRU-equipped devices may have limited energy, processing power, and positioning capabilities, VRU-specific communication requires specialized design considerations, including positioning, energy conservation, and user needs.

[0035] Figure 1 illustrates an exemplary system architecture involving a VRU according to an embodiment of the present disclosure. This system architecture can be used to implement, for example, an enhanced V2X service application architecture. It should be noted that Figure 1 illustrates only one of many possible types and arrangements of communication systems; the features of the present disclosure can be implemented in any of these various systems as needed.

[0036] As shown in Figure 1, an exemplary system may include a central sub-system (CSS), a multi-access edge computing (MEC) platform, an on-board subsystem, a road side unit (RSU), and a VRU. The central sub-system has the ability to communicate with the on-board sub-system, the road sub-system, the VRU, etc. The central sub-system has the ability to receive, store, process, and distribute global data, and is responsible for global information perception and global business policy control. Typically, the central sub-system can be implemented in a core network unit (e.g., an application function (AF)) or an application server.

[0037] The road subsystem can include one or more of the RSU, MEC platform, and roadside sensing devices. Roadside sensing devices are deployed at intersections, overpasses, main roads, and auxiliary roads. They have a specific sensing range, such as a range extending from the sidewalk at an intersection, or the junction of the non-motorized vehicle lane and the motor vehicle lane at an overpass. Equipped with sensory devices such as camera sensors, Lidar sensors, and radar sensors, roadside sensing devices have the ability to identify VRUs and vehicles within their sensing range, including the type, size, and mobility (speed and direction) of the VRUs and vehicles.

[0038] The RSU is a communication unit that has a (wired) connection with the roadside sensing equipment and the roadside MEC platform. The RSU can even be integrated with the roadside sensing equipment and / or the MEC platform. The RSU can have PC5 communication capabilities to wirelessly communicate with vehicles or VRUs within its coverage area.

[0039] The roadside MEC platform is generally deployed at a roadside location close to the RSU and related roadside sensing equipment. It records the historical trajectories of vehicles and VRUs through the road information collected by the RSU (including vehicle information, VRU information, traffic light information, etc.) and the road information captured by the roadside sensing equipment (movement information of various vehicles and VRUs, including original or processed video data streams, 3D point cloud data, etc.), and judges the risk of collision between vehicles and VRUs based on road conditions (for example, by analyzing the potential energy of the vehicle, and then judging the safety risk of a vehicle to surrounding objects). In the MEC platform, computing resources can be deployed to provide support for the computing needs of communication services (such as communication computing fusion services). As an example, the MEC platform can be implemented in a radio access network (RAN).

[0040] VRUs are diverse and include pedestrians, cyclists, motorcyclists, e-scooter riders, and drivers of powered two-wheeled vehicles. VRU terminal equipment (hereinafter referred to as VRU UE) transmits data such as the location, speed, direction, and trajectory of vulnerable traffic participants to the onboard subsystem, roadside unit (RSU), central subsystem, and multi-access edge computing platform, and receives application-layer information sent by the onboard subsystem, RSU, multi-access edge computing platform, and central subsystem.

[0041] Depending on whether the VRU UE supports V2X communication, the system is required to support A9, A10, A11, and A12 interfaces (VRU UE has V2X communication capability), or A1, A2, A3, and A4 interfaces (VRU UE does not have V2X communication capability). Interfaces A9 to A12 are all VRU-related interfaces. Interfaces A9 and A10 are based on V2X (such as LTE-V2X or NR-V2X) short-range communication technology, enabling VRU UE to communicate with RSU, vehicle equipment or other terminal equipment. Interfaces A11 and A12 are based on Uu (such as LTE Uu or NR Uu) cellular communication technology, enabling VRU UE to communicate with the central subsystem or MEC platform through the base station.

[0042] It should be noted that the term "base station" used in this disclosure is an example of a network control device and has its full breadth of general meaning. For example, in addition to the gNB and ng-eNB specified in the 5G communication standard, depending on the scenario in which the technical solutions of this disclosure are applied, a "base station" may also refer to, for example, an eNB, a remote radio head, a wireless access point, or a communication device performing similar functions in an LTE communication system. The following sections will describe in detail the application examples of base stations.

[0043] Additionally, in this disclosure, the term "UE" or "terminal device" has the full breadth of its ordinary meaning, such as a mobile phone, handheld device, media player, computer, laptop, tablet, on-board unit (OBU) or vehicle, roadside unit (RSU), or virtually any type of wireless device. In some cases, a terminal device may communicate using multiple wireless communication technologies. For example, a terminal device may be configured to communicate using one or more of GSM, UMTS, CDMA2000, WiMAX, LTE, LTE-A, WLAN, NR, Bluetooth, etc.

[0044] In this disclosure, a VRU and its terminal equipment (ie, VRU UE) may be distinguished, but it should be understood that the two may be used interchangeably in some cases. In particular, when describing a certain operation, the execution entity being a VRU or a VRU UE has the same meaning.

[0045] According to the embodiments of the present disclosure, in order to enable VRU to participate in smart transportation (such as vehicle-road-cloud collaboration) as an execution entity, it is proposed to take VRU as the main perspective and VRU security requirements as the main appeal, considering the communication interaction between VRU UE and RSU, vehicle and / or network (core network, central cloud, etc.).

[0046] Figure 2 shows an exemplary interaction process of a VRU UE access / registration service according to an embodiment of the present disclosure. In this example, the VRU UE has V2X communication capabilities, thereby being able to communicate with, for example, RSUs and vehicle equipment over short distances using a PC5 interface.

[0047] As shown in FIG. 2 , the process may start at step S1 , where the VRU UE generates a service request message in response to a triggering event in order to register for services applicable to the VRU.

[0048] According to the embodiments of the present disclosure, the VRU UE's request for service is triggered by a specific event instead of always searching for an RSU, which helps to save power of the VRU UE.

[0049] In one example, the triggering event includes the VRU UR receiving a broadcast message from the RSU, as shown in step S0 in Figure 2. The RSU sends the broadcast message via the PC5 interface (e.g., the A10 interface in Figure 1), so that when the VRU UE is about to enter or is entering the coverage area of ​​the RSU, it can trigger the upper layer application function of the VRU UE to generate a service request message.

[0050] As shown in Example 1a in FIG2 , the RSU may periodically send broadcast messages to its coverage area to notify surrounding VRU UEs and vehicle equipment of its presence.

[0051] In different examples, the RSU can cooperate with other functional entities to trigger the sending of broadcast messages to the VRU UE. For example, Figure 2 lists several exemplary cases:

[0052] 1b) The roadside sensing device associated with the RSU detects that a new VRU has entered its sensing range and sends this information to the RSU, which triggers the RSU to send a broadcast message to the VRU UE;

[0053] 1c) The RSU receives a Basic Safety Message (BSM) / Personal Safety Message (PSM) / VRU Awareness Message (VAM) sent by the VRU UE (e.g., periodically), and learns that a VRU is nearby, thereby triggering the sending of a broadcast message to the VRU UE.

[0054] 1d) The RSU receives a BSM / PSM / VAM message from a vehicle device. The message contains information about the vehicle sensing the VRU and the presence of the VRU in a specific area, triggering the sending of a broadcast message to the VRU UE.

[0055] 1e) The RSU receives an instruction from a core network unit (eg, application function AF) or an application server. The core network unit or application server learns based on the location information of the VRU UE that the VRU is about to enter the coverage of the RSU, thereby triggering the RSU to send a broadcast message to the VRU UE.

[0056] In addition to receiving the broadcast message of the RSU, the VRU UE may additionally or alternatively detect the following situations as triggering events (not shown in FIG2 ):

[0057] a) The VRU UE receives and analyzes data sent by surrounding vehicles / roadside equipment (e.g., vehicle location information, speed information, and direction information contained in BSM / PSM / VAM messages) through the PC5 interface. It discovers that vehicles around it are approaching at a certain speed, putting the VRU at a certain safety risk.

[0058] b) The VRU UE receives an indication from the core network unit or a specific application server via the Uu interface. For example, the core network / base station detects that the VRU UE is near a high-risk area through tracking, thereby triggering the VRU UE to actively search for nearby service providers. Additionally, the core network / base station may indicate to the VRU UE the device ID or IP address of a specific RSU nearby to facilitate the VRU UE's search for the specific RSU device.

[0059] c) Based on its location information and electronic map, the VRU UE discovers that the VRU is about to enter or is entering a high-risk area, such as an intersection, a road junction, a high-accident section, or a side road;

[0060] d) When the battery level of the VRU UE is lower than a certain threshold, the roadside equipment needs to provide related auxiliary services, such as requiring the RSU to provide positioning assistance, switching from active self-safety analysis and monitoring to passive MEC safety analysis and monitoring, etc.

[0061] It should be noted that the above situation is merely exemplary and not restrictive, and the VRU UE may trigger a service request according to other situations, for example, a pedestrian or a non-motor vehicle driver may actively instruct the VRU UE to seek auxiliary services, and so on.

[0062] The broadcast message sent by the RSU to the VRU UE may include various information about the services supported by the RSU, including but not limited to: the service content that the RSU can provide, including service types (such as collision avoidance / road risk warning, cooperative intersection lane change, positioning assistance, message relay / aggregate forwarding, etc.), and the service content corresponding to each service type (such as coverage, positioning accuracy, etc.); the communication settings that the RSU can support for each service, such as the communication interval / frequency (not a fixed value, preferably, there can be a list of several optional frequencies for a certain service type), communication coverage (different service types may correspond to different ranges), etc.

[0063] In response to the above triggering event, the VRU UE may generate a service request message for accessing the service according to the application service requirements / device configuration. As an example and not a limitation, the service request message may include at least:

[0064] - The device identifier of the VRU UE is used to uniquely identify the VRU UE in subsequent interactions. The device identifier is not limited to the VRU UE's own identifier, such as a 3GPP identifier such as the Subscription Permanent Identifier (SUPI). It can also include: the device application identifier of the upper-layer application running on the VRU UE; other identification information associated with the VRU, such as a fixed Internet of Things (IoT) device ID such as an RFID, which can be bound to devices such as bicycles and electric vehicles and their users;

[0065] -Service preference information, including various information about the services that the VRU wishes to access. For example, the service preference information may indicate at least one of the following:

[0066] The type of service the VRU desires, for example, includes at least one of the following: collision avoidance / road risk warning service, which alerts the VRU to potential collision risks or other road hazards; cooperative intersection and lane change service, which helps the VRU complete intersections and lane changes; positioning assistance service, which assists the VRU in positioning through GNSS, Bluetooth, BWP, etc.; and message relay / aggregate forwarding service, in which the VRU requests the RSU to forward its messages to expand their message coverage.

[0067] ● The communication mode used for each service, including transmit only (Tx only), receive only (Rx only), and transmit and receive (Tx+Rx). The communication mode here does not correspond to the communication capabilities of the VRU UE, but rather the communication mode of the VRU UE in the service after the RSU, which can be adjusted according to the specific application or service content, or over time. The communication mode can also have a finer granularity, such as the frequency of data packet transmission and reception of the VRU UE. In the case of multiple services, these services can share the same communication mode or have different communication modes;

[0068] ●The way the VRU receives warning prompts, such as the VRU UE triggering vibration, voice, displaying text / animation prompts, etc. after receiving the RSU warning prompt message. Different prompt methods may affect the determination of different Time-To-Collision (TTC) thresholds and other risk determination methods, and even affect whether the RSU prompts the VRU UE in different situations. For example, compared with vibration, voice prompts may take slightly longer, while displaying text or animations may take even longer. In addition, if the VRU displays text prompts for bicycles / electric vehicles, and the safety risk is a forward collision risk, especially the vehicle directly in front of the lane, then the VRU's attention should not be distracted from the forward field of view. However, in the case of rear / side collision risks, you can choose to trigger a reminder for the VRU;

[0069] Trigger conditions for the VRU to receive risk warnings include warning distance (how close the vehicle is to the VRU), warning potential threshold (a potential risk value calculated based on multiple factors such as the vehicle's current speed, mass, and braking force), TTC predicted collision value (trajectory prediction), vehicle loss of control warning, and warning of cargo risks (such as steel pipes, rebar, and flammable and explosive items). Extreme VRUs can be set to never receive warnings, allowing the RSU and vehicle to collaborate to ensure VRU safety.

[0070] Optionally, the service request message may also include other information required by the service, such as:

[0071] -VRU type, such as pedestrian, cyclist, moped rider, motorcycle rider, etc.;

[0072] - Information on the mobility and braking force of the VRU, mainly for non-motorized vehicles such as electric vehicles, motorcycles, and bicycles. Based on information such as the VRU type, the model of the non-motorized vehicle, and its age, the mobility performance (acceleration, deceleration, steering, etc.) and braking performance of the vehicle can be roughly determined.

[0073] -VRU UE positioning capabilities, such as positioning method, positioning accuracy, confidence level, etc.

[0074] - The predetermined trajectory / route of the VRU UE, such as the navigation route set by the user in a navigation application.

[0075] In the example where the VRU UE receives a broadcast message from the RSU, the VRU UE may preferably refer to the information contained in the broadcast message to generate a service request message. Based on the RSU broadcast message, the VRU UE may learn which services the RSU supports and the service content and / or communication settings for each service. The VRU UE may then determine the services and their settings required by the VRU UE, thereby improving the efficiency of service customization.

[0076] In step S2 shown in FIG. 2 , the VRU UE may send the generated service request message to the RSU via, for example, the PC5 interface (eg, the A10 interface in FIG. 1 ).

[0077] In step S3, the RSU and related system equipment receive and parse the service request information from the VRU UE and determine the service configuration for the VRU UE. The execution entity of this step may vary depending on the system architecture and service type. For example, in an architecture where the MEC platform assumes the majority of management and computing functions, the RSU may forward the VRU UE's service request message to the MEC platform, which can then determine the service content and / or service communication settings for the VRU UE. If the RSU has sufficient computing resources and the service is primarily provided by the RSU, the RSU may also perform the determination step independently.

[0078] Specifically, the RSU or MEC platform can determine the service configuration based on the VRU's service preference information and optional other information included in the service request message, where the service configuration may include, for example, the type, content, and communication settings of the service determined for the VRU. The VRU's service preference information indicates the VRU's preference for the service, so the RSU or MEC platform can mainly implement service customization based on this information.

[0079] For example, in a non-limiting example where a VRU requires a collision avoidance warning, a corresponding collision avoidance warning service can be customized for the VRU, including when the warning is triggered (e.g., when a vehicle approaches a certain range of the VRU), the warning prompt method (e.g., voice), the communication mode (e.g., VRU UE only receives), the warning (message) period / frequency (e.g., once every 10 seconds), etc. However, depending on different service types, the RSU or MEC platform may also refer to various information, such as the VRU's location information, mobility information, device capability information reported by the VRU UE, navigation data, real-time road conditions obtained from roadside sensing devices, etc.

[0080] Preferably, the RSU or MEC platform also has the ability to update communication settings (e.g., communication period / frequency) based on real-time changes in the above information, and send the updated communication settings to the VRU UE. For example, when the VRU enters the sensing range of the roadside sensing device associated with the RSU and is in a relatively safe area such as a sidewalk, as the VRU gradually approaches an intersection or the VRU's trajectory cuts into a cross-road, the VRU may face different degrees of risk in different environments. In this case, the frequency at which the VRU UE reports its own location and the service content may need to be changed. For example, the VRU UE only sends messages at a low frequency in a low-risk area and only opens a short receiving window, while the receiving window needs to be extended when the VRU UE is in a high-risk area.

[0081] According to some embodiments of the present disclosure, determining a service configuration for a VRU includes implementing group management of the VRU. One purpose of group management is to group and uniformly manage VRUs with the same or similar communication behaviors and communication requirements. The core content is to provide the same or similar service content to the grouped VRU UEs. For example, after grouping according to risk level, different levels of security monitoring can be performed on VRUs at different risks. For example, MEC computing power is focused on security monitoring allocated to higher-risk VRUs, providing high-priority and high-frequency data communication services.

[0082] The RSU or MEC platform can implement grouping based on various factors, including but not limited to at least one of the following:

[0083] - Group VRUs based on their current location, mobility, or type, capabilities, and physical information. For example, an RSU at a street intersection can group pedestrians on the sidewalk, non-motorized vehicles on the non-motorized vehicle lane, and motorcycles / electric motorcycles / powered tricycles on the motorized vehicle lane. Or, for example, multiple pedestrians within the sensing range of a roadside sensing device can be divided into multiple groups based on the historical overlap / intention of their movement trajectories. Or, for example, bicycles on the non-motorized vehicle lane can be grouped based on their speed.

[0084] - Group VRUs based on their current risk level. For example, VRUs with few nearby vehicles are defined as low-risk, bicycles, electric vehicles, and other VRUs near motorway lanes are classified as medium-risk, and VRUs with collision risks or those about to intersect with motor vehicles are classified as high-risk. Risk level grading and management processes enable online member access, member risk analysis and monitoring, and member risk alerts / traffic instruction interventions. Prompt messages can be sent to the entire group accurately and efficiently.

[0085] - Grouping based on VRU service type and transceiver type. There are two causal relationships in grouping based on transceiver type: first, the VRU UE itself (whether at the software or hardware level) sets its own transceiver type (single-transmit, single-receive, or transceiver); second, grouping is based on other parameter conditions, which in turn determine the VRU UE's transceiver behavior (in this case, the VRU UE needs to be notified, and such a VRU UE can define its own communication behavior through software settings);

[0086] - VRUs are grouped / paired for collaborative tasks based on whether they are collaborating with other VRUs. For example, if the RSU receives teaming requests from VRUs in different directions willing to form a cycling team, it can pair them up. Or, when VRUs are calibrating their positions, the RSU can select multiple VRUs to perform collaborative calibration.

[0087] Alternatively, the VRU can implement self-management, that is, multiple VRU UEs can be autonomously managed as a group without intervention from the roadside equipment. Figure 3 shows a VRU UE autonomous group management process according to an embodiment of the present disclosure.

[0088] As shown in Figure 3, a specific VRU UE (e.g., VRU UE-A) can initiate group management based on its own status (battery level, transmit power, etc.). The VRU UE-A proactively broadcasts VRU grouping messages to surrounding VRU UEs based on its current location, direction of movement, and other information. The VRU UE-A is not limited to any VRU type, such as pedestrians, bicycles, electric bicycles, and tricycles. The VRU UE-A broadcast message for group management can include its location, device ID, mobility parameters, and whether it has established a connection with an RSU within its coverage area.

[0089] A VRU UE (e.g., VRU UE-N) within the broadcast range is willing to participate in group management and sends a VRU group joining request to the initiator VRU UE-A via unicast to join the group management mode. The joining request may include information such as the location of the VRU UE-N, device ID, mobility parameters, and group management validity period.

[0090] VRU UE-A parses the received join request, selects VRU UEs that can be managed in a group according to predefined criteria, and multicasts or unicasts group confirmation information to the VRU UEs in the group. The group confirmation information includes group ID, group validity period, and effective area.

[0091] The VRU UE-A becomes the manager of the VRU group, providing early warning of VRU group movement. The VRU UE-A can proactively broadcast or send VRU group mobility information to its connected RSUs. The RSUs then determine whether there is a potential collision risk between VRU group members or with vehicles. If a risk exists, the RSUs notify vehicles and VRU UEs within their coverage area (e.g., via the group manager, VRU UE-A).

[0092] When a member of a VRU group leaves or a new VRU joins, the VRU UE-A manages the group. The VRU group update result is broadcasted or sent to the RSU by the VRU UE-A.

[0093] When VRU UE-A, acting as the group manager, intends to leave the group, it can immediately disband the VRU group and proactively notify the RSU of its intention. Alternatively, VRU UE-A transfers group management rights to, for example, VRU UE-B. VRU UE-B updates the group ID and multicasts its device ID to group members. Subsequent danger warnings and right-of-way acquisition requests are centrally managed by VRU UE-B.

[0094] Returning to Figure 2, in step S4, the RSU or MEC platform sends the service configuration for the VRU to the VRU UE, for example, via the PC5 interface. The service configuration message may also include a VRU UE identifier to identify the VRU UE to which the message is being sent. The service configuration includes, for example, the type, content, and communication settings of the service determined for the VRU. Specifically, the service configuration may also include information about the VRU group to which the VRU belongs, such as the VRU group ID, group validity period, effective area, and communication settings shared by the VRU group. The VRU UE can then apply the received service configuration in subsequent service interactions with the RSU.

[0095] The above mainly describes how the VRU UE interacts with the RSU via the PC5 interface to implement service registration / customization of the VRU UE on a specific RSU. However, according to embodiments of the present disclosure, the VRU UE can also interact with the core network unit / application server via the Uu interface to implement service customization of the VRU UE.

[0096] Figure 4 illustrates an exemplary interaction process for VRU UE access / registration services according to an embodiment of the present disclosure. Compared to the process in Figure 2 , the process in Figure 4 differs primarily in the interaction between the VRU UE and the core network element or application server. The following describes these differences.

[0097] As shown in FIG4 , after the VRU UE generates a service request message in response to a triggering event (step S1), in step S2′, the VRU UE sends the generated service request message to a core network element (e.g., application function AF) or an application server hosting the service via a Uu interface (e.g., A11 interface in FIG1 ).

[0098] In step S3', the core network element / application server determines a service configuration for the VRU based on the service preference information and optional other information contained in the service request message. The service configuration includes service content and communication settings customized for the VRU. Optionally, the core network element / application server can also manage VRUs in groups and apply service content and / or communication settings shared by the VRU group to the VRUs.

[0099] In step S4', the core network element / application server sends the service configuration for the VRU to the VRU UE, for example, via the Uu interface. The service configuration message may also include a VRU UE identifier to identify the VRU UE to which the message is sent. The VRU UE can then apply the received service configuration in subsequent service interactions with the RSU.

[0100] Through the interactive process of the VRU registration service described above, facilities such as the RSU / MEC platform / Internet of Vehicles cloud server can customize VRU assistance services based on the security needs of the VRU. Since the VRU can participate in safety assistance services as an active agent, for example, it is beneficial to improve the VRU's ability to proactively avoid danger after being warned. In addition, the RSU and VRU UE can negotiate the communication frequency, for example, providing discontinuous reception (DRX) transmission setting instructions to achieve power saving for the VRU UE. According to some embodiments of the present disclosure, a method for grouping VRUs is provided, which improves the efficiency of warning prompts for VRUs.

[0101] The following describes an example service process for a VRU, using safety assistance services (e.g., collision avoidance warning) as an example, with reference to Figures 5 and 6. It should be noted that the embodiments of the present disclosure are not limited to the collision avoidance warning services shown in Figures 5 and 6 and can be modified to apply to other types of services. The processes described in these figures can be used as a follow-up to the interactive processes in Figures 2 or 4. However, some of the steps can also be performed simultaneously with or before the interactive processes in Figures 2 or 4.

[0102] Figure 5 shows a safety assistance service process based on the PC5 interface according to an embodiment of the present disclosure. In this example, the VRU UE can support communication based on the PC5 interface.

[0103] As shown in the figure, in S51, when the roadside sensing device detects that a moving object enters its sensing area, it can identify the type of the object, such as whether it is a VRU or a vehicle, and generate corresponding status information based on the monitoring results, such as VRU status information or vehicle status information, including mobility information such as the position, speed, and moving direction of the VRU or vehicle, respectively.

[0104] Individual roadside sensing devices typically consist of multiple different types of sensors mounted on a tower, forming a complete sensing system. Furthermore, they have sensor data processing capabilities, enabling them to identify objects within their sensing range, such as VRUs, vehicles, and road surfaces (including road signs, shoulders, medians, construction sites, and surrounding vegetation). For mobile objects like VRUs and vehicles, they can also generate mobility information such as trajectory (historical trajectory, trajectory prediction), and speed (typically measured by radar). This information can be transmitted to the MEC / Internet of Vehicles cloud platform for further processing and analysis. A single sensor typically only has the ability to collect and transmit specific types of sensor information, such as image formation, lidar point cloud data, and radar data. However, some advanced sensors (such as the Sony IMX500) may also have some image recognition capabilities. Regardless of the output data format, the sensor device is unlikely to directly generate final road warning information; it requires further processing by an associated computing system. Furthermore, VRU protection warning zones can be configured for RSUs and roadside sensing devices.

[0105] In step S52, the roadside perception device pushes the generated VRU status message and vehicle status information to the MEC platform or the Internet of Vehicles cloud platform. The MEC platform or the Internet of Vehicles cloud platform receives and parses the VRU status information and vehicle status information in step S54 to run the algorithm to determine whether there is a collision risk between the VRU and the vehicle.

[0106] Optionally, in step S53, the VRU UE may report its own related information, including but not limited to mobility information such as its position, speed, and moving direction, or characteristic information of the VRU, such as the type of the VRU, the color of the clothes worn, the type of the device operated, etc., through, for example, the PC5 interface.

[0107] The purpose of the VRU reporting its own information is to: 1) facilitate the mapping between VRU UEs accessible to the RSU at the communication layer and VRU UEs identified by the sensor device (i.e., step S55 described later); 2) provide a means of mutual calibration for VRUs identified by the sensor device, including calibrating the information of the sensor-identified VRU with the information reported by the VRU UE, and vice versa. The specific calibration method depends on the implementation, for example, determining the reference side based on the confidence level of the data on both sides; 3) For some VRUs not identified by the sensor device (either completely unidentified or with low confidence), the information reported by the VRU UE can serve as supplementary information, taking into account the sensor device's missed detection rate, identification errors, obstacles blocking the sensor, and other factors.

[0108] It should be noted that step S53 does not necessarily occur after steps S51, S52, and S54, and the VRU UE may send VRU-related information multiple times, for example, continuously reporting its real-time location. If, before step S53, the VRU UE has already connected to the RSU through, for example, the process shown in FIG. 2 or FIG. 4 , then transmission and reception can proceed according to the negotiated communication settings. Conversely, if the VRU UE has not yet connected to the RSU (e.g., the process shown in FIG. 2 or FIG. 4 has not yet been executed), then step S53 is preferably executed to facilitate the RSU's establishment of contact with the VRU UE.

[0109] Also optionally, in step S55, the MEC or IoV cloud platform can match the VRU-related information reported by the VRU UE with the VRU status message identified by the roadside sensing device. The matching process may, for example, include: matching the mobility-related data of both parties (e.g., parameters such as location, speed, and direction), and if they are within a certain threshold range, they are considered to be matched; the user inputs some of his own characteristics at the application layer (e.g., clothing color, type of device operated by the VRU, and other characteristics that can be identified by the roadside sensing device) to assist in the matching judgment. The result of the matching is that the VRU status information is associated with its VRU (or VRU UE). The MEC or IoV cloud platform can also use this information to calibrate or supplement the VRU status information.

[0110] Next, in step S56, the MEC or IoV cloud platform determines whether there is a risk of collision or scraping between the VRU and the vehicle based on the VRU status information and the vehicle status information. For example, the MEC or IoV cloud platform analyzes vehicle and VRU mobility information, such as the VRU's location, speed, direction, and other information, as well as the relative position of the vehicle, and combines it with road conditions to determine whether there is a risk of collision. For example, the MEC or IoV cloud platform can predict whether the VRU's trajectory overlaps with the vehicle's trajectory (or more broadly, whether the trajectories are close together) to derive an expected collision time.

[0111] If it is determined that there is a collision risk, the MEC or the Internet of Vehicles cloud platform generates a warning prompt message. The generation of the warning message is entirely determined by the algorithm deployed on the MEC platform. If the VRU UE has pre-customized the warning service (for example, through the process described in Figure 2 or Figure 4), the algorithm can generate a warning message according to the warning trigger conditions and warning prompt method expected by the VRU. In step S57, the MEC or the Internet of Vehicles cloud platform pushes the warning message to the RSU, and then the RSU can send the warning message to the VRU UE through the PC5 interface in step S58 to remind the VRU to pay attention to the vehicle. In addition, the RSU can also send the warning message to the corresponding vehicle, for example, through the PC5 interface to prompt the vehicle to avoid.

[0112] Figure 6 illustrates a Uu-based safety assistance service process according to an embodiment of the present disclosure. The process begins at step S61, where a VRU or vehicle enters the sensing area of ​​a roadside sensing device. The roadside sensing device identifies the type, location, speed, direction, and other information of the VRUs and vehicles within the sensing area and generates a VRU status message and vehicle status information.

[0113] In step S62, the roadside sensing device pushes the generated VRU status message and vehicle status information to the MEC or the Internet of Vehicles cloud platform, and in step S64, the MEC or the Internet of Vehicles cloud platform can receive and parse the VRU status information and vehicle status information from the roadside sensing device. It should be noted that the MEC or the Internet of Vehicles cloud platform can communicate with the VRU UE through the Uu interface, and there are two cases depending on whether the core network deploys the relevant application functions / application servers:

[0114] 1) If the core network is deployed with relevant application function entities, the core network can provide services such as UE device ID verification and location services (including location updates provided by the Location Management Function (LMF) and positioning based on 3GPP technologies). Once the VRU UE is powered on and connected to the network through the Uu interface, the core network can instruct nearby RSUs and MEC platforms to perform security monitoring of the VRU UE in real time based on the VRU UE's location and RSU coverage information provided by the relevant application entities.

[0115] 2) If the core network has not deployed relevant application function entities, the VRU UE needs to communicate with the MEC / Internet of Vehicles cloud platform through the data plane, and the MEC / Internet of Vehicles cloud platform will perform matching.

[0116] Optionally, in step S63, the VRU UE may report its own related information, including but not limited to mobility information such as its location, speed, and direction of movement, or VRU feature information such as the type of VRU, the color of the clothing worn, the type of device operated, etc., through, for example, the PC5 interface. Furthermore, in optional step S65, the MEC or the Internet of Vehicles cloud platform matches the VRU related information reported by the VRU UE with the VRU status information identified by the roadside sensing device. The specific matching process is similar to that of step S55 and is not further described here.

[0117] In step S66, the MEC or IoV cloud platform determines whether there is a collision or scrape risk between the VRU and the vehicle based on the VRU status information and the vehicle status information. If a collision risk is determined, the MEC or IoV cloud platform generates a warning message. If the VRU UE has pre-subscribed to the warning service (e.g., through the process described in Figures 2 or 4), the algorithm can generate a warning message based on the VRU's desired warning trigger conditions and warning notification method.

[0118] In step S67, the MEC or the IoV cloud platform sends a warning message to the VRU UE via the Uu interface to remind the VRU to pay attention to the vehicle. In addition, the MEC or IoV cloud platform can also send a warning message to the corresponding vehicle via the Uu interface to prompt the vehicle to avoid.

[0119] Typically, warning messages are sent by RSUs to vehicles to alert them to potential VRUs along their routes. Suppose a roadside sensing system is compromised by a hacker, who maliciously broadcasts nonexistent VRU risk warning messages to vehicles in a specific area via the RSU. When these vehicles receive these messages, they may interfere with the driver's normal driving strategy or autonomous driving decisions, creating additional road use risks. Therefore, to mitigate the impact of this scenario on normal traffic flow and VRU protection, the following strategies can be considered:

[0120] 1) A vehicle receives a VRU warning from an RSU when there is no blind spot, but its own sensors do not detect a potential risk. If the RSU's VRU warning is a false alarm, the vehicle prioritizes its own perception and downgrades the priority of V2X warnings in corresponding or similar scenarios.

[0121] 2) The vehicle collects statistics on the comparison results between the VRU warning received in the non-blind area and the perception of its own sensors. The algorithm itself is set to count the continuous different perception results and the comparison differences with the real scene. When it finds that the result exceeds the set threshold, it actively shakes hands with the RSU to confirm its status information and the confidence level of the V2X warning information.

[0122] Next, an electronic device and a communication method according to embodiments of the present disclosure are described.

[0123] 7A is a block diagram illustrating an electronic device 100 for a VRU according to an embodiment of the present disclosure, and FIG7B is a flowchart illustrating a communication method that can be performed by the electronic device 100. The electronic device 100 can communicate with an electronic device 200 to be described below.

[0124] As shown in FIG7A , the electronic device 100 includes a processing circuit 101, which includes at least a generating unit 102, a sending unit 103, and a receiving unit 104. The processing circuit 101 can be configured to perform the communication method shown in FIG7B . The processing circuit 101 can refer to various implementations of digital circuit systems, analog circuit systems, or mixed-signal (a combination of analog and digital signals) circuit systems that perform functions in a computing system. The processing circuit can include, for example, circuits such as integrated circuits (ICs), application-specific integrated circuits (ASICs), parts or circuits of a separate processor core, an entire processor core, a separate processor, a programmable hardware device such as a field programmable gate array (FPGA), and / or a system including multiple processors.

[0125] The generation unit 102 of the processing circuit 101 is configured to generate a service request message in response to a trigger event (i.e., execute step S101 in FIG. 7B ). The service request message includes an identifier that uniquely identifies the terminal device of the VRU and service preference information. Events that trigger the generation of the service request message include, for example, receiving a broadcast message from an RSU or detecting that the VRU or its terminal device is in a predetermined state.

[0126] The sending unit 103 is configured to send the service request message generated by the generating unit 102 to a network side device, such as an RSU, an MEC platform, a core network unit, or an application server (i.e., executing step S102 in FIG7B ). The sending unit 103 can send the service request message through, for example, a PC5 interface or a Uu interface.

[0127] The receiving unit 104 is configured to receive a service configuration determined based on the service preference information from the network-side device (i.e., executing step S103 in FIG. 7B ). The service configuration includes, for example, the type, content, and communication settings of the service determined for the VRU, and can be transmitted via, for example, a PC5 interface or a Uu interface. Preferably, the service configuration includes information about the VRU group to which the VRU belongs.

[0128] The electronic device 100 may further include, for example, a communication unit 105. The communication unit 105 may be configured to communicate under the control of the processing circuit 101. In one example, the communication unit 105 may be implemented as a transceiver, including communication components such as an antenna array and / or a radio frequency link. The communication unit 105 is depicted with a dashed line because it may also be located outside the electronic device 100.

[0129] The electronic device 100 may also include a memory 106. The memory 106 may store various data and instructions, such as programs and data used for the operation of the electronic device 100, various data generated by the processing circuit 101, and the like. The memory 106 is depicted with a dotted line because it may be located within the processing circuit 101 or external to the electronic device 100. The memory 106 may be a volatile memory and / or a non-volatile memory. For example, the memory may include, but is not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), read-only memory (ROM), and flash memory.

[0130] 8A is a block diagram illustrating an electronic device 200 for a network-side device according to an embodiment of the present disclosure, and FIG8B is a flowchart illustrating a communication method that can be performed by the electronic device 200. The electronic device 200 can communicate with the electronic device 100 described above.

[0131] As shown in FIG8A , the electronic device 200 includes a processing circuit 201, which includes at least a receiving unit 202, a determining unit 203, and a sending unit 204. The processing circuit 201 can be configured to perform the communication method shown in FIG8B . The processing circuit 201 can refer to various implementations of digital circuit systems, analog circuit systems, or mixed-signal (a combination of analog and digital signals) circuit systems that perform functions in a computing system. The processing circuit can include, for example, circuits such as integrated circuits (ICs), application-specific integrated circuits (ASICs), parts or circuits of a separate processor core, an entire processor core, a separate processor, a programmable hardware device such as a field programmable gate array (FPGA), and / or a system including multiple processors.

[0132] The receiving unit 202 of the processing circuit 201 is configured to receive a service request message from the VRU UE (ie, execute step S201 in FIG. 8B ), wherein the service request message is generated by the VRU UE in response to a triggering event and includes an identifier uniquely identifying the VRU UE and service preference information.

[0133] The determining unit 203 is configured to determine a service configuration for the VRU based on the service preference information in the service request message (i.e., execute step S202 in FIG. 8B ). The service configuration includes the type, content, and communication settings of the service determined for the VRU, and preferably includes information about a VRU group to which the VRU belongs, wherein the VRUs in the VRU group have the same or similar communication settings.

[0134] The sending unit 204 is configured to send the service configuration determined by the determining unit 203 to the VRU UE (ie, execute step S203 in FIG8B ). The sending unit 204 can implement transmission of the service configuration through, for example, a PC5 interface or a Uu interface.

[0135] The electronic device 200 may further include, for example, a communication unit 205. The communication unit 205 may be configured to communicate under the control of the processing circuit 201. In one example, the communication unit 205 may be implemented as a transceiver, including communication components such as an antenna array and / or a radio frequency link. The communication unit 205 is depicted with dashed lines because it may also be located outside the electronic device 200.

[0136] The electronic device 200 may also include a memory 206. The memory 206 may store various data and instructions, such as programs and data used for the operation of the electronic device 200, various data generated by the processing circuit 201, and the like. The memory 206 is depicted with a dashed line because it may be located within the processing circuit 201 or outside the electronic device 200. The memory 206 may be a volatile memory and / or a non-volatile memory. For example, the memory may include, but is not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), read-only memory (ROM), and flash memory.

[0137] It should be understood that the various units of the electronic devices 100 and 200 described in the above embodiments are merely logical modules divided according to the specific functions they implement, and are not intended to limit specific implementation methods. In actual implementation, the above units can be implemented as independent physical entities, or can also be implemented by a single entity (for example, a processor (CPU or DSP, etc.), an integrated circuit, etc.).

[0138] [Exemplary Implementation of the Present Disclosure]

[0139] According to the embodiments of the present disclosure, various implementations of the concepts of the present disclosure can be envisioned, including but not limited to:

[0140] 1) An electronic device for vulnerable road users (VRUs), comprising:

[0141] The processing circuit is configured to:

[0142] In response to a triggering event, generating a service request message, the service request message including an identifier uniquely identifying a terminal device of the VRU and service preference information;

[0143] Sending the service request message to the network side device; and

[0144] A service configuration determined based on the service preference information is received from the network side device.

[0145] 2) The electronic device as described in 1), wherein the triggering event includes:

[0146] A broadcast message is received from a roadside unit (RSU) through a PC5 interface, where the broadcast message includes service content supported by the RSU and corresponding communication settings.

[0147] 3) The electronic device according to 2), wherein the broadcast message is triggered by at least one of the following:

[0148] Periodically;

[0149] The RSU receives information from an associated roadside sensing device indicating that the VRU has entered a sensing range of the roadside sensing device;

[0150] The RSU receives a BSM, PSM or VAM message sent by the terminal device of the VRU;

[0151] The RSU receives a BSM, PSM, or VAM message sent by a vehicle device indicating that the VRU is present in a specific area; and

[0152] The RSU receives an indication sent by a core network unit or an application server, indicating that the VRU enters the coverage of the RSU.

[0153] 4) The electronic device according to 1) or 2), wherein the triggering event includes at least one of the following:

[0154] The terminal device of the VRU finds that the VRU is in a certain security risk by receiving and analyzing data sent by vehicle equipment or roadside unit (RSU);

[0155] The terminal device of the VRU receives information indicating that the VRU is close to a high-risk area from a core network unit or an application server;

[0156] The terminal device of the VRU discovers, based on the positioning information, that the VRU has entered a high-risk area; and

[0157] The power level of the terminal device of the VRU is lower than a certain threshold.

[0158] 5) The electronic device according to 1), wherein the service preference information indicates at least one of the following:

[0159] The type of service desired by the VRU;

[0160] the communication mode used for the service;

[0161] The manner in which the VRU receives the early warning prompt;

[0162] The VRU receives a triggering condition for an early warning prompt.

[0163] 6) The electronic device as described in 5), wherein the service type includes at least one of the following:

[0164] Collision avoidance / road risk warning services;

[0165] Cooperative Interchange Lane Change Service;

[0166] Positioning assistance services; and

[0167] Message relay / collection forwarding service.

[0168] 7) The electronic device according to 1), wherein the service request message further includes at least one of the following:

[0169] The type of the VRU;

[0170] The mobility capability of the VRU;

[0171] The braking performance of the VRU;

[0172] Positioning capability of the terminal device of the VRU; and

[0173] The navigation route of the terminal device of the VRU.

[0174] 8) The electronic device according to 1), wherein the service configuration includes a type, content, and communication settings of a service determined for the VRU.

[0175] 9) The electronic device according to 8), wherein the service configuration further includes information about a VRU group to which the VRU belongs, wherein the VRUs in the VRU group have substantially the same communication settings.

[0176] 10) The electronic device according to 1), wherein the processing circuit is further configured to:

[0177] Receive VRU grouping information broadcast by another VRU;

[0178] sending a join request to the other VRU; and

[0179] A VRU Group Acknowledgement message is received from the other VRU.

[0180] 11) The electronic device according to 1), wherein the processing circuit is further configured to:

[0181] Send VRU status information to the roadside unit (RSU) through the PC5 interface;

[0182] Receive early warning prompts from the RSU through the PC5 interface.

[0183] 12) An electronic device for a network-side device, comprising:

[0184] The processing circuit is configured to:

[0185] receiving a service request message from a terminal device of a vulnerable transportation user (VRU), wherein the service request message is generated in response to a triggering event and includes an identifier uniquely identifying the terminal device of the VRU and service preference information;

[0186] determining a service configuration for the VRU based on the service preference information; and

[0187] The service configuration is sent to the terminal device of the VRU.

[0188] 13) The electronic device as described in 12), wherein the network side device includes a road side unit (RSU), a multi-access edge computing (MEC) platform, a core network unit or an application server.

[0189] 14) The electronic device according to 12), wherein the processing circuit is further configured to send, through a roadside unit (RSU), a broadcast message including service content and communication settings supported by the RSU as the trigger event in response to at least one of the following:

[0190] Periodically;

[0191] The RSU receives information from an associated roadside sensing device indicating that the VRU has entered a sensing range of the roadside sensing device;

[0192] The RSU receives a BSM, PSM or VAM message sent by the terminal device of the VRU;

[0193] The RSU receives a BSM, PSM, or VAM message sent by a vehicle device indicating that the VRU is present in a specific area; and

[0194] The RSU receives an indication sent by a core network unit or an application server, indicating that the VRU enters the coverage of the RSU.

[0195] 15) The electronic device according to 12), wherein the service preference information indicates at least one of the following:

[0196] The type of service desired by the VRU;

[0197] the communication mode used for the service;

[0198] The manner in which the VRU receives the early warning prompt; and

[0199] The VRU receives a triggering condition for an early warning prompt.

[0200] 16) The electronic device as described in 15), wherein the service type includes at least one of the following:

[0201] Collision avoidance / road risk warning services;

[0202] Cooperative Interchange Lane Change Service;

[0203] Location assistance features; and

[0204] Message relay / aggregate forwarding.

[0205] 17) The electronic device according to 12), wherein the service configuration includes a type, content, and communication settings of a service determined for the VRU.

[0206] 18) The electronic device according to 12), wherein the processing circuit is further configured to:

[0207] updating communication settings for services of the VRU based on a risk level of an environment in which the VRU is located; and

[0208] The updated communication settings are sent to the terminal device of the VRU.

[0209] 19) The electronic device according to 12), wherein the processing circuit is further configured to:

[0210] determining a VRU group to which the VRU belongs based on a predetermined group management criterion, wherein the VRUs within the VRU group have substantially the same communication settings; and

[0211] The service configuration includes information about the VRU group and sends the information to the terminal device of the VRU.

[0212] 20) The electronic device according to 12), wherein the processing circuit is further configured to:

[0213] receiving VRU status information of the VRU and vehicle status information from a roadside sensing device;

[0214] determining whether there is a collision risk between the VRU and the vehicle based on the VRU status information and the vehicle status information; and

[0215] In response to determining that there is a collision risk, a warning prompt is sent to the VRU.

[0216] 21) The electronic device according to 20), wherein the processing circuit is further configured to:

[0217] receiving VRU related information from a terminal device of the VRU; and

[0218] By matching VRU related information received from the terminal device of the VRU with VRU status information received from the drive test sensing device, the VRU status information is calibrated and associated with the VRU.

[0219] 22) An electronic device for a vehicle, comprising:

[0220] The processing circuit is configured to:

[0221] Receive V2X warnings about vulnerable road users (VRUs) from road test units (RSUs);

[0222] Comparing the V2X warning with real-world scenarios; and

[0223] Based on the comparison results, the priority of the V2X warning is adjusted.

[0224] 23) The electronic device according to 22), wherein the processing circuit is further configured to:

[0225] When the difference between the V2X warning and the actual scenario exceeds a predetermined threshold, confirm the vehicle status information and / or the confidence level of the V2Z warning with the RSU.

[0226] 24) A communication method, comprising:

[0227] In response to a triggering event, generating a service request message, the service request message including an identifier uniquely identifying a terminal device of the VRU and service preference information;

[0228] Sending the service request message to the network side device; and

[0229] A service configuration determined based on the service preference information is received from the network side device.

[0230] 25) A communication method, comprising:

[0231] receiving a service request message from a terminal device of a vulnerable transportation user (VRU), wherein the service request message is generated in response to a triggering event and includes an identifier uniquely identifying the terminal device of the VRU and service preference information;

[0232] determining a service configuration for the VRU based on the service preference information; and

[0233] The service configuration is sent to the terminal device of the VRU.

[0234] 26) A non-transitory computer-readable storage medium storing executable instructions, wherein the executable instructions, when executed, implement the communication method as described in 24) or 25).

[0235] FIG9 shows an example block diagram of a computer that can be implemented as a terminal device or a control device according to an embodiment of the present disclosure.

[0236] 9 , a central processing unit (CPU) 1301 executes various processes according to a program stored in a read-only memory (ROM) 1302 or a program loaded from a storage section 1308 to a random access memory (RAM) 1303. In the RAM 1303, data required when the CPU 1301 executes various processes and the like is also stored as needed.

[0237] The CPU 1301, the ROM 1302, and the RAM 1303 are connected to one another via a bus 1304. An input / output interface 1305 is also connected to the bus 1304.

[0238] The following components are connected to the input / output interface 1305: an input section 1306 including a keyboard, a mouse, etc.; an output section 1307 including a display such as a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1308 including a hard disk, etc.; and a communication section 1309 including a network interface card such as a LAN card, a modem, etc. The communication section 1309 performs communication processing via a network such as the Internet.

[0239] A drive 1310 is also connected to the input / output interface 1305 as needed. A removable medium 1311 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is mounted on the drive 1310 as needed so that a computer program read therefrom is installed in the storage section 1308 as needed.

[0240] In the case of realizing the above-described series of processing by software, a program constituting the software is installed from a network such as the Internet or a storage medium such as the removable medium 1311 .

[0241] Those skilled in the art will appreciate that such storage media are not limited to the removable medium 1311 shown in FIG. 13 , which stores programs therein and is distributed separately from the device to provide the programs to users. Examples of the removable medium 1311 include magnetic disks (including floppy disks (registered trademark)), optical disks (including compact disk read-only memories (CD-ROMs) and digital versatile disks (DVDs)), magneto-optical disks (including minidiscs (MDs) (registered trademark)), and semiconductor memories. Alternatively, the storage medium may be a ROM 1302, a hard disk included in the storage section 1308, or the like, in which the programs are stored and distributed to users together with the device containing them.

[0242] [Application Examples of the Present Disclosure]

[0243] The techniques described in this disclosure can be applied to a variety of products.

[0244] For example, the electronic devices 100 and 200 according to the embodiments of the present disclosure may be implemented as various base stations or installed in base stations, or may be implemented as various user equipments or installed in various user equipments.

[0245] The communication method according to the embodiments of the present disclosure can be implemented by various base stations or user equipment; the methods and operations according to the embodiments of the present disclosure can be embodied as computer-executable instructions, stored in a non-temporary computer-readable storage medium, and can be executed by various base stations or user equipment to implement one or more functions described above.

[0246] The technology according to the embodiments of the present disclosure can be made into various computer program products, which can be used in various base stations or user equipments to implement one or more functions described above.

[0247] The base stations referred to in this disclosure may be implemented as any type of base station, preferably, such as the macro gNB and ng-eNB defined in the 3GPP 5G NR standard. A gNB may cover a cell smaller than a macro cell, such as a pico gNB, micro gNB, and home (femto) gNB. Alternatively, a base station may be implemented as any other type of base station, such as a NodeB, eNodeB, and base transceiver station (BTS). A base station may also include: a main body configured to control wireless communications, and one or more remote radio heads (RRHs) located separately from the main body, wireless relay stations, drone towers, control nodes in automated factories, and the like.

[0248] The user equipment can be implemented as a mobile terminal (such as a smartphone, a tablet personal computer (PC), a notebook PC, a portable game terminal, a portable / dongle-type mobile router, and a digital camera) or an in-vehicle terminal (such as a car navigation device). The user equipment can also be implemented as a terminal that performs machine-to-machine (M2M) communication (also known as a machine-type communication (MTC) terminal), a drone, a sensor and actuator in an automated factory, etc. In addition, the user equipment can be a wireless communication module (such as an integrated circuit module including a single chip) installed on each of the above terminals.

[0249] The following briefly introduces examples of base stations and user equipment to which the technology of the present disclosure can be applied.

[0250] First application example of base station

[0251] FIG10 is a block diagram illustrating a first example of a schematic configuration of a base station to which the techniques of this disclosure may be applied. In FIG10 , the base station may be implemented as gNB 1400. gNB 1400 includes multiple antennas 1410 and base station device 1420. Base station device 1420 and each antenna 1410 may be connected to each other via an RF cable. In one implementation, gNB 1400 (or base station device 1420) herein may correspond to electronic device 200 described above.

[0252] Antenna 1410 includes multiple antenna elements, such as multiple antenna arrays for massive MIMO. Antenna 1410 can be arranged in a matrix antenna array, for example, and used by base station device 1420 to transmit and receive wireless signals. For example, multiple antennas 1410 can be compatible with multiple frequency bands used by gNB 1400.

[0253] The base station device 1420 includes a controller 1421 , a memory 1422 , a network interface 1423 , and a wireless communication interface 1425 .

[0254] The controller 1421 may be, for example, a CPU or DSP, and operates various higher-layer functions of the base station device 1420. For example, the controller 1421 may include the processing circuit 201 described above, execute the communication method described in FIG. 8B , or control various components of the electronic device 200. For example, the controller 1421 generates data packets based on data in the signal processed by the wireless communication interface 1425 and transmits the generated packets via the network interface 1423. The controller 1421 may bundle data from multiple baseband processors to generate bundled packets and transmit the generated bundled packets. The controller 1421 may have logic functions for performing control such as radio resource control, radio bearer control, mobility management, admission control, and scheduling. This control may be performed in conjunction with nearby gNBs or core network nodes. The memory 1422 includes RAM and ROM and stores programs executed by the controller 1421 and various types of control data (such as terminal lists, transmission power data, and scheduling data).

[0255] The network interface 1423 is a communication interface for connecting the base station device 1420 to the core network 1424 (e.g., a 5G core network). The controller 1421 can communicate with the core network node or another gNB via the network interface 1423. In this case, the gNB 1400 and the core network node or other gNB can be connected to each other via logical interfaces (such as NG interfaces and Xn interfaces). The network interface 1423 can also be a wired communication interface or a wireless communication interface for wireless backhaul lines. If the network interface 1423 is a wireless communication interface, the network interface 1423 can use a higher frequency band for wireless communication than the frequency band used by the wireless communication interface 1425.

[0256] The wireless communication interface 1425 supports any cellular communication scheme (such as 5G NR) and provides wireless connectivity to terminals located in the cell of the gNB 1400 via the antenna 1410. The wireless communication interface 1425 may typically include, for example, a baseband (BB) processor 1426 and RF circuitry 1427. The BB processor 1426 can perform, for example, encoding / decoding, modulation / demodulation, and multiplexing / demultiplexing, and various types of signal processing at various layers (e.g., the physical layer, MAC layer, RLC layer, PDCP layer, and SDAP layer). In place of the controller 1421, the BB processor 1426 may perform some or all of the aforementioned logical functions. The BB processor 1426 may be a memory that stores communication control programs, or a module including a processor configured to execute programs and associated circuitry. Program updates can modify the functionality of the BB processor 1426. This module may be a card or blade inserted into a slot in the base station device 1420. Alternatively, it may be a chip mounted on the card or blade. Meanwhile, the RF circuit 1427 may include, for example, a mixer, a filter, and an amplifier, and transmits and receives wireless signals via the antenna 1410. Although FIG10 shows an example in which one RF circuit 1427 is connected to one antenna 1410, the present disclosure is not limited to this illustration, and one RF circuit 1427 may be connected to multiple antennas 1410 at the same time.

[0257] As shown in Figure 10 , the wireless communication interface 1425 may include multiple BB processors 1426. For example, multiple BB processors 1426 may be compatible with multiple frequency bands used by gNB 1400. As shown in Figure 10 , the wireless communication interface 1425 may include multiple RF circuits 1427. For example, multiple RF circuits 1427 may be compatible with multiple antenna elements. While Figure 10 illustrates an example in which the wireless communication interface 1425 includes multiple BB processors 1426 and multiple RF circuits 1427, the wireless communication interface 1425 may also include a single BB processor 1426 or a single RF circuit 1427.

[0258] In the gNB 1400 shown in FIG10 , one or more units included in the processing circuit 201 may be implemented in the wireless communication interface 1425. Alternatively, at least a portion of these components may be implemented in the controller 1421. For example, the gNB 1400 may include a portion (e.g., the BB processor 1426) or the entirety of the wireless communication interface 1425, and / or a module including the controller 1421, and one or more components may be implemented in the module. In this case, the module may store a program that allows the processor to function as one or more components (in other words, a program that allows the processor to perform the operations of one or more components) and may execute the program. As another example, the program that allows the processor to function as one or more components may be installed in the gNB 1400, and the wireless communication interface 1425 (e.g., the BB processor 1426) and / or the controller 1421 may execute the program. As described above, the gNB 1400, base station device 1420, or module may be provided as an apparatus including one or more components, and the program that allows the processor to function as one or more components may also be provided. In addition, a readable medium having the program recorded therein can be provided.

[0259] Second application example of base station

[0260] FIG11 is a block diagram illustrating a second example of a schematic configuration of a base station to which the technology of the present disclosure can be applied. In FIG11 , the base station is illustrated as a gNB 1530. The gNB 1530 includes multiple antennas 1540, a base station device 1550, and an RRH 1560. The RRH 1560 and each antenna 1540 can be connected to each other via an RF cable. The base station device 1550 and the RRH 1560 can be connected to each other via a high-speed line such as an optical fiber cable. In one implementation, the gNB 1530 (or base station device 1550) herein may correspond to the electronic device 200 described above.

[0261] Antenna 1540 includes multiple antenna elements, such as multiple antenna arrays for massive MIMO. Antenna 1540 can be arranged in a matrix antenna array, for example, and used by base station device 1550 to transmit and receive wireless signals. For example, multiple antennas 1540 can be compatible with multiple frequency bands used by gNB 1530.

[0262] Base station device 1550 includes a controller 1551, a memory 1552, a network interface 1553, a wireless communication interface 1555, and a connection interface 1557. Controller 1551, memory 1552, and network interface 1553 are the same as controller 1421, memory 1422, and network interface 1423 described with reference to FIG.

[0263] The wireless communication interface 1555 supports any cellular communication scheme (such as 5G NR) and provides wireless communication to terminals located in the sector corresponding to the RRH 1560 via the RRH 1560 and the antenna 1540. The wireless communication interface 1555 may generally include, for example, a BB processor 1556. The BB processor 1556 is identical to the BB processor 1426 described with reference to FIG. 10 , except that the BB processor 1556 is connected to the RF circuit 1564 of the RRH 1560 via the connection interface 1557. As shown in FIG. 11 , the wireless communication interface 1555 may include multiple BB processors 1556. For example, the multiple BB processors 1556 may be compatible with multiple frequency bands used by the gNB 1530. Although FIG. 11 illustrates an example in which the wireless communication interface 1555 includes multiple BB processors 1556, the wireless communication interface 1555 may also include a single BB processor 1556.

[0264] The connection interface 1557 is an interface for connecting the base station device 1550 (wireless communication interface 1555) to the RRH 1560. The connection interface 1557 may also be a communication module for connecting the base station device 1550 (wireless communication interface 1555) to the RRH 1560 for communication in the high-speed line.

[0265] The RRH 1560 includes a connection interface 1561 and a wireless communication interface 1563 .

[0266] The connection interface 1561 is an interface for connecting the RRH 1560 (wireless communication interface 1563) to the base station device 1550. The connection interface 1561 may also be a communication module for communication in the above-mentioned high-speed line.

[0267] The wireless communication interface 1563 transmits and receives wireless signals via the antenna 1540. The wireless communication interface 1563 may generally include, for example, an RF circuit 1564. The RF circuit 1564 may include, for example, a mixer, a filter, and an amplifier, and transmits and receives wireless signals via the antenna 1540. Although FIG11 shows an example in which one RF circuit 1564 is connected to one antenna 1540, the present disclosure is not limited to this illustration, and one RF circuit 1564 may be connected to multiple antennas 1540 simultaneously.

[0268] As shown in FIG11 , the wireless communication interface 1563 may include multiple RF circuits 1564. For example, the multiple RF circuits 1564 may support multiple antenna elements. Although FIG11 shows an example in which the wireless communication interface 1563 includes multiple RF circuits 1564, the wireless communication interface 1563 may also include a single RF circuit 1564.

[0269] In the gNB 1500 shown in FIG11 , one or more units included in the processing circuit 201 may be implemented in the wireless communication interface 1525. Alternatively, at least a portion of these components may be implemented in the controller 1521. For example, the gNB 1500 may include a portion (e.g., the BB processor 1526) or the entirety of the wireless communication interface 1525, and / or a module including the controller 1521, and one or more components may be implemented in the module. In this case, the module may store a program that allows the processor to function as one or more components (in other words, a program that allows the processor to perform the operations of one or more components) and may execute the program. As another example, the program that allows the processor to function as one or more components may be installed in the gNB 1500, and the wireless communication interface 1525 (e.g., the BB processor 1526) and / or the controller 1521 may execute the program. As described above, the gNB 1500, base station device 1520, or module may be provided as a device including one or more components, and the program that allows the processor to function as one or more components may also be provided. In addition, a readable medium having the program recorded therein can be provided.

[0270] First application example of user equipment

[0271] 12 is a block diagram illustrating an example of a schematic configuration of a smartphone 1600 to which the technology of the present disclosure may be applied. In one example, the smartphone 1600 may be implemented as the electronic device 100 or 200.

[0272] The smart phone 1600 includes a processor 1601, a memory 1602, a storage device 1603, an external connection interface 1604, a camera 1606, a sensor 1607, a microphone 1608, an input device 1609, a display device 1610, a speaker 1611, a wireless communication interface 1612, one or more antenna switches 1615, one or more antennas 1616, a bus 1617, a battery 1618 and an auxiliary controller 1619.

[0273] The processor 1601 may be, for example, a CPU or a system on a chip (SoC), and controls the functions of the application layer and other layers of the smartphone 1600. The processor 1601 may include or function as the processing circuit 101 or 201 described with reference to the drawings. The memory 1602 includes RAM and ROM, and stores data and programs executed by the processor 1601. The storage device 1603 may include storage media such as semiconductor memories and hard disks. The external connection interface 1604 is an interface for connecting external devices (such as memory cards and universal serial bus (USB) devices) to the smartphone 1600.

[0274] The camera 1606 includes an image sensor (such as a charge coupled device (CCD) and a complementary metal oxide semiconductor (CMOS)) and generates a captured image. The sensor 1607 may include a group of sensors such as a measurement sensor, a gyroscope sensor, a geomagnetic sensor, and an acceleration sensor. The microphone 1608 converts the sound input to the smartphone 1600 into an audio signal. The input device 1609 includes, for example, a touch sensor, a keypad, a keyboard, a button, or a switch configured to detect a touch on the screen of the display device 1610, and receives an operation or information input from the user. The display device 1610 includes a screen (such as a liquid crystal display (LCD) and an organic light emitting diode (OLED) display) and displays the output image of the smartphone 1600. The speaker 1611 converts the audio signal output from the smartphone 1600 into sound.

[0275] The wireless communication interface 1612 supports any cellular communication scheme (such as 4G LTE or 5G NR, etc.) and performs wireless communication. The wireless communication interface 1612 may generally include, for example, a BB processor 1613 and an RF circuit 1614. The BB processor 1613 may perform, for example, encoding / decoding, modulation / demodulation, and multiplexing / demultiplexing, and perform various types of signal processing for wireless communication. Meanwhile, the RF circuit 1614 may include, for example, a mixer, a filter, and an amplifier, and transmit and receive wireless signals via an antenna 1616. The wireless communication interface 1612 may be a chip module on which the BB processor 1613 and the RF circuit 1614 are integrated. As shown in FIG12 , the wireless communication interface 1612 may include multiple BB processors 1613 and multiple RF circuits 1614. Although FIG12 shows an example in which the wireless communication interface 1612 includes multiple BB processors 1613 and multiple RF circuits 1614, the wireless communication interface 1612 may also include a single BB processor 1613 or a single RF circuit 1614.

[0276] In addition, in addition to the cellular communication scheme, the wireless communication interface 1612 can support other types of wireless communication schemes, such as a short-range wireless communication scheme, a near field communication scheme, and a wireless local area network (LAN) scheme. In this case, the wireless communication interface 1612 may include a BB processor 1613 and an RF circuit 1614 for each wireless communication scheme.

[0277] Each of the antenna switches 1615 switches the connection destination of the antenna 1616 between a plurality of circuits (eg, circuits for different wireless communication schemes) included in the wireless communication interface 1612 .

[0278] Antenna 1616 includes multiple antenna elements, such as multiple antenna arrays for massive MIMO. Antenna 1616 can be arranged in an antenna array matrix, for example, and is used for wireless communication interface 1612 to transmit and receive wireless signals. Smartphone 1600 may include one or more antenna panels (not shown).

[0279] In addition, the smartphone 1600 may include an antenna 1616 for each wireless communication scheme. In this case, the antenna switch 1615 may be omitted from the configuration of the smartphone 1600.

[0280] The bus 1617 connects the processor 1601, the memory 1602, the storage device 1603, the external connection interface 1604, the camera 1606, the sensor 1607, the microphone 1608, the input device 1609, the display device 1610, the speaker 1611, the wireless communication interface 1612, and the auxiliary controller 1619. The battery 1618 supplies power to the various blocks of the smartphone 1600 shown in FIG12 via feeders, which are partially shown as dashed lines in the figure. The auxiliary controller 1619 operates the minimum necessary functions of the smartphone 1600, for example, in sleep mode.

[0281] In the smartphone 1600 shown in FIG12 , one or more units included in the processing circuit 101 or 201 may be implemented in the wireless communication interface 1612. Alternatively, at least a portion of these components may be implemented in the processor 1601 or the auxiliary controller 1619. As an example, the smartphone 1600 includes a portion (e.g., the BB processor 1613) or the entirety of the wireless communication interface 1612, and / or a module including the processor 1601 and / or the auxiliary controller 1619, and one or more components may be implemented in the module. In this case, the module may store a program that allows the processor to function as one or more components (in other words, a program for allowing the processor to perform the operations of one or more components) and may execute the program. As another example, a program for allowing the processor to function as one or more components may be installed in the smartphone 1600, and the wireless communication interface 1612 (e.g., the BB processor 1613), the processor 1601, and / or the auxiliary controller 1619 may execute the program. As described above, the smartphone 1600 or module may be provided as a device including one or more components, and a program for allowing a processor to function as one or more components may be provided. In addition, a readable medium having the program recorded therein may be provided.

[0282] Second application example of user equipment

[0283] 13 is a block diagram illustrating an example of a schematic configuration of a car navigation device 1720 to which the technology of the present disclosure may be applied. The car navigation device 1720 includes a processor 1721, a memory 1722, a global positioning system (GPS) module 1724, a sensor 1725, a data interface 1726, a content player 1727, a storage medium interface 1728, an input device 1729, a display device 1730, a speaker 1731, a wireless communication interface 1733, one or more antenna switches 1736, one or more antennas 1737, and a battery 1738. In one example, the car navigation device 1720 may be implemented as any of the electronic devices 100 and 200 described in the present disclosure.

[0284] The processor 1721 may be, for example, a CPU or an SoC, and controls a navigation function and other functions of the car navigation device 1720. The memory 1722 includes a RAM and a ROM, and stores data and programs executed by the processor 1721.

[0285] The GPS module 1724 uses GPS signals received from GPS satellites to measure the position (such as latitude, longitude, and altitude) of the car navigation device 1720. The sensor 1725 may include a group of sensors such as a gyroscope sensor, a geomagnetic sensor, and an air pressure sensor. The data interface 1726 is connected to, for example, the vehicle network 1741 via a terminal not shown, and obtains data generated by the vehicle (such as vehicle speed data).

[0286] The content player 1727 reproduces content stored in a storage medium (such as a CD or DVD) inserted into the storage medium interface 1728. The input device 1729 includes, for example, a touch sensor, button, or switch configured to detect a touch on the screen of the display device 1730, and receives operations or information input from the user. The display device 1730 includes a screen such as an LCD or OLED display and displays images of the navigation function or reproduced content. The speaker 1731 outputs sounds of the navigation function or reproduced content.

[0287] The wireless communication interface 1733 supports any cellular communication scheme (such as 4G LTE or 5G NR) and performs wireless communication. The wireless communication interface 1733 may generally include, for example, a BB processor 1734 and an RF circuit 1735. The BB processor 1734 may perform, for example, encoding / decoding, modulation / demodulation, and multiplexing / demultiplexing, and perform various types of signal processing for wireless communication. Meanwhile, the RF circuit 1735 may include, for example, a mixer, a filter, and an amplifier, and transmit and receive wireless signals via an antenna 1737. The wireless communication interface 1733 may also be a chip module on which the BB processor 1734 and the RF circuit 1735 are integrated. As shown in Figure 13, the wireless communication interface 1733 may include multiple BB processors 1734 and multiple RF circuits 1735. Although Figure 13 shows an example in which the wireless communication interface 1733 includes multiple BB processors 1734 and multiple RF circuits 1735, the wireless communication interface 1733 may also include a single BB processor 1734 or a single RF circuit 1735.

[0288] In addition, in addition to the cellular communication scheme, the wireless communication interface 1733 can support other types of wireless communication schemes, such as short-range wireless communication schemes, near field communication schemes, and wireless LAN schemes. In this case, for each wireless communication scheme, the wireless communication interface 1733 can include a BB processor 1734 and an RF circuit 1735.

[0289] Each of the antenna switches 1736 switches a connection destination of the antenna 1737 between a plurality of circuits included in the wireless communication interface 1733 , such as circuits for different wireless communication schemes.

[0290] The antenna 1737 includes multiple antenna elements, such as multiple antenna arrays for massive MIMO, and can be arranged into an antenna array matrix, for example, and used for the wireless communication interface 1733 to transmit and receive wireless signals.

[0291] In addition, the car navigation device 1720 may include an antenna 1737 for each wireless communication scheme. In this case, the antenna switch 1736 may be omitted from the configuration of the car navigation device 1720.

[0292] The battery 1738 supplies power to the respective blocks of the car navigation device 1720 shown in Fig. 13 via a feeder line, which is partially shown as a dotted line in the figure. The battery 1738 accumulates the power supplied from the vehicle.

[0293] In the car navigation device 1720 shown in FIG13 , one or more units included in the processing circuit 101 or 201 may be implemented in the wireless communication interface 1733. Alternatively, at least a portion of these components may be implemented in the processor 1721. As an example, the car navigation device 1720 includes a portion (e.g., the BB processor 1734) or the entirety of the wireless communication interface 1733, and / or a module including the processor 1721, and one or more components may be implemented in the module. In this case, the module may store a program that allows the processor to function as one or more components (in other words, a program for allowing the processor to perform the operations of one or more components) and may execute the program. As another example, a program for allowing the processor to function as one or more components may be installed in the car navigation device 1720, and the wireless communication interface 1733 (e.g., the BB processor 1734) and / or the processor 1721 may execute the program. As described above, the car navigation device 1720 or a module may be provided as a device including one or more components, and a program for allowing the processor to function as one or more components may be provided. In addition, a readable medium having the program recorded therein can be provided.

[0294] The technology of the present disclosure can also be implemented as an in-vehicle system (or vehicle) 1740 including a car navigation device 1720, an in-vehicle network 1741, and one or more blocks of a vehicle module 1742. The vehicle module 1742 generates vehicle data (such as vehicle speed, engine speed, and fault information) and outputs the generated data to the in-vehicle network 1741.

[0295] The exemplary embodiments of the present disclosure are described above with reference to the accompanying drawings, but the present disclosure is certainly not limited to the above examples. Those skilled in the art may obtain various changes and modifications within the scope of the appended claims, and it should be understood that these changes and modifications will naturally fall within the technical scope of the present disclosure.

[0296] For example, a plurality of functions included in one unit in the above embodiments may be implemented by separate devices. Alternatively, a plurality of functions implemented by a plurality of units in the above embodiments may be implemented by separate devices, respectively. In addition, one of the above functions may be implemented by a plurality of units. Needless to say, such a configuration is included in the technical scope of the present disclosure.

[0297] In this specification, the steps described in the flowchart include not only processing executed in time series in the order described, but also processing executed in parallel or individually rather than necessarily in time series. In addition, even in the steps processed in time series, it goes without saying that the order can be changed as appropriate.

[0298] Although the present disclosure and its advantages have been described in detail, it should be understood that various changes, substitutions and transformations can be made without departing from the spirit and scope of the present disclosure as defined by the appended claims. Moreover, the terms "comprises," "comprising," or any other variations thereof in the embodiments of the present disclosure are intended to cover non-exclusive inclusions, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article, or device. In the absence of further restrictions, an element defined by the statement "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.

Claims

1. An electronic device for a vulnerable road user (VRU), comprising: The processing circuit is configured to: In response to a triggering event, generating a service request message, the service request message including an identifier uniquely identifying a terminal device of the VRU and service preference information; Sending the service request message to the network side device; as well as A service configuration determined based on the service preference information is received from the network side device.

2. The electronic device according to claim 1, wherein The triggering events include: A broadcast message is received from a roadside unit (RSU) through a PC5 interface, where the broadcast message includes service content supported by the RSU and corresponding communication settings.

3. The electronic device according to claim 2, wherein: The broadcast message is triggered by at least one of the following: Periodicity; The RSU receives information from an associated roadside sensing device indicating that the VRU has entered a sensing range of the roadside sensing device; The RSU receives a basic safety message (BSM), a personal safety message (PSM), or a VRU awareness message (VAM) sent by a terminal device of the VRU; The RSU receives a BSM, PSM, or VAM sent by a vehicle device indicating that the VRU is present in a specific area; as well as The RSU receives an indication sent by a core network unit or an application server, indicating that the VRU enters the coverage of the RSU.

4. The electronic device according to claim 1 or 2, wherein: The triggering event includes at least one of the following: The terminal device of the VRU finds that the VRU is in a certain security risk by receiving and analyzing data sent by vehicle equipment or roadside unit (RSU); The terminal device of the VRU receives an indication from the core network unit or the application server that the VRU is close to a high-risk area. Domain information; The terminal device of the VRU discovers, based on the positioning information, that the VRU has entered a high-risk area; and The power level of the terminal device of the VRU is lower than a certain threshold.

5. The electronic device according to claim 1, wherein The service preference information indicates at least one of the following: The type of service desired by the VRU; the communication mode used for the service; The manner in which the VRU receives the early warning prompt; and The VRU receives a triggering condition for an early warning prompt.

6. The electronic device according to claim 5, wherein: The service type includes at least one of the following: Collision avoidance / road risk warning services; Cooperative Interchange Lane Change Service; Positioning assistance services; as well as Message relay / collection forwarding service.

7. The electronic device according to claim 1, wherein The service request message further includes at least one of the following: The type of the VRU; The mobility capability of the VRU; The braking performance of the VRU; Positioning capability of the terminal device of the VRU; as well as The navigation route of the terminal device of the VRU.

8. The electronic device according to claim 1, wherein The service configuration includes the type, content, and communication settings of the service determined for the VRU.

9. The electronic device according to claim 8, wherein: The service configuration further includes information about a VRU group to which the VRU belongs, wherein the VRUs within the VRU group have substantially the same communication settings.

10. The electronic device according to claim 1, wherein The processing circuit is further configured to: Receive VRU grouping information broadcast by another VRU; sending a join request to the other VRU; and A VRU Group Acknowledgement message is received from the other VRU.

11. The electronic device according to claim 1, wherein The processing circuit is further configured to: Send VRU status information to the Roadside Unit (RSU) via the PC5 interface; and Receive early warning prompts from the RSU through the PC5 interface.

12. An electronic device for a network-side device, comprising: The processing circuit is configured to: receiving a service request message from a terminal device of a vulnerable transportation user (VRU), wherein the service request message is generated in response to a triggering event and includes an identifier uniquely identifying the terminal device of the VRU and service preference information; determining a service configuration for the VRU based on the service preference information; as well as The service configuration is sent to the terminal device of the VRU.

13. The electronic device according to claim 12, wherein: The network side equipment includes a road side unit (RSU), a multi-access edge computing (MEC) platform, a core network unit or an application server.

14. The electronic device according to claim 12, wherein: The processing circuit is further configured to send, via a roadside unit (RSU), a broadcast message including service content and communication settings supported by the RSU as the trigger event in response to at least one of the following: Periodicity; The RSU receives information from an associated roadside sensing device indicating that the VRU has entered a sensing range of the roadside sensing device; The RSU receives the basic safety message (BSM), personal safety message (PSM) and other information sent by the terminal device of the VRU. Message (PSM) or VRU awareness message (VAM); The RSU receives a BSM, PSM, or VAM sent by a vehicle device indicating that the VRU is present in a specific area; as well as The RSU receives an indication sent by a core network unit or an application server, indicating that the VRU enters the coverage of the RSU.

15. The electronic device according to claim 12, wherein The service preference information indicates at least one of the following: The type of service desired by the VRU; the communication mode used for the service; The manner in which the VRU receives the early warning prompt; and The VRU receives a triggering condition for an early warning prompt.

16. The electronic device according to claim 15, wherein: The service type includes at least one of the following: Collision avoidance / road risk warning services; Cooperative Interchange Lane Change Service; Location assistance features; and Message relay / aggregate forwarding.

17. The electronic device according to claim 12, wherein: The service configuration includes the type, content, and communication settings of the service determined for the VRU.

18. The electronic device according to claim 12, wherein: The processing circuit is further configured to: updating communication settings for services of the VRU based on a risk level of an environment in which the VRU is located; and The updated communication settings are sent to the terminal device of the VRU.

19. The electronic device according to claim 12, wherein: The processing circuit is further configured to: determining, based on a predetermined group management criterion, a VRU group to which the VRU belongs, wherein the VRUs within the VRU group have substantially the same communication settings; as well as The service configuration includes information about the VRU group and sends the information to the terminal device of the VRU.

20. The electronic device according to claim 12, wherein The processing circuit is further configured to: receiving VRU status information of the VRU and vehicle status information from a roadside sensing device; determining, based on the VRU status information and the vehicle status information, whether there is a collision risk between the VRU and the vehicle; as well as In response to determining that there is a collision risk, a warning prompt is sent to the VRU.

21. The electronic device according to claim 20, wherein: The processing circuit is further configured to: receiving VRU related information from a terminal device of the VRU; as well as By matching VRU related information received from the terminal device of the VRU with VRU status information received from the drive test sensing device, the VRU status information is calibrated and associated with the VRU.

22. An electronic device for a vehicle, comprising: The processing circuit is configured to: Receive V2X warnings about vulnerable road users (VRUs) from road test units (RSUs); Comparing the V2X warning with real-world scenarios; and Based on the comparison results, the priority of the V2X warning is adjusted.

23. The electronic device of claim 22, wherein the processing circuit is further configured to: When the difference between the V2X warning and the actual scenario exceeds a predetermined threshold, confirm the vehicle status information and / or the confidence level of the V2X warning to the RSU.

24. A communication method, comprising: In response to a triggering event, generating a service request message, the service request message including an identifier uniquely identifying a terminal device of the VRU and service preference information; Sending the service request message to the network side device; as well as A service configuration determined based on the service preference information is received from the network side device.

25. A communication method, comprising: receiving a service request message from a terminal device of a vulnerable transportation user (VRU), wherein the service request message is generated in response to a triggering event and includes an identifier uniquely identifying the terminal device of the VRU and service preference information; determining a service configuration for the VRU based on the service preference information; as well as The service configuration is sent to the terminal device of the VRU.

26. A non-transitory computer-readable storage medium storing executable instructions, wherein the executable instructions, when executed, implement the communication method according to claim 24 or 25.

Images