User Equipment and Network Relay for Emergency Services

Abstract

This application relates to improving the coverage and reliability of cellular emergency services. In one example, a relay UE is authorized by a core network to provide U2N relay for emergency services, and this authorization is based on UE capability information sent to the core network indicating support for U2N relay emergency function. During U2N relay discovery, the relay UE indicates to a remote UE that this capability can be provided. Thus, the remote UE selects a relay UE from a candidate set of relay UEs, and relay communication is established.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Provisional Application No. 63 / 310,015, entitled “User Equipment-To-Network Relay for Emergency Services,” filed February 14, 2022, the entire contents of which are incorporated herein by reference for all purposes.

[0002] This application relates to the field of wireless technologies, and in particular to user equipment and network relay for emergency services. [Background technology]

[0003] Cellular communications may be defined in various standards to enable communications between user equipment and cellular networks. For example, the fifth generation mobile network (5G) is a wireless standard that aims to improve data transmission speeds, reliability, availability, and the like. [Brief description of the drawings]

[0004] [Figure 1] 1 illustrates an example 5G network architecture incorporating both 3GPP (e.g., cellular) and non-3GPP (e.g., non-cellular) access to a 5G core network, according to some embodiments.

[0005] [Diagram 2] 1 illustrates an example 5G network architecture incorporating both dual 3GPP (e.g., LTE and 5G NR) access and non-3GPP access to a 5G core network, according to some embodiments.

[0006] [Diagram 3] 1 illustrates an example of a baseband processor architecture for a UE, according to some embodiments.

[0007] [Figure 4] 1 illustrates an example signaling and communication sequence diagram for emergency communication via user equipment (UE)-to-network relay, according to some embodiments.

[0008] [Diagram 5] 1 illustrates an example sequence diagram for emergency services over Layer 3 UE-to-network relay, according to some embodiments.

[0009] [Figure 6] 1 illustrates an example sequence diagram for emergency services via Layer 2 UE-to-network relay, according to some embodiments.

[0010] [Figure 7] 1 illustrates an example sequence diagram for UE-to-network relay discovery using Model A, according to some embodiments.

[0011] [Figure 8] 1 illustrates an example sequence diagram for UE-to-network relay discovery using Model B, according to some embodiments.

[0012] [Figure 9] 1 illustrates another example of a sequence diagram for UE-to-network relay discovery using Model A, according to some embodiments.

[0013] [Figure 10] 13 illustrates another example of a sequence diagram for UE-to-network relay discovery using Model B, according to some embodiments.

[0014] [Figure 11] 1 illustrates an example of an operational flow / algorithm structure for a relay UE to participate in relay communication, according to some embodiments.

[0015] [Figure 12] 1 illustrates an example of an operational flow / algorithm structure for a remote UE to participate in relayed communication, according to some embodiments.

[0016] [Figure 13] 1 illustrates an example of an operational flow / algorithm structure for a core network to participate in relay communication, according to some embodiments.

[0017] [Figure 14] 1 illustrates an example of a receiving component according to some embodiments.

[0018] [Figure 15] 1 illustrates an example of a UE in accordance with some embodiments.

[0019] [Figure 16] 1 illustrates an example of a base station in accordance with some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0020] The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular structures, architectures, interfaces, techniques, etc., to provide a thorough understanding of various aspects of the various embodiments. However, it will be apparent to one of ordinary skill in the art having the benefit of this disclosure that various aspects of the various embodiments may be implemented in other examples that depart from these specific details. In some cases, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail. For purposes of this disclosure, "A or B" means (A), (B), or (A and B).

[0021] In general, relaying architectures can be implemented to improve coverage and reliability by using architectures such as multi-hop. User Equipment (UE)-to-Network Relaying (also abbreviated U2N Relaying) is an exemplary implementation of relaying architectures. In U2N Relaying architecture, a first UE within the cellular coverage range is configured to relay uplink traffic of a second UE outside the cellular coverage range to the network. The first UE is also configured to relay downlink traffic from the network to the second UE. The first UE and the second UE are referred to as relay UE and remote UE, respectively. In this way, even though the remote UE is outside the cellular coverage, the access of the remote network to the network remains possible via the relay UE, thereby extending coverage and reliability.

[0022] For emergency services, the relay UE may indicate to the network (e.g., 5G core network) the capability to support U2N relay for emergency services. The network may then send authentication information to the relay UE indicating that U2N relay for emergency services may be provided. Based on the authentication information, during U2N relay discovery, the relay UE may indicate support for U2N relay for emergency services to the remote UE. The remote UE may select a relay UE from the candidate relay UEs based on the relay UE's support of U2N relay for emergency services, among other factors. Following the selection, the remote UE, the relay UE, and the network may participate in establishing a relay communication, including a direct connection between the remote UE and the relay UE. Such a connection is given high priority so that emergency traffic can be transmitted to and from the remote UE via the associated relay communication. These and other U2N relay capabilities for emergency services are further described herein below.

[0023] Embodiments of the present disclosure are described in the context of 5G networks, but the embodiments are not so limited and apply to other types of communication networks as well, including cellular networks.

[0024] Below is a glossary of terms that may be used in this disclosure.

[0025] As used herein, the term "circuitry" refers to, is a part of, or includes a hardware component configured to provide a described function, such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) or a memory (shared, dedicated, or group), an application specific integrated circuit (ASIC), a field programmable device (FPD) (e.g., a field programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high-capacity PLD (HCPLD), a structured ASIC, or a programmable system on a chip (SoC)), a digital signal processor (DSP), etc. In some embodiments, a circuitry can execute one or more software or firmware programs to provide at least some of the described functions. The term "circuitry" can also refer to the combination of one or more hardware elements (or combinations of circuits used in an electrical or electronic system) and program code used to perform the functions of the program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuit configuration.

[0026] As used herein, the term "processor circuitry" refers to, is a part of, or includes circuitry capable of sequentially and automatically performing a series of arithmetic or logical operations or the recording, storage, or transfer of digital data. The term "processor circuitry" may refer to an application processor, a baseband processor, a Central Processing Unit (CPU), a graphics processing unit, a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, or any other device capable of executing or running computer-executable instructions, such as program code, software modules, or functional processes.

[0027] As used herein, the term "interface circuitry" refers to, is a part of, or includes circuitry that enables the exchange of information between two or more components or devices. The term "interface circuitry" may refer to one or more hardware interfaces, such as, for example, a bus, an I / O interface, a peripheral component interface, a network interface card, etc.

[0028] As used herein, the term "user equipment" or "UE" refers to a device having wireless communication capabilities and may represent a remote user of network resources in a communication network. The term "user equipment" or "UE" may be considered synonymous with and may be referred to as client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, wireless equipment, reconfigurable wireless equipment, reconfigurable mobile device, etc. Additionally, the term "user equipment" or "UE" may include any type of wireless / wired device or any computing device that includes a wireless communication interface.

[0029] As used herein, the term "base station" refers to a device having wireless communication capabilities that is a network component of a communication network (or, more simply, a network) and may be configured as an access node in the communication network. UE access to the communication network may be managed at least in part by a base station, whereby a UE connects to the base station to access the communication network. Depending on the Radio Access Technology (RAT), a base station may be referred to as a gNodeB (gNB), eNodeB (eNB), access point, etc.

[0030] As used herein, the term "computer system" refers to any type of interconnected electronic device, computing device, or components thereof. In addition, the term "computer system" or "system" may refer to various components of a computer that are communicatively coupled to each other. Furthermore, the term "computer system" or "system" may refer to multiple computing devices or multiple computing systems that are communicatively coupled to each other and configured to share computing or networking resources.

[0031] As used herein, the term "resource" refers to a physical or virtual device, a physical or virtual component in a computing environment, or a physical or virtual component in a particular device, such as a computer device, a mechanical device, memory space, processor / CPU time, processor / CPU usage, processor and accelerator load, hardware time or usage, power, input / output operations, ports or network sockets, channel / link allocation, throughput, memory usage, storage, network, database and application, workload units, etc. A "hardware resource" may refer to a computational, storage, or network resource provided by a physical hardware element(s). A "virtualized resource" may refer to a computational, storage, or network resource provided by a virtualization infrastructure to an application, device, system, etc. The term "network resource" or "communication resource" may refer to a resource accessible by a computer device / system via a communication network. The term "system resource" may refer to any kind of shared entity for providing services and may include a computing resource or a network resource. A system resource may be thought of as a set of coherent functions, network data objects or services that reside on a single host or on multiple hosts and are accessible through a clearly identifiable server.

[0032] As used herein, the term "channel" refers to any tangible or intangible transmission medium used to communicate data or data streams. The term "channel" may be synonymous or equivalent to "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," or any other similar term indicating a path or medium over which data is communicated. Additionally, as used herein, the term "link" refers to a connection between two devices for the purpose of transmitting and receiving information.

[0033] As used herein, the terms "instantiate," "instantiation," and the like refer to the creation of an instance. An "instance" also refers to a concrete occurrence of an object, such as may occur during the execution of program code.

[0034] The term "connected" may mean that two or more elements at a common communications protocol layer have an established signaling relationship with each other via a communications channel, link, interface, or reference point.

[0035] As used herein, the term "network element" refers to a physical or virtualized device or infrastructure used to provide wired or wireless communications network services. The term "network element" may be considered or referred to as synonymous with networked computer, networking hardware, network equipment, network node, virtualized network function, and the like.

[0036] The term "information element" refers to a structural element that contains one or more fields. The term "field" refers to an information element or an individual content of a data element that contains the content. An information element may contain one or more further information elements.

[0037] The term "3GPP access" refers to an access (e.g., a radio access technology) specified by a 3GPP standard. These accesses include, but are not limited to, GSM / GPRS, LTE, LTE-A, and / or 5G NR. In general, 3GPP access refers to various types of cellular access technologies.

[0038] The term "non-3GPP access" refers to any access (e.g., radio access technology) that is not defined by a 3GPP standard. These accesses include, but are not limited to, WiMAX, CDMA2000, Wi-Fi, WLAN, and / or fixed networks. Non-3GPP accesses can be divided into two categories: "trusted" and "untrusted." Trusted non-3GPP accesses can directly interact with the Evolved Packet Core (EPC) and / or 5G Core (5GC), whereas untrusted non-3GPP accesses interact with the EPC / 5GC via network entities such as an Evolved Packet Data Gateway and / or a 5G NR Gateway. In general, non-3GPP accesses refer to various types of non-cellular access technologies.

[0039] FIG. 1 illustrates an example of a 5G network architecture incorporating both 3GPP (e.g., cellular) and non-3GPP (e.g., non-cellular) access to a 5G core network (CN), according to some embodiments. As illustrated, a UE 106 can access the 5G CN through both a radio access network (RAN, e.g., base station 104, which may be a gNB) and an access point (AP) 112. The AP 112 may include a connection to the Internet 100 as well as a connection to a non-3GPP interworking function (N3IWF) 103 network entity. The N3IWF may include a connection to a core access and mobility management function (AMF) 105 of the 5G CN. The AMF 105 may include an instance of a 5G mobility management (5G MM) function associated with the UE 106. In addition, the RAN (e.g., base station 104) may also have a connection to the AMF 105. Thus, the 5G CN may also support unified authentication for both connections and enable simultaneous registration of the UE 106 access via both the gNB 104 and the AP 112. As shown, the AMF 105 may include one or more functional entities associated with the 5G CN (e.g., a network slice selection function (NSSF) 120, a short message service function (SMSF) 122, an application function (AF) 124, a unified data management (UDM) 126, a policy control function (PCF) 128, and / or an authentication server function (AUSF) 130). It should be noted that these functional entities may also be supported by the session management functions (SMFs) 106a and 106b of the 5G CN.The AMF 105 may be connected to (or may communicate with) the SMF 106a. Additionally, the base station 104 may communicate with (or may be connected to) a User Plane Function (UPF) 108a, which may also communicate with the SMF 106a. Similarly, the N3IWF 103 may communicate with a UPF 108b, which may also communicate with the SMF 106b. Any UPF may be in communication with a data network (e.g., DNs 110a and 110b) and / or the Internet 100 and an Internet Protocol (IP) Multimedia Subsystem / IP Multimedia Core Network Subsystem (IMS) core network 110.

[0040] In general, a base station 104 communicates with one or more UEs (including, for example, a UE 106) via a transmission medium. Each of the user devices may be referred to herein as "user equipment" (UE). A base station (BS) 104 may be a base transceiver station (BTS) or a cell site ("cellular base station") and may include hardware that enables wireless communication with a UE 106.

[0041] The communication area (or coverage area) of the base station 104 may also be referred to as a "cell." The base station 104 and the UE 106 may be configured to communicate over a transmission medium using any of a variety of radio access technologies (RATs), also referred to as wireless communication technologies or telecommunication standards, such as GSM, UMTS (e.g., associated with a WCDMA or TD-SCDMA air interface), LTE, LTE-Advanced (LTE-A), 5G New Radio (5G NR), HSPA, 3GPP2 CDMA2000 (e.g., 1xRTT, 1xEV-DO, HRPD, eHRPD). When the base station 104 is implemented in the context of LTE, it may alternatively be referred to as an "eNodeB" or "eNB." When the base station 104 is implemented in the context of 5G NR, it may alternatively be referred to as a "gNodeB" or "gNB."

[0042] The base station 104 may also be equipped to communicate with a network (e.g., a cellular service provider's core network such as a 5G CN, a telecommunications network such as a public switched telephone network (PSTN), and / or the Internet, among other possibilities). The base station 104 may thus facilitate communications between user devices and / or between the UE 106 and the network. In particular, the cellular base station 104 may provide various telecommunications capabilities to the UE 106, such as voice, SMS, and / or data services.

[0043] Thus, the base station 104 and other similar base stations operating according to the same or different cellular communication standards may be provided as a network of cells that can provide continuous, or near-continuous, overlapping service to UEs 106 and similar devices over a geographic area via one or more cellular communication standards.

[0044] 1, the base station 104 may function as a "serving cell" with respect to the UE 106, which may also receive signals from one or more other cells (possibly within its communication range), which may be referred to as "neighboring cells." Such cells may also facilitate communication between user devices and / or between the user devices and the network 100. Such cells may include "macro" cells, "micro" cells, "pico" cells, and / or cells providing any of various other granularities of coverage area size.

[0045] In some embodiments, the base station 104 may be a next generation base station, such as a 5G New Radio (5G NR) base station, or "gNB." In some embodiments, the gNB may be connected to a legacy Evolved Packet Core (EPC) network and / or an NR Core (NRC) network. In addition, a gNB cell may include one or more Transition and Reception Points (TRPs). In addition, a UE capable of operating according to 5G NR may be connected to one or more TRPs in one or more gNBs.

[0046] The UE 106 may be capable of communicating using multiple wireless communication standards. For example, the UE 106 may be configured to communicate using at least one cellular communication protocol (e.g., GSM, UMTS (e.g., associated with a WCDMA or TD-SCDMA air interface), LTE, LTE-A, 5G NR, HSPA, 3GPP2 CDMA2000 (e.g., 1xRTT, 1xEV-DO, HRPD, eHRPD), etc.), in addition to wireless networking (e.g., Wi-Fi) and / or peer-to-peer wireless communication protocols (e.g., Bluetooth, Wi-Fi peer-to-peer, etc.). The UE 106 may additionally or alternatively be configured to communicate using one or more Global Navigational Satellite Systems (GNSS, e.g., GPS or GLONASS), one or more mobile television broadcast standards (e.g., ATSC-M / H or DVB-H), and / or any other wireless communication protocols, if desired. Other combinations of wireless communication standards (including three or more wireless communication standards) are also possible.

[0047] FIG. 2 illustrates an example of a 5G network architecture incorporating both dual 3GPP (e.g., LTE and 5G NR) and non-3GPP access to the 5G CN, according to some embodiments. As illustrated, the UE 206 can access the 5G CN via both the RAN (e.g., base station 204, such as a gNB) and the AP 212. The AP 212 can include a connection to the Internet 200 as well as a connection to the N3IWF 203 network entity. The N3IWF 203 can include a connection to the AMF 205 of the 5G CN. The AMF 205 can include an instance of a 5G MM function associated with the UE 206. In addition, the RAN (e.g., base station 204) may also have a connection to the AMF 205. Thus, the 5G CN can support unified authentication for both connections and can enable simultaneous registration of the UE 206 access via both the base station 204 and the AP 212. In addition, the 5G CN may support dual registration of UEs in both a legacy network (e.g., LTE via a base station 202 such as an eNB) and a 5G network (e.g., via a base station 204). As shown, the base station 202 may have a connection to a mobility management entity (MME) 242 and a serving gateway (SGW) 244. The MME 242 may have a connection to both the SGW 244 and the AMF 205. In addition, the SGW 244 may have a connection to both the SMF 206a and the UPF 208a. As shown, the AMF 205 may include one or more functional entities associated with the 5G CN (e.g., the NSSF 220, the SMSF 222, the AF 224, the UDM 226, the PCF 228, and / or the AUSF 230). The UDM 226 may also include a home subscriber server (HSS) function, and the PCF 228 may also include a policy and charging rules function (PCRF). These functional entities may also be supported by the SMF 606a and SMF 206b of the 5G CN. The AMF 206 may be connected to (or may communicate with) the SMF 206a. Furthermore, the base station 204 may communicate with (or may be connected to) the UPF 208a, which may also communicate with the SMF 206a.Similarly, the N3IWF 203 may communicate with a UPF 208b, which may also communicate with an SMF 206b. Both UPFs may communicate with a data network (e.g., DNs 210a and 210b) and / or the Internet 200 and the IMS core network 210.

[0048] In various embodiments, one or more of the network entities described above may be configured to perform methods for improving security checks in 5G NR networks, including mechanisms for emergency communications (e.g., voice calls and / or SMS messages) for UEs without cellular coverage (e.g., in non-cellular coverage), e.g., as described further herein.

[0049] FIG. 3 illustrates an example of a baseband processor architecture of a UE 300 (e.g., UE 106 and UE 206, etc.) according to some embodiments. The baseband processor architecture 300 described in FIG. 3 may be implemented on one or more radios or modems. As illustrated, a non-access stratum (NAS) 310 may include a 5G NAS 320 and a legacy NAS 350. The legacy NAS 350 may include a communication connection with a legacy access stratum (AS) 370. The 5G NAS 320 may include a communication connection with both a 5G AS 340 and a non-3GPP AS 330 and a Wi-Fi AS 332. The 5G NAS 320 may include functional entities associated with both access stratums. Thus, the 5G NAS 320 may include multiple 5G MM entities 326 and 328, as well as 5G session management (SM) entities 322 and 324. The legacy NAS 350 may include functional entities such as a short message service (SMS) entity 352, an evolved packet system (EPS) session management (ESM) entity 354, a session management (SM) entity 356, an EPS mobility management (EMM) entity 358, and a mobility management (MM) / GPRS mobility management (GMM) entity 360. Additionally, the legacy AS 370 may include functional entities such as an LTE AS 372, a UMTS AS 374, and / or a GSM / GPRS AS 376.

[0050] Thus, the baseband processor architecture 300 enables a common 5G-NAS for both 5G cellular and non-cellular (e.g., non-3GPP access). As shown, the 5G MM may maintain separate connection management and registration management state machines for each connection. In addition, a device (e.g., UE 106) may register to a single public land mobile network (PLMN) using 5G cellular access as well as non-cellular access. Furthermore, a device may be in a connected state in one access and idle state in another access, or vice versa. There may be common 5G-MM procedures (e.g., registration, deregistration, identification, authentication) for both accesses.

[0051] In various embodiments, one or more of the above-described functional entities of the 5G NAS and / or 5G AS may be configured to perform a method of emergency communication (e.g., voice call and / or SMS message) for a UE without cellular coverage (e.g., in non-cellular coverage), e.g., as further described herein.

[0052] FIG. 4 illustrates an example of a signaling and communication sequence diagram 400 for emergency communication via U2N relay, according to some embodiments. The signaling and communication sequence diagram 400 involves communication between a remote UE 410, a relay UE 420, a 5G Core (5GC) 430, a proxy call session control function (P-CSCF) module 440, and a public safety access point (PSAP) 450. For simplicity, base stations are not shown in FIG. 4. Nevertheless, similar to the network architecture described above, the base station provides a cell on which the relay UE 420 is camped so that the relay UE 420 is within the range of cellular coverage. The communication between the relay UE 420 and the 5GC 430 may be managed at least in part via the base station. In comparison, the remote UE 410 may involve the relay UE 420 for emergency services, since it may be outside the range of cellular coverage. Each of the remote UE 410 and relay UE 420 is an example of a UE 106 and includes the components of the UE 300 described herein above. The 5GC 430 can include the components of the 5G core network described in Figures 1 and 2. The P-CSCF module 440 can be implemented as dedicated hardware or a combination of hardware and software to provide an ingress point into and an egress point out of the service provider's IMS domain for an IMS client. The PSAP 450 can also be implemented as dedicated hardware or a combination of hardware and software in the public switched telephone network (PSTN) where an emergency services communication handler can receive and originate emergency calls. The PSAP 450 can also support packet-based connectivity to a service framework such as the IMS, allowing users of the IMS to make emergency communications (e.g., voice calls, video calls, text messages, etc.) without the need to route the call to the PSTN.

[0053] The signaling and communication sequence diagram 400 can be implemented to provide U2N relay for emergency services to a remote UE 410, whereby emergency communications (e.g., voice calls, video calls, text messages, etc.) to and from the remote UE 410 can be relayed from and to the PSAP 450 via the relay UE 420. Upon a trigger, the remote UE 410 can initiate U2N relay discovery. The trigger can be an emergency condition, such as making a call or sending a message to an emergency service (e.g., emergency services such as police, fire department, etc.) while the remote UE 410 is out of cellular service coverage. U2N discovery enables a remote UE to discover one or more candidate relay UEs, including the relay UE 420, based on such devices being configured to provide U2N relay functionality for emergency services and being within device-to-device (D2D) connectivity range, also referred to as peer-to-peer (P2P) connectivity range, to the remote UE 410. In some embodiments, the U2N relay discovery can be performed on unlicensed bands of the frequency spectrum. In some embodiments, U2N relay discovery may be performed based on any combination and / or all of dedicated peer-to-peer protocols, cellular-based communications, Wi-Fi-based communications, Bluetooth, and / or Bluetooth Low Energy-based communications, and other long-range and / or short-range communications technologies. In some embodiments, U2N relay discovery may be performed based on and / or in conjunction with 3GPP PC5 communications protocols. In some embodiments, U2N relay discovery may be performed using an emergency channel, for example, as described herein. In some embodiments, during U2N relay discovery, the remote UE 410 may provide information related to the emergency condition to the candidate relay UEs. For example, the remote UE 410 may provide an indication of the type of emergency, an approximate location of the remote UE 410, and / or other information related to the emergency condition.An example of U2N relay discovery is described in 3GPP TS23.304 V17.1.0(2021-12), section 6.3.2.3, the contents of which are incorporated herein by reference in their entirety.

[0054] The remote UE 410 may then select a relay UE 420 from the candidate relay UEs. In some embodiments, the selection of the relay UE 420 may be based on one or more factors, such as signal strength. An example of U2N relay selection is described in 3GPP TS23.304 V17.1.0(2021-12), section 6.3.2.3, the contents of which are incorporated herein by reference in their entirety.

[0055] Once selected, the relay UE 420 may establish U2N relay communication between the remote UE 410 and the 5GC 430. Establishing the U2N relay communication may include message exchanges between the remote UE 410 and the relay UE 420 and between the relay UE 420 and the 5GC 430, where the exchanged messages may indicate that the relay communication is established for emergency services. A D2D connection may be established between the remote UE 410 and the relay UE 420, and a network connection (e.g., via a base station) between the relay UE 410 and the 5GC 430 may be associated with the D2D connection such that uplink and downlink traffic may be relayed from the remote UE 410 and to the remote UE 104 via the relay UE 420. The type of messages and the specific establishment procedure may depend on the type of U2N relay (e.g., layer 3 U2N relay or layer 2 U2N relay), as further described in the next figure. In general, the messages may be transmitted based on any combination and / or all of dedicated peer-to-peer protocols, cellular-based communications, Wi-Fi-based communications, Bluetooth and / or Bluetooth Low Energy-based communications, and other long-range and / or short-range communications technologies. In some embodiments, the messages may be transmitted based on and / or in conjunction with the 3GPP PC5 communications protocol. In some embodiments, the messages may also be transmitted using an emergency channel. Examples of U2N relay establishment are described in 3GPP TS23.304 V17.1.0(2021-12), Section 6.5.1, Section 6.5.2, and 3GPP TS23.502 V17.3.0(2021-12), the contents of which are incorporated herein by reference in their entireties.

[0056] An IMS emergency session may then be established between the remote UE 410 and the P-CSCF module 440 based on the U2N relay communication. For example, the remote UE 410 may send an IMS registration request message to the relay UE 420, which may then forward the IMS registration request message to the 5GC 430. The relay UE 420 may perform an IMS registration to the 5GC 430 on behalf of the remote UE 410. The 5GC 430 may also register an IMS emergency session to the P-CSCF module 440. Examples of IMS emergency session establishment are described in 3GPP TS 23.502 V17.3.0 (2021-12) and 3GPP TS 23.167 V17.2.0 (2021-09), the contents of which are incorporated herein by reference in their entireties. Emergency communications (e.g., voice calls, video calls, and / or text messages) may then be supported between the remote UE 410 and the PSAP 450, with the associated traffic being exchanged using communication protocols supported by the IMS emergency session.

[0057] FIG. 5 illustrates an example sequence diagram 500 for emergency services via Layer 3 UE-to-network relaying, according to some embodiments. The sequence diagram 500 allows for several extensions to the sequence diagram 400, which are further described herein below. Similarities between the two sequence diagrams 400 and 500 are not repeated for brevity. The sequence diagram 500 involves communication between a remote UE 510, a relay UE 520, a 5G Core (5GC) 530, an N3IWF module 540, a 5GC 550, a P-CSCF module 560, and a PSAP 570. The 5G Core 530 may be part of the network of the relay UE 520. In comparison, the N3IWF module 540, the 5GC 550, and the P-CSCF module 560 may be part of the network of the remote UE 410. The network of relay UE 520 and the network of remote UE 510 may be the same, but need not be the same (if they are the same, 5GC 550 is the same as 5GC 530, otherwise they may be different). In Figure 5, relay UE 520 provides Layer 3 U2N relay.

[0058] An example of an extension involves U2N relay authorization. In particular, U2N relay authentication may be performed prior to U2N relay discovery, whereby the 5GC 530 authorizes the relay UE 520 to provide U2N relay for emergency services to one or more remote UEs. The relay UE 520 may send capability information to the 5GC 530 indicating the capability to support U2N relay for emergency services. The capability information indicates the capability of the relay UE 520 to act as a U2N relay for emergency services. This capability may be indicated to the network as part of the NAS capabilities in the 5GMM registration message. For example, the relay UE 520 may set this capability bit in the message based on a user input at the relay UE 520 corresponding to the user's consent to provide relay connectivity for emergency services, or based on a local configuration stored at the relay UE 520 and configuring the relay UE 520 to support this function. The 5GC 530 may take into account the UE capability to authenticate emergency relay services for the relay UE 520 in the registered PLMN of the relay UE 520 and / or additionally in one or more equivalent PLMNs. Authorization of the 5GC530 may be independent of authorization for normal (e.g., non-emergency) U2N relay services and / or may be independent of whether the relay UE520 is authorized for emergency services for itself in the current registered PLMN.

[0059] Based on a set of factors including authentication of the 5GC 530, the relay UE 520 can determine that U2N relay for emergency service capability can be provided to the remote UE. Other factors include, for example, relay service code (RSC) and battery level. In the context of layer 3 U2N relay, the relay UE 520 can provide layer 3 U2N relay for emergency services using only the RSC, which requires the remote UE to connect to the N3IWF. Additionally or alternatively, the relay UE 520 can provide layer 3 U2N relay for emergency services when the battery level exceeds a predefined threshold level. For example, the battery level can be classified into three categories, high, medium, and low, with thresholds of 60 percent and 30 percent (e.g., high is greater than 60 percent, medium is between 30 percent and 59 percent, and low is less than 29 percent). Of course, other categories and threshold levels may be defined, and such definitions can be stored by the relay UE 520 as a local configuration. Using the example three categories, a relay UE 510 may support Layer 3 U2N relay for emergency services, for example, only when its battery level is classified as high or medium. Additionally or alternatively, information regarding the battery level may be broadcast by the relay UE 520 (e.g., during U2N relay discovery) and used by remote UEs during U2N relay selection (e.g., one of the selection factors is a higher battery level of a first candidate relay UE relative to a second candidate relay UE, biasing the selection of the first candidate relay UE).

[0060] Upon determining that U2N relay for emergency services may be provided, the relay UE 520 may participate in U2N relay discovery with the remote UE 510. As described herein above, the battery level or related category may be transmitted to the remote UE 510 during this discovery. Another exemplary enhancement relates to indicating support of U2N relay for emergency services to the remote UE 510. In this manner, when the remote UE 510 is selecting a relay UE from the candidate UEs, the remote UE 510 may consider as one of the selection factors whether such candidate UE supports emergency relay services. The support information may be transmitted as part of Model A discovery and / or Model B discovery, as emergency RSC (eRSC), or as emergency service indicator (eSI), as further described in Figures 7-10.

[0061] Upon discovering that the relay UE 520 supports U2N relaying for emergency services, the remote UE 510 can select the relay UE 520 from among the similarly discovered candidate relay UEs. An exemplary extension to U2N relay selection includes emergency service factors. Emergency service factors can include an indication that the relay UE 520 supports relaying emergency services. In this manner, the remote UE 510 can select the best U2N relay (e.g., based on factors described with respect to FIG. 4) in view of capability indications from the candidate relay UEs indicating support (and / or non-support) of the emergency relay function. Another emergency service factor can include battery level. For example, the remote UE 510 selects the U2N relay for emergency services corresponding to the candidate relay UE with the highest battery level. Additionally or alternatively, the remote UE 510 can require that the candidate relay UE should have a minimum battery level or category to be selected (e.g., should have a medium or high battery level).

[0062] Following the U2N relay selection, relayed communication may be established. In the context of Layer 3 U2N relaying, the establishment may involve establishing a D2D connection between the remote UE 510 and the relay UE 520, establishing a session between the relay UE 520 and the 5GC 530 on behalf of the remote UE 510, followed by selecting an N3IWF module 540 and establishing a connection between the remote UE 510 and the N3IWF module 540.

[0063] Establishing a D2D connection between the remote UE 510 and the relay UE 520 may include the remote UE 510 sending a D2D request to the relay UE 520 on an unlicensed band of the frequency spectrum. In some embodiments, the D2D request message may be transmitted based on any combination and / or all of a dedicated peer-to-peer protocol, a cellular-based communication, a Wi-Fi-based communication, a Bluetooth® and / or Bluetooth Low Energy-based communication, and other long-range and / or short-range communication technologies. In some embodiments, the D2D request message may be transmitted based on and / or in conjunction with a 3GPP PC5 communication protocol. In some embodiments, the D2D request message may be transmitted using an emergency channel. In some embodiments, the D2D request message may include information related to an emergency condition to a potential relay UE. For example, the remote UE may provide an indication of a type of emergency, an approximate location of the remote UE, and / or other information related to the emergency condition. Upon registration with the 5GC 530, the relay UE 520 may accept the D2D request and inform the remote UE 510 of the acceptance of the D2D request. Additionally, the relay UE 520 may provide the remote UE 520 with information related to the remote UE 510 registering with the 5GC 530. The D2D connection may provide an IP address assigned to the remote UE 510 to the Layer 3 link.

[0064] An example extension for establishing a D2D connection relates to the use of a cause value for emergency services (e.g., the cause is "emergency services via U2N Relay"). In particular, the D2D request message may indicate the cause of the request to be for emergency services. The relay UE 520 may use the cause value to select an access class (e.g., AC=2) for access barring, such as an access identity and / or an access category for unified access control indicating emergency services, if an RRC connection establishment is required (e.g., for a PDU session establishment).

[0065] Establishing a session between the relay UE 520 and the 5GC 530 may include initiating an emergency attach procedure on behalf of the remote UE 510 with the 5GC 530 (e.g., with a base station serving the cell on which the relay UE 510 is camped). The attach procedure may include establishing a relay PDU session. The emergency attach procedure may also create and / or assign a default bearer to an SOS APN for emergency Session Initiation Protocol (SIP) signaling. The 5GC 530 may determine an appropriate PSAP, such as PSAP 570, based on location information of the remote UE 510 (e.g., provided by the relay UE 520). The relay UE 520 may accomplish a SIP emergency registration towards the P-CSCF 560. The P-CSCF 560 may facilitate the establishment of an RTP path towards the PSAP 570 to establish the emergency SIP session.

[0066] An exemplary extension for establishing a D2D connection concerns registration and priority. For example, the relay UE 520 does not initiate deregistration as long as a relay emergency session is ongoing. In other words, establishing a communication session (e.g., PDU session) between the relay UE 520 and the 5GC 530 is based on the UE-network relay registration. The UE-network relay deregistration is initiated only after this communication session is terminated. In case of resource constraints at the relay UE 520, the relay UE 520 should give priority to the relayed emergency session. In other words, the communication session (e.g., PDU session) has a higher priority than another communication function of the relay UE 520. Furthermore, the relay UE 520 indicates in the PDU session establishment that the relayed traffic is for emergency services. In this way, the communication is relayed by sending the remote UE's traffic in the PDU session to the core network and indicating that this traffic is for emergency services. However, if the RSC (e.g., eRSC) for emergency services is a standardized value used during U2N relay discovery, no explicit indication may be used. The 5GC 530 may treat PDU sessions for relayed emergency services with the same priority and importance as emergency service sessions initiated by the relaying UE 520 itself.

[0067] Selecting the N3IWF module 540 and establishing a connection between the remote UE 510 and the N3IWF module 540 may involve establishing an IPSec tunnel between them. An example of this process is described in 3GPP TS23.304 V17.1.0(2021-12), section 6.5.1, the contents of which are incorporated herein by reference in their entirety.

[0068] An IMS emergency session can then be established between the remote UE 510 and the P-CSCF module 560, which can support emergency communications (e.g., voice calls, video calls, test messages, etc.) between the remote UE 510 and the PSAP 570. Again, there are several extensions.

[0069] An exemplary extension relates to the location of the remote UE 510 during IMS emergency communication. In general, two types of location information can be used: UE provided location information (UPLI) and network provided location information (NPLI). In the case of Layer 3 U2N relay, the emergency communication is established using the N3IWF. The same requirements, such as the UE IP address (which in this case corresponds to the IP address of the relay UE 520), can be retrieved by the location retrieval function (LRF) of the network. 3GPP TS 23.167 V17.2.0, (2021-09), Section 7.5 and Annex L, the contents of which are incorporated herein by reference in their entirety, describe techniques for location processing, and such techniques can be adopted herein for the location determination of the remote UE 510. Furthermore, the remote UE 510 can include the new Radio Cell Global Identifier (NCGI) obtained during U2N relay discovery in the IMS emergency session request along with a confidence factor for the location. The trust score may be derived from calculating the distance between the remote UE 510 and the relay UE 520 by measuring by the remote UE 510 the side link reference signal received power (SL-RSRP) of a direct connection to the relay UE 520 (e.g., a PC5 link between them) or the side link discovery reference signal received power (SD-RSRP) of a discovery message between the remote UE 510 and the relay UE 520.

[0070] FIG. 6 illustrates an example sequence diagram 600 for emergency services via Layer 2 UE-to-network relaying, according to some embodiments. The sequence diagram 600 allows for several extensions to the sequence diagram 400. The extensions are further described herein below. Similarities between the two sequence diagrams 400 and 600 are not repeated for brevity. The sequence diagram 600 involves communication between a remote UE 610, a relay UE 620, a 5G Core (5GC) 630, a P-CSCF module 640, and a PSAP 650. In FIG. 6, the relay UE 620 provides Layer 2 U2N relaying.

[0071] An example of an extension involves U2N relay authentication. In particular, U2N relay authentication may be performed prior to U2N relay discovery, whereby the 5GC 630 authorizes the relay UE 620 to provide U2N relay for emergency services to one or more remote UEs. U2N relay authentication is similar to that described in connection with FIG. 5, and the similarities are not repeated here. The set of factors for Layer 3 U2N relay for emergency services may include RSC, but the RSC factors may not apply to Layer 2 U2N relay for emergency services. Instead, the relay UE 620 may consider whether emergency services are allowed in the cell (e.g., NG cell) where the UE 620 is camped. This determination may be based on a broadcast in a system information block (SIB) in the cell IMS EmergencySupport or eCalloverIMSSupport.

[0072] Upon determining that a U2N relay for emergency services can be provided, the relay UE 620 can participate in U2N relay discovery with the remote UE 610. Similar extensions relating to broadcasting battery level information and an indication that the U2N relay supports emergency services are applicable to Layer 2 U2N relay discovery, as further described in Figures 7-10.

[0073] Upon discovering that the relay UE 620 supports U2N relaying for emergency services, the remote UE 610 can select the relay UE 620 from among the similarly discovered candidate relay UEs. An exemplary extension to the U2N relay selection includes an emergency service factor as described in FIG. 5. Another exemplary extension to the U2N relay selection relates to PLMN identifiers (IDs). In particular, the remote UE 610 can ignore the PLMN ID(s) broadcasted by the relay UE 620 (and similarly other discovered candidate relay UEs) during the selection of the U2N relay for emergency services. Similar to cell selection for limited service conditions, the emergency service relay selection can be viewed as a limited service, which is an acceptable relay selection. Furthermore, the remote UE 610 performs emergency registration to the available 5G network through the relay UE 610 (if selected) even when the PLMNs broadcasted by the relay UE 610 do not include the preferred PLMN for the remote UE 620.

[0074] Following the U2N relay selection, relay communication can be established. In the context of Layer 2 U2N relaying, the establishment may involve establishing a D2D connection (e.g., PC5 connection) between the remote UE 610 and the relay UE 620, a service request of the relay UE 620 to the 5GC 630 to move the relay UE 620 to a CM_CONNECTED state, followed by establishing an AS connection between the remote UE 610 and the 5GC 630, and an emergency registration of the remote UE 610 to the 5GC 630. Establishing the D2D connection between the remote UE 610 and the relay UE 620 can be based on the 3GPP PC5 protocol. Thus, the relay UE 620 and the remote UE 610 can establish a PC5 link.

[0075] An example extension for establishing a D2D connection relates to using a cause value related to emergency services (e.g., the cause is "emergency services via U2N relay"). This extension is similar to the corresponding extension described in Figure 5, except that it applies to a service request for a layer 2 U2N relay.

[0076] The service request can be part of the RRC establishment with the base station. Similar priority and registration extensions as described above in FIG. 5 also apply here. In addition, in the context of layer 2 U2N relaying, the relay UE 620 indicates in the service request that the established connection is for relaying emergency registration and traffic from the remote UE. The relay UE 620 handles the radio bearers configured to carry the emergency traffic of the remote UE 610 with the same priority as the signaling radio bearers (SRBs) of the relay UE 620. The relay UE 620 can know that the remote UE 610 is using layer 2 U2N relaying for emergency services based on the cause value indicated by the remote UE 610 in the PC5 connection establishment phase, or alternatively by inspecting the establishment cause in a message (e.g., msg3) from the remote UE 610 to the 5GC 630.

[0077] During emergency registration, the remote UE 610 may initiate an emergency attach procedure (e.g., including registration of the remote UE 610 to the 5GC 630), such as with one or more functions of the 5GC 630, via the relay UE 610. The emergency attach procedure may create a default bearer and / or assign an SOS APN for emergency SIP signaling. The 5GC 630 may determine an appropriate PSAP, such as PSAP 650, based on location information of the remote UE 610 (e.g., provided by the relay UE 620). The remote UE 620 may effect a SIP emergency registration towards the P-CSF 640 module. The P-CSCF module 640 may facilitate establishment of an RTP path towards the PSAP 650, and an emergency SIP session is established.

[0078] An IMS emergency session can then be established between the remote UE 610 and the P-CSCF module 640, which can support emergency communications (e.g., voice calls, video calls, test messages, etc.) between the remote UE 610 and the PSAP 650. Again, there are several extensions.

[0079] An example extension relates to the location of the remote UE 610 during an IMS emergency communication. In the context of Layer 2 U2N relaying, if the 5GC 630 is using network-based positioning to obtain the location (e.g., NPLI) of the remote UE 610, the remote UE 61 can use the NCGI obtained during U2N discovery to report the enhanced cell ID. In addition, the remote UE 610 can include a confidence factor for the location based on a calculation of the distance to the relay UE 620 by measurements on SL-RSRP on the PC5 link between the remote UE 610 and the relay UE 620 and / or SD-RSRP measurements on the discovery message between the remote UE 610 and the relay UE 620.

[0080] 5 and 6, additional techniques may be used to provide further enhancements to the sequence diagram 400 of FIG. 4. An exemplary additional technique relates to a D2D connection between a remote UE and a relay UE. For example, the relay communication is established based on a direct communication request of the remote UE for emergency services. In this case, the direct communication request is given a higher priority by the relay UE than a request for a non-emergency service. In other words, the relay UE treats the direct communication request for emergency services with a higher priority than a request for a non-emergency service.

[0081] Another example technique relates to restricting a remote UE from initiating more than one emergency session at a time (e.g., a remote UE can initiate only one emergency session at a time). Similarly, a relay UE may receive multiple direct communication requests from different remote UEs for emergency services (e.g., by receiving a first direct communication from a first remote UE and a second direct communication request from a second remote UE). The relay UE may use a prioritization rule to select one of the remote UEs (e.g., the first remote instead of the second remote UE for UE-to-network relaying) to use for the relay session (e.g., U2N relaying, such that the relay UE is configured to support only one remote UE at a time for emergency service relaying). The prioritization rule indicates remote UE selection based on remote UE configured access identities. For example, the relay UE accepts requests from remote UEs configured with one of access identities 1-2 or 11-15. The communication request may be extended to include an access identification from the corresponding remote UE (e.g., an access identification of the first remote UE is included in the first direct communication request and corresponds to ID 1-2 or 11-15, thereby biasing the relay UE to select the first remote UE instead of the second remote UE). Additionally or alternatively, the prioritization rule indicates remote UE selection based on a corresponding contact in the contact list of the relay UE. A security parameter (such as a signed hash from the remote UE associated with the contact list) may be used for verification by the relay UE. For example, the first direct communication request includes a security parameter that the relay UE verifies based on the contact list. Additionally or alternatively, the prioritization rule indicates remote UE selection based on a first-come, first-served basis. For example, the first direct communication request is received before the second direct communication request. Thus, if two or more requests from the same priority level are received, the relay UE accepts the requests on a first-come, first-served basis.

[0082] Yet another exemplary technique relates to a relay UE's response to a direct communication request for emergency services. For example, the relay UE can send a response to the second direct communication request to a second remote UE (a remote UE that was not selected). The response indicates that the second direct communication request was rejected and / or the reason why the second direct communication request was rejected. In this way, the relay UE responds to a direct communication request for emergency services that cannot be accepted with an error reason indicating a status "relay busy" so that the corresponding remote UE can trigger relay discovery / selection again.

[0083] FIG. 7 illustrates an example sequence diagram 700 for UE-to-network relay discovery using model A, according to some embodiments. The sequence diagram 700 may be implemented as part of U2N relay discovery, whereby a relay UE 720 indicates to a remote UE 710 support for U2N relay (possibly layer 2 or layer 3) for emergency services. For example, the relay UE 720 may send (e.g., broadcast) a U2N discovery announcement message per model A of the U2N relay discovery process. The RSC may be included in this message, and its value may be sent to a standardized (e.g., defined in the technical specifications of the 5G standard) value of emergency RSC (eRSC). The eRSC value may be recognized by both the relay UE and the remote UE as indicating support for emergency services.

[0084] FIG. 8 illustrates an example sequence diagram 800 for UE-to-network relay discovery using Model B, according to some embodiments. The sequence diagram 800 may be implemented as part of U2N relay discovery, whereby a relay UE 820 indicates to a remote UE 810 support for U2N relay (possibly Layer 2 or Layer 3) for emergency services. Model B for U2N relay discovery is now described. According to Model B, the remote UE 810 sends a U2N relay discovery request to the relay UE 820. The request includes a query for RSC, where the queried value of RSC is set to the standardized value of eRSC. The relay UE 820 sends a U2N relay discovery response. The RSC may be included in the response, where its value is sent to the standardized value of eRSC, thereby indicating to the remote UE 820 that the relay UE 810 supports emergency services relay functionality.

[0085] FIG. 9 illustrates another example of a sequence diagram 900 for UE-to-network relay discovery using model A, according to some embodiments. The sequence diagram 900 may be implemented as part of U2N relay discovery, whereby a relay UE 920 indicates to a remote UE 910 support for U2N relay (possibly layer 2 or layer 3) for emergency services. Here, in addition to the RSC, an emergency service indicator (eSI) is used, whereby the RSC and the eSI are separate and distinct from each other. The eSI may have a value (e.g., a bit value set to "1") indicating the capability to support the emergency service relay function, and this capability is indicated as additional information along with the RSC. For example, the relay UE 920 may send (e.g., broadcast) a U2N discovery announcement message per model A of the U2N relay discovery process. This message may include the RSC and, separately, the eSI. Optionally, as indicated by the dotted arrow, the eSI can be sent in a separate message from that carrying the RSC, and this other message contains additional U2N relay discovery information such as the eSI, which can be used instead of or in addition to the U2N relay discovery announcement message.

[0086] FIG. 10 illustrates another example of a sequence diagram 1000 for UE-to-network relay discovery using Model B, according to some embodiments. The sequence diagram 1000 may be implemented as part of U2N relay discovery, whereby a relay UE 1020 indicates to a remote UE 1010 support for U2N relay (possibly Layer 2 or Layer 3) for emergency services. Model B for U2N relay discovery is now described with the use of eSI. According to Model B, the remote UE 1010 sends a U2N relay discovery request to the relay UE 1020. The request includes an RSC and an emergency service request. The relay UE 1020 sends a U2N relay discovery response. The response may include the RSC and separately the eSI.

[0087] 11 illustrates an example of an operational flow / algorithm structure 1100 for a relay UE to participate in relay communication, according to some embodiments. A relay UE is an example of a UE 106, 206, 300, 420, 520, 620, 720, 820, 920, 1020, or UE 1500 described herein above, or components thereof, such as the processor 1504. A relay UE can communicate directly with remote UEs and communicate with a core network (e.g., 5GC) via a base station (among other network components).

[0088] The operational flow / algorithm structure 1100 may include, at 1102, sending capability information to the core network indicating that the relay UE supports UE-to-network relaying for emergency services. For example, the capability information may be sent as part of the NAS capabilities in a 5GMM registration message, in response to a user input at the relay UE indicating consent to the capability, and / or based on a stored local configuration at the relay UE indicating capability support.

[0089] The operational flow / algorithm structure 1100 may include receiving authorization information from the core network indicating that UE-to-network relaying for emergency services is authorized for the relay UE, at 1104. For example, the authorization information may be received based on a determination by the core network that emergency services in the registered PLMN and / or one or more further equivalent PLMNs are allowed for the relay UE.

[0090] The operational flow / algorithm structure 1100 may include, at 1106, establishing a relay communication between the core network and a remote UE that is out of cellular coverage, the relay UE for relaying communication between the remote UE and a Public Safety Answering Point (PSAP) via the relay communication. The relay communication may include a Layer 2 U2N relay or a Layer 3 U2N relay, and the extensions described with respect to Figures 5-6 may be applied to establish and use the relay communication.

[0091] 12 illustrates an example of an operational flow / algorithm structure 1200 for a remote UE to participate in relay communication, according to some embodiments. The relay UE is an example of the UE 300, 410, 510, 610, 710, 810, 910, 1010, or UE 1500 described herein above, or components thereof, such as the processor 1504. The remote UE can communicate directly with the relay UE and with the core network (e.g., 5GC) via the relay UE (among other network components).

[0092] The operational flow / algorithm structure 1200 may include, at 1202, receiving information from a relay UE as part of UE-network relay discovery, the information indicating that the relay UE supports UE-network relaying for emergency services. For example, the information may include eRSC and / or eSI provided using Model A or Model B U2N relay discovery as described in Figures 7-10.

[0093] The operational flow / algorithm structure 1200 may include, at 1204, selecting a relay UE based on the information as part of a UE-to-network relay selection. For example, the remote UE selects a relay UE from a discovered candidate set of relay UEs only if the information indicates that the relay UE can provide U2N relaying for emergency services. Other factors may be used in the selection, such as those factors described in Figures 5-6.

[0094] The operational flow / algorithm structure 1200 may include, at 1206, establishing a relay communication with the core network via the relay UE while out of cellular coverage, for relaying communications between the remote UE and a Public Safety Answering Point (PSAP). The relay communication may include a Layer 2 U2N relay or a Layer 3 U2N relay, and the extensions described with respect to Figures 5-6 may be applied to establish and use the relay communication.

[0095] Figure 13 illustrates an example operational flow / algorithm structure 1300 for a core network to participate in relay communication, according to some embodiments. The core network is an example of a 5GC as described in connection with Figures 1-2 and 5-6. The core network can communicate with relay UEs via base stations (among other network components) and with remote UEs via relay UEs (also among other network components).

[0096] The operational flow / algorithm structure 1300 may include, at 1302, capability information from a relay user equipment (UE) indicating that the relay UE supports UE-to-network relaying for emergency services. For example, the capability information is received as part of the NAS capabilities in a 5GMM registration message.

[0097] The operational flow / algorithm structure 1300 may include, at 1304, transmitting authentication information to the relay UE indicating that UE-to-network relaying for emergency services is authorized for the relay UE. The authentication information may be transmitted based on a determination by the core network that emergency services in the registered PLMN and / or additionally in one or more equivalent PLMNs are allowed for the relay UE.

[0098] The operational flow / algorithm structure 1300 may include, at 1306, establishing a relayed communication with a remote UE outside of cellular coverage via a relay UE, the relayed communication for relaying communication between the remote UE and a Public Safety Answering Point (PSAP). The relayed communication may include a Layer 2 U2N relay or a Layer 3 U2N relay, and the extensions described with respect to Figures 5-6 may be applied to establish and use the relayed communication.

[0099] 14 illustrates a receiving component 1400 of a UE 106 according to some embodiments. The receiving component 1400 may include an antenna panel 1404 including several antenna elements. Although the panel 1404 is shown with four antenna elements, other embodiments may include other numbers.

[0100] The antenna panel 1404 may be coupled to an analog beamforming (BF) component that includes several phase shifters 1408(1)-1408(4). The phase shifters 1408(1)-1408(4) may be coupled to a radio frequency (RF) chain 1412. The RF chain 1412 may amplify the received analog RF signal, downconvert the RF signal to baseband, and convert the analog baseband signal to a digital baseband signal that may be provided to a baseband processor for further processing.

[0101] In various embodiments, control circuitry, which may be in a baseband processor, may provide BF weights (e.g., W1 through W4), which may represent phase shift values, to phase shifters 1408(1) through 1408(4) to provide receive beams at the antenna panel 1404. These BF weights may be determined based on channel-based beamforming.

[0102] 15 illustrates a UE 1500 according to some embodiments. The UE 1500 may be similar to and substantially interchangeable with the UE 106 of FIG.

[0103] Similar to that described above with respect to UE 124, UE 1500 may be any mobile or non-mobile computing device, such as, for example, a mobile phone, a computer, a tablet, an industrial wireless sensor (e.g., a microphone, a carbon dioxide sensor, a pressure sensor, a humidity sensor, a thermometer, a motion sensor, an accelerometer, a laser scanner, a fluid level sensor, an inventory sensor, a voltage / current meter or an actuator, etc.), a video surveillance / monitoring device (e.g., a camera or a video camera, etc.), a wearable device, or a relaxed-IoT device. In some embodiments, the UE may be a RedCap UE or an NR-Light UE.

[0104] The UE 1500 may include a processor 1504, an RF interface circuit 1508, a memory / storage 1512, a user interface 1516, a sensor 1520, a driver circuit 1522, a power management integrated circuit (PMIC) 1524, and a battery 1528. The components of the UE 1500 may be implemented as an integrated circuit (IC), a portion thereof, a separate electronic device or other module, logic, hardware, software, firmware, or a combination thereof. The block diagram of FIG. 15 is intended to show a high-level view of some of the components of the UE 1500. However, some of the components shown may be omitted, additional components may be displayed, and the components shown may be arranged differently in other implementations.

[0105] The components of the UE 1500 may be coupled with various other components via one or more interconnects 1532, which may represent any type of interface, input / output, bus (local, system, or extended), transmission line, trace, optical connection, etc. that allows various circuit components (on a common or different chips or chipsets) to interact with one another.

[0106] The processor 1504 may include processor circuitry such as, for example, a baseband processor circuit (BB) 1504A, a central processing unit circuit (CPU) 1504B, and a graphics processing unit circuit (GPU) 1504C. The processor 1504 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory / storage 1512 to cause the UE 1500 to perform the operations described herein.

[0107] In some embodiments, the baseband processor circuitry 1504A may access a communications protocol stack 1536 in the memory / storage 1512 to communicate over a 3GPP compliant network. In general, the baseband processor circuitry 1504A may access the communications protocol stack to perform user plane functions at the PHY, MAC, RLC, PDCP, SDAP, and PDU layers, and control plane functions at the PHY, MAC, RLC, PDCP, RRC, and non-access "NAS" layers. In some embodiments, PHY layer operations may additionally / alternatively be performed by components of the RF interface circuitry 1508.

[0108] The baseband processor circuit 1504A can generate or process baseband signals or waveforms that carry information in a 3GPP-compliant network. In some embodiments, waveforms for NR can be based on Cyclic Prefix OFDM (CP-OFDM) in the uplink or downlink and Discrete Fourier Transform Spread OFDM (DFT-S-OFDM) in the uplink.

[0109] The baseband processor circuit 1504A may also access group information 1524 from the memory / storage 1512 to determine search space groups in which certain iterations of the PDCCH may be transmitted.

[0110] The memory / storage 1512 may include any type of volatile or non-volatile memory that may be distributed throughout the UE 1500. In some embodiments, some of the memory / storage 1512 may be located on the processor 1504 itself (e.g., L1 and L2 cache), while other memory / storage 1512 may be external to the processor 1504 but accessible via a memory interface. The memory / storage 1512 may include any suitable volatile or non-programmable ROM, such as, but not limited to, volatile or non-volatile memory, e.g., dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), flash memory, solid state memory, or any other type of memory device technology.

[0111] The RF interface circuitry 1508 may include transceiver circuitry and a radio frequency front end module (RFEM) that enable the UE 1500 to communicate with other devices over a radio access network. The RF interface circuitry 1508 may include various elements disposed in the transmit or receive paths. These elements may include, for example, switches, mixers, amplifiers, filters, combiner circuits, control circuits, etc.

[0112] In the receive path, the RFEM may receive the radiated signal from the air interface via antenna 1524 and proceed to filter and amplify the signal (using a low noise amplifier). The signal may be provided to a transceiver receiver that downconverts the RF signal to a baseband signal that is provided to a baseband processor in the processor 1504.

[0113] In the transmit path, the transmitter of the transceiver upconverts the baseband signal received from the baseband processor and provides an RF signal to the RFEM, which may amplify the RF signal through a power amplifier before the signal is radiated over the air interface via the antenna 1524.

[0114] In various embodiments, the RF interface circuitry 1508 may be configured to transmit and receive signals in a manner that complies with NR access technologies.

[0115] The antenna 1524 may comprise several antenna elements, each of which converts electrical signals into radio waves to travel through the air and converts received radio waves into electrical signals. The antenna elements may be arranged in one or more antenna panels. The antenna 1524 may have antenna panels that are omnidirectional, directional, or a combination thereof to enable beamforming and multiple-input multiple-output communication. The antenna 1524 may include microstrip antennas, printed antennas fabricated on the surface of one or more printed circuit boards, patch antennas, phased array antennas, etc. The antenna 1524 may have one or more panels designed for a particular frequency band, including bands in FR1 or FR2.

[0116] User interface circuitry 1516 includes various input / output (I / O) devices designed to enable user interaction with UE 1500. User interface 1516 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting input, including, among others, one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touch screen, a microphone, a scanner, a headset, etc. Output device circuitry includes any physical or virtual means for displaying or otherwise communicating information, such as sensor readings, actuator position(s), or other similar information. The output device circuitry may include any number or combination of audio or visual displays, including, among others, one or more simple visual outputs / indicators (e.g., binary status indicators such as light emitting diodes (LEDs) and multi-character visual outputs), or more complex outputs such as display devices or touch screens (e.g., liquid crystal displays (LCDs), LED displays, quantum dot displays, projectors, etc.), where output such as text, graphics, multimedia objects, etc. are generated or created from operation of the UE 1500.

[0117] The sensors 1520 may include devices, modules, or subsystems that are intended to detect events or changes in their environment and transmit information about the detected events (sensor data) to some other device, module, subsystem, etc. Examples of such sensors include, among others, inertial measurement units including accelerometers, gyroscopes, or magnetometers, microelectromechanical or nanoelectromechanical systems including 3-axis accelerometers, 3-axis gyroscopes, or magnetometers, level sensors, flow sensors, temperature sensors (e.g., thermistors), pressure sensors; barometric pressure sensors; gravitational meters; altimeters; image capture devices (e.g., cameras or lensless apertures); light detection and ranging sensors, proximity sensors (e.g., infrared detectors, etc.), depth sensors, ambient light sensors, ultrasonic transceivers, microphones or other similar audio capture devices, etc.

[0118] The driver circuit 1522 may include software and hardware elements that operate to control specific devices embedded in, attached to, or otherwise communicatively attached to the UE 1500. The driver circuit 1522 may include individual drivers that enable other components to interact with or control various input / output (I / O) devices that may be present in or connected to the UE 1500. For example, the driver circuit 1522 may include a display driver that controls and enables access to a display device, a touchscreen driver that controls and enables access to a touchscreen interface, a sensor driver that obtains sensor readings of the sensor circuit 1520 and controls and enables access to the sensor circuit 1520, a driver that obtains actuator positions of electromechanical components or controls and enables access to electromechanical components, a camera driver that controls and enables access to an embedded image capture device, and an audio driver that controls and enables access to one or more audio devices.

[0119] The PMIC 1524 may manage the power provided to various components of the UE 1500. In particular, with respect to the processor 1504, the PMIC 1524 may control power source selection, voltage scaling, battery charging, or DC-DC conversion.

[0120] In some embodiments, the PMIC 1524 may control or otherwise be part of various power saving mechanisms of the UE 1500. For example, if the platform UE is in an RRC_Connected state where it is still connected to a RAN node because it expects to receive traffic shortly, after some period of inactivity the platform UE may enter a state known as Discontinuous Reception Mode (DRX). During this state, the UE 1500 may power down for short intervals, thereby saving power. If there is no data traffic activity for an extended period of time, the UE 1500 may transition to an RRC_Idle state where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The UE 1500 goes into a very low power state, performs paging, wakes up periodically again to listen to the network, and then powers down again. The UE 1500 cannot receive data in this state and must transition back to the original RRC_Connected state to receive data. In a further power saving mode, the device may be allowed to be unavailable from the network for periods longer than the paging interval (which can range from a few seconds to a few hours). During this time, the device may be completely unable to reach the network and may be completely powered down. Any data transmitted during this time will be significantly delayed, but the delay is deemed acceptable.

[0121] The battery 1528 may provide power to the UE 1500, although in some examples the UE 1500 may be mounted and deployed in a fixed location or may have a power source coupled to a power grid. The battery 1528 may be a lithium ion battery, a metal air battery such as a zinc air battery, an aluminum air battery, a lithium air battery, etc. In some implementations, such as vehicle-based applications, the battery 1528 may be a typical automotive lead acid battery.

[0122] 16 illustrates a gNB 1600 according to some embodiments. The gNB 1600 may be similar to and substantially interchangeable with the base station 104 of FIG.

[0123] The gNB 1600 may include a processor 1604, an RF interface circuit 1608, a core network (CN) interface circuit 1612, and a memory / storage circuit 1616.

[0124] The components of the gNB 1600 may be coupled to various other components via one or more interconnects 1628.

[0125] The processor 1604, RF interface circuitry 1608, memory / storage circuitry 1616 (including communication protocol stack 1610), antenna 1624, and interconnect 1628 may be similar to the like-named elements shown and described in connection with FIG.

[0126] The CN interface circuitry 1612 can provide connectivity to a core network, e.g., a fifth generation network interface (5GC), using a 5GC compatible core network protocol, such as the Carrier Ethernet protocol, or some other suitable protocol. Network connectivity may be provided to or from the gNB 1600 via optical fiber or wireless backhaul. The CN interface circuitry 1612 may include one or more dedicated processors or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, the CN interface circuitry 1612 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

[0127] It is understood that use of personally identifiable information should comply with privacy policies and practices generally recognized as meeting or exceeding industry or governmental requirements for maintaining user privacy. In particular, personally identifiable information data should be managed and handled in a manner that minimizes the risk of unintended or unauthorized access or use, and the nature of permitted uses should be clearly indicated to users.

[0128] For one or more embodiments, at least one of the components described in one or more of the preceding figures may be configured to perform one or more of the operations, techniques, processes, or methods as described in the example section below. For example, the baseband circuitry described above in connection with one or more of the preceding figures may be configured to operate according to one or more of the examples described below. As another example, circuitry associated with a UE, base station, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate according to one or more of the examples described below in the example section. EXAMPLES

[0129] Further exemplary embodiments are provided in the following sections.

[0130] Example 1 includes a method, the method including: sending capability information to a core network indicating that a relay UE supports UE-network relaying for emergency services; receiving authentication information from the core network indicating that UE-network relaying for emergency services is authorized for the relay UE; and establishing relay communication between the core network and a remote UE outside a cellular service range, wherein the relay UE is for relaying communication between the remote UE and a public safety answering point (PSAP) via the relay communication.

[0131] Example 2 includes the method according to example 1, wherein the capability information is sent as part of non-access stratum (NAS) capability information in a mobility management message.

[0132] Example 3 includes the method according to Examples 1 to 2, wherein the capability information is sent based on a user input at the relay UE or based on a configuration stored at the UE.

[0133] Example 4 includes the method of any one of Examples 1 to 3, wherein the UE-inter-network relaying is Layer 2 UE-inter-network relaying, including determining that emergency services are allowed in a cell where the relaying UE is camped, and determining that the UE-inter-network relaying for emergency services is authorized and, based on the emergency services being allowed, further Layer 2 UE-inter-network relaying for emergency services is provided.

[0134] Example 5 includes the method of any of Examples 1 to 3, including determining that the UE-network relay is a Layer 3 UE-to-network relay and that the Layer 3 UE-to-network relay supports emergency services with a Relay Service Code (RSC) associated with a connection to a Non-3rd Generation Partnership Project Interworking Function (N3IWF); determining that the UE-to-network relay for the emergency services is authorized; and based on the RSC, determining that the UE-to-network relay for the emergency services is provided.

[0135] Example 6 includes the method of any of Examples 1 to 5, including determining a battery level of a relaying UE, determining that UE-to-network relaying for emergency services is authorized, and based on the battery level, determining that further UE-to-network relaying for emergency services is provided.

[0136] Example 7 includes the method of example 6, further including transmitting an indication of the battery level to the remote UE as part of the UE-network relay discovery.

[0137] Example 8 includes the method of any of Examples 1 to 7, further including broadcasting a UE-network layer discovery announcement as part of the UE-network relay discovery, the UE-network layer discovery announcement including an emergency relay service code indicating that the relay UE supports connectivity for emergency services.

[0138] Example 9 includes receiving a UE-network layer discovery request from a remote UE as part of UE-inter-network relay discovery, the UE-network layer discovery request indicating a query for an emergency relay service code; 8. The method according to any one of claims 1 to 7, further comprising: sending a UE-network layer discovery response to the remote UE as part of the UE-network relay discovery, the UE-network layer discovery response including an emergency relay service code indicating that the relay UE supports connectivity for emergency services.

[0139] Example 10 includes the method of any of Examples 1 to 7, further including broadcasting a UE-network layer discovery announcement as part of the UE-network relay discovery, the UE-network layer discovery announcement including a relay service code (RSC) and an emergency service indicator separate from the RSC.

[0140] Example 11 includes the method of any of Examples 1 to 7, further including receiving a UE-network layer discovery request from a remote UE as part of the UE-network relay discovery, the UE-network layer discovery request indicating a query for a relay service code (RSC) and an emergency service request; and sending a UE-network layer discovery response to the remote UE as part of the UE-network relay discovery, the UE-network layer discovery response including the RSC and an emergency service indicator separate from the RSC.

[0141] Example 12 includes a method according to any of Examples 1 to 11, further including: receiving a message from a remote UE requesting relayed communication, the message including an indication that the relayed communication is requested for emergency services; and selecting an access category for evaluating the access identity wireless access barring based on the indication or the indication that the relayed communication is requested for emergency services.

[0142] Example 13 includes the method of any of Examples 1 to 12, wherein establishing relay communication includes establishing a communication session between the relay UE and the core network based on UE-inter-network relay registration, and UE-inter-network relay deregistration is initiated only after the communication session is terminated.

[0143] Example 14 includes the method of any of Examples 1 to 13, wherein establishing the relay communication includes establishing a communication session between the relay UE and the core network, and the communication session has a higher priority than another communication session of the relay UE.

[0144] Example 15 includes the method of any of Examples 1 to 14, wherein establishing relay communication includes establishing a protocol data unit (PDU) session for Layer 3 UE-to-network relaying, and the communication is relayed by sending traffic of the remote UE to the core network in the PDU session and indicating that the traffic is for emergency services.

[0145] Example 16 includes the method of any of Examples 1 to 14, wherein establishing the relay communication includes establishing a protocol data unit (PDU) session for Layer 3 UE-to-network relay, and the communication is relayed by transmitting traffic of the remote UE to the core network in the PDU session, and the traffic is transmitted without an indication that the traffic is for an emergency service based on an emergency relay service code.

[0146] Example 17 includes the method of any of Examples 1 to 14, wherein the UE-network relay is a Layer 2 UE-network relay, and the establishing the relay communication includes by indicating that the relay communication is established to relay emergency registration traffic from the remote UE, and establishing a connection to a radio access network (RAN).

[0147] Example 18 includes the method according to example 17, in which the traffic of the remote UE is given the same priority by the relay UE as the signaling radio bearer of the relay UE.

[0148] Example 19 includes the method described in Example 17, further including determining that the relay communication is for an emergency service based on a cause value indicated by the remote UE in the direct link connection establishment phase, based on an establishment cause indicated in a message of the remote UE to the core network, or.

[0149] Example 20 includes the method of any of Examples 1 to 19, in which the relay communication is established based on a direct communication request of a remote UE for an emergency service, and the direct communication request is given a higher priority by the relay UE than a request for a non-emergency service.

[0150] Example 21 includes the method of any of Examples 1 to 20, wherein the remote UE is a first remote UE, and further includes receiving a first direct communication request and a second direct communication request from the first remote UE and a second remote UE, respectively, and selecting the first remote UE instead of the second remote UE for UE-network relaying based on a prioritization rule.

[0151] Example 22 includes the method of example 21, in which the prioritization rule indicates selection of the remote UE based on access identities configured in the remote UE.

[0152] Example 23 includes the method of example 22, in which the access identity of the first remote UE is included in the first direct communication request.

[0153] Example 24 includes the method of example 21, in which the prioritization rule indicates selection of a remote UE based on a corresponding contact in a contact list of the relay UE.

[0154] Example 25 includes the method of example 24, in which the first direct communication request includes a security parameter that the relay UE verifies based on the contact list.

[0155] Example 26 includes the method of example 21, in which the prioritization rule indicates selection of a remote UE based on a first-come, first-served basis, where a first direct communication request is received before a second direct communication request.

[0156] Example 27 includes the method of Example 21, further including sending a response to the second direct communication request to the second remote UE, the response indicating that the second direct communication request has been rejected or that the cause of the second direct communication request has been rejected.

[0157] Example 28 includes a method including receiving information from a relay UE as part of UE-network relay discovery, the information indicating that the relay UE supports UE-network relaying for emergency services, selecting a relay UE based on the information as part of UE-network relay selection, and establishing relay communication with a core network via the relay UE while out of cellular service coverage, the relay communication being for relaying communication between a remote UE and a public safety answering point (PSAP).

[0158] Example 29 includes the method of example 28, wherein receiving information includes receiving a UE-network layer discovery announcement as part of the UE-network relay discovery, the UE-network layer discovery announcement including an emergency relay service code indicating that the relay UE supports connectivity for emergency services.

[0159] Example 30 includes the method of example 28, wherein receiving the information includes receiving a message as part of UE-network relay discovery, the message including an emergency relay service code indicating that the relay UE supports connectivity for emergency services.

[0160] Example 31 includes the method of example 28, further including sending a message to the relay UE as part of the UE-network relay discovery, the message indicating a query for an emergency relay service code, and receiving the information includes receiving a response as part of the UE-network relay discovery, the response including the emergency relay service code indicating that the relay UE supports connectivity for emergency services.

[0161] Example 32 includes the method of example 28, wherein receiving information includes receiving a message as part of UE-network relay discovery, the message including a relay service code (RSC) and an emergency service indicator separate from the RSC.

[0162] Example 33 includes the method of example 28, including sending a message to the relay UE as part of the UE-network relay discovery, the message indicating a query for a relay service code (RSC) and an emergency service request, and receiving information includes receiving a response as part of the UE-network relay discovery, the response including the RSC and an emergency service indicator separate from the RSC.

[0163] Example 34 includes the method of any one of examples 28-33, including receiving an indication of a battery level of a relay UE, the relay UE being further selected based at least in part on the battery level.

[0164] Example 35 includes the method of any of Examples 28 to 34, wherein the relay UE is selected independent of a Public Land Mobile Network (PLMN) identifier indicated by the relay UE.

[0165] Example 36 includes the method of any of Examples 28 to 35, wherein establishing relay communication includes performing emergency registration to the core network via the relay UE, and a public land mobile network (PLMN) broadcast of the relay UE excludes a preferred PLMN of the remote UE.

[0166] Example 37 includes a method as described in any of Examples 28 to 36, including transmitting location information to the core network in the relay communication, the location information being based on a new radio cell global identifier (NCGI) determined by the remote UE further during UE-network relay discovery.

[0167] Example 38 includes the method of example 37, wherein the location information further indicates a location confidence factor related to a distance between the remote UE and the relay UE, and the location confidence factor is determined based on a side link discovery reference signal received power (SD-RSRP) of a side link reference signal received power (SL-RSRP) discovery message of a direct connection to the relay UE or a measurement by the remote UE.

[0168] Example 39 includes the method of any of Examples 28 to 38, wherein establishing relay communication includes establishing an internet protocol multimedia subsystem (IMS) session between the remote UE and a proxy-call session control function (P-CSCF), and transmitting in the IMS session a new radio cell global identifier (NCGI) determined by the remote UE during UE-network relay discovery and a location confidence factor associated with a distance between the remote UE and the further relay UE.

[0169] Example 40 includes the method of any of Examples 28 to 39, wherein the remote UE is configured to establish only one emergency service session at a time.

[0170] Example 41 includes a method including: receiving capability information from a relay user equipment (UE) indicating that the relay UE supports UE-to-network relaying for emergency services; sending authentication information to the relay UE indicating that UE-to-network relaying for emergency services is authorized for the relay UE; and establishing relay communication with a remote UE outside of a cellular service range via the relay UE, wherein the relay communication is for relaying communication between the remote UE and a public safety answering point (PSAP).

[0171] Example 42 includes the method of example 41, wherein the authentication information is associated with one or more public land mobile networks (PLMNs).

[0172] Example 43 includes the method of any of Examples 41 to 42, wherein establishing relay communication includes establishing a protocol data unit (PDU) session with the relay UE for Layer 3 UE-to-network relaying, and the PDU session is given the same priority by the core network as an emergency service session initiated by the relay UE.

[0173] Example 44 includes a UE including means for performing one or more elements of the method described or related to any of Examples 1 to 40.

[0174] Example 45 includes one or more non-transitory computer-readable media containing instructions that, when executed by one or more processors of a UE, cause the UE to perform one or more elements of a method described or a related method of any of Examples 1 to 40, or any other method or process described herein.

[0175] Example 46 includes a UE including logic, modules, or circuitry for performing one or more elements of the method described or related to any of examples 1 to 40.

[0176] Example 47 includes a UE including one or more processors and one or more computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of a method described or related to any of Examples 1 to 40.

[0177] Example 48 includes a system comprising means for performing one or more elements of the method described or related to any of Examples 1 to 40.

[0178] Example 49 includes a core network comprising means for performing one or more elements of the method described or related to any of Examples 41 to 43.

[0179] Example 50 includes one or more non-transitory computer-readable media containing instructions that, when executed by one or more processors in a core network, cause the core network to perform one or more elements of a method described in any of Examples 41 to 43 or a method related thereto.

[0180] Example 51 includes a core network including logic, modules, or circuitry for performing one or more elements of the method described or related to any of Examples 41 to 43.

[0181] Example 52 includes a core network including one or more processors and one or more computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of a method described or related to any of Examples 41 to 43.

[0182] Example 53 includes a system comprising means for performing one or more elements of the method described or related to any of Examples 41 to 43.

[0183] Any of the above examples may be combined with any other example (or combination of examples) unless otherwise stated. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise forms disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

[0184] Although the above embodiments have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated, and it is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims

1. A relay user equipment (UE), one or more processors; and one or more memories that store instructions, the instructions, when executed by the one or more processors, Sending capability information to a core network, the capability information indicating that the relay UE supports UE-to-network relaying for emergency services; receiving authorization information from the core network indicating that the UE-to-network relaying for the emergency service is authorized for the relay UE; A relay UE configured to establish a relay communication between the core network and a remote UE outside a cellular service range, the relay UE being for relaying communication between the remote UE and a public safety answering point (PSAP) via the relay communication.

2. The relay UE of claim 1 , wherein the capability information is transmitted as part of Non-Access Stratum (NAS) capability information in a mobility management message.

3. The relay UE of claim 1 , wherein the capability information is sent based on a user input at the relay UE or based on a stored configuration at the UE.

4. The UE-to-network relaying is a Layer 2 UE-to-network relaying, and the execution of the instructions comprises: determining that emergency services are allowed in a cell in which the relay UE is camped; 2. The relay UE of claim 1, further configured to: determine that the Layer 2 UE-to-network relaying for emergency services is provided based on the UE-to-network relaying for emergency services being authenticated and the emergency services being authorized.

5. the UE-to-network relay is a Layer 3 UE-to-network relay, and the execution of the instructions determines that the Layer 3 UE-to-network relay supports an emergency service with a Relay Service Code (RSC) associated with a connection to a non-3rd Generation Partnership Project Interworking Function (N3IWF); 2. The relay UE of claim 1, further configured to: determine that the UE-to-network relaying for emergency services is authorized and that the UE-to-network relaying for emergency services is provided based on the RSC.

6. said executing said instructions determining a battery level of the relay UE; 2. The relay UE of claim 1, further configured to: determine that the UE-to-network relaying for emergency services is authorized and that the UE-to-network relaying for emergency services is provided based on the battery level.

7. The relay UE of claim 6 , wherein the execution of the instructions further configures the relay UE to transmit an indication of the battery level to the remote UE as part of UE-to-network relay discovery.

8. 2. The relay UE of claim 1, wherein the execution of the instructions further configures the relay UE to broadcast a UE-network layer discovery announcement as part of UE-network relay discovery, the UE-network layer discovery announcement including an emergency relay service code indicating that the relay UE supports connectivity for emergency services.

9. The execution of the instructions includes receiving a UE-network layer discovery request from the remote UE as part of UE-network relay discovery, the UE-network layer discovery request indicating a query for an emergency relay service code; 2. The relay UE of claim 1, further configured to send a UE-network layer discovery response to the remote UE as part of the UE-network relay discovery, the UE-network layer discovery response including the emergency relay service code indicating that the relay UE supports connectivity for emergency services.

10. 2. The relay UE of claim 1, wherein the execution of the instructions further configures the relay UE to broadcast a UE-network layer discovery announcement as part of UE-network relay discovery, the UE-network layer discovery announcement including a relay service code (RSC) and an emergency service indicator separate from the RSC.

11. The execution of the instructions includes receiving a UE-network layer discovery request from the remote UE as part of UE-network relay discovery, the UE-network layer discovery request indicating a query for a Relay Service Code (RSC) and an emergency service request; 2. The relay UE of claim 1, further configured to send a UE-network layer discovery response to the remote UE as part of the UE-network relay discovery, the UE-network layer discovery response including the RSC and an emergency service indicator separate from the RSC.

12. The execution of the instructions includes receiving a message from the remote UE requesting the relayed communication, the message including an indication that the relayed communication is required for emergency services; 2. The relay UE of claim 1, further configured to: select an access identity or an access category for evaluating radio access barring based on the indication that the relay communication is required for emergency services.

13. 2. The relay UE of claim 1, wherein establishing the relay communication includes establishing a communication session between the relay UE and the core network based on a UE-to-network relay registration, and UE-to-network relay deregistration is initiated only after the communication session is terminated.

14. The relay UE of claim 1 , wherein establishing the relay communication includes establishing a communication session between the relay UE and the core network, the communication session having a higher priority than another communication session of the relay UE.

15. 2. The relay UE of claim 1, wherein establishing the relay communication includes establishing a Protocol Data Unit (PDU) session for Layer 3 UE-to-network relay, and the communication is relayed by sending traffic of the remote UE to the core network in the PDU session and indicating that the traffic is for emergency services.

16. 2. The relay UE of claim 1, wherein establishing the relay communication includes establishing a Protocol Data Unit (PDU) session for Layer 3 UE-to-network relay, and the communication is relayed by transmitting traffic of the remote UE to the core network in the PDU session, and the traffic is transmitted without an indication that the traffic is for an emergency service based on an emergency relay service code.

17. 2. The relay UE of claim 1, wherein the UE-to-network relay is a Layer 2 UE-to-network relay, and establishing the relay communication includes establishing the connection by indicating that a connection to a Radio Access Network (RAN) is to be established for relaying emergency registration and traffic from the remote UE.

18. 18. The relay UE of claim 17, wherein the traffic of the remote UE is given the same priority by the relay UE as a signaling radio bearer of the relay UE.

19. 18. The relay UE of claim 17, wherein the execution of the instructions further configures the relay UE to determine that the relay communication is for an emergency service based on a cause value indicated by the remote UE in a direct link connection establishment phase or based on an establishment cause indicated in a message of the remote UE to the core network.

20. 2. The relay UE of claim 1, wherein the relay communication is established based on a direct communication request of the remote UE for emergency services, the direct communication request being given a higher priority by the relay UE than a request for non-emergency services.

21. the remote UE is a first remote UE, and the execution of the instructions comprises: receiving a first direct communication request and a second direct communication request from the first remote UE and a second remote UE, respectively; The relay UE of claim 1 , further configured to: select the first remote UE instead of the second remote UE for the UE-to-network relay based on a prioritization rule.

22. 22. The relay UE of claim 21, wherein the prioritization rule indicates selection of a remote UE based on an access identity configured in the remote UE.

23. The relay UE of claim 22, wherein an access identity of the first remote UE is included in the first direct communication request.

24. The relay UE of claim 21 , wherein the prioritization rule indicates selection of a remote UE based on a corresponding contact in a contact list of the relay UE.

25. The relay UE of claim 24, wherein the first direct communication request includes security parameters that the relay UE verifies based on the contact list.

26. 22. The relay UE of claim 21, wherein the prioritization rule indicates selection of remote UEs on a first-come, first-served basis, with the first direct communication request being received before the second direct communication request.

27. 22. The relay UE of claim 21, wherein the execution of the instructions further configures the relay UE to send a response to the second direct communication request to the second remote UE, the response indicating that the second direct communication request has been rejected or that a cause of the second direct communication request has been rejected.

28. One or more computer-readable storage media storing instructions that, when executed on a remote user equipment (UE), receiving, as part of UE-to-network relay discovery, information from a relay UE, the information indicating that the relay UE supports UE-to-network relaying for emergency services; selecting the relay UE based on the information as part of a UE-to-network relay selection; and establishing a relay communication with a core network via the relay UE while out of range of cellular service, the relay communication being for relaying communications between the remote UE and a public safety answering point (PSAP).

29. 29. The one or more computer-readable storage media of claim 28, wherein receiving the information includes receiving a UE-network layer discovery announcement as part of the UE-network relay discovery, the UE-network layer discovery announcement including an emergency relay service code indicating that the relay UE supports connectivity for emergency services.

30. 29. The one or more computer-readable storage media of claim 28, wherein receiving the information includes receiving a message as part of the UE-to-network relay discovery, the message including an emergency relay service code indicating that the relay UE supports connectivity for emergency services.

31. 29. The one or more computer-readable storage media of claim 28, wherein the operations further include sending a message to the relay UE as part of the UE-network relay discovery, the message indicating a query for an emergency relay service code, and receiving the information includes receiving a response as part of the UE-network relay discovery, the response including the emergency relay service code indicating that the relay UE supports connectivity for emergency services.

32. 29. The one or more computer-readable storage media of claim 28, wherein receiving the information includes receiving a message as part of the UE-to-network relay discovery, the message including a Relay Service Code (RSC) and an emergency service indicator separate from the RSC.

33. 29. The one or more computer-readable storage media of claim 28, wherein the operations further include sending a message to the relay UE as part of the UE-network relay discovery, the message indicating a query for a relay service code (RSC) and an emergency service request, and receiving the information includes receiving a response as part of the UE-network relay discovery, the response including the RSC and an emergency service indicator separate from the RSC.

34. 30. The one or more computer-readable storage media of claim 28, wherein the operations further include receiving an indication of a battery level of the relay UE, the relay UE being selected further based at least in part on the battery level.

35. 30. The one or more computer-readable storage media of claim 28, wherein the relay UE is selected independently of a Public Land Mobile Network (PLMN) identifier indicated by the relay UE.

36. 30. The one or more computer-readable storage media of claim 28, wherein establishing the relay communication includes performing an emergency registration to the core network via the relay UE, wherein a public land mobile network (PLMN) broadcast of the relay UE excludes a preferred PLMN of the remote UE.

37. 29. The one or more computer-readable storage media of claim 28, wherein the operations further include transmitting location information to the core network in the relay communication, the location information being based on a new radio cell global identifier (NCGI) determined by the remote UE during the UE-to-network relay discovery.

38. 38. The one or more computer-readable storage media of claim 37, wherein the location information further indicates a location confidence factor associated with a distance between the remote UE and the relay UE, the location confidence factor being determined based on a measurement by the remote UE of a side link reference signal received power (SL-RSRP) of a direct connection to the relay UE or a side link discovery reference signal received power (SD-RSRP) of a discovery message.

39. establishing the relayed communication includes establishing an internet protocol multimedia subsystem (IMS) session between the remote UE and a proxy-call session control function (P-CSCF); 29. The one or more computer-readable storage media of claim 28, wherein the operations further include transmitting in the IMS session a new radio cell global identifier (NCGI) determined by the remote UE during the UE-to-network relay discovery and a location confidence factor associated with a distance between the remote UE and the relay UE.

40. 30. The one or more computer-readable storage media of claim 28, wherein the remote UE is configured to establish only one emergency service session at a time.

41. A method performed by a core network, comprising: receiving capability information from a relay user equipment (UE) indicating that the relay UE supports UE-to-network relaying for emergency services; sending authentication information to the relay UE indicating that the UE-to-network relaying for emergency services is authorized for the relay UE; and establishing a relay communication with a remote UE outside of a cellular service range via the relay UE, the relay communication being for relaying communication between the remote UE and a public safety answering point (PSAP).

42. 42. The method of claim 41, wherein the authentication information is associated with one or more public land mobile networks (PLMNs).

43. 42. The method of claim 41, wherein establishing the relay communication includes establishing a Protocol Data Unit (PDU) session with the relay UE for Layer 3 UE-to-network relaying, the PDU session being given the same priority by the core network as an emergency service session initiated by the relay UE.

Images