KR20000076490A

KR20000076490A - Ｔｃｐ/ｉｐ/ｐｐｐ 모뎀

Info

Publication number: KR20000076490A
Application number: KR1020000002531A
Authority: KR
Inventors: 마이클워드 존슨; 존시케토 미나미; 료오 코야마; 마사루 시노하라; 토마스씨. 포프; 다니엘에프. 버크스
Original assignee: 코야마 리오; 아이레디 코포레이션
Priority date: 1999-05-28
Filing date: 2000-01-20
Publication date: 2000-12-26

Abstract

특정 로직과 함께 인터넷 네트워크 프로토콜 스택이 모뎀과 함께 제공되어, 모뎀을 인터넷에 즉시 접속시킨다. 결과적으로, 모뎀은 메인 CPU로부터 네트워크 프로토콜 프로세싱의 대부분을 오프로드하고, 모뎀은 통신 시스템의 전체 성능을 향상시킨다.

Description

ＴＣＰ/ＩＰ/ＰＰＰ 모뎀{TCT/IP/PPP MODEM}

본 출원은 1999년 5월 28일 제출된 미국 특허 충원 제 09/321,902호의 연장이다.

본 발명은 컴퓨터와 비컴퓨터 장치 모두에서 사용하기 위해 모뎀 코어에 네트워크 스택을 조합하는 것에 관한 것이다. 특히, 발명은 인터넷에서 통신하는 데 필요한 네트워크 프로토콜로 다수의 점-점 장치를 조합하는 인터넷-인지 모뎀에 관한 것이고, 이 장치들은 2400 kbps에서 56 kbps까지의 다양한 속도 모뎀, ISDN 모뎀, 새 xDSL 모뎀, 그리고 디지털 셀룰러 모뎀을 포함한다.

대부분의 접속이 독점 온라인 서비스, 대화식 터미널, BBS, 또는 단체 네트워크 시스템에서 이루어질 때, 컴퓨터 모뎀은 발전되었다. 이와 같이, 다수의 이러한 프로토콜이 존재하기 때문에, 소프트웨어의 접속 프로토콜을 구현하는 것이 필요했다. 이러한 프로토콜로는 x-모뎀, y-모뎀, z-모뎀, 커밋, 그리고 대화 특성 기반의 인터페이스가 포함된다.

오늘날, 인터넷이 호황을 누리면서, ISP와 독점적으로 접속하기 위해 다수의 모뎀이 사용되고 있고, 이는 사용자를 인터넷에 연결한다. 그러므로, 지금 독점적인 접속 프로토콜 세트가 존재한다. 이러한 프로토콜은 대부분의 모뎀 접속에 사용된다. 따라서, 인터넷에 바로 연결되는 모뎀을 설계할 때의 실제 필요와 이점이 있다.

인터넷에 의해 사용되는 접속 프로토콜과 그 계급 관계는 도 1에 도시된다. 이 프로토콜은 TCP(10), IP(11), UDP(13), 그리고 PPP(12)를 포함한다. 인터넷 용으로 모뎀을 최적화하는 것은 많은 장점을 제공하고, 그 장점이란, 전송 잠재성을 감소시키고, 서비스 요구사항을 감소시키며, 시스템 CPU의 처리 요구사항을 낮추고, 최적의 전송 레이트를 얻는 것이다.

현재의 컴퓨터 시스템은 모뎀 서브시스템을 직렬 장치로 처리한다. 기존 시스템의 블록 다이어그램이 도 2에 도시된다. 이러한 시스템에서, 웹 브라우저(21)와 같은 인터넷 장치가 메인 CPU(22) 상의 소프트웨어(19)에서 가동된다. 이 장치는 컴퓨터 네트워크 스택(23)을 호출하면서, 소프트웨어에서 구현된다. 네트워크 스택은 TCP, IP, UDP, 그리고 PPP 프로토콜을 구현한다. 한번 데이터가 처리되면, 결과적인 패킷은 모뎀 시스템(20)의 직렬 포트 인터페이스(27)까지 컴퓨터 버스(28)를 통해 CPU에 의해 보내진다. 모뎀 시스템, 예를 들어 모뎀 카드(18)가 호스트 프로세서에 의해 직렬 I/O 장치로 도시된다. 이 장치들은 바이트 크기로 데이터를 수용하고, 출력 FIFO(24)에 이를 위치시킨다. 이 FIFO는 8바이트로부터 64바이트까지 어디에도 위치할 수 있다. CPU는 고정된 수의 바이트를 쓰고, 모든 데이터가 보내지고 그 이상의 데이터를 수용할 분비가 되어있는 지를 직렬 I/O 장치가 통지하는 것을 기다린다. 이 통지는 시스템 인터럽트를 통해 행해지는 것이 일반적이다. 패킷 데이터는 FIFO에 쓰여진 후에, 모뎀 코어(25)에 출력 데이터 속도로 공급되고, 전화 라인(29)에 공급된다.

수신된 데이터에서, 모뎀은 입력 FIFO(26)에 모든 유입 패킷을 먼저 위치시킨다. 장치는 어떤 데이터가 이용가능할 때나 수신된 데이터가 어느 수준(예를 들어 16 바이트)에 도달할 때 호스트 CPU를 인터럽트시키도록 배치된다. 통지받을 때, CPU는 입력 FIFO의 모든 데이터를 읽고, 시스템 메모리의 버퍼에 임시로 데이터를 저장한다. 바닥 프로토콜(도 1 참조)은 데이터 처리를 시작할 수 있지만, 전체 패킷이 수신될 때까지 다음 레이어에 데이터를 보낼 수 없다. 전체 패킷이 수신되면, 소프트웨어 네트워크 스택의 PPP부는 제 2 프로토콜(IP)에 데이터를 보낸다. IP 소프트웨어는 IP 헤더를 처리하고, 헤더 체크섬을 확인한 후에, TCP 핸들러에 패킷을 보낸다. TCP 핸들러는 그 체크섬을 확인하고, 헤더의 PORT 번호에 의해 구체화되는 바와 같이 데이터를 적절한 장치에 보낸다.

오늘날 컴퓨터 모뎀의 대부분은 인터넷 접속을 위해 사용되기 때문에, 이 환경을 위해 모뎀을 최적화하는 것이 경제적으로 편리하고 실용적이다. 이것이 의미하는 것은 모뎀 시스템에서, 모뎀의 전송 특성을 조절하기 위해 프로토콜의 지식을 이용하고 네트워크 프로토콜을 필요적절하게 조절하는 능력을 구체화하는 것이다. 이것이 윈도우 가속기 그래픽 카드의 대중성 뒤에 있는 근본적 이유이다. 대부분의 PC가 마이크로소프트 윈도우즈 작동 시스템을 이용하고 있는 사실을 그래픽 칩 제작자가 알기 때문에, 이 환경에서 성능을 향상시키기 위해 제작자들은 그 구조를 미세 조절한다. 다른 그래픽 API를 가지는 다수의 작동 시스템이 존재한다면, 그래서 시장의 상당분을 차지한다면, 이는 실용적이지 않을 것이다. 그러나, 하나의 독점적인 표준하에서, 펜티엄 클래스 프로세서가 외부 지원 없이 그래픽 업무를 상당량 조절할 수 있지만, 대부분의 그래픽 카드 제작자는 윈도우즈 환경에 대해 제작자의 하드웨어를 최적화시키는 것을 선택하였다. 이는 이 기능이 대부분의 환경에서 요구되고 표준 장치를 구동하기 위해 훨씬 더 많은 MIP를 가지도록 호스트 프로세서를 오프로딩하는 것이 바람직하기 때문이다.

유사한 상황이 모뎀 카드 시장에 존재한다. 특정 로직과 함께 인터넷 네트워크 프로토콜 스택을 구체화하여, 모뎀 장치를 인터넷에 직접 접속되게 하는 것이 바람직하다. 그래서, 통신 시스템의 전체 성능을 향상시키면서, 메인 CPU로부터 네트워크 프로토콜 처리의 대부분을 모뎀 시스템이 오프로딩하게 하는 것이 바람직하다.

발명은 특정 로직과 함께 인터넷 네트워크 프로토콜 스택을 구체화하는 것이고, 이에 의해 모뎀 장치를 인터넷에 바로 접속되게 하는 것이다. 그 결과, 모뎀 시스템은 메인 CPU로부터 네트워크 프로토콜 처리의 대부분을 오프로딩하고, 통신 시스템의 전체 성능을 향상시킨다. 발명은 인터넷에서 통신하는 데 필요한 네트워크 프로토콜과 다수의 점-점 장치를 조합하는 인터넷 지각 모뎀을 제공한다. 여기서, 이 장치들에는 2400 kbps에서 56 kbps까지 다양한 속도의 기존 모뎀, ISDN 모뎀, 새 xDSL 모뎀, 그리고 디지털 셀룰러 모뎀이 포함된다.

데이터 전송

인터넷 즉시 접속 모뎀을 갖춘 시스템에서, 인터넷 장치는 소켓 패러미터를 먼저 설정한다. 이는 종착지 포트 번호, 접속 종류(TCP/UDP), TOS(서비스 종류) 요구사항, 그리고 종착지 IP 어드레스를 포함한다. 인터넷 즉시 접속 모뎀 카드 상의 네트워크 스택이 이 정보를 얻을 때, SYN 패킷을 보냄으로서 접속 시작을 기도한다. 이 패킷이 IP 엔진에 연결되고, 이는 IP 헤더에 부착되고, IP 헤더 체크섬을 계산한다. 이 패킷이 PPP 헤더에 부착된 PPP 핸들러에 전송되고, PPP 체크섬을 추가하며, 데이터를 벗어난다. PPP 캡슐화 이후에, 결과적인 네트워크 패킷은 모뎀 코어에 출력 FIFO를 통해 보내진다. 이 패킷에 대해, TCP 엔진이 패킷 분석 블록에게 이것이 SYN 패킷임을 표시한다. 패킷 분석기는 모뎀에 이것이 홀로 떨어진 패킷임을 표시하고, 바로 보내질 수 있음을 표시한다. 이 정보를 수신하면서, 모뎀은 추가적인 정보가 다가오는 지를 보기 위해 정상적인 50 ms 동안을 기다리지 않으면서 네트워크 패킷을 전송한다. 종착지 소켓이 역방향 SYN-ACK 패킷을 보낸 후에, ACK 패킷은 모뎀 카드로부터 보내진다. 이 패킷은 SYN 패킷에 대한 단계와 동일 단계를 따른다. 이 점에서, 소켓이 접속되고, 장치 소프트웨어(예를 들어 웹 브라우저)가 통지된다. 이 장치는 데이터를 모뎀에 직접 데이터 패킷 형태로 보낼 수 있다. 본 예에서, 장치가 웹 브라우저인 경우에, 장치는 정규 모뎀 시스템에서 직렬 포트 I/O 인터페이스에 반하여 패킷 인터페이스를 통해 모뎀 시스템에 직접 HTTP 요청을 보낼 수 있다. DMA 방식 데이터 전송은 이 목적을 위해 이용될 수 있다. 이 방법에서, 데이터 바이트 카운트는 패킷 인터페이스에 프로그래밍된다. 데이터는 호스트 CPU로부터 더 이상의 간섭없이 메모리로부터 모뎀 카드로 자동적으로 전송될 수 있다. 모든 데이터가 전송된 후에, 모뎀 카드로부터의 간섭이 데이터 전송 완료를 나타내는 호스트 CPU에 보내질 수 있다.

데이터가 모뎀 카드에 도달함에 따라, 데이터는 (본 예에서) TCP 데이터 출력 버퍼로 보내진다. 모든 데이터가 수신된 후에, 또는 패킷 당 최대 데이터 크기가 수신된 때에, TCP 블록은 체크섬 계산을 시작한다. 패킷은 SYN 패킷과 동일 방식으로 캡슐화된다. 이와 마찬가지로, TCP 엔진은 패킷에 대한 종착지 포트가 (80)이라는 것을 패킷 분석 블록에 나타낸다. 상기 패킷은 공지된 HTTP 포트이다. 패킷 분석기는 어떤 데이터도 없다는 것을 알고 있으며, 모뎀은 현 패킷을 즉시 보내야한다.

데이터 수신

네트워크 패킷을 수신할 때, 데이터는 모뎀 코어로부터 입력 FIFO를 통해 PPP 엔진에 보내지고, 상기 PPP 엔진은 PPP 헤더를 분석하고, 데이터 탈출을 방지하며, 체크섬 계산을 위한 패킷의 구동 검사를 시작한다. 캡슐화된 데이터가 IP 패킷이라고 엔진이 결정하면, IP 엔진을 작동시키고, PPP 헤더를 거친 모든 데이터는 IP 엔진으로 향한다. IP 엔진은 IP 헤더를 분석하고, 체크섬을 확인하며, 캡슐화된 프로토콜이 TCP라고 결정되면, IP 헤더를 거친 모든 데이터를 TCP 엔진에 보낸다. TCP 엔진은 TCP 헤더를 분석하고, 보안 레이어에 데이터부를 보낸다. 데이터가 HTML 데이터이면, 페이지의 레이팅 태그를 분석하는 레이팅 체크를 통과할 수 있다. 페이지가 모뎀 카드 세팅 이하의 레이팅을 가지면, 데이터는 통과될 것이다. 레이팅이 카드의 세팅을 초과하면, 초과 표시 메시지가 대신에 나타날 것이다. 레이지가 어떤 레이팅도 포함하지 않으면, 통과하거나 페이지를 블록하도록 페이지가 설정될 것이다. 모든 비-HTML 데이터는 TCP 데이터 버퍼에 직접 전해질 것이다.

모든 데이터가 버퍼 내로 쓰여질 때, 작동 카운트가 데이터 수신량을 감지한다. 네트워크 패킷의 말미에서, 전체 패킷이 에러없이 수신되었다는 것을 PPP 체크섬이 나타내면, 인터럽트가 호스트 CPU에 발생할 것이다. 이 장치는 수신된 데이터 카운트를 읽고, TCP 버퍼로부터 메인 메모리로 데이터를 전송하는 DMA 전송을 프로그래밍할 수 있다.

발명의 또다른 실시예

작은 메모리를 요구하면서도 고효율의 프로토콜 디코드를 제공하는, 저비용, 저출력, 간편제작용, 작은 형태의 팩터 네트워크 액세스 모듈을 본 발명은 제공한다. 발명은 하드웨어 일체형 시스템으로 구성되고, 상기 일체형 시스템은 바이트 스트리밍 방식으로 동시에 다중 네트워크 프로토콜을 디코딩하고, 한 패스로 패킷 데이터를 처리하여, 시스템 메모리와 폼 팩터 요구사항을 감소시키며, 소프트웨어 CPU 오버헤드를 제거한다.

발명의 본 실시예의 선호되는 형태는 네트워크 프로토콜 레이어, 데이터 핸들러, O.S. 스테이트 머신, 그리고 메모리 매니저 스테이트 머신으로 구성된다. 상기 메모리 매니저 스테이트 머신은 하드웨어 게이트 레벨에서 구현된다. 네트워크 패킷은 네트워크 프로토콜 레이어 스테이트 머신에 의해 물리적 전송 레벨 메카니즘으로부터 수신된다. 프로토콜 스테이트 머신은 각각의 바이트가 수신됨에 따라 TCP, IP, 사용자 데이터그램 프로토콜(UDP), PPP, 그리고 로오 소켓(Raw Socket)과 같은 네트워크 프로토콜을 동시에 디코딩한다. 각각의 프로토콜 핸들러는 중간 메모리를 필요로 하지 않으면서 패킷으로부터 즉시 헤더 정보를 분석하고, 해독하며, 발췌한다. 결과적인 데이터는 다음 프로토콜 레이어나 데이터 핸들러에 전달되고, 상기 데이터 핸들러는 전자 메일, 그래픽스, 하이퍼텍스트 전송 프로토콜(HTTP), 자바, 그리고 하이퍼텍스트 마크업 언어(HTML)와 같은 데이터 포맷을 디코딩하는 데이터 스테이트 머신으로 구성된다. 각각의 데이터 스테이트 머신은 영구 데이터에 따라 반응하고, 한 개 이상의 데이터 스테이트 머신에 의해 요구되는 어떤 데이터도 각각의 스테이트 머신에 동시에 제공된다. 특정 데이터 스테이트 머신에 의해 한번 이상 요구되는 데이터는 그러한 데이터를 표시하는 포인터와 함께 특정 메모리 위치에 자리하고, 최소의 메모리 사용을 보장한다. 결과적인 디스플레이 데이터는 데이터 스테이트 머신에 의해 생성되고, 네트워크 프로토콜 스테이트 머신을 통과하며, 상기 네트워크 프로토콜 스테이트 머신은 패킷에 포맷을 추가하고, 정보 헤더 정보를 체크섬하며, 물리적 전송 레벨 메카니즘을 통해 결과적인 네트워크 패킷을 보낸다.

본 실시예의 선호되는 형태는 네트워크 패킷을 처리하기 위한 소프트웨어와 CPU를 필요로 하지 않아서, 시스템 비용을 크게 감소시킨다. 하드웨어 게이트 레벨 구현은 시계산적으로 실현가능한 설계를 제공하고, 여기서, 설계자는 특정 장치가 저비용, 저출력, 작은 형태 팩터를 유지할 수 있는 기능을 선택할 수 있다.

도 1은 인터넷에 의해 사용되는 접속 프로토콜과 그 조직 관계를 도시하는 블록 다이어그램.

도 2는 전형적인 모뎀 서브시스템의 블록 다이어그램.

도 3은 발명에 따르는 인터넷 즉시 접속 모뎀 시스템의 블록 다이어그램.

도 4는 발명에 따르는 풀 네트워크 스택을 가지는 모뎀의 블록 다이어그램.

도 5는 발명에 따르는 PPP 기능을 도시하는 블록 다이어그램.

도 6a는 기존 모뎀과 네트워크 카드를 도시하는 블록 다이어그램.

도 6b는 발명에 따르는 모뎀과 향상된 에더넷 네트워크 카드의 블록 다이어그램.

도 7은 발명에 따르는 잠재시간을 결정하기 위해 PPP 프로토콜 패킷에 사용되는 필드를 도시하는 블록 다이어그램.

도 8은 발명에 따르는 TOS에 기초한 최적화를 도시하는 블록 다이어그램.

도 9는 발명에 따르는 종착지 포트에 기초한 최적화를 도시하는 블록 다이어그램.

도 10은 발명에 따르는 패킷 스테이트에 기초한 최적화를 도시하는 블록 다이어그램.

도 11은 발명에 따르는 조합된 잠재시간 표를 도시하는 블록 다이어그램.

도 12는 발명에 따르는 향상된 모뎀 시스템의 블록 다이어그램.

도 13은 발명에 따르는 HTML 스니퍼를 통해 흐르는 수신된 패킷 데이터의 블록 다이어그램.

도 14는 발명에 따르는 HTML 스니퍼의 블록 다이어그램.

도 15는 발명에 따르는 코어 시스템의 하이 레벨 데이터 플로우 다이어그램.

도 16은 발명에 따르는 시스템의 하이 레벨 블록 다이어그램.

도 17은 발명에 따르는 완전한 시스템 구현의 기능성 블록 다이어그램.

도 17A는 발명에 따르는 UMA 메모리 컨트롤러의 기능성 블록 다이어그램.

도 18은 종래의 구조와 발명에서 요구되는 데이터 테스크 시간을 도시하는 시간 비교 차트.

도 19는 발명에 따르는 장치의 가능한 개량점의 도면.

도 20은 발명에 따르는 인터넷 튜너 개념의 도면.

도 21은 발명에 따르는 두 구현예의 도면.

도 22는 발명에 따르는 네트워크 PC 구현예의 도면.

도 23은 발명에 따르는 휴대용 장치 구현예의 도면.

도 24는 발명에 따르는 스마트 전화 구현예의 도면.

도 25는 발명에 따르는 스마트 TV, 케이블 박스, 비디오 카세트 레코더(VCR), 디지털 비디오 디스크(DVD), 그리고 게임 미신 구현예의 도면.

도 26은 발명에 따르는 수신 패킷을 분할하는 타이밍 다이어그램.

도 27은 발명에 따르는 청구항 12의 패킷에 대한 신호 흐름을 보여주는 블록 다이어그램.

(참조 번호 설명)

10 ... TCP 11 ... IP

12 ... PPP 13 ... UDP

18 ... 모뎀 카드 19 ... 소프트웨어

20 ... 모뎀 시스템 22 ... 메인 CPU

23 ... 컴퓨터 네트워크 스택 24 ... 출력 FIFO

25 ... 모뎀 코어 26 ... 입력 FIFO

27 ... 직렬 포트 인터페이스 28 ... 컴퓨터 버스

29 ... 전화 라인

발명은 인터넷 상에서의 통신에 필요한 네트워크 프로토콜과 다수의 점-점 장치를 조합하는 인터넷 지각 모뎀을 제공하는 것이고, 여기서 이 장치들은 2400 kbps - 56 kbps까지의 다양한 속도의 기존 모뎀, ISDN 모뎀, 새 xDSL 모뎀, 그리고 디지털 셀룰러 모뎀을 포함한다. 본 발명은 특정 로직과 함께 인터넷 네트워크 프로토콜 스택을 구체화하여, 모뎀 장치가 인터넷에 즉시 접속할 수 있게 한다. 그 결과, 모뎀 시스템은 메인 CPU로부터 네트워크 프로토콜 프로세싱의 대부분을 오프로딩하고, 통신 시스템의 전체 성능을 개선시킨다.

발명은 인터넷 프로토콜에 사용될 때 모뎀 성능과 효율을 증가시키는 여러 기술을 제공한다. 이 기술들에는 아래와 같은 사항이 포함된다.

- 블록 기초 통신

- 잠재시간 최적화

- 프로세싱 전력 감소

- 에너지 요구사항 감소, 그리고

- 보안성 향상

데이터 전송 오버헤드 감소

근래의 모든 모뎀은 직렬 포트를 통해 통신한다. 직렬 통신은 에더넷 어댑터와 같은 다른 통신 장치에 여러 성능 단점을 가진다. 상기 에더넷 어댑터는 DMA(직접 메모리 액세스)를 통해 데이터 블록을 송수신함으로서 호스트 CPU와 통신한다.

직렬 통신

구형 직렬 하드웨어(예를 들어 UART)를 사용하는 직렬 통신은 송수신된 모든 캐릭터에 대한 인터럽트를 필요로 한다. 이는 상당한 오버헤드를 유발하여, 대부분의 컴퓨터 시스템에서 데이터 손실없이 19200 bps 이상의 속도로 통신하는 것이 불가능하다. 제 2 발생 직렬 하드웨어(예를 들어 16550 UART와 그 파생물)는 송수신시에 16 바이트까지 버퍼링할 수 있고, 버퍼가 어떤 레벨에 도달할 때까지 인터럽트를 지연시킨다. 이는 모뎀으로부터/모뎀까지의 데이터 전송에 필요한 인터럽트의 수를 감소시킨다. 이로 인해 대부분의 CPU에서 데이터 손실없이 56000 - 230400 bps의 직렬 데이터 속도를 현대 모뎀은 얻을 수 있다.

제 2 발생 직렬 하드웨어를 사용하는 고속 직렬 통신이 가능함에도 불구하고, 높은 데이터 속도에서 직렬 통신은 시스템 성능을 상당히 저하시킬 수 있다. 특히, 컴퓨터 시스템이 인터넷에서 작동하는 액션 게임이나 멀티-미디어 통신 프로그램을 구동할 때 크게 저하시킬 수 있다. 매 초마다 수천개의 인터럽트가 높은 데이터 속도에서 필요하다(표 1 참조).

표 1

각각의 인터럽트는 직렬 하드웨어까지/로부터 그리고 컴퓨터 작동 시스템까지/로부터 데이터를 읽고 쓰는 인터럽트 서비스 루틴을 필요로 한다. 이 인터럽트 루틴은 시스템 리소스를 비효율적으로 사용하는 I/O 포트에 데이터를 읽고 쓴다.

블록 전송을 이용한 최적화

시스템에서 인터럽트와 로드의 수를 줄이기 위해서 32 또는 64 바이트 버퍼를 가질 수 있는 다음 발생 UART에 대하여 이야기가 있었다. 이는 도움이 될 수 있지만, 데이터 패킷의 블록으로 인터넷 프로토콜과 전송 데이터를 위한 모뎀을 최적화하는 것이 정확한 해답이라는 것을 발명자는 인지하게 되었다.

모뎀/직렬 장치와 접하도록 설계된 인터넷 프로토콜이 직렬 기반(SLIP/PPP)이고 컴퓨터 시스템의 작동 시스템에서 전통적으로 구현되기 때문에, 모뎀에서/으로부터의 블록 기반 통신은 이전에는 고려되지 않았다. 여기서 기술되는 발명을 이용하여, 컴퓨터 작동 시스템으로부터 모뎀으로 네트워크 스택 프로토콜을 이동하는 것이 유익하다. 발명에 따르는 하드웨어 장치에서 구현될 수 있는 네트워크 프로토콜의 레이어는 PPP 레이어로부터 IP, TCP, 그리고 UDP 레이어까지의 범위를 가질 수 있다.

예: 블록 기반 인터럽트 필요조건

평균 100-바이트 IP 패킷을 가정할 때,

25600 Bps / 100 = 초당 256 인터럽트.

상기 예에서 볼 수 있는 바와 같이, 직렬 해법처럼, 상당량의 캐릭터 대신에 블록을 전송하는 것은 필요한 인터럽트의 수를 감소시킨다. 더 늦은 I/O 포트 펌핑 대신에 데이터를 통과하기 위해 직접 메모리 액세스(DMA)를 전송 루틴이 사용할 수 있다는 점이 추가되는 이점이다.

개별 바이트의 데이터 전송을 조작할 때 호스트 CPU의 부담을 덜 수 있기 때문에, 이는 더 빠르고 더 효율적인 데이터 조작 루틴을 생성할 수 있는 소프트웨어의 개발을 가능하게 한다.

잠재시간 감소

모뎀이 IP 패킷을 다루고 있다는 것을 모뎀이 알면, 데이터 유닛의 시작과 정지 위치에 대한 정보를 모뎀은 가진다. V.42와 V.42bis와 같은 모뎀 프로토콜은 이 정보를 이용하여 최적화될 수 있다.

V.42는 모뎀으로 전송되는 데이터의 종류에 대한 구식 정보를 가지지만, 네트워크 스택이 모뎀 코어의 옆에서 구체화되면, 데이터 유닛의 단부를 모뎀 코어에 나타낼 것이다. 모뎀 코어는 그 V.42 패킷을 순서에 따라 분할한다. 재전송이 단 한 개의 IP 패킷에만 영향을 미칠 더 높은 가능성을 가지기 때문에, 이는 재전송의 잠재시간을 감소시킨다. 패킷 단부의 정보는 V4.2 프로토콜이 삽입되는 더 많은 데이터 타임아웃의 기다림을 감소시키는 데 또한 사용될 수 있다. 수신된 최종 바이트가 데이터의 물리적 블록의 단부라는 것이 알려지면, 모뎀은 주위를 기다릴 필요없이 기다릴 시간을 감소시킬 수 있고, 전송될 준비가 된 데이터를 보내기 전에 그 이상의 데이터를 전송하게 한다.

발명의 이 태양은 현 블록을 압축하고 전송하기 전에 V.42 프로토콜이 기다리는 시점과 시간을 얻는 것을 최적화하기 위해 IP 및 TCP 패킷 스누핑을 실행하도록 확장될 수 있다. 예를 들어, IP 헤더의 TOS 필드는 패킷의 전송에 사용되는 잠재시간의 양을 결정하기 위해 사용될 수 있다. 패킷이 높은 우선도의 패킷이면, 시스템은 패킷을 즉시 보내는 것을 결정할 수 있고, 전송 준비된 그 이상의 패킷이 있는 지를 결정할 결정하기 위해 확인하지 않는다. 시스템은 이 TOS 정보에 바탕한 그 이상의 데이터를 변화하는 길이의 시간동안 기다릴 수 있다.

부가적인 잠재시간 최적화는 TCP 헤더를 확인함으로서 달성될 수 있다. SYN 플랙이 TCP 헤더에 설정되면, SYN-ACK가 연결의 다른 측부로부터 되돌아올때까지 아무 일도 발생하지 않기 때문에 데이터는 즉시 전송될 수 있다.

또한, 통신 링크의 송수신 단부에 동일한 기술적 진보가 있어야한다는 모뎀 기술의 이전의 진보와 달리, 여기서 공개되는 모뎀은 모든 기존 모뎀과 호환가능하게 작동한다. 그러므로, 접속의 한 단부만을 업데이트함으로서 성능 향상을 얻을 수 있다. 이러한 방법으로, 기술의 채택은 ISP 기본구조 상의 변화에 의존하지 않는다.

호스트 CPU로부터 요구되는 프로세싱 전력의 감소

모뎀 코어와 함께 네트워크 스택을 구체화함으로서, 인터넷 상에서 접속하고 통신하는 데 필요한 프로세싱 전력의 주목할만한 감소가 가능하다. 이로 인해, 모뎀을 이용하여 인터넷을 통해 통신하는 소형이면서, 저출력, 저비용의 장치가 가능하다. 이런 종류의 장치의 예로는 게임 콘솔, PDA, 장난감, 그리고 다른 소비자 전자 장치 및 이동 전자 장치 등이 있다.

PPP의 프로세서 전력 감소

각각의 패킷 단부에 딸린 CRC를 패킷이 포함하는 것을 PPP 프로토콜을 요구한다. 이 계산은 저-단부 프로세서에 상당한 양의 프로세싱 전력이 될 수 있는 것을 필요로 한다. 이탈 데이터와 패러미터 협상과 같이 프로토콜의 다른 태양은 소프트웨어 해법으로 구현될 때 각각의 바이트에 대한 메모리 액세스를 필요로한다. 모뎀에 PPP를 구현함으로서, 모든 협상이 모뎀 서브시스템에 국부적으로 유지가능하여, 시스템 버스 트래픽과 프로세싱 오버헤드를 살린다.

IP 구현시의 프로세서 전력 감소

IP 구현은 호스트 프로세서로부터 헤더 체크섬 연산을 오프로딩한다. 이는 모뎀 카드에 국부적으로 ICMP 에코 패킷 프로세싱을 유지한다. 이 프로토콜은 PING 장치를 위해 사용된다.

UDP 구현시의 프로세서 전력 감소

프로세싱 전력을 거의 필요로 하지 않는 캡슐화 장치로 U에를 사용하는 것이 가능함에도, 체크섬으로 사용될 때, U에는 일부 프로세서 리소스를 필요로 한다. 대부분의 빈약한 인터넷 고객은 데이터 전송을 위해 IP/UDP를 바탕으로 한다는 것을 주목해야한다.

TCP 구현시의 프로세서 전력 감소

TCP는 UDP보다 상당히 복잡하여, 더 많은 프로세싱 전력을 필요로 한다. TCP는 수많은 스테이트를 가지고, 체크섬이 패킷에서 실행되도록 요구한다. TCP 지원을 필요로 하는 구현된 제품에 대해, 여기서 공개되는 발명은 제공된 하드웨어 회로에 모든 복잡성과 프로세서 요구사항을 오프로딩하는 방법을 제공한다.

해법의 간편성

모뎀 서브시스템 내부에 네트워크 스택을 구체화함으로서, 동일한 모뎀 시스템이 다중 연산과 시스템 플랫폼 너머로 사용될 수 있다. 네트워크 스택 소프트웨어의 어떤 포팅도 필요하지 않기 때문에, 다른 시스템으로 모뎀을 이동시키는 것은 매우 쉽다. 이는 구체화된 시스템 시장에서 특히 중요하다. 상기 시장은 한 개나 두 개의 메인 OS를 가지지 않고, 대신에, 다수의 다른 OS, RTOS로 구성되며, 일부 경우에는 어떤 OS도 존재하지 않는다. 구현된 시스템 시장은 다수의 비호환 프로세서로 구성되는 특징을 또한 가진다. 무효 표준의 이 공백은 상당히 간편한 네트워크 해법을 장려한다.

에너지 필요조건 감소

여기서 기술되는 발명은 에너지 필요조건의 측면에서도 매우 효율적이다. 고도로 최적화된 스테이트 머신은 프로토콜의 인터넷 수트의 기능을 실현하기 위해 필요한 클럭 속도를 두 차수 이상 감소시킨다. 이는 연장된 배터리 수명과 발생 열 감소를 동반한다. 상기 발생 열이란, 여기서 기술되는 발명과 함께 설계되는 제품에 의해 발생되는 열을 말한다.

보안성 향상

모뎀과 함께 하드웨어에 네트워크 스택을 구현함으로서, 발명은 매우 안정하고 침범이 어려운 네트워크 스택을 제공한다. 이는 미리 소켓 연결이 설정되어 있지 않을 때 수신되는 패킷을 무시하는 하드웨어 구조 구현 때문이다. 더욱이, 패킷은 모뎀 카드를 지나 얻어지지 않아서, 요청되지 않은 패킷과 소프트웨어 사이의 상호작용을 불가능하게 한다. 추가적으로, HTML 패킷 스니퍼를 포함함으로서, HTML 레이팅 태그를 디코딩하는 것이 가능하다. 패킷 스니퍼는 패킷 버퍼의 바이트를 해역하고, 프리셋 레이팅 레벨 내에 있는 페이지만을 통과하도록 설정될 수 있다. 프로그래밍된 레이팅 레벨을 초과하는 페이지에 대해서, HTML 스니퍼는 실패 검색 메시지를 통과시키고, 모뎀 서브시스템을 지난 HTML 내용을 허용하지 않는다. 이는 모뎀을 내용 구동 미니-방화벽으로 변환시킨다.

레이팅 태그를 포함하지 않는 페이지에 대하여, 스니퍼는 상기 페이지들을 전혀 통과시키지 않을 수도 있고, 통과시킬 수도 있다. 레이팅 레벨은 보드 세팅을 통하여만, 즉 하드 와이어드를 통해 프로그래밍될 수 있다. 하드웨어에서 이 해법을 구현할 때의 장점은 어떤 웹 사이트를 필터링 아웃하고자 하는 사람이나 부모에 대해, 시스템의 모뎀 카드를 빼내지 않으면서 이 시스템 주위를 돌아보는 것이 불가능하다는 점이다. 어떤 소프트웨어 해법으로, 사용자는 비-필터링 브라우저를 간단히 로딩할 수 있고, 어떤 플러그-인을 작동시키지 않을 수 있으며, 필터가 바이패스될 수 있다. 모뎀 카드 상의 하드웨어에 필터를 제공함으로서, 기능을 바이패스할 방법이 없다.

시스템 구현

도 3은 인터넷 즉시 접속 모뎀 시스템의 블록 다이어그램이다.

데이터 전송

인터넷 즉시 접속 모뎀(31)을 갖춘 시스템에서, 인터넷 장치는 먼저 소켓 패러미터를 설정한다. 이는 종착지 포트 번호, 접속 종류(TCP/UDP), TOS(서비스 종류) 필요조건, 그리고 종착지 IP 어드레스를 포함한다. 인터넷 즉시 접속 모뎀(31)의 네트워크 스택(30)이 본 정보를 얻을 때, SYN 패킷을 전송함으로서 접속 시작을 기도한다. 이 패킷은 네트워크 스택 내에 IP 엔진에 연결되고, 상기 네트워크 스택은 IP 헤더에 부착되고, IP 헤더 체크섬을 연산한다. 패킷은 네트워크 스택 내에 PPP 핸들러에 보내지고, 상기 네트워크 스택은 PPP 헤더를 부착하고, PPP 체크섬을 첨부하며, 데이터를 이탈시킨다. PPP 캡슐화 이후에, 결과적인 네트워크 패킷은 모뎀 코어(33)에 출력 FIFO(32)를 통해 전송된다. 이 패킷에 대해, TCP 엔진은 패킷 분석 블록(34)에, SYN 패킷임을 나타낸다. 패킷 분석기(34)는 모뎀에, 이것이 스탠드 얼론 패킷이고 즉시 전송될 수 있다는 점을 나타낸다. 이 정보를 수신할 때의 모뎀은 추가적인 정보가 다가오는 지를 보기 위해 정상적인 50 ms를 기다리지 않으면서 네트워크 패킷을 전송한다.

종착지 소켓이 역방향 SYN-ACK 패킷을 전송한 후에, ACK 패킷은 모뎀 카드로부터 전송된다. 이 패킷은 SYN 패킷의 단계와 동일한 과정을 따른다. 이 때, 소켓 연결이 이루어지고, (웹 브라우저(21)와 같은) 장치 소프트웨어가 통지된다. 장치는 데이터 패킷 형태로 모뎀에 직접 데이터를 전송할 수 있다.

도 3에 도시되는 예에서, 장치가 웹 브라우저일 때, 장치는 정규 모뎀 시스템에서의 직렬 포트 I/O 인터페이스에 반하여 패킷 인터페이스(38)를 통해 모뎀 시스템에 직접 HTTP 요청을 보낼 수 있다. DMA 스타일 데이터 전송은 이 용도로 사용될 수 있다. 이 방법에서, 데이터 바이트 카운트는 패킷 인터페이스로 프로그래밍된다. 데이터는 호스트 CPU로부터 추가적인 간섭없이 메모리로부터 모뎀 카드로 자동적으로 전송될 수 있다. 모든 데이터가 전송된 후에, 모뎀 카드로부터의 인터럽트는 호스트 CPU(23)에 전송될 수 있어서, 데이터 전송이 완료되었음을 나타낸다.

데이터가 모뎀 카드에 도착함에 따라, 데이터는 (본 실시예에서) TCP 데이터 출력 버퍼에 전송된다. 모든 데이터가 수신된 후, 또는 패킷 당의 최대 데이터 크기가 수신되었을 때, TCP 블록은 체크섬 연산을 시작한다. 패킷은 SYN 패킷과 동일한 방식으로 캡슐화된다. 이와 마찬가지로, 네트워크 스택의 TCP 엔진은 패킷 분석 블록에, 패킷의 종착지 포트가 (80)이고, 이는 공지된 HTTP 포트임을 나타낸다. 패킷 분석기는 이때, 더 이상의 데이터가 없으며 모뎀이 현재 패킷을 즉시 전송해야 한다는 것을 알게된다.

데이터 수신

네트워크 패킷을 수신할 때, 데이터는 모뎀 코어(33)로부터 입력 FIFO(35)를 통해 네트워크 스택의 PPP 엔진까지 전송된다. 네트워크 스택은 PPP 헤더를 분석하고, 데이터 이탈을 막으며, 체크섬 연산에 대한 패킷의 체크 구동을 시작한다. 캡슐화된 데이터가 IP 패킷임을 엔진이 결정하면, 네트워크 스택의 IP 엔진을 작동시키고, PPP 헤더를 지나는 모든 데이터는 IP 엔진으로 전달된다. IP 엔진은 IP 헤더를 분석하고, 체크섬을 확인하며, 캡슐화된 프로토콜이 TCP임을 결정하면, IP 헤더를 지난 모든 데이터를 네트워크 스택의 TCP 엔진에 전송한다. 이때, TCP 엔진은 TCP 헤더를 분석하고, 보안 레이어(36)에 데이터부를 전송한다. 데이터가 HTML 데이터이면, 페이지의 레이팅 태그를 분석하는 레이팅 태그를 통과할 수 있다. 페이지가 모뎀 카드 세팅 이하의 레이팅을 가지면, 데이터는 통과될 것이다. 레이팅이 카드의 세팅을 초과하면, 이를 표시하는 메시지가 대신에 나타날 것이다. 페이지가 어떤 레이팅도 포함하지 않으면, 비트가 페이지를 통과하거나 막도록 설정될 것이다. 모든 비-HTML 데이터가 TCP 데이터 버퍼(37)까지 직접 전달된다.

데이터가 버퍼에 쓰여지고 있을 때, 수신된 데이터의 양을 러닝 카운트가 지켜본다. 네트워크 패킷의 단부에서, 전체 패킷이 에러없이 수신되었음을 PPP 체크섬이 나타내면, 호스트 CPU(23)에 인터럽트가 발생할 것이다. 장치는 수신된 데이터 카운트를 읽을 수 있고, TCP 버퍼로부터 메인 메모리로 데이터를 전송하기 위해 DMA 전송을 프로그래밍할 수 있다.

발명의 특징

다음의 논의 사항은 발명의 다양한 특징을 기술한다.

1. 블록 장치로서의 모뎀

2. 패킷 패러미터에 바탕한 잠재시간 최적화

a) 패킷 최적화의 기본 단부

b) IP TOS 플랙에 바탕한 최적화

c) UDP/TCP 포트 번호에 바탕한 최적화

d) TCP 스테이트에 바탕한 최적화, 그리고

e) 잠재시간 표

3. 완전한 인터넷 액세스 장치로서의 모뎀

a) 부분 스택 해법

i) PPP/IP

ii) PPP/IP/ICMP, 그리고

iii) PPP/IP/ICMP/UDP, 그리고

b) 완전 스택 해법(PPP/IP/ICMP/UDP/TCP)

4. 인터넷 가능 모뎀에서의 향상된 보안성 및 HTML 필터링

다음의 논의 사항은 상기 특징들을 더욱 상세히 기술할 것이다.

블록 장치로서의 모뎀

모뎀 하드웨어에 포함된 네트워크 레이어에 따라, 다른 데이터 형태가 모뎀 서브시스템에 전송될 수 있다. 그러나 어떤 구현에서도, DMA 전송은 전송에 요구되는 CPU 오버헤드를 최적화시키는 데 사용할 수 있다.

다음의 내용을 위해 도 4를 참조할 수 있다. 전체 네트워크 스택(40)이 모뎀 카드(41)에 포함되는 실시예에서, 장치(42)의 데이터만이 전송될 필요가 있다. 소프트웨어 장치(44)는 소켓 API(43)를 통해 모뎀 카드와 통신한다.

최소에서, PPP만이 모뎀에 첨가될 수 있다. PPP의 기능은 IP 패킷(데이터 블록)을 직렬 스트림으로 변형시켜서, 직렬 장치에 전송될 수 있게 한다(도 5 참조). PPP 프로토콜은 직렬 링크(즉, 압축 기도와 이탈 바이트)에서 데이터를 전송하는 데 사용되는 패러미터를 협상할 책임이 있다. 모뎀 내부에서 실행되는 PPP 기능(50)으로, 모뎀과 IP 프로토콜 스택 소프트웨어 사이의 통신이 에더넷 카드와 IP 스택이 통신하는 방식과 유사한 방식으로 작동한다.

에더넷 카드에 대해, 패킷은 IP 프로토콜 스택으로부터 장치 드라이버까지 운반된다. 모뎀의 경우에, 장치 드라이버는 모뎀과 호스트 컴퓨터까지/로부터 데이터 블록을 전송하는 간단한 인터페이스 소프트웨어 프로그램이다. 도 6b에서 발명에 따르는 모뎀의 구조와 도 6a의 기존 모뎀의 구조를 비교할 수 있다.

발명의 본 실시예는 앞서 기술된 장점을 모든 효율로 작동시키고, 매력적인 해법이다. 왜냐하면, 기존 모뎀 칩 세트에 최소량의 부가 로직만을 첨가함으로서 실현가능하기 때문이고, 지원을 위해 512 바이트 이하의 메모리만을 사용하기 때문이다. 이는 어떤 기존 모뎀에 더하기에 매우 합리적인 가격이다.

잠재시간 최적화

기존 모뎀은 운반하는 데이터의 종류에 대한 정보를 전혀 가지지 않으며, 그 프로토콜은 상호작용하는 캐릭터 기반의 인터페이스를 위해 최적화된다. 기존 모뎀 프로토콜은 정보 전송 이전에 50 ms의 지연하에 구축된다. 데이터의 정지와 시작 위치에 관한 정보를 모뎀은 전혀 가지지 않으므로 이 지연이 존재하고, 그래서, 더 이상의 데이터가 전송되지 않는다는 사실을 알 때까지 기다린다.

인터넷의 유행으로, 거의 모든 모뎀이 인터넷 접속에 사용된다. 이 지식과, 패킷 시작 및 정지에 관한 정보를 이용하는 것은 모뎀 전송 최적화를 도울 수 있다. 모뎀 프로토콜에 구축된 50 ms의 지연을 감소시키거나 제거함으로서, 한 모뎀으로부터 다른 모뎀에 인터넷 프로토콜 패킷을 이동시키는 데 걸리는 시간의 양을 이 최적화는 감소시킬 수 있다. 어떤 지연이 있어야 할지, 또는 모뎀이 패킷을 처리하기 전까지 얼마의 시간이 필요한 지를 결정하기 위해 네트워크 패킷의 다른 부분을 이용하여 발명의 이 특징은 확장될 수 있다. 이 최적화를 조율하는 하드웨어 모듈은 패킷 분석 블록(34)이다(도 3 참조).

패킷 최적화의 기본 단부

대부분의 기본 레벨에서, 패킷을 전송하기 전에 작은 양의 시간을 기다리도록 모뎀 프로토콜에 말하기 위해, PPP 패킷의 단부의 지식을 이용할 수 있다(도 7 참조). 기존 모뎀 모델에서, (V42와 같은) 모뎀 프로토콜 프레임을 제작하기 위해 충분한 바이트가 존재하지 않을 경우, 모뎀은 패킷의 타이밍 아웃과 전송 이전에 50 ms까지 그이상의 데이터를 기다릴 수 있다. PPP 패킷과 캡슐화된 프로토콜의 단부의 지식으로, 모뎀은 완전한 패킷을 가진다는 것을 아는 패킷의 전송을 촉진시킬 수 있다.

이 알고리즘은 LCP(링크 제어 프로토콜), PAP(패스워드 인증 프로토콜), CHAP(도전 신호 변경 인증 프로토콜), NCP(네트워크 제어 프로토콜)와 같은 PPP 서브프로토콜을 위해 사용될 수 있다. 이들과, 그 유사한 PPP 서브프로토콜로, 전송되는 패킷은 독립형이다. 즉, 모든 정보가 단일 패킷 내에 포함된다. 또한, 패킷이 전송된 후의 대부분의 경우에, 장치가 다른 장치로부터 응답을 기다리기 때문에, 어떤 데이터도 더 이상 전송되지 않는다. 그러므로, PPP 패킷이 PPP 서브-프로토콜을 포함하는 것을 패킷 분석기가 감지하면, PPP FCS 필드를 감지할 때, 데이터 전송 이전에 정상 적인 50 ms 대신에 단 2 ms만을 기다리도록 모뎀에게 지도할 수 있다. 최소한 2 ms 이상을 기다리는 이유는 LCP 인증과 PPP 혐상의 NCP 위상 사이의 전송에서, 등을 맞댄 패킷이 전송될 수 있기 때문이다. 그러나, 두 개의 등을 맞댄 패킷 이상은 존재하지 않으며, 제 2 패킷은 제 1 패킷의 2 ms 내에 즉시 추종할 것이다.

PPP 서브-프로토콜 패킷의 명령 코드를 봄으로서 또한번의 최적화가 발생할 수 있다. 명령 종류와 이에 상응하는 잠재시간 세팅의 예시된 매트릭스가 표 2에 도시된다.

표 2

IP 헤더 필드에 바탕한 최적화

TOS 필드에 바탕한 최적화

IP, TCP, 그리고 UDP 패킷에 대해, 패킷 전송 시간이나 시점에 대한 보다 현명한 결정이 IP 헤더의 서비스 필드의 종류를 검사함으로서 결정될 수 있다. TOS 필드는 패킷에 요구되는 우선성과 신뢰성을 기술한다. TOS 필드에 대해 설정가능한 성질로는 지연 최소화, 시간내 작업 처리량 최대화, 신뢰성 최대화, 그리고 비용 최소화가 있다. 정보는 시간 지연을 기다리는 변수를 설정하는 데 사용될 수 있거나, 모뎀 버퍼의 내용을 즉시 전송하는 데 사용할 수 있다.

캡슐화된 프로토콜에 바탕한 최적화

IP 헤더 필드에 바탕하여 실시도는 또다른 최적화는 프로토콜 필드의 잠재시간 설정을 바탕으로 한다. 대부분의 ICMP 및 IGMP 패킷은 자체 내장되어, 최소 대기 시간이 전송 이후에 필요해진다. IP 패킷이 IGMP 또는 ICMP 패킷을 포함한다고 패킷 분석기가 결정한 후에, 패킷을 즉시 전송하기 위해 모뎀 코어에 신호를 보낼 수 있다.

패킷 포트에 바탕한 최적화

어떤 종류의 인터넷 서비스는 송수신을 위해 단 한 패킷의 데이터만 필요로하는 정보 분포를 가진다. 이러한 종류의 서비스로, 더 이상의 데이터를 대기하지 않으면서 즉시 패킷을 전송하는 것이 최선이다. 다른 인터넷 서비스는 또다른 패킷 분포 패턴을 가지고, 상기 또다른 패킷 분포 패턴은 UDP와 TCP에 대해 최적화될 수 있다. 상기 UDP와 TCP는 IP의 상부에 사용되는 메이저 프로토콜이다. 둘 모두는 서비스를 기술하기 위해 포트를 이용한다. 도 9는 UDP와 TCP 모두에서 실행되는 포트 정보가 모뎀 잠재시간을 최적화하기 위해 어떻게 사용되는 지를 예로 제공한다.

잠재시간 표(90)는 더 이상의 데이터에 대한 패킷의 단부 이후에 대기할 시간의 양과 포트의 표를 포함한다. 이 방법을 사용하여 최적화한 예는 DNS 장치이다. 이 장치에서, 메시지의 전체 데이터부는 인터넷 패킷에 쉽게 맞춰진다. 그러므로, UDP 헤더 내의 종착지 포트를 검사한 후에 이것이 DNS 패킷으로 결정되면, 더 이상 다가올 패킷이 없기 때문에 패킷은 즉시 전송될 수 있다. 표 3은 프로토콜-포트 잠재시간 표의 예를 제공한다.

표 3

패킷 스테이트에 바탕한 잠재시간 최적화

TCP는 스테이트를 기반으로 하는 프로토콜이고, 일부 스테이트는 잠재시간 최적화에 사용될 수 있는 공지된 성질을 가진다. 예로는 모든 TCP 접속이 시작할 때의 세가지 방식의 신호 변경이 있다.

표 4

잠재시간 표

잠재시간 표는 패킷의 특성에 의해 트리거링되는 다수의 입력을 가지는 스테이트 머신이다. 이 입력으로부터, 잠재시간표는 모뎀 프로토콜을 위해 최적화된 잠재시간값을 생성하고, 시스템을 통과한 것처럼 각각의 패킷을 효율적으로 최적화한다. 잠재시간 표의 블록 다이어그램은 도 11에 도시되고, 앞서 기술된 정보가 조합된다.

IP 잠재시간 리졸버(110)는 IP 서브프로토콜 잠재시간 표(111)와 IP TOS 필드 잠재시간 표(112)로부터 입력을 취하고, 두 값 중 낮은 값을 선택한다. TCP 잠재시간 리졸버(113)는 종착지 포트 잠재시간 표(114)와 TCP 스테이트 잠재시간 표(115)에 대한 유사한 기능을 실행한다. IP 잠재시간 리졸버와 TCP 잠재시간 리졸버 출력은 조합된 잠재시간값을 생성하기 위해 먹스된다(먹스 선택은 IP 서브프로토콜 잠재시간 표(111)에 의해 분석되는 바와 같이 IP 헤더의 프로토콜 필드에 의해 결정된다). PPP 잠재시간 표(116)에 의해 한 개의 값이 또한 제공된다. 이 값은 IP 잠재시간 리졸버와 TCP 잠재시간 리졸버의 먹스된 값으로 먹스된다. 먹스(118)에 대한 먹스 선택은 PPP 잠재시간 표(116)에 의해 분석되는 바와 같이 PPP 헤더의 프로토콜 필드에 의해 결정된다. 최종 잠재시간값은 이때 모뎀 서브시스템에 전송된다.

완전한 인터넷 액세스 장치로서의 모뎀

확장된 인터넷 모뎀 모델은 독립형이고, 실현가능하며, 고도로 집적된 통신 제품이다.. 상기 모델은 거의 모든 전자 장치를 인터넷에서 작동시킬 수 있다(도 12 참조). 이 해법은 앞서 기술된 프로세서 바탕의 해법에 대해 수많은 장점을 가진다. 특히, 이 구조로 인해, 게임 콘솔과 VCR과 같은 비-컴퓨터 장치에도 인터넷을 지원할 수 있다. 제한된 메모리 영역을 가지면서 항상 네트워크를 지원할 필요가 없는 상기 장치들에 대해 이 구조는 또한 매우 유용하다. 이것의 예로 팜 파일롯 타입 장치가 있고, 추가되는 네트워크 지원이 필요할 때만이 모뎀이 사용되는 경우이다. 발명의 장점은 항상 사용되지는 않는 특징에 메모리 리소스를 낭비할 필요가 없다는 데 있다.

보안 장점 향상

앞서 기술한 바와 같이, 하드웨어 기반의 네트워크 스택을 가지는 하나의 보안성 이점은 정해진 소켓 연결에 대해 예정된 수신 패킷만이 모뎀 서브시스템을 지나도록 허락받는 데 있다. 모든 다른 패킷은 하드웨어 레벨에서 필터링 아웃되어, 이 패킷들과 소프트웨어간의 상호작용을 불가능하게 한다. 또한, HTML 스니퍼의 추가로, V-칩같은 필터링이 쉽게 극복될 수 없도록 제공될 수 있다. HTML 스니퍼의 블록 다이어그램은 도 13과 14에 도시된다.

도 13에서, 패킷(138)이 TCP 엔진(139)에 수신된다. 패킷은 특정 소켓을 향할 것이다. HTML 패킷 스니퍼(144)는 수신된 패킷 버퍼(145)에 패킷이 위치하는 지를 결정하기 위해 패킷에 가해지는 프리셋 레이팅(146)을 가진다.

도 14에서 도시되는 바와 같이, HTML 패킷 스니퍼 내에서, HTTP 반응 분석기(140)는 소켓(141)으로부터 수신된 패킷을 취하고, 데이터 내용이 유효한 HTML 데이터를 포함하는 지를 결정하기 위해 HTTP 헤더를 해역한다. 만약 그러하면, HTML 레이팅 디코더(142)를 작동시키고, 이는 레이팅 태그에 대한 HTML 데이터를 분석하기 시작한다. HTML 디코더는 모든 수신 데이터를 수신 패킷 버퍼(145)(HTTP 헤더 포함)에 기록하고, 동시에 태그를 분석한다. 레이팅 태그를 감지하면, 카드 프리셋 레이팅 레벨에 페이지 레이팅을 비교한다. 통과하면, 페이지는 수신 버퍼에의 저장을 계속한다. 페이지가 실패하면, 모든 추가적인 데이터가 억압되고, 메모리 버퍼는 현 패킷 수신 이전의 점으로 리셋되고, 거절 메시지가 메모리에 저장된다. 레이지가 페이지 헤드에 어떤 레이팅도 포함하지 않으면, 카드는 페이지를 통과시키거나 거절하도록 할 수 있다.

도 15에서, 발명의 또다른 실시예는 네트워크 프로토콜 레이어(1010), 데이터 핸들러(1020), 메모리 제어 모듈(1030), 그리고 작동 시스템(O.S.) 스테이트 머신 모듈(1040)로 구성되고, 그 각각은 하드웨어 게이트 레벨에서 구현된다. 네트워크 프로토콜 레이어(1010)는 유입되는 네트워크 패킷을 디코딩하고, 유출되는 네트워크 패킷을 인코딩한다. 네트워크 프로토콜 레이어(1010)는 다수의 스테이트 머신으로 구성되고, 상기 스테이트 머신은 유입되는 네트워크 패킷을 동시에 디코딩하는 다른 네트워크 프로토콜 스택(즉, PPP, TCP, IP, UDP, 그리고 로오 소켓)을 나타낸다. 게이트 레벨 로직의 프로토콜 스택의 구현은 패킷이 수신됨에 따라 네트워크 패킷의 실시간 디코딩을 허용하여, 어떤 임시 메모리 저장도 필요없게 한다. 모든 패킷 헤더 정보가 스테이트 머신에 의해 확인된 후에, 결과적인 데이터는 데이터 핸들러(1020)에 전송된다. 데이터 핸들러(1020)는 다수의 스테이트 머신으로 구성되고, 그 각각은 특정 데이터 종류(즉, HTTP, 전자 메일 형태(포스트 오피스 프로토콜(POP3), 인터넷 메시지 액세스 프로토콜(IMAP4), 간단한 메일 전송 프로토콜(SMTP)), 그래픽 표준(조인트 사진 엑스퍼트 그룹(JPEG), 그래픽 인터체인지 포맷(GIF), 자바, 그리고 HTML)를 처리한다. 데이터 핸들러의 게이트 레벨 구현은 수신된 데이터를 실시간으로 동시에 처리할 수 있게 하고, 수신에 따라 데이터 스트림을 좌우하는 장치(즉, 자바, HTML, POP3 전자 메일, 그리고 음향 및 영상 장치)에 특히 적합하다. 특정 데이터 스테이트 머신에 의해 한번 이상 요구되는 어떤 데이터도 동시 방식으로 제공된다. 특정 데이터 스테이트 머신에 의해 한번 이상 요구되는 어떤 데이터도 데이터 표시 포인터로 특정 메모리 위치에 자리잡는다. 모든 메모리 액세스는 메모리 제어 모듈(1030)을 통해 조정된다. 어떤 결과적인 디스플레이 데이터도 메모리 제어 모듈(1030)을 통한다. O.S. 스테이트 머신(1040)은 리소스 제어, 시스템, 그리고 사용자 인터페이스에 대한 모든 스테이트 머신 사이에 조정자로 작용한다. 어떤 사용자 입력도 O.S. 스테이트 머신에 의해 해역되고, 데이터 핸들러(1020)로 인도된다.

한 예로서, HTML 포맷을 해역하는 데이터 핸들러는 사이클릭 용장도 검사(CRC) 연산을 이용하여 HTML 태그를 디코딩한다. HTML 포맷은 태그로 알려진 캐릭터 스트링을 포함하고, 상기 스트링은 영상 출력 장치에서 디스플레이될 때, 이어지는 블록의 텍스트의 포매팅을 제어한다. 주어진 태그에 대한 CRC 번호를 발생시킴으로서, 그리고 포매팅 명령을 작동시키는 상기 번호를 이용함으로서, 이 태그들은 효율적으로 디코딩될 수 있다. 이러한 디코딩 알고리즘은 게이트 레벨 구현에 대해 적합하고, 동시에 가능한 것보다 훨씬 더 빨리 영상 출력 장치에 HTML 인코딩 문서가 디스플레이되게 한다.

발명이 하드웨어 게이트 레벨에서 기술되고 있지만, 프로그래밍가능한 어레이 로직(PAL), 일반 어레이 로직(GAL), 읽기 전용 메모리(ROM), 그리고 소프트웨어와 같은 다른 많은 방법으로 이 기능들이 구현될 수 있다는 점을 당 분야의 숙련자는 알 수 있을 것이다. 추가적으로, 특정 프로토콜과 데이터 종류가 표시되고, 발명의 모듈 방식이 특정 프로토콜이나 데이터 종류에 제한되지 않는 다는 점을 당 분야의 숙련자는 쉽게 알 수 있을 것이다.

도 16에서, 발명은 하이-레벨 블록 다이어그램으로 나타난다. 이 다이어그램은 발명을 충분히 구현하는 각각의 모듈의 작동 태스크를 기술한다. O.S. 스테이트 머신(2080)은 시스템 "글루" 로직과 장치 제어 인터페이스를 포함하고, 다른 모듈의 스테이트 머신 사이에서 "트래픽 캅(교통 경찰)"으로 작용한다. 네트워크 프로토콜 레이어(2070)는 TCP/IP, UDP, 로오 소켓, 그리고 PPP 프로토콜에 대한 스테이트 머신을 포함한다. 메모리 제어 모듈(2060)은 동일 메모리 영역에 시스템 및 영상 디스플레이 메모리가 위치하게 하는 통합 메모리 구조(UMA)에 대한 로직을 포함한다. 디스플레이 제어기(2050)는 VGA, 텔레비젼 표준, 또는 다른 종류의 디스플레이를 제어한다. 네 개의 데이터 핸들러가 이 구현에서 이용된다. 전자 메일 데이터 핸들러(2010)는 POP3와 IMAP4 포맷 모두를 해역한다. 인터프리터(2020)는 JPEG와 GIF 포맷을 디코딩하도록 구현된다(상용 및 전화 표준도 디코딩된다). 자바 머신(2030)이 또한 포함되어, 자바 언어 바이트 코드를 해역한다. 월드 와이드 웹(WWW) 브라우저(2040)는 HTML 디코더/가속기, HTTP 데이터 핸들러, 그리고 집적 전자 메일 스테이트 머신을 포함한다.

한 예로서, 모뎀 물리적 전송 하에서, 유입되는 JPEG 이미지 패킷이 시스템을 통한 흔적을 남긴다. 자판(3210) 타이핑에 의해 주어진 JPEG 이미지를 다운로딩하고자 하는 의도를 표시하는 사용자와 함께, 이 요청이 시작된다. 이 입력은 자판 인터페이스(3160)에 의해 해역되고, O.S. 스테이트 머신(3150)에 전송된다. O.S. 스테이트 머신(3150)은 이 입력을 처리하고, HTTP 클라이언트(3110)에게의 명령으로 이 입력을 통과시킨다. HTTP 클라이언트는 요청 패킷을 생성하고, 포트 디코더(3090)를 통해 TCP 레이어(3080)에 이를 보낸다. TCP 레이어는 적절한 TCP 헤더를 채택하고, IP 레이어(3070)에 이를 보낸다. IP 레이어는 이때 적절한 IP 헤더를 채택하고, PPP 레이어(3060)에 패킷을 보낸다. PPP 레이어는 적절한 헤더를 채택하고, FCS를 첨부하며, 물리적 전송 인터페이스(3050)에 데이터를 전송한다. 물리적 전송 인터페이스는 데이터를 비트 스트림으로 나열하고, 모뎀 유닛(3040)에 패킷을 전송한다. 요청이 호스트 서버에 의해 받아들여질 때, 요청된 JPEG 이미지를 클라이언트 시스템에 되보낸다. 먼저, 데이터가 존재하는 것을 물리적 전송 인터페이스(3050)에 표시하는 모뎀(3040)에 의해 데이터는 수신된다. 이때, 물리적 전송 인터페이스는 모뎀으로부터 비트 직렬 데이터를 읽고, 병렬 바이트 데이터로 변화시키며, 그리고 데이터가 존재함을 PPP 레이어(3060)에 표시한다. PPP 레이어는 수신된 바이트를 읽는다. 유효한 시작 바이트로 판명될 경우, 유입 바이트 분석을 시작한다. 바이트 스트림이 PPP 프로토콜 필드에 도달할 때, PPP 레이어는 디코딩을 실시하고, 이 예에서 IP 종류처럼 구체화된 패킷을 디코딩한다. 이 프로토콜 바이트에 따라, PPP 레이어는 IP 레이어(3070)를 작동시키고, IP 데이터가 수신되고 있음을 표시한다. 수신되는 모든 부가적인 데이터 바이트는 IP 레이어에 직접 전달된다. 이때 IP 레이어는 유입 데이터 바이트 분석을 시작한다. IP 헤더 프로토콜 필드에 도달하면, 어느 높은 프로토콜이 작동하는 지를 결정한다. 본 예에서, IP 레이어는 TCP 종류처럼 프로토콜 필드를 디코딩한다. 이때, IP 레이어는 TCP 레이어(3080)를 작동시키고, TCP 데이터가 수신되고 있을 때를 표시한다. 이 표시 장치가 활성화되면, 수신된 패킷의 모든 추가적인 데이터 바이트는 IP 및 TCP 레이어에 전송된다(IP 레이어는 체크섬 연산을 완료하기 위해 데이터 바이트를 필요로 한다). 이때, TCP 레이어는 유입 데이터 바이트를 분석하기 시작한다. TCP 헤더 종착 포트 필드에 도달할 때, 작동한 데이터 핸들러를 결정한다. 본 예에서, 포트 필드는 HTTP 클라이언트(3110)에 디코딩된다. 이 점에서, 포트 디코더는 HTTP 클라이언트를 작동시키고, HTTP 요청 데이터가 수신되고 있음을 나타낸다. 이때, HTTP 클라이언트는 수신된 데이터 바이트를 분석하기 시작한다. 패킷이 JPEG 이미지 종류임을 클라이언트가 결정하면, HTTP 클라이언트는 JPEG 디코더(3130)를 작동시킨다. 이 점에서, 모든 데이터 바이트는 JPEG 디코더로 인도된다. JPEG 디코더는 이때 모든 추가적인 유입 데이터 바이트를 수신하고, 차례로 이들을 처리한다. 결과적으로 디코딩된 이미지는 메모리 제어기(3120)를 통해 디스플레이 메모리에 전송되어, 디스플레이 장치(3260)에 출력하기 위해 디스플레이 제어기(3240)에 의해 처리된다.

도 17에서, 다양한 레이어가 공유된 메모리 리소스에 액세스를 필요로 한다. 모든 메모리 액세스는 단일 메모리 제어기에 의해 조정된다. 주어진 사이클에서 통합 메모리 버퍼에 액세스되는 레이어나 핸들러를 이 메모리 제어기가 결정한다. 모든 시스템과 디스플레이 메모리 버퍼가 단일 메모리 버퍼 유닛 내에 공유되는 사실로 인해, 메모리 제어기가 필요하다. 통합 메모리 제어기(3120)는 다양한 레이어로부터 읽기 및 쓰기 요청을 취하고, 고정된 우선 웨이팅으로 동적 회전 조정 스킴에 바탕한 요청을 조정한다. 이 알고리즘은 도 17A에 묘사된다. 도면의 구조에서, 장치 D2 3020A와 장치 D3 3030A 모두가 동시에 메모리 액세스를 요청하면, 아비터(arbitor)(3070A)는 가장 최근의 메모리 액세스를 가지지 않는 장치에 사이클을 수여한다. 이때 아비터(3070A)는 메모리 요청을 A 입력 아비터(3090A)전달한다. 아비터(3090A)의 B 입력이 아이들이면, 상기 요청이 아비터(3100A)의 B 입력까지 전달된다. 아비터(3100A)에의 A 입력이 아이들이면, 상기 요청은 메모리 유닛에 전달된다. 모든 조정 결정은 조합 로직을 이용하여 실행되어, 다른 어떤 메모리 요청이 구성되고 있지 않다면, 어떤 장치의 어떤 대기 상태를 제거할 것이다. 우선 웨이팅(priority weighting)은 조정 트리 구조를 배치함으로서 할당된다. 도 17A에서, 장치 D0 3000A와 장치 D1 3010A 각각은 25% 우선 웨이팅 의미를 가지고, 상기 의미는 모든 장치가 일정한 메모리 사용을 요청했을 때, 각각 시간의 조정 25%을 얻는 것을 의미한다. 장치 D2 3020A, D3 3030A, D4 3040A, D5 3050A 각각은 12.5% 우선 웨이팅을 가진다. 메모리 제어기 설계는 동일 로직 구조를 가지는 개별 조정 유닛을 가짐으로서 간단화된다. 이 도식에서, 요청 장치의 수와 그 우선 웨이팅은 아비터 유닛을 부가하고 배열함으로서 쉽게 배치된다.

도 18에서, 발명에서 제공되는 속도 장점은 현재 사용중인 기존 구조에 비해 훨씬 높다. 도면은 각각의 태스크를 완료하는 데 필요한 시간을 나타낸다. HTML 다운로드(4010), HTML 디코드(4020), JPEG 다운로드(4030), JPEG 디코드(4040), 자바 다운로드(4050), 자바 바이트 디코드(4060), 스트리밍 오디오(4070)를 필요로 하는 일련의 패킷에 대해, 이 태스크에 요구되는 시간은 기존 구조(4080)와 발명(iREADY 구조)(4090)에 대해 도시된다. 발명(4090)은 기존 구조(4080)보다 이 태스크에 대해 훨씬 빠르다.

도 19에서, 이 종류의 네트워크 액세스에 대한 진보된 장치가 도시된다. 현재, 네트워크 클라이언트의 종래 모델, 즉 컴퓨터(5010)가 사용된다. 네트워크 PC(5020), 휴대용 장치(5030), 스마트 전화(5040), 셋-톱 장치(5050), 그리고 스마트 TV(5060)의 소비자 적용 개념이 실현되는 중이다. 발명은 비용을 절감하면서 공간, 속도, 그리고 전력을 중요시하는 네트워크 엑세스를 갖춘 이 제품을 제공한다.

도 20에서, 발명은 텔레비젼(6020)이나 라디오 튜너(6110)와 유사하게 작동한다. 즉, 신호(패킷)는 지연없이 즉각 처리되고, 디스플레이나 오디오 출력에 전달된다. 인터넷 튜너(6080)라는 용어는 이러한 신호 처리 장치와 유사하게 발명을 기술하기 위해 사용된다. 인터넷 튜너(6080)는 스마트 TV(6040), 셋-톱 장치(6050), 스마트 전화(6060), 휴대용 장치(6070)와 같은 장치 제품과 인터넷 신호(6090) 사이의 인터페이스로 작용한다. 텔레비젼(6020)과 라디오 튜너(6110)가 하는 것처럼 실시간으로 인터넷 신호(6090)를 처리한다.

O.S. 스테이트 머신(7010), 네트워크 프로토콜 레이어(7020), 메모리 제어기(7030), 디스플레이 제어기(7040), 전자 메일 데이터 핸들러(7080), 인터프리터(7070), 자바 머신(7060), 그리고 WWW 브라우저(7050)를 이용하는 발명의 충분한 구현이 두 분리된 모듈로 분리될 수 있다는 것을 도 21은 도시한다. 발명의 모듈 방식은 데이터 핸들러(7130)(전자 메일 데이터 핸들러(7170), 인터프리터(7160), 자바 머신(7150), 그리고 WWW 브라우저(7140))와 같은 기능을 분리시키고, 특정 장치에 대한 하이-레벨 ROM 코드로 위치시킨다.

다음의 장치 예는 발명의 모듈 설계의 다양성을 도시한다.

도 22는 네트워크 PC에 대한 발명의 가능한 구조를 도시한다. 한 변화는 O.S. 스테이트 머신(8010), 네트워크 프로토콜 레이어(8020), 메모리 제어기(8030), 디스플레이 제어기(8040), 전자 메일 데이터 핸들러(8080), 인터프리터(8070), 자바 머신(8060), 그리고 WWW 브라우저(8050)를 포함한다. 전자 메일용 데이터 핸들러(8170), 인터프리터(8160), 자바 머신(8150), 그리고 WWW 브라우저(8140) 코드를 마이크로프로세서(8130)에서 구동되는 하이-레벨 ROM으로 위치시킴으로서 이는 변화될 수 있다. 마이크로프로세서(8130)는 네트워크 및 디스플레이 기능을 위해 O.S. 스테이트 머신(8090)을 통해 통신한다. 세 번째 변화는 세 번째 부분 ROM(8230)을 구동하는 마이크로프로세서(8220)가 네트워크 프로토콜 레이어(8190)와 O.S. 스테이트 머신(8180)로부터 유입되는 데이터를 해역하게 한다. 마이크로프로세서(8220)는 디스플레이 제어기(8210)를 통해 데이터를 디스플레이한다.

도 23에서, 휴대용 장치는 네트워크 프로토콜 레이어(9010)만을 사용할 수 있고, 기존 전송 메카니즘(9020)과 기존 마이크로컨트롤러(9040)에 인터페이스를 취할 수 있다. 전자 메일 기능은 전자 메일 데이터 핸들러(905)를 포함함으로서 추가될 수 있다. 발명의 모듈 방식을 보여주는 것에 더하여, 네트워크 프로토콜 레이어(9110)와 자바 머신(9100)은 휴대용 장치에 더해져서, 자바 애플릿을 처리하게 한다.

도 24에서, O.S. 스테이트 머신(1001), 네트워크 프로토콜 레이어(1002), 메모리 제어기(1003), 전자 메일 데이터 핸들러(1006), 그리고 디스플레이 제어기(1004)를 구현함으로서, 스마트 전화는 전자 메일 능력을 추가할 수 있다. 디스플레이 제어기(1004)는 발광 다이오드(LED), 액정 디스플레이(LCD), 또는 큰 맵의 디스플레이를 제어할 수 있다. 물리적 전송 제어(1005)는 스마트 전화의 연결시 필요조건에 따라 추가적으로 부가될 수 있다. O.S. 스테이트 머신(1007), 네트워크 프로토콜 레이어(1008), 그리고 메모리 제어기(1009)는 기존 마이크로컨트롤러(10100)와 함께 스마트 전화에 부가될 수 있다. 마이크로컨트롤러(10100)는 제 3 부분 전자 메일 클라이언트 코드(1011)를 이용하여 전자 메일 기능을 실행한다.

도 25에서, 스마트 전화, 케이블 박스, 비디오 카세트 레코더(VCR), 디지털 비디오 디스크(DVD) 플레이어, 그리고 게임 머신은 발명에 의해 제공되는 네트워크 액세스 능력을 이용할 수 있다. O.S. 스테이트 머신(1102), 네트워크 프로토콜 레이어(1103), 메모리 제어기(1104), WWW 브라우저(1107), 자바 머신(1106), 그리고 (부가적으로) 디스플레이 제어기(1105)가 기존 제어기(1101)와 인터페이스를 취한다. 제어기(1101)가 없으면, 디스플레이 제어기(1105)가 사용된다. 전자 메일(1115) 기능은 발명의 모듈 방식으로 인해 쉽게 추가될 수 있다. 앞서 언급한 바와 같이, 전자 메일 용 데이터 핸들러(1124), 인터프리터(1123), 자바 머신(1122), 그리고 WWW 브라우저(1121) 코드가 마이크로프로세서(1120)에서 구동되는 하이 레벨 ROM으로 부가적으로 위치할 수 있다. 마이크로프로세서(1120)는 네트워크 및 디스플레이 기능을 위해 O.S. 스테이트 머신(1116)을 통해 통신할 수 있다.

패킷 수신의 예

도 26은 수신되는 네트워크 패킷을 도시한다. 패킷은 다음의 아이템을 좌측에서 우측으로 포함한다.

- PPP 헤더

- IP 헤더

- TCP 헤더

- JPEG 데이터

- PPP FCS(필드 체크섬)

유효한 시작 바이트가 감지될 때, 'PPP 레이어 작동'이라는 라벨의 라인이 활성화되고, 도 27의 PPP 블록 내에 발생된다. 이 라인이 높아지면, 나머지 PPP 블록이 활성화된다. PPP 헤더 내에, PPP 패킷이 캡슐화하는 프로토콜의 종류를 나타내는 필드가 있다. 압축되지 않은 PPP 헤더에서, 이들은 바이트(4, 5)이다(시작 바이트를 0x7e로 함). 도 26에서, 이 바이트들은 캡슐화 데이터가 IP 패킷임을 나타내는 0x00과 0x21이다. 이 필드를 디코딩한 후에, PPP 블록은 IP 레이어 작동과 PPP 데이터 필드 신호를 활성화시키고, 이는 도 27의 IP 블록을 함께 작동시킨다. IP 레이어 작동 라인은 PPP 프로토콜 필드로부터 디코딩되고, 유입되는 데이터 바이트 스트림이 네트워크 패킷의 데이터 필드부 내에 있다는 것을 PPP 데이터 필드 라인이 나타낸다. 이 두 라인들은 IP 블록 작동을 위해 활성화된다. IP 블록이 작동하면, 유입되는 데이터 바이트 분석을 시작한다. 도 26을 다시 참고해보면, PPP 헤더 바로 다음의 데이터가 IP 헤더이다. IP 헤더 내에는, IP 패킷 내에 캡슐화되는 데이터 종류를 나타내는 필드가 있다. 도 26에서, 이 필드는 캡슐화된 데이터가 TCP 패킷임을 나타내는 0x06이도록 도시된다. TCP 레이어 작동 라인은 이 필드를 디코딩하는 IP 블록에 따라 활성화된다. IP 데이터 필드 라인은 이후의 한쌍의 바이트를 활성화시키는 데, 이는 IP 헤더 프로토콜 필드와 IP 데이터 필드의 시작 사이에서 유입되는 일부 바이트가 존재하기 때문이다. 유입 데이터 바이트 스트림이 네트워크 패킷의 데이터 필드부 내에 있음을 IP 데이터 필드 신호가 나타낸다. TCP 레이어 작동 및 IP 데이터 필드 라인 모두는 도 27의 TCP 블록을 작동시키기 위해 활성화된다. TCP 블록이 작동하면, 유입 데이터 바이트를 분석하기 시작한다. 도 26에서, IP 헤더 바로 다음의 데이터가 TCP 헤더이다. TCP 헤더 내에는 종착 포트를 위한 2 바이트 필드가 있다. 이 필드는 캡슐화된 데이터가 지향하는 장치나 데이터 핸들러를 표시한다. 도 26에서, 이 필드는 포트 0x0003으로 디코딩한다. 도 27에서, 포트(3)는 HTTP 포트로 표시된다. TCP 헤더 내에 종착 포트 필드를 디코딩한 후에, HTTP 작동 라인이 활성화되고, TCP 데이터 필드 라인이 한쌍의 바이트로 활성화되며, 이는 TCP 데이터 필드의 시작과 종착 포트 필드 사이에 일부 중간 바이트가 있기 때문이다. HTTP 작동 및 TCP 데이터 필드 라인 모두는 도 27의 HTTP/PORT3 블록을 작동시키기 위해 활성화되어야 한다. HTTP 블록이 작동되면, 유입되는 데이터 바이트를 분석하기 시작한다. JPEG 헤더를 디코딩할 때, 도 27의 JPEG 디코더 블록을 작동시킨다. JPEG 디코더가 작동하면, 유입 바이트를 처리하기 시작한다. JPEG 작동 라인은 JPEG 블록을 작동시키기 위해 필요한 유일한 라인이다.

여기서는 선호되는 실시예를 참조로 하여 발명이 기술되었지만, 본 발명의 정신과 범위를 벗어나지 않으면서 다른 장치가 여기서 설명되는 장치로 대치될 수 있다는 것을 당 분야의 숙련자는 이해할 수 있을 것이다. 따라서, 발명은 첨부된 청구 범위에 의해서만 제한되어야 한다.

Claims

한 개의 모뎀으로서, 상기 모뎀은 모뎀 코어와 네트워크 스택으로 구성되며, 상기 네트워크 스택은 전자 네트워크에서 상기 모뎀으로 통신하기 위해 네트워크 프로토콜을 실행하는 것을 특징으로 하는 모뎀.
제 1 항에 있어서, 상기 네트워크 스택은 인터넷 네트워크 프로토콜 스택으로 구성되는 것을 특징으로 하는 모뎀.
제 1 항에 있어서, 상기 네트워크 스택은 데이터 블록을 송수신하는 것을 특징으로 하는 모뎀.
제 1 항에 있어서, 상기 네트워크 스택에서 구현되는 네트워크 프로토콜은 PPP, IP, TCP, 그리고 UDP 통신 레이어에 의해 요구되는 프로토콜을 포함하는 것을 특징으로 하는 모뎀.
제 1 항에 있어서, 데이터 전송에 필요한 CPU 오버헤드를 최적화하기 위해, 상기 네트워크 스택은 직접 메모리 액세스(DMA)를 지원하는 것을 특징으로 하는 모뎀.
제 1 항에 있어서, 상기 네트워크 스택은 PPP, IP, 그리고 TCP 패킷 스누핑을 실행하는 것을 특징으로 하는 모뎀.
제 1 항에 있어서, 패킷 전송에 사용되는 잠재시간의 크기를 결정하기 위해, IP 헤더의 TOS 필드는 상기 네트우커 스택에 의해 사용되는 것을 특징으로 하는 모뎀.
제 1 항에 있어서, 상기 네트워크 스택은 TCP 헤더를 확인함으로서 잠재시간 최적화를 실행하는 것을 특징으로 하는 모뎀.
제 1 항에 있어서, 모든 프로토콜 협상은 상기 네트워크 스택에 의해 상기 모뎀에 국부적으로 유지되는 것을 특징으로 하는 모뎀.
제 1 항에 있어서, 상기 네트워크 스택은 설정된 소켓 연결이 존재하지 않으면, 어떤 수신된 패킷도 무시하는 것을 특징으로 하는 모뎀.
제 1 항에 있어서, 상기 모뎀은 HTML 레이팅 태그를 디코딩하기 위한 패킷 스니퍼를 추가로 포함하고, 상기 패킷 스니퍼는 현재 레이팅 레벨 내에 있는 페이지만을 통과시키는 것을 특징으로 하는 모뎀.
제 11 항에 있어서, 상기 패킷 스니퍼는 레이팅 태그를 전혀 포함하지 않는 레이팅되지 않은 페이지를 통과시키지 않거나, 또는 상기 레이팅되지 않은 페이지를 통과시키도록하는 구조를 가지는 것을 특징으로 하는 모뎀.
제 11 항에 있어서, 레이팅 레벨은 하드 와이어드 세팅을 통해 프로그래밍될 수 있는 것을 특징으로 하는 모뎀.
제 1 항에 있어서, 소프트웨어 장치는 상기 모뎀과 소켓 AP1을 통해 통신하는 것을 특징으로 하는 모뎀.
한 개의 모뎀으로서, 상기 모뎀은 모뎀 코어와 네트워크 스택으로 구성되고, 상기 네트워크 스택은 하드웨어에서 구현되어, 전자 네트워크에서 상기 모뎀을 통신시키기 위해 네트워크 프로토콜을 실행하며, 상기 네트워크 스택은 인터넷 네트워크 프로토콜 스택으로 구성되는 것을 특징으로 하는 모뎀.
제 15 항에 있어서, 상기 네트워크 스택은 PPP 스택을 추가로 포함하고, 상기 PPP 스택은 직렬 링크에서 전송하기 위해 직렬 스트림으로 IP 패킷을 변환시키며, 상기 직렬 링크에서 데이터 전송을 위해 사용되는 패러미터와 협상하는 것을 특징으로 하는 모뎀.
제 15 항에 있어서, 상기 모뎀은 패킷 분석 모듈을 추가로 포함하고, 상기 패킷 분석 모듈은 네트워크 패킷의 다른 부분을 이용하여, 지연이 있어야 하는 지와, 만약 지연이 있다면, 상기 모뎀이 패킷을 처리하기 전에 얼마간 지속되어야 하는 지를 결정하는 것을 특징으로 하는 모뎀.
제 15 항에 있어서, 상기 모뎀은 패킷 분석 모듈을 추가로 포함하고, PPP 패킷의 단부의 지식을 이용하여, 패킷 전송 이전에 최소량의 시간을 상기 모뎀에게 대기할 것을 명하는 것을 특징으로 하는 모뎀.
제 18 항에 있어서, 상기 패킷 분석 모듈은 PPP 서브프로토콜과 다른 PPP 서브프로토콜을 감지하고, 상기 PPP 서브프로토콜은 LCP(링크 제어 프로토콜), PAP(패스워드 인증 프로토콜), CHAP(도전 신호 변경 인증 프로토콜), 그리고 NCP(네트워크 제어 프로토콜)을 포함하며, 상기 패킷 분석 모듈은 이 정보를 이용하여, 패킷 전송에 사용되는 잠재시간의 양을 결정하는 것을 특징으로 하는 모뎀.
제 19 항에 있어서, 상기 패킷 분석 모듈은 PPP 서브프로토콜 패킷의 명령 코드를 검사하고, 이 정보를 이용하여 패킷 전송에 사용되는 잠재시간의 양을 결정하는 것을 특징으로 하는 모뎀.
제 18 항에 있어서, 상기 패킷 분석 모듈은 IP 헤더의 서비스(TOS) 필드의 종류를 검사하여, 패킷 전송에 사용되는 잠재시간의 양을 결정하는 것을 특징으로 하는 모뎀.
제 21 항에 있어서, 상기 TOS 필드는 패킷에 요구되는 우선성과 신뢰성을 기술하는 것을 특징으로 하는 모뎀.
제 21 항에 있어서, 상기 TOS 필드에 설정가능한 성질은 지연 최소화, 시간당 처리량 최대화, 신뢰성 최대화, 그리고 비용 최소화를 포함하는 것을 특징으로 하는 모뎀.
제 23 항에 있어서, 한 개 이상의 상기 TOS 플랙은 한번에 설정가능한 것을 특징으로 하는 모뎀.
제 18 항에 있어서, 상기 패킷 분석 모듈은 지연 최소화 성질을 위해 TOS 플랙을 검사하고, 패킷의 즉각적 전송을 상기 모뎀에게 명령하기 위해 IP 패킷이 끝에 있을 때 상기 네트워크 스택은 최소화 지연 성질과 정보를 이용하는 것을 특징으로 하는 모뎀.
제 18 항에 있어서, 최적화는 IP 헤더 필드를 바탕으로 실행되는 것을 특징으로 하는 모뎀.
제 26 항에 있어서, 잠재시간 설정은 프로토콜 필드를 바탕으로 하는 것을 특징으로 하는 모뎀.
제 26 항에 있어서, UDP와 TCP에 운반되는 포트 정보가 모뎀 잠재시간 최적화를 위해 사용되는 것을 특징으로 하는 모뎀.
제 15 항에 있어서, 상기 모뎀은 잠재시간 표를 추가로 포함하는 것을 특징으로 하는 모뎀.
제 29 항에 있어서, 상기 잠재시간 표는 프로토콜 표, 포트 표, 그리고 그 이상의 데이터에 대한 패킷의 종료 이후에 대기할 시간의 표를 포함하는 것을 특징으로 하는 모뎀.
제 29 항에 있어서, TCP 스테이트와 IP 헤더로부터의 정보는 상기 패킷의 종료시에 상기 모뎀 프로토콜에 전송되기 위해 잠재시간 값을 찾는 데 사용되는 것을 특징으로 하는 모뎀.
제 29 항에 있어서, 상기 잠재시간 표는 패킷 특성에 의해 트리거링되는 다수의 입력을 가지는 스테이트 머신이고, 상기 잠재시간 표는 상기 입력으로부터 모뎀 프로토콜을 위한 최적화된 잠재시간값을 생성하며, 상기 모뎀이 전송될 때 각각의 패킷이 최적화되는 것을 특징으로 하는 모뎀.
제 29 항에 있어서, 상기 모뎀은 IP 잠재시간 리졸버를 추가로 포함하고, 상기 IP 잠재시간 리졸버는 IP 서브-프로토콜 잠재시간 표와 IP TOS 필드 잠재시간 표로부터 입력값을 취하며, 상기 IP 잠재시간 리졸버는 상기 두 값 중 낮은 값을 선택하는 것을 특징으로 하는 모뎀.
제 29 항에 있어서, 상기 모뎀은 TCP 잠재시간 리졸버를 추가로 포함하고, 상기 TCP 잠재시간 리졸버는 종착 포트 잠재시간 표와 TCP 스테이트 잠재시간 표로부터 입력 값을 취하며, 상기 TCP 잠재시간 리졸버는 상기 두 값 중 낮은 값을 선택하는 것을 특징으로 하는 모뎀.
제 29 항에 있어서, 상기 모뎀은 IP 잠재시간 리졸버와 TCP 잠재시간 리졸버를 추가로 포함하고,

상기 IP 잠재시간 리졸버는 IP 서브 프로토콜 잠재시간 표와 IP TOS 필드 잠재시간 표로부터 입력 값을 취하며, 상기 IP 잠재 기산 리졸버는 상기 두 값으로부터 낮은 값을 취하고,

상기 TCP 잠재시간 리졸버는 종착 포트 잠재시간 표와 TCP 스테이트 잠재시간 표로부터 입력 값을 취하며, 상기 TCP 잠재시간 리졸버는 상기 두 값 중 낮은 값을 선택하고,

상기 IP 잠재시간 리졸버와 상기 TCP 잠재시간 리졸버 출력은 먹스되어 조합된 잠재시간 표를 생성하고, 상기 먹스는 IP 헤더 내의 프로토콜 필드에 의해 제어되는 것을 특징으로 하는 모뎀.
제 29 항에 있어서, 잠재시간 세팅값은 PPP 잠재시간표에 의해 제공되고, 상기 값은 PPP 프로토콜 필드와 PPP 명령 코드 필드에 의해 결정되는 것을 특징으로 하는 모뎀.
제 36 항에 있어서, 상기 PPP 잠재시간 표값은 상기 IP 잠재시간 리졸버와 상기 TCP 잠재시간 리졸버의 먹스된 값으로 먹스되는 것을 특징으로 하는 모뎀.
제 15 항에 있어서, 상기 모뎀은 독립형으로 실현가능한 고집적 통신 장치를 포함하고, 상기 장치는 폭넓은 분야의 전자 장치를 인터넷 작동시키는 것을 특징으로 하는 모뎀.
제 15 항에 있어서, 상기 모뎀은 TCP 소켓 필터를 추가로 포함하고, 정해진 소켓 연결을 지향하는 상기 모뎀에 수신된 패킷만이 상기 모뎀을 통과할 수 있고, 모든 다른 패킷은 하드웨어 레벨에서 상기 소켓 필터에 의해 필터링 아웃되는 것을 특징으로 하는 모뎀.
제 15 항에 있어서, 상기 모뎀은 HTML 패킷 스니퍼를 추가로 포함하고, 상기 스니퍼는 수신된 HTML 데이터를 분석하는 것을 특징으로 하는 모뎀.
제 40 항에 있어서, 상기 HTML 패킷 스니퍼는 프리셋 레이팅을 추가로 포함하고, 상기 패킷이 수신된 패킷 버퍼에 위치하는 지를 결정하기 위해 상기 프리셋 레이팅이 패킷에 가해지는 것을 특징으로 하는 모뎀.
제 40 항에 있어서, 상기 HTML 패킷 스니퍼는 HTTP 리스판스 분석기를 추가로 포함하고, 상기 분석기는 소켓으로부터 수신된 패킷을 취하며, 상기 분석기는 HTTP 헤더를 해역하여, 그 데이터가 유효한 HTML 데이터를 포함하는 지를 결정하고, 만약 그렇다면, 상기 분석기는 HTML 레이팅 디코더를 작동시키고, 이는 레이팅 태그에 대한 상기 HTML 데이터를 분석하기 시작하는 것을 특징으로 하는 모뎀.
제 40 항에 있어서, 상기 HTML 패킷 스니퍼는 HTML 디코더를 추가로 포함하고, 상기 HTML 디코더는 수신 패킷 버퍼에 모든 수신 데이터를 기록하고, 상기 HTML 디코더는 이와 동시에 태그를 분석하며,

상기 HTML 디코더가 레이팅 태그를 감지하면, 상응하는 페이지 레이팅을 프리셋 레이팅 레벨에 비교하고,

상기 레이지가 통과되면, 상기 페이지는 수신 버퍼에 계속 저장되며,

상기 페이지가 통과하지 못하면, 모든 추가적인 데이터가 억제되고, 거절 메시지가 메모리에 저장되며, 그리고

상기 페이지가 상기 페이지 헤드에서 어떤 레이팅도 포함하지 않으면, 상기 모뎀은 페이지를 통과시키도록 배치되거나, 사용자 배치에 바탕하여 상기 페이지를 거절하는 것을 특징으로 하는 모뎀.
한 개의 모뎀으로서, 상기 모뎀은 모뎀 코어와 네트워크 스택을 포함하며, 상기 네트워크 스택은 네트워크 프로토콜을 실행하여, 상기 모뎀을 전자 네트워크 상에서 통신시키고, 상기 네트워크 스택은 인터넷 네트워크 프로토콜 스택을 포함하고, 상기 네트워크 스택은 데이터 블록을 송수신하며, 상기 네트워크 스택에 구현되는 네트워크 프로토콜은 PPP, IP, TCP, 그리고 UDP 통신 레이어에 의해 요구되는 프로토콜을 포함하고, 상기 네트워크 스택은 직접 메모리 액세스(DMA) 작동을 지원하여, 데이터 전송에 요구되는 CPU 오버헤드를 최적화하는 것을 특징으로 하는 방법.
한가지의 모뎀 생성 방법으로서, 상기 방법은:

모뎀 코어를 제공하고; 그리고

네트워크 스택을 구현하는; 두 단계로 구성되고, 상기 네트워크 스택은 네트워크 프로토콜을 실행하여, 전자 네트워크에서 상기 모뎀을 통신시키는 것을 특징으로 하는 모뎀.
제 45 항에 있어서, 상기 네트워크 스택은 인터넷 프로토콜 스택을 포함하고, 상기 네트워크 스택은 데이터 블록을 송수신하며, 상기 네트워크 스택에 구현되는 네트워크 프로토콜은 PPP, IP, TCP, 그리고 UDP 통신 레이어에 의해 요구되는 프로토콜을 포함하고, 상기 네트워크 스택은 직접 메모리 액세스(DMA) 작동을 지원하여, 데이터 전송에 요구되는 CPU 오버헤드를 최적화하는 것을 특징으로 하는 방법.
제 45 항에 있어서, 상기 방법은 PPP, IP, TCP 패킷 스누핑을 실행하는 단계를 추가로 포함하는 것을 특징으로 하는 방법.
제 45 항에 있어서, 패킷 전송에 사용되는 잠재시간의 양을 결정하기 위해 IP 헤더의 TOS 필드를 이용하는 단계를 추가로 포함하는 것을 특징으로 하는 방법.
제 45 항에 있어서, TCP 헤더를 확인함으로서 잠재시간 최적화를 실행하는 단계를 추가로 포함하는 것을 특징으로 하는 방법.
제 45 항에 있어서, 모든 프로토콜 협상은 상기 네트워크 스택에 의해 상기 모뎀에 국부적으로 유지되는 것을 특징으로 하는 방법.
제 45 항에 있어서, 설정된 소켓 연결이 이미 존재하지 않는다면, 상기 네트워크 스택이 수신 패킷을 무시하는 것을 특징으로 하는 방법.
제 45 항에 있어서, 상기 방법은 HTML 레이팅 태그를 디코딩하기 위해 패킷 스니퍼를 제공하는 단계를 추가로 포함하고, 상기 패킷 스니퍼는 프리셋 레이팅 레벨 내의 페이지만을 통과시키는 것을 특징으로 하는 방법.
제 52 항에 있어서, 상기 패킷 스니퍼는 레이팅 태그를 전혀 포함하지 않는 레이팅되지 않은 페이지를 통과시키지 않거나, 또는 상기 레이팅되지 않은 페이지를 통과시키는 것을 특징으로 하는 방법.
제 52 항에 있어서, 하드 와이어드 세팅을 통해서만 레이팅 레벨이 프로그래밍되는 것을 특징으로 하는 방법.
제 45 항에 있어서, 소프트웨어 장치는 소켓 API를 통해 상기 모뎀 코어와 상기 네트워크 스택과 통신하는 것을 특징으로 하는 방법.
네트워크 프로토콜과 데이터를 디코딩 및 인코딩하는 장치로서, 상기 장치는 네트워크 프로토콜 레이어 모듈, 데이터 핸들러 모듈, 메모리 제어 모듈, 그리고 작동 시스템(O.S.) 스테이트 머신 모듈로 구성되고, 상기 네트워크 프로토콜 레이어 모듈은 네트워크 패킷 바이트를 인코딩 및 디코딩하는 것을 특징으로 하는 장치.
제 56 항에 있어서, 상기 네트워크 프로토콜 레어어는 다른 네트워크 프로토콜을 나타내는 다수의 스테이트 머신을 포함하는 것을 특징으로 하는 장치.
제 57 항에 있어서, 상기 네트워크 프로토콜 레이어는 한 개 이상의 다음의 네트워크 프로토콜, 즉, 점-점 프로토콜(PPP), 인터넷웍 패킷(IP), 전송 제어 프로토콜(TCP), 로오 소켓, 그리고 사용자 데이터그램 프로토콜(UDP)을 구현하는 것을 특징으로 하는 장치.
제 57 항에 있어서, 상기 네트워크 패킷 바이트는 실시간으로 처리되는 것을 특징으로 하는 장치.
제 57 항에 있어서, 상기 네트워크 패킷 바이트는 동시에 처리되는 것을 특징으로 하는 장치.
제 57 항에 있어서, 상기 네트워크 패킷 바이트는 직렬 바이트 처리되는 것을 특징으로 하는 장치.
제 56 항에 있어서, 상기 네트워크 프로토콜 레이어는 하드웨어 게이트 레벨 회로인 것을 특징으로 하는 장치.
제 57 항에 있어서, 특정 스테이트 머신에 의해 한 번 이상 요구되는 데이터는 메모리 위치를 표시하는 포인터로 특정 메모리 위치에 자리잡는 것을 특징으로 하는 장치.
제 58 항에 있어서, 상기 데이터 핸들러는 특정 데이터 종류를 처리하는 한 개 이상의 스테이트 머신으로 구성되는 것을 특징으로 하는 장치.
제 64 항에 있어서, 상기 데이터 핸들러는 한 개 이상의 다음의 데이터 종류, 즉, 하이퍼텍스트 프로토콜(HTTP), 하이퍼텍스트 마크업 언어(HTML), 포스트 오피스 프로토콜(POP3), 인터넷 메시지 액세스 프로토콜(IMAP4), 간단한 메일 전송 프로토콜(SMTP), 조인트 사진 전문가 그룹(JPEG), 그래픽 인터체인지 포맷(GIF), 그리고 자바 언어를 처리하는 것을 특징으로 하는 장치.
제 64 항에 있어서, 상기 데이터 종류는 실시간으로 처리되는 것을 특징으로 하는 장치.
제 64 항에 있어서, 상기 데이터 종류는 동시에 처리되는 것을 특징으로 하는 장치.
제 64 항에 있어서, 상기 데이터 종류는 직렬 바이트로 처리되는 것을 특징으로 하는 장치.
제 64 항에 있어서, 상기 데이터 핸들러는 하드웨어 게이트 레벨 회로인 것을 특징으로 하는 장치.
제 64 항에 있어서, 상기 데이터 핸들러는 하이 레벨 읽기 전용 메모리(ROM) 프로그램인 것을 특징으로 하는 장치.
제 64 항에 있어서, 상기 스테이트 머신에 의해 공유되거나, 특정 스테이트 머신에 의해 한 번 이상 요구되는 데이터는 메모리 위치를 표시하는 포인터로 특정 메모리 위치에 위치하는 것을 특징으로 하는 장치.
제 64 항에 있어서, 상기 스테이트 머신에 의해 공유되는 데이터는 상기 스테이트 머신에 동시에 제공되는 것을 특징으로 하는 장치.
제 56 항에 있어서, 상기 메모리 제어 모듈은 모든 메모리 액세스를 조정하는 것을 특징으로 하는 장치.
제 56 항에 있어서, 상기 메모리 제어 모듈은 동일 메모리 영역에 시스템 및 비디오 메모리가 존재하게 하는 통합 메모리 구조(UMA)를 포함하는 것을 특징으로 하는 장치.
제 56 항에 있어서, 상기 메모리 제어 모듈은 다수의 아비터 로직 블록으로 구성되고, 여기서 아비터 블록은 두 장치 사이의 동적 회전 알고리즘에 따라 조정하는 것을 특징으로 하는 장치.
제 56 항에 있어서, 상기 메모리 제어 모듈은 다수의 아비터 로직 블록으로 구성되고, 상기 아비터 로직 블록은 주어진 아비터 트리 구조에 바탕한 메모리 액세스에 대해 각각의 장치에 고정된 웨이팅 우선권을 주는 방식으로 배열되는 것을 특징으로 하는 장치.
제 56 항에 있어서, 상기 O.S. 스테이트 머신은 상기 네트워크 레이어, 상기 데이터 핸들러, 그리고 리소스 제어 시스템 및 사용자 인터페이스에 대한 상기 메모리 제어 모듈 사이의 아비트레이터로 작용하는 것을 특징으로 하는 장치.
제 56 항에 있어서, 디스플레이 제어기를 추가로 포함하는 것을 특징으로 하는 장치.
제 78 항에 있어서, 상기 디스플레이 제어기는 한 개 이상의 디스플레이, 즉 VGA, TV, 액정 디스플레이(LCD), 또는 발광 다이오드(LED)를 제어하는 것을 특징으로 하는 장치.
제 78 항에 있어서, 상기 네트워크 레이어, 상기 데이터 핸들러, 상기 메모리 제어기, 상기 O.S. 스테이트 머신, 그리고 상기 디스플레이 제어기는 하드웨어 게이트 레벨 회로인 것을 특징으로 하는 장치.
제 56 항에 있어서, 상기 장치는 소비자용 인터넷 튜너로 작용하는 것을 특징으로 하는 장치.
네트워크 프로토콜 및 데이터를 디코딩 및 인코딩하기 위한 프로세스로서, 상기 프로세스는:

네트워크 패킷 바이트 인코딩 및 디코딩;

패킷 데이터 바이트 프로세싱;

메모리 액세스 제어; 그리고

스테이트 머신 순서 제어;의 단계로 구성되는 것을 특징으로 하는 프로세스.
제 79 항에 있어서, 상기 네트워크 패킷 바이트 인코딩 및 디코딩 단계는 다수의 스테이트 머신을 이용하여 다른 네트워크 프로토콜을 나타내는 단계를 추가로 포함하는 것을 특징으로 하는 프로세스.
제 83 항에 있어서, 상기 네트워크 패킷 바이트 인코딩 및 디코딩 단계는 한 개 이상의 네트워크 프로토콜, 즉 점-점 프로토콜(PPP), 인터넷웍 패킷(IP), 전송 제어 프로토콜(TCP), 로오 소켓, 그리고 다른 사용자 데이터그램 프로토콜(UDP)을 인코딩 및 디코딩하는 단계를 추가로 포함하는 것을 특징으로 하는 프로세스.
제 83 항에 있어서, 상기 네트워크 패킷 바이트 인코딩 및 디코딩 단계는 네트워크 패킷 바이트를 실시간으로 프로세싱하는 단계를 추가로 포함하는 것을 특징으로 하는 프로세스.
제 82 항에 있어서, 네트워크 패킷 바이트 인코딩 및 디코딩 단계는 네트워크 패킷 바이트를 동시에 프로세싱하는 단계를 추가로 포함하는 것을 특징으로 하는 프로세스.
제 82 항에 있어서, 상기 네트워크 패킷 바이트 인코딩 및 디코딩 단계는 네트워크 패킷 바이트를 직렬 바이트 방식으로 프로세싱하는 단계를 추가로 포함하는 것을 특징으로 하는 프로세스.
제 82 항에 있어서, 상기 네트워크 패킷 바이트 인코딩 및 디코딩 단계는 하드웨어 게이트 레벨 회로인 것을 특징으로 하는 프로세스.
제 82 항에 있어서, 상기 네트워크 패킷 데이터 바이트 프로세싱 단계는 한 개 이상의 스테이트 머신을 이용하여 특정 데이터 종류를 프로세싱하는 단계를 추가로 포함하는 것을 특징으로 하는 프로세스.
제 89 항에 있어서, 상기 패킷 데이터 바이트 프로세싱 단계는 데이터 필드 디코딩을 위해 CRC 알고리즘을 사용하는 단계를 추가로 포함하는 것을 특징으로 하는 프로세스.
제 89 항에 있어서, 상기 패킷 데이터 바이트 프로세싱 단계는 한 개 이상의 데이터 종류를 프로세싱하는 단계를 추가로 포함하고, 상기 한 개 이상의 데이터 종류란, 하이퍼텍스트 전송 프로토콜(HTTP), 하이퍼텍스트 마크업 언어(HTML), 포스트 오피스 프로토콜(POP3), 인터넷 메시지 액세스 프로토콜(IMAP4), 간단한 메일 전송 프로토콜(SMTP), 조인트 사진 전문가 그룹(JPEG), 그래픽 인터체인지 포맷(GIF), 또는 자바 언어임을 의미하는 것을 특징으로 하는 프로세스.
제 89 항에 있어서, 상기 패킷 데이터 바이트 프로세싱 단계는 패킷 데이터 바이트를 실시간으로 프로세싱하는 것을 특징으로 하는 프로세스.
제 89 항에 있어서, 상기 패킷 데이터 바이트 프로세싱 단계는 패킷 데이터 바이트를 동시에 프로세싱하는 단계를 추가로 포함하는 것을 특징으로 하는 프로세스.
제 89 항에 있어서, 상기 패킷 데이터 바이트 프로세싱 단계는 패킷 데이터 바이트를 직렬 바이트 방식으로 프로세싱하는 것을 특징으로 하는 프로세스.
제 89 항에 있어서, 상기 패킷 데이터 바이트 프로세싱 단계는 하드웨어 게이트 레벨 회로인 것을 특징으로 하는 프로세스.
제 89 항에 있어서, 상기 패킷 데이터 바이트 프로세싱 단계는 프로그램인 것을 특징으로 하는 프로세스.
상기 패킷 데이터 바이트 프로세싱 단계는 메모리 위치를 표시하는 포인터로 특정 메모리 위치에 상기 특정 스테이트 머신에 의해 한 번 이상 데이터를 위치시키는 단계를 추가로 포함하는 것을 특징으로 하는 프로세스.
제 82 항에 있어서, 상기 메모리 액세스 제어 단계는 모든 메모리 액세스를 조절하는 단계를 추가로 포함하는 것을 특징으로 하는 프로세스.
제 82 항에 있어서, 상기 메모리 액세스 제어 단계는 통합 메모리 구조(UMA)를 이용하여, 시스템 및 비디오 메모리를 동일 메모리에 위치시키는 단계를 추가로 포함하는 것을 특징으로 하는 프로세스.
제 82 항에 있어서, 상기 스테이트 머신 순서 제어 단계는 상기 네트워크 패킷 바이트 인코딩 및 디코딩 단계, 상기 패킷 데이터 바이트 프로세싱 단계, 그리고 리소스 제어, 시스템 및 사용자 인터페이스를 위한 상기 메모리 액세스 제어 단계 사이에서 조정하는 단계를 추가로 포함하는 것을 특징으로 하는 프로세스.
제 82 항에 있어서, 상기 스테이트 머신 순서 제어 단계는 상기 데이터 핸들러 모듈 및 상기 네트워크 프로토콜 레이어 모듈을 제어하는 용도로 시스템 및 사용자 입력을 해역하는 단계를 추가로 포함하는 것을 특징으로 하는 프로세스.
제 82 항에 있어서, 출력 데이터를 디스플레이하는 단계를 추가로 포함하는 것을 특징으로 하는 프로세스.
제 102 항에 있어서, 상기 출력 데이터 디스플레이 단계는 다음 종류의 디스플레이 중 하나를 제어하는 단계를 추가로 포함하고, 상기 디스플레이란, VGA, TV, 액정 디스플레이(LCD), 또는 발광 다이오드(LED)를 의미하는 것을 특징으로 하는 프로세스.
제 102 항에 있어서, 상기 프로세스는 하드웨어 게이트 레벨 회로인 것을 특징으로 하는 프로세스.
제 82 항에 있어서, 상기 프로세스는 소비자용 인터넷 튜너인 것을 특징으로 하는 프로세스.