阅读说明：本技术 多跳无线中继支持 (Multi-hop wireless relay support ) 是由 米歇尔·佩拉斯 萨阿德·艾哈迈德 E·泽拉 于 2020-04-23 设计创作，主要内容包括：本发明公开了用于多跳中继的方法、设备和系统,该多跳中继可通过以下方式来实现：通告第一中继能力和到达远程无线发射/接收单元(WTRU)的第一跳数；接收第二中继能力和从所选择的中继WTRU到达该远程WTRU的第二跳数；基于该第二中继能力和该第二跳数来更新中继能力表；接收包括有效载荷的分组,该分组具有流量类型并且还包括最大跳数；基于该流量类型、该最大跳数和该中继能力表来选择所选择的中继WTRU；生成第一更新分组,该第一更新分组包括该有效载荷、该流量类型和比该最大跳数小一的第一更新跳数；以及将该第一更新分组传输到所选择的中继WTRU。(The invention discloses a method, equipment and a system for multi-hop relay, wherein the multi-hop relay can be realized by the following steps: advertising a first relay capability and a first number of hops to reach a remote wireless transmit/receive unit (WTRU); receiving a second relay capability and a second number of hops to reach the remote WTRU from the selected relay WTRU; updating a relay capability table based on the second relay capability and the second hop count; receiving a packet comprising a payload, the packet having a traffic type and further comprising a maximum number of hops; selecting the selected relay WTRU based on the traffic type, the maximum hop count, and the relay capability table; generating a first update packet comprising the payload, the traffic type, and a first update hop count that is one less than the maximum hop count; and transmitting the first update packet to the selected relay WTRU.)

1. A method for multihop relay transmission in a mesh network, the method comprising:

advertising a first relay capability and a first number of hops to reach a remote wireless transmit/receive unit (WTRU);

receiving a second relay capability and a second number of hops to reach the remote WTRU from the selected relay WTRU;

updating a relay capability table based on the second relay capability and the second hop count;

receiving a packet comprising a payload, the packet having a traffic type and further comprising a maximum number of hops;

selecting the selected relay WTRU based on the traffic type, the maximum hop count, and the relay capability table;

generating a first update packet comprising the payload, the traffic type, and a first update hop count that is one less than the maximum hop count; and

transmitting the first update packet to the selected relay WTRU.

2. The method of claim 1, wherein the selected relay WTRU is selected based on the second relay capability including the traffic type.

3. The method of claim 1, wherein the relay capability table includes the second hop count, and the selected relay WTRU is selected based on the second hop count being less than the first updated hop count.

4. The method of claim 1 wherein the remote WTRU is out of coverage from a core network.

5. The method of claim 1, wherein the packet further comprises a remote WTRU identifier.

6. The method of claim 1, wherein the traffic type is one of Mobility Management (MM) signaling, Session Management (SM) signaling, and user plane data.

7. The method of claim 1, wherein the packet is discarded when the first update number is less than one.

8. The method of claim 1, further comprising establishing a one-to-one connection with the selected relay WTRU.

9. The method of claim 1, wherein updating the relay capability table is based on an advertisement by each other relay WTRU in a plurality of relay WTRUs in the mesh network.

10. The method of claim 9, wherein the advertising comprises each of the plurality of relay WTRUs advertising the number of hops to reach the remote WTRU for each traffic type.

11. A method for multihop relay transmission in a mesh network, the method comprising:

advertising a first relay capability and a first number of hops to reach a core network;

receiving a second relay capability and a second number of hops from the selected relay wireless transmit/receive unit (WTRU) to the core network;

updating a relay capability table based on the second relay capability and the second hop count;

receiving a packet comprising a payload, the packet having a traffic type and further comprising a maximum number of hops;

selecting the selected relay WTRU based on the traffic type, the maximum hop count, and the relay capability table;

generating a first update packet comprising the payload, the traffic type, and a first update hop count that is one less than the maximum hop count; and

transmitting the first update packet to the selected relay WTRU.

12. The method of claim 11, wherein the selected relay WTRU is selected based on the second relay capability.

13. The method of claim 11, wherein the selected relay WTRU is selected based on the second hop count being less than the first updated hop count.

14. The method of claim 11, wherein each of a plurality of relay WTRUs in the mesh network updates its relay capability table based on an advertisement by each other relay WTRU in the plurality of relay WTRUs in the mesh network.

15. A wireless transmit/receive unit (WTRU) comprising:

a transmitter;

a receiver; and

a processor; the WTRU is configured to:

advertising, via the transmitter, a first relay capability and a first number of hops to reach a remote WTRU;

receiving, via the receiver, a second relay capability and a second number of hops to reach the remote WTRU from the selected relay WTRU;

updating, via the processor, a relay capability table based on the second relay capability and the second hop count;

receiving, via the receiver, a packet comprising a payload, the packet having a traffic type and further comprising a maximum number of hops;

selecting, via the processor, the selected relay WTRU based on the traffic type, the maximum hop count, and the relay capability table;

generating, via the processor, a first update packet comprising the payload, the traffic type, and a first update hop count that is one less than the maximum hop count; and

transmitting the first update packet to the selected relay WTRU via the transmitter.

16. The WTRU of claim 15, wherein the selected relay WTRU is selected based on the second relay capability including the traffic type.

17. The WTRU of claim 15, wherein the selected relay WTRU is selected based on the second hop count being less than the first updated hop count.

18. The WTRU of claim 15, wherein the packet further comprises a remote WTRU identifier.

19. The WTRU of claim 15 further configured to establish a one-to-one connection with the selected relay WTRU.

20. The WTRU of claim 15 wherein the processor updates the relay capability table based on an advertisement by at least one relay WTRU of a plurality of WTRUs in a mesh network.

Background

A network relay is a composite of a node B from the wireless transmit/receive unit (WTRU) side and a WTRU from the network side. Operators sometimes use network relays to extend network coverage, but usually at the expense of network capacity.

In broadcast mode (where relay selection may not be meaningful), using the WTRU as a relay has been limited to mission critical and vehicle-to-all (V2X) operation. Furthermore, it is specified that the WTRU as a relay is only used for two hops (i.e., remote WTRU to relay WTRU to gNB). Better energy efficiency and wider coverage may be required compared to the prior art.

Disclosure of Invention

The invention discloses a method, a device and a system for multi-hop relay in a mesh network. According to embodiments, such techniques may be implemented by: advertising a first relay capability and a first number of hops to reach a remote wireless transmit/receive unit (WTRU); receiving a second relay capability and a second number of hops to reach the remote WTRU from the selected relay WTRU; updating a relay capability table based on the second relay capability and the second hop count; receiving a packet comprising a payload, the packet having a traffic type and further comprising a maximum number of hops; selecting the selected relay WTRU based on the traffic type, the maximum hop count, and the relay capability table; generating a first update packet comprising the payload, the traffic type, and a first update hop count that is one less than the maximum hop count; and transmitting the first update packet to the selected relay WTRU.

The selected relay WTRU may be selected based on the second relay capability including the traffic type. The relay capability table may include the second hop count and the selected relay WTRU may be selected based on the second hop count being less than the first updated hop count. The remote WTRU may be out of coverage from the core network. The packet may also include a remote WTRU identifier. The traffic type may be one of Mobility Management (MM) signaling, Session Management (SM) signaling, and user plane data. Additionally, the packet may be discarded when the first update hop count is less than one. A one-to-one connection may be established with the selected relay WTRU. Updating the relay capability table may be based on an advertisement by each other relay WTRU of a plurality of relay WTRUs in the mesh network, and the advertisement may include the number of hops to reach the remote WTRU being advertised by each relay WTRU of the plurality of relay WTRUs for each traffic type.

According to embodiments, such techniques may be implemented by: advertising a first relay capability and a first number of hops to reach a core network; receiving a second relay capability and a second number of hops to reach the core network from the selected relay WTRU; updating a relay capability table based on the second relay capability and the second hop count; receiving a packet comprising a payload, the packet having a traffic type and further comprising a maximum number of hops; selecting the selected relay WTRU based on the traffic type, the maximum hop count, and the relay capability table; generating a first update packet comprising the payload, the traffic type, and a first update hop count that is one less than the maximum hop count; and transmitting the first update packet to the selected relay WTRU.

The selected relay WTRU may be selected based on the second relay capability and/or may be selected based on the second hop count being less than the first updated hop count. Each of the plurality of relay WTRUs in the mesh network may update its relay capability table based on the advertisement by each other relay WTRU in the plurality of relay WTRUs in the mesh network.

Depending on the embodiment, such techniques may be implemented by a WTRU including a transmitter, a receiver, and a processor. The WTRU may be configured to: advertising, via the transmitter, a first relay capability and a first number of hops to reach a remote WTRU; receiving, via the receiver, a second relay capability and a second number of hops to reach the remote WTRU from the selected relay WTRU; updating, via the processor, a relay capability table based on the second relay capability and the second hop count; receiving, via the receiver, a packet comprising a payload, the packet having a traffic type and further comprising a maximum number of hops; selecting, via the processor, the selected relay WTRU based on the traffic type, the maximum hop count, and the relay capability table; generating, via the processor, a first update packet comprising the payload, the traffic type, and a first update hop count that is one less than the maximum hop count; and transmitting the first update packet to the selected relay WTRU via the transmitter. The packet may also include a remote WTRU identifier. The processor may update the relay capability table based on an advertisement by at least one relay WTRU of a plurality of WTRUs in the mesh network.

Drawings

A more particular understanding can be obtained from the following description taken in conjunction with the accompanying drawings, in which like reference numbers indicate like elements, and wherein:

FIG. 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;

figure 1B is a system diagram illustrating an exemplary wireless transmit/receive unit (WTRU) that may be used within the communication system shown in figure 1A according to one embodiment;

fig. 1C is a system diagram illustrating an exemplary Radio Access Network (RAN) and an exemplary Core Network (CN) that may be used within the communication system shown in fig. 1A according to one embodiment;

figure 1D is a system diagram illustrating another exemplary RAN and another exemplary CN that may be used within the communication system shown in figure 1A according to one embodiment;

FIG. 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;

figure 1B is a system diagram illustrating an exemplary wireless transmit/receive unit (WTRU) that may be used within the communication system shown in figure 1A according to one embodiment;

fig. 1C is a system diagram illustrating an exemplary Radio Access Network (RAN) and an exemplary Core Network (CN) that may be used within the communication system shown in fig. 1A according to one embodiment;

figure 1D is a system diagram illustrating another exemplary RAN and another exemplary CN that may be used within the communication system shown in figure 1A according to one embodiment;

figure 2 is a system diagram illustrating an example of a mesh network of relay WTRUs;

fig. 3 is a diagram illustrating an exemplary method for multihop relay;

fig. 4 is a system diagram illustrating an example of hopping to the network in the Uplink (UL) direction;

fig. 5 is a system diagram illustrating an example of hopping to the network in the Downlink (DL) direction;

fig. 6 is a diagram illustrating an exemplary method for one-to-one communication establishment and traffic forwarding;

fig. 7A is a flow diagram illustrating DL transmission in a multihop mesh network; and is

Fig. 7B is a flow diagram illustrating UL transmission in a multi-hop mesh network.

Detailed Description

Fig. 1A is a schematic diagram illustrating an exemplary communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcast, etc., to a plurality of wireless users. Communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, communication system 100 may employ one or more channel access methods such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), orthogonal FDMA (ofdma), single carrier FDMA (SC-FDMA), zero-tailed unique word discrete fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), and so forth.

As shown in fig. 1A, the communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a Radio Access Network (RAN)104, a Core Network (CN)106, a Public Switched Telephone Network (PSTN)108, the internet 110, and other networks 112, although it is understood that any number of WTRUs, base stations, networks, and/or network elements are contemplated by the disclosed embodiments. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a Station (STA)) may be configured to transmit and/or receive wireless signals, and may include User Equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, Personal Digital Assistants (PDAs), smart phones, laptops, netbooks, personal computers, wireless sensors, hotspot or Mi-Fi devices, internet of things (IoT) devices, watches or other wearable devices, head-mounted displays (HMD), vehicles, drones, medical devices and applications (e.g., tele-surgery), industrial devices and applications (e.g., robots and/or other wireless devices operating in industrial and/or automated processing chain environments), consumer electronics, devices operating on commercial and/or industrial wireless networks, and so forth. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a WTRU.

Communication system 100 may also include base station 114a and/or base station 114 b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114B may be Base Transceiver Stations (BTSs), nodebs, evolved node bs (enbs), home nodebs, home evolved node bs, next generation nodebs, such as a enode B (gNB), New Radio (NR) NodeB, site controllers, Access Points (APs), wireless routers, and so forth. Although the base stations 114a, 114b are each depicted as a single element, it should be understood that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

The base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as Base Station Controllers (BSCs), Radio Network Controllers (RNCs), relay nodes, and so forth. Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for wireless services to a particular geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of a cell. For example, beamforming may be used to transmit and/or receive signals in a desired spatial direction.

The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., Radio Frequency (RF), microwave, centimeter-wave, micrometer-wave, Infrared (IR), Ultraviolet (UV), visible, etc.). Air interface 116 may be established using any suitable Radio Access Technology (RAT).

More specifically, as indicated above, communication system 100 may be a multiple-access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) terrestrial radio access (UTRA), which may establish the air interface 116 using wideband cdma (wcdma). WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or evolved HSPA (HSPA +). HSPA may include high speed Downlink (DL) packet access (HSDPA) and/or high speed Uplink (UL) packet access (HSUPA).

In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as evolved UMTS terrestrial radio access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-advanced (LTE-a) and/or LTE-advanced Pro (LTE-a Pro).

In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access that may use NR to establish the air interface 116.

In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may together implement LTE radio access and NR radio access, e.g., using Dual Connectivity (DC) principles. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., eNB and gNB).

In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA 20001X, CDMA2000 EV-DO, interim standard 2000(IS-2000), interim standard 95(IS-95), interim standard 856(IS-856), Global System for Mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), GSM EDGE (GERAN), and the like.

The base station 114B in fig. 1A may be, for example, a wireless router, a home nodeb, a home enodeb, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business, home, vehicle, campus, industrial facility, air corridor (e.g., for use by a drone), road, and so forth. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a Wireless Local Area Network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE-A, LTE-a Pro, NR, etc.) to establish the pico cell or the femto cell. As shown in fig. 1A, the base station 114b may have a direct connection to the internet 110. Thus, the base station 114b may not need to access the internet 110 via the CN 106.

The RAN 104 may communicate with a CN 106, which may be any type of network configured to provide voice, data, application, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102 d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and so forth. The CN 106 may provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in fig. 1A, it should be understood that the RAN 104 and/or the CN 106 may communicate directly or indirectly with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to connecting to the RAN 104, which may utilize NR radio technologies, the CN 106 may communicate with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technologies.

The CN 106 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the internet 110, and/or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides Plain Old Telephone Service (POTS). The internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and/or the Internet Protocol (IP) in the TCP/IP internet protocol suite. The network 112 may include wired and/or wireless communication networks owned and/or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in fig. 1A may be configured to communicate with a base station 114a, which may employ a cellular-based radio technology, and with a base station 114b, which may employ an IEEE 802 radio technology.

Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in fig. 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a Global Positioning System (GPS) chipset 136, and/or other peripherals 138, among others. It should be understood that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), any other type of Integrated Circuit (IC), a state machine, or the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120, which may be coupled to a transmit/receive element 122. Although fig. 1B depicts the processor 118 and the transceiver 120 as separate components, it should be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

Transmit/receive element 122 may be configured to transmit signals to and receive signals from a base station (e.g., base station 114a) over air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In one embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and/or receive RF and optical signals. It should be appreciated that transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

Although transmit/receive element 122 is depicted in fig. 1B as a single element, WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

Transceiver 120 may be configured to modulate signals to be transmitted by transmit/receive element 122 and demodulate signals received by transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker/microphone 124, a keypad 126, and/or a display/touch pad 128, such as a Liquid Crystal Display (LCD) display unit or an Organic Light Emitting Diode (OLED) display unit. The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. Further, the processor 118 may access information from, and store data in, any type of suitable memory, such as non-removable memory 130 and/or removable memory 132. The non-removable memory 130 may include Random Access Memory (RAM), Read Only Memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, a memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown).

The processor 118 may receive power from the power source 134 and may be configured to distribute and/or control power to other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, power source 134 may include one or more dry cell batteries (e.g., nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, and the like.

The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) over the air interface 116 and/or determine its location based on the timing of the signals received from two or more nearby base stations. It should be appreciated that the WTRU 102 may acquire location information by any suitable location determination method while remaining consistent with an embodiment.

The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and/or hardware modules that provide additional features, functionality, and/or wired or wireless connectivity. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and/or video), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a microphone, and/or the like,A module, a Frequency Modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and/or augmented reality (VR/AR) device, an activity tracker, and/or the like. Peripheral device 138 may include one or more sensors. The sensor may be one or more of: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, and a time sensor; a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, and the like.

The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with particular subframes for UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and/or simultaneous. A full-duplex radio may include an interference management unit to reduce and/or substantially eliminate self-interference via hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for which some or all signals are transmitted and received (e.g., associated with a particular subframe for UL (e.g., for transmission) or DL (e.g., for reception)).

Figure 1C is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As described above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using E-UTRA radio technology. The RAN 104 may also communicate with the CN 106.

RAN 104 may include enodebs 160a, 160B, 160c, but it should be understood that RAN 104 may include any number of enodebs while remaining consistent with an embodiment. The enodebs 160a, 160B, 160c may each include one or more transceivers to communicate with the WTRUs 102a, 102B, 102c over the air interface 116. In one embodiment, the enode bs 160a, 160B, 160c may implement MIMO technology. Thus, for example, the enode B160a may use multiple antennas to transmit wireless signals to the WTRU 102a and/or receive wireless signals from the WTRU 102 a.

Each of the enodebs 160a, 160B, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and the like. As shown in fig. 1C, enode bs 160a, 160B, 160C may communicate with each other over an X2 interface.

The CN 106 shown in fig. 1C may include a Mobility Management Entity (MME)162, a Serving Gateway (SGW)164, and a Packet Data Network (PDN) gateway (PGW) 166. While the foregoing elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and/or operated by an entity other than the CN operator.

MME 162 may be connected to each of enodebs 162a, 162B, 162c in RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during initial attachment of the WTRUs 102a, 102b, 102c, and the like. MME 162 may provide a control plane function for switching between RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and/or WCDMA.

SGW 164 may be connected to each of enodebs 160a, 160B, 160c in RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102 c. The SGW 164 may perform other functions such as anchoring the user plane during inter-enode B handover, triggering paging when DL data is available to the WTRUs 102a, 102B, 102c, managing and storing the context of the WTRUs 102a, 102B, 102c, and the like.

The SGW 164 may be connected to a PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network (such as the PSTN 108) to facilitate communications between the WTRUs 102a, 102b, 102c and conventional, legacy, landline communication devices. For example, the CN 106 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Additionally, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers.

Although the WTRU is depicted in fig. 1A-1D as a wireless terminal, it is contemplated that in some representative embodiments, such a terminal may use a wired communication interface (e.g., temporarily or permanently) with a communication network.

In a representative embodiment, the other network 112 may be a WLAN.

A WLAN in infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may have access or interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic to and/or from the BSS. Traffic originating outside the BSS and directed to the STA may arrive through the AP and may be delivered to the STA. Traffic originating from the STAs and directed to destinations outside the BSS may be sent to the AP to be delivered to the respective destinations. Traffic between STAs within a BSS may be sent through the AP, e.g., where a source STA may send traffic to the AP and the AP may pass the traffic to a destination STA. Traffic between STAs within a BSS may be considered and/or referred to as point-to-point traffic. Direct Link Setup (DLS) may be utilized to transmit point-to-point traffic between (e.g., directly between) a source and destination STA. In certain representative embodiments, DLS may use 802.11e DLS or 802.11z tunnel DLS (tdls). A WLAN using Independent Bss (IBSS) mode may not have an AP, and STAs within or using IBSS (e.g., all STAs) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

When using an 802.11ac infrastructure mode of operation or a similar mode of operation, the AP may transmit beacons on a fixed channel, such as the primary channel. The primary channel may be a fixed width (e.g., a20 MHz wide bandwidth) or a dynamically set width. The primary channel may be an operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access with collision avoidance (CSMA/CA) may be implemented, for example, in 802.11 systems. For CSMA/CA, an STA (e.g., each STA), including an AP, may listen to the primary channel. A particular STA may back off if the primary channel is sensed/detected and/or determined to be busy by the particular STA. One STA (e.g., only one station) may transmit at any given time in a given BSS.

High Throughput (HT) STAs may communicate using a 40 MHz-wide channel, e.g., via a combination of a primary 20MHz channel and an adjacent or non-adjacent 20MHz channel to form a 40 MHz-wide channel.

Very High Throughput (VHT) STAs may support channels that are 20MHz, 40MHz, 80MHz, and/or 160MHz wide. 40MHz and/or 80MHz channels may be formed by combining consecutive 20MHz channels. The 160MHz channel may be formed by combining 8 contiguous 20MHz channels, or by combining two non-contiguous 80MHz channels (this may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel encoding, the data may pass through a segment parser that may split the data into two streams. Each stream may be separately subjected to Inverse Fast Fourier Transform (IFFT) processing and time domain processing. These streams may be mapped to two 80MHz channels and data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the above-described operations for the 80+80 configuration may be reversed, and the combined data may be transmitted to a Medium Access Control (MAC).

802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11 ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the television white space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using the non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter type control/Machine Type Communication (MTC), such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., supporting only) certain bandwidths and/or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

WLAN systems that can support multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by STAs from all STAs operating in the BSS (which support the minimum bandwidth operating mode). In the 802.11ah example, for STAs (e.g., MTC-type devices) that support (e.g., only support) the 1MHz mode, the primary channel may be 1MHz wide, even though the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and/or other channel bandwidth operating modes. Carrier sensing and/or Network Allocation Vector (NAV) setting may depend on the state of the primary channel. If the primary channel is busy, for example, because STAs (supporting only 1MHz mode of operation) are transmitting to the AP, the entire available band may be considered busy even though most of the available band remains idle.

In the united states, the available frequency band for 802.11ah is 902MHz to 928 MHz. In korea, the available frequency band is 917.5MHz to 923.5 MHz. In Japan, the available frequency band is 916.5MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.

Figure 1D is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As indicated above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using NR radio technology. The RAN 104 may also communicate with the CN 106.

RAN 104 may include gnbs 180a, 180b, 180c, but it should be understood that RAN 104 may include any number of gnbs while remaining consistent with an embodiment. The gnbs 180a, 180b, 180c may each include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gnbs 180a, 180b, 180c may implement MIMO techniques. For example, the gnbs 180a, 108b may utilize beamforming to transmit signals to the gnbs 180a, 180b, 180c and/or receive signals from the gnbs 180a, 180b, 180 c. Thus, the gNB180a may use multiple antennas to transmit wireless signals to the WTRU 102a and/or receive wireless signals from the WTRU 102a, for example. In one embodiment, the gnbs 180a, 180b, 180c may implement carrier aggregation techniques. For example, the gNB180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on the unlicensed spectrum, while the remaining component carriers may be on the licensed spectrum. In one embodiment, the gnbs 180a, 180b, 180c may implement coordinated multipoint (CoMP) techniques. For example, WTRU 102a may receive a cooperative transmission from gNB180a and gNB180 b (and/or gNB180 c).

The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using transmissions associated with the set of scalable parameters. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using subframes or Transmission Time Intervals (TTIs) of various or extendable lengths (e.g., including different numbers of OFDM symbols and/or varying absolute lengths of time).

The gnbs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in an independent configuration and/or in a non-independent configuration. In a standalone configuration, the WTRUs 102a, 102B, 102c may communicate with the gnbs 180a, 180B, 180c while also not visiting other RANs (e.g., such as the enodebs 160a, 160B, 160 c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gnbs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using signals in an unlicensed frequency band. In a non-standalone configuration, the WTRUs 102a, 102B, 102c may communicate or connect with the gnbs 180a, 180B, 180c, while also communicating or connecting with other RANs, such as the eNode-B160a, 160B, 160 c. For example, the WTRUs 102a, 102B, 102c may implement the DC principles to communicate with one or more gnbs 180a, 180B, 180c and one or more enodebs 160a, 160B, 160c substantially simultaneously. In a non-standalone configuration, the enodebs 160a, 160B, 160c may serve as mobility anchors for the WTRUs 102a, 102B, 102c, and the gnbs 180a, 180B, 180c may provide additional coverage and/or throughput for the serving WTRUs 102a, 102B, 102 c.

Each of the gnbs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and/or DL, support of network slicing, interworking between DC, NR and E-UTRA, routing of user plane data towards User Plane Functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, etc. As shown in fig. 1D, the gnbs 180a, 180b, 180c may communicate with each other through an Xn interface.

The CN 106 shown in fig. 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF)183a, 183b, and possibly a Data Network (DN)185a, 185 b. While the foregoing elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and/or operated by an entity other than the CN operator.

The AMFs 182a, 182b may be connected to one or more of the gnbs 180a, 180b, 180c via an N2 interface in the RAN 104 and may serve as control nodes. For example, the AMFs 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support of network slicing (e.g., processing of different Protocol Data Unit (PDU) sessions with different requirements), selection of a particular SMF 183a, 183b, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, and so forth. The AMFs 182a, 182b may use network slicing to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service used by the WTRUs 102a, 102b, 102 c. For example, different network slices may be established for different use cases, such as services relying on ultra-high reliable low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for MTC access, and so on. The AMFs 182a, 182b may provide control plane functionality for handover between the RAN 104 and other RANs (not shown) that employ other radio technologies (such as LTE, LTE-A, LTE-a Pro, and/or non-3 GPP access technologies, such as WiFi).

The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 106 via an N11 interface. The SMFs 183a, 183b may also be connected to UPFs 184a, 184b in the CN 106 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure traffic routing through the UPFs 184a, 184 b. The SMFs 183a, 183b may perform other functions such as managing and assigning WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, etc. The PDU session type may be IP-based, non-IP-based, ethernet-based, etc.

The UPFs 184a, 184b may be connected via an N3 interface to one or more of the gnbs 180a, 180b, 180c in the RAN 104, which may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchors, etc.

The CN 106 may facilitate communications with other networks. For example, the CN 106 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Additionally, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers. In one embodiment, WTRUs 102a, 102b, 102c may connect to DNs 185a, 185b through UPFs 184a, 184b via an N3 interface to UPFs 184a, 184b and an N6 interface between UPFs 184a, 184b and local DNs 185a, 185 b.

In view of the corresponding descriptions of fig. 1A-1D and 1A-1D, one or more, or all, of the functions described herein with reference to one or more of the following may be performed by one or more emulation devices (not shown): WTRUs 102a-d, base stations 114a-B, enodebs 160a-c, MME 162, SGW 164, PGW 166, gNB180 a-c, AMFs 182a-B, UPFs 184a-B, SMFs 183a-B, DNs 185a-B, and/or any other device described herein. The emulation device can be one or more devices configured to emulate one or more or all of the functionalities described herein. For example, the emulation device may be used to test other devices and/or simulate network and/or WTRU functions.

The simulated device may be designed to implement one or more tests of other devices in a laboratory environment and/or an operator network environment. For example, the one or more simulated devices may perform one or more or all functions while being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network to test other devices within the communication network. The one or more emulation devices can perform one or more functions or all functions while temporarily implemented/deployed as part of a wired and/or wireless communication network. The simulation device may be directly coupled to another device for testing purposes and/or perform testing using over-the-air wireless communication.

The one or more emulation devices can perform one or more (including all) functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the simulation device may be used in a test scenario in a test laboratory and/or in a non-deployed (e.g., testing) wired and/or wireless communication network to enable testing of one or more components. The one or more simulation devices may be test devices. Direct RF coupling and/or wireless communication via RF circuitry (which may include one or more antennas, for example) may be used by the emulation device to transmit and/or receive data.

In accordance with implementations disclosed herein, WTRUs may be connected via relays and edge WTRUs (e.g., WTRUs connected to a network) with a mesh network that may allow network communications with remote WTRUs that are out of coverage to reach the network. Relay and edge WTRUs relay traffic between a remote WTRU and the network in both Uplink (UL) and Downlink (DL) directions. Each relay WTRU may be provisioned for one or more types of traffic to be supported. The type of traffic may include, for example, Mobility Management (MM) signaling, Session Management (SM) signaling, user plane data, and so on. The edge WTRU is connected to the network (e.g., core network) and is also a relay WTRU that can support all applicable types of traffic.

To enable relaying of traffic (e.g., multi-hop relaying of traffic), a relay WTRU may advertise its relay capabilities (e.g., MM signaling capabilities, SM signaling capabilities, and/or user plane data capabilities), the distance from the network (i.e., the number of hops traversed to reach the network), and a list of remote WTRUs that it may reach by a corresponding distance (i.e., the number of hops to reach one or more remote WTRUs). As used herein, a WTRU (e.g., a remote WTRU, a relay WTRU, and/or an edge relay WTRU) may advertise, transmit, and/or receive information using one or more antennas, such as a transmit antenna, a receive antenna, or a transceiver. Such components may be referred to as transceivers and/or receivers.

Fig. 2 shows a mesh network of relay WTRUs that specifies the number of hops in the UL and DL directions and the supported traffic types for each relay WTRU. As shown in fig. 2, WTRU 1201 is a remote WTRU that may be configured to receive data from one or more of relay WTRUs 202, 203, 204, and/or 205 and may not be able to receive data directly from core network 220. The relay WTRU 2202 may be configured for and may advertise its capabilities, including SM signaling and user plane data, and may also advertise the number of hops to the remote WTRU 1201 (i.e., 1 hop) and the number of hops to the core network 220 (i.e., 3 hops). The relay WTRU 3203 may be configured for and may advertise its capabilities, including MM signaling and user plane data, and may also advertise the number of hops to the remote WTRU 1201 (i.e., 1 hop) and the number of hops to the core network 220 (i.e., 2 hops). The relay WTRU 4204 may be configured for and may advertise its capabilities, including SM signaling, and may also advertise the number of hops to the remote WTRU 1201 (i.e., 2 hops) and the number of hops to the core network 220 (i.e., 2 hops). The edge relay WTRU5205 may be configured for and may advertise its capabilities, including SM signaling, MM signaling, and user plane data, and may also advertise the number of hops (i.e., 1 hop) to the core network 220. Figure 2 also shows that a given capability-specific transmission may traverse the corresponding path through each relay WTRU, depending on the capability. For example, UL user plane data transmissions from WTRU2 to the core network 220 may traverse from WTRU2 to WTRU3 to WTRU5 before they reach the core network 220 via the ran (gnb) 210.

As shown in fig. 2, one or more relay WTRUs may advertise their capabilities, the number of hops to one or more remote WTRUs and/or the network, and a list of remote WTRUs that they may reach by transmitting a wireless signal at a predetermined time, upon receipt of an advertisement request at each respective WTRU, or based on one or more other criteria.

Additionally, it should be noted that a given relay WTRU may support more than one type of traffic. The number of hops advertised by a given relay may correspond to the number of hops to a remote WTRU or network using any type of traffic supported by the given relay WTRU.

One-to-one communication such as proximity services (ProSe) may be established between a relay WTRU, a remote WTRU, and an edge WTRU for traffic forwarding (not shown). One-to-one communication may be used to transport different types of traffic (e.g., MM signaling, SM signaling, user plane data, etc.).

A remote WTRU (e.g., remote WTRU 1201 of fig. 2) and an edge WTRU (e.g., WTRU5205 of fig. 2) insert packets (i.e., data) into the mesh network of the relay WTRU. Each packet may include a remote WTRU ID, allowed hops, direction (i.e., UL or DL), and traffic type (e.g., MM signaling, SM signaling, or user plane data). The remote WTRU identifier is determined based on the traffic type. Depending on the implementation, the remote WTRU ID, the allowed hop count, the direction, and/or the traffic type may be stored in a packet header of each of the corresponding packets inserted into the mesh by the remote WTRU and/or the edge WTRU.

The relay WTRU may receive a packet from a remote WTRU, an edge WTRU, or another relay WTRU to be relayed based on capabilities of the relay WTRU (e.g., MM signaling, SM signaling, or user plane data). The relay WTRU may check the allowed hop count, subtract one hop, and update the packet (e.g., packet header) with the new resulting hop count (e.g., new allowed hop count). The relay WTRU may use information contained in the packet to determine whether the packet should be forwarded in the UL direction or the DL direction. For example, source information and/or destination information may be included in the packet, and the relay WTRU may use this information to determine the direction of packet transmission. The relay WTRU may search its relay capability table for the edge WTRU to forward data of the received UL packet and search the remote WTRU for DL packets.

The relay WTRU may determine the subsequent hops for a given packet by referring to its relay capability table. If the relay WTRU is not directly connected to a remote WTRU (for DL) or an edge WTRU (for UL), the relay WTRU may consider the next hop WTRU's advertised capabilities (e.g., supported traffic types) for next hop selection. Once the next hop is identified, the relay WTRU may forward the packet to the selected WTRU. Notably, if the number of allowed hops is greater than one, the relay WTRU may forward the packet to the next hop as determined based on the relay capability table. The relay WTRU may drop the packet if the allowed number of hops is 1 or 0.

Each WTRU participating in the mesh network of WTRUs may be pre-configured with a specific role (e.g., relay or edge) for traffic handling, as well as the allowed traffic types that it is configured to handle. The WTRU may be configured to handle one or more of the following traffic types: MM signaling, SM signaling, and/or user plane data. One or more values may be configured on each WTRU.

MM signaling traffic types may be used to identify control plane traffic related to mobility management, which is typically transported through core access and mobility management functions (AMFs) in 5G networks (e.g., recovery messages, service requests, tracking area updates, and generic uplink and downlink NAS messages). For example, the preset traffic sent by the application server to the WTRU may be transmitted through the 5G network and the AMF. In this example, the type of the preset traffic is MM signaling. Edge WTRUs typically may use signaling radio bearers to send/receive MM signaling traffic to/from the CN.

The SM signaling traffic type may be used to identify control plane traffic related to session management, which is typically handled by SMFs (e.g., PDU session setup, modification, release messages, and QoS modification procedures) in 5G networks. For example, a WTRU seeking to exchange traffic (e.g., IP traffic) with an external entity needs to establish a PDU session and obtain an IP address. The type of traffic associated with the establishment and maintenance of the session is SM signaling. Edge WTRUs typically use signaling radio bearers to send/receive this type of traffic to/from the CN.

The user plane traffic type is used to identify traffic (e.g., exchanged between an application running on the WTRU and an application server). The traffic is typically IP traffic, but may also be non-IP traffic or ethernet traffic. For example, a mail application running on the WTRU exchanges packets with a mail server to download email onto the WTRU. In this case, the type of the preset traffic is the user plane. Edge WTRUs typically use data radio bearers to send and receive this type of traffic to and from the CN. User traffic in the UL may originate from different applications running on the remote WTRU, while in the DL and Application Server (AS), another WTRU may send user plane traffic. The user plane traffic may be small infrequent packets, application level control signaling, or continuous stream data packets.

The traffic type may also be preset according to an application type or ID (e.g., a mapping table between application IDs and traffic types to be preset). For example, a cellular internet of things (CloT) application may generate user plane traffic that should be sent over the control plane interface (i.e., the traffic type is MM signaling or SM signaling) because packets are typically small and very few packets are sent infrequently. Another type of application that generates user plane traffic with large packet sizes (e.g., a streaming application) should be sent over the username interface (i.e., the traffic type is user plane data). QoS parameters (e.g., maximum delay, etc.) may also be configured according to the traffic type.

The maximum number of hops allowed for each traffic type may be preset. This value may be added to traffic forwarded into the mesh network (e.g., via a packet header). Additionally or alternatively, a mapping between QoS parameters and the maximum number of hops a packet should be transmitted in both UL and DL directions may be preset. For example, a remote WTRU introducing traffic in the mesh network may set the maximum number of hops allowed into the packet based on, for example, the traffic type, and then forward the packet to the next relay WTRU. The same behavior may apply to edge WTRUs, which may also introduce traffic into the mesh network.

The remote WTRU may be a WTRU that generates traffic to be sent to the network via the WTRU mesh to the network.

The WTRU may be configured as a relay and generate data to be sent to the network. Thus, the WTRU may act as a relay for the remote WTRU and may be the remote WTRU itself (i.e., use the relay WTRU to forward its traffic to the network).

Each relay or edge WTRU advertises (e.g., broadcasts) its capabilities to other WTRUs, as well as its hop count in the UL direction from the network for each traffic type. Supported application IDs/types may also be advertised. In addition, each relay WTRU advertises, for each traffic type (e.g., DL direction), a list of remote WTRUs that the relay WTRU may reach over the corresponding hop count. The capabilities include the traffic type and may include the role of the WTRU (i.e., relay and/or edge). The number of hops away from the network represents the number of relays traversed to reach the network, and the number of hops to a remote WTRU represents the number of relays traversed to reach a given remote WTRU. It should be understood that the mesh network may include multiple remote WTRUs.

The remote WTRU may be identified using a unique identifier (e.g., L2 ID, IP address, subscription association identifier (SUCI), etc.) that is specified and readable in all packets relayed in the mesh network. Each WTRU (e.g., a relay WTRU and a remote WTRU) may learn the number of hops that it is located away from the network based on the advertisements of the relay WTRU and the edge WTRU.

Figure 3 is an exemplary diagram illustrating all or a subset of relay WTRUs establishing a local relay capability table based on relay WTRU advertisements. As shown in fig. 3, WTRUs 201, 202, 203, 204, and 205 may be part of a mesh network, where WTRU 201 is a remote WTRU and WTRU 205 is an edge relay connected to a core network 220. WTRUs 202, 203, and 204 are relay WTRUs. At 301, the relay may advertise its capabilities, and at 302, each relay WTRU may update its local relay capability table in at least the UL direction.

At 304, the remote WTRU 1201 transmits a packet that includes a remote WTRU ID corresponding to the remote WTRU 1201, indicates the direction of transmission (i.e., UL), indicates the type of traffic (i.e., SM signaling), and the number of hops (i.e., 3 hops). At 306, the WTRU 2202 advertises the remote WTRU 1201 for the SM signaling traffic type 1 hop away from the WTRU 2202. At 308a, the relay capability table of WTRU 2202 is updated in the DL direction, and at 308b, the relay capability table of WTRU 4204 is updated in the DL direction. At 310a, the WTRU 2202 selects the WTRU 4204 as the next hop based on the transmission direction (i.e., UL), the traffic type (i.e., SM signaling), and the number of hops available based on the packet transmitted at 304 (i.e., 3 hops). At 312, the number of hops (i.e., 3 hops) may be reduced by 1 (i.e., resulting in a total of 2 hops) to account for the hops from relay WTRU 1201 to relay WTRU 2202. Further, at 310b, the relay WTRU 4204 may advertise that the remote WTRU 1201 is 2 hops away for SM signaling, and at 308c, the edge WTRU5205 updates its relay capability in the DL direction.

At 314, packets updated to include up to 2 hops are transmitted to the WTRU 4204, and at 316, the WTRU 4204 selects the edge WTRU5205 as the next hop based on the transmission direction (i.e., UL), traffic type (i.e., SM signaling), and the number of hops available based on the packets transmitted at 314 (i.e., 2 hops). At 318, the number of hops (i.e., 2 hops) may be reduced by 1 (i.e., resulting in a total of 1 hop) to account for the hops from relay WTRU 2202 to relay WTRU 4204. At 320, the packet updated to include the maximum 1 hop is transmitted to the edge WTRU5205 and at 322, the edge WTRU5205 transmits the packet to the core network 220 via SM signaling to complete the uplink transmission of the packet from the remote WTRU 1201 to the core network 220.

Further, at 324, the core network 220 provides a packet via SM signaling, the packet being addressed for the remote WTRU 1201 (e.g., via the remote WTRU ID). At 324, the edge WTRU5205 is provided with the packet with the preset. At 326, the edge WTRU5205 transmits a packet including a remote WTRU ID corresponding to the remote WTRU 1201, indicating the direction of transmission (i.e., DL), indicating the type of traffic (i.e., SM signaling), and the number of hops (i.e., 3 hops). At 328, the number of hops (i.e., 3 hops) is reduced by 1 to account for the transmission 326 from the edge WTRU5205 to the relay WTRU 4204. At 330, the relay WTRU 4204 transmits a packet including a remote WTRU ID corresponding to the remote WTRU 1201, indicating the direction of transmission (i.e., DL), indicating the type of traffic (i.e., SM signaling), and the number of hops to the relay WTRU 2202 (i.e., 2 hops). At 332, the number of hops (i.e., 2 hops) is reduced by 1 to account for the transmission 330 from the relay WTRU 4204 to the relay WTRU 2202. At 334, the relay WTRU 2202 transmits a packet that includes a remote WTRU ID corresponding to the remote WTRU 1201, indicates a direction of transmission (i.e., DL), indicates a traffic type (i.e., SM signaling), and a number of hops to the remote WTRU 1201 to complete the DL transmission (i.e., 1 hop).

Fig. 4 is a diagram illustrating an exemplary announcement of the UL direction and includes an exemplary relay capability table for remote WTRU 1201 and relay WTRU 3203. As shown in fig. 4, each WTRU (relay, remote, edge, etc.) determines its location from the number of hops of the network by receiving an advertisement from each other WTRU. As shown, the edge WTRU5205 and the relay WTRU each advertise their capabilities and hop count in the UL direction. The advertisement 205a from the edge WTRU5205 indicates to the edge WTRU5205 that the network is 1 hop away for SM signaling, MM signaling, and user plane data. The advertisement 202a from the relay WTRU 2202 indicates that the relay WTRU 2202 is 3 hops away from the network for SM signaling and user plane. The announcement 203a from the relay WTRU 3203 indicates that the relay WTRU 3203 is 2 hops away from the network for MM signaling and user plane data. The announcement 204a from the relay WTRU 4204 indicates that the relay WTRU 4204 is 2 hops away from the network for SM signaling.

In addition, for example, as shown in fig. 4, the relay WTRU 3203 generates the relay capability table 203b based on advertisements received from the edge WTRU5205, the relay WTRU 4204, and the relay WTRU 2202. The relay capability table 203b includes hops to the network for each given relay WTRU that provides an advertisement received by WTRU 3203. As shown, the relay capability table 203b includes the capabilities of the edge WTRU5205 for SM, MM and user plane data and 1 hop to the network, the capabilities of the relay WTRU4 for SM signaling and 2 hop to the network, and the capabilities of the relay WTRU2 for SM signaling and user plane data and 3 hop to the network. Further, the remote WTRU 1201 generates the relay capability table 201b based on the advertisements provided from the relay WTRU 2202 and the relay WTRU 3203. As shown, the relay capability table 201b includes the capability to relay MM signaling and user plane data of WTRU 3203 and 2 hops to the network, and the capability to relay SM signaling and user plane data of WTRU2 and 3 hops to the network.

Although relay capability tables for remote WTRU 1201 and relay WTRU 3203 are shown, it should be understood that each relay WTRU may generate a relay capability table for reaching the network. Thus, traffic from the WTRU1 may be sent to the network based on each generated relay capability table.

Similarly, traffic in the DL direction (i.e., towards the remote WTRU 1201) also needs to be relayed in the WTRU's mesh network, indicating that the remote WTRU1 may arrive via the mesh network. Such a DL relay capability table may also include the type of traffic and how many hops packets travel from a given relay WTRU to reach the remote WTRU 1201.

Fig. 5 is a diagram illustrating an exemplary relay WTRU advertisement and an exemplary DL relay capability table for the DL direction. In this example, the relay WTRU 2202, relay WTRU 3203, and relay WTRU 4204 advertise the number of hops to the remote WTRU 1201 and their supported traffic types. The edge WTRU5205 and other relay WTRUs receiving this information update their DL relay capability tables to identify to which next hop or relay WTRU the traffic of the remote WTRU1 should be sent based on the traffic type. A relay WTRU receiving a DL advertisement transmits an advertisement that indicates the path to the remote WTRU 1201 by the number of hops plus one for its supported traffic type in addition to updating its local DL relay capability table. For example, WTRU 4204 receives a possible advertisement from relay WTRU 2202 and relay WTRU 3203. The relay WTRU 4204 updates its relay capability table and sends an advertisement indicating that the remote WTRU1 for SM signaling may be reached over a two-hop distance.

As shown in fig. 5, the advertisement 202c from the relay WTRU 2202 indicates that the relay WTRU 2202 is 1 hop away from the remote WTRU 1201 for SM and user plane data. The announcement 203c from the relay WTRU 3203 indicates that the relay WTRU 3203 is 1 hop away from the remote WTRU 1201 for MM and user plane signaling. The announcement 204c from the relay WTRU 4204 instructs the relay WTRU 4204 to be 2 hops away from the remote WTRU 1201 for SM signaling.

Additionally, for example, as shown in fig. 5, the relay WTRU 3203 updates its relay capability table 203d to indicate that it is directly connected to the remote WTRU 1201. The relay capability table 201b of the remote WTRU 1201 may remain the same because the DL capabilities of the mesh network may not necessarily be stored by the remote WTRU 1201. The edge WTRU5205 updates its relay capability table to include the fastest transmissions to the remote WTRU 1201 for each traffic type (i.e., MM signaling to be transmitted via the relay WTRU 3203, SM signaling to be transmitted via the relay WTRU 4204, and user-plane data to be transmitted to the relay WTRU 3203) in addition to its UL capabilities (i.e., all UL traffic is transmitted to the core network 220 via the ran (gnb) 210).

Since all WTRUs in a given mesh network do not necessarily handle forwarding of all traffic types, each WTRU advertises the number of hops per traffic type for the DL and UL directions. For example, in some embodiments, the relay WTRU may forward MM signaling towards the remote WTRU via a path with two hops, while SM signaling may be sent via another path with three hops.

According to one embodiment, the relay capability table may include traffic type, hop count, relay identifier, relay role, QoS parameters, load, etc. for the UL direction. The relay capability table may include remote WTRU identifiers for the DL direction, traffic type, hop count, relay identifier, role, QoS parameters, load, etc. QoS parameter values are further disclosed herein. The load may be a value received on the advertisement of a particular relay WTRU. For example, referring to fig. 4 and 5, the relay capability table for the UL direction for the relay WTRU 3203 may be [ MM signaling, 1 hop, relay WTRU5, edge, etc. ] and [ user plane, 1 hop, WTRU5, edge, etc. ]. The relay capability table for the DL direction by relay WTRU 3203 may be [ remote WTRU1, MM signaling, remote (i.e., directly connected to a remote WTRU that is away from the mesh network) ]. The relay capability table for the UL direction by the edge WTRU5205 may be [ the edge WTRU forwards all traffic towards the network (out of the mesh network) ]. The relay capability table for the DL direction for the edge WTRU5205 may be [ remote WTRU1, MM signaling, 1 hop, WTRU3, relay, etc ], [ remote WTRU1, SM signaling, 2 hop, WTRU4, relay, etc. ] and [ remote WTRU1, user plane, 1 hop, WTRU3, relay, etc. ]. The relay WTRU 4204 relay capability table for the UL direction may be [ SM signaling, 1 hop, WTRU5, edge (i.e., directly connected to edge WTRU), etc. ]. The relay WTRU 4204 relay capability table for DL direction may be [ remote WTRU1, SM signaling, 1 hop, WTRU2, relay, etc. ].

The mesh network of the relay WTRU may be dynamic (i.e., the WTRU may arrive and leave the network). Thus, advertisements from relay WTRUs may be sent frequently and the local relay capability table for each recipient WTRU may be updated accordingly. The selection of the path or next relay WTRU may be on a per packet basis based on information from a given relay capability table when a packet needs to be inserted or relayed into the mesh network of the WTRU system.

A one-to-one connection (e.g., ProSe) may be established between a remote WTRU (e.g., remote WTRU 1201 of fig. 2) and a relay WTRU, providing access to the mesh network of WTRUs, and between relay WTRUs in the path up to an edge WTRU (e.g., edge WTRU5205 of fig. 2).

For example, in some embodiments, a remote WTRU (e.g., remote WTRU 1201 of fig. 2) may establish communication with a remote peer entity. Thus, a session (e.g., a PDU session) may need to be established with the network and traffic may need to be sent by a remote WTRU (e.g., remote WTRU 1201 of fig. 2). Thus, the remote WTRU may refer to its relay capability table and select a WTRU to relay its traffic to the network based on traffic type, hop count, QoS, etc. Different WTRUs may be selected to carry different traffic types (e.g., depending on the capabilities of each relay WTRU). Thus, multiple one-to-one communications may need to be established by the remote WTRU.

Once the next hop is selected, a one-to-one communication is established if there is no one-to-one communication between the two corresponding WTRUs. This one-to-one communication (e.g., PC5 unicast) from the remote WTRU to the relay WTRU represents the first segment of the relay path to the network. The selected relay WTRU advertises its capabilities related to the remote WTRU and/or the network including, but not limited to, hop count, traffic type, QoS, etc.

The selected relay WTRU repeats the same or similar logic as the remote WTRU (e.g., it applies the traffic type to the established communication and uses its local relay capability table to determine the next relay WTRU in the path in the UL direction). Once the next relay WTRU is identified, a one-to-one communication is established with the identified relay WTRU (if not). The process repeats on each relay WTRU until communication with the edge WTRU is established.

One-to-one communication between two relay WTRUs, or between a relay WTRU and an edge WTRU, may be used to send traffic of different data types from different WTRUs.

Each relay WTRU that receives the advertisement related to the remote WTRU updates its local relay capability table and advertises its ability to reach the remote WTRU and/or the network, adjusted hop count, types of traffic it supports, QoS, etc. Each WTRU (relay and edge) identifies the number of hops it is located away from the remote WTRU by listening to the relay WTRU's advertisement and incrementing the number of hops in the received advertisement by one.

According to one embodiment, the edge WTRU may not advertise DL information because the edge WTRU may be used for relaying when forwarding traffic in the UL direction. The edge WTRU may forward data received from either of its one-to-one communications (i.e., any relay WTRU) to the network.

When a remote WTRU's DL traffic is received at an edge WTRU, it references its relay capability table and selects a relay WTRU that may reach the remote WTRU based on traffic type, hop count, QoS, etc. This process is repeated by each relay WTRU receiving the remote WTRU's data until it reaches the relay WTRU that is directly connected to the remote WTRU. And then forward the data to the remote WTRU.

As shown in fig. 6, which refers to the mesh networks of fig. 4 and 5, at 610, all relay WTRUs advertise their capabilities (e.g., MM signaling relay, SM signaling relay, user plane relay), and a local relay capability table for the UL direction is established on each WTRU (including remote WTRUs and relay WTRUs) based on the received advertisements, as shown in fig. 4. The edge WTRU5205 connects directly to the network (e.g., via the gNB). Notably, at 610, when all relay WTRUs advertise their capabilities, the remote WTRU 1201 generates or updates its relay capability table in the UL direction to include MM signaling with 2 hops via the relay WTRU 3203, SM signaling with 3 hops via the relay WTRU 2202, and a user plane with 2 hops via the relay WTRU 3203. The relay WTRU 2202 generates or updates its relay capability table in the UL direction to include SM signaling with 2 hops via the relay WTRU 4204 and user plane data with 2 hops via the relay WTRU 3203. The relay WTRU 3203 generates or updates its relay capability table in the UL direction to include MM signaling with 1 hop via the edge WTRU5205 and user plane with 1 hop via the edge WTRU 5205. The relay WTRU 4204 generates or updates its relay capability table in the UL direction to include SM signaling with 1 hop via the edge WTRU 5205. The relay WTRU5205 generates or updates its relay capability table in the UL direction for direct transmission to the core network 220.

At 620, the remote WTRU 1201 may have MM signaling traffic it needs to transmit. The remote WTRU 1201 may select a path for MM signaling traffic based on its local relay capability table updated at 610 a. According to the example provided in fig. 6, a relay WTRU 3203 is selected for MM signaling traffic. If there is no one-to-one connection between the remote WTRU 1201 and the relay WTRU 3203, a one-to-one connection establishment is triggered at 620 a. If there is a one-to-one connection between remote WTRU 1201 and relay WTRU 3203, the one-to-one connection is used for transmission from remote WTRU 1201 to relay WTRU 3203 at 620 a.

According to an embodiment, the relay WTRU 3203 may determine that a one-to-one connection towards the edge WTRU5205 is required. If there is no one-to-one connection at a given point, at 620f, the relay WTRU 3203 may trigger establishment of a one-to-one connection with the edge WTRU5205 based on information from its local relay capability table. The DL path towards WTRU1 may be established from edge WTRU5205 to relay WTRU 3203 to remote WTRU 1201 using the same mechanism (i.e., using the relay capability table and establishing a one-to-one communication). MM signaling traffic may be exchanged in the UL and DL directions based on the UL and DL paths.

As shown in fig. 6, remote WTRU 1201 may send MM signaling traffic to relay WTRU 3203 at 620 a. MM signaling traffic includes at least one packet including a number of allowed hops, a direction (UL in this example), a signaling identifier of the remote WTRU 1201 (e.g., SUCI, 5G-GUTI, or a Permanent Equipment Identifier (PEI) or another ProSe ID), and may include other parameters (e.g., QoS parameters). The relay WTRU 3203 receives the packet, extracts the identifier of the remote WTRU 1201 associated with the signaling traffic, and advertises at 620c that it may arrive at the remote WTRU 1201 in one hop for MM signaling traffic type. The edge WTRU5205 receives the advertisement and updates its relay capability table in the DL direction at 620 e. The relay WTRU 3203 checks whether the received packet is for the DL direction or the UL direction based on information contained in the packet (e.g., packet header) and the number of allowed hops. Based on the packet received at the relay WTRU 3203, one hop is subtracted from the allowed hop count and the packet is updated with the new value of the hop count. Considering that the transmission is a UL packet, the relay WTRU 3203 searches the edge WTRU5205 at 620d to forward the received packet. Note that if the transmission includes DL packets, the relay WTRU 3203 will search for the remote WTRU 1201. At 620f, a one-to-one connection is established between the relay WTRU3 to the edge WTRU5205 (if there is no one-to-one connection). MM signaling traffic may be exchanged in both directions (UL and DL) at 620 g.

As shown in fig. 6, remote WTRU 1201 may send SM signaling traffic at 630. As shown in fig. 6, the remote WTRU 1201 may select a path for SM signaling traffic based on its local relay capability table at 630b (i.e., it selects the relay WTRU 2202 as the relay WTRU). One-to-one communication between the remote WTRU 1201 and the relay WTRU 2202 is established at 630a, one-to-one communication between the relay WTRU 22020 and the relay WTRU 4204 is established at 630g, and one-to-one communication between the relay WTRU 4204 and the edge WTRU5205 is established at 630 j. The relay WTRU 2202 receives the packet, extracts the identifier of the remote WTRU 1201 associated with the signaling traffic, and advertises at 630c that it can reach the remote WTRU 1201 for SM signaling and hop count (i.e., 1). The relay WTRU 4204 receives the advertisement from the relay WTRU 2202 and advertises at 630f that it may arrive at the remote WTRU 1201 for SM signaling, where the hop count advertised by the relay WTRU 2202 is incremented by one. SM signaling traffic may be exchanged in both directions (UL and DL) based on the updated relay capability table, updated based on the advertisement.

Remote WTRU 1201 sends SM signaling traffic to relay WTRU 2202 at 630 a. The grouping includes: number of allowed hops (i.e., 3 hops in this example), direction (i.e., UL in this example), and signaling identifier of the remote WTRU 1201. The packet may include other parameters (e.g., QoS parameters). The relay WTRU 2202 determines the packet direction to determine whether the transmission is in the DL direction or the UL direction (based on the information contained in the packet). The relay WTRU 2202 also determines the number of allowed hops and subtracts one hop (i.e., resulting in 2 hops in this example) based on the packet information. The relay WTRU2 searches the edge WTRU5205 to forward the received data because it is a UL packet. WTRU2 searches for remote WTRU1 (if it is a DL packet).

Since the relay WTRU 2202 is not connected to the edge WTRU5205, it uses its local relay capability table at 630b to determine the next hop (i.e., relay WTRU 4204 at 630 d) based on the type of data received (i.e., MM signaling, SM signaling, or user plane data) and broadcasts the capabilities of the relay WTRU at 630 c.

If the hop count is greater than one, the relay WTRU 2202 forwards the data to the next hop at 630g, as shown in figure 6. Otherwise, the WTRU 2202 discards the packet.

The relay WTRU 4204 receives the packet and repeats the same logic as the relay WTRU 2202 to find the edge WTRU5205 at 630i by referring to its local relay capability table and the direction and data type of the packet. The relay WTRU 4204 also checks the allowed hop count, subtracts one, and updates the packet before forwarding it to the edge WTRU5205 at 630 k.

At 640, the remote WTRU 1201 may send user plane traffic using the one-to-one connection that has been established at 620a for MM signaling based on the relay capability information. The grouping may include: number of allowed hops (i.e., 2 hops in this case), direction (i.e., UL in this case), user plane identifier (e.g., IP address) of the remote WTRU 1201, and may include other parameters (e.g., QoS parameters). Relay WTRU 3203 may receive the packet, extract the identifier of remote WTRU 1201 associated with the user plane traffic, update its relay capability table at 640b, and advertise at 640c that it may arrive at remote WTRU1 for the user plane traffic type and that it is in one hop. The edge WTRU5205 may receive the advertisement at 640d and update its relay capability table in the DL direction. User plane traffic may be switched in both directions (UL and DL) at 640e and 640 f.

The traffic path (e.g., next relay WTRU selection) is based on the number of hops to the network or to the remote WTRU and also based on the traffic type. The application ID/type may also be considered when determining the traffic path. The shortest path may be selected based on these factors. In addition, other information may be considered. For example, the load or QoS (e.g., delay) on the WTRU of traffic forwarding may be delayed. Thus, based on one or more factors, the selection of a path with a higher hop count may end.

To determine the next hop relay, the potential next hop relay needs to support a given type of traffic to be transmitted. Similarly, the type of traffic requires support by the WTRU chain for the entire traffic path as indicated by the number of hops advertised for a given traffic type.

Thus, depending on the traffic direction (i.e., UL or DL), a given WTRU seeking to transmit traffic utilizes its relay capability table for either a remote WTRU or an edge WTRU. If the relay WTRU is not connected to an edge WTRU or a remote WTRU, it selects the next relay WTRU to transmit the packet. The path selection (e.g., next relay WTRU selection) is determined based on the capabilities of the selected relay WTRU, its arrival edge WTRU (in UL direction), or the remote WTRU (in DL direction) supporting the traffic type of the packet, and the number of hops advertised by the selected next relay WTRU is less than or equal to the allowed number of hops specified in the packet.

Referring to fig. 5, an edge WTRU5205 receives traffic (packets) from the network in the DL direction. The edge WTRU5205 searches its relay capability table for the remote WTRU 1201 identifier for the next relay WTRU selection. The remote WTRU 1201 identifier is specified in the received packet (e.g., packet header). If there are multiple paths towards the identified remote WTRU 1201, the next relay WTRU selection is done as specified herein, i.e., considering traffic type, hop count, load, QoS, etc.

For example, the relay WTRU 3203 may receive traffic in the UL direction. The relay WTRU 3203 may then search its relay capability table for the edge WTRU 5205. If no entry specifies a direct connection with the edge WTRU5205, then selection is performed as specified above (i.e., relay WTRU based path).

The relay WTRU may receive traffic data to be forwarded (i.e., traffic data corresponding to its capabilities) via a one-to-one communication. One-to-one communication (e.g., ProSe) is established between relay WTRUs for traffic forwarding. The received packet may include information needed by the relay WTRU to determine where to forward the packet. For example, the packet may include: allowed number of hops to reach the network or remote WTRU; traffic type (MM signaling, SM signaling, or user plane data), forwarding direction (UL or DL); and a remote WTRU identifier.

A given relay WTRU may check whether a given packet is for the UL or DL direction and may search for an edge WTRU if it is a UL packet and a remote WTRU if it is a DL packet.

If a given relay WTRU is not connected to (i.e., one hop away from) an edge WTRU or a remote WTRU, the relay WTRU searches its relay capability table for the next relay WTRU to forward the received data. The next relay WTRU is determined based on the traffic type of the packet, the broadcast capability of the next hop relay WTRU, the forwarding direction, and the hop count specified in the packet (as compared to the hop associated with the next hop relay WTRU).

The relay WTRU checks the allowed hop count, subtracts one hop, and updates the packet with the new hop count before forwarding the packet to the selected relay WTRU (i.e., the next hop). For the UL and DL directions, the relay WTRU forwards the data to the next hop if the number of hops is greater than one. Otherwise, the relay WTRU discards the packet.

An edge WTRU (in the DL direction) and a remote WTRU (in the UL direction) insert packets into the WTRU's mesh network. The packet is modified to include the required fields for forwarding, e.g., allowed hop count, traffic type, direction, remote WTRU identifier, time, etc.

The remote WTRU inserts its identifier based on the traffic type. For example, the user plane traffic type may be identified using an IP address, while the signaling may be identified using sui. An edge WTRU that receives traffic for the DL direction (i.e., from the network) also inserts a remote WTRU identifier based on the traffic type. The edge WTRU determines a remote WTRU identifier based on information included in the packet. In some embodiments, the remote WTRU identifier is a destination IP address when user plane traffic is received and the remote WTRU identifier is a SUCI when SM or MM signaling is received.

The maximum number of hops is preset on the WTRU but may be modified by each WTRU based on measured or observed values. According to one embodiment, a packet introduced into a mesh network may contain an allowed time. Thus, the edge WTRU and the last relay WTRU in the mesh network may apply the allowed time to measure the time it takes for the packet to traverse the mesh network. The WTRU may then map the traffic type, QoS parameters, and observed forwarding time to a maximum number of hops. A relay WTRU or edge WTRU may increase (if the traversal is fast) or decrease (if the traversal is long) the maximum number of hops of packets inserted in the mesh network. Alternatively, if the transfer time is too long, the WTRU may select another relay WTRU as the next hop. For example, instead of reducing the number of hops, the WTRU may test whether the traversal time is better.

Figure 7A illustrates a flow chart 700 for DL transmission of packets from a core network to a remote WTRU according to the subject matter disclosed herein. The remote WTRU may be out of coverage from the core network such that transmissions from the core network cannot be received at the remote WTRU without multiple hop relaying through multiple relay WTRUs. At 710, each of a plurality of relay WTRUs in a mesh network may advertise its relay capability and the number of hops to reach a remote WTRU. For example, as shown in fig. 5, each relay WTRU 202 and 205 may advertise its relay capabilities (e.g., MM signaling, SM signaling, user-plane data, etc.) and the number of hops a given relay WTRU is away from the remote WTRU (e.g., relay WTRU 3203 may advertise its MM and user-plane data capabilities and its 1 hop away from the remote WTRU 1201).

At 712 of the flow diagram 700, an edge WTRU (e.g., the edge WTRU5205 of fig. 5) connected to a core network (e.g., the core network 220 of fig. 5) may update its edge WTRU relay capability table, and each of a plurality of relay WTRUs (e.g., the relay WTRU 202 and 205 of fig. 5) may update its corresponding relay WTRU relay capability table. The updating of the edge WTRU relay capability table and the relay WTRU relay capability table may be based on the advertisement made at 710 such that each of the plurality of relay WTRUs may update its respective relay capability table based on the advertisement made by each other relay WTRU of the plurality of relay WTRUs in the mesh network.

At 714 of flow diagram 700, a packet including a payload may be received at an edge WTRU. The packet may be received from a core network and may have a traffic type associated with the packet (e.g., MM signaling, SM signaling, user plane data, etc.). Additionally, the packet may include a maximum number of hops, which may be determined based on attributes of the packet such as priority, QoS requirements, associated time periods, and the like. The packet may also include a remote WTRU identifier that identifies the intended recipient of the payload.

At 716 of flow diagram 700, the selected relay WTRU may be selected from a plurality of relay WTRUs. The selected relay WTRU may be selected based on: the signaling capabilities of the selected WTRU matching the traffic type of the packet received at 714, the maximum number of hops associated with the packet received at 714, and an edge WTRU relay capability table (e.g., the edge WTRU relay capability table may include information about the selected relay WTRU corresponding to its signaling capabilities and its number of hops away from the remote WTRU). Notably, the selected relay WTRU may be selected based on the number of hops to reach the remote WTRU from the selected relay WTRU being less than the first updated number of hops, as disclosed at step 718.

At 718 of flowchart 700, a first update packet may be generated based on the packet received at 714. The first update packet may include a payload from the packet received at 714 and may have a direction, a traffic type, and an update hop count that is one less than the maximum hop count. Notably, the first update packet may have an update header with a modified maximum hop count (i.e., modified to a first hop count that is one less than the maximum hop count). For clarity, the first number of hops may combine the hops from the edge WTRU to the selected relay WTRU. The first update packet generated at 718 may be generated at the edge WTRU and/or the selected relay WTRU such that it may be generated before and/or after transmission by the edge WTRU.

At 720 of flow diagram 700, a first update packet may be transmitted by the edge WTRU. The first update packet may be received by the selected relay WTRU via a connection, such as a one-to-one connection between the edge WTRU and the selected relay WTRU. At 722 of flowchart 700, a second update packet may be generated. The second update packet may include the payload, direction, and traffic type from the packet received at 714, but may have an update hop count that is one less than the first hop count. Notably, the second update packet may have an update header with a modified maximum number of hops (i.e., modified to a second number of hops that is one less than the first number of hops). For clarity, the second number of hops may combine hops from the selected relay WTRU to a subsequently selected relay WTRU. The second update packet generated at 722 may be generated at the selected relay WTRU and/or subsequently selected relay WTRUs such that it may be generated before and/or after transmission by the selected relay WTRU.

At 724 of flowchart 700, a second update packet may be transmitted in a similar manner as the transmission of the first update packet to the selected relay WTRU at 720 based on the traffic type, the second update hop count, and/or the selected WTRU relay capability table. If one or more additional hops are needed, a second update packet may be received by subsequent relay WTRUs such that each additional hop may generate an update packet that includes a payload from the packet received at 714. At 726 of flowchart 700, a payload may be received at the remote WTRU from the packet received at 714, completing the DL transmission from the core network to the remote WTRU.

Figure 7B illustrates a flow chart 730 for UL transmission of packets from a remote WTRU to a core network according to the subject matter disclosed herein. The remote WTRU may be out of coverage from the core network such that UL transmissions from the remote WTRU may not be received at the core network without multiple hop relaying through multiple relay WTRUs. At 740, each of a plurality of relay WTRUs in the mesh network may advertise its relay capability and the number of hops to reach the core network. For example, as shown in fig. 4, each relay WTRU 202 and 205 may advertise its relay capabilities (e.g., MM signaling, SM signaling, user-plane data, etc.) as well as the number of hops a given relay WTRU is away from the remote WTRU (e.g., relay WTRU 3203 may advertise its MM signaling and user-plane data capabilities as well as its 2 hops away from the core network).

At 742 of flow diagram 730, the remote WTRU (e.g., remote WTRU 1201 of fig. 4) may update its edge WTRU relay capability table and each of the plurality of relay WTRUs (e.g., relay WTRU 202 of fig. 4 and 205) may update its corresponding relay WTRU relay capability table. The updating of the remote WTRU relay capability table and the relay WTRU relay capability table may be based on the advertisement made at 740 such that the remote WTRU and each of the plurality of relay WTRUs may update their respective relay capability tables based on the advertisement made by each other relay WTRU of the plurality of relay WTRUs in the mesh network.

At 744 of flow diagram 730, a packet including a payload may be generated by a remote WTRU. The packet may have a traffic type (e.g., MM signaling, SM signaling, user plane data, etc.) associated with the packet and the direction. Additionally, the packet may include a maximum number of hops, which may be determined based on attributes of the packet such as priority, QoS requirements, associated time periods, and the like.

At 746 of flow diagram 730, the selected relay WTRU may be selected from a plurality of relay WTRUs. The selected relay WTRU may be selected based on: the signaling capabilities of the selected WTRU matching the traffic type of the packet generated at 744, the maximum number of hops associated with the packet received at 744, and a remote WTRU relay capability table (e.g., the remote WTRU relay capability table may include information about the selected relay WTRU corresponding to its signaling capabilities and its number of hops away from the core network). Notably, as disclosed herein, the selected relay WTRU may be selected based on the number of hops to reach the core network from the selected relay WTRU being less than the first updated number of hops.

At 748 of flow diagram 730, the packet generated at 744 may be transmitted by the remote WTRU. The packet may be received by the intended selected relay WTRU. At 750, a first update packet can be generated based on the packet generated at 744 and transmitted at 748. The first update packet may include a payload from the packet generated at 744 and may have an update hop count that is one less than the maximum hop count. Notably, the first update packet may have an update header with a modified maximum hop count (i.e., modified to a first hop count that is one less than the maximum hop count). For clarity, the first number of hops may combine the hops from the remote WTRU to the selected relay WTRU. The first update packet generated at 748 may be generated at the remote WTRU and/or the selected relay WTRU such that it may be generated before and/or after transmission by the remote WTRU.

At 752 of flow diagram 730, the first update packet may be transmitted in a manner similar to the transmission of the packet to the selected relay WTRU at 748 based on the traffic type, the second update hop count, and/or the selected WTRU relay capability table. If one or more additional hops are needed, a first update packet may be received by a subsequently selected relay WTRU such that each additional hop may result in an update packet that includes a payload from the packet generated at 744. The subsequently selected relay WTRU may be an edge WTRU connected to the core network. At 754 of flowchart 730, a payload from the packet generated at 744 may be received at the core network completing the UL transmission from the core network to the remote WTRU.

Although features and elements are described above in particular combinations, one of ordinary skill in the art will understand that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer readable media include electronic signals (transmitted over a wired or wireless connection) and computer readable storage media. Examples of computer readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and Digital Versatile Disks (DVDs). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, terminal, base station, RNC, or any host computer.