KR100291021B1 - 광 가입자 분배망에서 호스트 디지털 터미널과 광 네트워크 유니트의 프로세서간 통신 프로토콜방법 - Google Patents

광 가입자 분배망에서 호스트 디지털 터미널과 광 네트워크 유니트의 프로세서간 통신 프로토콜방법 Download PDF

Info

Publication number
KR100291021B1
KR100291021B1 KR1019990005937A KR19990005937A KR100291021B1 KR 100291021 B1 KR100291021 B1 KR 100291021B1 KR 1019990005937 A KR1019990005937 A KR 1019990005937A KR 19990005937 A KR19990005937 A KR 19990005937A KR 100291021 B1 KR100291021 B1 KR 100291021B1
Authority
KR
South Korea
Prior art keywords
protocol data
data unit
protocol
unit
transmitting
Prior art date
Application number
KR1019990005937A
Other languages
English (en)
Other versions
KR20000056539A (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 윤종용
Priority to KR1019990005937A priority Critical patent/KR100291021B1/ko
Priority to CN00101137A priority patent/CN1264966A/zh
Publication of KR20000056539A publication Critical patent/KR20000056539A/ko
Application granted granted Critical
Publication of KR100291021B1 publication Critical patent/KR100291021B1/ko

Links

Classifications

    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B10/00—Transmission systems employing electromagnetic waves other than radio-waves, e.g. infrared, visible or ultraviolet light, or employing corpuscular radiation, e.g. quantum communication
    • H04B10/25—Arrangements specific to fibre transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • 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/26—Special purpose or proprietary protocols or architectures

Abstract

본 발명은 광 가입자 분배망에서 호스트 디지털 터미널과 광 네트워크 유니트의 프로세서간 통신을 위한 프로토콜방법에 관한 것으로, 간단한 메시지 처리 절차에 의해 메시지 처리 능력을 증가시킬 수 있는 프로세서간 통신 프로토콜방법을 제공함을 목적으로 한다. 이를 위해 본 발명은 호스트 디지털 터미널과 광 네트워크 유니트 중에 데이터 전송 요구가 있는 송신측이 상대방의 수신측으로 전송할 프로세서간 통신 메시지를 포함하는 데이터 프로토콜 데이터 유니트를 송신하면, 수신측은 데이터 프로토콜 데이터 유니트의 수신에 응답하는 긍정응답 프로토콜 데이터 유니트를 송신측으로 송신한다. 이때 송신측은 수신측으로부터 긍정응답 프로토콜 데이터 유니트를 수신하지 못하면 데이터 프로토콜 데이터 유니트를 재전송하고, 설정 횟수만큼 재전송한후에도 긍정응답 프로토콜 데이터 유니트를 수신하지 못하면 프로세스간 통신 페일로 처리한다. 이와 같이 간단한 메시지 처리 절차에 의해 메시지 처리 능력을 증가시킬 수 있다.

Description

광 가입자 분배망에서 호스트 디지털 터미널과 광 네트워크 유니트의 프로세서간 통신 프로토콜방법{INTERPROCESSOR COMMUNICATION METHOD BETWEEN HOST DIGITAL TERMINAL AND OPTICAL NETWORK UNIT IN OPTICAL LOCAL DISTRIBUTION LOOP)}
본 발명은 광 가입자 분배망에 관한 것으로, 특히 호스트 디지털 터미널과 광 네트워크 유니트의 프로세서간 통신을 위한 프로토콜(protocol)방법에 관한 것이다.
전화국과 가입자 단말 사이에 광 가입자 전달특성을 개선하기 위해 광 케이블이 도입되고, 전화국과 가입자 전화국과 가입자 단말 사이에 광 가입자 전송장치가 놓이게 됨으로써 전기적이 아닌 논리적인 루프가 형성되게 되었다. 이 루프를 광 가입자 루프라고 말한다. 이렇게 됨에 따라 전화국과 가입자 단말 사이는 단일 접속에서 다단 접속으로 바뀌게 되었고, 이로 인하여 형성된 망을 광 가입자망이라고 부르고 있다.
도 1은 통상적인 광 가입자망의 일예를 개략적으로 보인 블록구성도로서, CO(Central Office)(100)에 있는 호스트 디지털 터미널, 즉 HDT(Host Digital Terminal)(102)와 다수의 광 네트워크 유니트, 즉 ONU(Optical Network Unit)들(104-1∼104-n)이 광 파이버(optical fiber)로 제공되는 전송로들(106-1∼106-n) 각각을 통해 연결된다. 이와 같이 연결된 HDT(102)와 ONU들(104-1∼104-n)이 광 가입자 분배망을 이룬다. 이러한 광 가입자망 분배망은 예를 들어 James P. Dunn에 의해 발명되어 1996년 11월 12일자로 특허된 미합중국 특허번호 5,574,783호, Frank Klopfer 등에 의해 발명되어 1998년 8월 4일자로 특허된 미합중국 특허번호 5,790,171호 등에 개시되어 있다. 또한 1998년 3월 31일자로 발행된 한국통신학회지 제15권 제3호의 30∼31페이지와 그림 9, 대한민국 홍릉과학출판사에서 1996년 12월 27일자로 발행된 한국통신학회 정보통신 기술총서 '초고속 광통신 기술'의 458∼461페이지와 그림 17.10 등에 게재되어 있다. 이들에 따르면, HDT(102)는 도 1과 같이 광 가입자 분배망의 서빙 노드로서 CO(100)에 위치되거나 광역 광 가입자망인 경우에는 리모우트 노드(remote node)에 위치된다. 그리고 광 전송로들(106-1∼106-n)은 ONU들(104-1∼104-n)에서 각각 종단된다. ONU들(104-1∼104-n)은 광 가입자 접속장치 또는 광 종단장치로서, 각종 가입자 단말이 직접 접속되거나 또는 댁내망(CPN: Customer Premises Network)을 통하여 접속되거나 적당한 수의 가입자 및 트래픽을 수용하여 가입자와 동선 또는 동축 케이블로 연결된다.
한편 광 가입자 분배망에 있어서 HDT와 ONU간에는 프로세서간 통신, 즉 IPC(Interprocessor Communication)가 필요하다. 통상적으로 HDT와 ONU간의 IPC 프로토콜로서 TCP/IP(Transmission Control Protocol/Internet Protocol) 프로토콜을 채용하였었다. 그러나 HDT와 ONU간의 IPC는 단순한 기능만을 필요로 한다. 이러함에도 불구하고 복잡한 TCP/IP 프로토콜을 이용하게 되면 메시지 처리 속도면에서 그 성능이 떨어지게 된다.
상술한 바와 같이 HDT와 ONU간의 IPC 프로토콜로서 복잡한 TCP/IP 프로토콜을 이용하게 되면 메시지 처리 속도면에서 그 성능이 떨어지게 된다.
따라서 본 발명의 목적은 간단한 메시지 처리 절차에 의해 메시지 처리 능력을 증가시킬 수 있는 IPC 프로토콜방법을 제공함에 있다.
도 1은 통상적인 광 가입자망의 일예를 보인 블록구성도,
도 2는 본 발명의 실시예에 따른 호스트 디지털 터미널과 광 네트워크 유니트의 프로세서간 통신 프로토콜의 블록구성도,
도 3은 본 발명의 실시예에 따른 프로토콜 데이터 유니트 포맷도,
도 4a 내지 도 4c는 본 발명의 실시예에 따른 프로세서간 통신 프로토콜의 절차도,
도 5는 본 발명의 실시예에 따른 프로세서간 통신 프로토콜이 타스크로 구현된 동작 예시도,
도 6은 본 발명의 실시예에 따른 프로세서간 통신 프로토콜 구현 자료 구조도,
도 7은 본 발명의 실시예에 따른 도 5의 프로세서간 통신 프로토콜 타스크의 프로세서간 통신 커넥션 절차를 보인 흐름도,
도 8은 본 발명의 실시예에 따른 도 5의 프로세서간 통신 프로토콜 타스크의 프로세서간 통신 디스커넥션 절차를 보인 흐름도,
도 9는 본 발명의 실시예에 따른 도 5의 프로세서간 통신 프로토콜 타스크의 프로세서간 통신 메시지 송신 흐름도,
도 10은 본 발명의 실시예에 따른 도 5의 프로세서간 통신 프로토콜 타스크의 프로세서간 통신 메시지 수신 흐름도.
상술한 목적을 달성하기 위한 본 발명은 HDT와 ONU 중에 데이터 전송 요구가 있는 송신측이 상대방의 수신측으로 전송할 IPC 메시지를 포함하는 데이터 프로토콜 데이터 유니트를 송신하는 과정과, 수신측이 송신측으로부터 데이터 프로토콜 데이터 유니트를 수신하면 그에 응답하는 긍정응답 프로토콜 데이터 유니트를 송신하는 과정과, 송신측이 데이터 프로토콜 데이터 유니트를 송신한후 수신측으로부터 긍정응답 프로토콜 데이터 유니트를 수신하지 못하면 데이터 프로토콜 데이터 유니트를 재전송하는 과정과, 송신측이 데이터 프로토콜 데이터 유니트를 설정 횟수만큼 재전송한후에도 수신측으로부터 긍정응답 프로토콜 데이터 유니트를 수신하지 못하면 IPC 통신 페일(fail)로 처리하는 과정을 구비함을 특징으로 한다.
이하 본 발명의 바람직한 실시예를 첨부한 도면을 참조하여 상세히 설명한다. 하기 설명 및 첨부 도면에서 구체적인 메시지 포맷(message format)이나 크기와 같은 많은 특정 상세들이 본 발명의 보다 전반적인 이해를 제공하기 위해 나타나 있으나, 이들 특정 상세들은 본 발명의 설명을 위해 예시한 것으로, 본 발명이 그들에 한정됨을 의미하는 것은 아니다. 그리고 본 발명의 요지를 불필요하게 흐릴 수 있는 공지 기능 및 구성에 대한 상세한 설명은 생략한다. 그리고 하기 설명에서 도면들 중에 동일한 구성 요소들은 가능한한 어느 곳에서든지 동일한 부호들을 나타내고 있음에 유의해야 한다.
도 2는 본 발명의 실시예에 따른 IPC 프로토콜 블록도로서, IPCP(Interprocessor Communication Protocol) 서비스 인터페이스(200)와 IPC 프로토콜 코어(core)(202)와 MAC(Medium Access Control) 서비스 인터페이스(204)로 구성한다. 이와 같이 IPCP 서비스 인터페이스(200)와 IPC 프로토콜 코어(202)와 MAC 서비스 인터페이스(204)로 이루어지는 구조는 기본적으로 통상적인 경우와 동일하며, 전술한 도 1에 보인 HDT(102)와 ONU들(104-1∼104-n) 각각에 모두 동일하게 구현된다.
상기한 IPCP 서비스 인터페이스(200)는 IPC를 하고자하는 타스크와의 인터페이스를 한다. 이때 IPC 메시지의 형태로 인터페이스를 하며, 실질적으로 메시지를 송신하거나 수신하는 MAC 서비스 인터페이스(204)와 독립성을 갖는다. IPC 프로토콜 코어(202)는 실질적으로 IPC 프로토콜을 구현한 블록으로 IPCP 서비스 인터페이스(200)나 MAC 서비스 인터페이스(204)에서 받은 메시지들을 IPC 프로토콜을 적용할 수 있도록 가공한다. MAC 서비스 인터페이스(204)는 실질적으로 메시지를 전송하는 부분으로 IPC를 하고자하는 곳과의 연결 매체에 따라 해당 디바이스 드라이버(device driver)와 연결되어 IPC 프로토콜 코어(202)에서 가공된 IPC 메시지를 상대편으로 송신하거나 수신한다.
본 발명에 따라 실질적으로 IPC 프로토콜을 구현하는데 있어서 사용하는 메시지의 형태는 도 3에 보인 프로토콜 데이터 유니트, 즉 PDU(Protocol Data Unit)의 형태로 주고 받음으로써 이루어지는데, 모두 5가지의 PDU를 사용한다. 이들 5가지의 PDU는 데이터 PDU, 긴급(urgent)데이터 PDU, 긍정응답(Acknowledge: 이하 'ACK'라 함) PDU, 문의(hello) PDU, 문의 ACK PDU이다. 데이터 PDU는 IPC 메시지의 통상적인 전송에 사용된다. 긴급데이터 PDU는 긴급 IPC 메시지의 전송에 사용되는데, 예를 들어 프로그램을 다운로드(download)받는 목적으로 사용될 수 있다. ACK PDU는 데이터 PDU의 수신에 대해 응답하여 수신측에서 송신측으로 ACK 메시지의 전송에 사용된다. 문의 PDU는 송수신하는 데이터 PDU가 없는 경우 상대방의 정상동작 유무를 문의하는데 사용하며, 문의 ACK PDU는 문의 PDU의 수신에 대해 응답하여 수신측에서 송신측으로 ACK 메시지의 전송에 사용된다.
상기한 도 3에서 도 3(a)는 상기한 데이터 PDU의 포맷을 보인 것으로, PDU 타입 피일드(field)와 일련 번호(sequence number) 피일드와, 정보(information) 피일드로 이루어진다. 도 3(b)는 긴급데이터 PDU의 포맷을 보인 것으로, PDU 타입 피일드와 정보 피일드로 이루어진다. 도 3(c)는 ACK PDU와 문의 PDU와 문의 ACK PDU의 포맷을 보인 것으로, PDU 타입 피일드만으로 이루어진다. 상기한 피일드들중에 PDU 타입은 4옥텟(octet), 즉 4바이트로서 해당 PDU가 어떤 타입의 PDU인지를 알려주는 피일드로서, PDU 타입에 따라 PDU 타입 피일드에 할당되는 값의 예를 보이면 하기 표 1과 같다. 그리고 일련 번호 피일드도 4옥텟, 즉 4바이트로서 수신된 메시지가 다시 수신되는 경우 발생되는 오동작을 막기 위해 송신하는 PDU마다 각각 연속적 숫자를 붙여서 보내도록 하는 피일드이다. 정보 피일드는 6500옥텟, 즉 6500바이트로서 실질적으로 서비스 인터페이스쪽으로 송수신하는 실질적인 IPC 메시지가 들어가는 피일드이다.
PDU 타입 PDU 타입 피일드 값
데이터 PDU 0x01
긴급데이터 PDU 0x02
ACK PDU 0x03
문의 PDU 0x04
문의 ACK PDU 0x05
도 4a 내지 도 4c는 본 발명의 실시예에 따른 IPC 프로토콜의 절차도를 보인 것으로, 전술한 도 1의 HDT(102)와 ONU들(104-1∼104-n)간에 상기한 도 3에 보인 각각 PDU를 사용하여 IPC 통신을 하는 절차를 보인 것이다. 여기서 서브 네트워크들(300,302)중에 하나는 HDT(102)에 해당하고 다른 하나는 ONU들(104-1∼104-n)중 하나에 해당하는데, 상대적으로 송신측이 되거나 수신측이 되므로 혼동을 피하기 위해 편의상 '서브 네트워크'라 칭한다. 그리고 도 4a 내지 도 4c는 서브 네트워크들(300,302)중 서브 네트워크(300)가 송신측이 되고 서브 네트워크(302)가 수신측이 되는 예를 보인다.
상기한 도 4a는 서브 네트워크들(300,302)간에 본 발명에 따라 통상적인 IPC 메시지 전송을 하는 절차에 대한 예를 (400)∼(408)단계로 보인 것이다. 서브 네트워크들(300,302)중에 데이터 전송 요구가 있는 송신측인 서브 네트워크(300)가 (400)단계에서 상대방, 즉 수신측인 서브 네트워크(302)로 전송할 IPC 메시지를 포함하는 데이터 PDU를 송신한다. 이때 서브 네트워크(300)는 제1타이머(T100)를 시작시키고 널(null)상태에서 ACK 대기상태로 천이한다. 상기한 제1타이머(T100)는 예를 들어 1초로 셋팅한다. 수신측인 서브 네트워크(302)는 데이터 PDU의 수신에 응답하여 (402)단계에서 ACK PDU를 송신함으로써 데이터 PDU를 잘 수신하였음을 서브 네트워크(300)에 알린다. 이때 송신측인 서브 네트워크(300)는 데이터 PDU를 보낼때마다 데이터 PDU의 일련 번호를 1씩 증가시켜 보내고 데이터 PDU를 수신한 서브 네트워크(302)는 이전에 수신한 일련 번호를 유지한다. 이렇게 하여 서브 네트워크(302)는 상기한 (400)단계에서 데이터 PDU를 수신하면, 데이터 PDU의 일련 번호를 보고 이전에 수신된 데이터 PDU인지 여부를 확인한다. 만일 이전에 수신된 데이터 PDU와 같은 일련 번호를 가진 데이터 PDU가 수신되면 서브 네트워크(302)는 재수신된 것으로 판단하여 처리를 하지 않고, 일련 번호가 다르면 데이터 PDU에 포함된 IPC 메시지를 처리한다. 그리고 송신측인 서브 네트워크(300)는 한번에 하나의 데이터 PDU만을 보내며, ACK PDU가 오기 전까지 다른 데이터 PDU를 송신하지 않는다.
상기한 (402)단계에서 ACK PDU를 수신하면 서브 네트워크(300)는 종료하고 ACK 대기상태에서 널상태로 천이한다. 그리고 전송할 IPC 메시지가 더 있으면 상기한 (400)단계에서와 같이 (404)단계에서 다음의 데이터 PDU를 서브 네트워크(302)로 송신한다. 만일 서브 네트워크(300)가 (404)단계에서 데이터 PDU를 송신한후 제1타이머(T100)가 타임아웃(timeout)될때까지 서브 네트워크(302)로부터 ACK PDU를 수신하지 못하면 ACK 대기상태를 유지하며 (406)단계에서 데이터 PDU를 재전송하고 제1타이머(T100)를 다시 시작시킨다. 이와 같이 데이터 PDU를 재전송하는 경우 일련 번호는 증가시키지 않는다. 이후 또 제1타이머(T100)가 타임아웃될때까지 서브 네트워크(302)로부터 ACK PDU를 수신하지 못하면 서브 네트워크(300)는 (408)단계에서 데이터 PDU를 재전송하고 제1타이머(T100)를 다시 시작시킨다. 이렇게 하여 제1타이머(T100)의 타임아웃이 설정된 횟수, 예를들어 3회까지 발생하면 서브 네트워크(300)는 IPC 페일로 처리한다. 즉, 송신측이 데이터 PDU를 설정 횟수만큼 재전송한후에도 수신측으로부터 ACK PDU를 수신하지 못하면 IPC 페일로 처리하고 ACK 대기상태에서 IPC 페일상태로 천이한다.
상기한 도 4b는 서브 네트워크들(300,302)간에 긴급 IPC 메시지 전송을 하는 절차를 보인 것이다. 이때 서브 네트워크(300)는 (410)단계에서 IPC 메시지를 긴급데이터 PDU 형태로 송신하며, 널상태를 유지하고 ACK PDU의 수신은 대기하지 않는다. 그리고 서브 네트워크(302)는 상기한 (410)단계에서 긴급데이터 PDU를 수신한 경우에는 ACK PDU를 보내지 않고 긴급 IPC 메시지 처리만 한다.
상기한 도 4c는 서브 네트워크들(300,302)간에 문의 PDU를 전송하는 절차를 (412)∼(416)단계로 보인 것으로, 송수신하는 데이터 PDU가 없는 경우에는 널상태, ACK 대기상태, IPC 페일상태 등의 모든 상태에서 이루어진다. 서브 네트워크들(300,302)은 송수신하는 데이터 PDU가 없는 경우 IPC가 살아 있는지 주기적으로 확인하기 위하여 (412)∼(414)단계와 같이 제2타이머(T200)의 셋팅 시간, 예를 들어 10초마다 문의 PDU를 송신하고, 문의 PDU를 받은 수신측은 문의 ACK PDU를 전송하게 된다. 이경우 문의 PDU를 송신한 측에서 예를 들어 30초로 셋팅되는 제3타이머(T300)가 타임아웃될때까지 문의 ACK PDU를 받지 못하는 경우 IPC 페일 처리한다.
따라서 HDT(102)와 ONU들(104-1∼104-n)간에 상기한 도 3에 보인 PDU를 사용하여 필요한 메시지 처리 절차만을 간단하게 가지므로 복잡한 TCP/IP 프로토콜을 사용하는 경우에 비해 메시지 처리 능력을 증가시킬 수 있다.
도 5 내지 도 10은 상기한 바와 같은 본 발명의 구체적인 구현예를 보인 것이다. 먼저 도 5는 본 발명의 실시예에 따른 IPC 프로토콜이 타스크로 구현된 IPC의 동작을 보인 것으로, 본 발명의 실시예에 따른 IPC 프로토콜 타스크(500)와 타스크(510)와 AAL5(ATM Adaptation Layer 5) 디바이스 드라이버(512)와 LAN(Local Area Network) 디바이스 드라이버(516)간의 관련 구성을 보임과 아울러 IPC 프로토콜에 따른 동작을 (S1)∼(S8)단계로 보인 것이다. IPC 프로토콜 타스크(500)는 상기한 도 3과 도 4a 내지 도 4c에 보인 IPC 프로토콜을 위해 도 6과 같은 자료 구조를 구비하며 도 7 내지 도 10의 흐름도로서 보인 바와 같이 구현한다. 타스크(510)는 서브 네트워크들(300,302)내에서 IPC를 요구하는 각종 타스크들중 하나를 나타낸 것이다. AAL5 디바이스 드라이버(512)와 LAN 디바이스 드라이버(516)는 실제 IPC 메시지를 송수신하는 디바이스에 대한 디바이스 드라이버들로서, 서브 네트워크들(300,302)간의 연결 매체가 AAL5 디바이스(514)로 이루어질 경우에는 AAL5 디바이스 드라이버(512)가 사용되고, LAN 디바이스(518)로 이루어질 경우에는 LAN 디바이스 드라이버(516)가 사용된다. 그리고 타스크(510)에서 상대방 서브 네트워크로 송신할 IPC 메시지의 IPC 프로토콜 타스크(500)로 수신은 IPC 송신 큐(queue)(504)를 통해 이루어지고, IPC 프로토콜 타스크(500)에서 상대방 서브 네트워크로부터 수신한 IPC 메시지의 타스크(510)로의 송신은 분배(distribution) 큐(506)를 통해 이루어지며, AAL5 디바이스 드라이버(512) 또는 LAN 디바이스 드라이버(516)로부터 IPC 프로토콜 타스크(500)로의 PDU 수신은 IPC 수신 큐(508)를 통해 이루어진다. 그리고 타이머 모듈(502)에는 상기한 바와 같은 제1∼제3타이머(T100∼T300)가 설정되고 IPC 프로토콜 타스크(500)에 의해 시작/종료(start/cancel)된다.
먼저 타스크(510)에서 송신하고자 하는 IPC 메시지를 IPC 송신 큐(506)로 보내는 경우를 살펴본다. 이때 통상적인 경우와 같이 타스크(510)에서 메일박스(mailbox)를 보냄으로써 IPC 프로토콜 타스크(500)가 기동되고, IPC 프로토콜 타스크(500)는 IPC 송신 큐(504)와 IPC 수신 큐(508)를 모두 확인한다. 이때 타스크(510)로부터 보내진 IPC 메시지가 IPC 송신 큐(504)에 있게 되므로 IPC 프로토콜 타스크(500)는 (S1)단계에서 IPC 송신 큐(504)로부터 IPC 메시지를 수신하고, (S2)단계에서 IPC 메시지를 PDU 형태로 변환한다. 그리고 IPC 프로토콜 타스크(500)는 (S3)단계에서 IPC 메시지의 목적지에 따라 해당하는 AAL5 디바이스 드라이버(512) 또는 LAN 디바이스 드라이버(516)로 PDU를 보내고, (S4)단계에서 필요한 타이머를 타이머 모듈(502)에 등록하여 시작시킨다.
다음에 상대방 서브 네트워크로부터의 IPC 메시지를 수신하는 경우를 살펴본다. 이 경우 IPC 프로토콜 타스크(500)는 (S5)단계에서 AAL5 디바이스 드라이버(512) 또는 LAN 디바이스 드라이버(516)로부터 IPC 수신 큐(508)를 통해 PDU를 수신한다. 이때 통상적인 경우와 같이 AAL5 디바이스 드라이버(512) 또는 LAN 디바이스 드라이버(516)에서 메일박스를 보냄으로써 IPC 프로토콜 타스크(500)가 기동되고, IPC 프로토콜 타스크(500)는 IPC 송신 큐(504)와 IPC 수신 큐(508)를 모두 확인한다. 이때 IPC 수신 큐(508)에 IPC 메시지가 있게 되므로 IPC 프로토콜 타스크(500)는 (S5)단계에서 IPC 수신 큐(508)로부터 PDU를 수신하고, 수신된 PDU를 (S6)단계에서 상기한 도 4a 내지 도 4c와 같은 프로토콜에 따라 처리한다. 이때 상기한 (S4)단계에서 등록한 타이머를 (S7)단계에서 종료시키고, 수신된 PDU를 IPC 메시지 형태로 하여 (S8)단계에서 분배 큐(506)를 통해 타스크(510)로 보낸다.
도 6은 상기한 IPC 프로토콜 타스크(500)의 도 7 내지 도 10의 흐름도에 따른 절차 수행에 필요한 자료 구조를 보인 것으로, 상기한 도 2와 대응시켜 보면 도 6(a) 내지 도 6(c)는 도 2의 IPCP 서비스 인터페이스(200)에 구비되고, 도 6(d)는 도 2의 IPC 코어(202)에 구비되며, 도 6(e)와 도 6(f)는 도 2의 MAC 서비스 인터페이스(204)에 구비된다.
상기 도 6(a)는 링크 사용자 관리자(600)인 'linkUserManager[MAX_SUBNET]'를 보인 것으로, 링크 사용자 관리자(600)는 IPC를 하고자하는 서브 네트워크의 수만큼의 링크 사용자 엔티티(entity)를 가진다. 링크 사용자 엔티티는 커넥션(connection)이 될때 서브 네트워크당 1씩 할당된다. 도 6(b)는 링크 사용자 엔티티(602)인 'LinkUserEntity'를 보인 것이다. 링크 사용자 엔티티(602)의 커넥션 플래그 'connFlag'(connection flag)는 커넥션 여부를 검사하는데 사용되는 변수이다. 링크 사용자 'linkUser'는 도 6(c)에 보인 링크 사용자(604)를 가리키는 포인터이다. 도 6(c)는 링크 사용자(604)인 'LinkUser'를 보인 것으로, 'next'와 'prev'(previous)는 링크드 리스트(linked list) 형태 구현에 따른 정보이고, 'linkProvider'는 도 6(d)에 보인 링크 프로바이더(606)의 포인터이며, 'subnet'(subnetwork)은 커넥션된 서브 네트워크와 연결방법, 서브 네트워크를 구별할 수 있는 정보로 예를 들어 vpi(virtual path identifier)/vci(virtual path identifier) 등이 해당된다.
상기 도 6(d)는 링크 프로바이더(606)인 'LinkProvider'를 보인 것이다. 여기서 'next'와 'prev'는 링크드 리스트 형태 구현에 따른 정보이고, 'linkUser'는 연결 링크 사용자를 가리키는 포인터이다. 'ipcSapId'(IPC Service Access Point Identification)는 발생되는 이벤트에 따라 처리될 펑션(function)을 구분하고 연결된 커넥션을 구분하는 ID(Identification)이다. 'macProvider'(MAC provider)는 도 6(e)에 보인 MAC 프로바이더(608)를 가리키는 포인터이다. 'linkState'는 현재 커넥션의 상태를 나타낸다. 'waitingQ'(waiting queue)는 커넥션으로 PDU를 보낸후 ACK 대기상태에서 그 커넥션으로 보내려는 PDU가 있을 경우 버퍼링하기 위한 큐이다. 'txSeqNum'(transmit sequence number)는 데이터 PDU를 보내는 경우 일련 번호를 채우기 위해 이전에 보낸 일련 번호를 유지하는 변수로서, 데이터 PDU를 보낸후 1씩 증가된다. 'rxSeqNum'(receive sequence number)는 데이터 PDU를 받은 경우 수신된 데이터 PDU가 이전에 수신된 데이터 PDU인지를 판단하기 위해 이전에 수신된 데이터 PDU의 일련 번호를 유지하는 변수이다. 'retransmitCnt'(retransmit count)는 제1타이머(T100)가 타임아웃되어 재전송을 할 경우 재전송 IPC 페일 처리를 위해 재전송 횟수를 유지하는 변수이다. 'currentTxdata'(current transmit data)는 재전송시 이전에 보낸 데이터의 재전송을 위해 이전에 보낸 데이터를 버퍼링하기 위한 것이다.
상기 도 6(e)는 MAC 프로바이더(608)인 'MacProvider'을 보인 것으로, MAC 프로바이더(608)는 통신할 서브 네트워크와 연결되는 디바이스 드라이버를 관리한다. 이러한 MAC 프로바이더(608)는 AAL5 프로바이더, HDLC(High-level Data Link Control) 프로바이더 등 여러 형태를 가질 수 있다. 도 6(e)에서는 도 6(f)와 같이 AAL5 프로바이더인 예를 들었다. 도 6(f)는 MAC 프로바이더(608)가 2개의 AAL5 프로바이더(610,612) 'Aal5Provider'(AAL5 provider)를 가지는 경우를 보인 것이다. 'next'와 'prev'는 링크드 리스트 형태 구현에 따른 정보이고, 'subnetType'는 커넥션된 서브 네트워크와의 연결방법, 즉 디바이스 드라이버를 결정한다. 'macUser'는 연결 링크 프로바이더(606)의 포인터이다. 'macSapId'(MAC Service Access Point Identification)는 발생되는 이벤트에 따라 처리될 펑션을 구별하는 ID이다. 'subnet'은 서브 네트워크를 구별할 수 있는 정보로서, 결정된 디바이스 드라이버의 해당 서브 네트워크로 연결되는 경로(path)의 ID이다. 예를 들어 AAL5인 경우라면 vpi/vci 등이다. 'Aal5SapId'(AAL5 Service Access Point Identification)는 특정 vpi/vci로부터 받은 AAL5를 AAL5 프로바이더들(610,612)중에 어떤 AAL5 프로바이더로 넘겨줄 것인지를 의미하는 AAL5 프로바이더 구별 ID이다.
이제 상기한 도 6과 같은 자료 구조를 가지는 IPC 프로토콜 타스크(500)의 동작에 따른 절차를 도 7 내지 도 10을 함께 참조하여 설명한다. 먼저 IPC 커넥션을 요구하는 절차를 (700)∼(716)단계로 보인 도 7을 참조하면, IPC 프로토콜 타스크(500)는 (700)단계에서 도 5의 (S1)단계와 같이 특정한 서브 네트워크에 IPC 커넥션을 요구하는 메시지를 수신하여 커넥션 연결을 확인한다. 이때 커넥션 요구된 서브 네트워크가 도 6(a)의 링크 사용자 관리자(600)내에 존재하는지 여부를 (702)단계에서 검사한다. 만일 존재하지 않는다면 (704)단계에서 IPC 불가 에러 처리한다. 이와 달리 존재하면 (706)단계에서 도 6(b)의 링크 사용자 엔티티(602)의 커넥션 플래그 connFlag가 액티브인지를 검사한다. 만일 커넥션 플래그 connFlag가 액티브이면 기존에 커넥션이 연결되어 있는 상태이므로 (716)단계에서 커넥션을 완료한다. 이와 달리 커넥션 플래그 connFlag가 액티브가 아니면 (708)단계에서 도 6(b)의 링크 사용자 엔티티(602)의 커넥션 플래그 connFlag를 액티브시키고, 도 6(c)의 링크 사용자(604)를 생성 및 초기화하며, IPC 메시지의 커넥션을 요구하며, IPC 요구 서브 네트워크를 보고 도 6(c)의 링크 사용자(604)의 내용을 변경한다. 그리고 (710)단계에서 도 6(d)의 링크 프로바이더(606)를 생성 및 초기화한후, (712)단계에서 서브 네트워크에 따라 MAC 프로바이더(608)를 생성할 형태를 결정한다. 이후 (714)단계에서 서브 네트워크와 연결되는 방법, 즉 디바이스 드라이버의 형태에 따라 디바이스 프로바이더를 생성 및 초기화하고 제2,제3타이머(T200, T300)를 시작한후 (716)단계에서 커넥션을 완료한다. 이때 AAL5인 경우 도 6(f)의 AAL5 프로바이더(610,612)를 생성 및 초기화한다.
다음에 IPC 디스커넥션(disconnection)을 요구하는 절차를 (800)∼(814)단계로 보인 도 8을 참조하면, IPC 프로토콜 타스크(500)는 (800)단계에서 도 5의 (S1)단계와 같이 IPC 디스커넥션을 요구하는 메시지를 수신하여 커넥션 연결을 확인한다. 이때 디스커넥션 요구된 서브 네트워크가 도 6(a)의 링크 사용자 관리자(600)내에 존재하는지 여부를 (802)단계에서 검사한다. 만일 존재하지 않는다면 (804)단계에서 에러 처리한다. 이와 달리 존재하면 (806)단계에서 도 6(b)의 링크 사용자 엔티티(602)의 커넥션 플래그 connFlag가 액티브인지를 검사한다. 만일 커넥션 플래그 connFlag가 액티브가 아니면 기존에 커넥션이 존재하지 않는 상태이므로 (814)단계에서 디스커넥션을 완료한다. 이와 달리 커넥션 플래그 connFlag가 액티브이면 (808)단계에서 도 6(b)의 링크 사용자 엔티티(602)의 링크 사용자 정보 linkUser로부터 도 6(c)의 링크 사용자(604)를 찾고, 다시 링크 사용자(604)의 링크 프로바이더 정보 linkProvider로부터 도 6(d)의 링크 프로바이더(606)를 찾고, 링크 프로바이더(606)의 MAC 프로바이더 정보 macProvider를 찾아 디바이스 프로바이더인 도 6(f)의 AAL5 프로바이더(610)를 삭제한 다음에, AAL5 프로바이더(610)의 MAC 사용자 정보 macUser를 이용해 도 6(d)의 링크 프로바이더(606)를 찾아간다. 다음에 (810)단계에서 제2타이머(T200)를 종료시키고 도 6(d)의 링크 프로바이더(606)를 삭제하고 링크 프로바이더(606)의 링크 사용자 정보 linkUser를 이용해 6(b)의 링크 사용자 엔티티(602)를 찾아간다. 이후 (812)단계에서 링크 사용자 엔티티(602)의 커넥션 플래그 connFlag를 넌액티브(nonactive)시키고 링크 사용자 정보 linkUser를 통해 링크 사용자(604)를 삭제하고 (814)단계에서 디스커넥션을 완료한다.
다음에 IPC 메시지를 송신하는 절차를 (900)∼(918)단계로 보인 도 9를 참조하면, IPC 프로토콜 타스크(500)는 (900)단계에서 도 5의 (S1)단계와 같이 IPC 전송을 요구하는 메시지를 수신하여 커넥션 연결을 확인한다. 이때 IPC 메시지 전송 요구된 서브 네트워크가 도 6(a)의 링크 사용자 관리자(600)내에 존재하는지 여부를 (902)단계에서 검사한다. 만일 존재하지 않는다면 (904)단계에서 IPC 불가 에러 처리한다. 이와 달리 존재하면 (906)단계에서 도 6(b)의 링크 사용자 엔티티(602)의 커넥션 플래그 connFlag가 액티브인지를 검사한다. 만일 커넥션 플래그 connFlag가 액티브가 아니면 커넥션이 연결되어 있지 않는 상태이므로 (908)단계에서 에러 처리한다. 이와 달리 커넥션 플래그 connFlag가 액티브이면 (910)단계에서 IPC 메시지의 목적지를 보고 도 6(c)의 링크 사용자(604)의 내용을 삽입한후, 해당 메시지의 내용과 서브 네트워크, 링크 사용자(604)의 링크 프로바이더 정보 linkProvider를 넘겨준다. 그리고 (912)단계에서 IPC 메시지를 데이터 PDU의 형태로 만들고 도 6(d)의 링크 프로바이더(606)의 내용을 프로토콜에 적용하여 변경후, 링크 프로바이더(606)의 MAC 프로바이더 정보 macProvider의 주소, 서브 네트워크, 데이터 PDU를 넘겨준다. 다음에 (914)단계에서 서브 네트워크에 따라 데이터 PDU를 어떤 형태의 프로바이더를 사용할 것인지를 결정하고, (916)단계에서 해당 서브 네트워크와 연결되는 디바이스 드라이버의 형태에 따라 AAL5 디바이스 드라이버(512)와 LAN 디바이스 드라이버(516) 중에 해당하는 디바이스 드라이버로 PDU를 전송하고, 제1타이머(T100)를 시작한후 (918)단계에서 종료한다.
마지막으로 IPC 메시지를 수신한 경우 처리되는 절차를 (1000)∼(1018)단계로 보인 도 10을 참조하면, IPC 프로토콜 타스크(500)는 (1000)단계에서 도 5의 (S5)와 같이 AAL5 디바이스 드라이버(512)와 LAN 디바이스 드라이버(516) 중에 해당하는 디바이스 드라이버로부터 PDU를 수신하여 서브 네트워크 타입 정보 subnetType와 SapId를 가지고 도 6(e)의 어떤 형태인지를 구별후 도 6(f)의 AAL5 프로바이더(610,612)의 AAL5 SAP ID 정보 Aal5SapId를 서치하여 (1002)단계에서 해당 커넥션이 존재하는지 검사한다. 만일 존재하지 않는다면 (1004)단계에서 에러 처리한다. 이와 달리 존재하면 (1006)단계에서 AAL5 프로바이더의 주소와 함께 수신된 PDU를 보낸다. 그리고 (1008)단계에서 수신된 PDU의 내용을 분석해 일련 번호를 확인하여 도 6(d)의 수신 일련 번호 rxSeqNum과 비교하여 이전과 동일한지를 검사한다. 만일 동일하면 기존에 수신된 IPC 메시지이므로 수신된 PDU를 (1010)단계에서 버린다. 이와달리 동일하지 않으면 (1012)단계에서 수신된 PDU가 ACK PDU인지를 검사하여 ACK PDU이면 (1014)단계에서 제1타이머(T100)를 종료한다. 만일 ACK PDU가 아니면 (1016)단계에서 ACK PDU를 전송하고 도 6(d)의 링크 프로바이더(606)의 내용을 변경, 즉 수신 일련 번호 rxSeqNum의 갱신, 링크 상태 정보 linkState 등을 변경한후 분배 큐(506)로 전송하고 (1018)단계에서 종료한다.
상기한 도 5 내지 도 10을 참조하여 살펴본 바와 같이, 상기한 도 4a 내지 도 4c에 보인 본 발명의 IPC 프로토콜은 IPC 메시지 송신과 수신이 한개의 타스크(500)로 관리되어 이루어지며, 그에 따라 도 2에 보인 IPCP 서비스 인터페이스(200)와 IPC 프로토콜 코어(202)와 MAC 서비스 인터페이스(204)가 모듈별로 독립성을 가지므로 다른 어떠한 형태의 IPC 메시지도 처리할 수 있게 된다. 아울러 연결 매체에 따라 디바이스 드라이버의 구현만으로도 용이하게 접속시킬 수 있는 융통성을 구비한다.
한편 상술한 본 발명의 설명에서는 구체적인 실시예에 관해 설명하였으나, 여러가지 변형이 본 발명의 범위에서 벗어나지 않고 실시할 수 있다. 특히 본 발명의 실시예에서는 IPC 메시지의 통상적인 전송과 긴급 IPC 메시지 전송과 아울러 주기적으로 문의하는 사항을 모두 포함하여 보였으나, 실제 적용하는 경우에는 필요에 따라 선택적으로 적용할 수 있다. 따라서 발명의 범위는 설명된 실시예에 의하여 정할 것이 아니고 특허청구범위와 특허청구범위의 균등한 것에 의해 정하여져야 한다
상술한 바와 같이 본 발명은 HDT와 ONU간에 복잡한 TCP/IP 프로토콜을 사용치 않고 간단한 메시지 처리 절차에 의해 IPC를 실현함으로써 메시지 처리 능력을 증대시킬 수 있는 잇점이 있다.

Claims (10)

  1. 호스트 디지털 터미널과 그에 연결되는 다수의 광 네트워크 유니트를 구비하는 광 가입자 분배망에서 상기 호스트 디지털 터미널과 상기 광 네트워크 유니트의 프로세서간 통신 프로토콜방법에 있어서,
    상기 호스트 디지털 터미널과 상기 광 네트워크 유니트 중에 데이터 전송 요구가 있는 송신측이 상대방의 수신측으로 전송할 프로세서간 통신 메시지를 포함하는 데이터 프로토콜 데이터 유니트를 송신하는 과정과,
    상기 수신측이 상기 송신측으로부터 상기 데이터 프로토콜 데이터 유니트를 수신하면 그에 응답하는 긍정응답 프로토콜 데이터 유니트를 송신하는 과정과,
    상기 송신측이 상기 데이터 프로토콜 데이터 유니트를 송신한후 상기 수신측으로부터 상기 긍정응답 프로토콜 데이터 유니트를 수신하지 못하면 상기 데이터 프로토콜 데이터 유니트를 재전송하는 과정과,
    상기 송신측이 상기 데이터 프로토콜 데이터 유니트를 설정 횟수만큼 재전송한후에도 상기 수신측으로부터 상기 긍정응답 프로토콜 데이터 유니트를 수신하지 못하면 프로세스간 통신 페일로 처리하는 과정을 구비함을 특징으로 하는 프로세서간 통신 프로토콜방법.
  2. 제1항에 있어서, 상기 데이터 프로토콜 데이터 유니트가,
    상기 데이터 프로토콜 데이터 유니트임을 나타내는 프로토콜 데이터 유니트 타입 피일드와,
    상기 프로세간 통신 메시지에 따라 연속적으로 송신되는 데이터 프로토콜 데이터 유니트에 순차적으로 부여되는 일련 번호가 할당되는 일련 번호 피일드와,
    상기 프로세스간 통신 메시지의 데이터가 할당되는 정보 피일드로 이루어짐을 특징으로 하는 프로세서간 통신 프로토콜방법.
  3. 제2항에 있어서, 상기 긍정응답 프로토콜 데이터 유니트가, 상기 긍정응답 프로토콜 데이터 유니트임을 나타내는 프로토콜 데이터 유니트 타입 피일드만으로 이루어짐을 특징으로 하는 프로세서간 통신 프로토콜방법.
  4. 제1항에 있어서,
    상기 호스트 디지털 터미널과 상기 광 네트워크 유니트 중에 긴급데이터 전송 요구가 있는 송신측이 상대방의 수신측으로 전송할 프로세서간 통신 메시지를 포함하는 긴급데이터 프로토콜 데이터 유니트를 송신하는 과정과,
    상기 수신측이 상기 송신측으로부터 상기 긴급데이터 프로토콜 데이터 유니트를 수신하여 처리하는 과정을 더 구비함을 특징으로 하는 프로세서간 통신 프로토콜방법.
  5. 제4항에 있어서, 상기 데이터 프로토콜 데이터 유니트가,
    상기 데이터 프로토콜 데이터 유니트임을 나타내는 프로토콜 데이터 유니트 타입 피일드와,
    상기 프로세간 통신 메시지에 따라 연속적으로 송신되는 데이터 프로토콜 데이터 유니트에 순차적으로 부여되는 일련 번호가 할당되는 일련 번호 피일드와,
    상기 프로세스간 통신 메시지의 데이터가 할당되는 정보 피일드로 이루어짐을 특징으로 하는 프로세서간 통신 프로토콜방법.
  6. 제5항에 있어서, 상기 긴급데이터 프로토콜 데이터 유니트가,
    상기 긴급데이터 프로토콜 데이터 유니트임을 나타내는 프로토콜 데이터 유니트 타입 피일드와,
    상기 프로세스간 통신 메시지의 데이터가 할당되는 정보 피일드로 이루어짐을 특징으로 하는 프로세서간 통신 프로토콜방법.
  7. 제6항에 있어서, 상기 긍정응답 프로토콜 데이터 유니트가, 상기 긍정응답 프로토콜 데이터 유니트임을 나타내는 프로토콜 데이터 유니트 타입 피일드만으로 이루어짐을 특징으로 하는 프로세서간 통신 프로토콜방법.
  8. 호스트 디지털 터미널과 그에 연결되는 다수의 광 네트워크 유니트를 구비하는 광 가입자 분배망에서 상기 호스트 디지털 터미널과 상기 광 네트워크 유니트의 프로세서간 통신 프로토콜방법에 있어서,
    상기 호스트 디지털 터미널과 상기 광 네트워크 유니트 중에 데이터 전송 요구가 있는 송신측이 상대방의 수신측으로 전송할 프로세서간 통신 메시지를 포함하는 데이터 프로토콜 데이터 유니트를 송신하는 과정과,
    상기 수신측이 상기 송신측으로부터 상기 데이터 프로토콜 데이터 유니트를 수신하면 그에 응답하는 긍정응답 프로토콜 데이터 유니트를 송신하는 과정과,
    상기 송신측이 상기 데이터 프로토콜 데이터 유니트를 송신한후 상기 수신측으로부터 상기 긍정응답 프로토콜 데이터 유니트를 수신하지 못하면 상기 데이터 프로토콜 데이터 유니트를 재전송하는 과정과,
    상기 송신측이 상기 데이터 프로토콜 데이터 유니트를 설정 횟수만큼 재전송한후에도 상기 수신측으로부터 상기 긍정응답 프로토콜 데이터 유니트를 수신하지 못하면 프로세스간 통신 페일로 처리하는 과정과,
    상기 호스트 디지털 터미널과 상기 광 네트워크 유니트가 송수신하는 상기 데이터 PDU가 없는 경우 일정 시간간격마다 상대방으로 문의 프로토콜 데이터 유니트를 송신하는 과정과,
    상기 문의 프로토콜 데이터 유니트를 수신한 측은 상기 문의 프로토콜 데이터 유니트가 수신될때마다 그에 응답하여 문의 긍정응답 프로토콜 데이터 유니트를 전송하는 과정과,
    상기 문의 프로토콜 데이터 유니트를 송신한 측은 상기 문의 긍정응답 프로토콜 데이터 유니트가 설정된 시간내에 수신되지 않으면 상기 프로세스간 통신 페일로 처리하는 과정을 구비함을 특징으로 하는 프로세서간 통신 프로토콜방법.
  9. 제8항에 있어서, 상기 데이터 프로토콜 데이터 유니트가,
    상기 데이터 프로토콜 데이터 유니트임을 나타내는 프로토콜 데이터 유니트 타입 피일드와,
    상기 프로세간 통신 메시지에 따라 연속적으로 송신되는 데이터 프로토콜 데이터 유니트에 순차적으로 부여되는 일련 번호가 할당되는 일련 번호 피일드와,
    상기 프로세스간 통신 메시지의 데이터가 할당되는 정보 피일드로 이루어짐을 특징으로 하는 프로세서간 통신 프로토콜방법.
  10. 제9항에 있어서, 상기 긍정응답 프로토콜 데이터 유니트와 상기 문의 프로토콜 데이터 유니트와 상기 문의 긍정응답 프로토콜 데이터 유니트가, 각각 상기 긍정응답 프로토콜 데이터 유니트와 상기 문의 프로토콜 데이터 유니트와 상기 문의 긍정응답 프로토콜 데이터 유니트임을 나타내는 프로토콜 데이터 유니트 타입 피일드만으로 이루어짐을 특징으로 하는 프로세서간 통신 프로토콜방법.
KR1019990005937A 1999-02-23 1999-02-23 광 가입자 분배망에서 호스트 디지털 터미널과 광 네트워크 유니트의 프로세서간 통신 프로토콜방법 KR100291021B1 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
KR1019990005937A KR100291021B1 (ko) 1999-02-23 1999-02-23 광 가입자 분배망에서 호스트 디지털 터미널과 광 네트워크 유니트의 프로세서간 통신 프로토콜방법
CN00101137A CN1264966A (zh) 1999-02-23 2000-01-20 光通信用户网中在主数字终端和光网络单元之间建立处理器间通信协议的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1019990005937A KR100291021B1 (ko) 1999-02-23 1999-02-23 광 가입자 분배망에서 호스트 디지털 터미널과 광 네트워크 유니트의 프로세서간 통신 프로토콜방법

Publications (2)

Publication Number Publication Date
KR20000056539A KR20000056539A (ko) 2000-09-15
KR100291021B1 true KR100291021B1 (ko) 2001-05-15

Family

ID=19574837

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1019990005937A KR100291021B1 (ko) 1999-02-23 1999-02-23 광 가입자 분배망에서 호스트 디지털 터미널과 광 네트워크 유니트의 프로세서간 통신 프로토콜방법

Country Status (2)

Country Link
KR (1) KR100291021B1 (ko)
CN (1) CN1264966A (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103369497B (zh) * 2012-03-27 2018-11-30 中兴通讯股份有限公司 触发消息计数器的更新方法、机器类型通信服务器和终端

Also Published As

Publication number Publication date
KR20000056539A (ko) 2000-09-15
CN1264966A (zh) 2000-08-30

Similar Documents

Publication Publication Date Title
JP4396639B2 (ja) 路車間通信システム、基地局装置、及び移動局装置
US5539734A (en) Method of maintaining PVC status packetized communication system
US6370592B1 (en) Network interface device which allows peripherals to utilize network transport services
KR100776084B1 (ko) 티씨피/아이피 프로토콜 계층 2에서 리라이어블 서비스제공장치 및 그 방법
KR100291021B1 (ko) 광 가입자 분배망에서 호스트 디지털 터미널과 광 네트워크 유니트의 프로세서간 통신 프로토콜방법
Cisco X.25 Record Boundary Preservation for Data Communications Networks
Cisco X.25 Configuration and Management
Cisco X.25 Configuration and Management
Cisco X.25 Configuration and Management
Cisco X.25 Configuration and Management
Cisco X.25 Configuration and Management
Cisco X.25 Configuration and Management
Cisco X.25 Configuration and Management
Cisco X.25 Configuration and Management
Cisco X.25 Configuration and Management
Cisco X.25 Configuration and Management
Cisco X.25 Configuration and Management
Cisco X.25 Configuration and Management
Cisco X.25 Configuration and Management
Cisco X.25 Enhancements
Cisco X.25 Configuration and Management
Cisco X.25 Configuration and Management
Cisco X.25 Configuration and Management
Cisco X.25 Configuration and Management
Cisco X.25 Enhancements

Legal Events

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

Payment date: 20090226

Year of fee payment: 9

LAPS Lapse due to unpaid annual fee