Unicast communication method and device for vehicle networking

Abstract

The present invention discloses a method and device for unicast wireless communication between a vehicle-mounted unit and a roadside unit. In the present invention, the vehicle-mounted unit sends a connection request message to the roadside unit in a broadcast manner, and the connection request message is used to request the establishment of a unicast connection. In response to receiving the connection request message, the roadside unit sends a connection acceptance message to the vehicle-mounted unit in a unicast manner, and the connection acceptance message is used to notify the unicast connection service capability of the roadside unit. In response to receiving the connection acceptance message, the vehicle-mounted unit sends a connection confirmation message to the roadside unit in a unicast manner, and the connection confirmation message is used to confirm the establishment of the unicast connection to the roadside unit.

Description

Technical Field

[0001] The present invention relates to wireless communication technology for connected vehicles, and more specifically to unicast communication technology between a vehicle-mounted unit and a roadside unit in the connected vehicle. Background Art

[0002] The dedicated short-range communication (DSRC) standard based on the IEEE 802.11p communication standard and the LTE-V2X standard based on the 3GPP long-term evolution (LTE) standard are the two major mainstream communication standards currently used in the field of Internet of Vehicles. Compared with DSRC technology, LTE-V2X can utilize the existing cellular network infrastructure and spectrum resources, and has a lower application cost. Moreover, LTE-V2X technology has significantly improved in bandwidth, scope of application, quality of service, etc., and is suitable for a variety of Internet of Vehicles communication application scenarios. Therefore, the design of vehicle-to-infrastructure (V2I) communication between the on-board unit (OBU) and the roadside unit (RSU) based on LTE-V2X technology is conducive to overcoming the shortcomings of traditional DSRC communication and achieving better service quality, and has become a hot research direction at present.

[0003] Although LTE-V2X technology has many advantages over DSRC technology, the existing LTE-V2X standard can only support broadcast communication initiated by RSU. LTE-V2X technology under the existing standard cannot realize one-to-one unicast information interaction between the on-board unit and the vehicle, roadside unit, pedestrian, etc. For example, vehicle near field payment (VNFP), a typical application of V2I technology, refers to a service mode in which the vehicle acts as a service terminal to pay for the consumed goods or services. The on-board unit OBU and the roadside unit RSU exchange information to complete the payment function and vehicle information management. For application scenarios such as parking payment, charging payment, and refueling payment, when the vehicle stops, it is necessary to establish a connection and complete the service only when the vehicle enters the service area and there is a communication demand, that is, there is no need for the RSU to continuously establish connections with multiple different devices. Therefore, in this application scenario, if the RSU periodic broadcast communication method is still used in the communication connection establishment stage, it is not only not suitable for the requirement of the vehicle to actively initiate payment, but also causes a waste of communication resources, which is not conducive to the long-term effective operation of the equipment. Summary of the invention

[0004] The present invention content is not intended to identify the key features or essential features of the protected subject matter, nor is it intended to be used to limit the scope of the protected subject matter. The present invention content will be further described in the following specific embodiments.

[0005] In order to solve the technical problems existing in the broadcast communication mode initiated by RSU in the existing LTE-V2X standard in the application scenario of actively initiating payment when the vehicle stops, such as described in the background technology, the present disclosure provides a unicast connection communication process initiated by OBU by message interaction between OBU and RSU. The message interaction between OBU and RSU can utilize the dedicated service announcement (DSA) broadcast, DSA unicast, and dedicated short message (DSM) unicast communication modes provided by the present disclosure.

[0006] In one aspect, the present disclosure provides a method for wireless communication of an on-board unit. The method includes: sending a connection request message in a broadcast mode, the connection request message is used to request the establishment of a unicast connection; receiving a connection acceptance message sent in a unicast mode from a roadside unit in response to the connection request message, the connection acceptance message is used to notify the unicast connection service capability of the roadside unit; and in response to receiving the connection acceptance message, sending a connection confirmation message to the roadside unit in a unicast mode, the connection confirmation message is used to confirm the establishment of the unicast connection to the roadside unit.

[0007] On the other hand, the present disclosure also provides a method for wireless communication of a roadside unit, which includes: receiving a connection request message sent by a vehicle-mounted unit in a broadcast manner, the connection request message is used to request the establishment of a unicast connection; in response to receiving the connection request message, sending a connection acceptance message to the vehicle-mounted unit in a unicast manner, the connection acceptance message is used to notify the unicast connection service capability of the roadside unit; and receiving a connection confirmation message sent in a unicast manner from the vehicle-mounted unit in response to the connection acceptance message, the connection confirmation message is used to confirm the establishment of the unicast connection to the roadside unit.

[0008] In one aspect, the present disclosure provides a device for wireless communication of an on-board unit. The device includes: a memory; and at least one processor coupled to the memory. The at least one processor is configured to: send a connection request message in a broadcast manner, the connection request message being used to request the establishment of a unicast connection; receive a connection acceptance message sent in a unicast manner from a roadside unit in response to the connection request message, the connection acceptance message being used to notify the unicast connection service capability of the roadside unit; and send a connection confirmation message to the roadside unit in a unicast manner in response to receiving the connection acceptance message, the connection confirmation message being used to confirm the establishment of the unicast connection to the roadside unit.

[0009] On the other hand, the present disclosure also provides a device for wireless communication of a roadside unit. The device includes: a memory; and at least one processor coupled to the memory. The at least one processor is configured to: receive a connection request message sent by the on-board unit in a broadcast manner, the connection request message being used to request the establishment of a unicast connection; in response to receiving the connection request message, send a connection acceptance message to the on-board unit in a unicast manner, the connection acceptance message being used to notify the unicast connection service capability of the roadside unit; and receive a connection confirmation message sent in a unicast manner from the on-board unit in response to the connection acceptance message, the connection confirmation message being used to confirm the establishment of a unicast connection to the roadside unit.

[0010] In other aspects, the present disclosure further provides a computer-readable storage medium having a computer executable code stored thereon. The computer executable code can be used to execute the method for onboard unit wireless communication or the method for roadside unit wireless communication according to the present disclosure. The present disclosure further provides a computer program product. The computer program product includes instructions executable by a processor. When the instructions are executed by the processor, the method for onboard unit wireless communication or the method for roadside unit wireless communication according to the present disclosure can be implemented.

[0011] It should be noted that one or more of the above aspects include the features described in detail below and specifically described in the claims. The following description and drawings elaborate on some exemplary features from multiple aspects. These features are merely indicative of the various ways in which the principles of various aspects can be implemented, and the present disclosure is intended to include all such aspects and their equivalents. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 The protocol stack framework diagram of the LTE-based vehicle networking wireless communication technology is shown.

[0013] Figure 2 The frame formats of a dedicated short message data frame and a dedicated service announcement data frame are shown.

[0014] Figure 3 A schematic diagram showing the process of encapsulating a dedicated short message data frame between protocol layers is shown.

[0015] Figure 4A A flow chart of an exemplary method for wireless communication of an on-board unit according to an embodiment of the present disclosure is shown.

[0016] Figure 4B A flowchart of an exemplary method for wireless communication of a roadside unit according to an embodiment of the present disclosure is shown.

[0017] Figure 5 A block diagram of an exemplary apparatus for wireless communication of connected vehicle devices according to an embodiment of the present disclosure is shown.

[0018] Figure 6 A broadcast communication flow chart of a dedicated service announcement data frame according to an embodiment of the present disclosure is shown.

[0019] Figure 7 A unicast communication flow chart of a dedicated service announcement data frame according to an embodiment of the present disclosure is shown.

[0020] Figure 8 The figure shows a unicast communication flow chart of a dedicated short message data frame according to an embodiment of the present disclosure.

[0021] Fig. 9 A unicast connection communication flow chart initiated by a vehicle-mounted unit according to an embodiment of the present disclosure is shown.

[0022] Fig.10 A unicast connection communication flow chart initiated by a vehicle-mounted unit according to another embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0023] The following will describe various embodiments in detail with reference to the accompanying drawings. It should be understood that the description of these specific embodiments is only used to enable those skilled in the art to better understand and thereby implement the present disclosure, and is not intended to limit the scope of the present disclosure.

[0024] Figure 1 The protocol stack framework diagram of the LTE-based vehicle networking wireless communication technology is shown. The protocol stack of the LTE vehicle networking wireless communication equipment (e.g., OBU and RSU) mainly includes the application layer, the network layer, and the access layer. At the access layer, LTE-V2X supports the Uu interface and the PC5 interface. The Uu interface is the interface between the user terminal and the access network device (e.g., eNode B) in the LTE standard. The PC5 interface is the interface for direct connection between terminal devices (e.g., between cars) in the LTE standard. In an embodiment of the present disclosure, the unicast communication process initiated by the OBU can use the PC5 interface for interaction between the OBU and the RSU.

[0025] The network layer includes two parts: the data sublayer and the management sublayer. The management sublayer mainly completes system configuration and maintenance, etc., and its functions are integrated in the dedicated management entity (DME). DME is a general combination of management services, providing a management interface for the data sublayer, thereby interacting with the data sublayer and using the services of the data sublayer to transmit management data streams between different user devices. The data sublayer includes: IP and TCP / UDP layers, a dedicated short message protocol (DSMP) layer, and an adaptation layer. The data sublayer is used for user plane data transmission between user equipment application layers, and for the transmission of control plane messages between user equipment management layer entities (e.g., dedicated management entities) or between management layer entities and application layers. The IP protocol and DSMP protocol in the data sublayer are optional. In an embodiment of the present disclosure, the unicast communication process initiated by the OBU can interact between the OBU and the RSU via the DSMP protocol. The DSMP protocol layer is mainly responsible for data interaction with different applications. The DSMP entity can deliver application layer data packets to the bottom layer, and transmit short messages of interest to the application layer to the application layer. The DSMP protocol can use an application identifier (AID) to distinguish different application layer services.

[0026] The adaptation layer provides a transmission adaptation function between the underlying access technology (such as LTE-V2X) and the upper layer protocol stack. The adaptation layer can receive DSMP data packets or DME data packets sent by the upper layer, distinguish the underlying interface used by the data packet to be sent, and submit the corresponding data packet to the underlying layer that conforms to the corresponding access layer interface for transmission. The adaptation layer can also receive data packets from the bottom layer, distinguish the upper layer protocol type to which the corresponding data packet belongs, and submit the data packet to the specified upper layer protocol stack. The adaptation layer function also includes: mapping between application identifiers and destination layer 2 identifiers, generation / change / maintenance of source layer 2 identifiers, mapping between unicast / multicast addresses and layer 2 identifiers, and so on. In one embodiment of the present disclosure, the adaptation layer can also pass the source layer 2 identifier it generates, that is, the local address of the device, to the upper layer protocol stack (for example, DSMP).

[0027] The application layer is the highest layer of the user protocol stack. It decides to receive service data according to the needs of the equipment, and passes the service data to the network layer and the access layer to execute the sending process. According to an embodiment of the present disclosure, the messages exchanged between the OBU and the RSU in the unicast communication process initiated by the OBU are divided into user plane messages and control plane messages. Dedicated short message (DSM) data frames can be used to carry user plane messages, such as the interaction of application layer data information. Dedicated service announcement (DSA) data frames can be used to carry control plane messages, for example, wake-up messages, unicast service announcement messages, connection acceptance messages, and connection release announcements for releasing unicast connection communication processes initiated by the OBU. DSA data frames can be encapsulated in the data part of the DSM data frame, so as to be transmitted using the DSM data frame communication method.

[0028] Figure 2 FIG. 2 shows a frame format 210 of a DSM data frame in the DSMP protocol layer and a frame format 220 of a DSA data frame. Figure 2 As shown, in the DSMP protocol layer, the DSM data frame 210 includes two parts: a DSMP frame header and a payload data. The payload data part can be used to encapsulate user service data information from the application layer, and can also be used to encapsulate DSA frames from the application layer and / or a dedicated management entity. The DSMP frame header part includes: a DSMP version, used to distinguish different DSMP versions; a DSMP extension domain indication, used to indicate whether the following extension domain appears; a reserved domain, reserved for other functions; an extension domain, used for other information, for example, to indicate different functions of data information; an application identifier (AID), used to distinguish different application services; a data length, used to indicate the byte length of the upper layer data entity. According to some embodiments of the present disclosure, in the unicast communication process initiated by the OBU, other information such as the name and identifier of the message exchanged between the OBU and the RSU can be encapsulated in the extension domain of the DSM data frame.

[0029] like Figure 2 The DSA data frame includes two parts: a DSA frame header and application information. The DSA frame header part includes: a DSA version, which is used to distinguish different DSA version numbers; a DSA frame header extension field indication, which is used to indicate whether the following frame header extension field appears; a reserved field, which is reserved for other functions; a DSA identifier (ID), which is used to identify the uniqueness of the DSA; a content count, which is used to identify whether it is a repetition of the previous DSA when the DSA ID is the same; a frame header extension field, which is used for other information, for example, to indicate different functions of data information. The application information part includes: an application information count, which is used to indicate how many application information there are in total; an application identifier (AID), which is used to distinguish different application services; an application extension field, which is used to indicate application-related information. According to some embodiments of the present disclosure, the name or identifier of the control plane message exchanged between the OBU and the RSU in the unicast communication process initiated by the OBU can be encapsulated in the DSA ID field. According to other embodiments of the present disclosure, in a unicast communication process initiated by the OBU, other information such as the name and identifier of the control plane message exchanged between the OBU and the RSU may be encapsulated in a DSA frame header extension field or an application extension field.

[0030] Figure 3 The schematic diagram shows the process of encapsulating a dedicated short message data frame between protocol layers. Starting from the sending end application layer and / or dedicated management entity (DME), the application service data or control message DSA frame is sent to the DSMP layer. In the DSMP layer, a DSMP frame header is added to the data from the upper layer, packaged and encapsulated into a DSMP layer DSM frame, and sent to the adaptation layer. Figure 2 The DSMP frame header may include: DSMP version, DSMP extension field indication, reserved field, extension field, application identifier (AID), and data length. When the DSA frame is encapsulated in the data part of the DSM frame, the AID in the DSM frame may be set to the AID value corresponding to the DSA frame. In the adaptation layer, an adaptation layer frame header is added to the DSM frame from the DSMP layer, packaged and encapsulated into an adaptation layer DSM frame, and sent to the access layer. The adaptation layer frame header includes protocol type information, which is used to indicate the protocol type used by the upper layer data packet, for example, the DSMP protocol. In the access layer, an access layer frame header is added to the DSM frame from the adaptation layer, packaged and encapsulated into an access layer DSM frame, and sent to the receiving end access layer via the access layer communication technology (for example, PC5 interface). The receiving end can perform processing corresponding to the sending end, pass it upward from the access layer, and perform unpacking, decapsulation and filtering layer by layer, thereby realizing the communication of user plane messages and control plane messages between the sending end and the receiving end.

[0031] According to one embodiment, the above-mentioned interaction between protocol layers can be realized through data sublayer service primitives. In addition to the above-mentioned data packets generated by each protocol layer, the information exchanged between each protocol layer may also include other overhead information, such as source and destination addresses, and other information that needs to be exchanged between each protocol layer. In the embodiments of the present disclosure, the data sublayer service primitives may include but are not limited to: DSM.request, DSM.indication, Address.indication, ADAPTATION-LAYER.request, ADAPTATION-LAYER.indication, ACCESS-LAYER.request, ACCESS-LAYER.indication.

[0032] In addition, in order to use the management and maintenance functions provided by the management sublayer, the application layer and the DSMP layer also need to interact with the DME. For example, the device application needs to register at the DME first so that the DME can send the received DSM frame to the corresponding upper layer application. According to an embodiment of the present disclosure, during the DSA frame communication process, when the upper layer wants to send a DSA frame, it needs to send a request to the DME. When the DSMP layer receives a DSA frame, the DSA frame can be sent to the DME, and it is determined at the DME whether the DSA frame matches the service type of interest to the application layer. If it matches, the DSA frame is sent to the corresponding upper layer application. According to one embodiment, the interaction between each protocol layer and the DME can be achieved through the management sublayer service primitive. In the embodiment of the present disclosure, the management sublayer service primitive may include but is not limited to: DME-ProviderService.request, DME-ProviderService.confirm, DME-UserService.request, DME-UserService.confirm, DME-DSMService.request, DME-DSMService.confirm, DME-Event.indication.

[0033] The functions and parameters of the management sublayer service primitive and data sublayer service primitive used in the specific embodiment of the present disclosure are described in detail below. It should be noted that, in the absence of special instructions, the parameters included in the service primitives shown below are not necessary for the unicast communication process initiated by OBU according to the present disclosure, and the implementation of the unicast communication process according to the present disclosure is not limited to the specific form of the following service primitives. Those skilled in the art can come to mutually implement the information of the unicast communication process according to the present disclosure between each protocol layer by other means. These other ways are all within the scope of the present disclosure.

[0034] DME-ProviderService.request is a service primitive sent by the application layer to the DME entity, which is used to indicate that the upper layer entity requests to transmit a DSA frame. According to one embodiment of the present disclosure, the service primitive parameters are as follows:

[0035]

[0036]

[0037] Table 1 describes the parameters of the DME-ProviderService.request service primitive.

[0038]

[0039] Table-1

[0040] According to another embodiment of the present disclosure, the DME-ProviderService.request service primitive may also include a "Source MAC address" (source media access control MAC address) parameter. Similar to the peer MAC address, this parameter is also optional. It does not appear when requesting a DSA frame broadcast mode. When requesting a DSA frame unicast / multicast mode, if the application layer does not know the source MAC address, that is, the local address of the sending device, the source MAC address parameter may not appear, or be set to a default value, for example, 0 or any other value that can be recognized by the lower layer protocol as a non-valid source MAC address; if the application layer knows the source MAC address, it can be included as a "Source MAC address" parameter in the DME-ProviderService.request service primitive. In an embodiment of the present disclosure, by including the peer MAC address in the DME-ProviderService.request service primitive, it helps to implement the unicast communication mode of the DSA frame, which can then be used for the control plane message interaction between the OBU and the RSU in the unicast connection communication process initiated by the OBU.

[0041] The DME-ProviderService.confirm service primitive is used to confirm receipt of the corresponding request from the upper layer and to respond to DME-ProviderService.request. If the DME decides to accept this request, it starts unicast, multicast, or broadcast DSA for the upper layer. The service primitive parameters are as follows:

[0042]

[0043]

[0044] Table 2 describes the parameters of the DME-ProviderService.confirm service primitive.

[0045]

[0046] Table-2

[0047] DME-UserService.request is a service primitive sent by the application layer to the DME entity to indicate the application service that the upper layer entity is interested in or wants to receive. The service primitive parameters are as follows:

[0048]

[0049] Table 3 describes the parameters of the DME-UserService.request service primitive.

[0050]

[0051] Table-3

[0052] The DME-UserService.confirm service primitive is used to confirm the receipt of the corresponding request from the upper layer and to respond to DME-UserService.request. If the DME accepts this request, when it receives the DSA, it will match the application of interest identifier set in the upper layer request with the application in the DSA. The service primitive parameters are as follows:

[0053]

[0054] Table 4 describes the parameters of the DME-UserService.confirm service primitive.

[0055]

[0056] Table-4

[0057] DME-DSMService.request is a service primitive sent by the application layer to the DME entity, which is used to indicate that the upper layer requests a short message service. The service primitive parameters are as follows:

[0058]

[0059] Table 5 describes the parameters of the DME-DSMService.request service primitive.

[0060]

[0061] Table-5

[0062] The DME-DSMService.confirm service primitive is used to confirm receipt of the corresponding request from the upper layer and to respond to DME-DSMService.request. The parameters of this service primitive are as follows:

[0063]

[0064] Table 6 describes the parameters of the DME-DSMService.confirm service primitive.

[0065]

[0066] Table-6

[0067] According to one embodiment of the present disclosure, the management sublayer service primitive may also include DME-Event.indication. DME-Event.indication is a service primitive sent by the DME entity to the application layer, which is used to notify the application layer that the requested service of interest message has been received and subsequent operations can be performed. According to one embodiment of the present disclosure, the service primitive parameters are as follows:

[0068]

[0069] Table 7 describes the parameters of the DME-Event.indication service primitive.

[0070]

[0071] Table-7

[0072] According to other embodiments of the present disclosure, the service primitive may include the source MAC address and the peer MAC address as optional parameters, or may not include the peer MAC address parameter, or may not include both the peer MAC address and the source MAC address parameters. For example, in the case where the lower-layer entity receives a DSA broadcast frame, the peer MAC address in the DSA frame is mapped from the application identifier (AID), not the MAC address of the receiving device. In the case where the DME-Event.indication service primitive already includes the AID parameter, there is no need to send the peer MAC address to the application layer. By reducing the peer MAC address parameter in the DME-Event.indication service primitive, the overhead of interaction between protocol layers can be reduced. For another example, after the DME notifies the application layer of the receipt of the service message of interest to the application layer through the DME-Event.indication service primitive, the application layer performs subsequent operations through the DSA frame broadcast communication method. Since the application layer does not need the source MAC address and the peer MAC address, the overhead of interaction between protocol layers can be further reduced by reducing the source MAC address and the peer MAC address parameters in the DME-Event.indication service primitive.

[0073] DSM.request is a service primitive sent by the higher layer (e.g., application layer or DME) to the DSMP protocol layer to request the sending of DSM data. The service primitive parameters are as follows:

[0074]

[0075] Table 8 describes the parameters of the DSM.request service primitive.

[0076]

[0077]

[0078] Table-8

[0079] DSM.indication is a service primitive sent from the DSMP layer to a higher layer (e.g., an application layer or DME) to indicate that the higher layer has received DSM data. If the AID in the DSM indicates that the message is a DSA frame, the DSMP will send DSM.indication to the DME. According to one embodiment of the present disclosure, the service primitive parameters are as follows:

[0080]

[0081]

[0082] Table 9 describes the parameters of the DSM.indication service primitive.

[0083]

[0084] Table-9

[0085] According to another embodiment of the present disclosure, if the AID in the DSM indicates that the message is a DSA frame, then regardless of whether the DSA frame is a broadcast frame or a unicast / multicast frame, the source MAC address and the peer MAC address in the DSM.indication service primitive are mandatory, or at least the source MAC address is mandatory. The source MAC address can be obtained through the source address in the service primitive from the lower layer. In the DSA frame broadcast mode, in an implementation method where the peer MAC address is also mandatory, the peer MAC address can be obtained through the destination address in the service primitive from the lower layer. The destination address can be a local address generated by the adaptation layer of the receiving device, or obtained through a layer 2 identifier mapped by the AID.

[0086] In one embodiment, the present disclosure further provides an Address.indication service primitive. The Address.indication service primitive is used to inform the DME from the DSMP layer of the MAC address of the sending end device of the received DSA unicast, multicast or broadcast frame, that is, the source MAC address included in the DSM frame carrying the DSA frame, so that the receiving end device can send the DSA unicast frame in the subsequent communication process. According to one embodiment of the present disclosure, the parameters of the Address.indication service primitive are as follows:

[0087]

[0088] Table 10 describes the parameters of the Address.indication service primitive.

[0089]

[0090] Table-10

[0091] In the DSA frame broadcast mode, the destination address (Destination_address) described in Table 10 may be a local address generated by the adaptation layer of the receiving device, or may be obtained through a layer 2 identifier mapped by an AID. According to another embodiment of the present disclosure, the Address.indication service primitive may not include the peer MAC address to reduce the overhead of interaction between protocol layers. According to another embodiment of the present disclosure, the peer MAC address in the Address.indication service primitive is optional, i.e., it does not appear in the DSA frame broadcast mode, but is mandatory in the DSA frame unicast mode.

[0092] ADAPTATION-LAYER.request is a service primitive sent from the DSMP layer to the adaptation layer to request the transmission of adaptation layer data. The service primitive parameters are as follows:

[0093]

[0094]

[0095] Table 11 describes the parameters of the ADAPTATION-LAYER.request service primitive.

[0096]

[0097] Table-11

[0098] ADAPTATION-LAYER.indication is a service primitive sent from the adaptation layer to the DSMP layer to indicate that the adaptation layer data has been received. The service primitive parameters are as follows:

[0099]

[0100] Table 12 describes the parameters of the ADAPTATION-LAYER.indication service primitive.

[0101]

[0102] Table-12

[0103] As described in Table 12 above, the destination address parameter in the ADAPTATION-LAYER.indication service primitive is obtained through the destination layer 2 identification parameter in the ACCESS-LAYER.indication service primitive from the lower layer. According to one embodiment of the present disclosure, when a broadcast data frame is received, the adaptation layer can generate a local MAC address of the receiving device as the destination address parameter value in the ADAPTATION-LAYER.indication service primitive. In this way, even when a DSA broadcast frame is received, the upper layer can obtain the local real MAC address of the receiving end for subsequent communication processes.

[0104] ACCESS-LAYER.request is a service primitive sent from the adaptation layer to the access layer to request the sending of access data. The parameters of this service primitive are as follows:

[0105]

[0106] Table 13 describes the parameters of the ACCESS-LAYER.request service primitive.

[0107]

[0108]

[0109] Table-13

[0110] ACCESS-LAYER.indication is a service primitive sent from the access layer to the adaptation layer to indicate that access data has been received. The parameters of this service primitive are as follows:

[0111]

[0112] Table 14 describes the parameters of the ACCESS-LAYER.indication service primitive.

[0113]

[0114]

[0115] Table-14

[0116] Figure 4AA flow chart of an exemplary method 4100 for on-board unit wireless communication according to an embodiment of the present disclosure is shown. The method 4100 can be performed by an on-board unit (OBU) to implement a unicast connection establishment process initiated and led by the OBU on the basis of enhancing the OBU function. The message interaction between the OBU and the RSU in the unicast communication process according to the method 4100 can utilize the dedicated service announcement (DSA) broadcast communication mode, the DSA unicast communication mode, and the dedicated short message (DSM) unicast communication mode provided by the present disclosure.

[0117] In box 4110, method 4100 includes sending a connection request message in a broadcast manner. The connection request message is used to request the establishment of a unicast connection. Method 4100 may include repeatedly sending the connection request message until a connection acceptance message sent in response to the connection request message is received from the roadside unit, and then stopping sending the connection request message. In one embodiment, method 4100 may use a timer mechanism to repeatedly send the connection request message. Method 4100 may include stopping sending the connection request message when a timer for repeatedly sending the connection request message times out. In another embodiment, method 4100 may use a counter mechanism to repeatedly send the connection request message. Method 4100 may include counting the number of times the connection request message is repeatedly sent, and stopping sending the connection request message when the counter for sending the connection request message reaches a threshold. By utilizing a timer and / or counter mechanism to repeatedly send connection request messages, the present disclosure optimizes the communication process of method 4100, thereby ensuring as much as possible that the connection request message sent by the OBU can be received by the RSU, while being able to exit the communication process in the abnormal case where the OBU cannot receive a response message from the RSU, thereby avoiding resource consumption at the OBU and interference with communications with other devices.

[0118] According to an embodiment of the present disclosure, a connection request message may be sent by broadcasting a dedicated service announcement (DSA) data frame. The DSA data frame may include an AID identifying a unicast connection service. In this embodiment, sending a connection request message may include: an OBU sends a request from an application layer to a dedicated management entity (DME) to request the sending of the DSA data frame. The request may include an AID identifying a unicast connection service and a repetition rate. The repetition rate parameter is used to repeatedly send a connection request message. For example, the request may use the DME-ProviderService.request service primitive described above. The request may also include data information related to the connection request message. After receiving a request from the application layer, the DME may generate a DSA broadcast data frame based on the application identifier contained in the request and the data information related to the connection request message, and send it to the RSU in a broadcast manner after layer-by-layer processing of the lower layer protocol stack. In the process of sending a connection request message in a broadcast manner, the peer MAC address may not appear in the request message from the application layer to the DME.

[0119] In box 4120, method 4100 also includes receiving a connection acceptance message sent in a unicast manner from the RSU in response to the connection request message. The connection acceptance message is used to announce the unicast connection service capability of the RSU. The connection acceptance message is sent in a unicast manner through a dedicated service announcement DSA data frame. The DSA unicast data frame carrying the connection acceptance message includes an AID that identifies the unicast connection service. In order to enable the OBU to receive the connection acceptance message sent in a unicast manner, the receiving step also includes: before receiving, sending a request from the application layer to the DME, the request including the AID that identifies the unicast connection service. In this way, when the DME of the OBU receives the DSA data frame including the AID, it will indicate to the application layer. Therefore, the receiving step also includes: receiving an indication from the DME at the application layer, the indication may include the AID that identifies the unicast connection service, the source end address, and the peer end address. Because the source end address and peer end address carried in the connection acceptance message sent in a unicast mode are the address of the RSU that sends the message and the address of the target OBU of the message, the source end address and peer end address included in the above-mentioned indication are the address of the RSU and the address of the OBU respectively. The indication also includes the data information related to the connection acceptance message. The OBU application layer can determine that the connection acceptance message is received based at least in part on the application identifier and data information included in the indication. The request that the OBU sends to the DME from the application layer can adopt the DME-UserService.request service primitive. The indication from the DME received by the OBU at the application layer can adopt the DME-Event.indication service primitive.

[0120] In box 4130, method 4100 also includes sending a connection confirmation message to the roadside unit in unicast mode in response to receiving the connection acceptance message, and the connection confirmation message is used to confirm the establishment of the unicast connection to the roadside unit. The connection confirmation message can be sent in a unicast mode via a DSA data frame, and the DSA data frame includes an AID that identifies the unicast connection service. In order to enable the OBU to send the DSA data frame in a unicast mode, the sending step also includes: sending a request from the application layer to the DME to request to send the DSA unicast data frame, and the request includes the AID that identifies the unicast connection service and the peer address, and the peer address is the address of the roadside unit received in box 4120. The request can use the DME-ProviderService.request service primitive described above. In another embodiment, the request sent from the application layer to the DME can also include a source address, and the source address is the peer address in the connection acceptance message sent in a unicast mode received in box 4120, that is, the MAC address of the OBU.

[0121] although Figure 4A Only the operation steps of the unicast connection establishment phase performed by the OBU according to one embodiment of the present disclosure are shown, and the method 4100 also includes the operation steps performed by the OBU in the unicast connection interaction phase and the unicast connection release phase. In the data interaction phase of the unicast connection, the method 4100 also includes receiving data information sent in a unicast manner from the roadside unit, and the data information may include a data interaction request message or application layer service data; and sending data information to the roadside unit in a unicast manner, and the data information may include a data interaction response message or application layer service data. The data information sent by the OBU and the data information sent by the RSU are both implemented through the dedicated short message DSM data frame unicast communication method described in the present disclosure.

[0122] In the connection release stage, method 4100 also includes receiving a connection release announcement message sent in a unicast manner from the roadside unit, and the connection release announcement message is used to release the unicast connection established with the roadside unit. The connection release announcement message is sent in a unicast manner via a DSA data frame, and the DSA data frame includes an AID that identifies the unicast connection service. The processing process of the OBU receiving the connection release announcement message sent in a unicast manner is basically similar to the processing process of receiving the connection acceptance message sent in a unicast manner in box 4120, the main difference being that the DSA unicast data frame carries the connection release announcement message. Therefore, the technical content described above for box 4120 is also applicable to the step of receiving a connection release announcement message sent in a unicast manner.

[0123] Figure 4BA flowchart of an exemplary method 4200 for wireless communication of a roadside unit according to an embodiment of the present disclosure is shown. The method 4200 can be executed by a roadside unit (RSU) to cooperate with an onboard unit (OBU) to implement a unicast connection establishment process initiated and led by the OBU. In the unicast communication process according to the method 4200, the message interaction between the OBU and the RSU can utilize the dedicated service announcement (DSA) broadcast communication method, the DSA unicast communication method, and the dedicated short message (DSM) unicast communication method provided by the present disclosure.

[0124] In block 4210, method 4200 includes receiving a connection request message sent by the on-board unit in a broadcast manner. The connection request message is used to request the establishment of a unicast connection. The connection request message is sent by broadcasting a dedicated service announcement (DSA) data frame, and the DSA broadcast data frame includes an application identifier (AID) that identifies the unicast connection service. In order to enable the RSU to receive the connection request message sent in a broadcast manner, the receiving step also includes: before receiving, sending a request from the application layer to the DME, the request including the AID that identifies the unicast connection service. In this way, when the DME of the RSU receives the DSA data frame including the AID, it will indicate to the application layer. Therefore, the receiving step also includes: receiving an indication from the DME at the application layer, the indication including the AID that identifies the unicast connection service, the source address, and the peer address. The source address is the MAC address of the OBU that sends the connection request message. The peer address included in the indication can be the peer address carried in the connection request message, which is obtained by the adaptation layer of the OBU using AID mapping during the sending process. Alternatively, the peer address included in the indication may be a local MAC address obtained from the adaptation layer of the RSU. The indication may also include data information related to the connection request message. The RSU application layer may determine that the connection request message is received based at least in part on the application identifier and data information included in the indication. The request sent by the RSU from the application layer to the DME may adopt the DME-UserService.request service primitive. The indication received from the DME by the RSU at the application layer may adopt the DME-Event.indication service primitive.

[0125] In box 4220, method 4200 also includes sending a connection acceptance message in a unicast manner in response to receiving the connection request message. The connection acceptance message is used to announce the unicast connection service capability of the RSU. Method 4200 may include repeatedly sending the connection acceptance message until a connection confirmation message is received from the on-board unit in response to the connection acceptance message, and then stop sending the connection acceptance message. In one embodiment, method 4200 may use a timer mechanism to repeatedly send the connection acceptance message. Method 4200 may include stopping sending the connection acceptance message when a timer for repeatedly sending the connection acceptance message times out. In another embodiment, method 4200 may use a counter mechanism to repeatedly send the connection acceptance message. Method 4200 may include counting the number of times the connection acceptance message is repeatedly sent, and stopping sending the connection acceptance message when the counter for sending the connection acceptance message reaches a threshold. By utilizing a timer and / or counter mechanism to repeatedly send connection acceptance messages, the present disclosure optimizes the communication process of method 4200, thereby ensuring as much as possible that the connection acceptance message sent by the RSU can be received by the OBU, while being able to exit the communication process in the abnormal case where the RSU cannot receive a response message from the OBU, thereby avoiding resource consumption at the RSU and interference with communications with other devices.

[0126] According to an embodiment of the present disclosure, the connection acceptance message is sent in a unicast mode via a DSA data frame. The DSA unicast data frame includes an AID that identifies a unicast connection service. In order to enable the RSU to send the DSA data frame in a unicast mode, the step of sending the connection acceptance message also includes sending a request from the application layer to the DME to request to send the DSA data frame in a unicast mode, the request including the AID that identifies the unicast connection service, a repetition rate, and a peer address, wherein the repetition rate is used to repeatedly send the connection acceptance message, and the peer address is the address of the on-board unit. The peer address is the MAC address of the OBU that sends the connection request message received in block 4210. The request sent from the application layer to the DME may also include a source address. The source address may be a local MAC address obtained from the adaptation layer of the RSU during the process of receiving the connection request message in block 4210. Alternatively, in the case where the RSU application layer has not yet learned the local MAC address, the source address may be set to a default value, such as all 0s or any other value that can be identified as a non-valid source MAC address by the lower layer protocol. The request may also include data information related to the connection acceptance message. After receiving the request from the application layer, the DME can generate a DSA data frame based on the application identifier and data contained in the request, and send it to the OBU in a unicast manner after layer-by-layer processing of the lower layer protocol stack. The request sent from the RSU application layer to the DME can use the DME-ProviderService.request service primitive described above.

[0127] In box 4230, method 4200 also includes receiving a connection confirmation message sent in unicast mode in response to the connection acceptance message from the on-board unit, and the connection confirmation message is used to confirm the establishment of the unicast connection to the roadside unit. The connection confirmation message is sent in unicast mode via a dedicated service announcement DSA data frame, and the DSA data frame includes an AID that identifies the unicast connection service. In order to enable the RSU to receive the connection confirmation message sent in unicast mode, the receiving step also includes: before receiving, sending a request from the application layer to the DME, the request including the AID that identifies the unicast connection service. The request can use the DME-UserService.request service primitive. In this way, when the DME of the RSU receives the DSA data frame including the AID, it will indicate to the application layer. Therefore, the receiving step also includes: receiving an indication from the DME at the application layer, and the indication may include the AID that identifies the unicast connection service, the source address, and the peer address. Because the source end address and peer end address carried in the connection confirmation message sent in a unicast mode are the address of the OBU that sends the message and the address of the target RSU of the message, the source end address and peer end address included in the above-mentioned indication are the address of the OBU and the address of the RSU respectively. The indication also includes the data information related to the connection confirmation message. The OBU application layer can determine that the connection confirmation message is received based at least in part on the application identifier and data information included in the indication. The indication can adopt the DME-Event.indication service primitive.

[0128] although Figure 4B Only the operation steps of the unicast connection establishment phase performed by the RSU according to one embodiment of the present disclosure are shown, and the method 4200 also includes the operation steps performed by the RSU in the unicast connection interaction phase and the unicast connection release phase. In the data interaction phase of the unicast connection, the method 4200 also includes sending data information to the on-board unit in a unicast manner, and the data information may include a data interaction request message or application layer service data; and receiving data information sent in a unicast manner from the on-board unit, and the data information may include a data interaction response message or application layer service data. The data information sent by the RSU and the data information sent by the OBU are both implemented through the dedicated short message DSM data frame unicast communication method described in the present disclosure.

[0129] In the connection release phase, method 4200 also includes sending a connection release announcement message to the on-board unit in a unicast manner, and the connection release announcement message is used to release the unicast connection established with the on-board unit. The connection release announcement message is sent in a unicast manner via a DSA data frame, and the DSA data frame includes an AID that identifies the unicast connection service. The process of the RSU sending the connection release announcement message in a unicast manner is basically similar to the process of sending the connection acceptance message in a unicast manner in box 4220. The main difference is that the DSA unicast data frame carries a connection release announcement message. Therefore, the technical content described above for box 4220 is also applicable to the step of sending a connection release announcement message in a unicast manner.

[0130] Figure 5 1 shows a block diagram of an exemplary apparatus 500 for wireless communication of connected vehicle devices according to an embodiment of the present disclosure. The apparatus 500 may include at least one processor 510 and a memory 520. The processor 510 may be coupled to the memory 520 via a bus 530.

[0131] According to one embodiment of the present disclosure, the apparatus 500 can be used for wireless communication of a vehicle-mounted unit. In this embodiment, the processor 510 can be configured to execute a combined Figure 4A Method 4100 described. For example, the processor 510 may be configured to: send a connection request message in a broadcast manner, the connection request message being used to request the establishment of a unicast connection; receive a connection acceptance message sent in a unicast manner from a roadside unit in response to the connection request message, the connection acceptance message being used to notify the unicast connection service capability of the roadside unit; and send a connection confirmation message to the roadside unit in a unicast manner in response to receiving the connection acceptance message, the connection confirmation message being used to confirm the establishment of the unicast connection to the roadside unit.

[0132] According to another embodiment of the present disclosure, the apparatus 500 can be used for wireless communication of a roadside unit. In this embodiment, the processor 510 can be configured to execute a combined Figure 4B Method 4200 described. For example, the processor 510 may be configured to: receive a connection request message sent by the onboard unit in a broadcast manner, the connection request message being used to request the establishment of a unicast connection; in response to receiving the connection request message, send a connection acceptance message to the onboard unit in a unicast manner, the connection acceptance message being used to notify the unicast connection service capability of the roadside unit; and receive a connection confirmation message sent in a unicast manner from the onboard unit in response to the connection acceptance message, the connection confirmation message being used to confirm the establishment of the unicast connection to the roadside unit.

[0133] The following will be combined Figure 6-8The complete process of implementing DSA data frame broadcast communication, DSA data frame unicast communication, and DSM data frame unicast communication from the transmitting end to the receiving end according to the method 400 of the present disclosure is described in detail. It should be noted that these specific descriptions are only for illustrative purposes, so as to better understand the technical solution of the present disclosure. The present disclosure is not limited to the specific description here.

[0134] Figure 6 The following is a flow chart of the broadcast communication of a dedicated service announcement data frame according to an embodiment of the present disclosure. In the example where an onboard unit (OBU) sends a DSA frame broadcast to a roadside unit (RSU), Figure 6 The sending end shown can be an OBU, and the receiving end can be an RSU. In the example where the RSU sends a DSA frame broadcast to the OBU, Figure 6 The transmitting end shown may be an RSU, and the receiving end may be an OBU.

[0135] Before the sender sends the DSA broadcast data frame, first in step 6.a, the sender uses the DME-ProviderService.request service primitive to indicate to the DME that the application layer requests to send a DSA broadcast message, and informs the relevant application identifier (AID) and other information. In the DSA broadcast mode, the peer MAC address and the source MAC address may not appear in the DME-ProviderService.request service primitive. In step 6.a', after receiving the request, the DME replies to DME-ProviderService.confirm and enters the DSA message broadcast sending process. By setting the repetition rate parameter in DME-ProviderService.request, the periodic sending of the DSA broadcast message can be achieved.

[0136] Accordingly, at step 6.b, the receiving end shall complete the interaction between the application layer and DME before conducting DSA broadcast communication. The application layer indicates its interest in the business services related to the DSA broadcast frame through DME-UserService.request, in which the AID included is the same as the AID in the DME-ProviderService.request service primitive in step 6.a. At step 6.b', after receiving the request, the DME replies with DME-UserService.confirm, and then screens out the DSA message including the AID.

[0137] Next, the sender can use DSA as the data part of the DSM frame, which is sent by DME and passes through DSMP, adaptation layer and access layer in sequence, and is transmitted to the access layer of the receiving end through the access layer communication protocol, and then uploaded to the high layer of the receiving end layer by layer. The specific process is as follows.

[0138] At step 6.c, the transmitting DME determines the data part of the DSM, i.e., the DSA frame, according to the request from the application layer, and passes the data packet to the DSMP through the DSM.request service primitive. The service primitive contains information such as data and AID. In DSA broadcast communication, the source MAC address and the peer MAC address do not appear in the service primitive.

[0139] In step 6.d, the sending DSMP adds a DSMP frame header to the data packet and passes it to the adaptation layer through the ADAPTATION-LAYER.request service primitive. The service primitive includes data, AID, extended information, etc., in which the source address and destination address are all 0.

[0140] At step 6.e, the transmitting adaptation layer adds an adaptation layer frame header and passes it to the access layer through the ACCESS-LAYER.request service primitive. The service primitive includes data, source layer 2 identifier, destination layer 2 identifier, and extended information, etc., but does not include AID, which is included in the data part. In the DSA broadcast communication mode, the source layer 2 identifier is generated by the adaptation layer, and the destination layer 2 identifier is obtained by the adaptation layer using the AID mapping in ADAPTATION-LAYER.request. For example, according to Table 15 below, when the AID value is 1 to identify the wake-up RSU service, the destination layer 2 identifier 0x000000 can be mapped; when the AID value is 2 to identify the unicast connection service, the destination layer 2 identifier 0x000001 can be mapped. It should be noted that Table 15 is only used to illustrate how to obtain the destination layer 2 identifier through AID mapping in the broadcast communication mode. The present disclosure is not limited to the specific values ​​of the AID shown in Table 15, the identified service types, and the specific layer 2 identifier values ​​mapped.

[0141]

[0142] Table-15

[0143] At step 6.f, the access layer at the transmitting end adds an access layer frame header related to the access layer technology and broadcasts the DSM message carrying the DSA frame to the receiving end.

[0144] In step 6.g, the receiving end access layer receives the DSM message, obtains the data, source end layer 2 identifier, destination end layer 2 identifier and other information from its data packet, and informs the adaptation layer through ACCESS-LAYER.indication.

[0145] At step 6.h, the receiving-end adaptation layer obtains the source address and the destination address from the layer 2 identifier in ACCESS-LAYER.indication, and informs the DSMP layer of information such as the address and data through ADAPTATION-LAYER.indication. According to one embodiment of the present disclosure, if the adaptation layer determines that the DSM message is a broadcast message through the received destination layer 2 identifier belonging to the destination layer 2 identifier mapped by AID listed in Table 15, the local MAC address of the receiving-end device can be generated, and the local MAC address can be used as the destination address and passed to the DSMP layer through the ADAPTATION-LAYER.indication service primitive.

[0146] At step 6.i, the DSMP layer at the receiving end sends data and AID information to the DME through the DSM.indication service primitive. According to one embodiment of the present disclosure, in the DSA broadcast mode, DSM.indication may also include the source MAC address and the peer MAC address, so as to inform the application layer of the sender MAC address of the DSA broadcast frame, so as to facilitate the receiving end to adopt the DSA unicast communication mode in the subsequent communication process. In this embodiment, it is possible to jump directly from step 6.i to step 6.k.

[0147] According to another embodiment of the present disclosure, in the DSA broadcast mode, the source MAC address and the peer MAC address do not appear in the DSM.indication service primitive. In this embodiment, at step 6.j, the receiving end DSMP layer can inform the DME of the sender MAC address through the Address.indication service primitive to facilitate subsequent communication processes.

[0148] At step 6.k, the receiving end DME filters out the required DSA messages through AID matching. According to one embodiment of the present disclosure, the receiving end DME can notify the application layer through the DME-Event.indication service primitive that it has received the service message of interest and can perform subsequent operations. The DME-Event.indication service primitive may include information data carried by the AID and DSA frame. According to another embodiment of the present disclosure, the DME-Event.indication service primitive may also include the MAC address of the transceiver obtained by the DME from the DSM.indication or Address.indication service primitive, which is conducive to the receiving end adopting a unicast communication mode in the subsequent communication process.

[0149] Figure 7The unicast communication flow chart of the dedicated service announcement data frame according to the embodiment of the present disclosure is shown. In the example where the on-board unit (OBU) sends a unicast DSA frame to the roadside unit (RSU), Figure 7 The transmitter shown may be an OBU, and the receiver may be an RSU. In the example where the RSU sends a unicast DSA frame to the OBU, Figure 7 The transmitting end shown may be an RSU, and the receiving end may be an OBU.

[0150] Before the sender sends the DSA unicast data frame, first in step 7.a, the sender application layer indicates to the DME through the DME-ProviderService.request service primitive that the application layer requests to send a DSA unicast message, and informs the relevant AID and other information. According to one embodiment of the present disclosure, in the DSA unicast mode, the DME-ProviderService.request service primitive also includes the peer MAC address, that is, the MAC address of the receiving end of the DSA unicast data frame. The peer MAC address is obtained in the previous communication process. According to another embodiment of the present disclosure, in the DSA unicast mode, the DME-ProviderService.request service primitive may also include the peer MAC address and the source MAC address. The source MAC address is the local MAC address of the sender device, which can be obtained in the previous communication process, or can be generated by the sender adaptation layer and uploaded to the application layer layer by layer. In the case that the application layer has not yet learned the source MAC address, the source MAC address can be set to 0 or other default values. At step 7.a', after receiving the request, the DME replies to DME-ProviderService.confirm and enters the DSA message unicast sending process. By setting the repetition rate parameter in DME-ProviderService.request, the periodic sending of the DSA unicast message can be achieved.

[0151] Accordingly, at step 7.b, the receiving end shall complete the interaction between the application layer and DME before conducting DSA unicast communication. The application layer indicates its interest in the business services related to the DSA unicast frame through DME-UserService.request, in which the AID included is the same as the AID in the DME-ProviderService.request service primitive in step 7.a. At step 7.b', after receiving the request, the DME replies with DME-UserService.confirm, and then screens out the DSA message including the AID.

[0152] Next, the sender can use DSA as the data part of the DSM frame, which is sent by the DME and passes through the DSMP, adaptation layer, and access layer in sequence, and is transmitted to the access layer of the receiving end through the access layer communication protocol, and then uploaded to the high-level layer of the receiving end layer by layer. Figure 6 The DSA broadcast communication process described is similar, but the address setting method in the inter-layer service primitive of the sender is different. The specific process is as follows.

[0153] At step 7.c, the transmitting DME determines the data portion of the DSM and passes the data packet to the DSMP through the DSM.request primitive, including information such as data, AID, source MAC address, and peer MAC address. The source MAC address and the peer MAC address can be obtained from the DME-ProviderService.request service primitive from the application layer. According to another embodiment, in the case where the source MAC address is not included in the DME-ProviderService.request service primitive from the application layer, the source MAC address may not appear in the DSM.request service primitive, or the DME may set the source MAC address in the DSM.request service primitive to all 0s or other default values.

[0154] At step 7.d, the transmitting end DSMP adds a DSMP frame header to the data packet and passes it to the adaptation layer through the ADAPTATION-LAYER.request service primitive. The service primitive includes information such as data, AID, extension, source address, and destination address, wherein the source address and the destination address can be filled in with the adaptation layer address generated by converting the source MAC address and the peer MAC address in DSM.request. According to another embodiment of the present disclosure, when the source MAC address is not included in the DSM.request service primitive, the DSMP entity can fill in the source address in the ADAPTATION-LAYER.request service primitive with all 0s.

[0155] At step 7.e, the transmitting adaptation layer adds an adaptation layer frame header and passes it to the access layer through the ACCESS-LAYER.request service primitive. The service primitive includes data, source layer 2 identifier, destination layer 2 identifier, and extended information, etc., but does not include AID. AID is included in the data part. The source and destination layer 2 identifiers can be filled in as the source address in ADAPTATION-LAYER.request and the 24-bit MAC address in the destination address. According to one embodiment of the present disclosure, when the source address in the ADAPTATION-LAYER.request service primitive from the DSMP layer is all 0, the source layer 2 identifier can be generated by the adaptation layer.

[0156] In step 7.f, the access layer at the sending end adds an access layer frame header related to the access layer technology, and unicasts the DSM message carrying the DSA frame to the receiving end.

[0157] In step 7.g, the receiving end access layer receives the DSM message, obtains the data, source end layer 2 identifier, destination end layer 2 identifier and other information from its data packet, and informs the adaptation layer through ACCESS-LAYER.indication.

[0158] At step 7.h, the receiving adaptation layer obtains the source address and destination address from the layer 2 identifier in ACCESS-LAYER.indication, and informs the DSMP layer of the address and data information through ADAPTATION-LAYER.indication. In the DSA unicast communication process, the source layer 2 identifier and peer layer 2 identifier obtained by the adaptation layer from the access layer are the MAC address of the sender and the MAC address of the receiver, respectively, which can be directly converted into the source address and the destination address and passed to the DSMP layer.

[0159] At step 7.i, the receiving end DSMP layer sends data and AID information to the DME through the DSM.indication service primitive. According to one embodiment of the present disclosure, in the DSA unicast mode, DSM.indication may also include the source MAC address and the peer MAC address, so as to inform the application layer of the sender MAC address of the DSA unicast frame for subsequent communication processes. In this embodiment, it is possible to jump directly from step 7.i to step 7.k.

[0160] According to another embodiment of the present disclosure, even if a DSA unicast message is received, the DSMP layer at the receiving end will inform the DME of the source MAC address and the peer MAC address through the Address.indication service primitive at step 7.j to facilitate subsequent communication processes.

[0161] At step 7.k, the receiving end DME filters out the required DSA message through AID matching. According to one embodiment of the present disclosure, the receiving end DME can notify the application layer through the DME-Event.indication service primitive that it has received the service message of interest and can perform subsequent operations. The DME-Event.indication service primitive may include information data carried by the AID and DSA frame. According to another embodiment of the present disclosure, the DME-Event.indication service primitive may also include the MAC address of the transceiver obtained by the DME from the DSM.indication or Address.indication service primitive for subsequent communication processes.

[0162] Figure 8 The unicast communication flow chart of the dedicated short message data frame according to the embodiment of the present disclosure is shown. In the example where the on-board unit (OBU) sends a unicast DSM frame to the roadside unit (RSU), Figure 8 The sending end shown may be an OBU, and the receiving end may be an RSU. In the example where the RSU sends a unicast DSM frame to the OBU, Figure 8 The transmitting end shown may be an RSU, and the receiving end may be an OBU.

[0163] First, at step 8.a and step 8.a', the receiving end completes the interaction between the application layer and DME for the DSM data frame unicast service, that is: the receiving end indicates to the DME through the DME-DSMService.request primitive that the application layer requests the short message service. After receiving the request, the DME replies with DME-DSMService.confirm, and in the subsequent communication process, it sends a DSM message with the corresponding AID to the upper layer.

[0164] At step 8.b, the sending application layer determines the data portion of the DSM and passes the data packet to the DSMP through the DSM.request service primitive. The service primitive includes information such as data, AID, and MAC address, where the source MAC address is the MAC address of the sender and the peer MAC address is the MAC address of the receiving end known to the application layer.

[0165] In step 8.c, the sending DSMP adds a DSMP frame header to the data packet and passes it to the adaptation layer through the ADAPTATION-LAYER.request service primitive. The service primitive includes information such as data, AID, extension, source and destination addresses, where the source and destination addresses are filled in with the adaptation layer addresses generated by converting the source and peer MAC addresses in DSM.request.

[0166] At step 8.d, the sending adaptation layer adds an adaptation layer frame header and passes it to the access layer through the ACCESS-LAYER.request service primitive. The service primitive includes data, source layer 2 identifier, destination layer 2 identifier, and extended information, but does not include AID. AID is included in the data part. The source and destination layer 2 identifiers can be filled in as the 24-bit MAC address in the source address and destination address in ADAPTATION-LAYER.request.

[0167] In step 8.e, the access layer of the transmitting end unicasts the DSM message carrying the data to the receiving end.

[0168] In step 8.f, the receiving end receives the DSM message, the access layer sends data to the adaptation layer, obtains the source layer 2 identifier and the destination layer 2 identifier from the data packet, and informs the adaptation layer through the ACCESS-LAYER.Indication service primitive.

[0169] In step 8.g, the receiving adaptation layer obtains the source address and the destination address from the source layer 2 identifier and the destination layer 2 identifier in ACCESS-LAYER.indication, and informs the DSMP layer of the sender and receiver addresses and data information through ADAPTATION-LAYER.indication.

[0170] In step 8.h, the receiving DSMP layer sends data, AID, source MAC address, peer MAC address and other information to the application layer, where the source and peer MAC addresses are obtained through the addresses in ADAPTATION-LAYER.indication. The application layer knows that the corresponding service message has been received through the AID and can perform subsequent operations.

[0171] The following will be combined Fig. 9 and Fig.10 Specifically, an example of a message interaction process in which an OBU initiates a unicast connection communication by utilizing the DSA broadcast, DSA unicast and DSM unicast communication methods according to the present disclosure is described.

[0172] Fig. 9A unicast connection communication flow chart 900 is shown, which is initiated by an on-board unit according to an embodiment of the present disclosure. The unicast connection communication process 900 implements the unicast connection establishment process dominated by the RSU by being activated by the OBU. The unicast connection communication process 900 includes three stages: connection establishment, data interaction, and connection release. The connection establishment stage includes step 910 of broadcasting a wake-up message, step 920 of sending a unicast service announcement, and step 930 of unicasting a connection acceptance message. In different embodiments, step 920 may include sending a unicast service announcement message in a broadcast manner, or may include sending a unicast service announcement message in a unicast manner. The data interaction stage includes step 940 of unicast information communication from the RSU to the OBU, and step 950 of unicast information communication from the OBU to the RSU. The connection release stage includes step 950 of unicasting a connection release announcement message by the RSU. According to process 900, when there is no communication demand, the RSU can be in a dormant state, waiting for the OBU to wake up, so as to reduce unnecessary resource consumption. The following will be combined with Figure 6-8 Each step is described in detail.

[0173] In step 910, OBU sends a wake-up message in a broadcast mode to wake up RSU. When OBU needs to obtain service or detects entering a service area, a wake-up message can be actively sent to make RSU enter the working mode and start leading the unicast connection establishment process. The wake-up operation actively performed by OBU can be defined as another type of service that is different from subsequent unicast connection services, for example, wake-up service. Application identifier AID1 can be used to identify the wake-up service. According to different design methods, AID1 can have different specific numerical values.

[0174] In addition, if Fig. 9 As shown, step 910 includes repeatedly sending the wake-up message until a unicast service announcement message is received from the RSU in step 920. In order to prevent the OBU from repeatedly sending when it cannot receive a response from the RSU, in one embodiment, a timer mechanism can be used. When step 910 starts sending the wake-up message, the timer is started, and the wake-up message is repeatedly sent in a specific period. When the timer times out, step 910 stops sending the wake-up message. In another embodiment, a counter mechanism can be used. When step 910 starts sending the wake-up message, the counter is started, and the number of times the wake-up message is repeatedly sent is counted. When the counter value reaches a preset threshold, step 910 stops sending the wake-up message.

[0175] In step 910, the OBU may adopt Figure 6 The DSA data frame broadcast communication method shown is used to send the wake-up message, where the sending end is the OBU and the receiving end is the RSU. Figure 6In step 6.a, the OBU application layer indicates to the DME through the DME-ProviderService.request service primitive that the application layer requests to send a DSA data frame carrying a wake-up message. The service primitive may include the application identifier AID1 that identifies the wake-up service, the repetition rate for repeatedly sending the wake-up message, and other parameters. In step 6.a', after receiving the request, the DME replies DME-ProviderService.confirm and enters the wake-up message broadcast sending process. Figure 6 In step 6.b, the RSU application layer indicates to the DME that it is interested in the wake-up service through DME-UserService.request, and the service primitive includes the application identifier AID1. In step 6.b', after receiving the request, the DME replies with DME-UserService.confirm, and then filters out the DSA data frame including AID1.

[0176] exist Figure 6 At step 6.c, the DME of the OBU generates a DSA data frame according to the request from the application layer, and passes the data frame to the DSMP through the DSM.request service primitive, which contains the application identifier AID1. At step 6.d, the DSMP entity of the OBU adds a DSMP frame header to the data frame to generate a DSM data frame, and passes it to the adaptation layer through the ADAPTATION-LAYER.request service primitive, which includes the application identifier AID1, and the source address and destination address are all 0. At step 6.e, the OBU adaptation layer adds an adaptation layer frame header, generates a local MAC address (i.e., the MAC address of the OBU) as the source layer 2 identifier, uses AID1 to map the destination layer 2 identifier, and passes it to the access layer through the ACCESS-LAYER.request service primitive. At step 6.f, the OBU access layer broadcasts the DSM message carrying the wake-up message DSA to the RSU.

[0177] exist Figure 6At step 6.g, the RSU access layer receives the DSM message, obtains the data, source layer 2 identifier, destination layer 2 identifier and other information from its data packet, and informs the RSU adaptation layer through ACCESS-LAYER.indication. At step 6.h, the RSU adaptation layer obtains the source address and destination address from the layer 2 identifier in ACCESS-LAYER.indication, and informs the DSMP layer of the address and data information through ADAPTATION-LAYER.indication, where the source address is the OBU address. In another embodiment, the RSU adaptation layer can generate the local MAC address of the RSU, and use the MAC address as the destination address, and pass it to the DSMP layer through the ADAPTATION-LAYER.indication service primitive. At step 6.i, the DSMP layer of the RSU sends the DSM.indication service primitive to the DME. In one embodiment, the DSM.indication service primitive may include data, AID1, source MAC address and peer MAC address. In another embodiment, when a DSA broadcast frame is received, the source MAC address and the peer MAC address may not appear in the DSM.indication service primitive. The DSMP layer of the RSU may inform the DME of the source MAC address and the peer MAC address through the Address.indication service primitive at step 6.j. At step 6.k, the DME of the RSU filters out the DSA data frame carrying the wake-up message through AID matching. The DME of the RSU may notify the application layer that the wake-up message has been received through the DME-Event.indication service primitive. The DME-Event.indication service primitive may include AID1 and data information of the wake-up message. The DME-Event.indication service primitive may also include the MAC address of the transceiver obtained by the DME from the DSM.indication or Address.indication service primitive. After receiving the wake-up message, the RSU application layer may enter the working mode and send a unicast service announcement message in step 920.

[0178] like Fig. 9As shown, step 920 includes repeatedly sending the unicast service announcement message until a connection acceptance message is received from the OBU in step 930. In order to prevent the RSU from constantly repeating the transmission when the response from the OBU cannot be received, in one embodiment, a timer mechanism can be adopted. When the unicast service announcement message is started at step 920, the timer is started, and the message is repeatedly sent in a specific period. When the timer times out, step 920 stops sending the unicast service announcement message. In another embodiment, a counter mechanism can be adopted. When the unicast service announcement message is started at step 920, the counter is started, and the number of times the message is repeatedly sent is counted. When the counter value reaches a preset threshold, step 920 stops sending the unicast service announcement message.

[0179] In the embodiment of sending the unicast service announcement message in a broadcast manner at step 920, the RSU may adopt the following method: Figure 6 In this embodiment, the process of RSU broadcasting and sending unicast service announcement message can refer to the process of OBU broadcasting and sending wake-up message in step 910, and the main difference is that: the sending end in step 920 is RSU, and the receiving end is OBU; the unicast service announcement message sent in step 920 belongs to unicast connection service, and the service type can be identified by application identifier AID2. According to different design methods, AID2 can have different specific values.

[0180] In the embodiment of sending the unicast service announcement message in unicast mode at step 920, the RSU may adopt the following method: Figure 7 The DSA data frame is sent by unicast communication, wherein the sending end is RSU and the receiving end is OBU. Figure 7At step 7.a, the RSU application layer indicates to the DME through the DME-ProviderService.request service primitive that the application layer requests to send a DSA unicast data frame carrying a unicast service announcement message. According to one embodiment of the present disclosure, the DME-ProviderService.request service primitive includes parameters such as the application identifier AID2 that identifies the unicast connection service, the repetition rate for repeatedly sending the unicast service announcement message, and the peer MAC address. The peer MAC address is the MAC address of the receiving end (i.e., OBU) of the DSA unicast data frame. The peer MAC address may be obtained by the RSU application layer from the DME entity through the DME-Event.indication service primitive in step 910. According to another embodiment of the present disclosure, the DME-ProviderService.request service primitive may further include a source MAC address. The source MAC address is the MAC address of the RSU. In the case where the RSU application layer has not yet learned the source MAC address, the source MAC address may be set to 0 or other default values. At step 7.a', the RSU's DME receives the request and replies with DME-ProviderService.confirm, entering the unicast sending process of the unicast service announcement message. Correspondingly, at step 7.b, the RSU application layer indicates its interest in the unicast connection service with the application identifier AID2 through DME-UserService.request. At step 7.b', the DME receives the request and replies with DME-UserService.confirm, and then filters out the DSA message including AID2.

[0181] exist Figure 7 At step 7.c, the DME of the RSU generates a DSA data frame according to the request from the application layer, and passes the data frame to the DSMP through the DSM.request service primitive, which includes information such as data, AID2, source MAC address, and peer MAC address. The source MAC address and the peer MAC address can be obtained from the DME-ProviderService.request service primitive from the application layer, wherein the peer MAC address is the MAC address of the OBU, and the source MAC address can be the MAC address of the RSU, or it can be all 0 or other default values. According to another embodiment, when the source MAC address is not included in the DME-ProviderService.request service primitive from the application layer, the source MAC address may not appear in the DSM.request service primitive, or the DME may set the source MAC address in the DSM.request service primitive to all 0 or other default values.

[0182] exist Figure 7 At step 7.d, the DSMP entity of the RSU adds a DSMP frame header to the data packet and passes it to the adaptation layer through the ADAPTATION-LAYER.request service primitive. The service primitive includes information such as data, AID2, extension, source address, and destination address, wherein the destination address is the address of the OBU, and the source address can be filled in as the address generated by converting the source MAC address in the DSM.request. According to another embodiment of the present disclosure, when the source MAC address is not included in the DSM.request service primitive, the DSMP entity can fill in the source address in the ADAPTATION-LAYER.request service primitive as all 0 or other default values. At step 7.e, the RSU adaptation layer adds an adaptation layer frame header and passes it to the access layer through the ACCESS-LAYER.request service primitive. The service primitive includes data, source layer 2 identifier, destination layer 2 identifier, and extended information. The source and destination layer 2 identifiers can be filled in as the 24-bit MAC addresses in the source address and destination address in the ADAPTATION-LAYER.request. According to an embodiment of the present disclosure, when the source address in the ADAPTATION-LAYER.request service primitive from the DSMP layer is all 0 or other default values, the source layer 2 identifier can be generated by the adaptation layer and filled in with the 24-bit MAC address of the RSU. At step 7.f, the RSU access layer unicasts the DSM message carrying the unicast service announcement DSA to the OBU.

[0183] exist Figure 7At step 7.g, the OBU access layer receives the DSM message, obtains data, source layer 2 identifier, destination layer 2 identifier and other information from its data packet, and informs the OBU adaptation layer through ACCESS-LAYER.indication. At step 7.h, the OBU adaptation layer obtains the source address and destination address from the layer 2 identifier in ACCESS-LAYER.indication, and informs the DSMP layer of information such as the address and data through ADAPTATION-LAYER.indication, where the source address is the RSU address and the destination address is the OBU address. At step 7.i, the DSMP layer of the OBU sends a DSM.indication service primitive to the DME. In one embodiment, the DSM.indication service primitive may include data, AID2, source MAC address and peer MAC address. In another embodiment, the source MAC address and peer MAC address may not appear in the DSM.indication service primitive. The DSMP layer of the OBU can inform the DME of the source end MAC address and the peer end MAC address through the Address.indication service primitive at step 7.j. At step 7.k, the DME of the OBU filters out the DSA data frames related to the unicast connection service through AID matching. The DME of the OBU can notify the application layer that the DSA data frames related to the unicast connection service have been received through the DME-Event.indication service primitive. The DME-Event.indication service primitive may include AID2 and data information of the unicast service announcement message. The DME-Event.indication service primitive may also include the transceiver MAC address obtained by the DME from the DSM.indication or Address.indication service primitive. The OBU application layer can determine that the unicast service announcement message has been received based in part on the application identifier and / or data information in the DME-Event.indication service primitive.

[0184] After receiving the unicast service announcement message, the OBU stops sending the wake-up message and replies to the RSU with a connection acceptance message in a unicast manner in step 930 to complete the unicast connection establishment process. Figure 7The DSA data frame unicast communication mode shown in the figure is used to send the connection acceptance message. The processing process of the OBU sending the connection acceptance message in a unicast manner in step 930 can refer to the processing process of the RSU sending the unicast service announcement message in a unicast manner in step 920. After the RSU application layer determines that the unicast connection acceptance message replied by the OBU has been received, it stops sending the unicast service announcement, completes the unicast connection establishment process, and uses the dedicated unicast link to enter the data interaction phase.

[0185] The data interaction stage includes: in step 940, the RSU sends a data interaction request message to the OBU using a DSM data frame in a unicast manner, and in step 950, the OBU completes the response operation and also replies with a data interaction response message in a unicast manner using a DSM data frame. The specific process of the DSM unicast method can be referred to in conjunction with Figure 8 Described communication flow.

[0186] When the RSU determines that the current service has been completed, in step 960, the RSU sends a connection release announcement message to the OBU in a unicast manner to inform the OBU it serves that the communication connection has been released. Figure 7 The DSA data frame unicast communication mode shown is used to send the connection release message. The process of the RSU sending the connection release message in unicast mode in step 960 can refer to the process of the RSU sending the unicast service announcement message in unicast mode in step 920, and the main difference is that the content carried by the DSA data frame in step 960 is the connection release message.

[0187] Fig.10 A unicast connection communication flow chart 1000 is shown according to another embodiment of the present disclosure, which is initiated by the on-board unit. The unicast connection communication process 1000 implements a unicast connection establishment process initiated and dominated by the OBU on the basis of enhancing the OBU function. The unicast connection communication process generally includes three stages: connection establishment, data interaction, and connection release. The connection establishment stage includes step 1010 of broadcasting a connection request message, step 1020 of unicasting a connection acceptance message, and step 1030 of unicasting a connection confirmation message. The data interaction stage includes step 1040 of unicast information communication from the RSU to the OBU, and step 1050 of unicast information communication from the OBU to the RSU. The connection release stage includes step 1050 of unicasting a connection release announcement message by the RSU. According to process 1000, when there is no communication demand, the RSU is in a dormant state, waiting for the OBU to actively send a connection request to reduce unnecessary resource consumption. The following will be combined with Figure 6-8 Each step is described in detail.

[0188] In step 1010, the OBU sends a connection request message in a broadcast mode. When the OBU needs to obtain a service or detects that it has entered a service area, it can actively send a unicast connection request message. Fig.10 As shown, step 1010 includes repeatedly sending a connection request message until a connection acceptance message is received from the RSU in step 1020. In order to prevent the OBU from repeatedly sending when it cannot receive a response from the RSU, in one embodiment, a timer mechanism can be used. When step 1010 starts to send a connection request message, a timer is started, and the connection request message is repeatedly sent in a specific period. When the timer times out, step 1010 stops sending the connection request message. In another embodiment, a counter mechanism can be used. When step 1010 starts to send a connection request message, a counter is started, and the number of times the connection request message is repeatedly sent is counted. When the counter value reaches a preset threshold, step 1010 stops sending the connection request message.

[0189] In step 1010, the OBU may adopt Figure 6 The DSA data frame broadcast communication mode shown is used to send the connection request message, where the sending end is the OBU and the receiving end is the RSU. Figure 6 In step 6.a, the OBU application layer indicates to the DME through the DME-ProviderService.request service primitive that the application layer requests to send a DSA data frame carrying a connection request message. The service primitive may include the application identifier AID2 that identifies the unicast connection service, the repetition rate for repeatedly sending the connection request message, and other parameters. In step 6.a', after receiving the request, the DME replies DME-ProviderService.confirm and enters the connection request message broadcast sending process. Figure 6 In step 6.b, the RSU application layer indicates to the DME its interest in the unicast connection service through DME-UserService.request, which includes the application identifier AID2. In step 6.b', after receiving the request, the DME replies with DME-UserService.confirm, and then filters out the DSA data frame including AID2.

[0190] exist Figure 6At step 6.c, the DME of the OBU generates a DSA data frame according to the request from the application layer, and passes the data frame to the DSMP through the DSM.request service primitive, which contains the application identifier AID2. At step 6.d, the DSMP entity of the OBU adds a DSMP frame header to the data frame to generate a DSM data frame, and passes it to the adaptation layer through the ADAPTATION-LAYER.request service primitive, which includes the application identifier AID2, and the source address and destination address are all 0. At step 6.e, the OBU adaptation layer adds an adaptation layer frame header, generates a local MAC address (i.e., the MAC address of the OBU) as the source layer 2 identifier, uses AID1 mapping to obtain the destination layer 2 identifier, and passes it to the access layer through the ACCESS-LAYER.request service primitive. At step 6.f, the OBU access layer broadcasts the DSM message carrying the connection request message DSA to the RSU.

[0191] exist Figure 6At step 6.g, the RSU access layer receives the DSM message, obtains the data, source layer 2 identifier, destination layer 2 identifier and other information from its data packet, and informs the RSU adaptation layer through ACCESS-LAYER.indication. At step 6.h, the RSU adaptation layer obtains the source address and destination address from the layer 2 identifier in ACCESS-LAYER.indication, and informs the DSMP layer of the address and data information through ADAPTATION-LAYER.indication, where the source address is the OBU address. In another embodiment, the RSU adaptation layer can generate the local MAC address of the RSU, and use the MAC address as the destination address, and pass it to the DSMP layer through the ADAPTATION-LAYER.indication service primitive. At step 6.i, the DSMP layer of the RSU sends the DSM.indication service primitive to the DME. In one embodiment, the DSM.indication service primitive may include data, AID2, source MAC address and peer MAC address. In another embodiment, when a DSA broadcast frame is received, the source MAC address and the peer MAC address may not appear in the DSM.indication service primitive. The DSMP layer of the RSU may inform the DME of the source MAC address and the peer MAC address through the Address.indication service primitive at step 6.j. At step 6.k, the DME of the RSU filters out the DSA data frames related to the unicast connection service through AID matching. The DME of the RSU may notify the application layer that a message related to the unicast connection service has been received through the DME-Event.indication service primitive. The DME-Event.indication service primitive may include AID2 and data information of the connection request message. The DME-Event.indication service primitive may also include the MAC address of the transceiver obtained by the DME from the DSM.indication or Address.indication service primitive. The application layer may determine that a connection request message has been received based in part on the application identifier and / or data information in the DME-Event.indication service primitive. After receiving the connection request message, the RSU may enter the working mode and send a connection acceptance message in step 1020 .

[0192] like Fig.10As shown, step 1020 includes repeatedly sending the connection acceptance message until a connection confirmation message is received from the OBU in step 1030. In order to prevent the RSU from constantly repeating the transmission when it cannot receive a response from the OBU, in one embodiment, a timer mechanism can be adopted. When step 1020 starts to send the connection acceptance message, the timer is started, and the message is repeatedly sent in a specific cycle. When the timer times out, step 1020 stops sending the connection acceptance message. In another embodiment, a counter mechanism can be adopted. When step 1020 starts to send the connection acceptance message, a counter is started, and the number of times the message is repeatedly sent is counted. When the counter value reaches a preset threshold, step 1020 stops sending the connection acceptance message.

[0193] In step 1020, the RSU may adopt Figure 7 The DSA data frame is sent by unicast communication, wherein the sending end is RSU and the receiving end is OBU. Figure 7 At step 7.a, the RSU application layer indicates to the DME through the DME-ProviderService.request service primitive that the application layer requests to send a DSA unicast data frame carrying a connection acceptance message. According to one embodiment of the present disclosure, the DME-ProviderService.request service primitive includes parameters such as the application identifier AID2 that identifies the unicast connection service, the repetition rate for repeatedly sending the connection acceptance message, and the peer MAC address. The peer MAC address is the MAC address of the receiving end (i.e., OBU) of the DSA unicast data frame. The peer MAC address may be obtained by the RSU application layer from the DME entity through the DME-Event.indication service primitive in step 1010. According to another embodiment of the present disclosure, the DME-ProviderService.request service primitive may further include a source MAC address. The source MAC address is the MAC address of the RSU. In the case where the RSU application layer has not yet learned the source MAC address, the source MAC address may be set to 0 or other default values. At step 7.a', the RSU's DME receives the request and replies with DME-ProviderService.confirm, entering the connection acceptance message unicast sending process. Correspondingly, at step 7.b, the RSU application layer indicates its interest in the unicast connection service with application identifier AID2 through DME-UserService.request. At step 7.b', the DME receives the request and replies with DME-UserService.confirm, and then filters out the DSA message including AID2.

[0194] exist Figure 7At step 7.c, the DME of the RSU generates a DSA data frame according to the request from the application layer, and passes the data frame to the DSMP through the DSM.request service primitive, which includes information such as data, AID2, source MAC address, and peer MAC address. The source MAC address and the peer MAC address can be obtained from the DME-ProviderService.request service primitive from the application layer, wherein the peer MAC address is the MAC address of the OBU, and the source MAC address can be the MAC address of the RSU, or it can be all 0 or other default values. According to another embodiment, when the source MAC address is not included in the DME-ProviderService.request service primitive from the application layer, the source MAC address may not appear in the DSM.request service primitive, or the DME may set the source MAC address in the DSM.request service primitive to all 0 or other default values.

[0195] exist Figure 7 At step 7.d, the DSMP entity of the RSU adds a DSMP frame header to the data packet and passes it to the adaptation layer through the ADAPTATION-LAYER.request service primitive. The service primitive includes information such as data, AID2, extension, source address, and destination address, wherein the destination address is the address of the OBU, and the source address can be filled in as the address generated by converting the source MAC address in the DSM.request. According to another embodiment of the present disclosure, when the source MAC address is not included in the DSM.request service primitive, the DSMP entity can fill in the source address in the ADAPTATION-LAYER.request service primitive as all 0 or other default values. At step 7.e, the RSU adaptation layer adds an adaptation layer frame header and passes it to the access layer through the ACCESS-LAYER.request service primitive. The service primitive includes data, source layer 2 identifier, destination layer 2 identifier, and extended information. The source and destination layer 2 identifiers can be filled in as the 24-bit MAC addresses in the source address and destination address in the ADAPTATION-LAYER.request. According to an embodiment of the present disclosure, when the source address in the ADAPTATION-LAYER.request service primitive from the DSMP layer is all 0 or other default values, the source layer 2 identifier can be generated by the adaptation layer and filled in with the 24-bit MAC address of the RSU. At step 7.f, the RSU access layer unicasts the DSM message carrying the connection acceptance message DSA to the OBU.

[0196] exist Figure 7At step 7.g, the OBU access layer receives the DSM message, obtains data, source layer 2 identifier, destination layer 2 identifier and other information from its data packet, and informs the OBU adaptation layer through ACCESS-LAYER.indication. At step 7.h, the OBU adaptation layer obtains the source address and destination address from the layer 2 identifier in ACCESS-LAYER.indication, and informs the DSMP layer of information such as the address and data through ADAPTATION-LAYER.indication, where the source address is the RSU address and the destination address is the OBU address. At step 7.i, the DSMP layer of the OBU sends a DSM.indication service primitive to the DME. In one embodiment, the DSM.indication service primitive may include data, AID2, source MAC address and peer MAC address. In another embodiment, the source MAC address and peer MAC address may not appear in the DSM.indication service primitive. The DSMP layer of the OBU can inform the DME of the source MAC address and the peer MAC address through the Address.indication service primitive at step 7.j. At step 7.k, the DME of the OBU filters out the DSA data frames related to the unicast connection service through AID matching. The DME of the OBU can notify the application layer that the DSA data frames related to the unicast connection service have been received through the DME-Event.indication service primitive. The DME-Event.indication service primitive may include AID2 and data information of the connection acceptance message. The DME-Event.indication service primitive may also include the transceiver MAC address obtained by the DME from the DSM.indication or Address.indication service primitive. The OBU application layer can determine that the connection acceptance message has been received based in part on the application identifier and / or data information in the DME-Event.indication service primitive.

[0197] After receiving the connection acceptance message, the OBU stops sending the connection request message and replies to the RSU with a connection confirmation message in a unicast manner in step 1030 to complete the unicast connection establishment process. Figure 7 The DSA data frame unicast communication mode shown in the figure is used to send the connection confirmation message. The processing process of the OBU sending the connection confirmation message in a unicast manner in step 1030 can refer to the processing process of the RSU sending the connection acceptance message in a unicast manner in step 1020. After the RSU application layer determines that the unicast connection confirmation message replied by the OBU has been received, it stops sending the connection acceptance message, completes the unicast connection establishment process, and uses the dedicated unicast link to enter the data interaction phase.

[0198] The data interaction stage includes: in step 1040, the RSU sends a data interaction request message to the OBU using a DSM data frame in a unicast manner, and in step 1050, the OBU completes the response operation and also replies with a data interaction response message in a unicast manner using a DSM data frame. The specific process of the DSM unicast method can be referred to in conjunction with Figure 8 Described communication flow.

[0199] When the RSU determines that the current service has been completed, in step 1060, the RSU sends a connection release announcement message to the OBU in a unicast manner to inform the OBU it serves that the communication connection has been released. Figure 7 The DSA data frame unicast communication mode shown is used to send the connection release message. The process of the RSU sending the connection release message in unicast mode in step 1060 can refer to the process of the RSU sending the unicast service announcement message in unicast mode in step 1020, and the main difference is that the content carried by the DSA data frame in step 1060 is the connection release message.

[0200] The present disclosure also provides a computer-readable storage medium. Figure 4A or computer executable code of the method described in 4B.

[0201] The present disclosure also provides a computer program product. The computer program product includes a computer program product that can be executed by a processor to implement the combination Figure 4A Or instructions of the method described in 4B.

[0202] In the embodiments of the present disclosure, by utilizing the combination Figure 6-8 The DSA broadcast, DSA unicast, and DSM unicast communication modes described in this document provide Figure 9-10 The unicast connection communication process initiated by OBU is shown.

[0203] The unicast communication process initiated by the OBU provided in the present invention is based on the communication solution implemented by the LTE-V2X technology with better performance. It can be used in the vehicle network service scenario actively initiated by the vehicle, and is particularly suitable for near-field payment services when the vehicle is stopped. It has strong flexibility and applicability, and further reduces unnecessary repeated information transmission, saving communication overhead.

[0204] Those skilled in the art should understand that the various embodiments disclosed above may be subject to various modifications and variations without departing from the essence of the invention, and these modifications and variations should fall within the protection scope of the present invention, and the protection scope of the present invention should be defined by the claims.

Claims

1. A method for wireless communication of an on-board unit, comprising: Sending a connection request message in a broadcast manner, wherein the connection request message is used to request to establish a unicast connection; receiving, from a roadside unit, a connection acceptance message sent in a unicast manner in response to the connection request message, the connection acceptance message being used to notify the roadside unit of a unicast connection service capability; And in response to receiving the connection acceptance message, sending a connection confirmation message to the roadside unit in a unicast manner, wherein the connection confirmation message is used to confirm to the roadside unit that the unicast connection is established.

2. The method according to claim 1, wherein: The sending of the connection request message comprises: repeatedly sending the connection request message, and stopping sending the connection request message when one of the following items is satisfied: a timer for repeatedly sending the connection request message times out; a counter for sending the connection request message reaches a threshold; or the connection acceptance message is received.

3. The method according to claim 2, wherein: The connection request message is sent by broadcasting a dedicated service announcement (DSA) data frame, wherein the DSA data frame includes an application identifier (AID) for identifying a unicast connection service.

4. The method according to claim 3, wherein: The sending of the connection request message comprises: sending a request from the application layer to a dedicated management entity DME for requesting to send the DSA data frame, wherein the request comprises the AID and a repetition rate, and the repetition rate is used to repeatedly send the connection request message.

5. The method according to claim 1, wherein: The connection acceptance message is sent in a unicast manner via a dedicated service announcement DSA data frame, wherein the DSA data frame includes an application identifier AID that identifies a unicast connection service.

6. The method according to claim 5, wherein: The receiving connection acceptance message includes: before the receiving, sending a request from the application layer to the dedicated management entity DME, the request including the AID; and receiving an indication from the DME at the application layer, the indication including the AID identifying the unicast connection service, the source address, and the peer address, wherein the source address is the address of the roadside unit, and the peer address is the address of the on-board unit.

7. The method according to claim 1, wherein: The connection confirmation message is sent in a unicast manner via a dedicated service announcement DSA data frame, and the DSA data frame includes an application identifier AID that identifies a unicast connection service.

8. The method according to claim 7, wherein: The sending of the connection confirmation message includes: sending a request from the application layer to a dedicated management entity DME to request sending the DSA data frame, wherein the request includes the AID and a peer address, and the peer address is the address of the roadside unit.

9. The method according to claim 7, wherein: The sending of the connection confirmation message includes: sending a request from the application layer to the dedicated management entity DME to request sending the DSA data frame, the request includes the AID, the peer address, and the source address, the peer address is the address of the roadside unit, and the source address is the address of the vehicle-mounted unit.

10. The method according to claim 1, further comprising: receiving data information sent in unicast mode from the roadside unit; And sending data information to the roadside unit in a unicast manner, wherein the data information is sent in a unicast manner via a dedicated short message DSM data frame.

11. The method according to claim 1, further comprising: A connection release announcement message sent in unicast mode is received from the roadside unit, wherein the connection release announcement message is used to release the unicast connection established with the roadside unit, and the connection release announcement message is sent in unicast mode via a dedicated service announcement DSA data frame, and the DSA data frame includes an application identifier AID that identifies the unicast connection service.

12. A method for wireless communication of a roadside unit, comprising: Receiving a connection request message sent by the on-board unit in a broadcast manner, wherein the connection request message is used to request to establish a unicast connection; In response to receiving the connection request message, sending a connection acceptance message to the onboard unit in a unicast manner, wherein the connection acceptance message is used to notify the roadside unit of the unicast connection service capability; And receiving a connection confirmation message sent in a unicast manner in response to the connection acceptance message from the onboard unit, wherein the connection confirmation message is used to confirm the establishment of the unicast connection to the roadside unit.

13. The method according to claim 12, wherein: The connection request message is sent by broadcasting a dedicated service announcement (DSA) data frame, wherein the DSA data frame includes an application identifier (AID) for identifying a unicast connection service.

14. The method according to claim 13, wherein: The receiving of the connection request message includes: before the receiving, sending a request from the application layer to a dedicated management entity DME, the request including the AID; and receiving an indication from the DME at the application layer, the indication including the AID identifying the unicast connection service, the source address, and the peer address, the source address is the address of the on-board unit, and the peer address is the peer address in the connection request message or the address of the roadside unit obtained from the adaptation layer.

15. The method according to claim 12, wherein: The sending of the connection accept message comprises: repeatedly sending the connection accept message, and stopping sending the connection accept message when one of the following items is satisfied: a timer for repeatedly sending the connection accept message times out; a counter for sending the connection accept message reaches a threshold; or the connection confirmation message is received.

16. The method according to claim 15, wherein: The connection acceptance message is sent in a unicast manner via a dedicated service announcement DSA data frame, wherein the DSA data frame includes an application identifier AID that identifies a unicast connection service.

17. The method according to claim 16, wherein: The sending of the connection acceptance message includes: sending a request from the application layer to the dedicated management entity DME to request sending the DSA data frame, the request including the AID, the repetition rate, and the peer address, wherein the repetition rate is used to repeatedly send the connection acceptance message, and the peer address is the address of the on-board unit.

18. The method according to claim 16, wherein: The sending of the connection acceptance message includes: sending a request from the application layer to the dedicated management entity DME to request sending the DSA data frame, the request including the AID, repetition rate, peer address, and source address, wherein the repetition rate is used to repeatedly send the connection acceptance message, the peer address is the address of the on-board unit, and the source address is a default value or the address of the roadside unit obtained from the adaptation layer.

19. The method according to claim 12, wherein: The connection confirmation message is sent in a unicast manner via a dedicated service announcement DSA data frame, and the DSA data frame includes an application identifier AID that identifies a unicast connection service.

20. The method according to claim 19, wherein: The receiving connection confirmation message includes: before the receiving, sending a request from the application layer to the dedicated management entity DME, the request including the AID; and receiving an indication from the DME at the application layer, the indication including the AID, a source end address, and a peer end address, wherein the source end address is the address of the on-board unit, and the peer end address is the address of the roadside unit.

21. The method of claim 12, further comprising: Sending data information to the onboard unit in a unicast manner; And receiving data information sent in a unicast manner from the onboard unit, wherein the data information is sent in a unicast manner via a dedicated short message DSM data frame.

22. The method of claim 12, further comprising: A connection release announcement message is sent to the on-board unit in a unicast manner, wherein the connection release announcement message is used to release the unicast connection established with the on-board unit, and the connection release announcement message is sent in a unicast manner via a dedicated service announcement DSA data frame, and the DSA data frame includes an application identifier AID that identifies the unicast connection service.

23. A device for wireless communication of a vehicle-mounted unit, comprising: Memory; and at least one processor, coupled to the memory and configured to: send a connection request message in a broadcast manner, the connection request message being used to request establishment of a unicast connection; receiving a connection acceptance message sent in a unicast manner in response to the connection request message from the roadside unit, the connection acceptance message being used to notify the unicast connection service capability of the roadside unit; And in response to receiving the connection acceptance message, sending a connection confirmation message to the roadside unit in a unicast manner, wherein the connection confirmation message is used to confirm to the roadside unit that the unicast connection is established.

24. A device for wireless communication of a roadside unit, comprising: Memory; and at least one processor coupled to the memory and configured to: receive a connection request message sent by the onboard unit in a broadcast manner, the connection request message being used to request establishment of a unicast connection; In response to receiving the connection request message, sending a connection acceptance message to the onboard unit in a unicast manner, wherein the connection acceptance message is used to notify the roadside unit of the unicast connection service capability; And receiving a connection confirmation message sent in a unicast manner in response to the connection acceptance message from the onboard unit, wherein the connection confirmation message is used to confirm the establishment of the unicast connection to the roadside unit.

25. A computer-readable storage medium having stored thereon computer-executable codes for executing the method according to any one of claims 1-22.

26. A computer program product comprising instructions executable by a processor to implement the method according to any one of claims 1-22.

Images