KR20130126844A - Method and apparatus for providing contiuous service of rohc between base stations in lte system - Google Patents

Abstract

The present invention relates to a synchronization technique of a low load component carrier in carrier aggregation for maximizing the availability of an available frequency range. According to the present invention, ROHC Context header information is transferred by using X2 and S1 hand over message in the hander over between eNodeBs.

Description

Method of providing continuous service of header compression (RROC) between base stations in LTE system {Method and Apparatus for Providing Contiuous Service of ROHC between base stations in LTE System}

The present invention relates to a method and apparatus for efficiently using radio resources by recycling header information from initial data by recycling previously used ROHC information when transmitting data in uplink or downlink even during a handover event. will be.

One of the key features of 3G / LTE's Packet Data Convergence Protocol (3CPPP standard TS36.323) is ROHC.

In the conventional LTE technology, there is no continuity of ROHC since no ROHC context (eg, IP address, time stamp) is transmitted during handover.

In the present invention, the ROHC context information is transmitted during handover between eNodeBs using the X2 and S1 handover messages so that the ROHC continuously operates after the handover and transmits the header-compressed packet.

In the present invention, the ROHC context information is also transmitted during X2 or S1 handover, and the header-compressed information can be transmitted from the initial data by reusing existing ROHC information when transmitting data in uplink or downlink even during a handover event. Therefore, unnecessary overhead can be prevented, so that radio resources can be efficiently used.

1 and 2 show the procedure of the PDCP protocol.
3 illustrates an interface definition, and direct connection between eNBs is performed through an X2 interface, and an interface between an eNB and an MME is configured as an S1 interface.
4 shows a procedure for handover using an S1 message.
FIG. 5 illustrates a process of transmitting an uplink / downlink to an eNB Status Transfer message and an MME Status Transfer message.
6 shows a procedure for handover using an X2 message.
7 shows an SN Status Transfer procedure.
8 is a configuration block diagram of the eNB 120 / LGW 145 and the MME of FIGS. 1 to 7 according to another embodiment.

Hereinafter, some embodiments of the present invention will be described in detail with reference to exemplary drawings. In adding reference numerals to the components of each drawing, it should be noted that the same reference numerals are assigned to the same components as much as possible even though they are shown in different drawings. In the following description of the present invention, 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.

In describing the components of the present invention, terms such as first, second, A, B, (a), and (b) may be used. These terms are intended to distinguish the constituent elements from other constituent elements, and the terms do not limit the nature, order or order of the constituent elements. When a component is described as being "connected", "coupled", or "connected" to another component, the component may be directly connected to or connected to the other component, It should be understood that an element may be "connected," "coupled," or "connected."

When handover, ROHC-related context information disappears, and eventually ROHC is reset and full header packet transmission is required. When the UE handovers, it is due to the current standard operation of initializing the header compression context, which can be solved by allowing reuse of the compression context.

In the present invention, ROHC information is maintained by exchanging ROHC context information between handovers between eNodeBs, thereby preventing full header packet transmission even during handover.

One of the main functions of 3G / LTE's Packet Data Convergence Protocol (3GPP standard TS36.323) is inter-base station header compression (ROHC).

When transmitting the packet data convergence protocol (PDCP) SDU (Service Data Unit), the transmitting part transmits only the minimum header information by transmitting only the changed part of the header when the header of the packet is repeated.

The existing voice service uses CS (Circuit Switched) network, so there is no problem because there is no separate IP header. However, in the LTE system, such a CS network does not exist, and therefore, VoIP is required only when a service is performed in a PS (Packet Switched) network, and an IP / UDP / RTP header exists for this purpose.

1 and 2 show the procedure of the PDCP protocol. When the PDCP SDU is received from the upper layer, the SDU is numbered. This numbering uses a sequence number (SN) and a hyper frame number (HFN). The Sequence Number is incremented by 1 according to the SDU order delivered until it is smaller than the Maximum_PDCP_SN value. If this value is exceeded, the Sequence Number is set to 0, and the HFN is increased by one. The SN of the next delivered SDU is increased by one again, and is increased by one until this value does not exceed Maximum_PDCP_SN. These SN and HFN values are delivered to the Receiver Entity as a PDCH Header.

The ROHC protocol operates the static part of the header in such a way that the sender and the receiver store and use each other and update the corresponding part only when a specific part of the header is changed.

In addition, dynamic changes, such as the Time Stamp in the RTP header, can be compressed by sending only the difference between the Reference Clock in the Sender and Receiver.

This protocol header compression function is defined by IETF and related RFC documents are as follows.

In case of a terminal supporting VoIP, the RTP / UDP / IP protocol must be supported and generally supports RFC 3095.

The problem with the current LTE specification is to reset the PDCP's ROHC context information (eg IP Address, Time Stamp) at the time of handover, so the first packet after the handover has to send back both the IP address and time stamp. Done.

In this case, there is a problem of transmitting the IP header overhead (125% to 188%) of the first VoIP packet.

For handover, there are X2 handover and S1 handover.

If there is an X2 interface, the handover is executed using X2. If there is no X2 interface, the handover is performed through the S1 interface.

3 illustrates an interface definition, and direct connection between eNBs is performed through an X2 interface, and an interface between an eNB and an MME is configured as an S1 interface.

The 3GPP core network is a network mobility management entity (hereinafter referred to as 'MME') that is responsible for processing control signals of an evolved UTRAN base station (eNB) and a core network (Core Network), It includes a serving gateway (hereinafter referred to as S-GW) and a packet data network gateway (hereinafter referred to as 'PDN-GW' or 'P-GW').

The contents transmitted in the eNB Status Transfer and MME Status Transfer messages, which are S1 messages, and the SN Status Transfer messages, which are X2 messages, are shown in the following table, and include a PDCP Sequence Number and a Hyper Frame Number (HFN). The messages transmitted through the X2 and S1 interfaces can be seamlessly handovered by receiving PDCP information as shown below and receiving data not transmitted to each other during handover.

However, since the ROHC context information is not transmitted, the initial data does not operate the ROHC, so the data in which the header is compressed is not transmitted and the data including the general full header is transmitted.

IE Of Group Name Presence Range IE type and reference Semantics description Criticality Assigned Criticality E- RABs Subject to  Status Transfer List One - - > E- RABs Subject to  Status Transfer Item One to  <maxnoof E- RABs > EACH ignore >> E-RAB ID M 9.2.1.2 - - >> UL COUNT value M COUNT Value 9.2.1.32 PDCP-SN and HFN of first missing UL PDCP SDU - - >> DL COUNT value M COUNT Value 9.2.1.32 PDCP-SN and HFN that the target eNB should assign for the next DL SDU not having an SN yet - - >> Receive Status Of UL PDCP SDUs O BIT STRING (4096) PDCP Sequence Number = (First Missing SDU Number + bit position) modulo 4096

0: PDCP SDU has not been received.
1: PDCP SDU has been received correctly.

According to the present invention, a method of transmitting a ROHC context message between eNodeBs is also provided.

The first method is to send ROHC Context using S1 interface.

The second method is to transmit the ROHC context using the X2 interface.

The operation of the invention is as follows.

4 shows a procedure for handover using an S1 message. At this time, in step 10, the eNoddeB delivers the eNB Status Transfer message to the Source MME to convey the status related to handover, and the message is transmitted from the Target MME to the target eNodeB through the 11th MME Status Transfer message. .

The information transmitted here transmits state information on a service data unit (SDU) delivered on downlink or uplink.

FIG. 5 illustrates a process of transmitting an uplink / downlink to an eNB Status Transfer message and an MME Status Transfer message.

In the present invention, in addition to the information about the SDU status (Sequence Number) transmitted in the uplink / downlink in the eNB Status Transfer message and the MME Status Transfer message, the context information for the ROHC is additionally transmitted as shown in the table below.

IE Of Group Name Presence Range IE type and reference Semantics description Criticality Assigned Criticality Message Type M 9.2.13 YES ignore E- RABs Subject  To Status  Transfer List One YES ignore > E- RABs Subject  To Status  Transfer Item 1 to <maxnoof Bearers> EACH ignore >> E- RAB ID M 9.2.23 >> Receive Status  Of UL PDCP SDUs O BIT STRING (4096) PDCP Sequence Number = (First Missing SDU Number + bit position) modulo 4096

0: PDCP SDU has not been received.
1: PDCP SDU has been received correctly. >> UL COUNT Value M COUNT Value
9.2.15 PDCP-SN and Hyper Frame Number of the first missing UL SDU >> DL COUNT Value M COUNT Value
9.2.15 PDCP-SN and Hyper frame number that the target eNB should assign for the next DL SDU not having an SN yet >> Uplink RFC  3095 Context O RFC 3095 See below for details >> Downlink  RFC 3095 Context O RFC 3095 See below for details

The detailed context contents of RFC 3095 indicated in the previous table are defined as the table below.

>> RFC 3095 Header compression according to IETF standard RFC 3095 >>> Profiles MP 1 to <maxROHC- Profiles> Profiles supported by both compressor and decompressor in both UE and UTRAN. Profile 0 shall always be supported. >>>> Profile instance MP Integer (1 .. 3) 1 = 0x0001, 2 = 0x0002, 3 = 0x0003 (see [52]) >>> Uplink OP Indicates the necessary information elements for Uplink. >>>> Max_CID MD Integer (1 .. 16383) Highest context ID number to be used by the UE compressor.
Default value is 15. >>> Downlink OP Indicates the necessary information elements for Downlink. >>>> Max_CID MD Integer (1 .. 16383) Highest context ID number to be used by the UE decompressor.
Default value is 15. >>>> Reverse_Decompression_Depth MD Integer (0..65535) Determines whether reverse decompression should be used or not and the maximum number of packets that can be reverse decompressed by the UE decompressor. Default value is 0 (reverse decompression shall not be used).

Similarly, if there is an X2 Interface, the Context message for ROHC is delivered directly through the X2 message.

6 shows a procedure for handover using an X2 message.

In step 6 of FIG. 6 (SN Status Transfer), the contents of the ROHC context are the same as the ROHC context information transmitted through S1 described above.

7 shows an SN Status Transfer procedure.

Referring to FIG. 7, the SN Status Transfer procedure also informs the target eNB of the status information of the PDCP SDU transmitted with an eNB Status Transfer or MME Status Transfer message. In the present invention, ROHC context information is additionally delivered to this message. It plays a role. The ROHC context (IP address, time stamp, etc.) is exchanged between the eNodeBs through the SN Status Transfer message, which is an X2 message, between the eNodeBs.

In the present invention, the ROHC context information is also transmitted during X2 or S1 handover, and the header-compressed information can be transmitted from the initial data by reusing existing ROHC information when transmitting data in uplink or downlink even during a handover event. Therefore, unnecessary overhead can be prevented, so that radio resources can be efficiently used.

8 is a configuration block diagram of the eNB 120 / LGW 145 and the MME of FIGS. 1 to 7 according to another embodiment.

Referring to FIG. 8, the eNB 120 / LGW 145 includes a storage unit 1510, a controller 1520, and a transceiver 1530.

The MME 125 includes a storage means 1540, a controller 1550, and a transceiver 1560.

These storage means 1510, 1540 store a software program in which the system architecture or methods are implemented in FIGS.

Each of the controllers 1520 and 1550 controls the storage means 1510 and 1540 and the transceivers 1530 and 1560, respectively. Specifically, each of the controllers 1520 and 1550 executes the system architecture or methods in FIGS. 1 to 7 respectively stored in the storage means 1510 and 1540. Each of the controllers 1520 and 1550 transmits the aforementioned signals through the transceivers 1530 and 1560.

The 3GPP standards TS36.323 and RFC 3095 mentioned herein form part of this specification and may be added or cited as part of this specification as needed.

While the present invention has been described in connection with what is presently considered to be the most practical and preferred embodiments, it is to be understood that the invention is not limited to the disclosed embodiments. That is, within the scope of the present invention, all of the components may be selectively coupled to one or more of them. In addition, although all of the components may be implemented as one independent hardware, some or all of the components may be selectively combined to perform a part or all of the functions in one or a plurality of hardware. As shown in FIG. Codes and code segments constituting the computer program may be easily inferred by those skilled in the art.

Such a computer program may be stored in a computer readable storage medium and read and executed by a computer, thereby implementing embodiments of the present invention. As a storage medium of the computer program, a magnetic recording medium, an optical recording medium, or the like can be included.

It is also to be understood that the terms such as " comprises, "" comprising," or "having ", as used herein, mean that a component can be implanted unless specifically stated to the contrary. But should be construed as including other elements. All terms, including technical and scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs, unless otherwise defined. Commonly used terms, such as predefined terms, should be interpreted to be consistent with the contextual meanings of the related art, and are not to be construed as ideal or overly formal, unless expressly defined to the contrary.

The foregoing description is merely illustrative of the technical idea of the present invention, and various changes and modifications may be made by those skilled in the art without departing from the essential characteristics of the present invention. Therefore, the embodiments disclosed in the present invention are intended to illustrate rather than limit the scope of the present invention, and the scope of the technical idea of the present invention is not limited by these embodiments. The protection scope of the present invention should be interpreted by the following claims, and all technical ideas within the equivalent scope should be interpreted as being included in the scope of the present invention.

Claims (1)

handover between eNodeBs; And
The ROHC continually operates after handover by passing ROHC Context header information as header compressed packet when handover between eNodeBs using X2 and S1 handover message. How to provide continuous service

Images