Patent Description:
An example telecommunication standard is Long Term Evolution (LTE). LTE is a set of enhancements to the Universal Mobile Telecommunications System (UMTS) mobile standard promulgated by Third Generation Partnership Project (3GPP). LTE is designed to support mobile broadband access through improved spectral efficiency, lowered costs, and improved services using OFDMA on the downlink, SC-FDMA on the uplink, and multiple-input multiple-output (MIMO) antenna technology. However, as the demand for mobile broadband access continues to increase, there exists a need for further improvements in LTE technology.

A variety of connectivity can be provided to a user equipment (UE). When a UE is a vehicle, such as an automobile, the UE may be coupled to a cellular-type communication network (such as an LTE network or a <NUM> network), may be coupled to one or more other UEs over a vehicle-to-vehicle (V2V) network (such as a PC5 interface on a sidelink communication channel), may be coupled to a roadside unit (RSU) or another vehicle-to-everything (V2X) node over one or more communication channels (such as cellular or sidelink communication channels), and may be coupled to other communication devices over, for example, a WiFi communication channel, a dedicated short range communication (DSRC) channel, a wireless wide area network (WWAN), a wireless local area network (WLAN), an integrated cellular vehicle to everything (CV2X)/LTE/<NUM> communication channel, or another communication channel.

When a UE is capable of only V2V communication (referred to as Mode <NUM>, or an autonomous UE), or when a UE capable of LTE or <NUM> communication (referred to as Mode <NUM>) may be out-of-coverage of the LTE or <NUM> communication network, an emergency alert, such as a commercial mobile alert service (CMAS) communication, an earthquake tsunami warning system (ETWS) communication, or another alert message broadcast on a communication network, may not reach the Mode <NUM> UE or the out-of-coverage Mode <NUM> UE.

Therefore, it would be desirable to have the ability to forward such an alert to a UE that may not be able to otherwise receive it.

<CIT> (related to <CIT>, discloses a method for a UE to communicate with network nodes, the method comprising the steps of storing system information of a connected cell prior to releasing an access to a network, establishing a connection to a first network node using the stored system information when a power of the UE is turned on, transmitting to a second network node an attach request message including an indication that PDN connectivity is not necessary, and receiving an attach accept message indicating that a network access without the PDN connectivity is complete from the second network node. <CIT>, discloses a method for operating a first UE in a wireless vehicular communication network, the method comprising the steps of receiving a plurality of messages including control and data messages from at least one second UE using at least one of multiple resource pools, wherein the plurality of messages comprise event-triggered or periodic traffic and the multiple resource pools comprise at least one of dedicated or shared resource pools, determining at least one of the multiple resource pools to transmit the plurality of messages to the at least one second UE, wherein multiple traffic types or priorities are multiplexed in the at least one of the multiple resource pools, dynamically adjusting resource selection within the multiple resource pools based on resource selection criteria, and directly communicating the plurality of messages to the at least one second UE using the at least one of the multiple resource pools.

<CIT> discloses a method performed by one or more processors, comprising: receiving a notification message indicative of an occurrence of an event; determining that a position of a vehicular device that is associated with the one or more processors is located on a boundary of a reachability area surrounding a source of the event; determining that a direction of movement of the vehicular device is towards the source; responsive to determining that the position is on the boundary of the reachability area and that the direction of movement of the vehicular device is towards the source, entering a roadside unit state; detecting one or more vehicular devices that are uninformed of the occurrence of the event and that are located outside of the reachability area; and broadcasting the notification message to the one or more uninformed vehicular devices. <CIT> is a method for sending Commercial Mobile Alert System (CMAS) and Earthquake and Tsunami Warning System (ETWS) alert messages to recipients who are not located within a geographic area designated to receive the alert.

Various implementations of systems, methods and devices within the scope of the appended claims each have several aspects, no single one of which is solely responsible for the desirable attributes described herein. Without limiting the scope of the appended claims, some prominent features are described herein.

One aspect of the disclosure provides a method for forwarding an alert, including receiving an alert in a first communication device over a first communication network, and forwarding the alert to a second communication device in a second communication network, the second communication network comprising a vehicle-to-vehicle communication network, the second communication device incapable of receiving the alert over the first communication network.

Another aspect of the disclosure provides a system for communication including a first communication device configured to receive an alert over a first communication network, and the first communication device configured to forward the alert to a second communication device in a second communication network, the second communication network comprising a vehicle-to-vehicle communication network, the second communication device incapable of receiving the alert over the first communication network.

Yet another aspect of the disclosure provides a non-transitory computer-readable medium storing computer executable code for communication, the code executable by a processor to control a method including receiving an alert in a first communication device over a first communication network; and forwarding the alert to a second communication device in a second communication network, the second communication network comprising a vehicle-to-vehicle communication network, the second communication device incapable of receiving the alert over the first communication network.

Still another aspect of the disclosure provides a device for wireless communication including means for receiving an alert in a first communication device over a first communication network; and means for forwarding the alert to a second communication device in a second communication network, the second communication network comprising a vehicle-to-vehicle communication network, the second communication device incapable of receiving the alert over the first communication network.

In the figures, like reference numerals refer to like parts throughout the various views unless otherwise indicated. For reference numerals with letter character designations such as "102a" or "102b", the letter character designations may differentiate two like parts or elements present in the same figure. Letter character designations for reference numerals may be omitted when it is intended that a reference numeral encompass all parts having the same reference numeral in all figures.

Accordingly, in one or more exemplary embodiments, the functions described may be implemented in hardware, software, or any combination thereof. If implemented in software, the functions may be stored on or encoded as one or more instructions or code on a non-transitory computer-readable medium. Non-transitory computer-readable media include computer-readable storage media. Computer-readable storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable storage media can comprise a random-access memory (RAM), a read-only memory (ROM), an electrically erasable programmable ROM (EEPROM), optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of the aforementioned types of computer-readable media, or any other medium that can be used to store computer executable code in the form of instructions or data structures that can be accessed by a computer.

The macro cells include eNBs.

A network that includes both small cell and macro cells may be known as a heterogeneous network. The communication links <NUM> may use MIMO antenna technology, including spatial multiplexing, beamforming, and/or transmit diversity. The base stations <NUM> / UEs <NUM> may use spectrum up to Y MHz (e.g., <NUM>, <NUM>, <NUM>, <NUM>) bandwidth per carrier allocated in a carrier aggregation of up to a total of Yx MHz (x component carriers) used for transmission in each direction. Allocation of carriers may be asymmetric with respect to DL and UL (e.g., more or less carriers may be allocated for DL than for UL).

When operating in an unlicensed frequency spectrum, the small cell <NUM>' may employ LTE and use the same <NUM> unlicensed frequency spectrum as used by the Wi-Fi AP <NUM>. The small cell <NUM>', employing LTE in an unlicensed frequency spectrum, may boost coverage to and/or increase capacity of the access network. LTE in an unlicensed spectrum may be referred to as LTE-unlicensed (LTE-U), licensed assisted access (LAA), or MuLTEfire.

The millimeter wave (mmW) base station <NUM> may operate in mmW frequencies and/or near mmW frequencies in communication with the UE <NUM>. Communications using the mmW/near mmW radio frequency band has extremely high path loss and a short range.

The IP Services <NUM> may include the Internet, an intranet, an IP Multimedia Subsystem (IMS), a PS Streaming Service (PSS), and/or other IP services.

The base station may also be referred to as a Node B, evolved Node B (eNB), gNode B (gNB) (i.e., for a mmW base station capable of communicating over a <NUM> communication network), an access point, a base transceiver station, a radio base station, a radio transceiver, a transceiver function, a basic service set (BSS), an extended service set (ESS), or some other suitable terminology. When a base station <NUM> is referred to as an eNB or a gNB, it is understood that the terms eNB and gNB are intended to include any of the base station designations mentioned herein. The base station <NUM> provides an access point to the EPC <NUM> for a UE <NUM>. Examples of UEs <NUM> include a cellular phone, a smart phone, a session initiation protocol (SIP) phone, a laptop, a personal digital assistant (PDA), a satellite radio, a global positioning system, a multimedia device, a video device, a digital audio player (e.g., MP3 player), a camera, a game console, a tablet, a smart device, a wearable device, a vehicle, an automobile, a drone, or any other similar functioning device.

<FIG> is a diagram <NUM> illustrating an example of a DL frame structure in LTE. <FIG> is a diagram <NUM> illustrating an example of channels within the DL frame structure in LTE. <FIG> is a diagram <NUM> illustrating an example of an UL frame structure in LTE. <FIG> is a diagram <NUM> illustrating an example of channels within the UL frame structure in LTE. In LTE, a frame (<NUM>) may be divided into <NUM> equally sized subframes. Each subframe may include two consecutive time slots. A resource grid may be used to represent the two time slots, each time slot including one or more time concurrent resource blocks (RBs) (also referred to as physical RBs (PRBs)). In LTE, for a normal cyclic prefix, an RB contains <NUM> consecutive subcarriers in the frequency domain and <NUM> consecutive symbols (for DL, OFDM symbols; for UL, SC-FDMA symbols) in the time domain, for a total of <NUM> REs. For an extended cyclic prefix, an RB contains <NUM> consecutive subcarriers in the frequency domain and <NUM> consecutive symbols in the time domain, for a total of <NUM> REs.

As illustrated in <FIG>, some of the REs carry DL reference (pilot) signals (DL-RS) for channel estimation at the UE. The DL-RS may include cell-specific reference signals (CRS) (also sometimes called common RS), UE-specific reference signals (UE-RS), and channel state information reference signals (CSI-RS). <FIG> illustrates CRS for antenna ports <NUM>, <NUM>, <NUM>, and <NUM> (indicated as R<NUM>, R<NUM>, R<NUM>, and R<NUM>, respectively), UE-RS for antenna port <NUM> (indicated as R<NUM>), and CSI-RS for antenna port <NUM> (indicated as R). <FIG> illustrates an example of various channels within a DL subframe of a frame. The physical control format indicator channel (PCFICH) is within symbol <NUM> of slot <NUM>, and carries a control format indicator (CFI) that indicates whether the physical downlink control channel (PDCCH) occupies <NUM>, <NUM>, or <NUM> symbols (<FIG> illustrates a PDCCH that occupies <NUM> symbols). The PDCCH carries downlink control information (DCI) within one or more control channel elements (CCEs), each CCE including nine RE groups (REGs), each REG including four consecutive REs in an OFDM symbol. A UE may be configured with a UE-specific enhanced PDCCH (ePDCCH) that also carries DCI. The ePDCCH may have <NUM>, <NUM>, or <NUM> RB pairs (<FIG> shows two RB pairs, each subset including one RB pair). The physical hybrid automatic repeat request (ARQ) (HARQ) indicator channel (PHICH) is also within symbol <NUM> of slot <NUM> and carries the HARQ indicator (HI) that indicates HARQ acknowledgement (ACK) / negative ACK (NACK) feedback based on the physical uplink shared channel (PUSCH). The primary synchronization channel (PSCH) is within symbol <NUM> of slot <NUM> within subframes <NUM> and <NUM> of a frame, and carries a primary synchronization signal (PSS) that is used by a UE to determine subframe timing and a physical layer identity. The secondary synchronization channel (SSCH) is within symbol <NUM> of slot <NUM> within subframes <NUM> and <NUM> of a frame, and carries a secondary synchronization signal (SSS) that is used by a UE to determine a physical layer cell identity group number. Based on the PCI, the UE can determine the locations of the aforementioned DL-RS. The physical broadcast channel (PBCH) is within symbols <NUM>, <NUM>, <NUM>, <NUM> of slot <NUM> of subframe <NUM> of a frame, and carries a master information block (MIB). The MIB provides a number of RBs in the DL system bandwidth, a PHICH configuration, and a system frame number (SFN).

As illustrated in <FIG>, some of the REs carry demodulation reference signals (DM-RS) for channel estimation at the eNB. The UE may additionally transmit sounding reference signals (SRS) in the last symbol of a subframe. The SRS may be used by an eNB for channel quality estimation to enable frequency-dependent scheduling on the UL. <FIG> illustrates an example of various channels within an UL subframe of a frame. A physical random access channel (PRACH) may be within one or more subframes within a frame based on the PRACH configuration. The PRACH may include six consecutive RB pairs within a subframe. The PRACH allows the UE to perform initial system access and achieve UL synchronization. A physical uplink control channel (PUCCH) may be located on edges of the UL system bandwidth.

<FIG> is a diagram <NUM> illustrating an example of a radio protocol architecture for the user and control planes in LTE in accordance with various aspects of the present disclosure. The radio protocol architecture for the UE and the eNB is shown with three layers: Layer <NUM>, Layer <NUM>, and Layer <NUM>. Layer <NUM> (L1 layer) is the lowest layer and implements various physical layer signal processing functions. The L1 layer will be referred to herein as the physical layer <NUM>. Layer <NUM> (L2 layer) <NUM> is above the physical layer <NUM> and is responsible for the link between the UE and eNB over the physical layer <NUM>.

In the user plane, the L2 layer <NUM> includes a media access control (MAC) sublayer <NUM>, a radio link control (RLC) sublayer <NUM>, and a packet data convergence protocol (PDCP) <NUM> sublayer, which are terminated at the eNB on the network side. Although not shown, the UE may have several upper layers above the L2 layer <NUM> including a network layer (e.g., IP layer) that is terminated at the PDN gateway <NUM> (<FIG>) on the network side, and an application layer that is terminated at the other end of the connection (e.g., far end UE, server, etc.).

The PDCP sublayer <NUM> provides multiplexing between different radio bearers and logical channels. The PDCP sublayer <NUM> also provides header compression for upper layer data packets to reduce radio transmission overhead, security by ciphering the data packets, and handover support for UEs between eNBs. The RLC sublayer <NUM> provides segmentation and reassembly of upper layer data packets, retransmission of lost data packets, and reordering of data packets to compensate for out-of-order reception due to hybrid automatic repeat request (HARQ). The MAC sublayer <NUM> provides multiplexing between logical and transport channels. The MAC sublayer <NUM> is also responsible for allocating the various radio resources (e.g., resource blocks) in one cell among the UEs. The MAC sublayer <NUM> is also responsible for HARQ operations.

In the control plane, the radio protocol architecture for the UE and eNB is substantially the same for the physical layer <NUM> and the L2 layer <NUM> with the exception that there is no header compression function for the control plane. The control plane also includes a radio resource control (RRC) sublayer <NUM> in Layer <NUM> (L3 layer). The RRC sublayer <NUM> is responsible for obtaining radio resources (e.g., radio bearers) and for configuring the lower layers using RRC signaling between the eNB and the UE.

<FIG> is a block diagram of an eNB <NUM> in communication with a UE <NUM> in an access network.

Each spatial stream may then be provided to a different antenna <NUM> via a separate transmitter 418TX. Each transmitter 418TX may modulate an RF carrier with a respective spatial stream for transmission.

At the UE <NUM>, each receiver 454RX receives a signal through its respective antenna <NUM>. Each receiver 454RX recovers information modulated onto an RF carrier and provides the information to the receive (RX) processor <NUM>. The symbols on each subcarrier, and the reference signal, are recovered and demodulated by determining the most likely signal constellation points transmitted by the eNB <NUM>. The soft decisions are then decoded and deinterleaved to recover the data and control signals that were originally transmitted by the eNB <NUM> on the physical channel.

Similar to the functionality described in connection with the DL transmission by the eNB <NUM>, the controller/processor <NUM> provides RRC layer functionality associated with system information (e.g., MIB, SIBs) acquisition, RRC connections, and measurement reporting; PDCP layer functionality associated with header compression / decompression, and security (ciphering, deciphering, integrity protection, integrity verification); RLC layer functionality associated with the transfer of upper layer PDUs, error correction through ARQ, concatenation, segmentation, and reassembly of RLC SDUs, re-segmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs onto TBs, demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction through HARQ, priority handling, and logical channel prioritization.

Channel estimates derived by a channel estimator <NUM> from a reference signal or feedback transmitted by the eNB <NUM> may be used by the TX processor <NUM> to select the appropriate coding and modulation schemes, and to facilitate spatial processing. The spatial streams generated by the TX processor <NUM> may be provided to different antenna <NUM> via separate transmitters 454TX. Each transmitter 454TX may modulate an RF carrier with a respective spatial stream for transmission.

The UL transmission is processed at the eNB <NUM> in a manner similar to that described in connection with the receiver function at the UE <NUM>. Each receiver 418RX receives a signal through its respective antenna <NUM>. Each receiver 418RX recovers information modulated onto an RF carrier and provides the information to a RX processor <NUM>.

Currently some services provided over the cellular/3GPP networks can be offloaded to WiFi networks to reduce the overload and cost of 3GPP networks. Many of the IP Multimedia Subsystem (IMS) and 3GPP services like voice over LTE (VoLTE), Video-Telephony (VT), rich communication services (RCS), short message services (SMS), Enhanced <NUM> (E911) may be provided over wireless local area networks (e.g., WiFi) using an ePDG. WLAN coverage, e.g., over WiFi, may also be available in areas where normal WWAN/cellular (e.g., UMTS/LTE) coverage is not available e.g. underground parking, underground subway and/or train station, sewers etc. Also, a person can carry a small battery powered WiFi dongle device anywhere where normal cellular WWAN coverage is not available. In the case of an emergency, in no coverage area a CMAS message and/or a PWS message and/or an ETWS message and/or other emergency service related message may need to be distributed to device users to notify the users of emergency conditions and/or available emergency relief services. Thus methods and apparatus for providing emergency broadcast services like the CMAS message service, PWS message service, ETWS information related service over non cellular networks, e.g., over WLANs, are highly desirable. Various features related to supporting emergency broadcast services using ePDG-IWLAN are described below.

Whenever there is no cellular/WWAN (e.g., LTE/UMTS) coverage, currently a UE may get many of the 3GPP services over IWLAN. However unfortunately many broadcast services including vital emergency broadcast services are not currently offered over WLANs, e.g., over a WiFi network. If broadcast services like CMAS, PWS, and ETWS are not offloaded to WiFi and/or other local wireless networks, in indoor and/or underground scenarios where there is no cellular WWAN coverage, the emergency related warning messages may not reach the users in such areas which is highly undesirable. Thus the desirability and need of methods and apparatus to support offloading 3GPP broadcast services to IWLANs is evident.

Various features related to implementing broadcast services e.g., CMAS, PWS, ETWS, and/or other commercial or emergency broadcast services over WiFi using ePDG-IWLAN path based on S2b interface are described. Currently many broadcast/multicast services use beacons over WiFi. An IP packet (e.g., including emergency broadcast information) with broadcast IP from an ePDG may be used by a WLAN access point (AP) to broadcast, e.g., over WiFi, to all users accessing the WLAN through the WLAN AP. When the UEs connected to ePDG (e.g., UEs that are associated with the ePDG and/or authorized to receive WWAN services) receive the broadcast IP packet using broadcast IP configured based on an ePDG assigned IP address, the UE's consider the packet for processing to recover the communicated broadcast information. Other devices which are not affiliated with the WWAN service provider and/or not getting 3GPP services using the ePDG, just simply discard the packet as the broadcast IP (e.g., configured by the ePDG) used to broadcast the IP packet is unknown to these devices and thus such devices are unable to decode the packet as it is security protected.

In some configurations if information, e.g., emergency related messages, are intended to be broadcast to non-3GPP users/subscribers in addition to 3GPP users, then such information may be broadcast without being IP secured by the ePDG and/or using a broadcast IP address of the WLAN AP broadcasting the information to the connected devices rather than the broadcast IP assigned by the ePDG.

As used herein, the term "autonomous" may refer to a UE or another communication device, which may not have a connection to a communication network over which emergency alert messages may be broadcast. For example, when a UE is capable of only V2V communication, it may be considered a "Mode <NUM>" UE in that it may not have a connection to a communication network over which emergency alert messages may be broadcast.

As used herein, the term "Mode <NUM> UE" or "Mode <NUM> capability" refers to a UE that may be connected to a broadband network, such as an LTE, <NUM>, or other network, and, when connected to the broadband network, is capable of receiving an emergency alert, such as a ETWS alert or a CMAS alert from the LTE or <NUM> network. Such a Mode <NUM> UE is referred to as "in coverage" when it is connected to the LTE or <NUM> network. An "out-of-coverage" Mode <NUM> UE refers to a UE that is capable of being connected to an LTE or <NUM> network, but that is not connected to the LTE or <NUM> network at a particular time, such that it is "out-of-coverage" of the network. When a UE is an "out-of-coverage" Mode <NUM> UE, it is incapable of receiving an alert, such as a ETWS alert or a CMAS alert, from the broadband LTE or <NUM> network.

In an exemplary embodiment, an LTE V2V capable UE may be configured to forward an alert to a UE that may only have V2V capability, or that may have Mode <NUM> capability, but may be out-of-coverage of a communication network.

In an exemplary embodiment, a Mode <NUM> UE capable of supporting V2V and LTE or V2X (such as WiFi, DSRC, etc.) may be coupled to an autonomous UE (such as a Mode <NUM> UE or an out-of-LTE coverage Mode <NUM> UE) over a PC <NUM> interface or other sidelink channel, and may be configured to provide alerts received over an LTE, <NUM>, WiFi, DSRC, etc., channel, to the Mode <NUM> UE, or to an out-of-coverage Mode <NUM> UE, over the PC <NUM> (or other sidelink) communication channel.

Alternatively, a Mode <NUM> UE that may be coupled to a CV2X/LTE/<NUM> channel, or to an RSU or other V2X node (such as a drone, or other vehicle, that may be configured to broadcast information) over a WWAN or WLAN connection, may be configured to provide the alert to a Mode <NUM> UE, or to an out-of-coverage Mode <NUM> UE, over the PC <NUM> (or other sidelink) interface.

<FIG> shows a communication system <NUM> in accordance with an exemplary embodiment of delivering an alert to an autonomous UE. The system <NUM> includes a base station (also referred to as an eNB or a gNB) <NUM> and a base station <NUM>. In an exemplary embodiment, the base stations <NUM> and <NUM> may be exemplary embodiments of the base stations <NUM> of <FIG>, and may be referred to interchangeably as a base station, an eNB or a gNB.

The base station <NUM> may be coupled to a UE <NUM> over an air interface, also referred to as a Uu interface <NUM>. In an exemplary embodiment, the UE <NUM> is a vehicle capable of licensed communication with the base station <NUM> over, for example, an LTE communication network, and may also be capable of communicating directly with one or more other UEs (or vehicles) over, for example, a sidelink communication channel, that is, not using a WAN such as an LTE or a <NUM> network.

The base station <NUM> may be coupled to a V2X node <NUM> over a Uu interface <NUM>. The V2X node <NUM> may be a communication device configured to participate in, facilitate, or otherwise engage in direct vehicle-to-everything (V2X) communications, and, in an exemplary embodiment, may also be referred to as a roadside unit (RSU), or may also be a vehicle, such as a drone, or other vehicle that may be configured to broadcast information.

In an exemplary embodiment, the UE <NUM> may be referred to as a V2V UE and may be coupled in Mode <NUM>, where the UE <NUM> has an LTE or a <NUM> connection (or other WAN connection) with the base station <NUM> over Uu interface <NUM>. The UE <NUM> may also be operatively and communicatively coupled to UEs <NUM> and <NUM>. In an exemplary embodiment, the UE <NUM> may be a V2V UE coupled in Mode <NUM>, where it may be in communication with the UE <NUM>, and other UEs <NUM> and <NUM>, over, for example, a direct UE to UE interface, such as a PC <NUM> interface <NUM>, <NUM> and <NUM>, respectively. A PC <NUM> interface may also be referred to as a sidelink communication channel in that it does not require LTE, <NUM>, or another broadband network connectivity, but instead, allows direct V2V communication between and among UEs. The UE <NUM> may be referred to as an out-of-coverage UE, in that it may be out of coverage of the base station <NUM> and the base station <NUM>, and therefore may not have an LTE or <NUM> connection with the base station <NUM> or the base station <NUM>. In an exemplary embodiment, the UE <NUM> may be in communication with the UE <NUM> over PC <NUM> interface <NUM>, and may be in communication with the UE <NUM> over PC <NUM> interface <NUM>.

The UE <NUM> may be referred to as a cellular vehicle-to-everything (CV2X) UE in that it may be connected to a network <NUM> over connection <NUM>. The network <NUM> may be a WiFi network, a DSRC network, a CV2X/LTE/<NUM> network, or another network, such as an Internet Protocol (IP) network. The UE <NUM> may also be coupled to an RSU <NUM> over a connection <NUM>. The RSU <NUM> and the connection <NUM> may represent, for example, a WWAN, a WLAN, or another network. The UE <NUM> may also be coupled to the V2X node <NUM> over a PC <NUM> interface <NUM>. The V2X node <NUM> may also be coupled to the network <NUM> over a connection <NUM> and the RSU <NUM> may be coupled to the network <NUM> over connection <NUM>. In an exemplary embodiment, the UEs <NUM>, <NUM>, <NUM>, <NUM>, the V2X node <NUM>, and the RSU <NUM> may be exemplary embodiments of the UE <NUM> described in <FIG>.

In an exemplary embodiment, an RSU may comprise a stationary infrastructure entity supporting V2X applications that can exchange messages with other entities supporting V2X applications. As used herein, the term RSU refers to a logical entity that combines, or may be configured to combine, V2X application logic with the functionality of a base station, such as an eNB or a gNB (referred to as eNB-type RSU, or gNB-type RSU if so configured) or that may be configured to combine V2X application logic with the functionality of a UE (referred to as UE-type RSU if so configured). The RSU <NUM> shown in <FIG> is intended to be a generic RSU, where the RSU <NUM> is shown as a stand-alone element, not connected to a base station. If connected to a base station, the RSU <NUM> could be connected to the base station <NUM> (or another base station) over a Uu connection, such as Uu connection <NUM>, which is shown in <FIG> in broken line to indicate that it is optional. In an exemplary embodiment, sidelink resources for V2X communications may be preconfigured similar to the manner in which sidelink resources would be preconfigured for a Mode <NUM> UE. If the RSU <NUM> is connected to a base station (i.e., similar to V2X node <NUM>) the sidelink resources could be configured by the base station to which the RSU <NUM> could be connected, such as, for example, base station <NUM> over Uu connection <NUM>.

A satellite <NUM> may provide global navigation satellite system (GNSS) timing synchronization, and/or frequency synchronization, to the out-of-coverage UE <NUM>, and any other UEs that may not have the ability to receive LTE or <NUM> network timing synchronization and/or frequency synchronization.

In an exemplary embodiment, the UE <NUM> monitors the base station <NUM> for system information block (SIB) <NUM>, SIB <NUM> and SIB <NUM> signals for alerts. An emergency alerts, such as a commercial mobile alert service (CMAS) communication, an earthquake tsunami warning system (ETWS) communication, or another alert message broadcast on a WAN communication network, such as an LTE or <NUM> communication network, may use a SIB <NUM>, SIB <NUM> and/or a SIB <NUM> communication to convey the alert. In an exemplary embodiment, upon receipt of an alert, the UE <NUM> may convert the alert to a maximum transmission unit (MTU) protocol data unit (PDU) packet for transmission over a PC <NUM> interface to UEs that may not have received the SIB <NUM>, SIB <NUM> or SIB <NUM> communication having the emergency alert. The MTU is the largest possible frame size of a communications protocol data unit (PDU) on a Layer <NUM> data network. In an exemplary embodiment, in this example, the UE <NUM> converts the received CMAS or ETWS alert to a PDU that will fit in an MTU frame for the PC <NUM> interface over which the alert is being transmitted. The communication from the UE <NUM> over the PC <NUM> interface to UEs that may not have received the SIB <NUM>, SIB <NUM> or SIB <NUM> communication may be performed using the GNSS timing and frequency synchronization provided by the satellite <NUM>, thus ensuring that the UEs that may not have received the SIB <NUM>, SIB <NUM> or SIB <NUM> communication because they are not connected to the base station <NUM> or the base station <NUM>, are all synchronized to the PC <NUM> interface using the GNSS timing synchronization and frequency synchronization. A UE being synchronized to the PC <NUM> interface using the GNSS timing and/or frequency synchronization may be part of a UEs pre-configuration, for example, as defined by SLX V2V section <NUM>. For example, a Mode <NUM> UE and/or an out-of-coverage Mode <NUM> UE, which are not connected to a base station, may have preconfigured sidelink resource pools for receiving and transmitting data with other UEs. For example, the UE <NUM> may transmit the MTU PDU communication with the emergency alert to the UE <NUM> in either a non-IP or IPv6 communication over the PC <NUM> interface <NUM>, and/or may transmit the MTU PDU communication with the emergency alert to the UE <NUM> in either a non-IP or IPv6 communication over PC <NUM> interface <NUM>. In this manner, a UE, such as the UE <NUM> and the UE <NUM>, which may not be capable of receiving an alert, may receive the alert communication from the UE <NUM>. The UE <NUM> will continue forwarding the alert in this manner for a pre-determined, or a dynamically configurable, period of time, X, or for a pre-determined distance, Y, that the UE <NUM> may travel after receiving the alert. For example, the pre-determined or dynamic period of time, X, may be related to the nature of the alert, or other factors. The pre-determined distance, Y, may be related to how far the UE <NUM>, in this example, travels after receiving the alert, such that the alert may become less significant as the UE <NUM> travels away from the location where the alert was received.

In another exemplary embodiment, the RSU <NUM> or the CV2X UE <NUM> monitors the network <NUM>, for system information block (SIB) <NUM>, SIB <NUM> and SIB <NUM> communications, which may indicate an emergency alert. In another exemplary embodiment, the RSU <NUM> or the CV2X UE <NUM> monitors the network <NUM>, for an IP communication that may include an emergency alert. Upon receipt of an emergency alert, the RSU <NUM> or the CV2X UE <NUM> may convert the alert to a maximum transmission unit (MTU) protocol data unit (PDU) packet for transmission over a PC <NUM> interface to UEs that may not have received the SIB <NUM>, SIB <NUM> or SIB <NUM> communication, similar to that described above for the UE <NUM>. For example, the RSU <NUM> may transmit the MTU PDU communication to the UE <NUM> over connection <NUM>, and/or the UE <NUM> may transmit the MTU PDU communication to the UE <NUM> over PC <NUM> interface <NUM> in either a non-IP or IPv6 communication. The destination address may be set to a group cast and the communication resources for this PC <NUM> communication may be allocated by a base station, such as the base station <NUM> or the base station <NUM>. In this manner, a UE, such as the UE <NUM>, may receive the alert communication from the RSU <NUM> or from the network <NUM>. The UE <NUM> may continue forwarding the alert in this manner for a pre-determined, or dynamically configurable, period of time. In the case of an RSU, such as the RSU <NUM>, it is assumed that an RSU is stationary, so associating a pre-determined distance to the PC <NUM> communication of the emergency alert messages from the RSU <NUM> to the UE <NUM> may be inapplicable.

In another exemplary embodiment, the UE <NUM> may be subscribed to receive alerts over a PC <NUM> interface, such as the PC <NUM> interface <NUM>. Upon receipt of an alert from the UE <NUM> over the PC <NUM> interface <NUM>, or from another UE, such as another Mode <NUM> UE, the UE <NUM> may pass the alert from its lower communication layers up to its higher (application) layer along with a timestamp and a GPS location. The UE <NUM> may determine whether the same alert was received within a recent time period, and if so, it may discard the alert. If the UE <NUM> determines that the alert is valid and not previously received, then the UE <NUM> begins forwarding the alert over PC <NUM> interfaces <NUM>, <NUM> and <NUM> in either a non-IP or IPv6 communication to other Mode <NUM> UEs, RSUs or other out-of-coverage Mode <NUM> UEs for a pre-determined or dynamically configurable period of time and/or over a pre-determined distance.

In another exemplary embodiment, the V2X/RSU node <NUM> may be subscribed to receive alerts over one or more of the Uu interface <NUM>, the communication channel <NUM>, and the PC <NUM> interface <NUM>. Upon receipt of an alert, the V2X/RSU node <NUM> may pass the alert from its lower communication layers up to its higher (application) layer along with a timestamp and a GPS location. The V2X/RSU node <NUM> may convert the alert to a maximum transmission unit (MTU) protocol data unit (PDU) packet for transmission over a PC <NUM> interface to UEs that may not have received the SIB <NUM>, SIB <NUM> or SIB <NUM> communication using GNSS timing and frequency synchronization provided by the satellite <NUM>, as described above. For example, the V2X/RSU node <NUM> may transmit the MTU PDU communication to the UE <NUM> over PC <NUM> interface <NUM> in either a non-IP or IPv6 communication. The destination address may be set to a group cast and the resources may be allocated by a base station. In this manner, a UE, such as the UE <NUM>, may receive the alert communication from the V2X/RSU node <NUM>.

<FIG> is a flow chart illustrating an example of a method <NUM> for communication, in accordance with various aspects of the present disclosure. In the method <NUM>, it is assumed that a subject UE may be a vehicle capable of vehicle-to-vehicle communication and one that is in connected to a WAN, such as an LTE or <NUM> network, in Mode <NUM>.

In block <NUM>, a Mode <NUM> UE monitors system information block (SIB) <NUM>, SIB <NUM> and SIB <NUM> signals for alerts. Examples of alerts may include a CMAS communication, an ETWS communication, or another alert message. In an exemplary embodiment, the UE is subscribed at its application layer to forward these alerts. For example, a UE may have its upper communication layers, such as its application layer, configured or pre-configured to be subscribed to various applications and may have its transmit and receive properties configured accordingly. For example, in an exemplary embodiment, the UEs <NUM>, <NUM>, <NUM> and <NUM>, the RSU <NUM>, the V2X node <NUM> and the network <NUM> are all always subscribed to transmit and receive CMAS alerts, ETWS alerts, and other alerts.

In block <NUM>, upon receipt of an alert, the UE may display the alert on its display, may initiate an audible warning, may initiate a haptic warning, such as a vibration, or may otherwise display the alert message.

In block <NUM>, the UE may convert the alert to a maximum transmission unit (MTU) protocol data unit (PDU) packet for transmission over a PC <NUM> interface to UEs that may not have received the SIB <NUM>, SIB <NUM> or SIB <NUM> communication, using GNSS timing and frequency synchronization.

In block <NUM>, the UE may transmit the MTU PDU communication to another UE that may not have received the alert in either a non-IP or IPv6 communication over a PC <NUM> interface with an address set to group-cast and using resources allocated from the Uu interface and resources from the UEs pre-configuration. For example, the UE <NUM> may broadcast the alert over the PC <NUM> interface to UEs <NUM> and <NUM> as a multi-cast message and to all UEs that may be in the vicinity of the UE <NUM> and that may have a PC <NUM> interface connection established with the UE <NUM>, not individually addressed to the UEs <NUM> and <NUM>. In an exemplary embodiment, the resources used by the UE <NUM> to transmit the emergency alert message over the PC <NUM> interface may be allocated by the base station <NUM> over the Uu interface <NUM>. In an exemplary embodiment, a UE, such as the UE <NUM> may also be at least partially pre-configured to transmit the emergency alert over the PC <NUM> interface and the UEs <NUM> and <NUM> may be at least partially pre-configured to receive (and in some embodiments, retransmit) the emergency alert over the PC <NUM> interface, without the resources being allocated by the base station <NUM>. In this manner, a UE, such as the UE <NUM> and the UE <NUM>, which may not be capable of receiving an alert, may receive the alert communication from the UE <NUM>.

In block <NUM>, it is determined whether a predefined duration of time "X" and/or a pre-determined distance "Y" has been met. If it is determined in block <NUM> that a predefined duration of time "X" and/or a pre-determined distance "Y" has not been met, the process returns to block <NUM> and the MTU PDU transmission continues. If it is determined in block <NUM> that a predefined duration of time "X" and/or a pre-determined distance "Y" has been met, the process proceeds to block <NUM>.

In block <NUM>, the V2V PC <NUM> transmission of the MTU PDU communication ceases.

<FIG> is a flow chart illustrating an example of a method <NUM> for communication, in accordance with various aspects of the present disclosure. In the method <NUM>, the subject UE may be a roadside unit (RSU) coupled to a WWAN or a WLAN, or the subject UE may be an integrated CV2X/LTE/<NUM> device having a connection to an LTE/<NUM> communication network.

In block <NUM>, an RSU with WWAN/WLAN capability, such as the RSU <NUM>, monitors an IP network for an alert; or a CV2X/LTE/<NUM> device periodically monitors system information block (SIB) <NUM>, SIB <NUM> and SIB <NUM> signals for alerts. Examples of alerts may include a CMAS communication, an ETWS communication, or another alert message. In an exemplary embodiment, the RSU or the UE is subscribed at its application layer to forward these alerts. For example, an RSU or a UE may have its upper communication layers, such as its application layer, configured or pre-configured to be subscribed to various applications, such as an alert application, and may have its transmit and receive properties configured accordingly. For example, in an exemplary embodiment, the UEs <NUM>, <NUM>, <NUM> and <NUM>, the RSU <NUM>, the V2X node <NUM> and the network <NUM> are all always subscribed to transmit and receive CMAS alerts, ETWS alerts, etc..

In block <NUM>, the RSU or the CV2X/LTE/<NUM> UE may convert the alert to a maximum transmission unit (MTU) protocol data unit (PDU packet for transmission over a PC <NUM> interface to UEs that may not have received the SIB <NUM>, SIB <NUM> or SIB <NUM> communication using GNSS timing and frequency synchronization.

In block <NUM>, the RSU or the CV2X/LTE/<NUM> UE may transmit the MTU communication to another UE that may not have received the alert in either a non-IP or IPv6 communication over a PC <NUM> interface with an address set to group-cast and using resources allocated from the Uu interface and resources from the UEs pre-configuration. For example, the RSU <NUM> or the CV2X UE <NUM> may broadcast the alert over the PC <NUM> interface to UEs <NUM> and <NUM> as a multi-cast message to all UEs that may be in the vicinity of the RSU <NUM> or the UE <NUM> and that may have a PC <NUM> interface connection established with the RSU <NUM> or the UE <NUM>, and not individually addressed to the UEs <NUM> and <NUM>. In an exemplary embodiment, the resources used by the RSU <NUM> or the UE <NUM> to transmit the emergency alert message over a PC <NUM> interface may be allocated by the base station <NUM> or the base station <NUM>. In the case of the UE <NUM>, the UE <NUM> may have been previously connected to a base station over a Uu connection, and could have been previously configured with sidelink resources to allow transmission over a PC <NUM> interface. In the case of the RSU <NUM>, as described herein, the RSU <NUM> may have had sidelink resources for V2X communications preconfigured, or in an exemplary embodiment where the RSU <NUM> is connected to a base station, such as base station <NUM> over optional Uu connection <NUM>, (i.e., similar to V2X node <NUM>), the sidelink resources could be configured by the base station to which the RSU <NUM> would be, or would have been, connected. In an exemplary embodiment, a UE, such as the UE <NUM> may also be at least partially pre-configured to transmit the emergency alert over the PC <NUM> interface, as described above. In this manner, a UE, such as the UE <NUM> and the UE <NUM>, which may not be capable of receiving an alert, may receive the alert communication.

In block <NUM>, it is determined whether a predefined duration of time "X" has been met. If it is determined in block <NUM> that a predefined duration of time "X" has not been met, the process returns to block <NUM> and the MTU PDU transmission continues. If it is determined in block <NUM> that a predefined duration of time "X" has been met, the process proceeds to block <NUM>.

In block <NUM>, the V2V PC <NUM> transmission of the MTU communication ceases.

<FIG> is a flow chart illustrating an example of a method <NUM> for communication, in accordance with various aspects of the present disclosure. In the method <NUM>, it is assumed that a subject UE may be a vehicle capable of vehicle-to-vehicle communication and one that is out of coverage of a WAN, in Mode <NUM>.

In block <NUM>, a Mode <NUM> UE is subscribed to emergency alerts and configured to transmit and receive over a PC <NUM> interface. For example, the UE <NUM> may be configured by its application layer to receive and transmit an emergency alert message over the PC <NUM> interface <NUM>, <NUM> and/or <NUM>.

In block <NUM>, upon receipt of an emergency alert message (from another Mode <NUM> UE or from a Mode <NUM> UE), the Mode <NUM> UE lower layer (such as its physical layer) passes the alert to the UEs upper layer (such as its application layer) along with a time stamp and a GPS position. The time stamp and GPS position may be provided by, or obtained from, the satellite <NUM> (<FIG>).

In an exemplary embodiment, because the Mode <NUM> UE receives and transmits the emergency alert over a PC <NUM> interface, in this exemplary embodiment, there is no conversion to an MTU PDU as described in <FIG> and <FIG>.

In block <NUM>, it is determined whether the alert received in block <NUM> is a duplicate alert message received within the last "M" seconds. The duration of "M" is configurable. If it is determined in block <NUM> that the alert received in block <NUM> is a duplicate alert message received within the last "M" seconds, then the message is discarded in block <NUM>. If it is determined in block <NUM> that the alert received in block <NUM> is not a duplicate alert message received within the last "M" seconds, then, the message is displayed by the UE in block <NUM>.

In block <NUM>, the Mode <NUM> UE begins forwarding the alert over one or more PC <NUM> interfaces in either a non-IP or IPv6 communication to other Mode <NUM> UEs, RSUs or other out-of-coverage Mode <NUM> UEs for a pre-determined period of time and over a pre-determined distance.

In block <NUM>, it is determined whether a predefined duration of time "X" and/or a pre-determined distance "Y" has been met. If it is determined in block <NUM> that a predefined duration of time "X" and/or a pre-determined distance "Y" has not been met, the process returns to block <NUM> and alert message transmission continues. If it is determined in block <NUM> that a predefined duration of time "X" and/or a pre-determined distance "Y" has been met, the process proceeds to block <NUM>.

In block <NUM>, the V2V PC <NUM> transmission ceases.

<FIG> is a flow chart illustrating an example of a method <NUM> for communication, in accordance with various aspects of the present disclosure. In the method <NUM>, it is assumed that a subject UE may be a V2X node, an RSU, or another node.

In block <NUM>, a V2X/RSU node is subscribed to emergency alerts and is configured to transmit and receive over a PC <NUM> interface. For example, the V2X node <NUM> may be configured by its application layer to receive and transmit an emergency alert message over the PC <NUM> interface <NUM>.

In block <NUM>, upon receipt of an emergency alert message (from another Mode <NUM> UE or from a Mode <NUM> UE), the V2X/RSU node's lower layer (such as its physical layer) passes the alert to the V2X/RSU node's upper layer (such as its application layer) along with a time stamp and a GPS position. The time stamp and GPS location may be provided by, or obtained from, the satellite <NUM> (<FIG>).

In block <NUM>, the V2X/RSU may convert the alert to a maximum transmission unit (MTU) protocol data unit (PDU) packet for transmission over a PC <NUM> interface to UEs that may not have received the SIB <NUM>, SIB <NUM> or SIB <NUM> communication, using the GNSS timing and frequency synchronization.

In block <NUM>, it is determined whether the alert received in block <NUM> is a duplicate alert message received within the last "M" seconds. If it is determined in block <NUM> that the alert received in block <NUM> is a duplicate alert message received within the last "M" seconds, then the message is discarded in block <NUM>. If it is determined in block <NUM> that the alert received in block <NUM> is not a duplicate alert message received within the last "M" seconds, then, the message is displayed by the V2X/RSU in block <NUM>.

In block <NUM>, the V2X/RSU node begins forwarding the alert over one or more PC <NUM> interfaces in either a non-IP or IPv6 communication to other Mode <NUM> UEs, RSUs or other out-of-coverage Mode <NUM> UEs for a pre-determined period of time and/or over a pre-determined distance.

<FIG> is a functional block diagram of an apparatus <NUM> for a communication system in accordance with various aspects of the present disclosure. The apparatus <NUM> comprises means <NUM> for monitoring SIB <NUM>, SIB <NUM> and SIB <NUM> and being subscribed to forward alerts. In certain embodiments, the means <NUM> for monitoring SIB <NUM>, SIB <NUM> and SIB <NUM> and being subscribed to forward alerts can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for monitoring SIB <NUM>, SIB <NUM> and SIB <NUM> and being subscribed to forward alerts may comprise a UE monitoring SIB <NUM>, SIB <NUM> and SIB <NUM> for alerts and having its application layer configured to forward the alerts over a PC <NUM> interface. For example, in an exemplary embodiment, the UEs <NUM>, <NUM>, <NUM> and <NUM>, the RSU <NUM>, the V2X node <NUM> and the network <NUM> are all always subscribed to transmit and receive CMAS alerts, ETWS alerts, and other alerts.

The apparatus <NUM> further comprises means <NUM> for displaying an alert upon receipt of a SIB <NUM>, SIB <NUM> or SIB <NUM> communication. In certain embodiments, the means <NUM> for displaying an alert upon receipt of a SIB <NUM>, SIB <NUM> or SIB <NUM> communication can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for displaying an alert upon receipt of a SIB <NUM>, SIB <NUM> or SIB <NUM> communication may comprise a UE displaying the alert on its display, the UE initiating an audible warning, the UE initiating a haptic warning, such as a vibration, or the UE otherwise displaying the alert message.

The apparatus <NUM> further comprises means <NUM> for converting the alert to an MTU PDU for transmission over a PC <NUM> interface using GNSS synchronization. In certain embodiments, the means <NUM> for converting the alert to an MTU PDU for transmission over a PC <NUM> interface using GNSS synchronization can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for converting the alert to an MTU PDU for transmission over a PC <NUM> interface using GNSS synchronization may comprise a UE converting the alert to a maximum transmission unit (MTU) protocol data unit (PDU) packet for transmission over a PC <NUM> interface to UEs that may not have received the SIB <NUM>, SIB <NUM> or SIB <NUM> communication, using GNSS timing and frequency synchronization.

The apparatus <NUM> further comprises means <NUM> for forwarding the MTU PDU communication to another UE that may not have received the alert in either a non-IP or IPv6 communication over a PC <NUM> interface with an address set to group-cast and using resources allocated from the Uu interface and resources from the UEs pre-configuration. In certain embodiments, the means <NUM> for forwarding the MTU PDU communication to another UE that may not have received the alert in either a non-IP or IPv6 communication over a PC <NUM> interface with an address set to group-cast and using resources allocated from the Uu interface and resources from the UEs pre-configuration can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for forwarding the MTU PDU communication to another UE that may not have received the alert in either a non-IP or IPv6 communication over a PC <NUM> interface with an address set to group-cast and using resources allocated from the Uu interface and resources from the UEs pre-configuration may comprise the UE <NUM> broadcasting the alert over the PC <NUM> interface to UEs <NUM> and <NUM> as a multi-cast message to all UEs that may be in the vicinity of the UE <NUM> and that may have a PC <NUM> interface connection established with the UE <NUM>, not individually addressed to the UEs <NUM> and <NUM>. In an exemplary embodiment, the resources used by the IE <NUM> to transmit the emergency alert message over the PC <NUM> interface may be allocated by the base station <NUM> over the Uu interface <NUM>. In an exemplary embodiment, a UE, such as the UE <NUM> may also be at least partially pre-configured to transmit the emergency alert over the PC <NUM> interface.

The apparatus <NUM> further comprises means <NUM> for determining whether a predefined duration of time "X" and/or a pre-determined distance "Y" has been met. In certain embodiments, the means <NUM> for determining whether a predefined duration of time "X" and/or a pre-determined distance "Y" has been met can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for determining whether a predefined duration of time "X" and/or a pre-determined distance "Y" has been met may comprise a UE determining whether a predefined duration of time "X" and/or a pre-determined distance "Y" has been met to determine whether to maintain broadcasting the emergency alert over the PC <NUM> interface.

The apparatus <NUM> further comprises means <NUM> for ceasing V2V PC <NUM> transmission. In certain embodiments, the means <NUM> for ceasing V2V PC <NUM> transmission can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for ceasing V2V PC <NUM> transmission may comprise a UE determining that transmission of the emergency alert over the PC <NUM> interface should be terminated.

<FIG> is a functional block diagram of an apparatus <NUM> for a communication system in accordance with various aspects of the present disclosure. The apparatus <NUM> comprises means <NUM> for an RSU monitoring an IP network for an alert; or a CV2X/LTE/<NUM> device periodically monitoring system information block (SIB) <NUM>, SIB <NUM> and SIB <NUM> signals for alerts. In certain embodiments, the means <NUM> for an RSU monitoring an IP network for an alert; or a CV2X/LTE/<NUM> device periodically monitoring system information block (SIB) <NUM>, SIB <NUM> and SIB <NUM> signals for alerts can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for an RSU monitoring an IP network for an alert; or a CV2X/LTE/<NUM> device periodically monitoring system information block (SIB) <NUM>, SIB <NUM> and SIB <NUM> signals for alerts may comprise monitoring for a CMAS communication or an ETWS communication and the RSU or the UE being subscribed at its application layer to forward these alerts. For example, an RSU or a UE may have its upper communication layers, such as its application layer, configured or pre-configured to be subscribed to various applications and may have its transmit and receive properties configured accordingly. For example, in an exemplary embodiment, the UEs <NUM>, <NUM>, <NUM> and <NUM>, the RSU <NUM>, the V2X node <NUM> and the network <NUM> are all always subscribed to transmit and receive CMAS alerts, ETWS alerts, and other alerts.

The apparatus <NUM> further comprises means <NUM> for converting the alert to an MTU PDU for transmission over a PC <NUM> interface using GNSS synchronization. In certain embodiments, the means <NUM> for converting the alert to an MTU PDU for transmission over a PC <NUM> interface using GNSS synchronization can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for converting the alert to an MTU PDU for transmission over a PC <NUM> interface using GNSS synchronization may comprise an RSU or a UE converting the alert to a maximum transmission unit (MTU) protocol data unit (PDU) packet for transmission over a PC <NUM> interface to UEs that may not have received the SIB <NUM>, SIB <NUM> or SIB <NUM> communication, using GNSS synchronization.

The apparatus <NUM> further comprises means <NUM> for forwarding the MTU PDU communication to another UE that may not have received the alert in either a non-IP or IPv6 communication over a PC <NUM> interface with an address set to group-cast and using resources allocated from the Uu interface and resources from the UEs pre-configuration. In certain embodiments, the means <NUM> for forwarding the MTU PDU communication to another UE that may not have received the alert in either a non-IP or IPv6 communication over a PC <NUM> interface with an address set to group-cast and using resources allocated from the Uu interface and resources from the UEs pre-configuration can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for forwarding the MTU PDU communication to another UE that may not have received the alert in either a non-IP or IPv6 communication over a PC <NUM> interface with an address set to group-cast and using resources allocated from the Uu interface and resources from the UEs pre-configuration may comprise the RSU <NUM> or the UE <NUM> broadcasting the alert over the PC <NUM> interface to UEs <NUM> and <NUM> as a multi-cast message to all UEs that may be in the vicinity of the UE <NUM> or the RSU <NUM> and that may have a PC <NUM> interface connection established with the UE <NUM>, not individually addressed to the UEs <NUM> and <NUM>. In an exemplary embodiment, the resources used by the UE <NUM> to transmit the emergency alert message over the PC <NUM> interface may be allocated by the base station <NUM> over the Uu interface <NUM>. In an exemplary embodiment, a UE, such as the UE <NUM> may also be at least partially pre-configured to transmit the emergency alert over the PC <NUM> interface.

The apparatus <NUM> further comprises means <NUM> for determining whether a predefined duration of time "X" has been met. In certain embodiments, the means <NUM> for determining whether a predefined duration of time "X" has been met can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for determining whether a predefined duration of time "X" has been met may comprise a UE determining whether a predefined duration of time "X" has been met to determine whether to maintain broadcasting the emergency alert over the PC <NUM> interface.

<FIG> is a functional block diagram of an apparatus <NUM> for a communication system in accordance with various aspects of the present disclosure. The apparatus <NUM> comprises means <NUM> for subscribing to emergency alerts and transmitting and receiving over a PC <NUM> interface. In certain embodiments, the means <NUM> for subscribing to emergency alerts and transmitting and receiving over a PC <NUM> interface can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for subscribing to emergency alerts and transmitting and receiving over a PC <NUM> interface may comprise the UE <NUM> being configured by its application layer to receive and transmit an emergency alert message over the PC <NUM> interface <NUM>, <NUM> and/or <NUM>.

The apparatus <NUM> further comprises means <NUM> for a device's lower layer passing the alert to the device's upper layer along with a time stamp and a GPS position. In certain embodiments, the means <NUM> for a device's lower layer passing the alert to the device's upper layer along with a time stamp and a GPS position can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for a device's lower layer passing the alert to the device's upper layer along with a time stamp and a GPS position may comprise a Mode <NUM> UE's lower layer (such as its physical layer) passing the alert to the UE's upper layer (such as its application layer) along with a time stamp and a GPS position. The time stamp and GPS location may be provided by, or obtained from, the satellite <NUM> (<FIG>).

The apparatus <NUM> further comprises means <NUM> for determining whether the received alert is a duplicate alert message received within the last "M" seconds. In certain embodiments, the means <NUM> for determining whether the received alert is a duplicate alert message received within the last "M" seconds can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for determining whether the received alert is a duplicate alert message received within the last "M" seconds may comprise the UE <NUM> determining whether the alert was a duplicate received in the last "M" seconds.

The apparatus <NUM> further comprises means <NUM> for discarding the message if the alert was a duplicate received within the last "M" seconds. In certain embodiments, the means <NUM> for discarding the message if the alert was a duplicate received within the last "M" seconds can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for discarding the message if the alert was a duplicate received within the last "M" seconds may comprise the UE <NUM> discarding the message.

The apparatus <NUM> further comprises means <NUM> for displaying the alert. In certain embodiments, the means <NUM> for displaying the alert can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for displaying the alert may comprise a UE displaying the alert on its display, the UE initiating an audible warning, the UE initiating a haptic warning, such as a vibration, or the UE otherwise displaying the alert message.

The apparatus <NUM> further comprises means <NUM> for forwarding the MTU communication to another UE that may not have received the alert in either a non-IP or IPv6 communication over a PC <NUM> interface with an address set to group-cast. In certain embodiments, the means <NUM> for forwarding the MTU communication to another UE that may not have received the alert in either a non-IP or IPv6 communication over a PC <NUM> interface with an address set to group-cast can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for forwarding the MTU communication to another UE that may not have received the alert in either a non-IP or IPv6 communication over a PC <NUM> interface with an address set to group-cast may comprise the Mode <NUM> UE forwarding the alert over one or more PC <NUM> interfaces in either a non-IP or IPv6 communication to other Mode <NUM> UEs, RSUs or other out-of-coverage Mode <NUM> UEs for a pre-determined period of time and over a pre-determined distance.

<FIG> is a functional block diagram of an apparatus <NUM> for a communication system in accordance with various aspects of the present disclosure. The apparatus <NUM> comprises means <NUM> for subscribing to emergency alerts and transmitting and receiving over a PC <NUM> interface. In certain embodiments, the means <NUM> for subscribing to emergency alerts and transmitting and receiving over a PC <NUM> interface can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for subscribing to emergency alerts and transmitting and receiving over a PC <NUM> interface may comprise the V2X node <NUM> being configured by its application layer to receive and transmit an emergency alert message over the PC <NUM> interface <NUM>.

The apparatus <NUM> further comprises means <NUM> for a device's lower layer passing the alert to the device's upper layer along with a time stamp and a GPS position. In certain embodiments, the means <NUM> for a device's lower layer passing the alert to the device's upper layer along with a time stamp and a GPS position can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for a device's lower layer passing the alert to the device's upper layer along with a time stamp and a GPS position may comprise the V2X/RSU node's lower layer (such as its physical layer) passing the alert to the V2X/RSU node's upper layer (such as its application layer) along with a time stamp and a GPS position.

The apparatus <NUM> further comprises means <NUM> for converting the alert to an MTU PDU for transmission over a PC <NUM> interface using GNSS synchronization. In certain embodiments, the means <NUM> for converting the alert to an MTU PDU for transmission over a PC <NUM> interface using GNSS synchronization can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for converting the alert to an MTU PDU for transmission over a PC <NUM> interface using GNSS synchronization may comprise the V2X/RSU converting the alert to a maximum transmission unit (MTU) protocol data unit (PDU) packet for transmission over a PC <NUM> interface to UEs that may not have received the SIB <NUM>, SIB <NUM> or SIB <NUM> communication, using the GNSS synchronization.

The apparatus <NUM> further comprises means <NUM> for determining whether the received alert is a duplicate alert message received within the last "M" seconds. In certain embodiments, the means <NUM> for determining whether the received alert is a duplicate alert message received within the last "M" seconds can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for determining whether the received alert is a duplicate alert message received within the last "M" seconds may comprise the V2X/RSU determining whether the alert was a duplicate received in the last "M" seconds.

The apparatus <NUM> further comprises means <NUM> for discarding the message if the alert was a duplicate received within the last "M" seconds. In certain embodiments, the means <NUM> for discarding the message if the alert was a duplicate received within the last "M" seconds can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for discarding the message if the alert was a duplicate received within the last "M" seconds may comprise the V2X/RSU node <NUM> discarding the message.

The apparatus <NUM> further comprises means <NUM> for displaying the alert. In certain embodiments, the means <NUM> for displaying the alert can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for displaying the alert may comprise a V2X/RSU node <NUM> displaying the alert on its display, the V2X/RSU node <NUM> initiating an audible warning, the V2X/RSU node <NUM> initiating a haptic warning, such as a vibration, or the UE otherwise displaying the alert message.

The apparatus <NUM> further comprises means <NUM> for forwarding the MTU PDU communication to another UE that may not have received the alert in either a non-IP or IPv6 communication over a PC <NUM> interface with an address set to group-cast. In certain embodiments, the means <NUM> for forwarding the MTU PDU communication to another UE that may not have received the alert in either a non-IP or IPv6 communication over a PC <NUM> interface with an address set to group-cast can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for forwarding the MTU PDU communication to another UE that may not have received the alert in either a non-IP or IPv6 communication over a PC <NUM> interface with an address set to group-cast may comprise the V2X/RSU node <NUM> forwarding the alert over one or more PC <NUM> interfaces in either a non-IP or IPv6 communication to other Mode <NUM> UEs, RSUs or other out-of-coverage Mode <NUM> UEs for a pre-determined period of time and over a pre-determined distance.

The apparatus <NUM> further comprises means <NUM> for determining whether a predefined duration of time "X" and/or a pre-determined distance "Y" has been met. In certain embodiments, the means <NUM> for determining whether a predefined duration of time "X" and/or a pre-determined distance "Y" has been met can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for determining whether a predefined duration of time "X" and/or a pre-determined distance "Y" has been met may comprise a V2X/RSU node <NUM> determining whether a predefined duration of time "X" and/or a pre-determined distance "Y" has been met to determine whether to maintain broadcasting the emergency alert over the PC <NUM> interface.

The apparatus <NUM> further comprises means <NUM> for ceasing V2V PC <NUM> transmission. In certain embodiments, the means <NUM> for ceasing V2V PC <NUM> transmission can be configured to perform one or more of the function described in operation block <NUM> of method <NUM> (<FIG>). In an exemplary embodiment, the means <NUM> for ceasing V2V PC <NUM> transmission may comprise a V2X/RSU node <NUM> determining that transmission of the emergency alert over the PC <NUM> interface should be terminated.

The detailed description set forth above in connection with the appended drawings describes examples and does not represent the only examples that may be implemented or that are within the scope of the claims. The terms "example" and "exemplary," when used in this description, mean "serving as an example, instance, or illustration," and not "preferred" or "advantageous over other examples.

The various illustrative blocks and components described in connection with the disclosure herein may be implemented or performed with a general-purpose processor, a digital signal processor (DSP), an ASIC, an FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

Also, as used herein, including in the claims, "or" as used in a list of items (for example, a list of items prefaced by a phrase such as "at least one of" or "one or more of") indicates a disjunctive list such that, for example, a list of "at least one of A, B, or C" means A or B or C or AB or AC or BC or ABC (i.e., A and B and C).

Claim 1:
A method for wireless communication at a first communication device (<NUM>), comprising:
receiving an alert broadcast over a first communication network (<NUM>; <NUM>) in a first format, wherein the method is characterized by:
converting the alert to a second format compatible with transmission over a sidelink interface in a second communication network; and
forwarding the alert in the second format over the sidelink interface to a second communication device (<NUM>; <NUM>) in the second communication network;
wherein the second communication network is different from the first communication network and comprises a vehicle-to-vehicle communication network, and further wherein the second communication device (<NUM>; <NUM>) is incapable of receiving the alert over the first communication network (<NUM>; <NUM>) in the first format.