KR100469745B1 - Apparatus and method for allocating multiplexing ids to nodes in a finite-sized communication system - Google Patents

Abstract

An apparatus and method for efficiently allocating nodes to nodes in a network by varying a size of a multiplexing identifier according to a network size in a communication network including a plurality of nodes are disclosed. The apparatus for allocating a multiplexing identifier according to an embodiment of the present invention includes an input / output interface unit for relaying signals transmitted and received with each node, and the multiplexing identifier for allocating the multiplexing identifiers for each node. And a memory capable of storing the number of the multiplexed identifiers and a multiplexed identifier that is not assigned to a specific node from the memory when the multiplexed identifier allocation request message is received from a predetermined node. It is provided through an interface unit, characterized in that it comprises a control unit for changing the state whether the memory allocation.

Description

Apparatus and Method for Assigning Multiplexed Identifiers in Finite Scale Communication Networks {APPARATUS AND METHOD FOR ALLOCATING MULTIPLEXING IDS TO NODES IN A FINITE-SIZED COMMUNICATION SYSTEM}

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an interprocess communication (IPC) communication technology in an IP (Internet Protocol) based communication system. In particular, in a finite scale communication network composed of a limited number of nodes, MUX_ID (Multiplexing ID) is assigned to each node. An apparatus and method for efficiently allocating.

In the TCP / IP communication technology, a combination of an Internet protocol (IP), which is a network layer protocol, and a transmission control protocol (TCP), or a user datagram protocol (UDP), are used. Send and receive data. In TCP, communication is initiated after establishing a session (connection). In UDP, data is sent to the other address without establishing a session. The characteristic of UDP is that protocol processing is fast. However, there is no error correction or retransmission function like TCP, and it is partially used in multimedia applications requiring faster speed than reliability.

UDP serves only a limited service when messages are exchanged between computers in a network using IP. UDP is an alternative to TCP and sometimes referred to as UDP / IP when used with IP. Like TCP, UDP uses IP to receive the actual data units called datagrams from one computer to another. However, unlike TCP, UDP does not provide services such as dividing a message into packets (i.e., datagrams), reassembling on the other side, and in particular does not provide an order of arriving data packets. This means that applications using UDP must be able to verify that the entire message has arrived in the correct order. For network applications with very little data to exchange (and therefore very few messages to reassemble), UDP may be preferable to TCP for faster processing. UDP provides two services that are not provided in the IP layer. One is a port number for distinguishing other user requests, and a checksum function for checking whether the data arrives corrupted.

UDP and TCP, which are commonly used in IP technology, are inadequate for direct use in IP-based mobile communication systems. UDP is inadequate in that transmission is too unreliable. In the case of TCP, too many connections can be made for the operating system to handle, and features such as flow control, congestion control, and keep alive check can cause performance degradation.

In order to solve these problems, a form of providing reliability to UDP is a reliable UDP method. In one implementation of a resilient UDP, a MUX_ID, a sequence number, and an ACK number (acknowledge), which are relatable header fields for identifying communication end-points that share a UDP socket. number, fragment number, etc. to distinguish between communication endpoints sharing UDP sockets, retransmit, acknowledge, duplication check, split / reassembly It provides reliability to UDP by performing functions such as segmentation / re-assembly).

1 is a diagram illustrating a relatable UDP communication scheme according to the prior art.

Referring to FIG. 1, node 1 (100) and node 2 (110) transmit packet data to node 3 (120) using relatable UDP header (102) and relatable UDP header (112), respectively. The node 3 120 attempts to receive the packet data by interpreting the received relatable UDP header and storing it in the reception queue 122 for each multiplexing identifier.

However, since the length of the multiplexing identifier is fixed regardless of the size of the network in the conventional relatable UDP communication as described above, a bit may be wasted when the network size is small. In addition, if the length of the multiplexing identifier is unnecessarily long, the size of the relayable UDP packet to be transmitted and received increases, thereby increasing the overall amount of traffic and preparing to manage each flow separated by the multiplexing identifier at the transmitting and receiving end. You will also have the overhead of For example, if the length of the multiplexing identifier is 32 bits, the transmittable UDP protocol layer must be prepared for processing for 2 ³² flows. In addition, in the conventional flexible UDP communication, since multiplexing identifiers are randomly allocated to communication nodes, a same multiplexing identifier may be repeatedly allocated to several communication nodes, and a collision may occur. The transmitting node must first exchange control messages with the transmitting node before actually sending the data to the receiving node.

In summary, in the conventional relatable UDP communication, since a fixed length multiplexing identifier is assigned without using a predetermined policy, a conventional relatable UDP communication method is used in a mobile communication system constituting a finite scale network. The problem is that it is inefficient in terms of both traffic and protocol implementation.

Accordingly, an object of the present invention is to provide an apparatus and method for allocating a multiplexing identifier of a length suitable for the size of a network in order to reduce the amount of traffic in a finite scale communication network using a relatable UDP.

Another object of the present invention is to provide an apparatus and method for managing and assigning multiplexing identifiers to nodes in order to prevent communication collisions between nodes in a finite scale communication network using a relatable UDP.

An apparatus for allocating a multiplexed identifier according to an embodiment of the present invention for achieving the above objects comprises a predetermined number of nodes and each node in a finite scale communication system using a reliable UDP. An apparatus for allocating a multiplexing identifier to a terminal, the apparatus comprising: an input / output interface unit for relaying a signal transmitted and received with each node, and multiplexing identifiers defined according to sizes of the nodes and assigned to the respective nodes. And a memory having a table, and a control unit reading a multiplexing identifier corresponding to the predetermined node from the memory and providing the multiplexing identifier corresponding to the predetermined node to the predetermined node through the input / output interface unit. It is done.

According to another aspect of the present invention, there is provided an apparatus for assigning multiplexing identifiers, including an input / output interface unit for relaying signals transmitted and received with each node, and defined according to the size of each node and assigned to each node. A memory having at least the number of nodes for storing the multiplexing identifier and storing the assignment of the multiplexing identifier, and a multiplexing identifier not allocated to a specific node from the memory upon receiving a multiplexing identifier allocation request message from a predetermined node; It is characterized in that it comprises a control unit for assigning to the node to provide through the input and output interface unit and to change the state of the allocation of the memory.

The multiplexing identifier allocation method according to an embodiment of the present invention for achieving the above objects, the multiplexing identifier is defined according to the size of each node, represented by the minimum number of binary bits required to distinguish each of the nodes Storing each node, and if each node requests allocation of a multiplexing identifier, reading the stored multiplexing identifier corresponding to each node and providing the same to each node.

1 is a diagram illustrating a relatable UDP communication scheme according to the prior art.

2 illustrates a structure of a finite scale communication network according to an embodiment of the present invention.

3 is a diagram illustrating a configuration of the multiplexed identifier assignment server 200 of FIG. 2.

4 is a diagram illustrating a relatable UDP communication scheme in a finite scale communication network according to an embodiment of the present invention.

5 is a diagram illustrating a booting procedure for each node of a finite scale communication network to be assigned a multiplexing identifier from a multiplexing identifier allocation server according to an embodiment of the present invention.

FIG. 6 is a diagram illustrating a message exchange procedure between a Config server and a DHCP server when the DHCP client is executed in FIG. 5.

FIG. 7A is a diagram illustrating a procedure of processing a resolved UDP packet at a transmitting end according to an embodiment of the present invention. FIG.

FIG. 7B is a diagram illustrating a procedure of processing a resolved UDP packet at a receiving end according to an embodiment of the present invention. FIG.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the reference numerals to the components of the accompanying drawings, the same reference numerals and symbols are assigned to the same components as much as possible, even if displayed on different drawings. In the following description of the present invention, detailed descriptions of well-known functions and configurations that may obscure the gist of the present invention will be omitted.

The present invention aims to reduce the amount of traffic and the implementation burden by determining the size of the multiplexed identifier according to the network size using the relievable UDP and assigning the managed identifier in the basic procedure of the mobile communication system.

The relatable UDP communication method of the present invention is composed of a process of assigning a multiplexed identifier by a Config Server and a process of implementing a relatable UDP protocol. In the present invention, the relatable UDP may be a general relatable UDP protocol stack or may be a protocol stack tailored to IPC requirements of a mobile communication system. The Config Server may coexist in a DHCP server such as a Dynamic Host Configuration Protocol (DHCP) server involved in the booting process of the mobile communication system. DHCP is defined in RFC 1541 as a communication protocol for automatically allocating and managing configuration information necessary for executing TCP / IP communication. DHCP provides a uniform management service for IP addresses in a communication network in a TCP / IP environment.

FIG. 2 is a diagram illustrating a structure of a finite scale communication network according to an embodiment of the present invention, and illustrates the case where the number of nodes constituting the network is five except for the multiplexed identifier assignment server 200.

Referring to FIG. 2, a finite scale communication network according to an embodiment of the present invention communicates with each other by being assigned a multiplexing identifier allocation server 200 that manages allocation of multiplexing identifiers, and a multiplexing identifier from the server 200. Nodes 1 to 5 (210 to 250) are performed. The multiplexed identifier assignment server 200 is in the form of a Config Server.

3 illustrates a configuration of the multiplexed identifier assignment server 200 of FIG. 2.

Referring to FIG. 3, the multiplexed identifier assignment server 200 includes an I / O interface 301, a signal processor 303, a CPU 305, and a memory 307. In describing the roles of these components, the I / O interface 301 serves as an interface for inputting user data or for requesting assignment of multiplexing identifiers to each node in a network during booting. Do this. The signal processing unit 303 processes and outputs a signal from the I / O interface 301 and a signal from the CPU 305. The CPU 305 controls the overall operation of the multiplexed identifier allocation server 200, and in particular, the memory 307 stores the data input by the user in the memory 307 and the memory upon receiving the multiplexed identifier allocation request message from each node in the network. The multiplexing identifier stored in 307 is read and assigned to each node. The user determines the minimum number of binary bits required to distinguish nodes existing in the network, allocates a multiplexing identifier represented by the determined number of binary bits to each node, and stores the multiplexing identifier in each memory. For example, when the number of nodes existing in the network is five as shown in FIG. 2, the minimum number of bits is three and the multiplexing identifier assigned to each node is three bits of information. In this case, 3 (= 2 ^3-5 ) unused multiplexing identifiers may be allocated to the nodes if there are nodes added to the network.

Unlike the above, in order to automatically assign a multiplexing identifier without user intervention, the multiplexing identifier allocation server 200 may include an input / output interface unit for relaying signals transmitted and received with each of the nodes, and the multiplexing for allocating to each node. A memory having an identifier greater than or equal to the number of nodes and storing whether to assign the multiplexing identifier, and a multiplexing identifier not allocated to a specific node from the memory when the multiplexing identifier allocation request message is received from a predetermined node; The controller may be provided through the input / output interface unit and change the state of allocation of the memory.

4 is a diagram illustrating a relatable UDP communication scheme in a finite scale communication network according to an embodiment of the present invention.

In FIG. 4, five nodes (the first node 410, the second node 420, and the third node 430) are not illustrated except for the multiplexed identifier allocation server 400. In this case, the multiplexing identifier is represented by 3 bits according to the number of nodes.

Referring to FIG. 4, the first node 410 and the second node 420 each include a releasable UDP including a multiplexed identifier respectively allocated from the multiplexed identifier allocation server 400 as shown in FIG. 3. The packet data is transmitted to the third node 430 using the header 411 and the relatable UDP header 421, and the third node 430 interprets the received relatable UDP header to receive a queue. Packet data is received in a manner of storing for each multiplexing identifier at 431.

Since the size of the multiplexing identifier is determined according to the number of nodes constituting the network and the multiplexing identifier of that size is allocated and used from one allocation server, the relay of FIG. Unlike the conventional UDP communication method shown in FIG. 1, the full UDP communication method can prevent collision between multiplexing identifiers and waste of bits.

FIG. 5 is a diagram illustrating a booting procedure for each node in a network to be assigned a multiplexing identifier from a multiplexing identifier allocation server in a finite scale communication network according to an embodiment of the present invention. FIG. 5 illustrates an example in which each node uses an PPC processor and a Linux OS to execute an application program by allocating an IP address through DHCP.

Referring to FIG. 5, each node in the network first executes a PPC (Power PC) Booter when the power is turned on (step 502). Then, start the kernel (step 504), mount the root file system, run the initialization script (step 506), and up the network interface (508). In step 512, a DHCP client is executed to obtain an IP address and a multiplexing identifier (step 510), a network interface is configured (step 512), and finally, each application image is downloaded and an application program is executed. (Step 514).

FIG. 6 illustrates a message exchange procedure between a DHCP client and a DHCP server when the DHCP client is executed in FIG. 5. Each node knows the size of the multiplexing identifier and the multiplexing identifier assigned to it from the mux_id_size and mux_id option fields of the DHCP ACK message.

Referring to FIG. 6, first, the DHCP client 601 broadcasts a DHCP DISCOVER message 612 to find out a DHCP server that can be initialized and used in step 610. Then, in step 614, the DHCP server 603 determines the configuration and sends a DHCP OFFER message 616 to the DHCP client 601 to respond. In step 618, the DHCP client 601 selects Configuration and sends a DHCP REQUEST message 620 to the DHCP server 603. Then, the DHCP server 603 sends a DHCP ACK message 624 to the DHCP client 601 after allowing the configuration in step 622. This DHCP ACK message 624 includes mux_id_size and mux_id option fields so that each node can know the multiplexing identifier and the size of the multiplexing identifier assigned to it. Through these steps, the DHCP client completes the initialization in step 624. If the DHCP client 601 sends a DHCP RELEASE message 628 to the DHCP server 603 at shutdown in step 626, the DHCP server 603 terminates the DHCP procedure in step 630.

FIG. 7A illustrates a procedure for processing a releaseable UDP packet at a transmitting end according to an embodiment of the present invention, and FIG. 7B illustrates a procedure for processing a releaseable UDP packet at a receiving end.

Referring to FIG. 7A, the transmitting end first requests to transmit an IPC message (step 702), configures a removable UDP header using a multiplexing identifier at initialization (step 704), and stores a packet in a TX queue. In step 706, a UDP packet is transmitted (step 708), and in step 710, an ACK is received. If the ACK is received in step 710, the transmission is completed (step 712). If no ACK is received, the process proceeds to step 708 again to retransmit.

Referring to FIG. 7B, the receiving end first receives a UDP packet transmitted by the transmitting end (step 752), and in step 754, analyzes the relievable UDP header, and proceeds to step 756 to check whether the packet is repeatedly received. . If duplicate reception in step 756 proceeds to step 758 and discards the packet. If it is not duplicated in step 756, the sequence number is stored for each multiplexing identifier (step 760), and an ACK is transmitted to the transmitting end (step 762), and finally, the IPC message is received (step 764).

The relatable UDP communication method of the present invention described above may be divided into a process of allocating a multiplexing identifier to a node when a node is booted, and a process of operating the relatable UDP protocol based on the multiplexing identifier assigned to the nodes. . These processes will be described in detail by taking a base station (BS) system in a mobile communication system as an example.

First, the process of allocating the multiplexing identifier will be described. First, the multiplexing identifier allocation server determines the size of the multiplexing identifier according to the size of the network to use the relatable UDP. For example, in a mobile communication system, a BS is composed of a limited number of base station controllers (BSCs) and base station transceiver subsystems (BTSs), in which case the communication between the boards of the BSC and the BTS is performed. This should be done. The application layer of each board sends and receives messages, and there are times when it is necessary to choose to use the relatable UDP to send messages of a certain nature. If there are 12 BSCs, 64 BTSs per BSC, and 30 boards for each BSC and BTS, messages must be exchanged using a relatable UDP between a total of 23040 (= 12x64x30) boards. In this case, the minimum number of bits required to represent 23040 boards is 15 bits, but the number of multiplexing identifiers is 65536 (= 2 ¹⁶ ) for the scalability of the network.

Then, the DHCP server configures a pool of multiplexed identifiers as well as an IP address pool that manages the IP addresses to be assigned to each node. In IP-based BS systems, each board's IP is assigned dynamically or semi-statically, and a DHCP server is usually provided for that assignment. The Config server mentioned in the present invention may be regarded as an extension of the DHCP server. The Config server also provides the multiplexing identifier determined in the multiplexing identifier sizing process when each board is loaded to provide an IP address, a subnet mask, and the like. Therefore, multiplexing identifier information needs to be set when configuring the DHCP server environment. The general DHCP server configuration is shown below. The following is an example where the board with MAC address 08: 00: 2b: 4c: 59: 23 throws a DHCP request message and responds with a DHCP Ack message containing the IP address of 192.168.1.222.

host haagen {

hardware ethernet 08: 00: 2b: 4c: 59: 23;

fixed-address 192.168.1.222;

}

Setting of the DHCP server according to the present invention is as follows. In addition to the IP address, the DHCP Ack is sent with the multiplexing identifier size (mux_id_size) that the board will use. The multiplexing identifier size or multiplexing identifier can be defined in a vendor-specific DHCP option field (see RFC-1533).

host haagen {

hardware ethernet 08: 00: 2b: 4c: 59: 23;

fixed-address 192.168.1.222;

mux_id_size 16

mux_id 0x0001

}

Other settings of the DHCP server may be configured as follows.

option mux_id_size 8

subnet 192.168.1.0 netmask 255.255.255.0 {

range 192.168.1.1 192.168.1.128;

option mux_id_range 1 128

}

The above configuration allows the DHCP server to pass unused IP addresses and multiplexing identifiers among the IP addresses between 192.168.1.1 and 192.168.1.128 to the DHCP Ack when it receives a DHCP request from a board in the area managed by this DHCP server. The configuration file may vary depending on the type of the DHCP server. This configuration can be seen as an example of a DHCP server configuration that can give extensibility to assign remaining multiplexing identifiers to newly added boards among the multiplexing identifiers that can be created by mux_id_size.

After the above configuration, as shown in FIG. 5, a multiplexing identifier is also assigned along with the IP address at each node boot of the system.

Next, a description will be given of the process of using the relatable UDP protocol.

After completing the process of assigning the multiplexing identifier as described above, in order to send the message using the relatable UDP, the transmitting end fills the relatable UDP header with the multiplexing identifier previously assigned to the sending UDP socket and puts the packet in the TX queue. send. The operation of the relatable UDP is performed by using the TX queue and the RX queue. The packet is sent from the transmitter to the TX queue, and the receiver is put into the RX queue.

When the ACK arrives within a predetermined time, the transmitting end removes the packet stored in the transmission queue and finishes the releasing transmission. In the TX queue, a packet is retransmitted for which an ACK has not been received within a predetermined time. The receiving end classifies communication peer end points based on the multiplexing identifier and configures an RX queue for each end point. If the packet arriving at the receiving end is a new packet, the packet is put in the RX queue corresponding to the multiplexing identifier of the received packet, and the ACK is sent to the peer end point. If the packet arriving at the receiving end is a duplicate packet, the packet is discarded.

Comparing the prior art and the present invention based on the above-described bar is as follows.

The prior art uses a fixed length (eg 32-bit) multiplexing identifier for Mux / Demux of relatable UDP packets, but in the present invention, the size of the multiplexing identifier depends on the size of communication boards that need to use the relatable UDP. By setting this, it is possible to reduce the amount of network traffic in a small network.

In addition, in the prior art, since the multiplexing identifier is larger than necessary, an address space made of the multiplexing identifier is larger than necessary so that overhead may be generated for processing at the receiving side. In other words, the receiving end should configure more receive queues than necessary. In the present invention, this overhead can be reduced by determining the required size of multiplexed identifiers.

In addition, in the prior art, when a multiplexing identifier is generated almost randomly and a multiplexing identifier collides, a field is added to a releaseable UDP header to overcome this problem, and a control message is exchanged to avoid a collision between a transmitting end and a receiving end. The invention eliminates the need to exchange control fields with header fields for control by managing multiplexed identifier assignment. That is, the present invention can reduce the amount of traffic in the network through allocation management of multiplexing identifiers, and eliminate the time taken to start message exchange using the relatable UDP.

Meanwhile, in the detailed description of the present invention, specific embodiments have been described, but various modifications are possible without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined not only by the scope of the following claims, but also by the equivalents of the claims.

As described above, the present invention allocates a multiplexing identifier of a size that is variably defined according to the size of a network in a finite scale communication network to each node of the network, thereby improving efficiency in terms of both traffic and protocol implementation compared to the prior art. Can be increased. Specifically, by reducing the size of the multiplexing identifier, it is possible to reduce the amount of IPC traffic, reduce the processing overhead of the receive-relayable UDP stack, and resolve collisions of the multiplexing identifier in the relatable UDP layer. This can eliminate the overhead of sending and receiving control messages.

Claims (5)

An apparatus for allocating a multiplexing identifier to each node in a finite scale communication system composed of a predetermined number of nodes and using a reliable UDP. An input / output interface unit for relaying signals transmitted and received with each node; A memory defined according to the size of each node and having the multiplexing identifier for assigning to each node to the number of nodes or more and storing whether the multiplexing identifier is allocated; And a control unit for allocating a multiplexing identifier that is not assigned to a specific node from the memory to the node and providing the multiplexing identifier assignment request message from a predetermined node to the node and changing the state of allocation of the memory. The apparatus described above. An apparatus for allocating a multiplexing identifier to each node in a finite scale communication system composed of a predetermined number of nodes and using a reliable UDP. An input / output interface unit for relaying signals transmitted and received with each node; A memory defined according to the size of each node and having a table including multiplexing identifiers assigned corresponding to the nodes; And a control unit which reads a multiplexing identifier corresponding to the predetermined node from the memory and provides the multiplexing identifier assignment request message to the predetermined node through the input / output interface unit. In a finite scale communication system composed of a predetermined number of nodes and using reliable UDP, a method of assigning a multiplexing identifier to each node, Storing a multiplexing identifier defined for the size of each node and represented by a minimum number of binary bits required to distinguish each node for each node; And when each node requests allocation of a multiplexing identifier, reading the stored multiplexing identifier corresponding to each node and providing the multiplexing identifier to each node. In the method for transmitting and receiving data between the nodes in a finite scale communication system consisting of a predetermined number of nodes and using a reliable UDP Allocating a multiplexing identifier for each node defined by a size of each node and represented by a minimum number of binary bits required to distinguish the nodes; And transmitting and receiving data between the nodes using the assigned multiplexing identifier. The method of claim 4, wherein the multiplexing identifier assignment process comprises: Storing a multiplexing identifier represented by the minimum number of binary bits for each node, for each node; And when each node requests allocation of a multiplexing identifier, reading out and storing the stored multiplexing identifier corresponding to each node to each node.