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, a multi-hop relay chain is formed and maintained, which solves the problems of multi-hop relay chain management and maintenance in the prior art, and improves the energy efficiency and coverage of the network.

CN113748619BActive Publication Date: 2025-03-14INTERDIGITAL PATENT HOLDINGS INC
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202080029697.9
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2019-05-01
Filing Date
2020-05-01
Publication Date
2025-03-14
Estimated Expiration
2040-05-01

AI Technical Summary

Technical Problem

There is a lack of effective methods in existing 5G networks to form and manage multi-hop relay chains, especially when remote user equipment exceeds the coverage range, it is difficult to maintain the relay chain and switch the UE.

Method used

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

Benefits of technology

The multi-hop relay chain is formed and maintained in the 5G network, the energy efficiency and coverage of the network are improved, and the ability to switch and manage when the UE exceeds the coverage range.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN113748619B_ABST
    Figure CN113748619B_ABST
Patent Text Reader

Abstract

A method for forming a multi-hop relay chain in a wireless communication network, comprising discovering one or more other electronic devices within the communication range of the remote electronic device via a remote electronic device; selecting one of the discovered electronic devices as a relay electronic device for communicating in the multi-hop relay chain; after selecting the relay electronic device, sending a request to establish a PC5 link via the remote 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] Citation of Related Applications

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

[0003] The present disclosure relates generally to wireless communications, and more particularly to wireless communication systems, devices, methods, and computer-readable media regarding multi-hop relays in 5G networks. Background Art

[0004] The "background technology" description provided here is for the purpose of generally presenting the context of the present disclosure. To the extent described in this background technology section, the work of the presently named inventors, as well as various aspects of the description that may not constitute prior art at the time of filing this application, are neither explicitly nor implicitly admitted to be prior art against the present invention.

[0005] There are currently architectures and mechanisms for relaying multi-hop relays and incorporating them into 5G, which are intended to help improve the energy efficiency and coverage of 5G systems. However, for 5G, there are many problems associated with multi-hop relays. For example, current approaches 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. In addition, for multi-hop relay chain maintenance, there is no solution on how to switch the affected UEs to a new or existing relay chain, and whether and how to give the relay UE 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. Therefore, new methods are needed to address these problems. Summary of the invention

[0006] An exemplary embodiment of the present disclosure provides a method for forming a multi-hop relay chain in a wireless communication network, comprising discovering, via a remote user equipment (UE), one or more other UEs within a 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 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.

[0007] An exemplary embodiment of the present disclosure provides a method for registering a user equipment (UE) to enable a multi-hop relay service in a wireless communication network, comprising 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 the multi-hop relay service; providing an indication to the network of a role that the UE requests to perform in the multi-hop relay service, 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 under 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 under the condition that the role of the UE will be an intermediate UE.

[0008] An exemplary embodiment of the present disclosure provides a method for maintaining a multi-hop relay chain in a wireless communication network, comprising reorganizing the multi-hop relay chain by an intermediate user equipment (UE), wherein the reorganization includes 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 a network via the at least another intermediate UE.

[0009] A method for maintaining a multi-hop relay chain in a wireless communication network, comprising selecting an alternative user equipment (UE) to replace an existing intermediate UE when providing communication from a remote UE to the wireless communication network via the multi-hop relay chain, wherein the selection includes selecting from the remaining UEs in the multi-hop relay chain or from the 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.

[0010] A method for registration management and connection management in a wireless communication network, comprising updating connection management and registration management parameters at a core network asset in response to a registration request to form a new multi-hop relay chain or to join 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 a new or existing multi-hop relay chain.

[0011] A method for assisting a remote UE whose signal coverage range is farther than that of the UE with respect to a wireless communication network to access a relay service provided by a wireless communication network. The method comprises: 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 remote UE making the request. The method comprises sending a PC5 link establishment response message to the remote UE based on the relay chain association determination.

[0012] 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 also includes receiving a registration request message having information derived 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 being used to request the establishment of a new relay link for use by the remote UE, the remote UE registration information being used to request the remote UE to be registered with the wireless communication network. The method also includes processing a registration process of the remote UE based on the remote UE registration information, and processing a new relay link formation process 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 also 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 strategy obtained via a non-access stratum (NAS) connection.

[0013] 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 that can provide access to a relay chain service, selecting one of the one or more potential relay UEs as a target relay UE, sending a join relay chain request message to the target relay UE, and receiving a join relay chain response from the target relay UE via a non-access stratum (NAS) connection, originating from the wireless communication network.

[0014] This summary is provided to introduce some embodiments described herein in a simplified form, which together with other embodiments will be further described in the detailed description below. This summary is neither intended to identify key features or essential features of the claimed subject matter nor to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that address any or all deficiencies mentioned in any part of this disclosure.

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

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

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

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

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

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

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

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

[0023] Figure 1G is a system diagram illustrating an example of a computing system for use in a communications network;

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

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

[0026] Figure 4 The diagram illustrates NAS transport for SM, SMS, UE policy and LCS. It is worth noting that according to an exemplary embodiment, mobility management and session management functions can be separated;

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

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

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

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

[0031] Fig. 9illustrates a user plane protocol stack for layer 2 relay according to an exemplary embodiment;

[0032] Fig.10 illustrates the overall process of LTE ProSe discovery model A according to an exemplary embodiment;

[0033] Fig.11 illustrates the overall process of LTE ProSe discovery model B according to an exemplary embodiment;

[0034] Figure 12 Figures 12A-12C ) illustrates a general registration process in which multi-hop relaying may be enabled according to an exemplary embodiment;

[0035] Fig.13 illustrates a process in which registration may first be performed according to an exemplary embodiment;

[0036] Fig.14 Illustrate a process in which a PC5 link is first established according to an exemplary embodiment;

[0037] Fig.15 illustrates a process of joining an existing relay chain according to an exemplary embodiment;

[0038] Figure 16 Figures 16A-16B ) illustrates a process of network-assisted relay chain formation according to an exemplary embodiment;

[0039] Fig.17 illustrates a process of selecting a new relay UE according to an exemplary embodiment;

[0040] Fig.18 illustrates a process in which the AMF sets the RM / CM configuration for a UE in a relay chain according to an exemplary embodiment; and

[0041] Fig.19 An exemplary user interface is illustrated in accordance with an exemplary embodiment.

[0042] Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter.It should be understood that the detailed description of the exemplary embodiments is only for illustration and thus is not necessarily intended to limit the scope of the present disclosure. DETAILED DESCRIPTION

[0043] The Third Generation Partnership Project (3GPP) develops technical standards for cellular telecommunication 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 referred to as 3G), Long Term Evolution (LTE) (commonly referred to 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 next generation radio access technologies (new RATs), which are expected to include the provision of new flexible radio access below 7 GHz, and the provision of new ultra-mobile broadband radio access above 7 GHz. 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. Ultra-mobile broadband is expected to include cmWave and mmWave spectrum, which will provide opportunities for ultra-mobile broadband access for, for example, indoor applications and hotspots. In particular, ultra-mobile broadband is expected to share a common design framework with sub-7 GHz flexible radio access, with cmWave- and mmWave-specific design optimizations.

[0044] 3GPP has identified a variety of use cases that the New Radio (NR) is expected to support, resulting in a wide variety of user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (eMBB) ultra-reliable low latency communications (URLLC), massive machine type communications (mMTC), network operations (e.g., network slicing, routing, migration and interworking, energy saving), and enhanced vehicle-to-everything (eV2X) communications, which can include any of vehicle-to-vehicle communications (V2V), vehicle-to-infrastructure communications (V2I), vehicle-to-network communications (V2N), vehicle-to-pedestrian communications (V2P), and communications between vehicles and other entities. Specific services and applications in these categories include, for example, surveillance and sensing networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud office, first responder connectivity, car emergency calls, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile Internet, virtual reality, home automation, robotics, and aerial drones, to name a few. All of these use cases and others are contemplated herein.

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

[0046] Abbreviations

[0047]

[0048]

[0049]

[0050]

[0051] Example Communication Systems and Networks

[0052] Figure 1A An example communication system 100 is illustrated in which the systems, methods, and apparatus 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 a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and network services 113. The network services 113 may include, for example, a V2X server, a V2X function, a proximity area service (ProSe) server, a ProSe function, IoT services, video streaming, and / or edge computing, etc.

[0053] 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. Figure 1A In the example of Figures 1A-1E . It should be understood that, for various use cases contemplated for wireless communication, each WTRU may include or be included in any type of device or apparatus configured to send and / or receive wireless signals, including, by way of example only, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smart phone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronic product, a wearable device (such as a smart watch or smart clothing), a medical or e-health device, a robot, an industrial equipment, a drone, a vehicle such as a car, bus or truck, a train, or an airplane, etc.

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

[0055] The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, network services 113, and / or other networks 112. The roadside units (RSUs) 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or network services 113. By way of example, the base stations 114a, 114b may 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, and the like.

[0056] The base station 114a may 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 a base station controller (BSC), a radio network controller (RNC), a relay node, etc. Similarly, the base station 114b may be part of a RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as a BSC, an RNC, a relay node, etc. The base station 114a may be configured to send and / or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). Similarly, the base station 114b may be configured to send and / or receive wired and / or wireless signals within a specific geographic area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, for example, the base station 114a may include three transceivers, eg, one transceiver for each sector of the cell. The base station 114a may employ multiple-input multiple-output (MIMO) technology and thus, for example, may use multiple transceivers for each sector of the cell.

[0057] The base station 114a may communicate with one or more of the wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and 102g via an air interface 115 / 116 / 117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0058] The base station 114b may communicate with one or more of the RRHs 118a and 118b, the TRPs 119a and 119b, and / or the RSUs 120a and 120b via a wired or air interface 115b / 116b / 117b, which may be any suitable wired (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., RF, microwave, IR, UV, visible light, cmWave, mmWave, etc.). The air interface 115b / 116b / 117b may be established using any suitable RAT.

[0059] The RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a, 120b may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f via an air interface 115c / 116c / 117c, which may be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, cmWave, mmWave, etc.). The air interface 115c / 116c / 117c may be established using any suitable RAT.

[0060] The WTRUs 102 may communicate with each other via a direct air interface 115d / 116d / 117d, such as a sidelink communication, and the air interface 115d / 116d / 117d may be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, cmWave, mmWave, etc.). The air interface 115d / 116d / 117d may be established using any suitable RAT.

[0061] The communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the 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 the RAN 103b / 104b / 105b and the WTRUs 102c, 102d, 102e, and 102f may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interfaces 115 / 116 / 117 and / or 115c / 116c / 117c, respectively. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0062] The base station 114a in the 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 and the WTRUs 102c and 102d in the RAN 103b / 104b / 105b may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish an air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively, using, for example, Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A). The air interface 115 / 116 / 117 or 115c / 116c / 117c may implement 3GPP NR technology. LTE and LTE-A technologies may include LTE D2D and / or V2X technologies and interfaces (such as sidelink communications, etc.). Similarly, 3GPP NR technologies may include NR V2X technologies and interfaces (such as sidelink communications, etc.).

[0063] The base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, and 102g, or the RRHs 118a and 118b, the RPs 119a and 119b and / or the RSUs 120a and 120b and the WTRUs 102c, 102d, 102e, and 102f in the RAN 103b / 104b / 105b may implement a radio technology such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, 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.

[0064] Figure 1AThe base station 114c in the example 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 business 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., WTRU 102e) can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). Similarly, the base station 114c and the WTRU 102 (e.g., WTRU 102d) can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). The base station 114c and the WTRU 102 (e.g., 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. Figure 1A As shown in FIG, the base station 114c may have a direct connection to the Internet 110. Thus, the base station 114c may not be required to access the Internet 110 via the core network 106 / 107 / 109.

[0065] The RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b may be in communication with a core network 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, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication.

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

[0067] The core network 106 / 107 / 109 may also serve as a gateway for the WTRU 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), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The other networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 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, which may use the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT.

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

[0069] Although not in Figure 1A 106 / 107 / 109. Although not shown in the figure, the user equipment can establish a wired connection to the gateway. The gateway can be a residential gateway (RG). The RG can provide connectivity with the core network 106 / 107 / 109. Many of the embodiments included in this document can be equally applied to UEs that are WTRUs and UEs that use wired connections to connect to the network. For example, the concepts applied to wireless interfaces 115, 116, 117 and 115c / 116c / 117c can be equally applied to wired connections.

[0070] Figure 1B 1 is a system diagram of an example RAN 103 and a core network 106. As described above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. Figure 1BAs shown in FIG. 1 , the RAN 103 may include Node-Bs 140a, 140b, and 140c, which 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 particular 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).

[0071] like Figure 1B As shown in , Node-B 140a, 140b can communicate with RNC 142a. In addition, Node-B 140c can communicate with RNC 142b. Node B 140a, 140b and 140c can communicate with corresponding RNC 142a and 142b via Iub interface. RNC 142a and 142b can communicate with each other via Iur interface. Each of RNC 142a and 142b can be configured to control the corresponding Node-B 140a, 140b and 140c that it can be connected to. In addition, each of RNC 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 function, data encryption, etc.

[0072] Figure 1B The core network 106 shown in FIG. 1 may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. Although each of the above elements is depicted as part of the core network 106, any of these elements may be owned and / or operated by an entity other than the core network operator.

[0073] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communications devices.

[0074] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and IP-enabled devices.

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

[0076] Figure 1C 1 is a system diagram of an example RAN 104 and a core network 107. As described above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

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

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

[0079] Figure 1C The core network 107 shown in FIG. 1 may 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 may be owned and / or operated by an entity other than the core network operator.

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

[0081] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an 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 inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, and 102c, managing and storing the contexts of the WTRUs 102a, 102b, and 102c, and the like.

[0082] 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 packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0083] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communications devices. For example, the core network 107 may include or may communicate with 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. In addition, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0084] Figure 1D1 is a system diagram of an example RAN 105 and a core network 109. The RAN 105 may employ NR radio technology to communicate with the WTRUs 102a and 102b over the air interface 117. The RAN 105 may also be in communication with the core network 109. A non-3GPP interworking function (N3IWF) 199 may employ non-3GPP radio technology to communicate with the WTRU 102c over the air interface 198. The N3IWF 199 may also be in communication with the core network 109.

[0085] 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 over the air interface 117. When an integrated access and backhaul connection is used, the same air interface may be used between the WTRUs and the gNode-Bs, which may be a 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 may, for example, use multiple antennas to send 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 an eNode-B. It should also be appreciated that the RAN 105 may employ more than one type of base station. For example, the RAN may employ both eNode-Bs and gNode-Bs.

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

[0087] 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. Figure 1D As shown in FIG. , gNode-Bs 180a and 180b may communicate with each other, for example, via an Xn interface.

[0088] Figure 1DThe core network 109 shown in the figure can be a 5G core network (5GC). The core network 109 can provide numerous communication services to customers interconnected by a radio access network. The core network 109 includes multiple entities that perform the functions of the core network. The terms "core network entity" or "network function" used in this document refer to any entity that performs one or more functions of the core network. It should be understood that such a core network entity can be a logical entity implemented in the form of computer executable instructions (software) stored in a device or computer system (such as a computer system) configured for wireless and / or network communications. Figure 1G The system 90 is shown in the diagram in the memory and executed on its processor.

[0089] exist Figure 1D In the example of , the 5G core network 109 may include access and mobility management function (AMF) 172, session management function (SMF) 174, user plane function (UPF) 176a and 176b, user data management function (UDM) 197, authentication server function (AUSF) 190, network open function (NEF) 196, policy control function (PCF) 184, non-3GPP interworking function (N3IWF) 199, 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 diagram illustrates the network functions being directly connected to each other, although it will be appreciated that they may communicate via a routing agent (such as a diameter routing agent) or a message bus.

[0090] exist Figure 1D In the example of , connectivity between network functions is achieved via a set of interfaces or reference points. Network functions can be modeled, described or implemented as a set of services that are invoked or called by other network functions or services. Invoking network function services can be achieved via direct connections between network functions, exchange of messaging on a message bus, calling software functions, etc.

[0091] The AMF 172 may be connected to the RAN 105 via an N2 interface and may serve as a control node. For example, the AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, 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 generally route and forward NAS packets to and from the WTRUs 102a, 102b, and 102c via the N1 interface. The N1 interface is not used in Figure 1D Shown in.

[0092] The session management function (SMF) 174 may be connected to the AMF 172 via the N11 interface. Similarly, the SMF may be connected to the policy control function (PCF) 184 via the N7 interface and to the user plane functions (UPFs) 176a and 176b via the N4 interface. The SMF 174 may serve as a control node. For example, the SMF 174 may 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.

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

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

[0095] PCF 184 may be connected to SMF 174 via an N7 interface, to AMF 172 via an N15 interface, and to application function (AF) 188 via an N5 interface. The N15 and N5 interfaces are not Figure 1D 1. The PCF 184 may provide policy rules to control plane nodes such as the AMF 172 and the SMF 174, thereby allowing the control plane nodes to implement these rules. The PCF 184 may send the policy to the AMF 172 for the WTRUs 102a, 102b, and 102c so that the AMF may deliver the policy to the WTRUs 102a, 102b, and 102c via the N1 interface. The policy may then be implemented or applied at the WTRUs 102a, 102b, and 102c.

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

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

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

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

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

[0101] 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 running across a single RAN. Network slicing enables operators to create customized networks to provide optimized solutions for different market scenarios with diverse requirements in terms of functionality, performance and isolation, for example.

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

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

[0104] The core network 109 may facilitate communications with other networks. For example, the core network 109 may include, or may communicate with, 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. For example, the core network 109 may include, or may communicate with, a short message service (SMS) service center that facilitates communications via a short message service. For example, the 5G core network 109 may facilitate the exchange of non-IP data packets between the WTRUs 102a, 102b, and 102c and a server or application function 188. In addition, the core network 170 may provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which may include other wired or wireless networks owned or operated by other service providers.

[0105] Described in this article and Figure 1A , 1C The core network entities illustrated in 1D and 1E are identified using the names given to these entities in certain existing 3GPP specifications, but it should be understood that in the future, these entities and functions may be identified by other names, and in future specifications released by 3GPP (including future 3GPP NR specifications), certain entities or functions may be combined. Figure 1A , 1B The specific network entities and functions described and illustrated in 1C, 1D and 1E are provided as examples only, 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).

[0106] Figure 1E The diagram illustrates an example communication system 111 in which the systems, methods, and apparatus 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 gNBs, 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 range of the access network coverage 122. 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.

[0107] WTRUs A, B, C, D, E, and F may communicate with each other via gNB 121 over the Uu interface 129b if they are within the coverage of the access network (in Figure 1EWTRUs 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 access network coverage (e.g., within Figure 1E In the figure, WTRU A, B, C, D, E, and F can communicate with each other, and A, C, D, and E are represented outside the network coverage).

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

[0109] Figure 1F is an example device or apparatus WTRU 102 (e.g., Figure 1A , 1B , 1C, 1D or 1E WTRU 102). Figure 1F As shown in , the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136 and other peripherals 138. The WTRU 102 may include any sub-combination of the above elements. In addition, the base stations 114a and 114b and / or the base stations 114a and 114b may represent nodes such as, but not limited to, a base transceiver station (BTS), a 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., and may include Figure 1F Some or all of the elements depicted in and described herein.

[0110] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors 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 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1F The processor 118 and the transceiver 120 are depicted as separate components, although the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0112] In addition, although the transmit / receive element 122 is Figure 1F Although depicted as a single element in the figure, 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 over the air interface 115 / 116 / 117.

[0113] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate 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 to communicate using the same RAT via multiple beams to different RRHs, TRPs, RSUs, or nodes.

[0114] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a 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 therefrom. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a 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, or the like. The processor 118 may access information from, and store data in, memory that is not physically located in the WTRU 102, such as memory hosted on a server in a cloud or edge computing platform or in a home computer (not shown).

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

[0116] 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) regarding the current location of the WTRU 102. In addition to or in lieu 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) over the air interface 115 / 116 / 117 and / or determine its location based on the timing of receiving signals from two or more nearby base stations. The WTRU 102 may acquire location information by any suitable location-determination method.

[0117] 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.

[0118] 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.

[0119] 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.

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

[0121] 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 circuits that allow information to be stored and retrieved. ROM 93 generally contains stored data that is not easily modified. The data stored in RAM 82 can be read or changed by a processor 91 or other hardware device. Access to 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 a virtual address into a physical address when an instruction is executed. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in the first mode can only access memory mapped by its own process virtual address space; unless memory sharing between processes is set, it cannot access memory within the virtual address space of another process.

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

[0123] The display 86 controlled by the display controller 96 can be used to display the 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 with 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.

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

[0125] 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), causes the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any steps, operations, or functions described herein may be implemented in the form of such computer executable instructions executed on a processor of a device or computing system configured for wireless and / or wired network communications. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any non-temporary (e.g., tangible or physical) method or technology for storage of information, although such computer-readable storage media do not include signals. Computer-readable storage media include (but are not limited to) RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, cassettes, magnetic tape, magnetic disk storage or other magnetic storage, or any other tangible or physical medium that can be used to store the desired information and can be accessed by a computing system.

[0126] 5G Cellular Networks

[0127] Figure 2 The diagram illustrates a 5G system in an example of 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, for example as described in 3GPP standards and as described in Figure 2 The exemplary 5G non-roaming reference architecture includes a network open 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.

[0128] Figure 3The 5G system architecture for non-roaming scenarios is illustrated using reference point representations showing how various network functions interact according to exemplary embodiments. End-to-end communication between applications in the UE and applications in external networks uses services provided by the 3GPP system and optionally uses services provided by a Service Capability Server (SCS) residing in the DN. Figure 3 The diagram illustrates an architecture in which various entities interact with each other through 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 a 5G user plane (UP).

[0129] Data traffic from the UE 102 is sent over the PDU sessions created in the core network. The following network functions play a role in PDU session management within the core network 106 / 107 / 109. Figure 2 A network slice selection function (NSSF) 216 is also included.

[0130] 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.

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

[0132] • Policy and Control Function (PCF) 184: PCF 184 makes authorization and policy decisions for establishing PDU sessions.

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

[0134] • 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.

[0135] Control plane protocol stack

[0136] Figure 4 The diagram illustrates non-access stratum (NAS) transport 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 SM-related messages and procedures for the UE. A single N1 termination point can be located in the AMF. The AMF can forward the 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.

[0137] In addition, 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 services (LCS) between the Gateway Mobile Location Center (GMLC) and the UE.

[0138] Figure 5 A simple architecture model using Proximity Area Service (ProSe) UE-to-network relay according to an exemplary embodiment is illustrated.

[0139] Figure 6 The diagram illustrates a user plane protocol stack for UE to network relay, which applies layer 3 forwarding according to an exemplary embodiment. Figure 5 and 6 , the LTE ProSe UE to Network Relay entity may provide functionality to support connectivity with the network for a remote UE. The ProSe UE to Network Relay may relay unicast traffic (DL and UL) to a remote UE, as well as 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 may be considered a remote UE of the ProSe UE to Network Relay. The remote UE may be located within or outside of the E-UTRAN coverage. If the remote UE maintains both PC5 and Uu, the EPS core network entity on the Uu side of the remote UE is unaware of the ProSe UE to Network Relay path via PC5.

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

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

[0142] Step S703: The remote UE 102 uses Model A or Model B discovery to perform ProSe UE discovery to the network relay.

[0143] 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 relaying is required, the ProSe UE to network relay UE 701 initiates a new PDN connection establishment procedure for relaying.

[0144] Step S705: Allocate an IPv6 prefix or an IPv4 address to the remote UE 102. From this point on, uplink and downlink relaying can begin.

[0145] 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 identity of the remote UE user successfully connected in step 704 (provided via the user information). For the PDN connection associated with the relay chain, the MME 162 stores the Remote User ID and the related IP information in the EPS bearer context of the ProSe UE to Network Relay.

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

[0147] Enhancements to ProSe (Proximity Area Service) UE to Network Relay

[0148] 3GPP SA2 has conducted research on enhancing ProSe UE to network relay with the following objectives:

[0149] Investigate and evaluate necessary enhancements to the EPC to support generic Layer 2 Evolved ProSe UE to Network Relay, including procedures for the network to identify, authenticate, authorize, control, address and reach an Evolved ProSe Remote UE via the Evolved ProSe UE to Network Relay UE.

[0150] Investigate and study enhancements to the existing procedures to authorize a UE to act as an Evolved ProSe UE-to-Network Relay between an Evolved ProSe Remote UE and E-UTRAN.

[0151] Investigate and evaluate necessary enhancements to the evolved ProSe UE to network relay discovery and selection process.

[0152] ·Investigate and research support for service continuity.

[0153] Investigate and study support for power consumption efficiency of Evolved ProSe Long-Range UEs.

[0154] Investigate and study the support of Evolved ProSe long-range UEs (e.g. CIoT UEs) optimized for small data transfer and triggering.

[0155] Figure 8 A control plane protocol stack for enhanced UE-to-network relay is illustrated according to an exemplary embodiment.

[0156] Fig. 9 The diagram illustrates a proposed user plane protocol stack for layer 2 relay according to an exemplary embodiment.

[0157] For example, Figure 8 and Fig. 9 The proposed control plane protocol stack and user plane protocol stack for layer 2 relay are included respectively, 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.

[0158] Study on Enhanced Relay for Energy Efficiency and Wide Coverage (FS_REFEC)

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

[0160] Release 16 service requirements already include the possibility of direct 3GPP communication or indirect 3GPP communication with the help of 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 are identified:

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

[0162] The 5G system shall support gNB to allocate UE relay resource pool according to UE mobility.

[0163] The 5G system should support mobile UE relay to reconfigure its resource pool according to its current location and mobility.

[0164] The 5G system shall support the gNB to allocate and reconfigure UE routing ID according to UE mobility.

[0165] The 5G system should support hop-by-hop UE relay selection based on the long-term cost metric provided by the gNB and the instantaneous relay availability determined by the rapidly changing channel status and buffer load.

[0166] The 5G system should support high-power UEs to schedule the resources of low-power UEs.

[0167] ProSe Discovery

[0168] Fig.10 The diagram illustrates the whole process of ProSe discovery model A according to an exemplary embodiment. A PC5 discovery protocol stack may be defined for the D2D ProSe direct discovery mechanism.

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

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

[0171] Fig.11 The diagram illustrates the entire process of ProSe (Proximity Area Service) discovery model B according to an exemplary embodiment. Discovery model B also defines two roles for participating UEs: discoverer UE and discovered UE. Complete service authorization (S1101). The discoverer UE (e.g., 102) sends a request (S1102) containing 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 is there or are you there", because the discoverer UE sends information to other UEs. Model B only supports restricted discovery types. When matching information is determined, a report is generated (S1108).

[0172] Example Use Case: Problem Statement

[0173] The embodiments described herein can be used to address different use cases, including those described by 5G. As an example, non-limiting use case, consider a company that has a large plant where precursor chemicals are converted into other chemicals for use in highly specialized industries such as pharmaceuticals, plastics, cosmetics, etc. Many of these chemicals are hazardous because they are flammable and / or toxic to humans, and are often corrosive.

[0174] In order to avoid hazards to workers as much as possible, the company uses remote-controlled semi-autonomous robots to carry out the large-scale movement, storage and inspection of chemical barrels (containers) between different warehouses and within the production workshops themselves.

[0175] In addition to the above, containers of chemicals as well as hazmat 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.

[0176] Most of the work is done inside a metal enclosure that can seal in possible chemical leaks. The enclosure walls and the barrel, which is also metal, act as an electromagnetic (EM) shield, which makes signal propagation difficult and unpredictable.

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

[0178] As introduced in this article, some architectures and mechanisms are defined for relays in 3GPP specifications. However, many issues related to multi-hop relays have not been addressed in 5G. Incorporating multi-hop relays 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 relays should be considered as a potential way to meet these requirements. There are some major issues and challenges in deploying multi-hop relays in 5G networks.

[0179] Multi-hop relay chain formation: Once UEs (eg, 102, 701) find themselves in proximity to each other, a general question 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 out of coverage.

[0180] As discussed herein, the present disclosure provides embodiments that enable layer 2 multi-hop relaying. In other words, each UE may be attached or registered with the network directly or indirectly, and may determine how registration and connection management may be performed for each UE in the relay chain.

[0181] Each UE may perform periodic tracking area updates and registration updates. If each UE 102 initiates these processes at different times and relies 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.

[0182] With regard to power saving (e.g., PSM (power saving mode) and discontinuous reception (DRX)) and paging, when different cycles are assigned to different UEs in the relay chain, there may be excessive control signaling for the relay UE 701 to handle. This is especially true when the relay UE 701 needs to listen to incoming paging messages on behalf of the remote UE 102 and forward the paging messages from the network to the paged remote UE 102.

[0183] 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, so that in the context of multi-hop relay, the paging operation can be more efficient for both the network and the relay UE 701.

[0184] Multi-hop relay chain maintenance: In the event that a UE in the middle of a relay chain (which may be described as an intermediate UE) becomes unreachable (e.g. enters idle mode, leaves, or is switched off), the UE 102 needs to be aware of the change and pair itself with another UE (intermediate or relay). This means that the remote UE 102 should try 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, the gNB, the relay UE directly connected to the gNB) is responsible for maintaining the reachability state of the UEs in the relay chain, or multiple parties collaborate with each other for different roles. Some solutions are described herein regarding embodiments of how to switch the affected UEs 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.

[0185] 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 relays can be implemented to meet these requirements.

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

[0187] Registration process for UEs that want to enable multi-hop relay service. New information elements and multi-hop relay strategies are proposed. In addition, a UE can register with the network directly or indirectly via another UE.

[0188] Multi-hop relay strategy can be sent from PCF to UE

[0189] The process of joining and forming a multi-hop relay chain.

[0190] The UE may reuse the PC5 discovery process to discover and select a relay UE and determine if there is an existing multi-hop relay chain.

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

[0192] A method to maintain 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 is turned off or leaves)

[0193] 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 process is proposed:

[0194] A method whereby the network pages multiple UEs in a relay chain over the N2 interface, where the N2 connection is shared by these UEs.

[0195] · A method in which a remote UE performs a registration update procedure with a relay UE via 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.

[0196] In addition, it should be appreciated that the following examples include the following assumptions:

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

[0198] • The relay is a layer 2 relay, ie each UE is required to register with the network.

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

[0200] Registration to enable multi-hop relaying

[0201] Direct registration

[0202] Layer 2 relay requires each UE to register with the network and establish a NAS connection. In addition, in order to use multi-hop relay 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 a registration process.

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

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

[0205] Assuming that the UE initiates the registration procedure by communicating directly with the core network via the RAN node, for example, if the UE 102 wants to act as a remote UE, it needs to provide the following information:

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

[0207] Application service information, such as the application ID and application service provider ID associated with the relayed traffic

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

[0209] QoS requirements for relay traffic, such as data rate and maximum tolerable delay

[0210] Preferred Radio Access Technology (RAT), such as 5G NR, LTE radio, or non-3GPP access (e.g., satellite and WiFi). The UE may also indicate the priority of each possible RAT.

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

[0212] Regional information for relayed traffic: Indicates the region in which relaying is expected to occur or indicates that relaying is limited to that region. Outside of that region, the UE may be able to connect directly to the RAN node, or the UE prefers direct connection to the RAN node.

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

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

[0215] Application service information, such as application ID and application service provider ID, indicating what applications and service traffic the relay UE can relay

[0216] The maximum number of remote UEs and / or intermediate UEs that can connect to the relay UE

[0217] • RATs that can be used for relaying, such as 3GPP access or non-3GPP access.

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

[0219] 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 a relay chain or only between a relay UE and a UE in the relay chain, and whether data communication is allowed between any two UEs in a relay chain or only between a UE and a relay UE.

[0220] If the UE is to act as a relay UE, the 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, and the maximum area that the relay chain can cover. In addition, the relay UE can indicate whether it supports or requires distributed relay chain management.

[0221] Registration / connection management capability, indicating whether the relay UE is able to manage the registration state or connection state of the remote UE, or whether the UE must attach to the network, i.e., whether the UE supports layer 3 relay, layer 2 relay, or both.

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

[0223] The UE may provide the above information in the registration request message (ie, step S1201), or provide part of the information in step S201 and provide additional information in a continued interaction with the network (eg, step S1227) based on a request from the network.

[0224] After the AMF receives the UE policy container information, it triggers the UE policy association establishment / modification process with the PCF 184 depending on whether this is an initial registration or a registration update process. In step S1219, the AMF needs to consider whether the PCF is able to select and provide a multi-hop relay policy during the PCF selection process. The AMF calls the Npcf_UEPolicyControl service with a create or update operation to request the PCF to determine a multi-hop relay policy for the UE. The AMF may do this in step S1226. Alternatively, the AMF may decide to initiate a UE policy association establishment / modification together with step S1220.

[0225] 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).

[0226] Table 1 lists some information that can be included in a 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.

[0227] Table 1: Multi-hop relay strategy

[0228]

[0229]

[0230]

[0231] Indirect registration via relay UE

[0232] Figure 12 Figures 12A-12C) represents a remote UE 102, wherein the information originates from the remote UE 102. In another embodiment, FIG. 12 ( Figures 12A-12C ) can make UE 102 replaced by relay UE 701. For easier understanding, FIG. 12 ( Figures 12A-12C ) represents the identified UE 102, although any UE (remote UE, intermediate UE or relay UE) may replace UE 102.

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

[0234] Relay UE ID, such as 5G Globally Unique Temporary UE Identity (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.

[0235] S-NSSAI and Network Slice Instance (NSI) ID: Identifies the network slice and network slice instance assigned by the network to serve the relay UE during registration. Note that in an embodiment, it is expected that the network assigns the same network slice to serve UEs in a relay chain, however, if this is not possible, the network may attempt to ensure that the same AMF is selected to serve UEs in the same relay chain.

[0236] Multi-hop relay policy ID or reference ID to 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 the multi-hop relay operation from various aspects (such as UE registration update, paging, session management, relay chain formation and management, etc.).

[0237] Multi-hop relay chain ID (if any): identifies the multi-hop relay chain that the relay UE joins

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

[0239] Registration management configuration for relay UEs: 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 configuration for UEs joining the relay chain.

[0240] Discontinuous Reception (DRX) and paging configuration for relay UEs: Used by the AMF to determine the DRX parameters and paging configuration of the remote UE, such as DRX cycle, paging options, and paging timers.

[0241] When the AMF completes the registration process for the remote UE, it will send a request to the relay UE (i.e., Figure 12 ( Figures 12A-12C ) returns a registration acceptance message (ie, step S1225)), and then the relay UE forwards the message to the remote UE via the PC5 connection.

[0242] Multi-hop relay chain formation

[0243] When UEs complete registration with the network, they are authorized to form or join a multi-hop relay chain. The UE can initiate the process of joining a multi-hop relay chain by connecting to a relay UE or an intermediate UE to get in touch with the core network. This section focuses on those processes that are always initiated by a UE that wants to connect to a base station and the core network via a relay UE or an intermediate UE. In general, the following processes can be performed:

[0244] Discovery: The UE needs to discover one or more UEs in the vicinity and select one of the discovered UEs as a relay / intermediate UE towards the network. In addition, during the discovery process, the UE may discover one or more existing relay chains.

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

[0246] New information in PC5 discovery for relay selection

[0247] 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 re-used to discover relay / intermediate UEs and / or any existing multi-hop relay chain. In the context of multi-hop relays, the following new information can be included in the discovery process:

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

[0249] Layer 2 Link ID: This is the ID used for ProSe PC5 communication

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

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

[0252] 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 insert this information into the discovery message. This is helpful for UEs that are out of coverage, as the UE can establish a PC5 link before registering with the network.

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

[0254] Application / Service Type

[0255] Location information

[0256] Supported PC5 protocol stack

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

[0258] The following describes the mechanism by which a remote UE joins or forms a multi-hop relay chain. 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.

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

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

[0261] a. Then, first registration is performed by the network, and then the PC5 link is established based on the configuration as a result of the registration. Fig.13 The process of this embodiment is illustrated.

[0262] b. The second option is to establish the PC5 link first and then register. Fig.14 The process of this embodiment is illustrated.

[0263] 2. The remote UE has registered with the network: Fig.15 The diagram illustrates the process of this scenario embodiment.

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

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

[0266] • Encapsulate the Registration Request. The Registration Request may include the information elements specified herein for enabling the multi-hop relay service.

[0267] A Join Relay Chain Request indicating that the remote UE wants to join an existing relay chain via a relay UE

[0268] The relay chain ID discovered by the remote UE during the PC5 discovery process

[0269] Relay Policy ID: If the remote UE has some pre-configured relay policy, it sends the policy ID to the relay UE

[0270] 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.

[0271] • Remote UE ID: This is a layer 2 ID. Since the remote UE has not registered with the network, it does not have any network assigned UE ID.

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

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

[0274] Step S1302: Since the figure illustrates the situation where registration is performed first, the relay UE 701 decapsulates the registration request and forwards the message to the serving AMF 172. As discussed herein, the relay UE 102 may append some more information to the remote UE's registration request to facilitate the registration process at the AMF 172.

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

[0276] Step S1304: If the registration is successful, the AMF 172 returns a registration acceptance to the relay UE 701. The message may include the remote UE ID assigned by the network, the S-NSSAI assigned to serve the remote UE 102, the relay UE ID, and the 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 UE 102 needs to store, such as URSP and / or multi-hop relay policies, depending on the role of the remote UE 102. In addition, the AMF 172 may send some configurations about CM and RM operations, such as DRX cycle, paging options, and registration update timer values.

[0277] Step S1305: Once the relay UE 701 receives the registration acceptance message about 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:

[0278] Its own relay capabilities, as described further in this article.

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

[0280] Configuration proposed by the relay strategy, such as the maximum number of hops from the core RAN node 105.

[0281] By considering the traffic characteristics of the remote UE, its power consumption and remaining battery power for relaying traffic

[0282] The operating characteristics of the remote UE 102 , such as the DRX cycle, paging options, and registration update timer values, are made consistent with those of the relay UE 701 .

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

[0284] Note that the core network can help make this decision. For example, the network data analysis 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 UEs in the relay chain.

[0285] Step S1306: The relay UE 701 sends a PC5 link establishment response to the remote UE 102, which 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 can send some more information about the CM and RM configurations, such as registration update timers and paging operation options. If the relay UE 701 refuses to accept the remote UE 102 in the relay chain, it will forward the registration acceptance message and notify the remote UE 102 of the rejection decision to join the relay chain and the reason for the rejection in the response message.

[0286] The remote UE 102 may 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 response, the PCF and the relay UE 701 may accept the remote UE into different relay chains and return a response with a different multi-hop relay strategy. In this case, different relay UEs 701 are served by different AMFs 172, that is, the registration request is received by multiple AMFs 172, and when the remote UE 102 receives multiple registration acceptance messages, the remote UE 102 will notify the network by giving the AMF ID and its UE ID to resolve the conflict.

[0287] Fig.14 The diagram illustrates the process of first establishing a PC5 link under the assumption that the relay UE is registered with the network and a relay chain has been formed.

[0288] Step 1401: The remote UE 102 sends a PC5 link establishment request to the selected relay UE 701. This step is similar to Fig.13 The figure illustrates the situation where the PC5 link is first established and mutual authentication is required because the remote UE 102 has not yet registered with the network.

[0289] Step S1402: When receiving the 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 Fig.13 Step S1305 in .

[0290] Step S1403: The relay UE 701 returns a response indicating whether the remote UE 102 is accepted to join the relay chain to the remote UE 102. When 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 layer 2 ID, QoS parameters of the PC5 link, and broadcast / multicast capabilities.

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

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

[0293] Fig.15 The diagram illustrates the process of joining an existing relay chain by establishing a PC5 link, assuming that two UEs have completed registration with the network and have formed a relay chain.

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

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

[0296] Step S1502: The relay UE 701 sends a request to the serving AMF 172 to authenticate the remote UE 102, and optionally retrieves information for determining whether to accept the remote UE 102's request to join the relay chain.

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

[0298] Step S1504: AMF 172 returns the result and information to relay UE 701.

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

[0300] 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, the 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 between the UEs in the relay chain. In the case of non-acceptance, the PC5 link is not established.

[0301] Step S1507: If the remote UE 102 and the relay UE 701 are served by different AMFs, the serving AMF 172 will initiate the AMF reallocation procedure 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.

[0302] Notice, Figure 13-15 A 1-hop relay case is shown, but the various procedures are generic and can be applied to multi-hop cases. In other words, the relay UE 102 can be an intermediate UE that forwards the message to another intermediate or relay UE 701 that manages the relay chain.

[0303] Regarding forming 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 assigned 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).

[0304] Figure 16 Figures 16A-16B ) illustrates the process of network-assisted relay chain formation triggered by a PC5 link establishment procedure initiated by a remote UE. Assume that the remote UE has not yet registered with the network.

[0305] 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 relay traffic for it. Other information may be included, similar to that in Fig.13 The information contained in step S1301.

[0306] 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, such as Fig.13 As described in step S1305.

[0307] Step S1603: If the relay UE 701 decides to relay traffic for the remote UE 102, the relay UE 701 forwards the remote UE's registration request 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:

[0308] S-NSSAI and relay UE ID assigned to serve relay UE

[0309] Relay capability of relay UE

[0310] Policy reference ID or relay policy ID indicating the relay configuration and policy that the relay UE is to apply to the requested relay chain

[0311] Step S1604: AMF 172 initiates the registration process with other NFs for remote UE 102, and when the registration is completed, more remote UE information will be obtained, such as remote UE ID and subscription information.

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

[0313] 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 contacted directly, the NEF may be involved.

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

[0315] Step S1608: PCF 184 returns the decision and configuration parameters in response to AMF 172, where AMF 172 associates the remote / relay UE with the relay chain ID.

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

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

[0318] It should be realized that Fig.13 -16 Assume that the same AMF serves both remote UEs and relay UEs. If the UEs complete registration individually before joining or forming a new relay chain, the UEs may be served by different AMFs. In this case, the AMF reallocation process can be performed by moving the context of all UEs to one AMF that serves all UEs in the relay chain. This can make relay operations more efficient and reduce unnecessary signaling between AMFs.

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

[0320] In order to make the formation of distributed relay chains possible, the relay UE 701 can obtain authentication and authorization to do so from the core network. This can be done during the registration or registration update process of the relay UE 701. 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 it is not allowed to form any additional relay chains. 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 periodically update the state of the relay chain with the network. 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 a default strategy.

[0321] Multi-hop relay chain maintenance

[0322] When an intermediate UE in the middle of a multi-hop relay chain is turned off or leaves, the other remaining UEs in the relay chain or network need to find / form an alternative relay path for these UEs to reach the network. This is especially critical for UEs with ongoing traffic to and from the network. In other words, service continuity is desired for these UEs. This section provides an exemplary embodiment of a method that addresses how UEs in a relay chain and network can adapt to multi-hop relay chain interruptions and how to find new relay paths for these affected UEs.

[0323] Specifically, different solutions can be applied to different situations as follows:

[0324] · Relay UE 701 is not changed: In this case, only the UE in the middle of the relay chain (e.g., the intermediate UE) is changed, 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 do 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 PCF 184 so that the network function can participate in the decision-making process and inform the relay UE 701 whether it is allowed to do so. Finally, the relay UE 701 needs to inform the AMF 172 and PCF 184 of the new structure of the multi-hop relay chain so that the network knows which UE can be reached through which relay chain.

[0325] • The relay UE 701 is changed: This is more complicated, because the network, base station or remaining UEs need to select a new relay UE 701. Alternatively, the new relay UE 701 may be selected from the remaining UEs in the relay chain, or from a group of external UEs. Fig.17 The diagram illustrates the process of selecting a new relay UE, where two cases are illustrated:

[0326] • Selecting a new relay UE from the remaining UEs that are part of the relay chain.

[0327] Select a new relay UE from an external UE that is 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 activities.

[0328] Fig.17 The diagram illustrates the following steps:

[0329] Step S1701: The old relay UE 701a notifies the AMF 172 and other core network functions that it will no longer be a 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 for it to act as a relay, and application / service information related to the relay traffic.

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

[0331] Step S1703: 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 the remaining time that it can act as a relay UE in step S1701, AMF 172 may also include the time value. In addition, AMF 172 may indicate that a new relay UE 701b is expected. AMF 172 may also include a list of UE IDs in the remaining UEs that can act as relay UE 701.

[0332] 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 AMF 172 to become a new relay UE 701b. In the request, the UE ID and its relay capability are included. The specific information in the relay capability is further described in this article.

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

[0334] Step S1706: AMF 172 returns a response to the UE that sent the request message in step S1704 by indicating whether the request to act as a 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.

[0335] Step S1707: If the network does not receive any new relay UE request from the remaining UEs, and after a pre-configured time period, the network may decide that a new relay UE should be selected from an external UE. Then, the network functions (e.g., AMF, PCF, UDM / UDR, and NWDAF) will coordinate with each other to list a list of UEs that may be candidates for the new relay UE 701b. Then AMF172 sends 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., 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.

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

[0337] Step S1710: The new relay UE 701b sends a confirmation to the AMF 172 to inform all remaining UEs that they have successfully switched to the new relay UE 701b and can be reached via the new relay UE 701b. The AMF 172 and other network functions will create an association between the new relay UE 701b and these UEs.

[0338] Alternatively, the network or RAN node 105 may allow a 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 backup relay UEs without any service interruption.

[0339] Registration and connection management of UEs in multi-hop relay chains

[0340] The following description gives an exemplary embodiment of a method for configuring registration management (RM) and connection management (CM) for UEs in a relay chain, and how these RM / CM procedures are performed. Based on the multi-hop relay strategy, the network may decide to update the RM / CM configuration (such as paging options, power saving cycles, 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:

[0341] One or more UEs join or leave the existing relay chain

[0342] Forming a new relay chain

[0343] UE in the relay chain requests to update certain CM / RM parameters

[0344] The application server or application service provider associated with the relayed traffic requests this

[0345] Fig.18 The diagram illustrates an example embodiment process in which the AMF 172 may set the RM / CM configuration for a UE in a relay chain.

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

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

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

[0349] Step S1804: The relay UE 701 may store these connection management and registration management configuration parameters.

[0350] 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 ID specified in the message transmitted in step S1803.

[0351] Fig.18 The procedures shown in may be performed together with several core network procedures such as UE configuration update, service request and registration update.

[0352] Paging multiple UEs in a relay chain via N2

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

[0354] Two embodiments of the option for the AMF 172 to send an N2 paging message targeted at one or more UEs in the relay chain to the RAN node 105 are described here:

[0355] 1. Group-based N2 messaging: 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 deliver any N2 messages 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-TMS1, 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 the paging message to the UEs over 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 the target destination is. For UL N2 messaging, a single remote UE 102 or intermediate UE 102 is transparent to the N2 messaging because they do not have a direct connection with the RAN node 105. Thus, the proposed group-based N2 messaging is only used for DL. In addition, the AMF 172 can indicate in the N2 paging message the reason why the UE is paged, such as DL data arrival, UE configuration update required, or expected changes to 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, the relay capability of the relay UE, etc. When sending an 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.

[0356] 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 UE in the N2 message sent to the RAN node 105.

[0357] 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 a remote UE ID such as 5G SUPI, S-TMS1, so that it can calculate the paging occasion of the remote UE 102 and monitor the paging message for the remote UE 102. The relay UE 701 can derive this information from the remote UE 102 when the PC5 link is established, or derive this information from the network when the network accepts the remote UE 102 to join the relay chain, or derive this information when the remote UE 102 performs indirect registration via the relay UE 701. Once the relay UE 701 receives the paging message, it will find out which specific UEs are paged and forward the paging message to each UE via the PC5 link.

[0358] Registration update with relay UE via PC5

[0359] An example embodiment is described below in which the remote UE 102 may perform a registration update procedure by sending a request message to the relay UE 701, which will then report the registration update status of one or more UEs to the network at a pre-configured time. Typically, when the registration update timer expires, the UE will initiate the registration update procedure by sending a request message to the AMF 172 over a NAS connection. In the context of multi-hop relay, the remote UE 102 may choose to send the request message to the relay UE 701 over a PC5 link before the timer expires. This helps reduce signaling overhead for situations where there are no changes or any new requests from the remote UE 102.

[0360] The relay UE 701 may report to the AMF 172 when it is performing its own registration update procedure, or at a pre-configured time. For example, the remote UE 102 may specify a time point together with a registration update message that the relay UE 701 reports to the AMF 172 when the remote UE 102 wakes up and is available to receive any control messages or user data. The core network may configure the relay UE 701 so that when the relay UE 701 initiates its own registration update procedure, the relay UE 701 reports any registration updates on behalf of the UEs in the relay chain. This effectively means that the registration update procedure is aggregated by the relay UE 701 and the relay UE 701 reports to the network at the same time.

[0361] Alternatively, the relay UE 701 or the core network may decide that the relay UE 701 may perform registration updates 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.

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

[0363] Remote UE ID

[0364] Registration update timer: If the relay UE will report the remote UE's registration update status to the network, the remote UE will inform the relay UE of its timer so that the relay UE can let the network know the remote UE's registration status in a timely manner.

[0365] Any status update of the remote UE

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

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

[0368] The core network function (e.g., AMF, PCF) can 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, AMF 172 can indicate to the remote UE 102 and the relay UE 701 whether the remote UE 102 is allowed to perform registration updates with the relay UE through PC5, and specify some conditions, such as only when there is no state change and no request from the remote UE 102. In addition, AMF 172 can assign 2 different timers to the remote UE 102, respectively for registration updates with the relay UE 701 and AMF 172. Alternatively, the core network can assign 1 timer regardless of the method determined by the remote UE 102.

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

[0370] user interface

[0371] Fig.19 The diagram illustrates an exemplary user interface according to an example embodiment. The parameters defined for the multi-hop relay configuration may be provided by an end user, a network operator, or an application service provider through a user interface. In addition, the relay UE 701 or the network operator may retrieve and display relay statistics through a user interface 1901. A user interface screen instance 1901 may be presented for configuring or programming these parameters with default values, and for enabling or disabling relay services. A user may select a multi-hop configuration display screen instance input selection 1902. Selection 1902 may generate a new display screen instance 1903, which includes a user type option, which includes a service provider option 1904, a terminal device option 1905, and a network operator option 1906. Each presented option may be presented with corresponding selection inputs 1907, 1908, and 1909. When the corresponding selection input is received, a relay configuration screen instance 1910 may be presented. Screen instance 1910 may include a title 1911 and details 1912 of the configuration.

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

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

[0374] Thus, it should be appreciated by those skilled in the art that the disclosed systems and methods can be embodied in other specific forms without departing from their spirit or essential characteristics. Thus, the embodiments currently disclosed are considered to be illustrative in all respects, rather than restrictive. It is not exhaustive, nor does it limit the disclosure to the precise form disclosed. In view of the above teachings, various modifications and changes are possible, or various modifications and changes can be obtained from the practice of the disclosure without departing from the breadth or scope of the disclosure. Thus, although specific configurations are discussed herein, other configurations may also be adopted. The disclosure enables numerous modifications and other embodiments (e.g., combinations, rearrangements, etc.), and the numerous modifications and other embodiments are within the scope of ordinary technicians 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 can be combined, rearranged, omitted, etc. within the scope of the present invention to produce additional embodiments. In addition, some features are sometimes advantageous when used without corresponding use of other features. Thus, the applicant intends to include all such substitutions, modifications, equivalents, and changes within the spirit and scope of the disclosed subject matter.

[0375] Unless explicitly stated, reference to a singular element does not mean "one and only one," but rather "one or more." Furthermore, where a phrase similar to "at least one of A, B, or C" is used in the claims, it is intended that the phrase 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; for example, A and B, A and C, B and C, or A and B and C.

[0376] Unless a claim element herein is expressly referenced using the phrase "means for...", the claim element should not be interpreted in accordance with the provisions of 35 U.S.C. 112(f). The terms "comprises," "comprising," or any other variation thereof as used herein are intended to cover non-exclusive inclusions, such that a process, method, article, or apparatus comprising a series of elements does not include only these elements, but may include other elements that are not explicitly listed or that are 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 scope encompassing its meaning and scope and equivalents is intended to be included therein.

[0377] In the present specification, the term "UE" may be interchangeable with the broader term "electronic device," and vice versa, so that various applications and functions that can be implemented by the present disclosure may be covered.

[0378] 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 a 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.

[0379] 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.

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

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

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

[0383] In an exemplary embodiment, a method for registering a user equipment (UE) to enable a multi-hop relay service 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 the multi-hop relay service; providing an indication to the network of a role that the UE requests to perform in the multi-hop relay service, 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 under the condition that the role of the UE is to be a remote UE; and sending a second set of predetermined information about intermediate UE characteristics from the UE under the condition that the role of the UE is to be an intermediate UE.

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

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

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

[0387] In an exemplary embodiment, a method for maintaining a multi-hop relay chain in a wireless communication network includes 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 a network via the at least another intermediate UE.

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

[0389] 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 to join 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 a new or existing multi-hop relay chain.

[0390] In an exemplary embodiment, the method, wherein the core network asset hosts an Access and Mobility Management Function (AMF).

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

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

[0393] 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.

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

[0395] 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 a 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.

[0396] In an exemplary embodiment, a user equipment (UE) (e.g., a relay UE) assists a remote UE that is farther away than the UE in terms of signal coverage of a wireless communication network to access a relay service (e.g., Fig.13 , Fig.14 , Fig.15 Figure 16( Figures 16A-16B )). The relay UE may receive (for example, Figure 1E : 125a, 125b, 128) a PC5 link establishment request message (e.g., Fig.13 , Fig.14 , Fig.15 Figure 16( Figures 16A-16B )). Receiving may occur via a sidelink interface. The relay UE may determine whether there is a relay chain association with respect to the remote UE, including (e.g., Fig.13 , Fig.14 , Fig.15 Figure 16( Figures 16A-16B )) by determining whether to accept the remote UE to join the relay chain (for example, Fig.13 , Fig.14 , Fig.15 ) or determine whether the remote UE for the request assumes the role of a relay UE (eg, FIG. 16 ( Figures 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.

[0397] In an exemplary embodiment, the relay UE may send a join relay chain request message to the wireless communication network, wherein the join relay chain request message includes a registration request message (e.g., Fig.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, the role being 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 join relay chain response from the wireless communication network via a non-access stratum (NAS) connection.

[0398] In an exemplary embodiment, when the relay UE determines whether there is a relay chain association with respect to the remote UE, the relay UE may (for example, Fig.13 , Fig.14 , Fig.15 Figure 16( Figures 16A-16B )) determines through its control circuit whether to accept the remote UE to join the relay chain (for example, Fig.13 , Fig.14 , Fig.15 In this case, the PC5 link establishment request message may include an encapsulated join relay chain request indicating a request to join a relay chain, wherein the relay chain is an existing relay chain that exists before receiving the PC5 link establishment request message, and the existing relay chain is discovered by the remote UE (for example, Fig.10 or Fig.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., Fig.13 , Fig.14 ).

[0399] 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) ( Fig.13 , Fig.14 ).

[0400] 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, relay load status of the existing relay chain, configuration of the relay strategy, power consumption, having operating characteristics consistent with the remote UE, security requirements (e.g., 184-189, Fig.13 , Fig.14 ).

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

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

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

[0404] In an exemplary embodiment, determining whether there is a relay chain association for the remote UE includes indirectly sending information indicated in a 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., Fig.13 , Fig.14 , Fig.15 Figure 16( Figures 16A-16B )).

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

[0406] In an exemplary embodiment, determining whether there is a relay chain association with respect to the remote UE includes (e.g., Fig.13 , Fig.14 , Fig.15 Figure 16( Figures 16A-16B )) Network-assisted relay chain formation process (e.g., Figure 16 ( Figures 16A-16B )) or the distributed relay chain formation process (e.g. Fig.13 , Fig.14 , Fig.15 ).

[0407] 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 away than the UE in terms of signal coverage of the wireless communication network to access a relay service that enables access to other services provided by the wireless communication network (e.g., Fig.13 , Fig.14 , Fig.15 Figure 16( Figures 16A-16B )). The method further includes receiving a registration request message having information derived from a PC5 link establishment request message sent by the remote UE, the registration request message including information for requesting to establish a new relay chain (e.g., FIG. 16 ( Figures 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 to the wireless communication network. The method also includes processing a registration process of the remote UE based on the remote UE registration information, and processing a 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 roles of the UE and the remote UE, and obtaining service application information of the new relay chain. The method also 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 strategy obtained via a non-access stratum (NAS) connection (for example, FIG. 16 ( Figures 16A-16B )).

[0408] In an exemplary embodiment, the remote UE registration information may include the relay UE ID and relay UE capabilities and the requested relay policy ID (eg, FIG. 16 ( Figures 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 the UE in the relay chain, or mobility patterns of the UE in the relay chain (e.g., FIG. 16 ( Figures 16A-16B )).

[0409] In an exemplary embodiment, the network node may send a notification message (e.g., Fig.17 ).

[0410] In an exemplary embodiment, a remote UE that is farther away than a potential relay UE in terms of signal coverage of a wireless communication network may perform a method to access a relay service (e.g., Fig.13 , Fig.14 , Fig.15 Figure 16( Figures 16A-16B )), the method includes discovering one or more potential relay UEs (e.g., Fig.10 , Fig.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 a join relay chain response from the target relay UE originating from a wireless communication network via a non-access stratum (NAS) connection.

[0411] 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 a join relay chain response message includes any one or more of: a relay chain ID, a relay policy ID, and a remote role indication regarding the remote UE.

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

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

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

Claims

1. A method, comprising: receiving a PC5 link establishment request message from a remote electronic device; Determining whether a relay chain association exists for the remote electronic device includes: Determine whether to accept the remote electronic device to join the relay chain, or determining whether the remote electronic device assumes the role of a relay electronic device; Based on the determination of the relay chain association, sending a PC5 link establishment response message to the remote electronic device; Sending a join relay chain request message to the wireless communication network, wherein the join relay chain request message includes a registration request message requesting the wireless communication network to enable a multi-hop relay service; providing, to the wireless communication network, an indication of a role that the electronic device requests to perform in a multi-hop relay service, the role being a remote electronic device role or a relay electronic device role; determining whether to accept the remote electronic device to join the relay chain; Establishing a PC-5 link with a remote electronic device; and A join relay chain response is received from the wireless communication network via a non-access stratum (NAS) connection.

2. The method of claim 1, wherein determining whether a relay chain association exists for the remote electronic device comprises: determining whether to accept the remote electronic device to join the relay chain; as well as 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 receiving the PC5 Link Establishment Request message, and the existing relay chain being discovered by the remote electronic device, The relay chain ID indicating this existing relay chain, and An encapsulated network registration request indicating a layer 2 ID of the remote electronic device.

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

4. The method of claim 1, wherein the determining whether to accept the remote electronic device to join the relay chain comprises considering any one or more of the following: Relay capability, The relay load status of the existing relay chain, Configuration of relay policies, Power consumption, Have operating characteristics consistent with the remote electronic device, Security requirements.

5. The method according to claim 1, further comprising: A paging procedure is set up for electronic devices that are part of an existing relay chain, including sending a paging message to one or more electronic devices that are unreachable in the multi-hop relay chain, including performing the message transmission over an N2 interface.

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

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

8. The method of claim 1, wherein determining whether a relay chain association exists for the remote electronic device comprises: The information indicated in the PC5 link establishment request message is indirectly sent to the network node circuit of the wireless communication network via another electronic device, and the relay service is a multi-hop relay service.

9. The method according to claim 1, further comprising: Send a notification message indicating updated relay chain state information.

10. The method of claim 1, wherein the determining whether a relay chain association exists for the remote electronic device comprises: Network-assisted relay chain formation process or distributed relay chain formation process.

11. A method performed by a remote electronic device to gain access to a relay service provided by a wireless communication network, the remote electronic device being further away than a potential relay electronic device with respect to the signal coverage of the wireless communication network, the method comprising: discovering one or more potential relay electronic devices capable of providing access to a relay chain service; selecting one of the one or more potential relay electronic devices as a target relay electronic device; Sending a request message to join the relay chain to the target relay electronic device; receiving a join relay chain response having information originating from the wireless communication network from a target relay electronic device via a non-access stratum (NAS) connection; as well as establishing a connection to a relay chain via a target relay electronic device connected to a node in the wireless communication network; The join relay chain response message includes any one or more of the following: Relay chain ID, Relay policy ID, Remote role indication for remote electronic devices.

12. The method according to claim 11, 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.

13. The method of claim 11, wherein adding a relay chain response message comprises: Relay policy originating from (PCF) nodes on non-access stratum NAS connections.

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

Citation Information

Patent Citations

  • Optimizations for relay communications

    CN107211297A

  • Relay for wireless communication system

    WO2018129543A1