KR100711738B1

KR100711738B1 - 비트맵 기반 자동 재전송 요구 엔진 및 그것의 제어 방법

Info

Publication number: KR100711738B1
Application number: KR1020050012293A
Authority: KR
Inventors: 남경완; 이갑주; 최재선
Original assignee: 삼성전자주식회사
Priority date: 2005-02-15
Filing date: 2005-02-15
Publication date: 2007-04-25
Also published as: CN1848719B; US7487424B2; TW200642347A; KR20060091418A; US20060195753A1; CN1848719A; TWI309115B

Abstract

여기에 개시된 비트맵 기반 자동 재전송 요구 엔진 및 방법은, IEEE 802.11e 등과 같은 무선 랜 표준에서 보안 기능을 위해 제공되는 키 검색 엔진(Key Search Engine)을 이용하여, 수신된 프레임에 대한 BA(Block ACK)를 임미디어트 BA(Immediate BA)로 처리할 것인지, 또는 딜레이드 BA(Delayed BA)로 처리할 것인지 여부를 SIFS(Short Interframe Space) 구간 내에 결정하고, 결정된 BA의 타입에 따라서 상기 SIFS 구간 내에 해당 프레임들에 대한 BA를 즉각적으로 처리하거나(즉, Immediate BA), 또는 소정 시간이 지연된 이후에 소프트웨어적으로 처리한다(즉, Delayed BA). 본 발명에 따른 비트맵 기반 ARQ 엔진은, BA의 처리 방식을 결정하기 위해, MAC 어드레스에 대한 검색과 및 트래픽 ID에 대한 검색을 모두 수행하고, 이들과 정확히 일치하는 비트맵 엔트리를 검색해 낸다. 따라서, ARQ의 정확도가 높아지게 된다. 특히, 본 발명에 사용되는 비트맵 메모리는, 메모리의 단편화 문제를 최소화하며 운용되기 때문에, 최소한의 비트맵 메모리를 가지고도 블록 단위의 BA 처리를 효율적으로 처리할 수 있다. 따라서, 저렴한 비용으로 신속하고 정확한 비트맵의 분석을 수행할 수 있고, 통해 무선 네크워크에 연결된 채널에 대한 신뢰성 있는 전송과 서비스 품질(QoS)을 보장할 수 있게 된다.

Description

비트맵 기반 자동 재전송 요구 엔진 및 그것의 제어 방법{BITMAP-BASED AUTOMATIC REPEAT REQUEST ENGINE AND METHOD FOR THE SAME}

도 1은 IEEE 802.11e 프로토콜에서 데이터와 블록 단위의 수신확인신호가 송수신되는 타이밍을 보여주는 도면;

도 2는 본 발명의 바람직한 실시예에 따른 비트맵 기반 ARQ 엔진의 전체 구성을 보여주는 블록도;

도 3은 도 2에 도시된 ARQ 제어부의 동작을 설명하기 위한 흐름도;

도 4는 도 2에 도시된 ARQ 정보 비교부의 상세 구성을 보여주는 도면;

도 5는 도 2에 도시된 비트맵 관리부의 상세 구성을 보여주는 도면;

도 6은 도 5에 도시된 BM 제어부의 상태 흐름도; 그리고

도 7은 본 발명의 바람직한 실시예에 따른 비트맵 메모리의 운용 예를 보여주는 도면이다.

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

10 : ARQ 제어부 30 : ARQ 정보 비교부(AIC)

31 : 제 1 비교부 35 : 제 2 비교부

50 : 비트맵 관리부(BM) 51 : BM 제어부

53 : BMI 관리부 55 : 비트맵 메모리

100 : 비트맵 기반 ARQ 엔진

본 발명은 무선통신 시스템에 관한 것으로, 좀 더 구체적으로는 비트맵 기반 자동 재전송 요구 엔진(Bitmap-based Automatic Repeat Request Engine) 및 그것의 제어 방법에 관한 것이다.

산업사회의 발달로 처리되는 정보량이 급증함에 따라, 방대한 정보를 신속 정확하게 송수신할 수 있는 고속 데이터 전송 기술로서, 무선 네트워크에 대한 관심이 늘어나고 있다. 무선 랜(Wireless Local Area Network ; WLAN)은 기존의 유선 랜을 대체 또는 확장한 유연한 데이터 통신시스템으로, 무선주파수(Radio Frequency ; RF) 기술을 이용하여 유선망 없이도 데이터를 주고받을 수 있는 기능을 제공한다. 즉, 유선망에 구속되지 않고도 이더넷(Ethernet)이나 토큰링(Token ring)과 같은 유선 랜의 모든 이점과 기능을 제공한다. IEEE 802.11위원회에서 확정한 무선랜(Wireless Local Area Network ; WLAN)의 표준 규격에 따르면, 매체 접근 제어(Media Access Control ; 이하 MAC이라 칭함) 계층은 여러 대의 단말이 최소의 간섭과 최대의 성능을 가지고 공유하는 채널을 효율적으로 사용하기 위한 제어를 수행하고, 전송로의 이상 유무를 검출하는 기능을 수행한다.

데이터 통신 시스템에서는 송신기와 수신기 사이에 송수신되는 데이터 패킷(이하, 프로토콜 데이터 유닛(Protocol Data Unit ; PDU)이라 칭함)의 신뢰성 있는 전송을 보장하기 위해, 자동 재전송 요구라 불리는 ARQ(Automatic Repeat Request) 기술을 사용한다. ARQ는, 수신측이 송신측에게 손상된 데이터를 재 송신해줄 것을 요구하는 에러 통제 프로토콜이다. ARQ는 데이터 전송 시 에러 검출 코드(예를 들면, CRC(Cyclic Redundancy Check))를 사용한다. 에러 검출 코드는 수신기가 프로토콜 데이터 유닛(PDU)을 정확하게 수신했는지를 판정하는데 사용된다. 판정 결과 전송에러가 발생하였으면, ARQ는 자동으로 송신자에게 재 전송을 요청하여 통신 시스템의 전송 에러를 줄여 준다.

ARQ의 방식에는 정지-대기(Stop-and-Wait) ARQ, 고우-백-N(Go-Back-N) ARQ, 선택적 재전송(Selective Repeat) ARQ 등의 방식이 있다. 정지-대기 ARQ 방식은 한번에 하나의 프로토콜 데이터 유닛을 전송하는 방식으로, 프레임이 성공적으로 전달된 것을 확인한 후에 다음 프레임을 전송한다. 이 방식은 구현이 용이하다는 장점이 있지만, 하나의 프레임을 전송한 후 수신기로부터 해당 프로토콜 데이터 유닛을 성공적으로 수신했다는 수신확인신호(즉, ACK 신호)를 수신할 때까지 수신기에게 새로운 프로토콜 데이터 유닛을 전송하지 않기 때문에, 데이터 전송 효율이 낮은 단점이 있다. 고우-백-N ARQ 방식은 송신기가 수신기로부터 이전의 프로토콜 데이터 유닛을 성공적으로 수신하지 못했음을 표시하는 수신확인신호(즉, NACK 신호)을 수신할 때까지 연속적으로 데이터를 송신한다. 그리고 나서, 프로토콜 데이터 유닛의 미착 여부나 수신의 정확성 여부에 상관없이 후속의 모든 프로토콜 데이터 유닛들을 재 전송한다. 그러나, 고우-백-N ARQ 방식은 에러율이 낮고 왕복시간이 짧을 때에는 흡족할만한 성능을 보이지만, 에러율이 높아지거나 왕복시간이 길 어지게 되면, 데이터 전송 효율이 현저히 떨어지게 되는 단점이 있다. 이와 달리, 선택적 재전송 ARQ 방식에서 송신기는 수신기로부터 전송된 수신확인신호(ACK, NACK)의 조합에 응답해서 에러가 검출된 프로토콜 데이터 유닛만을 재 전송한다. 따라서, 선택적 재전송 ARQ 방식은 정지-대기 ARQ 방식이나 고우-백-N ARQ 방식 보다 전송 효율이 높은 장점을 가진다. 그러나, 구현이 복잡하고, 이론상으로 수신측에 무한한 버퍼 용량을 필요로 하기 때문에 비용이 많이 소요되는 문제가 있다.

기존의 무선 랜의 표준 규격(예를 들면 IEEE 802.11a, IEEE 802.11b)은 정지-대기(Stop-and-Wait) ARQ를 기반으로 한다. 정지-대기 ARQ 방식은, 구현이 용이하다는 장점이 있지만, 하나의 프레임을 전송한 후 수신기로부터 해당 프로토콜 데이터 유닛을 성공적으로 수신했다는 수신확인신호(ACK)를 수신할 때까지 수신기에게 새로운 프로토콜 데이터 유닛을 전송하지 않는다. 따라서, 데이터 전송 효율이 낮은 단점이 있다. 이와 같은 문제를 해결하기 위해, 최근에 제안된 무선 랜의 표준 규격(예를 들면, IEEE 802.11e, IEEE 802.11n, IEEE 802.16d 등)에서는, 프레임 단위 대신 블록 단위의 수신확인신호(Block ACK ; BA)를 보내는 Block ACK 기법(Block ACK mechanism)을 지원한다. Block ACK 기법은, 복수 개의 데이터 프레임들이 그룹 단위로 전송되는 것을 허용(allows)하기 때문에, 채널을 보다 효율적으로 사용할 수 있다. 그러나, 이 방식은 복수 개의 프레임들에 대한 복수 개의 ACK 신호들을 블록 단위로 처리해야 하기 때문에, 전송 제어 절차가 복잡한 문제가 있다.

따라서, 본 발명의 목적은 상술한 제반 문제점을 해결하기 위해 제안된 것으 로, 무선 네크워크에 연결된 채널에 대한 신뢰성 있는 전송과 서비스 품질(Quality of Service ; QoS)을 보장할 수 있는 비트맵 기반 자동 재전송 요구(ARQ) 엔진 및 그것의 제어 방법을 제공하는데 있다.

본 발명의 다른 목적은, 단말의 개수, 트래픽 ID의 개수, 프로토콜 데이터 유닛(Protocol Data Unit ; PDU)의 개수 등과 같이, 블록 단위의 ARQ의 성능을 좌우하는 가변 요소들에 대해 제약을 받지 않도록 최대한 유연하게 설계된 비트맵 기반 자동 재전송 요구(ARQ) 엔진 및 그것의 제어 방법을 제공하는데 있다.

본 발명의 또 다른 목적은, 비트맵 관리 정보를 이용하여 비트맵 메모리의 데이터 저장 공간을 효율적으로 관리함으로써, 불필요한 메모리 영역을 최소화시킨 비트맵 기반 자동 재전송 요구 엔진 및 그것의 제어 방법을 제공하는데 있다.

상술한 바와 같은 본 발명의 목적을 달성하기 위한 본 발명의 특징에 의하면, 비트맵 기반 자동 재전송 요구 엔진은, 복수 개의 프레임들에 대한 복수 개의 수신확인신호들과, 상기 수신확인신호들에 대한 복수 개의 관리정보들을 저장하는 비트맵 관리부; 수신된 프레임의 식별 정보와 상기 복수 개의 수신확인신호들에 대한 식별 정보들을 비교하여 상기 프레임의 처리 방식을 결정하는 자동 재전송 요구(Automatic Repeat Request ; ARQ) 정보 비교부; 그리고 상기 결정된 프레임의 처리 방식에 따라, 상기 수신확인신호들과 상기 관리정보들을 선택적으로 추출하여, 제 1 수신확인신호(Block Ack ; BA) 및 제 2 수신확인신호(ACK) 중 어느 하나를 발생하는 자동 재전송 요구 제어부를 포함하는 것을 특징으로 한다.

상술한 바와 같은 본 발명의 목적을 달성하기 위한 본 발명의 다른 특징에 의하면, 비트맵 기반 자동 재전송 요구 방법은, 복수 개의 프레임들에 대한 복수 개의 수신확인신호들과, 상기 수신확인신호들에 대한 복수 개의 관리정보들을 저장하는 단계; 수신된 프레임의 식별 정보와 상기 복수 개의 수신확인신호들에 대한 식별 정보들을 비교하여 상기 프레임의 처리 방식을 결정하는 단계; 그리고 상기 결정된 프레임의 처리 방식에 따라, 상기 수신확인신호들과 상기 관리정보들을 선택적으로 추출하여, 제 1 수신확인신호(Block Ack ; BA) 및 제 2 수신확인신호(ACK) 중 어느 하나를 발생하는 단계를 포함하는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 복수 개의 수신확인신호들은 비트맵 형식으로 저장되는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 자동 재전송 요구 정보 비교부는 무선 네트워크에서 보안 기능을 위해 제공되는 키 검색 엔진인 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 수신된 프레임 및 상기 복수 개의 수신확인신호들의 식별정보는, MAC(Media Access Control) 어드레스 및 트래픽 ID를 포함하는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 MAC 어드레스 하나 당 복수 개의 상기 트래픽 ID들이 대응되는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 트래픽 ID는, 접속 가능한 단말의 최대 개수만큼 할당되는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 자동 재전송 요구 정보 비교부는, 상기 수 신된 프레임의 상기 MAC 어드레스와 일치하는 MAC 어드레스 엔트리 번호를 검색하는 제 1 비교부; 그리고 제 1 비교부에서 일치하는 MAC 어드레스가 검출된 경우, 상기 수신된 프레임의 트래픽 ID 및 상기 MAC 어드레스 엔트리 번호와 일치하는 비트맵 엔트리를 검색하는 제 2 비교부를 포함하는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 제 1 비교부는, 상기 복수 개의 수신 확인 신호들에 대응되는 복수 개의 MAC 어드레스들을 저장하며, 상기 복수 개의 MAC 어드레스들은 상기 수신된 프레임의 MAC 어드레스와 비교되는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 제 2 비교부는, 상기 복수 개의 수신확인신호들에 대응되는 복수 개의 트래픽 ID들과 복수 개의 MAC 어드레스 엔트리 번호들을 저장하며, 상기 복수 개의 트래픽 ID들은 상기 수신된 프레임의 트래픽 ID와 비교되고, 상기 복수 개의 MAC 어드레스 엔트리 번호들은 상기 제 1 비교부로부터 입력된 상기 MAC 어드레스 엔트리 번호와 각각 비교되는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 자동 재전송 요구 제어부는, 상기 제 2 비교부에서 상기 트래픽 ID 및 상기 MAC 어드레스 엔트리 번호와 일치하는 비트맵 엔트리가 검색되면, 상기 제 1 수신확인신호를 발생하는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 제 1 수신확인신호는, 상기 복수 개의 수신확인신호들에 대해 그룹 단위로 발생된 수신확인신호인 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 자동 재전송 요구 제어부는, 상기 제 2 비교부에서 상기 트래픽 ID 및 상기 MAC 어드레스 엔트리 번호와 일치하는 비트맵 엔트리가 검색되지 않으면, 상기 제 2 수신확인신호를 발생하는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 제 2 수신확인신호는, 상기 수신된 프레임에 대한 단순 회답신호인 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 제 2 수신확인신호가 발생된 후 소정 시간이 경과하면, 소프트웨어적으로 상기 복수 개의 수신확인신호들에 대해 그룹 단위로 제 3 수신확인신호가 발생되는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 비트맵 관리부는, 상기 복수 개의 수신확인신호들을 비트맵 형태로 저장한 비트맵 메모리; 상기 관리 정보들을 저장하고, 상기 비트맵 메모리의 실제 어드레스를 계산하는 비트맵 정보 관리부; 그리고 상기 자동 재전송 요구 제어부의 제어에 응답해서, 상기 비트맵 메모리 및 상기 비트맵 정보 관리부에 저장된 정보들에 대한 검색, 업데이트, 및 추출 동작을 제어하는 비트맵 제어부를 포함하는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 비트맵 정보 관리부는, 협상되어 있는 프로토콜 데이터 유닛의 개수(Number of PDUs ; NOP), 상기 비트맵 메모리의 스타트 메모리 주소(Start Memory Address ; SMA), 및 프로토콜 데이터 유닛의 단편의 개수(Number Of Fragments ; NOF)를 저장하는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 비트맵 정보 관리부는, 프로토콜 데이터 유닛의 단편의 개수(NOF) 및 상기 프로토콜 데이터 유닛의 개수(NOP)를 근거로 하여, 상기 비트맵 메모리의 스타트 메모리 주소(SMA)를 계산하는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 비트맵 메모리는, 상기 제 1 수신확인신호 및 상기 제 2 수신확인신호 중 어느 하나가 발생되었을 때, 현재 사용 중인 상기 비트맵 메모리의 메모리 영역 보다 낮은 메모리를 갖는 영역 중에 사용이 완료된 메모리 영역이 존재하면, 상기 사용이 완료된 영역으로 데이터를 옮기는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 비트맵 메모리는 상기 옮겨진 메모리 영역의 어드레스에 응답해서 상기 스타트 메모리 주소(SMA)를 업데이트 하는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 비트맵 메모리 및 상기 비트맵 정보 관리부에 저장된 상기 정보들에 대한 업데이트, 검색, 및 추출 동작은, 블록수신확인신호 트랜젝션(Block Ack transaction) 단위로 반복되는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 비트맵 정보 관리부는, 스타트 웨이팅 플래그(Start Waiting Flag ; SWF), 상기 프레임들에 대한 스타트 시퀀스 번호(Start Sequence Number ; SSN)를 더 저장하는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 비트맵 정보 관리부는, 상기 블록수신확인신호 트랜젝션 구간이 시작될 때마다 상기 스타트 웨이팅 플래그(SWF)를 클리어하고, 상기 프레임들에 대한 스타트 시퀀스 번호(SSN)를 세팅하는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 수신된 프레임은, 블록 단위의 수신확인신호를 요청하는 프레임인 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 자동 재전송 요구 제어부는, 상기 수신된 프레임이 블록 단위의 수신확인신호이면, 현재 자신의 동작 상태가 상기 블록 단위 의 수신확인신호를 요청한 후 상기 블록 단위의 수신확인신호를 기다리던 중이었는지 여부를 확인하고, 상기 동작 상태의 확인 결과에 따라 상기 수신된 수신확인신호를 올바른 회신신호로서 인식하는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 자동 재전송 요구 제어부는, 상기 수신된 프레임이 서비스 품질 데이터인 경우, 상기 수신된 프레임의 정책 정보가 블록 단위의 수신확인신호를 제공하는 것으로 협상되어 있으면, 상기 수신된 프레임의 식별 정보와 상기 복수 개의 수신확인신호들에 대한 식별 정보들을 비교하는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 자동 재전송 요구 제어부는, 상기 비교 결과 상기 수신된 프레임의 식별 정보와 일치하는 상기 식별 정보가 존재하면, 해당 식별 정보에 대응되는 상기 수신확인신호 및 상기 관리정보들을 업데이트하는 것을 특징으로 한다.

바람직한 실시예에 있어서, 무선 네트워크에 연결된 적어도 하나 이상의 단말, 및 적어도 하나 이상의 중계기에 구비되는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 무선 네트워크는, 상기 단말과 단말의 접속, 상기 단말과 상기 중계기의 접속을 지원하는 것을 특징으로 한다.

상술한 바와 같은 본 발명의 목적을 달성하기 위한 본 발명의 다른 특징에 의하면, 비트맵 기반 자동 재전송 요구 엔진의 제어 방법은, 수신된 프레임의 종류를 분석하는 단계; 상기 분석된 프레임의 종류에 따라서, 상기 프레임의 식별정보와 비트맵 형식으로 저장된 복수 개의 수신확인신호들에 대한 식별 정보들에 대한 비교를 선택적으로 수행하는 단계; 그리고 상기 비교 결과에 따라 상기 수신된 프레임에 대한 처리 방식을 결정하는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 수신된 프레임의 종류가 블록 단위의 수신확인신호를 요청하는 프레임이면, 상기 프레임의 식별 정보와 상기 복수 개의 수신확인신호들에 대한 식별 정보들을 비교하여 상기 프레임에 대한 회답 방식을 결정하는 단계; 그리고 상기 결정된 프레임의 회답 방식에 따라, 상기 수신확인신호들과 상기 관리정보들을 선택적으로 추출하여, 제 1 수신확인신호(Block Ack ; BA) 및 제 2 수신확인신호(ACK) 중 어느 하나를 발생하는 단계를 포함하는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 수신된 프레임의 종류가 블록 단위의 수신확인신호이면, 현재 자신의 동작 상태가 상기 블록 단위의 수신확인신호를 요청한 후 상기 블록 단위의 수신확인신호를 기다리던 중이었는지 여부를 확인하는 단계; 그리고 상기 동작 상태의 확인 결과에 따라 상기 수신된 수신확인신호를 올바른 회신신호로서 인식하는 단계를 포함하는 것을 특징으로 한다.

바람직한 실시예에 있어서, 상기 수신된 프레임의 종류가 서비스 품질 데이터이면, 식별 정보와 상기 복수 개의 수신확인신호들에 대한 식별 정보들을 비교하는 단계; 그리고 상기 비교 결과, 상기 수신된 프레임의 식별 정보와 일치하는 상기 식별 정보가 존재하면, 해당 식별 정보에 대응되는 상기 수신확인신호 및 상기 관리정보들을 업데이트 하는 단계를 포함하는 것을 특징으로 한다.

(실시예)

이하 본 발명에 따른 실시예를 첨부된 도면을 참조하여 상세히 설명한다.

본 발명의 신규한 상술한 바와 같은 본 발명의 목적을 달성하기 위한 본 발명의 특징에 의하면, 비트맵 기반 자동 재전송 요구 엔진 및 방법은, 무선 랜 표준에서 보안 기능을 위해 제공되는 키 검색 엔진(Key Search Engine)을 이용하여, 수신된 프레임에 대한 BA(Block ACK)를 임미디어트 BA(Immediate BA)로 처리할 것인지, 또는 딜레이드 BA(Delayed BA)로 처리할 것인지 여부를 결정하여, BA의 처리 시간을 단축 시킨다. 그리고, 본 발명에 따른 비트맵 기반 ARQ 엔진은, BA의 처리 방식을 결정하기 위해, MAC 어드레스에 대한 검색과 및 트래픽 ID에 대한 검색을 모두 수행하기 때문에, ARQ의 정확도가 높아지게 된다. 특히, 본 발명에 사용되는 비트맵 메모리는, 메모리의 단편화 문제를 최소화하며 운용되기 때문에, 최소한의 비트맵 메모리를 가지고도 블록 단위의 BA 처리를 효율적으로 처리할 수 있다. 따라서, 저렴한 비용으로 신속하고 정확한 비트맵의 분석을 수행할 수 있고, 통해 무선 네크워크에 연결된 채널에 대한 신뢰성 있는 전송과 서비스 품질(QoS)을 보장할 수 있게 된다.

IEEE 802.11위원회에서 확정한 무선 랜 표준 규격, 예컨대 IEEE 802.11a, IEEE 802.11b 등과 같은 MAC 프로토콜들은 자원 경합 방식을 기반으로 설계되었기 때문에, QoS 보장을 위한 메커니즘이 포함되어 있지 않았다. 따라서, QoS에 문제를 갖고 있으며, 같은 주파수 대를 갖는 다른 제품들로 인해 상당한 주파수 간섭을 받는다. 그 결과, 데이터에는 영향을 미치지 않으나, 음성, 스트리밍(streaming) 오디오, 비디오와 같은 어플리케이션에서 문제가 발생하게 된다. 이와 같은 문제를 방지하기 위해, 최근에는 IEEE 802.11e 라는 새로운 워크 그룹(Work Group ; WG)이 결성되어, 무선 랜의 QoS 보장 측면의 요구 사항의 정립과 표준화를 유도하고 있다. 그리고, 도시권 통신망(Metropolitan Area Network ; MAN)이라 불리는 무선 MAN의 경우에도, 자원 할당 방식의 MAC을 기반으로 하는 IEEE 802.16을 이용하여 초기 표준화 작업에서부터 QoS 보장을 위한 요구 사항을 정립하고, 이에 대한 표준화를 추진하고 있다.

IEEE 802.11e MAC 프로토콜과 IEEE 802.16d 프로토콜 등에서는, 프레임 단위 대신 블록 단위의 수신확인신호(Block ACK ; BA)를 보내는 Block ACK 기법(Block ACK mechanism)을 지원한다. 하나의 블록에는 복수 개의 프레임들이 포함된다. Block ACK 기법은 복수 개의 프레임 단위(즉, 블록 단위)로 ACK 프레임을 처리하기 때문에, 그룹 ACK 기법(Group ACK mechanism)이라 불리기도 한다. ARQ에 Block ACK 기법을 적용하기 위해서는, 복수 개의 프레임들에 대한 수신확인신호들(긍정회신(ACK) 및/또는 부정회신(NACK))을 한꺼번에 관리할 수 있는 방안이 필요하다. 이를 위해, 802.11e MAC 프로토콜과 IEEE 802.16d 프로토콜 등에서는 비트맵(Bitmap)을 이용하여 복수 개의 프레임들에 대한 수신확인신호들((ACK/NACK))의 상태를 관리한다. 본 발명에서는 이와 같은 방식을 비트맵 기반 ARQ(Bitmap based ARQ)라 부르기로 한다. 아래에서는 IEEE 802.11e QoS 표준 스펙의 Block ACK을 지원하는 ARQ 엔진에 대해 중점적으로 설명될 것이다. 그러나, 이것은 본 발명이 적용되는 일 예에 불과하며, 비트맵 기반 ARQ 기능을 제공할 수 있는 타 무선 랜(또는 MAN) 스펙들(예를 들면, IEEE802.11g, IEEE802.11n, IEEE 802.16d 등)에도 모두 적용 가능하다.

도 1은 IEEE 802.11e 프로토콜에서 데이터와 블록 단위의 수신확인신호(이하, BA라 칭함)가 송수신되는 타이밍을 보여주는 도면이다. 도 1에는 하나의 단말(station ; STA)과 하나의 중계기(Access Point ; AP)가 연결된 점대점(Point-to-Point) 연결 방식을 예로 든 것으로, 상기 단말 및 중계기는 IEEE 802.11e 프로토콜에서 지원하는 QoS 단말 및 QoS 중계기를 각각 의미한다.

도 1을 참조하면, IEEE 802.11e 프로토콜에서는, 단말(STA)이 BAR(Block Ack Request) 프레임을 수신했을 때, SIFS(Short Interframe Space) 간격 내에 BA 프레임을 전송하도록 정의되어있다. SIFS는, 하나의 프레임 전송이 완료되고 나서 ACK, CTS(Clear To Send) 프레임 등을 전송하기 전까지의 시간 간격을 의미한다. 비트맵 기반 ARQ를 구현하기 위해서는, SIFS 구간 내에 비트맵을 분석하고 분석된 결과를 근거로 하여 128 바이트 길이의 BA(Block Ack) 프레임을 전송하여야 한다. 그러나, SIFS의 시간은 사실상 매우 짧은 시간이기 때문에, SIFS 구간 동안 상기와 같은 일련의 동작을 모두 수행하는 데에는 많은 어려움이 따른다.

따라서, 본 발명에서는 비트 맵 기반 ARQ를 효율적으로 지원할 수 있는 고속 비트맵 기반 ARQ 엔진을 구현하고, 이에 대한 제어 방법을 제시한다. 아래에서 상세히 설명되겠지만, 본 발명에 따른 비트맵 기반 ARQ 엔진은 IEEE 802.11e 등의 무선 랜 표준에서 보안 기능을 위해 제공되는 키 검색 엔진(Key Search Engine)을 이용하여 해당 프레임들에 대한 BA(Block Ack)를 임미디어트 BA(Immediate BA)로 처리할 것인지, 또는 딜레이드 BA(Delayed BA)로 처리할 것인지 여부를 결정한다. 결정된 BA의 타입에 따라서, 해당 프레임들에 대한 BA는 즉시 하드웨어적으로 처리되 거나(즉, Immediate BA), 또는 소정 시간이 지연된 이후에 소프트웨어적으로 처리된다(즉, Delayed BA).

IEEE 802.11e의 무선 랜 표준에서 BA를 지원하는 ARQ 엔진(100)을 설계함에 있어서 가변 요소는 다음과 같다. 첫째, 단말의 개수이고, 둘째, 트래픽 ID의 개수이다. 예를 들면, 1개의 단말과의 연결에 대해서도 다른 종류의 트래픽이 존재할 수 있다. 따라서, 트래픽의 종류를 구분하는데 트래픽 ID가 사용된다. 스펙에 정의되어 있는 트래픽 ID의 개수는 최대 16개인데, 실제 몇 개까지 지원할지는 구현 의존적이다. 셋째, 프로토콜 데이터 유닛(PDU)의 개수이다. 즉, 몇 개의 수신 프레임에 대해 1개의 ACK 프레임으로 회답하는가에 관한 문제이다. 스펙에는 최대 PDU의 개수가 64개인데, 이는 초기 협상에서 결정할 수 있다. 넷째, 단편의 개수(Number of Fragments)이다. 이는, PDU가 단편화될 때 최대 몇 개의 단편들로 나뉘어지는가에 대한 문제이다. 스펙에는 최대 16개로 규정되어 있으나, 실제로는 상황에 따라 가변적이다. 따라서, 본 발명에서는 이러한 가변 요소에 대해 최대한 유연한 특성을 갖는 ARQ 엔진을 제공한다.

도 2는 본 발명의 바람직한 실시예에 따른 비트맵 기반 ARQ 엔진(100)의 전체 구성을 보여주는 블록도이다. 도 2에 도시된 비트맵 기반 ARQ 엔진(100)은, IEEE 802.11e 등의 무선 랜 표준에서 지원하는 QoS 기능을 갖는 중계기(AP)와, QoS 기능을 갖는 단말(STA)에 구비된다. 상기 비트맵 기반 ARQ 엔진(100)은, 중계기(AP)와 단말(STA)간의 접속과, 단말(STA)과 단말(STA)간의 접속을 모두 지원한다. 상기 중계기(AP)와 단말들(STAs)은 데이터를 송신하는 기능과 데이터를 수신하는 기능을 모두 수행한다.

도 2를 참조하면, 본 발명에 따른 비트맵 기반 ARQ 엔진(100)은, 크게 ARQ 제어부(ARQ Controller ; 10), ARQ 정보 비교부(ARQ Information Comparator ; AIC)(30), 그리고 비트맵 관리부(Bitmap Manager ; BM)(50)로 구성된다.

ARQ 제어부(10)는 비트맵 기반 ARQ 엔진(100)의 제반 동작을 제어한다. 예를 들면, ARQ 제어부(10)는 수신한 복수 개의 프레임들의 종류에 따라 비트맵에 대한 검색(Search), 업데이트(Update), 및 추출(Extract) 동작을 제어하고, 상기 동작에 의해 얻어진 결과를 근거로 하여 상대방에게 회답 신호로서 BA 프레임 또는 ACK 프레임을 전송한다. 본 발명의 실시예에 있어서, ARQ 제어부(10)는 유한한 개수의 상태(State)를 가지는 유한 상태 머신(Finite State Machine ; FSM)으로 구성될 수 있다. 상태 머신(State Machine)은 각각의 상태(State)들을 어떤 조건에 따라 연결해 놓은 것으로, 하나의 입력(Input)을 근거로 하여, 현재 상태(Current State)로부터 다음 상태(Next State)로 전이(transition)하는 식으로 동작한다.

ARQ 정보 비교부(30)는, ARQ 제어부(10)의 제어에 따라 수신된 프레임에 대한 BA 처리 방식(즉, 임미디어트 BA로 처리할 것인지, 또는 딜레이드 BA로 처리할 것인지 여부)을 결정한다. 그리고 나서, ARQ 정보 비교부(30)는 결정된 BA 처리 방식에 따라서, 상대방에게 회답 신호로서 BA 프레임 및 ACK 프레임 중 어느 하나를 전송한다. 이를 위해 ARQ 정보 비교부(30)는 MAC 어드레스(MAC Address ; MA), 트래픽 ID(TID) 등의 ARQ 정보를 비교하여, 상기 ARQ 정보와 일치하는 엔트리가 비트맵에 존재하는지를 검색한다. ARQ 정보 비교부(30)에서 MAC 어드레스(MAC Address ; MA)에 대한 비교는 제 1 비교부(31)에서 수행된다. 그리고, 트래픽 ID에 대한 비교는 제 2 비교부(35)에서 수행된다. 이 분야에 대한 통상의 지식을 가진 이들에게 잘 알려져 있는 바와 같이, 비교 동작에는 많은 시간이 소요된다. 따라서, 본 발명에서는 비교에 소요되는 시간이 최소화될 수 있도록, IEEE 802.11i 등의 무선 랜 표준에서 기본적으로 제공되는 키 검색 엔진을 이용하여 비교를 수행한다. 그 결과, 비교에 사용될 하드웨어를 추가적으로 구비하지 않고도, 기존에 제공되는 구성을 활용하여 고속의 비교 동작을 수행할 수 있게 된다.

비트맵 관리부(50)는, ARQ 제어부(10)의 제어에 따라 비트맵을 업데이트하고, 비트맵 관리 정보(Bitmap Management Information ; BMI)를 관리한다, 그리고, 상기 비트맵 관리부(50)는 ARQ 제어부(10)의 제어에 따라, 검색된 결과를 ARQ 제어부(10)에게 출력하는 기능을 수행한다. 이를 위해 비트맵 관리부(50)는, BM 제어부(Bitmap Controller ; 51), BMI 관리부(Bitmap Management Information Controller ; 53), 및 비트맵 메모리(Bitmap Memory ; 55)를 포함한다.

도 3은 도 2에 도시된 ARQ 제어부(10)의 동작을 설명하기 위한 흐름도이다. 본 발명에 따른 비트맵 기반 ARQ 엔진(100)은 QoS 중계기(AP)와 QoS 단말(STA)에 구비되어, 중계기(AP)와 단말(STA)간의 접속과, 단말(STA)과 단말(STA)간의 접속을 모두 지원한다. 따라서, 도 3에서는 QoS 중계기(AP) 또는 QoS 단말(STA)이 데이터를 수신할 때의 동작과, 데이터를 송신할 때의 동작을 모두 나타내었다. 예를 들면, 도 3에 도시된 1100 내지 1130 단계의 동작과 1300 내지 1380 단계의 동작은 QoS 중계기(AP) 또는 QoS 단말(STA)이 데이터를 수신할 때의 동작을 나타내고, 1700 내지 1710 단계의 동작은 QoS 중계기(AP) 또는 QoS 단말(STA)이 데이터를 송신할 때의 동작을 각각 나타낸다.

도 3을 참조하면, ARQ 제어부(10)는 먼저 수신된 프레임의 타입을 판단한다(1000 단계). 1000 단계에서의 판단 결과, 수신된 프레임이 QoS 데이터(QDATA) 프레임인 경우에는, 해당 프레임의 ACK 정책(Ack Policy)이 BA(Block Ack)의 정책을 갖는지 여부를 판단한다(1100 단계). 여기서, 정책(policy)이란 네트웍 자원들이 클라이언트들 간에 어떻게 할당되어야 하는지를 정의한 일련의 공식 문장이다. 수신된 프레임이 BA의 정책을 갖는지의 여부는, 수신된 프레임의 일부 필드(Field)(예를 들면, 프레임의 헤더 등)를 해석함에 의해서 알 수 있다. 1100 단계에서의 판단 결과, 해당 프레임의 ACK 정책이 BA의 정책을 가지면, ARQ 정보 비교부(30)는 MAC 어드레스(MD)와, 트래픽 ID, 그리고 비트맵 어레이(Bitmap Array ; BtmArray)의 비교를 통해 비트맵에 일치하는 엔트리가 존재하는지 여부를 검색하고(1110 단계), 일치하는 엔트리가 비트맵에 존재하는지 여부를 판단한다(1120 단계). 1120 단계에서의 판단 결과, 상기 검색 결과와 일치하는 엔트리가 비트 맵에 존재하면, 비트맵 관리부(50)를 통해 비트맵 정보를 업데이트 한다(1130 단계). 이 때, 업데이트 되는 비트맵 정보를 위해 비트맵 엔트리 번호(Bitmap Entry Number ; BtM_EN), 시퀀스 번호(Sequence Number ; SN), 그리고 비트맵에 대한 단편 번호(Fragment Number ; FN)를 사용한다. 통상, 업데이트 동작은, 수신된 프레임의 CRC(Cyclic Redundancy Check) 데이터가 일치하지 않을 때 비트맵을 세팅하는 동작을 말한다. 그러나, 수신된 프레임이 제일 처음 수신된 프레임일 경우에는, 비트맵 을 관리하기 위한 정보도 함께 업데이트 한다. 이 때, CRC 데이터의 일치 여부에 따른 비트맵 값의 설정은 비트맵 메모리(55)에서 업데이트 되며, 비트맵을 관리하기 위한 정보는 BMI 관리부(53)에서 업데이트 된다. 그리고, 1120 단계에서의 판단 결과, 상기 검색 결과와 일치하는 엔트리가 비트 맵에 존재하지 않으면, 수순은 종료된다. 이상에서는 수신된 프레임이 QoS 데이터(QDATA) 프레임인 경우에 대한 ARQ 제어부(10)의 동작을 살펴보았다. 계속해서, 수신된 프레임이 BA(Block Ack)를 요구하는 BAR(Block Ack Request) 프레임인 경우에 대한 ARQ 제어부(10)의 동작을 살펴보면 다음과 같다.

1000 단계에서 ARQ 제어부(10)는 먼저 수신된 프레임의 타입을 판단한다. 1000 단계에서의 판단 결과, 수신된 프레임이 BA(Block Ack)를 요구하는 BAR(Block Ack Request) 프레임이면, ARQ 정보 비교부(30)는 MAC 어드레스(MD)와, 트래픽 ID, 그리고 비트맵 어레이(Bitmap Array ; BtmArray)에 대한 비교를 수행하고, 비트맵에 일치하는 엔트리가 존재하는지 여부를 검색한다(1300 단계). 그리고 나서, 1300 단계에서의 검색 결과와 일치하는 엔트리가 비트맵에 존재하는지 여부를 판단한다(1310 단계). 즉, 1310 단계에서는 해당 프레임들에 대한 BA를 임미디어트 BA(Immediate BA)로 처리할 것인지, 또는 딜레이드 BA(Delayed BA)로 처리할 것인지 여부를 결정하게 된다. BA의 타입에 따른 BA의 처리 방식은 다음과 같다.

1310 단계에서의 판단 결과, 상기 검색 결과와 일치하는 엔트리가 비트 맵에 존재하면(즉, 해당 프레임이 임미디어트 BA이면), 비트맵 관리부(50)는 BMI 관리부(53)와 비트맵 메모리(55)에 저장되어 있는 비트맵 정보를 추출한다(1320 단계). 이 때, 추출되는 비트맵 정보로는 비트맵 어레이(BtmArray), 비트맵 엔트리 번호(BtM_EN), 스타트 시퀀스 번호(Start Sequence Number ; SSN)가 있다. 1320 단계에서 추출된 비트맵 정보(BtmArray, BtM_EN, SSN)는 ARQ 제어부(10)로 제공된다. ARQ 제어부(10)는 비트맵 관리부(50)로부터 추출된 비트맵 정보(BtmArray, BtM_EN, SSN)를 근거로 하여 BA 프레임을 생성한다(1330 단계). 그리고 나서, 생성된 BA 프레임을 상대방(즉, 송신측)에게 회답 신호로서 전송한다(1340 단계).

한편, 1310 단계에서의 판단 결과, 상기 검색 결과와 일치하는 엔트리가 비트 맵에 존재하지 않으면(즉, 해당 프레임이 딜레이드 BA이면), ARQ 제어부(10)를 통해 ACK 프레임을 생성하고(1370 단계), 생성된 ACK 프레임을 상대방(즉, 송신측)에게 회답 신호로서 전송한다(1380 단계). 이처럼, 해당 프레임이 딜레이드 BA인 경우, ARQ 엔진(100)은 ACK 프레임을 전송하는 동작만 수행할 뿐, 딜레이드 BA를 처리하기 위한 더 이상의 동작을 수행하지 않는다. 딜레이드 BA를 처리하기 위한 실질적인 동작은 ARQ 엔진(100)이 아니라 수신측 장비(즉, 회답신호를 전송하는 중계기 또는 단말) 내부에서 소프트웨어적으로 수행된다. 즉, BAR 프레임을 수신한 중계기 또는 단말은, ACK 프레임을 상대편으로 전송하고 난 뒤, 상기 BAR 프레임을 소프트웨어적으로 해석한다. 그리고 나서, BA 프레임을 만들어서 나중에 전송한다. 이상에서는 수신된 프레임이 BAR 프레임인 경우에 대한 ARQ 제어부(10)의 동작을 살펴보았다. 계속해서, 수신된 프레임이 BA(Block Ack) 프레임인 경우에 대한 ARQ 제어부(10)의 동작을 살펴보면 다음과 같다.

1000 단계에서 ARQ 제어부(10)는 먼저 수신된 프레임의 타입을 판단한다. 1000 단계에서의 판단 결과, 수신된 프레임이 BA 프레임이면, ARQ 제어부(10)는 BA 프레임을 받아들인 자신의 동작 상태를 판단한다. 즉, 자신(즉, 송싱부)의 동작 상태가 상대편(즉, 수신부)에게 BA를 요구하는 BAR을 보내놓고 BA 프레임이 수신되기를 기다리는 WBA(Wait for BA frame) 상태에 있는지 여부를 판단한다(1700 단계). 1700 단계에서의 판단 결과 BA 프레임이 수신되기를 기다리고 있었으면, 수신된 BA 프레임을 BAR에 대한 정상적인 응답으로 인식한다(1710 단계). 그리고, 1700 단계에서의 판단 결과 BAR을 보내지도 않았는데 BA 프레임이 수신되었으면, 수신된 BA 프레임을 비정상적인 응답으로 인식하고, 해당 프레임을 무시(ignore)한다. 그리고, 수순은 종료된다.

앞에서 설명한 본 발명에 따른 BA을 지원 방안을 송신측과 수신측을 구분하여 요약하면 아래의 [표 1]과 같다.

[표 1]에는 도 3에 도시된 동작(예를 들면, 수신된 프레임이 QDATA인 경우와, BAR인 경우, 그리고 BA인 경우) 외에도, 송신측과 수신측에서 BA 엔트리를 추가하는 동작과, BA 엔트리를 삭제하는 동작에 대해 더 설명되어 있다. 이와 같은 BA 엔트리의 추가 및 삭제 동작은, 하드웨어로 구성될 수 도 있고, DD(Device Driver)와 같은 소프트웨어에 의해 수행될 수도 있다.

도 4는 도 2에 도시된 ARQ 정보 비교부(AIC ; 30)의 상세 구성을 보여주는 도면이다. 도 4를 참조하면, ARQ 정보 비교부(30)는 제 1 비교부(31)와 제 2 비교부(35)를 포함한다.

제 1 비교부(31)는 제 1 데이터 저장부(311)와 제 1 비교논리회로(315)로 구성된다. 제 1 데이터 저장부(311)는 64 개의 엔트리에 해당되는 MAC 어드레스들(MA0-MA63)과, 상기 MAC 어드레스들(MA0- MA63)에 대한 ARQ의 유효성(Valid) 여부를 저장한다. 여기서, ARQ가 유효하다는 의미는, 해당 MAC 어드레스(MA0-MA63)에 대해 블록 단위의 ACK가 수행되도록 정책이 결정되어 있음을 의미한다. 이는, 중계기(AP) 및/또는 단말(STA)들의 협상에 의해 결정된다.

제 1 비교부(31)는 ARQ 제어부(10)의 검색 요구에 응답해서, 제 1 데이터 저장부(311)에 저장되어 있는 유효한 MAC 어드레스들(MA0-MA63)과, 프레임으로부터 추출된 MAC 어드레스(MA[47:0])를 비교하여, 서로 일치하는 MAC 어드레스가 존재하는지 여부를 검출한다. 이와 같은 MAC 어드레스의 비교는, 제 1 비교논리회로(315)에서 수행된다. 제 1 비교논리회로(315)는 XOR 또는 XNOR 연산을 수행하는 논리회로로 구성될 수 있다. 도 4에는 제 1 비교논리회로(315)가 XNOR 연산을 수행하는 논리회로로 구성된 경우가 예시되어 있다.

제 1 비교부(31)는 제 1 비교논리회로(315)의 비교 결과에 따라, MAC 어드레스에 대한 히트(Hit)/미스(Miss) 결과와, 히트된 MAC 어드레스의 엔트리 번호(MAC Address Entry Number ; MA_EN)를 출력한다. 제 2 비교부(35)는, 제 1 비교부(31)로부터 발생된 MAC 어드레스에 대한 히트(Hit)/미스(Miss) 결과에 응답해서, MAC 어드레스 엔트리 번호(MAC Address Entry Number ; MA_EN)와 트래픽 ID에 대한 비교를 선택적으로 수행한다. 그리고, 제 2 비교부(35)는 비교 결과로서 트래픽 ID에 대한 히트(Hit)/미스(Miss) 결과와, 비트맵 엔트리 번호(Bitmap Entry Number ; BtM_EN)를 출력한다. 제 2 비교부(35)의 상세 구성 및 동작은 다음과 같다.

제 2 비교부(35)는 제 2 데이터 저장부(351)와 제 2 비교논리회로(355)로 구성된다. 제 2 데이터 저장부(351)는 64 개의 엔트리에 해당되는 MAC 어드레스 엔트리 번호(MA_EN)와 트래픽 ID를 저장한다. 제 2 비교부(35)는 제 1 비교부(31)로부터 활성화 된 히트(Hit) 신호가 발생된 경우에만, 제 1 비교부(31)로부터 입력된 MAC 어드레스 엔트리 번호(MA_EN[5:0])와 프레임으로부터 추출된 트래픽 ID(TID[3:0])가 제 2 데이터 저장부(351)에 저장되어 있는 데이터와 일치하는지 여부를 판별한다. MAC 어드레스 엔트리 번호(MA_EN)와 트래픽 ID에 대한 비교는, 실질적으로 제 2 비교논리회로(355)에서 수행된다. 제 2 비교논리회로(355) 역시 XOR 또는 XNOR 연산을 수행하는 논리회로로 구성될 수 있으며, 도 4에는 XNOR 연산을 수행하는 논리회로로 구성된 경우가 예시되어 있다. 제 2 비교부(35)는, 제 2 비교논리회로(355)의 비교 결과, 일치되는 MAC 어드레스 엔트리 번호(MA_EN)와 트래픽 ID가 존재하는 것으로 판별되면, 활성화된 히트(Hit) 신호를 발생한다. 그리고, 이와 동시에 트래픽 ID에 대응되는 비트맵 엔트리 번호(Btm_EN)를 출력한다.

제 1 비교부(31) 및 제 2 비교부(35)에서 수행되는 비교 동작은 병렬 비교 동작이 아니라, 제 1 비교부(31)의 비교 동작이 수행된 후 제 1 비교부(31)의 비교 결과에 따라 제 2 비교부(35)의 비교 동작이 수행되는 직렬 비교 동작을 수행한다. 예를 들어, 제 1 비교부(31)의 MAC 어드레스의 비교 결과 일치하는 MAC 어드레스가 존재하지 않는 경우(즉, 미스(Miss))인 경우, 제 2 비교기(35)에서는 더 이상 비교 동작이 수행되지 않는다. 따라서, 불필요한 비교 동작이 생략될 수 있으며, 회로의 구성이나 제어가 간단해 진다. 특히, 제 1 비교부(31) 및 제 2 비교부(35)는 CAM(Content-Addressable Memory)을 이용한 병렬 비교기(Parallel Comparator)로 구성될 수도 있지만, SPSRAM(Single-Port SRAM)을 이용한 직렬 비교기(Sequential Comparator)로 구성될 수 있다. 이 경우, 게이트 카운트(Gate Count)가 줄어들 수 있고, FPGA(Field-Programmable Gate Array) 프로토타입 테스트가 용이해 진다.

본 발명에 따른 ARQ 정보 비교부(30)는, IEEE 802.11i 등의 무선 랜 표준에서 기본적으로 제공되는 키 검색 엔진을 그대로 이용한 구조이다. 따라서, 별도의 하드웨어를 추가하지 않고도, 기존에 제공되는 구성을 활용하여 ARQ 정보를 비교할 수 있다. 본 발명에 따른 ARQ 정보 비교부(30)의 구성에서는, 기존의 키 검색 엔진에 MAC 어드레스들(MA0-MA63)에 대한 ARQ의 유효성(Valid) 정보와, 트래픽 ID 관련 정보만 추가되었다. 무선 랜 표준에서 지원하는 키 검색 엔진의 엔트리 개수는 64개가 일반적이다. 따라서, 본 발명에 따른 ARQ 엔진(100)의 ARQ 정보 비교부(30) 역시 64개의 엔트리를 지원한다. 여기서, 64개의 엔트리를 지원한다는 것은, 임미디어트 타입의 BA로 가능한 단말의 개수를 최대 64개까지 지원할 수 있음을 의미한다. 특히, 본 발명에 따른 ARQ 정보 비교부(30)에서는, MAC 어드레스 엔트리 번호(MA_EN)와 트래픽 ID를 함께 비교하기 때문에, 무선 랜의 표준 스펙에서와 같이 MAC 어드레스 엔트리 당 트래픽 ID의 개수를 최대 16개까지 지원할 수 있다. 단, 전체 총 트래픽 ID의 개수는 단말의 개수와 동일하게 64개로 구현한다. 즉, 64개 단말에 각각 1개의 트래픽 ID를 지원하도록 구성할 수도 있고, 4개의 단말이 각각 16개의 트래픽 ID를 지원하도록 구성할 수 있다. 이와 같은 구성에 따르면, 실제 사용 현황에 따라서 동적으로(dynamically) 변화를 지원할 수 있는 장점이 있다.

도 5는 도 2에 도시된 비트맵 관리부(BM ; 50)의 상세 구성을 보여주는 도면이다. 도 5를 참조하면, 비트맵 관리부(50)는 BM 제어부(Bitmap Controller ; 51), BMI 관리부(Bitmap Management Information Controller ; 53), 및 비트맵 메모리(Bitmap Memory ; 55)로 구성된다.

비트맵 관리부(BM ; 50)는, ARQ 제어부(10)로부터 발생된 검색(Search), 업데이트(Update), 및 추출(Extract) 요구에 응답해서, 비트맵에 대한 검색, 업데이트, 및 추출 동작을 수행한다. 이를 위해, BM 제어부(51)는, ARQ 제어부(10)로부터 발생된 요구에 따라 비트맵 관리부(50)의 제반 동작을 제어한다. BM 제어부(51)는, ARQ 제어부(10)와 마찬가지로 유한한 개수의 상태(State)를 가지는 유한 상태 머신(Finite State Machine ; FSM)으로 구성될 수 있다. BMI 관리부(53)는, 비트맵을 관리하기 위한 정보인 BMI (Bitmap Management Information)를 저장한다. 그리고, 비트맵 메모리(55)는 실제 비트맵 정보를 저장하는데 사용된다. 비트맵 관리부(50)를 구성하는 각 구성 요소들에 대한 상세 구성 및 동작은 다음과 같다.

BMI 관리부(53)에 저장되는 비트맵 관리 정보(BMI)는, 중계기 또는 단말이 소프트웨어적으로 관리되는 정보와, 하드웨어적으로 관리되는 정보로 구분된다. 소프트웨어적으로 관리되는 정보에는 단편의 개수(Number Of Fragments ; NOF), 프로토콜 데이터 유닛의 개수(Number of PDUs ; NOP), 및 비트맵 메모리(55)의 스타트 메모리 주소(Start Memory Address ; SMA)가 있다. 그리고, 하드웨어적으로 관리되는 정보에는 스타트 웨이팅 플래그(Start Waiting Flag ; SWF), 및 스타트 시퀀스 번호(Start Sequence Number ; SSN)가 있다. 스타트 웨이팅 플래그(SWF)는, 새로운 BA 트랜젝션(BA transaction)의 시작 시점을 나타내는 플래그(Flag)이다.

이들 정보 중 SWF, SSN, NOP, 및 SMA는 하나의 엔트리를 구성하며, 상기와 같은 구성을 갖는 64 개의 엔트리들이 BMI 관리부(53)에 저장된다. 그리고, NOF는 SWF, SSN, NOP, 및 SMA로 구성된 64개의 엔트리들과 별도로 BMI 관리부(53)에 저장되어, 비트맵의 단편의 개수를 관리하는데 사용된다.

비트맵 관리 정보와 관련된 본 발명의 주요 과제는, ARQ 엔진(100)의 실제 사용 현황에 맞게 비트맵 메모리를 최대한 유연(flexible)하게 활용하는 것이다. NOF, NOP, 그리고, SMA는 이런 의도를 반영한 것이다. 예를 들면, NOF는 현재 네트워크에서 프로토콜 데이터 유닛의 단편(Fragments)에 대한 실제 사용 현황을 기록하는 데 사용된다. NOP는 실제 협상(negotiation)된 최대 PDU의 개수(maximum number of PDUs)를 기록하는 데 사용된다. SMA는 비트맵 메모리(55)의 실제 시작 주소(즉, 비트맵 메모리(55)의 물리 주소(physical address))를 기록하는 데 사용된다. SMA에 기록된 비트맵 메모리(55)의 실제 시작 주소는, NOF와 NOP에 저장된 정보를 근거로 하여 계산된다. 비트맵 메모리(55)의 실제 시작 주소를 계산하기 위해, BMI 관리부(53) 내부에는 간단한 연산회로(미 도시됨)가 구비된다. 이와 같이, 본 발명에 따른 비트맵 기반 ARQ 엔진(100)은, 비트맵 메모리(55)를 관리하는데 필요한 정보들을 BMI 관리부(53) 내에 기록함으로써, 비트맵 메모리(55)를 최대한 효율적으로 사용한다.

아래에서는, 앞에서 설명한 BMI 관리부(53)의 구성을 근거로 하여, 본 발명에 따른 비트맵 기반 ARQ 엔진(100)의 동작을 살펴보기로 한다. 도 5에는 비트맵 메모리(55)의 NOF가 8일 때, BMI의 1번째 엔트리(즉, 0x0의 Btm_EN)가 최대 4개의 PDU로 협상(negotiation)된 경우와, 2번째 엔트리(즉, 0x1의 Btm_EN)가 최대 16개의 PDU로 협상된 경우가 도시되어 있다. BMI 관리부(53)는 SMA, NOF, NOP, SSN, 그리고 수신 프레임의 시퀀스 번호(SN)와 단편 번호(FN)를 이용하여, 업데이트된 비트맵 메모리(55)의 어드레스와, 추출된 비트맵 메모리(55)의 어드레스를 정확히 계산한다. 이를 위해 BMI 관리부(53) 내부에는 가산기(adder) 등과 같은 연산 회로(미 도시됨)가 구비된다.

BMI 관리부(53) 내부에는 총 64개의 엔트리가 지원된다. 이는 하드웨어적으로 임미디어트 BA를 지원할 수 있는 단말의 최대 개수(즉, 64개)와 동일하다. 하지만, 비트맵 메모리(55)는, 단지 16 개의 단편과 64개의 PDU로 구성된 데이터 쌍(16 Fragment, 64 PDU)을 총 16개까지 지원할 수 있는 메모리 용량, 즉 2,048 바이트의 메모리로 구성된다. 이처럼 비트맵 메모리(55)의 작은 용량에도 불구하고, 본 발명에 따른 ARQ 엔진(100)은 데이터 쌍의 구성에 따라서 실질적으로 제공할 수 있는 데이터 쌍(Fragment, PDU)의 개수는 최대 64개까지 확장 가능하다(즉, 최대 64개의 단말에 대해 임미디어트 BA를 지원할 수 있다). 비트맵 메모리(55)에 대한 메모리 용량의 효율적 사용에 대해서는 도 7을 참조하여 상세히 설명될 것이다.

도 6은 도 5에 도시된 BM 제어부(51)의 상태 흐름도이다. 도 6을 참조하면, BM 제어부(51)에서 수행되는 주요 동작은, SWF(Start Waiting Flag)를 클리어(clear)하는 것과, SSN(Start Sequence Number)을 BMI 관리부(53)에 설정하는 일이다. SWF는 시작 시점을 찾기 위한 플래그(Flag)로서, BA 프레임을 회답한 후에 '1'로 세팅된다. BM 제어부(51)는, SWF가 세팅된 후에 첫 번째의 BA의 정책 프레임을 수신하게 되면, 새로운 BA 트랜젝션(BA transaction)이 시작되는 것으로 인식하고 SSN을 BMI 관리부(53)에 기록한다. 그리고 나서 BM 제어부(51)는 SWF를 '0'으로 클리어 한다. 여기서, BA 트랜젝션은 첫번째 BA 정책(policy) 프레임부터 BA 회답까지 송/수신되는 프레임 시퀀스를 의미한다(도 1 참조). 비트맵 메모리(55) 및 BMI 관리부(53)에 저장된 정보에 대한 업데이트, 검색, 및 추출은 트랜젝션 단위로 반복된다.

도 7은 본 발명의 바람직한 실시예에 따른 비트맵 메모리(55)의 운용 예를 보여주는 도면이다.

비트맵 메모리(55)를 유연하게 사용함에 따라 생길 수 있는 문제는, 메모리의 단편화(Memory Fragmentation) 문제이다. 예를 들어, 비트맵 메모리를 동적으로 사용하게 되면서, 도 7의 좌측에 도시된 바와 같이 비트맵 메모리(5)의 메모리 영역이 단편화된다. 이 때, 비트맵 메모리(5)에 실제 남아있는 메모리의 용량은, 다음 번 후보 비트맵(Next Candidate Bitmap)의 크기 보다 크지만, 여러 군데로 쪼개져 있다 보니 사실상 사용할 수 없게 된다. 이는 비트맵 메모리의 전체 용량을 증가시키고, 자원의 낭비를 초래하게 된다.

이와 같은 문제를 해결하기 위해, 본 발명에서는 도 7의 우측에 도시된 바와 같이, 비트맵 메모리(55)가 단편화되지 않도록 데이터를 패킹(packing)시켜 저장한다. 예를 들어, 현재 사용 중인 메모리 영역보다 낮은 주소를 갖는 영역 중에 사용이 완료된 메모리 영역이 있으면, 비트맵 메모리(55)는 BA 트랜젝션이 끝날 때마다 사용이 완료된 영역으로 데이터를 옮기는 동작을 수행한다. 이와 같은 동작은 SMA(Start Memory Address)값을 바꾸는 것만으로 쉽게 해결된다. 따라서, 소프트웨어적인 연산을 통해 수행할 수 있다. 이 경우, 비어 있는 메모리 영역이 현재 데이터가 저장되어 있는 메모리 영역 보다 큰 경우에만 메모리 영역이 옮겨지게 되며, 메모리 영역이 옮겨지고 난 후의 다음 BA 트랜젝션부터는 바뀌어진 SMA부터 처리되도록 한다. 이러한 단순한 조작만으로도, 도 7에 도시된 바와 같이 메모리의 단편화 문제가 효과적으로 방지될 수 있다. 그 결과, 비트맵 메모리(55)를 최대한 효율적으로 사용할 수 있게 된다.

앞에서 설명한 바와 같이, 본 발명에 따른 비트맵 기반 ARQ 엔진(100)은, IEEE 802.11i 등과 같은 무선 랜 표준에서 보안 기능을 위해 제공되는 키 검색 엔진(Key Search Engine)을 이용하여, 수신된 프레임에 대한 BA를 임미디어트 BA(Immediate BA)로 처리할 것인지, 또는 딜레이드 BA(Delayed BA)로 처리할 것인지 여부를 SIFS와 같이 정해진 구간 동안 결정한다. 그리고, 결정된 BA의 타입에 따라서 해당 프레임들에 대한 BA를 즉각적으로 처리하거나(즉, Immediate BA), 또는 소정 시간이 지연된 이후에 소프트웨어적으로 처리한다(즉, Delayed BA). 비트맵 기반 ARQ 엔진(100)은, BA의 처리 방식을 결정하기 위해, MAC 어드레스에 대한 검색과 및 트래픽 ID에 대한 검색을 수행하고, 이들과 정확히 일치하는 비트맵 엔트리를 검색해 낸다. 따라서, ARQ의 정확도가 높아지게 된다.

이 외에도, 본 발명에 따른 비트맵 기반 ARQ 엔진(100)은 비트맵 메모리를 관리하는 비트맵 관리 정보(BMI)를 이용하여, 비트맵 메모리의 데이터 입출력을 관리한다. 그 결과, 비트맵 메모리에 대한 검색(Search), 업데이트(Update), 및 추출(Extract) 동작이 효율적으로 관리된다. 그리고, 본 발명에서는 메모리가 단편화되지 않고 컴팩트하게 저장될 수 있도록, SMA를 이용하여 비트맵 메모리(55)의 메모리 영역을 효율적으로 운용한다. 그 결과, 최소한의 메모리 용량을 가지고도 충분히 많은 데이터를 저장할 수 있고, 다수의 단말들(예를 들면, 무선 랜 스펙에서 지원하는 최대 단말 개수만큼)에 대해 ARQ를 처리할 수 있게 된다.

이상에서, 본 발명에 따른 회로의 구성 및 동작을 상기한 설명 및 도면에 따라 도시하였지만 이는 예를 들어 설명한 것에 불과하며 본 발명의 기술적 사상을 벗어나지 않는 범위 내에서 다양한 변화 및 변경이 가능함은 물론이다. 특히, 본 발명에 따른 비트맵 기반 ARQ 엔진(100)은 IEEE 802.11e의 무선 랜 표준 스펙을 예로 들어 설명되었다. 그러나, 이는 본 발명에 적용되는 일 예에 불과하며, 본 발명의 구조를 각 스펙에서 요구하는 조건으로 일부 변경하기만 하면, IEEE 802.11n, IEEE 802.16d 등의 무선 랜 표준 스펙에 적용될 수 있다. 예를 들면, 본 발명에 사용된 ARQ 제어부(10)의 구조를 일부 수정하고, MAC 어드레스 대신 CID(Caller ID)를 사용하고, NOF를 '1'로 고정하면, 802.16d의 선택적 ACK(Selective ACK) 방식에 그대로 적용될 수 있다.

본 발명은 또한 컴퓨터로 읽을 수 있는 기록매체에 컴퓨터가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 기록매체는 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 컴퓨터가 읽을 수 있는 기록매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한 캐리어 웨이브(예를 들어 인터넷을 통한 전송)의 형태로 구현되는 것도 포함한다. 또한 컴퓨터가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 컴퓨터가 읽을 수 있는 코드로 저장되고 실행될 수 있다.

이상과 같은 본 발명에 의하면, 최소한의 비트맵 메모리 용량을 가지고도 다수의 단말에 대한 블록 단위의 BA 처리를 효율적으로 처리할 수 있다. 그리고, 신속하고 정확한 비트맵의 분석을 통해 무선 네크워크에 연결된 채널에 대한 신뢰성 있는 전송과 서비스 품질(QoS)을 보장할 수 있게 된다.

Claims

복수 개의 프레임들에 대한 복수 개의 블록 수신확인신호(BA)들과, 상기 블록 수신확인신호들(BA)에 대한 복수 개의 관리정보들을 저장하는 비트맵 관리부;

수신된 프레임의 식별 정보와 상기 복수 개의 블록 수신확인신호들(BA)에 대한 식별 정보들을 비교하여 상기 프레임의 처리 방식을 결정하는 자동 재전송 요구(Automatic Repeat Request ; ARQ) 정보 비교부; 그리고

상기 결정된 프레임의 처리 방식에 따라서 상기 블록 수신확인신호(BA) 및 수신확인신호(ACK) 중 어느 하나를 발생하는 자동 재전송 요구 제어부를 포함하는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 1 항에 있어서,

상기 복수 개의 블록 수신확인신호들은 비트맵 형식으로 저장되는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 1 항에 있어서,

상기 자동 재전송 요구 정보 비교부는, 무선 네트워크에서 보안 기능을 위해 제공되는 키 검색 엔진인 것을 특징으로 하는 자동 재전송 요구 엔진.
제 1 항에 있어서,

상기 수신된 프레임 및 상기 복수 개의 블록 수신확인신호들의 식별정보는, MAC(Media Access Control) 어드레스 및 트래픽 ID를 포함하는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 4 항에 있어서,

상기 MAC 어드레스 하나 당 복수 개의 상기 트래픽 ID들이 대응되는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 4 항에 있어서,

상기 트래픽 ID는, 접속 가능한 단말의 최대 개수만큼 할당되는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 4 항에 있어서, 상기 자동 재전송 요구 정보 비교부는

상기 수신된 프레임의 상기 MAC 어드레스와 일치하는 MAC 어드레스 엔트리 번호를 검색하는 제 1 비교부; 그리고

제 1 비교부에서 일치하는 MAC 어드레스가 검출된 경우, 상기 수신된 프레임의 트래픽 ID 및 상기 MAC 어드레스 엔트리 번호와 일치하는 비트맵 엔트리를 검색하는 제 2 비교부를 포함하는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 7 항에 있어서,

상기 제 1 비교부는, 상기 복수 개의 블록 수신확인신호들에 대응되는 복수 개의 MAC 어드레스들을 저장하며,

상기 복수 개의 MAC 어드레스들은 상기 수신된 프레임의 MAC 어드레스와 비교되는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 7 항에 있어서,

상기 제 2 비교부는, 상기 복수 개의 블록 수신확인신호들에 대응되는 복수 개의 트래픽 ID들과 복수 개의 MAC 어드레스 엔트리 번호들을 저장하며,

상기 복수 개의 트래픽 ID들은 상기 수신된 프레임의 트래픽 ID와 비교되고, 상기 복수 개의 MAC 어드레스 엔트리 번호들은 상기 제 1 비교부로부터 입력된 상기 MAC 어드레스 엔트리 번호와 각각 비교되는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 7 항에 있어서,

상기 자동 재전송 요구 제어부는, 상기 제 2 비교부에서 상기 트래픽 ID 및 상기 MAC 어드레스 엔트리 번호와 일치하는 비트맵 엔트리가 검색되면, 상기 블록 수신확인신호를 발생하는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 10 항에 있어서,

상기 블록 수신확인신호는, 상기 복수 개의 프레임들에 대한 수신 확인을 위한 신호인 것을 특징으로 하는 자동 재전송 요구 엔진.
제 7 항에 있어서,

상기 자동 재전송 요구 제어부는, 상기 제 2 비교부에서 상기 트래픽 ID 및 상기 MAC 어드레스 엔트리 번호와 일치하는 비트맵 엔트리가 검색되지 않으면, 상기 수신확인신호(ACK)를 발생하는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 12 항에 있어서,

상기 수신확인신호(ACK)는, 상기 수신된 프레임에 대한 단순 회답신호인 것을 특징으로 하는 자동 재전송 요구 엔진.
제 13 항에 있어서,

상기 수신확인신호(ACK)가 발생된 후 소정 시간이 경과하면, 소프트웨어적에 의해서 상기 블록 수신확인신호가 발생되는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 2 항에 있어서, 상기 비트맵 관리부는,

상기 복수 개의 블록 수신확인신호들을 비트맵 형태로 저장한 비트맵 메모리;

상기 관리 정보들을 저장하고, 사용이 완료된 상기 비트맵 메모리의 실제 어드레스를 계산하는 비트맵 정보 관리부; 그리고

상기 자동 재전송 요구 제어부의 제어에 응답해서, 상기 비트맵 메모리 및 상기 비트맵 정보 관리부에 저장된 정보들에 대한 검색, 업데이트, 및 추출 동작을 제어하는 비트맵 제어부를 포함하는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 15 항에 있어서,

상기 비트맵 정보 관리부는, 협상되어 있는 프로토콜 데이터 유닛의 개수(Number of PDUs ; NOP), 상기 비트맵 메모리의 스타트 메모리 주소(Start Memory Address ; SMA), 및 프로토콜 데이터 유닛의 단편의 개수(Number Of Fragments ; NOF)를 저장하는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 16 항에 있어서,

상기 비트맵 정보 관리부는, 프로토콜 데이터 유닛의 단편의 개수(NOF) 및 상기 프로토콜 데이터 유닛의 개수(NOP)를 근거로 하여, 상기 비트맵 메모리의 스타트 메모리 주소(SMA)를 계산하는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 16 항에 있어서,

상기 비트맵 메모리는, 상기 블록 수신확인신호 및 상기 수신확인신호 중 어느 하나가 발생되었을 때, 현재 사용 중인 상기 비트맵 메모리의 메모리 영역 보다 낮은 메모리를 갖는 영역 중에 사용이 완료된 메모리 영역이 존재하면, 상기 사용이 완료된 영역으로 데이터를 옮기는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 18 항에 있어서,

상기 비트맵 메모리는 상기 옮겨진 메모리 영역의 어드레스에 응답해서 상기 스타트 메모리 주소(SMA)를 업데이트 하는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 15 항에 있어서,

상기 비트맵 메모리 및 상기 비트맵 정보 관리부에 저장된 상기 정보들에 대한 업데이트, 검색, 및 추출 동작은, 상기 블록 수신확인신호의 트랜젝션(transaction) 단위로 반복되는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 16 항에 있어서,

상기 비트맵 정보 관리부는, 스타트 웨이팅 플래그(Start Waiting Flag ; SWF), 상기 프레임들에 대한 스타트 시퀀스 번호(Start Sequence Number ; SSN)를 더 저장하는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 21 항에 있어서,

상기 비트맵 정보 관리부는, 상기 블록 수신확인신호의 상기 트랜젝션 구간이 시작될 때마다 상기 스타트 웨이팅 플래그(SWF)를 클리어하고, 상기 프레임들에 대한 스타트 시퀀스 번호(SSN)를 세팅하는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 1 항에 있어서,

상기 수신된 프레임은, 상기 블록 수신확인신호를 요청하는 프레임인 것을 특징으로 하는 자동 재전송 요구 엔진.
제 23 항에 있어서,

상기 자동 재전송 요구 제어부는, 상기 수신된 프레임이 상기 블록 수신확인신호이면, 현재 자신의 동작 상태가 상기 블록 수신확인신호를 요청한 후 상기 블록 수신확인신호를 기다리던 중이었는지 여부를 확인하고, 상기 동작 상태의 확인 결과에 따라 수신된 상기 블록 수신확인신호를 올바른 회신신호로서 인식하는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 23 항에 있어서,

상기 자동 재전송 요구 제어부는, 상기 수신된 프레임이 서비스 품질 데이터인 경우, 상기 수신된 프레임의 정책 정보가 상기 블록 수신확인신호를 제공하는 것으로 협상되어 있으면, 상기 수신된 프레임의 식별 정보와 상기 복수 개의 블록 수신확인신호들에 대한 식별 정보들을 비교하는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 25 항에 있어서,

상기 자동 재전송 요구 제어부는, 상기 비교 결과 상기 수신된 프레임의 식별 정보와 일치하는 상기 식별 정보가 존재하면, 해당 식별 정보에 대응되는 상기 블록 수신확인신호 및 상기 관리정보들을 업데이트하는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 1 항에 있어서,

상기 자동 재전송 요구 엔진은,

무선 네트워크에 연결된 적어도 하나 이상의 단말, 및 적어도 하나 이상의 중계기에 구비되는 것을 특징으로 하는 자동 재전송 요구 엔진.
제 27 항에 있어서,

상기 무선 네트워크는, 상기 단말과 단말의 접속, 상기 단말과 상기 중계기의 접속을 지원하는 것을 특징으로 하는 자동 재전송 요구 엔진.
복수 개의 프레임들에 대한 복수 개의 블록 수신확인신호들과, 상기 수신확인신호들에 대한 복수 개의 관리정보들을 저장하는 단계;

수신된 프레임의 식별 정보와 상기 복수 개의 블록 수신확인신호들에 대한 식별 정보들을 비교하여 상기 프레임의 처리 방식을 결정하는 단계; 그리고

상기 결정된 프레임의 처리 방식에 따라서 상기 블록 수신확인신호(BA) 및 수신확인신호(ACK) 중 어느 하나를 발생하는 단계를 포함하는 것을 특징으로 하는 자동 재전송 요구 방법.
제 29 항에 있어서,

상기 복수 개의 블록 수신확인신호들은 비트맵 형식으로 저장되는 것을 특징으로 하는 자동 재전송 요구 방법.
제 29 항에 있어서,

상기 프레임의 처리 방식을 결정하는 단계는, 무선 네트워크에서 보안 기능을 위해 제공되는 키 검색 엔진에서 수행되는 것을 특징으로 하는 자동 재전송 요구 방법.
제 29 항에 있어서,

상기 수신된 프레임 및 상기 복수 개의 수신확인신호들의 식별정보는, MAC(Media Access Control) 어드레스 및 트래픽 ID를 포함하는 것을 특징으로 하는 자동 재전송 요구 방법.
제 32 항에 있어서,

상기 MAC 어드레스 하나 당 복수 개의 상기 트래픽 ID들이 대응되는 것을 특징으로 하는 자동 재전송 요구 방법.
제 32 항에 있어서,

상기 트래픽 ID는, 접속 가능한 단말의 최대 개수만큼 할당되는 것을 특징으로 하는 자동 재전송 요구 방법.
제 32 항에 있어서, 상기 프레임의 처리 방식을 결정하는 단계는

상기 수신된 프레임의 상기 MAC 어드레스와 일치하는 MAC 어드레스 엔트리 번호를 검색하는 단계; 그리고

상기 수신된 프레임의 상기 MAC 어드레스와 일치하는 MAC 어드레스가 검출된 경우, 상기 수신된 프레임의 트래픽 ID 및 상기 MAC 어드레스 엔트리 번호와 일치하는 비트맵 엔트리를 검색하는 단계를 포함하는 것을 특징으로 하는 자동 재전송 요구 방법.
제 35 항에 있어서,

상기 MAC 어드레스와, 상기 트래픽 ID 및 상기 MAC 어드레스 엔트리 번호가 일치하는 비트맵 엔트리가 검색되면, 상기 블록 수신확인신호를 발생하는 단계를 더 포함하는 것을 특징으로 하는 자동 재전송 요구 방법.
제 36 항에 있어서,

상기 블록 수신확인신호는, 복수 개의 수신된 프레임들에 대한 수신 확인을 위한 신호인 것을 특징으로 하는 자동 재전송 요구 방법.
제 35 항에 있어서,

상기 MAC 어드레스와, 상기 트래픽 ID 및 상기 MAC 어드레스 엔트리 번호와 일치하는 비트맵 엔트리가 검색되지 않으면, 상기 수신확인신호가 발생되는 것을 특징으로 하는 자동 재전송 요구 방법.
제 38 항에 있어서,

상기 수신확인신호는, 상기 수신된 프레임에 대한 단순 회답신호인 것을 특징으로 하는 자동 재전송 요구 방법.
제 39 항에 있어서,

상기 수신확인신호가 발생된 후 소정 시간이 경과하면, 소프트웨어적으로 상기 블록 수신확인신호를 발생히는 단계를 더 포함하는 것을 특징으로 하는 자동 재전송 요구 방법.
제 30 항에 있어서,

상기 블록 수신확인신호들과 상기 관리정보들을 저장하는 단계에서는, 상기 블록 수신확인신호들은 비트맵 메모리에 저장되고, 상기 관리 정보들을 비트맵 정보 관리부에 각각 저장되는 것을 특징으로 하는 자동 재전송 요구 방법.
제 41 항에 있어서,

상기 블록 수신확인신호들과 상기 관리정보들을 저장하는 단계는, 상기 결정된 프레임의 처리 방식에 따라, 상기 비트맵 메모리 및 상기 비트맵 정보 관리부에 저장된 정보들에 대한 검색, 업데이트, 및 추출 동작을 제어하는 단계를 포함하는 것을 특징으로 하는 자동 재전송 요구 방법.
제 42 항에 있어서,

상기 비트맵 정보 관리부에는, 협상되어 있는 프로토콜 데이터 유닛의 개수(Number of PDUs ; NOP), 상기 비트맵 메모리의 스타트 메모리 주소(Start Memory Address ; SMA), 및 프로토콜 데이터 유닛의 단편의 개수(Number Of Fragments ; NOF)가 저장되는 것을 특징으로 하는 자동 재전송 요구 방법.
제 43 항에 있어서,

상기 비트맵 메모리 및 상기 비트맵 정보 관리부에 저장된 정보들에 대한 검색, 업데이트, 및 추출 동작을 제어하는 단계에서는, 프로토콜 데이터 유닛의 단편의 개수(NOF) 및 상기 프로토콜 데이터 유닛의 개수(NOP)를 근거로 하여, 상기 비트맵 메모리의 스타트 메모리 주소(SMA)가 계산되는 것을 특징으로 하는 자동 재전 송 요구 방법.
제 43 항에 있어서,

상기 비트맵 메모리 및 상기 비트맵 정보 관리부에 저장된 정보들에 대한 검색, 업데이트, 및 추출 동작을 제어하는 단계에서는, 상기 블록 수신확인신호 및 상기 수신확인신호 중 어느 하나가 발생되었을 때, 현재 사용 중인 상기 비트맵 메모리의 메모리 영역 보다 낮은 메모리를 갖는 영역 중에 사용이 완료된 메모리 영역이 존재하면, 상기 사용이 완료된 영역으로 데이터가 옮겨지는 것을 특징으로 하는 자동 재전송 요구 방법.
제 45 항에 있어서,

상기 비트맵 메모리 및 상기 비트맵 정보 관리부에 저장된 정보들에 대한 검색, 업데이트, 및 추출 동작을 제어하는 단계에서는, 상기 옮겨진 메모리 영역의 어드레스에 응답해서 상기 스타트 메모리 주소(SMA)가 업데이트 되는 것을 특징으로 하는 자동 재전송 요구 방법.
제 42 항에 있어서,

상기 비트맵 메모리 및 상기 비트맵 정보 관리부에 저장된 정보들에 대한 검색, 업데이트, 및 추출 동작을 제어하는 단계는, 상기 블록 수신확인신호의 트랜젝션(transaction) 단위로 반복되는 것을 특징으로 하는 자동 재전송 요구 방법.
제 42 항에 있어서,

상기 비트맵 정보 관리부에는, 스타트 웨이팅 플래그(Start Waiting Flag ; SWF), 상기 프레임들에 대한 스타트 시퀀스 번호(Start Sequence Number ; SSN)가 더 저장되는 것을 특징으로 하는 자동 재전송 요구 방법.
제 48 항에 있어서,

상기 비트맵 메모리 및 상기 비트맵 정보 관리부에 저장된 정보들에 대한 검색, 업데이트, 및 추출 동작을 제어하는 단계에서는, 상기 블록수신확인신호의 트랜젝션 구간이 시작될 때마다 상기 스타트 웨이팅 플래그(SWF)가 클리어되고, 상기 프레임들에 대한 스타트 시퀀스 번호(SSN)가 세팅되는 것을 특징으로 하는 자동 재전송 요구 방법.
제 29 항에 있어서,

상기 수신된 프레임은, 상기 블록 수신확인신호를 요청하는 프레임인 것을 특징으로 하는 자동 재전송 요구 방법.
제 50 항에 있어서,

상기 수신된 프레임이 상기 블록 수신확인신호이면, 현재 자신의 동작 상태가 상기 블록 수신확인신호를 요청한 후 상기 블록 수신확인신호를 기다리던 중이었는지 여부를 확인하고, 상기 동작 상태의 확인 결과에 따라 상기 수신된 블록 수신확인신호를 올바른 회신신호로서 인식하는 단계를 더 포함하는 것을 특징으로 하는 자동 재전송 요구 방법.
제 50 항에 있어서,

상기 수신된 프레임이 서비스 품질 데이터인 경우, 상기 수신된 프레임의 정책 정보가 상기 블록수신확인신호를 제공하는 것으로 협상되어 있으면, 상기 수신된 프레임의 식별 정보와 상기 복수 개의 블록 수신확인신호들에 대한 식별 정보들을 비교하는 단계를 더 포함하는 것을 특징으로 하는 자동 재전송 요구 방법.
제 52 항에 있어서,

상기 수신된 프레임이 서비스 품질 데이터일 때 수행된 상기 비교 결과, 상기 수신된 프레임의 식별 정보와 일치하는 상기 식별 정보가 존재하면, 해당 식별 정보에 대응되는 상기 블록 수신확인신호 및 상기 관리정보들을 업데이트 하는 단계를 더 포함하는 것을 특징으로 하는 자동 재전송 요구 방법.
제 29 항에 있어서,

상기 자동 재전송 요구 방법은,

무선 네트워크에 연결된 적어도 하나 이상의 단말, 및 적어도 하나 이상의 중계기에서 수행되는 것을 특징으로 하는 자동 재전송 요구 방법.
제 54 항에 있어서,

상기 무선 네트워크는, 상기 단말과 단말의 접속, 상기 단말과 상기 중계기의 접속을 지원하는 것을 특징으로 하는 자동 재전송 요구 방법.
수신된 프레임의 종류를 분석하는 단계;

상기 분석된 프레임의 종류에 따라서, 상기 프레임의 식별정보와 비트맵 형식으로 저장된 복수 개의 블록 수신확인신호들에 대한 식별 정보들에 대한 비교를 선택적으로 수행하는 단계; 그리고

상기 비교 결과에 따라 상기 수신된 프레임에 대한 처리 방식을 결정하는 것을 특징으로 하는 자동 재전송 요구 엔진의 제어 방법.
제 56 항에 있어서,

상기 수신된 프레임의 종류가 상기 블록 수신확인신호를 요청하는 프레임이면, 상기 프레임의 식별 정보와 상기 복수 개의 블록 수신확인신호들에 대한 식별 정보들을 비교하여 상기 프레임에 대한 회답 방식을 결정하는 단계; 그리고

상기 결정된 프레임의 회답 방식에 따라, 상기 수신확인신호들과 상기 관리정보들을 선택적으로 추출하여, 블록 수신확인신호(BA) 및 수신확인신호(ACK) 중 어느 하나를 발생하는 단계를 포함하는 것을 특징으로 하는 자동 재전송 요구 엔진의 제어 방법.
제 56 항에 있어서,

상기 수신된 프레임의 종류가 상기 블록 수신확인신호이면, 현재 자신의 동작 상태가 상기 블록 수신확인신호를 요청한 후 상기 블록 수신확인신호를 기다리던 중이었는지 여부를 확인하는 단계; 그리고

상기 동작 상태의 확인 결과에 따라 상기 수신된 블록 수신확인신호를 올바른 회신신호로서 인식하는 단계를 포함하는 것을 특징으로 하는 자동 재전송 요구 엔진의 제어방법.
제 56 항에 있어서,

상기 수신된 프레임의 종류가 서비스 품질 데이터이면, 식별 정보와 상기 복수 개의 수신확인신호들에 대한 식별 정보들을 비교하는 단계; 그리고

상기 비교 결과, 상기 수신된 프레임의 식별 정보와 일치하는 상기 식별 정보가 존재하면, 해당 식별 정보에 대응되는 상기 수신확인신호 및 상기 관리정보들을 업데이트 하는 단계를 포함하는 것을 특징으로 하는 자동 재전송 요구 엔진의 제어 방법.
제 56 항에 있어서,

상기 식별 정보들을 비교하는 단계는, 무선 네트워크에서 보안 기능을 위해 제공되는 키 검색 엔진에서 수행되는 것을 특징으로 하는 자동 재전송 요구 엔진의 제어 방법.
제 56 항 또는 제 57 항에 있어서,

상기 수신된 프레임 및 상기 복수 개의 수신확인신호들의 식별정보는, MAC(Media Access Control) 어드레스 및 트래픽 ID를 포함하는 것을 특징으로 하는 자동 재전송 요구 엔진의 제어 방법.
제 61 항에 있어서,

상기 MAC 어드레스 하나 당 복수 개의 상기 트래픽 ID들이 대응되는 것을 특징으로 하는 자동 재전송 요구 엔진의 제어 방법.
제 61 항에 있어서,

상기 트래픽 ID는, 접속 가능한 단말의 최대 개수만큼 할당되는 것을 특징으로 하는 자동 재전송 요구 엔진의 제어 방법.
제 61 항에 있어서, 상기 식별 정보들을 비교하는 단계는

상기 수신된 프레임의 상기 MAC 어드레스와 일치하는 MAC 어드레스 엔트리 번호를 검색하는 단계; 그리고

상기 수신된 프레임의 상기 MAC 어드레스와 일치하는 MAC 어드레스가 검출된 경우, 상기 수신된 프레임의 트래픽 ID 및 상기 MAC 어드레스 엔트리 번호와 일치하는 비트맵 엔트리를 검색하는 단계를 포함하는 것을 특징으로 하는 자동 재전송 요구 엔진의 제어 방법.
제 64 항에 있어서,

상기 MAC 어드레스와, 상기 트래픽 ID 및 상기 MAC 어드레스 엔트리 번호가 일치하는 비트맵 엔트리가 검색되면, 상기 블록 수신확인신호가 발생되는 것을 특징으로 하는 자동 재전송 요구 엔진의 제어 방법.
제 65 항에 있어서,

상기 블록 수신확인신호는, 상기 복수 개의 프레임들에 대한 수신확인을 위한 신호인 것을 특징으로 하는 자동 재전송 요구 엔진의 제어 방법.
제 64 항에 있어서,

상기 MAC 어드레스와, 상기 트래픽 ID 및 상기 MAC 어드레스 엔트리 번호와 일치하는 비트맵 엔트리가 검색되지 않으면, 상기 수신확인신호가 발생되는 것을 특징으로 하는 자동 재전송 요구 엔진의 제어 방법.
제 67 항에 있어서,

상기 수신확인신호는, 상기 수신된 프레임에 대한 단순 회답신호인 것을 특징으로 하는 자동 재전송 요구 엔진의 제어 방법.
제 68 항에 있어서,

상기 수신확인신호가 발생된 후 소정 시간이 경과하면, 소프트웨어적으로 상기 복수 개의 블록 수신확인신호들을 발생하는 단계를 더 포함하는 것을 특징으로 하는 자동 재전송 요구 엔진의 제어 방법.