Method for multi-hop relay in 5G network

By utilizing the PC5 link between the remote UE and the intermediate UE in the 5G network, the multi-hop relay chain is formed and maintained, and management problems in the prior art are solved, and more efficient network coverage and energy management are achieved.

CN120074618APending Publication Date: 2025-05-30INTERDIGITAL PATENT HOLDINGS INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510221195.0
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2019-05-01
Filing Date
2020-05-01
Publication Date
2025-05-30

AI Technical Summary

Technical Problem

The prior art is difficult to effectively form and manage multi-hop relay chains in 5G networks, especially when UEs exceed coverage, lack solutions for handover and distributed management.

Method used

Through the remote UE discovering and selecting intermediate UEs, establishing PC5 links, forming a multi-hop relay chain, and reorganizing the links in the intermediate UEs, selecting alternative UEs to replace the existing intermediate UEs, realizing distributed management.

Benefits of technology

It realizes efficient formation and maintenance of multi-hop relay chains in 5G networks, improves the energy efficiency and coverage of the system, and provides a flexible registration and connection management mechanism for UEs.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120074618A_ABST
    Figure CN120074618A_ABST
Patent Text Reader

Abstract

The present disclosure relates to a method for multi-hop relay in a 5G network. A method of multi-hop relay chain formation in a wireless communication network includes discovering, via a remote electronic device, one or more other electronic devices in a communication range of the remote electronic device; selecting one of the discovered electronic devices as a relay electronic device for communicating in the multi-hop relay chain; sending a request to establish a PC5 link via the remote electronic device after selecting the relay electronic device; and establishing a PC5 link with the remote electronic device to join or form a multi-hop relay chain within the wireless communication network.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] This application is a divisional application of a patent application with international application number PCT / US2020 / 031019 and national application number 202080029697.9, titled "Method for Multi-Hop Relay in 5G Networks", filed on May 1, 2020.

[0002] Citation of Related Applications

[0003] This application claims the benefit of U.S. Provisional Application No. 62 / 841,455, filed on May 1, 2019, the entire content of which is incorporated herein by reference. Technical Field

[0004] The present disclosure generally relates to wireless communication, and more particularly to wireless communication systems, apparatuses, methods, and computer-readable media related to multi-hop relay in 5G networks. Background Art

[0005] The "Background Art" description provided herein is for the purpose of generally presenting the context of the present disclosure. To the extent described in this Background Art section, the work of the currently named inventors, as well as aspects that may not constitute prior art at the time of filing this application, are neither expressly nor implicitly admitted to be prior art with respect to the present invention.

[0006] Currently, there are architectures and mechanisms for relaying multi-hop relays and incorporating them into 5G, aiming to help improve the energy efficiency and coverage of 5G systems. However, for 5G, there are many problems related to multi-hop relays. For example, current methods do not address how to form a multi-hop relay chain and to what extent the network manages or controls the formation of the multi-hop relay chain, especially when some UEs in the chain may be out of coverage. Additionally, for multi-hop relay chain maintenance, there are no solutions regarding how to switch affected UEs to a new or existing relay chain, and whether and how to give relay UEs a certain degree of freedom to manage the relay chain in a distributed manner through multi-hop relay chain formation and multi-hop relay chain maintenance. Thus, new methods are needed to solve these problems. Summary of the Invention

[0007] Exemplary embodiments of the present disclosure provide a method for forming a multi-hop relay chain in a wireless communication network, including discovering one or more other UEs within the communication range of a remote user equipment (UE) via the remote UE; selecting one of the discovered UEs as an intermediate UE for communication in the multi-hop relay chain; after selecting the intermediate UE, sending a request to establish a PC5 link via the remote UE; and establishing a PC5 link with the remote UE to join or form a multi-hop relay chain within the wireless communication network.

[0008] Exemplary embodiments of the present disclosure provide a method for registering a user equipment (UE) to enable multi-hop relay services in a wireless communication network, including sending a registration request message to the wireless communication network directly or via an intermediate UE, the registration request message requesting the network to enable multi-hop relay services; providing an indication of a role that the UE requests to perform in the multi-hop relay services to the network, the role being one of a remote UE and an intermediate UE; sending a first set of predetermined information about remote UE characteristics from the UE on the condition that the role of the UE will be a remote UE; and sending a second set of predetermined information about intermediate UE characteristics from the UE on the condition that the role of the UE will be an intermediate UE.

[0009] Exemplary embodiments of the present disclosure provide a method for maintaining a multi-hop relay chain in a wireless communication network, including reorganizing the multi-hop relay chain by an intermediate user equipment (UE), the reorganization including sending a PC5 link establishment message to include at least another intermediate UE in the multi-hop relay chain; and relaying information from a remote UE to the network via the at least another intermediate UE.

[0010] A method for maintaining a multi-hop relay chain in a wireless communication network, including when providing communication from a remote UE to a wireless communication network via a multi-hop relay chain, selecting an alternative user equipment (UE) to replace an existing intermediate UE, the selection including selecting from the remaining UEs in the multi-hop relay chain or UEs outside the multi-hop relay chain, wherein the selection includes selection by at least one of a core network entity, a base station, and the remaining UEs.

[0011] A method for registration management and connection management in a wireless communication network, including updating connection management and registration management parameters at a core network asset in response to a registration request for forming a new multi-hop relay chain or joining an existing multi-hop relay chain; sending a configuration update to an intermediate user equipment (UE); storing the connection management and registration management parameters by the intermediate UE; and sending the connection management and registration management parameters from the intermediate UE to other UEs in the new or existing multi-hop relay chain.

[0012] A method for assisting a remote UE with signal coverage farther than the UE in a wireless communication network to access relay services provided by the wireless communication network. The method includes: receiving a PC5 link establishment request message from the remote user equipment, determining whether there is a relay chain association for the remote UE, including by determining whether to accept the remote UE to join the relay chain or determining whether to assume the role of a relay UE for the requesting remote UE. The method includes sending a PC5 link establishment response message to the remote UE based on the relay chain association determination.

[0013] A method includes communicating with a relay UE to assist a remote UE in accessing a relay service, the relay service enabling access to other services provided by a wireless communication network. The method further includes receiving a registration request message having information sourced from a PC5 link establishment request message sent by the remote UE, the registration request message including remote UE new link information and remote UE registration information, the remote UE new link information for requesting establishment of a new relay link for use by the remote UE, and the remote UE registration information for requesting registration of the remote UE with the wireless communication network. The method further includes processing the registration procedure of the remote UE based on the remote UE registration information, and processing the formation procedure of the new relay link of the remote UE based on the remote UE new link information, including obtaining a relay link configuration, the relay link configuration including information identifying the roles of the UE and the remote UE, and obtaining service application information of the new relay link. The method further includes sending relay link configuration information to the UE, the relay link configuration information including the accepted roles of the UE and the remote UE, including a multi-hop relay policy obtained via a non-access stratum (NAS) connection.

[0014] A method for a remote UE to obtain access to a relay service provided by a wireless communication network. The method includes: discovering one or more potential relay UEs capable of providing access to a relay link service, selecting one of the one or more potential relay UEs as a target relay UE, sending a join relay link request message to the target relay UE, and receiving, via a non-access stratum (NAS) connection, a join relay link response from the target relay UE sourced from the wireless communication network.

[0015] This Summary is provided to introduce a selection of embodiments described herein in a simplified form. These embodiments, along with further embodiments, will be described in more detail hereinafter. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Additionally, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.

[0016] In this specification, the term "UE" may be interchanged with the broader term "electronic device" and vice versa. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The scope of the present disclosure can be better understood from the following detailed description of exemplary embodiments when read in conjunction with the accompanying drawings, in which:

[0018] Figure 1A is a system diagram illustrating an example 3rd Generation Partnership Project (3GPP) architecture;

[0019] Figure 1B is a system diagram illustrating an example of a radio access network (RAN) architecture and a core network architecture;

[0020] Figure 1C is a system diagram illustrating an example of a radio access network (RAN) architecture and a core network architecture;

[0021] Figure 1D is a system diagram illustrating an example of a radio access network (RAN) architecture and a core network architecture;

[0022] Figure 1E is a system diagram illustrating an example of a 3GPP architecture;

[0023] Figure 1F is a system diagram of an example device or apparatus configured for wireless communication;

[0024] Figure 1G is a system diagram illustrating an example of a computing system used in a communication network;

[0025] Figure 2 illustrates a non-roaming 5G system architecture including a service-based interface in the control plane according to an exemplary embodiment;

[0026] Figure 3 illustrates a non-roaming 5G system architecture including reference point representations showing how various network functions interact according to an exemplary embodiment;

[0027] Figure 4 illustrates NAS transmissions for SM, SMS, UE policies, and LCS. It should be noted that, according to an exemplary embodiment, the mobility management and session management functions can be separated;

[0028] Figure 5 illustrates an architecture model of LTE ProSe UE-to-network relay according to an exemplary embodiment;

[0029] Figure 6 illustrates a user plane protocol stack for LTE ProSe UE-to-network relay which, according to an exemplary embodiment, applies layer 3 forwarding;

[0030] Figure 7 illustrates a process for direct communication via relay for 3GPP LTE ProSe according to an exemplary embodiment;

[0031] Figure 8 illustrates a control plane protocol stack for enhanced UE-to-network relay according to an exemplary embodiment;

[0032] Figure 9Illustrate a user plane protocol stack for layer 2 relay according to an exemplary embodiment;

[0033] Figure 10 Illustrate the entire process of the LTE ProSe discovery model A according to an exemplary embodiment;

[0034] Figure 11 Illustrate the entire process of the LTE ProSe discovery model B according to an exemplary embodiment;

[0035] Figure 12( Figure 12A - 12C ) Illustrate a general registration process in which multi-hop relay can be enabled according to an exemplary embodiment;

[0036] Figure 13 Illustrate a process in which registration can be performed first according to an exemplary embodiment;

[0037] Figure 14 Illustrate a process in which a PC5 link is established first according to an exemplary embodiment;

[0038] Figure 15 Illustrate a process of joining an existing relay chain according to an exemplary embodiment;

[0039] Figure 16( Figure 16A - 16B ) Illustrate a process of network-assisted relay chain formation according to an exemplary embodiment;

[0040] Figure 17 Illustrate a process of selecting a new relay UE according to an exemplary embodiment;

[0041] Figure 18 Illustrate a process in which the AMF sets RM / CM configurations for UEs in a relay chain according to an exemplary embodiment; and

[0042] Figure 19 Illustrate an exemplary user interface according to an exemplary embodiment.

[0043] According to the detailed description provided below, other applicable fields of the present disclosure will become clear. It should be understood that the detailed description of the exemplary embodiments is only for illustration, and thus does not necessarily intend to limit the scope of the present disclosure. Detailed Description

[0044] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, core transport networks, and service capabilities - including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include Wideband Code Division Multiple Access (WCDMA) (commonly known as 3G), Long Term Evolution (LTE) (commonly known as 4G), LTE-Advanced standards, and New Radio (NR) also known as "5G". The development of 3GPP NR standards is expected to continue and include the definition of the next generation radio access technology (New RAT), which is expected to include the provision of new flexible radio access below 7 GHz, as well as the provision of new ultra-mobile broadband radio access above 7 GHz. The flexible radio access is expected to consist of new non-backward compatible radio access in new spectrum below 7 GHz and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide range of 3GPP NR use cases with different requirements. The ultra-mobile broadband is expected to include the cmWave and mmWave spectrums, which will provide opportunities for ultra-mobile broadband access for, e.g., indoor applications and hotspots. In particular, the ultra-mobile broadband is expected to share a common design framework with the flexible radio access below 7 GHz, with design optimizations specific to cmWave and mmWave.

[0045] 3GPP has identified various use cases that are expected to be supported by New Radio (NR), resulting in a wide variety of user experience requirements for data rate, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (eMBB), ultra-reliable low latency communication (URLLC), massive machine type communication (mMTC), network operations (e.g., network slicing, routing, migration, and interworking, energy savings), and enhanced vehicle-to-everything (eV2X) communication, which can include any one of vehicle-to-vehicle communication (V2V), vehicle-to-infrastructure communication (V2I), vehicle-to-network communication (V2N), vehicle-to-pedestrian communication (V2P), and communication of a vehicle with other entities. Just a few examples, specific services and applications in these categories include surveillance and sensing networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud office, first responder connectivity, automotive emergency call, disaster alert, real-time gaming, multi-person video call, autonomous driving, augmented reality, tactile internet, virtual reality, home automation, robotics, and aerial drones. All of these use cases and others are envisioned in this document.

[0046] The following is a list of acronyms related to service levels and core network technologies that may appear in the following description. Unless otherwise noted, the acronyms used in this document refer to the corresponding terms listed below.

[0047] Acronyms

[0048]

[0049]

[0050]

[0051]

[0052]

[0053] Example Communication Systems and Networks

[0054] Figure 1A FIG. illustrates an example communication system 100 in which the systems, methods, and devices described and claimed herein may be used. The communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g, generally or collectively referred to as one or more WTRUs 102. The communication system 100 may include radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b, core networks 106 / 107 / 109, public switched telephone networks (PSTNs) 108, the Internet 110, other networks 112, and network services 113. The network services 113 may include, for example, V2X servers, V2X functions, proximity services (ProSe) servers, ProSe functions, IoT services, video streaming, and / or edge computing, etc.

[0055] The embodiments disclosed herein may be used with any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102 may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. In Figure 1A the example of, each of the WTRUs 102 in Figure 1A - 1Eis depicted as a handheld wireless communication device. It should be understood that for the various use cases envisioned for wireless communication, each WTRU may include, or be included within, any type of device or apparatus configured to transmit and / or receive wireless signals. By way of example only, such device or apparatus includes user equipment (UE), mobile station, fixed or mobile subscriber unit, pager, cellular telephone, personal digital assistant (PDA), smart telephone, laptop computer, tablet computer, netbook, notebook computer, personal computer, wireless sensor, consumer electronics, wearable device (such as a smartwatch or smart clothing), medical or e-health device, robot, industrial equipment, drone, vehicle such as an automobile, bus or truck, train, or airplane, etc.

[0056] The communication system 100 may also include base stations 114a and 114b. In Figure 1A the example shown, each of base stations 114a and 114b is depicted as a single element. In reality, base stations 114a and 114b may include any number of interconnected base stations and / or network elements. Base station 114a may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks such as core network 106 / 107 / 109, Internet 110, network services 113, and / or other networks 112. Similarly, base station 114b may be any type of device configured to wired and / or wirelessly interface with at least one of remote radio heads (RRHs) 118a, 118b, transmit and receive points (TRPs) 119a, 119b, and / or roadside units (RSUs) 120a and 120b to facilitate access to one or more communication networks such as core network 106 / 107 / 109, Internet 110, other networks 112, and / or network services 113. Remote radio heads (RRHs) 118a, 118b may be any type of device configured to wirelessly interface with at least one of WTRUs 102 (e.g., WTRU 102c) to facilitate access to one or more communication networks such as core network 106 / 107 / 109, Internet 110, network services 113, and / or other networks 112.

[0057] TRP 119a and 119b can be any type of device configured to make a wireless interface connection with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, network services 113, and / or other networks 112. The roadside units (RSUs) 120a and 120b can be any type of device configured to make a wireless interface connection with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, other networks 112, and / or network services 113. By way of example, the base stations 114a, 114b can be base transceiver stations (BTSs), Node-Bs, eNode Bs, home Node Bs, home eNode Bs, next generation Node-Bs (gNode Bs), satellites, site controllers, access points (APs), wireless routers, etc.

[0058] Base station 114a can be part of a radio access network (RAN) 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Similarly, base station 114b can be part of a RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as BSCs, RNCs, relay nodes, etc. Base station 114a can be configured to transmit and / or receive wireless signals within a specific geographical area, which may be referred to as a cell (not shown). Similarly, base station 114b can be configured to transmit and / or receive wired and / or wireless signals within a specific geographical area, which may be referred to as a cell (not shown). A cell can be further divided into cell sectors. For example, the cell associated with base station 114a can be divided into three sectors. Thus, for example, base station 114a can include three transceivers, e.g., one transceiver for each sector of the cell. Base station 114a can employ multiple input multiple output (MIMO) technology, and thus, for example, multiple transceivers can be used for each sector of the cell.

[0059] Base station 114a can communicate with one or more of wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and 102g via air interfaces 115 / 116 / 117, and the air interfaces 115 / 116 / 117 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). Any suitable radio access technology (RAT) can be used to establish the air interfaces 115 / 116 / 117.

[0060] Base station 114b can communicate with one or more of remote radio heads (RRHs) 118a and 118b, transmit receive points (TRPs) 119a and 119b, and / or radio signal units (RSUs) 120a and 120b via wired or air interfaces 115b / 116b / 117b, and the air interfaces 115b / 116b / 117b can be any suitable wired (e.g., cable, optical fiber, etc.) or wireless communication link (e.g., RF, microwave, IR, UV, visible light, cmWave, mmWave, etc.). Any suitable RAT can be used to establish the air interfaces 115b / 116b / 117b.

[0061] RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a, 120b can communicate with one or more of WTRUs 102c, 102d, 102e, 102f via air interfaces 115c / 116c / 117c, and the air interfaces 115c / 116c / 117c can be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet (UV), visible light, cmWave, mmWave, etc.). Any suitable RAT can be used to establish the air interfaces 115c / 116c / 117c.

[0062] WTRUs 102 can communicate with each other via direct air interfaces 115d / 116d / 117d, such as sidelink communication, and the air interfaces 115d / 116d / 117d can be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet (UV), visible light, cmWave, mmWave, etc.). Any suitable RAT can be used to establish the air interfaces 115d / 116d / 117d.

[0063] The communication system 100 can be a multi-access system and can adopt one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, or the RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a and 120b in RAN 103b / 104b / 105b and the WTRUs 102c, 102d, 102e and 102f can implement radio technologies, such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use Wideband CDMA (WCDMA) to establish the air interfaces 115 / 116 / 117 and / or 115c / 116c / 117c respectively. WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed Uplink Packet Access (HSUPA).

[0064] The base station 114a in RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c and 102g, or the RRHs 118a and 118b, TRPs 119a and 119b and / or RSUs 120a and 120b in RAN 103b / 104b / 105b and the WTRUs 102c, 102d can implement radio technologies, such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can use, for example, Long-Term Evolution (LTE) and / or LTE-Advanced (LTE-A) to establish the air interfaces 115 / 116 / 117 or 115c / 116c / 117c respectively. The air interfaces 115 / 116 / 117 or 115c / 116c / 117c can implement 3GPP NR technology. LTE and LTE-A technologies can include LTE D2D and / or V2X technologies and interfaces (such as sidelink communication, etc.). Similarly, 3GPP NR technology can include NR V2X technologies and interfaces (such as sidelink communication, etc.).

[0065] The base station 114a in RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, and 102g, or the RRHs 118a and 118b, RPs 119a and 119b, and / or RSUs 120a and 120b in RAN 103b / 104b / 105b and the WTRUs 102c, 102d, 102e, and 102f can implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0066] Figure 1A The base station 114c therein can be, for example, a wireless router, a home Node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area such as a commercial location, a home, a vehicle, a train, an airplane, a satellite, a factory, a campus, etc. The base station 114c and the WTRU 102 (e.g., the WTRU 102e) can implement a radio technology such as IEEE802.11 to establish a wireless local area network (WLAN). Similarly, the base station 114c and the WTRU 102 (e.g., the WTRU 102d) can implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). The base station 114c and the WTRU 102 (e.g., the WTRU 102e) can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a pico cell or a femto cell. As Figure 1A shown, the base station 114c can have a direct connection to the Internet 110. Thus, it may not be required for the base station 114c to access the Internet 110 via the core network 106 / 107 / 109.

[0067] RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b may communicate with core networks 106 / 107 / 109, which may be any type of network configured to provide voice, data, messaging, authorization and authentication, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102. For example, core networks 106 / 107 / 109 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication.

[0068] Although not shown in Figure 1A RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b and / or core networks 106 / 107 / 109 may communicate directly or indirectly with other RANs that employ the same RAT as RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b that may utilize E-UTRA radio technology, core networks 106 / 107 / 109 may also communicate with another RAN (not shown) that employs GSM or NR radio technology.

[0069] Core networks 106 / 107 / 109 may also serve as gateways for the WTRUs 102 to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides Plain Old Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols such as the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) in the TCP / IP protocol suite. Other networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include any type of packet data network (e.g., IEEE 802.3 Ethernet) or another core network connected to one or more RANs, where the one or more RANs may employ the same RAT as RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b or a different RAT.

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

[0071] Although not shown in Figure 1A a user equipment may establish a wired connection to a gateway. The gateway may be a residential gateway (RG). The RG may provide connectivity to the core network 106 / 107 / 109. Many of the embodiments included herein may equally apply to a UE that is a WTRU and a UE that uses a wired connection to connect to the network. For example, the concepts applied to the wireless interfaces 115, 116, 117, and 115c / 116c / 117c may equally apply to a wired connection.

[0072] Figure 1B is a system diagram of an example RAN 103 and core network 106. As described above, the RAN 103 may employ UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also communicate with the core network 106. As Figure 1B shown in, the RAN 103 may include Node - Bs 140a, 140b, and 140c, and the Node - Bs 140a, 140b, and 140c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 115. The Node - Bs 140a, 140b, and 140c may each be associated with a specific cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. The RAN 103 may include any number of Node - Bs and radio network controllers (RNCs).

[0073] As Figure 1BAs shown, Node-Bs 140a, 140b can communicate with RNC 142a. Additionally, Node-B 140c can communicate with RNC 142b. Node-Bs 140a, 140b, and 140c can communicate with the respective RNCs 142a and 142b via the Iub interface. RNCs 142a and 142b can communicate with each other via the Iur interface. Each of RNCs 142a and 142b can be configured to control the respective Node-Bs 140a, 140b, and 140c to which it is connected. Additionally, each of RNCs 142a and 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0074] Figure 1B The core network 106 shown in [Figure] can 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 above elements is depicted as part of the core network 106, any of these elements can be owned and / or operated by an entity other than the core network operator.

[0075] The RNC 142a in the RAN 103 can be connected to the MSC 146 in the core network 106 via the IuCS interface. The MSC 146 can be connected to the MGW 144. The MSC 146 and the MGW 144 can provide the WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as the PSTN 108) to facilitate communication between the WTRUs 102a, 102b, and 102c and traditional landline communication devices.

[0076] The RNC 142a in the RAN 103 can also be connected to the SGSN 148 in the core network 106 via the IuPS interface. The SGSN 148 can be connected to the GGSN 150. The SGSN 148 and the GGSN 150 can provide the WTRUs 102a, 102b, and 102c with access to a packet-switched network (such as the Internet 110) to facilitate communication between the WTRUs 102a, 102b, and 102c and IP-capable devices.

[0077] The core network 106 can also be connected to other networks 112, which can include other wired or wireless networks owned and / or operated by other service providers.

[0078] Figure 1CIt is a system diagram of the exemplary RAN 104 and the core network 107. As described above, the RAN 104 can communicate with the WTRUs 102a, 102b, and 102c via the air interface 116 using the E-UTRA radio technology. The RAN 104 can also communicate with the core network 107.

[0079] The RAN 104 can include eNode-Bs 160a, 160b, and 160c. The RAN 104 can include any number of eNode-Bs. The eNode-Bs 160a, 160b, and 160c can each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c via the air interface 116. For example, the eNode-Bs 160a, 160b, and 160c can implement MIMO technology. Thus, the eNode-B 160a, for example, can use multiple antennas to transmit wireless signals to and receive wireless signals from the WTRU 102a.

[0080] Each of the eNode-Bs 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and / or downlink, etc. As Figure 1C shown, the eNode-Bs 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0081] Figure 1C The core network 107 shown can include a Mobility Management Entity (MME) gateway 162, a Serving Gateway (S-GW) 164, and a Packet Data Network (PDN) gateway (P-GW) 166. Although each of the above elements is depicted as part of the core network 107, any of these elements can be owned and / or operated by an entity other than the core network operator.

[0082] The MME 162 can be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via the S1 interface and can serve as a control node. For example, the MME 162 can be responsible for authenticating users of the WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of the WTRUs 102a, 102b, and 102c, etc. The MME 162 can also provide control plane functions for handover between the RAN 104 and other RANs (not shown) using other radio technologies such as GSM or WCDMA.

[0083] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via the S1 interface. The serving gateway 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, and 102c. The serving gateway 164 may also perform other functions such as anchoring the user plane during handovers between eNode Bs, triggering paging when downlink data is available for the WTRUs 102a, 102b, and 102c, managing and storing the context of the WTRUs 102a, 102b, and 102c, etc.

[0084] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, and 102c with access to a packet-switched network (such as the Internet 110) to facilitate communication between the WTRUs 102a, 102b, 102c and IP-capable devices.

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

[0086] Figure 1D is a system diagram of an example RAN 105 and core network 109. The RAN 105 may communicate with the WTRUs 102a and 102b via the air interface 117 using NR radio technology. The RAN 105 may also communicate with the core network 109. The Non-3GPP Interworking Function (N3IWF) 199 may communicate with the WTRU 102c via the air interface 198 using non-3GPP radio technology. The N3IWF 199 may also communicate with the core network 109.

[0087] The RAN 105 may include gNode-Bs 180a and 180b. The RAN 105 may include any number of gNode-Bs. The gNode-Bs 180a and 180b may each include one or more transceivers for communicating with the WTRUs 102a and 102b via the air interface 117. When using integrated access and backhaul connections, the same air interface may be used between the WTRU and the gNode-B, and it may be the core network 109 via one or more gNBs. The gNode-Bs 180a and 180b may implement MIMO, MU-MIMO, and / or digital beamforming techniques. Thus, the gNode-B 180a, for example, may use multiple antennas to transmit wireless signals to the WTRU 102a and receive wireless signals from the WTRU 102a. It should be appreciated that the RAN 105 may employ other types of base stations, such as eNode-Bs. It should also be appreciated that the RAN 105 may employ more than one type of base station. For example, the RAN may employ eNode-Bs and gNode-Bs.

[0088] The non-3GPP interworking function (N3IWF) 199 may include non-3GPP access points 180c. The N3IWF 199 may include any number of non-3GPP access points. The non-3GPP access points 180c may include one or more transceivers for communicating with the WTRU 102c via the air interface 198. The non-3GPP access points 180c may communicate with the WTRU 102c via the air interface 198 using the 802.11 protocol.

[0089] Each of the gNode-Bs 180a and 180b may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink or downlink, etc. As Figure 1D shown, the gNode-Bs 180a and 180b may communicate with each other via the Xn interface, for example.

[0090] Figure 1D The core network 109 shown may be a 5G core network (5GC). The core network 109 may provide numerous communication services to customers interconnected via the radio access network. The core network 109 includes multiple entities that perform the functions of the core network. The term "core network entity" or "network function" as used herein refers to any entity that performs one or more functions of the core network. It should be understood that such core network entities may be logical entities implemented in the form of computer-executable instructions (software) stored in a device or computer system configured for wireless and / or network communication, such as Figure 1Gin the memory of the system 90) shown in the figure and executed on its processor.

[0091] In Figure 1D the example of, the 5G core network 109 may include an access and mobility management function (AMF) 172, a session management function (SMF) 174, user plane functions (UPF) 176a and 176b, a user data management function (UDM) 197, an authentication server function (AUSF) 190, a network exposure function (NEF) 196, a policy control function (PCF) 184, a non-3GPP interworking function (N3IWF) 199, and a user data repository (UDR) 178. Although each of the above elements is depicted as part of the 5G core network 109, any of these elements may be owned and / or operated by an entity other than the core network operator. It should also be appreciated that the 5G core network may not be composed of all of these elements, may be composed of additional elements, and may be composed of multiple instances of each of these elements. Figure 1D The figure illustrates that network functions are directly interconnected, but it should be appreciated that they may communicate via a routing proxy (such as a diameter routing proxy) or a message bus.

[0092] In Figure 1D the example of, the connectivity between network functions is achieved via a set of interfaces or reference points. Network functions may be modeled, described, or implemented as a set of services that are invoked or called by other network functions or services. The invocation of network function services may be achieved via direct connections between network functions, exchanges of messages on a message bus, invocation of software functions, etc.

[0093] The AMF 172 may be connected to the RAN 105 via the N2 interface and may act as a control node. For example, the AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, and access authorization. The AMF may be responsible for forwarding user plane tunnel configuration information to the RAN 105 via the N2 interface. The AMF 172 may receive user plane tunnel configuration information from the SMF via the N11 interface. The AMF 172 may typically route and forward NAS packets to and from the WTRU 102a, 102b, and 102c via the N1 interface. The N1 interface is not shown in Figure 1D the figure.

[0094] The Session Management Function (SMF) 174 can be connected to the AMF 172 via the N11 interface. Similarly, the SMF can be connected to the Policy Control Function (PCF) 184 via the N7 interface and to the User Plane Function (UPF) 176a and 176b via the N4 interface. The SMF 174 can act as a control node. For example, the SMF 174 can be responsible for session management, IP address allocation for the WTRUs 102a, 102b, and 102c, management and configuration of traffic steering rules in the UPF 176a and UPF 176b, and generation of downlink data notifications to the AMF 172.

[0095] The UPF 176a and UPF 176b can provide the WTRUs 102a, 102b, and 102c with access to a Packet Data Network (PDN) (such as the Internet 110) to facilitate communication between the WTRUs 102a, 102b, and 102c and other devices. The UPF 176a and UPF 176b can also provide the WTRUs 102a, 102b, and 102c with access to other types of packet data networks. For example, the other network 112 can be Ethernet or any type of network that exchanges data packets. The UPF 176a and UPF 176b can receive traffic steering rules from the SMF 174 via the N4 interface. The UPF 176a and UPF 176b can provide access to the packet data network by connecting to the packet data network with the N6 interface or by interconnecting with each other or connecting to other UPFs via the N9 interface. In addition to providing access to the packet data network, the UPF 176 can also be responsible for packet routing and forwarding, policy rule enforcement, quality of service handling for user plane traffic, and downlink packet buffering.

[0096] The AMF 172 can also be connected to the N3IWF 199 via the N2 interface, for example. The N3IWF facilitates a connection between, for example, the WTRU 102c and the 5G core network 170 via a radio interface technology not defined by 3GPP. The AMF can interact with the N3IWF 199 in the same or a similar manner as it interacts with the RAN 105.

[0097] The PCF 184 can be connected to the SMF 174 via the N7 interface, to the AMF 172 via the N15 interface, and to the Application Function (AF) 188 via the N5 interface. The N15 and N5 interfaces are not in Figure 1DShown in. The PCF 184 can provide policy rules to control plane nodes such as the AMF 172 and the SMF 174, thereby allowing the control plane nodes to enforce these rules. The PCF 184 can send policies to the AMF 172 for the WTRUs 102a, 102b, and 102c, such that the AMF can deliver the policies to the WTRUs 102a, 102b, and 102c via the N1 interface. The policies can then be enforced or applied at the WTRUs 102a, 102b, and 102c.

[0098] The UDR 178 can act as a repository for authentication credentials and subscription information. The UDR can be connected to network functions such that the network functions can add data to the repository, read data from the repository, and modify data in the repository. For example, the UDR 178 can be connected to the PCF 184 via the N36 interface. Similarly, the UDR 178 can be connected to the NEF 196 via the N37 interface, and the UDR 178 can be connected to the UDM 197 via the N35 interface.

[0099] The UDM 197 can act as an interface between the UDR 178 and other network functions. The UDM 197 can authorize network functions to access the UDR 178. For example, the UDM 197 can be connected to the AMF 172 via the N8 interface, and the UDM 197 can be connected to the SMF 174 via the N10 interface. Similarly, the UDM 197 can be connected to the AUSF 190 via the N13 interface. The UDR 178 and the UDM 197 can be tightly integrated.

[0100] The AUSF 190 performs authentication-related operations, is connected to the UDM 178 via the N13 interface, and is connected to the AMF 172 via the N12 interface.

[0101] The NEF 196 opens up the capabilities and services in the 5G core network 109 to the application function (AF) 188. The opening can occur on the N33 API interface. The NEF can be connected to the AF 188 via the N33 interface, and it can be connected to other network functions in order to open up the capabilities and services of the 5G core network 109.

[0102] The application function 188 can interact with network functions in the 5G core network 109. The interaction between the application function 188 and the network functions can occur via a direct interface or can occur via the NEF 196. The application function 188 can be considered part of the 5G core network 109, or can be outside the 5G core network 109 and be deployed by an enterprise having a business relationship with the mobile network operator.

[0103] Network slicing is a mechanism that can be used by mobile network operators to support one or more "virtual" core networks behind the operator's air interface. This involves "slicing" the core network into one or more virtual networks to support different RANs or different service types operating across a single RAN. Network slicing enables operators to create customized networks in order to provide optimized solutions for different market scenarios that require diverse requirements in terms of, for example, functionality, performance, and isolation.

[0104] 3GPP designed the 5G core network to support network slicing. Network slicing is a good tool that network operators can use to support a wide variety of 5G use cases (such as massive IoT, critical communications, V2X, and enhanced mobile broadband) that require very diverse and sometimes extreme requirements. Without using network slicing technology, when each use case has its own specific set of performance, scalability, and availability requirements, it is possible that the network architecture is not flexible and scalable enough to effectively support the broader use case requirements. In addition, the introduction of new network services should be made more efficient.

[0105] See again Figure 1D , in a network slicing scenario, the WTRU 102a, 102b, or 102c can be connected to the AMF 172 via the N1 interface. The AMF 172 can logically be part of one or more slices. The AMF 172 can coordinate the connection or communication of the WTRU 102a, 102b, or 102c with one or more UPFs 176a and 176b, the SMF 174, and other network functions. Each of the UPFs 176a and 176b, the SMF 174, and other network functions can be part of the same slice or different slices. When they are part of different slices, they can be isolated from each other in terms of the different computing resources, security credentials, etc. that they can utilize.

[0106] The core network 109 can facilitate communication with other networks. For example, the core network 109 can include an IP gateway (such as an IP multimedia subsystem (IMS) server) that serves as an interface between the 5G core network 109 and the PSTN 108, or can communicate with the IP gateway. For example, the core network 109 can include a short message service (SMS) service center that facilitates communication via the short message service, or can communicate with the short message service (SMS) service center. For example, the 5G core network 109 can facilitate the exchange of non-IP data packets between the WTRU 102a, 102b, and 102c and a server or application function 188. Additionally, the core network 170 can provide the WTRU 102a, 102b, and 102c with access to a network 112, which can include other wired or wireless networks owned or operated by other service providers.

[0107] The core network entities described herein and illustrated in Figure 1A , 1C , Figures 1D and 1E are identified using the names given to these entities in certain existing 3GPP specifications. However, it should be understood that in the future, these entities and functions may be identified by other names, and in future specifications published by 3GPP (including future 3GPP NR specifications), certain entities or functions may be combined. Thus, the specific network entities and functions described and illustrated in Figure 1A , 1B , 1C, 1D and 1E are provided only as examples, and it should be understood that the subject matter disclosed and claimed herein may be implemented or realized in any similar communication system (whether currently defined or defined in the future).

[0108] Figure 1E FIG. 111 illustrates an example communication system in which the systems, methods, and devices described herein may be used. The communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, a base station gNB 121, a V2X server 124, and roadside units (RSUs) 123a and 123b. In practice, the concepts presented herein may be applied to any number of WTRUs, base stations gNB, V2X networks, and / or other network elements. One or several or all of the WTRUs A, B, C, D, E, and F may be outside the coverage area 122 of the access network. WTRUs A, B, and C form a V2X group, where WTRU A may be the group leader and WTRUs B and C are group members.

[0109] WTRUs A, B, C, D, E, F may communicate with each other via the gNB 121 over the Uu interface 129b if they are within the coverage area of the access network (in Figure 1E , only B and F are shown within the network coverage area). WTRUs A, B, C, D, E, F may communicate directly with each other via sidelink (PC5 or NR PC5) interfaces 125a, 125b, 128 if they are within or outside the coverage area of the access network (e.g., in Figure 1E , WTRUs A, B, C, D, E, F may communicate with each other, and A, C, D, and E are shown outside the network coverage area).

[0110] WTRUs A, B, C, D, E, and F may communicate with RSU 123a or 123b via vehicle-to-network (V2N) 126 or sidelink interface 125b. WTRUs A, B, C, D, E, and F may communicate with V2X server 124 via vehicle-to-infrastructure (V2I) interface 127. WTRUs A, B, C, D, E, and F may communicate with another UE via vehicle-to-pedestrian (V2P) interface 128.

[0111] Figure 1F is a block diagram of an example device or apparatus WTRU 102 that may be configured for wireless communication and operation according to the systems, methods, and devices described herein (such as Figure 1A , 1B , 1C, 1D, or 1E of WTRU 102). As Figure 1F shown, example WTRU 102 may include a processor 118, a transceiver 120, transmit / receive elements 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripheral devices 138. WTRU 102 may include any sub-combination of the above elements. Additionally, base stations 114a and 114b and / or nodes that base stations 114a and 114b may represent, such as but not limited to, a base transceiver station (BTS), Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, a next-generation node-B (gNode-B), and a proxy node, etc., may include Figure 1F some or all of the elements depicted and described herein.

[0112] Processor 118 may be a general-purpose processor, a dedicated 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), a state machine, etc. Processor 118 may 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 may be coupled to transceiver 120, and transceiver 120 may be coupled to transmit / receive elements 122. Although Figure 1F processor 118 and transceiver 120 are depicted as separate components, processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0113] The transmit / receive element 122 of the UE may be configured to transmit signals to a base station (e.g., Figure 1A base station 114a) via the air interface 115 / 116 / 117 or receive signals from a base station (e.g., Figure 1A base station 114a), or transmit signals to another UE or receive signals from another UE via the air interface 115d / 116d / 117d. For example, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. The transmit / receive element 122 may be, for example, a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. The transmit / receive element 122 may be configured to transmit and receive both RF signals and optical signals. The transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals and wired signals.

[0114] In addition, although the transmit / receive element 122 is depicted as a single element in Figure 1F , the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the air interface 115 / 116 / 117.

[0115] The transceiver 120 may be configured to modulate the signals to be transmitted by the transmit / receive element 122 and demodulate the signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11 or NR and E-UTRA), or communicate via multiple beams to different RRHs, TRPs, RSUs, or nodes using the same RAT.

[0116] The processor 118 of the WTRU 102 may be coupled to the speaker / microphone 124, keypad 126, and / or the display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data from them. The processor 118 may also output user data to the speaker / microphone 124, keypad 126, and / or the display / touchpad / indicator 128. Additionally, the processor 118 may access information from any type of suitable memory (such as the non-removable memory 130 and / or the removable memory 132), and store data therein. The non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. The processor 118 may access information from a memory that is not physically located in the WTRU 102 (such as a memory hosted on a server in the cloud or an edge computing platform or a home computer (not shown)), and store data therein.

[0117] The processor 118 may obtain power from the power supply 134, and may be configured to distribute power to other components in the WTRU 102, and / or control the power to other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry batteries, solar cells, fuel cells, etc.

[0118] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to, or instead of, the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) via the air interface 115 / 116 / 117, and / or determine its location based on the timing of signals received from two or more nearby base stations. The WTRU 102 may obtain location information by any suitable location determination method.

[0119] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, modules, FM radio units, digital music players, media players, video game player modules, Internet browsers, etc.

[0120] The WTRU 102 may be included in other devices or apparatuses, such as sensors, consumer electronics, wearable devices such as smart watches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, vehicles such as cars, trucks, trains, or airplanes. The WTRU 102 may be connected to other components, modules, or systems of such devices or apparatuses via one or more interconnect interfaces, such as an interconnect interface that may include one of the peripheral devices 138.

[0121] Figure 1G is a block diagram of an example computing system 90, which may include Figure 1A , 1C , 1D and 1E, such as certain nodes or functional entities in the RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110, other networks 112 or network services 113. The computing system 90 may include a computer or a server and may be primarily controlled by computer-readable instructions, which may be in the form of software, regardless of where or how such software is stored or accessed. Such computer-readable instructions may be executed within the processor 91 to enable the computing system 90 to work. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors 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), a state machine, etc. The processor 91 may perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the computing system 90 to operate in a communication network. Coprocessor 81 is an optional processor distinct from main processor 91 that may perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

[0122] During operation, the processor 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the main data transfer path of the computing system, the system bus 80. This system bus connects the components in the computing system 90 and defines the medium for data exchange. The system bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for the operating system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[0123] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes circuitry that allows for the storage and retrieval of information. The ROM 93 typically contains stored data that is not easily modified. The data stored in the RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to the RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that converts virtual addresses to physical addresses when an instruction is executed. The memory controller 92 can also provide a memory protection function that isolates the processes within the system and separates system processes from user processes. Thus, a program running in the first mode can only access the memory mapped by its own process virtual address space; it cannot access the memory within the virtual address space of another process unless memory sharing between processes is set up.

[0124] In addition, the computing system 90 can include a peripheral device controller 83 that is responsible for transferring instructions from the processor 91 to peripheral devices such as a printer 94, a keyboard 84, a mouse 95, and a disk drive 85.

[0125] A display 86 controlled by a display controller 96 can be used to display visual output generated by the computing system 90. Such visual output can include text, graphics, animated graphics, and video. The visual output can be provided in the form of a graphical user interface (GUI). The display 86 can be implemented using a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch panel. The display controller 96 includes the electronic components required to generate the video signal sent to the display 86.

[0126] In addition, the computing system 90 can include means for connecting the computing system 90 to an external communication network or device (such as Figure 1A 、 1B, communication circuitry (such as a wireless or wired network adapter 97) for enabling the computing system 90 to communicate with other nodes or functional entities of these networks (such as RANs 103 / 104 / 105, core networks 106 / 107 / 109, PSTN 108, Internet 110, WTRU 102, or other networks 112 of 1C, 1D, and 1E), and the communication circuitry, either alone or in combination with the processor 91, may be used to perform the sending and receiving steps of certain devices, nodes, or functional entities described herein.

[0127] It should be understood that any or all of the devices, systems, methods, and processes described herein may be embodied in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor (such as processor 118 or 91), cause the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any step, operation, or function described herein may be implemented in the form of such computer-executable instructions that are executed on a processor of a device or computing system configured for wireless and / or wired network communication. The computer-readable storage medium includes volatile and non-volatile, removable and non-removable media implemented by any non-transitory (e.g., tangible or physical) method or technology for the storage of information, provided that such computer-readable storage medium does not include signals. The computer-readable storage medium includes (but is not limited to) RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium that can be used to store the desired information and that can be accessed by a computing system.

[0128] 5G cellular network

[0129] Figure 2 Illustrates an example of a 5G system in a non-roaming reference architecture with a service-based interface in the control plane according to an exemplary embodiment. In the exemplary embodiments described herein, a remote UE may be assisted by a relay UE or one or more intermediate UEs and relay UEs of a relay chain to access any service function of the 5G system via the relay UE or via one or more intermediate UEs and relay UEs, such as as described in the 3GPP standards, and as in Figure 2as illustrated in the embodiments of. The exemplary 5G non-roaming reference architecture includes a Network Exposure Function (NEF) 196, a new Repository Function NRF 201, a Policy Control Function (PCF) 184, a User Data Management Function (UDM) 178, an Application Function (AF) 188, an Authentication Server Function (AUSF) 201, an Access and Mobility Function (AMF) 172, a Session Management Function (SMF) 174, a Radio Access Network (RAN) 103 / 104 / 105 function, a User Plane Function (UPF) 176, and a Data Network (DN) function 208.

[0130] Figure 3 Illustrated using reference points, the 5G system architecture in a non-roaming scenario is shown, where the reference points show how various network functions interact according to an exemplary embodiment. End-to-end communication between an application in the UE and an application in an external network uses services provided by the 3GPP system and optionally services provided by a Service Capability Server (SCS) residing in the DN. Figure 3 Illustrates an architecture in which each entity interacts with each other through the indicated reference points. A User Equipment (UE) device 102 can send and receive data to and from a Data Network (DN) 208 such as the Internet through a Radio Access Network (RAN) 105 and a User Plane Function (UPF) entity 176a. This data path is referred to as the 5G User Plane (UP).

[0131] Data traffic from the UE 102 is sent on a PDU session created in the core network. The following network functions play a role in the PDU session management within the core network 106 / 107 / 109. Figure 2 Also includes a Network Slice Selection Function (NSSF) 216.

[0132] · Access and Mobility Function (AMF) 172: The UE 102 sends an N1 message to the AMF 172 through the RAN node 105 to initially establish a PDU session in the core network. The AMF 172 selects an appropriate SMF 174 to handle the PDU session establishment request.

[0133] · Session Management Function (SMF) 174: The SMF 174 is responsible for creating a PDU session and can contact the UDM 197 for subscription information and the PCF 184 for policy information to use when processing the PDU session establishment request. The SMF 174 can also communicate with the UPF 176a and the RAN node 105 to establish tunnel information that can be used to route data from the UE 102 to the DN 208 and from the DN 208 back to the UE 102.

[0134] ·Policy and Control Function (PCF) 184: The PCF 184 authorizes and makes policy decisions for establishing a PDU session.

[0135] ·User Plane Function (UPF) 176a: The UPF 176a allocates resources in the user plane to allow data traffic to flow from the UE 102 to the DN 208 and from the DN 208 back to the UE 102. One or more UPFs 176a, 176b, 176c, etc. in the core network can be used to route data.

[0136] ·Radio Access Network (RAN) 105: The RAN node 105 provides communication access from the UE 102 to the core network for both control plane and user plane traffic.

[0137] Control Plane Protocol Stack

[0138] Figure 4 Illustrates non-access stratum (NAS) transmissions for session management (SM), short message service (SMS), UE policy, and location service (LCS) according to an exemplary embodiment. The mobility management function and the session management function can be separated. A single N1 NAS connection can be used for registration management and connection management (RM / CM), as well as for SM-related messages and procedures for the UE. A single N1 termination point can be located in the AMF. The AMF can forward SM-related NAS information to the SMF. The AMF can handle registration management and connection management of NAS signaling exchanged with the UE, while the SMF can handle session management of NAS signaling exchanged with the UE.

[0139] Additionally, the architecture includes several types of control signaling that can be transmitted over the NAS-MM protocol, such as UE policy between the PCF and the UE, and location service (LCS) between the Gateway Mobile Location Center (GMLC) and the UE.

[0140] Figure 5 Illustrates a simple architecture model for Proximity Services (ProSe) UE-to-network relay according to an exemplary embodiment.

[0141] Figure 6 Illustrates the user plane protocol stack for UE-to-network relay, which applies layer 3 forwarding according to an exemplary embodiment. See Figure 5 and 6, the LTE ProSe UE-to-network relay entity can provide a function that supports the connectivity of a remote UE to the network. The ProSe UE-to-network relay can relay unicast traffic (DL and UL) to the remote UE and relay eMBMS traffic using one-to-many ProSe direct communication. If a UE successfully establishes a PC5 link with a certain ProSe UE-to-network relay (e.g., LTE V2X, one-to-many interface, etc.), the UE can be considered a remote UE of that ProSe UE-to-network relay. The remote UE can be located within the E-UTRAN coverage area or outside the E-UTRAN coverage area. If the remote UE maintains both PC5 and Uu, the EPS core network entity on the Uu side of the remote UE is not aware of the ProSe UE-to-network relay path via PC5.

[0142] Figure 7 The figure illustrates an example process of direct communication via a relay UE 701 for 3GPP ProSe. The UE 701 that supports ProSe UE-to-network relay can attach to the network (if it is not already connected) and connect to a PDN connection to enable necessary relay traffic, or it can connect to an additional PDN connection to provide relay traffic to the remote UE. The PDN connection that supports UE-to-network relay can only be used for remote ProSe UE relay traffic.

[0143] Step S702: The ProSe UE-to-network relay UE 701 performs an initial E-UTRAN attachment (if not already attached) and / or establishes a PDN connection for relay (if there is no appropriate PDN connection for this relay).

[0144] Step S703: The remote UE 102 performs discovery of the ProSe UE-to-network relay using Model A or Model B discovery.

[0145] Step S704: The remote UE 102 selects the ProSe UE-to-network relay UE 701 and establishes a connection for one-to-one ProSe direct communication. If there is no PDN connection associated with the ProSe relay UE ID or an additional PDN connection for relay is needed, the ProSe UE-to-network relay UE 701 initiates a new PDN connection establishment process for relay.

[0146] Step S705: An IPv6 prefix or an IPv4 address is assigned to the remote UE 102. From this point on, uplink and downlink relay can start.

[0147] Step S706: For the PDN connection associated with the relay chain, the ProSe UE-to-network relay UE 701 sends a Remote UE Report (Remote User ID, IP information) message to the MME 162. The Remote User ID is the identifier of the remote UE user successfully connected in Step 704 (provided via user information). For the PDN connection associated with the relay chain, the MME 162 stores the Remote User ID and the relevant IP information in the EPS bearer context of the ProSe UE-to-network relay.

[0148] Step S707: The MME 162 forwards the Remote UE Report message to the S-GW 164, and the S-GW forwards the message to the P-GW 166 of the UE-to-network relay UE 701. The ProSe UE-to-network relay UE 701 can report multiple remote UEs 102 in one Remote UE Report message.

[0149] Enhancement of ProSe (Proximity Services) UE-to-network relay

[0150] Research on enhancing ProSe UE-to-network relay has been carried out in 3GPP SA2, and the objectives are as follows:

[0151] · Investigate and evaluate the necessary enhancements to the EPC to support general layer 2 evolution of ProSe UE-to-network relay, including the processes for the network to identify, authenticate, authorize, control, address, and reach the evolved ProSe remote UE via the evolved ProSe UE-to-network relay UE.

[0152] · Investigate and study the enhancement of existing processes to authorize the UE to act as an evolved ProSe UE-to-network relay between the evolved ProSe remote UE and the E-UTRAN.

[0153] · Investigate and evaluate the necessary enhancements to the evolved ProSe UE-to-network relay discovery and selection processes.

[0154] · Investigate and study the support for service continuity.

[0155] · Investigate and study the support for the power consumption efficiency of the evolved ProSe remote UE.

[0156] · Investigate and study the support for the evolved ProSe remote UE (such as CIoT UE) optimized for small data transfer and triggering.

[0157] Figure 8 Illustrate the control plane protocol stack for enhanced UE-to-network relay according to an exemplary embodiment.

[0158] Figure 9The figure illustrates a proposed user plane protocol stack for layer 2 relay according to an exemplary embodiment.

[0159] For example, Figure 8 and Figure 9 respectively include a proposed control plane protocol stack and a user plane protocol stack for layer 2 relay, where the adaptation layer is FFS. Note that this example is based on LTE PC5, which does not include RRC in the PC5-S stack.

[0160] Research on enhanced relay (FS_REFEC) for energy efficiency and wide coverage

[0161] Recently, there has been a research project in 3GPP SA1. This research focuses on identifying new requirements for relays for energy efficiency and wide coverage, especially those driven by new use cases in 5G. 5G envisions many different scenarios and verticals (inHome, smart agriculture, smart factories, public safety, etc.). Many of these are new, while others have been covered in previous generations of mobile networks. What all the research has in common is that they can identify use cases that require better energy efficiency and wider coverage compared to what previous generations (3G, 4G) could offer. This research targets layer 2 relay.

[0162] The Release 16 service requirements already include the possibility of direct 3GPP communication or indirect 3GPP communication via relays. However, this may not be sufficient to meet the needs of possible use cases from the listed areas. Incorporating multi-hop relays into 5G can help improve the energy efficiency and coverage of 5G systems. Some example requirements have been identified:

[0163] · The 5G system should support UE relay selection based on the instantaneous relay availability including the current relay mobility.

[0164] · The 5G system should support the gNB to allocate UE relay resource pools according to UE mobility.

[0165] · The 5G system should support mobile UE relays to reconfigure their resource pools according to their current location and mobility.

[0166] · The 5G system should support the gNB to allocate and reconfigure UE routing IDs according to UE mobility.

[0167] · The 5G system should support hop-by-hop UE relay selection based on long-term cost metrics provided by the gNB and the instantaneous relay availability determined by fast-changing channel states and cache loads.

[0168] · The 5G system should support high-power UEs to schedule resources for low-power UEs.

[0169] ProSe discovery

[0170] Figure 10 The figure illustrates the entire process of ProSe discovery model A according to an exemplary embodiment. A PC5 discovery protocol stack can be defined for the D2D ProSe direct discovery mechanism.

[0171] In LTE ProSe, there are two types of D2D ProSe direct discovery: open and restricted. Open is the case where no explicit permission from the discovered UE is required, while restricted discovery occurs only when there is explicit permission from the discovered UE.

[0172] In LTE, two discovery models are defined, discovery model A and discovery model B. Model A defines two roles for the participating UEs: the advertising UE and the monitoring UE. The advertising UE advertises certain information that can be used by neighboring UEs with discovery permission, while the monitoring UE monitors certain information of interest from neighboring advertising UEs. Service authorization is completed (S1001). In this model, the advertising UEs (e.g., UE 102 and / or UE 701) broadcast discovery messages at a predefined discovery interval (S1002). The example monitoring UEs (e.g., UE 102 and / or UE 701) interested in these messages read and process them (S1004). In this model, the advertising UE (e.g., 102) can broadcast information about itself to advertise its presence ("I'm here") and the services it offers (S1005). A matching report can be provided based on the discovery results (S1006). Model A supports both open and restricted discovery types. When matching information is determined, a report is generated (S1006).

[0173] Figure 11 The figure illustrates the entire process of ProSe (Proximity Services) discovery model B according to an exemplary embodiment. Discovery model B also defines two roles for the participating UEs: the discoverer UE and the discovered UE. Service authorization is completed (S1101). The discoverer UE (e.g., 102) sends a request (S1102) that contains certain information about the content it is interested in to discover and determine whether the discovered UE (e.g., 701) can provide certain services (S1103, S1104), and the discovered UE (e.g., 701) that receives the request message (S1105) can respond with some information related to the discoverer's request (S1106, S1107). This model can be summarized as "Who's there or Are you there?" because the discoverer UE sends information to other UEs. Model B only supports the restricted discovery type. When matching information is determined, a report is generated (S1108).

[0174] Example use case: Problem statement

[0175] The embodiments described herein can be used to address different use cases, including those described for 5G. As an example, without limitation, consider a company that has a large factory where precursor chemicals are converted into other chemicals for highly specialized industries such as pharmaceuticals, plastics, cosmetics, etc. Many of the chemicals are hazardous as they are flammable and / or toxic to humans and are often corrosive.

[0176] To avoid hazards to workers as much as possible, the company uses remotely controlled semi-autonomous robots for the extensive movement, storage, and inspection of chemical drums (containers) between different warehouses and within the production workshop itself.

[0177] In addition to the above, the containers of the chemicals and the hazardous material protective suits are equipped with communication devices that can send critical information such as temperature, humidity, and the possible presence of certain chemicals in the air.

[0178] Most of the work is carried out inside a metal enclosure that can enclose possible chemical leaks. The enclosure walls and the drums, which are also made of metal, act as electromagnetic (EM) shields, making signal propagation difficult and unpredictable.

[0179] The company chooses to use a UE of an embodiment capable of multi-hop relay operation to relay messages between the remote UE 102 and the gNB 140 instead of deploying multiple gNBs. Although not all UEs can be used as relays, a large number of UEs of different types (mounted on vehicles, handheld, on drums) ensure sufficient coverage. In other words, a mesh network is formed within the factory, where at least one UE (e.g., 701) is connected to the application server via the gNB and the 5G network.

[0180] As introduced herein, some architectures and mechanisms have been defined for relays in the 3GPP specifications. However, many issues related to multi-hop relay have not been addressed in 5G. Incorporating multi-hop relay into 5G can help improve the energy efficiency and coverage of 5G systems. Since 5G networks are expected to support a wide variety of applications and use cases with requirements such as improved energy efficiency and extended network coverage, multi-hop relay should be considered a potential way to meet these requirements. There are some major problems and challenges in deploying multi-hop relay in 5G networks.

[0181] Multi-hop relay chain formation: Once UEs (e.g., 102, 701) discover each other to be in proximity, the general problem is how to form a multi-hop relay chain and to what extent the network manages or controls the multi-hop relay chain formation. Note that some UEs in the chain may be outside the coverage area.

[0182] As discussed herein, the present disclosure provides embodiments enabling layer 2 multi-hop relay. In other words, each UE can be directly or indirectly attached to or registered with the network, and it can be determined how registration and connection management can be performed for each UE in the relay chain.

[0183] Each UE can perform periodic tracking area updates and registration updates. If the respective UEs 102 initiate these processes at different times and rely on the relay UE 701 to exchange messages with the network, the relay UE 701 will need to handle excessive control signaling. In other words, the control signaling overhead may be higher than the PC5 connection and the NAS connection between the relay UE 701 and the AMF 172.

[0184] Regarding power saving (e.g., PSM (Power Saving Mode) and discontinuous reception (DRX) and paging), in the case of allocating different periods to different UEs in the relay chain, there may be excessive control signaling for the relay UE 701 to handle. This is even more so when the relay UE 701 needs to listen for incoming paging messages on behalf of the remote UE 102 and forward the paging messages from the network to the paged remote UE 102.

[0185] For the network, when paging messages are sent to different UEs in the relay chain, some new mechanisms can be defined to reduce the paging overhead in the network, such that in the context of multi-hop relay, the paging operation can be more efficient for both the network and the relay UE 701.

[0186] Multi-hop relay chain maintenance: In the case where a UE in the middle of the relay chain (which can be described as an intermediate UE) becomes unreachable (e.g., enters the idle mode, leaves, or shuts down), the UE 102 needs to know this change and pair itself with another UE (intermediate or relay). This means that the remote UE 102 should attempt to join another relay chain or stay in the same relay chain by pairing with a different UE in the chain. It needs to be determined which party (i.e., the core network, gNB, relay UE directly connected to the gNB) is responsible for maintaining the reachability state of the UEs in the relay chain, or multiple parties cooperate with each other for different roles. Some solutions for embodiments on how to switch the affected UE to a new or existing relay chain and whether and how the relay UE 701 is given a certain degree of freedom to manage the relay chain in a distributed manner are described herein.

[0187] It is expected that 5G networks support a variety of applications and use cases, with requirements such as improving energy efficiency and extending network coverage. Multi-hop relay can be implemented to meet these requirements.

[0188] The following description focuses on embodiments enabling multi-hop relay operations in 5G networks that can improve energy efficiency and extend network coverage.

[0189] · Registration process of a UE that wants to enable multi-hop relay service. New information elements and multi-hop relay strategies are proposed. Additionally, a UE can register with the network directly or indirectly via another UE.

[0190] · The multi-hop relay strategy can be sent from the PCF to the UE

[0191] · Process of joining and forming a multi-hop relay chain.

[0192] · A UE can reuse the PC5 discovery process to discover and select a relay UE, and determine whether there is an existing multi-hop relay chain.

[0193] · Remote UE The process of establishing a PC5 link with the selected relay UE can be initiated by requesting to join an existing relay chain or form a new relay chain. As a requirement for layer 2 relay, the registration process of the UE can occur together with this process. Additionally, depending on the network configuration and multi-hop relay strategy, the network can participate in the process of forming a new multi-hop relay chain, which is proposed as network-assisted relay chain formation.

[0194] · Method for maintaining a multi-hop relay chain when a UE in the middle of the relay chain or a relay UE becomes unreachable (e.g., when the UE shuts down or leaves)

[0195] · For more efficient operation, methods for registration management and connection management of UEs in a multi-hop relay chain are proposed. According to the network configuration and multi-hop relay strategy, the following processes are proposed:

[0196] · Method for the network to page multiple UEs in a relay chain through the N2 interface, where the N2 connection is shared by these UEs.

[0197] · Method for a remote UE to perform a registration update process with a relay UE through a PC5 connection, and the relay UE will report the registration update status to the network on behalf of one or more UEs at a pre-configured time point.

[0198] Additionally, it should be realized that the following embodiments include the following assumptions:

[0199] · At least one UE in the relay chain is within the coverage of the gNB.

[0200] · The relay is layer 2 relay, i.e., it is required that each UE registers with the network.

[0201] · All UEs in the relay chain are served by the same network slice and AMF.

[0202] Registration for enabling multi-hop relay

[0203] Direct registration

[0204] Layer 2 relaying requires each UE to register with the network and establish a NAS connection. Additionally, in order to use multi-hop relaying services as a relay UE, remote UE, or intermediate UE, the UE needs to be authenticated and authorized by the network. In one embodiment, this can be achieved through the registration process.

[0205] Figure 12( Figure 12A - 12C ) illustrates a general registration process in which multi-hop relaying can be assisted. The general registration process described in "5G; Procedures for the 5G System (3GPP TS23.502 version 15.2.0 Release 15)", including section 4.2.2.2.2 (referred to herein as "Release 15"), is incorporated herein by reference in its entirety and can be applied as described, as well as as modified and described herein. Steps 1201 - S1226 are documented in Release 15. In an embodiment, UE registration can be achieved through the following process.

[0206] · Before forming or joining a multi-hop relay chain, the UE can indicate to the network that it wants to enable multi-hop relaying capabilities and what role it wants to play (i.e., remote UE, intermediate UE, or relay UE). The network can decide to request the RAN node to configure this role for the UE. At step S1201, this information can be inserted into the registration request message.

[0207] · Assume the UE initiates the registration process by communicating directly with the core network via the RAN node. For example, if UE102 wants to act as a remote UE, it needs to provide the following information:

[0208] · The direction of the relay traffic, i.e., UL and / or DL.

[0209] · Application service information, such as the application ID and application service provider ID associated with the relay traffic

[0210] · Expected traffic characteristics, such as periodic traffic with start and end times, IP or non-IP type traffic

[0211] · QoS requirements for the relay traffic, such as data rate and maximum allowable latency

[0212] · Preferred radio access technology (RAT), e.g., 5G NR, LTE radio, or non-3GPP access (e.g., satellite and WiFi). The UE can also indicate the priority order of each possible RAT.

[0213] · Supported PC5 protocol stack: Indicate the type of PC5 protocol stack it supports, such as LTE PC5 and / or NR PC5.

[0214] · Regional information of the relay traffic: Indicates the area where relay is expected to occur or indicates that the relay is limited within this area. Outside this area, the UE may be able to directly connect to the RAN node, or the UE prefers a direct connection to the RAN node.

[0215] If a UE (e.g., 701) wants to act as a relay UE or an intermediate UE, it needs to provide the following information:

[0216] · Relay capabilities, such as the data rate and data volume that can be relayed for remote UEs, the scheduling availability of the relay, the relay area (only UEs in this area can use this UE as a relay) or the relay range (indicating the maximum distance between this relay UE and any remote UE), the caching ability for relayed data, whether data aggregation is supported for UL (uplink), DL (downlink) or both directions

[0217] · Application service information, such as application ID and application service provider ID, indicating what application and service traffic this relay UE can relay

[0218] · The maximum number of remote UEs and / or intermediate UEs that can connect to this relay UE

[0219] · The RAT available for relay, such as 3GPP access or non-3GPP access.

[0220] · Supported PC5 protocol stack: Indicates the type of PC5 protocol stack it supports, such as LTE PC5 and / or NR PC5.

[0221] · Discovery assistance information, such as supported discovery mechanisms (e.g., LTE PC5 discovery, NR PC5 discovery, network-assisted discovery, Model A and Model B discovery, etc.), whether group discovery is supported, whether time synchronization is required between UEs in the relay chain or only between the relay UE and UEs in the relay chain, whether data communication is allowed between any two UEs in the relay chain or only between the UE and the relay UE.

[0222] · If a UE is to act as a relay UE, this UE needs to provide some more information about the entire relay chain, such as the maximum number of UEs in the relay chain, broadcast / multicast capabilities, the maximum area that the relay chain can cover. Additionally, the relay UE can indicate whether it supports or requires distributed relay chain management.

[0223] · Registration / connection management capabilities, indicating whether the relay UE can manage the registration status or connection status of remote UEs, or whether the UE must be attached to the network, i.e., whether the UE supports layer 3 relay, layer 2 relay or both.

[0224] In addition, regardless of its intended role (i.e., remote / relay / intermediate UE), the UE can include a UE policy container in the registration request message. Specifically, a Policy Section ID (PSD) can be included and used to identify the type of policy, such that the network knows that the UE is requesting a multi-hop relay policy. Additionally, an indication that the UE supports the multi-hop relay policy is included. This can trigger the network to create / update the UE policy association in a later step, and then the PCF (Policy Control Function) can determine the multi-hop relay policy and send it to the UE.

[0225] The UE can provide the above information in the registration request message (i.e., step S1201), or provide partial information in step S201 and provide additional information in the continued interaction with the network (such as step S1227) based on a request from the network.

[0226] After the AMF receives the UE policy container information, it depends on whether this is an initial registration or a registration update process to trigger the UE policy association establishment / modification process with the PCF 184. At step S1219, the AMF needs to consider whether the PCF can select and provide a multi-hop relay policy during the PCF selection process. The AMF uses a create or update operation to invoke the Npcf_UEPolicyControl service to request the PCF to determine a multi-hop relay policy for the UE. The AMF can perform this operation at step S1226. Alternatively, the AMF can decide to initiate the UE policy association establishment / modification together with step S1220.

[0227] As a result of the Npcf_UEPolicyControl service initiated by the AMF, the PCF will determine the multi-hop relay policy. The policy can be sent to the UE over the NAS connection established between the UE and the AMF as a result of the registration process (i.e., step S1225).

[0228] Table 1 lists some information that can be included in the multi-hop relay policy, where the multi-hop relay policy can be classified into several categories: related to Registration Management (RM), related to Connection Management (CM), and related to multi-hop relay chain formation and maintenance.

[0229] Table 1: Multi-hop Relay Policy

[0230]

[0231]

[0232] Indirect registration via a relay UE

[0233] Figure 12( Figure 12A - 12C ) shows the remote UE 102, where the information originates from the remote UE 102. In another embodiment, Figure 12(Figure 12A - 12C ) The UE 102 can be replaced by the relay UE 701. For easier understanding, FIG. 12( Figure 12A - 12C ) shows the identified UE 102, but any UE (remote UE, intermediate UE, or relay UE) can replace the UE 102.

[0234] A registration request originating from a remote UE 102 that is unable or determined to be unable to directly contact the RAN node 105 can be sent by the UE in FIG. 12( Figure 12A - 12C ) In other words, the UE shown in FIG. 12( Figure 12A - 12C ) can be the relay UE 701 that forwards the registration request message on behalf of the remote UE 102. Assuming that the relay UE 701 has completed its own registration process and the same AMF will serve the UEs in the multi-hop relay chain, when forwarding the registration request message received from the remote UE 102 in step S1201, the relay UE 701 needs to provide the following information.

[0235] · Relay UE ID, such as 5G globally unique temporary UE identifier (5G-GUTI), 5G globally unique subscription permanent identifier (SUPI), 5G S-temporary mobile subscription identifier (S-TMSI): Based on this information, the network can create an association between the relay UE and the remote UE.

[0236] · S-NSSAI and network slice instance (NSI) ID: Identify the network slice and network slice instance allocated by the network during registration to serve the relay UE. Note that in the embodiment, it is desirable for the network to allocate the same network slice to serve the UEs in the relay chain. However, if this cannot be achieved, the network can attempt to ensure that the same AMF is selected to serve the UEs in the same relay chain.

[0237] · Multi-hop relay policy ID or reference ID to the multi-hop relay policy: Based on this policy information, the network can determine the multi-hop relay policy for the remote UE. This policy can affect multi-hop relay operations in various aspects (such as UE registration updates, paging, session management, relay chain formation and management, etc.).

[0238] · Multi-hop relay chain ID (if any): Identify the multi-hop relay chain that the relay UE joins

[0239] · Relay capabilities of the relay UE, such as the data rate and data volume that can be relayed for the remote UE, the scheduling availability of the relay, the relay area (only the UEs in this area can use this UE as a relay), or the relay range indicating the maximum distance between this relay UE and any remote UE, the caching ability for relayed data, and whether data aggregation is supported for UL (uplink) and / or DL (downlink).

[0240] · Registration management configuration of the relay UE: This is used by the AMF to determine those configurations of the remote UE, such as the registration area, and the timer values for periodic registration updates. The network may want to set the same configurations for the UEs joining the relay chain.

[0241] · Discontinuous Reception (DRX) and paging configuration of the relay UE: This is used by the AMF to determine the DRX parameters and paging configuration of the remote UE, such as the DRX cycle, paging options, and paging timer.

[0242] When the AMF completes the registration process of the remote UE, it will return a registration acceptance message (i.e., step S1225)) to the relay UE (i.e., the UE shown in Figure 12( Figure 12A - 12C ) via the RAN node, and then the relay UE will forward this message to the remote UE through the PC5 connection.

[0243] Multi-hop relay chain formation

[0244] When UEs complete registration with the network, they are authorized to form or join a multi-hop relay chain. A UE can initiate the process of joining a multi-hop relay chain by connecting to a relay UE or an intermediate UE to establish contact with the core network. This section focuses on those processes that are always initiated by UEs that want to connect to the base station and the core network via a relay UE or an intermediate UE. Generally, the following processes can be carried out:

[0245] · Discovery: The UE needs to discover one or more neighboring UEs and select one of the discovered UEs as a relay / intermediate UE towards the network. Additionally, during the discovery process, the UE can discover one or more existing relay chains.

[0246] · PC5 link establishment: After selecting the relay / intermediate UE, the UE will request to establish a PC5 link.

[0247] New information in PC5 discovery for relay selection

[0248] The following describes what information can be used in the PC5 discovery process to enable multi-hop relay selection. The PC5 discovery process described in this article can be reused to discover relay / intermediate UEs and / or any existing multi-hop relay chains. In the context of multi-hop relay, the following new information can be included in the discovery process:

[0249] · UE ID: If any UE has completed registration, this is the ID assigned by the network, such as 5G-S-TMSI and 5G-GUTI.

[0250] · Layer 2 link ID: This is the ID used for ProSe PC5 communication

[0251] · Multi-hop relay chain ID: If the UE has joined or been assigned a relay chain, it can include this ID in the discovery message so that other UEs looking for relay / intermediate UEs can identify and request to join the existing multi-hop relay chain.

[0252] · Supported PC5 protocol stack: Indicates the type of PC5 interface supported by the UE, i.e., LTE PC5 and / or NR PC5.

[0253] · Multi-hop relay policy ID: This can be the policy applied to the relay chain (identified by the multi-hop relay chain ID) that the UE has joined. The UE can insert this information into the discovery message. Even if the UE has not joined any relay chain but is authorized by the network to act as a potential intermediate or relay UE during registration, it can also insert this information into the discovery message. This is helpful for UEs outside the coverage area because the UE can establish a PC5 link before registering with the network.

[0254] Using the discovered information, the UE can select relay / intermediate UEs and multi-hop relay chains by considering the following factors:

[0255] · Application / service type

[0256] · Location information

[0257] · Supported PC5 protocol stack

[0258] Method for establishing a PC5 connection to join / form a multi-hop relay chain

[0259] The mechanism for a remote UE to join or form a multi-hop relay chain is described below. It can be assumed that the relay UE has registered with the network regardless of whether a multi-hop relay chain has been formed. When a relay chain is formed, the network, base station, or relay UE can assign a multi-hop relay chain ID.

[0260] Regarding joining an existing relay chain, during the discovery process, the UE can discover existing multi-hop relay chains and one or more neighboring UEs. The UE will initiate the PC5 link establishment process to connect to the selected UE and join the multi-hop relay chain. There are 2 scenarios to consider:

[0261] 1. The remote UE has not registered with the network: In this case, the remote UE sends a registration request along with the PC5 link establishment request, and the relay UE can forward the registration request to the network. There are 2 options:

[0262] a. First, the network performs the registration, and then the PC5 link is established based on the configuration as a result of the registration. Figure 13 The figure illustrates the process of this embodiment.

[0263] b. The second option is to first establish a PC5 link and then perform registration. Figure 14 The figure illustrates the process of this embodiment.

[0264] 2. The remote UE has registered with the network: Figure 15 The figure illustrates the process of this scenario embodiment.

[0265] Figure 13 The figure illustrates the process of first performing registration under the assumption that the relay UE 701 has registered with the network and has been assigned a multi-hop relay chain ID.

[0266] Step S1301: The remote UE 102 sends a PC5 link establishment request to the selected relay UE 701 by including the following information:

[0267] · Encapsulated registration request. The registration request may include information elements specified herein for enabling multi-hop relay services.

[0268] · Relay chain join request indicating that the remote UE wants to join an existing relay chain via the relay UE

[0269] · Relay chain ID discovered by the remote UE during the PC5 discovery process

[0270] · Relay policy ID: If the remote UE has a certain pre-configured relay policy, it sends the policy ID to the relay UE

[0271] · Relay UE ID: This can be the ID used during the PC5 discovery process, such as layer 2 ID, 5G-GUTI, 5G-SUPI, and 5G-S-TMSI.

[0272] · Remote UE ID: This is the layer 2 ID. Since the remote UE has not yet registered with the network, it does not have any network-assigned UE ID.

[0273] · Application and service information: Indicates the type of application service associated with the relay traffic, such as application ID, application service provider ID.

[0274] · DNN: Indicates which data network the traffic from the remote UE is relayed to

[0275] Step S1302: Since the figure illustrates the scenario of first performing registration, the relay UE 701 de-encapsulates the registration request and forwards the message to the serving AMF 172. As discussed herein, the relay UE 102 may attach some more information to the remote UE's registration request to facilitate the registration process at the AMF 172.

[0276] Step S1303: When receiving a registration request message, the AMF 172 initiates a regular registration process for the remote UE 102 by communicating with other NFs within the core network.

[0277] Step S1304: If the registration is successful, the AMF 172 returns a registration acceptance to the relay UE 701. This message may include a remote UE ID assigned by the network, an S-NSSAI assigned to serve the remote UE 102, a relay UE ID, and a relay chain ID. Thus, the AMF 172 and the network know that the remote UE 102 can be reached via the relay UE 701. The AMF 172 may also return some policies that the UE102 needs to store, such as URSP and / or multi-hop relay policies, depending on the role of the remote UE 102. Additionally, the AMF 172 may send some configurations regarding CM and RM operations, such as DRX cycle, paging options, and registration update timer values.

[0278] Step S1305: Once the relay UE 701 receives a registration acceptance message regarding the remote UE 102 from the AMF 172, it will decide whether to allow the remote UE 102 to join the existing relay chain. The relay UE 701 may consider the following factors:

[0279] Its own relay capabilities, as further described herein.

[0280] The relay load of the existing relay chain, such as the number of UEs 102 that have joined the relay chain and the total amount of relay traffic in terms of data rate.

[0281] Configurations proposed by the relay policy, such as the maximum number of hops from the core RAN node 105.

[0282] By considering the traffic characteristics of the remote UE, its power consumption and remaining battery level for relay traffic

[0283] To make the operating characteristics of the remote UE 102, such as DRX cycle, paging options, and registration update timer values, consistent with those of the relay UE 701.

[0284] Some security requirements for multi-hop relay communication from the remote UE 102, such as end-to-end encryption.

[0285] Note that the core network can assist in making this decision. For example, the Network Data Analytics Function (NWDAF) in the core network can provide some analysis information (such as load information in the relay chain) and predict future traffic and mobility patterns for the UEs in the relay chain.

[0286] Step S1306: The relay UE 701 sends a PC5 link establishment response to the remote UE 102. The response includes a registration acceptance message from the core network and a decision on whether the remote UE 102 can join the relay chain. If the remote UE 102 is accepted, the relay UE 701 may send some more information about CM and RM configurations, such as a registration update timer and paging operation options. If the relay UE 701 rejects the acceptance of the remote UE 102 in the relay chain, it will forward the registration acceptance message and notify the remote UE 102 in the response message of the rejection decision regarding joining the relay chain and the reason for the rejection.

[0287] The remote UE 102 can select more than one relay UE 701 and send its registration request to the network through each relay UE 701. In other words, the remote UE 102 requests to join multiple relay chains by sending a PC5 link establishment request combined with a registration request and will expect a registration acceptance from the selected relay UE 701. In the response, the PCF and the relay UE 701 can accept the remote UE to enter different relay chains and return responses with different multi-hop relay policies. In this case, different relay UE 701 are served by different AMF 172, that is, the registration requests are received by multiple AMF 172. When the remote UE 102 receives multiple registration acceptance messages, the remote UE 102 will notify the network to resolve the conflict by giving the AMF ID and its UE ID.

[0288] Figure 14 The figure illustrates the process of first establishing a PC5 link under the assumption that the relay UE has registered with the network and the relay chain has been formed.

[0289] Step 1401: The remote UE 102 sends a PC5 link establishment request to the selected relay UE 701. This step is the same as Figure 13 step S1301 in. The figure illustrates the case where the PC5 link is first established and mutual authentication is required since the remote UE 102 has not registered with the network yet.

[0290] Step S1402: When receiving this request, the relay UE 701 decides whether to accept the request of the remote UE 102 to join the relay chain, which is similar to Figure 13 step S1305 in.

[0291] Step S1403: The relay UE 701 returns a response to the remote UE 102 indicating whether it accepts the remote UE 102 to join the relay chain. In the case where the remote UE 102 joins the relay chain, a PC5 link is established, and the relay UE 701 can provide some information about the PC5 link to the remote UE 102, such as the layer 2 ID, the QoS parameters of the PC5 link, and the broadcast / multicast capabilities.

[0292] Step S1404: The remote UE 102 receives the PC5 link establishment decision.

[0293] Steps S1405 - S1407: The remote UE 102 initiates an indirect registration process by sending a registration request message to the relay UE 701 via the PC5 link, as further described herein (for example, in the section describing the registration illustrated in FIG. 12).

[0294] Figure 15 The figure illustrates the process of joining an existing relay chain by establishing a PC5 link under the assumption that two UEs have completed registration with the network and a relay chain has been formed.

[0295] Step S1501: The remote UE 102 sends a PC5 link establishment request to the selected relay UE 701. In addition to the information discussed in step S1301 of Figure 13 , the remote UE 102 can also include its UE ID assigned by the network, such as 5G - GUTI, 5G - S - TMS1, and 5G - SUPI, since it has registered with the network. In addition, the remote UE 102 can provide some information about its RM / CM configuration, such as the registration update timer and the DRX cycle.

[0296] Note that in this embodiment, mutual authentication is not required because both the UE 102 and the UE 701 are authenticated and authorized by the network during the registration process. The UE ID assigned by the network (e.g., 5G - S - TMS1) and the layer 2 ID of the UE can be used in PC5 communication without any potential address conflicts.

[0297] Step S1502: The relay UE 701 sends a request to the serving AMF 172 to verify the remote UE 102 and optionally retrieve information for determining whether to accept the request for the remote UE 102 to join the relay chain.

[0298] Step S1503: The AMF 172 initiates a process within other NFs 1310 (e.g., UDM / UDR, NWDAF, and PCF) to verify the remote UE 102 information and collect information for the relay UE 701.

[0299] Step S1504: The AMF 172 returns results and information to the relay UE 701.

[0300] Step S1505: Once the relay UE 701 receives a response from the AMF 172, it will decide whether to allow the remote UE 102 to join the existing relay chain.

[0301] Step S1506: The relay UE 701 notifies the remote UE 102 of the decision. If the remote UE 102 is accepted to join the relay chain, PC5 link information is provided. The relay UE 701 may also send some information about CM and RM configuration updates because the remote UE 102 will join the relay chain, which requires some coordination among the UEs in the relay chain. In the case of non-acceptance, the PC5 link is not established.

[0302] Step S1507: If the remote UE 102 and the relay UE 701 are served by different AMFs, the serving AMF 172 will initiate an AMF reallocation process and move the UE context. This is possible because the remote UE 102 and the relay UE 701 register with the network separately before the remote UE 102 wants to establish a PC5 link.

[0303] Note that Figure 13 - 15 represents a 1-hop relay scenario, and the individual processes are generic and can be applied to multi-hop scenarios. In other words, the relay UE 102 can be an intermediate UE that forwards messages to another intermediate or relay UE 701 that manages the relay chain.

[0304] Regarding the formation of a new relay chain, if the UE does not find any existing relay chain during discovery, the request to establish a PC5 connection can trigger the process of forming a new relay chain. Depending on the configuration (e.g., relay policy, network operator configuration), the relay UE 701 can communicate with the core network and request to create a new relay chain with the allocated relay chain ID (network-assisted relay chain formation), or create a new relay chain without any assistance from the core network (distributed relay chain formation).

[0305] Figure 16( Figure 16A - 16B ) illustrates the process of network-assisted relay chain formation triggered by the PC5 link establishment process initiated by the remote UE. It is assumed that the remote UE has not registered with the network yet.

[0306] Step S1601: The remote UE 102 sends a PC5 link establishment request to the selected UE 701. In the request message, the remote UE 102 encapsulates a registration request and an indication requesting the selected UE 701 to be its relay traffic. Some other information may be included, and the some other information is similar to those included in Figure 13 Step S1301.

[0307] Step S1602: Once the selected UE 701 receives the request, it will first determine whether it wants to act as a relay for the remote UE 102. The relay UE 701 will consider several factors, as described in Figure 13 Step S1305.

[0308] Step S1603: If the relay UE 701 decides to relay traffic for the remote UE 102, the relay UE 701 forwards the registration request of the remote UE together with a message indicating that the relay UE 701 requests to establish a new relay chain to its serving AMF 172. In the relay request, the relay UE 701 may include the following information:

[0309] · The S-NSSAI allocated to serve the relay UE and the relay UE ID

[0310] · The relay capability of the relay UE

[0311] · The policy reference ID or relay policy ID indicating the relay configuration and policy that the relay UE will apply to the requested relay chain

[0312] Step S1604: The AMF 172 initiates the registration process with other NFs for the remote UE 102 and will obtain more remote UE information when the registration is completed. For example, the remote UE ID, subscription information.

[0313] Step S1605: The AMF 172 sends a relay chain formation request to the PCF on behalf of the relay UE 701 by including several information such as remote / relay UE information, relay policy ID, relay traffic characteristics, and service / application ID.

[0314] Step S1606: Optionally, the PCF contacts the UDM / UDR and AF / AS to retrieve some subscription information and service application related information of the UE. If the AF / AS cannot be directly contacted, the NEF may be involved.

[0315] Step S1607: Based on the information received from Steps S1605 and S1606, the PCF 184 determines whether the relay UE 701 can form a new relay chain. At the same time, the PCF 184 will determine some relay chain configurations, such as the maximum number of UEs in the relay chain, whether the relay UE 701 can be dynamically changed with or without notifying the network, the area information for relaying traffic, the service application information involved in the relay (such as DNN, application ID, ASPID), whether the relay UE 701 can manage the UEs in the relay chain in a distributed manner, the registration update timer, the DRX cycle, whether the UEs in the relay chain need to have the same time period for DRX or registration update, etc.

[0316] Step S1608: PCF 184 responds to the AMF 172 with a decision and configuration parameters, where the AMF 172 associates the remote / relay UE with the relay chain ID.

[0317] Step S1609: The AMF 172 sends the response with the above information, together with the registration acceptance for the remote UE 102, to the relay UE 701.

[0318] Step S1610: The relay UE 701 forwards the registration acceptance and some relay chain related configuration information to the remote UE 102.

[0319] It should be realized that Figure 13 -16 It is assumed that the same AMF serves the remote UE and the relay UE. If the UE completes registration separately before joining or forming a new relay chain, the UE may be served by a different AMF. In this case, the AMF reallocation process can be carried out by moving the context of all UEs to one AMF that serves all UEs in the relay chain. This can make the relay operation more efficient and reduce unnecessary signaling between AMFs.

[0320] In addition, in the case where the PCF rejects the request to form a new relay chain, it can indicate the reason (e.g., the relay UE 701 is overloaded, there is a policy conflict, the AS provider does not allow it), and find an alternative way for the remote UE 102 to reach the AF / AS through the core network, such as selecting another relay UE 701 or guiding the remote UE 102 to non-3GPP access to reach the core network.

[0321] To make distributed relay chain formation possible, the relay UE 701 can obtain the authentication and authorization for this from the core network. This can be done during the registration or registration update process of the relay UE 701. The PCF 184 can determine to what extent the relay UE 701 can manage the relay chain. For example, the relay UE 701 can add any UE to the relay chain or remove any UE from the relay chain, but is not allowed to form any additional relay chains. The PCF 184 can also select a multi-hop relay strategy and send it to the relay UE 701. In addition, the network can require the relay UE 701 to perform periodic updates with the network regarding the relay chain status. The relay chain ID can be assigned by the network. If the relay UE 701 is out of coverage when a new relay chain needs to be formed, the relay UE 701 will follow the multi-hop relay strategy to assign the relay chain ID and report to the network when possible. For this case, the multi-hop relay strategy can be pre-configured as the default strategy.

[0322] Multi-hop relay chain maintenance

[0323] When an intermediate UE in the middle of a multi-hop relay chain is turned off or leaves, the remaining UEs in the relay chain or the network need to find / form alternative relay paths so that these UEs can reach the network. This is especially critical for UEs with ongoing traffic to and from the network. In other words, it is desirable to provide service continuity for these UEs. This section presents exemplary embodiments of methods for how UEs in the relay chain and the network can adapt to a multi-hop relay chain interruption and how to find new relay paths for these affected UEs.

[0324] Specifically, different solutions can be applied for different scenarios as follows:

[0325] · The relay UE 701 remains unchanged: In this case, only the UE in the middle of the relay chain (e.g., the intermediate UE) changes, so that the relay UE 701 can reorganize the relay chain by sending a PC5 link establishment message to connect the remaining UEs. Depending on the multi-hop relay policy, the relay UE 701 can perform this reorganization of the relay chain without any interaction with the network. If the policy requires some interaction with the network, the relay UE 701 can send messages to the AMF 172 and the PCF 184 so that the network functions can participate in the decision-making process and notify the relay UE 701 whether it is allowed to do so. Finally, the relay UE 701 needs to notify the AMF 172 and the PCF 184 of the new structure of the multi-hop relay chain so that the network knows which UEs can be reached through which relay chain.

[0326] · The relay UE 701 changes: This is more complex because the network, the base station, or the remaining UEs need to select a new relay UE 701. Additionally, the new relay UE 701 can be selected from the remaining UEs in the relay chain or from a group of external UEs. Figure 17 The process of selecting a new relay UE is illustrated, and 2 cases are illustrated:

[0327] · Select a new relay UE from the remaining UEs that are part of the relay chain.

[0328] · Select a new relay UE from external UEs that are not part of the relay chain. In this case, the new relay UE can be a relay UE of another relay chain or a normal UE that does not participate in any relay activity.

[0329] Figure 17 The following steps are illustrated:

[0330] Step S1701: The old relay UE 701a notifies the AMF 172 and other core network functions that it will no longer be the relay UE 701 of the relay chain. The notification message includes the relay UE ID, the relay chain ID, and the relay policy ID. Optionally, the relay UE 701a may include a timer indicating the remaining time period during which it acts as a relay, and application / service information related to the relay traffic.

[0331] Step S1702: The AMF 172 and other NFs (e.g., PCF, UDM / UDR, NWDAF) determine possible ways to select a new relay UE 701b based on the multi-hop relay policy and the subscription information of the remaining UEs. Optionally, the AF 1310 and the application server (i.e., AS) may be contacted to obtain some application service information regarding the relay UE selection.

[0332] Step S1703: The AMF 172 sends a notification message with the relay chain ID and optional application service information to the remaining UEs via the old relay UE 701a. If the old relay UE indicates in Step S1701 the remaining time during which it can act as a relay UE, the AMF 172 may also include this time value. In addition, the AMF 172 may indicate the expectation of the new relay UE 701b. The AMF 172 may also include a list of UE IDs among the remaining UEs that can act as the relay UE 701.

[0333] Step S1704: If a UE among the remaining UEs is selected or can act as a relay UE, it will send a request message to become the new relay UE 701b to the AMF 172. In this request, the UE ID and its relay capabilities are included. The specific information in the relay capabilities is further described herein.

[0334] Step S1705: When receiving the request from the new relay UE 701b, the network will decide whether to accept the request.

[0335] Step S1706: The AMF 172 returns a response to the UE that sent the request message in Step S1704 by indicating whether the request to act as the new relay UE is accepted. If the new relay UE 701b is accepted, the AMF 172 will include a list of the remaining UE IDs in the relay chain, as well as some other configurations, such as RM / CM parameters, and whether the relay UE 701 can perform certain relay chain management in a distributed manner.

[0336] Step S1707: If the network does not receive any new relay UE requests from the remaining UEs and after a pre-configured time period, then the network may decide that a new relay UE should be selected from the external UEs. Then, network functions (e.g., AMF, PCF, UDM / UDR, and NWDAF) will coordinate with each other to list the list of UEs that may be candidates for the new relay UE 701b. Then AMF172 will send a message to the newly selected relay UE. AMF 172 may include the following information in the message: remaining UE ID, target relay chain ID (in the case where the new relay UE acts as a relay UE for another relay chain), target relay UE (i.e., the new relay UE) ID, old relay chain ID, and old relay policy ID. With this information, the new relay UE 701b can help the remaining UEs switch from the old relay chain to the new relay chain. In fact, the old relay chain is merged into the relay chain served by the new relay UE.

[0337] Step S1708: The new relay UE 701b initiates a PC5 link establishment process with these remaining UEs. If the new relay UE701b has already acted as a relay UE 701 for another relay chain identified by the target relay chain ID, then S1709 actually merges the old relay chain with the target relay chain.

[0338] Step S1710: The new relay UE 701b sends an acknowledgement to AMF 172 to notify that all the remaining UEs have successfully switched to the new relay UE 701b and can reach via the new relay UE 701b. AMF 172 and other network functions will create an association between the new relay UE 701b and these UEs.

[0339] Alternatively, the network or RAN node 105 may allow the UE to join multiple relay chains by connecting to multiple relay UEs 701. When the primary relay chain is disconnected, the remote UE 102 may redirect its traffic via these standby relay UEs without any service interruption.

[0340] Registration and Connection Management of UEs in Multi-hop Relay Chains

[0341] The following description gives exemplary embodiments of methods for configuring registration management (RM) and connection management (CM) for UEs in a relay chain, and how these RM / CM processes proceed. Based on the multi-hop relay policy, the network may decide to update the RM / CM configuration (such as paging options, power saving periods, and registration update timers) of the UEs in the relay chain for better coordination and simple operation. This may be triggered by one of the following events:

[0342] · One or more UEs join or leave an existing relay chain

[0343] · A new relay chain is formed

[0344] · A UE in the relay chain requests to update certain CM / RM parameters

[0345] · The application server or application service provider associated with the traffic of the relay requests to do so

[0346] Figure 18 Illustrate an example implementation process in which the AMF 172 can set the RM / CM configuration for the UE in the relay chain

[0347] Step S1801: As described above, when one of the triggering events occurs, the AMF 172 can be requested to update the configuration of the connection management and registration management operations. When the request is forwarded to the AMF 172, it contains the relay chain ID, so that the AMF 172 knows which UEs are involved

[0348] Step S1802: The AMF 172 decides on the CM / RM options and parameters based on the UE context and relay chain ID it stores. The AMF 172 can contact other NFs to obtain more information, such as the UE's subscription information from the UDM / UDR, the relay policy applied to the relay chain from the PCF, the session management information from the SMF, and some analysis data generated by the NWDAF

[0349] Step S1803: The AMF 172 sends the latest configuration to the relay UE 701 via the RAN node. The configuration update can include parameters such as the DRX cycle and the registration update timer. Additionally, it can include the relay chain ID and the relay UE ID. Optionally, the AMF 172 can specify some other UE IDs to join the relay chain, and the relay UE 701 can forward the configuration update to these UEs. If the AMF 172 does not include any specific UEs other than the relay UE 701, it can be assumed by default that each UE in the relay will update the configuration

[0350] Step S1804: The relay UE 701 can store these connection management and registration management configuration parameters

[0351] Step S1805: The relay UE 701 sends these configurations to a group of UEs or all UEs in the relay chain based on the UE IDs specified in the message transmitted in step S1803

[0352] Figure 18 The process shown can be carried out together with several core network processes (such as UE configuration update, service request, and registration update)

[0353] Paging multiple UEs in the relay chain via N2

[0354] According to the multi-hop relay strategy, the network or the relay UE 701 can decide to set the same paging cycle or paging timer for the UEs in the relay chain for simplicity of operation. In other words, these UEs 102 will listen for paging messages at approximately the same time, and the relay UE 701 will forward the paging messages to the corresponding downstream UEs.

[0355] Two embodiments of the option for the AMF 172 to send N2 paging messages targeting one or more UEs in the relay chain to the RAN node 105 are described here:

[0356] 1. Group-based N2 message transfer: For the relay UE 701 and all other UEs in the relay chain, only one N2 connection is established between the AMF 172 and the RAN node 105. In other words, the AMF 172 does not create an N2 connection for each UE in the relay chain. Instead, the N2 connection between the AMF 172 and the RAN node 105 for the relay UE 701 can be shared to transfer any N2 message to the UEs in the relay chain. Since the UEs in the relay chain need to register with the network, the UE ID (e.g., 5G-GUTI, 5G-S-TMSI, SUPI) and the relay chain ID can be used to identify the target destination UE in the N2 message. In the case where the network determines to page all UEs in the relay chain, the AMF 172 can insert the relay chain ID into the N2 paging message, and the relay UE 701 can broadcast this paging message to the UEs via the PC5 link. If the AMF determines to page a specific UE or a group of UEs in the relay chain, the AMF 172 will include the relay chain ID and the individual UE IDs in the N2 paging message so that the relay UE 701 and the intermediate UEs know which UE is the target destination. For UL N2 message transfer, a single remote UE 102 or intermediate UE 102 is transparent to the N2 message transfer because they do not have a direct connection to the RAN node 105. Thus, the proposed group-based N2 message transfer is only used for DL. Additionally, the AMF 172 can indicate in the N2 paging message the reason why the UE is being paged, such as DL data arrival, the need for UE configuration update, or an expected change in the relay chain. If the remote UE 102 can be reached via multiple relay UEs (i.e., the remote UE is involved in multiple relay chains), the AMF 172 will decide which relay UE 701 will forward the paging message to the remote UE 102 by considering different factors such as the number of hops between the relay UE 701 and the remote UE 102, the DRX cycle of the relay UE, and the relay capabilities of the relay UE. When sending the N2 paging message to the selected relay UE, the AMF 172 will include the relay chain ID and the UE ID in the paging message.

[0357] 2. The AMF 172 creates an N2 connection for each UE in the relay chain and uses a separate N2 identifier in the message sent to the RAN node 105. If the AMF 172 wants to page multiple UEs in the relay chain simultaneously, the AMF 172 needs to include each corresponding N2 identifier of the UEs in the N2 message sent to the RAN node 105.

[0358] In an embodiment, the relay UE 701 listens for paging messages on behalf of the UEs in the relay chain. Specifically, the relay UE 701 can obtain remote UE IDs such as 5G SUPI, S-TMSI, etc., enabling it to calculate the paging occasion of the remote UE 102 and monitor the paging messages for the remote UE 102. The relay UE 701 can derive this information from the remote UE 102 when establishing the PC5 link, or from the network when the network accepts the remote UE 102 to join the relay chain, or when the remote UE 102 performs indirect registration via the relay UE 701. Once the relay UE 701 receives a paging message, it identifies which specific UEs are paged and forwards the paging message to each UE via the PC5 link.

[0359] Registration update via PC5 with the relay UE

[0360] The following describes an example embodiment where the remote UE 102 can initiate a registration update process by sending a request message to the relay UE 701, and then the relay UE 701 will report the registration update status of one or more UEs to the network at a preconfigured time. Generally, when the registration update timer expires, the UE will send a request message to the AMF 172 via the NAS connection to initiate the registration update process. In the context of multi-hop relay, before the timer expires, the remote UE 102 can alternatively choose to send the request message to the relay UE 701 via the PC5 link. This helps reduce signaling overhead for cases where there are no changes or any new requests from the remote UE 102.

[0361] The relay UE 701 can report to the AMF 172 when performing its own registration update process or at a preconfigured time. For example, when the remote UE 102 wakes up and is available to receive any control messages or user data, the remote UE 102 can specify a time point together with the registration update message reported by the relay UE 701 to the AMF 172. The core network can configure the relay UE 701 such that when the relay UE 701 initiates its own registration update process, the relay UE 701 reports any registration updates on behalf of the UEs in the relay chain. This effectively means that the registration update process is aggregated by the relay UE 701 and the relay UE 701 reports to the network simultaneously.

[0362] Alternatively, the relay UE 701 or the core network may decide that the relay UE 701 can perform a registration update for all or some of the UEs in the relay chain led by the relay UE. Then, the relay UE 701 and the corresponding remote UE 102 may perform some PC5 procedures for registration update purposes at the configured time, and the relay UE 701 may report the registration update status to the core network on behalf of these UEs at the configured time point. Note that these two time points may be different and not necessarily sequential.

[0363] The remote UE 102 may include the following information in the registration update message sent to the relay UE 701 via the PC5 link:

[0364] · Remote UE ID

[0365] · Registration update timer: If the relay UE is to report the registration update status of the remote UE to the network, the remote UE will inform the relay UE of its timer so that the relay UE can timely let the network know the registration status of the remote UE.

[0366] · Any status update of the remote UE

[0367] · Any request to change the network configuration at the remote UE

[0368] The remote UE 102 may choose to use the PC5 control plane or user plane to send the registration update request message. If the control plane is used, a regular control message is transmitted together with the type setting to the registration update request. If the user plane is used, the registration update request may be encapsulated in a regular data message, and the remote UE indicates to the relay UE that the registration update request is encapsulated as the payload.

[0369] Core network functions (e.g., AMF, PCF) may enable / disable this feature by configuring the multi-hop relay policy and registration management configuration when the remote UE 102 joins the relay chain or when the relay chain is formed. For example, the AMF 172 may indicate to the remote UE 102 and the relay UE 701 whether the remote UE 102 is allowed to perform a registration update with the relay UE via PC5 and specify some conditions, such as only when there is no status change and no request from the remote UE 102. Additionally, the AMF 172 may allocate 2 different timers to the remote UE 102 for registration updates with the relay UE 701 and the AMF 172 respectively. Alternatively, the core network may allocate 1 timer regardless of the way determined by the remote UE 102.

[0370] The core network may perform such configuration through various procedures such as the registration procedure, service request procedure, and UE configuration update procedure.

[0371] User interface

[0372] Figure 19 The figure illustrates an exemplary user interface according to an example embodiment. Parameters defined for multi-hop relay configuration can be provided by an end user, a network operator, or an application service provider via the user interface. Additionally, the relay UE 701 or the network operator can retrieve and display relay statistics via the user interface 1901. A user interface screen instance 1901 can be presented for configuring or programming these parameters with default values and for enabling or disabling the relay service. A user can select a multi-hop configuration display screen instance input selection 1902. The selection 1902 can result in a new display screen instance 1903 that includes user type options, where the user type options include a service provider option 1904, a terminal device option 1905, and a network operator option 1906. Each presented option can be presented with a corresponding selection input 1907, 1908, and 1909. When the corresponding selection input is received, a relay configuration screen instance 1910 can be presented. The screen instance 1910 can include a configuration title 1911 and details 1912.

[0373] It should be understood that any method and process described herein can be embodied in the form of computer-executable instructions (i.e., program code) stored on a computer-readable storage medium, which, when executed by a machine (such as a computer, a server, an M2M terminal device, an M2M gateway device, etc.), perform and / or implement the systems, methods, and processes described herein. Specifically, any step, operation, or function described above can be implemented in the form of such computer-executable instructions. A computer-readable storage medium includes volatile and non-volatile, removable and non-removable media implemented by any method or technology for the storage of information, provided that such computer-readable storage medium does not include signals. A computer-readable storage medium includes (but is not limited to) RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or any other physical medium that can be used to store the desired information and that can be accessed by a computer.

[0374] In describing the preferred embodiments of the subject matter of the present disclosure illustrated in the figures, specific terms are employed for the sake of clarity. However, the claimed subject matter is not intended to be limited to the specific terms so selected, and it should be understood that each specific element includes all technical equivalents that operate in a similar manner to achieve a similar purpose.

[0375] Accordingly, those skilled in the art will recognize that the disclosed systems and methods may be embodied in other specific forms without departing from their spirit or essential characteristics. Thus, the presently disclosed embodiments are considered illustrative in all respects and not restrictive. It is not exhaustive and does not limit the disclosure to the precise forms disclosed. Given the above teachings, various modifications and variations are possible, or may be obtained from the practice of the disclosure, without departing from the breadth or scope of the disclosure. Accordingly, although specific configurations are discussed herein, other configurations may also be employed. The disclosure enables numerous modifications and other embodiments (e.g., combinations, rearrangements, etc.), and such numerous modifications and other embodiments are within the scope of those of ordinary skill in the art and are considered to fall within the scope of the disclosed subject matter and any equivalents thereof. The features of the disclosed embodiments may be combined, rearranged, omitted, etc. within the scope of the invention to produce additional embodiments. Additionally, certain features may sometimes be advantageously used without corresponding use of other features. Thus, the applicant intends to include all such substitutions, modifications, equivalents, and variations within the spirit and scope of the disclosed subject matter.

[0376] References to singular elements do not mean "one and only one" unless expressly stated otherwise, but rather "one or more." Additionally, in the case of using phrases similar to "at least one of A, B, or C" in the claims, the intention is for the phrase to be interpreted to mean that A may exist alone in an embodiment, B may exist alone in an embodiment, C may exist alone in an embodiment, or any combination of elements A, B, and C may exist in a single embodiment; e.g., A and B, A and C, B and C, or A and B and C.

[0377] Unless a claim element is expressly recited herein using the phrase "means for...", the claim element should not be construed under the provisions of 35 U.S.C. 112(f). As used herein, the terms "comprises," "comprising," or any other variation thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a series of elements does not include only those elements but may include other elements not expressly listed or inherent to the process, method, article, or apparatus. The scope of the invention is indicated by the appended claims. The scope includes all embodiments covered by the description herein. The meaning and scope thereof, as well as the scope of equivalents, are intended to be included therein.

[0378] In this specification, the term "UE" may be interchanged with the broader term "electronic device" and vice versa, such that various applications and functions enabled by the present disclosure may be covered.

[0379] In an exemplary embodiment, a method for forming a multi-hop relay chain in a wireless communication network includes discovering, via a remote user equipment (UE), one or more other UEs within the communication range of the remote UE; selecting one of the discovered UEs as an intermediate UE for communicating in the multi-hop relay chain; after selecting the intermediate UE, sending, via the remote UE, a request to join or form a multi-hop relay chain; and joining an existing relay chain or forming a new relay chain within the wireless communication network by establishing a PC5 link with the remote UE.

[0380] In an exemplary embodiment, the method further includes discovering an existing multi-hop relay chain and the one or more other UEs; and initiating a PC5 link to join the intermediate UE to the multi-hop relay chain.

[0381] In an exemplary embodiment, the method further includes determining whether the remote UE has registered with the network; and in response to a determination that the remote UE has not registered with the network, sending a registration request together with the PC5 link request.

[0382] In an exemplary embodiment, the method further includes registering the remote UE with the network; and after registering the remote UE with the network, establishing a PC5 link as a result of the registration.

[0383] In an exemplary embodiment, the method further includes registering the remote UE with the wireless communication network after establishing the PC5 link.

[0384] In an exemplary embodiment, a method for registering a user equipment (UE) to enable multi-hop relay services in a wireless communication network includes sending a registration request message to the wireless communication network, the registration request message requesting the network to enable multi-hop relay services; providing an indication to the network of a role that the UE requests to perform in the multi-hop relay services, the role being one of a remote UE and an intermediate UE; sending, under a condition that the role of the UE will be a remote UE, a first set of predetermined information about remote UE characteristics from the UE; and sending, under a condition that the role of the UE will be an intermediate UE, a second set of predetermined information about intermediate UE characteristics from the UE.

[0385] In an exemplary embodiment, the method, wherein the sending includes sending the request message directly or indirectly via another UE.

[0386] In an exemplary embodiment, the method, wherein sending the registration request message to the network includes sending a policy container in the registration request message.

[0387] In an exemplary embodiment, the method includes receiving a multi-hop relay policy at the UE via a non-access stratum (NAS) connection.

[0388] In an exemplary embodiment, a method for maintaining a multi-hop relay chain in a wireless communication network includes reorganizing, by an intermediate user equipment (UE), the multi-hop relay chain, the reorganization including sending a PC5 link establishment message to include at least another intermediate UE in the multi-hop relay chain; and relaying information from a remote UE to the network via the at least another intermediate UE.

[0389] In an exemplary embodiment, a method for maintaining a multi-hop relay chain in a wireless communication network includes, when providing communication from a remote UE to the wireless communication network via the multi-hop relay chain, selecting an alternative user equipment (UE) to replace an existing intermediate UE, the selection including selecting from the remaining UEs in the multi-hop relay chain or UEs outside the multi-hop relay chain, wherein the selection includes selection by at least one of a core network, a base station, and a remaining UE.

[0390] In an exemplary embodiment, a method for registration management and connection management in a wireless communication network includes updating connection management and registration management parameters at a core network asset in response to a registration request for a new multi-hop relay chain or for joining an existing multi-hop relay chain; sending a configuration update to an intermediate user equipment (UE); storing, by the intermediate UE, the connection management and registration management parameters; and sending, from the intermediate UE, the connection management and registration management parameters to other UEs in the new or existing multi-hop relay chain.

[0391] In an exemplary embodiment, the method, wherein the core network asset hosts an access and mobility management function (AMF).

[0392] The method further includes receiving, by the intermediate UE, a multi-hop relay policy; and sending an N2 paging message targeting one or more UEs in the new or existing multi-hop relay chain to a RAN node.

[0393] In an exemplary embodiment, the method, wherein the N2 paging message is group-based N2 messaging, wherein only one N2 connection is established between the core network asset and the RAN node for the intermediate UE and all other UEs in the new or existing multi-hop relay chain.

[0394] In an exemplary embodiment, the method, wherein the N2 paging message creates an N2 connection for each intermediate UE in the new or existing multi-hop relay chain.

[0395] In an exemplary embodiment, the method, wherein the intermediate UE calculates a paging occasion for the remote UE and monitors each paging message for the remote UE.

[0396] In an exemplary embodiment, a method for forming a multi-hop relay chain includes discovering one or more other UEs within a communication range via a remote UE; selecting one of the discovered UEs as an intermediate UE for communicating in the network; after selecting the intermediate UE, sending a request to establish a PC5 link via the remote UE; and establishing a PC5 link with the remote UE to join or form a multi-hop relay chain within the network.

[0397] In an exemplary embodiment, a user equipment (UE) (e.g., a relay UE) assists a remote UE that is farther from the UE in terms of the signal coverage of a wireless communication network to access relay services provided by the wireless communication network (e.g., Figure 13 , Figure 14 , Figure 15 , Figure 16( Figure 16A - 16B ). The relay UE may receive (e.g., Figure 1E : 125a, 125b, 128) a PC5 link establishment request message from the remote user equipment (e.g., Figure 13 , Figure 14 , Figure 15 , Figure 16( Figure 16A - 16B ). The reception may occur via a sidelink interface. The relay UE may determine whether there is a relay chain association for the remote UE, including (e.g., Figure 13 , Figure 14 , Figure 15 , Figure 16( Figure 16A - 16B ) by determining whether to accept the remote UE to join the relay chain (e.g., Figure 13 , Figure 14 , Figure 15 ) or determining whether to assume the role of a relay UE for the requested remote UE (e.g., Figure 16( Figure 16A - 16B ). The relay UE may then send a PC5 link establishment response message to the remote UE based on the relay chain association determination.

[0398] In an exemplary embodiment, the relay UE may send a request message to join the relay chain to the wireless communication network, where the request message to join the relay chain includes a registration request message requesting the network to enable multi-hop relay services for the remote UE (e.g., Figure 13 ). The relay UE may provide an indication of the role that the UE requests to play in the multi-hop relay service to the wireless communication network, and the role is a remote UE role or a relay UE role. The relay UE may determine whether to accept the remote UE to join the relay chain, and then establish a PC-5 link with the remote UE. The relay UE may receive a response to join the relay chain from the wireless communication network via a non-access stratum (NAS) connection.

[0399] In an exemplary embodiment, when the relay UE determines whether there is a relay chain association for the remote UE, the relay UE may (e.g., Figure 13 , Figure 14 , Figure 15 , Figure 16( Figure 16A - 16B )) determine whether to accept the remote UE to join the relay chain through its control circuit (e.g., Figure 13 , Figure 14 , Figure 15 ). In this case, the PC5 link establishment request message may include an encapsulated request to join the relay chain, which indicates a request to join the relay chain, and the relay chain is an existing relay chain that existed before receiving the PC5 link establishment request message, and the existing relay chain is discovered by the remote UE (e.g., Figure 10 or Figure 11 ). The PC5 link establishment request message may include a relay chain ID indicating the existing relay chain. The PC5 link establishment request message may include an encapsulated network registration request indicating the layer 2 ID of the remote UE (e.g., Figure 13 , Figure 14 ).

[0400] In an exemplary embodiment, the PC5 link establishment request message may include a relay policy ID, a relay UE ID, an application ID or an application service provider ID, and a data network name (DNN) ( Figure 13 , Figure 14 ).

[0401] In an exemplary embodiment, determining whether to accept the remote UE to join the relay chain includes considering any one or more of the following: relay capabilities, the relay load status of the existing relay chain, the configuration of the relay policy, power consumption, having operation characteristics consistent with the remote UE, security requirements (e.g., 184-189, Figure 13 , Figure 14 ).

[0402] In an exemplary embodiment, the relay UE may set up a paging process for a UE that is part of an existing relay chain, including sending a paging message to one or more unreachable UEs in the multi-hop relay chain, including message transmission through the N2 interface (e.g., Figure 2 - 3 ).

[0403] In an exemplary embodiment, the relay UE may receive a registration update message from the remote UE, forward the registration update message to the network on behalf of the remote UE, receive a registration update response from the network, and report the registration update status to the UEs in the relay chain.

[0404] In an exemplary embodiment, determining whether there is a relay chain association for the remote UE includes directly sending the information indicated in the PC5 link establishment request message to a network node of the wireless communication network, and the relay service may be a one-hop relay service or a multi-hop relay service (e.g., Figure 13 , Figure 14 , Figure 15 , Figure 16( Figure 16A - 16B ). In the case where there is an intermediate UE in the relay chain, the relay service may be designated as a multi-hop relay service.

[0405] In an exemplary embodiment, determining whether there is a relay chain association for the remote UE includes indirectly sending the information indicated in the PC5 link establishment request message to a network node circuit of the wireless communication network via another UE, and the relay service is a multi-hop relay service (e.g., Figure 13 , Figure 14 , Figure 15 , Figure 16( Figure 16A - 16B ).

[0406] In an exemplary embodiment, the relay UE may send a notification message indicating updated relay chain status information.

[0407] In an exemplary embodiment, determining whether there is a relay chain association for the remote UE includes (e.g., Figure 13 , Figure 14 , Figure 15 , Figure 16( Figure 16A - 16B ) a network-assisted relay chain formation process (e.g., Figure 16( Figure 16A - 16B )) or a distributed relay chain formation process (e.g., Figure 13 , Figure 14 , Figure 15 ).

[0408] In an exemplary embodiment, a network node of a wireless communication network may perform a method including communicating with a relay UE or an intermediate UE to assist a remote UE that is farther than the UE in terms of the signal coverage of the wireless communication network to access a relay service, which enables access to other services provided by the wireless communication network (e.g., Figure 13 , Figure 14 , Figure 15 , Figure 16( Figure 16A - 16B ). The method further includes receiving a registration request message having information from a PC5 link establishment request message sent by the remote UE, the registration request message including a request for establishing a new relay chain (e.g., Figure 16( Figure 16A - 16B)) Remote UE new link information for use by the remote UE, and remote UE registration information for requesting registration of the remote UE with the wireless communication network. The method further includes processing the registration process of the remote UE based on the remote UE registration information, and processing the new relay chain formation process of the remote UE based on the remote UE new link information, including obtaining a relay chain configuration containing information identifying the roles of the UE and the remote UE, and obtaining service application information of the new relay chain. The method further includes sending relay chain configuration information to the UE, the relay chain configuration information including the accepted roles of the UE and the remote UE, including a multi-hop relay policy obtained via a non-access stratum (NAS) connection (e.g., Figure 16( Figure 16A - 16B ))。

[0409] In an exemplary embodiment, the remote UE registration information may include a relay UE ID and relay UE capabilities, and a requested relay policy ID (e.g., Figure 16( Figure 16A - 16B )),Determining whether to accept the remote UE into the relay chain may include obtaining any one or more of the following: load information of the relay chain, current traffic and predicted future traffic of UEs in the relay chain, or mobility patterns of UEs in the relay chain (e.g., Figure 16( Figure 16A - 16B ))。

[0410] In an exemplary embodiment, a network node may send a notification message indicating updated relay chain status information (e.g., Figure 17 )。

[0411] In an exemplary embodiment, a remote UE that is further from a potential relay UE in terms of the signal coverage of the wireless communication network may perform a method to access relay services provided by the wireless communication network (e.g., Figure 13 、 Figure 14 、 Figure 15 、Figure 16( Figure 16A - 16B )),The method includes discovering one or more potential relay UEs capable of providing access to relay chain services (e.g., Figure 10 、 Figure 11 )。The method may include selecting one of the one or more potential relay UEs as a target relay UE. The method may include sending a join relay chain request message to the target relay UE. The method may include receiving, from the target relay UE, a join relay chain response originating from the wireless communication network via a non-access stratum (NAS) connection.

[0412] In an exemplary embodiment, the method may include establishing a connection with a relay chain via the target relay UE connected to a node in the wireless communication network, wherein the relay chain join response message includes any one or more of the following: a relay chain ID, a relay policy ID, a remote role indication regarding the remote UE.

[0413] In an exemplary embodiment, the method may include that when none of the one or more potential relay UEs are part of an existing relay chain, the relay chain join request message may include a request for a new relay chain (e.g., Figure 17 , Figure 18 ).

[0414] In an exemplary embodiment, the relay chain join response message may include a relay policy originating from a (PCF) node on a non-access stratum (NAS) connection.

[0415] In an exemplary embodiment, the method may include triggering the establishment of a PC5 link between the remote UE and the target relay UE and triggering the registration process of the remote UE by sending a relay chain join request message.

Claims

1. A method, the method comprises: Receiving a PC5 link establishment request message from a remote electronic device; Sending a PC5 link establishment response message to the remote electronic device; And Sending a join relay chain request message to a wireless communication network.

2. The method according to claim 1, further comprises: Determining whether there is a relay chain association for the remote electronic device, including: Determining whether to accept the remote electronic device to join the relay chain, or Determining whether to assume the role of a relay electronic device for the remote electronic device.

3. The method according to claim 2, further comprises: Providing an indication of the role that the electronic device requests to execute in the multi-hop relay service to the wireless communication network, the role being the remote electronic device role or the relay electronic device role; Determining whether to accept the remote electronic device to join the relay chain; Establishing a PC-5 link with the remote electronic device; and Receiving a join relay chain response from the wireless communication network via a non-access stratum (NAS) connection.

4. The method according to claim 2, wherein the determining whether there is a relay chain association for the remote electronic device comprises: Determining whether to accept the remote electronic device to join the relay chain; And wherein the PC5 link establishment request message includes: An encapsulated join relay chain request, the join relay chain request indicating a request to join a relay chain, the relay chain being an existing relay chain that existed before the PC5 link establishment request message was received and was discovered by the remote electronic device, and Indicating the relay chain ID of the existing relay chain, and An encapsulated network registration request, the network registration request indicating the layer 2 ID of the remote electronic device.

5. The method according to claim 2, wherein the determining whether to accept the remote electronic device to join the relay chain includes considering any one or more of the following: Relay capability, The relay load status of the existing relay chain, The configuration of the relay policy, Power consumption, Having operation characteristics consistent with the remote electronic device, Security requirements.

6. The method according to claim 2, wherein the determining whether there is a relay chain association for the remote electronic device comprises: Directly sending the information indicated in the PC5 link establishment request message to a network node of the wireless communication network, and the relay service is a 1-hop relay service or a multi-hop relay service.

7. The method according to claim 2, wherein the determining whether there is a relay chain association for the remote electronic device comprises: Indirectly sending the information indicated in the PC5 link establishment request message to a network node circuit of the wireless communication network via another electronic device, and the relay service is a multi-hop relay service.

8. The method according to claim 2, wherein the determining whether there is a relay chain association for the remote electronic device comprises: A network-assisted relay chain formation process or a distributed relay chain formation process.

9. The method according to claim 1, wherein the join relay chain request message includes a registration request message for requesting the wireless communication network to enable a multi-hop relay service.

10. The method according to claim 1, wherein the PC5 link establishment request message includes: Relay policy ID, relay electronic device ID, application ID or application service provider ID, and data network name DNN.

11. The method according to claim 1, further comprising: Setting up a paging process for an electronic device that is part of an existing relay chain, including sending a paging message to one or more unreachable electronic devices in a multi-hop relay chain, including message transmission on the N2 interface.

12. The method according to claim 1, further comprising: Receiving a registration update message from a remote electronic device; Forwarding the registration update message on behalf of the remote electronic device to the wireless communication network, Receiving a registration update response from the wireless communication network, and Reporting the registration update status to the electronic devices in the relay chain.

13. The method according to claim 1, further comprising: Sending a notification message indicating updated relay chain status information.

14. A wireless transmit / receive unit WTRU, comprising a processor and a memory, wherein the processor and the memory are configured to: Receive a PC5 link establishment request message from a remote electronic device; Send a PC5 link establishment response message to the remote electronic device; and Send a join relay chain request message to the wireless communication network.

15. The WTRU according to claim 14, wherein the WTRU is further configured to determine whether there is a relay chain association for the remote electronic device.

16. The WTRU according to claim 15, wherein the WTRU is further configured to determine whether to accept the remote electronic device to join the relay chain, or determine whether to assume the role of a relay electronic device for the remote electronic device.

17. The WTRU according to claim 16, wherein the WTRU is further configured to: Provide an indication of the role that the electronic device requests to perform in the multi-hop relay service to the wireless communication network, the role being a remote electronic device role or a relay electronic device role; Determine whether to accept the remote electronic device to join the relay chain; Establish a PC-5 link with the remote electronic device; and Receive a join relay chain response from the wireless communication network via a non-access stratum NAS connection.

18. A method performed by a remote electronic device to obtain access to a relay service provided by a wireless communication network, the remote electronic device having a signal coverage range with respect to the wireless communication network that is farther than that of potential relay electronic devices, the method comprising: Discovering one or more potential relay electronic devices capable of providing access to the relay chain service; Selecting one of the one or more potential relay electronic devices as a target relay electronic device; Sending a join relay chain request message to the target relay electronic device; Receiving a join relay chain response having information originating from the wireless communication network from the target relay electronic device via a non-access stratum NAS connection; and Establishing a connection to the relay chain via the target relay electronic device connected to a node in the wireless communication network.

19. The method according to claim 18, wherein the join relay chain response message includes any one or more of the following: Relay chain ID, Relay policy ID, Remote role indication for the remote electronic device.

20. The method according to claim 18, further comprising: When none of the one or more potential relay electronic devices is part of an existing relay chain, the join relay chain request message includes a request for a new relay chain.

21. The method according to claim 18, wherein the join relay chain response message comprises: A relay policy originating from a (PCF) node on a non-access stratum (NAS) connection.

22. The method according to claim 18, further comprising: By sending a join relay chain request message, triggering the establishment of a PC5 link between a remote electronic device and a target relay electronic device and triggering the registration process of the remote electronic device.

23. A method, comprising: Selecting one or more relay electronic devices; Sending a registration request message to each of the one or more relay electronic devices, wherein each of the one or more relay electronic devices is associated with a wireless transmit / receive unit (WTRU) ID, and wherein each of the one or more relay electronic devices sends a registration request message to the network; Receiving a plurality of registration acceptance messages from each of the one or more relay electronic devices; and Selecting a registration acceptance message from the plurality of received registration acceptance messages.

24. The method according to claim 23, wherein the registration request message includes a PC5 link establishment request message.

25. The method according to claim 23, wherein the one or more relay electronic devices are served by one or more access and mobility management functions (AMFs) of the network.

26. The method according to claim 23, wherein the method further comprises: Notifying the network by giving the WTRU ID of the selected relay electronic device associated with the selected registration acceptance message.

27. The method according to claim 26, wherein the method further comprises: Giving the AMF ID together with the WTRU ID of the selected relay electronic device associated with the selected registration acceptance message.