KR101024461B1 - 전송 윈도우를 사용하는 통신 시스템에서의 최적화된 패킷 데이터 전송 프로토콜 - Google Patents

Abstract

전송 윈도우를 사용하는 패킷 데이터 전송 프로토콜은 제1 전송 윈도우로부터 데이터 패킷들의 블록들을 송신하는(100) 패킷 제어 유닛(PCU)(4, 8)을 포함한다. 유저 장치(UE)(2)는 패킷들이 적절히 수신되지 않은 경우에 PCU로 부정응답을 전송하고(102), 트리거(60) 수립(104) 이벤트 후에, PCU는 적어도 헤더 정보를 포함하여 더미 무선 링크 제어(RLC) 블록(62)을 구성한다(106). PCU는 RLC 스톨 상태를 방지하기 위해 더 강력한 코딩 레이트로 더미 RLC 블록을 전송한다(108).

통신 시스템, 데이터 전송 프로토콜, 패킷, 전송 윈도우, 재전송

Description

전송 윈도우를 사용하는 통신 시스템에서의 최적화된 패킷 데이터 전송 프로토콜{OPTIMISED PACKET DATA TRANSMISSION PROTOCOL IN A COMMUNICATION SYSTEM EMPLOYING A TRANSMISSION WINDOW}

본 발명은 패킷 데이터의 전송 및 재전송에 관한 것으로, 특히, 전송 윈도우를 사용하는 무선 통신 시스템에서의 패킷 데이터에 대한 전송 프로토콜에 관한 것이다.

디지털 통신 네트워크를 통해 데이터 패킷들의 형태로 데이터를 전송하는 것은 통상적으로 프로토콜 스택(protocol stack)으로 알려진 메커니즘을 이용하여 수행된다. 프로토콜 층들의 계층구조(hierarchy)를 이용하여 데이터 전송을 조직화하기 위해 프로토콜들이 사용되는데, 이 프로토콜 층들이 집합적으로 프로토콜 스택으로 여겨진다. 층들의 계층구조는 통상적으로 (개별 비트들이 전송되는 방식을 지시하는) 물리 계층으로부터, 예를 들면, 하이-레벨 프로그램들이 어떻게 서로 상호동작하는지를 결정하는 응용 계층까지 확장된다.

프로토콜 스택의 중간 계층의 일 예는 네트워크 내의 단일 조직 링크(single organisational link)를 통한 데이터의 전송을 제어하는 논리 링크 제어(logical link control: LLC) 계층이 있다. 예를 들면, 범용 이동 전화 표준(Universal Mobile Telephone Standard: UMTS)을 통한 셀룰러 무선 통신 시스템 내의 LLC 계층에서는, 단일 조직 링크가 무선 네트워크 제어기(Radio Network Controller: RNC)와, 대개 이동 전화와 같은 이동국(Mobile Station: MS)인 유저 장치 사이에 존재하는 반면, 물리 계층에서는 물리적 접속이, RNC로부터 중간 물리 개체, 즉, 노드-B(기지국 트랜시버에 대한 UMTS 용어) 사이의 제1 물리 링크(Iub)와, 노드-B와 MS 사이의 제2 물리 링크(Uu)에 의해 구현된다. 상기의 예에서, RNC가 링크 계층의 패킷 제어 유닛(PCU) 또는 전송단(Tx-end)으로, MS가 수신단(Rx-end)으로 이해될 수 있다. 이 프로토콜 스택에서의 계층들은 서로 독립적으로 동작할 수 있다.

LLC 링크 계층 내에서, 자동 반복 요구(Automatic Repeat Request: ARQ)라 부르는 메커니즘이, 수신단으로 하여금 데이터 패킷들이 에러없이 수신되었는지 그렇지 않은지를 주기적으로 송신단에 알려주도록 하는 데이터 전송에 대한 에러 제어 메커니즘을 제공한다. 이것은 송신단으로 하여금 이전 주기에서 잘못 전송된 패킷들을 재전송할 수 있게 한다.

수신단에 의해 송신된 메시지는 응답/부정응답(ACK/NACK)으로 알려져 있다. ACK/NACK 메시지는 이전에 전송된 패킷 데이터 유닛들(PDU), 또한, 송신단에 의해 수신단으로 전송된 데이터 패킷들 또는 블록들의 ACK/NACK 상태를 포함한다. ACK/NACK 메시지를 수신하면, 송신단은 수신단에 의해 잘못 수신되었다고 보고된(NACK) 패킷들을 재전송할 수 있으며, 이때, 통상적으로 가장 오래된 NACK PDU가 먼저 재전송된다. 이러한 시나리오에서, 실시간(RT) 서비스들을 전송하려고 시도할 때에 몇 가지 문제들이 발생한다.

엔드-투-엔드(ETE) 접속이 수립되면, 다른 것들 중에서, 예를 들면, 패킷 전송 지연, 개런티 비트 레이트, 및 우선순위와 같은 임의의 서비스 품질(QoS) 요건들이 협상된다. 통상적으로 전송 지연은 전송 제어 프로토콜(TCP) 세그먼트들과 같은 운송 계층 프로토콜 패킷들의 운반에 대해 정의된다. 네트워크가 몇몇 링크들을 가지면, 와이어리스 무선 액세스 네트워크(RAN)가 수반될 때, 지연의 특정 부분이 에어 인터페이스에 대해 별도로 설정될 수 있는 것과 같이, 지연이 각 링크에 대해 특정되도록 더욱 분할될 수 있다. 전체 ETE QoS 요건들을 만족시키기 위해, 각 링크는 그 개별적인 QoS 요건들을 만족시킬 필요가 있다.

예로, 음성 및 동영상과 같은 실시간(RT) 서비스들에 대한 전송 지연은, 낮은 지연 변화로 데이터의 연속적인 스트림을 지원하는 것이 이용가능한 서비스를 지원하는데 필수적이기 때문에, 그 서비스의 결정적인 QoS 요건들 중 하나가 된다. 통상적으로, 유저 데이터그램 프로토콜(User Datagram Protocol: UDP)과 같은 전송 프로토콜이 사용되는데, 여기서 재전송은 지원되지 않는다. 이것은 전송 계층에서 패킷들을 재전송하는데 시간이 충분하지 않고, 이에 따라 이러한 서비스들이 어느 정도의 패킷 에러 또는 손실 허용치를 가져야 하기 때문이다. 이것은 비-실시간(non-RT: NRT) 서비스들에 대해서는 적용되지 않고, 여기서는 모든 데이터가 전송되도록 요구된다. 따라서, 재전송을 지원하는 프로토콜들은 통상적으로, 예를 들면, TCP와 같은 이러한 서비스들에 대해 사용된다.

에어 인터페이스에서, 접속들은 회선 스위칭 방식(CS) 또는 패킷 스위칭 방식(PS) 접속으로 할당된다. 전용 CS 리소스를 연결하는 대신에, 공급가능한 다중 화 이득들로 인해, PS 접속을 사용하는 것이 에어 인터페이스의 사용을 보다 효과적으로 만들 수 있다. 통상적으로 더 높은 지연 변화를 허용할 수 있는 웹 브라우징 또는 FTP 파일 전송과 같은 NRT 서비스들은 PS 베어러들에 맵핑된다. 그러나, 예를 들면, VoIP(voice over IP), PoC(push to talk over cellular), 및 심지어 동영상과 같이 더 많은 RT 서비스들을 PS 베어러들에 맵핑시키는 드라이브가 있다. 따라서, PS 도메인에서 QoS 보장을 지원할 필요가 있다.

무선 네트워크들은 그 유선 상대들에 비해 훨씬 더 높은 에러율을 가지는 경향이 있다. 사실상, 유선 네트워크에서의 손실은 대개 실제 디코딩 에러라기 보다는 그 노드에서의 버퍼 오버플로우, 즉, 정체현상(congestion)에 기인한다. 그 결과는, 에어 인터페이스를 통해 더 높은 계층 패킷들을 전송하는데 사용되는 PS 도메인 내의 무선 링크 제어(RLC) 프로토콜이 유저 측면에서 승인 모드(acknowldeged mode: AM)로 대개 실행되는 것이다. 재전송은 QoS 지연 예산이 초과되지 않는 한 허용될 수 있다.

먼저, 이러한 쟁점들이, 예를 들면, 무선 링크 제어(RLC) 및 TCP와 같은 전송 윈도우를 사용하는 어떠한 전송 프로토콜에도 적용될 수 있다는 점을 알아야 한다. GPRS에 대한 적용은, RT 및 NRT 서비스들에 대한 개별 RLC 접속을 위한 이동기기들에서의 현재의 지원 부족과, 이에 따른 하나의 TBF(Temporary Block Flow) 하에서 양쪽 모두를 지원할 필요성으로 인해 특히 관련이 있다. 앞서 언급한 바와 같이, 통상의 절차는 재전송이 지원되지 않는 프로토콜들 하에서 RT 서비스들을 지원하는 것이지만, 이동기의 배터리 전력이 유지될 필요가 있는 상황들 하에서, 다 수의 TBF의 유지보수는 불충분하게 여겨질 수 있다. 이러한 상황에서, RT 및 NRT 모두는 NRT 트래픽에 의해 예상되는 신뢰도를 유지하면서도 RT 서비스들이 그 전송 지연 보장치를 만족시킬 수 있는 프로토콜들을 이용하여 전송되어야 한다.

재전송의 하나의 문제점은 해당 응답 상태를 전송하고 수신하는 사이의 왕복 시간으로 인해 시간이 걸린다는 점이다. 만족되지 않는 QoS 요건들의 가능성을 줄이도록 구현된 메커니즘들을 이용하더라도, 재전송율이 너무 높을 수 있는 가능성이 언제나 존재할 것이다. 또한, 전송 윈도우의 제한된 크기로 인해, 현재 패킷 뒤에 더 높은 계층의 패킷들은, 현재 패킷이 전송 윈도우로부터 처리될 때까지 대기하게 될 것이다. 이것은 특히 3GPP 규격들은 본래 코딩 스킴으로만 RLC 블록들의 재전송을 허용하는 사실 - 채널 컨디션이 악화되면 재전송에서 겪는 에러율이 본래의 전송의 경우보다 훨씬 더 높을 수 있다는 것을 의미함 - 로 인해, GPRS 네트워크들에서 특히 문제가 된다(보다 강한 코딩 스킴들로 RLC 블록들을 재전송하는 것은 더 많은 RLC 블록들이 전송되도록 요구하며, 이것은 윈도우 크기를 초과하지 않기 때문에 이동기에서 RLC 개체에 의해 인식되지 않을 수 있음). 3GPP GPRS 규격은 수신 개체가 송신 개체에게 스톨(stall)을 겪고 있다는 것을 지시하기 위한 메커니즘을 제공하는 것(지시 비트가 응답 헤더에 제공됨) 이외에, 전송 윈도우를 전진시키기 위한 방법을 제공하지 않는다. 그러나, 그 정보가 획득되기 전에 전송 윈도우가 이미 정지될 가능성이 많다. 송신 개체가 할 수 있는 것은 부정응답된 블록들을 재전송하거나 응답이 수신되지 않은 블록들을 재전송하는 것이다.

재전송에 따른 다른 문제는, 현재 윈도우 내의 가장 오래된 블록이 응답되어 야만, 다음 전송 윈도우에서 새로운 데이터 블록들이 전송될 수 있다는 점이다. 그러므로, 이 블록이 응답되지 않으면 어떤 새로운 블록들도 전송될 수 없는 지점에 도달하는데, 이것은 새로운 블록들이 전송 윈도우 밖에 있기 때문이다. 이것은 정지 상태(stall condition)로 언급된다. 그 결과 모든 버퍼링된 블록들이 (큐를 점프할 수 없기 때문에) 대기되며, 이에 따라, 큐잉 지연이 길어지는 것을 겪게 될 것이다. 이것은 또한 더 높은 계층 패킷들 뿐만 아니라 전체 세션에 대한 패킷들의 QoS TD 요건들이 손상될 가능성을 증가시킨다.

더욱이, RT 및 NRT 세션들이 동일한 에어 인터페이스 접속을 통해 다중화되는 상황에서, RT LLC 프레임이 RLC에서 NRT LLC 프레임 뒤에 큐잉되어지는 것이 가능하다. 현재, RT 세션에 대한 QoS 개런티를 만족시키기 위한 가능성을 증가시키기 위해 NRT LLC 전송을 조속히 종료시키는 방법은 알려져 있지 않다.

그러므로, 본 발명의 분야에서 전송 윈도우를 사용하는 전송 프로토콜의 단점들을 해결하고, 그것으로 QoS 개런티를 만족시킬 가능성을 증가시키기 위한 요구가 존재한다.

따라서, 본 발명은 전술한 단점들의 하나 또는 그 이상을 단독 또는 어떠한 조합으로 바람직하게 완화시키거나 제거하기 위한 것이다.

제1 양태로, 본 발명은 청구항 제1항에서 청구한 것과 같은 패킷 데이터 전송 프로토콜을 위한 방법을 제공한다.

제2 양태로, 본 발명은 청구항 제8항에서 청구한 것과 같은 패킷 데이터 전송 프로토콜을 위한 장치를 제공한다.

제3 양태로, 본 발명은 청구항 제15항에 청구한 것과 같은 패킷 데이터 전송 프로토콜을 위한 시스템을 제공한다.

제4 양태로, 본 발명은 청구항 제23항에 청구한 것과 같은 저장 매체를 제공한다.

다른 양태들은 종속 청구항들에서 청구한 것과 같다.

본 발명에 따르면, 스톨 상태를 방지하기 위해, 적어도 헤더 정보를 포함하는 더미 RLC 블록이, 데이터의 새로운 블록들을 수락하는 유저 장치의 기회를 향상시키기 위해 보다 낮은 코딩 레이트로 재전송되는 블록으로서 전송된다. LLC 계층이 그 블록을 부당하게 지연시키더라도, 이것은 LLC 계층이 대안적인 복구 수단을 가지기 때문에 스톨 상태보다는 더 낫다.

본 발명의 실시예들이 이제 첨부된 도면들을 참조하여 예시적으로 설명될 것이다.

도 1은 셀룰러 통신 시스템에서 종래 기술에 따라 수행되는 데이터 패킷들의 전송 및 재전송의 개략도.

도 2는 본 발명의 일실시예에서 프로토콜 스택의 프로토콜 계층들의 개략도.

도 3은 본 발명에 따른 프로토콜의 개략도.

도 4는 본 발명의 일실시예에서 사용되는 프로세스 단계들을 도시한 순서도.

다음의 상세한 설명은 GPRS를 이용하여 실시간 서비스를 제공하는 셀룰러 통신 시스템에 적용가능한 본 발명의 실시예들에 초점을 둔다. 그러나, 본 발명은 이러한 적용예로 제한되는 것이 아니라, 전송 지연에 의해 부정적인 영향을 받을 수 있는 서비스들을 이용하는 많은 다른 셀룰러 통신 시스템들에도 적용될 수 있다는 것이 이해될 것이다.

일반적으로, 본 발명은 범용 이동 전화 표준(UMTS)을 따르는 셀룰러 통신 시스템에 적용될 수 있다. 본 실시예를 이해하는데 도움이 되는 이러한 통신 시스템(1)의 부분들이 예를 들어 도1에 개략적으로 도시되어 있다. 최종 사용자에 의해 사용되는 이동국(MS: 2)과 같은 유저 장치가 UMTS-규격의 Uu 인터페이스를 통해 동작하는 무선 링크(6)를 통해, UMTS에서는 노드-B(4)로 알려진 기지국 트랜시버와 결합된다. 노드-B(4)는 UMTS-규격의 Iub 인터페이스를 통해 동작하는 물리 링크(예로, 랜드라인)(10)를 통해 무선 네트워크 제어기(RNC: 8)에 결합된다. RNC(8)는 UMTS-규격의 Iu 인터페이스를 통해 동작하는 물리 링크(예로, 랜드라인)(14)를 통해 인터넷과 같은 코어 네트워크(12)에 결합된다.

본 실시예는 RNC(8)와 같은 패킷 제어 유닛(PCU)으로부터 MS(2)로 전송되는 데이터 패킷들에 관련되고, PCU가 고려중인 LLC 계층의 송신단을 대표하는 것과 같이, MS(2)는 링크 계층(예를 들어 도 2 참조)의 수신단을 대표한다. RNC(8)로부터 MS(2)로의 해당 물리 계층은 MS(2)와 노드-B(4)에서 구현되고, 여기서 노드-B는 MS(2)와 RNC(8)간의 물리 계층의 중간 물리적 엔티티를 형성한다.

송신단 링크 계층을 구현하는 RNC(8)는 랜드라인(10)에 의해 물리 계층의 송 신단을 구현하는 노드-B(4)에 접속된다. 따라서 도 1은 데이터 패킷들(16)의 본래, 즉 신규 블록들이 RNC(8)로부터 MS(2)로 전송되는 것을 개략적으로 보여준다.

각각의 데이터 패킷에 대해, MS(2)는 ACK/NACK 메시지(18), 즉, 응답(적절한 수신의 경우) 또는 부정응답(부적절한 수신의 경우)을 다시 전송한다. 무선 링크 제어(RLC) 계층 프로토콜 안에서 링크 계층만을 체계적으로 사용함으로써 ARQ 메커니즘은 RNC(8) 또는 대안적으로 노드-B(4)로부터 동작될 수 있다. RNC 또는 노드-B는 부정응답된 데이터 패킷들(20)이 MS(2)로 재전송될 수 있도록, 물리 계층에 의한 수신 후에, 주어진 제한 시간 주기 동안 캐시 내에 패킷들을 저장한다.

도 2는 본 발명에 따라 패킷 데이터 블록들의 전송을 수행하도록 적응된 (도 4의 시스템에 대한) 프로토콜 스택 배열(28)을 보여준다. 프로토콜 스택의 수신단(30)(MS(2)에 대응됨)은 링크 계층(32) 및 물리 계층(34)을 포함한다. 송신단 물리 계층은 중간 물리 개체, 즉, 노드-B(4)에서 구현되며, 이것은 도 2에 도시된 바와 같이, 추가의 물리 계층 부분(46)을 프로토콜 스택에 부가한다. 본 실시예에서, 부가적으로 물리 계층과 연관된 송신단 링크 계층 캐시(42)가 있으며, 이것은 노드-B 또는 RNC(도시됨)에 위치할 수 있다.

상기의 배열을 구현하고, 후술될 방법 단계들을 수행하기 위한 장치는 기존의 장치를 개조하거나 및/또는 부가의 모듈들을 제공함으로써 제공된다. 특히, 추가 장치는 중간 물리 개체, 즉, 노드-B(4)에 제공될 수 있다. 장치는 하드웨어, 펌웨어, 소프트웨어, 또는 이들의 조합의 형태로 이루어질 수 있다. 장치는 명령어들을 구현하고, 컴퓨터 디스크 또는 PROM과 같은 저장 매체에 저장된 데이터를 이용하기 위한 하나 또는 그 이상의 프로세서들을 포함할 수 있다.

도 3은 본 실시예에 따라 동작하도록 적응된 통신 시스템 및 장치를 개략적으로 도시한다. 앞에서와 같이, 본래의, 즉 신규 데이터 패킷들(16)이 패킷 제어 유닛(PCU) 송신 개체(예로, 노드-B(4) 또는 RNC(8))로부터 유저 장치(UE) MS(2)로 전송된다. 또한 이전과 같이, 각 데이터 패킷에 대해, MS(2)는 ACK/NACK 메시지(18), 즉, 응답(적절한 수신의 경우) 또는 부정응답(부적절한 수신의 경우)을 PCU로 전송한다. 그러나, 도 1에서의 절차와는 달리, 본 발명은, 트리거 이벤트(60)시에, 적어도 헤더 ID와 함께 더미 데이터 패킷(즉, RLC) 블록(62)을 전송한다.

본 발명에 따르면, 임의의 트리거 조건들이 만족될 때, (예로, 노드-B 또는 RNC를 포함하는 패킷 제어 유닛(PCU) 내의) 송신 개체가 (최소한) 해당 헤더 정보만을 포함한 더미 블록으로 재전송이 필요한 오류 블록들을 대체한다. GRPS의 경우에, 더미 블록은 보다 강력한(즉, 보다 낮은), 바람직하게는 가장 강력한 코딩 스킴으로 인코딩된다. TCP의 경우에는, 페이로드(payload)를 최소한으로 줄이도록 제안된다. 어느 경우든, 그 결과는 다음 전송 윈도우로 전진이 되어, (반응적으로) 스톨 상태를 제거하거나 (미리) 스톨의 가능성을 줄일 수 있다.

TCP 경우에, 보다 짧은 패킷의 전송 지연 시간이 더 낮을 것이기 때문에 이것이 달성된다. GPRS에 있어서는, 보다 강력한 코딩 스킴이 더 높은 성공적 전송 가능성을 가지기 때문에 이것이 달성된다. 본 발명은 RT, NRT 또는 두 세션 타입의 조합이 전송되든지에 관계없이, 어떠한 GPRS TBF에도 적용 가능하다. 더미 블 록 내의 "의미없는" 정보는, 더 높은 계층 PDU(GPRS의 경우에는 LLC 프레임)를 재구성할 때, 더 높은 LLC 계층들로 전달될 것이다.

실제로, PDU는 최소한 적어도 적절한 헤더 ID와 함께 더 낮은 코딩 레이트로 더미 RLC 블록을 전송할 것이다. 이것은 보다 낮은 코딩 레이트가 그 낮은 코딩 레이트에서 타이밍 윈도우에 수용되지 않을 수 있는 더 큰 코드 길이를 생성하기 때문이다. 그러므로, 헤더만이 전송될 수 있다(다른 데이터는 그 데이터가 RLC 타이밍과 맞을 것이라는 것을 알고 있는 한 전송될 수 있음). 이 더미 블록을 수신하면, MS는 새로운 RLC 블록들을 수락하기 위해, 새롭고 보다 강력한 코딩 스킴으로 전환한다는 것을 알 것이다. 더미 블록은 MS의 LLC 계층으로 전달되는데, 여기서 그 블록이 무효하다는 것을 판단하고, 그 블록을 폐기할 것이다. 다행히, LLC 계층(도 2의 32)은 물리 계층(도 2의 34)과는 별도로 동작하며, 물리 계층들은 새로운 레이트로 새로운 블록들의 다운로드로 진행함으로써, RLC 스톨을 방지할 수 있다.

본 설명의 나머지는 GPRS 시스템에 기반하지만, 기본 원리들은 모든 무손실 전송 프로토콜에 적용될 수 있다.

GPRS에 있어서, 더미 블록은 동일한 RLC 블록 ID를 이용하여 구성되어, 블록이 에러없이 수신된 경우(이것은 보다 강력한 코딩 스킴이 사용되기 때문에 매우 가능성이 있음), 그 수신 개체가 RLC 계층에서 실제 정보 블록이 올바르게 수신되었다고 믿도록 효과적으로 속이게 된다. 추가로, 더미 RLC 블록은, 길이 지시자(Length Indicator) 필드가 전송될 더미 블록의 코딩 스킴에 대해 예정된 (나머 지) LLC PDU를 포함하는 RLC 데이터 필드의 길이를 정확하게 지시하도록 구성될 수 있다. 대안적으로, LLC PDU가 RLC 블록에 의해 불완전하게 송신된 것을 지시하기 위해 길이 지시자가 0으로 설정될 수 있다. 다른 실시예는 더 강력한 코딩 스킴으로 본래 RLC 블록 정보를 인코딩하여, 새로운 RLC 블록에 불충분한 공간이 존재하는 경우에 LLC PDU를 자를 수 있도록 할 수 있다(이것은 하나 이상의 LLC 프레임으로부터의 정보가 RLC 블록 내에 포함될 때에 특히 유리하며, 이후에는 단지 하나의 LLC 프레임만이 영향을 받을 것이다).

더미 블록 내에 포함된 정보를 이용한 LLC PDU의 재구성은 다음의 3GPP TS 44.064, 5.8 조항에 명시된 기준에 따라 무효 LLC 프레임이 될 것이다.

1. LLC 프레임은 어드레스 필드, 제어 필드, 정보 필드, 및 정보 필드의 컨텐츠에 따라 완전한 프레임을 구성하는데 필요한 프레임 체크 시퀀스(Frame Check Sequence: FCS)를 포함하는데 필요한 것보다 적은 옥텟(octets)을 포함한다.

2. LLC 프레임은 FCS 에러를 포함한다.

무효 LLC 프레임들은 송신자에게 통지하지 않고 폐기된다. 그 프레임의 결과로 더 이상의 동작이 행해지지 않는다.

RLC PDU를 실제로 폐기하고 그에 따라 전송되는 LLC 프레임을 오염시켜 LLC 프레임의 폐기를 초래하는 것은 전체 세션의 QoS TD 요건들을 손상시키는 것보다 낫다. RT는 임의의 에러 레이트를 견딜 수 있으며, 사실상 서비스 데이터 유닛(SDU) 에러율은 또한 PFC(Packet Flow Context)에 대한 QoS 개런티들의 일부로서 협상된다. 또한, NRT 서비스들은 (재전송을 통한) 이러한 에러들을 복구하기 위 해, 일반적으로 TCP와 같은 보다 높은 계층의 전송 프로토콜을 사용한다.

본 발명에 따르면, 더미 RLC 블록의 전송을 유발할 수 있는 많은 조건들이 있다. 그 예들은 다음을 포함하지만 그것으로 제한되지는 않는다.

1) 후속 윈도우 내의 RLC 블록들에 대한 코딩 스킴이 현재 윈도우 내의 RLC 블록들에 사용되는 코딩 스킴보다 더 낮을 경우.

2) 제1 재전송이 요구될 때 설정되고, 패킷 폴링 요구(Packet Polling Request)가 RLC 블록에 대한 더 이상의 요구들을 받지 않을 때에 재설정되는 타이머에 의해 결정된 소정 주기의 시간보다 더 오래 RLC 윈도우 스톨이 발생된 경우. 타이머가 만료된 후 더미 RLC 블록이 전송될 것이다.

3) 스톨 상태가 종료된 것으로 판단된 경우. 예를 들어, 패킷들을 폐기하는 정상 동작 절차로 인해 전송 윈도우 내의 새로운 블록들의 수가 임의의 수/전체 크기의 임의 퍼센트 이하로 줄어든 경우.

4) RT LLC 프레임의 전송이 NRT LLC 프레임 뒤에 큐잉된 경우. 이후 이 방법은 그 프레임을 RLC 윈도우에서 소거하기 위해 NRT LLC 프레임의 RLC 재전송에 채택될 수 있다.

5) 현재 RT LLC 프레임의 TD 요건들이 만족될 수 없다고 예상된 경우, 잘못된 재전송을 통한 또 다른 지연을 초래하는 포인트가 없고, 이에 따라 재전송이 그 LLC 프레임을 소거하기 위해 가장 강력한 코딩 스킴으로 제한될 수 있다. 이것은 그 TD 요건들을 만족시키지 않는 이후의 RT LLC 프레임의 가능성을 줄일 수 있다.

하나의 특정한 구현예에서, 이들 옵션들과 다른 오션들이 인에이블되거나 디 스에이블될 수 있다.

이 기술의 가능한 부작용은 인지(perceived) BLER에 대한 것이다. 왜냐하면 보다 강력한 코딩 스킴으로의 블록 전송의 결과로 에러 레이트가 향상된 것으로 보여질 수 있기 때문이다. 이 문제는 BLER 예상치가 대개 링크 적응(코딩 스킴 선택) 알고리즘의 일부로서 사용되고, 이에 따라 낙관적인 BLER 예상치가 링크 적응 알고리즘으로 하여금 선택된 코딩 스킴을 잘못 증가시키도록 야기할 수 있다는 것이다. 그러나, 이것은 GPRS에서 수신 개체가 요구시 BLER 비트맵 보고를 제공하도록 함으로써 극복될 수 있다. 송신 개체는 어떤 블록들이 더 낮은 코딩 스킴으로 강하되었는지를 알기 때문에, 이것들은 BLER 통계로부터 배제될 수 있다.

도 4의 순서도를 참고하면, 본 발명은, 전송 지연 또는 전송 윈도우의 스톨링에 대한 근사와 같은 파라미터들에 대한 측정을 통해 보다 높은 계층 패킷들의 QoS 타겟들 또는 데이터 전송이 전체적으로 위험 상황인 것으로 여겨질 때, (무손실 전송 프로토콜들에 대해 전송 윈도우 전진을 가능하게 하기 위해) 송신 블록 재전송에 대해 (최소한으로) 헤더 정보만이 재전송되는 방법을 제공한다.

첫 번째 단계(100)는 이 기술분야에서 주지된 바와 같이 제1 전송 윈도우로부터 데이터 패킷 블록들을 송신하는 것을 포함한다.

다음 단계(102)는 송신된 데이터 패킷들에 대해 적어도 하나의 부정응답(NACK)을 수신하는 것을 포함한다. NACK는 그 전송 윈도우에 대한 현재 또는 임박한 스톨 상태를 나타낸다.

다음 단계(104)는 프로토콜에 대한 트리거를 수립하는 것을 포함하는데, 여 기서 다음의 단계들은 트리거 이벤트의 경우에만 발생한다. 이 단계는 본 방법에서 어느 곳에서든 발생할 수 있다. 트리거 이벤트 자체는 위에서 설명되었다. 어떠한 트리거 이벤트도 발생하지 않은 경우(105), 이 기술분야에서 알려진 바와 같이, 프로세스는 블록들의 재전송으로 계속된다(103).

트리거 이벤트(105)시, 다음 단계(106)는 적어도 하나의 헤더 ID를 포함하는 더미 데이터 패킷(즉, 무선 링크 제어(RLC)) 블록을 구성하는 것을 포함한다.

다음 단계(108)는 본래의 데이터 패킷 송신에 사용되는 것보다 더 강력한 코딩 레이트로 더미 RLC 블록을 전송하는 것을 포함한다.

다음 단계(110)는 더미 RLC 블록에 대한 응답을 수신하는 것을 포함하는데, 여기서, 유저 장치는 새로운 코딩 레이트로 패킷들을 수락하도록 재구성된다.

다음 단계(112)는 후속 전송 윈도우로부터 새로운 코딩 레이트로 데이터 패킷들의 새로운 블록들을 송신하는 것을 포함하며, 이로써, 전술한 바와 같이, RLC 블록들에 대한 스톨 상태를 방지할 수 있다.

본 발명을 고려하면, GPRS 시스템에 추가로, 무손실 전송 프로토콜들을 채용한 전송 윈도우를 사용하는 다른 와이어리스 네트워크들도 여기에 기술한 기술들로부터 이익을 얻을 수 있다는 것을 알 수 있다. 이러한 프로토콜들은 RLC 및 TCP를 포함한다.

본 발명은 다음과 같은 장점들을 제공한다.

(i) GPRS에 대해, 본 발명은 재전송될 RLC 블록의 ID를 모방한 보다 강력한 코딩 스킴으로 RLC 블록을 전송함으로써 무한한 RLC 스톨 문제를 극복하기 위해 LLC 프레임의 폐기를 가능하게 한다. 현재, 이것을 달성하기 위한 GPRS 규격 내의 주지된 방법은 존재하지 않는다.

(ii) 본 발명 이전에, GPRS RLC 블록 재전송은 동일한 코딩 스킴 및 에러 방지책으로 이루어져야 했다. 이것은 특히 무선 링크 상태가 본래 전송과 재전송 사이의 시간 주기 내에 악화되었을 때 RLC 윈도우 스톨을 야기하였다. 이것은 무선 상태가 악화되었을 때 대개 재전송이 정확히 발생되기 때문에 매우 자주 발생할 수 있었고, 무선 상태가 좋지 않은 동안에, 재전송이 성공할 확률은 낮다.

(iii) TCP에 대해 유사하게, 모든 패킷에서 TCP 엔드-포인트가 현재 가용한 윈도우 공간의 양을 광고하는 경우에, 그 시스템으로 이미 전송된 미응답 데이터를 뺀 윈도우 크기가 0인 경우에 데이터가 전송될 수 없다.

(iv) 본 발명 이전에는, 윈도우가 가득 찬 후에 전송될 후속 패킷을 위해 시간 안에 패킷이 그 링크를 건너고 그 응답이 송신 및 수신되기에는 TCP 윈도우 크기가 너무 작을 때에 TCP 재전송이 스톨링되었다. 이 왕복 시간(RTT)은 TCP 패킷 크기 뿐만 아니라 패킷이 건너야할 홉(hop)의 수 (및 각 홉에서의 큐 지연)에 영향을 받는다. 따라서 TCP 패킷 크기를 줄이면 RTT를 감소시킬 수 있고, 이것은 더 많은 패킷들이 주어진 윈도우 크기 동안에 전송되도록 할 수 있다.

명료성을 위해 상기의 상세한 설명은 상이한 기능 유닛들과 프로세서들에 대해 본 발명의 실시예들을 설명하였다는 것을 알 수 있다. 그러나, 본 발명의 범위에서 벗어나지 않는 한, 상이한 기능 유닛들 또는 프로세서들 사이에 어떠한 알맞은 기능의 분배가 이루어질 수 있다는 것이 명백할 것이다. 예를 들면, 개별 프로 세서들 또는 제어기들에 의해 수행되도록 도시된 기능들이 동일한 프로세서 또는 제어기에 의해 수행될 수 있다. 따라서, 특정 기능 유닛들에 대한 언급은 제한된 논리적 또는 물리적 구조 또는 조직을 나타낸다기 보다는 설명한 기능을 제공하기 위한 적절한 수단에 대한 언급으로 이해되어야만 한다.

본 발명은 하드웨어, 소프트웨어, 펌웨어 또는 이들의 조합을 포함한 적절한 형태로 구현될 수 있다. 본 발명은 선택적으로 하나 또는 그 이상의 데이터 프로세서들 및/또는 디지털 신호 프로세서들 상에서 실행되는 컴퓨터 소프트웨어로 적어도 부분적으로 구현될 수 있다. 본 발명의 일실시예의 구성요소 및 성분들은 어떠한 적절한 방식으로 물리적, 기능적 및 논리적으로 구현될 수 있다. 실제로 기능은 단일 유닛, 다수의 유닛들 또는 다른 기능 유닛들의 일부로서 구현될 수 있다. 이와 같이, 본 발명은 단일 유닛에서 구현되거나 상이한 유닛들 및 프로세서들 사이에 물리적 및 기능적으로 분배될 수 있다.

본 발명이 일부 실시예들과 관련하여 설명되었지만, 이것은 여기에 제시된 특정 형태로 제한되도록 의도한 것은 아니다. 오히려, 본 발명의 범위는 첨부한 청구범위에 의해서만 제한된다. 부가적으로, 어떠한 특징이 특정 실시예들과 관련하여 설명된 것으로 보여질 수 있지만, 이 기술분야에서 통상의 지식을 가진 자는 전술한 실시예들의 다양한 특징들이 본 발명에 따라 조합될 수 있다는 것을 이해할 것이다. 청구범위에서, "포함한다"는 용어는 다른 구성요소나 단계들의 존재를 배제하지 않는다.

또한, 개별적으로 열거되었더라도, 다수의 수단, 요소들 또는 방법 단계들 이, 예를 들면, 단일 유닛 또는 프로세서에 의해 구현될 수 있다. 부가적으로, 개별 특징들이 상이한 청구항들에 포함될 수 있지만, 이들은 유리하게 조합될 수 있고, 상이한 청구항들에 포함되는 것은 특징들의 조합이 실행가능하지 않거나 및/또는 유리하지 않다는 것을 의미하지 않는다. 또한, 한 카테고리의 청구항들 내에 포함된 특징은 그 카테고리로 제한되는 것을 암시하는 것이 아니라, 그 특징이 다른 청구항 카테고리에도 동일하게 적절히 적용될 수 있다는 것을 나타낸다. 또한, 청구항들 안의 특징들의 순서는 그 특징들이 수행되어야 하는 특정 순서를 의미하지 않고, 특히, 방법 청구항 내의 개별 단계들의 순서는 그 단계들이 그 순서로 수행되어야 한다는 것을 의미하지 않는다. 오히려, 단계들은 어떠한 적절한 순서로 수행될 수 있다.

Claims (10)

1. 전송 윈도우를 사용하는 패킷 데이터 전송 프로토콜을 위한 방법으로서,

   제1 전송 윈도우로부터 데이터 패킷들의 블록들을 송신하는 단계;

   상기 송신된 데이터 패킷들에 대해, 적어도 하나의 부정응답을 수신하는 단계;

   적어도 헤더 정보를 포함하는 더미 데이터 패킷 블록을 구성하는 단계;

   본래 송신된 데이터 패킷들에 사용된 것보다 더 강력한 코딩 레이트로 상기 더미 데이터 패킷 블록을 전송하는 단계;

   상기 더미 데이터 패킷 블록에 대한 응답(acknowledgement)을 수신하는 단계; 및

   후속 전송 윈도우로부터 데이터 패킷들의 새로운 블록들을 송신하는 단계

   를 포함하고,

   상기 프로토콜에 대한 트리거를 수립하는 단계를 더 포함하고,

   상기 구성 단계 및 송신 단계들은 상기 트리거의 발생시에만 발생하고,

   상기 트리거는, 상기 수신된 부정응답이 소정 기간보다 긴 기간 동안 RLC 윈도우 스톨(stall)이 발생하도록 야기한 경우의 상태, 상기 전송 윈도우 내의 새로운 블록들의 수가 임박한(impending) 스톨 상태를 나타내는 소정의 한계치 아래로 떨어진 경우의 상태, 실시간(RT) 논리 링크 제어(LLC) 프레임의 전송이 비-실시간(NRT) LLC 프레임 후에 큐잉된 경우의 상태, 및 현재의 RT LLC 프레임의 시간 지연 요건이 만족될 수 없다고 판단된 경우의 상태로 이루어진 그룹으로부터 선택된 상태를 포함하는, 전송 윈도우를 사용하는 패킷 데이터 전송 프로토콜을 위한 방법.
2. 제1항에 있어서,

   상기 더미 데이터 패킷 블록은 더미 무선 링크 제어(RLC) 블록인, 전송 윈도우를 사용하는 패킷 데이터 전송 프로토콜을 위한 방법.
3. 삭제
4. 삭제
5. 전송 윈도우를 사용하는 패킷 데이터 전송 프로토콜을 위한 장치로서,

   제1 전송 윈도우로부터 데이터 패킷들의 블록들을 송신하기 위한 수단;

   상기 송신된 데이터 패킷들에 대해, 적어도 하나의 부정응답을 수신하기 위한 수단;

   적어도 헤더 정보를 포함하는 더미 데이터 패킷 블록을 구성하기 위한 수단;

   본래 송신된 데이터 패킷들에 사용된 것보다 더 강력한 코딩 레이트로 상기 더미 데이터 패킷 블록을 전송하기 위한 수단;

   상기 더미 블록에 대한 응답을 수신하기 위한 수단; 및

   후속 전송 윈도우로부터 데이터 패킷들의 새로운 블록들을 송신하기 위한 수단

   을 포함하고,

   상기 프로토콜의 트리거를 수립하기 위한 수단을 더 포함하고,

   상기 프로토콜은 상기 트리거의 발생시에만 발생하고,

   상기 트리거는, 다음 윈도우 내의 RLC 블록에 대한 코딩 스킴이 현재 윈도우 내의 RLC 블록에 이용되는 코딩 스킴보다 더 강한 경우의 상태, 상기 수신된 부정응답이 소정 기간보다 긴 기간 동안 RLC 윈도우 스톨이 발생하도록 야기한 경우의 상태, 상기 전송 윈도우 내의 새로운 블록들의 수가 임박한(impending) 스톨 상태를 나타내는 소정의 한계치 아래로 떨어진 경우의 상태, 실시간(RT) 논리 링크 제어(LLC) 프레임의 전송이 비-실시간(NRT) LLC 프레임 후에 큐잉된 경우의 상태, 및 현재의 RT LLC 프레임의 시간 지연 요건이 만족될 수 없다고 판단된 경우의 상태로 이루어진 그룹내의 하나의 상태를 포함하는, 전송 윈도우를 사용하는 패킷 데이터 전송 프로토콜을 위한 장치.
6. 제5항에 있어서,

   상기 더미 데이터 패킷 블록은 더미 무선 링크 제어(RLC) 블록인, 전송 윈도우를 사용하는 패킷 데이터 전송 프로토콜을 위한 장치.
7. 삭제
8. 삭제
9. 삭제
10. 삭제

Images