KR20020060948A - 효율적인 초기 프로토콜 검출 방법 - Google Patents
효율적인 초기 프로토콜 검출 방법 Download PDFInfo
- Publication number
- KR20020060948A KR20020060948A KR1020027003102A KR20027003102A KR20020060948A KR 20020060948 A KR20020060948 A KR 20020060948A KR 1020027003102 A KR1020027003102 A KR 1020027003102A KR 20027003102 A KR20027003102 A KR 20027003102A KR 20020060948 A KR20020060948 A KR 20020060948A
- Authority
- KR
- South Korea
- Prior art keywords
- information
- byte
- communication device
- bytes
- content
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
- H04W28/18—Negotiating wireless communication parameters
-
- 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- 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
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Quality & Reliability (AREA)
- Communication Control (AREA)
- Mobile Radio Communication Systems (AREA)
- Time-Division Multiplex Systems (AREA)
- Maintenance And Management Of Digital Transmission (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
전체 패킷을 언프레임하지 않고서 PPP 패킷 내의 프로토콜 및 환경설정 메시지를 검출하는 방법 및 시스템. 본 방법은 복수의 데이터 프레임을 수신하는 (S306) 통신 장치 (MT2) 를 포함하고, 이 통신장치는 수신 프레임 내의 정보부분 (S305) 의 시작을 식별할 수 있다. 통신 장치는, 정보 부분이 소정 타입의 프로토콜 및 환경설정 메시지와 같이, 환경설정 메시지를 포함하는지를 검출한다. 제 1 실시형태에서, 검출은 통신장치가 복수 바이트의 콘텐츠를 언이스케이프하고 (S315), 이스케이프된 바이트가 희망 환경설정 정보를 포함하는 지를 판정하여 (S325, S330, S335) 달성된다. 제 2 실시형태에서, 통신 장치는 특정 바이트의 콘텐츠가 이스케이프된 또는 언이스케이프된 형태의 희망 환경설정 정보를 포함하는 지를 판정하고, 통신 장치는, 일반적으로 희망 환경설정 정보를 포함하는 바이트가 처리될 때까지, 정보 부분내의 바이트를 순차적으로 계속 처리한다.
Description
유례없는 인터넷 가입자의 증가뿐만 아니라, 무선 통신 및 컴퓨터 관련 기술의 최근 혁명은 이동 컴퓨팅 (mobile computing) 을 가능하게 하였다. 실제로, 이동 컴퓨팅의 유행은 현재 인터넷 기반 구조에서 이동 사용자에게 더 많은 지원을 제공하기 위해서 더 많은 요구가 요청되고 있다. 이 요청를 충족시키고 사용자에게 필요한 지원을 제공하는 주요 부분은, 무선통신시스템에서의 코드분할 다중접속 (CDMA) 기술의 사용이다.
CDMA 는 제목이 "MOBILE STATION-BASE STATION COMPATIBILITY STANDARD FOR DUAL-MODE WIDEBAND SPREAD SPECTRUM CELLULAR SYSTEM" 이고 1993년 7월 공표된 Telecommunications Industry Association/Electronics Industries Association Interim Standard-95 (TIA/EIA IS-95) 에 규정된 디지털 무선 주파수 (RF) 채널화 기술이다. 이 기술을 사용하는 무선통신시스템은 고유 코드를 통신 신호에 할당하고 이 통신 신호를 공통 (광대역) 확산 스텍트럼 대역폭에 걸쳐 확산시킨다. CDMA 시스템의 수신 장치가 정확한 코드를 갖는한, 그 수신 장치는 동일한 주파수 대역으로 동시에 송신된 다른 신호로부터 그 통신신호를 성공적으로 검출하고 선택할 수 있다. CDMA 의 사용은 시스템 트래픽 용량 (capacity) 을 증가시키고, 전체 통화 품질 및 잡음감소를 개선시키며, 데이터 서비스 트래픽에 대해 신뢰성있는 전송 메카니즘 (transport mechanism) 을 제공한다.
도 1 은 이런 무선 데이터 통신시스템 (100) 의 기본구성 요소들을 나타낸다. 이들 요소들 또는 그들의 인터페이스는 그들의 범위와 기능을 벗어나지 않고, 변형되거나, 보강되거나, 당해기술분야에서 공지된 다양한 표준들에 따를 수 있다. 시스템 (100) 은 이동단말장비, 즉 TE2 장치 (102) (예를 들어, 랩탑 (laptop) 또는 팜탑 (palmtop) 컴퓨터와 같은 단말장비) 가 인터워킹 펑션 (108; IWF; Interworking Function) 과 통신하도록 한다. 시스템 (100) 은 무선 통신 장치, 즉 MT2 장치 (104) (예를 들어, 무선 전화기) 및 기지국/이동국스위칭센터 (BS/MSC; 106)을 포함한다. IWF (108) 는 인터넷 또는 인트라넷 기반 억세스를 제공하는 공중교환전화망 또는 유선 패킷 데이터망과 같은 다른 네트워크와 무선 네트워크사이에서 게이트웨이 (gateway)로서 기능한다.
도 1 에 나타낸 바와 같이, IWF (108) 는 L 인터페이스를 통하여 BS/MSC (106) 에 연결된다. 때때로, IWF (108) 는 BS/MSC (106) 과 함께 위치할 수도 있다. TE2 장치 (102) 는 Rm 인터페이스를 통하여 MT2 장치 (104) 에 전기적으로 연결된다. MT2 장치 (104) 는 무선 인터페이스 Um 을 통하여 BS/MSC (106)와 통신한다. TE2 장치 (102) 및 MT2 장치 (104) 는 단일 유닛으로 통합되거나, 랩탑이 TE2 장치 (102) 이고 트랜시버가 MT2 장치 (104) 인 인스톨된 무선 전화 유닛의 경우와 같이, 분리될 수도 있다. 도 2 에 나타낸 바와 같이, TE2 장치 (102) 및 MT2 장치 (104) 의 조합은, 통합 또는 분리여부에 상관없이, 통상적으로 이동국 (MS; 103) 이라고 한다.
무선 통신의 다른 특성들을 제어, 관리 또는 기타 보조하는 다양한 공지 프로토콜을 적용함으로써, 다른 지원을 할 수 있다. 예를 들어, 인터넷 기반구조의 생명 (life-blood), 즉 인터넷 프로토콜 (IP) 이 패킷 지향 서비스를 지원하기 위해 무선 통신에 통합되고 있다. IP 프로토콜은 호스트 컴퓨터간에 패킷 (데이터그램) 의 어드레싱과 라우팅을 구정하며, 제목이 "INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION" 이고 1981년 9월 공표된 Request For Comment 791 (RFC 791) 에 정의되어 있다.
IP 프로토콜은 데이터를 송신용 IP 패킷으로 캡슐화하는 네트워크계층 프로토콜이다. 패킷의 헤더에, 어드레싱 정보가 첨부된다. IP 헤더 (예를 들어, IP 버전 4) 는 송신 및 수신 호스트를 식별하는 32-비트 어드레스를 포함한다. 이들 어드레스는, 중간 라우터 (intermediate router) 에 의해 사용되어, 의도한 어드레스에 있는 최종 수신지 (ultimate destination) 로 향하는 패킷 네트워크 통과 경로가 선택된다. 따라서, 발신측이 수신측의 IP 주소를 알고 있는 경우에는, IP 프로토콜은 세계 임의의 인터넷 노드에서 발신된 패킷을 세계 임의의 다른 인터넷 노드로 라우팅시킬 수 있게 된다.
무선통신시스템에 통합된 또 다른 공지된 프로토콜은, 점대점 프로토콜 (Point-to-Point Protocol; PPP) 로서, 이는 특히 인터넷 억세스를 제공한다. PPP 프로토콜은 제목이 "THE POINT-TO-POINT PROTOCOL (PPP)" 이고 1994년 7월 공표된 Request for Comment 1661 (RFC 1661) 에 상세하게 설명되어 있다.
이 PPP 프로토콜은 점대점 링크상에서 멀티 프로토콜 데이터그램을 송신하는 방법을 필수적으로 명시하고, 3 개의 주요구성요소, 즉 시리얼 링크상에서 멀티프로토콜 데이터그램을 캡슐화하는 방법; 데이터 링크 연결을 확립하고, 검사하고, 환경설정하고, 유지하는 링크제어 프로토콜 (Link Control Protocol; LCP); 및 다른 네트워크계층 프로토콜을 확립하고 환경설정하는 네트워크제어 프로토콜 (Network Control Protocols; NCPs) 의 패밀리를 포함한다.
무선통신시스템에서 다수의 서비스를 제공하기 위한 노력으로서, TE2 장치 (102) 와 IWF (108) 간에 무선 데이터 전송을 제공하기 위한 다양한 표준이 개발되었다. 예를 들어, 제목이 "DATA SERVICE OPTIONS FOR WIDEBAND SPREAD SPECTRUM SYSTEMS: PACKET DATA SERVICES" 이고 1998년 2월 공표된 TIA/EIA IS-707.5 표준은 TIA/EIA IS-95 시스템에 대한 패킷 데이터 송신 능력 지원을 위한 요구조건을 규정하고, 일련의 패킷 데이터 베어러 서비스를 규정하고 있다. 이와 유사하게, 제목이 "DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS: PACKET DATA SERVICES" 이고 1999년 3월 공표된 TIA/EIA IS-707-A.5 표준, 및 제목이 "DATA SERVICE OPTION FOR SPREAD SPECTRUM SYSTEMS: HIGH SPEED PACKET DATA SERVICE" 이고 1999년 3월 공표된 TIA/EIA IS-707-A.9 표준은 TIA/EIA IS-95 시스템에 대한 패킷 데이터 송신 지원을 위한 요구조건을 규정하고 있다.
이들 표준은 BS/MSC (106) 을 통한 TE2 장치 (102) 와 IWF (108) 간의 통신에 사용할 일정한 패킷 데이터 서비스 옵션을 제공한다. 그렇게 할 경우, IS-707.5 는 네트워크 모델을 도입하고, 이는 Rm 인터페이스, Um 인터페이스 및 L 인터페이스에 대한 패킷 데이터 프로토콜 요건을 상세히 규정한다. 이 모델에서는, 데이터 링크계층에 2 개의 개별 PPP 링크를 제공하며, 제 1 PPP 링크 (PPPR) 는 TE2 장치 (102) 과 MT2 장치 (104) 사이에 (즉, Rm 인터페이스를 통하여) 데이터 링크 계층을 제공하고, 제 2 PPP 링크 (PPPU) 는, 제 1 PPP 링크와는 독립적으로, MT2 장치 (104) 와 IWF (108) 사이에 (즉, Um 및 L 인터페이스를 통하여) 데이터 링크 계층을 제공한다.
독립적이고 분리된 PPP 링크들은 "투명한 이동성(transparent mobility)" 지원을 보조한다. 즉, TE2 장치 (102) 는, 시간과 현재 IWF (108) 부착 포인트 (point-of-attachment) 에 관계없이 끊어짐이 없고 투명한 서비스를 경험하여야 한다. 이와 같이, TE2 장치 (102) 는 위치 변화에 의해 영향을 받아서는 안된다. 예를 들어, TE2 장치 (102) 는, MT2 장치 (104) 가 다른 IWF (108) 에 부착하려고 시도하는 경우 같이, Um 링크상에서 발생하는 PPP 재교섭 (PPP renegotiation) 에 의해 영향을 받아서는 안된다. 따라서, 이 네트워크 모델은, Um 링크상의 변화가 Rm 링크에 영향을 주는 것을 방지하기 위하여, PPPR링크를 PPPU링크로부터 분리시키도록 동작한다. 즉, PPPR링크를 재교섭하지 않고도, PPPU링크를 재교섭할 수 있다.
도 2 는 IS-707.5 네트워크 모델의 각 엔터티에서의 프로토콜 스택을 나타낸다. 도 2 의 좌측에는, TE2 장치 (102) (예를 들어, 이동 단말기, 랩탑 또는 팜탑 컴퓨터) 상에서 운용되는 프로토콜 계층을 나타낸 종래 수직 포맷의 프로토콜스택이 있다. TE2 장치 (104) 프로토콜 스택은 Rm 인터페이스를 통하여 MT2 장치 (104) 프로토콜 스택에 논리적으로 연결되는 것으로 나타내었다. MT2 장치 (104) 는 Um 인터페이스 상으로 BS/MSC (106) 프로토콜 스택에 논리적으로 연결되는 것으로 나타내었다. 또한, BS/MSC (106) 는 L 인터페이스를 통하여 IWF (108) 프로토콜 스택에 논리적으로 연결되는 것으로 나타내었다.
예를 들어, 도 2 에 나타낸 프로토콜은 다음과 같이 동작한다. TE2 (102) 장치상의 PPPR프로토콜 (208) 은 상위 계층 프로토콜 (204) 및 네트워크 계층 IP 프로토콜 (206) 으로부터의 패킷을 인코딩한다. 그 다음에, PPPR프로토콜은 그 패킷을 TIA/EIA 232-F 프로토콜 (210) 을 ㅇ;용하는 Rm 인터페이스를 통하여 TIA/EIA 232-F 프로토콜 (212) 을 실행하는 MT2 장치 (104) 상의 TIA/EIA-232-F 호환 포트로 송신한다. TIA/EIA-232-F 표준은 제목이 "INTERFACE BETWEEN DATA TERMINAL EQUIPMENT AND DATA CIRCUIT TERMINATING EQUIPMENT EMPLOYING SERIAL BINARY DATA INTERCHANGE" 이고 1997년 7월에 공표되었다. Rm 인터페이스를 통한 송신을 규정하기 위해, 공지된 다른 표준 또는 프로토콜을 이용될 수도 있다. 예를 들어, 다른 응용 가능한 Rm 인터페이스 표준은 1998년 9월에 곧표된"UNIVERSAL SERIAL BUS (USB) SPECIFICATION, Revision 1.1" 과 1999년 7월에 공표된 "BLUETOOTH SPECIFICATION VERSION 1.0A CORE" 를 포함한다.
MT2 장치 (104) 상의 TIA/EIA 232-F 프로토콜 (212) 는 TE2 장치 (102) 로부터 패킷을 수신하고, 그 패킷을 PPPR프로토콜 (213) 으로 전달한다. 위에 설명한 바와 같이, PPPR프로토콜 (213) 은 PPP 프레임에 캡슐화된 패킷을 언프레임하고, 일반적으로 데이터 접속이 이루어질 때, 프로토콜 (213) 은 PPPU프로토콜 (217) 로 패킷을 전달한다. 프로토콜 (217) 은 그 패킷을 IWF (108) 에 위치하는 PPPU피어로의 송신을 위하여, 필수적으로 리프레임 (reframe) 한다. 패킷 캡슐화된 PPP 프레임을 Um 인터페이스를 통하여 BS/MSC (106) 으로 송신하는 데는, 당해기술분야에서 공지된 무선 링크 프로토콜 (RLP; 216) 및 IS-95 프로토콜 (214) 을 사용한다. RLP 프로토콜 (216) 은, 제목이 "DATA SERVICE OPTIONS FOR WIDEBAND SPREAD SPECTRUM SYSTEMS: RADIO LINK PROTOCOL" 이고 1998년 2월에 공표된 IS-707.2 표준과, 제목이 "DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS: RADIO LINK PROTOCOL" 이고 1999년 3월에 공표된 IS-707-A.2 표준에 규정되어 있다.
BS/MSC (106) 의 대응하는 RLP 프로토콜 (220) 과 IS-95 프로토콜 (222) 은, L 인터페이스를 통한 IWF (108) 상의 릴레이 계층 프로토콜 (234) 로의 송신을 위하여, 그 패킷을 릴레이 계층 프로토콜 (224) 로 전달한다. 그 후, PPPU프로토콜 (232) 은 그 수신한 패킷을 언프레임하고, 그 언프레임된 패킷을 네트워크 계층 프로토콜 IP (230) 으로 전달하며, 그 다음에 네트워크 계층 프로토콜 IP (230) 은 전달된 패킷을 상위계층 프로토콜 (228) 로 보내거나 인터넷으로 포워딩한다.
위에서 설명한 바와 같이, PPPR프로토콜 (213) 은, 데이터 링크 접속이 확립될 때, 패킷을 PPPU프로토콜 (217) 로 전달한다. RFC 1661 은 데이터 링크 접속을 확립하고, 환경설정하고, 시험하기 위해서는, 각각의 PPP 링크 (즉, PPPR과 PPPU) 를 통하여 링크 제어 프로토콜 (LCP) 패킷을 교환하고 교섭하여야 함을 규정한다. 이와 같이, 이들 LCP 패킷은, 다양한 옵션을 교섭하기 위해, Configure-Request, Configure-Ack, Configure-Nak, Protocol-Reject, 및 Configue-Reject 메시지를 포함하며 다음과 같이 동작한다. 즉, 환경설정 옵션을 교섭하기 위해 Configure-Request 패킷을 사용한다. Configuration-Ack 패킷은 수신 Configuration-Request 패킷내의 모든 환경설정 옵션을 인식할 수 있고 (recognizable) 모든 값들이 수용 가능한 경우에만, 송신된다. 그 요청된 Configuration-Request 패킷내의 환경설정 옵션을 인식할 수 있지만, 허용 불가한 값을 포함하고 있고, Configure-Nak 옵션 필드가 수용 불가한 Configuration-Request 환경설정 옵션과 동작할 제안값으로 채워져 잇는 경우, Configure-Nak 패킷이 송신된다. 그 요청된 Configure-Request 내의 환경설정 옵션이 수신기에 의해 이해되지 않는 환경설정 옵션을 포함하고 Configure-Reject 옵션 필드가 비인식 Configure-Request 환경설정 옵션을 포함하는 경우, Configure-Reject 패킷이송신된다.
일단 LCP 패킷을 교환하여, 링크 옵션을 교섭하고, 데이터 링크 접속을 확립하면, TE2 장치 (102) 와 IWF (108) 사이에 네트워크 계층 접속을 확립하여야 한다. 이 접속은, 예를 들어 IP 프로토콜을 포함한, 프로토콜 (206, 212, 218, 230) 을 통하여 달성한다. PPP 링크 양쪽단에서의 IP 프로토콜의 교섭, 환경설정, 인에이블링, 디스에이블링은 인터넷 프로토콜 제어 프로토콜 (IPCP) 에 의해 제공된다. IPCP 는 PPP 프로토콜에 포함된 네트워크 제어 프로토콜 (NCPs) 의 패밀리의 일부이며, 제목이 "THE PPP INTERNET PROTOCOL CONTROL PROTOCOL (IPCP)" 이고 1992년 5월 공표된 Request for Comment (RFC) 1332 에 설명되어 있다.
IPCP 프로토콜은 LCP 프로토콜과 동일한 환경설정 옵션 교섭 메카니즘을 이용하고, LCP 프로토콜과 매우 유사하게, IPCP 교섭이 Rm 인터페이스 및 Um 인터페이스 양쪽에 대하여 개별적으로 발생한다. RFC 1661 에 설명된 바와 같이, Configuration-Ack 패킷은 센더 (Sender) 가 응답할 옵션의 리스트를 포함한다. MT2 장치 (104) 는 Rm 및 Um 인터페이스를 통하여 수신 및 송신되는 Configuration-Ack 패킷을 모니터하고, 컴퓨터 메모리와 같은 스토리지 장치에 각 옵션의 값을 저장한다. 모든 환경설정 옵션은 RFC 1661 에 의해 정의되는 디폴트 값을 가지고, 이 값은 해당 환경설정 옵션이 교섭되지 않을 때 사용한다. 환경설정 옵션 디폴트 값은 예를 들어, 제목이 "PPP internet Protocol Control Protocol Extension for Name Server Addresses" 이고 1995년 12월 공표된 RFC 1877 과 같은 다른 RFCs 에 의해 정할 수도 있다.
네트워크 모델에 관하여 위에서 설명한 바와 같이, PPPR링크를 재교섭하지 않고, PPPU링크를 재교섭할 수 있다. 이러한 Rm 과 Um 인터페이스간의 분리를 유지하기 위하여, 일반적으로 MT2 장치 (104) 는 수신한 PPP 패킷을 언프레임하고 리프레임한다. MT2 장치 (104) 에 의해 수신한 패킷이 MT2 장치 (104) 내의 실행할 상위 계층 프로토콜로 보낼 것이 아닐 경우에만, PPP 피어 프로토콜로의 후속 송신을 위하여 그 PPP 패킷을 언프레임하여 리프레임한다. 이런 언프에이밍/리프레이밍 (reframing/unframing) 은, 그 패킷이 MT2 장치 (104) 에서 또 다른 처리를 요구하지 않을 때에도, 발생한다. 예를 들어,최초에 발호될 때, LCP 및 IPCP 메카니즘은 Um 및 Rm 인터페이스 양쪽에 대하여 교섭하여, 동일한 환경설정 옵션을 확립할 수 있다. 환경설정 옵션이 동일하게 유지되는한, MT2 장치 (104) 가 패킷을 언프레임/리프레임함이 없이, (그 환경설정 옵션에 대해 반대인)모든 PPP 데이터 패킷을 하나의 인터페이스에서 다른 인터페이스로 "전달 (pass through)" 할 수 있다. 명백하게, 환경설정 옵션이 동일한 경우에는, MT2 장치 (104) 는 불필요한 패킷 언프레이밍/리프레이밍 동작을 너무 많이 수행한다. 이러한 동작은 MT2 장치 (104) 의 처리 리소스 (processing resource) 와 스루풋 대기시간 (throughput latency) 에 악영향을 미친다.
그러나, 환경설정 옵션이 변화하면, 환경설정 옵션을 재교섭하여야 하므로, PPP 패킷을 언프레임/리프레임하는 데 유리하게 작용한다. 예를 들어, MT2 장치 (104) 가 이동체라는 사실로 인하여, 본래의 IWF (108) 와는 다른 IWF (108) 에의해 서비스되는 영역으로 이동할 수 있게 된다. 이것이 발생할 경우, MT2 장치 (104) 는 서비스를 위한 새로운 IWF (108) 로 "핸드 오프" 될 것이다. 이 핸드오프는 MT2 장치 (104) 의 개입뿐만 아니라 Um 인터페이스를 통한 특정 LCP 및 IPCP 환경설정 옵션의 재교섭을 요구한다. 환경설정 메시지 (예를 들어, Configure-Request, Configure-Ack, Configure-Nak 등) 을 포함하는 패킷이, 패킷의 콘텐츠를 언프레임 또는 감시하지 않고 단순히 "전달 (pass through)" 되는 경우, 그 패킷은 전체 링크의 엔드-투-엔드 재동기가 되어, Rm 및 Um 링크의 독립성이 종결되게 된다.
따라서, PPP 패킷을 언프레임하지 않고, 초기 프로토콜 및 환경설정 메시지를 검출할 수 있는 신규하고도 효율적인 방법 및 시스템이 요청되고 있다.
일반적으로, 본 발명은 무선통신분야에 관한 것이다. 보다 구체적으로, 본 발명은 전체 PPP 패킷을 언프레임하지 않고 초기 프로토콜 및 환경설정 메시지 검출을 수행하는 신규한 방법 및 시스템에 관한 것이다.
본 명세서에 포함되고 본 명세서의 일부를 구성하는 첨부도면은 본 발명의 실시형태를 나타내고, 그의 설명과 함께, 본 발명의 목적, 이점, 및 원리를 설명한다.
도 1 는 무선통신장치의 다양한 요소를 나타내는 하이레벨 블록도이다.
도 2 는 무선통신시스템의 프로토콜 스택을 개략적으로 나타낸 도면.
도 3 은 본 발명의 제 1 실시형태를 나타내는 플로우차트이다.
도 4A, 4B 는 본 발명의 제 2 실시형태를 나타내는 플로우차트이다.
도 5 는 PPP 프레임에 캡슐화된 일반적인 패킷 포맷을 나타내는 도면이다.
본 발명은, 전체 패킷을 언프레임하지 않고 PPP 패킷에서 프로토콜 및 환경설정 메시지를 검출하는 방법 및 시스템을 제공함으로써, 위에서 확인된 요구를 해결한다.
여기서 구현하고 폭넓게 설명하는 본 발명의 원리에 따른 방법 및 시스템은 복수의 데이터 프레임을 수신하는 통신장치를 포함하고, 이 통신장치는 수신 프레임 내의 정보의 시작부분을 검출할 수 있다. 통신 장치는 그 정보부분이 소정 타입의 프로토콜 및 환경설정 메시지와 같은 환경설정 정보를 포함하는 지를 검출한다. 제 1 실시형태에서는, 이러한 검출은, 통신장치가 복수 바이트의 콘텐츠를 언이스케이프하고 그 이스케이프된 바이트가 희망 환경설정 정보를 포함하는 지를 판정하는 통신 장치에 의해 달성된다. 제 2 실시형태에서는, 통신 장치가 특정 바이트의 콘텐츠가 희망 환경설정 정보를 이스케이프된 또는 언이스케이프된 형태로 포함하는 지를 판정하고, 계속하여 통신 장치는 희망 환경설정 정보를 주로포함하는 바이트가 처리되었거나 정보가 존재하지 않는다고 판정될 때까지, 정보 부분 내의 바이트를 순차 처리한다.
다음의 본 발명의 실시형태의 상세한 설명은 이들을 나타내는 첨부도면을 참조한다. 다른 실시형태도 가능하며, 본 발명의 정신 및 범위를 벗어나지 않고서 실시형태를 변형할 수도 있다. 따라서, 다음의 상세한 설명은 본 발명을 제한하려는 것이 아니다. 오히려, 본 발명의 범위는 첨부되는 청구범위에 의해서 정해진다.
아래 설명하는 본 발명의 실시형태는, 도면에 나타낸 엔터티의 소프트웨어, 펌웨어, 및 하드웨어 (예를 들어, TE2 장치 (102), MT2 장치 (104), BS/MSC (106) 및 IWF (108)) 를 포함한, 다양한 방법으로 구현할 수 있다. 본 발명은, 본 발명을 구현하는 데 사용하는 실제 소프트웨어 코드 또는 제어 하드웨어에 의해 제한되지 않는다. 따라서, 본 발명의 동작 및 작용을, 실제 소프트웨어 코드나 하드웨어 구성요소를 특정히 언급하지 않고 설명한 것이다. 이러한 비특정 언급 (non-specific reference) 은, 상세한 설명에 기초하여 본 발명의 실시형태를 구현하기 위해 당업자가 소프트웨어와 제어 하드웨어를 설계할 수 있기 때문에 가능하다.
여기서 설명하는 실시형태는 HDLC 프레임에 캡슐화된 PPP 패킷에서 동작하기 때문에, 도 5 는 이들 패킷의 다양한 속성 (attribute) 을 나타낸다. 프레임의 시작 ( 및 끝) 은 16 진 문자인 "7E" 로 표현되는 1 바이트 프레이밍 플래그에 의해 구분된다. 후속 2 바이트는 표준 PPP 패킷에서, 일반적으로 16 진 문자 "FF" 및 "03" 으로 각각 지정되는 프로토콜 어드레스 및 제어필드를 나타낸다. 다음 2 바이트는 예를 들어, 16 진 문자 "C0" 및 "21" 로 표시되는 LCP 프로토콜; 16 진 문자 "80" 및 "21" 로 표시되는 IPCP 프로토콜; 또는 16 진 문자 "00 (압축될 수도 있음)" 및 "2D" 로 표시되는 Van Jacobson 프로토콜 압축 상태와 같은 프로토콜 타입을 나타낸다. 후속 바이트는, 16 진 문자 "01" 로 표시되는 Configure-Request; 16 진 문자 "02" 로 포시되는 Configure-Ack; 또는 16 진 문자 "03" 으로 표시되는 Configure-Nak 와 같은 코드 또는 환경설정 메시지를 나타낸다.
1. 제 1 실시형태
도 3 은 본 발명의 제 1 실시형태를 나타내는 플로우차트이다. 이와 같이, 도 3 은 PPP 패킷에서 초기 프로토콜 및 환경설정 메시지 검출을 수행하는 MT2 장치 (104) 의 동작을 상세히 나타낸다.
단계 S305 에서, MT2 장치 (104) 는 우선, 인입 데이터 스트림을 스캔하여, 16 진 문자 "7E" 로 나타내는 프레이밍 프래그를 검출한다. 이 플래그는 프레임을 구분하고, 따라서 PPP 프레임에 캡슐화된 패킷의 시작 및/또는 끝을 표시하는 데 사용할 수 있다. MT2 장치 (104) 가 "7E" 프레이밍 플래그를 검출하지 않는 경우, MT2 장치 (104) 는 단계 S306 에 의해 나타낸 바와 같이, 플래그를 검출할 때까지 인입 데이터를 계속 스캐닝한다. 일단 MT2 장치 (104) 가 "7E" 프레이밍 플래그를 검출하면, MT2 장치 (104) 는 단계 S310 으로 진행한다.
"7E" 플래그를 검출한 후에, MT2 장치 (104) 는, 단계 S310 에서, 다음 바이트도 "7E" 플래그인지를 판정한다. 그럴 경우, MT2 장치 (104) 는, 단계 S320 에 나타낸 바와 같이, 특정 바이트를 스킵 (skip) 하고, 단계 S310 으로 복귀하여, 다음 바이트에 대해 "7E" 플래그 시험을 실시한다. 다음 바이트가 "7E" 플래그가 아닐 경우, MT2 장치 (104) 는 단계 S315 로 진행한다. 인입 데이터 스트림은, 프레임의 끝을 표시하는 "7E" 플래그가 새로운 프레임의 시작을 표시하는 후속 "7E" 플래그와 나란히 놓여지는(juxtaposed) 백투백 (back-to-back) 패킷의 경우와 같이 연속하는 "7E"플래그를 포함할 수도 있다. 단계 S310 과 S320 은 프레이밍 플래그를 필터링 아웃하도록 실행됨으로써, MT2 장치 (104) 가 프레임된 패킷의 정보 부분이 시작하는 위치를 식별할 수 있도록 한다.
다음 바이트가 "7E" 플래그가 아니고, 정보 바이트라는 것을 알 경우, MT2 장치 (104) 는, 단계 S315 에서, 다음 X 개의 바이트를 "언이스케이프 (unescape)" 하고, 여기서 X 는 프레임된 패킷에서 구한 정보의 상대 위치에 해당한다. 이러한 언이스케이핑은 PPP 프로토콜이 비동기 HDLC 형 프레이밍 (즉, RFC 1662 에 따라서) 으로 송신될 때 그 프로토콜이 "이스케이핑 기술 (escaping technique)" 을 이용하여, 특정 제어 문자로서도 기능하는 패킷의 정보 부분내의 특정 문자를 마스킹하기 때문에, 수행된다. 이러한 문자는 이스케이프 플래그 "7E" 뿐만 아니라 상술한 "7E" 플래그를 포함한다. 이들 문자가 프레임된 패킷의 정보 부분에 있을 경우, 이스케이핑 기술은 문자 앞의 이스케이프 플래그 "7D"를 스터핑 (stuff) 하고, 그 제어 기능을 무효화하기 (netralize) 위하여 문자를 변경한다. 따라서, 인입 데이터 스트림으로부터 특정 프로토콜 또는 환경설정 정보를 구하려고 할때, MT2 장치 (104) 는, 단계 S315 에서, 그것의 실제 아이덴터티를 언커버하기 위하여 구해진 정보에 억세스하는 데 필요한 개수의 바이트들을 언이스케이프한다. X 바이트를 언이스케이프한 후에, MT2 장치 (104) 는 단계 S325 로 진행한다.
단계 S325 에서, MT2 장치 (104) 는 언이스케이프된 X 바이트가 표준 PPP 어드레스, 및 제어 필드 문자 "FF" 와 "03"을 각각 포함하는 지를 판정한다. 일반적으로, 이들 문자는 PPP 패킷의 정보 부분의 제 1 및 제 2 바이트 (예를 들어 도5 참조) 를 포함함에도 불구하고, 이들 문자는 패킷으로부터 압축할 수 있기 때문에, 후속 정보 바이트 (ensuing information byte) 의 위치에 영향을 미친다. 따라서, MT2 장치 (104) 는 나중에 필요한 조절을 행하기 위하여 패킷의 언이스케이프된 바이트내에 이들 문자가 포함되는 지를 체크해야 한다. 문자 "FF" 및 "03" 이 언이스케이프된 바이트에 포함되어 있지 않으면 (즉, 문자 "FF" 및 "03" 이 압축된 경우), MT2 장치 (104) 는, 단계 330에서, 이들 바이트가 구하는 프로토콜 또는 환경설정 메시지를 포함하는 지를 체크한다. 그럴 경우, MT2 장치 (104) 는, 단계 340 에서, 패킷을 언프레임하고, 검출된 정보에 의해 지시되는 처리시에 사용하기 위하여 전체 패킷을 MT2 장치 (104) 언프에이머 (unframer) 로 포워딩한다. 바이트가 구하는 정보를 포함하지 않을 경우, 단계 S345 에 나타낸 바와 같이, MT2 장치 (104) 는 전체 패킷을 MT2 장치 (104) 송신 부분으로 송신하여 관련 인터페이스를 통하여 포워딩한다.
단계 S325 로 복귀하여, 언이스케이프된 X 바이트가 "FF" 및 "03" 을 포함할 경우, MT2 장치 (104) 는, 단계 S335 에서, 특정 X 바이트 이외에 다른 2 바이트를 언이스케이프하여 보상한다. 이는 X 바이트 내에 "FF" 및 "03" 문자를 포함시키는 것을 조절한다. 그후, MT2 장치 (104) 는 X+2 언이스케이프된 바이트를 단계 330 으로 제공하여, 상술한 바와 같이, MT2 장치 (104) 는 언이스케이프 바이트가 희망 정보를 포함하는 지를 체크한다. 그럴 경우, MT2 장치 (104) 는, 단계 S340 에서, 전체 패킷을 MT2 장치 (104) 언프레이머로 포워딩한다. 바이트가 구하는 프로토콜 또는 환경설정 메시지 정보를 포함하지 않으면, MT2 장치(104) 는 단계 S345 에서 전체 패킷을 MT2 장치 (104) 송신 부분으로 송신하여 관련 인터페이스를 통하여 패킷을 포워딩한다.
LCP 프로토콜 패킷의 초기 검출이 요구되는 것으로 가정하여, 본 실시형태의 동작을 설명한다. LCP 프로토콜 사양 (specification) 은 PPP 프레임된 패킷의 프로토콜 정보 부분에 제공된다. 도 5 에 나타낸 바와 같이, 프로토콜 정보는 2 바이트 길이이고, 일반적으로 표준 PPP 프레임된 패킷의 정보부분의 바이트 위치 3 및 4 를 점유한다. 인입 데이터 스트림을 스캔하고, 정보 바이트가 시작하는 위치를 식별한 후에 (즉, 단계 S305, S310, 및 S320), MT2 장치 (104) 는 단계 S315 에 나타낸 바와 같이, 다음 2 바이트 (즉, X 는 2 와 동일함) 를 언이스케이프한다. 단계 S325 에서, 첫번째 2 바이트가 "FF" 및 "03" 문자를 포함하지 않을 경우, MT2 장치 (104) 는 이들 바이트가 구하는 LCP 정보를 포함하는 지를 체크한다. 그럴 경우, MT2 장치 (104) 는, 단계 S340 에서, 패킷을 언프레임하고 LCP 프로토콜 정보에 의해 요구되는 처리시에 사용(engage) 하기 위하여, 전체 패킷을 MT2 장치 (104) 언프레이머로 포워딩한다. 바이트가 LCP 정보를 포함하지 않을 경우, 단계 S345 에 나타낸 바와 같이, MT2 장치 (104) 는 전체 패킷을 MT2 장치 (104) 송신 부분으로 송신하여, 관련 인터페이스를 통하여 포워딩한다.
한편, 언이스케이프된 X 바이트 중의 첫 번째 2 바이트가 "FF" 및 "03" 일 경우, MT2 장치 (104) 는, 단계 S335 에서, 첫 번째 2 바이트 이외에, 다음 2 바이트를 언이스케이프하여 보상한다. 그후, MT2 장치 (104) 는 4 개의 언이스케이프 바이트 모두를 단계 S330 으로 제공하고, 상술한 바와 같이, MT2 장치 (104)는, 이들 바이트가 구하는 LCP 정보를 포함하는 지를 체크한다. 그럴 경우, MT2 장치 (104) 는, 단계 S340 에서, 전체 패킷을 MT2 장치 (104) 송신 부분으로 송신한다. 바이트가 LCP 정보를 포함하지 않을 경우, MT2 장치 (104) 는 단계 S345에서 전체 패킷을 MT2 장치 (104) 송신 부분으로 송신한다.
위에 설명한 실시형태에 의하면, PPP 프레임된 패킷내에 포함되는 헤더 정보 모두를 전체 패킷을 언프레임하지 않고도 검출할 수 있다. 예를들어, 단계 S315 에서 X 값을 간단히 조절함으로써, 본 실시형태는 프로토콜 정보, 환결설정 메시지, 패킷 ID 등과 같은 PPP 정보를 검출할 수 있다.
따라서, 본 실시형태는 전체 패킷을 언프레임하지 않고도, PPP 패킷 스트림내의 프로토콜 및 환경설정 메시지를 검출한다. 더욱이, 패킷의 정보 부분내의 특정 바이트를 언이스케이프함으로써, 본 실시형태는 불필요한 PPP 패킷 언프레이밍/리프레이밍 동작을 수행하지 않고, 프로토콜 및 환경설정 메시지를 효율적으로 검출하는 시스템 및 방법을 제공한다.
2. 제 2 실시형태
도 4A, 4B는 본 발명의 제 2 실시형태를 나타내는 플로우차트이다. 본 실시형태는 패킷을 언프레임하지 않고 인입 데이터 스트림을 스캐닝하고 스테이지 (stage) 들에서 정보 바이트를 기계적으로 체크하여, PPP 프레임된 패킷의 정보 부분내에 포함된 프로토콜과 환경설정 메시지를 검출한다. 도 5 에 나타낸 바와 같이, PPP 프레임된 패킷의 포맷이 주어지면, 제 1 스테이지는 패킷의 정보 부분내에 포함된 1 바이트 어드레스 필드의 콘텐츠를 자세하게 검출한다. 제 2 스테이지는 어드레스 필드에 후속하는 1 바이트 제어 필드의 콘텐츠를 검출하는 것이다. 따라서, 본 실시형태는 스테이지를 진행하여(advance), 정보 부분의 끝까지, 모든 정보 필드의 콘텐츠를 검출할 수 있다. 예를 들어, 제 3 스테이지는 제어 필드에 후속하는 2 바이트 프로토콜 필드의 콘텐츠를 검출하는 것이다. 그러나, 본 실시형태의 PPP 프레임된 패킷 구조 및 순차적 특성으로 인하여, 그 프레임의 후속 필드들에 포함된 정보는 일반적으로 앞서는 필드에 포함된 정보를 처리하고 검출한 후에 검출한다.
본 실시형태의 대표적인 예로서, 구하는 정보가 제어 필드에 포한된다고 가정한다. 이 필드에 억세스하여 인입 데이터 스트림으로부터 관련 정보를 검출하기 위하여, MT2 장치 (104) 는 우선 PPP 패킷의 정보 부분의 시작을 식별하고, 어드레스 필드내의 정보를 검출한다. 어드레스 필드 정보를 처리한 후에, MT2 장치 (104) 는 제어 필드 정보에 억세스하고 검출할 수 있다.
이와 같이, 도 4A 는 본 실시형태의 제 1 스테이지를 나타낸다. 단계 S405 에서, MT2 장치 (104) 는 우선 인입 데이터 스트림을 스캔하여 프레이밍 플래그 "7E" 를 검출한다. "7E" 를 검출한 후에, MT2 장치 (104) 는, 단계 S410 에서, 다음 바이트도 "7E" 플래그인지를 판정한다. 그럴 경우, 단계 S415 에 나타낸 바와 같이, MT2 장치 (104) 는, 다음 바이트로 이동하고, 단계 S410 으로 복귀하여 다음 바이트에 대해 "7E" 플래그 시험을 행한다. 다음 바이트가 "7E" 플래그가 아닐 경우, MT2 장치 (104) 는 단계 S420 으로 진행한다. 제 1 실시형태와 관련하여 위에서 설명한 바와 같이, MT2 장치 (104) 가 PPP 프레임된 패킷의 정보부분의 시작을 식별할 수 있도록, 단계 S410 과 S415 는 프레이밍 플래그를 필터아웃한다.
MT2 장치 (104) 가 시작 정보 부분을 식별할 수 있으면, MT2 장치 (104) 는 PPP 패킷의 포맷을 사용 (exploit) 하여. 스테이지들에서 정보를 검출한다. 위에서 설명한 바와 같이, 본 실시형태의 제 1 스테이지는 문자 "FF" 를 검출하는 것이다.
단계 S420 에서, MT2 장치 (104) 는 제 1 정보 바이트가 이스케이프 문자 "7D" 인지를 체크한다. 위에 나타낸 바과 같이, 이스케이핑 기술은 특정 문자들의 앞에 이스케이프 플래그 "7D" 를 스터프하여, 그들을 마스크한다. 제 1 정보 바이트가 "7D" 가 아닐 경우 (즉, 제 1 정보 바이트가 이스케이프되지 않으면), MT2 장치 (104) 는, 단계 S425 에서, 제 1 정보 바이트가 "FF" 문자 (즉, 인이스케이프 형태) 인지를 체크한다. 그럴 경우, MT2 장치 (104) 는 단계 S435 로 진행한다. 제 1 정보 바이트가 "FF" 문자가 아닐 경우, MT2 장치 (104) 는, 단계 S426 에서, 구하는 프레임된 패킷에 다른 정보가 있는 지를 판정하고, 그럴 경우, MT2 장치 (1040 는 단계 S427 에서 다음 스테이지로 이동한다. 추가적인 희망 정보가 없을 경우, MT2 장치 (104) 는, 단계 S428 에서, 전체 패킷을 MT2 장치 (104) 송신 부분으로 송신하고, 이 송신 부분은 패킷을 관련 인터페이스를 통하여 포워딩한다.
단계 S420 으로 돌아가서, 제 1 정보 바이트가 "7D" (즉, 제 1 정보 바이트가 이스케이프됨), MT2 장치 (104) 는, 단계 S430에서, 다음 바이트가 이스케이프된 포맷의 "FF" 문자 (즉, 16 진 문자 "DF") 인지를 체크한다. 그럴 경우, MT2 장치 (104) 는 단계 435 로 진행한다. 다음 바이트가 "DF" 문자가 아닐 경우, MT2 장치 (104) 는 단계 S426 으로 진행하고, 위에서 설명한 바와 같이, MT2 장치 (104) 는 다른 희망 정보가 있는 지를 체크한다. 있을 경우, MT2 장치는 단계 S427 에서 다음 스테이지로 이동한다. 다른 추가적인 희망 정보가 없을 경우, MT2 장치 (104) 는, 단계 S428 에서, 전체 패킷을 MT2 장치 (104) 송신 부분으로 송신하고, 패킷을 관련 인터페이스를 통하여 포워딩한다.
단계 S430 에서, 다음 바이트가 이스케이프된 포맷의 "FF" 문자 (즉, 16 진 문자 "DF") 이면, MT2 장치 (104) 는 단계 S435 로 진행하여, 구할 다른 정보가 있는 지를 체크한다. 있을 경우, MT2 장치 (104) 는 단계 S427 에서 다음 스테이지로 이동한다. 추가적인 희망 정보가 없을 경우, MT2 장치 (104) 는, 단계 S437 에서, 패킷을 언프레임하고 검출된 정보가 나타내는 처리시에 사용하기 위하여 전체 패킷을 MT2 장치 (104) 언프레이머로 포워딩한다.
본 실시형태의 제 1 스테이지 (즉, 프로토콜 어드레스 필드에서 "FF" 문자의 검출) 을 완료한 후에, MT2 장치 (104) 는, 나타낸 예의 목적에 부응하여, 제어 필드에서 "03" 문자를 검출하려고 한다. 위에서 나타낸 바와 같이, 본 실시형태에서는 이 검출을 제 2 스테이지 검출이라 하며, 도 4 B 에 도시되어 있다..
단계 S427 에 나타낸 바와 같이, 제 1 스테이지를 완료하고, MT2 장치 (104) 는, 단계 S440 에서, 한번더, 다음 바이트가 "7D" 문자인지를 판정한다. 위에서 설명한 바와 같이, 이 판정은 관련 정보 필드내의 문자가 이스케이프된 경우에 사용한다. 다음 바이트가 "7D" 문자가 아닐 경우, MT2 장치 (104) 는, 단계 S445 에서, 그 바이트가 "03" 문자 (즉, 언이스케이프된 포맷) 인지를 판정한다. 그럴 경우, MT2 장치 (104) 는 단계 S435 로 진행하여, 앞에서와 같이, MT2 장치 (104) 는 구하는 추가 정보가 있는 지를 판정하고, 있을 경우, MT2 장치 (104) 는 단계 S427 에서와 같이 다음 스테이지로 이동한다. 그렇지 않으면, MT2 장치 (104) 는 단계 S428 에서, 전체 패킷을 MT2 장치 (104) 송신 부분으로 포워딩하여 패킷을 관련 인터페이스를 통하여 포워딩한다.
단계 S440 으로 돌아가서, MT2 장치 (104) 는, MT2 장치 (104) 가 후속 바이트가 "7D" 문자일 경우, 단계 S450 에서, 후속 바이트가 이스케이프된 포맷의 "03" 문자 (즉, 16진 문자 "23") 인지를 체크한다. 후속 바이트가 "23" 문자가 아닌 경우, MT2 장치 (104) 는 단계 S426 으로 진행하여, 단계 S427 에서처럼, 다음 스테이지로 이동할지를 판정하거나, 단계 S428 에서와 같이 패킷을 관련 인테페이스를 통하여 포워딩하는 MT2 장치 (104) 송신 부분으로 전체 패킷을 송신한다. 후속 바이트가 "23" 문자일 경우, MT2 장치 (104) 는 단계 S435 로 진행하여, 단계 S427 에서와 같이 다음 스테이지로 이동할지를 판정하거나 단계 S437 에서와 같이 전체 패킷을 MT2 장치 (104) 언프레이머로 포워딩할 지를 판정한다.
따라서, 본 실시형태는 패킷을 언프에임하지 않고도, PPP 패킷 스트림 내의 프로토콜 및 환경설정 메시지를 검출한다. 또한, 본 실시형태는 인입 데이터 스트림을 스캔하고, 스테이지들 내의 정보 바이트를 기계저으로 체크한다. 이들 스테이지는 PPP 프레임된 패킷의 정보 필드에 대응하며, 따라서, 이 실시형태는, 불필요한 PPP 패킷 언프레이밍/리프레이밍 동작을 수행하지 않고, 링크 환경설정에 영향을 주는 메시지를 무시하지 않고서, 희망 정보를 순차적으로 검출한다.
이상의 본 발명의 바람직한 실시형태의 설명은 도시 및 설명을 제공하는 것으로서, 본 발명을 개시된 형태에만 포괄하거나 제한하려는 것이 아니다. 상기 교시에 따라서 변경 및 변형을 할 수 있으며, 본 발명의 실시로부터 달성할 수도 있다. 따라서, 본 발명의 범위는 청구범위와 그 균등물에 의해 정해진다.
Claims (13)
- 통신 장치에서, 각각 정보 부분을 포함하는 복수의 프레임된 데이터 패킷을 수신하는 단계;상기 통신 장치에서, 상기 프레임된 데이터 패킷중의 하나에서 상기 정보 부분의 시작을 검출하는 단계; 및상기 통신 장치에서, 상기 정보 부분이 소정 타입의 상기 환경설정 정보를 포함하는 지를 판정하는 단계를 포함하고,상기 통신 장치는, 상기 정보 부분이 소정 타입의 상기 환경설정 정보를 포함하는 경우, 상기 프레임된 데이터 패킷 중의 상기 하나를 언프레임하는 것을 특징으로 하는, 소정 타입의 환경설정 정보의 초기 검출 방법.
- 제 1 항에 있어서,상기 검출 단계는 상기 복수의 상기 프레임된 데이터 패킷을 스캐닝하는 단계, 및 프레임 구분 문자를 식별하여 상기 프레임된 데이터 패킷중의 하나에 대하여 상기 정보 부분의 상기 시작을 확립하는 단계를 포함하는 것을 특징으로 하는 방법.
- 제 2 항에 있어서,상기 검출 단계는,상기 통신 장치에서, 상기 정보 부분내의 소정 바이트수의 콘텐츠를 언이스케이프하는 단계; 및상기 통신 장치에서, 상기 언이스케이프된 소정 바이트수의 상기 콘텐츠가 소정 문자를 포함하는 지를 판정하는 단계를 포함하고,상기 통신 장치는, 상기 언이스케이프된 소정 바이트수가 상기 소정 문자를 포함하는 경우, 상기 소정 바이트수에 이어서, 추가적인 후속 바이트의 콘텐츠를 언이스케이프하고,상기 통신 장치는, 상기 언이스케이프된 소정 바이트수의 상기 콘텐츠와 추가적인 후속 바이트의 콘텐츠가 소정 타입의 상기 환경설정 정보를 포함하는 지를 판정하는 것을 특징으로 하는 방법.
- 제 2 항에 있어서,상기 검출 단계는,상기 통신 장치에서, 상기 정보 부분의 특정 바이트 또는 바이트들의 콘텐츠가 상기 특정 바이트와 관련된 타입의 정보를 포함하는 지를 판정하는 단계; 및상기 통신 장치에서, 상기 특정 바이트의 상기 콘텐츠가 소정 타입의 상기 환경설정 정보를 포함하는 지를 판정하는 단계를 포함하고,상기 통신 장치는, 상기 특정 바이트의 상기 콘텐츠가 특정 타입의 상기 환경설정 정보가 없고 소정 타입의 상기 환경설정 정보가 상기 특정 바이트에 후속하는 바이트 위치에 배치되는 경우, 후속 스테이지로 진행하는 것을 특징으로 하는방법.
- 제 4 항에 있어서,상기 후속 스테이지로의 진행은,상기 통신 장치에서, 상기 특정 바이트에 후속하는, 상기 정보 부분의 하나 이상의 후속 바이트의 콘텐츠를 검사하는 단계;상기 통신 장치에서, 상기 후속 바이트의 콘텐츠가 상기 후속 바이트와 관련된 타입의 정보를 포함하는 지를 판정하는 단계; 및상기 통신 장치에서, 상기 후속 바이트의 상기 콘텐츠는 소정 타입의 상기 환경설정 정보를 포함하는 지를 판정하는 단계를 더 포함하고,상기 통신 장치는, 상기 후속 바이트의 콘텐츠가 소정 타입의 상기 환경설정 정보를 포함할 때까지, 상기 정보 부분의 후속 바이트를 순차적으로 검사하는 것을 특징으로 하는 방법.
- 제 5 항에 있어서,상기 특정 바이트의 상기 콘텐츠와 상기 후속 바이트의 상기 콘텐츠는 이스케이프된 정보를 포함하는 것을 특징으로 하는 방법.
- 제 5 항에 있어서,상기 특정 바이트의 상기 콘텐츠와 상기 후속 바이트의 상기 콘텐츠는 언이스케이프된 정보를 포함하는 것을 특징으로 하는 방법.
- 정보 부분을 각각 포함하는 복수의 프레임된 데이터 패킷을 송수신하는 단말 장치; 및상기 단말 장치에 연결되는 통신 장치를 구비하고,상기 통신 장치는 상기 프레임된 데이터 패킷 중의 하나내의 상기 정보 부분의 시작을 검출하고 상기 정보 부분이 소정 타입의 상기 환경설정 정보를 포함하는 지를 판정하며,상기 통신 장치는, 상기 정보 부분이 소정 타입의 상기 환경설정 정보를 포함하는 경우, 상기 프레임된 데이터 패킷중의 상기 하나를 언프레임하는 것을 특징으로 하는, 소정 타입의 환경설정 정보의 초기 검출 시스템.
- 제 8 항에 있어서,상기 통신 장치에 의한 상기 검출은,상기 복수의 프레임된 데이터 패킷을 스캐닝하는 단계, 및 프레임 구분 문자를 식별하여 상기 프레임된 데이터 패킷 중의 하나에 대하여 상기 정보 부분의 상기 시작을 확립하는 단계를 포함하는 것을 특징으로 하는 시스템.
- 제 9 항에 있어서,상기 통신 장치에 의한 상기 검출은,상기 정보 부분의 소정 바이트수의 콘텐츠를 언이스케이프하는 단계; 및상기 언이스케이프된 소정 바이트수의 콘텐츠가 소정 문자를 포함하는 지를 판정하는 단계를 포함하고,상기 통신 장치는, 상기 언이스케이프된 소정 바이트수가 상기 소정 문자를 포함할 때, 상기 소정 바이트수에 이어서, 추가적인 후속 바이트의 콘텐츠를 언이스케이프하고,상기 통신 장치는, 상기 언이스케이프된 소정 바이트수의 콘텐츠와 추가적인 후속 바이트의 콘텐츠가 소정 타입의 상기 환경설정 정보를 포함하는 지를 판정하는 것을 특징으로 하는 시스템.
- 제 9 항에 있어서,상기 통신 장치에 의한 상기 검출은,상기 정보 부분의 특정 바이트 또는 바이트들의 콘텐츠가 상기 특정 바이트 또는 바이트들과 관련되는 타입의 정보를 포함하는 지를 판정하는 단계; 및상기 특정 바이트 또는 바이트들의 상기 콘텐츠가 소정 타입의 상기 환경설정 정보를 포함하는 지를 판정하는 단계를 포함하고,상기 통신 장치는, 상기 특정 바이트 또는 바이트들의 상기 콘텐츠가 소정 타입의 상기 환경설정 정보가 없고 소정 타입의 상기 환경설정 정보가 상기 특정 바이트 또는 바이트들에 후속하는 바이트 위치에 배치될 때, 후속 스테이지로 진행하는 것을 특징으로 하는 시스템.
- 제 11 항에 있어서,후속스테이지로 상기 통신 장치의 진행은,상기 특정 바이트에 후속하는, 상기 정보 부분의 하나 이상의 후속 바이트의 콘텐츠를 검사하는 단계; 및상기 후속 바이트의 콘텐츠가 상기 후속 바이트와 관련되는 타입의 정보를 포함하는 지, 그리고 상기 후속 바이트의 상기 콘텐츠가 소정 타입의 상기 환경설정 정보를 포함하는 지를 판정하는 단계를 포함하고,상기 통신 장치는, 상기 후속 바이트의 콘텐츠가 소정 타입의 상기 환경설정 정보를 포함할 때까지, 상기 정보 부분의 후속 바이트를 순차적으로 검사하는 것을 특징으로 하는 시스템.
- 제 12 항에 있어서,상기 특정 바이트의 상기 콘텐츠와 상기 후속 바이트의 상기 콘텐츠는 이스케이프된 정보를 포함하는 것을 특징으로 하는 시스템.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/828,623 | 1999-09-08 | ||
US09/828,623 US6934276B1 (en) | 1999-09-08 | 1999-09-08 | Methods for efficient early protocol detection |
Publications (2)
Publication Number | Publication Date |
---|---|
KR20020060948A true KR20020060948A (ko) | 2002-07-19 |
KR100746866B1 KR100746866B1 (ko) | 2007-08-07 |
Family
ID=34838995
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
KR1020027003102A KR100746866B1 (ko) | 1999-09-08 | 2000-09-07 | 효율적인 조기 프로토콜 검출 방법 |
Country Status (7)
Country | Link |
---|---|
US (1) | US6934276B1 (ko) |
EP (1) | EP1210829B1 (ko) |
JP (1) | JP4472228B2 (ko) |
KR (1) | KR100746866B1 (ko) |
AT (1) | ATE415789T1 (ko) |
DE (1) | DE60040916D1 (ko) |
HK (1) | HK1056073A1 (ko) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030172178A1 (en) * | 2002-03-08 | 2003-09-11 | Eduard Lecha | Method to avoid high-level data link control (HDLC) frame abortion |
CN101790235B (zh) * | 2004-03-12 | 2012-05-23 | 三星电子株式会社 | 宽带无线通信系统中减小突发分配信息大小的方法和装置 |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5260942A (en) * | 1992-03-06 | 1993-11-09 | International Business Machines Corporation | Method and apparatus for batching the receipt of data packets |
FI98027C (fi) * | 1995-01-10 | 1997-03-25 | Nokia Telecommunications Oy | Pakettiradiojärjestelmä ja päätelaitteisto pakettiradiojärjestelmää varten |
US5666362A (en) * | 1995-07-25 | 1997-09-09 | 3Com Corporation | Method and apparatus for asynchronous PPP and synchronous PPP conversion |
US5699350A (en) * | 1995-10-06 | 1997-12-16 | Canon Kabushiki Kaisha | Reconfiguration of protocol stacks and/or frame type assignments in a network interface device |
JP3471523B2 (ja) * | 1996-05-21 | 2003-12-02 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 通信方法及び通信端末 |
US5835036A (en) * | 1997-05-12 | 1998-11-10 | Cisco Systems Co. | Method of encoding data for transmission |
US6157641A (en) * | 1997-08-22 | 2000-12-05 | Cisco Technology, Inc. | Multiprotocol packet recognition and switching |
DE19800772C2 (de) * | 1998-01-12 | 2000-04-06 | Ericsson Telefon Ab L M | Verfahren und Vorrichtung zur Verbindung mit einem Paketaustauschnetz |
AU3919300A (en) * | 1999-03-25 | 2000-10-09 | Motorola, Inc. | Point to point protocol multiplexing/demultiplexing method and apparatus |
US6542504B1 (en) * | 1999-05-28 | 2003-04-01 | 3Com Corporation | Profile based method for packet header compression in a point to point link |
US6483822B1 (en) * | 1999-06-07 | 2002-11-19 | Marcello Lioy | Establishing a packet network call between a mobile terminal device and an interworking function |
-
1999
- 1999-09-08 US US09/828,623 patent/US6934276B1/en not_active Expired - Lifetime
-
2000
- 2000-09-07 EP EP00961656A patent/EP1210829B1/en not_active Expired - Lifetime
- 2000-09-07 AT AT00961656T patent/ATE415789T1/de not_active IP Right Cessation
- 2000-09-07 JP JP2001522721A patent/JP4472228B2/ja not_active Expired - Fee Related
- 2000-09-07 DE DE60040916T patent/DE60040916D1/de not_active Expired - Lifetime
- 2000-09-07 KR KR1020027003102A patent/KR100746866B1/ko not_active IP Right Cessation
-
2003
- 2003-11-12 HK HK03108209A patent/HK1056073A1/xx not_active IP Right Cessation
Also Published As
Publication number | Publication date |
---|---|
US6934276B1 (en) | 2005-08-23 |
HK1056073A1 (en) | 2004-01-30 |
JP4472228B2 (ja) | 2010-06-02 |
EP1210829A2 (en) | 2002-06-05 |
ATE415789T1 (de) | 2008-12-15 |
JP2003509901A (ja) | 2003-03-11 |
KR100746866B1 (ko) | 2007-08-07 |
EP1210829B1 (en) | 2008-11-26 |
DE60040916D1 (de) | 2009-01-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6775553B1 (en) | Method of avoiding PPP time-outs during IPCP negotiations | |
US8098617B2 (en) | Method and apparatus for selective examination of PPP packets for renegotiation of a PPP link on a Um interface | |
US6909714B2 (en) | Method and apparatus for determining configuration options negotiated for a communications link employing a network model | |
EP1155551B1 (en) | Simultaneous setup of ppp on a um and rm interface | |
CA2384162C (en) | Methods for efficient early protocol detection | |
US6377556B1 (en) | 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 | |
EP1192827B1 (en) | SELECTIVELY FRAMING AND UNFRAMING PPP PACKETS DEPENDING ON NEGOTIATED OPTIONS ON THE Um AND Rm INTERFACES | |
US6804260B2 (en) | Method for selectively maintaining and applying PPP compression in a wireless communication system | |
KR100746866B1 (ko) | 효율적인 조기 프로토콜 검출 방법 |
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: 20120727 Year of fee payment: 6 |
|
FPAY | Annual fee payment |
Payment date: 20130729 Year of fee payment: 7 |
|
FPAY | Annual fee payment |
Payment date: 20140730 Year of fee payment: 8 |
|
FPAY | Annual fee payment |
Payment date: 20160629 Year of fee payment: 10 |
|
FPAY | Annual fee payment |
Payment date: 20170629 Year of fee payment: 11 |
|
LAPS | Lapse due to unpaid annual fee |