KR20030043529A - 패킷의 헤더압축을 지원하는 통신 시스템에서전체헤더패킷과 압축헤더패킷의 전송 제어 장치와 방법 - Google Patents

패킷의 헤더압축을 지원하는 통신 시스템에서전체헤더패킷과 압축헤더패킷의 전송 제어 장치와 방법 Download PDF

Info

Publication number
KR20030043529A
KR20030043529A KR1020010074774A KR20010074774A KR20030043529A KR 20030043529 A KR20030043529 A KR 20030043529A KR 1020010074774 A KR1020010074774 A KR 1020010074774A KR 20010074774 A KR20010074774 A KR 20010074774A KR 20030043529 A KR20030043529 A KR 20030043529A
Authority
KR
South Korea
Prior art keywords
packet
header
layer
compression
information
Prior art date
Application number
KR1020010074774A
Other languages
English (en)
Other versions
KR100765122B1 (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 KR1020010074774A priority Critical patent/KR100765122B1/ko
Priority to AT08010516T priority patent/ATE502472T1/de
Priority to AT02026088T priority patent/ATE412299T1/de
Priority to DE60229482T priority patent/DE60229482D1/de
Priority to EP20020026088 priority patent/EP1315356B1/en
Priority to EP20080010516 priority patent/EP1968277B1/en
Priority to DE60239500T priority patent/DE60239500D1/de
Priority to AU2002353634A priority patent/AU2002353634B2/en
Priority to MXPA04006224A priority patent/MXPA04006224A/es
Priority to PCT/KR2002/002199 priority patent/WO2003047189A1/en
Priority to UAA200600834A priority patent/UA82886C2/uk
Priority to RU2004119304A priority patent/RU2303858C2/ru
Priority to JP2002341556A priority patent/JP4309118B2/ja
Priority to US10/303,059 priority patent/US7486699B2/en
Publication of KR20030043529A publication Critical patent/KR20030043529A/ko
Priority to ZA2004/04748A priority patent/ZA200404748B/en
Priority to MA27746A priority patent/MA27160A1/fr
Priority to AU2006201242A priority patent/AU2006201242B2/en
Priority to US11/723,171 priority patent/US7656902B2/en
Application granted granted Critical
Publication of KR100765122B1 publication Critical patent/KR100765122B1/ko
Priority to JP2008190345A priority patent/JP4808749B2/ja
Priority to US12/343,766 priority patent/US7623549B2/en
Priority to US12/656,338 priority patent/US8351376B2/en

Links

Classifications

    • 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
    • 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
    • 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)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

본 발명은 유무선 통신 시스템에서 패킷 데이터의 헤더정보를 압축하여 전송하고 그 결과를 피드백하여 패킷 전송을 제어하도록 하기 위한 데이터 전송장치와 방법에 관한 것이다.
본 발명은 하나의 패킷 스트림에 대해 송신측 헤더압축담당계층은 상위계층으로부터 전달 받은 데이터의 헤더를 압축하여 전체헤더패킷 또는/및 압축헤더패킷으로 변환하는 헤더압축장치와, 이를 제어하는 헤더압축제어장치와, 상기 압축된 전체헤더패킷 또는/및 압축헤더패킷을 하위계층으로 전달하는 데이터 전송장치로 이루어지고; 링크제어계층은 상기 헤더압축담당계층으로부터 전달 받은 데이터를 전송제어장치 제어에 따라 저장하거나 수신측으로 전송하는 버퍼및 전송장치와, 수신측으로 전송된 데이터 중 전송에 실패한 데이터를 판별하여 전송실패정보를 상위계층에 전달하는 전송실패판별장치;로 이루어지는 통신시스템이며, 상위계층으로부터 전달 받은 데이터의 헤더를 헤더압축담당계층에서 압축하여 상기 압축된 전체헤더패킷 또는/및 압축헤더패킷을 링크제어계층으로 전달하며, 링크제어계층은 상기 전달 받은 데이터를 저장수단에 저장하거나 수신측으로 전송하고 이후 수신측으로 전송한 데이터 중 전송에 실패한 데이터가 있는가를 판단하여 전송에 실패한 데이터가 있는 경우에는 해당 데이터의 전송실패정보를 헤더압축담당계층으로 전달하여 헤더압축담당계층이 전체헤더패킷과 압축헤더패킷의 전송을 제어하는 것을 특징으로 한다.

Description

패킷의 헤더압축을 지원하는 통신 시스템에서 전체헤더패킷과 압축헤더패킷의 전송 제어 장치와 방법 {Apparatus for controlling transmission of full header packet and compression header packet in communication system supporting packet header compression and method thereof}
본 발명은 유무선 통신 시스템의 패킷 데이터의 헤더정보를 압축하여 전송하고 그 결과를 피드백하여 패킷 전송을 제어하도록 하기 위한 데이터 전송장치와 방법에 관한 것으로, 특히3GPP 비동기식(UMTS)이동통신시스템의 헤더압축담당계층인 PDCP계층이 하위의 링크제어계층인 RLC계층으로부터 전체헤더패킷 또는 압축헤더패킷의 전송결과를 전달 받아 전체헤더패킷과 압축헤더패킷의 전송을 조절해 전송효율 및 압축복원의 효율을 향상시키는데 적당하도록 한 UMTS시스템에서 데이터 전송장치 및 방법에 관한 것이다.
더욱 상세하게는 본 발명에서, 헤더압축담당계층은 상위계층으로부터 전달받은 패킷에 대해 헤더압축을 실행하여 하위의 링크제어계층으로 전달하며, 링크제어계층은 수신측으로 이를 전송하는 시스템에 있어서, 상위계층으로부터 전달 받은 데이터의 헤더를 압축하여 전체헤더패킷 또는/및 압축헤더패킷으로 변환하는 헤더압축장치와, 이를 제어하는 헤더압축제어장치와, 상기 압축된 전체헤더패킷 또는/ 및 압축헤더패킷을 하위계층으로 전달하는 데이터 전송장치로 이루어지는 헤더압축담당계층과; 상기 전달 받은데이터를 전송제어장치 제어에 따라 저장하거나 수신측으로 전송하는 버퍼및 전송장치와, 수신측으로 전송된 데이터중 전송에 실패한 데이터를 판별하여 전송실패정보를 상위계층에 전달하는 전송실패판별장치로 이루어지는 링크제어계층;으로 이루어진 통신시스템이다.
상기 시스템에서는 상위계층으로부터 전달 받은 데이터의 헤더를 헤더압축담당계층에서 압축하여 상기 압축된 전체헤더패킷 또는/및 압축헤더패킷을 링크제어계층으로 전달하며, 링크제어계층은 상기 전달 받은 데이터를 저장수단에 저장하거나 수신측으로 전송하고 이후 수신측으로 전송한 데이터중 전송에 실패한 데이터가 있는가를 판단하며 전송에 실패한 데이터가 있는 경우에는 해당 데이터의 전송실패정보를 헤더압축담당계층으로 전달하여, 헤더압축담당계층이 전체헤더패킷과 압축헤더패킷의 전송을 제어하는 데이터 전송 장치 및 방법에 관한 것이다.
이하 종래기술에 대해 설명한다.
먼저, 종래 및 본 발명에 대한 일반적인 배경 설명을 한다.
제2세대 회선망인 GSM(Global System for Mobile communications)과 패킷망인 GPRS(General Packet Radio Service)를 기초로 한 제3세대 WCDMA 기술(비동기식 IMT-2000)의 세부규격서 작성을 위해 유럽의 ETSI, 일본의 ARIB/TTC, 미국의 Tl, 중국의 CWTS 및 한국의 TTA 등은 제3세대 공동프로젝트(Third Generation Partnership Project ; 이하, 3GPP라 약칭함)라는 프로젝트를 구성했으며, 이 공동프로젝트를 통해 음성, 영상 및 데이터와 같은 멀티미디어 서비스를 무선환경에서도 제공할 수 있는 제3세대 이동통신 시스템을 개발 중에 있다.
3GPP에서는 신속하고 효율적인 프로젝트 운영과 기술개발을 위해, 5개의 기술규격그룹(Technical Specification Groups; 이하, TSG라 약칭함)을 두어 그 활동을 지원하고 있으며, 각 TSG는 부여된 영역과 관련된 표준규격의 개발, 승인, 그리고 그 관리를 책임진다.
이들 중에서 무선접속망(Radio Access Network : 이하 RAN이라 약칭함)그룹은 제3세대 이동통신시스템에서 새로운 무선접속망의 규정을 목표로, 단말기와 UMTS 무선망(Universal Mobile Telecommunications Network Terrestrial Radio Access Network;이하, UTRAN이라 약칭함)의 기능, 요구사항 및 인터페이스에 대한 규격을 개발하며, 핵심망 (Core Network 이하 CN이라 약칭함) 그룹은 UTRAN과 회선 백본망 또는 패킷 백본망과의 연결을 위한 CN의 기능, 요구사항 및 인터페이스에 대한 규격을 개발하고 있다.
도 1은 이러한 TSG-RAN과 TSG-CN에서 권고하고 있는 망 구조중 패킷 도메인(Packet Service domain : 이하 PS domain이라 약칭함) 에서의 망 구조를 보이고 있다.
도 1을 설명하면, 먼저 UTRAN은 여러 개의 무선망 부 시스템(Radio Netkwork Subsystem : 이하 RNS라 약칭함)으로 구성되어 있으며, 하나의 RNS는 여러 개의 Node B(기지국)와 하나의 무선망 제어기(Radio Network Controller : 이하 RNC라 약칭함)로 구성되어 있다.
그리고, CN은 회선망인가 패킷망인가에 따라 그 구조가 다른데, 본 발명에서 고려하는 패킷망의 경우에는 여러 개의 담당 GPRS 지원 노드(Serving GPRS Support Node : 이하 SGSN이라 약칭함)와 하나의 게이트웨이 GPRS 지원 노드(Gateway GPRSSupport Node : 이하 GGSN이라 약칭함)로 구성된다.
상기 도 1의 각 부분의 역할은 다음과 같다.
Node B는 단말(User Equipment : 이하 UE라 약칭함)이 UTRAN과 접속하기 위한 접속점의 역할을 하며, RNC는 각 UE에 대한 무선 자원의 할당 및 관리를 한다.
RNC는 두 가지로 구분되는데, 공용무선자원의 관리를 맡고 있는 제어 RNC(Control RNC : 이하 CRNC라 약칭함)와 각 단말에 할당된 전용무선자원을 관리하는 담당 RNC(Serving RNC : 이하 SRNC라 약칭함)로 나누어진다.
그리고 특정 UE의 입장에서 자신의 SRNC가 위치한 RNS를 특별히 담당 RNS(Serving RNS : 이하 SRNS라 약칭함)라고 한다.
SGSN은 UTRAN에서 전송한 정보를 라우팅하는 역할을 하며, GGSN은 정보의 목적지가 현재의 CN이 아닌 다른 망일 경우에 정보를 넘겨주는 게이트웨이의 역할을 한다.
PDN (Packet Domain Network)은 PS domain의 백본망으로, 다른 망과의 PS domain에서의 연결을 지원한다.
또한 상기 도 1의 각 부분의 인터페이스는 서로 간의 구별을 위해 다음과 같은 각각의 고유한 이름을 사용하고 있다.
UE와 Node B 사이는 Uu, Node B와 RNC 사이는 Iub, RNC와 RNC 사이는 Iur, RNC와 SGSN 사이는 Iu, SGSN과 GGSN 사이 또는 SGSN과 SGSN 사이는 Gn 인터페이스라고 한다.
상기 도 1은 망 구조의 한 예를 보인 것이며, 실제로는 Iur은 존재할 수도있고 존재하지 않을 수도 있으며, 다른 SGSN에 속한 RNC들 사이에도 Iur이 존재할 수 있다.
또한, SGSN 사이의 Gn도 존재할 수도 있고 존재하지 않을 수도 있다.
도 1의 망 구조를 좀더 자세하게 살펴보면 도 2 및 도 3과 같은 계층적 구조로 나타낼 수 있다.
도 2는 사용자 데이터의 전송을 위한 사용자 평면 (User plane : 이하 U-plane으로 약칭)을 나타내고, 도 3은 제어 신호의 전달을 위한 제어 평면 (Control plane : 이하 C-plane으로 약칭)을 나타낸다.
이들 계층 중 특히 무선 구간인 Uu 인터페이스의 세부 계층이 도 4에 나타나있으며, 이들을 자세히 살펴보면, U-plane에는 패킷 데이터 수렴 프로토콜계층(Packet Data Convergence Protocol Layer : 이하 PDCP라 약칭함) 계층, 무선링크제어 계층(Radio Link Control Layer : 이하 RLC라 약칭함), 매체접속제어 계층(Medium Access Control Layer : 이하 MAC이라 약칭함) 및 제1계층으로 물리계층(Physical Layer : 이하 Ll이라 약칭함)이 있으며, 제어평면에는 무선자원제어 계층(Radio Resource Control Layer : 이하 RRC라 약칭함), RLC계층, MAC계층 및 Ll계층이 있다.
이하 상기 도 4의 각 계층을 설명한다.
상기의 Ll계층은 다양한 무선전송기술을 이용해 상위 계층에 정보전송서비스(Information Transfer Service)를 제공한다.
상위에 있는 MAC계층과는 전송채널(Transport Channel)을 통해 연결되어 있으며, 이 전송채널을 통해 MAC계층과 물리계층 사이의 데이터가 이동한다.
전송채널은 단말이 독점적으로 이용할 수 있는지, 또는 여러 개의 단말이 공유해서 사용하는지에 따라 각각 전용전송채널(Dedicated Transport Channel)과 공용전송채널(Common Transport Channel)로 구분된다.
MAC계층은 무선자원의 할당 및 재할당을 위한 MAC 파라미터의 재할당 서비스를 제공한다.
상위계층인 RLC계층과는 논리채널(Logical Channel)로 연결되어 있으며, 전송되는 정보의 종류에 따라 다양한 논리채널이 제공된다.
일반적으로 제어평면의 정보를 전송할 경우에는 제어채널(Control Channel)을 이용하고, 사용자 평면의 정보를 전송하는 경우는 트래픽 채널(Traffic Channel )을 사용한다.
RLC계층은 무선링크의 설정 및 해제 서비스를 제공한다. 또한, 사용자평면의 상위계층으로부터 내려온 RLC 서비스데이터단위(Service Data Unit; 이하, SDU라 약칭함)의 분할 및 재조립 (Segmentation and Reassembly) 기능을 수행한다.
RLC SDU는 RLC계층에서 처리용량에 맞게 크기가 조절된 후 헤더(Header)정보가 더해져 프로토롤데이터단위(Protocol Data Unit; 이하, PDU라 약칭함)의 형태로 MAC계층에 전달된다.
RLC계층은 상위로부터 내려온 RLC SDU를 처리하는 방식에 따라 투명모드(Transparent Mode), 무응답모드(Unacknowledged Mode), 응답모드(Acknowledged Mode)의 세가지 방식으로 동작하고, RLC계층에는 상위계층에서 내려온 RLC SDU 또는 RLC PDU들을 저장하기 위한 RLC버퍼가 존재한다.
PDCP계층은 RLC계층의 상위에 위치하여, IPv4나 IPv6와 같은 네트워크 프로토콜을 통해 전송되는 데이터가 RLC계층에 맞는 형태로 데이터를 전송할 수 있도록 한다.
이 외에도 유선망에서 사용되는 불필요한 제어정보를 줄여 무선 인터페이스를 통해 효율적으로 전송될 수 있도록 해준다.
상기 기능은 헤더압축(Header Compression)이라고 불리며, 한 예로 TCP/IP용 헤더정보의 양을 줄이는데 사용될 수 있다.
RRC계층은 임의의 영역에 위치한 모든 단말에 정보를 방송해주는 정보방송서비스(Information broadcast service)를 제공한다. 또한, 제3계층에서의 제어신호교환을 위한 제어평면신호처리를 담당하여, 단말과 UTRAN간 무선자원의 설정, 유지및 해제 기능을 갖는다.
특히, RRC는 무선베어러(Radio Bearer : 이하 RB라 약칭함)의 설정, 유지 및 해제 기능과, 무선자원접속에 필요한 무선 자원의 할당, 재배치 또는 해제 기능을 갖는다. 이때 RB는 단말과 UTRAN간의 데이터 전달을 위해 제2계층에 의해 제공되는 서비스를 의미한다.
즉, 하나의 RB가 설정된다는 것은 무선 구간에서 특정 서비스를 제공하기 위하여 필요한 프로토콜 계층 및 채널의 특성을 규정하고, 각각의 구체적인 파라미터및 동작 방법을 설정하는 과정을 의미한다.
이하 상기의 PDCP에서 사용되는 IP 헤더 압축 알고리즘을 도 5,6,7를 참고로하여 구체적으로 살펴본다.
단말과 UTRAN에 위치한 PDCP계층이 수행하는 헤더압축기법을 자세히 살펴보도록 하자. IP패킷의 전송시, 특히 무선인터페이스를 통한 IP패킷의 전송시 헤더의 압축이 필요한 이유는 IP패킷의 헤더크기가 패킷의 패이로드(패킷의 데이터부분)크기와 비교하여 무시할 수 있을 정도로 작지 않기 때문이다.
예를 들어, 무선단말이 IP망으로부터 데이터를 수신하는 경우를 생각해보자.
각 패킷들은 IP망에서 라우팅될 수 있도록 IP의 헤더정보가 첨부되는데, IPv4의 경우에는 IP헤더에만 24옥텟이 사용되고, IPv6의 경우에는 40옥텟이 필요하다. 여기에 IP계층의 상위로 TCP계층이나 UDP계층이 위치해 있다면 추가로 각각 24옥텟과 8옥텟이 더 필요하다. 따라서, TCP/IPv6를 이용하여 패킷을 전송하는 경우에는 최소 64옥텟이 필요하게 되고, UDP/IPv6를 이용하여 전송하는 경우에는 하나의 패킷당 최소 48옥텟의 헤더정보가 필요함을 의미한다.
하지만, UDP/IPv6를 이용해 전송하는 VoIP(Voice Over IP) 서비스의 경우를 생각해보면, 48옥텟의 헤더크기는 음성코덱에 의해 압축된 음성패이로드의 크기인 수십옥텟(8kbps의 G.729코덱의 경우 20옥텟)에 비해 무척 큰 크기임을 알 수 있다.
따라서, IP패킷의 형태 그대로 전송한다면, 무선링크와 같이 전송대역폭이 한정되어 있는 링크에 사용하는 경우 커다란 성능저하를 가져올 것은 쉽게 예측할 수 있다. 이와 같은 필요에 의해서, 오랜시간 패킷의 헤더정보를 줄일 수 있는 헤더압축기법이 연구되어 왔다.
헤더압축기법은, 동일한 패킷스트림(Packet Stream)에 속하는 패킷들의 헤더정보는 거의 동일하다는 특성을 이용한다.
다른 의미로, 패킷스트림은 헤더정보가 매우 유사한 패킷들이고, 일반적으로 특정한 서비스를 제공하기 위하여 사용되는 패킷들은 동일한 패킷스트림이라고 할수 있다.
예를 들어, TCP/IP를 통해 패킷을 전송하는 경우, 동일한 주소(Address)와 동일한 포트(Port)번호를 갖고 전송되는 패킷들은 동일한 패킷스트림에 속한다고 생각할 수 있다.
헤더압축기법의 원리와 압축율을 알아보기 위해, 도 5에서와 같은 TCP/IPv6헤더필드를 살펴보자. 우선, 패킷스트림의 정의에서 IPv6의 주소필드들과 TCP헤더의 포트번호들은 동일한 패킷스트림에 속하므로 항상 일정할 것이다.
또한, 버전 필드는 IPv6가 사용되고 있음을 나타내며, Next Header필드는 IPv6헤더 다음에 오는 헤더정보가 TCP임을 지시하므로 해당 패킷 스트림에 대하여 동일하다고 할 수 있다.
트래픽 클래스필드는 해당 패킷의 우선순위를 나타내고, Flow Label필드는 우선순위에 의한 패킷의 제어가 필요할때 사용된다.
이때, Flow Label값이 0이외의 값으로 설정되면, Flow Label필드 앞에 있는 트래픽 클래스필드는 변하지 않는다.
하지만, Flow Label값이 0으로 설정되면 트래픽클래스 필드의 값은 변할 수 있다. 하지만, 서로 다른 트래픽클래스 필드의 값을 갖는 패킷들은 서로 다른 패킷 스트림에 속한다고 정의할 수 있으므로, 하나의 패킷 스트림에 대해서 트래픽 클래스필드와 Flow Label필드의 값은 변하지 않는다고 할 수 있다.
Hop Limit필드는 땅에서 라우터를 통과할 때마다 1씩 감소하는 필드이며, 이값이 0보다 작게 되면 해당 패킷은 폐기시킨다. 일반적으로, 패킷들은 망 내에서 동일한 경로를 통해 전송되기 때문에, 이 값 역시 특정 패킷 스트림에 대해서는 거의 일정하다고 볼 수 있다.
또한 Offset필드는 TCP 데이터의 시작점을 알려주는 것이므로 그 값이 일정하다.
따라서, 동일한 패킷 스트림에 속하는 패킷들이 전송되고 있는 경우, 패킷의 전송에 따라 그 정보가 변하지 않는 필드들은 도 5의 헤더필드에서 거의 대부분을 차지한다고 볼 수 있으며, 이들은 도 5에서 색칠한 부분들에 해당한다.
헤더압축기법에 대한 자세한 설명은 IETF(Internet Engineering Task Force)에서 발표하는 인터넷 기술과 관련된 공식 기술 문서들에서 찾을 수 있다. 참고로, PDCP계층에서는 RFC2507와 RFC3095에 기반한 헤더압축기법을 사용한다.
상기 RFC2507에서의 헤더압축기법은 IP계층 상위에 위치한 프로토콜이 TCP인지 아니면 그 이외의 프로토콜인지에 따라 구분하여 다른 압축기법을 사용할 수 있다.
즉, UDP/IP와 같이 TCP를 사용하지 않는 프로토롤은 "Compressed Non-TCP"라는 방법을 사용하고, TCP를 사용하는 경우에는 가변하는 헤더필드를 전송하는 방법에 따라 "Compressed TCP" 와 "Compressed TCP nodelta"로 구분한다.
Compressed TCP기법은 가변하는 헤더필드값의 차이가 연속되는 패킷사이에서는 그리 크지 않다는 점을 이용하여 필드전체값을 보내지 않고 패킷사이의 차이만큼을 전송하는 방법이고, "Compressed TCP nodelta"는 가변하는 헤더필드를 그대로 전송하는 방법이다.
수신측에서 압축된 헤더를 복원하기 위해서는 기준값이 필요하므로, 모든 헤더압축기법에서는 압축되지 않은 헤더의 모든 필드를 포함하고 있는 전체헤더(Full Header)를 전송하는 작업이 항상 선행되어야 한다. 전체헤더에는 도 5의 색칠한 부분과 같이 특정한 패킷스트림 내에서 변하지 않는 부분이 이후에 전송될 압축헤더의 복원에 사용된다. 도 5의 색칠한 부분과 같이, 이후에 전송되는 압축헤더정보를 복원하는데 필요한 정보들을 해당 패킷스트림의 문맥(Context)라고 정의한다. 따라서, 이 문맥은 압축헤더를 압축 전의 헤더로 복원할 수 있는 기준 정보가 된다. 또한, 문맥의 갱신이나 생성에 필요한 전체헤더를 포함한 패킷을 전체헤더패킷이라고 정의하고, 헤더정보가 압축되어 전송되는 패킷을 압축헤더패킷이라고 정의하자.
패킷의 전송 중, 문맥의 변화가 발생한다면 압축된 헤더정보를 전송하기 전에 변경된 전체헤더를 가장 먼저 전송해야한다. 이때, 전체헤더패킷은 일반 압축헤더패킷보다 훨씬 크므로, 전체헤더패킷의 전송은 가능한 줄여주어야 전송효율을 높일 수 있다. 이와 함께, 한 패킷스트림내에서 이러한 필드의 변화가 자주 발생하지 않도록 적절히 패킷스트림을 구성할 필요가 있다.
TCP/IP와 같이 "Compressed TCP" 또는 "Compressed TCP nodelta"을 사용하여 헤더를 압축하는 경우에 사용하는 헤더압축기법을 살펴보도록 하자.
상기에서도 언급했듯이, 특정 패킷스트림에 대하여 헤더압축기법을 사용하기위해서는 처음에 전체헤더를 전송하는 과정이 필요하다.
하지만, 망내에서 하나 이상의 패킷스트림이 존재할 수 있으므로, 각 패킷스트림에 대한 문맥을 지시하는 식별자를 압축식별자(Compression Identifier;이하 CID라 약칭함)라고 정의한다.
상기 CID값은 TCP 패킷에 대해서는 항상 8비트의 길이를 가지며, 압축헤더나 전체헤더를 전송할 경우에는 항상 CID값을 같이 전송해야한다.
전송된 전체헤더정보는 CID값에 따라 수신측에 저장되어 있으며, 패킷이 도착하면 CID값을 토대로 해당 전체헤더정보를 읽어 들여 원래의 헤더정보를 복원한다.
도 6은 TCP/IPv6 패킷에 대해 헤더압축기법이 사용될 때 전송하는 전체헤더의 구조이다. 도 6의 전체헤더는 "Compressed TCP"와 "Compressed TCP nodelta" 두 경우 모두에 대해 동일하다.
원래의 TCP/IPv6 헤더필드에는 CID필드가 없어 CID값을 넣을 수 없으므로, 이를 삽입할 수 있는 적절한 필드를 찾을 필요가 있다. 이때, 기존의 "패이로드길이" 필드는 하위계층으로부터 전달받을 수 있는 정보이므로, 굳이 해당 필드를 사용할 필요가 없다. 따라서, 이들 필드에 길이정보를 넣지 않고 CID를 넣어 전송할수 있다.
Compressed TCP 경우의 TCP/IPv6 패킷에 대해 헤더압축기법이 사용될 때 전송하는 압축헤더는 도 6의 TCP/IPv6 헤더 중에서 그림에서 색칠하지 않은 부분들로 구성되며, 그 크기는 일반적으로 4~7 옥텟이다. 이때, 압축헤더의 필드 중 CID 필드는 고정값을 가지고, Checksum 필드는 가변값을 가지며, 이를 제외한 나머지 필드들은 이전 압축헤더와의 차이(Difference)값을 전송한다.
Compressed TCP nodelta 경우의 TCP/IPv6 패킷에 대해 헤더압축기법이 사용될 때 전송하는 압축헤더는 도 6의 TCP/IPv6 헤더 중 IPv6 헤더의 CID필드와 TCP헤더의 발신지 포트와 목적지 포트 필드를 제외한 나머지 필드들로 구성되며, 그 크기는 일반적으로 17옥텟이다. 이때, 압축헤더의 필드 중 CID 필드는 고정값을 가지며, 이를 제외한 나머지 필드들은 가변값을 갖는다.
UDP/IP와 같이 TCP를 사용하지 않는 프로토콜은 "Compressed Non-TCP"라는 방법을 사용하여 헤더를 압축한다. 이 방법은 TCP/IP의 경우와 비슷하므로 간단하게 살펴보도록 하자.
TCP/IP의 경우와 마찬가지로, 특정 패킷스트림에 대하여 헤더압축기법을 사용하기 위해서는 처음에 전체헤더를 전송하는 과정이 필요하며, 또한 각 패킷스트림에 대한 구별을 할 수 있는 CID가 필요하다. 상기 CID값은 8비트 또는 16비트의 길이를 가지며, 압축헤더나 전체헤더를 전송할 경우에는 항상 CID값을 같이 전송해야한다.
UDP/IP 헤더압축기법에서는 각각의 패킷스트림을 구별하기 위해서 CID 뿐만아니라 해당 헤더정보의 세대(Generation)를 나타내는 "Generation"필드를 추가로 이용한다. Generation 필드는 해당 패킷의 헤더정보가 얼마나 오래된 것인지를 지시하며, 패킷의 전송시 항상 CID값과 함께 전송된다.
도 7은 UDP/IPv6 패킷에 대해 헤더압축기법이 사용될 때 전송하는 전체헤더의 구조이다.
원래의 UDP/IPv6 헤더필드에는 CID필드 또는 Generation필드가 없어 그값을 넣을 수 없으므로, 이를 삽입하기 위해 기존의 "패이로드길이" 필드나 "길이" 필드에 CID와 Generation을 넣어 전송한다. 도면에서 CID는 8비트의 CID를 사용하는 경우에는 CID(1)만을 이용하고, 16비트를 사용하는 경우에는 CID(2)만을 이용하며, Generation은 패이로드길이 필드의 일부분을 이용한다.
UDP/IPv6 패킷에 대해 헤더압축기법이 사용될 때 전송하는 압축헤더는 도 7의 UDP/IPv6 헤더 중에서 그림에서 색칠하지 않은 부분들로 구성되며, 그 크기는 일반적으로 4∼5 옥텟이다. 이때, 압축헤더의 필드 압축헤더의 필드 중 CID 필드와 Generation 필드는 고정값을 가지며, Checksum 필드는 가변값을 갖는다.
상기에서 설명한 바와 같이 헤더압축기법을 사용하면 재킷의 헤더크기를 상당량 줄일 수 있다는 장점이 있다. 특히 무선 인터페이스를 통해 패킷을 전송하고자 할 때, 패킷의 헤더크기가 재킷의 패이로드(패킷의 데이터부분)크기와 비교하여 상당히 크기 때문에, 헤더의 압축은 반드시 필요하다고 할 수 있다.
도 9는 종래에 헤더압축기법을 사용하여 패킷을 전송하는 시스템에 대한 블럭도이다.
종래 시스템의 PDCP계층은 헤더압축제어장치에서 헤더압축장치로 하여금 상위계층으로부터 수신한 데이터의 헤더를 압축하도록 한다. 전체헤더패킷 또는 압축헤더패킷으로 변환된 데이터는 데이터전송장치를 통해서 RLC계층으로 전달된다.
RLC계층에서는 이 전달된 데이터를 전송제어장치에서의 제어정보에 따라 버퍼에 저장하거나 전송장치를 통해 수신측으로 전송한다.
헤더압축기법으로 상기의 Compressed TCP 기법을 사용하는 경우에는, 한 패킷스트림에 대해서, 송신측은 먼저 전체헤더패킷을 전송하여 수신측에 문맥(Context)을 구성한 후, 이후의 패킷에 대해서는 이전 패킷과의 차이만큼만 나타내는 압축헤더를 사용하여 전송한다.
만약 전체헤더패킷이 성공적으로 전송되지 않는 경우에는 수신측에서 문맥(Context)이 올바르게 구성되지 못하므로, 수신측에서 이후의 압축헤더를 복원하는데 실패하게 된다. 또한, 압축헤더패킷이 성공적으로 전송되지 않은 경우에도 수신측의 문맥(Context)이 올바르게 갱신(Update)되지 않기 때문에, 전체헤더패킷이 손실된 경우와 마찬가지로 이후의 압축헤더를 복원할 수 없게 된다.
이와 같이 손상된 문맥(Context)은 해당 문맥(Context)의 새로운 전체헤더에 의해서만 복구될 수 있으며, 수신측에서는 이를 위해서 송신측에 해당문맥(Context)에 대한 새로운 전체헤더의 전송을 요구하는 CONTEXT_STATE 패킷을 전송한다.
도 8은 종래에 Context의 복구를 위해 사용되고 있는 Context State 패킷의 구조를 나타낸 도면이다.
CONTEXT_STATE 패킷은 여러 개의 CID 필드로 구성되는데, 각각의 CID 필드는 하나의 손상된 문맥(Context) 즉 하나의 손상된 패킷스트림을 뜻한다. 이러한 CONTEXT_STATE 패킷은 하나의 문맥(Context)이 손상될 때마다 사용하는 것이 아니라, 어느 개수 이상의 문맥(Context)이 손상되었을 때 이들을 모아 송신측으로 전송된다. 또한, 수신측에서 송신측으로 이러한 CONTEXT_STATE 패킷을 전송하는 것은 그 자체로 무선 자원을 낭비하는 것이기 때문에, RFC2507에서는 그 사용 빈도를 제한하고 있다.
그렇기 때문에 Compressed TCP 헤더압축기법을 사용하는 데 있어서 소실된 패킷이 발생할 경우, 수신측은 해당 문맥(Context)을 복구하기까지 어느 정도의 시간을 소비해야 하고, 송신측은 수신측에서 해당 문맥(Context)이 손상되었음을 모르기 때문에 그 동안 불필요하게 압축헤더패킷을 전송하므로 많은 무선자원을 낭비하게 된다.
따라서 본 발명에서는 상기와 같은 종래의 문제점을 해결하기 위한 것으로, UMTS시스템에서 Compressed TCP 헤더압축기법을 이용해 패킷을 전송하는 경우, 헤더압축기능을 수행하는 송신측의 PDCP계층이, 하나의 패킷스트림에서 전송된 전체헤더패킷 또는 압축헤더패킷들 중 하나의 재킷이라도 전송이 실패했음을 하위계층인 RLC계층으로부터 전달 받으면, 상기 패킷스트림의 해당 문맥(Context)이 손상되었음을 인지하고, 즉시 해당 문맥(Context)에 대한 새로운 전체헤더패킷을 전송함으로써, 수신측에서 손상된 문맥(Context)이 빨리 복구될 수 있도록 하여, 헤더압축기법에 의한 전송효율과 복원효율을 증가시킬 수 있도록 한 장치와 방법을 제안한다.
도 1은 3GPP에서 권고하고 있는 망 구조중 패킷 도메인 (PS domain) 에서의 망 구조를 나타낸 도면
도 2는 사용자 데이터의 전송을 위한 사용자 평면 (User plane)을 나타낸 도면
도 3은 제어 신호의 전달을 위한 제어평면 (Control plane )을 나타낸 도면
도 4는 3GPP 무선접속망 규격을 기반으로 한 단말과 UTRAN사이의 무선접속인터페이스 프로토콜의 구조
도 5는 TCP/IPv6의 일반헤더의 구조를 나타낸 도면
도 6은 TCP/IPv6의 헤더압축기법 사용 시 전체헤더의 구조를 나타낸 도면
도 7은 UDP/IPv6의 헤더압축기법 사용 시 전체헤더의 구조를 나타낸 도면
도 8은 종래에 Context의 복구를 위해 사용되고 있는 Context State 패킷의 구조를 나타낸 도면
도 9는 종래에 헤더압축기법을 사용하여 패킷을 전송하는 시스템에 대한 블럭도
도 10은 본 발명에서 제안하는 Quick Context Recovery방법을 사용하는 시스템에 대한 블럭도
본 발명의 패킷 데이터를 전송하고 제어하는 통신시스템은,
송신측 헤더압축담당계층은 상위계층으로부터 전달 받은 데이터의 헤더를 압축하여 전체헤더패킷 또는/및 압축헤더패킷으로 변환하는 헤더압축장치와, 이를 제어하는 헤더압축제어장치와, 상기 압축된 전체헤더패킷 또는/및 압축헤더패킷을 하위계층으로 전달하는 데이터 전송장치가 구성되며; 링크제어계층은 상기 헤더압축담당계층으로부터 전달 받은 데이터를 전송제어장치 제어에 따라 저장하거나 수신측으로 전송하는 버퍼및 전송장치와, 수신측으로 전송된 데이터 중 전송에 실패한 데이터를 판별하여 전송실패정보를 상위계층에 전달하는 전송실패판별장치;로 구성되는 것을 특징으로 한다.
또한 본 발명의 패킷 데이터의 전송방법은, 하나의 패킷스트림(Packet Stream)에 대해 수신측의 헤더압축담당계층에서 전체헤더패킷에 있는 전체헤더정보를 이용하여 압축헤더패킷에 있는 압축헤더정보를 복원하도록 하기 위해 모든 헤더정보를 갖는 전체헤더패킷 또는 압축된 헤더정보를 갖는 압축헤더패킷을 전송하는 통신시스템의 송신측 헤더압축담당계층에 있어서, 하위계층인 링크제어계층을 통하여 상기 패킷을 전송하는 단계와; 상기 링크제어계층으로부터 상기 패킷의 전송결과를 전달받는 단계와; 상기 하나 이상의 패킷에 대하여 전송실패정보를 전달받은 경우에는 상기 패킷스트림에 대하여 이후의 첫 패킷을 전체헤더패킷으로 전송하는 단계;를 포함하는 것을 특징으로 한다.
또한 본 발명은 하나의 패킷스트림(Packet Stream)에 대해 수신측의 헤더압축담당계층인 PDCP계층에서 전체헤더패킷에 있는 전체헤더정보를 이용하여 압축헤더패킷에 있는 압축헤더정보를 복원하도록 하기 위해 모든 헤더정보를 갖는 전체헤더패킷 또는 압축된 헤더정보를 갖는 압축헤더패킷을 섞어서 전송할 수 있는 UMTS시스템의 송신측 PDCP계층에 있어서, 링크제어계층인 RLC계층을 통하여 상기 패킷을 전송하는 단계와; 상기 RLC계층으로부터 상기 패킷의 전송결과를 전달받는 단계와; 상기 하나 이상의 패킷에 대하여 전송실패정보를 전달받은 경우에는 상기 패킷스트림에 대하여 이후의 첫 패킷을 전체헤더패킷으로 전송하는 단계;를 포함하는 것을 특징으로 한다.
바람직하게 본발명의 전송실패정보에는 해당패킷의 식별정보 또는/및 전송실패지시정보를 포함하는 것을 특징으로 한다.
바람직하게 본 발명에서 문맥(Context)이 전체헤더패킷 또는 압축헤더패킷등의 임의에 의해 갱신되는 압축방법을 사용할 경우, 헤더압축담당계층이 헤더압축후 링크제어계층으로 전달한 패킷중 상기 임의의 패킷이 수신측으로의 전송을 실패했을 경우에는 링크제어계층이 헤더압축담당계층으로 해당 패킷의 식별정보 또는/및 전송실패지시정보를 알려주는것을 특징으로 한다.
바람직하게 본 발명에서 문맥(Context)이 임의의 패킷에 의해 갱신되는 압축방법은 Compressed TCP 방법인 것을 특징으로 한다.
바람직하게 본 발명에서 헤더압축담당계층은 링크제어계층으로부터 임의 패킷의 전송실패정보를 전달받으면 해당 패킷스트림의 이후의 첫 패킷을 전체헤더패킷으로 전송하는것을 특징으로 한다.
바람직하게 본 발명에서 헤더압축담당계층은 링크제어계층으로부터 임의 패킷의 전송실패정보를 전달받은 즉시 해당 문맥(Context)의 새로운 전체헤더패킷을수신측으로 전송하는것을 특징으로 한다.
바람직하게 본 발명에서 RLC계층으로부터 전송실패정보를 전달 받은 PDCP계층은 전송에 실패한 패킷의 CID와 같은 CID를 사용하는 이후의 첫 패킷을 전체헤더패킷으로 압축하여 RLC계층으로 전달하는 것을 특징으로 한다.
바람직하게 본 발명에서 문맥(Context)이 전체헤더패킷에 의해서만 갱신되는 압축방법을 사용할 경우, 헤더압축담당계층이 헤더압축 후 링크제어계층으로 전달한 패킷 중 상기 전체헤더패킷이 수신측으로의 전송을 실패했을 경우에는 링크제어계층이 헤더압축담당계층으로 해당 패킷의 식별정보 또는/및 전송실패지시정보를 알려주는것을 특징으로 한다.
바람직하게 본 발명에서 헤더압축담당계층은 링크제어계층으로부터 전체헤더패킷의 전송실패정보를 전달받으면 해당 패킷스트림의 이후의 첫 패킷을 전체헤더패킷으로 전송하는것을 특징으로 한다.
바람직하게 본 발명에서 헤더압축을 담당하는 PDCP계층의 상위계층은 무선자원을 관리하는 RRC계층이며, 무선베어러(Radio Bearer)를 설정할 때 RRC계층이 RLC계층으로 RLC에서 폐기되는 SDU의 정보를 상위 계층으로 알려주도록 설정하는 것을 특징으로 한다.
바람직하게 본 발명에서 RRC는 RLC를 셋업할 때 전송실패보고지시자를 통해 SDU 폐기정보의 전달 여부를 결정하여 그 정보를 상위계층으로 알려주는것을 특징으로 한다.
바람직하게 본 발명에서 PDCP 계층이 PDCP PDU를 RLC계층으로 전달할 때 해당 PDU에 대한 전송실패 결과를 PDCP 계층으로 알리도록 지시하는것을 특징으로 한다.
바람직하게 본 발명에서 PDCP 계층이 PDCP PDU를 RLC계층으로 전달할 때 해당 PDU와 함께 전송실패보고지시자를 전달하여 RLC계층이해당 SDU의 폐기시 그 정보를 상위계층으로 알려주도록 하는것을 특징으로 한다.
본 발명의 다른 목적, 특징들은 첨부한 도면을 참조한 실시예들의 상세한 설명을 통해 명백해질 것이다.
이하 첨부된 도면을 참조하여 본 발명에 따른 패킷의 헤더압축을 지원하는 통신 시스템에서 전체헤더패킷과 압축헤더패킷의 전송 제어 장치와 방법을 설명한다.
먼저, 본 발명의 UMTS시스템에서는 송신측 PDCP계층으로부터 패킷을 전달받은 RLC계층이 수신측으로 전송한 패킷에 대한 전송실패결과를 PDCP계층으로 전달함으로써 PDCP계층이 전체헤더패킷과 압축헤더패킷의 전송을 효율적으로 제어할 수 있도록 한다. 이를 위해 RLC계층에는 모드에 상관없이 상위로부터 내려온 PDCP PDU의 전송실패결과를 PDCP계층으로 알려주는 기능을 추가할 필요가 있다.
도 9는 종래에 헤더압축기법을 사용하여 패킷을 전송하는 시스템에 대한 블럭도이다.
상기한 바와 같이 헤더압축기법을 사용하여 패킷을 전송하는 시스템에 대한 설명이고, 도10은 본 발명에서 제안하는 Quick Context Recovery방법을 사용하는 시스템에 대한 설명이다.
도 10에 대해 설명한다.
도면 10의 시스템은, 상위계층으로부터 전달 받은 데이터의 헤더를 압축하여 전체헤더패킷 또는/및 압축헤더패킷으로 변환하는 헤더압축장치와, 이를 제어하는 헤더압축제어장치와, 상기 압축된 전체헤더패킷 또는/및 압축헤더패킷을 하위계층으로 전달하는 데이터 전송장치로 이루어지는 헤더압축담당계층과; 상기 헤더압축담당계층으로부터 전달된 데이터를 전송제어장치 제어에 따라 저장하거나 수신측으로 전송하는 버퍼및 전송장치와, 수신측으로 전송된 데이터중 전송에 실패한 데이터를 판별하여 전송실패정보를 상위계층에 전달하는 전송실패판별장치로 이루어지는 링크제어계층;으로 구성되어 있다.
여기서, UMTS 시스템에서는 헤더압축담당계층은 PDCP계층이며, 링크제어계층은 RLC계층이다.
PDCP계층의 헤더압축장치에서 전체헤더패킷 또는 압축헤더패킷으로 변환된 데이터는 데이터전송장치를 통해서 RLC계층으로 전달된다.
RLC계층에서는 이 전달 받은 데이터를 전송제어장치에서의 제어정보에 따라 버퍼에 저장하거나 전송장치를 통해 수신측으로 전송한다.
이때 RLC계층 내에서 수신측으로 전송된 데이터는 제어정보를 통해 전송실패 판별장치에서 그 전송의 실패 여부가 판별되며, 만약 데이터의 전송이 실패로 판별된 경우, 전송실패판별장치는 그 전송실패정보를 PDCP계층의 헤더압축제어장치로 전달한다.
RLC계층으로부터 전송실패정보를 전달 받은 PDCP계층은 전송에 실패한 패킷의 CID와 같은 CID를 사용하는 이후의 첫 패킷을 전체헤더패킷으로 압축하여 RLC계층으로 전달한다.
이상에서 본 발명의 바람직한 실시예를 설명하였으나, 본 발명은 다양한 변화와 변경 및 균등물을 사용할 수 있다. 본 발명은 상기 실시예를 적절히 변형하여 동일하게 응용할 수 있음이 명확하다.
즉, 문맥(Context)이 전체헤더패킷에 의해서만 갱신되는 압축방법을 사용할 경우, 헤더압축담당계층이 헤더압축 후 링크제어계층으로 전달한 패킷 중 상기 전체헤더패킷이 수신측으로의 전송을 실패했을 경우에는 링크제어계층이 헤더압축담당계층으로 해당 패킷의 식별정보와 전송실패지시정보를 알려주도록 한다.
따라서 상기 기재 내용은 하기 특허청구범위의 한계에 의해 정해지는 본 발명의 범위를 한정하는 것이 아니다.
본 발명은 헤더압축기법을 사용하여 패킷 데이터를 전송하는 시스템에 있어서, 임의 패킷의 전송 실패로 인해 수신측의 문맥(Context)에 손상이 발생한 경우, 송신측 헤더압축담당계층이 하위의 링크제어계층으로부터의 해당 패킷에 대한 전송실패정보를 받은 즉시 해당 문맥(Context)의 새로운 전체헤더패킷을 수신측으로 전송함으로써, 추가로 패킷이 유실되는 것을 막고 보다 빠르게 문맥(Context)을 복구하여, 전송 효율과 압축복원 효율을 높일 수 있다.

Claims (16)

  1. 하나의 패킷스트림(Packet Stream)에 대해 수신측의 헤더압축담당계층에서 전체헤더패킷에 있는 전체헤더정보를 이용하여 압축헤더패킷에 있는 압축헤더정보를 복원하도록 하기 위해 모든 헤더정보를 갖는 전체헤더패킷 또는 압축된 헤더정보를 갖는 압축헤더패킷을 전송하는 통신시스템의 송신측 헤더압축담당계층에 있어서,
    하위계층인 링크제어계층을 통하여 상기 패킷을 전송하는 단계와;
    상기 링크제어계층으로부터 상기 패킷의 전송결과를 전달받는 단계와;
    상기 하나 이상의 패킷에 대하여 전송실패정보를 전달받은 경우에는 상기 패킷스트림에 대하여 이후의 첫 패킷을 전체헤더패킷으로 전송하는 단계;를 포함하는 것을 특징으로 하는 패킷 데이터 전송방법.
  2. 하나의 패킷스트림(Packet Stream)에 대해 수신측의 헤더압축담당계층인 PDCP계층에서 전체헤더패킷에 있는 전체헤더정보를 이용하여 압축헤더패킷에 있는 압축헤더정보를 복원하도록 하기 위해 모든 헤더정보를 갖는 전체헤더패킷 또는 압축된 헤더정보를 갖는 압축헤더패킷을 섞어서 전송할 수 있는 UMTS시스템의 송신측PDCP계층에 있어서,
    링크제어계층인 RLC계층을 통하여 상기 패킷을 전송하는 단계와;
    상기 RLC계층으로부터 상기 패킷의 전송결과를 전달받는 단계와;
    상기 하나 이상의 패킷에 대하여 전송실패정보를 전달받은 경우에는 상기 패킷스트림에 대하여 이후의 첫 패킷을 전체헤더패킷으로 전송하는 단계;를 포함하는 것을 특징으로 하는 패킷 데이터 전송방법.
  3. 제 1항 또는 제 2항에 있어서,
    전송실패정보에는 해당패킷의 식별정보 또는/및 전송실패지시정보를 포함하는 것을 특징으로 하는 패킷 데이터 전송방법.
  4. 제 1항 또는 제 2항에 있어서,
    문맥(Context)이 전체헤더패킷 또는 압축헤더패킷등의 임의에 의해 갱신되는 압축방법을 사용할 경우, 헤더압축담당계층이 헤더압축후 링크제어계층으로 전달한 패킷중 상기 임의의 패킷이 수신측으로의 전송을 실패했을 경우에는 링크제어계층이 헤더압축담당계층으로 해당 패킷의 식별정보 또는/및 전송실패지시정보를 알려 주는것을 특징으로 하는 패킷 데이터 전송방법.
  5. 제 4항에 있어서,
    문맥(Context)이 임의의 패킷에 의해 갱신되는 압축방법은 Compressed TCP 방법인 것을 특징으로 하는 패킷 데이터 전송방법.
  6. 제 4항에 있어서,
    헤더압축담당계층은 링크제어계층으로부터 임의 패킷의 전송실패정보를 전달받으면 해당 패킷스트림의 이후의 첫 패킷을 전체헤더패킷으로 전송하는것을 특징으로 하는 패킷 데이터 전송방법.
  7. 제 6항에 있어서,
    헤더압축담당계층은 링크제어계층으로부터 임의 패킷의 전송실패정보를 전달받은 즉시 해당 문맥(Context)의 새로운 전체헤더패킷을 수신측으로 전송하는것을 특징으로 하는 패킷 데이터 전송방법.
  8. 제 6항에 있어서, RLC계층으로부터 전송실패정보를 전달 받은 PDCP계층은 전송에 실패한 패킷의 CID와 같은 CID를 사용하는 이후의 첫 패킷을 전체헤더패킷으로 압축하여 RLC계층으로 전달하는 것을 특징으로 하는 패킷 데이터 전송방법.
  9. 제 1항 또는 제 2항에 있어서,
    문맥(Context)이 전체헤더패킷에 의해서만 갱신되는 압축방법을 사용할 경우, 헤더압축담당계층이 헤더압축 후 링크제어계층으로 전달한 패킷 중 상기 전체 헤더패킷이 수신측으로의 전송을 실패했을 경우에는 링크제어계층이 헤더압축담당계층으로 해당 패킷의 식별정보 또는/및 전송실패지시정보를 알려주는것을 특징으로 하는 패킷 데이터 전송방법.
  10. 제 9항에 있어서,
    문맥(Context)이 전체헤더에 의해서만 갱신되는 압축방법은 Compressed TCP nodelta 또는 Compressed non-TCP 방법인 것을 특징으로 하는 패킷 데이터 전송방법.
  11. 제 9항에 있어서,
    헤더압축담당계층은 링크제어계층으로부터 전체헤더패킷의 전송실패정보를 전달받으면 해당 패킷스트림의 이후의 첫 패킷을 전체헤더패킷으로 전송하는것을 특징으로 하는 패킷 데이터 전송방법.
  12. 제 2항에 있어서,
    헤더압축을 담당하는 PDCP계층의 상위계층은 무선자원을 관리하는 RRC계층이며, 무선베어러(Radio Bearer)를 설정할 때 RRC계층이 RLC계층으로 RLC에서 폐기되는 SDU의 정보를 상위 계층으로 알려주도록 설정하는 것을 특징으로 하는 패킷 데이터 전송방법.
  13. 제 12항에 있어서,
    RRC는 RLC를 셋업할 때 전송실패보고지시자를 통해 SDU 폐기정보의 전달 여부를 결정하여 그 정보를 상위계층으로 알려주는것을 특징으로 하는 패킷 데이터 전송방법.
  14. 제 2항에 있어서,
    PDCP 계층이 PDCP PDU를 RLC계층으로 전달할 때 해당 PDU에 대한 전송실패결과를 PDCP 계층으로 알리도록 지시하는것을 특징으로 하는 패킷 데이터 전송방법.
  15. 제 14항에 있어서, PDCP 계층이 PDCP PDU를 RLC계층으로 전달할 때 해당 PDU와 함께 전송실패보고지시자를 전달하여 RLC계층이해당 SDU의 폐기시 그 정보를 상위계층으로 알려주도록 하는것을 특징으로 하는 패킷 데이터 전송방법.
  16. 패킷 데이터를 전송하고 제어하는 통신시스템에 있어서,
    송신측 헤더압축담당계층은 상위계층으로부터 전달 받은 데이터의 헤더를 압축하여 전체헤더패킷 또는/및 압축헤더패킷으로 변환하는 헤더압축장치와, 이를 제어하는 헤더압축제어장치와, 상기 압축된 전체헤더패킷 또는/및 압축헤더패킷을 하위계층으로 전달하는 데이터 전송장치가 구성되며; 링크제어계층은 상기 헤더압축담당계층으로부터 전달 받은 데이터를 전송제어장치 제어에 따라 저장하거나 수신측으로 전송하는 버퍼및 전송장치와, 수신측으로 전송된 데이터 중 전송에 실패한 데이터를 판별하여 전송실패정보를 상위계층에 전달하는 전송실패판별장치;로 구성되는 것을 특징으로 하는 패킷데이터 전송장치.
KR1020010074774A 2001-11-24 2001-11-24 패킷의 헤더압축을 지원하는 통신 시스템에서전체헤더패킷과 압축헤더패킷의 전송 제어 장치와 방법 KR100765122B1 (ko)

Priority Applications (21)

Application Number Priority Date Filing Date Title
KR1020010074774A KR100765122B1 (ko) 2001-11-24 2001-11-24 패킷의 헤더압축을 지원하는 통신 시스템에서전체헤더패킷과 압축헤더패킷의 전송 제어 장치와 방법
AT02026088T ATE412299T1 (de) 2001-11-24 2002-11-22 Verfahren zur übertragung von paketdaten in komprimierter form in einem kommunikationssystem
DE60229482T DE60229482D1 (de) 2001-11-24 2002-11-22 Verfahren zur Übertragung von Paketdaten in komprimierter Form in einem Kommunikationssystem
EP20020026088 EP1315356B1 (en) 2001-11-24 2002-11-22 Method for transmitting packet data in compressed form in a communication system
EP20080010516 EP1968277B1 (en) 2001-11-24 2002-11-22 Method for transmitting packet data in compressed form in a communication system
DE60239500T DE60239500D1 (de) 2001-11-24 2002-11-22 Verfahren zur Übertragung von Paketdaten in komprimierter Form in einem Kommunikationssystem
AT08010516T ATE502472T1 (de) 2001-11-24 2002-11-22 Verfahren zur übertragung von paketdaten in komprimierter form in einem kommunikationssystem
MXPA04006224A MXPA04006224A (es) 2001-11-24 2002-11-23 Transmision selectiva de paquetes de cabecera completos o comprimidos.
PCT/KR2002/002199 WO2003047189A1 (en) 2001-11-24 2002-11-23 Selectively transmitting full or compressed header packets
UAA200600834A UA82886C2 (en) 2001-11-24 2002-11-23 Method for transmission data packages and a transmitter for transmission data packages
AU2002353634A AU2002353634B2 (en) 2001-11-24 2002-11-23 Selectively transmitting full or compressed header packets
RU2004119304A RU2303858C2 (ru) 2001-11-24 2002-11-23 Способ передачи пакетных данных в системе связи
JP2002341556A JP4309118B2 (ja) 2001-11-24 2002-11-25 通信システムのパケットデータ伝送方法
US10/303,059 US7486699B2 (en) 2001-11-24 2002-11-25 Method for transmitting packet data in communication system
ZA2004/04748A ZA200404748B (en) 2001-11-24 2004-06-15 Method for transmitting packet data in communication system
MA27746A MA27160A1 (fr) 2001-11-24 2004-06-24 Procede servant a transmettre des paquets de donnees dans un systeme de communication
AU2006201242A AU2006201242B2 (en) 2001-11-24 2006-03-24 Method for transmitting packet data in communication system
US11/723,171 US7656902B2 (en) 2001-11-24 2007-03-16 Method for transmitting packet data in communication system
JP2008190345A JP4808749B2 (ja) 2001-11-24 2008-07-23 通信システムのパケットデータ伝送方法
US12/343,766 US7623549B2 (en) 2001-11-24 2008-12-24 Method for transmitting packet data in communication system
US12/656,338 US8351376B2 (en) 2001-11-24 2010-01-26 Method for transmitting packet data in communication system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020010074774A KR100765122B1 (ko) 2001-11-24 2001-11-24 패킷의 헤더압축을 지원하는 통신 시스템에서전체헤더패킷과 압축헤더패킷의 전송 제어 장치와 방법

Publications (2)

Publication Number Publication Date
KR20030043529A true KR20030043529A (ko) 2003-06-02
KR100765122B1 KR100765122B1 (ko) 2007-10-11

Family

ID=29571945

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020010074774A KR100765122B1 (ko) 2001-11-24 2001-11-24 패킷의 헤더압축을 지원하는 통신 시스템에서전체헤더패킷과 압축헤더패킷의 전송 제어 장치와 방법

Country Status (1)

Country Link
KR (1) KR100765122B1 (ko)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100690845B1 (ko) * 2005-09-30 2007-03-09 엘지전자 주식회사 Ｔｃｐ/ｉｐ 프로토콜을 지원하는 이동 통신 망에서데이터를 효율적으로 송수신하기 위한 방법
KR100774856B1 (ko) * 2002-09-13 2007-11-08 루센트 테크놀러지스 인크 제어 메시지를 사용한 데이터 통신 방법
KR20200080096A (ko) * 2018-12-26 2020-07-06 부산대학교 산학협력단 산업 ＩｏＴ 무선 센서 네트워크의 데이터 패킷 큐 관리 장치 및 방법

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3730835B2 (ja) * 2000-03-03 2006-01-05 株式会社エヌ・ティ・ティ・ドコモ パケット伝送方法、中継装置およびデータ端末

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100774856B1 (ko) * 2002-09-13 2007-11-08 루센트 테크놀러지스 인크 제어 메시지를 사용한 데이터 통신 방법
KR100690845B1 (ko) * 2005-09-30 2007-03-09 엘지전자 주식회사 Ｔｃｐ/ｉｐ 프로토콜을 지원하는 이동 통신 망에서데이터를 효율적으로 송수신하기 위한 방법
KR20200080096A (ko) * 2018-12-26 2020-07-06 부산대학교 산학협력단 산업 ＩｏＴ 무선 센서 네트워크의 데이터 패킷 큐 관리 장치 및 방법

Also Published As

Publication number Publication date
KR100765122B1 (ko) 2007-10-11

Similar Documents

Publication Publication Date Title
JP4808749B2 (ja) 通信システムのパケットデータ伝送方法
USRE47719E1 (en) Relocating context information in header compression
KR100883063B1 (ko) 문맥 재할당 방법
EP1329078B1 (en) Defining header field compression for data packet connection
KR100896484B1 (ko) 이동통신시스템에서 데이터 전송 무선통신방법 및 무선통신장치
US6967964B1 (en) Context identification using header compression key at link layer
US8848684B2 (en) Bi-directional packet data transmission system and method
EP1362446B1 (en) Transfer of ip data in communications system, using several logical connections for compressed fields on the basis of different contexts
AU2005200565B2 (en) Method of resuming header decompression in a multimedia broadcast/multicast service system
RU2316906C2 (ru) Способ передачи пакетных данных в системе связи
KR100765122B1 (ko) 패킷의 헤더압축을 지원하는 통신 시스템에서전체헤더패킷과 압축헤더패킷의 전송 제어 장치와 방법
KR100981823B1 (ko) 비대칭 양방향 패킷데이터 송수신 방법 및 시스템

Legal Events

Date Code Title Description
N231 Notification of change of applicant
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: 20120926

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20130924

Year of fee payment: 7

FPAY Annual fee payment

Payment date: 20140924

Year of fee payment: 8

FPAY Annual fee payment

Payment date: 20150924

Year of fee payment: 9

FPAY Annual fee payment

Payment date: 20160923

Year of fee payment: 10