Wireless network system and method

Description: TECHNICAL FIELD [Detailed description of the invention]

【0001】

[Background Technology of the Present Invention] The present invention relates generally to digital data transmission protocols in communication networks, in particular efficient and reliable packetized digital data transmission for improved transmission performance with reduced bandwidth requirements. Related to protocols, these are in networks that are of poor quality or have widely varying physical channel characteristics, such as wireless network environments. [0002]

A typical open system interconnect (OSI) reference model network protocol defines several hierarchies and describes the protocol stack. A particular OSI model protocol that is widely used in telecommunications networks, including the Internet, is the Internet Protocol (IP), and in particular a supplemental IP known as the Transmission Control Protocol (TCP / IP). Of all OSI model protocols, including IP and TCP / lP, higher level layers, such as forwarding protocols, communicate with packetized data to lower level layers, such as the Internet Protocol layer. .. Then, a lower level layer, such as the Internet Protocol layer, ultimately relays the data to the data link layer, this time relays the data to the physical layer, and directs the physical transfer of the data. [0003]

In such communications, for example, first, the data intended to be transferred by a network device is an OSI model that includes several defined layers such as the physical layer, data link layer, network layer, transport layer, and so on. Formatted by the data protocol. An example of such an OSI model protocol is shown in Figure 1. In the model of Figure 1, the data transmitted by the device is processed first by the transport layer; this transport layer can overlap with the application layer in certain applications. Typically, the transport layer defines a forwarding mechanism so that the data is later split into data packets for physical forwarding. [0004]

The data from the transport layer is then processed by the interconnected network layers. An example of this network layer is the traditional Internet Protocol (IP) layer, as is widely realized today in TCP / IP networks such as the Internet. The interconnected network layer prepares packets from the forwarding protocol layer for forwarding over the interconnected networks. [0005]

The data link layer then prepares the physical transfer data over a defined network physical channel, such as an Ethernet link or other type of local area network. [0006]

Finally, the physical layer performs the actual transmission of data processed to and through the network operating under a particular OSI model implementation. [0007]

Currently, one of the most common implementations of the OSI model in network communication is TCP / IP. For example, Internet communication is typically done by TCP / IP, which is considered a standard for the Internet. In TCP / IP, the physical layer remains and is device or network independent, as long as the device and network can use the OSI model layer that follows TCP / IP. [0008]

In TCP / IP, the network layer is IP and the transport layer is TCP. IP and TCP are well known and defined as standards. Under that standard, the IP portion of the protocol handles the delivery of data packets to their intended destination. The TCP part performs integrity checks on the data and enhances the ability to reconstruct packets into the original message or to a file at the destination. [0009]

Although TCP is now widely used in data communications, including the Internet, the protocol was designed primarily for use with reliable, immutable channels and bandwidth, i.e., primarily for wired connections. .. And the transition of communication tendency and communication to mobiles and wireless devices did not presuppose that the TCP protocol was established. As other new low-quality and variable channel networks evolve, the assumptions and assumptions that TCP was designed for no longer have the same application in the wireless industry. [0010]

Therefore, improved protocols and methods are needed to explain the nature of radios and other new physical channels and applications. Many protocols and methods are designed to be described and operated, for example in voice over IP, multimedia forwarding, satellite protocols, multicast protocols, and the like. While these various designs may have advantages in a particular application, improved protocols and methods are still needed to address wireless communications and similar networks that exhibit variable bandwidth and channel execution characteristics. To. [0011]

Especially in wireless communication, traditional systems and methods such as the TCP / IP protocol have some drawbacks. These drawbacks are many round-trip times of communication (RTT), changes in measurements within the RTT due to changes in channel characteristics, substantial packet loss, high bit error rates, and data loss due to congestion. False assumptions for low transmission rates, unpredictable multi-channel possibilities, and ARQ technology are often very expensive. Moreover, while recent technological advances such as computer speed and error correction techniques can make improvements, these advances have not taken advantage of their potential in advance. [0012]

In short, there is a need for improvements in the technical field of communication in narrow bandwidth, low quality channels such as wireless networks. [0013]

[Summary of invention] The embodiment of the present invention is a communication method in a network. The method packetizes the payload into a sequence of data packets; inserts header packets toward the beginning, middle and end of the sequence; sends the sequence along with the header packets; the sequence. Steps to receive at least some data packets and at least one header packet; and that all data packets and at least one header packet have been received; at least not all data packets received Consists of receiving one header packet; and sending an authentication selected from the group consisting of receiving several data packets but not the header packet. [0014]

In a further form, the method comprises the step of terminating the method if the authentication indicates that the data packet and at least one header packet have all been received. [0015]

In other forms, the method further identifies a data packet that was not received if at least one header packet was received but not all data packets were received. The authentication of the transmitting step comprises the step of including the header of the unreceived data packet; and the step of retransmitting only the unreceived data packet; [0016]

In a further form, the method is a step of confirming that some data packets that are not header packets are received, and the authentication of the transmission step is of the received data packets. Steps that include identifiers; Steps that determine which data packets were not received based on said identifier during the authentication; Steps that retransmit only header packets and data packets that were not received; Consists of. [0017]

[Detailed description of the invention] FIG. 2 shows a communication network 2 composed of wireless devices 4 and 6 and connected devices 8 and 10. Network 2 includes intercommunication links 12 between various devices, 84, 6, 10 and other devices and communication links (not shown). An example of network 2 is the Internet, but other communication networks such as intranets, LANs, WANs, etc. may also be included. [0018]

In network 2, device 8 is a network device and device 10 is a display device. Each of these devices is wired to the communication link 12 and thus the entire network 2. Device 4 is a mobile wireless device. The device 6 is a stationary wireless device connected by a wire to the communication link 12. The mobile radio device 4 and the stationary radio device 6 can communicate wirelessly by cellular radio transmission and reception, for example, through one or more cell towers 14. The mode of radio communication is, for example, cellular digital packet data (CDPD) in a cellular radio environment, but in alternative or in addition, analog or digital cellular, radio frequency (RF), microwave, etc. Can be any other wireless mode. [0019]

In communication over network 2, the mobile radio device 4 and the stationary radio device 6 can communicate with each other by a specialized packetized data protocol as follows. [0020]

[Packeted data communication protocol] With reference to FIG. 3, radio devices 4 and 6 (shown in FIG. 2) communicate by Image Transfer Protocol (ITP) 20. ITP Protocol 20 follows the OSI model (shown in Figure 1), but is adapted for wireless communications with reduced bandwidth and variable channel characteristics and similar lower quality networks. ITP Protocol 20 contains various layers. [0021] [0021]

The data layer 22 provides the transfer of digital data. The transport layer 24 helps to divide the data into desired packets. The network layer 26 is from the transport layer 24 for transfer over a particular network, especially according to its characteristics, such as certain properties such as the particular protocol suitable for the Internet and other standardized suitable networks. Prepare the packet. The data link layer 28 prepares the packet for physical transfer, that is, describes the physical port for transfer through a specifically defined network physical channel. Finally, the physical layer 30. Performs the actual transmission of packets on a particular communication channel, such as the network 2 radio channel. [0022]

The ITP protocol 20 is somewhat similar to other OSI model protocols from this generalized point of view, but is unique in certain features of the transport layer 24 and the physical layer 30. In addition, ITP Protocol 20 provides a wireless resource manager 32. The wireless resource manager 32 provides interaction, interconnection, and communication between the transport layer 24 and the physical layer 30 of the ITP protocol 20. These features as well as the data and packet formats are now described. [0023]

[Sent data and data packet format] With reference to FIG. 4, the entire data payload 30 is separated or "packetized" into a series of data packets 40. This packetization is performed according to the process of transport layer 24 of ITP protocol 20. The transport layer 24 packetizes the data in the data packet 40 having a specific format. The first data packet 40 "in the sequence" of payload 30 is header packet 41. The header packet 41 contains a specific identifier called the "payload header" or "header packet" of the payload 30 of interest. Header packet 41 is contained within payload 30 at the beginning of payload 30, and is generally repeated in one of the last few packets 40 in the middle of payload 30 and at the end of payload 30. .. The specific format of data packet 40 for payload 30 will be described in the future. [0024]

Referring to FIG. 5, in the ITP protocol 20, the data packet 40 for transmission contains the transmission header 50. Transmission header 50 includes 8-bit packet type 42, 16-bit sequence ID 44 and 32-bit payload ID 46. The transmit header 50 is the first sequence of information for each data packet 40 in communication with the ITP protocol 20. Packet type 42 is used for data type determination. Sequence ID 44 indicates the sequence position for data packet 40 with respect to other data packet 40 (shown in FIG. 4) sent in the communication of the entire payload 30 (shown in FIG. 4). .. Payload ID 46 helps identify a particular payload 30 where the particular data packet 40 is part. [0025]

In addition, in certain cases of header packet 41 (ie, payload header) for a particular payload 30, payload ID 46 identifies 41 to a particular payload 30 sent by header packet ITP protocol 20. Thus, payload ID 46 is a field that distinguishes an individual data packet 40 from a particular payload 30. Payload ID 46 also uniquely identifies a given packet 40 if it is header packet 41 to include a header for a particular payload 30. The number of packets 40 in a particular payload 30 depends on the size of the payload 30 and the size of the data packet 40. [0026]

If the packetizer decomposes the data in the payload buffer separately into N packets, this number N is represented by the data field 48 of the data packet 40, which is the header packet 41 for the payload 30. Therefore, the number N represented in data field 48 of the unique header packet 41 for payload 30 identifies the number of data packets 41 in a particular payload 30. If the receiver receives the header packet 41, the receiver can determine from the transmission and how many packets 41 are expected with a particular payload 30. Header packet 41 also contains other information, including data directly from the payload buffer and other data. [0027]

[Received data and data packet format] FIG. 6 shows the incomplete payload 30 (in FIG. 4) when the header packet 41 for a particular payload 30 was received by the receiver 52, but the other data packets 40 were not so received. A block diagram of the retransmission request message packet 50 sent by the receiver 52 in response to the receipt (indicated by). Packet 50 contains payload identification 54 that identifies the payload 30 in question. Packet 50 also contains sequence ID 55 and packet type 56 identifiers. Message field 58 of packet 50 identifies that the header packet 41 of the received transmission content was received by the receiver 52. Another set of data identifies packets 40 that the receiver 52 did not receive and could not be reconstructed by forward error correction or data heuristics or a similar process. [0028]

FIG. 7 is a block diagram of the retransmitted packet 60 sent by the receiver 62 in response to an incomplete payload 30 reception for which the header packet 41 for a particular payload 30 was not received. Packet 60 contains a payload identification 64 that identifies the payload 30 in question. Packet 62 further contains sequence ID 63 and packet type identifier 65. Message field 66 of the identifier of packet 62 confirms that receiver 62 does not know how many packets, 40 are in payload 30, because receiver 62 did not receive header packet 41. If the time-out is reached after the receiver 62 begins to receive some data packets 40, the retransmission packet 60 is sent by the receiver 62. Another block of data in message field 62 identifies packets 40 received by the receiver and prevents the next transmission from repeating those packets 40 being received. The next transmission then retransmits only the previously unreceived header packets 41 and those packets 40. [0029]

[Wireless Resource Manager] Figure 8 is a functional block diagram of the wireless resource manager 32 in Figure 3. The radio resource manager 32 includes a transport layer interface 505, a physical layer interface 510, a channel characteristic database 520 and a radio unit characteristic database 530. The transport layer interface 505 communicates through a well-defined application programming interface (API) of the transport layer 24 (shown in FIG. 3) of the ITP protocol. Interface 505 communicates with physical layer interface 510 according to the ITP protocol. The physical layer interface 510 allows the wireless network device (not shown) and the wireless resource manager 32 to actually communicate by means of a wireless resource manager (RRM) within the wireless modem of such a device. This communication is further driven by a well-defined API of wireless network equipment to which the physical layer 30 can interact. The physical layer interface 510 allows the radio resource manager 32 to request data from the radio network device, such as channel status, channel characteristics and other characteristics. As previously mentioned, this information can be relayed to the transport layer 24 to allow the transport layer 24 to adapt to changing conditions in the wireless environment (see Figure 3). [0030]

The physical layer interface 510 further allows the radio resource manager 32 to request that the radio unit change its characteristics. For example, the wireless resource manager 32 may require the attached wireless communication unit to change the channel inspection system of the wireless device in order to minimize the impact on the inspection system during data transmission. Alternatively, the radio resource manager may specifically require the radio device to change channels. Of course, many other control and information mechanisms are possible, as known to those of skill in the art. [0031]

In addition to interfaces 505 and 510, the wireless resource manager 500 also includes a channel characteristic database 520. This channel characteristic database 520 contains information in the wireless receiver, associated channels, and other information such as error rate history and power characteristics, and other relevant information about the operation of the protocol in the wireless environment. It is a database that is available. The channel characteristic database 520 may also be adapted to include information about cell phone relays, relay facings, channels associated with them, and other relevant information as described above. [0032]

The radio resource manager 32 also includes the radio unit characteristic database 530. The radio unit characteristic database 530 is a database that contains information about the current operating characteristics of the radio equipment used to transmit the data. This can include matters such as channel test schedules, acceptable channels, power associated with those channels, and other radio device specific information that supports the data protocol. [0033]

Using the database in the radio resource manager 32 allows monitoring of error statistics based on the evolving changes in the "noise profile", which allows the radio resource manager 32 to monitor a given RF channel. Allows you to make informed inferences about the duration and frequency of high error rate periods for. Each RF channel shows its own noise profile, and records of this profile are accumulated and stored by the IP protocol. [0034]

The radio resource manager 32 uses the noise profile information to direct the transport layer 24 when the physical layer 30 operates erratically or unexpectedly. Information can also be requested by the transport layer 24 to determine the operating characteristics of the protocol, such as the appropriate FEC parameters to use or the appropriate timeouts. Unexpected channel events, such as channel changes that occur outside the protocol, are communicated to transport layer 24 in a similar manner. [0035]

It should be noted that the wireless resource manager 32 can be implemented as an independent resource, or can be in whole or in part within either the transport layer 24 or the physical layer 30 of the protocol stack. [0036]

[compression] Returning to Figure 3, in the ITP protocol, the transfer protocol layer 24 has many functions, including transfer mechanism 122, compression mechanism 124, forward error correction (FEC) mechanism 126, physical layer manager 128, and data heuristic manager 129. Unit is included. [0037]

The compression mechanism 124 takes the data generated by the network device and compresses it. The compression mechanism 124 can utilize interchangeable compression techniques that are adaptable to the actual data received. For example, the data consists of graphical data. The transport layer 24 can recognize the data as graphical data and realize a wavelet transformation on the graphical data. Alternatively, the transport layer 24 may have empirical knowledge of the types of graphical data and, adaptively, has a set of basic functions that minimizes the amount of data transferred. Small wave conversion on the data can be realized. [0038]

[Forward error correction] The FEC mechanism 126 takes the compressed data and adds an extra amount of data that allows the receiving mechanism to reconstruct the arriving data if the original data is missing. FEC mechanism 126 is adaptable to the existing current situation in and through its connection to the interconnected network 140. [0039]

In a typical FEC system based on a known error rate, for a certain amount of data K, an extra amount of data L is generated and added to the transmission, and the total amount of data K + L = N is actually To be sent. Extraction of an arbitrary amount of data K in the receiving device is sufficient to cause the receiver to regenerate the data transmitted by the transmitting device. As the transmission error rate rises and falls, the data volume L can be changed dynamically to reflect the expected transmission loss. [0040]

[Transfer mechanism] The transport layer 24 transfer mechanism 122 directs bundling or packetizing and rebunching the original payload of digital data at the receiving end. The transfer mechanism 122 also controls the calculation of the timeout at the receiving end of the transmission. In addition, transfer mechanism 122 directs the flow of information between the receive and transmit ends through the use of control protocols. These control protocols include a display of the received payload, a display of the incomplete transmission of the payload, and other handling forms of management between the receiving and transmitting parties on the interconnected network 12. There is. [0041]

The transfer protocol at the receiving end can track the amount of data not being received. As further described herein, when returning to the transmission protocol, the data allows the transmission protocol to adapt to the changing network environment. [0042]

Moreover, in the case of multipath links to interconnected networks, packets may be reorganized and prioritized. For example, if a link to an interconnected network is over a wireless link, high priority packets may be sent over channels that are likely to get more through that link. Packets with lower priority can be delayed or transmitted on noisy channels. [0043]

[Physical layer management] The physical layer manager mechanism 128 allows the transport layer 24 to finetune the transmission and reception of data over an interconnected network 12 (shown in FIG. 2). Physical layer manager 128 monitors physical layer 30 and provides the transport layer with 24 knowledge of its payload or the actual transmission state of the payload within physical layer 30. [0044]

Based on the state of the physical layer 30, the transport layer 30 can slow down the transmission, stop the transmission, modify the parameters in the FEC mechanism 126, and perform other actions. In the case of wireless links, the interaction between the physical layer manager mechanism 128 and the forwarding mechanism 122 allows, for example, IP protocol 20 to send high priority packets on more robust channels. [0045]

The ability to deactivate at the transport layer 24 is particularly important as it can simply stop data from flowing through protocol 20 when the physical layer is overloaded. Traditional protocols are unable to communicate in the protocol stack in the event of a physical delay. This makes overrun buffering at the upper levels of the traditional stack more common and significantly reduces the speed and efficiency of traditional protocol operations. Therefore, the physical layer manager mechanism 128 of this embodiment allows the buffer overrun to be minimized and allows Protocol 20 to resume without the snowballing delay of Protocol 20. .. [0046]

The physical layer manager mechanism 128 can further maintain a track of data in the transmission characteristics of the physical layer 30. The physical layer manager mechanism 128 allows the error rate in transmission to be maintained based on the amount of transmission received from receiving a protocol indicating the amount of unreceived data. [0047]

[Data heuristics] The data heuristic mechanism 129 of ITP Protocol 20 allows the data to be reconstructed at the receiving end, even in the absence of the minimum amount of data required in the FEC. For example, in graphics data, the data can be a representation of high and low energy parts. If the relevant high energy data is restored, the portion of the lost low energy data can be reconstructed solely by the lack of high energy data. As described, the data heuristic mechanism 129 is specific to such transmitted data. [0048]

Depending on the particular data and, if possible, the compression used on the data, the data heuristic mechanism 12a allows the forwarding layer 24 to assign priority to individual packets. This allows the forwarding mechanism 122 and the physical layer manager mechanism 128 to send higher priority packets on more robust channels or routes. [0049]

Further descriptions of data heuristics are provided after a discussion of common transmission and reception techniques such as: [0050]

[Sending process] FIG. 9 is a flow chart of a typical transmission of a digital data payload 30 (shown in FIG. 4) that can be realized in the ITP protocol 20 of FIG. In step 210, the data is compressed in the proper format. As those skilled in the art know, it is possible to utilize compression techniques and properties based on the data itself. For example, textual information data is most compressed, etc., but using image data, compression is achieved in some way. In step 220, the data is packetized as packet 40 (shown in FIG. 5) and prepared for transfer over the interconnected network 12 (shown in FIG. 2). In step 230, packets 40 are sorted in order of priority. FEC coding is performed in step 235. [0051]

In step 240, the packet is sent by a transmitter, such as mobile radio device 4 (shown in FIG. 2). In step 240, protocol 20 further monitors the physical link, i.e., the particular wireless communication (or optionally wired) communication channel of transmission. The transmission of packet 40 is then delayed or reordered, depending on the parameters of the monitored link, to optimize or guarantee satisfactory transmission results. [0052]

FIG. 10 is a block diagram of examples of possible physical connection transport layers 24 and 30 for implementing protocol 20 of FIG. In an example, protocol stack 600 includes physical layer 30 and transport layer 24 according to ITP protocol 20 (shown in FIG. 3). Communication between the transport layer 24 and the physical layer 30 is achieved, for example, by a pair of sockets 630 and 640. Socket 630 is open to transport layer 24. As in the past, the socket 630 connects to the application layer 632. Socket 640 is opened to stack 642, which stack 642 communicates with physical layer 30. Further, as in the past, the socket 640 connects to the application layer 644. Sockets 630, 640 communicate directly, allowing coordination between transport layer 24 and physical layer 30 with respect to events and conditions during operation of ITP protocol 20. [0053]

At the start of protocol 20, sockets 630 and 640 are created in transport layer 610 and physical layer 620, respectively. Information about the physical layer 30, such as channel characteristics in the case of wireless physical links, is transmitted to the transport layer 24 through sockets 630,640. Further, a request for changing the operation of the physical layer 30 or a request for the physical layer 30 is communicated by the same socket 630,640 mechanism. During operation, if for some reason the physical layer 30 cannot keep up with the data throughput by the protocol stack 600, the physical layer 30 will be transported by the communication configured by the pair of sockets 630, 640. Tell the situation to. The transport layer 24 maintains active communication with the physical layer 30, or a polling mechanism is used. [0054]

The situations that physical layer 30 can convey to transfer layer 24 are information such as channel state, channel switch or hop, and between physical wireless device 4 (shown in FIG. 2) and interconnect network 12. Contains (but is not limited to) other relevant information about the communication link. Transport layer 214 can use this information to maintain data communication over protocol stack 600. For example, if the channel characteristics determine that a new channel is needed for the link to the physical device 4 of the radio in the interconnected network 12, physical layer 30 transports through sockets 630 and 640. Communicate this action to layer 24. In response, transport layer 24 delays data communication through protocol stack 600 so that it does not create overflow conditions in any of the input buffers contained in the other layers of protocol stack 600. To do. [0055]

Upon improvement in the channel characteristics of the physical device, or upon completion of the channel switch, this event is communicated to radio protocol layer 610 by the same socket pairs 630 and 640. Upon notification of this event, the transfer protocol layer 610 enables or facilitates data transmission again by protocol stack 600. [0056]

Thus, the present invention envisions a dynamic communication protocol stack. The transport protocol layer 610 responds to characteristic changes in the protocol stack 600 and in the physical transmit characteristics. Therefore, thrashing data within the protocol stack 600 can be minimized. As envisioned, the top layer of the interconnected network protocol stack acts as a transmit manager for the communication system. [0057]

With reference to FIG. 11, the method 200 of FIG. 9 for transmission by protocol 23 is further detailed and various alternative methods are described. In particular, method 200 begins with step 210, which compresses the data to be transmitted. The compressed data is then packetized in step 220. Step 220 includes several partial steps below. [0058] [0058]

In step 222, method 200 waits for the data payload to be received. Method 200 receives the data payload in step 224. The payload data is then packetized into N packets in step 226. The header packet is then created in step 228. The header packet is then copied in step 230 and inserted at the beginning, middle, and end of the payload packet sequence. [0059]

Once the data is packetized in step 220 and the packets are ordered in step 230, FEC coding is performed in the payload of step 235. The packet is prepared for transmission, and the packet is transmitted in step 240. Step 240 of transmission involves various steps and can proceed along three possible routes, depending on the efficiency and completion of transmission. [0060]

For each of the routes, a packetized payload with the inserted header packet is sent in step 241. After the transmission in step 241 there is a waiting time in the transmitting device in step 242. During the waiting period of step 242, the transmitting device is notified that it has terminated or that the payload has been received or not received. [0061]

If the receiving device receives all packets of the payload containing at least one header packet, the receiving device sends an acknowledgment (ACK) that the payload has been received to the device transmitting in step 248. Method 200 then returns to step 220, and in particular step 222 waiting for the next payload. [0062]

On the other hand, if the receiving device receives only some of the packets transmitted in step 241 and at least one header packet, step 243 continues. At step 243, the receiving device sends a message to the transmitting device indicating which packet was successfully received. In the next step 244, the transmitting device determines which packet in the payload was not received, based on the knowledge of the particular packet received by the receiving device from the message in step 243. The transmitting device then prepares the unreceived packet for retransmission in step 246. In step 247, the transmitting device retransmits packets that were not received by the receiving device. Method 200 then returns to step 242, waiting again to finish, waiting to learn from the received message that the packet was successfully received or not received. [0063]

If the receiving device does not receive the header packet of the original transmission of step 241 during the waiting period of step 242, the transmitting device times out and does not receive any authentication or other message from the receiving device. A timeout occurs at step 245. After the timeout in step 245, the transmitting device retransmits the entire payload, including the header packet, in step 246 of preparing the packet for transmission. The entire payload and header packets are then retransmitted in step 247. After step 247, the transmitting device returns to step 242 waiting for authentication or timeout. [0064]

As is known to those skilled in the art, until the transmitting device determines or learns from the return message from the receiving device that the payload was received by the receiving device along with at least one header packet. , Method 200 continues. The FEC that encodes the packet in step 235 allows the receiving device to reconstruct the missing packet, even if the receiving device does not receive the packet, under certain conditions. In such a case, the receiving device can treat the situation as if the reconstructed packet was originally received, and that the package was received even though it was reconstructed by FEC decoding. Notify the device sending the indicated message. [0065]

With reference to FIG. 12, in connection with FIG. 3, in the case of an unexpected network event such as a communication channel interruption, it is shown using a timing diagram of the unexpected event. An unexpected event in this example requires a channel change for communication. First, at time T1, a channel change occurs that interrupts the transmission of data packet P on channel 1. This event is detected by Radio Resource Manager 32 (shown in Figure 3) of Protocol 20 (or by another physical layer mechanism that performs a similar function in its place). The radio resource manager 32 informs the transport layer 24 of protocol 20 that the event has occurred. The channel change occurs at time t1. Instead of continuing to transmit by protocol 20 (which would overflow the buffer used by protocol 20), the transport layer 24 of protocol 20 will remain until notified by the radio resource manager 32 of the successful channel change. , Stop sending data. [0066]

After the period tl, once a new channel is used, the transport layer 24 of protocol 20 continues the process of transmitting the data to be transmitted. Channel changes are described in T2, T3. In particular, in protocol 20, the transport layer 24 resumes relaying data for physical transfer only after a successful channel change. Therefore, the operation of Protocol 20 and the wireless resource manager 32 avoids the avalanche failure of all Protocol 20s, otherwise requires a reset time associated with the failure. [0067]

With reference to FIG. 13, Method 800 is performed in the unexpected event situation of FIG. In step 805, the transport layer of protocol 20 continues to relay data packet transmissions in action prior to an unexpected event. At step 810, for example, an unexpected event occurs requesting a channel change. Upon detecting this event, the transport layer 24 in step 820 delays subsequent data transmission until the unexpected event is processed in step 820. When an unexpected event is processed, normal transmission resumes at block 805 through the operation of Protocol 20. [0068]

[Receiving process] With reference to FIG. 14, the method 1400 for receiving the transmitted information follows protocol 20 (shown in FIG. 3). In step 1410, the receiver operating according to protocol 20 waits for the arrival of an initial packet of payload sent to the receiver. In step 1412, the transmitted packet arrives and is received by the receiving device. In step 1414, the received packet is determined as to whether the packet payload ID is active. If the payload ID is active, that is, if a particular payload is indicated by the payload ID, the received packet is accumulated with other arriving packets in step 1416. On the other hand, if the payload ID of the packet is not active, step 1418 begins payload assembly for the payload ID. [0069]

Then, in step 1420, the received packet list is created. Then, step 1416, which adds a packet to the payload received packet list, continues to step 1420. [0070]

In step 1422, method 1400 determines if the received payload is complete. If it is not perfect, step 1424 is followed in which the payload packet count is incremented. The payload timeout is then recalculated based on all packets expected in that payload and the timeout is reset for payload assembly in step 1426. Method 1400 then returns to step 1410, which waits for the packet to arrive. [0071]

If the payload is complete in step 1422, the next step 1428 sends a payload authentication (ACK) to the transmitter. At step 1430, the payload assembler operation ends. In the transmission process by method 200 (shown in Figures 9 and 11), if the packet is an encoded FEC, step 1440 decodes the packet into an appropriate number of source packets. In step 1442, the packet is transmitted to a file aggregator for reassembly so that it can be assembled and decoded. The receiving method 1400 is completed in step 1444, which finishes the task. [0072]

If the first packet is received in step 1410 waiting for a packet to arrive, step 1450 begins and a timeout begins. Method 1400 predicts the receipt of additional packets, while a timeout occurs in step 1450. If step 1450 of the timeout spans the entire timeout period, method 1400 performs a data heuristic analysis in step 1452 in an attempt to construct an unreceived packet. [0073]

In step 1454, method 1400 determines if unreceived packets can be recovered from existing received packets. If the packet can be recovered, data heuristic synthesis is performed in step 1456. The payload is then fully marked in step 1458. Method 1400 then moves on to step 1422 to determine if the payload is complete. In step 1454, method 1400 moves to step 1460 if it is determined that the unreceived packet cannot be restored by the data heuristic. At step 1460, it is determined whether or not the set maximum number of retries has been reached. If the maximum number of retries for receiving packets to complete the payload is reached, step 1462 is followed by creating a log of failed payload reception. In such a case, the incomplete payload is transmitted to the file collector for reassembly in step 1442, and method 1400 proceeds to the end of the task in step 1444. [0074]

On the other hand, if the maximum number of retries has not occurred as determined in step 1460, step 1464 determines if any payload header packet has been received. If a payload header packet is received, step 1466 sends a request to the transmitter to retransmit the missing packet. If no header packet has been received, instead, following step 1468, the receiving device sends a message to the transmitting device indicating which packet was received. In either case, steps 1466 and 1468 are followed by step 1426, where the payload receive timeout is recalculated and the timeout is reset in the payload assembler. Method 1400 returns to step 1410 waiting for the packet to arrive. [0075]

It should be noted that the receiving protocol can follow packets that are not physically received and can communicate this with the transmitting protocol as well. This will enhance the ability of the physical layer manager of the transmit protocol to adapt to changes in the environment throughout the network. Therefore, the protocol can minimize retransmissions by reconstructing one packet or approximately one, while sufficiently allowing the conformity of the protocol to work effectively. In addition, it makes sense to return the number of unreceived packets back to the original protocol. [0076]

FIG. 15-17 is a timing diagram detailing a typical interaction between transmission and reception by protocol 20 of FIG. With reference to FIG. 15, the time axis shows one possible embodiment of transmission and communication processing between receivers according to protocol 20. At time t1, the transmitter packetizes the payload buffer by protocol 20 and sends the resulting packet to the receiver operating by protocol 20 over an interconnected network. In the time between t1 and t2, the receiving protocol receives multiple packets destined for it. At time t2, the receive protocol receives all packets. At this time, the receiving protocol authenticates the delivery of the payload. [0077]

With reference to FIG. 16, the time axis shows another possible embodiment of communication processing between transmitting and receiving devices using protocol 20. At time t1, the transmitter packetizes the payload buffer by protocol 20 and sends the resulting packet over a network interconnected to the receiver operating by protocol 20. Between the times t1 and t2, the receiving protocol receives many packets directed to it by the transmitting device. However, in this case, the receiving protocol receives at least one header packet instead of all the packets of the payload sent by the transmitting protocol. [0078]

Upon arrival of the first packet of the payload, the receive protocol advances the timeout period. If no other packet has been received at the end of this timeout, which is time t3 in the figure, the receive protocol sends a request to retransmit only the missing packet. Protocol 20 knows the packet actually received. Stabilizes which packets are lost based on and based on header packets that contain information detailing the contents of the transmitted payload and packet. At time t3, the header packet is received by the receive protocol. The information in the header packet specifically includes the number of packets sent (and expected by the receiving protocol) in its payload. [0079]

The receiving protocol then determines which packets have not arrived and need to be retransmitted by the transmitting protocol. The receiving protocol formulates a request for these missing packets and, at time t3, sends a request to the transmitter to retransmit a particular missing packet. Requests to retransmit missing packets are received by the transmit protocol at time t4. At time t5, the required missing packet is retransmitted, as the transmitting protocol requires by the receiving protocol. [0080] [0080]

At time t6, the receiving protocol receives at least some, if not all, of the missing packets. Upon receipt of any first of the missing packets, the receiving device advances the timeout as described above. At time t7, the timeout period initiated by the receive protocol expires without the arrival of all missing packets. The receiving protocol then requests another retransmission of the packet that is not yet found at this time. [0081]

The retransmission request is received by the transmit protocol at time t8. The transmission protocol then retransmits the required missing packet at time t9. These missing packets are received by the receive protocol at time t10. [0082]

The receive protocol then sends an acknowledgment (ACK) of receipt of the full payload at time t10. This cycle of sending packets; the receiving protocol advances the timeout on the first arrival of the packet; at the end of the timeout period, when a header packet arrives, the receiver requires the receiver to retransmit only certain missing packets. What to do; and only the missing packets are retransmitted until the entire data payload is delivered to the receiver. Therefore, the receiving device positively requests the retransmission of only all the packets that have not been received by utilizing the information contained in the packet header. [0083]

It should be noted that the FEC implemented in the protocol allows the receiving protocol to further attempt to reconstruct the missing packet. Alternatively, the protocol can attempt to reconstruct certain data, such as graphical data, through the use of data heuristics. [0084]

With reference to FIG. 17, another time series is provided for the operating environment of protocol 20 of FIG. At time t1, the transmitting protocol formats and packets the payload data for communication over the interconnected network with respect to the receiving protocol. The packet is sent to the receiving protocol at time t1. [0085]

If the receiving protocol receives the first packet in the payload, the receiving protocol begins a timeout period. If another packet arrives during this timeout period, the receiving protocol begins the timeout period again. If the timeout expires without the incoming packet being received, the receiving protocol attempts to determine if the entire data payload has been received. [0086]

At time t2, the receiving protocol is receiving the packet and is beginning a timeout period. At time t3, the receive protocol expires without receiving the header packet. Therefore, the receiving protocol cannot determine the number of packets to expect a particular payload, and knows which packets were not received in order to request the retransmission of packets that are not found in the transmitting protocol. I can't. However, the receive protocol introduces a request to the transmit protocol, indicating that it has not received a packet header for a particular payload, and sends with that request to identify information about the received packet. [0087]

At time t4, the sending protocol received a request from the receiving protocol, indicating that it did not receive all packets for a particular payload, and the receiving protocol did not receive a packet header for that payload. Show that. The transmitting protocol uses identification information about the packets received by the receiving protocol to determine which packets should be sent back to the receiving protocol. The transmitting protocol then retransmits the missing packet to the receiving protocol during the period between t4 and t5. [0088]

Receiving at least one packet by the receiving protocol advances the timeout period, as shown in Figure 15-17. If the receiving protocol determines that it is a missing packet, the transmitting protocol requires that those missing packets be retransmitted. If the receiving protocol receives a packet header, the information contained in the packet header can be used to specifically request the retransmission of only the missing packet. If the receiving protocol has not received the packet header, it determines that all appropriate data has not been received and the receiving protocol requires the packet header to be retransmitted. Within the request, the receive protocol enumerates the packets it has received, so that the transmit protocol retransmits only those data packets, along with unreceived header packets. [0089]

It should be noted that unlike traditional data protocols, the timeout values of the present invention have a dynamic nature. Communication between the transport protocol layer and the physical layer allows the protocol to dynamically estimate the appropriate timeout based on the history of data transmission. In the case of wireless links, the characteristics of the channel, the characteristics of the receiving and transmitting devices, and the actual time close to the time but before the data transmission allow the protocol to set an efficient timeout. [0090]

The typical timeout of a receiving protocol is dynamic in nature, especially when the link to the interconnected network is wireless. In this case, a more efficient timeout can be calculated based on the radio link characteristics. Again, the physical layer manager interaction and the transfer mechanism in the protocol make it possible to operate this in an efficient manner. The forwarding mechanism includes a timeout, allowing the receiving protocol to efficiently determine when to send a message requesting data retransmission to the sending protocol. [0091]

The receive protocol calculates and monitors the timeout metric to determine how long to wait for all packets in the payload to arrive before assuming that one will be lost and request retransmission. , Tell the receiving protocol. The metric can be thought of as a weighted sum of the average or steady-state network performance delay and the impact of the instantaneous delay caused by the current status of the radio link. [0092]

Therefore, in this typical embodiment, the payload timeout can be expressed as follows in some environments. [Outside 1]

<img file="JP2003521155A_D0001.tif" />here, [Outside 2]

<img file="JP2003521155A_D0002.tif" />= Static burst delay calculated value, f (x, ...) = Instantaneous transmission delay effect, W_static= Weighting of static delay approximation effect, W_dynamic= Weighting of instantaneous delay effect, W_static+ W_dynamic= 1. [0093]

If a non-header packet arrives, the current payload size was sent successfully last, as the total payload transmission time depends on the payload size and the header packet is not guaranteed to be the first. It is assumed to be the size of the payload. Timing metrics can be recalculated more precisely when receiving information about the size of header packets or payloads. If no payload has been previously received, the bootstrap default value may be used. [0094]

In a dynamic environment, the fluctuation of the average transmission delay can be considered to be related to the above weight W. The greater the change in the dynamic environment, the greater the instantaneous effect on the overall packet delay. In a wireless environment, W_dynamicIs close to 0. [0095]

In this classic example [Outside 3]

<img file="JP2003521155A_D0003.tif" />Is [Outside 4]

<img file="JP2003521155A_D0004.tif" />Is based on, here, E_pptt(x) = predicted or average value per packet transmission delay, σ_pptt(x) = standard deviation per packet transmission delay, N_tpkts= Total number of packets expected in the next burst packet And E_pptt(x) and σ_pptt(x) is calculated from past payload reception performance. [0096]

For each payload received and for each abended payload, the total accumulated time experienced is divided by the number of received packets in the payload so that it arrives with a delay per packet statistic for that payload. Therefore, the standard deviation is also calculated. These values are recorded as part of the transfer protocol. The average per packet transmission time is calculated as a moving average over the actual last M delays for the packet statistics experienced and stored again as part of the forwarding protocol. [0097]

Instantaneous radio effects involve many things, including cell-to-cell variation in geographical, cellular telephone networks and more. Therefore, the function f (x, ...) is network-specific and is different on all network links. The function is a weighted sum of delay donations from various sources of instantaneous delay. To monitor the delay of each of these sources, one or more persistent mechanisms are typically embedded within the transfer protocol. Individual functions can be hard-coded based on empirical evidence for a particular network, but in an automated manner, in real-time or otherwise, alternative adjustments or derivations. Will be done. [0098]

With reference to Figures 18a-c, the block diagram shows typical results of the interaction between the transfer mechanism and the data heuristic mechanism. Figure 18a shows the payload in its constituent packets. Packets are numbered in Figure 18a according to the order in which the payload is typically separated by the forwarding mechanism of Protocol 20 (shown in Figure 3). Packets are prioritized by heuristic mechanisms based on the relative importance of the data carried by the packet. [0099]

In typical compression, especially in graphical data compression, lower frequencies or lower energies can be reconstructed with the associated higher energy coefficients. Therefore, during compression, the coefficients of the data are assigned relative priorities based on the content of the data. Data that are more easily approximated or regenerated are assigned a lower rank than those that are difficult to regenerate. [0100]

Therefore, in Figure l8a, the more important or higher weighted packets are packet 0 and packet N-1. The next most important is packet N, etc., which continues to the least important data packet (packet 2). Data heuristics encode packets in a way that matches the importance of the data contained therein. [0101]

In Figure l8b, the forwarding mechanism reorders the packets by the relative weights of the data they contained. Therefore, packet N-1 is moved to the second slot. Packets are also renumbered, allowing the receiving protocol to more fully assess the importance of the information. In addition, it is possible to retain the original order of the packets. [0102]

In Figure l8b, the contents of packet N-1 are exchanged for the contents of packet 1. Therefore, the new packet 1 has equal or less importance to packet 0, which has equal or more importance to packet 2. However, the inner field of packet 1 indicates that the natural order of the packets is still in the N-1th place. This allows the first order of packets to be preserved if necessary. [0103]

With reference to Figure 18c, the block diagram shows the order of the packets in Figure l8a-b as received by the receiving protocol. While attempting to reconstruct the payload, the receiving protocol properly infers that packet N-3, originally transmitted as packet 1, is missing. The protocol easily determines that the lack of packet N-3 is acceptable for the final payload reconstruction. The protocol reorders the packets to determine that the transmitted packet N-3 is no greater than its importance "D" in payload reconstruction. Therefore, the protocol easily determines that the lack of packet N-3 is acceptable for the final payload reconstruction. In addition, it should be noted that the payloads can be assembled in the original order shown in Figure 18a, as the original payload is still in the data. [0104]

This order of importance of the data contained in the packet aids in the efficiency of physical transmission of the packet. Forwarding protocols can include means of prioritizing the sending of critical packets over well-characterized transmission channels. Therefore, if the transmission channel is degraded by a sudden condition during packet transmission, the transport protocol layer can forward packets that are less important to be transmitted, thereby important data. It will be possible to wait for a good channel to send. [0105]

With reference to FIG. 19, the timing diagram shows typical interactions between data heuristics, transfer mechanisms and the physical layer manager of protocol 20 (shown in FIG. 3). First, transmission A is enabled at time t1 and has good transmission characteristics, as indicated by the high level in FIG. Therefore, the forwarding mechanism indicates that higher priority packets determined by the data heuristic mechanism should be sent during this period. Therefore, the highest priority packets, packets 1 and 2, are transmitted during this period. [0106]

Suddenly, at time t2, the channel characteristics for transmission change to poor quality, as indicated by the low level in FIG. The physical layer manager shows this change to the transfer mechanism. The forwarding mechanism then disables the transmission of more high priority packets on that channel. This is to ensure that high priority packets are received by the receiving protocol with a higher probability. Therefore, based on poor transmission quality, the forwarding mechanism dictates that the lowest importance packets should be sent at this time. Therefore, packet N is sent during this period. [0107]

At time t3, the channel characteristics are good, but not as good as at time t1. This change is indicated to the transfer mechanism by the physical layer manager in protocol 20. With improved forwarding characteristics, the forwarding protocol enables sending higher critical packets. Alternatively, the transfer protocol can wait until an optimal condition, such as time t1, is met. The forwarding mechanism can then direct the transmission of an intermediate importance packet, such as packet 5. Based on the presence of good channel characteristics, various techniques for packet priority and handling during their forwarding are conceivable. [0108]

The current method can be easily extended to multiple channels. Because the physical layer manager contains databases with different channel characteristics, the transmission of priority packets can be delayed while the forwarding protocol is waiting for a better channel rather than a better channel condition. Of course, other methods are also possible. [0109]

Although embodiments of the present invention have been shown and described, extensive modifications, modifications and substitutions have been considered by the previous disclosures and some examples, and some features of the invention have been used in correspondence with other features. It is available without doing anything. Therefore, the appended claims should be broadly construed and construed in a manner consistent with the scope of the present invention.

[Simple explanation of drawings]

[Figure 1]

Figure 1 shows the OSI model protocol stack of the prior art. [Figure 2]

Figure 2 is an interconnected network that includes various wiring and wireless connections. [Fig. 3]

FIG. 3 is a protocol stack according to an embodiment of the present invention. [Fig. 4]

FIG. 4 is a data payload for transmission according to the protocol of the embodiment of the present invention. [Fig. 5]

FIG. 5 is a data packet for transmission according to the protocol of the embodiment of the present invention. [Fig. 6]

FIG. 6 is an authentication message sent by the receiving device when a header packet is received according to the protocol of the embodiment of the present invention. [Fig. 7]

FIG. 7 is an authentication message sent by the receiving device when a data packet is received but a header packet is not received according to the protocol of the embodiment of the present invention. [Fig. 8]

Figure 8 is a radio resource manager that operates in connection with the protocol stack in Figure 3. [Fig. 9]

FIG. 9 is a flowchart of a transmission procedure according to the protocol of the embodiment of the present invention. [Fig. 10]

FIG. 10 is a block diagram of a typical physical connection between the transport layer and the physical layer of the protocol stack of FIG. 3 according to an embodiment of the present invention. [Fig. 11]

FIG. 11 is a flowchart of the procedure of FIG. 9 detailing possible operation examples related to the receiving protocol according to the embodiment of the present invention. [Fig. 12]

FIG. 12 is a timing diagram of channel generation and operation according to the embodiment of the present invention. [Fig. 13]

FIG. 13 is a flowchart of the operations that occur in FIG. [Fig. 14A]

FIG. 14A is a flowchart of a reception procedure according to the protocol of the embodiment of the present invention. [Fig. 14B]

FIG. 14B is a flowchart of the reception procedure according to the protocol of the embodiment of the present invention. [Fig. 15]

FIG. 15 is a timing diagram of a transmission and reception operation example according to the embodiment of the present invention. [Fig. 16]

FIG. 16 is a timing diagram of another transmission and reception operation example according to the embodiment of the present invention. [Fig. 17]

FIG. 17 is a timing diagram of yet another transmission and reception operation example according to the embodiment of the present invention. [Fig. 18]

Figure l8a-c is a block diagram of a typical interaction between a transfer mechanism and a data heuristic mechanism according to an embodiment of the present invention. [Fig. 19]

FIG. 19 is a timing diagram of a typical interaction between a data heuristic mechanism, a transfer mechanism and the radio resource manager of FIG. 8 according to an embodiment of the present invention.