KR20040053278A - 헤더 압축한 무선 통신 장치들 - Google Patents

헤더 압축한 무선 통신 장치들 Download PDF

Info

Publication number
KR20040053278A
KR20040053278A KR10-2004-7006777A KR20047006777A KR20040053278A KR 20040053278 A KR20040053278 A KR 20040053278A KR 20047006777 A KR20047006777 A KR 20047006777A KR 20040053278 A KR20040053278 A KR 20040053278A
Authority
KR
South Korea
Prior art keywords
packet
protocol
packets
header
encapsulated
Prior art date
Application number
KR10-2004-7006777A
Other languages
English (en)
Inventor
멜피그나노디에고
Original Assignee
코닌클리케 필립스 일렉트로닉스 엔.브이.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 코닌클리케 필립스 일렉트로닉스 엔.브이. filed Critical 코닌클리케 필립스 일렉트로닉스 엔.브이.
Publication of KR20040053278A publication Critical patent/KR20040053278A/ko

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/04—Interfaces between hierarchically different network devices
    • H04W92/10—Interfaces between hierarchically different network devices between terminal device and access point, i.e. wireless air interface

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Abstract

제 1 유닛 AP와 제 2 유닛 MT 사이의 무선 전송을 위한 방법이 개시되어 있다. 상기 방법은, 실시간 비트스트림(예를 들어, VoIP, 오디오 및 비디오)을 미리 결정된 최대 길이의 하나 이상의 페이로드들로 변환하는 유닛 AP, MT을 포함한다. 하나 이상의 미리 규정된 헤더들(RTP/UDP/IP)은 미리 규정된 통신 프로토콜에 따라 상기 유닛들 AP, MT 사이의 전송에 적합한 패킷들을 발생하기 위하여 상기 페이로드 또는 각각의 상기 페이로드에 적용한다. 그다음, 각 패킷은 유닛들 MT, AP 사이의 무선 접속을 가로질러 각 패킷을 전송하도록 적응된 캡슐화 프로토콜(BNEP)의 프레임 내에서 캡슐화된다. 그다음, 미리 규정된 헤더 압축 기술(IETF ROHC)은 각 캡슐화된 패킷에 적용된다.

Description

헤더 압축한 무선 통신 장치들{Wireless communication arrangements with header compression}
무선 유닛들, 및 무선 유닛들을 공유 자원 네트워크로 적어도 일시적으로 그룹화하는데 이용된 접속들에 기초한 무선 통신 시스템들이 공지되어 있다. 이러한 전형적인 타입의 한 현행 구현은 단거리, 주파수-홉핑 네트워크의 타입이며, 본 기술 분야에서 BluetoothTM통신으로 공지되어 있다. 이러한 장치는 BluetoothTM표준에 의해 제어되며, BluetoothTM통신의 적합성에 대한 완전한 사양은 BluetoothTM특수 이익 집단(SIG : Special Interests Group)을 통해 발견될 수 있으며, 그 웹사이트는 현행 BluetoothTM표준 및 관련 정보와 함께 "www.bluetooth.com"에서 발견될 수 있다.
BluetoothTM통신의 유용한 논의는 ISBN 0-13-089840-6하에 Prentice Hall PTR에 의해 출판되고, 저자가 Jennifer Bray 및 Charles F.Sturman인 "BluetoothTM, 무선 접속"의 교과서 형태로 발견될 수 있다.
예를 들어, 제 WO 01/20940호, 제 US 5940431호, 및 미국 공개 출원들 제 2001/0005368A1호 및 제 2001/0033601A1호에서 다른 종래 기술들이 발견될 수 있으며, 본 분야의 기술의 현행 상태의 일부 측면들도 개시되어 있다.
독자는 일반 BluetoothTM배경 정보와, 예를 들어 본 명세서에 이용되었지만 특별히 규정되지 않은 용어들의 설명에 대한에 대해서는 상술된 소스들을 참조한다.
BluetoothTM네트워크의 각 액세스점은 예를 들어, 이동 전자 통신 핸드세트들과 같은 하나 이상의 이동 단말기들과 BluetoothTM피코넷(piconet)을 형성한다. 이러한 BluetoothTMPAN은 VoIP(Voice-over-Internet-Protocol) 흐름들뿐만 아니라 다른 타입들의 IP 트래픽을 전달할 수 있다. 많은 핸드세트들(또는 다른 단말기들)이 동일한 액세스점에 부착할 수 있기 때문에, 한정된 이용 가능한 대역폭(피코넷 당 1Mbps의 총 집합체 용량)의 이용 효율을 최대화하는 것이 중요함을 알 수 있다.
BluetoothTM에 대한 최근 애플리케이션은 인터넷 상뿐만 아니라 기업 네트워크들/인트라넷들에 배치되고 있는 보이스 오버 인터넷 프로토콜(VoIP)의 전달이다.후자의 경우, VoIP의 주장점은 데이터에 통상적으로 이용된 기존 네트워크 인트라구조가 음성 트래픽에 의해 이용된다는 점이다. 그러나, VoIP 트래픽이 한정된 대역폭의 무선 링크를 통해 전달되어야 할 때에는, VoIP 흐름들이 지연 민감하고, 상당한 헤더 오버헤드들을 보이기 때문에, 대역폭 낭비를 최소화하는 것이 중요하다.
도 1에 도시된 아키텍처는 이동 단말기들의 그룹 MT1-n중 한 MT1은 인트라넷과 같은 기업 네트워크 내부에 VoIP 접속들을 설립함으로써, 코드 없는 전화 핸드세트로서 동작할 수 있고 내장된 IP 스택을 갖는 BluetoothTM사용 가능 제 3 세대(3G) 이동 전화를 포함한다. 이동 핸드세트 MT1은, 예를 들어 하나 이상의 다른 핸드세트들 MTn과 보이스-오버-IP(VoIP) 접속을 확립하기 위하여, 인트라넷에서 액세스점들의 세트 AP1...n을 이용하며, 보이스-오버-IP(VoIP) 접속은 인트라넷내 또는 전화 네트워크에 대한 전용 게이트웨이(PABX/VoIP GW)를 통해서 이루어질 수 있다.
VoIP 패러다임에 따라, 음성 샘플들은 이용되는 음성 코더에 길이가 의존하는 패킷들로 압축된다. 그러한 페이로드 길이는 대화중 긴 지연들을 도입하는 것을 회피하기 위해 제한되어야 한다. GSM 품질을 위해, 20바이트의 음성 패킷들을 생성하는 5.3kb/s의 G;723.1 코더가 이용될 수 있다. 이러한 페이로드는 12 바이트 헤더를 도입하는 실시간 프로토콜(RTP)을 이용하여 타임스탬프되고, 결과로서 생긴 세그먼트는 그 자신의 다른 8 바이트 헤더를 부가한 UDP 데이터그램으로 전달된다. RTP는 시간 동기화를 위한 편의들을 제공하고, UDP는 여러 개의 스트림이 접속 없는 논리적 채널로 함께 다중화되도록 허용한다. 이러한 RTP/UDP 패킷은 그다음, 20 바이트 IP 헤더를 부가하는 IP 데이터그램으로 캡슐화된다. IP 버전 6(IPv6)이 이용되는 경우에는, IP 헤더가 20바이트에서 40 바이트로 증가하여, 단 20바이트의 페이로드에 대해 60 바이트의 잠재적 전체 헤더를 제공하기 때문에 상황이 더 나빠질 수도 있다. 이러한 대역폭 활용의 저 효율성은 VoIP 패킷들이 유선 LAN을 통해 전달될 때에는 중요한 문제가 되지 않지만, 무선 LAN이 대신 이용될 때에는 심각한 제한들을 야기할 수 있다.
BluetoothTM통신의 특별한 경우로, 개인 영역 네트워크(PAN : Personal Area Network) 작업 그룹은 IP 오버 BluetoothTM를 표준화하고, 이러한 목적으로, "BluetoothTM네트워크 캡슐화 프로토콜"(BNEP : BluetoothTMNetwork Encapsulation Protocol)라 명명된 새로운 프로토콜을 개발하었다. 이러한 프로토콜은, BluetoothTM매체들을 통해 공통 네트워킹 프로토콜들을 전송하기 위해 이용되는 BluetoothTM네트워크 캡슐화를 위한 패킷 포맷을 규정한다. BNEP는 IP 데이터그램들이 이더넷 프레임들로 캡슐화되어 아래의 L2CAP층에 전송되도록 하는 이더넷 에뮬레이션을 BluetoothTM에 제공한다. 이더넷 에뮬레이션층을 도입함으로써, 예를 들어 네트워크 액세스점들에서 또는 BluetoothTMad-hoc 네트워크들에서 브로드캐스팅, 멀티캐스팅 및 제 2 층 브리징 기능들을 구현하는 것이 가능하다. BNEP의 전체세부 사항들은 BluetoothTMSIG 및 상기 관련된 웹사이트를 통해 얻어질 수 있다.
그러나, BNEP는 매우 유연하지만, 그 자신의 헤더 압축 메커니즘에도 불구하고 큰 오버헤드를 도입한다. 더 높은 층 프로토콜들의 오버헤드에 BNEP를 합산하면, 어떤 애플리케이션들에 대해 상당한 대역폭의 낭비를 유발할 수 있다. 예를 들어, 상기 논의된 VoIP 애플리케이션의 경우에, BNEP를 이용하여 RTP/UDP/IP 패킷들을 캡슐화하면, 이미 긴 헤더에 3 내지 15바이트 이상을 부가하게 되고, 따라서20바이트 페이로드에 대해 최소 (12+8+20+3=43)에서 최대 가능한 (12+8+40+15=75) 바이트들의 전체 헤더를 유발한다. 다른 타입의 IP 트래픽, 예를 들면 오디오 및/또는 비디오 신호들과 같은 매체들에 유사한 고려들이 적용된다. 후자의 경우, 오디오/비주얼 애플리케이션들에 의해 발생된 패킷들은 VoIP 패킷들보다 더 클 수 있지만, 여전히, 헤더 오버헤드들을 최소화하는 것이 중요하다. 실제로, 블루투스 시스템이 이용될 때, 오디오/비주얼 코더가 L2CAP 프레임에 일대일 맵핑될 수 있는 패킷들을 발생하는 것이 보통이다. 이것은 보다 양호한 재전송 제어를 허용하고, 유용한 패킷 수명이 만료될 때마다 보다 양호한 플러싱(flushing)을 쉽게 한다. 헤더 치수가 최소화되면, 기저대역 패킷의 유용한 페이로드가 주어지고, 실제의 오디오/비주얼 페이로드에 대해 더 큰 대역폭이 예약된다.
본 발명은 무선 압축 장치들과 이들을 작동시키는 방법들에 관한 것이며, 특히, 패킷-기반 무선 통신 장치와, 헤더 압축이 이용된 상기 무선 통신 장치를 작동시키는 방법에 관한 것이다. 또한, 본 발명은 통신 유닛들과 그러한 장치들에 이용된 소프트웨어 제품들에 관한 것이다.
도 1은 통신 시스템의 개략도.
도 2는 도 1에 따른 시스템에서 이용하기에 적당한, 본 발명의 실시예에 따른 통신 유닛에 대한 프로토콜 스택.
도 3은 도 2의 통신 유닛에 대한 네트워크 구성의 흐름도.
도 4a는 본 발명을 구현하는데 이용되는 헤더 압축기의 흐름도.
도 4b는 본 발명을 구현하는데 이용되는 헤더 압축 해제기의 흐름도.
도 5는 본 발명의 실시예의 기능도.
도 6a는 헤더 압축 및 압축 해제 체인의 개략도.
도 6b는 압축기 상태들의 블록도.
도 6c는 압축 해제기 상태들의 블록도.
도 7은 도 4a의 헤더 압축기에 대한 상태 머신.
본 발명의 목적은 개선된 무선 통신 장치들 및 상기 장치들을 작동시키는 개선된 방법들을 제공하는 것이다. 또한, 본 발명의 목적은 개선된 패킷-기반 무선통신 장치와, 헤더 압축이 이용된 상기 무선 통신 장치를 작동시키는 개선된 방법을 제공하는 것이다. 또한, 본 발명의 목적은 개선된 통신 유닛들과 그러한 개선된 통신 장치들 및 방법들에 연관되어 이용된 소프트웨어 제품들을 제공하는 것이다. 이러한 방법에서 본 발명의 특정 목적은, BluetoothTM개인 영역 네트워크의 VoIP, 오디오 및/또는 비디오와 같은 인터넷 프로토콜(IP) 비트스트림들에 RTP/UDP/IP/BNEP 헤더들로 인한 감소된 오버헤드를 제공하는 것이다.
따라서, 본 발명은, 제 1 유닛과 제 2 유닛 사이의 패킷-기반 무선 전송 방법을 제공하며, 상기 방법은:
a) 실시간 비트스트림을 미리 결정된 최대 길이의 하나 이상의 페이로드들로 변환하고;
b) 미리 규정된 통신 프로토콜에 따라 상기 유닛들 사이의 전송에 적합한 패킷들을 발생하기 위하여 하나 이상의 미리 규정된 헤더들을 페이로드 또는 각각의 상기 페이로드에 적용하고;
c) 상기 유닛들 사이의 무선 접속을 가로질러 상기 패킷 또는 각각의 상기 패킷을 전송하도록 적응된 캡슐화 프로토콜의 프레임 내에서 상기 패킷 또는 각각의 상기 패킷을 캡슐화하고; 및
d) 미리 규정된 헤더 압축 기술을 상기 캡슐화된 패킷 또는 각각의 상기 캡슐화된 패킷에 적용하는 상기 유닛을 포함한다.
상기 방법은, 보이스-오버-인터넷-프로토콜(VoIP), 오디오 또는 비주얼 스트림들과 같은 인터넷 프로토콜(IP) 트래픽을 포함하는 상기 실시간 비트스트림으로부터 페이로드 또는 각각의 상기 페이로드를 발생하는 단계를 포함할 수 있다.
상기 방법은, 상기 제 1 및 제 2 유닛들 사이의 서비스 복구 절차를 수행하는 단계와, 상기 서비스 복구 절차동안 상기 헤더 비교 기술을 통고(advertise)하는 단계를 포함할 수 있다.
상기 방법은, 압축된 비트스트림을 전달하기 위해, 상기 미리 규정된 통신 프로토콜의 세그먼테이션, 재조립 및 다중화 서비스들 중 하나 이상을 구성하는 단계를 포함할 수 있다.
상기 방법은, 상기 헤더 압축 기술을 적용하도록 적응된 압축기 및 압축 해제기의 컨텍스트에 캡슐화 프로토콜 정보를 부가함으로써 상기 헤더 압축을 적용하는 단계를 포함할 수 있고, 상기 정보는 예를 들어 상기 캡슐화 프로토콜의 스태틱 헤더 필드들을 포함할 수 있다.
상기 유닛은 BluetoothTM네트워크의 일부를 포함할 수 있고, 상기 방법은 BluetoothTM네트워크 캡슐화 프로토콜(BNEP)을 포함하는 캡슐화 프로토콜을 이용하여 상기 패킷 또는 각각의 상기 패킷을 캡슐화하는 단계를 포함할 수 있다.
상기 방법은, 바람직하게 상기 미리 결정된 헤더들 및 BNEP 헤더의 조합을 예를 들어 3 바이트의 미리 결정된 길이로 줄임(shrink)으로써, 상기 헤더 압축 기술을 이용하여 상기 캡슐화된 패킷 또는 각각의 상기 캡슐화된 패킷을 단일 슬롯 BluetoothTM기저대역 패킷으로 압축하는 단계를 포함할 수 있다.
상기 방법은, 인터넷 엔지니어링 태스크 포스(IETF : Internet Engineering Task Force)에 의해 승인된 ROHC와 같은, 로버스트 헤더 압축(ROHC : Robust Header Compression) 프레임워크의 형태로 상기 헤더 압축 기술을 적용하는 단계를 포함할 수 있다.
상기 방법은:
a) 상기 패킷들에 대한 실시간 프로토콜(RTP : Real Time Protocol)을 이용하는 단계;
b) IETF ROHC 양방향 낙관적 방식(optimistic approach; o-모드)을 이용하는 단계;
c) 널 R-CID가 디폴트인, 작은 ROHC 컨텍스트 식별자들(R-CID : ROHC Context Identifiers)를 이용하는 단계;
d) 일반 데이터그램 프로토콜(UDP) 첵섬을 전송하지 않고, 압축 해제기에서 UDP 첵섬을 선택적으로 재계산하는 단계;
e) 임의의 한 패킷 흐름 동안, 상기 전체 캡슐화 프로토콜 헤더를 스태틱 컨텍스트의 일부로서 고려하는 단계;
f) 실시간 프로토콜(RTP) 시퀀스 번호 및/또는 인터넷 프로토콜 식별만을 전송하는 단계;
g) 압축기에서 "초기화 및 리프레시"(IR : Initialization and Refresh), "1 차"(FO : First Order) 및 "2 차"(SO : Second Order) 상태들 사이의 전이와, 압축 해제기에서 "컨텍스트 없음"(NC : No Context), "스태틱 컨텍스트"(SC) 및 "전체컨텍스트"(FC : Full Context) 상태들 사이의 전이를 규정하는 단계 중 하나 이상을 포함할 수 있다.
상기 방법은, 미리 결정된 상기 프레임들만이 상기 헤더 압축 기술을 이용하여 압축되도록 캡슐화 프레임들을 분류하는 단계를 포함할 수 있다.
상기 방법은, 실시간 프로토콜(RTP), 일반 데이터그램 프로토콜(UDP) 및 인터넷 프로토콜(IP) 중 하나 이상에 따라 헤더들을 상기 페이로드에 적용하는 단계를 포함할 수 있다.
상기 방법은, 채널들간 통신하기 위해 복수의 논리적 채널들을 구성하는 상기 유닛들을 포함할 수 있고, 적어도 하나의 상기 채널은 상기 압축된 캡슐화된 패킷들의 전송에 전용이다.
상기 방법은, 상기 헤더 압축 기술을 윈도우-최하위 비트 코딩(W-LSB : Window-Least Significant Bit coding)에 기초하는 단계를 포함할 수 있다.
상기 방법은, 에러 복구 요청들 및 선택적으로, 컨텍스트 갱신들의 확인 응답들(acknowledgement)을 위해 적응된 상기 유닛들 사이에 피드백 채널을 제공함으로써, 압축기 및 압축 해제기 상태들 사이의 스위칭을 관리하는 단계를 포함할 수 있다.
상기 방법은, 기저대역 패킷들로 세그먼트된 상기 압축된 캡슐화된 프레임들을 연속으로 수신하고, 다음 상기 패킷이 전송되기 전에 각각의 상기 패킷을 긍정적으로 확인 응답하는 상기 유닛을 포함할 수 있고, 최종 상기 패킷 또는 확인 응답 메시지에서 전송 에러가 발생하는 경우에, 상기 최종 패킷은 재전송된다.
상기 방법은:
a) 기저대역 패킷 액세스 코드가 수신되지 않은 경우;
b) 정정할 수 없는 에러가 기저대역 패킷 헤더 내에 존재하는 경우;
c) 정정할 수 없는 에러가 상기 패킷의 상기 페이로드 내에 존재하는 경우 중 적어도 한 경우에 상기 패킷을 재전송하는 단계를 포함할 수 있다.
상기 방법은, 예를 들어 상기 프레임의 성공적인 전달을 위해, 타임아웃을 설정함으로써 상기 압축된 캡슐화된 프레임에 대한 다수의 재전송들을 한정하는 단계를 포함할 수 있다.
또한, 본 발명은 제 1 유닛과 제 2 유닛 사이의 패킷-기반 무선 전송을 실행하는 소프트웨어 제품을 제공하며, 상기 제품은:
a) 실시간 비트스트림을 미리 결정된 최대 길이의 하나 이상의 페이로드들로 변환하고;
b) 미리 규정된 통신 프로토콜에 따라 상기 유닛들 사이의 전송에 적합한 패킷들을 발생하기 위하여 하나 이상의 미리 규정된 헤더들을 페이로드 또는 각각의 상기 페이로드에 적용하고;
c) 상기 유닛들 사이의 무선 접속을 가로질러 상기 패킷 또는 각각의 상기 패킷을 전송하도록 적응된 캡슐화 프로토콜의 프레임 내에서 상기 패킷 또는 각각의 상기 패킷을 캡슐화하고; 및
d) 미리 규정된 헤더 압축 기술을 상기 캡슐화된 패킷 또는 각각의 상기 캡슐화된 패킷에 적용하기 위한 코드를 포함한다.
상기 소프트웨어 제품은 상기 통신 유닛의 일부를 형성하기 위해 BluetoothTM네트워크 인터페이스 소프트웨어 드라이버와 연관되어 실행될 수 있다.
또한, 본 발명은 실질적으로 실시간으로 제 2 유닛에 정보를 전달하도록 적응된 제 1 유닛을 포함하는 패킷 기반 무선 통신 장치를 제공하며, 상기 제 1 유닛은:
a) 실시간 비트스트림을 미리 결정된 최대 길이의 하나 이상의 페이로드들로 변환하고;
b) 미리 규정된 통신 프로토콜에 따라 상기 유닛들 사이의 전송에 적합한 패킷들을 발생하기 위하여 하나 이상의 미리 규정된 헤더들을 페이로드 또는 각각의 상기 페이로드에 적용하고;
c) 상기 유닛들 사이의 무선 접속을 가로질러 상기 패킷 또는 각각의 상기 패킷을 전송하도록 적응된 캡슐화 프로토콜의 프레임 내에서 상기 패킷 또는 각각의 상기 패킷을 캡슐화하고; 및
d) 미리 규정된 헤더 압축 기술을 상기 캡슐화된 패킷 또는 각각의 상기 캡슐화된 패킷에 적용하도록 적응된다.
상기 제 1 유닛은 BluetoothTM프로토콜에 따라 동작할 수 있고, 상기 캡슐화된 프로토콜은 바람직하게, 블루투스 네트워크 캡슐화 프로토콜(BNEP)을 포함하며, 상기 헤더 압축 기술은 바람직하게, 인터넷 엔지니어링 태스크 포스(IETF), 로버스트 헤더 압축(ROHC) 기술과 양립할 수 있다.
또한, 본 발명은 본 발명에 따른 방법에 따라 동작하도록 적응된 통신 유닛을 제공하며, 상기 유닛은 바람직하게, 액세스점 또는 이동 단말기와 같이, 블루투스 네트워크의 마스터 유닛 또는 슬레이브 유닛을 포함한다. 캡슐화된 패킷들의 헤더 압축 및/또는 압축 해제는 상기 통신 유닛과 연관된 BluetoothTM네트워크 인터페이스 소프트웨어 드라이버로 실행되는 소프트웨어 제품의 타입으로 구현될 수 있다. 이러한 소프트웨어 제품은 블루투스 네트워크 캡슐화 프로토콜(BNEP) 및 논리적 링크 제어 및 적응 프로토콜(L2CAP)층들, 프레임 분류기, 로버스트 헤더 압축(ROHC) 코덱 및 조정을 위한 관리 엔티티(ME)를 포함할 수 있다. 관리 엔티티는 호스트 제어기 인터페이스(HCI : Host Controller Interface)를 통해 BluetoothTM기저대역과 통신할 수 있고, 또한, 오퍼레이팅 시스템 특정 메커니즘들에 의해 상위 프로토콜층들과 통신할 수 있다. 예를 들어 이동 단말기 MT1-n로서 구체화된 슬레이브 통신 유닛이 예를 들어 액세스점 AP1-n으로서 구체화된 마스터 유닛에 접속할 때마다, 관리 엔티티는 그 매체 액세스 어드레스(MAC)를 등록할 수 있고, 상기 슬레이브 유닛에 대한 논리적 채널을 구성할 수 있다.
본 발명은 특정 실시예들을 참조하고 상술된 도면들을 참조하여 설명될 것이다. 그러한 설명은 단지 예의 방식이며, 본 발명이 이에 한정되지 않는다. 특히, 통신 시스템들에 기초한 패킷들 및 패킷에 대한 참조가 이루어질 것이다. 당업자는 본 발명이 패킷 스위칭된 시스템들에 한정되지 않지만, 전송 데이터를 위해 의도된 것으로서 패킷들을 이용하는 임의의 시스템, 즉 패킷 스위칭, 회로 스위칭 또는 다른 시스템인지에 무관한 시스템에 적용될 수 있음을 인식할 것이다. "무선(wireless)"에 관한 참조는 가장 넓은 의미로 이해되어야 한다. 예를 들면, 유선 네트워크 상의 전송들 일부에 대해 신뢰할 수 없는 임의의 시스템을 포함할 수 있는데, 예를 들면, 적외선 발산과 같은 광 전송 방법들을 포함한다. 그러나, 본 발명의 모든 실시예들이 BluetoothTM프로토콜이 이용될 수 있음을 주지한다. 그러한 시스템의 특징들은:
- 전개된(spread) 스펙트럼 기술로서 느린 주파수 홉핑;
- 마스터 및 슬레이브 유닛들로서, 마스터 유닛이 홉핑 시퀀스를 설정할 수 있다;
- 각 디바이스는 그자신의 클럭 및 어드레스를 갖는다;
- 마스터 유닛의 홉핑 시퀀스는 어드레스로부터 결정될 수 있다;
- 하나의 마스터와 통신하는 슬레이브 유닛들의 세트는 동일한 (마스터의) 홉핑 주파수를 모두 가지며 피코넷을 형성한다;
- 피코넷들은 스케터넷(scatternet)을 형성하기 위해 공통 슬레이브 유닛들을 통해 링크될 수 있다;
- 슬레이브와 마스터 유닛들간의 시분할 다중 전송들(TDMA : Time Division Multiplex Transmissions);
- 슬레이브와 마스터 유닛들간의 시분할 듀플렉스(TDD : Time Division Duplex);
- 동기 또는 비동기일 수 있는 슬레이브 및 마스터 유닛들간 전송들;
- 마스터 유닛들은 슬레이브 유닛들이 전송할 때를 결정한다;
- 슬레이브 유닛들은 마스터 유닛에 의해 어드레싱될 때에만 응답할 수 있다;
- 클럭들은 자기 발진(free-running)이다;
- 특히 2.4GHz 라이센스-프리 ISM 대역에서 동작하는 조정되지 않은 네트워크들;
- 그 영역 내에서 다른 BluetoothTM디바이스들을 발견하기 위하여 애플리케이션들을 인에이블하는 소프트웨어 스택;
- 다른 디바이스들은 복구/질의 절차에 의해 발견된다; 및
- 하드 또는 소프트 핸드오버들 중 하나 이상을 포함할 수 있다.
주파수 홉핑에 관하여, "느린 주파수 홉핑"은 변조율보다 더 느린 주파수 홉핑을 의미하며, "빠른 주파수 홉핑"은 변조율보다 더 빠른 홉핑율을 의미한다. 본 발명은 느리거나 또는 빠른 홉핑에 한정되지 않는다.
다음에서, 이동 단말기들인 이용자 단말기들에 대한 참조가 이루어질 수 있지만, 본 발명은 이에 한정되는 것이 아니라, 컴퓨터와 같은 고정된 이용자 단말기들을 포함할 수도 있다.
본 명세서에서 헤더 압축 기술들, 특히 로버스트 헤더 압축(ROHC)에 대한 참조가 이루어진다. 이들 기술들에 대한 일부 측면들의 요약을 제공하는 것이 유용하다고 생각되지만, 보다 상세한 이해를 위하여 독자는 2001년 7월 논문을 참조한다:
C Borman 등에 의한 "로버스트 헤더 압축(ROHC): 프레임워크 및 4개의 프로파일 : RTP, UDP, ESP 및 비압축"은 참조 번호 "RFC3095"하의" 인터넷 엔지니어링 태스크 포스"(IETF) 웹사이트를 통해 찾을 수 있으며, URL을 통해 액세스할 수 있다:
http://www.ietf.org/rfc/rfc3095.txt
일반적으로, 헤더 압축 메커니즘들은, 세션 동안 스태틱 헤더 필드들이 변경하지 않기 때문에 모든 패킷에 스태틱 헤더 필드들을 전송할 필요가 없다는 장점을 취함으로써 헤더 오버헤드를 감소시키며, 그러한 스태틱 헤더 필드들은 예를 들어 IP 어드레스들 및 UDP 포트들을 포함한다. 더욱이, 세션들 동안 변경하지 않는 필드들(예를 들어, RTP 타임스탬프, RTP 시퀀스 번호 및 IP 식별)을 효율적으로 처리할 수 있어서, 헤더 오버헤드는 더욱 감소될 수 있다. 어떤 경우에, 이들 소위 "변경 필드들(changing fields)"은 단순한 선형 외삽을 이용하여 이전 패킷들로부터 예측될 수 있다. 다른 헤더 필드들(예를 들어 IP 헤더 길이 및 UDP 길이)은 데이터 링크 레벨로부터 추측될 수 있으며, 그들을 전송할 필요가 없으며, 그들 필드들은 "추측 필드들(inferred fields)"이라 불린다.
헤더 압축 방식은 1999년 2월 논문에서의 S.Casner 및 V.Jacobson에 의한 "저속 시리얼 링크들을 위한 IP/UDP/RTP 헤더들 압축"(인터넷 RFC 2508)에 제안되었다. 이러한 장치는 RTP/UDP/IP 헤더들을 압축하지만, 전형적인 무선 링크들 상에서 생길 수 있는 에러율들 및 왕복 지연을 처리하도록 설계되지 않았다.
예를 들어 "ACE"(적응성 헤더 압축 : Adaptive header Compression) 및 "ROCCO"(로버스트 첵섬 기반 헤더 압축 : Robust Checksum-based header Compression)와 같은 무선 환경에 헤더 압축을 적응시키기 위한 기술들이 제안되었다. "ACE"는, 압축 해제기에 전달되는 가변 슬라이딩 윈도우(VSW : variable sliding window)에 포함된 다수의 참조값들을 이용하는 필드 엔코딩 방식 "변경 필드들"("윈도우-기반 최하위 비트"W-LSB)을 도입한다. ROCCO는 압축 해제기에서 정정 재구성을 확인하고 에러 전파를 회피하기 위해 CRC를 이용한다.
IETF ROHC 작업 그룹은 현재, 에러율들이 높고 왕복 시간들이 긴 링크들을 통해 작업하는 새로운 압축 방식들을 연구하고 있다. 상기 방식은 WCDMA, EDGE, 및 CDMA-2000과 같은 기술들을 이용하여 설립된 셀룰러 링크들에 대한 방식들이 수행되어야 한다. 그러나, 또한 상기 방식은 손실이 높고 왕복 시간들이 긴 다른 미래의 링크 기술들에 적용될 수 있어서, 단방향 링크들을 통해 압축이 성취될 수 있게 한다. IETF ROHC는 ACE 및 ROCCO에 의해 연구된 모든 기술들을 이용 및 조합하고, 세부사항들은:
http://www.ietf.org/html.charters/rohc-charter.html
에서 EITF ROHC 작업 그룹 URL을 통해 찾을 수 있다.
ROHC는 무선 채널들을 통해 RTP/UDP/IP 스트림들에 적용할 수 있는 로버스트 헤더 압축에 연장할 수 있는 프레임워크를 제공한다. TCP/IP 헤더들 및 다른 종류의 프로토콜들(예를 들어 모바일 IPv6)의 압축을 위한 지원은 또한 부가되고 있고 지금까지 네 개의 프로파일들은 ROHC RFC에 의해 규정되어야 한다:
0 압축되지 않은 IP 패킷들
1 RTP/UDP/IP
2 UDP/IP
3 ESP/IP
본 발명은 프로파일 1 에 집중한다.
ROHC 압축기 및 압축 해제기는 실시간 동적 필드들이 현재 처리되고, 따라서재구성된 헤더들, 즉 소정 컨텍스트 내에서 변경되지 않고 남아 있는 스태틱 헤더 필드들은 전혀 전송되지 않도록 컨텍스트 정보를 유지해야 한다. 압축 및 압축 해제 체인의 도면은 도 6a를 특히 참조하여 알 수 있다.
RTP/UDP/IP 흐름에 대해 동적 필드들은 아래와 같이 리스트된다:
- IP 식별(16 비트) IP-ID
- UDP 첵섬(16 비트)
- RTP 마커(1 비트) M-비트
- RTP 시퀀스 번호(16 비트) SN
- RTP 타임스탬프(32 비트) TS
모든 다른 헤더 필드들은 스태틱이거나 또는 추정된다.
초기에, 압축기는 "초기화 및 리프레시"(IR) 상태에 있으며, 이는 헤더들이 압축되지 않고 전송되어 압축 해제기가 IP 흐름에 대한 컨텍스트를 생성할 수 있도록 한다. "1 차"(FO : First Order) 상태에서, 압축기는 단지, 훼손된 컨텍스트일 수 있는 스트림에서 불규칙성들을 보상하기 위하여 스태틱 필드들의 갱신들을 압축 해제기에 전송한다. 따라서, 이러한 상태에서, 압축기는 컨텍스트 갱신들만을 전송한다. "2 차"(SO : Second Order) 상태에서, 압축기는 압축 해제기가 유효한 컨텍스트를 이미 수신했음을 확신하기 때문에, 압축된 헤더들을 전송한다. 특히 도 6b를 참조한다.
"컨텍스트 없음"(NC :No-Context) 상태에서 시작한다. 헤더의 성공적인 압축 해제시에, 정규 동작 상태인 "전체 컨텍스트"(FC : Full Context) 상태로 진행한다. 반복적으로 헤더들을 압축 해제한 후에만, FO 상태의 압축기에 의해 전송되는 컨텍스트 갱신 패킷들을 기다리는 "스태틱 컨텍스트"(SC : Static Context) 상태로 진행한다. 유효한 컨텍스트가 복구될 수 없다면, 압축 해제기는 NC 상태로 복귀한다. 특히 도 6c를 참조한다.
상태들간의 전이는, ROHC가 "단방향"(U-모드), "양방향 긍정"(O-모드 : bi-directional optimistic) 및 "양방향 신뢰"(R-모드 : bi-directional reliable)를 규정하는 동작 모드들에 의해 관리된다. U-모드에서, 압축 해제기에서 압축기로의 피드백 채널은, 압축기 상태들 간의 전이들이 들어오는 패킷 헤더들의 불규칙성들 및 주기적인 타임아웃들에만 기초하기 위하여, 존재하지 않는다(또는 이용될 수 없다). 이러한 경우, 컨텍스트의 주기적 리프레시들이 필요하다. O-모드에서, 피드백 채널은 에러 복구 요청들 및 (선택적으로) 컨텍스트 갱신들의 확인 응답들을 위해 이용된다. 이러한 동작 모드 뒤의 온당한 점은 피드백 채널의 이용을 최소화하는 것이다. 최종적으로, R-모드는 손실 전파 및 손상 전파에 대한 강력함(robustness)을 최대화하기 위해 피드백 채널을 집중적으로 이용한다.
W-LSB 엔코딩:
압축할 헤더 필드 값 "v"가 주어지면, W-LSB 알고리즘은 최하위 비트들만을 전송하여, 적절한 참조값(v_ref)이 압축기 및 압축 해제기 모두에서 유지된다. "v_ref" 값들 간의 미스매칭을 회피하기 위하여, 가변 슬라이딩 윈도우 VSW 내에서 "v_ref"를 선택하는 적절한 로버스트 알고리즘이 규정된다. 값 "v"가 압축되기 위해 전송될 최하위 비트들의 수 "k"는 하기에 설명하는 바와 같이 선택된다.
이 v가 변하는 것이 예상되는 간격이 되게 한다. 오프셋 파라미터 p는 압축할 특정 필드의 행동(behavior)에 따라 선택될 수 있다.
이제, 압축기에서 값 k는 하기와 같은 방법으로 선택될 수 있다:
k는 v가 간격 f(v_ref, k) 에 있도록 최소값이 된다.
그러나, 이러한 방식은 압축 해제기가 동일한 참조값(전송 에러들로 인해 사실상 상이할 수 있다)을 이용함을 압축기가 알지 못하기 때문에 에러들에 대해 강력하지 않을 수도 있다. 대신, 가변 슬라이딩 윈도우가 도입된다:
이것은, 전송된 최종 w값들을 포함한다. 새로운 값이 압축기에 들어올 때마다, VSW에 첨부된다. VSW의 기존 값들의 일부가 정확하게 수신되었음을 압축기가 충분히 확신할 때, 그들 값들은 VSW로부터 제거된다.
우리는 VSW의 최소 및 최대값들로서 다음을 규정한다.
W-LSB 코딩 방식에서, k의 선택은 다음 공식에 따라 이루어진다:
여기서 g()는 [수학식 2]에서 규정되었다.
이러한 방식으로, 압축 해제기가 전송된 m 비트들을 디코딩하기 위해 양호한 참조 간격을 가짐을 불확신함으로 인해, 더 높은 수의 비트들은 필드를 엔코딩하기 위해 이용된다. 사실상, 압축 해제기에서의 디코딩 기술은 다음 알고리즘을 기초한다.
이, v_ref_d가 최종적으로 정확하게 압축 해제된 값 및 m이 수신된 비트들의 수로 주어진 해석 간격(interpretation interval)으로서 규정되게 한다. 압축 해제된 필드는 m개의 최하위 비트들이 수신된 m개의 비트들과 매칭하는 상기 해석 간격에 값을 골라냄(picking)으로써 간단히 유도될 수 있다.
가변 슬라이딩 윈도우의 크기는 압축기가 압축 해제기 상태를 온으로 가진다는 확신에 의존하고, 선택된 ROHC 모드에 의존한다. U 및 O 모드들에 대해, w는 구현 의존적이다. ROHC 압축 패킷들(나중에 규정)의 신택스는 w의 허용된 치수를 설정한다. 사실상, 각 패킷 타입이 코딩된 헤더 필드에 대해 예약된 특정 수의 비트들을 갖기 때문에, 이것은 윈도우 치수를 자동적으로 규정한다. 예를 들어, RTP-SN은 UO-0 패킷에 네 개의 비트들이 예약되어 있으며, 그것은 윈도우 길이가 16으로 설정됨을 의미한다(최대 15개의 패킷들이 손실될 수 있다). R-모드에서, 압축 해제기로부터의 명시적 피드백은 슬라이딩 윈도우 치수를 최소하기 위해 이용될 수 있고, 따라서 압축비를 최대화한다.
W-LSB 알고리즘은 간단한 예를 통해 더 설명될 수 있다. 압축기가 값들 151, 152, 153, 154 및 155를 전송했고, 최종 세 개의 값들이 무선 링크 상의 전송 에러들로 인해 수신되지 않았음을 가정한다. 그다음, 압축기에서:
VSW = [151, 152, 153, 154, 155], vmin= 151 및 vmax= 155.
이제, 값 156이 압축기에 들어간다. 전송될 최하위 비트들의 수 k는 [수학식 5]에 의해 주어져 있고, k = max(3, 1) = 3을 산출한다. 값 156 = ‘10011100’의 최종 세 개의 LSB들이 전송된다(‘100’).
압축 해제기에서, 박들 153, 154 및 155가 손실되었기 때문에, 최종의 양호한 참조값은 152이다. [수학식 6]에 따라, 압축 해제기는 해석 간격 Id = [152, 159]를 가지며, 이는 하기에 설명된다.
이러한 간격 내에서, 세 개의 LSB들이 패턴 '100'과 매칭하는 값은 단지 156뿐임을 알 수 있다. 압축 해제의 정확성은, 검출되지 않은 전송 에러가 참조값으로 나중에 이용될 잘못 압축 해제된 값을 가지고, 손상 전파를 유발하는 것을 회피하기 위하여, 원 헤더(예를 들어 모드에 의존하는 3 내지 8 비트들)에 작은 CRC를 적용함으로써 확인될 수 있다. 손상된 값을 검출하는 CRC의 실패는 또한, ROHC 프레임워크에서 보상된다.
다른 엔코딩 방식들:
W-LSB 코딩 알고리즘은 ROHC 프레임워크에서 이용될 수 있는 것만이 아니다. 예를 들어, 시간에 걸쳐 정규 단계들(다수의 TS_STRIDE 값)에서 보통 증가하는 RTP 타임 스탬프와 같이 일부 헤더 필드들의 특정한 특성들의 장점을 취하는 다른 방식들이 존재한다. 이러한 특성은 "스케일링된 RTP 타임스탬프" 엔코딩에 의해 이용된다.
RTP 타임스탬프는 또한, 패킷 발생이 샘플링 주파수에 고정될 때 및 고정된 샘플링 주파수와 같은 일정한 속도로 발생되는 트래픽에 대한 지연 시간의 선형 함수로 근사될 수 있다. 이러한 경우, "RTP 타임스탬프의 시간-기반 압축"이 적용된다.
IP 식별 필드(IP-ID)는 IP-ID와 RTP 시퀀스 번호(각 새로운 패킷에 대해 나중에 하나씩 증가) 사이의 오프셋들만을 고려하고 그러한 오프셋들에 W-LSB 엔코딩을 적용함으로써 엔코딩된다.
ROHC RTP 프로파일:
압축될 RTP/UDP/IP 스트림의 일정한 헤더 필드들은 순서화된 리스트들로서 구성될 수 있다. ROHC 프레임워크는 압축 해제기에서의 (컨텍스트를 형성하는) 리스트 항목들이 압축기에 의해 유연하게 삽입, 삭제 또는 변경될 수 있는 방식으로이들 리스트들을 처리하기 위한 수단을 제공한다.
RTP 헤더의 동적 필드들은 테이블 1에 따라 엔코딩된다.
테이블 1 - RTP 헤더 동적 필드들 코딩
RTS TS 및 IP-ID 필드들은 종종, IP-ID가 시퀀스 번호와 동일한 델타만큼, 타임스탬프가 고정값들의 동일한 델타의 배수만큼 보통 증가되기 때문에, RTP SN으로부터 유도될 수 있다. 따라서, 이들 조건들이 적용될 때, RTP SN은 압축된 헤더에 포함되고, 다른 필드들을 유도하기 위한 함수들은 컨텍스트에 포함된다.
ROHC 패킷은 다음의 포맷을 가진다:
테이블 2 - ROHC 패킷
페이로드를 제외하고, 테이블 2의 각 패킷 엘리먼트는 고유한 비트 패턴으로 시작한다.
헤더들은 컨텍스트 ID(CID) 정보를 전달한다: 그들은 1과 15 사이의 작은 CID들에 대해 1바이트 '부가-CID' 옥텟(패턴 '1110'으로 시작)을 포함할 수 있거나, 또는 CID 공간이 클 때(최대 2 바이트) 내장된 CID 정보를 전달할 수 있다. ROHC 컨텍스트 식별자는 R-CID라 불린다. CID = 0이 전송되지 않으면, 패킷은 패킷 타입으로 시작하며, 이는 ‘1110’과는 다른 고유한 비트 패턴이고 널 CID가 내포된다.
피드백 정보는 임의의 ROHC 패킷으로 피기백(piggyback)될 수 있고, 컨텍스트 갱신들 및 헤더 압축 해제를 위한 부정 및 긍정 확인 응답들을 전달한다. 또한, 피드백 패킷들은 모드들간의 전이들(U-모드에서 O-모드로)을 요정하기 위해 압축 해제기에 의해 이용될 수 있다.
패킷 타입들:
여러 개의 패킷 타입들은 그들 함수, 이용된 모드 및 어느 필드가 전달되는지에 의존하여 ROHC에 의해 규정된다. ROHC 패킷들에 대한 표시는:
<모드><타입>-<선택적 필드들>
예를 들어, UOR-2 패킷은 U-모드, O-모드 또는 R-모드에서 이용될 수 있으며, 타입 2이다.
RTP 프로파일에서, 하기에 보여진 바와 같이, 세 개의 패킷 타입들은 압축된 헤더들을 식별하기 위해 이용되고, 두개의 패킷 타입들이 초기화 및 리프레시를 위해 이용된다:
0. (R-0, R-0-CRC, UO-0) : 이것은, 다른 필드들을 유도하는 모든 함수들이 디코더에서 공지되어 있기 때문에, W-LSB 엔코딩된 RTP-SN만이 전송되는 경우의 최소 패킷 타입이다.
1. (R-1, R-1-ID, R-1-TS, UO-1, UO-1-ID, UO-1-TS) : 이 패킷은, RTS-SN을 엔코딩하기 위해 필요한 비트들의 수가 패킷 타입 0에서 이용 가능한 수를 초과할 때, 또는 RTP SN으로부터 RTP TS 및 IP-ID를 유도하기 위한 함수들을 변경할 때 이용된다.
2. 임의의 SN-함수의 파라미터들을 변경하는데 이용된 (UOR-2, UOR-2-ID, UOR-2-TS)
3. IR : 이 패킷은 컨텍스트의 스태틱 부분, 즉 일정한 SN- 함수들을 전달하기 위해 이용된다.
4. IR-DYN : 이 패킷은 컨텍스트의 동적 부분, 즉 일정하지 않는 SN-함수들을 전달하기 위해 이용된다.
패킷 타입들 각각에 대한 고유한 프리픽스들을 형성하는 비트 패턴들은 테이블 3에 도시되어 있다.
테이블-3 패킷 프리픽스들
패킷을 수신할 때, 압축 해제기는 첫 번째 바이트를 분석하고 결과적으로 상태 머신을 구동한다.
IR 패킷:
초기화 및 리프레시(IR) 패킷은 압축 해제기가 RTP/UDP/IP 흐름에 대한 컨텍스트를 생성하도록 허용한다. 그 구조는 하기에 테이블 4에 도시되어 있다.
테이블 4-IR 패킷 포맷
부가-CID 옥텟은, 나머지 패킷으로 전달되는 스태틱 헤더 정보와 컨텍스트 식별자를 연관시키는 것을 허용한다. D 비트는 특정 프로파일이며, RTP 프로파일의 경우에는, 스태틱 체인 직후에 동적 서브헤더 정보의 존재를 표시한다. CID 정보 필드는 큰 컨텍스트 식별자들이 이용될 필요가 있는 경우에만 존재한다. 프로파일 필드는 ROHC 프로파일에 대한 식별자이다. 8비트 CRC가 뒤따르며, 말부에서, 독자는, 참조 번호 "RFC3095"하의" 인터넷 엔지니어링 태스크 포스"(IETF) 웹사이트를 통해 찾을 수 있는, C. Borman 등에 의한 "로버스트 헤더 압축(ROHC): 프레임워크 및 네 개의 프로파일들: RTP, UDP, ESP 및 비압축"을 참조한다. 값이 계산된 필드들에서 발생기 다항식들에 대해 섹션 5.9.1을 참조한다.
스태틱 체인은 스태틱 헤더 필드들의 순서화된 리스트를 포함한다. 예를 들어, IPv4 헤더는, 버전, 프로토콜, 소스 어드레스 및 목적지 어드레스를 포함하는스태틱 부분으로 시작되어야 한다. IPv4 헤더의 동적 부분은 서비스, 생존 시간, 식별, DF, RND, NBO, 연장 헤더 리스트의 타입을 포함한다.
IR-DYN 패킷:
이러한 패킷 타입은 컨텍스트의 동적 부분을 갱신하기 위해 이용되고, 그 포맷은 하기에 테이블 5에 도시된다. 이 경우에 동적 체인만이 전달된다.
테이블 5 - IR-DYN 패킷 포맷
일반 패킷 포맷:
압축된 패킷 포맷은 테이블 6에 도시되어 있다. 그 구조가 많은 조건들(Cx)에 의존하기 때문에 그 처리가 명백하지 않을 수도 있음을 알아야 한다.
테이블 6 - 일반 압축된 패킷 포맷
조건들은 이전 디코딩된 플래그 필드들의 값들에 의존한다. 헤더 연장들은 부가의 ROHC 정보(네 개의 상이한 연장 타입들이 규정된다)를 전달하기 위해 선택적으로 존재할 수 있다. IP-ID 필드는 컨텍스트가, 이러한 필드가 랜덤하게 변함을 표시하는 경우에 존재할 수 있다.
AH 데이터는 인증 헤더들을 참조하며, 보안 어소시에이션들(security associations)을 위한 값들을 포함한다. GRE 첵섬은 GRE 터널들(RFC2784, FRC2890)을 참조한다. UDP 첵섬은 컨텍스트에서 명시적으로 표시될 때에만 존재한다.
BluetoothTM을 위한 로버스트 헤더 압축:
본 발명의 두 가지 주요 논쟁들에 초점을 맞춘다:
a) 로버스트 헤더 압축(ROHC)을 BluetoothTM통신 시스템에 적용; 및
b) ROHC를 BNEP로 연장.
본 발명은, 단일 슬롯 BluetoothTM기저대역 패킷으로 맞추기 위해, VoIP 프레임, 비디오/오디오 스트림 또는 등가물을 압축할 수 있는 새로운 프로토콜을 제공하며, 본 명세서에서 이러한 프로토콜은 편의상 "ROHC-BNEP"라 부른다.
본 발명은 음성 애플리케이션들에만 한정되는 것이 아니라, BluetoothTM피코넷에서 실시간 IP 서비스들의 전송을 포함하는 오디오/비디오 스트리밍 애플리케이션들과 같은 다른 IP 트래픽에도 응용할 수 있다. 본 발명에 따라, BNEP 정보는 ROHC 압축기 및 압축 해제기의 컨텍스트에 부가된다. 이러한 방식으로, IP 패킷뿐만 아니라, 제 2층 프레임도 압축된다.
본 발명의 실시예에 따른 이동 핸드세트 MT1-n에 대한 프로토콜 스택은 특히 도 2를 참조하여 보여질 수 있다. 음성 엔코더가 생성하는 각 패킷에 대해, 12바이트 RTP 헤더는 시간 동기화를 허용하기 위해 부가된다. 애플리케이션 흐름들이 함께 다중화되고 헤더 첵섬에 부가되도록 허용하는 8 바이트 UDP 헤더가 부가된다. UDP 데이터그램은, IP 버전 4 또는 6이 이용되는지 여부에 따라 20 바이트 또는 40 바이트 헤더를 갖는 IP 패킷으로 캡슐화된다. IP 패킷을 BluetoothTM프레임으로 캡슐화하기 위해 이용되는 BNEP 헤더는 3 내지 15 바이트의 범위를 갖는다. 로버스트 헤더 압축(ROHC)이 RTP/UDP/IP 흐름들을 전달하는 BNEP 프레임들에 적용되는 것을알 수 있다.
4바이트 L2CAP 헤더 오버헤드를 고려하여, 27 바이트 페이로드를 갖는 단일 슬롯 DH1 기저대역 패킷으로 압축된 프레임을 전달하기 위하여, RTP/UDP/IP/BNEP 헤더들은 ROHC 압축기에 의해 3 바이트로 줄여져야 한다. 이러한 목표는 하기에 설명되는 바와 같이, BT 시스템 및 ROHC 압축기가 적절하게 구성되는 경우에 성취될 수 있다.
제안된 해결책은 여러 단계들을 포함한다:
- 표준 BluetoothTM서비스 복구 프로토콜을 이용하여 ROHC 압축 성능들을 통고한다;
- 압축된 비트스트림을 전달하도록 L2CAP 채널들을 구성한다;
- BNEP 스태틱 헤더 필드들을 ROHC 컨텍스트에 부가한다(모든 BNEP 헤더 필드들은 단일 VoIP 세션 내에서 스태틱이다);
- ROHC 프레임워크를 BluetoothTM기저대역 재전송 방식으로 적응시킨다; 및
- VoIP 패킷을 전달하는 BNEP 프레임들만이 제안된 ROHC-BNEP 알고리즘을 이용하여 압축되도록 BNEP 프레임들을 분류한다.
일반적인 ROHC 프레임워크는 상기를 참조하였다. 다음 섹션들에서, BluetoothTM경우에 대한 애플리케이션은, 이용할 패킷 타입들, 그들을 선택하는 방법 및 압축기 상태들 사이에서의 전이를 관리하는 방법을 포함하여 세부화될 것이다. ROHC-BNEP는 다음 툴들을 이용한다:
- RTP 프로파일이 이용된다;
- ROHC 양방향 긍정 모드는 이용된 방식이다: 성공하지 않은 압축 해제의 경우에 NACKS만이 피드백되며, 가능하면 그들 이용을 최소화하도록 노력한다.
- 작은 R-CID은 큰 CID 공간을 필요로 하지 않으며, 전송될 필요가 없기 때문에 널 R-CID는 디폴트로서 이용된다.
- UDP 첵섬이 전송되지 않는다(페이로드가 암호화되지 않는 경우에만 압축 해제기에서 선택적으로 재계산될 수 있다)
- 전체 BNEP 헤더가 동일한 VoIP 흐름에 대해 변경되지 않기 때문에, 스태틱 컨텍스트의 일부로서 고려되어야 한다.
- RTP TS를 유도하기 위한 함수가 공지되어 있기 때문에 RTP 시퀀스 번호 및/또는 IP-ID만이 전송된다(시간-기반 엔코딩은 침묵 억제(silence suppression)를 보상하기 위해 적용된다).
- 피드백 채널 이용은 압축 해제기에서 압축기로의 컨텍스트 갱신 요청들만을 전달하도록 최소화된다.
- 압축기에서 "초기화 및 리프레시"(IR), "1 차"(FO) 및 "2 차"(SO) 상태들 사이의 전이들과, 압축 해제기에서 "컨텍스트 없음"(NC), "상태 컨텍스트"(SC) 및 "전체 컨텍스트"(FC) 상태들 사이의 전이들이 규정된다.
BluetoothTM을 통한 ROHC는 도 7의 상태 머신에 의해 또한 명시된다. 각 압축기 상태에 대해, 정보가 전송되고(상부), 패킷들이 이용되고(하부), 또한 헤더정보(괄호안)를 위해 얼마나 많은 바이트가 전송되었는지를 표시한다. 상태들 사이의 전이들이 또한 표시되며 그들 설명들이 하기에 주어진다.
초기에, 압축기는 IR 상태에 있고, 모든 상태들 및 컨텍스트의 동적 부분은 압축 해제기에서 전송되어야 한다. 관측 시간 tlp(t)에서 손실 패킷들의 수가 관측 시간 t-1lp(t-1)에서 손실 패킷들의 수보다 더 작은 경우에만 IR에서 FO로의 전이가 이루어진다. 이들 관측 시간들은, 설정할 수 있는 임계 시간 내에서 압축 해제기에 의해 성공적으로 전달될 수 없는 VoIP 프레임들의 수를 압축기가 등록하는 시점들에 고정된다. lp(t)는 간격(t-1, t) 동안 BluetoothTM스택에서 L2CAP층에서 수신되는 경우의 각 L2CAP 타임아웃에 대해 1씩 증가된다. FO에서 SO로의 전이는 들어오는 VoIP 스트림이 불규칙성들(예를 들어, 음성 코더에서 침묵 억제와 같이)을 보여주지 않음을 압축기가 표시하는 경우에만 발생할 수 있다. SO에서 한번, 압축기는 IP 스트림이 불규칙성들을 보여주는 경우에 FO로 돌아간다. FO 상태에서, 스태틱 컨텍스트가 훼손되었음을 표시하는 NAK 패킷이 피드백 채널을 통해 수신되는 경우에 압축기는 IR 상태로 되돌아간다.
BluetoothTM상에 ROHC RTP 맵핑:
다음 섹션에 기술된 ROHC-BNEP 알고리즘은 ROHC 양방향 긍정 방식으로 하며, 상기 방식은, 상기 참조된 C. Borman 등에 의한 "로버스트 헤더 압축(ROHC): 프레임워크 및 네 개의 프로파일들: RTP, UDP, ESP 및 비압축"에 광범위하게 기재되어 있다.
피드백 채널 활용은 압축 해제기에서 압축기로 컨텍스트 갱신 요청들만을 전달하기 위해 최소화되었다. ROHC RTP 프로파일에 이용된 패킷 타입들은 섹션 5.2.7.의 C. Borman 등에서 발견될 수 있다. 압축 해제기는 단방향 모드에서 시작하고, 컨텍스트 정보를 얻은 후에 긍정 모드로 전이하기 원하는 것을 표시하는 피드백 패킷을 압축기에 다시 전송한다. 압축기가 그러한 요청들을 수신하는 즉시, 주기적인 IR 갱신들을 전송하는 것을 중단하고 O-모드로 진행하여 대역폭을 절약한다.
BluetoothTM시스템에서 ROHC-BNEP RTP/UDP/IP 헤더 압축 알고리즘의 효과를 평가하기 위하여, 일부 고려 사항들이 만들어져야 한다. 첫째, BluetoothTM논리적 링크 제어 및 적응층(L2CAP)이 고려되고, 기저대역 에러 처리 메커니즘들이 재방문될 것이다.
링크층 프레이밍:
L2CAP층은 BluetoothTM스택에 논리적 채널들 및 세그먼테이션 및 재조립(SAR : segmentation and reassembly) 기능을 제공한다. 논리적 채널은 채널 ID(CID)에 의해 식별되고, 기존 기저대역 접속을 이용하여 피어 엔티티들간의 전용 L2CAP 시그널링 메시지들에 의해 설정된다. 여러 논리적 채널들은 동일한 기저대역 접속을 통해 두 BT 디바이스들 사이에서 확립될 수 있다. 각 논리적 채널에 대해, 링크층은 L2CAP 최대 프레임 크기를 한정하는 최대 전송 유닛(MTU : Maximum Transmission Unit)이 규정된다. L2CAP SAR 기능은 L2CAP 프레임이, 시퀀스로 전송되는 다중 기저대역 패킷들로 세그먼트되게 한다.
기저대역층이 L2CAP 접속들을 구별하도록 허용되지 않기 때문에, 상이한 L2CAP 프레임들에 속하는 기저대역 패킷들은 인터리브될 수 없다. 달리 말하면, L2CAP 프레임의 제 1 패킷이 한번 전송되면, 동일한 논리적 접속의 모든 나머지 패킷들이 따라야 한다.
이러한 특성은, 두 애플리케이션들이 동일한 논리적 채널을 이용하는 경우에(또는 그들이 두개의 상이한 논리적 채널을 이용하는 경우에도), 우선권이 낮은 더 긴 프레임은 우선권이 높은 더 짧은 프레임의 전송을 지연시킬 수 있다.
따라서, 이러한 블로킹 효과를 회피하기 위하여 L2CAP MTU 파라미터를 적절히 이용하는 것이 권장된다. 예로서, 우리는 VoIP 애플리케이션과 하나이상의 TCP/IP 접속들을 가진 BT 클라이언트를 고려할 것이다. 두 애플리케이션들은, 제 1 애플리케이션이 지연에 민감하고 짧은 패킷들을 가지는 반면, 제 2 애플리케이션은 지연에 제약되지 않지만 최대 1500바이트 길이만큼 길 수 있기 때문에 상이한 특성들을 가진다. 실시간 트래픽을 지연하는 것을 회피하기 위하여, 작은 MTU는 TCP/IP 접속을 위해서도 이용되어야 하고, 이것이 IP층에서 큰 단편화 오버헤드(fragmentation overhead)를 도입하는 경우에도 이용되어야 한다.
상기 두 애플리케이션들은 상이한 신뢰도 요구들을 가진다: 실시간 트래픽에 대해, 특정 임계치를 넘는 전송 에러들로 인해 지연되는 패킷은 더 이상 유용하지 않고 중단될 수 있지만, TCP/IP 데이터 접속에 대해서는 그렇지 않다.
자동 플러시 타임아웃은 값을 설정할 수 있는 각 L2CAP 논리적 채널 상에 적용될 수 있다. 시뮬레이션들에서, VoIP 프레임들을 버리기 위해 12.5ms의 타임아웃이 이용되어야 한다.
TCP/IP 및 RTP/UDP/IP가 상기 예에서와 동일한 BT 링크 상에 동시에 존재하는 경우, VoIP 애플리케이션의 품질을 개선하기 위하여, TCP/IP 프레임들을 버리는 것을 허용하는지 여부에 따라 평가되어야 한다. 이러한 선택은 많은 인자들에 달려 있고, 실시간 및 데이터 트래픽 모두에 대한 구현을 갖는다(후자의 경우, TCP/IP 재전송들이 고려되어야 한다).
BluetoothTM에 ROHC-BT 알고리즘 시스템을 적용할 때, 지연 민감한 논리적 채널의 L2CAP 타임아웃들의 수는 헤더 압축 메커니즘의 에러 강력함을 증가시키는 중심 역할을 한다. 실제로, L2CAP 타임아웃 이벤트들은 프레임이 분실되었음을 표시해서, 헤더 압축기는, 예를 들어 적절한 ROHC 패킷 타입을 선택함으로써, 윈도우를 증가시키기 위해 이러한 정보를 이용할 수 있다.
에러 처리:
BluetoothTM기저대역에서의 ARQ 메커니즘은 수신기가 다음 패킷이 전송되기 전에 각 기저대역 패킷을 긍정적으로 확인 응답해야 한다. 데이터 패킷에서 또는 확인 응답 메시지에서 전송 에러들이 발생하는 경우, 패킷은 재전송되어야 한다. 패킷 재전송들을 야기하는 에러 상태들은:
- 수신되지 않은 기저대역 패킷 액세스 코드;
- 기저대역 패킷 헤더에서의 정정할 수 없는 에러들;
- 패킷 페이로드에서의 정정할 수 없는 에러들(에러 상태가 확인 응답 패킷에서만 발생하는 경우, ACK 필드가 패킷 헤더로 전달되기 때문에 재전송은 트리거되지 않는다)을 포함한다.
동일한 L2CAP 프레임의 일부인 모든 기저대역 패킷들은 수신기에서 조립된 프레임이 상위층들로 전달되기 전에 정확하게 수신되어야 한다. 전송기에서, L2CAP 프레임이 세그먼트되어야 하는 모든 기저대역 패킷들은 L2CAP 타임아웃 이벤트를 회피하기 위하여 설정할 수 있는 시간 내에서 긍정적으로 확인 응답되어야 한다.
L2CAP 타임아웃 이벤트가 발생할 때, 전송기는 HCI_Flush 명령을 이용하여 호스트 제어기에서 및 L2CAP 층 모두에서 모든 나머지 기저대역 패킷들을 플러시한다(BluetoothTMSIG, "코어 사양들 vl.1", H:1부분, 섹션 4.7.4를 참조). 이러한 명령은 지정된 접속 처리를 위해 미해결된(pending) 재전송들 모두를 리셋한다. 새로운 프레임의 시작으로 트리거되는 새로운 HCI 데이터 패킷이 수신되면, 정규 동작이 다시 시작된다.
L2CAP 접속의 수신은 L2CAP 채널의 구성에서 Flush_Timeout 선택을 이용함으로써 전송기의 L2CAP 타임아웃에 관하여 통지된다(BluetoothTMSIG, "코어 사양들 vl.1", D 부분, 섹션 6.2를 참조).
점-대-다중점:
VoIP 전송기가 BluetoothTM으로 실행될 때, 슬레이브 및 마스터가 그에 접속된 다른 슬레이브들을 가지는 경우에, 폴링 액세스 방식에 대한 일부 고려 사항이주어져야 한다.
먼저, 슬레이브는, 마스터가 VoIP 패킷들(예를 들어 약 30ms)의 발생과 매칭되는 속도로 폴링되도록 요청되어야 한다. 이것은, LMP_quality_of_service_request로 번역되는 명령 HCI_QoS_setup과 적절한 T폴(Tpoll)을 협정(negotiating)함으로써 이루어진다.
그러나 점-대-다중점 구성의 경우에, BluetoothTM기저대역의 무수한(unnumbered) ARQ 방식은 슬레이브에 의해 마스터에 전송되는 패킷이, 마스터가 슬레이브를 폴링할 때 확인 응답될 수 있음을 표시한다(BluetoothTMSIG, "코어 사양들 vl.1", B 부분, 섹션 5.3.1을 참조). 이것은 L2CAP 타임아웃들이 마스터의 스케줄링 방식에 따라 슬레이브에서 트리거될 수 있음을 의미한다.
구성:
초기 구성 처리는 개인 영역 네트워크 이용자(PANU)와 네트워크 액세스점 NAP(AP1-n) 사이의 흐름으로 도 3에 도시되어 있다. 액세스점 AP1-n에 대한 제 1 접속시, 핸드세트 MT는 액세스점 AP1-n에 의해 지원되는 서비스들에 대한 정보를 얻기 위해 S에 질의를 수행한다. 액세스점 AP1-n은 표준 BNEP 프로토콜(PSM 값이 할당)과, 이 문서에 명시된 새로운 ROHC-BNEP 프로토콜(동적 PSM이 이 목적을 위해 이용될 수 있음)에 대해 각각 PAN 및 ROHC-BNEP 성능들을 통고해야 한다.
L2CAP 신뢰할 수 있는 접속은 BNEP 특정 PSM을 요청함으로써 먼저 생성된다.그 다음, 제 2 L2CAP 접속은, S에 기록에서 통고된 ROHC-BNEP에 대한 동적 PSM 값을 이용함으로써 생성된다. 이러한 제 2 접속은 L2CAP 서비스 품질(QoS : Quality-of-Service) 설정 메시지들을 이용하여, 신뢰할 수 없는 것으로 구성될 수 있다. 이것은 한정될 VoIP 패킷에 대한 재전송들의 수를 허용한다: 사실상, 패킷이 특정한 시간량 내에 성공적으로 전달되지 않은 경우에, 수신기에 쓸모 없게 되어 버려질 수 있고, 그에 의해 대역폭을 절약한다. 이를 위해, L2CAP 타임아웃은 패킷 재전송들을 중지하고 BK 링크 관리기에서 모든 관련된 버퍼들을 비우는(free) 기저대역 플러시 명령과 결합될 필요가 없다. 요약하면, 이동 핸드세트는 두개의 논리적 채널들을 구성할 필요가 있는데, 하나는 표준 IP 트래픽을 전달하기 위한 것이고, 다른 하나는 압축된 VoIP 스트림을 위한 것이다. 일단 L2CAP 논리적 채널들이 설정되면, 이동 단말기와 액세스점은 다음 서브섹션들에서 설명되는 바와 같이, 일관되게 이용되어야 한다.
하나의 L2CAP 채널만이 액세스점 AP와 이동 단말기 MT 사이에서 확립될 수 있는 경우에, "신뢰할 수 없는" 채널은 VoIP 흐름을 보호하기 위하여 데이터 접속들에 이용되어야 한다. 신뢰할 수 없는 논리적 채널 상의 데이터 패킷들의 손실은 더 높은 층 프로토콜들(예를 들어 TCP/IP)에 의해 처리될 수 있다.
전송기 및 수신기 논리:
전송기에서, 도 4a에 예시된 알고리즘은 BNEP 프레임이 L2CAP에 전달되어야 할 때마다 이용될 수 있다.
무엇보다도 BNEP 프레임은 압축되어야하는지의 여부를 이해하기 위하여 식별되어야 한다. 사실상, RTP/UDP/IP 패킷들을 전달하는 BNEP 프레임들만이 제안된 ROHC-BNEP 알고리즘으로 처리되어야 한다.
다음 BNEP 헤더 필드들이 확인된다:
- BNEP 목적지 어드레스(피어는 ROHC 성능들을 가져야 한다)
- BNEP 프로토콜 타입("IP" 또는 "IPv6"이어야 하며, IEEE802.1p 및 IEEE802.1q는 QoS 지원하는 LAN들에 이용되기 때문에 이더넷 프레임 태깅을 위해서도 해석(interpreted)되어야 함)
- IP 프로토콜 타입(UDP이어야 함)
- UDP 포트(H.323에 대응해야 함).
BNEP 프레임이 압축되어야 하면, ROHC 컨텍스트가 검색되어 결과로서 생긴 압축된 프레임은, 신뢰할 수 없는 채널에 대응하는 L2CAP CID(L-CID)를 이용하여 L2CAP층에 전송된다. 프레임이 압축되지 않아도 되면, 신뢰할 수 있는 채널의 L-CID가 대신 이용된다.
수신기에서, 도 4b에 도시된 바와 같이, ROHC-BNEP L-CID에 대응하는 신뢰할 수 없는 채널로부터 프레임이 도착하면, ROHC-BNEP 압축 해제가 적용되어야 하는 것으로 가정된다. 성공적인 재전송 후에, 프레임은 BNEP층에 전달된다.
압축된 프레임이 정확하게 재구성될 수 없는 경우, 그 프레임은 압축 해제기에서 버려진다. 부정적 ACK는, N2 연속적인 압축된 패킷들이 재구성될 수 없으므로, 신뢰할 수 없는 채널 및 ROHC 피드백 패킷 타입을 이용하여 피어 ROHC 압축기에 다시 전송된다.(ROHC 알고리즘의 설명에 대한 나중 섹션을 참조) N2는 예를 들어 15로 설정된다.
ROHC-통한-BNEP 장치에 대한 블록도는 도 5에 도시되어 있다. ROHC 코덱 및 모든 관련된 논리는 소프트웨어 제품의 형태로 구현될 수 있으며, 상기 제품은 BluetoothTM네트워크 인터페이스 소프트웨어 구동기와 연관되어 실행된다. 이러한 소프트웨어 제품은 BNEP 및 L2CAP층들, 프레임 분류기, ROHC 코덱, 및 다양한 블록들을 조정하는 관리 엔티티(ME)를 포함한다. ME는 (존재할 때) 표준 HCI 인터페이스를 통해 BT 기저대역과 통신할 수 있고, 오퍼레이팅 시스템 특정 메커니즘들에 의해 상위층들과 통신할 수 있다.
이동 단말기 MT1-n이 AP1-n에 접속할 때마다, ME는 MAC 어드레스를 등록하고 그를 위해 논리적 채널들을 구성한다. BluetoothTM에서, 논리적 채널은 L2CAP 채널 ID(L-CID)라 명명된 한 쌍의 채널 종점들에 의해 특징된다. 채널 설정시, 각 피어는 그 자신의 국부적 L-CID를 할당하고 그것을 원격 디바이스에 전송한다. 따라서, ROHC 목적을 위해, 다음 테이블이 만들어질 수 있다.
테이블 9 - AP의 ROHC-BNEP 구성예
테이블 9의 예에서, AP1은 접속된 두개의 이동 단말기들 MT1,2를 갖는다. MT1은 두개의 논리적 채널들을 구성하는데, 하나는 정규 IP 트래픽에 대한 것이고, 다른 하나는 VoIP에 대한 것이다. 이러한 두 번째 채널은 널 ROHC 컨텍스트 ID를 이용할 것이다. MT2가 액세스점 AP1에 접속할 때, VoIP에 대한 채널을 구성한다: 널 R-CID는 이러한 경우에도 이용될 수 있다. 그러나, MT1이 제 2 RTP/UDP/IP/BNEP 흐름(4번째 행)에 대한 다른 채널을 구성할 때, 상이한 ROHC 컨텍스트가 이용되어야 하는데, 그 이유는 MT1이 별도로 처리되어야 하는(예를 들어, 하나의 음성 채널과 하나의 비디오 채널) 두개의 실시간 스트림들을 가지기 때문이다.
이동 단말기들과 액세스점들 사이에 본 명세서에 기술된 제안된 로버스트 헤더 압축 기술을 적용함으로써, 대역폭을 절약할 수 있음으로써, 동일한 피코넷에서의 다수의 접속들을 처리할 수 있다.
본 발명이 양호한 실시예에 관하여 특별히 도시되고 기술되었지만, 당업자는 형태 및 세부 사항의 변경들이 본 발명의 기술 사상 및 범위를 벗어나지 않고 이루어질 수 있음을 이해할 것이다.
용어풀이 :
ACL 비동기 비접속
AP 액세스점
BER 비트 에러율
BNEP 블루투스 네트워크 캡슐화 프로토콜
BT 블루투스
CID (ROHC에서)컨텍스트 ID, (블루투스 L2CAP에서) 채널 ID
IETF 인터넷 엔지니어링 태스크 포스
IP 인터넷 프로토콜
L2CAP 논리적 링크 제어 및 적응층
LAN 근거리 네트워크
L-CID L2CAP 채널 식별자
LM 링크 관리기
MAC 매체 액세스 제어
ME 관리 엔티티
MT 이동 단말기
PAN 개인 영역 네트워크
PSM 프로토콜 스위치 다중화기
R-CID ROHC 컨텍스트 식별자
ROHC 로버스트 헤더 압축
RSSI 수신된 신호 세기 표시
RTP 실시간 프로토콜
SDP 서비스 복구 프로토콜
TO 타임아웃
UDP 이용자 데이터그램 프로토콜
VoIP 보이스 오버 IP

Claims (21)

  1. 제 1 유닛과 제 2 유닛 사이의 패킷-기반 무선 전송 방법에 있어서,
    a) 실시간 비트스트림을 미리 결정된 최대 길이의 하나 이상의 페이로드들로 변환하고;
    b) 미리 규정된 통신 프로토콜에 따라 상기 유닛들 사이의 전송에 적합한 패킷들을 발생하기 위하여 하나 이상의 미리 규정된 헤더들을 상기 페이로드 또는 각각의 상기 페이로드에 적용하고;
    c) 상기 유닛들 사이의 무선 접속을 가로질러 상기 패킷 또는 각각의 상기 패킷을 전송하도록 적응된 캡슐화 프로토콜의 프레임 내에서 상기 패킷 또는 각각의 상기 패킷을 캡슐화하고; 및
    d) 미리 규정된 헤더 압축 기술을 상기 캡슐화된 패킷 또는 각각의 상기 캡슐화된 패킷에 적용하는 상기 유닛을 포함하는 패킷-기반 무선 전송 방법.
  2. 제 1 항에 있어서, 보이스-오버-인터넷-프로토콜(VoIP : Voice-over-Internet-Protocol), 오디오 또는 비주얼 스트림들과 같은 인터넷 프로토콜(IP) 트래픽을 포함하는 상기 실시간 비트스트림으로부터 상기 페이로드 또는 각각의 상기 페이로드를 발생하는 단계를 포함하는, 패킷-기반 무선 전송 방법.
  3. 제 1 항 또는 제 2 항에 있어서, 상기 제 1 및 제 2 유닛들 사이의 서비스복구 절차를 수행하는 단계와, 상기 서비스 복구 절차동안 상기 헤더 비교 기술을 통고(advertise)하는 단계를 포함하는, 패킷-기반 무선 전송 방법.
  4. 제 1 항 내지 제 3 항 중 어느 한 항에 있어서, 압축된 비트스트림을 전달하기 위해, 상기 미리 규정된 통신 프로토콜의 세그먼테이션, 재조립 및 다중화 서비스들 중 하나 이상을 구성하는 단계를 포함하는, 패킷-기반 무선 전송 방법.
  5. 제 1 항 내지 제 4 항 중 어느 한 항에 있어서, 상기 헤더 압축 기술을 적용하도록 적응된 압축기 및 압축 해제기의 컨텍스트에 캡슐화 프로토콜 정보를 부가함으로써 상기 헤더 압축을 적용하는 단계를 포함하고, 상기 정보는 예를 들어 상기 캡슐화 프로토콜의 스태틱 헤더 필드들을 포함하는, 패킷-기반 무선 전송 방법.
  6. 제 1 항 내지 제 5 항 중 어느 한 항에 있어서, 상기 유닛은 BluetoothTM네트워크의 일부를 포함하고, 상기 방법은 BluetoothTM네트워크 캡슐화 프로토콜(BNEP : BluetoothTMNetwork Encapsulation Protocol)을 포함하는 캡슐화 프로토콜을 이용하여 상기 패킷 또는 각각의 상기 패킷을 캡슐화하는 단계를 포함하는, 패킷-기반 무선 전송 방법.
  7. 제 6 항에 있어서, 바람직하게, 상기 미리 결정된 헤더들 및 BNEP 헤더의 조합을 예를 들어 3 바이트의 미리 결정된 길이로 줄임(shrink)으로써, 상기 헤더 압축 기술을 이용하여 상기 캡슐화된 패킷 또는 각각의 상기 캡슐화된 패킷을 단일 슬롯 BluetoothTM기저대역 패킷으로 압축하는 단계를 포함하는, 패킷-기반 무선 전송 방법.
  8. 제 1 항 내지 제 7 항 중 어느 한 항에 있어서, 인터넷 엔지니어링 태스크 포스(IETF : Internet Engineering Task Force)에 의해 승인된 ROHC와 같은, 로버스트 헤더 압축(ROHC : Robust Header Compression) 프레임워크의 형태로 상기 헤더 압축 기술을 적용하는 단계를 포함하는, 패킷-기반 무선 전송 방법.
  9. 제 8 항에 있어서,
    a) 상기 패킷들에 대한 실시간 프로토콜(RTP : Real Time Protocol)을 이용하는 단계;
    b) IETF ROHC 양방향 낙관적 방식(optimistic approach; o-모드)을 이용하는 단계;
    c) 널 R-CID가 디폴트인, 작은 ROHC 컨텍스트 식별자들(R-CID : ROHC Context Identifiers)을 이용하는 단계;
    d) 일반 데이터그램 프로토콜(UDP) 첵섬을 전송하지 않고, 압축 해제기에서 UDP 첵섬을 선택적으로 재계산하는 단계;
    e) 임의의 한 패킷 흐름 동안, 상기 전체 캡슐화 프로토콜 헤더를 스태틱 컨텍스트의 일부로서 고려하는 단계;
    f) 실시간 프로토콜(RTP) 시퀀스 번호 및/또는 인터넷 프로토콜 식별만을 전송하는 단계;
    g) 압축기에서 "초기화 및 리프레시"(IR : Initialization and Refresh), "1 차"(FO) 및 "2 차"(SO) 상태들 사이의 전이와, 압축 해제기에서 "컨텍스트 없음"(NC : No Context), "스태틱 컨텍스트"(SC) 및 "전체 컨텍스트"(FC : Full Context) 상태들 사이의 전이를 규정하는 단계 중 하나 이상을 포함하는, 패킷-기반 무선 전송 방법.
  10. 제 1 항 내지 제 9 항 중 어느 한 항에 있어서, 미리 결정된 상기 프레임들만이 상기 헤더 압축 기술을 이용하여 압축되도록 캡슐화 프레임들을 분류하는 단계를 포함하는, 패킷-기반 무선 전송 방법.
  11. 제 1 항 내지 제 10 항 중 어느 한 항에 있어서, 실시간 프로토콜(RTP), 일반 데이터그램 프로토콜(UDP) 및 인터넷 프로토콜(IP) 중 하나 이상에 따라 헤더들을 상기 페이로드에 적용하는 단계를 포함하는, 패킷-기반 무선 전송 방법.
  12. 제 1 항 내지 제 11 항 중 어느 한 항에 있어서, 채널들간 통신하기 위해 복수의 논리적 채널들을 구성하는 상기 유닛들을 포함하며, 적어도 하나의 상기 채널은 상기 압축된 캡슐화된 패킷들의 전송에 전용인, 패킷-기반 무선 전송 방법.
  13. 제 1 항 내지 제 12 항 중 어느 한 항에 있어서, 상기 헤더 압축 기술을 윈도우-최하위 비트 코딩(W-LSB : Window-Least Significant Bit coding)에 기초하는 단계를 포함하는, 패킷-기반 무선 전송 방법.
  14. 제 1 항 내지 제 13 항 중 어느 한 항에 있어서, 에러 복구 요청들 및 선택적으로, 컨텍스트 갱신들의 확인 응답들(acknowledgement)을 위해 적응된 상기 유닛들 사이에 피드백 채널을 제공함으로써, 압축기 및 압축 해제기 상태들 사이의 스위칭을 관리하는 단계를 포함하는, 패킷-기반 무선 전송 방법.
  15. 제 1 항 내지 제 14 항 중 어느 한 항에 있어서, 기저대역 패킷들로 세그먼트된 상기 압축된 캡슐화된 프레임들을 연속으로 수신하고, 다음 상기 패킷이 전송되기 전에 각각의 상기 패킷을 긍정적으로 확인 응답하는 상기 유닛을 포함하고, 최종 상기 패킷 또는 확인 응답 메시지에서 전송 에러가 발생하는 경우에, 상기 최종 패킷은 재전송되는, 패킷-기반 무선 전송 방법.
  16. 제 15 항에 있어서,
    a) 기저대역 패킷 액세스 코드가 수신되지 않은 경우;
    b) 정정할 수 없는 에러가 기저대역 패킷 헤더 내에 존재하는 경우;
    c) 정정할 수 없는 에러가 상기 패킷의 상기 페이로드 내에 존재하는 경우 중 적어도 한 경우에 상기 패킷을 재전송하는 단계를 포함하는, 패킷-기반 무선 전송 방법.
  17. 제 1 항 내지 제 16 항 중 어느 한 항에 있어서, 예를 들어 상기 프레임의 성공적인 전달을 위해, 타임아웃을 설정함으로써 상기 압축된 캡슐화된 프레임에 대한 다수의 재전송들을 한정하는 단계를 포함하는, 패킷-기반 무선 전송 방법.
  18. 제 1 유닛과 제 2 유닛 사이의 패킷-기반 무선 전송을 실행하는 소프트웨어 제품에 있어서,
    a) 실시간 비트스트림을 미리 결정된 최대 길이의 하나 이상의 페이로드들로 변환하고;
    b) 미리 규정된 통신 프로토콜에 따라 상기 유닛들 사이의 전송에 적합한 패킷들을 발생하기 위하여 하나 이상의 미리 규정된 헤더들을 상기 페이로드 또는 각각의 상기 페이로드에 적용하고;
    c) 상기 유닛들 사이의 무선 접속을 가로질러 상기 패킷 또는 각각의 상기 패킷을 전송하도록 적응된 캡슐화 프로토콜의 프레임 내에서 상기 패킷 또는 각각의 상기 패킷을 캡슐화하고; 및
    d) 미리 규정된 헤더 압축 기술을 상기 캡슐화된 패킷 또는 각각의 상기 캡슐화된 패킷에 적용하기 위한 코드를 포함하는 소프트웨어 제품.
  19. 실질적으로 실시간으로 제 2 유닛에 정보를 전달하도록 적응된 제 1 유닛을 포함하는 패킷 기반 무선 통신 장치에 있어서, 상기 제 1 유닛은,
    a) 실시간 비트스트림을 미리 결정된 최대 길이의 하나 이상의 페이로드들로 변환하고;
    b) 미리 규정된 통신 프로토콜에 따라 상기 유닛들 사이의 전송에 적합한 패킷들을 발생하기 위하여 하나 이상의 미리 규정된 헤더들을 상기 페이로드 또는 각각의 상기 페이로드에 적용하고;
    c) 상기 유닛들 사이의 무선 접속을 가로질러 상기 패킷 또는 각각의 상기 패킷을 전송하도록 적응된 캡슐화 프로토콜의 프레임 내에서 상기 패킷 또는 각각의 상기 패킷을 캡슐화하고; 및
    d) 미리 규정된 헤더 압축 기술을 상기 캡슐화된 패킷 또는 각각의 상기 캡슐화된 패킷에 적용하도록 적응되는, 패킷 기반 무선 통신 장치.
  20. 제 19 항에 있어서, 상기 제 1 유닛은 BluetoothTM프로토콜에 따라 동작할 수 있고, 상기 캡슐화된 프로토콜은 바람직하게, 블루투스 네트워크 캡슐화 프로토콜(BNEP)을 포함하며, 상기 헤더 압축 기술은 바람직하게, 인터넷 엔지니어링 태스크 포스(IETF), 로버스트 헤더 압축(ROHC) 기술과 양립할 수 있는, 패킷 기반 무선 통신 장치.
  21. 제 1 항 내지 제 19 항 중 어느 한 항의 방법에 따라 동작하고, 바람직하게 BluetoothTM통신 네트워크의 마스터 유닛 및 슬레이브 유닛 중 적어도 하나로서 적어도 일시적으로 구성되도록 적응된 무선 통신 유닛.
KR10-2004-7006777A 2001-11-06 2002-10-24 헤더 압축한 무선 통신 장치들 KR20040053278A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP01204215.6 2001-11-06
EP01204215 2001-11-06
PCT/IB2002/004459 WO2003041424A2 (en) 2001-11-06 2002-10-24 Wireless communication arrangements with encapsulation and header compression

Publications (1)

Publication Number Publication Date
KR20040053278A true KR20040053278A (ko) 2004-06-23

Family

ID=8181187

Family Applications (1)

Application Number Title Priority Date Filing Date
KR10-2004-7006777A KR20040053278A (ko) 2001-11-06 2002-10-24 헤더 압축한 무선 통신 장치들

Country Status (7)

Country Link
US (1) US20040264433A1 (ko)
EP (1) EP1514431A2 (ko)
JP (1) JP2005509381A (ko)
KR (1) KR20040053278A (ko)
CN (1) CN1636374A (ko)
AU (1) AU2002339605A1 (ko)
WO (1) WO2003041424A2 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100703494B1 (ko) * 2004-08-09 2007-04-03 삼성전자주식회사 이동통신 시스템에서 사용자 데이터 프로토콜 체크섬을 포함하는 음성패킷망의 패킷 송/수신 방법 및 장치
KR20110026291A (ko) * 2009-09-07 2011-03-15 삼성전자주식회사 무선통신시스템에서 로버스트 헤더 압축을 지원하기 위한 시스템 및 방법

Families Citing this family (93)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7136395B2 (en) * 2000-11-30 2006-11-14 Telefonaktiebolaget L M Ericsson (Publ) Method and system for transmission of headerless data packets over a wireless link
US7165112B2 (en) * 2001-06-22 2007-01-16 Motorola, Inc. Method and apparatus for transmitting data in a communication system
US7324516B2 (en) * 2002-08-14 2008-01-29 Intel Corporation Data packet header conversion
US7647421B2 (en) * 2002-08-20 2010-01-12 Nokia Corporation Extension header compression
US8270423B2 (en) 2003-07-29 2012-09-18 Citrix Systems, Inc. Systems and methods of using packet boundaries for reduction in timeout prevention
US7630305B2 (en) 2003-07-29 2009-12-08 Orbital Data Corporation TCP selective acknowledgements for communicating delivered and missed data packets
US7616638B2 (en) 2003-07-29 2009-11-10 Orbital Data Corporation Wavefront detection and disambiguation of acknowledgments
US8238241B2 (en) 2003-07-29 2012-08-07 Citrix Systems, Inc. Automatic detection and window virtualization for flow control
US8437284B2 (en) 2003-07-29 2013-05-07 Citrix Systems, Inc. Systems and methods for additional retransmissions of dropped packets
US8432800B2 (en) 2003-07-29 2013-04-30 Citrix Systems, Inc. Systems and methods for stochastic-based quality of service
US7822067B2 (en) 2003-08-08 2010-10-26 Qualcomm Incorporated Header compression enhancement for broadcast/multicast services
US7372843B1 (en) * 2003-09-23 2008-05-13 Cisco Technology, Inc. System and method for compressing information flows in a network environment
US7269388B2 (en) * 2003-12-01 2007-09-11 Microsoft Corporation Bluetooth pan driver
JP4143547B2 (ja) * 2004-01-21 2008-09-03 Ｎｅｃアクセステクニカ株式会社 データ通信システム
US7957389B2 (en) * 2004-03-31 2011-06-07 Alcatel-Lucent Usa Inc. Method of stall identification and recovery
EP1603339A1 (en) * 2004-06-01 2005-12-07 STMicroelectronics S.r.l. Method and system for communicating video data in a packet-switched network, related network and computer program product therefor
US8031644B2 (en) 2004-06-23 2011-10-04 Nokia Corporation Non-native media codec in CDMA system
US8254379B1 (en) * 2004-07-15 2012-08-28 Sprint Spectrum L.P. Method and system for application based compression profile selection
US20060039353A1 (en) * 2004-08-23 2006-02-23 Samuel Louis G Extended voice over internet protocol
US7675895B2 (en) 2004-09-14 2010-03-09 Alcatel-Lucent Usa Inc. Method and apparatus for wireless communication using voice over internet protocol
US9197857B2 (en) 2004-09-24 2015-11-24 Cisco Technology, Inc. IP-based stream splicing with content-specific splice points
US8966551B2 (en) 2007-11-01 2015-02-24 Cisco Technology, Inc. Locating points of interest using references to media frames within a packet flow
US8165104B2 (en) 2004-12-08 2012-04-24 Qualcomm Incorporated Methods and systems for enhancing local repair in robust header compression
US7633879B2 (en) * 2004-12-13 2009-12-15 Cisco Technology, Inc. Method and apparatus for discovering the incoming media path for an internet protocol media session
US7656853B2 (en) * 2004-12-27 2010-02-02 Microsoft Corporation Reducing power consumption of a wireless device
US20060205449A1 (en) * 2005-03-08 2006-09-14 Broadcom Corporation Mechanism for improved interoperability when content protection is used with an audio stream
US8009699B2 (en) * 2005-07-12 2011-08-30 Qualcomm Incorporated Efficient encoding of out of order data packets in a network
US9031071B2 (en) 2005-08-26 2015-05-12 Alcatel Lucent Header elimination for real time internet applications
US20090052446A1 (en) * 2005-09-06 2009-02-26 Nicholas Farrow Communications Interface
WO2007031090A1 (en) * 2005-09-15 2007-03-22 Aalborg Universitet A method of compressing the header of a data packet
KR100800878B1 (ko) 2005-09-23 2008-02-04 삼성전자주식회사 이동통신 시스템에서 사용자 데이터 프로토콜 체크섬을포함하는 음성패킷의 송수신 방법 및 장치
EP1773004A1 (en) 2005-10-10 2007-04-11 Nec Technologies (UK) Limited Header compression optimisation method during and after handovers in a cellular communication network
US20070086434A1 (en) * 2005-10-19 2007-04-19 Muthaiah Venkatachalam Efficient mechanisms for supporting VoIp in a wireless network
US8325600B2 (en) * 2005-12-30 2012-12-04 Intel Corporation Segmentation interleaving for data transmission requests
US7907609B2 (en) * 2006-01-06 2011-03-15 Qualcomm, Incorporated Method and apparatus for enhancing RoHC performance when encountering silence suppression
WO2007091207A1 (en) * 2006-02-07 2007-08-16 Nokia Corporation Providing and handling information on a state of a media stream
JP2007258817A (ja) * 2006-03-20 2007-10-04 Fujitsu Ltd パケット伝送装置
US7936694B2 (en) * 2006-04-03 2011-05-03 Hewlett-Packard Development Company, L.P. Sniffing-based network monitoring
US8750334B2 (en) * 2006-10-02 2014-06-10 Motorola Mobility Llc Link layer assisted robust header compression context update management
JP2008141254A (ja) * 2006-11-29 2008-06-19 Kyocera Corp 通信方法及び送信装置並びに受信装置
US8027328B2 (en) * 2006-12-26 2011-09-27 Alcatel Lucent Header compression in a wireless communication network
US7899025B2 (en) * 2006-12-26 2011-03-01 Alcatel-Lucent Usa Inc. Header suppression in a wireless communication network
US7813296B2 (en) * 2006-12-27 2010-10-12 Telefonaktiebolaget L M Ericsson (Publ) Adapting transmission and reception time in packet based cellular systems
DE102007018832B3 (de) 2007-04-20 2008-08-28 Siemens Ag Österreich Verfahren und Einrichtung zur Reduktion der Datenmenge in einem paketorientiertem Datennetz
US8064390B2 (en) 2007-04-27 2011-11-22 Research In Motion Limited Uplink scheduling and resource allocation with fast indication
US20080267168A1 (en) * 2007-04-27 2008-10-30 Zhijun Cai Slow Adaptation of Modulation and Coding for Packet Transmission
US7936695B2 (en) 2007-05-14 2011-05-03 Cisco Technology, Inc. Tunneling reports for real-time internet protocol media streams
US8023419B2 (en) 2007-05-14 2011-09-20 Cisco Technology, Inc. Remote monitoring of real-time internet protocol media streams
WO2008151411A1 (en) * 2007-06-15 2008-12-18 Research In Motion Limited System and method for large packet delivery during semi persistently allocated session
CN101682857B (zh) * 2007-06-15 2013-10-30 捷讯研究有限公司 用于减小链路适配开销的系统和方法
CN102970764B (zh) 2007-06-15 2015-07-15 黑莓有限公司 用于半永久和动态调度以及间断接收控制的系统和方法
US7835406B2 (en) 2007-06-18 2010-11-16 Cisco Technology, Inc. Surrogate stream for monitoring realtime media
US20090003347A1 (en) * 2007-06-29 2009-01-01 Yang Tomas S Backhaul transmission efficiency
US7817546B2 (en) 2007-07-06 2010-10-19 Cisco Technology, Inc. Quasi RTP metrics for non-RTP media flows
KR101377961B1 (ko) * 2007-07-27 2014-03-25 엘지전자 주식회사 헤더 오버헤드 감소를 위한 패킷 전송 방법
US20090034529A1 (en) * 2007-07-30 2009-02-05 Motorola, Inc. Method and apparatus for routing packets via header-compression channels
CN101364980B (zh) 2007-08-10 2012-06-20 华为技术有限公司 建立头压缩通信的方法及系统、头压缩策略功能实体
US20090046639A1 (en) * 2007-08-14 2009-02-19 Zhijun Cai System and Method for Handling Large IP Packets During VoIP Session
US8265080B2 (en) 2007-08-20 2012-09-11 Motorola Mobility Llc System and method for retransmissions in a discontinuous reception configured system
EP2632210A1 (en) 2007-09-14 2013-08-28 Research In Motion Limited System and method for discontinuous reception control start time
TWI395976B (zh) * 2008-06-13 2013-05-11 Teco Image Sys Co Ltd 掃描模組之光源投射裝置及其光源排列方法
US8031607B2 (en) * 2009-01-29 2011-10-04 Alcatel Lucent Implementation of internet protocol header compression with traffic management quality of service
US8254837B2 (en) * 2009-04-23 2012-08-28 Motorola Mobility Llc Establishing full-duplex audio over an asynchronous bluetooth link
US20110016313A1 (en) * 2009-07-15 2011-01-20 Qualcomm Incorporated HEADER COMPRESSION FOR TUNNELED IPsec PACKET
JP5278222B2 (ja) * 2009-07-22 2013-09-04 富士通株式会社 無線通信装置、無線通信方法および無線通信プログラム
US8886790B2 (en) * 2009-08-19 2014-11-11 Opanga Networks, Inc. Systems and methods for optimizing channel resources by coordinating data transfers based on data type and traffic
US8301982B2 (en) 2009-11-18 2012-10-30 Cisco Technology, Inc. RTP-based loss recovery and quality monitoring for non-IP and raw-IP MPEG transport flows
CN102215513B (zh) * 2010-04-02 2013-10-30 联芯科技有限公司 一种IPv4包头变化规律的检测方法和系统
CN101867572B (zh) * 2010-05-11 2015-08-12 中兴通讯股份有限公司 无线优盘的实现方法及系统
US8819714B2 (en) 2010-05-19 2014-08-26 Cisco Technology, Inc. Ratings and quality measurements for digital broadcast viewers
JP5734680B2 (ja) * 2011-01-26 2015-06-17 京セラ株式会社 移動通信方法及び基地局
RU2469244C1 (ru) * 2011-06-08 2012-12-10 Валерий Игнатьевич Гуров Водонагревательное устройство
CN102869044A (zh) * 2011-07-08 2013-01-09 联芯科技有限公司 分组域通信中标签形成方法、分组域通信方法及终端
US9331920B2 (en) * 2012-01-25 2016-05-03 Cisco Technology, Inc. Media path monitoring over a secure network
TWI524688B (zh) * 2012-07-13 2016-03-01 瑞昱半導體股份有限公司 藍牙服務估測裝置及其藍牙服務估測方法
US9973596B2 (en) * 2013-06-19 2018-05-15 Cisco Technology, Inc. Dynamically adjusting frame MTU to support low-latency communication
US9398253B2 (en) * 2013-07-26 2016-07-19 Qualcomm Incorporated Video pause indication in video telephony
JP6055389B2 (ja) * 2013-10-08 2016-12-27 株式会社Ｎｔｔドコモ 無線基地局
KR102192165B1 (ko) * 2013-11-25 2020-12-16 삼성전자주식회사 전자 장치에서 헤더 압축된 패킷을 처리하기 위한 장치 및 방법
US10856021B2 (en) 2015-03-11 2020-12-01 Lg Electronics Inc. Broadcast signal transmission apparatus, broadcast signal reception apparatus, broadcast signal transmission method, and broadcast signal reception method
US10834065B1 (en) 2015-03-31 2020-11-10 F5 Networks, Inc. Methods for SSL protected NTLM re-authentication and devices thereof
US9756455B2 (en) * 2015-05-28 2017-09-05 Sony Corporation Terminal and method for audio data transmission
US10404698B1 (en) 2016-01-15 2019-09-03 F5 Networks, Inc. Methods for adaptive organization of web application access points in webtops and devices thereof
US11071131B2 (en) 2016-01-26 2021-07-20 Ntt Docomo, Inc. Base station and transmission method
WO2019058418A1 (ja) * 2017-09-19 2019-03-28 株式会社日立国際電気 通信装置
KR102652451B1 (ko) * 2018-01-29 2024-04-01 코닌클리케 필립스 엔.브이. 블루투스 기반 ipv6 저전력 네트워킹
EP4030738A1 (en) * 2018-03-16 2022-07-20 Acklio Method and apparatus for processing message data
CN110971363B (zh) 2018-09-28 2022-03-08 华为技术有限公司 用于以太网数据的通信方法的方法和装置
US10979399B2 (en) * 2019-05-24 2021-04-13 Sierra Nevada Corporation Unified communication gateway systems
CN110727542B (zh) * 2019-09-18 2023-02-28 陕西法士特齿轮有限责任公司 一种Hex文件处理方法及应用
US11330665B2 (en) * 2020-01-09 2022-05-10 Qualcomm Incorporated Increasing throughput efficiency in a PDCP channel with ROHC TCP profile
CN115250137A (zh) * 2021-04-28 2022-10-28 合肥炬芯智能科技有限公司 蓝牙设备、蓝牙系统及其音频传输方法
CN113709510A (zh) * 2021-08-06 2021-11-26 联想(北京)有限公司 高速率数据实时传输方法及装置、设备、存储介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5940431A (en) * 1996-12-23 1999-08-17 Telefonaktiebolaget Lm Ericsson Access technique of channel hopping communications system
EP1107520A1 (en) * 1999-12-06 2001-06-13 Telefonaktiebolaget Lm Ericsson Method and arrangement in a communication network
EP1107508A1 (en) * 1999-12-06 2001-06-13 Telefonaktiebolaget Lm Ericsson System, method and computer program product for sending broadcast messages
US6608841B1 (en) * 1999-12-30 2003-08-19 Nokia Networks Oy System and method for achieving robust IP/UDP/RTP header compression in the presence of unreliable networks
US6931051B2 (en) * 2000-03-01 2005-08-16 Texas Instruments Incorporated Frequency hopping wireless communication system with filtered adaptive slicer

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100703494B1 (ko) * 2004-08-09 2007-04-03 삼성전자주식회사 이동통신 시스템에서 사용자 데이터 프로토콜 체크섬을 포함하는 음성패킷망의 패킷 송/수신 방법 및 장치
KR20110026291A (ko) * 2009-09-07 2011-03-15 삼성전자주식회사 무선통신시스템에서 로버스트 헤더 압축을 지원하기 위한 시스템 및 방법

Also Published As

Publication number Publication date
AU2002339605A1 (en) 2003-05-19
WO2003041424A3 (en) 2004-05-27
US20040264433A1 (en) 2004-12-30
CN1636374A (zh) 2005-07-06
EP1514431A2 (en) 2005-03-16
JP2005509381A (ja) 2005-04-07
WO2003041424A2 (en) 2003-05-15

Similar Documents

Publication Publication Date Title
KR20040053278A (ko) 헤더 압축한 무선 통신 장치들
JP2005509381A6 (ja) ヘッダ圧縮を行う無線通信装置
JP3559271B2 (ja) ヘッダフィールド圧縮時のコンテキスト識別子の定義方法
CA2429571C (en) Method and system for transmission of headerless data packets over a wireless link
Bormann et al. RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed
EP2098035B1 (en) Improved header compression in a wireless communication network
JP3751823B2 (ja) 実時間サービスにおけるヘッダ圧縮
JP2005525049A (ja) パケット通信によるワイヤレス通信アレンジメント
US8260287B2 (en) Mobile communication method and system
US8310988B2 (en) Method of MAC header generation and data transmitting
US20090268667A1 (en) Header compression mechanism for transmitting RTP packets over wireless links
JP3650362B2 (ja) 高遅延狭帯域幅ワイヤレス・システムにおいてスパースなフィードバックを提供する方法
NO20034054L (no) Etablering av flere kvalitetsnivåer for tjenester innen trådlös pakkekommunikasjon
WO2008085337A2 (en) Adaptive header compression in a wireless communication network
US20030002467A1 (en) Internet protocol framing using radio link protocol
US8537741B2 (en) Method of header compression over channels with out-of-order delivery
RU2316906C2 (ru) Способ передачи пакетных данных в системе связи
Ayadi et al. Implementation and evaluation of a TCP header compression for 6LoWPAN
KR101169724B1 (ko) 무선링크에 최적화된 헤더압축장치 및 그 방법
Marzegalli et al. Adaptive RTP/UDP/IP header compression for VoIP over Bluetooth
Fitzek et al. Header Compression Schemes for Wireless Internet Access
Kishi et al. A new inter-core built-in-self-test circuits for tri-state buffers in the system on a chip
Ayed et al. Enhancing robust header compression over IEEE 802 networks
Madsen Cooperative header compression
Yoshimura et al. Network Working Group C. Bormann, Editor, TZI/Uni Bremen Request for Comments: 3095 C. Burmeister, Matsushita Category: Standards Track M. Degermark, Univ. of Arizona H. Fukushima, Matsushita H. Hannu, Ericsson

Legal Events

Date Code Title Description
WITN Application deemed withdrawn, e.g. because no request for examination was filed or no examination fee was paid