KR100918961B1 - 무선 통신망에서 동적 영역 압축 및 ｎｃｂ 결정방법 - Google Patents

무선 통신망에서 동적 영역 압축 및 ｎｃｂ 결정방법 Download PDF

Info

Publication number
KR100918961B1
KR100918961B1 KR1020070101498A KR20070101498A KR100918961B1 KR 100918961 B1 KR100918961 B1 KR 100918961B1 KR 1020070101498 A KR1020070101498 A KR 1020070101498A KR 20070101498 A KR20070101498 A KR 20070101498A KR 100918961 B1 KR100918961 B1 KR 100918961B1
Authority
KR
South Korea
Prior art keywords
compression
ncb
compressor
state
bit
Prior art date
Application number
KR1020070101498A
Other languages
English (en)
Other versions
KR20090036355A (ko
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 강릉원주대학교산학협력단
Priority to KR1020070101498A priority Critical patent/KR100918961B1/ko
Publication of KR20090036355A publication Critical patent/KR20090036355A/ko
Application granted granted Critical
Publication of KR100918961B1 publication Critical patent/KR100918961B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/184—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being bits, e.g. of the compressed video stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/85—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

본 발명은 IP 프로토콜을 사용하는 무선 통신망에서 효율적인 데이터 전송을 위한 압축방법에 관한 것이다. 즉, 본 발명에서는 IP 프로토콜을 사용하는 무선 통신망에서 음성이나 비디오 트래픽과 같은 실시간 멀티미디어 데이터 전송을 위한 압축방식에 있어서, 네트워크의 상태, 전송데이터의 종류 등을 고려하여 압축기와 압축해제기간 RTP 헤더를 구성하는 여러 영역들 중에서 동적으로 일률적으로 증가하는 동적 영역을 가장 높은 압축률로 압축하는 방식을 통해 비싼 무선 대역폭의 낭비를 방지시킬 수 있으며, 전송 패킷의 크기를 줄임으로써 패킷 스트림의 용량을 증가시킬 수 있다. 또한 ROHC 등의 견고한 헤더 압축 알고리즘을 사용하면 IPv6에서 사용되고 있던 60바이트 헤더가 1바이트로 줄어들게 되어 주파수 대역폭을 크게 개선시킬 수 있다.
IP, 무선, 네트워크, 압축, BCB, NCB

Description

무선 통신망에서 동적 영역 압축 및 ＮＣＢ 결정방법{METHOD FOR COMPRESSING DYNAMIC AREA AND DECIDING NCB IN WIRELESS COMMUNICATION NETWORK}
본 발명은 IP 프로토콜(protocol)을 사용하는 무선 통신망(wireless network)에서 효율적인 데이터 전송을 위한 압축방법에 관한 것으로, 특히 IP 프로토콜을 사용하는 무선 통신망에서 음성이나 비디오 트래픽과 같은 실시간 멀티미디어 데이터 전송에 있어서 압축기(compressor)와 복원기(decompressor)간 네트워크의 상태, 전송데이터의 종류 등을 고려하여 실시간으로 통신 양단간의 압축률을 결정함으로써 최적의 압축효율을 구현할 수 있도록 하는 무선 통신망의 동적 영역 압축 및 협상압축비트(negotiation compression bit : 이하 "NCB" 라함) 결정방법에 관한 것이다.
통상적으로, RTP/UDP/IP 패킷의 헤더길이를 줄이는 헤더압축 방법으로 RFC 2507, RFC3095 방법이 있으며, 최근 IETF는 RFC 3095를 헤더압축의 표준의 하나로 채택하였다. 이는 IP 프로토콜을 사용하는 무선 링크를 대상으로 한 것으로, RFC 3095는 패킷(packet)의 크기(size)를 줄여서 스펙트럼 효율성과 패킷 손실, 그리고 지연을 줄임으로써 무선 네트워크에서의 상호 작용성을 증가시킬 것으로 보인다.
특히, 무선 통신 링크들은 유선 네트워크에는 적용되지 않는 다양한 조건에 직면하기 때문에 에러율(error rate)이 높아지게 되고, 이에 따라 패킷의 손실이 발생하게 된다. 이러한 문제는 무선 네트워크와 같이 왕복시간이 긴 경우에 더욱 악화되며, 정상적인 패킷 전송을 확인하는데 많은 시간이 소모되므로 음성 품질에 영향을 미치게 된다.
또한, IP 패킷의 높은 오버헤더(overhead)는 어떤 무선 링크에서든지 주파수 효율을 떨어뜨리게 된다. 인터넷 프로토콜인 IPv4에 있어서는 모바일 핸드셋(mobile handset)을 통해 IP상에서 음성을 전달할 수 있지만 헤더에서 거의 66% 정도의 대역폭이, 그리고 IPv6에서는 75%까지 낭비되는 문제점이 있었다.
따라서 본 발명은 종래 압축기와 압축해제기간 헤더압축에 있어서 IP 패킷의 높은 오버헤더로 인해 무선 링크에서 주파수 효율이 떨어지는 문제점을 해결하기 위해 안출된 것으로, RTP 헤더를 구성하는 여러 영역들 중에서 동적으로 일률적으로 증가하는 동적 영역을 가장 높은 압축률로 압축하는 방법을 제안하고, 압축기와 압축해제기간 협정에 의해 전송되는 패킷구조를 최적의 헤더압축을 위한 구조로 설계하여 압축효율을 높이도록 하는 IP 프로토콜을 이용한 무선 통신망에서 동적 영 역 압축 및 NCB 결정방법을 제공함에 있다.
상술한 본 발명은 IP 프로토콜을 사용하는 무선 통신망에서 효율적인 데이터 전송을 위한 압축방법으로서, (a)무선 통신망상 전송노드의 압축기와 목적지 노드의 복원기간 데이터 전송시 SN(sequential number)과 TS(time stamp)의 압축을 위한 기본압축비트(BCB)를 결정하는 단계와, (b)상기 압축기와 복원기간 협상을 통해 RTP로 운반되는 유류부하(payload) 트래픽의 특성에 따라 추가의 n비트를 산출하여 최종 협상압축비트(NCB)를 결정하는 단계와, (c)상기 압축기와 복원기간 결정된 상기 NCB로 상기 SN과 TS를 압축하여 데이터 송/수신을 수행하는 단계를 포함하는 것을 특징으로 한다.
본 발명에서는 IP 프로토콜을 사용하는 무선 통신망에서 멀티미디어 데이터 전송을 위한 압축방식에 있어서, 네트워크의 상태, 전송데이터의 종류 등을 고려하여 압축기와 압축해제기간 RTP 헤더를 구성하는 여러 영역들 중에서 동적으로 일률적으로 증가하는 동적 영역을 가장 높은 압축률로 압축하는 방식을 통해 비싼 무선 대역폭의 낭비를 방지시킬 수 있으며, 전송 패킷의 크기를 줄임으로써 패킷 스트림의 용량을 증가시킬 수 있는 이점이 있다. 또한 ROHC 등의 견고한 헤더 압축 알고리즘을 사용하면 IPv6에서 사용되고 있던 60바이트 헤더가 1바이트로 줄어들게 되 어 주파수 대역폭을 크게 개선시킬 수 있는 이점이 있다.
이하, 첨부된 도면을 참조하여 본 발명의 동작 원리를 상세히 설명한다. 하기에서 본 발명을 설명함에 있어서 공지 기능 또는 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략할 것이다. 그리고 후술되는 용어들은 본 발명에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.
본 발명의 구체적인 핵심 기술요지를 살펴보면, IP 프로토콜을 사용하는 무선 통신망에서 효율적인 데이터 전송을 위한 압축방법에 있어서, RTP 헤더를 구성하는 여러 영역들 중에서 동적으로 일률적으로 증가하는 동적 영역을 가장 높은 압축률로 압축하는 기술과, 압축기와 압축해제기간 협정에 의해 전송되는 패킷구조를 최적의 헤더압축을 위한 구조로 설계하여 압축효율을 높이도록 하는 기술을 통해 본 발명에서 이루고자 하는 바를 쉽게 달성할 수 있다.
도 1은 본 발명의 실시 예가 적용되는 압축기와 압축 해제기간 전송되는 데이터 처리 개념을 도시한 것으로, 이하 IP 프로토콜을 사용하는 무선 통신망상 압축기(compressor)(100)와 복원기(decompressor)(102)간 데이터 송/수신을 위한 압 축설정에 대해서 상세히 설명하기로 한다.
먼저, 위와 같은 압축기(100)와 복원기(102)간 헤더 압축(header compression)에 있어서는 우선적으로 압축기(100)와 복원기(102)간 동적(dynamic) 영역을 몇 비트(bit)로 정할 것인지를 결정하게 된다. 이 값은 기본압축비트(basic compression bit: 이하 "BCB" 라함)인 3비트로 결정할 수도 있고, 만일 이 값이 적절하지 않은 경우에는 압축기(100)와 복원기(102)는 RTP로 운반되는 페이로드 트래픽의 특징과 회선의 에러율, 그리고 회선의 속도 등의 조건을 고려하여 압축 비트수를 결정하게 되며, 이를 NCB라 한다. 이때 3비트가 적절한 경우 NCB값은 BCB값과 동일한 값을 가지게 된다.
이때 전송장치인 상기 압축기는 정상(Normal)상태와 압축(Compress)상태로 구성되며, 도 2에서 보여지는 바와 같이 정상상태에서 압축모드로 전이하여 동작하게 되고, 에러 발생시 다시 정상상태로 복원되어 동작하도록 구성된다.
또한, 수신장치인 복원기(102)는 수립(Build) 상태, 정상(Normal) 상태, 복구(Repair) 상태로 구성되며, 도 3에서 보여지는 바와 같이, 수립상태에서는 정상상태와 같이 컨텍스트(context)의 구축과 최초 패킷의 송수신, 그리고 NCB 비트의 협상을 진행한다. 정상상태는 압축상태와 대응하며, 최고의 압축률로 데이터 패킷을 전송하게 한다.
도 4는 위와 같은 압축기(100)와 복원기(102)간 압축비트를 결정하는 과정을 도시한 것으로, 16비트 SN(sequential number)과 32비트 TS(time stamp), 총 48비트를 NCB n비트로 압축할 수 있게 된다.
본 발명에서는 압축기(100)와 복원기(102) 노드간의 SN과 TS에 대한 BCB를 3비트로 설정하며, 압축기(100)와 복원기(102)는 RTP로 운반되는 유류부하(payload) 트래픽(traffic)의 특성에 따라 최종 협상 압축비인 NCB를 결정하고, 그 결과에 의해 SN과 TS를 압축하도록 설계한다.
위 도 2를 참조하면, 압축기(100)와 복원기(102)간 데이터 압축률 설정에 있어, BCB를 3비트로 설정하고(S400), 전송되는 데이터의 종류를 검사한다(S402). 이때 전송되는 데이터가 텍스트(text) 데이터인 경우 BCB 3비트를 압축기(100)와 복원기(102)간 NCB의 비트로 결정하여 전송한다.
그러나, 전송되는 데이터가 멀티 미디어(multimedia) 데이터인 경우 NCB를 BCB+n으로 설정하고(S404), 압축기(100)와 복원기(102)간 조정을 통해 압축 비트수를 결정하게 된다(S404).
즉, 본 발명에서는 압축기(100)와 복원기(102)간 SN 필드(field)의 압축여부와 TS 동적 필드(dynamic field)를 몇 비트로 정할 것인가를 결정함으로써 NCB를 결정하게 된다.
이때, SN 필드의 압축은 복원기(102)의 요구에 의해서만 압축이 이루어지도록 하여 양단간 특별한 옵션이 없는 경우 SN은 압축되지 않도록 하였다. 이는 SN필드는 RTP 패킷의 가장 중요한 필드로서 압축 그리고 복원상의 문제로 인해 손상을 받을 경우 치명적인 오류로 이어질 가능성이 크기 때문이다. 또한, TS 동적필드를 몇 비트로 압축할 것인가는 압축기(100)와 복원기(102)의 N-상태와 Build-상태에 따라 결정하게 되는데, 이때 페이로드 상태, 서비스 타입 등을 고려하여 결정한다. 위와 같은 과정을 거쳐 32비트 TS 필드를 최대 NCB로 압축할 수 있게 되는 것이다.
본 발명에서는 압축기(100)와 복원기(102) 노드간 TS에 대한 NCB를 결정하는 알고리즘을 다음과 같이 제안하였다.
인터넷상의 패킷은 잃어버릴 수 도 있고 지연되거나 패킷순서가 뒤집혀 오는 경우가 있다. 이런 문제를 극복하기 위하여 RTP 헤더에는 시간정보와 일련번호가 포함된다. 시간정보는 수신측에서 정확하게 20ms마다 한 패킷을 재생하는데 사용되고, 일련번호는 순서대로 재생하면서 잃어버린 패킷을 계산하게 된다. 여기서 4바이트 TS는 RTP 데이터 패킷이 처음 발생될 때 만들어지는데 랜덤한 초기치를 갖는다.
그 다음 패킷은 계속 증가되는 값을 갖는데, 어떤 데이터에 대해서는 증가되는 값을 갖지 않을 수 도 있다. 특히 동기화와 지터계산을 위하여 일률적으로 증가되는 클럭을 가져야 한다. 클럭은 동기화를 할 수 있고, 지터의 계산을 충분히 할 수 있도록 세밀하게 해야 한다.
MPEG 스트림(stream)의 경우, RTP를 사용해 비디오를 압축할 경우, 한 개의 패킷은 하나 이상의 그림을 포함하지 않으며, 한 개의 그림은 두 개 이상의 RTP 패킷으로 나누어 질 수도 있다. 이때 두 개로 나누어진 패킷들의 TS값은 같다.
RTP 마커 비트(marker bit)은 하나의 그림을 가지고 만들어진 패킷 중 마지막 패킷에서 1로 설정된다. 그리고 비디오 정보와 관련된 헤더압축 프로파일(profile)은 참조클럭으로 90kHz를 사용한다.
TS는 아래의 [수학식 1]에서와 같이 나타낼 수 있다.
TS=TS_SCALE×TS_STRIDE + TS_OFFSET
여기서 TS는 TS_SCALE×TS_STRIDE + TS+OFFSET으로 나뉘어 생각 할 수 있으며, TS_STRIDE는 보폭이라는 말의 의미처럼 고정적으로 증가하는 값을 말한다.
오디오 데이터의 경우 이 값은 160씩 증가한다. 오디오는 통상 8KHz 샘플링 주파수에 20ms의 주기를 가지므로 TS_STRIDE는 8000×0.02 = 160이 된다. 따라서 오디오데이터를 가지는 RTP패킷의 TS는 거의 160값씩 증가한다고 보면 된다.
MPEG-4 비디오의 경우 이 값은 3000씩 증가한다. MPEG은 코덱(codec)이 90KHz 샘플링에 초당 30프레임을 기본으로 하기 때문에 TS_STRIDE는 90000/30 = 3000이 된다. 물론 무조건 3000씩 증가하는 것이 아니라 0 일 수도 있고 3000보다 더 클 수도 있으므로 일률적으로 이 값을 인덱스처럼 송신 할 수 는 없을 것이다.
위 [수학식 1]에서 알 수 있듯이, TS_STRIDE 값만 알 수 있다면 TS값은 물론, TS_OFFSET, TS_SCALE 값을 알 수 있게 된다.
TS_SCALE은 RTP 패킷발생시점의 시간값이므로 여기에 TS_STRIDE 값을 곱하여 TS 값이 형성된다. 따라서 TS_OFFSET와 TS_SCALE값은 아래의 [수학식 2]에서 같이 구해질 수 있다.
TS_OFFSET=TS mod TS_STRIDE
TS_SCALE = TS/TS_STRIDE
E-ROHC 프로토콜에서는 TS 필드를 압축하기 위하여, 적절한 방식으로 TS_STRIDE값만을 전송하는 방식을 사용할 수 있을 것이다. TS의 값이 항상 일정하게 증가한다면 이 값 자체가 정적필드가 되므로 송신할 필요가 없어지게 되나, TS 값의 증가분이 항상 일정하지는 않다는 문제가 있기 때문에, 송신노드는 일정분의 증가되는 값을 항상 보내야만 한다.
따라서 TS가 0일 때는 0이 송신되어야 하고 TS가 3000일 때는 3000이 전달되어야 한다. 여기서 TS 필드의 압축은 WDELSB(Wrapped around Differential Encoding LSB)방식을 사용하였다. WDELSB 압축방식은 특정 필드값을 송신할 때, 전체 비트를 다 보내는 것이 아니라, 차이가 나는 내용만을 추출(differential)한 후 정해진 비트로 압축하는 방식이다. TS처럼 증가분이 거의 일정한 필드는 전체 비트를 다 송신하는 것이 아니라, 의미를 정확히 전달할 수 있는 범위 내에서, 우측 몇 개의 비트만을 송신하면 된다.
위 WDELSB 방식은 변형된 Delta 값 송신 방식과 같은 방식으로, 같은 스트림 내에서도 계속해서 TS_STRIDE값만큼씩 변한다고 가정할 때, 이 TS_STRIDE 값 범위 만큼씩의 WLSB 값만을 송신한다면, 전체 비트를 송신하는 것보다 많은 비트를 압축할 수 있게 된다.
이에 따라 본래의 TS 필드를 완벽히 복원 가능한 범위 내에서, 송신해야할 최소의 비트를 어떻게 구할 것인가를 다음과 같이 유도하였다.
먼저 원하는 트래픽의 TS_STRIDE값에 대한 최소 압축 비트수 k를 구하는 함 수 g(Vref, k)를 아래의 [수학식 3]에서 같이 정의하였다.
Figure 112007072404615-pat00001
여기서 Vref 는 참조주파수 Freqref를 가지는 트래픽을 나타내는 의미이고, k는 최소 압축비트를 나타낸다. 이때 같은 스트림 내에서도 TS값은 변할 수 있기 때문에, NCB값의 범위를 최소값(min)과 최대(max)값만큼으로 정의해야 한다. Vrefmin는 해당 프레임에서 최소 TS_STRIDE 일때의 프레임이고, Vrefmax는 해당 프레임에서 최대 TS_STRIDE 일 때의 프레임이이다.
따라서, NCB값을 구하는 식을 아래의 [수학식 4]와 같이 나타낼 수 있다.
Figure 112007072404615-pat00002
여기서, MPEG 비디오 프레임의 프레임 주파수가 최소값과 최대값 범위 내에서 바뀔 때마다 TS_STRIDE값이 변할 수 있기 때문에 위 [수학식 4]와 같이 NCB값을 그 범위에 맞도록 결정해 놓으면 원래의 TS필드를 복원할 수 있게 된다. 즉, 압축기(100)로부터 32비트 TS값이 최대 NCB(0≤n<32)로 압축되어 송신된다. 이것을 위 [수학식 4]에 대입하여 계산한 결과, 스트림이 길거나 큰 용량의 비디오 트래픽은 12비트에 근접하는 값으로, 오디오 파일 같은 작은 트래픽은 7비트내외로 압축하면 된다.
이어, 압축기(100)와 복원기(102)간 윈도우 사이즈 협상에 대해 살펴보기로 한다. 압축기(100)와 복원기(102) 사이에 압축통신이 이루어질 때 E-ROHC는 복원기의 ACK나 NAK 수신 없이 압축된 패킷을 송신한다.
이때, 압축기(100)의 N-상태, 복원기(102)의 Build-상태 동안 윈도사이즈 WD_send(Packets)를 결정한다. 그리고 최초 결정된 WD_send값은 수시로 압축기(100)와 복원기(102) 간의 상호 요구에 의해 재협상한다.
E-ROHC에서 제안하는 윈도사이즈 WD_send(packets) 산출수식은 아래의 [수학식 5]에서와 같다.
Figure 112007072404615-pat00003
여기서 MTU(Maximum Transmission Unit)는 기 설정되어있는 최대 전송유닛이고, BER_rev_value는 송수신단에서 협상한 BER값의 -1승 값을 기본으로 가감한 값이다. 이 링크의 BER(Bit Error Rate)이 10-5이면, (10-5)-1은 105=100000이 된다. 이때 MTU가 4000비트라면, WD_send(packets)는 25(packets)가 된다. 이 값을 프레임의 최대 전송단위 MTU로 나눈 값을 기본적인 윈도사이즈 WD_send(packets)로 정의한다.
위 과정을 좀더 상세히 설명하면, 우선 압축기(100)는 복원기(102)에게 BER_request라는 제어신호를 보낸다. 이 패킷은 WD_send 값의 협상을 요구하는 패킷으로 현재 이 링크의 BER값이 들어가 있다. 그러면, 복원기(102)는 수신한 BER_request 값을 체크한 후, 적당히 가감한 값(BER_rev_value=BER-1)을 확인 송신한다. 이에 따라, 압축기(100)는 수신한 BER__rev_value 값을 이용하여 MTU값과의 비율을 구한 후 WD_send(packets)값을 확정한다. 이 값을 BER_reconfirm 제어패킷을 이용하여 복원기(102)에 송신한다.
이어, 압축기와 복원기간 동적 영역의 압축 협상에 대해 살펴보기로 한다.
먼저 SN(Sequential Number) 압축을 설명하면, RTP에서 순서번호 SN을 구성하는 기존의 방식은 연속된 패킷의 순서번호를 1씩 증가시키는 것으로, 16비트 순서번호를 가진 RTP 패킷이라면 0 - 65535 까지 1씩 증가된다. 이는 수신 측에서 패킷의 손실을 발견하기 쉽기 때문이다.
그러나 보다 더 높은 압축률을 달성하기 위하여, SN의 증가분은 일정값의 배수로 변하도록 설계할 것을 제안하며, 이에 따라 n번째 패킷의 SN이 3000일때, n+1번째 패킷의 SN은 3000 + 8(23) = 3008이 된다. 따라서 순서번호 SN의 압축과 복원을 위한 구성 식은 아래의 [수학식 6]에서와 같다.
SNn=SNn-1+ 1
여기서 SNn은 RTP 패킷이 가지고 있는 본래의 순서번호이고, NCB는 16비트 SN의 기본 압축비트인 3이다.
다음으로 TS(Time Stamp) 압축을 설명하면, 앞에서 언급한 것처럼 E-ROHC 방식의 압축방법은 WDELSB(Wrapped around Differential Encoding LSB)이다. 이 방식은 TS값을 송신할 때, 전체 비트를 다 보내는 것이 아니라, 차이가 나는 내용만을 추출(differential)한 후 정해진 비트(NCB)로 압축하는 방식이다. 이때, TS를 압축하기 위한 최소의 압축비트 NCB(bits)를 아래의 [수학식 7]에서와 같이 구할 수 있다.
Figure 112007072404615-pat00004
여기서,
Figure 112007072404615-pat00005
Figure 112007072404615-pat00006
Figure 112007072404615-pat00007
in H.261
Figure 112007072404615-pat00008
in H.263
Figure 112007072404615-pat00009
in MPEG-4
또한 H.263 ver 2, MPEG-4 의 PCF는 각각 25Hz, 30Hz가 되는데, 이 값은 각각 3600, 3000의 배수로 TS값이 증가한다는 것이다.
즉, TS압축에서는 E-ROHC에서 WDELSB(Wrapped around Differential Encoding LSB) 방식으로 TS를 인코딩하였다. 다음은 의사코드(pseudo code)로 표현한 압축 알고리즘이다.
TS_Compress() IF TSn-1 > TSn 'Wrapped around Case TS_compress = Right_Bit_Trim(TS, NCB); '우측 NCB비트 Trim else TS_compress = Right_Bit_Trim(TSn - TSn-1, NCB); end IF END TS_Compress
이와 같이 압축기는 32-bit TS를 NCB(bits)로 압축하여 송신하게 되고, 이 값을 수신한 복원기(102)는 다음과 같이 복원하게 된다. 다음은 TS복원에서 의사코드(pseudo code)로 표현한 복원 알고리즘이다.
TS_Decompress() IF Left_Bit_Trim(TSn, (Bits of TS) - NCB) == 0x00000 TS = TS_comnpress; 'Wrap around Case else TSn = TSn-1 + TS_compress; 'Differential Encoding end IF TS_compress_ref = TS_compress; 'Repair-상태를 위해 보관 END TS_Decompress
이 방법이 TS 필드에서 어느 정도의 압축률을 가졌는지 하기의 [수학식 8]로 나타내었다. RTP헤더의 TS 압축 비율을 다음과 같이 구할 수 있다.
Figure 112007072404615-pat00010
여기서, TS는 압축하지 않을 때의 패킷헤더의 사이즈(byte)이고, TSproposed는 압축한 TS의 사이즈이다. CTS는 TS의 압축률, 즉 TS 사이즈의 상대적 비율이다. 위 [수학식 8]을 이용하여 32비트 TS의 압축비율을 구하면 아래의 [수학식 9]에서와 같다.
SN 비 압축시
Figure 112007072404615-pat00011
이어 압축기(100)와 복원기(102)간 컨텍스트(context)의 설계에 대해서 설명하기로 한다.
컨텍스트는 E-ROHC의 압축통신을 위해 정확하게 구축되어야 한다. 압축기(100)의 N-상태, 그리고 복원기(102)의 Build-상태에 구축되며 이때 압축기(100)는 풀 헤더(full header)를 복원기(102)에게 전송하여 컨텍스트를 구축하도록 한 다.
압축기(100)와 복원기(102)간의 초기화와 컨텍스트 구축이 이루어지는 N-상태 이후 복원기(102)는 압축헤더와 페이로드로 구성된 패킷을 압축기(100)에게 전송한다. 아래 [표 1]은 이것을 간략히 나타낸 것이다.
[표 1]
상태 압축기 복원기
N FULL 헤더를 전송 -
C - 압축헤더 + 페이로드만을 전송
아래 [표 2]는 N-상태 동안 구축되어지고 C-상태 동안 활용되어지는 컨텍스트의 구조를 나타낸 것이다. 주로 한 스트리밍 동안 절대 변하지 않는 정적 필드들 위주로 구성되어있으며, N-상태가 시작되면 압축기가 전송한 압축되지 않은 온전한 풀 헤더를 이용하여 구축한다.
[표 2]
CID 송신자주소 수신자주소 SP DP SSRC F P
90 1.1.1.1 2.2.2.2 .....
100 3.3.3.3 4.4.4.4 .....
먼저, 정적 필드는 송신자 주소(IPv4 인 경우 32비트, IPv6인 경우 128비트)와 수신자 주소가 있고 동기화발신지 식별자인 SSRC, 그리고 기여발신지 식별자인 CSRC, SP, DP 등으로 구성한다. 이 컨텍스트의 인덱스는 CID(context ID)로서 압축기(100)는 C-상태 동안에 CID와 뒤의 절에서 설명할 압축헤더를 같이 복원기(102)에게 송신하여 압축과 복원이 자유롭게 이루어지도록 한다.
위와 같은 컨텍스트의 초기화 구축에 있어서는, 컨텍스트는 압축기(100)와 복원기(102)에 공통으로 구축되는 압축복원 정보데이터베이스를 말한다. 복원기(102)는 Build-상태에서 압축기(100)(이때 N-상태)로부터 풀 헤더를 수신한 후, 이것을 이용하여 위 [표 2]와 같은 컨텍스트 DB를 구축한다. 이 컨텍스트는 이후 C-상태에서 압축기(100)로부터 수신 받은 CID를 이용하여 압축헤더 복원에 이용된다.
압축기(100)의 N-상태와 복원기(102)의 Build-상태간에는 도 5에서 보여지는 바와 같이, E-ROHC 통신을 위한 컨텍스트의 구축을 하게 되고, 이후의 통신규칙을 협상하게 된다. 최초 압축기(100)는 N-상태로 시작하게 되고 이때 풀 헤더를 전송하게 된다. 아래의 [표 3]에는 정적, 랜덤, 동적 필드를 분류하였다.
[표 3]
정적(static) 필드 동적(dynamic) 필드
VERS TRAFFIC CLASS FLOW LABEL NEXT HEADER SOURCE ADDRESS DESTINATION ADDRESS SOURCE PORT DESTINATION PORT (RTP) Ver P X PTYPE SSRC (RTP) Sequential Number Time Stamp
협상이 완료되고 컨텍스트의 구축이 완료되어 본격적인 압축통신 준비가 되면 압축기(100)는 C-상태로, 복원기(102)는 Normal-상태로 전이하게 된다.
한편, 통신이 이루어지는 동안 컨텍스트의 손상이 생기거나 송수신 데이터의 전송에러가 발생하게 되면 완벽한 복원은 불가능해진다. 이 경우 필드의 복원이나 컨텍스트의 재구축작업을 수행하게 된다. 이 두 가지 작업을 컨텍스트 재구축이라고 한다.
이 작업에는 두 가지가 있다. 첫째는 컨텍스트의 에러 또는 통신간의 에러에 의해 생긴 복원실패에 대해 복원기(102)가 Repair-상태로 전이하여 필드복원 기능을 수행하게 되는 경우이고, 둘째는 이러한 시도가 실패했을 경우, 복원기(102)는 Build-상태로 전이하고, 압축기(100)도 N-상태로 전이하여 초기화 과정으로 돌아가서 풀 헤더의 전송을 요구하고 필요한 경우 확장헤더를 송수신하여 정상적인 컨텍스트를 복구하는 방법이다.
다음으로, 압축기(100)와 복원기(102)간 압축헤더 설계에 대해 살펴보기로 한다. E_ROHC에서 압축기(100)와 복원기(102) 사이에 교환되는 메시지는 데이터 메시지와 제어 메시지로 분류 할 수 있다. 데이터 메시지는 정상적인 압축이 이루어지는 C-상태와 Normal-상태간에 오가는 압축된 헤더를 가지는 메시지를 말한다.
제어 메시지는 압축기(100)와 복원기(102) 사이에 압축통신을 하기 위한 준비 목적이나 통신오류를 제어하는데 사용하며 프로토콜의 5개의 상태가 각각 존재한다. 여기서는 이 5개의 상태에서 사용하는 제어 메시지와 데이터 메시지에 대해 설명하기로 한다.
먼저, N-상태는 C-상태로 가기 위한 압축기(100)의 준비상태이다. 주로 복원기(102)와의 협상에 관한 메시지로 구성된다.
이 상태에서 NCB값이 결정되고 컨텍스트를 구성하기위한 풀 헤더가 송수신 된다. NCB 패킷은 NCB_request 메시지에서 압축기(100)의 NCB값에 대한 요청신호가 전송되고 NCB_confirm 메시지를 사용하여 복원기(102)는 NCB값을 확정한다. 풀 메시지는 압축기(100)가 복원기(102)에게 컨텍스트를 구축하기 위한 정상적인 FULL_request 헤더를 송신하며, 복원기(102)는 FULL_confirm 메시지를 송신하여 컨텍스트 구축 성공을 알린다. 이 상태에서는 압축 데이터 메시지는 송수신되지 않는다.
다음으로, C-상태간에는 데이터 메시지와 제어 메시지가 모두 존재한다. 데이터 메시지는 CID, SN, TS_compress(k)로만 압축된 헤더와 페이로드로 구성된다. 제어 메시지는 WAIT 메시지와 수신된 패킷에 대한 ACK 메시지인데, 먼저 복원기(102)가 압축기에게 패킷 복원 중 에러발생을 보고하고 그 상태에서 잠시 대기를 요청하는 WAIT_request 메시지가 있다.
WAIT_success 메시지는 압축기(100)에게 자체 필드 복원 성공을 알리며, 계속해서 압축 패킷을 송신하라는 메시지이다. 그러나 복원기(102)에서 필드 복원이 실패했을 때는 WAIT_fail 메시지를 송신하여 압축기(100)에게 N-상태로 전이할 것을 요청하게 된다. 물론 복원기(102) 스스로도 Build-상태로 하향 전이하게 된다. ACK_data 메시지는 정해진 윈도 사이즈만큼의 패킷수신이후 데이터의 정상적인 수신을 보고하는 메시지이다.
다음으로, Build-상태는 압축기(100)의 N-상태와 압축통신 준비를 하는 상태이므로, 주로 압축기(100)와의 NCB값의 협상, 컨텍스트 구축 완료에 관한 메시지로 구성된다. NCB값의 결정, 컨텍스트 DB의 구축이 끝나면 N-상태와 Build-상태는 윈도 사이즈 협상을 하게 된다.
다음으로, Normal-상태는 압축통신이 이루어지는 상태이다. 메시지는 압축 헤더를 가지는 데이터 메시지와 복원에러시 C-상태를 대기(ready)시키는 WAIT 메시지로 구성된다. WAIT_request 메시지를 압축기(100)에게 보낸 후, 복원기(102)는 Repair-상태로 전이한다. 압축기(100)는 C-상태로 대기하는데, Repair-상태로부터 WAIT_success나 WAIT_fail 메시지를 수신할 때까지 유지된다.
마지막으로 Repair-상태는 압축 복원에러를 분석하여 재송신 없이 자체적으로 복원이 가능한가를 체크한다. 주로 메시지는 WAIT 이다. WAIT_success 메시지는 자체 필드 복원이 성공했다는 의미이다. 이 신호를 보낸 후 Normal-상태로 전이한다. 물론 압축기(100)는 계속 C-상태를 유지한다. 반면 WAIT_fail 메시지는 복원실패를 의미하며, 즉시로 Build-상태, N-상태로 전이해야한다.
위와 같은 각종 협상과 송수신 절차에 필요한 데이터와 제어 메시지 패킷의 프레임을 아래의 [표 4]에서와 같이 정의하였다. 먼저, 압축 협상 단계에서의 패킷 형태이다.
[표 4]
Packet From To Data Format
CTX_ok Build N CID
CTX_resend Build N CID
NCB_confirm Build N CID, NCB(bits)
NCB_request N Build CID, NCB(bits)
FULL_request N Build CID, Full Header 포함
FULL_confirm Build N CID
다음 아래 [표 5]는 윈도 사이즈를 협상하는 Build-상태와 N-상태의 메시지이다.
[표 5]
Packet From To Data Format
BER_request N Build CID, BER value
BER_confirm Build N CID, BER-1
BER__reconfirm N Build CID, WD_send(packets)
다음 아래 [표 6]은 가장 좋은 압축률을 가지고 정상적으로 송수신할 때의 형태이다.
[표 6]
Packet From TO Data Format
ACK_data Normal C CID, SN with received packets
정보데이터 C Normal CID, SN, TS_compress(NCB), 랜덤필드, 페이로드
다음 아래 [표 7]은 전송 중에 발생하는 오류에 관한 복원 단계의 메시지이다.
[표 7]
Packet From TO Data Format
WAIT_request Normal C CID
WAIT_success Repair C CID, SNn+1
WAIT_fail Repair C CID
이하에서는 상기 설명한 압축기(100)와 복원기(102)간 5가지 상태에서 동작에 대해 보다 상세히 설명하기로 한다. 이상에서 설명한 것을 바탕으로 하여 본 발명의 헤더 압축방식은 다음 같은 5가지 상태로 구성되어 동작하는 것으로 요약된 다.
가. 전송측 압축장치(Compressor)의 N-상태
압축기(100)와 복원기(102)간의 압축과 복원을 위한 컨텍스트의 설정을 담당하는 초기화상태이며 통신 간에 발생하는 치명적인 컨텍스트의 손상을 복구하기 위한 압축기의 상태이다. E-ROHC는 정상적인 송수신 단계 이전에, 초기 협상단계인 N-상태로 들어가게 되며, 이때 압축기(10)는 컨텍스트 구축을 위해 압축되지 않은 풀 헤더를 복원기(102)에게 전송한다. 또한 두 개의 노드간의 압축비트수를 정의하기 위한 NCB값을 계산하여 압축비트수를 결정하고, 윈도 사이즈 값을 결정한다.
이 상태는 E-ROHC의 가장 기본적인 상태로서 크게 다음과 같은 3가지의 기능을 하게 된다.
1. (컨텍스트 구축) 압축기(100)와 복원기(102)간의 컨텍스트 구축을 위한 프로세스(process)를 수행한다. 최초 압축기(100)는 풀 헤더를 송신하게 되고 압축기(100)에 컨텍스트 DB를 구축한다. 이후 복원기(102)로부터 컨텍스트 구축 완료 신호인 CTX_ok 또는 CTX_resend 메시지에 의해 C-상태로 전이하여 압축통신을 수행하거나 컨텍스트를 다시 작성하게 된다.
2. (NCB 결정) NCB 비트를 결정하여 이후 몇 비트로 동적 필드를 압축하여 송수신 할 것인가를 결정하게 된다. 서비스 타입(type of service)과 해당 트래픽(traffic)의 샘플링 주파수, 클럭 인터벌(interval) 값 등을 이용하여 NCB 결정 프로세스를 수행한다. 그리고 이때 산출된 NCB값과 CID, TS_STRIDE 값을 복원기(102)에 송신한 후 이상 없다고 판단될 때 C-상태로 전이하게 된다.
3. (윈도 사이즈 결정) 복원기(102)와 BER 메시지를 통해 윈도 사이즈WD_send(packets)를 결정한다. BER_request와 BER_confirm 메시지를 통해 압축기(100)와 복원기(102) 간에 윈도 사이즈를 결정하고, 최종 확정된 결과를 BER_reconfirm 메시지로 확정된다.
이후, C-상태로 전이한 이후에도 복원기(102)는 압축기와 같은 컨텍스트를 유지하다가 송수신상의 문제 또는 필드 복원 노력의 실패와 같은 문제가 발생시에 WAIT_request를 전달하여, 필드 복원시간동안의 대기를 요구하게 된다. 이후 압축기(100)는 WAIT_success 메시지를 받으면, C-상태에서 계속 압축 통신을 하게 되고, WAIT_fail 메시지를 받으면 컨텍스트 DB를 복구하기 위해 다시 N-상태로 전이하게 된다.
즉, 이 상태가 정상적으로 작동하면 양단간에 컨텍스트 DB가 구축되어야하고, 압축비트수와 윈도 사이즈가 결정되는 등 압축통신의 초기화가 달성되어야 한다. 압축기와 복원기 간의 제어 패킷은 아래의 [표 8]에서와 같다.
[표 8]
Packet 대상 내용
(수신)CTX_ok 복원기 Build D가 보낸 CTX 구축 성공 패킷
(수신)CTX_resend 복원기 Build D가 보낸 CTX 구축 실패 패킷
(수신)NCB_confirm 복원기 Build N-상태가 보낸 압축협상비트 NCB 확인
(송신)NCB_request 복원기 Build D에게 NCB 압축비트수 확인 요청
(송신)FULL_request 복원기 Build D에게 Full 헤더 송신, 컨텍스트 구축 용도
(수신)FULL_confirm 복원기 Build D의 컨텍스트 구축 완료 확인 신호
나. 전송측 압축장치(compressor)의 C-상태
N-상태를 통해 압축기(100)와 복원기(102)간의 정적 필드와 동적 필드의 컨 텍스트가 구축되고, 압축비트수가 결정되어 압축과 복원에 관한 정보의 구축이 완료되면, 압축기(100)는 CID 등의 기본적인 압축헤더와 페이로드만을 전송하는 C-상태로 작동하게 된다.
C-상태 동안 CID와 압축된 헤더의 통신이 이루어지다가, NAK신호인 WAIT_request 메시지가 수신(복원기의 필드 복원 실패)되면 압축기(100)는 복원기(102)의 필드복원을 위해 대기하거나, N-상태로 전환하여 컨텍스트 재구축 과정을 반복하게 된다.
C-상태는 ROHC O-Mode와 유사한 상태이다. 알고리즘은 크게 2가지로 구성되는데 압축통신이 정상일 때는, CID, SN, TS_Compress(NCB), 랜덤, 페이로드 데이터만을 윈도 사이즈 만큼씩 송수신하게 되고, 복원기(102)로부터 압축복원 실패 메시지를 받았을 때는 N-상태 컨텍스트 DB 재구축 기능으로 전이하게 된다.
좀더 상세히 설명하면,
1. 정상적인 압축 통신 상태일 때 압축기(100)는 CID, SN, TS_Compress(NCB), 랜덤, 페이로드로 압축된 데이터만을 송신하게 된다. 압축된 형태의 TS_compress는 Right_Bit_Trim(TSn - TSn-1, NCB)로 압축하며, 이때 헤더필드의 랜덤 필드는 비트 단위의 압축을 실시하여 더욱 더 압축율을 높이게 된다. 그리고 ROHC의 O-Mode처럼 복원기(102)의 ACK 신호의 수신여부와 상관없이 윈도 사이즈만큼씩의 패킷을 송신한다.
2. 압축통신 중에 복원기(102)로부터 WAIT_request신호를 수신하게 되면, 압축기(100)는 복원기(102)의 압축복원에 문제가 생겼다는 것을 인지하고, 복원 기(102)가 스스로 필드를 복원 할 때까지 대기한다.
이후, 필드복원에 성공했다는 WAIT_success 메시지를 수신시에는 다시 정상적인 압축 통신을 수행한다. 그러나 복원기(102)로부터 지정된 시간 내에 WAIT_success 신호를 수신하지 못할 경우에나 WAIT_fail 메시지를 받을 때는 N-상태로 전이하여 컨텍스트 재구축 단계로 작동하게 된다.
즉, 이 상태가 정상적으로 작동하면 압축통신이 양단간 원활히 수행되는 것이고, 통신간에 WAIT_fail 신호를 수신시에는 N-상태로 복귀하여 다시 컨텍스트 DB를 재구축 하게 된다. 이때 압축기(100)와 복원기(102) 간의 제어 패킷과 데이터 메시지는 아래의 [표 9]에서와 같다.
[표 9]
Packet 대상 내용
(수신)WAIT_request 복원기 Normal D가 필드복원을 위해 C에게 패킷의 송신대기 요청
(수신)WAIT_success 복원기 Normal D가 필드복원 성공을 통보. C는 압축패킷을 송신
(송신)WAIT_fail 복원기 Normal D가 필드복원 실패를 통보. C를 N-상태로 전이토록 요구. D도 Build-상태로 전이
(수신)ACK_data 복원기 Normal D는 정해진 윈도사이즈마다 이 메시지를 C에게 송신한다.
(압축)정보데이터 복원기 Normal CID, SN, TS_compress(NCB), 랜덤, 페이로드
이 중에서 ACK_data메시지는 복원기(102)가 압축기(100)에게 송신하는 메시지로서 윈도 사이즈만큼 수신한 후 수신이 잘 되었다는 의미의 제어신호이다.
다. 수신측 복원장치(decompressor)의 수립(build) 상태
압축기(100)가 N-상태일 때의 대응 상태로서 노드간에 압축통신이 가능하도 록 준비를 하는 상태, 주로 압축기(100)와의 컨텍스트 동기화 또는 재구축, 압축비트(NCB)비트의 결정, 그리고 수신단의 ACK없이 송신할 수 있는 패킷의 수인 윈도우 사이즈의 크기를 협상한다.
복원기(102)의 3가지 상태 중에서 기본이 되는 상태이고, 복원기(102)가 Normal-상태로 전이하여 압축통신을 할 수 있도록 컨텍스트 DB 구축기능을 수행하는 상태이다. 크게 3가지 기능으로 구분할 수 있다. 대응되는 압축기의 상태는 N-상태이다.
1. (컨텍스트 구축) 가장 먼저 복원기(102)는 컨텍스트 DB를 구축하여 압축기(100)에 있는 컨텍스트 DB와 데이터를 일치화 시키는 기능을 수행한다. 압축기(100)로부터 풀 헤더를 수신하면 이것을 이용하여 컨텍스트 DB를 구축하게 되고, 구축 성공 후에는 CTX_ok 신호를 압축기(100)에게 송신하여 컨텍스트 DB 구축이 완료되었다는 것을 알리게 된다. 만일 컨텍스트 구축이 실패하면 압축기(100)에게 CTX_resend 메시지를 송신하여 풀 헤더의 재송신을 요구하게 된다.
2. (NCB 결정) 컨텍스트 구축이 완료되면, 압축기(100)로부터 NCB 비트 확인 신호를 수신하여야 한다. 압축기(100)가 NCB비트를 결정하여 NCB_request 메시지를 보내면, 복원기(102)는 확인 후 NCB_confirm 메시지를 송신하여 확인해 준다.
3. 이 모든 작업 후에 복원기(102)는 압축기(100)로부터 수신한 최초의 압축헤더를 수신한 후, 컨텍스트 DB를 이용하여 압축 복원을 실시한다. 복원이 성공으로 이루어지면 복원기(102)는 자신의 상태를 FULL_confirm 메시지를 송신하고 Normal-상태로 상향 전이하게 된다.
즉, 이 단계가 끝나면 복원기(102)에 컨텍스트 DB가 구축 되어 있어야 하고, 이후 Normal-상태로 상향 전이하게 된다. 이때 압축기(100)와 복원기(102) 간의 제어 패킷과 데이터 메시지는 아래 [표 10]에서와 같다.
[표 10]
Packet 대상 내용
(수신)NCB_request 압축기 N C가 보낸 NCB 비트수의 확정요구
(송신)NCB_confirm 압축기 N C에게 보내는 NCB비트수 확정패킷
(송신)CTX_ok 압축기 N C에게 보내는 CTX 구축 성공 패킷
(송신)CTX_resend 압축기 N C에게 보내는 CTX 구축 실패 패킷
(수신)FULL_request 압축기 N C가 보낸 모든 준비 사항 체크 패킷
(송신)FULL_confirm 압축기 N C에게 보낸 모든 준비사항 OK
라. 수신측 복원장치(decompressor)의 정상(normal) 상태
압축기(100)의 C-상태(압축)에 대응되는 상태이다. 최고의 압축률을 유지하며, 압축기(100)에게 ACK나 NAK를 송수신 하지 않고 WD_send(packets) 만큼 압축기(100)의 압축 데이터를 수신하고 완벽하게 복원한다.
이 상태에서 프로토콜은 가장 높은 압축률을 얻게 되고 원활한 통신 기능을 수행하게 된다. 기 구축된 컨텍스트 DB를 사용하여 수신된 헤더를 복원하고, 만일 복원 실패 시에는 WAIT_request 메시지를 압축기에게 송신하고 Repair-상태로 전이하여 필드복원 기능을 수행한다.
Repair-상태에서 필드복원이 실패하게 되면 WAIT_fail 메시지를 압축기(100)에게 송신한 후, Build-상태로 하향 전이하게 되고, 복원이 성공하면 WAIT_success 메시지를 송신한 후, 다시 Normal-상태로 전이한다.
1. 압축기(100)로부터 수신되는 압축 헤더들 중에서 정적, 동적 필드는 컨텍 스트 DB를 이용하여 복원이 이루어지고, TS 필드는 TSn = TSn-1 + TS_compress방식으로 복원이 가능하다. 랜덤 필드는 비트 압축되어 있으므로, 비트 압축복원을 해야 완벽한 헤더 복원이 가능하다. 압축복원이 실패하면 즉시 송수신을 중지하고 WAIT_request 메시지를 송신 한 후, Repair-상태로 전이하여 컨텍스트를 복구하게 된다.
2. Repair-상태에서 필드복원이 성공하게 되면 WAIT_success 메시지를 송신하고 다시 Normal-상태로 전이하게 되지만, 실패하게 되면 상태를 WAIT_fail 메시지를 송신하고 Build-상태, N-상태로 전이하여 컨텍스트 재구축을 수행한다.
즉, 이 상태는 최고의 압축률로 송수신이 이루어지는 단계이고, 이후 에러 발생시 Repair-상태로 전이하게 된다. 이때, 압축기(100)와 복원기(102) 간의 제어 패킷과 데이터 메시지는 아래 [표 11]에서와 같다.
[표 11]
Packet 대상 내용
(송신)WAIT_request 압축기 C C에게 필드 복원시까지 잠시 대기 요구, DC는 즉시 Repair-상태로 전이한다.
(송신)ACK_data 압축기 C D는 정해진 윈도사이즈마다 이 메시지를 C에게 송신한다.
(수신)압축 데이터 CID, SN, TS_compress(NCB), 랜덤필드, 페이로드 압축헤더 프레임
마. 수신측 복원기의 복구(repair) 상태
복원기(102)에서 압축기(100)의 압축데이터를 정상적으로 복원하지 못할 경우, 복원기(102)는 압축기(100)에게 풀 헤더의 송신을 요구하지 않고, 복원기(102) 내부의 데이터(주로 이전에 수신한 패킷 데이터)를 이용하여 압축을 복원하고 컨텍스트의 필드 복원을 수행한다.
먼저, 이 상태에 들어오는 조건에 대하여 설명하면, 복원기(102)는 Normal-상태에서 압축 송수신을 하는 동안 여러 가지 에러상태에 직면하게 될 수 있다. 패킷을 수신할 때 나타날 수 있는 경우는 CID, 컨텍스트와 관계되어 생각할 수 있다. 수신된 CID를 가지고 컨텍스트 DB를 검색하게 되는데, 해당 레코드가 컨텍스트 DB에 구축이 되어있으나 SN, TS 등의 데이터가 손상되어 사용할 수 없을 경우가 있을 것이다. 이 경우는 이전 패킷들의 정보를 이용하여 필드 복원이 가능하다.
그러나, 전송 중에 CID 자체가 손상되거나 전혀 다른 CID가 수신된 경우는, 이 패킷이 전혀 새로운 스트림(stream)인지, 아니면 CID가 손상된 것인지 판단 할 수 가 없게 된다. 이 경우는 필드 복원을 담당하는 Repair-상태에서는 처리 불가능한 상태이므로 즉시 Build-상태로 전이하여 해당 패킷의 재전송을 요구해야 한다.
1. Repair-상태로 전이하게 되면, 복원기(102)는 즉시로 필드 복원 알고리즘을 이용하여, 압축기(100)에게 풀 헤더를 요구하기 이전에, 컨텍스트 DB가 복원가능한가를 체크한다.
2. 이러한 필드 복원 작업에 성공하면 WAIT_success 메시지를 압축기(100)에게 송신하고, 복원기(102)의 상태를 Normal-상태로 상향 전이시킨다.
3. 이 작업에 실패하면 컨텍스트 DB의 재설정을 위해 WAIT_fail 메시지를 압축기(100)에게 송신하여 N-상태로 전이시키고, 자신의 상태도 Build-상태로 하향 전이시킨다. 이때 압축기(100)와 복원기(102) 간의 제어 패킷과 데이터 메시지는 아래 [표 12]에서와 같다.
[표 12]
Packet 대상 내용
(송신)WAIT_success 압축기 C C에게 필드 복원이 성공적으로 끝난것을 알리고, C에게 새로운 패킷을 전송할 것을 요구
(송신)WAIT_fail 압축기 C C에게 필드 복원 실패를 알리고, C에게 N-상태로 전이하라고 지시
도 6 내지 도 10은 본 발명의 실시 예에 따른 압축기와 복원기간 초기상태, 정상상태, 에러상태, 에러복원성공 상태, 에러복원실패 상태시의 동작 다이어 그램을 각각 도시한 것이다.
먼저, 도 6은 압축기와 복원기간 압축통신의 최초단계를 나타낸 것으로, 상기 도 6에서 보여지는 바와 같이 압축기(100)와 복원기(102)는 최초 N-상태와 Build-상태로 시작되어 NCB를 결정하고 윈도 사이즈를 결정한 후, 컨텍스트를 각각 구축하게 된다.
다음으로, 도 7은 압축기와 복원기간 정상적인 압축통신이 이루어지는 정상상태를 나타낸 것으로, 컨텍스트가 정상적으로 구축되면, 압축기(100)는 C-상태로, 복원기(102)는 Normal-상태로 전이하여 상기 도 7에서 보여지는 바와 같은 압축된 패킷을 상호 송수신한다.
다음으로, 도 8은 압축기와 복원기간 통신이 이루어지는 동안 복원기(102)에서 압축복원에 실패한 에러발생상태를 나타낸 것으로, 상기 도 8에서 보여지는 바와 같이, 압축기(100)는 C-상태에 그대로 대기하고, 복원기(102)가 Repair-상태로 전이하여 기 수신된 데이터를 이용하여 패킷을 복원하게 된다.
다음으로, 도 9는 압축기와 복원기 양단간에 컨텍스트가 정상적이면서 에러가 발생한 필드의 복원이 성공한 상태를 나타낸 것으로, 상기 도 9에서 보여지는 바와 같이, 복원기(102)는 다시 Normal-상태로 전이하여 C-상태의 압축기(100)와 정상상태의 압축통신이 이루어지게 된다.
마지막으로, 도 10은 압축기와 복원기간 에러발생에 대한 필드 복원 실패상태를 나타낸 것으로, 상기 도 10에서 보여지는 바와 같이 해당 필드의 복원에 앞서, 각각 구축되어 있는 컨텍스트에 해당 레코드가 없는 경우, 복원기(102)는 이것이 새로운 스트림의 패킷이라고 판단하여 압축기(100)에게 해당 패킷의 재전송을 요구하여 에러유무를 판단한다. 이렇게 하기 위해 압축기(100)는 N-상태, 복원기(102)는 Build-상태의 초기상태로 전이하게 된다.
이하에서는 위와 같은 본 발명의 압축방식을 이용하는 경우 네트워크의 성능에 대해서는 살펴보기로 한다.
상기한 바와 같은 동적 압축을 통한 성능 분석을 위해 위 도 1에 도시된 압축기(100)와 복원기(102)간 시뮬레이션(simulation) 환경을 설정하면, 먼저 압축기(100)와 복원기(102)로 구성된 2개의 송수신 노드간의 전송만을 고려하고, 전송노드와 목적지 노드는 높은 패킷 에러율과 긴 RTT(radio transmission technology)를 가지는 IP네트워크로 가정한다.
또한, 포워드(forward) 데이터 채널 상에서 전송된 패킷은 손실될 수 있고, 패킷 에러의 특별한 형태가 없으며, 패킷의 순서는 압축기(100)와 복원기(102) 사 이에서 유지되는 것으로 가정하고, 수신기는 향상 전송 측에서 보낸 순서대로 패킷을 받는 것으로 가정한다. 또한 피드백(feedback) 채널 상에서 엄격한 지연이나, 에러 요구 사항이 없고, RTT의 어떤 특별한 분포를 가정하지 않는다. 마지막으로 동적으로 RTT에 대한 변화에 적응할 수 있으며, 헤더압축은 인터리빙(interleaving)과 채널코딩(channel codding)에 영향을 미치지 않는다고 가정한다.
위와 같은 가정 하에서 본 발명의 압축기법에 대한 성능평가를 위해 두 가지 측면에서 성능을 비교 분석하기로 한다.
위 비교 분석에 있어서, 첫 번째로는 비디오 스트리밍 트래픽에서 연속적인 패킷 손실 에러에 대한 압축비트수(NCB 또는 BCB)의 크기를 대상으로 Visual SLAM 3.0(AWESIM)을 이용하여 수행하고, 두 번째로는 보내질 데이터의 크기변화에 따른 복원 성공률에 관한 성능을 분석한다.
이때 평균 데이터 전송속도는 약 8Kbps이고 프레임율(frame rate)은 10fps, 비디오 프레임 크기는 100바이트이며, RTP계층에서 최대전송유닛(MTU)은 4000비트이다. 즉 500바이트 보다 더 큰 크기의 비디오 프레임은 단편화되어 2개나 혹은 그 이상의 RTP패킷으로 나뉘어져서 전송된다. 그러나 시뮬레이션에서는 RTP패킷은 고정적인 크기로 분할된다고 가정하였으며, MPEG4 스트림을 RTP 패킷으로 분할하는 과정이나 알고리즘에 대해서는 고려하지 않았으며, 고정크기의 RTP 패킷만을 대상으로 하였다. 시뮬레이션간 두 개의 노드(node) 간에 두 개의 채널을 사용하였다.
도 11은 본 발명의 실시 예에 따른 압축기(100)와 복원기(102)간 동적 압축 을 이용하는 경우의 에러율과 복원 성공률을 비교한 그래프를 도시한 것이다.
위 도 11을 참조하면, 연속적인 패킷손실의 길이가 작을수록 3비트 압축방식의 복원 성공률이 높아지고, 연속적 패킷 손실의 길이가 길어질수록 헤더의 압축비트수를 크게 한 방법의 성공률이 낮아지는 것을 볼 수 있다.
또한 3비트 압축의 경우 연속적 에러율이 10일 경우와 50일 경우의 복원 성공률의 차이가 8배 이상 벌어지는 것을 볼 수 있고, 9비트 압축의 경우는 연속적 에러의 길이에 거의 영향을 받지 않고, 성공률이 0.4∼0.6을 유지하는 것을 볼 때, 앞서 분석한 바와 같이 네트워크의 에러율이나 연속적 패킷 에러길이가 큰 환경에서는 SN과 TS의 압축비트수를 BCB+n 개로 증가시켜 압축과 복원을 하는 것이 유리한 것을 알 수 있다.
도 12는 본 발명의 실시 예에 따른 압축기(100)와 복원기(102)간 동적 압축을 이용하는 경우의 데이터 크기와 복원 성공률을 비교한 그래프를 도시한 것이다.
위 도 12를 참조하면, 데이터의 사이즈가 100바이트일 경우, 복원 성공률은 거의 차이가 없이 0.5∼0.6의 분포를 보이고 있음을 알 수 있다. 그러나 1G(giga) 바이트의 전송 데이터를 송신하는 경우 압축 비트수가 9비트인 경우와 3비트인 경우의 성공률의 비가 2배정도가 된다.
즉, 위 도 11 및 도 12의 성능 분석 결과, 3비트 압축의 경우 연속적 에러율이 10일 경우와 50일 경우의 차이가 8배 이상 차이가 있었으며, 9비트 압축의 경우는 연속적 에러의 길이에 거의 영향을 받지 않고, 에러율이 0.4∼0.6을 유지하는 것을 볼 수 있었다. 또한 연속적 에러비트가 평균치인 30일 경우 에러율이 0.6이하 인 5비트가 평균치임을 입증하였다. NCB가 5비트인 경우 압축단계가 [0, 127]로, 이것은 평균 연속 에러비트인 30비트가 에러로 손실된다하더라도 무난히 복원 가능하다는 의미이다. 또한 데이터의 크기가 클수록 압축비트를 크게 하여 복원 성공률을 높여야 함을 성능 분석을 통해 확인하였다.
상기한 바와 같이 본 발명에서는 IP 네트워크에서 헤더의 크기를 줄이는 IPHC나 ROHC 등의 압축기법에 모두 적용할 수 있는 동적 영역의 새로운 압축 방법을 제안하였으며, SN, TS의 압축률에 따른 성능의 차이 분석과, 데이터 크기와 복원 성공률과의 관계를 분석을 통해 압축기와 복원기간 네트워크의 상태, 전송데이터의 종류 등을 고려하여 실시간 통신 양단간의 압축률을 동적으로 결정하는 본 발명의 압축방법의 타당성을 검증하였다.
한편 상술한 본 발명의 설명에서는 구체적인 실시 예에 관해 설명하였으나, 여러 가지 변형이 본 발명의 범위에서 벗어나지 않고 실시될 수 있다. 따라서 발명의 범위는 설명된 실시 예에 의하여 정할 것이 아니고 특허청구범위에 의해 정하여져야 한다.
도 1은 본 발명의 실시 예에 따른 전송노드 압축기와 목적지 노드 압축해제기의 네트워크 구성도,
도 2는 본 발명의 실시 예에 따른 전송측 압축기의 동작 상태 예시도,
도 3은 본 발명의 실시 예에 따른 수신측 복원기의 동작 상태 예시도,
도 4는 본 발명의 실시 예에 따른 무선 통신망상 압축기와 복원기간 최종 협상압축비트 결정 동작 제어 흐름도,
도 5는 본 발명의 실시 예에 따른 압축기와 복원기간 컨텍스트 구축 예시도,
도 6 내지 도 10은 본 발명의 실시 예에 따른 압축기와 복원기간 초기상태, 정상상태, 에러상태, 에러복원성공 상태, 에러복원실패 상태시의 동작 다이어 그램 예시도,
도 11은 본 발명의 실시 예에 따른 에러율과 복원 성공률의 그래프 예시도,
도 12는 본 발명의 실시 예에 따른 데이터 크기와 복원 성공률의 그래프 예시도.

Claims (10)

  1. IP 프로토콜을 사용하는 무선 통신망에서 효율적인 데이터 전송을 위한 압축방법으로서,
    (a)무선 통신망상 전송노드의 압축기와 목적지 노드의 복원기간 데이터 전송시 SN(sequential number)과 TS(time stamp)의 압축을 위한 기본압축비트(BCB)를 결정하는 단계와,
    (b)상기 압축기와 복원기간 협상을 통해 RTP로 운반되는 유류부하(payload) 트래픽의 특성에 따라 추가의 n비트를 산출하여 최종 협상압축비트(NCB)를 결정하는 단계와,
    (c)상기 압축기와 복원기간 결정된 상기 NCB로 상기 SN과 TS를 압축하여 데이터 송/수신을 수행하는 단계
    를 포함하는 무선통신망에서 동적 영역 압축 및 NCB 결정방법.
  2. 제 1 항에 있어서,
    상기 (b)단계에서, 상기 유류부하 트래픽이 텍스트 데이터인 경우에는 데이터 전송을 위한 압축비트를 상기 기본압축비트로 사용하는 것을 특징으로 하는 무선통신망에서 동적 영역 압축 및 NCB 결정방법.
  3. 제 1 항에 있어서,
    상기 (b)단계에서, 상기 유류부하 트래픽이 멀티미디어 데이터인 경우에는 데이터 전송을 위한 압축비트를 상기 기본압축비트에 추가의 n비트를 가산한 최종협상압축비트(NCB)로 사용하는 것을 특징으로 하는 무선통신망에서 동적 영역 압축 및 NCB 결정방법.
  4. 제 3 항에 있어서,
    상기 (b)단계에서, 상기 NCB는, 상기 데이터가 전송되는 통신채널의 대역폭(BW), 전송될 데이터의 길이(Length) 및 상기 통신채널의 연속적인 에러율(Error)에 따라 가변 설정되는 것을 특징으로 하는 무선통신망에서 동적 영역 압축 및 NCB 결정방법.
  5. 제 4 항에 있어서,
    상기 NCB는, 아래의 [수학식]에서와 같이
    [수학식]
    Figure 112007072404615-pat00012
    Vref : 참조 주파수(Freqref)를 가지는 트래픽
    k : 최소 압축비트
    산출되는 것을 특징으로 하는 무선통신망에서 동적 영역 압축 및 NCB 결정방법.
  6. 제 5 에 있어서,
    상기 NCB는,
    상기 RTP로 운반되는 패킷의 가변영역인 32비트 TS필드를 압축하는 비트로 0∼32비트 범위로 설정되는 것을 특징으로 하는 무선통신망에서 동적 영역 압축 및 NCB 결정방법.
  7. 제 1 항에 있어서,
    상기 (b)단계에서, 상기 n비트는,
    0≤n〈 48 범위의 정수인 것을 특징으로 하는 무선통신망에서 동적 영역 압축 및 NCB 결정방법.
  8. 제 1 항에 있어서,
    상기 (b)단계에서, 상기 RTP로 운반되는 패킷 헤더의 TS값은,
    PCF 만큼씩 증가되도록 아래의 [수학식]에서와 같이
    [수학식]
    TSn = TSn-1 + PCTSI
    TSn : RTP의 n번째 패킷의 타임스탬프
    TSn-1 : 가장 최근에 디코드된 타임스탬프
    설계되는 것을 특징으로 하는 무선통신망에서 동적 영역 압축 및 NCB 결정방법.
  9. 제 1 항에 있어서,
    상기 (c)단계에서, 상기 TS값은,
    WDELSB(Wrapped around Differential Encoding LSB) 방식으로 압축되는 것을 특징으로 하는 무선통신망에서 동적 영역 압축 및 NCB 결정방법.
  10. 제 9 항에 있어서,
    상기 TS값은, 상기 WDELSB 압축방식을 통해 특정 필드값 송신 시 차이가 나는 내용만을 추출하여 미리 정해진 비트로 압축되는 것을 특징으로 하는 무선통신망에서 동적 영역 압축 및 NCB 결정방법.
KR1020070101498A 2007-10-09 2007-10-09 무선 통신망에서 동적 영역 압축 및 ｎｃｂ 결정방법 KR100918961B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020070101498A KR100918961B1 (ko) 2007-10-09 2007-10-09 무선 통신망에서 동적 영역 압축 및 ｎｃｂ 결정방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020070101498A KR100918961B1 (ko) 2007-10-09 2007-10-09 무선 통신망에서 동적 영역 압축 및 ｎｃｂ 결정방법

Publications (2)

Publication Number Publication Date
KR20090036355A KR20090036355A (ko) 2009-04-14
KR100918961B1 true KR100918961B1 (ko) 2009-09-25

Family

ID=40761369

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020070101498A KR100918961B1 (ko) 2007-10-09 2007-10-09 무선 통신망에서 동적 영역 압축 및 ｎｃｂ 결정방법

Country Status (1)

Country Link
KR (1) KR100918961B1 (ko)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005114950A1 (en) 2004-05-13 2005-12-01 Qualcomm Incorporated Header compression of multimedia data transmitted over a wireless communication system
KR20070082664A (ko) * 2006-02-17 2007-08-22 삼성전자주식회사 무선 페이딩 환경에서의 압축된 비디오 정합 장치 및 방법

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005114950A1 (en) 2004-05-13 2005-12-01 Qualcomm Incorporated Header compression of multimedia data transmitted over a wireless communication system
KR20070082664A (ko) * 2006-02-17 2007-08-22 삼성전자주식회사 무선 페이딩 환경에서의 압축된 비디오 정합 장치 및 방법

Also Published As

Publication number Publication date
KR20090036355A (ko) 2009-04-14

Similar Documents

Publication Publication Date Title
KR101722719B1 (ko) 역방향의 강력한 헤더 압축 수신기
CN101366261B (zh) 用于当遭遇静默抑制时增强稳健标头压缩性能的方法和设备
US9125088B2 (en) Dynamic robust header compression
CA2375830C (en) Robust header compression in packet communications
US7647421B2 (en) Extension header compression
EP1415474B1 (en) Method and compressor for compressing packet timestamp information
JP4936079B2 (ja) セルラー通信ネットワークにおけるハンドオーバ中およびハンドオーバ後のヘッダ圧縮最適化方法
KR100703494B1 (ko) 이동통신 시스템에서 사용자 데이터 프로토콜 체크섬을 포함하는 음성패킷망의 패킷 송/수신 방법 및 장치
Le et al. Efficient and robust header compression for real-time services
EP2190163B1 (en) A method for repairing the window-based least significant bits decoding in the robust header compression
KR100918961B1 (ko) 무선 통신망에서 동적 영역 압축 및 ｎｃｂ 결정방법
US7342938B1 (en) Spectrally efficient approach to protection of key elements in a non-homogenous data stream
Hannu Signaling compression (SigComp) requirements & assumptions
Woo et al. Performance analysis of robust header compression over mobile wimax
Fitzek et al. Cooperative ip header compression for parallel channels in wireless meshed networks
Rawat et al. Robust header compression over long delay links
Naidu et al. Implementation of header compression in 3GPP LTE
CN100428733C (zh) 移动通信网络中ip报头压缩的错误恢复方法及装置
Kim et al. A New Compression Method of SN, TS for On-Line Multimedia Services in Real Time Protocol
Kim et al. Header compression of rtp/udp/ip packets for real time high-speed ip networks
Minaburo et al. Performance Improvement of Multimedia flows by using UDP-Lite and ROUC compression
Zhang WLC04-2: Performance of Robust Header Compression for VoIP in 1xEV-DO Revision A System
Levy et al. General all-Layers combined with Efficient WLAN MAC Layer Headers Compression
Penchalaiah et al. Performance of TCP/IP/UDP adaptive header compression algorithm for wireless network
吴亦川 et al. A Mechanism to Efficiently Transport Wireless Real-Time IP Services over Cellular Links

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20120911

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20130910

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20140725

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20150727

Year of fee payment: 7

FPAY Annual fee payment

Payment date: 20160905

Year of fee payment: 8

LAPS Lapse due to unpaid annual fee