WO2018143728A1 - 통신시스템에서의 데이터 처리 방법 - Google Patents

통신시스템에서의 데이터 처리 방법 Download PDF

Info

Publication number
WO2018143728A1
WO2018143728A1 PCT/KR2018/001457 KR2018001457W WO2018143728A1 WO 2018143728 A1 WO2018143728 A1 WO 2018143728A1 KR 2018001457 W KR2018001457 W KR 2018001457W WO 2018143728 A1 WO2018143728 A1 WO 2018143728A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
information
pdcp
format
transmitter
Prior art date
Application number
PCT/KR2018/001457
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
Priority claimed from KR1020170015192A external-priority patent/KR102721539B1/ko
Application filed by 삼성전자 주식회사 filed Critical 삼성전자 주식회사
Priority to US16/481,032 priority Critical patent/US11122463B2/en
Publication of WO2018143728A1 publication Critical patent/WO2018143728A1/ko

Links

Images

Classifications

    • 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/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1614—Details of the supervisory signal using bitmaps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • 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/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1642—Formats specially adapted for sequence numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/36—Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053—Allocation of signaling, i.e. of overhead other than pilot signals
    • H04L5/0055—Physical resource allocation for ACK/NACK
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/28—Timers or timing mechanisms used in protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08—Upper layer protocols
    • 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
    • H04L2001/0092—Error control systems characterised by the topology of the transmission link
    • H04L2001/0097—Relays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02—Data link layer protocols

Definitions

  • the present invention relates to the transmission and reception of communication devices in a wireless communication system.
  • the present invention may refer to a Packet Data Convergence Protocol (PDCP) and a Radio Link Control (RLC) structure defined in 3GPP.
  • PDCP Packet Data Convergence Protocol
  • RLC Radio Link Control
  • a 5G communication system or a pre-5G communication system is called a system after a 4G network (Beyond 4G Network) or a system after an LTE system (Post LTE).
  • 5G communication systems are being considered for implementation in the ultra-high frequency (mmWave) band (eg, such as the 60 Gigabit (60 GHz) band).
  • mmWave ultra-high frequency
  • FD-MIMO massive array multiple input / output
  • FD-MIMO massive array multiple input / output
  • Array antenna, analog beam-forming, and large scale antenna techniques are discussed.
  • 5G communication systems have advanced small cells, advanced small cells, cloud radio access network (cloud RAN), ultra-dense network (ultra-dense network) , Device to Device communication (D2D), wireless backhaul, moving network, cooperative communication, Coordinated Multi-Points (CoMP), and interference cancellation
  • cloud RAN cloud radio access network
  • ultra-dense network ultra-dense network
  • D2D Device to Device communication
  • wireless backhaul moving network
  • cooperative communication Coordinated Multi-Points (CoMP), and interference cancellation
  • Hybrid FSK and QAM Modulation FQAM
  • SWSC Slide Window Superposition Coding
  • ACM Advanced Coding Modulation
  • FBMC Fan Bank Multi Carrier
  • NOMA non orthogonal multiple access
  • SCMA sparse code multiple access
  • the Internet is evolving from a human-centered connection network in which humans create and consume information, and an Internet of Things (IoT) network that exchanges and processes information between distributed components such as things.
  • IoT Internet of Things
  • IoE Internet of Everything
  • M2M machine to machine
  • MTC Machine Type Communication
  • IoT Internet technology
  • IoT is a field of smart home, smart building, smart city, smart car or connected car, smart grid, health care, smart home appliances, advanced medical services, etc. through convergence and complex of existing information technology (IT) technology and various industries. It can be applied to.
  • technologies such as sensor network, machine to machine (M2M), machine type communication (MTC), and 5G communication technologies include beamforming, multiple input multiple output (MIMO), and array antennas. It is implemented by the technique of.
  • cloud radio access network cloud RAN as the big data processing technology described above may be an example of convergence of 5G technology and IoT technology.
  • the present invention solves the problem of processing a packet for a packet that has not been received at the receiving end through a setting method and a reporting method for reporting packet information discarded at the transmitting end to a receiving end in a wireless communication system. Provide a way to.
  • the present invention also provides a procedure and method for operating without data loss when a sequence number is changed in a wireless communication system.
  • a method of a transmitter in a wireless communication system for solving the above problems, driving a timer for a packet data convergence protocol (PDCP) packet, when the timer expires, the PDCP Discarding the packet and transmitting a report including information of the discarded PDCP packet to the receiver.
  • PDCP packet data convergence protocol
  • the method includes receiving a report including information of a discarded Packet Data Convergence Protocol (PDCP) packet from a transmitter, wherein the PDCP packet,
  • PDCP Packet Data Convergence Protocol
  • the timer for the PDCP packet is driven and may be discarded at the transmitter by expiration of the timer.
  • PDCP Packet Data Convergence Protocol
  • a timer for a transceiver and a Packet Data Convergence Protocol (PDCP) packet are driven, and when the timer expires, the PDCP packet is discarded. It may include a control unit for controlling the transceiver to transmit a report including the information of the discarded PDCP packet to the receiver.
  • PDCP Packet Data Convergence Protocol
  • a receiver in a wireless communication system according to an embodiment of the present invention, includes a transmitter, a transmitter and a receiver for transmitting configuration information about a report including information of a packet data convergence protocol (PDCP) packet, and the transmitter. And a control unit for controlling the transceiver to receive a report including information of discarded PDCP packets generated based on configuration information, wherein the PDCP packet includes a timer for driving the PDCP packet and an expiration of the timer. Can be discarded at the transmitter.
  • PDCP packet data convergence protocol
  • the delay time can be reduced.
  • 1 is a diagram illustrating a discard timer operation during an uplink data transmission operation.
  • FIG. 2 is a diagram illustrating a problem that may occur in NR when a data packet is discarded.
  • FIG. 3 is a diagram illustrating a setting method for transmitting Discard packet information proposed by the present invention.
  • FIG. 4 is a diagram illustrating an operation in the case of transmitting single Discard packet information.
  • FIG. 5 is a diagram illustrating a method of storing Discard Packet information when a Discard Timer expires in a transmitter.
  • FIG. 6 is a diagram illustrating a method of starting by using an event when a plurality of Discard packet information is transmitted.
  • FIG. 7 is a diagram illustrating a method in which an event expires when a plurality of Discard packet information is transmitted.
  • FIG. 8 is a diagram illustrating a method of transmitting Discard packet information when a NACK is received by a Tx terminal.
  • Discard Packet information when every Discard packet is generated.
  • FIG. 10 is a diagram illustrating an example of a structure for transmitting Discard Packet information when a plurality of Discard packets are generated.
  • FIG. 11 is a diagram illustrating an example of a method including transmission of Discard Packet information when a PDCP data transmission packet is used.
  • FIG. 12 is a diagram illustrating a method of using a Contiguous Number to transmit Discard Packet information when a plurality of Discard packets are generated.
  • FIG. 13 is a diagram illustrating a method of using Discarded Sequence Number Now and Discarded Sequence Number High to transmit Discard Packet information when a plurality of Discard packets are generated.
  • FIG. 14 is a diagram illustrating a method of using a bitmap to transmit Discard Packet information when a plurality of Discard packets are generated.
  • FIG. 15 is a diagram illustrating an example in which a bitmap size is reported in a method of using a bitmap to transmit discard packet information when a plurality of discard packets are generated.
  • 16 is a diagram illustrating a scenario in which a header format considered in the present invention is changed.
  • 17 is a diagram illustrating an embodiment of a message in which a header format is changed.
  • 18 is a diagram illustrating an embodiment of a method of retransmission when a format is changed.
  • FIG. 19 is a diagram illustrating an embodiment of a header format when the format of a header is changed in the embodiment of FIG. 18.
  • 20 illustrates another embodiment of a method of retransmission when a format is changed.
  • FIG. 21 is a diagram illustrating an embodiment of a header format when the format of a header is changed in the embodiment of FIG. 20.
  • FIG. 22 is a diagram illustrating a procedure for requesting processing by sending old format data to an old entity capable of processing the existing format when the processing of the existing format data is required after the reset. .
  • FIG. 23 is a diagram illustrating a PDCP COUNT structure in a 3GPP communication system.
  • 24 is a diagram illustrating an embodiment of a method of reordering using COUNT at reset.
  • 25 is a diagram illustrating another embodiment of changing an HFN value and a COUNT upon resetting.
  • FIG. 26 is a diagram illustrating an example of changing a header format according to an embodiment of the present invention.
  • FIG. 27 is a diagram illustrating an example of changing a header format according to an embodiment of the present invention.
  • 28 is a diagram illustrating a procedure of changing a header format for uplink data according to an embodiment of the present invention.
  • 29 is a diagram illustrating a procedure of changing a header format for downlink data according to an embodiment of the present invention.
  • FIG. 30 is a diagram illustrating a procedure of changing a header format for uplink data according to an embodiment of the present invention.
  • FIG. 31 is a diagram illustrating a procedure of changing a header format for downlink data according to an embodiment of the present invention.
  • FIG. 32 is a diagram illustrating a format of a status report message according to an embodiment of the present invention.
  • 33 is a diagram illustrating a format of a status report message according to an embodiment of the present invention.
  • FIG. 34 illustrates a format of a PDCP data PDU including a COUNT according to an embodiment of the present invention.
  • 35 illustrates a format of a PDCP data PDU including a PDCP sequence number (SN) according to an embodiment of the present invention.
  • FIG. 36 is a diagram illustrating a method of distinguishing and decoding PDCP data PDU formats of FIGS. 34-35 in a PDCP apparatus of a receiver according to an embodiment of the present invention.
  • FIG. 37 is a diagram illustrating a method of classifying and decoding PDCP data PDU formats of FIGS. 34-35 in a PDCP apparatus of a receiver according to an embodiment of the present invention.
  • FIG. 38 is a diagram illustrating a case in which a PDCP SN is changed due to a packet type reset in which a length of a PDCP SN is changed according to an embodiment of the present invention.
  • FIG. 39 is a diagram illustrating a procedure of retransmitting an unreceived packet after resetting a packet type of which a length of a PDCP SN is changed according to an embodiment of the present invention.
  • FIG. 40 is a diagram illustrating a case where a PDCP SN is changed due to a packet type reset in which the length of a PDCP SN is changed according to an embodiment of the present invention.
  • FIG. 41 is a diagram illustrating a procedure of retransmitting an unreceived packet after resetting a packet type of which the length of a PDCP SN is changed according to an embodiment of the present invention.
  • FIG. 42 is a diagram illustrating a procedure of retransmitting an unreceived packet after resetting a packet type of which a length of a PDCP SN is changed according to an embodiment of the present invention.
  • FIG. 43 is a view showing an embodiment of a procedure of retransmitting an unreceived packet after resetting a packet type of which a length of a PDCP SN is changed according to an embodiment of the present invention.
  • FIG. 44 is a view illustrating a procedure of retransmitting an unreceived packet after resetting a packet type whose length of a PDCP SN is changed according to an embodiment of the present invention.
  • 45 is a diagram illustrating a procedure of changing a COUNT after resetting a packet format according to an embodiment of the present invention.
  • 46 is a diagram illustrating a procedure for changing a COUNT after resetting a packet format according to an embodiment of the present invention.
  • 47 is a diagram illustrating a procedure of changing a COUNT after resetting a packet format according to an embodiment of the present invention.
  • FIG. 48 is a diagram illustrating a procedure of restarting a COUNT and changing a header format for uplink data according to an embodiment of the present invention.
  • 49 is a diagram illustrating a procedure of restarting a COUNT and changing a header format for downlink data according to an embodiment of the present invention.
  • FIG. 50 is a diagram illustrating a signal flow of a terminal and a base station when a COUNT is restarted and a header format is changed for uplink data according to an embodiment of the present invention.
  • FIG. 51 is a diagram illustrating a UE and BS signal flow when COUNT is restarted and a header format is changed for downlink data according to an embodiment of the present invention.
  • FIG. 52 is a diagram illustrating a procedure of restarting a COUNT and changing a header format for uplink data according to an embodiment of the present invention.
  • 53 is a diagram illustrating a procedure of restarting a COUNT and changing a header format for downlink data according to an embodiment of the present invention.
  • FIG. 54 is a diagram illustrating a change signal flow between a terminal and a base station when COUNT is restarted and a header format is changed for uplink data according to an embodiment of the present invention.
  • 55 is a view illustrating a flow of a change signal between a terminal and a base station when COUNT is restarted and a header format is changed for downlink data according to an embodiment of the present invention.
  • FIG. 56 is a view illustrating a procedure of retransmitting an unreceived packet after resetting a packet type whose length of a PDCP SN is changed according to an embodiment of the present invention.
  • 57 is a diagram illustrating a procedure of retransmitting an unreceived packet after resetting a packet type of which the length of a PDCP SN is changed according to an embodiment of the present invention.
  • each block of the flowchart illustrations and combinations of flowchart illustrations may be performed by computer program instructions. Since these computer program instructions may be mounted on a processor of a general purpose computer, special purpose computer, or other programmable data processing equipment, those instructions executed through the processor of the computer or other programmable data processing equipment may be described in flow chart block (s). It creates a means to perform the functions. These computer program instructions may be stored in a computer usable or computer readable memory that can be directed to a computer or other programmable data processing equipment to implement functionality in a particular manner, and thus the computer usable or computer readable memory. It is also possible for the instructions stored in to produce an article of manufacture containing instruction means for performing the functions described in the flowchart block (s).
  • Computer program instructions may also be mounted on a computer or other programmable data processing equipment, such that a series of operating steps may be performed on the computer or other programmable data processing equipment to create a computer-implemented process to create a computer or other programmable data. Instructions for performing the processing equipment may also provide steps for performing the functions described in the flowchart block (s).
  • each block may represent a portion of a module, segment, or code that includes one or more executable instructions for executing a specified logical function (s).
  • logical function e.g., a module, segment, or code that includes one or more executable instructions for executing a specified logical function (s).
  • the functions noted in the blocks may occur out of order.
  • the two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the corresponding function.
  • ' ⁇ part' used in the present embodiment refers to software or a hardware component such as an FPGA or an ASIC, and ' ⁇ part' performs certain roles.
  • ' ⁇ ' is not meant to be limited to software or hardware.
  • ' ⁇ Portion' may be configured to be in an addressable storage medium or may be configured to play one or more processors.
  • ' ⁇ ' means components such as software components, object-oriented software components, class components, and task components, and processes, functions, properties, procedures, and the like. Subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables.
  • components and the 'parts' may be combined into a smaller number of components and the 'parts' or further separated into additional components and the 'parts'.
  • the components and ' ⁇ ' may be implemented to play one or more CPUs in the device or secure multimedia card.
  • ' ⁇ part' may include one or more processors.
  • FIG. 1 is a diagram illustrating a Discard timer timer during an uplink data transmission operation in a transmitter.
  • IP Packet 1 is a diagram illustrating an embodiment of an LTE system during an uplink data transmission operation.
  • data eg, an IP packet
  • PDCP Packet Data Convergence Protocol
  • IP Packet 1 consists of PDCP SDU1
  • IP Packet2 consists of PDCP SDU2
  • IP Packet3 consists of PDCP SDU3.
  • the Discard Timer operates for each PDCP SDU.
  • the PDCP SDU1 Discard Timer is started at the time when the PDCP SDU1 is created, and the expiration time set as the Discard Timer at the time when the Discard Timer expires (for example, RRC (Radio Resource Control) to PDCP).
  • RRC Radio Resource Control
  • the time setting of the Discard Timer may be set through RRC (Radio Resource Control).
  • FIG. 2 is a diagram illustrating a problem that may occur in a wireless communication system when a data packet is discarded.
  • FIG. 2 is a diagram illustrating an example of a problem that may occur when PDCP packets are discarded in a wireless communication system (eg, an LTE system) during an uplink data transmission operation.
  • a wireless communication system eg, an LTE system
  • the transmitter transmits data by transmitting the PDCP packet to a lower layer through a radio link control (RLC) layer to a receiver.
  • RLC radio link control
  • the transmitter transmits PDCP packets 1 to 7 to the receiver, but the receiver may not receive the RLC or PDCP packets 3, 4, and 5 due to a channel environment.
  • the receiver may transmit NACK (Negative Acknowledgment) on RLC packet information 3 to 5 that are not received when the RLC mode is an acknowledgment mode (AM) in the RLC layer.
  • NACK Negative Acknowledgment
  • AM acknowledgment mode
  • some of the packets 3, 4, and 5 may be discarded because the Discard Timer expired.
  • PDCP packets 3, 4, and 5 may be discarded according to the expiration of the PDCP discard timer as described in FIG.
  • the transmitter receives packet information that the receiver did not receive from the receiver, but because the PDCP packet was discarded, the transmitter cannot retransmit the PDCP packet that the receiver did not receive.
  • the receiver may send a NACK to the transmitter indefinitely as a request for retransmission for the PDCP packet not received.
  • FIG. 3 is a diagram illustrating a setting method for transmitting Discard packet information proposed by the present invention.
  • FIG. 3 is a diagram illustrating a method in which a transmitter (for example, a terminal or a base station) sets up to transmit discarded packet information among data to be transmitted in uplink.
  • a transmitter for example, a terminal or a base station
  • the base station 31 When a discarded packet is generated among uplink data, when the discarded packet information is transmitted and in what format, the base station 31 sends a Discard Packet Indication setting message to the terminal. By transmitting (1), the terminal can set the time and method for transmitting the Discard Packet information.
  • the terminal 30 when a periodic type is set as a report time of discarded packet information transmission, the terminal 30 immediately transmits discard packet information to the base station 31 at the time when the discard packet is generated (2). can do.
  • an event type when an event type is set as a report type transmission time of a discarded packet information, the terminal 30 combines or schedules information of a discard packet for a predetermined time from a time when a discard packet is generated.
  • Discard Packet information can be transmitted (2) by a combination of the information of the Discard Packet. For example, if an Event is specified as a Timer, it can contain an Event and an Event Threshold Time, or if an Event is specified as a counting, it can contain an Event N-Counter Threshold. have.
  • the event threshold time embodiment may include an expiration time.
  • the terminal 30 may set a format for transmitting the Discard Packet.
  • the Discard Packet format is used to transmit Discard Packets, Discard Sequence Number or Low Discard Sequence Low, and Discard Packet High or Discard Sequence High, or Discard Sequence Sequence Count.
  • a method including a sequence contiguous number or discard sequence bitmap information may be set.
  • the configuration message for transmitting the discarded packet information may be transmitted as system information or transmitted through dedicated signaling.
  • the terminal 30 or the base station 31 may use Dedicated Signaling as a discarded packet report message.
  • Dedicated Signaling For example, an RRC message or a medium access control (MAC) message may be used. Or may be a PDCP message, or an RLC message.
  • MAC medium access control
  • FIG. 4 is a diagram illustrating an operation in the case of transmitting single Discard packet information.
  • FIG. 4 is a diagram illustrating a method for transmitting Discard Packet information when a Discard Packet occurs in the method proposed by the present invention.
  • the operation of FIG. 4 may be performed.
  • the transmitter (for example, the terminal or the base station) checks (1) the Discard Timer from the time when the packet is generated in the PDCP. Transmitter checks whether Discard Timer expires by checking Discard Timer (2), and Discard Timer Discard PDCP packet when it expires (3). In addition, the transmitter transmits Discarded PDCP packet information (eg, including sequence information of Discard Packet) to a Receiver (eg, a terminal or a base station).
  • Discard Timer eg, including sequence information of Discard Packet
  • FIG. 5 is a diagram illustrating a method of storing Discard Packet information when a Discard Timer expires in a transmitter.
  • FIG. 5 is a diagram illustrating a method for storing Discard Packet information when a Discard Timer for each packet operates and the Discard Timer expires.
  • the transmitter checks the Discard Timer from the time when the packet is generated in PDCP (1).
  • the transmitter checks whether the Discard Timer expires by checking the Discard Timer, and if it expires, the Discard Timer discards the PDCP packet that has expired, and sends the Discarded PDCP packet information (eg PDCP Sequence Number). Save (3).
  • FIG. 6 is a diagram illustrating a method of starting by using an event when a plurality of Discard packet information is transmitted.
  • FIG. 6 is a diagram illustrating a method for starting an event timer or N-counter to transmit Discard Packet information generated during a waiting time after waiting for a predetermined time on the basis of a time when a Discard Packet occurs in the method proposed by the present invention.
  • the operation of FIG. 6 when the Discard Packet transmission time type is an event or includes an event threshold time, the operation of FIG. 6 may be performed.
  • the Transmitter Discards the PDCP packet after the Discard Timer expires, and stores the Discarded PDCP packet information (eg, PDCP Sequence Number) (1). After storing the Discard Packet information, the transmitter checks whether there is previously Discarded Packet information (2). When there is no Discard Packet information previously generated, the transmitter starts a waiting timer (3).
  • the operation of FIG. 6 when the Discard Packet transmission time type is an event or when an event N-counter threshold is included, the operation of FIG. 6 may be performed.
  • the Transmitter Discards the PDCP packet after the Discard Timer expires, and stores the Discarded PDCP packet information (eg, PDCP Sequence Number) (1). After storing the Discard Packet information, the transmitter checks whether there is previously Discarded Packet information (2). The transmitter starts the N-Counter when there is no Discard Packet information previously generated (3).
  • FIG. 7 is a diagram illustrating a method for operating when an event expires when transmitting a plurality of Discard packet information.
  • FIG. 7 is a diagram illustrating an operation when a Discard Packet is generated after an Event is started in the method proposed by the present invention.
  • the operation of FIG. 7 may be performed.
  • Transmitter checks whether the waiting timer works (1) when discard packet occurs. Transmitter checks if Waiting Timer exceeds Event Threshold Time when Waiting Timer is in operation (2). Transmitter performs the operation of (1) again if Waiting Timer has not expired. In addition, when the waiting timer expires, the transmitter transmits the Discard Packet information stored during the waiting timer to the receiver through the operation of FIG. 6. In addition, the transmitter initializes the waiting timer after transmitting Discard Packet information to the receiver (3).
  • Transmitter checks the existence of N-Counter's operation (1) when Discard Packet occurs. Transmitter checks if N-Counter exceeds Event N-Counter Threshold when N-Counter operates (2). The transmitter may perform operation (3) when the condition is satisfied by comparing the N-Counter and the Event N-Counter Threshold.
  • the transmitter when the transmitter decreases the N-Counter, it may be determined that the condition is satisfied when it is less than or equal to the Event N-Counter Threshold. As another example, when the transmitter increases the N-Counter, it may be determined that the condition is satisfied when it is greater than or equal to the Event N-Counter Threshold. If the N-Counter event is not satisfied in the operation of (2), the operation of (1) is performed again after changing the value of the N-Counter. For example, you can decrease the N-Counter or increase the N-Counter. When the N-Counter event is satisfied, the transmitter transmits the Discard Packet information stored during the N-Counter to the receiver through the operation of FIG. 5. In addition, after transmitting the Discard Packet information to the receiver, the transmitter initializes the N-Counter (3).
  • FIG. 8 is a diagram illustrating a method of transmitting Discard packet information when a NACK is received by a transmitter.
  • the transmitter may know whether the receiver loses a packet through the NACK message of the receiver (1).
  • the NACK message sent by the receiver includes a sequence number of a packet.
  • the transmitter checks whether there is discard packet information corresponding to the sequence number included in the NACK message (2).
  • Discard Packet information may be stored by the method of FIG.
  • the transmitter transmits (3) corresponding Discard Packet information (eg, Packet Sequence Number) to the receiver.
  • the transmitter determines that the packet of the sequence number included in the NACK message is not discarded, and thus the packet of the sequence number included in the NACK message. To the receiver (4).
  • FIG. 9 illustrates an example of a structure for transmitting Discard Packet information when every Discard packet is generated.
  • FIG. 9 is a diagram illustrating a packet structure for transmitting single information of a discarded packet to a receiver when a discard packet occurs when a discard packet is generated.
  • the transmitter may apply the present embodiment when the Discard Packet information is directly transmitted to the receiver at the time when the Discard Packet is generated.
  • the Discard Packet information of FIG. 9 may include Discard Packet Indication (DPI) and Discard Packet Information (eg, Discarded Packet Sequence Number) which are indicators indicating Discard Packet information.
  • DPI Discard Packet Indication
  • Discard Packet Information eg, Discarded Packet Sequence Number
  • the transmitter may include a Discard Packet Format in a Discard Packet Reporting message and transmit the signal in Dedicated Signaling.
  • the dedicated signaling message may be an RRC message or a MAC message or a PDCP message, or an RLC message.
  • FIG. 10 is a diagram illustrating an example of a structure for transmitting Discard Packet information when a plurality of Discard packets are generated.
  • FIG. 10 is a diagram illustrating a packet structure for transmitting a plurality of pieces of information of a discarded packet to a receiver when a discard packet occurs when a discard packet occurs.
  • the transmitter may apply the present embodiment when the discard packet information is transmitted from the time when the discard packet is generated until the event expiration time.
  • the Discard Packet information of FIG. 10 may include a plurality of Discard Packet Indication (DPI) and Discard Packet information (eg, Discarded Packet Sequence Number) which are indicators indicating Discard Packet information.
  • DPI Discard Packet Indication
  • Discard Packet information eg, Discarded Packet Sequence Number
  • E Excard Packet Sequence Number
  • E Excard packet sequence
  • the transmitter may transmit the Discard Packet Format to the dedicated signaling by including the Discard Packet Reporting message.
  • the dedicated signaling message may be an RRC message or a MAC message or a PDCP message, or an RLC message.
  • 11 is a diagram illustrating an example of a method for transmitting including Discard Packet information when using a PDCP data transmission packet.
  • FIG. 11 is a diagram illustrating a structure in which a single or a plurality of Discard Packet information is included and transmitted using a PDCP data transmission packet.
  • the information that may be included may include an indicator (D / C) indicating whether a data packet or a control packet.
  • the information that may be included may include a plurality of Discard Packet Indication (DPI) and Discard Packet information (eg, Discarded Packet Sequence Number) which are indicators indicating that Discard Packet information is included.
  • the transmitter may indicate that there is a discard packet sequence through an expansion bit (E).
  • the PDCP data packet may include a DPI in the reserved bit in the PDCP data packet structure used in the LTE system to indicate whether the corresponding PDCP data packet is a packet including a discard sequence number.
  • the Discard Sequence Number may be included.
  • the transmitter may indicate that there is one or more discard packet sequences through an expansion bit (E).
  • FIG. 12 is a diagram illustrating a method of using a Contiguous Number to transmit Discard Packet information when a plurality of Discard packets are generated.
  • FIG. 12 is a diagram illustrating a packet structure for transmitting a plurality of pieces of information of a discarded packet to a receiver when a discard packet is generated when a discard packet is generated.
  • the transmitter may apply the present embodiment when the discard packet information is transmitted from the time when the discard packet is generated until the event expiration time.
  • the Discard Packet information of FIG. 12 may include a Discard Packet Indication (DPI), which is an indicator indicating Discard Packet information, and a start time Sequence Number of the Discarded Packet, and several Discard packets are generated through a continuous number. I can tell you.
  • DPI Discard Packet Indication
  • the transmitter may indicate that there is a starting point sequence of the discard packet through the expansion bit (E1), and may inform that there is a contiguous number (CN) of the discard packet through the expansion bit (E2).
  • the transmitter may transmit the Discard Packet Format to the dedicated signaling by including the Discard Packet Reporting message.
  • the dedicated signaling message may be an RRC message or a MAC message or a PDCP message, or an RLC message.
  • FIG. 13 is a diagram illustrating a method of using Discarded Sequence Number Low and Discarded Sequence Number High to transmit Discard Packet information when a plurality of Discard packets are generated.
  • FIG. 13 is a diagram illustrating a packet structure for transmitting a plurality of pieces of information of a discarded packet to a receiver when a discard packet occurs when a discard packet is generated.
  • the transmitter may apply the present embodiment when the discard packet information is transmitted from the time when the discard packet is generated until the event expiration time.
  • the Discard Packet information of FIG. 13 may include Discard Packet Indication (DPI), which is an indicator of Discard Packet information, and a Discarded Packet Low SN (Discarded SN Low), which is a start time Sequence Number of a Discarded Packet. Through the high number (Discarded SN High), the sequence at the end of Discard Packet can be informed.
  • DPI Discard Packet Indication
  • Discarded SN Low Discarded Packet Low SN
  • Discard SN Low is 3 and Discard SN High is 5, it can be seen that the receiver is Discarded for Discard Sequence Numbers 3, 4, and 5.
  • the transmitter may indicate that there is a Discard SN Low, which is the start point of the Discard packet, through the Expansion Bit (E1), and that the Discard SN High, which is a sequence number of the end point of the Discard packet, is located, via the Expansion Bit (E2). Can be.
  • the transmitter may transmit the Discard Packet Format to the dedicated signaling by including the Discard Packet Reporting message.
  • the dedicated signaling message may be an RRC message or a MAC message or a PDCP message, or an RLC message.
  • FIG. 14 is a diagram illustrating a method of using a bitmap to transmit Discard Packet information when a plurality of Discard packets are generated.
  • FIG. 14 is a diagram illustrating a packet structure for transmitting a plurality of pieces of information of a discarded packet to a receiver when a discard packet is generated when a discard packet is generated.
  • the transmitter may apply the present embodiment when the discard packet information is transmitted from the time when the discard packet is generated until the event expiration time.
  • the Discard Packet information of FIG. 14 may include Discard Packet Indication (DPI), which is an indicator of Discard Packet information, and Discarded SN, which is a start time Sequence Number of a Discarded Packet.
  • DPI Discard Packet Indication
  • Discarded SN which is a start time Sequence Number of a Discarded Packet.
  • the transmitter may provide bitmap information to inform which packet is discarded from the start of the sequence number. For example, when the Discarded SN is 3 and the Bitmap is 2 bits, when it is represented by 1110, the receiver may know that the Discarded Packet Sequence is 3, 4, or 5.
  • the transmitter may transmit the Discard Packet Format to the dedicated signaling by including the Discard Packet Reporting message.
  • the dedicated signaling message may be an RRC message or a MAC message or a PDCP message, or an RLC message.
  • FIG. 15 is a diagram illustrating an example in which a bitmap size is reported in a method of using a bitmap to transmit discard packet information when a plurality of discard packets are generated.
  • FIG. 15 is a diagram illustrating a packet structure for transmitting a plurality of pieces of information of a discarded packet to a receiver when a discard packet is generated when a discard packet is generated.
  • the transmitter may apply the present embodiment when the discard packet information is transmitted from the time when the discard packet is generated until the event expiration time. have.
  • the Discard Packet information of FIG. 15 may include Discard Packet Indication (DPI), which is an indicator indicating Discard Packet information, and Discarded SN, which is a start time Sequence Number of a Discarded Packet.
  • DPI Discard Packet Indication
  • Discarded SN which is a start time Sequence Number of a Discarded Packet.
  • the transmitter may provide bitmap information to inform which packet is discarded from the start of the sequence number. For example, when the Discarded SN is 3 and the Bitmap is 2 bits, if it is represented by 1110, the receiver may know that the Discarded Packet Sequence is 3, 4, or 5.
  • the Bitmap Size indicator can inform the bitmap size.
  • the transmitter may transmit the Discard Packet Format to the dedicated signaling by including the Discard Packet Reporting message.
  • the dedicated signaling message may be an RRC message or a MAC message or a PDCP message, or an RLC message.
  • FIG. 16 illustrates a scenario in which a header format considered in the present invention is changed.
  • the transmitter (TX) and the receiver (RX) communicate with the header of the old format, but after reconfiguration or configuration, they communicate in the new format. Done.
  • the reset or configuration may be changed by the RRC message of the 3GPP network or by a preset condition.
  • the environment in which the scenario as shown in FIG. 16 occurs may include a handover between heterogeneous networks (for example, when moving from a 5G network to a 4G network) or a handover to a base station having a different specification version from the same network (for example, a 3GPP Release 14 base station).
  • a handover between heterogeneous networks for example, when moving from a 5G network to a 4G network
  • a handover to a base station having a different specification version from the same network for example, a 3GPP Release 14 base station.
  • the size of the sequence number (SN) in the header may change.
  • the communication may be performed by performing communication using a header having a SN size of 12 bits and performing communication using a header having a SN size of 10 bits.
  • the 3GPP network reconfiguration message can be used to change the header format.
  • This message may include information about the type of header to be changed and which system to change to. If the reset is a message regarding handover between homogeneous or heterogeneous networks, information for performing handover may be included. In addition, if the reset message is well received at the terminal, the terminal may send a reconfiguration complete message to the base station after the reset. If this was a reset on the handover, it may send a reset complete message to the new base station after the handover.
  • FIG. 18 is a diagram for one embodiment of a method of retransmission when a format is changed.
  • the embodiment of FIG. 18 illustrates a method of transmitting data in the old format after the reset message is sent in the old format, and transmitting data in the new format after all the data in the old format are transmitted.
  • the transmitter TX transmits packets from SN 0 to 9 when performing communication in the existing format.
  • the receiver RX may receive an out-of-sequence packet differently from the order sent by the transmitter TX.
  • packets are received in the order of 0, 1, 4, 7, 5, and 8.
  • the sequence number used in the status report message may use an existing sequence number, a PDCP COUNT value, or a new sequence number.
  • the transmitter subsequently transmits 2, 3, 6, and 9 packets that have already been transmitted to the receiver.
  • the existing format data is used.
  • the transmitter specifies that the packet is an old packet in the Format (F) field of the header, so that the receiver can process the data in the existing format.
  • the format field may specify whether an existing packet or a new packet is present.
  • the format field may be displayed in a toggle method according to the format. For example, a packet of an existing format may be sent by setting the format field value to 0 and a packet of a new format by setting the format field value to 1.
  • the transmitter indicates that the packet is the last packet in the last packet indicator (LPI) field of the last packet sent in the existing format, so that other packets can be processed later in the new format.
  • the receiver combines the sequence number, the format field, and the LPI field to perform reordering, thereby enabling lossless communication.
  • SN new sequence number
  • FIG. 19 is an embodiment of a header format when the format of a header is changed in the embodiment of FIG. 18.
  • a format (F) field and an LPI field (LPI, Last Packet Indicator) required for the present invention are included.
  • D / C is a data / control information field
  • R is a reserved field
  • SN is a sequence number field
  • Data is a data field. 19 illustrates an embodiment in which an SN field is reduced when a header format is changed. However, the size of the SN field may be increased or may remain the same.
  • FIG. 20 shows another embodiment of a method of retransmission when a format is changed.
  • data transmission is immediately performed in a new format.
  • a method of performing data transmission by including an existing format packet in a new format with respect to the remaining transmission of a message sent in the existing format. Indicates.
  • the transmitter TX transmits packets from SN 0 to 9 when performing communication in the conventional format.
  • the receiver RX may receive an out-of-sequence packet in a different order from the send order.
  • packets are received in the order of 0, 1, 4, 7, 5, and 8.
  • the sequence number used in the status report message may use an existing sequence number, a PDCP COUNT value, or a new sequence number.
  • SN new format and a new sequence number
  • the packed packet may include a field indicating that the packed packet is packed in an encapsulation indicator (EI) field of the header.
  • EI encapsulation indicator
  • LPI last packet indicator
  • FIG. 21 is an embodiment of a header format when the format of a header is changed in the embodiment of FIG. 20.
  • an EI (Encapsulation Indicator) field and an LPI field (LPI, Last Packet Indicator) are required for the present invention based on the PDCP layer format of the 3GPP communication system.
  • D / C is a data / control information field
  • R is a reserved field
  • SN is a sequence number field
  • Data is a data field. If the EI field indicates that it is packed, the data field will contain the header and data in the existing format.
  • 21 illustrates an embodiment in which an SN field is reduced when a header format is changed. However, the size of the SN field may be increased or may remain the same.
  • FIG. 22 illustrates a procedure for requesting processing by sending old format data to an old entity capable of processing an existing format when data processing of the existing format is required after resetting.
  • the old device can process this data and send it to the new device, or it can do its own processing. If this is uplink transmission, the apparatus for processing the existing format and the apparatus for processing the new format may be different base station apparatuses.
  • COUNT has a fixed length and is divided into a Hyper Frame Number (HFN) field and an SN field.
  • HFN Hyper Frame Number
  • the size of the SN field is variable, but the length of COUNT is fixed.
  • the 3GPP communication system it has a COUNT length of 32 bits. Therefore, if the length of the SN field is N bits, HFN has a length of 32-N bits.
  • the present invention proposes a method of performing reordering using this COUNT value when the header format is changed in the present invention including FIG. 16.
  • the COUNT value is one of the values of the PDCP layer in the 3GPP communication system.
  • N is the length of the SN (N bits).
  • N-bit PDCP SN and HFN in the COUNT value is derived as follows.
  • Equation 1-3 The correspondence of Equation 1-3 is used in the embodiment of FIGS. 24-25.
  • FIG. 24 shows an embodiment of a method of reordering using COUNT at reset.
  • the existing format has a 5-bit SN size (0-31 SN) and the new format has a 4-bit SN size (0-15).
  • the PDCP window for reordering is typically assumed to be half of the total possible SN.
  • the transmitter After receiving the status report message after reset, the transmitter converts the packet into COUNT values (486,489, 490, 491, 492, 493, 494, 498) corresponding to the previous HFN and SN, and then the new format of HFN and SN.
  • the receiver may perform a reordering by converting a COUNT into a previous HFN, SN value, and a packet received before resetting, and converting a COUNT into a new HFN, SN value.
  • the 25 illustrates another embodiment of changing the HFN value and the COUNT at reset.
  • the existing format has a 4-bit SN size (0-15 SN) and the new format has a 5-bit SN size (0-31).
  • the PDCP window for reordering is typically assumed to be half of the total possible SN.
  • 26-27 illustrate another scenario in which the header format considered in the present invention is changed.
  • TX and RX communicate with the header of the old format.
  • the TX and RX communicate with the temporary format afterwards.
  • New Format to communicate.
  • the reset or configuration may be changed by the RRC message of the 3GPP network or by a preset condition.
  • a reset or configuration scenario such as FIGS.
  • 26-27 occurs, handover between heterogeneous networks (for example, when moving from a 5G network to a 4G network) or a handover to a base station having a different specification version from the same network (for example, : May be changed from 3GPP Release 14 base station to Release 13 base station), or when the base station in the same base station determines.
  • heterogeneous networks for example, when moving from a 5G network to a 4G network
  • a handover to a base station having a different specification version from the same network for example, : May be changed from 3GPP Release 14 base station to Release 13 base station
  • the size of the sequence number (SN) in the header may change.
  • the size of the sequence number is relatively long, but the size of the sequence number is relatively short after using the temporary sequence number.
  • the communication may be performed by performing communication using a header having a SN size of 12 bits and performing communication using a header having a SN size of 10 bits.
  • the size of the sequence number is relatively short, but the size of the sequence number becomes relatively long after using the temporary sequence number.
  • the communication may be performed by performing communication using a header having a SN size of 12 bits and performing communication using a header having a SN size of 18 bits.
  • the temporary SN of FIGS. 26-27 may be used for lossless delivery of packets immediately after resetting or setting, and may be a PDCP COUNT value or another promised common size sequence number (SN).
  • SN common size sequence number
  • the change in the format of the header will be described interchangeably with the change in the SN length, but there is essentially no difference between them in the embodiment of the present invention.
  • Information about a certain time point for performing communication in the temporary format and communication information in a new format or condition information for determining a predetermined time point may be indicated through resetting or setting.
  • the old format of the embodiment of FIG. 28 may include a relatively long SN size and the new format may include a relatively short SN size. Or vice versa.
  • the temporary format may also be a PDCP COUNT value or another promised common size sequence number (SN).
  • the terminal 280 transmits the packet to the base station 281 in the old format (1). Thereafter, the terminal 280 receives a reconfiguration message from the base station 281 (2) and recognizes that it needs to be transmitted in a new format. At this time, in order to confirm the information of the packet received by the receiver, that is, the base station 281, a receiver status report message (Status report) is sent to the transmitter, that is, the terminal 280 (3). At this time, the PDCP device (Entity) of the base station 281 and the terminal 280 may play this role. The status report message contains information about which packets have been received, which packets have not been received or need retransmission.
  • the status report message may include a bitmap that indicates a sequence number or COUNT value that is not initially received and a reception status of a subsequent packet.
  • the detailed status report message is shown in FIGS. 32-33.
  • the terminal 280 may transmit packets 4, 5, and 6 in a temporary format as previously set, and then transmit packets 7 in a new format indicated in the reset message.
  • a packet having a SN or COUNT value larger than the FMS (First Missing SN) or FMC (First Missing COUNT) indicated in the status report message can be sent in a temporary format.
  • This fixed size may be the PDCP Window size used by the old format, or an integer multiple thereof. Since the transmitter, ie, the terminal 280, transmits the packet in a new format after transmitting in the temporary format, but undergoes retransmission on the radio channel, the base station 281 has an order of the temporary format data and the new format data. You can also mix and receive. In this case, an indicator is needed to distinguish whether the packet uses a temporary format to distinguish the header format.
  • the detailed header format is shown in FIGS. 34-35.
  • the old format of the embodiment of FIG. 29 may include a relatively long SN size and the new format may include a relatively short SN size. Or vice versa.
  • the temporary format may also be a PDCP COUNT value or another promised common size sequence number (SN).
  • the base station 291 transmits the packet to the terminal 290 in the old format (1). After receiving a reconfiguration message from the base station 291 (2), it is recognized that the transmission in a new format. At this time, in order to confirm the information of the packet received by the receiver, that is, the terminal 290, a receiver status report message (Status report) is sent to the transmitter, that is, the base station 291 (3). At this time, the PDCP device (Entity) of the base station 291 and the terminal 290 may play this role.
  • the status report message contains information about which packets have been received, which packets have not been received or need retransmission.
  • the status report message may include a bitmap that indicates a sequence number or COUNT value that is not initially received and a reception status of a subsequent packet.
  • the detailed status report message is shown in FIGS. 32-33. After transmitting the reset message, the base station 291 transmits the packet in a temporary format (4).
  • the base station 291 may transmit packets 5 and 6 in a temporary format as previously set, and then transmit packets 7 in a new format indicated in the reset message. At this time, a packet having a SN or COUNT value larger than the FMS (First Missing SN) or FMC (First Missing COUNT) indicated in the status report message can be sent in a temporary format.
  • This predetermined size may be as much as the PDCP window size used in the old format or an integer multiple thereof.
  • the transmitter i.e., the base station 291 transmits a packet in a new format after transmitting in a temporary format, but undergoes retransmission in a wireless channel, so the terminal 290 has a sequence of data in a temporary format and a new format. You can also mix and receive. In this case, an indicator is needed to distinguish whether the packet uses a temporary format to distinguish the header format.
  • the detailed header format is shown in FIGS. 34-35.
  • the old format of the embodiment of FIG. 30 may include a relatively long SN size and the new format may include a relatively short SN size. Or vice versa.
  • the temporary format may also be a PDCP COUNT value or another promised common size sequence number (SN).
  • the terminal 300 transmits the packet 1 to the first base station 301 in the old format. After receiving a reconfiguration message from the first base station 301 (2), it is recognized that the data should be transmitted to the second base station 302 in a new format. At this time, in order to confirm the information of the packet received by the existing receiver, that is, the first base station 301, a receiver status report message (Status report) is sent to the transmitter, that is, the terminal 300 (3).
  • Status report a receiver status report message
  • the first base station 301 may also send a status report message to the second base station 302 (4).
  • the second base station 302 may send the status report message to the terminal without the first base station 301 directly sending the status report message to the terminal.
  • the procedure for sending the status report message may be in charge of the PDCP device (Entity) of the base station and the terminal.
  • the status report message contains information about which packets have been received, which packets have not been received or need retransmission.
  • the status report message may include a bitmap that indicates a sequence number or COUNT value that is not initially received and a reception status of a subsequent packet. The detailed status report message is shown in FIGS. 32-33.
  • the terminal 300 After receiving the reset message, the terminal 300 transmits the packet in a temporary format (5).
  • the terminal 300 may transmit packets 6 and 7 in a temporary format as previously set, and then transmit packets 8 in a new format indicated in the reset message.
  • a packet having a SN or COUNT value larger than the FMS (First Missing SN) or FMC (First Missing COUNT) indicated in the status report message can be sent in a temporary format.
  • This predetermined size may be as much as the PDCP window size used in the old format or an integer multiple thereof.
  • the transmitter i.e., the terminal 300 transmits the packet in a new format and then transmits the packet in a new format (9).
  • the base station mixes the data of the temporary format and the new format because the wireless channel undergoes retransmission. May be received.
  • an indicator is needed to distinguish whether the packet uses a temporary format to distinguish the header format.
  • the detailed header format is shown in FIGS. 34-35.
  • the old format of the embodiment of FIG. 31 may include a relatively long SN size and the new format may include a relatively short SN size. Or vice versa.
  • the temporary format may also be a PDCP COUNT value or another promised common size sequence number (SN).
  • the first base station 311 transmits the packet to the terminal 310 in the old format (1). Thereafter, the terminal 310 receives a reconfiguration message from the first base station 311 (2), and then recognizes that the second base station 312 should receive data in a new format. The first base station 311 performs data forwarding to the second base station (3).
  • a receiver status report message (Status report) is sent to a new transmitter, that is, the second base station 312 (4).
  • the procedure for sending the status report message may be in charge of the PDCP device (Entity) of the base station and the terminal.
  • the status report message contains information about which packets have been received, which packets have not been received or need retransmission.
  • the status report message may include a bitmap that indicates a sequence number or COUNT value that is not initially received and a reception status of a subsequent packet. The detailed status report message is shown in FIGS. 32-33.
  • the terminal 310 After receiving the reset message, the terminal 310 receives the packet in a temporary format.
  • the second base station 312 may transmit packets 5, 6, and 7 in a temporary format as previously set, and then transmit packets 8 in the new format indicated in the reset message.
  • a packet having a SN or COUNT value larger than the FMS (First Missing SN) or FMC (First Missing COUNT) indicated in the status report message can be sent in a temporary format.
  • This predetermined size may be as much as the PDCP window size used in the old format or an integer multiple thereof.
  • the transmitter that is, the second base station 312 transmits the packet in the new format after the transmission in the temporary format (9), but the retransmission occurs in the radio channel, so that the terminal mixes the data in the temporary format with the new format. May be received.
  • an indicator is needed to distinguish whether the packet uses a temporary format to distinguish the header format.
  • the detailed header format is shown in FIGS. 34-35.
  • the status report message may include a D / C field, a PDU Type field, a FMS (First Missing SN) field, a bitmap field, and the like.
  • the D / C field is an indicator indicating whether a corresponding PDU (protocol data unit, message, packet) is a data PDU or a control PDU. Since the status report message is a type of control PDU, it may be displayed as a value indicating the control message.
  • the PDU Type is a bit indicating the detailed type of the corresponding PDU and is assumed to be a 3-bit value in FIG. 32. According to an embodiment of the present invention, the PDU Type field may be displayed as a value indicating a status report message.
  • the FMS field is set to the sequence number value SN of the earlier packet among the sequence numbers of packets determined to have not been received by the receiver at the time when the status report message is transmitted or when the reset message or the setup message is received.
  • the sequence number at this time may be an old sequence number used before resetting, a new sequence number used after resetting, or a temporary sequence number.
  • the bitmap field is a bit indicating a reception / non-receipt status of a packet after the packet corresponding to the sequence number indicated in the FMS field.
  • the bitmap field may be set to 0 if not received and 1 (or vice versa). For example, if the sequence number indicated in the FMS is 5, the first bit of the bitmap field indicates the reception / unreceipt status of the packet corresponding to the sequence number 6, and the fifth bit of the bitmap field receives the packet corresponding to the sequence number 10. / Can be set to an expression indicating an unreceived state.
  • the status report message may include a D / C field, a PDU Type field, a FMC (First Missing COUNT) field, a bitmap field, and the like.
  • the D / C field is an indicator indicating whether a corresponding PDU (protocol data unit, message, packet) is a data PDU or a control PDU. Since the status report message is a type of control PDU, it may be displayed as a value indicating the control message.
  • the PDU Type is a bit indicating the detailed type of the corresponding PDU and is assumed to be a 3-bit value in FIG. 33.
  • the PDU Type field may be displayed as a value indicating a status report message.
  • the FMC field is set to a PDCP COUNT value of the earliest packet among PDCP COUNTs of a packet determined to have not been received by the receiver at the time when a status report message is transmitted or when a reset message or a configuration message is received.
  • the bitmap field is a bit indicating a received / not received state for a packet after a packet corresponding to the PDCP COUNT indicated in the FMC field.
  • the bitmap field may be set to 0 if not received and 1 (or vice versa).
  • the first bit of the bitmap field indicates the received / unreceived state of the packet corresponding to COUNT 6
  • the fifth bit of the bitmap field indicates the received / unreceived state of the packet corresponding to COUNT 10. It can be set to an expression representing.
  • the PDCP data PDU format may include a D / C field, an F field, an R field, a COUNT field, and a data field.
  • the D / C field is an indicator indicating whether a corresponding PDU (protocol data unit, message, packet) is a data PDU or a control PDU.
  • the D / C field of the PDCP data PDU may be indicated by a value indicating the data PDU.
  • the F field indicates whether or not this data PDU contains a temporary number sequence number.
  • COUNT is used as the sequence number. If the embodiment of Fig. 34 is used in the temporary format, the F field may be set to a value indicating the temporary format.
  • the R field is a reserved field that is not used as a specific value, and the COUNT field indicates a PDCP COUNT value of the corresponding PDU.
  • the data field may be a value encrypted with a PDCP SDU (Service Data Unit).
  • a MAC-I field for integrity protection may be added.
  • the PDCP data PDU format may include a D / C field, an F field, an R field, a PDCP sequence number (SN) field, a data field, and the like.
  • the D / C field is an indicator indicating whether a corresponding PDU (protocol data unit, message, packet) is a data PDU or a control PDU.
  • the D / C field of the PDCP data PDU may be indicated by a value indicating the data PDU.
  • the F field indicates whether or not this data PDU contains a temporary number sequence number. If the embodiment of Fig. 35 is used in the temporary format, the F field may be set to a value indicating the temporary format.
  • the temporary format may be a format using a PDCP SN as shown in FIG. 35.
  • the R field is a reserved field that is not used as a specific value, and the PDCP SN field indicates a PDCP sequence number value of the corresponding PDU.
  • the data field may be a value encrypted with a PDCP SDU (Service Data Unit).
  • a MAC-I field for integrity protection may be added.
  • FIG. 36 illustrates a method of distinguishing and decoding PDCP data PDU formats of FIGS. 34-35 in a PDCP apparatus of a receiver.
  • the receiver may reset (1, 2) the header format including the sequence number and the sequence number.
  • the receiver then sends a status report message to the transmitter, which can then retransmit the packet.
  • the receiver After resetting the sequence number, the receiver resumes packet reception (3) and distinguishes whether the received data PDU has a format including COUNT of FIG. 34 or a reset PDCP SN of FIG. At this time, the value of the F field of FIGS. 34-35 may be distinguished (4) whether the format includes COUNT or the format including a reset new PDCP SN. If the PDCP data PDU in the form of COUNT is included, the packet can be decoded (5) by judging that the form is included in COUNT. Otherwise, the packet can be decoded (6) in the new format including the reset PDCP SN. .
  • FIG. 37 illustrates a method of classifying and decoding PDCP data PDU formats of FIGS. 34-35 in a PDCP apparatus of a receiver.
  • the receiver may reset (1, 2) the header format including the sequence number and the sequence number.
  • the receiver then sends a status report message to the transmitter, which can then retransmit the packet.
  • the receiver After resetting the sequence number, the receiver resumes packet reception (3) and distinguishes whether the received data PDU is in a format including a temporary PDCP SN or a reset PDCP SN.
  • the value of the F field of FIG. 35 may be used to distinguish whether the format includes the temporary PDCP SN or the reset PDCP SN. If the PDCP data PDU in the form of a temporary PDCP SN is included, the packet may be decoded (5) by judging that the PDCP SN is included in a temporary format. Otherwise, the packet may be decoded in a new format including a reset PDCP SN. Can be decoded (6).
  • FIG. 38 shows an embodiment in which the PDCP SN is changed by reconfiguring a packet format in which the length of the PDCP SN is changed.
  • the existing format has a 7-bit SN size (0-127 SN) and the new format has a 5-bit SN size (0-31 SN).
  • PDCP COUNT 8500033, 8500034, 8500038, 8500043, 8500055, 8500059, 8500065, 8500066, 8500069, 8500070, 8500071 and subsequent packets in the PDCP device of the receiver are not received at the time of reset. Assume that it is a state.
  • These packets need to be retransmitted after resetting, and may be sent with a header including one of PDCP COUNT, temporary SN, and new SN.
  • the HFN value of the existing format of these packets is equal to 66407 and the PDCP SN corresponds to the values of 65, 66, 70, 75, 87, 91, 97, 98, 101, 102, 103, and then PDCP SN.
  • the unreceived packets correspond to the new PDCP SN values 1,2,6,11,23,27 (HFN 265626), 1,2,5,6,7 (HFN 265627) and subsequent PDCP SN values. .
  • FIG. 39 illustrates an embodiment of a procedure in which an unreceived packet is retransmitted after reconfiguring a packet type whose length of a PDCP SN is changed.
  • the Status Report may be transmitted from the receiver to the transmitter and may include the FMC and the bitmap as shown in the embodiment of FIG. 33 or may include the FMS and the bitmap as shown in the embodiment of FIG. have.
  • FIG. 39 it is assumed that it is transmitted in a status report of FIG. 33 including an FMC and a bitmap.
  • the FMC displays the COUNT value of the packet with the smallest COUNT value among the unreceived packets, and 8500033 is displayed.
  • the packet after this packet is indicated by the bitmap to indicate the reception status.
  • 0 is indicated when not received, and 1 when received.
  • the bitmap may be represented as 01110 11110 11111 11111 10111 01111 10011.
  • bit 0 indicates that the COUNT value is 8500034, 8500038, 8500043, 8500055, 8500059, 8500065, and 8500066 is not received and indicates that the PDCP COUNT is 8500068.
  • the transmitter performs retransmission of unreceived packets.
  • the packet is transmitted in the form of PDU including PDCP COUNT of FIG. 34 for these packets. Packets marked COUNT like this do not cause HFN desynchronization. Subsequently, packets corresponding to PDCP COUNT 8500069 or more are transmitted using the new SN value of 5.
  • the packets are transmitted using PDCP COUNT values only up to unreceived packets (COUNT 8500066 in the above embodiment) included in a status report message, but this time point may be changed to another preset time point.
  • a packet including a COUNT may be transmitted from a COUNT value (COUNT 8500068 in the above embodiment) of a packet indicated as received in a status report message to a packet having a PDCP COUNT as high as a predetermined value.
  • the constant value may be the PDCP receiving window size corresponding to the new type PDCP SN.
  • Receive Window Size is 2 ( PDCP It can also be used as SN size-1) .
  • FIG. 40 illustrates an embodiment in which the PDCP SN is changed by reconfiguring a packet format in which the length of the PDCP SN is changed.
  • an existing format has a 7-bit SN size (0-127 SN) and a new format has a 5-bit SN size (0-31 SN).
  • PDCP COUNT 8500033, 8500034, 8500038, 8500043, 8500055, 8500059, 8500065, 8500066, 8500069, 8500070, 8500071 and subsequent packets in the PDCP device of the receiver are not received at the time of resetting. Assume that it is a state. These packets need to be retransmitted after resetting, and may be sent with a header including one of PDCP COUNT, temporary SN, and new SN.
  • the HFN value of the existing format of these packets is equal to 66407 and the PDCP SN corresponds to the values of 65, 66, 70, 75, 87, 91, 97, 98, 101, 102, 103, and then PDCP SN.
  • the unreceived packets correspond to the new types of PDCP SN values 1,2,6,11,23,27 (HFN 265626), 1,2,5,6,7 (HFN 265627) and subsequent PDCP SN values. At this time, there may be packets having the same PDCP SN value. This same PDCP SN value may cause HFN desynchronization.
  • a packet corresponding to COUNT 8500033 and a packet corresponding to COUNT 8500065 correspond to PDCP SN 1
  • the packet corresponding to COUNT 8500034 and the packet corresponding to COUNT 8500066 correspond to PDCP SN 2
  • a packet may be transmitted using a header including a temporary SN for specific packets. This can accurately determine the HFN value.
  • the temporary SN value can be used as a value large enough to accurately determine the HFN value.
  • the size of the temporary SN is assumed to be 22 bits. Therefore, in the embodiment of FIG. 40, the temporary SN of the unreceived packet at the reset time point may correspond to 111425, 111426, 111430, 111435, 111447, 111451, 111457, 111458, 111461, 111462, 111463 and more SN values.
  • the temporary HFN value for the temporary SNs may be two. The relationship between the HFN and the SN value follows Equation 1-3 above.
  • FIG. 41 illustrates an embodiment of a procedure in which an unreceived packet is retransmitted after reconfiguring a packet type whose length of a PDCP SN is changed.
  • the Size of the PDCP SN is changed from 7 bits to 5 bits due to reconfiguration.
  • the packet reception situation is the same as that of FIG. 40. Therefore, at this time, the Status Report may be transmitted from the receiver to the transmitter and may include the FMC and the bitmap as shown in the embodiment of FIG. 33 or may include the FMS and the bitmap as shown in the embodiment of FIG. have.
  • FIG. 41 it is assumed that it is transmitted in a status report of FIG. 33 including an FMC and a bitmap.
  • the FMC displays the COUNT value of the packet with the smallest COUNT value among the unreceived packets, and 8500033 is displayed. If the temporary SN value is used as FMS, 111425 may be indicated.
  • the packet after this packet is indicated by the bitmap to indicate the reception status. In the example of FIG. 41, 0 is indicated when not received, and 1 when received. Accordingly, the bitmap may be represented as 01110 11110 11111 11111 10111 01111 10011. That is, it can indicate that packets with COUNT values of 8500034, 8500038, 8500043, 8500055, 8500059, 8500065, and 8500066 are not received and have received the packet with PDCP COUNT of 8500068.
  • the transmitter performs retransmission of unreceived packets.
  • the packet is transmitted in the PDU format including the temporary PDCP SN among the PDU format including the PDCP SN of FIG. Packets marked with this temporary PDCP SN do not have HFN desynchronization. Subsequently, packets corresponding to PDCP COUNT 8500069 or more are transmitted using the new SN value of 5.
  • a packet including a temporary PDCP SN may be transmitted from a COUNT value (8500068 in the above embodiment) of a packet indicated as received in a status report message to a packet having a PDCP COUNT as high as a predetermined value.
  • the constant value may be the PDCP receiving window size corresponding to the new type PDCP SN.
  • Receive Window Size is 2 ( PDCP It can also be used as SN size- 1) .
  • FIG. 42 illustrates an embodiment of a procedure in which an unreceived packet is retransmitted after resetting a packet type of which the length of a PDCP SN is changed.
  • the Size of the PDCP SN is changed from 7 bits to 5 bits due to reconfiguration.
  • the packet reception situation is the same as the reception situation of FIG. 40.
  • the Status Report can be transmitted from the receiver to the transmitter and include the FMC and the bitmap as shown in the embodiment of FIG. 33 or include the FMS and the bitmap as shown in the embodiment of FIG. Can be.
  • FIG. 42 it is assumed that it is transmitted in a status report of FIG. 33 including an FMC and a bitmap.
  • the FMC displays the COUNT value of the packet with the smallest COUNT value among the unreceived packets, and 8500033 is displayed.
  • the packet after this packet is indicated by the bitmap to indicate the reception status.
  • 0 is indicated when unreceived, and 1 when received.
  • the bitmap may be represented as 01110 11110 11111 11111 10111 01111 10011. That is, it can indicate that packets with COUNT values of 8500034, 8500038, 8500043, 8500055, 8500059, 8500065, and 8500066 are not received and have received the packet with PDCP COUNT of 8500068.
  • the transmitter performs retransmission of unreceived packets.
  • the packet is transmitted in the PDU format including the new PDCP SN among the PDU format including the PDCP SN of FIG.
  • the F fields of FIGS. 34 to 35 may not be used.
  • HFN asynchronous may occur. However, this can be solved by using the delayed transmission scheme of FIGS. 43-44.
  • FIG. 43 illustrates an embodiment of a procedure in which an unreceived packet is retransmitted after a packet format reset in which a length of a PDCP SN is changed.
  • the size of the PDCP SN is changed from 7 bits to 5 bits due to reconfiguration.
  • the packet reception situation is the same as the reception condition of FIG. 40, and the description of the retransmitted packet is described in FIG. 41. Is the same as In the embodiment of FIG. 43, after transmitting a packet having a specific PDCP SN, a packet having a different HFN value among packets corresponding to the same PDCP SN is transmitted after a set timer time.
  • a packet corresponding to COUNT 8500033 which is the first packet among packets having a PDCP SN value of 1, is transmitted, and then a packet corresponding to COUNT 8500065 having the same PDCP SN is transmitted after a set timer time. do.
  • the timer may be indicated in a reset or set message or instruct to use a preset value.
  • the timer value may be set such that HFN asynchronous of different packets having the same PDCP SN does not occur, and may be set to a PDCP reordering timer length according to an embodiment.
  • the timer may be set for all PDCP packets, but in some cases, may be set for some packets transmitted after the reset.
  • FIG. 44 illustrates an embodiment of a procedure in which an unreceived packet is retransmitted after a packet format reset in which a length of a PDCP SN is changed.
  • the size of the PDCP SN is changed from 7 bits to 5 bits due to reconfiguration.
  • the packet reception situation is the same as the reception condition of FIG. 40, and the description of the retransmitted packet is described in FIG. 41. Is the same as In the embodiment of FIG. 44, after the transmitter transmits a packet having a specific PDCP SN, transmission of a corresponding packet after a set sequence number interval after this packet or a corresponding packet after a COUNT interval set after this packet is performed after a set timer time. It is characterized by.
  • the timer may be indicated in a reset or set message or instruct to use a preset value.
  • the timer value may be set such that HFN asynchronous of different packets having the same PDCP SN does not occur, or may be set to a PDCP Reordering Timer length according to an embodiment.
  • the interval (eg, sequence number interval or COUNT interval) of the packet delaying the transmission by the timer may be a preset value. This set value may be a PDCP reception window.
  • the COUNT value may be maintained even after the reset, but according to the embodiment, the COUNT value may be reset and may start from the initial value. In the embodiment of FIG. 45, it is assumed that packets corresponding to COUNT 5014, 5015, 5019, 5023, 5024 and subsequent values are not received at the reset time.
  • the receiver may transmit a bitmap for FMC or FMS value and subsequent packet reception in a status report message.
  • the PDCP COUNT value of the packet corresponding to the FMC or FMS value of the status report message may be reset to zero.
  • a COUNT value of a packet corresponding to an existing COUNT 5014 is reset to zero.
  • the packet corresponding to the changed COUNT 0,1,5,9,10 and more COUNT values may be reset to an unreceived state and retransmission procedure may be performed.
  • the COUNT value may be maintained even after the reset, but according to the embodiment, the COUNT value may be reset and may start from the initial value. In the embodiment of FIG. 46, it is assumed that packets corresponding to COUNT 5014, 5015, 5019, 5023, 5024 and subsequent values are not received at the reset time.
  • the receiver may transmit the FMC or FMS value in a status report message.
  • a bitmap may be transmitted for receiving a packet later.
  • the PDCP COUNT value of the packet corresponding to the FMC or FMS value of the status report message may be reset to zero.
  • packets from which the reset COUNT value is 0 to subsequent packets are reset to the unreceived state and thus retransmission procedures may be performed.
  • the COUNT value may be maintained even after the reset, but according to the embodiment, the COUNT value may be reset and may start from the initial value. In the embodiment of FIG. 47, it is assumed that packets corresponding to COUNT 5014, 5015, 5019, 5023, 5024 and subsequent values are not received at the reset time.
  • the receiver may transmit a Last Missing COUNT (LMC) value or a Last Missing SN (LMS) value in a status report message.
  • LMC Last Missing COUNT
  • LMS Last Missing SN
  • the LMC value is set to 5023.
  • the LMC value represents the smallest COUNT value continuously determined as an unreceived COUNT without a COUNT value determined to be received by the receiver.
  • the LMS value represents the smallest SN value that is successively determined as an unreceived SN without an SN determined to be received by the receiver.
  • a bitmap on whether a packet is received later may be transmitted.
  • the PDCP COUNT value of the packet corresponding to the LMC or LMS value of the status report message may be reset to zero.
  • all packets from which the reset COUNT value is zero to subsequent packets may be updated as being in an unreceived state to perform a retransmission procedure.
  • FIG. 48 illustrates a procedure of restarting a COUNT and changing a header format for uplink data.
  • the old format of the embodiment of FIG. 48 may include a relatively long SN size and the new format may include a relatively short SN size. Or vice versa.
  • the terminal 480 transmits the packet to the base station 481 in the old format (1). Thereafter, the terminal 480 receives a reconfiguration message from the base station 481 (2), and recognizes that it needs to be transmitted in a new format. At this time, in order to check the information of the packet received by the receiver, that is, the base station 481, the receiver sends a status report message (Status report) to the transmitter, that is, the terminal 480 (3). At this time, the PDCP device (Entity) of the base station 481 and the terminal 480 may play this role.
  • the status report message contains information about which packets have been received, which packets have not been received or need retransmission.
  • the status report message may include a bitmap that indicates a sequence number or COUNT value that is not initially received and a reception status of a subsequent packet.
  • the detailed status report message is shown in FIGS. 32-33.
  • the terminal 480 resets COUNT after receiving the reset message and receiving the status report message. At this time, the packet corresponding to one of the FMS, FMC, LMS, and LMC values included in the status report message is reset to COUNT 0.
  • the method of resetting the COUNT to 0 may follow the procedure of one of FIGS. 45-47. Thereafter, the terminal 480 may transmit 5 an uplink packet to the base station 481 in a new format. In order to prevent HFN asynchronous, the UE may use the transmission method described in FIGS. 43-44. From this point, the base station 481 receives the packet 6 in a new format.
  • the old format of the embodiment of FIG. 49 may include a relatively long SN size and the new format may include a relatively short SN size. Or vice versa.
  • the base station 491 transmits the packet to the terminal 490 in the old format (1). Recognize that the packet after the base station sends a reconfiguration message (2) should be sent in a new format.
  • a receiver status report message (Status report) is sent to the transmitter, that is, the base station 491 (3).
  • the PDCP device (Entity) of the base station and the terminal may play this role.
  • the status report message contains information about which packets have been received, which packets have not been received or need retransmission.
  • the status report message may include a packet sequence number or a COUNT value not initially received and a bitmap indicating the reception status of subsequent packets. The detailed status report message is shown in FIGS. 32-33.
  • the base station 491 resets COUNT after transmitting the reset message and receiving the status report message. At this time, the packet corresponding to one of the FMS, FMC, LMS, and LMC values included in the status report message is reset to COUNT 0.
  • the method of resetting the COUNT to 0 may follow the procedure of one of FIGS. 45-47. Thereafter, the base station 491 may transmit 5 a downlink packet to the terminal in a new format. In order to prevent HFN asynchronous, the base station may use the transmission method described in FIGS. 43-44. From this point on, the terminal 490 receives the packet in a new format (6).
  • FIG. 50 shows UE and BS signal flows when the COUNT is restarted and the header format is changed for uplink data.
  • the old format of the embodiment of FIG. 50 may include a relatively long SN size and the new format may include a relatively short SN size. Or vice versa.
  • the terminal 500 transmits the packet to the first base station 501 in the old format. Thereafter, the terminal 500 receives a reconfiguration message from the base station (2) and recognizes that it needs to be transmitted in a new format. In the embodiment of FIG. 50, it is assumed that a reset message is received from the first base station 501. However, if the base station is able to send a reset message to the terminal, the message is not limited. At this time, in order to check the information of the packet received by the receiver, that is, the first base station 501, a receiver status report message (Status report) is sent to the transmitter, that is, the terminal 500 (3). At this time, the PDCP device (Entity) of the base station and the terminal may play this role.
  • a receiver status report message (Status report) is sent to the transmitter, that is, the terminal 500 (3).
  • the first base station 501 sends a status report message to the terminal 500
  • the first base station 501 transmits (4) a status report message to the second base station 502.
  • the second base station 502 may send a status report message to the terminal 501.
  • the status report message contains information about which packets have been received, which packets have not been received or need retransmission.
  • the status report message may include a sequence number or a COUNT value that was not initially received.
  • the status report message may include a bitmap indicating the reception status of the packet.
  • the detailed status report message is shown in FIGS. 32-33.
  • the terminal 500 receives the reset message and resets the COUNT after receiving the status report message (5). At this time, the packet corresponding to one of the FMS, FMC, LMS, and LMC values included in the status report message is reset to COUNT 0.
  • the method of resetting the COUNT to 0 may follow the procedure of one of FIGS. 45-47. Thereafter, the terminal 500 may transmit 6 an uplink packet to the second base station 502 in a new format. In order to prevent HFN asynchronous, the base station and the terminal may use the transmission method described in FIGS. 43-44. From this point on, the second base station 502 receives the packet 7 in a new format.
  • FIG. 51 illustrates UE and BS signal flows when COUNT is restarted for downlink data and the header format is changed.
  • the old format of the embodiment of FIG. 51 may include a relatively long SN size and the new format may include a relatively short SN size. Or vice versa.
  • the first base station 511 transmits the packet to the terminal 510 in the old format (1). Thereafter, the terminal 510 receives a reconfiguration message from the base station and recognizes that the terminal 510 needs to receive a reconfiguration message. In the embodiment of FIG. 51, it is assumed that a reset message is received from the first base station 511. However, if a base station capable of sending a reset message to the terminal 510 is not limited, the message is sent. The first base station 511 transfers data to the second base station 512.
  • the receiver that is, the terminal 510 sends a receiver status report message (Status report) to the transmitter, that is, the base station to check the information of the packet received.
  • the PDCP device Entity
  • the terminal 510 sends a status report message to the second base station 512 (4).
  • the terminal 510 transmits the status report message to the first base station 511.
  • a status report message may be sent to the second base station 512.
  • the status report message contains information about which packets have been received, which packets have not been received or need retransmission.
  • the status report message may include a sequence number or a COUNT value that was not initially received.
  • the status report message may include a bitmap indicating the reception status of the packet.
  • the detailed status report message is shown in FIGS. 32-33.
  • the second base station 512 resets COUNT after receiving the status report message. At this time, the packet corresponding to one of the FMS, FMC, LMS, and LMC values included in the status report message is reset to COUNT 0.
  • the method of resetting the COUNT to 0 may follow the procedure of one of FIGS. 45-47. Thereafter, the second base station 512 may transmit 6 the downlink packet to the terminal in a new format. In order to prevent HFN asynchronous, the base station and the terminal may use the transmission method described in FIGS. 43-44. From this time, the terminal 510 receives the packet 7 in a new format.
  • the old format of the embodiment of FIG. 52 may include a relatively long SN size and the new format may include a relatively short SN size. Or vice versa.
  • the terminal 520 transmits the packet to the base station 521 in the old format (1). Thereafter, the terminal 520 receives the reconfiguration message from the base station 521 (2), and recognizes that the packet should be transmitted in a new format. At this time, in order to check the information of the packet received by the receiver, that is, the base station 521, a receiver status report message (Status report) is sent to the transmitter, that is, the terminal 520 (3). At this time, the PDCP device (Entity) of the base station 521 and the terminal 520 may play this role.
  • the status report message contains information about which packets have been received, which packets have not been received or need retransmission.
  • the status report message may include a bitmap that indicates a sequence number or COUNT value that is not initially received and a reception status of a subsequent packet. The detailed status report message is shown in FIGS. 32-33.
  • the terminal 520 receives the reset message and resets the COUNT after receiving the status report message (4). At this time, the packet corresponding to one of the FMS, FMC, LMS, and LMC values included in the status report message is reset to COUNT 0.
  • the method of resetting the COUNT to 0 may follow the procedure of one of FIGS. 45-47.
  • the terminal 520 After resetting COUNT to 0, the terminal 520 transmits the packet in a temporary format (5).
  • the terminal 520 may transmit packets 6 and 7 in a temporary format as previously set, and then transmit packets 8 in a new format indicated in the reset message.
  • a packet having a SN or COUNT value larger than the FMS (First Missing SN) or FMC (First Missing COUNT) indicated in the status report message can be sent in a temporary format.
  • This predetermined size may be as much as the PDCP window size used in the old format or an integer multiple thereof.
  • the transmitter i.e., the terminal 520 transmits the packet in the new format after the transmission in the temporary format, but suffers retransmission in the wireless channel, so that the base station 521 has a sequence of the temporary format data and the new format data. You can also mix and receive. In this case, an indicator is needed to distinguish whether the packet uses a temporary format to distinguish the header format.
  • the detailed header format is shown in FIGS. 34-35.
  • the old format of the embodiment of FIG. 53 may include a relatively long SN size and the new format may include a relatively short SN size. Or vice versa.
  • the base station 531 transmits a packet to the terminal 530 in the old format (1). After the base station 531 sends a reconfiguration message (2), it recognizes that the packet should be sent in a new format. At this time, in order to check the information of the packet received by the receiver, that is, the terminal 530, a receiver status report message (Status report) is sent to the transmitter, that is, the base station 531 (3). At this time, the PDCP device (Entity) of the base station 531 and the terminal 530 may play this role.
  • the status report message contains information about which packets have been received, which packets have not been received or need retransmission.
  • the status report message may include a bitmap that indicates a sequence number or COUNT value that is not initially received and a reception status of a subsequent packet. The detailed status report message is shown in FIGS. 32-33.
  • the base station 531 resets COUNT after transmitting the reset message and receiving the status report message. At this time, the packet corresponding to one of the FMS, FMC, LMS, and LMC values included in the status report message is reset to COUNT 0.
  • the method of resetting the COUNT to 0 may follow the procedure of one of FIGS. 45-47.
  • the base station 531 After the base station 531 resets the COUNT to 0, the base station 531 transmits the packet in a temporary format (5).
  • the base station may transmit (6) and (7) the packet in a temporary format as previously set and subsequently transmit (8) the packet in the new format indicated in the reset message.
  • a packet having a SN or COUNT value larger than the FMS (First Missing SN) or FMC (First Missing COUNT) indicated in the status report message can be sent in a temporary format.
  • This predetermined size may be as much as the PDCP window size used in the old format or an integer multiple thereof.
  • the transmitter i.e., the base station 531, transmits the packet in the new format after the transmission in the temporary format (9) but undergoes retransmission in the wireless channel, so that the terminal 530 has a sequence of the data in the temporary format and the new format. You can also mix and receive. In this case, an indicator is needed to distinguish whether the packet uses a temporary format to distinguish the header format.
  • the detailed header format is shown in FIGS. 34-35.
  • the old format of the embodiment of FIG. 54 may include a relatively long SN size and the new format may include a relatively short SN size. Or vice versa.
  • the terminal 540 transmits the packet to the first base station 541 in the old format. Afterwards, the terminal 540 receives a reconfiguration message from the base station and recognizes that it needs to transmit a new format. In the embodiment of FIG. 54, it is assumed that the reset message is received from the first base station 541 (2). However, if the base station is able to send the reset message to the terminal, the message is not limited. At this time, in order to confirm the information of the packet received by the receiver, that is, the first base station 541, a receiver status report message (Status report) is sent to the transmitter, that is, the terminal 540 (3).
  • Status report is sent to the transmitter, that is, the terminal 540 (3).
  • the PDCP device (Entity) of the base station and the terminal may play this role.
  • the first base station 541 sends to the terminal 540
  • the second base station after the first base station 541 transmits (4) a status report message to the second base station 542.
  • 542 may send a status report message to the terminal 540.
  • the status report message contains information about which packets have been received, which packets have not been received or need retransmission.
  • the status report message may include a sequence number or a COUNT value that was not initially received.
  • the status report message may include a bitmap indicating the reception status of the packet. The detailed status report message is shown in FIGS. 32-33.
  • the terminal 540 receives the reset message and resets the COUNT after receiving the status report message (5). At this time, the packet corresponding to one of the FMS, FMC, LMS, and LMC values included in the status report message is reset to COUNT 0.
  • the method of resetting the COUNT to 0 may follow the procedure of one of FIGS. 45-47.
  • the terminal 540 After resetting the COUNT to 0, the terminal 540 transmits the packet in a temporary format (6).
  • the terminal 540 may transmit packets 7 and 8 in a temporary format as previously set, and then transmit packets 9 in a new format indicated in the reset message.
  • a packet having a SN or COUNT value larger than the FMS (First Missing SN) or FMC (First Missing COUNT) indicated in the status report message can be sent in a temporary format.
  • This predetermined size may be as much as the PDCP window size used in the old format or an integer multiple thereof.
  • the transmitter i.e., the terminal 540 transmits the packet in the new format after transmitting in the temporary format, but suffers retransmission in the wireless channel. You may receive a mix of orders. In this case, an indicator is needed to distinguish whether the packet uses a temporary format to distinguish the header format.
  • the detailed header format is shown in FIGS. 34-35.
  • FIG. 55 illustrates a change signal flow between a terminal and a base station when COUNT is restarted for downlink data and a header format is changed.
  • the old format of the embodiment of FIG. 55 may include a relatively long SN size and the new format may include a relatively short SN size. Or vice versa.
  • the first base station 551 transmits the packet to the terminal 550 in the old format (1). Afterwards, the terminal 550 receives a reconfiguration message from the base station and recognizes that the terminal 550 should receive it in a new format. The base station recognizes that it should transmit a reconfiguration message and send it in a new format. In the embodiment of FIG. 55, it is assumed that the reset message is received from the first base station 551 (2). However, if the base station is able to send the reset message to the terminal, the message is not limited. The first base station 551 transfers data to the second base station 552 (3).
  • the receiver that is, the terminal 550 sends a receiver status report message (Status report) to the transmitter, that is, the base station to check the information of the packet received.
  • the PDCP device Entity
  • the terminal 550 sends a status report message to the second base station 552 (4).
  • the first base station may send a status report message to the second base station 552.
  • the status report message contains information about which packets have been received, which packets have not been received or need retransmission.
  • the status report message may include a sequence number or a COUNT value that was not initially received.
  • the status report message may also include a bitmap indicating the reception status of the packet.
  • the detailed status report message is shown in FIGS. 32-33.
  • the second base station 552 resets COUNT after receiving the status report message. At this time, the packet corresponding to one of the FMS, FMC, LMS, and LMC values included in the status report message is reset to COUNT 0.
  • the method of resetting the COUNT to 0 may follow the procedure of one of FIGS. 45-47. After resetting COUNT to 0, the second base station 552 transmits the packet in a temporary format (6). The second base station 552 may transmit packets 7, 8 in a temporary format as previously set, and then transmit packets 9 in the new format indicated in the reset message.
  • a packet having a SN or COUNT value larger than the FMS (First Missing SN) or FMC (First Missing COUNT) indicated in the status report message can be sent in a temporary format.
  • This predetermined size may be as much as the PDCP window size used in the old format or an integer multiple thereof.
  • the transmitter that is, the second base station 552 transmits the packet in the new format after transmitting in the temporary format, but suffers retransmission in the wireless channel, so that the terminal 550 may perform the retransmission of the temporary format data and the new format data. You may receive a mix of orders. In this case, an indicator is needed to distinguish whether the packet uses a temporary format to distinguish the header format.
  • the detailed header format is shown in FIGS. 34-35.
  • FIG. 56 illustrates an embodiment of a procedure in which an unreceived packet is retransmitted after reconfiguring a packet type whose length of a PDCP SN is changed.
  • the Status Report may be transmitted from the receiver to the transmitter and may include the FMC and the bitmap as shown in the embodiment of FIG. 33 or may include the FMS and the bitmap as shown in the embodiment of FIG. have.
  • FIG. 56 it is assumed that it is transmitted in a status report of FIG. 33 including an FMC and a bitmap.
  • the FMC displays the COUNT value of the packet with the smallest COUNT value among the unreceived packets, and 8500033 is displayed.
  • the packet after this packet is indicated by the bitmap to indicate the reception status.
  • 0 is indicated when not received and 1 when received.
  • the bitmap may be represented as 01110 11110 11111 11111 10111 01111 10011.
  • bit 0 indicates that the COUNT value is 8500034, 8500038, 8500043, 8500055, 8500059, 8500065, and 8500066 is not received and indicates that the PDCP COUNT is 8500068.
  • the transmitter performs retransmission of unreceived packets.
  • the packet is transmitted in the PDU format including the new PDCP SN among the PDU format including the PDCP SN of FIG.
  • the F fields of FIGS. 34 to 35 may not be used.
  • the packets may be transmitted by additionally attaching an RLC header of the RLC layer.
  • the RLC header may include an RLC sequence number (RLC SN).
  • RLC SN RLC sequence number
  • FIG. 56 is characterized in that reordering is performed in the RLC layer by a predetermined number of packets for packets received after the reset or the status report message. The order in which packets transmitted from a transmitter arrive at a receiver may be changed due to various factors such as a change in a wireless channel.
  • packets corresponding to RLC sequence numbers 3 and 4 may be transmitted first, and packets corresponding to RLC sequence number 4 may be transmitted later.
  • packets corresponding to RLC sequence number 4 arrives first at the receiver, and the packet corresponding to the RLC sequence number 3 may arrive later.
  • the change of the order may cause HFN asynchronous.
  • 12 packets from RLC sequence number 0 to RLC sequence number 11 are reordered in the RLC layer of the receiver, and then sequentially sent to the PDCP layer of the receiver.
  • the packet can be sent to the PDCP layer.
  • the base station may set the terminal how many packets to rearrange.
  • FIG. 57 illustrates an embodiment of a procedure in which an unreceived packet is retransmitted after a packet type reset in which a length of a PDCP SN is changed.
  • the Status Report may be transmitted from the receiver to the transmitter and may include the FMC and the bitmap as shown in the embodiment of FIG. 33 or may include the FMS and the bitmap as shown in the embodiment of FIG. have.
  • FIG. 57 it is assumed that it is transmitted in a status report of FIG. 33 including an FMC and a bitmap.
  • the FMC displays the COUNT value of the packet with the smallest COUNT value among the unreceived packets, and 8500033 is displayed.
  • the packet after this packet is indicated by the bitmap to indicate the reception status.
  • 0 is indicated when not received, and 1 when received.
  • the bitmap may be represented as 01110 11110 11111 11111 10111 01111 10011.
  • bit 0 indicates that the COUNT value is 8500034, 8500038, 8500043, 8500055, 8500059, 8500065, and 8500066 is not received and indicates that the PDCP COUNT is 8500068.
  • the transmitter performs retransmission of unreceived packets.
  • the packet is transmitted in the PDU format including the new PDCP SN among the PDU format including the PDCP SN of FIG.
  • the F fields of FIGS. 34 to 35 may not be used.
  • the packets may be transmitted by additionally attaching an RLC header of the RLC layer.
  • the RLC header may include an RLC sequence number (RLC SN).
  • RLC SN RLC sequence number
  • the order in which packets transmitted from a transmitter arrive at a receiver may be changed due to various factors such as a change in a wireless channel. For example, packets corresponding to RLC sequence numbers 3 and 4 (packets corresponding to PDCP sequence numbers 11 and 23) may be transmitted first, and packets corresponding to RLC sequence number 4 may be transmitted later. . However, the packet corresponding to the RLC sequence number 4 arrives first at the receiver, and the packet corresponding to the RLC sequence number 3 may arrive later. At this time, the change of the order may cause HFN asynchronous.
  • the timer is operated after the reset time, and the packet is rearranged until the timer expires, and then sequentially sent to the PDCP layer of the receiver. After that, the packet is received at the RLC layer of the receiver without rearrangement. Can be immediately sent to the PDCP layer. At this time, how much time to perform realignment (timer time) in the RLC sublayer may be set by the base station to the terminal.

Landscapes

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

Abstract

본 개시는 4G 시스템 이후 보다 높은 데이터 전송률을 지원하기 위한 5G 통신 시스템을 IoT 기술과 융합하는 통신 기법 및 그 시스템에 관한 것이다. 본 개시는 5G 통신 기술 및 IoT 관련 기술을 기반으로 지능형 서비스 (예를 들어, 스마트 홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 헬스 케어, 디지털 교육, 소매업, 보안 및 안전 관련 서비스 등)에 적용될 수 있다. 본 개시는 무선 통신 시스템에서 통신 기기의 송신 및 수신에 관한 것으로 3GPP에서 정의된 PDCP 및 RLC 구조를 참조할 수 있다.

Description

통신시스템에서의 데이터 처리 방법
본 발명은 무선 통신 시스템에서 통신 기기의 송신 및 수신에 관한 것이다. 본 발명에서는 일 예로 3GPP에서 정의된 PDCP(Packet Data Convergence Protocol) 및 RLC(Radio Link Control) 구조를 참조할 수 있다.
4G 통신 시스템 상용화 이후 증가 추세에 있는 무선 데이터 트래픽 수요를 충족시키기 위해, 개선된 5G 통신 시스템 또는 pre-5G 통신 시스템을 개발하기 위한 노력이 이루어지고 있다. 이러한 이유로, 5G 통신 시스템 또는 pre-5G 통신 시스템은 4G 네트워크 이후 (Beyond 4G Network) 통신 시스템 또는 LTE 시스템 이후 (Post LTE) 이후의 시스템이라 불리어지고 있다.
높은 데이터 전송률을 달성하기 위해, 5G 통신 시스템은 초고주파(mmWave) 대역 (예를 들어, 60기가(60GHz) 대역과 같은)에서의 구현이 고려되고 있다. 초고주파 대역에서의 전파의 경로손실 완화 및 전파의 전달 거리를 증가시키기 위해, 5G 통신 시스템에서는 빔포밍(beamforming), 거대 배열 다중 입출력(massive MIMO), 전차원 다중입출력(Full Dimensional MIMO: FD-MIMO), 어레이 안테나(array antenna), 아날로그 빔형성(analog beam-forming), 및 대규모 안테나 (large scale antenna) 기술들이 논의되고 있다. 또한 시스템의 네트워크 개선을 위해, 5G 통신 시스템에서는 진화된 소형 셀, 개선된 소형 셀 (advanced small cell), 클라우드 무선 액세스 네트워크 (cloud radio access network: cloud RAN), 초고밀도 네트워크 (ultra-dense network), 기기 간 통신 (Device to Device communication: D2D), 무선 백홀 (wireless backhaul), 이동 네트워크 (moving network), 협력 통신 (cooperative communication), CoMP (Coordinated Multi-Points), 및 수신 간섭제거 (interference cancellation) 등의 기술 개발이 이루어지고 있다.
이 밖에도, 5G 시스템에서는 진보된 코딩 변조(Advanced Coding Modulation: ACM) 방식인 FQAM (Hybrid FSK and QAM Modulation) 및 SWSC (Sliding Window Superposition Coding)과, 진보된 접속 기술인 FBMC(Filter Bank Multi Carrier), NOMA(non orthogonal multiple access), 및SCMA(sparse code multiple access) 등이 개발되고 있다.
한편, 인터넷은 인간이 정보를 생성하고 소비하는 인간 중심의 연결 망에서, 사물 등 분산된 구성 요소들 간에 정보를 주고 받아 처리하는 IoT(Internet of Things, 사물인터넷) 망으로 진화하고 있다. 클라우드 서버 등과의 연결을 통한 빅데이터(Big data) 처리 기술 등이 IoT 기술에 결합된 IoE (Internet of Everything) 기술도 대두되고 있다. IoT를 구현하기 위해서, 센싱 기술, 유무선 통신 및 네트워크 인프라, 서비스 인터페이스 기술, 및 보안 기술과 같은 기술 요소 들이 요구되어, 최근에는 사물간의 연결을 위한 센서 네트워크(sensor network), 사물 통신(Machine to Machine, M2M), MTC(Machine Type Communication)등의 기술이 연구되고 있다.
IoT 환경에서는 연결된 사물들에서 생성된 데이터를 수집, 분석하여 인간의 삶에 새로운 가치를 창출하는 지능형 IT(Internet Technology) 서비스가 제공될 수 있다. IoT는 기존의 IT(information technology)기술과 다양한 산업 간의 융합 및 복합을 통하여 스마트홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 스마트 그리드, 헬스 케어, 스마트 가전, 첨단의료서비스 등의 분야에 응용될 수 있다.
이에, 5G 통신 시스템을 IoT 망에 적용하기 위한 다양한 시도들이 이루어지고 있다. 예를 들어, 센서 네트워크(sensor network), 사물 통신(Machine to Machine, M2M), MTC(Machine Type Communication)등의 기술이 5G 통신 기술이 빔 포밍, MIMO(Multiple Input Multiple Output), 및 어레이 안테나 등의 기법에 의해 구현되고 있는 것이다. 앞서 설명한 빅데이터 처리 기술로써 클라우드 무선 액세스 네트워크(cloud RAN)가 적용되는 것도 5G 기술과 IoT 기술 융합의 일 예라고 할 수 있을 것이다.
본 발명은 무선 통신 시스템에서 송신단에서 폐기(Discard)된 패킷(Packet) 정보를 수신단에 보고하기 위한 설정 방법 및 보고하는 방법을 통해, 수신단에서의 수신하지 못한 Packet에 대해 패킷을 처리하는 문제를 해결하는 방법을 제공한다.
또한, 본 발명은 무선통신시스템에서 순서 번호(Sequence Number)의 크기가 변경될 때 데이터 손실 없이 동작하는 절차 및 방법을 제공한다.
상기와 같은 문제점을 해결하기 위한 본 발명의 일 실시 예에 따른 무선 통신 시스템에서 송신기의 방법에 있어서, PDCP(Packet Data Convergence Protocol) 패킷에 대한 타이머를 구동하는 단계, 상기 타이머가 만료되면, 상기 PDCP 패킷을 폐기하는 단계 및 상기 폐기된 PDCP 패킷의 정보를 포함하는 보고를, 수신기로 전송하는 단계를 포함할 수 있다.
또한, 본 발명의 일 실시 예에 따른 무선 통신 시스템에서 수신기의 방법에 있어서, 송신기로부터 폐기된 PDCP(Packet Data Convergence Protocol) 패킷의 정보를 포함하는 보고를 수신하는 단계를 포함하고, PDCP 패킷은, 상기 PDCP 패킷에 대한 타이머가 구동되고, 상기 타이머가 만료되는 것에 의하여 상기 송신기에서 폐기될 수 있다.
또한, 본 발명의 일 실시 예에 따른 무선 통신 시스템에서 송신기에 있어서, 송수신부 및 PDCP(Packet Data Convergence Protocol) 패킷에 대한 타이머를 구동하고, 상기 타이머가 만료되면, 상기 PDCP 패킷을 폐기하며, 상기 폐기된 PDCP 패킷의 정보를 포함하는 보고를, 수신기로 전송하도록 상기 송수신부를 제어하는 제어부를 포함할 수 있다.
또한, 본 발명의 일 실시 예에 따른 무선 통신 시스템에서 수신기에 있어서, 송신기로, PDCP(Packet Data Convergence Protocol) 패킷의 정보를 포함하는 보고에 관한 설정 정보를 전송하는 송수신부 및 상기 송신기로부터, 상기 설정 정보에 기반하여 생성된, 폐기된 PDCP 패킷의 정보를 포함하는 보고를 수신하도록 상기 송수신부를 제어하는 제어부를 포함하고, PDCP 패킷은, 상기 PDCP 패킷에 대한 타이머가 구동되고, 상기 타이머가 만료되는 것에 의하여 상기 송신기에서 폐기될 수 있다.
본 발명의 일 실시예에 따르면, 수신단으로 Discard된 Packet의 정보를 전송하고 이에 기반하여 수신단에서 Discard된 Packet을 제외하고 패킷을 처리함으로써, 지연 시간을 감소시킬 수 있는 효과를 얻을 수 있다.
또한, 본 발명의 일 실시예에 따르면, 순서 번호(Sequence Number)의 크기가 변경될 때에도 효과적인 통신이 가능하다.
도 1 은 Uplink 데이터 전송 동작 중 Discard Timer 동작을 나타낸 도면이다.
도 2 는 데이터 패킷이 Discard될 경우에 NR에서 발생 가능한 문제를 나타낸 도면이다.
도 3 은 본 발명에서 제안하는 Discard 패킷 정보를 전송하기 위한 설정 방법을 나타낸 도면이다.
도 4 은 단일의 Discard 패킷 정보를 전송하는 경우의 동작을 나타낸 도면이다.
도 5 는 Transmitter에서 Discard Timer 만료 시 Discard Packet 정보를 저장하는 방법을 나타낸 도면이다.
도 6 은 복수 개의 Discard 패킷 정보를 전송하는 경우에 이벤트를 이용하여 시작하는 방법을 나타낸 도면이다.
도 7 은 복수 개의 Discard 패킷 정보를 전송하는 경우에 이벤트가 만료 시 동작하는 방법을 나타낸 도면이다
도 8 는 Tx 단말에서 NACK을 수신을 하였을 경우 Discard 패킷 정보를 전송하는 방법을 나타낸 도면이다.
도 9 은 매 Discard 패킷 발생 시 Discard Packet 정보를 전송하기 위한 구조의 예시를 나타낸 도면이다.
도 10 은 복수개의 Discard 패킷 발생 시 Discard Packet 정보를 전송하기 위한 구조의 예시를 나타낸 도면이다.
도 11 은 PDCP 데이터 전송 패킷을 시용하는 경우 Discard Packet 정보를 포함하여 전송하는 방법을 나타낸 예시의 도면이다.
도 12은 복수개의 Discard 패킷 발생 시 Discard Packet 정보를 전송하기 위해 Contiguous Number를 이용하는 방법을 나타낸 예시의 도면이다.
도 13 은 복수개의 Discard 패킷 발생 시 Discard Packet 정보를 전송하기 위해 Discarded Sequence Number Now와 Discarded Sequence Number High를 이용하는 방법을 나타낸 예시의 도면이다.
도 14 은 복수개의 Discard 패킷 발생 시 Discard Packet 정보를 전송하기 위해 Bitmap을 이용하는 방법을 나타낸 예시의 도면이다.
도 15 은 복수개의 Discard 패킷 발생 시 Discard Packet 정보를 전송하기 위해 Bitmap을 이용하는 방법에서 Bitmap Size를 알려주는 경우의 예시를 나타낸 도면이다.
도 16은 본 발명에서 고려하는 헤더 형식이 변경되는 시나리오를 나타낸 도면이다.
도 17은 헤더 형식이 변경되는 메시지의 실시 예를 나타낸 도면이다.
도 18은 포맷이 바뀔 때 재전송이 되는 방식의 실시 예를 나타낸 도면이다.
도 19는 도 18의 실시 예에서 헤더의 형식이 바뀔 때 헤더 형식의 실시 예를 나타낸 도면이다.
도 20은 포맷이 바뀔 때 재전송이 되는 방식의 다른 실시 예를 나타낸 도면이다.
도 21은 도 20의 실시 예에서 헤더의 형식이 바뀔 때 헤더 형식의 실시 예를 나타낸 도면이다.
도 22는 재설정 이후에 기존 형식의 데이터 처리가 필요하게 될 경우 기존 형식을 처리할 수 있는 예전 장치(Old Entity)에 기존 형식의 데이터(Old Format Data)를 보내어 처리를 요청하는 절차를 나타낸 도면이다.
도 23은 3GPP 통신 시스템에서의 PDCP COUNT 구조를 나타낸 도면이다.
도 24는 재설정 시에 COUNT를 사용하여 재정렬을 하는 방법의 실시 예를 나타낸 도면이다.
도 25는 재설정 시에 HFN 값과 COUNT를 변경하는 또 다른 실시 예를 나타낸 도면이다.
도 26은 본 발명의 일 실시 예에 따른 헤더 형식의 변경 예를 도시한 도면이다.
도 27은 본 발명의 일 실시 예에 따른 헤더 형식의 변경 예를 도시한 도면이다.
도 28은 본 발명의 일 실시 예에 따른 상향링크 데이터에 대해 헤더 형식이 바뀌는 절차를 나타낸 도면이다.
도 29는 본 발명의 일 실시 예에 따른 하향링크 데이터에 대해 헤더 형식이 바뀌는 절차를 나타낸 도면이다.
도 30은 본 발명의 일 실시 예에 따른 상향링크 데이터에 대해 헤더 형식이 바뀌는 절차를 나타낸 도면이다.
도 31은 본 발명의 일 실시 예에 따른 하향링크 데이터에 대해 헤더 형식이 바뀌는 절차를 나타낸 도면이다.도 32는 본 발명의 일 실시 예에 따른 상태 보고 메시지의 형식을 나타낸 도면이다.
도 33은 본 발명의 일 실시 예에 따른 상태 보고 메시지의 형식을 나타낸 도면이다.
도 34는 본 발명의 일 실시 예에 따른 COUNT를 포함하는 PDCP 데이터 PDU의 형식을 나타낸 도면이다.
도 35는 본 발명의 일 실시 예에 따른 PDCP 순서 번호(SN)를 포함하는 PDCP 데이터 PDU의 형식을 나타낸 도면이다.
도 36은 본 발명의 일 실시 예에 따른 수신기의 PDCP 장치에서 도 34-35의 PDCP 데이터 PDU 형식을 구분하여 디코딩하는 방법을 나타낸 도면이다.
도 37은 본 발명의 일 실시 예에 따른 수신기의 PDCP 장치에서 도 34-35의 PDCP 데이터 PDU 형식을 구분하여 디코딩하는 방법을 나타낸 도면이다.
도 38은 본 발명의 일 실시 예에 따른 PDCP SN의 길이가 바뀌는 패킷 형식 재설정에 의해 PDCP SN이 바뀌는 경우를 나타낸 도면이다.
도 39는 본 발명의 일 실시 예에 따른 PDCP SN의 길이가 바뀌는 패킷 형식 재설정 이후 미수신 패킷이 재전송되는 절차를 나타낸 도면이다.
도 40은 본 발명의 일 실시 예에 따른 PDCP SN의 길이가 바뀌는 패킷 형식 재설정에 의해 PDCP SN이 바뀌는 경우를 나타낸 도면이다.
도 41는 본 발명의 일 실시 예에 따른 PDCP SN의 길이가 바뀌는 패킷 형식 재설정 이후 미수신 패킷이 재전송되는 절차를 나타낸 도면이다.
도 42는 본 발명의 일 실시 예에 따른 PDCP SN의 길이가 바뀌는 패킷 형식 재설정 이후 미수신 패킷이 재전송되는 절차를 나타낸 도면이다.
도 43은 본 발명의 일 실시 예에 따른 PDCP SN의 길이가 바뀌는 패킷 형식 재설정 이후 미수신 패킷이 재전송되는 절차의 실시예를 나타낸 도면이다.
도 44는 본 발명의 일 실시 예에 따른 PDCP SN의 길이가 바뀌는 패킷 형식 재설정 이후 미수신 패킷이 재전송되는 절차를 나타낸 도면이다.
도 45는 본 발명의 일 실시 예에 따른 패킷 형식의 재설정 이후에 COUNT를 변경하는 절차를 나타낸 도면이다.
도 46은 본 발명의 일 실시 예에 따른 패킷 형식의 재설정 이후에 COUNT를 변경하는 절차를 나타낸 도면이다.
도 47은 본 발명의 일 실시 예에 따른 패킷 형식의 재설정 이후에 COUNT를 변경하는 절차를 나타낸 도면이다.
도 48은 본 발명의 일 실시 예에 따른 상향링크 데이터에 대해 COUNT 재시작 및 헤더 형식이 바뀌는 절차를 나타낸 도면이다.
도 49는 본 발명의 일 실시 예에 따른 하향링크 데이터에 대해 COUNT 재시작 및 헤더 형식이 바뀌는 절차를 나타낸 도면이다.
도 50은 본 발명의 일 실시 예에 따른 상향링크 데이터에 대해 COUNT를 재시작하고 헤더 형식이 바뀌는 경우의 단말과 기지국 신호 흐름을 나타낸 도면이다.
도 51은 본 발명의 일 실시 예에 따른 하향링크 데이터에 대해 COUNT를 재시작하고 헤더 형식이 바뀌는 경우의 단말과 기지국 신호 흐름을 나타낸 도면이다.
도 52는 본 발명의 일 실시 예에 따른 상향링크 데이터에 대해 COUNT 재시작 및 헤더 형식이 바뀌는 절차를 나타낸 도면이다.
도 53은 본 발명의 일 실시 예에 따른 하향링크 데이터에 대해 COUNT를 재시작 및 헤더 형식이 바뀌는 절차를 나타낸 도면이다.
도 54는 본 발명의 일 실시 예에 따른 상향링크 데이터에 대해 COUNT를 재시작하고 헤더 형식이 바뀌는 경우 단말과 기지국 간 변경 신호 흐름을 나타낸 도면이다.
도 55는 본 발명의 일 실시 예에 따른 하향링크 데이터에 대해 COUNT를 재시작하고 헤더 형식이 바뀌는 경우 단말과 기지국 간 변경 신호 흐름을 나타낸 도면이다.
도 56은 본 발명의 일 실시 예에 따른 PDCP SN의 길이가 바뀌는 패킷 형식 재설정 이후 미수신 패킷이 재전송되는 절차를 나타낸 도면이다.
도 57은 본 발명의 일 실시 예에 따른 PDCP SN의 길이가 바뀌는 패킷 형식 재설정 이후 미수신 패킷이 재전송되는 절차를 나타낸 도면이다.
본 발명의 실시 예를 설명함에 있어서 본 발명이 속하는 기술 분야에 익히 알려져 있고 본 발명과 직접적으로 관련이 없는 기술 내용에 대해서는 설명을 생략한다. 이는 불필요한 설명을 생략함으로써 본 발명의 요지를 흐리지 않고 더욱 명확히 전달하기 위함이다.
마찬가지 이유로 첨부 도면에 있어서 일부 구성요소는 과장되거나 생략되거나 개략적으로 도시되었다. 또한, 각 구성요소의 크기는 실제 크기를 전적으로 반영하는 것이 아니다. 각 도면에서 동일한 또는 대응하는 구성요소에는 동일한 참조 번호를 부여하였다.
본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 개시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시 예들은 본 발명의 개시가 완전하도록 하고, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.
이 때, 처리 흐름도 도면들의 각 블록과 흐름도 도면들의 조합들은 컴퓨터 프로그램 인스트럭션들에 의해 수행될 수 있음을 이해할 수 있을 것이다. 이들 컴퓨터 프로그램 인스트럭션들은 범용 컴퓨터, 특수용 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서에 탑재될 수 있으므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서를 통해 수행되는 그 인스트럭션들이 흐름도 블록(들)에서 설명된 기능들을 수행하는 수단을 생성하게 된다. 이들 컴퓨터 프로그램 인스트럭션들은 특정 방식으로 기능을 구현하기 위해 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 지향할 수 있는 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장되는 것도 가능하므로, 그 컴퓨터 이용가능 또는 컴퓨터 판독 가능 메모리에 저장된 인스트럭션들은 흐름도 블록(들)에서 설명된 기능을 수행하는 인스트럭션 수단을 내포하는 제조 품목을 생산하는 것도 가능하다. 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에 탑재되는 것도 가능하므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에서 일련의 동작 단계들이 수행되어 컴퓨터로 실행되는 프로세스를 생성해서 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 수행하는 인스트럭션들은 흐름도 블록(들)에서 설명된 기능들을 실행하기 위한 단계들을 제공하는 것도 가능하다.
또한, 각 블록은 특정된 논리적 기능(들)을 실행하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 코드의 일부를 나타낼 수 있다. 또, 몇 가지 대체 실행 예들에서는 블록들에서 언급된 기능들이 순서를 벗어나서 발생하는 것도 가능함을 주목해야 한다. 예컨대, 잇달아 도시되어 있는 두 개의 블록들은 사실 실질적으로 동시에 수행되는 것도 가능하고 또는 그 블록들이 때때로 해당하는 기능에 따라 역순으로 수행되는 것도 가능하다.
이 때, 본 실시 예에서 사용되는 '~부'라는 용어는 소프트웨어 또는 FPGA또는 ASIC과 같은 하드웨어 구성요소를 의미하며, '~부'는 어떤 역할들을 수행한다. 그렇지만 '~부'는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. '~부'는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일 예로서 '~부'는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함한다. 구성요소들과 '~부'들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 '~부'들로 결합되거나 추가적인 구성요소들과 '~부'들로 더 분리될 수 있다. 뿐만 아니라, 구성요소들 및 '~부'들은 디바이스 또는 보안 멀티미디어카드 내의 하나 또는 그 이상의 CPU들을 재생시키도록 구현될 수도 있다. 또한 실시 예에서 '~부'는 하나 이상의 프로세서를 포함할 수 있다.
<제1 실시예>
도 1은 송신 장치(Transmitter)에서 상향링크(Uplink) 데이터 전송 동작 중 폐기(Discard) 타이머(Timer) 동작을 나타낸 도면이다.
도 1은 상향링크 데이터 전송 동작 중에 LTE 시스템에서의 실시 예를 나타낸 도면이다. 예를 들어, 상위 계층(Upper layer(일 예로, IP 계층(IP Layer))에서 전송할 데이터가 있는 경우 데이터(일 예로, IP 패킷(IP Packet))는 Upper Layer에서 PDCP(Packet Data Convergence Protocol) Layer로 전달 된다. 예를 들어, Upper Layer의 데이터인 IP Packet 1, IP Packet2, IP Packet3 (IP Packet 1~3은 같은 어플리케이션에서 생성된 데이터이거나 각각 다른 어플리케이션에서 생성된 데이터 일 수 있다)은, PDCP(Packet Data Convergence Protocol) Layer로 전달되고, IP Packet1은 PDCP SDU1로 구성되며, IP Packet2는 PDCP SDU2로 구성되며, IP Packet3은 PDCP SDU3으로 구성된다.
또한, 각 PDCP SDU를 생성하는 시점에, PDCP SDU별로 Discard Timer가 동작을 하게 된다. 예를 들어, LTE 시스템에서는 PDCP SDU1이 생성된 시점에 PDCP SDU1 Discard Timer를 시작하게 되며, Discard Timer가 만료되는 시점(예를 들어, RRC(Radio Resource Control)에서 PDCP로, Discard Timer로써 설정한 만료 시간이 50ms인 경우에 50ms이 넘었을 시)에 PDCP Layer에서 PDCP SDU1에 대해 Discard 하게 된다. 또한, Discard Timer의 시간 설정은 RRC(Radio Resource Control)를 통해 설정될 수 있다.
도 2는 데이터 패킷이 Discard될 경우에 무선통신 시스템에서 발생 가능한 문제를 나타낸 도면이다.
도 2는 상향링크 데이터 전송 동작 중에 무선통신 시스템(예, LTE 시스템)에서 PDCP Packet이 Discard 되었을 경우에 발생 될 수 있는 문제점의 예를 나타낸 도면이다. 예를 들어 Transmitter가 Receiver로 전송할 PDCP 패킷이 있는 경우 송신 장치(Transmitter)는 수신 장치(Receiver)에게 PDCP 패킷을 RLC(Radio Link Control) Layer를 통해, 하위 계층(Lower Layer)으로 전달하여 데이터를 전송할 수 있다.
Transmitter는 Receiver에게 PDCP 패킷 1~7을 전송하였으나, 채널 환경 등의 문제로 Receiver는 RLC 또는 PDCP 패킷 3, 4, 5에 대해 수신을 하지 못할 수 있다. 또한, 이 경우, Receiver는 RLC Layer에서 RLC 모드가 AM(Acknowledged mode)일 때, 수신하지 못한 RLC 패킷 정보 3~5에 대해 NACK(Negative Acknowledgement)을 전송할 수 있다. 또는, 패킷 3, 4, 5 중 일부가 Discard Timer가 만료하여 Discard 되었을 수도 있다.
만약, Receiver가 NACK을 보내는 시점에 Transmitter의 PDCP Layer에서는, 상기 도 1에서 기술한 바와 같이, PDCP Discard Timer의 만료에 따라 PDCP 패킷 3, 4, 5번을 Discard 할 수 있다. 이 경우, Transmitter는 Receiver로부터, Receiver가 수신하지 못한 패킷 정보를 수신하지만 PDCP 패킷을 Discard 하였기 때문에 Receiver에게, Receiver가 수신하지 못한 PDCP 패킷을 재전송 해줄 수 없게 된다. 또한, Receiver는 수신하지 못한 PDCP 패킷에 대해 재전송 요청으로써, Transmitter에게 무한정 NACK을 보내는 문제가 발생 할 수 있다.
도 3은 본 발명에서 제안하는 Discard 패킷 정보를 전송하기 위한 설정 방법을 나타낸 도면이다
도 3은 Transmitter(예를 들어, 단말 또는 기지국)가, 상향링크로 보낼 데이터 중 Discard된 패킷 정보를 전송하기 위해 설정하는 방법을 나타낸 도면이다.
상향링크로 보낼 데이터 중 Discard된 패킷이 발생 되었을 경우, Discard된 패킷 정보를 언제 전송할 것인가와, 어떤 포멧으로 전송할 것인지를, 기지국(31)이 단말로 폐기된 패킷 지시(Discard Packet Indication) 설정 메시지를 전송(1)하여, 단말이 Discard Packet 정보를 전송할 시점 및 방법을 설정할 수 있게 한다.
예를 들어, Discard된 패킷 정보 전송 시점(Report Type)으로 주기적(Periodic) type이 설정된 경우, 단말(30)은 Discard Packet이 발생된 시점에 바로 기지국(31)으로 Discard Packet 정보를 전송(2)할 수 있다. 또 다른 실시 예로, Discard된 패킷 정보 전송 시점 (Report Type)으로 이벤트(Event) type이 설정된 경우, 단말(30)은 Discard packet이 발생된 시점으로부터 일정 시간 동안의 Discard Packet의 정보들을 조합 또는 일정 카운팅 동안의 Discard Packet의 정보들의 조합으로 Discard Packet 정보를 전송(2)할 수 있다. 예를 들어, Event에서 Timer로 지정된 경우, Event와 이벤트 임계 시간(Event Threshold Time)을 포함할 수 있거나 Event에서 카운팅으로 지정된 경우, 이벤트 N-카운터 임계값(Event N-Counter Threshold)를 포함할 수 있다. 또한, Event Threshold Time실시 예로는 만료 시점을 포함할 수 있다.
또한, 단말(30)이 Discard Packet 정보를 전송하기로 결정한 후, Discard Packet을 전송하기 위한 포멧을 설정할 수 있다. 예를 들어, Discard Packet을 전송하기 위한 포멧(Report Format)으로, 폐기 시퀀스 번호(Discard Sequence Number) 또는 낮은 폐기 시퀀스(Discard Sequence Low) 및 높은 폐기 시퀀스(Discard Sequence High) 또는 폐기 시퀀스 연속 개수(Discard Sequence Contiguous Number) 또는 폐기 시퀀스 비트맵 정보(Discard Sequence Bitmap Info.) 등을 포함하는 방법을 설정할 수 있다.
Discard된 패킷 정보를 전송하기 위한 설정 메시지는 시스템 정보(System information)로 전달되거나 전용 시그널링(Dedicated Signaling)을 통해 전송될 수 있다.
또한, 단말(30) 또는 기지국(31)이 폐기된 패킷 보고(Discard Packet Reporting) 메시지로 Dedicated Signaling을 이용할 수 있으며 실시 예로, RRC 메시지(RRC Message) 또는 MAC(Medium Access Control) 메시지(MAC Message) 또는 PDCP 메시지(PDCP Message), 또는 RLC 메시지(RLC Message)일 수 있다.
도 4는 단일의 Discard 패킷 정보를 전송하는 경우의 동작을 나타낸 도면이다.
도 4는 본 발명에서 제안하는 방법 중 Discard Packet이 발생한 시점에 Discard Packet 정보를 전송하는 방법을 나타낸 도면이다.
본 발명의 하나의 실시 예로 Discard Packet 전송 시점이 Periodic인 경우 상기 도 4의 동작을 수행할 수 있다.
Transmitter(예를 들어, 단말 또는 기지국)는, PDCP에서 패킷이 생성된 시점부터 Discard Timer를 확인(1)한다. Transmitter는 Discard Timer의 확인을 통하여 discard timer의 만료여부를 확인(2)한 후, 만료가 되었을 경우 Discard Timer가 만료된 PDCP 패킷을 Discard 하게 된다(3). 또한, Transmitter는 Discard된 PDCP 패킷 정보(예를 들어, Discard Packet의 sequence 정보 등을 포함)를 Receiver(예를 들어, 단말 또는 기지국)로 전송한다.
도 5는 Transmitter에서 Discard Timer 만료 시 Discard Packet 정보를 저장하는 방법을 나타낸 도면이다.
도 5는 패킷별 Discard Timer가 동작하고 있으며 Discard Timer가 만료 되었을 경우 Discard Packet 정보를 저장하기 위한 방법을 나타낸 도면이다.
Transmitter는 PDCP에서 패킷이 생성된 시점부터 Discard Timer를 확인(1)한다. Transmitter는 Discard Timer의 확인을 통하여 Discard Timer의 만료여부를 확인(2)한 후, 만료가 되었을 경우 Discard Timer가 만료된 PDCP 패킷을 Discard하게 되고, Discard된 PDCP 패킷 정보(예, PDCP Sequence Number)를 저장한다(3).
도 6은 복수 개의 Discard 패킷 정보를 전송하는 경우에 이벤트를 이용하여 시작하는 방법을 나타낸 도면이다.
도 6은 본 발명에서 제안하는 방법 중 Discard Packet이 발생한 시점을 기준으로 일정 시간 동안 대기 후, 대기 시간 동안 발생한 Discard Packet 정보들을 전송하기 위해 Event Timer 또는 N-Counter 시작하는 방법을 나타낸 도면이다.
본 발명의 하나의 실시 예로, Discard Packet 전송 시점 Type이 Event인 경우, 또는 Event Threshold Time을 포함하였을 경우 상기 도 6의 동작을 수행할 수 있다.
Discard Timer가 만료된 패킷이 있을 경우, Transmitter는 Discard Timer가 만료된 PDCP 패킷을 Discard하게 되고, Discard된 PDCP 패킷 정보(예, PDCP Sequence Number)를 저장한다(1). Transmitter는 Discard Packet 정보를 저장 한 후에, 이전에 Discard된 Packet 정보가 있는지 확인(2)한다. Transmitter는, 이전에 생성된 Discard Packet 정보가 없는 경우, 대기 타이머(waiting Timer)를 시작한다(3).
본 발명의 또 다른 실시 예로, Discard Packet 전송 시점Type이 Event인 경우, 또는 Event N-Counter Threshold를 포함하였을 경우 상기 도 6의 동작을 수행할 수 있다.
Discard Timer가 만료된 패킷이 있을 경우, Transmitter는 Discard Timer가 만료된 PDCP 패킷을 Discard 하게 되고, Discard된 PDCP 패킷 정보(예, PDCP Sequence Number)를 저장한다(1). Transmitter는 Discard Packet 정보를 저장 한 후에, 이전에 Discard된 Packet 정보가 있는지 확인(2)한다. Transmitter는, 이전에 생성된 Discard Packet 정보가 없는 경우 N-Counter를 시작한다(3).
도 7은 복수 개의 Discard 패킷 정보를 전송하는 경우에 이벤트가 만료 시 동작하는 방법을 나타낸 도면이다.
도 7은 본 발명에서 제안하는 방법 중 Event가 시작된 후 Discard Packet이 발생 되는 경우의 동작을 나타낸 도면이다.
본 발명의 하나의 실시 예로 Event 중 Waiting Timer가 시작된 후 Discard Packet이 발생되면 상기 도 7의 동작을 수행할 수 있다.
Transmitter는 Discard Packet 발생 시 Waiting Timer의 동작의 유무(1)를 확인한다. Transmitter는 Waiting Timer가 동작 시, Waiting Timer가 Event Threshold Time을 초과하여 만료되었는지 확인한다(2). Transmitter는 Waiting Timer가 만료되지 않은 경우는 (1)의 동작을 다시 수행한다. 또한, Transmitter는 Waiting Timer가 만료되었을 경우 상기 도 6의 동작을 통해, Waiting Timer 동안 저장된 Discard Packet 정보를 Receiver로 전송한다. 또한, Transmitter는 Receiver로 Discard Packet 정보를 전송한 후 Waiting Timer를 초기화한다(3).
본 발명의 또 다른 실시 예로, Event 중 N-Counter가 시작된 후 Discard Packet이 발생되면 상기 도 7의 동작을 수행할 수 있다.
Transmitter는 Discard Packet 발생 시, N-Counter의 동작의 유무(1)를 확인한다. Transmitter는 N-Counter가 동작 시, N-Counter가 Event N-Counter Threshold를 초과하여 만료되었는지 확인한다(2). Transmitter는, N-Counter와 Event N-Counter Threshold를 비교하여 조건에 만족하면 (3)의 동작을 수행할 수 있다.
예를 들어, Transmitter가 N-Counter를 감소시키는 경우에는 Event N-Counter Threshold보다 작거나 또는 같은 경우에 조건이 만족함으로 결정할 수 있다. 또 다른 예로 Transmitter가 N-Counter를 증가 시키는 경우에는 Event N-Counter Threshold 보다 크거나 또는 같은 경우에 조건이 만족함으로 결정할 수 있다. 또한, (2)의 동작에서 N-Counter의 이벤트가 만족되지 않은 경우에는 N-Counter의 값을 변경 후 (1)의 동작을 다시 수행한다. 예를 들어 N-Counter를 감소 시키거나 N-Counter를 증가 시킬 수 있다. 또한 N-Counter이벤트가 만족되었을 경우 Transmitter는 상기 도 5의 동작을 통해 N-Counter 동안 저장된 Discard Packet 정보를 Receiver로 전송한다. 또한 Receiver로 Discard Packet 정보를 전송 후 Transmitter는 N-Counter를 초기화한다(3).
도 8은 Transmitter에서 NACK을 수신을 하였을 경우 Discard 패킷 정보를 전송하는 방법을 나타낸 도면이다.
Transmitter는, Receiver의 패킷 손실 여부를, Receiver의 NACK 메시지를 통해 알 수 있다(1). 예를 들어 Receiver가 보낸 NACK 메시지에는, Packet의 Sequence Number가 포함되어 있다. Transmitter는 Receiver로부터 NACK을 수신하면, NACK 메시지에 포함된 Sequence Number에 상응하는 Discard packet 정보가 있는지 확인(2)을 한다. Discard Packet 정보는 상기 도 5의 방법에 의해 저장될 수 있다. Transmitter는, NACK 수신 후 NACK 메시지에 포함된 Sequence Number에 상응하는 Discard Packet 정보가 있는 경우, Receiver로, 상응하는 Discard Packet 정보(예를 들어, Packet Sequence Number)를 전송(3)한다.
또한, Transmitter는, NACK 수신 후 NACK 메시지에 포함된 Sequence Number에 상응하는 Discard Packet 정보가 없는 경우, NACK 메시지에 포함된 Sequence Number의 Packet을 Discard 하지 않았다 판단하여, NACK메시지에 포함된 Sequence Number의 Packet을 Receiver로 전송(4)한다.
도 9는 매 Discard 패킷 발생 시 Discard Packet 정보를 전송하기 위한 구조의 예시를 나타낸 도면이다.
도 9는 Discard packet이 발생하면 Discard Packet 발생 시점에 Receiver로 Discard 된 Packet의 단일 정보를 보내기 위한 Packet 구조를 나타낸 도면이다.
예를 들어 Discard된 패킷 정보 전송 시점(Report Type)이 Periodic인 경우, Transmitter는 Discard Packet이 발생된 시점에 바로 Receiver로 Discard Packet 정보를 전송하는 경우에 본 실시 예를 적용할 수 있다.
도 9의 Discard Packet 정보로는, Discard Packet 정보임을 나타내는 지시자인 폐기 패킷 지시자(Discard Packet Indication, DPI) 및 Discard Packet 정보(예, Discarded Packet Sequence Number)를 포함할 수 있다.
또한, Transmitter는 폐기 패킷 포맷(Discard Packet Format)을 Discard Packet Reporting 메시지에 포함하여, Dedicated Signaling로 전송할 수 있다. 예를 들어, Dedicated Signaling 메세지는, RRC Message 또는 MAC Message 또는 PDCP Message, 또는 RLC Message일 수 있다.
도 10은 복수개의 Discard 패킷 발생 시 Discard Packet 정보를 전송하기 위한 구조의 예시를 나타낸 도면이다.
도 10은 Discard packet이 발생하면 Discard Packet 발생 시점에, Receiver로 Discard 된 Packet의 복수개의 정보를 보내기 위한 Packet 구조를 나타낸 도면이다.
예를 들어, Discard된 패킷 정보 전송 시점(Report Type)이 Event type인 경우, Transmitter는 Discard Packet이 발생된 시점부터 Event 만료 시점까지의 Discard Packet 정보들을 전송하는 경우에 본 실시 예를 적용할 수 있다.
도 10의 Discard Packet 정보로는 Discard Packet 정보임을 나타내는 지시자인 Discard Packet Indication(DPI) 및 Discard Packet 정보(예, Discarded Packet Sequence Number)를 복수 개 포함할 수 있다. 또한, 확장 비트(Expansion Bit(E))를 통해 폐기 패킷 시퀀스(Discard packet sequence)가 있음을 알려줄 수 있다.
또한, Transmitter는 Discard Packet Format을 Discard Packet Reporting 메시지에 포함하여 Dedicated Signaling로 전송할 수 있다. 예를 들어, Dedicated Signaling 메세지는, RRC Message 또는 MAC Message 또는 PDCP Message ,또는 RLC Message일 수 있다.
도 11은 PDCP 데이터 전송 패킷을 사용하는 경우 Discard Packet 정보를 포함하여 전송하는 방법을 나타낸 예시의 도면이다.
도 11은 PDCP 데이터 전송 패킷을 이용하여 단일 또는 복수개의 Discard Packet 정보를 포함하여 전송하는 구조를 나타낸 도면이다.
도 11에서, 포함될 수 있는 정보는, 데이터(Data) 패킷 또는 제어(Control) 패킷인지를 알려주는 지시자(D/C)를 포함할 수 있다. 또한, 도 11에서, 포함될 수 있는 정보는, Discard Packet 정보가 포함되어 있음을 알려주는 지시자인 Discard Packet Indication(DPI) 및 Discard Packet 정보(예, Discarded Packet Sequence Number)를 복수 개 포함할 수 있다. 또한, Transmitter는 Expansion Bit(E)를 통해 Discard packet sequence가 있음을 알려줄 수 있다.
일 실시 예로, LTE 시스템에서 이용하는 PDCP 데이터 패킷 구조에서 리저브된 비트(Reserved Bit)에 DPI를 포함하여 해당 PDCP Data Packet이 Discard Sequence Number를 포함하는 패킷인지 알려줄 수 있으며, 기존 PDCP data 패킷의 Sequence Number와 Data 사이에, Discard Sequence Number를 포함할 수 있다. 또한, Transmitter는 Expansion Bit(E)를 통해 하나 또는 복수 개의 Discard packet sequence가 있음을 알려줄 수 있다.
도 12는 복수개의 Discard 패킷 발생 시, Discard Packet 정보를 전송하기 위해 Contiguous Number를 이용하는 방법을 나타낸 예시의 도면이다.
도 12는 Discard packet이 발생하면 Discard Packet 발생 시점에, Receiver로 Discard 된 Packet의 복수개의 정보를 보내기 위한 Packet 구조를 나타낸 도면이다.
예를 들어, Discard된 패킷 정보 전송 시점(Report Type)이 Event type인 경우, Transmitter는 Discard Packet이 발생된 시점부터 Event 만료 시점까지의 Discard Packet 정보들을 전송하는 경우에 본 실시 예를 적용할 수 있다.
도 12의 Discard Packet 정보로는 Discard Packet 정보임을 나타내는 지시자인 Discard Packet Indication(DPI) 및 Discarded Packet의 시작 시점 Sequence Number를 포함 할 수 있으며, 연속적인 수(Contiguous Number)를 통해 몇 개의 Discard packet이 발생하였는지 알려줄 수 있다.
예를 들어, Discard Sequence Number가 3이며 Contiguous Number가 2인 경우, Receiver는 Discard Sequence Number 3, 4, 5에 대해 Discard 되었다는 것을 알 수 있다. 또한, Transmitter는 Expansion Bit(E1)를 통해 Discard packet의 시작 시점 sequence가 있음을 알려줄 수 있으며 Expansion Bit(E2)를 통해 Discard packet의 Contiguous Number(CN) 있음을 알려 줄 수 있다.
또한, Transmitter는 Discard Packet Format을 Discard Packet Reporting 메시지에 포함하여 Dedicated Signaling로 전송할 수 있다. 예를 들어, Dedicated Signaling 메세지는, RRC Message 또는 MAC Message 또는 PDCP Message, 또는 RLC Message일 수 있다.
도 13은 복수개의 Discard 패킷 발생 시 Discard Packet 정보를 전송하기 위해 Discarded Sequence Number Low와 Discarded Sequence Number High를 이용하는 방법을 나타낸 예시의 도면이다.
도 13은 Discard packet이 발생하면 Discard Packet 발생 시점에 Receiver로 Discard 된 Packet의 복수개의 정보를 보내기 위한 Packet 구조를 나타낸 도면이다.
예를 들어, Discard된 패킷 정보 전송 시점(Report Type)이 Event type인 경우, Transmitter는 Discard Packet이 발생된 시점부터 Event 만료 시점까지의 Discard Packet 정보들을 전송하는 경우에 본 실시 예를 적용할 수 있다.
도 13의 Discard Packet 정보로는, Discard Packet 정보임을 나타내는 지시자인 Discard Packet Indication(DPI) 및 Discarded Packet의 시작 시점 Sequence Number인 폐기 시퀀스의 낮은 번호(Discarded SN Low)를 포함할 수 있으며, 폐기 시퀀스의 높은 번호(Discarded SN High)를 통해 Discard Packet 종료 시점의 Sequence를 알려 줄 수 있다.
예를 들어, Discard SN Low가 3이며 Discard SN High가 5인 경우, Receiver는 Discard Sequence Number 3, 4, 5에 대해 Discard되었다는 것을 알 수 있다. 또한, Transmitter는 Expansion Bit(E1)를 통해 Discard packet의 시작 시점인 Discard SN Low가 있음을 알려 줄 수 있으며 Expansion Bit(E2)를 통해 Discard packet의 종료 시점의 Sequence Number인 Discard SN High가 있음을 알려줄 수 있다.
또한, Transmitter는 Discard Packet Format을 Discard Packet Reporting 메시지에 포함하여 Dedicated Signaling로 전송 할 수 있다. 예를 들어, Dedicated Signaling 메세지는 RRC Message 또는 MAC Message 또는 PDCP Message, 또는 RLC Message일 수 있다.
도 14는 복수개의 Discard 패킷 발생 시 Discard Packet 정보를 전송하기 위해 비트맵(Bitmap)을 이용하는 방법을 나타낸 예시의 도면이다.
도 14는 Discard packet이 발생하면 Discard Packet 발생 시점에, Receiver로 Discard 된 Packet의 복수개의 정보를 보내기 위한 Packet 구조를 나타낸 도면이다.
예를 들어, Discard된 패킷 정보 전송 시점(Report Type)이 Event type인 경우, Transmitter는 Discard Packet이 발생된 시점부터 Event 만료 시점까지의 Discard Packet 정보들을 전송하는 경우에 본 실시 예를 적용 할 수 있다.
도 14의 Discard Packet 정보로는, Discard Packet 정보임을 나타내는 지시자인 Discard Packet Indication(DPI) 및 Discarded Packet의 시작 시점 Sequence Number인 Discarded SN를 포함할 수 있다. 또한, Transmitter는 Bitmap 정보를 제공하여, Sequence Number 시작 지점부터 어떤 Packet이 Discard 되었는지 알려줄 수 있다. 예를 들어, Discarded SN이 3이고, Bitmap이 2비트인 경우에 1110으로 표현된 경우, Receiver는 Discard된 Packet Sequence가 3, 4, 5임을 알 수 있다.
또한, Transmitter는 Discard Packet Format을, Discard Packet Reporting 메시지에 포함하여 Dedicated Signaling로 전송할 수 있다. 예를 들어 Dedicated Signaling 메세지는 RRC Message 또는 MAC Message 또는 PDCP Message, 또는 RLC Message일 수 있다.
도 15는 복수개의 Discard 패킷 발생 시 Discard Packet 정보를 전송하기 위해 Bitmap을 이용하는 방법에서 비트맵 크기(Bitmap Size)를 알려주는 경우의 예시를 나타낸 도면이다.
도 15는 Discard packet이 발생하면 Discard Packet 발생 시점에, Receiver로 Discard 된 Packet의 복수개의 정보를 보내기 위한 Packet 구조를 나타낸 도면이다.
예를 들어, Discard된 패킷 정보 전송 시점(Report Type)이 Event type인 경우, Transmitter는, Discard Packet이 발생된 시점부터 Event 만료 시점까지의 Discard Packet 정보들을 전송하는 경우에 본 실시 예를 적용할 수 있다.
도 15의 Discard Packet 정보로는, Discard Packet 정보임을 나타내는 지시자인 Discard Packet Indication(DPI) 및 Discarded Packet의 시작 시점 Sequence Number인 Discarded SN를 포함할 수 있다. 또한, Transmitter는, Bitmap 정보를 제공하여 Sequence Number 시작 지점부터 어떤 Packet이 Discard 되었는지 알려줄 수 있다. 예를 들어, Discarded SN가 3이고, Bitmap이 2비트 인 경우에 1110으로 표현된 경우, Receiver는 Discard된 Packet Sequence가 3, 4, 5임을 알 수 있다. 또한, Bitmap Size 지시자를 통해 Bitmap 사이즈를 알려줄 수 있다.
또한, Transmitter는 Discard Packet Format을 Discard Packet Reporting 메시지에 포함하여 Dedicated Signaling로 전송할 수 있다. 예를 들어, Dedicated Signaling 메세지로는 RRC Message 또는 MAC Message 또는 PDCP Message, 또는 RLC Message일 수 있다.
<제2 실시예>
도 16은 본 발명에서 고려하는 헤더 형식이 변경되는 시나리오를 나타낸다. 기존에 송신기(TX)와 수신기(RX)는 기존 형식(Old Format)의 헤더를 가지고 통신을 수행하다가 재설정(Reconfiguration) 또는 설정(Configuration) 절차를 거친 이후부터는 새로운 형식(New Format)으로 통신을 수행하게 된다. 재설정 또는 설정은 3GPP 망의 RRC 메시지나, 아니면 사전에 설정된 조건에 의해 변경될 수 있다.
또한, 도 16과 같은 시나리오가 발생하는 환경은 이종 망 간의 핸드오버(예: 5G 통신망에서 4G 통신망으로 이동하는 경우) 또는 동일 망에서 규격 버전이 다른 기지국으로의 핸드오버(예: 3GPP Release 14 기지국에서 Release 13 기지국으로 변경하는 경우), 또는 동일 기지국 내 기지국이 판단하는 경우 등 여러 가지가 있을 수 있다. 헤더의 형식이 바뀔 때에는, 그 헤더에 있는 순서 번호(Sequence Number, SN)의 크기가 바뀔 수 있다. 예를 들어, 12비트의 SN 크기의 헤더로 통신을 수행하다가 10비트의 SN 크기의 헤더로 통신을 수행하는 것으로 변경될 수 있다.
도 17은 헤더 형식이 변경되는 메시지의 실시 예를 나타낸다. 헤더 형식의 변경을 위해서 3GPP 망의 재설정(Reconfiguration) 메시지가 사용될 수 있다. 이 메시지에는 변경되는 헤더의 종류, 어떤 시스템으로 변경되는지의 정보가 포함될 수도 있다. 만약, 재설정이 동종 망 또는 이종 망 간 핸드오버에 관한 메시지라면, 핸드오버를 수행하게 하는 정보가 포함될 수 있다. 또한, 만약, 재설정 메시지가 단말에서 잘 수신되었다면, 단말은 재설정 후 재설정 완료(Reconfiguration Complete) 메시지를 기지국에 보낼 수 있다. 만약 이것이 핸드오버에 관한 재설정이었다면, 핸드오버 이후 새로운 기지국에게 재설정 완료 메시지를 보낼 수도 있다.
도 18은 포맷이 바뀔 때 재전송이 되는 방식의 실시 예를 나타낸다. 도 18의 실시 예에서는 재설정 메시지 이후에도 기존 형식으로 보내던 메시지의 잔여 전송은 기존 형식으로 보내고, 기존 형식으로 만들어진 데이터가 모두 전송된 후에 새로운 형식으로 데이터 전송을 수행하는 방법을 나타낸다.
도 18의 실시 예에서는 기존 형식으로 통신을 수행할 때 송신기(TX)는 SN 0에서 9까지의 패킷을 보내는 것으로 가정한다. 이때, 하위 계층 또는 무선 링크에서의 전송 지연으로 수신기(RX)에서는, 송신기(TX)에서 보낸 순서와 다르게 순서가 변경되어(Out-of-sequence) 패킷을 수신할 수 있다. 도 18의 실시 예에서는 0, 1, 4, 7, 5, 8의 순서로 패킷을 수신한 것으로 가정한다.
이후, 재설정이 되었기 때문에 이 경우 기존 형식 데이터에 대한 상태 보고(Status Report) 메시지를 송신기에 보내게 된다. 수신기는 수신기가 수신한 가장 최근 SN이 8이기 때문에 현재 SN=8인 패킷까지 수신하였고 2, 3, 6에 해당하는 패킷은 미수신했음을 송신기에 보고하게 된다. 이때, 상태 보고 메시지에 사용되는 순서 번호는, 기존 순서 번호가 사용되거나 PDCP 카운트(PDCP COUNT) 값이 사용되거나, 새로운 순서 번호로 변경되어 사용될 수도 있다.
도 18의 실시 예에서는, 이후에 송신기가, 기 전송을 수행한 2, 3, 6, 9 패킷을 수신기에 보내게 되는데, 이 경우에는 기존 형식의 데이터를 사용하게 된다. 대신, 송신기는 헤더의 형식(Format, F) 필드에 기존(old) 패킷임을 명시하여, 수신기가 기존 형식으로 데이터를 처리할 수 있게 한다. 형식 필드는 기존 패킷인지 새 패킷인지를 명시할 수도 있으나, 다른 실시 예로 형식에 따라 토글(Toggle) 방식으로 표시할 수도 있다. 예를 들어 기존 형식의 패킷은 형식 필드 값을 0으로 설정하고 새 형식의 패킷은 형식 필드 값을 1로 설정하여 보내어, 구분할 수도 있다.
그리고 송신기는, 기존 형식으로 보내는 마지막 패킷의 마지막 패킷 지시자(LPI; Last Packet Indicator) 필드에 마지막(Last) 패킷임을 표시하여, 이후에 다른 패킷은 새로운 형식으로 처리할 수 있게 한다. 이렇게 되면 수신기는 순서 번호, 형식 필드, LPI 필드를 조합하여 재정렬(Reordering)을 수행하여, 손실 없는 통신을 할 수 있게 된다. 이때, 새로운 형식의 순서번호(Sequence Number, SN)는 유지되거나, 변경되거나, 다시 시작될 수도 있다.
도 19는 도 18의 실시 예에서 헤더의 형식이 바뀔 때 헤더 형식의 실시 예이다. 3GPP 통신시스템의 PDCP 계층 형식을 기초로 하여, 본 발명에 필요한 형식(F) 필드, LPI 필드(LPI, Last Packet Indicator)를 포함하였다. D/C는 데이터/제어 정보 필드, R은 예비(Reserved) 필드, SN은 순서번호(Sequence Number) 필드, Data는 데이터 필드이다. 도 19의 실시 예에서는 헤더 형식이 변경되면 SN 필드가 줄어드는 실시 예를 나타낸다. 하지만 SN 필드의 크기는 늘어날 수도 있고 동일하게 유지될 수도 있다.
도 20은 포맷이 바뀔 때 재전송이 되는 방식의 다른 실시 예를 나타낸다. 도 20의 실시 예에서는, 재설정 메시지 이후에 새로운 형식으로 데이터 전송을 바로 수행하게 되는데, 기존 형식으로 보내던 메시지의 잔여 전송에 대하여, 기존 형식 패킷을 신규 형식에 포함시키는 방식으로 데이터 전송을 수행하는 방법을 나타낸다.
도 20의 실시 예에서는 기존 형식으로 통신을 수행할 때 송신기(TX)는 SN 0에서 9까지의 패킷을 보내는 것으로 가정한다. 이때, 하위 계층 또는 무선 링크에서의 전송 지연으로, 수신기(RX)에서는 보낸 순서와 다르게 순서가 변경되어(Out-of-sequence) 패킷을 수신할 수 있다. 도 20의 실시 예에서는 0, 1, 4, 7, 5, 8의 순서로 패킷을 수신한 것으로 가정한다.
이후 재설정이 되었기 때문에, 이 경우 기존 형식 데이터에 대한 상태 보고(Status Report) 메시지를 송신기에 보내게 된다. 수신기는, 수신기가 수신한 가장 최근 SN이 8이기 때문에 현재 SN=8인 패킷까지 수신하였고 2, 3, 6에 해당하는 패킷은 미수신했음을 송신기에 보고하게 된다. 이때, 상태 보고 메시지에 사용되는 순서 번호는 기존 순서 번호가 사용되거나 PDCP COUNT 값이 사용되거나 새로운 순서 번호로 변경되어 사용될 수도 있다.
송신기는 상태 보고 메시지를 수신한 이후에 SN=2, 3, 6, 9에 해당하는 패킷의 재전송을 수행하게 된다. 다만, 헤더 형식이 변경되었기 때문에 2, 3, 6, 9 패킷을 그대로 보내기 어렵게 된다. 도 20의 실시 예에서는, 이때 새로운 형식과 새로운 순서번호(SN)를 사용하고, 대신 데이터 필드에 기존 데이터 필드를 포장하여(Encapsulation) 전송을 하게 된다. 따라서, SN=2, 3, 6, 9에 해당하는 패킷은 새로운 SN인 1, 2, 3, 4에 해당하는 헤더로 포장하여 전송하게 된다. 이때, 포장된 패킷은, 헤더의 인캡슐레이션 지시자(EI; Encapsulation Indicator) 필드에 포장되었음을 나타내는 필드를 포함할 수 있다.
만약, EI 필드가 포장되었음을 나타내는 필드라면, 수신기는 새로운 형식의 헤더를 제거한 이후 기존 형식의 헤더를 처리해야 한다. 만약 수신기에, 기존 형식을 처리하는 장치와 새로운 형식을 처리하는 장치가 분리되어 있다면, 기존 형식을 처리하는 장치에 해당 패킷의 처리를 요청할 수 있다. 만약, 이것이 상향링크 전송일 경우, 기존 형식을 처리하는 장치와 새로운 형식을 처리하는 장치는 각기 다른 기지국 장치일 수도 있다. 기존 SN=9(즉 새로운 SN=4)에 해당하는 패킷은 기존 형식으로 전송되는 마지막 패킷이기 때문에 패킷의 LPI(Last Packet Indicator) 필드에 마지막(Last) 패킷임을 표시하여, 이후에 다른 패킷은 새로운 형식으로 처리할 수 있게 한다. 이후에 송신되는 SN=5, 6에 해당하는 패킷은 새로운 형식 자체로 전송될 수 있다. 이렇게 되면 수신기는 재정렬(Reordering)을 수행하여 손실 없는 통신을 할 수 있게 된다.
도 21은 도 20의 실시 예에서 헤더의 형식이 바뀔 때 헤더 형식의 실시 예이다. 도 21에 따르면, 3GPP 통신시스템의 PDCP 계층 형식을 기초로 하여 본 발명에 필요한 EI(Encapsulation Indicator) 필드, LPI 필드(LPI, Last Packet Indicator)를 포함하였다. D/C는 데이터/제어 정보 필드, R은 예비(Reserved) 필드, SN은 순서번호(Sequence Number) 필드, Data는 데이터 필드이다. EI 필드에 포장되었음을 표시하게 되면, 데이터 필드에는 기존 형식의 헤더 및 데이터가 포함되게 된다. 도 21의 실시 예에서는 헤더 형식이 변경되면 SN 필드가 줄어드는 실시 예를 나타낸다. 하지만 SN 필드의 크기는 늘어날 수도 있고 동일하게 유지될 수도 있다.
도 22는 재설정 이후에 기존 형식의 데이터 처리가 필요하게 될 경우 기존 형식을 처리할 수 있는 예전 장치(Old Entity)에, 기존 형식의 데이터(Old Format Data)를 보내어 처리를 요청하는 절차를 나타낸다. 예전 장치는 이 데이터를 처리한 이후에 새 장치로 보낼 수도 있고 자체적으로 처리를 수행할 수도 있다. 만약, 이것이 상향링크 전송일 경우, 기존 형식을 처리하는 장치와 새로운 형식을 처리하는 장치는 각기 다른 기지국 장치일 수도 있다.
도 23은 3GPP 통신 시스템에서의 PDCP COUNT 구조를 나타낸다. COUNT는 고정 길이를 가지고 하이퍼 프레임 넘버(HFN; Hyper Frame Number) 필드와 SN 필드로 나뉘어 진다. SN 필드의 크기는 가변이지만 COUNT의 길이는 고정이다. 3GPP 통신 시스템에서는 32비트의 COUNT 길이를 가진다. 따라서, 만약 SN 필드의 길이가 N 비트라면, HFN은 32-N 비트의 길이를 가지게 된다. 본 발명에서는 도 16을 포함한 본 발명에서 헤더 형식이 바뀐 경우에 이 COUNT 값을 사용하여 재정렬(Reordering)을 수행하는 방법을 제안한다. COUNT 값은 3GPP 통신시스템에서 PDCP 계층의 값들 중 하나이다.
HFN, SN 값과 COUNT 값과의 연산관계는 다음과 같다.
[수식 1]
COUNT = HFN*(2N) + SN
여기에서 N은 SN의 길이(N 비트)이다.
만약에 COUNT 값에서 N 비트 PDCP SN와 HFN을 유도하는 관계는 다음과 같다.
[수식 2]
Figure PCTKR2018001457-appb-I000001
[수식 3]
SN = mod(COUNT, 2N)
상기 수식 1-3의 대응관계는 도 24-25의 실시 예에서 사용된다.
도 24에서는 재설정 시에 COUNT를 사용하여 재정렬을 하는 방법의 실시 예를 나타낸다. 도 24의 실시 예에서 기존 형식에서는 5비트의 SN 크기(0-31 SN), 새로운 형식에서는 4비트의 SN 크기(0-15)를 가지는 것을 가정한다. 이때, Reordering을 위한 PDCP 윈도우(PDCP Window)는 통상적으로 가능한 SN 전체의 절반으로 가정된다.
도 24의 실시 예에서는 HFN=15에서 재설정이 발생하여 새로운 형식으로 전송되는 것을 가정한다. 이때, 재설정 이후 전송되는 형식은 새로운 형식으로 전송되는 것을 가정한다. 대신, 이때 송신기와 수신기에서는 동일한 COUNT를 가지는 HFN과 SN으로 변경하여 패킷을 전송하게 된다. 도 24의 실시 예에서는 Old HFN=15에서 SN=6, 9, 10, 11, 12, 13, 14, 18 패킷을 제외한 SN=19까지의 패킷이 수신되지 않은 상황을 가정한다.
재설정 이후에 상태 보고 메시지를 받은 후, 송신기는 해당 패킷을, 이전 HFN 및 SN에 대응하는 COUNT 값(486,489, 490, 491, 492, 493, 494, 498)으로 환산한 후 새로운 형식의 HFN 및 SN으로 환산하여, New HFN=30의 SN=6, 9, 10, 11, 12, 13, 14와 New HFN=31, SN=2의 값으로 바꾼 후에 수신기에 패킷을 전송하게 된다. 수신기는 재설정 이전에 받은 패킷은 이전 HFN, SN 값으로 COUNT를 환산하고, 재설정 이후에 받은 패킷은 새로운 HFN, SN 값으로 COUNT를 환산하여 재정렬(Reordering)을 수행할 수 있다.
도 25는 재설정 시에 HFN 값과 COUNT를 변경하는 또 다른 실시 예를 나타낸다. 도 25의 실시 예에서 기존 형식에서는 4비트의 SN 크기(0-15 SN), 새로운 형식에서는 5비트의 SN 크기(0-31)를 가지는 것을 가정한다. 이때, Reordering을 위한 PDCP Window는 통상적으로 가능한 SN 전체의 절반으로 가정된다.
도 25의 실시 예에서는 HFN=30에서 재설정이 발생하여 새로운 형식으로 전송되는 것을 가정한다. 이때, 재설정 이후 전송되는 형식은 새로운 형식으로 전송되는 것을 가정한다. 이때, SN의 크기가 줄어들었기 때문에 그만큼 HFN은 증가하게 된다. 이 관계는 [수식 1-3]의 COUNT가 보존되는 HFN, SN 변환 관계를 사용하여 COUNT가 보존되게 변경될 수 있다.
도 25의 실시 예를 보면, 재설정 시점에 HFN =30의 SN=13, 14 패킷과 HFN=31, SN=2 패킷이 수신기에서 수신되지 않은 상황이다. 재설정 이후엔 환산과정을 거쳐서 HFN=15, SN=13, 14, 18로 변경하여 재전송을 수행하고 재정렬 과정을 거칠 수 있다.
도 26-27은 본 발명에서 고려하는 헤더 형식이 변경되는 또 다른 시나리오를 나타낸다. 기존에 TX와 RX는 기존 형식(Old Format)의 헤더를 가지고 통신을 수행하다가, 재설정(Reconfiguration) 또는 설정(Configuration) 절차를 거친 후 이후부터는 임시 형식으로 통신을 수행하다가, 일정 시점 후에 새로운 형식(New Format)으로 통신을 수행하게 된다. 재설정 또는 설정은 3GPP 망의 RRC 메시지나 아니면 사전에 설정된 조건에 의해 변경될 수 있다. 또한, 도 26-27과 같은 재설정 또는 설정 시나리오가 발생하는 환경은 이종 망 간의 핸드오버(예: 5G 통신망에서 4G 통신망으로 이동하는 경우) 또는 동일 망에서 규격 버전이 다른 기지국으로의 핸드오버(예: 3GPP Release 14 기지국에서 Release 13 기지국으로 변경하는 경우), 또는 동일 기지국 내 기지국이 판단하는 경우 등 여러 가지가 있을 수 있다.
헤더의 형식이 바뀔 때에는 그 헤더에 있는 순서 번호(Sequence Number, SN)의 크기가 바뀔 수 있다. 도 26의 실시 예에서는 순서 번호의 크기가 상대적으로 길었으나 임시 순서번호를 사용한 이후에는 순서번호의 크기가 상대적으로 짧은 것을 나타낸다. 예를 들어, 12비트의 SN 크기의 헤더로 통신을 수행하다가 10비트의 SN 크기의 헤더로 통신을 수행하는 것으로 변경될 수 있다.
도 27의 실시 예에서는 순서 번호의 크기가 상대적으로 짧았으나 임시 순서번호를 사용한 이후에는 순서번호의 크기가 상대적으로 길어지는 것을 나타낸다. 예를 들어 12비트의 SN 크기의 헤더로 통신을 수행하다가 18비트의 SN 크기의 헤더로 통신을 수행하는 것으로 변경될 수 있다.
도 26-27의 임시 SN은 재설정 또는 설정이 되는 직후에 패킷의 손실없는 전달을 하기 위한 목적으로 사용될 수 있으며, PDCP COUNT 값이나 다른 약속된 공통의 크기의 순서번호(SN)일 수도 있다. 본 발명에서는 헤더의 형식이 바뀐다는 것을 SN 길이가 바뀐다는 것과 혼용하여 기술할 것이나, 본질적으로 이들간의 차이는, 본 발명의 실시 예에서는 없다. 상기 임시 형식으로 통신을 수행하다가 새로운 형식으로 통신을 수행하게 되는 일정 시점에 대한 정보 또는 일정 시점을 판단하는 조건 정보는 상기 재설정 또는 설정을 통해 지시될 수 있다.
도 28은 상향링크 데이터에 대해 헤더 형식이 바뀌는 절차를 나타낸다. 도 28의 실시예의 예전 형식은 상대적으로 길이가 긴 SN 크기가 포함되는 것이 될 수 있고 새로운 형식은 상대적으로 길이가 짧은 SN 크기가 포함되는 것일 수 있다. 또는 반대의 경우도 가능하다. 또한 임시 형식은 PDCP COUNT 값이나 다른 약속된 공통의 크기의 순서번호(SN)일 수도 있다.
도 28의 실시예의 시작시점에는 단말(280)이 기지국(281)에게 예전 형식으로 패킷을 전송(1)한다. 이후 단말(280)은 기지국(281)으로부터 재설정(Reconfiguration) 메시지를 받고(2) 새로운 형식으로 전송해야 함을 인식한다. 이 때 수신기, 다시 말해서 기지국(281)이 수신한 패킷의 정보를 확인하기 위해서 수신기 상태 보고 메시지(Status report)를 송신기, 즉 단말(280)에게 보내게 된다(3). 이 때 기지국(281)과 단말(280)의 PDCP 장치(Entity)에서 이 역할을 담당할 수 있다. 이 상태 보고 메시지에는 어떤 패킷이 수신되었는지, 어떤 패킷이 수신되지 않거나 재전송이 필요한지 정보가 들어가 있다.
상태 보고 메시지는 처음 수신되지 않은 순서 번호 또는 COUNT 값과 이후 패킷의 수신상태를 나타내는 비트맵(Bitmap)을 포함할 수 있다. 자세한 상태 보고 메시지는 도 32-33에 나타난다. 단말(280)은 재설정 메시지를 받은 후부터는 임시 형식으로 패킷을 전송(4)하게 된다.
단말(280)은 사전에 설정된 만큼 임시 형식으로 패킷을 전송(4, 5, 6)하고 이후부터 재설정 메시지에서 지시된 새로운 형식으로 패킷을 전송(7)할 수 있다. 이 때 상태 보고 메시지에 표시된 FMS(First Missing SN)이나 FMC(First Missing COUNT)보다 정해진 만큼 큰 SN 또는 COUNT 값을 가지는 패킷까지 임시 형식으로 보낼 수 있다. 이 정해진 만큼의 크기는 예전 형식에서 사용하는 PDCP Window 크기 또는 그의 정수 배만큼 일 수 있다. 송신기, 즉 단말(280)은 임시 형식으로 전송한 후 새로운 형식으로 패킷을 전송(8)하게 되지만 무선 채널에서 재전송을 겪게 되기 때문에, 기지국(281)은 임시 형식의 데이터와 새로운 형식의 데이터의 순서가 섞여서 수신할 수도 있다. 이런 경우 헤더 형식을 구분하기 위해 패킷이 임시 형식을 사용하는지 구분하는 지시자가 필요하다. 자세한 헤더 형식은 도 34-35에 나타난다.
도 29는 하향링크 데이터에 대해 헤더 형식이 바뀌는 절차를 나타낸다. 도 29의 실시예의 예전 형식은 상대적으로 길이가 긴 SN 크기가 포함되는 것이 될 수 있고 새로운 형식은 상대적으로 길이가 짧은 SN 크기가 포함되는 것일 수 있다. 또는 반대의 경우도 가능하다. 또한 임시 형식은 PDCP COUNT 값이나 다른 약속된 공통의 크기의 순서번호(SN)일 수도 있다.
도 29의 실시예의 시작시점에는 기지국(291)이 단말(290)에게 예전 형식으로 패킷을 전송(1)한다. 이후 기지국(291)으로부터 재설정(Reconfiguration) 메시지를 받고(2), 새로운 형식으로 전송해야 함을 인식한다. 이 때 수신기, 다시 말해서 단말(290)이 수신한 패킷의 정보를 확인하기 위해서 수신기 상태 보고 메시지(Status report)를 송신기, 즉 기지국(291)에게 보내게 된다(3). 이 때 기지국(291)과 단말(290)의 PDCP 장치(Entity)에서 이 역할을 담당할 수 있다. 이 상태 보고 메시지에는 어떤 패킷이 수신되었는지, 어떤 패킷이 수신되지 않거나 재전송이 필요한지 정보가 들어가 있다.
상태 보고 메시지는 처음 수신되지 않은 순서 번호 또는 COUNT 값과 이후 패킷의 수신상태를 나타내는 비트맵(Bitmap)을 포함할 수 있다. 자세한 상태 보고 메시지는 도 32-33에 나타난다. 기지국(291)은 재설정 메시지를 송신한 후부터는 임시 형식으로 패킷을 전송(4)하게 된다.
기지국(291)은 사전에 설정된 만큼 임시 형식으로 패킷을 전송(5, 6)하고 이후부터 재설정 메시지에서 지시된 새로운 형식으로 패킷을 전송(7)할 수 있다. 이 때 상태 보고 메시지에 표시된 FMS(First Missing SN)이나 FMC(First Missing COUNT)보다 정해진 만큼 큰 SN 또는 COUNT 값을 가지는 패킷까지 임시 형식으로 보낼 수 있다. 이 정해진 만큼의 크기는 예전 형식에서 사용하는 PDCP Window 크기 또는 그의 정수배만큼 일 수 있다.
송신기, 즉 기지국(291)은 임시 형식으로 전송한 후 새로운 형식으로 패킷을 전송(8)하게 되지만 무선 채널에서 재전송을 겪게 되기 때문에 단말(290)은 임시 형식의 데이터와 새로운 형식의 데이터의 순서가 섞여서 수신할 수도 있다. 이런 경우 헤더 형식을 구분하기 위해 패킷이 임시 형식을 사용하는지 구분하는 지시자가 필요하다. 자세한 헤더 형식은 도 34-35에 나타난다.
도 30은 상향링크 데이터에 대해 헤더 형식이 바뀌는 절차를 나타낸다. 도 30의 실시예의 예전 형식은 상대적으로 길이가 긴 SN 크기가 포함되는 것이 될 수 있고 새로운 형식은 상대적으로 길이가 짧은 SN 크기가 포함되는 것일 수 있다. 또는 반대의 경우도 가능하다. 또한, 임시 형식은 PDCP COUNT 값이나 다른 약속된 공통의 크기의 순서번호(SN)일 수도 있다.
도 30의 실시예의 시작시점에는 단말(300)이 제 1 기지국(301)에게 예전 형식으로 패킷(1)을 전송한다. 이후 제 1 기지국(301)으로부터 재설정(Reconfiguration) 메시지를 받고(2), 이후 제 2 기지국(302)으로 데이터를 새로운 형식으로 전송해야 함을 인식한다. 이 때 기존 수신기, 다시 말해서 제 1 기지국(301)이 수신한 패킷의 정보를 확인하기 위해서 수신기 상태 보고 메시지(Status report)를 송신기, 즉 단말(300)에게 보내게 된다(3).
또한, 제 1 기지국(301)은 제 2 기지국(302)에게도 상태 보고 메시지를 보낼 수도 있다(4). 또한, 제 1 기지국(301)이 직접 단말에게 상태보고 메시지를 보내지 않고 제 2 기지국(302)이 단말에게 상태 보고 메시지를 보낼 수도 있다. 이러한 상태 보고 메시지를 보내는 절차는 기지국과 단말의 PDCP 장치(Entity)에서 담당할 수 있다. 이 상태 보고 메시지에는 어떤 패킷이 수신되었는지, 어떤 패킷이 수신되지 않거나 재전송이 필요한지 정보가 들어가 있다. 상태 보고 메시지는 처음 수신되지 않은 순서 번호 또는 COUNT 값과 이후 패킷의 수신상태를 나타내는 비트맵(Bitmap)을 포함할 수 있다. 자세한 상태 보고 메시지는 도 32-33에 나타난다.
단말(300)은 재설정 메시지를 받은 후부터는 임시 형식으로 패킷을 전송(5)하게 된다. 단말(300)은 사전에 설정된 만큼 임시 형식으로 패킷을 전송(6, 7)하고 이후부터 재설정 메시지에서 지시된 새로운 형식으로 패킷을 전송(8)할 수 있다. 이 때 상태 보고 메시지에 표시된 FMS(First Missing SN)이나 FMC(First Missing COUNT)보다 정해진 만큼 큰 SN 또는 COUNT 값을 가지는 패킷까지 임시 형식으로 보낼 수 있다. 이 정해진 만큼의 크기는 예전 형식에서 사용하는 PDCP Window 크기 또는 그의 정수배만큼 일 수 있다.
송신기, 즉 단말(300)은 임시 형식으로 패킷을 전송한 후 새로운 형식으로 패킷을 전송(9)하게 되지만 무선 채널에서 재전송을 겪게 되기 때문에 기지국은 임시 형식의 데이터와 새로운 형식의 데이터의 순서가 섞여서 수신할 수도 있다. 이런 경우 헤더 형식을 구분하기 위해 패킷이 임시 형식을 사용하는지 구분하는 지시자가 필요하다. 자세한 헤더 형식은 도 34-35에 나타난다.
도 31은 하향링크 데이터에 대해 헤더 형식이 바뀌는 절차를 나타낸다. 도 31의 실시예의 예전 형식은 상대적으로 길이가 긴 SN 크기가 포함되는 것이 될 수 있고 새로운 형식은 상대적으로 길이가 짧은 SN 크기가 포함되는 것일 수 있다. 또는 반대의 경우도 가능하다. 또한, 임시 형식은 PDCP COUNT 값이나 다른 약속된 공통의 크기의 순서번호(SN)일 수도 있다.
도 31의 실시예의 시작시점에는 제 1 기지국(311)이 단말(310)에게 예전 형식으로 패킷을 전송(1)한다. 이후, 단말(310)은 제1 기지국(311)으로부터 재설정(Reconfiguration) 메시지를 받고(2), 이후 제 2 기지국(312)으로 데이터를 새로운 형식으로 수신해야 함을 인식한다. 제1 기지국(311)은 제2 기지국으로 데이터를 전달(data forwarding) 한다(3).
이 때 기존 수신기, 다시 말해서 단말(310)이 수신한 패킷의 정보를 확인하기 위해서 수신기 상태 보고 메시지(Status report)를 새로운 송신기, 즉 제 2 기지국(312)에게 보내게 된다(4). 이러한 상태 보고 메시지를 보내는 절차는 기지국과 단말의 PDCP 장치(Entity)에서 담당할 수 있다. 이 상태 보고 메시지에는 어떤 패킷이 수신되었는지, 어떤 패킷이 수신되지 않거나 재전송이 필요한지 정보가 들어가 있다. 상태 보고 메시지는 처음 수신되지 않은 순서 번호 또는 COUNT 값과 이후 패킷의 수신상태를 나타내는 비트맵(Bitmap)을 포함할 수 있다. 자세한 상태 보고 메시지는 도 32-33에 나타난다.
단말(310)은 재설정 메시지를 받은 후부터는 임시 형식으로 패킷을 수신하게 된다. 제 2 기지국(312)은 사전에 설정된 만큼 임시 형식으로 패킷을 전송(5, 6, 7)하고, 이후부터 재설정 메시지에서 지시된 새로운 형식으로 패킷을 전송(8)할 수 있다. 이 때 상태 보고 메시지에 표시된 FMS(First Missing SN)이나 FMC(First Missing COUNT)보다 정해진 만큼 큰 SN 또는 COUNT 값을 가지는 패킷까지 임시 형식으로 보낼 수 있다. 이 정해진 만큼의 크기는 예전 형식에서 사용하는 PDCP Window 크기 또는 그의 정수배만큼 일 수 있다.
송신기, 즉 제 2 기지국(312)은 임시 형식으로 전송한 후 새로운 형식으로 패킷을 전송(9)하게 되지만 무선 채널에서 재전송을 겪게 되기 때문에 단말은 임시 형식의 데이터와 새로운 형식의 데이터의 순서가 섞여서 수신할 수도 있다. 이런 경우 헤더 형식을 구분하기 위해 패킷이 임시 형식을 사용하는지 구분하는 지시자가 필요하다. 자세한 헤더 형식은 도 34-35에 나타난다.
도 32는 상태 보고 메시지의 형식의 실시예를 나타낸다. 상태 보고 메시지에는 D/C 필드, PDU Type 필드, FMS (First Missing SN) 필드, 비트맵(Bitmap) 필드 등이 포함될 수 있다. D/C 필드는 해당 PDU(Protocol Data Unit, 메시지, 패킷)이 데이터 PDU인지 제어(Control) PDU인지를 지시하는 지시자이다. 상태 보고 메시지는 제어 PDU의 종류이기 때문에 제어 메시지를 나타내는 값으로 표시될 수 있다. PDU Type은 해당 PDU의 세부종류를 나타내는 비트로서 도 32에서는 3비트 값으로 가정하였다. 본 발명의 실시예에 따라 PDU Type 필드는 상태 보고 메시지를 나타내는 값으로 표시될 수 있다.
FMS 필드는 상태 보고 메시지가 전송되는 시점 또는 재설정 메시지 내지 설정 메시지를 수신하는 시점에 수신기가 미수신한 것으로 판단되는 패킷의 순서 번호 중 가장 앞선 패킷의 순서 번호값(SN)으로 설정된다. 이 때의 순서번호는 재설정 이전에 사용하던 예전 형식의 순서번호나, 재설정 이후에 사용할 새로운 형식의 순서 번호나, 임시 형식의 순서번호가 될 수 있다.
비트맵(Bitmap) 필드는 FMS 필드에 표시된 순서번호에 해당하는 패킷 이후의 패킷에 대한 수신/미수신 상태를 표시한 비트로서 미수신이면 0, 수신이면 1 (또는 반대로)로 설정될 수 있다. 가령 FMS에 표시된 순서번호가 5인 경우, 비트맵 필드의 첫 번째 비트는 순서번호 6에 해당하는 패킷의 수신/미수신 상태를 나타내고 비트맵 필드의 다섯 번째 비트는 순서번호 10에 해당하는 패킷의 수신/미수신 상태를 나타내는 식으로 설정될 수 있다.
도 33은 상태 보고 메시지의 형식의 다른 실시예를 나타낸다. 상태 보고 메시지에는 D/C 필드, PDU Type 필드, FMC (First Missing COUNT) 필드, 비트맵(Bitmap) 필드 등이 포함될 수 있다. D/C 필드는 해당 PDU(Protocol Data Unit, 메시지, 패킷)이 데이터 PDU인지 제어(Control) PDU인지를 지시하는 지시자이다. 상태 보고 메시지는 제어 PDU의 종류이기 때문에 제어 메시지를 나타내는 값으로 표시될 수 있다.
PDU Type은 해당 PDU의 세부종류를 나타내는 비트로서 도 33에서는 3비트 값으로 가정하였다. PDU Type 필드는 상태 보고 메시지를 나타내는 값으로 표시될 수 있다. FMC 필드는 상태 보고 메시지가 전송되는 시점 또는 재설정 메시지 내지 설정 메시지를 수신하는 시점에 수신기가 미수신한 것으로 판단되는 패킷의 PDCP COUNT 중 가장 앞선 패킷의 PDCP COUNT 값으로 설정된다. 비트맵(Bitmap) 필드는 FMC 필드에 표시된 PDCP COUNT에 해당하는 패킷 이후의 패킷에 대한 수신/미수신 상태를 표시한 비트로서 미수신이면 0, 수신이면 1 (또는 반대로)로 설정될 수 있다. 가령 FMC에 표시된 PDCP COUNT가 5인 경우, 비트맵 필드의 첫번째 비트는 COUNT 6에 해당하는 패킷의 수신/미수신 상태를 나타내며 비트맵 필드의 다섯번째 비트는 COUNT 10에 해당하는 패킷의 수신/미수신 상태를 나타내는 식으로 설정될 수 있다.
도 34는 COUNT를 포함하는 PDCP 데이터 PDU의 형식을 나타낸다. PDCP 데이터 PDU 형식은 D/C 필드, F필드, R필드, COUNT 필드, 데이터(Data) 필드 등을 포함할 수 있다. D/C 필드는 해당 PDU(Protocol Data Unit, 메시지, 패킷)이 데이터 PDU인지 제어(Control) PDU인지를 지시하는 지시자이다. PDCP 데이터 PDU의 D/C 필드는 데이터 PDU를 나타내는 값으로 표시될 수 있다. F필드는 이 데이터 PDU가 임시 형식의 순서번호를 포함하는지 아닌지를 나타낸다.
도 34의 실시예에서는 COUNT를 순서번호로 사용하는 실시예이다. 만약 도 34의 실시예가 임시형식으로 사용된다면 F필드는 임시 형식을 나타내는 값으로 설정될 수 있다. R필드는 특정 값으로 사용하지 않는 예비(Reserved) 필드이며, COUNT 필드는 해당 PDU의 PDCP COUNT 값을 나타낸다. 데이터(Data) 필드는 PDCP SDU(Service Data Unit)으로 암호화 된 값이 사용될 수도 있다. 이 외에 무결성 보호를 위한 MAC-I 필드 등이 추가될 수도 있다.
도 35는 PDCP 순서 번호(SN)를 포함하는 PDCP 데이터 PDU의 형식을 나타낸다. PDCP 데이터 PDU 형식은 D/C 필드, F필드, R필드, PDCP 순서번호(SN) 필드, 데이터(Data) 필드 등을 포함할 수 있다.
D/C 필드는 해당 PDU(Protocol Data Unit, 메시지, 패킷)이 데이터 PDU인지 제어(Control) PDU인지를 지시하는 지시자이다. PDCP 데이터 PDU의 D/C 필드는 데이터 PDU를 나타내는 값으로 표시될 수 있다. F필드는 이 데이터 PDU가 임시 형식의 순서번호를 포함하는지 아닌지를 나타낸다. 만약 도 35의 실시예가 임시형식으로 사용된다면 F필드는 임시 형식을 나타내는 값으로 설정될 수 있다. 실시예에 따라 임시 형식은 도 35와 같은 PDCP SN를 사용하는 형식이 될 수도 있다. R필드는 특정 값으로 사용하지 않는 예비(Reserved) 필드이며, PDCP SN 필드는 해당 PDU의 PDCP 순서 번호 값을 나타낸다. 데이터(Data) 필드는 PDCP SDU(Service Data Unit)으로 암호화 된 값이 사용될 수도 있다. 이 외에 무결성보호를 위한 MAC-I 필드 등이 추가될 수도 있다.
도 36은 수신기의 PDCP 장치에서 도 34-35의 PDCP 데이터 PDU 형식을 구분하여 디코딩하는 방법을 나타낸다. 도 28-31 또는 도 50-53의 실시예에 따라 재설정 메시지가 수신되면 수신기는 순서 번호 및 순서 번호를 포함하는 헤더 형식을 재설정(1, 2)할 수 있다. 이후 수신기는 상태 보고 메시지를 송신기에 보내게 되고 이를 바탕으로 송신기는 패킷을 재전송 할 수 있다.
수신기는 순서 번호 재설정 이후에 패킷 수신을 재개(3)하게 되고 이 때 수신되는 데이터 PDU가 도 34의 COUNT가 포함된 형식인지 도 35의 재설정된 PDCP SN을 포함하는 형식인지를 구분하게 된다. 이 때 도 34-35의 F 필드의 값으로 COUNT가 포함된 형식인지 재설정된 새로운 PDCP SN을 포함하는 형식인지를 구분(4)할 수 있다. 만약 COUNT가 포함된 형식의 PDCP 데이터 PDU라면 COUNT가 포함된 형식으로 판단하여 패킷을 디코딩(5)할 수 있고, 그렇지 않다면 재설정된 PDCP SN을 포함하는 새로운 형식으로 패킷을 디코딩(6)할 수 있다.
도 37은 수신기의 PDCP 장치에서 도 34-35의 PDCP 데이터 PDU 형식을 구분하여 디코딩하는 방법을 나타낸다. 도 28-31 또는 도 50-53의 실시예에 따라 재설정 메시지가 수신되면 수신기는 순서 번호 및 순서 번호를 포함하는 헤더 형식을 재설정(1, 2)할 수 있다. 이후 수신기는 상태 보고 메시지를 송신기에 보내게 되고 이를 바탕으로 송신기는 패킷을 재전송 할 수 있다.
수신기는 순서 번호 재설정 이후에 패킷 수신을 재개(3)하게 되고 이 때 수신되는 데이터 PDU가 임시형식의 PDCP SN을 포함하는 형식인지 재설정된 PDCP SN을 포함하는 형식인지를 구분하게 된다. 이 때 도 35의 F 필드의 값으로 임시형식의 PDCP SN을 포함하는 형식인지 재설정된 PDCP SN을 포함하는 형식인지를 구분(4)할 수 있다. 만약 임시형식의 PDCP SN이 포함된 형식의 PDCP 데이터 PDU라면 임시형식의 PDCP SN이 포함된 형식으로 판단하여 패킷을 디코딩(5)할 수 있고, 그렇지 않다면 재설정된 PDCP SN을 포함하는 새로운 형식으로 패킷을 디코딩(6)할 수 있다.
도 38은 PDCP SN의 길이가 바뀌는 패킷 형식 재설정에 의해 PDCP SN이 바뀌는 실시예를 나타낸다. 도 38의 실시예에서 기존 형식에서는 7비트의 SN 크기(0-127 SN), 새로운 형식에서는 5비트의 SN 크기(0-31)를 가지는 것을 가정한다. 도 38의 실시 예에서는 재설정이 되는 시점에 수신기의 PDCP 장치에서는 PDCP COUNT 8500033, 8500034, 8500038, 8500043, 8500055, 8500059, 8500065, 8500066, 8500069, 8500070, 8500071 및 그 이후 COUNT 값에 해당하는 패킷들이 미수신 상태인 것을 가정한다.
이 패킷들은 재설정 이후 재전송이 필요하며 PDCP COUNT, 임시 형식의 SN, 새로운 형식의 SN 중 하나를 포함하는 헤더가 포함되어 전송될 수 있다. 이 패킷들의 기존 형식의 HFN 값은 66407로 동일하고 PDCP SN은 65, 66,70, 75, 87, 91, 97, 98, 101, 102, 103, 및 그 이후 PDCP SN의 값에 대응된다. 상기 미수신 패킷들은 새 형식의 PDCP SN값 1,2,6,11,23,27(HFN 265626), 1,2,5,6,7(HFN 265627) 및 그 이후 PDCP SN의 값에 대응되게 된다. 이 때 같은 PDCP SN 값을 갖는 패킷들이 존재할 수 있는데 이러한 같은 PDCP SN 값은 HFN 비동기화(Desynchronization)을 일으킬 수 있다.
도 38의 실시예에서 COUNT 8500033에 해당하는 패킷과 COUNT 8500065에 해당하는 패킷은 모두 PDCP SN 1에 대응하기 때문에 만약 새로운 형식의 SN로 전송된다면 수신기에서 HFN 값을 정확히 판단하기 어려울 수 있다. 뿐만 아니라 COUNT 8500034에 해당하는 패킷과 COUNT 8500066에 해당하는 패킷도 모두 PDCP SN 2에 대응하기 때문에 만약 새로운 형식의 SN로 전송된다면 수신기에서 HFN 값을 정확히 판단하기 어려울 수 있다. 이 때 특정 패킷들에 대해 도 34의 PDCP COUNT를 포함한 헤더를 사용하여 패킷을 전송할 수 있다. 이를 통해 HFN 값을 정확히 판단할 수 있다. HFN과 SN 값과의 관계는 상기 수식 1-3을 따른다.
도 39는 PDCP SN의 길이가 바뀌는 패킷 형식 재설정 이후 미수신 패킷이 재전송되는 절차의 실시예를 나타낸다. 도 39에서는 재설정(Reconfiguration)으로 인해 PDCP SN의 크기가 7비트에서 5비트로 변경되는 것을 가정하고 이 때의 패킷 수신 상황은 도 38의 수신상황과 같다고 가정한다. 따라서 이 때 Status Report는 수신기에서 송신기로 전송될 수 있고 도 33의 실시예에 나타난 것과 같이 FMC와 비트맵(Bitmap)을 포함하거나 도 32의 실시예에 나타난 것과 같이 FMS와 비트맵을 포함할 수 있다. 도 39에서는 FMC와 비트맵을 포함하는 도 33의 상태보고(Status Report)로 전송되는 것을 가정하여 기술한다.
FMC는 미 수신한 패킷 중 COUNT 값이 가장 작은 패킷의 COUNT 값을 표시하게 되어 8500033이 표시된다. 그리고 이 패킷 이후의 패킷에 대해서는 비트맵으로 수신상태를 표시하게 된다. 도 39의 실시 예에서는 미수신이면 0, 수신이면 1로 표시하였다. 따라서 비트맵은 01110 11110 11111 11111 10111 01111 10011로 표시될 수 있다. 즉 COUNT 값이 8500034, 8500038, 8500043, 8500055, 8500059, 8500065, 8500066인 패킷들의 미수신임을 비트 0으로 명시하였고 PDCP COUNT가 8500068인 패킷까지 수신하였음을 나타낼 수 있다.
이것을 바탕으로 송신기는 미수신 패킷의 재전송을 수행하게 된다. 이 때 이들 패킷에 대해 도 34의 PDCP COUNT를 포함하는 PDU 형식으로 패킷을 전송하게 된다. 이렇게 COUNT가 표시된 패킷들은 HFN 비동기화(Desynchronization)가 생기지 않는다. 이후 PDCP COUNT 8500069 이상에 해당하는 패킷들은 새로운 SN 값인 5부터 사용하여 전송하게 된다.
도 39의 실시예에서는 상태 보고(Status Report) 메시지에 포함된 미수신 패킷(상기 실시예에서 COUNT 8500066)까지만 PDCP COUNT 값을 사용하여 패킷을 전송하였지만, 이 시점은 사전에 설정된 다른 시점으로 변동될 수 있다. 예를 들어, 상태 보고 메시지에서 표시된 수신된 것으로 표시된 패킷의 COUNT 값(상기 실시예에서 COUNT 8500068)에서 일정한 값만큼 높은 PDCP COUNT를 가지는 패킷까지 COUNT가 포함된 형식으로 전송할 수도 있다. 여기에서 일정한 값은 새로운 형식의 PDCP SN에 해당하는 PDCP 수신 Window 크기가 될 수도 있다. 수신 Window의 크기는 2( PDCP SN 크기-1)로 사용될 수도 있는데 5비트 PDCP SN에 대한 수신 Window 크기는 2(5-1)=16이 될 수 있다. 이 때 PDCP COUNT를 사용한 형식인지 PDCP SN을 사용한 형식인지는 도 34-35의 F필드로 구분할 수 있다.
도 40은 PDCP SN의 길이가 바뀌는 패킷 형식 재설정에 의해 PDCP SN이 바뀌는 실시예를 나타낸다. 도 40의 실시예에서 기존 형식에서는 7비트의 SN 크기(0-127 SN), 새로운 형식에서는 5비트의 SN 크기(0-31)를 가지는 것을 가정한다.
도 40의 실시예에서는 재설정이 되는 시점에 수신기의 PDCP 장치에서는 PDCP COUNT 8500033, 8500034, 8500038, 8500043, 8500055, 8500059, 8500065, 8500066, 8500069, 8500070, 8500071 및 그 이후 COUNT 값에 해당하는 패킷들이 미수신 상태인 것을 가정한다. 이 패킷들은 재설정 이후 재전송이 필요하며 PDCP COUNT, 임시 형식의 SN, 새로운 형식의 SN 중 하나를 포함하는 헤더가 포함되어 전송될 수 있다. 이 패킷들의 기존 형식의 HFN 값은 66407로 동일하고 PDCP SN은 65, 66,70, 75, 87, 91, 97, 98, 101, 102, 103, 및 그 이후 PDCP SN의 값에 대응된다.
상기 미수신 패킷들은 새 형식의 PDCP SN값 1,2,6,11,23,27(HFN 265626), 1,2,5,6,7(HFN 265627) 및 그 이후 PDCP SN 값에 대응되게 된다. 이 때 같은 PDCP SN 값을 갖는 패킷들이 존재할 수 있는데 이러한 같은 PDCP SN 값은 HFN 비동기화(Desynchronization)을 일으킬 수 있다.
도 40의 실시예에서 COUNT 8500033에 해당하는 패킷과 COUNT 8500065에 해당하는 패킷은 모두 PDCP SN 1에 대응하기 때문에 만약 새로운 형식의 SN로 전송된다면 수신기에서 HFN 값을 정확히 판단하기 어려울 수 있다. 뿐만 아니라 COUNT 8500034에 해당하는 패킷과 COUNT 8500066에 해당하는 패킷도 모두 PDCP SN 2에 대응하기 때문에 만약 새로운 형식의 SN로 전송된다면 수신기에서 HFN 값을 정확히 판단하기 어려울 수 있다. 이 때 특정 패킷들에 대해 임시 SN을 포함한 헤더를 사용하여 패킷을 전송할 수 있다. 이를 통해 HFN 값을 정확히 판단할 수 있다. 임시 SN의 값은 HFN 값을 정확히 판단할 수 있도록 충분히 큰 크기의 값으로 사용할 수 있다.
도 40의 실시예에서는 임시 SN의 크기를 22비트로 가정하였다. 따라서 도 40의 실시예에서 재설정 시점에 미수신된 패킷의 임시 SN은 111425, 111426, 111430, 111435, 111447, 111451, 111457, 111458, 111461, 111462, 111463 및 그 이상의 SN값으로 대응될 수 있다. 해당 임시 SN들에 대한 임시 HFN 값은 2가 될 수 있다. HFN과 SN 값과의 관계는 상기 수식 1-3 따른다
도 41은 PDCP SN의 길이가 바뀌는 패킷 형식 재설정 이후 미수신 패킷이 재전송되는 절차의 실시예를 나타낸다. 도 41에서는 재설정(Reconfiguration)으로 인해 PDCP SN의 크기가 7비트에서 5비트로 변경되는 것을 가정하고 이 때의 패킷 수신 상황은 도 40의 수신상황과 같다. 따라서 이 때 Status Report는 수신기에서 송신기로 전송될 수 있고 도 33의 실시예에 나타난 것과 같이 FMC와 비트맵(Bitmap)을 포함하거나 도 32의 실시예에 나타난 것과 같이 FMS와 비트맵을 포함할 수 있다. 도 41에서는 FMC와 비트맵을 포함하는 도 33의 상태보고(Status Report)로 전송되는 것을 가정하여 기술한다.
FMC는 미 수신한 패킷 중 COUNT 값이 가장 작은 패킷의 COUNT 값을 표시하게 되어 8500033이 표시된다. 만약 임시 SN 값이 FMS로 사용된다면 111425가 표시될 수도 있다. 그리고 이 패킷 이후의 패킷에 대해서는 비트맵으로 수신상태를 표시하게 된다. 도 41의 실시 예에서는 미수신이면 0, 수신이면 1로 표시하였다. 따라서 비트맵은 01110 11110 11111 11111 10111 01111 10011로 표시될 수 있다. 즉 COUNT 값이 8500034, 8500038, 8500043, 8500055, 8500059, 8500065, 8500066인 패킷들이 미수신임을 비트 0으로 명시하였고 PDCP COUNT가 8500068인 패킷까지 수신하였음을 나타낼 수 있다.
이것을 바탕으로 송신기는 미수신 패킷의 재전송을 수행하게 된다. 이 때 이들 패킷에 대해 도 35의 PDCP SN을 포함하는 PDU 형식 중 임시 PDCP SN을 포함하는 PDU 형식으로 패킷을 전송하게 된다. 이렇게 임시 PDCP SN가 표시된 패킷들은 HFN 비동기화(Desynchronization)가 생기지 않는다. 이후 PDCP COUNT 8500069 이상에 해당하는 패킷들은 새로운 SN 값인 5부터 사용하여 전송하게 된다.
도 41의 실시예에서는 상태 보고(Status Report) 메시지에 포함된 미수신 패킷까지(상기 실시예에서 COUNT 8500066)만 임시 PDCP SN 값을 사용하여 패킷을 전송하였지만 이 시점은 사전에 설정된 다른 시점으로 변동될 수 있다. 예를 들어, 상태 보고 메시지에서 표시된 수신된 것으로 표시된 패킷의 COUNT 값(상기 실시예에서 8500068)에서 일정한 값만큼 높은 PDCP COUNT를 가지는 패킷까지 임시 PDCP SN가 포함된 형식으로 전송할 수도 있다.
여기에서 일정한 값은 새로운 형식의 PDCP SN에 해당하는 PDCP 수신 Window 크기가 될 수도 있다. 수신 Window의 크기는 2( PDCP SN 크기- 1)로 사용될 수도 있는데 5비트 PDCP SN에 대한 수신 Window 크기는 2(5-1)=16이 될 수 있다. 이 때 임시 PDCP SN를 사용한 형식인지 새로운 PDCP SN을 사용한 형식인지는 도 35의 F필드로 구분할 수 있다.
도 42는 PDCP SN의 길이가 바뀌는 패킷 형식 재설정 이후 미수신 패킷이 재전송되는 절차의 실시 예를 나타낸다. 도 42에서는 재설정(Reconfiguration)으로 인해 PDCP SN의 크기가 7비트에서 5비트로 변경되는 것을 가정하고 이 때의 패킷 수신 상황은 도 40의 수신상황과 같다. 따라서, 이 때 Status Report는 수신기에서 송신기로 전송될 수 있고 도 33의 실시예에 나타난 것과 같이 FMC와 비트맵(Bitmap)을 포함하거나 도 32의 실시예에 나타난 것과 같이 FMS와 비트맵을 포함할 수 있다. 도 42에서는 FMC와 비트맵을 포함하는 도 33의 상태보고(Status Report)로 전송되는 것을 가정하여 기술한다.
FMC는 미 수신한 패킷 중 COUNT 값이 가장 작은 패킷의 COUNT 값을 표시하게 되어 8500033이 표시된다. 그리고 이 패킷 이후의 패킷에 대해서는 비트맵으로 수신상태를 표시하게 된다. 도 42의 실시 예에서는 미수신이면 0, 수신이면 1로 표시하였다. 따라서 비트맵은 01110 11110 11111 11111 10111 01111 10011로 표시될 수 있다. 즉 COUNT 값이 8500034, 8500038, 8500043, 8500055, 8500059, 8500065, 8500066인 패킷들이 미수신임을 비트 0으로 명시하였고 PDCP COUNT가 8500068인 패킷까지 수신하였음을 나타낼 수 있다.
이것을 바탕으로 송신기는 미수신 패킷의 재전송을 수행하게 된다. 이 때 이들 패킷에 대해 도 35의 PDCP SN을 포함하는 PDU 형식 중 새로운 PDCP SN을 포함하는 PDU 형식으로 패킷을 전송하게 된다. 도 42의 실시 예에서는 서로 다른 PDCP SN나 COUNT를 포함한 형식이 수신기에서 혼재하는 상황이 아니기 때문에 도 34-35의 F 필드는 사용하지 않을 수 있다. 도 42의 실시 예에서는 임시 PDCP SN이나 PDCP COUNT를 사용하지 않기 때문에 HFN 비동기화가 발생할 수도 있다. 하지만 이것은 도 43-44의 지연 전송 방식을 사용함으로써 해결할 수 있다.
도 43은 PDCP SN의 길이가 바뀌는 패킷 형식 재설정 이후 미수신 패킷이 재전송되는 절차의 실시예를 나타낸다. 도 43에서는 재설정(Reconfiguration)으로 인해 PDCP SN의 크기가 7비트에서 5비트로 변경되는 것을 가정하고 이 때의 패킷 수신 상황은 도 40의 수신상황과 같으며 재전송되는 패킷에 대한 기술은 도 41의 기술과 동일하다. 도 43의 실시예에서는 특정 PDCP SN을 갖는 패킷을 전송한 후, 같은 PDCP SN에 해당하는 패킷 중 HFN 값이 다른 패킷의 전송을 설정된 타이머 시간 이후에 하는 것을 특징으로 한다.
가령 도 43의 실시예에서는 PDCP SN 값을 1로 가지는 패킷 중 첫번째 패킷인 COUNT 8500033에 해당하는 패킷을 전송한 후 같은 PDCP SN을 가지는 COUNT 8500065에 해당하는 패킷을 설정된 타이머 시간 이후에 전송하는 것을 가정한다. 상기 타이머는 재설정 내지 설정 메시지에서 지시되거나 미리 설정된 값을 사용하도록 지시될 수 있다. 상기 타이머 값은 같은 PDCP SN을 가지는 서로 다른 패킷의 HFN 비동기가 발생하지 않도록 설정할 수 있고, 실시예에 따라 PDCP 재정렬 타이머(Reordering Timer) 길이로 설정될 수도 있다. 해당 타이머는 모든 PDCP 패킷에 대해 설정될 수 있으나 경우에 따라선 재설정 이후 전송되는 일부 패킷에 대해 설정될 수도 있다.
도 44는 PDCP SN의 길이가 바뀌는 패킷 형식 재설정 이후 미수신 패킷이 재전송되는 절차의 실시예를 나타낸다. 도 44에서는 재설정(Reconfiguration)으로 인해 PDCP SN의 크기가 7비트에서 5비트로 변경되는 것을 가정하고 이 때의 패킷 수신 상황은 도 40의 수신상황과 같으며 재전송되는 패킷에 대한 기술은 도 41의 기술과 동일하다. 도 44의 실시예에서는 송신기가 특정 PDCP SN을 갖는 패킷을 전송한 후, 이 패킷 이후 설정된 순서번호 간격 후에 해당하는 패킷 또는 이 패킷 이후 설정된 COUNT 간격 후에 해당하는 패킷의 전송을 설정된 타이머 시간 이후에 하는 것을 특징으로 한다.
가령 도 44의 실시예에서는 PDCP SN 값을 1로 가지는 패킷 중 첫 번째 패킷인 COUNT 8500033에 해당하는 패킷을 전송한 후 COUNT 값이 16보다 크거나 같은 COUNT 8500049(SN=17) 이후의 패킷에 대한 전송을 타이머 시간 이후에 수행하는 것을 가정한다. 상기 타이머는 재설정 내지 설정 메시지에서 지시되거나 미리 설정된 값을 사용하도록 지시될 수 있다. 상기 타이머 값은 같은 PDCP SN을 가지는 서로 다른 패킷의 HFN 비동기가 발생하지 않도록 설정할 수 있고, 실시 예에 따라 PDCP Reordering Timer 길이로 설정될 수도 있다. 또한 타이머로 전송을 지연시키는 패킷의 간격(예, 순서번호 간격 또는 COUNT 간격)은 사전에 설정된 값일 수 있다. 이러한 설정된 값은 PDCP 수신 Window가 될 수도 있다.
도 45는 패킷 형식의 재설정 이후에 COUNT를 변경하는 절차를 나타낸다. 도 16-44의 실시 예에서는 재설정 이후에도 COUNT 값이 유지될 수도 있으나, 실시 예에 따라 COUNT 값이 재설정되어 초기값부터 시작될 수도 있다. 도 45의 실시 예에서는 재설정 시점에 COUNT 5014, 5015, 5019, 5023, 5024 및 그 이후 값에 해당하는 패킷이 미수신 상태인 것을 가정한다.
이 때 수신기는 상태 보고(Status Report) 메시지에 FMC 또는 FMS 값과 이후 패킷의 수신여부에 대한 비트맵(Bitmap)을 전송할 수 있다. 이 때 상태 보고 메시지의 FMC 또는 FMS 값에 해당하는 패킷의 PDCP COUNT 값을 0으로 재설정할 수 있다. 도 45의 실시 예에서는 기존 COUNT 5014에 해당하는 패킷의 COUNT 값이 0으로 재설정되는 것을 가정한다. 상태보고 메시지의 비트맵에 따라 변경된 COUNT 0,1,5,9,10 및 그 이상의 COUNT 값에 해당하는 패킷이 미수신 상태인 것으로 재설정되어 재전송 절차를 수행할 수 있다.
도 46은 패킷 형식의 재설정 이후에 COUNT를 변경하는 절차를 나타낸다. 도 16-44의 실시 예에서는 재설정 이후에도 COUNT 값이 유지될 수도 있으나, 실시 예에 따라 COUNT 값이 재설정되어 초기값부터 시작될 수도 있다. 도 46의 실시 예에서는 재설정 시점에 COUNT 5014, 5015, 5019, 5023, 5024 및 그 이후 값에 해당하는 패킷이 미수신상태인 것을 가정한다.
이 때 수신기는 상태 보고(Status Report) 메시지에 FMC 또는 FMS 값을 전송할 수 있다. 부가적으로 이후 패킷의 수신여부에 대한 비트맵(Bitmap)을 전송할 수도 있다. 이 때 상태 보고 메시지의 FMC 또는 FMS 값에 해당하는 패킷의 PDCP COUNT 값을 0으로 재설정할 수 있다. 도 46의 실시 예에서는 기존 COUNT 5014에 해당하는 패킷의 COUNT 값이 0으로 재설정되는 것을 가정한다. 도 46의 실시 예에서는 상태보고 메시지의 비트맵과 관계 없이 재설정된 COUNT 값을 0으로 하는 패킷부터 이후의 패킷은 모두 미수신 상태인 것으로 재설정되어 재전송 절차를 수행할 수 있다.
도 47은 패킷 형식의 재설정 이후에 COUNT를 변경하는 절차를 나타낸다. 도 16-44의 실시 예에서는 재설정 이후에도 COUNT 값이 유지될 수도 있으나, 실시 예에 따라 COUNT 값이 재설정되어 초기값부터 시작될 수도 있다. 도 47의 실시 예에서는 재설정 시점에 COUNT 5014, 5015, 5019, 5023, 5024 및 그 이후 값에 해당하는 패킷이 미수신 상태인 것을 가정한다.
이 때 수신기는 상태 보고(Status Report) 메시지에 LMC(Last Missing COUNT) 값 또는 LMS(Last Missing SN) 값을 전송할 수 있다. 도 47의 실시예에서는 LMC값을 5023으로 설정하는 것으로 가정하였다. 여기서 LMC 값은 수신기가 수신한 것으로 판단하는 COUNT 값 없이 연속적으로 미수신 COUNT로 판단되는 가장 작은 COUNT 값을 나타낸다. 비슷하게 LMS 값은 수신기가 수신한 것으로 판단하는 SN 없이 연속적으로 미수신 SN로 판단되는 가장 작은 SN 값을 나타낸다. 부가적으로 이후 패킷의 수신 여부에 대한 비트맵(Bitmap)을 전송할 수도 있다.
이 때 상태 보고 메시지의 LMC 또는 LMS 값에 해당하는 패킷의 PDCP COUNT 값을 0으로 재설정할 수 있다. 도 47의 실시 예에서는 상태보고 메시지의 비트맵과 관계 없이 재설정된 COUNT 값을 0으로 하는 패킷부터 이후의 패킷은 모두 미수신 상태인 것으로 갱신되어 재전송 절차를 수행할 수 있다.
도 48은 상향링크 데이터에 대해 COUNT 재시작 및 헤더 형식이 바뀌는 절차를 나타낸다. 도 48의 실시예의 예전 형식은 상대적으로 길이가 긴 SN 크기가 포함되는 것이 될 수 있고 새로운 형식은 상대적으로 길이가 짧은 SN 크기가 포함되는 것일 수 있다. 또는 반대의 경우도 가능하다.
도 48의 실시예의 시작시점에는 단말(480)이 기지국(481)에게 예전 형식으로 패킷을 전송(1)한다. 이후 단말(480)은 기지국(481)으로부터 재설정(Reconfiguration) 메시지를 받고(2), 새로운 형식으로 전송해야 함을 인식한다. 이 때 수신기, 다시 말해서 기지국(481)이 수신한 패킷의 정보를 확인하기 위해서 수신기 상태 보고 메시지(Status report)를 송신기, 즉 단말(480)에게 보내게 된다(3). 이 때 기지국(481)과 단말(480)의 PDCP 장치(Entity)에서 이 역할을 담당할 수 있다.
이 상태 보고 메시지에는 어떤 패킷이 수신되었는지, 어떤 패킷이 수신되지 않거나 재전송이 필요한지 정보가 들어가 있다. 상태 보고 메시지는 처음 수신되지 않은 순서 번호 또는 COUNT 값과 이후 패킷의 수신상태를 나타내는 비트맵(Bitmap)을 포함할 수 있다. 자세한 상태 보고 메시지는 도 32-33에 나타난다.
단말(480)은 재설정 메시지를 받고 상태 보고 메시지를 수신한 후 COUNT를 재설정(4)한다. 이 때 상태 보고 메시지에 포함된 FMS, FMC, LMS, LMC 값 중 하나에 대응되는 패킷을 COUNT 0으로 재설정한다. COUNT를 0으로 재설정하는 방식은 도 45-47 중 하나의 절차를 따를 수 있다. 이후 단말(480)은 새로운 형식으로 상향링크 패킷을 기지국(481)에게 전송(5)할 수 있다. HFN 비동기를 방지하기 위해 단말은 도 43-44에 기술된 전송방법을 사용할 수도 있다. 이 때부터 기지국(481)은 새로운 형식으로 패킷을 수신(6)하게 된다.
도 49는 하향링크 데이터에 대해 COUNT 재시작 및 헤더 형식이 바뀌는 절차를 나타낸다. 도 49의 실시예의 예전 형식은 상대적으로 길이가 긴 SN 크기가 포함되는 것이 될 수 있고 새로운 형식은 상대적으로 길이가 짧은 SN 크기가 포함되는 것일 수 있다. 또는 반대의 경우도 가능하다.
도 49의 실시예의 시작시점에는 기지국(491)이 단말(490)에게 예전 형식으로 패킷을 전송(1)한다. 기지국이 재설정(Reconfiguration) 메시지를 보낸(2) 이후의 패킷은 새로운 형식으로 전송해야 함을 인식한다. 이 때 수신기, 다시 말해서 단말(490)이 수신한 패킷의 정보를 확인하기 위해서 수신기 상태 보고 메시지(Status report)를 송신기, 즉 기지국(491)에게 보내게 된다(3). 이 때 기지국과 단말의 PDCP 장치(Entity)에서 이 역할을 담당할 수 있다. 이 상태 보고 메시지에는 어떤 패킷이 수신되었는지, 어떤 패킷이 수신되지 않거나 재전송이 필요한지 정보가 들어가 있다. 상태 보고 메시지는 처음 수신되지 않은 패킷 순서 번호 또는 COUNT 값과 이후 패킷의 수신상태를 나타내는 비트맵(Bitmap)을 포함할 수 있다. 자세한 상태 보고 메시지는 도 32-33에 나타난다.
기지국(491)은 재설정 메시지를 전송하고 상태 보고 메시지를 수신한 후 COUNT를 재설정(4)한다. 이 때 상태 보고 메시지에 포함된 FMS, FMC, LMS, LMC 값 중 하나에 대응되는 패킷을 COUNT 0으로 재설정한다. COUNT를 0으로 재설정하는 방식은 도 45-47 중 하나의 절차를 따를 수 있다. 이후 기지국(491)은 새로운 형식으로 하향링크 패킷을 단말에게 전송(5)할 수 있다. HFN 비동기를 방지하기 위해 기지국은 도 43-44에 기술된 전송방법을 사용할 수도 있다. 이 때부터 단말(490)은 새로운 형식으로 패킷을 수신(6)하게 된다.
도 50은 상향링크 데이터에 대해 COUNT를 재시작하고 헤더 형식이 바뀌는 경우의 단말과 기지국 신호 흐름를 나타낸다. 도 50의 실시예의 예전 형식은 상대적으로 길이가 긴 SN 크기가 포함되는 것이 될 수 있고 새로운 형식은 상대적으로 길이가 짧은 SN 크기가 포함되는 것일 수 있다. 또는 반대의 경우도 가능하다.
도 50의 실시예의 시작시점에는 단말(500)이 제1 기지국(501)에게 예전 형식으로 패킷을 전송(1)한다. 이후 단말(500)은 기지국으로부터 재설정(Reconfiguration) 메시지를 받고(2), 새로운 형식으로 전송해야 함을 인식한다. 도 50의 실시 예에서는 제 1 기지국(501)으로부터 재설정 메시지를 받는 것으로 가정하였으나, 단말에게 재설정 메시지를 보낼 수 있는 기지국이라면 이 메시지를 보내는 것에 제한은 없다. 이 때 수신기, 다시 말해서 제 1 기지국(501)이 수신한 패킷의 정보를 확인하기 위해서 수신기 상태 보고 메시지(Status report)를 송신기, 즉 단말(500)에게 보내게 된다(3). 이 때 기지국과 단말의 PDCP 장치(Entity)에서 이 역할을 담당할 수 있다.
도 50의 실시 예에서는 제 1 기지국(501)이 단말(500)에게 상태보고 메시지를 보내는 것으로 가정하였으나, 제 1 기지국(501)이 제 2 기지국(502)에게 상태 보고 메시지를 전송(4)한 후 제 2 기지국(502)이 단말(501)에게 상태 보고 메시지를 보낼 수도 있다. 이 상태 보고 메시지에는 어떤 패킷이 수신되었는지, 어떤 패킷이 수신되지 않거나 재전송이 필요한지 정보가 들어가 있다. 상태 보고 메시지는 처음 수신되지 않은 순서 번호 또는 COUNT 값을 포함할 수 있다. 또한 상태 보고 메시지에는 패킷의 수신상태를 나타내는 비트맵(Bitmap)을 포함할 수도 있다. 자세한 상태 보고 메시지는 도 32-33에 나타난다.
단말(500)은 재설정 메시지를 받고 상태 보고 메시지를 수신한 후 COUNT를 재설정(5)한다. 이 때 상태 보고 메시지에 포함된 FMS, FMC, LMS, LMC 값 중 하나에 대응되는 패킷을 COUNT 0으로 재설정한다. COUNT를 0으로 재설정하는 방식은 도 45-47 중 하나의 절차를 따를 수 있다. 이후 단말(500)은 새로운 형식으로 상향링크 패킷을 제 2 기지국(502)에게 전송(6)할 수 있다. HFN 비동기를 방지하기 위해 기지국과 단말은 도 43-44에 기술된 전송방법을 사용할 수도 있다. 이 때부터 제 2 기지국(502)은 새로운 형식으로 패킷을 수신(7)하게 된다.
도 51은 하향링크 데이터에 대해 COUNT를 재시작하고 헤더 형식이 바뀌는 경우의 단말과 기지국 신호 흐름을 나타낸다. 도 51의 실시예의 예전 형식은 상대적으로 길이가 긴 SN 크기가 포함되는 것이 될 수 있고 새로운 형식은 상대적으로 길이가 짧은 SN 크기가 포함되는 것일 수 있다. 또는 반대의 경우도 가능하다.
도 51의 실시예의 시작시점에는 제1 기지국(511)이 단말(510)에게 예전 형식으로 패킷을 전송(1)한다. 이후 단말(510)은 기지국으로부터 재설정(Reconfiguration) 메시지를 받고 새로운 형식으로 수신해야 함을 인식한다. 도 51의 실시 예에서는 제 1 기지국(511)으로부터 재설정 메시지를 받는 것으로 가정하였으나, 단말(510)에게 재설정 메시지를 보낼 수 있는 기지국이라면 이 메시지를 보내는 것에 제한은 없다. 제1 기지국(511)은 제2 기지국(512)으로 데이터를 전달(3)한다.
이 때 수신기, 다시 말해서 단말(510)이 수신한 패킷의 정보를 확인하기 위해서 수신기 상태 보고 메시지(Status report)를 송신기, 즉 기지국에게 보내게 된다. 이 때 기지국과 단말의 PDCP 장치(Entity)에서 이 역할을 담당할 수 있다. 도 51의 실시예에서는 단말(510)이 제 2 기지국(512)에게 상태 보고 메시지를 보내는 것(4)으로 가정하였으나, 단말이 제 1 기지국(511)에게 전송한 후 제 1 기지국(511)이 제 2 기지국(512)에게 상태 보고 메시지를 보낼 수도 있다. 이 상태 보고 메시지에는 어떤 패킷이 수신되었는지, 어떤 패킷이 수신되지 않거나 재전송이 필요한지 정보가 들어가 있다. 상태 보고 메시지는 처음 수신되지 않은 순서 번호 또는 COUNT 값을 포함할 수 있다. 또한 상태 보고 메시지에는 패킷의 수신상태를 나타내는 비트맵(Bitmap)을 포함할 수도 있다. 자세한 상태 보고 메시지는 도 32-33에 나타난다.
제 2 기지국(512)은 상태 보고 메시지를 수신한 후 COUNT를 재설정(5)한다. 이 때 상태 보고 메시지에 포함된 FMS, FMC, LMS, LMC 값 중 하나에 대응되는 패킷을 COUNT 0으로 재설정한다. COUNT를 0으로 재설정하는 방식은 도 45-47 중 하나의 절차를 따를 수 있다. 이후 제 2 기지국(512)은 새로운 형식으로 하향링크 패킷을 단말에게 전송(6)할 수 있다. HFN 비동기를 방지하기 위해 기지국과 단말은 도 43-44에 기술된 전송방법을 사용할 수도 있다. 이 때부터 단말(510)은 새로운 형식으로 패킷을 수신(7)하게 된다.
도 52는 상향링크 데이터에 대해 COUNT 재시작 및 헤더 형식이 바뀌는 절차를 나타낸다. 도 52의 실시예의 예전 형식은 상대적으로 길이가 긴 SN 크기가 포함되는 것이 될 수 있고 새로운 형식은 상대적으로 길이가 짧은 SN 크기가 포함되는 것일 수 있다. 또는 반대의 경우도 가능하다.
도 52의 실시예의 시작시점에는 단말(520)이 기지국(521)에게 예전 형식으로 패킷을 전송(1)한다. 이후 단말(520)은 기지국(521)으로부터 재설정(Reconfiguration) 메시지를 받고(2), 새로운 형식으로 패킷을 전송해야 함을 인식한다. 이 때 수신기, 다시 말해서 기지국(521)이 수신한 패킷의 정보를 확인하기 위해서 수신기 상태 보고 메시지(Status report)를 송신기, 즉 단말(520)에게 보내게 된다(3). 이 때 기지국(521)과 단말(520)의 PDCP 장치(Entity)에서 이 역할을 담당할 수 있다. 이 상태 보고 메시지에는 어떤 패킷이 수신되었는지, 어떤 패킷이 수신되지 않거나 재전송이 필요한지 정보가 들어가 있다. 상태 보고 메시지는 처음 수신되지 않은 순서 번호 또는 COUNT 값과 이후 패킷의 수신상태를 나타내는 비트맵(Bitmap)을 포함할 수 있다. 자세한 상태 보고 메시지는 도 32-33에 나타난다.
단말(520)은 재설정 메시지를 받고 상태 보고 메시지를 수신한 후 COUNT를 재설정(4)한다. 이 때 상태 보고 메시지에 포함된 FMS, FMC, LMS, LMC 값 중 하나에 대응되는 패킷을 COUNT 0으로 재설정한다. COUNT를 0으로 재설정하는 방식은 도 45-47 중 하나의 절차를 따를 수 있다.
단말(520)은 COUNT를 0으로 재설정 한 이후부터는 임시 형식으로 패킷을 전송(5)하게 된다. 단말(520)은 사전에 설정된 만큼 임시 형식으로 패킷을 전송(6, 7)하고 이후부터 재설정 메시지에서 지시된 새로운 형식으로 패킷을 전송(8)할 수 있다. 이 때 상태 보고 메시지에 표시된 FMS(First Missing SN)이나 FMC(First Missing COUNT)보다 정해진 만큼 큰 SN 또는 COUNT 값을 가지는 패킷까지 임시 형식으로 보낼 수 있다. 이 정해진 만큼의 크기는 예전 형식에서 사용하는 PDCP Window 크기 또는 그의 정수배만큼 일 수 있다.
송신기, 즉 단말(520)은 임시 형식으로 전송한 후 새로운 형식으로 패킷을 전송(9)하게 되지만 무선 채널에서 재전송을 겪게 되기 때문에 기지국(521)은 임시 형식의 데이터와 새로운 형식의 데이터의 순서가 섞여서 수신할 수도 있다. 이런 경우 헤더 형식을 구분하기 위해 패킷이 임시 형식을 사용하는지 구분하는 지시자가 필요하다. 자세한 헤더 형식은 도 34-35에 나타난다.
도 53은 하향링크 데이터에 대해 COUNT를 재시작 및 헤더 형식이 바뀌는 절차를 나타낸다. 도 53의 실시예의 예전 형식은 상대적으로 길이가 긴 SN 크기가 포함되는 것이 될 수 있고 새로운 형식은 상대적으로 길이가 짧은 SN 크기가 포함되는 것일 수 있다. 또는 반대의 경우도 가능하다.
도 53의 실시예의 시작시점에는 기지국(531)이 단말(530)에게 예전 형식으로 패킷을 전송(1)한다. 기지국(531)이 재설정(Reconfiguration) 메시지를 보낸 이후(2), 패킷에 대해 새로운 형식으로 전송해야 함을 인식한다. 이 때 수신기, 다시 말해서 단말(530)이 수신한 패킷의 정보를 확인하기 위해서 수신기 상태 보고 메시지(Status report)를 송신기, 즉 기지국(531)에게 보내게 된다(3). 이 때 기지국(531)과 단말(530)의 PDCP 장치(Entity)에서 이 역할을 담당할 수 있다. 이 상태 보고 메시지에는 어떤 패킷이 수신되었는지, 어떤 패킷이 수신되지 않거나 재전송이 필요한지 정보가 들어가 있다. 상태 보고 메시지는 처음 수신되지 않은 순서 번호 또는 COUNT 값과 이후 패킷의 수신상태를 나타내는 비트맵(Bitmap)을 포함할 수 있다. 자세한 상태 보고 메시지는 도 32-33에 나타난다.
기지국(531)은 재설정 메시지를 송신하고 상태 보고 메시지를 수신한 후 COUNT를 재설정(4)한다. 이 때 상태 보고 메시지에 포함된 FMS, FMC, LMS, LMC 값 중 하나에 대응되는 패킷을 COUNT 0으로 재설정한다. COUNT를 0으로 재설정하는 방식은 도 45-47 중 하나의 절차를 따를 수 있다. 기지국(531)은 COUNT를 0으로 재설정 한 이후부터는 임시 형식으로 패킷을 전송(5)하게 된다. 기지국은 사전에 설정된 만큼 임시 형식으로 패킷을 전송(6, 7)하고 이후부터 재설정 메시지에서 지시된 새로운 형식으로 패킷을 전송(8)할 수 있다.
이 때 상태 보고 메시지에 표시된 FMS(First Missing SN)이나 FMC(First Missing COUNT)보다 정해진 만큼 큰 SN 또는 COUNT 값을 가지는 패킷까지 임시 형식으로 보낼 수 있다. 이 정해진 만큼의 크기는 예전 형식에서 사용하는 PDCP Window 크기 또는 그의 정수배만큼 일 수 있다. 송신기, 즉 기지국(531)은 임시 형식으로 전송한 후 새로운 형식으로 패킷을 전송(9)하게 되지만 무선 채널에서 재전송을 겪게 되기 때문에 단말(530)은 임시 형식의 데이터와 새로운 형식의 데이터의 순서가 섞여서 수신할 수도 있다. 이런 경우 헤더 형식을 구분하기 위해 패킷이 임시 형식을 사용하는지 구분하는 지시자가 필요하다. 자세한 헤더 형식은 도 34-35에 나타난다.
도 54는 상향링크 데이터에 대해 COUNT를 재시작하고 헤더 형식이 바뀌는 경우 단말과 기지국 간 변경 신호 흐름을 나타낸다. 도 54의 실시예의 예전 형식은 상대적으로 길이가 긴 SN 크기가 포함되는 것이 될 수 있고 새로운 형식은 상대적으로 길이가 짧은 SN 크기가 포함되는 것일 수 있다. 또는 반대의 경우도 가능하다.
도 54의 실시예의 시작시점에는 단말(540)이 제1 기지국(541)에게 예전 형식으로 패킷을 전송(1)한다. 이후 단말(540)은 기지국으로부터 재설정(Reconfiguration) 메시지를 받고 새로운 형식으로 전송해야 함을 인식한다. 도 54의 실시 예에서는 제 1 기지국(541)으로부터 재설정 메시지를 받는 것(2)으로 가정하였으나, 단말에게 재설정 메시지를 보낼 수 있는 기지국이라면 이 메시지를 보내는 것에 제한은 없다. 이 때 수신기, 다시 말해서 제 1 기지국(541)이 수신한 패킷의 정보를 확인하기 위해서 수신기 상태 보고 메시지(Status report)를 송신기, 즉 단말(540)에게 보내게 된다(3). 이 때 기지국과 단말의 PDCP 장치(Entity)에서 이 역할을 담당할 수 있다. 도 54의 실시예에서는 제 1 기지국(541)이 단말(540)에게 보내는 것으로 가정하였으나, 제 1 기지국(541)이 제 2 기지국(542)에게 상태 보고 메시지를 전송(4)한 후 제 2 기지국(542)이 단말(540)에게 상태 보고 메시지를 보낼 수도 있다.
이 상태 보고 메시지에는 어떤 패킷이 수신되었는지, 어떤 패킷이 수신되지 않거나 재전송이 필요한지 정보가 들어가 있다. 상태 보고 메시지는 처음 수신되지 않은 순서 번호 또는 COUNT 값을 포함할 수 있다. 또한 상태 보고 메시지에는 패킷의 수신상태를 나타내는 비트맵(Bitmap)을 포함할 수도 있다. 자세한 상태 보고 메시지는 도 32-33에 나타난다.
단말(540)은 재설정 메시지를 받고 상태 보고 메시지를 수신한 후 COUNT를 재설정(5)한다. 이 때 상태 보고 메시지에 포함된 FMS, FMC, LMS, LMC 값 중 하나에 대응되는 패킷을 COUNT 0으로 재설정한다. COUNT를 0으로 재설정하는 방식은 도 45-47 중 하나의 절차를 따를 수 있다.
단말(540)은 COUNT를 0으로 재설정 한 이후부터는 임시 형식으로 패킷을 전송(6)하게 된다. 단말(540)은 사전에 설정된 만큼 임시 형식으로 패킷을 전송(7, 8)하고 이후부터 재설정 메시지에서 지시된 새로운 형식으로 패킷을 전송(9)할 수 있다. 이 때 상태 보고 메시지에 표시된 FMS(First Missing SN)이나 FMC(First Missing COUNT)보다 정해진 만큼 큰 SN 또는 COUNT 값을 가지는 패킷까지 임시 형식으로 보낼 수 있다. 이 정해진 만큼의 크기는 예전 형식에서 사용하는 PDCP Window 크기 또는 그의 정수배만큼 일 수 있다.
송신기, 즉 단말(540)은 임시 형식으로 전송한 후 새로운 형식으로 패킷을 전송(10)하게 되지만 무선 채널에서 재전송을 겪게 되기 때문에 제 2 기지국(542)은 임시 형식의 데이터와 새로운 형식의 데이터의 순서가 섞여서 수신할 수도 있다. 이런 경우 헤더 형식을 구분하기 위해 패킷이 임시 형식을 사용하는지 구분하는 지시자가 필요하다. 자세한 헤더 형식은 도 34-35에 나타난다.
도 55는 하향링크 데이터에 대해 COUNT를 재시작하고 헤더 형식이 바뀌는 경우 단말과 기지국 간 변경 신호흐름을 나타낸다. 도 55의 실시예의 예전 형식은 상대적으로 길이가 긴 SN 크기가 포함되는 것이 될 수 있고 새로운 형식은 상대적으로 길이가 짧은 SN 크기가 포함되는 것일 수 있다. 또는 반대의 경우도 가능하다.
도 55의 실시예의 시작시점에는 제1 기지국(551)이 단말(550)에게 예전 형식으로 패킷을 전송(1)한다. 이후 단말(550)은 기지국으로부터 재설정(Reconfiguration) 메시지를 받고 새로운 형식으로 수신해야 함을 인식한다. 기지국은 재설정(Reconfiguration) 메시지를 송신하고 새로운 형식으로 전송해야 함을 인식한다. 도 55의 실시 예에서는 제 1 기지국(551)으로부터 재설정 메시지를 받는 것(2)으로 가정하였으나, 단말에게 재설정 메시지를 보낼 수 있는 기지국이라면 이 메시지를 보내는 것에 제한은 없다. 제1 기지국(551)은 제2 기지국(552)으로 데이터를 전달한다(3).
이 때 수신기, 다시 말해서 단말(550)이 수신한 패킷의 정보를 확인하기 위해서 수신기 상태 보고 메시지(Status report)를 송신기, 즉 기지국에게 보내게 된다. 이 때 기지국과 단말의 PDCP 장치(Entity)에서 이 역할을 담당할 수 있다. 도 55의 실시 예에서는 단말(550)이 제 2 기지국(552)에게 상태 보고 메시지를 보내는 것(4)으로 가정하였으나, 단말(550)이 제 1 기지국(551)에게 전송한 후 제 1 기지국(551)이 제 2 기지국(552)에게 상태 보고 메시지를 보낼 수도 있다. 이 상태 보고 메시지에는 어떤 패킷이 수신되었는지, 어떤 패킷이 수신되지 않거나 재전송이 필요한지 정보가 들어가 있다. 상태 보고 메시지는 처음 수신되지 않은 순서 번호 또는 COUNT 값을 포함할 수 있다. 또한 상태 보고 메시지에는 이후 패킷의 수신상태를 나타내는 비트맵(Bitmap)을 포함할 수도 있다. 자세한 상태 보고 메시지는 도 32-33에 나타난다.
제 2 기지국(552)은 상태 보고 메시지를 수신한 후 COUNT를 재설정(5)한다. 이 때 상태 보고 메시지에 포함된 FMS, FMC, LMS, LMC 값 중 하나에 대응되는 패킷을 COUNT 0으로 재설정한다. COUNT를 0으로 재설정하는 방식은 도 45-47 중 하나의 절차를 따를 수 있다. 제 2 기지국(552)은 COUNT를 0으로 재설정 한 이후부터는 임시 형식으로 패킷을 전송(6)하게 된다. 제 2 기지국(552)은 사전에 설정된 만큼 임시 형식으로 패킷을 전송(7, 8)하고 이후부터 재설정 메시지에서 지시된 새로운 형식으로 패킷을 전송(9)할 수 있다.
이 때 상태 보고 메시지에 표시된 FMS(First Missing SN)이나 FMC(First Missing COUNT)보다 정해진 만큼 큰 SN 또는 COUNT 값을 가지는 패킷까지 임시 형식으로 보낼 수 있다. 이 정해진 만큼의 크기는 예전 형식에서 사용하는 PDCP Window 크기 또는 그의 정수배만큼 일 수 있다. 송신기, 즉 제 2 기지국(552)은 임시 형식으로 전송한 후 새로운 형식으로 패킷을 전송(10)하게 되지만 무선 채널에서 재전송을 겪게 되기 때문에 단말(550)은 임시 형식의 데이터와 새로운 형식의 데이터의 순서가 섞여서 수신할 수도 있다. 이런 경우 헤더 형식을 구분하기 위해 패킷이 임시 형식을 사용하는지 구분하는 지시자가 필요하다. 자세한 헤더 형식은 도 34-35에 나타난다.
도 56은 PDCP SN의 길이가 바뀌는 패킷 형식 재설정 이후 미수신 패킷이 재전송되는 절차의 실시예를 나타낸다. 도 56에서는 재설정(Reconfiguration)으로 인해 PDCP SN의 크기가 7비트에서 5비트로 변경되는 것을 가정하고 이 때의 패킷 수신 상황은 도 40의 수신상황과 같다. 따라서 이 때 Status Report는 수신기에서 송신기로 전송될 수 있고 도 33의 실시예에 나타난 것과 같이 FMC와 비트맵(Bitmap)을 포함하거나 도 32의 실시예에 나타난 것과 같이 FMS와 비트맵을 포함할 수 있다. 도 56에서는 FMC와 비트맵을 포함하는 도 33의 상태보고(Status Report)로 전송되는 것을 가정하여 기술한다.
FMC는 미 수신한 패킷 중 COUNT 값이 가장 작은 패킷의 COUNT 값을 표시하게 되어 8500033이 표시된다. 그리고 이 패킷 이후의 패킷에 대해서는 비트맵으로 수신상태를 표시하게 된다. 도 56의 실시예에서는 미수신이면 0, 수신이면 1로 표시하였다. 따라서 비트맵은 01110 11110 11111 11111 10111 01111 10011로 표시될 수 있다. 즉 COUNT 값이 8500034, 8500038, 8500043, 8500055, 8500059, 8500065, 8500066인 패킷들의 미수신임을 비트 0으로 명시하였고 PDCP COUNT가 8500068인 패킷까지 수신하였음을 나타낼 수 있다.
이것을 바탕으로 송신기는 미수신 패킷의 재전송을 수행하게 된다. 이 때 이들 패킷에 대해 도 35의 PDCP SN을 포함하는 PDU 형식 중 새로운 PDCP SN을 포함하는 PDU 형식으로 패킷을 전송하게 된다. 도 56의 실시 예에서는 서로 다른 PDCP SN나 COUNT를 포함한 형식이 수신기에서 혼재하는 상황이 아니기 때문에 도 34-35의 F 필드는 사용하지 않을 수 있다.
이 때 패킷(PDCP SDU 또는 PDCP PDU)들은 RLC 계층의 RLC 헤더를 추가로 부착하여 전송될 수 있다. RLC 헤더는 RLC 순서번호(RLC SN)를 포함할 수 있다. 도 56의 실시예는 재설정 이후 또는 상태 보고 메시지 이후 수신하는 패킷에 대하여 일정 수의 패킷 만큼은 RLC 계층에서 재정렬(Reordering)을 수행하는 것을 특징으로 가진다. 무선 채널 변화 등 여러가지 원인으로 인해서 송신기에서 전송한 패킷들이 수신기에 도착하는 순서는 달라질 수 있다.
가령 RLC 순서번호 3, 4에 해당하는 (PDCP 순서번호 11,23에 해당하는) 패킷들은 RLC 순서번호 3에 해당하는 패킷이 먼저 전송되고, RLC 순서번호 4에 해당하는 패킷이 나중에 전송될 수 있다. 하지만 수신기에는 RLC 순서번호 4에 해당하는 패킷이 먼저 도착하고, RLC 순서번호 3에 해당하는 패킷이 나중에 도착할 수 있다. 이 때 이러한 순서가 바뀌는 현상으로 HFN 비동기화가 발생할 수도 있다.
도 56의 실시예에서는 RLC 순서번호 0부터 RLC 순서번호 11까지 12개의 패킷에 대해서는 수신기의 RLC 계층에서 재정렬을 수행한 후 순서대로 수신기의 PDCP 계층으로 보내고 그 이후 패킷에 대해서는 재정렬을 수행하지 않고 수신기의 RLC 계층에서 패킷을 수신하는 즉시 PDCP 계층으로 보낼 수 있다. 이 때 몇 개의 패킷만큼 재정렬을 수행할지는 기지국이 단말에게 설정해 줄 수 있다.
도 57은 PDCP SN의 길이가 바뀌는 패킷 형식 재설정 이후 미수신 패킷이 재전송되는 절차의 실시예를 나타낸다. 도 57에서는 재설정(Reconfiguration)으로 인해 PDCP SN의 크기가 7비트에서 5비트로 변경되는 것을 가정하고 이 때의 패킷 수신 상황은 도 40의 수신상황과 같다. 따라서 이 때 Status Report는 수신기에서 송신기로 전송될 수 있고 도 33의 실시예에 나타난 것과 같이 FMC와 비트맵(Bitmap)을 포함하거나 도 32의 실시예에 나타난 것과 같이 FMS와 비트맵을 포함할 수 있다. 도 57에서는 FMC와 비트맵을 포함하는 도 33의 상태보고(Status Report)로 전송되는 것을 가정하여 기술한다.
FMC는 미 수신한 패킷 중 COUNT 값이 가장 작은 패킷의 COUNT 값을 표시하게 되어 8500033이 표시된다. 그리고 이 패킷 이후의 패킷에 대해서는 비트맵으로 수신상태를 표시하게 된다. 도 57의 실시예에서는 미수신이면 0, 수신이면 1로 표시하였다. 따라서 비트맵은 01110 11110 11111 11111 10111 01111 10011로 표시될 수 있다. 즉 COUNT 값이 8500034, 8500038, 8500043, 8500055, 8500059, 8500065, 8500066인 패킷들의 미수신임을 비트 0으로 명시하였고 PDCP COUNT가 8500068인 패킷까지 수신하였음을 나타낼 수 있다.
이것을 바탕으로 송신기는 미수신 패킷의 재전송을 수행하게 된다. 이 때 이들 패킷에 대해 도 35의 PDCP SN을 포함하는 PDU 형식 중 새로운 PDCP SN을 포함하는 PDU 형식으로 패킷을 전송하게 된다. 도 57의 실시예에서는 서로 다른 PDCP SN나 COUNT를 포함한 형식이 수신기에서 혼재하는 상황이 아니기 때문에 도 34-35의 F 필드는 사용하지 않을 수 있다.
이 때 패킷(PDCP SDU 또는 PDCP PDU)들은 RLC 계층의 RLC 헤더를 추가로 부착하여 전송될 수 있다. RLC 헤더는 RLC 순서번호(RLC SN)를 포함할 수 있다. 도 57의 실시예는 재설정 이후 또는 상태 보고 메시지 이후 수신하는 패킷에 대하여 일정 시간 동안 RLC 계층에서 재정렬(Reordering)을 수행하는 것을 특징으로 가진다.
무선 채널 변화 등 여러가지 원인으로 인해서 송신기에서 전송한 패킷들이 수신기에 도착하는 순서는 달라질 수 있다. 가령 RLC 순서번호 3, 4에 해당하는 (PDCP 순서번호 11,23에 해당하는) 패킷들은 RLC 순서번호 3에 해당하는 패킷이 먼저 전송되고, RLC 순서번호 4에 해당하는 패킷이 나중에 전송될 수 있다. 하지만 수신기에는 RLC 순서번호 4에 해당하는 패킷이 먼저 도착하고, RLC 순서번호 3에 해당하는 패킷이 나중에 도착할 수 있다. 이 때 이러한 순서가 바뀌는 현상으로 HFN 비동기화가 발생할 수도 있다.
도 57의 실시예에서는 재설정 시간 이후 타이머를 동작 시켜서 타이머가 만료되기 전까지는 재정렬을 수행한 후 순서대로 수신기의 PDCP 계층으로 보내고 그 이후 패킷에 대해서는 재정렬을 수행하지 않고 수신기의 RLC 계층에서 패킷을 수신하는 즉시 PDCP 계층으로 보낼 수 있다. 이 때 RLC 소계층에서 얼마만큼의 시간 동안 재정렬을 수행할지(타이머 시간)는 기지국이 단말에게 설정해 줄 수 있다.
한편, 본 명세서와 도면에 개시된 본 발명의 실시 예들은 본 발명의 기술 내용을 쉽게 설명하고 본 발명의 이해를 돕기 위해 특정 예를 제시한 것일 뿐이며, 본 발명의 범위를 한정하고자 하는 것은 아니다. 즉 본 발명의 기술적 사상에 바탕을 둔 다른 변형 예들이 실시 가능하다는 것은 본 발명의 속하는 기술 분야에서 통상의 지식을 가진 자에게 자명한 것이다. 또한 상기 각각의 실시 예는 필요에 따라 서로 조합되어 운용할 수 있다. 예컨대, 본 발명의 실시예 1와 실시예 2의 일부분들이 서로 조합되어 기지국과 단말이 운용될 수 있다. 또한 상기 실시 예들은 LTE/LTE-A 시스템을 기준으로 제시되었지만, 5G, NR 시스템 등 다른 시스템에도 상기 실시예의 기술적 사상에 바탕을 둔 다른 변형 예들이 실시 가능할 것이다.

Claims (15)

  1. 무선 통신 시스템에서 송신기의 방법에 있어서,
    PDCP(Packet Data Convergence Protocol) 패킷에 대한 타이머를 구동하는 단계;
    상기 타이머가 만료되면, 상기 PDCP 패킷을 폐기하는 단계; 및
    상기 폐기된 PDCP 패킷의 정보를 포함하는 보고를, 수신기로 전송하는 단계를 포함하는 것을 특징으로 하는 송신기의 방법.
  2. 제1항에 있어서,
    상기 수신기로부터, 상기 보고에 관한 설정 정보를 수신하는 단계; 및
    상기 설정 정보에 기반하여, 상기 보고를 전송하는 단계를 더 포함하는 것을 특징으로 하는 송신기의 방법.
  3. 제1항에 있어서,
    상기 수신기로부터, 상기 보고에 관한 설정 정보를 수신하는 단계; 및
    상기 설정 정보에 기반하여, 상기 보고를 전송하는 단계를 더 포함하는 것을 특징으로 하는 송신기의 방법.
  4. 제3항에 있어서,
    상기 수신기로부터, 대기(waiting) 타이머의 임계값 정보 및 상기 폐기된 PDCP 패킷의 시퀀스 번호에 관한 포맷 정보를 포함하는 설정 정보를 수신하는 단계;
    제1 PDCP 패킷의 폐기가 확인되면, 상기 대기 타이머를 구동하는 단계;
    상기 대기 타이머가 상기 임계값 정보에 기반한 시간에 따라 만료되는지 여부를 확인하는 단계; 및
    상기 대기 타이머가 만료되면, 상기 제1 PDCP 패킷의 시퀀스 번호 및 상기 임계값 정보에 따른 시간 동안 폐기된 제2 PDCP 패킷의 시퀀스 번호를 포함하는 보고를 상기 수신기로 전송하는 단계를 포함하는 것을 특징으로 하는 송신기 방법.
  5. 무선 통신 시스템에서 수신기의 방법에 있어서,
    송신기로부터 폐기된 PDCP(Packet Data Convergence Protocol) 패킷의 정보를 포함하는 보고를 수신하는 단계를 포함하고,
    PDCP 패킷은, 상기 PDCP 패킷에 대한 타이머가 구동되고, 상기 타이머가 만료되는 것에 의하여 상기 송신기에서 폐기되는 것을 특징으로 하는 수신기의 방법.
  6. 제5항에 있어서,
    상기 송신기로, 상기 보고에 관한 설정 정보를 전송하는 단계; 및
    상기 설정 정보에 기반하여 생성된 상기 보고를 수신하는 단계를 더 포함하는 것을 특징으로 하는 수신기의 방법.
  7. 제6항에 있어서,
    상기 설정 정보는, 상기 보고의 전송 주기에 관한 정보, 상기 보고의 전송 이벤트에 관한 정보, 상기 전송 이벤트의 발생 조건에 관한 정보 및 상기 폐기된 PDCP 패킷 정보의 전송 포맷에 관한 정보 중 적어도 하나를 포함하는 것을 특징으로 하는 수신기의 방법.
  8. 제7항에 있어서,
    상기 송신기로, 대기(waiting) 타이머의 임계값 정보 및 상기 폐기된 PDCP 패킷의 시퀀스 번호에 관한 포맷 정보를 포함하는 설정 정보를 전송하는 단계; 및
    상기 송신기로부터, 제1 PDCP 패킷의 시퀀스 번호 및 상기 제1 PDCP 패킷이 폐기되는 것에 기반하여 상기 대기 타이머가 구동된 이후 상기 대기 타이머가 만료될 때까지의 시간 동안 폐기된 제2 PDCP 패킷의 시퀀스 번호를 포함하는 보고를 수신하는 단계를 포함하고,
    상기 대기 타이머는, 상기 송신기에서 구동된 이후 상기 임계값 정보에 따른 시간이 초과하면 만료되는 것을 특징으로 하는 수신기의 방법.
  9. 무선 통신 시스템에서 송신기에 있어서,
    송수신부; 및
    PDCP(Packet Data Convergence Protocol) 패킷에 대한 타이머를 구동하고, 상기 타이머가 만료되면, 상기 PDCP 패킷을 폐기하며, 상기 폐기된 PDCP 패킷의 정보를 포함하는 보고를, 수신기로 전송하도록 상기 송수신부를 제어하는 제어부를 포함하는 것을 특징으로 하는 송신기.
  10. 제9항에 있어서,
    상기 제어부는,
    상기 수신기로부터, 상기 보고에 관한 설정 정보를 수신하고, 상기 설정 정보에 기반하여, 상기 보고를 전송하도록 상기 송수신부를 제어하는 것을 특징으로 하는 송신기.
  11. 제10항에 있어서,
    상기 설정 정보는, 상기 보고의 전송 주기에 관한 정보, 상기 보고의 전송 이벤트에 관한 정보, 상기 전송 이벤트의 발생 조건에 관한 정보 및 상기 폐기된 PDCP 패킷 정보의 전송 포맷에 관한 정보 중 적어도 하나를 포함하는 것을 특징으로 하는 송신기.
  12. 제11항에 있어서,
    상기 제어부는,
    상기 수신기로부터, 대기(waiting) 타이머의 임계값 정보 및 상기 폐기된 PDCP 패킷의 시퀀스 번호에 관한 포맷 정보를 포함하는 설정 정보를 수신하고,
    제1 PDCP 패킷의 폐기가 확인되면, 상기 대기 타이머를 구동하며,
    상기 대기 타이머가 상기 임계값 정보에 기반한 시간에 따라 만료되면, 상기 제1 PDCP 패킷의 시퀀스 번호 및 상기 임계값 정보에 따른 시간 동안 폐기된 제2 PDCP 패킷의 시퀀스 번호를 포함하는 보고를 상기 수신기로 전송하도록 상기 송수신부를 제어하는 것을 특징으로 하는 송신기.
  13. 무선 통신 시스템에서 수신기에 있어서,
    송신기로, PDCP(Packet Data Convergence Protocol) 패킷의 정보를 포함하는 보고에 관한 설정 정보를 전송하는 송수신부; 및
    상기 송신기로부터, 상기 설정 정보에 기반하여 생성된, 폐기된 PDCP 패킷의 정보를 포함하는 보고를 수신하도록 상기 송수신부를 제어하는 제어부를 포함하고,
    PDCP 패킷은, 상기 PDCP 패킷에 대한 타이머가 구동되고, 상기 타이머가 만료되는 것에 의하여 상기 송신기에서 폐기되는 것을 특징으로 하는 수신기.
  14. 제13항에 있어서,
    상기 설정 정보는, 상기 보고의 전송 주기에 관한 정보, 상기 보고의 전송 이벤트에 관한 정보, 상기 전송 이벤트의 발생 조건에 관한 정보 및 상기 폐기된 PDCP 패킷 정보의 전송 포맷에 관한 정보 중 적어도 하나를 포함하는 것을 특징으로 하는 수신기.
  15. 제14항에 있어서,
    상기 제어부는,
    상기 송신기로, 대기(waiting) 타이머의 임계값 정보 및 상기 폐기된 PDCP 패킷의 시퀀스 번호에 관한 포맷 정보를 포함하는 설정 정보를 전송하고,
    상기 송신기로부터, 제1 PDCP 패킷의 시퀀스 번호 및 상기 제1 PDCP 패킷이 폐기되는 것에 기반하여 상기 대기 타이머가 구동된 이후 상기 대기 타이머가 만료될 때까지의 시간 동안 폐기된 제2 PDCP 패킷의 시퀀스 번호를 포함하는 보고를 수신하도록 상기 송수신부를 제어하며,
    상기 대기 타이머는, 상기 송신기에서 구동된 이후 상기 임계값 정보에 따른 시간이 초과하면 만료되는 것을 특징으로 하는 수신기.
PCT/KR2018/001457 2017-02-02 2018-02-02 통신시스템에서의 데이터 처리 방법 WO2018143728A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/481,032 US11122463B2 (en) 2017-02-02 2018-02-02 Method for processing data in communication system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2017-0015192 2017-02-02
KR1020170015192A KR102721539B1 (ko) 2017-02-02 통신시스템에서의 데이터 처리 방법

Publications (1)

Publication Number Publication Date
WO2018143728A1 true WO2018143728A1 (ko) 2018-08-09

Family

ID=63039912

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2018/001457 WO2018143728A1 (ko) 2017-02-02 2018-02-02 통신시스템에서의 데이터 처리 방법

Country Status (2)

Country Link
US (1) US11122463B2 (ko)
WO (1) WO2018143728A1 (ko)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3811542A2 (en) * 2018-06-21 2021-04-28 Telefonaktiebolaget Lm Ericsson (Publ) Preventing/mitigating packet loss in iab systems
WO2020139509A1 (en) * 2018-12-27 2020-07-02 Apple Inc. Integrity protection for frequent small data transmission
KR20210132864A (ko) * 2020-04-28 2021-11-05 삼성전자주식회사 패킷을 송수신하는 전자 장치 및 그 동작 방법
WO2022021301A1 (en) * 2020-07-31 2022-02-03 Qualcomm Incorporated Techniques for avoiding long transmission delays introduction
CA3241934A1 (en) * 2022-01-21 2023-07-27 Sungduck Chun Data unit processing
WO2023212425A2 (en) * 2022-08-09 2023-11-02 Futurewei Technologies, Inc. Methods and apparatus for differential quality of service (qos) handling of packets within a same service stream
US20240314632A1 (en) * 2023-03-14 2024-09-19 Dell Products, L.P. Dynamic packet re-ordering, discarding, and flow switching

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150023370A1 (en) * 2007-10-01 2015-01-22 Interdigital Patent Holdings, Inc. Method and apparatus for pcdp discard
US20150043435A1 (en) * 2013-08-09 2015-02-12 Blackberry Limited Method and system for protocol layer enhancements in data offload over small cells
US20150085667A1 (en) * 2013-09-26 2015-03-26 Kathiravetpillai Sivanesan Mitigation of traffic congestion in dual connectivity systems
US20150223093A1 (en) * 2012-08-17 2015-08-06 China Academy Of Telecommunications Technology Layer 2 measurement and result processing method and device under heterogeneous network
US20160278138A1 (en) * 2015-03-19 2016-09-22 Acer Incorporated Method of Radio Bearer Transmission in Dual Connectivity

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009009532A2 (en) * 2007-07-11 2009-01-15 Interdigital Technology Corporation Packet data convergence protocol operations
WO2013066258A2 (en) * 2011-11-04 2013-05-10 Telefonaktiebolaget L M Ericsson (Publ) Handling redundant data in a communication system
EP2830352A1 (en) * 2013-07-24 2015-01-28 Panasonic Intellectual Property Corporation of America Efficient discard mechanism in small cell deployment
JP6231837B2 (ja) * 2013-09-24 2017-11-15 株式会社Ｎｔｔドコモ 移動通信方法及び無線基地局
EP3298820B1 (en) * 2015-05-21 2019-11-13 Intel IP Corporation Pdcp status reporting for multi-rat offloading
US10602400B2 (en) * 2015-09-25 2020-03-24 Nokia Solutions And Networks Oy Enhancement of PDCP status report
US10396942B2 (en) 2016-03-29 2019-08-27 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving data in a communication system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150023370A1 (en) * 2007-10-01 2015-01-22 Interdigital Patent Holdings, Inc. Method and apparatus for pcdp discard
US20150223093A1 (en) * 2012-08-17 2015-08-06 China Academy Of Telecommunications Technology Layer 2 measurement and result processing method and device under heterogeneous network
US20150043435A1 (en) * 2013-08-09 2015-02-12 Blackberry Limited Method and system for protocol layer enhancements in data offload over small cells
US20150085667A1 (en) * 2013-09-26 2015-03-26 Kathiravetpillai Sivanesan Mitigation of traffic congestion in dual connectivity systems
US20160278138A1 (en) * 2015-03-19 2016-09-22 Acer Incorporated Method of Radio Bearer Transmission in Dual Connectivity

Also Published As

Publication number Publication date
US20190394675A1 (en) 2019-12-26
US11122463B2 (en) 2021-09-14
KR20180090148A (ko) 2018-08-10

Similar Documents

Publication Publication Date Title
WO2018143728A1 (ko) 통신시스템에서의 데이터 처리 방법
WO2021066466A1 (en) Method and apparatus for performing handover in wireless communication system
WO2018131987A1 (en) Method and apparatus for processing data in a wireless communication system
WO2020060352A1 (en) Methods and apparatuses for transmitting and receiving data in wireless communication system
WO2018231022A1 (en) Method for supporting multiple scheduling requests in next-generation mobile communication system
WO2020222527A1 (en) Method and apparatus for performing handover procedure in wireless communication system
WO2020045948A1 (en) Method and apparatus for performing dual connectivity in heterogeneous network
WO2018030798A1 (en) Method and apparatus for managing user plane operation in wireless communication system
WO2020197361A1 (en) Method and apparatus for handover without interruption of transmission and reception of data in next-generation mobile communication system
WO2018182388A1 (en) Apparatus and buffer control method thereof in wireless communication system
WO2020067816A1 (ko) Nr v2x 시스템을 위한 harq 동작을 수행하는 방법 및 장치
WO2015115854A1 (en) Method and apparatus for transmitting and receiving data using a plurality of carriers in mobile communication system
WO2018182366A1 (ko) Tcp/ip를 고려한 데이터 처리 방법
WO2019031883A1 (ko) 무선 통신 시스템에서 pdcp 재수립 방법 및 장치
WO2020027508A1 (en) Wireless node communication method and apparatus in wireless communication system
EP3251452A1 (en) Uplink control information transmitting method and apparatus
WO2020122509A1 (ko) 무선 통신 시스템에서 조건부 핸드오버의 실패 타이머 운용방법
WO2020209541A1 (ko) 무선 통신 시스템에서 단말 능력 보고 방법 및 장치
WO2020022849A1 (en) Method and apparatus for wireless communication of wireless node in wireless communication system
WO2020060207A1 (ko) 무선 통신 시스템에서 데이터를 송수신하는 방법 및 장치
EP3100376A1 (en) Method and apparatus for transmitting and receiving data using a plurality of carriers in mobile communication system
WO2018230964A1 (ko) 차세대 이동 통신 시스템에서 네트워크 요청 기반 버퍼 상태 보고를 처리하는 방법 및 장치
WO2022025528A1 (ko) 차세대 이동 통신 시스템에서 무결성 보호 또는 검증 절차로 인한 단말 프로세싱 부하를 줄이는 방법 및 장치
WO2020166906A1 (en) Methods and apparatuses for transmitting and receiving data in wireless communication system
WO2020060245A1 (en) Method and apparatus for identifying security key in next generation mobile communication system

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

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

Country of ref document: EP

Kind code of ref document: A1