KR20190017311A - Method and apparatus for retransmitting and recoverying of packet - Google Patents

Abstract

The present disclosure relates to a communication technique for fusing a 5G communication system with an IoT technology to support a higher data transmission rate than that of a 4G system, and a system thereof. The present disclosure can be applied to an intelligent service (for example, smart home, smart building, smart city, smart car or connected car, healthcare, digital education, retail business, security- and safety-related services, etc.) based on a 5G communication system and an IoT-related technology. The present invention relates to a method and an apparatus for retransmitting and recovering of a data packet. A control signal processing method in a wireless communication system comprises the following steps: receiving a first control signal transmitted from a base station; processing the received first control signal; and transmitting a second control signal generated based on the process to the base station.

Description

[0001] METHOD AND APPARATUS FOR RETRANSMITTING AND RECOVERYING OF PACKET [0002]

The present disclosure relates to a transmission method of a wireless communication system.

Efforts are underway to develop an improved 5G or pre-5G communication system to meet the growing demand for wireless data traffic after commercialization of the 4G communication system. For this reason, a 5G communication system or a pre-5G communication system is referred to as a 4G network (Beyond 4G Network) communication system or a post-LTE system (Post LTE) system.

To achieve a high data rate, 5G communication systems are being considered for implementation in very high frequency (mmWave) bands (e.g., 60 gigahertz (60GHz) bands). In order to mitigate the path loss of the radio wave in the very high frequency band and to increase the propagation distance of the radio wave, in the 5G communication system, beamforming, massive MIMO, full-dimension MIMO (FD-MIMO ), Array antennas, analog beam-forming, and large scale antenna technologies are being discussed.

In order to improve the network of the system, the 5G communication system has developed an advanced small cell, an advanced small cell, a cloud radio access network (cloud RAN), an ultra-dense network, (D2D), a wireless backhaul, a moving network, cooperative communication, Coordinated Multi-Points (CoMP), and interference cancellation Have been developed.

In addition, in the 5G system, the Advanced Coding Modulation (ACM) scheme, Hybrid FSK and QAM Modulation (FQAM) and Sliding Window Superposition Coding (SWSC), the advanced connection technology, Filter Bank Multi Carrier (FBMC) (non-orthogonal multiple access), and SCMA (sparse code multiple access).

On the other hand, the Internet is evolving into an Internet of Things (IoT) network in which information is exchanged between distributed components such as objects in a human-centered connection network where humans generate and consume information. IoE (Internet of Everything) technology, which combines IoT technology with big data processing technology through connection with cloud servers, is also emerging. In order to implement IoT, technology elements such as sensing technology, wired / wireless communication, network infrastructure, service interface technology and security technology are required. In recent years, sensor network, machine to machine , M2M), and MTC (Machine Type Communication). In the IoT environment, an intelligent IT (Internet Technology) service can be provided that collects and analyzes data generated from connected objects to create new value in human life. IoT is a field of smart home, smart building, smart city, smart car or connected car, smart grid, health care, smart home appliance, and advanced medical service through fusion of existing information technology . ≪ / RTI >

Accordingly, various attempts have been made to apply the 5G communication system to the IoT network. For example, technologies such as a sensor network, a machine to machine (M2M), and a machine type communication (MTC) are implemented by techniques such as beamforming, MIMO, and array antennas It is. The application of the cloud RAN as the big data processing technology described above is an example of the convergence of 5G technology and IoT technology.

This disclosure proposes a method of transmitting a status report message for data retransmission and decoding it.

In another embodiment of the present disclosure, a method of retransmitting based on a status report message is proposed.

Another embodiment of the present disclosure proposes a method of managing packets when the ordering policy for sending the packets is different.

According to an aspect of the present invention, there is provided a method of processing a control signal in a wireless communication system, the method comprising: receiving a first control signal transmitted from a base station; Processing the received first control signal; And transmitting the second control signal generated based on the process to the base station.

The effect of reducing the size of the status report message can be obtained from the present invention. According to another embodiment of the present invention, it is possible to prevent unnecessary retransmission from the present invention.

1 is an embodiment of a status report message format.
Figure 2 is one embodiment of a status report message.
Figure 3 is one embodiment of the proposed status report message.
Figure 4 is another embodiment of the proposed status report message.
Figure 5 is another embodiment of the proposed status report message.
6 shows a procedure of receiving a status report message.
7 shows a receiving procedure of the status report message.
8 shows an embodiment of a method of encoding when generating a status report message.
9 shows an example of a case where a status report message is sent due to the transmission of a divided packet.
10 shows an example of a case where a status report message is sent due to the transmission of a divided packet.
11 shows a procedure for retransmission after receiving a status report message in the transmitter of the present invention.
12 shows another procedure for retransmitting a status report message after receiving a status report message in the transmitter of the present invention.
13 shows a procedure for retransmission after receiving a status report message in the transmitter of the present invention.
FIG. 14 shows an embodiment in which the setting for sequence transmission and sequence neglect transmission is different between the base stations in the communication network.
15 shows an embodiment in which a mobile station transmits packet transmission information in the course of handover from a serving base station to a target base station.
FIG. 16 shows an embodiment in which a packet arrives and a handover occurs when performing an ignore sequence transmission.
FIG. 17 shows an embodiment of a method of sending a packet transmission information message in the embodiment of FIG.
FIG. 18 shows the format of the packet transmission information message of FIG.
19 is a diagram illustrating a structure of a terminal according to an embodiment of the present invention.
20 is a diagram illustrating a structure of a base station according to an embodiment of the present invention.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following description, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present invention rather unclear. The following terms are defined in consideration of the functions of the present invention, and these may be changed according to the intention of the user, the operator, or the like. Therefore, the definition should be based on the contents throughout this specification.

BRIEF DESCRIPTION OF THE DRAWINGS The advantages and features of the present invention and the manner of achieving them will become apparent with reference to the embodiments described in detail below with reference to the accompanying drawings. The present invention may, however, be embodied in many different forms and should not be construed as being limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the invention to those skilled in the art. Is provided to fully convey the scope of the invention to those skilled in the art, and the invention is only defined by the scope of the claims. Like reference numerals refer to like elements throughout the specification.

At this point, it will be appreciated that the combinations of blocks and flowchart illustrations in the process flow diagrams may be performed by computer program instructions. These computer program instructions may be loaded into a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus, so that those instructions, which are executed through a processor of a computer or other programmable data processing apparatus, Thereby creating means for performing functions. These computer program instructions may also be stored in a computer usable or computer readable memory capable of directing a computer or other programmable data processing apparatus to implement the functionality in a particular manner so that the computer usable or computer readable memory The instructions stored in the block diagram (s) are also capable of producing manufacturing items containing instruction means for performing the functions described in the flowchart block (s). Computer program instructions may also be stored on a computer or other programmable data processing equipment so that a series of operating steps may be performed on a computer or other programmable data processing equipment to create a computer- It is also possible for the instructions to perform the processing equipment to provide steps for executing the functions described in the flowchart block (s).

In addition, each block may represent a module, segment, or portion of code that includes one or more executable instructions for executing the specified logical function (s). It should also be noted that in some alternative implementations, the functions mentioned in the blocks may occur out of order. For example, two blocks shown in succession may actually be executed substantially concurrently, or the blocks may sometimes be performed in reverse order according to the corresponding function.

Herein, the term " part " used in the present embodiment means a hardware component such as software or an FPGA or an ASIC, and 'part' performs certain roles. However, 'part' is not meant to be limited to software or hardware. &Quot; to " may be configured to reside on an addressable storage medium and may be configured to play one or more processors. Thus, by way of example, 'parts' may refer to components such as software components, object-oriented software components, class components and task components, and processes, functions, , Subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. The functions provided in the components and components may be further combined with a smaller number of components and components or further components and components. In addition, the components and components may be implemented to play back one or more CPUs in a device or a secure multimedia card.

1 is an embodiment of a status report message format assumed in the present invention. The status report message refers to a message informing receipt / non-receipt of a packet in a retransmission procedure such as ARQ (Automatic Repeat reQuest). The embodiment of FIG. 1 shows the generation of a RLC Status Report at the Radio Link Control (RLC) layer of the 3GPP protocol. The RLC status report message may also be referred to as an RLC status PDU (Protocol Data Unit). The status report message is included in the MAC (Medium Access Control) layer, which is a lower layer, as a MAC SDU (Service Data Unit), and includes a MAC subheader. The MAC subheader includes R (Reserved), F (Format), LCID (Logical Channel ID), and L (Length) fields. The R bit is a spare bit that is not used, and the F field is a field indicating the length of the L field. For example, if the F field is 0, the L field may have 8 bits, or if the F field is 1, the L field may have a length of 16 bits. The L field indicates the length of the MAC SDU following the subheader. For example, if the L field has a value of 100, the MAC SDU may have a length of 100 bytes. 1 in the transmitter, the receiver can decode the MAC subheader and then decode the MAC SDU including the status report message.

2 is an embodiment of a status report message of the prior art. In the embodiment of FIG. 2, it is assumed that the NACK_SN field is not included in the status report message. This format can occur in situations where there is no outstanding packet recognized as a lost packet when sending a status report message.

The status report message may be composed of D / C (Data / Control), CPT (Control PDU Type), ACK_SN (Acknowledged Sequence Number), E1, Padding (padding) The D / C field indicates whether the corresponding PDU is a data PDU or a control PDU, and the status report message may be set to a value indicating control (Control, C). The CPT field is a field indicating which of the control PDUs. Since the status report message can be one of the control PDUs, the value of the CPT field can be set to a value corresponding to the status report message. The ACK_SN may have a value of one of the most recent value or the latest value of the sequence number (SN) received when sending the status report message plus one, or a value recorded in a specific variable of the packet receiver. For example, in a situation where Packets 1, 2, and 3 are successfully received, the value of ACK_SN may be a value of 4 plus 3, 1. The E1 field is a value for setting whether a Non Acknowledged Sequence Number (NACK_SN) field is added later. In the embodiment of FIG. 2, E1 is set to 0, indicating that there is no NACK_SN field. Since there is no more information after that, you can adjust the byte length by padding. At this time, the R bit may be set instead of the Padding field.

In the embodiment of FIG. 2, since the E1 field exists, padding is required to match the byte length. However, since the L field of the embodiment of FIG. 1 represents the total length of the status report message of FIG. 2, the E1 field of FIG. 2 may not be included.

Figure 3 is one embodiment of the proposed status report message. In the embodiment of FIG. 3, it is assumed that the NACK_SN field is not included in the status report message. This format can occur in situations where there is no outstanding packet recognized as a lost packet when sending a status report message.

The status report message may be composed of D / C (Data / Control), CPT (Control PDU Type), ACK_SN (Acknowledged Sequence Number) The D / C field indicates whether the corresponding PDU is a data PDU or a control PDU, and the status report message may be set to a value indicating control (Control, C). The CPT field is a field indicating which of the control PDUs. Since the status report message can be one of the control PDUs, the value of the CPT field can be set to a value corresponding to the status report message. The ACK_SN may have a value of one of the most recent value or the latest value of the sequence number (SN) received when sending the status report message plus one, or a value recorded in a specific variable of the packet receiver. For example, in a situation where Packets 1, 2, and 3 are successfully received, the value of ACK_SN may be a value of 4 plus 3, 1. Thereafter, there is no more information needed, so the length of the bytes can be adjusted by padding. At this time, the R bit may be set instead of the Padding field. However, in the embodiment of FIG. 3, the length of the ACK_SN field is 12 bits and the length of the byte is matched last, so there is no padding or R bit.

One of the features of the embodiment of Fig. 3 is that the E1 field of Fig. 2 does not exist. This is because it is not necessary to inform the existence of an additional NACK_SN in the E1 field if the length of the entire status report message is known through the L field shown in FIG.

Figure 4 is an embodiment of the proposed status report message. In the embodiment of FIG. 4, it is assumed that a NACK_SN field is included in the status report message. This format can occur in situations where there is an unacknowledged packet that is recognized as a lost packet when sending a status report message.

The status report message may be composed of Data / Control (D / C), Control PDU Type (CPT), Acknowledged Sequence Number (ACK_SN), NACK_SN, E1, E2, E3, NACK_SN_Range, SOstart, SOend and R fields. The D / C field indicates whether the corresponding PDU is a data PDU or a control PDU, and the status report message may be set to a value indicating control (Control, C). The CPT field is a field indicating which of the control PDUs. Since the status report message can be one of the control PDUs, the value of the CPT field can be set to a value corresponding to the status report message. The ACK_SN may have a value of one of the most recent value or the latest value of the sequence number (SN) received when sending the status report message plus one, or a value recorded in a specific variable of the packet receiver. For example, in a situation where Packets 1, 2, and 3 are successfully received, the value of ACK_SN may be a value of 4 plus 3, 1. The NACK_SN indicates a sequence number of a packet that is determined to have not been received when the status report message is sent. At this time, the status report message does not need to include the sequence numbers of all packets that are judged as not being received, and only the sequence numbers of the corresponding packets under specific conditions may be included. . The E1 field is a value for setting whether a Non Acknowledged Sequence Number (NACK_SN) field is added later. The E2 field indicates whether the SOstart and SOend fields exist in the corresponding block. The E3 field indicates whether the NACK_SN_Range field exists in the corresponding block. The SOstart field indicates the first byte of the lost NACK_SN at which the loss started, and the SOend field indicates the last byte of the lost NACK_SN at which the loss started. The R field indicates a spare field. Since there is no more information after that, you can adjust the byte length by padding. At this time, the R bit may be set instead of the Padding field. The name of the corresponding field may be different according to the embodiment.

In the embodiment of FIG. 4, a bundle of fields is indicated by a block. The corresponding block may be composed of NACK_SN, E1, E2, E3, NACK_SN_Range, SOstart, SOend, and R fields. Blocks in the format of FIG. 3 preceding the status report message may be referred to as mandatory blocks.

4, when the NACK_SN_Range field is set to appear in the E3 field, the NACK_SN_Range field is displayed after the E3 field. However, if the NACK_SN_Range field is set not to be displayed in the E3 field, an R bit or padding And the following information is displayed from the next byte. Through this method, the relative positions in the bytes of blocks consisting of all or part of NACK_SN, E1, E2, E3, NACK_SN_Range, SOstart, and SOend can be maintained.

Figure 5 is another embodiment of the proposed status report message. In the embodiment of FIG. 5, it is assumed that a NACK_SN field is included in the status report message. This format can occur in situations where there is an unacknowledged packet that is recognized as a lost packet when sending a status report message.

The status report message may include D / C (Data / Control), Control PDU Type (CPT), ACK_SN (Acknowledged Sequence Number), NACK_SN, E2, E3, NACK_SN_Range, SOstart, SOend and R fields. The D / C field indicates whether the corresponding PDU is a data PDU or a control PDU, and the status report message may be set to a value indicating control (Control, C). The CPT field is a field indicating which of the control PDUs. Since the status report message can be one of the control PDUs, the value of the CPT field can be set to a value corresponding to the status report message. The ACK_SN may have a value of one of the most recent value or the latest value of the sequence number (SN) received when sending the status report message plus one, or a value recorded in a specific variable of the packet receiver. For example, in a situation where Packets 1, 2, and 3 are successfully received, the value of ACK_SN may be a value of 4 plus 3, 1. The NACK_SN indicates a sequence number of a packet that is determined to have not been received when the status report message is sent. At this time, the status report message does not need to include the sequence numbers of all packets that are judged as not being received, and only the sequence numbers of the corresponding packets under specific conditions may be included. The E2 field indicates whether the SOstart and SOend fields exist in the corresponding block. The E3 field indicates whether the NACK_SN_Range field exists in the corresponding block. The SOstart field indicates the first byte of the lost NACK_SN at which the loss started, and the SOend field indicates the last byte of the lost NACK_SN at which the loss started. The R field indicates a spare field. Since there is no more information after that, you can adjust the byte length by padding. At this time, the R bit may be set instead of the Padding field. The name of the corresponding field may be different according to the embodiment.

In the embodiment of FIG. 5, a bundle of fields is indicated by a block. The corresponding block may be composed of NACK_SN, E2, E3, NACK_SN_Range, SOstart, SOend, and R fields. Blocks in the format of FIG. 3 preceding the status report message may be referred to as mandatory blocks.

5, when the NACK_SN_Range field is set to appear in the E3 field, the NACK_SN_Range field is displayed after the E3 field. However, if the NACK_SN_Range field is set not to be displayed in the E3 field, After filling with padding, the following information appears from the next byte. Through this method, the relative positions in the bytes of blocks consisting of all or part of NACK_SN, E1, E2, E3, NACK_SN_Range, SOstart, and SOend can be maintained.

One of the other features of the embodiment of Fig. 5 is that the E1 field of Fig. 4 does not exist. This is because it is not necessary to inform the existence of an additional NACK_SN in the E1 field if the length of the entire status report message is known through the L field shown in FIG.

FIG. 6 shows a procedure for receiving a status report message proposed in the present invention. In the embodiment of FIG. 6, it is assumed that a status report message including the D / C, CPT, and ACK_SN fields shown in FIG. 3 is received. In the embodiment of FIG. 6, the format of this message is referred to as a first format. In the embodiment of FIG. 3, it is assumed that the length of the ACK_SN is 12 bits, and the total status report message has a size of 2 bytes. However, if the length of the field is different or contains other fields, this size may vary. However, according to the defined format, the length of the status report message is a fixed value. This value is referred to as a first value in the embodiment of Fig.

The receiver can first decode the L field of the MAC subheader and check that the L field matches the first value. At this time, if the first value is correct, the corresponding MAC SDU can be in the first format. The D / C field or the CPT field is decoded to recognize that the corresponding PDU is a status reporting message. Then, it is determined that the message is the first type message and can be decoded in the determined format. Thereafter, the state can be updated based on the information, and the operation can be continued. If the L field is not the first value, it may be the status report format shown in FIG. 4 or FIG. 5, another control PDU, or a data packet. In FIG. 6, this is collectively referred to as a second format, in which case the packet can be decoded in a second format.

FIG. 7 shows a procedure for receiving a status report message proposed in the present invention. In the embodiment of FIG. 7, it is assumed that a status report message including the NACK_SN field shown in FIG. 5 is received.

The receiver can first decode the L field of the MAC subheader, the D / C, and the CPT field of the status report message. Then, the essential block of FIG. 5 is decoded to check the ACK_SN value. Then, it is confirmed whether the length of the decoded status report message matches the length of the status report message displayed in the L field. If they match, it is determined that the decoding of the status report message is finished and the status up to that point can be updated. If the length of the decoded status report message does not match the length of the status report message shown in the L field, it is determined that the next block exists and the next block is decoded. This process is repeated until the length of the decoded status report message matches the length of the status report message in the L field.

8 shows an embodiment of a method of encoding when generating a status report message. It is assumed that each block of Fig. 4 or Fig. 5 is encoded. If a plurality of consecutive NACK_SNs occur, the NACK_SN and NACK_SN_Range fields may be used to indicate how many SNs have been generated from the number of SNs for the efficiency of the status report message. At this time, the NACK_SN_Range field can be activated by setting the E3 field to 1. In the embodiment of FIG. 4 or FIG. 5, one bit remains in the same byte after the E3 field. Therefore, when the E3 field is set to 1, the NACK_SN_Range value can be set to 9 bits including the corresponding 1 bit. Otherwise, if the E3 field is 0, the remaining bits of the corresponding byte are filled with R field or padding, and NACK_SN can be started from the next byte. This allows the relative positions of the fields in each block to remain the same.

9 shows an example of a case where a status report message is sent due to the transmission of a divided packet. The embodiment of FIG. 9 assumes that a segmentation of a packet (RLC SDU) occurs in the RLC layer of 3GPP LTE or NR (New Radio). An RLC SDU that has not been segmented may form an RLC PDU with an RLC header. If division is required, the RLC SDU can be divided into several RLC SDU segments. In the embodiment of FIG. 9, it is assumed that it is divided into two RLC SDU segments. In this case, the divided RLC Segments may have respective RLC Headers, and this RLC Header may have different information from the header of the RLC SDU that has not been divided.

When the segmented RLC Segment 1 is transmitted first, a reordering timer can be started at the receiver based on this point. If segment 2 can not be received until the Reordering Timer expires, it shall be transmitted to the transmitter including the sequence number (SN, Sequence Number) of the corresponding RLC SDU in the status report message. However, this does not mean that the RLC SDU Segment 2 is lost, but it may be that the base station does not allocate resources and can not transmit the RLC SDU. Therefore, in this case, it is not desirable to perform retransmission after receiving the status report message.

10 shows an example of a case where a status report message is sent due to the transmission of a divided packet. The embodiment of FIG. 10 assumes that a segmentation of a packet (RLC SDU) occurs in the RLC layer of 3GPP LTE or NR (New Radio). An RLC SDU that has not been segmented may form an RLC PDU with an RLC header. If division is required, the RLC SDU can be divided into several RLC SDU segments. In the embodiment of FIG. 10, it is assumed that the RLC SDU segments are divided into two RLC SDU segments. In this case, the divided RLC Segments may have respective RLC Headers, and this RLC Header may have different information from the header of the RLC SDU that has not been divided.

When the segmented RLC Segment 1 is transmitted first, a reordering timer can be started at the receiver based on this point. If segment 2 can not be received until the Reordering Timer expires, it shall be transmitted to the transmitter including the sequence number (SN, Sequence Number) of the corresponding RLC SDU in the status report message. However, this does not mean the loss of the RLC SDU Segment 2, but it may be because the allocation time of the resource of the base station is delayed. In this case, since the packet transmission procedure may be performed due to HARQ or the like, it is not preferable to perform the retransmission after receiving the status report message in this case.

11 shows a procedure for retransmission after receiving a status report message in the transmitter of the present invention.

After the transmitter receives the status report message, it can confirm that the part that was delivered to the unreceived part has not yet been transmitted. For example, if the RLC Segment 2 portion of FIG. 10 is not received, it can be confirmed that the RLC segment 2 has been transmitted. If the part has not yet been transmitted, retransmission is not performed since the initial transmission must be performed.

If it has already transmitted the part that has not been received yet, confirm that the time elapsed since the start of transmission is earlier than the predetermined threshold time. If the part is started before the point in time that is earlier than the threshold time at the current point, the part can be retransmitted. However, if the transmission is started after the point in time that is earlier than the threshold time at the current point, the corresponding part is not retransmitted. In other words, if the current time is t and the threshold time is t1, retransmission is performed if the part that was received before the t-t1 is retransmitted, and if retransmission is not performed after t-t1. The base station may set the threshold time to the UE and may be included in the RLC-Config of the RRC message.

12 shows another procedure for retransmitting a status report message after receiving a status report message in the transmitter of the present invention.

After the transmitter receives the status report message, it can confirm when the transmitted part is transmitted to the non-receiving part. For example, if the RLC Segment 2 portion of FIG. 10 is not received, it can be confirmed when it is transmitted. It is confirmed whether the elapsed time from the start of transmission to the part which has not been received yet is transmitted before the preset threshold time. If the part is started before the point in time that is earlier than the threshold time at the current point, the part can be retransmitted. However, if the transmission is started after the point in time that is earlier than the threshold time at the current point, the corresponding part is not retransmitted. In other words, if the current time is t and the threshold time is t1, retransmission is performed if the part that was received before the t-t1 is retransmitted, and if retransmission is not performed after t-t1. The base station may set the threshold time to the UE and may be included in the RLC-Config of the RRC message.

13 shows a procedure for retransmission after receiving a status report message in the transmitter of the present invention.

After the transmitter receives the status report message, it can confirm that the part that was delivered to the unreceived part has not yet been transmitted. For example, if the RLC Segment 2 portion of FIG. 10 is not received, it can be confirmed that the RLC segment 2 has been transmitted. If the part has not yet been transmitted, retransmission is not performed since the initial transmission must be performed. If the part is already transmitted, it will perform the retransmission.

FIG. 14 shows an embodiment in which the setting for sequence transmission and sequence neglect transmission is different between the base stations in the communication network. 14, it is assumed that the base station 1 transmits the received packets to the core network in order, and the base station 2 transmits the received packets to the core network regardless of the order. When the MS handover from the BS 2 to the BS 1, since the BS 2 has already delivered the arrived packet to the core network, there may be no packet stored in the buffer. Therefore, the packet stored in the base station 1 can not be forwarded, and the base station 1 is difficult to sequentially transmit to the core network.

At this time, if the base station 2 informs the base station 1 of the sequence number (SN) of a packet already transmitted to the core network, the base station 1 can regard the packets as already received. In the embodiment of Figs. 15-17, the information is referred to as packet transmission information.

15 shows an embodiment in which a mobile station transmits packet transmission information in the course of handover from a serving base station to a target base station. When the serving BS determines handover of the MS, it sends a HO Request message to the target BS. At this time, the serving base station can inform the target base station whether the radio bearers of the serving base station perform in-sequence delivery or out-of-sequence delivery, respectively. Thereafter, the target serving station transmits a HO Request ACK message, and at this time, it can request the packet transmission information of the bearer. Then, the serving base station transmits the handover command (HO Command) to the mobile station and then performs the actual handover.

Independently of the procedure, or after receiving a request for packet transmission information, the serving base station can transmit the packet transmission information to the target base station.

FIG. 16 shows an embodiment in which a packet arrives and a handover occurs when performing an ignore sequence transmission. In the embodiment of FIG. 16, the sequence number of the packet ... , 14, 15, 19, and 16, and the base station transmits these packets to the core network as soon as they are processed. Then, when receiving the handover command message, 17, 18, 20, 21, ... The packets corresponding to the sequence numbers such as " 0 "

FIG. 17 shows an embodiment of a method of sending a packet transmission information message in the embodiment of FIG. At this time, the reception state of the packet is the same as the embodiment of FIG. At this time, the serving base station marks 16, which is the last sequence number of the received packet, as an offset, and displays 1 as a bitmap for subsequent packets, and 0 as a non-received packet . In this case, the bitmap can be represented by 00100000.

In yet another embodiment, the most recent sequence number that has not been received may be marked as an offset and subsequently marked as a bitmap. In this case, the offset can be displayed as 17 and the bitmap as 01000000.

FIG. 18 shows the format of the packet transmission information message of FIG. The packet transmission information may include an offset value and a bitmap value of a predetermined length as shown in FIG.

19 is a diagram illustrating a structure of a terminal according to an embodiment of the present invention.

Referring to FIG. 19, the terminal may include a transceiver unit, a terminal control unit, and a storage unit. In the present invention, the terminal control unit may be defined as a circuit or an application specific integrated circuit or at least one processor.

The transceiver can send and receive signals with other network entities. The transceiver may receive system information from, for example, a base station and may receive a synchronization signal or a reference signal.

The terminal control unit can control the overall operation of the terminal according to the embodiment of the present invention. For example, the terminal control unit can control the signal flow between each block to perform the operations according to the above-described drawings and flowcharts.

The storage unit may store at least one of information transmitted and received through the transmission / reception unit and information generated through the terminal control unit.

20 is a diagram illustrating a structure of a base station according to an embodiment of the present invention.

Referring to FIG. 20, the base station may include a transmission / reception unit, a base station control unit, and a storage unit. In the present invention, the base station control unit may be defined as a circuit or an application specific integrated circuit or at least one processor.

The transceiver can send and receive signals with other network entities. The transmitting and receiving unit can transmit system information to the terminal, for example, and can transmit a synchronous signal or a reference signal.

The base station control unit can control the overall operation of the base station according to the embodiment of the present invention. For example, the base station control unit may control the signal flow between each block to perform operations according to the above-described drawings and flowcharts.

The storage unit may store at least one of information transmitted and received through the transmission / reception unit and information generated through the base station control unit.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is to be understood that the invention is not limited to the disclosed exemplary embodiments. Accordingly, the scope of the present invention should be construed as being included in the scope of the present invention, all changes or modifications derived from the technical idea of the present invention.

Claims (1)

A method for processing a control signal in a wireless communication system,
Receiving a first control signal transmitted from a base station;
Processing the received first control signal; And
And transmitting the second control signal generated based on the process to the base station.

Images