Unicast communication method and device for vehicle networking

By introducing DSA and DSM unicast communication methods into the LTE-V2X network layer protocol stack, the problem of the inability to realize one-to-one unicast information interaction between the on-board unit and the roadside unit in the existing LTE-V2X standard is solved, and efficient unicast connection communication is achieved, improving service quality and reducing waste of communication resources.

CN114697901BActive Publication Date: 2025-05-02DENSO CORP
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202011561431.7
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2020-12-25
Publication Date
2025-05-02
Estimated Expiration
2040-12-25

AI Technical Summary

Technical Problem

The existing LTE-V2X standard can only support broadcast communication methods initiated by RSU, and cannot realize one-to-one unicast information interaction between vehicle-mounted units and vehicles, roadside units, and pedestrians, resulting in waste of communication resources and unsuitable service quality in application scenarios where the vehicle is actively initiated when the vehicle is stopped.

Method used

The LTE-V2X network layer protocol stack introduces dedicated service announcement (DSA) data frame broadcast communication method, DSA data frame unicast communication method, and dedicated short message (DSM) unicast communication method, through these methods, the unicast connection communication process initiated by the OBU is realized.

Benefits of technology

In the application scenario where the vehicle is actively initiated when the vehicle is stopped, efficient unicast communication between the on-board unit and the roadside unit is realized, which reduces the waste of communication resources, improves service quality, and is suitable for a variety of Internet of Vehicles communication application scenarios.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114697901B_ABST
    Figure CN114697901B_ABST
Patent Text Reader

Abstract

The present invention discloses a method and device for data frame communication. The method includes receiving a user service request from an application layer at a dedicated management entity. The user service request includes an application identifier of an interested service. The method also includes receiving a dedicated short message indication from a dedicated short message protocol layer at the dedicated management entity. The dedicated short message indication includes received data and a received application identifier. If the received application identifier matches the application identifier of the interested service, an event indication is sent by the dedicated management entity to the application layer. The event indication includes the received data and the received application identifier.
Need to check novelty before this filing date? Find Prior Art

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 onboard 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 onboard 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, the payment is initiated actively. Only when the vehicle enters the service area and there is a communication demand, it is necessary to establish a connection and complete the service, 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 improves the information interaction between the protocol layers in the LTE-V2X network layer protocol stack, and provides a dedicated service announcement (DSA) data frame broadcast communication mode, a DSA data frame unicast communication mode, and a dedicated short message (DSM) unicast communication mode. By using the DSA broadcast, DSA unicast and DSM unicast communication modes according to the present disclosure, the unicast connection communication process initiated by the OBU can be realized.

[0006] In one aspect, the present disclosure provides a method for data frame communication. The method includes: receiving a user service request from an application layer at a dedicated management entity DME, the user service request including an application identifier AID of an interested service; receiving a dedicated short message DSM indication from a dedicated short message protocol DSMP layer at the DME, the DSM indication including received data and received AID; if the received AID matches the AID of the interested service, the DME sends an event indication to the application layer, the event indication including the received data and the received AID.

[0007] On the other hand, the present disclosure also provides a device for data frame communication. The device includes: a memory; and at least one processor, which is coupled to the memory and is configured to: receive a user service request from an application layer at a dedicated management entity DME, the user service request including an application identifier AID of an interested service; receive a dedicated short message DSM indication from a dedicated short message protocol DSMP layer at the DME, the DSM indication including received data and received AID; if the received AID matches the AID of the interested service, the DME sends an event indication to the application layer, the event indication including the received data and the received AID.

[0008] On the other hand, the present disclosure also provides a computer-readable storage medium having stored thereon computer executable code for executing the following method steps: at a dedicated management entity DME, receiving a user service request from an application layer, the user service request including an application identifier AID of a service of interest; at the DME, receiving a dedicated short message DSM indication from a dedicated short message protocol DSMP layer, the DSM indication including received data and a received AID; if the received AID matches the AID of the service of interest, the DME sends an event indication to the application layer, the event indication including the received data and the received AID.

[0009] On the other hand, the present disclosure also provides a computer program product, comprising instructions that can be executed by a processor to implement the following operations: at a dedicated management entity DME, receiving a user service request from an application layer, the user service request including an application identifier AID of a service of interest; at the DME, receiving a dedicated short message DSM indication from a dedicated short message protocol DSMP layer, the DSM indication including received data and a received AID; if the received AID matches the AID of the service of interest, the DME sends an event indication to the application layer, the event indication including the received data and the received AID.

[0010] 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

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

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

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

[0014] Figure 4 A flow chart of an exemplary method for data frame communication according to an embodiment of the present disclosure is shown.

[0015] Figure 5 A block diagram of an exemplary device for data frame communication according to an embodiment of the present disclosure is shown.

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

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

[0018] 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.

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

[0020] 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

[0021] 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.

[0022] Figure 1 A protocol stack framework diagram of the LTE-based vehicle networking wireless communication technology is shown. The protocol stack of LTE vehicle networking wireless communication equipment (e.g., OBU and RSU) mainly includes an application layer, a network layer, and an 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.

[0023] 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, dedicated short message protocol (DSMP) layer, and 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 be used to 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.

[0024] 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).

[0025] 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.

[0026] 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 2As 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.

[0027] like Figure 2 As described, the DSA data frame 220 includes two parts: a DSA frame header and application information. The DSA frame header part includes: a DSA version, used to distinguish different DSA version numbers; a DSA frame header extension field indication, used to indicate whether the following frame header extension field appears; a reserved field, reserved for other functions; a DSA identifier (ID), used to identify the uniqueness of the DSA; a content count, used to identify whether it is a repetition of the previous DSA when the DSA ID is the same; a frame header extension field, used for other information, for example, used to indicate different functions of data information. The application information part includes: an application information count, used to indicate how many application information there are in total; an application identifier (AID), used to distinguish different application services; an application extension field, 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.

[0028] Figure 3 The schematic diagram of the process of encapsulating a dedicated short message data frame between protocol layers is shown. 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 2The 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, the PC5 interface). The receiving end may 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.

[0029] According to one embodiment, the above interaction between protocol layers can be implemented through data sublayer service primitives. In addition to the above 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.

[0030] 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.

[0031] The function and parameter 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 according to the unicast communication process of the present disclosure is not limited to the concrete form of the following service primitives.Those skilled in the art can come to mutually implement the information according to the unicast communication process of the present disclosure between each protocol layer by other means.These other means are all within the scope of the present disclosure.

[0032] 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 an embodiment of the present disclosure, the service primitive parameters are as follows:

[0033]

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

[0035]

[0036]

[0037] Table-1

[0038] 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.

[0039] 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 the request, it starts unicast, multicast, or broadcast DSA for the upper layer. The parameters of this service primitive are as follows:

[0040]

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

[0042]

[0043]

[0044] Table-2

[0045] 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:

[0046]

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

[0048]

[0049] Table-3

[0050] The DME-UserService.confirm service primitive is used to confirm 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:

[0051]

[0052]

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

[0054]

[0055] Table-4

[0056] 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:

[0057]

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

[0059]

[0060] Table-5

[0061] 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:

[0062]

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

[0064]

[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, 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] Table 9 describes the parameters of the DSM.indication service primitive.

[0082]

[0083] Table-9

[0084] 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.

[0085] 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:

[0086]

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

[0088]

[0089] Table-10

[0090] 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.

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

[0092]

[0093]

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

[0095]

[0096] Table-11

[0097] 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:

[0098]

[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 the 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]

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

[0108]

[0109]

[0110] Table-13

[0111] 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:

[0112]

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

[0114]

[0115] Table-14

[0116] Figure 4A flow chart of an exemplary method 400 for data frame communication according to an embodiment of the present disclosure is shown. The data frame communication method 400 can be used for DSA data frame unicast communication and DSA data frame broadcast communication to carry control plane messages exchanged between the OBU and the RSU in the unicast connection communication process initiated by the OBU. The method 400 can be used to receive DSA broadcast / unicast data frames and can also be used to send DSA broadcast / unicast data frames. The method 400 can be performed by an on-board unit (OBU) or a roadside unit (RSU).

[0117] At block 410, method 400 may include receiving a user service request from an application layer at a dedicated management entity (DME). The user service request includes an application identifier AID of the service of interest. The user service request is used to inform the DME of the service type that the upper layer user wishes to receive. The user service request may include a DME-UserService.request service primitive. For example, according to one embodiment of the present disclosure, in a unicast connection communication process initiated by an OBU, if the RSU wishes to receive a wake-up message from the OBU, the RSU application layer may send a user service request to the DME, and the user service request includes an AID identifying the wake-up service to indicate interest in the wake-up service. For another example, according to another embodiment of the present disclosure, in a unicast connection communication process initiated by an OBU, if the RSU wishes to receive a connection request message from the OBU, the RSU application layer may send a user service request to the DME, and the user service request includes an AID identifying the unicast connection service to indicate interest in the unicast connection service.

[0118] At block 420, method 400 may include receiving, at the DME, a dedicated short message (DSM) indication from a dedicated short message protocol (DSMP) layer. The DSM indication may include a DSM.indication service primitive. The dedicated short message indication includes received data and a received AID. The received data may include a data portion in a DSM frame obtained by unpacking and decapsulating the DSMP layer. The received AID may include an application identifier (AID) in a DSMP frame header obtained by processing the DSMP layer. In the case where the DSM frame data portion carries a DSA frame, the received AID may include an AID value corresponding to the DSA frame.

[0119] On the one hand, the received data may be a DSA broadcast data frame. According to one embodiment, the DSM.indication service primitive sent from the DSMP layer to the DME at box 420 may also include the source MAC address and the peer MAC address of the received data. That is, even in the broadcast communication mode, the source MAC address and the peer MAC address in the DSM.indication service primitive are mandatory. The source MAC address and the peer MAC address may be obtained respectively through the source address and the destination address in the message from the lower layer, wherein the destination address may be a local MAC address generated by the adaptation layer of the receiving device. According to another embodiment, method 400 may further include receiving an address indication from the DSMP layer at the DME. The address indication may include the source MAC address and the peer MAC address of the received data. The address indication may include the Address.indication service primitive.

[0120] On the other hand, the received data may be a DSA unicast data frame. According to one embodiment, the DSM.indication service primitive sent from the DSMP layer to the DME at box 420 may also include the source MAC address and the peer MAC address of the received data. The source MAC address and the peer MAC address may be obtained respectively through the source address and the destination address in the message from the lower layer. According to another embodiment, the method 400 may further include receiving an address indication from the DSMP layer at the DME. The address indication may include the source MAC address and the peer MAC address of the received data. The address indication may include the Address.indication service primitive. That is, as long as the DSMP entity determines that a DSA data frame is received, even if it is a DSA unicast data frame, the DSMP entity may send the source MAC address and the peer MAC address in the DSA data frame to the DME entity through the Address.indication service primitive.

[0121] At block 430, if the received AID matches the AID of the service of interest, the method 400 may include sending an event indication by the DME to the application layer. The event indication includes the received data and the received AID. The event indication may include a DME-Event.indication service primitive. In an embodiment where the DME is able to obtain the source MAC address and the peer MAC address of the received data through a service primitive from a lower layer, the event indication sent by the DME to the application layer may also include the source MAC address and the peer MAC address.

[0122] By sending an indication to the application layer that the service of interest has been received, the application layer can be triggered to perform the subsequent process of unicast connection communication according to the present disclosure. For example, when the RSU application layer receives a wake-up message from the OBU, the RSU can lead the unicast connection establishment process by sending a unicast service announcement message. In an implementation method in which the application layer can obtain the MAC address of the OBU through the service primitive from the DME, the RSU can send a unicast service announcement message to the OBU through the DSA unicast communication method. For another example, when the RSU application layer receives a unicast connection establishment request message from the OBU, the RSU can accept the unicast connection request of the OBU by sending a connection acceptance message to the OBU in a unicast manner.

[0123] In order for the RSU to send unicast service announcement messages or unicast connection acceptance messages to the OBU through DSA unicast communication, Figure 4 Not shown, method 400 may also include receiving a provider service request from the application layer at the DME. The provider service request is used to request the sending of a DSA unicast data frame. The provider service request may include at least the peer MAC address of the DSA unicast data frame. The peer MAC address may be obtained through parameters in the service primitive from the DME. In another embodiment, the provider service request may include the source MAC address and the peer MAC address of the DSA unicast data frame. The source MAC address may be a local MAC address obtained from the adaptation layer. When the application layer has not yet obtained the local MAC address, the source MAC address may 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.

[0124] Figure 5 A block diagram of an exemplary device 500 for data frame communication according to an embodiment of the present disclosure is shown. The device 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. The processor 510 may be configured to execute the method 400 described in conjunction with FIG. 4 to implement DSA data frame unicast communication and DSA data frame broadcast communication, thereby carrying control plane messages exchanged between the OBU and the RSU in the unicast connection communication process initiated by the OBU. The device 500 may be located in an onboard unit (OBU) or in a roadside unit (RSU).

[0125] According to one embodiment, at least one processor 510 may be configured to: receive a user service request from an application layer at a DME, the user service request including an application identifier AID of a service of interest; receive a DSM indication from a DSMP layer at the DME, the DSM indication including received data and a received AID; if the received AID matches the AID of the service of interest, the DME sends an event indication to the application layer, the event indication including the received data and the received AID.

[0126] On the one hand, the received data may be a DSA broadcast data frame. According to one embodiment, the DSM indication sent from the DSMP layer to the DME may also include the source MAC address and the peer MAC address of the received data. The source MAC address and the peer MAC address may be obtained respectively through the source address and the destination address in the message from the lower layer, wherein the destination address may be a local MAC address generated by the adaptation layer of the receiving end device. According to another embodiment, at least one processor 510 may be further configured to receive an address indication from the DSMP layer at the DME. The address indication may include the source MAC address and the peer MAC address of the received data.

[0127] On the other hand, the received data may be a DSA unicast data frame. According to one embodiment, the DSM indication sent from the DSMP layer to the DME may also include the source MAC address and the peer MAC address of the received data. The source MAC address and the peer MAC address may be obtained respectively through the source address and the destination address in the message from the lower layer. According to another embodiment, at least one processor 510 may be further configured to receive an address indication from the DSMP layer at the DME. The address indication may include the source MAC address and the peer MAC address of the received data.

[0128] When the DME is able to obtain the source MAC address and the peer MAC address of the received data through the service primitive from the lower layer, the event indication sent by the DME to the application layer may also include the source MAC address and the peer MAC address for subsequent unicast communication by the application layer. In order to enable the application layer to implement DSA unicast communication, at least one processor 510 may be further configured to receive a provider service request from the application layer at the DME. The provider service request is used to request the transmission of a DSA unicast data frame. The provider service request may include at least the peer MAC address of the DSA unicast data frame. The peer MAC address may be obtained through parameters in the service primitive from the DME. In another embodiment, the provider service request may include the source MAC address and the peer MAC address of the DSA unicast data frame. The source MAC address may be a local MAC address obtained from the adaptation layer. When the application layer has not yet obtained the local MAC address, the source MAC address may 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.

[0129] The following will be combined Figure 6-8 The 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.

[0130] 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 may be an OBU, and the receiving end may 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.

[0131] 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.

[0132] 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.

[0133] Next, the sender can use DSA as the data part of the DSM frame, which is sent by DME, 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 is uploaded to the high layer of the receiving end layer by layer. The specific process is as follows.

[0134] 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.

[0135] 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.

[0136] At step 6.e, the transmitting end 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 the following Table 15, 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.

[0137]

[0138] Table-15

[0139] 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.

[0140] 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.

[0141] 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.

[0142] 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.

[0143] 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.

[0144] At step 6.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, which is conducive to the receiving end adopting a unicast communication mode in the subsequent communication process.

[0145] Figure 7 The 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 sending end shown can be an OBU, and the receiving end can 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.

[0146] 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 DSA unicast message can be sent periodically.

[0147] 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 service 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.

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

[0149] At step 7.c, the transmitting end 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 DSM.request service primitive may not include the source MAC address, or the DME may set the source MAC address in the DSM.request service primitive to all 0s or other default values.

[0150] 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.

[0151] 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.

[0152] 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.

[0153] 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 the data packet, and informs the adaptation layer through ACCESS-LAYER.indication.

[0154] 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.

[0155] 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.

[0156] 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.

[0157] 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.

[0158] Figure 8The 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.

[0159] First, at step 8.a and step 8.a', the receiving end completes the interaction between the application layer and the 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.

[0160] 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.

[0161] 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.

[0162] At step 8.d, the sending adaptation layer adds the 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.

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

[0164] 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.

[0165] 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.

[0166] 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.

[0167] 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 modes according to the present disclosure is described.

[0168] Fig. 9 A 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.

[0169] In step 910, OBU sends wake-up message in broadcast mode, to be used for waking up RSU. When OBU needs to obtain service or detects entering service area, can actively send wake-up message, make RSU enter operating mode and begin leading unicast connection establishment process.The wake-up operation that OBU actively carries out can be defined as another kind of business type that is different from follow-up unicast connection business, for example, wake-up business.Can use application identifier AID1 to identify wake-up business.According to different design modes, AID1 can have different specific numerical values.

[0170] 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.

[0171] 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 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 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 with 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.

[0172] 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 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.

[0173] 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 can 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.

[0174] 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.

[0175] 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 The DSA data frame broadcast communication method shown in FIG. 1 is used for transmission. 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 transmitting 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.

[0176] 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 in a unicast communication mode, wherein the sending end is the RSU and the receiving end is the 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.

[0177] 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 transmits 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, 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 0 or other default values.

[0178] 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 extension 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.

[0179] 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 the address and data information through ADAPTATION-LAYER.indication, wherein 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 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, 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.

[0180] 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 stage.

[0181] 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.

[0182] 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.

[0183] 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.

[0184] 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. As shown in Figure 10, step 1010 includes repeatedly sending a connection request message until a connection acceptance message from the RSU is received in step 1020. In order to prevent the OBU from constantly repeating the transmission 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 cycle. 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.

[0185] 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 At 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. At step 6.a', after receiving the request, the DME replies DME-ProviderService.confirm and enters the connection request message broadcast sending process. Figure 6 At 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. At step 6.b', after receiving the request, the DME replies with DME-UserService.confirm, and then filters out the DSA data frame including AID2.

[0186] 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.

[0187] 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 can contain 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 .

[0188] 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.

[0189] 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.

[0190] 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 transmits 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, 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 0 or other default values.

[0191] 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 extension 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.

[0192] exist Figure 7 At 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 the address and data information through ADAPTATION-LAYER.indication, wherein 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 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, 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 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.

[0193] 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 7The 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 stage.

[0194] 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.

[0195] 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.

[0196] The present disclosure also provides a computer-readable storage medium. Figure 4 Computer executable code of the described method.

[0197] 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 4 Instructions for the described method.

[0198] 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.

[0199] The unicast communication process initiated by the OBU provided in the present invention is based on the LTE-V2X technology with better performance to implement the communication solution, which can be used in the vehicle networking 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.

[0200] 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 data frame communication, comprising: At the dedicated management entity DME, receiving a user service request from the application layer, the user service request including an application identifier AID of the service of interest; At the DME, receiving a dedicated short message DSM indication from a dedicated short message protocol DSMP layer, the DSM indication including received data and received AID; If the received AID matches the AID of the service of interest, the DME sends an event indication to the application layer, where the event indication includes the received data and the received AID.

2. The method according to claim 1, wherein: The received data is a dedicated service announcement DSA broadcast data frame, and wherein the DSM indication also includes the source MAC address and the peer MAC address of the received data, and the event indication also includes the source MAC address and the peer MAC address.

3. The method according to claim 2, wherein: The peer MAC address is a local MAC address generated by the adaptation layer.

4. The method according to claim 2, wherein: The service of interest is a wake-up service.

5. The method according to claim 1, wherein: The received data is a dedicated service announcement DSA unicast data frame, and wherein the DSM indication also includes the source MAC address and the peer MAC address of the received data, and the event indication also includes the source MAC address and the peer MAC address.

6. The method according to claim 1, further comprising: At the DME, receiving an address indication from the DSMP layer, the address indication including a source MAC address and a peer MAC address of the received data; And wherein, the event indication also includes the source MAC address and the peer MAC address.

7. The method according to claim 1, further comprising: At the DME, a provider service request is received from the application layer, wherein the provider service request is used to request sending a dedicated service announcement DSA unicast data frame, and the provider service request includes a peer MAC address of the DSA unicast data frame.

8. The method according to claim 1, further comprising: At the DME, a provider service request is received from the application layer, wherein the provider service request is used to request the sending of a dedicated service announcement DSA unicast data frame, and the provider service request includes a source MAC address and a peer MAC address of the DSA unicast data frame, wherein the source MAC address is a default value or a local MAC address obtained from an adaptation layer.

9. A device for data frame communication, comprising: Memory; as well as at least one processor coupled to the memory and configured to: At the dedicated management entity DME, receiving a user service request from the application layer, the user service request including an application identifier AID of the service of interest; At the DME, receiving a dedicated short message DSM indication from a dedicated short message protocol DSMP layer, the DSM indication including received data and received AID; If the received AID matches the AID of the service of interest, the DME sends an event indication to the application layer, where the event indication includes the received data and the received AID.

10. The device according to claim 9, wherein: The received data is a dedicated service announcement DSA broadcast data frame, and wherein the DSM indication also includes the source MAC address and the peer MAC address of the received data, and the event indication also includes the source MAC address and the peer MAC address.

11. The device according to claim 10, wherein: The peer MAC address is a local MAC address generated by the adaptation layer.

12. The device according to claim 10, wherein: The service of interest is a wake-up service.

13. The device according to claim 9, wherein: The received data is a dedicated service announcement DSA unicast data frame, and wherein the DSM indication also includes the source MAC address and the peer MAC address of the received data, and the event indication also includes the source MAC address and the peer MAC address.

14. The device according to claim 9, wherein: The at least one processor is further configured to: At the DME, receiving an address indication from the DSMP layer, the address indication including a source MAC address and a peer MAC address of the received data; And wherein, the event indication also includes the source MAC address and the peer MAC address.

15. The device according to claim 9, wherein: The at least one processor is further configured to: At the DME, a provider service request is received from the application layer, wherein the provider service request is used to request sending a dedicated service announcement DSA unicast data frame, and the provider service request includes a peer MAC address of the DSA unicast data frame.

16. The device according to claim 9, wherein: The at least one processor is further configured to: At the DME, a provider service request is received from the application layer, wherein the provider service request is used to request the sending of a dedicated service announcement DSA unicast data frame, and the provider service request includes a source MAC address and a peer MAC address of the DSA unicast data frame, wherein the source MAC address is a default value or a local MAC address obtained from an adaptation layer.

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

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

Citation Information

Patent Citations

  • Service cooperation system for vehicle

    CN107872777A

  • Method and apparatus for performing sidelink communication by UE in NR V2X

    CN111630933A