KR20160018110A - Method for transmitting and receiving data according to hdlc protocol - Google Patents

Method for transmitting and receiving data according to hdlc protocol Download PDF

Info

Publication number
KR20160018110A
KR20160018110A KR1020140102222A KR20140102222A KR20160018110A KR 20160018110 A KR20160018110 A KR 20160018110A KR 1020140102222 A KR1020140102222 A KR 1020140102222A KR 20140102222 A KR20140102222 A KR 20140102222A KR 20160018110 A KR20160018110 A KR 20160018110A
Authority
KR
South Korea
Prior art keywords
data frame
packet
header
data
footer
Prior art date
Application number
KR1020140102222A
Other languages
Korean (ko)
Inventor
조성동
Original Assignee
엘지전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Priority to KR1020140102222A priority Critical patent/KR20160018110A/en
Publication of KR20160018110A publication Critical patent/KR20160018110A/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0045—Arrangements at the receiver end
    • H04L1/0047—Decoding adapted to other signal detection operation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Communication Control (AREA)

Abstract

An HDLC transmitter for generating a packet data frame for transmitting a data packet, generating a header data frame and a footer data frame through encoding for the data packet, and transmitting the packet data frame, the header data frame, and the footer data frame as a byte stream A header data frame is detected through HDLC decoding of the byte stream, a packet data frame is detected based on the header data frame, a packet data frame is detected following the packet data frame, and a packet data frame is reconstructed A receiving method of an HDLC receiver is disclosed.

Figure P1020140102222

Description

TECHNICAL FIELD [0001] The present invention relates to a method of transmitting and receiving data according to an HDLC protocol,

The present invention relates to a method for transmitting packet data in a byte stream according to the HDLC protocol and a method for receiving packet data transmitted in a byte stream.

The High-level Data Link Control (HDLC) protocol is a data link layer protocol developed by the International Organization for Standardization (ISO), and is a bit-oriented protocol. The initial HDLC protocol is defined by ISO 3309 (frame structure), ISO 4335 (specific operation process), ISO 6159 (operation of unbalanced structure), ISO 6256 do.

FIG. 1 illustrates a process of transmitting and receiving data according to the HDLC protocol, and FIG. 2 illustrates a structure of an HDLC data frame as a data transmission unit of the HDLC protocol. The transmitter 100 according to the HDLC transmission scheme transmits the packet data 110 to the receiver 150 through the serial transmission layer 130 by HDLC encoding 120. [ The HDLC encoding 120 is a process of generating the HDLC data frame 200 of FIG. 2. First, a byte stuffing process is performed on the original packet data 110. Then, the stuffed packet data is inserted into the information part 240 of the HDLC data frame, and an error detection code (CRC) for the information part 240 is inserted into the checking part 250 of the HDLC data frame.

The receiver 150 extracts the information part 240 based on the flag 210 in the HDLC data frame transmitted through the serial transmission layer 130 and performs HDLC decoding 160 to remove the stuffing data from the extracted information part 240 ) Process. The original packet data 170 is restored through a decoding process and an error detection process is performed on the inspection unit 250 to ensure the reliability of the data inserted in the information unit 240.

It is an object of the present invention to reduce the burden of computation complexity and memory requirement due to a byte stuffing process for the entire packet data in the HDLC encoding process .

It is still another object of the present invention to reduce the error detection process for ensuring data reliability in data reception according to the HDLC protocol, thereby enabling efficient data processing.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not intended to limit the invention to the particular form disclosed. ≪ / RTI >

According to an aspect of the present invention, there is provided a data packet transmission method including generating a packet data frame for transmitting a data packet, generating a header data frame through header encoding for a data packet, Creating a footer data frame, and converting the packet data frame, the header data frame, and the footer data frame into a byte stream and transmitting the byte stream to a receiver.

The header data frame and the footer data frame may each include a sequence number field to which a value for identifying a data packet is input and a packet size field to which a value representing the size of the data packet is input.

The sequence number field and the packet size field included in the header data frame are each composed of 4 bytes. A value for identifying the data packet and a value indicating the size of the data packet can be arranged only in the 4-byte lower nibble.

The sequence number field and the packet size field included in the footer data frame are each composed of 4 bytes and the values of the two fields included in the footer data frame may be 1's complement to the values of the two fields included in the header data frame .

The transmitting step may be a step of serializing the packet data frame, the header data frame and the footer data frame into a byte stream in the order of a header data frame, a packet data frame, and a footer data frame.

According to another aspect of the present invention, there is provided a data packet receiving method including: detecting a header data frame through HDLC decoding of a received byte stream; transmitting a header data frame from a transmitter based on information included in the header data frame; The method comprising: detecting a packet data frame; detecting a footer data frame through HDLC decoding of the byte stream transmitted subsequent to the packet data frame; and detecting a header data frame and a footer data frame, And reconfiguring the data packet.

The header data frame and the footer data frame may each include a sequence number field to which a value for identifying a data packet is input and a packet size field to which a value representing the size of the data packet is input.

The step of detecting the packet data frame may detect the packet data frame according to the values of the sequence number field and the packet size field included in the header data frame.

The step of detecting the header data frame may check whether the upper nibble value of the bytes constituting the two fields included in the header data frame is a value determined by the transmitter.

The step of detecting the footer data frame may check whether the values of the two fields included in the footer data frame are in a 1's complement relation with the values of the two fields included in the header data frame.

According to the embodiments of the present invention, the following effects can be expected.

First, the byte stuffing process can be omitted without changing the conventional packet data structure, so that the computational complexity and the memory requirement amount are constant regardless of the size of the packet data.

Second, since the error detection process in the packet data receiving process is performed only for some bytes or can be omitted, the amount of operation required for the error detection process is reduced.

The effects obtainable in the embodiments of the present invention are not limited to the effects mentioned above, and other effects not mentioned can be obtained from the description of the embodiments of the present invention described below by those skilled in the art Can be clearly understood and understood. In other words, undesirable effects of implementing the present invention can also be obtained by those skilled in the art from the embodiments of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention. It is to be understood, however, that the technical features of the present invention are not limited to the specific drawings, and the features disclosed in the drawings may be combined with each other to constitute a new embodiment. Reference numerals in the drawings refer to structural elements.
1 is a diagram illustrating a data transmission and reception process according to a conventional HDLC protocol.
2 is a diagram showing a structure of an HDLC data frame as a data transmission unit of the conventional HDLC protocol.
3 is a diagram illustrating a data transmission / reception process according to the HDLC protocol according to an embodiment of the present invention.
4 is a diagram illustrating an HDLC data frame structure according to an embodiment of the present invention.
5 is a diagram illustrating an HDLC data frame structure according to an embodiment of the present invention.
6 is a diagram illustrating a process of receiving an HDLC packet according to an embodiment of the present invention.
7 is a diagram showing a structure of a transmitter and a receiver related to the present invention.

While the present invention has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the invention is not limited to the disclosed embodiments. Also, in certain cases, there may be a term selected arbitrarily by the applicant, in which case the meaning thereof will be described in detail in the description of the corresponding invention. Therefore, the term used in the present invention should be defined based on the meaning of the term, not on the name of a simple term, but on the entire contents of the present invention.

The following embodiments are a combination of elements and features of the present invention in a predetermined form. Each component or characteristic may be considered optional unless otherwise expressly stated. Each component or feature may be implemented in a form that is not combined with other components or features. In addition, some of the elements and / or features may be combined to form an embodiment of the present invention. The order of the operations described in the embodiments of the present invention may be changed. Some configurations or features of certain embodiments may be included in other embodiments, or may be replaced with corresponding configurations or features of other embodiments.

In the description of the drawings, there is no description of procedures or steps that may obscure the gist of the present invention, nor is any description of steps or steps that can be understood by those skilled in the art.

Throughout the specification, when an element is referred to as " comprising " or " including ", it is meant that the element does not exclude other elements, do. In addition, the term " "... Quot ;, " module " and the like refer to a unit for processing at least one function or operation, which may be implemented by hardware, software, or a combination of hardware and software. Also, the terms " a or ", " one ", " the ", and the like are synonyms in the context of describing the invention (particularly in the context of the following claims) May be used in a sense including both singular and plural, unless the context clearly dictates otherwise.

The embodiments of the present invention have been described herein with reference to a data transmission / reception relationship between a base station and a mobile station. Here, the base station is meaningful as a terminal node of a network that directly communicates with a mobile station. The specific operation described herein as performed by the base station may be performed by an upper node of the base station, as the case may be.

That is, various operations performed for communication with a mobile station in a network consisting of a plurality of network nodes including a base station may be performed by a base station or other network nodes other than the base station. The term 'base station' may be replaced by terms such as a fixed station, a Node B, an eNode B, an Advanced Base Station (ABS), or an access point.

Also, a 'Mobile Station (MS)' may be a user equipment (UE), a subscriber station (SS), a mobile subscriber station (MSS), a mobile terminal, an advanced mobile station The term " terminal "

Also, the transmitting end refers to a fixed and / or mobile node providing data service or voice service, and the receiving end means a fixed and / or mobile node receiving data service or voice service. Therefore, in the uplink, the mobile station may be the transmitting end and the base station may be the receiving end. Similarly, in a downlink, a mobile station may be a receiving end and a base station may be a transmitting end.

Further, an indication that a device performs communication with a " cell " may mean that the device transmits and receives signals with the base station of the corresponding cell. That is, although a practical object to which a device transmits and receives a signal may be a specific base station, it may be described as transmitting and receiving signals with a cell formed by a specific base station for convenience of description. Similarly, the description 'macro cell' and / or 'small cell' may mean specific coverage, and may also refer to a 'macro cell supporting a macro cell' and / or a 'small cell supporting a small cell' Base station '.

Embodiments of the present invention may be supported by standard documents disclosed in at least one of IEEE 802.xx systems, 3GPP systems, 3GPP LTE systems and 3GPP2 systems, which are wireless access systems. That is, self-explaining steps or parts not described in the embodiments of the present invention can be described with reference to the documents.

In addition, all terms disclosed in this document may be described by the standard document. In particular, embodiments of the present invention may be supported by one or more of the standard documents P802.16e-2004, P802.16e-2005, P802.16.1, P802.16p, and P802.16.1b, which are standard documents of the IEEE 802.16 system have.

Hereinafter, preferred embodiments according to the present invention will be described in detail with reference to the accompanying drawings. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The following detailed description, together with the accompanying drawings, is intended to illustrate exemplary embodiments of the invention and is not intended to represent the only embodiments in which the invention may be practiced.

In addition, the specific terminology used in the embodiments of the present invention is provided to help understanding of the present invention, and the use of such specific terminology can be changed into other forms without departing from the technical idea of the present invention.

3 is a diagram illustrating a data transmission / reception process according to the HDLC protocol according to an embodiment of the present invention.

As described above, in the transmission process according to the conventional HDLC protocol, a byte operation process for the entire packet data is required. On the other hand, 'packet data' may mean a minimum data processing unit that can be divided and processed. Due to the memory copying process and the insertion of the stuffed bytes required for such an operation, the computational complexity and the memory requirement increase linearly in proportion to the size of the packet data.

In order to ensure the reliability of data, an error detection process for an information part included in a data frame must be performed. If there is no hardware support for the error detection process, a software operation is required, There is an increased problem.

In order to solve this problem, an embodiment of defining a header and a footer when transmitting packet data through a byte stream transmission layer is proposed below. According to the present embodiment, packet data can be transmitted without changing the packet data, and the received data frame can be reconstructed into original packet data even on the receiving side.

In FIG. 3, the transmitter 300 performs a header encoding process 310 and a footer encoding process 315 on the packet data 305. The header and footer are defined to be compatible with the HDLC protocol even if byte stuffing is not performed in each encoding process. The encoded header and footer are serialized (320) with the packet data to be sent to the receiver (330) and arranged and transmitted in order of the data frame of the header, the data frame of the packet, and the data frame of the footer.

The receiver 330 receives the data transmitted through the serial transmission layer 325, and detects the header from the received data (335). The receiver 330 detects the footer following the header 340 and reconstructs and restores the original packet data 345. The process by which the receiver 330 reconstructs the received data will be described in detail with reference to FIG.

Hereinafter, the header and footer will be described in detail with reference to Figs. 4 and 5. Fig. 4 and 5 are diagrams illustrating an HDLC data frame structure according to an embodiment of the present invention.

The header data frame and the footer data frame are encoded into the structure shown in FIG. 4 through the header encoding 310 and the footer encoding 315 in FIG. The data frame structure of FIG. 4 differs from that of the conventional art in that a byte-stuffed data packet is inserted into the information part 240 in the conventional data frame structure, whereas the information part 240 in the data frame structure according to an embodiment of the present invention 440) is that the byte stuffing process is omitted. That is, the information unit 440 according to one embodiment includes a sequence number field 470 and a packet size field 480, and the two fields will be described in detail below.

First, the sequence number field 470 is composed of 4 bytes, and only the lower nibble of each byte has a value. The upper nibble of each byte is 0x00, which is not used when generating or reconfiguring the sequence number field 470. This is because the flag byte (byte having a value of 0x7E indicating the start and end of the HDLC frame) ) Is not generated. Accordingly, the conventional HDLC encoding process does not need to be performed.

In the sequence number field 470, a value for identifying the packet data is input, and a value from 0 to 65535 is input to increase by 1 each time packet data is generated. The value input to the sequence number field 470 is divided into units of nibble and arranged in the lower nibble of each byte of the sequence number field 470.

On the other hand, the pseudo-code constituting the sequence number field 470 from the value input to the sequence number field 470 is expressed by the following equation (1).

[Equation 1]

Byte [0] of the sequence number field = (input value & 0x000F)

Byte [1] = (input value & 0x00F0) in sequence number field >> 4

Byte [2] of the sequence number field = (input value & 0x0F00) >> 8

Byte [3] of the sequence number field = (input value & 0xF000) >> 12

Conversely, the pseudo code for reconstructing the value input from the sequence number field 470 in the receiver 330 is shown in Equation 2 below.

&Quot; (2) "

Bytes of input value [0] = (Byte [0] & 0x0F of sequence number field) | (Byte [1] & 0x0F in the sequence number field) << 4

Byte [1] = (byte [2] & 0x0F of the sequence number field) | (Byte [3] & 0x0F in sequence number field) << 4

Then, the packet size field 480 is composed of 4 bytes, and only the lower nibble of each byte has a value. The upper nibble of each byte is 0x00 and is not used when creating or reconfiguring the packet size field 480. This is a function that constrains the generation of flag bytes in the packet size field 480 as well as the sequence number field 470 .

In the packet size field 480, a value for indicating the size of the packet data to be transmitted is input, and the byte length of the packet data to be transmitted is input as a value from 0 to 65535. The input value is divided into nibble units and placed in the lower nibble of each byte of the packet size field 480.

On the other hand, the pseudo code constituting the sequence number field 480 from the value input to the packet size field 480 is expressed by the following Equation 3.

&Quot; (3) &quot;

Byte [0] in the Packet Size field = (input value & 0x000F)

Byte [1] = (input value & 0x00F0) in packet size field >> 4

Byte [2] in the Packet Size field = (input value & 0x0F00) >> 8

Bytes in the packet size field [3] = (value entered & 0xF000) >> 12

Conversely, the pseudo code for reconstructing the value input from the packet size field 480 at the receiver 330 is shown in Equation (4) below.

&Quot; (4) &quot;

Bytes of input value [0] = (Byte [0] & 0x0F in Packet size field) | (Bytes [1] & 0x0F in the packet size field) << 4

Bytes of input value [1] = (Byte [2] & 0x0F in Packet size field) | (Bytes [3] & 0x0F in the packet size field) << 4

In FIG. 5, the sequence number field 510 and the packet size field 515 of the header data frame 530 may be generated according to Equations 1 and 3 described above. That is, the sequence number field 510 is composed of 4 bytes represented by SEQ_1 to SEQ_4, and the packet size field 515 is composed of 4 bytes represented by SIZE_1 to SIZE_4.

Alternatively, the sequence number field 520 and the packet size field 525 of the footer data frame 550 are not directly generated by the above-described equations, but are stored in corresponding fields 510 of the header data frame 530 , 515) and a 1's complement relation. That is, the sequence number field 510 of the header data frame and the sequence number field 520 of the footer data frame are defined to have a one's complement value with respect to each other. (CSEQ_1 to CSEQ_4: 4 bytes of the sequence number field of the footer data frame, CSIZE_1 to CSIZE4: 4 bytes of the packet size field of the footer data frame) Similarly, the packet size field 515 of the header data frame and the packet size Field 525 may also be defined to have a one's complement value between them.

In addition, in the data frame structure of FIG. 4, the header data frame and the footer data frame may be implemented in a form in which the address part 420 and the control part 430 are omitted.

When a header data frame 530 and a footer data frame 550 in FIG. 5 are generated through the header encoding process and the footer encoding process, the transmitter transmits the header data frame 530, the packet data frame 540, Frame data frame 550 to the receiver.

6 is a diagram illustrating a process of receiving an HDLC packet according to an embodiment of the present invention. FIG. 6 shows a sequence of processes in which the receiver 330 of FIG. 3 reconstructs and processes the received HDLC packet data.

First, the receiver receives data transmitted in a byte stream from a transmitter (S605), and performs a byte reading process on the received stream (S610). If the flag is detected through the byte reading process (S615), the byte reading process and the HDLC decoding process are performed until the HDLC data frame is completed (S620). Upon completion of the HDLC data frame through the decoding process, the receiver determines whether an error has occurred in the data frame (S625). The process of determining whether or not an error has occurred can be performed by checking the upper nibbles of the sequence number field and the packet size field of the data frame. That is, if the upper nibbles of the two fields are not 0x00, the corresponding HDLC frame is not a header HDLC frame, and the receiver performs the previous process again.

If an error does not occur in the process of detecting an error occurrence, the receiver determines that the reception of the header data frame is completed, and extracts the sequence number field and the packet size field of the information part of the header data frame and confirms. The receiver checks the size of the packet data frame to be transmitted in the header data frame from the value input in the packet size field. Then, the receiver stores the packet data frame transmitted after the header data frame by the determined size (S630).

Subsequently, a process similar to the above-described S610 to S625 process is performed on the byte stream received subsequent to the packet data frame (S635 to S650). That is, the receiver detects the flag through the byte reading process on the received data frame following the packet data frame (S635 and S640), and after the HDLC decoding process (S645), if the HDLC data frame is completed, (S650).

The process of determining whether an error occurs in a data frame received after the packet data frame (S650) may be implemented differently from the process of step S625. That is, the receiver identifies the upper nibbles of the sequence number field and the packet size field of the data frame, but the value of the upper nibbles of the two fields should be 0xFF. That is, if the higher nibble is not a value of 0xFF, the corresponding data frame is not an HDLC data frame. That is, since a packet data frame is expected to be received subsequent to the packet data frame, the receiver checks that the two field values of the received data frame are in a 1's complement relationship with the two field values of the previously received header data frame.

If no error occurs in the HDLC data frame in step S650, the receiver determines that the reception of the footer data frame is completed following the packet data frame, and the packet reconfiguration is normally completed (step S655). Then, the receiver processes the reconfigured packet (S660).

According to the embodiments described with reference to FIGS. 3 to 6, it is not necessary to process or process the packet data (for example, a byte stuffing process). That is, the header data frame and the footer data frame are transmitted before and after the packet data frame so that the receiver can reconfigure the packet data. This has the advantage that a certain computational complexity and memory requirement are consumed per packet regardless of the size of the packet data.

Since the error detection code checking process for error detection is performed only for 8 bytes (sequence number field, packet size field) of the header data frame, the amount of calculation required is smaller than the conventional method for calculating the error detection code for the entire packet.

Further, when a device having a USB device interface communicates with a host using an endpoint such as an ACM (Abstract Control Model) or an OBEX (OBject Exchange), a byte stream transmitted to a USB host driver (ACM, OBEX class) The above-described embodiment can also be applied. That is, packet transmission and reconfiguration of a stream transmitted to the USB host driver can be performed according to the above-described embodiment. Also, since the USB transport layer guarantees data reliability, it is also possible to eliminate the process of calculating the error detection code.

In addition, transmission and reconfiguration of packets can be performed according to the above-described embodiment even in the case of transmitting / receiving a packet through a TCP / IP connection between devices, transmitting / receiving a packet via an RS-232 interface, and the like.

7 is a diagram showing a structure of a transmitter and a receiver related to the present invention.

In FIG. 7, transmitter 700 and receiver 800 may include radio frequency (RF) units 710 and 810, processors 720 and 820, and memories 730 and 830, respectively. Although FIG. 7 illustrates a 1: 1 communication environment between the transmitter 700 and the receiver 800, a communication environment can be established between a plurality of transmitters and the receiver 800. FIG.

Each of the RF units 710 and 810 may include transmission units 711 and 811 and reception units 712 and 812, respectively. The transmitter 711 and the receiver 712 of the transmitter 700 are configured to transmit and receive signals with the receiver 800 and other terminals and the processor 720 is operatively coupled to the transmitter 711 and receiver 712 And controls transmission and reception of signals between the transmitting unit 711 and the receiving unit 712 with other devices. The processor 720 performs various processes on the signal to be transmitted, and then transmits the processed signal to the transmitter 711. The receiver 712 processes the received signal.

If desired, processor 720 may store information contained in the exchanged message in memory 730. With such a structure, the transmitter 700 can perform the methods of the various embodiments of the present invention described above.

The transmitter 811 and the receiver 812 of the receiver 800 are configured to transmit and receive signals with other base stations and terminals and the processor 820 is functionally connected to the transmitter 811 and the receiver 812, The control unit 811 and the receiving unit 812 may control the transmission and reception of signals with other devices. In addition, the processor 820 may perform various processes on a signal to be transmitted, transmit the signal to the transmitter 811, and process the signal received by the receiver 812. If desired, the processor 820 may store information contained in the exchanged message in the memory 830. Having such a structure, the receiver 800 can perform the methods of the various embodiments described above.

Processors 720 and 820 of transmitter 700 and receiver 800 respectively direct (e.g., control, coordinate, manage, etc.) operations at transmitter 700 and receiver 800. Each of the processors 720 and 820 may be coupled to memories 730 and 830 that store program codes and data. The memories 730 and 830 are connected to the processors 720 and 820 to store operating systems, applications, and general files.

The processors 720 and 820 of the present invention may also be referred to as a controller, a microcontroller, a microprocessor, a microcomputer, or the like. Meanwhile, the processors 720 and 820 may be implemented by hardware or firmware, software, or a combination thereof. (DSP), digital signal processing devices (DSPDs), programmable logic devices (PLDs), and the like may be used to implement embodiments of the present invention using hardware, , FPGAs (field programmable gate arrays), and the like may be provided in the processors 720 and 820.

On the other hand, the above-described method can be implemented in a general-purpose digital computer that can be created as a program that can be executed in a computer and operates the program using a computer-readable medium. Further, the structure of the data used in the above-described method can be recorded on the computer-readable medium through various means. Program storage devices that may be used to describe a storage device including executable computer code for carrying out the various methods of the present invention should not be understood to include transient objects such as carrier waves or signals do. The computer readable medium includes a storage medium such as a magnetic storage medium (e.g., ROM, floppy disk, hard disk, etc.), optical reading medium (e.g., CD ROM, DVD, etc.).

It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. Therefore, the disclosed methods should be considered in an illustrative rather than a restrictive sense. It is intended that the present invention cover the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.

Claims (10)

A method for transmitting a data packet by a transmitter according to a high-level data link control (HDLC) protocol,
Generating a packet data frame for transmitting the data packet;
Generating a header data frame through header encoding for the data packet;
Generating a footer data frame through footer encoding for the packet data; And
Converting the packet data frame, the header data frame and the footer data frame into a byte stream and transmitting the byte stream to a receiver. The method according to claim 1,
Wherein the header data frame and the footer data frame each include a sequence number field in which a value for identifying the data packet is input and a packet size field in which a value indicating the size of the data packet is input. 3. The method of claim 2,
The sequence number field and the packet size field included in the header data frame are each composed of 4 bytes, and a value for identifying the data packet and a value indicating the size of the data packet are arranged only in the 4-byte lower nibble Lt; / RTI &gt; The method of claim 3,
The sequential number field and the packet size field included in the header data frame are each composed of 4 bytes. The values of the two fields included in the header data frame correspond to the values of the two fields included in the header data frame, Gt; a &lt; / RTI &gt; transmission method. The method according to claim 1,
Wherein the transmitting step serializes the packet data frame, the header data frame and the footer data frame in the order of the header data frame, the packet data frame, and the footer data frame, and converts the serialized data into the byte stream. . A method of receiving a data packet by a receiver according to a High-level Data Link Control (HDLC) protocol,
Detecting a header data frame through HDLC decoding of the received byte stream;
Detecting a packet data frame to be transmitted following the header data frame from a transmitter based on information included in the header data frame;
Detecting a footer data frame through HDLC decoding of a byte stream transmitted subsequent to the packet data frame; And
And reconstructing a data packet transmitted by the transmitter from the packet data frame when the header data frame and the footer data frame are detected. The method according to claim 6,
Wherein the header data frame and the footer data frame each include a sequence number field in which a value for identifying the data packet is input and a packet size field in which a value indicating the size of the data packet is input. 8. The method of claim 7,
The step of detecting the packet data frame
And detecting the packet data frame according to a value of a sequence number field and a packet size field included in the header data frame. 8. The method of claim 7,
The step of detecting the header data frame
Wherein a higher nibble value of the bytes constituting the two fields included in the header data frame is determined by the transmitter. 10. The method of claim 9,
The step of detecting the footer data frame
Wherein a value of two fields included in the header data frame is in a 1's complement relationship with the value of two fields included in the header data frame.
KR1020140102222A 2014-08-08 2014-08-08 Method for transmitting and receiving data according to hdlc protocol KR20160018110A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020140102222A KR20160018110A (en) 2014-08-08 2014-08-08 Method for transmitting and receiving data according to hdlc protocol

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020140102222A KR20160018110A (en) 2014-08-08 2014-08-08 Method for transmitting and receiving data according to hdlc protocol

Publications (1)

Publication Number Publication Date
KR20160018110A true KR20160018110A (en) 2016-02-17

Family

ID=55457426

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020140102222A KR20160018110A (en) 2014-08-08 2014-08-08 Method for transmitting and receiving data according to hdlc protocol

Country Status (1)

Country Link
KR (1) KR20160018110A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102409414B1 (en) * 2021-11-30 2022-06-15 한화시스템 주식회사 Digital radar receiver of radar system and multi-channel reception signal processing method using the same

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102409414B1 (en) * 2021-11-30 2022-06-15 한화시스템 주식회사 Digital radar receiver of radar system and multi-channel reception signal processing method using the same

Similar Documents

Publication Publication Date Title
US10863578B2 (en) Data transmission method, device and system
JP6533565B2 (en) Method and apparatus for processing data packets
CN110192428B (en) Method for message processing and associated device and apparatus
US20170078916A1 (en) Data processing method and apparatus
CN114208137B (en) Compression and decompression method and device for Ethernet frame header
CN104184834A (en) File transmission method and device and terminal
US11477619B2 (en) Variable volume data transmission in a mobile communication network
US10257328B2 (en) Method and apparatus for control frame extension
KR20160018110A (en) Method for transmitting and receiving data according to hdlc protocol
CN113796029A (en) Unit and method of base station system for transmission on forward link
US20120144275A1 (en) Code generating device and code generating method, code checking device and code checking method, computer program, and communication device
CN107770847B (en) Network access method, access equipment and terminal equipment
WO2017219205A1 (en) Base station, data transmission method and apparatus
CN107534853A (en) A kind of method and apparatus for starting relay function
CN110139317B (en) Data compression method, decompression method, sending end and receiving end
EP2566292B1 (en) Method, system and mobile terminal for configuring access point and application information
CN113329352A (en) Communication method, apparatus, device and medium
CN110475300A (en) Communication connecting method, device, base station, terminal and computer readable storage medium
WO2016154999A1 (en) Data transmission method, device and system
US12003322B2 (en) Data transmission method and communication apparatus
CN103597770A (en) Systems and methods for reducing acknowledgment message overhead
CN108738075B (en) Flexible protocol data unit packing method and user equipment thereof
EP3419252A1 (en) Wireless base station, terminal device, and communication system
JP2023550889A (en) Data transmission methods, communication devices, computer readable storage media, and chips
CN110875795A (en) Data transmission method, device, equipment and storage medium

Legal Events

Date Code Title Description
WITN Withdrawal due to no request for examination