KR101030469B1

KR101030469B1 - 시그널링 압축/압축 해제

Info

Publication number: KR101030469B1
Application number: KR1020077029212A
Authority: KR
Inventors: 지강 리우; 사미 주티라; 익카 페소넨
Original assignee: 스파이더 네비게이션즈 엘.엘.씨.
Priority date: 2005-05-17
Filing date: 2006-05-16
Publication date: 2011-04-25
Also published as: WO2006123221A1; CN101248642B; EP1900174B1; JP2008541643A; EP1900174A1; CN101248642A; US20060262812A1; US7765325B2; KR20080014041A

Abstract

본 발명은 패킷 데이터 망에서 신호 메시지를 압축하고 압축 해제하는 방법에 관한 것이다. 매개변수 정보는 패킷 데이터 망의 프로토콜 메시지의 헤더 부(header portion)에 들어있다. 그 매개변수 정보는 압축 메카니즘 또는 압축 해제 메카니즘 중에서 최소한 어느 하나의 처리 세목을 서술한다. 또한 그 매개변수 정보는 프로토콜 메시지와 함께, 패킷 데이터 망을 통하여, 패킷 데이터 망의 압축 기능부 또는 압축 해제 기능부에 전송된다. 그 다음엔, 그 매개변수 정보에 따라, 압축 기능부에 있는 압축 메카니즘 또는 압축 해제 기능부에 있는 압축 해제 메카니즘이 설정된다. 따라서, 매개변수 정보를 직접 이용함으로써, 첫 번째 메시지 또는 첫 번째로부터 몇몇 메시지들은 더 나은 방법으로 압축될 수 있다.

프로토콜, 압축, 압축 해제, 신호 압축, 신호 압축 해제, 사용자 장비, 외부 프록시

Description

시그널링 압축/압축 해제{SIGNALLING COMPRESSION/DECOMPRESSION}

본 발명은 패킷 데이터 네트워크(network : 이하, '네트워크' 또는 '망' 이라함)에서 신호 메시지(signaling message)를 압축하거나 압축 해제하는 방법 및 장치에 관한 것이다.

멀티미디어 통신에 사용되는, 세션 개시 프로토콜 (Session Initiation Protocol (SIP)) 또는 실시간 스트리밍 프로토콜 (Real-Time Streaming Protocol (RTSP))과 같은 여러 어플리케이션 프로토콜은, 광대역폭을 갖는 링크들에 이용되기 위하여 텍스트-기반으로 처리된다. 결과적으로, 이들 메시지들은 사이즈에 관하여 최적화되어 있지 않다. 예를 들어, 일반적인 SIP 메시지들은 수백 바이트로부터 2천 바이트까지 또는 그 이상의 크기를 갖는다. 인터넷 기술 표준화위원회(Internet Engineering Task Force(IETF))에서는, RFC 3261(Request for Comment 3261)에 SIP를 정의해 놓았다. 또한, SIP는 종단간 멀티미디어 세션들(end-to-end multimedia sessions)을 설정하고, 처리하며, 해제하기 위하여 사용되는(또는, 다른 프로토콜들 사이에서 사용되는) 소정의 응용-계층 프로토콜(application-layer protocol)이기도 하다. 셀룰러 통신망들(cellular networks)의 일부인 무선 전화기들에서 이들 프로토콜들을 계획대로 사용하는 경우, 메시지의 크기가 크다는 문제가 있다. 저속 인터넷 프로토콜 연결성(low-rate Internet Protocol connectivity)으로 인하여, 전송 지연이 중요한 의미를 갖는다. 재전송(retransmissions)과 몇몇 플로우(flow)에서 요구되는 메시지들의 다양성을 고려하면, 적어도 호 설정(call setup)과 피처 호출(feature invocation)은 부정적인 영향을 받는다.

이러한 문제점을 해결하기 위하여, 신호 압축 구조(Signaling Compression (SigComp) architecture)가 정의되었고, 이를 통하여 응용(또는, 어플리케이션) 메시지들이 강건한 무손실 압축기법(robust lossless compression)으로 처리된다. 개방형 시스템간 상호접속(Open System Interconnection model : OSI) 모델 관점에서는, 상기 신호압축(SigComp) 구조는 전송 계층(transport layer)을 강화시킨 것으로 해석될 수 있다. 따라서, SigComp는 상위 응용 계층들(higher layer applications)을 통하여 메시지를 전송하고 압축하게 한다. SigComp는 인터넷 기술표준화위원회(IETF)에서 표준화된 프로토콜로서, 응용-계층 프로토콜 메시지들을 압축한다. 특히, 이러한 기술은 SIP 메시지들을 압축하기 위하여 개발되었다. SIP 메시지들은 세션 설정 및 메시징(messaging)과 같은 여러 어플리케이션들에서 사용된다. SigComp의 주요 목적은 SIP 메시지들의 크기를 줄이는 것이고, 그에 따라 SIP 메시지들은 제한된 대역폭을 갖는 링크들(예를 들어, 셀룰러 통신망)을 통하여 짧은 대기 시간(low latency) 내에 전송될 수 있다. 신호압축(SigComp)을 하지 않으면, 전송 대기(transmission latency)에 의하여 종단 사용자들(end users)이 받아들일 수 없을 정도로 호 설정 시간이 길어질 것이다. SigComp에 대한 상세한 설명은, IETF에서 정의한 RFC들 즉, RFC 3320, RFC 3321, RFC 3322, RFC 3485, 및 RFC 3486에 규정되어 있다.

이동 통신에서의 그 유용성으로 인해, 3GPP(3rd Generation Partnership Project)에서는, 적어도 SIP 메시지들을 압축하기 위해서라도 SigComp의 사용을 권고하였다. 따라서 미래의 3세대 이동통신 단말기는 SigComp를 지원해야만 한다.

SigComp 구조의 전송측(transmitting side)은 압축기-디스패처(compressor dispatcher), 하나 또는 그 이상의 압축기(compressors), 및 상태 핸들러(state handler)를 구비한다. 압축기-디스패처는 어플리케이션으로부터의 인터페이스 역할을 수행한다. 어플리케이션은 어플리케이션 메시지와 구획 식별자(compartment identifier; 예를 들어, 메시지들을 어플리케이션별로 특정한 그룹으로 만들기 위하여 사용되는 식별자)를 압축기-디스패처에게 공급한다. 압축기-디스패처는 특정 압축기를 활성시킨다. 이는 전송될 SigComp 메시지를 원격 종단점(endpoint)에 되돌려 보낸다. 상태 핸들러는 상태정보를 저장하고 검색한다. 이러한 상태정보는 메시지 단위로(per-message base) 데이터를 업로드하지 않도록 SigComp 메시지들 사이에 저장된다.

SigComp 구조의 수신측은 압축 해제기-디스패처(decompressor-dispatcher), 범용 압축 해제 가상머신(Universal Decompressor Virtual Machine : UDVM))(압축 해제기능을 수행하는 가상머신), 및 상태 핸들러를 구비한다. 압축 해제기-디스패처는 어플리케이션 쪽으로의 인터페이스 역할을 수행한다. 압축 해제기-디스패처는 전송 계층으로터 SigComp 메시지를 수신하고, SigComp 메시지들을 압축 해제하는 UDVM의 인스턴스(instance)를 호출한다. 그 다음에 압축 해제기-디스패처는 그 발생된 압축 해제 메시지들을 어플리케이션으로 포워딩한다. 그 메시지를 위한 상태가 저장될 필요가 있으면, 어플리케이션은 구획 식별자를 되돌려 보낼 수 있다. 압축 해제 과정에서, 기존 상태에 액세스하거나 또는 새로운 상태를 생성하기 위해서, UDVM은 상태 핸들러를 호출할 수 있다.

SigComp 메시지들은 다른 어플리케이션 메시지들과 함께 전송 계층으로, 데이터 패킷 흐름으로서 전송된다. 여기서, 다른 어플리케이션 메시지들은 비압축 SIP 메시지와 RTSP 메시지를 그 예로 들 수 있다. 상기 SigComp 메시지들은 자신의 5 비트 구분문자들(delimiters)로 식별된다. 즉, 예를 들어, 전송제어프로토콜(Transmit Control Protocol : TCP)에 따른 스트리밍-기반 전송(transport)인 경우, 각 5비트 구분문자는 11111 비트로 시작하여 0xFFFF 비트로 끝난다. 그러나 종료 표시(end-marking)는, 예를 들어, 사용자 데이터그램 프로토콜(User Datagram Protocol)에 따른, 메시지-기반 전송에서는 필요하지 않다. 전송 계층 데이터 스트림은 압축 해제기-디스패처로 전송되는바, 이는 압축 해제을 위한 SigComp 메시지들을 식별하기 위해서 그리고 SIP 스택 또는 RTSP와 같은 특정 어플리케이션 클라이언트에게 비-신호압축 (non-SigComp) 메시지를 전달하기 위해서 정렬되어야만 한다.

그러나 초기 요청들(requests)은 압축되어 있지 않다. 왜냐하면, RFC　3486에 따르면, 다음 홉 URI(next hop URI)가, 매개변수 ";comp=SigComp" 를 포함할 때까지는 압축이 시작되지 않으며, 그리고 외부 프록시(outbound proxy)의 SIP-URI는 상기 매개변수를 포함하지 않기 때문이다. 프록시 주소는, 초기 등록 절차를 수행하는 동안에 전송 장치에 의해서 알려지고 그 후에는 변화되지 않는다.

SigComp는, 버전 숫자와 메모리 용량과 같은, 몇몇 매개변수들(parameters)을 정의한다. 이들 몇몇 매개변수들은 종단점에 의해 지원된다. 메시지 전송기와 메시지 수신기 사이에서 SigComp가 작동하기 위해서는, 전송기와 수신기는 매개변수들의 값들이 일치해야만 한다. 현재의 접근법은 SigComp 수신기가 SigComp 매개변수들의 최소값들을 지원해야만 한다는 것인바, 이들은 각각의 응용 프로토콜에 대해 정의된다. 여기서, 응용 프로토콜은 SIP를 예로 들 수 있다. 수신기는 최소값보다 큰 값을 제공할 수도 있다. 이 경우, 수신기는 전송기로 되돌려 보낸, SigComp 피드백 메시지 내에 상기 매개변수 값들을 알릴 수 있으며, 이러한 기술은, 예를 들어, 미국 특허출원 공개번호 US2005/0089327A1에 개시되어 있다. 그러나 이러한 종래 기술은 다음과 같은 문제점을 가지고 있다.

먼저, SigComp는 그 속도가 충분히 빠르지 않다. 전송기가 첫번째 메시지를 전송할 때, 수신기가 새로운 버전의 SigComp를 지원하는지 또는 특정된 최소 용량보다 더 큰 용량을 가지고 있는지를 알고 있는 것이 바람직하다. 물론, 전송기는 수신기가 보내는 SigComp 피드백 메시지를 기다릴 수 있다. 그러나 이러한 상황은 첫번째 메시지가 최적으로 압축될 수 없음을 의미한다. 이러한 문제점을 더욱 심각하게 하는 만드는 것으로, 소정의 메시지가 반대 방향으로 진행하기 전에, 전송기가 하나 이상의 메시지를 전송해야만 하는 경우가 있을 수 있다. 이런 경우는 다수의 메시지들(상기 첫번째 메시지뿐만 아니라)이 최적으로 압축될 수 없음을 의미한다.

둘째, SigComp는 구현하기가 복잡하다. 현재의 SigComp 알림 접근법(Sigcomp announcement approach)의 경우, 후속 메시지들을 위한 여분의 용량을 이용하기 위하여, 첫번째 메시지 이후에 "절환(switch)"(예를 들어, SigComp 버전 1으로부터 SigComp 버전 2로 또는 작은 메모리 버퍼로부터 큰 메모리 버퍼로)을 수행하기 위한 구현예가 요구될 것이다. 그러나 이러한 "절환" 은 그 구현을 더욱 복잡하게 만든다.

셋째, SigComp는, SigComp가 한쪽 신호 방향으로만 실시되는 비대칭 상황에서는 작용하지 않는다. 왜냐하면 전술한 알림 과정(announcement)은 SigComp 메시지의 일부로서 실행되어야만 하기 때문이다. 따라서, SigComp가 다른 방향으로 적용되지 않는다면, 그 어떤 SigComp 피드백(SigComp feedback)도 전송기로 되돌려 질 수 없다. 이와 관련하여, 몇몇 무선 기술들은 비대칭이라는 점(예컨대, 업링크에서는 작은 대역폭을 갖고, 다운링크에서는 큰 대역폭을 갖음)을 주목해야 한다. 이러한 경우, 업링크를 통해서 전송되는 SIP 메시지만 SigComp에 의해서 압축될 필요가 있다.

넷째, SigComp에서, 압축은 어떠한 압축 알고리즘에 의해서도 실행된다. RFC 3220의 기본 의도는, 사용된 압축 알고리즘에 관계없이 압축 해제과정은 항상 가능해야만 한다는 것이다. 압축 해제과정은 가상머신을 사용하여 실행되고, 그 가상머신은, 압축과정을 수행하는 종단점이 공급하는 바이트코드(bytecode)를 이용한다. 그러나 바이트코드는 크기가 수백 바이트이기 때문에, 무선 인터페이스(air interface)를 통하여 바이트코드를 전송하는 것은 압축율(compression ratio)을 떨어뜨린다. 압축 세션의 수명(RFC 3320에서는 구획 수명(compartment life time)) 동안에, 매우 적은 개수의 메시지들(50개 미만)이 압축되는 경우가 종종 발생한다. 따라서, SigComp를 이용하는 것은, 전송된 바이트들의 전체 크기를, 압축이 없는 경우보다 실제적으로 더 크게 만들 수도 있다. 양쪽 종단점들이 압축 알고리즘을 자유롭게 선택할 수도 있기 때문에, 바이트코드는 통상적으로 양쪽 방향으로 전송되는 점에 주목해야 한다. 최근에, 업링크와 다운링크를 통해서 바이트코드를 전송하려면, 750 바이트의 추가적인 페이로드(payload)를 각각 필요로 한다.

또한, 네트워크는 단말기 장치가 압축시에 어떤 알고리즘을 이용할지에 대해서는 영향을 미칠 수 없다. 속도가 매우 느리거나 또는 비효율적인 알고리즘이 사용될 수도 있다. 또는, 효율적인 알고리즘이 이용될 수 있지만, 이러한 경우에는 처리하는데 많은 시간을 필요로 하고 그에 따라 망(또는, 네트워크)의 서비스를 이용하는 사용자의 수가 제한된다.

더 나아가, 일반적으로 각각의 단말기는 항상 같은 바이트코드를 사용한다. 심지어 제조사가 동일한 여러 단말기들의 경우에는 아주 똑같은 바이트코드를 사용하는 것이 일반적이다. 따라서, 동일한 바이트코드가 무선-인터페이스를 통하여 시간당 여러 차례 전송되며, 이는 전체 용량을 줄어들게 하고 압축의 이점을 감소시킨다.

망에서 일어나는 또 하나의 문제는, 바이트코드가 여러 단말기들로부터 수신될 때, 언제나 똑같은 바이트코드들에 대해서 상태 식별자 (state-id)를 얻기 위해서, 네트워크는 SHA-1 값을 계산해야만 할 수도 있다는 점이다. 이러한 과정은 불필요한 프로세싱 부하를 네트워크 서버가 부담하도록 하며, 네트워크가 서비스 할 수 있는 사용자의 수를 실제로 제한한다.

다른 한편으로, 네트워크가 일 세트의 바이트코드들(bytecodes)을 저장한다면, 이러한 점은 UDVM 구현을 최적화할 수 있으며 따라서, 상기 저장된 바이트코드들은 매우 효율적으로 처리될 수 있다. 예를 들어, 소정의 바이트코드가 LZ77 알고리즘을 이용하여 압축 해제된다는 사실이 알려져 있다면, 그 바이트코드를 위한 네트워크 구현은 다음과 같은 방식으로 이루어질 수 있다. 즉, 가상 머신과 바이트코드는 전혀 이용되지 않지만, 더 효율적인 표준화된 방법을 이용하여 압축 해제과정이 수행되는 방식으로 그 바이트코드를 위한 네트워크 구현이 이루어질 수 있다. 여기서, 상기 표준화된 방법들로는, 소정의 범용 프로그래밍 언어들로 쓰여진 압축 해제 루틴(decompression routine)을 예로 들 수 있다. 따라서, 가상 머신에서 바이트코드를 이용하는 것과 비교하여, 하나의 서버가 관리하는 클라이언트의 수는 훨씬 많아질 수 있다.

본 발명의 목적은, 전술한 바와 같은 종래의 문제점들을 적어도 경감하기 위하여, 더 효과적인 신호압축 방법을 제공하는 데에 있다.

상기와 같은 본 발명의 목적은, 패킷 데이터 망에서 신호 메시지(signaling message)를 압축하거나 또는 압축 해제하는 방법에 의하여 달성되는바, 상기 방법은 다음과 단계들을 포함한다.

- 압축 메카니즘 또는 압축 해제 메카니즘에 대한 최소한 하나의 처리 세목(processing detail)을 서술하는 매개변수 정보(parameter information)를 상기 패킷 데이터 망의 프로토콜 메시지의 헤더부(header portion)에 제공하는 단계;

- 상기 패킷 데이터 망을 통하여, 상기 프로토콜 메시지를 상기 패킷 데이터 망의 압축 기능부(compresssion function) 또는 압축 해제 기능부(decompression function)에 포워딩하는 단계; 및

- 상기 매개변수 정보에 따라 상기 압축 기능부 또는 압축 해제 기능부에서 상기 압축 메카니즘 또는 압축 해제 메카니즘을 설정하는 단계.

또한, 상기와 같은 본 발명의 목적은, 패킷 데이터 망에서 신호 메시지를 처리하는 장치에 의하여 달성되는바, 상기 장치는 다음의 것들을 포함한다.

- 상기 패킷 데이터 망으로부터 수신한 프로토콜 메시지의 헤더부로부터, 압축 메카니즘 또는 압축 해제 메카니즘에 대한 최소한 하나의 처리 세목(processing detail)을 서술하는 매개변수 정보를 추출하는 수단; 및

- 상기 추출된 매개변수 정보에 따라, 상기 장치에 제공되고, 상기 신호 메시지를 압축 또는 압축 해제하기 위하여 이용되는 압축 기능부 또는 압축 해제 기능부를 설정하는 수단.

아울러, 상기와 같은 본 발명의 목적은, 패킷 데이터 망으로부터 전송된 신호 메시지를 처리하는 장치에 의하여 달성되는바, 상기 장치는 다음의 것들을 포함한다.

- 상기 패킷 데이터 망의 프로토콜 메시지의 헤더부에, 압축 메카니즘 또는 압축 해제 메카니즘에 대한 최소한 하나의 처리 세목(processing detail)을 서술하는 매개변수 정보를 부가하는 수단; 및

- 상기 부가된 매개변수 정보를 갖는 상기 프로토콜 메시지를 상기 패킷 데이터 망으로 전송하는 수단.

예컨대, SIP 레벨에서, 압축 매개변수 정보 또는 압축 해제 매개변수 정보를 프로토콜 메시지의 헤더부에 의해서 표시하는 것이 제안된다. 따라서, 첫 번째 메시지를 전송하기 전에, 전송기(transmitter unit)는 수신기의 압축 매개변수 값들을 결정할 수 있으며 또는 수신기(receiver unit)는 어떠한 추가적인 전용 신호(dedicated signalling) 없이도 압축 해제 매개변수 값들을 직접 결정할 수 있다.

그에 따라, 첫 번째 메시지 또는 처음 몇개의 메시지들이 더욱 양호하게 압축될 수 있다. 게다가, 압축 구현이 더욱 간단해질 수 있는바 왜냐하면, 다른 종단점의 압축 매개변수 정보(예컨대, 버전 정보 또는 용량 정보)를 학습한 후에, 절환(switch)할 필요가 없기 때문이다.

또 다른 이점으로는, 신호압축이 아주 간단하고, 또한 한 쪽 방향으로만 이용될 수 있을 뿐만 아니라, 예를 들어, RFC 3486와 같은 기존의 표준규격과 상호 운용될 수 있다는 것이다.

게다가, 알려진 용량 정보(advertised capability information)는 아마 이미 알려진 바이트코드들이 널리 알려질 수 있도록 확장될 수 있다. 이는 협상과정(negotiation phase)에서 압축율을 개선시키고 업링크 방향을 위한 압축 알고리즘도 선택될 수 있게 한다. 아울러, 가상 머신을 사용하지 않고 또한 바이트코드 없이 압축 해제할 수 있기 때문에, 더 효율적으로 압축 해제 알고리즘들을 복호할(decode) 기회가 생긴다. 결론적으로, 새롭고 더 개발된 (외부) 압축 알고리즘들을 도입할 수 있게 한다. 새로이 알려진 매개변수(new advertise parameter)가 부가된다면, 바이트코드 저장소에 대한 정보는 단방향성 압축과정의 경우에서도 수신될 수 있다.

일반적으로, 본 발명에 따른 장치가 전송단에서 구현되는 경우, 신호 메시지를 압축하여 전송하는 전송기를 구비할 수 있고, 이때 수신된 매개변수 정보는 압축 매개변수 정보가 된다. 선택적으로는, 전송단에 있는 본 발명에 따른 장치는 수신단에게 압축 해제 매개변수 정보를 전송할 수 있다.

본 발명에 따른 장치가 수신단에서 구성되는 경우, 신호 메시지를 수신하여 압축 해제하는 수신기를 구비할 수 있고, 이때 수신된 매개변수 정보는 압축 해제 매개변수 정보가 된다. 선택적으로, 수신단에 있는, 본 발명에 따른 장치는 전송단에게 압축 매개변수 정보를 전송할 수도 있다.

프로토콜 메시지는 응용-계층 프로토콜 메시지일 수 있다. 응용-계층 프로토콜 메시지는 SIP 메시지 또는 RTSP 메시지를 그 예로 들 수 있다. 매개변수 정보는 SigComp 구조의 최소한 한 개의 매개변수를 포함할 수 있다.

프로토콜 메시지는 피드백 메시지일 수 있다. 그 피드백 메시지는, 통신을 위한 초기 요청(initial request)에 따라, 상기 신호 메시지의 전송단으로 되돌려 지는 메시지이다.

게다가, 매개변수 정보는 SIP 메시지의 URI 또는 비어-헤더(Via-header) 중 최소한 어느 하나에 제공된다. 매개변수 정보는 패킷 데이터 망의 중간 서버 장치(intermediate server device)에서 URI에 부가될 수 있다. 또한, 매개변수 정보는 패킷 데이터 망의 클라이언트 장치에서 비어-헤더에 부가될 수 있다. 특히, 매개변수 정보는 압축 메카니즘의 이용을 나타내는 매개변수에, 접미어(suffix)로서 부가된다. 선택사항으로서, 매개변수 정보는 데이터 필드로서 부가될 수 있다. 여기서, 데이터 필드는 압축 메카니즘의 이용을 나타내는 매개변수와 구분된다.

예를 들어, 매개변수 정보는 매개변수 정보의 시작을 나타내는, 미리 결정된 첫 번째 문자를 구비할 수 있다. 또한, 매개변수 정보는 개별 정수 숫자가 이어지는, 최소한 하나의 문자를 구비한다. 정수 숫자는 그 최소한 하나의 문자에 의해 표시되는 매개변수의 해당 값을 나타낸다.

좀더 상세하게 설명하자면(하지만, 이에 한정되는 것은 아님), 상기 매개변수 정보는 신호 압축 버전, 상태 메모리 크기, 압축 해제 메모리 크기, 비트당 사이클 수, 및 논리적으로 가용한 상태 중에서 적어도 하나를 특정할 수 있다.

선택적으로 또는 부가적으로, 상기 매개변수 정보는 압축 기능부 또는 압축 해제 기능부에 대한 구현예의 독점적 정보(proprietary information)를 서술할 수 있다.

압축 해제 매개변수에 대한 구체적인 예로서, 매개변수 정보는 가상 압축 해제 머신(virtual decompression machine)이 사용하는, 최소한 하나의 바이트코드를 구비할 수 있다. 그 최소한 하나의 바이트코드는 패킷 데이터 망에서 널리 알려질 수 있다(can be advertised). 즉, 소정의 비어 매개변수(via parameter)로서, SIP 메시지의 비어-헤더(via-header)에 부가될 수 있다. 비어 매개변수는 바이트코드 상태 식별자(bytecode state identity)로부터 유도될 수 있다.

게다가, 상기 최소한 하나의 바이트코드가 지원되지 않는다면, 상기 최소한 하나의 바이트코드는, 프로토콜 메시지에 응답하여 전송되는 응답 메시지 내에서 변경되거나 교체될 수 있다. 이후, 상기 변경되거나 교체된 바이트코드는 다른 매개변수 명칭으로 전송된다. 선택적으로는, 상기 최소한 하나의 바이트코드는 수신단에 저장될 수 있다. 예를 들어, 최소한 하나의 바이트코드는 단말기 장치의 SIM에 저장될 수 있다. 저장과정은 최소한 하나의 바이트코드에 할당된 우선순위를 바탕으로 수행된다. 그럼으로써, 과거 바이트코드들을 삭제하기 위한 제어 과정이 더 쉽게 이루어진다.

선택적으로 또는 부가적으로, 상기 최소한 하나의 바이트코드는 세션 개시 프로토콜 등록 메시지(Session Initiation Protocol Register message)의 접속 헤더에 부가될 수 있다.

본 발명에 따른 여러 변경예들은 특허청구범위의 종속항에 기재되어 있다.

본 발명은 첨부된 도면을 참고로 실시예들을 바탕으로 설명된다.

도 1은 본 발명의 1 실시예에 따른 망 환경(network environment)을 나타낸 구성도이다.

도 2는 본 발명의 2 실시예에 따른, 비어-헤더가 변경된 예의 신호 처리 순서를 나타낸 도이다.

도 3은 본 발명의 2 실시예에 따른, 피드백 데이터의 전송 절차를 나타낸 신호 처리 순서도이다.

본 발명에 따른 최적의 실시예들은 RFC 3320에 규정된 SigComp 신호 압축 체계(scheme)에 연관되어 설명될 것이다.

RFC 3320의 3.3 절에는 5개의 SigComp 매개변수에 대하여 서술되어있다. 이들 매개변수들은 SigComp 수신기가 수신된 SigComp 메시지를 처리하는 방법과 연관된다. SigComp 동작을 성공적으로 수행하려면, SigComp 전송기는 그 수신기의 매개변수들의 값을 알고 있어야 한다. 5개의 SigComp 매개변수들은 다음과 같은 항목을 각각 규정한다. 압축 해제 메모리 크기(decompression_memory_size), 상태 메모리 크기(state_memory_size), 비트 당 사이클 수(cycles_per_bit), 압축 버전(SigComp_version), 및 지역 가용 상태 (locally available state; 0개 상태 항목 또는 그 이상 개수의 상태 항목을 포함하는 집합(set)).

도 1은 본 발명의 제 1 실시예에 따른 망 환경을 나타낸 구성도이다. 사용자 장비(user equipment : UE)(10) 또는 다른 단말기 장치(terminal device)에 제공되는 SIP 사용자 에이전트(미도시)는, 무선 접근망(radio access network)(미도시)을 통하여, 서비스 망(30)의 SIP 외부 프록시 서버(outbound proxy server)(20)(예를 들어, 제 1 홉 프록시 서버(first hop proxy server))와 SIP 메시지들을 교환하여, 인터넷과 같은 IP-기반 망(40)의 서비스에 접근한다. 여기서, SIP 외부 프록시 서버는 IP 멀티미디어 서브시스템의 프록시 호출 상태 제어기능 (Proxy Call State Control Function (PCSCF))을 예로 들 수 있다. 먼저, 사용자 장비(UE)(10)와 외부 프록시(20)는 일련의 메시지들(a sequence of messages)을 교환하고, 이러한 메시지들은 사용자 장비(10)와 외부 프록시 서버(20) 사이에서 보안 관계(security association)를 설정한다. 이러한 메시지들은 압축되지 않고 전송된다.

본 발명의 바람직한 실시예들에 따르면, SIP 레벨에서 상기 SigComp 매개변수들 중 최소한 하나의 SigComp 매개변수를 표시하기 위해서, 소정의 메카니즘이 도입된다.

제 1 실시예에서, 상기 메카니즘은 아래와 같은 두 개의 요소 또는 선택사항을 갖는다.

첫째, SigComp 매개변수들은 SIP URI의 일부부분으로서 표시될 수 있다. SIP URI는, 접속될 수 있는 SIP 통신자원(예를 들어, 사용자 또는 서비스)을 식별한다. 예를 들어, SIP 클라이언트는, SIP URI에 의해 식별되는 SIP 서버에게로 SIP 요청들을 전송한다. SIP URI에 SigComp 매개변수들을 포함시킴으로써, URI에 의해서 식별되는 SIP 엔터티(entity)의 SigComp 능력(capabilities)이 자동적으로 선언된다. 이는, 전송기 자신이 보낸 바로 그 첫번째 SIP 메시지에게, 가장 최적의 방법으로 SigComp가 적용되게 한다.

둘째, SigComp 매개변수들은 비어-헤더 필드(Via-header field)의 일부분으로서 표시될 수 있다. 비어-헤더 필드는 SIP 요청(SIP request)에서 운반된다. 이는, 요청에 대하여 SIP 응답 메시지가 어디로 전송되어야 할지를 나타낸다. 비어-헤더 필드에 SigComp 매개변수들을 포함시킴으로써, SIP 요청 메시지를 전송하는 전송기는 자신의 SigComp 용량(capacity)을 그 짝(peer)에게 고지할 수 있다. 따라서, 상기 짝(peer)은 첫번째 응답 메시지를 되돌려 보낼 때, 최적의 방법으로 SigComp를 적용할 수 있다.

주목해야 할 것은 상기 두가지 선택사항들은 그 어느 하나가 사용될 수도 있으며 또는 함께 사용될 수도 있다는 점이다. 예를 들어, 제 1 구성요소는 서버(프록시 서버)가 자신의 URI 내에서 SigComp 매개변수들을 고지하는 것을 허용할 수 있으며, 따라서 클라이언트는 서버로 전송된 첫번째 요청 메시지를 최적의 SigComp 구성으로 압축할 수 있다. 제 2 구성요소는 동일한 클라이언트가 그 자신의 SigComp 용량(미리 서버가 알 수 없음)을 그 요청 메시지의 비어-헤더 필드에서 선언하는데 유용하게 쓰인다. 서버가 상기 요청 메시지에 대한 응답 메시지를 되돌려 보내는 경우, 상기 서버는 클라이언트의 SigComp 용량에 따라 그 응답 메시지를 미리 압축할 수 있다.

SigComp 매개변수들은 다양한 형식들(formats)로 구현될 수 있지만, 이들 형식은 기본적으로 아래 두 가지의 선택사항(option)으로 나뉠 수 있다.

선택사항 1:

URI와 비어-헤더 필드 모두에 대해서는, RFC 3486에 규정되어 있듯이, SigComp 매개변수들은 접미어(suffix)로서, "comp=sigcomp"에 부가된다. 예를 들어:

sip:alice@Atlanta.com;comp=sigcomp_VnSnDnCn_Lx

via:SIP/2.0/UDP

pc33.Atlanta.com;branch=z9hG4bK776asdhds;comp=sigcomp_VnSnDnCn_Lx

상기 선택사항1의 형식을 설명하면 다음과 같다.

- 문자열 ("sigcomp") 다음의 첫 번째 밑줄 문자("_")는 SigComp 매개변수들의 시작을 나타낸다.

- 문자 ("V," "S," "D," "C," 및 "L")는, SigComp의 버전(SigComp_version), 상태 메모리 크기 (state_memory_size), 압축 해제 메모리 크기(decompression_memory_size), 비트 당 사이클 수(cycles_per_bit), 및 지역 가용 상태(locally available state)를 각각 나타낸다.

- 문자("V") 다음에는 SigComp 버전(SigComp_version)을 나타태는 정수가 이어진다. 그 정수는 한 자리수 이상의 숫자가 될 수 있다. 예를 들어, "V1"은 SigComp 버전이 1임을 나타내고 (SigComp_verson=1), "V10"은 SigComp 버전이 10 임을 나타낸다(SigComp=10).

- 마찬가지로, 각각의 문자들 ("D," "S," 및 "C") 뒤에는 해당하는 값을 나타내는 정수(한 자리수 이상의 숫자)가 이어진다. 그러나 그 정수의 문자 그대로의 의미는 다음과 같이 해석되어야 하고, 이는, RFC 3320의 3.3.1 절에 규정된 바와 같이, 가능한 값들로 이루어진 상위집합(superset)을 포함한다.

* n을 문자 그대로의 정수라고 정한다.

* "S"다음에 n이 0인 경우, state_memory_size=0 바이트; 그렇지 않으면,

state_memory_size= 2⁽¹⁰⁺ⁿ⁾ 바이트

* "D" 다음에는 상기와 같음, 단 n은 0이 될 수 없음(왜냐하면 0은 유효한 decompression_memory_size가 아니기 때문임),

* "C" 다음에: cycles_per_bit=2ⁿ

- 문자들("V," "S," "D," 및 "C")은 임의의 순서로 배열될 수 있다. 예를 들어, "V1S2D3C4" 와 "V1D3C4S2" 는 같은 의미이며, 이 둘의 매개변수 문자 배열은 다음과 같은 의미를 갖는다: SigComp_version=1, state_memory_size=4KB, decompression_memory_size=8KB, 및 cycles_per_bit=16. 또한, 해당 매개변수들이 SigComp 관련 사양서(specification)에 규정된 디폴트값을 갖는 경우에, 이들 매개변수 문자들의 전부 또는 그 일부가 생략될 수 있다. 예를 들어, 매개변수 문자 배열이 "S3"이면, 상태 메모리 크기는 8 KB(state_memory_size=8KB)이고, 다른 SigComp 매개변수 값들은 모두 디폴트값과 같다는 것을 의미한다.

- 문자 ("L") 다음의 문자열은 지역 가용 상태의 상태 식별자(전체 상태 식별자 또는 부분 상태 식별자)를 16진수로 나타낸다는 의미이다. 예를 들어, "L4B7ECDE7DA49"는 다음과 같은 의미를 갖는다: 즉, SIP 엔터티는 16진수 0x4B7ECDE7DA49로서, 부분 상태 식별자(최상위 6바이트)를 가지고 있는 지역 가용 상태를 갖는다. RFC 3320의 3.3.3 절 및 7.2절에 상세하게 설명되어 있다. 이러한 규정은, 전송기가 상태의 내용을 알고 있다면, 전송기가 상태 항목(state item)을 이용할 수 있게 하기 위함이다.

- 비고: "_Lx"가 0이거나 여러 값을 갖는 경우가 있을 수 있다. 특히, "_Lx"가 생략되면, SIP 엔터티가 SigComp 표준에 서술된 기본값들 이외에 어떠한 지역 가용 상태들을 가지지 않는다는 것을 의미한다.

- 비고: "D"와 "C" (결합된 매개변수 명칭들(compacted parameter names))는 앞서 설명한 예에서"Lx" 에서도 나타날 수 있기 때문에, "Lx" 앞의 밑줄 문자 ("_")는 파싱하기(parsing) 위하여 필요하다.

선택사항 2:

SigComp 매개변수들은 매개변수("comp=" )와 구분되는 데이터 필드로서 부가 된다. 예를 들어:

sip:alice@Atlanta.com;comp=sigcomp;comp-param=VnSnDnCn_Lx

via:SIP/2.0/UDP

pc33.Atlanta.com;branch=z9hG4bK776asdhds;comp=sigcomp;comp-

param=VnSnDnCn_Lx

'분리(separation)'를 제외하고, SigComp 매개변수 문자열의 형식은 선택사항 1에 있는 것과 똑같다. 선택사항 2의 장점은 RFC 3486 과의 상호운용성 (interoperability)에 있다. 즉, 본 발명을 구현하는 SIP 종단점(SIP 종단점 1)이, RFC 3486만을 구현하는 다른 SIP 종단점(SIP 종단점 2)에 상기 데이터 필드를 전송하는 경우, 상기 SIP 종단점 2는 "comp=sigcomp" 필드에 근거하여 상기 SIP 종단점 1이 SigComp를 지원하는 것으로 여전히 결론을 내릴 수 있다. 이후, "comp-param=" 필드는 수신기에 의해 무시될 것이다. 내릴 수 있는 오직 한 가지 결론은, 수신기는 전송기의 여분의 용량(기본값보다 큼)을 알 수 없다는 것이고, 어쨋든 이는 제안된 개량이 없는 경우가 된다. 또한, 선택사항 2(RFC 3486과 조합)는 SigComp 이외에 압축 특성들을 나타내는, 포괄적인 기본 틀로서 이용될 수 있다. 즉, RFC 3486으로서 "comp=" 필드는 압축 알고리즘을 나타내지만, 반면에 제안된 "comp-param"는 그 알고리즘의 추가 정보(예를 들어, 압축 매개변수들)를 표시할 수 있다. 선택사항 2는 SIP URI 및 비어-헤더에 추가 필드를 필요로 한다. 이는, 선택사항 1과 비교할 때, 더 많은 바이트(예를 들어, "comp-param=")가 필요하다는 것을 의미한다. 그러나 선택사항 2에는 상호운용성과 보편성을 준다는 장점이 있다.

또한, SIP 종단점이 SigComp 정보에 대한 독점 정보(proprietary information)를 나타낼 수 있도록, 상기 메카니즘이 확장될 수 있다는 점에 주목해야 한다. 하나의 단순한 방법은 SigComp 매개변수 필드에 "_Xs"를 부가하는 것이다. 여기서, 밑줄문자("_")는 구분문자(delimiter)이고, "X"는 독점 요소 (proprietary element)를 나타내고, "s"는 독점 정보를 나르는 텍스트 문자열을 나타낸다. 수신기가 그 의미를 해석하지 못하면, 필드("X")를 무시할 수 있다.

본 발명의 제 2 실시예는 단말기 장치뿐만 아니라 네트워크 측에도 하나 이상의 바이트코드를 단순하게 저장한다는 착상(idea)과, 바이트코드들이 무선-인터페이스를 통하여 계속해서 전송되지 않도록, 이용가능한 바이트코드를 알리는 방법에 관한 것이다.

단말기 개시 압축 세션과 관련된 제 1 실시예에서, 단말기 장치는, 바이트코드(또는 바이트코드들)를 이미 알고 있다고 널리 알림으로써(advertising), 망과 함께 압축 세션(예를 들어, SIP 방법들 (REGISTER 또는 INVITE)과 함께 구획과정(compartment))을 시작하는바, 이는 압축과정을 위하여 망에 의해서 이용되기 쉽다. 그 다음에, 망이 다운링크 방향으로 압축과정을 시작할 때, 단말기 장치가 널리 알렸던 것과 똑같은 바이트코드를 사용하기 원하는 경우, 바이트코드를 업로드 할 필요가 전혀 없다.

망으로부터 바이트코드를 받으면, 단말기 장치는 또한, 영구 메모리(permanent memory)에 얼마간의 과거 바이트코드 또는 한 개의 과거 바이트코드를 교체하면서 그 수신된 바이트코드를 저장할 수 있다. 따라서, 압축 알고리즘들이 진화됨에 따라 알고리즘들을 동적으로 갱신할 수 있으며 그리고 종래 방법들의 경우와 달리, 사전에 알고리즘들을 확정하거나 일치시킬 필요가 없다.

또한, 망은, 단말기에 의해서 주로 사용되는 바이트코드(바이트코드들)를, 비압축 응답 메시지(uncompressed response) 형식으로 또는 압축 메시지 형식으로 널리 알릴 수 있다. 여기서, 비압축 응답 메시지는 단말기 장치가 자신이 알고 있는 바이트코드를 널리 알릴 때 사용되고, 압축 메시지는 회귀된 매개변수들에 지역 가용 상태들을 널리 알리는, 공지의 방법에 의해서 사용된다(상세 내용은 RFC 3320 참조). 어느 경우든, 단말기가 망이 널리 알리는 바이트코드를 사용할 것을 선택하면, 망으로 그 바이트코드를 전송할 필요가 없다.

망 개시 압축 세션과 관련된 제 2 실시예에서, 단말기 장치들로부터 새로 수신한 바이트코드들을 다루는 방법에서 여러 차이가 있을 수 있다. 공식적으로 단말기 제조자들에 의해서 정당한 것으로 인가되지 않은 몇몇 코드들을 저장하는 보안 이슈 또는 리소스 이슈가 될 수도 있기 때문에, 영구 메모리에 바이트코드들을 저장하지 않는 것이 더 안전할 지도 모른다.

제 2 실시예의 기초를 이루는 착상(idea)은 또한, 의무적인 바이트코드들(mandatory bytecodes) 기타등등 뿐만 아니라 네트워크 운영자와 단말기 제조업자들 사이에서 바이트코드들을 일치시킨다라는 개념을 지원하는데에 주목해야 한다. 단말기 장치에 있는 몇몇 바이트코드들은 메모리에 있을 수도 있는데, 이는 새로운 알고리즘들로 덮어 쓰이거나 교체될 수 없을 것이다. 의무적인 알고리즘의 경우, 특정한 몇몇 이유 때문에 네트워크는 단말기 장치가 특히 의무적인 알고리즘(그리고 그 바이트코드)만을 사용하고 다른 알고리즘들은 사용하지 않을 것을 요구할 수도 있는데, 그렇지 않은 경우에는 상기 의무적인 알고리즘을 널리 알릴 필요는 없다.

SigComp 협상 방법(negotiation method)은 RFC 3486에 서술되어 있다. 그 방법은 ;comp=sigcomp를 이용하여 SigComp 압축 해제 능력(capability of SigComp decompression)을 표시한다. 하나의 접근법은 그 능력 정보(capability information)를 확장하는 것이고, 그에 따라 이미 알고 있을 수도 있는 바이트코드들이 널리 알려질 수 있다(can be advertised).

소정의 요청 메시지가 전송되는 때, 비어:헤더 (Via: header)는, 압축 해제할 능력과 의지가 있는 경우에는 언제나, ;comp=sigcomp 매개변수를 포함한다. 이러한 상황은 아직 압축 세션이 없는 때의 경우들로 쉽게 확장될 수 있다. 이러한 경우들에 대하여, 새로운 비어-매개변수(via-parameter), <compression-bytecodes>가 부가된다. 이러한 새로운 bc-매개변수(bc-parameter)는, 예를 들어, 다음과 같은 형식이 될 수 있다:

;bc=bc_state_id_in_hexadecimal.

예를 들어, 바이트코드 상태 식별자(bytecode state id)가 0x76 0x94 0x34 0xA3,..., 0x6C 이라면, bc-매개변수는 소정의 값을 갖는다:

;bc=769434A3...6C

상태 식별자(state-id)의 길이는 20 바이트이고, 따라서 40 바이트의 16진 숫자들이 있을 수 있다. 그러나 매개변수에서 필요로 하는 최소한 최소 접근 길이(minimum access length)(바이트 단위)가 되도록, 그 길이를 줄일 수 있다. 그에 따라, 최소 접근 길이가 6 바이트인 경우, bc-매개변수는 최소한 12 개의 16진수 숫자를 필요로 한다. 우선순위에 따라, 상태 식별자들에게 1 바이트코드 이상의 크기를 알려주는 것 또한 가능하다 (그러나 반드시 필요하지는 않음).

이동통신 단말기와 같은 단말기 장치가 새로운 bc-매개변수를 갖는 요청 메시지를 수신하면, 그 요청 메시지는 목록(알고 있는 경우)으로부터 바이트코드를 사용해야만 하고 다른 바이트코드를 선택할 필요가 없다. 이렇게 함으로써, 네트워크는 서버들의 부하가 평형을 이루게 할 수 있는데, 이는 양쪽 방향(업링크 방향과 다운링크 방향)에 사용되는 압축 알고리즘을 네트워크가 선택할 수 있기 때문이다.

bc-매개변수가 바이트코드의 빈 목록을 포함한다면, 이는 그 bc-매개변수를 전송했던 전송 엔터티에 의해 저장되거나 또는 선호되는 어떠한 바이트코드도 없음을 의미한다. 그러나 전송 엔터티는 이러한 메카니즘을 알고 있으며, 자신이 알고 있거나 선호하는 바이트코드를 다른 종단이 널리 알려주기를 원한다.

bc-매개변수를 수신하면, 다른 종단이 저장된 바이트코드 메카니즘을 지원한다는 것이 알려진다. 그러면, 응답 메시지를 전송할 때, 지지된 바이트코드들이 널리 알려질 수 있도록, 응답 메시지에서 비어:헤더(via:header)를 변경할 수 있다. 그러나 소정의 다른 명칭이 그 매개변수를 위하여 사용되어야만 한다. 그렇지 않으면, 다른 종단이 비어:헤더를 단지 카피(copy)해서 되돌려 보냈는지 아닌지 또는 바이트코드 널리 알림 방법을 실제로 알고 있는지 아닌지를 구분하기가 불가능하다. 응답할 때, 수신된 bc-매개변수 내용이 드랍(drop)되거나 또는 무시될 수 있으며, 그리고 bc_resp 매개변수에 의해서 교체될 수 있다. bc_resp 매개변수는 bc-매개변수와 똑같은 방식으로 코딩된다.

지지된 바이트코드들을 제공하는 다른 방식은 압축된 메시지에서, RFC 3320에 서술된 회귀 매개변수 메카니즘(returned parameters mechanism)을 이용하는 것이다. 그러나 그 메시지가 압축되지 않았다면, 그 새로운 bc_resp 매개변수는 알려진 바이트코드(바이트코드들)을 널리 알리기 위한 오직 하나의 방식이 된다.

다시한번 설명하면, 망이 업링크 방향으로 압축 알고리즘을 선택할 수 있게 하기 위하여, 단말기 장치가 바이트코드를 알고 있지만 다른 바이트코드를 선택할 수 없는 경우에, 단말기 장치는 bc_resp 매개변수에서 널리 알려진 바이트코드들을 사용해야만 한다.

bc-매개변수를 수신하면, 다른 종단이 저장된 바이트코드 메카니즘을 지지한다는 것이 알져진다. 그러면, 응답 메시지를 전송할 때, 지지된 바이트코드들이 널리 알려질 수 있도록, 응답 메시지에서 비어-헤더를 변경할 수 있다. 그러나 소정의 다른 명칭이 그 매개변수를 위하여 사용되어야만 한다. 그렇지 않으면, 다른 종단이 비어-헤더를 카피하여 보냈는지 안 보냈는지 또는 바이트코드 널리 알림 방법을 실제로 알고 있는지 알고 있지 않는지를 구분하기가 불가능하다. 응답할 때, 수신된 bc-매개변수 내용이 줄어들거나 무시되고 매개변수bc_resp 매개변수에 의해서 교체될 수 있다. bc_resp 매개변수는 bc-매개변수와 똑같은 방식으로 코딩된다.

도2는 본 발명의 제 2 실시예에 따른, 비어 헤더가 변경된 일례의 신호 처리 순서를 나타낸 도면이다. sigcomp 버전 2가 지원됨을 알리면서, 외부 프록시 서버(20)가 이용할 것 같은 바이트코드를 널리 알리기 위해서, "comp=sigcomp; bc=e24343....; comp_param=V2"를 포함하는 비어-헤더를 갖는 요청 메시지가 도1의 사용자 장비(10)에 의해 이용된다. 외부 프록시 서버(20)의 응답 메시지에서, 비어-헤더는 "comp=sigcomp; bc_resp=..."를 구비한다. 비어 매개변수가 변경되었기 때문에, 외부 프록시 서버(20)가 그 매개변수를 정말로 이해하고 있다는 것을 사용자 장비(10)가 알게된다. 이러한 메카니즘은 응답 메시지가 압축되지 않고 전송되는 경우에 필요하다. 때때로, 모든 응답 메시지를 압축하지는 않는 것이 유용할 수도 있다. 또는 때때로 한 쪽 방향으로 압축하는 것이 유용할 수도 있다. 이러한 경우에, 망은 압축하기를 원하지 않지만 단말기가 메시지들을 압축해주기를 바란다. 같은 유형의 비어-헤더 변경(modification)은, 예를 들어, "comp_param_resp=V2"와 같은 다른 신호압축 매개변수들에게도 유용할 수 있다. 그럼으로써, 2 방식 협상(two-way-negotiation)이 간단하게 달성된다.

즉, 응답 메시지에 있는 비어-헤더의 변경은 양 방향으로 신호압축 매개변수(sigcomp parameters)들이 교환되는 것을 허용한다. 물론, SigComp 압축이 응답메시지에서 이용될 경우에, 비어-헤더를 무시하는, SigComp 매개변수는 더 이상 필요하지 않다. 즉, 그 다음에 피드백 메카니즘이 이용될 수 있기 때문이다. 사용자 장비(10)가 압축시에 사용하는 알고리즘을 변경하기 위해서, bc-헤더들은 심지어 SigCom 동안에도 여전히 이용될 수 있다. 예를 들어, 처음에 사용자 장비(10)는 DEFLATE 알고리즘을 이용할 수 있고, 잠시 후에 네트워크는 몇몇 다른 알고리즘들이 더 효과적일 거라고 인식한다. 그러면, 몇몇 다른 바이트코드를 비어-헤더에서 널리 알릴 수 있다. 양 방향으로의 압축 알고리즘에 대한 주 제어권 (master control)을 네트워크가 가질 수도 있다.

바이트코드를 저장하는 여러 방법들이 있을 수 있다. 하나의 바이트코드 또는 몇몇 바이트코드들은 단말기 메모리에 영구 저장될 수 있다(예를 들어, 의무적인 바이트코드들 또는 운영자가 선호하는 바이트코드들). 가입자 식별 모듈 (Subscriber Identify Module : SIM)) 카드는, 바이트코드가 단말기 메모리에서 제거되어서는 안됨을 알리면서, 바이트코드 id와 함께 그 바이트코드의 매개변수들(예를 들어, 길이, 최소 접근 길이 등)이 저장될 수 있는 하나의 저장 장소(storage place)가 될 수 있다. 또한 SIM 카드는 전체 바이트코드를 저장할 수 있다. 바이트코드들은, 단문 메시지 송신 서비스 내려받기(Short Messaging Service (SMS) download) 등과 같은 공지의 메카니즘을 통해서 갱신될 수 있다.

단말기 장치가 SigComp 시그널링에서 새로운 바이트코드를 수신하는 경우, 단말기 장치는 바이트코드도 단말기 메모리에 저장하는 것이 통상적이다. 따라서, 단말기 장치가 다음번에 파워 온되는 때에 그 바이트코드는 널리 알려질 수 있다. 단말기 장치는 한정된 저장 용량만을 갖고 있기 때문에, 새로운 바이트코드를 저장하려면 메모리에서 몇몇의 과거 바이트코드들을 제거해야 하고, 이러한 경우를 위하여 얼마간의 우선순위 알고리즘들이 필요하다. 또한 바이트코드는 단말기 메모리에 저장되지 않을 수 있는데, 메모리에 더 상위의 우선순위를 갖는 바이트코드들만 있을 경우가 그렇다. 상기 상위 우선순위 바이트코드들은, SIM 카드가 상위 우선순위 바이트코드들이라고 지시하는 것들, 선호 바이트코드로서 몇몇 SIP 설정에 링크된 것들 등등을 포함할 수 있다. 우선순위 메카니즘은 공지의 여러 방법들에 의해서 구현될 수 있다.

네트워크 측의 관점에서 적합한 해결법은 다음과 같다. 이동통신 단말기 제조사들이 자사 단말기들에 쓰이는 바이트코드들에 대한 정보(최소한 상태 식별자)를 제공하고, 그러면 네트워크는 그 정보를 어딘가에 영구히 저장하거나 또는 바이트코드들을 불필요하게 저장할 필요가 없는 다른 방책(strategy)을 강구할 수 있다. 단말기 제조사들의 정보를 제공하기 위하여 그리고 바이트코드들을 언제 및/또는 어떻게 저장하는지를 제공하기 위해서, 적절한 메카니즘들이 이용될 수 있다. 그러나 아마도 새로운 바이트코드들을 저장하기 위한 방책은 단말기 제조사의 방책과 다르다.

단말기 장치가 자신의 메모리에 몇몇의 바이트코드들을 저장했으면, 그 바이트코드 모두를 ;bc 또는 ;bc_resp 필드에서 널리 알리는 것은 유용하지 않다. 간단한 방책은 압축에 쓰인 마지막 바이트코드를 널리 알리는 것이다. 더 상세한 방책들은, 어떤 바이트코드가 각각의 종단점에 대해 사용되었는지를 상기하는 것을 포함하며, 또는 그 바이트코드들을 연결설정(connection settings)에 링크시키는 것을 포함한다. 한편으로는, SIM은 선호 바이트코드 등에 대한 정보를 포함할 수 있다. 또한 몇몇 바이트코드들을 널리 알릴 수 있으나 이는 조심해서 다루어야 한다. 왜냐하면, 길이가 긴 널리 알림 메시들(long advertisement messages)이 처리되는 경우에 압축율이 감소되기 때문이다.

네트워크 측의 관점에서, 등록기(registrar)는, 사용자가 현재 이용하고 있는 바이트코드에 대한 정보를 가질 수 있다. 이러한 점은 그 정보를, REGISTER 메시지에 제공된 접속 헤더(Contact: header)에 부가하는 것을 필요로 한다. 한편으로는, 네트워크는 자신이 널리 알린 바이트코드들을 선택하기 위하여 다른 메카니즘들을 가질 수도 있다. 몇몇 케이스에서, 모든 사용자들이 소정의 특정한 바이트코드들을 선택하기를 네트워크가 원하는 경우, 그 선택과정은 간단하다. 하나의 바이트코드만이 널리 알려짐으로써, 압축 해제을 위한 각 사용자의 부하량(load effect)이 훨씬 쉽게 계산된다.

지금까지 설명한 것과 같이, 신호압축 매개변수들과 저장된 바이트코드들에 대한 정보가 전송될 수 있다. 그러나 일방향의 압축의 경우에, 회귀 피드백이 비어-헤더들로 전송되는 경우가 더 유용하다.

도3은 본 발명의 제 2 실시예에 따라, 제 1 종단점 (A)(220)과 제 2 종단점 (B)(230) 사이에서 주고받는 피드백 데이터의 전송 절차를 나타낸 신호 처리 순서도이다. 일방으로만 압축이 수행되면, 피드백은 종단점 (A)(220)에 전달되지 않는다. 왜냐하면 피드백 데이터는 압축된 메시지들로 전달되기 때문이다.

도3에 나타낸 것과 같이, 종단점(A)(220)에 있는 압축기(C)는 종단점(B) (230)에 있는 UDVM에 피드백을 요청하는 sigcomp 메시지를 전송한다(단계1). UDVM은 압축 정보를 유도하고(단계2), 상태 핸들러(SH)를 통하여 종단점(B)(230)에 있는 압축기(C)를 제어한다. 그에 따라, 피드백 정보를 갖는 응답 메시지를 생성한다(단계 3과 단계 4). 비어-헤더에 피드백을 부가함으로써, 압축 효율이 증가될 수 있다. 도 3에 나타낸, 종단점(B)(230)에 있는 압축기(C)는 SigComp 메시지를 생성하지 않음으로써, 실질적으로 압축기는 아니지만, 비압축된 메시지를 전송하고, 종단점(A)(220)을 위한 컴파트먼트(compartment)와 그 종단점을 위한 피드백이 검색되면, 상기 비압축된 메시지 내의 비어-헤더는 새로운 매개변수("returned-feedback=.....;)를 포함한다(단계 5). 종단점(A)(220)의 UDVM이 상기 새로운 매개변수를 갖는 비어-헤더를 수신하면(단계 7), 매칭 컴파트먼트(matching compartment) (가능하다면)를 검색한다(단계 6). 그리고 종단점(A)(220)에 있는 상태 핸들러(SH)를 경유하여 압축기(C)로 넘어감에 따라, 종단점(A)(220)에 있는 압축기(C)에서 더 진보된 압축 알고리즘(가령, dynamic compression)을 이용하는 것이 가능해진다(단계 9).

그러나 주목해야 할 것은 한 쪽 방향 압축과정도 다음과 같은 경우에 가능하다는 것이다. 소정의 데이터를 압축하는 것이 메시지를 실질적으로 확장하는 경우, 예를 들어, 이미 압축된 데이터를 압축하는 경우, 또는 사용된 압축 알고리즘에 대해 이상적이지 않은 데이터의 경우, 또는 예컨대 압축이 너무 많은 자원을 잠식하고 그리고 일시적으로 비활성되는 무거운 부하 상황(heavy load situation) 동안. 따라서 이는 압축되지 않은, 단지 얼마간의 메시지가 될 수 있다. 그러나 피드백은 여전히 다른 종단점에 있는 압축기에 인가될 수 있다.

이러한 회귀-피드백은, "...comp_param=Fnnnn"와 같은 비어-헤더에서 sigcomp-params의 일부분이 될 수 있고, 뿐만아니라 "bytecode...comp_param=B..."를 널리 알리는 또 다른 방식이 될 수도 있다.

일반적으로, 전체 SIP 메시지 크기에 대한 효과는 최소가 되어야 한다. 대부분의 경우, 제안된 개선된 비어-헤더들은 부가될 필요가 없다. 이상적으로는, SigComp 압축이 시작되기 바로 직전에(예를 들어, 초기 REGISTER 메시지들 상에서만), 상기 헤더들이 필요하다. 따라서 제안되는 여분의 필드들은, 몇몇 예외를 제외하고는, 신호압축 협상(sigcomp negotiation)의 대부분의 메시지들에서 필요없을 수도 있다. 이러한 예외들 중 하나로서, 단말기가 사용하고 있는 압축 알고리즘의 변경을 네트워크가 원하는 경우, bc-헤더가 네트워크에 의해서 추가될 수 있다. 또 다른 예외로서, 피드백이 비압축 메시지로 전송되는 경우, 피드백 헤더가 부가될 수 있는데, 이는 도3을 참조하여 전술된 바와 같다. 또 다른 예외로서, 원격 종단점을 위한 컴파트먼트가 여러 가지 이유로 파괴되는 경우, 신호압축 협상(sigcomp negotiation)은 다시 시작된다. 이는, 부정확인 메카니즘(NACK mechanism)에 의해서도 검출될 수 있다.

전술한 매개변수들 중 몇몇은, REGISTER 메시지 내의 컨택 정보(contact information)의 일부가 될 수 있다. 또한, URI의 일부분이 되거나 REGISTER 메시지 내의 분리된 헤더-필드가 될 수 있다.

지금까지 본 발명에 따른, 패킷 데이터 망에서 신호 메시지를 압축하고 압축 해제하는 방법 및 장치에 대하여 설명하였다. 매개변수 정보는 패킷 데이터 망의 프로토콜 메시지의 헤더부에 제공된다. 그 매개변수 정보는 압축 메카니즘 또는 압축 해제 메카니즘의 최소한 하나의 처리 세목을 서술하고, 프로토콜 메시지와 함께, 패킷 데이터 망을 통하여, 패킷 데이터 망의 압축 기능부 또는 압축 해제 기능부에 전송된다. 압축 기능부에 있는 압축 메카니즘 또는 압축 해제 기능부에 있는 압축 해제 메카니즘은 매개변수 정보에 따라 설정된다. 그에 따라, 그 매개변수 정보가 직접적으로 이용됨으로서, 첫 번째 메시지 또는 그 첫 번째 메시지를 포함하여 몇몇 메시지가 더 개선된 방법으로 압축될 수 있다.

아울러, 본 발명은 상기 실시예에 의해서 그 범위가 제한되지 않고 대신에 어떠한 패킷 데이터 망에서도 구현될 수 있고, 여기서, 압축 매개변수 또는 압축 해제 매개변수는 서로 교환될 수 있어야만 한다. 매개변수 정보는 매개변수이기만 하면 어떠한 변수든지 정의할 수 있다. 또한 매개변수 정보는 기본 목적을 달성하기에 적절한 어떠한 헤더 부를 이용해서라도 신호로서 보내지거나 널리 알려질 수 있다.

Claims

패킷 데이터 네트워크에서 통신하는 방법으로서,

상기 패킷 데이터 네트워크 내의 종단점(endpoint)에서 응용계층 프로토콜 메시지를 수신하는 단계 - 상기 프로토콜 메시지는 상기 프로토콜 메시지의 헤더부에 매개변수 정보를 포함하며, 상기 매개변수 정보는 압축 또는 압축 해제 메카니즘에 대한 적어도 하나의 처리 세목(processing detail)을 특정함 - 와;

상기 매개변수 정보에 따라 상기 압축 또는 압축 해제 메카니즘을 설정하는 단계

를 포함하는 패킷 데이터 네트워크에서 통신하는 방법.
삭제
제1항에 있어서,

상기 응용계층 프로토콜 메시지는,

세션 개시 프로토콜 메시지(Session Initiation Protocol message) 또는 실시간 스트리밍 프로토콜 메시지(Real-Time Streaming Protocol message)를 포함하는 것인 패킷 데이터 네트워크에서 통신하는 방법.
제1항 또는 제3항에 있어서,

상기 적어도 하나의 처리 세목은,

SigComp 구조(SigComp architecture)의 적어도 하나의 매개변수를 포함하는 것인 패킷 데이터 네트워크에서 통신하는 방법.
제1항 또는 제3항에 있어서,

상기 프로토콜 메시지는,

통신을 위한 초기 요청에 응답하여 전송되는 피드백 메시지(feedback message)인 것인 패킷 데이터 네트워크에서 통신하는 방법.
제1항 또는 제3항에 있어서,

상기 프로토콜 메시지는 세션 개시 프로토콜(SIP) 메시지를 포함하며,

상기 적어도 하나의 처리 세목은,

인터넷 식별자(Uniform Resource Identifier : URI) 또는 상기 세션 개시 프로토콜 메시지의 비어 헤더(Via-header) 중 적어도 하나 내에서 제공되는 것인 패킷 데이터 네트워크에서 통신하는 방법.
제6항에 있어서,

상기 적어도 하나의 처리 세목은,

상기 패킷 데이터 네트워크의 중간 서버 장치(intermediate server device)에서 상기 인터넷 식별자(URI)에 부가되는 것인 패킷 데이터 네트워크에서 통신하는 방법.
제6항에 있어서,

상기 적어도 하나의 처리 세목은,

클라이언트 장치에서 상기 비어-헤더에 부가되는 것인 패킷 데이터 네트워크에서 통신하는 방법.
제1항 또는 제3항에 있어서,

상기 프로토콜 메시지의 헤더부에 있는 매개변수에 접미어(suffix)로서 상기 적어도 하나의 처리 세목을 부가하는 단계를 더 포함하며,

상기 매개변수는 상기 압축 또는 압축 해제 매커니즘의 이용을 나타내는 것인 패킷 데이터 네트워크에서 통신하는 방법.
제1항 또는 제3항에 있어서,

상기 적어도 하나의 처리 세목은, 상기 프로토콜 메시지의 헤더부에 데이터 필드로서 부가되며,

상기 데이터 필드는, 상기 압축 또는 압축 해제 메카니즘의 이용을 나타내는 매개변수와 구분되는 것인 패킷 데이터 네트워크에서 통신하는 방법.
제9항에 있어서,

상기 매개변수 정보는,

상기 적어도 하나의 처리 세목의 시작을 나타내는, 미리 정해진 제 1 문자(character)를 포함하는 것인 패킷 데이터 네트워크에서 통신하는 방법.
제11항에 있어서,

상기 적어도 하나의 처리 세목은,

개별 정수가 후속되는 적어도 하나의 문자를 포함하고, 상기 개별 정수는 상기 적어도 하나의 문자에 의해 표현되는 매개변수의 대응하는 값을 나타내는 것인 패킷 데이터 네트워크에서 통신하는 방법.
제12항에 있어서,

상기 적어도 하나의 처리 세목은,

신호 압축 버전, 상태 메모리 크기, 압축 해제 메모리 크기, 비트 당 사이클 수, 및 논리 가용 상태 중에서 적어도 하나를 서술하는 것인 패킷 데이터 네트워크에서 통신하는 방법.
제12항에 있어서,

상기 적어도 하나의 처리 세목은,

상기 압축 또는 압축 해제 메카니즘의 구현에 관한 독점적 정보(proprietary information)를 서술하는 것인 패킷 데이터 네트워크에서 통신하는 방법.
제1항에 있어서,

상기 매개변수 정보는,

가상 압축 해제 머신(virtual decompression machine)에 의해서 이용될 적어도 하나의 바이트코드(bytecode)를 포함하는 것인 패킷 데이터 네트워크에서 통신하는 방법.
제15항에 있어서,

상기 패킷 데이터 네트워크에서 상기 적어도 하나의 바이트코드를 알리는(advertising) 단계

를 더 포함하는 패킷 데이터 네트워크에서 통신하는 방법.
제15항 또는 제16항에 있어서,

상기 프로토콜 메시지는, 세션 개시 프로토콜 메시지를 포함하며,

상기 세션 개시 프로토콜 메시지의 비어-헤드(via-head)에, 상기 적어도 하나의 바이트코드를 비어 매개변수(via parameter)로서 부가하는 단계

를 더 포함하는 패킷 데이터 네트워크에서 통신하는 방법.
제17항에 있어서,

상기 비어 매개변수는,

바이트코드 상태 식별자(bytecode state identity)로부터 유도되는 것인 패킷 데이터 네트워크에서 통신하는 방법.
제15항 또는 제16항에 있어서,

상기 적어도 하나의 바이트코드는,

상기 적어도 하나의 바이트코드가 지원되지 않는 경우, 상기 응용계층 프로토콜 메시지에 응답하여 전송되는 응답 메시지에서 변경되거나 또는 교체되는 것인 패킷 데이터 네트워크에서 통신하는 방법.
제19항에 있어서,

상기 변경되거나 또는 교체된 바이트코드는,

상기 프로토콜 메시지에서 사용되는 원래의 매개변수 명칭과는 상이한 매개변수 명칭을 포함하는 것인 패킷 데이터 네트워크에서 통신하는 방법.
제15항 또는 제16항에 있어서,

상기 적어도 하나의 바이트코드를 저장하는 단계

를 더 포함하는 패킷 데이터 네트워크에서 통신하는 방법.
제21항에 있어서,

상기 적어도 하나의 바이트코드는,

가입자 식별 모듈(Subscriber Identity Module)에 저장되는 것인 패킷 데이터 네트워크에서 통신하는 방법.
제21항에 있어서,

상기 저장하는 단계는,

상기 적어도 하나의 바이트코드에 할당된 우선순위에 기초하여 수행되는 것인 패킷 데이터 네트워크에서 통신하는 방법.
제15항 또는 제16항에 있어서,

상기 프로토콜 메시지는 세션 개시 프로토콜 등록 메시지(Session Initiation Protocol Register message)를 포함하며, 상기 방법은,

상기 세션 개신 프로토콜 등록 메시지의 컨택 헤더(contact header)에 상기 적어도 하나의 바이트코드를 부가하는 단계

를 더 포함하는 패킷 데이터 네트워크에서 통신하는 방법.
패킷 데이터 네트워크에서 시그널링(signaling)을 처리하는 장치로서,

프로토콜 메시지를 수신하는 수단과;

상기 프로토콜 메시지의 헤더부로부터 매개변수 정보를 추출하는 수단 - 상기 매개변수 정보는 압축 메카니즘에 대한 적어도 하나의 처리 세목(processing detail)을 서술함 - 과;

상기 프로토콜 메시지에 대한 응답 메시지를 압축하도록 상기 압축 메카니즘을 설정하는 수단을 포함하며,

상기 압축 메카니즘의 상기 적어도 하나의 처리 세목에 따라 상기 압축 메카니즘이 설정되는 것인 패킷 데이터 네트워크에서 시그널링을 처리하는 장치.
제25항에 있어서,

상기 응답 메시지를 전송하기 위한 전송 수단을 더 포함하며,

상기 매개변수 정보는 압축 매개변수 정보를 포함하는 것인 패킷 데이터 네트워크에서 시그널링을 처리하는 장치.
제26항에 있어서,

상기 프로토콜 메시지는 세션 개시 프로토콜 메시지를 포함하며,

상기 매개변수 정보는, 인터넷 식별자(Uniform Resource Identifier : URI) 또는 상기 세션 개시 프로토콜 메시지의 비어 헤더(Via-header) 중 적어도 하나 내에서 제공되는 것인 패킷 데이터 네트워크에서 시그널링을 처리하는 장치.
제25항에 있어서,

상기 매개변수 정보는, 압축 해제 메카니즘에 대한 적어도 하나의 처리 세목을 더 포함하며,

상기 압축 해제 메카니즘에 대한 적어도 하나의 처리 세목에 따라 상기 프로토콜 메시지를 압축 해제하기 위해 상기 압축 해제 메카니즘을 설정하는 수단

을 더 포함하는 패킷 데이터 네트워크에서 시그널링을 처리하는 장치.
제25항에 있어서,

상기 매개변수 정보는,

상기 프로토콜 메시지를 압축 해제하기 위해 가상 압축 해제 머신(virtual decompression machine)에 의해 이용될 적어도 하나의 바이트코드를 더 포함하는 것인 패킷 데이터 네트워크에서 시그널링을 처리하는 장치.
제29항에 있어서,

상기 프로토콜 메시지는 세션 개시 프로토콜 메시지를 포함하며,

상기 적어도 하나의 바이트코드는, 상기 세션 개시 프로토콜 메시지의 비어 헤더 또는 컨택-헤더 내에서 제공되는 것인 패킷 데이터 네트워크에서 시그널링을 처리하는 장치.
패킷 데이터 네트워크로부터의 시그널링 메시지(signaling message)를 처리하는 장치로서,

응용계층 프로토콜 메시지의 헤더부에 매개변수 정보를 부가하기 위한 수단 - 상기 매개변수 정보는 압축 또는 압축 해제 메카니즘에 대한 적어도 하나의 처리 세목(processing detail)을 서술함 - 과;

상기 부가된 매개변수 정보를 갖는 상기 프로토콜 메시지를 상기 패킷 데이터 네트워크 내의 종단점에 전송하기 위한 수단

을 포함하는 패킷 데이터 네트워크로부터의 시그널링 메시지를 처리하는 장치.
제31항에 있어서,

상기 종단점은 단말기 장치 또는 프록시 서버를 포함하는 것인 패킷 데이터 네트워크로부터의 시그널링 메시지를 처리하는 장치.
제31항에 있어서,

상기 응용계층 프로토콜 메시지는 세션 개시 프로토콜 메시지를 포함하며,

상기 매개변수 정보는, 인터넷 식별자(Uniform Resource Identifier : URI) 또는 상기 세션 개시 프로토콜 메시지의 비어 헤더(Via-header) 중 적어도 하나 내에서 제공되는 것인 패킷 데이터 네트워크로부터의 시그널링 메시지를 처리하는 장치.
제31항에 있어서,

상기 매개변수 정보는, 압축 해제 매개변수 정보를 포함하는 것인 패킷 데이터 네트워크로부터의 시그널링 메시지를 처리하는 장치.
제34항에 있어서,

상기 압축 해제 매개변수 정보는,

가상 압축 해제 머신(virtual decompression machine)에 의해 이용될 적어도 하나의 바이트코드를 포함하는 것인 패킷 데이터 네트워크로부터의 시그널링 메시지를 처리하는 장치.
제35항에 있어서,

상기 응용계층 프로토콜 메시지는 세션 개시 프로토콜 메시지를 포함하며,

상기 적어도 하나의 바이트코드는, 상기 세션 개시 프로토콜 메시지의 비어-헤더(Via-header) 또는 컨택 헤더(Contact-header) 내에서 제공되는 것인 패킷 데이터 네트워크로부터의 시그널링 메시지를 처리하는 장치.