Method and apparatus for operating protocol layers of a terminal in a mobile communication system

Abstract

A communication method and system are provided for converging a 5th-Generation (5G) communication system for supporting higher data rates beyond a 4th-Generation (4G) system with a technology for Internet of Things (IoT). The disclosure can be applied to smart services based on 5G communication technologies and IoT-related technologies, such as smart home, smart building, smart city, smart car, connected car, health care, digital education, smart retail, security and safety services. The disclosure relates to a scheme for improving operation of a terminal in an RRC inactive mode.

Description

[0001] This application is a divisional application of the patent application filed on April 5, 2019, with application number 201980024388.X and entitled "Method and apparatus for operating a terminal in an inactive mode in a next-generation mobile communication system". Technical Field

[0002] This disclosure relates to a method and apparatus for enhancing the effective operation and security of protocol layer devices in a next-generation mobile communication system when a terminal performs a state transition from Radio Resource Control (RRC) connected mode to RRC inactive mode or from RRC inactive mode to RRC connected mode. Background Technology

[0003] To meet the increased demand for wireless data services since the deployment of 4G communication systems, efforts have been made to develop improved 5G or pre-5G communication systems. Therefore, 5G or pre-5G communication systems are also referred to as "super 4G networks" or "post-LTE systems." The implementation of 5G wireless communication systems in higher frequency (mmWave) bands (e.g., the 60GHz band) is being considered to achieve higher data rates. To reduce radio wave propagation loss and increase transmission distance, the following technologies have been discussed in 5G communication systems: beamforming, massive MIMO, full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive MIMO technology. Furthermore, in 5G communication systems, development is underway to improve system networks based on: advanced small cells, cloud radio access networks (RAN), ultra-dense networks, device-to-device (D2D) communication, wireless backhaul, mobile networks, cooperative communication, coordinated multipoint (CoMP), and receiver interference cancellation. In 5G systems, the following technologies have been developed: hybrid FSK and QAM modulation (FQAM) and sliding window superposition coding (SWSC) as advanced coding and modulation (ACM); and filter bank multicarrier (FBMC), non-orthogonal multiple access (NOMA) and sparse code multiple access (SCMA) as advanced access technologies.

[0004] The internet, a human-centric network of connections where humans generate and consume information, is now evolving into the Internet of Things (IoT), in which distributed entities, such as things, exchange and process information without human intervention. The Internet of Everything (IoE), a combination of IoT technology and big data processing technology connected to cloud servers, has emerged. Because IoT implementation requires technological elements such as sensing technology, wired / wireless communication and network infrastructure, service interface technology, and security technology, sensor networks, machine-to-machine (M2M) communication, and machine-type communication (MTC) have recently been studied. Such an IoT environment can provide intelligent internet technology services that create new value for human life by collecting and analyzing data generated between connected things. Through the integration and combination of existing information technology (IT) with various industrial applications, IoT can be applied to a wide range of fields, including: smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, healthcare, smart appliances, and advanced medical services.

[0005] Consistent with this, various attempts have been made to apply 5G communication systems to IoT networks. For example, technologies such as sensor networks, MTC, and M2M communication can be implemented through beamforming, MIMO, and array antennas. The application of cloud RAN, as a big data processing technology as described above, can also be considered an example of the convergence between 5G and IoT technologies.

[0006] Recently, with the growth of communication systems, various studies have been conducted on terminals operating in RRC inactive mode. Therefore, improvements are needed in cell selection and reselection methods for terminals operating in RRC idle mode and RRC inactive mode.

[0007] The above information is presented as background information only to aid in understanding this disclosure. No determination or assertion is made regarding whether any of the above applies to prior art relating to this disclosure. Summary of the Invention

[0008] Technical issues

[0009] Mobile communication systems have been developed to provide communication while ensuring user mobility. With rapid technological advancements, these systems now offer not only voice communication but also high-speed data communication services. In such wireless mobile communication systems, terminals can receive services intermittently, rather than continuously for extended periods. Therefore, if a terminal continuously receives and identifies base station signals, its power consumption will be rapid. Reducing this power consumption is therefore crucial. To this end, the terminal can enter standby mode by switching from Radio Resource Control (RRC) connected mode to RRC idle mode. However, switching back from standby mode to RRC connected mode requires numerous signaling processes. Therefore, in next-generation mobile communication systems, an RRC inactive mode or a lightly connected mode can be introduced to reduce these signaling processes, similar to standby mode, enabling faster connection and saving terminal power. However, an efficient method is needed for switching between RRC connected mode and RRC inactive mode (or lightly connected mode), or vice versa.

[0010] As mentioned above, when a terminal of a next-generation mobile communication system performs a state transition, it is necessary to specify the operation of protocol layer devices, such as Media Access Control (MAC), Radio Link Control (RLC), and Packet Data Convergence Protocol (PDCP), which are suitable for the RRC inactive mode to be implemented or newly introduced; and in the case of sending and receiving RRC messages in RRC inactive mode, specific encryption and decryption processes for security need to be taken into account.

[0011] Additional aspects will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the embodiments presented.

[0012] Solution

[0013] The aspects disclosed herein will solve at least the aforementioned problems and / or disadvantages, and provide at least the following advantages.

[0014] According to an aspect of this disclosure, a method for a terminal in a wireless communication system is provided. The method includes: receiving a message from a base station, the message including configuration information indicating a Radio Resource Control (RRC) inactive state; based on the information, setting a state variable of a Packet Data Convergence Protocol (PDCP) entity associated with a Data Radio Bearer (DRB) to an initial value; and based on the information, discarding at least one stored PDCP Protocol Data Unit (PDU) of the PDCP entity associated with the DRB.

[0015] According to another aspect of this disclosure, a terminal in a wireless communication system is provided. The terminal includes: a transceiver configured to transmit and receive signals; and a controller configured to: receive a message from a base station, the message including information indicating a configuration of Radio Resource Control (RRC) inactive state; based on the information, set a state variable of a Packet Data Convergence Protocol (PDCP) entity associated with a Data Radio Bearer (DRB) to an initial value; and based on the information, discard at least one stored PDCP Protocol Data Unit (PDU) of the PDCP entity associated with the DRB.

[0016] According to an aspect of this disclosure, a method for a base station in a wireless communication system is provided. The method includes: generating a message including information indicating a configuration of Radio Resource Control (RRC) inactivity; and sending the message to a terminal, wherein, based on the information, a state variable of a Packet Data Convergence Protocol (PDCP) entity associated with the terminal's Data Radio Bearer (DRB) is set to an initial value; and wherein, based on the information, at least one stored PDCP Protocol Data Unit (PDU) of the PDCP entity associated with the DRB is discarded.

[0017] According to an aspect of this disclosure, a base station in a wireless communication system is provided. The base station includes: a transceiver configured to transmit and receive signals; and a controller configured to: generate a message including information indicating a configuration of Radio Resource Control (RRC) inactivity; and transmit the message to a terminal, wherein, based on the information, a state variable of a Packet Data Convergence Protocol (PDCP) entity associated with the terminal's Data Radio Bearer (DRB) is set to an initial value, and wherein, based on the information, at least one stored PDCP Protocol Data Unit (PDU) of the PDCP entity associated with the DRB is discarded.

[0018] Advantages of the invention

[0019] According to this disclosure, an effective protocol layer device operation is proposed to prevent the following when a terminal of a next-generation mobile communication system performs a state transition from RRC inactive mode to RRC connected mode or from RRC connected mode to RRC inactive mode: RRC message exchange to enhance security, unnecessary data transmission, and state inconsistencies (e.g., whether data has been successfully transmitted or state variables) between the terminal and the base station.

[0020] According to another aspect of this disclosure, in the event of a state transition of the terminal, for example, when the terminal transitions from RRC connection mode to RRC inactive mode and then back to RRC connection mode, a connection release procedure and a connection setup procedure are specifically proposed for security considerations; and the operations to be performed by the corresponding protocol layer device during the connection release procedure and connection setup procedure are proposed to resolve the issues of state inconsistency and unnecessary retransmission between the protocol layers of the terminal and the base station.

[0021] Other aspects, advantages, and salient features of this disclosure will become apparent to those skilled in the art from the following detailed description of various embodiments of the disclosure taken in conjunction with the accompanying drawings. Attached Figure Description

[0022] The above and other aspects, features and advantages of certain embodiments of the present disclosure will become more apparent from the following description taken in conjunction with the accompanying drawings, in which:

[0023] Figure 1 This is a diagram illustrating the structure of a Long Term Evolution (LTE) system according to an embodiment of the present disclosure;

[0024] Figure 2 This is a diagram illustrating the radio protocol structure in an LTE system according to an embodiment of the present disclosure;

[0025] Figure 3 This is a diagram illustrating the structure of a next-generation mobile communication system according to an embodiment of the present disclosure;

[0026] Figure 4 This is a diagram illustrating the radio protocol structure of a next-generation mobile communication system according to an embodiment of the present disclosure;

[0027] Figure 5 This is a diagram illustrating a mode in which a terminal can remain in a next-generation mobile communication system according to an embodiment of the present disclosure;

[0028] Figure 6 This is a diagram illustrating the process of a terminal transitioning from Radio Resource Control (RRC) connection mode to RRC idle mode and the process of a terminal transitioning from RRC idle mode to RRC connection mode according to embodiments of the present disclosure;

[0029] Figure 7 This is a diagram illustrating the process of a terminal switching from RRC connection mode to RRC inactive mode (or light connection mode) according to an embodiment of the present disclosure, and the process of a terminal switching from RRC inactive mode (or light connection mode) to RRC connection mode.

[0030] Figure 8This is a diagram illustrating a first embodiment of the corresponding protocol layer device operation and security setting process when a terminal in RRC inactive mode receives a paging message or restores its connection to the network due to the presence of data to be sent to the uplink, according to an embodiment of the present disclosure.

[0031] Figure 9 This is a diagram illustrating a second embodiment of the protocol layer device operation and security setting process according to an embodiment of the present disclosure when the timer for periodic radio access network (RAN) notification area update of a terminal in RRC inactive mode expires, when the terminal in RRC inactive mode deviates from the RAN notification area, or when the terminal in RRC inactive mode restores its connection to the network for RAN notification area update.

[0032] Figure 10 This is a diagram illustrating the operation of a terminal during the execution process according to an embodiment of the present disclosure;

[0033] Figure 11 This is a diagram illustrating the structure of a terminal according to an embodiment of the present disclosure; and

[0034] Figure 12 This is a diagram illustrating the structure of a base station according to an embodiment of the present disclosure.

[0035] Throughout the accompanying drawings, it should be noted that the same reference numerals are used to depict the same or similar elements, features, and structures. Detailed Implementation

[0036] The following description, provided with reference to the accompanying drawings, is intended to aid in a comprehensive understanding of the various embodiments of this disclosure as defined by the claims and their equivalents. It includes various specific details to aid understanding, but these details are to be considered exemplary only. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the various embodiments described herein without departing from the scope and spirit of this disclosure. Additionally, descriptions of well-known functions and constructions may be omitted for clarity and brevity.

[0037] The terms and words used in the following description and claims are not limited to their literal meaning, but are used only by the inventors to achieve a clear and consistent understanding of this disclosure. Therefore, it will be apparent to those skilled in the art that the following description of various embodiments of this disclosure is for illustrative purposes only and not for limiting the disclosure as defined by the appended claims and their equivalents.

[0038] It will be understood that the singular forms of “one,” “an,” and “the” include plural references unless the context explicitly indicates otherwise. Thus, for example, a reference to “component surface” includes a reference to one or more such surfaces.

[0039] In describing the embodiments in this specification, descriptions of technical content well known in the art to which this disclosure pertains and not directly related to this disclosure will be omitted in cases where it is determined that such technical content would obscure the subject matter of this disclosure with unnecessary detail.

[0040] For the same reason, some components are shown enlarged, omitted, or roughly in the accompanying drawings. Furthermore, the dimensions of some components may not fully reflect their actual dimensions. In the drawings, the same reference numerals are used for the same elements in various figures.

[0041] The aspects and features of this disclosure, as well as the methods for implementing those aspects and features, will become apparent from the embodiments described in detail with reference to the accompanying drawings. However, this disclosure is not limited to the embodiments disclosed below, but can be implemented in various forms. Matters defined in the specification, such as detailed constructions and elements, are provided only as specific details to assist those skilled in the art in fully understanding this disclosure, and this disclosure is defined only within the scope of the appended claims. Throughout this specification, the same reference numerals are used for the same elements in the various figures.

[0042] It will be understood that each box in a flowchart illustration, and combinations of boxes in a flowchart illustration, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more flowchart boxes. These computer program instructions can also be stored in computer-usable or computer-readable memory, which can instruct a computer or another programmable data processing apparatus to function in a particular manner, such that the instructions stored in computer-usable or computer-readable memory produce an article of writing including instruction means for implementing the functions specified in one or more flowchart boxes. The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowchart boxes.

[0043] Additionally, each box in the flowchart diagram may represent a module, segment, or section of code, which includes one or more executable instructions for implementing one or more specified logical functions. It should also be noted that in some alternative implementations, the functions indicated in the boxes may occur out of order. For example, depending on the functions involved, two boxes shown consecutively may actually execute substantially simultaneously, or sometimes in reverse order.

[0044] When used in embodiments, the term " "Unit" means, but is not limited to, software or hardware components that perform certain tasks, such as field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs). However, " "Unit" does not mean limited to software or hardware. The term "unit" A "cell" can be advantageously configured to reside on an addressable storage medium and configured to execute on one or more processors. Therefore, " "Units" can include, for example, components such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, code snippets, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. Components and " The functionality provided in the "unit" can be combined into fewer components and " "Unit", or further separated into additional components and " "Unit". In addition, components and " A “unit” can be implemented as one or more CPUs in an operating device or a secure multimedia card.

[0045] Figure 1 This is a diagram illustrating the structure of a Long Term Evolution (LTE) system according to an embodiment of the present disclosure.

[0046] refer to Figure 1 As shown, the radio access network of the LTE system consists of the following: Evolved Node Bs (hereinafter referred to as "ENB", "Node B" or "base station") 105, 110, 115 and 120, Mobility Management Entity (MME) 125 and Service Gateway (S-GW) 130. User Equipment (hereinafter referred to as "UE" or "terminal") 135 accesses the external network through ENBs 105, 110, 115 and 120 and S-GW 130.

[0047] exist Figure 1In this context, ENBs 105, 110, 115, and 120 correspond to existing Node Bs in the Universal Mobile Telecommunications System (UMTS). The ENB connects to UE 135 on the radio channel and plays a more complex role than existing Node Bs. In LTE systems, because all user services, including real-time services such as Voice over IP (VoIP) via the Internet Protocol, are served on shared channels, a device is necessary to perform scheduling by merging state information (such as buffer state, available transmission power state, and channel state for each UE), and ENBs 105, 110, 115, and 120 correspond to such scheduling devices. Typically, one ENB controls multiple cells. For example, to implement a transmission speed of 100 Mbps, the LTE system uses, for example, Orthogonal Frequency Division Multiplexing (OFDM) with a bandwidth of 20 MHz as the radio access technology. Furthermore, the LTE system employs an Adaptive Modulation and Coding (AMC) scheme, which determines the modulation scheme and channel coding rate to match the terminal's channel state. The S-GW130 is a device that provides data bearers and generates or removes data bearers under the control of the MME 125. The MME is a device that is responsible not only for terminal mobility management but also for various control functions, and it connects to multiple base stations.

[0048] Figure 2 This is a diagram illustrating the radio protocol structure in an LTE system according to an embodiment of the present disclosure.

[0049] refer to Figure 2 In the UE or ENB, the radio protocol of the LTE system consists of the following: Packet Data Convergence Protocol (PDCP) 205 or 240, Radio Link Control (RLC) 210 or 235, and Media Access Control (MAC) 215 or 230. PDCP 205 or 240 is responsible for IP header compression / decompression operations. The main functions of PDCP are summarized as follows:

[0050] -Header compression and decompression: ROHC only;

[0051] -Transmission of user data;

[0052] - Sequential delivery of upper-layer PDUs in the PDCP reconstruction process for RLC AM;

[0053] - For split bearers in DC (RLC AM only): PDCP PDU routing for transmission and PDCP PDU reordering for reception;

[0054] - Duplicate detection of lower-level service data units (SDUs) during the PDCP reconstruction process for RLC AM;

[0055] - For RLC AM, PDCP SDU retransmission during handover, and PDCP PDU retransmission during PDCP data recovery for split bearers in DC;

[0056] - Encryption and decryption; and

[0057] - Timer-based SDU dropping in the uplink.

[0058] The Radio Link Control (hereinafter referred to as "RLC") 210 or 235 reconfigures the PDCP Protocol Data Unit (PDU) to the appropriate size and performs ARQ operations. The main functions of the RLC are summarized below:

[0059] - Transmission of upper-layer PDUs;

[0060] - Error correction via ARQ (for AM data transmission only);

[0061] - Concatenation, segmentation, and reassembly of RLC SDUs (for UM and AM data transmission only);

[0062] - Resegmentation of RLC data PDUs (for AM data transmission only);

[0063] - Reordering of RLC data PDUs (only for UM and AM data transfer);

[0064] - Duplicate detection (only for UM and AM data transmission);

[0065] - Protocol error detection (only for AM data transmission);

[0066] -RLC SDU discard (only for UM and AM transmissions); and

[0067] -RLC reconstruction.

[0068] The MAC 215 or 230 connects to several RLC layer devices configured in a terminal and performs RLC PDU multiplexing to / demultiplexing from the MAC PDU. The main functions of the MAC are summarized below:

[0069] - Mapping between logical channels and transport channels;

[0070] - Multiplexing MAC SDUs belonging to one or different logical channels into a transport block (TB) delivered to the physical layer on the transport channel / demultiplexing MAC SDUs belonging to one or different logical channels from a transport block (TB) delivered by the physical layer on the transport channel.

[0071] - Scheduling information report;

[0072] - HARQ function (error correction via HARQ);

[0073] - Priority processing between logical channels of a UE;

[0074] - Priority processing between UEs via dynamic scheduling;

[0075] -MBMS service identifier;

[0076] -Transmission format selection; and

[0077] - Padding.

[0078] Physical layer 220 or 225 performs channel coding and modulation of upper-layer data to configure OFDM symbols and transmit them to a radio channel, or performs demodulation and channel decoding of OFDM symbols received on a radio channel to transmit demodulated and channel-decoded data to the upper layer.

[0079] Figure 3 This is a diagram illustrating the structure of a next-generation mobile communication system according to an embodiment of the present disclosure.

[0080] refer to Figure 3 As shown, the radio access network (hereinafter referred to as "NR" or "5G") of the next-generation mobile communication system consists of a new radio node B (hereinafter referred to as "NR gNB" or "NR ENB") 310 and a new radio core network (NR CN) 305. New radio user equipment (hereinafter referred to as "NR UE" or "terminal") 315 accesses external networks through NR gNB 310 and NR CN 305.

[0081] exist Figure 3In this context, the NR gNB 310 corresponds to the Evolved Node B (ENB) of the existing LTE system. The NR gNB connects to the NR UE 315 on the radio channel, and therefore can provide a superior service compared to the existing Node B. Since all user traffic is served on a shared channel in next-generation mobile communication systems, a device is necessary to perform scheduling by merging state information such as buffer state, available transmission power state, and channel state for each UE, and the NR gNB 310 is responsible for this. An NR gNB typically controls multiple cells. To implement ultra-high-speed data transmission compared to existing LTE, the NR gNB or cell may have the existing maximum bandwidth or greater, and Orthogonal Frequency Division Multiplexing (OFDM) can be considered to additionally transplant beamforming technology as a radio connection technology. Furthermore, an Adaptive Modulation and Coding (AMC) scheme is employed to determine the modulation scheme and channel coding rate to match the UE's channel state. The NR CN 305 performs mobility support, bearer configuration, and Quality of Service (QoS) configuration functions. The NR CN is a device responsible not only for terminal mobility management but also for various control functions and connects to multiple ENBs. Furthermore, the next-generation mobile communication system can also interlock with the existing LTE system, and the NR CN connects to the MME 325 via a network interface. The MME connects to the ENB 330, which serves as an existing base station.

[0082] Figure 4 This is a diagram illustrating the radio protocol structure of a next-generation mobile communication system according to an embodiment of the present disclosure.

[0083] refer to Figure 4 In the UE or NR ENB, the radio protocols of the next-generation mobile communication system consist of the following: the new Radio Service Data Adaptation Protocol (NR SDAP) 401 or 445, the new Radio Packet Data Convergence Protocol (NR PDCP) 405 or 440, the new Radio Link Control (NR RLC) 410 or 435, and the new Radio Media Access Control (NR MAC) 415 or 430.

[0084] The main functions of NR SDAP 401 or 445 may include parts of the following functions:

[0085] -Transmission of user plane data;

[0086] - Mapping between QoS streams and data radio bearers (DRBs) for both DL and UL;

[0087] - Mark the QoS flow ID in both DL and UL packets; and

[0088] - Mapping of reflected QoS flows to DRB for UL SDAP PDU.

[0089] Regarding SDAP layer devices, terminals can receive configuration information via RRC messages regarding whether PDCP layer devices, bearers, or logical channels use SDAP layer device headers or functions. If SDAP headers are configured, terminals can update or reconfigure the mapping information between QoS flows and uplink and downlink data bearers using the 1-bit Non-Access Stratum (NAS) QoS reflection configuration indicator (NAS reflected QoS) and the 1-bit Access Stratum (AS) QoS reflection configuration indicator (AS reflected QoS) in the SDAP header. The SDAP header may include QoS flow ID information indicating QoS. QoS information can be used for data processing priority and scheduling information to support smooth service.

[0090] The main functions of NR PDCP 405 or 440 may include some of the following functions:

[0091] -Header compression and decompression: ROHC only;

[0092] -Transmission of user data;

[0093] - Sequential delivery of upper-layer PDUs;

[0094] -Out-of-order delivery of upper-layer PDUs;

[0095] - Reordering of received PDCP PDUs;

[0096] - Duplicate detection of lower-level SDUs;

[0097] -Retransmission of PDCP SDU;

[0098] - Encryption and decryption; and

[0099] - Timer-based SDU dropping in the uplink.

[0100] As described above, reordering by an NR PDCP device can mean reordering PDCP PDUs received from the lower layer based on the PDCP sequence number (SN), and reordering by an NR PDCP device can include delivering data to the upper layer in the reordered order, or it can include direct data delivery regardless of order. Furthermore, reordering by an NR PDCP device can include: recording lost PDCP PDUs by reordering them, reporting the status of lost PDCP PDUs to the transmitting side, and requesting retransmission of the lost PDCP PDUs.

[0101] The main functions of NR RLC 410 or 435 may include some of the following functions:

[0102] - Transmission of upper-layer PDUs;

[0103] - Sequential delivery of upper-layer PDUs;

[0104] -Out-of-order delivery of upper-layer PDUs;

[0105] - Error correction via ARQ;

[0106] - Cascading, segmentation, and reassembly of RLC SDUs;

[0107] - Resegmentation of RLC data PDUs;

[0108] - Reordering of RLC data PDUs;

[0109] -Repeated detection;

[0110] - Protocol error detection;

[0111] -RLC SDU discarded; and

[0112] -RLC reconstruction.

[0113] As described above, sequential delivery by an NR RLC device can mean the sequential delivery of RLC SDUs received from a lower layer to an upper layer. When an original RLC SDU is segmented into several RLC SDUs to be received, sequential delivery by an NR RLC device can include the reassembly and delivery of RLC SDUs. Furthermore, sequential delivery by an NR RLC device can include: reordering received RLC PDUs based on the RLC SN or PDCP SN, and recording lost RLCP DUs by reordering them. Additionally, sequential delivery by an NR RLC device can include performing status reports to lost RLC PDUs on the transmitting side and requests for retransmission of lost PDCP PDUs. Furthermore, if lost RLC SDUs exist, sequential delivery by an NR RLC device can include sequentially delivering only the RLC SDUs preceding the lost RLC SDUs to the upper layer. Furthermore, the sequential delivery of RLC SDUs by the NR RLC device can include: despite the existence of lost RLC SDUs, if a timer expires, sequentially delivering all RLC SDUs received before a specific timer begins its operation to the upper layer; or, despite the existence of lost RLC SDUs, if a timer expires, sequentially delivering all RLC SDUs received up to the current time to the upper layer. Additionally, RLCPDUs can be processed in the order they were received (regardless of the SN order, but according to their arrival order), and then transmitted to the PDCP device in an out-of-order manner. In the case of fragmentation, segments stored in a buffer or to be received later are received and reconfigured into a complete RLC PDU to be processed and transmitted to the PDCP device. The NR RLC layer may not include concatenation functionality, which can be performed by the NR MAC layer or replaced by multiplexing functionality of the NR MAC layer.

[0114] As described above, the out-of-order delivery of NR RLC devices means that RLCSDUs received from lower layers are transmitted directly to upper layers regardless of the order in which they are received. If an original RLC SDU is segmented into several RLC SDUs to be received, out-of-order delivery may include the reassembly and transmission of RLC SDUs, as well as the recording of lost RLC PDUs by storing and sorting the RLC SN or PDCP SN of the received RLC PDUs.

[0115] The NR MAC 415 or 430 can connect to several NR RLC layer devices configured in a single terminal, and the main functions of the NR MAC can include some of the following:

[0116] - Mapping between logical channels and transport channels;

[0117] - MAC SDU multiplexing / demultiplexing;

[0118] - Scheduling information report;

[0119] - HARQ function (error correction via HARQ);

[0120] - Priority processing between logical channels of a UE;

[0121] - Priority processing among dynamically scheduled UEs;

[0122] -MBMS service identifier;

[0123] -Transmission format selection; and

[0124] -filling.

[0125] The new Radio Physical (NR PHY) layer 420 or 425 can perform channel coding and modulation of upper-layer data to generate and transmit OFDM symbols on a radio channel; or it can perform demodulation and channel decoding on OFDM symbols received on a radio channel to transmit the demodulated and channel-decoded data to the upper layer.

[0126] Figure 5 This is a diagram illustrating a mode in which a terminal can remain in a next-generation mobile communication system according to an embodiment of the present disclosure.

[0127] refer to Figure 5The terminal (UE) can remain in RRC connected mode 503, RRC inactive mode (or lightly connected mode) 502, and RRC idle mode 501, and can undergo handover processes to different modes 505, 510, 515, 520, and 525. Specifically, if data to be sent to the uplink is generated, if a paging message is received via the arrival of downlink data, or if the connection to the network is configured to update the tracking area (periodically or if the UE deviates from the tracking area), the terminal in RRC idle mode 501 can switch to RRC connected mode 503 (handover process 505 to different modes) to send and receive data. If no data is generated within a predetermined time after sending or receiving data, the terminal in RRC connected mode can switch to RRC idle mode via the network (handover process 515 to different modes). Furthermore, if no data is generated within the predetermined time, for the purpose of saving battery and supporting fast connection, the terminal in RRC connected mode 503 can switch to RRC inactive mode 502 via the network or itself (handover process 520 to a different mode). If data to be sent to the uplink is generated, if a paging message is received via the arrival of downlink data, or if the connection to the network is configured to update the tracking area (or RAN notification area) (periodically or if the UE deviates from the tracking area (or RAN notification area)), the terminal in RRC inactive mode 502 can switch to RRC connected mode 503 (handover process 510 to a different mode). The terminal in RRC inactive mode 502 can switch to RRC idle mode 501 via network indication, through pre-engaged configuration, or by itself (handover process 525 to a different mode). If there are many terminals in RRC inactive mode in the network, this may lead to increased network signaling overhead due to frequent updates of the RAN notification area, and therefore, handover from terminals in RRC inactive mode to RRC idle mode should be supported. When a terminal has a specific purpose, it can send data even in RRC inactive mode 502 without switching to RRC connected mode 503. It repeatedly switches between RRC inactive mode and RRC idle mode according to network instructions, and only switches to RRC connected mode when necessary. In this process, since the terminal in RRC inactive mode sends data, it has the following advantages: very short transmission latency and very low signaling overhead. When only a small amount of data is sent, a terminal with a specific purpose can correspond to a terminal that sends data intermittently or periodically over a very long period of time.In addition, a terminal in RRC idle mode 501 can be switched directly to RRC inactive mode 502 via the network, or can be switched to RRC connected mode, and then can be switched back to RRC inactive mode (switching to different modes is handled by processes 505 and 520).

[0128] To address the state mismatch between the terminal's mode during mode transitions and the terminal's mode as recognized by the network, an inactive timer can be additionally configured to be driven within the terminal. Furthermore, this inactive timer can be driven even within the ENB.

[0129] In this disclosure, RRC inactive mode and lightly connected mode can be interpreted as the same state mode, and it can be assumed that the terminal performs the same operations. Furthermore, RRC inactive mode and lightly connected mode can be interpreted as the same state mode, but it can be assumed that the terminal performs different operations in the corresponding modes. Conversely, RRC inactive mode and lightly connected mode can be interpreted as different state modes, and it can be assumed that the terminal performs different operations in the corresponding modes. Although RRC inactive mode and lightly connected mode share the same purpose regarding the ability to quickly reconnect with less signaling and to save battery, they can have the same or different modes depending on the implementation and definition of the terminal and network. Furthermore, terminal operation in RRC inactive mode and lightly connected mode can be the same as operation in RRC idle mode, and can have additional functions or only some of the functions of operation in RRC idle mode. As mentioned above, in RRC inactive mode, terminal battery can be saved; and when the terminal is connected to the network, fast connection can be configured with less signaling overhead. However, compared to the periodic update of the tracking area by terminals in RRC idle mode, terminals in RRC inactive mode should perform the process of updating the RAN notification area more frequently. Therefore, if there are many terminals in RRC inactive mode in the network, this can lead to signaling overhead due to the periodic update of the RAN notification area. Consequently, the network needs to manage terminals in RRC inactive mode and, if necessary, switch them to RRC idle mode.

[0130] Figure 6 This describes the process of a terminal switching from RRC connection mode to RRC idle mode and the process of a terminal switching from RRC idle mode to RRC connection mode according to embodiments of the present disclosure.

[0131] refer to Figure 6If a terminal (UE) that is sending and receiving data in RRC connection mode fails to send and receive data for a specific reason or at a predetermined time, in operation 601, the base station (ENB) may send an RRC connection release message to the UE to switch the UE to RRC idle mode. Afterwards, if data to be sent is generated, the UE that is not currently configured with a connection (hereinafter referred to as the "idle mode UE") performs RRC connection establishment processing with the ENB. In operation 605, the UE establishes backward transmission synchronization with the ENB through a random access process and sends an RRC connection request message to the ENB. This message contains the UE's identifier and the reason for connection establishment. In operation 610, the ENB sends an RRC connection setup message to the UE to enable the UE to set up the RRC connection. This message contains RRC connection setup information, etc. The RRC connection is also known as the signaling radio bearer (SRB) and is used to send and receive RRC messages as control messages between the UE and the ENB. In operation 615, the UE with RRC connection setup sends an RRC Connection Setup Complete message to the ENB. This message contains a control message Service Request (SERVICE REQUEST) for the UE to request bearer setup for a specific service from the MME. In operation 620, the ENB sends the Service Request (SERVICE REQUEST) message contained in the RRC Connection Setup Complete message to the MME, and the MME determines whether to provide the service requested by the UE. If, as a result of the determination, it is determined that the service requested by the UE will be provided, then in operation 625, the MME sends an Initial Context Setup Request (INITIAL CONTEXTSETUP REQUEST) message to the ENB. This message includes Quality of Service (QoS) information to be applied during Data Radio Bearer (DRB) setup, as well as security-related information (e.g., security keys and security algorithms) to be applied to the DRB. To set up security with the UE, in operations 630 and 635, the ENB exchanges a Security Mode Command (SecurityModeCommand) message and a Security Mode Complete (SecurityModeComplete) message with the UE. If the security settings are complete, then in operation 640, the ENB sends an RRC Connection Reconfiguration message to the UE.This message includes DRB setting information to be processed via its user data. In operation 645, the UE applies this information to set up the DRB and sends an RRC Connection Reconfiguration Complete message to the ENB. In operation 650, the ENB, having completed the DRB setup with the UE, sends an Initial Context Setup Complete message to the MME. In operations 655 and 660, the MME, having received the message, exchanges an S1 Bearer Setup message and an S1 Bearer Setup Response message with the S-GW to set up the S1 bearer. The S1 bearer is the connection used to transmit data sets between the S-GW and the ENB and corresponds to the DRB in a one-to-one manner. If the above processing is complete, in operations 665 and 670, the UE sends and receives data with the ENB via the S-GW. As described above, the general data transmission process consists of three stages: RRC connection setup, security setup, and DRB setup. In addition, during operation 675, the ENB can send an RRC Connection Reconfiguration message to the UE to update, add, or change settings for specific reasons.

[0132] As mentioned above, a number of signaling procedures are required to perform the switch from RRC idle mode to RRC connected mode. Therefore, in next-generation mobile communication systems, a new RRC inactive mode or lightly connected mode can be defined, and in this new mode, the UE and ENB store the UE context. If necessary, the S1 bearer can be maintained, and thus, faster connections can be established with a smaller number of signaling procedures.

[0133] Figure 7 This is a diagram illustrating the process of a terminal switching from RRC connection mode to RRC inactive mode (or light connection mode) and the process of a terminal switching from RRC inactive mode (or light connection mode) to RRC connection mode according to embodiments of the present disclosure.

[0134] refer to Figure 7This illustrates the overall flow between the terminal (UE) 7001, anchor eNB 7002, new eNB 7003, and MME 7004 for reusing UE context and S1 bearers between the UE and eNB. The UE 7001, in an RRC connection state, sends and receives data with the eNB. If data transmission and reception are interrupted, the eNB operates a specific timer, and if data transmission and reception are not resumed before the timer expires, in operation 7005, the eNB may consider releasing the UE's RRC connection, and the eNB may determine whether to switch the UE to RRC idle mode or RRC inactive mode based on specific conditions. These specific conditions may include the level of network traffic, the amount of UE context the network can maintain, and the number of UEs for which the network can support its services. In Operation 7010, to switch the UE to an RRC inactive or lightly connected state, the eNB can send an RRC connection release (RRCConnectionRelease) or RRC connection suspension (RRCConnectionSuspend) message, a newly defined RRC message, or another existing reused RRC message. In Operation 7010, the eNB can store the UE context after releasing the UE's RRC connection according to specific rules. It can allocate a recovery ID while sending a control message to the UE indicating the release of the RRC connection, and can configure a paging area (PA) where the UE reports mobility during lightly connected mode. In this case, in Operation 7010, through the recovery ID allocation, the UE knows it should store the UE context, or the eNB can include a separate context maintenance indication to indicate that the UE is operating in RRC inactive / lightly connected mode and that the UE context should be stored in the aforementioned message. Furthermore, this message can include security information for updating security settings necessary when the UE performs the RRC connection recovery procedure. For example, NextHopChainingCount (NCC) can be pre-assigned, and it can be used to calculate and configure a new security key KeNB* or KgNB*. In addition, control messages may include a cell list. During the period the eNB maintains the context, or when the UE intends to reconfigure the RRC connection during the effective period, the procedure using the stored context can be applied to this cell list. After releasing the UE's RRC connection, in operation 7015, the eNB maintains the UE's UE context and S1 bearers as is. S1 bearer calls: S1 control bearers are used to send and receive control messages between the eNB and the MME; and S1 user plane bearers are used to send and receive user data between the eNB and the S-GW. By maintaining the S1 bearers, the procedure for setting up the S1 bearers can be omitted when the UE intends to set up an RRC connection in the same cell or the same eNB.If the validity period expires, the eNB can delete the UE context and release the S1 bearer. UEs that have received the RRC Connection Release message in Operation 7010 switch to RRC inactive mode / lightly connected mode.

[0135] As mentioned above, an anchor eNB refers to an eNB that manages the RAN paging area (or RAN notification area) to manage the mobility of UEs in RRC inactive mode. As also mentioned above, the role of the anchor eNB can be performed alternatively by an Access and Mobility Management Function (AMF) device.

[0136] In operation 7020, the eNB sends a control message to the MME requesting a temporary suspension of the connection from the MME. If downlink data for the UE has been generated, in operation 7035, the MME, having received the control message, can instruct the S-GW to directly transmit the downlink data to the anchor eNB, and can also instruct the anchor eNB to generate a paging message and transmit it to the adjacent eNB. That is, the anchor eNB, having received the downlink data, stores the data in a buffer and continues the paging process. The anchor eNB invokes the eNB that maintains the UE's UE context and the S1-U bearer. If the UE does not respond to the paging message sent by the anchor eNB, i.e., paging fails, in operation 7035, the anchor eNB can request the paging process from the MME, and can request the MME to begin the paging process without transmitting the downlink data for the UE generated by the S-GW to the eNB, and the S-GW can operate accordingly.

[0137] A UE that has already received an RRC connection release message (RRCConnectionRelease) including information indicating context maintenance and recovery ID in operation 7010 can release the RRC connection. However, in operation 7025, it can operate a timer corresponding to the effective period, record a list of effective cells in memory, maintain the current UE context in memory without deleting it, and transition to a lightly connected mode. The UE context, as described above, means various information related to the UE's RRC settings, including SRB setting information, DRB setting information, and security key information. Subsequently, for some reason, in operation 7030, the necessity to set up the RRC connection occurs. UEs that were not assigned a recovery ID or had not indicated context maintenance in the previous RRC connection release process can begin the general RRC connection setup process (see [link]). Figure 6 (See above for reference) Figure 6As described, a UE in RRC inactive / lightly connected mode that was assigned a recovery ID in the previous RRC connection release process can use the stored UE context to attempt RRC connection recovery processing. As described above, a UE in RRC inactive / lightly connected mode can perform general RRC connection setup processing (see...). Figure 6 Furthermore, the stored UE context can be used to perform RRC connection recovery processing, depending on whether the network's RRC inactive mode / lightly connected mode is supported. That is, if RRC inactive mode / lightly connected mode is not supported, the UE can perform general RRC connection setup processing (see [link to relevant documentation]). Figure 6 If RRC inactive mode / lightly connected mode is supported, the UE can perform the RRC connection restoration procedure as follows. As mentioned above, the network can always support RRC inactive mode (therefore, system information may not separately indicate whether RRC inactive mode / lightly connected mode is supported). In this disclosure, each eNB or each cell can include an indication in the system information to be sent indicating whether the eNB or cell supports lightly connected mode. This indication can be included in the second block of system information 2, and can be included in blocks of other system information 1-19. As mentioned above, supporting lightly connected mode may mean that the corresponding eNB or cell can be configured and support the operations 7050, 7055, 7060, 7065, 7070, 7075, 7080, 7085 and 7090 described below. If there is a need to configure RRC connection, the UE in lightly connected mode reads the system information of the cell currently in camp. If the system information received by the UE in operation 7040 does not include an indication that the eNB or cell supports light connectivity (or RRC inactive mode), then in operation 7045, the UE can perform normal RRC connection setup procedures (see [link]). Figure 6 (See above for reference) Figure 6 As described. However, if the system information received by the UE in operation 7040 includes an indication that the eNB or cell supports light connectivity (or RRC inactive mode), then in operation 7045, the UE can use the stored UE context to perform RRC connection recovery processing. The RRC connection recovery processing using the stored UE context is described below.

[0138] First, the UE sends a preamble on message 1 to perform a random access procedure. If resource allocation is possible based on the preamble received on message 1, the eNB allocates the corresponding uplink resources to the UE on message 2. In operation 7050, the UE sends a recovery request message, including the recovery ID received in operation 7010, based on the received uplink resource information. This message can be a modified RRC Connection Request message or a newly defined message (e.g., an RRC Connection Resume Request message). If a UE in lightly connected mode moves to a cell in another eNB after the connection is released by the anchor eNB, the new eNB 7003 can know which eNB the corresponding UE previously received services from by receiving and identifying the UE's recovery ID. If the new eNB 7003 has successfully received and identified the recovery ID, a context retrieval procedure is performed in operations 7055 and 7060 to retrieve the UE context from the anchor eNB. If the UE context retrieval process fails for a specific reason, such as if the anchor / source eNB cannot be found or if the UE context does not exist, the eNB can send an RRC Connection Setup message, such as... Figure 6 As shown, this replaces the RRC ConnectionResume message and falls back to the state described in the reference above. Figure 6 The described RRC connection setup procedure serves as the subsequent bearer setup / security setup procedure. Furthermore, the eNB can complete security setup, send the UE to RRC connection mode, or return the UE to RRC inactive mode when sending an RRC ConnectionSuspend message along with a new UE identifier (Recovery ID) and the RAN paging area. The new eNB 7003 can bring the UE context from the anchor eNB 7002 via the S1 or X2 interface. If the new eNB has received the Recovery ID but has not yet successfully distinguished the UE for certain reasons, it can send an RRC ConnectionSetup message to the UE to fall back to the above reference. Figure 6The general RRC connection setup process is described above. Specifically, the eNB can send an RRC Connection Setup message to the UE, and the UE, having received this message, can send an RRC Connection Setup Complete message to the eNB to perform the connection setup. Furthermore, if a new eNB has received a recovery ID but has not yet successfully distinguished the UE (e.g., failure to retrieve the UE context from the anchor eNB), it can send an RRC Connection Release message or an RRC Connection Reject message to the UE to reject the UE's connection and can then retry to begin the process as described above. Figure 6The general RRC connection setup process is described below. In operation 7065, the new eNB identifies the MAC-I based on the retrieved UE context. The MAC-I is a message authentication code calculated by the UE using security information from the restored UE context (i.e., by applying a security key and a security counter) and the control message. The eNB uses the message's MAC-I, along with the security key and security counter stored in the UE context, to verify message integrity. Furthermore, in operation 7070, the new eNB determines the RRC connection settings to be applied to the UE and sends an RRC Connection Resume message containing the setup information to the UE. The eNB can identify the UE's recovery ID and can use the new security key KeNB* or KgNB* to encrypt the RRC Connection Resume message to send encrypted RRC Connection Resume messages. The UE can normally receive the RRC Connection Resume message by decrypting it using the new security key KeNB* or KgNB* pre-allocated by the NCC in Operation 7010. After the process of sending the RRC Connection Resume message, RRC messages and data can be encrypted with the new security key and can be sent and received by both the UE and the eNB. The RRC Connection Resume message can be a control message obtained by including information indicating "RRC context reuse" (reuse indicator) in the general RRC connection request message. The RRC Connection Resume message contains various information related to the UE's RRC connection settings in the same way as the RRC Connection Setup message. If the UE receives a general RRC Connection Setup message, it sets up the RRC connection based on the settings information indicated in the RRC Connection Setup message. However, if the UE receives an RRC Connection Resume message, it sets up the RRC connection (incremental (delta) configuration) by considering both the stored settings information and the settings information indicated in the control message. For example, the UE can determine the settings to apply by identifying the indicated settings information as incremental information for the stored settings, and can update the settings information or the UE context.For example, if the RRC Connection Resume message includes SRB setting information, the UE configures the SRB by applying the indicated SRB setting information; if the RRC Connection Resume message does not include SRB setting information, the UE configures the SRB by applying the SRB setting information stored in the UE context.

[0139] In operation 7075, the UE configures the RRC connection using the updated UE context and settings information, and sends an RRC Connection Resume Complete message to the eNB. Furthermore, in operations 7080 and 7085, the eNB sends a control message to the MME requesting the release of the temporary connection suspension and requests the MME to reconfigure the S1 bearer for the new eNB. If the above message is received, the MME requests the S-GW to reconfigure the S1 bearer for the new eNB and instructs the UE to process data normally. If the above processing is completed, in operation 7090, the UE resumes data transmission and reception in the aforementioned cell.

[0140] In the above process, if the anchor eNB releases the connection and the UE in light connection mode does not move significantly and is re-entering the cell of anchor eNB 7002, the new eNB 7003 can simply perform the connection temporary suspension release carried by S1 instead of the procedures 7080 and 7085, and not perform the procedures 7055 and 7060. The UE's UE context is searched by referring to the recovery ID indicated in message 3, and based on this, the connection is reconfigured in a manner similar to the above process.

[0141] If data transmission and reception are interrupted, the eNB operates a specific timer, and if data transmission and reception are not resumed before the timer expires, the eNB considers releasing the UE's RRC connection in operation 7095. In operation 7100, to switch the UE to an RRC inactive or lightly connected state, the eNB can reuse and send an RRC connection release or RRC connection suspension message, a newly defined RRC message, or another existing RRC message. In operation 7100, the eNB can store the UE context after releasing the UE's RRC connection according to specific rules, can assign a recovery ID when sending a control message instructing the UE to release the RRC connection, and in operation 7100, can configure the RAN paging area or RAN notification area where the UE reports mobility during RRC inactive mode (lightly connected mode). If, in operation 7105, the UE in RRC inactive mode (or lightly connected mode) deviates from the configured RAN paging area, it performs a RAN paging area update procedure.

[0142] In next-generation mobile communication systems, the eNB can be configured for UEs in RRC inactive mode, and can configure RAN paging areas or RAN notification areas so that the UE can report terminal identifiers (recovery IDs) and terminal mobility that can be used when attempting RRC connections later. Furthermore, the eNB can configure NCC values ​​for security settings to be used in subsequent connection setup processing.

[0143] In next-generation mobile communication systems, if an RRC-inactive eNB deviates from the Tracking Area (TA) or TA list configured in the network / MME / core network (CN), it performs a Tracking Area Update (TAU); and if it deviates from the RAN Paging Area or RAN Notification Area configured by the AMF or anchor eNB, it performs a RAN Paging Area Update. When a UE in RRC-inactive mode performs a RAN Paging Area Update, the network can send various messages in response, depending on the network's situation.

[0144] Next, based on the present disclosure, and based on the above process, further specific embodiments of the process for resolving the problem of state inconsistency and unnecessary retransmission between the protocol layers of the terminal and the base station are proposed, taking into account security, specifically proposing connection release and connection setup procedures, and specifically proposing the operations to be performed by the corresponding protocol layers during the connection release and connection setup procedures.

[0145] Next, according to this disclosure, the RRC connection release message described above can be used as an RRC release message, and the RRC connection resume request message can be used as an RRC resume request message. Furthermore, the RRC connection resume message can be used as an RRC resume message, and the RRC connection resume complete message can be used as an RRC resume complete message.

[0146] Figure 8 This is a diagram illustrating a first embodiment of the corresponding protocol layer device operation and security setting process when a terminal in RRC inactive mode receives a paging message or restores connection to the network due to the presence of data to be sent to the uplink, according to an embodiment of the present disclosure.

[0147] refer to Figure 8 In operation 805, base station (gNB) 802 can switch a terminal (UE) 801 in RRC connected mode to RRC inactive mode by sending an RRC message for a specific reason. Here, the specific reason may correspond to scheduling to efficiently utilize network transmission resources, and may correspond to situations where downlink or uplink data to the UE does not occur or is not expected to occur for some time. As described above, the RRC message can be an RRC release (RRCRelease) message with rrc-suspend (rrc suspended) indicating a switch to RRC inactive mode, an RRC suspension (RRCSuspend) message indicating a switch to RRC inactive mode, or an RRC suspension (RRCSuspend) message with an indication of a switch to RRC inactive mode.

[0148] As described above, if an RRC message is received in operation 805, the UE may perform one or more of the following operations (in operation 810, the UE receives an RRC suspension (RRCSuspend) or an RRC release (RRCRelease) with rrc-suspend).

[0149] 1. The system can store the resumeIdentity received from RRC messages, the NCC for determining the security key, and RAN NotificationAreaInfo for mobility support of the UE in RRC inactive mode. As described above, the network can include the NCC value in the RRC message to be sent to the UE, thus enhancing security when the UE subsequently performs a connection restoration process. That is, integrity protection or encryption can be initiated earlier by pre-generating a new security key. The RAN NotificationAreaInfo may include a cell list, RAN NotificationArea ID, or a timer value. If the UE leaves the area corresponding to the cell list or RAN NotificationArea ID, a RAN NotificationArea Update process can be performed. The timer can be operated in the RRC inactive state corresponding to the timer value, and a RAN Notification and Update process can be performed whenever the timer expires (to store the resumeIdentity, NCC, and RAN NotificationAreaInfo provided by the network).

[0150] 2. The MAC layer device is reset, i.e., initialized. If the MAC layer device is not initialized, data sent in RRC connection mode and existing in the buffer may be unnecessarily retransmitted later. That is, when the connection is restored, inconsistencies may occur between the Hybrid Automatic Repeat Request (HARQ) processing information and the HARQ processing information, and therefore, initialization can prevent MAC layer device problems (MAC reset) that may occur when the connection is restored.

[0151] 3. The initialized MAC layer device can suspend the process of updating the token value (Bj) for the Logical Channel Prioritization (LCP) procedure at predetermined time units. If the token value is continuously updated in RRC inactive mode, the token value for each logical channel will reach its maximum value, and therefore, the LCP procedure may not operate correctly when the connection is restored. That is, the priority among logical channels may not be applied properly (Bj accumulation during the LCP suspension process).

[0152] 4. In the RLC layer device corresponding to each bearer of the UE, unprocessed data (RLC SDU or RLCPDU) may be retained in the buffer. Therefore, data retransmission may be unnecessarily performed during the connection restoration process. Furthermore, the UE's RLC state variables may be out of sync with the gNB's RLC state variables. That is, the transmitted RLC window may not be properly synchronized with the received RLC window. Therefore, the UE rebuilds the RLC layer device for all SRBs and DRBs (rebuilds the RLC entity for all SRBs and DRBs).

[0153] 5. In the PDCP layer device corresponding to each bearer of the UE, unprocessed data (PDCP SDU or PDCP PDU) can be retained in the buffer. Therefore, data retransmission may be unnecessarily performed during the connection restoration process. Furthermore, the UE's PDCP state variables may be out of sync with the gNB's PDCP state variables. That is, the transmitted PDCP window may not be properly synchronized with the received PDCP window. Therefore, the UE discards all data related to the PDCP layer devices for all SRBs and DRBs and initializes the state variables (discarding all PDCP SDUs and PDUs for all SRBs and DRBs, and initializing the state variables for all SRBs and DRBs). It should be noted that the PDCP layer device reconstruction process does not include the data discarding process and state variable initialization process for DRBs as described above (variable initialization for Unacknowledged Mode (UM) DRBs is possible), but mainly includes processes for retransmission, security key updates, and updates to encryption and integrity protection algorithms. Therefore, it is possible to discard data and initialize state variables instead of rebuilding the PDCP layer device.

[0154] 6. If an SDAP layer device is configured, the UE can suspend the SDAP layer device because no operation of the SDAP layer device is required in RRC inactive mode. That is, in RRC inactive mode, there is no need for the mapping process between IP flows and bearers (if any exists, the SDAP entity is suspended for all DRBs).

[0155] 7. In addition to receiving an RRC Suspension message in response to an RRC Suspension Request message sent by the UE, a specific procedure may be performed. This specific procedure may be the process by which the UE stores the UE context (i.e., RRC configuration information, security configuration information, PDCP status information (e.g., Robust Header Compression (ROHC)), Cell Radio Network Temporary Identifier (C-RNTI), Cell Identifier, and Physical Cell Identifier (PCI)).

[0156] 8. The UE suspends all remaining SRBs and DRBs except SRB0. Later, if the UE receives a paging message, uplink data occurs in the UE, or the UE should perform a RAN notification area update procedure, the UE will not suspend SRB0 so that the connection recovery procedure can be started immediately through SRB0 (suspending all SRBs and DRBs except SRB0).

[0157] 9. The UE can operate a timer to periodically perform RAN notification area updates based on the timer value received from the RRC message (starting the timer with the timer value set to periodic-RNAU-timer).

[0158] 10. Configure the lower layer (e.g., PDCP) of the UE to suspend the integrity protection and encryption process (configure the lower layer to suspend integrity protection and encryption).

[0159] 11. The UE switches to RRC inactive mode (enters RRC inactive mode).

[0160] As described above, a UE that has transitioned to RRC inactive mode can perform an RRC connection restoration procedure with the network for specific reasons. These specific reasons could correspond to situations in operation 815, such as the UE receiving a paging message or uplink data transmission occurring within the UE. For these reasons, in operation 820, the UE can perform one or more of the following actions before, during, or after sending an RRC recovery request message to restore its connection with the network (actions related to sending the RRC recovery request message in operation 825).

[0161] 1. The UE configures the stored I-RNTI value as the resumeIdentity. The resumeIdentity is included in the RRC recovery request message to be sent to initiate the connection recovery process and enable the gNB to distinguish the UE. The RRC message may include the resumeIdentity and the connection recovery reason. The connection recovery reason may indicate uplink data transmission, paging message reception (control signal reception), tracking area update, RAN notification area update (timer expired), or RAN notification area update (deviation from the indicated area) (setting the resumeIdentity to the stored I-RNTI provided in the hangup).

[0162] 2. In Operation 805, the UE receives an RRC message and updates the security key based on the stored NCC value. That is, if the NCC value has not changed, the UE uses information about the previously used security key KgNB and the PCI and Absolute Radio Channel Number (ARFCN) read from the system information to guide the new security key; while if the NCC value has changed, the UE uses information about another security key NG and the PCI and ARFCN read from the system information to guide the new security key (using the stored NCC value, updating the KgNB key based on the current KgNB or NH).

[0163] 3. Using the updated security key, during operation 820, the UE can generate a Message Authentication Code for Integrity (MAC-I), enabling it to perform integrity protection when sending an RRC message (RRC Recovery Request Message), and can send the generated MAC-I along with the RRC message to the gNB.

[0164] 4. The UE restores the stored RRC configuration information and security configuration information from the UE context (restores the RRC configuration and security context from the stored UE AS context).

[0165] 5. If the UE has not yet thrown away the data of the PDCP layer device or initialized the state variables of the PDCP layer device when receiving the RRC message in Operation 805, then the UE discards the data (PDCP PDU or SDU) of the PDCP layer device for SRB1 and initializes the state variables. As mentioned above, discarding data can prevent unnecessary retransmissions that may occur during subsequent PDCP reconstruction, and initializing the state variables can synchronize the gNB and the state variables with each other (discarding all PDCP SDUs and PDUs for the PDCP entity of SRB1 and initializing the state variables for the PDCP entity of SRB1). Specifically, the state variables initialized as described above can be TX_NEXT, RX_NEXT, RX_DELIV, or RX_REORD values.

[0166] 6. The UE can rebuild the PDCP layer device for SRB1 to update the encryption algorithm and integrity verification algorithm with the updated security key. Furthermore, the UE can restore the PDCP state. Additionally, because the security key has been updated, the UE can initialize the COUNT value. It should be noted that the PDCP layer device reconstruction process does not include the data discarding process and state variable initialization process for DRB as described above (initialization of UM DRB variables is possible), but mainly includes the processes for retransmission, security key updates, and updates to the encryption algorithm and integrity protection algorithm (restoring the PDCP state, resetting the COUNT value, and rebuilding the PDCP entity for SRB1).

[0167] 7. UE restores SRB1. The reason why the UE restores SRB1 when sending RRC messages is: to send an RRC recovery request message to SRB0 without performing encryption and integrity verification, to receive the RRC recovery message normally through SRB1, and to perform decryption and integrity verification (restore SRB1).

[0168] 8. The UE can restore the integrity protection and encryption process based on the algorithm previously configured in the lower layer equipment (e.g., PDCP layer equipment) for all bearers except SRB0 (configure the lower layer to restore the integrity protection and encryption for all radio bearers except SRB0 using the previously configured algorithm and the updated key).

[0169] As described above, in operation 820, the UE can send an RRC recovery request message, and in response, in operation 830, the gNB can send an RRC recovery message or an RRC release message along with an rrc-suspend instruction to the UE. In this disclosure, to enhance security when the gNB sends an RRC message in operation 830, the gNB can generate and update a security key based on the NCC transmitted to the UE in the RRC message in operation 805, and can perform encryption and integrity protection procedures regarding the RRC message to be sent in operation 830.

[0170] If an RRC recovery message is received from the gNB during operation 830, the UE may perform one or more of the following operations (in operation 835, the UE receives an RRC recovery message (RRCResume)).

[0171] 1. The UE stops the timer used to update the RAN notification area operating in RRC inactive mode (stops the timer used for RNA updates).

[0172] 2. If an RRC message is received, the UE will restart the update of the token value (Bj) for each logical channel of the LCP procedure at predetermined time intervals (to restore the Bj accumulation in the LCP procedure).

[0173] 3. If an SDAP layer device is configured, the UE will restore the SDAP layer device for all bearers (restore the SDAP entity for all DRBs).

[0174] 4. In operation 810 or operation 825, if the UE has not yet discarded the data of the PDCP layer device or initialized the state variables of the PDCP layer device when the RRC message is received in operation 805, then the UE discards the data (PDCP PDU or SDU) of the PDCP layer device for all carried PDCP layer devices and initializes the state variables. As described above, discarding data can prevent unnecessary retransmissions that may occur during subsequent PDCP reconstruction, and initializing the state variables can synchronize the gNB and the state variables with each other (discarding all PDCP SDUs and PDUs for all SRBs and DRBs of PDCP entities and initializing the state variables for all SRBs and DRBs of PDCP entities). Specifically, the state variables initialized as described above can be TX_NEXT, RX_NEXT, RX_DELIV, or RX_REORD values.

[0175] 5. The UE can rebuild the PDCP layer device for SRB2 and all DRBs to update the encryption and integrity verification algorithms with the updated security key. Furthermore, the UE can restore the PDCP state. Additionally, because the security key has been updated, the UE can initialize the COUNT value. It should be noted that the PDCP layer device reconstruction process does not include the data discarding process and status variable initialization process for DRBs as described above (initialization of UM DRB variables is possible), but mainly includes processes for retransmission, security key updates, and updates to encryption and integrity protection algorithms (restoring the PDCP state, resetting the COUNT value, and rebuilding the PDCP entity for SRB2 and all DRBs). If a PDCP status report needs to be sent to the gNB when the statusReportRequired indication is configured in the PDCP layer device and the PDCP reconstruction process is executed, the UE may not perform this process. This is because there is currently no data in the PDCP layer device, and therefore, there is nothing to report. If the statusReportRequired indicator is configured, the PDCP layer device should configure the PDCP status report originally and send it to the gNB during rebuild; however, this indicator can be used when performing RRC connection setup. Figure 6 Operations 610, 640, or 675 or in Figure 7 Operation 7070 is configured in the PDCP configuration information (PDCP-config) of the message.

[0176] 6. Because the UE is ready to enter RRC connection mode, it can discard the stored UE context and UE recovery identifier (I-RNTI). The UE identifier can be referred to as resumeIdentity or I-RNTI (discarding the stored UE AS context and I-RNTI).

[0177] 7. Restore SRB2 and all DRBs in the UE (Restore SRB2 and all DRBs).

[0178] 8. The UE switches to RRC connection mode (enters RRC connection).

[0179] As described above, if an RRC message is received in operation 830, the UE switches to RRC connection mode, and in operation 840 sends an RRC recovery completion message to the gNB indicating that the RRC connection setup is complete in order to resume data transmission and reception with the gNB.

[0180] Figure 9 This is a diagram illustrating a second embodiment of the protocol layer device operation and security setting process according to an embodiment of the present disclosure, when a timer for periodic RAN notification area updates of a terminal in RRC inactive mode expires, when a terminal in RRC inactive mode deviates from the RAN notification area, or when a terminal in RRC inactive mode restores its connection to the network for RAN notification area updates.

[0181] refer to Figure 9 In operation 905, base station (gNB) 902 can switch a terminal (UE) 901 in RRC connected mode to RRC inactive mode by sending an RRC message for a specific reason. Here, the specific reason may correspond to scheduling to efficiently utilize network transmission resources, and may correspond to situations where downlink or uplink data to the UE does not occur or is not expected to occur for some time. As described above, the RRC message can be an RRC release (RRCRelease) message with rrc-suspend indicating a switch to RRC inactive mode, an RRC suspension (RRCSuspend) message indicating a switch to RRC inactive mode, or an RRC suspension (RRCSuspend) message with an indication of a switch to RRC inactive mode.

[0182] As described above, if an RRC message is received in operation 905, the UE may perform one or more of the following operations (in operation 910, the UE receives an RRC suspension (RRCSuspend) or an RRC release (RRCRelease) with rrc-suspend).

[0183] 1. The system can store the resumeIdentity received from RRC messages, the NCC for determining the security key, and RAN NotificationAreaInfo for mobility support of the UE in RRC inactive mode. As described above, the network can include the NCC value in the RRC message to be sent to the UE, thus enhancing security when the UE subsequently performs a connection restoration process. That is, integrity protection or encryption can be initiated earlier by pre-generating a new security key. The RAN NotificationAreaInfo may include a cell list, RAN NotificationArea ID, or a timer value. If the UE leaves the area corresponding to the cell list or RAN NotificationArea ID, a RAN NotificationArea Update process can be performed. The timer can be operated in the RRC inactive state corresponding to the timer value, and a RAN Notification and Update process can be performed whenever the timer expires (to store the resumeIdentity, NCC, and RAN NotificationAreaInfo provided by the network).

[0184] 2. The MAC layer device is reset, i.e., initialized. If the MAC layer device is not initialized, data sent in RRC connection mode and existing in the buffer may be unnecessarily retransmitted later. That is, when the connection is restored, inconsistencies may occur between HARQ processing information and the actual HARQ processing information. Therefore, initialization can prevent MAC layer device problems (MAC reset) that may occur when the connection is restored.

[0185] 3. The initialized MAC layer device can suspend the process of updating the token value (Bj) for the LCP procedure at predetermined time units. If the token value is continuously updated in RRC inactive mode, the token value of each logical channel will reach its maximum value, and therefore, the LCP procedure may not operate correctly when the connection is restored. That is, the priority between logical channels may not be applied properly (Bj accumulation during the suspension of the LCP procedure).

[0186] 4. In the RLC layer device corresponding to each bearer of the UE, unprocessed data (RLC SDU or RLCPDU) may be retained in the buffer. Therefore, data retransmission may be unnecessarily performed during the connection restoration process. Furthermore, the UE's RLC state variables may be out of sync with the gNB's RLC state variables. That is, the transmitted RLC window may not be properly synchronized with the received RLC window. Therefore, the UE rebuilds the RLC layer device for all SRBs and DRBs (rebuilds the RLC entity for all SRBs and DRBs).

[0187] 5. In the PDCP layer device corresponding to each bearer of the UE, unprocessed data (PDCP SDU or PDCP PDU) can be retained in the buffer. Therefore, data retransmission may be unnecessarily performed during the connection restoration process. Furthermore, the UE's PDCP state variables may be out of sync with the gNB's PDCP state variables. That is, the transmitted PDCP window may not be properly synchronized with the received PDCP window. Therefore, the UE discards all data related to the PDCP layer devices for all SRBs and DRBs and initializes the state variables (discarding all PDCP SDUs and PDUs for all SRBs and DRBs, and initializing the state variables for all SRBs and DRBs). It should be noted that the PDCP layer device reconstruction process does not include the data discarding process and state variable initialization process for DRBs as described above, but mainly includes processes for retransmission, security key updates, and updates to encryption and integrity protection algorithms. Therefore, it is possible to discard data and initialize state variables instead of rebuilding the PDCP layer device.

[0188] 6. If an SDAP layer device is configured, the UE can suspend the SDAP layer device because no operation of the SDAP layer device is required in RRC inactive mode. That is, in RRC inactive mode, there is no need for the mapping process between IP flows and bearers (if any exists, the SDAP entity is suspended for all DRBs).

[0189] 7. In addition to receiving an RRC Suspension (RRCSuspend) message in response to an RRC Suspension Request (RRCResumeRequest) message sent by the UE, a specific procedure can be performed. This specific procedure may be the process by which the UE stores the UE context (i.e., RRC configuration information, security configuration information, PDCP status information (e.g., ROHC), C-RNTI, cellIdentity, and PCI).

[0190] 8. The UE suspends all remaining SRBs and DRBs except SRB0. Later, if the UE receives a paging message, uplink data occurs in the UE, or the UE should perform a RAN notification area update procedure, the UE will not suspend SRB0 so that the connection recovery procedure can be started immediately through SRB0 (suspending all SRBs and DRBs except SRB0).

[0191] 9. The UE can operate a timer to periodically perform RAN notification area updates based on the timer value received from the RRC message (starting the timer with the timer value set to periodic-RNAU-timer).

[0192] 10. Configure the lower layer (e.g., PDCP) of the UE to suspend the integrity protection and encryption process (configure the lower layer to suspend integrity protection and encryption).

[0193] 11. The UE switches to RRC inactive mode (enters RRC inactive mode).

[0194] As described above, a UE transitioning to RRC inactive mode can perform an RRC connection restoration procedure with the network for specific reasons. These specific reasons could include the expiration of a timer applied to periodic RAN notification area updates or the UE deviating from the RAN notification area while in RRC inactive mode. For these reasons, in operation 915, the UE can perform one or more of the following actions before, during, or after sending the RRC restoration request message to restore connection with the network (in operation 920, actions related to sending the RRC restoration request message).

[0195] 1. The UE configures the stored I-RNTI value as the resumeIdentity. The resumeIdentity is included in the RRC recovery request message to be sent to initiate the connection recovery process and enable the gNB to distinguish the UE. The RRC message may include the resumeIdentity and the connection recovery reason. The connection recovery reason may indicate uplink data transmission, paging message reception (control signal reception), tracking area update, RAN notification area update (timer expired), or RAN notification area update (deviation from the indicated area) (setting the resumeIdentity to the stored I-RNTI provided in the hangup).

[0196] 2. In Operation 905, the UE receives an RRC message and updates the security key based on the stored NCC value. That is, if the NCC value has not changed, the UE uses information about the previously used security key KgNB and the PCI and ARFCN read from the system information to guide the new security key; while if the NCC value has changed, the UE uses information about another security key NG and the PCI and ARFCN read from the system information to guide the new security key (using the stored NCC value, updating the KgNB key based on the current KgNB or NH).

[0197] 3. Using the updated security key, in Operation 920, the UE can generate a MAC-I that enables it to perform integrity protection when sending an RRC message (RRC Recovery Request Message), and can send the generated MAC-I along with the RRC message to the gNB.

[0198] 4. The UE restores the stored RRC configuration information and security configuration information from the UE context (restores the RRC configuration and security context from the stored UE AS context).

[0199] 5. If the UE has not yet thrown away the data of the PDCP layer device or initialized the state variables of the PDCP layer device when receiving the RRC message in Operation 905, then the UE discards the data (PDCP PDU or SDU) of the PDCP layer device for SRB1 and initializes the state variables. As mentioned above, discarding data can prevent unnecessary retransmissions that may occur during subsequent PDCP reconstruction, and initializing the state variables can synchronize the gNB and the state variables with each other (discarding all PDCP SDUs and PDUs for the PDCP entity of SRB1 and initializing the state variables for the PDCP entity of SRB1). Specifically, the state variables initialized as described above can be TX_NEXT, RX_NEXT, RX_DELIV, or RX_REORD values.

[0200] 6. The UE can rebuild the PDCP layer device for SRB1 to update the encryption algorithm and integrity verification algorithm with the updated security key. Furthermore, the UE can restore the PDCP state. Additionally, because the security key has been updated, the UE can initialize the COUNT value. It should be noted that the PDCP layer device reconstruction process does not include the data discarding process and state variable initialization process for DRB as described above (initialization of UM DRB variables is possible), but mainly includes the processes for retransmission, security key updates, and updates to the encryption algorithm and integrity protection algorithm (restoring the PDCP state, resetting the COUNT value, and rebuilding the PDCP entity for SRB1).

[0201] 7. UE restores SRB1. The reason why the UE restores SRB1 when sending RRC messages is: to send an RRC recovery request message to SRB0 without performing encryption and integrity protection, to receive the RRC recovery message normally through SRB1, and to perform decryption and integrity verification (restore SRB1).

[0202] 8. The UE can restore the integrity protection and encryption process based on the algorithm previously configured in the lower layer equipment (e.g., PDCP layer equipment) for all bearers except SRB0 (configure the lower layer to restore the integrity protection and encryption of all radio bearers except SRB0 using the previously configured algorithm and updated key).

[0203] As described above, in operation 915, the UE can send an RRC recovery request message, and in response, in operation 925, the gNB can send an RRC suspension message or an RRC release message with an rrc-suspend indication to the UE. Specifically, if the UE's connection recovery reason indicates a tracking area update, RAN notification area update (timer expired), or RAN notification area update (deviation from the indicated area) in the RRC recovery request message, the gNB can send an RRC suspension message or an RRC release message with an rrc-suspend indication to the UE in operation 925. The RRC message in operation 925 may include RAN Notification Area Configuration Information (ranNotificationAreaInfo) for configuring a new RAN Notification Area, and the RAN Notification Area Configuration Information may include a cell list, a RAN Notification Area Identifier, or a timer value. If the UE deviates from the area corresponding to the cell list or RAN Notification Area Identifier, the UE can perform a RAN Notification Area Update procedure, operating the timer corresponding to the timer value in the RRC inactive state, and performing the RAN Notification Area Update procedure whenever the timer expires.

[0204] In this disclosure, to enhance security when the gNB sends an RRC message during operation 925, the gNB can generate and update a security key based on the NCC transmitted to the UE in the RRC message during operation 905, and can perform encryption and integrity protection procedures with respect to the RRC message to be sent during operation 925.

[0205] If, during operation 925, the UE receives an RRC suspend message or an RRC release message with an RRC-suspend indication from the gNB, the UE may perform one or more of the following procedures (in operation 930, the UE receives an RRC resume message).

[0206] 1. The system can store the resumeIdentity received from RRC messages, the NCC for determining the security key, and RAN NotificationAreaInfo for mobility support of the UE in RRC inactive mode. As described above, the network can include the NCC value in the RRC message to be sent to the UE, thus enhancing security when the UE subsequently performs a connection restoration process. That is, integrity protection or encryption can be initiated earlier by pre-generating a new security key. The RAN NotificationAreaInfo may include a cell list, RAN NotificationArea ID, or a timer value. If the UE leaves the area corresponding to the cell list or RAN NotificationArea ID, a RAN NotificationArea Update process can be performed. The system can operate the timer corresponding to the timer value in the RRC inactive state and perform a RAN notification and update process (to store the resumeIdentity, NCC, and RAN NotificationAreaInfo provided by the network) whenever the timer expires.

[0207] 2. The MAC layer device is reset, i.e., initialized. If the MAC layer device is not initialized, data sent in RRC connection mode and existing in the buffer may be unnecessarily retransmitted later. That is, when the connection is restored, inconsistencies may occur between HARQ processing information and the actual HARQ processing information. Therefore, initialization can prevent MAC layer device problems (MAC reset) that may occur when the connection is restored.

[0208] 3. The initialized MAC layer device can suspend the process of updating the token value (Bj) for the LCP procedure at predetermined time units. If the token value is continuously updated in RRC inactive mode, the token value of each logical channel will reach its maximum value, and therefore, the LCP procedure may not operate correctly when the connection is restored. That is, the priority between logical channels may not be applied properly (Bj accumulation during the suspended LCP procedure).

[0209] 4. In the RLC layer device corresponding to each bearer of the UE, unprocessed data (RLC SDU or RLCPDU) may be retained in the buffer. Therefore, data retransmission may be unnecessarily performed during the connection restoration process. Furthermore, the UE's RLC state variables may be out of sync with the gNB's RLC state variables. That is, the transmitted RLC window may not be properly synchronized with the received RLC window. Therefore, the UE rebuilds the RLC layer device for all SRBs and DRBs (rebuilds the RLC entity for all SRBs and DRBs).

[0210] 5. In the PDCP layer device corresponding to each bearer of the UE, unprocessed data (PDCP SDU or PDCP PDU) can be retained in the buffer. Therefore, data retransmission may be unnecessarily performed during the connection restoration process. Furthermore, the UE's PDCP state variables may be out of sync with the gNB's PDCP state variables. That is, the transmitted PDCP window may not be properly synchronized with the received PDCP window. Therefore, the UE discards all data for all SRBs and DRBs in the PDCP layer device and initializes the state variables (discards all PDCP SDUs and PDUs for all SRBs and DRBs, and initializes the state variables for all SRBs and DRBs). It should be noted that the PDCP layer device reconstruction process does not include the data discarding process and state variable initialization process for DRBs as described above, but mainly includes processes for retransmission, security key updates, and updates to encryption and integrity protection algorithms. Therefore, it is possible to discard data and initialize state variables instead of rebuilding the PDCP layer device.

[0211] 6. If an SDAP layer device is configured, the UE can suspend the SDAP layer device because it is not necessary to operate the SDAP layer device in RRC inactive mode. That is, in RRC inactive mode, there is no need for the mapping process between IP flows and bearers (if any exists, the SDAP entity for all DRBs is suspended).

[0212] 7. In addition to receiving an RRC Suspend message in response to an RRC Resume Request message sent by the UE, a specific procedure may be executed. This specific procedure may be the UE storing its UE context (i.e., RRC configuration information, security configuration information, PDCP status information (e.g., ROHC), C-RNTI, cell identifier, and PCI). Specifically, this specific procedure will not be executed if the timer used for periodic RAN notification area updates expires, or if the UE in RRC inactive mode deviates from the RAN notification area and therefore performs a connection restoration procedure for RAN notification area updates.

[0213] 8. The UE suspends all remaining SRBs and DRBs except SRB0. Later, if the UE receives a paging message, uplink data occurs in the UE, or the UE should perform a RAN notification area update procedure, the UE will not suspend SRB0 so that the connection recovery procedure can be started immediately through SRB0 (suspending all SRBs and DRBs except SRB0).

[0214] 9. The UE can operate a timer to periodically perform RAN notification area updates based on the timer value received from the RRC message (starting the timer with the timer value set to periodic-RNAU-timer).

[0215] 10. Configure the lower layer (e.g., PDCP) of the UE to suspend the integrity protection and encryption process (configure the lower layer to suspend integrity protection and encryption).

[0216] 11. The UE switches to RRC inactive mode (enters RRC inactive mode).

[0217] If an RRC suspend message or an RRC release message (RRCRelease) is received from Operation 925 with an RRC-suspend indication, the UE will maintain the RRC active mode again.

[0218] Next, in this disclosure, a method is proposed to prevent the UE from triggering unnecessary PDCP status reports.

[0219] In next-generation mobile communication systems, when the UE requests a PDCP reconstruction process or a PDCP data recovery process from a PDCP layer device at its upper layer (e.g., NAS layer), a PDCP status report is triggered. In this case, the UE should configure the PDCP status report and send it to the gNB.

[0220] In this disclosure, the above conditions are further subdivided, and the UE does not trigger or send unnecessary PDCP status reports to reduce the processing burden on the UE and reduce unnecessary overhead.

[0221] In this disclosure, it is proposed that a PDCP status report will not be triggered, configured, or sent even if an upper layer requests a PDCP reconstruction process if one of the following conditions is met.

[0222] 1. In the PDCP layer device used for UE bearer, the statusReportRequired value is set to TRUE (although it indicates that PDCP status reporting is performed during PDCP reconstruction or PDCP data recovery), but the UE AS context is reused in the RRC message received by the UE.

[0223] 2. In the PDCP layer device used for UE bearer, the statusReportRequired value is set to TRUE (although it indicates that PDCP status reporting is performed during PDCP reconstruction or PDCP data recovery), but the UE receives an RRC recovery message and requests PDCP reconstruction by receiving the RRC message.

[0224] 3. In the PDCP layer equipment used for UE bearer, the statusReportRequired value is set to TRUE (although it indicates that PDCP status reporting is performed during PDCP reconstruction or PDCP data recovery), but PDCP reconstruction is requested during the UE's RRC recovery process.

[0225] 4. In the PDCP layer equipment used for UE bearer, the statusReportRequired value is set to FALSE (if it indicates that PDCP status reporting is not performed during PDCP reconstruction or PDCP data recovery).

[0226] 5. In the PDCP layer device used for UE bearer, the statusReportRequired value is set to TRUE (although it indicates that PDCP status reporting is performed during PDCP reconstruction or PDCP data recovery), but the data (PDCP SDU and PDCP PDU) stored in the UE's PDCP layer device does not exist in the buffer and the values ​​of the RX_NEXT and RX_DELIV variables are equal to each other.

[0227] Furthermore, this disclosure proposes to trigger, configure, or send a PDCP status report if one of the following conditions is met and a PDCP reconstruction process is requested from an upper layer.

[0228] 1. In the PDCP layer device used for UE bearer, the statusReportRequired value is set to TRUE (which indicates that PDCP status reporting is performed during PDCP reconstruction or PDCP data recovery), and the indication for PDCP reconstruction (recreatedPDCP) is included in the RRC message received by the UE.

[0229] 2. The case where the statusReportRequired value is set to TRUE in the PDCP layer device used for UE bearer (which indicates that PDCP status reporting is performed during PDCP reconstruction or PDCP data recovery), and RRC configuration information and bearer configuration information (ReconfigWithSync) are included in the RRC message received by the UE.

[0230] 3. In the PDCP layer device used for UE bearer, the statusReportRequired value is set to TRUE (which indicates that PDCP status reporting is performed during PDCP reconstruction or PDCP data recovery), and the RRC message received by the UE is a message indicating the handover process and the case of PDCP reconstruction in response to the handover request.

[0231] 4. In the PDCP layer device used for UE bearer, the statusReportRequired value is set to FALSE (if it indicates that PDCP status reporting is not performed during PDCP reconstruction or PDCP data recovery), and the PDCP data (PDCP SDU and PDCP PDU) stored in the PDCP layer device exists in the buffer and the values ​​of the RX_NEXT and RX_DELIV variables are equal to each other.

[0232] In this disclosure, based on the conditions proposed in this disclosure, PDCP status report triggering is further subdivided, and the UE does not trigger or send unnecessary PDCP status reports, so as to reduce the processing burden of the UE and reduce unnecessary overhead.

[0233] Next, this disclosure proposes a new PDCP reconstruction method for transport PDCP layer devices (transmitting PDCP entities) to efficiently perform different PDCP reconstruction processes based on RRC messages.

[0234] The reconstruction process (PDCP reconstruction) of the first PDCP layer device proposed in this disclosure is as follows and can be applied to PDCP layer devices connected to RLC layer devices in RLC confirmation mode (RLC AM).

[0235] -During the PDCP entity reconstruction process, encryption algorithms and security keys provided by the upper layer are applied.

[0236] - During the PDCP entity reconstruction process, integrity protection algorithms and security keys provided by the upper layer are applied.

[0237] - For Acknowledgment Mode (AM) DRB, starting from the first PDCP SDU for which the lower layer has not yet acknowledged the successful delivery of the corresponding PDCP data PDU, before the PDCP entity is rebuilt, all PDCP SDUs already associated with the PDCP SN are retransmitted or transmitted in ascending order of the COUNT value associated with the PDCP SDU.

[0238] - Perform header compression of PDCP SDU.

[0239] - Perform integrity protection and encryption of the PDCP SDU using the COUNT value associated with the PDCP SDU.

[0240] - Submit the resulting PDCP data PDU to the lower layer.

[0241] The reconstruction process (PDCP reconstruction) of the second PDCP layer device proposed in this disclosure is as follows and can be applied to PDCP layer devices connected to RLC layer devices in RLC Acknowledgment Mode (RLC AM). The reconstruction process of the second PDCP layer device proposed in this disclosure can be defined as a PDCP initialization process (PDCP reset).

[0242] - Set the TX_NEXT status variable to its initial value.

[0243] - Discard all stored PDCP SDUs and PDCP PDUs.

[0244] - Apply encryption algorithms and security keys provided by the upper layer.

[0245] - Apply the integrity protection algorithm and security key provided by the upper layer.

[0246] - Set the RX_NEXT and RX_DELIV state variables to their initial values.

[0247] The first PDCP reconstruction procedure proposed in this disclosure can be performed if one of the following conditions is met.

[0248] 1. The RRC message received by the UE includes RRC configuration information and bearer configuration information (ReconfigWithSync), and requests the PDCP reconstruction process.

[0249] 2. The UE receives an RRC reconfiguration message or a handover indication message, and requests a PDCP reconstruction process.

[0250] 3. The RRC message received by the UE includes an instruction to rebuild the PDCP and a request for the PDCP rebuild process.

[0251] The second PDCP reconstruction procedure (PDCP initialization procedure) proposed in this disclosure can be executed if one of the following conditions is met.

[0252] 1. The UE receives an RRC message indicating the need to reuse the UE AS context and requesting the PDCP reconstruction procedure.

[0253] 2. The UE receives an RRC recovery message and requests the PDCP reconstruction process.

[0254] 3. The case where the PDCP reconstruction process is requested during the UE's connection recovery configuration process.

[0255] Next, in this disclosure, an effective paging method is proposed for situations where the gNB sends a paging message to a UE in RRC inactive mode or a UE in RRC idle mode.

[0256] In the paging method proposed in this invention, the gNB can define two different paging messages. The first paging message can be called a CN paging message and is a message that can be used to send a paging message to a UE in RRC idle mode. The second paging message can be called a RAN paging message and can be used to send a paging message to a UE in RRC inactive mode. The UE can distinguish between the two paging messages based on the identifiers included in the paging messages. For example, if the paging message includes an identifier such as S-TMSI or IMSI, the UE can consider the paging message to be a CN paging message. Conversely, if the paging message includes resumeIdentity or I-RNTI, the paging message can be considered a RAN paging message. In addition, the CN paging message and the RAN paging message can include indications that system information has been changed and should be newly received.

[0257] In the paging method proposed in this disclosure, different CN paging messages and RAN paging messages can be defined and used as a single common paging message. That is, only one paging message can be defined, and by the identifier included in the paging message, it can be distinguished whether the paging message is a message transmitted to a UE in RRC inactive mode (in the case that the included identifier is resumeIdentity or I-RNTI) or a message transmitted to a UE in RRC idle mode (in the case that the included identifier is S-TMSI or IMSI).

[0258] In the first and second embodiments of this disclosure, the process of resetting the COUNT value can be performed when the UE receives an RRC message (e.g., an RRC Release message) from the gNB and thus the UE transitions to RRC inactive mode. That is, the stored data described above can be discarded, and the above process can be performed together with the process of initializing window state variables and timers. In this way, the timers and transmission window variables that should be driven when transmitting data, as well as the COUNT value required when encrypting the data to be transmitted, can be prepared in advance.

[0259] As described above, if the UE receives an RRC message (e.g., an RRC release message) from the gNB, and the RRC message includes an indication that the UE wants to switch to RRC inactive mode (e.g., rrc-suspend), then receiving the RRC message can mean that the UE has switched to RRC inactive mode.

[0260] Figure 10 This is a diagram illustrating the operation of a terminal performing the above-described process according to an embodiment of the present disclosure.

[0261] refer to Figure 10 In operation 1001, the terminal can send and receive data in RRC connection mode, and in operations 1005 and 1010, it can transition to RRC inactive mode via an RRC message received from the base station. To enhance security, the base station can include the NCC value in the RRC message to be sent, and the terminal can store the NCC value and use it in newly generated and updated security keys when reconnecting. In operations 1015 and 1020, the terminal performs a connection restoration process, which, upon receiving a paging message, requires updating the RAN notification area, generating uplink data, or performing a tracking area update. During the connection restoration process, the terminal performs the procedures described above as presented in this disclosure, and in operation 1025, it transitions to RRC connection mode.

[0262] Figure 11 This is a diagram illustrating the structure of a terminal according to an embodiment of the present disclosure.

[0263] refer to Figure 11 The terminal includes a radio frequency (RF) processor 1110, a baseband processor 1120, a storage device 1130, and a controller 1140.

[0264] RF processor 1110 performs functions for transmitting and receiving signals on a radio channel, such as signal band conversion and amplification. Specifically, RF processor 1110 performs up-conversion of the baseband signal provided from baseband processor 1120 to an RF band signal to transmit the converted signal to the antenna, and performs down-conversion of the RF band signal received by the antenna back to a baseband signal. For example, RF processor 1110 may include transmit filters, receive filters, amplifiers, mixers, oscillators, digital-to-analog converters (DACs), and analog-to-digital converters (ADCs). Although only one antenna is shown in the figures, the terminal may be equipped with multiple antennas. Furthermore, RF processor 1110 may include multiple RF chains. Additionally, RF processor 1110 can perform beamforming. For beamforming, RF processor 1110 can adjust the phase and magnitude of signals transmitted or received through multiple antennas or antenna elements. Furthermore, the RF processor can perform MIMO and can receive multiple layers during MIMO operation. The RF processor 1110 can perform receive beam scanning under the control of the controller by a proper configuration of multiple antennas or antenna elements, or it can control the direction and beamwidth of the receive beam to synchronize the receive beam with the transmit beam.

[0265] The baseband processor 1120 performs conversions between baseband signals and bit strings according to the system's physical layer standard. For example, during data transmission, the baseband processor 1120 generates complex symbols by encoding and modulating the transmitted bit strings. Furthermore, during data reception, the baseband processor 1120 recovers the received bit strings by demodulating and decoding the baseband signals provided from the RF processor 1110. For example, following the OFDM method, during data transmission, the baseband processor 1120 generates complex symbols by encoding and modulating the transmitted bit strings, performs mapping of complex symbols on subcarriers, and then configures OFDM symbols through inverse fast Fourier transform (IFFT) operations and cyclic prefix (CP) insertion. Furthermore, during data reception, the baseband processor 1120 divides the baseband signals provided from the RF processor 1110 into units of OFDM symbols, recovers the signals mapped on subcarriers through FFT operations, and then recovers the received bit strings through demodulation and decoding.

[0266] The baseband processor 1120 and RF processor 1110 transmit and receive signals as described above. Therefore, the baseband processor 1120 and RF processor 1110 can be referred to as a transmitter, receiver, transceiver, or communication unit. Furthermore, to support different radio connectivity technologies, at least one of the baseband processor 1120 and RF processor 1110 may include multiple communication modules. Additionally, to process signals in different frequency bands, at least one of the baseband processor 1120 and RF processor 1110 may include different communication modules. For example, different radio connectivity technologies may include LTE networks and NR networks. Furthermore, different frequency bands may include ultra-high frequency (SHF) bands (e.g., 2.2 GHz or 2 GHz) and millimeter wave (mm Wave) bands (e.g., 60 GHz).

[0267] Storage device 1130 stores basic programs, application programs, and configuration information for the operation of the terminal. Storage device 1130 provides the stored data according to requests from controller 1140.

[0268] Controller 1140 controls the entire operation of the terminal. For example, controller 1140 sends and receives signals via baseband processor 1120 and RF processor 1110. Furthermore, controller 1140 records data in or reads data from storage device 1130. For this purpose, controller 1140 may include at least one processor or multiple connected processors 1142. For example, controller 1140 may include a communication processor that performs control over communications and an application processor (AP) that controls upper layers such as applications.

[0269] Figure 12 This is a diagram illustrating the structure of a base station according to an embodiment of the present disclosure.

[0270] refer to Figure 12 The base station includes an RF processor 1210, a baseband processor 1220, a communication circuit 1230, a storage device 1240, and a controller 1250.

[0271] RF processor 1210 performs functions for transmitting and receiving signals on a radio channel, such as signal band conversion and amplification. Specifically, RF processor 1210 performs up-conversion of baseband signals provided from baseband processor 1220 to RF band signals to transmit the converted signals to the antenna, and performs down-conversion of RF band signals received through the antenna back to baseband signals. For example, RF processor 1210 may include transmit filters, receive filters, amplifiers, mixers, oscillators, DACs, and ADCs. Although only one antenna is shown in the figures, the first connection node may be configured with multiple antennas. Furthermore, RF processor 1210 may include multiple RF chains. Additionally, RF processor 1210 can perform beamforming. For beamforming, RF processor 1210 can adjust the phase and magnitude of signals transmitted or received through multiple antennas or antenna elements. Furthermore, the RF processor can perform down-MIMO operation through transmission over one or more layers.

[0272] The baseband processor 1220 performs conversion between baseband signals and bit strings according to the physical layer standard of the first radio connection technology. For example, during data transmission, the baseband processor 1220 generates complex symbols by encoding and modulating the transmitted bit strings. Furthermore, during data reception, the baseband processor 1220 recovers the received bit strings by demodulating and decoding the baseband signals provided from the RF processor 1210. For example, following the OFDM method, during data transmission, the baseband processor 1220 generates complex symbols by encoding and modulating the transmitted bit strings, performs mapping of complex symbols on subcarriers, and then configures OFDM symbols through IFFT operations and CP insertion. Furthermore, during data reception, the baseband processor 1220 divides the baseband signals provided from the RF processor 1210 into units of OFDM symbols, recovers the signals mapped on subcarriers through FFT operations, and then recovers the received bit strings through demodulation and decoding. The baseband processor 1220 and the RF processor 1210 transmit and receive signals as described above. Therefore, the baseband processor 1220 and the RF processor 1210 can be referred to as a transmitter, receiver, transceiver, or communication unit.

[0273] The communication circuit 1230 provides an interface for communicating with other nodes in the network.

[0274] Storage device 1240 stores basic programs, application programs, and configuration information for the operation of the main base station. Specifically, storage device 1240 can store information about bearers allocated to connected terminals and measurement results reported from connected terminals. Furthermore, storage device 1240 can store information that forms the basis for determining whether to provide or suspend multiple connections to the terminals. Additionally, storage device 1240 provides the stored data upon request from controller 1250.

[0275] The controller 1250 controls the entire operation of the main base station. For example, the controller 1250 transmits and receives signals via the baseband processor 1220 and the RF processor 1210 or via the communication circuit 1230. Furthermore, the controller 1250 records data in or reads data from the storage device 1240. For this purpose, the controller 1250 may include at least one processor or multiple interconnect processors 1252.

[0276] As stated above, the embodiments disclosed in the specification and drawings are merely illustrative examples to facilitate explanation and understanding of the contents of this disclosure, but are not intended to limit the scope of this disclosure. Therefore, the scope of this disclosure should be interpreted to include all changes or modifications derived from the technical concept of this disclosure, in addition to the embodiments disclosed herein.

[0277] Although this disclosure has been shown and described with reference to various embodiments thereof, those skilled in the art will understand that various changes in form and detail may be made therein without departing from the spirit and scope of this disclosure as defined by the appended claims and their equivalents.

Claims

1. A method performed by a terminal in a wireless communication system, the method comprising: Receive a Radio Resource Control (RRC) release message from the base station, the RRC release message including information configuring the RRC inactive state; Reset the Media Access Control (MAC) entity based on the information provided; Based on the aforementioned information, all signaling radio bearers (SRBs) and all data radio bearers (DRBs) except for signaling radio bearer 0SRB0 are suspended. Based on the information, operations are performed on all DRBs, wherein the operations include: Set the state variables of the Packet Data Convergence Protocol (PDCP) entity to their initial values, and Discard all stored PDCP protocol data units (PDUs) of the PDCP entity; And based on the information, it enters the RRC inactive state.

2. The method according to claim 1, further comprising: When the terminal is in an RRC inactive state, the restoration of the RRC connection is triggered; as well as Send an RRC recovery request message to the base station.

3. The method of claim 2, wherein, RRC connection restoration is triggered based on received paging messages.

4. The method according to claim 1, wherein, The state variables include a first state variable, which indicates the count value of the next PDCP Service Data Unit (SDU) of the PDCP entity to be sent.

5. The method according to claim 1, wherein, The state variables include a second state variable and a third state variable. The second state variable indicates the count value of the next PDCP service data unit (SDU) of the PDCP entity expected to be received, and the third state variable indicates the count value of the first PDCP SDU of the PDCP entity that has not been delivered to the upper layer and is waiting.

6. A method performed by a base station in a wireless communication system, the method comprising: Generate a Radio Resource Control (RRC) release message, the RRC release message including information configuring the RRC inactive state, wherein the information is to be used by the terminal for: Reset the Media Access Control (MAC) entity. Suspend all signaling radio bearers (SRBs) and all data radio bearers (DRBs) except for signaling radio bearer 0 (SRB0). Perform operations on all DRBs, the operations including: Set the state variables of the Packet Data Convergence Protocol (PDCP) entity to their initial values, and Discard all stored PDCP protocol data units (PDUs) of the PDCP entity, and Entering the RRC inactive state; and Send the RRC release message to the terminal.

7. The method of claim 6, further comprising: The RRC connection recovery is triggered when the terminal is in an RRC inactive state, and an RRC recovery request message is received from the terminal.

8. The method according to claim 7, wherein, The restoration of the RRC connection is triggered by a paging message sent to the terminal.

9. The method according to claim 6, wherein, The state variables include a first state variable, which indicates the count value of the next PDCP Service Data Unit (SDU) of the PDCP entity to be sent.

10. The method according to claim 6, wherein, The state variables include a second state variable and a third state variable. The second state variable indicates the count value of the next PDCP service data unit (SDU) of the PDCP entity expected to be received, and the third state variable indicates the count value of the first PDCP SDU of the PDCP entity that has not been delivered to the upper layer and is waiting.

11. A terminal in a wireless communication system, the terminal comprising: transceiver; as well as The controller, coupled to the transceiver and configured to: Receive a Radio Resource Control (RRC) release message from the base station, the RRC release message including information configuring the RRC inactive state. The Media Access Control (MAC) entity is reset based on the information provided. Based on the aforementioned information, all signaling radio bearers (SRBs) and all data radio bearers (DRBs) are suspended, except for signaling radio bearer 0SRB0. Based on the information, operations are performed on all DRBs, wherein the operations include: Set the state variables of the Packet Data Convergence Protocol (PDCP) entity to their initial values, and Discard all stored PDCP protocol data units (PDUs) of the PDCP entity, and Based on the information, it enters the RRC inactive state.

12. The terminal according to claim 11, wherein, The controller is further configured to: When the terminal is in an RRC inactive state, the restoration of the RRC connection is triggered, and Send an RRC recovery request message to the base station.

13. The terminal according to claim 12, wherein, RRC connection restoration is triggered based on received paging messages.

14. The terminal according to claim 11, wherein, The state variables include a first state variable, which indicates the count value of the next PDCP Service Data Unit (SDU) of the PDCP entity to be sent.

15. The terminal according to claim 11, wherein, The state variables include a second state variable and a third state variable. The second state variable indicates the count value of the next PDCP service data unit (SDU) of the PDCP entity expected to be received, and the third state variable indicates the count value of the first PDCP SDU of the PDCP entity that has not been delivered to the upper layer and is waiting.

16. A base station in a wireless communication system, the base station comprising: transceiver; as well as The controller, coupled to the transceiver and configured to: Generate a Radio Resource Control (RRC) release message, the RRC release message including information configuring the RRC inactive state, wherein the information is to be used by the terminal for: Reset the Media Access Control (MAC) entity. Suspend all signaling radio bearers (SRBs) and all data radio bearers (DRBs) except for signaling radio bearer 0 (SRB0). Perform operations on all DRBs, the operations including: Set the state variables of the Packet Data Convergence Protocol (PDCP) entity to their initial values, and Discard all stored PDCP protocol data units (PDUs) of the PDCP entity, and Entering the RRC inactive state, and Send the RRC release message to the terminal.

17. The base station according to claim 16, wherein, The controller is further configured to: The RRC connection recovery is triggered when the terminal is in an RRC inactive state, and an RRC recovery request message is received from the terminal.

18. The base station according to claim 17, wherein, The restoration of the RRC connection is triggered by a paging message sent to the terminal.

19. The base station according to claim 16, wherein, The state variables include a first state variable, which indicates the count value of the next PDCP Service Data Unit (SDU) of the PDCP entity to be sent.

20. The base station according to claim 16, wherein, The state variables include a second state variable and a third state variable. The second state variable indicates the count value of the next PDCP service data unit (SDU) of the PDCP entity expected to be received, and the third state variable indicates the count value of the first PDCP SDU of the PDCP entity that has not been delivered to the upper layer and is waiting.

Images