WO2020111836A1 - 무선 통신 시스템에서 동작하는 방법 및 장치 - Google Patents

무선 통신 시스템에서 동작하는 방법 및 장치 Download PDF

Info

Publication number
WO2020111836A1
WO2020111836A1 PCT/KR2019/016624 KR2019016624W WO2020111836A1 WO 2020111836 A1 WO2020111836 A1 WO 2020111836A1 KR 2019016624 W KR2019016624 W KR 2019016624W WO 2020111836 A1 WO2020111836 A1 WO 2020111836A1
Authority
WO
WIPO (PCT)
Prior art keywords
mode
iot
terminal
rrc connection
rrc
Prior art date
Application number
PCT/KR2019/016624
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 엘지전자 주식회사
Priority to US17/291,720 priority Critical patent/US11968741B2/en
Publication of WO2020111836A1 publication Critical patent/WO2020111836A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/30—Connection release
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0023—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the signalling
    • H04L1/0025—Transmission of mode-switching indication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/08—Testing, supervising or monitoring using real traffic
    • 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
    • H04W68/00—User notification, e.g. alerting and paging, for incoming communication, change of service or the like
    • H04W68/005—Transmission of information for alerting of incoming communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0075—Transmission of coding parameters to receiver

Definitions

  • the present invention relates to a method and apparatus used in a wireless communication system.
  • a wireless communication system is a multiple access system capable of supporting communication with multiple users by sharing available system resources (bandwidth, transmission power, etc.).
  • Examples of the multiple access system 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, and a Single Carrier Frequency (SC-FDMA). Division Multiple Access) system.
  • 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
  • Technical problem to be achieved by the present invention is to provide a method and apparatus for supporting a plurality of IoT modes.
  • the technical problem of the present invention is not limited to the above-described technical problem, and other technical problems can be inferred from the embodiments of the present invention.
  • the present invention provides a method and apparatus for operating in a wireless communication system.
  • a method performed by a communication device in a wireless communication system comprising: receiving an RRC (Radio Resource Control) connection release message; Releasing the RRC connection based on the RRC connection release message; Included, the RRC connection release message includes information on the target Internet of Things (IoT) mode, and based on the information on the target IoT mode, the communication device switches from the source IoT mode to the target IoT mode
  • RRC Radio Resource Control
  • a communication device operating in a wireless communication system comprising: at least one transceiver; At least one processor; And at least one memory operatively coupled to the at least one processor and storing instructions that, when executed, cause the at least one processor to perform a particular operation; And, the specific operation includes receiving a radio resource control (RRC) connection release message and releasing the RRC connection based on the RRC connection release message, wherein the RRC connection release message includes the target IoT ( Internet of Things) mode, and based on the information on the target IoT mode, the communication device is provided with a communication device that is switched from the source IoT mode to the target IoT mode.
  • RRC radio resource control
  • the communication device may be switched from the source IoT mode to the target IoT mode at the same time as the RRC connection release or within a predetermined range from the time when the RRC connection release message is received.
  • the target IoT mode is set based on information on one or more preferred target IoT modes, and the information on the one or more preferred target IoT modes is an RRC connection transmitted by the communication device It may be included in the release request message.
  • the target IoT mode may be determined in advance before receiving the RRC connection release message.
  • information about one or more parameters for the operation of the target IoT mode may be received through an RRC configuration message and/or through the RRC connection release message before the RRC connection is released.
  • the communication device may monitor a paging message based on the target IoT mode after the RRC connection is released.
  • the communication device may test whether the operation of the target IoT mode satisfies a specific criterion before the RRC connection is released.
  • the device may include at least a terminal, a network, and an autonomous vehicle that can communicate with an autonomous vehicle other than the communication device.
  • 1 and 2 illustrate the structure of a radio frame.
  • 3 illustrates a resource grid of slots.
  • CDMA may be implemented with a radio technology such as UTRA (Universal Terrestrial Radio Access) or CDMA2000.
  • TDMA may be implemented with wireless technologies such as Global System for Mobile communications (GSM)/General Packet Radio Service (GPRS)/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 with wireless technologies such as IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802-20, and Evolved UTRA (E-UTRA).
  • UTRA is part of the Universal Mobile Telecommunications System (UMTS).
  • 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) is part of Evolved UMTS (E-UMTS) using E-UTRA
  • LTE-A (Advanced)/LTE-A pro is an evolved version of 3GPP LTE
  • 3GPP NR New Radio or New Radio Access Technology
  • 3GPP LTE/LTE-A/LTE-A pro is an evolved version of 3GPP LTE/LTE-A/LTE-A pro.
  • LTE means 3GPP TS 36.xxx Release 8 or later technology. Specifically, LTE technology after 3GPP TS 36.xxx Release 10 is called LTE-A, and LTE technology after 3GPP TS 36.xxx Release 13 is called LTE-A pro.
  • 3GPP NR refers to the technology after TS 38.xxx Release 15.
  • LTE/NR may be referred to as a 3GPP system.
  • "xxx" means standard document detail number.
  • LTE/NR may be referred to as a 3GPP system. Background art, terms, abbreviations, and the like used in the description of the present invention may refer to matters described in a standard document published prior to the present invention. For example, you can refer to the following documents.
  • RRC Radio Resource Control
  • RRC Radio Resource Control
  • 1 shows a structure of a radio frame used in LTE.
  • Figure 1 (a) shows a type 1 frame structure (frame structure type 1).
  • the type 1 frame structure can be applied to both a full duplex (Frequency Division Duplex) system and a half duplex (FDD) system.
  • FDD Frequency Division Duplex
  • One subframe is defined as two consecutive slots, and the i-th subframe is composed of slots corresponding to 2i and 2i+1. That is, a radio frame is composed of 10 subframes.
  • the time taken to transmit one subframe is called a transmission time interval (TTI).
  • the slot includes a plurality of OFDM symbols or SC-FDMA symbols in the time domain, and a plurality of resource blocks (Resource Block) in the frequency domain.
  • One slot includes a plurality of orthogonal frequency division multiplexing (OFDM) symbols in the time domain. Since 3GPP LTE uses OFDMA in the downlink, the OFDM symbol is for expressing one symbol period. The OFDM symbol may be referred to as one SC-FDMA symbol or symbol period.
  • a resource block is a resource allocation unit and includes a plurality of consecutive subcarriers in one slot.
  • the structure of the above-described radio frame is only an example, and the number of sub-frames included in the radio frame, the number of slots included in the sub-frame, and the number of OFDM symbols included in the slot may be variously changed.
  • Figure 1 (b) shows a type 2 frame structure (frame structure type 2).
  • the type 2 frame structure is applied to the TDD system.
  • the type 2 frame includes a special subframe composed of three fields: a downlink pilot time slot (DwPTS), a guard period (GP), and an uplink pilot time slot (UpPTS).
  • DwPTS is used for initial cell search, synchronization, or channel estimation in the UE.
  • UpPTS is used to match channel estimation at a base station and uplink transmission synchronization of a terminal.
  • the guard period is a period for removing interference caused in the uplink due to the multipath delay of the downlink signal between the uplink and the downlink.
  • Table 1 below shows the composition of the special frame (length of DwPTS/GP/UpPTS).
  • FIG. 2 illustrates the structure of a radio frame used in NR.
  • uplink (UL) and downlink (DL) transmission is composed of frames.
  • a radio frame has a length of 10 ms and is defined as two 5 ms half-frames (HFs).
  • the half-frame is defined by five 1ms subframes (Subframe, SF).
  • the subframe is divided into one or more slots, and the number of slots in the subframe depends on subcarrier spacing (SCS).
  • SCS subcarrier spacing
  • Each slot includes 12 or 14 OFDM(A) symbols according to a cyclic prefix (CP).
  • CP cyclic prefix
  • each slot includes 14 symbols.
  • the symbol may include an OFDM symbol (or CP-OFDM symbol) and an SC-FDMA symbol (or DFT-s-OFDM symbol).
  • Table 2 illustrates that when CP is normally used, the number of symbols for each slot, the number of slots for each frame, and the number of slots for each subframe vary according to SCS.
  • Table 3 illustrates that when an extended CP is used, the number of symbols for each slot, the number of slots for each frame, and the number of slots for each subframe vary according to the SCS.
  • OFDM(A) numerology eg, SCS, CP length, etc.
  • a (absolute time) section of a time resource eg, SF, slot, or TTI
  • a time unit TU
  • 3 illustrates the slot structure of the NR frame.
  • a slot contains multiple symbols in the time domain. For example, in the case of a normal CP, one slot includes 14 symbols, but in the case of an extended CP, one slot includes 12 symbols.
  • the carrier includes a plurality of subcarriers in the frequency domain.
  • Resource block (RB) is defined as a plurality of (eg, 12) consecutive subcarriers in the frequency domain.
  • BWP Bandwidth Part
  • P contiguous
  • the carrier may include up to N (eg, 5) BWPs. Data communication is performed through the activated BWP, and only one BWP can be activated for one terminal.
  • Each element in the resource grid is referred to as a resource element (RE), and one complex symbol may be mapped.
  • RE resource element
  • a frame is characterized by a self-contained structure in which a DL control channel, DL or UL data, UL control channel, etc. can all be included in one slot.
  • a DL control channel hereinafter, DL control region
  • the last M symbols in a slot can be used to transmit an UL control channel (hereinafter, UL control region).
  • N and M are each an integer of 0 or more.
  • the resource region (hereinafter, the data region) between the DL control region and the UL control region may be used for DL data transmission or may be used for UL data transmission.
  • the following configuration may be considered. Each section was listed in chronological order.
  • a PDCCH Physical Downlink Control Channel
  • a PDSCH Physical Downlink Shared Channel
  • a PUCCH Physical Uplink Control Channel
  • a PUSCH Physical Uplink Shared Channel
  • DCI downlink control information
  • uplink control information for example, ACK/NACK (Positive Acknowledgement/Negative Acknowledgement) information for DL data, CSI (Channel State Information) information, and SR (Scheduling Request) may be transmitted.
  • the GP provides a time gap in a process in which a base station (BS) and a terminal switch from a transmission mode to a reception mode or a process from a reception mode to a transmission mode. In a subframe, some symbols at a time point of switching from DL to UL may be set as GP.
  • MTC Machine Type Communication
  • M2M Machine-to-Machine
  • IoT Internet-of-Things
  • 3GPP 3rd Generation Partnership Project
  • the MTC may be implemented to satisfy the criteria of (i) low cost & low complexity, (ii) enhanced coverage, and (iii) low power consumption.
  • the MTC described in 3GPP release 10 and release 11 relates to a load control method.
  • the load control method is to prevent IoT (or M2M) devices from suddenly loading the base station.
  • the base station in the case of release 10, relates to a method of controlling the load by disconnecting the connection to connected IoT devices when a load occurs, and in the case of release 11, the base station broadcasts such as SIB14. It relates to a method of blocking a connection to a terminal in advance by notifying the terminal in advance to access later.
  • the UE category is an index indicating how much data the terminal can handle in the communication modem.
  • the UE category 0 UE reduces the baseband and RF complexity of the UE by using a Half Duplex operation with a reduced peak data rate, a relaxed RF requirement, and a single receive antenna.
  • eMTC enhanced MTC
  • MTC Mobility Management Entity
  • the MTC to be described later is eMTC (enhanced MTC), LTE-M1/M2, BL (Bandwidth reduced low complexity) / CE (coverage enhanced), non-BL UE (in enhanced coverage), NR MTC, enhanced BL / CE, etc.
  • MTC enhanced MTC
  • LTE-M1/M2 Long Term Evolution
  • CE coverage enhanced
  • non-BL UE in enhanced coverage
  • NR MTC enhanced BL / CE
  • MTC operates only in a specific system bandwidth (or channel bandwidth).
  • the specific system bandwidth may use 6RB of legacy LTE as shown in Table 4 below, and may be defined in consideration of frequency range and subcarrier spacing (SCS) of NR defined in Tables 5 to 7.
  • the specific system bandwidth may be expressed as a narrowband (NB).
  • Legacy LTE means a part described in 3GPP standard other than MTC.
  • MTC may operate using RBs corresponding to the lowest system bandwidths in Tables 6 and 7 below as in legacy LTE.
  • the MTC in the NR may operate in at least one bandwidth part (BWP) or may operate in a specific band of the BWP.
  • BWP bandwidth part
  • Table 5 is a table showing a frequency range (FR) defined in NR.
  • Table 6 is a table showing an example of maximum bandwidth configuration (NRB) for channel bandwidth and SCS in FR 1 of NR.
  • Table 7 is a table showing an example of the maximum transmission bandwidth configuration (NRB) for channel bandwidth and SCS in FR 2 of NR.
  • NRB maximum transmission bandwidth configuration
  • MTC operates in half duplex mode and uses limited (or reduced) maximum transmission power.
  • MTC does not use a channel (defined in legacy LTE or NR) that must be distributed over the entire system bandwidth of legacy LTE or NR.
  • legacy LTE channels not used for MTC are PCFICH, PHICH, and PDCCH.
  • MTC PDCCH MPDCCH
  • MPDCCH spans up to 6 RBs in the frequency domain and one subframe in the time domain.
  • MPDCCH is similar to EPDCCH, and additionally supports a common search space for paging and random access.
  • the MPDCCH is similar to the concept of E-PDCCH used in legacy LTE.
  • MTC uses a newly defined DCI format, and may be, for example, DCI formats 6-0A, 6-0B, 6-1A, 6-1B, 6-2, and the like.
  • MTC is PBCH (physical broadcast channel), PRACH (physical random access channel), M-PDCCH (MTC physical downlink control channel), PDSCH (physical downlink shared channel), PUCCH (physical uplink control channel), PUSCH (physical uplink shared channel).
  • the MTC repetitive transmission can decode the MTC channel even when the signal quality or power is very poor, such as in a poor environment such as a basement, which can increase cell radius and effect signal penetration.
  • the MTC may support only a limited number of transmission modes (TM) capable of operating in a single layer (or single antenna) or a channel or reference signal (RS) capable of operating in a single layer. .
  • TM transmission modes
  • RS channel or reference signal
  • the transmission mode in which the MTC can operate may be TM 1, 2, 6 or 9.
  • HARQ retransmission of MTC is adaptive and asynchronous, and is based on a new scheduling assignment received in MPDCCH.
  • PDSCH scheduling (DCI) and PDSCH transmission in MTC occur in different subframes (cross subframe scheduling).
  • All resource allocation information for SIB1 decoding (subframe, transport block size (TBS), subband index) is determined by parameters of MIB, and no control channel is used for STC1 decoding of MTC.
  • All resource allocation information (subframe, TBS, subband index) for SIB2 decoding is determined by several SIB1 parameters, and no control channel for SIB2 decoding of MTC is used.
  • MTC supports extended paging (DRX) cycle.
  • MTC can use the same as the primary synchronization signal (PSS) / secondary synchronization signal (SSS) / common reference signal (CRS) used in legacy LTE or NR.
  • PSS primary synchronization signal
  • SSS secondary synchronization signal
  • CRS common reference signal
  • PSS / SSS is transmitted in SS block (or SS / PBCH block or SSB) units, and TRS (tracking RS) may be used for the same purpose as CRS. That is, TRS is a cell-specific RS, and can be used for frequency / time tracking.
  • MTC is divided into two operation modes (first mode and second mode) and four different levels to improve coverage, and may be as shown in Table 8 below.
  • the MTC operation mode is referred to as CE Mode, in which case the first mode may be referred to as CE Mode A and the second mode as CE Mode B.
  • the first mode is defined for small mobility enhancement with full mobility and CSI (channel state information) feedback, so that there is no repetition or fewer repetitions.
  • the operation of the first mode may be the same as the operation range of UE category 1.
  • the second mode is defined for UEs with extremely poor coverage conditions that support CSI feedback and limited mobility, and a large number of repetitive transmissions are defined.
  • the second mode provides coverage enhancement of up to 15 dB based on the range of UE category 1.
  • Each level of MTC is defined differently in RACH and paging procedure.
  • the MTC operation mode is determined by the base station, and each level is determined by the MTC terminal. Specifically, the base station transmits RRC signaling including information on the MTC operation mode to the terminal.
  • the RRC signaling may be an RRC connection setup message, an RRC connection reconfiguration message, or an RRC connection reestablishment message.
  • the term of the message may be expressed as an information element (IE).
  • the MTC terminal determines the level in each operation mode, and transmits the determined level to the base station. Specifically, the MTC terminal determines the level in the operation mode based on the measured channel quality (eg, RSRP, RSRQ, or SINR), and determines the base station using PRACH resources (frequency, time, preamble) corresponding to the determined level. Inform the level.
  • the measured channel quality eg, RSRP, RSRQ, or SINR
  • PRACH resources frequency, time, preamble
  • the MTC terminal performs an idle state (eg, RRC_IDLE state) and/or an inactive state (eg, RRC_INACTIVE state) to reduce power consumption. ) State.
  • the MTC terminal switched to the valid state and/or the deactivated state may be configured to use the DRX method.
  • the MTC terminal switched to the idle state and/or the inactive state is configured to perform monitoring of MPDCCH related to paging only in a specific subframe (or frame, slot) according to a DRX cycle set by a base station or the like. Can be set.
  • the MPDCCH associated with paging may mean an MPDCCH scrambled with Paging Access-RNTI (P-RNTI).
  • NB-IoT Nearband-Internet of Things
  • NB-IoT provides low complexity and low power consumption through system bandwidth (system BW) corresponding to 1 PRB (Physical Resource Block) of a wireless communication system (eg, LTE system, NR system, etc.). It can mean a system to support.
  • system BW system bandwidth
  • PRB Physical Resource Block
  • NB-IoT may be referred to by other terms such as NB-LTE, NB-IoT enhancement, enhanced NB-IoT, further enhanced NB-IoT, NB-NR, and the like. That is, NB-IoT may be defined or replaced by a term to be defined in the 3GPP standard. Hereinafter, for convenience of description, it will be collectively expressed as'NB-IoT'.
  • NB-IoT mainly supports a device (or terminal) such as machine-type communication (MTC) in a cellular system, and may be used as a communication method for implementing IoT (ie, Internet of Things).
  • the NB-IoT system uses NB by using OFDM parameters such as subcarrier spacing (SCS) used in an existing wireless communication system (eg, 3GPP system, LTE system, and NR system) as the existing system.
  • SCS subcarrier spacing
  • an existing wireless communication system eg, 3GPP system, LTE system, and NR system
  • the frame structure, physical channel, multi-carrier operation, operation mode, and general signal transmission/reception related to the NB-IoT in the present specification are described in consideration of the case of the existing LTE system, Needless to say, the next generation system (for example, NR system, etc.) can be extended and applied.
  • the contents related to NB-IoT in the present specification may be extended to MTC (Machine Type Communication) that aims for similar technical purposes (eg, low-power, low-cost, improved coverage, etc.).
  • the base station and/or terminal supporting NB-IoT may be configured to transmit and receive physical channels and/or physical signals separately set from the existing system.
  • specific content related to physical channels and/or physical signals supported by the NB-IoT will be described.
  • Orthogonal frequency division multiple access (OFDMA) scheme may be applied to the NB-IoT downlink based on a subcarrier interval of 15 kHz. Through this, orthogonality between subcarriers is provided to effectively support co-existence with an existing system (eg, LTE system, NR system).
  • OFDMA orthogonal frequency division multiple access
  • the physical channel of the NB-IoT system may be expressed in a form in which'N (Narrowband)' is added to distinguish it from the existing system.
  • the downlink physical channel is defined as a narrowband physical broadcast channel (NPBCH), a narrowband physical downlink control channel (NPDCCH)/narrowband enhanced physical downlink control channel (NEPDCCH), a narrowband physical downlink shared channel (NPDSCH), and the like.
  • the link physical signal may be defined as a Narrowband Primary Synchronization Signal (NPSS), a Narrowband Secondary Synchronization Signal (NSSS), a Narrowband Reference Signal (NSR), a Narrowband Positioning Reference Signal (NPRS), or a Narrowband Wake Up Signal (NWUS).
  • NPSS Narrowband Primary Synchronization Signal
  • NSSS Narrowband Secondary Synchronization Signal
  • NSR Narrowband Reference Signal
  • NPRS Narrowband Positioning Reference Signal
  • NWUS Narrowband Wake Up Signal
  • the downlink physical channel and physical signal of the NB-IoT described above may be configured to be transmitted based on a time domain multiplexing scheme and/or a frequency domain multiplexing scheme.
  • repetition transmission may be performed for coverage enhancement.
  • NB-IoT uses a newly defined DCI format (DCI format), and for example, DCI format for NB-IoT may be defined as DCI format N0, DCI format N1, DCI format N2, and the like.
  • SC-FDMA Single Carrier Frequency Divison Multiple Access
  • SC-FDMA Single Carrier Frequency Divison Multiple Access
  • the physical channel of the NB-IoT system may be expressed in a form in which'N (Narrowband)' is added to distinguish it from the existing system.
  • the uplink physical channel may be defined as a narrowband physical random access channel (NPRACH) and a narrowband physical uplink shared channel (NPUSCH), and the uplink physical signal may be defined as a narrowband demodulation reference signal (NDMRS).
  • NPRACH narrowband physical random access channel
  • NPUSCH narrowband physical uplink shared channel
  • NMRS narrowband demodulation reference signal
  • the NPUSCH may consist of NPUSCH format 1, NPUSCH format 2, and so on.
  • NPUSCH format 1 is used for UL-SCH transmission (or transport)
  • NPUSCH format 2 can be used for transmission of uplink control information such as HARQ ACK signaling.
  • repetition transmission may be performed for coverage enhancement.
  • repetitive transmission may be performed by applying frequency hopping.
  • the operation mode of the NB-IoT will be described.
  • Three operation modes may be supported in the NB-IoT system.
  • 5 shows an example of operation modes supported in the NB-IoT system.
  • the operation mode of the NB-IoT is described based on the LTE band in this specification, it is only for convenience of description and can be extendedly applied to a band of another system (for example, an NR system band).
  • Figure 5 (a) shows an example of an in-band (In-band) system
  • Figure 5 (b) shows an example of a guard-band (Guard-band) system
  • Figure 5 (c) is a stand-alone (Stand-alone)
  • the in-band system is in-band mode (In-band mode)
  • the guard-band system is a guard-band mode (Guard-band mode)
  • stand-alone The system (stand-alone system) may be expressed in a stand-alone mode.
  • the in-band system may refer to a system or mode in which a specific 1 RB (ie PRB) in the (legacy) LTE band is used for NB-IoT.
  • the in-band system may be operated by allocating some resource blocks of the LTE system carrier.
  • the guard-band system may refer to a system or mode using NB-IoT in a space reserved for a guard band of a (legacy) LTE band.
  • the guard-band system may be operated by assigning a guard-band of an LTE carrier that is not used as a resource block in the LTE system.
  • the (legacy) LTE band may be set to have a Guard-band of at least 100 kHz at the end of each LTE band. To use 200 kHz, two non-contiguous Guard-bands can be used.
  • the in-band system and the guard-band system can be operated in a structure in which NB-IoT coexists in a (legacy) LTE band.
  • a standalone system may refer to a system or mode configured independently from the (legacy) LTE band.
  • the standalone system may be operated by separately allocating a frequency band used in the GERAN (GSM EDGE Radio Access Network) (eg, a future reassigned GSM carrier).
  • GSM EDGE Radio Access Network eg, a future reassigned GSM carrier.
  • the three operation modes described above may be independently operated, or two or more operation modes may be combined to operate.
  • the NB-IoT terminal performs an idle state (eg, RRC_IDLE state) and/or an inactive state (to reduce power consumption) ( Example: RRC_INACTIVE state).
  • the NB-IoT terminal switched to the valid state and/or the deactivated state may be configured to use the DRX method.
  • the NB-IoT terminal switched to the idle state and/or the inactive state monitors NPDCCH related to paging only in a specific subframe (or frame, slot) according to a DRX cycle set by a base station or the like. Can be set to perform.
  • the NPDCCH associated with paging may mean an NPDCCH scrambled with Paging Access-RNTI (P-RNTI).
  • the random access process is also referred to as a random access channel (RACH) process.
  • the random access process is variously used for initial access, uplink synchronization adjustment, resource allocation, handover, radio link reconfiguration after radio link failure, and location measurement.
  • the random access process is classified into a contention-based process and a dedicated (ie, non-competition-based) process.
  • the contention-based random access process is generally used, including initial access, and the dedicated random access process is limitedly used for handover, when downlink data arrives, and when resetting uplink synchronization in case of location measurement. .
  • the UE randomly selects the RACH preamble sequence.
  • the UE uses the RACH preamble sequence uniquely allocated by the base station to the UE. Therefore, a random access process can be performed without collision with other terminals.
  • FIG. 6 shows a random access process.
  • Fig. 6(a) shows a competition-based random access process
  • Fig. 6(b) illustrates a dedicated random access process.
  • the contention-based random access process includes the following four steps.
  • the messages transmitted in steps 1 to 4 may be referred to as messages (Msg) 1 to 4, respectively.
  • Step 1 The UE transmits the RACH preamble through the PRACH.
  • the terminal receives a random access response (Random Access Response, RAR) through the DL-SCH from the base station.
  • RAR Random Access Response
  • Step 3 The UE transmits a Layer 2 / Layer 3 message to the base station through UL-SCH.
  • Step 4 The terminal receives a contention resolution message from the base station through the DL-SCH.
  • the terminal may receive information on random access from the base station through system information.
  • the UE transmits the RACH preamble to the base station as in step 1.
  • the base station may distinguish each of the random access preambles through a time/frequency resource (RACH Occasion; RO) and a random access preamble index (PI) in which the random access preamble is transmitted.
  • RACH Occasion time/frequency resource
  • PI random access preamble index
  • the base station When the base station receives the random access preamble from the terminal, the base station transmits a random access response (RAR) message to the terminal as in step 2.
  • RAR random access response
  • the UE CRC In order to receive the random access response message, the UE CRCs a random access-RNTI (RA-RNTI), including scheduling information for the random access response message, within a preset time window (eg, ra-ResponseWindow).
  • RA-RNTI random access-RNTI
  • the masked L1/L2 control channel (PDCCH) is monitored.
  • the PDCCH masked with RA-RNTI can be transmitted only through a common search space.
  • the terminal may receive a random access response message from the PDSCH indicated by the scheduling information.
  • the terminal checks whether there is random access response information directed to the random access response message. Whether the random access response information indicated to the user exists may be confirmed by whether a random access preamble ID (RAPID) for the preamble transmitted by the terminal exists.
  • RAPID random access preamble ID
  • the index and RAPID of the preamble transmitted by the terminal may be the same.
  • the random access response information includes a corresponding random access preamble index, timing offset information for UL synchronization (eg, Timing Advance Command, TAC), UL scheduling information for message 3 transmission (eg, UL grant) and terminal temporary identification information ( Yes, Temporary-C-RNTI, TC-RNTI).
  • the UE receiving the random access response information transmits UL-SCH (Shared Channel) data (message 3) through PUSCH according to the UL scheduling information and the timing offset value, as in step 3.
  • the ID of the terminal may be included.
  • the message 3 may include information related to an RRC connection request for initial access (for example, an RRCSetupRequest message).
  • the message 3 may include a buffer status report (BSR) for the amount of data available for transmission by the terminal.
  • BSR buffer status report
  • the base station After receiving the UL-SCH data, as in step 4, the base station transmits a contention resolution message (message 4) to the terminal.
  • a contention resolution message (message 4)
  • TC-RNTI is changed to C-RNTI.
  • the message 4 may include ID and/or RRC connection-related information (eg, RRCSetup message) of the terminal. If the information transmitted through the message 3 and the information received through the message 4 do not match, or if the message 4 is not received for a certain period of time, the terminal may retransmit the message 3 as deemed that contention resolution has failed.
  • the dedicated random access process includes the following three steps.
  • the messages transmitted in steps 0 to 2 may be referred to as messages (Msg) 0 to 2, respectively.
  • the dedicated random access process may be triggered using a PDCCH (hereinafter, a PDCCH order) for the purpose of instructing a base station to transmit RACH preamble.
  • Step 0 The base station allocates the RACH preamble through dedicated signaling to the terminal.
  • Step 1 The UE transmits the RACH preamble through the PRACH.
  • the terminal receives a random access response (Random Access Response, RAR) through the DL-SCH from the base station.
  • RAR Random Access Response
  • steps 1 to 2 of the dedicated random access process may be the same as steps 1 to 2 of the contention-based random access process.
  • DCI format 1_0 is used to initiate a non-competition based random access process with a PDCCH order.
  • DCI format 1_0 is used to schedule the PDSCH in one DL cell.
  • the CRC Cyclic Redundancy Check
  • the bit values of the “Frequency domain resource assignment” field are all 1
  • DCI format 1_0 is used as a PDCCH command indicating a random access process. do.
  • the field of DCI format 1_0 is set as follows.
  • -UL/SUL (Supplementary UL) indicator 1 bit. If all the bit values of the RA preamble index are not 0 and SUL is set in the cell for the UE, the UL carrier is transmitted in the PRACH in the cell. Otherwise, it is reserved.
  • -SSB Synchronization Signal/Physical Broadcast Channel index: 6 bits. If the bit values of the RA preamble index are not all 0, it indicates the SSB used to determine the RACH opportunity for PRACH transmission. Otherwise, it is reserved.
  • -PRACH mask index 4 bits. If the bit values of the RA preamble index are not all 0, it indicates the RACH opportunity associated with the SSB indicated by the SSB index. Otherwise, it is reserved.
  • DCI format 1_0 When DCI format 1_0 does not correspond to the PDCCH command, DCI format 1_0 is composed of fields used for scheduling PDSCH (eg, Time domain resource assignment, Modulation and Coding Scheme (MCS), HARQ process number, PDSCH-to- HARQ_feedback timing indicator, etc.).
  • fields used for scheduling PDSCH eg, Time domain resource assignment, Modulation and Coding Scheme (MCS), HARQ process number, PDSCH-to- HARQ_feedback timing indicator, etc.
  • the MTC terminal may perform a random access procedure.
  • the basic configuration related to the RACH procedure is transmitted by SIB2.
  • SIB2 includes parameters related to paging.
  • Paging Occasion (PO) is a subframe in which P-RNTI can be transmitted on MPCCH.
  • PO refers to a start subframe of MPDCCH repetition.
  • the paging frame (PF) is one radio frame, and may include one or multiple POs.
  • DRX is used, the MTC terminal monitors only one PO per DRX cycle.
  • Paging NarrowBand (PNB) is a narrowband, and the MTC terminal performs paging message reception.
  • the MTC terminal may transmit a preamble through a physical random access channel (PRACH) and receive a response message (RAR) for the preamble through MPDCCH and a corresponding PDSCH.
  • PRACH physical random access channel
  • RAR response message
  • the MTC terminal may perform a contention resolution procedure such as transmission of an additional PRACH signal and reception of an MPDCCH signal and a corresponding PDSCH signal.
  • signals and/or messages (Msg 1, Msg 2, Msg 3, Msg 4) transmitted in the RACH procedure may be repeatedly transmitted, and this repetition pattern is set differently according to CE level.
  • Msg 1 means PRACH preamble
  • Msg 2 means random access response (RAR)
  • Msg 3 means UL transmission of MTC terminal for RAR
  • Msg 4 means DL transmission of base station for Msg 3 can do.
  • PRACH resource For random access, signaling for different PRACH resources and different CE levels is supported. This provides the same control of the near-far effect on the PRACH by grouping UEs experiencing similar path loss together. Up to four different PRACH resources may be signaled to the MTC terminal.
  • the NB-IoT terminal may perform a random access procedure to complete access to the base station.
  • the NB-IoT terminal may transmit a preamble to the base station through NPRACH, and as described above, the NPRACH may be set to be repeatedly transmitted based on frequency hopping or the like to improve coverage.
  • the base station can (preferably) receive the preamble through the NPRACH from the NB-IoT terminal.
  • the NB-IoT terminal may receive a random access response (RAR) for the preamble from the base station through the NPDCCH and the corresponding NPDSCH.
  • the base station may transmit a random access response (RAR) for the preamble to the NB-IoT terminal through the NPDCCH and the corresponding NPDSCH.
  • the NB-IoT terminal may transmit the NPUSCH to the base station using scheduling information in the RAR, and perform a contention resolution procedure such as NPDCCH and the corresponding NPDSCH.
  • the base station may receive the NPUSCH from the terminal using the scheduling information in the NB-IoT RAR, and perform the collision resolution procedure.
  • a terminal in the RRC_IDLE state can transmit and receive data with a base station in camp-on while maintaining an idle state without establishing an RRC connection with the base station.
  • This method is called early data transmission (EDT).
  • EDT early data transmission
  • the UE transmits a random access preamble through a random access preamble resource separately allocated for EDT in order to transmit data to a camp-on base station.
  • the base station that has received the random access preamble for EDT informs the UE that has transmitted the preamble through Msg2 transmission whether the EDT data transmission procedure is allowed, and when the base station permits the EDT data transmission, the corresponding terminal can transmit its global (Msg3) through Msg3.
  • the base station may transmit the data to the terminal through the Msg4, whether the data has been successfully received, or the user data to be transmitted to the terminal, and data transmission and reception between the base station and the terminal may be continued even after Msg4 depending on the control of the base station.
  • the UE does not establish an RRC connection with the base station and ends the EDT procedure.
  • -IoT mode means a communication method or communication operation mode supporting a specific combination of wireless environment/characteristics and/or terminal characteristics.
  • the IoT mode may be a communication method or a communication operation mode supporting a combination of different levels, such as a compensation level for coupling loss, UE complexity (eg, operating bandwidth of the UE), and battery consumption level.
  • a compensation level for coupling loss e.g, UE complexity
  • UE complexity eg, operating bandwidth of the UE
  • battery consumption level e.g, battery consumption level.
  • general non-BL operation, non-BL CE mode operation (CEmodeA/B), eMTC operation, NB-IoT operation, etc. in 3GPP LTE and/or NR systems may be defined as different IoT modes.
  • the terminal when the terminal operates in a specific IoT mode, in a process in which the terminal communicates with the base station (eg, paging, RACH, data transmission/reception, etc.), i) a bandwidth supported by the corresponding IoT mode is used ii) corresponding (N/M)PDCCH/PDSCH/PUSCH/PUCCH/PRACH structure specialized for IoT mode is used and/or iii) Physical channels corresponding to the number of repetitions (CE level) of the channel specialized for the corresponding IoT mode are transmitted/received It means being.
  • the base station eg, paging, RACH, data transmission/reception, etc.
  • IoT mode a communication method or communication operation mode supporting a specific combination of wireless environment/characteristics and/or terminal characteristics
  • IoT mode is IoT (low power) in a broad sense.
  • Low complexity, etc. that is, a communication method or communication operation mode that operates as a terminal of a general category (Cat) may also be included.
  • Cat general category
  • an IoT mode used in a broad sense in the present specification may be interpreted to refer to a non-IoT IoT mode on a 3GPP communication system and a plurality of modes included in the IoT mode.
  • the IoT mode on the 3GPP communication system may be referred to as the IoT mode in a narrow sense.
  • the IoT mode may be understood as a set of a terminal category (UE category) and a narrow meaning IoT mode (or a plurality of modes included in the IoT mode).
  • the IoT mode may be mixed with the terminal category, the IoT mode in a broad sense, and the IoT mode (or a plurality of modes in the IoT mode) in a narrow sense.
  • -non-BL mode a mode for a terminal of a general category (e.g. Category 0 or category 1 or higher, 20 MHz bandwidth support) to operate in the LTE system
  • a general category e.g. Category 0 or category 1 or higher, 20 MHz bandwidth support
  • a terminal having no bandwidth limitation receives MPDCCH as in CE mode A/B of eMTC and compensates for a large repetition and/or Mode that operates to support CE
  • -eMTC mode A mode that conforms to the eMTC standard of the LTE system
  • -NB-IoT mode A mode that conforms to the NB-IoT standard of LTE systems
  • IoT mode in which a specific bandwidth, channel and/or number of channel repetitions (CE level) is used may be defined.
  • IoT modes other than the explicitly defined IoT modes and the explicitly defined IoT modes may be referred to through numbering, such as a first mode and a second mode.
  • IoT modes other than the explicitly defined IoT modes and the explicitly defined IoT modes may be referred to as a first IoT mode, a second IoT mode, and the like.
  • the mode described as following the relevant standard of the LTE system may be replaced with modes in which the bandwidth, channel and/or repetition number (CE level) are equally supported in the NR system.
  • the mode described herein as conforming to the relevant standard of the LTE system may be understood as being replaced by a mode conforming to different NR terminal capability (UE capability) standards or NR-light standards in the NR system.
  • UE capability NR terminal capability
  • a typical example of a cellular wireless communication method is a 3GPP LTE system, and in the LTE system, in addition to a basic communication method (a method that supports communication in a maximum 20 MHz bandwidth through an existing UE category of Cat0 or Cat1 or higher), low complexity, low power, EMTC for compensation of large coupling loss, more low-complexity, low power, NB-IoT for compensation for large coupling loss, and UE of the existing category (category) to compensate for large coupling loss CEmodeA of eMTC/ It supports B mode, etc.
  • a basic communication method a method that supports communication in a maximum 20 MHz bandwidth through an existing UE category of Cat0 or Cat1 or higher
  • EMTC for compensation of large coupling loss
  • NB-IoT for compensation for large coupling loss
  • UE of the existing category category (category)
  • each operation method is referred to as a non-BL mode, an eMTC mode, an NB-IoT mode, or a non-BL CE mode.
  • the IoT mode is described based on the LTE system, but in other systems other than 3GPP NR or 3GPP, different levels of power consumption (egwake-up/sleeping cycle) and different levels of UE complexity (eg , Supported bandwidth), when one terminal supports an operation method supporting different levels of combined loss compensation (eg, the number of transmission repetitions), each operation method may be considered as an IoT mode.
  • Different data transfer rates, combined loss, and power consumption may be suitable for one device depending on the situation or service, so one device supports multiple IoT modes and switches different IoT modes and switches to the switched IoT mode. It may be efficient to perform the based operation. For example, if the parking lot is in a parking standby state, the terminal can perform only minimal communication with the base station in an NB-IoT mode capable of compensating for low power consumption and large coupling loss. When a driver is in a vehicle, it may be efficient for the terminal to perform large-capacity data communication to facilitate user data service in a non-BL mode.
  • the terminal may be located in the vehicle or the vehicle itself.
  • Hardware supporting both modes may be implemented through one integrated chip or two chips mounted on one device.
  • the hardware supporting the two modes may include physically separated devices, and the devices may be connected to different locations in the vehicle, and a communication line for switching IoT modes between devices may be connected.
  • a terminal supporting a plurality of different IoT modes in order to change the operation from one IoT mode to another, disconnects the cell and newly connects or performs a procedure corresponding to handover between cells.
  • the IoT mode or eMTC mode operation for compensating for a large coupling loss considering that the delay required for the initial connection to the base station of the terminal may take hundreds of msec to tens of seconds or more, multiple IoT modes according to various service changes It may be very important to reduce the delay required to switch the IoT mode of a terminal supporting.
  • the base station knows a single identifier (ID) for one terminal supporting a plurality of IoT modes. Or, it may be assumed that the base station knows that the IDs belong to the same terminal even though different IDs are registered for each IoT mode for one terminal supporting a plurality of IoT modes. Alternatively, the terminal may switch a plurality of IoT modes using only one ID.
  • the ID may be, for example, a global ID of a terminal such as TMSI/IMSI (Temporary Mobile Subscriber Identity/International Mobile Subscriber Identity).
  • the ID may be an ID uniquely given in a specific network area to a device (eg, a terminal) supporting a plurality of IoT modes.
  • a device eg, a terminal
  • a base station that does not know that a specific terminal uses a plurality of global IDs may need to transmit paging messages as many as the number of IoT modes.
  • the signaling overhead can be reduced by allowing the base station to transmit only one paging message to the terminal. .
  • the terminal of the present specification may be a terminal mounted on a vehicle. Further, the terminal of the present specification may be replaced with an autonomous vehicle as described through FIG. 15.
  • a vehicle equipped with a terminal (or an autonomous vehicle) is in a state in which a large-capacity communication with a base station is not required, such as a parking state
  • minimizing power consumption of the terminal may be advantageous for terminal operation.
  • a mobile terminal such as a terminal related to a vehicle, may move to a place in need of wide coverage support, such as an underground parking lot, after RRC connection is released.
  • the terminal in which the RRC connection is released may need to retrace the coverage, and the retrace process for changing the coverage may include additional data transmission and reception, processing of the terminal and the network (eg, re-execution of the random access process and/or switching of the terminal global ID) Since it is required, it may be advantageous for the operation of the terminal and the network to switch the IoT mode in connection with the transition to the RRC_IDLE state in order to prevent wasting and delay of the resources consumed.
  • IoT mode of can be switched to non-BL CE mode, eMTC mode or NB-IoT mode.
  • the IoT mode of the terminal within a certain time point when the terminal communicating with the RRC connection in eMTC mode is switched to the RRC_IDLE state or at the same time when the terminal receives the RRC connection release message instructing to switch to the RRC_IDLE state. Can be switched to the NB-IoT mode.
  • the IoT mode before switching may be referred to as a source IoT mode
  • the IoT mode after switching may be referred to as a target IoT mode.
  • a specific example of the case in which the IoT mode is also switched in relation to the case in which the terminal is switched from the RRC_CONNECTED state to the RRC_IDLE state may be the same as the method (1-1) and/or the method (1-2).
  • Method (1-1) The base station instructs the RRC_CONNECTED state of the RRC connection release (connection release) while indicating the IoT mode switch together
  • FIG. 7(a) shows the operation of the terminal and the base station when the base station instructs the IoT mode together while instructing the RRC connection to the terminal in the RRC_CONNECTED state
  • FIG. 7(b) shows that the base station releases the RRC connection to the terminal in the RRC_CONNECTED state.
  • an instruction to switch to the IoT mode for the terminal to monitor paging in the RRC_IDLE state may be transmitted.
  • the switching instruction to the IoT mode for monitoring paging may include an instruction of the target IoT mode.
  • a non-BL CE mode, an eMTC mode, or an NB-IoT mode may be indicated as a target IoT mode to a terminal in which the source IoT mode is a non-BL mode.
  • the network may determine that it is efficient for the corresponding terminal to switch to the standby mode based on the information on the buffer state, service state and/or location information of the terminal.
  • the network which determines that it is efficient for the terminal to switch to the standby mode, can instruct the base station to switch the terminal to the RRC_IDLE state. Accordingly, the base station may instruct the corresponding terminal to release the RRC connection.
  • the base station In order to receive paging in the target IoT mode, the base station is configured with parameters necessary for operation in the target IoT mode, such as the number of repetitions to be applied to (N/M)PDCCH/PDSCH reception and/or the level of CE (Coverage Enhancement). Can tell. Parameters required for operation in the target IoT mode may be set in the terminal through an RRC configuration message in advance before transmitting the RRC connection release message. Parameters required for operation in the target IoT mode may be set in the terminal through the RRC connection release message. Among the one or more parameter sets previously set in the terminal based on the RRC setup message, the base station notifies the terminal through the RRC connection release message to the terminal, so that parameters required for operation in the target IoT mode are set in the terminal It might be.
  • the terminal may monitor the paging based on the parameters set by the instruction from the base station after switching from the source IoT mode to the target IoT mode while switching from the RRC_CONNECTED state to the RRC_IDLE state according to the instructions of the base station.
  • the operation of monitoring paging includes an operation of monitoring whether there is P-RNTI PDCCH transmission in Paging (Occasion).
  • the UE can receive the PDSCH indicated by the P-RNTI PDCCH.
  • the PDSCH includes a terminal global ID and information transmitted to the corresponding terminal. The (repeated) transmission/reception of the P-RNTI PDCCH/PDSCH may be performed based on the target IoT mode.
  • the terminal performs the target IoT mode-based operation before the currently set source IoT mode is released may be to test and/or verify whether the terminal can actually operate in the target IoT mode indicated. For example, when the base station and the terminal operate in a corresponding target IoT mode, it may be tested and/or verified whether an expected requirement (coverage, power saving, etc.) is satisfied.
  • the terminal receives a new IoT mode setting from the base station or the source IoT It can also be set to stay in the mode. For example, if the target IoT mode includes the CE mode A setting, if feedback such as PUCCH/PUSCH from the terminal is not received or if the feedback reception performance does not satisfy a specific SINR value, the base station has a larger target IoT mode.
  • the target IoT mode can be reset to include a CE mode B setting that can support coverage.
  • FIG. 8(a) shows the operation of the terminal and the base station when the terminal in the RRC_CONNECTED state requests to switch to the IoT mode while requesting the RRC connection release to the base station
  • FIG. 8(b) shows that the terminal in the RRC_CONNECTED state releases the RRC connection to the base station.
  • the UE in the RRC_CONNECTED state may request to switch the IoT mode to be applied when monitoring paging in the RRC_IDLE state.
  • the terminal may request the IoT mode switch and the preferred target IoT mode together.
  • a terminal in which the source IoT mode is a non-BL mode may request a non-BL CE mode, an eMTC mode, or an NB-IoT mode as a target IoT mode.
  • the terminal in which the source IoT mode is eMTC mode may request the NB-IoT mode as the target IoT mode.
  • the preferred target IoT mode may be determined in consideration of the state of the terminal before switching to the RRC IDLE state.
  • a state of the terminal for example, a reference signal received power (RSRP), a received signal quality (Reference Signal Received Quality; RSRQ) and/or a receive path loss may be considered.
  • the preferred target IoT mode may be determined based on the worst communication environment that the terminal can anticipate. As the worst predictable communication environment, for example, statistically worst received signal power (RSRP), statistically worst received signal quality (RSRQ) and/or statistically worst received pathloss may be used as criteria. Can be.
  • the terminal may switch to the RRC_IDLE state and monitor paging based on the preferred target IoT mode requested by the terminal.
  • the base station refuses to switch to the preferred target IoT mode requested from the terminal or instructs to switch to another target IoT mode, in the RRC_IDLE state, the terminal stays in the source IoT mode or the target IoT mode indicated by the base station , Paging monitoring and other operations required in RRC_IDLE mode (eg, DL measurement, cell selection/reselection, random access, etc.) can be performed.
  • the type and signal bandwidth of the DL reference signal to be applied to the DL measurement (measurement), the period of DL measurement and reporting, the condition of a radio link failure, the condition of a cell capable of connection (eg , eMTC, whether NB-IoT is supported), a resource to be used for random access preamble transmission, and/or a random access preamble structure may be changed according to the IoT mode.
  • the terminal may request a second target IoT mode that can be used when an operation problem occurs in the target IoT mode.
  • the second target IoT mode may be set for a fallback operation when the target IoT mode cannot be used.
  • the target IoT mode may not support the data rate required for data transmission of the terminal.
  • the second target IoT mode may be set by an instruction of the base station corresponding to the request of the terminal. Alternatively, the base station may set the second target IoT mode without requesting the terminal.
  • the terminal in the RRC_CONNECTED state negotiates in advance with the base station through the RRC message the preferred IoT mode when the RRC_IDLE state is reached. You may. For example, the terminal may transmit information on the preferred target IoT mode in the RRC_CONNECTED state to the base station.
  • the base station may approve the switch to the preferred target IoT mode requested from the terminal, or may reject the switch or instruct the switch to another target IoT mode.
  • the terminal may transmit information on the second preferred target IoT mode that can be used when an operation problem occurs in the preferred target IoT mode to the base station.
  • the base station may approve the switch to one of the plurality of preferred target IoT modes requested from the terminal, or may indicate the switch to another target IoT mode.
  • the target IoT mode for the RRC_IDLE state is negotiated between the base station and the terminal, when the base station instructs the terminal to release the RRC connection, or when the UE is switched to the RRC_IDLE state for some other reason, the terminal is pre-negotiated target IoT You can monitor paging based on the mode.
  • the base station In order to receive paging in the target IoT mode, the base station is configured with parameters necessary for operation in the target IoT mode, such as the number of repetitions to be applied to (N/M)PDCCH/PDSCH reception and/or the level of CE (Coverage Enhancement). Can tell. Parameters required for operation in the target IoT mode may be set in the terminal through an RRC configuration message in advance before the RRC connection release process. Parameters necessary for operation in the target IoT mode may be set in the terminal through a response message of the base station to the RRC connection release request of the terminal.
  • parameters necessary for operation in the target IoT mode such as the number of repetitions to be applied to (N/M)PDCCH/PDSCH reception and/or the level of CE (Coverage Enhancement). Can tell. Parameters required for operation in the target IoT mode may be set in the terminal through an RRC configuration message in advance before the RRC connection release process. Parameters necessary for operation in the target IoT mode may be set
  • the base station informs the terminal through a response message to the RRC connection release request to the terminal, and parameters required for operation in the target IoT mode It may be set in the terminal.
  • the terminal may monitor paging based on the parameters set by the instruction from the base station after switching from the source IoT mode to the target IoT mode, while switching from the RRC_CONNECTED state to the RRC_IDLE state according to the request and/or the instruction of the base station. have.
  • the operation of monitoring paging includes an operation of monitoring whether there is P-RNTI PDCCH transmission in Paging (Occasion).
  • the UE can receive the PDSCH indicated by the P-RNTI PDCCH.
  • the PDSCH includes a terminal global ID and information transmitted to the corresponding terminal. The (repeated) transmission/reception of the P-RNTI PDCCH/PDSCH may be performed based on the target IoT mode.
  • the UE switches from the RRC_CONNECTED state to the RRC_IDLE state according to its request and/or the instruction of the base station, and after switching from the source IoT mode to the target IoT mode, in addition to paging monitoring based on the parameters set by the instruction from the base station, the RRC_IDLE mode You can perform the required operation (eg, DL measurement, cell selection/reselection, random access, etc.).
  • the required operation eg, DL measurement, cell selection/reselection, random access, etc.
  • the terminal may be advantageous for the terminal to change the IoT mode through an RRC connection release request in consideration of its application.
  • the terminal of the present specification may be a terminal mounted on a vehicle. Further, the terminal of the present specification may be replaced with an autonomous vehicle as described through FIG. 15.
  • a standby state such as a parking state or in a combination loss environment such as an underground parking lot.
  • firmware update it may be necessary to switch to the IoT mode supporting higher data capacity.
  • a terminal that has stayed in an IoT mode suitable for low power/coverage improvement in an RRC_IDLE state in an underground parking lot, etc. may be switched to an RRC_CONNECTED state while escaping from the underground parking lot for reasons such as vehicle operation.
  • a terminal staying in RRC_IDLE state in non-BL CE mode, eMTC mode, or NB-IoT mode switches IoT mode to non-BL mode at the same time as when establishing an RRC connection or starting a RRC connection process. can do.
  • the terminal staying in the RRC_IDLE state in the NB-IoT mode may switch the IoT mode to the eMTC mode at the same time as making the RRC connection or within a certain time from the start of the RRC connection process.
  • a specific example of the case in which the IoT mode is also switched with respect to the case where the terminal is switched from the RRC_IDLE state to the RRC_CONNECTED state may be the same as the method (2-1) and/or the method (2-2).
  • FIG. 9(a) shows the operation of the terminal and the base station when the base station instructs the IoT mode switching while transmitting the paging message to the terminal in the RRC_IDLE state
  • FIG. 9(b) shows the base station delivers the paging message to the terminal in the RRC_IDLE state.
  • the terminal operation is illustrated.
  • a network eg, eNB or gNB
  • transmits a paging message to a terminal in the RRC_IDLE state it is possible to instruct IoT mode switching through the paging message.
  • the paging message includes the global ID of a specific terminal, the network may instruct the terminal corresponding to the global ID to switch IoT.
  • the global ID may be, for example, TMSI (Temporary Mobile Subscriber Identity) and/or IMSI (International Mobile Subscriber Identity).
  • the base station may inform the target IoT mode together through a paging message.
  • the terminal Upon receiving the paging message, the terminal attempts random access to establish an RRC connection with the base station. For random access of the terminal, the following options may be followed.
  • the terminal performs random access based on the source IoT mode
  • the UE may establish an RRC connection with the base station through a procedure of random access preamble transmission, Msg2 reception, Msg3 transmission, and Msg4 reception through a method based on the Sword IoT mode.
  • the terminal switches to the target IoT mode, performs data transmission and reception with the base station, and performs necessary operations in the RRC_CONNECTED state.
  • random access preamble structure to be used according to the IoT mode resources for transmission of access preamble transmission, number of repetition of access preamble transmission, (M/N)PDCCH/(N)PDSCH structure to be applied to reception of Msg2/4, Msg2/4
  • the number of (M/N)PDCCH/(N)PDSCH repetitions to be applied to reception, the (N)PUSCH structure to be applied to Msg3 transmission, and/or the number of (N)PUSCH structures to be applied to Msg3 transmission may be different.
  • the base station is a target IoT mode such as the number of repetitions and/or coverage enhancement (CE) levels to be applied to (N/M)PDCCH/PDSCH reception and (N/M)PUCCH/PUSCH transmission in order for the UE to operate in the target IoT mode.
  • CE coverage enhancement
  • Parameters required for operation in the target IoT mode may be directly set to the terminal through a paging message, a message transmitted during the RRC connection procedure (eg, Msg4), and/or a message transmitted to the terminal after the RRC connection procedure. .
  • the parameters necessary for operation in the target IoT mode may be set in the terminal in advance through an RRC setting message while the terminal establishes an RRC connection before the RRC_IDLE state.
  • the base station sends a paging message to the UE and a message transmitted during the RRC connection procedure (eg For example, Msg4) and/or an RRC connection procedure may be informed through a message transmitted to the terminal, and parameters required for operation in the target IoT mode may be set in the terminal.
  • the base station may inform the terminal of the target IoT mode and/or related parameters through a message (e.g. Msg4 or RRC connection setup message) that the base station delivers to the terminal in the process of establishing an RRC connection.
  • a message e.g. Msg4 or RRC connection setup message
  • the terminal receiving the paging message targets the random access operation When starting in the mode, a random access operation is performed within a narrower coverage, so that the UE may fail to access the cell. Through the operation of option 1, a gain may be generated to avoid the terminal from failing to access the cell.
  • the source IoT mode supports narrower coverage than the target IoT mode, a problem may occur in receiving a paging signal in an area where path attenuation is large, such as an underground parking lot. Therefore, it may be advantageous for the terminal operation that the source IoT mode supports a wider coverage than the target IoT mode and that the random access operation is performed in the source IoT mode.
  • the terminal performs random access based on the target IoT mode
  • the terminal Upon receiving the paging message corresponding to itself, the terminal establishes an RRC connection with the base station through the procedures of random access preamble transmission, Msg2 reception, Msg3 transmission, and Msg4 reception using a method based on the target IoT mode, and based on the target IoT mode In the RRC_CONNECTED state, necessary actions are performed.
  • random access preamble structure to be used according to the IoT mode resources for transmission of access preamble transmission, number of repetition of access preamble transmission, (M/N)PDCCH/(N)PDSCH structure to be applied to reception of Msg2/4, Msg2/4
  • the number of (M/N)PDCCH/(N)PDSCH repetitions to be applied to reception, the (N)PUSCH structure to be applied to Msg3 transmission, and/or the number of (N)PUSCH structures to be applied to Msg3 transmission may be different.
  • the base station is a target IoT mode such as the number of repetitions and/or coverage enhancement (CE) levels to be applied to (N/M)PDCCH/PDSCH reception and (N/M)PUCCH/PUSCH transmission in order for the UE to operate in the target IoT mode.
  • CE coverage enhancement
  • Parameters required for operation in the target IoT mode may be directly set to the terminal through a paging message, a message transmitted during the RRC connection procedure (eg, Msg4), and/or a message transmitted to the terminal after the RRC connection procedure.
  • the parameters necessary for operation in the target IoT mode may be set in the terminal in advance through an RRC configuration message while the terminal establishes an RRC connection before the RRC_IDLE state.
  • the base station sends a paging message to the UE and a message transmitted during the RRC connection procedure (eg For example, Msg4) and/or an RRC connection procedure may be informed through a message transmitted to the terminal, and parameters required for operation in the target IoT mode may be set in the terminal.
  • RRC connection procedure eg For example, Msg4
  • Msg4 a message transmitted during the RRC connection procedure
  • an RRC connection procedure may be informed through a message transmitted to the terminal, and parameters required for operation in the target IoT mode may be set in the terminal.
  • different parameter sets for (N)PRACH, (M/N)PDCCH, (N)PDSCH, (N)PUSCH, and (N)PRACH resources according to the number of repetitions Can be prepared. For example, even among terminals in the same IoT mode, when the set parameter set is different, the maximum number of repetitions of the channel and/or channel transmission resource may be different.
  • Option 3 Depending on the conditions determined by the terminal itself, one of options 1) and 2) is followed.
  • the UE can perform random access by selecting one of options 1) and 2) based on specific conditions such as signal reception strength (eg, RSRP) from the base station.
  • specific conditions such as signal reception strength (eg, RSRP) from the base station.
  • RSRP signal reception strength
  • option 1) may be selected, otherwise, option 2) may be selected to operate.
  • the terminal of the present specification may be a terminal mounted on a vehicle. Further, the terminal of the present specification may be replaced with an autonomous vehicle as described through FIG. 15.
  • the environment of the terminal monitoring paging in the RRC_IDLE state in a specific IoT mode may be changed to an environment in which coupling loss is large, such as an underground parking lot.
  • the terminal In order to receive paging in a manner capable of compensating for a large coupling loss, the terminal needs to be switched to an IoT mode suitable for improving coverage while maintaining the RRC_IDLE state.
  • a terminal staying in the RRC_IDLE state in the non-BL mode may switch the IoT mode to the non-BL CE mode, eMTC mode, or NB-IoT mode while maintaining the RRC_IDLE state.
  • a terminal staying in the RRC_IDLE state in the eMTC mode may switch the IoT mode to the NB-IoT mode while maintaining the RRC_IDLE state.
  • the terminal may switch the IoT mode in a manner that does not need to compensate for a large coupling loss.
  • a terminal staying in the RRC_IDLE state in a non-BL CE mode, an eMTC mode or an NB-IoT mode may switch the IoT mode to a non-BL mode while maintaining the RRC_IDLE state.
  • a terminal staying in the RRC_IDLE state in the NB-IoT mode may switch the IoT mode to the eMTC mode while maintaining the RRC_IDLE state.
  • a specific example when the terminal switches the IoT mode in the RRC_IDLE state may be the same as the method (3-1).
  • Method (3-1) UE in RRC_IDLE state requests to switch to IoT mode through a random access process
  • FIG. 10 illustrates a terminal operation when the base station instructs the IoT mode change while transmitting a paging message to the terminal in the RRC_IDLE state.
  • the UE in the RRC_IDLE state may inform the base station to operate in a target IoT mode different from the source IoT mode in the RRC_IDLE state in the future, or request the base station to operate in a different target IoT mode. have.
  • the request may be included in the Msg3 transmitted after receiving the Msg2 from the base station after transmitting the random access preamble of the terminal.
  • the request may be included in the transmission of the (EDT based) message of the terminal after the transmission of Msg3.
  • the base station may accept or reject to operate in the requested target IoT mode through transmission of a response message corresponding to the request message from the terminal.
  • Msg3 includes a CCCH SDU associated with a terminal contention resolution ID (eg, UE global ID) for contention resolution, and through this, information on a terminal requesting an IoT mode switch can be informed to a base station.
  • a terminal contention resolution ID eg, UE global ID
  • the base station In order to receive paging in the target IoT mode, the base station is configured with parameters necessary for operation in the target IoT mode, such as the number of repetitions to be applied to (N/M)PDCCH/PDSCH reception and/or the level of CE (Coverage Enhancement). Can tell.
  • the parameters required for operation in the target IoT mode include a paging message, a message transmitted during the RRC connection procedure (eg, Msg4), and/or a message transmitted to a terminal after the RRC connection procedure (eg, EDT-based message). It can be set directly to the terminal through.
  • the parameters necessary for operation in the target IoT mode may be set in the terminal in advance through an RRC setting message while the terminal establishes an RRC connection before the RRC_IDLE state.
  • the base station sends a paging message to the UE and a message transmitted during the RRC connection procedure (eg For example, Msg4) and/or an RRC connection procedure may be informed through a message transmitted to the terminal, and parameters required for operation in the target IoT mode may be set in the terminal.
  • the UE When the IoT mode is changed in the RRC_IDLE state, the UE does not need to perform a connection procedure with the base station through a random access procedure, so for a UE in the NB-IoT, eMTC or NR-lite state, the random access procedure is applicable. It can be performed based on the EDT operation defined in the standard.
  • the terminal may perform paging reception and/or necessary operations in the target IoT mode requested by the user in the RRC_IDLE state based on the response of the base station (if the base station accepts the switch to the target IoT mode).
  • the terminal may perform paging reception and/or necessary operations in the existing source IoT mode based on the response of the base station (if the base station refuses to switch to the target IoT mode).
  • Embodiments may be implemented by organically combining one or more of the operations described above.
  • embodiments of the present invention may be performed by a communication device including a terminal, and receiving a RRC (Radio Resource Control) connection release message (S1101), based on the RRC connection release message. It may be configured to include the step of releasing the RRC connection (S1103).
  • RRC Radio Resource Control
  • the RRC connection release message may include information about the target IoT mode.
  • the communication device is switched from the source IoT mode to the target IoT mode based on the information on the target IoT mode.
  • the IoT mode switching time may be associated with an RRC disconnection operation.
  • the IoT mode may be switched simultaneously with disconnection of the RRC.
  • RRC connection release and IoT mode switching are not necessarily performed at the same time, and IoT mode switching may be performed within a predetermined time after the terminal receives the RRC connection release message.
  • Information about the target IoT mode may be transmitted by being included in the RRC connection release message by the network. Also, the RRC connection release message may be transmitted in response to the RRC connection release request message from the communication device.
  • the RRC connection release request message may include information on preferred target IoT modes, which is information on one or more target IoT modes preferred by the communication device.
  • information on the target IoT mode may be predetermined based on the result of negotiation between the communication device and the network before the communication device receives the RRC connection release message. The predetermined target IoT mode information may be received by the communication device before receiving the RRC connection release message.
  • Information about one or more parameters for the operation of the target IoT mode may be received through an RRC configuration message and/or through the RRC connection release message before RRC connection release.
  • Information about one or more parameters may include information about one or more parameter sets.
  • the communication device may test whether the operation of the target IoT mode satisfies a specific criterion before RRC connection release. If the test is satisfied, the communication device can operate based on the target IoT mode. If the test is not satisfied, the communication device may operate based on the source IoT mode or the second target IoT mode.
  • the communication device switched to the target IoT mode may monitor the paging message based on the target IoT mode after the RRC connection is released.
  • the communication system 1 applied to the present invention includes a wireless device, a base station and a network.
  • the wireless device means a device that performs communication using a radio access technology (eg, 5G NR (New RAT), Long Term Evolution (LTE)), and may be referred to as a communication/wireless/5G device.
  • a radio access technology eg, 5G NR (New RAT), Long Term Evolution (LTE)
  • LTE Long Term Evolution
  • the wireless device includes a robot 100a, a vehicle 100b-1, 100b-2, an XR (eXtended Reality) device 100c, a hand-held device 100d, and a home appliance 100e. ), Internet of Thing (IoT) devices 100f, and AI devices/servers 400.
  • IoT Internet of Thing
  • the vehicle may include a vehicle equipped with a wireless communication function, an autonomous driving vehicle, a vehicle capable of performing inter-vehicle communication, and the like.
  • the vehicle may include a UAV (Unmanned Aerial Vehicle) (eg, a drone).
  • XR devices include Augmented Reality (AR)/Virtual Reality (VR)/Mixed Reality (MR) devices, Head-Mounted Device (HMD), Head-Up Display (HUD) provided in vehicles, televisions, smartphones, It may be implemented in the form of a computer, wearable device, home appliance, digital signage, vehicle, robot, or the like.
  • the mobile device may include a smart phone, a smart pad, a wearable device (eg, a smart watch, smart glasses), a computer (eg, a notebook, etc.).
  • Household appliances may include a TV, a refrigerator, and a washing machine.
  • IoT devices may include sensors, smart meters, and the like.
  • the base station and the network may also be implemented as wireless devices, and the specific wireless device 200a may operate as a base station/network node to other wireless devices.
  • the wireless devices 100a to 100f may be connected to the network 300 through the base station 200.
  • AI Artificial Intelligence
  • the network 300 may be configured using a 3G network, a 4G (eg, LTE) network, or a 5G (eg, NR) network.
  • the wireless devices 100a to 100f may communicate with each other through the base station 200/network 300, but may directly communicate (e.g. sidelink communication) without going through the base station/network.
  • the vehicles 100b-1 and 100b-2 may communicate directly (e.g. Vehicle to Vehicle (V2V)/Vehicle to everything (V2X) communication).
  • the IoT device eg, sensor
  • the IoT device may directly communicate with other IoT devices (eg, sensor) or other wireless devices 100a to 100f.
  • Wireless communication/connections 150a, 150b, and 150c may be achieved between the wireless devices 100a to 100f/base station 200 and the base station 200/base station 200.
  • the wireless communication/connection is various wireless access such as uplink/downlink communication 150a and sidelink communication 150b (or D2D communication), base station communication 150c (eg relay, IAB (Integrated Access Backhaul)). It can be achieved through technology (eg, 5G NR).
  • wireless communication/connections 150a, 150b, 150c wireless devices and base stations/wireless devices, base stations and base stations can transmit/receive radio signals to each other.
  • the wireless communication/connections 150a, 150b, 150c can transmit/receive signals through various physical channels.
  • various signal processing processes eg, channel encoding/decoding, modulation/demodulation, resource mapping/demapping, etc.
  • resource allocation processes e.g., resource allocation processes, and the like.
  • FIG. 13 illustrates a wireless device that can be applied to the present invention.
  • the first wireless device 100 and the second wireless device 200 may transmit and receive wireless signals through various wireless access technologies (eg, LTE and NR).
  • ⁇ the first wireless device 100, the second wireless device 200 ⁇ is ⁇ wireless device 100x, base station 200 ⁇ and/or ⁇ wireless device 100x), wireless device 100x in FIG. 12 ⁇ .
  • the first wireless device 100 includes one or more processors 102 and one or more memories 104, and may further include one or more transceivers 106 and/or one or more antennas 108.
  • the processor 102 controls the memory 104 and/or transceiver 106 and may be configured to implement the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed herein.
  • the processor 102 may process information in the memory 104 to generate the first information/signal, and then transmit the wireless signal including the first information/signal through the transceiver 106.
  • the processor 102 may receive the wireless signal including the second information/signal through the transceiver 106 and store the information obtained from the signal processing of the second information/signal in the memory 104.
  • the memory 104 may be connected to the processor 102 and may store various information related to the operation of the processor 102.
  • the memory 104 is an instruction to perform some or all of the processes controlled by the processor 102, or to perform the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed herein. You can store software code that includes
  • the processor 102 and the memory 104 may be part of a communication modem/circuit/chip designed to implement wireless communication technology (eg, LTE, NR).
  • the transceiver 106 can be coupled to the processor 102 and can transmit and/or receive wireless signals through one or more antennas 108.
  • the transceiver 106 may include a transmitter and/or receiver.
  • the transceiver 106 may be mixed with a radio frequency (RF) unit.
  • the wireless device may mean a communication modem/circuit/chip.
  • the second wireless device 200 includes one or more processors 202, one or more memories 204, and may further include one or more transceivers 206 and/or one or more antennas 208.
  • the processor 202 controls the memory 204 and/or transceiver 206 and may be configured to implement the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed herein.
  • the processor 202 may process information in the memory 204 to generate third information/signal, and then transmit a wireless signal including the third information/signal through the transceiver 206.
  • the processor 202 may receive the wireless signal including the fourth information/signal through the transceiver 206 and store the information obtained from the signal processing of the fourth information/signal in the memory 204.
  • the memory 204 may be connected to the processor 202, and may store various information related to the operation of the processor 202.
  • the memory 204 is an instruction to perform some or all of the processes controlled by the processor 202, or to perform the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed herein. You can store software code that includes
  • the processor 202 and the memory 204 may be part of a communication modem/circuit/chip designed to implement wireless communication technology (eg, LTE, NR).
  • the transceiver 206 can be coupled to the processor 202 and can transmit and/or receive wireless signals through one or more antennas 208.
  • Transceiver 206 may include a transmitter and/or receiver.
  • Transceiver 206 may be mixed with an RF unit.
  • the wireless device may mean a communication modem/circuit/chip.
  • one or more protocol layers may be implemented by one or more processors 102 and 202.
  • one or more processors 102, 202 may implement one or more layers (eg, functional layers such as PHY, MAC, RLC, PDCP, RRC, SDAP).
  • the one or more processors 102 and 202 may include one or more Protocol Data Units (PDUs) and/or one or more Service Data Units (SDUs) according to the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed herein. Can be created.
  • PDUs Protocol Data Units
  • SDUs Service Data Units
  • the one or more processors 102, 202 may generate messages, control information, data or information according to the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed herein.
  • the one or more processors 102, 202 generate signals (eg, baseband signals) including PDUs, SDUs, messages, control information, data or information according to the functions, procedures, suggestions and/or methods disclosed herein. , 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 descriptions, functions, procedures, suggestions, methods and/or operational flow diagrams disclosed herein Depending on the field, PDU, SDU, message, control information, data or information may be acquired.
  • signals eg, baseband signals
  • One or more processors 102, 202 may be referred to as a controller, microcontroller, microprocessor, or microcomputer.
  • the one or more processors 102, 202 can be implemented by hardware, firmware, software, or a combination thereof.
  • ASICs Application Specific Integrated Circuits
  • DSPs Digital Signal Processors
  • DSPDs Digital Signal Processing Devices
  • PLDs Programmable Logic Devices
  • FPGAs Field Programmable Gate Arrays
  • Descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed in this document may be implemented using firmware or software, and firmware or software may be implemented to include modules, procedures, functions, and the like.
  • the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed herein are either firmware or software set to perform or are stored in one or more processors 102, 202 or stored in one or more memories 104, 204. It can be driven by the above processors (102, 202).
  • the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed herein can be implemented using firmware or software in the form of code, instructions and/or instructions.
  • the one or more memories 104, 204 may be coupled to 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 be comprised of ROM, RAM, EPROM, flash memory, hard drives, registers, cache memory, computer readable storage media, and/or combinations thereof.
  • the one or more memories 104, 204 may be located inside and/or outside of the one or more processors 102, 202. Also, the one or more memories 104 and 204 may be connected to the one or more processors 102 and 202 through various technologies such as a wired or wireless connection.
  • the one or more transceivers 106 and 206 may transmit user data, control information, radio signals/channels, and the like referred to in the methods and/or operational flowcharts of this document to one or more other devices.
  • the one or more transceivers 106, 206 may receive user data, control information, radio signals/channels, and the like referred to in the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed herein from one or more other devices. have.
  • one or more transceivers 106, 206 may be connected to one or more processors 102, 202, and may 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, or wireless signals 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, or wireless signals from one or more other devices.
  • one or more transceivers 106, 206 may be coupled to one or more antennas 108, 208, and one or more transceivers 106, 206 may be described, functions described herein through one or more antennas 108, 208.
  • the one or more antennas may be a plurality of physical antennas or a plurality of logical antennas (eg, antenna ports).
  • the one or more transceivers 106 and 206 use the received radio signal/channel and the like in the RF band signal to process the received user data, control information, radio signal/channel, and the like using one or more processors 102 and 202. It can be converted to a baseband signal.
  • the one or more transceivers 106 and 206 may convert user data, control information, and radio signals/channels processed using one or more processors 102 and 202 from a baseband signal to an RF band signal. To this end, the one or more transceivers 106, 206 may include (analog) oscillators and/or filters.
  • the wireless device 14 shows another example of a wireless device applied to the present invention.
  • the wireless device may be implemented in various forms according to use-example/service (see FIG. 12).
  • the wireless devices 100 and 200 correspond to the wireless devices 100 and 200 of FIG. 13, and various elements, components, units/units, and/or modules ).
  • the wireless devices 100 and 200 may include a communication unit 110, a control unit 120, a memory unit 130, and additional elements 140.
  • the communication unit may include a communication circuit 112 and a transceiver(s) 114.
  • the communication circuit 112 can include one or more processors 102,202 and/or one or more memories 104,204 of FIG.
  • the transceiver(s) 114 may include one or more transceivers 106,206 and/or one or more antennas 108,208 of FIG. 13.
  • the control unit 120 is electrically connected to the communication unit 110, the memory unit 130, and the additional element 140, and controls various operations of the wireless device. For example, the controller 120 may control the electrical/mechanical operation of the wireless device based on the program/code/command/information stored in the memory unit 130. In addition, the control unit 120 transmits information stored in the memory unit 130 to the outside (eg, another communication device) through the wireless/wired interface through the communication unit 110 or externally (eg, through the communication unit 110). Information received through a wireless/wired interface from another communication device) may be stored in the memory unit 130.
  • the additional element 140 may be variously configured according to the type of wireless device.
  • the additional element 140 may include at least one of a power unit/battery, an input/output unit (I/O unit), a driving unit, and a computing unit.
  • wireless devices include robots (FIGS. 12, 100A), vehicles (FIGS. 12, 100B-1, 100B-2), XR devices (FIGS. 12, 100C), portable devices (FIGS. 12, 100D), and home appliances. (Fig. 12, 100e), IoT device (Fig.
  • digital broadcasting terminal digital broadcasting terminal
  • hologram device public safety device
  • MTC device medical device
  • fintech device or financial device
  • security device climate/environment device
  • It may be implemented in the form of an AI server/device (FIGS. 12 and 400), a base station (FIGS. 12 and 200), and a network node.
  • the wireless device may be mobile or may be used in a fixed place depending on use-example/service.
  • various elements, components, units/parts, and/or modules in the wireless devices 100 and 200 may be connected to each other through a wired interface, or at least some of them may be connected wirelessly through the communication unit 110.
  • the control unit 120 and the communication unit 110 are connected by wire, and the control unit 120 and the first unit (eg, 130 and 140) are connected through the communication unit 110. It can be connected wirelessly.
  • each element, component, unit/unit, and/or module in the wireless devices 100 and 200 may further include one or more elements.
  • the controller 120 may be composed of one or more processor sets.
  • control unit 120 may include a set of communication control processor, application processor, electronic control unit (ECU), graphic processing processor, and memory control processor.
  • memory unit 130 includes random access memory (RAM), dynamic RAM (DRAM), read only memory (ROM), flash memory, volatile memory, and non-volatile memory (non- volatile memory) and/or combinations thereof.
  • Vehicles or autonomous vehicles can be implemented as mobile robots, vehicles, trains, aerial vehicles (AVs), ships, and the like.
  • the vehicle or autonomous vehicle 100 includes an antenna unit 108, a communication unit 110, a control unit 120, a driving unit 140a, a power supply unit 140b, a sensor unit 140c, and autonomous driving. It may include a portion (140d).
  • the antenna unit 108 may be configured as part of the communication unit 110. Blocks 110/130/140a through 140d correspond to blocks 110/130/140 in FIG. 14, respectively.
  • the communication unit 110 may transmit and receive signals (eg, data, control signals, etc.) with external devices such as other vehicles, base stations (e.g. base stations, road side units, etc.) and servers.
  • the controller 120 may perform various operations by controlling elements of the vehicle or the autonomous vehicle 100.
  • the controller 120 may include an electronic control unit (ECU).
  • the driving unit 140a may cause the vehicle or the autonomous vehicle 100 to travel on the ground.
  • the driving unit 140a may include an engine, a motor, a power train, wheels, brakes, and steering devices.
  • the power supply unit 140b supplies power to the vehicle or the autonomous vehicle 100 and may include a wired/wireless charging circuit, a battery, and the like.
  • the sensor unit 140c may obtain vehicle status, surrounding environment information, user information, and the like.
  • the sensor unit 140c includes an IMU (inertial measurement unit) sensor, a collision sensor, a wheel sensor, a speed sensor, a tilt sensor, a weight sensor, a heading sensor, a position module, and a vehicle forward /Reverse sensor, battery sensor, fuel sensor, tire sensor, steering sensor, temperature sensor, humidity sensor, ultrasonic sensor, illumination sensor, pedal position sensor, and the like.
  • the autonomous driving unit 140d maintains a driving lane, automatically adjusts speed, such as adaptive cruise control, and automatically travels along a predetermined route, and automatically sets a route when a destination is set. Technology, etc. can be implemented.
  • the communication unit 110 may receive map data, traffic information data, and the like from an external server.
  • the autonomous driving unit 140d may generate an autonomous driving route and a driving plan based on the acquired data.
  • the control unit 120 may control the driving unit 140a so that the vehicle or the autonomous vehicle 100 moves along the autonomous driving path according to a driving plan (eg, speed/direction adjustment).
  • the communication unit 110 may acquire the latest traffic information data non-periodically from an external server, and may acquire surrounding traffic information data from nearby vehicles.
  • the sensor unit 140c may acquire vehicle status and surrounding environment information.
  • the autonomous driving unit 140d may update the autonomous driving route and driving plan based on newly acquired data/information.
  • the communication unit 110 may transmit information regarding a vehicle location, an autonomous driving route, and a driving plan to an external server.
  • the external server may predict traffic information data in advance using AI technology or the like based on the information collected from the vehicle or autonomous vehicles, and provide the predicted traffic information data to the vehicle or autonomous vehicles.
  • the present invention can be applied to various wireless communication systems.

Landscapes

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

Abstract

본 발명의 일 실시예에 따른 무선 통신 시스템의 방법 및 장치는, RRC (Radio Resource Control) 연결 해제 메시지를 수신하고, 상기 RRC 연결 해제 메시지에 기반하여 RRC 연결을 해제하며, 상기 RRC 연결 해제 메시지는, 상기 타겟 IoT (Internet of Things) 모드에 대한 정보를 포함하고, 상기 타겟 IoT 모드에 대한 정보에 기반하여, 상기 통신 장치는 소스 IoT 모드에서 타겟 IoT 모드로 전환되는 것을 포함한다.

Description

무선 통신 시스템에서 동작하는 방법 및 장치
본 발명은 무선 통신 시스템에서 사용되는 방법 및 장치에 관한 것이다.
무선 통신 시스템이 음성이나 데이터 등과 같은 다양한 종류의 통신 서비스를 제공하기 위해 광범위하게 전개되고 있다. 일반적으로 무선통신 시스템은 가용한 시스템 자원(대역폭, 전송 파워 등)을 공유하여 다중 사용자와의 통신을 지원할 수 있는 다중 접속(multiple access) 시스템이다. 다중 접속 시스템의 예들로는 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) 시스템 등이 있다.
본 발명이 이루고자 하는 기술적 과제는, 복수의 IoT 모드들을 지원하는 방법 및 장치를 제공함에 있다.
본 발명의 기술적 과제는 상술된 기술적 과제에 제한되지 않으며, 다른 기술적 과제들이 본 발명의 실시예로부터 유추될 수 있다.
본 발명은 무선 통신 시스템에서 동작하는 방법 및 장치를 제공한다.
본 발명의 일 양태로서, 무선 통신 시스템에서 통신 장치에 의해 수행되는 방법으로서, RRC (Radio Resource Control) 연결 해제 메시지를 수신하는 단계; 상기 RRC 연결 해제 메시지에 기반하여, RRC 연결을 해제하는 단계; 를 포함하며, 상기 RRC 연결 해제 메시지는 상기 타겟 IoT (Internet of Things) 모드에 대한 정보를 포함하고, 상기 타겟 IoT 모드에 대한 정보에 기반하여, 상기 통신 장치는 소스 IoT 모드에서 타겟 IoT 모드로 전환되는, 방법이 제공된다.
본 발명의 다른 일 양태로서, 무선 통신 시스템에서 동작하는 통신 장치로서, 적어도 하나의 트랜시버; 적어도 하나의 프로세서; 및 상기 적어도 하나의 프로세서에 동작 가능하도록 연결되고, 실행될 경우 상기 적어도 하나의 프로세서가 특정 동작을 수행하도록 하는 명령들(instructions)을 저장하는 적어도 하나의 메모리; 를 포함하고, 상기 특정 동작은, RRC (Radio Resource Control) 연결 해제 메시지를 수신하고, 상기 RRC 연결 해제 메시지에 기반하여, RRC 연결을 해제하는 것을 포함하며, 상기 RRC 연결 해제 메시지는 상기 타겟 IoT (Internet of Things) 모드에 대한 정보를 포함하고, 상기 타겟 IoT 모드에 대한 정보에 기반하여, 상기 통신 장치는 소스 IoT 모드에서 타겟 IoT 모드로 전환되는, 통신 장치가 제공된다.
상기 방법 또는 장치에 있어서, 상기 RRC 연결 해제와 동시에 또는 상기 RRC 연결 해제 메시지를 수신한 시점으로부터 일정 범위 이내의 시점에서, 상기 통신 장치는 소스 IoT 모드에서 상기 타겟 IoT 모드로 전환될 수 있다.
상기 방법 또는 장치에 있어서, 상기 타겟 IoT 모드는 하나 이상의 선호 타겟 IoT 모드들에 대한 정보에 기반하여 설정되며, 상기 하나 이상의 선호 타겟 IoT 모드들에 대한 정보는, 상기 통신 장치에 의해 전송되는 RRC 연결 해제 요청 메시지에 포함될 수 있다.
상기 방법 또는 장치에 있어서, 상기 타겟 IoT 모드는 상기 RRC 연결 해제 메시지의 수신 전에 미리 결정될 수 있다.
상기 방법 또는 장치에 있어서, 상기 타겟 IoT 모드의 동작을 위한 하나 이상의 파라미터들에 대한 정보는, 상기 RRC 연결 해제 전에 RRC 설정 메시지를 통해 수신 및/또는 상기 RRC 연결 해제 메시지를 통해 수신될 수 있다.
상기 방법 또는 장치에 있어서, 상기 통신 장치는 상기 RRC 연결 해제 이후 상기 타겟 IoT 모드를 기반으로 페이징(paging) 메시지를 모니터링할 수 있다.
상기 방법 또는 장치에 있어서, 상기 통신 장치는 상기 RRC 연결 해제 전에 상기 타겟 IoT 모드의 동작이 특정 기준을 만족하는지 여부를 테스트할 수 있다.
상기 장치는 적어도 단말, 네트워크 및 상기 통신 장치 외의 다른 자율 주행 차량과 통신할 수 있는 자율 주행 차량을 포함할 수 있다.
상술한 본 발명의 양태들은 본 발명의 바람직한 실시예들 중 일부에 불과하며, 본원 발명의 기술적 특징들이 반영된 다양한 실시예들이 당해 기술분야의 통상적인 지식을 가진 자에 의해 이하 상술할 본 발명의 상세한 설명을 기반으로 도출되고 이해될 수 있다.
본 발명의 일 실시예에 따르면, 복수의 IoT 모드들을 지원하는 방법 및 장치를 통해 데이터 지연 및 손실을 감소시킬 수 있다는 장점이 있다.
본 발명의 기술적 효과는 상술된 기술적 효과에 제한되지 않으며, 다른 기술적 효과들이 본 발명의 실시예로부터 유추될 수 있다.
도 1 및 도 2는 무선 프레임(radio frame)의 구조를 예시한다.
도 3은 슬롯의 자원 그리드(resource grid)를 예시한다.
도 4은 자기-완비(self-contained) 슬롯의 구조를 예시한다.
도 5는 NB-IoT에서 사용되는 대역폭을 나타낸다.
도 6은 랜덤 접속 과정을 나타낸다.
도 7 내지 도 11은 본 발명의 실시예에 따른 흐름도를 나타낸다.
도 12 내지 도 15는 본 발명의 실시예에 따른 장치들을 예시한다.
이하의 기술은 CDMA, FDMA, TDMA, OFDMA, SC-FDMA 등과 같은 다양한 무선 접속 시스템에 사용될 수 있다. 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 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)의 일부이고 LTE-A(Advanced)/LTE-A pro는 3GPP LTE의 진화된 버전이다. 3GPP NR(New Radio or New Radio Access Technology)는 3GPP LTE/LTE-A/LTE-A pro의 진화된 버전이다.
설명을 명확하게 하기 위해, 3GPP 통신 시스템(예, LTE, NR)을 기반으로 설명하지만 본 발명의 기술적 사상이 이에 제한되는 것은 아니다. LTE는 3GPP TS 36.xxx Release 8 이후의 기술을 의미한다. 세부적으로, 3GPP TS 36.xxx Release 10 이후의 LTE 기술은 LTE-A로 지칭되고, 3GPP TS 36.xxx Release 13 이후의 LTE 기술은 LTE-A pro로 지칭된다. 3GPP NR은 TS 38.xxx Release 15 이후의 기술을 의미한다. LTE/NR은 3GPP 시스템으로 지칭될 수 있다. "xxx"는 표준 문서 세부 번호를 의미한다. LTE/NR은 3GPP 시스템으로 통칭될 수 있다. 본 발명의 설명에 사용된 배경기술, 용어, 약어 등에 관해서는 본 발명 이전에 공개된 표준 문서에 기재된 사항을 참조할 수 있다. 예를 들어, 다음 문서를 참조할 수 있다.
3GPP LTE
- 36.211: Physical channels and modulation
- 36.212: Multiplexing and channel coding
- 36.213: Physical layer procedures
- 36.300: Overall description
- 36.331: Radio Resource Control (RRC)
3GPP NR
- 38.211: Physical channels and modulation
- 38.212: Multiplexing and channel coding
- 38.213: Physical layer procedures for control
- 38.214: Physical layer procedures for data
- 38.300: NR and NG-RAN Overall Description
- 38.331: Radio Resource Control (RRC) protocol specification
도 1은 LTE에서 사용되는 무선 프레임의 구조를 나타낸다.
도 1(a)는 타입 1 프레임 구조(frame structure type 1)를 나타낸다. 타입 1 프레임 구조는 전이중(full duplex) FDD(Frequency Division Duplex) 시스템과 반이중(half duplex) FDD 시스템 모두에 적용될 수 있다.
하나의 무선 프레임(radio frame)은 Tf = 307200*Ts = 10ms의 길이를 가지고, Tslot = 15360*Ts = 0.5ms의 균등한 길이를 가지며 0부터 19의 인덱스가 부여된 20개의 슬롯으로 구성된다. 하나의 서브프레임은 2개의 연속된 슬롯으로 정의되며, i 번째 서브프레임은 2i 와 2i+1에 해당하는 슬롯으로 구성된다. 즉, 무선 프레임(radio frame)은 10개의 서브프레임(subframe)으로 구성된다. 하나의 서브프레임을 전송하는 데 걸리는 시간을 TTI(transmission time interval)이라 한다. 여기서, Ts 는 샘플링 시간을 나타내고, Ts=1/(15kHzХ2048)=3.2552Х10-8(약 33ns)로 표시된다. 슬롯은 시간 영역에서 복수의 OFDM 심볼 또는 SC-FDMA 심볼을 포함하고, 주파수 영역에서 복수의 자원 블록(Resource Block)을 포함한다.
하나의 슬롯은 시간 영역에서 복수의 OFDM(orthogonal frequency division multiplexing) 심볼을 포함한다. 3GPP LTE는 하향링크에서 OFDMA를 사용하므로 OFDM 심볼은 하나의 심볼 구간(symbol period)을 표현하기 위한 것이다. OFDM 심볼은 하나의 SC-FDMA 심볼 또는 심볼 구간이라고 할 수 있다. 자원 블록(resource block)은 자원 할당 단위이고, 하나의 슬롯에서 복수의 연속적인 부반송파(subcarrier)를 포함한다.
전이중 FDD 시스템에서는 각 10ms 구간 동안 10개의 서브프레임은 하향링크 전송과 상향링크 전송을 위해 동시에 이용될 수 있다. 이때, 상향링크와 하향링크 전송은 주파수 영역에서 분리된다. 반면, 반이중 FDD 시스템의 경우 단말은 전송과 수신을 동시에 할 수 없다.
상술한 무선 프레임의 구조는 하나의 예시에 불과하며, 무선 프레임에 포함되는 서브 프레임의 수 또는 서브 프레임에 포함되는 슬롯의 수, 슬롯에 포함되는 OFDM 심볼의 수는 다양하게 변경될 수 있다.
도 1(b)는 타입 2 프레임 구조(frame structure type 2)를 나타낸다. 타입 2 프레임 구조는 TDD 시스템에 적용된다. 하나의 무선 프레임(radio frame)은 Tf = 307200*Ts = 10ms의 길이를 가지며, 153600*Ts = 5ms 길이를 가지는 2개의 하프프레임(half-frame)으로 구성된다. 각 하프프레임은 30720*Ts = 1ms의 길이를 가지는 5개의 서브프레임으로 구성된다. i 번째 서브프레임은 2i 와 2i+1에 해당하는 각 Tslot = 15360*Ts = 0.5ms의 길이를 가지는 2개의 슬롯으로 구성된다. 여기에서, Ts 는 샘플링 시간을 나타내고, Ts=1/(15kHz×2048)=3.2552×10-8(약 33ns)로 표시된다.
타입 2 프레임에는 DwPTS(Downlink Pilot Time Slot), 보호구간(GP: Guard Period), UpPTS(Uplink Pilot Time Slot)인 3가지의 필드로 구성되는 특별 서브프레임을 포함한다. 여기서, DwPTS는 단말에서의 초기 셀 탐색, 동기화 또는 채널 추정에 사용된다. UpPTS는 기지국에서의 채널 추정과 단말의 상향 전송 동기를 맞추는 데 사용된다. 보호구간은 상향링크와 하향링크 사이에 하향링크 신호의 다중경로 지연으로 인해 상향링크에서 생기는 간섭을 제거하기 위한 구간이다.
다음 표 1은 특별 프레임의 구성(DwPTS/GP/UpPTS의 길이)을 나타낸다.
[표 1]
Figure PCTKR2019016624-appb-I000001
도 2는 NR에서 사용되는 무선 프레임의 구조를 예시한다.
NR에서 상향링크(UL) 및 하향링크(DL) 전송은 프레임으로 구성된다. 무선 프레임(radio frame)은 10ms의 길이를 가지며, 2개의 5ms 하프-프레임(Half-Frame, HF)으로 정의된다. 하프-프레임은 5개의 1ms 서브프레임(Subframe, SF)으로 정의된다. 서브프레임은 하나 이상의 슬롯(slot)으로 분할되며, 서브프레임 내 슬롯 개수는 SCS(Subcarrier Spacing)에 의존한다. 각 슬롯은 CP(cyclic prefix)에 따라 12개 또는 14개의 OFDM(A) 심볼(symbol)을 포함한다. 보통 CP (normal CP)가 사용되는 경우, 각 슬롯은 14개의 심볼을 포함한다. 확장 CP (extended CP)가 사용되는 경우, 각 슬롯은 12개의 심볼을 포함한다. 여기서, 심볼은 OFDM 심볼 (혹은, CP-OFDM 심볼), SC-FDMA 심볼 (혹은, DFT-s-OFDM 심볼)을 포함할 수 있다.
표 2는 보통 CP가 사용되는 경우, SCS에 따라 슬롯 별 심볼의 개수, 프레임 별 슬롯의 개수와 서브프레임 별 슬롯의 개수가 달라지는 것을 예시한다.
[표 2]
Figure PCTKR2019016624-appb-I000002
표 3은 확장 CP가 사용되는 경우, SCS에 따라 슬롯 별 심볼의 개수, 프레임 별 슬롯의 개수와 서브프레임 별 슬롯의 개수가 달라지는 것을 예시한다.
[표 3]
Figure PCTKR2019016624-appb-I000003
NR 시스템에서는 하나의 단말(User Equipment; UE)에게 병합되는 복수의 셀들간에 OFDM(A) 뉴모놀로지(numerology)(예, SCS, CP 길이 등)가 상이하게 설정될 수 있다. 이에 따라, 동일한 개수의 심볼로 구성된 시간 자원(예, SF, 슬롯 또는 TTI)(편의상, TU(Time Unit)로 통칭)의 (절대 시간) 구간이 병합된 셀들간에 상이하게 설정될 수 있다.
도 3은 NR 프레임의 슬롯 구조를 예시한다.
슬롯은 시간 도메인에서 복수의 심볼을 포함한다. 예를 들어, 보통 CP의 경우 하나의 슬롯이 14 개의 심볼을 포함하나, 확장 CP의 경우 하나의 슬롯이 12 개의 심볼을 포함한다. 반송파는 주파수 도메인에서 복수의 부반송파(subcarrier)를 포함한다. RB(Resource Block)는 주파수 도메인에서 복수(예, 12)의 연속한 부반송파로 정의된다. BWP(Bandwidth Part)는 주파수 도메인에서 복수의 연속한 (P)RB로 정의되며, 하나의 뉴모놀로지(numerology)(예, SCS, CP 길이 등)에 대응될 수 있다. 반송파는 최대 N개(예, 5개)의 BWP를 포함할 수 있다. 데이터 통신은 활성화된 BWP를 통해서 수행되며, 하나의 단말한테는 하나의 BWP만 활성화 될 수 있다. 자원 그리드에서 각각의 요소는 자원요소(Resource Element, RE)로 지칭되며, 하나의 복소 심볼이 매핑(mapping)될 수 있다.
도 4는 자기-완비(self-contained) 슬롯의 구조를 예시한다.
NR 시스템에서 프레임은 하나의 슬롯 내에 DL 제어 채널, DL 또는 UL 데이터, UL 제어 채널 등이 모두 포함될 수 있는 자기-완비 구조를 특징으로 한다. 예를 들어, 슬롯 내의 처음 N개의 심볼은 DL 제어 채널을 전송하는데 사용되고(이하, DL 제어 영역), 슬롯 내의 마지막 M개의 심볼은 UL 제어 채널을 전송하는데 사용될 수 있다(이하, UL 제어 영역). N과 M은 각각 0 이상의 정수이다. DL 제어 영역과 UL 제어 영역의 사이에 있는 자원 영역(이하, 데이터 영역)은 DL 데이터 전송을 위해 사용되거나, UL 데이터 전송을 위해 사용될 수 있다. 일 예로, 다음의 구성을 고려할 수 있다. 각 구간은 시간 순서대로 나열되었다.
1. DL only 구성
2. UL only 구성
3. Mixed UL-DL 구성
- DL 영역 + GP(Guard Period) + UL 제어 영역
- DL 제어 영역 + GP + UL 영역
* DL 영역: (i) DL 데이터 영역, (ii) DL 제어 영역 + DL 데이터 영역
* UL 영역: (i) UL 데이터 영역, (ii) UL 데이터 영역 + UL 제어 영역
DL 제어 영역에서는 PDCCH (Physical Downlink Control Channel)가 전송될 수 있고, DL 데이터 영역에서는 PDSCH (Physical Downlink Shared Channel)가 전송될 수 있다. UL 제어 영역에서는 PUCCH (Physical Uplink Control Channel)가 전송될 수 있고, UL 데이터 영역에서는 PUSCH (Physical Uplink Shared Channel)가 전송될 수 있다. PDCCH에서는 DCI(Downlink Control Information), 예를 들어 DL 데이터 스케줄링 정보, UL 데이터 스케줄링 정보 등이 전송될 수 있다. PUCCH에서는 UCI(Uplink Control Information), 예를 들어 DL 데이터에 대한 ACK/NACK(Positive Acknowledgement/Negative Acknowledgement) 정보, CSI(Channel State Information) 정보, SR(Scheduling Request) 등이 전송될 수 있다. GP는 기지국(Base Station; BS,)과 단말이 송신 모드에서 수신 모드로 전환하는 과정 또는 수신 모드에서 송신 모드로 전환하는 과정에서 시간 갭을 제공한다. 서브프레임 내에서 DL에서 UL로 전환되는 시점의 일부 심볼이 GP로 설정될 수 있다.
MTC (Machine Type Communication)
MTC(Machine Type Communication)은 M2M (Machine-to-Machine) 또는 IoT (Internet-of-Things) 등에 적용될 수 있는 많은 처리량(throughput)을 요구하지 않는 application으로서, 3GPP(3rd Generation Partnership Project)에서 IoT 서비스의 요구 사항을 충족시키기 위해 채택된 통신 기술을 말한다.
MTC는 (i) 낮은 비용 & 낮은 복잡도(low cost & low complexity), (ii) 향상된 커버리지 (enhanced coverage), (iii) 낮은 파워 소비 (low power consumption)의 기준을 만족하도록 구현될 수 있다.
3GPP에서 MTC는 release 10부터 적용되었으며, 3GPP의 release 별로 추가된 MTC의 특징에 대해 간략히 살펴본다.
먼저, 3GPP release 10과 release 11에서 기술된 MTC는 부하 제어(load control) 방법에 관한 것이다.
부하 제어 방법은 IoT(또는 M2M) 디바이스들이 갑자기 기지국에 부하를 주는 것을 미리 방지하기 위한 것이다.
보다 구체적으로, release 10의 경우, 기지국은 부하가 발생하는 경우 접속되어 있는 IoT 디바이스들에 대한 접속을 끊음으로써 부하를 제어하는 방법에 관한 것이며, release 11의 경우, 기지국이 SIB14와 같은 브로드캐스팅을 통해 추후 접속할 것을 미리 단말에게 알려서 단말에 대한 접속을 사전에 차단하는 방법에 관한 것이다.
Release 12의 경우, 저 비용(low cost) MTC를 위한 특징이 추가되었으며, 이를 위해 UE category 0이 새롭게 정의되었다. UE category는 단말이 얼마나 많은 데이터를 통신 모뎀에서 처리할 수 있는지를 나타내는 지표이다.
즉, UE category 0의 단말은 감소된 peak data rate, 완화된(relaxed) RF 요구 사항을 가지는 Half Duplex operation과 단일의(single) 수신 안테나를 사용함으로써, 단말의 baseband 및 RF 복잡도를 줄이게 된다.
Release 13에서 eMTC(enhanced MTC)라는 기술이 소개되었으며, legacy LTE에서 지원하는 최소 주파수 대역폭인 1.08MHz에서만 동작하도록 하여 가격과 전력 소모를 더 낮출 수 있도록 하였다.
이하에서 기술되는 내용은 주로 eMTC와 관련된 특징들이나, 특별한 언급이 없는 한 MTC, eMTC, 5G(또는 NR)에 적용될 MTC에도 동일하게 적용될 수 있다. 이하에서는 설명의 편의를 위해 MTC로 통칭하여 설명하기로 한다.
따라서, 후술하는 MTC는 eMTC (enhanced MTC), LTE-M1/M2, BL (Bandwidth reduced low complexity) / CE(coverage enhanced), non-BL UE(in enhanced coverage), NR MTC, enhanced BL / CE 등과 같이 다른 용어로 지칭될 수 있다. 즉, MTC라는 용어는 향후 3GPP 표준에서 정의될 용어로 대체할 수 있다.
(1) MTC는 특정 시스템 대역폭(또는 채널 대역폭)에서만 동작한다.
특정 시스템 대역폭은 아래 표 4와 같이 legacy LTE의 6RB를 사용할 수 있으며, 표 5 내지 표 7에서 정의된 NR의 주파수 범위(frequency range) 및 SCS(subcarrier spacing)을 고려하여 정의될 수 있다. 상기 특정 시스템 대역폭은 narrowband(NB)로 표현될 수 있다. 참고로, Legacy LTE는 MTC 이외 3GPP 표준에서 기술되고 있는 부분을 의미한다. 바람직하게는, NR에서 MTC는 legacy LTE에서와 같이 아래 표 6 및 표 7의 가장 낮은 시스템 대역폭에 대응하는 RB들을 사용하여 동작할 수 있다. 또는, NR에서 MTC는 적어도 하나의 대역폭 파트(bandwidth part, BWP)에서 동작하거나 또는 BWP의 특정 대역에서 동작할 수도 있다.
[표 4]
Figure PCTKR2019016624-appb-I000004
표 5는 NR에서 정의되는 주파수 범위(frequency range; FR)를 나타낸 표이다.
[표 5]
Figure PCTKR2019016624-appb-I000005
표 6은 NR의 FR 1에서 채널 대역폭 및 SCS에 대한 최대 전송 대역폭 구성 (NRB)의 일례를 나타낸 표이다.
[표 6]
Figure PCTKR2019016624-appb-I000006
표 7은 NR의 FR 2에서 채널 대역폭 및 SCS에 대한 최대 전송 대역폭 구성 (NRB)의 일례를 나타낸 표이다.
[표 7]
Figure PCTKR2019016624-appb-I000007
(2) MTC는 반-이중 모드(half duplex mode)로 동작하며, 제한된 (또는 감소된) 최대 전송 전력을 사용한다.
(3) MTC는 legacy LTE 또는 NR의 전체 시스템 대역폭에 걸쳐서 분산되어야 하는 (legacy LTE 또는 NR에서 정의되는) 채널을 사용하지 않는다.
일례로, MTC에 사용되지 않는 legacy LTE 채널은 PCFICH, PHICH, PDCCH이다.
따라서, MTC는 위의 채널들을 모니터링할 수 없어 새로운 제어 채널인 MPDCCH(MTC PDCCH)를 정의한다.
MPDCCH는 주파수 영역에서 최대 6RB들 및 시간 영역에서 하나의 subframe에 걸쳐 있다.
MPDCCH는 EPDCCH와 유사하며, 페이징 및 랜덤 액세스를 위한 common search space를 추가 지원한다.
상기 MPDCCH는 legacy LTE에서 사용되는 E-PDCCH의 개념과 유사하다.
(4) MTC는 새롭게 정의된 DCI format을 사용하며, 일례로 DCI format 6-0A, 6-0B, 6-1A, 6-1B, 6-2 등일 수 있다.
(5) MTC는 PBCH(physical broadcast channel), PRACH(physical random access channel), M-PDCCH(MTC physical downlink control channel), PDSCH(physical downlink shared channel), PUCCH(physical uplink control channel), PUSCH(physical uplink shared channel)를 반복적으로 전송할 수 있다. 이와 같은 MTC 반복 전송은 지하실과 같은 열악한 환경에서와 같이 신호 품질 또는 전력이 매우 열악한 경우에도 MTC 채널을 디코딩할 수 있어 셀 반경 증가 및 신호 침투 효과를 가져올 수 있다. MTC는 single layer(또는 single antenna)에서 동작할 수 있는 제한된 수의 전송 모드(transmission mode, TM)만 지원하거나 또는 single layer에서 동작할 수 있는 채널 또는 참조 신호(reference signal, RS)를 지원할 수 있다. 일례로, MTC가 동작할 수 있는 전송 모드는 TM 1, 2, 6 또는 9일 수 있다.
(6) MTC의 HARQ 재전송은 적응적(adaptive), 비동기(asynchronous) 방식이고, MPDCCH에서 수신된 새로운 scheduling assignment에 기초한다.
(7) MTC에서 PDSCH 스케줄링 (DCI)과 PDSCH 전송은 서로 다른 서브프레임에서 발생한다(크로스 서브프레임 스케줄링).
(8) SIB1 디코딩을 위한 모든 자원 할당 정보 (서브 프레임, TBS(Transport Block Size), 서브 밴드 인덱스)는 MIB의 parameter에 의해 결정되며, MTC의 SIB1 디코딩을 위해 어떤 제어 채널도 사용되지 않는다.
(9) SIB2 디코딩을 위한 모든 자원 할당 정보 (서브 프레임, TBS, 서브 밴드 인덱스)는 여러(several) SIB1 parameters에 의해 결정되며, MTC의 SIB2 디코딩을 위한 어떤 제어 채널도 사용되지 않는다.
(10) MTC는 확장(extended) 페이징 (DRX) 주기(cycle)을 지원한다.
(11) MTC는 legacy LTE 또는 NR에서 사용되는 PSS(primary synchronization signal) / SSS(secondary synchronization signal) / CRS(common reference signal)를 동일하게 사용할 수 있다. NR의 경우, PSS / SSS는 SS block(또는 SS / PBCH block 또는 SSB) 단위로 전송되며, TRS(tracking RS)는 CRS와 동일한 용도로 사용될 수 있다. 즉, TRS는 cell-specific RS로서, frequency / time tracking을 위해 사용될 수 있다.
다음, MTC 동작 모드(operation mode)와 레벨(level)에 대해 살펴본다. MTC는 커버리지 향상을 위해 2개의 동작 모드(제 1 모드, 제 2 모드)와 4개의 서로 다른 level들로 분류되며, 아래 표 8과 같을 수 있다.
상기 MTC 동작 모드는 CE Mode로 지칭되며, 이 경우 제 1 모드는 CE Mode A, 제 2 모드는 CE Mode B로 지칭될 수 있다.
[표 8]
Figure PCTKR2019016624-appb-I000008
제 1 모드는 완전한 이동성 및 CSI (channel state information) 피드백이 지원되는 작은 coverage 향상을 위해 정의되어, 반복이 없거나 또는 반복 횟수가 적은 모드이다. 제 1 모드의 동작은 UE category 1의 동작 범위와 동일할 수 있다. 제 2 모드는 CSI feedback 및 제한된 이동성을 지원하는 극히 열악한 커버리지 조건의 UE에 대해 정의되며, 많은 수의 반복 전송이 정의된다. 제 2 모드는 UE category 1의 범위를 기준으로 최대 15dB의 커버리지 향상을 제공한다. MTC의 각 level은 RACH와 paging procedure에서 다르게 정의된다.
MTC 동작 모드와 각 level이 결정되는 방법에 대해 살펴본다.
MTC 동작 모드는 기지국에 의해 결정되며, 각 level은 MTC 단말에 의해 결정된다. 구체적으로, 기지국은 MTC 동작 모드에 대한 정보를 포함하는 RRC 시그널링(signaling)을 단말로 전송한다. 여기서, RRC signaling은 RRC connection setup 메시지, RRC connection reconfiguration 메시지 또는 RRC connection reestablishment 메시지 등일 수 있다. 여기서, 메시지의 용어는 정보 요소(Information Element, IE)로 표현될 수 있다.
이후, MTC 단말은 각 동작 모드 내 level을 결정하고, 결정된 level을 기지국으로 전송한다. 구체적으로, MTC 단말은 measure한 채널 품질(예: RSRP, RSRQ 또는 SINR)에 기초하여 동작 모드 내 레벨을 결정하고, 결정된 level에 대응하는 PRACH 자원 (frequency, time, preamble)을 이용하여 기지국으로 결정된 level을 알린다.
MTC의 일반적인 신호 송수신 절차를 수행하는 중에, MTC 단말은 전력 소모(power consumption)을 감소시키기 위하여 유휴 상태(idle state)(예: RRC_IDLE state) 및/또는 비활성화 상태(inactive state)(예: RRC_INACTIVE state) 상태로 전환될 수 있다. 이 경우, 유효 상태 및/또는 비활성화 상태로 전환된 MTC 단말은 DRX 방식을 이용하도록 설정될 수 있다. 일례로, 유휴 상태 및/또는 비활성화 상태로 전환된 MTC 단말은 기지국 등에 의해 설정된 DRX 사이클(DRX cycle)에 따른 특정 서브프레임(또는 프레임, 슬롯)에서만 페이징(paging)과 관련된 MPDCCH의 모니터링을 수행하도록 설정될 수 있다. 여기에서, 페이징과 관련된 MPDCCH는 P-RNTI(Paging Access-RNTI)로 스크램블링된 MPDCCH를 의미할 수 있다.
NB-IoT (Narrowband-Internet of Things)
NB-IoT는 무선 통신 시스템(예: LTE 시스템, NR 시스템 등)의 1 PRB(Physical Resource Block)에 해당하는 시스템 대역폭(system BW)을 통해 낮은 복잡도(complexity), 낮은 전력 소비(power consumption)을 지원하기 위한 시스템을 의미할 수 있다.
여기에서, NB-IoT는 NB-LTE, NB-IoT enhancement, enhanced NB-IoT, further enhanced NB-IoT, NB-NR 등과 같이 다른 용어로 지칭될 수 있다. 즉, NB-IoT는 3GPP 표준에서 정의되거나 정의될 용어로 대체될 수 있으며, 이하에서는 설명의 편의를 위하여 'NB-IoT'로 통칭하여 표현하기로 한다.
NB-IoT는 주로 machine-type communication (MTC)와 같은 장치(device)(또는 단말)를 셀룰러 시스템(cellular system)에서 지원하여 IoT(즉, 사물 인터넷)를 구현하기 위한 통신 방식으로 이용될 수도 있다. 또한, NB-IoT 시스템은 기존의 무선 통신 시스템(예: 3GPP 시스템, LTE 시스템, NR 시스템)에서 사용되는 서브캐리어 간격(subcarrier spacing, SCS) 등의 OFDM 파라미터들을 기존의 시스템과 동일한 것을 사용함으로써 NB-IoT 시스템을 위해 추가적인 대역(band)을 할당할 필요가 없다. 이 때, 기존의 시스템 대역의 1 PRB를 NB-IoT 용으로 할당함으로써, 주파수를 효율적으로 사용할 수 있는 장점이 있다. 또한, NB-IoT의 경우, 각 단말은 단일 PRB(single PRB)를 각각의 캐리어(carrier)로 인식하므로, 본 명세서에서 언급되는 PRB 및 캐리어는 동일한 의미로 해석될 수도 있다.
이하, 본 명세서에서의 NB-IoT와 관련된 프레임 구조, 물리 채널, 다중 캐리어 동작(multi carrier operation), 동작 모드(operation mode), 일반적인 신호 송수신 등은 기존의 LTE 시스템의 경우를 고려하여 설명되지만, 차세대 시스템(예: NR 시스템 등)의 경우에도 확장하여 적용될 수 있음은 물론이다. 또한, 본 명세서에서의 NB-IoT와 관련된 내용은 유사한 기술적 목적(예: 저-전력, 저-비용, 커버리지 향상 등)을 지향하는 MTC(Machine Type Communication)에 확장하여 적용될 수도 있다.
NB-IoT를 지원하는 기지국 및/또는 단말은 기존의 시스템과 별도로 설정된 물리 채널 및/또는 물리 신호를 송수신하도록 설정될 수 있다. 이하, NB-IoT에서 지원되는 물리 채널 및/또는 물리 신호와 관련된 구체적인 내용에 대해 살펴본다.
먼저, NB-IoT 시스템의 하향링크에 대해 살펴본다. NB-IoT 하향링크에는 15kHz의 서브캐리어 간격에 기반하여 OFDMA(Orthogonal Frequency Division Multiple Access) 방식이 적용될 수 있다. 이를 통해, 서브캐리어 간 직교성을 제공하여 기존의 시스템(예: LTE 시스템, NR 시스템)과의 공존(co-existence)이 효율적으로 지원될 수 있다.
NB-IoT 시스템의 물리 채널은 기존의 시스템과의 구분을 위하여 'N(Narrowband)'이 추가된 형태로 표현될 수 있다. 예를 들어, 하향링크 물리 채널은 NPBCH(Narrowband Physical Broadcast Channel), NPDCCH(Narrowband Physical Downlink Control Channel)/NEPDCCH(Narrowband Enhanced Physical Downlink Control Channel), NPDSCH(Narrowband Physical Downlink Shared Channel) 등으로 정의되며, 하향링크 물리 신호는 NPSS(Narrowband Primary Synchronization Signal), NSSS(Narrowband Secondary Synchronization Signal), NRS(Narrowband Reference Signal), NPRS(Narrowband Positioning Reference Signal), NWUS(Narrowband Wake Up Signal) 등으로 정의될 수 있다.
일반적으로, 상술한 NB-IoT의 하향링크 물리 채널 및 물리 신호는 시간영역 다중화 방식 및/또는 주파수영역 다중화 방식에 기반하여 전송되도록 설정될 수 있다.
또한, 특징적으로, NB-IoT 시스템의 하향링크 채널인 NPBCH, NPDCCH, NPDSCH 등의 경우, 커버리지 향상(coverage enhancement)을 위하여 반복 전송(repetition transmission)이 수행될 수 있다.
또한, NB-IoT는 새롭게 정의된 DCI 포맷(DCI format)을 사용하며, 일 례로 NB-IoT를 위한 DCI 포맷은 DCI format N0, DCI format N1, DCI format N2 등으로 정의될 수 있다.
다음으로, NB-IoT 시스템의 상향링크에 대해 살펴본다. NB-IoT 상향링크에는 15kHz 또는 3.75kHz의 서브캐리어 간격에 기반하여 SC-FDMA(Single Carrier Frequency Divison Multiple Access) 방식이 적용될 수 있다. NB-IoT의 상향링크에서는 다중-톤(multi-tone) 전송 및 단일-톤(single-tone) 전송이 지원될 수 있다. 일례로, 다중-톤 전송은 15kHz의 서브캐리어 간격에서만 지원되며, 단일-톤 전송은 15kHz 및 3.75kHz의 서브캐리어 간격에 대해 지원될 수도 있다.
하향링크 부분에서 언급한 것과 같이, NB-IoT 시스템의 물리 채널은 기존의 시스템과의 구분을 위하여 'N(Narrowband)'이 추가된 형태로 표현될 수 있다. 예를 들어, 상향링크 물리 채널은 NPRACH(Narrowband Physical Random Access Channel) 및 NPUSCH(Narrowband Physical Uplink Shared Channel) 등으로 정의되고, 상향링크 물리 신호는 NDMRS(Narrowband Demodulation Reference Signal) 등으로 정의될 수 있다.
여기에서, NPUSCH는 NPUSCH 포맷 1과 NPUSCH 포맷 2 등으로 구성될 수 있다. 일례로, NPUSCH 포맷 1은 UL-SCH 전송(또는 운반)을 위해 이용되며, NPUSCH 포맷 2는 HARQ ACK 시그널링 등과 같은 상향링크 제어 정보 전송을 위해 이용될 수 있다.
또한, 특징적으로, NB-IoT 시스템의 하향링크 채널인 NPRACH 등의 경우, 커버리지 향상(coverage enhancement)을 위하여 반복 전송(repetition transmission)이 수행될 수 있다. 이 경우, 반복 전송은 주파수 호핑(frequency hopping)이 적용되어 수행될 수도 있다.
다음으로, NB-IoT의 동작 모드에 대해 살펴본다. NB-IoT 시스템에서는 3개의 동작 모드들이 지원될 수 있다. 도 5는 NB-IoT 시스템에서 지원되는 동작 모드들의 일 예를 나타낸다. 본 명세서에서는 NB-IoT의 동작 모드가 LTE 대역에 기반하여 설명되지만, 이는 설명의 편의를 위한 것일 뿐, 다른 시스템의 대역(예: NR 시스템 대역)에 대해서도 확장되어 적용될 수 있음은 물론이다.
구체적으로, 도 5(a)는 인-밴드(In-band) 시스템의 일례를 나타내며, 도 5(b)는 가드-밴드(Guard-band) 시스템의 일례를 나타내며, 도 5(c)는 독립형(Stand-alone) 시스템의 일례를 나타낸다. 이 때, 인-밴드 시스템(In-band system)은 인-밴드 모드(In-band mode)로, 가드-밴드 시스템(Guard-band system)은 가드-밴드 모드(Guard-band mode)로, 독립형 시스템(Stand-alone system)은 독립형 모드(Stand-alone mode)로 표현될 수 있다.
In-band 시스템은 (legacy) LTE 대역 내 특정 1 RB(즉, PRB)를 NB-IoT를 위해 사용하는 시스템 또는 모드를 의미할 수 있다. In-band 시스템은 LTE 시스템 캐리어(carrier)의 일부 자원 블록을 할당하여 운용될 수 있다.
Guard-band 시스템은 (legacy) LTE 밴드의 Guard-band를 위해 비워놓은(reserved) 공간에 NB-IoT를 사용하는 시스템 또는 모드를 의미할 수 있다. Guard-band 시스템은 LTE 시스템에서 자원 블록으로 사용되지 않는 LTE 캐리어의 Guard-band를 할당하여 운용될 수 있다. 일례로, (legacy) LTE 대역은 각 LTE 대역의 마지막에 최소 100kHz의 Guard-band를 가지도록 설정될 수 있다. 200kHz를 이용하기 위해서는, 2개의 비-연속적인(non-contiguous) Guard-band들이 이용될 수 있다.
상술한 것과 같이, In-band 시스템 및 Guard-band 시스템은 (legacy) LTE 대역 내에 NB-IoT가 공존하는 구조에서 운용될 수 있다.
이에 반해, standalone 시스템은 (legacy) LTE 대역으로부터 독립적으로 구성된 시스템 또는 모드를 의미할 수 있다. standalone 시스템은 GERAN(GSM EDGE Radio Access Network)에서 사용되는 주파수 대역(예: 향후 재할당된 GSM 캐리어)을 별도로 할당하여 운용될 수 있다.
상술한 3개의 동작 모드들은 각각 독립적으로 운용되거나, 둘 이상의 동작 모드들이 조합되어 운용될 수도 있다.
NB-IoT의 일반적인 신호 송수신 절차를 수행하는 중에, NB-IoT 단말은 전력 소모(power consumption)을 감소시키기 위하여 유휴 상태(idle state)(예: RRC_IDLE state) 및/또는 비활성화 상태(inactive state)(예: RRC_INACTIVE state) 상태로 전환될 수 있다. 이 경우, 유효 상태 및/또는 비활성화 상태로 전환된 NB-IoT 단말은 DRX 방식을 이용하도록 설정될 수 있다. 일례로, 유휴 상태 및/또는 비활성화 상태로 전환된 NB-IoT 단말은 기지국 등에 의해 설정된 DRX 사이클(DRX cycle)에 따른 특정 서브프레임(또는 프레임, 슬롯)에서만 페이징(paging)과 관련된 NPDCCH의 모니터링을 수행하도록 설정될 수 있다. 여기에서, 페이징과 관련된 NPDCCH는 P-RNTI(Paging Access-RNTI)로 스크램블링된 NPDCCH를 의미할 수 있다.
랜덤 접속(Random Access, RA) 과정
다음으로 랜덤 접속 과정에 대해 설명한다. 랜덤 접속 과정은 RACH(Random Access Channel) 과정으로도 지칭된다. 랜덤 접속 과정은 초기 접속, 상향링크 동기 조정, 자원 할당, 핸드오버, 무선링크 실패 이후 무선링크 재형성, 위치 측정 등의 용도로 다양하게 사용된다. 랜덤 접속 과정은 경쟁-기반(contention-based) 과정과, 전용(dedicated)(즉, 비-경쟁-기반) 과정으로 분류된다. 경쟁-기반 랜덤 접속 과정은 초기 접속을 포함하여 일반적으로 사용되며, 전용 랜덤 접속 과정은 핸드오버, 하향링크 데이터가 도달한 경우, 위치 측정의 경우에 상향링크 동기를 재설정하는 경우 등에 제한적으로 사용된다. 경쟁-기반 랜덤 접속 과정에서 단말은 RACH 프리앰블 시퀀스를 랜덤하게 선택한다. 따라서, 복수의 단말이 동시에 동일한 RACH 프리앰블 시퀀스를 전송하는 것이 가능하며, 이로 인해 이후 경쟁 해소 과정이 필요하다. 반면, 전용 랜덤 접속 과정에서 단말은 기지국이 해당 단말에게 유일하게 할당한 RACH 프리앰블 시퀀스를 사용한다. 따라서, 다른 단말과의 충돌 없이 랜덤 접속 과정을 수행할 수 있다.
도 6은 랜덤 접속 과정을 나타낸다. 도 6(a)는 경쟁-기반 랜덤 접속 과정을 나타내고, 도 6(b)는 전용 랜덤 접속 과정을 예시한다.
도 6(a)를 참조하면, 경쟁-기반 랜덤 접속 과정은 다음의 4 단계를 포함한다. 이하, 단계 1~4에서 전송되는 메시지는 각각 메시지(Msg) 1~4로 지칭될 수 있다.
-단계 1: 단말은 PRACH를 통해 RACH 프리앰블을 전송한다.
-단계 2: 단말은 기지국으로부터 DL-SCH를 통해 랜덤 접속 응답(Random Access Response, RAR)을 수신한다.
-단계 3: 단말은 UL-SCH를 통해 Layer 2 / Layer 3 메시지를 기지국으로 전송한다.
-단계 4: 단말은 DL-SCH를 통해 경쟁 해소(contention resolution) 메시지를 기지국으로부터 수신한다.
단말은 시스템 정보를 통해 기지국으로부터 랜덤 접속에 관한 정보를 수신할 수 있다.
랜덤 접속이 필요하면, 단말은 단계 1과 같이 RACH 프리앰블을 기지국으로 전송한다. 기지국은, 랜덤 접속 프리앰블이 전송된 시간/주파수 자원(RACH Occasion; RO) 및 랜덤 접속 프리앰블 인덱스(Preamble Index, PI)를 통해, 각각의 랜덤 접속 프리앰블들을 구별할 수 있다.
기지국이 단말로부터 랜덤 접속 프리앰블을 수신하면, 기지국은 단계 2와 같이 랜덤 접속 응답(Random Access Response, RAR) 메시지를 단말에게 전송한다. 랜덤 접속 응답 메시지의 수신을 위해, 단말은 미리 설정된 시간 윈도우(예를 들어, ra-ResponseWindow) 내에서, 랜덤 접속 응답 메시지에 대한 스케줄링 정보를 포함하는, RA-RNTI(Random Access-RNTI)로 CRC 마스킹된 L1/L2 제어채널(PDCCH)을 모니터링한다. RA-RNTI로 마스킹된 PDCCH는 공통 검색 공간(common search space)를 통해서만 전송될 수 있다. RA-RNTI로 마스킹된 스케줄링 신호를 수신한 경우, 단말은 상기 스케줄링 정보가 지시하는 PDSCH로부터 랜덤 접속 응답 메시지를 수신할 수 있다. 그 후, 단말은 랜덤 접속 응답 메시지에 자신에게 지시된 랜덤 접속 응답 정보가 있는지 확인한다. 자신에게 지시된 랜덤 접속 응답 정보가 존재하는지 여부는 단말이 전송한 프리앰블에 대한 RAPID(Random Access preamble ID)가 존재하는지 여부로 확인될 수 있다. 단말이 전송한 프리앰블의 인덱스와 RAPID는 동일할 수 있다. 랜덤 접속 응답 정보는, 대응하는 랜덤 접속 프리앰블 인덱스, UL 동기화를 위한 타이밍 오프셋 정보(예, Timing Advance Command, TAC), 메시지 3 전송을 위한 UL 스케줄링 정보(예, UL 그랜트) 및 단말 임시 식별 정보(예, Temporary-C-RNTI, TC-RNTI)를 포함한다.
랜덤 접속 응답 정보를 수신한 단말은, 단계 3과 같이, UL 스케줄링 정보 및 타이밍 오프셋 값에 따라 PUSCH를 통해 UL-SCH(Shared Channel) 데이터(메시지 3)를 전송한다. 메시지 3에는, 단말의 ID (또는 단말의 global ID)가 포함될 수 있다. 또는 메시지 3에는, 초기 접속을 위한 RRC 연결 요청 관련 정보(예를 들어, RRCSetupRequest 메시지)가 포함될 수 있다. 또한 메시지 3에는, 단말이 전송 가능한 데이터(data available for transmission)의 양에 대한 버퍼 상태 보고(Buffer Status Report; BSR)가 포함될 수 있다.
UL-SCH 데이터 수신 후, 단계 4와 같이, 기지국은 경쟁 해소(contention resolution) 메시지(메시지 4)를 단말에게 전송한다. 단말이 경쟁 해소 메시지를 수신하고 경쟁이 해소에 성공하면, TC-RNTI는 C-RNTI로 변경된다. 메시지 4에는, 단말의 ID 및/또는 RRC 연결 관련 정보(예를 들어, RRCSetup 메시지)가 포함될 수 있다. 메시지 3를 통해 전송한 정보와 메시지 4를 통해 수신한 정보가 일치하지 않거나, 일정 시간 동안 메시지 4를 수신하지 못하면, 단말은 경쟁 해소가 실패한 것으로 보고 메시지 3를 재전송할 수 있다.
도 6(b)를 참조하면, 전용 랜덤 접속 과정은 다음의 3 단계를 포함한다. 이하, 단계 0~2에서 전송되는 메시지는 각각 메시지(Msg) 0~2로 지칭될 수 있다. 전용 랜덤 접속 과정은 기지국이 RACH 프리앰블 전송을 명령하는 용도의 PDCCH(이하, PDCCH 오더(order))를 이용하여 트리거링 될 수 있다.
-단계 0: 기지국은 전용 시그널링을 통한 RACH 프리앰블을 단말에 할당한다.
-단계 1: 단말은 PRACH를 통해 RACH 프리앰블을 전송한다.
-단계 2: 단말은 기지국으로부터 DL-SCH를 통해 랜덤 접속 응답(Random Access Response, RAR)을 수신한다.
전용 랜덤 접속 과정의 단계 1~2의 동작은 경쟁 기반 랜덤 접속 과정의 단계1~2와 동일할 수 있다.
NR에서는 비-경쟁 기반 랜덤 접속 과정을 PDCCH 명령(order)으로 개시하기 위해 DCI 포맷 1_0가 사용된다. DCI 포맷 1_0는 하나의 DL 셀에서 PDSCH를 스케줄링 하는데 사용된다. 한편, DCI 포맷 1_0의 CRC(Cyclic Redundancy Check)가 C-RNTI로 스크램블 되고, "Frequency domain resource assignment" 필드의 비트 값이 모두 1인 경우, DCI 포맷 1_0는 랜덤 접속 과정을 지시하는 PDCCH 명령으로 사용된다. 이 경우, DCI 포맷 1_0의 필드는 다음과 같이 설정된다.
- RA 프리앰블 인덱스: 6비트
- UL/SUL(Supplementary UL) 지시자: 1비트. RA 프리앰블 인덱스의 비트 값이 모두 0이 아니면서 단말에 대해 셀 내에 SUL이 설정된 경우, 셀 내에서 PRACH가 전송된 UL 반송파를 지시한다. 그 외의 경우 미사용 된다(reserved).
- SSB (Synchronization Signal/Physical Broadcast Channel) 인덱스: 6비트. RA 프리앰블 인덱스의 비트 값이 모두 0가 아닌 경우, PRACH 전송을 위한 RACH 기회(occasion)를 결정하는데 사용되는 SSB를 지시한다. 그 외의 경우 미사용 된다(reserved).
- PRACH 마스크 인덱스: 4비트. RA 프리앰블 인덱스의 비트 값이 모두 0가 아닌 경우, SSB 인덱스에 의해 지시되는 SSB와 연관된 RACH 기회를 지시한다. 그 외의 경우 미사용 된다(reserved).
- 미사용(reserved): 10비트
DCI 포맷 1_0이 PDCCH 명령에 해당하지 않는 경우, DCI 포맷 1_0은 PDSCH를 스케줄링 하는데 사용되는 필드로 구성된다(예, Time domain resource assignment, MCS(Modulation and Coding Scheme), HARQ 프로세스 번호, PDSCH-to-HARQ_feedback timing indicator 등).
MTC 단말은 랜덤 액세스 절차(random access procedure)을 수행할 수 있다. RACH 절차와 관련된 기본적인 설정은 SIB2에 의해 전송된다. 또한, SIB2는 페이징과 관련된 파라미터들을 포함한다. 페이징 기회(Paging Occasion, PO)는 MPCCH 상에서 P-RNTI가 전송될 수 있는 서브프레임이다. P-RNTI PDCCH가 반복적으로 전송될 때, PO는 MPDCCH 반복의 시작 서브 프레임을 지칭한다. 페이징 프레임 (PF)은 하나의 무선 프레임으로, 하나 또는 다수의 PO들을 포함할 수 있다. DRX가 사용될 때, MTC 단말은 DRX cycle 당 하나의 PO만을 모니터한다. 페이징 NarrowBand (PNB)는 하나의 narrowband로, MTC 단말이 페이징 메시지 수신을 수행한다.
이를 위해, MTC 단말은 물리 랜덤 액세스 채널(PRACH: physical random access channel)을 통해 프리앰블을 전송하고, MPDCCH 및 이에 대응하는 PDSCH을 통해 프리앰블에 대한 응답 메시지(RAR)를 수신할 수 있다. 경쟁 기반 랜덤 액세스의 경우, MTC 단말은 추가적인 PRACH 신호의 전송 및 MPDCCH 신호 및 이에 대응하는 PDSCH 신호의 수신과 같은 충돌 해결 절차(contention resolution procedure)를 수행할 수 있다. MTC에서 RACH 절차에서 전송되는 신호 및/또는 메시지들 (Msg 1, Msg 2, Msg 3, Msg 4)는 반복적으로 전송될 수 있으며, 이러한 반복 패턴은 CE 레벨에 따라 다르게 설정된다. Msg 1은 PRACH 프리앰블을 의미하며, Msg 2는 RAR(random access response)를 의미하며, Msg 3은 RAR에 대한 MTC 단말의 UL 전송을 의미하며, Msg 4는 Msg 3에 대한 기지국의 DL 전송을 의미할 수 있다.
랜덤 액세스에 대해, 서로 다른 PRACH 자원들 및 서로 다른 CE 레벨들에 대한 시그널링이 지원된다. 이는 유사한 경로 감쇠(path loss)를 경험하는 UE들을 함께 그룹핑함으로써, PRACH에 대한 near-far 효과의 동일한 제어를 제공한다. 최대 4개까지의 서로 다른 PRACH 자원들이 MTC 단말로 시그널링될 수 있다.
NB-IoT 단말은 기지국에 접속을 완료하기 위해 임의 접속 과정(Random Access Procedure)을 수행할 수 있다.
구체적으로, NB-IoT 단말은 NPRACH를 통해 프리앰블(preamble)을 기지국으로 전송할 수 있으며, 상술한 바와 같이 NPRACH는 커버리지 향상 등을 위하여 주파수 호핑 등에 기반하여 반복 전송되도록 설정될 수 있다. 다시 말해, 기지국은 NB-IoT 단말로부터 NPRACH를 통해 프리앰블을 (반복적으로) 수신할 수 있다.
이후, NB-IoT 단말은 NPDCCH 및 이에 대응하는 NPDSCH를 통해 프리앰블에 대한 RAR(Random Access Response)을 기지국으로부터 수신할 수 있다. 다시 말해, 기지국은 NPDCCH 및 이에 대응하는 NPDSCH를 통해 프리앰블에 대한 RAR(Random Access Response)를 NB-IoT 단말로 전송할 수 있다.
이후, NB-IoT 단말은 RAR 내의 스케줄링 정보를 이용하여 NPUSCH를 기지국으로 전송하고, NPDCCH 및 이에 대응하는 NPDSCH과 같은 충돌 해결 절차(Contention Resolution Procedure)를 수행할 수 있다. 다시 말해, 기지국은 NB-IoT RAR 내의 스케줄링 정보를 이용하여 NPUSCH를 단말로부터 수신하고, 상기 충돌 해결 절차를 수행할 수 있다.
EDT (Early data transmission)
MTC와 NB-IoT의 경우에 RRC_IDLE 상태에 있는 단말이 기지국과 RRC 연결을 맺지 않고 유휴 상태를 유지하면서도 camp-on 중인 기지국과 데이터를 송수신할 수 있다. 이 방식을 EDT(Early data transmission)이라고 부른다. EDT 절차에서 단말은 camp-on 중인 기지국에게 데이터를 전송하기 위해서 EDT 용으로 별도로 할당된 랜덤 접속 프리앰블(random access preamble) 자원을 통해서 랜덤 접속 프리앰블을 전송한다. EDT용 랜덤 접속 프리앰블을 수신한 기지국은 Msg2 전송을 통해서 해당 프리앰블을 전송한 UE에게 EDT 데이터 전송 절차 허용 여부를 알려주며, 기지국이 EDT 데이터 전송을 허용한 경우에 해당 단말은 Msg3를 통해서 자신의 글로벌(global) ID와 함께 사용자 데이터 혹은 버퍼 상태를 알려주게 된다. 이후 기지국은 Msg4를 통해서 단말에게 데이터 수신 성공 여부 및 단말에게 전송할 사용자 데이터를 전송할 수 있으며, 기지국과 단말 사이의 데이터 송수신은 기지국의 컨트롤에 따라서는 Msg4 이후에도 이어질 수 있다. 데이터 송수신이 끝나면 단말은 기지국과 RRC 연결을 맺지 않고 EDT 절차를 끝내게 된다.
1. IoT 모드
이하에서는 본원 명세서에 사용되는 용어로서 IoT 모드들에 대해 설명한다.
- IoT mode: 특정 조합의 무선 환경/특성 및/또는 단말 특성을 지원하는 통신 방식 혹은 통신 동작 모드를 의미한다. 예를 들어, IoT 모드는 결합 손실(coupling loss) 보상 수준, UE 복잡도(UE의 동작 대역폭 등), 배터리 소모 수준 등에 서로 다른 수준의 조합을 지원하는 통신 방식 혹은 통신 동작 모드일 수 있다. 구체적인 예로서, 3GPP LTE 및/또는 NR 시스템에서의 일반적인 non-BL 동작, non-BL CE mode 동작(CEmodeA/B), eMTC 동작, NB-IoT 동작 등이 서로 다른 IoT 모드로 정의될 수 있다. 이하에서 단말이 특정 IoT 모드로 동작한다 함은, 단말이 기지국과 통신을 수행하는 과정(예, 페이징, RACH, 데이터 송수신 등)에 있어서, i) 해당 IoT 모드에서 지원하는 대역폭이 사용됨 ii) 해당 IoT 모드에 특화된 (N/M)PDCCH/PDSCH/PUSCH/PUCCH/PRACH 구조가 사용됨 및/또는 iii) 해당 해당 IoT 모드에 특화된 채널의 반복(repetition) 횟수(CE 수준)에 대응하는 물리 채널들이 송수신됨을 의미한다. 편의상, 설명을 용이하게 하기 위해, 특정 조합의 무선 환경/특성 및/또는 단말 특성을 지원하는 통신 방식 혹은 통신 동작 모드를 IoT 모드라고 지칭하였지만, 본 명세서에서 IoT 모드는, 넓은 의미로서 IoT(저전력, 저복잡도 등)로 동작하는 방식이 아닌 경우, 즉 일반적인 카테고리(Category; Cat)의 단말로 동작하는 통신 방식 혹은 통신 동작 모드도 포함할 수 있다. 예를 들어, 통신 시스템에 따라, 본 명세서에서 넓은 의미로 사용되는 IoT 모드는, 3GPP 통신 시스템 상의 Non-IoT IoT 모드, IoT 모드에 포함되는 복수의 모드들을 포괄하여 지칭하는 것으로 해석될 수 있다. 3GPP 통신 시스템 상의 IoT 모드는, 좁은 의미의 IoT 모드로 지칭될 수도 있다. 이런 취지로, 본 명세서에서 IoT 모드는 단말 카테고리(UE category) 및 좁은 의미의 IoT 모드(혹은, IoT 모드에 포함되는 복수의 모드들)의 집합으로 이해될 수 있다. 또한, 본 명세서에서 IoT 모드는 단말 카테고리, 넓은 의미의 IoT 모드, 좁은 의미의 IoT 모드(혹은, IoT mode 안의 복수의 모드들)와 혼용될 수 있다.
- non-BL mode: LTE 시스템에서 일반적인 카테고리의 단말(e.g. Category 0 혹은 category 1 이상, 20MHz 대역폭 지원)이 동작하기 위한 모드
- non-BL CE mode: LTE 시스템에서 대역폭 제한이 없는 단말(e.g., 20MHz 대역폭 지원)이 더 큰 결합 손실을 보상하기 위하여 eMTC의 CE mode A/B에서와 같이 MPDCCH를 수신하고 큰 반복 및/또는 CE를 지원하도록 동작하는 모드
- eMTC mode: LTE 시스템의 eMTC 표준을 따르는 모드
- NB-IoT mode: LTE 시스템의 NB-IoT 표준을 따르는 모드
이상에서 명시적으로 정의된 IoT 모드들 이외에도, 특정 대역폭, 채널 및/또는 채널 반복 횟수(CE 수준)가 사용되는 IoT 모드가 정의될 수 있다. 명시적으로 정의된 IoT 모드들 및 명시적으로 정의된 IoT 모드들 이외의 IoT 모드들은, 예를 들어 제1 모드, 제2 모드 등 넘버링(numbering)을 통해 지칭될 수 있다. 또는, 명시적으로 정의된 IoT 모드들 및 명시적으로 정의된 IoT 모드들 이외의 IoT 모드들은, 예를 들어 제1 IoT 모드, 제2 IoT 모드 등으로 지칭될 수 있다.
또한, 본 명세서에서 정의된 모드들 중 LTE 시스템의 관련 표준을 따르는 것으로 설명된 모드는, NR 시스템에서 대역폭, 채널 및/또는 반복 횟수(CE 수준)가 동일하게 지원되는 모드들로 대체될 수 있다. 예를 들어, 본원에서 LTE 시스템의 관련 표준을 따르는 것으로 설명된 모드는, NR 시스템에서는 서로 다른 NR 단말 능력 (UE capability) 관련 표준, 혹은 NR-light 표준을 따르는 모드로 대체되어 이해될 수 있다.
2. IoT 모드들의 전환
최근 기존의 사람 대 사람 통신에 비하여 다양한 무선 통신 서비스의 요구가 증가하면서 IoT(Internet of Things)로 광범위하게 일컬어지는 기계 대 사람, 기계 대 기계 등의 통신을 효율적으로 지원하기 위한 다양한 무선 통신 방식들이 개발되고 있다. 셀룰라 무선 통신 방식의 대표적인 예로서 3GPP LTE 시스템을 들 수 있으며, LTE 시스템에서는 기본적인 통신 방식(기존의 Cat0 혹은 Cat1이상의 UE category를 통해서 최대 20MHz 대역폭에서의 통신을 지원하는 방식) 외에도 저복잡도, 저전력, 큰 결합 손실의 보상을 위한 eMTC, 그보다 한 층 더한 저복잡도, 저전력, 큰 결합 손실의 보상을 위한 NB-IoT, 그리고, 기존 카테고리(category)의 단말이 큰 결합 손실의 보상을 위하여 eMTC의 CEmodeA/B로 동작하는 모드 등을 지원하고 있다. 본 명세서에서는, 1. IoT 모드에서 정의된 바에 기초하여, 각각의 동작 방식이non-BL 모드, eMTC 모드, NB-IoT 모드, non-BL CE 모드로 지칭된다. 본 명세서에서는 편의상 LTE 시스템을 기준으로 IoT 모드를 설명하고 있지만, 그 외에 3GPP NR 혹은 3GPP 이외의 시스템에서도 서로 다른 수준의 전력 소모(e.g.wake-up/sleeping cycle), 서로 다른 수준의 UE 복잡도(e.g., 지원 대역폭), 서로 다른 수준의 결합 손실 보상(e.g., 전송 반복 횟수)을 지원하는 동작 방식을 하나의 단말이 지원하는 경우, 각 동작 방식을 IoT 모드로 생각할 수 있다.
하나의 장치에 대해서도 상황이나 서비스에 따라서 서로 다른 데이터 전송율, 결합 손실, 전력 소모가 적합할 수 있으므로, 하나의 장치가 복수의 IoT 모드를 지원하면서, 서로 다른 IoT 모드를 전환하고 전환된 IoT 모드에 기반한 동작을 수행하는 것이 효율적일 수 있다. 예로서, 지하 주차장에 주차 대기 상태인 경우 단말은, 저전력, 큰 결합 손실 보상이 가능한 NB-IoT 모드로 기지국과 최소한의 통신만을 수행할 수 있다. 차량에 운전자가 탄 경우 단말은, non-BL모드로 사용자 데이터 서비스를 원활히 하기 위한 대용량 데이터 통신을 수행하는 것이 효율적일 수 있다. 단말은 차량 내에 위치하거나 차량 자체일 수 있다. 본 명세서를 통해, 예를 들어 단말이 NB-IoT 모드와 non-BL 모드를 모두 지원하면서 두 모드 사이를 전환하는 시나리오가 구현될 수 있다. 두 모드를 지원하는 하드웨어는, 하나의 통합 칩, 혹은 하나의 디바이스에 장착된 두 개의 칩을 통해서 구현될 수 있다. 또한 두 모드를 지원하는 하드웨어는 각각 물리적으로 분리된 디바이스들을 포함하고, 디바이스들은 차량 안의 서로 다른 위치에 장착된 상태에서, 디바이스들 간 IoT 모드 전환을 위한 통신 선로가 연결된 상태일 수 있다.
현재 LTE 시스템에서는 복수의 서로 다른 IoT 모드들을 지원하는 단말이, 한 IoT 모드에서 다른 IoT 모드로 동작을 바꾸려면, 셀과의 연결을 끊고 새로 접속하거나 셀 간 핸드오버(handover)에 상응하는 절차를 거침으로서 상당히 큰 지연과 데이터 손실을 감수해야 한다. 이러한 지연과 데이터 손실을 최소화하는 것이 사용자의 끊김 없는 통신을 위해서 필요할 수 있다. 특히 큰 결합 손실을 보상하기 위한 IoT 모드나 eMTC 모드 동작에서, 단말의 기지국에 대한 초기 접속에 필요한 지연이 수백 msec에서 수십 sec 이상까지도 걸릴 수 있는 것을 감안할 때, 다양한 서비스 변화에 따른 복수의 IoT 모드를 지원하는 단말의 IoT 모드 전환에 필요한 지연을 줄이는 것은 매우 중요할 수 있다.
본 명세서에서 제안하는 IoT 모드 전환 방식들에서, 기지국은 복수의 IoT 모드들을 지원하는 하나의 단말에 대하여, 단일 구분자(ID)를 알고 있다고 가정될 수 있다. 또는, 기지국은 복수의 IoT 모드들을 지원하는 하나의 단말에 대하여, 각 IoT 모드들 별로 서로 다른 ID가 등록되어 있더라도 해당 ID들이 동일 단말에 속하는 ID임을 알고 있다고 가정될 수 있다. 또는, 단말은 복수의 IoT 모드들을 하나의 ID만 사용하여 전환할 수도 있다. ID는, 예를 들어 TMSI/IMSI(Temporary Mobile Subscriber Identity/International Mobile Subscriber Identity)와 같은 단말의 글로벌(global) ID일 수 있다. 또한 ID는, 복수의 IoT 모드들을 지원하는 장치(예를 들어, 단말)에게 특정 네트워크 영역 내에서 고유하게 주어지는 ID일 수 있다. 특정 단말이 복수의 글로벌 ID들을 사용함을 알지 못하는 기지국은, IoT 모드의 수만큼 페이징 메시지들을 전송해야 할 수 있다. 기지국이 하나의 단말이 복수의 ID를 사용함을 알고 있는 경우 및/또는 단말이 하나의 글로벌 ID를 사용하는 경우에는, 기지국이 단말에게 하나의 페이징 메시지만 전송되도록 하여 시그널링 오버헤드를 감소시킬 수 있다.
본 명세서는 편의상 3GPP 표준 상에 기 정의된 모드들 간의 모드 전환 위주로 설명되어 있지만, 본 명세서의 설명들은 명시적으로 정의된 IoT 모드들 및/또는 명시적으로 정의된 IoT 모드가 아닌 IoT 모드들 간의 모드 전환으로 대체될 수 있다. 예를 들어, 본 명세서를 통해 설명된 동작을 통해 특정 제1 IoT 모드가, 제1 IoT 모드와는 다른 제2 IoT 모드로 전환될 수 있다.
(1) RRC_CONNECTED 상태로부터 RRC_IDLE 상태로 전환되는 경우와 관련된 IoT 모드 전환
본 명세서의 단말은, 차량에 장착된 단말일 수 있다. 또한, 본 명세서의 단말은, 도 15를 통해 설명된 바와 같이 자율 주행 차량으로 대체될 수 있다.
예를 들어서, 단말이 장착된 차량(또는 자율 주행 차량)이 주차 상태와 같이 기지국과의 대용량 통신이 필요 없는 상태가 될 경우, 단말의 전력 소모를 최소화하는 것이 단말 동작에 유리할 수 있다. 혹은 대기 모드에의 주변 환경이 지하 주차장과 같이 결합 손실이 큰 환경으로 변화할 경우에 대비해서, 단말의 IoT 모드를 보다 큰 결합 손실의 발생을 보상할 수 있는 방식의 IoT 모드로 전환하는 것이 단말 동작에 유리할 수 있다. 구체적인 예로, 차량과 관련된 단말과 같이 이동 가능한 단말이, RRC 연결 해제 이후 지하 주차장 등 넓은 커버리지의 지원이 필요한 장소로 이동할 수 있다. RRC 연결이 해제된 단말은 커버리지를 재추적해야 할 수 있고, 커버리지 변경을 위한 재추적 과정은 추가적인 데이터 송수신, 단말 및 네트워크의 처리 과정(e.g. 랜덤 접속 과정의 재수행 및/또는 단말 글로벌 ID의 전환 등)이 요구되므로, 이에 소모되는 자원 낭비 및 지연 방지를 위해 RRC_IDLE 상태로의 전환과 관련하여 IoT 모드를 전환하는 것이 단말 및 네트워크 동작에 유리할 수 있다. 예로서 non-BL 모드로 RRC 연결(connection)을 맺어서 통신하던 단말이 RRC_IDLE 상태로 전환될 때와 동시에 또는 단말이 RRC_IDLE 상태로 전환을 지시하는 RRC 연결 해제 메시지를 수신한 때로부터 일정 시점 이내에, 단말의 IoT 모드는 non-BL CE 모드, eMTC 모드 혹은 NB-IoT 모드로 전환될 수 있다. 또 다른 예로서 eMTC 모드로 RRC 연결을 맺어서 통신하던 단말이 RRC_IDLE 상태로 전환될 때와 동시에 또는 단말이 RRC_IDLE 상태로 전환을 지시하는 RRC 연결 해제 메시지를 수신한 때로부터 일정 시점 이내에, 단말의 IoT 모드는 NB-IoT 모드로 전환될 수 있다. 본 명세서에서, 단말의 IoT 모드가 전환되는 경우, 전환되기 전의 IoT 모드는 소스 IoT 모드(source IoT mode), 전환된 이후의 IoT 모드는 타겟 IoT 모드(target IoT mode)로 지칭될 수 있다. 단말이 RRC_CONNECTED 상태에서 RRC_IDLE 상태로 전환되는 경우와 관련하여 IoT 모드도 전환되는 경우의 구체적인 예시는, 방식 (1-1) 및/또는 방식 (1-2)와 같을 수 있다.
방식(1-1) 기지국이 RRC_CONNECTED 상태의 단말에게 RRC 연결 해제(connection release)를 지시하면서 IoT 모드 전환을 함께 지시
도 7(a)는 기지국이 RRC_CONNECTED 상태의 단말에게 RRC 연결 해제를 지시하면서 IoT 모드를 함께 지시하는 경우 단말과 기지국의 동작을, 도 7(b)는 기지국이 RRC_CONNECTED 상태의 단말에게 RRC 연결 해제를 지시하면서 IoT 모드를 함께 지시하는 경우 단말 동작을 도시한다.
기지국이 단말에게 RRC 연결 해제 메시지를 전송할 때, RRC 연결 해제 메시지와 함께, 단말이 RRC_IDLE 상태(state)에서 페이징(paging)을 모니터링하기 위한 IoT 모드로의 전환 지시가 전송될 수 있다. 페이징을 모니터링하기 위한 IoT 모드로의 전환 지시는, 타겟 IoT 모드의 지시를 포함할 수 있다. 예로서 소스 IoT 모드가 non-BL 모드인 단말에게, 타겟 IoT 모드로 non-BL CE 모드, eMTC 모드, 혹은 NB-IoT 모드가 지시될 수 있다.
예를 들어서 네트워크는 단말의 버퍼 상태, 서비스 상태 및/또는 위치 정보 등에 대한 정보를 기반으로, 해당 단말이 대기 모드로 전환하는 것이 효율적임을 판단할 수 있다. 단말이 대기 모드로 전환하는 것이 효율적이라고 판단한 네트워크는, 기지국에게 해당 단말을 RRC_IDLE 상태로 전환할 것을 지시할 수 있다. 이에 따라서 기지국은 해당 단말에게 RRC 연결 해제를 지시할 수 있다.
기지국은, 단말이 해당 타겟 IoT 모드에서 페이징을 수신하기 위하여 (N/M)PDCCH/PDSCH 수신에 적용할 반복 횟수 및/또는 CE (Coverage Enhancement) 수준 등 타겟 IoT 모드에서의 동작에 필요한 파라미터들을 단말에게 알려줄 수 있다. 타겟 IoT 모드에서의 동작에 필요한 파라미터들은, RRC 연결 해제 메시지 전송 전에 미리 RRC 설정(configuration) 메시지를 통해서 단말에 설정되어 있을 수 있다. 타겟 IoT 모드에서의 동작에 필요한 파라미터들은, RRC 연결 해제 메시지를 통해 단말에 설정될 수도 있다. RRC 설정 메시지를 기반으로 미리 단말에 설정된 하나 이상의 파라미터 세트들 중, 어느 파라미터 세트가 적용될지를 기지국이 단말로 RRC 연결 해제 메시지를 통해 알려주어, 타겟 IoT 모드에서의 동작에 필요한 파라미터들이 단말에 설정될 수도 있다.
단말은, 기지국의 지시에 따라서 RRC_CONNECTED 상태에서 RRC_IDLE 상태로 전환하면서, 소스 IoT 모드에서 타겟 IoT 모드로 전환한 뒤, 기지국으로부터 지시에 의해 설정된 파라미터들을 기반으로 페이징을 모니터링할 수 있다. 페이징을 모니터링을 하는 동작은, PO (Paging Occasion)에서 P-RNTI PDCCH 전송이 있는지를 모니터링 하는 동작을 포함한다. P-RNTI PDCCH가 검출되면, 단말은 P-RNTI PDCCH에 의해 지시되는 PDSCH를 수신할 수 있다. PDSCH에는 단말 글로벌 ID가 포함되며, 해당 단말에게 전달되는 정보가 포함된다. P-RNTI PDCCH/PDSCH의 (반복) 전송/수신은 타겟 IoT 모드에 기반하여 수행될 수 있다.
타겟 IoT 모드와 관련된 정보를 수신한 단말이, 실제로 타겟 IoT 모드를 기반으로 동작하는 최초 시점은, 단말에 설정된 소스 IoT 모드 동작이 완전히 해제되기 이전 시점도 가능하다. 단말이 현재 설정된 소스 IoT 모드 해제 전 타겟 IoT 모드 기반의 동작을 수행하는 것은, 단말이 지시받은 타겟 IoT 모드로 실제 동작할 수 있는지 여부를 테스트 및/또는 검증(verify) 하기 위함일 수 있다. 예를 들어, 기지국 및 단말이 해당 타겟 IoT 모드로 동작하는 경우, 기대한 요건(coverage, power saving 등)이 만족되는지가 테스트 및/또는 검증될 수 있다.
만약, 테스트 및/또는 검증 과정에서, 기지국 및/또는 단말이 해당 타겟 IoT 모드에서 기대했던 이득이 충분하지 않거나 문제가 발생되었다고 판단하는 경우에는, 단말은 기지국으로부터 IoT 모드 설정을 새롭게 받거나 또는 소스 IoT 모드에 머무르도록 설정될 수도 있다. 예를 들어서 타겟 IoT 모드가 CE 모드 A 설정을 포함하는 경우, 단말로부터의 PUCCH/PUSCH 등의 피드백이 수신되지 않거나 피드백 수신 성능이 특정 SINR 값을 만족하지 못하면, 기지국은 타겟 IoT 모드가 좀 더 큰 커버리지를 지원 가능한 CE 모드 B 설정을 포함하도록 타겟 IoT 모드를 재설정할 수 있다.
방식(1-2) RRC_CONNECTED 상태의 단말이 기지국에게 RRC 연결 해제를 요청하면서 IoT 모드 전환을 함께 요청
도 8(a)는 RRC_CONNECTED 상태의 단말이 기지국에게 RRC 연결 해제를 요청하면서 IoT 모드 전환을 함께 요청하는 경우 단말과 기지국의 동작을, 도 8(b)는 RRC_CONNECTED 상태의 단말이 기지국에게 RRC 연결 해제를 요청하면서 IoT 모드 전환을 함께 요청하는 경우 단말 동작을 도시한다.
RRC_CONNECTED 상태의 단말이 기지국에게 RRC 연결 해제 요청 메시지를 전달하면서, RRC_IDLE 상태에서 페이징을 모니터링할 때에 적용할 IoT 모드 전환을 함께 요청할 수 있다. 단말은 IoT 모드 전환과 선호되는 타겟 IoT 모드를 함께 요청할 수 있다. 예로서 소스 IoT 모드가 non-BL 모드인 단말은 타겟 IoT 모드로 non-BL CE 모드, eMTC 모드, 혹은 NB-IoT 모드를 요청할 수 있다. 혹은 소스 IoT 모드가 eMTC 모드인 단말은 타겟 IoT 모드로 NB-IoT 모드를 요청할 수 있다. 선호 타겟 IoT 모드는 RRC IDLE 상태로의 전환 전 단말의 상태를 고려하여 결정될 수 있다. 단말의 상태로서, 예를 들어, 수신 신호 전력(Reference Signal Received Power; RSRP), 수신 신호 품질(Reference Signal Received Quality; RSRQ) 및/또는 수신 경로 손실(pathloss) 등이 고려될 수 있다. 또는 선호 타겟 IoT 모드는, 단말이 예상 가능한 가장 나쁜 통신 환경 등을 기준으로 결정될 수 있다. 예상 가능한 가장 나쁜 통신 환경으로서, 예를 들어, 통계적으로 가장 나쁜 수신 신호 전력(RSRP), 통계적으로 가장 나쁜 수신 신호 품질(RSRQ) 및/또는 통계적으로 가장 나쁜 수신 경로 손실(pathloss)이 기준으로 사용될 수 있다. 기지국이 단말의 요청에 대한 응답으로 RRC 연결 해제를 지시하면, 단말은 RRC_IDLE 상태로 전환해서 자신이 요청한 선호 타겟 IoT 모드를 기반으로 페이징을 모니터링할 수 있다. 기지국이 단말로부터 요청된 선호 타겟 IoT 모드로의 전환을 거부하거나 다른 타겟 IoT 모드로의 전환을 지시할 경우, RRC_IDLE 상태에서 단말은 소스 IoT 모드에 머물거나 기지국에 의해 지시된 타겟 IoT 모드에 머물면서, 페이징 모니터링 및 그 외의 RRC_IDLE 모드에서 필요한 동작(e.g., DL measurement, cell selection/reselection, random access 등)을 할 수 있다. 예를 들어서, DL 측정 (measurement)에 적용할 DL 참조(reference) 신호의 종류 및 신호 대역폭, DL 측정 및 보고의 주기, 무선 연결 실패(radio link failure)의 조건, 연결이 가능한 셀의 조건(e.g., eMTC, NB-IoT 지원 여부), 랜덤 접속 프리앰블(random access preamble) 전송에 사용할 자원 및/또는 랜덤 접속 프리앰블 구조 등이 IoT 모드에 따라서 달라질 수 있다. 뿐만 아니라, 단말은 해당 타겟 IoT 모드에서 동작에 문제가 발생하는 경우에 사용할 수 있는 제 2 타겟 IoT 모드를 요청할 수 있다. 제 2 타겟 IoT 모드는, 해당 타겟 IoT 모드가 사용될 수 없는 경우의 폴백(fallback) 동작을 위해 설정될 수 있다. 해당 타겟 IoT 모드에서 동작에 문제가 발생하는 경우는, 예를 들어, 하향링크 수신 신호 검출이 특정 값 보다 낮아진 경우, 단말이 전송할 데이터가 해당 타겟 IoT 모드에서 지원하기에 적합하지 않은 경우 및/또는, 해당 타겟 IoT 모드가 단말의 데이터 전송에 요구되는 데이터 전송률을 지원하지 못하는 경우 등이 있을 수 있다. 제2 타겟 IoT 모드는 단말의 요청에 대응한 기지국의 지시에 의해 설정될 수 있다. 또는, 기지국이 단말의 요청 없이 제2 타겟 IoT 모드를 설정할 수 있다.
기존 통신 시스템은 단말이 기지국에게 RRC 연결 해제 요청을 하는 절차를 지원하지 않음을 고려하여, RRC_CONNECTED 상태의 단말은 기지국과, RRC_IDLE 상태가 될 경우 선호하는 IoT 모드를 RRC 메시지를 통해서 미리 협상(negotiation)할 수도 있다. 예를 들어, 단말은 RRC_CONNECTED 상태에서 선호 타겟 IoT 모드에 대한 정보를 기지국으로 전송할 수 있다. 기지국은 단말로부터 요청된 선호 타겟 IoT 모드로의 전환을 승인할 수도 있고, 전환을 거부하거나 다른 타겟 IoT 모드로의 전환을 지시할 수도 있다. 단말은 선호 타겟 IoT 모드에서 동작에 문제가 발생하는 경우에 사용할 수 있는 제 2 선호 타겟 IoT 모드에 대한 정보를 기지국으로 전송할 수도 있다. 기지국은 단말로부터 요청된 복수의 선호 타겟 IoT 모드들 중 하나로의 전환을 승인하거나, 다른 타겟 IoT 모드로의 전환을 지시할 수도 있다. 기지국과 단말 사이에 RRC_IDLE 상태를 위한 타겟 IoT 모드가 협상된 후에, 기지국이 단말에게 RRC 연결 해제를 지시한 경우 또는 다른 어떤 이유에 의해서 UE가 RRC_IDLE 상태로 전환된 경우, 단말은 미리 협상된 타겟 IoT 모드를 기반으로 페이징을 모니터링할 수 있다.
기지국은, 단말이 해당 타겟 IoT 모드에서 페이징을 수신하기 위하여 (N/M)PDCCH/PDSCH 수신에 적용할 반복 횟수 및/또는 CE (Coverage Enhancement) 수준 등 타겟 IoT 모드에서의 동작에 필요한 파라미터들을 단말에게 알려줄 수 있다. 타겟 IoT 모드에서의 동작에 필요한 파라미터들은, RRC 연결 해제 과정 전에 미리 RRC 설정(configuration) 메시지를 통해서 단말에 설정되어 있을 수 있다. 타겟 IoT 모드에서의 동작에 필요한 파라미터들은, 단말의 RRC 연결 해제 요청에 대한 기지국의 응답 메시지를 통해 단말에 설정될 수도 있다. RRC 설정 메시지를 기반으로 미리 단말에 설정된 하나 이상의 파라미터 세트들 중, 어느 파라미터 세트가 적용될지를 기지국이 단말로 RRC 연결 해제 요청에 대한 응답 메시지를 통해 알려주어, 타겟 IoT 모드에서의 동작에 필요한 파라미터들이 단말에 설정될 수도 있다.
단말은, 자신의 요청 및/또는 기지국의 지시에 따라서 RRC_CONNECTED 상태에서 RRC_IDLE 상태로 전환하면서, 소스 IoT 모드에서 타겟 IoT 모드로 전환한 뒤, 기지국으로부터 지시에 의해 설정된 파라미터들을 기반으로 페이징을 모니터링할 수 있다. 페이징을 모니터링을 하는 동작은, PO (Paging Occasion)에서 P-RNTI PDCCH 전송이 있는지를 모니터링 하는 동작을 포함한다. P-RNTI PDCCH가 검출되면, 단말은 P-RNTI PDCCH에 의해 지시되는 PDSCH를 수신할 수 있다. PDSCH에는 단말 글로벌 ID가 포함되며, 해당 단말에게 전달되는 정보가 포함된다. P-RNTI PDCCH/PDSCH의 (반복) 전송/수신은 타겟 IoT 모드에 기반하여 수행될 수 있다.
단말은, 자신의 요청 및/또는 기지국의 지시에 따라서 RRC_CONNECTED 상태에서 RRC_IDLE 상태로 전환하면서, 소스 IoT 모드에서 타겟 IoT 모드로 전환한 뒤, 기지국으로부터 지시에 의해 설정된 파라미터들을 기반으로 페이징 모니터링 외에도 RRC_IDLE 모드에서 필요한 동작(e.g., DL measurement, cell selection/reselection, random access 등)을 할 수 있다.
IoT 모드에 따라 지원 가능한 세부사항들이 정형화되어 있다면, 단말이 자신의 어플리케이션(application)을 고려하여 RRC 연결 해제 요청을 통해 IoT 모드를 변경하는 것이 단말 동작에 유리할 수 있다.
(2) RRC_IDLE 상태로부터 RRC_CONNECTED 상태로 전환되는 경우와 관련된 IoT 모드 전환
앞서 설명된 바와 같이 본 명세서의 단말은, 차량에 장착된 단말일 수 있다. 또한, 본 명세서의 단말은, 도 15를 통해 설명된 바와 같이 자율 주행 차량으로 대체될 수 있다.
단말이 장착된 차량(또는 자율 주행 차량)이 주차 상태와 같은 대기 상태에서 전력 소모를 최소화하기 위해 혹은 지하 주차장과 같이 결합 손실이 큰 환경에서 RRC_IDLE 상태로 저전력/커버리지 개선에 적합한 IoT 모드에 머물던 단말이 펌웨어(firmware) 업데이트 등의 이유로 대용량 통신이 필요하여 RRC 연결을 맺는다면, 더 높은 데이터 용량을 지원하는 IoT 모드로 전환하는 것이 필요할 수 있다. 구체적인 예로, 지하 주차장 등에서 RRC_IDLE 상태로 저전력/커버리지 개선에 적합한 IoT 모드에 머물던 단말이, 차량 운행 등을 이유로 지하 주차장에서 벗어나면서 RRC_CONNECTED 상태로 전환될 수 있다. 지상에서 이동하는 단말은 보다 적은 커버리지를 지원하더라도 데이터 전송률(data rate)가 높은 IoT 모드로 동작하는 것이 유리할 수 있다. RRC_CONNECTED 상태로 기 진입한 단말이 데이터 전송률이 높은 IoT 모드로의 전환을 하기 위해서는, 추가적인 데이터 송수신, 단말 및 네트워크의 처리 과정(e.g. 랜덤 접속 과정의 재수행 및/또는 단말 글로벌 ID의 전환 등)이 요구되므로, 이에 소모되는 자원 낭비 및 지연 방지를 위해 RRC_CONNECTED 상태로의 전환과 관련하여 IoT 모드를 전환하는 것이 단말 및 네트워크 동작에 유리할 수 있다. 예로서 non-BL CE 모드, eMTC 모드 혹은 NB-IoT 모드로 RRC_IDLE 상태에 머물던 단말이, RRC 연결을 맺음과 동시에 또는 RRC 연결 과정을 시작한 시점으로부터 일정 시점 이내에, non-BL 모드로 IoT 모드를 전환할 수 있다. 또 다른 예로서 NB-IoT 모드로 RRC_IDLE 상태에 머물던 단말이, RRC 연결을 맺음과 동시에 또는 RRC 연결 과정을 시작한 시점으로부터 일정 시점 이내에, IoT 모드를 eMTC 모드로 전환할 수 있다. 단말이 RRC_IDLE 상태에서 RRC_CONNECTED 상태로 전환되는 경우와 관련하여 IoT 모드도 함께 전환되는 경우의 구체적인 예시는, 방식 (2-1) 및/또는 방식 (2-2)와 같을 수 있다.
방식(2-1) 기지국이 RRC_IDLE 상태의 단말에게 페이징 메시지를 전달하면서 IoT 모드 전환을 함께 지시
도 9(a)는 기지국이 RRC_IDLE 상태의 단말에게 페이징 메시지를 전달하면서 IoT 모드 전환을 함께 지시하는 경우 단말과 기지국의 동작을, 도 9(b)는 기지국이 RRC_IDLE 상태의 단말에게 페이징 메시지를 전달하면서 IoT 모드 전환을 함께 지시하는 경우 단말 동작을 도시한다.
네트워크(예, eNB 또는 gNB)가 RRC_IDLE 상태의 단말에게 페이징 메시지를 전달할 때에, 페이징 메시지를 통해서 IoT 모드 전환을 지시할 수 있다. 페이징 메시지에는 특정 단말의 글로벌 ID가 포함되므로, 네트워크는 글로벌 ID에 해당하는 단말이 IoT 를 전환하도록 지시할 수 있다. 글로벌 ID는, 예를 들어 TMSI (Temporary Mobile Subscriber Identity) 및/또는 IMSI (International Mobile Subscriber Identity)일 수 있다.
기지국은 페이징 메시지를 통해 타겟 IoT 모드를 함께 알려줄 수 있다. 페이징 메시지를 수신한 단말은 기지국과 RRC 연결을 맺기 위해서 랜덤 접속(random access)를 시도한다. 단말의 랜덤 접속을 위하여 다음과 같은 옵션들을 따를 수 있다.
옵션 1) 단말은 소스 IoT 모드를 기반으로 랜덤 접속을 수행
자신에게 해당하는 페이징 메시지를 수신한 단말은, 소드 IoT 모드에 기반한 방식을 통해서 랜덤 접속 프리앰블 전송 및 Msg2 수신, Msg3 전송, Msg4 수신의 절차를 거쳐서 기지국과 RRC 연결을 맺을 수 있다. RRC 연결 이후 단말은 타겟 IoT 모드로 전환하여 기지국과의 데이터 송수신 및 RRC_CONNECTED 상태에서 필요한 동작을 수행한다. 예를 들어서, IoT 모드에 따라서 사용할 랜덤 접속 프리앰블 구조, 접속 프리앰블 전송을 위한 자원, 접속 프리앰블 전송 반복 횟수, Msg2/4 수신에 적용할 (M/N)PDCCH/(N)PDSCH 구조, Msg2/4 수신에 적용할 (M/N)PDCCH/(N)PDSCH 반복 횟수, Msg3 전송에 적용할 (N)PUSCH 구조 및/또는 Msg3 전송에 적용할 (N)PUSCH 구조 횟수 등이 다를 수 있다.
기지국은 단말이 해당 타겟 IoT 모드에서 동작하기 위하여 (N/M)PDCCH/PDSCH 수신 및 (N/M)PUCCH/PUSCH 전송에 적용할 반복 횟수 및/또는 CE(coverage enhancement) 수준 등의 타겟 IoT 모드에서의 동작에 필요한 파라미터들을 알려줄 수 있다. 타겟 IoT 모드에서의 동작에 필요한 파라미터들은, 페이징 메시지, RRC 연결 절차 중에 전송되는 메시지(예를 들어, Msg4), 및/또는 RRC 연결 절차 이후 단말에게 전송되는 메시지를 통해서 단말에 직접 설정될 수 있다. 타겟 IoT 모드에서의 동작에 필요한 파라미터들은, 단말이 RRC_IDLE 상태가 되기 전 RRC 연결을 맺었을 동안에, RRC 설정 메시지를 통해서 미리 단말에 설정되어 있을 수 있다. 단말이 RRC_IDLE 상태가 되기 전 RRC 연결을 맺었을 동안에 RRC 설정 메시지를 기반으로 미리 단말에 설정된 파라미터 세트들 중, 어느 파라미터 세트가 적용될지를 기지국이 단말로 페이징 메시지, RRC 연결 절차 중 전송되는 메시지(예를 들어, Msg4) 및/또는 RRC 연결 절차 이후 단말에게 전송되는 메시지를 통해서 알려주어, 타겟 IoT 모드에서의 동작에 필요한 파라미터들이 단말에 설정될 수도 있다.
혹은 페이징 메시지가 아니라, RRC 연결을 맺는 과정에서 기지국이 단말에게 전달하는 메시지(e.g Msg4 혹은 RRC connection setup 메시지)를 통해서, 기지국이 단말에게 타겟 IoT 모드 및/또는 관련 파라미터를 알려줄 수도 있다.
소스 IoT 모드가 타겟 IoT 모드보다 더 넓은 커버리지(예를 들어, 지하 주차장 등 경로 감쇄가 큰 지역 내에서 단말이 동작하는 동안)를 지원할 수 있을 경우, 페이징 메시지를 받은 단말이 랜덤 접속 동작을 타겟 IoT 모드에서 시작하면, 더 좁은 커버리지 내에서 랜덤 접속 동작이 수행되어 단말이 셀 접속에 실패할 수 있다. 옵션 1의 동작을 통해, 단말이 셀 접속에 실패하는 것을 피하는 이득이 발생될 수 있다. 반대로 소스 IoT 모드가 타겟 IoT 모드보다 더 좁은 커버리지를 지원하는 경우에는, 예를 들어 지하 주차장 등 경로 감쇄가 큰 지역 내에서 페이징 신호 수신에 문제가 발생할 수 있다. 따라서 소스 IoT 모드가 타겟 IoT 모드보다 더 넓은 커버리지를 지원하도록 하고 랜덤 접속 동작을 소스 IoT 모드로 수행하는 것이 단말 동작에 유리할 수 있다.
옵션 2) 단말은 타겟 IoT 모드를 기반으로 랜덤 접속을 수행
자신에게 해당하는 페이징 메시지를 수신한 단말은, 타겟 IoT 모드에 기반한 방식을 이용해서 랜덤 접속 프리앰블 전송 및 Msg2 수신, Msg3 전송, Msg4 수신의 절차를 거쳐서 기지국과 RRC 연결을 맺고, 타겟 IoT 모드를 기반으로 RRC_CONNECTED 상태에서 필요한 동작을 수행한다. 예를 들어서, IoT 모드에 따라서 사용할 랜덤 접속 프리앰블 구조, 접속 프리앰블 전송을 위한 자원, 접속 프리앰블 전송 반복 횟수, Msg2/4 수신에 적용할 (M/N)PDCCH/(N)PDSCH 구조, Msg2/4 수신에 적용할 (M/N)PDCCH/(N)PDSCH 반복 횟수, Msg3 전송에 적용할 (N)PUSCH 구조 및/또는 Msg3 전송에 적용할 (N)PUSCH 구조 횟수 등이 다를 수 있다.
기지국은 단말이 해당 타겟 IoT 모드에서 동작하기 위하여 (N/M)PDCCH/PDSCH 수신 및 (N/M)PUCCH/PUSCH 전송에 적용할 반복 횟수 및/또는 CE(coverage enhancement) 수준 등의 타겟 IoT 모드에서의 동작에 필요한 파라미터들을 알려줄 수 있다. 타겟 IoT 모드에서의 동작에 필요한 파라미터들은 페이징 메시지, RRC 연결 절차 중에 전송되는 메시지(예를 들어, Msg4), 및/또는 RRC 연결 절차 이후 단말에게 전송되는 메시지를 통해서 단말에 직접 설정될 수 있다. 타겟 IoT 모드에서의 동작에 필요한 파라미터들은 단말이 RRC_IDLE 상태가 되기 전 RRC 연결을 맺었을 동안에, RRC 설정 메시지를 통해서 미리 단말에 설정되어 있을 수 있다. 단말이 RRC_IDLE 상태가 되기 전 RRC 연결을 맺었을 동안에 RRC 설정 메시지를 기반으로 미리 단말에 설정된 파라미터 세트들 중, 어느 파라미터 세트가 적용될지를 기지국이 단말로 페이징 메시지, RRC 연결 절차 중 전송되는 메시지(예를 들어, Msg4) 및/또는 RRC 연결 절차 이후 단말에게 전송되는 메시지를 통해서 알려주어, 타겟 IoT 모드에서의 동작에 필요한 파라미터들이 단말에 설정될 수도 있다. 동일 IoT 모드에서도, (N)PRACH, (M/N)PDCCH, (N)PDSCH, (N)PUSCH에 적용되는 최대 반복 횟수 및/또는 반복 횟수에 따른 (N)PRACH 자원 등에 대하여 서로 다른 파라미터 세트들이 준비될 수 있다. 예를 들어, 동일 IoT 모드의 단말들끼리도, 설정된 파라미터 세트가 서로 다른 경우, 채널의 최대 반복 횟수 및/또는 채널 전송 자원이 서로 달라질 수 있다.
옵션 3) 단말이 자체적으로 판단한 조건에 따라서 옵션 1)과 옵션 2) 중 하나를 따름
자신에게 해당하는 페이징 메시지를 수신한 단말은, 기지국으로부터의 신호 수신 세기(e.g., RSRP) 등의 특정 조건을 기준으로 옵션 1)과 옵션 2) 중 하나의 방식을 선택하여 랜덤 접속을 수행할 수 있다. 예를 들어서 기지국으로부터 측정된 RSRP가 특정 값 이하인 경우에는 옵션 1)을, 아닌 경우는 옵션 2)를 선택하여 동작할 수 있다.
(3) RRC_IDLE 상태에서 IoT 모드 전환
앞서 설명된 바와 같이 본 명세서의 단말은, 차량에 장착된 단말일 수 있다. 또한, 본 명세서의 단말은, 도 15를 통해 설명된 바와 같이 자율 주행 차량으로 대체될 수 있다.
예를 들어서, 특정 IoT 모드로 RRC_IDLE 상태에서 페이징 모니터링하고 있는 단말의 환경이, 지하 주차장과 같이 결합 손실이 큰 환경으로 바뀔 수 있다. 큰 결합 손실을 보상할 수 있는 방식으로 페이징을 수신하기 위해서, 단말은 RRC_IDLE 상태를 유지하면서도 커버리지 개선에 적합한 IoT모드로 전환될 필요성이 있다. 예로서 non-BL 모드로 RRC_IDLE 상태에 머물던 단말은, RRC_IDLE 상태를 유지하면서 non-BL CE 모드, eMTC 모드 혹은 NB-IoT 모드로 IoT 모드를 전환할 수 있다. 또 다른 예로서 eMTC 모드로 RRC_IDLE 상태에 머물던 단말은, RRC_IDLE 상태를 유지하면서 NB-IoT 모드로 IoT 모드를 전환할 수 있다. 반대로 차량이 지하 주차장에서 빠져 나왔을 경우, 더 효율적인 페이징 수신을 위해서, 단말은 큰 결합 손실을 보상할 필요가 없는 방식으로 IoT 모드를 전환할 수 있다. 예로서 non-BL CE 모드, eMTC 모드 혹은 NB-IoT 모드로 RRC_IDLE 상태에 머물던 단말이, RRC_IDLE 상태를 유지하면서 non-BL 모드로 IoT 모드를 전환할 수 있다. 또 다른 예로서 NB-IoT 모드로 RRC_IDLE 상태에 머물던 단말이, RRC_IDLE 상태를 유지하면서 eMTC 모드로 IoT 모드를 전환할 수 있다. 단말이 RRC_IDLE 상태에서 IoT 모드를 전환하는 경우의 구체적인 예시는, 방식 (3-1)과 같을 수 있다.
방식(3-1) RRC_IDLE 상태의 단말이 랜덤 접속 과정을 통해서 IoT 모드 전환을 요청
도 10은 기지국이 RRC_IDLE 상태의 단말에게 페이징 메시지를 전달하면서 IoT 모드 전환을 함께 지시하는 경우 단말 동작을 도시한다.
RRC_IDLE 상태의 단말이 기지국에 대한 랜덤 접속 절차를 수행하면서, 앞으로 RRC_IDLE 상태에서 소스 IoT 모드와는 다른 타겟 IoT 모드에서 동작할 것을 기지국에 알리거나, 기지국으로 다른 타겟 IoT 모드에서 동작하게 해줄 것을 요청할 수 있다. 해당 요청은 단말의 랜덤 접속 프리앰블 전송 후, 기지국으로부터 Msg2를 수신한 뒤에 전송하는 Msg3에 포함될 수 있다. 또는 해당 요청은 Msg3 전송 이후 단말의 (EDT 기반) 메시지 전송에 포함될 수 있다. 기지국은 단말로부터의 요청 메시지에 대응하는 응답 메시지 전송을 통해서, 요청된 타겟 IoT 모드에서 동작할 것을 수락 또는 거부할 수 있다. Msg3에는 경쟁 해소를 위해 단말 경쟁 해소 ID(예, UE global ID)와 연관된 CCCH SDU가 포함되며, 이를 통해 IoT 모드 전환을 요청하는 단말에 관한 정보를 기지국에게 알릴 수 있다.
기지국은, 단말이 해당 타겟 IoT 모드에서 페이징을 수신하기 위하여 (N/M)PDCCH/PDSCH 수신에 적용할 반복 횟수 및/또는 CE (Coverage Enhancement) 수준 등 타겟 IoT 모드에서의 동작에 필요한 파라미터들을 단말에게 알려줄 수 있다. 타겟 IoT 모드에서의 동작에 필요한 파라미터들은, 페이징 메시지, RRC 연결 절차 중에 전송되는 메시지(예를 들어, Msg4), 및/또는 RRC 연결 절차 이후 단말에게 전송되는 메시지(예를 들어, EDT 기반 메시지)를 통해서 단말에 직접 설정될 수 있다. 타겟 IoT 모드에서의 동작에 필요한 파라미터들은, 단말이 RRC_IDLE 상태가 되기 전 RRC 연결을 맺었을 동안에, RRC 설정 메시지를 통해서 미리 단말에 설정되어 있을 수 있다. 단말이 RRC_IDLE 상태가 되기 전 RRC 연결을 맺었을 동안에 RRC 설정 메시지를 기반으로 미리 단말에 설정된 파라미터 세트들 중, 어느 파라미터 세트가 적용될지를 기지국이 단말로 페이징 메시지, RRC 연결 절차 중 전송되는 메시지(예를 들어, Msg4) 및/또는 RRC 연결 절차 이후 단말에게 전송되는 메시지를 통해서 알려주어, 타겟 IoT 모드에서의 동작에 필요한 파라미터들이 단말에 설정될 수도 있다.
RRC_IDLE 상태에서 IoT 모드가 변경되는 경우에는, 랜덤 접속 과정을 통해서 단말이 기지국과 연결 절차를 수행할 필요가 없으므로, NB-IoT, eMTC 또는 NR-lite 상태에 있는 단말의 경우, 랜덤 접속 절차를 해당 표준에서 정의된 EDT동작에 기반하여 수행할 수 있다.
단말은 기지국의 응답에 기반하여(기지국이 타겟 IoT 모드로의 전환을 수락한 경우), RRC_IDLE 상태에서 자신이 요청한 타겟 IoT 모드에서 페이징 수신 및/또는 필요한 동작을 수행할 수 있다. 또는, 단말은 기지국의 응답에 기반하여(기지국이 타겟 IoT 모드로의 전환을 거부한 경우), 기존 소스 IoT 모드에서 페이징 수신 및/또는 필요한 동작을 수행할 수 있다.
구현예
이상에서 설명된 동작들 중 하나 이상이 유기적으로 결합되어 실시예들이 구현될 수 있다.
앞서 설명된 동작들의 조합에 의해 구현 가능한 실시예 중 하나는 도 11과 같을 수 있다.
도 11을 참조하면, 본 발명의 실시예들은 단말을 포함하는 통신 장치에 의해 수행될 수 있고, RRC (Radio Resource Control) 연결 해제 메시지를 수신하는 단계(S1101), 상기 RRC 연결 해제 메시지에 기반하여 RRC 연결을 해제하는 단계(S1103)를 포함하여 구성될 수 있다.
RRC 연결 해제 메시지는 타겟 IoT 모드에 대한 정보를 포함할 수 있다. 또한, 통신 장치는 타겟 IoT 모드에 대한 정보에 기반하여, 소스 IoT 모드에서 타겟 IoT 모드로 전환된다. IoT 모드의 전환 시점은, RRC 연결 해제 동작과 연관될 수 있다. 예를 들어, RRC 연결 해제와 동시에 IoT 모드가 전환될 수 있다. 다만, 반드시 RRC 연결 해제와 IoT 모드 전환이 동시에 수행되는 것은 아니며, 단말이 RRC 연결 해제 메시지를 수신한 이후 일정 시간 내에 IoT 모드 전환이 수행될 수 있다.
타겟 IoT 모드에 대한 정보는 네트워크에 의해 RRC 연결 해제 메시지에 포함되어 전송될 수 있다. 또한, RRC 연결 해제 메시지는 통신 장치로부터의 RRC 연결 해제 요청 메시지에 대응하여 전송될 수 있다. RRC 연결 해제 요청 메시지는, 통신 장치가 선호하는 하나 이상의 타겟 IoT 모드들에 대한 정보인 선호 타겟 IoT 모드들에 대한 정보를 포함할 수 있다. 또한, 타겟 IoT 모드에 대한 정보는 통신 장치가 RRC 연결 해제 메시지를 수신하기 전에, 통신 장치와 네트워크 사이의 협상 결과를 기반으로 미리 결정되어 있을 수 있다. 미리 결정된 타겟 IoT 모드에 대한 정보는 RRC 연결 해제 메시지 수신 전에 통신 장치에 의해 수신될 수 있다.
타겟 IoT 모드의 동작을 위한 하나 이상의 파라미터들에 대한 정보는, RRC 연결 해제 전에 RRC 설정 메시지를 통해 수신 및/또는 상기 RRC 연결 해제 메시지를 통해 수신될 수 있다. 하나 이상의 파라미터들에 대한 정보는, 하나 이상의 파라미터 세트들에 대한 정보를 포함할 수 있다.
통신 장치는 RRC 연결 해제 전에 상기 타겟 IoT 모드의 동작이 특정 기준을 만족하는지 여부를 테스트할 수 있다. 테스트가 만족되면 통신 장치는 타겟 IoT 모드를 기반으로 동작할 수 있다. 테스트가 만족되지 않으면 통신 장치는 소스 IoT 모드 또는 제2 타겟 IoT 모드를 기반으로 동작할 수 있다.
타겟 IoT 모드로 전환된 통신 장치는, RRC 연결 해제 이후 타겟 IoT 모드를 기반으로 페이징 메시지를 모니터링할 수 있다.
이상에서 설명된 도 11의 동작에 더하여, 도 1 내지 도 10를 통해 설명된 동작 중 하나 이상이 결합되어 추가로 수행될 수 있다.
본 발명이 적용되는 통신 시스템 예
이로 제한되는 것은 아니지만, 본 문서에 개시된 본 발명의 다양한 설명, 기능, 절차, 제안, 방법 및/또는 동작 순서도들은 기기들간에 무선 통신/연결(예, 5G)을 필요로 하는 다양한 분야에 적용될 수 있다.
이하, 도면을 참조하여 보다 구체적으로 예시한다. 이하의 도면/설명에서 동일한 도면 부호는 다르게 기술하지 않는 한, 동일하거나 대응되는 하드웨어 블록, 소프트웨어 블록 또는 기능 블록을 예시할 수 있다.
도 12는 본 발명에 적용되는 통신 시스템(1)을 예시한다.
도 12를 참조하면, 본 발명에 적용되는 통신 시스템(1)은 무선 기기, 기지국 및 네트워크를 포함한다. 여기서, 무선 기기는 무선 접속 기술(예, 5G NR(New RAT), LTE(Long Term Evolution))을 이용하여 통신을 수행하는 기기를 의미하며, 통신/무선/5G 기기로 지칭될 수 있다. 이로 제한되는 것은 아니지만, 무선 기기는 로봇(100a), 차량(100b-1, 100b-2), XR(eXtended Reality) 기기(100c), 휴대 기기(Hand-held device)(100d), 가전(100e), IoT(Internet of Thing) 기기(100f), AI기기/서버(400)를 포함할 수 있다. 예를 들어, 차량은 무선 통신 기능이 구비된 차량, 자율 주행 차량, 차량간 통신을 수행할 수 있는 차량 등을 포함할 수 있다. 여기서, 차량은 UAV(Unmanned Aerial Vehicle)(예, 드론)를 포함할 수 있다. XR 기기는 AR(Augmented Reality)/VR(Virtual Reality)/MR(Mixed Reality) 기기를 포함하며, HMD(Head-Mounted Device), 차량에 구비된 HUD(Head-Up Display), 텔레비전, 스마트폰, 컴퓨터, 웨어러블 디바이스, 가전 기기, 디지털 사이니지(signage), 차량, 로봇 등의 형태로 구현될 수 있다. 휴대 기기는 스마트폰, 스마트패드, 웨어러블 기기(예, 스마트워치, 스마트글래스), 컴퓨터(예, 노트북 등) 등을 포함할 수 있다. 가전은 TV, 냉장고, 세탁기 등을 포함할 수 있다. IoT 기기는 센서, 스마트미터 등을 포함할 수 있다. 예를 들어, 기지국, 네트워크는 무선 기기로도 구현될 수 있으며, 특정 무선 기기(200a)는 다른 무선 기기에게 기지국/네트워크 노드로 동작할 수도 있다.
무선 기기(100a~100f)는 기지국(200)을 통해 네트워크(300)와 연결될 수 있다. 무선 기기(100a~100f)에는 AI(Artificial Intelligence) 기술이 적용될 수 있으며, 무선 기기(100a~100f)는 네트워크(300)를 통해 AI 서버(400)와 연결될 수 있다. 네트워크(300)는 3G 네트워크, 4G(예, LTE) 네트워크 또는 5G(예, NR) 네트워크 등을 이용하여 구성될 수 있다. 무선 기기(100a~100f)는 기지국(200)/네트워크(300)를 통해 서로 통신할 수도 있지만, 기지국/네트워크를 통하지 않고 직접 통신(e.g. 사이드링크 통신(sidelink communication))할 수도 있다. 예를 들어, 차량들(100b-1, 100b-2)은 직접 통신(e.g. V2V(Vehicle to Vehicle)/V2X(Vehicle to everything) communication)을 할 수 있다. 또한, IoT 기기(예, 센서)는 다른 IoT 기기(예, 센서) 또는 다른 무선 기기(100a~100f)와 직접 통신을 할 수 있다.
무선 기기(100a~100f)/기지국(200), 기지국(200)/기지국(200) 간에는 무선 통신/연결(150a, 150b, 150c)이 이뤄질 수 있다. 여기서, 무선 통신/연결은 상향/하향링크 통신(150a)과 사이드링크 통신(150b)(또는, D2D 통신), 기지국간 통신(150c)(e.g. relay, IAB(Integrated Access Backhaul)과 같은 다양한 무선 접속 기술(예, 5G NR)을 통해 이뤄질 수 있다. 무선 통신/연결(150a, 150b, 150c)을 통해 무선 기기와 기지국/무선 기기, 기지국과 기지국은 서로 무선 신호를 송신/수신할 수 있다. 예를 들어, 무선 통신/연결(150a, 150b, 150c)은 다양한 물리 채널을 통해 신호를 송신/수신할 수 있다. 이를 위해, 본 발명의 다양한 제안들에 기반하여, 무선 신호의 송신/수신을 위한 다양한 구성정보 설정 과정, 다양한 신호 처리 과정(예, 채널 인코딩/디코딩, 변조/복조, 자원 매핑/디매핑 등), 자원 할당 과정 등 중 적어도 일부가 수행될 수 있다.
본 발명이 적용되는 무선 기기 예
도 13은 본 발명에 적용될 수 있는 무선 기기를 예시한다.
도 13을 참조하면, 제1 무선 기기(100)와 제2 무선 기기(200)는 다양한 무선 접속 기술(예, LTE, NR)을 통해 무선 신호를 송수신할 수 있다. 여기서, {제1 무선 기기(100), 제2 무선 기기(200)}은 도 12의 {무선 기기(100x), 기지국(200)} 및/또는 {무선 기기(100x), 무선 기기(100x)}에 대응할 수 있다.
제1 무선 기기(100)는 하나 이상의 프로세서(102) 및 하나 이상의 메모리(104)를 포함하며, 추가적으로 하나 이상의 송수신기(106) 및/또는 하나 이상의 안테나(108)을 더 포함할 수 있다. 프로세서(102)는 메모리(104) 및/또는 송수신기(106)를 제어하며, 본 문서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 동작 순서도들을 구현하도록 구성될 수 있다. 예를 들어, 프로세서(102)는 메모리(104) 내의 정보를 처리하여 제1 정보/신호를 생성한 뒤, 송수신기(106)을 통해 제1 정보/신호를 포함하는 무선 신호를 전송할 수 있다. 또한, 프로세서(102)는 송수신기(106)를 통해 제2 정보/신호를 포함하는 무선 신호를 수신한 뒤, 제2 정보/신호의 신호 처리로부터 얻은 정보를 메모리(104)에 저장할 수 있다. 메모리(104)는 프로세서(102)와 연결될 수 있고, 프로세서(102)의 동작과 관련한 다양한 정보를 저장할 수 있다. 예를 들어, 메모리(104)는 프로세서(102)에 의해 제어되는 프로세스들 중 일부 또는 전부를 수행하거나, 본 문서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 동작 순서도들을 수행하기 위한 명령들을 포함하는 소프트웨어 코드를 저장할 수 있다. 여기서, 프로세서(102)와 메모리(104)는 무선 통신 기술(예, LTE, NR)을 구현하도록 설계된 통신 모뎀/회로/칩의 일부일 수 있다. 송수신기(106)는 프로세서(102)와 연결될 수 있고, 하나 이상의 안테나(108)를 통해 무선 신호를 송신 및/또는 수신할 수 있다. 송수신기(106)는 송신기 및/또는 수신기를 포함할 수 있다. 송수신기(106)는 RF(Radio Frequency) 유닛과 혼용될 수 있다. 본 발명에서 무선 기기는 통신 모뎀/회로/칩을 의미할 수도 있다.
제2 무선 기기(200)는 하나 이상의 프로세서(202), 하나 이상의 메모리(204)를 포함하며, 추가적으로 하나 이상의 송수신기(206) 및/또는 하나 이상의 안테나(208)를 더 포함할 수 있다. 프로세서(202)는 메모리(204) 및/또는 송수신기(206)를 제어하며, 본 문서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 동작 순서도들을 구현하도록 구성될 수 있다. 예를 들어, 프로세서(202)는 메모리(204) 내의 정보를 처리하여 제3 정보/신호를 생성한 뒤, 송수신기(206)를 통해 제3 정보/신호를 포함하는 무선 신호를 전송할 수 있다. 또한, 프로세서(202)는 송수신기(206)를 통해 제4 정보/신호를 포함하는 무선 신호를 수신한 뒤, 제4 정보/신호의 신호 처리로부터 얻은 정보를 메모리(204)에 저장할 수 있다. 메모리(204)는 프로세서(202)와 연결될 수 있고, 프로세서(202)의 동작과 관련한 다양한 정보를 저장할 수 있다. 예를 들어, 메모리(204)는 프로세서(202)에 의해 제어되는 프로세스들 중 일부 또는 전부를 수행하거나, 본 문서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 동작 순서도들을 수행하기 위한 명령들을 포함하는 소프트웨어 코드를 저장할 수 있다. 여기서, 프로세서(202)와 메모리(204)는 무선 통신 기술(예, LTE, NR)을 구현하도록 설계된 통신 모뎀/회로/칩의 일부일 수 있다. 송수신기(206)는 프로세서(202)와 연결될 수 있고, 하나 이상의 안테나(208)를 통해 무선 신호를 송신 및/또는 수신할 수 있다. 송수신기(206)는 송신기 및/또는 수신기를 포함할 수 있다 송수신기(206)는 RF 유닛과 혼용될 수 있다. 본 발명에서 무선 기기는 통신 모뎀/회로/칩을 의미할 수도 있다.
이하, 무선 기기(100, 200)의 하드웨어 요소에 대해 보다 구체적으로 설명한다. 이로 제한되는 것은 아니지만, 하나 이상의 프로토콜 계층이 하나 이상의 프로세서(102, 202)에 의해 구현될 수 있다. 예를 들어, 하나 이상의 프로세서(102, 202)는 하나 이상의 계층(예, PHY, MAC, RLC, PDCP, RRC, SDAP와 같은 기능적 계층)을 구현할 수 있다. 하나 이상의 프로세서(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, RAM, EPROM, 플래시 메모리, 하드 드라이브, 레지스터, 캐쉬 메모리, 컴퓨터 판독 저장 매체 및/또는 이들의 조합으로 구성될 수 있다. 하나 이상의 메모리(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)를 통해 본 문서에 개시된 설명, 기능, 절차, 제안, 방법 및/또는 동작 순서도 등에서 언급되는 사용자 데이터, 제어 정보, 무선 신호/채널 등을 송수신하도록 설정될 수 있다. 본 문서에서, 하나 이상의 안테나는 복수의 물리 안테나이거나, 복수의 논리 안테나(예, 안테나 포트)일 수 있다. 하나 이상의 송수신기(106, 206)는 수신된 사용자 데이터, 제어 정보, 무선 신호/채널 등을 하나 이상의 프로세서(102, 202)를 이용하여 처리하기 위해, 수신된 무선 신호/채널 등을 RF 밴드 신호에서 베이스밴드 신호로 변환(Convert)할 수 있다. 하나 이상의 송수신기(106, 206)는 하나 이상의 프로세서(102, 202)를 이용하여 처리된 사용자 데이터, 제어 정보, 무선 신호/채널 등을 베이스밴드 신호에서 RF 밴드 신호로 변환할 수 있다. 이를 위하여, 하나 이상의 송수신기(106, 206)는 (아날로그) 오실레이터 및/또는 필터를 포함할 수 있다.
본 발명이 적용되는 무선 기기 활용 예
도 14는 본 발명에 적용되는 무선 기기의 다른 예를 나타낸다. 무선 기기는 사용-예/서비스에 따라 다양한 형태로 구현될 수 있다(도 12 참조).
도 14를 참조하면, 무선 기기(100, 200)는 도 13의 무선 기기(100,200)에 대응하며, 다양한 요소(element), 성분(component), 유닛/부(unit), 및/또는 모듈(module)로 구성될 수 있다. 예를 들어, 무선 기기(100, 200)는 통신부(110), 제어부(120), 메모리부(130) 및 추가 요소(140)를 포함할 수 있다. 통신부는 통신 회로(112) 및 송수신기(들)(114)을 포함할 수 있다. 예를 들어, 통신 회로(112)는 도 13의 하나 이상의 프로세서(102,202) 및/또는 하나 이상의 메모리(104,204) 를 포함할 수 있다. 예를 들어, 송수신기(들)(114)는 도 13의 하나 이상의 송수신기(106,206) 및/또는 하나 이상의 안테나(108,208)을 포함할 수 있다. 제어부(120)는 통신부(110), 메모리부(130) 및 추가 요소(140)와 전기적으로 연결되며 무선 기기의 제반 동작을 제어한다. 예를 들어, 제어부(120)는 메모리부(130)에 저장된 프로그램/코드/명령/정보에 기반하여 무선 기기의 전기적/기계적 동작을 제어할 수 있다. 또한, 제어부(120)는 메모리부(130)에 저장된 정보를 통신부(110)을 통해 외부(예, 다른 통신 기기)로 무선/유선 인터페이스를 통해 전송하거나, 통신부(110)를 통해 외부(예, 다른 통신 기기)로부터 무선/유선 인터페이스를 통해 수신된 정보를 메모리부(130)에 저장할 수 있다.
추가 요소(140)는 무선 기기의 종류에 따라 다양하게 구성될 수 있다. 예를 들어, 추가 요소(140)는 파워 유닛/배터리, 입출력부(I/O unit), 구동부 및 컴퓨팅부 중 적어도 하나를 포함할 수 있다. 이로 제한되는 것은 아니지만, 무선 기기는 로봇(도 12, 100a), 차량(도 12, 100b-1, 100b-2), XR 기기(도 12, 100c), 휴대 기기(도 12, 100d), 가전(도 12, 100e), IoT 기기(도 12, 100f), 디지털 방송용 단말, 홀로그램 장치, 공공 안전 장치, MTC 장치, 의료 장치, 핀테크 장치(또는 금융 장치), 보안 장치, 기후/환경 장치, AI 서버/기기(도 12, 400), 기지국(도 12, 200), 네트워크 노드 등의 형태로 구현될 수 있다. 무선 기기는 사용-예/서비스에 따라 이동 가능하거나 고정된 장소에서 사용될 수 있다.
도 14에서 무선 기기(100, 200) 내의 다양한 요소, 성분, 유닛/부, 및/또는 모듈은 전체가 유선 인터페이스를 통해 상호 연결되거나, 적어도 일부가 통신부(110)를 통해 무선으로 연결될 수 있다. 예를 들어, 무선 기기(100, 200) 내에서 제어부(120)와 통신부(110)는 유선으로 연결되며, 제어부(120)와 제1 유닛(예, 130, 140)은 통신부(110)를 통해 무선으로 연결될 수 있다. 또한, 무선 기기(100, 200) 내의 각 요소, 성분, 유닛/부, 및/또는 모듈은 하나 이상의 요소를 더 포함할 수 있다. 예를 들어, 제어부(120)는 하나 이상의 프로세서 집합으로 구성될 수 있다. 예를 들어, 제어부(120)는 통신 제어 프로세서, 어플리케이션 프로세서(Application processor), ECU(Electronic Control Unit), 그래픽 처리 프로세서, 메모리 제어 프로세서 등의 집합으로 구성될 수 있다. 다른 예로, 메모리부(130)는 RAM(Random Access Memory), DRAM(Dynamic RAM), ROM(Read Only Memory), 플래시 메모리(flash memory), 휘발성 메모리(volatile memory), 비-휘발성 메모리(non-volatile memory) 및/또는 이들의 조합으로 구성될 수 있다.
본 발명이 적용되는 차량 또는 자율 주행 차량 예
도 15는 본 발명에 적용되는 차량 또는 자율 주행 차량을 예시한다. 차량 또는 자율 주행 차량은 이동형 로봇, 차량, 기차, 유/무인 비행체(Aerial Vehicle, AV), 선박 등으로 구현될 수 있다.
도 15를 참조하면, 차량 또는 자율 주행 차량(100)은 안테나부(108), 통신부(110), 제어부(120), 구동부(140a), 전원공급부(140b), 센서부(140c) 및 자율 주행부(140d)를 포함할 수 있다. 안테나부(108)는 통신부(110)의 일부로 구성될 수 있다. 블록 110/130/140a~140d는 각각 도 14의 블록 110/130/140에 대응한다.
통신부(110)는 다른 차량, 기지국(e.g. 기지국, 노변 기지국(Road Side unit) 등), 서버 등의 외부 기기들과 신호(예, 데이터, 제어 신호 등)를 송수신할 수 있다. 제어부(120)는 차량 또는 자율 주행 차량(100)의 요소들을 제어하여 다양한 동작을 수행할 수 있다. 제어부(120)는 ECU(Electronic Control Unit)를 포함할 수 있다. 구동부(140a)는 차량 또는 자율 주행 차량(100)을 지상에서 주행하게 할 수 있다. 구동부(140a)는 엔진, 모터, 파워 트레인, 바퀴, 브레이크, 조향 장치 등을 포함할 수 있다. 전원공급부(140b)는 차량 또는 자율 주행 차량(100)에게 전원을 공급하며, 유/무선 충전 회로, 배터리 등을 포함할 수 있다. 센서부(140c)는 차량 상태, 주변 환경 정보, 사용자 정보 등을 얻을 수 있다. 센서부(140c)는 IMU(inertial measurement unit) 센서, 충돌 센서, 휠 센서(wheel sensor), 속도 센서, 경사 센서, 중량 감지 센서, 헤딩 센서(heading sensor), 포지션 모듈(position module), 차량 전진/후진 센서, 배터리 센서, 연료 센서, 타이어 센서, 스티어링 센서, 온도 센서, 습도 센서, 초음파 센서, 조도 센서, 페달 포지션 센서 등을 포함할 수 있다. 자율 주행부(140d)는 주행중인 차선을 유지하는 기술, 어댑티브 크루즈 컨트롤과 같이 속도를 자동으로 조절하는 기술, 정해진 경로를 따라 자동으로 주행하는 기술, 목적지가 설정되면 자동으로 경로를 설정하여 주행하는 기술 등을 구현할 수 있다.
일 예로, 통신부(110)는 외부 서버로부터 지도 데이터, 교통 정보 데이터 등을 수신할 수 있다. 자율 주행부(140d)는 획득된 데이터를 기반으로 자율 주행 경로와 드라이빙 플랜을 생성할 수 있다. 제어부(120)는 드라이빙 플랜에 따라 차량 또는 자율 주행 차량(100)이 자율 주행 경로를 따라 이동하도록 구동부(140a)를 제어할 수 있다(예, 속도/방향 조절). 자율 주행 도중에 통신부(110)는 외부 서버로부터 최신 교통 정보 데이터를 비/주기적으로 획득하며, 주변 차량으로부터 주변 교통 정보 데이터를 획득할 수 있다. 또한, 자율 주행 도중에 센서부(140c)는 차량 상태, 주변 환경 정보를 획득할 수 있다. 자율 주행부(140d)는 새로 획득된 데이터/정보에 기반하여 자율 주행 경로와 드라이빙 플랜을 갱신할 수 있다. 통신부(110)는 차량 위치, 자율 주행 경로, 드라이빙 플랜 등에 관한 정보를 외부 서버로 전달할 수 있다. 외부 서버는 차량 또는 자율 주행 차량들로부터 수집된 정보에 기반하여, AI 기술 등을 이용하여 교통 정보 데이터를 미리 예측할 수 있고, 예측된 교통 정보 데이터를 차량 또는 자율 주행 차량들에게 제공할 수 있다.
본 발명은 본 발명의 특징을 벗어나지 않는 범위에서 다른 특정한 형태로 구체화될 수 있음은 당업자에게 자명하다. 따라서, 상기의 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다.
상술된 바와 같이 본 발명은 다양한 무선 통신 시스템에 적용될 수 있다.

Claims (15)

  1. 무선 통신 시스템에서 통신 장치에 의해 수행되는 방법에 있어서,
    RRC (Radio Resource Control) 연결 해제 메시지를 수신하는 단계; 및
    상기 RRC 연결 해제 메시지에 기반하여, RRC 연결을 해제하는 단계; 를 포함하며,
    상기 RRC 연결 해제 메시지는, 상기 타겟 IoT (Internet of Things) 모드에 대한 정보를 포함하고,
    상기 타겟 IoT 모드에 대한 정보에 기반하여, 상기 통신 장치는 소스 IoT 모드에서 타겟 IoT 모드로 전환되는, 방법.
  2. 제1항에 있어서,
    상기 RRC 연결 해제와 동시에 또는 상기 RRC 연결 해제 메시지를 수신한 시점으로부터 일정 범위 이내의 시점에서, 상기 통신 장치는 소스 IoT 모드에서 상기 타겟 IoT 모드로 전환되는, 방법.
  3. 제1항에 있어서,
    상기 타겟 IoT 모드는 하나 이상의 선호 타겟 IoT 모드들에 대한 정보에 기반하여 설정되며,
    상기 하나 이상의 선호 타겟 IoT 모드들에 대한 정보는, 상기 통신 장치에 의해 전송되는 RRC 연결 해제 요청 메시지에 포함되는, 방법.
  4. 제1항에 있어서,
    상기 타겟 IoT 모드는, 상기 RRC 연결 해제 메시지의 수신 전에 미리 결정되는, 방법.
  5. 제1항에 있어서,
    상기 타겟 IoT 모드의 동작을 위한 하나 이상의 파라미터들에 대한 정보는,
    상기 RRC 연결 해제 전에 RRC 설정 메시지를 통해 수신 및/또는 상기 RRC 연결 해제 메시지를 통해 수신되는, 방법.
  6. 제1항에 있어서,
    상기 통신 장치는 상기 RRC 연결 해제 이후 상기 타겟 IoT 모드를 기반으로 페이징(paging) 메시지를 모니터링하는, 방법.
  7. 제1항에 있어서,
    상기 통신 장치는 상기 RRC 연결 해제 전에 상기 타겟 IoT 모드의 동작이 특정 기준을 만족하는지 여부를 테스트하는, 방법.
  8. 무선 통신 시스템에서 동작하는 통신 장치에 있어서,
    적어도 하나의 트랜시버;
    적어도 하나의 프로세서; 및
    상기 적어도 하나의 프로세서에 동작 가능하도록 연결되고, 실행될 경우 상기 적어도 하나의 프로세서가 특정 동작을 수행하도록 하는 명령들(instructions)을 저장하는 적어도 하나의 메모리; 를 포함하고,
    상기 특정 동작은,
    RRC (Radio Resource Control) 연결 해제 메시지를 수신하고,
    상기 RRC 연결 해제 메시지에 기반하여, RRC 연결을 해제하는 것을 포함하며,
    상기 RRC 연결 해제 메시지는, 상기 타겟 IoT (Internet of Things) 모드에 대한 정보를 포함하고,
    상기 타겟 IoT 모드에 대한 정보에 기반하여, 상기 통신 장치는 소스 IoT 모드에서 타겟 IoT 모드로 전환되는, 통신 장치.
  9. 제8항에 있어서,
    상기 RRC 연결 해제와 동시에 또는 상기 RRC 연결 해제 메시지를 수신한 시점으로부터 일정 범위 이내의 시점에서, 상기 통신 장치는 소스 IoT 모드에서 상기 타겟 IoT 모드로 전환되는, 통신 장치.
  10. 제8항에 있어서,
    상기 타겟 IoT 모드는 하나 이상의 선호 타겟 IoT 모드들에 대한 정보에 기반하여 설정되며,
    상기 하나 이상의 선호 타겟 IoT 모드들에 대한 정보는, 상기 통신 장치에 의해 전송되는 RRC 연결 해제 요청 메시지에 포함되는, 통신 장치.
  11. 제8항에 있어서,
    상기 타겟 IoT 모드는, 상기 RRC 연결 해제 메시지의 수신 전에 미리 결정되는, 통신 장치.
  12. 제8항에 있어서,
    상기 타겟 IoT 모드의 동작을 위한 하나 이상의 파라미터들에 대한 정보는,
    상기 RRC 연결 해제 전에 RRC 설정 메시지를 통해 수신 및/또는 상기 RRC 연결 해제 메시지를 통해 수신되는, 통신 장치.
  13. 제8항에 있어서,
    상기 통신 장치는 상기 RRC 연결 해제 이후 상기 타겟 IoT 모드를 기반으로 페이징(paging) 메시지를 모니터링하는, 통신 장치.
  14. 제8항에 있어서,
    상기 통신 장치는 상기 RRC 연결 해제 전에 상기 타겟 IoT 모드의 동작이 특정 기준을 만족하는지 여부를 테스트하는, 통신 장치.
  15. 제8항에 있어서,
    상기 통신 장치는 적어도 단말, 네트워크 및 상기 통신 장치 외의 다른 자율 주행 차량과 통신할 수 있는 자율 주행 차량을 포함하는, 통신 장치.
PCT/KR2019/016624 2018-11-28 2019-11-28 무선 통신 시스템에서 동작하는 방법 및 장치 WO2020111836A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/291,720 US11968741B2 (en) 2018-11-28 2019-11-28 Method and device for switching an IoT mode in wireless communication system

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR20180149748 2018-11-28
KR20180149780 2018-11-28
KR10-2018-0149780 2018-11-28
KR10-2018-0149748 2018-11-28

Publications (1)

Publication Number Publication Date
WO2020111836A1 true WO2020111836A1 (ko) 2020-06-04

Family

ID=70853517

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2019/016624 WO2020111836A1 (ko) 2018-11-28 2019-11-28 무선 통신 시스템에서 동작하는 방법 및 장치

Country Status (2)

Country Link
US (1) US11968741B2 (ko)
WO (1) WO2020111836A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023004555A1 (zh) * 2021-07-26 2023-02-02 北京小米移动软件有限公司 行为控制方法和装置

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115665866A (zh) * 2018-12-10 2023-01-31 华为技术有限公司 一种通信方法、装置及计算机可读存储介质
US11251888B1 (en) * 2020-12-18 2022-02-15 Itron, Inc. Preserving battery life in poor signal conditions using RF link analysis
US11638215B2 (en) 2020-12-18 2023-04-25 Itron, Inc. Techniques for preserving battery life in poor signal conditions using cellular protocol information
US11818796B1 (en) * 2021-07-22 2023-11-14 T-Mobile Innovations Llc Distributed computing across a wireless communications network

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101175217B1 (ko) * 2008-04-30 2012-08-21 후아웨이 테크놀러지 컴퍼니 리미티드 자원 처리 방법, 통신 시스템, 및 이동성 관리 요소
KR20130034641A (ko) * 2011-09-28 2013-04-05 삼성전자주식회사 이동 통신 시스템에서 무선 네트워크 배치 상태 테스트 프로세스 수행 장치 및 방법
US20140204908A1 (en) * 2011-08-30 2014-07-24 Telefonaktiebolaget L M Ericsson (Publ) Methods of and nodes for selecting a target core network for handing over a voice session of a terminal
KR20150099367A (ko) * 2014-02-20 2015-08-31 삼성전자주식회사 영상통화 서비스 품질을 높이는 방법 및 장치

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10728812B2 (en) * 2016-08-11 2020-07-28 Lg Electronics Inc. Method and apparatus for supporting MBMS service continuity
US11064555B2 (en) * 2016-11-09 2021-07-13 Lg Electronics Inc. Method for transmitting RRC message and wireless device
TWI643508B (zh) * 2016-12-22 2018-12-01 張恭維 用於物聯網智能設備的智慧路由系統
US10772064B2 (en) * 2017-02-02 2020-09-08 Apple Inc. Positioning enhancements for narrowband internet of things
WO2018195787A1 (en) * 2017-04-26 2018-11-01 Qualcomm Incorporated Enhanced machine type communications quick idle transition after connection release
WO2018201451A1 (zh) * 2017-05-05 2018-11-08 华为技术有限公司 一种设备接入方法、用户设备及网络设备
CN109246766B (zh) * 2017-06-15 2023-05-30 夏普株式会社 无线配置方法和相应的用户设备
WO2019029688A1 (en) * 2017-08-11 2019-02-14 Mediatek Inc. AUTONOMOUS EU LIBERATION FOR THE INTERNET OF OBJECTS
WO2019064260A1 (en) * 2017-09-29 2019-04-04 Telefonaktiebolaget Lm Ericsson (Publ) SYSTEMS AND METHODS PROVIDING A SLEEP-BASED EARLY DATA TRANSMISSION SOLUTION FOR ENERGY SAVING MODE
WO2019074418A1 (en) * 2017-10-10 2019-04-18 Telefonaktiebolaget Lm Ericsson (Publ) NETWORK NODE, USER EQUIPMENT (UE) AND METHODS CARRIED OUT THEREIN

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101175217B1 (ko) * 2008-04-30 2012-08-21 후아웨이 테크놀러지 컴퍼니 리미티드 자원 처리 방법, 통신 시스템, 및 이동성 관리 요소
US20140204908A1 (en) * 2011-08-30 2014-07-24 Telefonaktiebolaget L M Ericsson (Publ) Methods of and nodes for selecting a target core network for handing over a voice session of a terminal
KR20130034641A (ko) * 2011-09-28 2013-04-05 삼성전자주식회사 이동 통신 시스템에서 무선 네트워크 배치 상태 테스트 프로세스 수행 장치 및 방법
KR20150099367A (ko) * 2014-02-20 2015-08-31 삼성전자주식회사 영상통화 서비스 품질을 높이는 방법 및 장치

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
QUALCOMM INCORPORATED: "CN type indication in RRC Connection Release Message", R2-1812747 . 3GPP TSG RAN WG2 MEETING #103, 10 August 2018 (2018-08-10), Gothenburg , Sweden, XP051522341 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023004555A1 (zh) * 2021-07-26 2023-02-02 北京小米移动软件有限公司 行为控制方法和装置

Also Published As

Publication number Publication date
US20220132622A1 (en) 2022-04-28
US11968741B2 (en) 2024-04-23

Similar Documents

Publication Publication Date Title
WO2020111836A1 (ko) 무선 통신 시스템에서 동작하는 방법 및 장치
WO2016013901A1 (ko) 단말 간 통신을 지원하는 무선 통신 시스템에서 파워 제어 방법 및 이를 위한 장치
WO2020145780A1 (ko) Nr v2x에서 기지국에 의해 할당된 자원을 기반으로 사이드링크 통신을 수행하는 방법 및 장치
WO2021033946A1 (ko) 무선 통신 시스템에서 단말이 임의 접속 과정을 수행하기 위한 신호를 송수신하는 방법 및 이를 위한 장치
WO2020180032A1 (ko) Nr v2x에서 psfch를 전송하는 방법 및 장치
WO2021086084A1 (ko) 무선 통신 시스템에서 무선 신호 송수신 방법 및 장치
WO2021230729A1 (ko) 무선 통신을 위한 신호 송수신 방법 및 이를 위한 장치
WO2021071234A1 (ko) Nr v2x에서 psfch 자원을 선택하는 방법 및 장치
WO2020226408A1 (ko) 사이드링크 전송을 위한 자원에 관한 정보
WO2020167059A1 (ko) 무선 통신 시스템에서 신호를 송수신하는 방법 및 이를 지원하는 장치
WO2022154637A1 (ko) 무선 통신 시스템에서 신호 송수신 방법 및 장치
WO2021182916A1 (ko) Nr v2x에서 사이드링크 통신을 위한 전력을 절약하는 방법 및 장치
WO2021033944A1 (ko) 무선 통신 시스템에서 단말이 임의 접속 과정을 수행하는 방법 및 이를 위한 장치
WO2020180172A1 (en) Method of performing random access procedure, and transmitting device, apparatus and storage medium therefor
WO2022071755A1 (ko) 무선 통신 시스템에서 무선 신호 송수신 방법 및 장치
WO2020032530A1 (en) Method of transmitting uplink signals, and device therefor
WO2021040433A1 (ko) Nr v2x에서 동기화를 수행하는 방법 및 장치
WO2022086174A1 (ko) 무선 통신 시스템에서 무선 신호 송수신 방법 및 장치
WO2021230728A1 (ko) 무선 통신을 위한 신호 송수신 방법 및 이를 위한 장치
WO2021187797A1 (ko) Nr v2x에서 단말이 슬립 모드로 진입하는 방법 및 장치
WO2021040239A1 (ko) Nr v2x에서 s-ssb를 송수신하는 방법 및 장치
WO2020204566A1 (ko) 무선 통신 시스템에서 사이드링크 통신을 위한 제어 정보를 송수신하는 방법 및 대역 부분
WO2020204565A1 (ko) 무선 통신 시스템에서 사이드링크 통신을 위한 제어 정보를 송수신하는 방법 및 장치
WO2022270899A1 (en) Method and apparatus for small data transmission in a wireless communication system
WO2022149853A1 (ko) 무선 통신 시스템에서 상태 천이를 처리하기 위한 방법 및 장치

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: 19891567

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19891567

Country of ref document: EP

Kind code of ref document: A1