KR20060133950A - Ｉｐｃｐ 협상 기간 동안 ｐｐｐ 타임 아웃을 방지하는방법 및 장치 - Google Patents

Ｉｐｃｐ 협상 기간 동안 ｐｐｐ 타임 아웃을 방지하는방법 및 장치 Download PDF

Info

Publication number
KR20060133950A
KR20060133950A KR1020067003779A KR20067003779A KR20060133950A KR 20060133950 A KR20060133950 A KR 20060133950A KR 1020067003779 A KR1020067003779 A KR 1020067003779A KR 20067003779 A KR20067003779 A KR 20067003779A KR 20060133950 A KR20060133950 A KR 20060133950A
Authority
KR
South Korea
Prior art keywords
ppp
ipcp
protocol
client
address
Prior art date
Application number
KR1020067003779A
Other languages
English (en)
Other versions
KR101073268B1 (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 KR20060133950A publication Critical patent/KR20060133950A/ko
Application granted granted Critical
Publication of KR101073268B1 publication Critical patent/KR101073268B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5084—Providing for device mobility
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/168—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP] specially adapted for link layer protocols, e.g. asynchronous transfer mode [ATM], synchronous optical network [SONET] or point-to-point protocol [PPP]
    • 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/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • 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/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/11—Allocation or use of connection identifiers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02—Data link layer protocols

Landscapes

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

Abstract

무선 통신 장치상에 위치하는 PPP 서버와 PPP 클라이언트 사이에서 프로토콜 동기화 주기를 연장하는 방법 및 장치가 제공된다. 일 양상에서, PPP 클라이언트가 IPCP Configure-Request 메세지를 전송할 때마다, PPP 서버는 IPCP Configure-Nak 메세지를 생성하여 PPP 클라이언트로 전송하며, 여기서 제1 DNS 어드레스, 제2 DNS 어드레스, 제1 WINS 어드레스, 또는 제2 WINS 어드레스로서 의도적으로 전송되는 임의의 넌-제로 값이 IPCP Configure-Nak 메세지에서 전송된다. IP 어드레스는 IPCP Configure-Nak 메세지에서 의도적으로 생략된다.

Description

ＩＰＣＰ 협상 기간 동안 ＰＰＰ 타임 아웃을 방지하는 방법 및 장치{AVOIDING PPP TIME-OUTS DURING IPCP NEGOTIATIONS}
본 발명은 일반적으로 통신 분야에 관한 것이다. 특히, 본 발명은 무선 네트워크들에 대한 프로토콜 동기화 주기들을 연장하는 것에 관한 것이다.
무선 통신 분야 및 컴퓨터 관련 기술에서의 발전 및 인터넷 가입자들의 증가는 이동 컴퓨팅의 이용을 용이하게 하였다. 사실, 이동 컴퓨팅의 인기는 이동국 사용자들에게 보다 많은 지원을 제공하기 위해서 현재 인터넷 인프라구조에 대해 많은 것을 요구하고 있다. 이러한 요구들을 만족시키고 사용자들에게 필요한 지원을 제공하는 중요한 부분은 무선 통신 시스템에서 코드분할다중접속(CDMA)을 사용하는 것이다.
CDMA는 1993년 7월에 공표된 통신 산업 협회/전기 산업 협회 잠정 표준-95(TIA/EIA IS-95), 제목 "듀얼-모드 광대역 확산 스펙트럼 셀룰러 시스템용 이동국-기지국 호환 표준"에 제시되어 있으며, 이는 본 명세서에서 참조된다. 이러한 기술을 사용하는 이동 무선 시스템들은 고유 코드를 통신 신호들에 할당하고, 이러한 통신 신호들을 공통(광대역) 확산 스펙트럼 대역폭에 걸쳐 확산한다. CDMA 시스템의 수신 장치가 정확한 코드를 가지고 있다면, 수신 장치는 동일한 대역폭 상 에서 동시에 전송되는 다른 신호들로부터 자신의 통신 신호를 검출 및 선택할 수 있다. CDMA의 사용은 시스템 트래픽 용량을 증가시키고, 전체 통화 품질을 개선하여 잡음을 감소시키고, 데이터 서비스 트래픽에 대한 신뢰성 있는 전송 매커니즘을 제공한다. CDMA 기술을 이용하는 예시적인 시스템은 TIA에 의해 공표된 cdma2000 ITU-R 무선 전송 기술(RTT) 후보자 제출(이하 cdma2000)이다. cdma2000에 대한 표준은 IS-2000(cdma2000 1xEV-DV) 및 IS-856(cdma2000 1xEV-DO)의 드래프트 버젼들에 제시되고, TIA에 의해 승인되었다. 또 다른 CDMA 표준은 W-CDMA 표준이고, 이는 3세대 파트너쉽 프로젝트 "3GPPP", 문서번호 3G TS 25.211, 3G TS 25.212, 3G TS 25.213, 및 3G TS 25.214에 구현되어 있다. W-CDMA 표준은 유니버셜 이동 통신 시스템(UMTS)로 알려진 GSM-기반 시스템에 통합된다.
상술한 통신 표준들은 실행될 수 있는 다양한 통신 시스템들 중 단지 일부 예일 뿐이다. 표준들에 대한 하나의 일반적인 카테고리는 "3세대" 또는 "3G"로 지칭되고, 이는 cdma2000 및 W-CDMA 모두에 적용된다. 이러한 3G 표준들은 증가된 사용자들 및 데이터 집약적 애플리케이션을 지원하는 증가된 데이터 레이트들을 위해 사용된다.
도1은 이러한 무선 데이터 통신 시스템(100)의 기본 엘리먼트들을 보여주는 도이다. 제시된 엘리먼트들이 공지된 다양한 표준들에 따라 본 발명의 영역을 벗어남이 없이 다양하게 변형 및 수정될 수 있음을 당업자는 잘 이해할 수 있을 것이다. 시스템(100)은 이동 단말 장치(TE2)(102)(예를 들면, 랩톱 또는 팜톱 컴퓨터와 같은 단말 장치)가 망연동 장치(IWF)(108)와 통신할 수 있도록 하여준다. 시스 템(100)은 무선 통신 장치(MT2)(104)(예를 들면, 무선 전화기) 및 기지국/이동 교환 센터(BS/MSC)(106)를 포함한다. IWF(108)는 무선 네트워크 및 다른 네트워크들(예를 들면, 이동 교환 전화 네트워크 또는 인터넷/인트라넷 기반 접속을 제공하는 유선 패킷 데이터 네트워크) 사이에서 게이트웨이로서 기능한다. L 인터페이스는 IWF(108)를 BS/MSC(106)와 연결시킨다. 종종 IWF(108)는 BS/MSC(106)와 같은 장소에 배치된다. TE2 장치(102)는 Rm 인터페이스를 통해 MT2 장치(104)와 전기적으로 연결된다. MT2 장치(104)는 무선 인터페이스 Um을 통해 BS/MSC(106)와 통신한다. TE2 장치(102) 및 MT2 장치(104)는 하나의 유닛(예를 들면, MT0 장치)에 통합되거나, 또는 랩톱이 TE2 장치(102)이고 트랜시버가 MT2 장치(104)인 설치된 이동 전화기 유닛의 경우 분리될 수도 있다. 통합되건 또는 분리되건 간에, TE2 장치(102) 및 MT2 장치(104)의 조합은 일반적으로 이동국(MS)(103)으로 지칭된다.
무선 통신의 다양한 양상들을 제어, 관리, 및 이용하기 위해서 다양한 공지된 프로토콜들을 적용함으로써 다른 지원들이 가능해질 수 있다. 예를 들어, 인터넷 인프라구조의 근원인, 인터넷 프로토콜(IP)이 패킷-지향 서비스들을 수용하기 위해서 많은 무선 통신 서비스들에서 통합되었다. IP 프로토콜은 호스트 컴퓨터들 사이에서 패킷들(데이터그램)의 어드레싱 및 라우팅을 규정하고, 이는 1981년 9월에 공표된, Request For Comment 791(RFC 791), 제목 "INTERNET PROTOCOL DRAPA INTERNET PROGRAM PROTOCOL SPECIFICATION"에 정의되어 있다.
IP 프로토콜은 전송을 위해 IP 패킷들 내로 데이터를 캡슐화하는 네트워크 계층 프로토콜이다. 정보의 어드레싱 및 라우팅은 패킷의 헤더에 첨부된다. IP 헤더들은 송신 및 수신 호스트들을 식별하는 32 비트 어드레스를 포함한다. 이러한 어드레스는 의도된 어드레스의 종국적인 목적지로 향하는 네트워크 경로를 선택하기 위해서 중간 라우터들에 의해 사용된다. 따라서, IP 프로토콜은 전 세계 임의의 인터넷 노드에서의 발신 패킷이 전 세계 임의의 다른 인터넷 노드로 라우팅될 수 있도록 하여준다.
무선 통신 시스템에 통합되는 또 다른 공지된 프로토콜은 점 대 점(PPP) 프로토콜이고, 이는 특히 인터넷 접속을 제공한다. PPP 프로토콜은 1994년 7월에 공표된 Request for Comments 1661(RFC 1661), 제목 "THE POINT TO POINT PROTOCOL(PPP)"에 상술되어 있다.
본질적으로, PPP 프로토콜은 점 대 점 링크들 상에서 멀티-프로토콜 데이터그램들을 전송하는 방법을 규정하고, 3개의 주요한 컴포넌트들을 포함한다:멀티-프로토콜 데이터그램들을 캡슐화하는 방법; 데이터 링크 접속을 확립, 구성, 및 테스트하는 링크 제어 프로토콜(LCP); 및 상이한 네트워크-계층 프로토콜들을 확립 및 구성하는 네트워크 제어 프로토콜(NCP) 패밀리.
무선 통신 시스템상의 서비스를 호스트에게 제공하는 노력에 있어서, 다양한 표준들이 TE2 장치(102) 및 IWF(108) 사이에서 무선 데이터 전송을 수용하기 위해서 개발되었다. 예를 들어, 본 명세서에서 참조되며, 1998년에 공표된 TIA/EIA IS-707.5 표준, 제목 "광대역 확산 스펙트럼 서비스를 위한 데이터 서비스 옵션:패킷 데이터 서비스"는 TIA/EIA IS-95에서 패킷 데이터 전송 능력을 지원하기 위한 요구조건들을 정의하고, 패킷 데이터 베어러(bearer) 서비스들을 규정한다.
특히, IS-707.5 표준은 BS/MSC(106)를 통해 TE2 장치(102) 및 IWF(108) 사이에서 통신하는데 사용될 수 있는 임의의 패킷 데이터 서비스 모드들을 제공한다. 이를 통해, IS-707.5 는 특정 동작 모드를 제공하는 네트워크 모델을 도입한다. 네트워크 모델은 제1 PPP 링크가 TE2 장치(102) 및 MT2 장치(104) 사이에서 설정되고, 제1 링크와는 독립적인 제2 PPP 링크가 MT2 장치(104) 및 IWF(108) 사이에서 설정되는 상황을 나타낸다. 이러한 모델은 임의의 수신된 PPP 패킷들을 그들의 최종 목적지로 전송하고, 이동성 관리 및 네트워크 어드레스 관리를 제공하기에 앞서, MT2 장치(102)가 임의의 수신된 PPP 패킷들을 언프레임화(unframe) 하고, 이들을 재-프레임화(re-frame) 하도록 한다.
도2는 IS-707.5 네트워크 모델의 각 엔티티에서의 프로토콜 스택들을 보여준다. TE2 장치(102)(예를 들면, 무선 단말, 랩톱 또는 팜톱 컴퓨터)상에서 실행되는 프로토콜 계층들을 기존의 수직 포맷으로 제시하는 프로토콜 스택이 도2의 좌측에 제시된다. TE2 프로토콜 스택은 Rm 인터페이스상에서 MT2 장치(104) 프로토콜 스택과 논리적으로 연결되는 것으로 제시된다. MT2 장치(104)는 Um 인터페이스상에서 BS/MSC(106) 프로토콜과 논리적으로 연결되는 것으로 제시된다. BS/MSC(106)는 L 인터페이스상에서 IWF(108)와 논리적으로 연결되는 것으로 제시된다.
예를 들어, 도2에 제시된 프로토콜들은 다음과 같이 동작한다: Rm 인터페이스와 관련되는 TE2 장치(102) 상의 PPP 계층은 상위 계층 프로토콜(204) 및 네트워크 계층 IP 프로토콜(206)로부터의 패킷들을 인코딩한다. 그리고 나서, PPPR 계층 (208)은 예를 들어, TIA/EIA 232-F 프로토콜(210)과 같은 적용가능한 프로토콜을 사용하여 Rm 인터페이스상에서 패킷들을 전송하고, 패킷들은 MT2 장치(104)에서 TIA/EIA 232-F-호환 포트에 의해 수신된다. TIA/EIA-232-F 표준은 본 명세서에서 참조되고, 1997년 10월에 공표된, "직렬 이진 데이터 상호교환을 사용하는 데이터 단말 장치 및 데이터 회선-종단 장치 사이의 인터페이스"에서 정의된다. 다른 공지된 프로토콜들이 Rm 인터페이스상에서의 전송을 정의하는데 사용될 수 있다. 예를 들어, 다른 적용가능한 Rm 인터페이스 표준들은 본 명세서에서 참조되고, 1998년 9월에 공표된 "유니버셜 직렬 버스(USB) 규격, 리비젼 1.1", 및 1999년 7월에 공표된 "블루투스 규격 버젼 1.0A 코어"를 포함한다.
MT2 장치(104) 상의 TIA/EIA 232-F 프로토콜(212)은 TE2 장치(102)로부터 패킷들을 수신하고, 이들을 MT2 장치(104)의 PPPR 계층(213)으로 전달한다. PPPR 계층(213)은 PPP 프레임들 내에 캡슐화된 패킷들을 프레임해제하고, 일반적으로 데이터 접속이 이뤄지면, 계층(213)은 Um 인터페이스와 관련된 PPP 계층(즉, PPPU 계층(217))으로 패킷들을 전달한다. PPPU 계층(217)은 IWF(108)에 위치하는 PPPU 피어(peer)로 전송을 위해 PPP 프레임들 내에 패킷들을 포맷화한다. 공지된 무선 링크 프로토콜(RLP)(216) 및 IS-95 프로토콜(214)은 Um 인터페이스상에서 BS/MSC(106)로 PPP 프레임들에서 캡슐화된 패킷들을 전송하는데 사용된다. RLP 프로토콜(216)은 1998년 2월에 공표된 IS-707.2 표준, 제목 "광대역 확산 스펙트럼 시스템을 위한 데이터 서비스 옵션:무선 링크 프로토콜"에서 정의되고, IS-95 프로토콜은 상술한 IS-95 표준에서 정의된다. WCDMA 시스템에서, PPP 계층은 RLP 계층과 유사한 기능성을 갖는 무선 링크 제어(RLC) 계층에 위치한다.
상술한 바와 같이, PPPR 프로토콜(213)은 데이터 링크 접속이 확립되는 경우 PPPU 프로토콜(217)로 패킷을 전달한다. RFC(1661)는 데이터 링크 연결을 확립, 구성, 및 테스트하기 위해서 링크 제어 프로토콜(LCP) 패킷들이 각각의 PPP 링크(즉, PPPR 및 PPPU) 상에서 교환 및 협상되어야 한다는 것을 제공한다.
일단 LCP 패킷들이 교환되고, 링크 옵션이 협상되고, 데이터 링크 연결이 설정되면, 네트워크 계층 연결이 TE2 장치(102) 및 IWF(108) 사이에서 확립되어야한다. 이러한 연결은 예를 들어 IP 프로토콜을 포함하는 프로토콜들(206,212,218,230)을 사용한다. PPP 링크의 양측에서 IP 프로토콜에 대한 협상, 구성, 인에이블링, 및 디스에이블링이 공지된 인터넷 프로토콜 제어 프로토콜(IPCP)에 의해 제공된다. IPCP는 PPP 프로토콜에 포함된 네트워크 제어 프로토콜(NCP) 패밀리의 일부이고, 1992년 5월에 공표된 Request for Comment(RFC) 1332, "PPP 인터넷 프로토콜 제어 프로토콜(IPCP)"에 제시되어 있다.
IPCP 프로토콜은 IP 어드레스들의 지청 및 요청을 포함하여, 다양한 옵션들을 협상하기 위해서 표준 PPP Configure-Request, Configure-Ack, 및 Configure-Nak 메세지들을 사용한다. IPCP는 IP 어드레스를 요청하는 요청자가 특정 어드레스를 포함하는 Configure-Request 메세지를 발생시키는 것을 제공한다. 특정 IPCP 어드레스가 수용가능하면, Configure-Ack 메세지가 피어(peer)에 의해 요청자로 전 송된다. 특정 IP 어드레스가 수용가능하지 않으면, 피어는 제안된 IP 어드레스를 포함하는 Configure-Nak 메세지를 전송한다. 그리고 나서, 요청자는 제안된 IP 어드레스를 갖는 새로운 Configure-Request 메세지를 전송하고, 피어는 Configure-Ack로 응답한다.
하나 이상의 어드레스를 할당하는 IPCP 내의 메커니즘이 존재하지 않기 때문에, PPPU 및 PPPR 링크들을 통해 단지 하나의 IP 어드레스를 할당하는 것만이 가능하다. 이는 PPPU 상에서 IWF로부터 할당되는 IP 어드레스가 PPPR 상에서 TE2로 추가로 할당되어야 함을 의미한다. 네트워크 모델에서, IPCP 어드레스 협상은 Rm 인터페이스 및 Um 인터페이스에 대해 개별적으로 발생할 수 있다. 이와 같이, 어드레스가 TE2 장치(102)에 PPPR 링크의 다른 측에서 할당될 수 있기 전에, MT2 장치(104)는 PPPU 링크의 일 측에서 Um 인터페이스를 통해 IP 어드레스를 IWF(108)와 먼저 협상하여야 한다.
그러나, IPCP 어드레스 협상의 완료는 동작 지연들에 의해 방해될 수 있다. 예를 들어, MT2 장치(104) 및 IWF(108) 사이의 링크가 TE2 장치(102) 및 MT2 장치(104) 사이의 링크보다 느린 경우, 이러한 지연들이 발생될 수 있다. 이와 같이, Um 링크에 비해 Rm 링크 상의 IPCP 어드레스 협상이 보다 빠르게 달성될 수 있다. 따라서, TE2 장치(102)는 MT2 장치(104)가 IWF(108)로부터 IP 어드레스를 제공하기 위해 Um 링크 상에서 필요한 어드레스 협상들을 완료하지 못했기 때문에 주어질 수 없는 MT2 장치(104)로부터의 IP 어드레스를 요청할 수 있다. 비록 TE2 장치(102) 는 MT2 장치(104)가 결국 IP 어드레스를 제공하기 위해 대기할 수 있지만, TE2 장치(102) 상의 실행-특정 타임-아웃이 존재하고, 이러한 타임 아웃은 TE2 장치가 IP 어드레스 요청을 중단하게 하고, 따라서 PPP 협상을 완전히 중단하게 한다.
동작 지연의 또 다른 예는 TE2 장치가 MT2 장치상에서 할당된 IP 어드레스를 전달할 수 있기에 앞서, 다른 엔티티로부터, 결국 TE2 장치(102)로 할당될 IP 어드레스를 IWF(108)가 획득하여야만 하는 경우에 발생한다. 이렇게 하는데, MT2 장치(104)가 IP 어드레스를 수신하기에 앞서 수초의 시간이 소요된다.
예를 들어, TE2 장치(102)에서 실행되는 일부 애플리케이션들은 TE2 장치가 타임 아웃되기 전에 3번의 시도에 대해 매 3초 마다 Configure-Request 메세지들을 TE2 장치(102)가 발생시키도록 한다. 이러한 경우, IP 어드레스를 수신하는데 9초 이상이 소요되면, TE2 장치(102)는 어드레스 요청을 중단한다. 명백하게, 상술한 2개의 시나리오들은 TE2 장치의 영구적인 중단을 야기하는 지연들을 발생시킬 수 있다.
따라서, IPCP 어드레스 협상을 유지하기 위해 타임-아웃을 방지할 수 있는 신규한 방법이 요구된다.
상술한 요구들은 IPCP 협상들을 유지하기 위한 타임 아웃 방지 방법 및 장치를 제공함으로써 만족된다. 일 양상에서, 점 대 점 프로토콜(PPP) 클라이언트 및 PPP 서버 사이에서 프로토콜 동기화 주기를 연장하는 방법이 제공되고, 여기서 PPP 서버는 무선 통신 장치상의 위치하며, 상기 방법은 PPP 클라이언트로부터의 인터넷 프로토콜 제어 프로토콜(IPCP) 구성 요청에 응답하여 PPP 서버에서 부정 확인응답(negative acknowledgment) 메세지를 발생시키는 단계 - 여기서, 부정 확인응답 메세지는 의도적으로 임의의 보충 IPCP 정보를 포함하고, IP 어드레스 옵션을 포함하지 않음 - ; 및 프로토콜 동기화 주기를 완료하기 위해서 필요한 모든 파라미터들을 PPP 서버가 수신하였다면, IPCP 구성 요청에 응답하여 PPP 서버에서 긍정 확인응답(acknowledgment) 메세지를 발생시키는 단계를 포함한다.
또 다른 양상에서, 점 대 점 프로토콜(PPP) 클라이언트 및 PPP 서버 사이의 프로토콜 동기화 주기를 연장하기 위한 장치가 제공되며, 여기서 PPP 서버는 무선 통신 장치에 위치하는데, 상기 장치는 적어도 하나의 메모리 엘리먼트; 및 상기 적어도 하나의 메모리 엘리먼트에 저장된 한 세트의 지령들을 실행하도록 구성되는 적어도 하나의 처리 엘리먼트를 포함하며, 상기 한 세트의 지령들은 PP 클라이언트로부터의 인터넷 프로토콜 제어 프로토콜(IPCP) 구성 요청에 응답하여 PPP 서버에서 부정 확인응답(negative acknowledgment) 메세지를 발생시키는 지령 - 여기서, 부정 확인응답 메세지는 의도적으로 임의의 보충 IPCP 정보를 포함하고, IP 어드레스 옵션을 포함하지 않음 - ; 및 프로토콜 동기화 주기를 완료하기 위해서 필요한 모든 파라미터들을 PPP 서버가 수신하였다면, IPCP 구성 요청에 응답하여 PPP 서버에서 긍정 확인응답(acknowledgment) 메세지를 발생시키는 지령을 포함한다.
도1은 무선 통신 시스템의 다양한 엘리먼트들을 보여주는 상위 레벨 블록 다이아그램이다.
도2는 무선 통신 시스템의 프로토콜 스택들을 보여주는 도이다.
도3A는 일 실시예를 설명하는 흐름도이다.
도3B는 일 실시예의 동작을 설명하는 프로토콜-메세지 흐름도이다.
도4는 또 다른 실시예를 설명하는 흐름도이다.
도5는 GSM EDGE 무선 접속 네트워크(GERAN) 또는 UMTS 무선 접속 네트워크(URTAN) 무선 채널들 상에서 일반 패킷 무선 서비스(GPRS)-인에이블 네트워크의 패킷 데이터 연결을 설정하는 프로토콜-메세지 흐름도이다.
본 발명의 실시예들은 도면에서 제시된 엔티티들(즉, TE2, MT2, BS.MSC, IWF)을 소프트웨어, 펌웨어, 및 하드웨어를 포함하여 다양한 구현들로 실현될 수 있다. 본 실시예들을 구현하는데 사용되는 실제 소프트웨어 코드 또는 제어 하드웨어는 본 발명의 범위를 제한하지 않는다. 따라서, 본 실시예들의 동작 및 구성은 실제 소프트웨어 또는 하드웨어 컴포넌트들을 특정하지 않고 기술될 것이다. 당업자는 하기 설명에 기초하여 본 발명을 구현하기 위해서 소프트웨어 및 제어 하드웨어를 설계할 수 있기 때문에, 특정 소프트웨어 또는 하드웨어 컴포넌트를 특정하지 않더라고 본 발명을 이해하는데 전혀 지장이 없을 것이다.
도3A는 본 발명의 실시예를 설명하는 흐름도이고, 도3B는 본 발명의 실시예의 동작을 설명하는 프로토콜-메세지 흐름도이다. 도3A에 제시된 바와 같이, MT2 장치(104)는 블록(B305)에서 Um 인터페이스를 통해 IWF(108)와 PPP 협상을 개시한다. 이러한 이벤트는 도3B에 제시된 바와 같이(참조 번호 A), Rm 인터페이스상에 서 LCP 협상의 시작에 의해 트리거링된다.
블록(B310)에서, MT2 장치(104)는 TE2 장치(102)로부터 IPCP Configure-Request 메세지를 수신할 때까지 대기한다. 일단 MT2 장치(104)가 TE2 장치(102)로부터 Configure-Request 메세지를 수신하면, MT2 장치(104)는 블록(B315)으로 진행한다.
블록(B315)에서, MT2 장치(104)는 TE2 장치(102)로부터의 Configure-Request 메세지에 응답하여 IWF(108)에 의해 할당된 IP 어드레스를 수신하였는지 여부를 결정한다. MT2 장치(104)가 수신하지 못하였다면, MT2 장치(104)는 블록(B320)으로 진행하고, 여기서 MT2 장치(104)는 Configure-Request 메세지 내에 포함된 IP 어드레스를 거절하고, 임의의(arbitrary) IP 어드레스를 갖는 Configure-Nak 메세지를 전송한다(도3B의 참조번호 B). 임의의 IP 어드레스는 MT2 장치(104)에 의해 거절될 어드레스이다. 임의의 IP 어드레스를 갖는 Configure-Nak 메세지를 전송할 때, MT2 장치(104)는 블록(B310)으로 돌아가서 임의의 IP 어드레스를 갖는 TE2 장치(102)로부터의 IPCP Configure-Request 메세지를 대기한다. 이러한 임의의 IP 어드레스는 IWF(108)에 의해 할당되는 IP 어드레스가 아니기 때문에, MT2 장치(104)는 블록(B320)으로 들어가고, 여기서 Configure-Request 메세지에 포함된 IP 어드레스를 다시 거절하고 임의의 IP 어드레스를 갖는 Configure-Request 메세지를 전송한다. 이러한 임의의 어드레스는 이전 반복과 동일할 어드레스일 수도 있고, 다른 어드레스일 수도 있다. 일련의 블록들(B310-B315-B320)에 의해 발생된 루프는 MT2 장치(104)가 IWF(108)에 의해 할당된 IP 어드레스를 수신할 때까지 반복된다. TE2 장치(102)를 관련시키고, TE2 장치(102)가 Configure-Request 메세지를 생성하도록 트리거링함으로써, MT2 장치(104)는 TE2 장치(102)가 타임 아웃되는 것을 방지하여 IPCP 어드레스 협상들을 계속 유지할 수 있게 하여준다. MT2 장치(104) 및 TE2 장치(102) 사이에 교환되는 메세지들의 수를 감소시키는 루프 내의 지연을 도입하는 것 역시 가능하다.
블록(B315)으로 다시 돌아가서, MT2 장치(104)가 IWF(108)에 의해 할당된 IP 어드레스를 수신하였다고 MT2 장치(104)가 결정하면, MT2 장치는 블록(B325)으로 진행하고, 여기서 MT2 장치(104)는 TE2 장치(102)로 할당된 IP 어드레스를 담고 있는 Config-Nak 메세지를 전송한다(참조번호 C). 그리고 나서, MT2 장치(104)는 블록(B330)에서 TE2 장치(102)로부터 할당된 IP 어드레스를 갖는 Configure-Request 메세지를 수신한다(참조 번호 D).
MT2 장치(104)는 블록(B335)으로 진행하고, 여기서 TE2 장치(102)로부터의 Configure-Request 메세지 수신 확인을 알리기 위해(acknowledge) TE2 장치(102)로 Config-Ack 메세지를 전송한다(참조번호 E). 블록(B340)에서, MT2 장치(104)는 Um 링크 상에서 IWF(108)와 협상된 IPCP 옵션들을 TE2 장치(102)로 전송한다(참조 번호 F). 그리고 나서, MT2 장치(104)는 블록(B345)에서 IWF(108)에 의해 할당된 IP 어드레스에 의해 사용중인 옵션들을 알리는 Config-Ack 메세지를 수신한다(참조번호 G). 블록(B340 및 B345)에서의 처리들은 엄격하게 요구되는 것은 아니며, 모든 패킷들이 MT2 장치(104)를 통해 프레임화 또는 언프레임화되기 때문에 MT2 장치(104)는 TE2 장치(102)로 임의의 IPCP 값들을 전송할 수 있다.
따라서, 상술한 실시예는 MT2 장치(104)에 의해 거절될 임의의 IP 어드레스들을 담고 있는 Configure-Nak 메세지들을 TE2 장치(102)에 제공함으로써 실행-특정 타임 아웃을 방지할 수 있게 된다. Configure-Nak 메세지들은 TE2 장치(102)가 Configure-Request 메세지를 발생시키는 것을 트리거링한다. 이러한 상호작용은 MT2 장치(104)가 IWF에 의해 할당된 IP 어드레스를 수신하고 이러한 IP 어드레스를 Configure-Nak 메세지에서 TE2 장치로 전송할 때까지 계속된다. 이러한 방식으로, TE2 장치(102)는 실행-특정 타임 아웃으로 인해 영구적으로 중단(abort)되는 것이 방지되며, PPP 협상들이 유지된다.
의도적으로 PPP 협상들을 연장하는 추가적인 실시예들
또 다른 실시예에서, TE2 장치는 IPCP 어드레스 협상의 영구적인 타임 아웃이 방지되고, IPCP 패킷 교환에서 특정 필드들에 대한 요청들을 중단시키는 것이 방지된다. 본 실시예는 의도적으로 IPCP Configure-Nak 메세지들을 사용하여 PPP 서버가 PPP 클라이언트와 보다 긴 시간 동안 대화하도록 함으로써 IPCP 프로토콜 동기화 주기를 연장한다. 이러한 연장된 대화에서 사용되는 IPCP Configure-Nak 메세지는 IPCP 패킷들 내의 하나 이상의 다음 필드들을 포함한다:제1 도메인 네이밍 시스템(DNS) 어드레스, 제2 DNS 어드레스, 제1 윈도우 인터넷 네이밍 서비스(WINS) 어드레스, 및/또는 제2 WINS 어드레스. PPP 클라이언트로부터 IPCP 구성 요청 메세지에서 요청된 실제 파라미터들과는 관계없이 IPCP 협상 단계 동안 PPP 서버는 PPP 클라이언트와 보다 긴 시간 동안 대화한다. 이러한 연장된 대화는 IPCP 협상 단계가 완료될 때까지 PPP 클라이언트가 제1 IPCP 구성 요청 메세지에서 요청된 모든 파라미터들을 유지할 수 있도록 한다.
이해를 돕기 위해, 용어 "보충(supplemental) IPCP 정보"는 제1 DNS 어드레스들, 제2 DNS 어드레스들, 제1 WINS 어드레스들, 및 제2 WINS 어드레스들 각각 또는 이들의 임의적인 조합을 지칭하기 위해서 사용된다. "IP 어드레스"라는 용어는 2가지 의미를 가지고 있다. 첫째, 용어 "IP 어드레스"는 RFC 791에서 논의된 임의의 어드레스를 일반적으로 지칭한다. 둘째, 용어 "IP 어드레스"는 PPP 클라이언트에 대한 어드레스 할당을 위한, IPCP 패킷 내의 특정 필드를 구체적으로 지칭한다. 여기서 논의되는 실시예에서, "IP 어드레스"는 상기 두 번째 의미로 사용된다.
보충 IPCP 정보는 한정되지 않는 듀레이션 동안 IPCP 협상들의 프로토콜 동기화 주기를 연장하기 위해서 MT2 장치로부터 TE2 장치로 Configure-Nak 메세지 내에서 전송된다. 즉, 컴퓨터 판독가능 매체 상의 소프트웨어는 프로토콜 동기화 주기를 연장하기 위해서 IP 어드레스가 아니라 상이한 타입의 어드레스를 무한정 반복하도록 설계된다.
도4는 본 실시예를 설명하는 흐름도이다. 이해를 돕기 위해, 소프트웨어 엔티티 "PPP 클라이언트" 및 "PPP 서버"가 사용된다. PPP 클라이언트 및 PPP 서버는 2개의 개별 전기 장치와 같이 별개의 물리적 장치상에 위치할 수 있고, 대안적으로 동일한 전자 장치 내에 상주할 수도 있다. 예를 들어, PPP 클라이언트의 기능은 하나의 처리 유닛에 의해 구현되고, PPP 서버의 기능은 다른 처리 유닛에 의해 구현되며, 이러한 2개의 처리 유닛들은 동일한 전자 장치 내에 위치한다.
블록(400)에서, PPP 클라이언트는 IPCP Configure-Request 메세지를 PPP 서 버로 전송한다. IPCP Configure-Request 메세지 수신시에, PPP 서버는 블록(410)에서 네트워크로부터의 파라미터들에 대해 협상한다. 그러나, PPP 서버는 요구되는 파라미터들이 네트워크로부터 획득될 때까지 PPP 클라이언트로부터의 요청에 응답할 수 없다.
블록(420)에서, PPP 서버는 IPCP Configure-Nak 메세지를 생성하여 이를 PPP 클라이언트로 전송하고, 여기서 넌-제로(non_zero) 값을 갖는 보충 IPCP 정보가 전송된다. 보충 IPCP 정보는 제1 DNS 어드레스, 제2 DNS 어드레스, 제1 WINS 어드레스, 제2 WINS 어드레스 또는 이들의 임의적인 조합을 포함한다. 본 실시예의 일 양상에서, IP 어드레스는 IPCP Configure-Nak 메세지의 IP 어드레스 필드로부터 의도적으로 생략된다. 본 실시예의 또 다른 양상에서, 블록(420)의 동작은 블록(410)의 동작에 앞서 수행될 수 있다.
블록(430)에서, PPP 클라이언트는 블록(420)의 IPCP Configure-Nak 메세지에 응답하여 또 다른 IPCP Configure-Request 메세지를 전송한다.
블록(420 및 430)은 PPP 서버가 블록(440)에서 네트워크로부터 IPCP 파라미터들을 수신할 때까지 무한정 반복된다.
블록(450)에서, PPP 서버는 네트워크로부터 수신된 실제 IP, DNS, 및WINS 어드레스로 그 자신을 구성(configure)하고, PPP 서버를 구성하기 위해서 사용된 정보를 갖는 IPCP Configure-Nak를 PPP 클라이언트로 전송한다. 블록(460)에서, PPP 클라이언트는 블록(450)에서 전송된 파라미터들을 갖는 IPCP Configure-Request 메세지를 전송한다. 블록(470)에서, PPP 서버는 프로토콜 동기화를 완료하는 요청된 파라미터들에 대한 IPCP Configure-Ack를 전송한다.
도4에서 제시된 실시예들에 대한 변형들이 존재한다. 일 양상에서, PPP 서버는 예를 들어, IPCP Configure-Nak 메세지가 임의의 제1 DNS 어드레스를 전달하고, 제2 IPCP Configure-Nak 메세지가 임의의 제2 DNS 어드레스를 전달하고, 제3 IPCP Configure-Nak 메세지가 임의의 제1 WINS 어드레스를 전달하고, 제4 IPCP Configure-Nak 메세지가 임의의 제2 WINS 어드레스를 전달하고, 제 5 IPCP Configure-Nak 메세지가 또 임의의 또 다른 제1 DNS 어드레스를 전달하는 것과 같이, 상이한 IPCP Configure-Request 메세지에 응답하여 상이한 보충 IPCP 정보 서브셋들을 전송하도록 설계될 수 있다. 본 실시예의 이러한 양상을 이용하여, 각각의 뒤이은 IPCP Configure-Nak 메세지는 상이한 어드레스 값을 전달한다.
또 다른 양상에서, PPP 서버는 모든 IPCP Configure-Nak 메세지에서 동일한 임의의 DNS 및 WINS 어드레스들을 전송할 수도 있다. 그러나, 다양한 양상들 사이에서 일정한 것은 IP 어드레스 필드 내의 어떠한 IP 어드레스도 전송되지 않는다는 것이다. 또다시, 여기서 사용되는 "IP 어드레스"는 일반적인 용어를 지칭하는 것이 아니라 IPCP 패킷 내의 특정 필드를 지칭하기 위해서 사용된다는 것을 주의하여야 한다.
IP 어드레스가 아니라, 임의의 DNS 및 WINS 어드레스가 전송되는 본 실시예는 임의의 무선 통신 네트워크에서 보다 많은 장점을 갖는다. 예를 들어, WCDMA 시스템 또는 GSM/GPRS(글로벌 시스템 이동/일반 패킷 무선 서비스) 시스템에서, PPP 클라이언트는 PPP 서버로부터의 IPCP 응답 대기시간이 설정된 기간을 초과하면 타임 아웃되도록 구성된다. PPP 클라이언트는 3초 후에 IPCP 요청을 재전송한다. PPP 클라이언트는 N번(일반적으로 10으로 설정된) IPCP 요청을 재전송하고, 만약 IPCP 응답이 수신되지 않으면 PPP 링크를 닫는다. 따라서, PPP 서버와 네트워크 사이의 무선 연결이 IPCP 패킷을 수신하지 않고 그 PPP 클라이언트에 대한 타임 아웃 제한시간을 초과하면, PPP 클라이언트는 자동적으로 PPP 링크를 종료하게 된다.
패킷 데이터 서비스를 위해 GPRS를 사용하는 무선 네트워크에서, 네트워크의 일반적인 구조는 도1의 구조와 유사하다. 그러나, 약간의 차이점이 존재한다. 이동 장치는 "사용자 장치(UE)"로 지칭되고, 기지국의 기능은 UMTS 지상 무선 접속 네트워크(UTRAN)의 부분으로서 설명되며, UTRAN은 무선 네트워크 제어기(RNC) 및 노드 B 또는 GSM 에지 무선 접속 네트워크(GERAN)의 일부로 구성되며, GERAN은 기지국 제어기(BSC) 및 기지국 트랜시버(BTS)로 구성된다. UE로부터의 패킷은 무선 링크 상에서 RNC 또는 BSC로 전송되고, 그리고 나서 서빙 GPRS 노드(SGSN)로 전송되며, SGSN은 패킷 스위칭, 라우팅, 다른 노드에 대한 데이터베이스 기능을 제공한다. IWF가 무선 네트워크 및 패킷 데이터 서비스 네트워크 사이의 포털(portal)로 동작하는 것이 아니라, 게이트웨이 GPRS 지원 노드(GGSN)가 포털로 동작한다. GGSN은 또한 GPRS 서비스들에 대한 데이터베이스 기능, 패킷 스위칭, 및 라우팅을 제공하도록 동작한다. 네트워크 엔티티들 사이의 다양한 인터페이스들 역시 상이한 이름을 갖는다. 그러나, 전체적인 원리들은 유사하다. 도5는 음성 연결에 반대되는, 패킷 데이터 연결을 설정하기 위해서 GPRS 네트워크의 다양한 엔티티들 사이의 메세지 흐름을 보여주는 도이다. 구체적인 내용은 2003년 6월에 공표된, 문 서 3GPP TS 29.061, 제목 "3세대 파트너쉽 프로젝트; 기술 규격 그룹 코어 네트워크; 패킷 기반 서비스들을 지원하는 공중 랜드 이동 네트워크(PLMN) 및 패킷 데이터 네트워크(PDN) 사이의 망간 접속" 에 제시되어 있다.
단말 장치(TE)(500)는 TE(500)가 연결되는 UE(502)로 ATD*98 메세지(510)를 전달한다. ATD*98 메세지(510)는 패킷 데이터 프로토콜(PDP)을 가동시키는 메세지이다. UE(502)는 연결 메세지(512)로 응답한다. 그리고 나서, TE(500) 및 UE(502)는 링크 제어(LCP) 프로토콜 레벨 협상을 수행한다. LCP 협상(514)이 성공적으로 완료된 후, 챌린지 핸드쉐이크 인증 프로토콜(CHAP) 또는 패스워드 인증 프로토콜(PAP) 협상(516)이 개시된다. 인증 파라미터들이 TE(500) 및 UE(502) 사이에서 협상된 후, TE(500)는 UE(502)로 IPCP 요청 메세지(518)를 전송한다.
UE(502)가 IPCP 요청(518)을 수신하면, UE(502)는 PDP 컨텍스트 활성화(activation) 요청 메세지(520)를 SGSN(504)으로 전송한다. SGSN(504)는 PDP 컨텍스트 메세지를 생성하고 PDP 컨텍스트 메세지(522)를 적절한 GGSN(506)으로 전송한다. 그리고 나서, GGSN(506)은 네트워크 서비스들에 대한 UE(502)로의 접속을 허용할 것인지를 결정하기 위해서 관리, 인증, 허가, 인증(AAA) 서버와 인증 및 검증 절차를 수행한다.
AAA 서버(508)가 허가를 부여하면, GGSN(506)은 PDP 컨텍스트 생성 PDP 컨텍스트 응답 메세지(526)를 SGSN(504)으로 전송한다. SGSN(504)는 활성화 PDP 컨텍스트 수용 메세지(528)를 UE(502)로 전송한다. 그리고 나서, UE(502)는 TE(500)로 IPCP Configure 확인 메세지(520)를 전송하고, TE(500)가 이를 수신하면, 패킷 데 이터 연결을 위한 셋업이 완료된다.
도5에 제시된 흐름도를 다시 참조하면, PDP 컨텍스트 활성화 기간 동안, 타임아웃 문제가 심각해 질 수 있음을 관측할 수 있고, 여기서 PPP 서버의 일부로서 동작하는 UMTS/GPRS 장치는 무선 네트워크와 접촉하여, 그 자신을 PPP 서버로 구성하기 위해 필요한 파라미터들을 획득하여야 한다. PDP 컨텍스트 활성화 프로세스는 종종 완료하는데 30초 이상의 시간이 소요된다. 이러한 긴 호출 셋업 시간은 많은 요인들에 의해 야기된다. 이러한 요인들은 원격 인증 다이얼-인 사용자 서버(RADIUS) 또는 AAA 서버로 향하는 인증 및 구성(configuration)과 같은 동작에서 초래되는, 코어 네트워크 내의 지연들, UE 및 RNC 사이의 무선 자원 제어(RRC) 연결 확립시에 UTRAN 내의 지연들 또는 완전하지 않은 무선 조건하에서 UE 및 BSC 사이에서 GPRS 무선 자원(GPR) 연결 확립시에 GERAN 내의 지연들, 및 랜덤 액세스 시도들 사이의 셀 재선택에 기인한 지연들을 포함한다. 도4에 제시된 실시예는 그 활성화 처리 기간 동안 PPP 클라이언트가 PPP 링크를 종결시키는 것을 방지한다.
본 발명의 실시예가 유용한 또 다른 상황은 PDP 컨텍스트 활성화 절차를 개시하기에 앞서 GPRS Attach 절차들을 수행하여야 하는 UMTS/GPRS 장치에서 사용되는 경우이다. GPRS Attach 절차는 일반적으로 네트워크가 UE 방향으로 인증 및 키 동의 절차를 개시하도록 하고, 뒤이어 RNC/BSC에 의해 할당된 무선 채널 자원들 상에서 무결성 보호 및/또는 암호화를 확립하기 위해 추가적인 무선 접속 레벨 시그널링이 뒤따른다. 따라서, GPRS 또는 UMTS에 대한 PDP 컨텍스트 활성화 절차는 훨씬 많은 시간이 소요되고, 이는 PPP 클라이언트가 타임 아웃되게 한다.
또 다른 타임 아웃 문제는 PPP 클라이언트가 DNS 어드레스 및/또는 WINS 어드레스에 대한 요청들을 포함하고, PPP 서버가 네트워크가 그 어드레스를 할당할 때까지 적시에 응답할 수 없는 경우에 발생한다. 이러한 타임아웃 주기 이후에, PPP 클라이언트는 PPP 클라이언트가 PPP 서버로 전송하는 IPCP 패킷들 내의 DNS 어드레스 및/또는 WINS 어드레스들에 대한 요청을 배제할 것이다. 일반적으로, PPP 클라이언트는 M번의 재시도 후에, DNS 어드레스 요청을 중단하도록 구성되고, 여기서 M은 일반적으로 4이다. 4번의 재시도는 일반적으로 대략 PPP 협상의 15초에 상응한다.
PPP 서버가 15초 후에 IP 및 DNS 어드레스 할당을 시도하면, 타임 아웃 주기 후에 이에 대한 특정 요청을 PPP 클라이언트가 만들지 않았기 때문에, PPP 클라이언트는 DNS 및/또는 WINS 어드레스들을 수용하지 않을 것이다. PPP 클라이언트는 여전히 IP 어드레스를 수용할 것이며 성공적으로 PPP 링크를 설정할 것임을 주의하라. PPP 클라이언트는 PPP 클라이언트가 특정하게 요청한 값들만을 수용하며, 이러한 상황에서, PPP 클라이언트는 15초 후에는 DNS 및/또는 WINS 어드레스에 대한 요청을 중단하였다. PPP 클라이언트가 DNS 어드레스에 대한 요청들을 중단하면, PPP 링크의 할당된 데이터 파이프라인은 쓸모없게 되는데, 왜냐하면 PPP 클라이언트와 동일한 장치에서 실행되는 애플리케이션에 의해 사용될 수 있는 DNS 서버가 존재하지 않기 때문이다. 할당된 데이터 파이프라인을 사용하기 위해서, 장치의 사용자는 자신이 접촉하기를 원하는 호스트의 IP 어드레스를 명확하게 진술하여야 한다. 이러한 상황은 대부분의 웹 페이지들이 링크의 실제 어드레스가 아니라, 호 스트 이름을 사용하여 하이퍼 텍스트 마크업 언어(HTML) 링크로 구현되는 웹 서핑에서는 문제가 된다.
당업자는 상술한 다양한 예시적인 논리블록, 모듈, 회로, 및 알고리즘 단계들이 전자 하드웨어, 컴퓨터 소프트웨어, 또는 이들의 조합으로서 구현될 수 있음을 잘 이해할 것이다. 하드웨어 및 소프트웨어의 상호 호환성을 명확히 하기 위해, 다양한 예시적인 소자들, 블록, 모둘, 회로, 및 단계들이 그들의 기능적 관점에서 기술되었다. 이러한 기능이 하드웨어 또는 소프트웨어로 구현되는지는 특정 애플리케이션 및 전체 시스템에 대해 부가된 설계 제한들에 의존한다. 당업자는 이러한 기능들을 각각의 특정 애플리케이션에 대해 다양한 방식으로 구현할 수 있지만, 이러한 구현 결정이 본발명의 영역을 벗어나는 것은 아니다.
다양한 예시적인 논리 블록들, 모듈들, 및 회로들이 범용 프로세서; 디지털 신호 처리기, DSP; 주문형 집적회로, ASIC; 필드 프로그램어블 게이트 어레이, FPGA; 또는 다른 프로그램어블 논리 장치; 이산 게이트 또는 트랜지스터 논리; 이산 하드웨어 컴포넌트들; 또는 이러한 기능들을 구현하도록 설계된 것들의 조합을 통해 구현 또는 수행될 수 있다. 범용 프로세서는 마이크로 프로세서 일 수 있지만; 대안적 실시예에서, 이러한 프로세서는 기존 프로세서, 제어기, 마이크로 제어기, 또는 상태 머신일 수 있다. 프로세서는 예를 들어, DSP 및 마이크로프로세서, 복수의 마이크로프로세서들, DSP 코어와 결합된 하나 이상의 마이크로 프로세서, 또는 이러한 구성들의 조합과 같이 계산 장치들의 조합으로서 구현될 수 있다.
상술한 방법의 단계들 및 알고리즘은 하드웨어에서, 프로세서에 의해 실행되 는 소프트웨어 모듈에서, 또는 이들의 조합에 의해 직접 구현될 수 있다. 소프트웨어 모듈들은 랜덤 액세스 메모리(RAM); 플래쉬 메모리; 판독 전용 메모리(ROM); 전기적 프로그램어블 ROM(EPROM); 전기적 삭제가능한 프로그램어블 ROM(EEPROM); 레지스터; 하드디스크; 제거가능한 디스크; 컴팩트 디스크 ROM(CD-ROM); 또는 공지된 저장 매체의 임의의 형태로서 존재한다. 예시적인 저장매체는 프로세서와 결합되어, 프로세서는 저장매체로부터 정보를 판독하여 저장매체에 정보를 기록한다. 대안적으로, 저장 매체는 프로세서의 구성요소일 수 있다. 이러한 프로세서 및 저장매체는 ASIC 에 위치한다. ASIC 는 사용자 단말에 위치할 수 있다. 대안적으로, 프로세서 및 저장 매체는 사용자 단말에서 이산 컴포넌트로서 존재할 수 있다.
상술한 실시예들은 당업자가 본원발명을 보다 용이하게 실시할 수 있도록 하기 위해 기술되었다. 따라서 당업자는 본원발명이 상술한 실시예들로 제한되지 않으며 본 발명의 기술적 사상에 근거하여 다양한 변형이 가능함을 잘 이해할 것이다.

Claims (10)

  1. 무선 통신 장치상에 위치하는 PPP 서버와 점 대 점 프로토콜(PPP) 클라이언트 사이에서 프로토콜 동기화 주기를 연장하는 방법으로서,
    PPP 클라이언트로부터의 인터넷 프로토콜 제어 프로토콜(IPCP) 구성(configuration) 요청에 응답하여 PPP 서버에서 부정 확인응답(Nak) 메세지를 생성하는 단계 - 여기서 상기 부정 확인응답 메세지는 의도적으로 임의의(arbitrary) 보충 IPCP 정보를 포함하며, IP 어드레스 옵션을 포함하지 않음 - ; 및
    PPP 서버가 프로토콜 동기화 주기를 완성하기 위해 필요한 모든 파라미터들을 수신하였다면, PPP 클라이언트로부터의 IPCP 구성 요청에 응답하여 PPP 서버에서 긍정 확인응답(Ack) 메세지를 생성하는 단계를 포함하는 프로토콜 동기화 주기 연장 방법.
  2. 제1항에 있어서,
    PPP 클라이언트로부터의 반복된 IPCP 구성 요청에 응답하여 PPP 서버에서 새로운 부정 확인응답 메세지를 생성하는 단계를 더 포함하며, 상기 새로운 부정 확인응답 메세지는 이전의 부정 확인응답 메세지와는 다른 보충 IPCP 정보를 포함하며, IP 어드레스 옵션을 포함하지 않는 프로토콜 동기화 주기 연장 방법.
  3. 제1항에 있어서,
    PPP 클라이언트로부터의 반복된 IPCP 구성 요청에 응답하여 PPP 서버에서 새로운 부정 확인응답 메세지를 생성하는 단계를 더 포함하며, 상기 새로운 부정 확인응답 메세지는 이전의 부정 확인응답 메세지와 동일한 보충 IPCP 정보를 포함하며, IP 어드레스 옵션을 포함하지 않는 프로토콜 동기화 주기 연장 방법.
  4. 제1항에 있어서,
    상기 임의의 보충 IPCP 정보는 임의의 도메인 네이밍 시스템(DNS) 어드레스인 프로토콜 동기화 주기 연장 방법.
  5. 제1항에 있어서,
    상기 임의의 보충 IPCP 정보는 임의의 윈도우 인터넷 네이밍 시스템(WINS) 어드레스인 프로토콜 동기화 주기 연장 방법.
  6. 무선 통신 장치상에 위치하는 PPP 서버와 점 대 점 프로토콜(PPP) 클라이언트 사이에서 프로토콜 동기화 주기를 연장하는 장치로서, 상기 장치는
    적어도 하나의 메모리 엘리먼트; 및
    상기 적어도 하나의 메모리 엘리먼트에 저장된 한 세트의 지령들을 실행하도록 구현되는 적어도 하나의 처리 엘리먼트를 포함하며, 상기 한 세트의 지령들은
    PPP 클라이언트로부터의 인터넷 프로토콜 제어 프로토콜(IPCP) 구성(configuration) 요청에 응답하여 PPP 서버에서 부정 확인응답(Nak) 메세지를 생성 하는 지령 - 여기서 상기 부정 확인응답 메세지는 의도적으로 임의의(arbitrary) 보충 IPCP 정보를 포함하며, IP 어드레스 옵션을 포함하지 않음 - ; 및
    PPP 서버가 프로토콜 동기화 주기를 완성하기 위해 필요한 모든 파라미터들을 수신하였다면, PPP 클라이언트로부터의 IPCP 구성 요청에 응답하여 PPP 서버에서 긍정 확인응답(Ack) 메세지를 생성하는 지령을 포함하는 프로토콜 동기화 주기 연장 장치.
  7. 제6항에 있어서,
    상기 적어도 하나의 처리 엘리먼트는 PPP 클라이언트를 호스트하는 동일한 전자 장치에 위치하는 프로토콜 동기화 주기 연장 장치.
  8. 제7항에 있어서,
    상기 적어도 하나의 처리 장치는 PPP 클라이언트를 호스트하지 않는 전자 장치에 위치하는 프로토콜 동기화 주기 연장 장치.
  9. 무선 통신 장치상에 위치하는 PPP 서버와 점 대 점 프로토콜(PPP) 클라이언트 사이에서 프로토콜 동기화 주기를 연장하는 장치로서,
    PPP 클라이언트로부터의 인터넷 프로토콜 제어 프로토콜(IPCP) 구성(configuration) 요청에 응답하여 PPP 서버에서 부정 확인응답(Nak) 메세지를 생성하는 수단 - 여기서 상기 부정 확인응답 메세지는 의도적으로 임의의(arbitrary) 보충 IPCP 정보를 포함하며, IP 어드레스 옵션을 포함하지 않음 - ; 및
    PPP 서버가 프로토콜 동기화 주기를 완성하기 위해 필요한 모든 파라미터들을 수신하였다면, PPP 클라이언트로부터의 IPCP 구성 요청에 응답하여 PPP 서버에서 긍정 확인응답(Ack) 메세지를 생성하는 수단을 포함하는 프로토콜 동기화 주기 연장 방법.
  10. PPP 서버와 점 대 점(PPP) 클라이언트 사이에서 프로토콜 동기화 주기를 연장하는 방법으로서,
    PPP 클라이언트를 인터넷 프로토콜 제어 프로토콜(IPCP) 협상에 관여시키는 단계; 및
    의도적으로 임의의 IPCP 어드레스를 갖는 구성 요청 메세지들을 PPP 클라이언트가 생성하도록 트리거링하는 단계를 포함하는 프로토콜 동기화 주기 연장 방법.
KR1020067003779A 2003-08-26 2006-02-24 Ｉｐｃｐ 협상중에 ｐｐｐ 타임아웃을 방지하는 방법 및 장치 KR101073268B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US10/649,552 US7412528B2 (en) 2000-01-14 2003-08-26 Avoiding PPP time-outs during IPCP negotiations
US10/649,552 2003-08-26
PCT/US2004/026346 WO2005022642A1 (en) 2003-08-26 2004-08-12 Avoiding ppp time-outs during ipcp negotiations

Publications (2)

Publication Number Publication Date
KR20060133950A true KR20060133950A (ko) 2006-12-27
KR101073268B1 KR101073268B1 (ko) 2011-10-12

Family

ID=34273344

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020067003779A KR101073268B1 (ko) 2003-08-26 2006-02-24 Ｉｐｃｐ 협상중에 ｐｐｐ 타임아웃을 방지하는 방법 및 장치

Country Status (5)

Country Link
US (1) US7412528B2 (ko)
KR (1) KR101073268B1 (ko)
BR (1) BRPI0413918A (ko)
IL (1) IL173704A (ko)
WO (1) WO2005022642A1 (ko)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6865169B1 (en) 1999-11-02 2005-03-08 Ipwireless, Inc. Cellular wireless internet access system using spread spectrum and internet protocol
US8463231B1 (en) * 1999-11-02 2013-06-11 Nvidia Corporation Use of radius in UMTS to perform accounting functions
US6775553B1 (en) * 2000-01-14 2004-08-10 Qualcomm Incorporated Method of avoiding PPP time-outs during IPCP negotiations
DE10048487A1 (de) * 2000-09-29 2002-04-18 Siemens Ag Verfahren zum Anschluß von Datenendeinrichtungen an ein Datennetz
US7287079B2 (en) * 2001-06-29 2007-10-23 Qualcomm Incorporated Implementing and coordinating configuration of protocol processes
US7451209B1 (en) 2003-10-22 2008-11-11 Cisco Technology, Inc. Improving reliability and availability of a load balanced server
US7421695B2 (en) * 2003-11-12 2008-09-02 Cisco Tech Inc System and methodology for adaptive load balancing with behavior modification hints
US6947406B2 (en) * 2003-12-23 2005-09-20 Motorola, Inc Establishing connections between terminal equipment and a mobile terminal
KR100617672B1 (ko) * 2003-12-26 2006-08-28 삼성전자주식회사 이동통신 단말기와 기지국 간에 점대 점 프로토콜 연결설정 방법
JP4533247B2 (ja) * 2004-06-08 2010-09-01 キヤノン株式会社 サービス提供システム、サービス提供方法及びサービス提供装置
CN100589374C (zh) * 2004-07-08 2010-02-10 中兴通讯股份有限公司 一种使用点到点协议时防止ip地址泄漏的方法
US20060034256A1 (en) * 2004-08-13 2006-02-16 Nokia Corporation System and method for service discovery during connection setup in a wireless environment
US7586876B2 (en) * 2004-08-30 2009-09-08 Samsung Electronics Co., Ltd Handoff system and method between a wireless LAN and mobile communication network
TWI272811B (en) * 2004-12-23 2007-02-01 Mediatek Inc Method of negotiation for IP configuration, machine readable medium thereof, and terminal equipment and mobile terminal utilizing same
US20060165093A1 (en) * 2005-01-27 2006-07-27 Utstarcom, Inc. Method and apparatus to support multi-stack hang time usage and multi-stack accounting
CN100518185C (zh) * 2005-04-29 2009-07-22 华为技术有限公司 Ppp接入终端获取运营商服务器地址的方法
CN100399751C (zh) * 2006-01-20 2008-07-02 北京朗通环球科技有限公司 一种检测和维护ppp链路的方法
CN101257496B (zh) * 2006-11-13 2011-03-30 华为技术有限公司 一种获取配置信息的方法和系统
US8060653B2 (en) * 2007-04-23 2011-11-15 Ianywhere Solutions, Inc. Background synchronization
CN101646205B (zh) * 2008-08-05 2014-07-09 华为技术有限公司 移动网络高速接入公网的节点、方法及系统
US8769367B2 (en) * 2010-01-28 2014-07-01 Mediatek Inc. Apparatus, method, and system for IP address negotiations
US10715349B2 (en) * 2018-07-12 2020-07-14 Raytheon Company PPPoE extension over layer 2 switch embedding PPPoE agent

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE59611095D1 (de) 1995-07-05 2004-10-28 Siemens Ag Einrichtung (iwf) zum bidirektionalen verbinden eines elan und eines cls-weitverkehrsnetzes
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
KR100260516B1 (ko) 1997-04-01 2000-07-01 정선종 코드분할 다중접속 이동통신망에서의 비동기통신 데이터발신호 및 착신호 서비스 방법
US6061739A (en) 1997-11-26 2000-05-09 International Business Machines Corp. Network address assignment using physical address resolution protocols
FI105976B (fi) 1998-02-09 2000-10-31 Nokia Networks Oy Matkaviestimen suurinopeuksinen liityntä TCP/IP-verkkoon
US6212563B1 (en) 1998-10-01 2001-04-03 3Com Corporation Method and system for setting and managing externally provided internet protocol addresses using the dynamic host configuration protocol
US6483822B1 (en) * 1999-06-07 2002-11-19 Marcello Lioy Establishing a packet network call between a mobile terminal device and an interworking function
US6775553B1 (en) 2000-01-14 2004-08-10 Qualcomm Incorporated Method of avoiding PPP time-outs during IPCP negotiations
US7000031B2 (en) 2000-04-07 2006-02-14 Broadcom Corporation Method of providing synchronous transport of packets between asynchronous network nodes in a frame-based communications network
US20020107514A1 (en) * 2000-04-27 2002-08-08 Hooven Michael D. Transmural ablation device with parallel jaws
US7447182B2 (en) 2001-04-06 2008-11-04 Nortel Networks Limited Discovering an address of a name server
US7342894B2 (en) * 2002-04-03 2008-03-11 Qualcomm Incorporated System and method for transparent Mobile IP registration within PPP negotiation

Also Published As

Publication number Publication date
US20040132473A1 (en) 2004-07-08
US7412528B2 (en) 2008-08-12
KR101073268B1 (ko) 2011-10-12
IL173704A0 (en) 2006-07-05
BRPI0413918A (pt) 2006-11-07
WO2005022642A1 (en) 2005-03-10
IL173704A (en) 2010-12-30

Similar Documents

Publication Publication Date Title
KR101073268B1 (ko) Ｉｐｃｐ 협상중에 ｐｐｐ 타임아웃을 방지하는 방법 및 장치
US8086748B2 (en) Avoiding PPP time outs during IPCP negotiations
EP1504617B1 (en) Method and system for performing the transfer of provisioning data in a wireless communication system
US7369529B2 (en) Method and apparatus for differentiating point to point protocol session termination points
US6785823B1 (en) Method and apparatus for authentication in a wireless telecommunications system
KR101192523B1 (ko) 서로 다른 링크 확립 프로토콜을 가진 네트워크들에 대한 핸드오프 지원
US20050201388A1 (en) Method and apparatus for providing a VPN service according to a packet data protocol in a wireless communication system
JP4625081B2 (ja) ネットワーク・アクセスのための早いリンク確立
US20070140252A1 (en) Fast call setup method
JP5680688B2 (ja) つながれた装置のための代理暗号化認証の方法と装置
RU2304854C2 (ru) Способ определения согласованных вариантов конфигурации для линии радиосвязи, использующей сетевую модель
US6978382B1 (en) Method and an apparatus for granting use of a session of a packet data transmission standard designated by an identifier
KR20070103362A (ko) 서로 다른 링크 확립 프로토콜을 가진 네트워크들에 대한핸드오프 지원
US6947406B2 (en) Establishing connections between terminal equipment and a mobile terminal
JP2006019934A (ja) パケット交換網の呼設定方法
Lee et al. A point-to-point protocol improvement to reduce data call setup latency in Cdma2000 system

Legal Events

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

Payment date: 20140929

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20150930

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20160929

Year of fee payment: 6

LAPS Lapse due to unpaid annual fee