KR101124066B1

KR101124066B1 - 왕복 지연시간이 긴 시스템에서의 ａｒｑ와 ｈａｒｑ의 상호작용 방법

Info

Publication number: KR101124066B1
Application number: KR1020080121805A
Authority: KR
Inventors: 홍태철; 강군석; 안도섭; 이호진
Original assignee: 한국전자통신연구원
Priority date: 2008-12-03
Filing date: 2008-12-03
Publication date: 2012-04-12
Also published as: US8291276B2; US20100138713A1; KR20100063332A

Abstract

왕복 지연시간이 긴 시스템에서의 ARQ와 HARQ의 상호작용 방법이 제공된다. HARQ계층으로부터의 내부 피드백 정보를 이용하여, ARQ 동작을 위한 전송 윈도우(Transmission Window)가 동작하도록 하고, ARQ 상태 보고 정보를 이용하여 대기 윈도우(Waiting Window)가 동작하도록 하여, 긴 왕복지연시간으로 인하여 전송 윈도우가 빠르게 이동하지 못하는 단점을 해결할 수 있다.

ARQ, HARQ, 전송 윈도우, 대기 윈도우, 재전송 윈도우

Description

왕복 지연시간이 긴 시스템에서의 ＡＲＱ와 ＨＡＲＱ의 상호작용 방법{INTERACTION METHOD BETWEEN ARQ AND HARQ FOR THE SYSTEM WITH LONG ROUND TRIP DELAY}

본 발명은 왕복 지연시간이 긴 시스템에서의 ARQ와 HARQ의 상호작용 방법에 관한 것이다.

본 발명은 지식경제부 및 정보통신연구진흥원의 IT원천기술개발사업의 일환으로 수행한 연구로부터 도출된 것이다[과제관리번호: 2008-F-010-01, 과제명: IMT-Advanced 위성접속 기술개발(표준화연계)].

HARQ(Hybrid Automatic Repeat Request)는 FEC(Forward Error Correction) 방법과 ARQ를 결합한 방법이다.

FEC(Forward Error Correction)는 오류정정부호를 사용하여 무선 채널에서 발생하는 오류를 정정하여 정확한 정보를 수신할 수 있도록 도와주는 기술이다.

또한, ARQ는 채널에서 오류가 발생하면 수신단에서 송신단에 재전송을 요구하여, 패킷을 재전송 받는 방법이다.

HARQ에 의한 방법은 오류정정부호를 사용하여 오류를 방지하며, 오류정정부 호로 오류정정이 되지 않는 경우에, 자동재전송요구를 통하여 패킷을 재전송하는 방법을 말한다.

일반적으로 HARQ는 종래의 ARQ가 수행되는 계층보다 아래 계층에서 수행하도록 하며, HARQ를 통해 오류정정이 실패한 경우, ARQ를 통해 오류정정을 하도록 설계되었다.

종래의 지상이동통신시스템의 경우, ARQ를 수행하는 BSC(Base Station Controller), RNC(Radio Network Controller) 등과 같은 네트워크 제어기가, 기지국과 분리되어 있어서, HARQ와 ARQ사이의 연동작용을 전송효율화를 이루기가 쉽지 않았다.

그러나, 3GPP(3rd Generation Partnership Project)에서 진행중인 LTE(Long Term Evolution) 표준에 따르면, 기지국에서 네트워크 제어기 기능까지 수행하도록 정의하여, HARQ와 ARQ의 상호작용 기술을 적용할 수 있는 토대가 마련되었다.

본 발명은 상기와 같은 종래 기술을 개선하기 위해 안출된 것으로서, HARQ계층으로부터의 내부 피드백 정보를 이용하여, ARQ 동작을 위한 전송 윈도우(Transmission Window)가 동작하도록 하고, ARQ 상태 보고 정보를 이용하여 대기 윈도우(Waiting Window)가 동작하도록 하여, 긴 왕복지연시간으로 인하여 전송 윈도우가 빠르게 이동하지 못하는 단점을 해결하고자 한다.

또한, 본 발명은 HARQ의 NACK을 ACK으로 오인하는 오류가 발생하는 경우에도, 대기 윈도우에 있는 패킷을 재전송할 수 있도록 하고자 한다.

본 발명의 일측에 따른 왕복 지연시간이 긴 시스템에서의 ARQ와 HARQ의 상호작용 방법은, 패킷 전송에 대응하여 수신되는 제1피드백 정보를 이용하여, 제1계층부가 상기 패킷 전송에 대한 성공 또는 실패 여부를 판단하는 단계; 상기 패킷의 전송을 성공한 것으로 상기 제1계층부가 판단한 경우, 제2계층부가 상기 패킷을 전송윈도우로부터 대기윈도우측으로 전달하는 단계; 상기 패킷의 전송을 실패한 것으로 상기 제1계층부가 판단한 경우, 제2계층부에서 실패한 것으로 판단되는 상기 패킷을 전송 윈도우로부터 재전송 윈도우 측으로 전달하여, 상기 패킷을 재전송하는 단계; 및 상기 패킷의 정보를 포함하는 제2피드백 정보를 제2계층부가 수신하고, 상기 제2피드백 정보에 기초하여 상기 패킷의 처리를 결정하는 단계를 포함한다.

이때, 상기 패킷의 전송을 성공한 것으로 상기 제1계층부가 판단한 경우, 제 2계층부가 상기 패킷을 전송윈도우로부터 대기 윈도우측으로 전달하는 단계는, 제1계층부의 피드백 정보를 활용하여, 제2계층부가 추가적인 전송을 하기 위해 상기 전송윈도우의 크기를 조절하는 단계를 더 포함할 수 있다.

이때, 상기 제1계층부의 피드백 정보를 활용하여, 제2계층부가 추가적인 전송을 하기 위해 상기 전송윈도우의 크기를 조절하는 단계는, 상기 패킷의 패킷 번호가 이번에 수신해야 할 패킷 번호와 동일하지 않은 경우, 추가적인 패킷 전송을 위하여 제2계층부의 전송윈도우와 관련된 최대 전송 상태 변수(Maximum send state variable)를 패킷의 크기만큼 증가시키는 단계; 상기 패킷의 패킷 번호가 새로 수신해야 할 패킷 번호와 동일하고 대기 윈도우의 재순서화 작업이 필요한지의 여부를 판단하여, 재순서화 작업을 수행하는 단계; 및 재순서화 작업이 성공적으로 완료된 경우에는, 상기 최대 전송 상태 변수를 기본값으로 환원하고, 재순서화 작업이 성공적으로 완료되지 않은 경우에는, 상기 최대 전송 상태 변수를 패킷의 크기만큼 증가시키는 단계를 더 포함할 수 있다.

이때, 상기 패킷의 전송 실패를, 전송 성공으로 인식하는 오류가 발생한 경우, 상기 패킷을 재전송하는 단계를 더 포함할 수 있다.

이때, 상기 패킷의 전송 실패를, 전송 성공으로 인식하는 오류가 발생한 경우, 상기 패킷을 재전송하는 단계는, 상기 NACK가 ACK로 인식되는 오류가 발생한 경우, 상기 패킷의 재전송에 관한 정보를 포함하는 제1피드백 또는 제2피드백 정보를 수신하는 단계; 상기 제1피드백 또는 제2피드백 정보에 기초하여 상기 대기 윈도우가 상기 패킷을 상기 재전송 윈도우 측으로 전달하는 단계; 및 상기 재전송 윈 도우가 상기 패킷을 재전송하는 단계를 포함할 수 있다.

이때, 상기 제1계층부는, HARQ(Hybrid Automatic Repeat Request)를 수행하는 MAC(Media Access Control)계층일 수 있다.

이때, 상기 제2계층부는, ARQ(Automatic Repeat Request)를 수행하는 RLC(Radio Link Control)계층일 수 있다.

이때, 상기 제1피드백 정보는, HARQ 관련 피드백 정보일 수 있다.

이때, 상기 제2피드백 정보는, ARQ 관련 피드백 정보일 수 있다.

이때, 상기 패킷의 정보를 포함하는 제2피드백 정보를 제2계층부가 수신하고, 상기 제2피드백 정보에 기초하여 상기 패킷의 처리를 결정하는 단계는, 상기 제2피드백 정보를 분석한 결과, 상기 패킷의 전송이 성공한 경우, 대기 윈도우에서 해당 패킷을 삭제하는 단계; 상기 제2피드백 정보를 분석한 결과, 상기 패킷의 전송이 실패하고 상기 패킷이 상기 전송 윈도우에 존재하는 것으로 확인된 경우, 제1계층부가 상기 패킷의 재전송을 수행하고 있는 경우는 재전송을 실행하지 않는 단계; 및 상기 제2피드백 정보를 분석한 결과, 상기 패킷의 전송이 실패하고 상기 패킷이 상기 전송 윈도우에 존재하는 것으로 확인된 경우, 제1계층부가 상기 패킷의 재전송을 수행하고 있지 않은 경우는 재전송을 실행하는 단계를 포함할 수 있다.

본 발명의 일례에 따르면 HARQ계층으로부터의 내부 피드백 정보를 이용하여, ARQ 동작을 위한 전송 윈도우(Transmission Window) 동작하도록 하고, ARQ 상태 보고 정보를 이용하여 대기 윈도우(Waiting Window)가 동작하도록 하여, 긴 왕복지연 시간으로 인하여 전송 윈도우가 빠르게 이동하지 못하는 단점을 해결할 수 있다.

또한 본 발명에 따르면, HARQ의 NACK을 ACK으로 오인하는 오류가 발생하는 경우에도, 대기 윈도우에 있는 패킷을 재전송하여 빠르게 전송 오류에 대응할 수 있다.

이하 첨부된 도면들 및 첨부된 도면들에 기재된 내용들을 참조하여 본 발명의 바람직한 실시예를 상세하게 설명하지만, 본 발명이 실시예들에 의해 제한되거나 한정되는 것은 아니다. 각 도면에 제시된 동일한 참조부호는 동일한 부재를 나타낸다.

하기에서 기술하는 본 발명에 따른 실시예는 위성 시스템과 같은 신호의 왕복 지연시간이 긴 시스템에 적용될 수 있다.

왕복 지연시간이 긴 시스템의 경우에는 긴 왕복 지연시간으로 인하여, 전송 패킷에 대한 NACK을 수신하여 HARQ 레벨에서 상기 전송 패킷을 재전송한 패킷이 수신 단말기에 도착하기 전에, 상태 정보(STATUS PDU)를 수신하게 되어 ARQ 레벨의 패킷의 재전송이 수행되는 결과를 초래할 수 있다. 또한 제한된 전송 윈도우 크기를 가지는 경우, HARQ를 통해 전송이 성공하였음에도, 상태 정보(STATUS PDU)를 수신할 때까지 새로운 패킷을 전송하지 못하는 상황도 발생할 수 있다.

따라서, 긴 왕복지연시간을 가지는 시스템에서 HARQ/ARQ를 모두 동작시키면 동일한 데이터를 HARQ와 ARQ에서 모두 재전송하는 경우가 발생하여 대역폭 낭비를 초래하며, 전송률도 저하될 수 있다.

본 발명은 이와 같은 문제를 해결하기 위한 수단을 제공하고자 한다.

도 1은 본 발명의 일례에 따른 윈도우를 설명하기 위한 도면이다. 도 1을 참조하여 본 발명의 일례에 따른 윈도우를 설명하기로 한다.

본 발명의 일례에 따르면, 전송 윈도우(Transmission Window: 120)는 상기 HARQ(Hybrid Automatic Repeat Request)의 수행에 해당하는 계층으로부터의 내부 피드백(feedback) 정보에 기초하여 동작하고, 대기 윈도우(Waiting Window: 110)는 상기 ARQ(Automatic Repeat Request)에 관련된 상태 보고 정보에 기초하여 동작한다.

HARQ(Hybrid Automatic Repeat Request)는 FEC(Forward Error Correction) 방법과 ARQ(Automatic Repeat Request)를 결합한 방법이다. FEC는 오류정정부호를 사용하여 무선 채널에서 발생하는 오류를 정정하여 정확한 정보를 수신할 수 있도록 하는 기술이고, ARQ는 채널에서 오류가 발생하면 수신단에서 송신단에 재전송을 요구하여 다시 패킷을 전송받는 방법이다.

따라서, HARQ 방법에 따르면 오류정정부호를 사용하여 오류를 방지하며, 오류정정부호로 오류정정이 안 되는 경우에는 자동재전송요구를 통하여 패킷을 재전송할 수 있다.

일반적으로 HARQ는 ARQ가 수행되는 계층보다 아래 계층에서 수행하도록 하며, HARQ를 통해 오류정정이 실패한 경우, ARQ를 통해 오류정정을 하도록 설계된다.

HARQ의 경우, 복잡도를 줄이기 위하여 스탑-앤-웨이트(Stop-And-Wait)의 방 식의 재전송기법을 사용하는데 반해, ARQ의 경우에는 선택적 반복(Selective Repeat) 방식의 재전송 기법을 사용한다.

3GPP(3rd Generation Partnership Project) LTE(Radio Network Controller) 시스템에서 사용되는 ARQ의 경우에는 전송 윈도우(Transmitting Window)와 수신윈도우(Receiving Window)를 기반으로 재전송을 수행한다. 전송 윈도우는 VT(A), VT(S), VT(MS)의 값을 가지고 동작을 제어하며, 수신윈도우는 VR(R), VR(H), VR(MR)의 값을 가지도 동작을 제어한다. 전송 윈도우와 수신윈도우에서 정의된 상기와 같은 변수들의 의미는 다음과 같다.

VT(A)는 순서에 따라 ACK(수신 긍정 확인 신호)를 수신해야 할 다음 데이터 패킷의 일련 번호(Sequence Number: SN) 값을 가지며, 전송 윈도우에 하위 값으로 제공된다.

VT(S)는 다음에 새롭게 생성되어 전송된 데이터 패킷에 할당할 일련 번호(SN) 값을 가진다. VT(S)는 초기 값이 0으로 설정되고, 일련 번호(SN) = VT(S)인 AMD PDU를 전달할 때 마다 갱신된다.

VT(MS)는 VT(A) + 전송 윈도우의 크기(AM_Window_Size)와 동일하고, 이것은 전송 윈도우에 상위 값으로 이용된다.

VR(R)는 마지막으로 순서대로 완벽하게 수신된 데이터 패킷의 일련 번호(SN)의 값을 가지고, 이것은 수신윈도우의 하위 값으로 이용된다.

VR(H)는 수신된 데이터 패킷들 중에서 가장 큰 일련 번호(SN) 값을 가진다.

VR(MR)은 이 상태변수는 VR(R) + 전송 윈도우의 크기(AM_Window_Size)와 같 은 값을 가지는 데, 이것은 수신윈도우를 넘는 첫 번째 데이터 패킷의 일련 번호(SN)의 값이다.

이와 같이, HARQ와 ARQ는 각각의 계층(Layer)에서 할당된 임무를 독립적으로 완수하도록 하는데, HARQ와 ARQ의 상호작용 방법은 MAC계층(또는 물리계층)에서 수행되는 HARQ 동작과, RLC(Radio Link Control)계층에서 수행되는 ARQ를 연동하여 전송효율을 개선하고자 하는 방법이다.

이러한 방법들은 기본적으로 HARQ에서 수신한 피드백 정보를 ARQ 계층에 보고하고, 이 정보를 이용하여 ARQ에서 빠른 재전송 및 HARQ 피드백 오류에 대한 대처를 하도록 하고 있다.

따라서, 본 발명에 따르면 왕복지연시간이 긴 시스템에 적합한 HARQ와 ARQ의 사이의 상호작용을 통해 전송효율을 높일 수 있다.

도 1에 도시된 바와 같이, 전송 윈도우(Transmission Window: 120)가 기본적으로 HARQ 피드백 정보에 따라서 운영되고, 상태 보고 정보 패킷(STATUS PDU)에 따라서 대기 윈도우(Waiting Window: 110)가 실행된다.

전송 윈도우(Transmission Window: 120)의 경우, 3GPP LTE의 RLC(Radio Link Controller) 전송 윈도우(Transmission Window: 120)의 VT(A)(121), VT(S)(122), VT(MS)(123)를 이용하여 운영하고, 대기 윈도우(Waiting Window)의 경우 VT(CA)(111)를 통해서 운영한다.

전송 윈도우(120)의 경우 상기에서 설명한 바와 같으며, VT(A)의 경우만 동작방식을 HARQ 피드백 정보에 따른 것으로 수정한다. 일반적으로 VT(A)의 경우, 상태 보고 정보 패킷(STATUS PDU)의 ACK(수신 긍정 확인 신호)를 통해서 갱신되는데, 제안하는 방법에서는 VT(A)가 HARQ의 ACK 수신에 따른 내부 피드백 정보를 통해 갱신되는 것으로 정의할 수 있다.

또한, 대기 윈도우(110)의 VT(CA)는 상태 보고 정보 패킷(STATUS PDU)에 대한 ACK에 의해서 갱신되는 것으로 정의하였다. 이렇게 분리하여 운영하는 경우, HARQ로부터의 내부 ACK정보에 따라서 전송 윈도우(120)가 동작하기 때문에 빠르게 다음 PDU(Protocol Data Unit)들에 대한 전송이 이루어질 수 있는 장점이 있으며, 또한 상태 보고 정보 패킷(STATUS PDU)에서 NACK(수신 부정 확인 신호)를 수신한 패킷이, 대기 윈도우(110)에 없는 경우에는 HARQ의 재전송 중임을 알 수 있으므로, 불필요한 재전송을 방지하는 장점도 가지고 있다.

VT(CA)는 순서에 따라 상태 보고 정보 패킷(STATUS PDU)을 통해 ACK을 수신해야 할 다음 데이터 패킷의 일련 번호(Sequence Number: SN)값을 가지며, 대기 윈도우(110) 에 하위 값으로 제공된다. 대기 윈도우의 크기는 시스템에 맞게 시스템 설계자가 결정할 수 있다.

도 2는 본 발명의 일례에 따른 두 개의 윈도우(Window)를 사용하여 운영하는 RLC(Radio Link Control)의 전송 버퍼의 논리적인 구조를 도시한 도면이다.

본 발명의 일례에 따른 버퍼는, 전송 버퍼(Transmission Buffer: 210)와 재전송 버퍼(Retransmission Buffer: 240), 대기 윈도우(Waiting Window)를 위한 대기 버퍼(Waiting Buffer: 240)를 포함하여 구성된다.

또한, 도 1에서 설명한 것과 같이 전송 버퍼(Transmission Buffer: 210) 및 전송 윈도우(Transmission Window: 120)는 HARQ 피드백(Feedback) 정보에 영향을 받고, 대기 버퍼(Waiting Buffer: 220) 및 대기 윈도우(Waiting Window): 110)는 상태 보고 정보 패킷(STATUS PDU: 230)의 영향을 받는다.

또한, 대기 버퍼(Waiting Buffer: 220)의 경우, HARQ개체에서 NACK를 ACK으로 인식하는 오류 발생을 감지한 경우에는, 그에 대한 피드백 정보를 수신하여, 대기 버퍼(Waiting Buffer)에 있는 패킷을 재전송할 수 있도록 하는 기능도 수행한다.

수신기가 전송한 NACK를 ACK로, 송신기 측에서 잘못 인식한 경우, 성공적인 전송으로 간주하고, 다음 전송을 수행하게 된다. 따라서, 이러한 경우에는, 수신기에서 NACK가 ACK로 잘못 인식되는 오류를 알려주어, 송신기가 NACK가 ACK로 잘못 인식된 오류가 발생한 해당 패킷을 다시 전송하도록 한다.

도 3은 본 발명의 일례에 따른 HARQ 피드백 정보를 수신한 경우의 단말의 동작을 나타내는 흐름도이다.

송신측이 HARQ 피드백 패킷을 수신하고(S301), NACK가 ACK로 잘못 인식되는 오류가 발생하였는지의 여부를 판단한다(S302).

상기 판단 결과, NACK가 ACK로 잘못 인식되는 오류(NACK to ACK 오류)가 발생한 경우에는, 대기 윈도우(Waiting Window)에서 상기 NACK to ACK 오류 발생 HARQ 패킷에 해당하는, 패킷(RLC PDU)을 복사하여 재전송 버퍼(Retransmission Buffer)로 보내서 재전송하고 종료한다(S303).

송신측의 상기 판단 결과, NACK가 ACK로 잘못 인식되는 오류(NACK to ACK 오 류)가 발생하지 않은 경우에는, 패킷의 전송이 실패하였지를 판단하여(S304), 패킷의 전송이 실패한 경우에는, 전송 윈도우(Transmission Window)에서 HARQ 패킷에 해당하는 패킷(RLC PDU)을 복사하여 재전송 버퍼(Retransmission Buffer)로 보내 재전송하고 종료한다(S305).

또한, 송신측의 판단 결과, 상기 패킷의 전송이 실패하지 않은 경우에는, 해당 패킷(RLC PDU)를 전송 버퍼(Transmission Buffer)에서 삭제하고, 패킷을 대기 버퍼(Waiting Buffer)로 이동시킨다(S306).

이후, 전송 용량을 확보하기 위해서 VT(MS)를 갱신하게 되며, 이와 같은 갱신 방법을 보다 상세하게 살펴보면 다음과 같다.

송신측은 ACK에 대한 패킷(RLC PDU)의 일련 번호(SN)가 VT(A)값과 동일한지의 여부를 판단한다(S307).

송신측의 판단 결과, ACK에 대한 RLC PDU의 일련 번호(SN)가 VT(A)값과 동일하지 않은 경우에는, w_reordering 변수가 true 값을 가지고 있는지의 여부를 판단하고(S309), 상기 판단 결과 w_reordering 변수가 true 값을 가지고 있지 않은 경우, 상기 w_reordering 변수의 값을 true로 설정한다(S309).

이때, w_reordering 변수는 대기 윈도우의 재순서화 작업이 수행해야 하는지의 여부를 나타내는 변수로서, true 값을 가진 경우에는 재순서화를 수행해야 하며, false인 경우에는 재순서화 작업이 필요 없다.

송신측의 판단 결과, w_reordering 변수가 true 값을 가지고 있는 경우에는, VT(MS)의 값을 VT(MS) + 패킷(RLC PDU) 크기(size)로 설정하고 종료한다(S310).

송신측의 판단 결과, ACK에 대한 패킷(RLC PDU)의 일련 번호(SN)가 VT(A)값과 동일한 경우에는, VT(A) 값을 전송 윈도우(Transmission Window)에서 ACK을 수신하지 못한 가장 작은 일련 번호(SN) 값으로 설정한다.

이후, 송신측은 w_reordering 변수가 false 값을 가지고 있는지의 여부를 판단하고(S312), 상기 판단 결과, w_reordering 변수가 false 값을 가지고 있는 경우 종료하고, 상기 판단 결과 w_reordering 변수가 false 값을 가지고 있지 않은 경우, 대기 윈도우(Waiting Window)에 있는 RLC PDU들에 대한 재순서화(reordering) 작업을 수행한다(S313).

이때, 상기 재순서화(reodrdering) 작업은 모든 패킷(RLC PDU)들이 일련 번호(SN)에 따라 빠짐없이 순서대로 나열되는 것을 말한다.

송신측은 상기 재순서화가 성공하였는지의 여부를 판단하고(S314), 판단 결과 상기 재순서화가 성공적으로 이루어진 경우에는, VT(MS)의 값을 VT(A)+ 전송 윈도우의 크기(AM_Window_Size)로 설정한다(S315). 이후, w_reordering 변수의 값을 false로 설정한다(S316).

한편, 단말은 판단 결과 상기 재순서화가 성공하지 못한 경우에는, VT(MS)의 값을 VT(MS) + 패킷(RLC PDU) 크기로 설정한다(S317).

이후, 단말은 w_reordering변수의 값을 true로 설정하고 종료한다(S318).

도 4는 본 발명의 일례에 따른 상태 보고 정보 패킷(STATUS PDU)를 수신한 경우의 단말의 동작을 나타내는 흐름도이다.

송신측은 상태 보고 정보 패킷(STATUS PDU)를 수신하고(S410),

패킷(RLC PDU)에 대한 NACK이 존재하는지의 여부를 판단하여, 패킷(RLC PDU)에 대한 NACK이 존재하지 않는 경우에는, ACK이 확인된 연속된 패킷(RLC PDU)들 중에 최대 일련 번호(SN) 값보다 1만큼 큰 값으로, 대기 윈도우(Waiting Window)의 VT(CA) 값을 갱신하고 종료한다(S403).

송신측은 패킷(RLC PDU)에 대한 NACK이 존재하는지의 여부를 판단한 결과, RLC PDU에 대한 NACK이 존재하는 경우에는, NACK이 수신된 패킷(RLC PDU)들 중에 대기 윈도우(Waiting Window)에 존재하는 최소 일련 번호(SN) 값으로 대기 윈도우(Waiting Window)의 VT(CA) 값을 갱신한다(S404).

이후, 송신측은 NACK에 대한 패킷(RLC PDU)이 전송 윈도우(Transmission Window)에 존재하는지의 여부를 판단한다(S405).

송신측은 상기 판단 결과, NACK에 대한 패킷(RLC PDU)이 전송 윈도우(Transmission Window)에 존재하는 경우에는, RLC 계층 ARQ 재전송을 수행하지 않고 종료한다(S406).

송신측은 상기 판단 결과, NACK이 수신된 패킷(RLC PDU)들 중에 전송 윈도우(Waiting Window)에 존재하지 않는 경우에는, NACK을 수신한 패킷(RLC PDU)가 대기 윈도우(Waiting Window)에 존재하는지의 여부를 판단한다(S407).

송신측은 상기 판단 결과, NACK을 수신한 패킷(RLC PDU)가 대기 윈도우(Waiting Window)에 존재하지 않는 경우에는, RLC 계층 ARQ 재전송을 수행하지 않고 종료한다.

또한, 상기 판단 결과, NACK을 수신한 패킷(RLC PDU)가 대기 윈도우(Waiting Window)에 존재하는 경우에는, 재전송 버퍼(Retransmission Buffer)에 해당 패킷(RLC PDU)가 존재하는지의 여부를 판단하고(S408), 상기 판단 결과 재전송 버퍼(Retransmission Buffer)에 해당 패킷(RLC PDU)가 존재하는 경우에는 RLC 계층 ARQ 재전송을 수행하지 않고 종료한다.

한편, 단말의 상기 판단 결과, 재전송 버퍼(Retransmission Buffer)에 해당 패킷(RLC PDU)가 존재하지 않는 경우에는, ARQ 재전송을 수행한다(S409).

도 5는 본 발명의 일례에 따른 ARQ와 HARQ 지원 방법을 설명하기 위한 도면이다.

종래에는 오류 정정을 위하여 재전송하는 방법으로서, RLC(Radio Link Control)계층인 2계층에서 ARQ(Automatic Repeat Request)를 수행하였다.

본 발명의 일례에 따르면, ARQ와 HARQ 지원 방법을 함께 사용한다.

즉, ARQ(510)를 수행하는 RLC 계층(2계층)에서 패킷을 전송하기 위하여, HARQ(Hybrid Automatic Repeat Request: 520)를 관리하는 1계층인 MAC(Media Access Control)계층으로 패킷을 전송하고, MAC 계층에서 물리계층을 통하여 패킷이 전달된다.

상기 물리계층의 전송 성공 또는 실패 여부는, HARQ 피드백(521)을 통하여 MAC 계층이 알게 되고, 실패의 경우에는 MAC 계층에서 재전송을 명령하여 수행한다.

또한, HARQ(520)에서 정의한 최대 재전송 횟수만큼 전송 후에도, 전송이 실패한 경우에는 MAC 계층은 더 이상 전송을 시도하기 않고, 해당 패킷을 버퍼에서 삭제한다.

이때, RLC 계층에서는 HARQ 전송실패에 대한 내부 피드백 또는 ARQ 피드백(STATUS PDU: 상태정보 패킷)(511)을 통하여 전송 명령한 패킷이 아직 전송되지 않았음을 알게 되면, RLC 계층에서의 재전송 명령을 하고, MAC 계층은 새롭게 HARQ(520)를 통하여 패킷을 전송한다.

도 6은 본 발명의 일례에 따른 ARQ와 HARQ 지원 방법을 설명하기 위한 흐름도이다.

본 발명의 일례에 따르면, 도 5에 도시된 바와 같이 HARQ의 피드백 정보(610)를 활용하여 새로운 패킷(RLC PDU: 620)을 전송할 수 있다.

또한, HARQ 재전송과 ARQ 재전송이 중복하여 발생하는 것을 방지할 수 있으며, 종래의 HARQ와 ARQ 두 단계의 오류정정의 의미를 훼손하지 않는 장점이 있다.

그뿐만 아니라, HARQ의 피드백 후에 대기 윈도우(Waiting Window)에서 RLC 레벨의 피드백에 대하여 다시 대기하고 있기 때문에, HARQ의 피드백의 NACK가 ACK로 잘못 인식되는 오류(NACK to ACK 오류)에 대한 대응도 할 수 있다.

이상과 같이 본 발명은 비록 한정된 실시예와 도면에 의해 설명되었으나, 본 발명은 상기의 실시예에 한정되는 것은 아니며, 본 발명이 속하는 분야에서 통상의 지식을 가진 자라면 이러한 기재로부터 다양한 수정 및 변형이 가능하다.

그러므로, 본 발명의 범위는 설명된 실시예에 국한되어 정해져서는 아니되며, 후술하는 특허청구범위뿐 아니라 이 특허청구범위와 균등한 것들에 의해 정해져야 한다.

도 1은 본 발명의 일례에 따른 윈도우를 설명하기 위한 도면이다.

<도면의 주요 부분에 대한 부호의 설명>

110: 대기 윈도우 120: 전송 윈도우

210: 전송 버퍼 220: 대기 버퍼

230: 상태 보고 정보 패킷 240: 재전송 버퍼

Claims

패킷 전송에 대응하여 수신되는 제1피드백 정보를 이용하여, 제1계층부가 상기 패킷 전송에 대한 성공 또는 실패 여부를 판단하는 단계;

상기 패킷의 전송을 성공한 것으로 상기 제1계층부가 판단한 경우, 제2계층부가 상기 패킷을 전송윈도우로부터 대기윈도우측으로 전달하는 단계;

상기 패킷의 전송을 실패한 것으로 상기 제1계층부가 판단한 경우, 제2계층부에서 실패한 것으로 판단되는 상기 패킷을 전송 윈도우로부터 재전송 윈도우 측으로 전달하여, 상기 패킷을 재전송하는 단계; 및

상기 패킷의 정보를 포함하는 제2피드백 정보를 제2계층부가 수신하고, 상기 제2피드백 정보에 기초하여 상기 패킷의 처리를 결정하는 단계

를 포함하고,

상기 패킷의 정보를 포함하는 제2피드백 정보를 제2계층부가 수신하고, 상기 제2피드백 정보에 기초하여 상기 패킷의 처리를 결정하는 단계는,

상기 제2피드백 정보를 분석한 결과, 상기 패킷의 전송이 성공한 경우, 대기 윈도우에서 해당 패킷을 삭제하는 단계;

상기 제2피드백 정보를 분석한 결과, 상기 패킷의 전송이 실패하고 상기 패킷이 상기 전송 윈도우에 존재하는 것으로 확인 된 경우, 제1계층부가 상기 패킷의 재전송을 수행하고 있는 경우는 재전송을 실행하지 않는 단계; 및

상기 제2피드백 정보를 분석한 결과, 상기 패킷의 전송이 실패하고 상기 패킷이 상기 전송 윈도우에 존재하는 것으로 확인 된 경우, 제1계층부가 상기 패킷의 재전송을 수행하고 있지 않은 경우는 재전송을 실행하는 단계를 포함하는 것을 특징으로 하는 왕복 지연시간이 긴 시스템에서의 ARQ와 HARQ의 상호작용 방법.
제1항에 있어서,

상기 패킷의 전송을 성공한 것으로 상기 제1계층부가 판단한 경우, 제2계층부가 상기 패킷을 전송윈도우로부터 대기 윈도우측으로 전달하는 단계는,

제1계층부의 피드백 정보를 활용하여, 제2계층부가 추가적인 전송을 하기 위해 상기 전송윈도우의 크기를 조절하는 단계

를 더 포함하는 것을 특징으로 하는 왕복지연시간이 긴 시스템에서의 ARQ와 HARQ의 상호작용 방법.
제2항에 있어서,

상기 제1계층부의 피드백 정보를 활용하여, 제2계층부가 추가적인 전송을 하기 위해 상기 전송윈도우의 크기를 조절하는 단계는,

상기 패킷의 패킷 번호가 이번에 수신해야 할 패킷 번호와 동일하지 않은 경우, 추가적인 패킷 전송을 위하여 제2계층부의 전송윈도우와 관련된 최대 전송 상태 변수(Maximum send state variable)를 패킷의 크기만큼 증가시키는 단계;

상기 패킷의 패킷 번호가 새로 수신해야 할 패킷 번호와 동일하고 대기 윈도우의 재순서화 작업이 필요한지의 여부를 판단하여, 재순서화 작업을 수행하는 단계; 및

재순서화 작업이 성공적으로 완료된 경우에는, 상기 최대 전송 상태 변수를 기본값으로 환원하고, 재순서화 작업이 성공적으로 완료되지 않은 경우에는, 상기 최대 전송 상태 변수를 패킷의 크기만큼 증가시키는 단계

를 포함하는 것을 특징으로 하는 왕복지연시간이 긴 시스템에서의 ARQ와 HARQ의 상호작용 방법.
제1항에 있어서,

상기 패킷의 전송 실패를, 전송 성공으로 인식하는 오류가 발생한 경우, 상기 패킷을 재전송하는 단계

를 더 포함하는 것을 특징으로 하는 왕복 지연시간이 긴 시스템에서의 ARQ와 HARQ의 상호작용 방법.
제4항에 있어서,

상기 패킷의 전송 실패를, 전송 성공으로 인식하는 오류가 발생한 경우, 상기 패킷을 재전송하는 단계는,

NACK가 ACK로 인식되는 오류가 발생한 경우, 상기 패킷의 재전송에 관한 정보를 포함하는 제1피드백 또는 제2피드백 정보를 수신하는 단계;

상기 제1피드백 또는 제2피드백 정보에 기초하여 상기 대기 윈도우가 상기 패킷을 상기 재전송 윈도우 측으로 전달하는 단계; 및

상기 재전송 윈도우가 상기 패킷을 재전송하는 단계

를 포함하는 것을 특징으로 하는 왕복 지연시간이 긴 시스템에서의 ARQ와 HARQ의 상호작용 방법.
제1항에 있어서,

상기 제1계층부는,

HARQ(Hybrid Automatic Repeat Request)를 수행하는 MAC(Media Access Control)계층인 것을 특징으로 하는 왕복 지연시간이 긴 시스템에서의 ARQ와 HARQ의 상호작용 방법.
제1항에 있어서,

상기 제2계층부는,

ARQ(Automatic Repeat Request)를 수행하는 RLC(Radio Link Control)계층인 것을 특징으로 하는 왕복 지연시간이 긴 시스템에서의 ARQ와 HARQ의 상호작용 방법.
제1항에 있어서,

상기 제1피드백 정보는,

HARQ 관련 피드백 정보인 것을 특징으로 하는 왕복 지연시간이 긴 시스템에서의 ARQ와 HARQ의 상호작용 방법.
제1항에 있어서,

상기 제2피드백 정보는,

ARQ 관련 피드백 정보인 것을 특징으로 하는 왕복 지연시간이 긴 시스템에서의 ARQ와 HARQ의 상호작용 방법.
삭제