Method and device for managing asynchronous terminal service in mobile communication system
The method and device for managing asynchronous terminal services in 6G communication systems address power consumption inefficiencies by optimizing service request handling and transmission timing, resulting in improved power efficiency and service provision for UEs.
Patent Information
- Application Number
- PCT/KR2024/096841
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-12-14
- Filing Date
- 2024-12-12
- Publication Date
- 2025-06-19
AI Technical Summary
Existing mobile communication systems face inefficiencies in power consumption due to frequent state transitions when synchronous service operation methods are applied, especially in managing asynchronous terminal services in 6G communication systems.
A method and device are introduced to manage the timing of message transmission between new logical devices in a radio access network (RAN) or core network, allowing user equipment (UE) to provide services asynchronously and reduce power consumption by optimizing service request handling based on connection states and service urgency.
This approach enhances power usage efficiency by reducing unnecessary transitions to connected mode, enabling UEs to provide various network services more effectively while minimizing energy wastage.
Smart Images

Figure KR2024096841_19062025_PF_FP_ABST
Abstract
Description
Method and device for managing asynchronous terminal services in mobile communication systems
[0001] The present disclosure relates to a technology for a control plane of a mobile communication system, and to a method and device for managing an asynchronous terminal service in a communication system.
[0002] Looking back at the evolution of wireless communication over successive generations, technologies have primarily been developed for human-facing services such as voice, multimedia, and data. With the commercialization of 5G (5th-generation) communication systems, an explosive increase in connected devices is expected to be connected to communication networks. Examples of networked objects include vehicles, robots, drones, home appliances, displays, smart sensors installed in various infrastructures, construction equipment, and factory equipment. Mobile devices are expected to evolve into diverse form factors, including augmented reality glasses, virtual reality headsets, and holographic devices. In the 6th-generation (6G) era, efforts are being made to develop improved 6G communication systems to connect hundreds of billions of devices and objects and provide diverse services. For this reason, 6G communication systems are often referred to as "beyond 5G."
[0003] The 6G communication system, expected to be realized around 2030, will have a maximum transmission speed of terabytes per second (i.e., 1,000 gigabits per second) and a wireless latency of 100 microseconds (μsec). In other words, compared to 5G, the transmission speed in a 6G communication system will be 50 times faster, while the wireless latency will be reduced to one-tenth.
[0004] To achieve these high data rates and ultra-low latency, 6G communication systems are being considered for implementation in the terahertz band (e.g., from 95 gigahertz (GHz) to 3 terahertz (THz)). Compared to the millimeter wave (mmWave) band introduced in 5G, the terahertz band is expected to experience more severe path loss and atmospheric absorption, making it more crucial to ensure signal reach, or coverage, in this band. Key technologies to ensure coverage include radio frequency (RF) components, antennas, new waveforms that offer better coverage than OFDM (orthogonal frequency division multiplexing), beamforming, and multiple antenna transmission technologies such as massive multiple-input and multiple-output (MIMO), full-dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas. In addition, new technologies such as metamaterial-based lenses and antennas, high-dimensional spatial multiplexing using orbital angular momentum (OAM), and reconfigurable intelligent surfaces (RIS) are being discussed to improve the coverage of terahertz band signals.
[0005] In addition, in order to improve frequency efficiency and system network, 6G communication systems are developing full duplex technology that utilizes the same frequency resources at the same time for uplink and downlink; network technology that integrates satellites and high-altitude platform stations (HAPS); network structure innovation technology that supports mobile base stations and enables optimization and automation of network operation; dynamic spectrum sharing technology through collision avoidance based on spectrum usage prediction; AI-based communication technology that utilizes artificial intelligence (AI) from the design stage and internalizes end-to-end AI support functions to realize system optimization; and next-generation distributed computing technology that realizes services with complexity that exceeds the limits of terminal computing capabilities by utilizing ultra-high-performance communication and computing resources (mobile edge computing (MEC), cloud, etc.). In addition, efforts are being made to further strengthen connectivity between devices, further optimize networks, promote softwareization of network entities, and increase the openness of wireless communications through the design of new protocols to be used in 6G communication systems, the implementation of hardware-based security environments, the development of mechanisms for the safe use of data, and the development of technologies for maintaining privacy.
[0006] Research and development of these 6G communication systems are expected to enable a new level of hyper-connected experience (the next hyper-connected experience) through the hyper-connectivity of 6G communication systems, which encompass not only connections between things but also connections between people and things. Specifically, 6G communication systems are expected to enable services such as truly immersive extended reality (Truly Immersive XR), high-fidelity mobile holograms, and digital replicas. Furthermore, services such as remote surgery, industrial automation, and emergency response, which are provided through 6G communication systems through enhanced security and reliability, will find application in diverse fields such as industry, medicine, automobiles, and home appliances.
[0007] The present disclosure proposes a method and device for introducing a new logical device in a radio access network (RAN) or core network within a mobile communication system and managing the timing of transmission of messages exchanged by the new device with other network devices (network functions (NFs)) in relation to services provided by user equipment (UE).
[0008] According to one embodiment of the present disclosure, a method of a first network function (NF) entity in a mobile communication system includes the steps of transmitting a UE service request to a user equipment (UE) through a radio access network (RAN), the UE service request including type information indicating whether the UE service request is a real-time service; and receiving a UE service response from the UE through the RAN, wherein a paging message based on the UE service request includes paging cause information.
[0009] According to one embodiment of the present disclosure, a method is provided in a mobile communication system, comprising: a first network function (NF) entity, comprising: a transceiver; and at least one processor; wherein the at least one processor is configured to transmit a UE service request to a user equipment (UE) via a radio access network (RAN), the UE service request including type information indicating whether the UE service request is a real-time service; and receive a UE service response from the UE via the RAN, wherein a paging message based on the UE service request includes paging cause information.
[0010] By providing a method and device according to an embodiment of the present disclosure, a service can be provided by efficiently using the energy of a user device.
[0011] By providing a method and device according to an embodiment of the present disclosure, it is possible to improve the inefficiency of power consumption that may occur when the synchronous service operation method of a mobile communication system is directly applied by designing the control interface of the UE on a service basis.
[0012] By providing a method and device according to an embodiment of the present disclosure, a USH (UE (user equipment) service handler) can determine a transmission time by considering a connection status of a UE and an urgency of a service call when transmitting a message for a NF (network function) to call a UE service and a message for a UE to call an NF service and transmitting a response thereto.
[0013] By providing a method and device according to an embodiment of the present disclosure, a UE can improve power usage efficiency by reducing the frequency of transitioning to a connected mode while satisfying the requirements of each service call.
[0014] By providing a method and device according to an embodiment of the present disclosure, a UE can provide various network services by applying service-based operations.
[0015] Figure 1 is a diagram illustrating the network structure and interface of a 5G system.
[0016] Figure 2 is a diagram illustrating real-time and non-real-time UE (user equipment) service operation operations.
[0017] FIG. 3 is a diagram illustrating a connection structure of a USH (UE service handler) device according to one embodiment of the present invention.
[0018] FIG. 4 is a diagram illustrating real-time and non-real-time UE service operation operations according to one embodiment of the present invention.
[0019] FIG. 5 is a diagram illustrating an operation when requesting real-time UE service from USH in NF according to one embodiment of the present invention.
[0020] FIGS. 6A and 6B are diagrams illustrating operations when a non-real-time UE service is requested from a USH in an NF according to one embodiment of the present invention.
[0021] FIG. 7 is a diagram illustrating an example of a UE service call operation via a RAN (radio access network) according to one embodiment of the present invention.
[0022] FIG. 8 is a diagram illustrating an example of a paging message at the request of a USH according to one embodiment of the present invention.
[0023] FIG. 9 is a diagram illustrating a UE service call operation through a connection management function (CMF) according to one embodiment of the present invention.
[0024] FIG. 10 is a diagram illustrating an operation in which a USH calls a service depending on whether a UE has a radio connection according to one embodiment of the present invention.
[0025] FIG. 11 is a diagram illustrating a subscription operation for a UE connection state of a USH according to one embodiment of the present invention.
[0026] FIG. 12 is a diagram illustrating an operation in which a UE requests an NF service using a USH according to one embodiment of the present invention.
[0027] FIG. 13 is a diagram illustrating a procedure in which a USH transmits a pending request when a RAN handover of a UE occurs according to one embodiment of the present invention.
[0028] Fig. 14 is a flowchart illustrating the operation of a USH according to one embodiment of the present invention.
[0029] Fig. 15 is a structural diagram showing the structure of a USH according to one embodiment of the present invention.
[0030] Hereinafter, one embodiment of the present disclosure will be described in detail with reference to the attached drawings.
[0031] In describing this disclosure, descriptions of technical details that are well-known in the technical field to which this disclosure pertains and are not directly related to this disclosure will be omitted. This is to avoid obscuring the gist of this disclosure by omitting unnecessary explanations and to convey it more clearly. Furthermore, the terms described below are defined based on their functions in this disclosure and may vary depending on the intent or custom of the user or operator. Therefore, their definitions should be based on the contents of this specification as a whole.
[0032] For the same reason, some components in the attached drawings are exaggerated, omitted, or schematically depicted. Furthermore, the dimensions of each component do not entirely reflect its actual size. Identical or corresponding components in each drawing are assigned the same reference numbers.
[0033] Hereinafter, a base station (BS) is an entity that performs resource allocation of a terminal, and may be at least one of a gNode B, an eNode B, a Node B (or an xNode B (where x is an alphabet including g or e)), a wireless access unit, a base station controller, a satellite, an airborn, or a node on a network. A user equipment (UE) may include a mobile station (MS), a vehicle, a satellite, an airborn, a cellular phone, a smartphone, a computer, or a multimedia system capable of performing a communication function. In the present disclosure, a downlink (DL) is a wireless transmission path of a signal transmitted from a base station to a terminal, and an uplink (UL) means a wireless transmission path of a signal transmitted from a terminal to an air station. Additionally, a sidelink (SL) may exist, which means a wireless transmission path of a signal transmitted from a terminal to another terminal.
[0034] In addition, although LTE, LTE-A, or 5G systems may be described below as examples, embodiments of the present disclosure may also be applied to other communication systems having similar technical backgrounds or channel types. For example, this may include 5G-Advance or NR-Advance, or 6th generation mobile communication technology (6G) developed after 5G mobile communication technology (or new radio, NR), and the 5G described below may also include existing LTE, LTE-A, and other similar services. In addition, the present disclosure may be applied to other communication systems with some modifications within a range that does not significantly deviate from the scope of the present disclosure, as determined by a person having skilled technical knowledge.
[0035] At this time, it will be understood that each block of the processing flowchart drawings and combinations of the flowchart drawings can be performed by computer program instructions. These computer program instructions can be installed in a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, so that the instructions executed by the processor of the computer or other programmable data processing equipment create a means for performing the functions described in the flowchart block(s). These computer program instructions can also be stored in a computer-available or computer-readable memory that can direct a computer or other programmable data processing equipment to implement the functions in a specific manner, so that the instructions stored in the computer-available or computer-readable memory can also produce a manufactured item that includes an instruction means for performing the functions described in the flowchart block(s). Since the computer program instructions may be installed on a computer or other programmable data processing device, a series of operational steps may be performed on the computer or other programmable data processing device to create a computer-executable process, and the instructions that cause the computer or other programmable data processing device to perform the steps for performing the functions described in the flowchart block(s) may also provide steps for performing the functions described in the flowchart block(s).
[0036] Additionally, each block may represent a module, segment, or portion of code that contains one or more executable instructions for performing a specific logical function(s). It should also be noted that in some alternative implementation examples, the functions described in the blocks may occur out of order. For example, two blocks depicted in succession may actually be executed substantially concurrently, or the blocks may sometimes be executed in reverse order, depending on their respective functions.
[0037] Here, the term '~ part' used in this embodiment means software or hardware components such as FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit), and the '~ part' performs certain roles. However, the '~ part' is not limited to software or hardware. The '~ part' may be configured to be on an addressable storage medium or may be configured to play one or more processors. Therefore, as an example, the '~ part' includes components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and '~ parts' may be combined into a smaller number of components and '~ parts' or further separated into additional components and '~ parts'. Additionally, the components and '~parts' may be implemented to activate one or more CPUs within a device or secure multimedia card. In addition, in an embodiment, the '~parts' may include one or more processors.
[0038] 3GPP, responsible for cellular mobile communications standards, is standardizing a new core network architecture called 5G Core (5GC) to facilitate the evolution of 4G LTE systems to 5G systems. Compared to the Evolved Packet Core (EPC), the network core for 4G, 5GC supports the following differentiated features:
[0039] 5GC can easily support the network virtualization paradigm by separating mobility management functions from session management functions. In 4G LTE, all terminals can receive services from the network through signaling exchanges with a single core entity called the mobility management entity (MME), which is responsible for registration, authentication, mobility management, and session management. In 5G, the number of terminals (including MTC terminals) will explode, and the mobility and traffic / session characteristics that must be supported depending on the terminal type will become more specialized. Therefore, supporting all functions from a single entity (such as the MME) will inevitably reduce scalability by adding entities for each required function. Therefore, various functions are being developed based on a structure that separates mobility management and session management functions to improve scalability in terms of functional / implementation complexity and signaling load of the core entity responsible for the control plane.
[0040] With the advancement and widespread adoption of network function virtualization and cloud technologies, the core network of 5G mobile communication systems has adopted a service-based architecture (SBA). Within this architecture, each network function (NF) is defined as software that provides one or more services, with the goal of evolving to facilitate modification and deployment. Furthermore, the system supports a service mesh architecture, facilitating the introduction of new network functions and the discovery and utilization of mutual services.
[0041] FIG. 1 illustrates a mobile communication system structure according to one embodiment of the present disclosure.
[0042] Referring to FIG. 1, a 5GS (5G System), which is a mobile communication system, may be composed of a terminal (UE), a base station ((R)AN), and a 5G core network. Referring to FIG. 1, the 5G core network may be composed of the remaining NFs (Network Functions) excluding the UE, (R)AN, and DN of FIG. 1. Specifically, the 5G core network may be composed of an Access and Mobility Management Function (AMF), a Session Management Function (SMF), a User Plane Function (UPF), a Policy Control Function (PCF), a Unified Data Management (UDM), a Network Repository Function (NRF), a Network Exposure Function (NEF), a Network Slice Selection Function (NSSF), an Authentication Server Function (AUSF), an Application Function (AF), and a Data Network (DN). A terminal (UE) may access a 5G core network through a base station ((R)AN). Hereinafter, a UE may be referred to as a terminal, and an (R)AN may be referred to as a base station. Additionally, the 5G core network may further include an Application Function (AF) and a Data Network (DN).
[0043] In one embodiment, AMF is a Network Function (NF) that manages wireless network access and mobility for a terminal.
[0044] The SMF is an NF that manages sessions for terminals. Session information includes QoS (Quality of Service) information, charging information, and packet processing information. The UPF is an NF that processes user traffic (e.g., user plane traffic) and is controlled by the SMF.
[0045] The PCF is an NF that manages operator policy (PLMN policy) for providing services in a wireless communication system. Additionally, the PCF can be divided into a PCF responsible for AM (Access and Mobility) policy and UE policy, and a PCF responsible for SM (Session Management) policy. The PCF responsible for AM / UE policy and the PCF responsible for SM policy can be logically or physically separate NFs, or they can be a single NF.
[0046] The UDM is an NF that stores and manages subscriber information (UE subscription) for terminals. The NRF registers and manages NF functions in the 5G core network and searches for and selects NFs that satisfy required functions. The NEF exposes 5G network core functions to the outside world and can be used for communication between AF and the 5G core network.
[0047] NSSF may be a network slicing control solution that selects a set of network slice instances that serve user equipment and determines the access and mobility functions to be used. AUSF may be an authentication server function that facilitates security processes and may be an NF that authenticates UEs and stores authentication keys. AF may be an NF that provides application functions for services according to the present disclosure. DN may refer to a data network that may provide operator services, Internet access, or third-party services.
[0048] Within 5G SBA, network functions primarily exchange control messages in a request-response format. For normal control message exchange and control procedure execution, each NF must be constantly available for communication. Other message exchange methods (e.g., subscribe-notify) also operate under the assumption that NFs are always available for communication.
[0049] The service-based interface (SBI), which is limitedly applied to the control plane of the 5G core network, can be expanded and applied to the control interface of user plane (UP) devices and the control interface of user devices.
[0050] Extending SBI to the UE's control interface means that the UE can offer various services that other network devices can utilize, including the exchange of existing control plane signaling. In this case, a UE-provided service refers to an approach in which another network device invokes the UE to perform a specific operation or action (including message transmission). For example, a NF can invoke the 'Measurement report' service provided by the UE, causing the UE to process and transmit statistics on channel quality over a specific period of time to the NF. Alternatively, a UE can invoke the 'Sensing' service provided by another UE, causing the UE to perform ambient sensing using UWB and transmit the results to the requesting UE.
[0051] As mentioned above, existing SBA services operate under the assumption that each NF is always ready for communication. In contrast, UEs must sleep and wake to optimize power consumption.
[0052] Figure 2 is a diagram illustrating real-time and non-real-time UE service operation operations.
[0053] In Fig. 2, NF (network function) A (220) and NF B (230) refer to NF entities belonging to the core network in which the UE (200) is registered.
[0054] Step 240 indicates that the UE (200) is in an Idle state.
[0055] Thereafter, in step 245, NF A (220) can transmit service request #1 including a paging procedure to UE (200) via RAN (210). The service request #1 may be a service request for a non-real-time service. When UE (200) receives service request #1 including a paging procedure, even though the service request #1 is a non-real-time service, UE (200) can perform the paging procedure in step 250 and change to a connected state.
[0056] At step 255, the UE (200) may transmit service response #1 to the NF A (220) via the RAN (210). Thereafter, at step 260, the UE (200) may transition back to the Idle state.
[0057] At step 265, NF B (230) may transmit service request #2 including a paging procedure to UE (200) via RAN (210). The service request #2 may be a service request for a real-time service. When UE (200) receives service request #2 including a paging procedure, it may perform a paging procedure at step 270 and transition to a connected state. At step 275, UE (200) may transmit service response #2 to NF B (230) via RAN (210).
[0058] Referring to Figure 2, if the real-time service provisioning method used in the existing SBA is applied to the UE, the UE must wake up and process the request every time a service request is made, which can lead to inefficient power consumption due to frequent state transitions to the connected state. Therefore, when designing a service-based UE control interface, it is necessary to devise a service provisioning method other than the real-time service provisioning method.
[0059] Accordingly, this disclosure proposes a novel logical device that manages the timing of transmission of messages related to service requests, enabling UEs to provide services asynchronously and access services from other network devices. This addresses the potential power consumption inefficiencies that can arise when applying the synchronous service method of existing systems to UEs.
[0060] FIG. 3 is a diagram illustrating a connection structure of a USH (UE service handler) device according to one embodiment of the present invention.
[0061] FIG. 3 is a diagram illustrating a control plane including a connection management function (CMF) (320), a UE service handler (USH) (330), and network functions (NF)s (340).
[0062] In one embodiment, CMF (320) is a logical device responsible for UE reachability from a core network perspective within the system, and may include AMF in a 5G system.
[0063] In one embodiment, the USH (330) may refer to a logical device that asynchronously manages UE-related services, allowing the UE to asynchronously provide services within the system and access services of other network devices. The USH (330) may be integrated with AMF or RRC, configured as an independent device within a RAN, or as an independent NF within a CN.
[0064] USH (330) has the following connectivity with other network devices.
[0065] In one embodiment, the USH (330) may be connected to NFs (340) using a common interface within the system (e.g., 5G SBI). In one embodiment, the NFs (340) are not limited to control plane devices within the CN, and may refer to any network device that can be connected to the USH via the common interface.
[0066] In one embodiment, the USH (330) may be connected to the RAN (310) using a common interface or a dedicated interface (e.g., a 5G NG interface) within the system.
[0067] In one embodiment, the USH (330) may be connected to the UE (300) using any message protocol (e.g., ASN.1, JSON, etc.) capable of exchanging information over a Layer 3 transport protocol.
[0068] In one embodiment, the USH (330) may provide a UE service call request registration function for the NF (s) (340). In one embodiment, the USH (330) may manage the interdependency between the UE service calls registered by the NF (s) (340). In one embodiment, the USH (330) may determine the call time based on the urgency of the UE service call request registered by the NF (s) (340) and may forward the registered UE service call request. In one embodiment, the USH (330) may determine the call path according to the Radio connection state of the UE (300). In one embodiment, the USH (330) may provide a NF service call request registration function so that the UE (300) can asynchronously call the NF service. In one embodiment, the USH (330) may support the RAN (310) mobility of the UE (300) in managing the asynchronous service request.
[0069] In order to support the function of the USH (330), the RAN (310) may additionally perform the following functions. In one embodiment, when the RAN (310) performs UE paging at the request of the USH (330), the RAN (310) may transmit as a paging cause that the paging reason is due to a UE service request from the NF (s) (340). In one embodiment, the RAN (310) may notify the USH (330) of a connection state transition event of the UE (300) at the request of the USH (330).
[0070] FIG. 4 is a diagram illustrating real-time and non-real-time UE service operation operations according to one embodiment of the present invention.
[0071] In Fig. 4, NF (network function) A (420) and NF B (430) may refer to NF entities belonging to the core network in which the UE (400) is registered. Fig. 4 illustrates that USH (410) is included and operates, and USH (410) may refer to a logical device having the same function as USH (330) described in Fig. 3.
[0072] Step 440 indicates that the UE (400) is in an Idle state. Step 445 indicates that the NF A (420) can transmit Service Request #1 to the USH (410). In step 450, if the Service Request #1 is a non-real-time service, the USH (410) can transmit Service Call #1 ACK to the NF A (420) without transmitting it to the UE (400).
[0073] In step 455, NF B (430) transmits service request #2 to USH (410), and if the service request #2 is a real-time service, USH (410) can forward the service request #2 to UE (400) via RAN. When UE (400) receives service request #2, it can perform a paging procedure with RAN in step 460 and transition to connected state. In step 465, UE (400) can transmit service response #2 to NF B (430) via RAN. Thereafter, in step 470, USH (410) can transmit service request #1 received in step 445 to UE (400) in connected state via RAN. At step 475, the UE (400) transmits service response #1 to the USH (410) via the RAN, and the USH (410) can forward the service response #1 to the NF A (420).
[0074] Referring to FIG. 4, unlike FIG. 2, in the case of a service request for a non-real-time service, the USH (410) does not immediately transmit the service request to the UE (400) but stores it, and then, when a service request for a real-time service is received, the USH (410) performs a paging procedure on the UE (400) and transmits the previously stored service request for the non-real-time service, thereby reducing inefficient power consumption due to frequent state transitions.
[0075] Hereinafter, FIGS. 5 and 6 describe a method by which a USH receives and manages a UE service call request from an NF. In one embodiment, a USH may provide a service that allows NFs to request calls for services provided by a UE. In one embodiment, a UE service call request from each NF may include at least one of a UE ID (identifier), a service name, a message body to be used when calling the service, and an urgency level.
[0076] In one embodiment, the UE ID may include an ID (e.g., 5G-S-TMSI) that can identify the UE in a RAN paging or CN paging situation depending on the implementation and deployment method of the USH. In one embodiment, the service name may include a name of a service that the request intends to call among the services provided by the UE. In one embodiment, the message body corresponds to a message body on a control plane protocol used by the system, and the USH may transmit the message body to the UE as is without modifying it. In addition, the urgency may refer to a value for the urgency of the message (e.g., a number from 1 to 10). In one embodiment, the UE service invocation request may include a maximum allowable delay time, and optionally may directly include information on whether the service is to be invoked immediately. In one embodiment, the information on the maximum allowable delay time and whether the service is to be invoked immediately may be utilized by the USH to determine the UE service invocation time.
[0077] In one embodiment, if the system is configured to include whether a service should be called immediately, the USH can determine whether to immediately call the UE service upon receiving the service call request. In one embodiment, if an immediate call is requested, the USH can immediately call the corresponding UE service and return the response to the NF. In one embodiment, if an immediate call is not requested, the USH can return a response to the call request reception to the NF and manage the request as a pending request. The response can include an identifier for the request.
[0078] FIG. 5 is a diagram illustrating an operation when requesting real-time UE service from USH in NF according to one embodiment of the present invention.
[0079] FIG. 5 illustrates the operation between a UE (500), a RAN (510), a CMF (520), a USH (530), and a NF (540). The CMF (520) and the USH (530) may refer to logical devices that provide the same functions as the CMF (320) and the USH (330) described in FIG. 3.
[0080] In step 550, NF (540) may transmit a UE service request (Nush_UE service request) to USH (530). In one embodiment, the UE service request may include at least one of a UE ID, a service name, a message body, a service name, and class information indicating whether the service is real-time / non-real-time. For example, in step 550, the class information indicating whether the service is real-time / non-real-time may indicate that the service requesting the UE service is a real-time service.
[0081] In step 555, the USH (530), the UE (500), the RAN (510), and the CMF (520) may perform a network-originated UE service call procedure. In step 560, the USH (530) may transmit a UE service response (Nush_UE service response) to the NF (540). In one embodiment, the UE service response may include at least one of information such as the type ('type') of the target service, a UE ID, a service name, and a service response. For example, in step 560, the service type ('type') information may indicate that the service for the UE service response is a real-time service.
[0082] In one embodiment, the USH (530) may reject a service call if a new request may conflict with other requests already existing in the pending requests (e.g., changing the same parameter). In one embodiment, the criteria by which the USH (530) determines a conflicting service are pre-defined, and these may be defined according to a standard or may be arbitrarily set by the operator. In one embodiment, the USH (530) may determine the call timing of requests in the pending requests according to any judgment criteria. For example, this may be the case when the sum of the urgency values exceeds a threshold value, or when the allowable delay time for one or more requests becomes smaller than the threshold value. In one embodiment, the NF (540) may provide a new service for receiving the delayed called service response result.
[0083] FIGS. 6A and 6B are diagrams illustrating operations when a non-real-time UE service is requested from a USH in an NF according to one embodiment of the present invention.
[0084] Figures 6a and 6b illustrate the operation between the USH (600) and the NF (610). The USH (600) may refer to a logical device that provides the same function as the USH (330) described in Figure 3.
[0085] FIG. 6a illustrates a case where the USH (600) successfully registers a UE service request from the NF (610), and FIG. 6b illustrates a case where the USH (600) fails to register a UE service request from the NF (610).
[0086] Referring to FIG. 6A, in step 620, NF (610) may transmit a UE service request (Nush_UE service request) to USH (600). In one embodiment, the UE service request may include at least one of a UE ID, a service name, a message body, a service name, class information indicating a real-time / non-real-time service, and urgency (level) information. For example, the UE service request in step 620 may be a non-real-time service according to the class information and the urgency (level) may be “2.” In step 625, USH (600) may transmit a UE service response (Nush_UE service response) to NF (610). In one embodiment, the UE service response may include at least one of a UE service type, a service ID, and the like. Step 625 illustrates a case where the type of the UE service response is enrollment.
[0087] In one embodiment, the USH (600) may invoke a UE service based on a trigger reason it operates independently. For example, when the USH (600) receives a service request for a non-real-time message, it may store the non-real-time message as a pending request and calculate and store the sum of the information indicating the urgency.
[0088] In step 630, USH (600) can determine whether the sum of information indicating the urgency of the pending request is greater than a predetermined threshold.
[0089] At step 635, the USH (600) may perform a network-originated UE service call procedure.
[0090] In step 640, the USH (600) may transmit a UE service result (Nnf_UE Service Result) to the NF (610). In one embodiment, the UE service result may include at least one of the type of the target service, a service ID, a UE ID, a service name, and information regarding a service response. For example, step 640 may indicate that the type of the target service is a non-real-time service (NRT).
[0091] Referring to FIG. 6b, at step 650, NF (610) may transmit a UE service request (Nush_UE service request) to USH (600). In one embodiment, the UE service request may include at least one of a UE ID, a service name, a message body, a service name, class information indicating a real-time / non-real-time service, and urgency (level) information. For example, the UE service request at step 620 may be a non-real-time service according to the class information and the urgency (level) may be "2".
[0092] At step 655, the USH (600) may identify that the new service request conflicts with a service that the USH (600) previously received and stored as a pending request.
[0093] At step 660, the USH (600) may transmit a UE service response (Nush_UE Service Response) to the NF (610). In one embodiment, the UE service response may include at least one of the UE service response type and service ID. For example, step 660 illustrates a case where the UE service response type is reject.
[0094] Below, Figures 7, 8, and 9 describe the USH proactively invoking a UE service. This is a description of the network-originated UE service call mentioned in Figures 5 and 6a. In one embodiment, the USH can proactively invoke a UE service via the CMF or RAN.
[0095] In one embodiment, the USH may invoke a service of the UE through a device (CMF) responsible for UE reachability in the CN when it is determined that the UE has a context in the CN (e.g., RM-Registered in 5G) and no RAN connection exists (e.g., CM-Idle & RRC-Idle in 5G).
[0096] In one embodiment, if the USH determines that the UE has a context within the CN and that a RAN connection also exists (e.g., RRC-Connected or RRC-Inactive in 5G), the USH can invoke a service for the UE through the CN's UE reachability management function (CMF) or a RAN device. To this end, the CMF and the RAN can provide services that the USH can use to invoke the UE's service. In one embodiment, the UE can immediately provide a service response to a service request proactively invoked by the USH.
[0097] In one embodiment, when proactively calling a UE's service, the USH may forward all requests included in the pending requests, or select and forward only the requests corresponding to the trigger reason (e.g., the remaining delay time is below a threshold).
[0098] FIG. 7 is a diagram illustrating an example of a UE service call operation via a RAN (radio access network) according to one embodiment of the present invention.
[0099] FIG. 7 illustrates operations between a UE (700), a RAN (710), a CMF (720), and a USH (730). The CMF (720) and the USH (730) may refer to logical devices that provide the same functions as the CMF (320) and the USH (330) described in FIG. 3.
[0100] In step 740, if a RAN connection of the UE exists, the USH (730) may transmit a UE service request (Nran_UeServiceRequest) for a UE service call to the RAN (710). In one embodiment, the UE service request may include at least one of information such as a UE ID, a service type indicating whether the target service is a real-time or non-real-time service, and at least one call ID / service name / msg. body for each service call. For this purpose, the RAN (710) may provide a new service for a UE service call to the USH (730).
[0101] At step 745, the RAN (710) may perform RAN paging if the UE (700) is in the RRC-Inactive state. In one embodiment, the RAN (710) may include in the paging message that the paging is due to a service request from the NF through the paging cause.
[0102] In step 750, the UE (700) may transmit to the RAN (710) a resume cause of no-signaling when requesting an RRC resume by the corresponding paging. In step 753, the RAN (710) may transmit an RRC Resume message to the UE (700). In step 755, the UE (700) may transmit an RRC Resume complete message to the RAN (710).
[0103] In step 760, the RAN (710) may transmit the service request received in step 740 to the RRC-Connected UE (700). In steps 763, 765, 770, and 775, the UE (700) may transmit a UE service response for each service call to the USH (730) via the RAN (710). In one embodiment, the UE service response (Nran_UeServiceResponse) transmitted by the RAN (710) to the USH (730) in steps 765 and 775 may include a call ID for each service call, msg.body (service result), etc.
[0104] FIG. 8 is a diagram illustrating an example of a paging message at the request of a USH according to one embodiment of the present invention.
[0105] Figure 8 illustrates an example of a paging message illustrated in step 745 of Figure 7.
[0106] FIG. 9 is a diagram illustrating a UE service call operation through a connection management function (CMF) according to one embodiment of the present invention.
[0107] FIG. 9 illustrates the operation between a UE (900), a RAN (910), a CMF (920), and a USH (930). The CMF (920) and the USH (930) may refer to logical devices that provide the same functions as the CMF (320) and the USH (330) described in FIG. 3.
[0108] Referring to FIG. 9, in step 940, if the RAN connection of the UE (900) does not exist, the USH (900) may transmit a UE service request (Ncmf_UeServiceRequest) to the CMF (920). In one embodiment, the UE service request may include at least one of a UE ID, a service type indicating whether the target service is a real-time or non-real-time service, and at least one service call-specific call ID / service name / msg. body. In one embodiment, the USH (930) may call a UE service through the CMF (920) even if the RAN connection of the UE (900) exists. In one embodiment, the USH (930) can call a UE service via the CMF (920) whether or not the RAN connection of the UE (900) exists. In this case, the USH (930) has the advantage of not needing to determine the RAN connection state of the UE (900), but even if the RAN connection exists, signaling overhead may occur as it must go through the CMF (920).
[0109] In step 945, the CMF (920) may forward the UE service request (Ncmf_UeServiceRequest) of step 940 to the RAN (910). In step 950, the RAN (910) may perform a UE service procedure with the UE (900). In one embodiment, if the UE (900) does not have a RAN connection, the UE service procedure may include a paging procedure. After step 950 is completed, if the RAN (910) receives a UE service response from the UE (900), the RAN (910) may transmit a UE service response (Nran_UeServiceResponse) to the CMF (920) in step 960. In one embodiment, the UE service response (Nran_UeServiceResponse) may include a call ID for each service call, msg.body (service result), etc. At step 965, CMF (920) may forward a UE service response (Ncmf_UeServiceResponse) to USH (930).
[0110] FIG. 10 is a diagram illustrating an operation in which a USH calls a service depending on whether a UE has a radio connection, according to one embodiment of the present invention.
[0111] FIG. 10 is a diagram illustrating an example of a routing configuration procedure of a USH, and illustrates operations between a UE (1000), a RAN (1010), and a USH (1020). The USH (1020) may refer to a logical device that provides the same function as the USH (330) described in FIG. 3.
[0112] Referring to FIG. 10, at step 1030, the UE (1000) and the RAN (1010) may perform an RRC Establishment, Re-Establishment, or Resume procedure. At step 1040, the UE (1000) transitions to a connected state, and at step 1050, the RAN (1010) may transmit a status notification of the UE (1000) to the USH (1020). In one embodiment, the status notification of the UE (1000) may include a UE ID and information indicating the current radio connection status of the UE. In one embodiment, since the UE (1000) has completed the radio connection at step 1030, the information indicating the radio connection status of the UE at step 1050 may indicate 'connected'.
[0113] When the USH (1020) is notified that the radio connection of the UE (1000) is activated, it can transfer at least one entire pending request it has to the UE (1000) through the RAN (1010). That is, in step 1060, the USH (1020) can transmit a UE service request (Nran_UeServiceRequest) triggered by a transition of the radio connection state of the UE (1000) to the RAN (1010). In one embodiment, the UE service request can include at least one of information such as a UE ID, a service type indicating whether the target service is a real-time or non-real-time service, and call ID / service name / msg. body for each service call.
[0114] The UE service request transmitted in step 1060 is a service request for a non-real-time service, and the service request type may indicate non-real-time. In one embodiment, the USH (1020) may transmit a remaining delay time (countdown) for each service request together with the service request. In one embodiment, the remaining delay time may be calculated by the USH (1020) based on the maximum delay time transmitted by the NF when registering with the USH (1020), or if the USH (1020) knows a pre-defined value for the maximum delay time for each service, the USH (1020) may calculate and transmit the remaining delay time from the request registration time.
[0115] In step 1063, the RAN (1010) may forward the received UE service request to the UE (1000). In steps 1065 and 1067, the UE (1000) may transmit a UE service response for each service call to the USH (1020) via the RAN (1010). In one embodiment, if a service request invoked by a wireless connection state transition has information about a maximum delay time, the UE (1000) may provide a service response within the delay time.
[0116] In one embodiment, the UE service response (Nran_UeServiceResponse) transmitted by the RAN (1010) to the USH (1020) in step 1067 may include a call ID for each service call, msg.body (service result), etc.
[0117] In step 1070, the UE (1000) may transmit a UE service response for the service call to the RAN (1010). Even if the UE (1000) transitions to an Idle state in step 1073, the RAN (1010) may transmit a UE service response (Nran_UeServiceResponse) to the USH (1020) in step 1075, and the UE service response (Nran_UeServiceResponse) transmitted by the RAN (1010) to the USH (1020) may include a call ID for each UE service call, msg.body (service result), etc.
[0118] FIG. 11 is a diagram illustrating a subscription operation for a UE connection state of a USH according to one embodiment of the present invention.
[0119] Figure 11 illustrates the operation between RAN (1110) and USH (1120). USH (1120) may refer to a logical device that provides the same function as USH (330) described in Figure 3.
[0120] FIG. 11 illustrates an operation of requesting a subscription to a service that can be notified of information about the radio connection status of a UE from a RAN (1110) so that a USH (1120) can determine a network device to request a UE service call based on the radio connection status of the UE.
[0121] In step 1130, the USH (1120) may transmit a UE state subscription request (Nan_UE State Subscribe Request) to the RAN (1110). In one embodiment, the UE state subscription request may include information indicating a UE ID and a desired level of notification. In one embodiment, the desired level of notification may indicate whether to receive notification only for RRC-Idle transitions (Idle) or whether to also receive notification for transitions between RRC-Inactive and RRC-Connected (inactive). If the USH (1120) also receives notification for transitions between RRC-Inactive and RRC-Connected, it may utilize this to transmit pending requests when the UE transitions from RRC-Inactive to RRC-Connected.
[0122] At step 1135, the RAN (1110) may transmit a UE status response (Nran_UE State response) to the USH (1120). In one embodiment, the UE status response may include information about the UE ID and the current wireless connection state of the UE. For example, if the UE is currently connected, the RAN (1110) may transmit the current wireless connection state of the UE as "Connected."
[0123] If the information indicating the level of notification to be received included in the UE state subscription request of step 1130 is 'inactive' and the wireless connection state of the UE transitions to inactive, the RAN (1110) may transmit a UE state notification (Nran_UE State notify) to the USH (1120) in step 1140. In one embodiment, the UE state notification (Nran_UE State notify) may include a UE ID and information ('inactive') about the current wireless connection state of the UE. Thereafter, in step 1150, the USH (1120) may transmit a UE state unsubscribe request (Nran_UE State Unsubscribe Request) to the RAN (1110). In one embodiment, the UE state unsubscribe request may include necessary information such as a UE ID.
[0124] Referring to FIG. 11, if the RAN connection is maintained according to the UE status notification such as step 1140, the USH (1120) determines the UE service call target as the RAN and transmits a UE service request to the RAN, and if the RAN connection is terminated, changes the UE service call target to the CMF and transmits the UE service request to the CMF.
[0125] FIG. 12 is a diagram illustrating an operation in which a UE requests an NF service using a USH according to one embodiment of the present invention.
[0126] Figure 12 illustrates the operation between a UE (1200), a USH (1210), and a NF (1220). The USH (1210) may refer to a logical device that provides the same function as the USH (330) described in Figure 3.
[0127] Referring to FIG. 12, in step 1230, the UE (1200) may transmit an NF service request (Nush_NF Service Requests) to the USH (1210). In one embodiment, the NF service request may include at least one of an NF ID, a service name, a message body to be used when calling a service, and class information or urgency information indicating whether the target service is a real-time or non-real-time service. In one embodiment, the service name may indicate the service name of the NF (1220) that the request intends to call. In one embodiment, the message body corresponds to the message body on the control plane protocol used by the system, and this part may be transmitted to the NF as is by the USH without modification. For example, step 1230 indicates that the NF service request is for a non-real-time service (class=non-realtime).
[0128] In step 1235, the USH (1210) may register the non-realtime service call request of the UE (1200) as a pending request without directly forwarding it to the NF (1220) and may transmit an NF service response (Nush_NF Service Response) to the UE (1200). In one embodiment, the NF service response may include information such as the processing type for the service, the service ID, etc. For example, step 1235 indicates that the processing type for the service included in the NF service response is registration ('enroll').
[0129] Thereafter, in step 1240, the USH (1210) may transmit a service request to the NF (1220), and in step 1245, the NF (1220) may transmit a service response to the USH (1210). In step 1250, the UE (1200) may transition to the Idle state regardless of the operations of steps 1240 and 1245.
[0130] In step 1260, if there is a previously unconfirmed NF service call result, the UE (1200) may transmit an NF Service Result Request to the USH (1210) after transitioning to the Connected state. The NF Service Result Request may include at least one of a service ID, an NF ID, and a service name. In step 1265, the USH (1210) may transmit an NF Service Result to the UE (1200). In one embodiment, the NF Service Result may include at least one of a type of a target service, a service ID, an NF ID, a service name, and information related to a service response. For example, in step 1265, the type of the target service indicates that it is a non-realtime (NRT) service. In one embodiment, the USH (1210) may detect a transition to the Connected state without a request from the UE through a configured UE state notification and transmit the NF Service Result.
[0131] In one embodiment, when a UE (1200) calls an NF service and wants to receive an immediate response, it may call the NF in real time through the USH (1210) to receive the NF service result, or it may call the service of the NF (1220) directly without going through the USH (1210).
[0132] FIG. 13 is a diagram illustrating a procedure in which a USH transmits a pending request when a RAN handover of a UE occurs according to one embodiment of the present invention.
[0133] FIG. 13 illustrates the operation between a UE (1300), a Source RAN (A) (1310), a Target RAN (B) (1320), a Source USH (A) (1330), and a Target USH (B) (1340). The Source USH (A) (1330) and the Target USH (B) (1340) may refer to logical devices that provide the same functionality as the USH (330) described in FIG. 3.
[0134] Referring to FIG. 13, an operation supporting mobility of a UE is illustrated so that UE service requests held by a USH are not missed when the RAN device to which the UE is connected is changed.
[0135] At step 1350, the UE (1300), the Source RAN (A) (1310), and the Target RAN (B) (1320) may perform an Inter-gNB handover procedure. Step 1350 of FIG. 13 represents an Inter-gNB handover procedure including steps 1360 and 1395. Step 1360 is included in step 1350, and the UE (1300) may transmit RRCReconfigurationComplete to the Target RAN (B) (1320) indicating that the RRC connection has been completed. In one embodiment, when transmitting a handover request of the handover procedure, the Source RAN (A) (1310) may also transmit information on the Source USH (A) (1330) to which it is connected to the Target RAN (B) (1320).
[0136] At step 1370, the Target RAN (B) (1320) may transmit a RAN Handover notification to the connected Target USH (B) (1340). In one embodiment, the RAN Handover notification may include at least one of information about a UE ID, a Source USH (A), a Source RAN (A), and a Target RAN (B).
[0137] At step 1380, the Target USH (B) (1340) may transmit a pending request fetching request to the Source USH (A) (1330) based on the Source USH (A) information included in the RAN handover notification. In one embodiment, the pending request fetching request may include at least one of information about the UE ID, the Source RAN (A), and the Target RAN (B).
[0138] In step 1385, the Source USH (A) (1330) may transmit a pending request fetching response to the Target USH (B) (1340). In one embodiment, the pending request fetching response may include a UE ID, at least one call ID for each service call, a service name, a message body, and remaining delay time (countdown) information. In one embodiment, the remaining delay time may be a value calculated based on the maximum delay time that the NF transmitted when registering with the Source USH (A) (1330), or, if the Source USH (A) (1330) knows a pre-defined value for the maximum delay time for each service, the Source USH (A) (1330) may calculate and transmit it from the request registration time. In one embodiment, if there is no change in the USH, only the information of the RAN device that will perform the UE service call may be modified.
[0139] At step 1390, the Target USH(B)(1340) may transmit a RAN Handover notification response to the Target RAN(B)(1320). At step 1395, the Target RAN(B)(1320) may transmit a UEContextRelease to the Source RAN(A)(1310).
[0140] Fig. 14 is a flowchart illustrating the operation of a USH according to one embodiment of the present invention.
[0141] The USH illustrated in FIG. 14 may refer to a logical device that provides the same function as the USH (330) described in FIG. 3, i.e., a network function (NF) entity. Hereinafter, the USH will be referred to as a first network function (NF) entity to describe the operation of the USH.
[0142] At step 1410, the first NF entity may receive a UE (user equipment) service request from the second NF entity.
[0143] At step 1420, the first NF entity may register the UE service request if the UE service request is for a non-real-time service.
[0144] In step 1430, the first NF entity may determine whether to transmit the registered UE service request to the corresponding UE based on information about the urgency included in the UE service request. In one embodiment, the first NF entity may determine whether to transmit the UE service request to the corresponding UE based on information about the urgency included in the UE service request and information about at least one urgency included in at least one previously received UE service request. In one embodiment, the first NF entity may determine whether to transmit the UE service request to the corresponding UE based on information about the maximum allowable delay time included in the UE service request. In one embodiment, if the UE service request conflicts with at least one previously received UE service request, the first NF entity may determine not to transmit the UE service request to the corresponding UE.
[0145] In step 1440, if the first NF entity determines to transmit the UE service request to the corresponding UE, the first NF entity may forward the UE service request to the UE. In one embodiment, if the corresponding UE is in a wireless connection state, the first NF entity may forward the UE service request via a radio access network (RAN). In one embodiment, if the corresponding UE is in a radio resource control (RRC) inactive state, the UE service request may be transmitted after a paging procedure. In one embodiment, the first NF entity may receive a notification about the status of the corresponding UE from a radio access network (RAN). In one embodiment, if the status of the corresponding UE is connected, the first NF entity may forward the UE service request and at least one previously received UE service request to the UE via the RAN.
[0146] In one embodiment, the first NF entity may forward the UE service request to a third NF entity included in the core network and via a radio access network (RAN) when the corresponding UE is not in a wireless connection state.
[0147] In one embodiment, the first NF entity may receive a UE service response from the UE. In one embodiment, the first NF entity may transmit a UE service result message to the second NF entity. In one embodiment, the UE service result message may include information on the type of UE service corresponding to the UE service request.
[0148] In one embodiment, the first NF entity may transmit a UE status subscription request to the RAN. In one embodiment, the first NF entity may include the step of receiving a UE status response from the RAN. In one embodiment, the notification about the status of the corresponding UE from the RAN may be based on the UE status subscription request.
[0149] FIG. 15 is a structural diagram illustrating the structure of a USH (UE service handler) according to one embodiment of the present invention.
[0150] The USH entity illustrated in FIG. 15 according to one embodiment may refer to a logical device that provides the same function as the USH (330) described in FIG. 3, i.e., a network function (NF) entity. The USH entity may include a processor (1520) that controls the overall operation of the USH entity, a transceiver (1500) including a transmitter and a receiver, and a memory (1510). Of course, the present invention is not limited to the above example, and the USH entity may include more or fewer components than the components illustrated in FIG. 15.
[0151] According to one embodiment of the present disclosure, the transceiver (1500) can transmit and receive signals with network entities or other network nodes. The signals transmitted and received with the network entities may include control information and data. In addition, the transceiver (1500) can receive signals via a wireless channel, output them to the processor (1520), and transmit the signals output from the processor (1520) via the wireless channel.
[0152] According to one embodiment of the present disclosure, the processor (1520) can control the USH entity to perform any one of the operations described above. Meanwhile, the processor (1520), the memory (1510), and the transceiver (1500) do not necessarily have to be implemented as separate modules, and of course, they can be implemented as a single component in the form of a single chip. In addition, the processor (1520) and the transceiver (1500) can be electrically connected. In addition, the processor (1520) can be an Application Processor (AP), a Communication Processor (CP), a circuit, an application-specific circuit, or at least one processor.
[0153] According to one embodiment of the present disclosure, the USH entity may be referred to as a first NF entity. At least one processor of the first NF entity may receive a UE (user equipment) service request from a second NF entity.
[0154] At least one processor may register the UE service request if the UE service request is for a non-real-time service. The at least one processor may determine whether to transmit the registered UE service request to a corresponding UE based on information about an urgency included in the UE service request. In one embodiment, the at least one processor may determine whether to transmit the UE service request to the corresponding UE based on information about an urgency included in the UE service request and information about at least one urgency included in at least one previously received UE service request. In one embodiment, the at least one processor may determine whether to transmit the UE service request to the corresponding UE based on information about a maximum allowable delay time included in the UE service request. In one embodiment, if the UE service request conflicts with at least one previously received UE service request, the UE service request may be determined not to be transmitted to the corresponding UE.
[0155] At least one processor may, when determining to transmit the UE service request to the corresponding UE, forward the UE service request to the UE. In one embodiment, when the corresponding UE is in a wireless connection state, the at least one processor may forward the UE service request via a radio access network (RAN). In one embodiment, when the corresponding UE is in a radio resource control (RRC) inactive state, the UE service request may be transmitted after a paging procedure. In one embodiment, the at least one processor may receive a notification about the status of the corresponding UE from the radio access network (RAN). In one embodiment, when the status of the corresponding UE is connected, the at least one processor may forward the UE service request and at least one previously received UE service request to the UE via the RAN.
[0156] In one embodiment, at least one processor may forward the UE service request via a third NF entity included in the core network and a radio access network (RAN) when the corresponding UE is not in a wireless connection state.
[0157] In one embodiment, at least one processor may receive a UE service response from the UE. In one embodiment, the first NF entity may transmit a UE service result message to the second NF entity. In one embodiment, the UE service result message may include information on the type of UE service corresponding to the UE service request.
[0158] In one embodiment, at least one processor may transmit a UE status subscription request to the RAN. In one embodiment, the at least one processor may include the step of receiving a UE status response from the RAN. In one embodiment, the notification from the RAN regarding the status of the corresponding UE may be based on the UE status subscription request.
[0159] The methods according to the embodiments described in the claims or specification of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software.
[0160] When implemented in software, a computer-readable storage medium storing one or more programs (software modules) may be provided. The one or more programs stored in the computer-readable storage medium are configured for execution by one or more processors within an electronic device. The one or more programs include instructions that cause the electronic device to execute methods according to the embodiments described in the claims or specification of the present disclosure.
[0161] These programs (software modules, software) may be stored in a non-volatile memory including random access memory, flash memory, read only memory (ROM), electrically erasable programmable read only memory (EEPROM), magnetic disc storage devices, compact disc ROMs (CD-ROMs), digital versatile discs (DVDs) or other forms of optical storage devices, magnetic cassettes, or may be stored in a memory configured as a combination of some or all of these. In addition, each configuration memory may be included in multiple numbers.
[0162] Additionally, the program may be stored on an attachable storage device that is accessible via a communication network such as the Internet, an intranet, a local area network (LAN), a wide local area network (WLAN), a storage area network (SAN), or a combination thereof. Such a storage device may be connected to a device implementing an embodiment of the present disclosure via an external port. Additionally, a separate storage device on the communication network may be connected to a device implementing an embodiment of the present disclosure.
[0163] In the specific embodiments of the present disclosure described above, components included in the present disclosure are expressed in the singular or plural form, depending on the specific embodiment presented. However, the singular or plural expressions are selected to suit the presented situation for convenience of explanation, and the present disclosure is not limited to singular or plural components. Components expressed in the plural form may be composed of singular elements, or components expressed in the singular form may be composed of plural elements.
[0164] While the detailed description of this disclosure has described specific embodiments, it should be understood that various modifications are possible without departing from the scope of this disclosure. Therefore, the scope of this disclosure should not be limited to the described embodiments, but should be defined not only by the scope of the claims described below, but also by equivalents thereof.
Claims
1. In a method of a first network function (NF) entity in a mobile communication system, A step of transmitting a UE service request to a UE (user equipment) through a RAN (radio access network), wherein the UE service request includes type information indicating whether the UE service request is a real-time service; and A step of receiving a UE service response from the UE through the RAN; A method characterized in that the paging message based on the above UE service request includes paging cause information.
2. In paragraph 1, A step of registering the UE service request when the above type information indicates that the UE service request is a non-real-time service; A step of determining whether to transmit the registered UE service request to the UE based on information about the urgency included in the UE service request; and A method characterized by comprising: a step of forwarding the UE service request to the UE when it is determined to transmit the UE service request to the UE.
3. In the first paragraph, the step of transmitting the UE service request to the UE; A method characterized by comprising the step of transmitting the UE service request through the RAN when the UE is in a wireless connection state.
4. In the first paragraph, the step of transmitting the UE service request to the UE; A method characterized by comprising the step of forwarding the UE service request through a third NF entity included in a core network and the RAN, when the UE is not in a wireless connection state.
5. In paragraph 2, A step of determining whether to transmit the UE service request to the UE based on the information about the urgency included in the UE service request; A method characterized by comprising: a step of determining whether to transmit the UE service request to the UE based on the information about the urgency included in the UE service request and the information about at least one urgency included in at least one previously received UE service request.
6. In paragraph 2 A step of determining whether to transmit the UE service request to the UE based on the information about the urgency included in the UE service request; A method characterized by comprising: a step of determining whether to transmit the UE service request to the UE based on the maximum allowable delay time information included in the UE service request.
7. In paragraph 1, A step of receiving the UE service request from a second NF entity; and Further comprising a step of transmitting a UE service result message to the second NF entity based on the UE service response; A method characterized in that the above UE service result message includes the above type information.
8. In the second paragraph, the step of determining whether to transmit the UE service request to the UE based on the information on the urgency included in the UE service request; A method characterized by comprising the step of determining not to transmit the UE service request to the UE if the UE service request conflicts with at least one previously received UE service request.
9. In the second paragraph, when it is determined to transmit the UE service request to the UE, the step of transmitting the UE service request to the UE is; A step of receiving a notification about the status of the UE from a RAN (radio access network); and A method characterized by comprising the step of: transmitting the UE service request and at least one previously received UE service request to the UE through the RAN when the state of the UE is connected; 10. In paragraph 1, A step of transmitting a UE status subscription request to the RAN; and comprising the step of receiving a UE status response from the RAN; A method characterized in that the notification about the status of the UE received from the RAN is based on the UE status subscription request.
11. In a first network function (NF) entity in a mobile communication system, Transmitter and receiver; and comprising at least one processor; wherein the at least one processor comprises: Transmitting a UE service request to a UE (user equipment) through a RAN (radio access network), wherein the UE service request includes type information indicating whether the UE service request is a real-time service, and It is configured to receive a UE service response from the UE through the RAN, A method characterized in that the paging message based on the above UE service request includes paging cause information.
12. In paragraph 11, If the above type information indicates that the UE service request is a non-real-time service, register the UE service request, Decide whether to transmit the registered UE service request to the UE based on information about the urgency included in the UE service request, and A first NF entity configured to forward the UE service request to the UE when it is determined to transmit the UE service request to the UE.
13. In the 11th paragraph, at least one processor, A first NF entity, characterized in that it is configured to transmit the UE service request through the RAN when the UE is in a wireless connection state.
14. In the 11th paragraph, at least one processor, A first NF entity, characterized in that it is configured to forward the UE service request through a third NF entity included in a core network and the RAN when the UE is not in a wireless connection state.
15. In the 12th paragraph, at least one processor, A first NF entity configured to determine whether to transmit the UE service request to the UE based on the information about the urgency included in the UE service request and the information about at least one urgency included in at least one previously received UE service request.
Citation Information
Patent Citations
Peer-to-peer based network management method and proxy selection server
CN102843255A
Network element management method and device, storage medium and electronic equipment
CN117041980A
Access control method and device
EP2854446A1
Systems, devices and methods of decomposing service requests into domain-specific service requests
US20180331970A1
Paging Cause Value
US20220369280A1