KR20000056539A - Interprocessor communication method between host digital terminal and optical network unit in optical local distribution loop) - Google Patents

Abstract

PURPOSE: A host digital terminal in optical subscriber network and communication protocol between optical network units is provided to enhance message processing functions by using a simple message processing procedure. CONSTITUTION: A host digital terminal in optical subscriber network and communication protocol between optical network units includes the following steps. A serve network(300) which is required to transmit data transmits data Protocol Data Unit(PDU) which includes an Interprocessor Communication(IPC) message to a receiving serve network(302) as shown in step 400. A serve network(300) activates a primary timer(T100) and converts from null status into Acknowledge status(ACK). A receiving serve network(302) responds to the data PDU and transmits ACK PDU so as to inform serve network(300) of the well-received message as shown in step 402. A transmitting serve network(300) increases the sequence numbers of data PDU one after another when transmitting data PDU. A receiving serve network(302) maintains the received sequence numbers of the data PDU. By this way, a serve network(302) determines whether the received data PDU has already been received by checking the sequence numbers. If the data PDU was received before, the serve network(302) will not respond. If there is more IPC messages to transmit, data PDU is transmitted to the serve network(302) as shown in step 404.

Description

Method of communication protocol between host digital terminal and processor in optical subscriber distribution network

The present invention relates to an optical subscriber distribution network, and more particularly, to a protocol method for communication between a host digital terminal and an processor of an optical network unit.

An optical cable is introduced to improve the optical subscriber transfer characteristics between the telephone station and the subscriber station, and an optical subscriber transmission device is placed between the telephone station and the subscriber station and the subscriber station, thereby forming a logical loop that is not electrical. This loop is called an optical subscriber loop. As a result, between the telephone station and the subscriber station is changed from a single connection to a multi-stage connection, and the resulting network is called an optical subscriber network.

1 is a block diagram schematically illustrating an example of a conventional optical subscriber network, in which a host digital terminal in a central office (100), that is, a host digital terminal (HDT) 102 and a plurality of optical network units, That is, ONUs (Optical Network Units) 104-1 to 104-n are connected through each of the transmission paths 106-1 to 106-n provided by optical fibers. The HDT 102 and the ONUs 104-1 to 104-n thus connected form an optical subscriber distribution network. Such optical subscriber network distribution networks are described, for example, by US Patent No. 5,574,783, invented by James P. Dunn and filed on Nov. 12, 1996, by Frank Klopfer, et al. No. 5,790,171 and the like. In addition, pages 30-31 of the Korean Journal of Communication Sciences, Vol. 15, No. 3, published on March 31, 1998, and Figure 9, The Korean Institute of Communication and Information Technology, published on December 27, 1996 by Hongneung Science Publishing Co., Ltd. See pages 458-461 and Figure 17.10. According to them, the HDT 102 is located at the CO 100 as a serving node of the optical subscriber distribution network as shown in FIG. 1 or at a remote node in the case of a wide area optical subscriber network. And the optical transmission paths 106-1 to 106-n terminate at the ONUs 104-1 to 104-n, respectively. The ONUs 104-1 to 104-n are optical subscriber access devices or optical terminators, in which various subscriber stations are directly connected or connected through a customer premises network (CPN) or a suitable number of subscribers and traffic. It accepts and connects with subscribers with copper or coaxial cable.

Meanwhile, in the optical subscriber distribution network, interprocessor communication, that is, interprocessor communication (IPC), is required between the HDT and the ONU. In general, TCP / IP (Transmission Control Protocol / Internet Protocol) protocol has been adopted as an IPC protocol between HDT and ONU. However, the IPC between HDT and ONU only needs simple functionality. Nevertheless, the use of complex TCP / IP protocols reduces performance in terms of message processing speed.

As described above, when the complicated TCP / IP protocol is used as the IPC protocol between the HDT and the ONU, the performance of the message processing speed is degraded.

Accordingly, an object of the present invention is to provide an IPC protocol method capable of increasing a message processing capability by a simple message processing procedure.

1 is a block diagram showing an example of a typical optical subscriber network,

2 is a block diagram of a communication protocol between a processor of a host digital terminal and an optical network unit according to an embodiment of the present invention;

3 is a protocol data unit format diagram according to an embodiment of the present invention;

4A through 4C are flowcharts of an interprocessor communication protocol according to an embodiment of the present invention;

5 is a diagram illustrating an operation in which an interprocessor communication protocol is implemented as a task according to an embodiment of the present invention;

6 is an interprocessor communication protocol implementation data structure diagram according to an embodiment of the present invention;

7 is a flowchart illustrating an interprocessor communication connection procedure of the interprocessor communication protocol task of FIG. 5 according to an embodiment of the present invention;

8 is a flowchart illustrating an interprocessor communication disconnection procedure of the interprocessor communication protocol task of FIG. 5 according to an embodiment of the present invention;

9 is a flow chart of an interprocessor communication message transmission of the interprocessor communication protocol task of FIG. 5 according to an embodiment of the present invention;

10 is a flowchart of receiving an interprocessor communication message of the interprocessor communication protocol task of FIG. 5 in accordance with an embodiment of the present invention.

In order to achieve the above object, the present invention provides a process of transmitting a data protocol data unit including an IPC message to be transmitted to a receiving side by a sender having a data transmission request between the HDT and the ONU, and the receiving side transmits a data protocol from the transmitting side. Transmitting an acknowledgment protocol data unit in response to receiving the data unit; and retransmitting the data protocol data unit if the sender fails to receive the acknowledgment protocol data unit from the receiver after transmitting the data protocol data unit. And if the transmitting side fails to receive the acknowledgment protocol data unit from the receiving side even after the transmitting side retransmits the data protocol data unit by the set number of times, processing the IPC communication fail.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following description and the annexed drawings, numerous specific details, such as specific message format or size, are set forth in order to provide a thorough understanding of the present invention, but these specific details are illustrated for purposes of explanation of the invention. This does not mean that they are limited to them. And a detailed description of known functions and configurations that may unnecessarily obscure the subject matter of the present invention will be omitted. In the following description, it should be noted that like elements represent like numerals wherever possible.

2 is a block diagram of an IPC protocol according to an embodiment of the present invention, which includes an IPCP (Interprocessor Communication Protocol) service interface 200, an IPC protocol core 202, and a MAC (Medium Access Control) service interface 204. Configure. As such, the structure of the IPCP service interface 200, the IPC protocol core 202, and the MAC service interface 204 is basically the same as in the conventional case, and the HDT 102 and ONUs 104 shown in FIG. In each of -1 to 104-n).

The IPCP service interface 200 interfaces with a task to be IPC. At this time, the interface is in the form of an IPC message, and is substantially independent of the MAC service interface 204 for transmitting or receiving a message. The IPC protocol core 202 is a block that substantially implements the IPC protocol, and processes the messages received from the IPCP service interface 200 or the MAC service interface 204 to apply the IPC protocol. The MAC service interface 204 is a part for transmitting a message, which is connected to a corresponding device driver according to a connection medium with a place where an IPC is to be transmitted, and processes an IPC message processed by the IPC protocol core 202 to the other party. Send or receive.

According to the present invention, a message used to substantially implement an IPC protocol is formed by sending and receiving in the form of a protocol data unit, that is, a PDU (Protocol Data Unit) shown in FIG. 3, and all five PDUs are used. . These five PDUs are data PDUs, urgent data PDUs, acknowledgment (hereinafter referred to as "ACK") PDUs, hello PDUs, inquiry ACK PDUs. The data PDU is used for the normal transmission of IPC messages. The emergency data PDU is used to transmit an emergency IPC message, for example, may be used for downloading a program. The ACK PDU is used for sending an ACK message from the receiving side to the transmitting side in response to receiving the data PDU. The inquiry PDU is used to inquire whether the other party operates normally when there is no data PDU to transmit and receive. The inquiry ACK PDU is used to transmit an ACK message from the receiving side to the transmitting side in response to receiving the inquiry PDU.

In FIG. 3, FIG. 3 (a) shows the format of the data PDU, and includes a PDU type field, a sequence number feed, and an information feed. 3 (b) shows the format of the emergency data PDU, which is composed of a PDU type feed and an information feed. 3 (c) shows the format of an ACK PDU, a query PDU, and a query ACK PDU, and consists of only PDU type feeds. The PDU type is 4 octets, i.e., 4 bytes, indicating which type of PDU the PDU is, and showing an example of a value assigned to the PDU type due to the PDU type. It is shown in Table 1 below. The serial number feed is also 4 octets, i.e., 4 bytes, so as to prevent a malfunction caused when the received message is received again, each PDU to be transmitted is assigned with consecutive numbers. The information feed is 6500 octets, or 6500 bytes, which is a feed containing a substantial IPC message to send and receive to the service interface.

PDU type PDU type feed value Data PDU 0x01 Emergency Data PDU 0x02 ACK PDU 0x03 Contact PDU 0x04 Contact ACK PDU 0x05

4A to 4C show a procedure diagram of an IPC protocol according to an embodiment of the present invention, which is shown in FIG. 3 above between the HDT 102 and ONUs 104-1 to 104-n of FIG. 1 described above. Each shows the procedure for IPC communication using PDU. Here, one of the sub-networks 300 and 302 corresponds to the HDT 102 and the other corresponds to one of the ONUs 104-1 to 104-n, which is relatively a transmitting side or a receiving side to avoid confusion. For convenience, it is referred to as a "sub network". 4A to 4C show an example in which the sub network 300 is a transmitting side and the sub network 302 is a receiving side among the sub networks 300 and 302.

FIG. 4A shows an example of a procedure for transmitting a conventional IPC message between sub-networks 300 and 302 according to the present invention in steps 400 and 408. The sub-network 300, which is the transmitting side of the sub-networks 300, 302, which has a data transmission request, transmits a data PDU including an IPC message to be transmitted to the counterpart, that is, the sub-network 302, which is the receiving side in step 400. At this time, the sub-network 300 starts the first timer T100 and transitions from the null state to the ACK standby state. The first timer T100 is set to, for example, 1 second. In response to the reception of the data PDU, the receiving sub-network 302 notifies the sub-network 300 that the data PDU has been well received by transmitting the ACK PDU in step 402. At this time, each time the sub network 300 transmits the data PDU, the serial number of the data PDU is increased by 1, and the sub network 302 receiving the data PDU maintains the previously received serial number. In this way, when the sub-network 302 receives the data PDU in step 400, it checks the serial number of the data PDU and checks whether the data PDU has been previously received. If a data PDU having the same serial number as the previously received data PDU is received, the sub-network 302 determines that the received data has been re-received, and does not process it. If the serial number is different, the IPC message included in the data PDU is processed. The sub-network 300, which is the transmitting side, transmits only one data PDU at a time, and does not transmit another data PDU until the ACK PDU comes.

Upon receiving the ACK PDU in step 402, the sub-network 300 terminates and transitions from the ACK wait state to the null state. If there are more IPC messages to transmit, the next data PDU is transmitted to the sub network 302 in step 404 as in step 400. If the sub network 300 does not receive the ACK PDU from the sub network 302 until the first timer T100 times out after transmitting the data PDU in step 404, the ACK wait state is maintained. In step 406, the data PDU is retransmitted and the first timer T100 is restarted. If the data PDU is retransmitted in this way, the serial number is not increased. Thereafter, if the ACK PDU is not received from the sub network 302 until the first timer T100 times out, the sub network 300 retransmits the data PDU in step 408 and restarts the first timer T100. Let's do it. In this way, when the timeout of the first timer T100 occurs up to a set number of times, for example, three times, the sub-network 300 processes the IPC fail. That is, if the transmitting side does not receive the ACK PDU from the receiving side even after retransmitting the data PDU by the set number of times, it is processed as an IPC fail and transitions from the ACK waiting state to the IPC failing state.

4B illustrates a procedure of transmitting an emergency IPC message between sub networks 300 and 302. At this time, the sub-network 300 transmits an IPC message in the form of an emergency data PDU in step 410, maintains a null state, and does not wait for reception of an ACK PDU. When the sub network 302 receives the emergency data PDU in step 410, the sub network 302 only processes the emergency IPC message without sending an ACK PDU.

4C illustrates a procedure of transmitting a query PDU between the sub-networks 300 and 302 in steps 412 to 416. If there is no data PDU to transmit and receive, a null state, an ACK wait state, an IPC fail state, and the like are shown. In all states. When there are no data PDUs to transmit and receive, the sub-networks 300 and 302 inquire the setting time of the second timer T200, for example, every 10 seconds, as in steps 412 to 414 to periodically check whether the IPC is alive. After receiving the PDU and receiving the inquiry PDU, the receiving end transmits the inquiry ACK PDU. In this case, the IPC fail process is performed when the query DU does not receive the query ACK PDU until the third timer T300, which is set to 30 seconds, times out.

Therefore, since the PDU shown in FIG. 3 described above is simply used between the HDT 102 and the ONUs 104-1 to 104-n, only the required message processing procedure is used. You can increase your abilities.

5 to 10 show a specific embodiment of the present invention as described above. First, Figure 5 shows the operation of the IPC protocol implemented as an IPC protocol task according to an embodiment of the present invention, IPC protocol task 500 and task 510 and AAL5 (ATM Adaptation Layer 5) according to an embodiment of the present invention ) Shows the related configuration between the device driver 512 and the LAN (Local Area Network) device driver 516, and the operations according to the IPC protocol are shown in the steps S1 to S8. The IPC protocol task 500 has the same data structure as that of FIG. 6 for the IPC protocol shown in FIGS. 3 and 4A to 4C and is implemented as shown in the flowchart of FIGS. 7 to 10. Task 510 represents one of a variety of tasks that require IPC in sub-networks 300, 302. The AAL5 device driver 512 and the LAN device driver 516 are device drivers for a device that transmits and receives an actual IPC message. When the connection medium between the sub-networks 300 and 302 is composed of the AAL5 device 514, the AAL5 device driver (512) is used. 512 is used and a LAN device driver 516 is used when it is made of a LAN device 518. Then, the task 510 receives the IPC message to the counterpart subnetwork to the IPC protocol task 500 through the IPC transmit queue 504, and receives the IPC message from the counterpart subnetwork in the IPC protocol task 500. The transmission of an IPC message to task 510 is via distribution queue 506, and PDU reception from AAL5 device driver 512 or LAN device driver 516 to IPC protocol task 500 is IPC received. Through queue 508. In the timer module 502, the first to third timers T100 to T300 as described above are set and started / ended by the IPC protocol task 500.

First, the case in which the IPC message to be transmitted from the task 510 is sent to the IPC transmission queue 506 will be described. At this time, the IPC protocol task 500 is activated by sending a mailbox from the task 510 as in the usual case, and the IPC protocol task 500 opens the IPC transmission queue 504 and the IPC reception queue 508. Check all. At this time, since the IPC message sent from the task 510 is in the IPC transmission queue 504, the IPC protocol task 500 receives the IPC message from the IPC transmission queue 504 in step S1, and the IPC in step S2. Convert the message to PDU format. The IPC protocol task 500 sends the PDU to the corresponding AAL5 device driver 512 or the LAN device driver 516 according to the destination of the IPC message in step S3. Start by registering at 502).

Next, a case of receiving an IPC message from a counterpart subnetwork will be described. In this case, the IPC protocol task 500 receives the PDU from the AAL5 device driver 512 or the LAN device driver 516 through the IPC reception queue 508 in step S5. At this time, the IPC protocol task 500 is activated by sending a mailbox from the AAL5 device driver 512 or the LAN device driver 516 as in a normal case, and the IPC protocol task 500 performs the IPC transmission queue 504 and the IPC. Check all receive queues 508. At this time, since there is an IPC message in the IPC reception queue 508, the IPC protocol task 500 receives the PDU from the IPC reception queue 508 in step S5, and the received PDU in FIG. To the protocol as in Fig. 4c. At this time, the timer registered in step (S4) is terminated in step (S7), and the received PDU is sent to the task 510 through the distribution queue 506 in step (S8) in the form of an IPC message.

FIG. 6 illustrates a data structure for performing a procedure according to the flowcharts of FIGS. 7 to 10 of the IPC protocol task 500 described above. FIG. 6 (a) to FIG. 6 (c) 2 is provided in the IPCP service interface 200 of FIG. 2, FIG. 6 (d) is provided in the IPC core 202 of FIG. 2, and FIGS. 6 (e) and 6 (f) are the MAC service interface of FIG. 2. 204 is provided.

6 (a) shows the link user manager 600, “linkUserManager [MAX_SUBNET].” The link user manager 600 has as many link user entities as the number of subnetworks to be IPC. The link user entity is assigned 1 per subnetwork when it is connected. 6 (b) shows a “LinkUserEntity” which is a link user entity 602. The connection flag "connFlag" (connection flag) of the link user entity 602 is a variable used to check whether the connection is established. The link user "linkUser" is a pointer to the link user 604 shown in Fig. 6C. FIG. 6 (c) shows the link user 604, "LinkUser", where "next" and "prev" (previous) are information according to a linked list type implementation, and "linkProvider" is shown in FIG. is a pointer to the link provider 606 shown in d), and " subnet " (subnetwork) is information for distinguishing a connected subnetwork, a connection method, and a subnetwork, for example, a virtual path identifier (vpi) / vci ( virtual path identifier).

6 (d) shows a link provider 606, “LinkProvider”. Here, "next" and "prev" are information according to a linked list type implementation, and "linkUser" is a pointer to a link user. "ipcSapId" (IPC Service Access Point Identification) is an identification (ID) that distinguishes a function to be processed according to an event generated and an associated connection. The "macProvider" (MAC provider) is a pointer to the MAC provider 608 shown in Fig. 6E. "linkState" represents the state of the current connection. "waitingQ" (waiting queue) is a queue for buffering when there is a PDU to send to the connection in the ACK waiting state after sending the PDU to the connection. "txSeqNum" (transmit sequence number) is a variable that maintains a serial number previously sent to fill a serial number when sending a data PDU, and is incremented by one after sending the data PDU. A "rxSeqNum" (receive sequence number) is a variable that maintains the serial number of a previously received data PDU to determine whether the received data PDU is a previously received data PDU when the data PDU is received. "retransmitCnt" (retransmit count) is a variable that maintains the number of retransmissions for retransmission IPC fail processing when the first timer T100 times out and retransmits. "currentTxdata" (current transmit data) is for buffering previously sent data for retransmission of previously sent data upon retransmission.

6 (e) shows a MAC provider 608, "MacProvider", which manages a device driver connected to a sub-network to communicate with. The MAC provider 608 may have various forms such as an AAL5 provider, a high-level data link control (HDLC) provider, and the like. In Fig. 6 (e), an example is an AAL5 provider as shown in Fig. 6 (f). FIG. 6 (f) shows a case where the MAC provider 608 has two AAL5 providers 610 and 612 "Aal5Provider". "next" and "prev" are information according to a linked list type implementation, and "subnetType" determines a connection method, that is, a device driver, with a connected subnetwork. "macUser" is a pointer to the connection link provider 606. "MacSapId" (MAC Service Access Point Identification) is an ID for identifying a function to be processed according to the generated event. "subnet" is information for identifying a subnetwork, and is an ID of a path to a corresponding subnetwork of the determined device driver. For example, AAL5 is vpi / vci. "Aal5SapId" (AAL5 Service Access Point Identification) is an AAL5 provider distinguished ID that indicates which AAL5 provider to pass AAL5 received from a particular vpi / vci to the AAL5 providers 610 and 612.

Now, a procedure according to the operation of the IPC protocol task 500 having the data structure as shown in FIG. 6 will be described with reference to FIGS. 7 to 10. Referring to FIG. 7, which shows a procedure for requesting an IPC connection as steps 700 through 716, the IPC protocol task 500 performs IPC on a specific sub network as shown in step S1 of FIG. 5 in step 700. Verify the connection by receiving a message requesting a connection. At this time, it is checked in step 702 whether the connection requested subnetwork exists in the link user manager 600 of FIG. If it does not exist, an IPC impossible error is processed in step 704. Otherwise, in step 706, it is checked whether the connection flag connFlag of the link user entity 602 of FIG. 6 (b) is active. If the connection flag connFlag is active, the connection is already connected and the connection is completed in step 716. Otherwise, if the connection flag connFlag is not active, the connection flag connFlag of the link user entity 602 of FIG. 6 (b) is activated in step 708, and the link user 604 of FIG. 6 (c) is generated and initialized. Request the connection of the IPC message, change the contents of the link user 604 in FIG. After generating and initializing the link provider 606 of FIG. 6 (d) in step 710, the form for generating the MAC provider 608 according to the sub-network is determined in step 712. Thereafter, in step 714, the device provider is generated and initialized according to the method of connecting to the sub-network, that is, the device driver type, and the second and third timers T200 and T300 are started. do. In this case, AAL5 generates and initializes the AAL5 providers 610 and 612 of FIG. 6 (f).

Next, referring to FIG. 8, which shows a procedure for requesting an IPC disconnection in steps 800 through 814, the IPC protocol task 500 is performed in step 800 from step 800 in step S1. Verify the connection connection by receiving a message requesting IPC disconnection. In this case, it is checked in step 802 whether the disconnected subnetwork exists in the link user manager 600 of FIG. If it does not exist, an error is handled in step 804. Otherwise, in step 806, it is checked whether the connection flag connFlag of the link user entity 602 of FIG. 6 (b) is active. If the connection flag connFlag is not active, the connection is not present. Therefore, the connection is completed in step 814. In contrast, if the connection flag connFlag is active, in step 808, the link user information linkUser of the link user entity 602 of FIG. 6 (b) is found from the link user information linkUser of FIG. The link provider 606 of FIG. 6 (d) is found from the link provider information linkProvider, and the MAC provider information macProvider of the link provider 606 is found, and the AAL5 provider of FIG. 6 (f) which is a device provider. After deleting 610, the AAL5 provider 610 uses MAC user information macUser to find the link provider 606 of FIG. 6 (d). Next, in step 810, the second timer T200 is terminated, the link provider 606 of FIG. 6 (d) is deleted, and the link 6 (b) is linked using the link user information linkUser of the link provider 606. Visit user entity 602. Thereafter, in step 812, the connection flag connFlag of the link user entity 602 is nonactive and the link user 604 is deleted through the link user information linkUser, and the connection is completed in step 814.

Next, referring to FIG. 9, which shows a procedure for transmitting an IPC message in steps 900 and 918, the IPC protocol task 500 requests IPC transmission as in step S1 of FIG. 5 in step 900. Receive the message and confirm the connection connection. At this time, it is checked in step 902 whether the sub-network required to transmit the IPC message exists in the link user manager 600 of FIG. If it does not exist in step 904, IPC impossible error processing. Otherwise, in step 906, it is checked whether the connection flag connFlag of the link user entity 602 of FIG. 6 (b) is active. If the connection flag connFlag is not active, the connection is not connected and an error is processed in step 908. On the contrary, if the connection flag connFlag is active, in step 910, the destination of the IPC message is viewed and the content of the link user 604 of FIG. 6 (c) is inserted. Then, the content of the message and the subnetwork and link user 604 are inserted. Pass the link provider information linkProvider. In operation 912, the IPC message is configured in the form of a data PDU, and the contents of the link provider 606 of FIG. 6 (d) are applied to the protocol. After that, the MAC provider information macProvider of the link provider 606 is changed. Passes address, subnetwork, and data PDUs. Next, in step 914, it is determined which type of provider the data PDU is to use according to the sub-network, and in step 916, the AAL5 device driver 512 is determined according to the type of device driver connected to the sub-network. The PDU is transmitted to the corresponding device driver among the LAN device drivers 516, and the start of the first timer T100 is terminated at step 918.

Lastly, referring to FIG. 10, which shows a procedure to be processed when an IPC message is received, in steps 1000 through 1018, the IPC protocol task 500 performs an AAL5 device as shown in S5 of FIG. 5 in step 1000. After receiving the PDU from the corresponding device driver among the driver 512 and the LAN device driver 516 and identifying the type of FIG. 6 (e) with the subnetwork type information subnetType and SapId, the AAL5 pro of FIG. The AAL5 SAP ID information Aal5SapId of the providers 610 and 612 is searched to check whether the corresponding connection exists in step 1002. If it does not exist, an error is processed in step 1004. Otherwise, in step 1006, the received PDU with the address of the AAL5 provider is sent. In step 1008, the contents of the received PDU are analyzed to confirm the serial number, and then compared with the received serial number rxSeqNum of FIG. If the same, the received PDU is discarded in step 1010 because it is a previously received IPC message. On the other hand, if it is not the same, it is checked whether the received PDU is an ACK PDU in step 1012, and if it is an ACK PDU, the first timer T100 is terminated in step 1014. If it is not the ACK PDU, in step 1016, the ACK PDU is transmitted and the contents of the link provider 606 of FIG. 6 (d) are changed, that is, the update of the received serial number rxSeqNum, the link state information linkState, and the like are distributed. Transfer to queue 506 and end at step 1018.

As described above with reference to FIGS. 5 to 10, the IPC protocol of the present invention shown in FIGS. 4A to 4C is performed by managing and transmitting an IPC message as one task 500. Since the IPCP service interface 200, the IPC protocol core 202, and the MAC service interface 204 shown in Fig. 2 have module independence, they can process any other type of IPC message. In addition, depending on the connection medium, it has the flexibility to easily connect only by implementing the device driver.

Meanwhile, in the above description of the present invention, specific embodiments have been described, but various modifications can be made without departing from the scope of the present invention. Particularly, in the embodiment of the present invention, although both the normal transmission of the IPC message and the emergency IPC message transmission were included, the inquiry was periodically included. However, the present invention may be selectively applied as necessary. Therefore, the scope of the invention should not be defined by the described embodiments, but should be defined by the equivalent of claims and claims.

As described above, the present invention has the advantage that the message processing capability can be increased by realizing the IPC by a simple message processing procedure without using a complicated TCP / IP protocol between the HDT and the ONU.

Claims (10)

A communication protocol method between the host digital terminal and the processor of the optical network unit in an optical subscriber distribution network having a host digital terminal and a plurality of optical network units connected thereto. Transmitting a data protocol data unit including an interprocessor communication message to be transmitted to a receiving side of a counterpart by a transmitting side having a data transmission request between the host digital terminal and the optical network unit; Transmitting an acknowledgment protocol data unit in response to the receiving side receiving the data protocol data unit from the transmitting side; Retransmitting the data protocol data unit if the transmitting side fails to receive the acknowledgment protocol data unit from the receiving side after transmitting the data protocol data unit; And if the transmitting side fails to receive the acknowledgment protocol data unit from the receiving side even after the transmitting side retransmits the data protocol data unit by a set number of times, an inter-process communication failing process. . The method of claim 1, wherein the data protocol data unit, A protocol data unit type feed indicating the data protocol data unit; A serial number feed to which serial numbers sequentially assigned to data protocol data units continuously transmitted according to the interprocess communication message are assigned; And an information feed to which data of the interprocess communication message is allocated. 3. The method according to claim 2, wherein said acknowledgment protocol data unit consists only of a protocol data unit type feed indicating that said acknowledgment protocol data unit. The method of claim 1, Transmitting an emergency data protocol data unit including an interprocessor communication message to be transmitted from the host digital terminal and the optical network unit to a receiving party having an urgent data transmission request to a receiving party of the other party; And receiving, by the receiving side, the emergency data protocol data unit from the transmitting side, and processing the inter-processor communication protocol. The method of claim 4, wherein the data protocol data unit, A protocol data unit type feed indicating the data protocol data unit; A serial number feed to which serial numbers sequentially assigned to data protocol data units continuously transmitted according to the interprocess communication message are assigned; And an information feed to which data of the interprocess communication message is allocated. The method of claim 5, wherein the emergency data protocol data unit, A protocol data unit type feed indicating the emergency data protocol data unit; And an information feed to which data of the interprocess communication message is allocated. 7. The method according to claim 6, wherein said acknowledgment protocol data unit consists only of a protocol data unit type feed indicating that said acknowledgment protocol data unit. A communication protocol method between the host digital terminal and the processor of the optical network unit in an optical subscriber distribution network having a host digital terminal and a plurality of optical network units connected thereto. Transmitting a data protocol data unit including an interprocessor communication message to be transmitted to a receiving side of a counterpart by a transmitting side having a data transmission request between the host digital terminal and the optical network unit; Transmitting an acknowledgment protocol data unit in response to the receiving side receiving the data protocol data unit from the transmitting side; Retransmitting the data protocol data unit if the transmitting side fails to receive the acknowledgment protocol data unit from the receiving side after transmitting the data protocol data unit; If the transmitting side fails to receive the acknowledgment protocol data unit from the receiving side even after retransmitting the data protocol data unit by a set number of times, processing as an interprocess communication fail; Transmitting a query protocol data unit to a counterpart at a predetermined time interval when there is no data PDU transmitted and received between the host digital terminal and the optical network unit; Receiving the inquiry protocol data unit, transmitting the inquiry acknowledgment protocol data unit in response to the inquiry protocol data unit whenever it is received; And the transmitting side of the inquiry protocol data unit is configured to process the inter-process communication fail if the inquiry acknowledgment protocol data unit is not received within a predetermined time. The method of claim 8, wherein the data protocol data unit, A protocol data unit type feed indicating the data protocol data unit; A serial number feed to which serial numbers sequentially assigned to data protocol data units continuously transmitted according to the interprocess communication message are assigned; And an information feed to which data of the interprocess communication message is allocated. 10. The apparatus of claim 9, wherein the acknowledgment protocol data unit, the inquiry protocol data unit, and the inquiry acknowledgment protocol data unit are respectively the acknowledgment protocol data unit, the inquiry protocol data unit, and the inquiry acknowledgment protocol data unit. An inter-processor communication protocol method comprising only a protocol data unit type feed indicating.