Multi-relay usage management

CN122556136APending Publication Date: 2026-08-11KONINKLIJKE PHILIPS NV
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-01-08
Publication Date
2026-08-11

Smart Images

  • Figure CN122556136A_ABST
    Figure CN122556136A_ABST
Patent Text Reader

Abstract

The present invention relates to a method comprising: a first wireless relay device sending a first message to an Access and Mobility Management Function (AMF), the first message indicating the multi-hop relay capability of the first wireless relay device; the first wireless relay device receiving a second message from the AMF, the second message being: multi-hop relay for an authorized service; and indicating a Relay Service Code (RSC) for the service; the first wireless relay device receiving a sidelink advertisement message from a second wireless relay device, the sidelink advertisement message including: an indication indicating support for multi-hop relay; and the RSC; and the first wireless relay device sending a sidelink connection request message to the second wireless relay device based on the second message requesting multi-hop relay for the RSC.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to wireless communication, such as cellular communication networks. In particular, this invention relates to protocols for establishing or initiating communications with relay architectures. Summary of the Invention

[0002] This invention aims to improve relay management in communication networks.

[0003] According to the present invention, methods and apparatus as claimed in the appended set of claims are proposed.

[0004] In particular, in a first aspect of the invention, a method is provided comprising: The first wireless relay device receives the second message from the network functional unit: Multi-hop relay for authorized services; and Indicates the relay service code (RSC) for the service; and The first wireless relay device sends a sidelink connection request message to the second wireless relay device based on the second message. The sidelink connection request message requests a multi-hop relay for the RSC.

[0005] In a variation of the first aspect, the method further includes: the first wireless relay device sending a first request message indicating multi-hop relay capability to the network functional unit.

[0006] In another variation of the first aspect, the method further includes: the first wireless relay device receiving a sidelink advertisement message from the second wireless relay device, the sidelink advertisement message including an indication of support for multi-hop relay and at least one of the RSCs.

[0007] In another variation of the first aspect, the multi-hop relay is to relay user data from a remote wireless device to the network using more than one wireless relay device.

[0008] In another variation of the first aspect, the second message further indicates a second RSC, wherein the second RSC is used for the service when a direct connection to the cell is available.

[0009] In another variation of the first aspect, the direct connection to the cell is a connection from the first wireless relay device to the cell, without using another wireless relay device between the cell and the first wireless relay device.

[0010] In another variation of the first aspect, the method includes: the first wireless relay device sending a second sidelink advertisement message indicating multi-hop relay to the remote wireless device. In one example, the second sidelink advertisement message further indicates that the direct connection to the cell is unavailable. Optionally, the second sidelink advertisement message further indicates the number of hops to the cell. Optionally, the method may further include: the first wireless relay device receiving a second sidelink connection message from the remote wireless device, wherein the second sidelink connection message indicates whether the remote wireless device supports multi-hop relay.

[0011] In another variation of the first aspect, the method further includes: the first wireless relay device sending a sidelink connection rejection message to the remote wireless device based on the remote wireless device not indicating support for multi-hop relay.

[0012] In another variation of the first aspect, the second message further includes one or more conditions when the first wireless relay device is authorized to perform multi-hop relay.

[0013] In another variation of the first aspect, the method further includes: the first wireless relay device sending a sidelink release request based on a direct connection to the cell. The method may also include: the first wireless relay device sending an indication to the remote wireless device regarding the non-use of multi-hop relays. Additionally, the method may include: the first wireless relay device sending a configuration message to the remote wireless device indicating modifications to PC5 QoS parameters.

[0014] In another variation of the first aspect, the second message further indicates at least one of the following: whether multi-hop relay of the service via a plurality of radio layer 2 relay devices is permitted, or whether multi-hop relay of the service via a plurality of radio layer 3 relay devices is permitted.

[0015] In another variation of the first aspect, the one or more conditions indicate at least one of the following: one or more networks, one or more frequency bands, or one or more geographical regions.

[0016] In another variation of the first aspect, the first request message further includes at least one of the following: a first indication indicating whether multi-hop relaying via the plurality of radio layer 2 relay devices is supported; a second indication indicating whether multi-hop relaying via the plurality of radio layer 3 relay devices is supported; the maximum number of relay hops supported; whether the topmost relay operation is supported; or whether downstream relay operation is supported.

[0017] In another variation of the first aspect, the direct connection to the cell is available if the first wireless relay device is able to camp on the cell or if the cell indicates support for multi-hop relay.

[0018] According to a second aspect of the present invention, a method is provided comprising: The wireless device receives one or more policy configurations, including a first policy configuration and a second policy configuration, wherein... The first policy configuration associated with multi-hop relay indicates a first parameter, wherein, in multi-hop relay, the intermediate relay is connected to the network relay; The second policy configuration instruction second parameter is not associated with multi-hop relay; and The one or more policy configurations are associated with the first relay service; The establishment of a sidelink connection for the first relay service is triggered by the wireless device; and The wireless device sends a connection request message, which includes: In response to selecting the first relay device of the multi-hop relay, the first parameter; and In response to selecting not to indicate the second relay device of the multi-hop relay, the second parameter.

[0019] According to a second aspect of the present invention, a method is provided comprising: The network relay receives a radio resource control (RRC) message from the base station indicating one or more parameters for configuring relay operation; The network relay receives sidelink messages associated with multi-hop relays from the wireless device, wherein, in multi-hop relays, intermediate relays are connected to the network relay; and The network relay sends a second RRC message to the base station indicating the type of the wireless device, wherein the type of the wireless device indicates the relay type.

[0020] According to a third aspect of the present invention, a method is provided comprising: The first relay receives one or more policy configurations including a first policy configuration for multi-hop relay, wherein, in multi-hop relay, intermediate relays are connected to network relays; The first relay device sends a first message to the wireless device to establish a first side link connection; The first relay receives a second message from the second relay, the second message establishing a second side link connection for multi-hop relay; and Based on receiving the second side link message, the first relay device sends a third message to the wireless device indicating the modification of the first side link.

[0021] In a variation of the second aspect of the invention, the modification indicates the multi-hop relay.

[0022] According to a third aspect of the present invention, a method is provided comprising: The wireless device receives a policy configuration indicating one or more parameters for multi-hop relay, wherein, in multi-hop relay, an intermediate relay is connected to a network relay. The wireless device receives one or more announcement messages from one or more relays, wherein: The first relay of the one or more relays sends a first announcement message of the one or more announcement messages, the first announcement message indicating a multi-hop relay for the service; and The second relay of the one or more relays sends a second notification message of the one or more notification messages, the second notification message not indicating a multi-hop relay for the service; and The wireless device sends a sidelink connection request for the multi-hop relay to the first relay based on the policy configuration and the first announcement message.

[0023] According to a fourth aspect of the present invention, a method is provided comprising: A first message is sent by a wireless device, the first message including one or more parameters for indicating the multi-hop capability of the wireless device, wherein the one or more parameters include at least one of the following: A first capability, the first capability indicating whether the wireless device supports one or more first functions of a remote wireless device with multi-hop relay; The second capability indicates whether the wireless device supports one or more second functions of an intermediate relay device in multi-hop relay; and The third capability indicates whether the wireless device supports one or more third functions of a multi-hop relay network relay device; and The wireless device receives a second message, the second message authorizing at least one of the following: First authorization for the remote wireless device with multi-hop relay; A second authorization for the intermediate relay device for multi-hop relays; and Third authorization for the network relay device with multi-hop relay.

[0024] According to a fifth aspect of the present invention, a method is provided comprising: The first base station receives a context management message from the network functional unit, the context management message including: Identifiers for wireless devices; and Authorization information, which authorizes the wireless device as a wireless relay device for multi-hop relay services; and The first base station sends a handover request message, including the identifier and the authorization information, to the second base station.

[0025] In a variation of the fifth aspect, the context management message further includes one or more capability parameters indicating that the wireless device supports the multi-hop relay service. Optionally, the one or more capability parameters include at least one of the following: First license for remote wireless devices with multi-hop relays; Secondary authorization for intermediate relay equipment in multi-hop relays; and Third-party licenses for network relay devices with multi-hop relays.

[0026] In another variation of the fifth aspect, the authorization information includes at least one of the following: First authorization for the remote wireless device with multi-hop relay; A second authorization for the intermediate relay device for multi-hop relays; and Third authorization for the network relay device with multi-hop relay.

[0027] In another variation of the fifth aspect, the first base station determines whether to send one or more radio parameters configuring the multi-hop relay to the wireless device based on the authorization information indicated by the context management message or based on the capability indication.

[0028] According to a sixth aspect of the present invention, a method is provided comprising: A radio resource control (RRC) message is received from a radio device via a first relay by a first base station, the RRC message requesting the establishment of an RRC connection, wherein the RRC message indicates at least one of the following: Information indicating the wireless device's ability to support multi-hop relay; Indicates the request information of the wireless device; The first base station receives a context management message from the network functional unit. The context management message includes authorization information, which authorizes the wireless device to act as a wireless relay device for the multi-hop relay. The first base station sends one or more radio parameters configuring the multi-hop relay to the wireless device via the first relay based on the context management message.

[0029] According to a seventh aspect of the present invention, a method is provided comprising: The network node receives a path switching request message from the base station, including the identifier of the wireless device; and The network functional unit sends a response to the path handover request message to the base station, wherein the response includes: Identifiers for wireless devices; and The authorization information authorizes the wireless device to act as a wireless relay device for multi-hop relay services.

[0030] According to an eighth aspect of the present invention, a method is provided comprising: The first node managing mobility receives a first message from the wireless device, the first message including: The identifier associated with the wireless device; and Information indicating the wireless device's ability to support multi-hop relay; and The first node sends a second message to the second node with management capabilities, the second message including: The identifier; and The capability information.

[0031] According to a ninth aspect of the present invention, a method is provided comprising: The first base station receives a handover request for a wireless device from the second base station, wherein the handover request message includes: The identifier associated with the wireless device; and Information indicating the wireless device's ability to support multi-hop relay; and The first base station sends a path handover request message to the access and mobility management node; and The first base station receives a path handover request confirmation message from the access and mobility management node, the path handover request confirmation message including: Authorization information indicating whether the UE is allowed to perform multi-hop relay.

[0032] According to a tenth aspect of the present invention, a method is provided comprising: The wireless device sends one or more registration messages indicating one or more capability parameters, the one or more capability parameters indicating that the wireless device supports one or more roles for multi-hop relay; A wireless device receives one or more configuration messages including one or more policy configuration parameters, wherein the one or more policy configuration parameters include at least one of the following: One or more relay service codes for the service; and One or more conditions are used when the wireless device is allowed to perform the multi-hop relay for the service, wherein the one or more conditions include one or more identifiers indicating one or more networks.

[0033] According to the eleventh aspect of the present invention, a method is provided, comprising: The first wireless relay device sends a first message to the Access and Mobility Management Function Unit (AMF), the first message indicating the multi-hop relay capability of the first wireless relay device; The first wireless relay device receives a second message from the AMF, the second message being: Multi-hop relay for authorized services; and Indicates the Relay Service Code (RSC) for the service. The first wireless relay device receives a side link notification message from the second wireless relay device, the side link notification message including: Indicators supporting multi-hop relays; and The RSC; and The first wireless relay device sends a request message to the second wireless relay device based on the second message, requesting a side link connection for the multi-hop relay of the RSC.

[0034] According to a twelfth aspect of the present invention, an apparatus for use as a first wireless relay device is provided, comprising: The receiver is configured to receive a second message from the network functional unit: The controller is configured to determine whether to authorize a multi-hop relay for service. The controller is adapted to indicate the relay service code (RSC) for the service; and A transmitter configured to send a sidelink connection request message for the multi-hop relay of the RSC to a second wireless relay device based on the second message. Attached Figure Description

[0035] This document describes examples of several embodiments of various embodiments of the present disclosure with reference to the accompanying drawings.

[0036] Figure 1A and Figure 1B An example communication network including an access network and a core network is shown.

[0037] Figure 2A , Figure 2B , Figure 2C and Figure 2D Various examples of frameworks for service-based architectures within the core network are shown.

[0038] Figure 3An example communication network including core network functional units is shown.

[0039] Figure 4A and Figure 4B An example of a core network architecture with multiple user plane functional units and untrusted access is shown.

[0040] Figure 5 An example of the core network architecture used in roaming scenarios is shown.

[0041] Figure 6 An example of a network slice is shown.

[0042] Figure 7A , Figure 7B and Figure 7C The diagram illustrates the user plane protocol stack, the control plane protocol stack, and the services provided between the protocol layers of the user plane protocol stack.

[0043] Figure 8 An example of a quality of service model for data exchange is shown.

[0044] Figure 9A , Figure 9B , Figure 9C and Figure 9D Example states and state transitions of a wireless device are shown.

[0045] Figure 10 An example of the registration process for wireless devices is shown.

[0046] Figure 11 An example of a service request process for a wireless device is shown.

[0047] Figure 12 An example of the Protocol Data Unit (PDU) session establishment process for a wireless device is shown.

[0048] Figure 13 An example of a component in a communication network is shown.

[0049] Figure 14A , Figure 14B , Figure 14C and Figure 14D Various examples of physical core network deployments are shown, each physical core network deployment having one or more network functional units or portions thereof.

[0050] Figure 15 This is a diagram of one aspect of an exemplary embodiment of the present disclosure.

[0051] Figure 16 This is a diagram of one aspect of an exemplary embodiment of the present disclosure.

[0052] Figure 17This is a diagram of one aspect of an exemplary embodiment of the present disclosure.

[0053] Figure 18 This is a diagram of one aspect of an exemplary embodiment of the present disclosure.

[0054] Figure 19 This is a diagram of one aspect of an exemplary embodiment of the present disclosure.

[0055] Figure 20 This is a diagram of one aspect of an exemplary embodiment of the present disclosure.

[0056] Figure 21 This is a diagram of one aspect of an exemplary embodiment of the present disclosure.

[0057] Figure 22 This is a diagram of one aspect of an exemplary embodiment of the present disclosure.

[0058] Figure 23 This is a diagram of one aspect of an exemplary embodiment of the present disclosure.

[0059] Figure 24 This is a diagram of one aspect of an exemplary embodiment of the present disclosure.

[0060] Figure 25 This is a diagram of one aspect of an exemplary embodiment of the present disclosure.

[0061] Figure 26 This is a diagram of one aspect of an exemplary embodiment of the present disclosure.

[0062] Figure 27 This is a diagram of one aspect of an exemplary embodiment of the present disclosure.

[0063] Figure 28 This is a diagram of one aspect of an exemplary embodiment of the present disclosure. Detailed Implementation

[0064] In this disclosure, various embodiments are presented as examples of how the disclosed techniques and / or how the disclosed techniques can be practiced in environments and scenarios. It will be apparent to those skilled in the art that various changes in form and detail can be made without departing from the scope. Indeed, after reading the description, it will be apparent to those skilled in the art how to implement alternative embodiments. This embodiment should not be limited to any of the exemplary embodiments described. Embodiments of this disclosure will be described with reference to the accompanying drawings. Limitations, features, and / or elements from the disclosed example embodiments may be combined to create further embodiments within the scope of this disclosure. Any drawings emphasizing features and advantages are presented for illustrative purposes only. The disclosed architecture is flexible and configurable enough that it can be utilized in ways other than those shown. For example, actions listed in any flowchart may be reordered or used only optionally in some embodiments.

[0065] The embodiments can be configured to operate as needed. The disclosed mechanisms can be executed when certain criteria are met, for example, in wireless devices, base stations, radio environments, networks, combinations thereof, etc. Example criteria may be based at least in part on, for example, wireless device or network node configuration, traffic load, initial system setup, packet size, service characteristics, combinations thereof, etc. Various example embodiments can be applied when one or more criteria are met. Therefore, example embodiments that selectively implement the disclosed protocols can be implemented.

[0066] Base stations can communicate in combination with wireless devices. Wireless devices and / or base stations can support multiple technologies and / or multiple versions of the same technology. Wireless devices can have one or more specific capabilities. When this disclosure relates to a base station communicating with multiple wireless devices, this disclosure can refer to a subset of the total number of wireless devices in a coverage area. This disclosure can refer to, for example, multiple wireless devices having a given capability and a given LTE or 5G version in a given sector of a base station. Multiple wireless devices in this disclosure can refer to selected multiple wireless devices and / or a subset of the total number of wireless devices in a coverage area, etc., performing according to the disclosed method. Multiple base stations or multiple wireless devices may exist in the coverage area that may not conform to the disclosed method; for example, those wireless devices or base stations may be based on older versions of LTE or 5G technology.

[0067] In this disclosure, “a” and “an”, and similar phrases, refer to a single instance of a particular element but should not be construed as excluding other instances of that element. For example, a bicycle with two wheels can be described as having “wheels”. Any term ending with the suffix “(s)” should be construed as “at least one” and / or “one or more”. In this disclosure, the term “may” should be construed as “may, for example”. In other words, the term “may” indicates that the phrase following the term “may” is an example of one of a variety of suitable possibilities that may or may not be employed by one or more embodiments in various embodiments. As used herein, the terms “comprising” and “consisting of” enumerate one or more components of the described element. The term “comprising” is interchangeable with “including” and does not exclude the inclusion of unlisted components in the described element. In contrast, “consisting of” provides a complete enumeration of one or more components of the described element.

[0068] The phrases “based on,” “in response to,” “depending on,” “adopted,” “used,” and similar phrases indicate the presence and / or influence of a particular factor and / or condition on an event and / or action, but do not exclude the presence and / or influence of unlisted factors and / or conditions on the event and / or action. For example, if action X is performed “based on” condition Y, this would be interpreted as the action being performed “at least based on” condition Y. For example, if the execution of action X is performed when conditions Y and Z are satisfied, the execution of action X can be described as “based on Y.”

[0069] The term "configured to" can refer to the capabilities of a device, whether the device is in an operational or non-operational state. "Configured" can refer to specific settings within the device that affect its operational characteristics, regardless of whether the device is in an operational or non-operational state. In other words, hardware, software, firmware, registers, memory values, etc., can be "configured" within the device, whether the device is in an operational or non-operational state, to provide specific characteristics to the device. Terms such as "control messages generated in the device" can mean that control messages have parameters that can be used to configure specific characteristics, or can be used to implement certain actions within the device, regardless of whether the device is in an operational or non-operational state.

[0070] In this disclosure, parameters may include one or more information objects, and information objects may include one or more other objects. For example, if parameter J includes parameter K, and parameter K includes parameter L, and parameter L includes parameter M, then J includes L, and J includes M. Parameters may be referred to as fields or information elements. In the example embodiments, when one or more messages include multiple parameters, this means that a parameter among the multiple parameters is in at least one of the one or more messages, but not necessarily in every one of the one or more messages.

[0071] This disclosure may refer to the possible combinations of the listed elements. For brevity and readability, this disclosure does not explicitly describe every permutation that can be obtained by selecting from a set of optional features. This disclosure should be interpreted as explicitly disclosing all such permutations. For example, the seven possible combinations of the listed elements A, B, and C include: (1) “A”; (2) “B”; (3) “C”; (4) “A and B”; (5) “A and C”; (6) “B and C”; and (7) “A, B, and C”. For brevity and readability, these seven possible combinations can be described using any of the following interchangeable formulas: “at least one of A, B, and C”; “at least one of A, B, or C”; “one or more of A, B, and C”; “one or more of A, B, or C”; “A, B, and / or C”. It should be understood that impossible combinations are excluded. For example, “X and / or not X” should be interpreted as “X or not X”. It will also be understood that these formulas can describe alternative terms for overlapping and / or synonymous concepts, such as “identifier, identifier, and / or ID number”.

[0072] This disclosure may refer to sets and / or subsets. As an example, a set X may be a set of elements that includes one or more elements. If every element of X is also an element of Y, then X may be called a subset of Y. In this disclosure, only non-empty sets and subsets are considered. For example, if Y consists of elements Y1, Y2, and Y3, then possible subsets of Y are {Y1, Y2, Y3}, {Y1, Y2}, {Y1, Y3}, {Y2, Y3}, {Y1}, {Y2}, and {Y3}.

[0073] Figure 1A An example of a communication network 100 in which embodiments of the present disclosure may be implemented is shown. The communication network 100 may include, for example, a Public Land Mobile Network (PLMN) operated by a network operator. Figure 1A As shown, the communication network 100 includes a wireless device 101, an access network (AN) 102, a core network (CN) 105, and one or more data networks (DN) 108.

[0074] Wireless device 101 can communicate with DN 108 via AN 102 and CN 105. In this disclosure, the term "wireless device" can refer to and encompass any mobile or fixed (non-mobile) device that requires or can use wireless communication. For example, a wireless device can be a telephone, smartphone, tablet, computer, laptop, sensor, instrument, wearable device, Internet of Things (IoT) device, vehicle roadside unit (RSU), relay node, automobile, unmanned aerial vehicle, urban air traffic, and / or any combination thereof. The term "wireless apparatus" encompasses other terms including user equipment (UE), user terminal (UT), access terminal (AT), mobile station, handheld device, wireless transmitting and receiving unit (WTRU), and / or wireless communication equipment.

[0075] AN 102 can connect radio device 101 to CN 105 in any suitable manner. The communication direction from AN 102 to radio device 101 is referred to as the downlink, and the communication direction from radio device 101 to AN 102 is referred to as the uplink. Downlink and uplink transmissions can be separated using frequency division duplex (FDD), time division duplex (TDD), and / or some combination of both duplexing technologies. AN 102 can connect to radio device 101 via radio communication over the air interface. An access network that operates at least partially over the air interface can be referred to as a radio access network (RAN). CN 105 can establish one or more end-to-end connections between radio device 101 and one or more DNs 108. CN 105 can authenticate radio device 101 and provide accounting functions.

[0076] In this disclosure, the term "base station" can refer to and encompass any element of AN 102 that facilitates communication between wireless device 101 and AN 102. Access networks and base stations have many different names and implementations. A base station can be a terrestrial base station fixed to the earth. A base station can be a mobile base station with mobile coverage areas. A base station can be in space, such as on a satellite. For example, WiFi and other standards can use the term "access point." As another example, the 3rd Generation Partnership Project (3GPP) has produced specifications for three generations of mobile networks, each using different terminology. Third-generation (3G) and / or Universal Mobile Telecommunications System (UMTS) standards can use the term "node B." 4G, Long Term Evolution (LTE), and / or Evolved Universal Terrestrial Radio Access (E-UTRA) standards can use the term "evolved node B" (eNB). 5G and / or New Radio (NR) standards can describe AN 102 as a Next Generation Radio Access Network (NG-RAN) and can refer to the base station as a Next Generation eNB (ng-eNB) and / or Next Generation Node B (gNB). Future standards (e.g., 6G, 7G, 8G) may use new terms to refer to elements (e.g., wireless devices, base stations, AN, CN, and / or components thereof) that implement the methods described in this disclosure. A base station may be implemented as a relay or relay node for extending the coverage area of ​​a donor node. A relay node may amplify and rebroadcast radio signals received from the donor node. A relay node may perform the same / similar functions as a relay node, but may decode the radio signals received from the donor node to remove noise before amplifying and rebroadcasting the radio signals.

[0077] AN 102 may include one or more base stations, each having one or more coverage areas. The geographical size and / or extent of the coverage area can be defined based on the range within which a receiver of AN 102 can successfully receive transmissions from a transmitter (e.g., wireless device 101) operating within the coverage area (and / or vice versa). A coverage area may be referred to as a sector or cell (but in some contexts, the term cell refers to the carrier frequency used in a particular coverage area, rather than the coverage area itself). A base station with a large coverage area may be referred to as a macrocell base station. Other base stations cover smaller areas, for example, to provide coverage in areas with weak macrocell coverage, or to provide additional coverage (sometimes referred to as a hotspot) in areas with high traffic. Examples of small cell base stations, in descending order of coverage area, include microcell base stations, picocell base stations, and femtocell base stations or femtocell base stations. In summary, the coverage area of ​​a base station can provide radio coverage to wireless device 101 over a wide geographical area to support wireless device mobility.

[0078] A base station may include one or more antenna sets for communicating with wireless device 101 via an air interface. Each antenna set may be individually controlled by the base station. Each antenna set may have a corresponding coverage area. As an example, a base station may include three antenna sets to control three coverage areas on three different sides of the base station, respectively. The entire base station (and its corresponding antennas) may be deployed at a single location. Alternatively, a controller at a central location may control one or more antenna sets at one or more distributed locations. The controller may be, for example, a baseband processing unit as part of a centralized or cloud RAN architecture. The baseband processing unit may be centralized in a pool of baseband processing units or virtualized. The antenna sets at distributed locations may be referred to as Remote Radio Headers (RRHs).

[0079] Figure 1B Another example communication network 150 in which embodiments of the present disclosure can be implemented is shown. Communication network 150 may include, for example, a PLMN operated by a network operator. Figure 1B As shown, the communication network 150 includes a UE 151, a Next-Generation Radio Access Network (NG-RAN) 152, a 5G Core Network (5G-CN) 155, and one or more DNs 158. The NG RAN 152 includes one or more base stations, shown as a Next-Generation Node B (gNB) 152A and a Next-Generation Evolved Node B (ng eNB) 152B. The 5G-CN 155 includes one or more Network Functional Elements (NFs), including a control plane functional element 155A and a user plane functional element 155B. The one or more DNs 158 may include public DNs (e.g., the Internet), private DNs, and / or carrier-internal DNs. (Relative to...) Figure 1A The corresponding components shown can represent specific implementations and / or terms.

[0080] The base station of NG-RAN 152 can connect to UE 151 via the Uu interface. The base stations of NG-RAN 152 can connect to each other via the Xn interface. The base station of NG-RAN 152 can connect to 5G CN 155 via the NG interface. The Uu interface may include an air interface. The NG and Xn interfaces may include air interfaces, or may consist of a direct physical connection and / or an indirect connection via an underlying transport network (e.g., an Internet Protocol (IP) transport network).

[0081] Each of the Uu, Xn, and NG interfaces can be associated with a protocol stack. The protocol stack can include a user plane (UP) and a control plane (CP). Typically, user plane data can include data related to the user of UE 151, such as internet content downloaded via a web browser application, sensor data uploaded via a tracking application, or email data sent to or from an email server. In contrast, control plane data can include signaling and messages that facilitate the packaging and routing of user plane data so that it can be exchanged with the DN. The NG interface can, for example, be divided into an NG user plane interface (NG-U) and an NG control plane interface (NG-C). The NG-U interface can provide delivery of user plane data between the base station and one or more user plane network function elements 155B. The NG-C interface can be used for control signaling between the base station and one or more control plane network function elements 155A. The NG-C interface can provide, for example, NG interface management, UE context management, UE mobility management, NAS message transmission, paging, PDU session management, and configuration transmission and / or warning message transmission. In some cases, the NG-C interface can support the transmission of user data (e.g., for small data transmissions of IoT devices).

[0082] One or more base stations in an NG-RAN 152 base station can be split into a Central Unit (CU) and one or more Distributed Units (DUs). The CU can be coupled to one or more DUs via an F1 interface. The CU can handle one or more upper layers of the protocol stack, and the DU can handle one or more lower layers of the protocol stack. For example, the CU can handle RRC, PDCP, and SDAP, while the DU can handle RLC, MAC, and PHY. One or more DUs can be geographically different relative to the CU and / or to each other. Therefore, the CU / DU split architecture can allow for increased coverage and / or better coordination.

[0083] gNB 152A and ng-eNB 152B can provide different user plane and control plane protocol terminations to UE 151. For example, gNB 154A can provide New Radio (NR) protocol termination through the Uu interface associated with the first protocol stack. ng-eNB 152B can provide Evolved UMTS Terrestrial Radio Access (E-UTRA) protocol termination through the Uu interface associated with the second protocol stack.

[0084] 5G-CN 155 can authenticate UE 151, establish end-to-end connections between UE 151 and one or more DNs 158, and provide billing functions. 5G-CN 155 can be based on a service-based architecture, where the NFs comprising 5G-CN 155 provide services to each other and other elements of the communication network 150 via interfaces. 5G-CN 155 can include any number of other NFs and any number of instances of each NF.

[0085] Figure 2A , Figure 2B , Figure 2C and Figure 2D Various examples of frameworks for a service-based architecture within the core network are shown. In a service-based architecture, services can be sought by service consumers and provided by service producers. Before obtaining a specific service, an NF can determine where such a service can be obtained. To discover services, an NF can communicate with a Network Repository Functional Unit (NRF). As an example, an NF providing one or more services can register with the NRF. The NRF can store data related to one or more services that an NF is prepared to provide to other NFs in the service-based architecture. Consumer NFs can query the NRF to discover producer NFs (e.g., by obtaining a list of NF instances providing a specific service from the NRF).

[0086] exist Figure 2A In the example, NF 211 (in this example, the consumer NF) can send request 221 to NF 212 (the producer NF). Request 221 can be a request for a specific service and can be sent based on the fact that NF 212 is the producer of that service. Request 221 can include data related to NF 211 and / or the requested service. NF 212 can receive request 221, perform one or more actions associated with the requested service (e.g., retrieve data), and provide response 221. The one or more actions performed by NF 212 can be based on the requested data included in request 221, data stored by NF 212, and / or data retrieved by NF 212. Response 222 can notify NF 211 that one or more actions have been completed. Response 222 can include response data related to NF 212, one or more actions, and / or the requested service.

[0087] exist Figure 2B In the example, NF 231 sends request 241 to NF 232. In this example, part of the service provided by NF 232 is sending request 242 to NF 233. NF 233 can perform one or more actions and provide a response 243 to NF 232. Based on response 243, NF 232 can send response 244 to NF 231. Figure 2B It will be understood that a single NF can perform the roles of service producer, service consumer, or both. A particular NF service can include any number of nested NF services generated by one or more other NFs.

[0088] Figure 2C An example of a subscription-notification interaction between a consumer NF and a producer NF is shown. Figure 2C In the above, NF 251 sends subscription 261 to NF 252. NF 253 sends subscription 262 to NF 252. For illustrative purposes, in Figure 2C Two NFs are shown (to demonstrate that NF 252 can provide multiple subscription services to different NFs), but it should be understood that subscription notification interaction requires only one subscriber. NFs 251 and 253 can be independent of each other. For example, NFs 251 and 253 can independently discover NF 252 and / or independently determine the subscription to the service provided by NF 252. In response to the receipt of a subscription, NF 252 can provide a notification to the subscribing NF. For example, NF 252 can send notification 263 to NF 251 based on subscription 261, and can send notification 264 to NF 253 based on subscription 262.

[0089] like Figure 2C As illustrated in the example diagram, the sending of notifications 263 and 264 can be based on the determination that a condition has occurred. For example, notifications 263 and 264 can be based on the determination that a specific event has occurred, the determination that a specific condition has not been met, and / or the determination that the duration associated with the subscription has elapsed (e.g., the period of time associated with a subscription to a periodic notification). Figure 2C As illustrated in the example diagram, NF 252 can send notifications 263 and 264 to NFs 251 and 253 simultaneously and / or in response to the same conditions. However, it should be understood that NF 252 can provide notifications at different times and / or in response to different notification conditions. In one example, NF 251 can request notification when a parameter measured by NF 252 exceeds a first threshold, and NF 252 can request notification when the parameter exceeds a second threshold different from the first threshold. In one example, the parameter of interest and / or the corresponding threshold can be indicated in subscriptions 261 and 262.

[0090] Figure 2D This shows another example of a subscription notification interaction. Figure 2D In this context, NF 271 sends subscription 281 to NF 272. In response to receiving subscription 281 and / or determining that a notification condition has occurred, NF 272 can send notification 284. Notification 284 can then be sent to NF 273. Figure 2C The example in [the example] (where notifications are sent to the subscribed NF) is different. Figure 2DThis illustrates how subscriptions and their corresponding notifications can be associated with different NFs. For example, NF 271 can subscribe to a service provided by NF 272 on behalf of NF 273.

[0091] Figure 3 Another example communication network 300 in which embodiments of the present disclosure may be implemented is shown. The communication network 300 includes a user equipment (UE) 301, an access network (AN) 302, and a data network (DN) 308. Figure 3 The remaining elements depicted may be included in and / or associated with the core network. Each element of the core network may be referred to as a network functional unit (NF).

[0092] Figure 3 The NFs described include User Plane Functional Element (UPF) 305, Access and Mobility Management Functional Element (AMF) 312, Session Management Functional Element (SMF) 314, Policy Control Functional Element (PCF) 320, Network Repository Functional Element (NRF) 330, Network Exposure Functional Element (NEF) 340, Unified Data Management (UDM) 350, Authentication Server Functional Element (AUSF) 360, Network Slice Selection Functional Element (NSSF) 370, Charging Functional Element (CHF) 380, Network Data Analysis Functional Element (NWDAF) 390, and Application Functional Element (AF) 399. UPF 305 can be a user plane core network functional element, while NFs 312, 314, and 320-390 can be control plane core network functional elements. Although... Figure 3 The example is not shown, but the core network may include any NF depicted and / or additional instances of one or more different NF types providing different services. Other examples of NF types include Gateway Mobility Location Center (GMLC), Location Management Function Unit (LMF), Operations, Administration and Maintenance Function Unit (OAM), Public Alarm System (PWS), Short Message Service Function Unit (SMSF), Unified Data Repository (UDR), and Unstructured Data Storage Function Unit (UDSF).

[0093] Figure 3 Each element depicted has an interface with at least one other element. The interface can be a logical connection, rather than, for example, a direct physical connection. Any interface can be identified using reference point representation and / or service-based representation. In the reference point representation, the letter "N" followed by a number indicates the interface between two specific elements. For example, as... Figure 3As shown, AN302 and UPF 305 are connected via “N3”, while UPF 305 and DN 308 are connected via the “N6” interface. In contrast, in service-based representation, the letter “N” is followed by a letter. The letter identifies the NF providing services to the core network. For example, PCF 320 can provide services via interface “Npcf”. PCF 320 can provide services to any NF in the core network via “Npcf”. Therefore, service-based representation can correspond to a set of reference point representations. For example, the Npcf interface between PCF 320 and the core network can typically correspond to the N7 interface between PCF 320 and SMF 314, the N30 interface between PCF 320 and NEF 340, and so on.

[0094] UPF 305 can be used as a gateway for user plane services between AN 302 and DN 308. UE 301 can connect to UPF 305 via the Uu interface and the N3 interface (also described as the NG-U interface). UPF 305 can connect to DN 308 via the N6 interface. UPF 305 can connect to one or more other UPFs (not shown) via the N9 interface. UE 301 can be configured to receive services via Protocol Data Unit (PDU) sessions, which serve as a logical connection between UE 301 and DN 308. SMF 314 can select UPF 305 (or multiple UPFs, if needed) to handle specific PDU sessions between UE 301 and DN 308. SMF 314 can control the functionality of UPF 305 regarding PDU sessions. SMF 314 can connect to UPF 305 via the N4 interface. UPF 305 can handle any number of PDU sessions associated with any number of UEs (via any number of ANs). To handle one or more PDU sessions, the UPF 305 can be controlled by any number of SMFs via any number of corresponding N4 interfaces.

[0095] Figure 3 The AMF 312, as depicted, controls the UE's access to the core network. UE 301 can register with the network via the AMF 312. UE 301 may need to register before establishing a PDU session. The AMF 312 manages the UE 301's registration area, enabling the network to track the UE 301's physical location within the network. For UEs in connected mode, the AMF 312 can manage UE mobility, such as handover from one AN or a portion thereof to another AN or a portion thereof. For UEs in idle mode, the AMF 312 can perform registration updates and / or page the UE to transition it to connected mode.

[0096] AMF 312 can receive NAS messages sent by UE 301 according to the Non-Access Stratum (NAS) protocol. NAS messages relate to communication between UE 301 and the core network. Although NAS messages can be relayed to AMF 312 via AN 302, they can be described as communication via the N1 interface. NAS messages can facilitate UE registration and mobility management, for example, by authenticating, identifying, configuring, and / or managing UE 301's connectivity. NAS messages can support session management procedures for maintaining user plane connectivity and Quality of Service (QoS) of the session between UE 301 and DN 309. If the NAS message involves session management, AMF 312 can send the NAS message to SMF 314. NAS messages can be used to transmit messages between UE 301 and other components of the core network (e.g., core network components other than AMF 312 and SMF 314). AMF 312 can act on a specific NAS message itself, or alternatively, forward the NAS message to the appropriate core network functional unit (e.g., SMF 314, etc.).

[0097] Figure 3 The SMF 314, as depicted, can establish, modify, and / or release PDU sessions based on messages received from UE 301. For example, when establishing a PDU session, the SMF 314 can allocate, manage, and / or assign IP addresses to UE 301. Multiple SMFs can exist in the network, each associated with a corresponding set of radio devices, base stations, and / or UPFs. A UE with multiple PDU sessions can be associated with a different SMF for each PDU session. As described above, the SMF 314 can select one or more UPFs to handle PDU sessions and can control the processing of PDU sessions by the selected UPF by providing rules (PDR, FAR, QER, etc.) for packet processing. Rules related to the QoS and / or charging of a specific PDU session can be obtained from PCF 320 and provided to UPF 305.

[0098] The PCF 320 can provide policy-related services to other NFs. The PCF 320 can use subscription data and information about network conditions to determine policy rules, and then provide these rules to the specific NFs that can be responsible for enforcing them. Policy rules can relate to policy control for access and mobility and can be enforced by the AMF. Policy rules can relate to session management and can be enforced by the SMF 314. Policy rules can be, for example, network-specific, radio device-specific, session-specific, or data flow-specific.

[0099] The NRF 330 can provide service discovery. The NRF 330 can belong to a specific PLMN. The NRF 330 can maintain NF profiles related to other NFs in the communication network 300. NF profiles may include, for example, the NF's address, PLMN and / or type, slice identifier, a list of one or more services provided by the NF, and the authorization required to access the service.

[0100] Figure 3 The NEF 340, as depicted, can provide an interface to an external domain, allowing the external domain to selectively access the control plane of the communication network 300. The external domain may include, for example, third-party network function units, application function units, etc. The NEF 340 can act as a proxy between external components and network function units (such as AMF 312, SMF 314, PCF 320, UDM 350, etc.). As an example, the NEF 340 can determine the location or reachability status of UE 301 based on reports from AMF 312 and provide status information to the external component. As an example, the external component can provide information via the NEF 340 that helps set parameters for establishing a PDU session. The NEF 340 can determine which control plane data and capabilities are exposed to the external domain. The NEF 340 can provide secure exposure that authenticates and / or authorizes the external entities to which the data or capabilities of the communication network 300 are exposed. The NEF 340 can selectively control exposure, making the internal architecture of the core network hidden from the external domain.

[0101] The UDM 350 can provide data storage for other NFs. The UDM 350 allows for a consolidated view of network information available from a single resource across different NFs, ensuring that the most relevant information is accessible from a single resource. The UDM 350 can store and / or retrieve information from a Unified Data Repository (UDR). For example, the UDM 350 can obtain user subscription data related to UE 301 from the UDR.

[0102] AUSF 360 supports mutual authentication between the core network and UE 301, as well as authentication between UE 301 and the core network. AUSF 360 can perform key negotiation processes and provide key materials that can be used to improve security.

[0103] The NSSF 370 can select one or more network slices to be used by the UE 301. The NSSF 370 can select slices based on slice selection information. For example, the NSSF 370 can receive Single Network Slice Selection Assistance Information (S-NSSAI) and map the S-NSSAI to a Network Slice Instance Identifier (NSI).

[0104] CHF 380 can control charging-related tasks associated with UE 301. For example, UPF 305 can report service usage associated with UE 301 to SMF 314. SMF 314 can collect usage data from UPF 305 and one or more other UPFs. Usage data can indicate how much data is exchanged, with which DN is data exchanged, the network slice associated with the data, or any other information that may affect charging. SMF 314 can share the collected usage data with CHF. CHF can use the collected usage data to perform charging-related tasks associated with UE 301. Depending on the charging status of UE 301, CHF can instruct SMF 314 to restrict or affect UE 301's access and / or provide charging-related notifications to UE 301.

[0105] The NWDAF 390 can collect and analyze data from other network functional units and provide data analysis services to them. As an example, the NWDAF 390 can collect data related to the load level of a specific network slice instance from the UPF 305, AMF 312, and / or SMF 314. Based on the collected data, the NWDAF 390 can provide load level data to the PCF 320 and / or NSSF 370, and / or notify the PCF 320 and / or NSSF 370 if the slice's load level reaches and / or exceeds a load level threshold.

[0106] AF 399 can operate outside the core network, but can interact with it to provide information related to QoS requirements or service routing preferences associated with specific applications. AF 399 can access the core network based on exposure constraints imposed by NEF 340. However, the core network operator may consider AF 399 a trusted domain with direct network access.

[0107] Figure 4A , Figure 4B and Figure 5 It shows similarities in some aspects Figure 3 Other examples of the core network architecture of the 300 are described in the diagram. For simplicity, details are omitted. Figure 3 Some of the core network components are described in the text. Figure 4A , Figure 4B and Figure 5 Many of the elements depicted are similar in some respects to Figure 3 The elements depicted are shown in the image. For the sake of brevity, some details related to their function or operation have been omitted.

[0108] Figure 4AAn example of a core network architecture 400A, including an arrangement of multiple UPFs, is shown. Core network architecture 400A includes UE 401, AN 402, AMF 412, and SMF 414. Unlike the previous example of the core network architecture described above, Figure 4A Multiple UPFs (including UPF 405, UPF 406, and UPF 407) and multiple DNs (including DN 408 and DN 409) are described. Each of the multiple UPFs 405, 406, and 407 can communicate with the SMF 414 via the N4 interface. DNs 408 and 409 communicate with UPFs 405 and 406 respectively via the N6 interface. Figure 4A As shown, multiple UPF 405, 406, and 407 can communicate with each other via the N9 interface.

[0109] UPF 405, 406, and 407 can perform service detection, where the UPF identifies and / or classifies packets. Packet identification can be performed based on Packet Detection Rules (PDRs) provided by SMF 414. A PDR can include packet detection information, which includes one or more of the following: source interface, UE IP address, core network (CN) tunnel information (e.g., the CN address of an N3 / N9 tunnel corresponding to a PDU session), network instance identifier, Quality of Service Flow Identifier (QFI), filter set (e.g., an IP packet filter set or an Ethernet packet filter set), and / or application identifier.

[0110] In addition to indicating how to detect a specific packet, a PDR can also indicate the rules used to process the packet when it is detected. Rules can include, for example, Forwarding Action (FAR) rules, Multiple Access (MAR) rules, Usage Reporting (URR) rules, QoS Enforcement (QER) rules, etc. For instance, a PDR can include one or more FAR identifiers, MAR identifiers, URR identifiers, and / or QER identifiers. These identifiers can indicate the rules specified for processing a particular detected packet.

[0111] UPF 405 can perform service forwarding based on FARs. For example, a FAR can instruct packets associated with a specific PDR to be forwarded, copied, dropped, and / or buffered. A FAR can instruct the destination interface, such as "access" for downlink or "core" for uplink. If packets are to be buffered, the FAR can instruct a Buffer Action Rule (BAR). As an example, if a PDU session is deactivated, UPF 405 can perform data buffering on a specific number of downlink packets.

[0112] UPF 405 can perform QoS enforcement based on QERs. For example, a QER can indicate the authorized guaranteed bit rate and / or the maximum bit rate to be enforced for packets associated with a particular PDR. A QER can indicate specific guaranteed and / or maximum bit rates that can be used for uplink and / or downlink packets. UPF 405 can use corresponding QFIs to mark packets belonging to a specific QoS flow. Marking allows the packet receiver to determine the QoS of the packet.

[0113] UPF 405 can provide usage reports to SMF 414 based on URRs. URRs can indicate one or more triggering conditions for generating and reporting usage reports, such as immediate reporting, periodic reporting, thresholds for incoming uplink traffic, or any other suitable triggering conditions. URRs can also indicate methods for measuring the use of network resources, such as data volume, duration, and / or events.

[0114] As described above, DNs 408 and 409 may include public DNs (e.g., the Internet), private DNs (e.g., privately owned, internally owned DNs), and / or carrier-owned DNs. Each DN can provide carrier services and / or third-party services. The services provided by the DN may be the Internet, IP Multimedia Subsystem (IMS), augmented or virtual reality networks, edge computing or mobile edge computing (MEC) networks, etc. Each DN may be identified using a Data Network Name (DNN). UE 401 may be configured to establish a first logical connection with DN 408 (first PDU session), a second logical connection with DN 409 (second PDU session), or both simultaneously (first PDU session and second PDU session).

[0115] Each PDU session can be associated with at least one UPF that is configured to operate as a PDU session anchor (PSA or "anchor"). The anchor can be a UPF that provides an N6 interface to the DN.

[0116] exist Figure 4AIn the example, UPF 405 can be the anchor for the first PDU session between UE 401 and DN 408, while UPF 406 can be the anchor for the second PDU session between UE 401 and DN 409. When UE 401 moves from one access network to another, the core network can use the anchor to provide service continuity (e.g., IP address continuity) for a specific PDU session. For example, suppose UE 401 uses a data path to DN 408 from an access network other than AN 402 to establish a PDU session. The data path may include UPF 405 acting as the anchor. Further suppose UE 401 later moves to the coverage area of ​​AN 402. In this scenario, SMF 414 can select a new UPF (UPF 407) to bridge the gap between the newly entered access network (AN 402) and the anchor UPF (UPF 405). PDU session continuity can be preserved when any number of UPFs are added or removed from the data path. When a UPF is added to the data path, such as Figure 4A As shown, it can be described as an intermediate UPF and / or a cascaded UPF.

[0117] As described above, UPF 406 can be the anchor for a second PDU session between UE 401 and DN 409. Although the anchor for the first and second PDU sessions is... Figure 4A Different UPFs are associated with each other, but it should be understood that this is merely an example. It will also be understood that multiple PDU sessions with a single DN can correspond to any number of anchors. When multiple UPFs exist, the UPF at the branch point ( Figure 4A The UPF 407 in the example can operate as an uplink classifier (UL-CL). UL-CL can transfer uplink user plane services to different UPFs.

[0118] For example, when establishing a PDU session, the SMF 414 can allocate, manage, and / or assign IP addresses to the UE 401. The SMF 414 can maintain an internal pool of IP addresses to be assigned. If needed, the SMF 414 can assign IP addresses provided by a Dynamic Host Configuration Protocol (DHCP) server or an Authentication, Authorization, and Accounting (AAA) server. IP address management can be performed according to Session and Service Continuity (SSC) modes. In SSC mode 1, the UE 401's IP address can be maintained (and the same anchor UPF can be used) as the wireless device moves within the network. In SSC mode 2, the UE 401's IP address changes as the UE 401 moves within the network (e.g., the old IP address and UPF can be discarded, and a new IP address and anchor UPF can be established). In SSC mode 3, the old IP address can be temporarily maintained (similar to SSC mode 1) when a new IP address is established (similar to SSC mode 2), thus combining the features of SSC mode 1 and SSC mode 2. Applications sensitive to IP address changes can operate according to SSC mode 1.

[0119] UPF selection can be controlled by SMF 414. For example, when establishing and / or modifying a PDU session between UE 401 and DN 408, SMF 414 can select UPF 405 as the anchor for the PDU session and / or select UPF 407 as an intermediate UPF. Criteria for UPF selection include path efficiency and / or speed between AN 402 and DN 408. The reliability, load status, location, slice support, and / or other capabilities of candidate UPFs may also be considered.

[0120] Figure 4B An example of a 400B core network architecture adapted for untrusted access is shown. Similar to... Figure 4A ,like Figure 4B The UE 401 depicted is connected to DN 408 via AN 402 and UPF 405. AN 402 and UPF 405 constitute trusted (e.g., 3GPP) access to DN 408. Alternatively, UE 401 can also access DN 408 using untrusted access network AN 403 and Non-3GPP Interoperability Working Functional Unit (N3IWF) 404.

[0121] AN 403 can be, for example, a Wireless Land Area Network (WLAN) operating according to the IEEE 802.11 standard. UE 401 can connect to AN 403 via interface Y1 in any manner specified for AN 403. The connection to AN 403 may or may not involve authentication. UE 401 can obtain an IP address from AN 403. UE 401 can determine to connect to core network 400B and select an untrusted access for that purpose. AN 403 can communicate with N3IWF 404 via interface Y2. After selecting untrusted access, UE 401 can provide N3IWF 404 with sufficient information to select an AMF. The selected AMF can be, for example, the same AMF used by UE 401 for 3GPP access (AMF 412 in this example). N3IWF 404 can communicate with AMF 412 via interface N2. UPF 405 can be selected, and N3IWF 404 can communicate with UPF 405 via the N3 interface. UPF 405 can be a PDU session anchor (PSA), and UPF 405 can maintain the anchor for the PDU session even when UE 401 moves between trusted and untrusted access.

[0122] Figure 5 An example of core network architecture 500 in a roaming scenario is shown. In the roaming scenario, UE 501 is a subscriber to a first PLMN (Home PLMN or HPLMN) but attached to a second PLMN (Visitor PLMN or VPLMN). Core network architecture 500 includes UE 501, AN 502, UPF 505, and DN 508. AN 502 and UPF 505 can be associated with a VPLMN. The VPLMN can manage AN 502 and UPF 505 using core network elements associated with the VPLMN, including AMF 512, SMF 514, PCF 520, NRF 530, NEF 540, and NSSF 570. AF 599 can be adjacent to the VPLMN's core network.

[0123] UE 501 may not be a VPLMN subscriber. AMF 512 may authorize UE 501 to access the network based on, for example, roaming restrictions applied to UE 501. To obtain network services provided by the VPLMN, the VPLMN's core network may need to interact with the core network elements of UE 501's HPLMN (specifically, PCF 521, NRF 531, NEF 541, UDM 551, and / or AUSF 561). The VPLMN and HPLMN can communicate using the N32 interface connecting the respective Secure Edge Protection Agent (SEPP). Figure 5In this context, the corresponding SEPPs are described as VSEPP 590 and HSEPP 591.

[0124] For definitional purposes, VSEPP 590 and HSEPP 591 communicate via the N32 interface, while hiding information about each PLMN from each other. SEPP can apply roaming policies based on communication via the N32 interface. PCF 520 and PCF521 can communicate via SEPP to exchange policy-related signaling. NRF 530 and NRF 531 can communicate via SEPP to perform service discovery for NFs in their respective PLMNs. VPLMN and HPLMN can independently maintain NEF 540 and NEF541. NSSF 570 and NSSF 571 can communicate via SEPP to coordinate slice selection for UE 501. HPLMN can handle all authentication and subscription-related signaling. For example, when UE 501 registers or requests service via VPLMN, VPLMN can authenticate UE 501 and / or obtain UE 501's subscription data by accessing HPLMN via SEPP's UDM 551 and AUSF 561.

[0125] Figure 5 The core network architecture 500 described in the document can be referred to as a local offloading configuration, where UE 501 uses one or more UPFs (i.e., UPF 505) of the VPLMN to access DN 508. However, other configurations are also possible. For example, in the home routing configuration ( Figure 5 (Not shown in the diagram) In this configuration, UE 501 can use one or more UPFs of the HPLMN to access the DN. In the home routing configuration, the N9 interface can operate parallel to the N32 interface, spanning the boundary between the VPLMN and HPLMN to carry user plane data. One or more SMFs of the corresponding PLMN can communicate via the N32 interface to coordinate session management for UE 501. The SMFs can control their respective UPFs on either side of the boundary.

[0126] Figure 6 An example of network slicing is shown. Network slicing can refer to dividing shared infrastructure (e.g., physical infrastructure) into different logical networks. These different logical networks can be controlled independently, isolated from each other, and / or associated with dedicated resources.

[0127] Network architecture 600A illustrates an unsliced ​​physical network corresponding to a single logical network. Network architecture 600A includes a user plane, where UE 601A, UE 601B, and UE 601C (collectively referred to as UE 601) have physical and logical connections to DN608 via AN 602 and UPF 605. Network architecture 600A also includes a control plane, where AMF 612 and SMF 614 control various aspects of the user plane.

[0128] Network architecture 600A may have a specific set of characteristics (e.g., related to maximum bit rate, reliability, latency, bandwidth usage, power consumption, etc.). This set of characteristics may be influenced by the nature of the network elements themselves (e.g., processing power, availability of free memory, proximity to other network elements, etc.) or by their management (e.g., being optimized to maximize bit rate or reliability, reduce latency or power bandwidth usage, etc.). The characteristics of network architecture 600A may change over time, for example, by upgrading equipment or by modifying processes to target specific characteristics. However, at any given time, network architecture 600A will have a single set of characteristics that may or may not be optimized for a particular use case. For example, UE 601A, UE 601B, and UE 601C may have different requirements, but network architecture 600A can only be optimized for one of the three UEs.

[0129] Network Architecture 600B is an example of a sliced ​​physical network divided into multiple logical networks. Figure 6 In this architecture, the physical network is divided into three logical networks, called slice A, slice B, and slice C. For example, UE 601A can be served by AN 602A, UPF605A, AMF 612, and SMF 614A. UE 601B can be served by AN 602B, UPF 605B, AMF 612, and SMF 614B. UE 601C can be served by AN 602C, UPF 605C, AMF 612, and SMF 614C. Although the corresponding UE 601 communicates with different network elements from a logical perspective, these network elements can be deployed by the network operator using the same physical network elements.

[0130] Each network slice can be customized to provide a network service with a different set of characteristics. For example, slice A could correspond to enhanced mobile broadband (eMBB) service. Mobile broadband can refer to internet access by mobile users, typically associated with smartphones. Slice B could correspond to ultra-reliable low-latency communication (URLLC), which focuses on reliability and speed. Compared to eMBB, URLLC can improve the feasibility of use cases such as autonomous driving and remote surgery. Slice C could correspond to massive machine-type communication (mMTC), which focuses on low-power service delivery to a large number of users. For example, slice C could be optimized for dense networks of battery-powered sensors that provide small amounts of data at regular intervals. Many mMTC use cases would be too expensive to operate with eMBB or URLLC networks.

[0131] If the service requirements for one of UEs 601 change, the network slice serving that UE can be updated to provide better service. Furthermore, the set of network characteristics corresponding to eMBB, URLLC, and mMTC can be changed to provide different types of eMBB, URLLC, and mMTC. Alternatively, network operators can provide entirely new services in response to, for example, customer demand.

[0132] exist Figure 6 In this example, each UE 601 has its own network slice. However, it should be understood that a single slice can serve any number of UEs, and a single UE can operate using any number of slices. Furthermore, in the example network architecture 600B, AN 602, UPF 605, and SMF 614 are divided into three separate slices, while AMF 612 is unsliced. However, it should be understood that network operators can deploy any architecture that selectively utilizes any mixture of sliced ​​and unsliced ​​network elements, where different network elements are divided into different numbers of slices. Although... Figure 6 Only three core network functional units are described, but it should be understood that other core network functional units can also be sliced. A PLMN that supports multiple network slices can maintain a separate Network Repository Functional Unit (NFR) for each slice, enabling other NFs to discover network services associated with that slice.

[0133] Network slice selection can be controlled by the AMF (Agency Management Function) or, alternatively, by a separate Network Slice Selection Functional Unit (NSSF). For example, network operators can define and implement different Network Slice Instances (NSIs). Each NSI can be associated with a Single Network Slice Selection Auxiliary Information (S-NSSAI). An S-NSSAI can include a specific slice / service type (SST) indicator (indicating eMBB, URLLC, mMTC, etc.). As an example, a specific tracking area can be associated with one or more configured S-NSSAIs. The UE can identify one or more requested and / or subscribed S-NSSAIs (e.g., during registration). The network can indicate one or more allowed and / or denied S-NSSAIs to the UE.

[0134] S-NSSAI may also include a slice distinguisher (SD) to differentiate between different tenants for a specific slice and / or service type. For example, a tenant could be a network operator's guaranteed network resources (e.g., purchased) and / or a customer (e.g., a vehicle manufacturer, service provider, etc.) for specific policies used to process its subscribers. Network operators can configure different slices and / or slice types and use the SD to determine which tenant is associated with a specific slice.

[0135] Figure 7A , Figure 7B and Figure 7C The user plane (UP) protocol stack, the control plane (CP) protocol stack, and the services provided between the protocol layers of the UP protocol stack are shown.

[0136] These layers can be associated with the Open Systems Interconnection (OSI) model for computer networking capabilities. In the OSI model, Layer 1 can correspond to the bottom layer, with higher layers above it. Layer 1 can correspond to the physical layer, which involves the physical infrastructure (e.g., cables, optical fibers, and / or radio frequency transceivers) used for signal transmission. In New Radio (NR), Layer 1 can include the Physical Layer (PHY). Layer 2 can correspond to the Data Link Layer. Layer 2 can involve packaging data (e.g., packing it into data frames) for transmission between nodes in the network using the physical infrastructure of Layer 1. In NR, Layer 2 can include the Media Access Control (MAC) layer, Radio Link Control (RLC) layer, Packet Data Convergence Layer (PDCP) layer, and Service Data Application Protocol Layer (SDAP).

[0137] Layer 3 can correspond to the network layer. Layer 3 can involve routing data already encapsulated in Layer 2. Layer 3 can handle data prioritization and traffic avoidance. In NR, Layer 3 can include the Radio Resource Control (RRC) layer and the Non-Access Layer (NAS) layer. Layers 4 through 7 can correspond to the transport, session, presentation, and application layers. The application layer interacts with the end user to provide application-related data. In one example, the end user implementing the application can generate application-related data and initiate the transmission of that information to a target data network (e.g., the Internet, an application server, etc.). Starting from the application layer, each layer in the OSI model can manipulate and / or repackage information and deliver it to lower layers. At the lowest layer, manipulated and / or repackaged information can be exchanged via physical infrastructure (e.g., electrical, optical, and / or electromagnetic). As it approaches the target data network, the information is unpacked and provided to increasingly higher layers until it reaches the application layer again in a form usable by the target data network (e.g., the same form the end user provides the information in). In response to the end user, the data network can reverse this process.

[0138] Figure 7A The user plane protocol stack is shown. The user plane protocol stack can be a New Radio (NR) protocol stack for the Uu interface between UE 701 and gNB 702. In layer 1 of the UP protocol stack, UE 701 can implement PHY 731, and gNB 702 can implement PHY 732. In layer 2 of the UP protocol stack, UE 701 can implement MAC 741, RLC 751, PDCP 761, and SDAP 771. gNB 702 can implement MAC 742, RLC 752, PDCP 762, and SDAP 772.

[0139] Figure 7B The control plane protocol stack is shown. The control plane protocol stack can be an NR protocol stack for the Uu interface between UE 701 and gNB 702 and / or the N1 interface between UE 701 and AMF 712. In layer 1 of the CP protocol stack, UE 701 can implement PHY 731, and gNB 702 can implement PHY 732. In layer 2 of the CP protocol stack, UE 701 can implement MAC 741, RLC 751, PDCP 761, RRC 781, and NAS 791. gNB 702 can implement MAC 742, RLC 752, PDCP 762, and RRC 782. AMF 712 can implement NAS 792.

[0140] NAS can involve the non-access stratum, specifically communication between UE 701 and the core network (e.g., AMF 712). Lower layers can involve the access stratum, such as communication between UE 701 and gNB 702. Messages sent between UE 701 and the core network can be referred to as NAS messages. In one example, a NAS message may be relayed by gNB 702, but the content of the NAS message (e.g., the information elements of the NAS message) may not be visible to gNB 702.

[0141] Figure 7C It shows in Figure 7A This illustrates an example of services provided between protocol layers of the NR user plane protocol stack. UE 701 can receive services through a PDU session, which can be a logical connection between UE 701 and a data network (DN). UE 701 and the DN can exchange data packets associated with the PDU session. The PDU session can include one or more Quality of Service (QoS) flows. SDAP 771 and SDAP 772 can perform mapping and / or demapping between one or more QoS flows of the PDU session and one or more radio bearers (e.g., data radio bearers). The mapping between QoS flows and data radio bearers can be determined by gNB 702 in SDAP 772 and can be notified to UE 701 (e.g., based on control signaling and / or reflection mapping). For reflection mapping, SDAP 772 of gNB 220 can tag downlink packets with QoS Flow Indicators (QFIs) and deliver the downlink packets to UE 701. UE 701 can determine the mapping based on the QFI of the downlink packets.

[0142] PDCP 761 and PDCP 762 can perform header compression and / or decompression. Header compression can reduce the amount of data transmitted at the physical layer. PDCP 761 and PDCP 762 can perform encryption and / or decryption. Encryption can reduce unauthorized decoding of data transmitted at the physical layer (e.g., intercepted at the air interface) and protect data integrity (e.g., ensuring control messages originate from their intended source). PDCP 761 and PDCP 762 can perform retransmission of undelivered packets, in-order delivery and reordering of packets, packet duplication, and / or identification and removal of duplicate packets. In dual-connectivity scenarios, PDCP 761 and PDCP 762 can perform mapping between split radio bearers and RLC channels.

[0143] RLC 751 and RLC 752 can perform segmented retransmissions via Automatic Repeat Request (ARQ). RLC 751 and RLC 752 can remove duplicate data units received from MAC 741 and MAC 742, respectively. RLC 213 and 223 can provide RLC channels as services to PDCP 214 and 224, respectively.

[0144] MAC 741 and MAC 742 can perform multiplexing and / or demultiplexing of logical channels. MAC 741 and MAC 742 can map logical channels to transport channels. In one example, UE 701 can multiplex data elements of one or more logical channels into a transport block in MAC 741. UE 701 can use PHY 731 to send the transport block to gNB 702. gNB 702 can use PHY 732 to receive the transport block and demultiplex the data elements of the transport block back to the logical channel. MAC 741 and MAC 742 can perform error correction, logical channel prioritization, and / or padding via Hybrid Automatic Repeat Request (HARQ).

[0145] PHY 731 and PHY 732 can perform transmission channel to physical channel mapping. PHY 731 and PHY 732 can perform digital and analog signal processing functions (e.g., encoding / decoding and modulation / demodulation) for transmitting and receiving information (e.g., transmission via an air interface). PHY 731 and PHY 732 can perform multi-antenna mapping.

[0146] Figure 8 An example of a Quality of Service (QoS) model for differentiated data exchange is shown. Figure 8 In the QoS models, there are UE 801, AN 802, and UPF 805. QoS models promote the prioritization of certain packets or Protocol Data Units (PDUs) (also known as packets). For example, higher priority packets can be exchanged faster and / or more reliably compared to lower priority packets. The network can allocate more resources to exchanging high QoS packets.

[0147] exist Figure 8In the example, a PDU session 810 is established between UE 801 and UPF 805. PDU session 810 may be a logical connection enabling UE 801 to exchange data with a specific data network (e.g., the Internet). UE 801 may request the establishment of PDU session 810. When establishing PDU session 810, UE 801 may identify the target data network, for example, based on the target data network name (DNN). PDU session 810 may be managed, for example, by a Session Management Function (SMF, not shown). To facilitate the exchange of data associated with PDU session 810 between UE 801 and the data network, the SMF may select UPF 805 (and optionally, one or more other UPFs, not shown).

[0148] One or more applications associated with UE 801 can generate uplink packets 812A-812E associated with PDU session 810. To operate within the QoS model, UE 801 can apply QoS rule 814 to uplink packets 812A-812E. QoS rule 814 can be associated with PDU session 810 and can be determined and / or provided to UE 801 when PDU session 810 is established and / or modified. Based on QoS rule 814, UE 801 can classify uplink packets 812A-812E, mapping each of them to a QoS flow, and / or tagging uplink packets 812A-812E with a QoS flow indicator (QFI). When packets travel through the network and may be mixed with other packets from other UEs with potentially different priorities, the QFI indicates how the packets should be processed according to the QoS model. In this diagram, uplink packets 812A and 812B are mapped to QoS flow 816A, uplink packet 812C is mapped to QoS flow 816B, and the remaining packets are mapped to QoS flow 816C.

[0149] QoS flows can be the finest granular level of QoS differentiation within a PDU session. The figure shows three QoS flows 816A-816C. However, it should be understood that any number of QoS flows can exist. Some QoS flows may be associated with a guaranteed bit rate (GBR QoS flow), while others may have a non-guaranteed bit rate (non-GBR QoS flow). QoS flows can also be subject to per-UE and per-session aggregated bit rates. One of the QoS flows can be the default QoS flow. QoS flows can have different priorities. For example, QoS flow 816A may have a higher priority than QoS flow 816B, and QoS flow 816B may have a higher priority than QoS flow 816C. Different QoS flow characteristics can reflect different priorities. For example, QoS flows can be associated with a flow bit rate. A specific QoS flow can be associated with a guaranteed flow bit rate (GFBR) and / or a maximum flow bit rate (MFBR). A QoS flow can be associated with a specific packet delay budget (PDB), packet error rate (PER), and / or maximum packet loss rate. QoS flows can also be subject to per-UE and per-session aggregated bit rates.

[0150] To function within the QoS model, UE 801 can apply resource mapping rule 818 to QoS flows 816A-816C. The air interface between UE 801 and AN 802 can be associated with resource 820. In this illustration, QoS flow 816A is mapped to resource 820A, while QoS flows 816B and 816C are mapped to resource 820B. Resource mapping rule 818 can be provided by AN 802. To meet QoS requirements, resource mapping rule 818 can specify more resources for relatively high-priority QoS flows. With more resources, high-priority QoS flows (such as QoS flow 816A) may be more likely to obtain high traffic bit rates, low packet delay budgets, or other characteristics associated with QoS rule 814. Resource 820 may include, for example, radio bearers. Radio bearers (e.g., data radio bearers) can be established between UE 801 and AN 802. The radio bearer between UE 801 and AN 802 in 5G can be different from the bearer in LTE. For example, the evolved packet system (EPS) bearer between UE and packet data network gateway (PGW), the S1 bearer between eNB and serving gateway (SGW), and / or the S5 / S8 bearer between SGW and PGW.

[0151] Once a packet associated with a specific QoS flow is received at AN 802 via resource 820A or resource 820B, AN 802 can segment the packet into corresponding QoS flows 856A-856C based on QoS profile 828. QoS profile 828 can be received from SMF. Each QoS profile may correspond to a QFI, for example, a QFI marked on uplink packets 812A-812E. Each QoS profile may include QoS parameters such as a 5G QoS identifier (5QI) and an allocation and reservation priority (ARP). QoS profiles for non-GBR QoS flows may also include additional QoS parameters such as reflection QoS attributes (RQA). QoS profiles for GBR QoS flows may also include additional QoS parameters such as guaranteed flow bit rate (GFBR), maximum flow bit rate (MFBR), and / or maximum packet loss rate. A 5QI may be a standardized 5QI with a one-to-one mapping to a standardized combination of 5G QoS features for each known service. A 5QI may also be a dynamically assigned 5QI with an undefined standardized 5QI value. 5QI can represent 5G QoS characteristics. 5QI can include resource type, default priority, packet delay budget (PDB), packet error rate (PER), maximum data burst size, and / or average window. Resource type can indicate a non-GBR QoS flow, a GBR QoS flow, or a delay-critical GBR QoS flow. Average window can represent the duration for calculating GFBR and / or MFBR. ARP can be a priority level including preemption capability and preemption vulnerability. Based on ARP, AN 802 can apply admission control to QoS flows under resource constraints.

[0152] AN 802 can select one or more N3 tunnels 850 for the transmission of QoS flows 856A-856C. After the packets are divided into QoS flows 856A-856C, the packets can be sent to UPF 805 (e.g., toward DN) via the selected one or more N3 tunnels 850. UPF 805 can verify that the QFI of uplink packets 812A-812E is aligned with QoS rule 814 provided to UE 801. UPF 805 can measure and / or count packets and / or provide packet metrics to, for example, PCF.

[0153] The diagram also illustrates the process used for the downlink. Specifically, one or more applications can generate downlink packets 852A-852E. UPF 805 can receive downlink packets 852A-852E from one or more DNs and / or one or more other UPFs. According to the QoS model, UPF 805 can apply Packet Detection Rule (PDR) 854 to downlink packets 852A-852E. Based on PDR 854, UPF 805 can map packets 852A-852E to QoS flows. In this diagram, downlink packets 852A and 852B are mapped to QoS flow 856A, downlink packet 852C is mapped to QoS flow 856B, and the remaining packets are mapped to QoS flow 856C.

[0154] QoS flows 856A-856C can be sent to AN 802. AN 802 can apply resource mapping rules to QoS flows 856A-856C. In this diagram, QoS flow 856A is mapped to resource 820A, while QoS flows 856B and 856C are mapped to resource 820B. To meet QoS requirements, resource mapping rules can allocate more resources to higher-priority QoS flows.

[0155] Figures 9A-9D Example states and state transitions of a wireless device (e.g., a UE) are shown. At any given time, a wireless device may be in Radio Resource Control (RRC) state, Registration Management (RM) state, and Connection Management (CM) state.

[0156] Figure 9A This is an example diagram illustrating the RRC state transitions of a wireless device (e.g., a UE). A UE can be in one of three RRC states: RRC Idle 910 (e.g., RRC_IDLE), RRC Inactive 920 (e.g., RRC_INACTIVE), or RRC Connected 930 (e.g., RRC_CONNECTED). A UE can implement different RAN-related control plane procedures based on its RRC state. Other elements of the network (e.g., base stations) can track the RRC states of one or more UEs and implement RAN-related control plane procedures suitable for each UE's RRC state.

[0157] In an RRC connection 930, the UE can exchange data with the network (e.g., a base station). The parameters necessary for establishing this data exchange can be established and are known to both the UE and the network. These parameters can be referred to and / or included in the UE's RRC context (sometimes referred to as the UE context). These parameters may include, for example: one or more AS contexts; one or more radio link configuration parameters; bearer configuration information (e.g., related to data radio bearers, signaling radio bearers, logical channels, QoS flows, and / or PDU sessions); security information; and / or PHY, MAC, RLC, PDCP, and / or SDAP layer configuration information. The base station connected to the UE can store the UE's RRC context.

[0158] When in RRC Connection 930, the UE's mobility can be managed by the access network, while the UE can manage its own mobility when in RRC Idle 910 and / or RRC Inactivity 920. When in RRC Connection 930, the UE can manage mobility by measuring signal levels (e.g., reference signal levels) from the serving cell and neighboring cells and reporting these measurements to the base station currently serving the UE. The network can initiate a handover based on the reported measurements. The RRC state can transition from RRC Connection 930 to RRC Idle 910 via Connection Release Procedure 930, or from RRC Connection 930 to RRC Inactivity 920 via Connection Inactivity Procedure 932.

[0159] During RRC Idle 910, an RRC context may not be established for the UE. During RRC Idle 910, the UE may not have an RRC connection with the base station. When in RRC Idle 910, the UE may be in sleep mode most of the time (e.g., to conserve battery power). The UE may wake up periodically (e.g., once in each discontinuous reception cycle) to monitor paging messages from the access network. UE mobility can be managed by the UE through a process called cell reselection. The RRC state can be transitioned from RRC Idle 910 to RRC Connection 930 via Connection Establishment Procedure 913, which may involve a random access procedure, discussed in more detail below.

[0160] In RRC inactivity 920, the previously established RRC context is maintained in both the UE and the base station. This allows for a faster transition to RRC connection 930 with reduced signaling overhead compared to the transition from RRC idle 910 to RRC connected 930. The RRC state can be transitioned to RRC connected 930 via connection restoration procedure 923. The RRC state can be transitioned to RRC idle 910 via connection release procedure 921, which can be the same as or similar to connection release procedure 931.

[0161] RRC status can be associated with mobility management mechanisms. In RRC Idle 910 and RRC Inactive 920, mobility can be managed by the UE through cell reselection. The purpose of mobility management in RRC Idle 910 and / or RRC Inactive 920 is to allow the network to notify the UE of events via paging messages without having to broadcast paging messages across the entire mobile network. The mobility management mechanisms used in RRC Idle 910 and / or RRC Inactive 920 allow the network to track the UE at the cell group level, enabling paging messages to be broadcast in the cells of the cell group where the UE is currently camped, rather than across the entire network. Tracking can be based on different packet granularities. For example, there can be three levels of cell packet granularity: individual cells; cells within a RAN area identified by a RAN Area Identifier (RAI); and cells within a RAN area group referred to as a tracking area and identified by a Tracking Area Identifier (TAI).

[0162] The tracking area can be used to track the UE at the CN level. The CN can provide the UE with a list of TAIs associated with the UE's registration area. If the UE moves to a cell associated with a TAI not included in the list of TAIs associated with the UE's registration area via cell reselection, the UE can perform a registration update with the CN to allow the CN to update the UE's location and provide the UE with a new UE registration area.

[0163] RAN areas can be used to track UEs at the RAN level. For a UE in the RRC Inactive 920 state, a RAN notification area can be assigned to the UE. A RAN notification area can include one or more cell identifiers, a list of RAIs, and / or a list of TAIs. In one example, a base station can belong to one or more RAN notification areas. In one example, a cell can belong to one or more RAN notification areas. If a UE moves via cell reselection to a cell not included in the RAN notification area assigned to the UE, the UE can perform a notification area update with the RAN to update the UE's RAN notification area.

[0164] The base station that stores the RRC context for the UE or the UE's last serving base station may be referred to as the anchor base station. The anchor base station may maintain the UE's RRC context at least during the time period when the UE is in the anchor base station's RAN notification area and / or during the time period when the UE is in RRC inactivity 920.

[0165] Figure 9B This is an example diagram illustrating the registration management (RM) state transitions of a wireless device (e.g., a UE). The states are RM deregistration 940 (e.g., RM-DEREGISTERED) and RM registration 950 (e.g., RM-REGISTERED).

[0166] In RM deregistration 940, the UE is not registered with the network, and the network cannot access the UE. To become accessible to the network, the UE must perform an initial registration. As an example, the UE can register with the network's AMF. If registration is rejected (Registration Rejection 944), the UE remains in RM deregistration 940. If registration is accepted (Registration Acceptance 945), the UE transitions to RM registration 950. While the UE is in RM registration 950, the network can store, maintain, and / or maintain the UE's UE context. The UE context can be referred to as the radio device context. The UE context corresponding to network registration (maintained by the core network) can be different from the RRC context corresponding to the RRC state (maintained by the access network (e.g., base station)). The UE context may include a record of the UE identifier and various information related to the UE, such as UE capability information, policy information for UE access and mobility management, a list of allowed or established slices or PDU sessions, and / or the UE's registration area (i.e., a list of tracking areas covering the geographic area where the radio device may be found).

[0167] When a UE is in RM Registration 950, the network can store the UE's UE context and use it to access the UE if necessary. Furthermore, the network may not provide certain services unless the UE is registered. A UE can update its UE context while remaining in RM Registration 950 (Registration Update Acceptance 955). For example, if a UE leaves one tracking area and enters another, the UE can provide the network with a tracking area identifier. The network can deregister the UE, or the UE can deregister itself (Deregistration 954). For example, if a radio device is inactive for a certain period of time, the network can automatically deregister the radio device. Upon deregistration, the UE can transition to RM Deregistration 940.

[0168] Figure 9C This is an example diagram illustrating the connection management (CM) state transitions of a wireless device from the perspective of the wireless device (e.g., UE). The UE may be in CM idle 960 (e.g., CM-IDLE) or CM connected 970 (e.g., CM-CONNECTED).

[0169] In CM Idle 960, the UE does not have a Non-Access Stratum (NAS) signaling connection with the network. As a result, the UE cannot communicate with core network functional units. The UE can transition to CM Connection 970 by establishing an AN signaling connection (AN signaling connection establishment 967). This transition can be initiated by sending an Initial NAS message. The Initial NAS message can be a registration request (e.g., if the UE is RM Deregistration 940) or a service request (e.g., if the UE is RM Registration 950). If the UE is RM Registration 950, the UE can initiate AN signaling connection establishment by sending a service request, or the network can send a paging request, thereby triggering the UE to send a service request.

[0170] In CM 970, the UE can communicate with core network functional units using NAS signaling. As an example, the UE can exchange NAS signaling with the AMF for registration management purposes, service request procedures, and / or authentication procedures. As another example, the UE can exchange NAS signaling with the SMF to establish and / or modify PDU sessions. The network can disconnect the UE, or the UE can disconnect itself (AN signaling connection release 976). For example, if the UE transitions to RM deregistration 940, the UE can also transition to CM Idle 960. When the UE transitions to CM Idle 960, the network can deactivate the user plane connection of the UE's PDU session.

[0171] Figure 9D This is an example diagram illustrating the CM state transitions of a wireless device (e.g., a UE) from a network perspective (e.g., the AMF). The UE's CM state, tracked by the AMF, can be in CM Idle 980 (e.g., CM-IDLE) or CM Connected 990 (e.g., CM-CONNECTED). When the UE transitions from CM Idle 980 to CM Connected 990, the AMF can establish the UE's N2 context (N2 context establishment 989). When the UE transitions from CM Connected 990 to CM Idle 980, the AMF can release the UE's N2 context (N2 context release 998).

[0172] Figure 10-12 An example procedure for UE registration, service request, and PDU session establishment is shown.

[0173] Figure 10 An example of a registration process for a wireless device (e.g., a UE) is shown. Based on the registration process, the UE can transition from, for example, RM deregistration 940 to RM registration 950.

[0174] Registration can be initiated by the UE for purposes such as obtaining authorization to receive services, enabling mobility tracking, enabling reachability, or other purposes. The UE can perform initial registration as the first step towards connecting to the network (e.g., if the UE is powered on, airplane mode is off, etc.). Registration can also be performed periodically to keep the network informed of the UE's presence (e.g., when in CM-IDLE state), or in response to changes in UE capabilities or registration area. Deregistration can be performed (…). Figure 10 (Not shown in the image) to stop network access.

[0175] At position 1010, the UE sends a registration request to the AN. As an example, the UE may have moved from the coverage area of ​​a previous AMF (illustrated as AMF#1) to the coverage area of ​​a new AMF (illustrated as AMF#2). The registration request can be a NAS message. The registration request can include the UE identifier. The AN can select an AMF for the UE's registration. For example, the AN can select a default AMF. For example, the AN can select an AMF already mapped to the UE (e.g., the previous AMF). The NAS registration request can include a network slice identifier, and the AN can select an AMF based on the requested slice. After the AMF is selected, the AN can send a registration request to the selected AMF.

[0176] At 1020, the AMF receiving the registration request (AMF#2) performs a context transfer. The context can be the UE context, such as the RRC context for the UE. As an example, AMF#2 can send a message to AMF#1 requesting the UE's context. This message can include the UE identifier. This message can be a Namf_Communication_UEContextTransfer message. AMF#1 can send a message to AMF#2 including the requested UE context. This message can also be a Namf_Communication_UEContextTransfer message. After receiving the UE context, AMF#2 can coordinate the UE's authentication. After authentication is complete, AMF#2 can send a message to AMF#1 indicating that the UE context transfer is complete. This message can be a Namf_Communication_UEContextTransfer response message.

[0177] Authentication may require the participation of the UE, AUSF, UDM, and / or UDR (not shown). For example, the AMF may request the AUSF to authenticate the UE. For example, the AUSF may perform UE authentication. For example, the AUSF may obtain authentication data from the UDM. For example, the AUSF may send a Subscription Permanent Identifier (SUPI) to the AMF based on successful authentication. For example, the AUSF may provide an intermediate key to the AMF. The intermediate key can be used to derive the UE's access-specific security key, enabling the AMF to perform Security Context Management (SCM). The AUSF may obtain subscription data from the UDM. Subscription data may be based on information obtained from the UDM (and / or UDR). Subscription data may include subscription identifiers, security credentials, access and mobility-related subscription data, and / or session-related data.

[0178] At position 1030, the new AMF (AMF#2) registers and / or subscribes to the UDM. AMF#2 can use the UDM's UE Context Management Service (Nudm_UECM) to perform registration. AMF#2 can use the UDM's Subscriber Data Management Service (Nudm_SDM) to obtain the UE's subscription information. If the UE's subscription information changes, AMF#2 can also request the UDM to notify AMF#2. When the new AMF registers and subscribes, the old AMF (AMF#1) can deregister and unsubscribe. After deregistration, AMF#1 is no longer responsible for the UE's mobility management.

[0179] At position 1040, AMF#2 retrieves the Access and Mobility (AM) policy from the PCF. As an example, AMF#2 can provide the PCF with the UE's subscription data. The PCF can determine the UE's access and mobility policy based on the subscription data, network operator data, current network conditions, and / or other suitable information. For example, the owner of the first UE might purchase a higher service tier than the owner of the second UE. The PCF can provide rules associated with different service tiers. Based on the respective UE's subscription data, the network can apply different policies to promote different service tiers.

[0180] For example, access and mobility policies may involve service area restrictions, RAT / Frequency Selection Priority (RFSP, where RAT stands for Radio Access Technology), authorization and prioritization of access types (e.g., LTE vs. NR), and / or selection of non-3GPP access (e.g., Access Network Discovery and Selection Policy (ANDSP)). Service area restrictions may include a list of tracking areas that allow (or prohibit) the UE from being served. Access and mobility policies may include UE Routing Selection Policy (URSP) that affects the routing of established or new PDU sessions. As mentioned above, different policies may be obtained and / or implemented based on the UE's subscription data, the UE's location (i.e., the location of the AN and / or AMF), or other suitable factors.

[0181] At 1050, AMF#2 can update the context of the PDU session. For example, if the UE has an existing PDU session, AMF#2 can coordinate with the SMF to activate the user plane connection associated with the existing PDU session. The SMF can update and / or release the session management context of the PDU session (Nsmf_PDUSession_UpdateSMContext, Nsmf_PDUSession_ReleaseSMContext).

[0182] At position 1060, AMF#2 sends a registration acceptance message to the AN, and the AN forwards the registration acceptance message to the UE. The registration acceptance message may include the new UE identifier and / or the newly configured slice identifier. The UE may send a registration completion message to the AN, and the AN forwards the registration completion message to AMF#2. The registration completion message confirms receipt of the new UE identifier and / or the newly configured slice identifier.

[0183] At position 1070, AMF#2 can obtain UE policy control information from the PCF. The PCF can provide Access Network Discovery and Selection Policy (ANDSP) to facilitate non-3GPP access. The PCF can provide UE Routing Policy (URSP) to facilitate the mapping of specific data services to specific PDU session connection parameters. As an example, URSP can indicate that data services associated with a specific application should be mapped to a specific SSC mode, network slice, PDU session type, or preferred access type (3GPP or non-3GPP).

[0184] Figure 11 An example of a service request process for a wireless device (e.g., a UE) is shown. Figure 11 The service request procedure described herein is a network-triggered service request procedure for a UE in CM-IDLE state. However, other service request procedures (e.g., UE-triggered service request procedures) may also be referenced. Figure 11To understand this, as will be discussed in more detail below.

[0185] At 1110, the UPF receives data. This data can be downlink data for transmission to the UE. This data can be associated with an existing PDU session between the UE and the DN. For example, data can be received from the DN and / or another UPF. The UPF can buffer the received data. In response to the data reception, the UPF can notify the SMF of the received data. The identity of the SMF to be notified can be determined based on the received data. This notification can be, for example, an N4 session report. This notification can indicate that the UPF has received data associated with the UE and / or a specific PDU session associated with the UE. In response to receiving the notification, the SMF can send PDU session information to the AMF. The PDU session information can be sent in the N1N2 message transmission used for forwarding to the AN. The PDU session information can include, for example, UPF tunnel endpoint information and / or QoS information.

[0186] At 1120, the AMF determines that the UE is in CM-IDLE state. This determination at 1120 can be made in response to the receipt of PDU session information. Based on the determination that the UE is CM-IDLE, the service request process can proceed to 1130 and 1140, as follows... Figure 11 As shown. However, if the UE is not CM-IDLE (e.g., the UE is CM-CONNECTED), steps 1130 and 1140 can be skipped, and the service request process can proceed directly to step 1150.

[0187] At 1130, the AMF pages the UE. Paging at 1130 can be performed based on the UE being CM-IDLE. To perform paging, the AMF can send a paging request to the AN. The paging request can be referred to as a paging message or a paging request. The paging request can be an N2 request message. The AN can be one of several ANs in the UE's RAN notification area. The AN can send a paging request to the UE. The UE can be within the AN's coverage area and can receive the paging request.

[0188] At point 1140, the UE can request service. The UE can send a service request to the AMF via the AN. For example... Figure 11 As described, a UE can request service at 1140 in response to receiving a paging at 1130. However, as mentioned above, this is specific to a network-triggered service request procedure. In some scenarios (e.g., if uplink data becomes available at the UE), the UE can initiate a UE-triggered service request procedure. A UE-triggered service request procedure can begin at 1140.

[0189] At 1150, the network can authenticate the UE. Authentication may require the participation of the UE, AUSF, and / or UDM, for example, authentication similar to that described elsewhere in this disclosure. In some cases (e.g., if the UE has recently been authenticated), authentication at 1150 can be skipped.

[0190] At 1160, AMF and SMF can perform PDU session updates. As part of the PDU session update, SMF can provide AMF with one or more UPF tunnel endpoint identifiers. In some cases ( Figure 11 (not shown in the image), an SMF may need to coordinate with one or more other SMFs and / or one or more other UPFs to establish a user face.

[0191] At 1170, the AMF can send PDU session information to the AN. The PDU session information can be included in the N2 request message. Based on the PDU session information, the AN can configure user plane resources for the UE. To configure user plane resources, the AN can, for example, perform an RRC reconfiguration of the UE. The AN can acknowledge to the AMF that it has received the PDU session information. The AN can notify the AMF that user plane resources have been configured and / or provide information related to user plane resource configuration.

[0192] In the case of a UE-triggered service request procedure, the UE can receive a NAS service acceptance message from the AMF via the AN at 1170. After configuring user plane resources, the UE can send uplink data (e.g., uplink data that causes the UE to trigger a service request procedure).

[0193] At 1180, the AMF can update the Session Management (SM) context of the PDU session. For example, the AMF can notify the SMF (and / or one or more other associated SMFs) that user plane resources have been configured, and / or provide information related to user plane resource configuration. The AMF can provide the SMF (and / or one or more other associated SMFs) with one or more AN tunnel endpoint identifiers. After the SM context update is complete, the SMF can send an Update SM Context Response message to the AMF.

[0194] Based on updates to the Session Management Context (SMF), the SMF can update the PCF for policy control purposes. For example, if the UE's location has changed, the SMF can notify the PCF of the UE's new location.

[0195] Based on updates to the session management context, the SMF and UPF can perform session modifications. Session modifications can be performed using N4 session modification messages. After the session modification is complete, the UPF can send downlink data to the UE (e.g., downlink data that causes the UPF to trigger a network-triggered service request procedure). The transmission of downlink data can be based on one or more AN tunnel endpoint identifiers.

[0196] Figure 12 An example of a Protocol Data Unit (PDU) session establishment process for a wireless device (e.g., a UE) is shown. The UE may decide to send a PDU session establishment request to create a new PDU session, switch an existing PDU session to a 3GPP network, or for any other suitable reason.

[0197] At 1210, the UE initiates a PDU session establishment. The UE can send a PDU session establishment request to the AMF via the AN. The PDU session establishment request can be a NAS message. The PDU session establishment request can indicate: the PDU session ID; the requested PDU session type (new or existing); the requested DN (DNN); the requested network slice (S-NSSAI); the requested SSC mode; and / or any other suitable information. The PDU session ID can be generated by the UE. The PDU session type can be, for example, an Internet Protocol (IP) based type (e.g., IPv4, IPv6, or dual-stack IPv4 / IPv6), an Ethernet type, or an unstructured type.

[0198] The AMF can select an SMF based on a PDU session establishment request. In some scenarios, the requested PDU session may already be associated with a specific SMF. For example, the AMF may store the UE's UE context, and the UE context may indicate that the PDU session ID of the requested PDU session is already associated with a specific SMF. In other scenarios, the AMF can select an SMF based on determining that the SMF is ready to handle the requested PDU session. For example, the requested PDU session may be associated with a specific DNN and / or S-NSSAI, and the SMF can be selected based on determining that it can manage PDU sessions associated with a specific DNN and / or S-NSSAI.

[0199] At 1220, the context of the network management PDU session is established. After selecting the SMF at 1210, the AMF sends a PDU session context request to the SMF. The PDU session context request may include the PDU session establishment request received from the UE at 1210. The PDU session context request may be an Nsmf_PDUSession_CreateSMContext request and / or an Nsmf_PDUSession_UpdateSMContext request. The PDU session context request may indicate the UE's identifier; the requested DN; and / or the requested network slice. Based on the PDU session context request, the SMF can retrieve subscription data from the UDM. The subscription data may be the UE's session management subscription data. The SMF can subscribe to updates to the subscription data so that if the UE's subscription data changes, the PCF will send new information. After obtaining the UE's subscription data, the SMF can send a PDU session context response to the AMG. The PDU session context response may be an Nsmf_PDUSession_CreateSMContext response and / or an Nsmf_PDUSession_UpdateSMContext response. The PDU session context response may include the session management context ID.

[0200] At point 1230, auxiliary authorization / authentication can be performed if needed. Auxiliary authorization / authentication can involve the UE, AMF, SMF, and DN. The SMF can access the DN via a Data Network Authentication, Authorization, and Accounting (DN AAA) server.

[0201] At position 1240, the network establishes a data path for uplink data associated with a PDU session. The SMF can select a PCF and establish a session management policy association. Based on this association, the PCF can provide an initial set of policy control and charging rules (PCC rules) for the PDU session. When targeting a specific PDU session, the PCF can instruct the SMF on the method for assigning IP addresses to the PDU session, the default charging method for the PDU session, the address of the corresponding charging entity, triggers for requesting new policies, etc. The PCF can also target Service Data Flows (SDFs) that include one or more PDU sessions. When targeting an SDF, the PCF can instruct the SMF on policies for applying QoS requirements, monitoring services (e.g., for charging purposes), and / or guiding services (e.g., by using one or more specific N6 interfaces).

[0202] SMF can determine and / or assign IP addresses for PDU sessions. SMF can select one or more UPFs (User-Defined Functions). Figure 12In the example, a single UPF (Service Provider Function) handles a PDU session. The SMF can send N4 session messages to the selected UPF. N4 session messages can be N4 session establishment requests and / or N4 session modification requests. N4 session messages can include packet detection, enforcement, and reporting rules associated with the PDU session. In response, the UPF can acknowledge by sending an N4 session establishment response and / or an N4 session modification response.

[0203] The SMF can send PDU session management information to the AMF. PDU session management information can be a session service request (e.g., Namf_Communication_N1N2MessageTransfer) message. PDU session management information can include the PDU session ID. PDU session management information can be a NAS message. PDU session management information can include N1 session management information and / or N2 session management information. N1 session management information can include a PDU session establishment acceptance message. The PDU session establishment acceptance message can include UPF tunnel endpoint information and Quality of Service (QoS) information associated with the PDU session.

[0204] The AMF can send an N2 request to the AN. The N2 request may include a PDU session establishment acceptance message. Based on the N2 request, the AN can determine the AN resources for the UE. The UE can use the AN resources to establish a PDU session with the DN via the AN. The AN can determine the resources to be used for the PDU session and indicate the determined resources to the UE. The AN can send a PDU session establishment acceptance message to the UE. For example, the AN can perform an RRC reconfiguration for the UE. After establishing the AN resources, the AN can send an N2 request confirmation to the AMF. The N2 request confirmation may include N2 session management information, such as the AN's PDU session ID and tunnel endpoint information.

[0205] After establishing a data path for uplink data at point 1240, the UE can optionally transmit uplink data associated with the PDU session. For example... Figure 12 As shown, uplink data can be sent to the DN associated with the PDU session via the AN and UPF.

[0206] At position 1250, the network can update the PDU session context. The AMF can send a PDU session context update request to the SMF. The PDU session context update request can be an Nsmf_PDUSession_UpdateSMContext request. The PDU session context update request can include N2 session management information received from the AN. The SMF can acknowledge the PDU session context update. The acknowledgment can be an Nsmf_PDUSession_UpdateSMContext response. This acknowledgment can include a request to notify the SMF of any UE mobility event subscriptions. Based on the PDU session context update request, the SMF can send an N4 session message to the UPF. The N4 session message can be an N4 session modification request. The N4 session message can include tunnel endpoint information of the AN. The N4 session message can include forwarding rules associated with the PDU session. In response, the UPF can acknowledge by sending an N4 session modification response.

[0207] After receiving the tunnel endpoint information from the AN, the UPF can relay downlink data associated with the PDU session. For example... Figure 12 As shown, downlink data can be received from the DN associated with the PDU session via the AN and UPF.

[0208] Figure 13 An example of a component in a communication network is shown. Figure 13 The physical deployment (hereinafter referred to as "Deployment 1330") includes wireless device 1310, base station 1320, and one or more network functional units 1330. Any wireless device described in this disclosure may have components similar to those of wireless device 1310 and may be implemented in a similar manner to wireless device 1310. Any other base station (or any part thereof, depending on the architecture of the base station) described in this disclosure may have components similar to those of base station 1320 and may be implemented in a similar manner to base station 1320. Any physical core network deployment (or any part thereof, depending on the architecture of the base station) in this disclosure may have components similar to those of deployment 1330 and may be implemented in a similar manner to deployment 1330.

[0209] Wireless device 1310 can communicate with base station 1320 via air interface 1370. The communication direction from wireless device 1310 to base station 1320 via air interface 1370 is called the uplink, and the communication direction from base station 1320 to wireless device 1310 via air interface 1370 is called the downlink. Some combination of FDD, TDD, and / or duplex technologies can be used to separate downlink transmissions from uplink transmissions. Figure 13A single wireless device 1310 and a single base station 1320 are shown, but it should be understood that the wireless device 1310 can communicate with any number of base stations or other access network components via the air interface 1370, and the base station 1320 can communicate with any number of wireless devices via the air interface 1370.

[0210] Wireless device 1310 may include processing system 1311 and memory 1312. Memory 1312 may include one or more computer-readable media, such as one or more non-transitory computer-readable media. Memory 1312 may include instructions 1313. Processing system 1311 may process and / or execute instructions 1313. Processing and / or execution of instructions 1313 may cause wireless device 1310 and / or processing system 1311 to perform one or more functions or activities. Memory 1312 may include data (not shown). One of the functions or activities performed by processing system 1311 may be storing data in memory 1312 and / or retrieving previously stored data from memory 1312. In one example, downlink data received from base station 1320 may be stored in memory 1312, and uplink data used for transmission to base station 1320 may be retrieved from memory 1312. Figure 13 As shown, wireless device 1310 can communicate with base station 1320 using transmission processing system 1314 and / or reception processing system 1315. Alternatively, transmission processing system 1314 and reception processing system 1315 can be implemented as a single processing system, or both can be omitted and all processing in wireless device 1310 can be performed by processing system 1311. Although Figure 13 Not shown, but the transmission processing system 1314 and / or the reception processing system 1315 may be coupled to a dedicated memory similar to but separate from the memory 1312, and include instructions that can be processed and / or executed to perform one or more of their respective functions. The wireless device 1310 may include one or more antennas 1316 for access to the air interface 1370.

[0211] Wireless device 1310 may include one or more other elements 1319. These other elements 1319 may include software and / or hardware providing features and / or functionality, such as a speaker, microphone, keypad, display, touchpad, satellite transceiver, Universal Serial Bus (USB) port, hands-free headset, FM radio unit, media player, internet browser, electronic control unit (e.g., for motor vehicles), and / or one or more sensors (e.g., accelerometer, gyroscope, temperature sensor, radar sensor, lidar sensor, ultrasonic sensor, light sensor, camera, GPS sensor, etc.). Wireless device 1310 may receive user input data from and / or provide user output data to one or more other elements 1319. These other elements 1319 may include a power source. Wireless device 1310 may receive power from the power source and may be configured to distribute power to other components in wireless device 1310. The power source may include one or more power sources, such as a battery, solar cell, fuel cell, or any combination thereof.

[0212] Wireless device 1310 can transmit uplink data to base station 1320 and / or receive downlink data from base station 1320 via air interface 1370. To perform transmission and / or reception, one or more of processing system 1311, transmission processing system 1314, and / or receiving system 1315 can implement Open Systems Interconnection (OSI) functions. As an example, transmission processing system 1314 and / or receiving system 1315 can perform Layer 1 OSI functions, and processing system 1311 can perform higher-layer functions. Wireless device 1310 can use one or more antennas 1316 to transmit and / or receive data via air interface 1370. In scenarios where one or more antennas 1316 include multiple antennas, the multiple antennas can be used to perform one or more multi-antenna techniques, such as spatial multiplexing (e.g., single-user multiple-input multiple-output (MIMO) or multi-user MIMO), transmit / receive diversity, and / or beamforming.

[0213] Base station 1320 may include processing system 1321 and memory 1322. Memory 1322 may include one or more computer-readable media, such as one or more non-transitory computer-readable media. Memory 1322 may include instructions 1323. Processing system 1321 may process and / or execute instructions 1323. Processing and / or execution of instructions 1323 may cause base station 1320 and / or processing system 1321 to perform one or more functions or activities. Memory 1322 may include data (not shown). One of the functions or activities performed by processing system 1321 may be storing data in memory 1322 and / or retrieving previously stored data from memory 1322. Base station 1320 may communicate with wireless device 1310 using transmitting processing system 1324 and receiving processing system 1325. Although Figure 13 Not shown, but the transmitting processing system 1324 and / or the receiving processing system 1325 may be coupled to a dedicated memory similar to but separate from the memory 1322, and include instructions that can be processed and / or executed to perform one or more of their respective functions. The wireless device 1320 may include one or more antennas 1326 for access to the air interface 1370.

[0214] Base station 1320 can transmit downlink data to and / or receive uplink data from wireless device 1310 via air interface 1370. To perform transmission and / or reception, one or more of processing system 1321, transmission processing system 1324, and / or receiving system 1325 can implement OSI functions. As an example, transmission processing system 1324 and / or receiving system 1325 can perform Layer 1 OSI functions, and processing system 1321 can perform higher-layer functions. Base station 1320 can use one or more antennas 1326 to transmit and / or receive data via air interface 1370. In scenarios where one or more antennas 1326 include multiple antennas, the multiple antennas can be used to perform one or more multi-antenna techniques, such as spatial multiplexing (e.g., single-user multiple-input multiple-output (MIMO) or multi-user MIMO), transmit / receive diversity, and / or beamforming.

[0215] Base station 1320 may include interface system 1327. Interface system 1327 may communicate with one or more base stations and / or one or more elements of the core network via interface 1380. Interface 1380 may be wired and / or wireless, and interface system 1327 may include one or more components suitable for communication via interface 1380. Figure 13In this configuration, interface 1380 connects base station 1320 to a single deployment 1330; however, it should be understood that wireless device 1310 can communicate with any number of base stations and / or CN deployments via interface 1380, and deployment 1330 can communicate with any number of base stations and / or other CN deployments via interface 1380. Base station 1320 may include one or more other elements 1329 similar to one or more of other elements 1319.

[0216] Deployment 1330 may include any number of portions of any number of instances of one or more Network Functional Units (NFs). Deployment 1330 may include processing system 1331 and memory 1332. Memory 1332 may include one or more computer-readable media, such as one or more non-transitory computer-readable media. Memory 1332 may include instructions 1333. Processing system 1331 may process and / or execute instructions 1333. Processing and / or execution of instructions 1333 may cause deployment 1330 and / or processing system 1331 to perform one or more functions or activities. Memory 1332 may include data (not shown). One of the functions or activities performed by processing system 1331 may be storing data in memory 1332 and / or retrieving previously stored data from memory 1332. Deployment 1330 may use interface system 1337 to access interface 1380. Deployment 1330 may include one or more other elements 1339 similar to one or more of other elements 1319.

[0217] One or more of systems 1311, 1314, 1315, 1321, 1324, 1325, and / or 1331 may include one or more controllers and / or one or more processors. One or more controllers and / or one or more processors may include, for example, a general-purpose processor, a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and / or other programmable logic devices, discrete gate and / or transistor logic, discrete hardware components, onboard units, or any combination thereof. One or more of systems 1311, 1314, 1315, 1321, 1324, 1325, and / or 1331 may perform signal encoding / processing, data processing, power control, input / output processing, and / or any other function that enables wireless device 1310, base station 1320, and / or deployment 1330 to operate in a mobile communication system.

[0218] Many of the elements described in the disclosed embodiments can be implemented as modules. A module is defined herein as an element that performs a defined function and has an interface to the definitions of other elements. Modules described in this disclosure can be implemented in hardware, software combined with hardware, firmware, wet hardware (e.g., hardware with biological elements), or a combination thereof, and may be behaviorally equivalent. For example, a module can be implemented as a software routine or modeling / simulation program (such as Simulink, Stateflow, GNU Octave, or LabVIEW MathScript) written in a computer language (such as C, C++, Fortran, Java, Basic, Matlab, etc.) configured to be executed by a hardware machine. Modules can be implemented using physical hardware that includes discrete or programmable analog, digital, and / or quantum hardware. Examples of programmable hardware include computers, microcontrollers, microprocessors, DSPs, ASICs, FPGAs, and complex programmable logic devices (CPLDs). Computers, microcontrollers, and microprocessors can be programmed using languages ​​such as assembly, C, C++, etc. FPGAs, ASICs, and CPLDs are typically programmed using hardware description languages ​​(HDLs), such as VHSIC Hardware Description Language (VHDL) or Verilog, which configure the connections between internal hardware modules with limited functionality on the programmable device. The techniques mentioned are often used in combination to achieve the desired functional modules.

[0219] Wireless device 1310, base station 1320, and / or deployment 1330 may implement timers and / or counters. A timer / counter may start from an initial value. Startup, as used herein, may include restarting. Once started, the timer / counter can run. The operation of a timer / counter may be associated with an occurrence. When an occurrence occurs, the value of the timer / counter may change (e.g., increment or decrement). An occurrence may be, for example, an external event (e.g., receiving a signal, measuring a condition, etc.), an internal event (e.g., sending a signal, calculating, comparing, performing an action, or deciding to perform such an action, etc.) or any combination thereof. In the case of a timer, an occurrence may be the elapsed amount of time. However, it should be understood that a timer may be described and / or implemented as a counter that counts the elapsed time of a specific unit of time. A timer / counter may run in the direction of a final value until it reaches that final value. Reaching the final value may be referred to as the expiration of the timer / counter. The final value may be referred to as a threshold. A timer / counter may be paused, wherein the current value of the timer / counter is maintained, preserved, and / or carried over, even when one or more events occur that would otherwise cause the value of the timer / counter to change. The timer / counter can be unpaused or continuous, wherein the value held, maintained, and / or carried begins to change again when an event occurs once or multiple times. The timer / counter can be set and / or reset. Setting can include resetting, as used herein. When a timer / counter is set and / or reset, its value can be set to an initial value. The timer / counter can be started and / or restarted. Starting can include restarting, as used herein. In some embodiments, when a timer / counter is restarted, its value can be set to the initial value, and the timer / counter can begin running.

[0220] Figure 14A , 14B Figures 14C and 14D illustrate various example arrangements of physical core network deployments, each with one or more network functional elements or portions thereof. Core network deployments include deployments 1410, 1420, 1430, 1440, and / or 1450. Each deployment can be similar to, for example... Figure 13Deployment 1330 is depicted in the diagram. Specifically, each deployment may include a processing system for performing one or more functions or activities, a memory for storing data and / or instructions, and an interface system for communicating with other network elements (e.g., other core network deployments). Each deployment may include one or more network functional units (NFs). The term NF may refer to a specific set of functions and / or one or more physical elements configured to perform those functions (e.g., a processing system and memory including instructions that, when executed by the processing system, cause the processing system to perform the function). For example, in this disclosure, when a network functional unit is described as performing X, Y, and Z, it should be understood that this refers to one or more physical elements configured to perform X, Y, and Z, regardless of how or where the one or more physical elements are deployed. The term NF may refer to a network node, network element, and / or network device.

[0221] As will be discussed in more detail below, there are many different types of NFs, and each type of NF can be associated with different sets of functions. Multiple different NFs can be flexibly deployed in different locations (e.g., in different physical core network deployments) or in the same location (e.g., co-located in the same deployment). A single NF can be flexibly deployed in different locations (using different physical core network deployments) or in the same location. Furthermore, a physical core network deployment can also implement one or more base stations, application functional units (AFs), data networks (DNs), or any part thereof. NFs can be implemented in many ways, including as network elements on dedicated or shared hardware, as software instances running on dedicated or shared hardware, or as virtualized functional units instantiated on a platform (e.g., a cloud-based platform).

[0222] Figure 14A An example arrangement of a core network deployment, in which each deployment includes a network functional unit, is shown. Deployment 1410 includes NF 1411, deployment 1420 includes NF 1421, and deployment 1430 includes NF 1431. Deployments 1410, 1420, and 1430 communicate via interface 1490. Deployments 1410, 1420, and 1430 may have different physical locations with different signal propagation delays relative to other network elements. The diversity of physical locations of deployments 1410, 1420, and 1430 enables services to be provided to a wide area with improved speed, coverage, security, and / or efficiency.

[0223] Figure 14B An example layout is shown where a single deployment includes more than one NF. (Compared to...) Figure 14A (Each NF is deployed in a separate deployment) is different. Figure 14BMultiple NFs in deployments 1410 and 1420 are shown. In one example, deployments 1410 and 1420 can implement software-defined networking (SDN) and / or network function virtualization (NFV).

[0224] For example, deployment 1410 includes an additional network functional unit NF 1411A. NF 1411 and NF 1411A may consist of multiple instances of the same NF type, located together in the same physical location within the same deployment 1410. NF 1411 and NF 1411A may be implemented independently of each other (e.g., isolated and / or independently controlled). For example, NF 1411 and NF 1411A may be associated with different network slices. In addition to all the functions associated with NF 1411A, the processing system and memory associated with deployment 1410 can perform all the functions associated with NF 1411. In one example, NF 1411 and NF 1411A may be associated with different PLMNs, but deployment 1410 implementing NF 1411 and NF 1411A may be owned and / or operated by a single entity.

[0225] exist Figure 14B Elsewhere, deployment 1420 includes NF 1421 and additional network functional unit NF 1422. NF 1421 and NF 1422 can be different NF types. Similar to NF 1411 and NF 1411A, NF 1421 and NF 1422 can coexist within the same deployment 1420, but are implemented separately. As an example, a first PLMN can own and / or operate deployment 1420 with NF 1421 and NF 1422. As another example, a first PLMN can implement NF 1421, and a second PLMN can obtain (e.g., lease, purchase, etc.) at least a portion of the capabilities of deployment 1420 (e.g., processing power, data storage, etc.) from the first PLMN to implement NF 1422. As yet another example, the deployment can be owned and / or operated by one or more third parties, and the first PLMN and / or the second PLMN can purchase the corresponding portion of the capabilities of deployment 1420. When multiple NFs are provided at a single deployment, the network can operate with greater speed, coverage, security, and / or efficiency.

[0226] Figure 14CAn example core network deployment is shown, in which multiple different deployments are used to implement a single instance of an NF. Specifically, a single instance of NF 1422 is implemented at deployments 1420 and 1440. As an example, the functionality provided by NF 1422 can be implemented as a series or sequence of sub-services. Each sub-service can be implemented independently, for example, at different deployments. Each sub-service can be implemented in different physical locations. By distributing the implementation of sub-services of a single NF across different physical locations, mobile communication networks can operate with greater speed, coverage, security, and / or efficiency.

[0227] Figure 14D This illustrates an example deployment of the core network in which data processing services are used to implement one or more network functional units. Figure 14D In this context, NF 1411, NF 1411A, NF 1421, and NF 1422 are included in deployment 1450, which is implemented as a data processing service. Deployment 1450 may include, for example, a cloud network and / or a data center. Deployment 1450 may be owned and / or operated by a PLMN or a non-PLMN third party. NF 1411, NF 1411A, NF 1421, and NF 1422 implemented using deployment 1450 may belong to the same PLMN or different PLMNs. The PLMN may acquire (e.g., lease, purchase, etc.) at least a portion of the capabilities of deployment 1450 (e.g., processing power, data storage, etc.). By providing one or more NFs through the data processing service, mobile communication networks can operate with greater speed, coverage, security, and / or efficiency.

[0228] As shown in the figure, different network elements (e.g., NFs) may reside in different physical deployments or coexist in a single physical deployment. It should be understood that, in this disclosure, unless explicitly stated otherwise, sending and receiving messages between different network elements is not limited to inter-deployment or intra-deployment transmissions.

[0229] In one example, a deployment can be a "black box" that is pre-configured with one or more NFs and pre-configured to communicate with other "black box" deployments in a prescribed manner (e.g., via interface 1490). Alternatively, a deployment can be configured to operate according to open-source instructions (e.g., software) designed to implement NFs and communicate with other deployments transparently. Deployments can operate according to Open RAN (O-RAN) standards.

[0230] One of the advancements enabled by 5G systems (5GS) is the use of new frequency bands that were not actively used in previous generations of communication systems (e.g., 4G, 3G). For example, as equipment components of mobile communication systems begin to support higher frequencies (e.g., millimeter waves), 5G systems can support higher bit rates via these higher frequencies.

[0231] However, one of the problems with using higher frequencies is that the communication range supported by higher frequencies is shorter than that supported by lower frequencies (e.g., centimeter waves). Figure 15 As the example illustrates, as long as a user's mobile device (e.g., UE A) is within the cell's coverage area (e.g., the base station's signal strength is above the minimum threshold required to maintain communication), the user (e.g., UE A) can enjoy higher data bitrate services. However, as the communication range supported by the cell shortens due to the use of higher frequencies, another user (e.g., UE B) is more likely to be outside the cell's coverage area, and communication services may not be available to that user. This can lead to reduced availability of communication services in 5G systems and more disruptions to communication services.

[0232] like Figure 16As illustrated in the example, a remote UE (e.g., remote C, remote UE C) can benefit from using sidelink communication (e.g., PC5 communication) via a relay UE (e.g., relay A, e.g., a wireless relay device, a relay wireless device). In one example, a user of the remote UE can decide to use a relay UE. For example, when the remote UE is outside the coverage area of ​​a base station, the remote UE (e.g., a remote wireless device) may not be able to communicate directly with one or more cells of the base station (e.g., not using another intermediate UE). Based on the fact that the remote UE cannot communicate directly with the base station, the user of the remote UE can decide to use a relay service (e.g., data communication between the remote UE and the network (e.g., an application server, a base station, a UPF, etc.) via one or more relay UEs). To use a relay service, the remote UE can begin searching for candidate relay UEs. For example, the remote UE may be configured with first relay policy information by a configuration server (e.g., PCF, AF, AMF, SMF, etc.). For example, the first relay policy information may indicate (including) at least one of one or more relay service codes (RSCs) allowed for the remote UE (e.g., RSC 1) and an indication of whether the remote UE is allowed to use relay services from the relay UE (e.g., authorization information). Similarly, the relay UE may be configured with second relay policy information by a configuration server. For example, the second relay policy information may indicate (including) at least one of one or more relay service codes allowed for the relay UE (e.g., RSC 1) and / or a second indication of whether the relay UE is allowed to provide one or more relay services to the remote UE (associated with an RSC). The remote UE may find one or more candidate relay UEs that can relay data services between the base station and the remote UE. For example, the relay UE may send a sidelink advertisement message (e.g., a sidelink advertisement message, such as a Prose PC5 discovery message for advertisement). For example, based on the relay UE being allowed to provide one or more relay services, the sidelink advertisement message may include one or more RSCs. In one example, the remote UE may receive a sidelink advertisement message. Based on the first trunk policy information including RSC 1 and / or based on the sidelink advertisement message including RSC 1, the remote UE can determine that it can use the trunk UE for trunk services (e.g., trunk service 1 associated with RSC 1). The remote UE can select a trunk UE from one or more found candidate trunk UEs. For example, the remote UE can establish a sidelink connection with the trunk UE (e.g., by sending / receiving a direct link connection request and / or by receiving / sending a direct link connection acceptance, etc.).In one example, based on the establishment of a sidelink connection between the relay UE and the remote UE and / or based on the remote UE's instruction of RSC 1, the relay UE can utilize the network to establish (send / receive PDU session establishment / modification messages) a PDU session associated with RSC 1 with the SMF. After the PDU session is established, the relay UE can receive one or more packets sent by the remote UE and / or can deliver one or more packets to the network (e.g., base station, UPF). By using the communication links between the remote UE and the relay UE, and between the relay UE and the base station, data services can be exchanged between the remote UE and the application server. However, this mechanism may not be sufficient to support the communication of the remote UE when one or more found candidate relay UEs are located outside the cell's coverage (e.g., cannot directly connect to the cell (e.g., base station)).

[0233] In such Figure 17 In the example shown, different types of relay UEs can be used. For example, different types of relay UEs may include one or more first-type relay UEs and / or one or more second-type relay UEs. For example, one or more first-type relay UEs may be one or more relay UEs located within the cell coverage (e.g., relay B), and / or may be directly connected to the cell. For example, one or more second-type relay UEs may be one or more UEs located outside the cell coverage (e.g., relay A), and may be indirectly connected to the cell (e.g., to the base station, to the network) via one or more other relay UEs (e.g., one or more first-type relay UEs). For example, in order to relay services from a remote UE to the network, one or more second-type relay UEs may need to connect to one or more first-type relay UEs. For example, because the second UE (e.g., relay A) of one or more second-type relay UEs is located outside the cell coverage, the second UE may need to connect to the sidelink of the first UE (e.g., relay B) of one or more first-type relay UEs to deliver services from the remote UE (e.g., the UE served by the second UE) to the network. For example, if the first UE receives a service from a remote UE via the second UE, the first UE can deliver the service to the network (e.g., base station, UPF, data network) via a PDU session.

[0234] In one example, a configuration server (e.g., a PCF via control plane signaling, an AMF via control plane signaling, a configuration server via user plane signaling, etc.) may send one or more configuration information to one or more UEs. For example, the one or more UEs may include one or more relay UEs (e.g., relay A, relay B) and / or one or more remote UEs (e.g., remote C). For example, the one or more configuration information may include a first configuration and / or a second configuration. The first configuration may include information for the one or more relay UEs. For example, the first configuration may indicate at least one of one or more Relay Service Codes (RSCs) used to indicate one or more first relay services. For example, the first configuration may indicate that one or more relay UEs are permitted (authorized) to relay services (associated with one or more first relay services) for one or more remote UEs. The second configuration may include information for the one or more remote UEs (e.g., information used when one or more remote UEs need to use relay services). For example, the second configuration may indicate at least one of one or more Relay Service Codes (RSCs) used to indicate one or more second relay services. For example, the second configuration may indicate that one or more remote UEs are permitted (authorized) to use one or more second relay services. For example, one or more first trunk services may include the first trunk service and / or the RSC for the first trunk service may be RSC(1). For example, one or more second trunk services may include the second trunk service and / or the RSC for the second trunk service may be RSC(1).

[0235] In one example, relay B may be located within the coverage of the base station, and / or relay A may be located outside the coverage of the base station. Because relay A is outside the coverage, and / or because relay A cannot establish a direct (network) connection to the base station, relay A can determine to establish a sidelink connection with relay B to connect to the network.

[0236] In one example, relay B can initiate / trigger the establishment of a PDU session and / or initiate / trigger modifications to the PDU session (e.g., updates). For example, the PDU session can be associated with RSC(1), and / or the PDU session can be used to relay services associated with RSC(1). For example, the PDU session can be associated with a network slice and / or data network linked to RSC(1).

[0237] In one example, because relay B has a PDU session associated with RSC(1), because relay B is authorized to relay, and / or because relay B has information about RSC(1), relay B can send a first-side traverse advertisement message (e.g., message 4B, step 4B). For example, the first-side traverse advertisement message can indicate RSC(1).

[0238] In one example, because relay A is authorized to relay, and / or because relay A has information of RSC(1), relay A can send a second-side traverse advertisement message (e.g., message 4A, step 4A). For example, the second-side traverse advertisement message can indicate RSC(1).

[0239] In one example, remote C may receive a first-side crosslink advertisement message, and / or remote C may receive a second-side crosslink advertisement message. Because remote C is authorized to use a trunk, and because remote C is configured (e.g., authorized for) RSC(1), remote C can determine which trunk service to use associated with RSC(1). Because the first-side crosslink advertisement message indicates RSC(1), remote C may consider trunk B as the first candidate trunk. Because the second-side crosslink advertisement message indicates RSC(1), remote C may consider trunk A as the second candidate trunk. Because there are multiple candidate trunks, remote C can perform a selection of a trunk. For example, based on the fact that a first measured signal strength (e.g., -30 dBm RSRP) of trunk A is stronger than a second measured signal strength (e.g., -50 dBm RSRP) of trunk B, remote C may select trunk A for the trunk service associated with RSC(1).

[0240] In one example, remote C may not support relaying operations using multiple relays (e.g., multi-hop relay). For example, multi-hop relay could be relaying data from a remote UE to the network via a series of more than one UE (e.g., relay UE) and / or via multiple PC5 interfaces with one or more Uu interfaces. For example, a remote UE may support single-hop relay. For example, single-hop relay could be relaying services between a remote UE and the network using up to one intermediate UE. For example, multi-hop relay could be associated with a first path from remote C to the base station via relay A and relay B. For example, single-hop relay could be associated with a second path from remote C to the base station via relay B. For example, remote C may only support basic (e.g., single-hop) relay and may not support advanced relay (e.g., multi-hop). For example, remote C could be a traditional UE. For example, due to subscribing to basic relay services, the home network of remote C may not allow remote C to use advanced relay services (e.g., multi-hop relay). In the prior art, if a remote UE selects relay A for relaying RSC(1) services, it may fail to obtain relay services correctly, for example, due to capacity limitations and / or service protocol (e.g., subscription) limitations. In this case, the remote UE's access attempt to relay A may waste sidelink radio resources and / or may affect the services of other remote UEs accessing relay A. A similar situation may occur for relay A if multi-hop relaying is not permitted. For example, if relay A is a low-capacity UE, and / or if relay A does not subscribe to advanced services (e.g., providing multi-hop relaying), a second announcement from relay A may result in service interruptions for advanced remote UEs (e.g., remote UEs capable of using multi-hop relaying).

[0241] In example embodiments of this disclosure, signaling can be enhanced to configure relay UEs and / or remote UEs with information about when / how / allowed advanced relay operations (e.g., multi-hop relays). This can assist relay UEs in determining when to provide advanced relay services, and / or assist remote UEs in determining which relay to select based on the availability of advanced relay services. In another example, lateral link signaling can be enhanced to assist remote UEs and / or adjacent relay UEs in determining whether a relay UE supports advanced relay services. This can assist downstream relay UEs in selecting which upstream relay UE to use for advanced relay services. In another example, mapping information between a first RSC for basic relays and a second RSC for advanced relays can be provided. This can support service continuity when a remote UE navigates through relay UEs with different capabilities. In another example, auxiliary information (e.g., capability information, authorization information) can be delivered between one or more network nodes. This can assist each network node in making the correct decision regarding the use of advanced relay operations.

[0242] In this specification, the term "5G access network" may be interpreted as or may refer to an access network that includes at least one of NG-RAN and / or non-3GPP access networks (AN) and is connected to the 5G core network.

[0243] In this specification, the term "5G core network" can be interpreted as or can refer to the core network connected to the 5G access network. This can be the 5G core (5GC).

[0244] In this specification, the term "3GPP RAN" or "RAN" may be interpreted as or may refer to a radio access network using 3GPP RAT. For example, this may include at least one of gNB, eNB, ng-eNB, en-gNB, etc. and / or combinations thereof. For example, this may be at least one of E-UTRAN, NG-RAN, etc. and / or combinations thereof.

[0245] In this specification, the term "NG-RAN" may be interpreted as or may refer to a base station, which may include at least one of gNB, ng-eNB, relay node, base station central unit (e.g., gNB-CU), base station distributed unit (e.g., gNB-DU), etc. This may be a radio access network connected to at least one of 5GC, NR, E-UTRA, and / or combinations thereof.

[0246] In this specification, the term "E-UTRAN" may be interpreted as or may refer to a base station, which may include at least one of eNB, en-gNB, etc. This can be a radio access network connected to at least one of the evolved packet core (EPC), supporting NR, E-UTRA, and / or combinations thereof.

[0247] In this specification, the term "network node" may be interpreted as or may refer to at least one of a core network node, an access node, a UE, and / or a combination thereof. A network may include one or more network nodes.

[0248] In this specification, the term "core network node" may be interpreted as or may refer to core network equipment, which may include at least one of AMF, SMF, NSSF, UPF, NRF, UDM, PCF, SoR-AF, AF, DDNMF, MB-SMF, MB-UPF, MME, SGW, PGW, SMF+PGW-C, SMF+PGW-U, UDM+HSS, etc.

[0249] In this specification, the term "relay UE" (relay wireless device, wireless relay device, relay, etc.) can be interpreted as U2N relay UE and / or U2U relay UE. A relay UE can be a relay. A relay UE can be a 5G ProSe relay UE.

[0250] In this specification, the term UE-to-Network (U2N) relay UE can be interpreted as a UE that provides network relay services (e.g., UE-to-network services, such as data delivery from / to a network (e.g., application server, data network)) for remote UEs and / or downstream UEs (e.g., downstream terminal UEs, downstream relay UEs, downstream remote UEs). A U2N relay UE can be a U2N relay and / or a 5G ProSe UE-to-Network relay UE. A U2N relay UE can provide functionality supporting connections to a downstream UE network (e.g., application server, base station, UPF, data network, etc.). For example, a downstream UE-to-network connection can be a data delivery service providing data between the downstream UE and the network (e.g., base station, UPF, data network). A U2N relay UE can include at least single-hop (e.g., basic) U2N relay UEs and / or multi-hop (e.g., evolved, advanced) U2N relay UEs. A single-hop U2N relay can be directly connected to a network (e.g., direct network connection) and / or can be directly connected to a remote UE. Multi-hop U2N relays can connect to the network via one or more first UEs (e.g., another first U2N relay and / or another first U2U relay and / or an upstream relay UE) and / or connect to a remote UE via one or more second UEs (e.g., another second U2N relay and / or another second U2U relay and / or a downstream relay UE). U2N relay UEs can include at least one of edge U2N relay UEs and / or intermediate U2N relay UEs. For example, an edge U2N relay UE can connect directly to a remote UE without any intermediate UEs, and / or can connect directly to a cell (e.g., a base station, a network) without any intermediate UEs. For example, edge U2N relay UEs can include first-type edge U2N relay UEs (e.g., directly connected to a cell, a top relay UE) and / or second-type edge U2N relays (e.g., directly connected to a remote UE, a bottom relay UE). For example, intermediate U2N relay UEs can be U2N relay UEs that are not directly connected to a cell and / or not directly connected to a remote UE. An upstream relay UE can be a relay UE that is closer to the cell in the relay UE chain, and / or a downstream relay UE can be a relay UE that is closer to a remote UE (e.g., a terminal UE) in the relay UE chain. For example, an upstream UE can be a UE that is closer to the cell in the UE chain, and / or a downstream UE can be a UE that is closer to a remote UE (e.g., a terminal UE) in the UE chain.

[0251] In this specification, the term UE-to-UE (U2N) relay UE can be interpreted as a UE that provides UE-to-UE relay services (e.g., U2U services, data transfer between two UEs without traversing a network / cell / base station) to a remote UE (terminal UE). A U2U relay UE can be a U2U relay and / or a 5G ProSe UE-to-UE relay UE. For example, a U2U relay UE can provide data delivery services between a first terminal UE and a second terminal UE. A U2U relay UE can be at least a single-hop (e.g., basic) U2U relay UE and / or a multi-hop (e.g., evolved, advanced) U2U relay UE. A single-hop U2U UE relay can be directly connected to the first terminal UE and the second terminal UE. A multi-hop U2U relay UE can be connected to the first terminal UE via one or more other U2U relay UEs. For example, an edge U2U relay UE can be directly connected to the first terminal UE and / or can be connected to the second terminal UE via one or more intermediate UEs. For example, an intermediate U2U relay UE can be connected to a first terminal UE via one or more intermediate UEs and / or can be connected to a second terminal UE via one or more intermediate UEs.

[0252] In this specification, the term "sidelink" can be interpreted as a direct interface between UEs. For example, a sidelink may include a PC5 interface. For example, a direct connection between UEs may be a sidelink connection. For example, a direct sidelink connection may be a connection between UEs without any other UEs (e.g., a relay UE) in between. For example, a direct sidelink connection may be a connection between UEs with one or more other UEs in between.

[0253] In this specification, the term "remote UE" can be interpreted as a UE that can send and / or receive services to and from the network via one or more relay UEs. A remote UE can search, select, and / or establish direct sidelink connections with relay UEs (e.g., sidelink connections, PC5 connections, D2D connections). If a remote UE is outside the coverage of a cell, it can establish an indirect network connection to the cell via one or more relay UEs. If a UE connects to the network via one or more relay UEs, the UE can be interpreted as a remote UE. A remote UE and one or more relay UEs can use one or more PC5 interfaces. A remote UE can receive configuration information and / or policy information from the network for using one or more relay UEs. The remote UE can use the configuration information and / or policy information when using one or more relay UEs and / or when it intends to use one or more relay UEs. For example, a remote UE can be a 5G ProSe remote UE.

[0254] In this specification, the term UE can be interpreted as a UE connected to another UE via one or more UE-to-UE (U2U) relays. For example, a UE could be a 5G ProSe UE.

[0255] In this specification, the term Relay Service Code (RSC) can be interpreted as a code used to identify a connection (e.g., relay) service. RSCs can be used for both UE-to-network relay and UE-to-UE relay scenarios. For UE-to-UE relay scenarios, RSCs can be used to identify the connection service provided by the U2U relay and / or the authorized user to whom the U2U relay can provide services. For UE-to-network relay scenarios, RSCs can be used to identify connection services associated with PDU sessions and / or with network slicing, data networks, etc.

[0256] In this specification, the term UE-to-UE relay service (e.g., U2U relay service) can be interpreted as a data delivery service between a first UE and a second UE via one or more intermediate third UEs. For example, the first UE may send data to the second UE via one or more third UEs. In this case, one or more intermediate third UEs may provide UE-to-UE relay (or relay) service. When the second UE receives data, the second UE may consume the data (e.g., second application processing data of the second UE) and / or may forward the data (e.g., U2U relay for U2U service) to other entities (e.g., network, relay UE) in the case of U2U relay for U2N service.

[0257] In this specification, the term UE-to-network relay service (e.g., U2N relay service) can be interpreted as a data delivery service between a first UE and the network via one or more intermediate third UEs. For example, the first UE may send data to the network via one or more third UEs. In this case, a third UE among the one or more third UEs (e.g., a UE with a direct (network) connection to a cell of the network, and / or a UE with a PDU session to deliver data for the first UE) may receive data from the first UE via other UEs among the one or more intermediate third UEs, and / or the third UE may forward data to the network via a PDU session (and / or via zero or more upstream relay UEs). The data delivery service may be a UE-to-network relay (or relay) service, and / or the service provided by a PDU session may be a UE-to-network relay service.

[0258] In this specification, the term multi-hop can be interpreted as having more than one (link, hop, interface) between the first UE and the second UE (or network). For example, using Figure 17As an example, for communication between remote C and the network, the first path (the path involving remote C, relay A, relay B, and the network) can be a multi-hop path (e.g., not a single-hop), while the second path (the path involving remote C, relay B, and the network but not relay A) can be a single-hop path (i.e., not multi-hop). In other examples, for communication, if more than one relay UE (or UE) is involved, it can be interpreted as multi-hop. In other examples, for communication, if only one relay UE (or UE) is involved, it can be interpreted as single-hop (relay). Similarly, when two entities cannot communicate directly, if a relay (or UE) is used between the two entities, a single-hop relay can be applied. When two entities cannot communicate directly, if more than one relay (or UE) is used between the two entities, a multi-hop relay can be applied.

[0259] In this specification, the term direct network communication can be interpreted as a communication mode in which there is no relay UE between the UE and the network. For example, for direct network communication, the UE and the network (e.g., a base station) can use the Uu interface, and / or may not use the PC5 interface. For example, in the case of direct network connection (communication), the UE can be within the coverage of the network.

[0260] In this specification, the term indirect network communication can be interpreted as a communication mode in which one or more relay UEs exist between the UE (remote UE) and the network. For example, in indirect network communication, the UE and a first relay UE among the one or more relay UEs may use a PC5 interface and / or the network (e.g., a base station), and a second relay UE among the one or more relay UEs may use a Uu interface.

[0261] In this specification, the term RSC (Railway Service Code) can be interpreted as an indicator that a relay UE provides connectivity services to other UEs (e.g., relay UE, remote UE, terminal UE). An RSC can be configured on a relay UE, terminal UE, and / or remote UE. An RSC can indicate whether it is associated with providing Layer 2 or Layer 3 relay services. A relay UE supporting multiple RSCs can advertise RSCs using one or more discovery messages (e.g., announcement messages).

[0262] Figure 18 An example embodiment of this disclosure is depicted. In one example, the UE may indicate whether it has the capability to support multi-hop relay. In another example, the UE may receive an indication as to whether it is permitted to perform multi-hop relay operations. This can help network operators control where the UE can participate in multi-hop relay. For the sake of brevity, redundant details will be omitted based on another part of this disclosure.

[0263] In one example, relay UE A (e.g., relay radio device A, wireless relay device A, relay A) may send a first NAS message to the AMF. For example, the first NAS message may be at least one of a registration request message, a UL NAS transport message, etc. For example, the first NAS message may include a UE policy container. For example, the UE policy container may include a UE policy provisioning request. For example, the UE policy provisioning request may include a 5G ProSe policy and / or a 5G ProSe policy for multi-hop relay. For example, the first NAS message may include an indication that relay UE A has the capability to support multi-hop relay and / or that relay UE A has the capability to act as a multi-hop relay UE (e.g., multi-hop capability). For example, the first NAS message may include a first capability indicator indicating that relay UE A supports relay operation and / or a second capability indicator indicating that relay UE A supports multi-hop relay operation. For example, this can help a legacy AMF (e.g., one that does not support multi-hop relay) interpret / use the first capability indicator, and / or help an advanced AMF (e.g., one that supports multi-hop relay) interpret / use the second capability indicator.

[0264] In one example, the AMF can receive a first NAS message. In response to receiving the first NAS message, the AMF can send a request to the UDM. For example, the request to the UDM could request the UDM to send subscription data for relay UE A for multi-hop relay operation to the AMF. In response to the request to the UDM, the UDM can send a response to the AMF. For example, the response to the AMF could include subscription data for relay UE A for multi-hop relay operation. For example, the subscription data for relay UE A could include indications that relay UE A is permitted (authorized, subscribed) to multi-hop relay and / or that relay UE A has a subscription for multi-hop relay.

[0265] In one example, in response to receiving a first NAS message, in response to receiving subscription data from the UDM, and / or in response to detecting a mobility event of relay UE A, the AMF may send a first notification message to the PCF. For example, the first notification message to the PCF may include at least one of the following: subscription data indicating that relay UE A has a subscription for multi-hop relay, an indication that relay UE A moves from PLMN X (e.g., cell X, base station X) to PLMN Y (e.g., cell Y, base station Y), a UE policy provisioning request, and / or the ability of relay UE A to support multi-hop relay. For example, the first notification message may be at least one of a Namf_Communication_N1MessageNotify message, an Npcf_UEPolicyControl_Create request message, an Npcf_AMPolicyControl_Create request message, a Namf_EventNotify message, etc. For example, the first Namf message may include at least one of a UE policy container, an indication that relay UE A has the ability to support multi-hop relay, subscription data, etc.

[0266] In other examples, when a relay UE A's subscription changes (e.g., from not subscribing to a multi-hop relay to subscribing to a multi-hop relay), the UDM may send a second notification message to the PCF (and / or via the AMF). For example, the second notification message may include an indication that relay UE A has a subscription for a multi-hop relay.

[0267] In other examples, the PCF may receive a third notification message from the application server. For example, the third notification may indicate whether the UE (e.g., a remote UE, a relay UE) is allowed to use multi-hop relay services, whether the UE is allowed to act as a multi-hop relay, whether the UE preferably uses (and / or provides) multi-hop relay or single-hop relay, etc. Alternatively and / or additionally, when the AMF receives a first NAS message from relay UE A, the AMF may send a fourth notification message to the application server. For example, the application server may manage (e.g., determine, authorize, etc.) services related to multi-hop relay of relay UE A (e.g., application services, application data streams). In response to receiving the fourth notification message, the application server may send updated configuration information to the PCF via the third notification message.

[0268] In one example, the PCF can receive at least one of a first notification message, a second notification message, a third notification message, etc. Because relay UE A supports multi-hop relay capability, and / or because relay UE A is allowed to perform multi-hop relay (e.g., act as / perform as a multi-hop relay), the PCF can determine (e.g., via the AMF, via the user plane) to send first provision policy information (e.g., provision policy information, multi-hop relay policy information, etc.) to relay UE A. For example, the first provision policy information may include first multi-hop relay provision information. For example, the first multi-hop relay provision information may include (e.g., indicating) at least one of the following:

[0269] One or more RSCs. Each of the one or more RSCs can be associated with a relay service. For example, each relay service can be associated with a specific U2N service, a specific U2U service, a specific data network, a specific application, a specific user group, a specific network slice, etc. RSCs can allow the identification of specific relay services, users, user groups, data services, etc.

[0270] For each RSC, one or more multi-hop relay conditions indicate when a UE (e.g., the entity receiving multi-hop provisioning information) is permitted (authorized) to act as a multi-hop relay UE, use multi-hop relay services, etc. For example, one or more multi-hop relay conditions may include at least one of one or more network identifiers (e.g., PLMN A, PLMN B, SNPN C), one or more location areas (e.g., city D, tracking area E, geographic coordinates F), and / or one or more time periods (e.g., start time, end time, duration). For example, when one or more multi-hop conditions are met, a UE may be permitted to use multi-hop functionality as a relay UE, provide multi-hop relay services to other UEs, and / or use multi-hop relay services provided by other UEs. For example, when one or more multi-hop conditions are not met, a UE may not be permitted to use multi-hop functionality as a relay UE, and / or use multi-hop relay services.

[0271] For each RSC, one or more single-hop conditions are indicated for when the UE is allowed (authorized) to act as a single-relay UE. For example, when one or more single-hop conditions are met, the UE may be allowed to use single-hop functionality as a relay UE and / or use single-hop relay services. For example, when one or more single-hop conditions are not met, the UE may not be allowed to use single-hop functionality as a relay UE and / or may not be allowed to use single-hop relay services.

[0272] An indicator that shows whether the UE is allowed to act as a multi-hop relay UE. This indicates whether the UE is authorized to perform the role of a multi-hop relay UE.

[0273] An indicator that shows whether the UE is allowed to act as a single-hop relay UE. This indicates whether the UE is authorized to perform the role of a single-hop relay UE.

[0274] An indicator that shows whether the UE is allowed to use multi-hop relay services.

[0275] An indicator that shows whether the UE is allowed to use single-hop relay services.

[0276] An indicator that indicates whether a UE is permitted to provide relay services to other (downstream) relay UEs.

[0277] An indicator that indicates whether a UE is allowed to connect (e.g., use) an upstream relay UE as a relay UE to provide relay services to other (downstream) UEs.

[0278] An indicator that shows whether the UE is permitted to act as a multi-hop U2N relay UE. This indicates whether the UE is authorized to perform the role of a multi-hop U2N relay UE.

[0279] An indicator that specifies whether a UE is permitted to act as a multi-hop Layer 2 U2N relay UE. This indicates whether the UE is authorized to perform the role of a multi-hop Layer 2 U2N relay UE. For example, when using Layer 2 multi-hop relay, the path from the base station to the remote UE can be controlled by the base station.

[0280] An indicator that suggests whether a UE is permitted to act as a multi-hop Layer 3 U2N relay UE. This can indicate whether the UE is authorized to perform the role of a multi-hop Layer 3 U2N relay UE. For example, when using Layer 3 multi-hop relay, the path from the topmost relay UE to the remote UE may not be controlled by the base station, and / or the base station may not be aware of the remote UE.

[0281] This indicates the maximum number of hops allowed for multi-hop relay. For example, this could indicate the maximum number of hops a UE is allowed to support multi-hop relay and / or the maximum number of hops a UE is allowed to use for multi-hop relay (e.g., the number of PC5 interfaces, the number of interfaces, the number of relay UEs in the path). For example, if the maximum number of hops allowed for multi-hop relay is set to 5, the UE may not provide relay services to remote UEs that require more than 5 hops to reach the network.

[0282] For example, the first multi-hop provisioning information might indicate that RSC1B is allowed for relay UE A used for multi-hop relay operations, and RSC1A is allowed for relay UE A used for single-hop relay operations, and / or RSC1B and RSC1A are associated with the same service (e.g., PDU session, network slicing, data network). For example, if authorized, the first multi-hop provisioning information may include RSC1B and / or RSC1A. For example, if not authorized, the first multi-hop provisioning information may not include RSC1B and / or RSC1A.

[0283] In one example, the PCF can send a first policy information for relaying UE A to the AMF. In response to receiving the first policy information from the PCF, the AMF can send a second NAS message to the UE. For example, the second NAS message can be at least one of a DL NAS transmission message, a registration acceptance message, a UE configuration update message, etc. For example, the second NAS message may include the first policy information.

[0284] In one example, relay UE A can receive a second NAS message. Because the second NAS message includes first provision policy information, because the second NAS message indicates (e.g., includes) one or more RSCs permitted for multi-hop relay, and / or because the second NAS message includes first multi-hop provisioning information indicating that multi-hop relay is permitted, relay UE A can determine that relay UE A is authorized to provide multi-hop relay services to other UEs.

[0285] In one example, relay UE B can receive second policy information (not shown in the figure). For example, the second policy information can be similar to the first policy information (containing information related to relay UE B but not relay UE A). For example, relay UE B can receive the second policy information in a similar manner to how relay UE A receives the first policy information. For example, one or more network nodes (e.g., AMF, PCF, UDM, AF) can perform actions similar to those for the first policy information to construct / deliver the second policy information.

[0286] In one example, a remote UE C can receive third proposal policy information (not shown in the figure). For example, the remote UE C can receive the third proposal policy information in a similar manner to how the relay UE A receives the first proposal policy information. For example, one or more network nodes (e.g., AMF, PCF, UDM, AF) can perform actions similar to those of the first proposal policy information to construct / deliver the third proposal policy information. For example, the third proposal policy information can indicate whether the remote UE C is allowed to use the service via multi-hop relay. For example, the remote UE C can send a NAS message similar to the first NAS message. For example, such a NAS message can indicate whether the remote UE C supports multi-hop relay, e.g., whether the remote UE C has the ability to use relay services via multi-hop relay. Similarly, the AMF can receive the third proposal policy information from the PCF and / or UDM. For example, the third proposal policy information can use a format similar to that of the first proposal policy information. For example, the third proposal policy information can include (e.g., indicate) at least one of the following:

[0287] One or more RSCs. This can indicate one or more RSCs that are permitted for use by the UE (e.g., remote UE C).

[0288] For each RSC, one or more multi-hop conditions indicate when a UE is allowed (authorized) to act as a multi-hop remote UE (e.g., a UE using U2N services via multiple relay UEs). For example, one or more multi-hop relay conditions (e.g., multi-hop conditions) may include at least one of one or more network identifiers (e.g., PLMN A, PLMN B, SNPN C), one or more location areas (e.g., city D, tracking area E, geographic coordinates F), and / or one or more time periods (e.g., start time, end time, duration). For example, when one or more multi-hop conditions are met, a UE may be allowed to use multi-hop functionality as a remote UE, and / or a UE may be allowed to use one or more multi-hop relays. For example, when one or more multi-hop conditions are not met, a UE may not be allowed to use multi-hop functionality as a relay UE.

[0289] For each RSC, one or more single-hop trunking conditions indicate when a UE is allowed (authorized) to use a single-hop trunk UE. For example, when one or more single-hop trunking conditions are met, a remote UE C may be allowed to use the single-hop function to use a trunk UE. Conversely, when one or more single-hop conditions are not met, a remote UE C may not be allowed to use the single-hop function to use a trunk UE.

[0290] An indicator that suggests whether a UE is permitted to act as a multi-hop remote UE. This can indicate whether a UE is authorized to use one or more multi-hop relay UEs.

[0291] An indicator that suggests whether the UE is permitted to act as a single-hop remote UE. This can indicate whether the UE is authorized to use a single-hop relay UE.

[0292] An indicator that shows whether the UE is permitted to act as a multi-hop U2N remote UE. This can indicate whether the UE is authorized to perform the role of a multi-hop U2N remote UE, for example, using one or more U2N multi-hop relay UEs.

[0293] An indicator that suggests whether a UE is permitted to act as a multi-hop Layer 2 U2N remote UE. This can indicate whether the UE is authorized to perform the role of a multi-hop Layer 2 U2N remote UE, for example, using one or more Layer 2 multi-hop relay UEs. For example, when using Layer 2 multi-hop relay, the path from the base station to the remote UE can be controlled by the base station.

[0294] Whether the UE is allowed to act as a multi-hop Layer 3 U2N remote UE. This indicates whether the UE is authorized to perform the role of a multi-hop Layer 3 U2N remote UE, for example, using one or more Layer 3 multi-hop relay UEs. For example, when using Layer 3 multi-hop relays, the path from the top relay UE to the remote UE may not be controlled by the base station.

[0295] The maximum number of hops allowed for multi-hop relay. For example, when a UE uses multi-hop relay service, this can indicate the maximum number of hops allowed for the UE (e.g., the number of PC5 interfaces, the number of interfaces). For example, if the maximum number of hops allowed for multi-hop relay is set to 5, the UE may not use multi-hop relay service that requires more than 5 hops to reach the network.

[0296] In one example, relay UE B can be in the second coverage area of ​​a second cell (e.g., a second base station). Because a direct connection to the second cell (second network) (e.g., a direct network connection) is available, and / or because relay UE B is permitted (authorized) to use the second ProSe policy information for multi-hop relaying against other UEs (e.g., remote UEs, relay UEs), relay UE B can determine to provide multi-hop relay services (e.g., U2N relay services, such as U2U relay services). For example, relay UE B can determine to provide multi-hop relay services associated with RSC 1B. For example, relay UE B can send a sidelink message 4A. For example, sidelink message 4A can be a PC5 message 4A. Sidelink message 4A can be at least one of the following: announcement message 4A (e.g., a PC5 protocol discovery message for announcing 4A), ProSe additional parameter announcement response message 4A, ProSe PC5 discovery message 4A, ProSe direct link establishment message 4A, ProSe direct link modification message 4A, etc. Sidelink message 4A may include at least one of the following:

[0297] Source Layer 2 ID: This can indicate the source layer 2 identifier of the transmitting UE (e.g., relay UE B).

[0298] Destination Layer 2 ID: This can indicate one or more destination Layer 2 identifiers associated with one or more UEs that send sidelink messages 4A to it.

[0299] RSC: This can identify the connectivity services provided by relay UE B to one or more remote UEs and / or one or more relay UEs. It can also identify the authorized user of relay UE B. For example, this could indicate RSC 1B.

[0300] Discoverer Information: This can provide information about the discoverer user (i.e., user information ID).

[0301] Target information: This can provide information about the user who was discovered by the target (i.e., user information ID).

[0302] User Information ID List: This can provide information about one or more terminal UEs, one or more remote UEs, or one or more relay UEs.

[0303] Multi-hop support indicator: This can indicate that the sender (e.g., relay UE B) supports multi-hop relay, the sender supports connections with another relay UE (e.g., downstream relay UE, upstream relay UE) (e.g., side link connection), the sender supports (e.g., provides) multi-hop U2N relay services, etc.

[0304] The first coverage indicator indicates whether the sender is under coverage.

[0305] The second coverage indicator indicates whether the sender has a connection to the upstream relay UE in the coverage area.

[0306] In one example, relay UE A (Case 2) may move out of cell coverage. For example, relay UE A may not be able to find a cell to camp on (due to weak cell signal, or the network associated with the found cell is not permitted for relay UE A, etc.). Because a direct connection to the cell (to the network) is unavailable, because relay UE A is permitted (authorized) to perform multi-hop relay (e.g., permitted to use / connect to other relay UEs to provide connectivity services to other remote UEs), because an upstream relay UE (e.g., relay UE B) in coverage is available, because relay UE A receives a sidelink message 4A indicating support for multi-hop relay, and / or because relay UE A is authorized (received authorization) for multi-hop relay, because relay UE A is authorized for RSC 1B associated with multi-hop relay, relay UE A can determine to participate in multi-hop relay, connect to an upstream relay UE, establish a sidelink connection to another relay (e.g., relay UE B used for multi-hop relay), etc. For example, relay UE A can send a sidelink message 4B to relay UE B to establish a sidelink connection. For example, sidelink message 4B can be a PC5 message 4B. For example, sidelink message 4B can be at least one of the following: announcement message 4B, ProSe additional parameter announcement response message 4B, ProSe PC5 discovery message 4B, ProSe direct link establishment message 4B, ProSe direct link modification message 4B, sidelink connection establishment message, etc. Sidelink message 4B can include at least one of the following:

[0307] Source Layer 2 ID: This can indicate the source layer 2 identifier of the sending UE. For example, this can indicate relay UE A.

[0308] Destination Layer 2 ID: This can indicate one or more destination Layer 2 identifiers associated with one or more UEs that send sidelink messages 4B to it. For example, this can indicate relay UE B.

[0309] RSC: This can identify the connection service requested by relay UE A from relay UE B, and / or can indicate that relay UE A requests a connection with relay UE B to provide / use multi-hop relay services. For example, this can indicate RSC 1B.

[0310] Discoverer Information: This can provide information about the discoverer user (i.e., user information ID).

[0311] Target information: This can provide information about the user who was discovered by the target (i.e., user information ID).

[0312] Multi-hop support indicator: This can indicate that the sender (e.g., relay UE A) supports multi-hop relay, the sender supports connection to another relay UE, the sender supports multi-hop relay service, the sender supports acting as a downstream relay UE, the sender supports acting as an upstream relay UE, the sender is authorized for multi-hop relay, etc.

[0313] In one example, relay UE A can receive a sidelink message 4C (not shown in the figure) from relay UE B. For example, sidelink message 4C can indicate at least one of the following: a sidelink connection has been successfully established between relay UE A and relay UE B; relay UE A is permitted for multi-hop relaying; relay UE A is permitted as a downstream relay of relay UE B; multi-hop relay service associated with RSC1B is permitted for relay UE A; relay UE B provides multi-hop relay service to relay UE A, etc. In one example, relay UE B can receive information from the network indicating whether relay UE A can connect to relay UE B as a downstream relay and / or indicating whether relay UE A is permitted for multi-hop relaying. If this information indicates that relay UE A is permitted, relay UE B can send a sidelink message 4C indicating that relay UE A is permitted for multi-hop relaying.

[0314] In one example, relay UE A may send a sidelink message 5B to one or more remote UEs (e.g., remote UE C). For example, based on relay UE A establishing a sidelink connection to an upstream relay (e.g., relay UE B), based on relay UE A receiving an indication from relay UE B allowing multi-hop relaying, based on relay UE A receiving an indication regarding allowing / establishing an RSC 1B with relay UE B (configured for multi-hop operation), based on relay UE A receiving permission to act as a downstream relay, and / or based on relay UE A being outside coverage, relay UE A may determine that it can act as a downstream relay, can perform as a multi-hop relay UE, and / or relay UE A may send a sidelink message 5B. For example, the sidelink message 5B may be a PC5 message 5B. The sidelink message 5B may be at least one of the following: an announcement message, a ProSe additional parameter announcement response message, a ProSe PC5 discovery message, a ProSe direct link establishment response message, a ProSe direct link modification message, etc. Sidelink message 5B may include at least one of the following:

[0315] Source Layer 2 ID: This can indicate the source layer 2 identifier of the sending UE. For example, this can indicate relay UE A.

[0316] Destination Layer 2 ID: This can indicate the destination Layer 2 identifier associated with one or more UEs that send sidelink messages 5BB to it. For example, this can indicate one or more remote UEs (terminal UEs) and / or one or more downstream relay UEs.

[0317] RSC: This can identify the connectivity service provided by relay UE A, and / or indicate that relay UE A provides multi-hop relay from relay UE A. For example, this can indicate RSC 1B.

[0318] Discoverer Information: This can provide information about the discoverer user (i.e., user information ID).

[0319] Target information: This can provide information about the user who was discovered by the target (i.e., user information ID).

[0320] Multi-hop support indicator: This can indicate at least one of the following: the sender (e.g., relay UE A) supports multi-hop relay, the sender supports a connection to another relay UE, the sender supports multi-hop relay services (e.g., U2N relay service, U2U relay service), the sender uses multi-hop relay, the connection service associated with RSC (e.g., RSC1B) is provided via multi-hop relay, the sender is a downstream relay UE, the sender is an intermediate relay UE, the sender is connected to an upstream relay UE, etc.

[0321] In one example, relay UE A (Case 1) can move to the first coverage area of ​​the first cell (first base station, first network). Because a direct connection to the first cell (first network) is available, and / or because relay UE A is permitted (authorized) to be used for (single-hop) relaying of other remote UEs, relay UE A can determine to provide relay services (e.g., UE-to-network relay service), relay UE A can determine to act as a single-hop relay UE, and / or relay UE A can determine to act as a (topmost) edge relay UE. For example, relay UE A can determine to provide (single-hop) relay services associated with RSC 1A, and / or relay UE A can determine not to provide (multi-hop) relay services associated with RSC 1B. For example, relay UE A can send a sidelink message 5A. For example, sidelink message 5A can be PC5 message 5A. Sidelink message 5A can be at least one of the following: an announcement message, a ProSe additional parameter announcement response message, a ProSe PC5 discovery message, a ProSe direct link establishment and response message, or a ProSe direct link modification message. Sidelink message 5A can include at least one of the following:

[0322] Source Layer 2 ID: This can indicate the source layer 2 identifier of the sending UE. For example, this can indicate relay UE A.

[0323] Destination Layer 2 ID: This can indicate the target Layer 2 identifier associated with one or more UEs that send sidelink messages 5A to it.

[0324] RSC: This can identify the connectivity services provided by relay UE A to one or more remote UEs and / or one or more relay UEs. It can also identify the authorized user of relay UE A. For example, this could indicate RSC 1A. For example, this could indicate the provision of single-hop relay services.

[0325] Sender information: This can provide information about the discoverer user (i.e., user information ID).

[0326] Target information: This can provide information about the user who was discovered by the target (i.e., user information ID).

[0327] User Information ID List: This can provide information about one or more terminal UEs, one or more remote UEs, or one or more relay UEs.

[0328] Single-hop trunk indication: This can indicate whether the sender uses (or supports) multi-hop trunking, whether the sending UE is a top-edge trunk UE, whether the sending UE is an intermediate trunk UE, whether the sending UE is directly connected to the network, whether the sending UE is within coverage, and / or whether the sender uses (or supports) single-hop trunking. For example, this can indicate the use of single-hop trunking and / or the non-use of multi-hop trunking.

[0329] In one example, remote UE C can receive a sidelink message 5B (Case 2). Based on the third prose policy information, remote UE C can determine which relay UE to use and / or whether to use multi-hop relay service. For example, if the third prose policy information indicates that remote UE C is allowed to use multi-hop relay service, if the third prose policy information includes RSC1B, if relay UE A indicates support for multi-hop relay, and / or if relay UE A sends a sidelink message 5B, then remote UE A can select relay UE A and / or send a first request message to relay A (for establishing a sidelink connection). The first request message may indicate (e.g., include) RSC1B, may include an indicator indicating that remote UE C requests multi-hop relay service, and / or may indicate that remote UE C supports multi-hop relay (e.g., include an indicator indicating that remote UE C supports multi-hop relay).

[0330] In one example, remote UE C can receive a sidelink message 5A (Case 1). Based on the third proposal policy information, remote UE C can determine which relay UE to use and / or whether to use multi-hop relay service. For example, if the third proposal policy information indicates that remote UE C is not allowed to use multi-hop relay service, if the third proposal policy information does not include RSC 1B, if the third proposal policy information includes RSC 1A, if relay UE A does not indicate support for multi-hop relay, and / or if relay UE A sends a sidelink message 5A, then remote UE A can select relay UE A and can send a second request message (for establishing a sidelink connection) to relay A. The second request message may include RSC 1A, may not include an indicator requesting multi-hop relay service, and / or may indicate that remote UE C does not support multi-hop relay.

[0331] Figure 18 Examples can help UEs when to use multi-hop relay services.

[0332] Figure 19 An example embodiment of this disclosure is depicted. Similar to... Figure 18 The relay UE A can indicate support for multi-hop relay. Return to Figure 19 In one example, relay UE A may receive an indication that relay UE A is not allowed to perform multi-hop relaying. This can help the UE determine which relay to select. For the sake of brevity, redundant details will be omitted based on another part of this disclosure.

[0333] In one example, relay UE A can send the first NAS message to AMF.

[0334] In one example, the PCF can send a fourth promise policy information to the AMF for relaying UE A. Except that the fourth promise policy information may not include RSC 1B information, and / or except that the fourth promise policy information may indicate that relaying UE A is not allowed to perform multi-hop relaying, the fourth promise policy information can be similar to the first promise policy information. In response to receiving the fourth promise policy information from the PCF, the AMF can send a third NAS message to the UE. Except that the third NAS message may include the fourth promise policy information, the third NAS message can be similar to the second NAS message. For example, the fourth promise policy information may indicate RSC 1 for the relay services allowed for relaying UE A.

[0335] In one example, relay UE A may receive a third NAS message. Because the third NAS message includes fourth prose policy information, because the third NAS message does not include one or more RSCs that are permitted for multi-hop relay, because the third NAS message indicates that relay UE A is not permitted to provide multi-hop relay service for RSC 1, and / or because the third NAS message includes fourth multi-hop provisioning information that does not indicate that multi-hop relay is permitted (e.g., it does not include an indicator that allows multi-hop relay), relay UE A can determine that relay UE A is not authorized to provide multi-hop relay to other UEs.

[0336] In one example, relay UE B may be in the second coverage area of ​​a second cell. Relay UE B may receive second policy information. For example, the second policy information may include an indication that relay UE B is permitted to provide multi-hop relay service for RSC 1. For example, relay UE B may determine to provide multi-hop relay service associated with RSC 1. For example, relay UE B may send a sidelink message 4A. Sidelink message 4A may include an indication regarding relay UE B providing multi-hop relay service for RSC 1.

[0337] In one example, relay UE A (Case 2) may move out of network coverage. For example, because relay UE A cannot find a cell to camp on, because a direct connection to the cell (network) is unavailable, because relay UE A is not authorized (permitted) for multi-hop relay (e.g., not permitted to connect to other relay UEs to provide connectivity services to other remote UEs), because a relay UE in coverage (e.g., relay UE B) is available, because relay UE A receives a sidelink message 4A indicating RSC 1, because relay UE A is not authorized (received authorization) for multi-hop relay, and because relay UE A is authorized for single-hop relay for RSC 1, relay UE A can determine to establish a sidelink connection with relay UE (e.g., relay UE B) as a remote UE and / or relay UE A can determine to establish a single-hop relay connection toward relay UE. For example, relay UE A may determine not to provide relay services to other remote UEs (e.g., for RSC 1), relay UE A may use relay UE B to transmit its own services, and / or relay UE A may determine not to relay services of other remote UEs to relay UE B, etc. For example, relay UE A may send a sidelink message 4B1 to relay UE B. Sidelink message 4B1 can be similar to sidelink message 4B, except that it may not indicate that relay UE A is capable of multi-hop relaying, and except that it may not indicate that relay UE A is requesting multi-hop relay services. For example, sidelink message 4B1 may indicate RSC 1.

[0338] In one example, relay UE A can receive a sidelink message 4C1 from relay UE B. For example, sidelink message 4C1 can be similar to sidelink message 4C, but with minor differences. For instance, sidelink message 4C1 might indicate that relay UE A is not allowed to act as a relay, is not allowed to provide multi-hop relay service, is not allowed to act as a downstream relay of relay UE B, or needs to act as a remote UE, etc.

[0339] In one example, relay UE A may send a sidelink message 5B1 to one or more remote UEs (e.g., remote UE C). For example, based on relay UE A establishing a sidelink connection to a relay UE (e.g., relay UE B) acting as a remote UE, based on relay UE A not receiving an indication that multi-hop relay is allowed, based on relay UE A not being allowed to perform multi-hop relay, and / or based on relay UE A being outside coverage, relay UE A may send a sidelink message 5B1, and / or the sidelink message 5B1 may not indicate that relay UE A supports (or provides) (multi-hop) relay services (e.g., it may not include an indication that relay UE A supports (or provides) (multi-hop) relay services). Alternatively, relay UE A may not send a sidelink message 5B and / or relay UE A may not send a sidelink message 5B. For example, because relay UE A does not act as a relay UE, relay UE A may be a remote UE.

[0340] In one example, relay UE A (Case 1) can move to the first coverage area of ​​the first cell (first base station, first network). Because a direct connection to the first cell (first network) is available, and / or because relay UE A is permitted (authorized) for (single-hop) relaying of other remote UEs, relay UE A can determine to provide relay services (e.g., UE-to-network relay services). For example, relay UE A can determine to provide (single-hop) relay services associated with RSC 1. For example, relay UE A can send a sidelink message 5A1. For example, sidelink message 5A1 can be similar to sidelink message 5A. For example, based on fourth prose policy information, sidelink message 5A can include RSC 1.

[0341] Figure 20An example embodiment of this disclosure is depicted. For example, relay UE A may receive one or more announcements (e.g., announcement messages, such as discovery messages for announcements) from one or more neighboring relay UEs. Based on the information from one or more announcements, relay UE A may determine an upstream relay UE. The upstream relay UE may indicate relay UE A to the base station. This can reduce unnecessary attempts to establish lateral link connections. For the sake of brevity, redundant details will be omitted based on another part of this disclosure.

[0342] In one example, relay UE A may receive first proposal policy information and / or the first proposal policy information may indicate that relay UE A is permitted to provide multi-hop relay service for RSC 1. In one example, relay UE B may receive second proposal policy information and / or the second proposal policy information may indicate that relay UE B is permitted to provide multi-hop relay service for RSC 1. In one example, relay UE F may receive fifth proposal policy information. In one example, relay UE D may receive sixth proposal policy information. For example, the fifth proposal policy information may use a structure similar to the first proposal policy information, and / or the fifth proposal policy information may indicate that relay UE F is not permitted for multi-hop relay and / or relay UE F is permitted to provide (single-hop) relay service associated with RSC 1. For example, the sixth proposal policy information may use a structure similar to the first proposal policy information, and / or the sixth proposal policy information may indicate that relay UE D is not permitted for multi-hop relay and / or relay UE D is permitted to provide (single-hop) relay service associated with RSC 1.

[0343] In one example, relay UE F may send a sidelink message 4A2. For example, sidelink message 4A2 may have a similar structure (and / or purpose of content) to sidelink message 4A, and / or may contain information related to relay UE F. For example, based on the fifth prose policy information indicating that relay UE F is not allowed to be used for multi-hop relay, sidelink message 4A2 may not indicate the following (e.g., it may not include information indicating the following): relay UE F provides multi-hop relay service for RSC1, relay UE F provides (single-hop) relay service for RSC1 to a remote UE, and / or relay UE F may not provide relay service for RSC1 to a downstream relay UE.

[0344] In one example, relay UE B can send a sidelink message 4A3. Sidelink message 4A3 can have similar content to sidelink message 4A. For example, based on second policy information indicating that relay UE B is permitted for multi-hop relaying because the upstream relay to which relay UE B is connected supports multi-hop relaying, and / or because a direct connection to the cell is available to relay UE B, sidelink message 4A3 can instruct relay UE B to provide multi-hop relay service for RSC 1, can instruct relay UE B to support multi-hop relaying, can instruct relay UE B to provide relay service for RSC 1 for remote UEs, and / or relay UE B to provide relay service for RSC 1 for downstream relay UEs.

[0345] In one example, relay UE D can send a sidelink message 4A4. Sidelink message 4A4 can have a similar structure to sidelink message 4A. For example, based on the sixth prose policy information indicating that relay UE D is not allowed for multi-hop relay, and / or because relay UE D does not have a direct connection to the cell (e.g., outside coverage), sidelink message 4A4 may not instruct relay UE D to provide multi-hop relay service for RSC 1, etc.

[0346] In one example, relay UE A can select an upstream relay UE. For example, relay UE A may select relay UE B based on the following: relay UE A is authorized for multi-hop relay; relay UE A is outside the cell's coverage area; relay UE A is authorized for RSC 1; an upstream relay UE providing a connection to the network (cell, base station) is available; and / or relay UE B indicates that relay UE B supports multi-hop relay for RSC 1. For example, relay UE B can provide relay UE A with a connection to the cell (network, base station); and / or relay UE B can act as an upstream relay UE for relay UE A.

[0347] In one example, based on the selection of relay UE B, relay UE A can send a sidelink message 4B1. For example, sidelink message 4B1 can be similar to sidelink message 4B. For example, sidelink message 4B1 can indicate the following (e.g., including indicators / information indicating the following): relay UE A requests multi-hop relay service, relay UE A requests relay UE B to act as an upstream relay UE, relay UE A supports multi-hop relay capability, relay UE A can act as a downstream relay UE for RSC 1, request multi-hop relay service, request RSC 1, relay UE A is outside network coverage, etc.

[0348] In one example, after receiving the sidelink message 4B1, relay UE B can send an RRC message to the base station. For example, the base station may have an RRC connection with relay UE B. For example, relay UE B may be the top-edge relay UE (e.g., a relay UE with a direct connection to the base station in a chain of relay UEs associated with relay UE A). For example, the RRC message may be at least one of a UE information message, an RRC establishment request message, an RRC establishment complete message, an RRC reconfiguration message, an RRC configuration message, a UL RRC transmission message, etc. For example, the RRC message may include at least one of the following: an identifier of relay UE B, an identifier of relay UE A, an indication indicating that relay UE B supports multi-hop relay capability, an indication indicating that relay UE A supports multi-hop relay capability, an indication indicating that relay UE A is a downstream relay UE of relay UE B, an indication indicating that relay UE A is requesting multi-hop relay service, etc. For example, based on the RRC message, the base station can update the configuration of relay UE B. For example, based on an RRC message, the base station can send a response (e.g., an RRC message) to relay UE B. For example, the response to relay UE B can indicate that relay UE A is allowed to perform (connection) as a downstream relay UE, relay UE A is allowed to perform multi-hop relay operations, and / or the connection from relay UE A to relay UE B is allowed.

[0349] In one example, relay UE B can receive a response from the base station. Based on this response, because the response permits relay UE A, relay UE B can send a sidelink response (e.g., sidelink message 4C) to relay UE A. For example, the sidelink response could indicate that relay UE A is allowed to act as a downstream relay UE, relay UE A is allowed to perform multi-hop relaying, the connection between relay UE A and relay UE B is allowed, etc.

[0350] In one example, based on the sidelink response, relay UE A can send a sidelink message 5B5. For example, sidelink message 5B5 can instruct relay UE A to provide relay service for RSC 1. For example, because the sidelink response indicates that relay UE A is allowed to provide (multi-hop) relay service, relay UE A can send sidelink message 5B5 and / or sidelink message 5B5 can instruct relay service for RSC 1. For example, sidelink message 5B5 can indicate the relay type. For example, the relay type can be at least one of Layer 3 (normal, single-hop) U2N relay, Layer 3 (advanced, multi-hop) U2N relay, multi-hop relay, single-hop relay, Layer 2 (normal, single-hop) U2N relay, Layer 2 (advanced, multi-hop) U2N relay, etc. For example, the relay type can indicate to the receiver the type of relay UE A and / or the type of relay service provided.

[0351] Figure 21 An example embodiment of this disclosure is depicted. For instance, when a remote UE C moves, the available relay UEs for the remote UE C can change. Based on policy information, the remote UE C can select a relay for service continuity. This can reduce the service interruption time of the remote UE C. For the sake of brevity, redundant details will be omitted based on another part of this disclosure.

[0352] In one example, remote UE C can receive third policy information. For instance, the third policy information might indicate that RSC 1A is used for single-hop trunk service, RSC 1B is used for multi-hop trunk service, RSC 1A is mapped to RSC 1B, RSC 1B is mapped to RSC 1A, and / or RSC 1A and RSC 1B are associated with the same service (e.g., network slicing, data network, application, user group, etc.). Similar information can be delivered to trunk UE F, trunk UE A, and / or trunk UE B.

[0353] In one example, remote UE C can be outside coverage and / or can search for relay UEs. For example, based on remote UE C being outside coverage, based on remote UE C being permitted for RSC 1B, based on remote UE C being permitted to use multi-hop relay UEs, based on a sidelink message 5B received from relay UE A indicating RSC 1B, and / or based on relay UE A indicating support for multi-hop relays, remote UE C can select relay UE A. For example, based on selecting relay UE A, remote UE C can establish a sidelink connection with relay UE A and / or can use multi-hop relays via relay UE A, and / or can use RSC 1B services via relay UE A.

[0354] In one example, remote UE C can move from an area covered by relay UE A to an area covered by relay UE F. For example, relay UE F can be within the cell's coverage area. For example, relay UE F can send a sidelink message 4A5. For example, sidelink message 4A5 can indicate that relay UE F can provide relay services and / or relay UE F can support RSC 1A.

[0355] In one example, remote UE C can receive sidelink message 4A5. Because remote UE C is allowed to use the service associated with RSC 1A, and / or because the signal strength of relay UE F is superior to that of relay UE A, remote UE C can select (or switch to) relay UE F. Based on the selection of relay UE F, remote UE C can establish a sidelink connection with relay UE F for RSC 1A. For example, based on third policy information, remote UE A can determine that RSC 1B is mapped to RSC 1A, remote UE A can determine that services transmitted via RSC 1B can be delivered via RSC 1A, and / or remote UE C can switch from using RSC 1B for service to using RSC 1A for service. For example, based on the handover, remote UE C can stop using multi-hop relays of RSC 1B, and / or can start using single-hop relays of RSC 1A. For example, based on the mapping between a first RSC for single-hop relay and a second RSC for multi-hop relay, the remote UE C can determine which RSCs are compatible (e.g., can be used for the same service), which service's traffic can be delivered via the first RSC or via the second RSC, and / or whether a relay UE is available for service continuity. For example, the remote UE can receive traffic from the upper layer. Based on the traffic and / or based on third prose policy information, the UE can determine the first RSC that can be used when single-hop relay is available and / or the second RSC that can be used when multi-hop relay is available. Based on the availability of nearby relay UEs and / or one or more RSCs supported by nearby relay UEs, the remote UE can establish a connection to a first relay UE providing the first RSC or a second relay UE providing the second RSC. For example, after establishing a connection to the first relay UE for the first RSC, and if the first relay UE is unavailable and / or if the second relay UE is available, the remote UE can use the relay service of the second relay UE for the second RSC instead of the first relay UE for the first RSC. By providing mapping information between the RSC used for single-hop relays and the RSC used for multi-hop relays, service interruptions can be minimized.

[0356] Figure 22 An example embodiment of this disclosure is depicted. For instance, when relay UE A moves, relay UE A may move into and / or out of cell coverage. If a remote UE connects to relay UE A, relay UE A may perform a sidelink modification procedure to support service continuity. This can reduce service interruption time for the remote UE C. For the sake of brevity, redundant details will be omitted based on another part of this disclosure.

[0357] In one example, remote UE C can receive third policy information. For instance, the third policy information might indicate that RSC 1A is used for single-hop trunk service, RSC 1B is used for multi-hop trunk service, RSC 1A is mapped to RSC 1B, RSC 1B is mapped to RSC 1A, and / or RSC 1A and RSC 1B are associated with the same service. Similar information can be delivered to trunk UE A and / or trunk UE B.

[0358] In one example, relay UE A can connect to relay UE B. For example, relay UE A may be outside coverage and / or relay UE B may be within cell coverage. Because relay UE B supports / provides multi-hop relay and / or because relay UE A supports / provides multi-hop relay, relay UE A can establish a sidelink connection to relay UE B and / or relay UE A can provide relay services to remote UE C via relay UE B. Remote UE C can establish a sidelink connection to relay UE A for multi-hop relay services. For example, for a sidelink connection between relay UE A and remote UE C, RSC 1B can be used and / or remote UE C and relay UE A can exchange RSC 1B.

[0359] In one example, relay UE A can move into the cell's coverage area. Based on coverage availability, and / or based on relay UE A being permitted for single-hop relay in RSC 1A, relay UE A can release its connection to relay UE B (e.g., by sending a PC5 direct connection release message), relay UE A can switch from multi-hop relay mode to single-hop relay mode, relay UE A can stop acting as a downstream relay UE, relay UE A can send an indication to relay UE B indicating the availability of a direct network connection, and / or relay UE A can establish an RRC connection with the cell (base station).

[0360] In one example, based on RSC 1B being mapped to RSC 1A, relay UE A can begin providing relay services for RSC 1A, and / or can stop providing services for RSC 1B (e.g., the announcement message sent by relay UE A may not further include RSC 1B and / or may include RSC 1A). For example, based on the availability of a direct connection to the cell, relay UE A can send a sidelink (direct) connection modification message to remote UE C. For example, the sidelink connection modification message may indicate that RSC 1B is no longer used, RSC 1A is available, services via RSC 1B are mapped to RSC 1A, the associated RSC for PC5 QoS flows is changed from RSC 1B to RSC 1A, and / or RSC 1B is switched to RSC 1A.

[0361] In one example, remote UE C can receive a sidelink connection modification message from relay UE A. For example, based on the sidelink connection modification message and / or based on a handover from RSC 1B to RSC 1A, remote UE C can update the sidelink configuration and / or can begin transmitting services via the relay service associated with RSC 1A (which was previously transmitted via RSC 1B).

[0362] Figure 23 An example embodiment of this disclosure is depicted. For example, one or more relay UEs can provide services for RSC, and each of the one or more relay UEs can indicate whether it uses multi-hop relays to provide services (e.g., by sending a message including an indicator / information indicating whether it uses multi-hop relays to provide services). This can help a remote UE configure radio parameters. For brevity, redundant details will be omitted based on another part of this disclosure.

[0363] In one example, a remote UE C may receive seventh policy information. For example, the seventh policy information may indicate that RSC 1 (e.g., the service associated with RSC 1) is permitted for the remote UE C. For example, delivering the seventh policy information to the remote UE C may use a mechanism similar to that used for delivering the third policy information. For example, the seventh policy information may indicate whether the remote UE C is permitted to use multi-hop relay services provided by other relay UEs. For example, the seventh policy information may indicate that the remote UE C is permitted to use RSC 1 for multi-hop relay services (e.g., via one or more relay UEs providing multi-hop relay services).

[0364] In one example, relay UE A can connect to relay UE B. For example, relay UE A and relay UE B can provide multi-hop relay services. For example, based on the fact that relay UE A is connected to the network via another relay UE (e.g., relay UE B), based on the fact that relay UE A is allowed to use multi-hop relay functionality for RSC 1, and / or based on the fact that relay UE A is allowed for RSC 1, relay UE A can send a sidelink message 5B5. For example, sidelink message 5B5 can indicate the following (e.g., including the following, including indicators indicating the following): RSC 1, relay UE A provides multi-hop relay services, relay UE A provides relay services for RSC 1, provides multi-hop relay for RSC 1, relay UE A is connected to the network via one or more upstream relay UEs, etc.

[0365] In one example, remote UE C can be outside coverage and / or can search for relay UEs. For example, based on the fact that remote UE C is outside coverage, based on allowing remote UE C to use RSC 1, based on allowing remote UE C to use one or more multi-hop relay UEs, based on allowing remote UE C to use multi-hop relay services, based on a sidelink message 5B5 received from relay UE A indicating RSC 1, and / or based on relay UE A indicating support for multi-hop relays, remote UE C can select relay UE A. For example, based on selecting relay UE A, remote UE C can establish a sidelink connection with relay UE A, can use multi-hop relays via relay UE A, can use multi-hop relay configuration parameters, can activate multi-hop relay functionality, and / or can use the services of RSC 1 via relay UE A.

[0366] In one example, remote UE C can move from an area covered by relay UE A to an area covered by relay UE F. For example, relay UE F can be within the cell's coverage area. For example, relay UE F can send a sidelink message 4A5. For example, sidelink message 4A5 can indicate that relay UE F can provide relay services (e.g., including an indicator indicating that relay UE F can provide relay services) and / or can not indicate that relay UE F uses multi-hop relay, and / or can not indicate that relay UE F supports multi-hop relay, and / or can indicate RSC 1. For example, sidelink message 4A5 can not include an indicator indicating that relay UE F supports multi-hop relay, and / or sidelink message 4A5 can include an indicator indicating that multi-hop relay is not supported.

[0367] In one example, remote UE C can receive sidelink message 4A5. Because remote UE C is permitted for RSC 1, because remote UE C uses the service associated with RSC 1 via relay UE A, because relay UE F provides the service for RSC 1, and / or because the signal strength of relay UE F is superior to that of relay UE A, remote UE C can choose relay UE F to continue using the service for RSC 1. Based on the selection of relay UE F, remote UE C can establish a sidelink connection with relay UE F for RSC 1. For example, based on the seventh policy information indicating that RSC 1 is permitted for remote UE C, remote UE C can select or reselect relay UE F. Because sidelink message 4A5 does not indicate multi-hop relay, remote UE C can disable multi-hop relay functionality and / or can use relay UE F as a single-hop relay for RSC 1. This can reduce the time when remote UE C cannot obtain service.

[0368] Figure 24An example embodiment of this disclosure is depicted. For example, the UE can send capability information about multi-hop relay, and network nodes (e.g., a first (e.g., source) AMF, a first (e.g., source) base station) can deliver authorization information for multi-hop relay and / or capability information to other network nodes (e.g., a second (e.g., target) AMF, a second (e.g., target) base station). This can reduce signaling load and can assist another network node in determining whether to provide multi-hop relay service. For the sake of brevity, redundant details will be omitted based on another part of this disclosure.

[0369] In one example, relay UE B can establish a first RRC connection with a first base station. For example, relay UE B can send RRC message 1A to the first base station. For example, to establish the first RRC connection, RRC message 1A can be at least one of the following: uplink (RRC) transmission message, RRC establishment request, RRC recovery request, RRC connection establishment complete message, RRC recovery complete message, RRC reconfiguration complete message, UE information message, etc. For example, in response to receiving RRC message 1A, the first base station can send RRC message 1B to relay UE B to establish the first RRC connection.

[0370] In one example, relay UE B can send NAS message 1A to AMF via a first base station on a first RRC connection. For example, NAS message 1A can be at least one of a registration request message, a service request message, a UL NAS transport message, etc. For example, NAS message 1A can include second multi-hop capability information. The second multi-hop capability information can indicate the following (e.g., include one or more indicators indicating the following):

[0371] The first capability indicates whether the UE (e.g., relay UE B) supports multi-hop relay. This can also indicate whether the UE supports Layer 2 and / or Layer 3 relays as multi-hop relays.

[0372] The second capability indicates whether the UE supports multi-hop relay for other UEs. This can also indicate whether the UE supports Layer 2 and / or Layer 3 relay as a multi-hop relay for other UEs.

[0373] The third capability indicates whether the UE supports using relay services via multi-hop relays (e.g., as a remote UE). This can also indicate whether the UE supports being a Layer 2 remote UE and / or a Layer 3 remote UE as a multi-hop relay.

[0374] The fourth capability indicates whether the UE supports multi-hop relay as an upstream relay UE. This can also indicate whether the UE supports acting as a Layer 2 relay and / or Layer 3 relay.

[0375] The fifth capability indicates whether the UE supports multi-hop relay as a downstream relay UE. This can also indicate whether the UE supports Layer 2 and / or Layer 3 relays as a downstream relay UE.

[0376] The sixth capability indicates whether the UE supports multi-hop trunking as an edge trunking UE. It can also indicate whether the UE can be used as a top edge trunking UE and / or a bottom edge trunking UE. Furthermore, it can indicate whether the UE supports Layer 2 trunking and / or Layer 3 trunking as a top edge trunking UE and / or a bottom edge trunking UE.

[0377] The seventh capability indicates whether the UE supports multi-hop trunking as an intermediate trunk UE. This can also indicate whether the UE supports Layer 2 trunking and / or Layer 3 trunking as an intermediate trunk UE.

[0378] One or more capability indicators that indicate at least one of the following.

[0379] For example, the first base station may deliver NAS message 1A to the AMF via a first NG interface message (e.g., step 2A). For example, the NG interface message may be an initial UE message.

[0380] In one example, the AMF can receive NAS message 1A. The AMF can inspect the PCF and UDM. For example, the AMF can receive second multi-hop authorization information from the PCF. For instance, the second multi-hop authorization information could be similar to the second policy information (using the same...). Figure 18 (A delivery mechanism similar to the one shown in the example). For example, the AMF can receive subscription data from the relay UE B from the UDM. In other examples, the AMF can send a first Nucmf message to the UCMF (UE Radio Capability Management Function Unit). For example, the first Nucmf message can be a Nucmf_provisioning creation message, etc. For example, the first Nucmf message can include second multi-hop capability information and / or the identifier of the UE (e.g., relay UE B). For example, the UCMF can store the UE's identifier and / or the second multi-hop capability information. This can help the AMF when the relay UE B does not send the second multi-hop capability information. For example, when the NAS message 1A does not include the second multi-hop capability information, the AMF can retrieve the second multi-hop capability information from the UCMF (e.g., via sending / receiving a Nucmf_UECapabilityManagement message to / from the UCMF).

[0381] In one example, the AMF may send a second NG message to the first base station. For example, the second NG message may be at least one of an initial UE context establishment message, a UE configuration message, a DL transmission message, a path handover confirmation message, etc. For example, the second NG message (e.g., step 2B) may include at least one of second multi-hop authorization information, second multi-hop capability information, etc. For example, the second multi-hop authorization information may indicate at least one of the following (e.g., including one or more indicators indicating at least one of the following):

[0382] The first authorization information indicates whether the UE (e.g., relay UE B) is allowed to provide / use multi-hop relay services (features). This can also indicate whether the UE is allowed / authorized as a Layer 2 relay and / or Layer 3 relay.

[0383] The second authorization information indicates whether the UE is permitted to provide multi-hop relay services to other UEs (e.g., remote UE, terminal UE, downstream UE). This may also indicate whether the UE supports acting as a Layer 2 relay and / or Layer 3 relay.

[0384] The third authorization information indicates whether the UE is allowed to use relay services via multi-hop relays (e.g., as a remote UE, as a terminal UE, or as a downstream UE). This can also indicate whether the UE supports being a Layer 2 remote UE and / or a Layer 3 remote UE.

[0385] The fourth authorization information indicates whether the UE is allowed to provide multi-hop relay to downstream UEs as an upstream relay UE. This can also indicate whether the UE supports acting as a Layer 2 relay and / or Layer 3 relay.

[0386] The fifth authorization information indicates whether the UE is allowed to perform multi-hop relay as a downstream relay UE, and / or whether the UE is allowed to connect to an upstream relay UE. This may also indicate whether the UE supports acting as a Layer 2 relay and / or Layer 3 relay.

[0387] The sixth authorization information indicates whether the UE is allowed to perform multi-hop relay as an edge relay UE. It can also indicate whether the UE can be used as a top edge relay UE and / or a bottom edge relay UE. Furthermore, it can indicate whether the UE supports acting as a Layer 2 relay and / or a Layer 3 relay.

[0388] The seventh authorization information indicates whether the UE is allowed to perform multi-hop relay as an intermediate relay UE. This can also indicate whether the UE supports acting as a Layer 2 relay and / or Layer 3 relay.

[0389] In one example, a first base station may receive a second NG message. Based on the information received from the second NG message, the first base station may configure relay UE B. For example, if second multi-hop authorization information indicates that relay UE B is allowed to perform multi-hop operations, the first base station may send a third RRC message (e.g., a configuration update) to relay UE B. For example, the third RRC message may indicate at least one of the following (e.g., including information of at least one of the following): one or more sideline resources for multi-hop relay operations, an indicator indicating that relay UE B is allowed to perform multi-hop relay operations, and / or one or more information elements based on the second multi-hop authorization information (e.g., the second multi-hop authorization information). For example, if second multi-hop capability information indicates that relay UE B supports multi-hop relay operations, the first base station may send a third RRC message. For example, the third RRC message may indicate at least one of the following: one or more sideline resources for multi-hop relay operations, an indicator indicating that relay UE B is allowed to perform multi-hop relay operations, and / or one or more information elements based on the second multi-hop capability information. For example, the third RRC message may indicate whether relay UE B can act as at least one of edge multi-hop relay UE, intermediate multi-hop relay UE, multi-hop remote UE, multi-hop relay terminal UE, etc. For example, if the second NG message does not include information indicating the ability of relay UE B to support multi-hop relay operation, then the third RRC message may not include configuration information for multi-hop operation.

[0390] For example, relay UE B can receive a third RRC message. Because the third RRC message indicates that relay UE B is permitted to perform multi-hop relay operations, relay UE B can send a sidelink message 5B5. For example, sidelink message 5B5 can instruct relay UE B to provide multi-hop relay services.

[0391] In one example, a first base station may determine that it wants to hand over relay UE B from the first base station to a second base station. For example, the first base station may send a handover request message to the second base station via the Xn interface. For example, the handover request message may include at least one of the following: the identifier of the target cell of the second base station, the identifier of relay UE B (e.g., C-RNTI, Xn UE ID, etc.), second multi-hop authorization information, and / or second multi-hop capability information.

[0392] In one example, the second base station may receive a handover request. In response to receiving the handover request, and / or based on whether the second base station supports multi-hop relay, the second base station may send a handover response to the first base station. For example, the handover response may include an RRC message container. For example, the RRC message container may indicate whether relay UE B is allowed to perform multi-hop relay operation after handover to the second base station. For example, if the second base station supports multi-hop relay operation, if second multi-hop authorization information indicates that relay UE B is allowed to perform multi-hop relay, if second multi-hop capability information indicates that relay UE B supports multi-hop relay capability, and / or if the second base station allows relay UE B to use multi-hop relay operation, then the second base station may determine that relay UE B is allowed to act as a multi-hop relay. For example, based on this determination, the RRC message container may include information about multi-hop relay operation. For example, the RRC message container may be an RRC reconfiguration message.

[0393] In one example, based on a received handover response, the first base station may send an RRC message container to relay UE B. For example, if the RRC message container does not indicate that relay UE B is permitted for multi-hop operations, then after the handover (e.g., after accessing the second base station), relay UE B may stop using multi-hop operations. For example, if the RRC message container indicates that relay UE B is permitted for multi-hop operations, then after the handover (e.g., after accessing the second base station), relay UE B may begin (or continue) using multi-hop operations, for example, continuing to serve downstream UEs.

[0394] In other examples, if the first base station does not support multi-hop relay operation, it may not send the second multi-hop capability information and / or second multi-hop authorization information to the second base station. In this case, after handover, the second base station may send a request to the relay UE B to send multi-hop capability information. In response, the relay UE B may send the second multi-hop capability information to the second base station.

[0395] In one example, based on the RRC message container, relay UE B can perform a handover procedure. For instance, relay UE B can send an RRC reconfiguration complete message to indicate that relay UE B is accessing a second base station.

[0396] In one example, in response to receiving an RRC reconfiguration complete message, the second base station may send a path handover request message to the AMF. For example, the path handover request message may indicate the following (e.g., including information indicating the following): whether the second base station supports multi-hop relay operation, whether relay UE B is served by the second base station, and / or the identifier of relay UE B.

[0397] In one example, the AMF can receive a path handover request message. In response to receiving the path handover request message, the AMF can send a path handover response message. For example, the path handover response message may include at least one of second multi-hop authorization information and / or second multi-hop capability information. In other examples, each element of the second multi-hop authorization information in the path handover response message can be updated / modified compared to the second NG message. For example, based on a change in the relay UE B's subscription, a change in the relay UE B's location area, and / or support for one or more base stations for multi-hop relay operations, the AMF can determine what to update the second multi-hop authorization information (e.g., from allowed to disallowed, and vice versa). In other examples, the relay UE B may switch from a base station that does not support multi-hop operations to a second base station that supports multi-hop operations. In this case, sending a path handover response message including second multi-hop authorization information can help the second base station operate correctly.

[0398] In one example, the second base station can receive a path handover response message. Based on the path handover response message, the second base station can send an RRC message 3B. For example, the RRC message 3B can indicate whether the relay UE B is permitted for multi-hop relay operation. For example, if the RRC message 3B does not include an indicator indicating that multi-hop operation is permitted, and / or if the RRC message 3B does not include radio resource configuration for multi-hop operation, then the relay UE B may consider multi-hop operation not permitted and / or may not send an announcement message indicating that the relay UE B provides multi-hop relay service.

[0399] In one example, relay UE B can send a sidelink message 5B. For instance, if relay UE B is allowed to perform multi-hop operations, relay UE B can send a sidelink message 5B indicating support for multi-hop relay.

[0400] In one example, relay UE A (or remote UE C) can establish a sidelink connection with relay UE B. Relay UE A can send RRC message 6A to the second base station via relay UE B (and / or via one or more upstream relay UEs). For example, RRC message 6A can indicate to the second base station whether relay UE A (or remote UE C) supports multi-hop relay operation, whether relay UE A requests to perform as a multi-hop relay, and whether remote UE C requests to use multi-hop relay services, etc.

[0401] In one example, the second base station can receive RRC message 6A. For example, based on the identifier of relay UE A, the second base station can send a request to the AMF to request context information of relay UE A. For example, a similar mechanism used above for relay UE B can be used. For example, the AMF can receive NG message 5A indicating relay UE A from the second (or first) base station. For example, the AMF can send NG message 5B to the second (or first) base station, which includes first multi-hop authorization information and / or first multi-hop capability information. The first multi-hop authorization information can use a similar structure to the second multi-hop authorization information and can indicate one or more authorization information related to relay UE A. The first multi-hop capability information can use a similar structure to the second multi-hop capability information and can indicate one or more authorization information related to relay UE A. In other examples, the AMF can retrieve the second multi-hop capability information from the UCMF. This can help reduce overhead on the Uu interface.

[0402] In one example, the second (or first) base station may receive NG message 5B. Based on first multi-hop authorization information (e.g., indicating that relay A is permitted for multi-hop operation) and / or first multi-hop capability information, the second (or first) base station may determine one or more RRC parameters for relay UE A, and / or one or more RRC parameters for one or more downstream relay UEs of relay UE A, and / or one or more RRC parameters for one or more upstream relay UEs of relay UE A. Based on the determination of one or more RRC parameters, the second base station may send one or more RRC messages to relay UE A, one or more downstream relay UEs, and / or one or more upstream relay UEs.

[0403] In one example, a remote UE may send a connection request to a second base station via one or more relay UEs that support multi-hop operation. In response to receiving the connection request, the second base station may receive multi-hop authorization information and / or multi-hop capability information for the remote UE from the AMF. The methods previously described for relay UE A and / or relay UE B can be applied to the remote UE when configuring and / or determining its configuration.

[0404] For example, Figure 24 Examples can help reduce signaling load on the air interface and / or handle heterogeneous support for multi-hop relays from different entities.

[0405] Figure 25 An example embodiment of this disclosure is depicted. For example, each UE can perform multiple roles.

[0406] In one example, the first UE (e.g., U2N trunk L1) can be performed as one of the upstream trunk UEs for the second UE (e.g., U2N trunk L2) or the third UE (e.g., U2N trunk L3). The first UE can be performed as an edge U2N trunk UE, as the topmost edge U2N trunk UE, as the topmost U2N trunk UE, etc.

[0407] In one example, the second UE (e.g., U2N trunk L2) can be implemented as one of the upstream trunk UEs for the third UE (e.g., U2N trunk L3). The second UE can be implemented as one of the downstream trunk UEs for the first UE. The second UE can be implemented as one of the intermediate trunk UEs between the remote UE and the topmost edge trunk UE.

[0408] In one example, the third UE (e.g., U2N trunk L3) may not function as one of the upstream trunk UEs for other trunk UEs and / or may function as one of the upstream trunks for a remote UE. The third UE may function as one of the downstream trunk UEs for the first UE and / or for the second UE. The third UE may function as an edge U2N trunk UE, as the bottommost edge U2N trunk UE, as the bottom U2N trunk UE, etc.

[0409] In one example, a remote UE can use multi-hop U2N trunk services via one or more U2N trunks (e.g., U2N trunk L1, U2N trunk L2, U2N trunk L3).

[0410] In one example, a downstream UE may include a downstream relay UE and / or a remote UE. In one example, an upstream UE may include an upstream relay UE.

[0411] Figure 26 An example embodiment of this disclosure is depicted. For example, prose policy information may include at least one of prose policy information for relaying (e.g., used when the UE acts as a relay UE) and / or prose policy information for remote UEs (e.g., used when the UE acts as a remote UE). For example, prose policy information for relaying may include first multi-hop policy information and / or second policy information. For example, prose policy information for remote UEs may include third multi-hop policy information.

[0412] For example, a criterion (e.g., one or more conditions) may indicate that a remote UE may use multi-hop relay and / or that a relay can provide multi-hop relay services under one or more conditions. This criterion may be used by the UE to determine when it is permitted to perform multi-hop relay operations.

[0413] Figure 27An example embodiment of this disclosure is depicted.

[0414] In one example, the UE may send a first RRC message to the base station. For example, the first RRC message may include multi-hop capability information. For example, the multi-hop capability information may include at least one of access stratum multi-hop capability information (e.g., related to the RRC layer and the base station) indicating that the UE supports multi-hop relay operation and / or non-access stratum multi-hop capability information (e.g., related to the NAS layer and the core network) indicating that the UE supports multi-hop relay operation. For example, the access stratum capability information may indicate to the base station whether the UE supports multi-hop relay operation. For example, the non-access stratum capability information may indicate to one or more core network nodes whether the UE supports multi-hop relay operation.

[0415] In one example, the UE may receive a second RRC message from the base station. For example, the second RRC message may indicate the following (e.g., including indications of the following): whether the UE is allowed to perform multi-hop relay operation and / or one or more parameters for multi-hop relay operation (e.g., QoS, radio resources).

[0416] In one example, the UE can search for one or more cells or one or more networks to camp on.

[0417] In one example, the UE can determine whether a direct connection to the cell is available. For example, based on the cell being unavailable for camping and the UE being allowed to use a relay UE, the UE can search for one or more candidate relay UEs. For example, the UE can find one or more candidate relay UEs. For example, the UE can receive one or more sidelink advertisement messages from one or more candidate relay UEs. For example, based on one or more sidelink advertisement messages, the UE can determine whether there is a relay UE providing a connection to the network.

[0418] In one example, the UE can determine the availability of a relay UE providing a connection to the network based on one or more sidelink advertisement messages. The UE can determine whether the relay UE supports multi-hop relay. If the relay UE supports multi-hop relay and / or if the UE is authorized to perform multi-hop relay, the UE can select the relay UE. For example, based on the selection of the relay UE, a sidelink connection to the relay UE can be established, the UE can be instructed to support multi-hop relay, or the UE can be instructed to request multi-hop relay, etc. Alternatively, if the relay UE does not indicate support for multi-hop relay, the UE can establish a sidelink connection with the relay UE as a remote UE.

[0419] In one example, the UE can establish a sidelink connection to a relay UE used for multi-hop relay. Based on the establishment of the sidelink connection, the UE can send a second sidelink advertisement message. For example, the second sidelink advertisement message can instruct the UE to provide multi-hop relay service and / or the UE to provide U2N service.

[0420] In one example, alternatively, if the UE finds a cell to camp on and / or if the cell supports relay operation, the UE may act as the top-edge relay UE (e.g., the topmost relay UE) and / or may stop multi-hop relay operation. For example, the UE may establish a Uu connection to the cell (e.g., a base station), provide relay services to remote UEs, and / or establish lateral links with one or more downstream relay UEs. Establishing lateral links with one or more downstream relay UEs allows multi-hop relay services to be provided to one or more downstream UEs.

[0421] Figure 28 An example embodiment of this disclosure is depicted.

[0422] In one example, the base station can receive an RRC connection request message from the UE. In response to receiving the RRC connection request message, the base station can send a first NG message (e.g., an initial UE message) to the AMF. For example, the initial UE message may indicate that the base station supports multi-hop relay operation and / or the UE's identifier.

[0423] In one example, the base station can receive a second NG message from the AMF. For example, the second NG message can be at least one of an initial UE context message, a path handover confirmation message, etc. For example, the second NG message can include at least one of multi-hop authorization information and / or multi-hop capability information. For example, multi-hop authorization information can indicate whether the UE is permitted to provide multi-hop relay services and / or whether the UE is permitted to use multi-hop relay services. For example, multi-hop capability information can indicate whether the UE supports multi-hop relay functionality.

[0424] In one example, the base station can configure the UE based on the second NG message. For example, the base station can send an RRC configuration message to the UE. For example, the RRC configuration message can indicate one or more radio resources for multi-hop relay, one or more pieces of information about the relay UE involved in the multi-hop relay operation (e.g., downstream relay UE, upstream relay UE).

[0425] In one example, the base station may receive a measurement report from the UE and / or determine whether to hand over the UE to another base station. For example, the base station may send a handover request message to a second base station. For example, the handover request message may include at least one of multi-hop authorization information and / or multi-hop capability information.

[0426] In one example, an indication (e.g., a signal) can be implemented in various ways. For example, a first indication can be made via a first field in a first signaling (e.g., a message). Alternatively and / or additionally, a second indication can be made by omitting the first field in the first signaling. For example, if the first message includes the first field, a first indication can be made (e.g., implemented, delivered from the sender to the receiver). For example, if the first field in the first message is set to the value A, a third indication can be made. For example, if the first message does not include the first field, a second indication can be made. In other examples, a fourth indication can be made by sending a second signaling. Alternatively and / or additionally, a fifth indication can be made by not sending a second signaling (e.g., a message). For example, a sender can indicate something by sending a message that includes an indicator (e.g., an information element) containing indication information. For example, when a first entity indicates a first thing to a second entity, the first entity can send an indicator (e.g., an information element) indicating the first thing to the second entity, and / or can send a message including the indicator to the second entity. In other examples, when the first entity does not instruct the second entity on the second thing, the first entity may not send the second entity a first indicator (e.g., an information element) indicating the second thing, may not send the second entity a message including the first indicator, and / or may send the second entity a second indicator indicating that the second thing is not applied.

[0427] In one example, a first radio relay device (e.g., relay UE A, downstream relay UE) may send a first message to the Access and Mobility Management Function (AMF) indicating the first radio relay device's multi-hop relay capability. The first radio relay device may receive a second message from the AMF. The second message may authorize the first radio relay device to provide multi-hop relay services. The second message may indicate (e.g., include) a relay service code (RSC) for the service. The first radio relay device may receive a sidelink advertisement message from a second radio relay device (e.g., relay B, upstream relay UE). The sidelink advertisement message may include an indication of support for multi-hop relay, and / or an RSC (e.g., an RSC associated with multi-hop relay, an RSC allowed for multi-hop relay). The first radio relay device may send a sidelink connection request message to the second radio relay device requesting multi-hop relay services for the RSC.

[0428] In one example, the first wireless relay device may receive a second message from the network functional unit. The second message may authorize the first wireless relay device to perform multi-hop relaying for the service. The second message may include an indication of the Relay Service Code (RSC) for the service. The first wireless relay device may send a sidelink connection request message to the second wireless relay device requesting multi-hop relaying for the RSC.

[0429] In one example, a first wireless relay device may send a first request message to the AMF indicating multi-hop relay capability. The first wireless relay device may receive a second message from the network functional unit. The second message may authorize the first wireless relay device to perform multi-hop relay for the service. The second message may include an indication of the Relay Service Code (RSC) for the service. The first wireless relay device may send a sidelink connection request message to a second wireless relay device requesting multi-hop relay for the RSC.

[0430] In one example, a first wireless device may receive a second message from a network functional unit. The second message may authorize the first wireless relay device to perform multi-hop relaying for the service. The second message may include an indication of a Relay Service Code (RSC) for the service. The first wireless relay device may receive a sidelink advertisement message from a second wireless relay device, which includes an indication of support for multi-hop relaying and at least one of an RSC. The first wireless relay device may send a sidelink connection request message to the second wireless relay device requesting multi-hop relaying for the RSC.

[0431] In one example, the first wireless relay device may receive a second message from the network functional unit. The second message may authorize the first wireless relay device to perform multi-hop relaying for the service. The second message may include an indication of the Relay Service Code (RSC) for the service. The first wireless relay device may send a sidelink connection request message to the second wireless relay device requesting multi-hop relaying for the RSC. Multi-hop relaying may be a process of relaying user data from a remote wireless device to the network using more than one wireless relay device. For example, the more than one wireless relay device may include at least the first wireless relay device and / or the second wireless relay device.

[0432] In one example, a first wireless relay device may receive a second message from a network functional unit. The second message may authorize the first wireless relay device to perform multi-hop relaying for service. The second message may include an indication of a relay service code (RSC) for the service. The second message may include a second RSC, which is used for service when a direct connection to the cell is available and / or when single-hop relaying is used. The first wireless relay device may send a sidelink connection request message to the second wireless relay device requesting multi-hop relaying for the RSC.

[0433] In one example, a first wireless relay device may receive a second message from a network functional unit. The second message may authorize the first wireless relay device to perform multi-hop relaying for a service. The second message may include an indication of a relay service code (RSC) for the service. The second message may include a second RSC, which is used for the service when a direct connection to the cell is available to the first wireless relay device and / or when single-hop relaying is used. The first wireless relay device may send a sidelink connection request message to the second wireless relay device requesting multi-hop relaying for the RSC. A direct connection to the cell of a wireless device may be a connection from the wireless device (e.g., the first wireless relay device) to the cell without using another wireless relay device between the cell and the first wireless relay device.

[0434] In one example, the first wireless relay device may receive a second message from the network functional unit. The second message may authorize the first wireless relay device to perform multi-hop relaying for the service. The second message may include an indication of the Relay Service Code (RSC) for the service. The first wireless relay device may send a sidelink connection request message to the second wireless relay device requesting multi-hop relaying for the RSC. The first wireless relay device may also send a second sidelink advertisement message indicating multi-hop relaying to a remote wireless device.

[0435] In one example, a first wireless relay device may receive a second message from a network functional unit. The second message may authorize the first wireless relay device to perform multi-hop relaying for the service. The second message may include an indication of the Relay Service Code (RSC) for the service. The first wireless relay device may send a sidelink connection request message to a second wireless relay device requesting multi-hop relaying for the RSC. The first wireless relay device may send a second sidelink advertisement message indicating multi-hop relaying to a remote wireless device. The second sidelink advertisement message may indicate that a direct connection to the cell is not available to the second wireless relay device.

[0436] In one example, a first wireless relay device may receive a second message from a network functional unit. The second message may authorize the first wireless relay device to perform multi-hop relaying for the service. The second message may include an indication of the Relay Service Code (RSC) for the service. The first wireless relay device may send a sidelink connection request message to a second wireless relay device requesting multi-hop relaying for the RSC. The first wireless relay device may send a second sidelink advertisement message indicating multi-hop relaying to a remote wireless device. The second sidelink advertisement message may indicate (e.g., from the first wireless relay device, from the second wireless relay device, from the remote wireless device, etc.) the number of hops to the cell (e.g., number of interfaces, number of links).

[0437] In one example, a first wireless relay device may receive a second message from a network functional unit. The second message may authorize the first wireless relay device to perform multi-hop relaying for the service. The second message may include an indication of the Relay Service Code (RSC) for the service. The first wireless relay device may send a sidelink connection request message to a second wireless relay device requesting multi-hop relaying for the RSC. The first wireless relay device may send a second sidelink advertisement message indicating multi-hop relaying to a remote wireless device. The first wireless relay device may receive a second sidelink connection message from the remote wireless device, wherein the second sidelink connection message indicates whether the remote wireless device supports multi-hop relaying.

[0438] In one example, a first wireless relay device may receive a second message from a network functional unit. The second message may authorize the first wireless relay device to perform multi-hop relaying for the service. The second message may include an indication of the Relay Service Code (RSC) for the service. The first wireless relay device may send a sidelink connection request message to a second wireless relay device requesting multi-hop relaying for the RSC. The first wireless relay device may send a second sidelink advertisement message indicating multi-hop relaying to a fifth remote wireless device. The first wireless relay device may send a sidelink connection rejection message to the fifth remote wireless device based on the fifth remote wireless device not indicating support for multi-hop relaying.

[0439] In one example, a first wireless relay device may receive a second message from a network functional unit. The second message may authorize the first wireless relay device to perform multi-hop relaying for a service. The second message may include an indication of the Relay Service Code (RSC) for the service. The first wireless relay device may send a sidelink connection request message to the second wireless relay device requesting multi-hop relaying for the RSC. The second message may also include one or more conditions when the first wireless relay device is authorized to perform multi-hop relaying.

[0440] In one example, a first wireless relay device may receive a second message from a network functional unit. The second message may authorize the first wireless relay device to perform multi-hop relaying for a service. The second message may include an indication of a Relay Service Code (RSC) for the service. The first wireless relay device may send a sidelink connection request message to the second wireless relay device requesting multi-hop relaying for the RSC. The second message may also include one or more conditions when the first wireless relay device is authorized to perform multi-hop relaying. The one or more conditions may indicate at least one of one or more networks, one or more frequency bands, or one or more geographical areas.

[0441] In one example, the first wireless relay device may receive a second message from the network functional unit. The second message may authorize the first wireless relay device to perform multi-hop relaying for the service. The second message may include an indication of the relay service code (RSC) for the service. The first wireless relay device may send a sidelink connection request message to the second wireless relay device requesting multi-hop relaying for the RSC. The first wireless relay device may send a sidelink release request to the second wireless relay device based on at least one of the following: a direct connection to the cell is available, or changes (addition, removal) to one or more upstream relay wireless devices.

[0442] In one example, the first wireless relay device may receive a second message from the network functional unit. The second message may authorize the first wireless relay device to perform multi-hop relaying for the service. The second message may include an indication of the relay service code (RSC) for the service. The first wireless relay device may send a sidelink connection request message to the second wireless relay device requesting multi-hop relaying for the RSC. The first wireless relay device may send a sidelink release request to itself based on at least one of the following: a direct connection to the cell is available, or changes (addition, removal) to one or more upstream relay wireless devices. The first wireless relay device may send an indication to a remote wireless device that it does not need to use multi-hop relaying.

[0443] In one example, the first wireless relay device may receive a second message from the network functional unit. The second message may authorize the first wireless relay device to perform multi-hop relaying for the service. The second message may include an indication of the relay service code (RSC) for the service. The first wireless relay device may send a sidelink connection request message to the second wireless relay device requesting multi-hop relaying for the RSC. The first wireless relay device may send a sidelink release request to itself based on at least one of the following: a direct connection to the cell is available, or changes (addition, removal) to one or more upstream relay wireless devices. The first wireless relay device may send a configuration message to a remote wireless device indicating modifications to PC5 QoS parameters.

[0444] In one example, the first wireless relay device may receive a second message from the network functional unit. The second message may authorize the first wireless relay device to perform multi-hop relaying of the service. The second message may include an indication of the Relay Service Code (RSC) for the service. The first wireless relay device may send a sidelink connection request message to the second wireless relay device requesting multi-hop relaying of the RSC. The second message may also indicate at least one of the following: whether multi-hop relaying of the service via multiple Layer 2 relay devices is permitted, or whether multi-hop relaying of the service via multiple Layer 3 relay devices is permitted.

[0445] In one example, a first wireless relay device may receive a second message from a network functional unit. The second message may authorize the first wireless relay device to perform multi-hop relaying for a service. The second message may include an indication of a Relay Service Code (RSC) for the service. The second message may include a second RSC, which is used for the service when a direct connection to the cell is available to the first wireless relay device and / or when single-hop relaying is used. The first wireless relay device may send a sidelink connection request message to the second wireless relay device requesting multi-hop relaying for the RSC. A direct connection to the cell of a wireless device may be a connection from the wireless device (e.g., the first wireless relay device) to the cell without using another wireless relay device between the cell and the first wireless relay device. The first wireless relay device may determine that a direct connection to the cell is available if it can camp on the cell or if the cell does not indicate support for multi-hop relaying.

[0446] In one example, a first wireless relay device may send a first request message to the AMF indicating multi-hop relay capability. The first wireless relay device may receive a second message from the network functional unit. The second message may authorize the first wireless relay device to perform multi-hop relay for the service. The second message may include an indication of the relay service code (RSC) for the service. The first wireless relay device may send a sidelink connection request message to a second wireless relay device requesting multi-hop relay for the RSC. The first request message may also include at least one of the following: a first indication indicating whether multi-hop relay via multiple layer 2 relay devices is supported; a second indication indicating whether multi-hop relay via multiple layer 3 relay devices is supported; the maximum number of relay hops supported; whether top-level relay operation is supported; or whether downstream relay operation is supported.

[0447] In one example, the first base station and network functional unit can receive a context management message, which includes the identifier of the wireless device and authorization information authorizing the wireless device as a multi-hop relay for service. The first base station can send a handover request message including the identifier and authorization information to the second base station.

[0448] In one example, a network node can receive a path switching request message from a base station, which includes the identifier of the wireless device. The network node can then send a response to the path switching request message to the base station, wherein the response includes the identifier of the wireless device and authorization information authorizing the wireless device as a wireless relay device for multi-hop relays used for service.

[0449] In one example, a network node can receive a first message from a first base station, which includes an identifier for the wireless device and capability information indicating that the wireless device supports multi-hop relay. The network node can then send a second message to a second base station, including the identifier and capability information of the wireless device.

[0450] One or more embodiments of this disclosure can be applied to U2U relay services. For example, an example for providing U2N services (e.g., data services between a UE and an application server (network)) is described. By replacing U2N services with U2U services (e.g., data services between UEs without going through an application server (network)), the description and / or examples can be applied to U2U services.

Claims

1. A method comprising: The first wireless relay device receives a second message from the network function unit, the second message being: Multi-hop relay for authorized services; as well as Indicates the relay service code (RSC) for the service; as well as The first wireless relay device sends a sidelink connection request message to the second wireless relay device based on the second message. The sidelink connection request message requests a multi-hop relay for the RSC.

2. The method of claim 1, further comprising: The first wireless relay device sends a first request message indicating the capability of multi-hop relay to the network functional unit.

3. The method according to claim 1 or 2, further comprising: The first wireless relay device receives a sidelink advertisement message from the second wireless relay device, the sidelink advertisement message including an indication of support for multi-hop relay and at least one of the RSCs.

4. The method according to any one of the preceding claims, wherein, The multi-hop relay is a method of relaying user data from a remote wireless device to the network using more than one wireless relay device.

5. The method according to any one of the preceding claims, wherein, The second message also indicates a second RSC, which is used for the service when a direct connection to the cell is available.

6. The method according to any one of the preceding claims, wherein, The direct connection to the cell is a connection from the first wireless relay device to the cell, without using another wireless relay device between the cell and the first wireless relay device.

7. The method of any of the preceding claims, further comprising: The first wireless relay device sends a second side link advertisement message indicating multi-hop relay to the remote wireless device.

8. The method of claim 7, wherein, The second side link advertisement message also indicates that the direct connection to the cell is unavailable.

9. The method of claim 7, wherein, The second side link advertisement message also indicates the hop count to the cell.

10. The method of claim 7 or 8 or 9, further comprising: The first wireless relay device receives a second side link connection message from the remote wireless device, wherein the second side link connection message indicates whether the remote wireless device supports multi-hop relay.

11. The method of claims 7-10, further comprising: The first wireless relay device sends a sidelink connection rejection message to the remote wireless device based on the fact that the remote wireless device does not indicate support for multi-hop relay.

12. The method of any of the preceding claims, wherein, The second message also includes one or more conditions when the first wireless relay device is authorized to perform multi-hop relay.

13. The method according to any one of the preceding claims further comprises: The first wireless relay device can be used to send a side link release request based on the direct connection to the cell.

14. The method of claim 13, further comprising: The first wireless relay device sends an instruction to the remote wireless device regarding not using multi-hop relay.

15. The method of claim 14, further comprising: The first wireless relay device sends a configuration message indicating the modification of PC5 QoS parameters to the remote wireless device.

16. The method of any of the preceding claims, wherein, The second message also indicates at least one of the following: whether multi-hop relay of the service via multiple radio layer 2 relay devices is allowed, or whether multi-hop relay of the service via multiple radio layer 3 relay devices is allowed.

17. The method of any of the preceding claims, wherein, The one or more conditions indicate at least one of the following: one or more networks, one or more frequency bands, or one or more geographical regions.

18. The method of claim 2, wherein, The first request message further includes at least one of the following: a first indication indicating whether multi-hop relaying via the plurality of radio layer 2 relay devices is supported; a second indication indicating whether multi-hop relaying via the plurality of radio layer 3 relay devices is supported; the maximum number of relay hops supported; whether top-level relay operation is supported; or whether downstream relay operation is supported.

19. The method of any of the preceding claims, wherein, The direct connection to the cell is available if the first wireless relay device is able to camp on the cell or if the cell indicates support for multi-hop relay.

20. A method comprising: The wireless device receives one or more policy configurations, including a first policy configuration and a second policy configuration, wherein... The first policy configuration associated with multi-hop relay indicates a first parameter, wherein, in multi-hop relay, the intermediate relay is connected to the network relay; The second policy configuration instruction second parameter is not associated with multi-hop relay; and And the one or more policy configurations are associated with the first relay service; The establishment of a sidelink connection for the first relay service is triggered by the wireless device; and The wireless device sends a connection request message, which includes: In response to selecting the first relay device of the multi-hop relay, the first parameter; and In response to selecting not to indicate the second relay device of the multi-hop relay, the second parameter.

21. A method comprising: The network relay receives a radio resource control (RRC) message from the base station indicating one or more parameters for configuring relay operation; The network relay receives sidelink messages associated with multi-hop relays from the wireless device, wherein, in multi-hop relays, intermediate relays are connected to the network relay; and The network relay sends a second RRC message to the base station indicating the type of the wireless device, wherein the type of the wireless device indicates the relay type.

22. A method comprising: The first relay receives one or more policy configurations including a first policy configuration for multi-hop relay, wherein, in multi-hop relay, intermediate relays are connected to network relays; The first relay device sends a first message to the wireless device to establish a first side link connection; The first relay receives a second message from the second relay, the second message establishing a second side link connection for multi-hop relay; and Based on receiving the second side link message, the first relay device sends a third message to the wireless device indicating the modification of the first side link.

23. The method of claim 22, wherein, The modification indicates the multi-hop relay.

24. A method comprising: The wireless device receives a policy configuration indicating one or more parameters for multi-hop relay, wherein, in multi-hop relay, an intermediate relay is connected to a network relay. The wireless device receives one or more announcement messages from one or more relays, wherein: The first relay of the one or more relays sends a first announcement message of the one or more announcement messages, the first announcement message indicating a multi-hop relay for the service; and The second relay of the one or more relays sends a second notification message of the one or more notification messages, the second notification message not indicating a multi-hop relay for the service; and The wireless device sends a sidelink connection request for the multi-hop relay to the first relay based on the policy configuration and the first announcement message.

25. A method comprising: A first message is sent by a wireless device, the first message including one or more parameters for indicating the multi-hop capability of the wireless device, wherein the one or more parameters include at least one of the following: A first capability, the first capability indicating whether the wireless device supports one or more first functions of a remote wireless device with multi-hop relay; The second capability indicates whether the wireless device supports one or more second functions of an intermediate relay device in multi-hop relay; and The third capability indicates whether the wireless device supports one or more third functions of a multi-hop relay network relay device; and The wireless device receives a second message, the second message authorizing at least one of the following: First authorization for the remote wireless device with multi-hop relay; A second authorization for the intermediate relay device for multi-hop relays; and Third authorization for the network relay device with multi-hop relay.

26. A method comprising: The first base station receives a context management message from the network functional unit, the context management message including: Identifiers for wireless devices; and Authorization information, which authorizes the wireless device as a wireless relay device for multi-hop relay services; and The first base station sends a handover request message, including the identifier and the authorization information, to the second base station.

27. The method of claim 26, wherein, The context management message also includes one or more capability parameters indicating that the wireless device supports the multi-hop relay service.

28. The method of claim 27, wherein, The one or more capability parameters include at least one of the following: First license for remote wireless devices with multi-hop relays; Secondary authorization for intermediate relay equipment in multi-hop relays; and Third-party licenses for network relay devices with multi-hop relays.

29. The method of claim 26 or 27 or 28, wherein, The authorization information includes at least one of the following: First authorization for the remote wireless device with multi-hop relay; A second authorization for the intermediate relay device for multi-hop relays; and Third authorization for the network relay device with multi-hop relay.

30. The method of any one of claims 26-29, wherein, Based on the authorization information indicated by the context management message or based on the capability indication, the first base station determines whether to send one or more radio parameters for configuring the multi-hop relay to the wireless device.

31. A method comprising: A radio resource control (RRC) message is received from a radio device via a first relay by a first base station, the RRC message requesting the establishment of an RRC connection, wherein the RRC message indicates at least one of the following: Information indicating the wireless device's ability to support multi-hop relay; Indicates the request information of the wireless device; The first base station receives a context management message from the network functional unit. The context management message includes authorization information, which authorizes the wireless device to act as a wireless relay device for the multi-hop relay. The first base station sends one or more radio parameters configuring the multi-hop relay to the wireless device via the first relay based on the context management message.

32. A method comprising: The network node receives a path switching request message from the base station, which includes the identifier of the wireless device. as well as The network functional unit sends a response to the path handover request message to the base station, wherein the response includes: Identifiers for wireless devices; and The authorization information authorizes the wireless device to act as a wireless relay device for multi-hop relay services.

33. A method comprising: The first node managing mobility receives a first message from the wireless device, the first message including: The identifier associated with the wireless device; and Information indicating the wireless device's ability to support multi-hop relay; and The first node sends a second message to the second node with management capabilities, the second message including: The identifier; and The capability information.

34. A method comprising: The first base station receives a handover request for the wireless device from the second base station, wherein the handover request message includes: The identifier associated with the wireless device; and Information indicating the wireless device's ability to support multi-hop relay; and The first base station sends a path handover request message to the access and mobility management node; and The first base station receives a path handover request confirmation message from the access and mobility management node, the path handover request confirmation message including: Authorization information indicating whether the UE is allowed to perform multi-hop relay.

35. A method comprising: A wireless device sends one or more registration messages indicating one or more capability parameters, wherein the one or more capability parameters indicate that the wireless device supports one or more roles for multi-hop relay; A wireless device receives one or more configuration messages including one or more policy configuration parameters, wherein the one or more policy configuration parameters include at least one of the following: One or more relay service codes for the service; and One or more conditions are used when the wireless device is allowed to perform the multi-hop relay for the service, wherein the one or more conditions include one or more identifiers indicating one or more networks.

36. A method comprising: The first wireless relay device sends a first message to the Access and Mobility Management Function (AMF) unit, the first message indicating the multi-hop relay capability of the first wireless relay device; The first wireless relay device receives a second message from the AMF, the second message being: Multi-hop relay for authorized services; as well as Indicates the Relay Service Code (RSC) for the service. The first wireless relay device receives a side link notification message from the second wireless relay device, the side link notification message including: Indicators supporting multi-hop relays; and The RSC; and The first wireless relay device sends a request message to the second wireless relay device based on the second message, requesting a side link connection for the multi-hop relay of the RSC.

37. An apparatus for use as a first wireless relay device, comprising: The receiver is configured to receive a second message from the network functional unit: The controller is configured to determine whether to authorize a multi-hop relay for service. The controller is adapted to indicate the relay service code (RSC) for the service; and A transmitter configured to send a sidelink connection request message for the multi-hop relay of the RSC to a second wireless relay device based on the second message.

38. A computer program product comprising instructions for performing the steps of the method according to claims 1-34.