Method and device for retrieving context of terminal without direct connection between base stations in next generation mobile communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. This method comprises the steps of: transmitting, to a base station, a first message including an indicator indicating that transmission of additional information required for a resume is scheduled; receiving, from the base station, a second message including uplink resource information allocated on the basis of the indicator; and transmitting, to the base station on the basis of the allocated uplink resource information, the additional information which is required for the resume and has not been transmitted in the first message, wherein a user equipment is in an inactive state.

Description

Method and apparatus for reclaiming the context of a terminal without direct connection between base stations in a next-generation mobile communication system

[0001] The present disclosure relates to a next-generation mobile communication system, and more specifically, to a method and apparatus for retrieving the context of a terminal without direct connection between base stations in a next-generation mobile communication system.

[0002] 5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and can be implemented not only in frequency bands below 6 GHz ('Sub 6 GHz'), such as 3.5 gigahertz (3.5 GHz), but also in ultra-high frequency bands called millimeter waves (mmWave), such as 28 GHz and 39 GHz ('Above 6 GHz'). In addition, for 6G mobile communication technology, which is referred to as a system beyond 5G, implementation in the terahertz (THX) band (e.g., the 3 terahertz band at 95 GHz) is being considered to achieve transmission speeds 50 times faster and ultra-low latency reduced to one-tenth compared to 5G mobile communication technology.

[0003] In the early stages of 5G mobile communication technology, aiming to satisfy service support and performance requirements for enhanced Mobile BroadBand (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), technologies such as beamforming and Massive MIMO to mitigate path loss and increase transmission distance in ultra-high frequency bands, support for various numerologies (such as the operation of multiple subcarrier spacings) and dynamic operation of slot formats for the efficient utilization of ultra-high frequency resources, initial access techniques to support multi-beam transmission and broadband, definition and operation of Band-Width Parts (BWP), Low Density Parity Check (LDPC) codes for high-volume data transmission, new channel coding methods such as Polar Codes for the reliable transmission of control information, and L2 pre-processing (L2 Standardization has been carried out for pre-processing, network slicing which provides a dedicated network specialized for specific services, and other methods.

[0004] Currently, discussions are underway to improve and enhance the performance of the initial 5G mobile communication technology, taking into account the services that the 5G mobile communication technology was intended to support. Additionally, standardization of the physical layer is in progress for technologies such as V2X (Vehicle-to-Everything), which helps autonomous vehicles make driving decisions and enhance user convenience based on their own location and status information transmitted by the vehicle; NR-U (New Radio Unlicensed), which aims for system operation in unlicensed bands to comply with various regulatory requirements; NR terminal low power consumption technology (UE Power Saving); Non-Terrestrial Network (NTN), which is direct terminal-satellite communication for securing coverage in areas where communication with the terrestrial network is impossible; and positioning.

[0005] In addition, standardization is underway in the field of wireless interface architecture / protocols for technologies such as the Industrial Internet of Things (IIoT) to support new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) which provides nodes to expand network service areas by integrating wireless backhaul links and access links, Mobility Enhancement including Conditional Handover and Dual Active Protocol Stack (DAPS) Handover, and 2-step Random Access (2-step RACH for NR) which simplifies random access procedures. Standardization is also underway in the field of system architecture / services for 5G baseline architectures (e.g., Service based Architecture, Service based Interface) to incorporate Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC), which provides services based on the location of the terminal.

[0006] When such 5G mobile communication systems are commercialized, connected devices, which are increasing explosively, will be connected to communication networks. Accordingly, it is expected that there will be a need to enhance the functionality and performance of 5G mobile communication systems and to integrate the operation of connected devices. To this end, new research is planned to be conducted on 5G performance improvement and complexity reduction, support for AI services, support for metaverse services, and drone communication using eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0007] Furthermore, the advancement of these 5G mobile communication systems encompasses multi-antenna transmission technologies such as new waveforms to guarantee coverage in the terahertz band of 6G mobile communication technology, Full Dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas; metamaterial-based lenses and antennas to improve terahertz band signal coverage; high-dimensional spatial multiplexing technology using OAM (Orbital Angular Momentum); and Reconfigurable Intelligent Surface (RIS) technology; as well as Full Duplex technology for enhancing frequency efficiency and system networks in 6G mobile communication technology; AI-based communication technologies that realize system optimization by utilizing satellites and AI from the design stage and internalizing end-to-end AI support functions; and the realization of services of complexity exceeding the limits of terminal computing capabilities by utilizing ultra-high-performance communication and computing resources. It could serve as a foundation for the development of next-generation distributed computing technologies.

[0008] The objective of the present invention is to provide a device and method capable of effectively providing services in a next-generation mobile communication system through embodiments.

[0009] The technical problems to be solved by the present invention are not limited to those mentioned above, and other unmentioned technical problems will be clearly understood by those skilled in the art from the description below.

[0010] The present invention, for solving the above-mentioned problems, comprises a method performed in a User Equipment (UE) in a wireless communication system, the method including: transmitting a first message to a base station that includes an indicator indicating that the transmission of additional information required for a resume is scheduled; receiving a second message from the base station that includes uplink resource information allocated based on the indicator; and transmitting to the base station additional information required for a resume that was not transmitted in the first message based on the allocated uplink resource information, wherein the user equipment is in a deactivated state.

[0011] In one embodiment, the first message transmits some of the additional information required for the resume, and the additional information required for the resume further includes information for identifying at least one of the prior base station and network.

[0012] In one embodiment, prior to transmitting a first message, the method further includes the step of receiving a Radio Resource Control (RRC) release message from a prior base station, wherein the RRC release message includes information for identifying a network.

[0013] In one embodiment, the first message is characterized as being an RRC (Radio Resource Control) resume request message.

[0014] In addition, in another embodiment of the present invention, a method performed at a base station in a wireless communication system comprises: receiving a first message from a user device (User Equipment, UE) including an indicator indicating that the transmission of additional information required for resuming is scheduled; transmitting a second message to the UE including uplink resource information allocated based on the indicator; and receiving from the UE additional information required for resuming that was not transmitted in the first message based on the allocated uplink resource information, wherein the UE is in a deactivated state.

[0015] In addition, in another embodiment of the present invention, a user device (UE) in a wireless communication system comprises: a transceiver capable of transmitting and receiving at least one signal; and a control unit coupled to the transceiver, wherein the control unit is configured to: transmit a first message to a base station that includes an indicator indicating that the transmission of additional information required for a resume is scheduled; receive a second message from the base station that includes uplink resource information allocated based on the indicator; and transmit to the base station additional information required for a resume that was not transmitted in the first message based on the allocated uplink resource information, and wherein the user device is in a deactivated state.

[0016] In addition, in another embodiment of the present invention, a base station in a wireless communication system comprises: a transceiver capable of transmitting and receiving at least one signal; and a control unit coupled to the transceiver, wherein the control unit is configured to receive a first message from a User Equipment (UE) including an indicator indicating that the transmission of additional information required for resuming is scheduled, transmit a second message to the UE including uplink resource information allocated based on the indicator, and receive from the UE additional information required for resuming that was not transmitted in the first message based on the allocated uplink resource information, and wherein the UE is in a deactivated state.

[0017] According to an embodiment of the present disclosure, an apparatus and method capable of effectively providing services in a next-generation mobile communication system may be provided.

[0018] The effects obtainable from the present disclosure are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art to which the present disclosure belongs from the description below.

[0019] FIG. 1 is a drawing illustrating the structure of a wireless communication system (or, mobile communication system) related to the present disclosure.

[0020] FIG. 2 is a flowchart illustrating a procedure for determining a ran notification area in which a base station can recover the inactive context of a terminal through a core network according to one embodiment of the present disclosure.

[0021] FIG. 3 is a flowchart illustrating a procedure for a base station or core network to transmit a ran notification area to a terminal according to one embodiment of the present disclosure.

[0022] FIG. 4 is a flowchart illustrating a procedure for a base station to recover the inactive context of a terminal through a core network according to one embodiment of the present disclosure.

[0023] FIG. 5 is a flowchart illustrating a procedure for a base station to recover the inactive context of a terminal through multiple core networks according to one embodiment of the present disclosure.

[0024] FIG. 6A is a flowchart illustrating a procedure for recovering the inactive context of a terminal through a core network using an I-RNTI received by a base station from a terminal according to one embodiment of the present disclosure.

[0025] FIG. 6B is a flowchart illustrating a procedure for recovering the inactive context of a terminal through a core network using an I-RNTI received by a base station from a terminal according to an embodiment of the present disclosure.

[0026] FIG. 7 is a flowchart illustrating a procedure for a terminal to transmit additional information required for the RRC resume process to a base station via 4-step RACH according to one embodiment of the present disclosure.

[0027] FIG. 8 is a flowchart illustrating a procedure for a terminal to transmit additional information required for an RRC resume process to a base station via a 2-step RACH according to an embodiment of the present disclosure.

[0028] FIG. 9 is a flowchart illustrating a procedure for a terminal to transmit additional information required for the RRC resume process to a base station via RACH-less resume according to one embodiment of the present disclosure.

[0029] FIG. 10 is a flowchart illustrating a procedure for a base station to request and receive additional information required for an RRC resume process from a terminal according to an embodiment of the present disclosure.

[0030] FIG. 11 is a block diagram illustrating an example of the configuration of a base station according to one embodiment of the present disclosure.

[0031] FIG. 12 is a block diagram illustrating an example of the configuration of a terminal according to one embodiment of the present disclosure.

[0032] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the attached drawings.

[0033] In describing the embodiments, technical details that are well known in the technical field to which this disclosure belongs and are not directly related to this disclosure are omitted. This is intended to convey the essence of this disclosure more clearly without obscuring it by omitting unnecessary explanations.

[0034] For the same reason, some components in the attached drawings have been exaggerated, omitted, or schematically depicted. Additionally, the dimensions of each component do not entirely reflect their actual dimensions. Identical or corresponding components in each drawing have been assigned the same reference numbers.

[0035] The advantages and features of the present disclosure, and the methods for achieving them, will become clear by referring to the embodiments described below in detail together with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below but may be implemented in various different forms. These embodiments are provided merely to ensure that the disclosure is complete and to fully inform those skilled in the art of the scope of the disclosure, and the present disclosure is defined only by the scope of the claims. Throughout the specification, the same reference numerals refer to the same components. Furthermore, in describing the present disclosure, if it is determined that a detailed description of related functions or configurations might unnecessarily obscure the essence of the present disclosure, such detailed description is omitted. Additionally, the terms described below are defined considering their functions in the present disclosure, and these may vary depending on the intentions or conventions of the user or operator. Therefore, their definitions should be based on the content throughout the entire specification.

[0036] In describing the embodiments of the present disclosure, the focus is primarily on the New Radio (NR), which is a wireless access network, and the Packet Core 5G System, 5G Core Network, or NG Core (Next Generation Core), which is a core network, as specified by the 3rd Generation Partnership Project (3GPP), a mobile communication standardization organization. However, the main point of the present disclosure is that it can be applied to other communication systems having a similar technical background with slight modifications without significantly departing from the scope of the present disclosure, and this will be possible at the judgment of a person with skilled technical knowledge in the technical field of the present disclosure.

[0037] For convenience of explanation, some terms and names defined in 3GPP standards (specifications for 5G, NR, LTE, or similar systems) may be used below. However, the present disclosure is not limited by these terms and names and may be equally applied to systems conforming to other standards.

[0038] Terms used in the following description to identify connected nodes, terms referring to network entities, terms referring to messages, terms referring to interfaces between network entities, terms referring to various identification information, etc., are examples provided for the convenience of explanation. Accordingly, the present disclosure is not limited to the terms used herein, and other terms referring to objects having equivalent technical meanings may be used.

[0039] Hereinafter, the base station is an entity that performs resource allocation for terminals and may be at least one of gNode B, eNode B, Node B, BS (Base Station), wireless access unit, base station controller, or a node on a network. The terminal may include UE (User Equipment), MS (Mobile Station), cellular phone, smartphone, computer, or a multimedia system capable of performing communication functions. In the present disclosure, the downlink (DL) refers to the wireless transmission path of a signal transmitted by the base station to the terminal, and the uplink (UL) refers to the wireless transmission path of a signal transmitted by the terminal to the base station.

[0040] At this point, it will be understood that each block of the process flow diagrams and combinations of the flow diagrams can be executed by computer program instructions. Since these computer program instructions can be loaded into the processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, the instructions executed through the processor of the computer or other programmable data processing equipment create means to perform the functions described in the flow diagram block(s). Since these computer program instructions can also be stored in computer-available or computer-readable memory that can be directed toward the computer or other programmable data processing equipment to implement the function in a specific way, the instructions stored in computer-available or computer-readable memory can also produce a manufactured item containing instruction means to perform the function described in the flow diagram block(s). Since computer program instructions can be loaded onto a computer or other programmable data processing equipment, instructions that perform a series of operation steps on the computer or other programmable data processing equipment to create a process executed by the computer can also provide steps for executing the functions described in the flowchart block(s).

[0041] Additionally, each block may represent a module, segment, or part of code containing one or more executable instructions for executing a specific logical function(s). It should also be noted that in some alternative execution examples, the functions mentioned in the blocks may occur out of order. For example, two blocks described in succession may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order according to their corresponding functions.

[0042] In this embodiment, the term "part" refers to a software or hardware component such as a Field Programmable Gate Array (FPGA) or an Application Specific Integrated Circuit (ASIC), and the "part" performs certain roles. However, the meaning of "part" is not limited to software or hardware. The "part" may be configured to reside in an addressable storage medium or configured to run one or more processors. Accordingly, as an example, the "part" includes components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, 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." In addition, the components and '~parts' may be implemented to utilize one or more CPUs (central processing units) within the device or secure multimedia card. Furthermore, in the embodiment, the '~part' may include one or more processors.

[0043] 5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and can be implemented not only in frequency bands below 6 GHz ('Sub 6 GHz'), such as 3.5 gigahertz (3.5 GHz), but also in ultra-high frequency bands called millimeter waves (mmWave), such as 28 GHz and 39 GHz ('Above 6 GHz'). In addition, for 6G mobile communication technology, which is referred to as a system beyond 5G, implementation in the terahertz band (e.g., the 3 terahertz (3 THz) band at 95 GHz) is being considered to achieve transmission speeds 50 times faster and ultra-low latency reduced to one-tenth compared to 5G mobile communication technology.

[0044] In the early stages of 5G mobile communication technology, aiming to satisfy service support and performance requirements for enhanced Mobile BroadBand (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), technologies included beamforming and Massive MIMO to mitigate path loss and increase transmission distance in ultra-high frequency bands; support for various numerologies (such as operating multiple subcarrier spacings) and dynamic operation of slot formats for the efficient utilization of ultra-high frequency resources; initial access techniques to support multi-beam transmission and broadband; the definition and operation of Band-Width Parts (BWP); Low Density Parity Check (LDPC) codes for high-volume data transmission; new channel coding methods such as Polar Codes for the reliable transmission of control information; and L2 pre-processing (L2 Standardization has been carried out for pre-processing, network slicing which provides a dedicated network specialized for specific services, and other methods.

[0045] Currently, discussions are underway to improve and enhance the performance of the initial 5G mobile communication technology, taking into account the services that the 5G mobile communication technology was intended to support. Additionally, standardization of the physical layer is in progress for technologies such as V2X (Vehicle-to-Everything), which helps autonomous vehicles make driving decisions and enhance user convenience based on their own location and status information transmitted by the vehicle; NR-U (New Radio Unlicensed), which aims for system operation in unlicensed bands to comply with various regulatory requirements; NR terminal low power consumption technology (UE Power Saving); Non-Terrestrial Network (NTN), which is direct terminal-satellite communication for securing coverage in areas where communication with the terrestrial network is impossible; and positioning.

[0046] In addition, standardization is underway in the field of wireless interface architecture / protocols for technologies such as the Industrial Internet of Things (IIoT) to support new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) which provides nodes to expand network service areas by integrating wireless backhaul links and access links, Mobility Enhancement including Conditional Handover and Dual Active Protocol Stack (DAPS) Handover, and 2-step Random Access (2-step RACH for NR) which simplifies random access procedures. Standardization is also underway in the field of system architecture / services for 5G baseline architectures (e.g., Service based Architecture, Service based Interface) to incorporate Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC), which provides services based on the location of the terminal.

[0047] When such 5G mobile communication systems are commercialized, connected devices, which are increasing explosively, will be connected to communication networks. Accordingly, it is expected that there will be a need to enhance the functionality and performance of 5G mobile communication systems and to integrate the operation of connected devices. To this end, new research is planned to be conducted on 5G performance improvement and complexity reduction, support for AI services, support for metaverse services, and drone communication using eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0048] Furthermore, the advancement of these 5G mobile communication systems encompasses multi-antenna transmission technologies such as new waveforms to guarantee coverage in the terahertz band of 6G mobile communication technology, Full Dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas; metamaterial-based lenses and antennas to improve terahertz band signal coverage; high-dimensional spatial multiplexing technology using OAM (Orbital Angular Momentum); and Reconfigurable Intelligent Surface (RIS) technology; as well as Full Duplex technology for enhancing frequency efficiency and system networks in 6G mobile communication technology; AI-based communication technologies that realize system optimization by utilizing satellites and AI from the design stage and internalizing end-to-end AI support functions; and the realization of services of complexity exceeding the limits of terminal computing capabilities by utilizing ultra-high-performance communication and computing resources. It could serve as a foundation for the development of next-generation distributed computing technologies.

[0049] In a mobile communication system, the connection state between a terminal and a base station is defined by the RRC (Radio Resource Control) protocol, and the terminal's state is defined by the following three RRC states.

[0050] - RRC IDLE state: A state in which the terminal is not connected to the base station via RRC. In this state, the terminal detects the base station's incoming signal, monitors the paging channel to receive core network paging (CN Paging), and obtains cell system information to independently perform neighbor cell measurement and cell selection.

[0051] - RRC Connected (or Active) State (RRC CONNECTED state): A state in which the terminal is RRC connected with the base station. The terminal transmits and receives data with the network through the base station and can perform handover between cells and base stations under the control of the base station based on the terminal's measurement result reports.

[0052] - RRC Inactive State (RRC INACTIVE state): A state in which a terminal disconnects the RRC connection after being in the RRC Connected (or Active) state with the base station, allowing for a fast RRC connection by saving some of the terminal context (UE context) information of the RRC connection state between the base station and the terminal. Similar to the RRC Idle State (RRC IDLE state), the terminal detects the incoming signal from the base station and monitors the paging channel to receive core network paging (CN Paging) and base station paging (RAN paging). It can also obtain cell system information to independently perform neighbor cell measurement and cell selection. Additionally, the terminal can check the RAN-based notification area (i.e., RNA) set by the network based on the cell system information, and if it moves out of the set RAN-based notification area, it can perform a procedure to update the RAN-based notification area to the network (i.e., RNA update (RNAU)).

[0053] For a terminal in the RRC inactive state, the last serving base station, which is the base station when the terminal changes from the RRC connected state to the RRC inactive state, can store the terminal context (UE context) information. In this case, when the terminal performs an RRC connection to the base station again and transitions to the RRC connected state, the new serving base station receives the terminal context (UE context) information from the last serving base station and uses it in the RRC connection process, so the connection time until the terminal connects to the network and transmits signal messages or user data can be reduced.

[0054]

[0055] FIG. 1 is a diagram illustrating the structure of a wireless communication system (or mobile communication system) related to the present disclosure. Specifically, FIG. 1 is a diagram illustrating an example of the structure of a mobile communication system to which the technology of the present disclosure may be applied. The RAN Node (120) specified in this structure may be a base station connected to a core network (CN: Core Network) (110), and may be, for example, a 4G eNB, a 5G gNB, a 6G base station, etc. The core network (110) may be an EPC (Evolved Packet Core Network), a 5GC (5G Core Network), a 6GC (6G Core Network), etc. Some entity or function of the core network, for example, a 4G MME (Mobility Management Entity) or a 5G AMF (Access and Mobility Management Function), establishes an interface connection with the RAN Node (120). The interface (111) between the RAN Node (120) and the core network (110) can be a 4G S1 interface, a 5G NG interface, a 6G NG interface, etc. The RAN Node (120) can be connected via an interface (121) that allows direct communication with other RAN Nodes, and the interface (121) between RAN Nodes can be a 4G X2 interface, a 5G Xn interface, a 6G Xn interface, etc. Additionally, the RAN Node (120) may not be connected via an interface for direct communication with other RAN Nodes, and if there is no interface directly connected between RAN Nodes, the interface connected to the core network (110) can be used.

[0056] In order to support inter-cell movement of a terminal in the existing RRC inactive state, a direct interface (121) between base stations that are RAN Nodes is required, and context information of the terminal in the RRC inactive state can be transmitted through the direct interface (121) between base stations. Additionally, the RAN-based notification area can be configured to be limited to the cells supported by the base station that is connected to the last serving base station via a direct interface. Therefore, when the terminal's RRC state changes to the RRC inactive state, if there is no direct interface between the last serving base station, which is the base station at the time, and the base station that the terminal intends to connect to, the terminal performs a procedure (i.e., an RRC setup procedure) to transition from the RRC idle state to the RRC connected state with the new base station, and a new terminal context (UE context) is created. And, the terminal context (UE context) stored in the last serving base station is deleted from the last serving base station in accordance with the instructions of the core network (CN) (110) which recognizes that the terminal is connected to a new base station.

[0057] The present disclosure proposes an embodiment for maintaining the RRC inactive state even when the terminal in the RRC inactive state moves to a base station that does not have a direct interface connection with the last serving base station. Furthermore, the present disclosure proposes a method to reduce the connection time from when the terminal reconnects to a base station and transmits signal messages or user data by receiving terminal context (UE context) information from the last serving base station at the new serving base station and using it in the RRC connection process during the process of the terminal reconnecting to a base station and transitioning to the RRC connected state. To this end, the present disclosure includes an embodiment for setting a RAN (Radio Access Network)-based notification area (RAN notification area (RNA)) for a terminal transitioning to the RRC inactive state in a network, an embodiment for transmitting terminal context (UE context) information between base stations using an interface connected between a base station and a core network, and an embodiment for the terminal to transmit additional information to a base station.

[0058]

[0059] FIG. 2 is a flowchart illustrating a procedure for determining a RAN notification area in which a base station can recover the inactive context of a terminal according to one embodiment of the present disclosure.

[0060] A base station can determine whether the terminal's inactive context can be recovered based on information received from the terminal's resume request (e.g., I-RNTI). For example, if the base station ID is included in or identifiable within the I-RNTI (Inactive-Radio Network Temporary Identifier), the base station receiving the terminal's resume request may request the recovery of the terminal's inactive context from the base station identified in the I-RNTI. However, if the base station receiving the terminal's resume request cannot directly connect with the base station indicated in the I-RNTI, the recovery of the terminal's inactive context may not be performed. In such cases, the base station may need to perform the recovery of the terminal's inactive context through the core network. To support the recovery of the terminal's inactive context within the core network, the core network needs to identify the resume information (e.g., I-RNTI) that the base station sets for the terminal. To this end, the base station may need to share information with the core network to enable identification of the base station or the core network through the resume information.

[0061] RAN node 1 (220) may be able to connect directly with RAN node 2 (230) (e.g., Xn interface). RAN node 1 (220) may transmit the RAN area code (RANAC) along with information of RAN node 1 (220) (e.g., base station ID, cell information, TAC, Local RAN node ID) through a message transmitted to RAN node 2 (230) (e.g., Xn Setup request, NG-RAN node configuration update) (step 261), and RAN node 2 (230) may also transmit the RANAC along with information of RAN node 2 (230) through a message transmitted to RAN node 1 (220) (e.g., Xn setup response, NG-RAN node configuration update acknowledge) (step 262). Through the RANAC information, the base station can determine which RAN nodes belonging to which RANAC have a direct connection interface and can reclaim the terminal's inactive context. If the base station cannot reclaim the terminal's inactive context through the direct connection interface, it may need to reclaim the terminal's inactive context through the interface between the base station and the core network.

[0062] In step 263, RAN node 1 (220) may include the RANAC used by RAN node 1 (220) in a message (e.g., NG setup request, RAN configuration update) transmitted to the core network's CN function 1 (250) (e.g., AMF). The RANAC used by RAN node 1 (220) may be configured as OAM (Operations, Administration and Maintenance), etc., according to the plan of the operator or base station manager. Additionally, RAN node 1 (220) may transmit a Local RAN node ID (e.g., a modified ID to reduce the size of the entire base station or cell ID) to the CN function 1 (250) that can identify RAN node 1 (220). The Local RAN node ID may be determined by the base station itself so that it does not have the same value as a neighboring base station (e.g., a base station with a direct connection interface or a base station connected to the same CN function), or it may be configured as OAM, etc., according to the plan of the operator or base station manager. In addition, if the Local RAN node ID can be managed by the CN function, the RAN node 1 (220) can request the Local RAN node ID from the CN function 1 (250).

[0063] At step 264, CN function 1 (250) may include a RANAC that RAN node 1 (220) can use in a response to a message received from RAN node 1 (220) (e.g., NG setup response, RAN configuration update acknowledge) or in a message sent to CN RAN node 1 (220) (e.g., AMF configuration update). CN function 1 (250) may send a Local RAN node ID to RAN node 1 (220) to use if RAN node 1 (220) has sent a Local RAN node ID request or if there is a need to set a Local RAN node ID. CN function 1 (250) may send at least one base station or cell ID, or a RANAC, or a TAC to RAN node 1 (220) that can recover the terminal's inactive context through the CN function.

[0064] The UE (210) can be connected to the CN function 1 (250) through the RAN node 1 (220). To do this, the UE (210) can establish a connection with the RAN node 1 (220) (step 265), and the RAN node 1 (220) can transmit a NAS message transmitted by the UE (210) to the CN function 1 (250) (e.g., an initial UE (210) message) (step 266). CN function 1 (250) can transmit a message (e.g., an initial context setup request) to transmit information required for the terminal's service to RAN node 1 (220), and CN function 1 (250) can transmit RNA information available to the UE (210) (e.g., at least one base station or cell ID, or RANAC, or TAC, which can recover the terminal's inactive context through the CN function) to RAN node 1 (220) (step 267). The base station can refer to this information to instruct the terminal to use RNA information.

[0065] At step 268, RAN node 2 (230) may request or instruct RNA management through a message transmitted to CN function 1 (250). At this time, if CN function 1 (250) cannot support the inactive operation of RAN node 2 (230) for reasons such as not supporting the retrieval of the terminal's inactive context through the core network or not being able to perform RNA management such as local RAN node ID management, it may convey information to RAN node 2 (230) that it cannot support the requested operation through a response to the message (e.g., NG setup response, RAN configuration update acknowledge) or an additional message (e.g., AMF configuration update) (step 269). The CN function may include reasons in the response such as not being able to assign a local RAN node ID, not supporting UE context retrieval, or being temporarily unavailable due to overload, etc.

[0066] RAN node 3 (240) can transmit the RANAC used by RAN node 3 (240) through a message transmitted to CN function 1 (250) (step 270). The RANAC used by RAN node 3 (240) may be configured as OAM, etc., according to the plan of the operator or base station manager. RAN node 3 (240) can transmit a Local RAN node ID that can identify RAN node 3 (240) to CN function 1 (250). The Local RAN node ID may be determined by the base station itself so that it does not have the same value as a neighboring base station, or it may be configured as OAM, etc., according to the plan of the operator or base station manager. If CN function 1 (250) determines, based on information transmitted by RAN node 3 (240) and information transmitted by another RAN node, that the Local RAN node ID transmitted by RAN node 3 (240) cannot be used for reasons such as the Local RAN node ID of another RAN node having the same value, it may convey information that the Local RAN node ID corresponding to RAN node 3 (240) cannot be used (e.g., conflict indication) through a response to the message transmitted by RAN node 3 (240) (e.g., NG setup response, RAN configuration update acknowledge) or an additional message (e.g., AMF configuration update) (step 271). Additionally, CN function 1 (250) may indicate at least one Local RAN node ID that RAN node 3 (240) can use.

[0067] A RAN node 1 (220) connected to a UE (210) can transmit a Release message instructing the UE (210) to transition to an RRC inactive state (step 272). At this time, the RAN notification area information, which includes a directive instructing the transition to an RRC inactive state and some or all of the information exchanged with a directly connected RAN node or CN function, can be transmitted to the UE (210). Through this information, the UE (210) can check the Cell ID, RNA, TAC information, etc. of a RAN node directly connected to the RAN node 1 (220), and can check the Cell ID, RNA, TAC information, etc. of a RAN node capable of recovering an inactive context through a CN function.

[0068]

[0069] FIG. 3 is a flowchart illustrating a procedure for a base station or core network to transmit a ran notification area to a terminal according to one embodiment of the present disclosure.

[0070] In situations where a terminal moves through RNA, etc., when transmitting a resume request as needed, it may be necessary to determine whether the terminal's inactive context can be recovered from the last serving RAN node at the newly moved base station through the interface between base stations or the interface between the base station and the core network. In the embodiment described later in the drawings (e.g., identifying whether to transmit additional information for RRC resume), the operation of transmitting information by the terminal may vary based on information instructed by the base station or information determined by the terminal.

[0071] The UE (310) can be connected to the CN function 1 (340) through the RAN node 1 (320) (step 351).

[0072] RAN node 1 (320) may periodically broadcast system information (e.g., system information block 1 or other system information block, etc.) that may include various information (e.g., cell connection information, initial resource information, location information, time information, etc.) or transmit it at the request of a terminal (step 352). The system information may include the RANAC, TAC, PLMN, Cell ID, etc. to which RAN node 1 (320) belongs.

[0073] When a terminal moves to a RAN node belonging to a different RNA (e.g., RANAC, base station ID, cell ID, or TAC), the terminal may need information included in system information transmitted by RAN node 1 (320) or the moved RAN node to determine whether the new RAN node can recover the terminal's inactive context from the previous RAN node (last serving RAN node) through the inter-base station interface, or through the interface between the base station and the core network, or whether additional information is needed to identify the last serving RAN node or the registered CN function. To this end, RAN node 1 (320) may include base station or cell information, RANAC information, and TAC information that can recover the terminal's inactive context through the inter-base station interface or the interface between the base station and the core network in the system information (e.g., system information block 1 or other system information block, etc.).

[0074] RAN node 1 (320) can transmit a Release message (step 353) instructing the UE (310) to transition to an RRC inactive state. The RAN node 1 (320) may include base station or cell information, RANAC information, and TAC information in the Release message that can recover the terminal's inactive context through a base station interface or an interface between a base station and a core network.

[0075] RAN node 1 (320) may explicitly or implicitly include information of RNA that can recover terminal inactive context through an interface between base stations, information of RNA that can recover terminal inactive context through an interface between base stations and a core network, information of RNA that cannot recover terminal inactive context, etc.

[0076] The UE (310) can exchange information with the CN function 1 (340) using NAS messages. The CN function 1 (340) can receive a NAS message from the terminal (e.g., NAS registration request) (step 354) and perform the terminal's registration procedure, and can transmit RNA information to the UE (310) (step 355) through a response message (e.g., NAS registration accept) or additional messages (e.g., Configuration update command). The UE (310) can maintain and use the RNA information received from the CN function 1 (340) without directly receiving the information from the RAN node. Receiving such information in the CN function can be less frequent than receiving it from the RAN node via RRC release messages, etc., which can reduce signaling overhead, and the CN function has the advantage of being able to change information such as RNA without relying on the RAN node.

[0077] CN function 1 (340) may explicitly or implicitly include information of RNA that can recover terminal inactive context through the interface between base stations at the RAN node 1 (320) connected to the UE (310), information of RNA that can recover terminal inactive context through the interface between base stations and the core network, and information of RNA that cannot recover terminal inactive context.

[0078] UE (310) can move to RAN node 2 (step 356) while in an RRC inactive state.

[0079] The UE (310) can obtain information about the RNA to which the RAN node 2 (330) belongs (step 357) based on system information transmitted by the RAN node 2 (330), and can determine whether the terminal inactive context between the RAN node 1 (320) and the RAN node 2 (330) can be recovered via the interface between the base station and the core network, or whether additional information is needed to identify the last serving RAN node or the registered CN function, based on RNA information previously transmitted by the RAN node 1 (320) or the CN function 1 (340).

[0080]

[0081] FIG. 4 is a flowchart illustrating a procedure for a base station to recover the inactive context of a terminal through a core network according to one embodiment of the present disclosure.

[0082] A single base station may be connected to one or more CN functions (e.g., AMF). In one embodiment, in a procedure to retrieve the inactive context of a terminal through an interface between a base station and a core network, the RAN node that receives the terminal's resume request and the last serving RAN node may be connected to the same CN function.

[0083] The UE (410) may be connected to the CN function 1 (440) through the RAN node 1 (420) (step 451).

[0084] RAN node 1 (420) can transmit RNA information to UE (410) as system information as in the example of FIG. 3, or transmit it via an RRC message (e.g., Release) (step 452), and UE (410) can transition to an RRC inactive state.

[0085] UE (410) can move to RAN node 2 (430) while in an RRC inactive state (step 453).

[0086] When a connection is required from a cell of RAN node 2 (430) (e.g., receiving RAN paging, receiving paging, generating UL data, RNA update operation), the UE (410) may attempt to connect by sending an RRC message (e.g., Resume request) to the cell of RAN node 2 (430) (step 454). The Resume request message may include information such as a resume cause, I-RNTI, and resumeMAC-I. The resume cause may include the reason for attempting to connect to the cell, and the I-RNTI may include information about the last serving RAN node (e.g., RAN node 1 (420)), the terminal's inactive context identifier, etc. The resumeMAC-I may be a value that can check whether the terminal's inactive context identifier is valid at the last serving RAN node.

[0087] RAN node 2 (430) receives a Resume request and can identify the identifier of the last serving RAN node (e.g., local RAN node ID or base station or cell ID) via I-RNTI and check if it is connected to the last serving RAN node via a direct interface. If there is no direct interface to the last serving RAN node, RAN node 2 (430) may need to reclaim the inactive context of the UE (410) from the last serving RAN node using the interface between the base station and the core network.

[0088] RAN node 2 (430) may send a message (e.g., RAN node message forward request) to the connected CN function 1 (440) to retrieve the terminal's inactive context from the last serving RAN node (step 455). The message sent by RAN node 2 (430) to CN function 1 (440) may include the RAN node 2 (430) ID (source RAN node ID), the last serving RAN node ID (target RAN node ID), the retrieve UE (410) context request message, and information received from the UE (410) (e.g., resume cause, I-RNTI, resumeMAC-I).

[0089] If the last serving RAN node can be identified based on the message received from the RAN node 2 (430), the CN function 1 (440) can send a message requesting the recovery of the terminal's inactive context to the last serving RAN node (step 456). At this time, the CN function 1 (440) can identify the RAN node 1 (420) using the target RAN node ID received from the RAN node 2 (430), or can identify the RAN node 1 (420) using information transmitted by the terminal, such as an I-RNTI.

[0090] RAN node 1 (420) receives a message requesting the retrieval of the terminal's inactive context received from CN function 1 (440), and if the terminal's inactive context is valid, it can transmit a response containing the terminal's inactive context (step 457).

[0091] CN function 1 (440) can transmit a response (457) containing the inactive context of the terminal received from RAN node 1 (420) to RAN node 2 (430) (step 458).

[0092] RAN node 2 (430) receives the inactive context of the terminal from CN function 1 (440) and can send a path switch request to CN function 1 (440) to change the existing data transmission path (e.g., the path transmitted through RAN node 1 (420)) to RAN node 2 (430) (step 459).

[0093] CN function 1 (440) receives a path switch request (459), changes the data transmission path of the UE (410) from RAN node 1 (420) to RAN node 2 (430), and responds to RAN node 2 (430) with a path switch acknowledge message (step 460).

[0094] If CN function 1 (440) determines that there is no longer a need to maintain the UE (410) context at RAN node 1 (420), it may send a message to RAN node 1 (420) to delete the UE (410) context (e.g., UE context release command) (step 461).

[0095] RAN node 2 (430) can receive a path switch acknowledge from CN function 1 (440) and perform an action corresponding to the resume cause of UE (410). For example, it can send a message to UE (410) to keep UE (410) in an RRC inactive state without transitioning to an RRC connected state (e.g., Release) (step 462), or send a message to UE (410) to transition UE (410) to an RRC connected state (e.g., RRCResume) (step 463).

[0096]

[0097] FIG. 5 is a flowchart illustrating a procedure for a base station to recover the inactive context of a terminal through multiple core networks according to one embodiment of the present disclosure.

[0098] A single base station may be connected to one or more CN functions (e.g., AMF). In one embodiment, in a procedure to retrieve the inactive context of a terminal through an interface between a base station and a core network, the RAN node that receives the terminal's resume request and the last serving RAN node may be connected to different CN functions.

[0099] The UE (510) may be connected to the CN function 1 (550) through the RAN node 1 (520) (step 561).

[0100] RAN node 1 (520) can transmit RNA information to UE (510) as system information as in the example of FIG. 3, or transmit it via an RRC message (e.g., Release) (step 562), and UE (510) can transition to an RRC inactive state.

[0101] The UE (510) can move to the cell of RAN node 2 (530) while in an RRC inactive state (step 563).

[0102] When a connection is required from a cell of RAN node 2 (530) (e.g., receiving RAN paging, receiving paging, generating UL data, RNA update operation), the UE (510) may attempt to connect by sending an RRC message (e.g., Resume request) to the cell of RAN node 2 (530) (step 564). The Resume request message may include information such as a resume cause, I-RNTI, and resumeMAC-I. The resume cause may include the reason for attempting to connect to the cell, and the I-RNTI may include information about the last serving RAN node (e.g., RAN node 1 (520)), the terminal's inactive context identifier, etc. The resumeMAC-I may be a value that can check whether the terminal's inactive context identifier is valid at the last serving RAN node.

[0103] RAN node 2 (530) receives the resume request (step 564) transmitted by the UE (510), can identify the identifier of the last serving RAN node (e.g., local RAN node ID or base station or cell ID) via I-RNTI, and can determine if it is connected to the last serving RAN node via a direct interface. If there is no direct interface to the last serving RAN node, RAN node 2 (530) may need to reclaim the UE (510)'s inactive context from the last serving RAN node using the interface between the base station and the core network.

[0104] RAN node 2 (530) may send a message (e.g., RAN node message forward request) to the connected CN function 2 (540) (RAN node 2 (530) may not be able to send or receive messages with CN function 1 (550), or the default operation for retrieving inactive context through the interface between the base station and the core network may be set to CN function 2 (540)) to retrieve the terminal's inactive context from the last serving RAN node (step 565). The message sent by RAN node 2 (530) to CN function 2 (540) may include the RAN node 2 (530) ID (source RAN node ID), the last serving RAN node ID (target RAN node ID), the retrieve UE (510) context request message, and information received from the UE (510) (e.g., resume cause, I-RNTI, resumeMAC-I).

[0105] CN function 2 (540) can determine whether the last serving RAN node is connected to CN function 1 (550) based on information received from RAN node 2 (530) (e.g., I-RNTI), or if the last serving RAN node is not connected to CN function 2 (540), it can send a message (e.g., CN level RAN node message forward request) to CN function 1 (550) to retrieve the terminal's inactive context (step 566) through a determination such as being configured by a network operator or OAM, etc. to attempt to connect to CN function 1 (550).

[0106] CN function 1 (550) can transmit a message (e.g., RAN node message forward) to the last serving RAN node to retrieve the terminal's inactive context (e.g., CN level RAN node message forward request) based on information (e.g., I-RNTI) included in the message (e.g., CN level RAN node message forward request) to retrieve the terminal's inactive context from CN function 2 (540) (step 567).

[0107] RAN node 1 (520) receives a message requesting the retrieval of the terminal's inactive context received from CN function 1 (550), and can send a response message to CN function 1 (550) if the terminal's inactive context is valid (step 568).

[0108] CN function 1 (550) can transmit the inactive context of the terminal received from RAN node 1 (520) to CN function 2 (540) (step 569).

[0109] CN function 2 (540) can transmit the inactive context of the terminal received from CN function 1 (550) to RAN node 2 (530) (step 570).

[0110] RAN node 2 (530) receives the inactive context of the terminal from CN function 2 (540) and can send a path switch request to CN function 2 (540) to change the existing data transmission path (e.g., the path transmitted through CN function 1 (550) and RAN node 1 (520)) to CN function 2 (540) and RAN node 2 (530) (step 571).

[0111] After receiving a path switch request (step 571) from RAN node 2 (530), CN function 2 (540) can change the data transmission path of UE (510) from CN function 1 (550) to CN function 2 (540) and send a message to CN function 1 (550) to request UE context from CN function 1 (550) (e.g., CN level UE context transfer request) (step 572).

[0112] CN function 1 (550) receives a message from CN function 2 (540) requesting a change in the data transmission path of UE (510) and a UE context, and can transmit a message requesting a change in the data transmission path of UE (510) and a UE context to CN function 2 (540) (step 573).

[0113] CN function 2 (540) can send a message (e.g., path switch acknowledge) to RAN node 2 (530) acknowledging that the data transmission path of UE (510) has been changed to RAN node 2 (530) (step 574).

[0114] If CN function 1 (550) determines that there is no longer a need to maintain the UE context at RAN node 1 (520), it may send a message to RAN node 1 (520) to delete the UE context (e.g., UE context release command) (step 575).

[0115] RAN node 2 (530) can receive a path switch acknowledge from CN function 2 (540) and perform an action corresponding to the resume cause of UE (510). For example, it can send a message to UE (510) to keep UE (510) in an RRC inactive state without transitioning to an RRC connected state (e.g., Release) (step 576), or send a message to UE (510) to transition UE (510) to an RRC connected state (e.g., RRCResume) (step 577).

[0116]

[0117] FIGS. 6A and 6B are flowcharts illustrating a procedure for retrieving the inactive context of a terminal through a core network using an I-RNTI received by a base station from a terminal according to an embodiment of the present disclosure. Specifically, FIGS. 6A and 6B describe a procedure for retrieving the inactive context of a terminal through a core network using an I-RNTI received by a base station from a terminal at multiple RAN nodes and multiple CN functions. In one embodiment, the retrieval of the inactive context of a terminal in the core network may fail, and the base station may obtain information that the retrieval of the inactive context of a terminal in the core network has failed.

[0118] The UE (610) may be connected to the CN function 1 (660) through the RAN node 1 (620) (step 671).

[0119] RAN node 1 (620) can transmit RNA information to UE (610) as system information as in the example of FIG. 3, or transmit it via an RRC message (e.g., Release) (step 672), and UE (610) can transition to an RRC inactive state.

[0120] The UE (610) can move to the cell of RAN node 2 (630) while in an RRC inactive state (step 673).

[0121] When a connection is required from RAN node 2 (630) (e.g., receiving RAN paging, receiving paging, generating UL data, RNA update operation), the UE (610) may attempt to connect by sending an RRC message (step 674) (e.g., a Resume request) to the cell of RAN node 2 (630). The Resume request message may include information such as a resume cause, I-RNTI, and resumeMAC-I. The resume cause may include the reason for attempting to connect to the cell, and the I-RNTI may include information about the last serving RAN node (e.g., RAN node 1 (620)), the terminal's inactive context identifier, etc. The resumeMAC-I may be a value that can check whether the terminal's inactive context identifier is valid at the last serving RAN node.

[0122] RAN node 2 (630) receives a Resume request (step 674), can identify the identifier of the last serving RAN node (e.g., local RAN node ID) via I-RNTI, and can check if it is connected to the last serving RAN node via a direct interface (step 675). If there is no direct interface to the last serving RAN node, RAN node 2 (630) may need to reclaim the inactive context of the UE (610) from the last serving RAN node using an interface between the base station and the core network.

[0123] In one embodiment, the base station requests the core network to retrieve the inactive context, but the core network may not be able to identify the last serving RAN node.

[0124] RAN node 2 (630) can send a message (e.g., RAN node message forward request) to the connected CN function 2 (650) to retrieve the terminal's inactive context from the last serving RAN node (RAN node 2 (630) may not be able to send or receive messages with CN function 1 (660), or may be configured to prioritize sending a request to retrieve the terminal's inactive context through the interface between the base station and the core network to CN function 2 (650)) (step 676). The message that RAN node 2 (630) sends to CN function 2 (650) may include RAN node 2 (630) ID (source RAN node ID), last serving RAN node ID (target RAN node ID), retrieve UE (610) context request message (if the CN function transmits the message content without modifying it), and information received from UE (610) (e.g., resume cause, I-RNTI, resumeMAC-I).

[0125] CN function 2 (650) may not be able to identify the last serving RAN node (step 677) using the information received from RAN node 2 (630) (e.g., I-RNTI). In this case, CN function 2 (650) may send a message to RAN node 2 (630) indicating that the inactive context of the terminal failed to be retrieved (e.g., Retrieve UE (610) context failure) (step 678).

[0126] RAN node 2 (630) can send a message (e.g., RAN node message forward request) to the connected CN function 2 (650) to retrieve the terminal's inactive context from the last serving RAN node (RAN node 2 (630) may not be able to send or receive messages with CN function 1 (660), or may be configured to prioritize sending a request to retrieve the terminal's inactive context through the interface between the base station and the core network to CN function 2 (650)) (step 679). The message that RAN node 2 (630) sends to CN function 2 (650) may include RAN node 2 (630) ID (source RAN node ID), last serving RAN node ID (target RAN node ID), retrieve UE (610) context request message (if the CN function transmits the message content without modifying it), and information received from UE (610) (e.g., resume cause, I-RNTI, resumeMAC-I).

[0127] In one embodiment, the base station may request the core network to retrieve the inactive context but may incorrectly identify the last serving RAN node (step 680). It is assumed that the CN function 2 (650) can identify the last serving RAN node using information received from the RAN node 2 (630) (e.g., I-RNTI). However, since the I-RNTI may not contain all of the base station or cell IDs of the last serving RAN node, the last serving RAN node identified by the CN function 2 (650) (e.g., RAN node 3 (640)) may differ from the actual terminal's last serving RAN node (RAN node 1 (620)) (step 680).

[0128] RAN node 3 (640) receives a request from CN function 2 (650) to retrieve the terminal's inactive context (step 681), but since it does not possess the UE (610)'s inactive context, it may fail to verify the validity of the terminal's inactive context using the information from the requested I-RNTI and resumeMAC-I. RAN node 3 (640) may send a message to CN function 2 (650) indicating that it cannot retrieve the terminal's inactive context (e.g., retrieve UE context failure) (step 682).

[0129] CN function 2 (650) can send a message to RAN node 2 (630) (step 683) that the inactive context of the terminal transmitted by RAN node 3 (640) cannot be retrieved (e.g., retrieve UE context failure).

[0130] If RAN node 2 (630) fails to recover the terminal's inactive context through CN function 2 (650), or attempts to recover the terminal's inactive context through another CN function (e.g., CN function 1 (660)) in parallel with the attempt to recover the terminal's inactive context through CN function 2 (650). Steps 684 to 691 may be the same procedure as the operation to recover the terminal's inactive context through CN function 1 (660) described in the embodiment of FIG. 4.

[0131]

[0132] FIG. 7 is a flowchart illustrating a procedure for a terminal to transmit additional information required for the RRC resume process to a base station via 4-step RACH according to one embodiment of the present disclosure.

[0133] The embodiments of the drawings described above assume that a RAN node can identify the last serving RAN node or the registered CN function using information (e.g., I-RNTI) included in the RRC resume message transmitted by the terminal. The I-RNTI may include a smaller Local RAN node ID capable of identifying the entire base station and cell ID to fit the size of the UL CCCH message (e.g., 40 bits or 64 bits). As shown in the examples of FIGS. 6A and 6B, the base station receiving the terminal's resume request may not be able to identify the last serving RAN node or the registered CN function using only the Local RAN node ID, so the terminal may need to transmit additional information required for the resume to the base station.

[0134] Additional information required for the resume may be some or all of the following examples, or processed information from some of the information below.

[0135] - PLMN information (e.g., MCC and MNC)

[0136] - Base station identifier or cell identifier

[0137] - CN function (e.g., AMF) identifier (e.g., AMF region ID, AMF set ID, AMF pointer)

[0138] - Terminal identifier (e.g., 5G-TMSI)

[0139] - TAC (tracking area code)

[0140] - An identifier assigned by a base station or CN function (e.g., a local identifier for an AMF, base station, terminal, etc.). When assigned by a CN function, the identifier assigned to each terminal can be transmitted directly to the terminal using a NAS message, etc., or the identifier assigned to each terminal can be notified to the base station through a message transmitted to the base station (e.g., Core Network Assistance Information for RRC INACTIVE).

[0141] A terminal may need criteria for determining whether additional information required for resumption needs to be transmitted when moving to a base station belonging to a specific RNA. For example, when a terminal moves from a cell of RNA 1 to a cell of RNA 2, additional information for retrieving the terminal's inactive context may not be required, but when moving to a cell of RNA 3, additional information for retrieving the terminal's inactive context may be required. Accordingly, the base station may determine whether additional information needs to be provided when the terminal moves to an RNA different from the RNA to which the base station belongs and instruct the terminal accordingly. This information may be indicated by at least one cell identifier information, RANAC information, TAC information, etc., using the example of FIG. 3 or other methods not described in this disclosure.

[0142] The UE (710) may be connected to the CN function (740) through the RAN node 1 (720) (step 751).

[0143] RAN node 1 (720) can transmit RNA information to UE (710) as system information as in the example of FIG. 3, or transmit it via an RRC message (e.g., Release) (step 752), and UE (710) can transition to an RRC inactive state.

[0144] UE (710) can move to the cell of RAN node 2 (730) while in an RRC inactive state (step 753).

[0145] The UE (710) can identify (step 754) that the RNA to which RAN node 2 (730) belongs is different from the RNA to which RAN node 1 (720) belongs, through system information (e.g., RANAC, TAC, Cell ID) transmitted by RAN node 2 (730). The system information transmitted by RAN node 2 (730) may include an identifier indicating that RAN node 2 (730) supports the transmission of additional information required for the terminal's resume, or an identifier requesting the transmission of additional information required for the resume from RAN node 2 (730) (e.g., additional information indicator). Additionally, RACH resources that can instruct the base station to connect to the terminal including the transmission of additional information required for the resume (e.g., a RACH preamble transmission resource (frequency and / or time resource) that does not transmit additional information required for the resume, or a different RACH preamble transmission resource or RACH preamble sequence distinct from the preamble sequence) may be indicated.

[0146] The UE (710) may use 4-step RACH to transmit an RRC resume to RAN node 2 (730). The RACH preamble transmission resources and settings for using 4-step RACH may be instructed to the terminal by RAN node 2 (730) or another RAN node.

[0147] If UE (710) determines that additional information necessary for a resume needs to be transmitted, or if it determines that RAN node 2 (730) supports or requests the transmission of additional information necessary for a resume, it may transmit MSG1 (e.g., RACH preamble) to RAN node 2 (730) through a RACH resource that can be used to transmit additional information necessary for a resume as directed through system information transmitted by RAN node 2 (730) (step 755).

[0148] RAN node 2 (730) receives MSG1 transmitted by UE (710) and can transmit MSG2 (756) (e.g., random access response) to allocate MSG3 resources. RAN node 2 (730) can anticipate that the size of MSG3 transmitted by UE (710) will be larger than the size of MSG3 without additional information required for resume, and can allocate more resources.

[0149] UE (710) receives MSG2 transmitted by RAN node 2 (730) (step 756) and can use allocated MSG3 resources to transmit an RRC resume message and additional information required for the resume to RAN node 2 (730) (step 757). The additional information required for the resume may be the same as the existing (RRCResumeRequest or RRCResumeRequest1) or may be included in a new RRC resume request (e.g., a new RRC resume request format or an extended I-RNTI), transmitted in different RRC messages, or included in MAC CE, etc. and transmitted to RAN node 2 (730).

[0150] RAN node 2 (730) receives MSG3 (757) transmitted by UE (710) and may transmit MSG4 to UE (710) (step 758) (if, for example, in the case of contention resolution MAC CE or contention free RACH, MSG4 may not be transmitted). If UE (710) transmitted MSG3 without including additional information for resumption, or if there is a shortage of uplink resources allocated to UE (710) for MSG3, additional uplink resources may be allocated.

[0151] If the UE (710) did not send additional information for resuming from the MSG3 sent to the RAN node 2 (730) or could not send it due to a lack of uplink resources, it can send additional information necessary for resuming that was not sent from the MSG3 to the RAN node 2 (730) through the allocated uplink resources (step 759).

[0152] The base station may not set up a RACH resource that identifies additional information transmission, or it may identify additional information transmission from a spare bit of the terminal (e.g., an additional information transmission indicator). The UE (710) may transmit MSG1 (e.g., a RACH preamble) to RAN node 2 (730) through a general RACH resource (e.g., one that can be used commonly for all RACH connections or can be distinguished from a RACH that identifies additional information transmission) (step 760).

[0153] RAN node 2 (730) receives MSG1 transmitted by UE (710) and can transmit MSG2 (e.g., random access response) to allocate MSG3 resources (step 761).

[0154] UE (710) can receive MSG2 transmitted by RAN node 2 (730) and use allocated MSG3 resources to transmit an RRC resume message to RAN node 2 (730) (step 762). UE (710) can set the spare bit of the RRC resume request message to 1 to notify RAN node 2 (730) that additional information required for the resume is scheduled to be transmitted. Alternatively, depending on the uplink resource allocation situation, if additional information required for the resume can be transmitted along with the RRC resume request message in MSG3, UE (710) can set the spare bit of the RRC resume request message to 1 to notify the transmission of additional information required for the resume. The additional information required for the resume may be included in an existing or new RRC resume request (e.g., a new RRC resume request format or an extended I-RNTI), transmitted in different RRC messages, or included in MAC CE, etc., and transmitted to RAN node 2 (730).

[0155] RAN node 2 (730) receives MSG3 (762) transmitted by UE (710) and may transmit MSG4 to UE (710) (step 763) (if, for example, contention resolution MAC CE or contention free RACH, MSG4 may not be transmitted). If UE (710) transmitted MSG3 without including additional information for resumption, or if there is insufficient uplink resources allocated to UE (710) for MSG3, additional uplink resources may be allocated.

[0156] If the UE (710) did not send additional information for resuming from the MSG3 sent to the RAN node 2 (730) or could not send it due to a lack of uplink resources, it can send additional information necessary for resuming that was not sent from the MSG3 to the RAN node 2 (730) through the allocated uplink resources (step 764).

[0157] RAN node 2 (730) can more easily identify the last serving RAN node and the registered CN function by using additional information required for the resume received from the UE (710). RAN node 2 (730) may perform a procedure (step 765) to reclaim the terminal's inactive context using the examples of FIGS. 4, 5, and 6, or other methods not described in this disclosure. For the sake of brevity of the procedure, the drawing shows that the procedure for RAN node 2 (730) to reclaim the terminal's inactive context begins after receiving an uplink message following MSG3, but it may be performed after receiving MSG3 or at another time.

[0158]

[0159] FIG. 8 is a flowchart illustrating a procedure for a terminal to transmit additional information required for an RRC resume process to a base station via a 2-step RACH according to an embodiment of the present disclosure.

[0160] The UE (810) may be connected to the CN function (840) through the RAN node 1 (820) (step 851).

[0161] RAN node 1 (820) can transmit RNA information to UE (810) as system information as in the example of FIG. 3, or transmit it via an RRC message (e.g., Release) (step 852), and UE (810) can transition to an RRC inactive state.

[0162] UE (810) can move to the cell of RAN node 2 (830) while in an RRC inactive state (step 853).

[0163] The UE (810) can transmit system information (e.g., RANAC, TAC, Cell ID) to the RAN node 2 (830) (step 854). The UE (810) can identify that the RNA to which the RAN node 2 (830) belongs is different from the RNA to which the RAN node 1 (820) belongs through the system information transmitted by the RAN node 2 (830). The system information transmitted by the RAN node 2 (830) may include an identifier that the RAN node 2 (830) supports the transmission of additional information necessary for the terminal's resume, or an identifier that requests the transmission of additional information necessary for the resume from the RAN node 2 (830) (e.g., an additional information indicator). In addition, a RACH resource capable of instructing the base station to connect to the terminal including the transmission of additional information required for resumption (e.g., a RACH preamble transmission resource (frequency and / or time resource) that does not transmit additional information required for resumption, or a different RACH preamble transmission resource or RACH preamble sequence distinct from the preamble sequence) may be indicated.

[0164] The UE (810) may use a 2-step RACH to transmit an RRC resume to RAN node 2 (830). Resources and settings for transmitting the RACH preamble and PUSCH payload for using the 2-step RACH may be instructed to the terminal by RAN node 2 (830) or another RAN node. Resources allocated to the PUSCH payload of the MSGA that can be transmitted using the RACH may be greater than resources allocated to the PUSCH payload that does not contain additional information required for the resume.

[0165] If UE (810) determines that additional information required for a resume needs to be transmitted, or if it determines that RAN node 2 (830) supports or requests the transmission of additional information required for a resume, it may transmit MSGA (e.g., RACH preamble and PUSCH payload) to RAN node 2 (830) via RACH resources that can be used to transmit additional information required for a resume as directed by system information transmitted by RAN node 2 (830) (step 855). The PUSCH payload may contain an RRC resume message and additional information required for a resume, and the additional information required for a resume may be included in an existing or new RRC resume request (e.g., a new RRC resume request format or an extended I-RNTI), transmitted in different RRC messages, or included in MAC CE, etc. and transmitted to RAN node 2 (830).

[0166] RAN node 2 (830) receives the MSGA transmitted by the UE (810) (step 855) and can transmit an MSGB (e.g., contention resolution or random access response) in response (step 856). If the UE (810) transmitted the MSGA without including additional information for resumption, or if it is determined that there is a shortage of uplink resources allocated to the UE (810) for the MSGA, additional uplink resources may be allocated.

[0167] If the UE (810) did not send additional information for resuming from the MSGA sent to the RAN node 2 (830) or could not send it due to a lack of uplink resources, it can send additional information necessary for resuming that was not sent from the MSGA to the RAN node 2 (830) via RRC or MAC CE messages, etc. (step 857) through the allocated uplink resources.

[0168] The base station may not set a RACH resource that identifies additional information transmission, or it may identify additional information transmission from the terminal's spare bit (e.g., additional information transmission indicator). The UE (810) may transmit MSGA (e.g., RACH preamble and PUSCH payload) to RAN node 2 (830) via a resource for a 2-step RACH connection (e.g., which may be used commonly for all RACH connections or may be distinct from the RACH that identifies additional information transmission) (step 858). The UE (810) may notify RAN node 2 (830) that additional information required for the resume is scheduled to be transmitted by setting the spare bit of the RRC resume request message to 1. Alternatively, depending on the uplink resource allocation situation, if additional information required for resume can be transmitted along with the RRC resume request message in the PUSCH payload of MSGA, the UE (810) may set the spare bit of the RRC resume request message to 1 to indicate the transmission of additional information required for resume. The additional information required for resume may be included in an existing or new RRC resume request (e.g., a new RRC resume request format or an extended I-RNTI), transmitted in different RRC messages, or included in MAC CE, etc. and transmitted to RAN node 2 (830).

[0169] RAN node 2 (830) receives the MSGA transmitted by the UE (810) (step 858) and can transmit an MSGB (e.g., contention resolution or random access response) in response (step 859). If the UE (810) transmitted the MSGA without including additional information for resumption, or if it is determined that there is a shortage of uplink resources allocated to the UE (810) for the MSGA, additional uplink resources may be allocated.

[0170] If the UE (810) did not send additional information for resuming from the MSGA (step 858) sent to the RAN node 2 (830) or could not send it due to a lack of uplink resources, it can send additional information necessary for resuming that was not sent from the MSGA (step 858) to the RAN node 2 (830) via an RRC or MAC CE message, etc. (step 860) through the allocated uplink resources.

[0171] RAN node 2 (830) can more easily identify the last serving RAN node and the registered CN function by using additional information required for the resume received from the UE (810). RAN node 2 (830) may perform a procedure (step 861) to reclaim the terminal's inactive context using the examples of FIGS. 4, 5, and 6, or other methods not described in this disclosure. For the sake of brevity of the procedure, the drawing shows that the procedure for RAN node 2 (830) to reclaim the terminal's inactive context begins after receiving the transmission of MSGB or a subsequent uplink message, but it may be performed after receiving MSGA, after the transmission of MSGB, or at other times.

[0172]

[0173] FIG. 9 is a flowchart illustrating a procedure for a terminal to transmit additional information required for the RRC resume process to a base station via RACH-less resume according to one embodiment of the present disclosure.

[0174] The UE (910) may be connected to the CN function (940) through the RAN node 1 (920) (step 951).

[0175] RAN node 1 (920) can transmit RNA information to UE (910) as system information as in the example of FIG. 3, or transmit it via an RRC message (e.g., Release) (step 952), and UE (910) can transition to an RRC inactive state.

[0176] UE (910) can move to the cell of RAN node 2 (930) while in an RRC inactive state (step 953).

[0177] The UE (910) can transmit system information (e.g., RANAC, TAC, Cell ID) to the RAN node 2 (930) (step 954). The UE (910) can identify that the RNA to which the RAN node 2 (930) belongs is different from the RNA to which the RAN node 1 (920) belongs through the system information transmitted by the RAN node 2 (930). The system information transmitted by the RAN node 2 (930) may include an identifier indicating that the RAN node 2 (930) supports the transmission of additional information necessary for the terminal's resume, or an identifier (e.g., an additional information indicator) requesting the transmission of additional information necessary for the resume from the RAN node 2 (930). The UE (910) may be instructed in advance to transmit uplink messages or data to the RAN node 2 (930) without performing RACH. These settings may be received via an RRC message (e.g., RRC release or system information) from RAN node 1 (920) or RAN node 2 (930) and may include information on the time to maintain information (timing advance, TA) for synchronization between the RAN node and the UE (910), or information on a signal to receive a new TA. Additionally, information on a periodic resource (e.g., configured grant, CG) to transmit uplink messages when the UE (910)'s TA is valid may be included. The UE (910) may transmit a signal (e.g., RACH preamble or low power wake-up signal) to RAN node 2 (930) to receive a new TA or to inform the RAN node that it can transmit uplink messages that do not perform RACH.A signal for a resume that does not use RACH may be transmitted using a different resource or signal form that is distinct from the signal for a general RACH connection method (e.g., 4-step or 2-step RACH).

[0178] After receiving a RACH preamble or low power wake-up signal from the UE (910) (step 955), the RAN node 2 (930) may instruct the UE (910) to use a TA (step 956) or instruct the UE (910) to use CG (Confiured Grant) resource information (e.g., time and frequency information, resource cycle) (step 956). This information may be similar to the existing MSG2 (e.g., random access response) or simplified information for TA management or CG resource information, such as excluding the allocation of uplink resources.

[0179] UE (910) may use the designated CG resources to transmit an uplink message for resuming to RAN node 2 (930). UE (910) may transmit an RRC resume message and additional information required for resuming (step 957) if it determines that transmission of additional information required for resuming is necessary, or if it determines that RAN node 2 (930) supports or requests transmission of additional information required for resuming. The additional information required for resuming may be included in an existing or new RRC resume request (e.g., a new RRC resume request format or an extended I-RNTI), transmitted in a different RRC message, or transmitted to RAN node 2 (930) by being included in MAC CE, etc. Different information (e.g., RRC resume request and additional information) may be transmitted using the same or different CG resources.

[0180] RAN node 2 (930) can more easily identify the last serving RAN node and the registered CN function by using additional information required for the resume received from the UE (910). RAN node 2 (930) can perform a procedure (step 958) to retrieve the inactive context of the terminal using the examples of FIG. 4, 5, and 6, or other methods not described in this disclosure.

[0181]

[0182] FIG. 10 is a flowchart illustrating a procedure for a base station to request and receive additional information required for an RRC resume process from a terminal according to an embodiment of the present disclosure.

[0183] A base station may receive a resume request from a terminal and perform a procedure to reclaim an inactive context. In this case, if the information received from the terminal by the base station or core network (e.g., I-RNTI) cannot identify the last serving RAN node or registered CN function or reclaim the inactive context, additional information (e.g., some or all of the information described in FIG. 7) may be required from the terminal. Transmitting additional information in response to a terminal's resume request may result in signaling overhead, a decrease in coverage due to a larger message size, or reduced resource utilization. To overcome this, a method is proposed in which a base station requests and receives additional information from the terminal as an example.

[0184] The UE (1010) may be connected to the CN function 1 (1050) through the RAN node 1 (1020) (step 1061).

[0185] RAN node 1 (1020) can transmit RNA information to UE (1010) as system information as in the example of FIG. 3, or transmit it via an RRC message (e.g., Release) (step 1062), and UE (1010) can transition to an RRC inactive state.

[0186] The UE (1010) can move to the cell of RAN node 2 (1030) while in an RRC inactive state (step 1063).

[0187] RAN node 2 (1030) can transmit system information to UE (1010) (step 1064). The system information may include an identifier that RAN node 2 (1030) supports the transmission of additional information necessary for the terminal's resume, or an identifier that requests the transmission of additional information necessary for the resume from RAN node 2 (1030) (e.g., additional information indicator).

[0188] The UE (1010) can send an RRC resume request to the RAN node 2 (1030) (step 1065) and start a timer (e.g., T319) that can determine the failure of the RRC resume procedure (step 1081). The value of this timer can be set in advance by the base station or OAM, etc., on the terminal, and when it expires, the UE (1010) can determine that the RRC resume procedure has failed and enter the RRC IDLE state.

[0189] If the UE (1010) supports the function of transmitting additional information required for the resume procedure in response to a request from the base station, it may include an indicator in the RRC resume request message that it can process the message, for example, by setting the spare bit to 1.

[0190] RAN node 2 (1030), having received an RRC resume request from UE (1010), may attempt to reclaim the terminal's inactive context (step 1066) based on information received from UE (1010) (e.g., I-RNTI). The attempt by RAN node 2 (1030) to reclaim the terminal's inactive context may be performed as exemplified in FIGS. 4, FIGS. 5, FIGS. 6A, and FIGS. 6B. If the attempt to reclaim the terminal's inactive context is successful, subsequent procedures may follow the success procedures of FIGS. 4, FIGS. 5, FIGS. 6A, and FIGS. 6B. RAN node 2 (1030) can determine (step 1067) that the attempt to retrieve the terminal's inactive context from the UE (1010) has failed through the examples of FIGS. 6A and 6B (an example of failing to identify the last serving RAN node or identifying it as an incorrect last serving RAN node) and the procedure exemplified in FIGS. 6A and 6B (e.g., retrieve UE (1010) context failure).

[0191] RAN node 2 (1030) may request additional information necessary for resuming the inactive context from the terminal (step 1068) if it determines that additional information is needed for resuming the inactive context due to reasons such as failing to attempt to reclaim the terminal's inactive context (step 1067) or failing to identify the CN function using information transmitted by UE (1010) (e.g., I-RNTI). The request for additional information may be indicated by DCI, MAC CE, RRC messages, etc., and may explicitly or implicitly request some or all of the additional information exemplified in FIG. 7.

[0192] If the RAN node 2 (1030) requests additional information necessary for resuming (step 1068), the UE (1010) may stop the timer (e.g., T319) that was started when the RRC resum request was sent (step 1082). Since this timer (e.g., T319) may not have taken into account that the RAN node requests additional information necessary for resuming from the UE (1010), a new timer may be needed.

[0193] The UE (1010) may respond to the RAN node 2 (1030) with additional information required for the resume requested by the RAN node 2 (1030) (step 1068), such as an RRC or MAC CE message (step 1069). The UE (1010) may start a new timer (e.g., T319x) (step 1083). This timer (e.g., T319x) may start after receiving a message from the RAN node 2 (1030) requesting additional information required for the resume. The value of this timer (e.g., T319x) may be set in advance by the base station instructions or OAM on the terminal, and upon expiration, the UE (1010) may determine the RRC resume procedure to have failed and enter the RRC IDLE state. This timer (e.g., T319x) may be a timer for compensating for delay time that may be added, such as an attempt to reclaim the terminal's inactive context.

[0194] RAN node 2 (1030) can more easily identify the last serving RAN node and the registered CN function (e.g., CN function 1 (1050)) by using additional information required for the resume received from the UE (1010). RAN node 2 (1030) can perform a procedure to recover the inactive context of the terminal (step 1070) using the examples of FIG. 4, 5, and 6, or other methods not described in this disclosure.

[0195] RAN node 2 (1030) can perform an action corresponding to the resume cause of UE (1010) after the inactive context retrieval and path switch procedure of the terminal (e.g., the example of FIG. 4, 5, and 6). For example, it can send a message (e.g., Release) to UE (1010) to keep UE (1010) in an RRC inactive state without transitioning to an RRC connected state (step 1071), or send a message (e.g., RRCResume) to UE (1010) to transition UE (1010) to an RRC connected state (step 1072).

[0196] After receiving a response to an RRC resume request (e.g., RRC release or RRC resume) from RAN node 2 (1030), the UE (1010) may stop the timer (e.g., T319x) associated with the transmission of additional information required for the resume (step 1084).

[0197]

[0198] FIG. 11 is a block diagram illustrating an example of the configuration of a base station according to one embodiment of the present disclosure.

[0199] A base station may include a transceiver (1105), a control unit (1110), and a storage unit (1115). The transceiver (1105), the control unit (1110), and the storage unit (1115) may operate according to the communication method of the base station described above. A network device may also correspond to the structure of the base station. However, the components of the base station are not limited to the examples described above. For example, the base station may include more components or fewer components than the components described above. For example, the base station may include a transceiver (1105) and a control unit (1110). Furthermore, the transceiver (1105), the control unit (1110), and the storage unit (1115) may be implemented in the form of a single chip.

[0200] The transceiver (1105) collectively refers to the receiver and the transmitter of a base station and can transmit and receive signals with a terminal, another base station, or another network device. At this time, the signals transmitted and received may include control information and data. For example, the transceiver (1105) can transmit system information to a terminal and can transmit a synchronization signal or a reference signal. To this end, the transceiver (1105) may be composed of an RF transmitter that up-converts and amplifies the frequency of the transmitted signal, and an RF receiver that low-noise amplifies the received signal and down-converts the frequency. However, this is merely one embodiment of the transceiver (1105), and the components of the transceiver (1105) are not limited to an RF transmitter and an RF receiver. The transceiver (1105) may include a wired / wireless transceiver and may include various configurations for transmitting and receiving signals. Additionally, the transceiver (1105) can receive a signal through a communication channel (e.g., a wireless channel) and output it to a control unit (1110), and transmit the signal output from the control unit (1110) through the communication channel. Additionally, the transceiver (1105) can receive a communication signal and output it to a processor, and transmit the signal output from the processor to a terminal, another base station, or another entity through a wired or wireless network.

[0201] The storage unit (1115) can store programs and data necessary for the operation of the base station. Additionally, the storage unit (1115) can store control information or data included in signals obtained from the base station. The storage unit (1115) may be composed of a storage medium or a combination of storage media such as ROM, RAM, hard disk, CD-ROM, and DVD. Additionally, the storage unit (1115) can store at least one of information transmitted and received through the transmission and reception unit (1105) and information generated through the control unit (1110).

[0202] In the present disclosure, the control unit (1110) may be defined as a circuit or an application-specific integrated circuit or at least one processor. The processor may include a communication processor (CP) that performs control for communication and an application processor (AP) that controls upper layers such as applications. The control unit (1110) may control the overall operation of a base station according to an embodiment proposed in the present disclosure. For example, the control unit (1110) may control the signal flow between each block to perform operations according to the flowchart described above.

[0203]

[0204] FIG. 12 is a block diagram illustrating an example of the configuration of a terminal according to one embodiment of the present disclosure.

[0205] The terminal may include a transceiver (1205), a control unit (1210), and a storage unit (1215). The transceiver (1205), the control unit (1210), and the storage unit (1215) may operate according to the communication method of the terminal described above. However, the components of the terminal are not limited to the examples described above. For example, the terminal may include more components or fewer components than the components described above. For example, the terminal may include a transceiver (1205) and a control unit (1210). In addition, the transceiver (1205), the control unit (1210), and the storage unit (1215) may be implemented in the form of a single chip.

[0206] The transceiver (1205) is a collective term for the receiving unit and the transmitting unit of a terminal, and can transmit and receive signals with a base station, another terminal, or a network entity. The signals transmitted and received with the base station may include control information and data. For example, the transceiver (1205) can receive system information from the base station and can receive a synchronization signal or a reference signal. To this end, the transceiver (1205) may be composed of an RF transmitter that up-converts and amplifies the frequency of the transmitted signal, and an RF receiver that low-noise amplifies the received signal and down-converts the frequency. However, this is merely one embodiment of the transceiver (1205), and the components of the transceiver (1205) are not limited to an RF transmitter and an RF receiver. Additionally, the transceiver (1205) may include a wired / wireless transceiver and may include various configurations for transmitting and receiving signals. Additionally, the transceiver (1205) can receive a signal through a wireless channel and output it to the control unit (1210), and transmit the signal output from the control unit (1210) through the wireless channel. Additionally, the transceiver (1205) can receive a communication signal and output it to a processor, and transmit the signal output from the processor to a network entity through a wired or wireless network.

[0207] The storage unit (1215) can store programs and data necessary for the operation of the terminal. Additionally, the memory (1215) can store control information or data included in signals obtained from the terminal. The storage unit (1215) may be composed of a storage medium or a combination of storage media such as ROM, RAM, hard disk, CD-ROM, and DVD.

[0208] In the present disclosure, the control unit (1210) may be defined as a circuit or an application-specific integrated circuit or at least one processor. The processor may include a communication processor (CP) that performs control for communication and an application processor (AP) that controls upper layers such as applications. The control unit (1210) may control the overall operation of the terminal according to the embodiment proposed in the present disclosure. For example, the control unit (1210) may control the signal flow between each block to perform operations according to the flowchart described above.

Claims

1. A method performed on a User Equipment (UE) in a wireless communication system, A step of transmitting a first message to a base station, including an indicator that indicates that additional information required for a resume is scheduled to be transmitted; A step of receiving a second message from the base station, the message including uplink resource information allocated based on the indicator; and The method includes the step of transmitting additional information required for the resume, which was not transmitted in the first message, to the base station based on the allocated uplink resource information. A method characterized in that the above user device is in a deactivated state.

2. In Paragraph 1, The first message above transmits some of the additional information required for the resume, and A method characterized in that the additional information required for the above Resume further includes information for identifying at least one of the prior base stations and networks.

3. In Paragraph 1, Prior to the transmission of the first message above, the method further includes the step of receiving an RRC (Radio Resource Control) release message from a previous base station, and A method characterized in that the above RRC release message includes information for identifying a network.

4. In Paragraph 1, A method characterized in that the first message above is an RRC (Radio Resource Control) resume request message.

5. In a method performed at a base station in a wireless communication system, A step of receiving a first message from a User Equipment (UE) that includes an indicator indicating that additional information required for a resume is scheduled to be transmitted; A step of transmitting a second message to the above UE, the message including uplink resource information allocated based on the indicator; and The method includes the step of receiving additional information required for the resume that was not transmitted in the first message, based on the allocated uplink resource information from the above UE. A method characterized in that the above UE is in a deactivated state.

6. In Paragraph 5, The first message above transmits some of the additional information required for the resume, and A method characterized in that the additional information required for the above Resume further includes information for identifying at least one of the prior base stations and networks.

7. In Paragraph 5, Prior to the transmission of the first message above, an RRC (Radio Resource Control) release message is transmitted from the former base station to the UE, and A method characterized in that the above RRC release message includes information for identifying a network.

8. In Paragraph 5, A method characterized in that the first message above is an RRC (Radio Resource Control) resume request message.

9. In a User Equipment (UE) in a wireless communication system, A transceiver capable of transmitting and receiving at least one signal; and It includes a control unit combined with the above-mentioned transmitting and receiving unit, and The above control unit is: Transmit a first message to a base station, including an indicator that the transmission of additional information required for resume is scheduled, and Receiving a second message from the base station that includes uplink resource information allocated based on the indicator, and The above base station is configured to transmit additional information required for the resume that was not transmitted in the first message, based on the allocated uplink resource information, and A user device characterized by the above user device being in a disabled state.

10. In Paragraph 9, The first message above transmits some of the additional information required for the resume, and A user device characterized by additional information required for the above Resume further including information for identifying at least one of the prior base stations and networks.

11. In Paragraph 9, The above control unit is further configured to receive an RRC (Radio Resource Control) release message from a previous base station prior to the transmission of the first message, and A user device characterized in that the above RRC release message includes information for identifying a network.

12. In Paragraph 9, A user device characterized in that the first message above is an RRC (Radio Resource Control) resume request message.

13. In a base station of a wireless communication system, A transceiver capable of transmitting and receiving at least one signal; and It includes a control unit combined with the above-mentioned transmitting and receiving unit, and The above control unit is: Receiving a first message from a User Equipment (UE) that includes an indicator indicating that additional information required for a resume is scheduled to be transmitted, and Transmit a second message containing uplink resource information allocated based on the indicator to the above UE, and It is configured to receive additional information required for the resume that was not transmitted in the first message, based on the allocated uplink resource information from the above UE, and A base station characterized in that the above-mentioned UE is in a deactivated state.

14. In Paragraph 13, The first message above transmits some of the additional information required for the resume, and A base station characterized by additional information required for the above Resume further including information for identifying at least one of the prior base stations and networks.

15. In Paragraph 13, Prior to the transmission of the first message above, an RRC (Radio Resource Control) release message is transmitted from the former base station to the UE, and A base station characterized in that the above RRC release message includes information for identifying a network.

Images