User equipment (UE)

Abstract

The present invention provides a method for, when an end-to-end QoS value included in a UE policy and used in communication path establishment or communication for ProSe multi-hop communication is insufficient, etc., transmitting / receiving various kinds of information necessary for communication between UEs that constitute the communication path or communication with a network, and a control message including the information, and causing each UE or the network to perform behavior or processing based on the message.

Description

UE (User Equipment)

[0001] This embodiment relates to UE (User Equipment). This application claims priority from Japanese Patent Application No. 2025-019341 filed in Japan on February 7, 2025, and incorporates its content herein by reference.

[0002] In 3GPP (3rd Generation Partnership Project: registered trademark), the system architecture of 5GS (5G System), which is the fifth-generation (5G) mobile communication system, is under consideration, and discussions are being held to support new procedures and new functions (see Non-Patent Documents 1 to 4). In Release 19 of the 5G standard, architectures, procedures for communication and control, etc. for extending the Proximity based Services (ProSe) function are under consideration (see Non-Patent Document 1).

[0003] 3GPP TS 24.554 V19.0.0 (2024-12); 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Proximity-services (ProSe) in 5G System (5GS) protocol aspects; Stage 3 (Release 18)

[0004] In 5GS (5G System), Proximity-services (ProSe) for realizing proximity wireless communication between UEs is under consideration. Furthermore, in Release 19 of the 5G standard, multi-hop communication between UEs via multiple relay UEs is under consideration.

[0005] On the other hand, in cases where the End-to-End QoS values ​​included in the UE policy used for establishing or communicating a communication path for ProSe multi-hop communication are insufficient, the various information necessary for communication between each UE or network constituting the communication path, the sending and receiving of control messages containing such information, and the behavior and processing of each UE or network based on such messages are not clearly defined.

[0006] One aspect of this embodiment has been made in view of the circumstances described above, and its purpose is to provide a method for performing various types of information necessary for communication between each UE or network constituting a communication path, sending and receiving control messages containing such information, and executing the behavior and processing of each UE or network based on such messages, when the value of End-to-End QoS included in the UE policy used in establishing or communicating a communication path for ProSe multihop communication is insufficient.

[0007] One embodiment of this User Equipment (UE) comprises a transceiver unit and a control unit, wherein the transceiver unit sends a registration request message to the network containing capability information indicating support for operation as a 5G ProSe multi-hop L3 (Layer-3) UE-to-UE (U2U) end UE, and if accepted by the network, the transceiver unit receives a ProSeP (5G ProSe Policy) from the network containing end-to-end QoS parameters, the transceiver unit sends a message to the network containing first information, the first information indicating that the end-to-end QoS parameters assigned by the network are insufficient, and the transceiver unit receives a new ProSeP from the network containing new end-to-end QoS parameters based on the first information. One embodiment of this User Equipment (UE) comprises a transceiver unit, a control unit, and a storage unit, wherein the UE operates as a 5G ProSe multi-hop L3 (Layer-3) UE-to-UE (U2U) end UE, and in the discovery procedure, if the control unit determines that the maximum number of hops determined by the control unit based on the End-to-End QoS parameters included in the ProSeP (5G ProSe Policy) stored in the storage unit is less than the number of hops assumed by the UE, the control unit aborts the discovery procedure, the transceiver unit sends a message containing second information to the network, the second information indicating that the end-to-end QoS parameters assigned from the network are insufficient, the transceiver unit receives a new ProSeP from the network containing new End-to-End QoS parameters based on the second information, and the control unit executes a new discovery procedure.

[0008] According to one aspect of this embodiment, various information necessary for establishing a communication path for multi-hop communication and providing UE policies including QoS for ProSe multi-hop communication is clarified, and means for sending and receiving control messages containing such information between UEs, and methods for executing the behavior and processing of each UE based on such messages are provided.

[0009] This diagram outlines the mobile communication system (EPS / 5GS). This diagram explains the detailed configuration of the mobile communication system (EPS / 5GS). This diagram explains the equipment configuration of the UE. This diagram explains the configuration of the access network equipment (gNB) in 5GS. This diagram explains the configuration of the core network equipment (AMF / SMF / UPF) in 5GS. This diagram explains the registration procedure. This diagram explains the network request UE policy management procedure. This diagram explains the UE request ProSeP provision procedure.

[0010] The best mode for implementing one aspect of this embodiment will be described below with reference to the drawings. In this embodiment, as an example, an embodiment of a mobile communication system when one aspect of this embodiment is applied will be described.

[0011] [1. System Overview] First, Figure 1 is a diagram illustrating the general structure of the mobile communication system 1 used in each embodiment, and Figure 2 is a diagram illustrating the detailed configuration of the mobile communication system 1.

[0012] Figure 1 shows that mobile communication system 1 consists of UE_A10, access network_A80, core network_A90, PDN (Packet Data Network)_A5, access network_B120, core network_B190, and DN (Data Network)_A6.

[0013] In the following, these devices and functions may be referred to using abbreviations such as UE, Access Network_A, Core Network_A, PDN, Access Network_B, Core Network_B, DN, etc.

[0014] Figure 2 also shows devices and functions such as UE_A10, E-UTRAN80, MME40, SGW35, PGW-U30, PGW-C32, PCRF60, HSS50, 5G AN120, AMF140, UPF130, SMF132, PCF160, UDM150, and N3IWF170, as well as the interfaces that connect these devices and functions to each other.

[0015] In the following, these devices and functions may be described using abbreviations such as UE, E-UTRAN, MME, SGW, PGW-U, PGW-C, PCRF, HSS, 5G AN, AMF, UPF, SMF, PCF, UDM, N3IWF, etc.

[0016] Furthermore, the 4G system, EPS (Evolved Packet System), consists of access network_A and core network_A, but may also include UE and / or PDN. Similarly, the 5G system, 5GS (5G System), consists of UE, access network_B and core network_B, but may also include DN.

[0017] A UE is a device capable of connecting to network services via 3GPP access (also known as a 3GPP access network or 3GPP AN) and / or non-3GPP access (also known as a non-3GPP access network or non-3GPP AN). A UE may be a wireless communication terminal device such as a mobile phone or smartphone, and may be a terminal device capable of connecting to both EPS and 5GS. A UE may be equipped with a UICC (Universal Integrated Circuit Card) or an eUICC (Embedded UICC). A UE may also be referred to as a user device or a terminal device.

[0018] Furthermore, access network_A corresponds to E-UTRAN (Evolved Universal Terrestrial Radio Access Network) and / or a wireless LAN access network. E-UTRAN has one or more eNBs (evolved Node B; eNodeB)45. Note that in the following, eNB45 may be written simply as eNB. If there are multiple eNBs, each eNB is connected to the others, for example, by an X2 interface. Furthermore, the wireless LAN access network has one or more access points.

[0019] Furthermore, access network_B corresponds to the 5G access network (5G AN). The 5G AN consists of NG-RAN (NG Radio Access Network) and / or non-3GPP access networks. One or more gNBs (NR Node B; gNodeB)122 are located in the NG-RAN. Note that, below, gNB122 may be written with the symbol omitted, such as gNB. A gNB is a node that provides the NR (New Radio) user plane and control plane to the UE, and is a node that connects to the 5GCN via an NG interface (including the N2 interface or N3 interface). In other words, a gNB is a base station device newly designed for 5GS and has different functions from the base station device (eNB) used in the 4G system, EPS. Also, if there are multiple gNBs, each gNB is connected to the others, for example, by an Xn interface.

[0020] Furthermore, a non-3GPP access network may be an untrusted non-3GPP access network or a trusted non-3GPP access network. Here, an untrusted non-3GPP access network may be a non-3GPP access network that does not perform security management within the access network, such as a public Wi-Fi network. On the other hand, a trusted non-3GPP access network may be an access network defined by 3GPP and may be equipped with a TNAP (trusted non-3GPP access point) and a TNGF (trusted non-3GPP Gateway function).

[0021] Furthermore, in the following, E-UTRAN and NG-RAN may be referred to as 3GPP access. Similarly, wireless LAN access networks and non-3GPP AN may be referred to as non-3GPP access. Additionally, nodes located in access network_B may be collectively referred to as NG-RAN nodes.

[0022] Furthermore, in the following, access network_A and / or access network_B and / or the devices included in access network_A and / or the devices included in access network_B may be referred to as access networks or access network devices.

[0023] Furthermore, Core Network A corresponds to EPC (Evolved Packet Core). EPC is configured with, for example, MME (Mobility Management Entity), SGW (Serving Gateway), PGW (Packet Data Network Gateway)-U, PGW-C, PCRF (Policy and Charging Rules Function), HSS (Home Subscriber Server), etc.

[0024] Furthermore, Core Network B corresponds to 5GCN (5G Core Network). 5GCN includes, for example, AMF (Access and Mobility Management Function), UPF (User Plane Function), SMF (Session Management Function), PCF (Policy Control Function), and UDM (Unified Data Management). Here, 5GCN may also be expressed as 5GC.

[0025] Furthermore, in this specification, Core Network A and / or Core Network B and / or devices included in Core Network A and / or devices included in Core Network B may be referred to as the Core Network, or Core Network Devices or Devices within the Core Network, or Network, or NW. In other words, for example, when Network, or NW is referred to in this specification, it may mean Core Network A or Core Network B.

[0026] The core network (Core Network A and / or Core Network B) may be an IP mobile communication network operated by a Mobile Network Operator (MNO) that connects the access network (Access Network A and / or Access Network B) to the PDN and / or DN; it may be a core network for a mobile network operator that operates and manages the mobile communication system 1; or it may be a core network for a virtual mobile communication operator or virtual mobile communication service provider such as an MVNO (Mobile Virtual Network Operator) or MVNE (Mobile Virtual Network Enabler).

[0027] Furthermore, although Figure 1 shows a case where the PDN and DN are the same, they may be different. The PDN may be a Data Network (DN) that provides communication services to the UE. The DN may be configured as a packet data service network, or it may be configured for each service. In addition, the PDN may include connected communication terminals. Therefore, connecting to the PDN may also mean connecting to communication terminals or server devices located in the PDN. Furthermore, sending and receiving user data with the PDN may also mean sending and receiving user data with communication terminals or server devices located in the PDN. Note that the PDN may be referred to as DN, and the DN may be referred to as PDN.

[0028] Furthermore, in the following, access network_A, core network_A, PDN, access network_B, core network_B, DN, and / or one or more devices included therein may be referred to as a network or network device. In other words, when a network and / or network device sends and receives messages and / or performs procedures, it means that access network_A, core network_A, PDN, access network_B, core network_B, DN, and / or one or more devices included therein send and receive messages and / or perform procedures.

[0029] Furthermore, the UE can connect to the access network. The UE can also connect to the core network via the access network. In addition, the UE can connect to the PDN or DN via the access network and the core network. That is, the UE can send and receive (communicate) user data with the PDN or DN. When sending and receiving user data, non-IP communication may be used in addition to IP (Internet Protocol) communication.

[0030] Here, IP communication refers to data communication using IP, where data is sent and received via IP packets. An IP packet consists of an IP header and a payload. The payload may include data sent and received by devices and functions included in EPS or devices and functions included in 5GS. Non-IP communication refers to data communication that does not use IP, where data is sent and received in a format different from the structure of an IP packet. For example, non-IP communication may be data communication realized by sending and receiving application data without an IP header, or it may be user data sent and received by the UE with other headers such as a MAC header or an Ethernet® frame header attached.

[0031] Furthermore, access network_A, core network_A, access network_B, core network_B, PDN_A, and DN_A may include devices not shown in Figure 2. For example, core network_A and / or core network_B may include an AUSF (Authentication Server Function) or an AAA (Authentication, authorization, and accounting) server (AAA-S).

[0032] Here, AUSF is a core network device equipped with authentication functions for 3GPP access and non-3GPP access. Specifically, it is a network function unit that receives authentication requests for 3GPP access and / or non-3GPP access from the UE and executes the authentication procedure.

[0033] Furthermore, the AAA server is a device equipped with authentication, authorization, and billing functions, which connects directly or indirectly to the AUSF via other network devices. The AAA server may be a network device within the core network. However, the AAA server may not be included in core network_A and / or core network_B, but may be included in PLMN. In other words, the AAA server may be a core network device or a device located outside the core network. For example, the AAA server may be a server device within PLMN managed by a third party.

[0034] Note that in Figure 2, for the sake of simplification, only one of each device / function is shown; however, multiple similar devices / functions may be configured in the mobile communication system 1. Specifically, the mobile communication system 1 may be configured with multiple devices / functions such as UE_A10, E-UTRAN80, MME40, SGW35, PGW-U30, PGW-C32, PCRF60, HSS50, 5G AN120, AMF140, UPF130, SMF132, PCF160, and / or UDM150.

[0035] UPF_A235 connects to DN, SMF, other UPFs, and access networks. UPF_A235 may also perform roles such as anchoring to intra-RAT mobility or inter-RAT mobility, packet routing and forwarding, UL CL (Uplink Classifier) ​​functionality supporting routing of multiple traffic flows to a single DN, branching point functionality supporting multi-homed PDU sessions, QoS processing for the user plane, verification of uplink traffic, buffering of downlink packets, and triggering of downlink data notification. Furthermore, UPF_A235 may also act as a relay device for transferring user data, serving as a gateway between the DN and the core network_B190. In addition, UPF_A235 may also act as a gateway for IP communication and / or non-IP communication. Moreover, UPF_A235 may have the functionality to forward IP communication and the functionality to convert between non-IP and IP communication. Furthermore, the multiple gateways that are deployed may also be gateways that connect the core network_B190 to a single DN. Note that UPF_A235 may have connectivity to other NFs and may connect to each device via other NFs.

[0036] Furthermore, a different UPF, UPF_C239 (also referred to as branching point or uplink classifier), may exist as a device or NF between UPF_A235 and the access network. If UPF_C239 exists, the PDU session between the UE and DN will be established via the access network, UPF_C239, and UPF_A235.

[0037] Furthermore, UPF130 may be the same device as UPF_A235. Note that UPF130 and UPF_A235 may be written with the symbols omitted, like UPF.

[0038] [2. Configuration of Each Device] Next, the configuration of each device (UE, and / or access network device, and / or core network device) used in each embodiment will be described with reference to a diagram. Each device may be configured as physical hardware, as logical (virtual) hardware configured on general-purpose hardware, or as software. Furthermore, at least some (including all) of the functions of each device may be configured as physical hardware, logical hardware, or software.

[0039] Furthermore, each memory unit within each device / function described below (memory unit_A340, memory unit_A440, memory unit_B540, memory unit_A640, memory unit_B740) is composed of, for example, semiconductor memory, SSD (Solid State Drive), HDD (Hard Disk Drive), etc. In addition, each memory unit can store not only the information originally set at the time of shipment, but also various information transmitted and received with devices / functions other than its own device / function (for example, UE, and / or access network devices, and / or core network devices, and / or PDN, and / or DN). In addition, each memory unit can store identification information, control information, flags, parameters, etc., contained in control messages transmitted and received within the various communication procedures described later. Furthermore, each memory unit may store this information for each UE. In addition, when interworking between 5GS and EPS occurs, each memory unit can store control messages and user data transmitted and received with devices / functions contained within 5GS and / or EPS. In this case, not only data transmitted and received via the N26 interface can be stored, but also data transmitted and received without using the N26 interface.

[0040] [2.1. UE Device Configuration] First, an example of the device configuration of a UE (User Equipment) will be described using FIG. 3. The UE is composed of a control unit _A300, an antenna 310, a transceiver unit _A320, and a storage unit _A340. The control unit _A300, the transceiver unit _A320, and the storage unit _A340 are connected via a bus. The transceiver unit _A320 is connected to the antenna 310.

[0041] The control unit _A300 is a functional unit that controls the operations and functions of the entire UE. The control unit _A300 reads and executes various programs stored in the storage unit _A340 as necessary to realize various processes in the UE.

[0042] The transceiver unit _A320 is a functional unit for wireless communication with a base station device (eNB or gNB) in an access network via an antenna. That is, the UE can transmit and receive user data and / or control information with an access network device, and / or a core network device, and / or a PDN, and / or a DN using the transceiver unit _A320.

[0043] Explaining in detail with reference to FIG. 2, the UE can communicate with a base station device (eNB) in the E-UTRAN via the LTE-Uu interface by using the transceiver unit _A320. Also, the UE can communicate with a base station device (gNB) in the 5G AN by using the transceiver unit _A320. Further, the UE can transmit and receive NAS (Non-Access-Stratum) messages with the AMF via the N1 interface by using the transceiver unit _A320. However, since the N1 interface is logical, in reality, the communication between the UE and the AMF is performed via the 5G AN.

[0044] The storage unit _A340 is a functional unit for storing programs, user data, control information, etc. necessary for each operation of the UE.

[0045] [2.2 gNB Device Configuration] Next, an example of the gNB device configuration will be described using Fig. 4. The gNB is composed of a control unit _B500, an antenna 510, a network connection unit _B520, a transceiver unit _B530, and a storage unit _B540. The control unit _B500, the network connection unit _B520, the transceiver unit _B530, and the storage unit _B540 are connected via a bus. The transceiver unit _B530 is connected to the antenna 510.

[0046] The control unit _B500 is a functional unit that controls the operations and functions of the entire gNB. The control unit _B500 realizes various processes in the gNB by reading and executing various programs stored in the storage unit _B540 as necessary.

[0047] The network connection unit _B520 is a functional unit for the gNB to communicate with the AMF and / or UPF. That is, the gNB can transmit and receive user data and / or control information to and from the AMF and / or UPF using the network connection unit _B520.

[0048] The transceiver unit _B530 is a functional unit for wireless communication with the UE via the antenna 510. That is, the gNB can transmit and receive user data and / or control information to and from the UE using the transceiver unit _B530.

[0049] Explaining in detail with reference to Fig. 2, the gNB within the 5G AN can communicate with the AMF via the N2 interface and with the UPF via the N3 interface by using the network connection unit _B520. Also, the gNB can communicate with the UE by using the transceiver unit _B530.

[0050] The storage unit _B540 is a functional unit for storing programs, user data, control information, etc. necessary for each operation of the gNB.

[0051] [2.3. AMF Device Configuration] Next, an example of the AMF device configuration will be described using Figure 5. The AMF consists of a control unit_B700, a network connection unit_B720, and a storage unit_B740. The control unit_B700, the network connection unit_B720, and the storage unit_B740 are connected via a bus. The AMF may be a node that handles the control plane. The AMF may also be a network device. In other words, for example, in this specification, a network device may mean an AMF.

[0052] The control unit B700 is a functional unit that controls the operation and functions of the entire AMF. The control unit B700 implements various processes in the AMF by reading and executing various programs stored in the memory unit B740 as needed.

[0053] The network connection unit_B720 is a functional unit for the AMF to connect to base station equipment (gNB), and / or SMF, and / or PCF, and / or UDM, and / or SCEF within the 5G AN. In other words, the AMF can use the network connection unit_B720 to send and receive user data and / or control information with base station equipment (gNB), and / or SMF, and / or PCF, and / or UDM, and / or SCEF within the 5G AN. To put it another way, for example, the network connection unit may also be a transmitting and receiving unit.

[0054] Referring to Figure 2, the AMF within 5GCN can communicate with the gNB via the N2 interface, the UDM via the N8 interface, the SMF via the N11 interface, and the PCF via the N15 interface, using the network connection unit _A620. Furthermore, the AMF can send and receive NAS messages with the UE via the N1 interface using the network connection unit _A620. However, since the N1 interface is logical, actual communication between the UE and the AMF takes place via the 5G AN. Additionally, if the AMF supports the N26 interface, it can communicate with the MME via the N26 interface using the network connection unit _A620.

[0055] Memory unit B740 is a functional unit for storing programs, user data, control information, etc., necessary for each operation of the AMF.

[0056] Furthermore, the AMF has functions such as exchanging control messages with the RAN using the N2 interface, exchanging NAS messages with the UE using the N1 interface, encrypting and protecting the integrity of NAS messages, registration management (RM) function, connection management (CM) function, reachability management function, mobility management function for UEs, etc., forwarding SM (Session Management) messages between the UE and the SMF, access authentication (Access Authentication, Access Authorization) function, security anchor function (SEA), security context management (SCM), support for the N2 interface to the N3IWF (Non-3GPP Interworking Function), support for sending and receiving NAS signals with the UE via the N3IWF, and authentication of UEs connected via the N3IWF.

[0057] Furthermore, registration management manages the RM state for each UE. The RM state may be synchronized between the UE and the AMF. There are two RM states: unregistered state (RM-DEREGISTERED state) and registered state (RM-REGISTERED state). In the RM-DEREGISTERED state, the UE is not registered with the network, so the UE context in the AMF does not have valid location or routing information for that UE, and therefore the AMF cannot reach the UE. In the RM-REGISTERED state, the UE is registered with the network, so the UE can receive services that require registration with the network. Note that the RM state may also be expressed as the 5GMM state. In this case, the RM-DEREGISTERED state may be expressed as the 5GMM-DEREGISTERED state, and the RM-REGISTERED state may be expressed as the 5GMM-REGISTERED state.

[0058] In other words, 5GMM-REGISTERED means that each device may have established a 5GMM context or a PDU session context. Furthermore, when each device is 5GMM-REGISTERED, UE_A10 may start sending and receiving user data and control messages, and may respond to paging. In addition, when each device is 5GMM-REGISTERED, UE_A10 may perform registration procedures other than the registration procedure for initial registration, and / or service request procedures.

[0059] Furthermore, 5GMM-DEREGISTERED may occur even if each device has not established a 5GMM context, or if the location information of UE_A10 is not known to the network, or if the network is unreachable to UE_A10. If each device is in a 5GMM-DEREGISTERED state, UE_A10 may initiate the registration procedure, or establish a 5GMM context by executing the registration procedure.

[0060] Furthermore, connection management manages the CM state for each UE. The CM state may be synchronized between the UE and the AMF. There are two CM states: disconnected state (CM-IDLE state) and connected state (CM-CONNECTED state). In the CM-IDLE state, the UE is in the RM-REGISTERED state but does not have a NAS signaling connection established with the AMF via the N1 interface. Also, in the CM-IDLE state, the UE does not have an N2 connection or an N3 connection. On the other hand, in the CM-CONNECTED state, the UE has a NAS signaling connection established with the AMF via the N1 interface. Also, in the CM-CONNECTED state, the UE may have an N2 connection and / or an N3 connection.

[0061] Furthermore, connection management may be handled separately for CM states in 3GPP access and CM states in non-3GPP access. In this case, the CM states in 3GPP access may include an unconnected state (CM-IDLE state over 3GPP access) and a connected state (CM-CONNECTED state over 3GPP access). Furthermore, the CM states in non-3GPP access may include an unconnected state (CM-IDLE state over non-3GPP access) and a connected state (CM-CONNECTED state over non-3GPP access). Note that the unconnected state may be expressed as idle mode, and the connected state may be expressed as connected mode.

[0062] Furthermore, the CM state may be expressed as 5GMM mode. In this case, the disconnected state may be expressed as 5GMM-IDLE mode, and the connected state may be expressed as 5GMM-CONNECTED mode. Additionally, the disconnected state in 3GPP access may be expressed as 5GMM-IDLE mode over 3GPP access, and the connected state in 3GPP access may be expressed as 5GMM-CONNECTED mode over 3GPP access. Furthermore, the disconnected state in non-3GPP access may be expressed as 5GMM-IDLE mode over non-3GPP access, and the connected state in non-3GPP access may be expressed as 5GMM-CONNECTED mode over non-3GPP access. Note that 5GMM-IDLE mode may also be expressed as idle mode, and 5GMM-CONNECTED mode may also be expressed as connected mode.

[0063] Furthermore, one or more AMFs may be placed within core network_B. Also, an AMF may be a Network Function (NF) that manages one or more Network Slice Instances (NSIs). Additionally, an AMF may be a Common Control Plane Network Function (CCNF) shared among multiple NSIs.

[0064] Furthermore, N3IWF is a device and / or function placed between the non-3GPP access and 5GCN when the UE connects to 5GS via non-3GPP access.

[0065] [2.4. SMF Device Configuration] Next, an example of an SMF device configuration will be explained using Figure 5. The SMF consists of a control unit_B700, a network connection unit_B720, and a storage unit_B740. The control unit_B700, network connection unit_B720, and storage unit_B740 are connected via a bus. The SMF may be a node that handles the control plane.

[0066] The control unit_B700 is a functional unit that controls the operation and functions of the entire SMF. The control unit_B700 implements various processes in the SMF by reading and executing various programs stored in the memory unit_B740 as needed.

[0067] The network connection unit B720 is a functional unit for the SMF to connect with the AMF, and / or UPF, and / or PCF, and / or UDM. In other words, the SMF can use the network connection unit B720 to send and receive user data and / or control information with the AMF, and / or UPF, and / or PCF, and / or UDM.

[0068] Referring to Figure 2, the SMF within 5GCN can communicate with the AMF via the N11 interface, the UPF via the N4 interface, the PCF via the N7 interface, and the UDM via the N10 interface by using the network connection unit A620.

[0069] Memory unit B740 is a functional unit for storing programs, user data, control information, etc., necessary for each operation of the SMF.

[0070] SMF has session management functions such as establishing, modifying, and releasing PDU sessions; IP address allocation and management functions for UEs; UPF selection and control functions; UPF configuration functions for routing traffic to appropriate destinations; functions for sending and receiving the SM portion of NAS messages; functions for notifying when downlink data has arrived (Downlink Data Notification); functions for providing AN-specific (AN-specific) SM information sent to ANs via the N2 interface through AMF; functions for determining the SSC mode (Session and Service Continuity mode) for sessions; and roaming functions.

[0071] [2.5. UPF Device Configuration] Next, an example of the UPF device configuration will be explained using Figure 5. The UPF consists of a control unit_B700, a network connection unit_B720, and a storage unit_B740. The control unit_B700, the network connection unit_B720, and the storage unit_B740 are connected via a bus. The UPF may be a node that handles the control plane.

[0072] The control unit B700 is a functional unit that controls the operation and functions of the entire UPF. The control unit B700 implements various processes in the UPF by reading and executing various programs stored in the memory unit B740 as needed.

[0073] The network connection unit B720 is a functional unit that allows the UPF to connect with base station equipment (gNB), and / or SMF, and / or DN within the 5G AN. In other words, the UPF can use the network connection unit B720 to send and receive user data and / or control information with base station equipment (gNB), and / or SMF, and / or DN within the 5G AN.

[0074] Referring to Figure 2, the UPF within 5GCN can communicate with the gNB via the N3 interface, the SMF via the N4 interface, the DN via the N6 interface, and other UPFs via the N9 interface by using the network connection unit A620.

[0075] Memory unit B740 is a functional unit for storing programs, user data, control information, etc., necessary for each operation of the UPF.

[0076] UPF has functions such as acting as an anchor point for intra-RAT mobility or inter-RAT mobility, acting as an external PDU session point for interconnecting to DNs (i.e., acting as a gateway between DNs and core network B to forward user data), routing and forwarding packets, an UL CL (Uplink Classifier) ​​function that supports routing multiple traffic flows to a single DN, a branching point function that supports multi-homed PDU sessions, a QoS (Quality of Service) processing function for the user plane, an uplink traffic verification function, downlink packet buffering, and a function to trigger downlink data notification.

[0077] Furthermore, the UPF may also be a gateway for IP communication and / or non-IP communication. The UPF may also have the function of forwarding IP communication, and may also have the function of converting non-IP communication to IP communication. In addition, multiple gateways may be gateways connecting the core network B to a single DN. The UPF may also have connectivity to other NFs, and may connect to each device via other NFs.

[0078] Furthermore, the user plane refers to user data transmitted and received between the UE and the network. The user plane may be transmitted and received using a PDN connection or a PDU session. In addition, in the case of EPS, the user plane may be transmitted and received using the LTE-Uu interface and / or the S1-U interface and / or the S5 interface and / or the S8 interface and / or the SGi interface. Furthermore, in the case of 5GS, the user plane may be transmitted and received via the interface between the UE and the NG RAN and / or the N3 interface and / or the N9 interface and / or the N6 interface. Hereinafter, the user plane may be referred to as U-Plane.

[0079] Furthermore, the control plane refers to the control messages transmitted and received for communication control of the UE, etc. The control plane may be transmitted and received using the NAS (Non-Access-Stratum) signaling connection between the UE and the MME. In addition, in the case of EPS, the control plane may be transmitted and received using the LTE-Uu interface and the S1-MME interface. In addition, in the case of 5GS, the control plane may be transmitted and received using the interface between the UE and the NG RAN and the N2 interface. Hereinafter, the control plane may be referred to as the control plane or the C-Plane.

[0080] Furthermore, the U-Plane (User Plane; UP) may also be a communication channel for sending and receiving user data, and may consist of multiple bearers. Furthermore, the C-Plane (Control Plane; CP) may also be a communication channel for sending and receiving control messages, and may consist of multiple bearers.

[0081] [2.6. Description of Other Devices and / or Functions] Next, we will describe the other devices and / or functions.

[0082] PCF has functions such as providing policy rules.

[0083] Furthermore, UDM has functions such as authentication credential processing, user identification processing, access authentication, registration / mobility management, and subscription management.

[0084] Furthermore, the PCRF is connected to the PGW and / or PDN and has functions for managing QoS for data delivery. For example, it manages the QoS of the communication channel between UE_A10 and the PDN. In addition, the PCRF may also be a device that creates and / or manages PCC (Policy and Charging Control) rules and / or routing rules used by each device when sending and receiving user data.

[0085] Furthermore, the HSS is connected to the MME and / or SCEF and has functions such as managing subscriber information. The subscriber information of the HSS is referenced, for example, when the MME performs access control. In addition, the HSS may be connected to a location management device other than the MME.

[0086] [3. Explanation of Terms and Identification Information Used in Each Embodiment] Next, we will explain in advance the specialized terms and identification information used in each embodiment.

[0087] [3.1. Explanation of Terms Used in Each Embodiment] Next, we will explain the specialized terms used in each embodiment.

[0088] The term "network" refers to at least a portion of Access Network B, Core Network B, and DN. Furthermore, one or more devices included in at least a portion of Access Network B, Core Network B, and DN may be referred to as a network or network device. In other words, the statement that a network performs message transmission and / or processing may also mean that devices within the network (network devices, and / or control devices) perform message transmission and / or processing. Conversely, the statement that devices within the network perform message transmission and / or processing may also mean that the network performs message transmission and / or processing.

[0089] SM (Session Management) messages (also referred to as NAS (Non-Access-Stratum) SM messages) may be NAS messages used in procedures for SM (SM procedures), and may be control messages sent and received between UE_A10 and SMF_A230 via AMF_A240. Furthermore, SM messages may include PDU session establishment request messages, PDU session establishment accept messages, PDU session establishment reject messages, PDU session modification request messages, PDU session modification command messages, PDU session modification complete messages, PDU session modification command reject messages, PDU session modification reject messages, PDU session release request messages, PDU session release reject messages, PDU session release command messages, PDU session release complete messages, etc. Also, procedures for SM or SM procedures may include PDU session establishment procedures, PDU session modification procedures, and UE-requested PDU session release procedures.Each procedure may be initiated from the UE (User Environment) or from the NW (Network).

[0090] Mobility management (MM) messages (also referred to as NAS MM messages) may be NAS messages used for MM procedures, and may be control messages sent and received between UE_A10 and AMF_A240. Furthermore, MM messages may include registration request messages, registration accept messages, registration reject messages, de-registration request messages, de-registration accept messages, configuration update command messages, configuration update complete messages, service request messages, service accept messages, service reject messages, notification messages, notification response messages, etc. Furthermore, the MM procedure or MM procedure may include a Registration procedure, a De-registration procedure, a Generic UE configuration update procedure (also simply called a UE configuration update procedure), an authentication and / or authorization procedure, a Service request procedure, a Paging procedure, and a Notification procedure. Here, the MM procedure may be read as a NAS procedure. In other words, the MM procedure may be a NAS procedure. Moreover, NAS signalling may be performed in the NAS procedure. In other words, NAS signalling may be performed in the MM procedure.

[0091] The 5GS (5G System) service is a connectivity service provided using the core network B190. Furthermore, the 5GS service may be a different service from the EPS service, or it may be a service similar to the EPS service.

[0092] Non-5GS services may be any service other than 5GS services, and may include EPS services and / or non-EPS services.

[0093] The PDN (Packet Data Network) type indicates the type of PDN connection, and includes IPv4, IPv6, IPv4v6, and non-IP. If IPv4 is specified, it means that data will be sent and received using IPv4. If IPv6 is specified, it means that data will be sent and received using IPv6. If IPv4v6 is specified, it means that data will be sent and received using either IPv4 or IPv6. If non-IP is specified, it means that communication will be conducted using a communication method other than IP, rather than IP.

[0094] A PDU (Protocol Data Unit / Packet Data Unit) session can be defined as the relationship between a DN (Digital Network) and an UE (User Environment) that provides PDU connectivity services, but it may also be connectivity established between the UE and an external gateway. In 5GS, the UE can send and receive user data to and from the DN using the PDU session by establishing a PDU session via access network_B and core network_B. Here, this external gateway may be UPF, SCEF, etc. The UE can use the PDU session to send and receive user data with devices such as application servers located on the DN. Each device (UE, and / or access network device, and / or core network device) may manage one or more pieces of identification information associated with each PDU session. These pieces of identification information may include one or more of the following: DNN, QoS rule, PDU session type, application identification information, NSI identification information, access network identification information, and SSC mode, or other information may be included. Furthermore, when multiple PDU sessions are established, the pieces of identification information associated with each PDU session may be the same or different.

[0095] A DNN (Data Network Name) can be any identification information that identifies the core network and / or external networks such as DNs. Furthermore, the DNN can also be used as information to select gateways such as PGW / UPFs that connect to the core network B190. Additionally, the DNN may be equivalent to an APN (Access Point Name).

[0096] The PDU (Protocol Data Unit / Packet Data Unit) session type indicates the type of PDU session, and includes IPv4, IPv6, Ethernet, and Unstructured. Specifying IPv4 indicates that data will be sent and received using IPv4. Specifying IPv6 indicates that data will be sent and received using IPv6. Specifying Ethernet indicates that Ethernet frames will be sent and received. Ethernet may also indicate that IP-based communication will not be used. Specifying Unstructured indicates that data will be sent and received to application servers, etc., on the DN using Point-to-Point (P2P) tunneling technology. P2P tunneling technology may include, for example, UDP / IP encapsulation technology. In addition to the above, IP may also be included as a PDU session type. IP can be specified when the UE (User Environment) can use both IPv4 and IPv6.

[0097] A PLMN (Public Land Mobile Network) is a communication network that provides mobile radio communication services. A PLMN is a network managed by a telecommunications operator, and the operator can be identified by the PLMN ID. A PLMN that matches the MCC (Mobile Country Code) and MNC (Mobile Network Code) of a UE's (International Mobile Subscriber Identity) may be a Home PLMN (HPLMN). Furthermore, a UE may maintain an Equivalent HPLMN list (also called an Equivalent HPLMN; also called an Equivalent PLMN) in its USIM to identify one or more EPLMNs. A PLMN that is different from an HPLMN and / or EPLMN may be a VPLMN (Visited PLMN). A PLMN that has been successfully registered by a UE may be a RPLMN (Registered PLMN).

[0098] A tracking area is one or more ranges managed by the core network that can be represented by the location information of UE_A10. A tracking area may also consist of multiple cells. Furthermore, a tracking area may be the range where control messages such as paging are broadcast, or the range where UE_A10 can move without handover procedures. Additionally, a tracking area may be a routing area, a location area, or something similar. Hereinafter, a tracking area may also be a TA (Tracking Area). A tracking area may be identified by a TAI (Tracking Area Identity) consisting of a TAC (Tracking Area Code) and a PLMN.

[0099] A registration area is a set of one or more TAs assigned by the AMF to a UE. Furthermore, while UE_A10 is moving within one or more TAs included in the registration area, it may move without sending or receiving signals for tracking area updates. In other words, a registration area may be a set of information indicating an area that UE_A10 can move to without performing the tracking area update procedure. A registration area may be identified by a TAI list consisting of one or more TAIs.

[0100] The current TAI is the TAI broadcast by the selected PLMN within the cell where the UE is located or camping. If the cell is a satellite NG-RAN cell broadcasting multiple TACs in the selected PLMN, the UE NAS layer may select the current TAI from among the multiple TACs in the selected PLMN.

[0101] A UE ID is information used to identify a UE (User Account). For example, a UE ID may be a SUCI (Subscription Concealed Identifier), SUPI (Subscription Permanent Identifier), GUTI (Globally Unique Temporary Identifier), IMEI (International Mobile Subscriber Identity), IMEISV (IMEI Software Version), or TMSI (Temporary Mobile Subscriber Identity). Alternatively, a UE ID may be other information configured within an application or network. Furthermore, a UE ID may be information used to identify a user.

[0102] PC5 is a reference point. PC5 may also be a reference point between ProSe-enabled UEs. Furthermore, PC5 may be a reference point for 5G ProSe Direct Discovery, and / or 5G ProSe Direct Communication, and / or 5G ProSe U2N (UE-to-Network) Relay, and / or 5G ProSe U2U (UE-to-UE) Relay.

[0103] A PC5 path may be a communication channel on PC5. A PC5 path may also be a communication channel between ProSe-compatible UEs. Furthermore, a PC5 path may simply refer to PC5 itself. A PC5 path may also be referred to as a PC5 interface.

[0104] A PC5 link may be a PC5 path. A PC5 link may also be called a PC5 direct link, a 5G ProSe direct link, a direct link, or simply a link.

[0105] Uu may be a wireless interface. Furthermore, Uu may be a wireless interface between a 5G AN and an UE.

[0106] A Uu path may be a communication channel on Uu. A Uu path may also be a communication channel between a 5G AN and a UE. Furthermore, a Uu path may be Uu itself. A Uu path may also be referred to as a Uu interface. A Uu path may also be referred to as a Uu link.

[0107] 5G ProSe (Proximity-based Services) may be services provided by 5GS based on UEs that are in close proximity to each other. Furthermore, 5G ProSe may simply be referred to as ProSe.

[0108] A 5G ProSe-enabled UE may be a UE that supports 5G ProSe requirements and related procedures. A 5G ProSe-enabled UE may also be referred to as a ProSe-enabled UE.

[0109] The initiating UE may be the UE that sends the PROSE direct link establishment request message.

[0110] The target UE may be the UE that sends the PROSE direct link establishment acceptance message.

[0111] A remote UE may be a ProSe-enabled UE that communicates with the DN via a U2N relay UE. In this specification, a remote UE is also referred to as a 5G ProSe remote UE or remote UE.

[0112] The remote UE may be a 5G ProSe remote UE, a 5G ProSe layer-2 remote UE, or a 5G ProSe layer-3 remote UE. Furthermore, the 5G ProSe layer-2 remote UE may be a 5G ProSe-compatible UE that communicates with the DN via a 5G ProSe layer-2 UE-to-network relay UE. Similarly, the 5G ProSe layer-3 remote UE may be a 5G ProSe-compatible UE that communicates with the DN via a 5G ProSe layer-3 UE-to-network relay UE.

[0113] A remote UE may also be referred to as a UE that operates as a remote UE.

[0114] Furthermore, the 5G ProSe layer-2 remote UE is a 5G ProSe-compatible UE that communicates with the DN via the 5G ProSe layer-2 U2N relay UE. The 5G ProSe layer-2 remote UE may also be referred to as a layer-2 remote UE.

[0115] Furthermore, a 5G ProSe layer-3 remote UE is a 5G ProSe-compatible UE that communicates with the DN via a 5G ProSe layer-3 UE-to-network relay UE. A 5G ProSe layer-3 remote UE can also be referred to as a layer-3 remote UE.

[0116] A remote UE may be any UE that has been approved to operate as a remote UE.

[0117] A U2N (UE-to-network) relay UE may be a ProSe-enabled UE that provides functionality to support the network connectivity of a remote UE. In this specification, a U2N relay UE is also referred to as a U2N relay UE.

[0118] The U2N relay UE may be a 5G ProSe U2N relay UE, a 5G ProSe layer-2 U2N relay UE, or a 5G ProSe layer-3 U2N relay UE. Furthermore, the 5G ProSe layer-2 U2N relay UE may be a 5G ProSe-compatible UE that provides functionality to support network connectivity for a 5G ProSe layer-2 remote UE via a Layer 2 protocol. Additionally, the 5G ProSe layer-3 U2N relay UE may be a 5G ProSe-compatible UE that provides functionality to support network connectivity for a 5G ProSe layer-3 remote UE via a Layer 3 protocol.

[0119] A U2N relay UE may also be referred to as a UE that operates as a U2N relay UE. Furthermore, a U2N relay UE may also be referred to as a target relay UE. Finally, a U2N relay UE may also be referred to as a U2N relay.

[0120] Furthermore, the 5G ProSe layer-2 U2N relay UE is a 5G ProSe-enabled UE that provides the functionality to support network connectivity for the 5G ProSe layer-2 remote UE via the layer-2 protocol.

[0121] Furthermore, the 5G ProSe layer-3 U2N relay UE is a 5G ProSe-enabled UE that provides the functionality to support network connectivity for the 5G ProSe layer-3 remote UE via the layer-3 protocol.

[0122] Furthermore, the communication method in which a remote UE connects to the network via a U2N relay UE may be referred to as 5G ProSe UE-to-network relaying. 5G ProSe UE-to-network relaying may also be simply referred to as relaying, 5G ProSe UE-to-network relay, relay, or U2N relay.

[0123] A U2N relay UE may be any UE that has been approved to operate as a U2N relay UE.

[0124] A remote UE that supports multi-hop communication may be a ProSe-enabled UE that communicates with the DN via a U2N intermediate UE and a multi-hop U2N relay UE.

[0125] A remote UE that supports multi-hop may be a 5G ProSe remote UE supporting 5G ProSe multi-hop U2N Relay, or a 5G ProSe remote UE supporting 5G ProSe Layer-3 multi-hop U2N Relay.

[0126] Furthermore, the 5G ProSe remote UE supporting 5G ProSe Layer-3 multi-hop U2N Relay may be a 5G ProSe-compatible UE that communicates with the DN via a 5G ProSe Layer-3 U2N intermediate UE and / or a 5G ProSe U2N relay UE supporting 5G ProSe Layer-3 multi-hop U2N Relay. Furthermore, the 5G ProSe remote UE supporting 5G ProSe Layer-3 multi-hop U2N Relay may also be referred to as a multi-hop layer-3 remote UE.

[0127] A remote UE that supports multi-hop may also be referred to as a UE that operates as a multi-hop supporting remote UE. Furthermore, a remote UE that supports multi-hop may also be referred to as a multi-hop remote UE. Additionally, a multi-hop remote UE may be referred to as a 5G ProSe multi-hop remote UE.

[0128] A multi-hop remote UE may be any remote UE that supports multi-hop.

[0129] A multi-hop remote UE may be any UE that is authorized to operate as a multi-hop remote UE.

[0130] A multi-hop remote UE may also be referred to as a 5G ProSe multi-hop remote UE, a 5G ProSe multi-hop layer-2 remote UE, or a 5G ProSe multi-hop layer-3 remote UE.

[0131] A 5G ProSe multi-hop layer-2 remote UE may be a ProSe-enabled UE that communicates with a DN via zero or more 5G ProSe layer-2 intermediate UE-to-Network relay UEs and 5G ProSe multi-hop layer-2 UE-to-Network relay UEs.

[0132] A 5G ProSe multi-hop layer-3 remote UE may be a ProSe-enabled UE that communicates with a DN via zero or more 5G ProSe layer-3 intermediate UE-to-Network relay UEs and 5G ProSe multi-hop layer-3 UE-to-Network relay UEs.

[0133] A U2N (UE-to-network) relay UE that supports multi-hop can be a ProSe-enabled UE that provides functionality to support network connectivity for multi-hop remote UEs.

[0134] A U2N relay UE that supports multi-hop may be a 5G ProSe U2N relay UE supporting 5G ProSe multi-hop U2N Relay, or a 5G ProSe U2N relay UE supporting 5G ProSe Layer-3 multi-hop U2N Relay.

[0135] Furthermore, the 5G ProSe U2N relay UE supporting 5G ProSe Layer-3 multi-hop U2N Relay may be a 5G ProSe-enabled UE that provides the functionality to support network connectivity for the 5G ProSe remote UE supporting 5G ProSe Layer-3 multi-hop U2N Relay via the Layer 3 protocol. Furthermore, the 5G ProSe U2N relay UE supporting 5G ProSe Layer-3 multi-hop U2N Relay may also be referred to as a multi-hop layer-3 U2N relay UE.

[0136] A U2N relay UE that supports multi-hop may also be referred to as a UE that operates as a U2N relay UE that supports multi-hop. Furthermore, a U2N relay UE that supports multi-hop may also be referred to as a multi-hop U2N relay UE. Furthermore, a multi-hop U2N relay UE may also be referred to as a multi-hop U2N relay. Finally, a multi-hop U2N relay UE may also be referred to as a 5G ProSe multi-hop U2N relay UE.

[0137] A multi-hop U2N relay UE may be a U2N relay UE that supports multi-hop.

[0138] A multi-hop U2N relay UE may be any UE that is authorized to operate as a multi-hop U2N relay UE.

[0139] The multi-hop U2N relay UE may also be referred to as the 5G ProSe multi-hop UE-to-network relay UE, the 5G ProSe multi-hop layer-2 UE-to-network relay UE, or the 5G ProSe multi-hop layer-3 UE-to-network relay UE.

[0140] A 5G ProSe multi-hop UE-to-Network relay UE may be a 5G ProSe UE-to-network relay UE that supports 5G ProSe multi-hop UE-to-network relay.

[0141] A 5G ProSe multi-hop layer-2 UE-to-network relay UE may be a 5G ProSe layer-2 UE-to-network relay UE that supports 5G ProSe multi-hop layer-2 UE-to-network relay.

[0142] A 5G ProSe multi-hop layer-3 UE-to-network relay UE may be a 5G ProSe layer-3 UE-to-network relay UE that supports 5G ProSe multi-hop layer-3 UE-to-network relay.

[0143] A U2N (UE-to-network) intermediate UE may be a ProSe-enabled UE that provides functionality to support connectivity between a multi-hop remote UE and a multi-hop U2N relay UE.

[0144] The U2N intermediate UE may be a 5G ProSe U2N intermediate UE or a 5G ProSe layer-3 U2N intermediate UE. Furthermore, the 5G ProSe layer-3 U2N intermediate UE may be a 5G ProSe-enabled UE that provides functionality to support network connectivity for a 5G ProSe remote UE supporting a 5G ProSe Layer-3 multi-hop U2N Relay via a Layer 3 protocol and / or a 5G ProSe U2N relay UE supporting a 5G ProSe Layer-3 multi-hop U2N Relay. The 5G ProSe layer-3 U2N intermediate UE may also be referred to as a layer-3 U2N intermediate UE.

[0145] A U2N intermediate UE may also be referred to as a UE that operates as a U2N intermediate UE. A U2N intermediate UE may also be referred to as an intermediate U2N UE.

[0146] Furthermore, there may be one or more U2N intermediate UEs. For example, between a multi-hop remote UE and a multi-hop U2N relay UE, there may be a first U2N intermediate UE and a second U2N intermediate UE, from left to right.

[0147] Furthermore, the U2N intermediate UE may also be referred to as Relay participated in multi-hop U2N relaying, or as 5G ProSe Intermediate Relay. The U2N intermediate UE may also be referred to as multi-hop U2N relay UE, or as 5G ProSe multi-hop U2N relay UE. The U2N intermediate UE may also be referred to as 5G ProSe layer-3 multi-hop U2N relay UE. Furthermore, the U2N intermediate UE may also be referred to as 5G ProSe L3 (Layer-3) Intermediate relay, or as 5G ProSe L3 (Layer-3) Intermediate relay UE.

[0148] Furthermore, the U2N intermediate UE may also be referred to as the 5G ProSe Intermediate U2N Relay UE or the 5G ProSe Intermediate U2N Relay.

[0149] A U2N intermediate UE may be any UE authorized to operate as a U2N intermediate UE. Hereinafter, a U2N intermediate UE will also be referred to as an intermediate UE.

[0150] The U2N intermediate UE may also be referred to as the 5G ProSe intermediate UE-to-network relay UE, the 5G ProSe layer-2 intermediate UE-to-network relay UE, or the 5G ProSe layer-3 intermediate UE-to-network relay UE.

[0151] A 5G ProSe intermediate UE-to-network relay UE may be a ProSe-enabled UE that provides the functionality to support network connectivity for multi-hop remote UEs by using other ProSe-enabled UEs and a PC5 reference point. The 5G ProSe intermediate UE-to-network relay UE may be located on the path between the multi-hop remote UE and the multi-hop U2N relay UE.

[0152] A 5G ProSe layer-2 intermediate UE-to-network relay UE may be a ProSe-enabled UE that provides the ability to support connection to a network of 5G ProSe multi-hop layer-2 remote UEs using a PC5 reference point with other ProSe-enabled UEs via the layer-2 protocol.

[0153] A 5G ProSe layer-3 intermediate UE-to-network relay UE may be a ProSe-enabled UE that provides the ability to support connection to a network of 5G ProSe multi-hop layer-3 remote UEs using other ProSe-enabled UEs and PC5 reference points via the layer-3 protocol.

[0154] An End UE may be a ProSe-enabled UE that communicates with another ProSe-enabled UE via a U2U (UE-to-UE) relay UE. An End UE may be a ProSe-enabled UE that communicates with another ProSe-enabled UE via a U2U relay UE. In this specification, a 5G ProSe End UE is also referred to as an End UE. In this specification, a UE that operates as an initiating UE is also referred to as a source End UE. In this specification, a destination End UE is also referred to as a target End UE.

[0155] The End UE may be a 5G ProSe end UE, a 5G ProSe layer-2 end UE, or a 5G ProSe layer-3 end UE. Furthermore, the 5G ProSe layer-2 end UE may be a 5G ProSe-compatible UE that communicates with other 5G ProSe-compatible UEs via a 5G ProSe layer-2 UE-to-UE relay UE. Similarly, the 5G ProSe layer-3 end UE may be a 5G ProSe-compatible UE that communicates with other 5G ProSe-compatible UEs via a 5G ProSe layer-3 UE-to-UE relay UE.

[0156] An End UE may also be referred to as a UE that acts as an End UE. More specifically, an End UE may consist of a source End UE and a destination End UE (or target End UE). Here, the source end UE may be the end UE that sends the request message, and the target end UE may be the end UE that receives the request message.

[0157] Furthermore, the 5G ProSe layer-2 end UE is a 5G ProSe-enabled UE that communicates with another 5G ProSe-enabled UE via the 5G ProSe layer-2 U2U relay UE.

[0158] Furthermore, the 5G ProSe layer-3 end UE is a 5G ProSe-enabled UE that communicates with another 5G ProSe-enabled UE via the 5G ProSe layer-3 U2U relay UE.

[0159] A multi-hop End UE may be an End UE that supports multi-hop. A multi-hop UE may be a 5G ProSe multi-hop layer-3 end UE. A multi-hop End UE may be a 5G ProSe Layer-3 End UE that supports 5G ProSe Layer-3 multi-hop UE-to-UE Relay.

[0160] A U2U (UE-to-UE) relay UE may be a ProSe-enabled UE that provides functionality to support connectivity between two end UEs. One or more U2U relay UEs may be ProSe-enabled UEs that provide functionality to support connectivity between two end UEs.

[0161] The UE-to-UE relay (U2U Relay) UE may be a 5G ProSe U2U relay UE, a 5G ProSe layer-2 U2U relay UE, or a 5G ProSe layer-3 U2U relay UE. In this specification, the 5G ProSe UE-to-UE Relay is also referred to simply as U2U Relay or U2U Relay UE. Furthermore, when describing multiple U2U Relay UEs in this specification, each U2U Relay UE is also referred to as U2U Relay UE#1, U2U Relay UE#2, etc., to distinguish them.

[0162] Here, the 5G ProSe layer-2 U2U relay UE may be a 5G ProSe-enabled UE that provides the functionality to support connectivity between two 5G ProSe layer-2 end UEs via a Layer 2 protocol.

[0163] Furthermore, the 5G ProSe layer-3 U2U relay UE may be a 5G ProSe-enabled UE that provides the functionality to support connectivity between two 5G ProSe layer-3 end UEs via the Layer 3 protocol.

[0164] A U2U relay UE may also be referred to as a UE that operates as a U2U relay UE. A U2U relay UE may also be referred to as a U2U relay.

[0165] Furthermore, the 5G ProSe layer-2 U2U relay UE is a 5G ProSe-enabled UE that provides the functionality to support connectivity between two 5G ProSe layer-2 end UEs via the layer-2 protocol.

[0166] Furthermore, the 5G ProSe layer-3 U2U relay UE is a 5G ProSe-enabled UE that provides the functionality to support connectivity between two 5G ProSe layer-3 end UEs via the layer-3 protocol.

[0167] Furthermore, a 5G ProSe multi-hop layer-3 UE-to-UE relay UE may be a 5G ProSe layer-3 UE-to-UE relay UE that supports 5G ProSe multi-hop layer-3 UE-to-UE relay.

[0168] Furthermore, a 5G ProSe multi-hop layer-2 UE-to-UE relay UE may be a 5G ProSe layer-2 UE-to-UE relay UE that supports 5G ProSe multi-hop layer-2 UE-to-UE relay.

[0169] A 5G ProSe multi-hop L3 U2U relay UE may be a 5G ProSe multi-hop layer-3 UE-to-UE relay UE, or a 5G ProSe multi-hop layer-2 UE-to-UE relay UE.

[0170] The discovery procedure may be a procedure for detecting and identifying another nearby UE using NR radio signals. More specifically, the discovery procedure may be a 5G ProSe direct discovery procedure, a 5G ProSe U2N relay discovery procedure, or a 5G ProSe multi-hop U2U relay discovery procedure. The discovery procedure may also be referred to as 5G ProSe direct discovery, 5G ProSe multi-hop discovery, or 5G ProSe discovery.

[0171] Multi-hop communication may refer to communication via two or more UEs. Alternatively, multi-hop communication may refer to a UE communicating with another UE or network via two or more other UEs.

[0172] More specifically, for example, multi-hop communication may be communication between End UEs via two or more U2U (UE-to-UE) Relay UEs.

[0173] Furthermore, for example, when a multi-hop remote UE connects to a network via one or more U2N intermediate UEs and a multi-hop U2N relay UE, this may be referred to as multi-hop communication. In this case, the multi-hop remote UE and / or U2N intermediate UE and / or multi-hop U2N relay UE may support multi-hop.

[0174] Here, multi-hop communication may be UE-to-network relay multi-hop communication, UE-to-UE relay multi-hop communication, 5G ProSe U2N(UE-to-network) relay multi-hop communication, or 5G ProSe U2U(UE-to-UE) relay multi-hop communication.

[0175] Multi-hop communication may simply be referred to as multi-hop. Furthermore, a UE that supports multi-hop may be a multi-hop UE. Also, a UE that supports multi-hop may be a UE that supports operating as a multi-hop UE.

[0176] The multi-hop relay may be a 5G ProSe multi-hop U2N relay, a 5G ProSe multi-hop layer-2 U2N relay, a 5G ProSe multi-hop layer-3 U2N relay, a 5G ProSe multi-hop U2U relay, a 5G ProSe multi-hop layer-2 U2U relay, or a 5G ProSe multi-hop layer-3 U2U relay.

[0177] Furthermore, a UE that supports multi-hop communication may be a multi-hop UE. Also, a UE that supports multi-hop communication may be a UE that supports operating as a multi-hop UE. More specifically, for example, a UE that supports multi-hop communication may be a 5G ProSe U2U (UE-to-UE) Relay UE and / or a 5G ProSe U2N (UE-to-Network) Relay UE. Or, for example, a UE that supports multi-hop communication may be a 5G ProSe U2U (UE-to-UE) Relay UE and / or a 5G ProSe U2N (UE-to-Network) Relay UE and / or a 5G ProSe U2U Relay UE and / or a 5G ProSe U2U End UE.

[0178] Supporting multi-hop means supporting 5G ProSe multi-hop U2N relay and / or U2U relay, supporting 5G ProSe multi-hop layer-2 U2N relay, supporting 5G ProSe multi-hop layer-3 U2N relay, supporting 5G ProSe multi-hop layer-2 U2U relay, and supporting 5G ProSe multi-hop layer-3 U2U relay.

[0179] The Application Layer ID is an identifier that identifies a 5G ProSe-enabled UE within the context of a particular application.

[0180] The Relay Service Code (RCS) may be information used to identify the connection services provided by U2U-relay and / or U2N relay, and the authorized users to whom U2U-relay and / or U2N relay provides these services. In this specification, the Relay Service Code is also referred to as RCS.

[0181] Furthermore, for example, the relay service code may be information used to identify communication or communication services between End UEs via a multi-hop communication path using one or more U2U-relay UEs.

[0182] Furthermore, the relay service code may select security policies and information necessary for authentication and authorization between the End UE and the U2U relay UE.

[0183] Furthermore, the relay service code may be information included in the configuration parameters for U2U-relay and / or U2N relay. The relay service code may be information included in the configuration parameters for U2U-relay and / or U2N relay. The relay service code may be information included in the configuration parameters for End UE.

[0184] PQI (PC5 5QI) may be 5QI (5G QoS Identifier) ​​via the PC5 interface.

[0185] 5QI is a quantity used as a reference to specific QoS forwarding operations (such as packet loss rate and packet delay budget; PDB) provided to 5G QoS flows. This may be implemented in the access network by 5QI referencing node-specific parameters (such as scheduling weights, admission thresholds, queue management thresholds, and link layer protocol configurations) that control QoS forwarding processing.

[0186] ProSeP may be a 5G ProSe policy, or information that indicates or includes a 5G ProSe policy. Furthermore, ProSeP may be a UE policy for ProSe, or a UE policy for ProSe services. ProSeP may also be provided from the network to the UE through the network-requested UE policy management procedure and / or the UE-requested ProSeP provision procedure described below. Furthermore, ProSeP may be information determined by the PCF and provided to the UE via the AMF. ProSeP may also be referred to as a ProSe policy.

[0187] Here, ProSeP may include, for example, a UE policy for 5G ProSe direct discovery, a UE policy for 5G ProSe direct communications, a UE policy for 5G ProSe UE-to-network relay, a UE policy for 5G ProSe usage information reporting, a UE policy for 5G ProSe UE-to-UE relay, a UE policy for 5G ProSe multi-hop UE-to-network relay, and / or a UE policy for 5G ProSe multi-hop UE-to-UE relay.

[0188] Furthermore, for example, a UE policy for 5G ProSe multi-hop UE-to-network relay may be a UE policy for 5G ProSe multi-hop UE-to-network relay UE, a UE policy for 5G ProSe intermediate UE-to-network relay UE, and / or a UE policy for 5G ProSe multi-hop UE-to-network remote UE.

[0189] Here, the UE policy for 5G ProSe multi-hop UE-to-UE relay may be the UE policy for 5G ProSe multi-hop UE-to-UE relay UE, and / or the UE policy for 5G ProSe multi-hop UE-to-UE end UE.

[0190] Furthermore, ProSeP may include QoS for relay services. Here, QoS for relay services may be QoS for relay services between endpoints of communications for ProSe services. This is also referred to as End-to-End QoS for a relay service, or end-to-end QoS. In this specification, unless otherwise specified, End-to-End QoS for relay services will be referred to as end-to-end QoS.

[0191] Here, in the ProSe multi-hop L3 relay service, end-to-end QoS may only be satisfied if the QoS requirements are appropriately translated and satisfied between each UE. In other words, in ProSe multi-hop communication, the QoS between endpoint UEs and between endpoint UEs and relay UEs, or between relay UEs, i.e., the QoS per hop, must be appropriately configured.

[0192] Here, the end-to-end QoS for the relay service may be, for example, QoS between U2U end UEs (e.g., between a source end UE and a target end UE), or QoS between a 5G ProSe remote UE and a U2N relay UE.

[0193] More specifically, for example, in the case of a 5G ProSe L3 U2N relay service, multi-hop adjustment is performed considering the number of hops between the endpoint 5G ProSe L3 remote UEs, and the maximum PDB (packet delay budget) applied to the PC5 links on each adjacent hop may be derived from end-to-end QoS information based on a hop adjustment coefficient (for example, if the number of hops is 5, it may be 1 / 5 of the standardized PDB value of PQI).

[0194] Furthermore, for example, in the case of a 5G ProSe L3 U2U relay service, when the source end UE sets up the PC5 QoS flow, it may provide end-to-end QoS parameters to the 5G ProSe L3 U2U relay. Each 5G ProSe L3 U2U relay may then divide the QoS parameters according to the received QoS information into the QoS parameters of the previous hop and the QoS parameters from itself to the target end UE. The 5G ProSe L3 U2U relay may then send the remaining PC5 QoS parameters to the next hop. Each 5G ProSe L3 U2U relay may divide the PDB evenly across the hops, or it may divide it according to its own implementation (up to a value divided evenly by the number of hops). The target end UE and each 5G ProSe L3 U2U relay also send the accepted PC5 QoS parameters and optionally the cumulative QoS parameters to the previous hop during the L2 link establishment or modification procedure. The accepted PC5 QoS parameters may be determined based on the QoS parameters of the previous hop, taking into account the accumulated QoS received from the next hop, as described above.

[0195] [3.2. Description of Identification Information in Each Embodiment] Next, the identification information used in each procedure of each embodiment will be described. Note that each piece of identification information may be control information or simply information. In this specification, identification information will also be referred to as control information or simply information.

[0196] In this embodiment, the first identification information is information indicating the UE's capability with respect to 5G ProSe functionality. Furthermore, the first identification information may be information indicating the UE's capability with respect to 5G ProSe multi-hop communication functionality. More specifically, for example, the first identification information may be information indicating whether the UE supports operating as a 5G ProSe multi-hop layer-2 UE-to-network-relay UE, and / or a 5G ProSe multi-hop layer-2 UE-to-network-remote UE, and / or a 5G ProSe layer-2 intermediate relay UE, and / or a 5G ProSe multi-hop layer-3 UE-to-network-relay UE, and / or a 5G ProSe multi-hop layer-3 UE-to-network-remote UE, and / or a 5G ProSe layer-3 intermediate relay UE, and / or a 5G ProSe multi-hop layer-3 UE-to-UE relay UE, and / or a 5G ProSe multi-hop layer-3 end UE.

[0197] Furthermore, the first identification information may be information that the UE includes in the registration request message and sends to the network. In other words, by including the first identification information in the registration request message, the UE may indicate to the network whether or not it supports one or more functions indicated by the first information.

[0198] Furthermore, the first identification information may be information contained in a 5GMM (5GS mobility management) capability information element (IE), or information contained in an IE different from the 5GMM capability IE. Alternatively, the first information may be a combination of information contained in a 5GMM (5GS mobility management) capability information element (IE) and information contained in an IE different from the 5GMM capability IE.

[0199] Furthermore, the first identification information further includes "5G ProSe direct discovery" and / or "5G ProSe Direct Communication" and / or "5G ProSe L2 U2N relay (5G ProSe Layer-2 UE-to-Network Relay)" and / or "5G ProSe L3 U2N relay (5G ProSe Layer-3 UE-to-Network Relay)" and / or "5G ProSe L2 remote UE" and / or "5G ProSe L3 remote UE" and / or "5G ProSe L2 U2U relay UE (5G ProSe Layer-2 UE-to-UE Relay UE)" and / or "5G ProSe L2 The documentation may include information indicating whether the UE supports operating as "End UE (5G ProSe Layer-2 End UE)" and / or "5G ProSe L3 End UE (5G ProSe Layer-3 End UE)," or whether the UE supports these functions or operations.

[0200] Here, for example, if the UE supports one or more functions related to the 5G ProSe multi-hop communication service, the UE may set or configure information indicating support for such functions in the corresponding bits of the first identification information included in the registration request message. In addition, if such functions are supported, the bit corresponding to those functions may be set to "1".

[0201] In this embodiment, the tenth identification information may be a policy for a UE that supports 5G ProSe multi-hop services. Alternatively, the tenth identification information may be a 5G ProSe Policy (ProSeP). Alternatively, the tenth identification information may be information included in UE Policies IE. Furthermore, the tenth identification information may be end-to-end QoS for multi-hop relay services included in ProSeP. The tenth identification information may also be included in a MANAGE UE POLICY COMMAND message and sent to the UE from the network or from the PCF via the AMF.

[0202] More specifically, for example, the tenth identification information may be a UE policy (ProSeP) for "5G ProSe multi-hop U2N relay UE (5G ProSe multi-hop UE-to-network relay UE)", and / or "5G ProSe intermediate U2N relay UE (5G ProSe intermediate UE-to-network relay UE)", and / or "5G ProSe multi-hop U2N remote UE (5G ProSe multi-hop UE-to-network remote UE)", and / or "5G ProSe multi-hop U2U relay UE (5G ProSe multi-hop UE-to-UE relay UE)", and / or "5G ProSe multi-hop U2U end UE (5G ProSe multi-hop UE-to-UE end UE)".

[0203] Here, the tenth identification information may be a ProSeP corresponding to the first identification information. More specifically, for example, if a UE sends a registration request message containing the first identification information to the network, and part or all of the first identification information is accepted by the network, the tenth identification information may be a ProSeP corresponding to part or all of the first information accepted by the network.

[0204] Furthermore, for example, a tenth identification information including end-to-end QoS for a multi-hop relay service may be provided only to UEs that support the first identification information operating as a 5G ProSe multi-hop layer-3 UE-to-network-relay UE and / or a 5G ProSe multi-hop layer-3 UE-to-network-remote UE and / or a 5G ProSe multi-hop layer-3 end UE.

[0205] The 11th identification information in this embodiment may be information indicating that the end-to-end QoS requirement for the L3 multi-hop ProSe U2U communication channel that the UE is attempting to establish is not met, and / or the end-to-end QoS for the L3 multi-hop ProSe U2U communication that the UE is attempting to establish is not enabled, and / or the end-to-end QoS for the L3 multi-hop ProSe U2U communication that the UE is attempting to establish is insufficient, and / or the End-to-End QoS value does not meet the requirements for the multi-hop communication channel that the UE is attempting to establish, and / or the end-to-end QoS parameters assigned from the network are insufficient, and / or the QoS between hops of the direct link being established is insufficient. Furthermore, the 11th identification information may be information indicating a failure to approve the end-to-end QoS.

[0206] Here, the eleventh identifier may be a cause value. More specifically, for example, the eleventh identifier may be information contained in the PC5 signaling protocol cause information element (IE).

[0207] Furthermore, the 11th identification information may be information that is included in a message by the UE and transmitted to the network in a Network-requested UE policy management procedure or a UE-requested ProSeP provisioning procedure.

[0208] More specifically, for example, the 11th identification information may be information that the UE includes in a Manage UE Policy command reject message and sends to the network. Alternatively, for example, the 11th identification information may be information included in the PC5 signaling protocol reason information element that is included in the Manage UE Policy command reject message. In other words, the 11th identification information may be information that is included in a message sent from the UE to the network (AMF, or PCF).

[0209] In this embodiment, the 12th identification information may be information indicating the number of hops calculated by the UE from the end-to-end QoS or cumulative QoS value, and / or information indicating a request for a new End-to-End QoS value, and / or information indicating the end-to-end QoS value desired by the UE, and / or information indicating the maximum number of hops. Furthermore, the 12th identification information may be information indicating a request for a new ProSeP including new end-to-end QoS parameters from the network or PCF.

[0210] Here, the 12th piece of identification information may be, for example, indication information for showing a UE's request or preference to the network.

[0211] Furthermore, the 12th identification information may be included in a message sent to the network by the UE during a Network-requested UE policy management procedure. More specifically, for example, the 12th identification information may be information included in a UE policy provisioning request message sent to the network by the UE.

[0212] The 21st identification information in this embodiment may be information indicating that the end-to-end QoS requirement of the L3 multi-hop ProSe U2U communication channel that the UE is attempting to establish is not met, and / or that the end-to-end QoS of the L3 multi-hop ProSe U2U communication that the UE is attempting to establish is not valid, and / or that the end-to-end QoS of the L3 multi-hop ProSe U2U communication that the UE is attempting to establish is insufficient, and / or that the End-to-End QoS value does not meet the requirements of the multi-hop communication channel that the UE is attempting to establish, and / or that the end-to-end QoS parameter assigned from the network is insufficient, and / or that the QoS between hops of the direct link being established is insufficient, and / or information indicating the number of hops calculated by the UE from the end-to-end QoS or cumulative QoS value, and / or information indicating that a new End-to-End QoS value is requested, and / or information indicating the end-to-end QoS value desired by the UE, and / or information indicating the maximum number of hops.

[0213] Here, the 21st identification information may be information included in messages sent and received between UEs that constitute the communication path of the 5G ProSe multihop service. Here, the sending and receiving of messages containing the 12th identification information between UEs that constitute the communication path of the 5G ProSe multihop service may be performed, for example, between a U2U relay UE and a source-end UE, or between two U2U relay UEs, or between a U2N intermediate UE and a U2N remote UE, or between two U2N intermediate UEs.

[0214] Furthermore, the 21st identification information may be included in messages by the UE and transmitted and received between UEs in each procedure of the Procedure for 5G ProSe multi-hop U2U relay discovery over PC5 interface with model B, or the Procedure for 5G ProSe multi-hop U2N relay discovery over PC5 interface with model B. More specifically, for example, the 21st identification information may be information that the UE includes in the ProSe PC5 Discovery Response (ProSe PC5 DISCOVERY) message.

[0215] In this specification, the procedure for multi-hop U2U relay discovery over a PC5 interface using Model B, or the procedure for multi-hop U2N relay discovery over a PC5 interface using Model B, will also be referred to as the multi-hop U2U Model B discovery procedure, the multi-hop U2N Model B discovery procedure, the multi-hop Model B discovery procedure, the Model B discovery procedure, or simply the discovery procedure.

[0216] The 31st identification information in this embodiment may be information indicating that the end-to-end QoS requirements of the L3 multi-hop ProSe U2U communication channel that the UE is attempting to establish are not met, and / or the end-to-end QoS of the L3 multi-hop ProSe U2U communication that the UE is attempting to establish is not enabled, and / or the end-to-end QoS of the L3 multi-hop ProSe U2U communication that the UE is attempting to establish is insufficient, and / or the End-to-End QoS value does not meet the requirements of the multi-hop communication channel that the UE is attempting to establish, and / or the end-to-end QoS parameters assigned from the network are insufficient, and / or the inter-hop QoS of the direct link being established is insufficient.

[0217] Here, the 31st identifier may be a cause value. More specifically, for example, the 31st identifier may be information contained in the PC5 signaling protocol cause (PC5 signaling protocol cause, or PC5 signaling protocol cause 2) Information Element (IE).

[0218] Furthermore, the 31st identification information may be information that is included in a message by the UE during the ProSe direct link establishment procedure and transmitted to other UEs that constitute the 5GM ProSe multihop communication channel.

[0219] More specifically, for example, the 31st identification information may be information that the UE includes in a ProSe Direct Link Establishment Reject message and transmits to other UEs that constitute the 5GM ProSe multihop communication channel.

[0220] The 32nd identification information in this embodiment may be information indicating the number of hops calculated by the UE from the end-to-end QoS or cumulative QoS value, and / or information indicating a request for a new End-to-End QoS value, and / or information indicating the end-to-end QoS value desired by the UE, and / or information indicating the maximum number of hops.

[0221] Here, the 32nd piece of identification information may be, for example, indication information for showing a UE's request or preference to the network.

[0222] Furthermore, the 32nd identification information may be information that is included in a message by the UE during the ProSe direct link establishment procedure and transmitted to other UEs that constitute the 5GM ProSe multihop communication channel.

[0223] More specifically, for example, the 32nd identification information may be information that the UE includes in a ProSe Direct Link Establishment Reject message and transmits to other UEs that constitute the 5GM ProSe multihop communication channel.

[0224] The 41st identification information in this embodiment may be information indicating that the end-to-end QoS requirement of the L3 multi-hop ProSe U2U communication channel that the UE is attempting to establish is not met, and / or that the end-to-end QoS of the L3 multi-hop ProSe U2U communication that the UE is attempting to establish is not valid, and / or that the end-to-end QoS of the L3 multi-hop ProSe U2U communication that the UE is attempting to establish is insufficient, and / or that the End-to-End QoS value does not meet the requirements of the multi-hop communication channel that the UE is attempting to establish, and / or that the end-to-end QoS parameter assigned from the network is insufficient, and / or that the QoS between hops of the direct link being established is insufficient, and / or information indicating the number of hops calculated by the UE from the end-to-end QoS or cumulative QoS value, and / or information indicating a request for a new End-to-End QoS value, and / or information indicating the end-to-end QoS value desired by the UE, and / or information indicating the maximum number of hops.

[0225] Here, the 41st identification information may be information included in messages sent and received between UEs that constitute the communication path of the ProSe multihop service. Here, the sending and receiving of messages containing the 12th identification information between UEs that constitute the communication path of the ProSe multihop service may be performed, for example, between a U2U relay UE and a source-end UE, or between two U2U relay UEs, or between a U2N intermediate UE and a U2N remote UE, or between two U2N intermediate UEs.

[0226] Furthermore, the 41st identification information may be included in a message by the UE during the 5G ProSe direct link release procedure and transmitted between UEs. More specifically, for example, the 41st identification information may be information that the UE includes in the ProSe direct PROSE DIRECT LINK RELEASE message.

[0227] Details of the behavior of the UE and network based on one or more combinations of the above identification information from the 1st to the 41st are not limited to those described in this chapter, but are also described in Chapter 4 and / or Chapter 5.

[0228] [4. Description of Procedures Used in Each Embodiment] Next, the procedures used in each embodiment will be described. Here, the procedures used in each embodiment may include registration procedures, network request UE policy management procedures, and UE request ProSeP provision procedures.

[0229] Herein, in this specification, the network request UE policy management procedure and / or the UE request ProSeP provision procedure will also be referred to simply as the ProSeP provision procedure.

[0230] In each embodiment, the explanation will be based on the example where the HSS and UDM, PCF and PCRF, SMF and PGW-C, and UPF and PGW-U are configured as the same device (i.e., the same physical hardware, the same logical hardware, or the same software), as shown in Figure 2. However, the contents described in this embodiment are also applicable when these are configured as different devices (i.e., different physical hardware, different logical hardware, or different software). For example, data may be transmitted and received directly between them, or data may be transmitted and received via the N26 interface between the AMF and MME, or data may be transmitted and received via the UE.

[0231] [4.1. Registration Procedure] The registration procedure will be explained using Figure 6.

[0232] The registration procedure is initiated and executed by the UE in 5GS. Hereafter, in this section, this procedure will also be referred to as the registration procedure. The registration procedure is a procedure initiated by the UE to register with access network_B and / or core network_B and / or DN. The UE can execute this procedure at any time, for example, when powering on, if it is not registered with the network. In other words, the UE can start this procedure at any time as long as it is in the unregistered state (RM-DEREGISTERED state). Furthermore, each device (especially the UE and AMF) can transition to the registered state (RM-REGISTERED state) based on the completion of the registration procedure.

[0233] Furthermore, the registration procedure may be an initial registration initiated by the UE, or a registration procedure for mobility and periodic registration update, or a mobility and periodic registration update, or a mobility registration update procedure. Here, the mobility registration update procedure may also be called a registration procedure for mobility updates. These registration procedures may also be MM procedures.

[0234] Furthermore, the registration procedure may also be a procedure for updating the location registration information of the UE in the network, and / or for the UE to periodically notify the network of the status of the UE, and / or for updating specific parameters related to the UE in the network.

[0235] Furthermore, in this procedure, each UE may be permitted by the network to use multi-hop communication or multi-hop functionality via two or more U2U relay UEs. In addition, after the completion of this procedure, each UE may, based on permission from the network, establish a ProSe Layer-3 multi-hop UE-to-UE Relay communication path and initiate or execute ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0236] A UE may initiate the registration process when it moves across TAs. More specifically, a UE may initiate a Mobility Registration Update process to re-register when it moves to a TA different from the one indicated in its TA list. Furthermore, a UE may initiate this process when a running timer expires. Furthermore, a UE may initiate the registration process when it is necessary to update the context of each device due to disconnection or invalidation of a PDU session. Furthermore, a UE may initiate the registration process if there is a change in capability information and / or preferences related to the establishment of a UE PDU session. Furthermore, a UE may initiate the registration process periodically. Furthermore, a UE may initiate the registration process based on the completion of a UE configuration update process. Note that a UE can perform the registration process at any time it chooses, not limited to these.

[0237] Furthermore, a UE may initiate a registration process periodically, even if it is already registered. In other words, a UE may initiate a registration process based on the expiration of a timer. In other words, a registration process performed periodically may be a Periodic Registration Update process.

[0238] Furthermore, the registration procedure performed based on the mobility of the UE and the registration procedure performed periodically will also be referred to as the registration procedure for mobility and registration renewal, or the registration renewal procedure. In other words, the registration procedure for mobility and registration renewal may be a registration procedure performed based on the mobility of the UE, or it may be a registration procedure performed periodically. Furthermore, the registration procedure for mobility and registration renewal may be a registration procedure performed based on a configuration update of the UE. Furthermore, the registration procedure for mobility and registration renewal may be a registration procedure performed to establish a communication channel for sending and receiving user data. Furthermore, the registration procedure for mobility and registration renewal may be a registration procedure performed based on a request from the network. In other words, the registration procedure for mobility and registration renewal may be a registration procedure other than the initial registration procedure. Hereinafter, the registration procedure for mobility and registration renewal may be referred to as "this procedure".

[0239] Next, we will explain each step of the registration process. Note that the registration process described below may refer to the initial registration process or the registration process for mobility and registration renewal.

[0240] First, the UE initiates the registration process by sending a Registration request message to the AMF (S600)(S602)(S604). Specifically, the UE sends an RRC message containing the Registration request message to the 5G AN (or gNB) (S600). The Registration request message is a NAS message. The RRC message may be a control message sent and received between the UE and the 5G AN (or gNB). NAS messages are processed at the NAS layer, and RRC messages are processed at the RRC layer. The NAS layer is a higher layer than the RRC layer.

[0241] Here, the UE may include the first identification information in the registration request message and / or RRC message and transmit it to the network. More specifically, the UE may include the first identification information in the registration request message and / or RRC message, or it may include it in a different control message, for example, a control message at a lower layer than the RRC layer (e.g., MAC layer, RLC layer, PDCP layer).

[0242] A specific example of the first identification information that the UE includes in the registration request message will be detailed in Chapter 5.

[0243] In this case, if multiple pieces of identification information are sent and received between the UE and the network, two or more of these pieces of identification information may be configured as one or more pieces of identification information. Furthermore, the information indicating support for each function and the information indicating a request to use each function may be sent and received as the same piece of identification information, or as different pieces of identification information.

[0244] Furthermore, the UE may indicate to the network that it supports the functions indicated by the first identification information, or it may indicate the UE's requests, by sending a registration request message to the network that includes the first identification information.

[0245] Furthermore, the UE may include each piece of identification information in the registration request message and send it, thereby indicating to the network what the identification information included in the registration request message represents.

[0246] Furthermore, the UE may choose and decide whether or not to include the first identification information in the registration request message based on subscriber information, and / or network status, and / or user registration information, and / or context held by the UE.

[0247] When a 5G AN (or gNB) receives an RRC message containing a registration request message, it selects an AMF to forward the registration request message (S602). The 5G AN (or gNB) may select an AMF based on the information contained in the registration request message and / or RRC message. The 5G AN (or gNB) extracts the registration request message from the received RRC message and forwards it to the selected AMF (S604).

[0248] The AMF receives a registration request message from the UE that includes the first identification information. Upon receiving the registration request message from the UE that includes the first identification information, the AMF may recognize and store what the first identification information contained in the registration request message means or what it represents.

[0249] Furthermore, AMF may determine, based on the first identification information received from the UE, whether the UE is authorized to use the 5G ProSe L3 multihop communication service. Also, AMF may authorize the UE to use the 5G ProSe L3 multihop communication service based on the first identification information received from the UE.

[0250] Furthermore, the AMF may transmit the first identification information received from the UE to the PCF. The AMF may also transmit the first identification information received from the UE and approved by the network or the AMF to the PCF.

[0251] When the AMF receives a registration request message, it can perform a first conditional determination. This first conditional determination determines whether the network (or the AMF) will accept the UE's request. If the first conditional determination is true, the AMF initiates the procedure shown in Figure 6(A); if the first conditional determination is false, it initiates the procedure shown in Figure 6(B).

[0252] Furthermore, the first condition determination may be performed based on the receipt of a registration request message, and / or each piece of identification information contained in the registration request message, and / or subscriber information, and / or network capability information, and / or operator policy, and / or network status, and / or user registration information, and / or context held by AMF, etc. For example, if the network permits the UE's request, the first condition determination is true, and if the network does not permit the UE's request, the first condition determination may be false. Also, if the network to which the UE is registered, and / or the devices within the network, support the function requested by the UE, the first condition determination is true, and if they do not support the function requested by the UE, the first condition determination may be false. Furthermore, if the transmitted and received identification information is permitted, the first condition determination is true, and if the transmitted and received identification information is not permitted, the first condition determination may be false. Furthermore, the conditions that determine the truth or falsity of the first condition determination are not limited to those described above.

[0253] First, let's explain the case where the first condition is true.

[0254] In the procedure shown in Figure 6(A), AMF sends a Registration Accept message to the UE via the 5G AN (or gNB) as a response message to the Registration Request message (S608). The Registration Accept message is a NAS message sent and received on the N1 interface, but it is included in the RRC message when sent and received between the UE and the 5G AN (gNB).

[0255] Furthermore, the AMF may indicate that the UE's request has been accepted by sending a registration acceptance message based on the identification information received from the UE, and / or subscriber information, and / or network capability information, and / or operator policies, and / or network status, and / or user registration information, and / or context held by the AMF. Here, the various identification information received by the AMF from the UE may be the first identification information included by the UE in the registration request message. In addition, the AMF may send a registration acceptance message to the UE if it accepts the first identification information provided by the UE.

[0256] In this case, if multiple pieces of identification information are sent and received between the UE and the network, two or more of these pieces of identification information may be configured as one or more pieces of identification information. Furthermore, information indicating support for each function and information indicating a request to use each function may be sent and received with the same piece of identification information, or with different pieces of identification information.

[0257] Furthermore, AMF may select and decide whether or not to include identification information in the registration acceptance message based on the identification information received by AMF from the UE or each device, and / or subscriber information, and / or network capability information, and / or operator policies, and / or network status, and / or user registration information, and / or context held by AMF.

[0258] Furthermore, the AMF may indicate that the UE's request has been accepted by sending a registration acceptance message based on the received identification information, and / or subscriber information, and / or network capability information, and / or operator policies, and / or network status, and / or user registration information, and / or context held by the AMF.

[0259] Furthermore, the AMF may include information in the registration acceptance message indicating that some of the UE's requests have been rejected, or may indicate the reason why some of the UE's requests have been rejected by sending information indicating that some of the UE's requests have been rejected. Furthermore, the UE may become aware of the reason why some of its requests have been rejected by receiving information indicating that some of the UE's requests have been rejected. The reason for rejection may also be information indicating that the content of the identification information received by the AMF from the UE is not permitted.

[0260] The UE receives a registration acceptance message from the AMF via the 5G AN (gNB) (S608). Upon receiving the registration acceptance message, the UE can recognize that its request in the registration request message has been accepted, and can also recognize the content of the various identification information contained in the registration acceptance message.

[0261] Furthermore, the UE can send a Registration Complete message to the AMF via the 5G AN (gNB) as a response message to the registration acceptance message (S610). Here, the registration complete message is a NAS message sent and received on the N1 interface, but it is included in the RRC message when sent and received between the UE and the 5G AN (gNB).

[0262] The AMF can receive a registration completion message via 5G AN(gNB) (S610). The UE and each device may also complete the procedure in Figure 6(A) or the registration procedure based on the sending and receiving of the registration acceptance message and / or registration completion message.

[0263] Next, we will explain the case where the first condition determination is false. In the procedure shown in Figure 6(B), the AMF sends a registration rejection message to the UE via the 5G AN(gNB) as a response message to the registration request message (S612). Here, the registration rejection message is a NAS message sent and received on the N1 interface, but it is included in the RRC message sent and received between the UE and the 5G AN(gNB).

[0264] Furthermore, the AMF may indicate that the UE's request has been rejected by sending a registration rejection message based on the identification information received from the UE, and / or subscriber information, and / or network capability information, and / or operator policies, and / or network status, and / or user registration information, and / or context held by the AMF.

[0265] In this case, when multiple pieces of identification information are sent and received between the UE and the network, two or more of these pieces of identification information may be configured as one or more pieces of identification information. Furthermore, information indicating support for each function and information indicating a request to use each function may be sent and received with the same piece of identification information, or they may be sent and received with different pieces of identification information.

[0266] Furthermore, AMF may select and decide whether or not to include identification information in the registration rejection message based on each piece of identification information received by AMF, and / or subscriber information, and / or network capability information, and / or operator policies, and / or network status, and / or user registration information, and / or context held by AMF.

[0267] Furthermore, the AMF may indicate that the UE's request in the registration request message has been rejected by sending a registration rejection message. The AMF may also include information indicating the reason for the rejection in the registration rejection message, or may indicate the reason for the rejection by sending the reason for the rejection separately. Furthermore, the UE may recognize the reason for the rejection of its request by receiving information indicating the reason for the rejection of its request. The reason for the rejection may also be information indicating that the content of the identification information received by the AMF is not permitted.

[0268] The UE receives a registration rejection message from the AMF via the 5G AN (gNB) (S612). Upon receiving the registration rejection message, the UE can recognize that its request via the registration request message has been rejected, and can also recognize the content of the various identification information contained in the registration rejection message. Furthermore, if the UE does not receive a registration rejection message after a predetermined period has elapsed since sending the registration request message, it may recognize that its request has been rejected. Each device completes procedure (B) in this procedure based on the transmission and reception of the registration rejection message.

[0269] Furthermore, the procedure in Figure 6(B) may be initiated if the procedure in Figure 6(A) is discontinued.

[0270] Each device completes the registration procedure based on the completion of either procedure (A) or (B) in Figure 6. Furthermore, each device may transition to a state where the UE is registered with the network (RM-REGISTERED state) based on the completion of procedure (A) in Figure 6, or it may maintain a state where the UE is not registered with the network (RM-DEREGISTERED state) based on the completion of procedure (B) in Figure 6, or it may transition to a state where the UE is not registered with the network. Additionally, each device may transition to each state based on the completion of the registration procedure or based on the establishment of a PDU session.

[0271] Furthermore, the UE may complete the registration process based on the reception of a registration acceptance message or a registration rejection message from the network.

[0272] Furthermore, each device may perform processing based on the information sent and received during the registration process, upon completion of the registration procedure. For example, if it receives information indicating that some of the UE's requests were rejected, it may recognize the reason why the UE's requests were rejected. Furthermore, each device may perform the procedure again based on the reason why the UE's requests were rejected, or it may perform the registration procedure for core network_B or another cell.

[0273] Furthermore, based on the completion of the registration process, the UE may store the identification information received along with the registration acceptance message and / or registration rejection message, and may recognize the network's decision.

[0274] The UE may recognize the content of the above identification information by receiving a registration acceptance message or a registration rejection message.

[0275] Furthermore, the actions taken upon receiving each piece of identification information may be performed based on the received identification information.

[0276] [4.2. Network-requested UE policy management procedure] Next, the network-requested UE policy management procedure will be explained using Figure 7. Hereafter in this section, the network-requested UE policy management procedure will also be referred to as this procedure. This procedure may be initiated by the network. This procedure may also be referred to as the ProSeP provision procedure.

[0277] This procedure may be initiated upon completion of the registration procedure. Alternatively, this procedure may be initiated when the PCF decides to update the UE policy.

[0278] Next, we will explain each step of this procedure.

[0279] First, the PCF sends a manage UE policy command message to the UE via the AMF (S700).

[0280] At this point, the PCF may send a managed UE policy command message to the UE that includes the tenth identification information. Alternatively, the PCF may indicate to the UE what each identification information represents by sending the tenth identification information.

[0281] Furthermore, the PCF may select and / or decide whether or not to include the tenth identification information in the management UE policy command message, based on the status of the UE and / or information received from other NFs, etc.

[0282] Furthermore, the PCF may determine whether or not to send a management UE policy command message and / or identification information based on the status of the UE, and / or information received from the ProSe application server, and / or information received from other NFs.

[0283] More specifically, for example, the PCF may decide whether to include and send the tenth identifier in the managed UE policy command message based on what the UE has accepted from the network during the registration procedure. In other words, for example, during the registration procedure, the PCF may decide whether to include and send the tenth identifier in the managed UE policy command message, the identifier corresponding to what the first identifier included in the registration request message by the UE indicates.

[0284] More specifically, for example, if the registration procedure involves the UE requesting the content indicated by the first identification information from the network, and this procedure is executed after the network has accepted the content indicated by the identification information, the PCF may send a management UE policy command containing the tenth identification information to the UE.

[0285] Specific examples of the content of the UE policy included in the 10th identification information that the UE receives from the network will be described in detail in each embodiment of Chapter 5.

[0286] Next, the UE receives a management UE policy command message from the PCF via the AMF. The UE may also receive a management UE policy command message from the PCF that includes a tenth identification piece.

[0287] Furthermore, based on the receipt of a management UE policy command message, the UE may store each piece of identification information received with the management UE policy command message, or recognize a network decision. The UE may also recognize the content of the identification information received with the management UE policy command message.

[0288] More specifically, for example, if the UE receives a 10th piece of identification information, it may recognize and remember that it is the ProSeP corresponding to the identification information requested by the UE in the registration request message.

[0289] Next, when the UE receives a management UE policy command message, it can perform a third conditional determination. This third conditional determination determines whether the UE will accept the network request. If the third conditional determination is true, the UE initiates the procedure shown in Figure 7(A); if the third conditional determination is false, it initiates the procedure shown in Figure 7(B).

[0290] Furthermore, the third condition determination may be performed based on the reception of a management UE policy command message, and / or the identification information contained in the management UE policy command message, and / or subscriber information, and / or UE capability information, and / or UE policy, and / or the state of the UE, and / or the context held by the UE, etc. For example, if the UE permits the network request, the third condition determination may be true, and if the UE does not permit the network request, the third condition determination may be false. Also, if the UE supports the functionality requested by the network, the third condition determination may be true, and if the UE does not support the functionality requested by the network, the third condition determination may be false. In addition, if the transmitted and received identification information is permitted, the third condition determination may be true, and if the transmitted and received identification information is not permitted, the third condition determination may be false. Furthermore, the conditions that determine the truth or falsity of the third condition determination are not limited to those described above.

[0291] First, let's explain the case where the third condition is true.

[0292] In the procedure shown in Figure 7(A), the UE sends a "manage UE policy complete" message to the PCF via the 5G AN (or gNB) and / or AMF as a response message to the managed UE policy command message (S702).

[0293] Next, PCF receives a management UE policy completion message from the UE via AMF.

[0294] Furthermore, based on the receipt of the managed UE policy completion message, the PCF may store the identification information received along with the managed UE policy completion message, or recognize the UE's decision. The PCF may also recognize the content of the identification information received along with the managed UE policy completion message.

[0295] Furthermore, the above PCF behavior may be performed after receiving the management UE policy completion message.

[0296] Furthermore, when PCF receives a Management UE policy completion message, it may perform the actions it would have taken upon receiving each piece of identification information contained in the Management UE policy completion message.

[0297] Furthermore, the PCF may forward each piece of received identification information to another NF (e.g., a ProSe application server).

[0298] Each device may complete the procedure in Figure 7(A) based on the sending and receiving of a managed UE policy command message and / or a managed UE policy completion message.

[0299] Next, we will explain the case where the third condition is false.

[0300] In the procedure shown in Figure 7(B), the UE sends a manage UE policy command reject message to the PCF via the 5G AN (or gNB) and / or AMF as a response message to the managed UE policy command message (S704).

[0301] Here, the UE may send the 11th identification information, including a management UE policy command rejection message, to the PCF or the network. The UE may also indicate to the network that it has rejected this procedure for the reasons indicated by the 11th identification information by sending a management UE policy command rejection message including the 11th identification information to the network. The UE may also select and decide whether or not to include the 11th identification information in the registration request message based on subscriber information, and / or the network status, and / or the user's registration information, and / or the context held by the UE.

[0302] Next, the PCF receives a management UE policy command rejection message from the UE via the AMF, which includes the 11th identification information.

[0303] If a PCF receives a management UE policy command rejection message from a UE containing the 11th identification information, it may recognize and remember what the 11th identification information means or indicates.

[0304] Furthermore, based on the 11th identification information received from the UE, the PCF may recognize that the UE requires new end-to-end QoS for the 5G ProSe L3 multi-hop communication service, and may also decide to initiate and execute a new network request UE policy management procedure after the completion of this procedure.

[0305] Furthermore, based on the receipt of a managed UE policy command rejection message, the PCF may store the identification information received along with the managed UE policy command rejection message, or recognize the UE's decision. The PCF may also recognize and store the content of the identification information received along with the managed UE policy command rejection message.

[0306] Furthermore, the above PCF behavior may be performed after receiving a management UE policy command rejection message.

[0307] Furthermore, if PCF receives a management UE policy command rejection message, it may perform the actions it would have taken upon receiving each piece of identification information contained in the management UE policy command rejection message.

[0308] Furthermore, the PCF may forward each piece of received identification information to another NF (e.g., a ProSe application server).

[0309] Each device may complete the procedure in Figure 7(B) based on the sending and receiving of a managed UE policy command message and / or a managed UE policy command rejection message.

[0310] Furthermore, each device may complete the network request UE policy management procedure based on the completion of the above-described process and / or the sending and receiving of a management UE policy command message and / or the sending and receiving of a management UE policy completion message and / or the sending and receiving of a management UE policy command rejection message.

[0311] Furthermore, each device may perform processing based on the identification information transmitted and received during this procedure, upon completion of this procedure.

[0312] Furthermore, based on the completion of the network request UE policy management procedure, the UE may add new UE policies, modify existing UE policies, or delete existing UE policies.

[0313] [4.3. UE-requested ProSeP provisioning procedure] Next, the UE-requested ProSeP provisioning procedure will be explained using Figure 8. Hereafter, the UE-requested ProSeP provisioning procedure will also be referred to as this procedure. This procedure may be led by the UE. This procedure may also be referred to as the ProSeP provisioning procedure.

[0314] Furthermore, this procedure may be initiated upon or in conjunction with the completion of the registration procedure. It may also be initiated when the UE requests a UE policy or ProSe policy. Furthermore, this procedure may be a UE policy provisioning procedure.

[0315] Furthermore, this procedure may also be performed to update a ProSeP upon the expiration of a timer indicating each validity period, which is set for each ProSeP indicated by the tenth identification information, either set in the UE or stored by the UE.

[0316] Next, we will explain each step of this procedure.

[0317] First, the UE sends a UE policy provisioning request message containing the 12th identification information to the PCF via the AMF (S800).

[0318] Next, the PCF receives a UE policy provision request message containing the 12th identification information from the UE via the AMF. Upon receiving the UE policy provision request message containing the 12th identification information, the PCF may recognize and store what the 12th identification information means or what it represents.

[0319] Furthermore, based on the 12th identification information received from the UE, the PCF may recognize the end-to-end QoS requirements for the 5G ProSe L3 multihop communication service requested by the UE, and during this procedure, may create an end-to-end QoS that satisfies those requirements, or decide to transmit it to the UE.

[0320] Furthermore, based on the receipt of the UE policy request message, the PCF may store the identification information received along with the UE policy request message, or recognize the network decision. The PCF may also recognize the content of the identification information received along with the UE policy request message.

[0321] Furthermore, the above PCF behavior may be performed after receiving the UE policy command message.

[0322] Furthermore, when PCF receives a UE policy provision request message, it may perform the actions it would have taken upon receiving each piece of identification information contained in the UE policy provision request message.

[0323] When the PCF receives a UE policy provision request message, it can perform a fourth condition determination. The fourth condition determination determines whether the network will accept the UE's request. If the fourth condition determination is true, the PCF initiates the procedure shown in Figure 8(A); if the fourth condition determination is false, it initiates the procedure shown in Figure 8(B).

[0324] Furthermore, the fourth condition determination may be performed based on the receipt of the UE policy provision request message, and / or each piece of identification information contained in the UE policy provision request message, and / or subscriber information, and / or network capability information, and / or operator policy, and / or network status, and / or user registration information, and / or context held by the PCF, etc. For example, if the network permits the UE's request, the fourth condition determination may be true, and if the network does not permit the UE's request, the fourth condition determination may be false. Also, if the network to which the UE is registered, and / or the devices within the network, support the function requested by the UE, the fourth condition determination may be true, and if they do not support the function requested by the UE, the fourth condition determination may be false. Furthermore, if the transmitted and received identification information is permitted, the fourth condition determination may be true, and if the transmitted and received identification information is not permitted, the fourth condition determination may be false. Furthermore, the conditions that determine the truth or falsity of the fourth condition determination are not limited to those described above.

[0325] First, let's explain the case where the fourth condition is true.

[0326] In the procedure shown in Figure 8(A), the PCF may perform the network request policy management procedure (S802). Here, the network request policy management procedure may be the procedure described in the aforementioned network request UE policy management procedure (Chapter 4.2).

[0327] Each device may complete the procedure in Figure 8(A) based on the sending and receiving of UE policy provision request messages and / or the completion of the network request policy management procedure. In the procedure in Figure 8(A), i.e., the network request policy management procedure, the UE policy received by the UE from the network may be the 10th identification information. Specific examples of the content of the 10th identification information received by the UE from the network will be described in detail in each embodiment of Chapter 5.

[0328] Next, we will explain the case where the fourth condition is false.

[0329] In the procedure shown in Figure 8(B), the PCF sends a UE policy provisioning rejection message to the UE via the 5G AN (or gNB) and / or AMF as a response message to the UE policy provisioning request message (S804).

[0330] Furthermore, the PCF may determine whether or not to send a UE policy refusal message and / or each piece of identification information based on the UE status and / or information received from the ProSe application server and / or information received from other NFs.

[0331] Next, the UE receives a UE policy provision refusal message from the PCF via the AMF.

[0332] Furthermore, based on the receipt of a UE policy denial message, the UE may store the identification information received along with the UE policy denial message, or recognize the network decision. The UE may also recognize the content of the identification information received along with the UE policy denial message.

[0333] Furthermore, the above UE behavior may be performed after receiving a UE policy provision denial message.

[0334] Furthermore, if the UE receives a UE policy refusal message, it may perform the actions it would have taken upon receiving each piece of identification information contained in the UE policy refusal message.

[0335] Each device may complete the procedure in Figure 8(B) based on the sending and receiving of UE policy provision request messages and / or UE policy provision denial messages.

[0336] Furthermore, each device may complete this procedure based on the completion of the above-described process and / or the sending and receiving of UE policy provision request messages and / or the completion of the network request policy management procedure and / or the sending and receiving of UE policy provision refusal messages.

[0337] Furthermore, each device may perform processing based on the identification information transmitted and received during this procedure, upon completion of this procedure.

[0338] Furthermore, upon completion of this procedure, UE may add new UE policies, modify existing UE policies, or delete existing UE policies.

[0339] [5. Embodiments] Each embodiment in this embodiment will be described below. The embodiments described in this chapter are based on the definitions of terms and various identification information explained in Chapter 3, and the procedures explained in Chapter 4. Furthermore, in this chapter, each embodiment described will be referred to as the embodiment of this chapter, or simply as each embodiment.

[0340] Herein, each embodiment of this chapter may begin with the UE sending a registration request message to the network, including UE capability information regarding the UE's support for 5G ProSe multi-hop functionality, in the registration procedure (Chapter 4.1), and the registration request message being accepted. Herein, the UE capability information accepted in the registration procedure may be the UE capability information indicated by the first identification information, and may be the 5G ProSe multi-hop functionality supported by the UE.Specific details of the first identification information sent by the UE to the network, and / or some or all of the information contained in the first identification information accepted by the network, will be described in this section or in the sections of each embodiment.

[0341] Furthermore, each embodiment in this chapter may further include the provisioning of a policy from the PCF, which includes end-to-end QoS corresponding to the capabilities of the UE accepted in the registration procedure, through the UE policy provisioning procedures in Chapters 4.2 and 4.3. Moreover, each embodiment in this chapter may also be an embodiment in which the UE policy provisioning procedures in Chapters 4.2 and 4.3 are performed multiple times.

[0342] Here, the first to fourth embodiments may be embodiments relating to a 5G ProSe multi-hop U2U relay service. Furthermore, the UEs of the first to fourth embodiments may support operating as at least a 5G ProSe multi-hop layer-3 UE-to-UE relay UE and / or a 5G ProSe multi-hop layer-3 end UE. In other words, the UEs of the first to fourth embodiments may include in their first identification information information that they support operating as at least a 5G ProSe multi-hop layer-3 UE-to-UE relay UE and / or a 5G ProSe multi-hop layer-3 end UE, and a network receiving such first identification information may accept these.

[0343] Furthermore, the fifth to eighth embodiments may be embodiments relating to a 5G ProSe multi-hop U2N relay service. The UEs of the fifth to eighth embodiments may support operating as at least a 5G ProSe multi-hop layer-3 UE-to-network-relay UE and / or a 5G ProSe multi-hop layer-3 UE-to-network-remote and / or a 5G ProSe layer-3 intermediate relay UE. In other words, the UEs of the fifth to eighth embodiments may include in their first identification information information that they support operating as at least a 5G ProSe multi-hop layer-3 UE-to-network-relay UE and / or a 5G ProSe multi-hop layer-3 UE-to-network-remote and / or a 5G ProSe layer-3 intermediate relay UE, and a network receiving such first identification information may accept these.

[0344] Furthermore, unless otherwise specified, each embodiment described in each section of this chapter may be performed individually and independently, or one or more of the procedures of the embodiments described in each section may be performed in combination, or one or more of the procedures of the embodiments described in each section may be performed in any order.

[0345] More specifically, for example, each of the first to fourth embodiments may be performed individually or in any order. For example, one or more of the second to fourth embodiments may be performed after the first embodiment has been performed.

[0346] Furthermore, for example, the fifth to eighth embodiments may be performed individually or in any order. For example, one or more embodiments from the sixth to eighth may be performed after the fifth embodiment has been performed.

[0347] The following describes each embodiment.

[0348] [5.1. First Embodiment] The first embodiment in this embodiment will be described below. Hereinafter, in this section, the first embodiment will also be referred to as this embodiment.

[0349] This embodiment may be one in which the UE and / or network are started with the registration procedure completed.

[0350] Furthermore, this embodiment may relate to the behavior of each UE and the network when, during the ProSeP provisioning procedure, the source-end UE, U2U relay UE, or target-end UE recognizes that there are missing end-to-end QoS parameters included in the ProSeP provided by the PCF.

[0351] More specifically, this embodiment relates to the behavior of a UE and the network when, in a network request UE policy management procedure or a UE request ProSeP provision procedure performed after the completion of the registration procedure, the end-to-end QoS included in the ProSeP provided from the network (PCF) to the UE determines that it does not meet the QoS requirements for the communication path for the ProSe multihop communication service that the UE is expecting or attempting to establish.

[0352] This embodiment may be an embodiment in which, in the registration procedure, a first identification information indicating that the UE supports operating as a 5G ProSe multi-hop layer-3 UE-to-UE relay UE and / or 5G ProSe multi-hop layer-3 end UE is included in a registration request message sent to the network and initiated or executed upon acceptance by the network or AMF.

[0353] Next, the UE or network that has completed the registration procedure executes the network-requested UE policy management procedure (Chapter 4.2) or the UE-requested ProSeP provision procedure (Chapter 4.3), and the PCF provides the UE with a ProSeP that includes end-to-end QoS. Here, the ProSeP that includes end-to-end QoS may be the tenth identification information. Note that the tenth identification information may be the tenth identification information that the UE sent to the network during the registration procedure, based on the first identification information that the UE sent to the network.

[0354] Here, if the UE receives a ProSeP from the PCF during the network request UE policy management procedure, and the source-end UE recognizes that the end-to-end QoS parameters included in the ProSeP provided by the PCF are missing, the UE may send a Manage UE Policy command reject message to the PCF, including the 11th identification information. Upon receiving the 11th identification information, the PCF recognizes, based on the 11th identification information, that the end-to-end QoS parameters included in the ProSeP provided to the UE are missing, and after the completion of the network request UE policy management procedure, may execute a new network request UE policy management procedure and provide the UE with a new ProSeP that includes the new end-to-end QoS.

[0355] Alternatively, if the source-end UE recognizes after the UE has completed the procedure for providing a ProSeP from the PCF that the ProSeP provided by the PCF is missing end-to-end QoS parameters, the UE may initiate a UE-requested ProSeP provisioning procedure and send a UE policy provisioning request message to the PCF, including the 12th identification information. Upon receiving the 12th identification information, the PCF may recognize, based on the 12th identification information, that the ProSeP provided to the UE is missing end-to-end QoS parameters and may provide the UE with a new ProSeP, including the new end-to-end QoS, during the UE-requested ProSeP provisioning procedure. Note that the procedure for providing a ProSeP may be a network-requested UE policy management procedure.

[0356] Furthermore, the content of the identification information for item 1, and / or item 10, and / or item 11, and / or item 12, and the PCF's recognition based on said identification information, may be based on the detailed descriptions of each identification information explained in Chapter 3.2.

[0357] Based on the above, for example, the UE of this embodiment sends a registration request message to the network that includes capability information indicating that it supports operation as a 5G ProSe multi-hop L3 (Layer-3) UE-to-UE (U2U) end UE, and the network accepts it. In other words, the UE of this embodiment may be a UE that operates as a 5G ProSe multi-hop L3 (Layer-3) UE-to-UE (U2U) end UE.

[0358] Next, in the ProSeP provision procedure, the UE receives a tenth identification information from the network (PCF), which is a ProSeP (5G ProSe Policy) including end-to-end QoS parameters. Here, in the registration procedure, the PCF may send the 10th identification information, which is a ProSeP (5G ProSe Policy) including end-to-end QoS parameters, to the UE based on the first identification information that the UE sent to the network.

[0359] If the source-end UE recognizes that there are missing end-to-end QoS parameters in the ProSeP provided by the PCF, the source-end UE sends a message to the network (PCF) containing the 11th or 12th identification information. Here, the 11th or 12th identification information may be information indicating that there are missing end-to-end QoS parameters assigned by the network. Also, as mentioned above, the 11th or 12th identification information may be a management UE policy command rejection message or a UE policy provision request message.

[0360] Here, the UE may recognize, based on information stored by the UE, that there are missing end-to-end QoS parameters in the ProSeP provided by the PCF. More specifically, the information stored by the UE may be information indicating the criteria or validity of the end-to-end QoS included in the ProSeP. In other words, the UE may recognize, based on information stored by the UE indicating the criteria or validity of the end-to-end QoS included in the ProSeP, that there are missing end-to-end QoS parameters in the ProSeP provided by the PCF.

[0361] Upon receiving the 11th or 12th identification information, the PCF recognizes that the end-to-end QoS parameters included in the ProSeP provided to the UE are missing, and may provide the UE with a new ProSeP that includes the new end-to-end QoS during an ongoing or newly initiated ProSeP provisioning procedure. In other words, the UE may receive a new ProSeP from the network (PCF) that includes the new end-to-end QoS based on the 11th or 12th identification information.

[0362] Here, the message containing the 11th or 12th identification information may be a Manage UE Policy command reject message or a UE policy provisioning request message.

[0363] Furthermore, the content of the first and / or tenth and / or eleventh and / or twelfth identification information in this embodiment, and the recognition of the PCF based on said identification information, may be based on the detailed descriptions of each identification information described in Chapter 3.2.

[0364] [5.2. Second Embodiment] A second embodiment of this embodiment will be described below. In this section, the second embodiment will also be referred to as this embodiment.

[0365] This embodiment may be one in which the UE and / or network are initiated having completed the registration procedure and / or ProSeP provision procedure described in the first embodiment.

[0366] Furthermore, this embodiment may relate to the behavior of each UE and network when, during the discovery procedure, the source-end UE, U2U relay UE, or target-end UE recognizes that there are missing end-to-end QoS parameters included in the ProSeP provided by the PCF.

[0367] More specifically, this embodiment relates to the behavior of the UE and the network when, after the completion of the registration procedure and the ProSeP provision procedure (network request UE policy management procedure and / or UE request ProSeP provision procedure), during the multi-hop U2U relay discovery procedure using Model B on the PC5 interface (5G ProSe multi-hop UE-to-network relay discovery over PC5 interface with Model B), the UE determines that the end-to-end QoS provided from the network (PCF) to the UE does not meet the QoS requirements for the communication path for the ProSe multi-hop communication service that the UE is expecting or attempting to establish.

[0368] Herein, the UE of this embodiment may include in a registration request message in which it sends to the network a first identification information indicating that it supports operating as a 5G ProSe multi-hop layer-3 UE-to-UE relay UE and / or 5G ProSe multi-hop layer-3 end UE during the registration procedure, and this may be executed if accepted by the network or AMF.

[0369] A UE or network that has completed the registration procedure executes the network request UE policy management procedure (Chapter 4.2) or the UE request ProSeP provision procedure (Chapter 4.3), and a ProSeP containing end-to-end QoS is provided from the PCF to the UE. Here, the ProSeP containing end-to-end QoS may be the tenth identification information.

[0370] If a UE that has completed the above procedures (i.e., a source-end UE acting as an initiating UE) recognizes during the Model B discovery procedure that there are missing end-to-end QoS parameters in the ProSeP provided by the PCF, the UE may abort the Model B discovery procedure on the PC5 interface using Model B and initiate the UE request ProSeP provision procedure.

[0371] Furthermore, a source-end UE acting as an initiating UE may, in the UE request ProSeP provisioning procedure, send a UE policy provisioning request message to the PCF, including the 12th identification information. Upon receiving the 12th identification information, the PCF may, based on the 12th identification information, recognize that the end-to-end QoS parameters included in the ProSeP provided to the UE are missing, and may, during the UE request ProSeP provisioning procedure, provide the UE with a new ProSeP that includes the new end-to-end QoS. In other words, the UE may receive the 12th identification information, or a new ProSeP from the network (PCF) that includes the new end-to-end QoS based on the 12th identification information.

[0372] Here, the source-end UE acting as the initiating UE may recognize the lack of end-to-end QoS parameters included in the ProSeP provided by the PCF based on the reception of a discovery response message containing 21st identification information from the U2U relay UE during the Model B discovery procedure. The discovery response message may also be a "PROSE PC5 DISCOVERY message for UE-to-UE relay" message.

[0373] Furthermore, the content of the identification information for item 1, and / or item 10, and / or item 12, and / or item 21, and the PCF's recognition based on such identification information, may be based on the detailed descriptions of each identification information explained in Chapter 3.2.

[0374] Based on the above, for example, the UE of this embodiment sends a registration request message to the network containing first identification information, which is capability information indicating that it supports operation as a 5G ProSe multi-hop L3 (Layer-3) UE-to-UE (U2U) end UE, and the network accepts it. In other words, the UE of this embodiment may be a UE that operates as a 5G ProSe multi-hop L3 (Layer-3) UE-to-UE (U2U) end UE. Here, the UE of this embodiment may be a source-end UE that operates as an initiating UE. Furthermore, the UE of this embodiment may receive and store a tenth identification information from the network (PCF), which is a ProSeP (5G ProSe Policy) including end-to-end QoS parameters, during the ProSeP provision procedure.

[0375] Next, in the Model B discovery procedure of this embodiment, if the UE determines or recognizes that the maximum number of hops determined by the control unit based on the End-to-End QoS parameters included in the ProSeP (5G ProSe Policy) stored by the UE is less than the number of hops assumed by the UE, the UE may terminate the Model B discovery procedure that is currently running. Here, the Model B discovery procedure may be, for example, a multi-hop U2U relay discovery procedure on the PC5 interface using Model B, or a multi-hop U2N relay discovery procedure using Model B (5G ProSe multi-hop UE-to-network relay discovery over PC5 interface with Model B).

[0376] Next, the UE may initiate the UE Request ProSeP provisioning procedure and send a UE policy provisioning request message to the PCF, including the 12th identification information, which may be information indicating that there are missing end-to-end QoS parameters assigned by the network (PCF).

[0377] Upon receiving the 12th identification information, the PCF may, based on the 12th identification information, recognize that the end-to-end QoS parameters included in the ProSeP provided to the UE are missing, and may provide the UE with a new ProSeP that includes the new end-to-end QoS during the UE request ProSeP provision procedure.

[0378] A UE that receives a new ProSeP from the PCF, including a new end-to-end QoS, may initiate or execute a new discovery procedure.

[0379] Furthermore, in this embodiment, the content of the first and / or tenth and / or twelfth and / or twentieth identification information, and the recognition of the PCF based on said identification information, may be based on the detailed descriptions of each identification information described in Chapter 3.2.

[0380] [5.3. Third Embodiment] A third embodiment of this embodiment will be described below. In this section, the third embodiment will also be referred to as this embodiment.

[0381] This embodiment may be one in which the UE and / or network are initiated having completed the registration procedure and / or ProSeP provision procedure and / or discovery procedure as described in the first and second embodiments.

[0382] Furthermore, this embodiment may relate to the behavior of each UE and the network when the source-end UE, U2U relay UE, or target-end UE recognizes that there are missing end-to-end QoS parameters included in the ProSeP provided by the PCF during the direct link establishment procedure.

[0383] For example, the UE of this embodiment sends a registration request message to the network containing first identification information, which is capability information indicating that it supports operation as a 5G ProSe multi-hop L3 (Layer-3) UE-to-UE (U2U) end UE, and the network accepts it. In other words, the UE of this embodiment may be a UE that operates as an end UE. Here, the UE of this embodiment may be a source-end UE that operates as an initiating UE. Furthermore, the UE of this embodiment may receive and store a tenth identification information from the network (PCF), which is a ProSeP (5G ProSe Policy) containing end-to-end QoS parameters, during the ProSeP provisioning procedure. Furthermore, the UE of this embodiment may be in a state where the discovery procedure has been completed.

[0384] Next, if the source-end UE, U2U relay UE, or target-end UE recognizes during the direct link establishment procedure that there are insufficient end-to-end QoS parameters included in the ProSeP provided by the PCF, the UE of this embodiment may receive a direct link establishment rejection message containing the 31st and / or 32nd identification information from the 5G ProSe multi-hop L3 (Layer-3) UE-to-UE (U2U) relay UE. Here, the 31st and / or 32nd identification information may be information indicating at least that there are insufficient end-to-end QoS parameters assigned by the network (PCF) and / or that there is insufficient QoS between hops of the direct link being established.

[0385] Upon receiving a direct link establishment rejection message containing the 31st and / or 32nd identification information, the UE may complete the direct link establishment rejection message and, based on the received 31st and / or 32nd identification information, initiate the UE request ProSeP provisioning procedure and send a UE policy provisioning request message to the PCF, including the 12th identification information, where the 12th identification information may be information indicating that there are insufficient end-to-end QoS parameters assigned by the network (PCF).

[0386] Upon receiving the 12th identification information, the PCF may, based on the 12th identification information, recognize that the end-to-end QoS parameters included in the ProSeP provided to the UE are missing, and may provide the UE with a new ProSeP including the new end-to-end QoS during the UE request ProSeP provision procedure. Furthermore, upon receiving the new ProSeP from the PCF, which includes the new end-to-end QoS, the UE may execute or initiate a new Model B discovery procedure and / or a direct link establishment procedure and / or a direct link modification procedure.

[0387] Alternatively, for example, the UE of this embodiment sends a registration request message to the network containing first identification information, which is capability information indicating that it supports operation as a 5G ProSe multi-hop L3 (Layer-3) UE-to-UE (U2U) relay UE (U2U relay UE), and the network accepts it. In other words, the UE of this embodiment may be a UE that operates as a U2U relay UE.

[0388] In the direct link establishment procedure, if the U2U relay UE determines or recognizes that the QoS between hops of the direct link being established is insufficient, based on the QoS information (end-to-end QoS, or cumulative QoS) and hop-related information (hop limit) contained in the direct link establishment request message received from the source end UE or another U2U relay UE, it may send a direct link establishment rejection message containing the 31st and / or 32nd identification information to the initiating UE or U2N relay UE (the U2U relay UE closer to the initiating UE; the parent U2U relay UE). Here, the 31st and / or 32nd identification information may be information indicating at least that the end-to-end QoS parameters assigned by the network (PCF) are insufficient, and / or that the QoS between hops of the direct link being established is insufficient.

[0389] Furthermore, each UE may, based on the identification information in paragraph 31 and / or paragraph 32, receive a new end-to-end QoS provided by the PCF, included in the new ProSeP, from the initiating UE or the U2N relay UE (the U2U relay UE closer to the initiating UE; the parent U2U relay UE) after the completion of the direct link establishment procedure.

[0390] Furthermore, each UE may initiate or execute new Model B discovery procedures and / or direct link establishment procedures and / or direct link modification procedures based on the new end-to-end QoS included in the new ProSeP provided by the PCF.

[0391] Furthermore, in this embodiment, the content of the first and / or tenth and / or twelfth and / or twentieth identification information, and the recognition of the PCF based on said identification information, may be based on the detailed descriptions of each identification information described in Chapter 3.2.

[0392] [5.4. Fourth Embodiment] The fourth embodiment of this embodiment will be described below. In this section, the fourth embodiment will also be referred to as this embodiment.

[0393] This embodiment may be one in which the UE and / or network are initiated having completed the registration procedure and / or ProSeP provision procedure and / or discovery procedure and / or direct link establishment procedure as described in the first to third embodiments.

[0394] Furthermore, this embodiment may relate to the behavior of each UE and the network when, during communication using a ProSe multi-hop direct link, the source-end UE, U2U relay UE, or target-end UE recognizes that there is a shortage of end-to-end QoS parameters included in the ProSeP provided by the PCF.

[0395] For example, the UE of this embodiment sends a registration request message to the network containing first identification information, which is capability information indicating that it supports operation as a 5G ProSe multi-hop L3 (Layer-3) UE-to-UE (U2U) end UE, and the network accepts it. In other words, the UE of this embodiment may be a UE that operates as an end UE. Here, the UE of this embodiment may be a source end UE that operates as an initiating UE.

[0396] Furthermore, the UE of this embodiment may receive and store a 10th identification information, which is a ProSeP (5G ProSe Policy) including end-to-end QoS parameters, from the network (PCF) during the ProSeP provision procedure. Furthermore, the UE of this embodiment may be in a state where the discovery procedure has been completed.

[0397] Next, the UE of this embodiment may perform and complete a direct link establishment procedure, and the source-end UE and target-end UE may begin communication using the established direct link.

[0398] If, while the source-end UE and target-end UE are communicating using an established direct link, the source-end UE, the U2U relay UE, or the target-end UE recognizes that there are insufficient end-to-end QoS parameters included in the ProSeP provided by the PCF, the source-end UE may receive a direct link release request message containing the 41st identification information from the 5G ProSe multi-hop L3 (Layer-3) UE-to-UE (U2U) relay UE. Here, the 41st identification information may be information indicating at least that there are insufficient end-to-end QoS parameters assigned by the network (PCF) and / or that there is insufficient QoS between hops of the direct link being established.

[0399] Upon receiving a direct link establishment rejection message containing the 41st identification information, the UE may complete the direct link establishment rejection message and, based on the received 41st identification information, initiate the UE request ProSeP provisioning procedure and send a UE policy provisioning request message to the PCF, including the 12th identification information. Here, the 12th identification information may be information indicating that there are insufficient end-to-end QoS parameters assigned by the network (PCF).

[0400] Upon receiving the 12th identification information, the PCF may, based on the 12th identification information, recognize that the end-to-end QoS parameters included in the ProSeP provided to the UE are missing, and may provide the UE with a new ProSeP including the new end-to-end QoS during the UE-requested ProSeP provision procedure. Furthermore, it may execute or initiate a new Model B discovery procedure and / or a direct link establishment procedure and / or a direct link modification procedure that includes the new end-to-end QoS.

[0401] Alternatively, for example, the UE of this embodiment sends a registration request message to the network containing first identification information, which is capability information indicating that it supports operation as a 5G ProSe multi-hop L3 (Layer-3) UE-to-UE (U2U) relay UE (U2U relay UE), and the network accepts it. In other words, the UE of this embodiment may be a UE that operates as a U2U relay UE.

[0402] In the direct link establishment procedure, if the U2U relay UE determines or recognizes that the QoS between hops of the direct link being established is insufficient, based on the QoS information (end-to-end QoS, or cumulative QoS) and hop-related information (hop limit) contained in the direct link establishment request message received from the source end UE or another U2U relay UE, it may send a direct link establishment rejection message containing the 41st identification information to the initiating UE or U2N relay UE (the U2U relay UE closer to the initiating UE; the parent U2U relay UE). Here, the 41st identification information may be information indicating at least that the end-to-end QoS parameters assigned by the network (PCF) are insufficient, and / or that the QoS between hops of the direct link being established is insufficient.

[0403] Furthermore, each UE may, based on the identification information in Section 41, initiate or execute a new Model B discovery procedure and / or a direct link establishment procedure and / or a direct link modification procedure based on the new end-to-end QoS included in the new ProSeP provided by the PCF after the completion of the direct link establishment procedure.

[0404] Furthermore, in this embodiment, the content of the first and / or tenth and / or twelfth and / or twentieth identification information, and the recognition of the PCF based on said identification information, may be based on the detailed descriptions of each identification information described in Chapter 3.2.

[0405] [5.5. Fifth Embodiment] The fifth embodiment of this embodiment will be described below. In this section, the fourth embodiment will also be referred to as this embodiment.

[0406] This embodiment may be one in which the UE and / or network are started with the registration procedure completed.

[0407] Furthermore, this embodiment may relate to the behavior of each UE and the network when a remote UE and / or a U2N intermediate UE and / or a U2N relay UE recognizes during the ProSeP provisioning procedure that there are missing end-to-end QoS parameters included in the ProSeP provided by the PCF.

[0408] More specifically, this embodiment relates to the behavior of a UE when, in a network request UE policy management procedure or a UE request ProSeP provision procedure performed after the completion of the registration procedure, the UE determines that the end-to-end QoS included in the ProSeP provided to the UE from the network (PCF) does not meet the QoS requirements for the communication path for the ProSe multihop communication service that the UE expects or attempts to establish.

[0409] This embodiment may be an embodiment in which, in the registration procedure, a first identification information is included in the registration request message sent to the network indicating that the UE supports operating as a 5G ProSe multi-hop layer-2 UE-to-network-relay UE, and / or a 5G ProSe multi-hop layer-2 UE-to-network-remote UE, and / or a 5G ProSe layer-2 intermediate relay UE, and / or a 5G ProSe multi-hop layer-3 UE-to-network-relay UE, and / or a 5G ProSe multi-hop layer-3 UE-to-network-remote UE, and / or a 5G ProSe layer-3 intermediate relay UE, and the registration procedure is initiated or executed after acceptance by the network or AMF.

[0410] Next, the UE or network that has completed the registration procedure executes the network-requested UE policy management procedure (Chapter 4.2) or the UE-requested ProSeP provision procedure (Chapter 4.3), and the PCF provides the UE with a ProSeP that includes end-to-end QoS. Here, the ProSeP that includes end-to-end QoS may be the tenth identification information. Note that the tenth identification information may be the tenth identification information that the UE sent to the network during the registration procedure, based on the first identification information that the UE sent to the network.

[0411] Here, if the UE receives a ProSeP from the PCF during the network request UE policy management procedure, and the remote UE recognizes that the end-to-end QoS parameters included in the ProSeP provided by the PCF are missing, the UE may send a Manage UE Policy command reject message to the PCF, including the 11th identification information. Upon receiving the 11th identification information, the PCF recognizes, based on the 11th identification information, that the end-to-end QoS parameters included in the ProSeP provided to the UE are missing, and after the completion of the network request UE policy management procedure, may execute a new network request UE policy management procedure and provide the UE with a new ProSeP that includes the new end-to-end QoS.

[0412] Alternatively, if a remote UE recognizes after the UE has completed the procedure for providing a ProSeP from the PCF that the ProSeP provided by the PCF is missing end-to-end QoS parameters, the UE may initiate a UE Request ProSeP provisioning procedure and send a UE policy provisioning request message to the PCF, including the 12th Identification. Upon receiving the 12th Identification, the PCF may, based on the 12th Identification, recognize that the ProSeP provided to the UE is missing end-to-end QoS parameters and, during the UE Request ProSeP provisioning procedure, provide the UE with a new ProSeP that includes the new end-to-end QoS.

[0413] Furthermore, the content of the identification information for item 1, and / or item 10, and / or item 11, and / or item 12, and the PCF's recognition based on said identification information, may be based on the detailed descriptions of each identification information explained in Chapter 3.2.

[0414] Based on the above, for example, the UE of this embodiment sends a registration request message to the network that includes capability information indicating that it supports operation as a 5G ProSe multi-hop U2N (UE-to-Network) remote UE, and the network accepts it. In other words, the UE of this embodiment may be a UE that operates as a 5G ProSe multi-hop U2N (UE-to-Network) remote UE.

[0415] Next, in the ProSeP provision procedure, the UE receives a tenth identification information from the network (PCF), which is a ProSeP (5G ProSe Policy) including end-to-end QoS parameters. Here, in the registration procedure, the PCF may send the 10th identification information, which is a ProSeP (5G ProSe Policy) including end-to-end QoS parameters, to the UE based on the first identification information that the UE sent to the network.

[0416] If the remote UE recognizes that there are missing end-to-end QoS parameters in the ProSeP provided by the PCF, the remote UE sends a message to the network (PCF) containing the 11th or 12th identification information. Here, the 11th or 12th identification information may be information indicating that there are missing end-to-end QoS parameters assigned by the network. Also, as mentioned above, the 11th or 12th identification information may be a management UE policy command rejection message or a UE policy provision request message.

[0417] Here, the UE may recognize, based on information stored by the UE, that there are missing end-to-end QoS parameters in the ProSeP provided by the PCF. More specifically, the information stored by the UE may be information indicating the criteria or validity of the end-to-end QoS included in the ProSeP. In other words, the UE may recognize, based on information stored by the UE indicating the criteria or validity of the end-to-end QoS included in the ProSeP, that there are missing end-to-end QoS parameters in the ProSeP provided by the PCF.

[0418] Upon receiving the 11th or 12th identification information, the PCF recognizes that the end-to-end QoS parameters included in the ProSeP provided to the UE are missing, and may provide the UE with a new ProSeP that includes the new end-to-end QoS during an ongoing or newly initiated ProSeP provisioning procedure. In other words, the UE may receive a new ProSeP from the network (PCF) that includes the new end-to-end QoS based on the 11th or 12th identification information.

[0419] Here, the message containing the 11th or 12th identification information may be a Manage UE Policy command reject message or a UE policy provisioning request message.

[0420] Furthermore, the content of the first and / or tenth and / or eleventh and / or twelfth identification information in this embodiment, and the recognition of the PCF based on said identification information, may be based on the detailed descriptions of each identification information described in Chapter 3.2.

[0421] [5.6. Sixth Embodiment] The sixth embodiment of this embodiment will be described below. In this section, the fourth embodiment will also be referred to as this embodiment.

[0422] This embodiment may be one in which the UE and / or network are initiated having completed the registration procedure and / or ProSeP provision procedure described in the sixth embodiment.

[0423] Furthermore, this embodiment may relate to the behavior of each UE and network when a remote UE and / or U2N intermediate UE and / or U2N relay UE recognize during the discovery procedure that there are missing end-to-end QoS parameters included in the ProSeP provided by the PCF.

[0424] More specifically, this embodiment relates to the behavior of the UE and the network when, after the completion of the registration procedure and the ProSeP provision procedure (network request UE policy management procedure and / or UE request ProSeP provision procedure), during the 5G ProSe multi-hop UE-to-network relay discovery over PC5 interface with model B procedure, the end-to-end QoS provided from the network (PCF) to the UE determines or recognizes that it does not meet the QoS requirements for the communication path for the ProSe multi-hop communication service that the UE is expecting or attempting to establish.

[0425] Herein, the UE of this embodiment may include in a registration request message to the network a first identification information indicating that it supports operating as a 5G ProSe multi-hop layer-2 UE-to-network-relay UE, and / or a 5G ProSe multi-hop layer-2 UE-to-network-remote UE, and / or a 5G ProSe layer-2 intermediate relay UE, and / or a 5G ProSe multi-hop layer-3 UE-to-network-relay UE, and / or a 5G ProSe multi-hop layer-3 UE-to-network-remote UE, and / or a 5G ProSe layer-3 intermediate relay UE during the registration procedure, and this may be an embodiment that is executed when accepted by the network or AMF.

[0426] A UE or network that has completed the registration procedure executes the network request UE policy management procedure (Chapter 4.2) or the UE request ProSeP provision procedure (Chapter 4.3), and a ProSeP containing end-to-end QoS is provided from the PCF to the UE. Here, the ProSeP containing end-to-end QoS may be the tenth identification information.

[0427] If a remote UE acting as an initiating UE has completed the above procedures, and during the 5G ProSe multi-hop UE-to-network relay discovery over the PC5 interface with model B procedure, the remote UE and / or the U2N intermediate UE and / or the U2N relay UE recognize that there are missing end-to-end QoS parameters in the ProSeP provided by the PCF, the UE may abort the U2N relay discovery procedure over the PC5 interface with model B and initiate the UE request ProSeP provision procedure.

[0428] Furthermore, a remote UE acting as an initiating UE may, in the UE request ProSeP provisioning procedure, send a UE policy provisioning request message to the PCF, including the 12th identification information. Upon receiving the 12th identification information, the PCF may, based on the 12th identification information, recognize that the end-to-end QoS parameters included in the ProSeP provided to the UE are missing, and may, during the UE request ProSeP provisioning procedure, provide the UE with a new ProSeP that includes the new end-to-end QoS.

[0429] Here, the remote UE acting as the initiating UE may recognize the lack of end-to-end QoS parameters included in the ProSeP provided by the PCF based on the reception of a discovery response message containing 21st identification information from the U2U relay UE during the U2N relay discovery procedure on the PC5 interface using Model B. The discovery response message may also be a "PROSE PC5 DISCOVERY message for UE-to-Network relay" message.

[0430] Furthermore, the content of the identification information for item 1, and / or item 10, and / or item 12, and / or item 21, and the PCF's recognition based on such identification information, may be based on the detailed descriptions of each identification information explained in Chapter 3.2.

[0431] Based on the above, for example, the UE of this embodiment sends a registration request message to the network containing first identification information, which is capability information indicating that it supports operation as a 5G ProSe multi-hop U2N (UE-to-Network) remote UE, and the network accepts it. In other words, the UE of this embodiment may be a UE that operates as a 5G ProSe multi-hop U2N (UE-to-Network) remote UE. Here, the UE of this embodiment may be a remote UE that operates as an initiating UE. Furthermore, the UE of this embodiment may receive and store a tenth identification information from the network (PCF), which is a ProSeP (5G ProSe Policy) including end-to-end QoS parameters, during the ProSeP provision procedure.

[0432] Next, in the discovery procedure, if the UE determines that the maximum number of hops determined by the control unit based on the End-to-End QoS parameters included in the ProSeP (5G ProSe Policy) stored by the UE is less than the number of hops assumed by the UE, the UE may terminate the discovery procedure that is currently running. Here, the discovery procedure may be, for example, a multi-hop U2N relay discovery procedure over the PC5 interface using model B (5G ProSe multi-hop UE-to-network relay discovery over PC5 interface with model B).

[0433] Next, the UE may initiate the UE Request ProSeP provisioning procedure and send a UE policy provisioning request message to the PCF, including the 12th identification information, which may be information indicating that there are missing end-to-end QoS parameters assigned by the network (PCF).

[0434] Upon receiving the 12th identification information, the PCF may, based on the 12th identification information, recognize that the end-to-end QoS parameters included in the ProSeP provided to the UE are missing, and may provide the UE with a new ProSeP that includes the new end-to-end QoS during the UE request ProSeP provision procedure. In other words, the UE may receive the 12th identification information, or a new ProSeP that includes the new end-to-end QoS based on the 12th identification information, from the network (PCF).

[0435] A UE that receives a new ProSeP from the PCF, including a new end-to-end QoS, may initiate or execute a new discovery procedure.

[0436] Furthermore, in this embodiment, the content of the first and / or tenth and / or twelfth and / or twentieth identification information, and the recognition of the PCF based on said identification information, may be based on the detailed descriptions of each identification information described in Chapter 3.2.

[0437] [5.7. Seventh Embodiment] The seventh embodiment in this embodiment will be described below. In this section, the fourth embodiment will also be referred to as this embodiment.

[0438] This embodiment may be one in which the UE and / or network are initiated having completed the registration procedure and / or ProSeP provision procedure and / or discovery procedure as described in the first and second embodiments.

[0439] Furthermore, this embodiment may relate to the behavior of each UE and the network when a remote UE and / or a U2N intermediate UE and / or a U2N relay UE recognizes that there are missing end-to-end QoS parameters included in the ProSeP provided by the PCF during the direct link establishment procedure.

[0440] For example, the UE of this embodiment sends a registration request message to the network containing first identification information, which is capability information indicating that it supports operation as a 5G ProSe multi-hop L3 (Layer-3) UE-to-Network (U2N) remote UE (remote UE), and the network accepts it. In other words, the UE of this embodiment may be a UE that operates as a remote UE. Here, the UE of this embodiment may be a remote UE that operates as an initiating UE. Furthermore, the UE of this embodiment may receive and store a tenth identification information from the network (PCF), which is a ProSeP (5G ProSe Policy) including end-to-end QoS parameters, during the ProSeP provisioning procedure. Furthermore, the UE of this embodiment may be in a state where the discovery procedure has been completed.

[0441] Next, if the remote UE and / or U2N intermediate UE and / or U2N relay UE recognize that there are insufficient end-to-end QoS parameters included in the ProSeP provided by the PCF during the direct link establishment procedure, the UE of this embodiment may receive a direct link establishment rejection message containing the 31st and / or 32nd identification information from the 5G ProSe L3 (layer-3) intermediate UE-to-Network (U2N) relay UE (U2N intermediate UE). Here, the 31st and / or 32nd identification information may be information indicating at least that there are insufficient end-to-end QoS parameters assigned by the network (PCF) and / or that there is insufficient QoS between hops of the direct link being established.

[0442] Upon receiving a direct link establishment rejection message containing the 31st and / or 32nd identification information, the UE may complete the direct link establishment rejection message and, based on the received 31st and / or 32nd identification information, initiate the UE request ProSeP provisioning procedure and send a UE policy provisioning request message to the PCF, including the 12th identification information, where the 12th identification information may be information indicating that there are insufficient end-to-end QoS parameters assigned by the network (PCF).

[0443] Upon receiving the 12th identification information, the PCF may, based on the 12th identification information, recognize that the end-to-end QoS parameters included in the ProSeP provided to the UE are missing, and may provide the UE with a new ProSeP including the new end-to-end QoS during the UE request ProSeP provision procedure. Furthermore, upon receiving the new ProSeP including the new end-to-end QoS from the PCF, the UE may execute or initiate a new direct link establishment procedure.

[0444] Alternatively, for example, the UE of this embodiment sends a registration request message to the network containing first identification information, which is capability information indicating that it supports operation as a 5G ProSe multi-hop UE-to-Network (U2N) intermediate UE, and the network accepts it. In other words, the UE of this embodiment may be a UE that operates as a U2N intermediate UE.

[0445] In this embodiment, if the U2N intermediate UE determines or recognizes that the QoS between hops of the direct link being established is insufficient based on the QoS information (end-to-end QoS, or cumulative QoS) and hop-related information (hop limit) contained in the direct link establishment request message received from the U2N remote UE or another U2N intermediate UE during the direct link establishment procedure, it may send a direct link establishment rejection message containing the 31st and / or 32nd identification information to the initiating UE or U2N relay UE (the U2U relay UE closer to the initiating UE; the parent U2U relay UE). Here, the 31st and / or 32nd identification information may be information indicating at least that the end-to-end QoS parameters assigned by the network (PCF) are insufficient, and / or that the QoS between hops of the direct link being established is insufficient.

[0446] Furthermore, each UE may, based on the identification information in paragraph 31 and / or paragraph 32, receive a new end-to-end QoS provided by the PCF, included in the new ProSeP, from the initiating UE or the U2N relay UE (the U2U relay UE closer to the initiating UE; the parent U2U relay UE) after the completion of the direct link establishment procedure.

[0447] Furthermore, each UE may initiate or execute a new direct link establishment procedure or a direct link modification procedure based on the new end-to-end QoS included in the new ProSeP provided by the PCF.

[0448] Furthermore, in this embodiment, the content of the first and / or tenth and / or twelfth and / or twentieth identification information, and the recognition of the PCF based on said identification information, may be based on the detailed descriptions of each identification information described in Chapter 3.2.

[0449] [5.8. Eighth Embodiment] The eighth embodiment in this embodiment will be described below. In this section, the fourth embodiment will also be referred to as this embodiment.

[0450] This embodiment may be an embodiment in which the UE and / or the network starts in a state where the registration procedure, and / or the ProSeP provision procedure, and / or the discovery procedure, and / or the direct link establishment procedure described in the fifth to seventh embodiments are completed.

[0451] Furthermore, this embodiment may be an embodiment regarding the behavior of each UE and the network when the remote UE, and / or the U2N intermediate UE, and / or the U2N relay UE recognize that the end-to-end QoS parameters included in the ProSeP provided from the PCF are insufficient during communication using the ProSe multi-hop direct link.

[0452] For example, the UE of this embodiment transmits a registration request message including first identification information, which is capability information indicating the ability to operate as a 5G ProSe multi-hop L3 (Layer-3) UE-to-Network (U2N) remote UE (remote UE), to the network and is accepted by the network. In other words, the UE of this embodiment may be a UE that operates as a remote UE. Here, the UE of this embodiment may be a remote UE that operates as an initiating UE.

[0453] Furthermore, the UE of this embodiment may receive, from the network (PCF), and store tenth identification information, which is a ProSeP (5G ProSe Policy) including end-to-end QoS parameters, in the ProSeP provision procedure. Furthermore, the UE of this embodiment may be in a state where the discovery procedure is completed.

[0454] Subsequently, the UE of this embodiment may execute and complete a direct link establishment (directory link establishment) procedure, and use the established direct link for the remote UE and the U2N relay UE to start communication.

[0455] If, while the remote UE and the U2N relay UE are communicating using an established direct link, the remote UE and / or the U2N intermediate UE and / or the U2N relay UE recognize that there are insufficient end-to-end QoS parameters included in the ProSeP provided by the PCF, the remote UE may receive a direct link release request message containing the 41st identification information from the 5G ProSe multi-hop L3 (Layer-3) UE-to-UE (U2U) relay UE, where the 41st identification information may be information indicating at least that there are insufficient end-to-end QoS parameters assigned by the network (PCF) and / or that there is insufficient QoS between hops of the direct link being established.

[0456] Upon receiving a direct link establishment rejection message containing the 41st identification information, the UE may complete the direct link establishment rejection message and, based on the received 41st identification information, initiate the UE request ProSeP provisioning procedure and send a UE policy provisioning request message to the PCF, including the 12th identification information. Here, the 12th identification information may be information indicating that there are insufficient end-to-end QoS parameters assigned by the network (PCF).

[0457] Upon receiving the 12th identification information, the PCF may, based on the 12th identification information, recognize that the end-to-end QoS parameters included in the ProSeP provided to the UE are missing, and may provide the UE with a new ProSeP including the new end-to-end QoS during the UE-requested ProSeP provision procedure. Furthermore, it may execute or initiate a new Model B discovery procedure and / or a direct link establishment procedure and / or a direct link modification procedure that includes the new end-to-end QoS.

[0458] Alternatively, for example, the UE of this embodiment sends a registration request message to the network containing first identification information, which is capability information indicating that it supports operation as a 5G ProSe multi-hop L3 (Layer-3) UE-to-UE (U2U) relay UE (U2U relay UE), and the network accepts it. In other words, the UE of this embodiment may be a UE that operates as a U2U relay UE.

[0459] In this embodiment, if the U2N intermediate UE determines or recognizes that the QoS between hops of the direct link being established is insufficient based on the QoS information (end-to-end QoS, or cumulative QoS) and hop-related information (hop limit) contained in the direct link establishment request message received from a remote UE or another U2N intermediate UE during the direct link establishment procedure, it may send a direct link establishment rejection message containing the 41st identification information to the initiating UE or U2N relay UE (a U2U relay UE closer to the initiating UE; a parent U2U relay UE). Here, the 41st identification information may be information indicating at least that the end-to-end QoS parameters assigned by the network (PCF) are insufficient, and / or that the QoS between hops of the direct link being established is insufficient.

[0460] Furthermore, each UE may, based on the identification information in Section 41, initiate or execute a new Model B discovery procedure and / or a direct link establishment procedure and / or a direct link modification procedure based on the new end-to-end QoS included in the new ProSeP provided by the PCF after the completion of the direct link establishment procedure.

[0461] Furthermore, the content of the first and / or tenth and / or twelfth and / or twentieth identification information in this embodiment, and the recognition of the PCF based on said identification information, may be based on the detailed descriptions of each identification information described in Chapter 3.2. [6. Modifications] A program that operates in a device according to one aspect of this embodiment may be a program that controls the Central Processing Unit (CPU), etc., to make the computer function in order to realize the functions of the embodiment according to one aspect of this embodiment. The program or the information handled by the program is temporarily stored in volatile memory such as Random Access Memory (RAM), non-volatile memory such as flash memory, a Hard Disk Drive (HDD), or other storage device system.

[0462] Furthermore, a program for realizing the functions of one embodiment relating to this embodiment may be recorded on a computer-readable recording medium. This can also be realized by loading the program recorded on this recording medium into a computer system and executing it. The term "computer system" here refers to a computer system built into the device, and includes hardware such as an operating system and peripheral devices. The term "computer-readable recording medium" may be a semiconductor recording medium, an optical recording medium, a magnetic recording medium, a medium that dynamically holds a program for a short period of time, or any other computer-readable recording medium.

[0463] Furthermore, each functional block or feature of the apparatus used in the embodiments described above may be implemented or executed by an electrical circuit, such as an integrated circuit or a combination of integrated circuits. An electrical circuit designed to perform the functions described herein may include a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or a combination thereof. The general-purpose processor may be a microprocessor, a conventional processor, controller, microcontroller, or state machine. The aforementioned electrical circuits may consist of digital circuits or analog circuits. Also, if advances in semiconductor technology lead to the emergence of integrated circuit technologies that replace current integrated circuits, one or more aspects of this embodiment may use new integrated circuits based on such technologies.

[0464] It should be noted that this embodiment is not limited to the embodiments described above. Although one example of a device is described in this embodiment, this embodiment is not limited to this and can be applied to stationary or non-movable electronic devices installed indoors or outdoors, such as terminal devices or communication devices for AV equipment, kitchen equipment, cleaning and washing machines, air conditioning equipment, office equipment, vending machines, and other household equipment.

[0465] Although embodiments of this embodiment have been described in detail above with reference to the drawings, the specific configuration is not limited to this embodiment, and design changes and the like that do not depart from the gist of this embodiment are also included. Furthermore, this embodiment can be modified in various ways within the scope of the claims, and embodiments obtained by appropriately combining the technical means disclosed in different embodiments are also included in the technical scope of this embodiment. In addition, configurations in which elements described in each of the above embodiments that produce similar effects are substituted for each other are also included.

[0466] One embodiment of this model can be used, for example, in communication systems, communication equipment (e.g., mobile phone devices, base station devices, wireless LAN devices, or sensor devices), integrated circuits (e.g., communication chips), or programs.

[0467] 1 Mobile Communication System 10 UE_A 30 PGW-U 32 PGW-C 35 SGW 40 MME 45 eNB 50 HSS 60 PCRF 80 Access Network_A (E-UTRAN) 90 Core Network_A 120 Access Network_B (5G AN) 122 gNB 130 UPF 132 SMF 140 AMF 150 UDM 160 PCF 190 Core Network_B 235 UPF_A 239 UPF_C

Claims

1. User Equipment (UE) comprising a transceiver unit and a control unit, wherein the transceiver unit transmits a registration request message to a network containing capability information indicating support for operation as a 5G ProSe multi-hop L3 (Layer-3) UE-to-UE (U2U) end UE, and if accepted by the network, the transceiver unit receives a ProSeP (5G ProSe Policy) from the network containing end-to-end QoS parameters, the transceiver unit transmits a message to the network containing first information, the first information indicating that the end-to-end QoS parameters assigned by the network are insufficient, and the transceiver unit receives a new ProSeP from the network containing new end-to-end QoS parameters based on the first information.

2. User Equipment (UE) comprising a transmitting / receiving unit, a control unit, and a storage unit, wherein the UE operates as a 5G ProSe multi-hop L3 (Layer-3) UE-to-UE (U2U) end UE, and the control unit, in a discovery procedure, determines that the maximum number of hops determined by the control unit based on the End-to-End QoS parameters included in the ProSeP (5G ProSe Policy) stored in the storage unit is less than the number of hops assumed by the UE, the control unit aborts the discovery procedure, the transmitting / receiving unit transmits a message containing second information to the network, the second information is information indicating that the end-to-end QoS parameters assigned from the network are insufficient, the transmitting / receiving unit receives a new ProSeP from the network containing new End-to-End QoS parameters based on the second information, and the control unit executes a new discovery procedure.

Images