advertising service information for a service

Abstract

The present disclosure relates to advertising service information for a service. In some examples, a first wireless device transmits service information for a service within a first frequency band designated for vehicle-related communications, the service information including information of a channel in a second frequency band for communication of data for the service, the second frequency band being outside the first frequency band.

Description

Technical Field

[0001] This disclosure relates to the field of wireless communications, and more specifically, to service information regarding the notification of services. Background Technology

[0002] Vehicles may be provided with communication components to allow them to communicate with each other using networks or other service infrastructure, or using another device. Examples of data that can be transmitted or received by a vehicle may include data collected by sensors, operational information, status information, etc. Such data may be referred to as vehicle-related data.

[0003] The amount of vehicle-related data can overload communication resources used for vehicle-related data communication in some cases. Summary of the Invention

[0004] This disclosure provides a method comprising: transmitting service information for a service by a first wireless device in a first frequency band designated for vehicle-related communications, the service information including information about a channel in a second frequency band for data communication of the service, the second frequency band being outside the first frequency band.

[0005] This disclosure provides a first wireless device, including: a wireless interface; and at least one processor coupled to the wireless interface and configured to: receive service information for a service from a second wireless device in a first frequency band designated for vehicle-related communications, the service information including channel information in a second frequency band for data communication of the service outside the first frequency band, and to access the service using the channel in the second frequency band.

[0006] This disclosure provides a non-transient machine-readable storage medium including instructions that, when executed, cause a first wireless device to transmit service information for a service to a second wireless device within a first frequency band designated for vehicle-related communications. The service information includes information about a channel located in a second frequency band outside the first frequency band for data communication of the service. Attached Figure Description

[0007] Some implementations of this disclosure are described with reference to the following figures.

[0008] Figure 1A This is a block diagram illustrating an example arrangement of vehicles, roadside units, and access networks based on some implementations of this disclosure.

[0009] Figure 1B This is a message flow diagram of example procedures involving vehicle, roadside unit (RSU), and intelligent transportation system (ITS) services, based on some implementations of this disclosure.

[0010] Figures 2A-2CThe illustration shows example groups of service announcements included in some implementations of this disclosure.

[0011] Figure 2D The illustration shows an example format of a new wireless access (WAVE) service announcement (WSA) in a vehicle environment, according to some examples of this disclosure.

[0012] Figure 3 and Figure 4 This is a flowchart of an example process for a receiving device according to some implementations of this disclosure.

[0013] Figure 5 This is a block diagram of some implementations of wireless devices based on this disclosure.

[0014] Throughout the accompanying figures, the same reference numerals denote similar but not necessarily identical elements. The figures are not necessarily drawn to scale, and the dimensions of some parts may be exaggerated to more clearly illustrate the examples shown. Furthermore, the figures provide examples and / or implementations consistent with the description; however, the description is not limited to the examples and / or implementations provided in the figures. Detailed Implementation

[0015] In this disclosure, the terms “a,” “an,” or “the” are intended to include the plural form as well, unless the context clearly indicates otherwise. Similarly, when used in this disclosure, “include,” “including,” “comprise,” “comprising,” “have,” or “having” specifies the presence of the said element, but does not exclude the presence or addition of other elements.

[0016] In some examples, communication in the network is mediated by the Institute of Electrical and Electronics Engineers (IEEE). Alliance standards, or European Telecommunications Standards Institute / 3GPP standards management. Some IEEE standards mentioned in this disclosure include: IEEE 802.11ax (Efficient WLAN Task Group within the IEEE 802.11 project), IEEE 802.11bd (Next Generation V2X - Vehicle to Anything - Task Group within the IEEE 802.11 project), and IEEE 802.11md (Revision and Maintenance Task Group within the IEEE 802.11 project). ETSI / 3GPP standards include different generations of cellular networks (such as second-generation (2G) Global System for Mobile Communications / General Packet Radio Services (GSM / GPRS), third-generation (3G) Universal Mobile Telecommunications System (UMTS), fourth-generation (4G) Long Term Evolution (LTE), and fifth-generation (5G) New Radio (NR)) and related technologies (such as PC5 sidelinks and Multimedia Broadcast Multicast Service (MBMS) broadcast channels).

[0017] The IEEE 802.11p-2010 amendment (part of the IEEE 802.11-2016 standard) specifies the use of a 10 MHz wideband channel in the 5.9 GHz band for vehicular environments (where communication occurs between vehicles, between a vehicle and a roadside unit (RSU), or between a vehicle and other devices). IEEE 802.11p is an extension of IEEE 802.11a, in which frames are transmitted in a non-associative state.

[0018] Communication in the vehicle environment can be referred to as "vehicle-related communication".

[0019] The 5.9 GHz band is an example of a frequency band designated for vehicle-related communications (e.g., V2X communications). This designated frequency band for vehicle-related communications can also be referred to as the Intelligent Transportation Systems (ITS) band. A frequency band designated for vehicle-related communications can refer to a frequency band that is generally restricted to use by services participating in vehicle-related communications. Depending on local regulations, services not participating in vehicle-related communications should not use or are not permitted to use frequency bands designated for vehicle-related communications. An example of such frequency designation is footnote NG160 of FCC Regulation 47C.FR §2.106.

[0020] A “frequency band” is defined as a range of frequencies. In some examples, a frequency band may include a continuous range of frequencies that begins at a first frequency and ends at a second frequency. In other examples, a frequency band may include multiple discontinuous frequency ranges.

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

[0022] V2X is a feature that provides communication from a vehicle to other entities (and possibly also / or alternatively, to the vehicle and other entities) that can affect that vehicle and / or other entities. V2X includes one or more features in a subset of features, including vehicle-to-vehicle communication or a combination of the following: other vehicles (vehicle-to-vehicle communication or V2V communication); infrastructure such as an RSU (vehicle-to-infrastructure communication or V2I communication); pedestrians (vehicle-to-pedestrian communication or V2P communication); networks (vehicle-to-network communication or V2N communication); devices such as electronic devices within a vehicle (vehicle-to-device communication or V2D communication); electricity grid (vehicle-to-grid communication or V2G communication), and so on.

[0023] Devices compliant with IEEE 802.11p use a special operating mode known as Out-of-BSS (OCB). No device-to-network authentication / association is required before the device can transmit application or service data to another device over the network. The only parameters that need to be configured are the frequency channel (center frequency and bandwidth) for communication. The frequency channel (or more simply, the "channel") is known in advance and is typically assigned at a higher layer as part of the definition of a particular V2X application. Communication is either broadcast-addressed or unicast-addressed. Many V2X applications proprietaryly rely on unacknowledged broadcast modes.

[0024] V2X endpoint devices refer to electronic devices capable of participating in V2X communication. V2X endpoint devices can include vehicles, electronic devices (e.g., desktop computers, laptop computers, tablets, smartphones, wearable devices, gaming equipment, etc.), RSUs (which refer to any equipment provided on, near, or on roads, such as traffic lights, electronic signs, toll booths, or any other type of structure), network nodes in the network, equipment in the power grid, etc.

[0025] 1. question

[0026] 1.1 Question 1

[0027] An ITS band (or another frequency band designated for vehicle-related communications) may have limited capacity for information transmission. As the ITS system adds new services to transmit data with potentially large payloads, the channels in the ITS band may become saturated. In other words, the bandwidth of a channel in the ITS band may be fully utilized, making further communication of information within that ITS band impossible or delayed. A “channel” (“frequency channel”) can refer to a frequency portion of the ITS band. In further examples, “channel” generally refers to a communication resource that can be used, such as carrying data in a radio communication network.

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

[0029] To account for the limited capacity of the ITS band, it may be desirable to offload data communication to another band outside the ITS band via certain services. In some examples, such a band outside the ITS band may be referred to as a non-ITS band. In further examples, multiple non-ITS bands may exist, in which information communication can be performed by certain services.

[0030] If there is no frequency overlap between the first frequency band and the second frequency band, then the first frequency band is outside the second frequency band.

[0031] Certain types of vehicle-related communications are considered critical, such as information related to vehicle safety or information that should be transmitted within a relatively short timeframe of the event associated with the communication. Examples of such critical vehicle-related information include the vehicle's position and trajectory on the road, information about collisions, information about obstacles on the road, information about local road conditions (e.g., ice, floods, wind, sand, wind on bridges, fog, etc.), information about road closures, information about emergency or priority vehicles, information about faulty road signals, etc. Such critical vehicle-related communications should still occur in the ITS band, or more broadly, in the bands designated for vehicle-related communications.

[0032] Other types of vehicle-related communications can be considered non-critical, such as communications not related to safety or communications where delays in information transmission are tolerable. Examples of non-critical vehicle-related information include traveler information, attraction announcements, information about congestion, new road layouts, information about accident black spots, information about bike lanes and intersection signals and phasing information, supplementary information about critical events, etc.

[0033] One issue involves how to discover instances where vehicle-related communications for a specific service will occur outside the ITS band.

[0034] 1.2 Question 2

[0035] In examples where multiple non-ITS frequency bands are provided by correspondingly different types of networks, it may be desirable to match different services with different non-ITS frequency bands depending on the characteristics of the services and how well they match the performance of the corresponding types of access networks. Matching services with non-ITS frequency band services may also be related to energy management for V2X systems. Different types of access networks can include cellular access networks, wireless local area networks (WLANs) (also known as...) (Network), etc.

[0036] 1.3 Question 3

[0037] In some cases, certain non-ITS frequency bands are available based on local direct communication between wireless devices that are within each other's wireless range (e.g., radio range). If the service can communicate over a wireless network that supports communication over a large geographical area, additional security should be implemented to protect such communication.

[0038] 2. Example Implementation

[0039] In the following discussion, reference will be made to the ITS band and non-ITS band in some example implementations.

[0040] More generally, the techniques or mechanisms according to this disclosure can be applied to other types of frequency bands, wherein a frequency band designated for vehicle-related communications (“vehicle-related band”) may include a set of communication resources (defined by any or a combination of frequency, time, coding, etc.). Non-vehicle-related bands may include another set of communication resources outside the frequency band designated for vehicle-related communications. Non-vehicle-related bands are not designated for vehicle-related communications; that is, non-vehicle-related bands are not reserved for vehicle-related communications.

[0041] 2.1 Use ITS bands to discover services delivered outside of ITS bands.

[0042] The techniques or mechanisms discussed in this section can be used to solve problems 1 and 2 in sections 1.1 and 1.2 above.

[0043] According to some implementations of this disclosure, a technique or mechanism is provided to discover ITS services that have been offloaded from an ITS band (e.g., the 5.9 GHz band) to a non-ITS band (WLAN, 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 may be portions of unlicensed or licensed spectrum.

[0044] Note that ITS bands can be part of a wireless communication technology in which V2X endpoint devices can communicate directly with each other without transmitting data through network infrastructure. On the other hand, one or more non-ITS bands are deployed over corresponding access networks.

[0045] "Access network" can refer to a network that includes network equipment through which endpoint devices can obtain connectivity and communicate with one or more other endpoint devices. Access networks can include wireless access networks, such as cellular access networks, WLANs, etc. Cellular access networks can include LTE access networks, 5G access networks, or any other type of access network. In some other examples, access networks can include wired networks in which endpoint devices are connected to the network via wired connections to perform communication.

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

[0047] Figure 1A This is a block diagram of an example arrangement including one or more ITS services 102, RSUs 104, and vehicles 106. Although there is only one RSU and one vehicle... Figure 1A While this is depicted in the example, it should be noted that in some other examples, there may be more than one RSU and / or more than one vehicle.

[0048] although Figure 1A ITS service 102 is shown outside of RSU 104 and vehicle 106, but in some other examples, ITS service 102 may be included in RSU 104 or vehicle 106.

[0049] Figure 1A Various types of access networks are also shown, including WLAN 108 and another access network 110, which may be of a different type from WLAN 108. For example, the other access network 110 may be a cellular access network.

[0050] In some examples, RSU 104 can communicate with ITS service 102 via wired network 105, or alternatively via WLAN 108 or access network 110.

[0051] WLAN 108 includes one or more access points (APs) 112, and access network 110 includes one or more network nodes 114. APs 112 are capable of wireless communication with wireless devices (such as RSUs 104 or vehicles 106). Similarly, network nodes 114 are capable of wireless communication with wireless devices. If access network 110 is a cellular access network, network nodes 114 may be referred to as base stations (also known as NodeBs, eNodeBs, 5G base stations, etc.).

[0052] RSU 104 includes a communication interface 116 for performing information communication. The "communication interface" may include a communication transceiver for transmitting and receiving signals over a communication link. The communication interface may also include one or more protocol layers that manage the use of one or more corresponding protocols for data communication.

[0053] RSU 104 also includes a service information announcement engine 118, which is capable of announcing service information in the ITS band. As used herein, "engine" may refer to hardware processing circuitry, which may include any or a combination of the following: a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or another hardware processing circuitry. Alternatively, "engine" may refer to a combination of hardware processing circuitry and machine-readable instructions (software and / or firmware) executable on the hardware processing circuitry.

[0054] Although only one communication interface 116 is shown in RSU 104, in some other examples, RSU 104 may include more than one communication interface to communicate according to different corresponding access technologies.

[0055] Vehicle 106 also includes a communication interface 120 (or multiple communication interfaces). In addition, vehicle 106 includes an ITS communication engine 122 to perform vehicle-related communications.

[0056] In some examples, communication interface 116 in RSU 104 and communication interface 120 in vehicle 106 can be used to allow RSU 104 and vehicle 106 to communicate directly with each other without using any network infrastructure such as access networks (e.g., WLAN 108 and access network 110). Note that communication interface 116 in RSU 104 (or different communication interfaces in RSU 104) can be used to communicate via access networks (such as WLAN 108 or access network 110). Similarly, communication interface 120 in vehicle 106 (or different communication interfaces in vehicle 106) can be used to communicate via access networks.

[0057] The direct wireless communication between RSU 104 and vehicle 106 can employ any of a variety of communication technologies, such as Dedicated Short Range Communication (DSRC) using IEEE 802.11p-2010, LTE-V2X (PC5 interface), lightweight communication (e.g., Li-Fi) links, and any other short range communication technologies.

[0058] Based on some example techniques and mechanisms, it is possible to discover ITS services whose communication is provided through non-ITS bands. Typically, ITS bands can operate as a notification source, providing information about ITS services available in one or more non-ITS bands.

[0059] The ITS band can be used to announce service information for communication in ITS service 102. Figure 1A In the example, the service information notification engine 118 in RSU 104 transmits service information from RSU 104 to vehicle 106 via a direct link.

[0060] In other examples, the Service Message Notification Engine 118 may be included in a different node than RSU 104. For example, the Service Message Notification Engine 118 may be included in another vehicle, a network node such as AP 112 or network node 114, or any other device.

[0061] Service information may include information about one or more of the following characteristics of ITS services that will perform communication in non-ITS frequency bands:

[0062] • Information about channels outside the ITS band, such as radio information. If the serving communications have dedicated channels, the radio information can identify the frequency band and / or channel.

[0063] • Information indicating the flow characteristics of the ITS service, where examples of flow characteristics may include any or a combination of the following: whether the vehicle-related data is unidirectional or bidirectional, whether the vehicle-related data is unicast or broadcast (multicast), Internet Protocol (IP) information (e.g., IP address, etc.), the duty cycle of the vehicle-related data (where the duty cycle refers to the periodicity in which the vehicle-related data is transmitted), etc.

[0064] • Information that identifies the service, such as a Uniform Resource Identifier (URI) (e.g., a URL that specifies where the service’s data is located on the network) or a human-readable string used to display on the user interface (e.g., “incident consultation”).

[0065] Based on the service information announced by the service information notification engine 118, the ITS communication engine 122 in the vehicle 106 can transmit vehicle-related data to the ITS service 102 via a non-ITS frequency band, which can be provided, for example, by WLAN 108 or access network 110, or both.

[0066] In other examples, the other endpoint device may include an ITS communication engine similar to ITS communication engine 122, wherein the other endpoint device is also capable of receiving service information announced by service information notification engine 118 and of performing communication of vehicle-related data with ITS service 102 via non-ITS frequency bands.

[0067] Examples of use cases are described below.

[0068] In one example, vehicle 106 (as part of the service information announced from RSU 104 in local direct radio transmission) receives a URL for a web service application programming interface (API) and other information about a given ITS service 102. The ITS communication engine 122 in vehicle 106 connects to the announced URL over a cellular network (e.g., 110) via a cellular transmission control protocol / Internet protocol (TCP / IP) connection. The URL refers to the given ITS service 102 provided by a server, which in some examples may reside in a cloud operated by a third party (different from the operator of the cellular network or RSU 104). The given ITS service 102 can transmit vehicle-related data, such as current data on the status of road infrastructure, via RSU 104.

[0069] In another example, vehicle 106 is a taxi queuing to pick up passengers at an airport. Vehicle 106 receives service information about a given ITS service 102 (in local direct radio transmission). The service information may include information from WLAN 108 used to transmit vehicle-related data for the given ITS service 102. Vehicle 106 connects to WLAN 108 while queuing at the airport and is able to download vehicle-related data from the LAN behind the WLAN AP. In some examples, vehicle 106 is able to download current information from a local server connected to the LAN, enabling the use of no internet access.

[0070] In another example, such as Figure 1BAs shown, ITS service 102 (at 150) generates a new Universal Unique Identifier (UUID) (which is an example of the requested token), and ITS service 102 (at 152) sends the token (UUID) to RSU 104. In response to vehicle 106 requesting the token from RSU 104, RSU 104 (at 154) sends service information including the token (UUID) and the server URL associated with ITS service 102 to vehicle 104 via local direct communication transmission. By sending the UUID as a token to ITS service 102 via the access network (at 156), vehicle 106 continues to access ITS service 102 at the URL. ITS service 102 (at 158) determines from the token that vehicle 106 is near RSU 104 for vehicle authentication. Vehicle 106 then receives vehicle-related data from ITS service 102 via the access network (e.g., WLAN 108 or access network 110).

[0071] Alternatively, a UUID may be generated at RSU 104 and provided to ITS service 102 for use by ITS service 102 to authenticate vehicle 106 based on the proximity of vehicle 106 to RSU 104.

[0072] In another example, a given ITS service 102 provides local fuel price information. This given ITS service 102 can be implemented using one or more servers that are part of the cloud. These servers (multiple servers) provide local fuel price information in different communities across the globe. Within a local community, an RSU (e.g., RSU 104) transmits a specific URL or token that allows vehicle 106 to download the correct local fuel information from the servers (multiple servers). For example, a vehicle driving in Ottawa will access Ottawa's fuel prices, not Vancouver's.

[0073] The following additional sections describe more specific mechanisms or techniques for announcing service information for ITS services in non-ITS frequency bands.

[0074] 2.1.1 Use the ITS band as a pilot channel (WSA message).

[0075] In some examples, the Wireless Access (WAVE) Service Advertisement (WSA) message in a vehicular environment can be used to provide information about services in non-ITS bands. The WSA message is defined according to IEEE 1609.2.

[0076] IEEE 1609.2 WSA messages can be adapted to carry information about available ITS services. Service information regarding ITS services may include, for example, the recipient technology being... The unlicensed spectrum channel number / band, or the URI / URL to which the ITS service can be connected using TCP / IP networking protocols (e.g., cloud ITS services). This enables WSA to advertise services delivered in the unlicensed spectrum via various radio technologies and higher-level networking / Internet technologies.

[0077] Section 8.2 of IEEE 1609.2-2016 describes WSA frames. The proposed high-level changes and updates to the IEEE 1609.2-2016 standard include (more details are provided in section 3.1 below):

[0078] • Added WSA version.

[0079] • Allows variable-length service information segments.

[0080] • Allows channel information segments of variable length.

[0081] • Allows multiple channel segments per service segment, enabling services to be advertised as available through more than one method (e.g., DSRC channel number and URI).

[0082] • If possible, rename the “Channel Information Segment” to the “Service Access Segment”.

[0083] The channel information field can contain any IEEE 802.11 channel number / operation class, URI, 3GPP UMTS Terrestrial Radio Access (UTRA) absolute RF channel number UARFCN, IP address, etc. More fields are listed in section 2.1.4.

[0084] • Technology type, such as 4G, 5G, etc.

[0085] WSA messages may include radio channel information, credentials for accessing a network (such as WLAN), service access information (such as a service URL), and a credential token for accessing the service.

[0086] 2.1.2 Use the ITS band as a pilot channel (discovery message).

[0087] In other examples, discovery messages can be used to advertise services in non-ITS bands. Examples of discovery messages include Access Network Query Protocol (ANQP) messages, General Advertisement Service (GAS) messages, and so on. A wireless device (e.g., vehicle 106) can exchange ANQP and GAS messages with another device (e.g., RSU 104) without first performing authentication and / or association with that device.

[0088] ANQP is a query and response announcement protocol used by wireless devices to discover a range of information about a radio access network. Prior to authentication, GAS provides layer 2 transmission of frames for the announcement protocol between peer wireless devices.

[0089] Examples of information that can be announced in a discovery message include vehicle-related data transmitted via non-ITS frequency bands. Channel, URI, etc. The discovery message may include an ANQP response transmitted in response to an ANQP query issued by a wireless device (e.g., vehicle 106) to another device (e.g., RSU 104). The ANQP may be modified to ensure that it operates between the wireless device and the RSU, or alternatively between two wireless devices. As another example, the discovery message may include a GAS response transmitted in response to a GAS query issued by a wireless device (e.g., vehicle 106) to another device (e.g., RSU 104).

[0090] In other examples, instead of using the query / response technique, announcements of service information can be sent using periodic frames (which are sent periodically).

[0091] A new WSMP frame (IEEE 1609) was created to encapsulate all existing GAS responses (defined for IEEE 802.11) that operate using various advertising protocols. These protocols include ANQP, the Registered Location Query Protocol (RLQP), and the Pre-Association Discovery (PAD) (11aq) payload. Advertising protocols such as PAD can be enhanced to ensure that PAD can operate in peer-to-peer mode and is independent of the network infrastructure or servers located within it. In the case of RLQP and PAD, the server is located within or connected to the peer wireless device.

[0092] 2.1.3 Use the ITS band as a pilot channel (broadcast common action frame).

[0093] In other examples, broadcast common action frames are used to transmit WSA (or WSA-type information) in IEEE 802.11 channels (e.g., 5.9 GHz ITS channels). This can be a broadcast service information frame, which can be defined (or modified) in IEEE 802.11bc.

[0094] 2.1.4 The fields announced

[0095] The following fields may be included in the enhanced service notification methods described in sections 2.1.1, 2.1.2 and 2.1.3.

[0096] • Channel number, for example, IEEE 802.11 channel number, such as the channel number in the ITS band.

[0097] • Channel width, such as 10, 20, 40, 80, 160 MHz.

[0098] • Service Set Identifier (SSID) for WLAN (e.g., to identify the local WLAN).

[0099] · Alliance Wi-Fi URI (which can be a WLAN-specific credential using the Device Configuration Protocol (DPP)).

[0100] • URL (e.g., location information of a web service).

[0101] URI.

[0102] • Provider Service Identifier (PSID) (also known as Application Identifier (AID)).

[0103] • Service name, which is a string that identifies the ITS service.

[0104] • Service hash, which is a value generated by applying a hash function to the name of the ITS service.

[0105] • Service type, which is a numerical value that identifies the type of ITS service.

[0106] • Service subtype, which is a numerical value that identifies the type of ITS service.

[0107] • Mobile Network Code (MNC), Mobile Country Code (MCC), Public Land Mobile Network (PLMN), where this combination can identify a cellular network.

[0108] ·UARFCN, which is the frequency code for cellular networks.

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

[0110] In some examples, the URL and URI are used by the receiving device to connect to the ITS service over the top. Over the top means via the Internet Protocol over a wireless access network (such as a cellular network or WLAN).

[0111] In some examples, the PSID indicates the specific ITS service being advertised. In many protocols, the PSID is an index number in the header that indicates which upper-layer application should handle decoding the contained packet. In the case of service advertisement, the received PSID is used to match the receiving device with a list of applications it is interested in receiving or has already subscribed to. The receiving device uses the PSID to determine whether to access the advertised service.

[0112] In further examples, the service name, service hash, service type, and / or service subtype can be used in place of or appended to the PSID.

[0113] The WLAN SSID, Wi-Fi URI, and PLMN provide information about the access network. This information can be included in a discovery message that is identical to the URL or URL information of the server where the service is accessed. Providing information about the access network and the location on the network both allow the service to be offered discreetly on the access network, rather than being publicly accessible on the Internet. For example, the URI can refer to a server on a specific LAN / WLAN, or it can point to a Service Capability Exposure Function (SCEF) or V2X Control Function (VCF) in a 3GPP network.

[0114] 2.1.5 WSA encoded as URI / URL

[0115] A WSA can be constructed as a URI to encode its information. The WSA payload can include a URI formatted as an IP URI or a WSA URI.

[0116] Where services can be provided over a specific radio technology via IP connectivity, service announcements may include WSA svc URIs and URLs.

[0117] 2.1.6 Authenticity of service notices

[0118] If a WSMP message is used to carry an enhanced service advertisement payload, the entire message can be signed to convey its authenticity to the receiving device. If another packet format is used, the signature can be used to sign the specific content of the service advertisement or the entire message as a whole.

[0119] Figure 2AAn exemplary packet 202 is shown for carrying a service announcement 204 signed at the packet level. For example, a "packet" refers to a unit of data having a format defined by the protocol. Service announcement 204 includes service information 206 about ITS services (such as any example service information discussed further above). In some other examples, service announcement 204 may include multiple pieces of service information 206 about multiple ITS services.

[0120] Digital signature 208 is included in or attached to packet 202, wherein digital signature 208 is derived by signing the contents of packet 202 (such as by using a cryptographic key).

[0121] Figure 2B Another example group 210 is shown, which includes service announcement 212. Service announcement 212 includes service information 214 about the ITS service.

[0122] exist Figure 2B In this case, service information 214 is signed separately, rather than as... Figure 2A The entire packet 202 is signed as shown. Therefore, signature 216 is generated based on the signing of service information 214, and signature 216 is included in packet 210.

[0123] Figure 2C Another example group 220 is shown, which includes service announcement 222. Service announcement 222 includes multiple service information 224-1 to 224-N (N≥2) about the corresponding multiple ITS services.

[0124] exist Figure 2C In this process, each service message 224-i (i = 1 to N) is signed individually. Therefore, signature 226-i (i = 1 to N) is generated based on the signing of service message 224-i. Signatures 226-1 to 226-N are included in packet 220.

[0125] Figure 2C This allows multiple service information about multiple ITS services to be sent in a single message, where the multiple service information may be signed by different sources.

[0126] For example, an RSU 104 at the intersection of an interstate highway and a city road can announce services signed by two different government agencies (a state agency and a city agency). Even though different signatures are transmitted in the same WSA frame (more generally, a packet), the different signatures verify different sources of information providers. The signed service information can come from different backend networks (e.g., LAN, WAN, Internet, etc.) into the RSU 104.

[0127] Signatures can be generated using any of a wide variety of cryptographic algorithms. Different cryptographic algorithms can provide different levels of security based on the number of bits or other parameters. Traveler information from the first source may have a different level of cryptographic protection than emergency information from the second source. Both messages can be transmitted from the same RSU104.

[0128] 2.2 ITS band messages used as location / proximity verification tokens

[0129] The techniques or mechanisms discussed in this section can be used to solve problem 3 in section 1.3 above.

[0130] As shown above, direct wireless communication can be performed between RSU 104 and vehicle 106. This direct wireless communication is short-range communication, meaning that RSU 104 and vehicle 106 can communicate directly with each other if vehicle 106 is within a specified distance of RSU 104. The specified distance can be a relatively short distance, such as, for example, less than 500 meters (m), less than 250 meters, less than 100 meters, or less than 50 meters.

[0131] Messages transmitted using direct wireless communication (such as announcements including one or more service information of one or more corresponding ITS services) may be referred to as “short-range messages”. As discussed in this disclosure with reference to some examples, short-range messages may include WSA messages or different types of messages.

[0132] In some examples, short-range messages (such as messages sent by RSU 104 to vehicle 106 via direct wireless communication) can be used for proximity verification to facilitate the delivery of vehicle-related data for ITS services using a server. The delivery of vehicle-related data using a server can be based on the following: Representation Layer State Transfer (REST) ​​Application Programming Interface (API), URL / URI, Message Queuing Telemetry Transport (MQTT), Constrained Application Protocol (CoAP), Active Message Queuing Protocol (AMQP), or another mechanism.

[0133] Based on the exchange of messages in direct wireless communication (such as DSRC communication, 3GPP PC5 sidelink communication, etc.), vehicle 106 (or another receiving device for short-range messages) is verified to be in a specific geographical location. "Geographical location" refers to a geographical position.

[0134] In some examples, vehicle 106 receives broadcast short tokens, such as in WSA messages transmitted in the ITS band. In other examples, local cryptographic challenge / exchange is performed on a local direct radio link. Messages can be transmitted in the ITS band to verify the proximity or location of vehicle 106.

[0135] The token itself can be embedded in a URL path or URI. Embedding the token in a URL or URI can be used in unauthenticated and one-way local direct radio links. The token is delivered via a local direct link radio link (such as from RSU 104 to vehicle 106 or from the transmitting vehicle to the receiving vehicle). In some examples, the token is authenticated by two devices (e.g., two vehicles, or RSU and vehicle) via a connection to a central server through an access network (e.g., WLAN 108 or access network 110).

[0136] In an alternative example, the token may be transmitted as part of a two-way exchange within the ITS band (such as a two-way exchange between RSU 104 and vehicle 106, or a two-way exchange between vehicles). For example, the two-way exchange may be part of a cryptographic challenge. After the token is transmitted from the transmitting device to the receiving device, a user-specific token or credential may be provided to the receiving device (e.g., vehicle 106). In this case, the local direct radio link is bidirectional, and the data is acknowledged and verified locally. In response to successful local authentication via the direct radio link, the ITS service is conditionally obtained from the central server via the access network.

[0137] Once the receiving device (e.g., vehicle 106) (using any of the techniques described above) obtains a token or credential, the token can be used over the access network (e.g., 108 or 110) to access ITS services (see the discussion above). Figure 1B ).

[0138] In some examples, the token or credential can be any of the following:

[0139] • The URI path portion;

[0140] • Variables in Hypertext Transfer Protocol (HTTP) POST / GET requests;

[0141] • A portion of the credentials for a Transport Layer Security (TLS) connection;

[0142] • Access credentials used in connection with WLAN;

[0143] • Parts of higher-level exchange protocols (e.g., Bootstrap Remote Secure Key Infrastructure (BRSKI));

[0144] • Public Key Infrastructure (PKI) certificates; or

[0145] Temporary UUID.

[0146] The token is selected from a namespace or numeric space sufficient to prevent conflicts with specific target ITS services. This ensures that, with medium-level security (for broadcast tokens) and high-level security (for local cryptographic challenges), the entity requesting the service over the network (e.g., the Internet or another insecure network) is indeed / has been located in the specific geographic location (or geographic region).

[0147] In some examples, tokens can be signed for authenticity or encrypted for confidentiality.

[0148] In some examples, a token may contain information about the scope of its validity. A scope can be anything, and the following two examples are provided: A scope can be the time during which the token remains valid. A scope can be one or more geographical locations within which the token is valid. The scope information can be contained within the token itself, or the scope information can be stored by a server or service that maps the token to the scope represented by the token.

[0149] In some examples, security monitoring features at the server or service level, or access control gateways for the server or service, can monitor the misuse or abuse of tokens used to access the service. This can be used to prevent fraudulent access requests and to detect and prevent denial-of-service attacks.

[0150] 3.1 Further details about the WSA format

[0151] The WSA message header contains a version number. Version 3 is defined in IEEE 1609.3-2016 Section 8.2.2.2. Proposals for some implementations of this disclosure are for later versions that will be numbered 4 or higher.

[0152] exist Figure 2D The updated WSA frame format is shown in the top row.

[0153] The new WSA version can be reflected in field 250.

[0154] Service information segment 252 can have a variable length. Figure 2D The second line shows the details of service information segment 252. More than one service information segment 252 may exist within a single WSA.

[0155] Radio channel information segment 254 can have a variable length.

[0156] Each service segment 252 contains more than one channel segment, and field 256 specifies the number of channel segments.

[0157] Field 258 specifies the technology type, such as 4G, 5G, etc.

[0158] Field 260 includes the PSID, field 262 includes the service URI, field 264 includes access credentials for accessing the access network, field 266 includes service credentials for allowing access to the service, field 268 includes a proximity token as further discussed above, and field 270 includes a WAVE information element extension.

[0159] exist Figure 2D Other fields not marked are existing fields defined by the WSA protocol.

[0160] In some examples, a new WSA service instance (an instance of an ITS service supporting WSA) according to some embodiments of this disclosure may satisfy any or a combination of the following:

[0161] • A WSA service instance can be primarily identified by a PSID (e.g., a list of service information instances where the PSID is the master key). The identification of a WSA service instance can be extended to use other non-PSID identifiers, such as domain name symbols or fully qualified domain names (FQDNs).

[0162] • Options exist for services referenced by URIs / URLs. A URI or URL allows the receiving device to establish a TCP / HTTP connection to access the network via the URI or URL.

[0163] • There is an option to invoke an ISO 21177 TLS connection to the server.

[0164] • WSA service instances can enable a REST API to the URI, but give the receiving device some authentication bits for a two-way authenticated TLS connection.

[0165] A WSA may contain more than one instance using the same PSID. This can be used to transmit service availability to a receiver via more than one access network or access technology type. For example, the signal phase and timing of an intersection can be provided via direct short-range communication on DSRC and C-V2X channels, and can be downloaded from a server via the Internet.

[0166] 3.2 WSA URI

[0167] The WSA URI provides information about the ITS service. An example WSA URI is provided below.

[0168] wsa-service-instance="wsa-svc:"[channel-list";"][service-info";"]

[0169] [radio-technology";"][tech";"][service-type";"][psid]";;"

[0170] pkex-bootstrap-info=[information]

[0171] channel-list="C:"class-and-channels*(","class-and-channels)

[0172] class-and-channels=class " / "channel*(","channel)

[0173] class = 1 * 3 DIGIT

[0174] channel = 1 * 3 DIGIT

[0175] service-info="S:"*(%x20-3A / %x3C-7E); semicolon not allowed

[0176] radio-technology="R:"tech*(","tech)

[0177] tech="WiFi", "Cell", "Wave"

[0178] service-type="PSID","URL","URI";

[0179] psid=*DIGIT

[0180] The service-type parameter in the example WSA URI indicates the type of service. If service-type equals "URL" or "URI", then the URL or URI will follow the WSA URI in the frame.

[0181] 3.3 The process of receiving equipment

[0182] Figure 3 It is based on some examples of the receiving device (e.g., Figure 1A The flowchart of the process executed by vehicle 106.

[0183] The receiving device (at 302) tunes its communication interface (e.g., the radio device in the communication interface) to a control channel, which can be any of the following: IEEE 802.11p channel 180 (DSRC channel), LTE-V2X channel 183 (PC5 side link), etc.

[0184] The receiving device (at 304) receives data from a nearby transmitting device (e.g., via a control channel). Figure 1A The RSU 104, another vehicle, or another device receives WSA messages.

[0185] The receiving device (at 306) parses the received WSA message and determines a list of services (e.g., ITS services) advertised by the WSA message. The "list of services" can identify one or more services.

[0186] The receiving device (at 308) compares the list of services in the WSA message with the list of services programmed at the receiving device for which the receiving device is of interest. If the receiving device (at 310) determines that 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 continues to access the service using any of the following: (1) if accessing the service using a DSRC radio, the receiving device (at 312) tunes the DSRC radio to a channel / time slot to receive further messages for the service; (2) if accessing the service via a WLAN, the receiving device (at 314) connects to the WLAN to access the service; or (3) if accessing the service using a URI or URL, the receiving device (at 316) obtains the data for the service at the URI or URL via an access network (such as a cellular network).

[0187] Figure 4 According to further examples, the receiving device (e.g., Figure 1A The flowchart of the process executed by vehicle 106.

[0188] The receiving device (at 402) tunes its communication interface (e.g., the radio in the communication interface) to a control channel, which can be any of the following: IEEE 802.11p channel 180 (DSRC channel), LTE-V2X channel 183 (PC5 side link), etc.

[0189] The receiving device (at 404) receives data from a nearby transmitting device (e.g., via a control channel) through a control channel. Figure 1A The RSU 104 (or another vehicle or device) receives the WSA message.

[0190] The receiving device (at 406) parses the received WSA message and determines the list of services (e.g., ITS services) advertised by the WSA message.

[0191] The receiving device (at 408) compares the list of services in the WSA message with the list of services programmed at the receiving device that are of interest to the receiving device. If the receiving device (at 410) determines that 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.

[0192] Services advertised in the WSA can have more than one access method (e.g., signal phase and timing (SPAT) messages on a DSRC channel or via a web API). In this case, the receiving device has a priority order in which it determines which method to use to access the service. The receiving device (at 412) selects an access method from the multiple access methods according to the priority order. Then, the receiving device (at 414) uses the selected access method to access the service.

[0193] 4 Example equipment layout

[0194] Figure 5 It is a wireless device 500 (e.g., Figure 1A A block diagram of RSU 104 or vehicle 106, or another wireless device. Wireless device 500 can perform any of the tasks discussed herein.

[0195] Wireless device 500 includes hardware processor 502 (or multiple hardware processors). The hardware processor may include a microprocessor, the core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or another hardware processing circuit.

[0196] The wireless device 500 includes a communication interface 508 for performing communication via a wireless network.

[0197] The wireless device 500 also includes a non-transient machine-readable or computer-readable storage medium 504, which stores machine-readable instructions executable on one or more hardware processors 502 to perform various tasks.

[0198] Machine-readable instructions include vehicle-related data communication control instructions 506 executable on one or more hardware processors 502. The vehicle-related data communication control instructions 506 can be executed on one or more hardware processors 502. Figure 1A The RSU 104 executes the service information notification engine 118's task, or can execute... Figure 1A The ITS communication engine 122 in vehicle 106 may perform any of the other tasks described in this disclosure.

[0199] For example, vehicle-related data communication control command 506 may be part of RSU 104 and may cause the transmission of service information for a service within a first frequency band (e.g., ITS band) designated for vehicle-related communication, the service information including channel information, the channel being in a second frequency band (e.g., non-ITS band) for data communication for the service, outside the first frequency band.

[0200] In a further example, service information may also include information indicating the flow characteristics of data communication for the service, and / or information related to the service’s identification or location (e.g., URI, URL, PSID, service name, service hash, service type or subtype, etc.).

[0201] In some examples, service information is transmitted from wireless device 500 to a second wireless device, and this service information is included in the message before the association between the second wireless device and wireless device 500.

[0202] In some examples, a first type of access network supporting a first frequency band (e.g., DSRC link, PC5 side link, etc.) is different from a second type of access network supporting a second frequency band (e.g., WLAN, cellular access network, etc.).

[0203] In some examples, wireless device 500 sends a token to a second wireless device, which is usable by the second wireless device in securely accessing the service.

[0204] For example, when the second wireless device is near the wireless device 500 and communicates with the wireless device 500 through the local wireless medium, a token is sent to the second wireless device, and the access to the service by the second wireless device occurs through an access network separate from the local wireless medium.

[0205] In some examples, the token provides the following indication: when the second wireless device receives the token, the second wireless device is within the specified geographical location of the wireless device 500.

[0206] In other examples, vehicle-related data communication control command 506 may be part of vehicle 106 and may enable wireless device 500 to receive service information for a service from a second wireless device within a first frequency band designated for vehicle-related communications. Vehicle-related data communication control command 506 causes wireless device 500 to access the service using a channel in the second frequency band advertised by the service information.

[0207] In some examples, the service information includes information for multiple services, and the vehicle-related data communication control command 506 causes the wireless device 500 to compare the multiple services with information for one or more services stored at the wireless device 500, and to identify the service to be accessed based on the comparison.

[0208] In some examples, the service information indicates multiple different access technologies for accessing the service, and the vehicle-related data communication control command 506 causes the wireless device 500 to select an access technology from the multiple different access technologies for use in accessing the service.

[0209] In some examples, vehicle-related data communication control command 506 causes wireless device 500 to verify the authenticity of service information based on a signature representing the signing of service information.

[0210] In some examples, when wireless device 500 is near second wireless device, wireless device 500 receives a token from second wireless device, which is transmitted via local wireless medium, and wireless device 500 accesses the service via an access network separate from local wireless medium.

[0211] The techniques or mechanisms implemented according to some of the present disclosure may provide one or more of the following benefits: allow for more efficient use of ITS band capacity, provide more flexible ITS service deployment through one or more radio technologies, or provide coordination of service discovery across multiple radios, whose different receiving devices may have different sets of performance.

[0212] Local discovery mechanisms enable cloud services to be deployed and discovered locally, eliminating the need for centralized management of local services (which can be deployed in different geographical locations).

[0213] Storage medium 504 may include any or a combination of the following: semiconductor memory devices, such as dynamic or static random access memory (DRAM or SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory or other types of non-volatile memory devices; magnetic disks, such as fixed disks, floppy disks, and removable disks; another magnetic medium, including magnetic tape; optical media, such as compact discs (CDs) or digital video discs (DVDs); or another type of storage device. Note that the instructions discussed above may be provided on a computer-readable or machine-readable storage medium, or alternatively, may be provided on multiple computer-readable or machine-readable storage media distributed across a large system having possibly multiple nodes. Such one or more computer-readable or machine-readable storage media are considered part of an article (or article of manufacture). An article or article of manufacture may refer to any single or multiple manufactured components. One or more storage media may be located either in a machine that executes the machine-readable instructions or at a remote site from which the machine-readable instructions may be downloaded for execution via a network.

[0214] In the foregoing description, numerous details have been set forth to provide an understanding of the subject matter disclosed herein. However, implementations may be practiced without some of these details. Other practices may include modifications and variations from the details discussed above. It is intended that the appended claims cover such modifications and variations.

Claims

1. A method for communication, comprising: receiving, by a roadside unit, RSU, from a vehicle, a request for a token to access a vehicle-related service in a first frequency band designated for vehicle-related communications; and transmitting, by the roadside unit, RSU, service information in the first frequency band designated for vehicle-related communications for the vehicle to access a vehicle-related service, wherein the vehicle-related service is a service offloaded from a vehicle-related frequency band to a non-vehicle-related frequency band, the service information includes information of a frequency channel in a second frequency band for communication of data of the vehicle-related service, the second frequency band being outside the first frequency band, the service information further includes the token to be used by the vehicle as a credential to access the vehicle-related service, wherein the first frequency band is for direct short-range communications to verify proximity or location of the vehicle to the RSU and to communicate with the vehicle over a local wireless medium, and wherein the token provides an indication that the vehicle is within a designated geographic location of the RSU when the vehicle receives the token, and wherein the access of the vehicle to the vehicle-related service occurs through an access network, the access network being separate from the local wireless medium.

2. The method of claim 1, wherein a first type of access network supporting the first frequency band is different from a second type of access network supporting the second frequency band.

3. The method of claim 1, wherein the service information further includes information indicating flow characteristics of the communication of the data of the service.

4. The method of claim 1, wherein the service information further includes information related to an identity or location of the service.

5. The method of claim 1, wherein the service information is included in a Wireless Access Service Announcement, WSA, message in a vehicle environment.

6. The method of claim 1, wherein the service information is transmitted to the vehicle and included in a message prior to an association of the vehicle with the RSU.

7. The method of claim 1, wherein the service information is included in a broadcast public action frame.

8. The method of claim 1, wherein the service information includes a Uniform Resource Identifier, URI.

9. The method of claim 8, wherein the URI includes an Internet Protocol, IP, URI or a Wireless Access Service Announcement, WSA, URI in a vehicle environment.

10. The method of claim 1, wherein the service information is signed with a signature to allow confirmation of authenticity of the service information.

11. The method of claim 1, wherein the service information contains information for multiple services.

12. A first wireless device, comprising: a wireless interface; and at least one processor coupled to the wireless interface and configured to: transmit, to a roadside unit, RSU, a request for a token to access a vehicle-related service in a first frequency band designated for vehicle-related communications, the first wireless device being associated with a vehicle; and ​ receive service information from the RSU for the vehicle to access a vehicle-related service within the first frequency band designated for vehicle-related communications, wherein the vehicle-related service is a service offloaded from a vehicle-related frequency band to a non-vehicle-related frequency band, the service information includes information of a frequency channel in a second frequency band for communication of data for the vehicle-related service, the second frequency band being outside of the first frequency band, the service information further includes the token to be used by the vehicle as a credential to access the vehicle-related service, wherein the first frequency band is for direct short-range communications to verify proximity or location of the vehicle to the RSU and to communicate with the vehicle over a local wireless medium, and wherein the token provides an indication that the vehicle is within a designated geographic location of the RSU when the vehicle receives the token, and wherein the access by the vehicle to the vehicle-related service occurs over an access network that is separate from the local wireless medium.

13. The first wireless device of claim 12, wherein the service information contains information for a plurality of services, and the at least one processor is configured to: compare the plurality of services to information of one or more services stored at the first wireless device, and identify the service to be accessed based on the comparison.

14. The first wireless device of claim 12, wherein the service information indicates a plurality of different access technologies for accessing the service, and the at least one processor is configured to: select an access technology from the plurality of different access technologies to use in accessing the service.

15. The first wireless device of claim 12, wherein the at least one processor is configured to: confirm authenticity of the service information based on a signature represented by a signature of the service information.

16. A non-transitory machine-readable storage medium including instructions that when executed cause a first wireless device to: transmit a request for a token to a roadside unit (RSU) for accessing a vehicle-related service within a first frequency band designated for vehicle-related communications, the first wireless device being associated with a vehicle; and receive service information from the RSU for the vehicle to access a vehicle-related service within the first frequency band designated for vehicle-related communications, wherein the vehicle-related service is a service offloaded from a vehicle-related frequency band to a non-vehicle-related frequency band, the service information includes information of a frequency channel in a second frequency band for communication of data for the vehicle-related service, the second frequency band being outside of the first frequency band, the service information further includes the token to be used by the vehicle as a credential to access the vehicle-related service, wherein the first frequency band is for direct short-range communications to verify proximity or location of the vehicle to the RSU and to communicate with the vehicle over a local wireless medium, and wherein the token provides an indication that the vehicle is within a designated geographic location of the RSU when the vehicle receives the token, And wherein the access of the vehicle to the vehicle-related service occurs through an access network, which is separate from the local wireless medium.

Images