KR20010090597A - 공통 ip 어드레스를 갖는 이동 단말 및 무선 장치 - Google Patents

공통 ip 어드레스를 갖는 이동 단말 및 무선 장치 Download PDF

Info

Publication number
KR20010090597A
KR20010090597A KR1020017005236A KR20017005236A KR20010090597A KR 20010090597 A KR20010090597 A KR 20010090597A KR 1020017005236 A KR1020017005236 A KR 1020017005236A KR 20017005236 A KR20017005236 A KR 20017005236A KR 20010090597 A KR20010090597 A KR 20010090597A
Authority
KR
South Korea
Prior art keywords
protocol
address
packet
networked device
mobile
Prior art date
Application number
KR1020017005236A
Other languages
English (en)
Other versions
KR100897239B1 (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 러셀 비. 밀러
Publication of KR20010090597A publication Critical patent/KR20010090597A/ko
Application granted granted Critical
Publication of KR100897239B1 publication Critical patent/KR100897239B1/ko

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5007Internet protocol [IP] addresses
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/26Network addressing or numbering for mobility support
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04Network layer protocols, e.g. mobile IP [Internet Protocol]

Landscapes

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

Abstract

네트워크화된 장치가 별개의 네트워크화된 장치와 한개의 IP 어드레스를 공유한다. 상기 네트워크화된 장치는 수신된 IP 패킷의 포트 번호를 조사한다. 네트워크화된 장치는 상기 수신된 IP 패킷의 포트 번호가 애플리케이션에 대응하는 경우에는 상기 네트워크화된 장치 상의 애플리케이션으로 상기 IP 패킷을 라우팅한다. 상기 네트워크화된 장치는 또한 개시(origination) 어드레스로 상기 별개의 네트워크화된 장치에 할당된 IP 어드레스를 포함하는 IP 패킷을 발생시킨다. 마찬가지로, 상기 IP 어드레스는 상기 별개의 네트워크화된 장치에서 시작하는 전송된 IP 패킷을 차단하고, 개시 어드레스로 상기 별개의 네트워크화된 장치에 할당된 IP 어드레스를 포함하는 IP 패킷을 시작하므로써 상기 네트워크화된 장치 및 별개의 네트워크화된 장치 사이로 "시프트(shift)"될 수 있다.

Description

공통 IP 어드레스를 갖는 이동 단말 및 무선 장치{A MOBILE TERMINAL AND WIRELESS DEVICE WITH COMMON IP ADDRESS}
인터네트워킹, 즉 각 근거리 통신망(랜;LAN)의 연결이 급속도로 대중화되고 있다. 보통 "인터넷"이라고 불리는 그 기본 구조 및 관련된 프로토콜이 널리 알려지고 널리 사용되게 되었다. 인터넷 프로토콜(IP)은 인터넷의 가장 중요한 부분이며, 해당 기술 분야에 잘 알려져 있고, "인터넷 프로토콜 DARPA 인터넷 프로그램 프로토콜 설명서"(1981년 9월)라는 표제가 붙은 RFC(Request For Comment) 791에 더 설명된 바와 같이 랜간에 데이터그램의 라우팅을 써포트한다.
IP는 어드레싱을 포함하여 수개의 서비스를 제공하는 데이터그램-기반 프로토콜이다. IP 프로토콜은 전송을 위해 데이터를 IP 패킷으로 캡슐화하고, 어드레싱 정보를 패킷의 헤더에 추가한다. IP헤더는 송신 및 수신 호스트를 식별하는 32비트 어드레스를 포함한다. 이러한 어드레스들은 패킷을 위한, 네트워크를 통과하여 의도된 어드레스의 궁극적 목적지로의 경로를 선택하기 위해, 중간 라우터에 의해 사용된다. IP 어드레싱의 기본 개념은 IP 어드레스의 초기 전치부호(prefix)가 일반화된 라우팅 결정에 사용될 수 있다는 것이다. 예를 들어, 어드레스의 처음 16비트는 콸콤 인코포레이티드를 식별하고, 처음 20비트는 콸콤의 메인 오피스를 식별하며, 전체 32비트는 이더넷(Ethernet) 상의 특정 호스트를 식별할 수 있다. 추가적인 예로서, 콸콤의 IP 네트워크에 있어서 모든 어드레스는 점으로 구분된 4개의 숫자(dotted-quad notation) 형태, 예를 들면 129.46.xxx.xxx이고, 여기서 "xxx"는 0에서 255 사이의 정수이다.
이와 같은 IP의 전치부호-기반의 라우팅 특징에 의해 명백한 바와 같이, 상기 IP 어드레스는 인터넷 상의 특정 호스트의 위치에 관한 암시적인 지리적 정보를 포함한다. 다른 말로 하면, 인터넷 상의 임의의 라우터가 "129.46"으로 시작하는 목적지 IP 어드레스를 갖는 패킷을 수신할 때마다, 상기 라우터는 미국 캘리포니아 주의 콸콤 인코포레이티드로 향하는 특정 방향으로 그 패킷을 전송한다. 그리하여, 상기 IP 프로토콜은, 출발점의 그룹이 목적지 그룹의 IP 어드레스를 안다는 전제하에, 상기 전세계의 임의의 인터넷 노드에서 발생된 데이터그램이 다른 어떠한 전세계 인터넷 노드로도 라우팅될 수 있게 한다.
이동 컴퓨팅 및 이동 인터넷 액세스의 인기가 높아지면서, IP 프로토콜을 사용하여 랩탑 또는 팜탑 컴퓨터 같은 이동 단말들에 대한 이동 데이터 써포트를 제공하기 위한 필요성이 증가했다. 그러나, 언급한 대로, 인터넷 라우팅에 사용되는 IP 어드레싱 방식은 암시된 지리적 정보를 포함한다. 다른 말로 하면, 사용자가 자신의 이동 단말을 식별하기 위해 고정 IP 어드레스를 사용하고자 하는 경우에, 그이동 단말이 "홈" 네트워크(즉, 그 고정 IP 어드레스를 포함하는 네트워크)에서 분리되어 있을때, IP 패킷을 상기 이동 단말로 전송하기 위한 기술이 없으면, 그 이동 단말을 향하도록 의도된 IP 패킷은 그 이동 단말로 라우팅 되지 않을 것이다.
예를 들어, 사용자가 그의 이동 단말을 샌디에이고의 콸콤 인코포레이티드에 있는 "홈" IP 네트워크로부터 분리해서, 캘리포니아의 팔로 알토로 가져가서 자신의 콸콤에 할당된 고정 IP 어드레스를 유지한채, 그곳의 스탠포드 대학교의 IP 네트워크에 연결하기로 결정하였다고 가정하자. 상기 이동 단말의 고정 IP 어드레스에 암시된 지리적 위치 정보 때문에, 상기 이동 단말로 향하도록 의도된 임의의 IP 어드레스는 여전히 콸콤의 IP 네트워크로 라우팅될 것이다. IP 패킷들을 콸콤의 IP 네트워크에서 팔로 알토의 스탠포드 대학교의 IP 네트워크에 있는 인터넷에 연결되어 있는 현재 위치의 상기 이동 단말로 전송하기 위한 어떤 메카니즘이 없다면, 그러한 IP 패킷들은 그 "홈" 네트워크에서 분리된 경우에는 상기 이동 단말로 전달될 수 없다.
이러한 필요성을 충족시키기 위해, "IP 이동성 써포트"(1996년 10월)라는 표제가 붙은 RFC 2002에는 인터넷에서 이동 노드로의 IP 데이터그램의 투명한 라우팅을 가능케하는 프로토콜 프로토콜 향상 대책이 설명되어 있다. RFC 2002에 설명된 기술들을 사용하여, 각 이동 노드는 현재 인터넷에 연결된 위치에 상관없이, 항상 그 "홈" IP 어드레스에 의해 식별된다. 그 홈 IP 네트워크에서 분리된 경우, 이동 단말은 "캐어-오브(care-of)" 어드레스와 관련하게 되어, IP 데이터그램을 라우팅하는데 필요한 정보를 현재 인터넷에 연결된 위치로 전송해준다. RFC 2002는 캐어-오버 어드레스의 등록을 위해 "홈 에이전트"를 제공하므로써 이것을 수행한다. 이 홈 에이전트는 "IP 터널링"으로 불리는 기술을 사용하므로써 상기 이동 단말로 향하도록 의도된 IP 데이터그램을 전송한다. IP 터널링은 캐어-오브 어드레스를 포함하는 새 IP 헤더를 상기 이동 단말의 홈 IP 어드레스에 해당하는 목적지 어드레스를 갖는 임의의 도착하는 IP 패킷에 부착하는 홈 에이전트를 포함한다. 상기 캐어-오브 어드레스에 도착한 후에, 상기 캐어-오브 어드레스에 있는 "외부 에이전트"는 상기 IP 터널링 헤더를 분리시키고, 상기 IP 패킷을 인터넷에 연결된 현재 위치에 있는 상기 이동 단말에 전달한다.
이런 식으로, RFC 2002기술은, 자신의 이동 단말의 IP 어드레스를 바꾸지 않고도 그 이동 단말의 인터넷 연결 위치를 바꾸고자 하는 사용자들에게 이동 데이터 서비스를 제공한다. 이것은 몇가지 장점을 갖는다. 첫째, 이것은 인터넷 상의 다른 모든 위치의 출발 노드로 하여금 그것이 어디에 있건 관계없이 상기 이동 단말로 주기적인 "푸시(push)" 서비스를 전송한다. 그러한 서비스에는 주식 시세 또는 이메일도 포함된다. 이것은 이동 사용자가 정보를 검색하기 위해 "다이얼 인"하거나 또는 그의 홈 네트워크에 접속할 필요가 없도록 한다. 또한, 이것은 상기 이동 단말로 하여금, 임의의 출발 그룹이 상기 이동 단말의 위치를 추적하지 않아도, 원하는 만큼 자주 그 위치를 바꿀 수 있도록 한다.
이동 단말의 이동 자유성을 증가시키기 위해, 많은 이동 사용자들은 통상적으로 셀룰러 또는 휴대 전화같은 무선 통신 장치를 사용하여 인터넷에 접속한다. 다른 말로 하면, 많은 이동 사용자들은, 지상-기반 네트워크로의 액세스점으로 보통 "이동국"이라고 불리는 무선 통신 장치 또는 MT2 장치를 사용한다. 여기에 사용된 바와 같이, "이동국" 또는 "MT2 장치"는 이동하고 있거나 갑작스런 중지 상황에서 사용되도록 의도된 공중 무선 네트워크의 임의의 기지국을 가리킬 것이다. 이동국 및 MT2 장치는 휴대용 유닛(예컨대, 핸드-헬드(hand-held) 개인 전화), 자동차에 인스톨된 유닛, 및 무선 로컬 루프(WLL;Wireless Local Loop) 전화를 포함한다.
도 1은 무선 단말(TE2 장치;102)이 무선 통신 장치(MT2 장치;104) 및 기지국/이동국 스위칭 센터(BS/MSC;Base Station/Mobile Switching Center;106)를 포함하는 무선 통신 시스템을 통해 인터워킹 펑션(IWF;Interworking Function;108)과 통신하는 무선 데이터 통신 시스템에 대한 하이-레벨 블록 다이어그램이다. 도 1에서, 상기 IWF(108)는 인터넷에 액세스 포인트로서의 역할을 한다. IWF(108)는 BS/MSC(106)에 연결 및 BS/MSC(106)와 함께 위치하고, 이것은 종래 기술에서 알려진 바와 같은 통상적인 무선 기지국이다. TE2 장치(102)는 MT2 장치(104)에 연결되며, MT2 장치(104)는 교대로 BS/MSC(106) 및 IWF(108)와 무선 통신한다.
TE2 장치(102) 및 IWF(108) 사이의 데이터 통신을 가능케하는 많은 프로토콜들이 존재한다. 예를 들어, "광대역 확산 스펙트럼 시스템에 대한 데이터 서비스 옵션:패킷 데이터 서비스"(1998년 2월 발간)라는 표제가 붙은 텔레커뮤니케이션 공업 협회(Telecommunication Industry Association;TIA)/전자공업 협회(Electronics Industry Association;EIA) 인터림 표준 IS-707.5에는 일부분이 BS/MSC(106) 및 IWF(108)인 TIA/EIA IS-95 광대역 스펙트럼 확산 시스템 상의 패킷 데이터 전송 능력의 써포트에 대한 필요조건에 정의되어 있다. IS-707.5는 BS/MSC(106)를 통해TE2 장치(102) 및 IWF(108)간의 통신에 사용되는 패킷 데이터 운반인 서비스를 설명한다. 위 설명에는 RFC 2002의 이동 IP 서비스 및 "셀룰러 디지털 패킷 데이터(CDPD) 시스템 설명서, 버젼 1.1"(CDPD 포럼 인코포레이티드, 1995년 1월 29일 발간)라는 표제가 붙은 CDPD를 포함하는 다중 패킷 데이터 서비스에 적용될 수 있는 절차들이 제공되어 있다. CDPD는 AMPS(아날로그) 셀룰러 데이터 서비스이며, 이동성에 대한 그 자신의 약간의 써포트를 포함한다. CDPD는 몇가지 중요한 점에서 이동 IP와 다르다. 가장 눈에 띄게는, CDPD 모뎀은 CDPD 네트워크에 속하는 할당된 IP 어드레스를 갖는다. 따라서, CDPD 모뎀이 CDPD 네트워크 내에서 로밍하더라도, 이동 IP로 써포트되는 단말이 그 "홈" 네트워크의 바깥에서 그 "홈" 어드레스를 사용하는 방식과 동일한 방식으로 CDPD 네트워크 밖에서 그 IP 어드레스를 사용하지는 않는다.
IS-707.5는 또한 TE2 장치(102)와 MT2 장치(104; Rm 인터페이스)사이, MT2 장치(104)와 BS/MSC(106;Um 인터페이스)사이 및 BS/MSC(106)와 IWF(L 인터페이스)사이의 링크 상에 통신 프로토콜에 대한 필요조건들도 제공한다.
이제 도 2를 참조하면, IS-707.5 릴레이 모델의 각 실체에 있는 프로토콜 스택의 다이어그램이 도시되어 있다. 도 2는 대략 IS-707.5의 도 1.4.2.1-1에 해당한다. 상기 도면의 맨 좌측에는, 통상적인 수직 포맷으로, TE2 장치(102)(예컨대, 이동 단말, 랩탑 또는 팜탑 컴퓨터) 상에서 실행되는 프로토콜 층을 보여주는 프로토콜 스택이 있다. 상기 TE2 프로토콜 스택은 상기 Rm 인터페이스를 통해 MT2 장치(104)로 논리적으로 연결되는 것으로 도시되어 있다. 상기 MT2 장치(104)는 상기 Um 인터페이스를 통해 상기 BS/MSC(106) 프로토콜에 논리적으로 연결되는 것으로 도시되어 있다. 상기 BS/MSC(106)는 교대로 L 인터페이스를 통해 IWF(108) 프로토콜 스택에 논리적으로 연결되는 것으로 도시되어 있다.
도 2의 동작의 예는 다음과 같다. TE2 장치(102) 상에서 실행되는 응용 프로그램과 같은 상부 층 프로토콜(202) 실체는 인터넷을 통해 IP 패킷을 전송할 필요가 있다. 응용의 예로는 넷스케이프 네비게이터나 마이크로소프트 익스플로러 등과 같은 웹 브라우저가 있다. 웹 브라우저는 http://www.qualcomm.com 같은 URL(Universal Resource Locator)을 요구 한다. 또한 상부층 프로토콜(202)에 있는 DNS(Domain Name System)는 텍스트 형식의 호스트 네임 "www.qualcomm.com"을 32비트 숫자 IP 어드레스로 번역한다. 또한 상부층 프로토콜(202)에 있는 HTTP(Hypertext Transfer Protocol)는 요구된 URL에 대한 GET 메시지를 구축하고, 또한 TCP(Transmission Control Protocol)이 메시지를 전송하는데 사용될 것과 TCP 포트(80)가 HTTP 동작에 사용될 것임을 특정한다.
상부층 프로토콜(202)인 TCP 프로토콜은 DNS 포트(80)에 의해 특정되는 IP 어드레스로의 연결을 열고, HTTP GET 메시지를 전달한다. 상기 TCP 프로토콜은 상기 IP 프로토콜이 메시지 전송에 사용될 것임을 특정한다. 네트워크층 프로토콜(204)인 IP 프로토콜은 상기 TCP 패킷을 특정된 IP 어드레스로 전달한다. 링크층 프로토콜(206)인 PPP(Point to Point Protocol)는 상기 IP/TCP/HTTP 패킷을 인코딩하고 그것을 릴레이층 프로토콜(208;EIA-232)을 사용하여 상기 Rm 인터페이스를 통해 MT2 장치 상의 EIA-232-호환 포트로 전송한다. 상기 PPP 프로토콜은 "점대점 프로토콜(PPP)"라는 표제가 붙은 RFC 1661에 상세히 설명되어 있다.
상기 MT2 장치(104) 상의 EIA-232 프로토콜(210)은, Um 인터페이스를 통해 BS/MSC로 전달하기 위해, 상기 전송된 PPP 패킷을 RLP(Radio Link Protocol;212) 및 IS-95 프로토콜(214)의 조합으로 전달한다. 상기 RLP 프로토콜(212)은 IS-707.2에 정의되어 있고, IS-95 프로토콜은 위에 언급된 IS-95에 정의되어 있다. RLP 프로토콜(216) 및 IS-95 프로토콜(218)의 조합을 포함하는 BS/MSC(106) 상의 보충 릴레이층 프로토콜 스택은 상기 Um 인터페이스를 통해 PPP 패킷을 수신하고, 그것을 상기 IWF 릴레이층 프로토콜(228)로의 L 인터페이스를 통과시키기 위해 MT2 릴레이층 프로토콜(220)로 전달한다. 상기 MT2 릴레이층 프로토콜(220) 및 IWF 릴레이층 프로토콜(228)은 "광대역 스펙트럼 확산 디지털 셀룰러 시스템을 위한 데이터 서비스 인터워킹 펑션 인터페이스"라는 표제가 붙은 TIA/EIA IS-658에 설명되어 있다.
상기 IWF의 링크층(227)에 있는 PPP 프로토콜은 TE2 장치(102)로부터의 PPP 패킷을 디코딩하고, TE2 장치(102) 및 IWF(108) 사이의 PPP 연결을 종료시키기 위해 서비스한다. 상기 디코딩된 패킷들은, 검토 및 IP 패킷 헤더에 있는 TE2 장치(102)로 특정된 IP 어드레스(여기서는 www.qualcomm.com에 대한 IP 어드레스)로의 라우팅을 위해, PPP 프로토콜(226)에서 IWF(108)의 네트워크층 프로토콜(224)의 IP 프로토콜로 전달된다. TCP 같이 IWF(108)에서 수행될 상부층 프로토콜 작업들이 있는 경우에, 그 작업들은 상부층 프로토콜(222)에 의해 수행된다.
TE2 장치(102)에 의해 발생된 IP 패킷의 궁극적인 목적지가 IWF(108)이 아니라고 가정하면, 패킷들은 IWF(108)의 네트워크층 프로토콜(224), 링크층(227) 및릴레이층 프로토콜(228)을 통해 인터넷 상의 다음 라우터(미도시)로 전송된다. 이런 식으로, TE2 장치(102)로부터의 IP 패킷은 MT2 장치(104), BS/MSC(106) 및 IWF(108)를 통해 인터넷 상의 궁극적인 의도된 목적지를 향해 통신되고, 따라서 상기 IS-707.5 표준 릴레이 모델에 따른 TE2 장치(102)에 무선 패킷 데이터 서비스를 제공하게 된다.
도 2에 설명된 바와 같이, 상기 IS-707.5 표준은 TE2 장치(102) 및 IWF(108) 사이의 링크 상의 통신 프로토콜에 대한 필요조건을 제공하는데, 이 필요조건에는 Rm, Um 및 L 인터페이스에 대한 필요조건이 포함된다. 이러한 필요조건 및 절차들은 RFC 2002에 설명된 이동 IP 서비스를 써포트하는데 적용가능하다. 그러나, IS-707.5는 첫번째 예에서 이동 IP 서비스를 구축하기 위한 절차는 제공하지 않는다. 다른 말로 하면, IS-707.5는 이동 IP 서비스를 써포트하기 위한 프레임워크를 제공하지만, 이동 IP 서비스를 협상(negotiate)하거나, 이동 IP 서비스에 대한 홈 에이전트 및 외부 에이전트를 갖는 TE2 장치(102)를 등록하기 위한 절차를 제공하지는 않는다. 이러한 절차들은 RFC 2002 내에서 찾아볼 수 있다.
또한, IS-707.5의 네트워크 및 릴레이 모델은 TE2 장치(102)로의 단일 IP 어드레스 할당을 암시한다. MT2 장치(104)의 배타적인 사용을 위한 제2 IP 어드레스의 할당에 아무것도 별개로 제공되지 않는다. 정말로, 현재로서는 PPP 세션당 하나 이상의 IP 어드레스를 얻는 것이 가능하지 않다. 모빌 마다 다중 PPP 세션을 써포트하는 것은 IWF(108)에서의 자원의 추가적인 손실때문에 서비스 제공자들에게는 그리 매력적이지 않다. 사용자가, 이동 IP를 써포트하기 위해서는 통상적으로 몇몇애플리케이션층 실체가 TE2 장치(102) 내에 존재하여야 한다는 것을 고려한다면 이 차이점은 중요하다. 불행하게도, 개인 컴퓨터에 대한 가장 인기있는 운영체제인 마이크로소프트 윈도우는 이동 IP를 써포트하지 않으며, 현재로서는 그러한 써포트를 할 것이라고 기대되지도 않는다. 결과적으로, 마이크로소프트 윈도우(또는 다른 운영 체제)를 실행시키는 TE2 장치는 자신의 "홈" IP 네트워크에 연결되지 않은 경우는 그들의 "홈" IP 어드레스를 사용할 수 없다. 이 때문에 이동 사용자는, "홈" IP 네트워크에서 분리되어 있을 때는, "푸시" 서비스 및 직접 이메일 배달과 같은 이동 IP 서비스의 잇점을 이용할 수 없다.
MT2 장치가 TE2 장치에 대한 이동 IP 써포트를 구축하기 위해 TE2 장치에 대한 프록시(proxy)로서 동작하는, TE2 장치의 이동 IP 등록을 수행하기 위한 방법 및 시스템이 요구된다. 보다 일반적으로는, 두개의 네트워크화된 장치(예컨대, MT2 및 TE2)가 하나의 IP 어드레스를 공유할 수 있도록 해주는 방법 및 시스템이 요구된다.
본 발명은 무선 데이터 서비스에 관련된 것이다. 보다 구체적으로는, 본 발명은 네트워크에 연결된 장치들 사이에서 인터넷 프로토콜(IP) 종점들을 시프팅(shifting)하기 위한 신규하고 진보된 방법 및 시스템에 관련된 것이다.
도 1은 단말 장치가 무선 통신 장치를 통해 인터넷에 연결되는 무선 데이터 통신 시스템에 대한 하이-레벨 블록 다이어그램.
도 2는 IS-707.5 릴레이 모델의 각 실체에 있는 프로토콜 스택의 다이어그램.
도 3은 본 발명의 MT2 장치의 동작에 대한 하이-레벨 상태도.
도 4는 본 발명의 한 실시예에 대한 각 실체의 프로토콜 스택의 다이어그램.
도 5는 도 3의 이동 IP 모드 상태(310)에 대한 확장된 상태도.
도 6은 본 발명의 대체적인 실시예의 각 실체에 대한 프로토콜 스택의 다이어그램.
도 7은 도 3의 이동 IP 모드(310)에 대한 대체적 실시예에 대한 확장 상태도를 설명한다.
도 8은 IP 어드레스 시프팅을 수행하기 위한 한 방법을 설명하는 흐름도.
도 9A는 IP 패킷 수신과 관련하여 IP 어드레스 시프팅을 수행하기 위한 대체적인 방법을 설명하는 흐름도.
도 9B는 IP 패킷 송신과 관련하여 IP 어드레스 시프팅을 수행하기 위한 대체적인 방법을 설명하는 흐름도.
본 발명은 프록시 이동 노드 등록의 부분으로서 수행되는 것과 같은 IP 종점들을 시프팅하기 위한 신규하고 진보된 시스템 및 방법에 관련된 것이다. 상기 방법은 단말 장치로부터 이동 데이터 서비스가 필요하다는 신호를 보내는 단계 및 무선 통신 장치에 있어서, 상기 신호를 보내는 단계에 반응하여 단말 장치의 이동 노드 등록을 초기화하는 단계를 포함한다. 상기 단말 장치는 패킷화된 데이터를 전송하고, 상기 단말 장치에 접속된 무선 통신 장치는 상기 패킷화된 데이터를 IP 어드레스 요구에 포함된 인터넷 프로토콜(IP) 어드레스에 대해 모니터링한다. 상기 IP 어드레스 요구가 정적 IP 어드레스에 대한 것일 경우에, 상기 무선 통신 장치는 상기 IP 어드레스를 사용하여 이동 노드 등록을 초기화한다. 상기 무선 통신 장치는 이동 노드 등록을 시작할 때, 상기 단말 장치가 패킷화된 데이터를 송신하거나 수신하지 못하도록 하고, 이동 노드 등록이 완료된 후에 상기 단말 장치가 패킷화된 데이터를 송신 및 수신하도록 한다. 결과적으로, 이동 노드 등록은 상기 단말 장치에 투명하게 발생되고, 단말 장치가 자신의 이동 IP 써포트를 가질 필요가 없도록 해준다.
본 발명의 또다른 관점에서, 네트워크화된 장치(무선 통신 장치도 가능)는 분리된 네트워크화된 장치(단말 장치일 수도 있음)와 IP 어드레스를 공유한다. 상기 공유는 수신된 IP 패킷의 포트 번호를 조사하는 네트워크화된 장치에 의해 발생한다. 상기 수신된 IP 패킷의 포트 번호가 상기 네트워크화된 장치는 상기 IP 패킷을 상기 네트워크화된 장치 상의 애플리케이션으로 라우팅한다. 반면에, 상기 수신된 IP 패킷의 포트 번호가 상기 네트워크화된 장치 상에서 동작하는 애플리케이션에 대응하는 경우에는, 상기 네트워크화된 장치는 상기 IP 패킷을 별도의 네트워크화된 장치로 라우팅한다.
또한, 상기 네트워크화된 장치는, 상기 네트워크화된 장치 상의 애플리케이션이 IP 패킷을 발생시킬 필요가 있는지를 결정한 후에, 개시(origination) 어드레스로서 상기 별도의 네트워크화된 장치에 할당된 IP 어드레스를 포함하는 IP 패킷을 발생시킨다.
마찬가지로, 상기 IP 어드레스는 상기 네트워크화된 장치 및 별도의 네트워크화된 장치 사이로 시프팅된다. 상기 네트워크화된 장치는, 별도의 네트워크화된 장치에서 발생하여 전송된 IP 패킷을 차단하고, 또한 상기 네트워크화된 장치가 상기 제1 네트워크화된 장치상의 애플리케이션이 IP 패킷을 발생시킬 필요가 있다고 결정하는 경우에는, 개시 어드레스로 상기 별개의 네트워크화된 장치로 할당된 IP 어드레스를 포함하는 IP 패킷을 발생시키므로써, 별도의 네트워크화된 장치로부터 그 자신으로 IP 어드레스를 시프트 시킨다. 상기 네트워크화된 장치는, 상기 별도의 네트워크화된 장치의 IP 어드레스를 사용하는 동안, 상기 별도의 네트워크화된 장치로 어드레싱된 수신된 IP 패킷을 버릴 수 있다.
본 발명의 특징, 목적 및 장점들은 도면들과 함께 아래의 설명으로부터 더 명백해 질 것이며, 동일한 참조 문자들은 도면 전체에 걸쳐 동일한 아이템을 표시하는 것이다.
본 발명은 데이터 서비스 가능 MT2 장치의 사용자들로의 투명한 이동성을 써포트하도록 의도된다. 본 발명의 다양한 실시예들이 3개의 사용 모델하에서 데이터 서비스들을 써포트하도록 의도된다.
제1 사용 모델은 이동 IP가 써포트되지 않지만, 동적으로 할당된 IP 어드레스를 사용하는 데이터 서비스들은 그럼에도 불구하고 여전히 써포트된다. 이 첫 번째 사용 모델에서, 상기 TE2 장치는 TE2 장치가 현재 연결된 인터넷 서비스 공급자(ISP)에 의해 IP 어드레스가 동적으로 할당된다. 이 제1 사용 모델은 이동 IP 써포트를 사용하지 않고 그 "홈" IP 어드레스도 사용하지 않는다. 결과적으로, 상기 TE2 장치는, 그 홈 IP 네트워크로부터 데이터를 전달하기 보다는, 상기 ISP에 연결된 동안 그것이 명시적으로 요구한 데이터 만을 수신한다.
제2 사용 모델은 TE2 장치를 대표하는 프록시로서, 이동 IP 써포트가 MT2 장치에 제공되는 것이다. 이 제2 모델은 이동 IP 써포트를 갖기 원하는 이동 사용자들에게 적용되지만, 이동 IP를 써포트하는 TE2 장치를 갖지 않은 이동 사용자들에게는 적용되지 않는다. 예를 들어, 마이크로소프트 윈도우즈 운영 체제를 실행시키고 있는 랩탑 같은 TE2 장치들의 사용자는 이 제2 사용 모델에 속한다. 이 제2 사용 모델에서, TE2 장치는 자신의 홈 IP 네트워크에 연결되어 있는지 또는 이동 IP-활성화된 무선 네트워크 상에서 로밍하고 있는지에 관계없이, 자신의 "홈" IP 어드레스(즉, 자신의 홈 네트워크에 의해 할당된 "불변(permanent)" IP 어드레스)를 사용한다. 이 제2 사용 모델은 또한 소위 "스마트 폰"이라고 불리는 TE2 장치 및 MT2 장치를 통합하는 장치들에 대한 이동성 써포트를 제공한다.
제3 사용 모델은 TE2 장치에 이동 IP 써포트가 제공되는 것이다. 이 제3 사용 모델은 이동 IP 써포트를 갖는 TE2 장치들의 사용자들에게 적용가능하며, 따라서 MT2 장치로부터의 프록시 서비스가 필요치 않다. 본 발명의 다양한 실시예들이 이 3가지 사용 모델에 대한 하나 이상의 필요조건을 만족시키도록 의도된다.
아래에 설명된 본 발명이 번호들(TE2 장치(102), MT2 장치(104), BS/MSC(106) 및 IWF(108))에 설명된 각 실체들에서 소프트웨어, 펌웨어 및 하드웨어 같은 많은 다른 실시예들로 구현될 수 있다는 것은 해당 분야의 당업자들에게는 명백할 것이다. 본 발명을 구현하기 위해 사용된 실제적인 소프트웨어 코드 또는 제어 하드웨어는 본 발명을 제한하지 않는다. 따라서, 본 발명의 동작은 실제적인 소프트웨어 코드를 참조하지 않고 설명될 것이며, 해당 분야의 당업자가 여기의 설명을 기초로 본 발명의 다양한 실시예를 구현하기 위한 소프트웨어 및 제어 하드웨어를 설계할 수 있다는 것이 이해될 것이다.
도 3으로 넘어가서, 본 발명의 MT2 장치의 동작에 대한 하이-레벨 상태도가 도시되어 있다. 도 3에서 MT2 장치는 폐쇄 상태(308)에서 시작한다. 폐쇄상태(308)에서 상기 MT2 장치는 콜(call) 중에 있지 않고 콜을 기다리는 상태이다. 이동-종료 콜(즉, MT2 장치가 콜을 받은 그룹의 콜)은 이 상태에서는 고려되지 않으며, 그 콜들은 이미 IP 어드레스 할당되어 있거나 이동 IP를 등록했다고 가정한다. MT2 장치가 이미 이동 IP에 등록한 경우에, 이것은 이 폐쇄 상태(308)에 있지 않고, 아래에 완전히 설명될 이동 IP 모드 상태(310)에 있다.
패킷 데이터 콜이 TE2 장치에서 시작하면, 상기 MT2 장치 폐쇄 상태(308)에서 이동성이 활성화되었는가?상태(304)로 변환된다. 이동성이 활성화되었는가?상태(304)에서, 상기 MT2 장치는 (이동 IP에 대한)이동성 써포트가 활성화되었는가를 판단하기 위해 이동성 데이터 아이템(302)의 값을 체크한다. 한 실시예에서, 이동성 데이터 아이템(302)은 바람직하게는 예컨대 TE2 장치 또는 MT2 장치 상의 사용자 인터페이스를 통하여 이동성 사용자에 의해 선택적으로 구성된 3개의 값들 중 하나를 갖는다. 다른 실시예들도 이동 사용자가 다소간의 구성 선택권을 가질수 있도록 하기 위해 다소간의 값들을 사용한다. 여전히 다른 실시예들은 이동성 데이터 아이템(302)에 대한 사용자-구성이 가능하지 않다. 다른 실시예들에서, 이동성 데이터 아이템(302)은 존재하지 않고, 결정은 제어 소프트웨어로 하드-코딩(hard-coded)된다.
이동성 데이터 아이템의 제1 값은 "비활성화"이다. 이동성 데이터 아이템(302) 값이 "비활성화" 일때는, MT2 장치는 이동 IP 협상 및 등록을 써포트하지 않는다. 결과적으로, 이동성 데이터 아이템(302)이 "비활성화" 값을 가질때 발생된 모든 패킷 데이터 콜들은 아래에 설명될 바와 같이 단순 IP 모드(306)를 사용한다.
제2 값은 "사용가능한 경우(if available)"이다. 이동성 데이터 아이템(302) 값이 "사용가능한 경우"인 때는, 하부구조(BS/MSC(106) 및 IWF(108))가 이동 IP를 써포트하거나, MT2 장치에 의해 시도된 이동 노드 등록이 실패하지 않은 경우에, 상기 MT2 장치는 IP 협상 및 등록을 제공할 것이다.
하부구조가 이동 IP를 써포트하지 않는 경우에, 패킷 데이터 콜은 단순 IP 모드(306) 콜이 된다. 다른 말로 하면, 이동성 데이터 아이템(302)에 대한 "사용가능한 경우" 값은, 하부구조에 의해 써포트되고 성공적으로 협상되었을때는, TE2 장치 및 MT2 장치의 사용이 이동 IP의 장점을 얻을 수 있도록 해주지만, 그렇지 않은 경우에도 여전히 이동 IP 써포트없이 데이터 패킷 데이터 콜은 가능하다. 이동 사용자가 이동성 데이터 아이템(302) 값을 변화시킬 수 없는 실시예에서는, 이 제2 값이 사용된다. 양자택일로, 이동성 데이터 아이템(302)은 항상 "사용가능한 경우"로 설정되어 있거나, 완전히 생략되어 있어서, 이동성이 활성화되었는가?상태(304) 및 단순 IP 모드 상태(306) 사이의 변환을 제거시킨다.
제3 값은 "배타적으로"이다. 이동성 데이터 아이템(302)의 값이 "배타적으로"인 경우에, 상기 하부구조(BS/MSC(106) 및 IWF(108))가 이동 IP를 써포트 하거나 MT2 장치에 의해 시도된 이동 노드 등록이 실패하지 않으면, 상기 MT2 장치는 이동 IP 협상 및 등록을 제공한다. 그러나, 위의 "사용가능한 경우" 값과 대조적으로, 하부구조가 이동 IP를 써포트하지 않거나, 이동 노드 등록 시도가 실패하는 경우에는, MT2 장치는 단순 IP 콜을 완료시키지 않고 패킷 콜 발생 시도를 완전히 실패시킨다. 즉, 이동성 데이터 아이템(302)에 대한 "배타적으로" 값은 이동 IP가 써포트되는 콜 이외에는 어떤 패킷 데이터든 MT2 장치에서 발생하지 못하도록 한다.
이동성 데이터 아이템(302) 값이 "비활성화"이거나 이동성 데이터 아이템(302)값이 "사용가능한 경우"이지만 이동 IP가 하부구조에 의해 써포트되지 않는 경우에, MT2 장치는 패킷 데이터 콜 발생 시도로 단순 IP 모드(306)를 시작할 것이다. 한 실시예에서, 상기 단순 IP 모드(306)는 도 2를 참조하여 설명된 바와 같은 통상적인 IS-707.5 릴레이 모델을 채용한다.
이동성 데이터 아이템(302) 값이 "사용 가능한 경우" 또는 "배타적으로"인 경우에, MT2 장치는 이동성이 활성화되었는가?상태(304)에서 이동 IP 모드(310)로의 변환된다. MT2 장치가 아래에 설명될 바와 같이 TE2 장치를 대표하는 프록시로서 이동 IP 서비스에 대한 이동 노드 등록에 관여하는 것은 이 이동 IP 모드(310)이다.
도 4로 넘어가서, 본 발명의 한 실시예에 대한 각 실체의 프로토콜 스택에 대한 다이어그램이 도시되어 있다. 도 4의 다이어그램과 도 2의 다이어그램의 차이점은, 도 4에서는 추가적인 프로토콜층 본 발명의 이동 노드 등록을 써포트하기 위해 MT2 장치(104)에 존재한다는 것이다. 이러한 추가적인 프로토콜 층들은 PPP 프로토콜(415), IP 프로토콜(413), UDP 프로토콜(411) 및 이동 IP 프로토콜(409)을 포함한다. 추가적인 프로토콜 층들은, 도 4의 프로토콜 층이 도 2의 프로토콜 층과 동일하게 동작하게 되는 범위까지 확장되지는 않을 것이다. 다음 설명은 도 4 및 도 2의 차이점을 중심으로 설명한다.
도 4의 동작에 대한 예시는 다음과 같다. TE2 장치(102) 상에서 동작하는 애플리케이션과 같은 상부층 프로토콜(402)은, 도 2의 상부층 프로토콜(202) 실체와 유사하게, 인터넷을 통해 IP 패킷을 전송할 필요성을 갖는다. 이 애플리케이션은 예를 들어, TCP 또는 UDP 프로토콜을 사용하는 메시지를 발생시키고 TCP 또는 UDP 패킷은 목적지 IP 어드레스를 사용하는 IP 프로토콜에 의해 캡슐화된다. PPP(406)는 IP 패킷의 틀을 구성하고 릴레이층 프로토콜(408) IP 패킷들을 EIA-232를 사용하는 Rm 인터페이스를 통해 EIA-232 프로토콜(410)을 실행시키는 MT2 장치 상의 EIA-232-호환 포트로 전송한다.
그러나, 해당 분야에서 알려진 바와 같이, 점대점 링크에 대한 통신을 구축하기 위해, PPP 링크의 각 종단(여기서는, TE2 PPP 프로토콜(406) 및 IWF PPP 프로토콜(426))은 우선 구축을 위한 링크 제어 프로토콜(LCP;Link Control Protocol) 패킷을 전송하고, 데이터 링크 연결을 구성 및 테스트해야 한다. 상기 링크가 LCP에 의해 구축된 후에, PPP 프로토콜(406)은 네트워크층 프로토콜(여기서는, TE2 IP 프로토콜(404) 및 IWF IP 프로토콜(425))을 구성하기 위해 네트워크 제어 프로토콜(NCP;Network Control Protocol) 패킷을 전송한다. 각 네트워크층 프로토콜이 구성된 후에는, 각 네트워크층 프로토콜로부터의 데이터그램은 그들 사이의링크를 통해 전송될 수 있다.
한 실시예에서, IP에 대한 NCP는 IP 제어 프로토콜(IPCP;IP Control Protocol)이다. IPCP는 "PPP 인터넷 프로토콜 제어 프로토콜(IPCP)"(1992년 5월 발간)라는 표제가 붙은 RFC 1332에 상세히 설명되어 있다. IPCP는 점대점 링크 중 어느 하나 에서 실행되는 TE2 IP 프로토콜(404) 및 IWF IP 프로토콜(425)의 구성, 활성화 및 비활성화를 조절한다. 이 기술분야에서 알려진 바와 같이, IPCP는 구성 요구를 사용하는데, 구성 요구는 IP 어드레스에 대한 구성 옵션을 포함하는 메시지들이다. 구성 요구 메시지의 이 구성 옵션 부분은 구성 요구의 전송자(여기서는 TE2 장치(102))에 의해 사용될 IP 어드레스를 협상하기 위한 방법을 제공한다. 그것은 구성 요구의 전송자로 하여금, IP 어드레스를 특정하므로써 어느 IP 어드레스가 요구되는지를 지정하거나, 피어(peer;여기서는, IWF(108))가 전송자에 대한 동적 IP 어드레스를 제공하도록 요구할 수 있도록 한다. 구성 요구의 전송자가 IP 어드레스 구성 옵션의 IP 어드레스 필드를 모두 0으로 설정하는 경우에는, 피어는 옵션에 대한 구성 NAK(negative acknowledgement)를 전송하고, 유효한 IP 어드레스를 반환하므로써, 동적 IP 어드레스를 제공할 수 있다. 반면에, 구성 요구의 전송자가 IP 어드레스 구성 옵션의 IP 어드레스 필드를 특정 IP 어드레스로 설정하는 경우에는, 피어는 상기 특정된 IP 어드레스가 옵션에 대한 구성 ACK를 전송하므로써 받아들여질 수 있음을 표시할 수 있다. 본 발명은 이동 노드 등록을 하는 동안 TE2 장치에 대한 프록시로서 역할을 할 것인지 또 언제 그 역할을 할 것인지를 결정하기 위해 TE2 장치(102) 및 IWF(108) 장치 사이의 IPCP 통신을 이용한다.
도 5는 도 3의 이동 IP 모드 상태(310)의 확장된 상태도를 설명한다. 이동성이 활성화되었는가?상태(304)(도 3)가 이동성 데이터 아이템이 비활성화되지 않았다고 결정하면, 그것은 PPP 모니터링 서브스테이트로 이동한다. 콜이 종료되는 경우에는, 도 5의 임의의 서브스테이트로부터 폐쇄 서브스테이트(516)로 이동할 수 있다는 것을 주목하여야 한다. 그러나, 간략함을 위해, 개방 서브스테이트(508)에서 폐쇄 서브스테이트(516)로의 콜 종료된 이동만이 설명된다.
PPP 서브스테이트(502)를 모니터링할 때, MT2 장치(104)는 RLP 프로토콜(412) 및 EIA-232프로토콜(410) 피어들 사이의 MT2 장치 프로토콜 스택에 네트워크 "마개(spigot)"를 삽입한다. 즉, EIA-232 프로토콜(410) 및 RLP 프로토콜(412) 사이를 통과하는 PPP 패킷은 MT2 장치(104)에 의해 모니터링 및 조사된다. 이것은 PPP 패킷들이 TE2 장치(102) 및 IWF(108) 사이를 통과할때, MT2 장치(104)가 PPP 패킷들을 모니터링할 수 있도록 해준다.
제1 LCP 패킷은 PPP 재동기화 시작 상태(504)에 관하여 아래에 설명될 바와 같이 내부-IWF 핸드오프 다음에 사용하기 위한 MT2 장치(104)에 의해 캐시된다. MT2 장치(104)는 TE2 장치(102) 및 IWF(108) 사이에서 교환되고 있는 PPP 패킷을, TE2 장치(102)로부터의 IPCP 패킷이 MT2 장치(104)에 의해 감지될 때까지 계속해서 모니터링한다. 이 IPCP 패킷은 구성 요구에 대한 IP 어드레스 구성 옵션에서 정적 또는 동적 IP 어드레스가 요구되고 있는지를 결정하기 위해 MT2 장치(104)에 의해 조사된다. IP 어드레스 필드가 모두 제로인 IP 어드레스를 갖는 경우에는, TE2 장치는 동적 어드레스를 요구한다. 그러한 경우에, TE2 장치(102)에 의한 이동 IP 써포트에 대한 요구는 없고 MT2 장치(104)는 단순 IP 모드(306)로 이동한다(도 3).
반면에, TE2 장치(102)에 의해 전송된 구성 요구의 IP 어드레스 필드가 정적(즉, 0이 아닌) IP 어드레스를 포함하는 경우에, MT2 장치(104)는 IPCP 모니터링 상태(506)로 이동한다. IPCP 모니터링 상태(506)에서, MT2 장치(104)는 TE2 장치(102) 및 IWF(108) 사이에서 교환되고 있는 IPCP 패킷을 모니터링한다. 상세하게 말하면, MT2 장치(104)는 TE2 장치(102)에 의한 IP 어드레스 요구가 구성 ACK와 함께 IWF(108)에 의해 받아들여 졌는지를 결정하기 위해 IPCP 패킷을 조사한다.
TE2 장치(102)에 의한 정적 IP 어드레스 요구가 IWF(108)에 의해 거부되는 경우에, MT2 장치(104)는 이동성?상태(514) 상태로 전환되고, 거기서 이동성 데이터 아이템(302)의 값을 체크한다. 이동성 데이터 아이템(302) 값이 "사용가능한 경우"인 경우에는, 이동 IP 써포트가 사용가능하지 않은 경우에는 사용자는 단순 IP 콜(즉, 동적으로 할당된 IP 어드레스)로 만족된다고 가정하였기 때문에,MT2 장치(104)는 단순 IP 모드 상태(306)로 전환된다(도 3). 그러나, 이동성 데이터 아이템(302) 값이 "배타적으로"인 경우에는, 사용자가 단순 IP 콜로 만족하지 않는다고 가정하였기 때문에 MT2 장치(104)는 폐쇄 상태(516)로 전환된다.
TE2 장치(102)에 의한 정적 IP 어드레스 요구가 IWF(108)에 의해 수락되는 경우에, IPCP 협상을 마친 후에 MT2 장치(104)는 이동 등록 상태(512)로 전환된다. 이동 등록 상태(512)에서, MT2 장치(104)는 PPP 프로토콜(415), IP 프로토콜(413), UDP 프로토콜(411) 및 이동 IP 프로토콜(409)을 시작한다. MT2 장치(104)는 TE2 장치(102)를 흐름제어(flow control)한다. 여기서 사용되는 "흐름제어"라는 용어는TE2 장치(102)가 그 릴레이층 인터페이스를 통해 데이터를 송신 및 수신하지 못하도록 하는 단계를 가리킨다. 도 4의 실시예에서, 이것은 TE2 장치의 EIA-232 프로토콜(408) 및 MT2 장치의 EIA-232 프로토콜(410) 사이의 링크이다. 소프트웨어 또는 하드웨어 흐름제어가 사용될 수 있다. 예를 들어, 한 실시예에서, MT2 장치(104)는 핀 전압들 중 하나를 MT2 장치(104) 및 TE2 장치(102) 사이에서 토글링(toggling)시킨다.
TE2 장치(102)를 흐름제어 하므로써, MT 장치(104), 보다 상세하게는 IP 프로토콜(413)은 이동 노드 등록을 하기 위한 IP-종점이 된다. 이것은 MT2 장치(104)가 TE2 장치(102)를 대표하여 TE2 장치(102)에 명백한 이동 노드 등록을 수행하도록 한다. 개념적으로, 이것은 IP-종점을 TE2 장치(102)로부터 "시프트" 시키고, 그렇지 않은 경우에는 MT2 장치(104)로 시프트시킨다.
MT2 장치(104)는 이동 노드 등록(MNR;Mobile Node Registration) 데이터 아이템(510)을 읽는다. 이 실시예에서, 이러한 데이터 아이템들은 적절한 비휘발성 메모리 회로(미도시)에 저장된다. 이러한 MNR 데이터 아이템(510)은 이동 노드 등록을 수행하는데 필요하다. 이러한 MNR 데이터 아이템(510)은 RFC 2002에 설명된 보증 파라미터 인덱스인 MD5 인증 키 및 홈 에이전트 IP 어드레스를 포함한다.
MT2 장치(104)는 TE2 장치(102) 및 MNR 데이터 아이템(510)에 의해 요구된 정적 IP 어드레스를 사용하여 RFC 2002에 설명된 이동 노드 등록을 수행한다. 이동 노드 등록에 대한 상세한 설명은 RFC에 나와 있으므로, 간략하게 설명하기로 한다. 간단히 말해서, 이동 IP 프로토콜(409)은 외부의 에이전트 간청(solicitation) 메시지를 IWF(108)의 이동 IP 프로토콜(421)로 전송한다. 이 외부 에이전트 간청 메시지는 UDP 프로토콜(411)로 전달된다. UDP 프로토콜(411)은 기술 분야에 아려진 바와 같은 데이터그램 서비스로서 동작하고, 외부 에이전트 간청 메시지를 IP 프로토콜(413)로 전달하며, 여기서 RFC 2002에 따라 브로드캐스트 어드레스 또는 "모든 라우터" 멀티캐스트 어드레스의 IP 헤더와 함께 패킷화된다.
IP 프로토콜(413)은 IP 패킷을, IP 패킷을 PPP 패킷으로 패킷화하고, Um 인터페이스를 통해 전달하기 위해 RLP 프로토콜(412) 및 IS-95 프로토콜(414)로 전달하는 PPP 프로토콜(415)로 전달한다. BS/MSC(106)의 보충적인 RLP 프로토콜(416) 및 IS-95 프로토콜(418)은 L 인터페이스를 통하여 릴레이층 프로토콜(428)로 전달하기 위하여 릴레이층 프로토콜(420)로 데이터를 전달한다.
PPP 프로토콜(426)은 수신된 PPP 패킷을 해제하고 그것을 IP 프로토콜(425)로 전달한다. IP 프로토콜(425)은 IP 헤더를 제거하고 상기 패킷을, 교대로 상기 패킷 해제된 외부 에이전트 간청 메시지를 이동 IP 프로토콜(421)로 전달하는 UDP 프로토콜(423)로 라우팅한다. 이동 IP 프로토콜(421)이 IWF(108)에 있는 경우에는, IWF(108)에 있는 외부 에이전트 실체가 있는 것이며, 그것은 MT2 장치(104)의 이동 IP 프로토콜(409)로의 역경로를 따라서 에이전트 광고 메시지로 응답한다.
이동 IP 프로토콜(409)은 이동 노드 등록 메시지를 IWF(108) 상의 외부 에이전트로 전송한다. 이동 노드 등록 메시지가 외부 에이전트로 수락될 수 있는 경우에, 외부 에이전트는 그 이동 노드 등록 메시지를 TE2 장치의 홈 IP 네트워크에 있는 홈 에이전트 실체(TE2 장치(102)에 의해 요구된 정적 IP 어드레스를 포함하는것)로 전달할 것이다.
이동 노드 등록 메시지가 홈 에이전트로 수락될 수 있는 경우에, 홈 에이전트는 외부 에이전트의 "캐어 오브" 어드레스를 이용하여 TE2 장치(102)에 대한 이동성 바인딩을 만들어 낸다. RFC 2002에 설명된 바와 같은 이동성 바인딩은 TE2 장치의 홈 네트워크에 도착한, TE2 장치(102)를 향하도록 의도된 임의의 IP 패킷들을 따라가서, 그것들을 IP 터널링을 사용하여 외부 에이전트로 전달하는 라우팅이다.
이동성 바인딩이 발생되었다는 홈 에이전트로부터의 통보를 수신하자 마자, 외부 에이전트는 터널화된 패킷의 내부 IP 어드레스(즉, TE2 장치(102)에 의해 요구된 정적 IP 어드레스) 및 MT2 장치(104)의 "전화번호" 사이의 합동 관계를 만들어 낸다. 여기서, "전화번호"라는 단어는 MT2 장치(104)의 식별 숫자를 표현하는 넓은 의미로 사용된다. 여기서 사용되는 것처럼, MT2 장치(104)의 이동 식별 번호(MIN;Mobile Identification Number), 그 전자 시리얼 번호(ESN;Electronic Serial Number) 또는 이 기술 분야에서 알려진 바와 같이, MT2 장치(104)가 BS/MSC(106)와 함께 등록한 다른 유일한 식별자를 가리키는 것으로 의도된다. IWF(108)는 IP를 MIN으로 또는 IP를 ESN으로의 번역을 유지한다.
이 이동 노드 등록을 수행하기 위해, 본 발명은 MT2 장치의 프로토콜 스택의 이동 IP 프로토콜(409) 레벨에서 실행되는 이동 노드 등록 소프트웨어에 선행 데이터 전달을 확실히 하기 위해서, RLP 프로토콜(412)로부터 MT2 PPP 프로토콜(415)까지 IP 패킷을 라우팅한다. MT2 PPP 프로토콜(415)은 RFC 1661에 설명된 바와 같은 완전한 PPP 구현은 아니라는 사실을 주목해야 한다. 도 4의 실시예에서, PPP는 앞서 설명한 바와 같이, 이미 TE2 장치(102) 및 IWF(108) 사이에서 이미 협상되었기 때문에 MT2 PPP 프로토콜(415)은 프로토콜 또는 링크 구축에 대한 어떠한 협상도 수행하지 않고, 틀을 만들고, 다시 해제하며 이동 등록 상태(512)동안에 임의의 요구된 MT2 장치(104)에 의해 송신 및 수신되는 IP 패킷으로부터의 문자 탈출을 수행한다.
위에 설명되고 이동 노드 등록 상태(512) 동안에 수행된 이동 노드 등록이 어떤 이유에서든 실패하면, 한 실시예에서 MT2 장치(104)는 이동 IP 프로토콜(409), UDP 프로토콜(411), IP 프로토콜(413) 및 PPP 프로토콜(415)을 퇴거(exit)시키고, 폐쇄 상태(516)로 전환된다. 실패의 원인으로 가능한 몇가지 이유들은 이동 노드 등록 메시지를 거부하는 외부 에이전트 또는 홈 에이전트를 포함한다. 다른 실시예들에서, MT2 장치(104)는 PPP를, TE2 장치에 의해 요구된 정적 IP 어드레스가 아닌 동적 IP 어드레스와 재동기화 하려는 시도를 한다.
그렇지 않으면, 이동 등록 상태(512)에서 이동 노드 등록을 성공하자마자, MT2 장치는 이동 IP 프로토콜(405), UDP 프로토콜(411), IP 프로토콜(413) 및 PPP 프로토콜(415)을 퇴거시키고 열림 상태(508)로 이동한다. 열림 상태(508)에서, MT2 장치(104)는 도 2에 도시된 바와 같이, IS-707.5 릴레이 모델에 따라 동작한다. 이 열림 상태(508)에서, MT2 장치(104)의 RLP 프로토콜(412)에 도착하는 데이터는 TE2 장치(102) 및 MT2 장치(104) 사이의 EIA-232 인터페이스를 통해 단지 전송될 뿐이다.
MT2 장치는 다음 세가지 중 하나, 즉 콜이 완료되거나 MT2 장치(104)가 다른IWF로 핸드오프되거나 또는 이동 등록 수명이 초과되는 경우 중 하나가 발생할 때까지 열림 상태(508)에 남아 있게 된다. 이 콜은 여러가지 방법으로 종료될 수 있다. 예를 들어, 사용자는 MT2 장치(104) 상의 "종료"키(미도시) 또는 이와 유사한 것을 눌러서 의도적으로 데이터 콜을 중지시킬 수 있다. 또다른 예는 TE2 장치(102) 또는 IWF(108)가 단독으로 그들 사이의 PPP 세션을 끝내는 것이다. 또다른 예에서는, 데이터 콜은 단지 MT2 장치(104) 및 BS/MSC(106) 사이의 라디오 링크가 나빠져서 콜이 중단되는 것이다. 콜이 이러한 방법들 중 하나도 종료된 경우에는, MT2 장치(104)는 폐쇄 상태(516)로 이동한다.
폐쇄 상태(516)에서, MT2 장치(104)는 여전히 제자리에 있는 경우에는, 이동 IP 프로토콜 스택(이동 IP 프로토콜(409), UDP 프로토콜(411), IP 프로토콜(413) 및 PPP 프로토콜(415))을 중단시키는데 필요한 하우스키핑 펑션을 수행한다. 추가적으로, MT2 장치(104)는 제자리에 있는 경우에는 네트워크 "마개"(417)를 제거한다. 마지막으로, 임의의 적당한 사용자 통보 메시지는 (예컨대 사용자 인터페이스(미도시)에) 디스플레이 되거나 또는 이동 IP 등록 과정이 성공적이지 않았다는 것을 표시하기 위해 사용자에게 전달된다. 선택적으로, 어떤 실패가 발생하였는가 및 그 원인(알고 있다면)에 대한 보다 상세한 설명 또한 디스플레이 될 것이다. 어떤 통보를 하고 하우스키핑 청소를 완료한 후에, MT2 장치(104)는 폐쇄 상태(308)로 이동한다(도 3).
양자택일적으로, 열림 상태(508)에 있는 동안, MT2 장치(104)는 다른 BS/MSC(106)으로 핸드오프될 수 있다. 통상적으로, 이것은 한 지리적 위치에서 원래 BS/MSC(106)의 서비스 영역 바깥에 있는 다른 위치로 이동할 때 발생할 것이다. 두개의 BS/MSC들이 동일한 IWF(108)에 의해 서비스되지 않는 경우에는, IWF간 핸드오프가 발생한다. MT2 장치(104)는 IS-95 패킷 존 ID를 조사하거나, 시스템 증명(SID;System Identification) 또는 네트워크 증명(NID;Network Identification)내의 변화를 주목하므로써 이것을 감지할 수 있다. 어떤 경우든, MT2 장치(104)는 PPP 재동기화 시작 상태(504)로 이동할 것이다. PPP 재동기화 시작 단계(504)에서, MT2 장치(104)는 위에 설명된 바와 같이 PPP 협상을 시작할때 캐시된 처음 LCD 패킷을 전송하므로써 IWF(108)와의 PPP 재동기화를 시작한다. 이것은 IWF(108)로부터의 반응에 있어서 LCD 패킷의 교환을 호소한다. LCD 패킷의 교환을 감지하자마자, MT2 장치는 위에 설명된 바와 같이 이전의 PPP 모니터링 상태(502)로 이동한다.
반면에, 열림 상태(508) 동안에 RFC 2002에 정의된 이동 등록 수명이 초과되는 경우에, 위에 설명한 바와 같이 MT2 장치(104)는 이동 노드 등록을 재협상하기 위해 직접 이전의 이동 등록 상태(512)로 이동한다.
따라서, 도 4의 실시예에서, MT2 장치(104)의 추가적인 프로토콜층들(PPP 프로토콜(415),IP 프로토콜(413), UDP 프로토콜(411) 및 이동 IP 프로토콜(409))은 이동 등록 상태(512)에서 이동 노드 등록을 수행하기 위해서만 사용되며, 이동 등록 상태(512)를 떠난 후에는 동작하지 않는다. 이 추가적인 프로토콜층이 사용되는 동안의 모든 IP 트래픽은 MT2 장치(104)에서 시작 및 종료된다. 개념적으로, 이것은 이동 노드 등록 동안 TE2 장치(102)로부터 IP 종점을 "시프트"시키고, 이동 노드 등록을 완료한 후에 TE2 장치(102)로 되돌아 간다. 이런 식으로, MT2 장치(104)는 이동 노드 등록 동안 TE2 장치(102)에 대한 프록시로서 서비스하며, 자기 자신의 IP 이동성 써포트를 갖기 위해 TE2 장치(102)에 대한 필요성을 미연에 방지해 준다.
도 6은 본 발명의 대체적인 실시예의 각 실체의 프로토콜 스택에 대한 다이어그램이다. 도 6 및 도 4 사이의 중요한 차이점은 도 6의 실시예에서, MT2 장치(104) 및 TE2 장치(102) 사이에 PPP 레벨에서의 피어 관계가 존재한다는 것이다. MT2 장치(104)의 PPPR 프로토콜(605)이 TE2 장치(102)의 PPPR 프로토콜(606)에 대한 종점으로서의 역할을 하고 있는 것을 주목할 것. 또한 IWF(108)의 PPPU 프로토콜(626)이 MT2 장치(104)의 PPPU 프로토콜(615)에 대한 종점으로의 역할을 하고 있는 점도 주목할 것. 도 4의 실시예와 대조적으로, 이러한 PPPR 및 PPPU 링크는 이동 노드 등록 후에 MT2 장치(104)에서 살아남는다.
도 6의 동작은 도 7의 상태도를 참조하여 설명될 것이다. 도 7은 도 3의 이동 IP 모드(310)에 대한 대체적인 실시예의 상태도이다. MT2 장치(104)는 PPPR 모니터링 상태(702)에서 시작한다. MT2 장치(104)는 PPPR 프로토콜(605)을 시작하고 MT2 장치(104) 및 TE2 장치(102) 사이의 PPPR 링크를 협상한다.
MT2 장치(104)는 또한 필요한 경우에는 나중에 PPP 재동기화에서 사용될 TE2 장치에서 수신된 제1 LCP 패킷을 캐시한다.
MT2 장치(104)는 TE2 장치의 IPCP 구성 요구를 찾는 PPPR 링크를 계속해서 모니터링한다. TE2 장치의 IPCP 구성 요구를 감지하자마자, MT2 장치(104)는 IP 어드레스 필드를 조사한다. 요구된 IP 어드레스가 동적인 경우, 즉 모두 0인 경우에는 , MT2 장치(104)는 PPP의 재동기화 시작 단계(704)로 이동한다.
PPP의 재동기화 시작 단계(704)에서, MT2 장치(104)는 PPPR 프로토콜(605)의 동작을 멈추게 하고 (PPPR 모니터링 상태(702)에서 이미 캐시된)원래의 LCP 패킷을 IWF(108)로 전달하여, TE2 장치(102) 및 IWF(108) 사이에서 직접 PPP 링크를 시작한다. 이것은 단순 IP 콜에 대한 MT2 장치(104) 상에서 PPPR 프로토콜(605) 및 PPPU 프로토콜(615) 실행의 오버헤드를 피하기 위해 행해진다. 동적 어드레스가 요구되었기 때문에, MT2 장치(104)에서의 여분의 PPP층은 불필요하고, 도 2의 보통 IS-707.5 릴레이 모델이 적용된다.
그러나, TE2 장치의 IPCP 구성 요구가 정적 IP 어드레스를 포함하는 경우에는, MT2 장치(104)는 PPPR 링크가 PPPR 모니터링 상태(702)에서 완전히 협상이 끝난 다음 PPPU 협상 단계(706)로 이동한다. PPPU 협상 단계(706)에서, MT2 장치(104)는 이동 IP 프로토콜(609), UDP 프로토콜(611), IP 프로토콜(613) 및 PPPU 프로토콜(615)을 포함하는 MT2 프로토콜 스택에서 추가적인 층들을 시작한다. MT2 장치(104)는 또한 TE2 장치(102)를 흐름 제어 한다. 다시, 흐름 제어는 TE2 장치(102)가 Rm 인터페이스를 통해 어떠한 데이터도 송신하거나 수신하지 못하도록 하는 것을 가리킨다.
MT2 장치(104)는 PPPU 프로토콜(615) 및 PPPU 프로토콜(626) 사이의 PPPU 링크를 협상한다. PPPU 링크 협상에서, MT2 장치(104)는 PPPR 링크의 협상 동안 TE2 장치(102)에 의해 요구된 것과 같은 파라미터들을 사용한다. 상세하게는, MT2장치(104)로부터 TE2 장치(102)에 의해 요구된 정적 IP 어드레스는 IWF(108)와 PPPU 링크를 협상할때 MT2 장치(104)에 의해 사용된다.
PPPU 링크 협상 동안에, MT2 장치(104)는 IWF(108)에 의해 반환된 IPCP 패킷을 모니터링한다. 정적 IP 어드레스를 포함하는 IPCP 구성 요구가 IWF(108)에 의해 거절되는 경우에, MT2 장치(104)는 이동성 모드?상태(708)로 이동한다.
이동성 모드?상태(708)에서, 이동성 데이터 아이템(302)이 체크된다. 이동성 데이터 아이템(302) 값이 "사용가능한 경우"인 경우에, MT2 장치(104)는 단순 IP 모드(306)에서의 단순 IP 콜 시도에 대한 준비 단계에서, PPP의 재동기화 시작 상태(704)로 이동한다. 이동성 데이터 아이템(302) 값이 "이동 IP 배타적으로"인 경우에는, MT2 장치(104)는 폐쇄 상태(710)로 이동한다. 폐쇄 상태(710)는 동작에 있어서 도 5의 폐쇄 상태(516)와 유사하다.
정적 IP 어드레스를 포함하는 IPCP 구성 요구가 IWF(308)에 의해 수락된 경우에, MT2 장치(104)는 이동 등록 상태(712)로 이동한다. 이동 등록 상태(712)에 들어가자 마자 시스템의 상태는, TE2 장치(102)의 관점에서 볼때, MT2 장치(104)의 IP 어드레스는 IWF(108)의 어드레스인 것으로 보인다. 또한, IWF(108)의 관점에서 볼때, MT2 장치(104)의 IP 어드레스는 TE2 장치(102)의 IP 어드레스인 것으로 보인다. 다른 말로 하면, MT2 장치(104)는 PPPR 프로토콜(605) 및 PPPU 프로토콜(615) 사이의 두개의 IP 어드레스를 유지하고 있다. 결과적으로, MT2 장치(104)는 IP 어드레스에 상관없이 PPPR 프로토콜(605) 및 PPPU 프로토콜(615) 사이로 PPP 패킷을 전달한다.
이동 등록 상태(712)는 몇가지 중요한 예외를 제외하고는 도 5의 이동 등록 상태(512)와 매우 유사하다. 첫째, 이동 등록 상태(712)에서 이동 등록 패킷은 PPPU 프로토콜(615)에서 PPPR 프로토콜(605)이 아닌 IP 프로토콜(613)로 전달된다. 이것은 이동 등록 패킷의 라우팅이 MT2 프로토콜 스택에서 한층 높은 곳에서 발생한다는 점에서 도 4 및 5의 동작과는 다르다. 둘째, PPPU 프로토콜(615)이 MT2 장치(104) 및 IWF(108) 사이의 PPP 링크를 종료시키는 역할을 하기 때문에, 도 6의 실시예에서 아무런 네트워크 마개도 필요치 않다. 결과적으로, IWF(108)과의 협상 동안에 교환되는 PPP 패킷들은, 도 4 및 도 5에서의 실시예에 관한 경우와 마찬가지로 MT2 장치(104)가 TE2 장치(102) 및 IWF(108) 사이의 PPP 협상에 대해 "엿듣기(eavesdrop)" 보다는 MT2 장치(104) 그 자신과 함께 발생 및 종료된다.
이동 노드 등록이 이동 등록 상태(712)에서 성공한 경우에, MT2 장치(104)는 열림 상태(714)로 이동한다. 열림 상태(714)는 도 5의 열림 상태(508)와 매우 유사하다. 도 7 및 도 5의 실시예 사이의 중요한 차이점은 PPPR 프로토콜(605) 및 PPPU 프로토콜(615)이 열림 상태(714) 동안에 제자리에 남아 있는 다는 사실이다. 결과적으로, Um 인터페이스를 통해 MT2 장치에 도착하는 IP 패킷들은, EIA-232 프로토콜(610)로 직접 라우팅되는 것이 아니고, RLP 프로토콜(612)에 의해 PPPU 프로토콜(615)로 라우팅되고, 교대로 PPPR 프로토콜(605) 및 EIA-232 프로토콜(610)로 라우팅된다. 마찬가지로, Rm 인터페이스를 통해 MT2 장치(104)에 의해 수신되는 모든 IP 패킷들은, RLP 프로토콜(612)로 직접 라우팅되는 것이 아니고, EIA-232 프로토콜(610)에 의해 PPPR 프로토콜(605)로 라우팅되고, 교대로 PPPU프로토콜(615) 및 RLP 프로토콜(612)로 라우팅된다.
IWF간 핸드오프가 열림 상태(714) 동안에 발생하는 경우에, MT2 장치(104)는 PPP 재동기화 시작 상태(709)로 이동한다. PPP 재동기화 시작 상태(709)는 PPP 재동기화 시작 상태(504)와 유사하게 동작한다. 그러나, PPP 재동기화 시작 상태(709)에서, PPPR 링크가 아닌 PPPU 링크만 재협상된다. 결과적으로, PPPR 링크는 변하지 않고 IWF간 핸드오프를 TE2 장치(102)에 투명하게 만들어 캐시된 LCP 패킷이 필요 없도록 한다.
콜이 열림 상태(714)(또는 도 7의 임의의 다른 상태)에 있는 동안 종료된 경우에, MT2 장치(104)는 폐쇄 상태(710)로 이동한다. 폐쇄 상태(710)는 도 5의 폐쇄상태(516)와 매우 유사하다. 그러나, 폐쇄 상태(710)에서는, 제거 되어야할 네트워크 마개가 없다. 추가적으로, 콜 종료 타이밍에 따라, 협상 중에 있는 몇몇 PPP 예제들이 남아 있다. 어떤 경우든, MT2 장치(104)는 이동 IP 프로토콜(609), UDP 프로토콜(611), IP 프로토콜(613), PPPR 프로토콜(605) 및 PPPU 프로토콜(615)을, 현재 작동 중인 경우에는 그 작동을 정지시킨다. 도 5의 실시예에서와 같이, 콜 실패의 원인은 선택적으로 디스플레이 될 수 있다.
따라서, 도 6의 실시예에서, MT2 장치(104)의 추가적인 프로토콜층들(아래로 이동 IP 프로토콜(609), UDP 프로토콜(611) 및 IP 프로토콜(613))이 이동 등록 상태(712)에서의 이동 노드 등록을 수행하기 위해 사용되고, 이동 등록 상태(712)를 떠난 후에는 그 동작을 멈춘다. 그러나, PPPR 프로토콜(605) 및 PPPU 프로토콜(615)은 열림 상태(714) 동안에 변하지 않는다. 이런 식으로, MT2장치(104)는 이동 노드 등록 동안에 TE2 장치(102)에 대한 프록시로서의 역할을 하여, TE2 장치(102)가 그 자신의 IP 이동성 써포트를 가질 필요를 미연에 방지해 준다.
위의 설명은 연결된 단말 장치를 대표하는 프록시 서비스를 제공하기 위한 IP 어드레스 시프팅의 사용에 대한 예제를 제공한다. 이동 IP 등록 외에 본 발명의 IP 어드레스 시프팅 방법에 대한 추가적인 응용예들이 있다. 본 발명의 IP 어드레스 시프팅 방법은 임의의 프록시 서비스 또는 하나의 IP 어드레스를 공유하여야 하는 임의의 두개의 네트워크 장치에 대해서도 사용될 수 있다. 예를 들어, 본 발명은 TE2 장치(102)가 능동 데이터 서비스 콜(즉, TE2 장치(102)의 사용자가 멀리서 이메일을 체크하기 위해 다이얼인 하는 경우)에 있는 경우와 MT2 장치(104)가 IP 패킷들(예컨대, 웹-브라우저 애플리케이션)을 송신 또는 수신하여야 하는 실행중인 애플리케이션을 갖고 있는 경우 MT2 장치(104)와 TE2 장치(102) 사이에서 사용될 수 있다.
본 발명의 독특한 면은 MT2 장치(104) 및 TE2 장치(102)에 사용될 수 있는 IP 어드레스가 단 하나인 시스템의 프록시 서비스에 대한 기술을 제공한다는 점이다. 예를 들어, IS-707.5의 네트워크 및 릴레이 모델은 하나의 IP 어드레스를 TE2 장치(102)로 할당하는 것을 암시하고 있다. 어떤 별개의 설비도 MT2 장치(104)의 배타적인 사용을 위한 제2 IP 어드레스의 할당을 위해 제공될 필요 없다. 정말로, 현재는 PPP 세션당 하나 이상의 IP 어드레스를 얻는 것이 불가능하다. 이동 세션 당 다수의 PPP를 써포트하기 위한 IWF(108)내의 자원의 추가적인 손실이 서비스 공급자들에게는 별로 매력적이지 못하다.
IP 어드레스가 단 하나만 TE2 장치(102)에 할당된다는 사실은 또한 IP 어드레스를 필요로 하는 MT2 장치(104) 상에서 실행되는 다른 어떠한 애플리케이션도, 프록시 서비스에 대한 것이건 아니건 간에, TE2 장치(102)에 할당된 IP 어드레스를 "공유"해야 한다는 사실을 암시한다. 이 IP 어드레스 시프팅을 수행하기 위한 한 방법이 위에 설명되어 있고 도 8의 흐름도에 도시되어 있다. 도 8의 방법은 도 4 및 도 6을 참조하여 위에 설명된 시스템에 의해 수행될 수 있다.
도 8의 프로세스는 MT2 장치(104) 상에서 실행되는 임의의 애플리케이션이 IP 패킷을 발생시킬 필요가 있는지의 결정 단계(802)에서 시작된다. 예를 들어, 도 4의 이동 IP 애플리케이션(409) 또는 도 6의 (609)는 이동 IP 노드 등록을 위한 프록시로서 그 기능을 수행할 IP 패킷을 발생시켜야 한다. IP 패킷을 발생시켜야 하는, MT2 장치(104) 상에서 실행되는 애플리케이션의 또다른 예로 웹 브라우저를 들수 있다. 특히 MT2 장치(104)가 컴퓨터/전화(또는 "스마트폰")인 경우에, MT2 장치(104) 상에서 실행되고 있는 IP 패킷 서비스들을 사용하는 많은 다른 애플리케이션들이 있다.
MT2 장치(104)는 블록(804)에서 TE2 장치(102)로부터의 출력 IP 패킷들을 차단한다. 이것은 TE2 장치(102)를 "흐름 제어"하는(즉, TE2 장치(102)가 그 릴레이층 인터페이스를 통해 데이터를 송신 및 수신하지 못하도록 하는) MT2 장치(104)에 의해 위에 설명된 대로 수행된다. 예를 들어, 도 4의 실시예에서, TE2 장치(102)의 EIA-232 프로토콜(408) 및 MT2 장치(104)의 EIA-232 프로토콜(410) 사이의 링크는MT2 장치(104)에 의해 흐름 제어된다. 소프트웨어 또는 하드웨어 흐름 제어가 사용될 수 있다. 예를 들어, 한 실시예에서, MT2 장치(104)는 MT2 장치(104) 및 TE2 장치(102) 사이의 핀 전압들 중 하나를 토글링한다.
TE2 장치(102)를 흐름제어 하므로써, MT2 장치(104), 상세하게는 IP 프로토콜(413)은 이제 이후의 IP 패킷을 송신 또는 수신할 목적으로 IP-종점이 된다. 개념적으로, 이것은 TE2 장치(102)에서, 그렇지 않으면, MT2 장치(104)로 IP-종점을 "시프트"시킨다. 따라서, 블록(806)에서 MT2 장치(104)는 원래 TE2 장치(102)에 할당된 IP 어드레스를 사용하여 IP 패킷들을 송신 및 수신한다.
본 발명의 IP 어드레스 시프팅 방법의 제1 실시예에서, TE2 장치(102)를 향하도록 의도된 IP 패킷들은 블록(808)에서 MT2 장치(104)에 의해 버려진다. 이것은 MT2 장치(104) 상에서 실행되고 있는 임의의 애플리케이션에 의해 무시되는 IP 패킷만에 의해서 발생할 수 있다.
본 발명의 IP 어드레스 시프팅 방법에 대한 제2 실시예는 도 9A-9B에 설명되어 있다. 이 제2 실시예에서, IP 어드레스는 TE2 장치(102)를 흐름제어하지 않고, 패킷 단위로(packet-by-packet) MT2 장치(104) 및 TE2 장치(102) 사이에서 개념적으로 시프트된다. 도 9A-9B의 방법은 도 4 및 6을 참조하여 위에서 설명된 시스템들에 의해 수행된다.
블록(902)에서, MT2 장치(104)는 인바운드 IP 패킷의 포트 번호를 조사한다. 위에 언급된 대로, 포트 번호는 TCP 또는 UDP와 같은 전달층 프로토콜에 의해 할당된다. 따라서, 두개의 IP 패킷이 동일한 IP 목적지 어드레스를 갖고 있기는 하지만, 그들의 포트 번호가 다르다. 이 기술분야에 공지된 바와 같이, 동일한 장치 또는 다른 장치 상에서 실행되는 다른 애플리케이션들은 포트 번호가 다를 수 있다. 블록(902)에서 인바운드 IP 패킷의 포트 번호를 조사하는 것은 IP 패킷을 조사하기 위해 PPP 패킷의 틀을 해제하는 것을 포함한다. 예를 들어, 도 6에 설명된 네트워크 모델에서, PPPU 프로토콜(615)은 IWF(108)로부터 들어오는 PPP 패킷의 틀을 해체할 것이다. MT2 장치(104)는 IP 패킷의 포트 번호를 조사할 것이다. 교대로, 그것은 소정의 비트수에 의해 IP 패킷으로 단지 인덱싱하는 것도 포함한다. PPP 헤더들, IP 헤더들의 길이 및 IP 패킷 내의 포트 번호의 위치는 다양한 표준에 따라 잘 정의되어 있다.
결정단계(904)에서, MT2 장치(104)는 IP 패킷이 MT2 장치(104)상에서 실행되고 있는 애플리케이션에 의해 사용되고 있는 포트 번호를 포함하는지를 결정한다. 예를 들어, MT2 장치(104)가 인터넷 브라우저 애플리케이션을 실행시키고 있는 경우에, 그 브라우저 애플리케이션은 특정 포트번호 예컨대 포트(200)를 사용할 것이다. IP 패킷 내의 포트 번호도 포트(200)이라면, IP 패킷은 MT2 장치(104) 상에서 실행되는 예제 애플리케이션에 의해 사용되고 있는 포트 번호를 포함한다. 그러나, 이 IP 패킷의 포트 번호가 200이 아니라면, IP 패킷은 MT2 장치(104) 상에서 실행되고 있는 예제 애플리케이션에 의해 사용되고 있는 포트 번호를 포함하지 않을 것이다.
IP 패킷의 포트번호가 MT2 장치(104) 상의 애플리케이션에 의해 사용되고 있는 것인 경우에는, 상기 흐름은 MT2 장치(104)가 IP 패킷을 MT2 장치(104)로 라우팅하는 블록(906)까지 진행한다. 그러나, IP 패킷의 포트 번호가 MT2 장치(104) 상의 애플리케이션에 의해 사용되지 않고 있는 경우에는, 상기 흐름은 MT2 장치(104)가 IP 패킷을 TE2 장치(102)로 라우팅하는 블록(908)까지 진행한다. 이것은 PPP 패킷을 재구조화하는 것과 그것을 Rm 링크를 통해 TE2 장치(102)까지 전송하는 것을 포함한다. 도 6에 설명된 네트워크 모델 실시예에서, 이것은 PPPR 프로토콜(605)에 의해 수행될 것이다. 이런 식으로, MT2 장치(104)는 MT2 장치(104)상에서 실행 중인 애플리케이션으로 향하는 모든 IP 패킷들을 중간에서 가로채어 프로세싱하고, 이밖의 IP 패킷들은 TE2 장치(102)로 전달한다. 따라서, IP 패킷은 아무것도 MT2 장치(104)에 의해 버려지지 않고, TE2 장치(102)는 흐름-제어되지 않는다.
MT2 장치(104)상의 애플리케이션이 도 9B의 결정 단계(910)에서 결정된 대로 IP 패킷들을 발생시킬 필요가 있는 경우에, MT2 장치(104) 애플리케이션은 블록(912)에서 TE2 장치(102)에 할당된 IP 어드레스를 사용하여 IP 패킷들을 발생시킨다. 어느 경우든, 흐름은, MT2 장치(104)가 IP 패킷을 발생시킬 필요가 있는지를 계속 결정하는 블록(910)으로 돌아간다. 따라서, MT2 장치(104)는 패킷 단위로 TE2 장치(102)에 할당된 IP 어드레스를 공유한다.
바람직한 실시예에 대한 앞의 설명은 기술 분야의 당업자로 하여금 본 발명을 사용할 수 있도록 하기 위한 것이다. 당업자들에 의해 이러한 실시예들에 다양한 변형이 쉽게 가해질 수 있고, 여기에 정의된 기본적인 원리들은 본 발명의 범위를 벗어나지 않고 다른 실시예들에 적용될 수 있다. 따라서, 본 발명은 여기에 소개된 실시예들에 제한되지 않고 원리들 및 여기에 개시된 신규한 특징들과 일치하는 최대 범위를 포함한다.

Claims (12)

  1. 제1 네트워크화된 장치 및 제2 네트워크화된 장치 사이에서 인터넷 프로토콜(IP) 주소를 공유하기 위한 방법으로서, 상기 방법은,
    제1 네트워크화된 장치에서 수신된 IP 패킷의 포트 번호를 조사하는 단계;
    상기 제1 네트워크화된 장치에서, 상기 수신된 IP 패킷의 상기 포트 번호가 상기 제1 네트워크화된 장치 상의 애플리케이션이 대응하는 경우에는, 상기 IP 패킷을 상기 애플리케이션으로 라우팅하는 단계; 및
    상기 IP 패킷의 상기 포트 번호가 상기 애플리케이션에 대응하지 않는 경우에는, 상기 제1 네트워크화된 장치로부터 상기 제2 네트워크화된 장치로 상기 IP 패킷을 라우팅하는 단계를 포함하는 것을 특징으로 하는 IP 어드레스 공유 방법.
  2. 제1항에 있어서, 상기 제1 네트워크화된 장치로부터, 개시(origination) 어드레스로 상기 제2 네트워크화된 장치에 할당된 IP 어드레스를 포함하는 IP 패킷을 발생시키는 단계를 더 포함하는 것을 특징으로 하는 IP 어드레스 공유 방법.
  3. 제2항에 있어서, 상기 제1 네트워크화된 장치에서, 상기 제1 네트워크화된 장치 상의 애플리케이션이 IP 패킷을 전송할 필요가 있는지를 결정하는 단계를 더 포함하는 것을 특징으로 하는 IP 어드레스 공유 방법.
  4. 제1 네트워크 장치 및 제2 네트워크 장치 사이에서 인터넷 프로토콜(IP)을 시프팅(shifting)하는 방법으로서, 상기 방법은,
    상기 제1 네트워크화된 장치에서, 상기 제2 네트워크화된 장치에서 만들어져서 전송된 IP 패킷을 차단하는 단계; 및
    상기 제1 네트워크화된 장치로부터, 개시 어드레스로서 상기 제2 네트워크화된 장치에 할당된 IP 어드레스를 포함하는 IP 패킷을 발생시키는 단계를 포함하는 것을 특징으로 하는 IP 어드레스 시프팅 방법.
  5. 제4항에 있어서, 상기 제1 네트워크화된 장치에서, 상기 제1 네트워크화된 장치 상의 애플리케이션이 IP 패킷을 송신 및 수신할 필요가 있는지를 결정하는 단계를 더 포함하는 것을 특징으로 하는 IP 어드레스 시프팅 방법.
  6. 제5항에 있어서, 상기 제1 네트워크화된 장치에서, 상기 제2 네트워크화된 장치로 어드레싱된 수신된 IP 패킷들을 버리는(discard) 단계를 더 포함하는 것을 특징으로 하는 IP 어드레스 시프팅 방법.
  7. 네트워크화된 장치로서,
    수신된 IP 패킷의 포트 번호를 조사하기 위한 수단;
    상기 수신된 IP 패킷의 포트 번호가 상기 애플리케이션에 대응하는 경우에, 상기 IP 패킷을 상기 네트워크화된 장치 상의 애플리케이션으로 라우팅하기 위한수단; 및
    상기 수신된 IP 패킷의 포트 번호가 상기 애플리케이션에 대응하지 않는 경우에, 별도의 네트워크화된 장치로 상기 IP 패킷을 라우팅하기 위한 수단을 포함하는 것을 특징으로 하는 네트워크화된 장치.
  8. 제7항에 있어서, 상기 네트워크화된 장치로부터, 시작 어드레스로 상기 별도의 네트워크화된 장치에 할당된 IP 어드레스를 포함하는 IP 패킷을 발생시키기 위한 수단을 더 포함하는 것을 특징으로 하는 네트워크화된 장치.
  9. 제8항에 있어서, 상기 네트워크화된 장치 상의 애플리케이션이 IP 패킷들을 발생시킬 필요가 있는지를 결정하기 위한 수단을 더 포함하는 것을 특징으로 하는 네트워크화된 장치.
  10. 네트워크화된 장치로서,
    별도의 네트워크화된 장치에서 발생하는 전송된 IP 패킷을 차단하기 위한 수단; 및
    상기 네트워크화된 장치로부터, 개시 어드레스로 상기 별도의 네트워크화된 장치에 할당된 IP 어드레스를 포함하는 IP 패킷을 발생시키기 위한 수단을 포함하는 것을 특징으로 하는 네트워크화된 장치.
  11. 제10항에 있어서, 상기 제1 네트워크화된 장치가 IP 패킷들을 발생시킬 필요가 있는 지를 결정하기 위한 수단을 더 포함하는 것을 특징으로 하는 네트워크화된 장치.
  12. 제11항에 있어서, 상기 네트워크화된 장치에서, 상기 별도의 네트워크화된 장치로 어드레싱된 수신된 IP 패킷들을 버리기 위한 수단을 더 포함하는 것을 특징으로 하는 네트워크화된 장치.
KR1020017005236A 1998-10-26 1999-10-26 공통 ip 어드레스를 갖는 이동 단말 및 무선 장치 KR100897239B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17922698A 1998-10-26 1998-10-26
US09/179,226 1998-10-26

Publications (2)

Publication Number Publication Date
KR20010090597A true KR20010090597A (ko) 2001-10-18
KR100897239B1 KR100897239B1 (ko) 2009-05-14

Family

ID=22655738

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020017005236A KR100897239B1 (ko) 1998-10-26 1999-10-26 공통 ip 어드레스를 갖는 이동 단말 및 무선 장치

Country Status (10)

Country Link
EP (1) EP1125418B1 (ko)
JP (3) JP4477239B2 (ko)
KR (1) KR100897239B1 (ko)
CN (1) CN1157032C (ko)
AU (1) AU1235300A (ko)
BR (1) BRPI9914806B1 (ko)
CA (2) CA2348030C (ko)
DE (1) DE69935863T2 (ko)
HK (1) HK1040850A1 (ko)
WO (1) WO2000025497A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100464038B1 (ko) * 2002-11-13 2004-12-31 엘지전자 주식회사 이동통신 단말기의 통신 프로토콜 세션 공유 방법
KR100886550B1 (ko) * 2002-09-17 2009-03-02 삼성전자주식회사 아이피 어드레스 할당 장치 및 방법

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6377556B1 (en) * 1999-07-14 2002-04-23 Qualcomm Incorporated Method and apparatus to resynchronize ppp on um interface without affecting ppp on a rm interface and to resynchronize ppp on a rm interface without affecting ppp on a um interface
WO2002028052A2 (en) * 2000-09-28 2002-04-04 Koninklijke Philips Electronics N.V. Wireless network interface
KR100459439B1 (ko) * 2002-10-18 2004-12-03 엘지전자 주식회사 통합 웹 브라우징 서비스 장치 및 방법
US7782878B2 (en) * 2004-08-16 2010-08-24 I2Telecom Ip Holdings, Inc. System and method for sharing an IP address
US8265005B2 (en) * 2006-03-06 2012-09-11 Qualcomm Incorporated Method and apparatus for communicating with a wireless network using a single address for multiple processors
US7849252B2 (en) * 2008-05-30 2010-12-07 Intel Corporation Providing a prefix for a packet header
CN106533536B (zh) * 2016-11-07 2019-07-26 北京航空航天大学 极地轨道低轨道卫星网络ip编址方法及装置

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05327712A (ja) * 1991-08-09 1993-12-10 Nec Corp 端末アダプタ
US5708655A (en) * 1996-06-14 1998-01-13 Telefonaktiebolaget L M Ericsson Publ Method and apparatus for addressing a wireless communication station with a dynamically-assigned address
JPH10257085A (ja) * 1997-03-14 1998-09-25 Toshiba Corp データ通信システム装置、接続端末装置及びサーバ装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100886550B1 (ko) * 2002-09-17 2009-03-02 삼성전자주식회사 아이피 어드레스 할당 장치 및 방법
KR100464038B1 (ko) * 2002-11-13 2004-12-31 엘지전자 주식회사 이동통신 단말기의 통신 프로토콜 세션 공유 방법

Also Published As

Publication number Publication date
CA2660174A1 (en) 2000-05-04
DE69935863D1 (de) 2007-05-31
JP4886022B2 (ja) 2012-02-29
CN1157032C (zh) 2004-07-07
EP1125418A1 (en) 2001-08-22
JP2010109987A (ja) 2010-05-13
JP2010114905A (ja) 2010-05-20
KR100897239B1 (ko) 2009-05-14
JP2002529021A (ja) 2002-09-03
EP1125418B1 (en) 2007-04-18
AU1235300A (en) 2000-05-15
BRPI9914806B1 (pt) 2015-07-28
HK1040850A1 (en) 2002-06-21
WO2000025497A1 (en) 2000-05-04
CA2660174C (en) 2012-10-23
JP4477239B2 (ja) 2010-06-09
DE69935863T2 (de) 2008-01-17
JP4856233B2 (ja) 2012-01-18
BR9914806A (pt) 2002-02-13
CA2348030A1 (en) 2000-05-04
CN1331878A (zh) 2002-01-16
CA2348030C (en) 2011-01-25

Similar Documents

Publication Publication Date Title
KR100709929B1 (ko) 프록시 이동 노드 등록을 이용하는 ip 이동성 지원
KR100606619B1 (ko) 무선 통신 네트워크에서 이동ip 등록의 자동 호출
US6424639B1 (en) Notifying a mobile terminal device of a change in point of attachment to an IP internetwork to facilitate mobility
JP4856233B2 (ja) 共通ipアドレス付きの移動端末および無線装置
US6973088B2 (en) PPP link negotiation in mobile IP systems
KR100893838B1 (ko) 점 대 점 프로토콜 (ppp) 세션 요청 동안의 채널최적화를 위한 방법 및 장치
KR101035817B1 (ko) 무선 인터넷 서비스를 위한 이동 단말의 인터넷 주소 형성방법
Kammann Proposal for a mobile service control protocol
MXPA01004107A (en) A mobile terminal and wireless device with common ip address

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E902 Notification of reason for refusal
E902 Notification of reason for refusal
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: 20130429

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20140430

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20160330

Year of fee payment: 8

FPAY Annual fee payment

Payment date: 20170330

Year of fee payment: 9

FPAY Annual fee payment

Payment date: 20180329

Year of fee payment: 10

LAPS Lapse due to unpaid annual fee