WO2000027076A1

WO2000027076A1 - A datalink protocol for a telecommunications method and system

Info

Publication number: WO2000027076A1
Application number: PCT/US1999/025353
Authority: WO
Inventors: Henry H. Houh
Original assignee: 3Com Corporation
Priority date: 1998-10-29
Filing date: 1999-10-28
Publication date: 2000-05-11
Also published as: AU1329600A

Abstract

A method and system for communicating with a telecommunication device (14, 18) over a network (22) is described. A communication channel (26) for exchanging information exclusively with the telecommunication device (14, 18) is established. A mode for transmitting data onto the network is selected from one of a reliable tra nsmission mode, an unreliable transmission mode, or a prioritized unreliable transmission mode. A packet is formed comprising the data to be transmitted to the telecommunication device and indicia representing the selected transmission mode. The packet is transmitted onto the network using the selected transmission mode.

Description

A DATALINK PROTOCOL FOR A TELECOMMUNICATIONS METHOD AND SYSTEM

Related Application This application claims the benefit of U.S. Provisional Application, Serial No.

60/106,116 filed October 29, 1998.

Field of the Invention

This invention relates to telecommunications systems and methods. More particularly, the invention relates to real-time telecommunications systems and methods that use a datalink protocol to provide various messaging services.

Background of the Invention With the advent of protocols for sending packetized data over networks, many have endeavored to send packetized voice signals over network infrastructure. The challenge has been to transmit packetized voice signals with reliability and quality equal to that attained by traditional switch-based telephone systems at a cost- competitive price. Because voice signals require real-time transmission, the general view has been that voice communications must have a "guaranteed" bandwidth channel, as in traditional switch-based telephone systems, in order to provide the desired quality of service. This view has spawned protocols (e.g., Asynchronous Transfer Mode (ATM) and IsoEthernet) that provide virtual, dedicated channels for voice and other real-time applications and a separate virtual data channel. Networks that implement these

protocols are expensive. These high costs have stunted the growth of the installed base of these products. An affordable and dominant network protocol is standard (IEEE 802.3) lOBaseT Ethernet, which does not provide a virtual guaranteed bandwidth channel. The large installed base of 10 Mbit Ethernet has created an incentive for the development of improved Ethernet protocols, such as 100 Mbit, 1 Gbit, and switched Ethernet.

For years, the telecommunications industry has sought to use a data network

infrastructure to carry voice (or audio) signals. For one, telephony, messaging, and computer integration are generally less expensive and less complicated over a single network infrastructure than over separate infrastructures. By sending voice over the

data network, the functionality of advanced telephone systems can merge with the

power, scalability and open connectivity of networking solutions.

Sending packetized voice over the same network infrastructure as packetized data eliminates the need for two infrastructures and takes advantage of advanced computer telephony and personal computer messaging applications running on the data network without the expense of hardware and software links. Another well-known advantage of packetized voice is the ability to transfer signals over wide area network

infrastructures (e.g., the Internet) as a means of saving on toll charges for telephone usage. Accordingly, various products have been introduced to send packetized voice - over the Internet. Some of these products include accessories that interface with the Private Branch Exchange (PBX) to enable time-division multiplexed digital signals to be converted into packet-based digital signals. The advantages of sending voice and data over the same infrastructure have been recognized for some time. Several entities have contemplated telecommunication systems that operate both voice and data communications over one network infrastructure (i.e., one wire for both voice and data). The challenge is to provide quality service for voice and other applications that need real-time bandwidth even when a network is heavily loaded with data traffic, and to do so in a cost-effective manner.

Summary The invention features a method for communicating with a telecommunication

device over a network. A mode for transmitting data onto the network to the telecommunication device is selected from one of a reliable transmission mode, an unreliable transmission mode, or a prioritized unreliable transmission mode. A packet is formed comprising the data to be transmitted to the telecommunication device and indicia representing the selected transmission mode. The packet is transmitted onto the network using the selected transmission mode.

For the reliable transmission mode and, optionally, the semi-reliable transmission mode, a communication channel for exchanging information exclusively with the telecommunication device is established. The communication channel can be

established by transmitting an initial packet to the telecommunication device and providing indicia in the initial packet representing the communication channel.

Subsequent packet communication is coordinated with the telecommunication device by using the indicia to generate a sequence number for the packet. At the telecommunication device, an expected packet number is generated from the indicia. The expected packet number is compared to the sequence number in the packet. An acknowledgment is issued when the sequence number in the packet matches the expected packet sequence number. The packet can be re-transmitted each time a predetermined period of time elapses until (i) the acknowledgment associated with the packet is received from the telecommunication device or (ii) the packet is

resent a maximum number of times. A second packet can be transmitted to the

telecommunication device after the acknowledgment associated with the first packet is received from the telecommunication device. For the reliable transmission mode, a

limit to the number of packets transmitted and unacknowledged by the telecommunication device is determined.

For the prioritized unreliable transmission mode, the packet is queued for transmission to the telecommunication device ahead in order of non-prioritized

packets. The prioritized unreliable transmission mode can be selected when the data in the packet are time-critical data, such as, for example, audio data and video data. Accordingly, data that are time-sensitive in nature, such as audio data, can receive preferential treatment for transmission onto the network.

In another aspect, the invention features a telecommunications device for communicating over a network with a receiving telecommunications device. The telecommunication device comprises a processor that selects a mode for transmitting . data from one of a reliable transmission mode, an unreliable transmission mode, or a

prioritized unreliable transmission mode. A packet generator forms a packet comprising the data to be transmitted to the receiving telecommunication device and indicia representing the transmission mode selected by the processor. A transmitter transmits the packet received from the packet generator onto the network using the selected transmission mode. The network can be an Ethernet network. For the reliable transmission mode and, optionally, the semi-reliable transmission mode, the telecommunication device includes a communication channel that is established for exchanging information exclusively with the receiving telecommunication device. The communication channel can be a unidirectional communication channel through which

packets of data flow exclusively to the receiving telecommunication device and through which acknowledgments flow exclusively from the receiving telecommunication device.

Description of the Drawings

The invention is pointed out with particularity in the appended claims. The above and further advantages of the invention may be better understood by referring to the following description in conjunction with the accompanying drawings, in which:

Fig. 1 shows an exemplary telecommunication system comprising a sending telecommunication device in communication with a receiving telecommunication

device over a network;

Fig. 2 shows an exemplary functional block diagram of the telecommunication

devices;

Fig. 3 shows an embodiment of a portion a protocol stack used to practice the invention;

Fig. 4 shows an exemplary format for packets transmitted over the network

according to the protocol of the invention;

Fig. 5 shows an exemplary process of establishing a communication channel between the sending device and the receiving device; and

Fig. 6 shows the sending and the receiving devices communicating using the reliable transmission mode.

Detailed Description

Fig. 1 shows an exemplary packet-based telecommunication system 10 incorporating the principles of the invention. The system 10 includes a sending telecommunication device 14 in communication with a receiving telecommunication

device 18 via a network 22. The network 22 can be, for example, a local-area network

(LAN) or a wide area network (WAN), an Intranet or the Internet. In one embodiment, the network 22 is an Ethernet network.

For simplicity of illustration two telecommunication devices 14, 18 are shown, although the system 10 can include many additional telecommunication devices. Examples of telecommumcation devices 14, 18 include a telephone set and a telephone line interface module(TLTM) unit. The TLIM unit can connect to the central office of

a telephone service provider via the public switched telephone network (PSTN) and can include any number of TLIMs for continuing expansion of the system 10. Each telecommunication device 14, 18 can have an Ethernet hub for connecting that device . to a network interface card of a computer system (not shown). Accordingly,

telecommunication devices and computer systems use the same network infrastructure. Communication between the telecommunication devices 14, 18 over the network 22 is accomplished using a packet-based protocol. The protocol of the invention provides a variety of messaging services (or transmission modes) for exchanging packets between the telecommunication devices 14, 18. The messaging services, described further below, include: (i) a reliable transmission mode, (ϋ) an unreliable transmission mode, (ϋi) a prioritized unreliable transmission mode, and (iv) a semi-reliable transmission mode.

Generally, the sending device 14 selects one of the transmission modes for

transmitting data to the receiving device 18. For the reliable and, optionally, the semi-

reliable transmission modes, the telecommunication devices 14, 18 establish a point-to- point communication channel 26 for exchanging information exclusively with each other. The communication channel 26 supports one source and one destination. In one embodiment, the commumcation channel 26 is unidirectional, i.e., packets containing data (i.e., data packets) flow exclusively from the sending device 14 to the

receiving device 18 and for the reliable transmission mode acknowledgment packets flow exclusively from the receiving device 18 to the sending device 14. In another embodiment, the communication channel 26 is bidirectional, wherein each telecommunication device 14, 18 is at the same time a source and a destination of data and acknowledgment packets. The sending device 14 forms a packet comprising the data to be transmitted to the receiving telecommunication device 18. The packet includes indicia representing -

the selected transmission mode. The sending device 14 transmits the packet onto the network 22 using the selected transmission mode. In transit, the transmitted packet can pass through one or more devices (not shown) connected to the network 22 that route the packet to the receivmg device 18.

While communicating with the receiving device 18 in one of the transmission modes, the sending device 14 can concurrently engage in communication with another telecommumcation device on the network 22 using any one of the transmission modes. For example, the sending device 14 can be communicating with the receiving device 18 in the reliable transmission mode while communicating with another telecommunication device in the prioritized unreliable mode. Communication with the

receiving device 18 by the sending device 14 can also occur concurrently using more than one of the transmission modes. For example, the sending device 14 can be

exchanging some packets with the receiving device 18 using the reliable transmission

mode amidst packets exchanged using the unreliable transmission mode. Further the sending device 14 can establish multiple concurrently active channels of communication with the receiving device 18.

Fig. 2 shows an exemplary functional block diagram of the telecommunication devices 14, 18. Each telecommunication device 14, 18 includes a packet controller 30 coupled to a physical network interface 40, memory 42, and an I/O subsystem 50. The memory 36 can be implemented using synchronous dynamic random access memory (SDRAM). Other types of memory devices can be used (e.g., SRAM).

They physical network interface 40 includes a transmitter 34 and a receiver 38 for transmitting and receiving packets over the network 22. The physical network interface 40 also includes a buffer 46 for queuing a packet next in line for transmission onto the network 22. The buffer 46 can hold one or more packets at a time for transmission by the transmitter 34 onto the network. In one embodiment, the physical

interface 40 is a Media Access Control device (MAC) operating as a 10/100 Ethernet port capable of a 100 Mpbs network data rate.

The I/O subsystem 50 includes I/O devices such as, for example, a telephone keypad, a telephone handset, a headset, a microphone, or a speaker. The I/O

subsystem 50 can receive input signals through the telephone keypad or audio signals through the microphone or handset, and can transmit signals to the speaker or the handset. For the purposes of converting analog signals to digital, and digital signals to analog, the I/O subsystem 50 includes codecs (not shown). The packet controller 30 is in electrical communication with the I/O subsystem 50 to form packets from the signals

received from the I/O devices. The packet controller 30 also controls the transfer of

packets between the memory 42 and the physical network interface 40.

Fig. 3 shows a portion of a protocol stack 52 used by each device 14, 18 of the system 10. The protocol stack portion 52 includes a physical layer 54, a data link layer 58, an optional network layer 62, e.g., Internet Protocol (IP), and a transport layer 66. The data link layer 58 of the invention can interface either the network layer 62 or the transport protocol 66.

At the sending device 14, upon accepting a packet from a higher layer (e.g., the

transport layer 66 or network layer 62), the data link layer 58 encapsulates the packet by adding a header and a trailer to the packet, and then sends the encapsulated packet to the physical layer 54 for transmission onto the network 22. At receiving device 18, . upon receiving an encapsulated packet from across the network 22, the physical layer 54 passes the encapsulated packet up to the data link layer 54. The data link layer 54 then examines and removes the header information from the encapsulated packet, and passes the remainder of the packet to the higher layers of the protocol stack 52.

Fig. 4 shows an exemplary general format 78 for packets transmitted over the network 22 according the principles of the invention. Packets can include other information beyond what is described below or have a different order of fields and still

be within the scope of the invention. The format 78 includes an Ethernet header 82 having a destination MAC address field, a source MAC address field, and an

encapsulation mode field 84. The destination and source MAC addresses are unique

six-byte addresses given to each device connected to the network 22. For example, in the Ethernet header 82 of a packet transmitted from the sending device 14 to the receiving device 18, the source MAC address is the unique MAC address of the sending device 14, and the destination MAC address is the unique MAC address of the receiving device 18.

The encapsulation mode field 84 of the Ethernet header 82 identifies the encapsulation mode employed to encapsulate information within packets exchanged between the sending 14 and the receiving 18 devices. In one embodiment, the encapsulation mode field 84 identifies one of three modes of packet header encapsulation: (1) the data link protocol of the invention, (2) 802.1p/Q IEEE standard, or (3) the IP protocol. If the encapsulation mode field 84 indicates that the encapsulation mode is the IP protocol, then the protocol field 88 of the encapsulation header 86 indicates that there is a second encapsulation header field 87, which in one . embodiment is a UDP header. In this embodiment, the Ethernet encapsulation mode

field 84 specifies the first encapsulation header 86 as an IP (Internet Protocol) header, and the protocol field 88 within the IP header specifies UDP (User Datagram Protocol) as the second encapsulation header type 87. Similarly, each encapsulation header specifies the subsequent encapsulated header type. Accordingly, the packet format 78 accommodates he layering of protocols.

If the encapsulation mode field 84 identifies either the 802.1p/Q or the IP/UDP mode, the Ethernet header 82 is followed by an encapsulation header 86. For either type of encapsulation mode, 802.1p/Q and IP/UDP protocols, the encapsulation header

86 includes a sub-header field 88 that can be used to activate the data link control

protocol of the invention. For example, the encapsulation mode field 84 of the Ethernet header 82 can identify the 802.1p/Q header, and the sub-header field 88 of the

subsequent encapsulation header 86 can identify the data link control protocol of the

invention. In this example, the data link control protocol of the invention operates in conjunction with the 802. lp/Q header. In other embodiments, the data link control protocol of the invention can operate in conjunction with the IP/UDP protocols or independently of either the 802. lp/Q or IP/UDP protocols. If either the encapsulation mode field 84 of the Ethernet header 82 or the subheader field 88 of the encapsulation header 86 indicates that the packet is to be transmitted according to the data link control protocol, the format 78 of the packet also includes a packet type field 89. Such packet type field 89 identifies the type of contents in the packet. Because each transmission mode is associated with one of the packet types, as described below, the packet type field 89 also correlates to the transmission mode for that packet. In one embodiment, each packet type is associated with a unique two-byte value. Each packet transmitted between the telecommunication devices 14, 18 includes one of these unique values in the packet type field 89 to indicate the data link control packet type. The various packet types transmitted between the telecommumcation devices 14, 18 include:

• a SYN packet, which is a control packet issued by the sending device 14 to establish a communication channel;

• a SYN ACK packet, which is an acknowledgment packet issued by the receiving device 18 in response to a SYN packet from the sending device 14;

• a REL DATA packet, which is a data packet issued by the sending device 14 using the reliable transmission mode;

• a REL ACK packet, which is an acknowledgment packet issued by the

receiving device 18 in response to receiving a valid REL D ATA data packet from the sending device 14;

• an UNR DATA packet, which is a data packet issued by the sending

device 14 using the unreliable transmission mode; • an AUD DATA packet, which is a data packet issued by the sending device 14, containing audio data and indicia of a priority status for placing the data packet onto the network 22;

• a SEM DATA packet, which is a data packet issued by the sending device 14 using the semi-reliable transmission mode;

• an ERROR packet, which is a control packet issued by the sending or

receiving devices 14, 18 indicating that an error has occurred in the network 22;

• a FIN packet, which is a control packet issued by the sending device 14 to close the communication channel 26; and

• a FTN ACK packet, which is an acknowledgment packet issued by the

receiving device 18 in response to receiving the FTN control packet

from the sending device 14.

When the packet type is a SYN, SYN ACK, UNR_DATN REL_DATN SEM_DATN REL_ACK, ERROR, FTN, or FTN_ACK packet, the packet format 78

also includes a data link control header 90. The data link control header 90, when

used, includes a sequence number and virtual device identifiers (VDNs). The sequence number is used to initialize the communication channel 26 and to coordinate communications between the telecommunication devices 14, 18 as described below. During initialization, a VDN is assigned to each logical device supported at a MAC address. Each MAC address can support up to 2^Λ16 internally mapped physical or

logical devices.

When the packet type is a S YN_ACK, AUD_DATN UNR_DATN REL_DATN SEM_DATN or ERROR packet, the packet format 78 also includes a data portion 94 that includes the data related to that particular communication. For example, for an AUD DATA packet, the relevant data include audio data generated or forwarded by the sending device 14. For a SYN_ACK packet, for example, the relevant data can include channel status, such as "channel already established" or "new

session created."

Establishing the Communication Channel

The system 10 uses two packet types to establish the commumcation channel 26 between the telecommunication devices 14, 18 when operating according to the

reliable and, optionally, the semi-reliable transmission modes. One packet type is the SYN packet, issued by the sending device 14; the other is the SYN_ACK packet, issued by the receiving device 18 in response to the SYN packet from the sending device 14.

To open the commumcation channel 26, the receiving device 18 needs to receive a SYN packet from the sending device 14. When a packet arrives, the packet

controller 30 of the receiving device 18 examines the packet type in the packet type field 89 to determine the packet type. If the packet type differs from a SYN packet, and the telecommunication devices 14, 18 have not yet established a commumcation

channel, the receiving device 18 sends an ERROR packet to the sending device 14

indicating that no communication channel exists.

Fig. 5 shows an exemplary process of establishing the commumcation channel 26. As shown, the telecommunication devices 14, 188 can establish the communication channel 26 with two packet transmissions in approximately the time expended by a packet making one round-trip. Generally, upon power up or reset or the initiation of a new channel indicated by an intention to send a semi-reliable or reliable packet to a new destination, the sending device 14 automatically initiates the process of establishing the communication channel 26 by sending the SYN packet to the receiving device 18 (step 102). The data link control header 90 of the SYN packet

includes a sequence number used by the devices 14, 18 to uniquely represent the communication channel 26 and to initialize packet numbering for subsequent packet

transmissions. The sending device 14 stores the sequence number, referred to as LastSequenceNumber, in a variable data structure. The sending device 14 can randomly generate the sequence number. In one embodiment, the randomly generated number is a 16-bit non-zero value. The generated sequence number should differ from a sequence number, if any, used to represent a previous communication channel established between the sending and receiving devices 14, 18. The response to the SYN packet by the receiving device 18 depends, in part, on the current communication status between the devices 14, 18. When the sending

and receiving devices 14, 18 are not currently communicating via an active

communication channel, the receiving device 18 generates at least two numerical values from the sequence number in the SYN packet. One value represents the commumcation channel that is being established between the sending and receiving devices 14, 18. This value is stored in a data structured referenced as ThisChannel. A second value represents the sequence number that the receiving device 18 expects to find in the next data packet received from the sending device 18. This value is stored in a variable data structure referenced as NextPacketToReceive. The following

exemplary pseudo-code illustrates the process:

ThisChannel = LastSequenceNumber;

NextPacketToReceive = (LastSequenceNumber + IncrementalValue); 5 where IncrementalValue is any positive or negative non-zero value. To keep both values, ThisChannel and NextPacketToReceive, within a predetermined range, the above process steps can use a modulo operation as follows:

ThisChannel = LastSequenceNumber%SequenceRange;

NextPacketToReceive = (LastSequenceNumber + IncrementalValue) 10 %SequenceRange; where SequenceRange is a large predetermined constant (e.g., 2^Λ16).

The receiving device 18 returns a SYN_ACK packet to the sending device 14

(step 106). The SYN ACK packet includes a sequence number that is the same as the sequence number in the SYN packet. By this acknowledgment, the receiving device

15 18 indicates to the sending device 14 that the receiving device 18 has received the SYN packet identified by the returned sequence number and is available to receive

packets. The SYN_ACK packet can include indicia in the data portion 94 of the packet indicating that the communication channel has been established. When the sending device 14 determines that the returned sequence number matches the sequence 20 number in the SYN packet, the sending device 14 releases the SYN packet from the buffer 46 and can commence transmitting data packets to the receiving device 18.

If instead the devices 14, 18 have already established a communication channel when the receiving device 18 receives the SYN packet, the receiving device 18 compares the sequence number in the SYN packet with the value ThisChannel. When the values match, the receiving device 18 returns a SYN ACK packet with indicia in the data portion 94 that the communication channel has already been established. This situation may occur when an earlier SYN ACK issued by the receiving device 18 is

lost during transmission, and the sending device 14 resends the SYN packet after waiting a predetermined period for the response. If instead the values differ, the receiving device 18 replies with a SYN_ACK packet indicating that a new communication channel has been established. The receiving device 18 generates ThisChannel and NextPacketToReceive as described above. The sending and receiving devices 14, 18 communicate using this new communication channel, and not with the previously established commumcation channel. Reliable Transmission Mode

In general, commumcation on the network 22 is unreliable in that packets can be lost, duplicated, delayed, or reordered during transmission. An advantage of the reliable transmission mode is that this mode can convert an unreliable telephone

communication path into a reliable communication channel. In the reliable transmission

mode, the receiving device 18 receives packets in sequential order and processes each packet only once. In one embodiment, the sending device 14 awaits the return of an acknowledgment from the receiving device 18 before transmitting the next packet. Other embodiments can employ windowing schemes with transmit windows larger than one packet.

Fig. 6 shows the sending and the receiving devices 14, 18 communicating using the reliable transmission mode. As described in Fig. 5, the devices 14, 18 establish a communication channel (steps 102 and 106). To generate a REL DATA data packet, the sending device 14 obtains the data for the data portion 96 of the packet, encapsulates the data portion 96 with the Ethernet and other header information as described above, generates a new sequence number, and places the new sequence number in the data link control header 90. The new sequence number equals the LastSequenceNumber incremented by the IncrementalValue. The sending device 14 then increments the LastSequenceNumber by the IncrementalValue.

In step 110, the sending device 14 transmits the REL DATA packet containing

the new sequence number to the receivmg device 18. If the new packet sequence number does not match the NextPacketToReceive value, the receiving device 18 ignores the REL DATA packet. If instead these values match, the receiving device 18 accepts the data in the data portion 96 of the packet, passing the data to the higher levels of the protocol stack 52, and replies with a REL_ACK packet (step 114). The REL ACK packet includes a return sequence number that matches the sequence number in the REL D ATA packet.

If instead the REL_DATA packet is a duplicate of a REL DATA packet

previously received by the receiving device 18, then the sequence number of that duplicate packet is different from the NextPacketToReceive value by the

IncrementalValue. In this event, the receiving device 18 returns a REL ACK packet having the same sequence number as the duplicate packet, but ignores the data in the REL_DATA packet.

If the sequence number in the received RELJDATA packet is neither the

NextPacketToReceive value nor differs from the NextPacketToReceive value by the IncrementalValue, the receiving device 18 ignores the RELJDATA packet and accompanying data, and does not return the REL ACK acknowledgment packet. The receiving device 18 deems the REL DATA packet to be an out-of-order packet.

As illustrated by steps 118 and 122, and again by steps 130, 134 and 138, when 5 the sending device 14 does not receive a proper REL ACK packet within a predetermined time-out period, which can change based upon the number of retry

attempts, the sending device 14 retransmits the RELJDATA packet. If the number of time-outs and subsequent retries exceeds a predetermined limit, the sending device 14 signals an error to the higher layers of the protocol stack 52. When the sending device

10 14 receives a REL ACK for which the sending device 14 is not waiting, the acknowledgment is ignored (step 145).

When the sending device 14 receives a REL ACK packet, the sending device 14 compares the returned sequence number in the REL_ACK packet with the LastSequenceNumber to determine whether the acknowledgment packet corresponds

15 to the currently unacknowledged REL DATN

In one embodiment, only one REL DATA can remain unacknowledged at any one time for the communication channel 26. The sending device 14 maintains a variable data structure, referenced as OutstandingUnackPackets, which keeps count of the number of transmitted and unacknowledged data packets. The sendmg device 14 0 sets the value of OutstandingUnackPackets to one after transmitting the REL DATA packet to the receiving device 18. Upon receivmg the REL_ACK packet, the sending

device 14 compares the returned sequence number in the REL ACK packet with the LastSequenceNumber. If the values match, then the sending device 14 resets the value of OutstandingUnackPackets to equal zero. Accordingly, the sending device 14 releases the buffer 46 for the next packet to be transmitted.

If instead the returned sequence number matches the sequence number of a RELJDATA packet transmitted immediately prior to the currently transmitted RELJDATA packet, the sending device 14 ignores and discards the REL_ACK

packet. If the returned sequence number matches neither the LastSequenceNumber nor the sequence number of 'die immediately prior RELJDATA packet, the sending

device 14 re-transmits the currently transmitted RELJDATA packet. In this regard, the sending device 14 operates as if a time out occurred while awaiting the REL_ACK packet.

Unreliable Transmission M le

For the unreliable transmission mode, an established communication channel between the sending and receiving devices is unnecessary, nor does the sending device 14 require acknowledgments from the receiving device 18 before transmitting the next packet. In the unreliable transmission mode, the sending device 14 forms a

UNRJ ATA data packet by setting the packet type to indicate unreliable transmission.

Transmission of the UNRJDATA packets is continuous; the buffer 46 is released

immediately for transmission of the next packet after the transmitter 34 places the

packet in the buffer 46 onto the network 22.

Prioritized Unreliable Transmission Mode

Like the unreliable transmission mode described above, the sending device 14 requires no acknowledgments from the receiving device 18 before transmitting the next packet when the packet is using the prioritized unreliable transmission mode. Also, an established communication channel between the sending and receiving devices is not

required. The prioritized unreliable transmission mode increases the likelihood the data packets are successfully transmitted onto the network 22. The sending system 14 can designate priority for a data packet by inserting the unique value associated with the AUD DATA packet type into the packet type field 89 of the packet format 78.

Data packets given a priority receive preferential treatment from the sending - device 14 over non-prioritized packets (e.g., REL DATA and UNRJDATA) for placement onto the network 22. For example, the sending device 14 can be currently

forwarding a RELJDATA packet onto the network 22, and waiting the return of an acknowledgment, when a AUD _D ATA packet is produced. The sending device 14 can remove the REL DATA packet from the buffer 46 and insert the AUD JD ATA packet in the buffer. In one embodiment, the preempted RELJDATA packet is discarded. In another embodiment, the RELJ ATA packet is stored until after the sending device 14 completely places the AUDJDATA packet on the network 22. Then the transmission of the preempted REL DATA can be resumed.

The prioritized unreliable transmission mode can be useful for transmitting packets containing time-sensitive information such as a voice (or audio) data and video data. (Audio data are time-sensitive because as time elapses the usefulness of the audio data decreases significantly.) Consequently, audio data can be given, in effect, a separate path to ensure that such data reaches the network 22 and, consequently, the

target destination while the audio data are still useful.

Semi-Reliable Transmission Mode

The semi-reliable transmission mode is a hybrid of the reliable transmission mode and the unreliable transmission mode. In one embodiment, like the reliable transmission mode, the semi-reliable transmission mode establishes a communication channel between the sending and receiving devices so that the devices can exchange information exclusively with each other. In another embodiment, this communication channel need not be established. Like the unreliable transmission mode, the sending device 14 may, under conditions described below, transmit a packet to the receiving - device 18 without having received an anticipated acknowledgment for a previously transmitted semi-reliable packet.

The sending system 14 can designate a data packet for semi-reliable transmission by inserting the unique value associated with the SEM_DATA packet type into the packet type field 89. After the sending device 14 transmits an SEM DATA packet onto the network 22, the sending device 14 waits a predetermined period of time for return of a corresponding acknowledgment. During that predetermined period of time, the sending device 14 may retransmit the packet. If

the acknowledgment returns within that period, the sending device 14 prepares and sends the next packet onto the network 22. However, if that period of time elapses without receiving the acknowledgment, the sending device 14 removes the SEM_DATA packet from the buffer 46 and transmits the next packet onto the network 22.

Closing the Channel Connection

The sending device 14 can close the communication channel 26 by issuing a

FIN packet. The sending system 14 can designate a packet as a FTN packet by inserting the unique value associated with the FTN packet type into the packet type field 89. The FTN packet also includes a value representing the currently established communication channel that the sending device 14 is attempting to close.

In response to the FTN packet, the receiving device 18 issues a FIN ACK packet. The FTN ACK packet includes a return value matching the value obtained

from the FIN packet. The sending device 14 compares the returned value in the FTN_ACK packet with the value sent in the FTN packet. A match closes the communication channel 26. To resume commumcation with the receiving device 18,

the sending device 14 must issue SYN packet.

If the sending device 18 does not receive the FIN_ACK within a predetermined period of time, the sending device re-transmits the FIN packet. After a maximum number of attempts, the sending device signals an error to the higher layers of the network architecture.

While the invention has been shown and described with reference to specific preferred embodiments, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and

scope of the invention as defined by the following claims.

Claims

What is Claimed is:

1. A method for communicating with a telecommunication device over a network, the method comprising the steps of: selecting a mode for transmitting data to the telecommunication device from one of a reliable transmission mode, an unreliable transmission mode, or a prioritized -

unreliable transmission mode; forming a packet comprising the data to be transmitted to the telecommunication device and indicia representing the selected transmission mode; and transmitting the packet onto the network using the selected transmission mode.

2. The method of claim 1 further comprising the step of establishing a communication channel for exchanging information exclusively with the telecommunication device.

3. The method of claim 2 selecting the reliable transmission mode and wherein

the packet is a first packet and the step of establishing the communication channel

comprises the steps of: transmitting an initial packet representing the communication channel; and

coordinating subsequent packet communication with the telecommunication

device by using the indicia to generate a sequence number for the first packet.

4. The method of claim 1 selecting the reliable transmission mode and further comprising the step of resending the packet each time a predetermined period of time elapses until (i) an acknowledgment associated with the packet is received from the telecommunication device or (ϋ) the packet is resent a maximum number of times.

5. The method of claim 1 selecting the reliable transmission mode and wherein the packet is a first packet and further comprising the step of transmitting a second packet to the telecommunication device after an acknowledgment associated with the first packet is received from the telecommumcation device.

6. The method claim 5 further comprising the steps of: generating an expected packet number from the indicia; receiving the first packet at the telecommunication device;

comparing the expected packet number with the sequence number in the first packet; and issuing an acknowledgment when the sequence number in the first packet matches the expected packet sequence number.

7. The method of claim 1 selecting the reliable transmission mode and further comprising the step of receiving an acknowledgment from the telecommunication

device in response to the transmitted packet.

8. The method of claim 7 further comprising the steps of:

providing a sequence number in the packet; and providing a second sequence number in the acknowledgment that corresponds to the sequence number in the packet.

9. The method of claim 1 selecting the prioritized unreliable transmission mode and further comprising the step of queuing the packet for transmission to the telecommunication device ahead in order of non-prioritized packets.

10. The method of claim 1 selecting the prioritized unreliable transmission

mode when the data are time-sensitive data.

11. The method of claim 1 wherein the telecommunication device is a first telecommumcation device and further comprising the step of establishing a first communication channel with the first telecommunication device and a second

commumcation channel with a second telecommumcation device connected to the network, wherein the second communication channel is concurrently active with the first communication channel.

12. The method of claim 11 wherein the first and second telecommunication

devices are the same telecommumcation device.

13. The method of claim 1 selecting the reliable transmission mode and further comprising the step of determining a limit for a number of packets transmitted to and

unacknowledged by the telecommunication device.

14. The method of claim 13 further comprising the step of changing the limit

from the determined number while the communication channel is active.

15. A method for communicating with a telecommunication device over a network, the method comprising the steps of: selecting a mode for transmitting data to the telecommunication device from one of a reliable transmission mode, an unreliable transmission mode, a prioritized unreliable transmission mode, or a semi-reliable transmission mode; forming a packet comprising the data to be transmitted to the telecommunication device and indicia representing the selected transmission mode; and transmitting the packet onto the network using the selected transmission mode.

16. A telecommunication device for communicating over a network with a receiving telecommunications device, comprising: a processor selecting a mode for transmitting data to the receiving telecommumcation device from one of a reliable transmission mode, an unreliable

transmission mode, or a prioritized unreliable transmission mode; a packet generator forming a packet comprising the data to be transmitted to the receiving telecommunication device and indicia representing the transmission mode

selected by the processor; and

a transmitter transmitting the packet received from the packet generator onto the network using the selected transmission mode.

17. The telecommunications device of claim 16 wherein the network is an Ethernet network.

18. The telecommunications device of claim 16 further comprising a

communication channel established exclusively between the telecommumcation devices, wherein the communication channel is a unidirectional commumcation channel - through which packets of data flow exclusively to the receiving telecommunication device.

19. The telecommunications device of claim 16 further comprising a communication channel established exclusively between the telecommunication devices, wherein the communication channel is a unidirectional communication channel through which acknowledgments flow exclusively from the receiving telecommumcation device.

20. The telecommunications device of claim 16 further comprising a commumcation channel established exclusively between the telecommunication device, wherein the commumcation channel is a bidirectional commumcation channel through which data is exchanged in both directions between the sending and receiving devices.

21. In a telecommunications network including a receiving telecommunication

device and a sending telecommumcation device, a protocol for communicating

between the sending and receiving telecommunication devices comprising: computer-executable services transmitting data using one of a reliable transmission mode, an unreliable transmission mode, a prioritized unreliable transmission mode; and computer-executable operations that form a packet comprising the data to be

transmitted to the receiving telecommunication device and indicia representing the selected transmission mode.

22. The protocol of claim 21 further comprising computer-executable operations that establish a commumcation channel for exchanging information exclusively with the receiving telecommunication device.

23. The protocol of claim 21 wherein the computer executable operations that form the packet are implemented at a data link layer.