User equipment (UE)

Abstract

The present invention provides: a means for clarifying various information required for establishing a communication path for multi-hop communication and further transmitting and receiving control messages including the information between UEs; and a method for executing the behavior and processing of each UE based on the message.

Description

UE (User Equipment)

[0001] This embodiment relates to UE (User Equipment). This application claims priority to Japanese Patent Application No. 2024-120814, filed on July 26, 2024, the contents of which are incorporated herein by reference.

[0002] The 3GPP (3rd Generation Partnership Project: registered trademark) is studying the system architecture of the 5G System (5GS), a fifth-generation (5G) mobile communication system, and is discussing how to support new procedures and new functions (see Non-Patent Documents 1 to 4). In Release 19 of the 5G standard, the architecture for expanding the Proximity-based Services (ProSe) function, as well as procedures for communication and control, are being studied (see Non-Patent Document 4).

[0003] 3GPP TS 23.304 V18.6.0 (2024-06); 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Proximity based Services (ProSe) in the 5G System (5GS); (Release 18)3GPP TS 24.554 V18.5.1 (2024-06); 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Proximity-services (ProSe) in 5G System (5GS) protocol aspects; Stage 3 (Release 18)3GPP TS 24.501 V18.7.0 (2024-06); 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3; (Release 18)3GPP TR 23.700-03 V1.0.0 (2024-06); 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on system enhancement for Proximity based Services (ProSe) in the 5G System (5GS); Phase 3 (Release 19)

[0004] In 5GS (5G System), Proximity-services (ProSe) is being considered to realize close-proximity wireless communication between UEs. Furthermore, Release 19 of the 5G standard considers multi-hop communication between UEs via multiple relay UEs.

[0005] On the other hand, the various types of information required to establish communication paths for multi-hop communication, the transmission and reception of control messages containing this information between UEs, and the behavior and processing of each UE based on these messages are not clearly defined.

[0006] One aspect of this embodiment has been made in consideration of the above circumstances, and its purpose is to clarify the various information required to establish a communication path for multi-hop communication, and further to provide a means for transmitting and receiving control messages containing this information between each UE, and a method for executing the behavior and processing of each UE based on this message.

[0007] A UE (User Equipment) of one aspect of this embodiment is a UE having a transceiver unit and a controller, and the UE is a third UE-to-UE relay UE, and in a 5G ProSe UE-to-UE Relay communication procedure using integrated discovery, the transceiver unit receives a direct link establishment request message from a second UE-to-UE relay UE, the direct link establishment request message including fifth and sixth information, the fifth information being an upper limit of the number of hops between End-to-End UEs, and the sixth information being the number of hops from the sender to the first UE-to-UE relay UE, and the controller recognizes, based on the fifth and sixth information, that the number of hops has reached the upper limit and therefore the received message cannot be forwarded, and the transceiver unit, based on the recognition of the controller, transmits a direct link establishment rejection message to the second UE-to-UE relay UE, the direct link establishment rejection message including seventh information, and the seventh information being a reason value indicating that the number of hops in Layer-3 multi-hop UE-to-UE Relay communication has reached the upper limit. A UE (User Equipment) of one aspect of this embodiment is a UE having a transceiver unit and a control unit, and the UE is a second UE-to-UE relay UE, and in a 5G ProSe UE-to-UE Relay communication procedure using integrated discovery, when the transceiver unit receives a direct link establishment rejection message including fourth and seventh information from a third UE-to-UE relay UE, the control unit determines to forward the direct link establishment rejection message to a first UE-to-UE relay UE based on the fourth information, the fourth information is a relay indication indicating that the direct link establishment rejection message can be forwarded, and the seventh information is a reason value indicating that the number of hops in Layer-3 multi-hop UE-to-UE Relays communication has reached an upper limit, and the transceiver unit transmits the direct link establishment rejection message including the fourth and seventh information to the first UE-to-UE relay UE.

[0008] According to one aspect of this embodiment, various information required to establish a communication path for multi-hop communication is clarified, and a means for transmitting and receiving control messages including the information between UEs, and a method for executing the behavior and processing of each UE based on the message are provided.

[0009] FIG. 1 is a diagram illustrating an overview of a mobile communication system (EPS / 5GS). FIG. 2 is a diagram illustrating a detailed configuration of a mobile communication system (EPS / 5GS). FIG. 3 is a diagram illustrating a device configuration of a UE. FIG. 4 is a diagram illustrating a configuration of an access network device (gNB) in 5GS. FIG. 5 is a diagram illustrating a configuration of a core network device (AMF / SMF / UPF) in 5GS. FIG. 6 is a diagram illustrating a registration procedure. FIG. 7 is a diagram illustrating a network-requested UE policy management procedure. FIG. 8 is a diagram illustrating a UE-requested ProSeP provision procedure. FIG. 9 is a diagram illustrating a 5G ProSe UE-to-UE Relay communication procedure using integrated discovery.

[0010] Hereinafter, a best mode for carrying out one aspect of this embodiment will be described with reference to the drawings. In this embodiment, as an example, an embodiment of a mobile communication system to which one aspect of this embodiment is applied will be described.

[0011] [1. System Overview] First, FIG. 1 is a diagram for explaining an overview of a mobile communication system 1 used in each embodiment, and FIG. 2 is a diagram for explaining a detailed configuration of the mobile communication system 1.

[0012] FIG. 1 shows that the mobile communication system 1 is composed 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 by abbreviating the symbols, 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 interfaces that connect these devices and functions to each other.

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

[0016] The 4G system EPS (Evolved Packet System) includes an access network A and a core network A, but may further include a UE and / or a PDN. The 5G system 5GS (5G System) includes a UE, an access network B, and a core network B, but may further include a DN.

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

[0018] Furthermore, access network_A corresponds to an E-UTRAN (Evolved Universal Terrestrial Radio Access Network) and / or a wireless LAN access network. One or more eNBs (evolved Node Bs) 45 are deployed in the E-UTRAN. Note that, hereinafter, the eNB 45 may be referred to by abbreviating the symbol eNB. If there are multiple eNBs, the eNBs are connected to each other, for example, via an X2 interface. Furthermore, one or more access points are deployed in the wireless LAN access network.

[0019] Furthermore, access network_B corresponds to a 5G access network (5G AN). The 5G AN is composed of an NG-RAN (NG Radio Access Network) and / or a non-3GPP access network. One or more gNBs (NR Node Bs) 122 are deployed in the NG-RAN. Note that, hereinafter, the symbol for gNB 122 may be abbreviated, such as gNB. The gNB is a node that provides the NR (New Radio) user plane and control plane to UEs and connects to the 5GCN via an NG interface (including an N2 interface or an N3 interface). In other words, the 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. Furthermore, when there are multiple gNBs, the gNBs are connected to each other, for example, via an Xn interface.

[0020] Furthermore, the non-3GPP access network may be an untrusted non-3GPP access network or a trusted non-3GPP access network. Here, the 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 wireless LAN. On the other hand, the trusted non-3GPP access network may be an access network specified by 3GPP, and may include a trusted non-3GPP access point (TNAP) and a trusted non-3GPP gateway function (TNGF).

[0021] In the following, E-UTRAN and NG-RAN may be referred to as 3GPP access. Also, wireless LAN access networks and non-3GPP AN may be referred to as non-3GPP access. Also, 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 devices included in access network _A, and / or devices included in access network _B may be referred to as access networks or access network devices.

[0023] The core network_A corresponds to an EPC (Evolved Packet Core), which includes, for example, an MME (Mobility Management Entity), an SGW (Serving Gateway), a PGW (Packet Data Network Gateway)-U, a PGW-C, a PCRF (Policy and Charging Rules Function), and an HSS (Home Subscriber Server).

[0024] Furthermore, the core network_B corresponds to a 5G Core Network (5GCN). In the 5GCN, for example, an Access and Mobility Management Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), a Policy Control Function (PCF), a Unified Data Management (UDM), etc. are arranged. Here, the 5GCN may be expressed as a 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 core networks, or core network devices, or devices within core networks, or networks, or NWs. In other words, for example, when referring to networks or NWs 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, or 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] Also, while FIG. 1 illustrates a case where the PDN and the DN are the same, they may be different. The PDN may be a DN (Data Network) that provides communication services to the UE. The DN may be configured as a packet data service network, or may be configured for each service. Furthermore, the PDN may include a connected communication terminal. Therefore, connecting to the PDN may mean connecting to a communication terminal or a server device located in the PDN. Furthermore, transmitting and receiving user data to and from the PDN may mean transmitting and receiving user data to and from a communication terminal or a server device located in the PDN. The PDN may be referred to as the DN, and the DN may be referred to as the PDN.

[0028] In addition, hereinafter, at least a portion of the access network _A, the core network _A, the PDN, the access network _B, the core network _B, and the DN, and / or one or more devices included therein may be referred to as a network or a network device. In other words, when a network and / or a network device sends or receives a message and / or performs a procedure, it means that at least a portion of the access network _A, the core network _A, the PDN, the access network _B, the core network _B, and the DN, and / or one or more devices included therein send or receive a message and / or perform a procedure.

[0029] The UE can also connect to an access network. The UE can also connect to a core network via the access network. The UE can also connect to a PDN or DN via the access network and the core network. That is, the UE can transmit and receive (communicate) user data with the PDN or DN. When transmitting and receiving user data, not only IP (Internet Protocol) communication but also non-IP communication can be used.

[0030] Here, IP communication refers to data communication using IP, and data is transmitted and received using IP packets. An IP packet consists of an IP header and a payload portion. The payload portion may include data transmitted 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, and data is transmitted and received in a format different from the IP packet structure. For example, non-IP communication may be data communication achieved by transmitting and receiving application data without an IP header, or it may be user data transmitted and received by a UE with a different header such as a MAC header or an Ethernet (registered trademark) frame header.

[0031] In addition, access network _A, core network _A, access network _B, core network _B, PDN_A, and DN_A may be configured with devices not shown in Fig. 2. For example, core network _A and / or core network _B may include an AUSF (Authentication Server Function) and an AAA (Authentication, authorization, and accounting) server (AAA-S).

[0032] Here, the AUSF is a core network device having an authentication function for 3GPP access and non-3GPP access, specifically, a network function unit that receives an authentication request for 3GPP access and / or non-3GPP access from a UE and executes the authentication procedure.

[0033] The AAA server is a device that has authentication, authorization, and accounting functions and is connected to the AUSF directly or indirectly via another network device. The AAA server may be a network device within the core network. The AAA server may not be included in the core network _A and / or core network _B, but may be included in the PLMN. In other words, the AAA server may be a core network device or a device outside the core network. For example, the AAA server may be a server device within the PLMN managed by a third party.

[0034] 2, for the sake of simplicity, each device and function is shown one by one, but multiple similar devices and functions may be configured in the mobile communication system 1. Specifically, the mobile communication system 1 may be configured with multiple devices and 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] The UPF_A235 is connected to the DN, the SMF, other UPFs, and the access network. The UPF_A235 may perform functions such as anchoring for intra-RAT or inter-RAT mobility, packet routing and forwarding, an UL CL (Uplink Classifier) ​​function that supports routing of multiple traffic flows for one DN, a branching point function that supports multi-homed PDU sessions, QoS processing for the user plane, verification of uplink traffic, buffering of downlink packets, and a trigger function for downlink data notification. The UPF_A235 may also be a relay device that forwards user data as a gateway between the DN and the core network_B190. The UPF_A235 may also be a gateway for IP communication and / or non-IP communication. The UPF_A235 may also have the function of forwarding IP communication and the function of converting non-IP communication to IP communication. Furthermore, multiple gateways may be gateways that connect the core network _B190 to a single DN. Note that UPF_A235 may have connectivity with other NFs and may be connected to each device via other NFs.

[0036] Between UPF_A235 and the access network, UPF_C239 (also called a branching point or uplink classifier), which is a UPF different from UPF_A235, may exist as a device or NF. When UPF_C239 exists, a PDU session between the UE and the DN will be established via the access network, UPF_C239, and UPF_A235.

[0037] Furthermore, the UPF 130 may be the same device as the UPF_A 235. Note that the UPF 130 and the UPF_A 235 may be written with the symbols omitted, such as 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 the drawings. Each device may be configured as physical hardware, as logical (virtual) hardware configured on general-purpose hardware, or as software. Furthermore, at least a part (including all) of the functions of each device may be configured as physical hardware, logical hardware, or software.

[0039] Note that each memory unit (memory unit_A340, memory unit_A440, memory unit_B540, memory unit_A640, memory unit_B740) in each device / function mentioned below is configured with, for example, a semiconductor memory, a solid state drive (SSD), a hard disk drive (HDD), etc. Furthermore, each memory unit can store not only information originally set at the time of shipment, but also various information transmitted and received between devices / functions other than the device / function itself (e.g., UE, and / or access network device, and / or core network device, and / or PDN, and / or DN). Furthermore, each memory unit can store identification information, control information, flags, parameters, etc. included in control messages transmitted and received in various communication procedures described below. Furthermore, each memory unit may store this information for each UE. Furthermore, when interworking between 5GS and EPS is performed, each memory unit can store control messages and user data transmitted and received between 5GS and / or devices / functions included in EPS. At this time, not only those transmitted and received via the N26 interface but also those transmitted and received without going through the N26 interface can be stored.

[0040] [2.1. Device configuration of UE] First, an example of the device configuration of UE (User Equipment) will be explained using Figure 3. The UE is composed of a control unit _A300, an antenna 310, a transceiver unit _A320, and a memory unit _A340. The control unit _A300, the transceiver unit _A320, and the memory 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 operation and functions of the entire UE. The control unit _A300 realizes various processing in the UE by reading and executing various programs stored in the memory unit _A340 as necessary.

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

[0043] Explaining in detail with reference to Figure 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. The UE can also communicate with a base station device (gNB) in the 5G AN by using the transceiver unit _A320. The UE can also transmit and receive AMF and NAS (Non-Access-Stratum) messages via the N1 interface by using the transceiver unit _A320. However, since the N1 interface is logical, in reality, communication between the UE and the AMF is performed via the 5G AN.

[0044] The memory 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 Figure 4. The gNB is composed of a control unit _B500, an antenna 510, a network connection unit _B520, a transceiver unit _B530, and a memory unit _B540. The control unit _B500, the network connection unit _B520, the transceiver unit _B530, and the memory 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 operation 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 memory 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 send and receive user data and / or control information between 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] 2, a gNB in ​​a 5G AN can communicate with an AMF via an N2 interface by using a network connection unit _B 520, and can communicate with a UPF via an N3 interface, and can communicate with a UE by using a transceiver unit _B 530.

[0050] The memory 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 explained using Figure 5. The AMF is composed of a control unit _B700, a network connection unit _B720, and a memory unit _B740. The control unit _B700, the network connection unit _B720, and the memory 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 realizes various processing 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 a base station device (gNB), and / or SMF, and / or PCF, and / or UDM, and / or SCEF in a 5G AN. That is, the AMF can use the network connection unit _B720 to transmit and receive user data and / or control information between a base station device (gNB), and / or SMF, and / or PCF, and / or UDM, and / or SCEF in a 5G AN. In other words, for example, the network connection unit may be a transceiver unit.

[0054] Explaining in detail with reference to FIG. 2, the AMF in the 5GCN can communicate with a gNB via the N2 interface by using the network connection unit _A620, can communicate with a UDM via the N8 interface, can communicate with an SMF via the N11 interface, and can communicate with a PCF via the N15 interface. The AMF can also send and receive NAS messages with a UE via the N1 interface by using the network connection unit _A620. However, since the N1 interface is logical, communication between the UE and the AMF is actually performed via a 5G AN. Furthermore, if the AMF supports the N26 interface, it can communicate with an MME via the N26 interface by using the network connection unit _A620.

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

[0056] 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) functions, connection management (CM) functions, reachability management functions, mobility management functions for UEs, etc., transferring SM (Session Management) messages between the UE and the SMF, access authentication (Access Authorization) functions, security anchor functionality (SEA), security context management (SCM), a function to support the N2 interface for the N3IWF (Non-3GPP Interworking Function), a function to support sending and receiving NAS signals with the UE via the N3IWF, and a function to authenticate UEs connected via the N3IWF.

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

[0058] In other words, 5GMM-REGISTERED may be a state in which each device has established a 5GMM context or a PDU session context. When each device is 5GMM-REGISTERED, UE_A10 may start transmitting and receiving user data and control messages, or may respond to paging. Furthermore, 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 be a state in which each device has not established a 5GMM context, a state in which UE_A10's location information is not known to the network, or a state in which UE_A10 is unreachable from the network. Note that when each device is 5GMM-DEREGISTERED, UE_A10 may initiate a registration procedure or may establish a 5GMM context by performing the registration procedure.

[0060] In addition, connection management manages the CM state for each UE. The CM state may be synchronized between the UE and the AMF. The CM state includes a non-connected state (CM-IDLE state) and a 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. In the CM-IDLE state, the UE does not have an N2 interface connection or an N3 interface 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. In the CM-CONNECTED state, the UE may have an N2 interface connection and / or an N3 interface connection.

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

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

[0063] In addition, one or more AMFs may be placed in the core network _B. In addition, the AMF may be a Network Function (NF) that manages one or more Network Slice Instances (NSIs). In addition, the AMF may be a Common Control Plane Network Function (CCNF) shared among multiple NSIs.

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

[0065] [2.4. SMF Device Configuration] Next, an example of the SMF device configuration will be explained using Figure 5. The SMF is composed of a control unit _B700, a network connection unit _B720, and a memory unit _B740. The control unit _B700, the network connection unit _B720, and the memory 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 realizes various processing 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 send and receive user data and / or control information between the AMF, and / or UPF, and / or PCF, and / or UDM using the network connection unit _B720.

[0068] Explaining in more detail with reference to Figure 2, the SMF in the 5GCN can communicate with the AMF via the N11 interface, with the UPF via the N4 interface, with the PCF via the N7 interface, and with the UDM via the N10 interface by using the network connection unit _A620.

[0069] The memory unit _B740 is a functional unit for storing programs, user data, control information, etc. required for each operation of the SMF.

[0070] The SMF has session management functions such as establishing, modifying, and releasing PDU sessions, IP address allocation for UEs and its management, UPF selection and control, UPF configuration for routing traffic to the appropriate destination, sending and receiving the SM portion of NAS messages, Downlink Data Notification, providing AN-specific (for each AN) SM information to be sent to the AN via the N2 interface via the AMF, determining the SSC mode (Session and Service Continuity mode) for the session, 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 is composed of a control unit _B700, a network connection unit _B720, and a memory unit _B740. The control unit _B700, the network connection unit _B720, and the memory 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 realizes various processing 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 for the UPF to connect to a base station device (gNB), and / or SMF, and / or DN within the 5G AN. In other words, the UPF can use the network connection unit _B720 to transmit and receive user data and / or control information between the base station device (gNB), and / or SMF, and / or DN within the 5G AN.

[0074] Explaining in more detail with reference to Figure 2, a UPF in a 5GCN can communicate with a gNB via the N3 interface, with an SMF via the N4 interface, with a DN via the N6 interface, and with other UPFs via the N9 interface by using the network connection unit _A620.

[0075] The memory unit _B740 is a functional unit for storing programs, user data, control information, etc. required for each operation of the UPF.

[0076] The UPF has functions such as an anchor point for intra-RAT mobility or inter-RAT mobility, an external PDU session point for interconnecting to DNs (i.e., a gateway between DNs and core network_B that forwards user data), packet routing and forwarding, an UL CL (Uplink Classifier) ​​function that supports routing of multiple traffic flows to one 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 notifications.

[0077] The UPF may also be a gateway for IP communication and / or non-IP communication. The UPF may also have a function for forwarding IP communication and a function for converting non-IP communication and IP communication. Furthermore, multiple gateways may be gateways that connect the core network_B to a single DN. The UPF may also have connectivity with other NFs and may be connected to each device via other NFs.

[0078] The user plane refers to user data transmitted and received between a UE and a network. The user plane may be transmitted and received using a PDN connection or a PDU session. Furthermore, 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 the U-Plane.

[0079] Furthermore, the control plane refers to control messages transmitted and received to control UE communications, etc. The control plane may be transmitted and received using a Non-Access-Stratum (NAS) signaling connection between the UE and the MME. Furthermore, in the case of EPS, the control plane may be transmitted and received using the LTE-Uu interface and the S1-MME interface. Furthermore, 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 be a communication path for transmitting and receiving user data and may be composed of multiple bearers. Furthermore, the C-Plane (Control Plane; CP) may be a communication path for transmitting and receiving control messages and may be composed of multiple bearers.

[0081] [2.6. Description of Other Devices and / or Functions] Next, other devices and / or functions will be described.

[0082] The PCF has a function to provide policy rules.

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

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

[0085] The HSS is connected to the MME and / or SCEF and has a function of managing subscriber information. The subscriber information of the HSS is referred to, for example, when controlling access to the MME. Furthermore, the HSS may be connected to a location management device different from the MME.

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

[0087] [3.1. Explanation of Terms Used in Each Embodiment] Next, highly specialized terms used in each embodiment will be explained.

[0088] A network refers to at least a portion of an access network _B, a core network _B, and a DN. Furthermore, one or more devices included in at least a portion of an access network _B, a core network _B, and a DN may be referred to as a network or a network device. In other words, when a network transmits, receives, and / or processes messages, it may mean that devices within the network (network devices and / or control devices) transmit, receive, and / or process messages. Conversely, when a device within the network transmits, receives, receives, and / or processes messages, it may mean that the network transmits, receives, receives, and / or processes messages.

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

[0090] An MM (Mobility management) message (also referred to as an NAS MM message) may be an NAS message used in procedures for MM, and may be a control message transmitted and received between UE_A10 and AMF_A240. Furthermore, the MM message may include a registration request message, a registration accept message, a registration reject message, a de-registration request message, a de-registration accept message, a configuration update command message, a configuration update complete message, a service request message, a service accept message, a service reject message, a notification message, a notification response message, etc. Furthermore, the procedures for MM or MM procedures may include a registration procedure, a de-registration procedure, a generic UE configuration update procedure (also simply referred to as a UE configuration update procedure), an authentication and / or authorization procedure, a service request procedure, a paging procedure, and a notification procedure.

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

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

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

[0094] A PDU (Protocol Data Unit / Packet Data Unit) session can be defined as an association between a DN that provides PDU connectivity services and a UE, but it may also be connectivity established between a UE and an external gateway. In 5GS, a UE can transmit and receive user data to and from a DN by establishing a PDU session via an access network _B and a core network _B. Here, this external gateway may be a UPF, SCEF, or the like. The UE can transmit and receive user data to and from a device, such as an application server, located in the DN using the PDU session. Note that each device (UE, and / or access network device, and / or core network device) may manage one or more pieces of identification information associated with a PDU session. Note that this identification information may include one or more of a DNN, a QoS rule, a PDU session type, an application identification information, an NSI identification information, an access network identification information, and an SSC mode, or may further include other information. Furthermore, when multiple PDU sessions are established, the identification information associated with each PDU session may be the same or different.

[0095] The DNN (Data Network Name) may be identification information for identifying a core network and / or an external network such as a DN. Furthermore, the DNN can also be used as information for selecting a gateway such as a PGW / UPF that connects the core network B190. Furthermore, 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 can be IPv4, IPv6, Ethernet, or Unstructured. If IPv4 is specified, it indicates that data will be sent and received using IPv4. If IPv6 is specified, it indicates that data will be sent and received using IPv6. If Ethernet is specified, it indicates that Ethernet frames will be sent and received. Ethernet may also indicate that communication using IP is not performed. If Unstructured is specified, it indicates that data will be sent and received to an application server or the like in the DN using Point-to-Point (P2P) tunneling technology. As the P2P tunneling technology, for example, UDP / IP encapsulation technology may be used. In addition to the above, the PDU session type may also include IP. IP can be specified if the UE is capable of using 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 an operator, which is a communication service provider, and the operator can be identified by a PLMN ID. A PLMN that matches the MCC (Mobile Country Code) and MNC (Mobile Network Code) of a UE's IMSI (International Mobile Subscriber Identity) may be a Home PLMN (HPLMN). Furthermore, a UE may store an Equivalent HPLMN list (also referred to as equivalent HPLMN) in its USIM to identify one or more EPLMNs (Equivalent HPLMNs). A PLMN different from the HPLMN and / or EPLMN may be a Visited PLMN (VPLMN). A PLMN to which a UE has successfully registered may be a Registered PLMN (RPLMN).

[0098] A tracking area is a single or multiple ranges managed by the core network that can be represented by the location information of UE_A10. Note that a tracking area may be composed of multiple cells. Furthermore, a tracking area may be an area in which control messages such as paging are broadcast, or an area in which UE_A10 can move without performing a handover procedure. Furthermore, a tracking area may be a routing area, a location area, or anything similar. Hereinafter, a tracking area may 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 collection of one or more TAs assigned to a UE by the AMF. Note that while UE_A10 is moving within one or more TAs included in the registration area, it may be able to move without sending or receiving signals for tracking area update. In other words, a registration area may be a group of information indicating areas in which UE_A10 can move without performing a 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 in the cell where the UE is located or camped, or if the cell is a satellite NG-RAN cell that broadcasts multiple Tracking Area Codes (TACs) in the selected PLMN, the UE NAS layer may select the current TAI from multiple Tracking Area Codes (TACs) in the selected PLMN.

[0101] The Lists of 5GS forbidden tracking areas may be a list of 5GS forbidden tracking areas for roaming and / or a list of 5GS forbidden tracking areas for regional provision of service stored by a UE not operating in an SNPN access operation mode. In other words, a UE not operating in an SNPN access operation mode must store a list of 5GS forbidden tracking areas for roaming and / or a list of 5GS forbidden tracking areas for regional service provision. Furthermore, the UE must search for a suitable cell within the same PLMN that belongs to a TA that is not included in the list of 5GS forbidden tracking areas.

[0102] Furthermore, a UE is not permitted to request 5GS services other than emergency services if it is located in a cell of a TA that belongs to the list of 5GS forbidden tracking areas for regional provision of service.

[0103] The UE may also store the forbidden tracking area ID (TAI) in a list of 5GS forbidden tracking areas for regional service provision to prevent repeated attempts to access cells in the forbidden tracking area. Furthermore, the list of 5GS forbidden tracking areas for regional service provision may be deleted when the UE is powered off, when the SIM is removed, or periodically (for a period ranging from 12 to 24 hours).

[0104] In addition, the information indicating the 5GS forbidden tracking areas for roaming may be included in an information element (IE) containing one or more forbidden TAI(s) for the list of "5GS forbidden tracking areas for roaming" included in a message sent by the network, and transmitted to the UE.

[0105] In addition, the 5GS forbidden tracking areas for regional provision of service may be included in an information element (IE) containing one or more forbidden TAIs for the list of "5GS forbidden tracking areas for regional provision of service" (5GS forbidden tracking areas for roaming) included in a message sent by the network and transmitted to the UE.

[0106] The UE ID is information for identifying a UE. For example, the UE ID may be a SUCI (Subscription Concealed Identifier), a SUPI (Subscription Permanent Identifier), a GUTI (Globally Unique Temporary Identifier), an IMEI (International Mobile Subscriber Identity), an IMEISV (IMEI Software Version), or a TMSI (Temporary Mobile Subscriber Identity). Alternatively, the UE ID may be other information set in an application or a network. Furthermore, the UE ID may be information for identifying a user.

[0107] PC5 is a reference point. PC5 may be a reference point between ProSe-enabled UEs. PC5 may be a reference point for 5G ProSe Direct Discovery, 5G ProSe Direct Communication, 5G ProSe UE-to-Network Relay, and / or 5G ProSe UE-to-UE Relay.

[0108] The PC5 path may be a communication path on the PC5. The PC5 path may also be a communication path between ProSe-enabled UEs. The PC5 path may also refer to the PC5. The PC5 path may also be referred to as a PC5 interface.

[0109] In addition, the PC5 link may be a PC5 path. The PC5 link may be referred to as a PC5 direct link, a 5G ProSe direct link, or a direct link.

[0110] Uu may be a radio interface, and Uu may be a radio interface between a 5G AN and a UE.

[0111] The Uu path may be a communication path on the Uu. The Uu path may also be a communication path between the 5G AN and the UE. The Uu path may also refer to the Uu. The Uu path may also be referred to as a Uu interface. The Uu path may also be referred to as a Uu link.

[0112] 5G Proximity-based Services (ProSe) may be services provided by 5GS based on UEs being in close proximity to each other. 5G ProSe may also be referred to as ProSe.

[0113] 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-capable UE.

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

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

[0116] An End UE may be a ProSe-enabled UE that communicates with another ProSe-enabled UE via a U2U 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 simply referred to as an End UE.

[0117] 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. Note that the 5G ProSe layer-2 end UE may be a 5G ProSe capable UE that communicates with other 5G ProSe capable UEs via a 5G ProSe layer-2 UE-to-UE relay UE. Also, the 5G ProSe layer-3 end UE may be a 5G ProSe capable UE that communicates with other 5G ProSe capable UEs via a 5G ProSe layer-3 UE-to-UE relay UE.

[0118] An End UE may be referred to as a UE acting as an End UE. More specifically, an End UE may include a source End UE and a destination End UE (also referred to as a target End UE). Here, the source End UE may be an End UE that sends a request message, and the target End UE may be an End UE that receives the request message.

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

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

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

[0122] A 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, 5G ProSe UE-to-UE Relay is also simply referred to as U2U Relay or U2U Relay UE. Furthermore, in this specification, when describing multiple U2U Relay UEs, each U2U Relay UE is also referred to as U2U Relay UE#1, U2U Relay UE#2, etc. to distinguish them from one another.

[0123] Here, the 5G ProSe layer-2 U2U relay UE may be a 5G ProSe-enabled UE that provides the function of supporting a connection between two 5G ProSe layer-2 end UEs via a layer 2 protocol.

[0124] Also, here, the 5G ProSe layer-3 U2U relay UE may be a 5G ProSe-enabled UE that provides a function to support a connection between two 5G ProSe layer-3 end UEs via a layer 3 protocol.

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

[0126] In addition, 5G ProSe layer-2 U2U relay UE is a 5G ProSe-enabled UE that provides the capability to support connectivity between two 5G ProSe layer-2 end UEs via layer-2 protocols.

[0127] In addition, 5G ProSe layer-3 U2U relay UE is a 5G ProSe-enabled UE that provides the capability to support connectivity between two 5G ProSe layer-3 end UEs via layer-3 protocols.

[0128] A discovery procedure may be a procedure that uses NR radio signals to detect and identify other nearby UEs.

[0129] The discovery procedure may be a 5G ProSe direct discovery procedure, a 5G ProSe UE-to-network relay discovery procedure, or a 5G ProSe UE-to-UE relay discovery procedure. The discovery procedure may also be referred to as 5G ProSe direct discovery or 5G ProSe discovery.

[0130] Multi-hop communication may refer to communication via two or more UEs. Also, multi-hop communication may refer to communication between a UE and another UE or a network via two or more other UEs. More specifically, for example, multi-hop communication may refer to communication between End UEs via two or more UE-to-UE Relay UEs.

[0131] For example, the embodiment illustrated in Fig. 9 may be multi-hop communication. More specifically, the embodiment illustrated in Fig. 9 may be an example in which a source end UE connects to a target end UE via two U2U relay UEs, establishes a communication path for multi-hop communication, and performs multi-hop communication. Here, the source end UE, and / or U2U relay UE #1, and / or U2U relay UE #2, and / or target end UE illustrated in Fig. 9 may support multi-hop communication.

[0132] Here, the multi-hop communication may be UE-to-network relay multi-hop communication or UE-to-UE relay multi-hop communication.

[0133] Furthermore, a UE that supports multi-hop communication may be a multi-hop UE. Furthermore, 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 UE-to-UE Relay UE and / or a UE-to-Network Relay UE. Or, for example, a UE that supports multi-hop communication may be a UE-to-UE Relay UE and / or a UE-to-Network Relay UE and / or an End UE.

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

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

[0136] Furthermore, for example, the relay service code may be information for identifying communication or communication service between End UEs via a multi-hop communication path via two or more U2U-relay UEs.

[0137] In addition, the relay service code may select security policies and information required for authentication and authorization between the End UE and the U2U relay UE.

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

[0139] ProSeP may be a 5G ProSe policy or information indicating or including a 5G ProSe policy. ProSeP may also be provided from the network to the U2U-relay and / or End UE in a network-requested UE policy management procedure and / or a UE-requested ProSeP provision procedure, which will be described later. ProSeP may also be information determined by the PCF and provided to the U2U-relay and / or End UE.

[0140] OLSR (Optimized Link State Routing Protocol) or OLSRv2 (Optimized Link State Routing Protocol Version 2) is a proactive routing protocol for mobile ad-hoc network environments, specified by the Mobile ad-hoc Network (MANET) Working Group of the IETF (Internet Engineering Task Force).

[0141] Here, a proactive routing protocol may be a routing protocol in which the terminals constituting the mobile ad hoc network exchange information in advance to determine a communication path before user communication is performed.

[0142] Currently, standardization is being promoted for use as a routing protocol for establishing a communication path between two End UEs when sending and receiving IP (Internet Protocol) type traffic in Layer-3 Multi-hop UE-to-UE Relay communications.

[0143] [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, and is also referred to as control information in this specification.

[0144] The first identification information in this embodiment is information indicating the capability of the UE, more specifically, the first identification information is capability information indicating that the UE supports a Mobile Ad-hoc Network (MANET) routing protocol in transmitting and receiving IP type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0145] Alternatively, the first identification information may be capability information indicating that the UE does not support a MANET (Mobile Ad-hoc Network) routing protocol in transmitting and receiving IP type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0146] The first identification information may also be information included as part of the 5GMM capability, or a 5GMM capability IE (Information Element), or the 5GMM capability.

[0147] Also, in this specification, unless otherwise specified, the first identification information may be capability information indicating that the UE supports a MANET (Mobile Ad-hoc Network) routing protocol in transmitting and receiving IP type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0148] The second identification information in this embodiment is information indicating the capability of the UE, more specifically, the second identification information is capability information indicating that the UE supports Layer-3 multi-hop UE-to-UE Relay of Ethernet type or Unstructured type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0149] Alternatively, the second identification information is capability information indicating that the UE does not support Layer-3 multi-hop UE-to-UE Relay of Ethernet type or Unstructured type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0150] The second identification information may also be information included as part of the 5GMM capability, or a 5GMM capability Information Element (IE), or the 5GMM capability.

[0151] The first and / or second identification information may be configured as a single piece of information that combines these.

[0152] In this specification, unless otherwise specified, the second identification information may be capability information indicating that the UE supports Layer-3 multi-hop UE-to-UE Relay of Ethernet type or Unstructured type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0153] The third identification information in this embodiment is information indicating support of a capability or function of the network. More specifically, the third identification information may be information indicating that the network supports a Mobile Ad-hoc Network (MANET) routing protocol in transmitting and receiving IP-type traffic in ProSe Layer-3 multi-hop UE-to-UE relay communication.

[0154] Alternatively, the third identification information may be information indicating that the network does not support a MANET (Mobile Ad-hoc Network) routing protocol in transmitting and receiving IP type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0155] Furthermore, the third identification information may be 5GS network feature support, or 5GS network feature support IE (Information Element), or information included as part of these.

[0156] In this specification, unless otherwise specified, the third identification information may be information indicating that the network supports a MANET (Mobile Ad-hoc Network) routing protocol in transmitting and receiving IP type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0157] The fourth identification information in this embodiment is information indicating support of a network capability or function. More specifically, the fourth identification information may be information indicating that the network supports Layer-3 multi-hop UE-to-UE Relay of Ethernet type or Unstructured type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0158] Alternatively, the fourth identification information may be information indicating that the network does not support Layer-3 multi-hop UE-to-UE Relay of Ethernet type or Unstructured type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0159] Furthermore, the fourth identification information may be 5GS network feature support, or 5GS network feature support IE (Information Element), or information included as part of these.

[0160] In this specification, unless otherwise specified, the fourth identification information may be information indicating that the network supports Layer-3 multi-hop UE-to-UE Relay of Ethernet type or Unstructured type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0161] The fifth identification information in this embodiment is a reason or a cause value that the network indicates to the UE, and more specifically, the fifth identification information may be a cause value that indicates that the network does not support a Mobile Ad-hoc Network (MANET) routing protocol in transmitting and receiving IP-type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0162] In other words, for example, the fifth identification information may be a reason value indicating that the network does not support the capability indicated by the first identification information, where the first identification information received by the network may be capability information indicating that the UE supports a Mobile Ad-hoc Network (MANET) routing protocol in transmitting and receiving IP-type traffic.

[0163] Furthermore, the fifth identification information may be a reason value indicating that the network or AMF does not allow the UE to perform ProSe Layer-3 multi-hop UE-to-UE Relay communication that uses a Mobile Ad-hoc Network (MANET) routing protocol for transmitting and receiving IP type traffic. In other words, the fifth identification information may be a reason value indicating that the network or AMF does not allow the UE to use a Mobile Ad-hoc Network (MANET) routing protocol for transmitting and receiving IP type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0164] Furthermore, the fifth identification information may be the 5GMM cause or information included as part of the 5GMM cause IE.

[0165] Furthermore, the fifth identification information may be identification information included in a registration rejection message that is sent as a response message to a registration request message including the first identification information by a network or AMF that receives the registration request message from a UE during the registration procedure.

[0166] The sixth identification information in this embodiment is a cause value indicated by the network to the UE. It is a reason or a cause value indicated by the network to the UE. More specifically, the sixth identification information may be a cause value indicating that the network does not support Layer-3 multi-hop UE-to-UE Relay in transmitting and receiving Ethernet type or Unstructured type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0167] In other words, for example, the sixth identification information may be a reason value indicating that the network does not support the capability indicated by the second identification information, where the second identification information received by the network may be capability information indicating that the UE supports Layer-3 multi-hop UE-to-UE Relay of Ethernet-type or Unstructured-type traffic.

[0168] Furthermore, the sixth identification information may be a reason value indicating that the network or AMF does not allow the UE to perform ProSe Layer-3 multi-hop UE-to-UE Relay communication using Layer-3 multi-hop UE-to-UE Relay for Ethernet type or Unstructured type traffic. In other words, the sixth identification information may be a reason value indicating that the network or AMF does not allow the use of Layer-3 multi-hop UE-to-UE Relay for Ethernet type or Unstructured type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0169] Furthermore, the sixth identification information may be the 5GMM cause or information included as part of the 5GMM cause IE.

[0170] Furthermore, the sixth identification information may be identification information included in a registration rejection message that is sent as a response message to a registration request message including the second identification information by a network or AMF that receives the registration request message from a UE during the registration procedure.

[0171] The tenth identification information in this embodiment is ProSe Policy (ProSeP). More specifically, the tenth identification information may be ProSeP when a MANET (Mobile Ad-hoc Network) routing protocol is used in transmitting and receiving IP-type traffic in ProSe Layer-3 multi-hop UE-to-UE relay communication.

[0172] In other words, the tenth identification information may be information indicating that the identification information is ProSeP for multi-hop communication that transmits and receives IP type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0173] The tenth identification information may be information included in the UE Policies IE.

[0174] Furthermore, the tenth identification information may include the maximum number of hops between two End UEs attempting ProSe Layer-3 multi-hop UE-to-UE Relay communication. Alternatively, a UE that has received the tenth identification information may determine the maximum number of hops between two End UEs attempting ProSe Layer-3 multi-hop UE-to-UE Relay communication based on the content indicated by the tenth identification information.

[0175] The eleventh identification information in this embodiment is ProSe Policy (ProSeP). More specifically, the eleventh identification information may be ProSeP when Layer-3 multi-hop UE-to-UE Relay is used in transmitting and receiving Ethernet-type or Unstructured-type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0176] In other words, the 11th identification information may be information indicating that the ProSeP is for multi-hop communication that transmits and receives Ethernet type or Unstructured type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0177] The eleventh identification information may be information included in the UE Policies IE.

[0178] Furthermore, the eleventh identification information may include the maximum number of hops between two End UEs attempting ProSe Layer-3 multi-hop UE-to-UE Relay communication. Alternatively, a UE that has received the tenth identification information may determine the maximum number of hops between two End UEs attempting ProSe Layer-3 multi-hop UE-to-UE Relay communication based on the content indicated by the eleventh identification information.

[0179] The twentieth identification information in this embodiment is a relay indication. Here, the relay indication indicated by the twentieth identification information may be information indicating that "The PROSE DIRECT LINK ESTABLISHMENT REQUEST message cannot be forwarded by a 5G ProSe UE-to-UE relay UE," that is, that the PROSE direct link establishment request message cannot be forwarded by a U2U Relay UE.

[0180] Alternatively, the relay indication indicated by the 20th identification information may be information indicating that "The PROSE DIRECT LINK ESTABLISHMENT REQUEST message can be forwarded by a 5G ProSe UE-to-UE relay UE," i.e., that the PROSE direct link establishment request message can be forwarded by a U2U Relay UE.

[0181] More specifically, for example, a U2U Relay UE that receives a message including a relay indication indicated by the 20th identification information may determine whether to relay the message in consideration of the content of the relay indication. Here, the message including the 20th identification information may be a ProSe Direct Link Establishment Request message. Furthermore, the U2U relay UE may determine whether to forward the ProSe Direct Link Establishment Request message in consideration of the 20th and / or 21st and / or 22nd identification information.

[0182] In other words, the content or parameters of the relay indication indicated by the 20th identification information may be used to indicate whether the U2U relay UE forwards the ProSe direct link establishment request message.

[0183] Furthermore, the U2U Relay UE may determine the content of the 20th identification information to be included in the message based on the relay indication indicated by the received 20th identification information and the 21st and 22nd identification information. Alternatively, the U2U Relay UE may determine whether to include the 20th identification information in the message based on the relay indication indicated by the received 20th identification information and the 21st and 22nd identification information.

[0184] The 21st identification information in this embodiment is the maximum number of hops between End UEs. More specifically, the 21st identification information may be the maximum number of hops between two End UEs attempting ProSe Layer-3 multi-hop UE-to-UE Relay communication. The 21st identification information may be a value determined by the UE based on or taking into consideration the 10th identification information.

[0185] The 22nd identification information in this embodiment may be the number of hops from the End UE.

[0186] More specifically, for example, when a U2U relay UE receives a message including 22nd identification information #1, and forwards the message, it may take into account the 20th and 21st identification information and forward a message including 22nd identification information #2, which is 22nd identification information #1 plus "1".

[0187] The 23rd identification information in this embodiment may be a cause value. More specifically, the 23rd identification information may be a cause value indicating that the number of hops from the source End UE has reached an upper limit in Layer-3 multi-hop UE-to-UE Relays communication. Here, the 23rd identification information may be a cause value included in a PC5 signaling protocol cause Information Element (IE).

[0188] Furthermore, the 23rd identification information may be a reason value indicating that the number of hops from the source End UE has reached an upper limit in Layer-3 multi-hop UE-to-UE Relays communication, or that a message will not arrive at the destination End UE because the number of hops from the source End UE has reached an upper limit. Here, the 23rd identification information may be identification information that is included in a direct link establishment rejection message and transmitted to the source End UE by a U2U Relay UE that recognizes that the number of hops from the source End UE has reached an upper limit in Layer-3 multi-hop UE-to-UE Relays communication, or that a message will not arrive at the destination End UE because the number of hops from the source End UE has reached an upper limit.

[0189] Furthermore, the 23rd identification information may be identification information that U2U Relay determines to include in the direct link establishment rejection message when the value indicated by the 23rd identification information included in the direct link establishment request message (DCR) is the same as or exceeds the value indicated by the 22nd identification information.

[0190] Details of the behavior of the UE and the network based on one or a combination of the above identification information 1 to 23 are not limited to those described in this chapter, but are also described in Chapter 4 and / or Chapter 5.

[0191] [4. Description of Procedures Used in Each Embodiment] Next, procedures used in each embodiment will be described. Here, the procedures used in each embodiment may include a registration procedure, a network-requested UE policy management procedure, a UE-requested ProSeP provisioning procedure, and a 5G ProSe UE-to-UE Relay communication procedure using integrated discovery.

[0192] In each embodiment, as shown in FIG. 2, the HSS and UDM, PCF and PCRF, SMF and PGW-C, and UPF and PGW-U are each configured as the same device (i.e., the same physical hardware, the same logical hardware, or the same software). However, the contents described in this embodiment are also applicable to cases where 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 these devices, 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.

[0193] [4.1. Registration Procedure] The registration procedure will be explained with reference to FIG.

[0194] The registration procedure is a procedure initiated and executed by the UE in 5GS. Hereinafter, in this section, this procedure is also referred to as the registration procedure. The registration procedure is a procedure initiated by the UE to register with the access network_B, and / or the core network_B, and / or the DN. If the UE is not registered with the network, it can execute this procedure at any time, for example, when it is powered on. In other words, if the UE is in the unregistered state (RM-DEREGISTERED state), it can start this procedure at any time. 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.

[0195] The registration procedure may be an initial registration initiated by the UE, or a mobility and periodic registration update, or a mobility registration update procedure. Here, the mobility registration update procedure may also be referred to as a registration procedure for mobility update. These registration procedures may also be MM procedures.

[0196] Furthermore, the registration procedure may 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 certain parameters related to the UE in the network.

[0197] In addition, in this procedure, each UE may be authorized by the network to perform multi-hop communication via two or more U2U relay UEs or to use a multi-hop function. Furthermore, after completing this procedure, each UE may initiate or perform the establishment of a ProSe Layer-3 multi-hop UE-to-UE Relay communication path and the ProSe Layer-3 multi-hop UE-to-UE Relay communication based on authorization from the network.

[0198] A UE may initiate a registration procedure when performing mobility across TAs. More specifically, a UE may initiate a Mobility Registration Update procedure to re-register when it moves to a TA different from the TA indicated in the TA list it holds. Furthermore, a UE may initiate this procedure when a running timer expires. Furthermore, a UE may initiate a registration procedure when a context update for each device is required due to a PDU session disconnection or invalidation. Furthermore, a UE may initiate a registration procedure when a change occurs in the capability information and / or preferences related to the establishment of a PDU session. Furthermore, a UE may initiate a registration procedure periodically. Furthermore, a UE may initiate a registration procedure based on the completion of a UE Configuration Update procedure. However, the UE may perform the registration procedure at any timing, not limited to these.

[0199] Furthermore, even when the UE is in a registered state, the UE may periodically initiate the registration procedure. In other words, the UE may initiate the registration procedure based on the expiration of a timer. In other words, the registration procedure performed periodically may be a periodic registration update procedure.

[0200] The registration procedure performed based on the mobility of the UE and the registration procedure performed periodically are also referred to as a registration procedure for mobility and registration update or a registration update procedure. In other words, the registration procedure for mobility and registration update may be a registration procedure performed based on the mobility of the UE, or may be a registration procedure performed periodically. Furthermore, the registration procedure for mobility and registration update may be a registration procedure performed based on a configuration update of the UE. Furthermore, the registration procedure for mobility and registration update may be a registration procedure performed to establish a communication path for transmitting and receiving user data. Furthermore, the registration procedure for mobility and registration update may be a registration procedure performed based on a request from the network. Furthermore, in other words, the registration procedure for mobility and registration update may be a registration procedure other than the initial registration procedure. Hereinafter, the registration procedure for mobility and registration update may be referred to as the main procedure.

[0201] Next, each step of the registration procedure will be described. Note that the registration procedure described below may be an initial registration procedure or a registration procedure for mobility and registration renewal.

[0202] First, the UE starts the registration procedure by sending a registration request message to the AMF (S600) (S602) (S604). Specifically, the UE sends an RRC message including a 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 transmitted and received between the UE and the 5G AN (or gNB). The NAS message is processed in the NAS layer, and the RRC message is processed in the RRC layer. The NAS layer is a layer higher than the RRC layer.

[0203] Here, the UE may transmit one or more of the first and second identification information to the network by including them in a registration request message and / or an RRC message. More specifically, the UE may transmit one or more of the first and second identification information by including them in a registration request message and / or an RRC message, or may transmit them in a control message different from these, for example, a control message of a layer lower than the RRC layer (for example, a MAC layer, an RLC layer, or a PDCP layer).

[0204] More specifically, for example, if the UE supports a Mobile Ad-hoc Network (MANET) routing protocol for transmitting and receiving IP type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication, the UE may transmit first identification information, which indicates that the UE supports a Mobile Ad-hoc Network (MANET) routing protocol for transmitting and receiving IP type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication, in a registration request message.

[0205] Alternatively, for example, if the UE does not support a Mobile Ad-hoc Network (MANET) routing protocol for transmitting and receiving IP-type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication, the UE may transmit a registration request message including first identification information indicating that the UE does not support a Mobile Ad-hoc Network (MANET) routing protocol for transmitting and receiving IP-type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication, or may transmit a registration request message without including the first identification information.

[0206] Furthermore, for example, if the UE supports Layer-3 multi-hop UE-to-UE Relay of Ethernet type or Unstructured type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication, the UE may transmit second identification information indicating that it supports Layer-3 multi-hop UE-to-UE Relay of Ethernet type or Unstructured type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication, by including it in the registration request message.

[0207] Alternatively, for example, if the UE does not support Layer-3 multi-hop UE-to-UE Relay of Ethernet type or Unstructured type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication, the UE may transmit a registration request message including second identification information indicating that the UE does not support Layer-3 multi-hop UE-to-UE Relay of Ethernet type or Unstructured type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication, or may transmit a registration request message without including the first identification information in the registration request message.

[0208] Here, when multiple pieces of identification information are transmitted 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. Note that the information indicating support for each function and the information indicating a request for use of the function may be transmitted and received as the same identification information, or may be transmitted and received as different identification information.

[0209] In addition, the UE may indicate to the network that the UE supports each function or indicate the UE's request by sending a registration request message including one or more of the first and second identification information.

[0210] Furthermore, the UE may include each piece of identification information in a registration request message and transmit it, thereby indicating to the network the contents indicated by the identification information included in the registration request message.

[0211] In addition, the UE may select and decide whether to include one or more of the first and second 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, etc.

[0212] When a 5G AN (or gNB) receives an RRC message including a registration request message, it selects an AMF to which to forward the registration request message (S602). Note that the 5G AN (or gNB) can select an AMF based on information included in the registration request message and / or the RRC message. The 5G AN (or gNB) extracts the registration request message from the received RRC message and forwards the registration request message to the selected AMF (S604).

[0213] The AMF receives a registration request message including one or more identification information from the first to second identification information, wherein the AMF that receives the registration request message including one or more identification information from the first to second identification information from the UE may recognize and store the meaning of the one or more identification information from the first to second identification information included in the registration request message.

[0214] More specifically, for example, when the AMF receives first identification information from the UE, it may recognize that the UE supports or does not support a MANET (Mobile Ad-hoc Network) routing protocol in transmitting and receiving IP type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0215] Also, for example, when the AMF receives second identification information from the UE, it may recognize that the UE supports or does not support Layer-3 multi-hop UE-to-UE Relay of Ethernet type or Unstructured type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0216] Furthermore, the AMF may determine whether the UE is authorized to use the ProSe Layer-3 multi-hop UE-to-UE Relay communication service based on one or more of the first to second identification information received from the UE. Furthermore, the AMF may authorize the UE to use the ProSe Layer-3 multi-hop UE-to-UE Relay communication service based on one or more of the first to second identification information received from the UE.

[0217] In addition, the AMF may transmit one or more pieces of identification information from the first to second identification information received from the UE to the PCF. In addition, the AMF may transmit one or more pieces of identification information approved by the network or the AMF from the first to second identification information received from the UE to the PCF.

[0218] When the AMF receives the registration request message, the AMF can perform a first condition determination. The first condition determination is for determining whether the network (or the AMF) accepts the UE's request. If the first condition determination is true, the AMF starts the procedure of (A) in Figure 6, while if the first condition determination is false, the AMF starts the procedure of (B) in Figure 6.

[0219] The first condition determination may be performed based on the reception of a registration request message, and / or each identification information included 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 a context held by the AMF, etc. For example, if the network permits the UE's request, the first condition determination may be true, and if the network does not permit the UE's request, the first condition determination may be false. Furthermore, if the network to which the UE is registered and / or a device within the network supports a function requested by the UE, the first condition determination may be true, and if the function requested by the UE is not supported, the first condition determination may be false. Furthermore, if the identification information to be transmitted and received is permitted, the first condition determination may be true, and if the identification information to be transmitted and received is not permitted, the first condition determination may be false. The conditions for determining whether the first condition determination is true or false do not have to be limited to the above-described conditions.

[0220] First, the case where the first condition is true will be described.

[0221] In the procedure of (A) in Fig. 6, the AMF transmits a registration accept message to the UE via the 5G AN (or gNB) as a response message to the registration request message (S608). Note that the registration accept message is an NAS message transmitted and received on the N1 interface, but is transmitted and received between the UE and the 5G AN (gNB) as part of an RRC message.

[0222] The AMF may also indicate that the UE's request has been accepted by sending a registration acceptance message based on each identification information, and / or subscription 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 AMF, etc. received from the UE.

[0223] More specifically, for example, the AMF may include any one or more of the third to fourth identification information in a registration accept message and send it to the UE.

[0224] More specifically, for example, if the network or AMF supports a MANET (Mobile Ad-hoc Network) routing protocol for transmitting and receiving IP type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication, the AMF may include third identification information indicating that it supports a MANET (Mobile Ad-hoc Network) routing protocol for transmitting and receiving IP type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication in a registration accept message and send it to the UE.

[0225] Alternatively, for example, if the network or AMF does not support a MANET (Mobile Ad-hoc Network) routing protocol for transmitting and receiving IP type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication, the AMF may send a registration accept message including a third identification information indicating that the network or AMF does not support a MANET (Mobile Ad-hoc Network) routing protocol for transmitting and receiving IP type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication, or may send a registration request message without including the third identification information in the registration accept message.

[0226] Also, for example, if the network or AMF supports Layer-3 multi-hop UE-to-UE Relay of Ethernet type or Unstructured type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication, the AMF may send third identification information indicating that it supports Layer-3 multi-hop UE-to-UE Relay of Ethernet type or Unstructured type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication in the registration accept message.

[0227] Or, for example, if the network or AMF does not support Layer-3 multi-hop UE-to-UE Relay of Ethernet type or Unstructured type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication, the AMF may send a registration request message including fourth identification information indicating that it does not support Layer-3 multi-hop UE-to-UE Relay of Ethernet type or Unstructured type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication, or may send a registration request message without including the fourth identification information in the registration request message.

[0228] Here, when multiple pieces of identification information are transmitted 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. Note that the information indicating support for each function and the information indicating a request for use of the function may be transmitted and received as the same identification information, or may be transmitted and received as different identification information.

[0229] Furthermore, the AMF may select and decide whether to include any one or more of the third to fourth identification information in the registration acceptance message based on each identification information received by the AMF from the UE or each device, 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 AMF, etc.

[0230] The AMF may also indicate that the UE's request has been accepted by sending a registration acceptance message based on the received identification information, and / or subscription 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 AMF, etc.

[0231] Furthermore, the AMF may include information indicating that some of the UE's requests have been rejected in the registration acceptance message and send it, or may indicate the reason why some of the UE's requests have been rejected by sending the information indicating that some of the UE's requests have been rejected. Furthermore, the UE may recognize the reason why some of the UE's requests have been rejected by receiving the information indicating that some of the UE's requests have been rejected. Note that the reason for the rejection may be information indicating that the content indicated by the identification information received by the AMF is not permitted.

[0232] The UE receives a registration acceptance message from the AMF via the 5G AN (gNB) (S608). By receiving the registration acceptance message, the UE can recognize that the UE's request via the registration request message has been accepted and the contents of various identification information included in the registration acceptance message.

[0233] More specifically, for example, the UE receives a registration message including one or more of the third to fourth identification information from the AMF (S608). Here, the UE that receives the registration accept message including one or more of the third to fourth identification information from the AMF may recognize and store the information indicated by one or more of the third to fourth identification information included in the registration accept message.

[0234] More specifically, for example, when the UE receives the third identification information from the AMF, the UE may recognize that the network or the AMF supports or does not support a MANET (Mobile Ad-hoc Network) routing protocol in transmitting and receiving IP type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0235] Furthermore, for example, when the UE receives third identification information from the AMF, the network or AMF may recognize that the Layer-3 multi-hop UE-to-UE Relay service using a MANET (Mobile Ad-hoc Network) routing protocol for sending and receiving IP type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication has been approved / authorized or not approved / authorized.

[0236] Also, for example, when the UE receives the fourth identification information from the AMF, the UE may recognize that the network or the AMF supports or does not support Layer-3 multi-hop UE-to-UE Relay of Ethernet type or Unstructured type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0237] Furthermore, for example, when the UE receives the fourth identification information from the AMF, the UE may recognize that the network or the AMF has approved / authorized or not approved / authorized the use of the Layer-3 multi-hop UE-to-UE Relay service for Ethernet type or Unstructured type traffic in the ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0238] The UE may also recognize that the AMF has authorized the use of the ProSe Layer-3 multi-hop UE-to-UE Relay communication service based on one or more of the third to fourth identification information received from the AMF.

[0239] Furthermore, the UE can send a Registration Complete message to the AMF via the 5G AN (gNB) as a response message to the registration accept message (S610). Here, the Registration Complete message is an NAS message transmitted and received on the N1 interface, but is transmitted and received between the UE and the 5G AN (gNB) as an RRC message.

[0240] The AMF may receive a registration completion message via the 5G AN (gNB) (S610). In addition, the UE and each device may complete the procedure of (A) in Figure 6 or complete the registration procedure based on the transmission and reception of the registration acceptance message and / or the registration completion message.

[0241] Next, a case where the first condition determination is false will be described. In the procedure of (B) of Fig. 6, the AMF transmits a Registration reject message to the UE via the 5G AN (gNB) as a response message to the Registration Request message (S612). Here, the Registration Reject message is an NAS message transmitted and received on the N1 interface, but is transmitted and received between the UE and the 5G AN (gNB) as an RRC message.

[0242] The AMF may also indicate that the UE's request has been rejected by sending a registration acceptance message based on each identification information, and / or subscription 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 AMF, etc. received from the UE.

[0243] Here, the AMF may send the registration rejection message including one or more of the fifth to sixth identification information.

[0244] More specifically, for example, the network or AMF may include a fifth identification information in a registration rejection message and send it to the UE, the fifth identification information indicating that the use of a MANET (Mobile Ad-hoc Network) routing protocol is not permitted for transmitting and receiving IP type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0245] Furthermore, when the AMF receives a registration request message including the first identification information from the UE, it may include the fifth identification information in the registration rejection message depending on the conditions.

[0246] Also, for example, the network or AMF may include sixth identification information in a registration rejection message and send it to the UE, indicating that the use of Layer-3 multi-hop UE-to-UE Relay for Ethernet type or Unstructured type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication is not permitted.

[0247] Furthermore, when the AMF receives a registration request message including the second identification information from the UE, it may include the sixth identification information in the registration rejection message depending on the conditions.

[0248] Here, when multiple pieces of identification information are transmitted and received, two or more of these pieces of identification information may be configured as one or more pieces of identification information. Note that the information indicating support for each function and the information indicating a request for use of each function may be transmitted and received as the same identification information, or may be transmitted and received as different identification information.

[0249] Furthermore, the AMF may select and decide whether to include one or more of the fifth and sixth identification information in the registration rejection message based on each identification information received by the AMF, 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 AMF, etc.

[0250] Furthermore, the AMF may indicate that the UE's request via the registration request message has been rejected by sending a registration rejection message. Furthermore, the AMF may include information indicating the reason for the rejection in the registration rejection message and send it, or may indicate the reason for the rejection by sending the reason for the rejection. Furthermore, the UE may recognize the reason for the rejection of the UE's request by receiving information indicating the reason for the rejection of the UE's request. Note that the reason for the rejection may be information indicating that the content indicated by the identification information received by the AMF is not permitted.

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

[0252] More specifically, for example, the UE may receive a registration rejection message from the AMF including one or more of the fifth to sixth identities.

[0253] More specifically, for example, when the UE receives the fifth identification information from the AMF, it may recognize that the use of a MANET (Mobile Ad-hoc Network) routing protocol is not permitted for sending and receiving IP type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0254] Also, for example, when the UE receives the sixth identification information from the AMF, it may recognize that the use of Layer-3 multi-hop UE-to-UE Relay for Ethernet type or Unstructured type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication is not permitted.

[0255] The procedure in FIG. 6(B) may be started when the procedure in FIG. 6(A) is stopped.

[0256] Each device completes the registration procedure based on the completion of the procedure of (A) or (B) in Figure 6. Note that each device may transition to a state in which the UE is registered in the network (RM-REGISTERED state) based on the completion of the procedure of (A) in Figure 6, or may maintain a state in which the UE is not registered in the network (RM-DEREGISTERED state) or transition to a state in which the UE is not registered in the network based on the completion of the procedure of (B) in Figure 6. Furthermore, the transition of each device to each state may be based on the completion of the registration procedure or the establishment of a PDU session.

[0257] The UE may also complete the registration procedure based on receiving a registration accept message or a registration reject message.

[0258] Furthermore, each device may perform processing based on the information transmitted and received during the registration procedure based on the completion of the registration procedure. For example, if the device transmits or receives information indicating that some of the UE's requests have been rejected, the device may recognize the reason why the UE's requests have been rejected. Furthermore, each device may perform this procedure again based on the reason why the UE's requests have been rejected, or may perform the registration procedure for the core network_B or another cell.

[0259] Furthermore, the UE may store the identification information received with the registration accept message and / or the registration reject message and may recognize the network's decision based on the completion of the registration procedure.

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

[0261] The behavior to be performed when each piece of identification information is received may be performed based on the received identification information.

[0262] [4.2. Network-requested UE policy management procedure] Next, the network-requested UE policy management procedure will be described with reference to Fig. 7. Hereinafter, 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.

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

[0264] Next, each step of this procedure will be described.

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

[0266] Here, the PCF may transmit to the UE a management UE policy command message including one or more of the tenth to eleventh identification information. The PCF may also transmit one or more of the tenth to eleventh identification information to indicate to the UE the content indicated by each identification information.

[0267] In addition, the PCF may select and / or decide whether to include one or more of the identification information from the 10th to 11th identification information in the management UE policy command message based on the state of the UE and / or information received from other NFs, etc.

[0268] The PCF may also determine whether to send a management UE policy command message and / or each identification information based on the state of the UE, and / or information received from the ProSe application server, and / or information received from other NFs, etc.

[0269] More specifically, for example, the PCF may determine whether to include one or more of the tenth to eleventh identification information in the management UE policy command message and send it based on the content of the UE's acceptance from the network during the registration procedure.

[0270] More specifically, for example, if, during a registration procedure, the UE requests the network for content indicated by the first identification information and this procedure is executed after the network accepts the content indicated by the third identification information, the PCF may send a management UE policy command including the tenth identification information to the UE. In other words, the tenth identification information may be information indicating ProSeP that is sent or provided from the network during the registration procedure to a UE that has been accepted to use a Mobile Ad-hoc Network (MANET) routing protocol for transmitting and receiving IP-type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0271] Furthermore, for example, if, during a registration procedure, the UE requests the content indicated by the second identification information from the network and this procedure is executed after the content indicated by the fourth identification information is accepted by the network, the PCF may send a management UE policy command including the tenth identification information to the UE. In other words, the eleventh identification information may be information indicating ProSeP that is sent or provided from the network during the registration procedure to a UE that has been accepted to use Layer-3 multi-hop UE-to-UE Relay for Ethernet-type or Unstructured-type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0272] Next, the UE receives a manage UE policy command message from the PCF via the AMF. The UE may also receive a manage UE policy command message from the PCF, the manage UE policy command message including one or more of the tenth to eleventh identities.

[0273] Furthermore, the UE may store each piece of identification information received with the manage UE policy command message based on receiving the manage UE policy command message, or may recognize the network's decision, and may recognize the content of the identification information received with the manage UE policy command message based on receiving the manage UE policy command message.

[0274] More specifically, for example, when the UE receives the tenth identification information, it may recognize and store that it is ProSeP when using the MANET (Mobile Ad-hoc Network) routing protocol in transmitting and receiving IP type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0275] Furthermore, for example, when a UE receives the eleventh identification information, it may recognize and store that the identification information is ProSeP when using Layer-3 multi-hop UE-to-UE Relay in transmitting and receiving Ethernet type or Unstructured type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0276] Furthermore, each UE that has received one or more of the tenth to eleventh identification information may perform a procedure or communication between End UEs that uses or takes into account the ProSe Policy indicated by one or more of the tenth to eleventh identification information in the ProSe UE-to-UE Relay communication procedure using integrated discovery, which will be described later.

[0277] Next, when the UE receives the Manage UE Policy Command message, the UE can perform a third condition determination. The third condition determination is for determining whether the UE accepts the network request. If the third condition determination is true, the UE starts the procedure shown in Figure 7(A). If the third condition determination is false, the UE starts the procedure shown in Figure 7(B).

[0278] The third condition determination may be performed based on the reception of a management UE policy command message, and / or each identification information, subscriber information, UE capability information, UE policy, UE state, and / or context held by the UE, etc., included in the management UE policy command message. For example, if the UE authorizes a network request, the third condition determination may be true, and if the UE does not authorize the network request, the third condition determination may be false. Also, if the UE supports a function requested by the network, the third condition determination may be true, and if the UE does not support the function requested by the network, the third condition determination may be false. Furthermore, if the identification information to be transmitted and received is authorized, the third condition determination may be true, and if the identification information to be transmitted and received is not authorized, the third condition determination may be false. The conditions for determining whether the third condition determination is true or false are not limited to the above-described conditions.

[0279] First, the case where the third condition is true will be described.

[0280] In the procedure of (A) of Figure 7, 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 manage UE policy command message (S702).

[0281] Next, the PCF receives a manage UE policy complete message from the UE via the AMF.

[0282] Furthermore, the PCF may store the identification information received with the managed UE policy complete message based on the reception of the managed UE policy complete message, or may recognize the UE's decision. Also, the PCF may recognize the content of the identification information received with the managed UE policy complete message based on the reception of the managed UE policy complete message.

[0283] Note that the above PCF behavior may be implemented after receiving a managed UE policy complete message.

[0284] In addition, when the PCF receives a managed UE policy complete message, the PCF may perform the behavior when receiving each piece of identification information included in the managed UE policy complete message.

[0285] The PCF may also forward each received identification information to another NF (e.g., a ProSe application server).

[0286] Each device may complete the procedure of FIG. 7(A) based on sending and receiving a Manage UE Policy Command message and / or a Manage UE Policy Complete message.

[0287] Next, a case where the third condition is false will be described.

[0288] In the procedure of (B) of Figure 7, 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 manage UE policy command message (S704).

[0289] The PCF then receives a management UE policy command reject message from the UE via the AMF.

[0290] Furthermore, the PCF may, based on receipt of the Manage UE Policy Command Reject message, store the identification information received with the Manage UE Policy Command Reject message and recognize the UE's decision. Also, the PCF may, based on receipt of the Manage UE Policy Command Reject message, recognize the content of the identification information received with the Manage UE Policy Command Reject message.

[0291] It should be noted that the above PCF behavior may be implemented after receiving a Management UE Policy Command Reject message.

[0292] In addition, when the PCF receives a manage UE policy command reject message, the PCF may implement the behavior upon receiving each piece of identification information included in the manage UE policy command reject message.

[0293] The PCF may also forward each received identification information to another NF (e.g., a ProSe application server).

[0294] Each device may complete the procedure of FIG. 7(B) based on sending and receiving the manage UE policy command message and / or the manage UE policy command reject message.

[0295] Furthermore, each device may complete a network-requested UE policy management procedure based on the completion of the above-mentioned processing, 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.

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

[0297] Furthermore, based on the completion of the network-requested UE policy management procedure, the UE may add a new UE policy, change a UE policy stored in the UE, or delete a UE policy stored in the UE.

[0298] [4.3. UE-requested ProSeP provisioning procedure] Next, the UE-requested ProSeP provisioning procedure will be described with reference to FIG. 8. Hereinafter, the UE-requested ProSeP provisioning procedure will also be referred to as this procedure. Note that this procedure may be initiated by the UE.

[0299] This procedure may be initiated based on or in conjunction with the completion of a registration procedure, or may be initiated when the UE requests a UE policy or a ProSe policy.

[0300] This procedure may also be a procedure executed to update ProSeP upon expiration of a timer indicating each validity period set for each ProSeP indicated by the 10th and / or 11th identification information set in the UE or stored by the UE.

[0301] Next, each step of this procedure will be described.

[0302] First, the UE sends a UE policy provisioning request message to the PCF via the AMF (S800).

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

[0304] Furthermore, based on receiving the UE policy provision request message, the PCF may store the identification information received with the UE policy provision request message, recognize the network decision, and based on receiving the UE policy provision request message, recognize the content of the identification information received with the UE policy provision request message.

[0305] Note that the above PCF behavior may be implemented after receiving a UE Policy Command message.

[0306] In addition, when the PCF receives a UE policy provision request message, the PCF may perform the behavior when it receives each piece of identification information included in the UE policy provision request message.

[0307] When the PCF receives the UE policy provision request message, the PCF can perform a fourth condition determination. The fourth condition determination is for determining whether the network accepts the UE request. If the fourth condition determination is true, the PCF starts the procedure in Figure 8 (A). If the fourth condition determination is false, the PCF starts the procedure in Figure 8 (B).

[0308] The fourth condition determination may be performed based on the reception of the UE policy provision request message, and / or the identification information included in the UE policy provision request message, and / or the subscriber information, and / or the network capability information, and / or the operator policy, and / or the network status, and / or the user registration information, and / or the context held by the PCF. For example, if the network permits the UE request, the fourth condition determination may be true, and if the network does not permit the UE request, the fourth condition determination may be false. Furthermore, if the network to which the UE is registered and / or a device within the network supports the function requested by the UE, the fourth condition determination may be true, and if the function requested by the UE is not supported, the fourth condition determination may be false. Furthermore, if the identification information to be transmitted and received is permitted, the fourth condition determination may be true, and if the identification information to be transmitted and received is not permitted, the fourth condition determination may be false. The conditions for determining whether the fourth condition determination is true or false are not limited to the above-described conditions.

[0309] First, the case where the fourth condition is true will be described.

[0310] In the procedure of (A) of Figure 8, the PCF may perform a network-requested policy management procedure (S802). Here, the network-requested policy management procedure may be the procedure described in the above-mentioned network-requested UE policy management procedure (Chapter 4.2).

[0311] Each device may complete the procedure of (A) in FIG. 8 based on sending and receiving a UE policy provision request message and / or completing a network-requested policy management procedure.

[0312] Next, a case where the fourth condition is false will be described.

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

[0314] The PCF may also determine whether to send a UE policy provision rejection message and / or each identification information based on the state of the UE, and / or information received from the ProSe application server, and / or information received from other NFs, etc.

[0315] The UE then receives a UE policy provision rejection message from the PCF via the AMF.

[0316] Furthermore, the UE may store the identification information received together with the UE policy provision rejection message based on receiving the UE policy provision rejection message, or may recognize the network's decision. Also, the UE may recognize the content of the identification information received together with the UE policy provision rejection message based on receiving the UE policy provision rejection message.

[0317] It should be noted that the above UE behavior may be implemented after receiving a UE policy provision rejection message.

[0318] Furthermore, when the UE receives a UE policy provision rejection message, the UE may perform the behavior it performs when it receives each piece of identification information included in the UE policy provision rejection message.

[0319] Each device may complete the procedure of (B) in FIG. 8 based on sending and receiving the UE policy provision request message and / or the UE policy provision rejection message.

[0320] Furthermore, each device may complete this procedure based on completion of the above-mentioned processing, and / or sending and receiving a UE policy provision request message, and / or completing a network-requested policy management procedure, and / or sending and receiving a UE policy provision rejection message.

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

[0322] Furthermore, based on the completion of this procedure, the UE may add a new UE policy, change the UE policy stored in the UE, or delete the UE policy stored in the UE.

[0323] [4.4 5G ProSe UE-to-UE Relay Communication Procedure with Integrated Discovery] The 5G ProSe UE-to-UE Relay communication procedure with integrated discovery is described using Figure 9. In this section, the 5G ProSe UE-to-UE Relay communication procedure with integrated discovery is also referred to as this procedure. The 5G ProSe UE-to-UE Relay communication procedure with integrated discovery may also be a procedure that combines the U2U relay discovery procedure and the direct link establishment procedure.

[0324] In this section, using Figure 9, we will show an example of establishing a three-hop communication path consisting of four UEs: source End UE, U2U Relay UE#1, U2U Relay UE#2, and destination End UE, and transmitting and receiving user data.

[0325] This procedure may be a procedure for 5G Prose UE-to-UE Relay communication by joint discovery via Layer-3 UE-to-UE Relay, or may be a procedure for establishing a communication path for multi-hop communication between End UEs via two or more UE-to-UE Relays.

[0326] This procedure may be performed multiple times. In other words, after this procedure is completed, it may be started again.

[0327] In this procedure, the UE that sends the request message may be referred to as the initiating UE. In other words, the initiating UE may be the UE that sends the PROSE direct link establishment request message. That is, the initiating UE in this procedure may be an End UE and / or a U2U Relay UE.

[0328] A UE other than the initiating UE may be referred to as a target UE. A UE that receives the request message may be referred to as a target UE. In other words, the target UE may be a UE that sends a PROSE direct link establishment accept message or a PROSE direct link establishment reject message.

[0329] Furthermore, in this procedure, the End UE (source End UE or destination End UE) and the U2U Relay UE, and / or the U2U Relay and the U2U Relay UE may transmit and receive various control messages or user data via PC5.

[0330] Next, each step of this procedure will be described.

[0331] Here, this procedure may be executed after each UE completes the registration procedure. Also, this procedure may be initiated in a state where a service is authorized for each UE and parameters are provisioned for each UE. More specifically, for example, this procedure may be initiated in a state where an End UE is authorized and provisioned with parameters for using a service provided by the U2U Relay UE. Also, this procedure may be initiated in a state where the U2U Relay UE is authorized and provisioned with parameters for providing a service to relay traffic between two End UEs.

[0332] First, a direct communication request (DCR) message is repeatedly broadcast and forwarded by each UE from a source end UE via U2U Relay #1 and U2U Relay #2 until it reaches a destination end UE (S902). Here, in this specification, the DCR message is also simply referred to as DCR. Note that in this specification, a direct communication request (DCR) message, a direct communication request message, and a ProSe direct link establishment request (PROSE DIRECT LINK ESTABLISHMENT REQUEST) message may be the same. In other words, in this specification, the direct communication request message (DCR) may be read as a ProSe direct link establishment request message. Also, in this specification, the ProSe direct link establishment request message may be read as a direct communication request message (DCR). Also, in this specification, the ProSe direct link establishment request message (PROSE DIRECT LINK ESTABLISHMENT REQUEST) message is also simply referred to as a direct link establishment request message.

[0333] Here, in S902, each Direct Communication Request message (DCR) transmitted and received may include one or more pieces of identification information from the twentieth to twenty-first identification information.

[0334] Furthermore, at S902 during this procedure, the U2U relay UE that receives the DCR may determine the content of the 20th identification information or whether to include the 20th identification information, taking into account the 21st and / or 22nd identification information.

[0335] Also, at S902 during this procedure, a U2U relay UE that receives a DCR including the 20th identification information or a DCR not including the 20th identification information, indicating that the message cannot be forwarded, may recognize that the message cannot be forwarded or that the message cannot be forwarded.

[0336] More specifically, the source End UE broadcasts a DCR#1 message, and U2U Relay UE#1 receives DCR#1. Next, U2U Relay #1 broadcasts DCR#2, and U2U Relay UE#2 receives DCR#2. Furthermore, U2U Relay UE#2 broadcasts DCR#3, and the destination End UE receives DCR#3.

[0337] Furthermore, DCR#2 may be a message based on DCR#1, or may be a message generated by U2U Relay UE#1 by modifying the contents of DCR#1 received by DCR#1. More specifically, for example, the 22nd identification information included in DCR#2 may be a value obtained by adding 1 to the value indicated by the 22nd identification information included in DCR#1. That is, U2U Relay UE#1 may add 1 to the value indicating the number of hops from the source End UE, which is included in the received DCR#1. Furthermore, U2U Relay UE#1 may generate DCR#2 by adding its own ID (e.g., UE ID, etc.) and / or address, etc., to DCR#1 as a list.

[0338] Furthermore, DCR#3 may also be a message modified by U2U Relay UE#2 in the same manner as DCR#2. Here, U2U Relay UE#2 may also generate DCR#3 by adding its own ID or address to the list in addition to the ID of U2U relay UE#1 added to DCR#2.

[0339] Here, the list of IDs or addresses of U2U Relays included in each DCR may be used by the U2U Relay UE or the destination End UE to recognize the route to the source End UE. Furthermore, when a U2U Relay UE receives a broadcasted DCR including its own ID or address, it may ignore or discard the message.

[0340] Next, the destination End UE that has received the DCR (DCR#3) may perform relay selection (S904).

[0341] More specifically, it may be an operation of selecting a U2U Relay UE to send a response or a response message when a destination End UE receives DCRs from the same source End UE from different U2U Relays. Note that the relay selection may be performed according to signal strength, and / or local policy, and / or operator policy for each Relay Service Code (RSC), etc.

[0342] FIG. 9 may be an example in which the destination End UE selects U2U Relay #2.

[0343] Next, the destination End UE may transmit a response message to the direct link establishment request message (DCR) to the U2U Relay UE#2 selected in the relay selection (S906). Here, the response message to the DCR may be a direct link establishment acceptance message or a direct link establishment rejection message. Note that the response message to the DCR transmitted by the destination End UE may be transmitted by unicast.

[0344] Upon receiving the response message for the DCR from the destination End UE, the U2U Relay UE #2 may forward the response message to the U2U Relay UE #1 (S908). Note that the forwarding in this step may be performed by unicast.

[0345] Furthermore, the U2U Relay UE #1 may forward the response message received from the U2U Relay UE #2 to the source End UE (S910). Note that the forwarding in this step may be performed by unicast.

[0346] Here, the destination End UE does not need to include the identification information of the 20th to 21st identification information in the response message to the DCR transmitted and received from S906 to S910. Alternatively, the destination End UE may include the identification information of the 20th to 21st identification information in the response message to the DCR transmitted and received from S906 to S910.

[0347] Furthermore, the destination End UE may include a list of U2U Relay IDs or addresses in the DCR (DCR#3) received by the destination End UE in the response message to the DCR transmitted in S906. U2U Relay UE #2 and U2U Relay UE #1, which receive response messages including the list of U2U Relay IDs or addresses in S908 and S910, may forward the response messages based on the list of U2U Relay IDs or addresses.

[0348] If the response message to the DCR sent from the destination End UE is a direct link establishment acceptance message, a communication path may be established between the source End UE and the destination End UE via U2U Relay UE#1 and U2U Relay UE#2.

[0349] In this embodiment, the established communication path between the end UEs may be capable of transmitting and receiving any one of IP (Internet Protocol), Ethernet, and Unstructured traffic. Note that the source end UE may indicate to each UE in a direct link establishment request message which type of traffic connectivity is to be established.

[0350] Furthermore, the source End UE and the destination End UE may perform communication using any of the following types: IP (Internet Protocol), Ethernet, or Unstructured via the communication path established via U2U Relay UE #1 and U2U Relay UE #2 (S912).

[0351] In addition, the ProSe direct link establishment request message or the direct communication request message transmitted and received in S902 of this procedure may be transmitted by broadcast at the discretion of each UE.

[0352] In addition, messages transmitted and received in S906, S908, S910, and S912 of this procedure may be transferred by unicast between each UE. Here, the messages transmitted and received in S906, S908, and S910 may be ProSe direct link establishment accept messages or ProSe direct link establishment reject messages. Furthermore, transmission and reception of user data between End UEs via two or more U2U Relay UEs may be transmitted and received by unicast for each segment (between a pair of two U2U Relays).

[0353] On the other hand, at S902 during this procedure, if the U2U relay UE and / or End UE receives a DCR and recognizes that the DCR message cannot be forwarded or that the message cannot be forwarded, it may send a direct link establishment rejection message addressed to the source End UE to the source U2U Relay UE or source End UE of the DCR message.

[0354] Although an example of three-hop communication between End UEs via two U2U Relay UEs has been shown above in this procedure, the number of U2U Relays may be two or more.

[0355] More specifically, for example, U2U Relay UE #3 and / or U2U Relay UE #4 may exist between U2U Relay UE #2 and the destination End UE, and communication between End UEs may be performed over four or more hops. In this case, each UE may perform the processing or behavior described in each step of this procedure. Furthermore, the same processing or behavior may be performed when receiving a message from a U2U Relay and forwarding it to the U2U Relay.

[0356] [5. Embodiments] Next, each embodiment of this example will be described. Note that each embodiment described in this chapter is based on the definitions of terms and various identification information explained in Chapter 3, and the procedures explained in Chapter 4. In addition, in this chapter, each embodiment described in this chapter will also be referred to as each embodiment of this chapter, or simply each embodiment.

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

[0358] More specifically, for example, each UE of this embodiment may execute the first embodiment and then execute the second to fourth embodiments.

[0359] Each embodiment will be described below.

[0360] [5.1. First embodiment] A first embodiment of this example will be described. Hereinafter, in this section, the first embodiment will also be referred to as this embodiment.

[0361] This embodiment relates to a response from the network to a registration request message including UE capability information that is sent by the UE to the network during the registration procedure described in Chapter 4.1, and to the provision of ProSeP after the registration procedure.

[0362] In the following, this section will explain the information sent and received in the registration procedure, and / or the network-requested UE policy management procedure, and / or the UE-requested ProSeP provision procedure, as well as the behavior of each device in the UE and network.

[0363] In this embodiment, in the registration procedure, the UE sends a registration request message including the first and / or second identification information to the network, and receives a registration accept message including the third and / or fourth identification information to complete the registration procedure.

[0364] Further, after the registration procedure is completed, in the network-requested UE policy management procedure, the PCF sends a manage UE policy command message to the UE, including the tenth and / or eleventh identification information, to complete the network-requested UE policy management procedure.

[0365] Here, the network or PCF may provide the UE with ProSeP corresponding to a ProSe Layer-3 multi-hop UE-to-UE Relay communication method supported by both the UE and the network, among the capability information corresponding to the ProSe Layer-3 multi-hop UE-to-UE Relay communication method indicated by the UE to the network in the registration request. Note that the ProSe Layer-3 multi-hop UE-to-UE Relay communication method may be communication using a MANET (Mobile Ad-hoc Network) routing protocol for transmitting and receiving IP type traffic, or communication using Layer-3 multi-hop UE-to-UE Relay for Ethernet type or Unstructured type traffic.

[0366] More specifically, for example, in a registration procedure, if the UE sends a registration request message including first and second identification information to the network and receives a registration accept message including third and fourth identification information from the network, in a network-requested UE policy management procedure, the PCF may send a manage UE policy command message including tenth and eleventh identification information to the UE.

[0367] Or, for example, in a registration procedure, if the UE sends a registration request message including a first identification to the network and receives a registration accept message including a third identification from the network, in a network-requested UE policy management procedure, the PCF may send a manage UE policy command message including a tenth identification to the UE.

[0368] Alternatively, in a registration procedure, for example, if the UE sends a registration request message including the second identification information to the network and receives a registration accept message including the fourth identification information from the network, in a network-requested UE policy management procedure, the PCF may send a manage UE policy command message including the eleventh identification information to the UE.

[0369] Or, for example, in a registration procedure, if the UE sends a registration request message including the first and second identification information to the network and receives a registration accept message including the third identification information from the network, in a network-requested UE policy management procedure, the PCF may send a manage UE policy command message including the tenth identification information to the UE.

[0370] Or, for example, in a registration procedure, if the UE sends a registration request message including the first and second identification information to the network and receives a registration accept message including the fourth identification information from the network, in a network-requested UE policy management procedure, the PCF may send a manage UE policy command message including the eleventh identification information to the UE.

[0371] Or, for example, in a registration procedure, if the UE sends a registration request message to the network including the first and second identification information and receives a registration accept message from the network that does not include the third and fourth identification information, then in a network-requested UE policy management procedure, the PCF may send a manage UE policy command message to the UE including the tenth and eleventh identification information.

[0372] Here, if the network does not support one or more of the capability information corresponding to the ProSe Layer-3 multi-hop UE-to-UE Relay communication method indicated by the UE in the registration request to the network, or if the network rejects the registration request, the network or PCF does not need to provide the UE with ProSeP, which is the ProSe Layer-3 multi-hop UE-to-UE Relay communication method. Note that the ProSe Layer-3 multi-hop UE-to-UE Relay communication method may be communication using a MANET (Mobile Ad-hoc Network) routing protocol for transmitting and receiving IP-type traffic, or communication using Layer-3 multi-hop UE-to-UE Relay for Ethernet-type or unstructured-type traffic.

[0373] More specifically, for example, in a registration procedure, if the UE sends a registration request message including the first and / or second identification information to the network and receives a registration rejection message including the fifth and / or sixth identification information from the network, the network or PCF may not perform a network-requested UE policy management procedure, and the PCF may not provide the UE with the ProSeP indicated by the tenth and eleventh identification information.

[0374] Or, for example, in a registration procedure, if the UE sends a registration request message including the first and / or second identification information to the network and receives a registration accept message from the network that does not include the third and fourth identification information, the network or PCF does not need to perform a network-requested UE policy management procedure, and the PCF does not need to provide the UE with the ProSeP indicated by the tenth and eleventh identification information.

[0375] As described above, for example, the UE of this embodiment first transmits a registration request message including first and second identification information to the network in the registration procedure.

[0376] Here, the first identification information is capability information indicating that the UE supports a Mobile Ad-hoc Network (MANET) routing protocol for transmitting and receiving IP-type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication, and the second identification information is information indicating that the UE supports Layer-3 multi-hop UE-to-UE Relay of Ethernet-type or Unstructured-type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0377] The UE receives a registration accept message in response to the registration request message from the network, and the UE and the network devices complete the registration procedure, where the registration accept message received by the UE may include the third and fourth identification information.

[0378] Subsequently, the network or the PCF may initiate a network-requested UE policy management procedure based on the completion of the registration procedure. Furthermore, the PCF may send a manage UE policy command message including tenth and eleventh identification information to the UE in the network-requested UE policy management procedure. Furthermore, the UE may receive the manage UE policy command message including the tenth and eleventh identification information from the PCF via the AMF. Here, the tenth identification information may be ProSeP when a Mobile Ad-hoc Network (MANET) routing protocol is used for transmitting and receiving IP-type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication. Furthermore, the eleventh identification information may be ProSeP when a Layer-3 multi-hop UE-to-UE Relay is used for transmitting and receiving Ethernet-type or Unstructured-type traffic in ProSe Layer-3 multi-hop UE-to-UE Relay communication.

[0379] The network or PCF may also determine a tenth identification based on the first identification, and may also determine an eleventh identification based on the second identification.

[0380] [5.2. Second Embodiment] A second embodiment of this example will be described. In this section, the second embodiment will also be referred to as the present embodiment. Note that the second embodiment may be an embodiment executed after the first embodiment. Also, this embodiment is an embodiment related to the behavior of U2U Relay UE.

[0381] This embodiment may be an embodiment in which, in the 5G ProSe UE-to-UE Relay communication procedure using integrated discovery described in Chapter 4.4, the source End UE transmits a Direct Communication Request (DCR) message including the 20th, 21st, and 22nd identification information.

[0382] Here, the source End UE transmits to U2U Relay UE #1 DCR#1 including the 20th identification information, the 21st identification information in which the maximum hop count is set to "1", the 22nd identification information in which the hop count from the source End UE is set to "1", and a list of the IDs and / or addresses of the source End UE.

[0383] Next, U2U Relay UE #1 evaluates the information contained in DCR#1 received from the source End UE and may determine that DCR#1 is capable of forwarding and / or requires forwarding. U2U Relay UE #1 then transmits DCR#2 to U2U Relay UE #2, which includes, in DCR#1, the 20th identification information, the 21st identification information in which the maximum number of hops is set to "2", the 22nd identification information in which the number of hops from the source End UE is set to "2", and a list of IDs and / or addresses of the source End UE and U2U Relay UE #2.

[0384] Here, the 20th identification information included by U2U Relay UE #1 in DCR #2 may be "The PROSE DIRECT LINK ESTABLISHMENT REQUEST message cannot be forwarded by a 5G ProSe UE-to-UE relay UE." Alternatively, U2U Relay UE #1 may not include the 20th identification information in DCR #2. In other words, the contents of the 20th identification information or whether to include the 20th identification information in the message (DCR #2) may be determined or decided based on the fact that DCR #2 in which the same values ​​are set for the 21st identification information and the 22nd identification information is not capable of further forwarding.

[0385] U2U Relay UE #2 may then evaluate the information contained in DCR#2 received from the source End UE and determine that DCR#2 does not allow and / or require forwarding.

[0386] The behavior of each UE during the transition will be described in detail in a third embodiment below.

[0387] As described above, for example, U2U Relay UE#1 of this embodiment receives a direct link establishment request message including identification information 20, 21, and 22 from the source End UE in a 5G ProSe UE-to-UE Relay communication procedure using integrated discovery.

[0388] Here, the 20th identification information may be a relay indication, the 21st identification information may be an upper limit of the number of hops between End-to-End UE, and the 22nd identification information may be the number of hops from the sender to the first UE-to-UE relay UE. Note that the 20th identification information may be "The PROSE DIRECT LINK ESTABLISHMENT REQUEST message can be forwarded by a 5G ProSe UE-to-UE relay UE."

[0389] Furthermore, if the value indicated by the 22nd identification information is smaller than the value indicated by the 21st identification information, the U2U Relay UE#1 may decide to forward the direct link establishment request message based on or taking into consideration the 20th identification information.

[0390] Subsequently, based on the above-mentioned determination, the U2U Relay UE#1 may forward or transmit a direct link establishment request message including the 20th, 21st, and 22nd identification information. Here, the 22nd identification information included in the direct link establishment request message forwarded by the U2U Relay UE#1 may be set to a value obtained by adding "1" to the 22nd identification information included in the direct link establishment request message received by the U2U Relay UE#1.

[0391] [5.3. Third Embodiment] A third embodiment of this example will be described. In this section, the third embodiment will also be referred to as the present embodiment. Note that the third embodiment may be an embodiment executed after the first embodiment. Also, this embodiment is an embodiment related to the behavior of U2U Relay UE.

[0392] This embodiment may be an embodiment in which, in the 5G ProSe UE-to-UE Relay communication procedure using integrated discovery described in Chapter 4.4, the source End UE transmits a Direct Communication Request (DCR) message including the 20th, 21st, and 22nd identification information.

[0393] Here, the source End UE broadcasts DCR#1 including the 20th identification information, the 21st identification information in which the maximum hop count is set to "1", the 22nd identification information in which the hop count from the source End UE is set to "1", and a list of the ID and / or address of the source End UE.

[0394] Next, U2U Relay UE #1, which receives DCR#1 broadcast by the source End UE, evaluates the information contained in DCR#1 and may recognize that DCR#1 is possible and / or requires forwarding. U2U Relay UE #1 broadcasts DCR#2 to DCR#1, which includes 20th identification information, 21st identification information in which the maximum number of hops is set to "2", 22nd identification information in which the number of hops from the source End UE is set to "2", and a list of IDs and / or addresses of the source End UE and U2U Relay UE #1.

[0395] Here, the 20th identification information included by U2U Relay UE #1 in DCR #2 may be "The PROSE DIRECT LINK ESTABLISHMENT REQUEST message cannot be forwarded by a 5G ProSe UE-to-UE relay UE." Alternatively, U2U Relay UE #1 may not include the 20th identification information in DCR #2. In other words, the contents of the 20th identification information or whether to include the 20th identification information in the message (DCR #2) may be determined or decided based on the fact that DCR #2 in which the same values ​​are set for the 21st identification information and the 22nd identification information is not capable of further forwarding.

[0396] Next, U2U Relay UE #2, which receives DCR#2 broadcast by U2U Relay UE #1, may evaluate the information contained in DCR#2 and recognize that DCR#2 is not capable of forwarding and / or does not require forwarding.

[0397] When U2U Relay UE #2 recognizes that DCR#2 is not capable of forwarding and / or does not need forwarding, it may transmit a direct link establishment rejection message addressed to the source End UE. Here, the direct link establishment rejection message transmitted by U2U Relay UE #2 may be transmitted to the source End UE via U2U relay UE#1. Furthermore, the direct link establishment rejection message transmitted and received between each UE may be a message transmitted and received by unicast.

[0398] Here, the direct link establishment rejection message may be sent including the 23rd identification information and / or a list of IDs and / or addresses of the U2U Relay UEs through which the message passed before reaching the source End UE and U2U Relay UE #2.

[0399] Furthermore, the 23rd identification information may be a reason value indicating that in Layer-3 multi-hop UE-to-UE Relays communication, the number of hops from the source End UE has reached an upper limit, or that the message cannot reach the destination End UE because the number of hops from the source End UE has reached an upper limit.

[0400] As described above, for example, U2U relay #2 in this embodiment receives a direct link establishment request message including identification information 21 and 22 from U2U relay #1 in a 5G ProSe UE-to-UE Relay communication procedure using integrated discovery.

[0401] Here, the 21st identification information may be an upper limit of the number of hops between End-to-End UE, and the 22nd identification information may be the number of hops from the source to the first UE-to-UE relay UE.

[0402] Next, based on the 21st and 22nd identification information included in the direct link establishment request message, U2U Relay UE #2 may recognize that the number of hops has reached the upper limit and therefore forwarding of the direct link establishment request message is not possible and / or not necessary.

[0403] Furthermore, based on the recognition, the U2U Relay UE #2 may transmit a direct link establishment rejection message including 23rd identification information to the source End UE via the UE-to-UE Relay UE #1, where the 23rd identification information may be a reason value indicating that the number of hops in the Layer-3 multi-hop UE-to-UE Relays communication has reached an upper limit or maximum value.

[0404] Here, the direct link establishment rejection message including the 23rd identification information that the U2U Relay UE #2 sends to the source End UE via the UE-to-UE Relay UE #1 may further include the 20th identification information. Here, the 20th identification information may be "The PROSE DIRECT LINK ESTABLISHMENT REQUEST message can be forwarded by a 5G ProSe UE-to-UE relay UE," i.e., a relay indication indicating that it is possible to forward the direct link establishment rejection message.

[0405] [5.4. Fourth Embodiment] A fourth embodiment of this example will be described. In this section, the fourth embodiment will also be referred to as the present embodiment. Note that the fourth embodiment may be an embodiment that is performed after the first embodiment.

[0406] In the transmission, reception, or forwarding of a direct link establishment rejection message, as also described in the third embodiment, the U2U Relay UE of this embodiment may decide to forward the direct link establishment rejection message received from the destination End UE or U2U relay UE to the U2U Relay UE or the source End UE, and may perform the forwarding.

[0407] Here, the direct link establishment rejection message may be transmitted or forwarded by unicast between U2U Relay UEs or between a U2U Relay UE and an End UE. Furthermore, the direct link establishment rejection message may be forwarded based on a list of addresses added by each U2U Relay UE that relays the direct link establishment request message described in the second and third embodiments.

[0408] From the above, for example, when this embodiment is executing the establishment of a communication path between End UEs via three U2U Relays, when U2U Relay UE#2 receives a direct link establishment rejection message including the 20th and / or 23rd identification information from U2U Relay UE#3 in a 5G ProSe UE-to-UE Relay communication procedure using integrated discovery, it may decide to forward or transmit the direct link establishment rejection message to U2U Relay #1 based on the 20th identification information.

[0409] Here, the 20th identification information may be a relay indication indicating that it is possible to forward the direct link establishment rejection message, and the 23rd identification information may be a reason value indicating that the number of hops in the Layer-3 multi-hop UE-to-UE Relays communication has reached an upper limit.

[0410] Based on the above determination, U2U Relay UE #2 may send a direct link establishment rejection message including the 20th and / or 23rd identification information to U2U Relay UE #1.

[0411] Furthermore, U2U Relay UE #1, which has received a direct link establishment rejection message including the 20th and / or 23rd identification information from U2U Relay UE #2, may determine to transmit the direct link establishment rejection message to the source End UE or the U2U Relay UE based on the 20th and / or 23rd identification information, and may transmit the message. [6. Modifications] A program running on an apparatus according to one aspect of this embodiment may be a program that controls a Central Processing Unit (CPU) or the like to cause a computer to function so as to realize the functions of an embodiment according to one aspect of this embodiment. The program or information handled by the program is temporarily stored in a volatile memory such as a random access memory (RAM), a non-volatile memory such as a flash memory, a hard disk drive (HDD), or another storage device system.

[0412] A program for realizing the functions of an embodiment according to one aspect of this example may be recorded on a computer-readable recording medium. The program may be read into a computer system and executed. The term "computer system" as used herein refers to a computer system built into a device, including hardware such as an operating system and peripheral devices. The term "computer-readable recording medium" may refer to a semiconductor recording medium, an optical recording medium, a magnetic recording medium, a medium that dynamically stores a program for a short period of time, or any other computer-readable recording medium.

[0413] Additionally, each functional block or feature of the device used in the above-described embodiments may be implemented or performed by an electrical circuit, such as an integrated circuit or multiple integrated circuits. The 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, or a conventional processor, controller, microcontroller, or state machine. The electrical circuit may be composed of digital circuits or analog circuits. Furthermore, as advances in semiconductor technology emerge, one or more aspects of the present embodiments may utilize new integrated circuit technologies that replace current integrated circuits.

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

[0415] Although the embodiment of this example has been described in detail above with reference to the drawings, the specific configuration is not limited to this embodiment, and design modifications within the scope of this example are also included. Furthermore, various modifications of this example are possible 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 example. Furthermore, configurations in which elements described in each of the above embodiments are substituted with elements that achieve the same effect are also included.

[0416] One aspect of this embodiment can be used, for example, in a communication system, a communication device (e.g., a mobile phone device, a base station device, a wireless LAN device, or a sensor device), an integrated circuit (e.g., a communication chip), or a program.

[0417] 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. A UE (User Equipment) comprising a transceiver unit and a controller, the UE being a third UE-to-UE relay UE, wherein in a 5G ProSe UE-to-UE Relay communication procedure using integrated discovery, the transceiver unit receives a direct link establishment request message from a second UE-to-UE relay UE, the direct link establishment request message including fifth and sixth information, the fifth information being an upper limit of the number of hops between End-to-End UEs, and the sixth information being the number of hops from a sender to a first UE-to-UE relay UE, the controller recognizing, based on the fifth and sixth information, that the received message cannot be forwarded because the number of hops has reached the upper limit, and the transceiver unit, based on the recognition of the controller, transmits a direct link establishment rejection message including seventh information to the second UE-to-UE relay UE, the seventh information being a reason value indicating that the number of hops in Layer-3 multi-hop UE-to-UE Relay communication has reached the upper limit.

2. The UE according to claim 1, wherein the transceiver unit further includes fourth information in a direct link establishment rejection message including the seventh information and transmits the message to a second UE-to-UE relay UE, the fourth information being a relay indication indicating that the direct link establishment rejection message can be forwarded.

3. A UE (User Equipment) comprising a transceiver unit and a controller, wherein the UE is a second UE-to-UE relay UE, wherein, in a 5G ProSe UE-to-UE Relay communication procedure using integrated discovery, when the transceiver unit receives a direct link establishment rejection message including fourth and seventh information from a third UE-to-UE relay UE, the controller determines to forward the direct link establishment rejection message to a first UE-to-UE relay UE based on the fourth information, the fourth information is a relay indication indicating that the direct link establishment rejection message can be forwarded, and the seventh information is a reason value indicating that the number of hops in Layer-3 multi-hop UE-to-UE Relays communication has reached an upper limit, and the transceiver unit transmits the direct link establishment rejection message including the fourth and seventh information to the first UE-to-UE relay UE.

Images