WO2023153731A1 - Sdt와 관련된 통신 - Google Patents

Sdt와 관련된 통신 Download PDF

Info

Publication number
WO2023153731A1
WO2023153731A1 PCT/KR2023/001621 KR2023001621W WO2023153731A1 WO 2023153731 A1 WO2023153731 A1 WO 2023153731A1 KR 2023001621 W KR2023001621 W KR 2023001621W WO 2023153731 A1 WO2023153731 A1 WO 2023153731A1
Authority
WO
WIPO (PCT)
Prior art keywords
ran
sdt
new
context
xnap
Prior art date
Application number
PCT/KR2023/001621
Other languages
English (en)
French (fr)
Inventor
김석중
변대욱
Original Assignee
엘지전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Publication of WO2023153731A1 publication Critical patent/WO2023153731A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/27—Transitions between radio resource control [RRC] states

Definitions

  • This specification relates to mobile communication.
  • 3rd generation partnership project (3GPP) long-term evolution (LTE) is a technology enabling high-speed packet communications. Many initiatives have been proposed for LTE goals, including those aimed at reducing user and provider costs, improving service quality, and expanding and improving coverage and system capacity. 3GPP LTE requires cost per bit reduction, service availability improvement, flexible use of frequency bands, simple structure, open interface, and appropriate power consumption of terminals as upper-level requirements.
  • NR New Radio
  • 3GPP has successfully and timely delivered a new Radio Access Technology (RAT) that meets both urgent market needs and long-term requirements set by the International Mobile Telecommunications (ITU-R) international mobile telecommunications (IMT)-2020 process.
  • RAT Radio Access Technology
  • ITU-R International Mobile Telecommunications
  • IMT international mobile telecommunications
  • the technical components needed to standardize must be identified and developed.
  • NR should be able to use spectrum bands ranging from at least up to 100 GHz that can be used for wireless communication even in the more distant future.
  • NR aims to be a single technology framework that covers all usage scenarios, requirements and deployment scenarios, including enhanced mobile broadband (eMBB), massive machine-type-communications (mMTC), ultra-reliable and low latency communications (URLLC), and more. do. NR may inherently be forward compatible.
  • eMBB enhanced mobile broadband
  • mMTC massive machine-type-communications
  • URLLC ultra-reliable and low latency communications
  • NR may inherently be forward compatible.
  • Small Data Transmission which transmits a small amount of data while maintaining the terminal as RRC INACTIVE, is being discussed.
  • the UE may have non-SDT bearer data.
  • a process of stopping SDT and transitioning to the RRC_CONNECTED state may begin.
  • a method for supporting transmission of non-SDT data is required.
  • a method for a first NG-RAN node to perform communication includes receiving a RETRIEVE UE CONTEXT request message including a first UE XnAP ID and an I-RNTI from a second NG-RAN node; Performing verification for UE based on the I-RNTI; and transmitting a response message to the second NG-RAN node in response to the RETRIEVE UE CONTEXT request message.
  • an apparatus implementing the method is provided.
  • a method for a first NG-RAN node to perform communication includes receiving an RRC resume request message including an I-RNTI from a UE; Transmitting a RETRIEVE UE CONTEXT request message including a first UE XnAP ID and an I-RNTI to a second NG-RAN node; In response to the RETRIEVE UE CONTEXT request message, a response message from the second NG-RAN node receiving; and transmitting an RRC Resume message to the UE.
  • an apparatus implementing the method is provided.
  • FIG. 1 shows an example of a communication system to which an implementation of the present specification is applied.
  • FIG. 2 shows an example of a wireless device to which implementations of the present disclosure apply.
  • FIG 3 shows an example of a wireless device to which implementations of the present disclosure apply.
  • FIG 4 shows an example of a network node to which the implementation of the present specification is applied.
  • 5 shows an example of a 5G system architecture to which the implementation of the present specification is applied.
  • 6A and 6B show an example of a procedure related to SDT of the disclosure of this specification.
  • 7A and 7B show signal flow diagrams according to a first example of a first example of the disclosure of this specification.
  • 8A and 8B show signal flow diagrams according to a second example of the first example of the disclosure of this specification.
  • 9A and 9B show signal flow diagrams according to a third example of the first example of the disclosure of this specification.
  • 10A and 10B show signal flow diagrams according to a second example of the disclosure of this specification.
  • FIG. 11 shows a signal flow diagram according to a fourth example of the disclosure of this specification.
  • multiple access systems include a code division multiple access (CDMA) system, a frequency division multiple access (FDMA) system, a time division multiple access (TDMA) system, an orthogonal frequency division multiple access (OFDMA) system, a system, and a single SC-FDMA system. It includes a carrier frequency division multiple access (MC-FDMA) system and a multicarrier frequency division multiple access (MC-FDMA) system.
  • CDMA may be implemented through a radio technology such as universal terrestrial radio access (UTRA) or CDMA2000.
  • TDMA may be implemented through a radio technology such as global system for mobile communications (GSM), general packet radio service (GPRS), or enhanced data rates for GSM evolution (EDGE).
  • GSM global system for mobile communications
  • GPRS general packet radio service
  • EDGE enhanced data rates for GSM evolution
  • OFDMA may be implemented through a radio technology such as institute of electrical and electronics engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, or evolved UTRA (E-UTRA).
  • UTRA is part of the universal mobile telecommunications system (UMTS).
  • 3rd generation partnership project (3GPP) long-term evolution (LTE) is a part of evolved UMTS (E-UMTS) using E-UTRA.
  • 3GPP LTE uses OFDMA in downlink (DL) and SC-FDMA in uplink (UL).
  • the evolution of 3GPP LTE includes LTE-A (advanced), LTE-A Pro, and/or 5G NR (new radio).
  • implementations herein are primarily described in the context of a 3GPP-based wireless communication system.
  • the technical characteristics of the present specification are not limited thereto.
  • the following detailed description is provided based on a mobile communication system corresponding to a 3GPP-based wireless communication system, aspects of the present disclosure that are not limited to a 3GPP-based wireless communication system may be applied to other mobile communication systems.
  • a or B may mean “only A”, “only B” or “both A and B”.
  • a or B (A or B)” in the present specification may be interpreted as “A and / or B (A and / or B)”.
  • A, B or C herein means “only A”, “only B”, “only C”, or “any combination of A, B and C ( any combination of A, B and C)”.
  • a slash (/) or comma (comma) used in this specification may mean “and/or”.
  • A/B may mean “A and/or B”. Accordingly, “A/B” may mean “only A”, “only B”, or “both A and B”.
  • A, B, C may mean “A, B or C”.
  • At least one of A and B may mean “only A”, “only B” or “both A and B”.
  • the expression “at least one of A or B” or “at least one of A and/or B” means “A and It can be interpreted the same as “at least one of A and B”.
  • “at least one of A, B and C” means “only A”, “only B”, “only C”, or “A, B and C”. It may mean any combination of A, B and C”.
  • “at least one of A, B or C” or “at least one of A, B and/or C” It may mean "at least one of A, B and C”.
  • control information may be suggested as an example of “control information”.
  • control information in this specification is not limited to “PDCCH”, and “PDCCH” may be suggested as an example of “control information”.
  • PDCCH control information
  • a user equipment UE
  • the illustrated UE may be referred to as a terminal, a mobile equipment (ME), and the like.
  • the UE may be a portable device such as a laptop computer, a mobile phone, a PDA, a smart phone, and a multimedia device, or may be a non-portable device such as a PC and a vehicle-mounted device.
  • UE is used as an example of a wireless communication device (or wireless device, or wireless device) capable of wireless communication.
  • An operation performed by the UE may be performed by a wireless communication device.
  • a wireless communication device may also be referred to as a wireless device, a wireless device, and the like.
  • AMF may mean an AMF node
  • SMF may mean an SMF node
  • UPF may mean a UPF node.
  • a base station which is a term used below, generally refers to a fixed station that communicates with wireless devices, eNodeB (evolved-NodeB), eNB (evolved-NodeB), BTS (Base Transceiver System), access point ( Access Point) and gNB (Next Generation NodeB).
  • eNodeB evolved-NodeB
  • eNB evolved-NodeB
  • BTS Base Transceiver System
  • Access Point Access Point
  • gNB Next Generation NodeB
  • FIG. 1 shows an example of a communication system to which an implementation of the present specification is applied.
  • the 5G usage scenario shown in FIG. 1 is only an example, and the technical features of this specification can be applied to other 5G usage scenarios not shown in FIG. 1 .
  • enhanced mobile broadband eMBB
  • massive machine type communication mMTC
  • ultra-reliable low-latency communications URLLC; ultra-reliable and low latency communications
  • Some use cases may require multiple categories for optimization, while other use cases may focus on just one key performance indicator (KPI).
  • KPI key performance indicator
  • eMBB goes far beyond basic mobile internet access and covers rich interactive tasks and media and entertainment applications in the cloud and augmented reality.
  • Data is one of the key drivers of 5G, and dedicated voice services may not be available for the first time in the 5G era.
  • voice processing is expected to be simplified as an application that leverages the data connection provided by the communication system.
  • the main reason for traffic growth is the increase in the size of content and the increase in applications requiring high data transmission rates.
  • streaming services audio and video
  • conversational video and mobile Internet access will become more widely used.
  • Many of these applications require an always-on connection to push real-time information and alerts for users.
  • Cloud storage and applications are rapidly growing in mobile communication platforms and can be applied to both work and entertainment.
  • Cloud storage is a special use case that accelerates the increase in uplink data transmission speed.
  • 5G is also used for remote work in the cloud. When using a tactile interface, 5G requires much lower end-to-end latency to maintain a good user experience.
  • entertainment such as cloud gaming and video streaming is another key factor driving the demand for mobile broadband capabilities.
  • Smartphones and tablets are essential for entertainment everywhere, including in highly mobile environments such as trains, cars and airplanes.
  • Another use case is augmented reality for entertainment and information retrieval. In this case, augmented reality requires very low latency and instantaneous data volume.
  • IoT internet-of-things
  • URLLC includes ultra-reliable, low-latency links to autonomous vehicles and new services that will transform the industry through remote control of state infrastructure. Reliability and latency are essential to controlling smart grids, automating industries, achieving robotics, and controlling and coordinating drones.
  • 5G is a means of delivering gigabit per second of streaming rated at hundreds of megabits per second, and can complement fiber-to-the-home (FTTH) and cable-based broadband (or DOCSIS). Such fast speeds are needed to deliver TV with 4K and higher (6K, 8K and higher) resolutions, as well as virtual and augmented reality.
  • Virtual reality (VR) and augmented reality (AR) applications include immersive sports games. Certain applications may require special network configurations. For VR games, for example, game companies need to integrate their core servers into the network operator's edge network servers to minimize latency.
  • Cars are expected to be a new important motivating force in 5G, with many use cases for vehicular mobile communications. For example, entertainment for passengers requires high concurrent capacity and high mobility broadband mobile communications. In the future, users will continue to expect high-quality connections regardless of location and speed.
  • Another use case in the automotive sector is AR dashboards.
  • the AR dashboard allows the driver to identify an object in a dark place other than the object visible from the front window, and displays the distance to the object and the movement of the object by overlapping information delivery to the driver.
  • wireless modules will enable communication between vehicles, exchange of information between vehicles and supporting infrastructure, and exchange of information between vehicles and other connected devices, such as those accompanying pedestrians.
  • a safety system reduces the risk of an accident by guiding the driver through alternative courses of action to make driving safer.
  • the next step will be remotely controlled or self-driving vehicles.
  • This requires very high reliability and very fast communication between different autonomous vehicles and between vehicles and infrastructure.
  • self-driving vehicles will perform all driving activities and drivers will focus only on traffic beyond which the vehicle cannot identify them.
  • the technological requirements of autonomous vehicles require ultra-low latency and ultra-high reliability to increase traffic safety to levels that humans cannot achieve.
  • Smart cities and smart homes/buildings will be embedded in high-density wireless sensor networks.
  • a decentralized network of intelligent sensors will identify conditions for cost- and energy-efficient maintenance of a city or home.
  • a similar configuration can be performed for each household. All temperature sensors, window and heating controllers, burglar alarms and appliances will be connected wirelessly. Many of these sensors generally have low data rates, power and cost. However, real-time HD video for monitoring may be required by certain types of devices.
  • the smart grid uses digital information and communication technologies to collect information and connect sensors to act on the collected information. As this information can include the behavior of suppliers and consumers, the smart grid can improve the distribution of fuels such as electricity in ways such as efficiency, reliability, affordability, sustainability of production, and automation.
  • the smart grid can also be considered as another low-latency sensor network.
  • Mission-critical applications are one of the 5G usage scenarios.
  • the health segment includes many applications that can benefit from mobile communications.
  • the communication system may support telemedicine, which provides clinical care at a remote location. Telemedicine can help reduce barriers to distance and improve access to health services that are not consistently available in remote rural areas. Telemedicine is also used to perform critical care and save lives in emergency situations.
  • Mobile communication-based wireless sensor networks can provide remote monitoring and sensors for parameters such as heart rate and blood pressure.
  • Wireless and mobile communications are becoming increasingly important in industrial applications. Wiring is expensive to install and maintain. Therefore, the possibility of replacing cables with reconfigurable wireless links is an attractive opportunity for many industries. However, to achieve this replacement, a wireless connection with cable-like latency, reliability, and capacity needs to be established, and the management of the wireless connection needs to be simplified. When 5G connectivity is required, low latency and very low error probability are the new requirements.
  • Logistics and freight tracking is an important use case for mobile communications, enabling inventory and package tracking from anywhere using location-based information systems. Logistics and freight use cases typically require low data rates, but location information with wide coverage and reliability.
  • a communication system 1 includes wireless devices 100a to 100f, a base station (BS) 200 and a network 300 .
  • FIG. 1 illustrates a 5G network as an example of a network of the communication system 1, the implementation herein is not limited to the 5G system and may be applied to future communication systems beyond the 5G system.
  • Base station 200 and network 300 may be implemented as wireless devices, and certain wireless devices may act as base station/network nodes in conjunction with other wireless devices.
  • the wireless devices 100a to 100f represent devices that perform communication using radio access technology (RAT) (eg, 5G NR or LTE), and may also be referred to as communication/wireless/5G devices.
  • the wireless devices 100a to 100f are, but are not limited to, a robot 100a, a vehicle 100b-1 and 100b-2, an extended reality (XR) device 100c, a portable device 100d, and a home appliance. It may include a product 100e, an IoT device 100f, and an artificial intelligence (AI) device/server 400.
  • the vehicle may include a vehicle having a wireless communication function, an autonomous vehicle, and a vehicle capable of performing inter-vehicle communication. Vehicles may include unmanned aerial vehicles (UAVs) (eg, drones).
  • UAVs unmanned aerial vehicles
  • XR devices may include AR/VR/mixed reality (MR) devices, and HMDs (head- mounted device) or HUD (head-up display).
  • Portable devices may include smart phones, smart pads, wearable devices (eg smart watches or smart glasses) and computers (eg laptops).
  • Appliances may include TVs, refrigerators, and washing machines.
  • IoT devices can include sensors and smart meters.
  • the wireless devices 100a to 100f may be referred to as user equipment (UE).
  • the UE includes, for example, a mobile phone, a smart phone, a notebook computer, a digital broadcast terminal, a personal digital assistant (PDA), a portable multimedia player (PMP), a navigation system, a slate PC, a tablet PC, an ultrabook, a vehicle, and an autonomous driving function.
  • vehicles connected cars, UAVs, AI modules, robots, AR devices, VR devices, MR devices, hologram devices, public safety devices, MTC devices, IoT devices, medical devices, fintech devices (or financial devices), security devices , weather/environment devices, 5G service related devices, or 4th industrial revolution related devices.
  • a UAV may be an aircraft that is navigated by a radio control signal without a human being on board.
  • a VR device may include a device for implementing an object or background of a virtual environment.
  • an AR device may include a device implemented by connecting a virtual world object or background to a real world object or background.
  • an MR apparatus may include a device implemented by merging an object or a background of the virtual world with an object or a background of the real world.
  • the hologram device may include a device for realizing a 360-degree stereoscopic image by recording and reproducing stereoscopic information using an interference phenomenon of light generated when two laser lights, called holograms, meet.
  • a public safety device may include an image relay device or imaging device wearable on a user's body.
  • MTC devices and IoT devices may be devices that do not require direct human intervention or manipulation.
  • MTC devices and IoT devices may include smart meters, vending machines, thermometers, smart light bulbs, door locks, or various sensors.
  • a medical device may be a device used for the purpose of diagnosing, treating, mitigating, treating or preventing a disease.
  • a medical device may be a device used to diagnose, treat, mitigate, or correct an injury or damage.
  • a medical device may be a device used for the purpose of inspecting, replacing, or modifying structure or function.
  • the medical device may be a device used for fertility control purposes.
  • a medical device may include a device for treatment, a device for driving, a device for (in vitro) diagnosis, a hearing aid, or a device for procedures.
  • a security device may be a device installed to prevent possible danger and to maintain safety.
  • a security device may be a camera, closed circuit television (CCTV), recorder, or black box.
  • a fintech device may be a device capable of providing financial services such as mobile payments.
  • a fintech device may include a payment device or POS system.
  • the weather/environment device may include a device that monitors or predicts the weather/environment.
  • the wireless devices 100a to 100f may be connected to the network 300 through the base station 200 .
  • AI technology may be applied to the wireless devices 100a to 100f, and the wireless devices 100a to 100f may be connected to the AI server 400 through the network 300.
  • the network 300 may be configured using a 3G network, a 4G (eg LTE) network, a 5G (eg NR) network, and a network after 5G.
  • the wireless devices 100a to 100f may communicate with each other through the base station 200/network 300, but communicate directly without going through the base station 200/network 300 (e.g., sidelink communication) You may.
  • the vehicles 100b-1 and 100b-2 may perform direct communication (eg, vehicle-to-vehicle (V2V)/vehicle-to-everything (V2X) communication).
  • IoT devices eg, sensors
  • IoT devices may directly communicate with other IoT devices (eg, sensors) or other wireless devices 100a to 100f.
  • a wireless communication/connection 150a, 150b, 150c may be established between the wireless devices 100a-100f and/or between the wireless devices 100a-100f and the base station 200 and/or between the base stations 200.
  • the wireless communication/connection refers to uplink/downlink communication 150a, sidelink communication 150b (or device-to-device (D2D) communication), and inter-base station communication 150c (eg, relay, integrated IAB (integrated) communication). It can be established through various RATs (eg, 5G NR), such as access and backhaul).
  • the wireless devices 100a to 100f and the base station 200 may transmit/receive radio signals to each other through the wireless communication/connection 150a, 150b, and 150c.
  • the wireless communication/connections 150a, 150b, and 150c may transmit/receive signals through various physical channels.
  • various configuration information setting processes for transmitting / receiving radio signals various signal processing processes (eg, channel encoding / decoding, modulation / demodulation, resource mapping / demapping, etc.), And at least a part of a resource allocation process may be performed.
  • AI refers to the field of researching artificial intelligence or methodologies that can create it
  • machine learning Machine Learning
  • Machine Learning refers to the field of defining various problems dealt with in the field of artificial intelligence and studying methodologies to solve them.
  • Machine learning is also defined as an algorithm that improves the performance of a certain task through constant experience.
  • a robot may refer to a machine that automatically processes or operates a given task based on its own capabilities.
  • a robot having a function of recognizing an environment and performing an operation based on self-determination may be referred to as an intelligent robot.
  • Robots can be classified into industrial, medical, household, military, etc. according to the purpose or field of use.
  • the robot may perform various physical operations such as moving a robot joint by having a driving unit including an actuator or a motor.
  • the movable robot includes wheels, brakes, propellers, and the like in the driving unit, and can run on the ground or fly in the air through the driving unit.
  • Autonomous driving refers to a technology that drives by itself, and an autonomous vehicle refers to a vehicle that travels without a user's manipulation or with a user's minimal manipulation.
  • autonomous driving includes technology to keep the driving lane, technology to automatically adjust the speed such as adaptive cruise control, technology to automatically drive along a set route, and technology to automatically set a route when a destination is set. All technologies may be included.
  • a vehicle includes a vehicle having only an internal combustion engine, a hybrid vehicle having both an internal combustion engine and an electric motor, and an electric vehicle having only an electric motor, and may include not only automobiles but also trains and motorcycles.
  • Self-driving vehicles can be viewed as robots with self-driving capabilities.
  • Augmented reality is a collective term for VR, AR, and MR.
  • VR technology provides only CG images of objects or backgrounds in the real world
  • AR technology provides CG images created virtually on top of images of real objects
  • MR technology provides CG images by mixing and combining virtual objects in the real world. It is a skill.
  • MR technology is similar to AR technology in that it shows real and virtual objects together. However, there is a difference in that virtual objects are used to supplement real objects in AR technology, whereas virtual objects and real objects are used with equal characteristics in MR technology.
  • NR supports a number of numerologies or subcarrier spacing (SCS) to support various 5G services. For example, when the SCS is 15 kHz, it supports a wide area in traditional cellular bands, and when the SCS is 30 kHz/60 kHz, dense-urban, lower latency and wider A wider carrier bandwidth is supported, and when the SCS is 60 kHz or higher, a bandwidth greater than 24.25 GHz is supported to overcome phase noise.
  • SCS subcarrier spacing
  • the NR frequency band may be defined as two types of frequency ranges (FR1 and FR2).
  • the number of frequency ranges can be changed.
  • the frequency ranges of the two types FR1 and FR2 may be shown in Table 1 below.
  • FR1 may mean "sub 6 GHz range”
  • FR2 may mean "above 6 GHz range” and may be referred to as millimeter wave (mmW). there is.
  • mmW millimeter wave
  • FR1 may include a band of 410 MHz to 7125 MHz as shown in Table 2 below. That is, FR1 may include a frequency band of 6 GHz (or 5850, 5900, 5925 MHz, etc.) or higher. For example, a frequency band of 6 GHz (or 5850, 5900, 5925 MHz, etc.) or higher included in FR1 may include an unlicensed band. The unlicensed band may be used for various purposes, and may be used, for example, for communication for vehicles (eg, autonomous driving).
  • the wireless communication technology implemented in the wireless device of the present specification may include narrowband IoT (NB-IoT) for low power communication as well as LTE, NR, and 6G.
  • NB-IoT technology may be an example of low power wide area network (LPWAN) technology, and may be implemented in standards such as LTE Cat NB1 and/or LTE Cat NB2, and is not limited to the above-mentioned names.
  • LPWAN low power wide area network
  • the wireless communication technology implemented in the wireless device of the present specification may perform communication based on LTE-M technology.
  • LTE-M technology may be an example of LPWAN technology and may be called various names such as eMTC (enhanced MTC).
  • LTE-M technologies include 1) LTE CAT 0, 2) LTE Cat M1, 3) LTE Cat M2, 4) LTE non-BL (non-bandwidth limited), 5) LTE-MTC, 6) LTE MTC , and/or 7) may be implemented in at least one of various standards such as LTE M, and is not limited to the above-mentioned names.
  • the wireless communication technology implemented in the wireless device of the present specification may include at least one of ZigBee, Bluetooth, and/or LPWAN considering low-power communication, and is limited to the above-mentioned names It is not.
  • ZigBee technology can generate personal area networks (PANs) related to small/low-power digital communication based on various standards such as IEEE 802.15.4, and can be called various names.
  • PANs personal area networks
  • FIG. 2 shows an example of a wireless device to which implementations of the present disclosure apply.
  • the first wireless device 100 and the second wireless device 200 may transmit/receive radio signals to/from the external device through various RATs (eg, LTE and NR).
  • various RATs eg, LTE and NR.
  • ⁇ the first wireless device 100 and the second wireless device 200 ⁇ refer to ⁇ the wireless devices 100a to 100f and the base station 200 ⁇ in FIG. 1, ⁇ the wireless devices 100a to 100f ) and wireless devices 100a to 100f ⁇ and/or ⁇ base station 200 and base station 200 ⁇ .
  • the first wireless device 100 may include at least one transceiver, such as transceiver 106, at least one processing chip, such as processing chip 101, and/or one or more antennas 108.
  • Processing chip 101 may include at least one processor such as processor 102 and at least one memory such as memory 104 .
  • memory 104 is shown by way of example to be included in processing chip 101 . Additionally and/or alternatively, memory 104 may be located external to processing chip 101 .
  • Processor 102 may control memory 104 and/or transceiver 106 and may be configured to implement the descriptions, functions, procedures, suggestions, methods and/or operational flow diagrams disclosed herein.
  • the processor 102 may process information in the memory 104 to generate first information/signal and transmit a radio signal including the first information/signal through the transceiver 106 .
  • the processor 102 may receive a radio signal including the second information/signal through the transceiver 106 and store information obtained by processing the second information/signal in the memory 104 .
  • Memory 104 may be operably coupled to processor 102 .
  • Memory 104 may store various types of information and/or instructions.
  • Memory 104 may store software code 105 embodying instructions that when executed by processor 102 perform the descriptions, functions, procedures, suggestions, methods, and/or operational flow diagrams disclosed herein.
  • software code 105 may implement instructions that, when executed by processor 102, perform the descriptions, functions, procedures, suggestions, methods, and/or operational flow diagrams disclosed herein.
  • software code 105 may control processor 102 to perform one or more protocols.
  • software code 105 may control processor 102 to perform one or more air interface protocol layers.
  • processor 102 and memory 104 may be part of a communications modem/circuit/chip designed to implement a RAT (eg LTE or NR).
  • Transceiver 106 may be coupled to processor 102 to transmit and/or receive wireless signals via one or more antennas 108 .
  • Each transceiver 106 may include a transmitter and/or a receiver.
  • the transceiver 106 may be used interchangeably with a radio frequency (RF) unit.
  • the first wireless device 100 may represent a communication modem/circuit/chip.
  • the second wireless device 200 may include at least one transceiver such as transceiver 206 , at least one processing chip such as processing chip 201 and/or one or more antennas 208 .
  • Processing chip 201 may include at least one processor such as processor 202 and at least one memory such as memory 204 .
  • memory 204 is shown by way of example to be included in processing chip 201 . Additionally and/or alternatively, memory 204 may be located external to processing chip 201 .
  • Processor 202 may control memory 204 and/or transceiver 206 and may be configured to implement the descriptions, functions, procedures, suggestions, methods and/or operational flow diagrams disclosed herein.
  • the processor 202 may process information in the memory 204 to generate third information/signal and transmit a radio signal including the third information/signal through the transceiver 206 .
  • the processor 202 may receive a radio signal including the fourth information/signal through the transceiver 206 and store information obtained by processing the fourth information/signal in the memory 204 .
  • Memory 204 may be operably coupled to processor 202 .
  • Memory 204 may store various types of information and/or instructions.
  • Memory 204 may store software code 205 embodying instructions that when executed by processor 202 perform the descriptions, functions, procedures, suggestions, methods, and/or operational flow diagrams disclosed herein.
  • software code 205 may implement instructions that, when executed by processor 202, perform the descriptions, functions, procedures, suggestions, methods, and/or operational flow diagrams disclosed herein.
  • software code 205 may control processor 202 to perform one or more protocols.
  • software code 205 may control processor 202 to perform one or more air interface protocol layers.
  • the processor 202 and memory 204 may be part of a communications modem/circuit/chip designed to implement a RAT (eg LTE or NR).
  • the transceiver 206 may be coupled to the processor 202 to transmit and/or receive wireless signals via one or more antennas 208 .
  • Each transceiver 206 may include a transmitter and/or a receiver.
  • the transceiver 206 may be used interchangeably with the RF unit.
  • the second wireless device 200 may represent a communication modem/circuit/chip.
  • one or more protocol layers may be implemented by one or more processors 102, 202.
  • the one or more processors 102 and 202 may include one or more layers (eg, a physical (PHY) layer, a media access control (MAC) layer, a radio link control (RLC) layer, a packet data convergence protocol (PDCP) layer, functional layers such as a radio resource control (RRC) layer and a service data adaptation protocol (SDAP) layer) may be implemented.
  • layers eg, a physical (PHY) layer, a media access control (MAC) layer, a radio link control (RLC) layer, a packet data convergence protocol (PDCP) layer, functional layers such as a radio resource control (RRC) layer and a service data adaptation protocol (SDAP) layer
  • PHY physical
  • MAC media access control
  • RLC radio link control
  • PDCP packet data convergence protocol
  • RRC radio resource control
  • SDAP service data adaptation protocol
  • One or more processors 102, 202 generate one or more protocol data units (PDUs) and/or one or more service data units (SDUs) according to the descriptions, functions, procedures, proposals, methods and/or operational flow diagrams disclosed herein. can do.
  • One or more processors 102, 202 may generate messages, control information, data or information according to the descriptions, functions, procedures, proposals, methods and/or operational flow diagrams disclosed herein.
  • One or more processors 102, 202 may process PDUs, SDUs, messages, control information, data or signals containing information (e.g., baseband signal) can be generated and provided to one or more transceivers (106, 206).
  • One or more processors 102, 202 may receive signals (eg, baseband signals) from one or more transceivers 106, 206, and the descriptions, functions, procedures, proposals, methods and/or operational flow diagrams disclosed herein According to the PDU, SDU, message, control information, data or information can be obtained.
  • signals eg, baseband signals
  • One or more processors 102, 202 may be referred to as a controller, microcontroller, microprocessor and/or microcomputer.
  • One or more processors 102, 202 may be implemented by hardware, firmware, software, and/or combinations thereof.
  • ASICs application specific integrated circuits
  • DSPs digital signal processors
  • DSPDs digital signal processing devices
  • PLDs programmable logic devices
  • FPGAs field programmable gates
  • Descriptions, functions, procedures, proposals, methods and/or operational flow diagrams disclosed herein may be implemented using firmware and/or software, and firmware and/or software may be implemented to include modules, procedures, and functions. .
  • Firmware or software configured to perform the descriptions, functions, procedures, suggestions, methods and/or operational flow diagrams disclosed herein may be included in one or more processors 102, 202 or stored in one or more memories 104, 204 and It can be driven by the above processors 102 and 202.
  • the descriptions, functions, procedures, suggestions, methods and/or operational flow diagrams disclosed herein may be implemented using firmware or software in the form of codes, instructions and/or sets of instructions.
  • One or more memories 104, 204 may be coupled with one or more processors 102, 202 and may store various types of data, signals, messages, information, programs, codes, instructions and/or instructions.
  • the one or more memories 104, 204 may include read-only memory (ROM), random access memory (RAM), erasable programmable ROM (EPROM), flash memory, hard drive, registers, cache memory, computer readable storage media, and/or any of these It can be composed of a combination of One or more memories 104, 204 may be located internally and/or external to one or more processors 102, 202. Additionally, one or more memories 104, 204 may be coupled to one or more processors 102, 202 through various technologies, such as wired or wireless connections.
  • One or more transceivers 106, 206 may transmit to one or more other devices user data, control information, radio signals/channels, etc., as discussed in the descriptions, functions, procedures, proposals, methods and/or operational flow diagrams disclosed herein. .
  • One or more transceivers 106, 206 may receive user data, control information, radio signals/channels, etc., from one or more other devices as referred to in the descriptions, functions, procedures, proposals, methods and/or operational flow diagrams disclosed herein. there is.
  • one or more transceivers 106 and 206 may be connected to one or more processors 102 and 202 and transmit and receive wireless signals.
  • one or more processors 102, 202 may control one or more transceivers 106, 206 to transmit user data, control information, radio signals, etc. to one or more other devices.
  • one or more processors 102, 202 may control one or more transceivers 106, 206 to receive user data, control information, radio signals, and the like from one or more other devices.
  • One or more transceivers 106, 206 may be coupled with one or more antennas 108, 208.
  • One or more transceivers (106, 206) via one or more antennas (108, 208) transmit user data, control information, radio signals/channels referred to in the descriptions, functions, procedures, proposals, methods and/or operational flow diagrams disclosed herein. etc. can be set to transmit and receive.
  • one or more antennas 108 and 208 may be a plurality of physical antennas or a plurality of logical antennas (eg, antenna ports).
  • One or more transceivers use one or more processors (102, 202) to process received user data, control information, radio signals/channels, etc. etc. can be converted from an RF band signal to a baseband signal.
  • One or more transceivers 106 and 206 may convert user data, control information, and radio signals/channels processed by one or more processors 102 and 202 from baseband signals to RF band signals.
  • one or more of the transceivers 106 and 206 may include (analog) oscillators and/or filters.
  • one or more transceivers 106, 206 up-convert an OFDM baseband signal to an OFDM signal via an (analog) oscillator and/or filter under the control of one or more processors 102, 202 and , the up-converted OFDM signal can be transmitted at the carrier frequency.
  • One or more transceivers 106, 206 receive OFDM signals at the carrier frequency and down-convert the OFDM signals to OFDM baseband signals via (analog) oscillators and/or filters under the control of one or more processors 102, 202 ( down-convert).
  • a UE may act as a transmitting device on an uplink (UL) and as a receiving device on a downlink (DL).
  • a base station may operate as a receiving device in UL and as a transmitting device in DL.
  • the first wireless device 100 operates as a UE and the second wireless device 200 operates as a base station.
  • the processor 102 coupled to, mounted on, or shipped to the first wireless device 100 may perform UE operations in accordance with implementations herein or may operate the transceiver 106 to perform UE operations in accordance with implementations herein.
  • a processor 202 connected to, mounted on, or shipped to the second wireless device 200 is configured to perform base station operations in accordance with implementations herein or to control the transceiver 206 to perform base station operations in accordance with implementations herein. It can be.
  • a base station may be referred to as a Node B, an eNode B (eNB), or a gNB.
  • eNB eNode B
  • gNB gNode B
  • FIG 3 shows an example of a wireless device to which implementations of the present disclosure apply.
  • a wireless device may be implemented in various forms according to use cases/services (see FIG. 1).
  • the wireless devices 100 and 200 may correspond to the wireless devices 100 and 200 of FIG. 2 and may be configured by various components, devices/parts and/or modules.
  • each wireless device 100 , 200 may include a communication device 110 , a control device 120 , a memory device 130 and additional components 140 .
  • the communication device 110 may include a communication circuit 112 and a transceiver 114 .
  • communication circuitry 112 may include one or more processors 102, 202 of FIG. 2 and/or one or more memories 104, 204 of FIG.
  • transceiver 114 may include one or more transceivers 106, 206 of FIG. 2 and/or one or more antennas 108, 208 of FIG.
  • the control device 120 is electrically connected to the communication device 110, the memory device 130, and the additional component 140, and controls the overall operation of each wireless device 100, 200.
  • the control device 120 may control electrical/mechanical operation of each of the wireless devices 100 and 200 based on programs/codes/commands/information stored in the memory device 130 .
  • the control device 120 transmits information stored in the memory device 130 to the outside (eg, other communication devices) via the communication device 110 through a wireless/wired interface, or through a wireless/wired interface to a communication device ( 110), information received from the outside (eg, other communication devices) may be stored in the memory device 130.
  • the additional component 140 may be configured in various ways according to the type of the wireless device 100 or 200.
  • additional components 140 may include at least one of a power unit/battery, an input/output (I/O) device (eg, an audio I/O port, a video I/O port), a power unit, and a computing device.
  • I/O input/output
  • Wireless devices 100 and 200 include, but are not limited to, a robot (100a in FIG. 1 ), a vehicle (100b-1 and 100b-2 in FIG. 1 ), an XR device (100c in FIG. 1 ), a portable device ( FIG. 1 100d), home appliances (100e in FIG. 1), IoT devices (100f in FIG.
  • wireless devices 100 and 200 may be used in a mobile or fixed location depending on usage/service.
  • all of the various components, devices/parts and/or modules of the wireless devices 100 and 200 may be connected to each other through wired interfaces, or at least some of them may be wirelessly connected through the communication device 110.
  • the control device 120 and the communication device 110 are connected by wire, and the control device 120 and the first devices (eg, 130 and 140) are communication devices. It can be connected wirelessly through (110).
  • Each component, device/portion and/or module within the wireless device 100, 200 may further include one or more elements.
  • the control device 120 may be configured by one or more processor sets.
  • control device 120 may be configured by a set of a communication control processor, an application processor (AP), an electronic control unit (ECU), a graphic processing unit, and a memory control processor.
  • AP application processor
  • ECU electronice control unit
  • the memory device 130 may include RAM, DRAM, ROM, flash memory, volatile memory, non-volatile memory, and/or a combination thereof.
  • FIG 4 shows an example of a network node to which the implementation of the present specification is applied.
  • FIG. 4 shows the above-described second wireless device 200 of FIG. 2 or the wireless device 200 of FIG. 3 when the base station is divided into a central unit (CU) and a distributed unit (DU). It is a drawing illustrating in detail.
  • CU central unit
  • DU distributed unit
  • a base station 200 may be connected to a core network 300 .
  • Base stations 200 may be connected to each other.
  • an interface between the base station 200 and the core network 300 may be referred to as NG.
  • an interface between base stations 200 may be referred to as Xn.
  • Base station 200 may be divided into CU 210 and DU 220. That is, the base stations 200 may be hierarchically separated and operated.
  • the CU 210 may be connected to one or more DUs 220.
  • an interface between the CU 210 and the DU 220 may be referred to as F1.
  • the CU 210 may perform a function of an upper layer of the base station 200, and the DU 220 may perform a function of a lower layer of the base station 200.
  • the CU 210 may be a logical node hosting RRC, SDAP, and PDCP layers of the base station 200 (eg, gNB).
  • the CU (W32) may be a logical node hosting the RRC and PDCP layers of the base station 200 (eg, ng-eNB).
  • DU 220 may be a logical node hosting the base station's RLC, MAC and PHY layers.
  • DU 220 may be partially controlled by CU 210 .
  • One DU 220 may support one or more cells. One cell can be supported by only one DU (220).
  • One DU 220 may be connected to one CU 210, and one DU 220 may be connected to a plurality of CUs 210 according to appropriate implementation.
  • 5 shows an example of a 5G system architecture to which the implementation of the present specification is applied.
  • the structure of a 5G system consists of the following network functions (NFs).
  • Data Network e.g. operator services, internet access or third party services
  • Figure 5 shows a 5G system architecture in a non-roaming case using a reference point representation showing how various network functions interact with each other.
  • UDSF In FIG. 5, for clarity of the point-to-point diagram, UDSF, NEF and NRF are not described. However, all network functions shown can interact with UDSF, UDR, NEF and NRF as needed.
  • connection of the UDR to other NFs is not shown in FIG. 5 .
  • connections between NWDAF and other NFs are not shown in FIG. 5 .
  • the 5G system architecture includes the following reference points.
  • -N15 represents a reference point between PCF and AMF in a roaming scenario, and a reference point between AMF and PCF of a visited network in a roaming scenario.
  • AF by a third party other than an operator may be connected to 5GC through NEF.
  • the CM is used to establish or release a signaling connection between the UE and AMF.
  • the CM includes a function of establishing and releasing a NAS signaling connection between the UE and the AMF through the N1 reference point.
  • the NAS signaling connection enables NAS signaling exchange between the UE and the core network.
  • the NAS signaling connection may include an AN signaling connection between an access network (AN) and a UE (an RRC connection through 3GPP access or a connection between a UE and an N3IWF through non-3GPP access) and an N2 connection between an AN and an AMF for a UE. .
  • CM states Two CM states are used to reflect the NAS signaling connection between the UE and AMF.
  • the two CM states are:
  • the CM status for 3GPP access and the CM status for non-3GPP access may be independent of each other. For example, it may be in the CM-IDLE state for 3GPP access and in the CM-CONNECTED state for non-3GPP access.
  • CM-IDLE state the CM-CONNECTED state
  • transition between the CM-IDLE state and the CM-CONNECTED state will be described.
  • a UE in CM-IDLE state does not have a NAS signaling connection with AMF through the N1 interface.
  • the UE may perform a cell selection or cell reselection procedure and a PLMN selection procedure.
  • CM-IDLE For a UE in CM-IDLE state, there is no AN signaling connection, N2 connection and N3 connection.
  • the UE When the UE is in the CM-IDLE state and in the RM (Registration Management)-REGISTERED state, the UE may perform the following operations:
  • the UE can respond to paging by performing a service request procedure.
  • MICO Mobile Initiated Connection Only
  • the UE When the UE has uplink signaling or user data to transmit, it may perform a service request procedure.
  • UE information for initiating communication with the UE may be stored in the AMF.
  • the AMF can retrieve stored information necessary to initiate communication with the UE using 5G-GUTI (Globally Unique Temporary Identifier).
  • the UE may provide 5G-S-TMSI (5G-Short-Temporary Mobile Subscriber Identity) as part of AN parameters while performing a procedure for establishing an AN signaling connection.
  • 5G-S-TMSI 5G-Short-Temporary Mobile Subscriber Identity
  • the UE enters the CM-CONNECTED state. can enter
  • the Initial NAS message initiates a transition from the CM-IDLE state to the CM-CONNECTED state.
  • the initial NAS message may be, for example, a registration request message, a service request message, or a deregistration request message.
  • the AMF may perform the following deposits:
  • the AMF may perform a network triggered service request procedure by sending a paging request message to the UE.
  • the AMF may perform a network initiated service request procedure except when the UE cannot respond due to MICO mode or mobility restrictions.
  • the AMF may enter the CM-CONNECTED state for the UE.
  • Receipt of an initial N2 message eg, N2 INITIAL UE MESSAGE
  • a UE in the CM-CONNECTED state has a signaling connection with the AMF through the N1 reference point.
  • the NAS signaling connection may use an RRC connection between the UE and the NG-RAN and a New Generation Application Protocol (NGAP) UE association between the AN and the AMF for 3GPP.
  • NGAP New Generation Application Protocol
  • the UE may be in a CM-CONNECTED state with an NGAP UE association not bound to any Transport Network Layer Association (TNLA) between the AN and the AMF.
  • TNLA Transport Network Layer Association
  • the UE may perform the following actions:
  • AMF may perform the following operations:
  • the AMF may enter the CM-IDLE state for the UE.
  • the AMF may maintain the UE CM state in the AMF in the CM-CONNECTED state.
  • a UE in the CM-CONNECTED state may be in an RRC inactive state. If the UE is in the RRC Disabled state, the following apply:
  • - UE reachability is managed by the RAN, along with assistance information from the core network.
  • - UE paging is managed by the RAN.
  • the UE manages paging using the UE's CN (5G-S-TMSI) and RAN identifier
  • the CM state in the UE is the CM-IDLE state
  • an AN signaling connection eg, when the UE transmits an initial NAS message
  • the CM state is switched to the CM-CONNECTED state.
  • the CM state in the UE is the CM-CONNECTED state and the AN signaling connection is released, the CM state is switched to the CM-IDLE state.
  • the CM state for the UE in the AMF is the CM-IDLE state
  • the CM state is switched to the CM-CONNECTED state.
  • the CM state for the UE in the AMF is the CM-CONNECTED state
  • the N2 context is released, the CM state is switched to the CM-IDLE state.
  • RRC states in LTE include RRC_IDLE state and RRC_CONNECTED state.
  • the RRC state may include RRC_IDLE state, RRC_CONNECTED state and RRC_INACTIVE state. That is, the RRC_INACTIVE state is newly defined in 5G.
  • the RRC_INACTIVE state may mean an RRC state in which a UE (eg UE) is in a Connected state in the core network, but is in an IDLE state in terms of a radio between the UE and the NG-RAN.
  • a UE eg UE
  • IDLE a radio between the UE and the NG-RAN.
  • the terminal when the terminal is in the RRC_INACTIVE state, the terminal is in a state in which the RRC connection is released from the radio side, the terminal is in the MM (Mobility Management)-REGISTERED state, and the CM (Connection Management)_CONNECTED state.
  • MM Mobility Management
  • CM Connection Management
  • the core can quickly provide a connection to the UE without requiring signaling that occurs when switching to the CONNECTED state.
  • radio resources can be efficiently used.
  • Small Data Transmission which transmits a small amount of data while maintaining the terminal as RRC INACTIVE, is being discussed.
  • the UE may have non-SDT bearer data.
  • a process of stopping SDT and transitioning to the RRC_CONNECTED state may begin.
  • a method for supporting transmission of non-SDT data is required.
  • the UE may enter the coverage of the new NG-RAN. If the UE needs to transmit non-SDT data, the UE transmits an RRC resume request to the new NG-RAN. At this time, it is unclear how to verify the resume MAC-I of the terminal. In addition, since there is no way for the new NG-RAN to find the UE context, a method for the new NG-RAN to utilize the existing UE context is needed.
  • the UE may stop SDT and notify the network of non-SDT data through an RRC Resume Request message again. Since both the old NG-RAN and the new NG-RAN have the UE context for the UE, it is not clear which NG-RAN will verify the Resume MAC-I included in the RRC message transmitted by the UE. If the old NG-RAN verifies the Resume MAC-I for the UE, it must inform the new NG-RAN that the UE verification has passed. In addition, a method for the old NG-RAN to transfer the new security key KgNB* value to be used by the UE in the RRC_CONNECTED state is required.
  • the new NG-RAN may have already completed the AMF and Path Switch Request processes during the SDT process.
  • the new NG-RAN may update or release some parameter values related to the UE according to the instructions of the AMF, a method for the old NG-RAN to deliver only some contexts to the new NG-RAN is required.
  • the new NG-RAN already receives the UE context from the old NG-RAN during the SDT process. However, there is no way for the new NG-RAN to find the existing UE context while the UE sends the second RRC Resume Request message. Therefore, a method for the new NG-RAN to utilize the existing UE context is required.
  • UL data related to a non-SDT bearer may be generated.
  • the UE must stop the corresponding SDT procedure and inform the network that non-SDT data has occurred. It is necessary to discuss whether there is a problem with using the conventional Resume procedure again (ie, Common Control Channel (CCCH) solution) in the process of the UE notifying the network that non-SDT data has occurred.
  • CCCH Common Control Channel
  • the UE transmits the ongoing SDT stop the session
  • the UE may send a second RRCResumeRequest message using the I-RNTI issued by the old anchor gNB and perform horizontal key derivation.
  • I-RNTI Inactive Radio Network Temporary Identifier
  • the old anchor gNB may be used as a term with the same meaning as old NG-RAN or old RAN.
  • serving gNB may be used as a term with the same meaning as new NG-RAN or new RAN.
  • a small data transmission (SDT) function that allows a UE to transmit small data in an INACTIVE state is being studied.
  • the UE may need to transmit UL data over a radio bearer configured for SDT.
  • an SDT procedure may be initiated to transmit and receive data over a radio bearer configured for SDT, and multiple DL and UL packets may be exchanged during the SDT session.
  • an RRCResumeRequest is sent as part of the first UL transmission by the UE along with UL SDT data.
  • the UE uses the stored Next Hop Chaining Counter (NCC) value to generate a security key when generating this first RRCResumeRequest (i.e. same as the legacy resume procedure).
  • NCC Next Hop Chaining Counter
  • SDT procedures are supported with or without anchor relocation.
  • anchor relocation the target gNB gets the UE context from the previous anchor gNB.
  • the PDCP layer is terminated at the target gNB and a path switch procedure is performed before user data is encoded/decoded. If there is no anchor relocation, the previous anchor gNB terminates the PDCP layer and no path switching procedure is performed.
  • new UL data may appear in the buffer of a radio bearer not configured for SDT.
  • the UE may initiate a procedure to indicate this non-SDT data arrival to the network.
  • the UE may terminate the ongoing SDT procedure and trigger a new RRC resume procedure. In this case, the UE may transmit a second RRCResumeRequest to the network.
  • ResumeMAC-I Resume Message Authentication Code - Integrity
  • One option discussed is to use the key derived when the UE starts the SDT procedure to generate the resumeMAC-I for the second RRCResumeRequest sent in the second RRC resume procedure for non-SDT data indication.
  • the C-RNTI input to the resumeMAC-I calculation is the C-RNTI the UE had on the connected PCell before the RRC connection was suspended (ie, the same approach as in the conventional resume procedure).
  • the UE then performs horizontal key derivation to obtain a key to be used for subsequent messages exchanged with the network.
  • the same I-RNTI used for the first RRCResumeRequest is reused for sending the second RRCResumeRequest. Therefore, in the case of path switching, an option is being discussed in which the old anchor gNB verifies the UE by using the key used in the target gNB (ie, KRRCint_1 in the figure below) to protect message integrity.
  • 6A and 6B show an example of a procedure related to SDT of the disclosure of this specification.
  • UE In the examples of FIGS. 6A and 6B , UE, gNB, Last Serving gNB (ie, old anchor gNB), UPF, AMF and/or SMF are shown.
  • Last Serving gNB ie, old anchor gNB
  • UPF User Plane Function
  • AMF Access Management Function
  • SMF Session Management Function
  • the Last Serving gNB may transmit the RRCRelease message together with suspendConfig.
  • the UE may be in RRC_INACTIVE state and CM-CONNECTED state.
  • the UE may initiate SDT. And, the UE can calculate resume MAC-I using the stored KRRCint_0.
  • KRRCint is a key derived by Mobile Equipment (ME) (or UE) and gNB from KgNB, and is used for RRC signal protection using a specific integrity algorithm.
  • KRRCint_0 is the KRRCint value stored when the terminal transitions to the RRC_INACTIVE state.
  • resume MAC-I is an authentication token used when the gNB uses UE authentication, and is a value used when the gNB verifies the UE.
  • the UE can calculate KgNB*_1.
  • KgNB* may also be referred to as KNG-RAN*.
  • KgNB* or KNG-RAN* may be a key derived when the ME (or UE) and the NG-RAN (ie gNB or ng-eNB) perform horizontal key derivation or vertical key derivation.
  • the UE based on horizontal key derivation or vertical key derivation, target PCI, ticket Absolute Radio Frequency Channel Number (ARFCN)-DL / EARFCN-DL and KgNB/NH to derive KNG-RAN*.
  • the UE may calculate UP keys and CP keys including new KRRCint_1 according to a conventional procedure.
  • the UE may transmit a message (Msg3/MsgA) to the gNB along with an RRCResumRequest message. At this time, the UE may also transmit resumId, cause, and shortREsumMAC-I, and may also transmit UL data.
  • Msg3/MsgA message
  • RRCResumRequest message message
  • the UE may also transmit resumId, cause, and shortREsumMAC-I, and may also transmit UL data.
  • the gNB may transmit a RETRIVE UE CONTEXT REQUEST message to the Last Serving gNB along with the SDT indication.
  • the Last Serving gNB may calculate newKgNB*_1 and derive another key including KRRCint_1.
  • the Last Serving gNB may transmit a RETRIIVE UE CONTEXT RESPONSE message to the gNB.
  • the gNB may transmit Xn-U ADDRESS INDICATION to the Last Serving gNB.
  • gNB may transmit a PATH SWITCH REQUEST message to AMF/SMF.
  • AMF/SMF and UPF may perform a PDU session update procedure and an N4 session modification procedure.
  • AMF/SMF may transmit a PATH SWITCH REQUEST ACKNOWLEDGE message to gNB.
  • the gNB may transmit msgB/msg4 and DL data to the UE.
  • Subsequent SDT data may be transmitted and received between the UE and UPF.
  • Non-SDT data may arrive at the UE.
  • the UE may initiate a second RRC Resume procedure. And, the UE may update the UE Inactive AS context using KRRCint_1 and KgNB*_1. The UE may calculate resume MAC-I using KRRCint_1. And the UE may calculate KgNB*2 using horizontal key derivation according to a conventional procedure. And, the UE may calculate UP keys and CP keys according to a conventional procedure.
  • the UE may transmit a message (Msg3/MsgA) to the gNB along with an RRCResumRequest message. At this time, the UE may also transmit shortResumMAC-I calculated using resumId, cause, and updated KRRCint_1.
  • the gNB may transmit a RETRIIVE UE CONTEXT REQUEST message to the Last Serving gNB.
  • the Last Serving gNB may identify that the RRCResumRequest message was transmitted from the same UE based on the I-RNTI. And, the Last Serving gNB may verify ResumMAC-I based on KRRCint_1 instead of KRRCint_0. And, the Last Serving gNB may calculate KgNB*2 using horizontal key derivation according to the prior art.
  • the Last Serving gNB may transmit a RETRIIVE UE CONTEXT RESPONSE message to the gNB.
  • gNB may transmit an RRCResume message to the UE.
  • the gNB may transmit a UE CONTEXT RELEASE message to the Last Serving gNB.
  • a scheme in which the UE triggers a new RRC resume procedure before receiving a response from the network to the first RRCResumeRequest is also being considered.
  • the old NG-RAN that had the UE context can deliver the UE context to the new NG-RAN to which the UE currently accesses. If non-SDT data is generated to the UE during the SDT, the UE may stop the corresponding SDT process and transmit the RRC Resume Request message to the network again. In this case, it is not clear which NG-RAN will verify the Resume MAC-I included in the corresponding RRC message. This is because both the old NG-RAN and the new NG-RAN have a UE context for the UE. If the old NG-RAN verifies the Resume MAC-I for the UE, it must inform the new NG-RAN that the UE verification has passed. In addition, a method for the old NG-RAN to transfer the new security key KgNB* value to be used by the corresponding UE in the RRC_CONNECTED state is required.
  • a problem may occur if the old NG-RAN delivers all currently stored UE contexts to the new NG-RAN in addition to the security key. This is because when the new NG-RAN has already completed the AMF and Path Switch Request processes during the SDT process, some parameter values related to the UE context may have been updated or released. Therefore, a method for the old NG-RAN to transfer only some contexts to the new NG-RAN is also required.
  • the new NG-RAN has already received the UE context from the old NG-RAN during the SDT process. At this time, since there is no way for the new NG-RAN to find the existing UE context while the UE sends the second RRC Resume Request message, a method for the new NG-RAN to utilize the existing UE context is also required.
  • the old NG-RAN allows the new NG-RAN to transition the corresponding UE to the RRC_CONNECTED state for non-SDT data transmission
  • Example of a method for informing the new NG-RAN suggests
  • a new Xn message may be defined and used.
  • a new RRC message may be defined and used.
  • the old NG-RAN may generate and transmit a security key value to be used by the new NG-RAN in the RRC_CONNECTED state after completing verification for the UE.
  • the old NG-RAN may transmit an additional indication notifying it so that the new NG-RAN does not repeat the process again.
  • the old NG-RAN transmits the New NG-RAN UE XnAP ID_1 that the new NG-RAN allocated during the SDT process to the new NG-RAN. By doing so, the New NG-RAN can find the existing UE context used in the SDT process.
  • a first example of the disclosure herein describes an example related to an SDT procedure using anchor relocation.
  • 7A and 7B show signal flow diagrams according to a first example of a first example of the disclosure of this specification.
  • FIGS. 7A and 7B show an example of a procedure for supporting non-SDT data transmission in an ongoing SDT procedure with anchor relocation.
  • the UE may inform the old NG-RAN of the fact that data to be transmitted has occurred through the Non-SDT bearer. Then, the old NG-RAN can generate a new security key after verifying the corresponding terminal and deliver it to the new NG-RAN. Basically, it is assumed that the UE context is moved to the New NG-RAN during the SDT process.
  • both the New NG-RAN and the Old NG-RAN are not separated into CU-CP, CU-UP, and DU, but this is only an example, and The contents can also be applied when the New NG-RAN and/or the Old NG-RAN are separated into CU-CP, CU-UP, and DU.
  • the NG-C connection between the old NG-RAN and AMF is maintained, and the NG-U connection between the old NG-RAN and UPF is also maintained.
  • Step 1 The UE may decide to transmit SDT data in the RRC-INACTIVE state. Then, the UE generates an RRC Resume Request message including I-RNTI, RRC resume cause (for small data transmission in RRC-INACTIVE), and authentication token (e.g., Resume MAC-I) and transmits it to New NG-RAN. there is.
  • the terminal may generate a resume MAC-I based on the KRRCint_0 value stored in the process of transitioning to the RRC_INACTIVE state.
  • the SDT data stored in the buffer of the terminal may be multiplexed and transmitted together with the RRC Resume Request message.
  • the UE may include SDT-related information (e.g., whether or not there is UL data, whether or not to respond to DL Data, etc.) in the RRC Resume Request message and transmit it to the New NG-RAN.
  • KgNB*_1 After transmitting the RRC Resume Request message to the network, the UE generates a KgNB*_1 value, and through this, new KRRCint_1, KRRCenc_1, KUPenc_1 (Optional), and KUPint_1 (Optional) values can be derived. These values may be key values used for integrity protection or encryption for RRC and user planes, respectively.
  • KUPenc is a key that the ME and gNB derive from KgNB and can be used to protect UP traffic using a specific encryption algorithm.
  • KUPint is a key that ME and gNB derive from KgNB, and can be used to protect UP traffic between ME and gNB using a specific integrity algorithm.
  • KRRCenc is a key derived by the ME and gNB from KgNB, and can be used to protect the RRC signal using a specific encryption algorithm.
  • Step 2 New NG-RAN may receive an RRC Resume Request message from the UE. Based on the I-RNTI, the New NG-RAN can check whether the UE context for the corresponding UE can be found. If it fails to find the UE context through the I-RNTI, the new NG-RAN may specify the old NG-RAN based on the I-RNTI. In addition, the new NG-RAN may transmit a RETRIEVE UE CONTEXT REQUEST message to the old NG-RAN in order to receive UE context from the corresponding node (ie, the old NG-RAN).
  • the New NG-RAN may allocate a New NG-RAN UE XnAP ID_1 and transmit the same to the old NG-RAN.
  • the new NG-RAN may inform the old NG-RAN that the current terminal is accessing to transmit SDT data.
  • Step 3 Old NG-RAN can verify the UE.
  • the Old NG-RAN can check whether the UE context for the corresponding UE can be found based on the I-RNTI. If the corresponding UE context can be found, it can be checked whether the Resume MAC-I sent by the UE is valid.
  • Step 4 After the old NG-RAN completes verification of the corresponding UE, the old NG-RAN may decide to transfer the UE context for the corresponding UE to the new NG-RAN. Then, the old NG-RAN may respond to the new NG-RAN through a RETRIEVE UE CONTEXT RESPONSE message.
  • Step 5 If there is DL data to be delivered to the UE, in order to receive the corresponding DL data, New NG-RAN may transmit DL data forwarding address information by transmitting an XN-U ADDRESS INDICATION message.
  • Step 6 New NG-RAN initiates the Path Switch Request procedure toward 5GC, and through this, informs that the UE will serve through New NG-RAN.
  • Step 7 When the procedure for changing the UP path related to the UE to the new NG-RAN is completed, the AMF may respond to the new NG-RAN through a PATH SWTICH REQUEST ACKNOWLEDGE message.
  • Step 8 New NG-RAN may respond to the UE through Msg B or Msg 4. If there is DL data to be delivered to the UE in this process, the New NG-RAN can multiplex the DL data together with the RRC message and transmit it.
  • the UE and 5GC can exchange SDT data through the New NG-RAN.
  • Step 9 Data related to the Non-SDT bearer may arrive at the terminal. Accordingly, the UE may decide to stop transmitting SDT data in order to transition to the RRC-CONNECTED state and start a normal resume procedure to notify the network that non-SDT data has arrived.
  • Step 10 The UE may transmit an RRC Resume Request message to the NG-RAN again from the cell where it currently resides. At this time, the terminal may generate a Resume MAC-I based on the value of KRRCint_1 obtained in Step 1. In addition, the UE may include the Resume MAC-I in the second RRC Resume Request message and transmit it to the New NG-RAN.
  • the terminal may derive KgNB * 2 by performing Horizontal Key derivation based on the value of KgNB * 1. Through this, the terminal can calculate new KRRCint_2, KRRCenc_2, KUPenc_2 (Optional), and KUPint_2 (Optional) values.
  • Step 11 Upon receiving the second RRC Resume Request message from the UE, the New NG-RAN can check whether the UE context for the corresponding UE can be found based on the I-RNTI. If it fails to find the UE context through the I-RNTI, the old NG-RAN can be specified based on the I-RNTI. In addition, the new NG-RAN may transmit a RETRIEVE UE CONTEXT REQUEST message to the old NG-RAN in order to receive the UE context from the corresponding node (ie, the old NG-RAN). In this process, the New NG-RAN may allocate the New NG-RAN UE XnAP ID_2 to generate a UE-associated Xn connection and transmit the same to the old NG-RAN.
  • Step 12 The Old NG-RAN can check whether the UE context for the corresponding UE can be found based on the I-RNTI. If the corresponding UE context can be found, it can be checked whether the Resume MAC-I sent by the UE is valid.
  • the Old NG-RAN can derive KgNB*2 from KgNB*1 included in the UE context through horizontal key derivation when verification of the corresponding UE passes.
  • Old NG-RAN can use KRRCint_1, not KRRCint_0 used in Step 3, in the process of verifying the Resume MAC-I sent by the corresponding UE.
  • Step 13 When the old NG-RAN decides to transfer the UE context for the corresponding terminal to the new NG-RAN after the verification of the corresponding terminal is completed, the old NG-RAN sends a RETRIEVE UE CONTEXT FAILURE message to the new NG-RAN. may respond to RAN.
  • the old NG-RAN may include the security key KgNB*2 obtained in Step 12 and the NCC value together in the message and transmit the message to the new NG-RAN.
  • New NG-RAN may perform the following operations by receiving a new security key:
  • the node serving the UE has become a New NG-RAN, and the trigger of the UE Context Release procedure toward the Old NG-RAN
  • Step 4 Received through the Step 4 process and can continue to use the UE context that was being used for SDT transmission
  • the old NG-RAN performs the following operations can be done
  • the old NG-RAN may also include the New NG-RAN UE XnAP ID_1 allocated by the New NG-RAN in step 2 in the RETRIEVE UE CONTEXT FAILURE message. Based on this, the New NG-RAN can find the UE context that was being used for SDT transmission after receiving it in Step 4 and can continue to use it.
  • the New NG-RAN can fail to find the UE context through New NG-RAN UE XnAP ID_1, it can inform the old NG-RAN through a new cause value related to it. In this case, the old NG-RAN may start a procedure for delivering the UE context to the new NG-RAN again.
  • New NG-RAN may calculate new KRRCint_2, KRRCenc_2, KUPenc_2 (Optional), and KUPint_2 (Optional) values based on the received KgNB*2.
  • a new XnAP message may be defined and used instead of the RETRIEVE UE CONTEXT FAILURE message.
  • the RETRIEVE UE CONTEXT RESPONSE message may be used instead of the RETRIEVE UE CONTEXT FAILURE message.
  • the corresponding PDU session was released, but the Step When the corresponding PDU Session is included again in the UE context transmitted in step 13)
  • the outdated UE context stored in the old NG-RAN is delivered to the new NG-RAN.
  • the old NG-RAN adds a new indication in the RETRIEVE UE CONTEXT RESPONSE message so that the new NG-RAN ignores other Mandatory IEs except for the IE related to the security key among several mandatory IEs in the RETRIEVE UE CONTEXT RESPONSE message. You may.
  • New NG-RAN consists of CU-CP, CU-UP, and DU
  • CU-CP of New NG-RAN includes new KRRCint_2, KRRCenc_2, KUPenc_2 (Optional), and KUPint_2 based on KgNB*2.
  • KRRCint_2, KRRCenc_2, KUPenc_2 Optional
  • KUPint_2 based on KgNB*2.
  • a value can be calculated.
  • E1AP message e.g., BEARER CONTEXT SETUP REQUEST, BEARER CONTEXT MODIFICATION REQUEST, or New message
  • the CU-UP of the New NG-RAN can be notified of the change of the UP security key.
  • the CU-CP of the New NG-RAN may also inform the CU-UP of the New NG-RAN that the PDCP related to the SDT Bearer should not initialize the COUNT value.
  • the New NG-RAN can exchange the SDT data whose transmission is stopped in step 13 with the terminal again after transitioning the corresponding terminal to the RRC_CONNECTED state.
  • the CU-CP of the New NG-RAN may use the UE Context used in the SDT transmission process as it is.
  • the CU-CP of the New NG-RAN may send a UE CONTEXT MODIFICATION REQUEST message to the DU of the New NG-RAN to request setup for a Non-SDT bearer (e.g., Bearer configuration, F1 UL TEIDs).
  • a Non-SDT bearer e.g., Bearer configuration, F1 UL TEIDs.
  • the CU-CP of the New NG-RAN may deliver the old gNB-DU UE F1AP ID set by the DU of the New NG-RAN together.
  • the DU of the New NG-RAN can know that the UE is attempting to set up a non-SDT bearer in addition to the SDT bearer. Through this, the DU of the New NG-RAN can utilize information such as SDT bearer and CG configuration configured for the corresponding UE as it is.
  • the DU of the New NG-RAN can inform the CU of the New NG-RAN through a new cause value related to it.
  • the CU of the New NG-RAN may start a procedure for creating a new UE context again in the DU of the New NG-RAN.
  • Step 14 New NG-RAN may generate and transmit an RRC Resume message to the UE to transition the UE to the RRC_CONNECTED state.
  • New NG-RAN can encrypt the RRC Resume message using KgNB*2 received in Step 13. Then, the UE can decrypt the corresponding RRC message based on KgNB*2 calculated in Step 10.
  • Step 15 The New NG-RAN may request a release for the UE by sending a UE Context Release message to the Old NG-RAN. Upon receiving this, the old NG-RAN may delete all contexts related to the UE and release the allocated resources.
  • 8A and 8B show signal flow diagrams according to a second example of the first example of the disclosure of this specification.
  • FIGS. 8A and 8B show an example of a procedure for supporting non-SDT data transmission in an ongoing SDT procedure with anchor relocation.
  • the UE may inform the old NG-RAN of the fact that data to be transmitted has occurred through the Non-SDT bearer. Then, after the old NG-RAN proceeds with the verification for the corresponding terminal, it can deliver the fact that the verification has passed to the new NG-RAN.
  • the new NG-RAN may generate a new security key to be used for the corresponding UE through horizontal key derivation. Basically, it is assumed that the UE context is transferred to the New NG-RAN in the SDT process.
  • both the New NG-RAN and the Old NG-RAN are not separated into CU-CP, CU-UP, and DU, but this is only an example, and The contents can also be applied when the New NG-RAN and/or the Old NG-RAN are separated into CU-CP, CU-UP, and DU.
  • Step 0 to Step 11 It may be performed in the same manner as Step 0 to Step 11 of the example of FIGS. 7A and 7B.
  • Step 12 The Old NG-RAN can check whether the UE context for the corresponding UE can be found based on the I-RNTI. If the corresponding UE context can be found, it can be checked whether the Resume MAC-I sent by the UE is valid.
  • Old NG-RAN can use KRRCint_1, not KRRCint_0 used in Step 3, in the process of verifying the Resume MAC-I sent by the corresponding UE.
  • Step 13 When the old NG-RAN decides to transfer the UE context for the corresponding terminal to the new NG-RAN after the verification of the corresponding terminal is completed, the old NG-RAN sends a RETRIEVE UE CONTEXT FAILURE message to the new NG-RAN. may respond to RAN.
  • the old NG-RAN may include a “Non-SDT data arrival” indication in the message and deliver it to the new NG-RAN.
  • New NG-RAN may perform the following operations by receiving a new indication:
  • the node serving the UE has become a New NG-RAN, and the trigger of the UE Context Release procedure toward the Old NG-RAN
  • Steps 4-8) Horizontal key derivation should be performed based on the KgNB*1 used in the Ongoing SDT session (i.e., Steps 4-8), through which a new security key KgNB*2 can be obtained.
  • Step 4 Received through the Step 4 process and can continue to use the UE context that was being used for SDT transmission
  • the old NG-RAN performs the following operations can be done
  • the old NG-RAN may also include the New NG-RAN UE XnAP ID_1 allocated by the New NG-RAN in step 2 in the RETRIEVE UE CONTEXT FAILURE message. Based on this, the New NG-RAN can find the UE context that was being used for SDT transmission after receiving it in Step 4 and can continue to use it.
  • the New NG-RAN fails to find the UE context through the New NG-RAN UE XnAP ID_1, it can inform the old NG-RAN through a new cause value related to it. In this case, the old NG-RAN may start a procedure for delivering the UE context to the new NG-RAN again.
  • New NG-RAN can calculate new KRRCint_2, KRRCenc_2, KUPenc_2 (Optional), and KUPint_2 (Optional) values based on KgNB*2 newly obtained through horizontal key derivation.
  • a new XnAP message may be defined and used instead of the RETRIEVE UE CONTEXT FAILURE message.
  • the RETRIEVE UE CONTEXT RESPONSE message may be used instead of the RETRIEVE UE CONTEXT FAILURE message.
  • the corresponding PDU session was released, but the Step When the corresponding PDU Session is included again in the UE context transmitted in step 13)
  • the outdated UE context stored in the old NG-RAN is delivered to the new NG-RAN.
  • the new NG-RAN ignores other mandatory IEs or ignores all mandatory IEs except for the security key-related IE among several mandatory IEs in the RETRIEVE UE CONTEXT RESPONSE message. New indications can also be added to the message.
  • New NG-RAN consists of CU-CP, CU-UP, and DU
  • CU-CP of New NG-RAN includes new KRRCint_2, KRRCenc_2, KUPenc_2 (Optional), and KUPint_2 based on KgNB*2.
  • KRRCint_2, KRRCenc_2, KUPenc_2 Optional
  • KUPint_2 based on KgNB*2.
  • a value can be calculated.
  • E1AP message e.g., BEARER CONTEXT SETUP REQUEST, BEARER CONTEXT MODIFICATION REQUEST, or New message
  • the CU-UP of the New NG-RAN can be notified of the change of the UP security key.
  • the CU-CP of the New NG-RAN may also inform the CU-UP of the New NG-RAN that the PDCP related to the SDT Bearer should not initialize the COUNT value.
  • the New NG-RAN can exchange the SDT data whose transmission was stopped in step 13 with the UE again after transitioning the corresponding UE to the RRC_CONNECTED state.
  • the CU-CP of the New NG-RAN may use the UE Context used in the SDT transmission process as it is.
  • the CU-CP of the New NG-RAN may send a UE CONTEXT MODIFICATION REQUEST message to the DU of the New NG-RAN to request setup for a Non-SDT bearer (e.g., Bearer configuration, F1 UL TEIDs).
  • a Non-SDT bearer e.g., Bearer configuration, F1 UL TEIDs.
  • the CU-CP of the New NG-RAN may deliver the old gNB-DU UE F1AP ID set by the DU of the New NG-RAN together.
  • the DU of the New NG-RAN can know that the UE is attempting to set up a non-SDT bearer in addition to the SDT bearer. Through this, the DU of the New NG-RAN can utilize information such as SDT bearer and CG configuration configured for the corresponding UE as it is.
  • the DU of the New NG-RAN can inform the CU of the New NG-RAN through a new cause value related to it.
  • the CU of the New NG-RAN may start a procedure for creating a new UE context again in the DU of the New NG-RAN.
  • Step 14 to Step 15 It may be performed in the same manner as Step 14 to Step 15 of the example of FIGS. 7A and 7B.
  • 9A and 9B show signal flow diagrams according to a third example of the first example of the disclosure of this specification.
  • FIGS. 9A and 9B show an example of a procedure for supporting non-SDT data transmission in an ongoing SDT procedure with anchor relocation.
  • a method is proposed in which the old NG-RAN delivers the I-RNTI value currently allocated to the UE together with the UE context to the new NG-RAN during the SDT process for the UE. Therefore, when the UE transmits the second RRC Resume Request message, Resume MAC-I verification may be performed in the new NG-RAN rather than the old NG-RAN.
  • the UE context is transferred to the New NG-RAN during the SDT process.
  • both the New NG-RAN and the Old NG-RAN are not separated into CU-CP, CU-UP, and DU, but it is applicable when they are separated into CU-CP, CU-UP, and DU.
  • Step 0 to Step 3 It may be performed in the same manner as Step 0 to Step 3 of the example of FIGS. 7A and 7B.
  • Step 4 After the old NG-RAN completes verification of the corresponding UE, the old NG-RAN may decide to transfer the UE context for the corresponding UE to the new NG-RAN. Then, the old NG-RAN may respond to the new NG-RAN through a RETRIEVE UE CONTEXT RESPONSE message. In this process, the old NG-RAN may include the I-RNTI value allocated by the old NG-RAN for the corresponding UE in a message and transmit it to the new NG-RAN.
  • the New NG-RAN When the New NG-RAN receives the I-RNTI value, it can store it in the UE context. In addition, the New NG-RAN may inform the Old NG-RAN that the UE Context Release procedure should be started as soon as the Path Switch Request procedure is finished.
  • two I-RNTI values may be pre-allocated when the old NG-RAN transitions the UE to the RRC_INACTIVE state in Step 0.
  • the Old NG-RAN may include two I-RNTI values in the RRC Release message and deliver it to the UE.
  • the terminal may include the 1st I-RNTI in the message in the process of transmitting the 1st RRC Resume Request message in Step 1.
  • the Old NG-RAN can transmit the second I-RNTI value to the RETRIEVE UE CONTEXT RESPONSE message to the New NG-RAN in Step 4 if the verification for the corresponding UE succeeds in Step 3.
  • the UE may include the I-RNTI value not used in Step 1 (ie, the 2nd I-RNTI) in the 2nd RRC Resume Request message and transmit it to the network.
  • the new NG-RAN can find the UE context by comparing the I-RNTI value received from the old NG-RAN in Step 4 with the I-RNTI value received from the UE in Step 11.
  • Step 5 to Step 8 It may be performed in the same manner as Step 5 to Step 8 of the example of FIGS. 7A and 7B.
  • Step 9 The New NG-RAN may request a release for the corresponding UE by transmitting a UE Context Release message to the Old NG-RAN. Upon receiving this, the old NG-RAN may delete all contexts related to the UE and release the allocated resources.
  • Step 10 It may be performed in the same manner as Step 9 of the example of FIGS. 7A and 7B.
  • Step 11 It may be performed in the same manner as Step 10 of the example of FIGS. 7A and 7B.
  • the UE may derive KgNB * 2 by performing Horizontal Key derivation or Vertical Key derivation based on the KgNB * 1 value. Through this, the terminal can calculate new KRRCint_2, KRRCenc_2, KUPenc_2 (Optional), and KUPint_2 (Optional) values.
  • Step 12 New NG-RAN may receive the second RRC Resume Request message from the UE. Then, the New NG-RAN can know that non-SDT data has arrived for the corresponding UE, and a state transition to RRC_CONNECTED is required to transmit it. Therefore, the New NG-RAN can stop transmitting SDT data for the corresponding UE and check whether the UE context for the corresponding UE can be found. That is, the New NG-RAN compares the I-RNTI value received from the old NG-RAN in Step 4 with the I-RNTI sent by the UE, and the UE used in the ongoing SDT session (ie Steps 4 to 8) in the New NG-RAN context can be found. Afterwards, the New NG-RAN can check whether the Resume MAC-I sent by the UE is valid.
  • New NG-RAN can derive KgNB*2 from KgNB*1 included in the UE context through horizontal vertical key derivation or vertical key derivation if verification of the corresponding UE passes. Also, New NG-RAN may calculate new KRRCint_2, KRRCenc_2, KUPenc_2 (Optional), and KUPint_2 (Optional) values based on KgNB*2.
  • the New NG-RAN may generate and transmit an RRC Resume message to the UE in order to transition the UE to the RRC_CONNECTED state.
  • New NG-RAN encrypts the RRC Resume message using KgNB*2 derived above, and the UE can decrypt the RRC message based on KgNB*2 calculated in Step 11.
  • New NG-RAN consists of CU-CP, CU-UP, and DU
  • CU-CP of New NG-RAN includes new KRRCint_2, KRRCenc_2, KUPenc_2 (Optional), and KUPint_2 based on KgNB*2.
  • KRRCint_2, KRRCenc_2, KUPenc_2 Optional
  • KUPint_2 based on KgNB*2.
  • a value can be calculated.
  • E1AP message e.g., BEARER CONTEXT SETUP REQUEST, BEARER CONTEXT MODIFICATION REQUEST, or New message
  • the CU-UP of the New NG-RAN can be notified of the change of the UP security key.
  • the CU-CP of the New NG-RAN may also inform the CU-UP of the New NG-RAN that the PDCP related to the SDT Bearer should not initialize the COUNT value.
  • the New NG-RAN can exchange the SDT data whose transmission was stopped in step 12 with the terminal again after transitioning the corresponding terminal to the RRC_CONNECTED state.
  • the CU-CP of the New NG-RAN may use the UE Context used in the SDT transmission process as it is.
  • the CU-CP of the New NG-RAN may send a UE CONTEXT MODIFICATION REQUEST message to the DU of the New NG-RAN to request setup for a Non-SDT bearer (e.g., Bearer configuration, F1 UL TEIDs).
  • a Non-SDT bearer e.g., Bearer configuration, F1 UL TEIDs.
  • the CU-CP of the New NG-RAN may deliver the old gNB-DU UE F1AP ID set by the DU of the New NG-RAN together.
  • the DU of the New NG-RAN can know that the UE is attempting to set up a non-SDT bearer in addition to the SDT bearer. Through this, the DU of the New NG-RAN can utilize information such as SDT bearer and CG configuration configured for the corresponding UE as it is.
  • the DU of the New NG-RAN can inform the CU of the New NG-RAN through a new cause value related to it.
  • the CU of the New NG-RAN may start a procedure for creating a new UE context again in the DU of the New NG-RAN.
  • a second example of the disclosure herein describes an example related to an SDT procedure that does not use anchor relocation.
  • 10A and 10B show signal flow diagrams according to a second example of the disclosure of this specification.
  • FIGS. 10A and 10B show an example of a procedure for supporting non-SDT data transmission in an ongoing SDT procedure without anchor relocation.
  • FIGS. 10A and 10B show an example of a procedure for supporting non-SDT data transmission in an ongoing SDT procedure without anchor relocation.
  • the UE may inform the old NG-RAN of the fact that data to be transmitted has occurred through the Non-SDT bearer. Then, the old NG-RAN can generate a new security key after verifying the corresponding terminal and deliver it to the new NG-RAN. Basically, it is assumed that only some UE contexts are transferred to the New NG-RAN during the SDT process.
  • both the New NG-RAN and the Old NG-RAN are not separated into CU-CP, CU-UP, and DU, but this is only an example, and The contents can also be applied when the New NG-RAN and/or the Old NG-RAN are separated into CU-CP, CU-UP, and DU.
  • Step 0 to Step 3 It may be performed in the same manner as Step 0 to Step 3 of the example of FIGS. 7A and 7B.
  • Step 4 After the old NG-RAN verifies the corresponding UE, the old NG-RAN may decide to still maintain the UE context for the corresponding UE. Then, the old NG-RAN may transmit a PARTIAL UE CONTEXT TRANSFER message to the new NG-RAN.
  • the corresponding XnAP message includes some UE context (ie, RLC layer configuration for SDT bearer, DRB ID, UL TNL Address Information, etc.) necessary for the new NG-RAN to support SDT for the UE.
  • Step 5 It may be performed in the same manner as Step 5 of the example of FIGS. 7A and 7B.
  • Step 6 New NG-RAN may respond to the UE through Msg B or Msg 4. If there is DL data to be delivered to the UE in this process, the New NG-RAN can multiplex the DL data together with the RRC message and transmit it.
  • the UE and 5GC can exchange SDT data through the New NG-RAN.
  • Step 7 It may be performed in the same manner as Step 9 of the example of FIGS. 7A and 7B.
  • Step 8 It may be performed in the same manner as Step 10 of the example of FIGS. 7A and 7B.
  • Step 9 It may be performed in the same manner as Step 11 of the example of FIGS. 7A and 7B.
  • Step 10 It may be performed in the same manner as Step 12 of the example of FIGS. 7A and 7B.
  • Step 11 If the old NG-RAN decides to transfer the UE context for the corresponding terminal to the new NG-RAN after the verification of the corresponding terminal is completed, the old NG-RAN sends a RETRIEVE UE CONTEXT RESPONSE message to the new NG-RAN. may respond to RAN. At this time, the old NG-RAN may include the security key KgNB*2 obtained in Step 10 and the NCC value together in the message and transmit the message to the new NG-RAN.
  • the old NG-RAN In the process of transitioning the UE to RRC_CONNECTED and supporting transmission of non-SDT data, in order for the new NG-RAN to continue to use the UE context related to the SDT bearer received in Step 4, the old NG-RAN You can perform the following actions.
  • the old NG-RAN may also include the New NG-RAN UE XnAP ID_1 allocated by the New NG-RAN in step 2 in the RETRIEVE UE CONTEXT RESPONSE message. Based on this, the New NG-RAN can find the UE context that was being used for SDT transmission after receiving it in Step 4 and can continue to use it.
  • the new NG-RAN can know that non-SDT data has occurred for the corresponding UE, and thus can stop SDT transmission for the corresponding UE.
  • New NG-RAN may fail to find UE context related to SDT bearer through New NG-RAN UE XnAP ID_1. In this case, the New NG-RAN may recreate the UE context for the SDT bearer by utilizing the UE context included in the RETRIEVE UE CONTEXT RESPONSE message.
  • New NG-RAN may calculate new KRRCint_2, KRRCenc_2, KUPenc_2 (Optional), and KUPint_2 (Optional) values based on the received KgNB*2.
  • the CU-CP of the Old NG-RAN can also inform the CU-UP of the New NG-RAN through the CU-CP of the New NG-RAN that the PDCP related to the SDT Bearer should not initialize the COUNT value in Step 11. .
  • the New NG-RAN can exchange the SDT data whose transmission was stopped in step 11 with the terminal again after transitioning the corresponding terminal to the RRC_CONNECTED state.
  • the CU-CP of the New NG-RAN may use the UE Context used in the SDT transmission process as it is.
  • the CU-CP of the New NG-RAN may send a UE CONTEXT MODIFICATION REQUEST message to the DU of the New NG-RAN to request setup for a Non-SDT bearer (e.g., Bearer configuration, F1 UL TEIDs).
  • a Non-SDT bearer e.g., Bearer configuration, F1 UL TEIDs.
  • the CU-CP of the New NG-RAN may deliver the old gNB-DU UE F1AP ID set by the DU of the New NG-RAN together.
  • the DU of the New NG-RAN can know that the UE is attempting to set up a non-SDT bearer in addition to the SDT bearer. Through this, the DU of the New NG-RAN can utilize information such as SDT bearer and CG configuration configured for the corresponding UE as it is.
  • the DU of the New NG-RAN can inform the CU of the New NG-RAN through a new cause value related to it.
  • the CU of the New NG-RAN may start a procedure for creating a new UE context again in the DU of the New NG-RAN.
  • the RETRIEVE UE CONTEXT RESPONSE message transmitted in step 11 may be a response to the RETRIEVE UE CONTEXT REQUEST message transmitted in step 2.
  • New NG-RAN UE XnAP ID_2 instead of New NG-RAN UE XnAP ID_1 of Old NG-RAN may be additionally included in the RETRIEVE UE CONTEXT RESPONSE message.
  • Step 12 New NG-RAN may generate and transmit an RRC Resume message to the UE to transition the UE to the RRC_CONNECTED state.
  • New NG-RAN can encrypt the RRC Resume message using KgNB*2 received in Step 11. Then, the UE can decrypt the corresponding RRC message based on KgNB*2 calculated in Step 8.
  • Step 13 The New NG-RAN may request a release for the UE by sending a UE Context Release message to the Old NG-RAN. Upon receiving this, the old NG-RAN may delete all contexts related to the UE and release the allocated resources.
  • the third example of the disclosure of this specification may be an example to which various examples described in the above-described first and/or second examples of the disclosure of this specification are specifically applied.
  • the UE may stop the ongoing SDT session and then start a procedure for indicating this non-SDT data arrival to the network.
  • One of the solutions to support this is for the UE to send a second RRCResumeRequest message using the I-RNTI issued by the previous anchor gNB and perform horizontal key derivation.
  • An example of a flowchart related to this procedure is the same as the example of FIGS. 6A and 6B described above.
  • node previously anchor gNB or serving gNB
  • the serving gNB When receiving the second RRCResumeRequest message in an SDT without anchor relocation (e.g., Random Access Channel (RACH) based SDT (RA-SDT)), the serving gNB did not find an I-RNTI based UE context. Therefore, the serving gNB can check the node ID included in the I-RNTI and initiate a Retrieve UE Context procedure to request the previous anchor gNB to provide the UE context. Therefore, in this case, the existing anchor gNB can perform ResumeMAC-I verification and key derivation.
  • RACH Random Access Channel
  • both gNBs may temporarily have the full UE context.
  • the serving gNB may not be able to find the UE context based on the I-RNTI included in the second RRCResumeRequest message. Therefore, as in RA-SDT without anchor relocation, the serving gNB can initiate the Retrieve UE Context procedure.
  • the old anchor gNB can then perform ResumeMAC-I verification and key derivation.
  • the I-RNTI allocated by the original anchor gNB must be provided to the serving gNB during the SDT procedure, so the same I-RNTI can be reused in two different gNBs. On the other hand, such reuse may be avoided.
  • Proposal 1 The former anchor gNB shall process the second RRCResumeRequest message and then perform ResumeMAC-I verification and key derivation.
  • the UE can send a second RRCResumeRequest message with an updated security key before contention resolution of the first RRCResumeRequest message for SDT is completed. If the first RRCResumeRequest message is lost but the second message can be sent to the old anchor gNB, the old anchor gNB does not know which security key (i.e. KRRCint_0 or KRRCint_1) was used to verify the ResumeMAC-I in the second RRCResumeRequest message. .
  • KRRCint_0 or KRRCint_1 was used to verify the ResumeMAC-I in the second RRCResumeRequest message.
  • One possible solution to avoid this problem is for the UE to include an explicit indication to distinguish the second RRCResumeRequest message. However, this may affect the specification from an RRC point of view. Another solution is for the former anchor gNB to perform ResumeMAC-I verification twice based on each security key. This can be implemented without affecting the specification. From a gNB point of view,
  • Proposal 2 No explicit indication sent by the UE to distinguish the second RRRCResumeRequest message from the gNB point of view is provided.
  • the old anchor gNB MUST keep the UE context to check the ResumeMAC-I when receiving the second RRCResumeRequest message. Therefore, the serving gNB must keep initiating the UE context release procedure towards the previous anchor gNB during the ongoing SDT session. This may be reflected in future specification updates.
  • the previous anchor gNB when receiving the second RRCResumeRequest message notifying non-SDT data arrival, the previous anchor gNB derives a new security key KgNB*2 after verifying ResumeMAC-I and provides the derived security key to the serving gNB.
  • KgNB*2 the security key
  • how to notify the serving gNB of successful verification of ResumeMAC-I and provide an updated security key should be discussed.
  • One of the solutions is to use the RETRIEVE UE CONTEXT RESPONSE message to provide the updated security key to the serving gNB.
  • the UE context is already sent to the serving gNB during the ongoing SDT procedure. The serving gNB may then change some parameters in the UE context during the path switching request procedure.
  • the old anchor gNB retransmits the RETRIEVE UE CONTEXT RESPONSE message with the UE context included, some IEs in the UE context may be outdated.
  • the serving gNB upon receiving the RETRIEVE UE CONTEXT RESPONSE message, the serving gNB must initiate a path switching request procedure toward 5GC. However, in this scenario, this step has to be skipped because the serving gNB has already established UE-related signaling connections for 5GC and switched UP paths. Therefore, it may not be reasonable to use a RETRIEVE UE CONTEXT RESPONSE message to provide an updated security key to the serving gNB.
  • Another solution is to include the updated security key in the RETRIEVE UE CONTEXT FAILURE message. Based on this information, the serving gNB can consider that non-SDT data has arrived at the UE and ResumeMAC-I has been successfully verified. The serving gNB can then calculate the UP and CP keys based on the previous anchor gNB's security key KgNB*2. In this case, there is no need to initiate a path divert request procedure.
  • the old anchor gNB In addition, in order for the serving gNB to continue to use the UE context provided in the ongoing SDT procedure, the old anchor gNB must provide the old UE. This is the XnAP ID assigned by the serving gNB during the ongoing SDT procedure.
  • the previous anchor gNB must transmit the previous UE XnAP ID assigned by the serving gNB during the ongoing SDT procedure.
  • Proposal 3 From a RAN3 point of view, a CCCH solution is feasible.
  • Proposal 4 If a CCCH solution is adopted for non-SDT data arrival, how to support the CCCH solution can be further discussed.
  • Proposal 1 The former anchor gNB shall process the second RRCResumeRequest message and then perform ResumeMAC-I verification and key derivation.
  • Proposal 2 No explicit indication sent by the UE to distinguish the second RRRCResumeRequest message from the gNB point of view is provided.
  • Proposal 3 From a RAN3 point of view, a CCCH solution is feasible.
  • Proposal 4 If a CCCH solution is adopted for non-SDT data arrival, how to support the CCCH solution can be further discussed.
  • the fourth example of the disclosure of this specification is the operation of the UE, which can be applied to at least one example of the first example, the second example, and/or the third example of the disclosure of the present specification described through various examples above.
  • An example, an example of operation of New NG-RAN, an example of operation of old NG-RAN, and an example of operation of 5GC (eg, SMF, AMF, and/or UPF) may be shown.
  • the operation described in the example of FIG. 11 is only an example, and within the scope of the disclosure of this specification, the operation of the UE, New NG-RAN, Old NG-RAN, 5GC, etc. is not limited by the example of FIG. 11 don't
  • the UE, New NG-RAN, Old NG-RAN, 5GC, etc. are the operations described in the first example, second example, and/or third example of the disclosure of this specification. can perform them.
  • the UE, New NG-RAN, Old NG-RAN, 5GC, etc. are the examples of FIGS. 6A and 6B, the examples of FIGS. 7A and 7B, and FIGS. 8A and 6B. Operations described in the examples of FIG. 8B , the examples of FIGS. 9A and 9B , and/or the examples of FIGS. 10A and 10B may be performed.
  • FIG. 11 shows a signal flow diagram according to a fourth example of the disclosure of this specification.
  • the example of FIG. 11 shows an example of performing communication related to SDT.
  • the example of FIG. 11 shows an example of an operation for supporting transmission of non-SDT data in a situation where an SDT procedure is in progress.
  • New NG-RAN may mean a New gNB and a serving gNB.
  • Old NG-RAN may mean Old gNB and Last serving gNB.
  • step S1101 may be an operation performed after non-SDT data is generated in the UE in a situation where an SDT procedure is in progress.
  • steps 1 to 14 of the example of FIGS. 6A and 6B may be performed before step S1101 is performed.
  • steps 1 to 9 of the example of FIGS. 7A and 7B may be performed before step S1101 is performed.
  • steps 1 to 9 of the example of FIGS. 8A and 8B may be performed before step S1101 is performed.
  • steps 1 to 10 of the example of FIGS. 9A and 9B may be performed before step S1101 is performed.
  • steps 1 to 7 of the example of FIGS. 10A and 10B may be performed before step S1101 is performed.
  • step S1101 the UE may transmit an RRC Resume Request message to the New NG-RAN.
  • the new NG-RAN may transmit a request message to the old NG-RAN.
  • the request message may include the UE XnAP ID and I-RNTI.
  • the Old NG-RAN can verify UE based on I-RNTI. For example, the Old NG-RAN may find the UE context of the UE based on the I-RNTI. The Old NG-RAN may check whether the Resume MAC-I transmitted by the UE is valid. And, the Old NG-RAN may derive a security key KgNB*2 from KgNB*1 included in the UE context through horizontal key derivation.
  • the old NG-RAN may transmit a response message to the new NG-RAN.
  • the response message may include the UE XnAP ID previously allocated by New NG-RAN.
  • the New NG-RAN can know that non-SDT data has occurred by receiving the UE XnAP ID it has allocated. And, the New NG-RAN may stop SDT transmission to the UE.
  • the response message may include, for example, the security key KgNB*2.
  • steps S1102 and S1103 may not be performed.
  • New NG-RAN may perform verification of the UE.
  • New NG-RAN may transmit an RRC message to the UE.
  • the New NG-RAN may encrypt the RRC message using the security key KgNB*2.
  • the request message may be a RETRIEVE UE CONTEXT REQUEST message and the response message may be a RETRIEVE UE CONTEXT FAILURE message.
  • the response message may be a RETRIEVE UE CONTEXT RESPONSE message.
  • a security key value to be used by the new NG-RAN in the RRC_CONNECTED state can be created and passed.
  • the new NG-RAN may transmit an additional indication notifying this so as not to repeat the process again.
  • the New NG-RAN in order for New NG-RAN to continue to use the UE context used in the SDT process, the New NG-RAN UE XnAP ID_1 allocated during the SDT process is delivered together so that the New NG-RAN uses it in the SDT process. It is possible to find the existing UE context.
  • the terminal in order to support non-SDT data transmission, the terminal does not establish an RRC connection again after stopping SDT transmission, and transitions to the RRC_CONNECTED state in the middle of SDT transmission to non-SDT transmission.
  • SDT data can be transmitted so that unnecessary operation of the terminal can be prevented.
  • proposing a method for changing the gNB serving the UE in the process of transitioning the UE to the RRC_CONNECTED state it is possible to help the UE transition quickly.
  • Non-SDT data occurs in a UE while SDT is in progress
  • the UE quickly transitions to the RRC_CONNECTED state to support fast transmission of non-SDT data.
  • the UE context used in the existing SDT can be continuously utilized, it is possible to prevent the new NG-RAN from repeatedly creating a UE context for the same UE and requesting an UP path change to 5GC.
  • a method for transitioning a terminal performing small data transmission in an RRC_INACTIVE state to an RRC_CONNECTED state in a mobile communication system may be proposed.
  • the terminal may transmit the RRC Resume Request message to the second wireless network once again.
  • the second wireless network may transmit an RRC Resume Request message to the first wireless network after understanding the resume MAC-I verification for the corresponding terminal. For example, if the first wireless network succeeds in verifying the corresponding terminal, the new NG-RAN UE XnAP ID allocated by the second wireless network allocated in the previous SDT process and the newly obtained security key are shared with the second wireless network.
  • the second wireless network can inform the first wireless network that the terminal should transition from the SDT in the RRC_INACTIVE state to the RRC_CONNECTED state due to the occurrence of non-SDT data.
  • the second wireless network may create a new bearer by adding it to the previously allocated UE context for the corresponding terminal, and then command the terminal to transition to the RRC-CONNECTED state through an RRC Resume message.
  • a terminal eg, UE
  • the operation of a terminal (eg, UE) described in this specification may be implemented by the devices of FIGS. 1 to 3 described above.
  • the terminal eg, UE
  • the operation of a terminal (eg, UE) described herein may be processed by one or more processors 102 or 202 .
  • the operations of the terminal described in this specification may be stored in one or more memories 104 or 204 in the form of instructions/programs (e.g. instructions, executable code) executable by one or more processors 102 or 202.
  • One or more processors (102 or 202) control one or more memories (104 or 204) and one or more transceivers (105 or 206), and execute instructions/programs stored in one or more memories (104 or 204) to execute the disclosure of this specification. It is possible to perform the operation of the terminal (eg, UE) described in
  • instructions for performing operations of a terminal (eg, UE) described in the disclosure of this specification may be stored in a non-volatile computer readable storage medium.
  • the storage medium may be included in one or more memories 104 or 204.
  • the instructions recorded in the storage medium may be executed by one or more processors 102 or 202 to perform the operation of the terminal (eg, UE) described in the disclosure of this specification.
  • the operation of the network nodes may be implemented by the device of FIGS. 1 to 3 to be described below.
  • the network node or base station may be the first device 100 or the second device 200 of FIG. 2 .
  • operations of a network node or base station described herein may be processed by one or more processors 102 or 202.
  • the operations of the terminal described in this specification may be stored in one or more memories 104 or 204 in the form of instructions/programs (e.g.
  • processors 102 or 202 control one or more memories 104 or 204 and one or more transceivers 106 or 206, and execute instructions/programs stored in one or more memories 104 or 204 to execute instructions/programs as described herein. It is possible to perform the operation of the network node or base station described above.
  • the instructions for performing the operation of the network node or base station described in the disclosure of this specification may be stored in a non-volatile (or non-transitory) computer-readable storage medium.
  • the storage medium may be included in one or more memories 104 or 204.
  • the instructions recorded in the storage medium may be executed by one or more processors 102 or 202 to perform the operation of the network node or base station described in the disclosure of this specification.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 명세서(present disclosure)의 일 개시는 제1 NG-RAN 노드가 통신을 수행하는 방법을 제공한다. 상기 방법은 RETRIEVE UE CONTEXT 요청 메시지를 제2 NG-RAN 노드로부터 수신하는 단계; 및 응답 메시지를 제2 NG-RAN 노드에게 전송하는 단계를 포함할 수 있다.

Description

SDT와 관련된 통신
본 명세서는 이동통신에 관한 것이다.
3rd generation partnership project (3GPP) long-term evolution (LTE)는 고속 패킷 통신(high-speed packet communications)을 가능하게 하는 기술이다. 사용자 비용 및 공급자 비용을 줄이고, 서비스 품질을 개선하며, 커버리지 및 시스템 용량을 확장 및 개선하는 것을 목표로 하는 것을 포함하여 LTE 목표를 위해 많은 계획이 제안되어 왔다. 3GPP LTE는 비트 당 비용 절감, 서비스 가용성 향상, 주파수 대역의 유연한 사용, 간단한 구조, 개방형 인터페이스 및 단말의 적절한 전력 소비를 상위 수준의 요구 사항(upper-level requirement)으로 요구한다.
ITU (International Telecommunication Union) 및 3GPP에서 New Radio (NR) 시스템에 대한 요구 사항 및 사양을 개발하기 위한 작업이 시작되었다. 3GPP는 긴급한 시장 요구 사항(urgent market needs)과 ITU-R (International Mobile Telecommunications) international mobile telecommunications (IMT)-2020 프로세스에서 정한 장기적인 요구 사항을 모두 충족하는 새로운 Radio Access Technology (RAT)를 적시에 성공적으로 표준화하는 데 필요한 기술 구성 요소를 식별하고 개발해야 한다. 또한, NR은 더 먼 미래에도 무선 통신에 사용할 수 있는 최소 최대 100GHz 범위의 스펙트럼 대역을 사용할 수 있어야 한다.
NR은 enhanced mobile broadband (eMBB), massive machine-type-communications (mMTC), ultra-reliable and low latency communications (URLLC) 등을 포함한 모든 사용 시나리오, 요구 사항 및 배포 시나리오를 다루는 단일 기술 프레임 워크를 목표로 한다. NR은 본질적으로 순방향 호환이 가능할 수 있다(forward compatible).
단말을 RRC INACTIVE로 유지한 상태에서, 소량의 데이터를 전송하는 Small Data Transmission (SDT)가 논의되고 있다. SDT가 진행되는 상황에서, 단말이 non-SDT bearer data를 가지고 있을 수 있다. 이 경우, 단말이 non-SDT bearer data를 네트워크로 전달하기 위해, SDT를 중단하고 RRC_CONNECTED 상태로 천이하는 과정이 시작될 수 있다. SDT 절차가 진행되는 상황에서, non-SDT 데이터의 전송을 지원하기 위한 방안이 필요하다.
일 양태에 있어서, 제1 NG-RAN 노드가 통신을 수행하는 방법을 제공한다. 상기 방법은 제1 UE XnAP ID 및 I-RNTI를 포함하는 RETRIEVE UE CONTEXT 요청 메시지를 제2 NG-RAN 노드로부터 수신하는 단계; 상기 I-RNTI에 기초하여, UE에 대한 검증을 수행하는 단계; 및 RETRIEVE UE CONTEXT 요청 메시지에 대한 응답으로, 응답 메시지를 상기 제2 NG-RAN 노드에게 전송하는 단계를 포함할 수 있다.
다른 양태에 있어서, 상기 방법을 구현하는 장치가 제공된다.
일 양태에 있어서, 제1 NG-RAN 노드가 통신을 수행하는 방법을 제공한다. 상기 방법은 UE로부터 I-RNTI를 포함하는 RRC 재개 요청 메시지를 수신하는 단계; 제1 UE XnAP ID 및 I-RNTI를 포함하는 RETRIEVE UE CONTEXT 요청 메시지를 제2 NG-RAN 노드에게 전송하는 단계;RETRIEVE UE CONTEXT 요청 메시지에 대한 응답으로, 응답 메시지를 상기 제2 NG-RAN 노드로부터 수신하는 단계; 및 상기 UE에게 RRC Resume 메시지를 전송하는 단계를 포함할 수 있다.
다른 양태에 있어서, 상기 방법을 구현하는 장치가 제공된다.
도 1은 본 명세서의 구현이 적용되는 통신 시스템의 예를 나타낸다.
도 2는 본 명세서의 구현이 적용되는 무선 장치의 예를 나타낸다.
도 3은 본 명세서의 구현이 적용되는 무선 장치의 예를 나타낸다.
도 4는 본 명세서의 구현이 적용되는 네트워크 노드의 일 예를 나타낸다.
도 5은 본 명세서의 구현이 적용되는 5G 시스템 구조(system architecture)의 예를 나타낸다.
도 6a 및 도 6b는 본 명세서의 개시의 SDT에 관련된 절차의 일 예를 나타낸다.
도 7a 및 도 7b는 본 명세서의 개시의 제1예의 제1 예시에 따른 신호 흐름도를 나타낸다.
도 8a 및 도 8b는 본 명세서의 개시의 제1예의 제2 예시에 따른 신호 흐름도를 나타낸다.
도 9a 및 도 9b는 본 명세서의 개시의 제1예의 제3 예시에 따른 신호 흐름도를 나타낸다.
도 10a 및 도 10b는 본 명세서의 개시의 제2예에 따른 신호 흐름도를 나타낸다.
도 11은 본 명세서의 개시의 제4예에 따른 신호 흐름도를 나타낸다.
다음의 기법, 장치 및 시스템은 다양한 무선 다중 접속 시스템에 적용될 수 있다. 다중 접속 시스템의 예시는 CDMA(code division multiple access) 시스템, FDMA(frequency division multiple access) 시스템, TDMA(time division multiple access) 시스템, OFDMA(orthogonal frequency division multiple access) 시스템, 시스템, SC-FDMA(single carrier frequency division multiple access) 시스템, MC-FDMA(multicarrier frequency division multiple access) 시스템을 포함한다. CDMA는 UTRA(universal terrestrial radio access) 또는 CDMA2000과 같은 무선 기술을 통해 구현될 수 있다. TDMA는 GSM(global system for mobile communications), GPRS(general packet radio service) 또는 EDGE(enhanced data rates for GSM evolution)와 같은 무선 기술을 통해 구현될 수 있다. OFDMA는 IEEE(institute of electrical and electronics engineers) 802.11(Wi-Fi), IEEE 802.16(WiMAX), IEEE 802.20, 또는 E-UTRA(evolved UTRA)와 같은 무선 기술을 통해 구현될 수 있다. UTRA는 UMTS(universal mobile telecommunications system)의 일부이다. 3GPP(3rd generation partnership project) LTE(long-term evolution)는 E-UTRA를 이용한 E-UMTS(evolved UMTS)의 일부이다. 3GPP LTE는 하향링크(DL; downlink)에서 OFDMA를, 상향링크(UL; uplink)에서 SC-FDMA를 사용한다. 3GPP LTE의 진화는 LTE-A(advanced), LTE-A Pro, 및/또는 5G NR(new radio)을 포함한다.
설명의 편의를 위해, 본 명세서의 구현은 주로 3GPP 기반 무선 통신 시스템과 관련하여 설명된다. 그러나 본 명세서의 기술적 특성은 이에 국한되지 않는다. 예를 들어, 3GPP 기반 무선 통신 시스템에 대응하는 이동 통신 시스템을 기반으로 다음과 같은 상세한 설명이 제공되지만, 3GPP 기반 무선 통신 시스템에 국한되지 않는 본 명세서의 측면은 다른 이동 통신 시스템에 적용될 수 있다.
본 명세서에서 사용된 용어와 기술 중 구체적으로 기술되지 않은 용어와 기술에 대해서는, 본 명세서 이전에 발행된 무선 통신 표준 문서를 참조할 수 있다.
본 명세서에서 “A 또는 B(A or B)”는 “오직 A”, “오직 B” 또는 “A와 B 모두”를 의미할 수 있다. 달리 표현하면, 본 명세서에서 “A 또는 B(A or B)”는 “A 및/또는 B(A and/or B)”으로 해석될 수 있다. 예를 들어, 본 명세서에서 “A, B 또는 C(A, B or C)”는 “오직 A”, “오직 B”, “오직 C”, 또는 “A, B 및 C의 임의의 모든 조합(any combination of A, B and C)”을 의미할 수 있다.
본 명세서에서 사용되는 슬래쉬(/)나 쉼표(comma)는 “및/또는(and/or)”을 의미할 수 있다. 예를 들어, “A/B”는 “A 및/또는 B”를 의미할 수 있다. 이에 따라, “A/B”는 “오직 A”, “오직 B”, 또는 “A와 B 모두”를 의미할 수 있다. 예를 들어, “A, B, C”는 “A, B 또는 C”를 의미할 수 있다.
본 명세서에서 “A 및 B의 적어도 하나(at least one of A and B)”는, “오직 A”, “오직 B” 또는 “A와 B 모두”를 의미할 수 있다. 또한, 본 명세서에서 “A 또는 B의 적어도 하나(at least one of A or B)”나 “A 및/또는 B의 적어도 하나(at least one of A and/or B)”라는 표현은 “A 및 B의 적어도 하나(at least one of A and B)”와 동일하게 해석될 수 있다.
또한, 본 명세서에서 “A, B 및 C의 적어도 하나(at least one of A, B and C)”는, “오직 A”, “오직 B”, “오직 C”, 또는 “A, B 및 C의 임의의 모든 조합(any combination of A, B and C)”을 의미할 수 있다. 또한, “A, B 또는 C의 적어도 하나(at least one of A, B or C)”나 “A, B 및/또는 C의 적어도 하나(at least one of A, B and/or C)”는 “A, B 및 C의 적어도 하나(at least one of A, B and C)”를 의미할 수 있다.
또한, 본 명세서에서 사용되는 괄호는 “예를 들어(for example)”를 의미할 수 있다. 구체적으로, “제어 정보(PDCCH)”로 표시된 경우, “제어 정보”의 일례로 “PDCCH”가 제안된 것일 수 있다. 달리 표현하면 본 명세서의 “제어 정보”는 “PDCCH”로 제한(limit)되지 않고, “PDCCH”가 “제어 정보”의 일례로 제안될 것일 수 있다. 또한, “제어 정보(즉, PDCCH)”로 표시된 경우에도, “제어 정보”의 일례로 “PDCCH”가 제안된 것일 수 있다.
본 명세서에서 하나의 도면 내에서 개별적으로 설명되는 기술적 특징은, 개별적으로 구현될 수도 있고, 동시에 구현될 수도 있다.
여기에 국한되지는 않지만, 본 명세서에서 개시된 다양한 설명, 기능, 절차, 제안, 방법 및/또는 작동 흐름도는 기기 간 무선 통신 및/또는 연결(예: 5G)이 요구되는 다양한 분야에 적용될 수 있다.
이하, 본 명세서는 도면을 참조하여 보다 상세하게 기술될 것이다. 다음의 도면 및/또는 설명에서 동일한 참조 번호는 달리 표시하지 않는 한 동일하거나 대응하는 하드웨어 블록, 소프트웨어 블록 및/또는 기능 블록을 참조할 수 있다.
첨부된 도면에서는 예시적으로 UE(User Equipment)가 도시되어 있으나, 도시된 상기 UE는 단말(Terminal), ME(Mobile Equipment), 등의 용어로 언급될 수도 있다. 또한, 상기 UE는 노트북, 휴대폰, PDA, 스마트 폰(Smart Phone), 멀티미디어 기기등과 같이 휴대 가능한 기기일 수 있거나, PC, 차량 탑재 장치와 같이 휴대 불가능한 기기일 수 있다.
이하에서, UE는 무선 통신이 가능한 무선 통신 기기(또는 무신 장치, 또는 무선 기기)의 예시로 사용된다. UE가 수행하는 동작은 무선 통신 기기에 의해 수행될 수 있다. 무선 통신 기기는 무선 장치, 무선 기기 등으로도 지칭될 수도 있다. 이하에서, AMF는 AMF 노드를 의미하고, SMF는 SMF 노드를 의미하고, UPF는 UPF 노드를 의미할 수 있다.
이하에서 사용되는 용어인 기지국은, 일반적으로 무선기기와 통신하는 고정된 지점(fixed station)을 말하며, eNodeB(evolved-NodeB), eNB(evolved-NodeB), BTS(Base Transceiver System), 액세스 포인트(Access Point), gNB(Next generation NodeB) 등 다른 용어로 불릴 수 있다.
I. 본 명세서의 개시에 적용될 수 있는 기술 및 절차
도 1은 본 명세서의 구현이 적용되는 통신 시스템의 예를 나타낸다.
도 1에 표시된 5G 사용 시나리오는 본보기일 뿐이며, 본 명세서의 기술적 특징은 도 1에 나와 있지 않은 다른 5G 사용 시나리오에 적용될 수 있다.
5G에 대한 세 가지 주요 요구사항 범주는 (1) 향상된 모바일 광대역(eMBB; enhanced mobile broadband) 범주, (2) 거대 기계 유형 통신 (mMTC; massive machine type communication) 범주 및 (3) 초고신뢰 저지연 통신 (URLLC; ultra-reliable and low latency communications) 범주이다.
부분적인 사용 예는 최적화를 위해 복수의 범주를 요구할 수 있으며, 다른 사용 예는 하나의 KPI(key performance indicator)에만 초점을 맞출 수 있다. 5G는 유연하고 신뢰할 수 있는 방법을 사용하여 이러한 다양한 사용 예를 지원한다.
eMBB는 기본적인 모바일 인터넷 접속을 훨씬 능가하며 클라우드와 증강 현실에서 풍부한 양방향 작업 및 미디어 및 엔터테인먼트 애플리케이션을 커버한다. 데이터는 5G 핵심 동력의 하나이며, 5G 시대에는 처음으로 전용 음성 서비스가 제공되지 않을 수 있다. 5G에서는 통신 시스템이 제공하는 데이터 연결을 활용한 응용 프로그램으로서 음성 처리가 단순화될 것으로 예상된다. 트래픽 증가의 주요 원인은 콘텐츠의 크기 증가와 높은 데이터 전송 속도를 요구하는 애플리케이션의 증가 때문이다. 더 많은 장치가 인터넷에 연결됨에 따라 스트리밍 서비스(오디오와 비디오), 대화 비디오, 모바일 인터넷 접속이 더 널리 사용될 것이다. 이러한 많은 응용 프로그램은 사용자를 위한 실시간 정보와 경보를 푸시(push)하기 위해 항상 켜져 있는 상태의 연결을 요구한다. 클라우드 스토리지(cloud storage)와 응용 프로그램은 모바일 통신 플랫폼에서 빠르게 증가하고 있으며 업무와 엔터테인먼트 모두에 적용될 수 있다. 클라우드 스토리지는 상향링크 데이터 전송 속도의 증가를 가속화하는 특수 활용 사례이다. 5G는 클라우드의 원격 작업에도 사용된다. 촉각 인터페이스를 사용할 때, 5G는 사용자의 양호한 경험을 유지하기 위해 훨씬 낮은 종단 간(end-to-end) 지연 시간을 요구한다. 예를 들어, 클라우드 게임 및 비디오 스트리밍과 같은 엔터테인먼트는 모바일 광대역 기능에 대한 수요를 증가시키는 또 다른 핵심 요소이다. 기차, 차량, 비행기 등 이동성이 높은 환경을 포함한 모든 장소에서 스마트폰과 태블릿은 엔터테인먼트가 필수적이다. 다른 사용 예로는 엔터테인먼트 및 정보 검색을 위한 증강 현실이다. 이 경우 증강 현실은 매우 낮은 지연 시간과 순간 데이터 볼륨을 필요로 한다.
또한 가장 기대되는 5G 사용 예 중 하나는 모든 분야에서 임베디드 센서(embedded sensor)를 원활하게 연결할 수 있는 기능, 즉 mMTC와 관련이 있다. 잠재적으로 IoT(internet-of-things) 기기 수는 2020년까지 2억4천만 대에 이를 것으로 예상된다. 산업 IoT는 5G를 통해 스마트 시티, 자산 추적, 스마트 유틸리티, 농업, 보안 인프라를 가능하게 하는 주요 역할 중 하나이다.
URLLC는 주 인프라의 원격 제어를 통해 업계를 변화시킬 새로운 서비스와 자율주행 차량 등 초고신뢰성의 저지연 링크를 포함하고 있다. 스마트 그리드를 제어하고, 산업을 자동화하며, 로봇 공학을 달성하고, 드론을 제어하고 조정하기 위해서는 신뢰성과 지연 시간이 필수적이다.
5G는 초당 수백 메가 비트로 평가된 스트리밍을 초당 기가비트에 제공하는 수단이며, FTTH(fiber-to-the-home)와 케이블 기반 광대역(또는 DOCSIS)을 보완할 수 있다. 가상 현실과 증강 현실뿐만 아니라 4K 이상(6K, 8K 이상) 해상도의 TV를 전달하려면 이 같은 빠른 속도가 필요하다. 가상 현실(VR; virtual reality) 및 증강 현실(AR; augmented reality) 애플리케이션에는 몰입도가 높은 스포츠 게임이 포함되어 있다. 특정 응용 프로그램에는 특수 네트워크 구성이 필요할 수 있다. 예를 들어, VR 게임의 경우 게임 회사는 대기 시간을 최소화하기 위해 코어 서버를 네트워크 운영자의 에지 네트워크 서버에 통합해야 한다.
자동차는 차량용 이동 통신의 많은 사용 예와 함께 5G에서 새로운 중요한 동기 부여의 힘이 될 것으로 기대된다. 예를 들어, 승객을 위한 오락은 높은 동시 용량과 이동성이 높은 광대역 이동 통신을 요구한다. 향후 이용자들이 위치와 속도에 관계 없이 고품질 연결을 계속 기대하고 있기 때문이다. 자동차 분야의 또 다른 사용 예는 AR 대시보드(dashboard)이다. AR 대시보드는 운전자가 전면 창에서 보이는 물체 외에 어두운 곳에서 물체를 식별하게 하고, 운전자에게 정보 전달을 오버랩(overlap)하여 물체와의 거리 및 물체의 움직임을 표시한다. 미래에는 무선 모듈이 차량 간의 통신, 차량과 지원 인프라 간의 정보 교환, 차량과 기타 연결된 장치(예: 보행자가 동반하는 장치) 간의 정보 교환을 가능하게 한다. 안전 시스템은 운전자가 보다 안전하게 운전할 수 있도록 행동의 대체 과정을 안내하여 사고의 위험을 낮춘다. 다음 단계는 원격으로 제어되거나 자율 주행하는 차량이 될 것이다. 이를 위해서는 서로 다른 자율주행 차량 간의, 그리고 차량과 인프라 간의 매우 높은 신뢰성과 매우 빠른 통신이 필요하다. 앞으로는 자율주행 차량이 모든 주행 활동을 수행하고 운전자는 차량이 식별할 수 없는 이상 트래픽에만 집중하게 될 것이다. 자율주행 차량의 기술 요구사항은 인간이 달성할 수 없는 수준으로 교통 안전이 높아지도록 초저지연과 초고신뢰를 요구한다.
스마트 사회로 언급된 스마트 시티와 스마트 홈/빌딩이 고밀도 무선 센서 네트워크에 내장될 것이다. 지능형 센서의 분산 네트워크는 도시 또는 주택의 비용 및 에너지 효율적인 유지 보수에 대한 조건을 식별할 것이다. 각 가정에 대해서도 유사한 구성을 수행할 수 있다. 모든 온도 센서, 창문과 난방 컨트롤러, 도난 경보기, 가전 제품이 무선으로 연결될 것이다. 이러한 센서 중 다수는 일반적으로 데이터 전송 속도, 전력 및 비용이 낮다. 그러나 모니터링을 위하여 실시간 HD 비디오가 특정 유형의 장치에 의해 요구될 수 있다.
열이나 가스를 포함한 에너지 소비와 분배를 보다 높은 수준으로 분산시켜 분배 센서 네트워크에 대한 자동화된 제어가 요구된다. 스마트 그리드는 디지털 정보와 통신 기술을 이용해 정보를 수집하고 센서를 서로 연결하여 수집된 정보에 따라 동작하도록 한다. 이 정보는 공급 회사 및 소비자의 행동을 포함할 수 있으므로, 스마트 그리드는 효율성, 신뢰성, 경제성, 생산 지속 가능성, 자동화 등의 방법으로 전기와 같은 연료의 분배를 개선할 수 있다. 스마트 그리드는 지연 시간이 짧은 또 다른 센서 네트워크로 간주될 수도 있다.
미션 크리티컬 애플리케이션(예: e-health)은 5G 사용 시나리오 중 하나이다. 건강 부분에는 이동 통신의 혜택을 누릴 수 있는 많은 응용 프로그램들이 포함되어 있다. 통신 시스템은 먼 곳에서 임상 치료를 제공하는 원격 진료를 지원할 수 있다. 원격 진료는 거리에 대한 장벽을 줄이고 먼 시골 지역에서 지속적으로 이용할 수 없는 의료 서비스에 대한 접근을 개선하는 데 도움이 될 수 있다. 원격 진료는 또한 응급 상황에서 중요한 치료를 수행하고 생명을 구하기 위해 사용된다. 이동 통신 기반의 무선 센서 네트워크는 심박수 및 혈압과 같은 파라미터에 대한 원격 모니터링 및 센서를 제공할 수 있다.
무선과 이동 통신은 산업 응용 분야에서 점차 중요해지고 있다. 배선은 설치 및 유지 관리 비용이 높다. 따라서 케이블을 재구성 가능한 무선 링크로 교체할 가능성은 많은 산업 분야에서 매력적인 기회이다. 그러나 이러한 교체를 달성하기 위해서는 케이블과 유사한 지연 시간, 신뢰성 및 용량을 가진 무선 연결이 구축되어야 하며 무선 연결의 관리를 단순화할 필요가 있다. 5G 연결이 필요할 때 대기 시간이 짧고 오류 가능성이 매우 낮은 것이 새로운 요구 사항이다.
물류 및 화물 추적은 위치 기반 정보 시스템을 사용하여 어디서든 인벤토리 및 패키지 추적을 가능하게 하는 이동 통신의 중요한 사용 예이다. 물류와 화물의 이용 예는 일반적으로 낮은 데이터 속도를 요구하지만 넓은 범위와 신뢰성을 갖춘 위치 정보가 필요하다.
도 1을 참조하면, 통신 시스템(1)은 무선 장치(100a~100f), 기지국(BS; 200) 및 네트워크(300)을 포함한다. 도 1은 통신 시스템(1)의 네트워크의 예로 5G 네트워크를 설명하지만, 본 명세서의 구현은 5G 시스템에 국한되지 않으며, 5G 시스템을 넘어 미래의 통신 시스템에 적용될 수 있다.
기지국(200)과 네트워크(300)는 무선 장치로 구현될 수 있으며, 특정 무선 장치는 다른 무선 장치와 관련하여 기지국/네트워크 노드로 작동할 수 있다.
무선 장치(100a~100f)는 무선 접속 기술(RAT; radio access technology) (예: 5G NR 또는 LTE)을 사용하여 통신을 수행하는 장치를 나타내며, 통신/무선/5G 장치라고도 할 수 있다. 무선 장치(100a~100f)는, 이에 국한되지 않고, 로봇(100a), 차량(100b-1 및 100b-2), 확장 현실(XR; extended reality) 장치(100c), 휴대용 장치(100d), 가전 제품(100e), IoT 장치(100f) 및 인공 지능(AI; artificial intelligence) 장치/서버(400)을 포함할 수 있다. 예를 들어, 차량에는 무선 통신 기능이 있는 차량, 자율주행 차량 및 차량 간 통신을 수행할 수 있는 차량이 포함될 수 있다. 차량에는 무인 항공기(UAV; unmanned aerial vehicle)(예: 드론)가 포함될 수 있다. XR 장치는 AR/VR/혼합 현실(MR; mixed realty) 장치를 포함할 수 있으며, 차량, 텔레비전, 스마트폰, 컴퓨터, 웨어러블 장치, 가전 제품, 디지털 표지판, 차량, 로봇 등에 장착된 HMD(head-mounted device), HUD(head-up display)의 형태로 구현될 수 있다. 휴대용 장치에는 스마트폰, 스마트 패드, 웨어러블 장치(예: 스마트 시계 또는 스마트 안경) 및 컴퓨터(예: 노트북)가 포함될 수 있다. 가전 제품에는 TV, 냉장고, 세탁기가 포함될 수 있다. IoT 장치에는 센서와 스마트 미터가 포함될 수 있다.
본 명세서에서, 무선 장치(100a~100f)는 사용자 장비(UE; user equipment)라고 부를 수 있다. UE는 예를 들어, 휴대 전화, 스마트폰, 노트북 컴퓨터, 디지털 방송 단말기, PDA(personal digital assistant), PMP(portable multimedia player), 네비게이션 시스템, 슬레이트 PC, 태블릿 PC, 울트라북, 차량, 자율주행 기능이 있는 차량, 연결된 자동차, UAV, AI 모듈, 로봇, AR 장치, VR 장치, MR 장치, 홀로그램 장치, 공공 안전 장치, MTC 장치, IoT 장치, 의료 장치, 핀테크 장치(또는 금융 장치), 보안 장치, 날씨/환경 장치, 5G 서비스 관련 장치 또는 4차 산업 혁명 관련 장치를 포함할 수 있다.
예를 들어, UAV는 사람이 탑승하지 않고 무선 제어 신호에 의해 항행되는 항공기일 수 있다.
예를 들어, VR 장치는 가상 환경의 개체 또는 배경을 구현하기 위한 장치를 포함할 수 있다. 예를 들어, AR 장치는 가상 세계의 개체나 배경을 실제 세계의 개체나 배경에 연결하여 구현한 장치를 포함할 수 있다. 예를 들어, MR 장치는 객체나 가상 세계의 배경을 객체나 실제 세계의 배경으로 병합하여 구현한 디바이스를 포함할 수 있다. 예를 들어, 홀로그램 장치는, 홀로그램이라 불리는 두 개의 레이저 조명이 만났을 때 발생하는 빛의 간섭 현상을 이용하여, 입체 정보를 기록 및 재생하여 360도 입체 영상을 구현하기 위한 장치가 포함할 수 있다.
예를 들어, 공공 안전 장치는 사용자 몸에 착용할 수 있는 이미지 중계 장치 또는 이미지 장치를 포함할 수 있다.
예를 들어, MTC 장치와 IoT 장치는 인간의 직접적인 개입이나 조작이 필요하지 않은 장치일 수 있다. 예를 들어, MTC 장치와 IoT 장치는 스마트 미터, 자동 판매기, 온도계, 스마트 전구, 도어락 또는 다양한 센서를 포함할 수 있다.
예를 들어, 의료 장치는 질병의 진단, 처리, 완화, 치료 또는 예방 목적으로 사용되는 장치일 수 있다. 예를 들어, 의료 장치는 부상이나 손상을 진단, 처리, 완화 또는 교정하기 위해 사용되는 장치일 수 있다. 예를 들어, 의료 장치는 구조나 기능을 검사, 교체 또는 수정할 목적으로 사용되는 장치일 수 있다. 예를 들어, 의료 장치는 임신 조정 목적으로 사용되는 장치일 수 있다. 예를 들어, 의료 장치는 치료용 장치, 운전용 장치, (체외)진단 장치, 보청기 또는 시술용 장치를 포함할 수 있다.
예를 들어, 보안 장치는 발생할 수 있는 위험을 방지하고 안전을 유지하기 위해 설치된 장치일 수 있다. 예를 들어, 보안 장치는 카메라, 폐쇄 회로 TV(CCTV), 녹음기 또는 블랙박스일 수 있다.
예를 들어, 핀테크 장치는 모바일 결제와 같은 금융 서비스를 제공할 수 있는 장치일 수 있다. 예를 들어, 핀테크 장치는 지불 장치 또는 POS 시스템을 포함할 수 있다.
예를 들어, 날씨/환경 장치는 날씨/환경을 모니터링 하거나 예측하는 장치를 포함할 수 있다.
무선 장치(100a~100f)는 기지국(200)을 통해 네트워크(300)와 연결될 수 있다. 무선 장치(100a~100f)에는 AI 기술이 적용될 수 있으며, 무선 장치(100a~100f)는 네트워크(300)를 통해 AI 서버(400)와 연결될 수 있다. 네트워크(300)는 3G 네트워크, 4G(예: LTE) 네트워크, 5G(예: NR) 네트워크 및 5G 이후의 네트워크 등을 이용하여 구성될 수 있다. 무선 장치(100a~100f)는 기지국(200)/네트워크(300)를 통해 서로 통신할 수도 있지만, 기지국(200)/네트워크(300)를 통하지 않고 직접 통신(예: 사이드링크 통신(sidelink communication))할 수도 있다. 예를 들어, 차량(100b-1, 100b-2)은 직접 통신(예: V2V(vehicle-to-vehicle)/V2X(vehicle-to-everything) 통신)을 할 수 있다. 또한, IoT 기기(예: 센서)는 다른 IoT 기기(예: 센서) 또는 다른 무선 장치(100a~100f)와 직접 통신을 할 수 있다.
무선 장치(100a~100f) 간 및/또는 무선 장치(100a~100f)와 기지국(200) 간 및/또는 기지국(200) 간에 무선 통신/연결(150a, 150b, 150c)이 확립될 수 있다. 여기서, 무선 통신/연결은 상향/하향링크 통신(150a), 사이드링크 통신(150b)(또는, D2D(device-to-device) 통신), 기지국 간 통신(150c)(예: 중계, IAB(integrated access and backhaul)) 등과 같이 다양한 RAT(예: 5G NR)을 통해 확립될 수 있다. 무선 통신/연결(150a, 150b, 150c)을 통해 무선 장치(100a~100f)와 기지국(200)은 서로 무선 신호를 송신/수신할 수 있다. 예를 들어, 무선 통신/연결(150a, 150b, 150c)은 다양한 물리 채널을 통해 신호를 송신/수신할 수 있다. 이를 위해, 본 명세서의 다양한 제안에 기반하여, 무선 신호의 송신/수신을 위한 다양한 구성 정보 설정 과정, 다양한 신호 처리 과정(예: 채널 인코딩/디코딩, 변조/복조, 자원 맵핑/디맵핑 등), 및 자원 할당 과정 등 중 적어도 일부가 수행될 수 있다.
AI는 인공적인 지능 또는 이를 만들 수 있는 방법론을 연구하는 분야를 의미하며, 머신 러닝(기계 학습, Machine Learning)은 인공 지능 분야에서 다루는 다양한 문제를 정의하고 그것을 해결하는 방법론을 연구하는 분야를 의미한다. 머신 러닝은 어떠한 작업에 대하여 꾸준한 경험을 통해 그 작업에 대한 성능을 높이는 알고리즘으로 정의하기도 한다.
로봇은 스스로 보유한 능력에 의해 주어진 일을 자동으로 처리하거나 작동하는 기계를 의미할 수 있다. 특히, 환경을 인식하고 스스로 판단하여 동작을 수행하는 기능을 갖는 로봇을 지능형 로봇이라 칭할 수 있다. 로봇은 사용 목적이나 분야에 따라 산업용, 의료용, 가정용, 군사용 등으로 분류할 수 있다. 로봇은 액츄에이터(actuator) 또는 모터를 포함하는 구동부를 구비하여 로봇 관절을 움직이는 등의 다양한 물리적 동작을 수행할 수 있다. 또한, 이동 가능한 로봇은 구동부에 휠, 브레이크, 프로펠러 등이 포함되어, 구동부를 통해 지상에서 주행하거나 공중에서 비행할 수 있다.
자율 주행은 스스로 주행하는 기술을 의미하며, 자율 주행 차량은 사용자의 조작 없이 또는 사용자의 최소한의 조작으로 주행하는 차량을 의미한다. 예를 들어, 자율 주행에는 주행 중인 차선을 유지하는 기술, 어댑티브 크루즈 컨트롤과 같이 속도를 자동으로 조절하는 기술, 정해진 경로를 따라 자동으로 주행하는 기술, 목적지가 설정되면 자동으로 경로를 설정하여 주행하는 기술 등이 모두 포함될 수 있다. 차량은 내연 기관만을 구비하는 차량, 내연 기관과 전기 모터를 함께 구비하는 하이브리드 차량, 그리고 전기 모터만을 구비하는 전기 차량을 모두 포괄하며, 자동차뿐만 아니라 기차, 오토바이 등을 포함할 수 있다. 자율 주행 차량은 자율 주행 기능을 가진 로봇으로 볼 수 있다.
확장 현실은 VR, AR, MR을 총칭한다. VR 기술은 현실 세계의 객체나 배경 등을 CG 영상으로만 제공하고, AR 기술은 실제 사물 영상 위에 가상으로 만들어진 CG 영상을 함께 제공하며, MR 기술은 현실 세계에 가상 객체를 섞고 결합시켜서 제공하는 CG 기술이다. MR 기술은 현실 객체와 가상 객체를 함께 보여준다는 점에서 AR 기술과 유사하다. 그러나, AR 기술에서는 가상 객체가 현실 객체를 보완하는 형태로 사용되는 반면, MR 기술에서는 가상 객체와 현실 객체가 동등한 성격으로 사용된다는 점에서 차이점이 있다.
NR은 다양한 5G 서비스를 지원하기 위한 다수의 뉴머럴로지(numerology) 또는 부반송파 간격(SCS; subcarrier spacing)을 지원한다. 예를 들어, SCS가 15kHz인 경우, 전통적인 셀룰러 밴드에서의 넓은 영역(wide area)를 지원하며, SCS가 30kHz/60kHz인 경우, 밀집한 도시(dense-urban), 저지연(lower latency) 및 더 넓은 반송파 대역폭(wider carrier bandwidth)를 지원하며, SCS가 60kHz 또는 그보다 높은 경우, 위상 잡음(phase noise)를 극복하기 위해 24.25GHz보다 큰 대역폭을 지원한다.
NR 주파수 대역은 2가지 타입(FR1, FR2)의 주파수 범위(frequency range)로 정의될 수 있다. 주파수 범위의 수치는 변경될 수 있다. 예를 들어, 2가지 타입(FR1, FR2)의 주파수 범위는 아래 표 1과 같을 수 있다. 설명의 편의를 위해, NR 시스템에서 사용되는 주파수 범위 중 FR1은 "sub 6GHz range"를 의미할 수 있고, FR2는 "above 6GHz range"를 의미할 수 있고 밀리미터 웨이브(millimeter wave, mmW)로 불릴 수 있다.
주파수 범위 정의 주파수 범위 부반송파 간격
FR1 450MHz - 6000MHz 15, 30, 60kHz
FR2 24250MHz - 52600MHz 60, 120, 240kHz
상술한 바와 같이, NR 시스템의 주파수 범위의 수치는 변경될 수 있다. 예를 들어, FR1은 아래 표 2와 같이 410MHz 내지 7125MHz의 대역을 포함할 수 있다. 즉, FR1은 6GHz (또는 5850, 5900, 5925 MHz 등) 이상의 주파수 대역을 포함할 수 있다. 예를 들어, FR1 내에서 포함되는 6GHz (또는 5850, 5900, 5925 MHz 등) 이상의 주파수 대역은 비면허 대역(unlicensed band)을 포함할 수 있다. 비면허 대역은 다양한 용도로 사용될 수 있고, 예를 들어 차량을 위한 통신(예: 자율 주행)을 위해 사용될 수 있다.
주파수 범위 정의 주파수 범위 부반송파 간격
FR1 410MHz - 7125MHz 15, 30, 60kHz
FR2 24250MHz - 52600MHz 60, 120, 240kHz
여기서, 본 명세서의 무선 장치에서 구현되는 무선 통신 기술은 LTE, NR 및 6G뿐만 아니라 저전력 통신을 위한 협대역 IoT(NB-IoT, narrowband IoT)를 포함할 수 있다. 예를 들어, NB-IoT 기술은 LPWAN(low power wide area network) 기술의 일례일 수 있고, LTE Cat NB1 및/또는 LTE Cat NB2 등의 규격으로 구현될 수 있으며, 상술한 명칭에 한정되는 것은 아니다. 추가적으로 또는 대체적으로, 본 명세서의 무선 장치에서 구현되는 무선 통신 기술은 LTE-M 기술을 기반으로 통신을 수행할 수 있다. 예를 들어, LTE-M 기술은 LPWAN 기술의 일례일 수 있고, eMTC(enhanced MTC) 등의 다양한 명칭으로 불릴 수 있다. 예를 들어, LTE-M 기술은 1) LTE CAT 0, 2) LTE Cat M1, 3) LTE Cat M2, 4) LTE non-BL(non-bandwidth limited), 5) LTE-MTC, 6) LTE MTC, 및/또는 7) LTE M 등의 다양한 규격 중 적어도 어느 하나로 구현될 수 있으며 상술한 명칭에 한정되는 것은 아니다. 추가적으로 또는 대체적으로, 본 명세서의 무선 장치에서 구현되는 무선 통신 기술은 저전력 통신을 고려한 지그비(ZigBee), 블루투스(Bluetooth) 및/또는 LPWAN 중 적어도 어느 하나를 포함할 수 있으며, 상술한 명칭에 한정되는 것은 아니다. 예를 들어, 지그비 기술은 IEEE 802.15.4 등의 다양한 규격을 기반으로 소형/저-파워 디지털 통신에 관련된 PAN(personal area networks)을 생성할 수 있으며, 다양한 명칭으로 불릴 수 있다.
도 2는 본 명세서의 구현이 적용되는 무선 장치의 예를 나타낸다.
도 2를 참조하면, 제1 무선 장치(100)와 제2 무선 장치(200)는은 다양한 RAT(예: LTE 및 NR)를 통해 외부 장치로/외부 장치로부터 무선 신호를 송수신할 수 있다.
도 2에서, {제1 무선 장치(100) 및 제2 무선 장치(200)}은(는) 도 1의 {무선 장치(100a~100f) 및 기지국(200)}, {무선 장치(100a~100f) 및 무선 장치(100a~100f)} 및/또는 {기지국(200) 및 기지국(200)} 중 적어도 하나에 대응할 수 있다.
제1 무선 장치(100)는 송수신기(106)와 같은 적어도 하나의 송수신기, 프로세싱 칩(101)과 같은 적어도 하나의 프로세싱 칩 및/또는 하나 이상의 안테나(108)를 포함할 수 있다.
프로세싱 칩(101)은 프로세서(102)와 같은 적어도 하나의 프로세서와 메모리(104)와 같은 적어도 하나의 메모리를 포함할 수 있다. 도 2에는 메모리(104)가 프로세싱 칩(101)에 포함되는 것이 본보기로 보여진다. 추가적으로 및/또는 대체적으로, 메모리(104)는 프로세싱 칩(101) 외부에 배치될 수 있다.
프로세서(102)는 메모리(104) 및/또는 송수신기(106)를 제어할 수 있으며, 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 작동 흐름도를 구현하도록 구성될 수 있다. 예를 들어, 프로세서(102)는 메모리(104) 내의 정보를 처리하여 제1 정보/신호를 생성하고, 제1 정보/신호를 포함하는 무선 신호를 송수신기(106)를 통해 전송할 수 있다. 프로세서(102)는 송수신기(106)를 통해 제2 정보/신호를 포함하는 무선 신호를 수신하고, 제2 정보/신호를 처리하여 얻은 정보를 메모리(104)에 저장할 수 있다.
메모리(104)는 프로세서(102)에 동작 가능하도록 연결될 수 있다. 메모리(104)는 다양한 유형의 정보 및/또는 명령을 저장할 수 있다. 메모리(104)는 프로세서(102)에 의해 실행될 때 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 작동 흐름도를 수행하는 명령을 구현하는 소프트웨어 코드(105)를 저장할 수 있다. 예를 들어, 소프트웨어 코드(105)는 프로세서(102)에 의해 실행될 때, 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 작동 흐름도를 수행하는 명령을 구현할 수 있다. 예를 들어, 소프트웨어 코드(105)는 하나 이상의 프로토콜을 수행하기 위해 프로세서(102)를 제어할 수 있다. 예를 들어, 소프트웨어 코드(105)는 하나 이상의 무선 인터페이스 프로토콜 계층을 수행하기 위해 프로세서(102)를 제어할 수 있다.
여기에서, 프로세서(102)와 메모리(104)는 RAT(예: LTE 또는 NR)을 구현하도록 설계된 통신 모뎀/회로/칩의 일부일 수 있다. 송수신기(106)는 프로세서(102)에 연결되어 하나 이상의 안테나(108)를 통해 무선 신호를 전송 및/또는 수신할 수 있다. 각 송수신기(106)는 송신기 및/또는 수신기를 포함할 수 있다. 송수신기(106)는 RF(radio frequency)부와 교체 가능하게 사용될 수 있다. 본 명세서에서 제1 무선 장치(100)는 통신 모뎀/회로/칩을 나타낼 수 있다.
제2 무선 장치(200)는 송수신기(206)와 같은 적어도 하나의 송수신기, 프로세싱 칩(201)과 같은 적어도 하나의 프로세싱 칩 및/또는 하나 이상의 안테나(208)를 포함할 수 있다.
프로세싱 칩(201)은 프로세서(202)와 같은 적어도 하나의 프로세서와 메모리(204)와 같은 적어도 하나의 메모리를 포함할 수 있다. 도 2에는 메모리(204)가 프로세싱 칩(201)에 포함되는 것이 본보기로 보여진다. 추가적으로 및/또는 대체적으로, 메모리(204)는 프로세싱 칩(201) 외부에 배치될 수 있다.
프로세서(202)는 메모리(204) 및/또는 송수신기(206)를 제어할 수 있으며, 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 작동 흐름도를 구현하도록 구성될 수 있다. 예를 들어, 프로세서(202)는 메모리(204) 내의 정보를 처리하여 제3 정보/신호를 생성하고, 제3 정보/신호를 포함하는 무선 신호를 송수신기(206)를 통해 전송할 수 있다. 프로세서(202)는 송수신기(206)를 통해 제4 정보/신호를 포함하는 무선 신호를 수신하고, 제4 정보/신호를 처리하여 얻은 정보를 메모리(204)에 저장할 수 있다.
메모리(204)는 프로세서(202)에 동작 가능하도록 연결될 수 있다. 메모리(204)는 다양한 유형의 정보 및/또는 명령을 저장할 수 있다. 메모리(204)는 프로세서(202)에 의해 실행될 때 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 작동 흐름도를 수행하는 명령을 구현하는 소프트웨어 코드(205)를 저장할 수 있다. 예를 들어, 소프트웨어 코드(205)는 프로세서(202)에 의해 실행될 때, 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 작동 흐름도를 수행하는 명령을 구현할 수 있다. 예를 들어, 소프트웨어 코드(205)는 하나 이상의 프로토콜을 수행하기 위해 프로세서(202)를 제어할 수 있다. 예를 들어, 소프트웨어 코드(205)는 하나 이상의 무선 인터페이스 프로토콜 계층을 수행하기 위해 프로세서(202)를 제어할 수 있다.
여기에서, 프로세서(202)와 메모리(204)는 RAT(예: LTE 또는 NR)을 구현하도록 설계된 통신 모뎀/회로/칩의 일부일 수 있다. 송수신기(206)는 프로세서(202)에 연결되어 하나 이상의 안테나(208)를 통해 무선 신호를 전송 및/또는 수신할 수 있다. 각 송수신기(206)는 송신기 및/또는 수신기를 포함할 수 있다. 송수신기(206)는 RF부와 교체 가능하게 사용될 수 있다. 본 명세서에서 제2 무선 장치(200)는 통신 모뎀/회로/칩을 나타낼 수 있다.
이하, 무선 장치(100, 200)의 하드웨어 요소에 대해 보다 구체적으로 설명한다. 이로 제한되는 것은 아니지만, 하나 이상의 프로토콜 계층이 하나 이상의 프로세서(102, 202)에 의해 구현될 수 있다. 예를 들어, 하나 이상의 프로세서(102, 202)는 하나 이상의 계층(예: PHY(physical) 계층, MAC(media access control) 계층, RLC(radio link control) 계층, PDCP(packet data convergence protocol) 계층, RRC(radio resource control) 계층, SDAP(service data adaptation protocol) 계층과 같은 기능적 계층)을 구현할 수 있다. 하나 이상의 프로세서(102, 202)는 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 동작 흐름도에 따라 하나 이상의 PDU(protocol data unit) 및/또는 하나 이상의 SDU(service data unit)를 생성할 수 있다. 하나 이상의 프로세서(102, 202)는 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 동작 흐름도에 따라 메시지, 제어 정보, 데이터 또는 정보를 생성할 수 있다. 하나 이상의 프로세서(102, 202)는 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 동작 흐름도에 따라 PDU, SDU, 메시지, 제어 정보, 데이터 또는 정보를 포함하는 신호(예: 베이스밴드 신호)를 생성하여, 하나 이상의 송수신기(106, 206)에게 제공할 수 있다. 하나 이상의 프로세서(102, 202)는 하나 이상의 송수신기(106, 206)로부터 신호(예: 베이스밴드 신호)를 수신할 수 있고, 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 동작 흐름도에 따라 PDU, SDU, 메시지, 제어 정보, 데이터 또는 정보를 획득할 수 있다.
하나 이상의 프로세서(102, 202)는 컨트롤러, 마이크로 컨트롤러, 마이크로 프로세서 및/또는 마이크로 컴퓨터로 지칭될 수 있다. 하나 이상의 프로세서(102, 202)는 하드웨어, 펌웨어, 소프트웨어, 및/또는 이들의 조합에 의해 구현될 수 있다. 일 예로, 하나 이상의 ASIC(application specific integrated circuit), 하나 이상의 DSP(digital signal processor), 하나 이상의 DSPD(digital signal processing device), 하나 이상의 PLD(programmable logic device) 및/또는 하나 이상의 FPGA(field programmable gate arrays)가 하나 이상의 프로세서(102, 202)에 포함될 수 있다. 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 동작 흐름도는 펌웨어 및/또는 소프트웨어를 사용하여 구현될 수 있고, 펌웨어 및/또는 소프트웨어는 모듈, 절차, 기능을 포함하도록 구현될 수 있다. 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 동작 흐름도를 수행하도록 설정된 펌웨어 또는 소프트웨어는 하나 이상의 프로세서(102, 202)에 포함되거나, 하나 이상의 메모리(104, 204)에 저장되어 하나 이상의 프로세서(102, 202)에 의해 구동될 수 있다. 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 동작 흐름도는 코드, 명령어 및/또는 명령어의 집합 형태로 펌웨어 또는 소프트웨어를 사용하여 구현될 수 있다.
하나 이상의 메모리(104, 204)는 하나 이상의 프로세서(102, 202)와 연결될 수 있고, 다양한 형태의 데이터, 신호, 메시지, 정보, 프로그램, 코드, 지시 및/또는 명령을 저장할 수 있다. 하나 이상의 메모리(104, 204)는 ROM(read-only memory), RAM(random access memory), EPROM(erasable programmable ROM), 플래시 메모리, 하드 드라이브, 레지스터, 캐쉬 메모리, 컴퓨터 판독 저장 매체 및/또는 이들의 조합으로 구성될 수 있다. 하나 이상의 메모리(104, 204)는 하나 이상의 프로세서(102, 202)의 내부 및/또는 외부에 위치할 수 있다. 또한, 하나 이상의 메모리(104, 204)는 유선 또는 무선 연결과 같은 다양한 기술을 통해 하나 이상의 프로세서(102, 202)와 연결될 수 있다.
하나 이상의 송수신기(106, 206)는 하나 이상의 다른 장치에게 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 동작 흐름도에서 언급되는 사용자 데이터, 제어 정보, 무선 신호/채널 등을 전송할 수 있다. 하나 이상의 송수신기(106, 206)는 하나 이상의 다른 장치로부터 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 동작 흐름도에서 언급되는 사용자 데이터, 제어 정보, 무선 신호/채널 등을 수신할 수 있다. 예를 들어, 하나 이상의 송수신기(106, 206)는 하나 이상의 프로세서(102, 202)와 연결될 수 있고, 무선 신호를 송수신할 수 있다. 예를 들어, 하나 이상의 프로세서(102, 202)는 하나 이상의 송수신기(106, 206)가 하나 이상의 다른 장치에게 사용자 데이터, 제어 정보, 무선 신호 등을 전송하도록 제어할 수 있다. 또한, 하나 이상의 프로세서(102, 202)는 하나 이상의 송수신기(106, 206)가 하나 이상의 다른 장치로부터 사용자 데이터, 제어 정보, 무선 신호 등을 수신하도록 제어할 수 있다.
하나 이상의 송수신기(106, 206)는 하나 이상의 안테나(108, 208)와 연결될 수 있다. 하나 이상의 송수신기(106, 206)는 하나 이상의 안테나(108, 208)를 통해 본 명세서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 동작 흐름도에서 언급되는 사용자 데이터, 제어 정보, 무선 신호/채널 등을 송수신하도록 설정될 수 있다. 본 명세서에서, 하나 이상의 안테나(108, 208)는 복수의 물리 안테나이거나, 복수의 논리 안테나(예: 안테나 포트)일 수 있다.
하나 이상의 송수신기(106, 206)는 수신된 사용자 데이터, 제어 정보, 무선 신호/채널 등을 하나 이상의 프로세서(102, 202)를 이용하여 처리하기 위해, 수신된 사용자 데이터, 제어 정보, 무선 신호/채널 등을 RF 밴드 신호에서 베이스밴드 신호로 변환할 수 있다. 하나 이상의 송수신기(106, 206)는 하나 이상의 프로세서(102, 202)를 이용하여 처리된 사용자 데이터, 제어 정보, 무선 신호/채널 등을 베이스밴드 신호에서 RF 밴드 신호로 변환할 수 있다. 이를 위하여, 하나 이상의 송수신기(106, 206)는 (아날로그) 발진기(oscillator) 및/또는 필터를 포함할 수 있다. 예를 들어, 하나 이상의 송수신기(106, 206)는 하나 이상의 프로세서(102, 202)의 제어 하에 (아날로그) 발진기 및/또는 필터를 통해 OFDM 베이스밴드 신호를 OFDM 신호로 상향 변환(up-convert)하고, 상향 변환된 OFDM 신호를 반송파 주파수에서 전송할 수 있다. 하나 이상의 송수신기(106, 206)는 반송파 주파수에서 OFDM 신호를 수신하고, 하나 이상의 프로세서(102, 202)의 제어 하에 (아날로그) 발진기 및/또는 필터를 통해 OFDM 신호를 OFDM 베이스밴드 신호로 하향 변환(down-convert)할 수 있다.
본 명세서의 구현에서, UE는 상향링크(UL; uplink)에서 송신 장치로, 하향링크(DL; downlink)에서 수신 장치로 작동할 수 있다. 본 명세서의 구현에서, 기지국은 UL에서 수신 장치로, DL에서 송신 장치로 동작할 수 있다. 이하에서 기술 상의 편의를 위하여, 제1 무선 장치(100)는 UE로, 제2 무선 장치(200)는 기지국으로 동작하는 것으로 주로 가정한다. 예를 들어, 제1 무선 장치(100)에 연결, 탑재 또는 출시된 프로세서(102)는 본 명세서의 구현에 따라 UE 동작을 수행하거나 본 명세서의 구현에 따라 UE 동작을 수행하도록 송수신기(106)를 제어하도록 구성될 수 있다. 제2 무선 장치(200)에 연결, 탑재 또는 출시된 프로세서(202)는 본 명세서의 구현에 따른 기지국 동작을 수행하거나 본 명세서의 구현에 따른 기지국 동작을 수행하기 위해 송수신기(206)를 제어하도록 구성될 수 있다.
본 명세서에서, 기지국은 노드 B(Node B), eNode B(eNB), gNB로 불릴 수 있다.
도 3은 본 명세서의 구현이 적용되는 무선 장치의 예를 나타낸다.
무선 장치는 사용 예/서비스에 따라 다양한 형태로 구현될 수 있다(도 1 참조).
도 3을 참조하면, 무선 장치(100, 200)는 도 2의 무선 장치(100, 200)에 대응할 수 있으며, 다양한 구성 요소, 장치/부분 및/또는 모듈에 의해 구성될 수 있다. 예를 들어, 각 무선 장치(100, 200)는 통신 장치(110), 제어 장치(120), 메모리 장치(130) 및 추가 구성 요소(140)를 포함할 수 있다. 통신 장치(110)는 통신 회로(112) 및 송수신기(114)를 포함할 수 있다. 예를 들어, 통신 회로(112)는 도 2의 하나 이상의 프로세서(102, 202) 및/또는 도 2의 하나 이상의 메모리(104, 204)를 포함할 수 있다. 예를 들어, 송수신기(114)는 도 2의 하나 이상의 송수신기(106, 206) 및/또는 도 2의 하나 이상의 안테나(108, 208)를 포함할 수 있다. 제어 장치(120)는 통신 장치(110), 메모리 장치(130), 추가 구성 요소(140)에 전기적으로 연결되며, 각 무선 장치(100, 200)의 전체 작동을 제어한다. 예를 들어, 제어 장치(120)는 메모리 장치(130)에 저장된 프로그램/코드/명령/정보를 기반으로 각 무선 장치(100, 200)의 전기/기계적 작동을 제어할 수 있다. 제어 장치(120)는 메모리 장치(130)에 저장된 정보를 무선/유선 인터페이스를 통해 통신 장치(110)를 거쳐 외부(예: 기타 통신 장치)로 전송하거나, 또는 무선/유선 인터페이스를 통해 통신 장치(110)를 거쳐 외부(예: 기타 통신 장치)로부터 수신한 정보를 메모리 장치(130)에 저장할 수 있다.
추가 구성 요소(140)는 무선 장치(100, 200)의 유형에 따라 다양하게 구성될 수 있다. 예를 들어, 추가 구성 요소(140)는 동력 장치/배터리, 입출력(I/O) 장치(예: 오디오 I/O 포트, 비디오 I/O 포트), 구동 장치 및 컴퓨팅 장치 중 적어도 하나를 포함할 수 있다. 무선 장치(100, 200)는, 이에 국한되지 않고, 로봇(도 1의 100a), 차량(도 1의 100b-1 및 100b-2), XR 장치(도 1의 100c), 휴대용 장치(도 1의 100d), 가전 제품(도 1의 100e), IoT 장치(도 1의 100f), 디지털 방송 단말, 홀로그램 장치, 공공 안전 장치, MTC 장치, 의료 장치, 핀테크 장치(또는 금융 장치), 보안 장치, 기후/환경 장치, AI 서버/장치(도 1의 400), 기지국(도 1의 200), 네트워크 노드의 형태로 구현될 수 있다. 무선 장치(100, 200)는 사용 예/서비스에 따라 이동 또는 고정 장소에서 사용할 수 있다.
도 3에서, 무선 장치(100, 200)의 다양한 구성 요소, 장치/부분 및/또는 모듈의 전체는 유선 인터페이스를 통해 서로 연결되거나, 적어도 일부가 통신 장치(110)를 통해 무선으로 연결될 수 있다. 예를 들어, 각 무선 장치(100, 200)에서, 제어 장치(120)와 통신 장치(110)는 유선으로 연결되고, 제어 장치(120)와 제1 장치(예: 130과 140)는 통신 장치(110)를 통해 무선으로 연결될 수 있다. 무선 장치(100, 200) 내의 각 구성 요소, 장치/부분 및/또는 모듈은 하나 이상의 요소를 더 포함할 수 있다. 예를 들어, 제어 장치(120)는 하나 이상의 프로세서 집합에 의해 구성될 수 있다. 일 예로, 제어 장치(120)는 통신 제어 프로세서, 애플리케이션 프로세서(AP; application processor), 전자 제어 장치(ECU; electronic control unit), 그래픽 처리 장치 및 메모리 제어 프로세서의 집합에 의해 구성될 수 있다. 또 다른 예로, 메모리 장치(130)는 RAM, DRAM, ROM, 플래시 메모리, 휘발성 메모리, 비휘발성 메모리 및/또는 이들의 조합에 의해 구성될 수 있다.
도 4는 본 명세서의 구현이 적용되는 네트워크 노드의 일 예를 나타낸다.
도 4는 기지국이 중앙 유닛(CU; central unit)과 분산 유닛(DU; distributed unit)으로 분할되는 경우, 상술한 도 2의 제2 무선 장치(200) 또는 도 3의 무선 장치(200)를 보다 상세하게 예시하는 도면이다.
도 4을 참조하면, 기지국(200)은 코어 네트워크(300)와 연결될 수 있다. 기지국(200)은 서로 연결될 수 있다. 예를 들어, 기지국(200)과 코어 네트워크(300) 사이의 인터페이스를 NG라 할 수 있다. 예를 들어, 기지국(200) 사이의 인터페이스를 Xn이라 할 수 있다.
기지국(200)은 CU(210) 및 DU(220)로 분할될 수 있다. 즉, 기지국(200)은 계층적으로 분리되어 운용될 수 있다. CU(210)는 하나 이상의 DU(220)와 연결될 수 있다. 예를 들어, CU(210)와 DU(220) 사이의 인터페이스를 F1이라 할 수 있다. CU(210)는 기지국(200)의 상위 계층의 기능을 수행할 수 있고, DU(220)는 기지국(200)의 하위 계층의 기능을 수행할 수 있다. 예를 들어, CU(210)는 기지국(200)(예: gNB)의 RRC, SDAP 및 PDCP 계층을 호스팅하는 논리 노드(logical node)일 수 있다. 또는, CU(W32)는 기지국(200)(예: ng-eNB)의 RRC 및 PDCP 계층을 호스팅하는 논리 노드일 수 있다. 예를 들어, DU(220)는 기지국의 RLC, MAC 및 PHY 계층을 호스팅하는 논리 노드일 수 있다.
DU(220)의 동작은 부분적으로 CU(210)에 의해 제어될 수 있다. 하나의 DU(220)는 하나 이상의 셀을 지원할 수 있다. 하나의 셀은 오직 하나의 DU(220)에 의해서만 지원될 수 있다. 하나의 DU(220)는 하나의 CU(210)에 연결될 수 있고, 적절한 구현에 의하여 하나의 DU(220)는 복수의 CU(210)에 연결될 수도 있다.
도 5은 본 명세서의 구현이 적용되는 5G 시스템 구조(system architecture)의 예를 나타낸다.
5G 시스템(5GS; 5G system) 구조는 다음과 같은 네트워크 기능(NF; network function)으로 구성된다.
- AUSF (Authentication Server Function)
- AMF (Access and Mobility Management Function)
- DN (Data Network), 예를 들어 운영자 서비스, 인터넷 접속 또는 타사 서비스
- USDF (Unstructured Data Storage Function)
- NEF (Network Exposure Function)
- I-NEF (Intermediate NEF)
- NRF (Network Repository Function)
- NSSF (Network Slice Selection Function)
- PCF (Policy Control Function)
- SMF (Session Management Function)
- UDM (Unified Data Management)
- UDR (Unified Data Repository)
- UPF (User Plane Function)
- UCMF (UE radio Capability Management Function)
- AF (Application Function)
- UE (User Equipment)
- (R)AN ((Radio) Access Network)
- 5G-EIR (5G-Equipment Identity Register)
- NWDAF (Network Data Analytics Function)
- CHF (CHarging Function)
또한, 다음과 같은 네트워크 기능이 고려될 수 있다.
- N3IWF (Non-3GPP InterWorking Function)
- TNGF (Trusted Non-3GPP Gateway Function)
- W-AGF (Wireline Access Gateway Function)
도 5은 다양한 네트워크 기능이 어떻게 서로 상호 작용하는지를 보여주는 기준점(reference point) 표현을 사용하여 비로밍(non-roaming) 사례의 5G 시스템 구조를 보여준다.
도 5에서는 점 대 점 도면의 명확성을 위해, UDSF, NEF 및 NRF는 설명되지 않았다. 그러나 표시된 모든 네트워크 기능은 필요에 따라 UDSF, UDR, NEF 및 NRF와 상호 작용할 수 있다.
명확성을 위해, UDR과 다른 NF(예: PCF)와의 연결은 도 5에 도시되지 않는다. 명확성을 위해, NWDAF과 다른 NF(예: PCF)와의 연결은 도 5에 도시되지 않는다.
5G 시스템 구조는 다음과 같은 기준점을 포함한다.
- N1: UE와 AMF 사이의 기준점.
- N2: (R)AN과 AMF 사이의 기준점.
- N3: (R)AN과 UPF 사이의 기준점.
- N4: SMF와 UPF 사이의 기준점.
- N6: UPF와 데이터 네트워크 사이의 기준점.
- N9: 두 UPF 사이의 기준점.
다음의 기준점은 NF의 NF 서비스 간에 존재하는 상호 작용을 보여준다.
- N5: PCF와 AF 사이의 기준점.
- N7: SMF와 PCF 사이의 기준점.
- N8: UDM과 AMF 사이의 기준점.
- N10: UDM과 SMF 사이의 기준점.
- N11: AMF와 SMF 사이의 기준점.
- N12: AMF와 AUSF 사이의 기준점.
- N13: UDM과 AUSF 사이의 기준점.
- N14: 두 AMF 사이의 기준점.
- N15: 로밍 시나리오(non-roaming scenario)에서, PCF와 AMF 간의 레퍼런스 포인트, 로밍 시나리오에서, AMF와 방문 네트워크(visited network)의 PCF 간의 레퍼런스 포인트를 나타낸다.
- N16: 두 SMF 사이의 기준점(로밍의 경우 방문 네트워크의 SMF와 홈 네트워크의 SMF 사이)
- N22: AMF와 NSSF 사이의 기준점.
- N30: PCF와 NEF 간의 기준점.
- N33: AF와 NEF 간의 기준점.
경우에 따라, UE를 서비스하기 위해 두 개의 NF를 서로 연결해야 할 수도 있다.
참고로, 도 5에서 사업자(operator) 이외의 제3자(third party)에 의한 AF는 NEF를 통해 5GC에 접속될 수도 있다.
<연결 관리(Connection Management: CM)>
CM은 UE와 AMF간의 시그널링 연결을 수립 또는 해제하기 위해 사용된다. 예를 들어, CM은 N1 레퍼런스 포인트를 통해 UE와 AMF 간의 NAS 시그널링 연결을 수립하는 기능 및 해제하는 기능을 포함한다. NAS 시그널링 연결은 UE와 코어 네트워크 간의 NAS 시그널링 교환(NAS signaling exchange)을 가능하게 한다.
NAS 시그널링 연결은 AN(Access Network)과 UE 간의 AN 시그널링 연결(3GPP 액세스를 통한 RRC 연결 또는 비-3GPP 액세스를 통한 UE와 N3IWF 간의 연결) 및 AN과 AMF 간의 UE에 대한 N2 연결을 포함할 수 있다.
2개의 CM 상태는 UE와 AMF 간의 NAS 시그널링 연결을 반영하기 위해 사용된다. 2개의 CM 상태는 아래와 같다:
- CM-IDLE
- CM-CONNECTED
3GPP 액세스에 대한 CM 상태 및 비-3GPP 액세스에 대한 CM 상태는 서로 독립적일 수 있다. 예를 들어, 3GPP 액세스에 대해서는 CM-IDLE 상태이고, 비-3GPP 액세스에 대해서는 CM-CONNECTED 상태일 수 있다.
이하에서, CM-IDLE 상태, CM-CONNECTED 상태 및 CM-IDLE 상태와 CM-CONNECTED 상태 간의 전환에 대해 설명하기로 한다.
1. CM-IDLE 상태
CM-IDLE 상태에 있는 UE는 N1 인터페이스를 통한 AMF와의 NAS 시그널링 연결을 가지고 있지 않다. UE는 셀 선택이나 셀 재선택 절차와 PLMN 선택 절차를 수행할 수 있다.
CM-IDLE 상태에 있는 UE에 대해, AN 시그널링 연결, N2 연결 및 N3 연결이 존재하지 않는다. UE가 CM-IDLE 상태이고 RM(Registration Management)-REGISTERED 상태인 경우, UE는 아래의 동작을 수행할 수 있다:
- UE가 Mobile Initiated Connection Only(MICO) 모드가 아닌 한, 서비스 요청 절차를 수행함으로써 페이징에 응답할 수 있다.
- UE가 전송할 업링크 시그널링 또는 사용자 데이터를 가질 때, 서비스 요청 절차를 수행할 수 있다.
AMF 내에서의 UE 상태가 RM-REGISTERED 이면, UE와의 통신을 개시하기 위한 UE 정보가 AMF에 저장될 수 있다. AMF는 5G-GUTI(Globally Unique Temporary Identifier)를 사용하여 UE와의 통신을 개시하는데 필요한 저장된 정보를 검색할 수 있다.
UE는 AN 시그널링 연결 수립을 위한 절차를 수행하는 동안 5G-S-TMSI(5G-Short-Temporary Mobile Subscriber Identity)를 AN 파라미터의 일부로 제공할 수 있다. AN 시그널링 연결이 UE와 AN 사이에 수립될 때마다 (3GPP 액세스를 통해 RRC Connected 상태로 들어가는 경우, 또는 비-3GPP 액세스를 통해 UE와 N3IWF 간의 연결을 수립하는 경우), UE는 CM-CONNECTED 상태로 들어갈(enter) 수 있다.
초기(Initial) NAS 메시지의 전송은 CM-IDLE 상태에서 CM-CONNECTED 상태로의 전환을 개시한다. 여기서, 초기 NAS 메시지는 예를 들어, 등록 요청 메시지, 서비스 요청 메시지, 등록취소 요청(Deregistration Request) 메시지일 수 있다.
AMF 내의 UE 상태가 CM-IDLE이고 RM-REGISTERED인 경우, AMF는 아래 동탁을 수행할 수 있다:
- AMF가 UE에 전송할 mobile-terminated 데이터 또는 시그널링을 가지는 경우, AMF는 UE에 페이징 요청 메시지를 전송함으로서 네트워크 개시 서비스 요청 절차(a network triggered Service Request procedure)를 수행할 수 있다. AMF는 UE가 MICO 모드 또는 이동성 제한 등으로 인해 응답할 수 없는 경우를 제외하고 네트워크 개시 서비스 요청 절차를 수행할 수 있다.
UE에 대해 AN과 AMF 사이에 N2 연결이 수립될 때마다, AMF는 UE에 대해 CM-CONNECTED 상태로 들어갈 수 있다. 초기 N2 메시지(예: N2 INITIAL UE MESSAGE)의 수신은 AMF에서의 CM-IDLE 상태에서 CM-CONNECTED 상태로의 전환을 개시한다.
UE 및 AMF는 CM-IDLE 상태일 때, 예를 들어, MICO 모드를 활성화 함으로써 전력 효율 및 시그널링 효율을 최적화 할 수도 있다.
2. CM-CONNECTED 상태
CM-CONNECTED 상태에 있는 UE는 N1 레퍼런스 포인트를 통해 AMF와 시그널링 연결을 가지고 있다. NAS 시그널링 연결은 UE와 NG-RAN 간의 RRC 연결 및 3GPP에 대한 AN과 AMF 간의 NGAP(New Generation Application Protocol) UE 연계(NGAP UE association)를 사용할 수 있다. UE는 AN과 AMF 간의 임의의 TNLA(Transport Network Layer Association)에 바인딩되지 않은(not bound to) NGAP UE 연계와 함께한 CM-CONNECTED 상태에 있을 수 있다. NAS 시그널링 절차가 완료되면, AMF는 UE와의 NAS 시그널링 연결을 해제하기로 결정할 수 있다.
CM-CONNECTED 상태에서, UE는 아래 동작을 수행할 수 있다:
- AN 시그널링 연결이 해제될 때마다(예를 들어, 3GPP 액세스를 통해 RRC Idle 상태에 들어가는 경우 또는 비-3GPP 액세스를 통한 UE와 N3IWF 간의 연결이 해제된 것이 UE에 의해 검출된 경우), UE는 CM-IDLE 상태로 들어갈 수 있다.
AMF 내의 UE CM 상태가 CM-CONNECTED 상태인 경우, AMF는 아래의 동작을 수행할 수 있다:
- AN 해제 절차가 완료될 때, UE에 대한 논리적 NGAP 시그널링 연결 및 N3 사용자 평면 연결이 해제되면, AMF는 UE에 대한 CM-IDLE 상태에 들어갈 수 있다.
UE가 코어 네트워크로부터 등록취소(de-register) 될 때까지, AMF는 AMF 내의 UE CM 상태를 CM-CONNECTED 상태로 유지할 수 있다.
CM-CONNECTED 상태에 있는 UE는 RRC 비활성화 상태에 있을 수 있다. UE가 RRC 비활성화 상태에 있으면, 아래의 내용이 적용된다:
- UE reachability는 코어 네트워크로부터의 지원 정보(assistance information)와 함께, RAN에 의해 관리된다,
- UE 페이징은 RAN에 의해 관리된다.
- UE는 UE의 CN(5G-S-TMSI) 및 RAN indentifier를 이용하여 페이징을 관리한다
3. CM-IDLE 상태와 CM-CONNECTED 상태 간의 전환
전술한 CM-IDLE 상태에 대한 설명 및 CM-CONNECTED 상태에 대한 설명에 기초하여, CM-IDLE 상태와 CM-CONNECTED 상태 간의 전환의 예시를 설명한다.
UE 내에서의 CM 상태가 CM-IDLE 상태인 경우, AN 시그널링 연결이 수립되면(예를 들어, UE가 초기 NAS 메시지를 전송한 경우), CM 상태는 CM-CONNECTED 상태로 전환된다. UE 내에서의 CM 상태가 CM-CONNECTED 상태인 경우, AN 시그널링 연결이 해제되면, CM 상태가 CM-IDLE 상태로 전환된다.
AMF 내에서의 UE에 대한 CM 상태가 CM-IDLE 상태인 경우, N2 컨텍스트가 수립되면, CM 상태가 CM-CONNECTED 상태로 전환된다. AMF 내에서의 UE에 대한 CM 상태가 CM-CONNECTED 상태인 경우, N2 컨텍스트가 해제되면, CM 상태가 CM-IDLE 상태로 전환된다.
<RRC 상태(RRC state)>
LTE에서 RRC 상태는 RRC_IDLE 상태 및 RRC_CONNECTED 상태를 포함한다. 5G에서 RRC 상태는 RRC_IDLE 상태, RRC_CONNECTED 상태 및 RRC_INACTIVE 상태를 포함할 수 있다. 즉, 5G에서 RRC_INACTIVE 상태가 새로 정의되었다.
RRC_INACTIVE 상태는, 단말(예: UE)가 코어 네트워크에서는 Connected 상태이지만, 단말과 NG-RAN 사이의 Radio 측면에서는 IDLE 상태인 RRC 상태를 의미할 수 있다. 예를 들어, 단말이 RRC_INACTIVE 상태인 경우, 단말은 Radio 측면에서는 RRC 연결이 해제된 상태이고, 단말은 코어 네트워크 측면에서는 MM(Mobility Management)-REGISTERED 상태이고, CM(Connection Management)_CONNECTED 상태일 수 있다.
RRC_INACTIVE 상태가 사용될 경우, 단말이 RRC_INACTIVE 상태에서 RRC_CONNECTED 상태로 전환될 경우, 코어에서는 CONNECTED 상태로 전환할 때 발생하는 시그널링이 필요 없이 빠르게 단말에게 연결을 제공할 수 있다. 그리고, 단말과 NG-RAN 사이의 Radio 측면에서는 Radio 자원이 불필요하게 낭비되는 것을 방지할 수 있으므로, Radio 자원을 효율적으로 사용할 수 있다.
II. 본 명세서의 개시
본 명세서에서 후술되는 개시들은 하나 이상의 조합(예: 이하에서 설명하는 내용들 중 적어도 하나를 포함하는 조합)으로 구현될 수 있다. 도면 각각은 각 개시의 실시예를 나타내고 있으나, 도면의 실시예들은 서로 조합되어 구현될 수도 있다.
본 명세서의 개시에서 제안하는 방안에 대한 설명은 이하에서 설명하는 하나 이상의 동작/구성/단계의 조합으로 구성될 수 있다. 아래에서 설명하는 아래의 방법들은 조합적으로 또는 보완적으로 수행되거나 사용될 수 있다.
단말을 RRC INACTIVE로 유지한 상태에서, 소량의 데이터를 전송하는 Small Data Transmission (SDT)가 논의되고 있다. SDT가 진행되는 상황에서, 단말이 non-SDT bearer data를 가지고 있을 수 있다. 이 경우, 단말이 non-SDT bearer data를 네트워크로 전달하기 위해, SDT를 중단하고 RRC_CONNECTED 상태로 천이하는 과정이 시작될 수 있다. SDT 절차가 진행되는 상황에서, non-SDT 데이터의 전송을 지원하기 위한 방안이 필요하다.
예를 들어, 단말이 RRC inactive 상태에서 SDT 서비스를 이용하는 동안, 단말이 new NG-RAN의 커버리지에 들어갈 수 있다. 단말이 non-SDT 데이터 전송을 해야 하는 경우, 단말은 RRC resume request를 new NG-RAN에게 전송한다. 이때, 단말의 Resume MAC-I를 어떻게 검증할지 불명확하다. 또한, New NG-RAN이 UE context를 찾을 수 있는 방법이 없어서, new NG-RAN이 기존의 UE context를 활용할 수 있는 방안이 필요하다.
예를 들어, SDT를 이용하는 도중에 단말이 SDT를 중지하고 다시 RRC Resume Request 메시지를 통해 non-SDT data의 발생을 네트워크에게 알릴 수 있다. old NG-RAN과 new NG-RAN 모두 단말에 대한 UE context를 가지고 있기 때문에, 단말이 전송한 RRC 메시지에 포함된 Resume MAC-I를 어느 NG-RAN이 검증할지가 명확하지 않다. 만약 old NG-RAN이 해당 단말에 대한 Resume MAC-I를 검증한다면 UE verification이 통과했음을 new NG-RAN에게 알려야 한다. 그리고, 해당 단말이 RRC_CONNECTED 상태에서 사용할 새로운 security Key KgNB* 값을 old NG-RAN이 new NG-RAN에게 전달할 방법이 필요하다.
또한, 예를 들어, new NG-RAN이 SDT 과정 동안 AMF와 Path Switch Request 과정까지 이미 끝마쳤을 수 있다. 이 경우, AMF의 지시에 따라 new NG-RAN이 UE에 관련된 몇몇 parameter 값을 업데이트하거나 release 했을 수 있기 때문에, old NG-RAN이 New NG-RAN에게 일부 context만을 전달할 방법이 필요하다.
또한, 예를 들어, new NG-RAN은 SDT 과정에서 이미 old NG-RAN으로부터 UE context를 수신한다. 하지만, 단말이 두번째 RRC Resume Request 메시지를 보내는 과정에서 new NG-RAN이 기존 UE context를 찾을 수 있는 방법이 없다. 따라서, new NG-RAN이 기존 UE context를 활용할 수 있는 방법이 필요하다.
SDT를 사용 중인 단말에 대해, non-SDT bearer와 관련된 UL data가 생길 수 있다. 이 경우, 단말은 해당 SDT procedure를 중단하고 네트워크에게 non-SDT data가 발생했음을 알려야 한다. 단말이 네트워크에게 non-SDT data가 발생했음을 알리는 과정에서 종래의 Resume procedure을 다시 이용하는 것 (즉, Common Control Channel (CCCH) solution)과 관련하여 문제가 없는지 논의가 필요하다.
CCCH 솔루션의 경우, non-SDT 무선 베어러에 대한 데이터가 있을 때, 네트워크가 새로운 Inactive Radio Network Temporary Identifier (I-RNTI) 또는 보안 키 정보와 함께 RRCRelease 메시지를 UE에게 전송하기 전에, UE는 진행 중인 SDT 세션을 중단한다. 이 경우 UE는 이전 앵커(old anchor) gNB에서 발행한 I-RNTI를 사용하여 두 번째 RRCResumeRequest 메시지를 보내고 수평 키 유도(horizontal key derivation)를 수행할 수 있다. 이 경우, 다음과 같은 문제가 발생할 수 있다:
일례로, 어느 노드(이전 앵커 gNB 또는 서빙 gNB)가 이전 앵커 gNB와 연관된 I-RNTI로 두 번째 RRCResumeRequest 메시지를 처리하고 ResumeMAC-I 검증 및 키 유도를 수행할지 불분명하다. 참고로, 본 명세서의 개시의 다양한 예시에서, old anchor gNB는 old NG-RAN 또는 old RAN와 같은 의미의 용어로 사용될 수 있다. 또한, 서빙 gNB는 new NG-RAN 또는 new RAN과 같은 의미의 용어로 사용될 수 있다.
다른 일례로, 이전 앵커 gNB 및/또는 서빙 gNB는 UE가 전송한 명시적 표시를 통해 두 번째 RRCResumeRequest 메시지를 구별할 수 있는지 불분명하다.
이러한 문제점에 대해, 이하의 예시와 같은 논의가 필요하다.
UE가 INACTIVE 상태에서 작은 데이터 전송을 허용하는 SDT(Small Data Transmission) 기능이 연구되고 있다. UE가 SDT 용으로 구성된 무선 베어러를 통해 UL 데이터를 전송해야 할 수 있다. 이 경우, SDT 절차는 SDT용으로 구성된 무선 베어러를 통해 데이터를 송수신하기 위해 시작될 수 있고, 다중 DL 및 UL 패킷은 SDT 세션 동안 교환될 수 있다. SDT 절차가 시작되면 RRCResumeRequest가 UL SDT 데이터와 함께 UE에 의한 첫 번째 UL 전송의 일부로 전송된다. UE는 이 첫 번째 RRCResumeRequest를 생성할 때(즉, 레거시 재개 절차와 동일) 보안 키를 생성하기 위해 저장된 Next Hop Chaining Counter (NCC) 값을 사용한다.
SDT 절차는 앵커 재배치를 포함하거나 포함하지 않고 지원된다. 앵커 재배치가 수행되면 타겟 gNB가 이전 앵커 gNB에서 UE 컨텍스트를 가져온다. 이 경우 PDCP 계층은 타겟 gNB에서 종료되고 사용자 데이터가 인코딩/디코딩되기 전에 경로 전환(path switch) 절차가 수행된다. 앵커 재배치가 없는 경우 이전 앵커 gNB는 PDCP 계층을 종료하고 경로 전환 절차는 수행되지 않는다.
SDT 절차가 진행되는 동안 SDT에 대해 설정되지 않은 무선 베어러의 버퍼에 새로운 UL 데이터가 나타날 수 있다. UE가 이 non-SDT 데이터 도착을 네트워크에 표시하기 위한 절차를 시작할 수 있다. UE가 네트워크에게 인디케이션을 전송하기 위해, UE가 진행 중인 SDT 절차를 종료하고 새로운 RRC 재개 절차를 트리거할 수 있다. 이 경우, UE는 두 번째 RRCResumeRequest를 네트워크로 전송할 수 있다.
이 경우, Resume Message Authentication Code - Integrity (resumeMAC-I) 재사용을 방지할 수 있는 솔루션이 추가로 논의되었다. 논의된 한 가지 옵션은 비-SDT 데이터 표시를 위한 제2 RRC 재개 절차에서 전송되는 제2 RRCResumeRequest에 대한 resumeMAC-I를 생성하기 위해, UE가 SDT 절차를 시작할 때 도출된 키를 사용하는 것이다. resumeMAC-I 계산에 대한 C-RNTI 입력은 UE가 RRC 연결이 중단되기 전에 연결된 PCell에서 가지고 있던 C-RNTI이다 (즉, 종래 재개 절차에서와 동일한 접근 방식임). 그 후, UE는 네트워크와 교환되는 후속 메시지에 사용될 키를 획득하기 위해 수평 키 유도를 수행한다. 이 솔루션에서 첫 번째 RRCResumeRequest에 사용된 것과 동일한 I-RNTI는 두 번째 RRCResumeRequest를 전송하는 데 재사용된다. 따라서 경로 전환의 경우, 메시지의 무결성 보호를 위해 대상 gNB에서 사용되는 키(즉, 아래 그림의 KRRCint_1)를 old anchor gNB가 사용하여, UE를 검증하는 옵션이 논의되고 있다.
위에서 설명한 예시에 따른 절차를 쉽게 이해하기 위한 예시적인 call flow는 도 6a 및 도 6b의 예시와 같다.
이하의 도면은 본 명세서의 구체적인 일례를 설명하기 위해 작성되었다. 도면에 기재된 구체적인 장치의 명칭이나 구체적인 신호/메시지/필드의 명칭은 예시적으로 제시된 것이므로, 본 명세서의 기술적 특징이 이하의 도면에 사용된 구체적인 명칭에 제한되지 않는다.
도 6a 및 도 6b는 본 명세서의 개시의 SDT에 관련된 절차의 일 예를 나타낸다.
도 6a 및 도6b의 예시에서, UE, gNB, Last Serving gNB (즉, old anchor gNB), UPF, AMF 및/또는 SMF가 도시된다.
1. Last Serving gNB는 suspendConfig와 함께 RRCRelease 메시지를 전송할 수 있다.
2. UE는 RRC_INACTIVE 상태 및 CM-CONNECTED 상태가 될 수 있다.
3. UE는 SDT를 개시할 수 있다. 그리고, UE는 저장된 KRRCint_0을 사용하여 resume MAC-I를 계산할 수 있다. 참고로, KRRCint는 Mobile Equipment (ME) (또는 UE)와 gNB가 KgNB로부터 도출한 키이며, 특정 무결성 알고리즘을 사용하는 RRC 신호 보호에 사용된다. 여기서 KRRCint_0은 단말이 RRC_INACTIVE 상태로 천이될 때 저장하고 있던 KRRCint 값이다. 참고로, resume MAC-I는 gNB가 UE 인증을 사용할 때 사용되는 인증 토큰으로, gNB가 단말에 대한 검증을 할 때 사용하는 값이다. 그리고 UE는 KgNB*_1을 계산할 수 있다. 참고로, KgNB*는 KNG-RAN*으로도 지칭될 수 있다. KgNB* 또는 KNG-RAN*은 ME(또는 UE)와 NG-RAN(즉, gNB 또는 ng-eNB)이 수평 키 도출 또는 수직 키 도출을 수행할 때 도출하는 키일 수 있다. 예를 들어, RRCResumeRequest 메시지 전송 후의 RRCReject 메시지를 제외한 모든 RRC 메시지 보호를 위해, UE는 수평 키 도출 또는 수직 키 도출에 기초하여, 타겟 PCI, 티겟 Absolute Radio Frequency Channel Number (ARFCN)-DL/EARFCN-DL 및 KgNB/NH를 사용하여 KNG-RAN*을 도출할 수 있다. 그리고, UE는 종래 절차에 따라, new KRRCint_1을 포함하여, UP keys 와 CP keys를 계산할 수 있다.
4. UE는 gNB에게 RRCResumRequest 메시지와 함께 메시지(Msg3/MsgA)를 전송할 수 있다. 이때, UE는 resumId, cause, shortREsumMAC-I도 함께 전송할 수 있으며, UL 데이터도 전송할 수 있다.
5. gNB는 SDT 인디케이션과 함께 RETRIVE UE CONTEXT REQUEST 메시지를 Last Serving gNB에게 전송할 수 있다.
6. Last Serving gNB는 newKgNB*_1을 계산하고, KRRCint_1을 포함하는 다른 키를 도출할 수 있다.
7. Last Serving gNB는 RETRIVE UE CONTEXT RESPONSE 메시지를 gNB에게 전송할 수 있다.
8. gNB는 Xn-U ADDRESS INDICATION을 Last Serving gNB에게 전송할 수 있다.
9. gNB는 경로 전환 요청(PATH SWITCH REQUEST) 메시지를 AMF/SMF에게 전송할 수 있다.
10. AMF/SMF와 UPF는 PDU 세션 업데이트 절차 및 N4 세션 수정 절차를 수행할 수 있다.
11. AMF/SMF는 PATH SWITCH REQUEST ACKNOWLEDGE 메시지를 gNB에게 전송할 수 있다.
12. gNB는 msgB/msg4와 DL 데이터를 UE에게 전송할 수 있다.
13. 후속 SDT 데이터가 UE와 UPF 사이에서 전송되고 수신될 수 있다.
14. UE에게 non-SDT 데이터가 도착할 수 있다.
15. UE는 두번째 RRC Resume 절차를 개시할 수 있다. 그리고, UE는 KRRCint_1 및 KgNB*_1을 사용하여 UE Inactive AS context를 업데이트할 수 있다. UE는 KRRCint_1을 사용하여 resume MAC-I를 계산할 수 있다. 그리고 UE는 종래 절차에 따라, 수평 키 도출(horizontal key derivation)을 사용하여 KgNB*2을 계산할 수 있다. 그리고, UE는 종래 절차에 따라, UP keys 와 CP keys를 계산할 수 있다.
16. UE는 gNB에게 RRCResumRequest 메시지와 함께 메시지(Msg3/MsgA)를 전송할 수 있다. 이때, UE는 resumId, cause, 업데이트된 KRRCint_1을 이용하여 계산된 shortResumMAC-I도 함께 전송할 수 있다.
17. gNB는 RETRIVE UE CONTEXT REQUEST 메시지를 Last Serving gNB에게 전송할 수 있다.
18. Last Serving gNB는 I-RNTI에 기초하여, RRCResumRequest 메시지가 동일한 UE로부터 전송되었다는 것을 식별할 수 있다. 그리고, Last Serving gNB는 KRRCint_0 대신, KRRCint_1에 기초하여 ResumMAC-I를 검증할 수 있다. 그리고, Last Serving gNB는 종래 기술에 따라, 수평 키 도출을 사용하여, KgNB*2를 계산할 수 있다.
19. Last Serving gNB는 RETRIVE UE CONTEXT RESPONSE 메시지를 gNB에게 전송할 수 있다.
20. gNB는 RRCResume 메시지를 UE에게 전송할 수 있다.
21. gNB는 UE CONTEXT RELEASE 메시지를 Last Serving gNB에게 전송할 수 있다.
선택 사항으로, 첫 번째 RRCResumeRequest에 대한 네트워크의 응답을 수신하기 전에 UE가 새로운 RRC 재개 절차를 트리거하는 방안도 고려되고 있다.
단말이 SDT를 시도하는 과정에서 UE context를 가지고 있던 old NG-RAN이 현재 단말이 접속한 New NG-RAN에게 UE context를 전달할 수 있다. SDT 도중에 단말에게 non-SDT data가 발생하면, 단말이 해당 SDT 과정을 중지하고 다시 RRC Resume Request 메시지를 네트워크에게 전달할 수 있다. 이 경우, 해당 RRC 메시지 내에 포함되어 있는 Resume MAC-I를 어느 NG-RAN이 검증할지가 명확하지 않다. 왜냐하면, old NG-RAN과 new NG-RAN 모두 단말에 대한 UE context를 가지고 있기 때문이다. 만약 old NG-RAN이 해당 단말에 대한 Resume MAC-I를 검증한다면 UE verification이 통과했음을 new NG-RAN에게 알려야 한다. 또한, 해당 단말이 RRC_CONNECTED 상태에서 사용할 새로운 security Key KgNB* 값을 old NG-RAN이 new NG-RAN에게 전달할 방법이 필요하다.
또한 이 과정에서 old NG-RAN이 security key 외에도 현재 저장 중인 UE context를 모두 New NG-RAN에게 전달할 경우 문제가 발생할 수 있다. 왜냐하면 new NG-RAN이 SDT 과정 동안 AMF와 Path Switch Request 과정까지 이미 끝마친 경우, UE context에 관련된 몇몇 parameter 값이 업데이트되거나 release 되었을 수 있기 때문이다. 따라서 old NG-RAN이 New NG-RAN에게 일부 context만을 전달할 방법도 필요하다.
또한 new NG-RAN은 SDT 과정에서 이미 old NG-RAN으로부터 UE context를 수신한 상태이다. 이때, 단말이 두번째 RRC Resume Request 메시지를 보내는 과정에서 new NG-RAN이 기존 UE context를 찾을 수 있는 방법이 없기 때문에 new NG-RAN이 기존 UE context를 활용할 수 있는 방법도 필요하다.
이하에서 설명하는 본 명세서의 개시의 다양한 예시에서, non-SDT data 전송을 위해 New NG-RAN이 해당 단말을 RRC_CONNECTED 상태로 천이시킬 수 있도록, old NG-RAN이 New NG-RAN에게 알리는 방법의 예시를 제안한다. 또한 new NG-RAN이 SDT 과정에서 가지고 있던 UE context를 계속해서 활용할 수 있도록, old NG-RAN이 관련 정보를 new NG-RAN에게 전달하는 방법의 예시를 제안한다.
아래에서 기술된 2개의 NG-RAN 간 Xn message들의 일부에 대해서, 새로운 Xn 메시지가 정의되어 사용될 수도 있다. 또한, 아래에서 기술된 NG-RAN과 UE 간의 RRC message들의 일부에 대해서, 새로운 RRC message가 정의되어 사용될 수도 있다.
단말의 non-SDT data 전송을 지원하기 위해, old NG-RAN은 단말에 대한 verification 을 끝마친 후 new NG-RAN이 RRC_CONNECTED 상태에서 사용할 security key 값을 생성하여 전달할 수 있다. 또한 만약 new NG-RAN이 SDT 과정 동안 AMF와 Path Switch Request 과정까지 이미 끝마친 경우, new NG-RAN이 해당 과정을 다시 반복하지 않도록, old NG-RAN은 이를 알리는 추가적인 indication을 같이 전달할 수 있다. 또한 New NG-RAN이 SDT 과정에서 사용하던 UE context를 계속해서 이용할 수 있도록, old NG-RAN은 New NG-RAN이 SDT 과정에서 할당하였던 New NG-RAN UE XnAP ID_1을 같이 New NG-RAN에게 전달함으로써, New NG-RAN이 SDT 과정에서 사용하였던 기존 UE context을 찾을 수 있도록 할 수 있다.
아래 본 명세서의 개시의 다양한 예시에서 설명하는 절차들에서, 어떤 동작/step들은 동시에/병렬적으로 수행될 수도 있고, 본 명세서의 개시에서 설명된 순서와는 다른 순서로 수행될 수도 있다.
이하에서, 본 명세서의 개시의 제1예 내지 제4예를 참조하여, 본 명세서의 개시를 설명한다. 이하에서 설명하는 본 명세서의 개시의 제1예 내지 제4예는 조합되어 구현될 수도 있다.
1. 본 명세서의 개시의 제1예
이하에서, 도 7a 및 7b의 예시, 도 8a 및 8b의 예시 및 도 9a 및 9b의 예시를 참조하여, 본 명세서의 개시의 제1예를 설명하기로 한다.
본 명세서의 개시의 제1예는 앵커 재배치를 사용한 SDT 절차에 관련된 예시를 설명한다.
이하의 도면은 본 명세서의 구체적인 일례를 설명하기 위해 작성되었다. 도면에 기재된 구체적인 장치의 명칭이나 구체적인 신호/메시지/필드의 명칭은 예시적으로 제시된 것이므로, 본 명세서의 기술적 특징이 이하의 도면에 사용된 구체적인 명칭에 제한되지 않는다.
도 7a 및 도 7b는 본 명세서의 개시의 제1예의 제1 예시에 따른 신호 흐름도를 나타낸다.
예를 들어, 도 7a 및 도7b의 예시는 앵커 재배치와 함께 진행중인 SDT 절차에서 비-SDT 데이터 전송을 지원하기 위한 절차의 예시를 나타낸다.
도 7a 및 도7b의 예시에 따르면, 단말이 Non-SDT bearer을 통해 전송해야 될 data가 생겼다는 사실을 old NG-RAN에게 알릴 수 있다. 그러면, old NG-RAN이 해당 단말에 대한 verification을 진행한 후 새로운 security key를 생성하여 new NG-RAN에게 전달할 수 있 있다. 기본적으로, SDT 과정에서 New NG-RAN으로 UE context가 옮겨진 경우가 가정된다. 또한, 본 명세서의 개시에서는 New NG-RAN와 Old NG-RAN 모두 CU-CP와 CU-UP, DU로 분리되어 있지 않은 상태를 가정하고 있으나, 이는 예시에 불과하며, 본 명세서의 개시에서 설명하는 내용은 New NG-RAN 및/또는 Old NG-RAN이 CU-CP와 CU-UP, DU로 분리되어 있는 경우도 적용될 수 있다.
Step 0: 단말은 현재 RRC-INACTIVE 상태에 있다. 따라서 단말과 old NG-RAN (=Last serving NG-RAN)은 각각 UE context를 저장하고 있다. Old NG-RAN과 AMF 사이의 NG-C 연결은 유지되고 있으며, Old NG-RAN과 UPF 사이의 NG-U 연결도 유지된다.
Step 1: 단말은 RRC-INACTIVE 상태에서 SDT data를 전송하기로 결정할 수 있다. 그러면, 단말은 I-RNTI, RRC resume cause (for small data transmission in RRC-INACTIVE), 그리고 authentication token (e.g., Resume MAC-I) 등을 포함한 RRC Resume Request 메시지를 생성하여 New NG-RAN에게 전송할 수 있다. 단말은 RRC_INACTIVE 상태로 천이하는 과정에서 저장하고 있던 KRRCint_0 값에 기초하여, Resume MAC-I을 생성할 수 있다.
이때, 단말의 buffer에 저장 중인 SDT data를 RRC Resume Request 메시지와 같이 multiplexing 하여 전송할 수 있다. 또한 단말은 SDT와 관련된 정보 (e.g., UL data 여부, DL Data에 대한 응답 여부 등)를 같이 RRC Resume Request 메시지에 포함시켜 New NG-RAN에게 전달할 수 있다.
NOTE: 단말은 RRC Resume Request 메시지를 네트워크로 전송한 이후, KgNB*_1 값을 생성하고 이를 통하여 새로운 KRRCint_1과 KRRCenc_1, KUPenc_1 (Optional), 그리고 KUPint_1 (Optional) 값을 도출할 수 있다. 이러한 값들은 RRC와 User plane에 대하여 각각 integrity protection 또는 encryption을 하는데 사용하는 key 값일 수 있다. 예를 들어, KUPenc는 ME와 gNB가 KgNB로부터 도출한 키로, 특정 암호화 알고리즘을 사용하여 UP 트래픽을 보호하는 데 사용될 수 있다. 예를 들어, KUPint는 ME와 gNB가 KgNB로부터 파생한 키로, 특정 무결성 알고리즘을 사용하여 ME와 gNB 간의 UP 트래픽 보호에 사용될 수 있다. KRRCenc는 ME와 gNB가 KgNB로부터 도출한 키로, 특정 암호화 알고리즘을 사용하여 RRC 신호를 보호하는 데 사용될 수 있다.
Step 2: New NG-RAN은 단말로부터 RRC Resume Request 메시지를 수신할 수 있다. New NG-RAN은 I-RNTI에 기초하여, 해당 단말에 대한 UE context를 찾을 수 있는지 확인할 수 있다. 만약 I-RNTI를 통해 UE context를 찾는데 실패한 경우, New NG-RAN은 I-RNTI에 기초하여 old NG-RAN을 특정할 수 있다. 그리고, New NG-RAN은 해당 node(즉, old NG-RAN)으로부터 UE context를 전달받기 위해 RETRIEVE UE CONTEXT REQUEST 메시지를 old NG-RAN에게 전송할 수 있다. 이 과정에서 UE-associated Xn connection을 생성하기 위해, New NG-RAN은 New NG-RAN UE XnAP ID_1을 할당하여 같이 old NG-RAN에게 전달할 수 있다. 또한 New NG-RAN은 현재 단말이 SDT data를 전송하기 위해 접속 중임을 old NG-RAN에게 같이 알릴 수 있다.
Step 3: Old NG-RAN은 UE를 검증할 수 있다. Old NG-RAN은 I-RNTI에 기초하여, 해당 단말에 대한 UE context를 찾을 수 있는지 확인할 수 있다. 해당 UE context를 찾을 수 있는 경우, 단말이 보낸 Resume MAC-I가 유효한지 확인할 수 있다.
Step 4: Old NG-RAN이 해당 단말에 대한 검증을 완료한 후, Old NG-RAN이 해당 단말에 대한 UE context를 new NG-RAN에게 전달하기로 결정할 수 있다. 그러면, Old NG-RAN은 RETRIEVE UE CONTEXT RESPONSE 메시지를 통해 new NG-RAN에게 응답할 수 있다.
Step 5: 단말에게 전달해야 할 DL data가 있는 경우, 해당 DL data를 전달받기 위해, New NG-RAN은 XN-U ADDRESS INDICATION 메시지를 전송하여 DL data forwarding address 정보를 전달할 수 있다.
Step 6: New NG-RAN은 5GC 쪽으로 Path Switch Request 절차를 개시하고, 이를 통해 단말이 New NG-RAN을 통해 serving 될 것임을 알린다.
Step 7: 해당 단말과 관련된 UP path를 new NG-RAN 쪽으로 변경하기 위한 절차가 끝나면 AMF는 PATH SWTICH REQUEST ACKNOWLEDGE 메시지를 통해 new NG-RAN에게 응답할 수 있다.
Step 8: New NG-RAN은 Msg B 또는 Msg 4를 통해 단말에게 응답할 수 있다. 이 과정에서 단말에게 전달할 DL data가 있다면, New NG-RAN은 DL data를 RRC message와 같이 multiplexing 하여 전송할 수 있다.
이후에 단말과 5GC는 New NG-RAN을 통하여 SDT data를 교환할 수 있다.
Step 9: Non-SDT bearer에 관련된 data가 단말에 도착할 수 있다. 따라서 단말은 RRC-CONNECTED 상태로 천이하기 위해 SDT data 전송을 멈추고 non-SDT data가 도착했음을 네트워크에게 알리기 위해 normal Resume procedure를 시작하기로 결정할 수 있다.
Step 10: 단말은 현재 머물러 있는 cell에서 다시 NG-RAN에게 RRC Resume Request 메시지를 전송할 수 있다. 이때 단말은 Step 1에서 구한 KRRCint_1 값에 기초하여 Resume MAC-I를 생성할 수 있다. 그리고, 단말은 2번째 RRC Resume Request 메시지에 Resume MAC-I를 포함시킨 뒤 New NG-RAN에게 전송할 수 있다.
NOTE: 단말은 2번째 RRC Resume Request 메시지를 전송한 뒤, KgNB*1 값에 기초하여 Horizontal Key derivation을 수행함으로써, KgNB*2를 도출할 수 있다. 이를 통해 단말은 새로운 KRRCint_2와 KRRCenc_2, KUPenc_2 (Optional), 그리고 KUPint_2 (Optional) 값을 계산할 수 있다.
Step 11: 단말로부터 2번째 RRC Resume Request 메시지를 수신한 New NG-RAN은 I-RNTI에 기초하여 해당 단말에 대한 UE context를 찾을 수 있는지 확인할 수 있다. 만약 I-RNTI를 통해 UE context를 찾는데 실패한 경우, I-RNTI를 기반으로 old NG-RAN을 특정할 수 있다. 그리고 New NG-RAN은 해당 node(즉, old NG-RAN)로부터 UE context를 전달받기 위해, old NG-RAN에게 RETRIEVE UE CONTEXT REQUEST 메시지를 전송할 수 있다. 이 과정에서 New NG-RAN은 UE-associated Xn connection을 생성하기 위해, New NG-RAN UE XnAP ID_2를 할당하여 old NG-RAN에게 같이 전달할 수 있다.
Step 12: Old NG-RAN은 I-RNTI에 기초하여, 해당 단말에 대한 UE context를 찾을 수 있는지 확인할 수 있다. 해당 UE context를 찾을 수 있는 경우, 단말이 보낸 Resume MAC-I가 유효한지 확인할 수 있다. Old NG-RAN은 해당 단말에 대한 검증이 통과되면, horizontal key derivation을 통하여 UE context에 포함된 KgNB*1로부터 KgNB*2를 도출할 수 있다.
NOTE: Old NG-RAN은 해당 단말이 보낸 Resume MAC-I를 검증하는 과정에서 Step 3에서 사용한 KRRCint_0이 아닌, KRRCint_1을 사용할 수 있다.
Step 13: Old NG-RAN이 해당 단말에 대한 검증이 끝내고 난 뒤 해당 단말에 대한 UE context를 new NG-RAN에게 전달하기로 결정하면, Old NG-RAN은 RETRIEVE UE CONTEXT FAILURE 메시지를 통해 new NG-RAN에게 응답할 수 있다. 이때 Old NG-RAN은 Step 12에서 얻은 security key KgNB*2와 NCC 값을 같이 메시지에 포함시켜, new NG-RAN에게 전달할 수 있다. 예를 들어, New NG-RAN은 새로운 security key를 수신함으로써 다음과 같은 동작을 수행할 수 있다:
- 해당 단말에 대해 non-SDT data가 도착하였으며, 이를 전송하기 위해 RRC_CONNECTED로의 상태 천이가 필요함을 알 수 있음
- 해당 단말에 대한 SDT data 전송 중단
- Old NG-RAN에서 해당 단말에 대한 UE verification이 성공적으로 끝남
- 이후로 해당 단말을 serving하는 node는 New NG-RAN이 되었으며, Old NG-RAN 쪽으로의 UE Context Release 절차의 trigger
- AMF 쪽으로 다시 Path Switch Request 절차를 수행하지 않아도 됨
- Step 4 과정을 통하여 수신하여 SDT 전송을 위해 사용 중이던 UE context를 계속해서 이용할 수 있음
해당 단말을 RRC_CONNECTED로 천이시키고 non-SDT data에 대한 전송을 지원하는 과정에서, New NG-RAN이 Step 4에서 수신한 UE context를 계속해서 사용할 수 있도록 하기 위해, old NG-RAN은 다음의 동작을 수행할 수 있다. 예를 들어, old NG-RAN은 New NG-RAN 이 step 2 과정에서 할당하였던 New NG-RAN UE XnAP ID_1을 같이 RETRIEVE UE CONTEXT FAILURE 메시지에 포함시킬 수 있다. 이를 기반으로 New NG-RAN은 Step 4에서 수신한 이후 SDT 전송을 위하여 사용 중이던 UE context를 찾을 수 있고 이를 계속해서 활용할 수 있다. 만약 New NG-RAN이 New NG-RAN UE XnAP ID_1를 통해 UE context를 찾는데 실패할 수 있다면 이와 관련된 새로운 cause value를 통해 old NG-RAN에게 알릴 수 있다. 이 경우 old NG-RAN은 New NG-RAN에게 다시 UE context을 전달하기 위한 절차를 시작할 수 있다.
New NG-RAN은 수신한 KgNB*2를 기반으로 새로운 KRRCint_2와 KRRCenc_2, KUPenc_2 (Optional), 그리고 KUPint_2 (Optional) 값을 계산할 수 있다.
NOTE: RETRIEVE UE CONTEXT FAILURE 메시지 대신에 새로운 XnAP 메시지가 정의되어 사용될 수도 있다. 또는 RETRIEVE UE CONTEXT FAILURE 메시지 대신에 RETRIEVE UE CONTEXT RESPONSE 메시지가 활용될 수도 있는데, 이 경우(e.g., Step 6과 7 과정을 통해 일부 PDU Session에 대한 Path Switch가 실패함에 따라 해당 PDU Session을 release 하였는데, Step 13에서 전송받는 UE context 안에 해당 PDU Session이 다시 포함되는 경우 등)엔 old NG-RAN이 저장하고 있던 outdated UE context 가 new NG-RAN에 전달될 가능성이 있다. 이를 방지하기 위해, new NG-RAN이 RETRIEVE UE CONTEXT RESPONSE 메시지 내의 여러 mandatory IE 중에서 Security key와 관련된 IE를 제외하고 다른 Mandatory IE들은 무시하도록, old NG-RAN이 RETRIEVE UE CONTEXT RESPONSE 메시지 안에 새로운 indication을 추가할 수도 있다.
NOTE: 만약 New NG-RAN이 CU-CP, CU-UP, DU로 구성되어 있는 경우, New NG-RAN의 CU-CP는 KgNB*2를 기반으로 새로운 KRRCint_2와 KRRCenc_2, KUPenc_2 (Optional), 그리고 KUPint_2 (Optional) 값을 계산할 수 있다. 그리고 E1AP 메시지 (e.g., BEARER CONTEXT SETUP REQUEST, BEARER CONTEXT MODIFICATION REQUEST, or New message)를 통하여 New NG-RAN의 CU-UP에게 UP security key의 변경일 알릴 수 있다. 이 과정에서 New NG-RAN의 CU-CP는 SDT Bearer에 관련된 PDCP가 COUNT 값을 초기화하지 말라고 New NG-RAN의 CU-UP에게 같이 알릴 수 있다. 이를 통해 New NG-RAN은 해당 단말을 RRC_CONNECTED 상태로 천이시킨 후 step 13에서 전송이 중단된 SDT data를 다시 단말과 교환할 수 있다.
NOTE: 만약 New NG-RAN이 CU-CP, CU-UP, DU로 구성되어 있는 경우, New NG-RAN의 CU-CP는 SDT 전송 과정에서 사용하던 UE Context를 그대로 활용할 수도 있다. 이 경우, New NG-RAN의 CU-CP는 New NG-RAN의 DU에게 UE CONTEXT MODIFICATION REQUEST 메시지를 보내 Non-SDT bearer (e.g., Bearer configuration, F1 UL TEIDs)에 대한 셋업을 요청할 수 있다. 이때 해당 단말에 대한 SDT 과정에서 New NG-RAN의 CU-CP는 New NG-RAN의 DU가 설정한 old gNB-DU UE F1AP ID를 같이 전달할 수 있다. 이를 통하여 New NG-RAN의 DU는 해당 단말이 SDT bearer 외에 추가로 non-SDT bearer를 셋업하려고 시도하는 것을 알 수 있다. 이를 통해 New NG-RAN의 DU는 해당 단말을 위해 설정하였던 SDT bearer, CG configuration 등의 정보를 그대로 활용할 수 있다.
만약 New NG-RAN의 DU가 old gNB-DU UE F1AP ID를 통해 UE context를 찾는데 실패한다면, New NG-RAN의 DU는 이와 관련된 새로운 cause value를 통해 New NG-RAN의 CU에게 알릴 수 있다. 이 경우 New NG-RAN의 CU는 New NG-RAN의 DU에서 다시 새로운 UE context을 생성하기 위한 절차를 시작할 수 있다.
Step 14: New NG-RAN은 해당 단말을 RRC_CONNECTED 상태로 천이시키기 위해 RRC Resume 메시지를 생성하여 단말에게 전송할 수 있다. New NG-RAN은 Step 13에서 수신한 KgNB*2를 이용하여 RRC Resume 메시지를 encryption할 수 있다. 그러면, 단말은 Step 10에서 계산한 KgNB*2를 기반으로 해당 RRC 메시지를 decryption 할 수 있다.
Step 15: New NG-RAN은 Old NG-RAN에게 UE Context Release 메시지를 전송하여 해당 단말에 대한 release를 요청할 수 있다. 이를 수신한 old NG-RAN은 해당 단말과 관련된 모든 context를 삭제하고 할당된 resource를 release할 수 있다.
이하의 도면은 본 명세서의 구체적인 일례를 설명하기 위해 작성되었다. 도면에 기재된 구체적인 장치의 명칭이나 구체적인 신호/메시지/필드의 명칭은 예시적으로 제시된 것이므로, 본 명세서의 기술적 특징이 이하의 도면에 사용된 구체적인 명칭에 제한되지 않는다.
도 8a 및 도 8b는 본 명세서의 개시의 제1예의 제2 예시에 따른 신호 흐름도를 나타낸다.
예를 들어, 도 8a 및 도8b의 예시는 앵커 재배치와 함께 진행중인 SDT 절차에서 비-SDT 데이터 전송을 지원하기 위한 절차의 예시를 나타낸다.
도 8a 및 도8b의 예시에 따르면, 단말이 Non-SDT bearer을 통해 전송해야 될 data가 생겼다는 사실을 old NG-RAN에게 알릴 수 있다. 그러면, old NG-RAN이 해당 단말에 대한 verification을 진행한 후 검증이 통과되었다는 사실을 new NG-RAN에게 전달할 수 있다. old NG-RAN이 전달한 indication을 수신한 new NG-RAN은 horizontal key derivation을 통해 해당 단말에 대해 사용할 새로운 security key를 생성할 수 있다. 기본적으로 SDT 과정에서 New NG-RAN으로 UE context가 옮겨진 경우가 가정된다. 또한, 본 명세서의 개시에서는 New NG-RAN와 Old NG-RAN 모두 CU-CP와 CU-UP, DU로 분리되어 있지 않은 상태를 가정하고 있으나, 이는 예시에 불과하며, 본 명세서의 개시에서 설명하는 내용은 New NG-RAN 및/또는 Old NG-RAN이 CU-CP와 CU-UP, DU로 분리되어 있는 경우도 적용될 수 있다.
Step 0 ~ Step 11: 도 7a 및 도 7b의 예시의 Step 0~ Step 11과 동일한 방식으로 수행될 수 있다.
Step 12: Old NG-RAN은 I-RNTI에 기초하여, 해당 단말에 대한 UE context를 찾을 수 있는지 확인할 수 있다. 해당 UE context를 찾을 수 있는 경우, 단말이 보낸 Resume MAC-I가 유효한지 확인할 수 있다.
NOTE: Old NG-RAN은 해당 단말이 보낸 Resume MAC-I를 검증하는 과정에서 Step 3에서 사용한 KRRCint_0이 아닌, KRRCint_1을 사용할 수 있다.
Step 13: Old NG-RAN이 해당 단말에 대한 검증이 끝내고 난 뒤 해당 단말에 대한 UE context를 new NG-RAN에게 전달하기로 결정하면, Old NG-RAN은 RETRIEVE UE CONTEXT FAILURE 메시지를 통해 new NG-RAN에게 응답할 수 있다. 또한 Old NG-RAN은 “Non-SDT data arrival” indication을 메시지에 같이 포함시켜 new NG-RAN에게 전달할 수 있다. New NG-RAN은 새로운 indication을 수신함으로써 다음과 같은 동작을 수행할 수 있다:
- 해당 단말에 대해 non-SDT data가 도착하였으며, 이를 전송하기 위해 RRC_CONNECTED로의 상태 천이가 필요함을 알 수 있음
- 해당 단말에 대한 SDT data 전송 중단
- Old NG-RAN에서 해당 단말에 대한 UE verification이 성공적으로 끝남
- 이후로 해당 단말을 serving하는 node는 New NG-RAN이 되었으며, Old NG-RAN 쪽으로의 UE Context Release 절차의 trigger
- AMF 쪽으로 다시 Path Switch Request 절차를 수행하지 않아도 됨
- Ongoing SDT session (i.e., Step 4~8 과정)에서 사용하던 KgNB*1을 기반으로 horizontal key derivation을 수행해야 하며 이를 통해 새로운 security key KgNB*2를 얻을 수 있음
- Step 4 과정을 통하여 수신하여 SDT 전송을 위해 사용 중이던 UE context를 계속해서 이용할 수 있음
해당 단말을 RRC_CONNECTED로 천이시키고 non-SDT data에 대한 전송을 지원하는 과정에서, New NG-RAN이 Step 4에서 수신한 UE context를 계속해서 사용할 수 있도록 하기 위해, old NG-RAN은 다음의 동작을 수행할 수 있다. 예를 들어, old NG-RAN은 New NG-RAN 이 step 2 과정에서 할당하였던 New NG-RAN UE XnAP ID_1을 같이 RETRIEVE UE CONTEXT FAILURE 메시지에 포함시킬 수 있다. 이를 기반으로 New NG-RAN은 Step 4에서 수신한 이후 SDT 전송을 위하여 사용 중이던 UE context를 찾을 수 있고 이를 계속해서 활용할 수 있다. 만약 New NG-RAN이 New NG-RAN UE XnAP ID_1를 통해 UE context를 찾는데 실패한다면 이와 관련된 새로운 cause value를 통해 old NG-RAN에게 알릴 수 있다. 이 경우 old NG-RAN은 New NG-RAN에게 다시 UE context을 전달하기 위한 절차를 시작할 수 있다.
New NG-RAN은 horizontal key derivation을 통해 새롭게 얻은 KgNB*2를 기반으로 새로운 KRRCint_2와 KRRCenc_2, KUPenc_2 (Optional), 그리고 KUPint_2 (Optional) 값을 계산할 수 있다.
NOTE: RETRIEVE UE CONTEXT FAILURE 메시지 대신에 새로운 XnAP 메시지가 정의되어 사용될 수도 있다. 또는 RETRIEVE UE CONTEXT FAILURE 메시지 대신에 RETRIEVE UE CONTEXT RESPONSE 메시지가 활용될 수도 있는데, 이 경우(e.g., Step 6과 7 과정을 통해 일부 PDU Session에 대한 Path Switch가 실패함에 따라 해당 PDU Session을 release 하였는데, Step 13에서 전송받는 UE context 안에 해당 PDU Session이 다시 포함되는 경우 등)엔 old NG-RAN이 저장하고 있던 outdated UE context 가 new NG-RAN에 전달될 가능성이 있다. 이를 방지하기 위해, new NG-RAN이 RETRIEVE UE CONTEXT RESPONSE 메시지 내의 여러 mandatory IE 중에서 Security key와 관련된 IE를 제외하고 다른 Mandatory IE들은 무시하거나 모든 mandatory IE들을 무시하도록, old NG-RAN이 RETRIEVE UE CONTEXT RESPONSE 메시지 안에 새로운 indication을 추가할 수도 있다.
NOTE: 만약 New NG-RAN이 CU-CP, CU-UP, DU로 구성되어 있는 경우, New NG-RAN의 CU-CP는 KgNB*2를 기반으로 새로운 KRRCint_2와 KRRCenc_2, KUPenc_2 (Optional), 그리고 KUPint_2 (Optional) 값을 계산할 수 있다. 그리고 E1AP 메시지 (e.g., BEARER CONTEXT SETUP REQUEST, BEARER CONTEXT MODIFICATION REQUEST, or New message)를 통하여 New NG-RAN의 CU-UP에게 UP security key의 변경일 알릴 수 있다. 이 과정에서 New NG-RAN의 CU-CP는 SDT Bearer에 관련된 PDCP가 COUNT 값을 초기화하지 말라고 New NG-RAN의 CU-UP에게 같이 알릴 수 있다. 이를 통해 New NG-RAN은 해당 단말을 RRC_CONNECTED 상태로 천이시킨 후step 13에서 전송이 중단된 SDT data를 다시 단말과 교환할 수 있다.
NOTE: 만약 New NG-RAN이 CU-CP, CU-UP, DU로 구성되어 있는 경우, New NG-RAN의 CU-CP는 SDT 전송 과정에서 사용하던 UE Context를 그대로 활용할 수도 있다. 이 경우, New NG-RAN의 CU-CP는 New NG-RAN의 DU에게 UE CONTEXT MODIFICATION REQUEST 메시지를 보내 Non-SDT bearer (e.g., Bearer configuration, F1 UL TEIDs)에 대한 셋업을 요청할 수 있다. 이때 해당 단말에 대한 SDT 과정에서 New NG-RAN의 CU-CP는 New NG-RAN의 DU가 설정한 old gNB-DU UE F1AP ID를 같이 전달할 수 있다. 이를 통하여 New NG-RAN의 DU는 해당 단말이 SDT bearer 외에 추가로 non-SDT bearer를 셋업하려고 시도하는 것을 알 수 있다. 이를 통해 New NG-RAN의 DU는 해당 단말을 위해 설정하였던 SDT bearer, CG configuration 등의 정보를 그대로 활용할 수 있다.
만약 New NG-RAN의 DU가 old gNB-DU UE F1AP ID를 통해 UE context를 찾는데 실패한다면, New NG-RAN의 DU는 이와 관련된 새로운 cause value를 통해 New NG-RAN의 CU에게 알릴 수 있다. 이 경우 New NG-RAN의 CU는 New NG-RAN의 DU에서 다시 새로운 UE context을 생성하기 위한 절차를 시작할 수 있다.
Step 14 ~ Step 15: 도 7a 및 도 7b의 예시의 Step 14~ Step 15과 동일한 방식으로 수행될 수 있다.
이하의 도면은 본 명세서의 구체적인 일례를 설명하기 위해 작성되었다. 도면에 기재된 구체적인 장치의 명칭이나 구체적인 신호/메시지/필드의 명칭은 예시적으로 제시된 것이므로, 본 명세서의 기술적 특징이 이하의 도면에 사용된 구체적인 명칭에 제한되지 않는다.
도 9a 및 도 9b는 본 명세서의 개시의 제1예의 제3 예시에 따른 신호 흐름도를 나타낸다.
예를 들어, 도 9a 및 도 9b의 예시는 앵커 재배치와 함께 진행중인 SDT 절차에서 비-SDT 데이터 전송을 지원하기 위한 절차의 예시를 나타낸다.
도 9a 및 도 9b의 예시에 따르면, 단말에 대한 SDT 과정 중에 old NG-RAN이 New NG-RAN에게 UE context와 함께 단말에게 현재 할당한 I-RNTI 값을 같이 전달하는 방법을 제안하고 있다. 따라서 단말이 두번째 RRC Resume Request 메시지를 전송하는 경우, old NG-RAN이 아닌 new NG-RAN에서 Resume MAC-I 검증을 수행할 수 있다. 기본적으로 SDT 과정에서 New NG-RAN으로 UE context가 옮겨진 경우를 가정하고 있다. 또한 New NG-RAN와 Old NG-RAN 모두 CU-CP와 CU-UP, DU로 분리되어 있지 않은 상태를 가정하고 있으나 CU-CP와 CU-UP, DU로 분리되어 있는 경우에 적용 가능하다.
Step 0 ~ Step 3: 도 7a 및 도 7b의 예시의 Step 0~ Step 3과 동일한 방식으로 수행될 수 있다.
Step 4: Old NG-RAN이 해당 단말에 대한 검증을 완료한 후, Old NG-RAN이 해당 단말에 대한 UE context를 new NG-RAN에게 전달하기로 결정할 수 있다. 그러면, Old NG-RAN은 RETRIEVE UE CONTEXT RESPONSE 메시지를 통해 new NG-RAN에게 응답할 수 있다. 이 과정에서 Old NG-RAN은 해당 단말에 대해 old NG-RAN이 할당하였던 I-RNTI 값을 같이 메시지에 포함시켜 new NG-RAN에게 전달할 수 있다.
New NG-RAN은 I-RNTI 값을 전달받으면 이를 UE context 내에 저장할 수 있다. 그리고, New NG-RAN은 Path Switch Request 절차가 끝나는 대로 Old NG-RAN 쪽으로 UE Context Release 절차를 시작해야 함을 알릴 수 있다.
NOTE: 동일한 I-RNTI가 여러 NG-RAN에서 이용되는 것을 막기 위해, Old NG-RAN이 Step 0에서 해당 단말을 RRC_INACTIVE 상태로 천이시킬 때, 2개의 I-RNTI 값을 미리 할당할 수도 있다. Old NG-RAN은 2개의 I-RNTI 값을 RRC Release 메시지 안에 포함시켜 단말에게 전달할 수 있다. 이 경우 단말은 Step 1에서 1번째 RRC Resume Request 메시지를 전송하는 과정에서 1번째 I-RNTI를 메시지에 포함시킬 수 있다. Old NG-RAN은 Step 3에서 해당 단말에 대한 verification이 성공하면 Step 4에서 2번째 I-RNTI 값을 RETRIEVE UE CONTEXT RESPONSE 메시지에 포함시켜 New NG-RAN에게 전달할 수 있다. 단말은 Step 10에서 non-SDT data가 도착하면, Step 1에서 사용하지 않은 I-RNTI 값 (즉, 2번째 I-RNTI)를 2번째 RRC Resume Request 메시지에 포함시켜 네트워크로 전송할 수 있다. 이 경우, New NG-RAN은 Step 4에서 old NG-RAN으로부터 수신한 I-RNTI 값과 Step 11에서 단말로부터 수신한 I-RNTI 값을 비교하여 UE context을 찾을 수 있다.
Step 5 ~ Step 8: 도 7a 및 도 7b의 예시의 Step 5 ~ Step 8과 동일한 방식으로 수행될 수 있다.
Step 9: New NG-RAN은 UE Context Release 메시지를 Old NG-RAN에게 전송함으로써, 해당 단말에 대한 release를 요청할 수 있다. 이를 수신한 old NG-RAN은 해당 단말과 관련된 모든 context를 삭제하고 할당된 resource를 release할 수 있다.
Step 10: 도 7a 및 도 7b의 예시의 Step 9과 동일한 방식으로 수행될 수 있다.
Step 11: 도 7a 및 도 7b의 예시의 Step 10과 동일한 방식으로 수행될 수 있다.
NOTE: 단말은 2번째 RRC Resume Request 메시지를 전송한 뒤, KgNB*1 값에 기초하여 Horizontal Key derivation 또는 Vertical Key derivation을 수행함으로써, KgNB*2를 도출할 수 있다. 이를 통해 단말은 새로운 KRRCint_2와 KRRCenc_2, KUPenc_2 (Optional), 그리고 KUPint_2 (Optional) 값을 계산할 수 있다.
Step 12: New NG-RAN은 단말로부터 2번째 RRC Resume Request 메시지를 수신할 수 있다. 그러면, New NG-RAN은 해당 단말에 대해 non-SDT data가 도착하였으며, 이를 전송하기 위해 RRC_CONNECTED로의 상태 천이가 필요함을 알 수 있다. 따라서 New NG-RAN은 해당 단말에 대한 SDT data 전송을 중단하고 해당 단말에 대한 UE context를 찾을 수 있는지 확인할 수 있다. 즉, New NG-RAN은 Step 4에서 old NG-RAN으로부터 수신한 I-RNTI 값과 단말이 보낸 I-RNTI를 비교하여 New NG-RAN에서 ongoing SDT session (즉, Step 4~8)에 사용한 UE context를 찾을 수 있다. 이후 New NG-RAN은 단말이 보낸 Resume MAC-I가 유효한지 확인할 수 있다.
Step 13: New NG-RAN은 해당 단말에 대한 검증이 통과되면, New NG-RAN은 horizontal vertical key derivation 또는 vertical key derivation을 통하여 UE context에 포함된 KgNB*1로부터 KgNB*2를 도출할 수 있다. 또한 New NG-RAN은 KgNB*2에 기초하여 새로운 KRRCint_2와 KRRCenc_2, KUPenc_2 (Optional), 그리고 KUPint_2 (Optional) 값을 계산할 수 있다.
New NG-RAN은 해당 단말을 RRC_CONNECTED 상태로 천이시키기 위해 RRC Resume 메시지를 생성하여 단말에게 전송할 수 있다. New NG-RAN은 앞서 도출한 KgNB*2를 이용하여 RRC Resume 메시지를 encryption 하며, 단말은 Step 11에서 계산한 KgNB*2를 기반으로 해당 RRC 메시지를 decryption 할 수 있다.
NOTE: 만약 New NG-RAN이 CU-CP, CU-UP, DU로 구성되어 있는 경우, New NG-RAN의 CU-CP는 KgNB*2를 기반으로 새로운 KRRCint_2와 KRRCenc_2, KUPenc_2 (Optional), 그리고 KUPint_2 (Optional) 값을 계산할 수 있다. 그리고 E1AP 메시지 (e.g., BEARER CONTEXT SETUP REQUEST, BEARER CONTEXT MODIFICATION REQUEST, or New message)를 통하여 New NG-RAN의 CU-UP에게 UP security key의 변경일 알릴 수 있다. 이 과정에서 New NG-RAN의 CU-CP는 SDT Bearer에 관련된 PDCP가 COUNT 값을 초기화하지 말라고 New NG-RAN의 CU-UP에게 같이 알릴 수 있다. 이를 통해 New NG-RAN은 해당 단말을 RRC_CONNECTED 상태로 천이시킨 후 step 12에서 전송이 중단된 SDT data를 다시 단말과 교환할 수 있다.
NOTE: 만약 New NG-RAN이 CU-CP, CU-UP, DU로 구성되어 있는 경우, New NG-RAN의 CU-CP는 SDT 전송 과정에서 사용하던 UE Context를 그대로 활용할 수도 있다. 이 경우, New NG-RAN의 CU-CP는 New NG-RAN의 DU에게 UE CONTEXT MODIFICATION REQUEST 메시지를 보내 Non-SDT bearer (e.g., Bearer configuration, F1 UL TEIDs)에 대한 셋업을 요청할 수 있다. 이때 해당 단말에 대한 SDT 과정에서 New NG-RAN의 CU-CP는 New NG-RAN의 DU가 설정한 old gNB-DU UE F1AP ID를 같이 전달할 수 있다. 이를 통하여 New NG-RAN의 DU는 해당 단말이 SDT bearer 외에 추가로 non-SDT bearer를 셋업하려고 시도하는 것을 알 수 있다. 이를 통해 New NG-RAN의 DU는 해당 단말을 위해 설정하였던 SDT bearer, CG configuration 등의 정보를 그대로 활용할 수 있다.
만약 New NG-RAN의 DU가 old gNB-DU UE F1AP ID를 통해 UE context를 찾는데 실패한다면, New NG-RAN의 DU는 이와 관련된 새로운 cause value를 통해 New NG-RAN의 CU에게 알릴 수 있다. 이 경우 New NG-RAN의 CU는 New NG-RAN의 DU에서 다시 새로운 UE context을 생성하기 위한 절차를 시작할 수 있다.
2. 본 명세서의 개시의 제2예
이하에서, 도 10a 및 10b의 예시를 참조하여, 본 명세서의 개시의 제1예를 설명하기로 한다.
본 명세서의 개시의 제2예는 앵커 재배치를 사용하지 않는 SDT 절차에 관련된 예시를 설명한다.
이하의 도면은 본 명세서의 구체적인 일례를 설명하기 위해 작성되었다. 도면에 기재된 구체적인 장치의 명칭이나 구체적인 신호/메시지/필드의 명칭은 예시적으로 제시된 것이므로, 본 명세서의 기술적 특징이 이하의 도면에 사용된 구체적인 명칭에 제한되지 않는다.
도 10a 및 도 10b는 본 명세서의 개시의 제2예에 따른 신호 흐름도를 나타낸다.
예를 들어, 도 10a 및 10b의 예시는 앵커 재배치가 없이, 진행중인 SDT 절차에서 비-SDT 데이터 전송을 지원하기 위한 절차의 예시를 나타낸다.
예를 들어, 도 10a 및 10b의 예시는 앵커 재배치 없이, 진행중인 SDT 절차에서 비-SDT 데이터 전송을 지원하기 위한 절차의 예시를 나타낸다.
도 10a 및 10b의 예시에 따르면, 도 7a 및 도7b의 예시에 따르면, 단말이 Non-SDT bearer을 통해 전송해야 될 data가 생겼다는 사실을 old NG-RAN에게 알릴 수 있다. 그러면, old NG-RAN이 해당 단말에 대한 verification을 진행한 후 새로운 security key를 생성하여 new NG-RAN에게 전달할 수 있 있다. 기본적으로, SDT 과정에서 New NG-RAN으로 일부 UE context만 옮겨진 경우가 가정된다. 또한, 본 명세서의 개시에서는 New NG-RAN와 Old NG-RAN 모두 CU-CP와 CU-UP, DU로 분리되어 있지 않은 상태를 가정하고 있으나, 이는 예시에 불과하며, 본 명세서의 개시에서 설명하는 내용은 New NG-RAN 및/또는 Old NG-RAN이 CU-CP와 CU-UP, DU로 분리되어 있는 경우도 적용될 수 있다.
Step 0 ~ Step 3: 도 7a 및 도 7b의 예시의 Step 0~ Step 3과 동일한 방식으로 수행될 수 있다.
Step 4: Old NG-RAN이 해당 단말에 대한 검증이 끝내고 난 뒤 해당 단말에 대한 UE context를 old NG-RAN이 여전히 유지하기로 결정할 수 있다. 그러면, Old NG-RAN은 PARTIAL UE CONTEXT TRANSFER 메시지를 new NG-RAN에게 전송할 수 있다. 해당 XnAP 메시지는 new NG-RAN이 단말에 대한 SDT를 지원하는데 필요한 일부 UE context (즉, RLC layer configuration for SDT bearer, DRB ID, UL TNL Address Information 등)를 포함하고 있다.
Step 5: 도 7a 및 도 7b의 예시의 Step 5와 동일한 방식으로 수행될 수 있다.
Step 6: New NG-RAN은 Msg B 또는 Msg 4를 통해 단말에게 응답할 수 있다. 이 과정에서 단말에게 전달할 DL data가 있다면, New NG-RAN은 DL data를 RRC message와 같이 multiplexing 하여 전송할 수 있다.
이후에 단말과 5GC는 New NG-RAN을 통하여 SDT data를 교환할 수 있다.
Step 7: 도 7a 및 도 7b의 예시의 Step 9와 동일한 방식으로 수행될 수 있다.
Step 8: 도 7a 및 도 7b의 예시의 Step 10과 동일한 방식으로 수행될 수 있다.
Step 9: 도 7a 및 도 7b의 예시의 Step 11과 동일한 방식으로 수행될 수 있다.
Step 10: 도 7a 및 도 7b의 예시의 Step 12와 동일한 방식으로 수행될 수 있다.
Step 11: Old NG-RAN이 해당 단말에 대한 검증이 끝내고 난 뒤 해당 단말에 대한 UE context를 new NG-RAN에게 전달하기로 결정하면, Old NG-RAN은 RETRIEVE UE CONTEXT RESPONSE 메시지를 통해 new NG-RAN에게 응답할 수 있다. 이때 Old NG-RAN은 Step 10에서 얻은 security key KgNB*2와 NCC 값을 같이 메시지에 포함시켜, new NG-RAN에게 전달할 수 있다.
해당 단말을 RRC_CONNECTED로 천이시키고 non-SDT data에 대한 전송을 지원하는 과정에서, New NG-RAN이 Step 4에서 수신한 SDT bearer와 관련된 UE context를 계속해서 사용할 수 있도록 하기 위해, old NG-RAN은 다음의 동작을 수행할 수 있다. 예를 들어, old NG-RAN은 New NG-RAN 이 step 2 과정에서 할당하였던 New NG-RAN UE XnAP ID_1을 같이 RETRIEVE UE CONTEXT RESPONSE 메시지에 포함시킬 수 있다. 이를 기반으로 New NG-RAN은 Step 4에서 수신한 이후 SDT 전송을 위하여 사용 중이던 UE context를 찾을 수 있고 이를 계속해서 활용할 수 있다. 또한 이를 통해 new NG-RAN은 해당 단말에 대해 non-SDT data가 발생했음을 알 수 있고, 따라서 해당 단말에 대한 SDT 전송을 중단할 수 있다. New NG-RAN이 New NG-RAN UE XnAP ID_1를 통해 SDT bearer와 관련된 UE context를 찾는데 실패할 수도 있다. 이 경우, New NG-RAN은 RETRIEVE UE CONTEXT RESPONSE 메시지 안에 포함된 UE context를 활용하여 SDT bearer에 대한 UE context를 다시 생성할 수 있다.
New NG-RAN은 수신한 KgNB*2를 기반으로 새로운 KRRCint_2와 KRRCenc_2, KUPenc_2 (Optional), 그리고 KUPint_2 (Optional) 값을 계산할 수 있다.
NOTE: Old NG-RAN의 CU-CP는 New NG-RAN의 CU-CP을 통해 New NG-RAN의 CU-UP에게 Step 11에서 SDT Bearer에 관련된 PDCP가 COUNT 값을 초기화하지 말라는 것을 같이 알릴 수 있다. 이를 통해 New NG-RAN은 해당 단말을 RRC_CONNECTED 상태로 천이시킨 후 step 11에서 전송이 중단된 SDT data를 다시 단말과 교환할 수 있다.
NOTE: 만약 New NG-RAN이 CU-CP, CU-UP, DU로 구성되어 있는 경우, New NG-RAN의 CU-CP는 SDT 전송 과정에서 사용하던 UE Context를 그대로 활용할 수도 있다. 이 경우, New NG-RAN의 CU-CP는 New NG-RAN의 DU에게 UE CONTEXT MODIFICATION REQUEST 메시지를 보내 Non-SDT bearer (e.g., Bearer configuration, F1 UL TEIDs)에 대한 셋업을 요청할 수 있다. 이때 해당 단말에 대한 SDT 과정에서 New NG-RAN의 CU-CP는 New NG-RAN의 DU가 설정한 old gNB-DU UE F1AP ID를 같이 전달할 수 있다. 이를 통하여 New NG-RAN의 DU는 해당 단말이 SDT bearer 외에 추가로 non-SDT bearer를 셋업하려고 시도하는 것을 알 수 있다. 이를 통해 New NG-RAN의 DU는 해당 단말을 위해 설정하였던 SDT bearer, CG configuration 등의 정보를 그대로 활용할 수 있다.
만약 New NG-RAN의 DU가 old gNB-DU UE F1AP ID를 통해 UE context를 찾는데 실패한다면, New NG-RAN의 DU는 이와 관련된 새로운 cause value를 통해 New NG-RAN의 CU에게 알릴 수 있다. 이 경우 New NG-RAN의 CU는 New NG-RAN의 DU에서 다시 새로운 UE context을 생성하기 위한 절차를 시작할 수 있다.
NOTE: Step 11에서 전송된 RETRIEVE UE CONTEXT RESPONSE 메시지는 step 2에서 전송된 RETRIEVE UE CONTEXT REQUEST 메시지에 대한 응답일 수 있다. 이 경우, Old NG-RAN으ㄴ New NG-RAN UE XnAP ID_1이 아닌 New NG-RAN UE XnAP ID_2를 추가로 RETRIEVE UE CONTEXT RESPONSE 메시지에 포함시킬 수 있다.
Step 12: New NG-RAN은 해당 단말을 RRC_CONNECTED 상태로 천이시키기 위해 RRC Resume 메시지를 생성하여 단말에게 전송할 수 있다. New NG-RAN은 Step 11에서 수신한 KgNB*2를 이용하여 RRC Resume 메시지를 encryption할 수 있다. 그러면, 단말은 Step 8에서 계산한 KgNB*2를 기반으로 해당 RRC 메시지를 decryption 할 수 있다.
Step 13: New NG-RAN은 Old NG-RAN에게 UE Context Release 메시지를 전송하여 해당 단말에 대한 release를 요청할 수 있다. 이를 수신한 old NG-RAN은 해당 단말과 관련된 모든 context를 삭제하고 할당된 resource를 release할 수 있다.
3. 본 명세서의 개시의 제3예
이하에서, 본 명세서의 개시의 제3예를 설명하기로 할 수 있다. 참고로, 본 명세서의 개시의 제3예는 앞서 설명한 본 명세서의 개시의 제1예 및/또는 제2예에서 설명한 다양한 예시들이 구체적으로 적용되는 예시일 수 있다.
본 명세서의 개시의 제3예에에 따르면, non-SDT 베어러에 대한 UL 데이터가 있는 경우 UE는 진행 중인 SDT 세션을 중단한 다음 이 non-SDT 데이터 도착을 네트워크에 표시하는 절차를 시작할 수 있다. 이를 지원하기 위한 솔루션 중 하나는 UE가 이전 앵커 gNB에서 발행한 I-RNTI를 사용하여 두 번째 RRCResumeRequest 메시지를 전송하고 수평 키 도출(horizontal key derivation)를 수행하는 것이다. 이러한 절차와 관련된 흐름도의 예시는 앞서 설명한 도 6a 및 도 6b의 예시와 같다.
앞서 설명한 바와 같이, 아래의 예시와 같은 문제점이 존재한다:
일례로, 어느 노드(이전 앵커 gNB 또는 서빙 gNB)가 이전 앵커 gNB와 연관된 I-RNTI로 두 번째 RRCResumeRequest 메시지를 처리하고 ResumeMAC-I 검증 및 키 유도를 수행할지 불분명하다; 및/또는
다른 일례로, 이전 앵커 gNB 및/또는 서빙 gNB는 UE가 전송한 명시적 표시를 통해 두 번째 RRCResumeRequest 메시지를 구별할 수 있는지 불분명하다.
앵커 재배치가 없는 SDT(예: Random Access Channel (RACH) based SDT (RA-SDT))에서 두 번째 RRCResumeRequest 메시지를 수신했을 때 서빙 gNB는 I-RNTI 기반의 UE 컨텍스트를 찾지 못했다. 따라서 서빙 gNB는 I-RNTI에 포함된 노드 ID를 확인하고 Retrieve UE Context 절차를 시작하여 이전 앵커 gNB에게 UE 컨텍스트를 제공하도록 요청할 수 있다. 따라서 이 경우 기존 앵커 gNB는 ResumeMAC-I 검증 및 키 유도를 수행할 수 있다.
Observation 1: 앵커 재배치가 없는 RA-SDT에서는 이전 앵커 gNB가 ResumeMAC-I 검증 및 키 유도를 수행하는 것이 자연스러울 수 있다.
앵커 재배치가 있는 SDT에서 SDT 세션이 진행 중이지만 서빙 gNB가 Retrieve UE Context 절차 후 old anchor gNB로 XnAP UE Context Release 절차를 아직 시작하지 않은 경우, 두 gNB 모두 일시적으로 전체 UE 컨텍스트를 가질 수 있다. 이 경우, UE가 두 번째 RRCResumeRequest 메시지를 전송하면, I-RNTI가 이전 앵커 gNB에 의해 할당되었기 때문에, 서빙 gNB는 두 번째 RRCResumeRequest 메시지에 포함된 I-RNTI에 기초하여 UE 컨텍스트를 찾지 못할 수 있다. 따라서 앵커 재배치가 없는 RA-SDT에서와 같이 서빙 gNB는 Retrieve UE Context 절차를 시작할 수 있다. 그런 다음 이전 앵커 gNB는 ResumeMAC-I 검증 및 키 유도를 수행할 수 있다.
서빙 gNB가 ResumeMAC-I 검증 및 키 도출를 수행하기 위해서는 기존 앵커 gNB가 할당한 I-RNTI를 SDT 절차가 진행되는 동안 서빙 gNB에 제공해야 하므로 서로 다른 두 gNB에서 동일한 I-RNTI를 재사용할 수도 있다. 한편, 이러한 재사용은 피해야 할 수도 있다.
Observation 2: 앵커 재배치가 있는 RA-SDT에서도 이전 앵커 gNB는 ResumeMAC-I 검증 및 키 도출을 수행해야 한다.
Observation 1, 2에 기초하여, 다음과 같은 proposal을 제안한다.
Proposal 1: 이전 앵커 gNB는 두 번째 RRCResumeRequest 메시지를 처리한 다음 ResumeMAC-I 검증 및 키 도출을 수행해야 한다.
앞서 언급한 두번째 문제에 관련하여, UE는 SDT에 대한 첫 번째 RRCResumeRequest 메시지의 경합 해결(contention resolution)이 완료되기 전에 보안 키가 업데이트된 두 번째 RRCResumeRequest 메시지를 보낼 수 있다고 가정한다. 첫 번째 RRCResumeRequest 메시지가 손실되었지만 두 번째 메시지를 이전 앵커 gNB로 보낼 수 있는 경우 이전 앵커 gNB는 두 번째 RRCResumeRequest 메시지에서 ResumeMAC-I를 확인하는 데 어떤 보안 키(즉, KRRCint_0 또는 KRRCint_1)가 사용되었는지 알지 못한다. 이 문제를 피하기 위해 가능한 한 가지 해결책은 UE가 두 번째 RRCResumeRequest 메시지를 구별하기 위한 명시적 표시를 포함하는 것이다. 그러나 이는 RRC 관점에서 스펙에 영향을 미칠 수 있다. 또 다른 해결책은 이전 앵커 gNB가 각 보안 키를 기반으로 ResumeMAC-I 검증을 두 번 수행하는 것이다. 이는 스펙에 영향을 주지 않고 구현할 수 있다. gNB 관점에서 후자의 방안이 더 바람직할 수 있다.
Proposal 2: gNB 관점에서 두 번째 RRRCResumeRequest 메시지를 구분하기 위해 UE가 보낸 명시적 지시가 제공되지 않는다.
이 CCCH 솔루션을 지원하기 위해 일부 스펙 업데이트가 필요할 수 있다.
앵커 재배치가 있는 RA-SDT에서 SDT 세션이 진행되는 동안 이전 앵커 gNB는 두 번째 RRCResumeRequest 메시지를 수신할 때 ResumeMAC-I를 확인하기 위해 UE 컨텍스트를 유지해야 한다. 따라서 서빙 gNB는 진행 중인 SDT 세션 동안 이전 앵커 gNB를 향한 UE 컨텍스트 해제 절차의 시작을 유지해야 한다. 이는 추후 스펙 업데이트에 반영될 수 있다.
또한 non-SDT 데이터 도착을 알리는 두 번째 RRCResumeRequest 메시지를 수신한 경우, 이전 앵커 gNB는 ResumeMAC-I 검증 후 새로운 보안 키 KgNB*2를 도출하고 이 도출된 보안 키를 서빙 gNB에 제공한다. 이 시나리오에서 ResumeMAC-I의 성공적인 검증을 서빙 gNB에 알리고 업데이트된 보안 키를 제공하는 방법이 논의되어야 한다. 솔루션 중 하나는 RETRIEVE UE CONTEXT RESPONSE 메시지를 사용하여 업데이트된 보안 키를 서빙 gNB에 제공하는 것다. 그러나 UE 컨텍스트는 진행 중인 SDT 절차 중에 이미 서빙 gNB로 전송된다. 그런 다음 서빙 gNB는 경로 전환 요청 절차 중에 UE 컨텍스트에서 일부 매개 변수를 변경할 수 있다. 따라서 old anchor gNB가 RETRIEVE UE CONTEXT RESPONSE 메시지에 UE context를 포함시켜 재전송하면 UE context의 일부 IE가 outdated일 수 있다. 또한 기존 절차에 따르면 RETRIEVE UE CONTEXT RESPONSE 메시지를 수신하면 서빙 gNB는 5GC를 향한 경로 전환 요청 절차를 시작해야 한다. 그러나 이 시나리오에서는 서빙 gNB가 이미 5GC에 대한 UE 관련 시그널링 연결을 설정하고 UP 경로를 전환하기 때문에 이 단계를 건너뛰어야 한다. 따라서 서빙 gNB에 업데이트된 보안 키를 제공하기 위해 RETRIEVE UE CONTEXT RESPONSE 메시지를 사용하는 것은 합리적이지 않은 수도 있다.
또 다른 해결책은 업데이트된 보안 키를 RETRIEVE UE CONTEXT FAILURE 메시지에 포함시키는 것이다. 이 정보를 기반으로 서빙 gNB는 non-SDT 데이터가 UE에 도착했고 ResumeMAC-I가 성공적으로 검증되었다고 간주할 수 있다. 그런 다음 서빙 gNB는 이전 앵커 gNB의 보안 키 KgNB*2를 기반으로 UP 및 CP 키를 계산할 수 있다. 이 경우 경로 전환 요청 절차를 시작할 필요가 없다.
Observation 3: 두 번째 RRCResumeRequest 메시지에서 ResumeMAC-I의 성공적인 검증 후, 이전 앵커 gNB는 업데이트된 보안 키 KgNB*2를 포함하여 RETRIEVE UE CONTEXT FAILURE 메시지를 전송해야 한다.
또한 서빙 gNB가 진행 중인 SDT 절차에서 제공되는 UE 컨텍스트를 계속 사용하기 위해서는 old anchor gNB가 old UE를 제공해야 한다. 진행 중인 SDT 절차 중에 서빙 gNB가 할당한 XnAP ID이다.
Observation 4: 이전 앵커 gNB는 진행 중인 SDT 절차 중에 서빙 gNB가 할당한 이전 UE XnAP ID를 전송해야 한다.
관찰을 기반으로 다음과 같은 proposal들도 제안한다.
Proposal 3: RAN3 관점에서 CCCH 솔루션이 실현 가능하다.
Proposal 4: 비SDT 데이터 도착을 위해 CCCH 솔루션이 채택되는 경우, CCCH 솔루션을 지원하는 방법을 추가로 논의될 수 있다.
본 명세서의 개시의 제3예에 따르면, 이하의 예시들이 제안될 수 있다:
Proposal 1: 이전 앵커 gNB는 두 번째 RRCResumeRequest 메시지를 처리한 다음 ResumeMAC-I 검증 및 키 도출을 수행해야 한다.
Proposal 2: gNB 관점에서 두 번째 RRRCResumeRequest 메시지를 구분하기 위해 UE가 보낸 명시적 지시가 제공되지 않는다.
Proposal 3: RAN3 관점에서 CCCH 솔루션이 실현 가능하다.
Proposal 4: 비SDT 데이터 도착을 위해 CCCH 솔루션이 채택되는 경우, CCCH 솔루션을 지원하는 방법을 추가로 논의될 수 있다.
4. 본 명세서의 개시의 제4예
이하에서, 도 11의 예시를 참조하여, 본 명세서의 개시의 제4예를 설명하기로 한다.
본 명세서의 개시의 제4예는, 앞서 다양한 예시를 통해 설명한 본 명세서의 개시의 제1예, 제2예, 및/또는 제3예 중 적어도 하나의 예에 대해 적용될 수 있는, UE의 동작의 예시, New NG-RAN의 동작의 예시, old NG-RAN의 동작의 예시, 5GC(예: SMF, AMF, 및/또는 UPF 등)의 동작의 예시를 나타낼 수 있다.
이하에서, 도 11의 예시에서 설명하는 동작은 예시에 불과하며, 본 명세서의 개시의 범위에서, UE, New NG-RAN, Old NG-RAN, 5GC 등의 동작은 도 11의 예시에 의해 제한되지 않는다. 예를 들어, 도 11의 예시에 도시되지 않더라도, UE, New NG-RAN, Old NG-RAN, 5GC 등은 본 명세서의 개시의 제1예, 제2예, 및/또는 제3예에서 설명한 동작들을 수행할 수 있다. 예를 들어, 도 11의 예시에 도시되지 않더라도, UE, New NG-RAN, Old NG-RAN, 5GC 등은, 앞서 설명한 도 6a 및 도 6b의 예시, 도 7a 및 도 7b의 예시, 도 8a 및 도 8b의 예시, 도 9a 및 도 9b의 예시 및/또는 도 10a 및 도 10b의 예시에서 설명한 동작들을 수행할 수 있다.
이하의 도면은 본 명세서의 구체적인 일례를 설명하기 위해 작성되었다. 도면에 기재된 구체적인 장치의 명칭이나 구체적인 신호/메시지/필드의 명칭은 예시적으로 제시된 것이므로, 본 명세서의 기술적 특징이 이하의 도면에 사용된 구체적인 명칭에 제한되지 않는다.
도 11은 본 명세서의 개시의 제4예에 따른 신호 흐름도를 나타낸다.
도 11의 예시는 SDT에 관련된 통신을 수행하는 일 예를 나타낸다. 예를 들어, 도 11의 예시는 SDT 절차가 진행중인 상황에서 비-SDT 데이터의 전송을 지원하기 위한 동작의 예시를 나타낸다.
참고로, New NG-RAN은 New gNB, 서빙 gNB를 의미할 수 있다. Old NG-RAN은 Old gNB, Last serving gNB를 의미할 수 있다.
참고로, 단계(S1101)은 SDT 절차가 진행 중인 상황에서, UE에게 non-SDT 데이터가 발생한 이후에 수행되는 동작일 수 있다.
예를 들어, 단계(S1101)가 수행되기 전에, 도 6a 및 도 6b의 예시의 step 1 내지 step 14가 수행될 수 있다. 예를 들어, 단계(S1101)가 수행되기 전에, 도 7a 및 도 7b의 예시 의 step 1 내지 step 9가 수행될 수 있다. 예를 들어, 단계(S1101)가 수행되기 전에, 도 8a 및 도 8b의 예시 의 step 1 내지 step 9가 수행될 수 있다. 예를 들어, 단계(S1101)가 수행되기 전에, 도 9a 및 도 9b의 예시 의 step 1 내지 step 10이 수행될 수 있다. 예를 들어, 단계(S1101)가 수행되기 전에, 도 10a 및 도 10b의 예시 의 step 1 내지 step 7이 수행될 수 있다.
단계(S1101)에서, UE는 RRC Resume Request 메시지를 New NG-RAN에게 전송할 수 있다.
단계(S1102)에서, New NG-RAN은 요청 메시지를 old NG-RAN에게 전송할 수 있다. 요청 메시지는 UE XnAP ID 및 I-RNTI를 포함할 수 있다.
Old NG-RAN은 I-RNTI에 기초하여 UE를 검증할 수 있다. 예를 들어, Old NG-RAN은 I-RNTI에 기초하여 UE의 UE context를 찾을 수 있다. Old NG-RAN은 UE가 전송한 Resume MAC-I가 유효한지 확인할 수 있다. 그리고, Old NG-RAN은 horizontal key derivation을 통해, UE context에 포함된 KgNB*1로부터 보안 키 KgNB*2를 도출할 수 있다.
단계(S1103)에서, Old NG-RAN은 응답 메시지를 New NG-RAN에게 전송할 수 있다. 응답 메시지는 이전에 New NG-RAN가 할당하였던 UE XnAP ID를 포함할 수 있다. New NG-RAN은 자신이 할당했던 UE XnAP ID를 수신함으로써, 비-SDT 데이터가 발생했다는 거슬 알 수 있다. 그리고, New NG-RAN은 UE에 대한 SDT 전송을 중단할 수도 있다. 또한, 응답 메시지는 예를 들어 보안 키 KgNB*2를 포함할 수 있다.
참고로, 도 9a 및 도 9b의 예시에 따른 동작이 수행되는 경우, 단계(S1102) 및 단계(S1103)은 수행되지 않을 수도 있다. 예를 들어, 도 9a 및 도 9b의 예시에 따른 경우, 단계(S1101)이 수행된 이후, New NG-RAN이 UE에 대한 검증을 수행할 수 있다.
단계(S1104)에서, New NG-RAN은 RRC 메시지를 UE에게 전송할 수 있다. 예를 들어, New NG-RAN은 보안 키 KgNB*2를 사용하여 RRC 메시지를 encryption할 수 있다.
참고로, 도 11의 예시에서, 요청 메시지는 RETRIEVE UE CONTEXT REQUEST 메시지이고 응답 메시지는 RETRIEVE UE CONTEXT FAILURE 메시지일 수 있다. 또는, 응답 메시지는 RETRIEVE UE CONTEXT RESPONSE 메시지일 수도 있다.
다양한 도면을 참조하여 설명된 본 명세서의 개시의 다양한 예시들은, 개별적으로 수행될 수도 있고, 다른 예시들과 함께 수행될 수도 있다.
다양한 예시들을 참조하여 본 명세서의 개시에서 설명한 바에 따르면, 단말의 non-SDT data 전송을 지원하기 위해, old NG-RAN은 단말에 대한 verification 을 끝마친 후 new NG-RAN이 RRC_CONNECTED 상태에서 사용할 security key 값을 생성하여 전달할 수 있다. 또한 만약 new NG-RAN이 SDT 과정 동안 AMF와 Path Switch Request 과정까지 이미 끝마친 경우 해당 과정을 다시 반복하지 않도록 이를 알리는 추가적인 indication을 같이 전달할 수 있다. 또한 New NG-RAN이 SDT 과정에서 사용하던 UE context를 계속해서 이용할 수 있도록, New NG-RAN이 SDT 과정에서 할당하였던 New NG-RAN UE XnAP ID_1을 같이 전달하여 New NG-RAN이 SDT 과정에서 사용하였던 기존 UE context을 찾을 수 있도록 할 수 있다.
다양한 예시들을 참조하여 본 명세서의 개시에서 설명한 바에 따르면, Non-SDT data 전송을 지원하기 위해 해당 단말이 SDT 전송을 중단한 뒤 다시 RRC connection을 맺지 않고, SDT 전송 중간에 RRC_CONNECTED 상태로 천이하여 non-SDT data를 전송할 수 있도록 하여 단말의 불필요한 동작을 막을 수 있다. 특히 단말을 RRC_CONNECTED 상태로 천이시키는 과정에서 단말을 serving하는 gNB를 바꿀 수 있는 방법을 제안하여 단말의 빠른 상태 천이를 도울 수 있다.
다양한 예시들을 참조하여 본 명세서의 개시에서 설명한 바에 따르면, SDT가 진행 중인 과정에서 Non-SDT data가 단말에 발생할 경우, 해당 단말이 빠르게 RRC_CONNECTED 상태로 천이하도록 하여 non-SDT data에 대한 빠른 전송을 지원할 수 있다. 또한 기존에 진행 중이던 SDT에서 사용한 UE context를 계속해서 활용할 수 있도록 하여, new NG-RAN이 동일 단말에 대해 UE context를 반복해서 생성하고 5GC로 UP path 변경을 요청하는 것을 막을 수 있다.
다양한 예시들을 참조하여 본 명세서의 개시에서 설명한 바에 따르면, 이동통신시스템에서 RRC_INACTIVE 상태에서 small data transmission을 진행하던 단말을 RRC_CONNECTED 상태로 천이시키기 위한 방법이 제안될 수 있다. 예를 들어, 단말은 제 2 무선 네트워크에게 다시 한 번 RRC Resume Request 메시지를 전달할 수 있다. 예를 들어, 제 2 무선 네트워크는 해당 단말에 대한 resume MAC-I 검증을 이해 RRC Resume Request 메시지를 제 1 무선 네트워크에게 전달할 수 있다. 예를 들어, 제 1 무선 네트워크는 해당 단말에 대한 검증이 성공하면 앞선 SDT 과정에서 할당하였던 제 2 무선 네트워크가 할당하였던 New NG-RAN UE XnAP ID와 함께 새롭게 구한 Security key를 같이 제 2 무선 네트워크에게 전달할 수 있다. 이를 통해, 제2 무선 네트워크는 해당 단말이 non-SDT data 발생으로 인해 RRC_INACTIVE 상태의 SDT에서 RRC_CONNECTED 상태로 천이되어야 함을 제1 무선 네트워크에게 알릴 수 있다. 제 2 무선 네트워크는 해당 단말에 대해 이전에 할당된 UE context에 추가하여 새로운 bearer를 생성한 뒤 단말에게 RRC Resume 메시지를 통해 RRC-CONNECTED 상태로 천이하라고 명령할 수 있다.
참고로, 본 명세서에서 설명한 단말(예: UE)의 동작은 앞서 설명한 도 1 내지 도 3의 장치에 의해 구현될 수 있다. 예를 들어, 단말(예: UE)은 도 2의 제1 장치(100) 또는 제2 장치(200)일 수 있다. 예를 들어, 본 명세서에서 설명한 단말(예: UE)의 동작은 하나 이상의 프로세서(102 또는 202)에 의해 처리될 수 있다. 본 명세서에서 설명한 단말의 동작은 하나 이상의 프로세서(102 또는 202)에 의해 실행가능한 명령어/프로그램(e.g. instruction, executable code)의 형태로 하나 이상의 메모리(104 또는 204)에 저장될 수 있다. 하나 이상의 프로세서(102 또는 202)는 하나 이상의 메모리(104 또는 204) 및 하나 이상의 송수신기(105 또는 206)을 제어하고, 하나 이상의 메모리(104 또는 204)에 저장된 명령어/프로그램을 실행하여 본 명세서의 개시에서 설명한 단말(예: UE)의 동작을 수행할 수 있다.
또한, 본 명세서의 개시에서 설명한 단말(예: UE)의 동작을 수행하기 위한 명령어들은 기록하고 있는 비휘발성 컴퓨터 판독가능 저장 매체에 저장될 수도 있다. 상기 저장 매체는 하나 이상의 메모리(104 또는 204)에 포함될 수 있다. 그리고, 저장 매체에 기록된 명령어들은 하나 이상의 프로세서(102 또는 202)에 의해 실행됨으로써 본 명세서의 개시에서 설명한 단말(예: UE)의 동작을 수행할 수 있다.
참고로, 본 명세서에서 설명한 네트워크 노드(예: 5GC, AMF, SMF, UPF 등) 또는 기지국(예: New NG=RAN, NG-RAN, Old NG-RAN, serving gNB, last serving gNB 등)의 동작은 이하 설명될 도 1 내지 도 3의 장치에 의해 구현될 수 있다. 예를 들어, 네트워크 노드 또는 기지국은 도 2의 제1 장치(100) 또는 제2 장치(200)일 수 있다. 예를 들어, 본 명세서에서 설명한 네트워크 노드 또는 기지국의 동작은 하나 이상의 프로세서(102 또는 202)에 의해 처리될 수 있다. 본 명세서에서 설명한 단말의 동작은 하나 이상의 프로세서(102 또는 202)에 의해 실행가능한 명령어/프로그램(e.g. instruction, executable code)의 형태로 하나 이상의 메모리(104 또는 204)에 저장될 수 있다. 하나 이상의 프로세서(102 또는 202)는 하나 이상의 메모리(104 또는 204) 및 하나 이상의 송수신기(106 또는 206)을 제어하고, 하나 이상의 메모리(104 또는 204)에 저장된 명령어/프로그램을 실행하여 본 명세서의 개시에서 설명한 네트워크 노드 또는 기지국의 동작을 수행할 수 있다.
또한, 본 명세서의 개시에서 설명한 네트워크 노드 또는 기지국의 동작을 수행하기 위한 명령어들은 기록하고 있는 비휘발성(또는 비일시적) 컴퓨터 판독가능 저장 매체에 저장될 수도 있다. 상기 저장 매체는 하나 이상의 메모리(104 또는 204)에 포함될 수 있다. 그리고, 저장 매체에 기록된 명령어들은 하나 이상의 프로세서(102 또는 202)에 의해 실행됨으로써 본 명세서의 개시에서 설명한 네트워크 노드 또는 기지국의 동작을 수행할 수 있다.
이상에서는 바람직한 실시예를 예시적으로 설명하였으나, 본 명세서의 개시는 이와 같은 특정 실시예에만 한정되는 것은 아니므로, 본 명세서의 사상 및 특허청구범위에 기재된 범주 내에서 다양한 형태로 수정, 변경, 또는 개선될 수 있다.
상술한 예시적인 시스템에서, 방법들은 일련의 단계 또는 블록으로써 순서도를 기초로 설명되고 있지만, 설명되는 단계들의 순서에 한정되는 것은 아니며, 어떤 단계는 상술한 바와 다른 단계와 다른 순서로 또는 동시에 발생할 수 있다. 또한, 당업자라면 순서도에 나타낸 단계들이 배타적이지 않고, 다른 단계가 포함되거나 순서도의 하나 또는 그 이상의 단계가 권리범위에 영향을 미치지 않고 삭제될 수 있음을 이해할 수 있을 것이다.
본 명세서에 기재된 청구항들은 다양한 방식으로 조합될 수 있다. 예를 들어, 본 명세서의 방법 청구항의 기술적 특징이 조합되어 장치로 구현될 수 있고, 본 명세서의 장치 청구항의 기술적 특징이 조합되어 방법으로 구현될 수 있다. 또한, 본 명세서의 방법 청구항의 기술적 특징과 장치 청구항의 기술적 특징이 조합되어 장치로 구현될 수 있고, 본 명세서의 방법 청구항의 기술적 특징과 장치 청구항의 기술적 특징이 조합되어 방법으로 구현될 수 있다.

Claims (12)

  1. 제1 New Generation Radio Access Node (NG-RAN) 노드가 통신을 수행하는 방법으로서,
    제1 UE XnAP ID 및 I-RNTI를 포함하는 RETRIEVE UE CONTEXT 요청 메시지를 제2 NG-RAN 노드로부터 수신하는 단계;
    상기 I-RNTI에 기초하여, User Equipment (UE)에 대한 검증을 수행하는 단계; 및
    RETRIEVE UE CONTEXT 요청 메시지에 대한 응답으로, 응답 메시지를 상기 제2 NG-RAN 노드에게 전송하는 단계를 포함하고,
    상기 응답 메시지는 상기 UE에 관련된 제2 UE XnAP ID 및 보안 키를 포함하고,
    상기 UE에 관련된 상기 제2 UE XnAP ID는 상기 제1 NG-RAN 노드가 상기 제2 NG-RAN 노드로부터 이전에 수신했고,
    상기 제2 UE XnAP ID는 상기 제2 NG-RAN 노드가 Small Data Transmission (SDT) 전송을 위해 사용되었던 UE 컨텍스트를 비-SDT 전송을 위해 사용하도록 하는 것을 특징으로 하는 방법.
  2. 제1항에 있어서,
    상기 검증을 수행하는 단계는,
    상기 I-RNTI에 기초하여 상기 UE에 대한 UE context를 찾을 수 있는지 확인하는 단계; 및
    상기 UE context에 기초하여, 상기 RETREIVE UE CONTEXT 요청 메시지에 포함된 Resume MAC-I가 유효한지 확인하는 단계를 더 포함하는 방법.
  3. 제2항에 있어서,
    상기 검증이 수행된 이후, 수평 키 도출 (horizontal key derivation)에 기초하여 상기 보안 키를 도출하는 단계를 더 포함하는 방법.
  4. 제1항에 있어서,
    상기 보안 키는 상기 제2 NG-RAN 노드가 상기 UE에게 전송하는 RRC 재개 메시지를 암호화하는데 사용되는 것을 특징으로 하는 방법.
  5. 제1항에 있어서,
    상기 제2 UE XnAP ID는 상기 제2 NG-RAN 노드가 상기 UE가 상기 비-SDT 전송을 사용하고자 한다는 것을 인지하도록 하는 것을 특징으로 하는 방법.
  6. 제1항에 있어서,
    상기 응답 메시지는 RETRIEVE UE CONTEXT RESPONSE 메시지인 것을 특징으로 하는 방법.
  7. 제1항에 있어서,
    상기 응답 메시지는 RETRIEVE UE CONTEXT FAILURE 메시지인 것을 특징으로 하는 방법.
  8. 통신을 수행하는 제1 New Generation Radio Access Node (NG-RAN) 노드에 있어서,
    적어도 하나의 프로세서; 및
    명령어(instructions)를 저장하고, 상기 적어도 하나의 프로세서와 동작가능하게(operably) 전기적으로 연결가능한, 적어도 하나의 메모리를 포함하고,
    상기 명령어가 상기 적어도 하나의 프로세서에 의해 실행되는 것에 기초하여 수행되는 동작은:
    제1 UE XnAP ID 및 I-RNTI를 포함하는 RETRIEVE UE CONTEXT 요청 메시지를 제2 NG-RAN 노드로부터 수신하는 단계;
    상기 I-RNTI에 기초하여, User Equipment (UE)에 대한 검증을 수행하는 단계; 및
    RETRIEVE UE CONTEXT 요청 메시지에 대한 응답으로, 응답 메시지를 상기 제2 NG-RAN 노드에게 전송하는 단계를 포함하고,
    상기 응답 메시지는 상기 UE에 관련된 제2 UE XnAP ID를 포함하고,
    상기 UE에 관련된 상기 제2 UE XnAP ID는 상기 제1 NG-RAN 노드가 상기 제2 NG-RAN 노드로부터 이전에 수신했고, 및
    상기 제2 UE XnAP ID는 상기 제2 NG-RAN 노드가 Small Data Transmission (SDT) 전송을 위해 사용되었던 UE 컨텍스트를 비-SDT 전송을 위해 사용하도록 하는 것을 특징으로 하는 제1 NG-RAN 노드.
  9. 제1 New Generation Radio Access Node (NG-RAN) 노드가 통신을 수행하는 방법으로서,
    User Equipment (UE)로부터 I-RNTI를 포함하는 RRC 재개 요청 메시지를 수신하는 단계;
    제1 UE XnAP ID 및 I-RNTI를 포함하는 RETRIEVE UE CONTEXT 요청 메시지를 제2 NG-RAN 노드에게 전송하는 단계;
    RETRIEVE UE CONTEXT 요청 메시지에 대한 응답으로, 응답 메시지를 상기 제2 NG-RAN 노드로부터 수신하는 단계; 및
    상기 UE에게 RRC Resume 메시지를 전송하는 단계를 포함하고,
    상기 응답 메시지는 상기 UE에 관련된 제2 UE XnAP ID를 포함하고,
    상기 UE에 관련된 상기 제2 UE XnAP ID는 상기 제1 NG-RAN 노드가 상기 제2 NG-RAN 노드에게 이전에 전송했던 ID이고, 및
    상기 제2 UE XnAP ID가 수신된 것에 기초하여, 상기 제1 NG-RAN 노드가 Small Data Transmission (SDT) 전송을 위해 사용했던 UE 컨텍스트가 비-SDT 전송을 위해 사용되는 것을 특징으로 하는 방법.
  10. 제9항에 있어서,
    상기 제2 UE XnAP ID에 기초하여, 상기 SDT 전송을 위해 사용했던 UE 컨텍스트를 찾는 단계를 더 포함하는 방법.
  11. 제9항에 있어서,
    상기 SDT 전송을 위해 사용했던 UE 컨텍스트를 찾지 못한 경우, 상기 응답 메시지에 포함된 UE 컨텍스에 기초하여 SDT 베어러에 대한 UE 컨텍스트를 생성하는 단계를 더 포함하는 방법.
  12. 통신을 수행하는 제1 New Generation Radio Access Node (NG-RAN) 노드에 있어서,
    적어도 하나의 프로세서; 및
    명령어(instructions)를 저장하고, 상기 적어도 하나의 프로세서와 동작가능하게(operably) 전기적으로 연결가능한, 적어도 하나의 메모리를 포함하고,
    상기 명령어가 상기 적어도 하나의 프로세서에 의해 실행되는 것에 기초하여 수행되는 동작은:
    User Equipment (UE)로부터 I-RNTI를 포함하는 RRC 재개 요청 메시지를 수신하는 단계;
    제1 UE XnAP ID 및 I-RNTI를 포함하는 RETRIEVE UE CONTEXT 요청 메시지를 제2 NG-RAN 노드에게 전송하는 단계;
    RETRIEVE UE CONTEXT 요청 메시지에 대한 응답으로, 응답 메시지를 상기 제2 NG-RAN 노드로부터 수신하는 단계; 및
    상기 UE에게 RRC Resume 메시지를 전송하는 단계를 포함하고,
    상기 응답 메시지는 상기 UE에 관련된 제2 UE XnAP ID를 포함하고,
    상기 UE에 관련된 상기 제2 UE XnAP ID는 상기 제1 NG-RAN 노드가 상기 제2 NG-RAN 노드에게 이전에 전송했던 ID이고, 및
    상기 제2 UE XnAP ID가 수신된 것에 기초하여, 상기 제1 NG-RAN 노드가 Small Data Transmission (SDT) 전송을 위해 사용했던 UE 컨텍스트가 비-SDT 전송을 위해 사용되는 것을 특징으로 하는 제1 NG-RAN 노드.
PCT/KR2023/001621 2022-02-11 2023-02-03 Sdt와 관련된 통신 WO2023153731A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2022-0018417 2022-02-11
KR20220018417 2022-02-11

Publications (1)

Publication Number Publication Date
WO2023153731A1 true WO2023153731A1 (ko) 2023-08-17

Family

ID=87564688

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2023/001621 WO2023153731A1 (ko) 2022-02-11 2023-02-03 Sdt와 관련된 통신

Country Status (1)

Country Link
WO (1) WO2023153731A1 (ko)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20180055914A (ko) * 2015-11-04 2018-05-25 엘지전자 주식회사 무선 통신 시스템에서 서빙 노드 이전 방법 및 이를 위한 장치
US20190289661A1 (en) * 2018-03-16 2019-09-19 Asustek Computer Inc. Method and apparatus of handling multiple radio resource control (rrc) procedures in a wireless communication system
US20200351723A1 (en) * 2017-11-13 2020-11-05 Lg Electronics Inc. Method for managing ue context and device supporting the same

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20180055914A (ko) * 2015-11-04 2018-05-25 엘지전자 주식회사 무선 통신 시스템에서 서빙 노드 이전 방법 및 이를 위한 장치
US20200351723A1 (en) * 2017-11-13 2020-11-05 Lg Electronics Inc. Method for managing ue context and device supporting the same
US20190289661A1 (en) * 2018-03-16 2019-09-19 Asustek Computer Inc. Method and apparatus of handling multiple radio resource control (rrc) procedures in a wireless communication system

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"3 Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; Xn application protocol (XnAP) (Release 16)", 3GPP STANDARD; TECHNICAL SPECIFICATION; 3GPP TS 38.423, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG3, no. V16.8.0, 23 December 2021 (2021-12-23), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, pages 1 - 467, XP052083431 *
LATHEEF FASIL ABDUL; INGALE MANGESH ABHIMANYU: "On the UE Context Retrieval Enhancements for Improved Inter-RAT Mobility", 2020 IEEE 3RD 5G WORLD FORUM (5GWF), IEEE, 10 September 2020 (2020-09-10), pages 324 - 329, XP033840502, DOI: 10.1109/5GWF49715.2020.9221422 *

Similar Documents

Publication Publication Date Title
WO2021045339A1 (en) Method and apparatus for supporting up security for mo-edt in cu-du split in a wireless communication system
WO2021172964A1 (en) Method and apparatus for failure recovery in wireless communication system
WO2022050659A1 (ko) 트래픽 제어
WO2021187829A1 (ko) 네트워크 슬라이스와 관련된 통신
WO2021225317A1 (ko) 혼잡 제어에 관련된 통신
WO2020060007A1 (ko) 5g 이동통신에서 pdu 세션을 핸들링하는 방법 및 무선 기기
WO2021020933A1 (ko) Plmn을 변경하기 위한 방안
WO2022075562A1 (ko) 멀티캐스트와 관련된 통신
WO2021162500A1 (ko) 멀티 액세스 pdu 세션과 관련된 통신
WO2021187881A1 (en) Network support indication for ue provided pdu session pair information
WO2021162498A1 (ko) Npn에서의 pws서비스 방안
WO2021177716A2 (ko) 멀티캐스트와 관련된 통신
WO2021182807A1 (en) Method and apparatus for supporting a daps handover procedure in a wireless communication system
WO2021187936A1 (ko) 네트워크 슬라이스에 의한 통신 방법
WO2021177734A1 (en) Support of service continuity for handover between snpn and plmn
WO2021187783A1 (en) Support of service continuity between snpn and plmn
WO2021235779A1 (ko) 멀티캐스트와 관련된 통신
WO2021091153A1 (ko) 무선 통신 시스템에서 사이드링크 통신에 관련된 설정을 제어하기 위한 방법 및 장치
WO2021075841A1 (en) Method and apparatus for performing communication after mobility in wireless communication system
WO2021025246A1 (en) Method and apparatus for handling security information between a wireless device and a network for a fast rrc release procedure in a wireless communication system
WO2022035204A1 (ko) 네트워크 슬라이스와 관련된 통신
WO2022075612A1 (ko) 무선 통신 시스템에서 자원 할당을 위한 방법 및 장치
WO2021158090A1 (en) Method and apparatus for inactivity handling in mobility in wireless communication system
WO2021194306A1 (en) Method and apparatus for reconfiguration in wireless communication system
WO2022235034A1 (ko) Ue 컨텍스트와 관련된 통신

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23753081

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023753081

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2023753081

Country of ref document: EP

Effective date: 20240911