KR100302329B1 - Method for serial communication between simple electronic switch and personal computer - Google Patents
Method for serial communication between simple electronic switch and personal computer Download PDFInfo
- Publication number
- KR100302329B1 KR100302329B1 KR1019990036009A KR19990036009A KR100302329B1 KR 100302329 B1 KR100302329 B1 KR 100302329B1 KR 1019990036009 A KR1019990036009 A KR 1019990036009A KR 19990036009 A KR19990036009 A KR 19990036009A KR 100302329 B1 KR100302329 B1 KR 100302329B1
- Authority
- KR
- South Korea
- Prior art keywords
- data
- protocol
- sender
- flag
- packet
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 38
- 238000004891 communication Methods 0.000 title claims abstract description 32
- 230000005540 biological transmission Effects 0.000 claims abstract description 43
- 238000012360 testing method Methods 0.000 claims abstract description 11
- 238000012545 processing Methods 0.000 claims description 11
- 230000008859 change Effects 0.000 claims description 6
- 230000008569 process Effects 0.000 claims description 4
- 238000010586 diagram Methods 0.000 description 4
- 230000004044 response Effects 0.000 description 4
- 230000008901 benefit Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 238000010998 test method Methods 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/12—Arrangements for remote connection or disconnection of substations or of equipment thereof
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/38—Information transfer, e.g. on bus
- G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
- G06F13/4282—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40052—High-speed IEEE 1394 serial bus
- H04L12/40071—Packet processing; Packet format
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Multimedia (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
본 발명은 간이 전자교환기와 PC 간의 직렬 통신 방법을 제공하기 위한 것으로, 이러한 본 발명은 간이 전자 교환기에서 PC와 직렬통신을 할 때, 프로토콜의 시작 플래그와 끝 플래그는 한 패킷의 시작과 끝을 구분하고 LRC는 패킷 내부의 데이터 전송 오류를 검출하게 하고, 데이터의 길이는 길이 필드에서 정의하여 그 다음에 오는 데이터의 길이를 판단할 수 있게 해 주며, 플래그 필드 내의 PCS 는 그 다음에 오는 P-Type에서 정의된 프로토콜이 보조 프로토콜인지 상위 레벨의 응용 프로토콜인지를 판단할 수 있게 해주고, P-Type은 상위 레벨 프로토콜의 종류를 판별하게 해 주도록 하는 SCBP 프로토콜을 사용하여 패킷화되지 않은 일반 데이터와 패킷화된 데이터를 구분하여 송신하고 수신하는 단계와; 에코 테스트와 체크 얼라이브와 라운드 트립 타임을 갖는 보조 프로토콜에 의해 에코 테스트와 체크 얼라이브와 라운드 트립 타임을 수행하는 단계를 수행함으로서, 직렬 통신을 할 때 패킷화된 데이터와 일반 데이터의 혼재시 구분 송수신 문제를 해결하고, 효율적인 데이터의 전송을 위해 부가기능을 분리된 프로토콜로 설정함으로써, 상위 레벨에 안정성과 효율성을 제공할 수 있게 되는 것이다.The present invention is to provide a serial communication method between a simple electronic switch and a PC. When the serial communication with the PC in the simple electronic exchange, the present invention, the start flag and the end flag of the protocol distinguish the start and end of one packet. LRC detects a data transmission error in the packet, the length of the data is defined in the length field to determine the length of the data that follows, and the PCS in the flag field follows the P-Type. It is possible to determine whether the protocol defined in the sub-protocol or higher-level application protocol is defined, and the P-Type can be used to determine the type of higher-level protocol. Separating and transmitting the received data; Echo test and check-alive and round trip time are performed by the secondary protocol with echo test and check-alive and round trip time. In order to solve this problem, and to set up additional functions as separate protocols for efficient data transmission, it is possible to provide stability and efficiency at a higher level.
Description
본 발명은 간이 전자교환기와 PC 간의 직렬 통신 방법에 관한 것으로, 특히 직렬 통신을 할 때 패킷화된 데이터와 일반 데이터(Raw Data)의 혼재시 구분 송수신 문제를 해결하고, 효율적인 데이터의 전송을 위해 부가기능을 분리된 프로토콜로 설정함으로써, 상위 레벨에 안정성과 효율성을 제공하기에 적당하도록 한 간이 전자교환기와 PC 간의 직렬 통신 방법에 관한 것이다.The present invention relates to a serial communication method between a simple electronic exchange and a personal computer. In particular, the serial communication method solves the problem of distinguishing transmission / reception when mixing packetized data and raw data, and adding data for efficient data transmission. By setting the functionality as a separate protocol, it relates to a serial communication method between a simple electronic exchange and a PC that is suitable for providing stability and efficiency at a higher level.
일반적으로 SLIP(Serial Line IP)나 PPP(Point-to-Point Protocol)는 기본적으로 직렬통신 상에서 IP(Internet Protocol) 데이터그램(Datagram)을 전송하기 위해서 고안된 프로토콜이다. 그러나 이러한 SLIP나 PPP는 간이 전자 교환기와 PC 간의 직렬통신에는 적합하지 않고, 부득이하게 이용해야 할 경우에는 상위 레벨에 기본적인 요소를 제공하는 프로토콜을 다시 구현해야 한다.In general, SLIP (Serial Line IP) or PPP (Point-to-Point Protocol) is basically a protocol designed to transmit an Internet Protocol (IP) datagram over serial communication. However, such SLIP or PPP is not suitable for serial communication between a simple electronic switch and a PC, and if necessary, it is necessary to reimplement a protocol that provides a basic element at a higher level.
그래서 SLIP 캡슐화 (Encapsulation)의 경우 END문자(0xc0)와 ESC문자(0xdb)를 정의하여 데이터의 패킷의 시작부분과 끝부분을 구분하는 요소만을 제공한다. 이 프로토콜은 전적으로 상위의 IP 패킷을 직렬포트를 통해 전송하기 위해 고안된 프로토콜이다.Therefore, in the case of SLIP encapsulation, the END character (0xc0) and the ESC character (0xdb) are defined to provide only elements that distinguish the beginning and the end of a packet of data. This protocol is designed to transmit the upper level IP packet through the serial port.
또한 PPP는 SLIP에서와 비슷한 시작 플래그(Start Flag)와 끝 플래그(End Flag) 및 이스케이프 문자 (Escape Character)를 정의한다. 하지만 이 프로토콜은 프로토콜 필드와 CRC 필드를 제공함으로써 복수개의 프로토콜이 PPP를 이용할 수 있게 해줌과 동시에 전송상의 데이터 오류를 검사할 수 있게 해 준다.PPP also defines Start Flags, End Flags, and Escape Characters, similar to those in SLIP. However, this protocol provides a protocol field and a CRC field to allow multiple protocols to use PPP while also checking for data errors on the transmission.
그 외에 주소(Address) 필드와 제어(Control) 필드도 정의되어 있으나 일반적으로는 큰 의미가 없고, 많은 구현에 있어서 필드의 값 자체를 검사하지 않기도 한다.In addition, the Address and Control fields are defined, but they are generally not significant and many implementations do not check the value of the field itself.
좀더 일반적인 구현으로는 간이 사설 교환기가 기존에 구비하고 있는 패킷화 되지 않은 일반 데이터(Raw Data) 전송기능을 그대로 유지하기 위해 패킷화가 요구되는 경우에만 데이터를 패킷화하여 일반 데이터(Raw Data)와 혼재시켜서 함께 전송하는 방법도 사용된다. 이러한 경우를 위한 특별한 요소가 프로토콜 내에 존재하지 않는다면 일반 데이터 (Raw Data)와 패킷화된 데이터를 구분하기 위해서 상대적으로 많은 양의 데이터를 검사해야 한다. 이러한 방법으로는 데이터 처리에 필요 이상의 처리 (Overhead)가 가해지게 될 뿐만 아니라 패킷 전송상의 데이터 오류와 일반 데이터를 제대로 구분할 수 없기 때문에 잠재적인 오류의 가능성을 내포하고 있다.In a more general implementation, data is packetized and mixed with raw data only when packetization is required in order to maintain the unpacked raw data transmission function provided by the simple private exchange. It is also used to send together. If there is no special element for this case in the protocol, a relatively large amount of data must be examined to distinguish raw data from packetized data. This method not only adds more overhead to the data processing, but also implies the possibility of a potential error because it is unable to properly distinguish data errors from general data in packet transmission.
또한 프로토콜로서 제공해야 하는 기본적인 제어기능의 부재로 인하여 복수의 상위 레벨에서 계속 그러한 기능들을 재정의하고 구현해야 한다.In addition, due to the lack of basic control functions that must be provided as protocols, they must continue to redefine and implement those functions at multiple higher levels.
도1은 종래 SLIP와 PPP 프로토콜의 구조도이다.1 is a structural diagram of a conventional SLIP and PPP protocol.
그래서 SLIP의 경우 END문자(0xc0)를 시작 플래그로 사용하고 이어서 데이터를 전송한 후 끝 플래그로 같은 END문자(0xc0)를 사용하여 패킷을 닫는다. END문자(0xc0)가 데이터 부분의 중간에 나올 때는 ESC문자(0xdb)를 이용하여 END문자(0xc0)를 0xdb, 0xdc로 대체한다. ESC문자(0xdb)가 데이터 중간에 나올 때는 이 문자를 0xdb, 0xdd로 대체한다. 데이터를 받는 측에서는 이러한 대체 문자들을 원상태로 복원시켜야 한다.Therefore, in the case of SLIP, the packet is closed by using the END character (0xc0) as the start flag, and then transmitting data, and then using the same END character (0xc0) as the end flag. When the END character (0xc0) appears in the middle of the data part, replace the END character (0xc0) with 0xdb and 0xdc using the ESC character (0xdb). If an ESC character (0xdb) appears in the middle of data, replace it with 0xdb and 0xdd. The receiving party should restore these replacement characters to their original state.
또한 PPP의 경우 시작 플래그와 끝 플래그로 0x7e 값을 사용하고, 0x7d가 이스케이프 문자 (Escape Character)로 사용된다. 데이터 부분에서 0x7e는 0x7d, 0x5e로 0x7d는 0x7d, 0x5d로 대체된다. 주소(Address) 필드는 0xff로, 제어(Control) 필드는 0x03으로 고정되어 있다. 프로토콜(Protocol) 필드는 그 다음에 나오는 데이터 필드의 타입을 나타내는데, 이 값으로 IP 데이터그램(Datagram), 연결 제어 데이터(Link Control Data), 네트워크 제어 데이터(Network Control Data) 등을 나타내게 된다. CRC 필드는 2 바이트 오류검사 값을 나타낸다. 데이터 필드는 1500 바이트까지의 데이터를 가질 수 있다.In the case of PPP, 0x7e value is used as start flag and end flag, and 0x7d is used as escape character. In the data part, 0x7e is replaced by 0x7d, 0x5e and 0x7d is replaced by 0x7d and 0x5d. The Address field is fixed at 0xff, and the Control field is fixed at 0x03. The protocol field indicates the type of data field that follows, and this value indicates an IP datagram, a link control data, a network control data, or the like. The CRC field represents a 2-byte error check value. The data field may have up to 1500 bytes of data.
그 외의 일반적인 구현에서는 일반 데이터(Raw Data)와 패킷화된 데이터를 혼재시켜 전송함으로써 이들의 구분을 전적으로 프로토콜 상위 레벨에서 행하게 한다. 이를 위해서 전송되어 온 데이터가 정해진 패킷 형태를 가지고 있는지 검사를 한 후, 두 형식의 구분을 결정하게 된다.In other general implementations, the mixed data is transmitted in a mixture of raw data and packetized data so that the classification is performed entirely at the upper level of the protocol. To this end, after checking whether the transmitted data has a predetermined packet type, it is decided to distinguish between the two types.
그러나 이러한 SLIP이나 IP는 간이 전자 교환기에 직접적으로 적용시키기 어려운 문제점을 내포하고 있고, 이를 해결하기 위해 상위 레벨의 프로토콜을 구현해야 한다. 그 외의 일반적인 프로토콜은 일반 데이터(Raw Data)와 패킷화된 데이터의 구분에 많은 오버헤드(Overhead)를 요구함과 동시에 오류의 가능성을 내포하고 있다. 또한 기본적인 제어기능의 부재로 복수의 상위 레벨에서 같은 기능을 반복해서 구현해야 하는 문제점 또한 안고 있다.However, such SLIP or IP has a problem that is difficult to apply directly to a simple electronic exchange, and a high level protocol must be implemented to solve this problem. Other common protocols require a lot of overhead in distinguishing between raw data and packetized data, and include a possibility of error. In addition, there is a problem in that the same function is repeatedly implemented at a plurality of higher levels due to the lack of basic control functions.
이에 본 발명은 상기와 같은 종래의 제반 문제점을 해소하기 위해 제안된 것으로, 본 발명의 목적은 직렬 통신을 할 때 패킷화된 데이터와 일반 데이터(Raw Data)의 혼재시 구분 송수신 문제를 해결하고, 효율적인 데이터의 전송을 위해 부가기능을 분리된 프로토콜로 설정함으로써, 상위 레벨에 안정성과 효율성을 제공할 수 있는 간이 전자교환기와 PC 간의 직렬 통신 방법을 제공하는 데 있다.Accordingly, the present invention has been proposed to solve the above conventional problems, and an object of the present invention is to solve the problem of distinguishing transmission and reception when mixing packetized data and raw data when serial communication, It is to provide a serial communication method between a simple electronic switch and a PC that can provide stability and efficiency at a higher level by setting additional functions as separate protocols for efficient data transmission.
도1은 종래 SLIP와 PPP 프로토콜의 구조도이고,1 is a structural diagram of a conventional SLIP and PPP protocol,
도2는 본 발명에 의한 간이 전자교환기와 PC 간의 직렬 통신 방법에 사용되는 SCBP 패킷 형식을 보인 구조도이며,2 is a structural diagram showing a SCBP packet format used in a serial communication method between a simple electronic exchange and a PC according to the present invention;
도3은 본 발명에 의한 간이 전자교환기와 PC 간의 직렬 통신 방법에 사용되는 보조 프로토콜의 패킷 형식을 보인 구조도이고,3 is a structural diagram showing a packet format of an auxiliary protocol used in a serial communication method between a simple electronic exchange and a personal computer according to the present invention;
도4는 본 발명에 의한 간이 전자교환기와 PC 간의 직렬 통신 방법에서 송신방법을 보인 흐름도이며,4 is a flowchart showing a transmission method in a serial communication method between a simple electronic exchange and a personal computer according to the present invention;
도5는 본 발명에 의한 간이 전자교환기와 PC 간의 직렬 통신 방법에서 수신방법을 보인 흐름도이고,5 is a flowchart illustrating a receiving method in a serial communication method between a simple electronic exchange and a personal computer according to the present invention;
도6은 도3에서 에코 테스트 방법을 보인 흐름도이며,6 is a flowchart illustrating an echo test method in FIG.
도7은 도3에서 체크 얼라이브 방법을 보인 흐름도이고,FIG. 7 is a flowchart illustrating a check-alive method in FIG. 3;
도8은 도3에서 라운드 트립 타임 방법을 보인 흐름도이다.8 is a flowchart illustrating a round trip time method of FIG. 3.
상기와 같은 목적을 달성하기 위하여 본 발명에 의한 간이 전자교환기와 PC 간의 직렬 통신 방법은,In order to achieve the above object, a serial communication method between a simple electronic exchange and a PC according to the present invention,
간이 전자 교환기에서 PC와 직렬통신을 할 때, 프로토콜의 시작 플래그(Start Flag)와 끝 플래그(End Flag)는 한 패킷의 시작과 끝을 구분하고 LRC(Longitudinal Redundancy Check)는 패킷 내부의 데이터 전송 오류를 검출하게 하고, 데이터의 길이는 길이(Length) 필드에서 정의하여 그 다음에 오는 데이터의 길이를 판단할 수 있게 해 주며, 플래그(Flags) 필드 내의 PCS(Protocol Class) 는 그 다음에 오는 P-Type(Protocol Type)에서 정의된 프로토콜이 보조 프로토콜 (Associate Protocol)인지 상위 레벨의 응용 프로토콜(Application Protocol)인지를 판단할 수 있게 해주고, P-Type은 상위 레벨 프로토콜의 종류를 판별하게 해 주도록 하는 SCBP 프로토콜을 사용하여 패킷화되지 않은 일반 데이터와 패킷화된 데이터를 구분하여 송신하고 수신하는 단계와; 에코 테스트와 체크 얼라이브와 라운드 트립 타임을 갖는 보조 프로토콜에 의해 에코 테스트와 체크 얼라이브와 라운드 트립 타임을 수행하는 단계를 수행함을 그 기술적 구성상의 특징으로 한다.When serial communication with a PC is performed in a simple electronic exchange, the start flag and end flag of the protocol distinguish the beginning and end of a packet, and the longitudinal redundancy check (LRC) causes data transmission errors within the packet. The length of the data can be defined in the Length field to determine the length of the next data, and the PCS (Protocol Class) in the Flags field is followed by P-. SCBP allows you to determine whether the protocol defined in Type (Protocol Type) is an Associate Protocol or a higher level Application Protocol, and the P-Type allows you to determine the type of the higher level protocol. Distinguishing and transmitting and receiving unpacked general data and packetized data using a protocol; The technical configuration is characterized by performing the steps of performing the echo test, the check alive and the round trip time by an auxiliary protocol having the echo test and the check alive and the round trip time.
이하, 상기와 같은 본 발명에 의한 간이 전자교환기와 PC 간의 직렬 통신 방법의 기술적 사상에 따른 일실시예를 첨부한 도면에 의거 상세히 설명하면 다음과 같다.Hereinafter, with reference to the accompanying drawings an embodiment according to the technical idea of a serial communication method between a simple electronic exchange and a PC according to the present invention as follows.
먼저 종래의 프로토콜들은 같은 프로토콜 또는 하나의 묶음(Suite)으로 정의된 보조적인 프로토콜과의 상호통신 규정을 정의해 놓고 있다. 일반적으로 이러한 정의만으로도 원하는 기능을 충분히 구현할 수 있으나 특정 상황에서는 예외적인 데이터의 흐름 또한 통제해야 할 경우가 생긴다.First, the conventional protocols define the intercommunication rules with the supplementary protocols defined as the same protocol or a suite. In general, these definitions are sufficient to implement the desired functionality, but under certain circumstances you may also need to control the flow of exceptional data.
본 발명에 의한 방법에 사용되는 프로토콜의 적용 대상인 간이 전자 교환기의 경우 교환기의 유지보수 및 관리를 위한 텍스트 데이터의 양방향 흐름이 존재한다. 또한 경우에 따라서는 교환기 내부 설정을 변경하기 위한 이진(Binary) 데이터의 흐름이 존재하기도 한다.In the case of a simple electronic exchange which is subject to a protocol used in the method according to the present invention, there exists a bidirectional flow of text data for maintenance and management of the exchange. In some cases, there is also a flow of binary data to change the internal settings of the exchange.
이러한 경우들에 있어서 공통적인 사항은 패킷화 되지 않은 일반 데이터(Raw Data)의 흐름이라는 것이다. 이것은 차세대 통신 어플리케이션을 제공하는 CTI (Computer Telephony Integration) 기능 등을 구현 및 제공하는데 있어서 큰 장애가 된다. 따라서 기존의 일반 데이터(Raw Data)의 흐름과 패킷화된 데이터 흐름을 명확히 구분하여 수신/전송할 수 있는 프로토콜이 요구된다. 또한 직렬통신시의 최하위 레벨 프로토콜이 일반적으로 요구되는 부가기능을 제대로 구비하고 있지 못하기 때문에 그 상위 레벨에서 중복하여 구현하여야 하는 비효율성 또한 존재한다.Common in these cases is the flow of raw data that is not packetized. This is a major obstacle in implementing and providing CTI (Computer Telephony Integration) functions that provide next generation communication applications. Therefore, there is a need for a protocol that can clearly receive and transmit the flow of normal data and packetized data flow. In addition, since the lowest level protocol in serial communication does not have the required additional functions, there is an inefficiency that must be implemented at a higher level.
따라서 본 발명에서는 최소한의 오버헤드(Overhead)로 기존의 문제점들을 해결하는 방안을 제시한다.Therefore, the present invention proposes a method for solving the existing problems with minimal overhead.
그래서 시작 플래그(Start Flag)와 끝 플래그(End Flag)는 한 패킷의 시작과 끝을 구분하고 LRC(Longitudinal Redundancy Check)는 패킷 내부의 데이터 전송 오류를 검출하게 된다. 데이터의 길이는 길이(Length) 필드에서 정의되어 그 다음에 오는 데이터의 길이를 판단할 수 있게 해 준다.Therefore, a start flag and an end flag distinguish a start and end of a packet, and a longitudinal redundancy check (LRC) detects a data transmission error inside the packet. The length of the data is defined in the Length field, allowing you to determine the length of the data that follows.
플래그(Flags) 필드 내의 PCS(Protocol Class) 는 그 다음에 오는 P-Type(Protocol Type)에서 정의된 프로토콜이 보조 프로토콜 (Associate Protocol)인지 상위 레벨의 응용 프로토콜(Application Protocol)인지를 판단할 수 있게 해준다. P-Type은 상위 레벨 프로토콜의 종류를 판별하게 해 준다. 현재 정의된 보조 프로토콜 (Associate Protocol)은 Echo Test, Check Alive, Round Trip Time 등 세 가지이다.The Protocol Class (PCS) in the Flags field can be used to determine whether the protocol defined in the subsequent P-Type (Associate Protocol) or higher level Application Protocol. Do it. P-Type allows you to determine the type of higher level protocol. Currently, there are three secondary protocols defined: Echo Test, Check Alive, and Round Trip Time.
플래그(Flags) 필드에 정의된 나머지 여섯 개의 플래그들이 일반 데이터(Raw Data)와 패킷화된 데이터를 구분하여 전송/수신할 수 있게 해주는 메커니즘을 제공한다.The remaining six flags defined in the Flags field provide a mechanism to distinguish between raw data and packetized data for transmission / reception.
RST (Raw Data Start)와 RED (Raw Data End)는 각각 일반 데이터의 시작과 끝을 의미하고, 일반 데이터(Raw Data)와 패킷화된 데이터 전송/수신간의 스위치 작용을 해준다. RSA (RST Acknowledgement)와 REA (RED Acknowledgement)는 각각 RST와 RED 신호를 받은 측이 이러한 신호를 받았을 때 신호를 보낸 측에 알려주는 플래그이다. 이로써 RST나 RED를 보낸 측은 상대방이 자신이 보낸 신호를 정상적으로 수신했는지 확인하고 바뀐 모드로 송신을 시작할 수 있게 된다. RSN(RST Not Requested)과 REN(RED Not Requested)는 예상되는 오류를 방지하기 위한 플래그이다.Raw Data Start (RST) and Raw Data End (RED) mean the start and end of normal data, respectively, and act as a switch between raw data and packetized data transmission / reception. RSA (RST Acknowledgment) and REA (RED Acknowledgement) are flags that inform the sender when the RST and RED signals receive these signals, respectively. This allows the sender of the RST or RED to confirm that the other party has received the signal it sent normally and to start transmitting in the changed mode. RST Not Requested (RSN) and RED Not Requested (REN) are flags to prevent expected errors.
일반 데이터(Raw Data) 전송 중 우연히 RST나 RED 형식과 동일한 데이터 형태가 만들어질 수도 있다. 이러한 경우 수신측은 송신측이 다른 모드로 바꿔 전송하겠다는 신호로 해석하고 RSA나 REA를 보내게 된다. 이때 송신측은 RSN이나 REN을 보냄으로써 이러한 오류를 정정해 주게 된다. 이러한 오류의 가능성이 매우 적기는 하지만 이러한 과정을 통해서 오류의 가능성이 제거되게 된다.During the transmission of raw data, the same data type as the RST or RED format may be created by chance. In this case, the receiver interprets it as a signal that the sender switches to another mode and transmits an RSA or REA. At this time, the sender corrects this error by sending RSN or REN. Although the likelihood of such errors is very small, this process eliminates them.
그래서 본 발명에 의한 프로토콜은 SCBP(Serial Communication Base Protocol)이라는 기본 프로토콜과 SCAP(Serial Communication Associate Protocols)라는 보조 프로토콜들로 구성된다. 데이터 송수신을 위한 모든 기능은 SCBP만으로도 가능하고, SCAP는 기본적인 부가기능을 제공한다.Thus, the protocol according to the present invention is composed of a basic protocol called SCBP (Serial Communication Base Protocol) and a supplementary protocol called SCAP (Serial Communication Associate Protocols). All functions for sending and receiving data are available with SCBP alone, and SCAP provides basic additional functions.
SCBP는 도2와 같은 패킷 형식을 지닌다. 시작(Start) 플래그는 패킷의 시작을 나타내는 플래그로 0xbc의 값을 가진다. 끝(End) 플래그는 패킷의 끝을 나타내는 플래그로 시작 플래그와 같은 값인 0xbc의 값을 가진다. LRC (Longitudinal Redundancy Check)는 전송 데이터의 오류를 검출되는데 사용되는 필드로 1 Byte의 길이를 갖는다. LRC는 시작 플래그와 끝 플래그를 제외한 모든 바이트들을 (LRC 자체도 포함하여) 비트 위치별로 XOR 연산을 하였을 때 결과가 0xff가 되도록 설정된 값이다. 수신측에서 같은 연산을 수행했을 때 0xff 값이 산출되지 않는다면 데이터 송신 중 오류가 발생한 것으로 간주한다.SCBP has a packet format as shown in FIG. Start flag is a flag indicating the start of a packet and has a value of 0xbc. End flag is a flag indicating the end of a packet and has a value of 0xbc which is the same value as the start flag. LRC (Longitudinal Redundancy Check) is a field used to detect errors in transmission data and has a length of 1 byte. LRC is a value set to be 0xff when all bytes except the start flag and the end flag are XORed by bit positions (including the LRC itself). If 0xff value is not calculated when the same operation is performed at the receiver, an error occurs during data transmission.
길이(Length) 필드는 바로 다음에 나오는 데이터의 길이를 나타낸다. 이를 통해서 수신측에서는 수신된 데이터의 길이를 알 수 있게 된다. 길이 필드는 1Byte의 크기를 갖기 때문에 최대 255 Byte의 데이터가 하나의 패킷에 실릴 수 있다. 플래그(Flags) 필드의 PCS(Protocol Class) 플래그는 2 Bit를 사용하는 플래그로서, 바로 다음에 오는 P-Type(Protocol Type) 필드에 나타나는 프로토콜의 클래스를 나타낸다. 00값은 보조 프로토콜 (Associate Protocols)을 위해 사용되고 01과 10값은 응용 프로토콜 (Application Protocol)을 위해 사용된다. 따라서 SCBP에 부가기능을 제공하는 (Associate Protocols) 외의 응용 프로그램들은 01과 10값을 PCS로 갖는 프로토콜을 SCBP의 상위에 구현해야 한다.The Length field indicates the length of the data immediately following. Through this, the receiving side can know the length of the received data. Since the length field has a size of 1 byte, up to 255 bytes of data may be carried in one packet. The PCS (Protocol Class) flag in the Flags field is a flag that uses 2 bits and indicates the class of the protocol that appears in the P-Type (Protocol Type) field immediately following. Values 00 are used for Associate Protocols and values 01 and 10 are used for Application Protocol. Therefore, applications other than Associate Protocols that provide additional functionality to SCBP should implement a protocol on top of SCBP that has a value of 01 and 10 as PCS.
PCS값 00의 경우 P-Type의 값은, Echo Test는 0x01, Check Alive는 0x02, Round Trip Time은 0x03의 값을 갖는다. PCS 값 11은 차후에 추가될 Class를 위해 예약(Reserved) 되어 있다.In the case of the PCS value 00, the P-Type has a value of 0x01 for Echo Test, 0x02 for Check Alive and 0x03 for Round Trip Time. PCS value 11 is reserved for future classes.
플래그 필드 중 RST(Raw Data Start)는 전송모드를 일반 데이터(Raw Data) 모드로 전환할 때 사용된다. 이때 송신측은 RST 비트를 1로 Set해야 하고 PCS를 포함한 나머지 플래그들은 동시에 1로 Set될 수 없다. P-Type은 0x00 값으로 설정되고, 길이 필드는 0x00으로 설정되며 데이터 필드는 데이터를 갖지 않는다.Raw Data Start (RST) in the Flag field is used to switch the transmission mode to Raw Data mode. At this time, the transmitting side should set the RST bit to 1, and the remaining flags including PCS cannot be set to 1 at the same time. The P-Type is set to a value of 0x00, the length field is set to 0x00 and the data field has no data.
RED(Raw Data End)는 전송모드를 패킷 모드로 전환할 때 사용된다. 이때 송신측은 RED 비트를 1로 Set해야 하고 나머지 설정사항은 RST와 동일하다.RED (Raw Data End) is used to switch the transmission mode to the packet mode. At this time, the transmitter shall set the RED bit to 1 and the remaining settings are the same as the RST.
RSA(RST Acknowledgement)는 수신측이 송신측으로부터 RST를 받았을 경우 설정되며 수신측은 RSA 비트를 1로 Set한 후 송신측에 즉각 송신해야 한다. 즉각 송신이라는 말은 송신 큐(Queue) 상에서 최상위에 위치시킨다는 말과 동일하다. 나머지 설정사항은 RST와 동일하다.The RSA (RST Acknowledgment) is set when the receiving side receives the RST from the transmitting side. The receiving side should set the RSA bit to 1 and immediately transmit it to the transmitting side. Immediate transmission is equivalent to placing it at the top of the transmission queue. The remaining settings are the same as for RST.
REA(RED Acknowledgement)는 수신측이 송신측으로부터 RED를 받았을 경우 설정되며 수신측은 RSA 비트를 1로 Set한 후 송신측에 즉각 송신해야 한다. 나머지 설정사항은 RST와 동일하다.The REA (RED Acknowledgment) is set when the receiving side receives RED from the transmitting side. The receiving side should immediately transmit to the transmitting side after setting RSA bit to 1. The remaining settings are the same as for RST.
RSN (RST Not Requested)는 송신측이 RST는 보내지 않았는데 수신측으로부터 RSA를 받았을 경우 송신측으로부터 전송된다. 이때 송신측은 RSN 비트를 1로 Set한 후 즉각 송신해야 한다. 나머지 설정사항은 RST와 동일하다.RSN Not Requested (RSN) is transmitted from the sender when the sender receives an RSA from the receiver without sending an RST. At this time, the transmitter shall transmit immediately after setting RSN bit to 1. The remaining settings are the same as for RST.
REN(RED Not Requested)는 송신측이 RED를 보내지 않았는데 수신측으로부터 REA를 받았을 경우 송신측으로부터 전송된다. 이때 송신측은 REN 비트를 1로 Set한 후 즉각 송신해야 한다. 이러한 설정은 발생 가능한 오류를 정정할 수 있는 기능을 제공한다.The REN (RED Not Requested) is transmitted from the sender when the sender does not send RED but receives the REA from the receiver. At this time, the transmitter shall transmit immediately after setting the REN bit to 1. This setting provides the ability to correct possible errors.
일반 데이터(Raw Data) 송신 중 우연히 RST나 RED를 갖는 패킷과 동일한 데이터가 전송될 수도 있다. 이러한 경우 수신측은 송신측이 송신 모드를 바꾸려 한다고 인식하고 RSA나 REA를 보내게 되는데 이때 송신측이 RSN이나 REN을 수신측에 보냄으로써 전송모드를 원래의 상태로 되돌릴 수 있게 해 준다.During the transmission of raw data, the same data as a packet having RST or RED may be transmitted by accident. In this case, the receiving side recognizes that the transmitting side wants to change the transmission mode, and then sends an RSA or REA. At this time, the transmitting side sends the RSN or REN to the receiving side so that the transmission mode can be returned to its original state.
송신 알고리즘은 도4(ST1 ~ ST30)에 나타나 있고, 수신 알고리즘은 도5(ST31 ~ ST61)에 나타나 있다. 송수신 양측에 있어서 기본 모드는 일반 데이터(Raw Data) 모드로 설정된다.The transmission algorithm is shown in Fig. 4 (ST1 to ST30), and the reception algorithm is shown in Fig. 5 (ST31 to ST61). The basic mode is set to a raw data mode on both sides of the transmission and reception.
따라서 패킷화된 데이터를 송수신하기 위해서는 먼저 송신을 하는 측에서 RED를 보내서 패킷 모드로 전환을 해야 한다. 일반적으로 교환기는 초기의 수신측이 된다.Therefore, in order to send and receive packetized data, the transmitting side must first send RED to switch to packet mode. In general, the exchange becomes the initial receiving side.
또한 송신측은 일반 데이터(Raw Data)와 패킷화된 데이터를 위한 분리된 큐(Queue)를 구현하거나 하나의 큐에 태그(Tag) 필드를 둠으로써 큐(Queue) 내부의 일반 데이터(Raw Data)와 패킷화된 데이터를 구분할 수 있어야 한다.In addition, the sender implements a separate queue for the raw data and the packetized data, or puts a tag field in a single queue, so that the sender can use the raw data in the queue and the raw data. It should be able to distinguish packetized data.
수신측은 독립된 큐를 구현할 필요는 없지만 분리된 큐는 구현시 명확성을 제공할 것이다.The receiving side does not need to implement a separate queue, but a separate queue will provide clarity at implementation.
송신 알고리즘에서, 전송할 차례가 된 큐 내부의 데이터가 현재의 전송 모드와 다를 때에는 먼저 RST나 RED를 보내서 모드를 바꾼 후 전송하도록 되어 있다. 도4를 보면 RST나 RED를 보낸 후에 수신측으로부터의 RSA나 REA를 기다리고 이것이 수신되지 않으면 다시 일반 데이터 모드로 돌아오게 되어 있다.In the transmission algorithm, when the data in the queue to be transmitted differs from the current transmission mode, the RST or RED is sent first to change the mode, and then the transmission is performed. In Figure 4, after sending the RST or RED, it waits for the RSA or the REA from the receiving end and returns to the normal data mode if it is not received.
그리고 도4에는 표시되어 있지 않지만, 이러한 일반적인 데이터 전송과정과는 별도로, 송신측은 주기적으로 Check Alive 패킷을 수신측에 보내어 상대방이 동작하고 있는지를 체크한다.Although not shown in Fig. 4, apart from such a general data transmission process, the sender periodically sends a Check Alive packet to the receiver to check whether the other party is operating.
만약 상대방으로부터 응답이 없다면 송신측은 상대방이 더 이상 존재하지 않는 것으로 간주하고 데이터 전송 모드를 일반 데이터(Raw Data) 모드로 전환하고 패킷 데이터를 위한 큐(Queue)의 내용을 지우게 된다.If there is no response from the other party, the sender assumes that the other party no longer exists and switches the data transmission mode to raw data mode and clears the contents of the queue for packet data.
본 프로토콜에서는 각 시스템의 특성과 처리능력을 고려하여 이 기능을 위한 타이머의 값을 정의하지는 않지만 1000ms 정도로 3번 재시도 할 것을 권장한다.This protocol does not define the timer value for this function considering the characteristics and processing capacity of each system, but it is recommended to retry three times at about 1000ms.
수신 알고리즘에서는, 일반적인 처리 외에 수신된 패킷의 플래그(Flags) 필드를 검사하여 처리하는 과정을 보여준다. RST나 RED가 수신됐을 때의 RSA, REA 송신 처리, RSA, REA가 수신됐을 때의 모드변경 처리, RSN, REN이 수신 됐을 때의 정정 처리 등의 과정과 이러한 과정에서 오류가 발생했을 때의 오류처리 등을 행하게 된다.In the reception algorithm, the flag field of the received packet is examined and processed in addition to the normal processing. RSA, REA transmission processing when RST or RED is received, mode change processing when RSA and REA are received, correction processing when RSN and REN are received, and errors when an error occurs in these processes Processing and the like.
도6 내지 도8에서는 SCAP(Serial Communication Associate Protocols)에 속하는 보조 프로토콜(Associate Protocols)의 알고리즘을 나타낸다. 도3에서는 이러한 프로토콜들의 패킷 형식을 나타내고 있다.6 to 8 show algorithms of Associate Protocols belonging to SCAP (Serial Communication Associate Protocols). Figure 3 shows the packet format of these protocols.
도6a는 에코를 송신할 경우이고, 도6b는 에코 응답을 수신하는 경우이며, 도6c는 다시 에코를 전송하는 경우이다. 그래서 도6의 Echo Test의 경우(ST71 ~ ST96), 송신측이 RQ(Request) 플래그를 1로 Set하고 길이(Length) 필드와 그 길이를 갖는 데이터를 실어서 수신측에 전송하면, 수신측은 RP(Reply) 플래그를 1로 Set하고 수신된 패킷의 길이 필드값과 데이터 필드값을 자신의 패킷에 복사하여 송신측에 전송한다. RQ와 RP중 하나만 1로 Set 되어야 한다. 길이 필드가 6 Bit길이를 갖기 때문에 데이터를 최고 63 Byte까지 실을 수 있다.FIG. 6A shows a case of transmitting an echo, FIG. 6B shows a case of receiving an echo response, and FIG. 6C shows a case of transmitting an echo again. Thus, in the case of the Echo Test of FIG. 6 (ST71 to ST96), when the transmitting side sets the RQ (Request) flag to 1 and loads the length field and the data having the length to the receiving side, the receiving side receives the RP. Set the (Reply) flag to 1 and copy the length field value and data field value of the received packet to its own packet and send it to the sender. Only one of RQ and RP should be set to 1. Since the length field has 6 bits, data can be loaded up to 63 bytes.
도7의 Check Alive(ST101 ~ ST133)는 상대방이 동작하고 있는 중인지를 검사하는 프로토콜이다. 도7a는 체크 얼라이브를 송신하는 경우이고, 도7b는 체크 얼라이브 응답을 수신하는 경우이며, 도7c과 도7d는 체크 얼라이브를 수신하는 경우이다. 그래서 송신측이 RQ(Request) 플래그를 1로 Set하고 송신하면 수신측은 RP(Reply) 플래그를 1로 Set하여 송신측에 전송한다. Sender 필드는 송신측이 자신을 나타내기 위해 임의로 설정하는 값이지만, 0을 설정할 수는 없다. 0은 SCBP에서 내부적인 용도로 이 패킷을 보낼 때 사용한다.Check Alive (ST101 to ST133) in Fig. 7 is a protocol for checking whether the counterpart is operating. 7A shows a case of transmitting a check-alive, FIG. 7B shows a case of receiving a check-alive response, and FIGS. 7C and 7D show a case of receiving a check-alive. Therefore, when the sender sets the RQ (Request) flag to 1 and transmits, the receiver sets the RP (Reply) flag to 1 and transmits it to the sender. The Sender field is a value set arbitrarily by the sender to indicate itself, but cannot be set to 0. 0 is used by SCBP to send this packet for internal use.
수신측은 Sender 값을 복사하여 송신측에 돌려보낸다. IF(Inform) 플래그는일방적으로 송신측이 수신측에 자신이 살아있음을 알리는 용도로 사용할 수 있다. RQ, RP, IF 중 하나만이 1로 Set될 수 있고 Sender필드는 5 Bit의 길이를 갖는다.The receiver copies the Sender value and sends it back to the sender. The IF (Inform) flag can be used for the purpose of informing the sender that he is alive. Only one of RQ, RP, and IF can be set to 1 and the sender field is 5 bits long.
도8의 RTT (Round Trip Time)(ST141 ~ ST178)은 송신측이 보낸 패킷이 수신측에 도달하는 시간을 검사하기 위해 사용되는 프로토콜이다. 여기서 도8a는 RTT를 송신하는 경우이고, 도8b는 RTT 응답을 수신하는 경우이며, 도8c는 다시 RTT를 송신하는 경우이다. 송신측은 RQ를 1로 Set하고 S-S Time에 자신의 현재 시간을 초(6 Bit)와 밀리초(10 Bit)의 형태로 저장하여 보낸다. 수신측은 송신측이 NR(Need Receiver Time)을 설정하였으면 R-R Time에 자신이 패킷을 받은 시간을, R-S Time에 자신이 패킷을 전송하는 시간을 저장하고 S-S Time은 그대로 복사한 후 송신측으로 전송한다. 송신측은 이 정보를 토대로 송수신단 간의 전송 시간을 계산할 수 있게 된다.Round Trip Time (RTT) ST141 to ST178 of FIG. 8 is a protocol used to check a time when a packet sent from a transmitter arrives at a receiver. 8A illustrates a case of transmitting an RTT, FIG. 8B illustrates a case of receiving an RTT response, and FIG. 8C illustrates a case of transmitting an RTT. The sender sets RQ to 1 and stores its current time in seconds (6 bits) and milliseconds (10 bits) in S-S Time. If the receiver sets the NR (Need Receiver Time), the receiver stores the time of receiving the packet in the R-R Time, the time of transmitting the packet in the R-S Time, and the S-S Time is copied as it is and transmitted to the transmitter. The transmitter can calculate the transmission time between the transmitter and the receiver based on this information.
이처럼 본 발명은 직렬 통신을 할 때 패킷화된 데이터와 일반 데이터(Raw Data)의 혼재시 구분 송수신 문제를 해결하고, 효율적인 데이터의 전송을 위해 부가기능을 분리된 프로토콜로 설정함으로써, 상위 레벨에 안정성과 효율성을 제공하게 되는 것이다.As described above, the present invention solves the problem of distinguishing transmission and reception when mixed packetized data and raw data during serial communication, and sets an additional function as a separate protocol for efficient data transmission, thereby ensuring stability at a higher level. And efficiency.
이상에서 본 발명의 바람직한 실시예를 설명하였으나, 본 발명은 다양한 변화와 변경 및 균등물을 사용할 수 있다. 본 발명은 상기 실시예를 적절히 변형하여 동일하게 응용할 수 있음이 명확하다. 따라서 상기 기재 내용은 하기 특허청구범위의 한계에 의해 정해지는 본 발명의 범위를 한정하는 것이 아니다.Although the preferred embodiment of the present invention has been described above, the present invention may use various changes, modifications, and equivalents. It is clear that the present invention can be applied in the same manner by appropriately modifying the above embodiments. Accordingly, the above description does not limit the scope of the invention as defined by the limitations of the following claims.
이상에서 살펴본 바와 같이, 본 발명에 의한 간이 전자교환기와 PC 간의 직렬 통신 방법은 기존의 일반 데이터(Raw Data) 형태로 존재하던 데이터의 흐름과 이를 이용하던 응용 프로그램을 그대로 사용하면서 패킷화된 데이터 또한 송수신 함으로써 직렬포트의 상위 레벨에서 행해야만 했던 데이터 구분을 최하위 레벨에서 행하여 전송의 효율을 높임과 동시에 후자의 방식이 잠재적으로 내포하고 있는 오류의 가능성을 제거함으로써 안정성을 제공할 수 있는 효과가 있게 된다.As described above, in the serial communication method between the simple electronic exchange and the PC according to the present invention, the packetized data may be used while using the flow of data existing in the form of raw data and the application program using the same. By transmitting and receiving, data separation, which had to be done at the upper level of the serial port, can be performed at the lowest level to increase the transmission efficiency and to provide stability by eliminating the possibility of the error that the latter method potentially contains. .
이러한 일반 데이터(Raw Data)와 패킷화된 데이터의 송수신 스위칭 기능은 최소한의 오버헤드(Overhead)로 기존에 구축되어 있는 소프트웨어를 최대한 유지하면서 안정된 패킷 송수신 기능을 최하위 레벨에서 구현할 수 있다는 이점이 있다.The transmission and reception switching function of the raw data and the packetized data has an advantage that stable packet transmission / reception function can be implemented at the lowest level while maintaining the existing software with the minimum overhead.
또한 보통 상위 레벨에서 구현되어 왔던 기본적인 부가기능을 직렬포트의 최하위 프로토콜에서 직접 사용하고 또한 바로 위 레벨의 프로토콜에 부가기능을 제공하게끔 함으로써 복수개의 상위 어플리케이션이 중복하여 구현해야 했던 낭비요인을 제거하고, 또한 간이 전자 교환기 등 사용 가능한 내부 자원이 상대적으로 부족한 시스템에 적합하도록 오버헤드(Overhead)를 최소화하고 전송 데이터의 크기 등을 적절한 선으로 한정함과 동시에 반드시 필요로 되는 기능요소만으로 구성하였으므로 상위 레벨 프로토콜이나 어플리케이션 구현시 짧은 시간 내에 명확하게 본 프로토콜의 요소를 파악하여 구현의 경제성을 높인 효과도 있게 된다.In addition, by using the basic add-on that was normally implemented at the upper level directly in the lowest level protocol of the serial port, and providing the additional function at the upper level protocol, it eliminates the waste that multiple upper applications had to implement redundantly, In addition, to minimize the overhead and to limit the size of the transmission data to the appropriate line to fit the system with relatively low internal resources such as a simple electronic exchange, the high level protocol However, when implementing an application, it is possible to clearly understand the elements of the protocol in a short time and increase the economics of the implementation.
Claims (7)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1019990036009A KR100302329B1 (en) | 1999-08-27 | 1999-08-27 | Method for serial communication between simple electronic switch and personal computer |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1019990036009A KR100302329B1 (en) | 1999-08-27 | 1999-08-27 | Method for serial communication between simple electronic switch and personal computer |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR20010019557A KR20010019557A (en) | 2001-03-15 |
| KR100302329B1 true KR100302329B1 (en) | 2001-11-01 |
Family
ID=19609046
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1019990036009A KR100302329B1 (en) | 1999-08-27 | 1999-08-27 | Method for serial communication between simple electronic switch and personal computer |
Country Status (1)
| Country | Link |
|---|---|
| KR (1) | KR100302329B1 (en) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH07264263A (en) * | 1994-03-25 | 1995-10-13 | Sanyo Electric Co Ltd | Serial communication interface device |
| JPH08163151A (en) * | 1994-12-12 | 1996-06-21 | Nippondenso Co Ltd | Serial communication device |
| JPH10247929A (en) * | 1997-03-04 | 1998-09-14 | Sony Corp | Serial communication system |
| KR19980046491A (en) * | 1996-12-12 | 1998-09-15 | 정장호 | Transmission and reception control system of serial communication in large capacity ICPS |
| JPH10290268A (en) * | 1997-04-17 | 1998-10-27 | Matsushita Electric Ind Co Ltd | Synchronous serial communication circuit and communicating method |
| KR19990059975A (en) * | 1997-12-31 | 1999-07-26 | 윤종용 | Protocol Optimization Method for Serial Communication |
-
1999
- 1999-08-27 KR KR1019990036009A patent/KR100302329B1/en not_active IP Right Cessation
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH07264263A (en) * | 1994-03-25 | 1995-10-13 | Sanyo Electric Co Ltd | Serial communication interface device |
| JPH08163151A (en) * | 1994-12-12 | 1996-06-21 | Nippondenso Co Ltd | Serial communication device |
| KR19980046491A (en) * | 1996-12-12 | 1998-09-15 | 정장호 | Transmission and reception control system of serial communication in large capacity ICPS |
| JPH10247929A (en) * | 1997-03-04 | 1998-09-14 | Sony Corp | Serial communication system |
| JPH10290268A (en) * | 1997-04-17 | 1998-10-27 | Matsushita Electric Ind Co Ltd | Synchronous serial communication circuit and communicating method |
| KR19990059975A (en) * | 1997-12-31 | 1999-07-26 | 윤종용 | Protocol Optimization Method for Serial Communication |
Also Published As
| Publication number | Publication date |
|---|---|
| KR20010019557A (en) | 2001-03-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100334788B1 (en) | Method and apparatus for connecting a node to a wireless network using standard protocols | |
| US5805818A (en) | System for acknowledging availability of neighbor node using data packet containing data that is ordinarily fowarded to neighbor node | |
| US20020199019A1 (en) | Method and apparatus for transmitting data in a communication system | |
| Perkins | Requirements for an Internet Standard Point-to-Point Protocol | |
| Simpson | PPP LCP Extensions | |
| Rand | PPP reliable transmission | |
| US6745360B1 (en) | Method and system for controlling the rate of acknowledgment of communication packets | |
| US7680122B2 (en) | Communication method for data communication based on point-to-point protocol | |
| US5983271A (en) | Method for processing asynchronous low-level protocols in a communication device to off load the main processor | |
| EP3410637B1 (en) | Information transmission method, gateway, and controller | |
| WO2007118381A1 (en) | The method, system and apparatus for transferring syslog message | |
| KR100302329B1 (en) | Method for serial communication between simple electronic switch and personal computer | |
| JP2000236348A (en) | Management system of remote equipment using internet protocol | |
| US6526049B1 (en) | Packet transferring device | |
| Schneider et al. | PPP for Data Compression in Data Circuit-Terminating Equipment (DCE) | |
| Cisco | Tunneling of Asynchronous Security Protocols | |
| Cisco | Tunneling of Asynchronous Security Protocols | |
| Cisco | Tunneling of Asynchronous Security Protocols | |
| Cisco | Tunneling of Asynchronous Security Protocols | |
| Cisco | Tunneling of Asynchronous Security Protocols | |
| Cisco | Tunneling of Asynchronous Security Protocols | |
| Cisco | Tunneling of Asynchronous Security Protocols | |
| JPH09326810A (en) | Connection changeover method on occurrence of fault | |
| CN100413266C (en) | Process and apparatus for reliable remote testing | |
| US6725273B1 (en) | Point-to-point prefix protocol |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A201 | Request for examination | ||
| E701 | Decision to grant or registration of patent right | ||
| GRNT | Written decision to grant | ||
| LAPS | Lapse due to unpaid annual fee |