Patent Description:
The amount of vehicle-related data can in some cases overload communication resources used for the communications of vehicle-related data.

<CIT> discloses a network system where a first network node of a first frequency layer acquires information on services that are offered by a second network node at a second, different frequency layer. The second network node is within the coverage area of the first network node. The first network node broadcasts a service advertisement message to at least one terminal device (UE) for advertising the services offered by the second network node at the second frequency layer.

<CIT> discloses a method of sharing information among road side units, vehicles, road side unit repositories and pedestrians to enhance vehicular capabilities.

"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on architecture enhancements for the Evolved Packet System (EPS) and the <NUM> System (5GS) to support advanced V2X services (Release <NUM>)" discloses path-based QoS booking where the PLMN provides a booked resource token which the application can provide the UE so the UE can request the QoS when it comes to the desired node.

Moreover, the drawings provide examples and/or implementations consistent with the description;.

In some examples, communications in a network are governed by Institute of Electrical and Electronic Engineers (IEEE), Wi-Fi® Alliance standards, or European Telecommunications Standards Institute/Third Generation Partnership Project (ETSI/3GPP) standards. Some IEEE standards mentioned in the present disclosure include: IEEE <NUM>. 11ax (High Efficient WLAN task group within the IEEE <NUM> project), IEEE <NUM>. 11bd (Next Generation V2X - Vehicle to anything - task group within the IEEE <NUM> project), IEEE <NUM>. 11md (Revision and maintenance task group within the IEEE <NUM> project). ETSI/3GPP standards include different generations of cellular networks such as second generation (<NUM>) Global System for Mobile/General Packet Radio Service (GSM/GPRS), third generation (<NUM>) Universal Mobile Telecommunications (UMTS), fourth generation (<NUM>) Long Term Evolution (LTE), and fifth generation (<NUM>) New Radio (NR), as well as associated technologies such as PC5 Sidelink and Multimedia Broadcast Multicast Service (MBMS) broadcast channels.

The IEEE <NUM>. 11p-<NUM> amendment (part of the IEEE <NUM>-<NUM> standard) specifies usage of <NUM> megahertz (MHz) wide channels in the <NUM> gigahertz (GHz) band for a vehicular environment (in which communications occur between vehicles, between vehicles and road side units (RSUs), or between vehicles and other devices). IEEE <NUM>. 11p is an extension of IEEE <NUM>. 11a, where frames are transmitted in an un-associated state.

Communications in a vehicular environment can be referred to as "vehicle-related communications.

This <NUM> band is an example of a frequency band that is designated for vehicle-related communications (e.g., V2X communications). This frequency band designated for vehicle-related communications can also be referred to as Intelligent Transport System (ITS) band. A frequency band that is designated for vehicle-related communications can refer to a frequency band that is limited generally for use by services that participate in vehicle-related communications. Depending on local regulations, services that do not participate in vehicle-related communications should not use or are not allowed to use the frequency band designated for vehicle-related communications. An example of such a frequency designation is footnote NG160 of the FCC regulation <NUM> C.

A "frequency band" is defined as a range of frequencies. In some examples, a frequency band can include a contiguous range of frequencies that starts at a first frequency and ends at a second frequency. In other examples, a frequency band can include multiple non-contiguous ranges of frequencies.

More generally, a "band" can refer to a collection of communication resources (defined by any or some combination of frequency, time, coding, etc.). A band designated for vehicle-related communications refers to a collection of communication resources designated for vehicle-related communications.

V2X is a feature that provides for communication of information from a vehicle to other entities (and possibly also/alternatively vice versa) that may affect the vehicle and/or the other entities. V2X includes one or more of a subset of features, including communication of a vehicle to/from any or some combination of the following: other vehicles (vehicle-to-vehicle or V2V communication); an infrastructure, e.g., RSUs (vehicle-to-infrastructure or V2I communication); a pedestrian (vehicle-to-pedestrian or V2P communication); a network (vehicle-to-network or V2N communication); a device, e.g., an electronic device within the vehicle (vehicle-to-device or V2D communication), an electricity grid (vehicle-to-grid or V2G communication); and so forth.

IEEE <NUM>. 11p-compliant devices use a special operation mode referred to as Outside the Context of a BSS (OCB). No authentication/association of a device with a network has to be performed before the device can communicate application data or service data over the network with another device. The only parameter to be configured is a frequency channel (central frequency and bandwidth) to communicate on. The frequency channel (or more simply "channel") is known before hand and is typically assigned as part of the definition of a particular V2X application at a higher layer. Communication is broadcast addressed or unicast addressed. Many V2X applications rely exclusively on the unacknowledged broadcasting mode.

A V2X endpoint device refers to an electronic device that is able to participate in a V2X communication. A V2X endpoint device can include a vehicle, an electronic device (e.g., a desktop computer, a notebook computer, a tablet computer, a smartphone, a wearable device, a game appliance, etc.), an RSU (which refers to any equipment that is provided on a road, on the side of a road, or in proximity to a road, such as for example, a traffic light, an electronic sign, a toll booth, or any other type of structure), a network node in a network, equipment in an electricity grid, and so forth.

The ITS band (or another frequency band designated for vehicle-related communications) may have a restricted capacity for transmission of information. As an ITS system adds new services that communicate data with possibly large payloads, the channels in the ITS band can become full. In other words, the bandwidth of the channels in the ITS band may become fully utilized such that further communications of information in the ITS band is not possible or may be delayed. A "channel" (or "frequency channel") can refer to a frequency portion of the ITS band. In further examples, a "channel" more generally refers to a communication resource, such as in a radio communication network, that can be used to carry data.

A "service" can refer to an entity (such as a program or a machine) or to a process or thread or any other type of activity.

To account for the restricted capacity of the ITS band, it may be desirable to offload the communication of data by certain services to another band that is outside of the ITS band. In some examples, such a band that is outside of the ITS band can be referred to as a non-ITS band. In further examples, there may be multiple non-ITS bands in which communications of information by certain services may be performed.

A first frequency band is outside a second frequency band if there is no overlap in frequencies between the first frequency band and the second frequency band.

Certain types of vehicle-related communications are considered to be critical, such as information related to safety of vehicles or information that should be communicated within a relatively short amount of time of an event that is associated with the communication of the information. Examples of such critical vehicle-related information include position and trajectory of a vehicle on a road, information about a collision, information about an obstacle in a roadway, information about local road environmental conditions (e.g., ice, floods, wind, sand, wind on a bridge, fog, etc.), information about a road closure, information about an emergency or priority vehicle, information about a failed road signal, and so forth. The communication of such critical vehicle-related information should still occur in the ITS band, or more generally, in a band designated for vehicle-related communications.

Other types of vehicle-related communications can be considered non-critical, such as communications not related to safety or communications where delays in the transmission of information can be tolerated. Examples of non-critical vehicle-related information include traveler information, attraction advertisement, information about congestion, new road layouts, information about traffic accident blackspots, information about cycle lane and road intersections signal and phase information, supplementary information about a critical event, and so forth.

An issue relates how to discover instances where vehicle-related communications of specific services are to occur in a non-ITS band.

In examples where there are multiple non-ITS bands provided by respective different types of networks, it may also be desirable to match different services to different non-ITS bands depending upon characteristics of the services and how they match up with performances of the respective different types of access networks that provide the respective non-ITS bands. Matching services to non-ITS bands may also relate to energy management for V2X systems. The different types of access networks can include a cellular access network, a Wireless Local Area Network (WLAN) (also referred to as a Wi-Fi® network), and so forth.

In some cases, certain non-ITS bands are available based on local direct communications between wireless devices that are locally within wireless range (e.g., radio range) of one another. If services are able to communicate over wireless networks that support communications over a large geographical region, then additional security should be implemented to protect such communications.

In the ensuing discussion, reference is made to ITS bands and non-ITS bands in some example implementations.

More generally, techniques or mechanisms according to the present disclosure may be applied to other types of bands, where a band designated for vehicle-related communications ("vehicle-related band") can include a collection of communication resources (defined by any or some combination of frequency, time, coding, etc.) designated for vehicle-related communications. A non-vehicle-related band can include another collection of communication resources that is outside of the band designated for vehicle-related communications. The non-vehicle-related band is not designated for vehicle-related communications, i.e., the non-vehicle-related band is not reserved for use for vehicle-related communications.

Techniques or mechanisms discussed in this sub-section can be used to address Issues <NUM> and <NUM> in Sections <NUM> and <NUM> above.

In accordance with some implementations of the present disclosure, techniques or mechanisms are provided to discover ITS services that have been offloaded from the ITS band (e.g., the <NUM> band) to non-ITS bands (of a WLAN, a cellular network, or another access network), or more generally, to discover vehicle-related services that have been offloaded from a vehicle-related band to one or more non-vehicle-related bands, which can be part of an unlicensed or licensed spectrum.

Note that the ITS band may be part of a wireless communication technology in which V2X endpoint devices are able to communicate directly with one another, without communicating data over a network infrastructure. On the other hand, one or more non-ITS bands are deployed over respective one or more access networks.

An "access network" can refer to a network including network equipment over which an endpoint device is able to obtain connectivity and to communicate with one or more other endpoint devices. An access network can include a wireless access network, such as a cellular access network, a WLAN, and so forth. A cellular access network can include an LTE access network, a <NUM> access network, or any other type of access network. In other examples, an access network can include a wired network, in which an endpoint device is connected by a wired connection to the network to perform communications.

In cases where both the ITS band and one or more non-ITS bands are employed for vehicle-related communications of IT services, multiple different types of communication technologies may be employed to perform the vehicle-related communications.

<FIG> is a block diagram of an example arrangement that includes one or more ITS services <NUM>, an RSU <NUM>, and a vehicle <NUM>. Although just one RSU and one vehicle are depicted in <FIG>, it is noted that in other examples, there can be more than one RSU and/or more than one vehicle.

Although <FIG> shows the ITS services <NUM> as being external of the RSU <NUM> and the vehicle <NUM>, in other examples, an ITS service <NUM> may be included in the RSU <NUM> or in the vehicle <NUM>.

<FIG> also shows various different types of access networks, including a WLAN <NUM>, and another access network <NUM> which can be of a different type than the WLAN <NUM>. For example, the other access network <NUM> may be a cellular access network.

In some examples, the RSU <NUM> may communicate with an ITS service <NUM> over a wired network <NUM>, or alternatively, through the WLAN <NUM> or the access network <NUM>.

The WLAN <NUM> includes one or more access points (APs) <NUM>, and the access network <NUM> includes a one or more network nodes <NUM>. In AP <NUM> is able to communicate wirelessly with a wireless device, such as the RSU <NUM> or the vehicle <NUM>. Similarly, the network node <NUM> is able to communicate wirelessly with a wireless device. If the access network <NUM> is a cellular access network, then the network node <NUM> can be referred to as a base station (also referred to as a NodeB, an eNodeB, a <NUM> base station, etc.).

The RSU <NUM> includes a communication interface <NUM> to perform a communication of information. A "communication interface" can include a communication transceiver to transmit and receive signals over a communication link, such as a wireless link. The communication interface can also include one or more protocol layers that govern use of one or more respective protocols for the communication of data.

The RSU <NUM> further includes a service information advertising engine <NUM> that is able to advertise service information in an ITS band. As used here, an "engine" can refer to a hardware processing circuit, which can include any or some combination of a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or another hardware processing circuit. Alternatively, an "engine" can refer to a combination of a hardware processing circuit and machine-readable instructions (software and/or firmware) executable on the hardware processing circuit.

Although just one communication interface <NUM> is shown in the RSU <NUM>, in other examples, the RSU <NUM> can include more than one communication interface to communicate according to different respective access technologies.

The vehicle <NUM> also includes a communication interface <NUM> (or multiple communication interfaces). In addition, the vehicle <NUM> includes an ITS communication engine <NUM> to perform vehicle -related communications.

In some examples, the communication interface <NUM> in the RSU <NUM> and the communication interface <NUM> in the vehicle <NUM> can be used to allow the RSU <NUM> and the vehicle <NUM> to communicate directly with one another, without using the network infrastructure of any access network, such as the WLAN <NUM> and the access network <NUM>, for example. Note that the communication interface <NUM> in the RSU <NUM> (or a different communication interface in the RSU <NUM>) can be used to communicate over an access network, such as the WLAN <NUM> or the access network <NUM>. Similarly, the communication interface <NUM> in the vehicle <NUM> (or different communication interface in the vehicle <NUM>) can be used to communicate over an access network.

A direct wireless communication between the RSU <NUM> and the vehicle <NUM> can employ any of various different communication technologies, such as Dedicated Short-Range Communications (DSRC) using IEEE <NUM>. 11p-<NUM>, LTE-V2X (PC5 interface), light communications (e.g. Li-Fi) link, and any other short range communication technology.

Techniques or mechanisms according to some examples are able to discover ITS services whose communications are provided over non-ITS bands. Generally, the ITS band can operate as an advertising resource that provides information regarding ITS services available in one or more non-ITS bands.

The ITS band can be used to advertise service information for communications of the ITS services <NUM>. In the example of <FIG>, the service information advertising engine <NUM> in the RSU <NUM> transmits the service information, such as over a direct link from the RSU <NUM> to the vehicle <NUM>.

In other examples, the service information advertising engine <NUM> can be included in a different node, other than the RSU <NUM>. For example, the service information advertising engine <NUM> can be included in another vehicle, a network node such as the AP <NUM> or the network node <NUM>, or any other device.

The service information can include information of one or more of the following characteristics of an ITS service that is to perform communications in a non-ITS band:.

Based on the service information advertised by the service information advertising engine <NUM>, the ITS communication engine <NUM> in the vehicle <NUM> can communicate vehicle-related data with an ITS service <NUM> over a non-ITS band, which can be provided by the WLAN <NUM> or the access network <NUM>, or both, for example.

In other examples, another endpoint devices can include an ITS communication engine similar to the ITS communication engine <NUM>, where this other endpoint device is also able to receive service information advertised by the service information advertising engine <NUM>, and to perform communication of vehicle-related data with an ITS service <NUM> over a non-ITS band.

The following describes examples of use cases.

In an example, the vehicle <NUM> receives (as part of advertised service information from the RSU <NUM> in a local direct radio transmission) a URL for a web service application programming interface (API) and other information about a given ITS service <NUM>. The ITS communication engine <NUM> in the vehicle <NUM> connects to the advertised URL over a cellular Transmission Control Protocol/Internet Protocol (TCP/IP) connection over a cellular network (e.g., <NUM>). The URL refers to the given ITS service <NUM> provided by a server, which in some examples may be located in a cloud operated by a third party (different from an operator of the cellular network or an operator of the RSU <NUM>). The given ITS service <NUM> can transmit vehicle-related data through the RSU <NUM>, such as current data about the state of a road infrastructure.

In another example, the vehicle <NUM> is a taxi queued to pick up passengers at an airport. The vehicle <NUM> receives (in a local direct radio transmission) service information about a given ITS service <NUM>. The service information may include information of the WLAN <NUM> used to communicate vehicle-related data of the given ITS service <NUM>. The vehicle <NUM> connects to the WLAN <NUM> while queued at the airport and is able to download vehicle-related data from a LAN behind the WLAN AP. In some examples, the vehicle <NUM> is able to download current information from a local server connected to the LAN, such that no Internet access is employed.

In another example, as shown in <FIG>, the ITS service <NUM> generates (at <NUM>) a new universally unique identifier (UUID) (which is an example of the requested token), and the ITS service <NUM> sends (at <NUM>) the token (UUID) to the RSU <NUM>. In response to the vehicle <NUM> requesting a token from the RSU <NUM>, the RSU <NUM> sends (at <NUM>) service information including the token (UUID) and a server URL relating to the ITS service <NUM> to the vehicle <NUM> over a local direct communication transmission. The vehicle <NUM> proceeds to access the ITS service <NUM> at the URL by sending (at <NUM>) to the ITS service <NUM> over an access network, the UUID as a token. The ITS service <NUM> determines (at <NUM>) from the token that the vehicle <NUM> is within proximity of the RSU <NUM>, for authenticating the vehicle <NUM>. The vehicle <NUM> subsequently receives vehicle-related data of the ITS service <NUM> over the access network (e.g., the WLAN <NUM> or the access network <NUM>).

Alternatively, the UUID can be generated at the RSU <NUM> and provided to the ITS service <NUM> for use by the ITS service <NUM> in authenticating the vehicle <NUM> based on proximity of the vehicle <NUM> to the RSU <NUM>.

In another example, a given ITS service <NUM> provides local fuel price information. The given ITS service <NUM> can be implemented using one or more servers that is (are) part of a cloud. The server(s) provide local fuel price information in different communities across the globe. Within a local community an RSU (e.g., the RSU <NUM>) transmits a specific URL or token that allows the vehicle <NUM> to download the correct local fuel information from the server(s). For example, a vehicle driving in Ottawa will access the Ottawa fuel prices and not the Vancouver fuel prices.

The following further sub-sections describe more specific mechanisms or techniques for advertising service information for communications of ITS services in non-ITS bands.

In some examples, a Wireless Access in Vehicular Environments (WAVE) Service Advertisement (WSA) message can be used to provide information about a non-ITS band service. WSA messages are defined according to IEEE <NUM>.

IEEE <NUM> WSA messages can be adapted to carry information about an available ITS service. The service information for the ITS service can include the following, as examples: channel number/band in license-exempt spectrum in which the receiver technology is a Wi-Fi® technology, or a URI/URL where the ITS service can be connected to using TCP/IP networking protocols (e.g., a cloud ITS service). This enables the WSA to advertise a service delivered in license-exempt spectrum, by a variety of radio technologies, as well as higher layer networking/internetworking technologies.

IEEE <NUM>-<NUM> Section <NUM> describes the WSA frame. Changes and updates proposed to the IEEE <NUM>-<NUM> standard, at a high level, include (further details are provided further below in <NUM>):.

A WSA message can include radio channel information, credentials for an access network such as a WLAN, service access information such as a service URL, and credential tokens to access the service.

As other illustrative examples for better understanding the present invention which are not covered by the appended claims, discovery messages can be used to advertise non-ITS band services. Examples of discovery messages include an Access Network Query Protocol (ANQP) message, a Generic Advertisement Service (GAS) message, and so forth. A wireless device (e.g., the vehicle <NUM>) can exchange ANQP and GAS messages with another device (e.g., the RSU <NUM>) without the wireless device having to first perform authentication and/or association with the other device.

ANQP is a query and response advertisement protocol that is used by a wireless device to discover a range of information about a wireless access network. GAS provides the Layer <NUM> transport for an advertisement protocol's frames between peer wireless devices prior to authentication.

Examples of information that can be advertised in a discovery message include a Wi-Fi® channel, a URI, and so forth, associated with vehicle-related data that is transmitted over a non-ITS band. The discovery message can include an ANQP reply that is transmitted in response to an ANQP query issued by a wireless device (e.g., the vehicle <NUM>) to another device (e.g., the RSU <NUM>). Changes can be made to ANQP to ensure that it can operate either between a wireless device and an RSU, or alternatively between two wireless devices. As another example, the discovery message can include a GAS reply that is transmitted in response to a GAS query issued by a wireless device (e.g., the vehicle <NUM>) to another device (e.g., the RSU <NUM>).

In other examples, instead of using a query/response technique, the advertisement of service information can be sent using a periodic frame (that is sent periodically).

A new WSMP frame (IEEE <NUM>) is created to encapsulate all the existing GAS responses (defined for IEEE <NUM>) operating with various advertisement protocols. The advertisement protocols include ANQP, Registered Location Query Protocol (RLQP), and Pre-Association Discovery (PAD) (11aq) payloads. Enhancements can be made to an advertisement protocol such as PAD to ensure that PAD can operate in a peer-to-peer mode and not be reliant on a network infrastructure or a server located in the network infrastructure. In the case of RLQP and PAD, servers would be located within or be connected to the peer wireless device.

In further examples, a broadcast public action frame is used to transmit WSAs (or WSA-type information) in an IEEE <NUM> channel (e.g., a <NUM> ITS channel). This can be a broadcast service information frame, which can be defined in IEEE <NUM>. 11bc (modified).

The following fields can be included in the enhanced service advertisement methods described in Sections <NUM>. <NUM>, <NUM>. <NUM>, and <NUM>.

In some examples, a channel number, channel width, and UARFCN are used by a receiving device to tune to another radio channel (possibly the same radio technology or a different radio technology) to receive vehicle-related data of the ITS service on that radio channel.

In some examples, a URL and a URI are used by the receiving device to connect to an ITS service over-the-top. Over the top means via an internetworking protocol on a wireless access network such as cellular network or a WLAN.

In some examples, a PSID indicates the particular ITS service being advertised. In many protocols, a PSID is an index number in a header indicating which upper layer application should handle decoding the contained packet. In the case of service advertisements, the PSID received is used to match a list of applications the receiving device is interested in receiving or has subscribed to. The receiving device uses the PSID to determine whether to access the advertised service or not.

In further examples, a Service Name, a Service Hash, a Service Type and/or a Service Subtype can be used instead of or in addition to a PSID.

A WLAN SSID, a Wi-Fi URI, and a PLMN are to provide information about an access network. The information about the access network may be accompanied in the same discovery message as the URL or URL information of the server at which the service is accessed. Providing both the information of the access network and the location on the network allows the service to be offered privately on the access network as opposed to the service being publicly accessible on the Internet. For example, the URI can refer to a server on a specific LAN/WLAN, or the URI can point to a Service Capability Exposure Function (SCEF) or a V2X Control Function (VCF) in a 3GPP network.

The WSA can be constructed in the form of a URI to encode this information of the WSA. The WSA payload can include a URI formatted as an IP URI or a WSA URI.

In a case where the service may be offered over a specific radio technology through IP connectivity, the service advertisement can include a WSA svc URI followed by a URL.

As an illustrative example for better understanding the present invention which is not covered by the appended claims, if a WSMP message is used to carry the enhanced service advertisement payload, the entire message can be signed to convey its authenticity to the receiving device. If another packet format is used a signature can be used to sign either the content of the service advertisement specifically, or the whole message in its entirety.

<FIG> shows an example packet <NUM> carrying a service advertisement <NUM> that is signed at the packet level. A "packet" refers to a unit of data that has a format specified by a protocol, for example. The service advertisement <NUM> includes service information <NUM> about an ITS service (such as any of the example service information discussed further above). In other examples, the service advertisement <NUM> can include multiple service information <NUM> about multiple ITS services.

The digital signature <NUM> is included in or attached to the packet <NUM>, where the digital signature <NUM> is derived by signing the content of the packet <NUM>, such as by using a cryptographic key.

<FIG> shows another example packet <NUM> that includes a service advertisement <NUM>. The service advertisement <NUM> includes service information <NUM> about an ITS service.

In <FIG>, the service information <NUM> is signed individually, rather than signing the entire packet <NUM> as shown in <FIG>. Accordingly, a signature <NUM> is produced based on signing the service information <NUM>, and the signature <NUM> is included in the packet <NUM>.

<FIG> shows another example packet <NUM> that includes a service advertisement <NUM>. The service advertisement <NUM> includes multiple service information <NUM>-<NUM> to <NUM>-N (N ≥ <NUM>) about respective multiple ITS services.

In <FIG>, each service information <NUM>-i (i = <NUM> to N) is signed individually. Accordingly, a signature <NUM>-i (i = <NUM> to N) is produced based on signing the service information <NUM>-i. The signatures <NUM>-<NUM> to <NUM>-N are included in the packet <NUM>.

<FIG> allows multiple service information about multiple ITS services to be sent in one message, where the multiple service information may be potentially signed by different sources.

For example, the RSU <NUM> at the intersection of a state freeway and a city road may advertise services signed by two different government agencies (a state agency and a city agency). The different signatures validate the different sources of the information providers, even though they are transmitted in the same WSA frame (more generally, packet). The service information being signed may come from different backend networks (e.g., LAN, WAN, Internet, etc.) into the RSU <NUM>.

Signatures may be produced using any of various different cryptographic algorithms. The different cryptographic algorithms can provide different levels of security based on a number of bits or other parameters of a cryptographic algorithm. Traveler information from a first source may have a different level of cryptographic protection than emergency information from a second source. Both can be transmitted from the same RSU <NUM>.

Techniques or mechanisms discussed in this sub-section can be used to address Issue <NUM> in Section <NUM> above.

As noted above, a direct wireless communication can be performed between the RSU <NUM> and the vehicle <NUM>. This is direct wireless communication is a short-range communication, where the RSU <NUM> and the vehicle <NUM> are able to communicate with one another directly if the vehicle <NUM> is within a specified distance of the RSU <NUM>. The specified distance can be a relatively short distance, such as less than <NUM> meters (m), or less than <NUM>, or less than <NUM>, or less than <NUM>, as examples.

A message, such as an advertisement including one or more service information of respective one or more ITS services, communicated using the direct wireless communication can be referred to as a "short-range message. " The short-range message can include a WSA message or a different type of message, as discussed in the present disclosure according to some examples.

In some examples, a short-range message (such as sent by the RSU <NUM> to the vehicle <NUM> over a direct wireless communication) can be used as a proximity verification for delivery of vehicle-related data of an ITS service using a server. The delivery of the vehicle-related data using the server can be based on use of a REpresentational State Transfer (REST) application programming interface (API), a URL/URI, a Message Queueing Telemetry Transport (MQTT), a Constrained Application Protocol (CoAP), an Active Message Queuing Protocol (AMQP), or another mechanism.

The vehicle <NUM> (or another receiving device of the short-range message) is verified to be at a particular geolocation based on the exchange of messages in the direct wireless communication, such as a DSRC communication, a 3GPP PC5 sidelink communication, and so forth. A "geolocation" refers to a geographic position.

In some examples, the vehicle <NUM> receives a broadcast short-lived token, such as in a WSA message transmitted in the ITS band. In other examples, a local cryptographic challenge/exchange is made on the local direct radio link. Messages can be transmitted in the ITS band to verify proximity or location of the vehicle <NUM>.

The token itself can be embedded in a URL path or URI. Embedding the token in a URL or URI can be used in a local direct radio link that is unacknowledged and unidirectional. The token is passed (such as from the RSU <NUM> to the vehicle <NUM> or from a transmitting vehicle to a receiving vehicle) over the local direct link radio link. In some examples, the token is validated by connections through an access network (e.g., the WLAN <NUM> or the access network <NUM>) to a central server by both devices (e.g., two vehicles, or an RSU and a vehicle).

In alternative examples, the token can be transmitted as part of a bidirectional exchange (such as between the RSU <NUM> and the vehicle <NUM> or between vehicles) in the ITS band. The bidirectional exchange can be part of a cryptographic challenge, for example. After the token is transmitted from a transmitting device to a receiving device, a user-specific token or voucher can provided to the receiving device (e.g., the vehicle <NUM>). In this case the local direct radio link is bidirectional and data is acknowledged and validated locally. Upon successful validation locally over the direct radio link, an ITS service is conditionally obtained from a central server over an access network.

Once the receiving device (e.g., the vehicle <NUM>) obtains the token or voucher (using any technique discussed above), the token is used over an access network (e.g., <NUM> or <NUM>) to access the ITS service (see <FIG> discussed above).

In some examples, the token or voucher can be any of the following:.

Tokens are chosen from a namespace or number space sufficient to prevent collisions for a particular target ITS service. This assures that with a medium level of security (for the broadcast token case) and a high level of security (for the local cryptographic challenge), the entity requesting a service over a network (e.g., the Internet or another unsecured network) indeed was/is present at a specific geolocation (or geographic region).

In some examples, the token may be signed for authenticity or encrypted for confidentiality.

In some examples, the token may contain information about the scope of the token's validity. Scope can be any of many things, with the following two examples provided. Scope can be a time during which the token remains valid. Scope can be a geolocation or geolocations within which the token is valid. Information of the scope may be contained in the token itself, or information of the scope can be stored by a server or service that maps a token to a scope the token represents.

In some examples, a security monitoring function at the server or service or an access control gateway to the server or service can monitor for misuse or abuse of tokens to access a service. This can be used to prevent fraudulent access requests and also to detect and prevent denial of service attacks.

There is a version number in the header of a WSA message. IEEE <NUM>-<NUM> Section <NUM>. <NUM> has defined Version <NUM>. A proposal according to some implementations of the present disclosure is for a later version which will be numbered <NUM> or higher.

An updated WSA frame format is shown in the top line of <FIG>.

A new WSA version may be reflected in a field <NUM>.

A Service Info Segment <NUM> can have a variable length. The detailed content of the Service Info Segment <NUM> is shown in the second line of <FIG>. There may be more than one Service Info Segment <NUM> in a single WSA.

A Radio Channel Info Segment <NUM> can have a variable length.

Multiple Channel Info Segments per Service Info Segment <NUM> are allowed, and a field <NUM> specifies a number of the Channel Info Segments.

A field <NUM> specifies a technology type, such as Wi-Fi®, Bluetooth®, <NUM>, <NUM>, etc..

A field <NUM> includes a PSID, a field <NUM> includes a service URI, a field <NUM> includes an access credential to access an access network, a field <NUM> includes a service credential to allow access of a service, a field <NUM> includes a proximity token as discussed further above, and a field <NUM> includes a WAVE Information Element Extension.

The other fields not labelled in <FIG> are existing fields as defined by the WSA protocol.

A new WSA service instance (an instance of an ITS service that supports WSA) according to some implementations of the present disclosure can satisfy any or some combination of the following, in some examples:.

A WSA URI provides information about ITS services. An example WSA URI is provided below. wsa-service-instance = "wsa-svc:"[channel-list ";"] [service-info ";"] [radio-technology
";"] [tech ";"] [service-type ";"] [psid]";;"
pkex-bootstrap-info = [information]
channel-list = "C:" class-and-channels *("," class-and-channels)
class-and-channels = class "/" channel *("," channel)
class = <NUM>*3DIGIT
channel = <NUM>*3DIGIT
service-info = "S:" *(%x20-3A / %x3C-7E); semicolon not allowed
radio-technology = "R:" tech *("," tech)
tech = "WiFi", "Cell", "Wave"
service-type = "PSID", "URL", "URI";
psid = *DIGIT.

The service-type parameter in the example WSA URI indicates the type of service. If the service-type is equal to "URL" or "URI", a URL or URI will follow the WSA URI in the frame.

<FIG> is a flow diagram of a process performed by a receiving device (e.g., the vehicle <NUM> of <FIG>) according to some examples.

The receiving device tunes (at <NUM>) its communication interface (e.g., a radio in the communication interface) to a control channel, which can be any of the following: IEEE <NUM>. 11p channel <NUM> (a DSRC channel), LTE-V2X channel <NUM> (a PC5 sidelink), and so forth.

The receiving device receives (at <NUM>), over the control channel, a WSA message from a nearby transmitting device (e.g., the RSU <NUM> of <FIG>, another vehicle, or another device).

The receiving device parses (at <NUM>) the received WSA message and determines a list of services (e.g., ITS services) that the WSA message advertises. A "list of services" can identify one service or multiple services.

The receiving device compares (at <NUM>) the list of services in the WSA message with a list of services programmed at the receiving device as being of interest to the receiving device. If the receiving device determines (at <NUM>) there is a match between the list of services in the WSA message and the list of services programmed at the receiving device, the receiving device proceeds to access the service, using any of the following: (<NUM>) if the service is to be accessed using a DSRC radio, the receiving device tunes (at <NUM>) to the DSRC radio to a channel/timeslot to receive further messages of the service, (<NUM>) if the service is to be accessed over a WLAN, the receiving device connects (at <NUM>) to the WLAN to access the service, or (<NUM>) if the service is to be accessed using a URI or URL, the receiving device fetches (at <NUM>) data at the URI or URL for the service over an access network, such as a cellular network.

<FIG> is a flow diagram of a process performed by a receiving device (e.g., the vehicle <NUM> of <FIG>) according to further examples.

The receiving device tunes (at <NUM>) its communication interface (e.g., a radio in the communication interface) to a control channel, which can be any of the following: IEEE <NUM>. 11p channel <NUM> (a DSRC channel), LTE-V2X channel <NUM> (a PC5 Sidelink), and so forth.

The receiving device parses (at <NUM>) the received WSA message and determines a list of services (e.g., ITS services) that the WSA message advertises.

The receiving device compares (at <NUM>) the list of services in the WSA message with a list of services programmed at the receiving device as being of interest to the receiving device. If the receiving device determines (at <NUM>) there is a match between the list of services in the WSA message and the list of services programmed at the receiving device, the receiving device performs the following.

A service advertised in the WSA may have more than one access method (e.g., a Signal Phase and Timing (SPAT) message on a DSRC channel or via a web API). In that case the receiving device has a prioritized order in which the receiving device decides which method to use to access the service. The receiving device selects (at <NUM>) an access method from among the multiple access methods according to the prioritized order. The receiving device then accesses (at <NUM>) the service using the selected access method.

<FIG> is a block diagram of a wireless device <NUM> (e.g., the RSU <NUM> or vehicle <NUM> of <FIG>, or another wireless device). The wireless device <NUM> can perform any of the tasks discussed herein.

The wireless device <NUM> includes a hardware processor <NUM> (or multiple hardware processors). A hardware processor can include a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or another hardware processing circuit.

The wireless device <NUM> includes a communication interface <NUM> to perform communications over a wireless network.

The wireless device <NUM> further includes a non-transitory machine-readable or computer-readable storage medium <NUM> that stores machine-readable instructions executable on the one or more hardware processors <NUM> to perform various tasks.

The machine-readable instructions include vehicle-related data communication control instructions <NUM> that are executable on the one or more hardware processors <NUM>. The vehicle-related data communication control instructions <NUM> can perform tasks of the service information advertising engine <NUM> in the RSU <NUM> of <FIG>, or can perform tasks of the ITS communication engine <NUM> in the vehicle <NUM> of <FIG>, or can perform any of the other tasks described in the present disclosure.

For example, the vehicle-related data communication control instructions <NUM> can be part of the RSU <NUM> and can cause transmission, within a first band designated for vehicle-related communications (e.g., an ITS band), of service information for a service, the service information including information of a channel in a second band (e.g., a non-ITS band) for communication of data of the service, the second band being outside of the first band.

In further examples, the service information further can include information indicating a stream characteristic of the communication of data of the service, and/or information relating to an identification or location of the service (e.g., a URI, a URL, a PSID, a service name, a service hash, a service type or subtype, etc.).

In some examples, the service information is transmitted by the wireless device <NUM> to a second wireless device, and the service information is included in a message prior to association of the second wireless device with the wireless device <NUM>.

In some examples, a first type of access network (e.g., DSRC link, PC5 sidelink, etc.) that supports the first band is different from a second type of access network (e.g., a WLAN, a cellular access network, etc.) that supports the second band.

In particular, the wireless device <NUM> sends a token to a second wireless device, where the token is useable by the second wireless device in securely accessing the service.

In particular, the token is sent to the second wireless device while the second wireless device is in a proximity of and communicating over a local wireless medium with the wireless device <NUM>, and where the access of the service by the second wireless device occurs over an access network that is separate from the local wireless medium.

In some examples, the token provides an indication that the second wireless device was within a specified geolocation of the wireless device <NUM> at a time the second wireless device received the token.

In other examples, the vehicle-related data communication control instructions <NUM> can be part of the vehicle <NUM>, and can cause the wireless device <NUM> to receive, from a second wireless device within a first band designated for vehicle-related communications, service information for a service. The vehicle-related data communication control instructions <NUM> cause the wireless device <NUM> to access the service using a channel in the second band advertised by the service information.

In some examples, the service information contains information for a plurality of services, and the vehicle-related data communication control instructions <NUM> cause the wireless device <NUM> to compare the plurality of services to information of one or more services stored at the wireless device <NUM>, and identify the service that is to be accessed based on the comparison.

In some examples, the service information indicates a plurality of different access techniques for accessing the service, and the vehicle-related data communication control instructions <NUM> cause the wireless device <NUM> to select, to use in accessing the service, an access technique from the plurality of different access techniques.

In some examples, the vehicle-related data communication control instructions <NUM> cause the wireless device <NUM> to confirm an authenticity of the service information based on signing of the service information represented by a signature.

In some examples, the wireless device <NUM> receives, from a second wireless device, a token while the wireless device <NUM> is in a proximity of the second wireless device, the token communicated over a local wireless medium, and the wireless device <NUM> accesses the service over an access network that is separate from the local wireless medium.

Techniques or mechanisms according to some implementations of the present disclosure may provide one or more of the following benefits: allow for more efficient use of the capacity of the ITS band, provide more flexible deployment of ITS service over one or more radio technologies, or provide harmonization of service discovery across multiple radios of which different receiving devices may have different sets of capabilities.

The local discovery mechanism may enable cloud services to be deployed locally and discovered locally, so that central management of the local services (which may be deployed at different geolocations) does not have to be performed.

The storage medium <NUM> can include any or some combination of the following: a semiconductor memory device such as a dynamic or static random access memory (a DRAM or SRAM), an erasable and programmable read-only memory (EPROM), an electrically erasable and programmable read-only memory (EEPROM) and flash memory or other type of non-volatile memory device; a magnetic disk such as a fixed, floppy and removable disk; another magnetic medium including tape; an optical medium such as a compact disk (CD) or a digital video disk (DVD); or another type of storage device. Note that the instructions discussed above can be provided on one computer-readable or machine-readable storage medium, or alternatively, can be provided on multiple computer-readable or machine-readable storage media distributed in a large system having possibly plural nodes. Such computer-readable or machine-readable storage medium or media is (are) considered to be part of an article (or article of manufacture). The storage medium or media can be located either in the machine running the machine-readable instructions, or located at a remote site from which machine-readable instructions can be downloaded over a network for execution.

The present disclosure also includes a computer-readable medium to cause a computer device, e.g. a wireless device, to perform the disclosed methods. For example, a non-transitory machine-readable storage medium comprising instructions that upon execution cause a first wireless device to transmit, within a first band designated for vehicle-related communications, service information for a service to a second wireless device, the service information comprising information of a channel in a second band for communication of data of the service, the second band being outside of the first band, is disclosed.

Claim 1:
A method comprising:
receiving, by a road side unit, RSU, (<NUM>) within a first frequency band designated for vehicle-related communications, a request from a vehicle (<NUM>) for a token to access a vehicle-related service (<NUM>); and
transmitting (<NUM>), by the road side unit, RSU, (<NUM>) within the first frequency band designated for vehicle-related communications, service information (<NUM>, <NUM>, <NUM>) for the vehicle (<NUM>) to access a vehicle-related service (<NUM>),
wherein the vehicle-related service is a service that has been offloaded from a vehicle-related frequency band to non-vehicle-related frequency bands,
the service information comprising information of a frequency channel (<NUM>) in a second frequency band for communication of data of the vehicle-related service (<NUM>), the second frequency band being outside of the first frequency band,
the service information further comprising the token used by the vehicle (<NUM>) as credential to access the vehicle-related service,
wherein the first frequency band is used for a direct short-range communication to verify the proximity or location of the vehicle (<NUM>) with the RSU (<NUM>) and communicating over a local wireless medium with the vehicle (<NUM>),
and wherein the token provides an indication that the vehicle (<NUM>) was within a specified geolocation of the RSU (<NUM>) at a time the vehicle (<NUM>) received the token,
and wherein the access of the vehicle-related service (<NUM>) by the vehicle (<NUM>) occurs over an access network (<NUM>, <NUM>) that is separate from the local wireless medium.