Methods, devices, and systems for power-efficient d2d communication for wearable and iot devices
By employing device-to-device communication technology in wireless communication networks, the issues of communication reliability and efficiency in public safety applications are resolved. This enables efficient D2D communication outside the coverage area of LTE networks, supports the transmission of multiple services and traffic offloading, and meets the needs of public safety and commercial applications.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- INTERDIGITAL PATENT HOLDINGS INC
- Filing Date
- 2017-08-02
- Publication Date
- 2026-05-12
AI Technical Summary
Existing wireless communication networks struggle to achieve highly reliable and efficient device-to-device (D2D) communication in public safety applications, especially in areas outside LTE network coverage. They cannot meet the demands of public safety applications for services such as voice and video, and lack effective radio communication support in areas not covered by network infrastructure.
It adopts radio access technology based on 3GPP and LTE, and realizes functions such as direct, instant voice service and video push through device-to-device (D2D) communication. It also utilizes D2D services to offload services and traffic based on proximity, and supports the deployment of self-organizing radio infrastructure.
It improves the reliability and efficiency of communication for public safety applications, enables high-performance radio communication outside network coverage, supports the transmission of multiple service types, and achieves effective communication in areas not covered by network infrastructure.
Smart Images

Figure CN116321527B_ABST
Abstract
Description
[0001] This application is a divisional application of Chinese Patent Application No. 201780058225.4, filed on August 2, 2017, entitled “Method, apparatus and system for power-efficient D2D communication for wearable and IoT devices”, the contents of which are incorporated herein by reference. Technical Field
[0002] This invention relates to the field of wireless communication, and more specifically, to methods, apparatus, and systems for implementing device-to-device (D2D) communication in a wireless communication network. Background Technology
[0003] D2D communication has recently garnered significant attention as major standardization bodies such as IEEE and 3GPP have defined or are defining specifications supporting device-to-device (D2D) communication. Support for D2D communication is being introduced in the context of 3GPP and LTE-based radio access to enable cost-effective and high-performance public safety communications using LTE technology. This is primarily driven by the desire to harmonize radio access technologies across jurisdictions to reduce capital expenditures and operating costs for radio access technologies applicable to public safety (PS) type applications. Another important incentive is that LTE is a scalable broadband radio solution that can efficiently reuse different service types such as voice and video.
[0004] Because public safety (PS) applications typically require radio communication in areas outside the radio coverage of LTE networks (e.g., in tunnels, deep basements, or after a catastrophic system outage), D2D communication support is needed for PS in the absence of any operational network or before the arrival of ad hoc (Ad Hoc) deployed radio infrastructure. However, even when operating with operational network infrastructure, PS communication generally still requires higher reliability than commercial services.
[0005] PS-type applications (e.g., PS-type applications between first responders) are likely to include direct push-to-talk voice services using multiple call groups. Additionally, to effectively utilize the capabilities provided by LTE broadband radio, PS-type applications may include services such as video push or download.
[0006] The expectation is that once deployed, D2D communication will be available not only for PS-type applications but also for commercial uses. One example might be the situation for utility companies, which typically need to support two-way radio communication in areas not covered by network infrastructure. Furthermore, D2D services such as Discovery are suitable signaling mechanisms to allow for proximity-based service and traffic offloading using LTE-based radio access in commercial use cases. Attached Figure Description
[0007] A more detailed understanding can be obtained through the following detailed description given in conjunction with the accompanying drawings. Similar to the detailed description, the figures in these drawings are illustrative. Therefore, the drawings and detailed description should not be considered limiting, and other equally valid examples are also possible.
[0008] Furthermore, the same reference numerals in the accompanying drawings denote the same elements, and wherein:
[0009] Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented;
[0010] Figure 1B This illustrates a method according to an embodiment. Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) used within a communication system is shown.
[0011] Figure 1C This illustrates a method according to an embodiment. Figure 1A A system diagram of an example radio access network and another example core network used within the communication system shown;
[0012] Figure 1D This illustrates a method according to an embodiment. Figure 1A A system diagram of another example radio access network and another example core network used within the communication system shown;
[0013] Figure 1E This illustrates a method according to an embodiment. Figure 1A A system diagram of another example radio access network and another example core network used in the communication system shown;
[0014] Figure 2 This is a block diagram illustrating the basic communication architecture of D2D communication in a radio access network.
[0015] Figure 3A This is a diagram illustrating the signal flow for establishing and performing D2D communication in a radio network according to an exemplary embodiment of selecting a relay UE based on an MME;
[0016] Figure 3B This is a diagram illustrating the signal flow for establishing and performing D2D communication in a radio network according to an exemplary embodiment of relay UE selection based on a remote UE; and
[0017] Figure 4 A NAS message structure according to an exemplary embodiment is shown. Detailed Implementation
[0018] A detailed description of illustrative embodiments can now be described with reference to the accompanying drawings. However, while the invention can be described in conjunction with representative embodiments, the invention is not limited thereto, and it should be understood that other embodiments can be used, or modifications and additions can be made to the described embodiments to perform the same function of the invention without departing from the invention.
[0019] Although representative embodiments are shown in general using wireless network architectures below, any number of different network architectures can be used, including networks with wired and / or wireless components, for example.
[0020] I. Exemplary Network for Implementation
[0021] This disclosure is dedicated to improving D2D communication in next-generation 3GPP LTE radio access networks (RAN) (commonly referred to as 5G or New Radio (NR)). However, the concepts and inventions disclosed herein have a broader applicability. The following is a description of the basic structure of some of the more common RAN technologies and related equipment currently in use, and these concepts (including a description of the current 3GPP LTE architecture) can be applied.
[0022] Figure 1A This is an illustration of an exemplary communication system 100 that can implement one or more of the disclosed embodiments. The communication system 100 can be a multiple access system providing voice, data, video, messaging, broadcasting, and other content to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 can use 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), etc.
[0023] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, radio access networks (RANs) 103 / 104 / 105, core networks 106 / 107 / 109, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network components. Each WTRU 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, any WTRU 102a, 102b, 102c, or 102d may be referred to as a "station" and / or "STA," and may be configured to transmit and / or receive radio signals. It may include user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, consumer electronic devices, and so on. Any of WTRU 102a, 102b, 102c, or 102d may be interchangeably referred to as a UE.
[0024] The communication system 100 may also include base station 114a and / or base station 114b. Each base station 114a, 114b may be any type of device configured to enable access to one or more communication networks (e.g., core networks 106 / 107 / 109, the Internet 110, and / or other networks 112) by wirelessly interfacing with at least one of WTRUs 102a, 102b, 102c, 102d. For example, base stations 114a, 114b may be base transceiver stations (BTS), node B, e-node B, home node B, home e-node B, site controllers, access points (APs), and wireless routers, etc. Although each base station 114a, 114b is described as a single component, it should be understood that base stations 114a, 114b may include any number of interconnected base stations and / or network components.
[0025] Base station 114a may be part of RAN 103 / 104 / 105, and the RAN may also include other base stations and / or network components (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals within a specific geographical area called a cell (not shown). 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, base station 114a may include three transceivers, that is, each transceiver corresponds to one sector of the cell. In another embodiment, base station 114a may use multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell.
[0026] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interfaces 115 / 116 / 117, wherein the air interface can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interfaces 115 / 116 / 117 can be established using any suitable radio access technology (RAT).
[0027] More specifically, as described above, the communication system 100 can be a multiple access system and can use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA, etc. For example, base station 114a in RAN 103 / 104 / 105 and WTRU 102a, 102b, 102c can implement a certain radio technology, such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), wherein the technology can use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117. 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 UL Packet Access (HSUPA).
[0028] In another embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement a certain radio technology, such as Evolved UMTS Terrestrial Radio Access (E-UTRA), wherein the technology may use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) to establish air interfaces 115 / 116 / 117.
[0029] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement the following radio technologies, such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate for GSM Evolution (EDGE), and GSM EDGE (GERAN), etc.
[0030] Figure 1A Base station 114b can be a wireless router, home node B, home e node B, or access point, and can use any suitable radio access technology (RAT) to facilitate wireless connectivity in a local area, such as a business premises, residence, vehicle, campus, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can establish a wireless local area network (WLAN) by implementing a radio technology such as IEEE 802.11. In another embodiment, base station 114b and WTRUs 102c, 102d can establish a wireless personal area network (WPAN) by implementing a radio technology such as IEEE 802.15. In yet another embodiment, base station 114b and WTRUs 102c, 102d can establish a picocell or femtocell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.). Figure 1A As shown, base station 114b can be directly connected to the Internet 110. Therefore, base station 114b does not need to access the Internet 110 through core networks 106 / 107 / 109.
[0031] RANs 103 / 104 / 105 can communicate with core networks 106 / 107 / 109, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more WTRUs 102a, 102b, 102c, 102d. For example, core networks 106 / 107 / 109 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although in Figure 1AWhile not shown, it should be understood that RAN103 / 104 / 105 and / or core networks 106 / 107 / 109 can communicate directly or indirectly with other RANs that use the same RAT or a different RAT as RAN 103 / 104 / 105. For example, in addition to connecting with RAN 103 / 104 / 105 using E-UTRA radio technology, core networks 106 / 107 / 109 can also communicate with other RANs (not shown) using GSM, UMTS, CDMA 2000, WiMAX, or WiFi radio technologies.
[0032] Core networks 106 / 107 / 109 may also act as gateways for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Simple Old-Style Telephone Service (POTS). The Internet 110 may include a globally interconnected computer network system using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another core network connected to one or more RANs, wherein the one or more RANs may use the same RAT or a different RAT as RAN 103 / 104 / 105.
[0033] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multi-mode capability (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers communicating with different wireless networks on different wireless links). For example... Figure 1A The WTRU102c shown can be configured to communicate with base station 114a, which can use cellular-based radio technology, and with base station 114b, which can use IEEE 802 radio technology.
[0034] Figure 1B This is a system diagram illustrating an example of WTRU 102. (See diagram below.) Figure 1BAs shown, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive unit 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripheral devices 138. It should be understood that, while remaining consistent with the embodiments, WTRU 102 may also include any sub-combination of the foregoing components.
[0035] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), and a state machine, etc. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, and transceiver 120 can be coupled to transmitting / receiving unit 122. Although Figure 1B While the processor 118 and transceiver 120 are described as separate components, it should be understood that the processor 118 and transceiver 120 can also be integrated into a single electronic component or chip.
[0036] Transmit / receive component 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) via air interface 115 / 116 / 117. For example, in another embodiment, transmit / receive component 122 may be an antenna configured to transmit and / or receive RF signals. As an example, in another embodiment, transmit / receive component 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, transmit / receive component 122 may be configured to transmit and / or receive RF and optical signals. It should be understood that transmit / receive component 122 may be configured to transmit and / or receive any combination of wireless signals.
[0037] Although Figure 1B While the transmit / receive component 122 is described as a single component, the WTRU 102 may include any number of transmit / receive components 122. More specifically, the WTRU 102 may use MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive components 122 (e.g., multiple antennas) that transmit and receive radio signals via air interfaces 115 / 116 / 117.
[0038] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving unit 122 and demodulate signals received by transmitting / receiving unit 122. As described above, WTRU 102 can have multimode capability. Therefore, transceiver 120 can include multiple transceivers that allow WTRU 102 to communicate using various RATs (e.g., UTRA and IEEE 802.11).
[0039] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keyboard 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from these components. The processor 118 can also output user data to the speaker / microphone 124, keyboard 126, and / or display / touchpad 128. Furthermore, the processor 118 can access and store information from any suitable memory, such as non-removable memory 130 and / or removable memory 132. Non-removable memory 130 can include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 can include a subscriber identity module (SIM) card, memory stick, secure digital card (SD) memory card, etc. In other embodiments, the processor 118 can access and store information from memory that is not actually located in WTRU 102; for example, such memory could be located in a server or home computer (not shown).
[0040] The processor 118 can receive power from the power supply 134 and can be configured to distribute and / or control power for other components in the WTRU 102. The power supply 134 can be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell battery packs (such as nickel-cadmium (Ni-Cd), nickel-zinc (Ni-Zn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, and fuel cells, etc.
[0041] 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) related to the current location of the WTRU 102. As a supplement or replacement to the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interfaces 115 / 116 / 117, and / or determine its location based on signal timing received from two or more nearby base stations. It should be understood that, while remaining consistent with the embodiments, the WTRU 102 may acquire location information using any suitable positioning method.
[0042] The processor 118 can also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, etc. Modules, FM radio units, digital music players, media players, video game console modules, internet browsers, etc. When the peripheral device 138 includes one or more sensors, the sensors may be one or more of the following: gyroscopes, accelerometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, and / or humidity sensors.
[0043] WTRU 102 may include a full-duplex radio device, wherein the reception or transmission of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous for the radio device. The full-duplex radio device may include an interference management unit 139 that reduces and / or substantially eliminates self-interference by means of hardware (e.g., choke coils) or by means of a processor (e.g., a separate processor (not shown) or by means of processor 118) for signal processing.
[0044] Figure 1C This is a system schematic diagram of RAN 103 and core network 106 according to another embodiment. As described above, RAN 103 can use UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 115. RAN 103 can also communicate with core network 106. Figure 1CAs shown, RAN 103 may include nodes B 140a, 140b, and 140c, each of which may include one or more transceivers communicating with WTRUs 102a, 102b, and 102c via air interface 115. Each of nodes B 140a, 140b, and 140c may be associated with a specific cell (not shown) within RAN 103. RAN 103 may also include RNCs 142a and 142b. It should be understood that RAN 103 may include any number of nodes B and RNCs while remaining consistent with the embodiments.
[0045] like Figure 1C As shown, nodes B 140a and 140b can communicate with RNC 142a. Additionally, node B 140c can also communicate with RNC 142b. Nodes B 140a, 140b, and 140c can communicate with their respective RNCs 142a and 142b via the Iub interface. RNCs 142a and 142b can communicate with each other via the Iur interface. Each RNC 142a and 142b can be configured to control its connected node B 140a, 140b, or 140c. Furthermore, each RNC 142a and 142b can be configured to perform or support other functions, such as outer-loop power control, load control, permission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.
[0046] Figure 1C The core network 106 shown may include a Media Gateway (MGW) 144, a Mobile Switching Center (MSC) 146, a Serving GPRS Support Node (SGSN) 148, and / or a Gateway GPRS Support Node (GGSN) 150. Although each of the foregoing components is described as part of the core network 106, it should be understood that entities other than the core network operator may also own and / or operate any of these components.
[0047] RNC 142a in RAN 103 can connect to MSC 146 in core network 106 via the IuCS interface. MSC 146 can then connect to MGW 144. MSC 146 and MGW 144 can provide WTRU 102a, 102b, and 102c with access to circuit-switched networks such as PSTN 108, facilitating communication between WTRU 102a, 102b, and 102c and traditional landline communication equipment.
[0048] The RNC 142a in RAN 103 can also be connected to the SGSN 148 in core network 106 via an IuPS interface. The SGSN 148 can then be connected to the GGSN 150. The SGSN 148 and GGSN 150 can provide WTRUs 102a, 102b, and 102c with access to packet-switched networks such as the Internet, facilitating communication between WTRUs 102a, 102b, and 102c and IP-enabled devices.
[0049] As described above, the core network 106 can also be connected to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.
[0050] Figure 1D This is a system schematic diagram showing RAN 104 and core network 107 according to one embodiment. As described above, RAN 104 can use E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. Furthermore, RAN 104 can also communicate with core network 107.
[0051] RAN 104 may include eNodeBs 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of eNodeBs while remaining consistent with the embodiments. Each eNodeB 160a, 160b, and 160c may include one or more transceivers to communicate with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNodeBs 160a, 160b, and 160c may implement MIMO technology. Thus, for example, eNodeB 160a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.
[0052] Each eNodeB 160a, 160b, or 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. For example... Figure 1D As shown, nodes B160a, 160b, and 160c can communicate with each other via the X2 interface.
[0053] Figure 1DThe core network 107 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. While each of the above components is described as part of the core network 107, it should be understood that entities other than the core network operator may also own and / or operate any of these components.
[0054] MME 162 can connect to each eNodeB 162a, 162b, 162c in RAN 104 via the S1 interface and can act as a control node. For example, MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a specific serving gateway during the initial attach process of WTRUs 102a, 102b, 102c, etc. MME 162 can provide control plane functions to perform handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.
[0055] Service gateway 164 can connect to each eNodeB 160a, 160b, 160c in RAN 104 via the S1 interface. Service gateway 164 typically routes and forwards user data packets to / from WTRUs 102a, 102b, 102c. Service gateway 164 can perform other functions, such as anchoring the user plane during handover between eNodeBs, triggering paging when DL data is available to WTRUs 102a, 102b, 102c, managing and storing the context of WTRUs 102a, 102b, 102c, etc.
[0056] Service gateway 164 can be connected to PDN gateway 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks such as the Internet 110, in order to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.
[0057] Core network 107 can facilitate communication with other networks. For example, core network 107 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks such as PSTN 108 to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. As an example, core network 107 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), wherein the IP gateway acts as an interface between core network 107 and PSTN 108. Furthermore, core network 107 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.
[0058] Figure 1E This is a system schematic diagram illustrating RAN 105 and core network 109 according to one embodiment. RAN 105 may be an access service network (ASN) communicating with WTRUs 102a, 102b, and 102c via air interface 117 using IEEE 802.16 radio technology. As discussed further below, communication links between different functional entities of WTRUs 102a, 102b, and 102c, RAN 105, and core network 109 can be defined as reference points.
[0059] like Figure 1E As shown, RAN 105 may include base stations 180a, 180b, 180c and ASN gateway 182. However, it should be understood that RAN 105 may include any number of base stations and ASN gateways while remaining consistent with the embodiments. Each base station 180a, 180b, 180c may be associated with a specific cell (not shown) in RAN 105, and each base station may include one or more transceivers to communicate with WTRUs 102a, 102b, 102c via air interface 117. In one embodiment, base stations 180a, 180b, 180c may implement MIMO technology. Thus, for example, base station 180a may use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a. Base stations 180a, 180b, 180c may also provide mobility management functions such as handover triggering, tunnel establishment, radio resource management, traffic classification, Quality of Service (QoS) policy enforcement, etc. ASN Gateway 182 can act as a traffic aggregation point and can be responsible for implementing paging, subscriber profile caching, routing to the core network 109, etc.
[0060] The air interface 117 between WTRUs 102a, 102b, and 102c and RAN 105 can be defined as an R1 reference point implementing the IEEE 802.16 standard. Additionally, each WTRU 102a, 102b, and 102c can establish a logical interface (not shown) with the core network 109. This logical interface between WTRUs 102a, 102b, and 102c and the core network 109 can be defined as an R2 reference point, which can be used for authentication, licensing, IP host configuration management, and / or mobility management.
[0061] The communication link between each base station 180a, 180b, and 180c can be defined as an R8 reference point, which includes protocols for facilitating WTRU handover and data transmission between base stations. The communication link between base stations 180a, 180b, and 180c and ASN gateway 182 can be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each WTRU 102a, 102b, and 100c.
[0062] like Figure 1E As shown, RAN 105 can be connected to core network 109. The communication link between RAN 105 and core network 109 can be defined as an R3 reference point, which, as an example, includes protocols for facilitating data transfer and mobility management capabilities. Core network 109 may include a Mobile IP Home Agent (MIP-HA) 184, an Authentication, Authorization, and Accounting (AAA) server 186, and a gateway 188. While each of the aforementioned components is described as part of core network 109, it should be understood that entities other than the core network operator may also own and / or operate any of these components.
[0063] MIP-HA 184 can implement IP address management and allow WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. MIP-HA 184 can provide WTRUs 102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, facilitating communication between WTRUs 102a, 102b, and 102c and IP-enabled devices. AAA Server 186 can handle user authentication and support user services. Gateway 188 can facilitate interoperability with other networks. For example, Gateway 188 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks such as PSTN 108, facilitating communication between WTRUs 102a, 102b, and 102c and legacy terrestrial communication equipment. Additionally, the gateway 188 can also provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.
[0064] Although Figure 1E Although not shown, it should be understood that RAN 105 can connect to other ASNs, and other RANs (e.g., RAN 103 and / or 104) and / or core network 109 can connect to other core networks (e.g., core networks 106 and / or 107). The communication link between RAN 105 and other ASNs can be defined as an R4 reference point, which may include protocols for coordinating the mobility of WTRUs 102a, 102b, and 102c between RAN 105 and other ASNs. The communication link between core network 109 and other core networks can be defined as an R5 reference point, which may include protocols for facilitating interoperability between the home core network and the visited core network.
[0065] Although Figure 1A-1E The WTRU is described as a wireless terminal; however, it should be understood that in some typical embodiments, such a terminal may use a wired communication interface (e.g., temporary or permanent) with the communication network.
[0066] In a typical embodiment, the other network 112 may be a WLAN.
[0067] A WLAN employing an Infrastructure Basic Services Set (BSS) model may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may access or interface with a distributed system (DS) or other type of wired / wireless network that sends traffic into and / or out of the BSS. Traffic originating outside the BSS and destined for a STA can be delivered to the STA via the AP. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP; for example, a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between the source and destination STAs (e.g., directly therebetween) using Direct Link Establishment (DLS). In some typical embodiments, the DLS may use 802.11e DLS or 802.11z Channelized DLS (TDLS). A WLAN using the Independent BSS (IBSS) mode may not have an access point (AP), and STAs (STAs) within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. Here, the IBSS communication mode is sometimes referred to as a "self-organizing" communication mode.
[0068] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel (e.g., the primary channel). The primary channel can have a fixed width (e.g., a 20 MHz bandwidth) or a width dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by STAs to establish connections with the AP. In some typical embodiments, Carrier-Sensed Multiple Access with Collision Avoidance (CSMA / CA) can be implemented (e.g., in an 802.11 system). For CSMA / CA, STAs, including the AP (e.g., each STA), can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, that particular STA can fall back. Within a given BSS, at any given time, only one STA (e.g., only one station) can be transmitting.
[0069] High-throughput (HT) STAs can communicate using channels with a width of 40 MHz (e.g., by combining a 20 MHz main channel with an adjacent 20 MHz adjacent channel to form a continuous 40 MHz channel).
[0070] Very High Throughput (VHT) STAs can support channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels or by combining two non-consecutive 80MHz channels (this combination may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data is transmitted and passed through a segmented parser that splits the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed individually on each stream. The streams can be mapped onto two 80MHz channels, and the data can be transmitted by the STA performing the transmission. On the receiver of the STA performing the reception, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).
[0071] 802.11af and 802.11ah support sub-1 GHz operating modes. Compared to 802.11n and 802.11ac, the channel operating bandwidth and carrier used in 802.11af and 802.11ah are reduced. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a typical embodiment, 802.11ah can support instrument-type control / machine-type communication (e.g., machine-type communication (MTC) devices in macro coverage areas). MTC may have certain capabilities, such as limited capabilities including support (e.g., only support) certain and / or limited bandwidths. MTC devices may include a battery with a battery life exceeding a threshold (e.g., for maintaining a very long battery life).
[0072] For WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah), the WLAN system includes a channel that can be designated as the primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by a particular STA, which is derived from all STAs operating in the BSS that support the minimum bandwidth operating mode. In the example of 802.11ah, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes, the width of the primary channel can be 1MHz for STAs that support (e.g., only support) the 1MHz mode (e.g., MTC type devices). Carrier sensing and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy (e.g., because an STA (which only supports the 1MHz operating mode) is transmitting to the AP), then the entire available band can be considered busy even if most of the band remains open and available.
[0073] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. Depending on the country code, the total bandwidth available for 802.11ah is 6MHz to 26MHz.
[0074] II.D2D
[0075] D2D communication using LTE-based radio access is designed to operate in either network-controlled mode or UE-autonomous mode (hereinafter referred to as Mode 1 and Mode 2, respectively). Mode 1 (network-controlled) is only possible when the relay D2D terminal is within the radio range of the LTE base station. If the D2D terminal cannot communicate with the LTE base station, it will fall back to Mode 2 (UE-autonomous) operation. In Mode 2, the UE will primarily use the channel access parameters pre-stored in the UE.
[0076] For D2D communication in Mode 1, the LTE base station reserves a selected set of UL subframes for D2D transmission. The LTE base station may also advertise a set of UL subframes, including relevant parameters, in which D2D communication for neighboring cells or Mode 2 terminals can be received. Not all LTE system bandwidth (BW) in subframes reserved for D2D is necessarily available for D2D transmission. When operating in Mode 1, radio resources for D2D communication are licensed to the D2D terminal by the serving cell. The D2D license from the network is preceded by a UL transmission performed by the terminal using one or more of the cell's normal UL channels, which indicates to the base station the amount of D2D data the terminal wishes to transmit. The D2D license received by the D2D terminal from the LTE base station on the cell's DL control channel will allow the D2D terminal to use certain selected radio resources, i.e., certain resource blocks (RBs) in certain subframes, within a certain scheduling period.
[0077] In Mode 1, the D2D terminal sends a Scheduling Assignment (SA) request message in one or more D2D subframes in the first group, and then transmits the D2D data in the second group of D2D subframes during the scheduling period. Among other things, the scheduling assignment includes an identifier field, a modulation and coding scheme (MCS) field, and resource indicator and tracking area (TA) fields. Among other things, the D2D data packet includes a Media Access Control (MAC) header with source and destination addresses. Multiple logical channels can be multiplexed and transmitted by the UE as part of a single transport block (TB) in a given D2D subframe.
[0078] For D2D communication in Mode 2, the D2D terminal autonomously selects time / frequency radio resources. Channel access parameters are typically pre-configured (e.g., subframes, scheduling periods, or surveillance subframes for SA control messages and corresponding D2D data transmission) and stored on the D2D terminal. Except for the UL traffic indication and DL D2D licensing phases (both discussed above in conjunction with Mode 1 operation), Mode 2 terminals essentially follow the same transmission behavior as Mode 1 terminals; that is, they also send SA request messages, followed by D2D data within the scheduling period.
[0079] For D2D communication in Mode 1 and Mode 2, the D2D terminal can also send auxiliary D2D signals, such as D2D synchronization signals and channel condition messages (e.g., CQI), to help the receiver demodulate the D2D terminal's transmission.
[0080] D2D communication using LTE-based radio access can carry voice channels or data packets. A special case of D2D communication is D2D discovery service. Unlike voice channels, D2D discovery typically requires only small packet transmissions, which can usually be assembled within one, two, or several subframes. For example, these packets may contain application data announcing the availability of a device or software application to participate in D2D data exchange with nearby terminals.
[0081] D2D discovery may or may not use the same channel access protocol as D2D communication used for voice or data. For D2D discovery services within the coverage area of an LTE base station, D2D discovery resources can be allocated separately from those used for D2D communication with voice or general D2D data. Radio resources used for D2D discovery messages can be autonomously selected by the D2D terminal from a set of resources reserved by the eNB and periodically repeated as time-frequency radio resources in certain UL subframes (Type 1 discovery), or they can be explicitly allocated to the D2D terminal by the LTE serving cell (Type 2 discovery). The latter case is similar to D2D communication mode 1 because the resources are allocated by the network. On the other hand, the difference is that transmission regarding scheduling assignment is not mandatory when sending D2D discovery messages. However, in some cases, it may still be necessary for the D2D terminal sending only D2D discovery messages to transmit auxiliary D2D synchronization signals to assist the D2D receiver.
[0082] Using LTE technology to connect to and manage low-cost MTC devices is of great significance. A prime example of such low-cost devices is wearable devices, which also have the advantage of being almost always close to a smartphone that can be used as a relay.
[0083] A research project (SI) on D2D enhancements for wearable and Internet of Things (IoT) devices has been discussed in the 3GPP RAN (see RP-160677, Further Enhancements to LTE Device to Device, UE to Network Relays for IoT and Wearables). The aim of this SI is to investigate the application of D2D (including non-3GPP short-range technologies) in these devices. Specifically, two main aspects of LTE technology require further enhancement to enable D2D-assisted wearable and MTC applications: enhancements to UE to network relay functionality and enhancements to achieve reliable unicast PC5 links to at least support low-power, low-rate, low-complexity / low-cost devices. Regarding the enhancement of UE to network relay functionality, the UE to network relay architecture in ProSe (Proximity Services) does not distinguish between the traffic of remote UEs and the traffic of relay UEs in the access layer. This model limits the ability of networks and operators to treat remote UEs as separate devices, for example, for billing or security purposes. In particular, 3GPP security associations do not extend end-to-end between the network and remote UEs. Therefore, relay UEs can access the communications of remote UEs without restriction. In some cases, this may pose a security risk to the remote UE.
[0084] UE-to-network relay should be enhanced to support (1) end-to-end security over the relay link, (2) service continuity, (3) E2E QoS (end-to-end quality of service) (where possible), (4) efficient operation with multiple remote UEs, and (5) efficient path switching between the Uu and D2D air interfaces. Relaying using D2D can also be based on non-3GPP technologies such as Bluetooth and Wi-Fi. Enhancements such as service continuity can make relaying more attractive to these technologies in commercial use cases. This is particularly useful for wearable devices due to their proximity to the user's smartphone and form factor limitations that may make direct Uu connections less practical (e.g., due to battery size limitations). Relaying can achieve significant power savings for remote UEs (which are relaying their traffic). This is especially true for deep coverage scenarios. One cost-effective way to introduce relaying is to use a unidirectional D2D link between the remote device and the relay device. In this case, the relay UE can be used to relay only uplink data from the remote UE. The advantage of this method is that it does not add additional RF capabilities for D2D reception to the remote UE.
[0085] Regarding the enhancements to achieve reliable unicast PC5 links to support at least low-power, low-data-rate, and low-complexity / low-cost devices, low-cost D2D devices can be implemented by reusing ideas developed during NB-IoT (Narrowband-IoT) and eMTC research. For example, NB-IoT / eMTC uplink waveforms can be reused for D2D. These devices may use a single modem to communicate with the Internet / cloud and with near-end devices. Current PC5 link designs, derived from broadcast-oriented designs driven by public safety use cases, suffer from a bottleneck: the lack of any link adaptation and feedback mechanisms hinders low-power and reliable D2D communication. These shortcomings prevent achieving the target performance metrics for wearable and MTC use cases in terms of power consumption, spectral efficiency, and device complexity. Low power consumption and low complexity are critical attributes for wearable and MTC use cases, which typically feature small form factors and long battery life.
[0086] Figure 2 The basic architecture of remote UE 205 and relay UE 203 is shown, which includes their connection to eNB 201. The basic assumptions in the context of the current SI in 3GPP (see RP-160677, further enhancements for LTE device-to-device, UE-to-network relay for IoT and wearable devices) are as follows: (1) Interface (IF)1 is the Uu interface between the UE and the eNB; (2) IF2 is a D2D link (which may be PC5, but may also be a non-3GPP link, such as Bluetooth, WiFi or other non-3GPP links); (3) IF3 is the Uu interface, which may be assumed to be NB-IoT (i.e., the remote UE may be within the extended coverage of the eNB through NB-IoT repeat).
[0087] The following options are possible regarding how to route data and control information to / from a remote UE via different interfaces.
[0088] First, all control and data to / from remote UE 205 can be sent via IF2. In this scenario, remote UE 205 may still be able to listen for broadcast signaling via IF3 when connected to relay UE 203, but it can also receive broadcast signaling from relay UE 203. This scheme results in maximum power savings for the remote UE.
[0089] Alternatively, control and data communications can be separated. In this case, control information and procedures are executed on IF3, but data (UL and DL) are transmitted via IF2. In this case, the remote UE 205 can save power associated with sending and receiving data via IF2, but cannot save power related to control information.
[0090] In the third option, uplink and downlink communication are separated. In this case, all uplink data (control and data) is sent via IF2, and all downlink data (control and data) is sent via IF3. In this configuration, the UE can save power by avoiding uplink transmissions.
[0091] In the fourth option, the remote UE 205 transmits only UL user plane (UP) data via IF2. All other traffic (DL UP and all control plane traffic) is transmitted via IF3.
[0092] The technologies described in LTE Release 13 for D2D UE-to-network relay have several drawbacks that make them less than ideal for IoT and wearable devices. For example, the wearable and IoT use cases are primarily for commercial applications. Currently, there is no interaction between the ProSe function and the eNB. Because commercial use such as wearables and IoT requires substantial control over D2D communication by the eNB (e.g., determining resources for D2D communication), the ProSe function may need to be completely replaced, or at least significantly modified to be more closely integrated with the eNB or network. To achieve better QoS and resource utilization (to address the potential for a large number of relays), the network should be given greater control compared to LTE Release 13 relays, including but not limited to the ability to trigger the establishment and teardown of relay links and / or discovery. Furthermore, most wearable devices are likely personal gadgets. Therefore, typical wearable and / or IoT devices should be able to connect to only one or a few authorized relay devices (e.g., the gadget owner's phone and / or tablet). In other words, in this scenario, the wearable or IoT device should only be able to access the relay device it is configured to connect to, rather than attempting to connect to all available neighboring relay UEs. This process needs clarification and an overview. Furthermore, the relay scheme in version 13 is designed for situations where remote devices are not directly connected to the network. However, wearable device use cases will typically present very different scenarios, where the wearable device is located within the eNB's coverage area, but D2D is primarily used for power-saving purposes. Therefore, the connectivity and coverage assumptions for wearable and IoT relays are very different, leading to the need for different assumptions related to connectivity and access.
[0093] For example, it is not necessary to assume that the remote device has no direct connection to the network. Therefore, the solution can utilize D2D relays for some communications but not for others. New control signaling and transports are expected, which, in relation to the remote UE and the network (e.g., NAS), enable the remote UE to communicate directly with the network in some aspects and via relays in others. Furthermore, new access and discovery mechanisms are expected to provide greater eNB and network control over D2D communications.
[0094] Most of the embodiments discussed below are described for the scenario where the UE communicates using D2D under the control of the LTE network. However, such solutions are also applicable to future 5G RATs. Therefore, as an example only, although the eNB is primarily described below as a network control point, it should be understood that the eNB is merely an example, and the network control point can be a cell, a transport point (TRP), or an equivalent network control point in 5G.
[0095] Furthermore, this disclosure primarily uses PC5 (i.e., the traditional LTE D2D link) to describe D2D links and associated processes. However, it should be reiterated that this is merely exemplary, and other technologies can be used, including non-3GPP technologies as part of LTE research projects (RP-160677 mentioned above, further enhancements to LTE device-to-device and UE-to-network relay for IoT and wearable devices) and future device-to-device communication technologies for 5G (including 3GPP-based and non-3GPP-based technologies).
[0096] II.A. Relay Selection Based on MME
[0097] The process outlined in this section is based on the premise that the subscription information of a remote device (e.g., a wearable device) is linked to the subscription of a relay device (e.g., a cellular phone or other UE). Specifically, the wearable device and the relay UE (e.g., a smartphone) are typically owned by the same subscriber; therefore, when the wearable device (remote UE) attaches to the network, the subscription database on the network (e.g., the Home Subscriber Service (HSS)) may have already linked the relay node to the wearable device's information.
[0098] Figure 3A This is a signal flow diagram illustrating an exemplary process according to an exemplary embodiment employing MME-based relay selection. As shown, during the attach process 301, the wearable UE 313 can indicate to the network (MME 317) that it is capable of acting as a remote UE. Based on such indication, the MME 317 can query the HSS 319 (see...). Figure 3AQuery 302 in the query request requests information (e.g., relay UE ID) about any one or more UEs (e.g., UE 311) registered with the HSS as belonging to the same user as the wearable UE 313 and capable of serving as a relay UE for the wearable UE 313. This can be done as part of the subscription request process. As part of the response message 303 received from the HSS 319, the MME 317 can receive security information specific to the remote UE-relay UE connection. Of course, those skilled in the art will understand that NAS signaling between the MME and the UE can be transmitted via the eNB 315.
[0099] Information related to the identification of the relay UE(s) that can be obtained by the MME 317 from the HSS 319 may include, for example, one or more relay UE IDs (IDs broadcast by the relay UE for PC5 discovery) and security information, such as one or more special signatures that can be used by the remote UE to authenticate the relay UE (described in more detail below in conjunction with PC5 discovery procedure 306) and vice versa (i.e., the relay UE can use the same signature to authenticate the remote UE). The MME 317 may forward this information to the remote UE 313 (e.g., a wearable device) in the attach response message 304. Furthermore, a security key for encrypting data transmitted over the PC5 link may also be sent in the attach response message 304.
[0100] After completing the attachment process, the wearable UE 313 can initiate a PC5 discovery process and locate the relay UE (one or more) 311 based on the received relay UE ID (one or more). To avoid confusion with the accompanying drawings, this process is primarily described only in... Figure 3A Points 305 and 306 in the diagram indicate this. However, it should be understood that the PC5 discovery process involves various signaling between network nodes. For example, relay UE 311 may broadcast its security signature as part of a discovery message (PC5 discovery). Remote UE 313 authenticates the relay UE by comparing the security signature received on the PC5 discovery channel with the security signature received in the attach response message 304. If the signatures match, the relay UE can be considered authenticated.
[0101] In some exemplary embodiments, the MME 317 may provide more than one relay UE to the remote UE in the attach response message 304. This may be the case if the wearable UE is associated with multiple relay UEs, based on subscriber information stored at the HSS 319. The remote UE 313 may then adaptively select a specific relay from a list of potential relay UEs to connect to based on certain criteria, such as any one or more or a combination of the following: (1) measurements on PC5 determined during the discovery process (e.g., the remote UE may simply select the relay UE with the best quality measurement or the first relay UE in the list with a measurement above a certain threshold); (2) the current load of the relay UEs announced during the discovery process (e.g., the number of connected remote UEs) (selecting the relay UE with the fewest connected remote UEs); and (3) predefined or configurable preferences in the application layer.
[0102] The discovery process may be followed by the establishment or association of a connection between the remote UE 313 and the relay UE 311. The connection establishment message 307 sent by the remote UE 313 to the relay UE 311 may include a security signature required by the relay UE 311 to authenticate the remote UE 313. The relay UE 311 can then authenticate the remote UE 313 based on this signature. Figure 3A In step 8), it is assumed that when it connects to the network, or when the remote UE 313 connects to the network, it receives some security information from the network, such as a signature context and encryption keys (one or more) for authentication. Alternatively, the relay UE 311 may request such security information from the network when it receives a connection request 307 from the remote UE 313. The relay UE 311 authenticates the remote UE 313 (308) based on the received security signature and sends a connection response 309 to the remote UE 313. The connection response message 309 may include the relay UE's security signature.
[0103] Data transmission 310 can begin upon completion of connection establishment. This data transmission can be encrypted using keys previously received from the network by the remote UE and the relay UE.
[0104] Note that the Attach Request message 304 in the above process is merely exemplary. Other NAS messages (mobility management, session management, or new NAS messages) may be used alternatively or additionally for this purpose.
[0105] II.B. Relay Selection Based on Remote UE
[0106] In an exemplary embodiment based on a remote UE, such as Figure 3B As shown, remote UE 313' can communicate with networks 323, 324, 325, 326 (and) Figure 3A Compared to 301, 302, 303, and 304 in the previous step, the attachment process performed before PC5 detected 321 and 322 (compared to 301, 302, 303, and 304). Figure 3A Compared to 305 and 306 in the previous section). By performing PC5 discovery 321 and 322, the remote UE 313' becomes aware of one or more available relay UEs 311' in its vicinity. Through this discovery process, the remote UE 313' can generate a list of identifiers for all available relay UEs (or a subset of surrounding relay UEs).
[0107] For example, the subset can be determined based on one or more predetermined criteria, such as the Public Land Mobile Network (PLMN) to which the potential relay UE belongs. For instance, only relay UEs belonging to a specific PLMN can be stored by the remote UE. PLMN information can be broadcast by the relay UE as part of a PC5 discovery message, or it can be part of the broadcast relay UE ID. Alternatively or additionally, only potential relay UEs that meet a signal level threshold can be selected. Note that due to the low transmission power characteristics of remote UEs, a remote UE may be able to listen for discovery signals from some relay UEs but cannot send them.
[0108] Alternatively or additionally, the broadcast discovery message may include an indication of whether the potential relay UE supports relaying to wearable or IoT devices. This information may be broadcast by the relay UE as part of a PC5 discovery message.
[0109] Alternatively or additionally, the remote UE may consider information about the types of services supported by the relay UE (e.g., health monitoring services). The relay UE may broadcast the supported services in a PC5 discovery message.
[0110] Alternatively or additionally, the remote UE may take into account the current load of the relay UE (e.g., the number of remote UEs already connected to the relay UE).
[0111] After discovering processes 321 and 322, the remainder of the process can be substantially as follows: Figure 3A That's how it's done.
[0112] For example, the remote UE 313 can then perform an attach procedure with the network (with... Figure 3A Compared to 301, 302, 303, and 304 in the previous embodiment). The attachment message 323 in this embodiment is similar to that in the network-based embodiment ( Figure 3AThe attach message described may differ in that it may contain a list of possible relay candidates (relay UE IDs) based on the discovery process described above and the criteria described above for selecting a smaller subset of possible relay UEs. Upon receiving this information, MME 317' may check (message 324) HSS 319' to obtain the subscription profile of remote UE 313' and the subscription information of each possible relay UE (which is part of the list included in attach message 301 received from the remote UE). HSS 319' should respond (message 325), and then MME 317' can use the information received from HSS 319' in message 325 and the parameters in attach message 323 to select the relay UE 311' that remote UE 313' should attempt to connect to. Such relay UE information can be transmitted back to the remote UE in attach accept message 326.
[0113] MME 317' may select more than one possible relay UE. If this is the case, MME 317' may send the associated priority of each relay UE in the attach accept message 326. Remote UE 313' may begin by attempting to associate with the relay UE with the highest priority (message 327). Relay UE 311' authenticates remote UE 313' based on the received security signature (328) and sends a connection response 329 to remote UE 313'. The connection response message 329 may include the security signature of the relay UE. Data transmission 330 may begin after the connection is established. This data transmission may be encrypted by a key previously received from the network by both the remote UE and the relay UE.
[0114] If the remote UE cannot connect to the relay UE, it can attempt to associate with the next highest-ranked relay UE in the priority list, and so on. As previously mentioned, the security parameters (authentication signature, encryption key, etc.) can also be sent by the MME for authentication purposes and for encrypting user data.
[0115] MME 317' can consider one or more additional factors besides subscription information to determine the list of relay UEs and their associated priorities for the remote UE. For example, it can consider the PLMN ID of the relay UE. For example, considering network sharing protocols with various PLMNs, the MME can allow only remote UEs to connect to relay UEs from a specific PLMN. Alternatively or additionally, the MME can consider the type of the remote UE (e.g., wearable UE or IoT UE) and / or the number of remote UEs already connected to the relay UE. The MME can determine the type of remote UE and the number of remote UEs connected to a specific relay UE based on message exchanges between the relay UE or the remote UE and the MME when the remote UE connects to the relay UE.
[0116] Alternatively or additionally, the MME may consider service types (e.g., smartwatches, priority services such as health monitoring requested by a remote UE). The service information may be part of the attach message or a different NAS message exchange between the UE and the core network.
[0117] II.C. Core Network Procedures for Remote UEs
[0118] This section concerns NAS signaling between the remote UE and the core network via a relay UE. In other words, it involves control messages (e.g., NAS messages) sent by the remote UE to the relay UE, which then forwards them on behalf of the remote UE to the core network (the counterpart to control messages directly transmitted between the remote UE and the network, such as...). Figure 3A (Messages 1 and 4 in the text).
[0119] The process discussed below can be performed when a remote UE first discovers a relay UE, or when a remote UE receives an indication or trigger (or more specifically, control signaling) from an eNB or network to move traffic to a relay node.
[0120] II.C.1. NAS Message Transmission
[0121] The remote UE can send the NAS message to the relay UE via PC5-S or a sidelink channel. Assume a sidelink channel exists for control signaling. (Reference) Figure 4New message types (e.g., PDCP SDU type) 401 or L2 protocol IDs (e.g., ProSe destination L2 ID) can be defined for NAS messages from a remote UE to a relay UE via a sidelink, enabling the relay UE receiving the control message to understand it as a NAS message and thus forward it to the relay UE's NAS layer. Alternatively, NAS messages between the remote UE and the relay UE can be sent via a separate resource pool on PC5, or identified via a dedicated ProSe (PPPP) or sidelink logical channel according to packet priority.
[0122] Figure 4 A NAS message structure, according to an exemplary embodiment, is shown for use by a relay UE to forward NAS messages received from a remote UE (e.g., via the aforementioned PC5-S channel or sidelink channel) to an MME (or other network node). A new EPS Mobility Management (EMM) message container 405 can be added at the NAS layer. The purpose of this container is to transmit remote UE NAS messages to the MME within this container via a NAS signaling connection between the relay UE and the MME. The new EMM405 container is sent to the MME in an EMMNAS message (new or existing). A new value for the Protocol Discriminator Information Element (IE) 409 can be defined such that the MME understands that the received message is a NAS message from a remote UE. The MME takes further action based on the payload of the message container 405. Note that a similar approach can be used for Session Management (SM) messages.
[0123] In the downlink, the MME can encapsulate a NAS message for a remote UE within an EMM message container 405, similar to a NAS message to the relay UE. Based on the protocol discriminator 409 of the incoming NAS message, the relay UE can infer that the message is destined for a remote UE. The relay UE's NAS layer will further examine the payload of the EMM message container 405 to determine the ID of the remote UE to which the NAS message is addressed, for example, a globally unique temporary UE ID (GUTI). A mapping may exist at the NAS layer between the remote UE GUTI (an identifier known at the CN) and a sidelink ID (e.g., a ProSe ID). The relay UE then forwards the NAS message to the access layer (AS) with the ProSe ID, whereby the AS will use this identifier to send the message to the remote UE via the sidelink. Upon receiving this sidelink message, based on the previously described message type or L2 protocol ID, the message will be forwarded to the NAS layer in the remote UE.
[0124] In addition to the protocol discriminator, NAS messages exchanged between the relay UE and the MME can also contain message types, although such information can also be found in the remote UE EMM container with the remote UE NAS payload. Including such information as part of the message can help the MME prioritize various requests during periods of high congestion.
[0125] II.C.2. Tracking Area Updates
[0126] The relay UE can perform a Tracking Area Update (TAU) procedure on behalf of one or more remote UEs connected to it. It is assumed that the relay has up-to-date knowledge of the remote UEs communicating with it. Therefore, the remote UE does not necessarily need to perform a TAU directly with the MME. Instead, the relay UE can include the remote UE's identification when performing a periodic or normal TAU procedure. Since the TAU procedure is performed between the relay UE and the MME, the reception of the TAU acceptance message may not be transmitted to the remote UE(s). However, in some scenarios, the remote UE may require information from the TAU response from the MME. For example, if the MME rejects the TAU procedure, the remote UE may want to be notified of this fact, as the rejection may mean that the remote UE may have to take some action, such as reattaching to the network. PC5-S signaling with a new message type can be used to transmit such rejection scenarios to the remote UE. The PC5-S message may also contain a reason code / value indicating the reason for the rejection.
[0127] In addition, relay UEs can use the previously described NAS transport method to send normal TAU messages for individual remote UEs. This may occur, for example, when a particular UE needs to send a normal TAU to reconfigure network parameters (e.g., power saving mode (PSM) timer or UE capability changes).
[0128] If the following scenario occurs: a remote UE moves out of the coverage area of a relay UE it has been using and the remote UE is in idle mode, a TAU can be triggered by the remote UE. This TAU will be sent directly from the remote UE to the MME (e.g., using the cell's Uu), because by definition, the "remote" UE will no longer be connected to the relay UE. The purpose of this TAU message is to notify the network that the remote UE is no longer within the coverage area of the previously connected relay UE. The network can then directly (via the Uu interface) send all control signaling to the remote UE. This behavior can continue until the remote UE connects to the same or a different relay node. When the remote UE reconnects to the same or a different relay node, the network can then resume sending control messages via the relay node. The network receiving a TAU message via the relay node can be considered an indication that the network is sending Mobile Termination (MT) traffic (data and signaling) via the relay UE.
[0129] III. Conclusion
[0130] Although the features and elements are described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in computer programs, software, or firmware embedded in a computer-readable medium and executed by a computer or processor. Examples of non-transitory computer-readable media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, buffer memory, semiconductor storage devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM discs and digital multipurpose discs (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU 102, UE, terminal, base station, RNC, or any host computer.
[0131] Furthermore, in the above embodiments, references to processing platforms, computing systems, controllers, and other devices including processors are mentioned. These devices may include at least one central processing unit (“CPU”) and memory. According to the practice of those skilled in the art of computer programming, references to symbolic descriptions of actions and operations or instructions can be executed by various CPUs and memories. These actions and operations or instructions may be referred to as “executed,” “computer-executed,” or “CPU-executed.”
[0132] Those skilled in the art will understand that the operations or instructions described by the actions and symbols include the CPU's manipulation of electrical signals. The electrical system represents the identification of data bits, causing electrical signals to be transformed or restored, and maintaining the storage location of data bits in the memory system, thereby reconfiguring or otherwise altering the CPU's operation and other signal processing. Maintaining the storage location of data bits involves having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that exemplary embodiments are not limited to the platforms or CPUs described above, and other platforms and CPUs may support the provided methods.
[0133] Data bits can also be stored on computer-readable media, including disks, optical disks, and any other large CPU-readable storage system, whether volatile (e.g., random access memory (“RAM”)) or non-volatile (e.g., read-only memory (“ROM”)). The computer-readable media can include cooperative or interconnected computer-readable media that reside exclusively on the processor system or are distributed among multiple interconnected processing systems, which may be local to the processing system or remote. It is understood that representative implementations are not limited to the memories described above, and other platforms and memories may support the described methods.
[0134] In the illustrated embodiments, any of the operations, processes, etc., described herein can be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions can be executed by a processor of a mobile unit, network element, and / or any other computing device.
[0135] There is a distinction between hardware and software implementations in a system. The use of hardware or software is generally (but not always, as the choice between hardware and software can be critical in certain environments) a design choice that considers a trade-off between cost and efficiency. Various tools (e.g., hardware, software, and / or firmware) can influence the processes and / or systems and / or other technologies described herein, and the preferred tools can vary depending on the context of the deployed processes and / or systems and / or other technologies. For example, if the implementer determines that speed and accuracy are paramount, they may choose primarily hardware and / or firmware tools. If flexibility is paramount, they may choose primarily software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.
[0136] The foregoing detailed description has presented various implementations of the apparatus and / or process using block diagrams, flowcharts, and / or examples. Within the scope of one or more functions and / or operations contained in these block diagrams, flowcharts, and / or examples, those skilled in the art will understand that each function and / or operation within these block diagrams, flowcharts, or examples can be implemented individually and / or together in a wide range of hardware, software, or firmware, or substantially any combination thereof. Suitable processors include, for example, general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application-specific integrated circuits (ASICs), application-specific standard products (ASSPs); field-programmable gate array (FPGA) circuits, any other type of integrated circuit (IC), and / or state machines.
[0137] While features and elements are provided above in specific combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. This disclosure is not limited to the specific embodiments described herein, which are intended as examples of various aspects. Many modifications and variations can be made without departing from their essence and scope, as is known to those skilled in the art. Elements, actions, or instructions used in the description of this application should not be construed as critical or essential to the invention unless explicitly stated otherwise. In addition to the methods and apparatuses listed herein, those skilled in the art will recognize functionally equivalent methods and apparatuses within the scope of this disclosure based on the above description. These modifications and variations should also fall within the scope of the appended claims. This disclosure is defined solely by the appended claims, including their full equivalents. It should be understood that this disclosure is not limited to specific methods or systems.
[0138] It should also be understood that the terminology used herein is for describing particular implementations only and is not restrictive. The terms “station” and its abbreviation “STA”, “user equipment” and its abbreviation “UE” as used herein can refer to (i) a radio transmit and / or receive unit (WTRU), as described below; (ii) an implementation of any number of WTRUs, as described below; (iii) a device with wireless and / or wired capabilities (e.g., wired), configured with some or all of the structure and functions of a WTRU (e.g., as described above); (iii) a device with wireless and / or wired capabilities, configured with fewer than all the structure and functions of a WTRU, as described below; and / or (iv) others. Details of example WTRUs that can represent any UE described herein have been referenced above. Figures 1A to 1E Provided.
[0139] In some representative embodiments, portions of the subject matter described herein may be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, those skilled in the art will understand that some aspects of the embodiments disclosed herein, in whole or in part, may be equivalently implemented by integrated circuits as one or more computer programs running on one or more computers (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware, or substantially any combination of these, and that designing circuitry and / or writing code for such software and / or firmware according to this disclosure is known to those skilled in the art. Furthermore, those skilled in the art will understand that the mechanisms of the subject matter described herein can be distributed as various forms of program products, and that exemplary embodiments of the subject matter described herein are applicable regardless of the specific type of signal-bearing medium used to actually perform that distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media, such as floppy disks, hard disks, CDs, DVDs, digital tapes, computer memory, etc., and transmission media, such as digital and / or analog communication media (e.g., optical fibers, waveguides, wired communication links, wireless communication links, etc.).
[0140] The topics described herein sometimes show different components that are contained in or connected to different other components. It is understood that the architectures depicted are merely examples, and many other architectures that implement the same functionality can be implemented in practice. Conceptually, any arrangement of components that implement the same functionality is effectively “associated” to achieve the desired functionality. Therefore, any two components combined here to achieve a particular function can be considered “associated” with each other to achieve the desired functionality, regardless of the architecture or intermediate components. Similarly, any two associated components can also be considered “operationally connected” or “operationally coupled” to each other to achieve the desired functionality, and any two components that can be associated in this way can also be considered “operationally coupled” to each other to achieve the desired functionality. Specific examples of operationally coupled components include, but are not limited to, physically pairable and / or physically interactive components and / or wirelessly interactive components and / or logically interactive and / or logically interactive components.
[0141] Regarding the use of virtually any plural and / or singular terms herein, those skilled in the art can escape from plural to singular and / or from singular to plural as appropriate in context and / or application. For clarity, various singular / plural substitutions may be explicitly proposed herein.
[0142] Those skilled in the art will understand that the terminology used herein, and especially in the claims (e.g., the body of the claims), is generally “open-ended” (e.g., the term “comprising” should be understood as “including but not limited to,” the term “having” should be understood as “at least having,” the term “comprising” should be understood as “including but not limited to,” etc.). Those skilled in the art will also understand that if a claim describes a particular quantity, it will be explicitly stated in the claim, and without such a description, there is no such meaning. For example, the term “single” or similar language may be used to indicate only one item. To aid understanding, the following claims and / or the description herein may contain the use of the prepositional phrases “at least one” or “one or more” to introduce the claim description. However, the use of these phrases should not be construed as implying that a claim description introduced by the indefinite article “a” limits any particular claim containing such an introduced claim description to an embodiment containing only one such description, even if the same claim includes the prepositional phrases “one or more” or “at least one” and the indefinite article (e.g., “a”) (e.g., “a” should be understood as meaning “at least one” or “one or more”). The same applies to the use of definite articles used to introduce the claim description. Furthermore, even if a specific quantity described in the derived claims is explicitly stated, those skilled in the art will understand that such a description should be interpreted as indicating at least the quantity described (e.g., simply stating "two descriptions" without any other modifiers indicates at least two descriptions, or two or more descriptions). Additionally, in these instances where the convention of "at least one of A, B, and C" is used, this convention is generally understood by those skilled in the art (e.g., "the system has at least one of A, B, and C" can include, but is not limited to, the system having only A, only B, only C, A and B, A and C, B and C, and / or A, B, and C, etc.). In these instances where the convention of "at least one of A, B, or C" is used, this convention is generally understood by those skilled in the art (e.g., "the system has at least one of A, B, or C" can include, but is not limited to, the system having only A, only B, only C, A and B, A and C, B and C, and / or A, B, and C, etc.). Those skilled in the art will also understand that any substantially separating word and / or phrase indicating two or more alternatives, whether in the specification, claims, or drawings, should be understood to include the possibility of including one of the two items, either one or both. For example, the phrase "A or B" is understood to include the possibility of including "A" or "B" or "A" and "B". Furthermore, the term "any" as used herein, followed by a plurality of items and / or multiple items, is intended to include "any", "any combination", "any number", and / or "any combination of a plurality of items", either alone or in combination with other items and / or other kinds of items.Furthermore, the terms "set" or "group" as used herein are intended to include any number of items, including zero. Additionally, the term "quantity" as used herein is intended to include any number, including zero.
[0143] Furthermore, if the features or aspects of this disclosure are described in accordance with the Markush Group, those skilled in the art will understand that this disclosure is also described in accordance with any individual member or subgroup of members of the Markush Group.
[0144] Those skilled in the art will understand that, for any and all purposes, such as for providing a written description, all scopes disclosed herein also include any and all possible subscopes and combinations thereof. Any scope listed herein can be readily understood as sufficient to describe and implement the same scope divided into at least two, three, four, five, ten, etc., equal parts. As a non-limiting example, each scope described herein can be readily divided into a lower third, a middle third, and an upper third, etc. Those skilled in the art will also understand that all language such as “more than,” “at least,” “greater than,” “less than,” etc., includes the described numbers and scopes that can subsequently be divided into the aforementioned subscopes. Finally, those skilled in the art will understand that a scope includes each individual member. Thus, for example, a group and / or set with 1-3 cells refers to a group / set with 1, 2, or 3 cells. Similarly, a group / set with 1-5 cells refers to a group / set with 1, 2, 3, 4, or 5 cells, and so on.
[0145] Furthermore, the claims should not be construed as limiting to the provided order or elements unless the description has such an effect. Additionally, the use of the term "means for..." in any claim is intended to invoke 35 U.S.SC §112. The claim format of 6 or device + function, and any claim without the term "device for..." does not have this intention.
[0146] The software-associated processor can be used to implement radio frequency transceivers in a Wireless Transmit / Receive Unit (WTRU), User Equipment (UE), terminal, base station, Mobility Management Entity (MME), or Evolved Packet Core (EPC), or any host computer. The WTRU can incorporate hardware and / or software-implemented modules (including Software-Defined Radio (SDR)) and other components, such as cameras, video camera modules, video phones, walkie-talkies, vibration devices, speakers, microphones, television transceivers, hands-free headsets, and keyboards. Modules, FM radio units, Near Field Communication (NFC) modules, Liquid Crystal Display (LCD) units, Organic Light Emitting Diode (OLED) units, digital music players, media players, video game console modules, Internet browsers and / or any Wireless Local Area Network (WLAN) or Ultra Wideband (UWB) modules.
[0147] Although the invention has been described in relation to a communication system, it will be understood that the system can be implemented in software on a microprocessor / general-purpose computer (not shown). In some embodiments, the functionality of one or more of the various components can be implemented in software that controls the general-purpose computer.
[0148] Furthermore, although the invention has been shown and described with reference to specific embodiments, it is not intended to be limited to the details shown. Rather, various modifications to the details may be made within the scope of the claims without departing from the invention.
Claims
1. A method implemented by a first wireless transmit / receive unit (WTRU), the method comprising: A device-to-device (D2D) communication link is established between the first WTRU and the second WTRU, wherein the first WTRU acts as a relay for the second WTRU to the network; Receive a first D2D message from the second WTRU, the first D2D message including a Non-Access Stratum (NAS) message; Based on the receipt of the first D2D message, a message is forwarded to the network, the forwarded message including a NAS message from the second WTRU; A response message is received from the network in response to a message forwarded based on a first D2D message; as well as Based on the response message received from the network, a second D2D message is transmitted to the second WTRU, the second D2D message indicating response information related to the first D2D message.
2. The method according to claim 1, wherein, The response message is related to the Tracking Area Update (TAU) message.
3. The method according to claim 2, wherein, The response message is an out-of-coverage rejection based on the TAU request.
4. The method of claim 3, wherein the second D2D message instructs the second WTRU to reconnect to the network.
5. The method according to claim 1, wherein the first D2D message and the second D2D message correspond to corresponding PC5 messages.
6. The method of claim 1, wherein the first D2D message and the second D2D message correspond to corresponding sidelink messages.
7. The method according to claim 1, further comprising: Perform a D2D WTRU discovery process to discover the second WTRU.
8. The method of claim 1, wherein the message sent to the network includes an identifier of the second WTRU.
9. A first wireless transmit / receive unit (WTRU), the WTRU including a processor and a memory, the processor and memory being configured to: A device-to-device (D2D) communication link is established between the first WTRU and the second WTRU, wherein the first WTRU is configured to act as a relay for the second WTRU to the network; Receive a first D2D message from the second WTRU, the first D2D message including a Non-Access Stratum (NAS) message; Based on receiving the first D2D message, a message is forwarded to the network, the forwarded message including a NAS message from the second WTRU; A response message is received from the network in response to the forwarded message based on the first D2D message; as well as Based on the response message received from the network, a second D2D message is transmitted to the second WTRU, the second D2D message indicating response information related to the first D2D message.
10. The first WTRU of claim 9, wherein the response message is associated with a Tracking Area Update (TAU) message.
11. The first WTRU of claim 10, wherein the response message is an out-of-coverage rejection message and wherein the second D2D message indicates that the second WTRU will reconnect to the network.
12. The first WTRU according to claim 9, wherein the first D2D message and the second D2D message correspond to corresponding PC5 messages.
13. The first WTRU of claim 9, wherein the first D2D message and the second D2D message correspond to corresponding sidelink messages.
14. The first WTRU according to claim 9, further comprising: Perform a D2D WTRU discovery process to discover the second WTRU.
15. The first WTRU of claim 9, wherein the message sent to the network includes an identifier of the second WTRU.